APISENSE®: a distributed platform for deploying, executing and managing data collection campaigns using smart devices - thèse Informatique - Revenir à l'accueil

 APISENSE-a-distribut..> 04-Jan-2015 21:51  5.7M  

 APISENSE-terminaux-i..> 04-Jan-2015 21:53  5.4M  

 Addition-formulae-on..> 04-Jan-2015 21:26  3.0M  

 Classification-et-ca..> 04-Jan-2015 11:58  1.3M  

 Collaboration-de-tec..> 04-Jan-2015 21:27  2.4M  

 Contributions-a-la-v..> 04-Jan-2015 21:51  5.4M  

 Equilibrage-de-charg..> 04-Jan-2015 21:25  3.2M  

 Faciliter-le-develop..> 04-Jan-2015 21:56  4.4M  

 Factorisation-matric..> 04-Jan-2015 11:59  2.7M  

 Generation-automatiq..> 03-Jan-2015 22:04  2.6M  

 Gestion-de-la-variab..> 04-Jan-2015 21:55  4.8M  

 Idéalisation-d-asse..> 04-Jan-2015 11:57  2.1M  

 Inference-d-invarian..> 04-Jan-2015 11:58  1.5M  

 Integration-de l-inf..> 04-Jan-2015 21:25  3.4M  

 Interrogation-de-gra..> 03-Jan-2015 22:04  2.9M  

 La-gestion-du-trafic..> 03-Jan-2015 22:01  4.1M  

 Langage-de-mashup-Th..> 04-Jan-2015 21:24  4.1M  

 Les-logiciels-de-ges..> 03-Jan-2015 22:03  3.1M  

 Lh-rs-p2p-une-nouvel..> 04-Jan-2015 11:59  2.7M  

 Mesure-de-la-fragili..> 04-Jan-2015 21:24  3.8M  

 Meta-modelisation-du..> 04-Jan-2015 21:56  4.1M  

 Methode-de-classific..> 04-Jan-2015 11:58  1.3M  

 Methodes-sequentiell..> 04-Jan-2015 21:27  2.2M  

 Mise-en-oeuvre-appli..> 04-Jan-2015 21:54  4.4M  

 Modelisation-d-une-a..> 04-Jan-2015 21:53  5.0M  

 Modelisation-et-dete..> 04-Jan-2015 11:57  1.6M  

 Normalisation-et-App..> 03-Jan-2015 22:01  4.1M  

 Prise-en-compte-de-l..> 03-Jan-2015 22:04  2.8M  

 Qualification-system..> 04-Jan-2015 21:26  2.8M  

 Reconnaissance-de-co..> 03-Jan-2015 22:03  3.6M  

 Segmentation-supervi..> 04-Jan-2015 11:58  1.3M  

 Services-de-repartit..> 03-Jan-2015 21:59  4.7M  

 Techniques-visuelles..> 04-Jan-2015 21:27  2.7M  

 The-Emergence-of-Mul..> 03-Jan-2015 22:05  2.5M  

 Trigraphes-de-Berge-..> 03-Jan-2015 22:02  3.9M   

Vers-une-capitalisat..> 03-Jan-2015 22:00 4.6M 

 Application-Agnostic..> 03-Jan-2015 21:16  2.1M  

 Continuity-Editing-f..> 03-Jan-2015 17:35  4.0M  

 Double-WP-Vers-une-p..> 03-Jan-2015 17:36  4.0M  

 Effective-Reproducib..> 03-Jan-2015 21:18  2.0M  

 Enforcing-reuse-and-..> 03-Jan-2015 21:17  2.0M  

 Extracting-Bounded-s..> 03-Jan-2015 21:19  4.0M  

 Fingerprint-Quality-..> 03-Jan-2015 21:16  2.1M  

 GPU-Load-Balance-Gui..> 03-Jan-2015 21:18  4.0M  

 Minkowski-sum-of-pol..> 03-Jan-2015 21:17  2.0M  

 Quality-Assessment-o..> 03-Jan-2015 21:16  2.1M  

 Rester-statique-pour..> 03-Jan-2015 17:35  4.0M  

 The-Power-of-Polynom..> 03-Jan-2015 21:16  2.1M  

 Analyse-numerique-Co..> 03-Jan-2015 17:33  3.0M  

 Approches-m-k-firm-p..> 03-Jan-2015 17:27  3.7M  

 COURS-LA-CULTURE-INF..> 03-Jan-2015 17:25  3.8M  

 CRYPTANALYSE-DE-RSA-..> 03-Jan-2015 17:33  3.0M  

 Cours-Interconnexion..> 03-Jan-2015 17:34  3.0M  

 Cours-d-Analyse-et-C..> 03-Jan-2015 17:22  3.9M  

 Efficient-C++finite-..> 03-Jan-2015 17:30  3.5M  

 Efficient-C++finite-..> 03-Jan-2015 17:31  3.2M  

 Fondements-de-l-Info..> 03-Jan-2015 17:22  4.0M  

 INTRODUCTION-A-L-INF..> 03-Jan-2015 17:24  3.8M  

 Informatique-et-Ling..> 03-Jan-2015 17:24  3.8M  

 Initiation-a-l-infor..> 03-Jan-2015 17:26  3.8M  

 Intelligence-Artific..> 03-Jan-2015 15:16  2.5M  

 Introduction-a-l-ana..> 03-Jan-2015 17:27  3.7M  

 Introduction-a-la-ge..> 03-Jan-2015 17:26  3.8M  

 Le-routage-externe-B..> 03-Jan-2015 17:32  3.1M  

 Le-systeme-d-informa..> 03-Jan-2015 17:32  3.1M  

 Lecture1_Linear_SVM_..> 03-Jan-2015 14:57  2.4M  

 Lecture2_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

 Lecture3_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

 Lecture4_Kenrels_Fun..> 03-Jan-2015 14:55  2.4M  

 Lecture5_Kernel_SVM...> 03-Jan-2015 14:55  2.4M  

 Lecture6_SVDD.pdf.htm   03-Jan-2015 14:54  2.4M  

 Lecture7_Cross_Valid..> 03-Jan-2015 14:54  2.4M  

 Lecture8_Multi_Class..> 03-Jan-2015 14:57  2.4M  

 Lecture9_Multi_Kerne..> 03-Jan-2015 14:53  2.5M  

 Lecture10_Outilier_L..> 03-Jan-2015 14:53  2.5M  

 Les-reseaux-sans-fil..> 03-Jan-2015 15:17  2.5M  

 NooJ-pour-l-Intellig..> 03-Jan-2015 17:30  3.2M  

 Outils-Logiques-pour..> 03-Jan-2015 15:15  2.8M  

 Presentation-de-la-r..> 03-Jan-2015 17:33  3.0M  

 Projet-IP-SIG-Signal..> 03-Jan-2015 15:16  2.5M  

 Robotique-Mobile-PDF..> 03-Jan-2015 15:16  2.6M  

 Systeme-informatique..> 03-Jan-2015 15:17  2.5M  

 Systemes-Multi-Agent..> 03-Jan-2015 17:28  3.5M  

 Tutoriel-Android-TP-..> 03-Jan-2015 14:57  2.3M  

 Understanding-SVM-th..> 03-Jan-2015 14:57  2.4M  

 Une-histoire-de-la-m..> 03-Jan-2015 17:28  3.5M  

 Une-introduction-aux..> 03-Jan-2015 17:31  3.1M  

 Vers-une-signalisati..> 03-Jan-2015 17:25  3.8M 

HAL Id: tel-01087325 https://tel.archives-ouvertes.fr/tel-01087325 Submitted on 25 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Département de formation doctorale en informatique UFR IEEA École doctorale SPI Lille APISENSE® : une plate-forme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données sur des terminaux intelligents THÈSE présentée et soutenue publiquement le 05/11/2014 pour l’obtention du Doctorat de l’Université Lille I (spécialité informatique) par Haderer Nicolas Composition du jury Rapporteurs : Chantal Taconet, TELECOM SudParis, France Ernesto Exposito, INSA Toulouse, France Examinateurs : Stéphane Frénot, INSA Lyon, France Luigi Lancieri, Université Lille I, France Directeur : Lionel Seinturier, Université Lille I, France Co-encadrant : Romain Rouvoy, Université Lille I, France Laboratoire d’Informatique Fondamentale de Lille – Inria Lille - Nord Europe UMR Lille 1/CNRS 8022R É S UM É Le mobile crowdsensing est une nouvelle forme de collecte de données exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour collecter massivement des données environnementales ou comportementales d’une population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans de nombreux domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements socioculturels. Cependant, le mobile crowdsensing n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que faire face à l’hétérogénéité des plateformes mobiles disponibles. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au mobile crowdsensing pour adresser les limitations liées au développement, au déploiement et à l’exécution de campagnes de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. Plus particulièrement, APISENSE® propose un environnement distribué favorisant le développement et le déploiement rapides de campagnes de collecte, tout en prenant en considération des contraintes telles que la protection de la vie privée des utilisateurs ou encore les ressources énergétiques limitées de leurs terminaux. Pour atteindre ces objectifs, APISENSE® repose sur le modèle de composant SCA et sur l’ingénierie des lignes de produits logiciels, offrant ainsi un environnement modulaire et facilement configurable pour supporter une grande diversité de campagnes de collecte. Un modèle de programmation de haut niveau a également été proposé permettant de s’affranchir de toute la complexité liée aux développements d’applications de collecte mobiles. APISENSE® a été utilisé pour réaliser une campagne de collecte de données déployée auprès d’une centaine d’utilisateurs au sein d’une étude sociologique, et évalué à travers des expériences qui démontrent la validité, l’efficacité et le passage à échelle de notre solution. iiiA B S T R A C T Mobile crowdsensing is a new form of data collection that takes advantage of millions smart devices already deployed throughout the world to collect massively environmental or behavioral data from a population. Recently, this type of data collection has attracted interest from a large number of industrials and academic players in many areas, such as the study of urban mobility, environmental monitoring, health or the study of sociocultural attitudes. However, mobile crowdsensing is in its early stages of development, and many challenges remain to be addressed to take full advantage of its potential. These challenges include privacy, limited energy resources of devices, development of reward and recruitment models to select appropriates mobile users and dealing with heterogeneity of mobile platforms available. In this thesis, we aim to reconsider the architectural design of current mobile crowdsensing systems to provide a simple and effective way to design, deploy and manage data collection campaigns. The main contributions of this thesis are organize around APISENSE®, the resulting platform of this research. In particular, APISENSE® offers a distributed environment based on the SCA component model and software product line engineering , providing a modular and flexible environment to support a wide variety of data collection campaigns. Futhemore, APISENSE® takes into account constraints, such as protecting the privacy of users or limited energy resources devices. We also propose a high-level programming model to get rid of the complexity associated with the development of mobile data collection applications. APISENSE® has been used to carry out a data collection campaign deployed over hundred of users in a sociological study and evaluated through experiments demonstrating the validity, effectiveness and scalability of our solution. vTA B L E D E S M AT I È R E S 1 introduction 9 1.1 Contexte 9 1.2 Problématiques 10 1.3 Objectif du manuscrit 12 1.4 Contributions 13 1.5 Plan du manuscrit 15 1.6 Publications 16 I État de l’art 19 2 systèmes de collecte de données 21 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 12.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 II Contributions 53 3 collecte mobile de données 55 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 4 collecte répartie de données 91 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 24.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 III Évaluations 127 5 pratiques culturelles et usages de l’informatique connectée 129 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 6 évaluation du modèle collaboratif 145 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 IV Conclusion 157 7 conclusion 159 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 3bibliographie 165 4TA B L E D E S F I G U R E S Figure 1 Vue d’ensemble de APISENSE® 15 Figure 2 Développement d’une application mobile avec FunfInABox 35 Figure 3 Architecture de Medusa [55] 41 Figure 4 Architecture de PRISM [16] 44 Figure 5 Architecture de Bubble-sensing [45] 45 Figure 6 Architecture de Anonysense [62] 48 Figure 7 Tableau comparatif des plate-formes MCS 52 Figure 8 Interface de Programmation APISENSE 61 Figure 9 Exemple de capture d’écran d’un retour utilisateur 67 Figure 10 Architecture de l’intergiciel mobile 69 Figure 11 Interaction de la couche d’exécution 69 Figure 12 Règles de confidentialité 75 Figure 13 Exemple de contenu web disponible via le FeedbackManager 78 Figure 14 Flux de données de l’expérience Manipulation de Lego NXT 82 Figure 15 Impact d’APISENSE sur la consommation énergétique 88 Figure 16 Impact des capteurs sur la consommation énergétique 89 Figure 17 Vue d’ensemble d’APISENSE® 93 Figure 18 Architecture SCA du serveur central 96 Figure 19 Modèle de caractéristiques d’une campagne de collecte 102 Figure 20 Architecture initiale d’un nœud de collecte 107 Figure 21 Processus de génération d’une architecture SCA 108 Figure 22 Architecture SCA d’une campagne de collecte 109 Figure 23 Interaction des composants APISENSE® 111 Figure 24 Exemple d’extension : Export des données au format KML 114 Figure 25 Composant SCA responsable du recrutement collaboratif 120 Figure 26 Distribution des capteurs virtuels 121 Figure 27 Données collectées par l’étude PRACTIC 132 Figure 28 Exemple de retour utilisateur PRACTIC 137 Figure 29 Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 138 5Figure 30 Nombre d’inscriptions par jour à PRACTIC 140 Figure 31 Diversité des équipements mobiles 141 Figure 32 Taux de participation à la collecte opportuniste 141 Figure 33 Taux de participation à la collecte participative et opportuniste 142 Figure 34 Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 142 Figure 35 Architecture du simulateur de traces de mobilité 147 Figure 36 Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique 149 Figure 37 Comparaison de la couverture géographique selon différentes périodes de la journée 150 Figure 38 Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte 152 Figure 39 Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153 6L I S T E D E S TA B L E A U X Table 1 Liste des fonctions d’observation d’événements prédéfinis. 61 Table 2 Liste des paramètres d’une fonction de rappel 61 Table 3 Configuration de l’observation de la position d’un utilisateur 62 Table 4 Liste des fonctions d’un objet de souscription 64 Table 5 Liste des fonctions de la façade de collecte 65 Table 6 Liste des fonctions de la façade dédiée à la création des questionnaires 66 Table 7 Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) 80 Table 8 Tableau décrivant la qualité du système de classification 85 Table 9 Comparaison de l’expressivité et du nombre de lignes de code 87 Table 10 Propriétés définissant une expérience de collecte 97 Table 11 Interface de programmation dédiée à la définition des campagnes de collecte communautaires. 116 Table 12 Façade utilisée pour les besoins de l’application PRACTIC 138 71 I N T R O D U C T I O N 1.1 contexte La dernière génération de terminaux intelligents tels que les smartphones ou les tablettes tactiles est rapidement devenue omniprésente dans notre quotidien. On recense, actuellement, plus d’un milliard de smartphones à travers le monde et ce nombre ne va cesser d’augmenter [42]. Non seulement dotés d’une grande capacité de calcul et d’une connexion Internet en continu, ces terminaux sont désormais programmables et équipés d’un grand nombre de capteurs sophistiqués permettant de prendre des images, capter des sons, mesurer la température ou la pression atmosphérique tout en donnant la position géographique. De ce fait, leurs usages permettent de générer de nombreuses traces numériques d’activités, capables d’identifier nos habitudes, nos relations sociales ainsi que l’environnement dans lequel on évolue. De par leurs fortes présences dans notre société et leurs hautes prouesses technologiques, ces terminaux ont ouvert la voie à une nouvelle forme de collecte de données à grande échelle, récemment appelée le Mobile Crowd Sensing (MCS) [27]. Plus particulièrement, le MCS fait référence à l’ensemble des applications qui impliquent des citoyens ordinaires, munis de leurs terminaux intelligents, afin de collecter et de partager des données dans le but de mesurer des phénomènes d’un intérêt commun. Ces dernières années, de nombreuses recherches ont été menées pour tenter d’exploiter le potentiel du MCS dans de nombreux domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement ou la santé [39, 11]. Quelques exemples d’applications novatrices dans ce secteur comprennent la collecte et le partage de données concernant la qualité de l’air [19], le trafic routier [51], la pollution sonore [47], les performances cyclistes [20], ou encore des informations relatives aux prix des produits de consommation [17]. 91.2 problématiques Comme la revue de la littérature l’indique, le MCS n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel [39, 27, 66]. Ces défis sont particulièrement liés à l’implication d’individus rationnels, qui sont au centre du système de collecte de données. Cela demande de prendre en considération de nombreux aspects non-fonctionnels qui ne sont pas directement liés à la collecte de données difficiles en elle-même, rendant par conséquent le développement de ces systèmes encore difficile. Plus particulièrement, il est nécessaire de prendre en compte les points suivants : énergie : Bien que la dernière génération des terminaux intelligents continue de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces terminaux restent limitées. Sans une gestion rigoureuse de l’énergie consommée par les applications de collecte, la batterie de ces terminaux peut s’épuiser en quelques heures, décourageant ainsi les individus à installer ces applications. respect de la vie privée : Sans un mécanisme de protection approprié, les applications mobiles peuvent se devenir de parfaits espions, en révélant potentiellement des informations privées sur leur propriétaire. Il est par exemple possible qu’elles puissent enregistrer des conversations intimes ou prendre des photos d’une scène privée, d’identifier des trajets quotidiennement empruntés par le propriétaire du terminal et d’observer ses principaux lieux de vie tels que son domicile ou son lieu de travail. Ce point représente également un frein majeur pour l’acceptation de ces applications par les individus. D’un autre coté, certaines de ces données peuvent se révéler indispensables pour l’objectif de la collecte de données. compromis : Prendre en compte ces deux derniers points demande généralement le développement d’algorithmes sophistiqués permettant de faire un compromis entre l’énergie consommée par les applications mobiles, leur niveau d’intrusion dans la vie privée des individus et la qualité des données collectées. diversité : De plus, les développeurs doivent également faire face à la diversité des systèmes d’exploitations mobiles disponibles sur le marché (par ex. Android, iOS). Pour déployer une application auprès d’un grand nombre d’individus, les développeurs doivent généralement étudier et développer une application pour chacun de ces systèmes, entraînant par conséquent un coût important (c.-à-d. temps de développement, monétaire). 10passage á l’échelle : Finalement, ces systèmes doivent également faire face au défi de collecter une grande quantité de données reportées par des utilisateurs répartis à travers le monde. De ce fait, déployer une application auprès de plusieurs millions d’utilisateurs qui collectent et propagent continuellement des données vers un serveur serait inefficace, et demanderait des ressources importantes en terme de CPU, de mémoire et d’espace de stockage de l’infrastructure hébergeant l’application serveur pour stocker et analyser ces données. En outre, ces applications peuvent générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. Dans ce contexte, il est nécessaire de mettre en place un modèle de déploiement adapté pour recruter les bons utilisateurs au bon moment, capable de collecter seulement les données utiles à la campagne de collecte. À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisables dans un contexte non anticipé [6]. Ces systèmes ont été conçus complètement indépendamment les uns des autres, ne partageant aucun module logiciel commun, alors qu’ils ont à faire face à des problématiques communes. La mise en place d’une nouvelle campagne de collecte demande généralement de développer un nouveau système à partir de zéro, pouvant entraîner la négligence de certains aspects non fonctionnels, comme protéger la vie privée des individus, à cause de contrainte de temps ou une expertise limitée dans ce domaine. Ce manque d’approche réutilisable, également pointé du doigt dans la littérature [39, 27, 60, 66], entrave ainsi l’adoption du MCS par de nombreux acteurs intéressés par ce type de collecte. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiées au MCS pour adresser les limitations identifiées ci-dessus liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Plus particulièrement, l’objectif des travaux de cette thèse est de proposer une plate-forme générique, favorisant le développement et le déploiement rapides de campagnes de collecte de données pouvant être menées dans une grande variété de domaines. 111.3 objectif du manuscrit Comme nous l’avons décrit dans la section précédente, le développement d’applications utilisant le MCS comme source de collecte de données est une tâche complexe, nécessitant une grande expertise. Toutefois, pour ouvrir cette forme de collecte à de nombreux acteurs académiques et industriels, nous proposons dans cette thèse une plate-forme générique qui facilite le développement et le déploiement de ces applications de collecte. Plus particulièrement, nous adressons dans cette thèse les points suivants : Simplifier le développement des applications de collecte Le premier défi concerne le développement des applications de collecte. Actuellement, ce développement nécessite une grande expertise dans les systèmes d’exploitation des terminaux mobiles disponibles sur le marché. Pour simplifier leur développement, il est nécessaire de proposer un modèle de programmation nouveau fournissant une abstraction complète de ces systèmes d’exploitation. Dans ce contexte, les principaux défis sont de proposer un modèle : i) assez général pour supporter une grande variété d’activités de collecte qui peuvent impliquer une grande variété de capteurs, ii) permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur, iii) et finalement portable pour être en mesure de s’exécuter sur les différents systèmes d’exploitation. D’autre part, il est nécessaire de fournir un environnement fiable assurant la confidentialité des utilisateurs, efficace pour ne pas empêcher une utilisation normale des terminaux mobiles et faciles d’utilisation pour les utilisateurs voulant participer aux collectes de données. Mise en œuvre d’une plate-forme générique de collecte de données Le deuxième défi concerne l’architecture de la plate-forme responsable du déploiement des applications de collecte, de la persistance et de l’analyse des données collectées. La plupart des plate-formes proposées actuellement sont souvent monolithiques, donnant très peu ou pas de possibilités de personnalisation. Cependant, les applications de collectes peuvent être menées dans une grande variété de domaines, nécessitant diffé- 12rents services de l’application serveur pour analyser et stocker les données collectées ou encore déployer ces applications. Pour prendre en compte cette diversité, la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture mise en œuvre. Cela demande par conséquent de proposer un modèle identifiant les points communs et les différentes exigences des applications de collecte qui peuvent être réalisées. Ce modèle doit s’appuyer sur les bonnes pratiques de l’ingénierie logiciel pour fournir un cadre logiciel modulaire et configurable, et être utilisé simplement par les différents acteurs voulant mener de nouvelles collectes de données pour leurs permettre d’exprimer leurs exigences. D’autre part, la plate-forme doit être capable de passer à l’échelle, c’est-à-dire d’être capable d’impliquer un grand nombre d’utilisateurs mobiles ainsi qu’un grand nombre d’acteurs voulant définir de nouvelles collectes d’un grand volume de données. 1.4 contributions En réponse à ces défis, ces travaux ont abouti à la définition, l’implémentation et l’évaluation d’une plate-forme baptisée APISENSE®. La finalité de APISENSE® est de permettre une mise en place rapide de campagnes de collectes de données à travers des terminaux mobiles intelligents. Nous proposons ici une vue d’ensemble de la solution proposée illustrée par la figure 1. APISENSE® distingue deux rôles évoluant dans la plate-forme. Le premier, appelé simplement utilisateur, peut être un acteur voulant définir et déployer de nouvelles campagnes de collecte de données à travers des terminaux mobiles. Les utilisateurs peuvent utiliser un nœud de collecte dédié (DataGathering Node), qui peut être déployé sur une infrastructure publique ou privée selon leur exigence, et se servir des services fournis par celui-ci pour définir de nouvelles tâches de collecte grâce à un langage de script dédié, déployer la tâche à travers un sous-ensemble d’individus ainsi qu’exploiter ou exposer les données collectées (par ex. visualisation, analyse). Le second rôle, appelé participant, est un individu possédant un terminal mobile. Les participants peuvent utiliser une application mobile dédiée pour télécharger les tâches de collecte, les exécuter dans un environnement sécurisé et automatiquement propager les données collectées. Dans APISENSE®, la mise en relation entre les nœuds de collecte et les participants est assurée par le serveur central (Central Server). Dans un sens, le serveur central peut être perçu comme un magasin dédié aux tâches de collecte. Typiquement, son rôle est 13d’assurer le déploiement des tâches de collecte soumises par les nœuds de collecte, et également d’assurer une première couche d’anonymat des participants. Les objectifs présentés dans la section précédente sont adressés avec APISENSE® de la manière suivante : • À l’issue d’une étude approfondie des architectures présentées dans la littérature (cf. chapitre 2 section 2.3), nous avons proposé un modèle permettant de représenter la variabilité des systèmes responsables du développement et du déploiement de campagnes de collectes de données (cf. chapitre 3 section 4.4). Ce modèle est ensuite fourni aux utilisateurs leur permettant de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. Une application serveur dédiée (c.-à-d. DataGathering Node dans la figure 1) est ensuite générée suite aux exigences définies, fournissant un ensemble de services permettant de développer et de déployer de nouvelles campagnes de collecte, d’assurer la persistance des données collectées par les dispositifs mobiles ainsi que de connecter des services additionnels pour extraire ou traiter ces données. • Nous avons défini un modèle de programmation de haut niveau permettant de s’affranchir de toute la complexité liée aux développements mobiles. Basée sur un langage de script, cette abstraction a été conçue pour être assez générale pour supporter une grande variété d’applications de collecte, facilement accessible pour des utilisateurs ayant très peu d’expertise en programmation mobile, et facilement portable pour être exécutée dans différents environnements mobiles (par ex. Android, iOS, Window Mobile)(cf. chapitre 3 section 3.3). • Pour assurer l’exécution des campagnes de collecte définies par notre modèle de programmation, nous proposons un environnement d’exécution dédié aux utilisateurs mobiles. Cet environnement est responsable du téléchargement, de l’exécution des applications de collectes et de la propagation des données collectées (cf. chapitre 3 section 3.4). Principalement, cet environnement met l’accent sur la consommation énergétique liée à l’exécution d’une campagne de collecte et la protection de la vie privée des utilisateurs. • Nous proposons des modèles et des algorithmes dédiés à l’optimisation de l’exécution de campagnes de collecte. L’optimisation proposée réside en deux points. Pour le premier, nous proposons un modèle de déploiement de tâches de collecte contextuel, permettant d’attribuer une application de collecte à un individu en fonction de propriétés temporelles, géographiques et de capacité 14de détection. Pour le second, nous proposons un algorithme permettant de coordonner l’exécution des tâches de collecte, entre les dispositifs répondant aux mêmes propriétés, afin d’équilibrer les coûts énergétiques entre les terminaux et de diminuer la redondance des données collectées(cf. chapitre 4 section 4.5). Figure 1 – Vue d’ensemble de APISENSE® 1.5 plan du manuscrit Ce manuscrit est divisé en quatre parties. La première partie donne une vue d’ensemble de l’état de l’art dans le domaine du Mobile crowdsensing. La seconde partie décrit les contributions de ce manuscrit. La troisième porte sur la validation des contributions proposées. Et finalement la quatrième conclut ce manuscrit et décrit les perspectives issues des travaux de cette thèse. Plus particulièrement, la suite de ce document est organisé comme suit. Partie 1 : État de l’art Chapitre 1 : Systèmes de collecte de données Ce chapitre a pour objectif de donner dans un premier un temps une vison plus approfondie du Mobile crowdsensing ainsi que ses problématiques. Nous décrivons par la suite des travaux proches à ceux proposés dans cette thèse et nous identifions leurs limitations. 15Partie 2 : Contributions Chapitre 3 : Collecte mobile de données Ce chapitre traite de l’environnement mobile de APISENSE®. Il décrit tout d’abord le modèle de programmation proposé permettant de minimiser le coût du développement des applications de collecte de données. Par la suite, il présente l’architecture de l’environnement mobile dédié à l’exécution des applications de collecte. Chapitre 4 : Collecte répartie de données Ce chapitre présente l’architecture et les choix d’implémentation de l’environnement serveur APISENSE® permettant de déployer des applications de collecte ainsi que d’exploiter les données collectées. Partie 3 : Validations Chapitre 5 : Pratiques culturelles et usages de l’informatique connectée Ce chapitre présente une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein d’une étude sociologique nommée PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Chapitre 6 : Performance et efficacité de APISENSE® présente une validation quantitative sur les performances de APISENSE® Partie 4 : Conclusion Chapitre 7 : Conclusion Finalement, ce chapitre conclut ce manuscrit et expose les perspectives des travaux présentés. 1.6 publications Les travaux de cette thèse ont été réalisés au sein de l’équipe SPIRALS commune à Inria et à l’Université Lille 1 au sein de l’UMR LIFL (Laboratoire d’Informatique Fondamentale de Lille). Ils ont donné lieu aux publications scientifiques suivantes. Conférence International • Dynamic Deployment of Sensing Experiments in the Wild Using Smartphones. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. In 13th International IFIP 16Conference on Distributed Applications and Interoperable Systems (DAIS), pages 43-56. • A Federated Multi-Cloud PaaS Infrastructure. Fawaz Paraiso, Nicolas Haderer, Philippe Merle, Romain Rouvoy, Lionel Seinturier. In 5th IEEE International Conference on Cloud Computing (2012), pages 392-399. Chapitre de livre • A Cloud-based Infrastructure for Crowdsourcing Data from Mobile Devices. Nicolas Haderer, Fawaz Paraiso, Christophe Ribeiro, Philippe Merle, Romain Rouvoy, Lionel Seinturier Wenjun Wu. Cloud-based Software Crowdsourcing, Springer, 2014 (To appear) Workshop • A preliminary investigation of user incentives to leverage crowdsensing activities. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. 2nd International IEEE PerCom Workshop on Hot Topics in Pervasive Computing (PerHot) (2013), pp. 199-204. • Towards Multi-Cloud Configurations Using Feature Models and Ontologies. Clément Quinton, Nicolas Haderer, Romain Rouvoy and Laurence Duchien. In Proceedings of the 1st International Workshop on Multi-Cloud Applications and Federated Clouds, Multi-Cloud’13. Prague, Czech Republic, 22 April 2013, pp. 21-26. Vulgarisation scientifique • APISENSE : Crowd-Sensing Made Easy. Nicolas Haderer, Romain Rouvoy, Christophe Ribeiro, Lionel Seinturier. ERCIM News, ERCIM, 2013, Special theme : Mobile Computing, 93, pp. 28-29. • Le capteur, c’est vous ! Nicolas Haderer, Christophe Ribeiro, Romain Rouvoy, Simon Charneau, Vassili Rivron, Alan Ouakrat, Sonia Ben Mokhtar, Lionel Seinturier L’Usine Nouvelle, L’Usine Nouvelle, 2013, 3353, pp. 74-75 • Campagne de collecte de données et vie privée. Nicolas Haderer, Miguel Nuñez Del Prado Cortez, Romain Rouvoy, Marc-Olivier Killijian and Matthieu Roy. 3ème Journées du GDR CNRS GPL (2012), pp. 253-254. Rapport de recherche • AntDroid : A distributed platform for mobile sensing. Nicolas Haderer, Romain Rouvoy, Lionel Seinturier. [Research Report], 2012, pp. 27. RR-7885 17Première partie État de l’art 192 S Y S T ÈM E S D E C O L L E C T E D E D O N N É E S Sommaire 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 2.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 212.1 mobile crowdsensing 2.1.1 Qu’est ce que le Mobile crowdsensing ? En 2010, Ganti et al. définissent le Mobile crowdsensing comme la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents qui, collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun". Typiquement, le MCS offre de nombreux avantages par rapport aux méthodes classiques de collecte de données telles que les réseaux de capteurs (WSNs), qui peuvent impliquer des coûts importants liés à l’installation d’un grand nombre de capteurs statiques et de leurs maintenances. En effet, des millions de dispositifs mobiles sont déjà déployés dans la nature, portés par des utilisateurs dans leur vie quotidienne. Avec la généralisation des magasins d’applications (par ex. App Store, Google Play), il est désormais possible pour des petites organisations comme des équipes de recherche ou des petites entreprises de rapidement délivrer une application mobile auprès de cette masse d’utilisateurs. Par exemple, au lieu d’installer un ensemble de caméras le long des routes, il est possible de collecter des données du trafic routier et de détecter les embouteillages en utilisant le GPS des dispositifs mobiles des conducteurs. Un autre avantage de l’utilisation de ces dispositifs est le nombre de capteurs multimodaux inclus dans ces appareils, permettant une collecte d’information contextuelle de haut niveau. En effet, le GPS peut fournir la position d’un utilisateur. Le microphone, quand il n’est pas utilisé pour les communications téléphoniques, peut être utilisé comme capteur acoustique. L’accéléromètre peut être, quant à lui, utilisé pour identifier les modes de transport des utilisateurs, leur activité journalière (par ex. temps passé en position assise, à dormir, à marcher, à courir) mais aussi détecter des dégâts importants sur une route. De nouveaux capteurs peuvent également facilement être ajoutés à ceux initialement préinstallés, en utilisant des connexions sans fils comme le Bluetooth pour communiquer entre eux. Quelques exemples sont les bracelets connectés qui peuvent mesurer la fréquence cardiaque 1 d’un individu, ou les capteurs qui mesure la qualité de l’air [19]. Pour finir, le dernier avantage est de pouvoir inclure les utilisateurs dans le processus de collecte, bénéficiant ainsi de l’intelligence humaine pour collecter des données sémantiquement complexes à identifier à partir de simples capteurs. Par exemple, un utilisateur peut facilement identifier la dégradation d’installations 1. http://pulseon.fi/ 22publiques, prendre une photo de ces dégâts et l’envoyer à la collectivité territoriale concernée [35]. Grâce à ces avantages, le MCS a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement et la santé [39, 11]. Cependant, l’utilisation des dispositifs mobiles possédés par des individus introduit également de nouvelles problématiques, comme la préservation de la vie privée des utilisateurs, la grande consommation énergétique des applications de collecte ou alors comment inciter les utilisateurs à installer et exécuter ces applications. Dans la suite de cette section, nous présentons tout d’abord une vue d’ensemble de ces applications avant de décrire avec plus de précision ces problématiques. 2.1.2 Classification des applications Dans la littérature, il existe un grand nombre d’applications de collecte de données, mettant en évidence l’utilisation du MCS dans une grande variété de domaines. Globalement, ces applications peuvent être classées selon deux critères : le sujet à observer et le mode d’acquisition des données. Le classement selon le sujet à observer se scinde, lui encore, en deux dimensions : les applications de collecte personnelle et les applications de collecte communautaire. Les applications de collecte personnelle visent à observer et analyser le comportement d’un individu (e.g., activité physique, mode de transport), tandis que les applications de collecte communautaire visent à observer des phénomènes (à plus grande échelle) sur l’environnement (par ex. qualité réseaux, pollution atmosphérique ou sonore) ou sur une infrastructure publique (e.g., trafic routier, place de parking disponible, dégâts de matériel public). Le classement selon le mode d’acquisition de données peut également se scinder en deux modalités appelées : collecte participative et collecte opportuniste. Dans la collecte participative, l’utilisateur est directement impliqué dans la prise de décision de la collecte (i.e., en décidant quand, comment et quelles données doivent être collectées). Au contraire, dans la collecte opportuniste, elle est complètement automatisée par l’application, sans nécessiter une intervention de l’utilisateur. 23Collecte personnelle ou communautaire Dans les systèmes de collecte personnelle, l’ objectif est d’observer des phénomènes liés à un individu. Dans ce type de système, toutes les données collectées sont géné- ralement couplées avec un identifiant unique, permettant de suivre l’évolution d’un utilisateur spécifique à travers le temps. Elles sont généralement rendues à l’utilisateur sous forme d’un rapport détaillé sur son activité, partagées à travers un réseau social ou alors agrégées à travers plusieurs utilisateurs afin d’identifier divers comportements. Ce type de collecte est généralement utilisé dans les domaines de la santé, du sport ou de l’environnement. Dans le domaine de l’environnement par exemple, PEIR [51](Personal Environmental Impact Report) est un système permettant aux utilisateurs de se servir de leurs dispositifs mobiles afin de déterminer leur exposition aux polluants présents dans leur environnement. PEIR collecte continuellement les données GPS vers un serveur pour y effectuer une série de traitement consistant à segmenter les différents déplacements des utilisateurs, identifier les modes de transports (par ex. bus, voiture) et calculer la quantité de gaz carbonique émise lors des déplacements. Pour le calcul de l’émission du gaz carbonique, PEIR couple les informations des déplacements avec plusieurs bases de données : celles des principales entreprises polluantes, et celles de la météo et du trafic routier. Sur un site Internet spécifique, les utilisateurs peuvent ensuite consulter les rapports de leurs déplacements, les aidants à modifier leurs comportements et protéger leur santé. Dans le domaine du sport, BikeNet [20] fournit aux cyclistes une application leur permettant de mesurer leurs expériences sportives. BikeNet combine les données du GPS et de l’accéléromètre pour calculer la vitesse, les calories perdues ainsi que la qualité des routes empruntées. Les données collectées peuvent être visualisées par les cyclistes eux-mêmes, ou être agrégées avec d’autres utilisateurs afin de construire une carte complète des pistes cyclables. Les systèmes de collecte personnelle sont également beaucoup utilisés dans le cadre d’expériences scientifiques. Par exemple, EmotionSense [56] est un système dédié aux études de psychologie sociale. Il tente d’établir une relation entre le bien-être d’un utilisateur et ses interactions sociales ou ses activités. Pour identifier ces informations, EmotionSense analyse continuellement trois types d’informations. Premièrement, les conversations téléphoniques des utilisateurs pour mesurer leurs émotions durant leurs appels. Deuxièmement, les périphériques Bluetooth voisins pour identifier les 24personnes se trouvant régulièrement à proximité. Et finalement l’accéléromètre pour identifier l’activité régulière de l’utilisateur. Dans un autre contexte, HealthAware [28] est une application visant à observer l’obésité des utilisateurs. Avec cette application, les utilisateurs peuvent prendre en photo leur nourriture, ce qui permet au système de leur fournir en retour des informations sanitaires complémentaires sur cette nourriture. HealthAware collecte également les données de l’accéléromètre pour mesurer l’activité physique quotidienne des utilisateurs. Le système fournit en retour un rapport complet sur l’activité effectuée, et rappelle aux utilisateurs l’importance de garder une activité physique quotidienne pour être en bonne santé. Les systèmes de collecte communautaire visent, quant à eux, à observer des phénomènes à plus grande échelle, sur l’environnement ou sur des infrastructures publiques afin d’améliorer la vie d’une communauté (par ex. toutes les personnes habitant dans une ville, les étudiants d’une université). Quelques scénarios types de ce genre de collecte comprennent la mesure de la pollution atmosphérique en milieu urbain, ou l’observation des réseaux routiers afin de détecter les embouteillages ou des dégâts importants sur la chaussée. CommonSense [19] est un exemple d’application dédié à l’observation de la pollution atmosphérique. L’application mobile de CommonSense combine les données GPS avec des données fournies par un capteur externe mesurant la qualité de l’air ambiant. La communication entre le mobile et le capteur externe est assurée par une connexion Bluetooth. Les capteurs externes ainsi que l’application sont déployés auprès de la population, qui collectivement propage leurs positions ainsi que la qualité de l’air vers un serveur. Les données sont ensuite agrégées et peuvent être visualisées sur un site Internet spécifique. Similairement, NoiseTube [47] utilise directement les microphones des dispositifs mobiles pour mesurer la pollution sonore en milieu urbain. Un autre type de collecte communautaire implique la mesure de phénomènes en relation avec des infrastructures publiques. Par exemple, Nericell [50] est un projet qui a pour objectif de mesurer différents phénomènes issus du trafic routier. Ce projet analyse continuellement la position d’un utilisateur qui, couplée avec les informations issues de l’accéléromètre, permet de détecter la dégradation d’une route ou des freinages d’urgences et, couplée avec le microphone, permet de détecter un fort trafic à partir du bruit ambiant. Dans un autre contexte, LiveCompare [17] est une application qui permet de comparer différents prix d’un même article se trouvant dans des magasins situés à proximité 25d’un utilisateur. Avec cette application, les utilisateurs peuvent se servir de leur dispositif pour prendre en photo le code-barres d’un article. Le code est ensuite décrypté, et envoyé vers un serveur avec la position de l’utilisateur et la photo. En échange, LiveCompare fournit aux utilisateurs les différents prix disponibles pour ce même produit, en fonction des magasins se trouvant à proximité. Un autre exemple d’application est CreekWatcher 2 . Cette application surveille les niveaux et la pollution des eaux, à l’aide des rapports des utilisateurs, comme des photos prises à divers endroits au bord des étendues d’eau, ou des messages texte sur le quantité de déchets. Ces informations peuvent ensuite être exploitées par des commissions de contrôle des eaux. Collecte participative ou opportuniste Indépendant du sujet à observer, un facteur déterminant du succès d’une application est le niveau d’implication des utilisateurs dans le processus de collecte [38]. Typiquement, le processus de collecte peut prendre deux formes appelées collecte opportuniste [39] et participative [7]. Dans celle dite opportuniste, la collecte de données est complètement automatisée par l’application mobile (par ex. "collecter la position toutes les cinq minutes"). Cette approche a le principal avantage de minimiser l’intervention humaine dans le processus de collecte. Cela est particulièrement utile dans le cadre d’une collecte communautaire, permettant d’assurer la propagation de données régulièrement sur le serveur (sans que l’utilisateur soit contraint à accomplir des tâches quotidiennes sur son dispositif). Cependant, ces applications sont plus difficiles à développer, et consomment également beaucoup de ressources énergétiques. En effet, la difficulté principale pour développer ce type d’application est de déterminer dans quel contexte se trouve le dispositif mobile, afin d’assurer une certaine qualité des données collectées. Par exemple dans l’application NoiseTube [47], qui a pour objectif d’observer la pollution sonore, il est nécessaire de mesurer le niveau sonore uniquement quand le dispositif est hors de la poche ou du sac de l’utilisateur. Dans ce cas, cette issue peut être résolue en utilisant le capteur de lumière, mais par conséquent, nécessite la consommation de ressources plus conséquentes. 2. http://www.ibm.com/smarterplanet/us/en/water_management/article/creek_ watch.html 26Au contraire, la collecte dite participative nécessite une plus grande implication de la part des utilisateurs. Par exemple, dans l’application LiveCompare [17], les utilisateurs doivent manuellement prendre une photo du produit qu’ils veulent comparer. Le principal avantage de cette approche est qu’elle permet de bénéficier de l’intelligence humaine pour réaliser des opérations plus complexes. Si nous reprenons l’exemple de application NoiseTube [47], l’approche participative peut permettre de résoudre facilement le problème du contexte du dispositif, en demandant aux utilisateurs de prendre une mesure du niveau sonore manuellement lorsque leur dispositif est hors de leur poche. Cependant, l’inconvénient de cette approche est que la qualité des données, ainsi que la fréquence à laquelle elles sont collectées, dépend fortement de l’enthousiasme des utilisateurs pour l’application. 2.1.3 Discussion Dans cette section, nous avons présenté une vue d’ensemble du MCS, ses principales caractéristiques ainsi que les domaines d’applications utilisant le MCS comme source d’approvisionnement de données. Cependant, jusqu’à ce jour, les applications développées ont principalement été élaborées dans un contexte applicatif spécifique, et difficilement réutilisable. En effet, ces applications ont été conçues complètement indé- pendamment des unes des autres, ne partageant aucun module logiciel commun, alors qu’elles ont à faire face à des problématiques communes. Ce manque de solutions réutilisables, largement pointé du doigt dans la littérature ces dernières années [39, 27, 60, 66], rend non seulement le développement d’une application spécifique difficile, mais il y a aussi la problématique du recrutement des participants qui doit être repris de zéro pour chaque application. Avec la popularité croissante du MCS dans de nombreuses communautés scienti- fiques, fournir une plate-forme générique permettant un rapide développement et un déploiement d’une large variété de campagnes de collecte de données devient une nécessité [27]. C’est donc dans cette lignée que s’inscrivent les travaux de cette thèse. Cependant, réaliser une telle plate-forme comporte de nombreux défis, que nous présentons dans la section suivante. 272.2 les challenges clés du mobile crowdsensing Dans cette section, nous identifions les principaux défis à relever afin proposer une plateforme générique dédiée aux développements et aux déploiements de campagne de collecte de données. Principalement, nous identifions cinq défis : Sécurité et vie privée, Gestion des ressources, Hétérogénéité des équipements et des OS, Diffusion et passage à l’échelle de applications, Implication et incitation des usagers. Pour chacun des défis, nous décrivons brièvement la problématique ainsi que les différentes solutions envisagées dans l’état de l’art. 2.2.1 Sécurité et Vie privée Respecter la vie privée des utilisateurs est peut-être la responsabilité la plus fondamentale d’une plate-forme de collecte. Les utilisateurs sont naturellement sensibles aux données collectées sur leurs dispositifs, spécialement si ces informations comprennent leurs localisations, des images sensibles ou alors des communications audios. En effet, de nombreux travaux [36] ont montré que de nombreuses données, même si elles peuvent paraître anodines prises individuellement, peuvent révéler de nombreuses informations sensibles sur les habitudes ou les relations sociales d’un individu lorsqu’elles sont agrégées dans la durée. Par exemple, les données de géolocalisation collectées avec le GPS, couplées avec des données temporelles peuvent être utilisées pour inférer les trajets quotidiens empruntés par un utilisateur, ou encore ses principaux lieux de vies tels que son domicile ou son lieu de travail [26]. Afin de protéger la vie privée des utilisateurs, de nombreuses solutions ont été envisagées dans la littérature. Christin et al. [11] donne une bonne vue d’ensemble des techniques utilisées selon le contexte de la collecte, qu’elle soit personnelle ou communautaire. Typiquement, ces techniques peuvent consister à utiliser un alias pour assurer les communications entre le serveur et le dispositif mobile, à perturber volontairement les données collectées avant de les propager vers le serveur (en modifiant par exemple les coordonnées GPS), à agréger les données entre n utilisateurs partageant des propriétés communes (par ex. n participant situés dans le même quartier), ou alors à échanger alternativement les traces de mobilités entre plusieurs utilisateurs. 28Cependant, bien que ces approches permettent d’assurer une certaine confidentialité des utilisateurs, elles impliquent également une dégradation des données qui sont collectées. Dans ce cas, il est nécessaire de faire un compromis entre qualité et confidentialité. Ce compromis peut être fait en effectuant un maximum de traitement directement dans le dispositif mobile. Par exemple, Nericell [50] adopte cette approche en analysant toutes les données issues de l’accéléromètre et du microphone localement, et propage uniquement des informations de haut niveau sur le serveur (par ex. fort trafic). Une autre solution envisagée par Christin et al. [11] est de laisser la possibilité aux utilisateurs de définir leurs exigences en matière de vie privée. En effet, la notion de vie privée peut énormément varier d’un individu à un autre. Par exemple, certain utilisateur peuvent être retissant à partager leur position contraire à d’autre. Dans ce contexte, il est nécessaire de fournir aux utilisateurs des moyens leur permettant de spécifier les données qu’ils veulent partager, dans quelles circonstances (par ex. temps, position), et surtout dans quel but. 2.2.2 Gestion des ressources Alors que les smartphones continuent de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces dispositifs restent limitées. En effet, certaines applications déployées [49] montrent que la durée de vie de la batterie d’un dispositif, peut être réduite de 20 heures à 6 heures si certaines ressources sont exploitées activement. Par exemple les ressources du CPU pour traiter un grand volume de données (par ex. traitement de données audio), les ressources de certains capteurs comme le GPS, ou encore des ressources de communications (par ex. 3G, WIFI) pour partager en temps réel les données collectées. Un aspect intéressant pour réduire la consommation énergétique de ces applications est la multimodalité de certains capteurs. En effet, cela peut permettre de faire un compromis entre la qualité des données, en terme de fréquence d’échantillonnage et de précision, et le coût énergétique lié à leurs acquisitions. L’exemple le plus courant est l’acquisition de la position d’un utilisateur, qui peut être obtenue soit par le GPS, impliquant une grande coût énergétique, mais fournissant une grande précision (5- 20 mètres), soit par WiFi ou par la triangularisation GSM, qui sont moins précis 29(20-1000 mètres), mais ont une taxe énergétique moins importante. À partir de ce constat, de nombreux travaux ont été proposés dans la littérature, essayant d’alterner l’utilisation de ces différents capteurs pour faire le plus efficacement ce compromis. Par exemple, EnLoc [14] adapte la fréquence d’échantillonnage et les capteurs haute et basse qualité en fonction de la batterie de l’utilisateur. Matador [8] propose également un algorithme adaptatif, mais pour déterminer si l’utilisateur se trouve dans une zone précise. SenseLoc [34] active le GPS uniquement si l’utilisateur se déplace en utilisant l’accéléromètre pour identifier son activité. Cependant, un inconvénient de ces approches est qu’elles ont été conçues pour un contexte applicatif spécifique, et qu’elles ne sont donc pas forcement adaptées pour un autre. De plus, ces approches restent limitées lorsque de multiples applications coexistent dans un même dispositif. Par exemple, les applications dédiées à l’observation de la pollution sonore et du trafic routier nécessitent toutes les deux des données de géolocalisation. Dans ce contexte, ces applications effectuent leurs propres échantillonnages des données GPS, pouvant entraîner une surconsommation énergétique du dispositif mobile. Cela limite ainsi les utilisateurs à participer à un nombre limité d’applications. 2.2.3 Hétérogénéité des équipements et des OS Un autre aspect à prendre en considération est l’hétérogénéité des systèmes d’exploitation et des équipements disponibles. En effet, selon Gartner Inc. 3 , les ventes de smartphones en 2013 ont totalisé plus de 1,8 milliards d’unité, réparties principalement entre trois systèmes d’exploitation (OS), Android 4 avec 78,4% de part de marché, iOS 5 avec 15,6 % et Windows Phone 6 avec 3,2%. Bien que ce marché en pleine effervescence — soit une augmentation 3.5% depuis 2012 —, confirme le potentiel du Mobile crowdsensing pour la collecte de données à grande échelle, cela induit aussi un long processus de développement pour prendre en considération tous ces systèmes d’exploitation. Pour le développement d’une application sur un OS spécifique, un ensemble d’outils et d’APIs sont fournis aux développeurs. Ces APIs sont implémentées généralement dans des langages de programmation différents, par exemple Java pour Android et 3. Gartner Inc. http://www.gartner.com/newsroom/id/2665715 4. Android : http://www.android.com 5. iOS : http://www.apple.com/fr/ios 6. Windows Phone : http://www.windowsphone.com 30Objective-C ou Apple Swift 7 pour iOS. Ceci implique qu’une application développée pour l’un de ces OS est incompatible avec les autres. Par conséquent, cela demande aux développeurs d’étudier et de développer une application spécifique pour chaque OS disponible, afin de pouvoir impliquer un maximum d’utilisateurs dans le système de collecte. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. Pour faire face à cette hétérogénéité, également identifiée par [60], il est nécessaire de concevoir les applications de collecte dans un langage de haut niveau. Dans ce contexte, le défi consiste à proposer une abstraction assez générale pour supporter le dé- veloppement d’applications variées (opportuniste et participative), qui peut également impliquer une grande variété de capteurs, portables pour supporter la diversité des plate-formes mobiles (c.-à-d. Android, iOS, Windows Mobile), et finalement accessibles pour minimiser l’expertise nécessaire dans les technologies mobiles. 2.2.4 Diffusion et passage à l’échelle des applications La diffusion des applications est un aspect crucial pour assurer le passage à l’échelle d’une plate-forme de collecte. Généralement, la diffusion des applications mobiles est assurée par les magasins traditionnels proposés par les plate-formes mobiles (par ex. Google Play pour Android, Apple Store pour iOS). Cependant, une fois disponible dans un magasin, l’application peut être potentiellement téléchargée par des millions d’utilisateurs à travers le monde. Ces utilisateurs peuvent alors générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. De plus, la période de prolifération des mises à jours de ces applications vers les utilisateurs peut prendre plusieurs heures jusqu’à plusieurs jours selon le magasin utilisé (par ex. quelques heures pour Google Play jusqu’à plusieurs heures pour Apple Store). Dans le cadre du MCS, cette période est beaucoup trop longue, spécialement si l’objectif est de collecter des données lors d’un événement ne durant que quelque jours, comme un festival ou une fête nationale. En effet, lors de ces manifestations, après avoir récolté les premières données, il peut s’avérer nécessaire de 7. https://developer.apple.com/swift 31mettre rapidement à jour l’application afin d’améliorer la qualité de la collecte ou de remédier à des défauts de programmation. Dans ce cadre, il est nécessaire de développer de nouveaux mécanismes pour déployer ces applications de collecte [39]. Ces mécanismes devront prendre en compte plusieurs considérations. La première est de maîtriser le déploiement de ces applications vers les participants les plus à même à collecter les données désirées, en limitant le nombre d’utilisateurs impliqués dans la collecte, ou en ne visant qu’une population particulière (par ex. région géographique, tranche d’âge), tout en assurant leurs confidentialités. La deuxième considération est d’assurer un rapide déploiement de leurs mises à jour pour adresser les exigences évolutives liées aux premières données collectées, ou tout simplement pour corriger des erreurs de programmation. La dernière, aussi envisagée par [27, 60], est de permettre de coordonner l’exécution des campagnes à travers plusieurs dispositifs, notamment dans les campagnes de collecte communautaire. En effet, généralement ces applications collectent périodiquement (toutes les x secondes) des données sans prendre en considération si un autre dispositif placé à proximité exécute la même application. Cela peut ainsi entraîner une forte duplication de données collectées, en particulier en milieu urbain où il peut y avoir une forte densité d’utilisateurs. Dans ce contexte, effectuer une coordination entre ces dispositifs pourrait permettre de diminuer la quantité de données redondantes sur le serveur, et également équilibrer les charges énergétiques entre les dispositifs, réduisant ainsi l’énergie globale consommée lors de l’exécution de la campagne. 2.2.5 Implication et incitation des usagers Inévitablement, sans une participation adéquate des utilisateurs, il peut être très difficile d’obtenir la masse de données critique pour l’application. Cependant, comme nous l’avons mentionné dans les sous-sections précédentes, en utilisant une application de collecte, les utilisateurs consomment de nombreuses ressources de leurs dispositifs, et peuvent potentiellement s’exposer à la divulgation d’informations confidentielles. Dans ce contexte, un utilisateur peut ne pas être intéressé à participer à l’application, à moins de recevoir une récompense adaptée. Dans ce contexte, de nombreux travaux ont porté sur la réalisation d’un modèle économique permettant d’attribuer des récompenses financières aux utilisateurs en fonction de leur participation. Ces modèles peuvent être statiques [57], en attribuant 32un prix fixe aux données partagées par les utilisateurs, ou dynamiques [40] en faisant varié le prix des données en fonction de la couverture des premières données partagée, pour inciter par exemple les utilisateurs à se déplacer dans des zones peu couvertes. Cependant, bien que ces modèles puissent favoriser la participation des utilisateurs et améliorer la qualité des données obtenues, collecter des données à grande échelle peut nécessiter un budget considérable, qui n’est pas forcément accessible par exemple pour des équipes de recherche. Dans ce contexte, de nombreux modèles alternatifs, non monétaires, ont été explorés dans la littérature ces dernières années. Ces sources de motivation peuvent par exemple s’inscrire dans le cadre d’une démarche citoyenne ou scientifique en aidant à diminuer l’émission de gaz carbonique dans la nature par exemple [51]. Ces sources peuvent également prendre la forme d’un jeu, en simulant une compétition entre les utilisateurs, en partageant ses performances sur les réseaux sociaux [49], ou en attribuant des récompenses virtuelles. Une dernière source de motivation est d’obtenir un bénéfice direct en partageant des données, par exemple dans l’application LiveCompare [17], les utilisateurs peuvent bénéficier des prix scannés par les autres utilisateurs. 2.2.6 Discussion Le principal objectif d’une plate-forme générique de collecte de données est de permettre la fédération d’une large communauté d’utilisateurs, avec des niveaux d’expertises et des exigences différentes. En effet, les campagnes de collecte de données peuvent être de différents types, qui peuvent être de type communautaire ou personnel, et peuvent également impliquer différents niveaux de participation de la part des utilisateurs (c.-à-d. collecte opportuniste et participative). Comme nous en avons discuté tout au long de cette section, la mise en place d’une campagne demande de faire de nombreux compromis. Que ce soit sur la qualité des données, leur quantité, la préservation de la vie privée des utilisateurs ou encore la consommation énergétique des applications de collecte. Nous avons également vu que dans la littérature, de nombreux modèles ou algorithmes ont été proposés pour adresser ces points. Cependant, aucun de ces modèles ne représente une solution idéale, et ne peut être appliqué seulement dans un contexte applicatif spécifique (par ex. population visée, type de de données collectées). Dans ce contexte, nous pensons que la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture logicielle d’une plate-forme générique. La flexibilité fait 33référence à la capacité de la plate-forme à s’adapter à la diversité des campagnes de collecte qui peuvent être menées. Cette diversité peut faire référence à différents types de données qui peuvent être collectées (c.-à-d. impliquant de nombreux capteurs), aux technologies utilisées pour les sauvegarder (c.-à-d. base de données), et les structurer (c.-à-d. méthode d’indexation) et les analyser. Quant à l’extensibilité, elle fait référence à la capacité de la plate-forme pour intégrer de nouvelles contributions, afin de faire face aux exigences des utilisateurs non anticipées. Dans ce cadre, la plate-forme pourrait permettre également à des scientifiques travaillant sur une problématique spécifique du MCS (par ex. vie privée, modèle de récompense, etc.), de se focaliser sur leur domaine d’expertise sans avoir à redévelopper un système complet et donc participer à l’amélioration de la plate-forme. Dans la section suivante, nous faisons une étude comparative des différentes plateformes ayant reçu beaucoup d’attention dans la littérature ces dernières années, et ayant ce même objectif. 2.3 travaux connexes Comme nous l’avons vue dans la section précédente, le développement d’application de collecte de données demande de faire face à de nombreux défis. Dans cette section, nous décrivons un certain nombre de travaux existants, proposant des plate-formes ayant pour objectif de simplifier leurs développements et leurs déploiements. Pour chaque travail présenté, nous décrivons brièvement l’architecture générale adoptée, et nous les confrontons par rapport aux défis définis dans la section précédente. 2.3.1 Funf Open Sensing Framework Funf [1] est une plate-forme open source dédié aux développements d’applications de collecte de données mobiles basées sur le système d’exploitation Android. Initialement, Funf a été développé par le MIT Media Lab, afin de proposer aux scientifiques un outil plus générique pour les aider à facilement concevoir leurs applications de collecte. Le concept de base proposé par Funf est appelé Probe. Typiquement, un Probe est un module logiciel (c.-à-d. portion de code Android) assurant la capture de données d’un capteur physique ou logique (par ex. GPS, température, contact). Pour le développement 34des applications, Funf met à disposition un service appelé FunfInABox, accessible via une interface web. L’interface propose un formulaire qui permet aux scientifiques de sélectionner et configurer un ensemble de Probe à inclure dans l’application mobile (cf. figure 2). Le formulaire validé, FunfInABox procède alors à la génération de l’application et de la mettre à disposition des scientifiques à travers un compte Dropbox, un service de stockage et de partage de fichier en ligne. L’application peut également être configurée pour propager périodiquement les données collectées vers le même compte Dropbox, ou sur un serveur HTTP. Pour des raisons de sécurité, toutes les données collectées sont encryptées, et toutes les données sensibles telles que les contacts ou les SMS sont automatiquement hachés. Funf fournit également un ensemble de scripts qui peuvent être utilisés par les scientifiques pour décrypter les données, les insérer dans une base de données relationnelle et visualiser les données. Figure 2 – Développement d’une application mobile avec FunfInABox Funf se diffère principalement par sa simplicité. En effet, l’utilisation d’un formulaire web permet de rapidement développer une nouvelle application sans nécessiter toutes sortes d’expertise en programmation. Cependant, les applications qui peuvent être développées restent très basiques, limitées à la collecte périodique de données brutes de capteurs, et ne supportent pas les interactions avec les utilisateurs. De plus, les applications générées ne proposent pas aux utilisateurs de mécanismes leur permettant de contrôler les données qui sont collectées sur leurs dispositifs ni de retour sur celles-ci. D’autres parts, Funf ne fournissent pas de service spécifique pour aider les utilisateurs à déployer leurs applications vers les dispositifs mobiles. Ils sont alors contraints d’utiliser les magasins d’applications, devant faire face aux problématiques discutées précédemment(cf. section 2.2.4). 352.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones Jon Froehlich et al. [25] proposent une approche plus flexible pour développer des applications de collecte avec MyExperience. 1 2 3 4 6 7 8 9 14 15 16 17 18 00:30 19 CallQuality 20 21 22 23 25 cellnetwork.png 26 27 Bad 28 Poor 29 Fair 30 Good 31 Excellent 32 33 34 Listing 2.1 – MyExperience : Exemple de configuration de collecte de données MyExperience facilite la définition d’une expérience collecte en proposant une abstraction appelée Sensors Triggers et Actions au-dessus du langage descriptif XML. Dans cette abstraction, les triggers combinent les flux des données fournis par les sensors et une expression logique pour déterminer quand une action doit être déclenchée. 36Pour capturer l’expérience d’un utilisateur, cette abstraction supporte la définition de questionnaires, qui peuvent être présentés à l’utilisateur périodiquement, ou après un évènement spécifique. Le listing 2.1 montre par exemple une expérience affichant à un utilisateur un questionnaire lui demandant la qualité de sa communication vocale après un appel téléphonique. Cependant, l’abstraction proposée a plusieurs limitations. La première est que les triggers qui exécutent les actions ne peuvent pas exécuter une seconde action en fonction du résultat de la première. Cela empêche par exemple de déclencher un nouveau questionnaire en fonction des premières réponses fournies. La deuxième concerne l’expressivité de l’abstraction qui reste limitée aux balises XML définies au préalable. Cette limitation par exemple empêche le développement d’algorithmes contextuels complexes (par ex. inférence de l’activité d’un utilisateur) complexe. Et finalement, MyExperience reste limité aux collectes participatives. L’architecture de la plate-forme MyExperience est composée de deux parties spéci- fiques : i) une application mobile Windows Mobile, responsable de de l’exécution des fichiers XML et ii) une application serveur, responsable de la persistance des données collectées. L’application mobile supporte également la propagation automatique des données vers le serveur. La propagation des données est effectuée lorsqu’une connexion réseau est détectée, et utilise le protocole HTTPS pour sécuriser le transfert des données. L’application fournit également une option permettant d’utiliser un algorithme de cryptographie SHA-1 pour hacher les données confidentielles des utilisateurs (par ex. SMS, contacts, numéro de téléphone). Cependant, MyExperience ne fournit pas de mécanisme particulier pour aider les scientifiques à déployer leurs expériences. L’application mobile ne supportant l’exécution que d’une seule expérience, cela empêche par exemple aux scientifiques de bénéficier des applications déjà installées chez les utilisateurs pour déployer leurs propres expériences.Néanmoins, MyExperience fournit plusieurs mécanismes permettant la mis à jours des expériences à distance, en envoyant la nouvelle expérience par SMS ou un message électronique aux utilisateurs concernés. Cependant, cela nécessite que les scientifiques aient connaissance du numéro de télé- phone ou de l’adresse électronique des utilisateurs, ce qui met en péril l’anonymat des utilisateurs. 372.3.3 Medusa : A programming framework for crowd-sensing applications Medusa, présenté par Ra et al. [55], est une plate-forme de programmation et de distribution de tâches de collecte participatives. Medusa s’adresse principalement aux utilisateurs finaux, sans expertise en programmation. Un exemple typique d’application présentée est celui du citoyen journaliste, permettant au journaliste de recruter des citoyens mobiles pour récolter des vidéos et des commentaires d’un évènement spécifique (par ex. accident, feu de forêt). Dans Medusa, la spécification d’une nouvelle tâche consiste à définir une séquence d’actions qui doivent être exécutées par les mobiles. Pour spécifier cette séquence d’actions, Medusa propose MedScript, une abstraction de haut niveau basé sur XML. MedScript propose deux niveaux d’abstractions : les stages et les connecteurs. Les stages permettent de définir une action élémentaire qui doit exécutée par le dispositif. MedScript distingue deux type de stages : i) les stages consistant à extraire des données des capteurs (par ex. GPS, accéléromètre) appelés SPC-Stage, et les stages nécessitant une intervention humaine (par ex. prendre une vidéo, documenté une photo) appelés Hit-Stage. Chaque stage inclut également plusieurs paramètres, comme une date d’expiration, un contexte d’exécution (par ex. région spécifique ou période de la journée) et également inclure une récompense financière pour inciter les utilisateurs à exécuter les stages. Par exemple, le listing 2.2 décrit l’application du citoyen journaliste. Cette application comporte quatre stages et deux connecteurs définissant l’enchaînement suivant : Recruit -> TakePicture -> GetSummary -> UploadData . Le premier stage permet de recruter les utilisateurs, le deuxième demande aux utilisateurs de prendre une photo dans une région spécifique, le troisième demande aux utilisateurs de commenter la photo prise et finalement le dernier permet d’envoyer le commentaire et la photo vers le serveur. 1 2 Citizen-Journalst 3 4 Recruit HIT 5 recruit 6 7 Citizen Journalist Demonstration 8 18:00:00 12/16/2011 9 .05 10

W_WID

3811 12 13 14 GetSummary SPC 15 medusalet_videosummary 16 immediate none 17 18 IMAGE 19

SUMMARY

20 21 22 23 TakePicture SPC 24 medusalet_mediagen 25 location=34.020259|-118.290131|40, user-initiated 26 27 -t image 28

IMAGE

29 30 31 32 UploadData SPC 33 medusalet_uploaddata 34 none textdesc 35 36 SUMMARY 37 38 39 40 41 Recruit 42 TakePicture Hiring 43 44 45 TakePicture 46 GetSummary Hiring 47 48 49 GetSummary 50 UploadData Hiring 51 52 Listing 2.2 – Le journaliste citoyen développé en MedScript language Pour le déploiement des tâches de collecte, l’architecture de Medusa (cf. figure 3) est composé d’un ensemble de service exécuté sur une infrastructure serveur, et une 39application mobile distribuée auprès d’un ensemble d’utilisateurs. Nous décrivons brièvement le rôle de ces composants. Le Interpreter est le point d’entré de Medusa, il accepte les tâches décrites en MedScript, vérifie leur validité et les envoies aux Task Tracker. Le Task Tracker est responsable de coordonner l’exécution des tâches vers les dispositifs mobiles. Pour chaque tâche, le Task Tracker lui associe une instance dédiée responsable du suivie des différents stages associés à la tâche. Dans ce cas, si la tâche doit être exécuté par 50 utilisateurs (c.-à-d. collecter 50 images dans l’exemple présenté), 50 instances seront alors instanciées dans le Task Tracker. Pour chaque stage inclus dans la tâche, l’instance associé à la tâche notifie l’application mobile assignée lui demandant d’exécuter le stage. Une fois le stage complété, l’application mobile alerte le Task Tracker et attend une instruction pour exécuter le stage suivant. Une fois tous les stages terminés, le Task Tracker averti l’initiateur de la tâche et rend les données disponibles dans le Data Repository. Le Worker Manager sert principalement d’interface avec le service Amazon Mechanical Turk (AMT) 8 , qui est utilisé pour la phase de recrutement. Lorsque le Task Tracker instancie une nouvelle tâche, une description de la tâche ainsi que sa rémunération est postée sur le service AMT. Les participants peuvent alors se connecter sur le service AMT avec leur application mobile, et s’inscrire auprès de la tâche qu’il les intéresse. Une fois inscrit, le Worker Manager notifie le Task Tracker, qui peut alors procéder à l’exécution des stages. AMT est également utilisé pour assurer les communications (c.-à-d. par SMS) entre le Task Tracker et les applications mobiles, et la rémunération des utilisateurs. Cette approche permet d’assurer l’anonymat des utilisateurs, dans le sens où Medusa n’a pas besoin de connaître l’identité réelle des utilisateurs pour communiquer avec eux et les récompenser. Le Stage Library représente la partie extensible de Medusa. Chaque stage supporté par MedScript est associé à un exécutable Android stocké dans le Stage Library. Les exécutables sont alors téléchargés par les dispositifs mobiles avant d’exécuter le stage associé. Cette approche permet d’étendre les capacités offertes par MedScript sans avoir à recompiler l’application mobile et la redéployer. L’ Application mobile est composée de deux services appelés StageTracker et MedBox. Le Stage Tracker est responsable des communications entre l’ap- 8. Amazon mechanical turk : https://www.mturk.com 40plication mobile et les services du serveur. Ces communications comprennent le téléchargement des exécutables des différents stages, d’analyser les SMS envoyés par AMT et propager les données vers le serveur. La MedBox est responsable de l’exécution des stages dans le dispositif mobile. Un stage peut être exécuté soit directement après une notification du Stage Tracker, soit en fonction du contexte de l’utilisateur (c.-à-d. zone géographique ou période de la journée). L’application mobile fournit également plusieurs mécanismes pour contrôler les ressources consommées par l’application mobile et assurer la confidentialité des participants. Pour la gestion des ressources, Medusa laisse la possibilité aux participants de définir des limites en terme de CPU, réseau ou mémoire utilisées lors de l’exécution des stages. Pour assurer la confidentialité, l’application mobile demande une confirmation aux utilisateurs avant de propager les données sur le serveur. Cela permet aux utilisateurs de vérifier si les données collectées peuvent être compromettantes vis-à-vis de leurs vies privées. Figure 3 – Architecture de Medusa [55] Medusa propose certains aspects intéressants à l’égard des considérations discutées dans la section précédente. Ces aspects sont l’intégration d’un service tiers comme AMT, pour assurer l’anonymat des utilisateurs, la possibilité d’intégrer des récom- 41penses financières, ou encore proposer une application mobile générique favorisant la participation des utilisateurs à plusieurs tâches de collecte. Cependant Medusa a plusieurs limitations. La première réside lors de la phase de recrutement des utilisateurs. En effet, si nous reprenons l’exemple du citoyen journaliste, il faudrait que, idéalement, seul les utilisateurs se situant à proximité de l’événement couvert par le journaliste, puissent être capables de s’inscrire à la tâche. Or, bien que Medusa supporte la notion de contexte d’exécution (par ex. exécuter un stage dans une zone géographique), celle-ci est interprétée uniquement par l’application mobile après la phase d’enregistrement. Ainsi, de nombreux utilisateurs peuvent s’enregistrer sans qu’ils ne soient à proximité de l’événement visé. Une autre limitation réside dans l’abstraction du modèle de programmation proposé, qui reste limité à la définition de tâche participatives et communautaires. Par exemple, cette abstraction ne permet pas de définir des tâches suivant l’évolution d’un utilisateur à travers une longue période (par ex. "collecter toutes les 5 minutes la position du GPS"). Et finalement, la dernière limitation réside dans les mécanismes d’extension de Medusa. En effet, pour étendre les fonctionnalités offertes par MedScript, les développeurs ont besoin de développer un nouveau module Java compatible Android. Ce mécanisme a deux inconvénients. Le premier concerne la sécurité. En effet, un développeur mal intentionné peut développer un stage envoyant des SMS à l’insu des participants, ou récupérer des données confidentielles (par ex. contacts) et les envoyer vers un service tiers. Et le deuxième rend exclusive Medusa uniquement pour Android, empêchant de faire face à l’hétérogénie des OS mobiles. 2.3.4 PRISM : Platform for Remote Sensing using Smartphones PRISM [16] est une plate-forme adressant particulièrement trois points qui sont la généralité, la sécurité et le passage à l’échelle. Pour adresser la généralité, PRISM propose une application mobile permettant le téléchargement de tâches de collecte écrites en code natif. Cette approche permet de faciliter la réutilisation de code et de donner une totale flexibilité pour le développement de tâches complexes et variés. Dans ce cadre, PRISM supporte le développement de tâche participatives et opportunistes. Néanmoins, cette approche a plusieurs limitations. Premièrement, le développement de code natif demande une grande expertise en programmation et dans les plate-formes mobiles. PRISM ne fournit pas d’API de 42plus haut pour simplifier leurs développements. Deuxièmement, le développement de code natif ne permet pas de faire face à l’hétérogénéité des OS mobiles. Le code développé reste alors exclusivement exécutable par OS mobile supporté par PRISM, en l’occurrence Windows Mobile. Et finalement, permettre à des développeurs tiers de déployer du code natif sur les dispositifs mobiles peut également poser des problèmes de sécurité et de confidentialité vis-à-vis des participants. Pour limiter les problèmes de sécurité, PRISM implémente un mécanisme d’interposition, empêchant les tâches d’accéder à des fonctions critiques de l’appareil. L’application mobile observe également les ressources énergétique et réseaux consommées par les tâches, et stoppe leurs exécutions si elles dépassent une valeur limite. Cela permet de renforcer la sécurité de l’appareil, en évitant que des tâches épuisent totalement la batterie des utilisateurs. Pour permettre aux utilisateur de contrôler les données collectées durant l’exécution des tâches, PRISM fournit un mécanisme de contrôle d’accès comprenant trois niveaux : i) No Sensors empêchant tous accès, ii) Location Only permettant l’accès uniquement aux capteurs de position et All Sensors autorisant tous les accès. En ce qui concerne le passage à l’échelle du système, PRISM propose une approche permettant de maîtriser le déploiement des tâches de collecte à un sous-ensemble d’utilisateurs. La figure 4 décrit l’architecture globale de PRISM comprenant deux parties spécifiques : i) une application mobile pour Window Mobile, responsable de l’exécution des tâches soumise par le serveur, et ii) le serveur PRISM, acceptant des tâches d’applications tierces pour les déployer auprès des applications mobiles. Dans PRISM, le déploiement des taches de collecte est assuré via approche push-based, c’est-à-dire permettant au serveur de pousser les applications directement vers les dispositifs mobiles. Cette approche a le principal avantage d’assurer un déploiement rapide des applications, sans que les utilisateurs soient obligés de se connecter réguliè- rement sur le serveur pour voir si une nouvelle tâche est disponible. Pour permettre aux développeurs de définir un sous-ensemble de dispositifs pour déployer leurs tâches, PRISM fournit une API comportant deux niveaux de raffinements (cf. listing 2.3). 1 // set up the first level coarse-grained predicate 2 L1pred = new FirstLevelPredicate(); 3 L1pred.location = ; 4 L1pred.radius = ; 5 L1pred.stationary = false; 6 L1pred.cameraPresent = true; 7 L1pred.numOfPhones = ; 43Figure 4 – Architecture de PRISM [16] 8 // set up the second level fine-grained predicate 9 L2pred = new SecondLevelPredicate(); 10 L2pred.location = ; 11 L2pred.radius = ; 12 // set up the application with the predicates 13 PRSIMapp = new PRISMApplication(); 14 PRSIMapp.Init(); 15 PRISMapp.SetPredicates(L1pred, L2pred); 16 PRISMapp.SetBinary(); 17 PRISMapp.DistributeToPhones(); 18 // read and process data sent by phones 19 while (appData = PRISMapp.GetData()) { 20 ; 21 } Listing 2.3 – Exemple d’application développée avec PRISM Le premier niveau permet de spécifier les capteurs nécessaires pour exécuter la tâche, le nombre de mobiles désirés et une vaste région géographique. Le deuxième niveau permet quant à lui de définir contexte plus précis (par ex. lorsque l’utilisateur se déplace, se trouve dans une zone précise). Pour être en mesure de déployer les tâches de collecte, PRISM requiert une connaissance complète des dispositifs mobiles ainsi que leurs mobilités. Cette connaissance est assurée par une phase d’enregistrement assurée par les dispositifs mobiles. Lors de l’enregistrement, les dispositifs mobiles 44reportent deux sortes d’informations comprenant des données statiques (par ex. capteurs disponibles) et des informations dynamiques (par ex. position et niveau de batterie restant). Cependant, cela nécessite que les dispositifs envoient constamment leurs positions pour permettre au serveur d’avoir une vision en temps réel de leur répartition. Cela peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur, et également négliger la confidentialité des utilisateurs. Lorsqu’une nouvelle tâche est soumise au serveur PRISM, celui-ci compare le premier niveau de raffinement avec tous les dispositifs enregistrés au préalable, et la déploie uniquement aux dispositifs correspondants au premier niveau de raffinement. Le deuxième niveau de raffinement sera ensuite interprété par l’application mobile, qui déclenchera l’exécution de la tâche en fonction des contraintes spécifiées. 2.3.5 Bubble-sensing Bubble-sensing [45] est un système dédié aux déploiements de tâches de collecte participative et communautaire. Ce système focalise principale sur les méthodes de dé- ploiements des tâches de collecte qui doivent être exécutées dans une région spécifique. La figure 5 illustre son architecture. Figure 5 – Architecture de Bubble-sensing [45] Dans le modèle proposé par Bubble-sensing, la création d’une tâche est initiée par le dispositif d’un participant (dispositif A dans la figure 5). Le dispositif joue alors le rôle de bubble anchor, et est responsable de la maintenance de la tâche de collecte dans la zone géographique d’intérêt. Une tâche est définie par un tuple : i) action qui définie 45la tâche à réalisé par les participants (par ex. prendre une photo, une vidéo), région qui définie une zone géographique représentant la bulle où la tâche doit être exécutée, et une durée qui définie la date limite ou l’action doit être réalisé. La tâche est disséminée périodiquement, par des communications à courte distance (par ex. Bluetooth, Wifi direct), jusqu’à ce qu’un autre dispositif mobile reçoive et accepte d’exécuter la tâche en question (dispositif C). Les données collectées sont ensuite envoyées sur le bubble-server. Dans le cas ou l’initiateur de la tâche quitte la zone géographique initialement définie, un message est alors disséminé à tous les autres dispositifs se trouvant à proximité. Dans le cas ou un autre dispositif reçoive le message, il devient alors le bubble anchor (dispositif B) responsable de la maintenance de la tâche dans la bulle. En utilisant cette approche, Bubble-sensing permet d’éviter aux dispositifs de reporter continuellement leur position auprès d’une entité centrale. Cependant, cela implique qu’il y est constamment la présence de participants volontaire pour jouer le rôle de bubble-anchor dans la zone géographique d’intérêt, sinon la tâche de collecte serait alors perdu. 2.3.6 Pogo, a Middleware for Mobile Phone Sensing Pogo [6] est une plate-forme proposée par Brouwers et al., qui a pour objectif d’aider les scientifiques à développer et déployer des tâches de collecte à grande échelle. Trois types d’acteurs sont identifiés dans Pogo. Les participants propriétaires des dispositifs mobiles, les scientifiques et un administrateur. Les participants mobiles exécutent une application mobile dédiée, développée pour Android. En installant l’application mobile, les participants acceptent de partager les ressources de leurs dispositifs pour exécuter des tâches développées par les scientifiques. Les scientifiques, quant à eux, peuvent exécuter une application sur leur ordinateur pour développer de nouvelles tâches et les déployer. Et finalement l’administrateur est responsable d’assigner un ensemble de participants aux scientifiques. Cette assignation est effectuée à partir d’un serveur central, qui garde également une trace de tous les dispositifs et des données qu’ils partagent. Cependant, les auteurs donnent très peu d’informations sur cette phase d’assignation, si elle est manuelle ou automatisée. Une fois un participant assigné à un scientifique, Pogo assure le déploiement des tâches par une approche push-based. Cette approche permet d’assurer un rapide déploiement des mises à jour des tâches, mais implique également un manque de transparence sur les données qui sont 46collectées sur les dispositifs des participants ni avec qui ils les partagent. Nous pensons que ce manque de transparence peut freiner leurs participations, surtout qu’aucun mécanisme d’incitation n’est proposé. Dans Pogo, les tâches de collecte peuvent être développées en JavaScript. Pour simplifier le développement des tâches, Pogo propose une abstraction basée sur le pattern publish-subcribe [21], permettant d’effectuer des communications asynchrone entre entre les scripts et les capteurs. La figure 2.4 illustre un exemple de tâches reportant toutes les minutes les points d’accès WiFi sur les ordinateurs des scientifiques. Comparée aux approches précédentes, l’utilisation du JavaScript comporte de nombreux avantages. Tout d’abord, cela permet de bénéficier de l’expressivité d’un langage générale, permettant ainsi de définir des algorithmes contextuels complexes. Ensuite, l’utilisation du JavaScript permet également de favoriser la réutilisation de code. Et finalement de nombreux projet open sources proposent des moteurs d’exécutions pour l’exécution de code JavaScript sur Android 9 , iOS 10 ou Window Mobile 11, permettant d’assurer la portabilité du code développée vers diverses plate-formes. Cependant, l’abstraction proposée par Pogo ne permet pas d’interagir avec les participants, restant exclusivement réservé à la collecte opportuniste de données. 1 function start(){ 2 3 subscribe(’wifi-scan’, function(msg){ 4 5 publish(msg,’wifi-scan’) 6 7 } , { interval : 60 * 1000 }) } Listing 2.4 – Exemple d’application développée avec Pogo Pogo protège la vie privée des utilisateurs finaux en cachant leur identité aux scientifiques. En outre, les utilisateurs finaux conservent le contrôle de leurs données et sont en mesure de contrôler les capteurs utilisés par l’application. Pogo prend également la consommation d’énergie en considération en coordonnant la transmission des données pour les faire coïncider avec les transmissions d’autres applications. Cela permet d’éviter d’activer les interfaces réseaux constamment qui engendre un grand coût énergétique. 9. Android : https://developer.mozilla.org/enUS/docs/Rhino 10. iOS :https://github.com/phoboslab/JavaScriptCore-iOS 11. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey 472.3.7 AnonySense : A System for Anonymous Opportunistic Sensing Shin et al. introduisent une plate-forme appelée AnonySense [62], adressant majoritaire les problématiques de confidentialité dans les systèmes de collecte opportuniste. Figure 6 – Architecture de Anonysense [62] 1 ( Expires 1196728453 ) 2 ( Accept (= @WiFi a/b/g ) ) 3 ( Report (LOCATION APLIST) 4 ( Every 60 seconds ) 5 ( In ( (1 1) (2 2) (3 0)))) Listing 2.5 – Exemple d’application développée en AnonyTL Pour la description des tâches de collecte, Anonysense propose sur un langage dédié appelé AnonyTL, inspiré de la syntaxe Lisp. AnonyTL permet de spécifier le comportement d’une tâche en fournissant un ensemble de conditions d’acception, des reports de données, et une date d’expiration. Le listing 2.5 décrit un exemple de tâche exprimée en AnonyTL. Cette tâche peut être acceptée uniquement par des dispositifs connectés à une borne WiFi, et collecte l’ensemble des bornes WiFi voisines ainsi que la position toutes les 60 secondes lorsque l’utilisateur se trouve dans une zone précise. Les auteurs proposent, un nouveau argument, le choix d’un nouveau langage pour fournir une notation plus concise et plus compréhensible. Cependant, cette concision diminue également l’expressivité du langage, et empêche également la réutilisation de code pré-existant. 48Le modèle proposé par Anonysense comporte les éléments suivants : un ensemble de dispositifs mobiles (MN), d’applications tierces (App), une autorité d’enregistrement (RA), un service de distribution de tâches (TS), et un service de rapport (RS) et un service d’anonymisation (AS). Dans ce modèle, un App soumet une tâche à l’autorité d’enregistrement (RA). Le RA vérifie ensuite si la tâche respecte la confidentialité des utilisateurs avant de la transmettre au service de distribution (TS). A intervalles réguliers, les MNs se connectent au TS et téléchargent l’ensemble des tâches disponibles. Les MNs choisissent ensuite les tâches qu’ils veulent accepter. Lorsqu’un rapport est prêt, les MNs l’envoient directement au RS ou au AS selon la sensibilité des données. Si le rapport contient des données sensibles, le rapport est envoyé au AS, dans le cas contraire, il est envoyé directement au RS. 2.4 synthèse et conclusion Dans cette section, nous faisons un bilan des plate-formes décrites dans la section précédente. Le tableau 7 fournit un récapitulatif de ces approches et les positionne par rapport aux défis décris en section 2.2. En ce qui concerne les abstractions proposées pour le développement des tâches de collecte, seulement PRISM [16] supporte à la fois le développement de tâche opportuniste et participative, en permettant le déploiement de code natif directement vers les dispositifs mobiles. Cependant, il ne fournit par d’abstraction particulière permettant de simplifier le développement des tâches de collecte. De plus, le déploiement de code natif reste exclusivement réservé à un système d’exploitation mobile spécifique, dans ce cas Windows Mobile. Pour le déploiement et le recrutement des tâches de collecte, principalement deux approches coexistent. La première est l’approche pull-based, adoptée par Medusa [55] et Anonysense, où les dispositifs sont responsables de télécharger les tâches de collecte auprès du serveur. Le principal avantage de cette approche est qu’elle permet d’assurer un certain degré de transparence, dans le sens où les participants peuvent sélectionner les tâches qu’ils souhaitent exécuter. Cependant, le temps de propagation des tâches peut être relativement long, et demande aux participants de vérifier constamment si une nouvelle tâche est disponible. Pour le recrutement des participants, Anonysense permet 49de sélectionner un sous ensemble de participants basé sur leur position. Pour assurer un temps de propagation rapide malgré l’approche pull-based utilisée, l’application mobile télécharge régulièrement toutes les tâches de collecte disponibles sur le serveur et exécute celles qui correspondent à son contexte. Cependant, cela peut impliquer un coût énergétique important des applications mobiles si de nombreuses tâches sont disponibles sur le serveur et ne correspondent pas au contexte du dispositif. La deuxième est l’approche push-based, adoptée par PRISM [16] et Pogo [6], où au contraire c’est le serveur qui déploie les tâches directement auprès des dispositifs mobiles. Son principal avantage est qu’elle permet un déploiement rapide des tâches de collecte, qui peut être très bénéfique dans le cadre où une rapide mise à jour de l’application doit être effectuée. Cependant, cette approche manque de transparence, dans le sens où les participants n’ont pas conscience des données qui sont collectées sur leur dispositif mobile. Pour le recrutement des utilisateurs, PRISM propose également un modèle basé sur la position des participants. Afin de permettre au système d’identi- fier les participants se situant dans une région spécifique, les applications mobiles ont besoin de reporter continuellement leur position sur le serveur, ce qui peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur. Finalement, la majorité de ces plate-formes propose une architecture centralisée, composée d’une application serveur pour le déploiement des tâches de collecte et une application mobile responsable de leurs exécutions. Cependant, ce style architectural impose à tous les utilisateurs du système de partager les ressources de l’infrastructure hébergeant la plate-forme, des mécanismes de stockage de données, le modèle financier imposé par le fournisseur de l’infrastructure et également la législation du pays où l’infrastructure est hébergée. Cela impose également les modèles mis en place pour déployer une application vers les terminaux mobiles, des mécanismes pour protéger la vie privée des utilisateurs, de récompense ainsi que la structure des données collectées. Dans ce contexte, nous pensons que ce type d’architecture limite fortement la réutilisation du système dans un contexte d’application non initialement prévu, ainsi que son passage à l’échelle. De plus, l’entité centrale représente un point unique de défaillance, qui, en cas d’attaque, peut compromettre l’ensemble des données collectées. Dans ce chapitre, nous avons présenté une vue d’ensemble du Mobile crowdsensing, ses caractéristiques, ses avantages ainsi que les défis qui doivent être adressés pour le déploiement de campagnes de collecte de données à grande échelle. À cause de ces 50nombreux défis, la mise en place de campagnes de collecte reste encore difficile, et reste réservée à des développeurs experts. Bien que de nombreuses plate-formes ont été proposées dans l’état de l’art pour simplifier le développement et le déploiement des ces campagnes, les solutions proposées restent encore restreintes à un contexte d’application particulier. De plus, la centralisation de leur architecture limite fortement la réutilisation de ces systèmes dans un autre contexte applicatif ainsi que leurs passages à l’échelle. À partir de ce constat, cela nous a mené à proposer APISENSE®, une plateforme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données. Plus particulièrement, APISENSE® c’est : 1. Un modèle de programmation facilitant le développement de tâches de collecte participatives et opportunistes 2. Un environnement mobile sécurisé assurant l’exécution des tâches de collecte 3. Une architecture décentralisée permettant d’assurer le passage à l’échelle de la plate-forme 4. Un modèle permettant de configurer une application serveur responsable du déploiement des tâches de collecte, de la persistance ainsi que de l’exploitation des données collectées. Dans le chapitre suivant, nous présentons notre première contribution concernant le modèle de programmation des tâches de collecte ainsi que l’environnement mobile dédié à leur exécution. 51Figure 7 – Tableau comparatif des plate-formes MCS 52Deuxième partie Contributions 533 C O L L E C T E M O B I L E D E D O N N É E S Sommaire 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 3.1 introduction Le Mobile Crowd Sensing (MCS) est un mode de collecte de données qui a récemment été défini comme :" la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents, qui collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun." [27]. Ces dernières années, le MCS a suscité l’intérêt d’un grand nombre d’acteurs académiques, dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux [9]. Cependant, le développement de ces applications reste une tâche complexe. En effet, ces applications ont besoin de faire face à de nombreuses propriétés non fonctionnelles telles que les ressources énergétiques limitées des dispositifs mobiles, le respect de 55la confidentialité des utilisateurs mobiles, ou encore le coût du recrutement d’un nombre important d’utilisateurs. À cause de cette complexité, il peut être très difficile pour de nombreuses acteurs de développer leurs applications capables de récolter la masse de données nécessaires pour leurs études. Ces dernières années, de nombreuses communautés scientifiques, utilisant le MCS dans leur processus expérimental, ont beaucoup discuté des bénéfices que pourrait apporter un système facilitant ce mode d’acquisition de données [27, 60, 66, 68]. Dans ce contexte, nous proposons dans cette thèse APISENSE®, une plate-forme visant de nombreux acteurs privés, publics ou académiques, leurs permettant de facilement développer et déployer des applications de collecte de données à travers des utilisateurs mobiles. Dans le chapitre section 1.4, page 13 , nous avons présenté une vue d’ensemble d’APISENSE®. Nous rappelons brièvement que le système est composé de trois entités logicielles i) un serveur central responsable du déploiement de tâches de collecte, ii) des nœuds de collecte dédiés aux utilisateurs, responsable du déploiement des tâches de collecte vers le serveur central et la persistance des données collectées, et finalement iii) un agent mobile, dédié aux participants (c.-à-d. utilisateur mobile) responsables de l’exécution des tâches de collecte. Dans ce chapitre, nous présentons notre première contribution qui consiste à proposer un modèle de programmation visant à minimiser l’expertise nécessaire liée aux développements d’applications de collecte, et la conception d’un environnement d’exécution mobile dédié à aux applications développées par notre interface de programmation. structure du chapitre La suite du chapitre est organisée comme suit : dans la section 3.2, nous faisons un bref rappel des problématiques et des solutions proposées dans l’état de l’art, et identifions les considérations prises en comptes pour la conception de notre solution. Nous présentons par la suite en section 3.3 une vue d’ensemble de l’interface de programmation proposée pour le développement des tâches de collecte. En section 3.4, nous présentons l’architecture du substrat d’exécution dédié à l’exécution des tâches de collecte. Nous présentons en section 3.5 l’évaluation d’un prototype réalisé sur Android, avant de conclure en section 3.6. 563.2 considérations et objectifs de conception Afin d’avoir une large applicabilité, permettant de définir une grande variété de tâches de collecte, nous devons proposer un modèle de programmation qui demande de prendre en considération principalement les trois points suivants : Diversité des tâches de collecte : Une tâche de collecte consiste à définir quel est le type de données (par ex. position, image), quand le processus de collecte doit être effectué (par ex. toutes les 5 minutes, lorsqu’un événement spécifique apparait) et comment une donnée doit être capturée. En ce qui concerne le comment, typiquement deux méthodes peuvent être utilisées. La première demande une interaction avec l’utilisateur (appelée collecte participative [7]), en lui demandant de répondre à un questionnaire ou prendre une photo par exemple. La deuxième s’effectue de manière autonome (appelée collecte opportuniste [39]), en interagissant directement avec les capteurs mobiles embarqués dans les terminaux mobiles. Diversité des traitements locaux : Pour la définition d’une tâche de collecte, quatre préoccupations doivent être prises en considérations : i) la limitation des ressources énergétiques, ii) la quantité des données générées et propagées vers le serveur, iii) la qualité des données et finalement iv) la confidentialité des participants. Prendre en compte ces considérations demande généralement de faire des compromis entre elles, en effectuant un traitement local avant de propager les données vers le serveur. L’objectif de ces traitements est de diminuer les données à propager sur le serveur, en remontant uniquement les données essentielles pour l’expérience, économisant ainsi la batterie de l’utilisateur par la réduction de communications réseau. Ces traitements peuvent consister à filtrer les données aberrantes, inférer une information contextuelle de haut niveau à partir de données brutes (par ex. mode de transport), ou encore alterner l’utilisation des capteurs en fonction de leurs consommations énergétiques (par ex. GPS vs géolocalisation GSM). Diversité des plate-formes mobiles : D’autre part, permettre le déploiement des tâches de collecte vers un grand nombre de participants demande également de prendre en compte la diversité des plate-formes mobiles disponibles. Ceci amène généralement à étudier et réaliser une application mobile spécifique pour chacune d’entre elles. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus 57de six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. En tant que plate-forme de collecte de données, APISENSE® a deux publics distincts : i) les utilisateurs qui veulent définir de nouvelles campagnes de collecte de données, ii) les participants qui exécuteront ces tâches de collecte sur leur dispositif mobile. Dans ce contexte, à partir des considérations décrites ci-dessus et de ces deux publics distincts évoluant dans APISENSE®, nous identifions les objectifs de conception suivants : Objectif de conception pour les utilisateurs : Afin de minimiser le niveau d’expertise nécessaire liée aux développements des applications de collecte, il est nécessaire de fournir une abstraction facilitant leurs développements. Dans ce contexte, l’objectif est de proposer un langage de programmation reposant sur trois propriétés : 1. la généralité : pour supporter une grande variété d’activités de collecte (c.-à-d. participative et/ou opportuniste), qui peuvent également impliquer une grande variété de capteurs. 2. l’accessibilité : permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur. 3. la portabilité : afin d’éviter de devoir définir plusieurs tâches de collecte pour différentes plate-formes mobiles, l’abstraction proposée doit être en mesure de s’exécuter sur ces différentes plate-formes. Objectif de conception pour les participants : Inévitablement, les participants mobiles jouent un rôle central dans le processus de collecte. Afin de favoriser leurs participations, nous pensons que la confiance et la transparence doivent être un aspect fondamental du système. Cela nécessite que les utilisateurs mobiles aient connaissance des données qui sont collectées sur leurs terminaux, avec qui ils les partagent et dans quel but. D’autre part, favoriser l’acceptabilité des utilisateurs demande de fournir un substrat d’exécution permettant de : 1. Contrôler la confidentialité : en laissant la possibilité aux utilisateurs de choisir les données qui sont partagées, les capteurs qui peuvent être utilisés par les 58applications de collecte, et dans quelle circonstance les données peuvent être partagées. 2. Minimiser l’impact énergétique : lié à l’exécution d’une application de collecte, pour ne pas empêcher une utilisation normale du dispositif. Notamment si de multiples applications doivent être exécutées sur un seul dispositif. 3. Récompense adaptée : pour favoriser la participation des utilisateurs mobiles, en rendant ludique le but de la collecte de données, ou en récompensant les utilisateurs financièrement selon la nature des données collectées. 3.3 langage de programmation des collectes Pour le développement des tâches de collecte, nous avons opté pour le langage de script JavaScript. Le choix du JavaScript est motivé principalement pour trois raisons. Premièrement, JavaScript est un langage accessible et populaire, bénéficiant de l’expressivité d’un langage générale. Cela donne aux utilisateurs une grande liberté pour définir des traitements complexes, intégrer des libraires déjà existantes de traitement de données (par ex. clustering) pour inférer des données de haut niveau directement dans le dispositif mobile. Ensuite, JavaScript est facilement transportable et exécutable sur de nombreuses plateformes mobiles, permettant un rapide déploiement et une rapide propagation des mis à jour de la tâche de collecte. Et finalement, d’un point de vue plus technique, JavaScript est nativement exécuté dans un bac à sable (sandbox en anglais), facilitant le contrôle des fonctionnalités des dispositifs mobiles accessibles par les scripts. Pour faciliter le développement des tâches de collecte, nous proposons une interface de programmation (API) dédiée à la collecte de données, au-dessus de JavaScript. Le principal objectif de l’API est de fournir une abstraction complète des technologies mobiles, permettant le développement d’application de collecte de données, sans avoir une expertise particulière dans ces technologies. Dans APISENSE, une tâche de collecte est spécifiée par un ou plusieurs scripts JavaScript, qui peuvent être déployés et exécutés sur les dispositifs mobiles des participants. Dans la suite de cette section, nous présentons une vue d’ensemble de l’API proposée. 593.3.1 Concept de l’interface de programmation Comme le montre la figure 8, notre API consiste en un ensemble de variables pré- définies, appelée façades, définissant l’ensemble des fonctionnalités accessibles par les scripts. Plus précisément, une façade permet d’interagir avec les ressources d’un dispositif, et est implémentée dans le langage natif de la plate-forme d’exécution. Ces ressources peuvent être par exemple des capteurs physiques (par ex. température, GPS), des capteurs logiciels (par ex. appel téléphonique, installation d’une application) ou encore l’interface graphique du dispositif mobile. Dans notre API, chaque façade proposée fait référence à une ressource spécifique, et délimite un sous-ensemble de fonctionnalités fourni par celle-ci. Ce procédé permet ainsi d’empêcher l’utilisation complète des fonctionnalités des dispositifs mobiles, pour des raisons de sécurité et de confidentialité vis-à-vis du participant. Par exemple, cela permet de crypter toutes les informations sensibles (par ex. contacts, numéro de téléphone, etc.), d’empêcher l’installation de nouvelles applications ou encore de faire des appels téléphoniques. Également pour des raisons de confidentialité, nous laissons la possibilité aux participants de contrôler les façades accessibles par les scripts de collecte. Par exemple, un participant peut à tout moment enlever la possibilité à un script de déterminer sa position, ou d’être notifié lorsqu’il reçoit des SMS. La communication entre les scripts et les façades peut s’effectuer de deux manières différentes. La première, de manière asynchrone, permet aux scripts d’être notifiés du changement des états des capteurs des dispositifs mobiles. La deuxième, de manière synchrone, permet aux scripts de collecte d’effectuer une action spécifique, ou alors de lire directement le dernier état d’un capteur. 3.3.2 Collecte de données dirigée par les évènements L’écoute des évènements permet de déclencher une action ou un traitement en fonction du contexte de l’utilisateur mobile. Par exemple, la collecte de données peut être déclenchée uniquement lorsque l’utilisateur est en situation de mobilité. L’observation du contexte consiste principalement à observer le changement d’état d’un capteur interne du dispositif. Pour interagir avec les capteurs, les façades proposent un ensemble de fonctions permettant aux scripts d’être notifiés de ce changement d’état. Le tableau 1 montre quelques exemples de façade et des fonctions associées dédiées à l’observation d’un événement particulier. L’observation consiste donc à souscrire une 60Figure 8 – Interface de Programmation APISENSE Façade Fonction Description $location onLocationChange Observation du changement de position $battery onBatteryStateChange Observation de l’état de la batterie $acc onAccelerometerChange Observation de l’accélération $phone onPhoneCall Observation des appels téléphonique Table 1 – Liste des fonctions d’observation d’événements prédéfinis. Paramètre Type Description configuration JSONObject Configuration de l’observation de l’état du capteur callback function(event,subscription) Fonction de rappel condition (optionnel) String Condition logique Table 2 – Liste des paramètres d’une fonction de rappel 61fonction de rappel, à une façade responsable du capteur capable de générer l’événement voulu. La souscription comprend trois paramètres, permettant la configuration du capteur, la fonction de rappel et une expression logique permettant de raffiner l’observation des événements, et retourne un objet de type Subscriber. configuration Le premier paramètre configuration laisse la possibilité de configurer l’observation du capteur en question. La configuration peut être utilisée afin de faire un compromis en qualité des données transmises par les capteurs (c.-à-d. fréquence d’échantillonnage, précision) et l’énergie consommée liée à l’observation du capteur. Un exemple classique est l’observation du changement de la position d’un utilisateur. Généralement, ce compromis peut être effectué en alternant le type de capteur utilisé — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais fournit une localisation moins précise —, ou la fréquence d’échantillonnage. Le tableau 2 illustre les configurations du capteur de position possibles. Fonction Description period Période d’échantillonnage de la position provider Capteur de position utilisé : gps ou network Table 3 – Configuration de l’observation de la position d’un utilisateur fonction de rappel Le deuxième paramètre permet d’enregistrer une fonction qui sera exécutée lors du changement d’état du capteur observé. Par exemple, le listing suivant montre la syntaxe permettant à un script de collecte d’être notifié lorsque l’utilisateur est en situation de mobilité : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque une nouvelle position est détectée }) Chaque événement est défini par un ensemble d’attributs, sérialisés par un ensemble de clés/valeurs utilisant le formalisme JSON. Chaque événement est au minimum défini par un nom, et la date de sa production. Le listing suivant illustre un exemple d’événement produit lorsqu’une nouvelle position de l’utilisateur est détectée : 62{ event : "location", time : 18005010510, latitude : 50.65, longitude : 2.11, accuracy : 100, speed : 3 } Dans cet exemple, l’événement est défini par cinq attributs indiquant la position de l’utilisateur (c.-à-d.latitude, longitude), la précision de la position (c.-à-d.accuracy) et la vitesse de l’utilisateur (c.-à-d.speed). condition logique Optionnellement, l’écoute d’événement peut être raffinée en insérant une condition lors de la souscription. La condition se définit par un opérateur appliqué à un attribut appartenant à l’événement et à une valeur. Plusieurs conditions peuvent être exprimées en ajoutant des opérateurs logiques de type et, ou ou non. (cf. listing 3.1). Le listing suivant illustre un exemple utilisant une expression logique, implémentant une solution naïve pour déterminer si l’utilisateur est en train de marcher : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque l’utilisateur marche }," &((speed > 3),(speed < 5)) ") Dans cet exemple, nous observons donc le changement de position, et nous définissons que la fonction de rappel doit être exécutée uniquement si l’utilisateur se déplace à une vitesse comprise entre trois et cinq Kilomètres/h. 1 expression ::= key’(’[condition+]’)’ | condition 2 condition ::= eventAttribute operator value 3 key ::= ( "!" | "&" | "|" ) 4 operator ::= ( "<" | "==" | ">" | "<=" | ">=" ) 5 eventName ::= alpha* 6 eventAttribute ::= alpha* 7 value ::= alphanumeric* Listing 3.1 – Grammaire BNF d’une expression logique objet de souscription Pour maintenir un lien entre la souscription et le script, un objet de type Subscriber (cf. table 4) est retourné lors de l’enregistrement. L’objet de souscription permet d’annuler la souscription à un événement particulier 63(fonction suspend), permettant d’éteindre un capteur actif afin de conserver l’énergie du dispositif mobile. La méthode resume permet de reprendre une souscription qui a été annulée. Fonction Description suspend Suppression de l’observation resume Redémarrage de la souscription Table 4 – Liste des fonctions d’un objet de souscription 3.3.3 Les actions En plus de l’observation des événements, les façades fournissent également des fonctions permettant d’exécuter des actions spécifiques. Dans la suite de cette soussection, nous présentons les principales actions prédéfinies par notre API qui sont la collecte et la propagation de données, l’interaction avec l’utilisateur mobile ou encore définir des informations pouvant être fournies en retour aux utilisateurs sur les données collectées. Collecte et propagation des données La collecte de données est effectuée à l’aide de la façade dédiée $trace. Cette façade possède trois fonctions comme le montre le tableau 5. La première permet de sauvegarder une donnée dans la base de données locale du terminal mobile (méthode add). Les données sont sous la forme d’un objet JSON, n’imposant aucune structure de données particulière pour représenter les données collectées. Cela laisse ainsi une grande flexibilité aux utilisateurs de définir leurs propres structures. Additionellement, les utilisateurs peuvent ajouter des méta-informations (méthode addHeader), permettant de diminuer la collecte de données redondantes, et leurs agrégations une fois propagées vers le serveur. Ces méta-informations représentent généralement des données statiques, c’est à dire qui n’évoluent pas dans le temps. L’API permet également de définir la stratégie pour propager les données vers les nœuds de collecte grâce à la méthode send. Lors de l’appel à cette fonction, la façade propagera les données sauvegardées dans la base de données locale si une connexion est disponible, sinon les données seront propagées une fois la connexion retrouvée. Dans le cas où aucune stratégie n’est définie, les données seront propagées automatiquement une fois que le 64dispositif est branché sur secteur et possède une connexion réseau. Cela permet de diminuer la consommation énergétique des dispositifs des participants. Fonction Description add(data) Collecter une donnée addHeader(key,value) Collecter une donnée statique send() Propagation des données collectées Table 5 – Liste des fonctions de la façade de collecte Interaction avec l’utilisateur Collecter des données de façon transparente peut ne pas être suffisant dans certains cas. En effet, certaines informations comme la satisfaction d’un utilisateur ou ses intentions sont difficilement perceptibles à partir de donnée brute. Prenons par exemple une collecte de donnée visant à observer la qualité du signal réseau d’un utilisateur mobile. Il peut être intéressant de voir comment la qualité du signal réseau influe sur la qualité de la communication vocale. Cependant, cette information peut être très difficilement inférée à partir des données brutes issues des capteurs. Dans ce contexte, une solution possible est de proposer des questionnaires d’évaluation aux utilisateurs. Ce type de collecte est également appelé collecte participative. Pour supporter la collecte participative, notre API dispose d’une façade permettant la création et la publication de questionnaire aux utilisateurs mobiles. Le tableau 6 illustre les principales fonctions fournies par cette façade. La création d’un nouveau questionnaire s’effectue à partir de la fonction create de la façade $survey. La fonction retourne un objet de type Survey, disposant d’un ensemble de fonctions permettant d’insérer des questions ouvertes (par ex. zone de texte), de question fermée (par ex. case à cocher), ainsi que des captures multimédias (c.-à-d. photo, vidéo, audio). La fonction then permet de modifier la séquence des questions proposée à l’utilisateur, qui est par défaut dans l’ordre de leurs créations. Cela permet par exemple de proposer des questions différentes selon les premières réponses données par l’utilisateur. Nous illustrerons un exemple de création de questionnaire dans la sous-section 3.5.1 . 65Facade $survey Return Fonction Description Survey create Création d’un nouveau questionnaire void publish(survey,callback) Publication du questionnaire Type Survey void close(label,question,responses) Création d’une question fermée void open(label,question) Création d’une question ouverte void image(label,format) Capture photo void audio(label,format) Capture audio void video(label,format) Capture vidéo void then(label,callback) Spécification de la prochaine fonction Table 6 – Liste des fonctions de la façade dédiée à la création des questionnaires Retour utilisateur Afin de favoriser leurs participations des utilisateurs, et surtout maintenir les utilisateurs dans la durée, nous avons intégré à notre API la possibilité d’effectuer facilement des retours visuels sur les données collectées par l’utilisateur mobile. Ces retours visuels peuvent être directement développés utilisant le couple JavaScript/HTML, fournissant une grande flexibilité pour concevoir des retours selon la nature de collecte de données. Pour simplifier leurs développements, nous proposons des modules complémentaires qui peuvent être inclus dans la tâche de collecte lors de son déploiement, ou téléchargés dynamiquement lors de l’exécution du script. Actuellement nous proposons deux modules génériques permettant de créer automatiquement des graphes ou des cartes géographiques à partir des données collectées. Par exemple, le listing 3.2 décrit un exemple l’utilisation d’un module facilitant la génération de graphe. Dans cet exemple, les trois premières permettent de charger le module (ligne 1), créer un nouveau graphique (ligne 2) et rendre disponible le graphique pour les utilisateurs (ligne 3). Les lignes suivantes permettent d’observer les évènements relatifs aux changements de la force du signal GSM (ligne 7), et d’ajouter une nouvelle valeur au graphique lorsqu’un nouvel évènement est détecté (ligne 9). La figure 9 montre une capture d’écran du rendu graphique de cet exemple. 66// signal strenght chart configuration var chartLib = require("lib-chart.js") chart = chartLib.area({name : "GSM Signal Strength Chart"}); chart.publish(); // telephony sensor monitoring initialization $telephony.onSignalStrengthChanged(function(event){ chart.add({ x : event.time, event.level }); }); Listing 3.2 – Exemple de retour utilisateur Figure 9 – Exemple de capture d’écran d’un retour utilisateur Dans cette section, nous avons présenté une vue d’ensemble de notre API, dédié aux développements des tâches de collectes de notre système. Une documentation plus détaillée est également disponible le site internet dédié à APISENSE 1 . Dans la 1. http://apisense.io 67section suivante, nous présentons les concepts et l’architecture de l’intergiciel dédié à l’exécution de l’interface de programmation présentée dans cette section. 3.4 intergiciel de collecte Dans la première section de ce chapitre, nous avons présenté une interface de programmation dédiée aux développements de tâche de collecte en environnement mobile. Dans cette section, nous présentons en détail l’architecture de l’intergiciel responsable de l’exécution des tâches de collecte. D’un point de vue utilisateur, l’intergiciel se dé- cline sous la forme d’une application mobile, qui peut être téléchargée et installée afin de participer aux expériences de collecte de données. Dans ce cadre, l’application peut être perçue comme un conteneur générique de tâches de collecte, capable d’interagir avec les différents serveurs pour la propagation des données collectées (vers les nœuds de collecte), le téléchargement des tâches de collecte (auprès du serveur central) ainsi que leurs exécutions. La figure 10 illustre une vue d’ensemble de l’architecture de l’intergiciel se déclinant en trois couches. Dans la suite de cette section, nous présentons en détails chacune de ces couches dédiées à : i) l’exécution des tâches de collecte (cf. sous-section 3.4.1), au contrôle des ressources du dispositif mobile (cf. sous-section 3.4.2), et iii) aux interactions avec les différentes entités logicielles d’APISENSE® (cf. sous-section 3.4.3). 3.4.1 Couche d’exécution Nous présentons ici la couche responsable de l’exécution des tâches de collecte développées avec l’interface de programmation que nous avons présentée dans la section précédente. La première couche de l’architecture présentée est responsable de l’exécution des tâches de collecte. La Figure 11 illustre plus en détail les différents modules et les interactions nécessaires à l’exécution des tâches de collecte. Le point d’entrée de cette couche est le Script Manager, qui est responsable de créer ou détruire une instance d’exécution d’une tâche de collecte, selon l’ordre envoyé par le Privacy Manager. Dans ce contexte, l’objectif clé est de fournir un environnement d’exécution sécurisé, permettant également aux participants de contrôler les données qu’ils partagent pour des raisons de confidentialité. Cependant, généralement tous les accès aux données brutes des capteurs peuvent constituer une menace pour la 68Figure 10 – Architecture de l’intergiciel mobile Figure 11 – Interaction de la couche d’exécution 69vie privée des participants. Par exemple, l’accès au microphone peut être utilisé pour enregistrer une conversation téléphonique souhaitant rester privée. L’accès continu au GPS peut permettre à un utilisateur anonyme d’être identifié juste en couplant des informations géographiques et temporelles [26]. Néanmoins, ce risque reste inhérent dans le domaine de la collecte de données. En effet, si nous voulons une protection parfaite, tous les accès aux capteurs devraient être bloqués. Pour mitiger ces risques, nous laissons la possibilité aux participants de contrôler les capteurs accessibles par les tâches de collecte (cf. 3.4.2). Pour la gestion de ce contrôle d’accès, chaque instance d’exécution d’une tâche de collecte est exécutée dans un bac à sable dédié (sandbox en anglais), permettant d’intercepter tous les appels entre les tâches de collecte et les capteurs du dispositif. Ainsi, toutes les fonctionnalités de l’interface de programmation sont fournies par un ensemble de façades (cf. sous-section 3.3.1), représentant également le point d’extension de notre l’architecture. Une façade est un objet, écrit en code natif de la plate-forme mobile, permettant l’interaction entre les tâches de collecte et l’environnement mobile. Le listing 3.3 montre l’exemple d’un squelette d’implémentation sous Android, de la façade permettant d’accéder aux capteurs de localisation. Dans cette façade, la fonction getReferenceName retourne le nom de la variable qui est utilisée pour accéder aux fonctions fournies par la façade. Chaque fonction annotée par une annotation @ScriptMethod, indique au moteur de script que la fonction est accessible par les tâches de collecte. Si nous reprenons l’exemple illustré dans la section précédente (cf. sous-section 3.3), la fonctionnalité $location.onLocationChanged accessible par la tâche de collecte, est implémentée par la façade LocationFacade, injectée en tant que variable $location et implémentant la fonction onLocationChanged. 1 public class LocationFacade extends AbstractAndroidFacade{ 2 3 public String getReferenceName() {return "location";} 4 5 public String getSensorDescription(){ ... 6 7 @ScriptMethod 8 public ISubscriber onLocationChanged( 9 JSONObject params,IScriptFunction callback,String... filters){ 10 // subscribe to location sensor update 11 return ... 12 } 13 14 public void shutdown() { ... // clean sensor subscription } 15 } 70Listing 3.3 – Squelette de l’implémentation d’une façade sur Android Lors de la création d’une nouvelle instance d’exécution, le Script Manager effectue une requête au Privacy Manager pour lister l’ensemble des capteurs admis par le participant. Le Script Manager injectera alors seulement les façades correspondantes aux capteurs qui auront été admis par le participant. Dans ce cadre, les façades correspondant aux capteurs non autorisés ne seront pas injectées, empêchant les scripts de bénéficier des fonctionnalités du capteur en question. Réguler l’accès aux capteurs Pour interagir avec les capteurs du dispositif mobile, les façades doivent interagir avec le Sensor Controller. Son objectif est principalement de réguler l’accès aux capteurs du dispositif et de filtrer les données sensibles. Par exemple, lorsqu’une façade demande l’accès à des informations de type SMS ou numéro de téléphone, les données retournées par la couche de contrôle seront automatiquement cryptées pour protéger la vie privée des participants. Deux types de communications peuvent être effectuées avec le Sensor Controller, des communications de type asynchrone permettant la lecture continuelle de l’état d’un capteur et de type synchrone afin de lire directement l’état d’un capteur. Pour économiser la batterie du dispositif mobile, le Sensor Controller dispose de deux mécanismes. Le premier est un mécanisme de cache, dédié aux communications synchrones. Ce mécanisme permet principalement de limiter une lecture excessive de l’état d’un capteur. Ce mécanisme consiste principalement à définir une fenêtre temporelle dans laquelle seront insérées toutes les données récupérées par le Sensor Controller via les APIs des systèmes mobiles, donnant accès aux données fournis par les capteurs physiques. Avant de procéder à un nouvel accès aux capteurs, la couche de contrôle vérifiera dans un premier temps si la donnée demandée est disponible dans la fenêtre temporelle. Si elle est disponible, la valeur du cache sera alors renvoyée. Le deuxième mécanisme mis en place tente de minimiser le nombre de souscriptions effectuées aux capteurs des dispositifs. Typiquement, un script peut être notifié du changement d’état d’un capteur en enregistrant à une façade une fonction de rappel, une expression logique permettant de filtrer les états ainsi qu’une période indiquant la fréquence des mises à jour des données. Dans le cas où plusieurs scripts procèdent 71à la souscription d’un même capteur avec une période différente, le Sensor Controller effectuera seulement une souscription aux capteurs correspondants, avec une période correspondante à la plus petite période des deux souscriptions. Prenons le cas par exemple où deux scripts effectuent une souscription au capteur GPS avec les périodes respectives de 10 et 20 secondes. Dans ce cas, le Sensor Controller effectuera une seule souscription au capteur GPS avec une fréquence d’échantillonnage égale à 10 secondes, et notifiera les deux scripts toutes les 10 secondes de la nouvelle position. 3.4.2 Couche de contrôle Cette couche est responsable du contrôle de l’exécution des scripts de collecte. Le contrôle consiste à automatiquement démarrer ou arrêter un script de collecte, à partir d’un ensemble de contraintes contextuelles définies par les participants et les expé- riences. Ces contraintes peuvent par exemple permettre aux participants d’empêcher l’exécution d’un script en dehors de la période allant de 9 heures et 18 heures ou lorsque le participant est en dehors d’une zone géographique. Un autre scénario envisagé est d’empêcher l’exécution d’un script si le niveau de la batterie est inférieur à 30 %. Ces contraintes peuvent être classifiées en quatre catégories : contrainte temporelle, contrainte géographique, contrainte de ressource et contrainte de capteur. Ces contraintes sont respectivement interprétées par les modules TimeConstraint, ZoneContraint, ResourceConstraint et SensorConstraint. Contrainte temporelle Ces contraintes, interprétées par le module Time Constraint, permettent de spécifier différentes périodes de la journée durant lesquelles les expériences ont l’autorisation d’être exécutées. Ces contraintes sont modélisées comme un ensemble de périodes où chaque période est définie par un temps de départ et un temps de fin. Pour une expérience donnée, la contrainte temporelle est vérifiée si, à instant t, t appartient au moins à une période définie par le participant et à une période définie par le contexte d’exécution de l’expérience. La surveillance contextuelle des contraintes temporelle consiste à surveiller l’horloge interne du dispositif mobile. Pour chaque contrainte définie, ce module programme une alarme, demandant au système d’être notifié au début et à la fin de la période définissant la contrainte. 72Contrainte géographique Interprétées par le module Zone Constraint, les contraintes géographiques permettent de spécifier un ensemble de lieux ou de régions, dans lesquelles les scripts peuvent être exécutés selon la position du participant. Une contrainte géographique est modélisée par un ensemble de régions circulaires en terme de latitude, longitude et un rayon en kilomètre. Pour une expérience donnée, la contrainte géographique est vérifiée si à une position p donnée, p est inclus au moins dans une zone définie par le participant ou par le contexte d’exécution de l’expérience. En ce qui concerne la surveillance contextuelle, surveiller activement la position de l’utilisateur peut engendrer une grande consommation énergétique du dispositif. Pour diminuer cette consommation énergétique, nous utilisons un algorithme fréquemment utilisé [3, 8] dans la littérature. Typiquement, l’idée principale est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance de l’utilisateur et la zone la plus proche de sa position actuelle. Contrainte de ressource Ces contraintes permettent de limiter les ressources consommées par l’application. Le participant peut par exemple définir un seuil de batterie pour stopper l’exécution de toutes les expériences de collecte pour éviter un épuisement complet de sa batterie. Une autre ressource qui peut être contrôlée est la quantité de données échangées via une connexion de données mobiles qui peut induire un coût monétaire pour le participant. Dans ce cadre, le participant peut définir un seuil maximum de données transmises lorsqu’une connexion est utilisée. Contrainte de capteur Ces contraintes permettent de spécifier les fonctionnalités permises par les scripts de collecte. Dans l’interface de programmation proposée pour définir une expérience de collecte, nous avons vu que les fonctionnalités accessibles par les scripts se font par l’intermédiaire de façades. Pour chaque façade, le participant a la possibilité de définir s’il autorise l’accès à l’ensemble des fonctionnalités proposées par la façade. Par exemple, le participant peut enlever l’autorisation de la façade $sms, qui supprimera la possibilité de recueillir des informations relatives aux SMS envoyés et lus. 73Dans l’architecture présentée précédemment en figure 10, les modules TimeConstraint, ZoneConstraint et RessourceConstraint ont pour rôle de surveiller le contexte du dispositif (e.g. horloge interne, position, niveau de batterie) et d’envoyer un message au Privacy Manager afin de notifier un changement de contexte du dispositif mobile. Lors de la notification, le Privacy Manager vérifie pour chaque expérience si les contraintes spécifiées par le participant et par l’expérience sont respectées. Dans ce cas, le Privacy Manager interprètera les contraintes de capteurs définies par le module Sensor Constraint pour générer une nouvelle instance d’exécution ou stopper l’exécution d’une expérience de collecte. 3.4.3 Couche d’interaction La dernière couche présenté dans cette section représente la couche de plus haut niveau de l’intergiciel. Cette couche est principalement responsable des interactions entre le dispositif mobile avec les différentes entités logicielles de notre architecture et le participant. Typiquement, cinq types d’interactions sont nécessaires au déroulement des expériences de collecte : i) l’enregistrement auprès du serveur central, ii) la souscription à une expérience de collecte, iii) la mise à jour des expériences, iv) l’interaction avec les participants et finalement v) la propagation des données collectées. Dans la suite de cette sous-section, nous présentons ces interactions et les modules responsables de leurs fonctionnements. Souscription du dispositif Le processus d’enregistrement, géré par le Profile Manager, permet d’informer le serveur central de la disponibilité d’un nouveau périphérique mobile pour l’exécution de nouvelles tâches de collecte. Typiquement, cette phase d’enregistrement consiste à fournir des informations générales du dispositif et du participant, permettant de proposer des expériences de collecte adéquates. Dans ce contexte, deux sortes d’informations sont principalement échangées. Les premières sont des informations relatives au dispositif mobile incluant le type du dispositif (par ex. smartphone, tablette), son système d’exploitation (par ex. Android, iOS), ses performances ainsi que les capteurs embarqués (par ex. température, GPS). Pour raffiner la proposition des expériences, les participants ont la possibilité de compléter ces informations volontairement en indiquant les différents lieux de vie dans lequel ils évoluent (par ex. maison, travail) son statut (par ex. professionnel) ainsi que son âge.Toutes les informations transmises 74Figure 12 – Règles de confidentialité resteront confidentielles, c’est-à-dire qu’elles ne seront pas directement accessibles par les nœuds de collecte du système. Ces informations seront utilisées uniquement par le serveur central lors de la phase du déploiement des expériences de collecte. D’autre part, afin de protéger la vie privée des participants, le Profile Manager permet aux participants de définir certaines règles de confidentialités (cf. figure 12). Principalement trois catégories de règles peuvent être définies. Les deux premières permettent de spécifier des zones géographiques et temporelles, indiquant à l’agent mobile une interdiction d’exécuter des tâches de collecte. La dernière catégorie permet de spécifier des règles d’autorisations, permettant d’empêcher l’activation des capteurs ou l’accès aux données brutes du capteur si l’utilisateur ne veut pas partager une information. Nous aborderons plus en détails ce point dans la sous-section suivante (cf. sous-section 3.4.2). Souscription à une expérience Une fois le dispositif enregistré, les participants ont la possibilité de lister (via le ExperimentManager), un sous ensemble d’expériences de collecte proposées par les utilisateurs. Les expériences sont retournées en fonction des informations fournies lors de la phase d’enregistrement. Chaque expérience est définie tout d’abord par un nom ainsi qu’une brève description indiquant l’objectif de la collecte de données. La description d’une expérience est également caractérisée par un contexte d’exécution définissant quand l’expérience doit être exécutée. Le contexte d’exécution est défini 75selon une dimension géographique (par ex. à l’intérieur d’une zone) et une dimension temporelle (par ex. période dans la journée). D’autre part, des informations relatives aux capteurs utilisés sont fournies pour indiquer aux participants quels sont les types de données qui peuvent être collectées sur leurs dispositifs. À partir de l’ensemble des descriptions disponibles, le participant a la possibilité de soumettre une souscription à une expérience de collecte. Dans ce cadre, la souscription déclenchera le téléchargement des scripts associés dans le système de fichier du dispositif mobile ainsi que des informations complémentaires propres aux scripts de collecte. Ces informations comprennent la version actuelle des scripts de collecte, l’adresse du serveur de collecte ayant initié l’expérience ainsi qu’un identifiant anonyme généré lors de la souscription. L’identifiant anonyme généré par le serveur central est unique pour chaque expérience. Cette identifiant servira alors de clé d’authentification lors de la propagation des données vers le serveur de collecte. Lorsque les scripts de l’expérience sont téléchargés, le module déclenche automatiquement son exécution. Néanmoins le participant garde à tout moment la possibilité d’arrêter son exécution. Mise à jour des expériences La mise à jour des expériences de collecte est gérée par le module NotificationManager. Les mise à jour sont effectuées par des communications de type push, c’est-à-dire des communications serveur vers mobile. Dans notre contexte applicatif, cela permet d’éviter de faire des requêtes périodiques vers le serveur, induisant un surcoût énergétique pour assurer une rapide prolifération. Pour assurer ce type de communication, nous utilisons des services intermédiaires proposés par les plate-formes mobiles actuelles, telles que APNs (Apple Push Notification service) pour plateformes tournant sur iOS et GCM (Google Cloud Messaging) pour les plateformes Android. Généralement, pour utiliser ce type de service, les dispositifs mobiles doivent tout d’abord procéder à une phase d’enregistrement auprès du service en question. Cette phase permet l’obtention d’un identifiant unique, qui devra ensuite être partagé avec le serveur — dans notre contexte, le serveur central— voulant envoyer des messages vers le dispositif en question. Le serveur peut ensuite faire appel au service dédié en utilisant les identifiants partagés pour propager directement des informations auprès des dispositifs mobiles. Dans ce contexte, lorsqu’une nouvelle version d’une expérience est déployée, le serveur central envoie un message à tous les participants ayant souscrits à l’expérience en question. Ce message est ensuite intercepté par le NotificationManager qui déclenchera automati- 76quement le téléchargement de la nouvelle version, sans imposer aux participants de télécharger à nouveau la tâche de collecte manuellement. Retour utilisateur Le Feedback Manager est responsable de l’interaction entre les tâches de collecte et les participants. Comme nous l’avons mentionné précédemment (cf. sous-section 3.3.3, page 66 ), l’interface de programmation proposée permet de diffuser des visualisations aux participants. Ces visualisations peuvent consister à fournir des statistiques sur les données collectées sous forme de graphique ou de carte, leur demander de prendre une photo d’un évènement particulier ou répondre à un questionnaire. Ces visualisations peuvent être directement développées en HTML/JavaScript, fournissant une grande flexibilité pour définir leurs propres visualisations en fonction de la nature de leurs expériences. D’autre part, cela permet également d’être indépendant de la plate-forme d’exécution, évitant ainsi le développement de plusieurs visualisations selon les plateformes visées. Dans ce cadre, nous tirons bénéfice des modules fournis par les plateformes mobiles (par ex. WebView 2 pour Android, UIWebView 3 pour iOS) pour faciliter l’intégration de contenus web dans une application mobile. Dans ce contexte, les tâches de collecte peuvent interagir avec le FeedBackManager, via une façade dédiée, permettant de publier un nouveau contenu accessible par le participant. Chaque contenu web est ensuite sérialisé et sauvegardé dans une base de données, et pourra être visualisé par le participant à tout moment à partir d’une interface graphique fournie par le FeedBackManager, (cf. figure 13). Propagation des données La propagation des données vers les nœuds de collecte est gérée par le TrackManager. Lors de l’exécution d’une tâche de collecte, les données collectées sont transmises au TrackManager qui les sauvegarde dans la base de donnée locale du dispositif. Pour chaque expérience, le processus de propagation (cf. sous-section 3.3.3) consiste à compresser les données collectées, ajouter des méta-informations sur la configuration du dispositif du participant (c.-à-d. filtre de vie privée) et à faire appel au service dédié du serveur de collecte ayant initié l’expérience pour l’envoi des données. Pour des raisons de sécurité, l’envoi des données s’effectue en utilisant le protocole HTTPS pour le cryptage des données. 2. Android WebView : http://tinyurl.com/android-webview 3. iOS UIWebView : http://tinyurl.com/ios-webview 77Figure 13 – Exemple de contenu web disponible via le FeedbackManager Nous venons de présenter dans cette section l’intergiciel mobile responsable de l’exécution de tâche de collecte, développée avec l’interface de programmation présentée dans la première section de chapitre. Dans la section suivante, nous présentons l’évaluation d’un prototype implémentant les concepts proposés dans ce chapitre. 3.5 évaluation du prototype Afin d’implémenter les concepts présentés dans ce chapitre sur une plate-forme mobile spécifique, celle-ci doit permettre principalement i) d’effectuer des processus en tâche de fond, ii) permettre la lecture en continue des capteurs, iii) et finalement être capable d’intégrer un moteur de script dans une application. Lorsque nous avons commencé le développement de notre prototype, la plate-forme Android correspondait parfaitement à ces caractéristiques, contrairement aux systèmes d’exploitation iOS qui ne permettaient pas d’exécuter des processus en tâche de fond limitant ainsi le développement d’application de collecte opportuniste. Cependant, les récentes mise à jour de ce système d’exploitation fournissent désormais ce support, rendant portable notre système pour iOS. Par manque de temps, nous n’avons pas pu fournir un prototype complet sur ce système d’exploitation, mais nous avons fourni une preuve de faisabilité disponible en open source 4 . Le prototype Android proposé a été conçu pour être utilisé comme application autonome ou comme librairie. En tant qu’application autonome, l’application peut être 4. https://github.com/APISENSE/APISENSE-SDK-iOS 78téléchargée par des participants voulant évoluer dans le système en flashant un QR code publié sur le site internet APISENSE® 5 . Plus particulièrement, le prototype réalisé à été développé en utilisant la version 2.3 du SDK proposé par Android. L’ensemble des modules proposés par l’architecture est inclus dans un Service de haute priorité pour prévenir que le système ne supprime notre application lorsqu’il a besoin de mémoire. Pour l’exécution des scripts, nous utilisons Rhino 6 , un moteur d’exécution JavaScript pour Java, qui permet l’interopérabilité des deux langages. L’ensemble du code réalisé représente approximativement 30000 lignes de codes, incluant l’interface graphique et l’architecture de l’application et les façades développées. Dans la suite cette section, nous présentons plusieurs cas réels d’expériences, montrant la diversité des tâches de collecte qui peuvent être réalisées à l’aide notre interface de programmation. Nous comparons par la suite son expressivité avec les différentes approches proposées dans la littérature, et discutons du coût énergétique lié à l’exécution des tâches de collecte sur les dispositifs mobiles. 3.5.1 Quelques exemples de collectes Pour démontrer l’expressivité de l’interface de programmation proposée dans ce chapitre, nous avons implémenté quatre tâches de collecte différentes (cf. table 7). Chaque tâche de collecte est inspirée de l’état de l’art, et démontre différents aspects de APISENSE. Wifi/Blutooth Scanner Wifi/Blutooth Scanner est une application opportuniste, montrant une interaction avec les capteurs Wi-Fi et Bluetooth d’un dispositif. Le listing 3.4 illustre le script implémentant cette application. L’objectif du script est de collecter, toutes les minutes, les points d’accès WIFI et les périphériques Bluetooth d’un utilisateur mobile. Dans le script, nous enregistrons une fonction de rappel aux façades $wifi et $bluetooth responsables des interactions avec ces capteurs, et nous configurons les capteurs pour qu’ils effectuent une nouvelle recherche toutes les minutes (period:"1 min"). La 5. http://www.apisense.fr 6. http://www.mozilla.org/rhino 79Application Capteurs Description Wifi-Blutooth Scanner Réseaux Application opportuniste. Collecte périodiquement les périphériques Bluetooth et Wi-Fi. Citoyen Journaliste GPS + Questionnaire Application participative. Demande à l’utilisateur de prendre une photo lorsqu’il se situe dans une zone géographique. Qualité Réseau Réseau + Questionnaire + Télé- phone Combinaison d’une application opportuniste et participatif.pour corréler la qualité d’une communication en fonction de la qualité du signal GSM. Exploiter des capteurs externes Bluetooth Communication avec un robot Lego Mindstorms NXT Inférence Conxtuelle Accéléromètre + Questionnaire Intégration d’une machine d’apprentissage pour inférer l’activité d’un utilisateur. Table 7 – Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) fonction de rappel enregistrée collecte alors les résultats donnés par les capteurs pour les propager vers le serveur ($trace.add(event)). 1 $wifi.onScan({period : "1 min"},function(event){ 2 $trace.add(event) 3 }) 4 $bluetooth.onScan({period : "1 min"}, function(event){ 5 $trace.add(event) 6 }) Listing 3.4 – Tâche de collecte : Wifi/Bluetooth Scanner Nous décrivons dans l’exemple suivant un exemple de collecte participative. Le Citoyen Journaliste L’objectif de cette application est de montrer comment une tâche de collecte peut interagir avec un utilisateur. Le Citoyen Journaliste, présenté initialement en [29], demande aux utilisateurs mobiles de prendre une image dans une région géographique spécifique, et de la commenter. Le script présenté dans le listing 3.5, crée d’abord un questionnaire (ligne 1-3). En ligne 5 nous observons la position de l’utilisateur et définissons que la fonction enregistrée (ligne 6-8) doit être exécutée uniquement lorsque la position de l’utilisateur se trouve dans le polygone précis (ligne 8). La fonction enregistrée publie le questionnaire à l’utilisateur (ligne 6), et collecte les données pour les propager vers le serveur lorsque l’utilisateur aura répondu au questionnaire. 801 var survey = $survey.create(); 2 survey.image("Take a picture"); 3 survey.open("Add a comment"); 4 5 $location.onLocationChanged(function(event){ 6 $survey.publish(survey,function(content){ 7 $trace.add(content); 8 $task.finish(); 9 }); 10 },"&((lat >= 0)(lat <= 1)(lon >= 0)(lon <= 1))") Listing 3.5 – Tâche de collecte : Le Citoyen Journalist Qualité Réseau Dans cette application, inspirée de MyExperience [25], nous voulons étudier la corrélation entre la qualité du signal réseau et la qualité de la communication vocale. Dans cette application (cf. listing 3.6), nous voulons montrer deux nouvelles propriétés de notre interface de programmation qui sont i) sa capacité à pourvoir adapter la séquence des questions d’un questionnaire en fonction des premières réponses d’un utilisateur et ii) combiner une collecte opportuniste et participative Dans la première partie du script (ligne 1-6), nous collectons la force du signal réseau GSM lorsque l’utilisateur est en situation de mobilité. Afin d’effectuer un retour sur les données collectées, nous insérons un nouveau point dans la visualisation proposée (ligne 6). Dans la deuxième partie du script (ligne 8-14), nous définissons un questionnaire et ajoutons deux questions relatives à la qualité d’une communication vocale. La première question consiste à demander la qualité de sa communication vocale. La deuxième consiste à lui demander pourquoi le participant a considéré que la communication a été mauvaise. Nous définissons ensuite l’enchaînement des questions (ligne 15-18) qui consiste à proposer uniquement la deuxième question uniquement si l’utilisateur a répondu une réponse spécifique à la première question. Ensuite, nous proposons le questionnaire lorsque l’utilisateur a terminé une communication vocale. 1 $location.onLocationChanged(function(event){ 2 $trace.add({ 3 latlng : [event.latitude,event.longitute], 4 signal : $telephony.signalStrength() 5 }) 6 }) 7 818 var qualitySurvey = $survey.create() 9 qualitySurvey.close("q1", 10 "Quelle a été la qualité de votre communication ?", 11 ["Trés Mauvaise", "Mauvaise", "Moyenne", "Bonne", "Excellente"]) 12 qualitySurvey.close("q2", 13 "Quel a été le probléme ?", 14 ["écho", "grésillement", "voix coupé"]) 15 qualitySurvey.then("q1",function(response){ 16 if (response == "Trés Mauvaise") 17 return "q2" 18 }) 19 20 $phone.onCallFinish(function(event){ 21 $survey.publish(qualitySurvey, function(content){ 22 $trace.add({ 23 latlng : $location.lastLocation(), 24 signal : $telephony.signalStrength(), 25 content : content 26 }) 27 })} Listing 3.6 – Exemple d’application participative Exploiter des capteurs externes Figure 14 – Flux de données de l’expérience Manipulation de Lego NXT Dans cette expérience, nous montrons que notre interface de programmation peut également être utilisée pour interagir avec des capteurs externes, afin de collecter des données qui ne peuvent pas être initialement capturées avec les capteurs initialement inclus dans les dispositifs mobiles. Cette expérience exploite les capteurs intégrés d’un robot Lego Mindstorms NXT (c.-à-d. capteur de contact, d’ultrason, de température et de pression atmosphérique), et permet également d’interagir avec le moteur du robot afin d’en prendre le contrôle à partir de la tâche de collecte. 82Comme le montre la figure 14, l’expérience est composée de deux scripts : NXT.js et Task.js décris par le listing 3.7. Le rôle du premier script est de faire une abstraction avec les différentes fonctionnalités des robots NXT. Ce script communique avec la façade responsable de l’interface Bluetooth, pour établir une connexion avec le robot et le manipuler à distance. Ce script peut être ensuite intégré dans le script Task.js en tant que librairie (ligne 1). Dans cet exemple, nous établissons une connexion avec un robot NXT à proximité (ligne 8), et déclenchons les moteurs du robot pour le faire avancer. Nous réagissons également lorsque le robot rencontre un obstacle pour le faire changer de direction (ligne 11-13). Les lignes (15-22) permettent ensuite de collecter des données capturées par les capteurs du dispositif mobile (par ex. GPS) et des capteurs du robot NXT (c.-à-d. pression atmosphérique et température) lorsqu’il se déplace. 1 var nxt = require("NXT.js"); 2 3 var change_direction = function(){ 4 nxt.move_back() 5 nxt.turn_left({ ’angle’ : 45 * random(), ’duration’ : ’2s’}) 6 nxt.move_forward() 7 } 8 nxt.onConnect({’timeout’: ’30s’},function(){ 9 nxt.move_forward() 10 11 nxt.onTouch(function(){ 12 change_direction() 13 }) 14 15 $location.onLocationChanged({provider : ["network"]},function(event){ 16 $trace.add({ 17 latlng : [event.latitude,event.longitude], 18 pressure : nxt.pressure(), 19 temperature : nxt.temperature() 20 }) 21 }) 22 }) Listing 3.7 – Tâche de collecte : Manipulation de Lego NXT Inférence Contextuelle Dans cette dernière expérience, l’objectif est de montrer que APISENSE® peut également être utilisé pour rapidement prototype et valider empiriquement des algorithmes contextuels. Dans ce scénario, nous voulons mettre en place un modèle d’apprentissage permettant de reconnaître l’activité d’un utilisateur (c.-à-d. assis, debout, marche, courir, monter ou descendre des escaliers). L’idée générale de l’approche est d’observer 83les données transmises par le capteur d’accélération afin de déterminer l’activité de l’utilisateur. Le script décrit dans le listing 3.8 implémente l’algorithme initialement proposé en [37]. 1 var classes = ["walk","jog","stand", "sit", "up", "down"]; 2 var current = 0; var buffer = new Array(); 3 var model = weka.newModel(["avrX","avrY",...], classes); 4 var filter = "|(dx>"+delta+")(dy>"+delta+")(dz>"+delta+")"; 5 6 var input = $accelerometer.onChange(filter, 7 function(acc) { buffer.push(acc) }); 8 9 var learn = time.schedule({ period: ’5s’ }, function(t) { 10 if (model.learn(classes[current]) >= threshold) { 11 current++; 12 } 13 if (current < classes.length) { // Learning phase 14 input.suspend(); 15 var output = $dialog.display( 16 { message: "Select movement", spinner: classes }); 17 model.record(attributes(buffer), output); 18 sleep(’2s’); 19 buffer = new Array(); 20 input.resume(); 21 } else { // Exploitation phase 22 dialog.display({message: "Learning phase completed"}); 23 learn.cancel(); 24 model.setClassifier("NAIVE_BAYES"); 25 time.schedule({ period: ’5s’ }, function(t) { 26 trace.add({ 27 position: model.evaluate(attributes(buffer)), 28 stats: model.statistics() }); 29 buffer = new Array(); 30 } } }); Listing 3.8 – Tâche de collecte : Inférence Contextuelle. Le script se décompose en deux phases : i) une phase d’apprentissage et ii) une phase d’exploitation. Pour réaliser la phase d’apprentissage, nous avons intégré un algorithme d’apprentissage [44] implémenté en Java dans l’intergiciel mobile, et nous avons ajouté une façade pour utiliser ses fonctionnalités à partir du script. Durant la phase d’apprentissage, le script génère une boite de dialogue demandant à l’utilisateur de répéter des mouvements spécifiques. Lorsque l’utilisateur exécute les mouvements demandés, nous enregistrons les données d’accélérations selon les trois axes, et calculons des métriques (c.-à-d. moyenne, l’écart type, etc. ) sur les valeurs obtenues. Ces métriques sont ensuite insérées dans l’algorithme d’apprentissage et le mouvement qui à été effectué. Une fois que suffisamment de données ont été insérées dans le modèle d’apprentissage, le 84Predicted Class Acc (%) Walk Jog Stand Sit Up Down Walk 66 0 4 0 0 0 94,3 Jog 0 21 0 0 0 0 100 Stand 4 0 40 0 0 0 90,9 Sit 0 0 2 83 0 0 97,6 Up stair 0 0 0 0 22 0 100 Down stair 0 0 0 0 0 11 100 Table 8 – Tableau décrivant la qualité du système de classification script passe en phase d’exploitation. Dans cette phase, nous évaluons, toutes les cinq secondes, les métriques des données d’accélération dans le modèle d’apprentissage. Le résultat correspondant au mouvement de l’utilisateur et ensuite sauvegardé avec les statistiques du modèle obtenu pour les reporté sur le serveur. Le tableau 8 reporte la matrice de confusion décrivant la qualité du système de classification obtenue par un utilisateur durant cette expérience. La matrice illustre le nombre de mouvements effectués durant cette expérience, et la haute précision des prédictions obtenues pour chacun des mouvements. Discussion Dans cette sous-section, nous discutons de l’expressivité et la complexité des approches décrites dans l’état de l’art avec APISENSE®. Nous utilisons le nombre de lignes de code pour comparer la complexité avec deux applications de collecte couvrant les deux formes d’acquisition de données qui sont la collecte opportuniste (application Wifi-Bluetooth Scanner) et participative (application Citoyen Journaliste). Le tableau 9 présente le nombre de lignes de code nécessaires pour développer ces applications. Le symbole X signifie que l’application ne peut pas être exprimée et le symbole ? signifie que l’application est réalisable, mais que nous n’avons pas d’information sur le nombre de lignes de code nécessaire avec l’approche concernée. En terme de lignes de code, APISENSE® est beaucoup plus concis (4 lignes) que les approches utilisant le langage déclaratif XML pour concevoir une application. C’est la cas avec MyExperience (27 lignes) et Medusa (45 lignes) pour l’application Citoyen Journaliste. De plus ces deux dernières approches ne supportent la définition d’application de collecte purement opportuniste comme l’application Wifi-Blutooth 85Scanner. Même si la concision de notre code est à peu près similaire à Anonysense (7 lignes de code) et Pogo (6 lignes de code), notre approche comporte de nombreux avantages comparés à ces approches. Par apport à Anonysense, qui utilise un DSL pour le développement des applications, le langage JavaScript nous permet d’avoir une plus grande flexibilité pour concevoir des traitements plus complexes, et surtout nous permet de facilement réutiliser du code déjà existant, comme nous l’avons montré dans l’application présentée en sous-section (cf. 3.5.1). Par rapport à Pogo, utilisant également une interface de programmation basée sur JavaScript, notre interface de programmation supporte les tâches de collecte de données participative qui n’est pas possible avec l’interface proposée par Pogo. La seule approche proposée supportant la collecte opportuniste et participative est PRISM, qui propose le déploiement d’applications de collecte écrites en code natif. Cependant PRISM ne propose pas d’abstraction pour faciliter le développement de ses applications, nécessitant une expertise approfondie en développement mobile. L’application Citoyen Journaliste nécessite par exemple 330 lignes de code. En outre, le développement natif des applications les rend exclusives pour un OS mobile, demandant par conséquent d’étudier et développer une nouvelle version de l’application pour supporter l’hétérogénéité des OS disponible. Nous avons présenté dans cette section un ensemble d’applications réalisables avec APISENSE®. Nous pensons que APISENSE® propose un bon compromis entre toutes les approches proposée dans l’état de l’art, supportant la collecte opportuniste (application Wifi/Blutooth Scanner), participative (application Citoyen Journaliste), ou une combinaison des deux (application Qualité Réseau) tout en fournissant une abstraction complète des technologies mobiles. En proposant une interface de programmation au-dessus de JavaScript, APISENSE® permet également de définir des traitements complexes (application Inférence contextuelle), et faciliter la réutilisation de code déjà existant (application Exploiter des capteurs externes). Nous pensons que la réutilisation est un aspect fondamental pour le succès APISENSE®, favorisant son utilisation par de nombreux acteurs académiques ou industriels, avec des niveaux d’expertises différents dans la collecte de données. En effet, les experts du domaine peuvent proposer des modules ou algorithmes complexes, utilisant les capteurs des dispositifs pour inférer des informations de haut niveau (par ex. activité de l’utilisateur, mode de transport), ou encore utiliser intelligemment les différents capteurs pour réduire la consommation énergétique des applications de collecte dans un contexte spécifique [14]. Ces modules pourront être ensuite réutilisés par des utilisateurs non experts. Et finalement, l’utilisation de JavaScript permet également de supporter l’hétérogénéité des OS mobiles 86Wifi-Blutooth Scanner Citoyen Journaliste APISENSE 4 9 Medusa [55] X 45 MyExperience [25] X 27 Anonysense [62] 5 X Pogo [6] 4 X PRISM [16] ? 330 Table 9 – Comparaison de l’expressivité et du nombre de lignes de code pour s’affranchir d’étudier et développer une nouvelle application pour chaque OS disponible. 3.5.2 Coût énergétique d’une expérience de collecte Dans cette section, nous comparons la consommation énergétique de notre prototype réalisé sur Android avec Funf [1], une application présentée dans l’état de l’art APISENSE® ( section 2.3.1, page 34 ). Nous rappelons que Funf est un outil permettant de générer des applications natives Android à la carte. Pour réaliser cette expérience, nous avons exécuté chaque application durant 24 heures, sur un Nexus-S réinitialisée à une configuration par défaut, pour limiter le bruit qui peut être induit par d’autres applications. Chaque application est configurée pour collecter toutes les 10 minutes des informations de la batterie du dispositif mobile. Le résultat de cette expérience est illustré par la figure 15 Dans cette courbe, l’abscisse représente le temps, et l’ordonnée la tension en millivolt représentant le niveau de la batterie du dispositif. La tension d’un dispositif varie généralement entre 4200 millivolts, représentant 100% de niveau de batterie, et 3200 millivolts. Comparé à une application native (baseline), nous pouvons observer que le surcoût énergétique de notre prototype est faible comparé à une application native, et moins important que celui imposé par Funf. Bien que notre solution soit plus consommatrice qu’une application native, notre solution ne nécessite aucune expertise particulière de la plate-forme Android, et rend également transparent le déploiement de l’application et la propagation des données pour les développeurs. Comme la consommation énergétique dépend fortement de i) la nature de l’expé- rience, ii) du type de capteur utilisé et iii) du volume des données produit, nous avons réalisé une seconde expérience permettant d’estimer l’impact des différents capteurs 87 4100 4120 4140 4160 4180 4200 0 200 400 600 800 1000 1200 1400 Voltage (mV) Time (s) Android Native Application Funf Bee.sense Figure 15 – Impact d’APISENSE sur la consommation énergétique sur la consommation de la batterie (cf. figure 16). Pour cette expérience, nous avons développé trois scripts, qui ont été exécutés séparément sur trois dispositifs mobiles. Le premier script (APISENSE + Bluetooth), déclenche un scan toutes les minutes et collecte le niveau de la batterie aussi bien que le résultat du scan. Le second (APISENSE + GPS) collecte également toutes les minutes les données GPS tandis que le dernier script collecte des données relatives au point d’accès WIFI. Cette expérience démontre que même avec un stress important sur les capteurs, il est possible de collecter des données durant une journée normale de travail sans avoir à recharger le dispositif mobile (40% d’énergie consommée après 10 Heures d’activation du GPS). 3.6 conclusion Le développement d’applications mobiles dédiées à la collecte de données est un processus long et complexe. Généralement, afin de déployer l’application vers un grand nombre d’utilisateurs, plusieurs applications ont besoin d’être développées pour faire face à la diversité des plate-formes mobiles disponibles. D’autre part, ces applications doivent généralement prendre en compte des aspects non fonctionnels tels que la 88 0 20 40 60 80 100 0 100 200 300 400 500 Battery level (%) Time (min) APISENSE APISENSE + GPS APISENSE + Bluetooth APISENSE + WiFi Figure 16 – Impact des capteurs sur la consommation énergétique protection de la vie privée des utilisateurs ainsi que la consommation énergétique de ces applications. Dans ce chapitre, nous avons présenté notre approche pour diminuer le coût lié aux développements d’applications mobiles dédiées à la collecte de données. Plus particulièrement, nous avons présenté dans un premier temps une interface de programmation de haut niveau pour la définition d’une application de collecte. L’interface proposée a été conçue pour i) faire face à la diversité des applications de collecte (i.e. participative, opportuniste), ii) supporter l’hétérogénéité des plate-formes mobiles iii) tout en permettant de s’abstraire de la complexité liée au développement mobile. Nous avons ensuite présenté l’environnement mobile dédié aux utilisateurs en charge de l’exécution de l’interface proposée. Nous avons particulièrement présenté son architecture composée de quatre couches pour i) le déploiement et la propagation des données, ii) permettre aux utilisateurs de contrôler des les données collectées sur leurs dispositifs, iii) l’exécution des applications de collecte et iv) limiter la consommation énergétique liée à l’exécution d’une application de collecte. Dans le chapitre suivant, nous allons présenter l’environnement serveur de notre architecture. 894 C O L L E C T E R É PA RT I E D E D O N N É E S Sommaire 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 4.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 4.1 introduction L’objectif des travaux de cette thèse est de proposer une solution générique, facilitant le développement et le déploiement de campagnes de collecte de données à travers des dispositifs mobiles. Dans le chapitre précédent, nous avons présenté l’environnement mobile de APISENSE®, la plate-forme résultante des travaux de cette thèse. Nous avons proposé un modèle de programmation facilitant le développement d’applications mobiles dédiées à la collecte de données et un intergiciel déployé au préalable sur les dispositifs mobiles, dédié à leurs exécutions. 91Dans ce chapitre, nous présentons notre deuxième contribution concernant l’architecture et l’implémentation de l’environnement serveur de APISENSE®, responsable du déploiement des campagnes de collecte, de la persistance des données ainsi que leurs analyses. Ce chapitre adresse particulièrement deux défis introduit en début de manuscrit, qui sont la généralité de la plate-forme, concernant la capacité de la plate-forme à supporter une grande diversité de campagnes de collecte ainsi que son passage à l’échelle. structure du chapitre La suite du chapitre est organisée comme suit : en section 4.2, nous présentons une vue d’ensemble de l’architecture proposée, et discutons des bénéfices de cette architecture par rapport aux solutions de l’état de l’art. Dans les sections 4.3 et 4.4, nous présentons en détail l’architecture des différentes entités logicielles de APISENSE®, ainsi que les méthodes de conceptions et de modélisations utilisées. Dans le chapitre 4.5, nous proposons une optimisation améliorant le passage à l’échelle du système avant de conclure en section 4.6. 4.2 infrastructure répartie de traitement des données Avant de présenter en détail l’architecture proposée dans ce chapitre, nous présentons ici une vue globale de la plate-forme APISENSE®. La figure 17 donne un aperçu simpli- fié des différentes entités logicielles qui la composent, et leurs principales interactions. L’architecture est principalement composée de trois parties distinctes : un ensemble de nœuds de collecte (DataGathering Node), un serveur central (Central Server) et un ensemble de nœuds mobiles avec une application dédiée installée au préalable par les participants. Nous avons déjà présenté les noeuds mobiles dans le chapitre précédent (cf. 3.4, page 68 ). APISENSE® adopte une architecture décentralisée, où le serveur central est assumé comme le tiers de confiance de la plate-forme. Plus particulièrement, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte, vers les nœuds mobiles du système. Afin de fournir un déploiement adapté (par ex. zone géographique, type de dispositif mobile), le serveur central a besoin de maintenir à jour un ensemble d’informations, sur les dispositifs mobiles disponibles pour exécuter des tâches de collecte. Dans ce contexte, nous supposons que le serveur central est géré par un acteur de confiance, qui peut être une organisation publique, ou une structure de recherche. 92Figure 17 – Vue d’ensemble d’APISENSE® La gestion des campagnes de collecte est assurée par les nœuds de collecte, qui peuvent être dédiés à un ou plusieurs utilisateurs. Typiquement, la gestion d’une campagne de collecte comporte quatre phases : i) définir une tâche de collecte, ii) recruter un sous-ensemble de dispositifs mobiles, iii) assurer la persistances des données collectées (c.-à-d. dans une base de données) lors de l’exécution de la tâche iv), exploiter les données. Pour réaliser ces différentes étapes, un nœud de collecte propose un environnement fournissant un ensemble de services qui peuvent être entièrement configurés par les utilisateurs. La configuration consiste en la sélection de modules implémentant la logique dédiée à la réalisation d’une étape d’une campagne de collecte. Dans ce cadre, les modules proposés peuvent implémenter différentes stratégies selon la nature de la campagne. Par exemple, la phase de collecte peut inclure un modèle particulier d’anonymisation des données pour assurer la confidentialité des participants. Ce choix de conception, séparant les préoccupations du déploiement ainsi que la collecte et l’analyse des données, nous permet de rompre avec le syndrome de l’enfermement propriétaire. Premièrement, en offrant la possibilité aux utilisateurs de déployer leurs nœuds de collecte sur l’infrastructure de leur choix, leur permettant 93ainsi de garder un contrôle total sur les données collectées durant leurs campagnes. Les nœuds de collecte peuvent ainsi être déployés vers une infrastructure publique ou privée, en fonction des préoccupations éthiques ou légales en rapport avec le stockage des données. De plus, les nœuds de collecte des utilisateurs sont complètement isolés les uns des autres, améliorant la sécurité et la disponibilité de leurs environnements, permettant d’effectuer des traitements lourds sur les données collectées sans affecter les autres instances. Et finalement, en gardant une entité centrale (c.-à-d. le serveur central), cela permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter leurs tâches de collecte, s’affranchissant ainsi d’une longue période de recrutement. Après avoir présenté une vue globale de la plate-forme APISENSE®, nous présentons dans la suite de ce chapitre l’architecture et les services fournis par le serveur central (cf. section 4.3), ainsi que les nœuds de collecte (cf. section 4.4). 4.3 architecture du serveur central Comme nous l’avons présenté dans la section précédente, APISENSE® est une plate-forme répartie dédiée aux déploiements et à l’exécution de campagnes de collectes de données. Afin de fournir une plate-forme modulaire, facilement extensible et configurable, APISENSE® est une plate-forme orientée service, utilisant un modèle à composants logiciels pour modéliser les différentes applications serveur qui la composent. Plus spécifiquement, APISENSE® est basée sur le modèle SCA [46], un standard initié par le consortium OASIS, dédié à la modélisation d’architectures tout en étant indépendant des langages de programmation, des protocoles de communication, des langages de description d’interface et des propriétés non fonctionnelles. La figure 18 illustre le modèle SCA du serveur central. Dans SCA, les bases des constructions sont les composants logiciels, qui peuvent offrir des services, ou solliciter d’autres composants via des références. Les services ainsi que les références peuvent être connectés à l’aide de fils (wire en anglais). SCA spécifie un modèle à composants hiérarchiques, laissant la possibilité d’implémenter un composant par un langage de programmation, ou par un ensemble de sous composants. Dans le dernier cas, ces composants sont appelés composite. Afin de supporter l’interaction entre des services distants, SCA spécifie la notion de communication distante (binding), permettant de décrire 94le protocole que le client devra utiliser pour invoquer un service. Dans l’architecture SCA proposée, les composants ParticipantFrontend, GatheringNodeFrontend ScientistFrontend et représentent les points d’entrés pour les différents acteurs qui interagissent avec le serveur central. Ces composants exposent leurs services en tant que ressource REST, accessibles via le protocole HTTP. Plus particulièrement, ces composants fournissent quatre types services nécessaires au fonctionnement du système, dédié à : L’enregistrement des participants : ce service (participant registration) est accessible par les dispositifs mobiles, permettant l’enregistrement d’un nouveau participant volontaire pour exécuter de nouvelles tâches de collecte. L’enregistrement des expériences de collecte : ce service (deploy scripts) est accessible par les nœuds de collecte, et permet aux utilisateurs d’enregistrer de nouvelles expériences de collecte. Le déploiement des expériences de collecte : ces services (list experiment, download script, recruit participants) assurent la propagation des expériences vers les terminaux mobiles. La gestion des nœuds de collecte : ces services (user registration, deploy data gathering node, downloads modules) représentent les points d’entré dans le système pour les utilisateurs voulant créer et configurer un nœud de collecte. Nous présentons dans la suite de cette section les services fournis par ces composants. 4.3.1 L’enregistrement des participants L’enregistrement des participants permet d’informer le serveur central de la présence et de la disponibilité des participants pour exécuter des tâches de collecte. Ce service, fourni par le composant DeploymentService, est invoqué par les nœuds mobiles lors de leurs installations sur les terminaux mobiles des participants. L’inscription inclut des informations statiques sur la configuration matérielle des terminaux des participants, ainsi que des informations confidentielles. Les informations matérielles comprennent le type du terminal (par ex. smartphone, tablette), le système d’exploitation utilisé (par ex. Android, iOS) ainsi que l’ensemble des capteurs embarqués dans le terminal. Les informations confidentielles comprennent par défaut le nom, le prénom et une adresse électronique valide. Cependant, le participant a la possibilité de raffiner ces informations, volontairement, en indiquant des lieux géographiques — à gros grain (par ex. pays, région ou ville) — où il évolue, son statut ainsi que son âge. Ces informations sont ensuite stockées dans une base de données, et serviront 95Figure 18 – Architecture SCA du serveur central lors de la phase de déploiement. Pour des raisons de confidentialité, elles pourront être accessibles uniquement par le serveur central, c’est-à-dire qu’elles ne seront pas accessibles par les nœuds de collecte du système. 4.3.2 L’enregistrement des expériences de collecte Accessible par les nœuds de collecte du système, ce service, fourni par le composant Recruitment, permet l’enregistrement d’une expérience de collecte auprès du serveur central. Cette enregistrement comprend deux catégories d’éléments. La première correspond a un ensemble de fichiers JavaScript définissant la tâche de collecte (cf. section 3.3, page 59 ). La deuxième catégorie définit les propriétés de l’expérience et également ses exigences en matière de déploiement. Ces propriétés sont définies par un ensemble de clés/valeurs utilisant le formalisme JSON. Comme le montre le tableau 10, trois catégories de propriétés sont actuellement supportées : global : définit principalement des informations générales sur l’expérience de collecte. Ces propriétés ne sont pas interprétées par le serveur central, mais 96propriété nom description global name Nom de l’expérience description Description du but de la collecte de données version Version de l’expérience de collecte privacy Description du modèle de protection de la vie privée incentive Description du modèle de récompense nodeurl URL du nœud de collecte de collecte recruitment sensors Liste des capteurs utilisées par la tâche de collecte max_numbers Nombre maximum de participants admis dans l’expé- rience de collecte area Zone globale de collecte (par ex. pays, région, ville) platform Liste de plate-formes mobiles context area Liste de zone géographique. period Liste de période journalière Table 10 – Propriétés définissant une expérience de collecte permettent d’informer les participants sur les objectifs de l’expérience (description), le modèle de confidentialité (privacy) et de récompense (incentive). recruit : permet de définir les participants autorisés à participer à une expérience de collecte. Ces propriétés permettent de limiter le nombre de participants impliqué dans l’expérience (max_numbers), de sélectionner des participants évoluant dans un lieu géographique (area) — à gros grains (par ex. pays, région ou ville) —, disposant d’un terminal ayant les capteurs nécessaires pour l’exécution de la tâche de collecte (sensors) et disposant d’une plate-forme mobile spécifique (platform). context : permet de spécifier le contexte d’exécution de la tâche de collecte une fois propagée vers les terminaux mobiles. Dans ce cadre, les propriétés permettent de spécifier une liste de zones géographiques (area) — région circulaire définie par les coordonnées du centre et un rayon exprimé en mètres —, et une liste de périodes journalières (period) dans lesquelles l’expérience doit s’exécuter. Ces propriétés seront ensuite interprétées par les nœuds mobiles, qui seront responsables de déclencher ou de stopper l’exécution de la tâche de collecte (cf. section 3.4.2, page 72 ). 974.3.3 Déploiement des tâches de collecte Une fois l’expérience enregistrée, deux stratégies principales peuvent être considérées pour propager les tâches de collecte vers les nœuds mobiles des participants [16]. La première approche (push-based) consiste à déployer automatiquement l’expérience de collecte auprès des utilisateurs mobiles. Dans la deuxième (pull-based), le nœud mobile télécharge la tâche de collecte après une action volontaire du participant, ou en effectuant une requête périodiquement vers le serveur pour voir si une nouvelle expérience est disponible [62]. Dans ce cadre le serveur central supportent ces deux approches pour la propagation des tâches de collecte. Approche pull-based La première approche (pull-based) est supportée par les composants Pull, DeploymentService et PropertyMatcher. Dans un premier temps, les participants peuvent accéder au service proposé par le Pull, via leur dispositif mobile, pour récupérer une liste d’expériences mises à disposition par les utilisateurs. Dans ce cadre, le PropertyMatcher détermine les expériences accessibles pour le participant, en faisant la correspondance entre les propriétés de recrutement des expériences, et des informations partagées par le participant lors de son inscription. Des informations générales sont fournies pour chaque expérience accessible, permettant au participant de visualiser le but de l’expérience de collecte, du modèle de confidentialité et de récompense ainsi que les capteurs utilisés lors de son exécution. À partir de ces informations, le participant a alors la possibilité de s’enregistrer à une expérience. Lors de la souscription, un identifiant anonyme est alors généré. Cet identifiant est ensuite envoyé au nœud de collecte ayant initié l’expérience et à l’agent mobile, pour l’avertir d’un nouveau recrutement dans l’expérience. Dans ce cadre, l’identifiant anonyme servira pour toutes les communications entre les nœuds de collecte et les participants, comme lors de la propagation des données. Cela permet en effet aux participants de ne pas révéler leurs identités réelles lors des interactions avec les nœuds de collecte, assurant ainsi une première couche d’anonymisation. Une fois la souscription terminée, l’agent mobile peut alors télécharger la tâche de collecte associée et déclencher son exécution. Approche push-based La deuxième approche (push-based) est supportée par les composants Push, et également par le composant PropertyMatcher. Dans ce cadre, le Push fournit un service, 98accessible par les nœuds de collecte, pour pousser directement une tâche de collecte vers les agents mobiles des participants. Ce processus comprend deux étapes. La première consiste à envoyer un message vers les agents mobiles acceptant ce mode de déploiement, et correspondant aux propriétés de l’expérience. La deuxième étape est ensuite similaire à l’approche présentée ci-dessus, c’est-à-dire composée de la phase de souscription et de téléchargement de la tâche de collecte. Pour établir ce type de propagation, il est nécessaire de supporter des communications dans le sens serveur vers terminaux mobiles. Typiquement, ce type de communication peut être effectué en utilisant des services dédiés, proposés par les fournisseurs des OS mobiles tels que GCM (Google Cloud Messaging) pour Android ou APNs (Apple Push Notification service) pour iOS. Dans ce contexte, le composant PushService est en charge de l’interaction avec ces services pour envoyer des messages vers les terminaux mobiles selon l’OS mobile visé. Indépendamment de l’approche utilisée, le composant Push permet également aux nœuds de collecte de propager des messages aux utilisateurs mobiles s’étant inscrits à leurs expériences. Ces messages peuvent être propagés soit à un participant en particulier, ou alors à l’ensemble des participants ayant souscrits à l’expérience. Deux types de messages peuvent être transmis : update : Message indiquant la disponibilité d’une nouvelle mise à jour de l’expérience. Dans ce cadre, ce message déclenchera le téléchargement de la nouvelle version de l’expérience par les nœuds mobiles. Cela permet de rapidement adapter le comportement de l’expérience une fois déployée. notification : Ces messages permettent aux utilisateurs de notifier l’état d’avancement de l’expérience en cours, en partageant des statistiques globales des données collectées avec tous les participants. 4.3.4 Gestion des nœuds de collecte Les derniers services présentés sont responsables de la création et de la configuration des nœuds de collecte. Un utilisateur voulant évoluer dans APISENSE®, peut se connecter au service géré par le composant DataGatheringRepository via une interface web, et déclencher le téléchargement de leur propre nœud de collecte. Celui-ci pourra ensuite être déployé vers une infrastructure publique ou privée, selon les exigences des utilisateurs. 99Un nœud de collecte peut être téléchargé suivant deux formats : 1. En tant qu’image virtuelle pré-configurée, permettant son déploiement au-dessus d’un environnement virtualisé. Dans ce cadre, l’image virtuelle comprend toute la pile logicielle nécessaire au bon fonctionnement du nœud de collecte. Plus particulièrement, elle est composée d’une distribution Linux, d’une machine virtuelle Java (JVM), d’une base de données MongoDb 1 pour le stockage des données, et FraSCAti responsable de l’exécution des composants SCA du nœud de collecte. 2. En tant qu’archive web (.war), permettant son déploiement directement au-dessus d’un serveur d’application (c.-à-d. Apache Tomcat). Le service fourni par le ComponentRepository propose un ensemble de composants modulaires, dédiés à la configuration d’un nœud de collecte. Les utilisateurs peuvent accéder à ce service via leur nœud de collecte nouvellement déployé, pour télécharger et assembler des composants dans leur nœud de collecte en fonction de la nature des expériences qu’ils veulent mener. Nous présentons ce point plus en détail dans la section suivante. 4.4 architecture des noeuds de collecte Dans la section précédente, nous avons présenté l’architecture et les services fournis par le serveur central de la plate-forme APISENSE®. Dans ce chapitre, nous présentons l’architecture des nœuds de collecte, et plus particulièrement comment nous tirons profit du modèle SCA pour fournir des nœuds de collecte facilement configurables. Les nœuds de collecte sont les entités logicielles de notre système responsables de la gestion des campagnes de collecte des utilisateurs. Nous rappelons qu’une campagne est essentiellement composée de quatre étapes qui consiste : 1. à définir une tâche de collecte via une interface de programmation dédiée, 2. à publier la tâche de collecte auprès du serveur central pour le recrutement des participants, 3. à assurer la persistance des données collectées par les dispositifs, 4. et finalement à analyser et exploiter les données collectées Par ailleurs, une expérience peut également comporter un modèle de protection de la vie privée des participants, ainsi qu’un modèle de récompense. 1. https://www.mongodb.org 100Pour faire face à la diversité des expériences qui peuvent être menées, les nœuds de collecte peuvent être entièrement configurés selon la nature d’une expérience. Cette configuration consiste essentiellement à assembler un ensemble de composants SCA, où chaque composant est responsable de la logique fonctionnelle d’une étape d’une expérience. Dans ce contexte, plusieurs composants peuvent être dédiés à une même étape, représentant la partie variable d’une configuration. Pour guider les utilisateurs dans ce processus d’assemblage, nous avons adopté une approche basée sur l’ingénierie des Lignes de Produits Logiciels (LDPs) [12, 52] (en anglais SPL pour Software Product Line). Typiquement, l’idée est i) de définir un Modèle de Caractéristiques (MC) [32](en anglais FM pour Feature Model) qui capture les caractéristiques communes et les points de variabilité d’une configuration d’une expérience, ii) d’implémenter le MC comme un assemblage de composants SCA et de proposer le MC aux utilisateurs pour leurs permettre de sélectionner les composants selon la nature des expériences qu’ils veulent mener. Dans la suite de cette section, nous présentons le MC dédié à la configuration des expériences de collecte en sous-section 4.4.1, un exemple d’architecture SCA généré et leurs interactions permettant la réalisation d’une campagne de collecte, et nous finissons par présenter le mécanisme d’extension permettant d’adresser les exigences non anticipées. 4.4.1 Modèle de caractèristiques d’une campagne de collecte La notion de Modèle de Caractéristiques (MC), introduite par Kang et al. [32], est une technique de modélisation permettant la description d’un ensemble d’artéfacts réutilisables, qui peuvent être utilisés pour créer une famille de logiciels qui possède des caractéristiques communes, mais exhibant également des différences. Le MC représente ainsi l’ensemble des choix proposés à un utilisateur pour lui permettre de configurer un logiciel spécifique à ses besoins. Typiquement, un MC est spécifié sous forme d’arbre, dont les nœuds représentent les caractéristiques d’un logiciel et les arcs spécifient des liens de composition entre les caractéristiques. Trois catégories de caractéristique peuvent être définies : les caractéristiques obligatoires, les caractéristiques optionnelles et les caractéristiques alternatives. Additionnellement, des règles de composition peuvent être définies, établissant une 101relation entre les caractéristiques. Ces règles peuvent prendre deux formes i) une caractéristique qui nécessite la sélection d’une autre caractéristique (définissant une interdépendance entre les caractéristiques), et ii) la sélection d’une caractéristique peut exclure la sélection d’une autre. Dans notre contexte d’utilisation, nous utilisons cette technique pour modéliser les différents choix proposés aux utilisateurs pour leur permettre de configurer les services d’une campagne de collecte selon les spécificités de celle-ci. La figure 19 illustre le MC dédié à la configuration d’une campagne de collecte. Typiquement, le MC identifie principalement cinq points de variabilités pour i) configurer l’environnement de développement des tâches de collecte (SensingTask Description), ii) choisir un modèle de recrutement des utilisateurs (Recruitment), iii) choisir une série de traitements sur les données collectées avant leurs insertions dans la base de données (OnlineProcessing), iv) spécifier l’indexation des données dans la base de données (Collector), v) exposer des services au-dessus des données collectées (Service). Nous décrivons à présent brièvement ces différents points de variabilités et les caractéristiques actuellement supportées. Figure 19 – Modèle de caractéristiques d’une campagne de collecte 102SensingTask Description Ce premier point de variabilité permet aux utilisateurs de sélectionner l’interface web dédiée aux développements des tâches de collecte vue dans le chapitre précédent (cf. section 3.3). La première interface, définie par la caractéristique CodeEditor, propose un éditeur de code en ligne — avec coloration syntaxique, complétion de code, etc. — permettant le développement des tâches de collecte directement en JavaScript. La deuxième interface, définie par la caractéristique Form, quant à elle, fournit une interface web permettant le développement des tâches à partir d’un formulaire. Le formulaire permet principalement de spécifier le type de données à collecter (par ex. position, accéléromètre, périphérique Bluetooth) avec la fréquence de collecte pour chaque donnée (par ex. toutes les cinq minutes). Après validation du formulaire, un fichier JavaScript est généré à partir des choix effectués par l’utilisateur. Le formulaire permet de rendre accessible le développement des tâches pour des utilisateurs n’ayant aucune expertise en programmation. Cependant, le formulaire limite l’expressivité des tâches qui peuvent être développées, en définissant uniquement des tâches de collecte périodique de données. Nous prévoyons dans des travaux futurs de proposer des métaphores visuelles pour développer des tâches de collecte plus complexes, tout en permettant leur développement par des utilisateurs n’ayant aucune expertise en développement. Certains travaux ont déjà été proposés dans ce sens tels que Scratch [48, 58] ou Alice [15] ou plus récemment App Inventor 2 . Le principe de ces approches consiste à fournir un environnement intuitif, dans lequel on associe des composants visuellement pour définir le comportement d’une application. Recruitment Ce deuxième point de variabilité permet de sélectionner le modèle utilisé pour recruter un sous-ensemble de participants exécutant la tâche de collecte. Dans ce contexte, le recrutement consiste essentiellement à interagir avec les services du serveur central pour déployer la tâche de collecte et assurer sa mise à jour, définir un sous-ensemble de participants autorisés à l’exécuter et son contexte d’exécution. Les deux caractéristiques associées à ce point de variabilité (Individuel et Collaborative) permettent de faire face aux différentes échelles de collecte (cf. section 2.1.2) que sont la collecte personnelle et la collecte communautaire. La caractéristique Individuel propose un modèle simple de recrutement des participants dédié à la collecte personnelle de données, qui a généralement pour objectif de suivre l’activité d’un individu à travers le temps. Nous présentons plus en détail en 2. http://appinventor.mit.edu 103sous-section 4.4.4 ce modèle et les différentes interactions entre les nœuds mobiles, le serveur central et les nœuds de collecte nécessaires. La caractéristique Collaborative propose un modèle principalement dédié à la collecte communautaire de données, qui a généralement pour objectif de surveiller des phénomènes liés à l’environnement des participants (par ex. surveiller la qualité du signal réseau dans la ville de Paris). Nous décrirons plus en détail ce modèle dans la section 4.5. Online Processing Ce point de variabilité permet de définir un ensemble de traitements à effectuer sur les données collectées avant leurs insertions dans une base de données. Les traitements peuvent consister à calculer des statistiques globales sur les données collectées (caracté- ristique Statistique), calculer un modèle d’incitation pour récompenser les participants (point de variabilité Incentive), ou encore effectuer des traitements modifiant les données collectées pour assurer leurs confidentialités (point de variabilité Privacy). Incentive Ce point de variabilité définit le modèle de récompense de l’expérience de collecte. Typiquement, l’incitation peut prendre une grande variété de formes. Par exemple, ré- compenser les participants financièrement [41] pour les données partagées, ou transférer des mécanismes de jeux dans le contexte de la collection de données [69]. Généralement, un modèle de récompense a pour objectif d’augmenter la participation des utilisateurs, et de les motiver à partager des données plus pertinentes pour l’expérience. Actuellement, nous supportons un modèle de récompense [24] basé sur la quantité et la qualité des données partagée par des participants. Ce modèle est également utilisé dans des applications mobiles populaires telles que Waze 3 ou encore Foursquare 4 . Le modèle est basé sur le concept de récompense [69] qui peut prendre deux formes différentes. La première consiste à émuler une compétition, en effectuant un classement entre les participants. Dans ce cadre, le modèle peut être configuré par les utilisateurs, en attribuant des points selon le type de données partagées. Le deuxième permet d’attribuer des badges/trophées, en fonction du nombre de points remportés par les participants. 3. https://www.waze.com 4. https://foursquare.com 104Dans l’application mobile présentée dans le chapitre précédant, plusieurs mécanismes permettent aux participants de contrôler les données qui sont collectées par leur dispositif (cf. chapitre 3 sous-section 3.4.2, page 72 ). Ce mécanisme peut être utilisé par exemple par les participants pour empêcher l’application d’activer le GPS qui consomme beaucoup d’énergie. Dans ce cas, les utilisateurs peuvent contrebalancer l’énergie utilisée par les capteurs, et la sensibilité des données — d’un point de vue vie privée —, en attribuant plus de points selon les données collectées par les participants. Par exemple, le capteur GPS est bien connu pour fournir une grande précision pour déterminer la position d’un utilisateur, mais consomme beaucoup plus d’énergie que la géolocalisation GSM, moins précise. Dans ce contexte, pour inciter les participants à partager leurs capteurs GPS, plus de points peuvent être attribués aux données collectées par le GPS. Privacy Additionnellement, un modèle de confidentialité peut être intégré dans l’expérience de collecte. Dans ce cadre, les composants implémentant ces modèles sont responsables de l’assainissement des données reportées par les participants, avant leurs insertions dans la base de données. Actuellement nous supportons un modèle classique de perturbation [2], consistant à modifier les coordonnées spatiales et temporelles en y ajoutant une perturbation aléatoire. La perturbation est introduite par un bruit gaussien à l’intérieur d’une sphère de rayon r centré sur les coordonnées d’origine. Nous envisageons d’intégrer plusieurs modèles issus de l’état de l’art [11] tels que des modèles de dissimulation spatiale [64, 30, 62]. Collector Ce point de variabilité est responsable de la persistance ainsi que de l’indexation des données collectées dans une base de données. Actuellement, la persistance des données est effectuée avec la technologie MongoDB, une base de données non-relationnelle orientée documents. Dans notre cas d’utilisation, le principal bénéfice de cette technologie est de ne pas imposer un schéma spécifique pour sauvegarder les données. En effet, de nombreux systèmes [25, 22] utilisent des bases de données SQL qui nécessitent la définition de schéma statique pour structurer les données. Ce choix de conception limite alors la réutilisation du système nécessitant la sauvegarde de données ayant une structure non prévue dans le schéma défini au préalable. Dans ce cadre, MongoDB représente une technologie fournissant la flexibilité nécessaire pour faire face à l’hétérogénéité des données qui peuvent être collectées durant les expériences. 105Les données sont sérialisées sous la forme d’un tableau JSON. Dans ce cadre, l’utilisation du formalisme JSON fournit une grande flexibilité aux utilisateurs pour représenter les données, selon le type des capteurs impliqués dans la tâche de collecte. La structure des données est définie par les utilisateurs lors du développement de la tâche de collecte (cf. sous-section 3.3.3). Les métadonnées sont générées par l’application mobile, comportant l’identifiant unique de l’utilisateur — crée par le serveur central lors de l’enregistrement du participant dans l’expérience —, la version de la tâche de collecte ainsi que la date où les données ont été générées. Les utilisateurs ont également la possibilité de compléter ces méta-informations. Dans ce cadre, ces méta-informations peuvent être utilisées pour structurer les données dans la base de données, par exemple indexer les données par jour (caractéristique DateIndex), par utilisateur (caractéristique UserIndex) ou utiliser un index géographique (caractéristique GeoIndex) pour faciliter le traitement des données à caractère géographique. Service Le dernier point de variabilité permet de sélectionner des services responsables d’exposer les données après leurs sauvegardes dans la base de données. Actuellement, nous supportons des composants génériques qui permettent de fournir une interface web donnant un accès à la base de données (caractéristique Query), de visualiser des statistiques sur données collectées sous forme de graphe (caractéristique Chart), visualiser sous forme de carte (caractéristique Map) si l’indexation sélectionnée dans la partie précédente utilise un index géographique, ou alors d’exporter les données dans divers formats (point de variabilité Export) (c.-à-d. CSV, JSON, XML). Dans cette section, nous avons présenté notre approche pour permettre de faire à face à la diversité des campagnes de collecte qui peuvent être menées par les utilisateurs. Pour prendre en compte cette diversité, nous avons proposé de modéliser l’environnement responsable de la gestion d’une campagne comme une famille de produits à l’aide de Modèle de Caractéristique (MC). Le MC présenté permet de définir les points communs et également les différences relatives aux campagnes de collecte. Ces différences peuvent consister à utiliser différents modèles de confidentialité, de recrutement ou d’incitation selon la nature de l’expérience, choisir différentes façons pour développer les tâches de collecte selon le niveau de programmation des utilisateurs ou alors structurer et exposer les données collectées durant la campagne. Ainsi, le MC définit l’ensemble des choix présentés aux utilisateurs pour leur permettre de configurer leurs campagnes de collecte en fonction de leurs exigences. Dans la section 106suivante, nous décrivons comment un nœud de collecte génère un environnement assurant la gestion d’une campagne de collecte à partir des choix effectués par les utilisateurs et comment les utilisateurs peuvent étendre les nœuds de collecte pour faire face à des exigences non anticipées. 4.4.2 Création d’une nouvelle campagne Toutes les caractéristiques initialement introduites dans la section précédente sont associées à un composites SCA. La création d’une nouvelle campagne consiste donc à intégrer et à assembler dans l’architecture initiale du nœud de collecte (cf. figure 20) un ensemble de composite SCA. Dans ce cadre, le MC permet de spécifier l’ensemble des assemblages valides pour générer une nouvelle instance de campagne de collecte. Une fois déployé, un nœud de collecte (cf. figure 20) est composé de quatre composants génériques, dédiés à la création d’une nouvelle campagne : ExperimentManager, WebManager, ModuleManager et le ReconfigurationManager. Figure 20 – Architecture initiale d’un nœud de collecte Le point d’entrée de cette architecture est le composant ExperimentManager. Ce composant est responsable du déclenchement de la génération d’une nouvelle campagne. Pour lancer cette génération, ce dernier composant a besoin de trois informations : i) le nom de la campagne de collecte, ii) une description de l’objectif de la collecte, iii) et l’ensemble des caractéristiques sélectionnées dans le MC par les utilisateurs. La 107création d’une nouvelle campagne peut également s’effectuer à partir d’une interface web fournie par le composant WebManager. La figure 21 montre une vision simplifiée de la génération d’une nouvelle campagne. Figure 21 – Processus de génération d’une architecture SCA Une fois la sélection validée, en fonction des différentes contraintes exprimées dans le MC, le composant ExperimentManager procède alors aux téléchargements des différents composites associés aux caractéristiques sélectionnées, auprès du serveur central via le composant ModuleLibrary. Une fois les composites téléchargés, le composant ExperimentManager exploite alors les capacités d’introspection du moteur d’exécution SCA via le composant ReconfigurationManager pour instancier les composites téléchargés dans l’architecture du nœud de collecte. Par exemple, la figure 22 illustre une nouvelle instance générée à partir de la sélection des caractéristiques suivantes : CodeEditor, Individuel, Badge, Pertubation, userIndex, Query, Export-KML. Cette nouvelle instance expose ainsi de nouveaux services permettant 108Figure 22 – Architecture SCA d’une campagne de collecte 109d’éditer une tâche de collecte associée à la campagne (composant SensingTask :CodeEditor), de déployer cette tâche auprès du serveur central afin de recruter un ensemble de participants (composant Recruitement :Individuel), d’anonymiser et de sauvegarder les données collectées par les participants (composant Privacy :Perturbation et Collector :UserIndex), configurer le mécanisme de récompense (composant Incentive :Ranking) et finalement exploiter les données collecter (composant Service :Query et Service :Export :KML). Nous présentons de manière plus détaillée dans la section suivante comment ces composants interagissent entre eux lors d’une campagne de collecte configurée avec un modèle de recrutement Individuel. L’exécution d’une campagne communautaire sera décrite en section 4.5. 4.4.3 Intéraction entre les composants Après avoir présenté les différents composants logiciels formant le serveur central et les nœuds de collecte de APISENSE®, nous présentons dans cette sous-section leurs interactions. La figure 23 montre un diagramme de séquence illustrant les différents messages échangés entre les acteurs du système (c.-à-d. utilisateurs et participants) et les composants de APISENSE®, lors de l’exécution d’une campagne de collecte personnelle. Comme le montre le diagramme, la réalisation d’une campagne de collecte comporte trois phases : la création de la campagne de collecte (phase 1), le déploiement d’une tâche de collecte vers les dispositifs mobiles des participants (phase 2) et la propagation des données vers un nœud de collecte. (phase 3). phase 1 - création d’une campagne de collecte La création d’une nouvelle campagne de collecte est initiée par un utilisateur à partir de son nœud de collecte. La création de la campagne consiste à sélectionner un ensemble de caractéristiques, appartenant au MC, définissant la configuration de la campagne de collecte. À partir d’une configuration valide, le composant ExperimentManager télécharge les composants SCA associés aux caractéristiques auprès du serveur central et génère une nouvelle instance de la campagne (cf. figure 22). La nouvelle instance est un composite SCA, constitué d’un ensemble de composants qui exposent automatiquement de nouveaux services permettant le développement de la tâche de collecte (composant SensingTask), de la publier (composant Recruitment), de reporter les données collectées par les dispositifs mobiles (composant DataHandler) et de récupérer les données collectées (composant Query). 110Figure 23 – Interaction des composants APISENSE® 111phase 2 - déploiement de la tâche de collecte Une fois les services de la nouvelle campagne de collecte exposés, les utilisateurs peuvent alors développer la tâche de collecte associée à la campagne de collecte via le composant SensingTask, configurer les propriétés de déploiement de la tâche de collecte (cf. section 4.3.2) et la publier auprès du serveur central via le composant Deployment. Une fois publiée, le composant Recruitment du serveur central analyse les propriétés de la tâche de collecte et notifie tous les participants, correspondant à ces propriétés, de la disponibilité d’une nouvelle tâche de collecte est disponible. Les participants volontaires peuvent alors s’y inscrire. Dans ce cas, le dispositif mobile télécharge la tâche de collecte et l’identifiant anonyme généré lors de l’inscription qui est également partagé avec le composant ExperimentManager du nœud de collecte. Une fois téléchargée, la tâche de collecte est alors exécutée sur le dispositif mobile. phase 3 - propagation des données La dernière phase consiste à reporter les données collectées durant l’exécution de la tâche de collecte. Les données sont directement reportées auprès du composant DataHandler du nœud de collecte ayant initié la tâche de collecte. Lors de la propagation des données, l’identifiant anonyme est également envoyé, permettant au nœud de collecte de vérifier si les données proviennent bien d’un utilisateur inscrit à l’expérience. Si l’identifiant est valide, le composant DataHandler fait appel au composant Privacy qui est responsable de l’assainissement des données, avant leur sauvegarde et leur indexation dans la base de données via le composant Collector. Les utilisateurs peuvent alors accéder aux données sauvegardées, exporter les données collectées, et également retourner à la phase 2 afin de modifier le comportement de la tâche de collecte en fonction des résultats observés. Nous venons de décrire l’ensemble des interactions des composants APISENSE® permettant la réalisation d’une campagne de collecte de données. La section suivante présente le mécanisme d’extension de APISENSE® permettant le développement et l’intégration de nouveau composant dans la plate-forme. 4.4.4 Extension des nœuds de collecte En définissant un nœud de collecte comme une application SCA, nous bénéficions aussi de sa modularité pour facilement étendre la plate-forme. Dans cette sous-section, nous présentons comment de nouveaux services peuvent être ajoutés à un nœud de 112collecte. L’ajout d’un nouveau service est effectué à partir d’une archive ZIP, que nous appellerons une contribution. Comme le montre l’exemple illustré par la figure 24, une contribution contient la description d’une caractéristique, associée à un composite SCA, ainsi que l’ensemble des artéfacts implémentant le composite (c.-à-d. code compilé, scripts). La contribution présentée vise donc à ajouter un nouveau service responsable d’exporter les données collectées sous le format KML 5 , un format d’encodage utilisant le formalisme XML destiné à la gestion de l’affichage de données géospatiales dans les systèmes d’information géographique. Dans ce cadre, le premier élément vise à définir la contribution comme une caracté- ristique s’inscrivant dans le MC général présenté en sous-section 4.4.1. La description de la caractéristique définit donc le nœud parent (c.-à-d. caractéristique Export dans l’exemple), identifiant un nouveau point de variabilité, les caractéristiques requises, et le composite SCA associé. Dans cet exemple, le composite définit un nouveau service (c.-à-d. export service), exposé comme une ressource REST. Afin de récupérer les données collectées, le composant déclare une référence vers un composant fournissant un service de requête vers la base de données. Et finalement, le composant, déclare son implémentation comme étant une implémentation en Java. Les nœuds de collecte et le serveur central fournissent un service dédié aux déploiements de nouvelles contributions. Dans ce cadre, un utilisateur peut déployer une contribution directement dans son nœud de collecte, ou directement sur le serveur central pour la partager avec les autres utilisateurs du système. 4.5 campagne de collecte communautaire Dans la section précédente, nous avons présenté les principaux composants des nœuds de collecte et plus particulièrement comment ces composants peuvent être assemblés pour créer des services dédiés à une campagne de collecte spécifique. Nous avons également présenté le premier modèle de recrutement Individuel, où le recrutement est basé uniquement sur les propriétés des participants. Dans cette section, nous décrivons le modèle de recrutement Communautaire. Ce type de campagne, également appelé public sensing dans la littérature [33], consiste à collecter continuellement des données relatives à l’environnement des participants (par ex. bruit ambiant, qualité réseaux, pollution de l’air) dans une zone géographique [47, 63, 50]. 5. https://developers.google.com/kml/documentation 113Figure 24 – Exemple d’extension : Export des données au format KML 114Typiquement, une approche couramment utilisée dans ce type de campagne consiste à impliquer un maximum de dispositifs mobiles dans la collecte de données. Cependant, ces dispositifs collectent périodiquement (c.-à-d. toutes les x secondes) ces données environnementales sans prendre en considération si un autre nœud mobile placé à proximité collecte les mêmes données [27]. Cette approche naïve peut s’avérer inef- ficace principalement pour deux raisons. La première est qu’elle peut impliquer la remontée d’une grande quantité de données similaires, en particulier en milieu urbain ou une forte concentration d’utilisateurs (c.-à-d. situés à proximité) peuvent collecter simultanément ces données identiques. Cela demande par conséquent beaucoup plus de ressources côté serveur pour stocker ces données et les analyser. La seconde est qu’elle implique également une grande perte énergétique des appareils mobiles qui collectent ces données similaires. Récemment, Sheng et al. [59] ont montré qu’effectuer une collaboration entre les dispositifs, en fonction d’un objectif de couverture de la zone à observer, pouvait radicalement diminuer l’énergie consommée par l’ensemble des dispositifs, et par conséquent diminuer également le volume de données transmises sur le serveur. Dans ce cas, les objectifs de couverture définissent uniquement la quantité de données nécessaire pour la campagne, permettant de faire un compromis entre la quantité des données collectées, et le coût énergétique liée à leurs acquisitions. Pour effectuer la collaboration, cette approche fais l’hypothèse que les trajets de chaque appareil mobile est connue à l’avance. À partir de ces trajets, l’algorithme proposé dans cette approche permet d’assimiler les tâches de collecte uniquement aux mobiles capables de couvrir les objectifs de couvertures définis au préalable . Cependant, faire l’hypothèse que la mobilité de chaque appareil mobile est connue à l’avance peut être difficilement appliqué en déploiement réel, dû à la difficulté de prédire les trajectoires des participants [60]. Dans ce contexte, nous présentons dans cette section un modèle de recrutement collaboratif, permettant de coordonner l’exécution des tâches de collecte sans avoir une connaissance au préalable de la mobilité des participants. Le modèle proposé a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. Dans notre architecture, ce modèle est assuré par le composant associé à la caractéristique Collaboration du MC présentée en sous-section 4.4.1. Pour assurer la coordination des tâches, le composant se base sur des propriétés de couverture géographique et temporelle décrites par les utilisateurs, leur permettant de définir seulement la quantité de données nécessaires pour leur 115campagne. Pour définir ces propriétés, ainsi que différentes exigences en relation avec leur campagne, nous proposons une interface de programmation complémentaire à celle présentée dans le chapitre précédent (cf. section 3.3). Dans la suite de cette section, nous présentons tout d’abord l’interface de programmation proposée suivie d’un exemple de campagne de collecte développée avec cette interface. Nous présentons par la suite les différents processus assurant l’exécution ainsi que la coordination des ces campagnes de collecte. 4.5.1 Extension du modèle de programmation Dans cette section, nous présentons l’interface de programmation dédié à la définition de campagne de collecte de données communautaire. La table 11 illustre les principales fonctions proposées par cette interface. Phase Méthode Description Collecte sense(callback : function()) Enregistrement d’une tâche de collecte Recrutement accept(function()) Définition des dispositifs autorisés à exécuter une tâche ranking(function(users)) Classement des dispositifs prioritaires pour l’exécution de la tâche Couverture geoCoverage(bound : Array, coverage : String) Définition des propriétés de couverture géographique timeCoverage(during : Number, every : Number) Définition des propriétés de couverture temporelle duplicate(n : Number) Nombre de dispositifs attribués à une tâche selon les propriétés de couverture. Table 11 – Interface de programmation dédiée à la définition des campagnes de collecte communautaires. Typiquement, la définition d’une campagne de collecte communautaire comprend trois phases : collecte, recrutement, couverture. collecte : La première phase consiste à enregistrer la tâche de collecte qui sera distribuée auprès des nœuds mobiles. La tâche de collecte décrit les données qui doivent être collectées et reportées par les nœuds mobiles (cf. section 3.3, page 59 ). L’enregistrement de celle-ci est effectué en insérant une fonction de rappel 116à la méthode sense. Cette tâche sera ensuite exécutée par les nœuds mobiles lorsqu’ils seront assignés à celle-ci. recrutement : La deuxième phase consiste à définir la stratégie de recrutement des nœuds mobiles. Cette phase permet de filtrer les nœuds mobiles, ou d’en privilégier certains en fonction de leur contexte lors de l’attribution de la tâche de collecte. Par exemple, cela permet de baser le recrutement sur certains attributs (par ex. type de connexion réseaux, vitesse de déplacement), ou de privilégier les nœuds mobiles ayant le niveau de batterie le plus élevé. Le filtrage des nœuds mobiles consiste à enregistrer une fonction de rappel à la méthode accept. Cette fonction sera exécutée par les nœuds mobiles avant l’attribution de la tâche de collecte à un ou plusieurs nœuds. Cette fonction a pour objectif d’observer le contexte du nœud mobile, et définir si celui-ci est autorisé à exécuter la tâche. Dans ce cas, cette fonction doit retourner une liste de propriétés (par ex. niveau de batterie, vitesse de déplacement, qualité du signal réseau), dans le cas contraire, elle doit retourner une valeur nulle. La méthode ranking permet de privilégier certains nœuds mobiles pour exécuter une tâche de collecte, basée sur les propriétés retournées par la méthode accept. couverture : La troisième phase permet de définir les objectifs de couverture temporelle et géographique de la campagne de collecte. Cela permet par exemple de faire un compromis entre le coût énergétique utilisé par l’ensemble de nœuds mobiles, et la quantité de données reportées pendant la campagne. L’objectif de couverture temporelle peut être défini par la méthode timeCoverage, qui prend deux paramètres. Ces deux paramètres permettent de spécifier pendant combien de temps la tâche de collecte doit être exécutée et à quelle fréquence (par ex. exécuter la tâche pendant 30 minutes toutes les heures). L’objectif de couverture géographique peut être défini par la méthode geoCoverage, qui prend également deux paramètres. Ces paramètres permettent de spécifier la zone géographique globale de la campagne et à quelle granularité la tâche de collecte doit être distribuée (par ex. exécuter la tâche dans la ville de Paris tous les 500 mètres). La méthode duplicate permet de définir le nombre de dispositifs attribués à la tâche de collecte en fonction des propriétés de couvertures. Exemple d’application Afin de mieux illustrer le modèle de programmation proposé, nous présentons ici un exemple de campagne de collecte de données. Nous utiliserons également cet exemple comme un fil conducteur tout au long de cette section. Dans cette campagne, décrites par le listing 4.1, nous voulons mettre en place une collecte de 117données permettant d’élaborer une cartographie représentant la qualité des réseaux GSM en fonction des opérateurs des réseaux mobiles dans la ville de Paris. La première phase consiste à enregistrer la tâche de collecte de cette campagne (ligne 2-9). La tâche de collecte consiste à exécuter 10 Ping (Packet INternet Groper) réseaux à une machine distante particulière lorsque le participant a changé de position (ligne 3), et à collecté la latence moyenne des requêtes effectuées (ligne 7), la position de l’utilisateur (ligne 6) ainsi que son opérateur de réseau mobile (ligne 5). La deuxième phase consiste à définir la stratégie de recrutement des utilisateurs. Dans cette phase, nous voulons recruter uniquement les participants disposant d’une connexion de données mobiles (ligne 13). Pour les participants ayant ce type de connexion, nous renvoyons le niveau actuel de leur batterie pour pouvoir privilé- gier l’attribution de la tâches de collecte au participant disposant du niveau de batterie le plus élevé (ligne 18-20). Dans le cas contraire, le participant n’est pas autorisé à exécuter la tâche de collecte. Dans la troisième phase, nous définissons les propriétés de couverture pour optimiser l’énergie utilisée par l’ensemble des dispositifs mobile, et minimiser la quantité de données reportées sur le serveur. Pour cela, nous définissons que la tâche de collecte doit être exécutée au maximum par deux participants (ligne 25) répartis tous les cinqcents mètres dans la ville de Paris (ligne 23), et que la tâche doit être exécutée pendant trente minutes toutes les heures (ligne 24). 1 // phase 1 : définition de la tâche de collecte 2 sense(function() { 3 $location.onLocationChanged(function(event) { 4 $trace.add({ 5 operator : $telephony.operator(), 6 loc: [event.latitude, event.longitude], 7 latency : $network.ping(10,"http://...").average}); 8 })} 9 }) 10 11 // phase 2 : définition de la stratégie de recrutement 12 accept(function(){ 13 if (network.connectionType() != "WIFI"){ 14 15 return {battery : $battery.level()} 16 }else return undefined 17 }) 18 ranking(function(users){ 19 return users.sort("battery").select(); 20 }) 21 22 //phase 3 : définition des objectifs de couverture 11823 geoCoverage([[50.614291,3.13282],[50.604159,3.15239]],"500 m") 24 timeCoverage("30 min","1 H") 25 duplicate(2) Listing 4.1 – Tâche de collecte : Observer la qualité réseau Dans cette section, nous avons présenté le modèle de programmation proposé pour définir des campagnes de collecte supportant la collecte collaborative de données. Nous décrivons dans la suite de cette section comment ces campagnes sont exécutées par les nœuds de collecte. 4.5.2 Coordonner l’exécution des tâches de collecte Dans cette section, nous décrivons le modèle et les algorithmes mis en œuvre pour supporter la coordination des tâches de collecte en fonction des propriétés de couvertures géographique et temporelle. Le principal défi qui doit être adressé pour mettre en œuvre une coordination optimisée est de permettre au nœud de collecte d’avoir une vision aussi précise que possible de la réparation géographique des nœuds mobiles disponibles. Cependant, en utilisant une approche naïve qui consisterait à reporter continuellement la position des dispositifs mobiles vers le serveur ne seraient pas efficace pour plusieurs raisons. Premièrement, cela pourrait engendrer un trafic trop important de messages échangés entre les nœuds mobiles et le serveur, spécialement si de nombreux mobiles sont impliqués dans la campagne. Deuxièmement, cela impliquerait une trop grande consommation énergique des nœuds mobiles, dû à l’activation constante de capteur comme le GPS. Et finalement, classifier les nœuds mobiles en fonction de leur distance les uns par rapport aux autres, en utilisant des algorithmes de clustering [31] par example, entraînerait un surcharge du serveur, spécialement si cette classification doit être effectuée en permanence sur un grand volume de données. Pour adresser ce défi, nous avons adopté pour une approche de virtualisation de capteur, initialement proposée dans les réseaux de capteurs (WSNs). [10]. Typiquement, la virtualisation consiste à rajouter une couche logicielle abstraite, appelée couche virtuelle, composée d’un ensemble de capteurs virtuels, superposée à une couche physique. Un capteur virtuel est une entité logicielle autonome, responsable de gérer le flux de messages entre le serveur et un groupe de capteurs caractérisés par des propriétés communes (par ex. zone géographique, type de capteurs). Dans notre approche, l’idée 119principale est de diviser la zone globale de collecte en plusieurs zone géographiques en fonction des propriétés de couverture géographique de la campagne de collecte. Pour chaque zone, nous attribuons un capteur virtuel qui sera responsable de coordonner l’exécution des tâches entre les nœuds mobiles situé dans sa zone. Dans ce contexte, les nœuds mobiles ont uniquement besoin de partager leur position lorsqu’ils entrent ou sortent de la zone gérée par un capteur virtuel. Le composant responsable de l’exécution des campagnes de collecte communautaire et de la gestion des capteurs virtuels est le composite Recruitment :Collaborative (cf. figure 25). Ce composant est associé à la caractéristique Collaborative du point de variabilité Recruitement dans le modèle de caractéristiques présenté en sous-section 4.4.1. Figure 25 – Composant SCA responsable du recrutement collaboratif Ce composite est constitué des trois composants : i) ScriptEngine responsable de l’exécution du script JavaScript définissant la campagne de collecte, ii) VSManager responsable de la création et la gestion des capteurs virtuels et iii) Deployment responsable d’interagir avec le serveur central pour déployer les scripts auprès des nœuds mobiles. L’exécution d’une campagne communautaire comprend trois phases : i) la phase de génération des capteurs virtuels, ii) la phase de connexion des nœuds mobiles avec les capteurs virtuels, iii) et la phase de coordination de l’exécution des tâches de collecte. Nous décrivons à présent l’ensemble de ces étapes. Phase 1 : Génération des capteurs virtuels L’objectif ici est de générer un ensemble de capteurs virtuels responsables de coordonner l’exécution des tâches de collecte entre les nœuds mobiles. La génération de ces capteurs virtuels est assurée par le composant VSManager. Chaque capteur virtuel est caractérisé par une propriété définissant la zone géographique incluse dans la zone 120globale de collecte des données. La génération de ces capteurs est effectuée à partir de la méthode geoCoverage(bound,coverage) de l’interface de programmation, définissant la zone géographique globale de la collecte (paramètre bound), et la taille de la zone gérée par un capteur virtuel (paramètre coverage). À partir de ces paramètres, le composant VSManager génère et instancie un ensemble de capteurs virtuels, et les distribue pour couvrir l’intégralité de la zone globale de collecte (cf. figure 26). Typiquement, un capteur virtuel est un composite SCA disposant de deux services : composant RegistrationService et CoordinationService. Le premier service est dédié à l’enregistrement des nœuds mobiles. Ce service est exposé en tant que ressource REST, accessible à partir d’une URL générée à partir de la zone géographique dont il est responsable. Dans ce cas, les nœuds mobiles sont responsables de s’enregistrer auprès du capteur virtuel en fonction de leur position. Le deuxième service est responsable d’attribuer une tâche de collecte à un ou plusieurs nœuds mobiles qui se sont enregistrés au préalable. Nous détaillons ces différents points dans les section suivantes. Figure 26 – Distribution des capteurs virtuels Phase 2 : Connexion des appareils mobiles et des capteurs virtuels La deuxième phase consiste à établir une connexion entre les nœuds mobiles et les capteurs virtuels. Pour établir cette connexion, les nœuds mobiles ont tout d’abord besoin de télécharger la tâche de collecte auprès du serveur central. Le déploiement de la tâche de collecte vers le serveur central, assurée par le composant DeploymentService, 121suit le même procédé qui celui présenté en sous-section 4.4.4. Comme le montre la figure 26, la tâche de collecte comporte deux fichiers JavaScript : sense.js correspondant au code JavaScript responsable de la collecte des données (ligne 3-8 dans l’exemple décrit par le listing 4.1), et VSmonitoring.js. Dans un premier temps, seulement le fichier VSmonitoring.js est exécuté. Ce dernier script télécharge dans un premier temps l’ensemble des propriétés des capteurs virtuels générés (c.-à-d. zone géographique et l’URL du service d’enregistrement). À partir de ces propriétés, ce script observe continuellement la position du nœud mobile pour déterminer la présence du nœud mobile se situe dans une zone gérée par un capteur virtuel, et est responsable de l’enregistrement et du dé-enregistrement auprès du capteur virtuel associé. En ce qui concerne la surveillance de la position du nœud mobile, nous utilisons un algorithme couramment utilisé dans la littérature pour déterminer si un dispositif se trouve dans une zone spécifique, tout en minimisant le coût énergétique. Typiquement, l’idée principale derrière est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui, au contraire, consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance entre l’utilisateur et le capteur virtuel le plus proche de sa position actuelle. Phase 3 : Coordonner l’exécution des tâches de collecte Dans cette section, nous présentons l’algorithme utilisé par les capteurs virtuel pour coordonner l’exécution des tâches de collecte entre les nœuds mobiles enregistrés auprès d’un capteur virtuel. Le principal défi dans cette partie est de faire face à la connectivité imprévisible des nœuds mobiles. En effet, on ne peut pas partir du postula que tous les nœuds enregistrés sont réellement disponibles pour exécuter une tâche. De nombreux phénomènes peuvent empêcher les nœuds mobiles d’avertir un capteur virtuel qu’ils ne sont plus disponibles, comme la perte d’un signal réseau, un épuisement complet de la batterie ou tout simplement l’extinction du téléphone mobile par le participant. Pour prendre en considération ces phénomènes, l’idée principale de notre approche consiste à dupliquer le nombre de nœuds mobiles assignés à une tâche de collecte, et à intégrer une phase de demande d’exécution afin d’éviter d’avoir à assigner une tâche à un nœud qui n’a pas annulé son enregistrement au capteur virtuel. 122L’algorithme (cf. algorithme 1) est déclenché périodiquement en fonction des propriétés de couverture temporelle qui peuvent être définies par l’interface de programmation avec la méthode geoCoverage(duration,every). Algorithm 1 Algorithme de coordination des tâches de collecte Require: connectedDevices : List of connected devices activeDevices : List of activated devices t : Time threshold Task(tstart,tend) : Temporal properties of the sensing task duplicate : Maximum number of devices to assign the sensing task if (size(activeDevices) < duplicate) then candidates ⇐ connectedDevices − activeDevices if notEmpty(candidates) then availableCandidates ⇐  broadcastTaskRequestEvent(candidates) repeat receive(Device(id, n)) add(availableCandidates,Device(id, properties)) until timeout t is reached for (i = 0 → (size(activeDevices) − duplicate))) do device ⇐ ranking(availableCandidates) activeDevices ⇐ device + activeDevices availableCandidates ⇐ availableCandidates − device broadcastTaskExecutionRequest(device, tstart, tstop) end for end if end if L’algorithme vérifie tout d’abord si le nombre de dispositifs mobile déjà assigné à une tâche (size(activeDevice)) est inférieur à la propriété de duplication. Dans ce cas, nous définissons une liste candidate comme un ensemble de dispositifs connectés et n’exécutant pas actuellement une tâche de collecte. Pour tous les candidats, un message leur est envoyées avec la fonction de recrutement définie par l’interface de programmation (ligne 12-17 dans l’exemple du listing 4.1), — dans notre exemple, nous voulons recruter uniquement les nœuds mobiles disposant d’une connexion GSM —. Le capteur virtuel attend ensuite un temps t la réponse des dispositifs mobiles. Les nœuds correspondant à la méthode de recrutement répondent ensuite au capteur virtuel avec un ensemble de propriétés indiquant leurs états actuels (par ex. niveau de 123batterie, type de connexion de données). Ces nœuds sont ensuite ajoutés à une liste indiquant leurs disponibilités pour exécuter la tâche de collecte. Ces nœuds sont ensuite classifiés par la méthode ranking. Cette méthode correspond à celle définie par l’interface de programmation (ligne 18-20 du listing 4.1), permettant de privilégier certains nœuds par rapport à leurs propriétés. Dans notre exemple, nous privilégions les noeuds mobiles disposant du niveau de batterie le plus élevé. À la fin du processus, un nouveau message est envoyé aux nœuds mobiles leur demandant d’exécuter la tâche de collecte. Les noeuds mobiles recevant ce message démarrent l’exécution de la tâche de collecte jusqu’à la date définie par tend ou lorsque les nœuds quittent de la zone gérée par le capteur virtuel. Cela permet de réattribuer la tâche de collecte à un autre nœud. À la fin de l’exécution, toutes les données collectées sont ensuite propagées directement sur le nœud de collecte. 4.6 conclusion APISENSE® propose un environnement facilitant la gestion de campagnes de collecte de données. Pour supporter une grande diversité de campagne de collecte, nous avons proposé un modèle permettant de configurer un environnement serveur (c.-à-d. honey) responsable de l’exécution d’une campagne de collecte. Ainsi, ce modèle est utilisé pour configurer les services d’un nœud de collecte en fonction des spécificités des campagnes de collecte. Cette configuration comprends cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. À partir de ce modèle, un nœud de collecte peut être ensuite généré et déployé par les utilisateurs vers une infrastructure qui peut être publique ou privée selon la nature des données collectées. Cela leur permet de garder un contrôle total sur l’infrastructure hébergeant les données collectées durant leurs campagnes. APISENSE® se distingue également par son architecture décentralisée, permettant d’améliorer le passage à l’échelle du système. Son architecture est ainsi composée d’un ensemble de nœuds de collecte organisé autour du serveur central. Concernant le serveur central, son principal objectif est d’assurer le déploiement des tâches de 124collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrée au préalable. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire. L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. La description des contributions de ce manuscrit est à présent terminée. Dans les chapitres suivants, nous présentons les évaluations de la plate-forme APISENSE®. 125Troisième partie Évaluations 1275 P R AT I Q U E S C U LT U R E L L E S E T U S A G E S D E L’ I N F O RM AT I Q U E C O N N E C T É E Sommaire 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 Dans cette partie, nous présentons les évaluations de la plate-forme APISENSE® en deux chapitres. Dans le premier chapitre, nous présentons une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein de l’étude PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Ce chapitre a pour objectif de montrer le gain en terme de coût de développement apporté par notre plate-forme, et également de montrer la faisabilité de notre approche dans un cas réel d’utilisation. Le deuxième chapitre évalue le passage à l’échelle de APISENSE® pour la réalisation de campagne de collecte communautaire. Nous évaluons notamment le gain du modèle de recrutement collaboratif, permettant de faire un compromis entre l’énergie consommée par les dispositifs mobiles et la quantité de données générées tout en gardant une bonne couverture de collecte. 1295.1 introduction Dans la partie précédente de ce manuscrit, nous avons présenté en intégralité APISENSE®, la plate-forme résultante des travaux de cette thèse. Comme nous l’avons déjà évoqué, le principal objectif de cette thèse est d’ouvrir l’accès du Mobile Crowd Sensing à de nombreux acteurs privés ou académiques, en leur permettant de facilement développer et déployer leurs campagnes de collecte de données. Dans ce chapitre, nous présentons une campagne réalisée au sein d’une étude sociologique nommée PRACTIC 1 (Pratiques Culturelles et Usages de l’Informatique Connectée), qui vise à comprendre l’usage des technologies numériques connectées en matière d’habitudes et de routines de consommations culturelle et médiatique. Cette étude a été réalisée par une équipe pluridisciplinaire, composée de deux ingénieurs en informatique pour le développement des scripts de collecte, et deux chercheurs en sciences de l’information et de la communication pour l’interprétation des données collectées. Par le biais de la description de cette étude, nous cherchons tout d’abord à montrer la faisabilité de notre approche pour être utilisée dans un cas réel d’utilisation, et plus particulièrement évaluer le gain en terme de cout de développement apporté par APISENSE®. 5.2 contexte et objectif de l’étude practic Le principe de l’étude PRACTIC est né de notre rencontre avec des chercheurs en sociologie, dans le cadre du projet de l’Observatoire Scientifique de l’Internet 2 initié par INRIA 3 . Un premier objectif de cette collaboration est de voir en quelle mesure les nouveaux mécanismes de collecte de données, comme le Mobile Crowd Sensing, peuvent augmenter les méthodes traditionnelles de la recherche numérique en sciences sociales. En effet, de nos jours, la nouvelle génération des terminaux intelligents comme les tablettes ou les smartphones sont fortement intégrés dans la vie sociale et culturelle des individus. Cette intégration représente de nouvelles opportunités pour les sciences sociales, qui peuvent ainsi collecter massivement et sur le long terme, des données comportementales des individus de manière non intrusive. De plus, cela nous a permis de confronter notre plate-forme à un déploiement réel, et d’être utilisée par des personnes tierces à notre équipe. 1. http ://beta.apisense.fr/practic 2. http ://metroscope.org/ 3. www.inira.fr 130L’étude PRACTIC est composée majoritaire de deux phases. La première est une phase de collecte de données auprès d’un ensemble de participants volontaires, combinant les collectes de données opportuniste et participative (c.-à-d. questionnaire). Dans le cadre de PRACTIC, la confrontation de la collecte opportuniste et participative permet de mesurer l’écart entre la représentation des individus sur l’utilisation de leur smartphone et leur pratique effective. La seconde phase comprend des traitements statistiques sur les données collectées qui aboutiront sur quelques entretiens individuels. Dans ce chapitre, nous décrivons uniquement la première phase de l’étude qui est directement en relation avec la plate-forme APISENSE®. Nous décrivons à présent le développement de cette phase de collecte. 5.3 développement de l’étude practic La phase de collecte a entièrement été développée par APISENSE®, en utilisant son modèle de programmation (cf. chapitre 3 section 3.3) pour la description des données collectées sur les environnements mobiles, et un nœud de collecte déployé sur un serveur privé pour la persistance des données. Cette phase a été développée par un Ingénieur Jeune Diplômé (IDJ) en informatique, intégré pour les besoins de l’étude, qui n’avait aucune compétence particulière en programmation mobile au début du développement. L’application PRACTIC a d’abord connu plusieurs phases de test auprès d’un sous ensemble de participants. Ces différentes itérations ont permis d’identifier certains bugs, et d’ajouter des fonctionnalités non anticipées qui ont permis de consolider APISENSE® et l’enquête. Durant cette phase de test, l’ingénieur en question été responsable de faire la transition entre les exigences des sociologues, et les capacités offertes par notre plate-forme. La figure 27 illustre les principales données collectées par l’application PRACTIC. Un aspect intéressant ici est qu’elle utilise un large éventail des fonctionnalités proposées par APISENSE®. La collecte de données comprend principalement trois parties différentes que sont la collecte opportuniste de données, la collecte participative et les retours utilisateurs, correspondant respectivement à plusieurs scripts de collecte. Nous décrivons à présent brièvement ces différents points, et comparons à la fin de cette section le gain en terme de coût de développement apporté par notre modèle de programmation. 131Figure 27 – Données collectées par l’étude PRACTIC 5.3.1 Collecte opportuniste La première partie vise à collecter la diversité des rythmes de vie ainsi que des usages sociaux ou culturels des dispositifs mobiles. Toutes ces données sont collectées automatiquement par l’application sans nécessiter une intervention des participants. Typiquement, trois types de données sont collectées : Contenu Mobile, Activité de l’utilisateur, et Contexte mobile. Chaque type de données correspond à un script de collecte spécifique. Nous présentons brièvement un exemple simplifié des scripts de collecte développés. Contenu Mobile Le contenu mobile (cf. listing 5.1) vise à identifier des profils culturels des participants en fonction du contenu de leur appareil mobile. Dans le cadre de PRACTIC, la dimension culturelle est vue à deux niveaux : le type des applications mobiles installées (c.-à-d. jeux,divertissement, communication), les genres musicaux des participants. Le listing 5.1 décrit le script de collecte associé. La première partie du script (ligne 1-6) est déclenchée une seule fois lors de la première exécution du script. Dans cette partie, un ensemble de méta-données est collecté comprenant la liste des applications installées (nom, date d’installation, catégorie), et celle des fichiers musicaux présents (nom, artiste, format d’encodage, taille en Ko). La deuxième partie vise à identifier les cycles d’installation et de désinstallation des applications. Cette partie est réalisée 132automatiquement lorsqu’un événement concernant l’installation ou la désinstallation est déclenchée par le système mobile. 1 $schedule.once(function(){ 2 // store media files meta-data 3 $trace.add($media.getAudioFiles()); 4 // store installed applications meta-data 5 $trace.add($app.getLaunchableApplications()); 6 }); 7 8 $app.onAppInstallEvent(function(app){ 9 // store new installed or uninstalled application meta-data 10 $trace.add(app); 11 }); Listing 5.1 – Collecte du contenu mobile Activité utilisateur Cette partie vise à collecter les différents rythmes de vie et d’usages des dispositifs mobiles. Les usages sont principalement séparés en deux catégories correspondant aux usages natifs des téléphones mobiles (c.-à-d. appels et SMS) et les nouveaux usages introduis par la nouvelle génération des terminaux intelligents. Le listing 5.2 décrit l’utilisation de la façade $phone permettant de collecter des données sur les appels et les SMS émis et reçus. Pour des raisons de confidentialité, le contenu des appels et des SMS ainsi que l’identifiant des correspondants ne sont pas accessibles à partir des scripts. Seules la durée des communications ainsi que la taille des SMS sont disponibles. 1 $phone.onCallCompleted(function(call){ $trace.add(call) }); 2 3 $phone.onSMS(function(sms){ $trace.add(sms) }) Listing 5.2 – Collecte des usages natifs des dispositifs mobile La deuxième catégorie, illustrée par le listing 5.4 identifie les sessions d’utilisation des dispositifs. Celles-ci comprennent les sessions générales d’utilisations (écran allumé et éteint) et les sessions d’utilisation des applications. L’identification des sessions générales peut être effectuée par le biais de la façade $screen permettant d’intercepter les événements liés à l’écran du dispositif (lignes 2 et 22). Une session commence lorsque l’événement onScreenOn est déclenché. À la suite de cet événement, le script vérifie toutes les secondes (ligne 5) l’application exécutée en premier plan du dispositif (ligne 6), et collecte une session applicative lorsque l’application détectée est différente de la précédente (lignes 7-20). La session générale se termine lorsque l’événement 133onScreenOff est déclenché, dans ce cas la vérification des applications exécutées en premier plan est annulée (ligne 30), et cela déclenche également une nouvelle collecte de données correspondant à la durée de la session générale (lignes 25-29). 1 var subscription,startSession,subscription,appName,startApp; 2 $screen.onScreenOn(function(screen){ 3 4 startSession = screen.time; 5 subscription = $schedule.every("1 s",function(event){ 6 var currentApp = $app.currentApplicationName(); 7 if (appName != currentApp){ 8 9 appName = currentApp; 10 startApp = event.time; 11 12 // store application session 13 $trace.add({ 14 event : "ApplicationSession", 15 start : startApp, 16 end : event.time, 17 name : appName 18 }); 19 }; 20 }); 21 }); 22 $screen.onScreenOff(function(event){ 23 24 // store screen session 25 $trace.add({ 26 event : "ScreenSession", 27 start : startSession, 28 end : event.time 29 }); 30 subscription.suspend(); 31 }); Listing 5.3 – Collecte des usages des applications mobile Contexte mobile Finalement, la dernière catégorie des données collectées permet de mettre en perspective l’utilisation des applications et leurs contextes (cf. listing 5.4). Cela permet d’identifier par exemple si certaines applications sont utilisées uniquement lorsque le participant se trouve à son domicile ou sur son lieu de travail,ou encore d’observer si la qualité du réseau ou le niveau de batterie influe sur l’utilisation de certaines applications. Cette catégorie comprend les cycles de chargement et le niveau de la batterie (lignes 10-12), le contexte réseau (ligne 7-9) constitué du type de connexion 134de données (c.-à-d. Wi-Fi, 3G/4G), et de la force du signal réseau GSM (lignes 1-6). Pour déterminer si l’utilisateur est en situation de mobilité, le choix a été fait de collecter uniquement les identifiants des antennes cellulaires, qui permettent d’avoir une approximation de la localisation du participant sans entraîner une consommation énergétique supplémentaire de l’application mobile [65]. 1 $telephony.onSignalStrengthChanged(function(signal){ 2 $trace.add({ 3 level : signal.level, 4 cellId : $telephony.cellId() 5 }); 6 }); 7 $network.onNetworkStateChange(function(networkEvent){ 8 $trace.add(networkEvent); 9 }); 10 $battery.onBatteryStateChange(function(batteryEvent){ 11 $trace.add(batteryEvent); 12 }); Listing 5.4 – Collecte des usages des applications mobiles 5.3.2 Collecte participative Le questionnaire vise à collecter des données déclaratives sur l’équipement, les usages et le rapport à la vie privée des participants. Il est composé de 152 questions, dont certaines ne sont pas obligatoires. Par exemple, dans la partie des usages, le fait de ne pas posséder une tablette par exemple permet de ne pas répondre à un sous-groupe de questions. Entre 20 et 30 minutes sont nécessaires pour répondre intégralement au questionnaire. Les questions sont organisées au sein de quatre grandes parties : à propos de vous (16 questions), équipements (36), pratiques culturelles et usage de l’informatique connectée (60) et publicité en ligne et privée (19). Le questionnaire peut être complété à tout moment par les participants à partir de leurs dispositifs. Le listing 5.5 montre une très brève partie du questionnaire développé. Typiquement, les réponses du questionnaire vont être croisées par les sociologues avec les données collectées automatiquement par l’application. 1 var survey = $survey.create("PRACTIC"); 2 // ... 3 var q88 = survey.close("Quel est le lecteur musical que vous utilisez le plus ?",[ 4 "Chaine Hi-Fi / Platine Vinyle", 5 "Baladeur/MP3", 1356 "Smartphone", 7 "L’ordinateur (musique enregistrée sur le disque dur ou CD)", 8 "La radio", 9 "La television (chaines musicales comme MTV)", 10 "Autre lecteur de musique" 11 ]); 12 var q88b = survey.open("Quel autre lecteur utilisez-vous ?"); 13 var q89 = survey.close("Quel est votre maniére d’écoute principale avec votre lecteur ?",[ 14 "Casque audio", 15 "Enceinte/Ampli", 16 "Sans rien" 17 ]); 18 q88.then(function(response){ 19 20 if (response == "Autre lecteur de musique"){ 21 return q88b; 22 } 23 else return q89; 24 }); Listing 5.5 – Extrait du questionnaire PRACTIC 5.3.3 Retour utilisateur La dernière partie des scripts de collecte vise à donner un aperçu aux participants des données collectées. Typiquement, l’objectif de cette partie est d’agir en toute transparence vis-à-vis des participants sur les données qui sont collectées sur leurs dispositifs, et d’apporter un aspect ludique à l’application. L’idée est de permettre aux participants de confronter leur perception de l’utilisation de leur dispositif avec leur usage réel. La figure 28 montre un exemple de retour utilisateur sur la durée totale d’utilisation de son appareil. Cette partie a été développée intégralement en HTML/JavaScript. 5.3.4 Discussions Dans cette section, nous avons décrit l’ensemble des scripts de collecte qui a été nécessaire dans le cas de l’étude PRACTIC. Nous allons maintenant identifier le gain apporté par APISENSE® pour le développement de ce cas d’étude. L’application mobile APISENSE®, responsable du téléchargement, de l’exécution des scripts et de la propagation des données collectées a été développée en utilisant la version 2.3 du SDK de Android. L’application APISENSE® fournit de nombreuses abstractions qui simplifient 136Figure 28 – Exemple de retour utilisateur PRACTIC le développement d’une application de collecte de données. La première permet tout d’abord d’avoir une abstraction complète du SDK Android pour accéder aux données fournies par Android, et intercepter les différents événements internes au dispositif mobile grâce aux façades. Le tableau 12 récapitule les façades qui ont été utilisées pour développer PRACTIC, et leur nombre de lignes de code Java qui ont été nécessaires à leur développement. Au total, ces façades comptent approximativement 6000 lignes de code. Pour les besoins de l’étude, en collaboration avec l’ingénieur responsable du développement de PRACTIC, nous avons dû intégrer deux nouvelles façades pour lister les fichiers musicaux (façade $media) et pour observer les évènements liés à l’écran d’un dispositif (façade $screen). Ces façades peuvent être à présent disponibles pour le développement de nouveaux scripts de collecte. L’application APISENSE® dispose également d’un ensemble de services responsables de l’exécution des scripts de collecte en tâche de fond,d’interagir avec le serveur central d’APISENSE® pour le téléchargement et de la mise à jour des scripts de collecte, d’interagir avec les nœuds de collecte des scientifiques pour propager automatiquement les données collectées, et de contrô- ler les ressources consommées par les scripts de collecte (cf. chapitre 3 section 3.4). Cette partie comporte approximativement plus de 20000 lignes de code. Pour finir, l’application mobile APISENSE® possède également une interface graphique générique destinée aux participants (6000 lignes de code). 137Façade Description LOC $survey Génération et publication d’un questionnaire 1277 $feedback Intégration de visualisation HTML/JavaScript 2144 $network Observation du contexte réseau 259 $telephony Observation du réseau cellulaire 400 $phone Observation des communications 600 $battery Observation des états de la batterie 158 $app Observation des applications 362 $trace Collecte et propagation des données 376 $screen (nouvelle) Observation de l’écran 235 $media (nouvelle) Liste du contenu 210 Table 12 – Façade utilisée pour les besoins de l’application PRACTIC La figure 29 met en évidence le gain en terme de lignes de codes obtenu grâce à APISENSE® par rapport aux scripts développés. Au total, seulement 7 % de codes spécifiques ont eu besoin d’être développés pour l’étude PRACTIC. Les principaux efforts de développement résident dans la description des 150 questions et leurs enchaînements (760 lignes) et dans les interfaces graphiques effectuant un retour sur les données obtenues (1600 lignes). Dans la section suivante, nous présentons le protocole de déploiement de l’application. Figure 29 – Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 1385.4 déploiement de l’étude practic Après avoir présenté dans son ensemble les scripts de collecte de l’étude PRACTIC, nous présentons dans cette section son protocole de déploiement et discutons de la participation à cette étude. 5.4.1 Protocole du déploiement Pour la mise en place de l’étude PRACTIC, un nœud de collecte a tout d’abord été déployé sur un serveur privé des scientifiques. Le nœud de collecte a été configuré pour utiliser un modèle de recrutement individuel, pour indexer les données collectées par utilisateur et pour utiliser un système de classement à point (cf. chapitre 4 section 4.4.1) afin de maximiser la participation des utilisateurs. Pour que les données collectées soient pleinement exploitables par les sociologues, ils ont besoin qu’elles soient collectées au minimum pendant 14 jours par participant, et que celui-ci ait répondu au questionnaire de l’enquête. Dans ce contexte, les points sont attribués de la manière suivante : • 50 points pour les participants ayant installé l’application sur une tablette et un smarpthone, remplis le questionnaire et ayant généré plus de 14 jours de données. • 20 points pour les participants qui ont installé sur un seul appareil (smartphone ou tablette), avec le questionnaire rempli et toujours un minimum de 14 jours de données générées. • 1 point par jour de données générées • 2 points si le questionnaire est rempli Des lots ont été prévus pour récompenser les meilleurs participants comprenant une tablette tactile, un smarpthone, une liseuse ainsi que des disques durs externes et des clés USB. Le nœud de collecte a également été utilisé pour le développement des scripts de collecte ainsi que leurs déploiements auprès d’un serveur central que nous avions au préalablement déployé sur un service Microsoft Azure 4 . Pour des raisons éthiques et légales, l’étude PRACTIC a été soumise et validée par la Commission National de l’Informatique et des Libertés 5 (CNIL). 4. http ://azure.microsoft.com/fr-fr/ 5. http://www.cnil.fr/ 139Les participants intéressés à participer à l’étude PRACTIC doivent tout d’abord télécharger et installer l’application mobile APISENSE® publiée sur le site internet APISENSE® 6 en flashant un QR code. À partir de l’application, les participants pourront alors s’enregistrer auprès de l’étude PRACTIC. L’enregistrement déclenchera automatiquement le téléchargement et l’exécution des scripts de collecte après la validation d’une charte de confidentialité. Un identifiant unique est généré et accordé à chaque participant lors de son inscription. Ce n’est qu’en acceptant de communiquer cet identi- fiant avec les chercheurs qu’ils pourront être identifiés. Nous présentons dans la suite de cette section le niveau de participation à PRACTIC, et discutons des premiers retours de l’expériences. 5.4.2 Participation L’étude PRACTIC s’est déroulée du 10 MARS au 19 Avril 2014. La figure 30 montre le nombre d’utilisateurs inscrits par jour, ainsi que l’accumulation du nombre d’inscriptions durant l’étude. Au total, 88 participants ont été recrutés durant l’étude. Figure 30 – Nombre d’inscriptions par jour à PRACTIC Un aspect intéressant des participants recrutés est la diversité de leurs équipements (cf. figure 31), ce qui nous a permis de tester APISENSE® sur 45 modèles de smartphones différents. Outre le nombre d’inscriptions, le succès de l’étude repose principalement sur le taux de participation des utilisateurs tout au long de l’étude. Pour que les données 6. http://www.apisense.fr 140Figure 31 – Diversité des équipements mobiles d’un participant soient exploitables par les chercheurs, il est nécessaire qu’elles aient été collectées au moins sur une période de 14 jours, et que celui-ci ait répondu au questionnaire de l’application. Figure 32 – Taux de participation à la collecte opportuniste 141Figure 33 – Taux de participation à la collecte participative et opportuniste Sur l’ensemble des participants, comme la montre la figure 32, 48 ont collecté des données plus de 14 jours, 21 de 4 à 13 jours, 13 de 1 à jour 6 qui n’ont collecté aucune donnée. Les participants ayant répondu au questionnaire sont au nombre de 25, et les participants ayant à la fois répondu au questionnaire et collecté au moins 14 jours de données sont au nombre de 12 (cf. figure 34). Ces derniers représentent les cas d’étude concrets pour les scientifiques. Bien que ce nombre soit inférieur à celui escompté au début de l’étude, un point positif des premiers résultats obtenus permet de valider que les dispositifs sont bien au cœur des pratiques de certains participants. La figure 34 par exemple représente le nombre de sessions applicatives, ainsi que leurs durées, sur une période de 40 jours Cette courbe met bien en évidence les différents rythmes des usages d’un participant en particulier, qui utilise son dispositif tout au long de la journée, et qui intensifie son utilisation en fin de journée. Figure 34 – Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 1425.5 conclusion Dans ce chapitre, nous avons présenté un cas réel de campagne de collecte de données développée et déployée avec APISENSE® au sein d’une étude sociologique. Nous avons montré que APISENSE® permettait réduire le temps de développement d’une campagne de collecte en proposant un modèle de programmation permettant de s’abstraire complètement des technologies mobiles. Dans le cas de cette étude, le modèle de programmation a permis d’économiser plus de 90% de code nécessaire à son développement. La campagne développée a été déployée auprès de 88 utilisateurs sur une période d’un mois et demi. 143É VA L U AT I O N D U M O D È L E C O L L A B O R AT I F 6 Sommaire 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 6.1 introduction Dans ce chapitre, notre objectif est de montrer la validité du modèle de recrutement collaboratif présenté dans le chapitre 4 en section 4.5, page 113 qui permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles. Nous rappelons que le but de cette coordination est dans un premier temps de répartir les charges énergétiques entre les dispositifs mobiles durant la campagne de collecte, puis dans un second temps de diminuer la quantité de données propagées vers les nœuds de collecte en limitant la propagation de données dupliquées. La validité du modèle est évaluée sur quatre critères : i) la quantité de données propagées sur les nœuds de collecte, ii) la quantité d’énergie utilisée par les dispositifs mobiles ainsi que iii) le surcoût induit par notre approche pour effectuer la coordination des tâches, iv) la couverture géographique des données obtenues. Pour valider notre modèle, nous avons mené une expérience et développé un environnement de simulation que nous détaillons dans la section suivante. 6.2 mise en place de l’expérience Pour cette évaluation, nous reprenons l’exemple de l’application présentée dans la section 4.5.1 page 116 qui est une version simplifiée d’une collecte de données exposée 145dans LiveLab [61]. L’objectif de cette application est d’utiliser les dispositifs mobiles pour mesurer la qualité des réseaux GSM en milieu urbain. Le listing 6.1 décrit la tâche de collecte associée à cette application qui consiste à exécuter 10 Pings réseaux (Packet INternet Groper) toutes les trente secondes et à collecter la latence moyenne des Pings effectués ainsi que la position du dispositif obtenue avec par GPS. 1 $location.onLocationChanged({period : "30s", provider : "GPS"},function(event) { 2 $trace.add({ 3 loc: [event.latitude, event.longitude], 4 latency : $network.ping(10,"http://...").average}); 5 })} Listing 6.1 – Tâche de collecte : Mesure de la latence réseau Pour évaluer notre approche, nous avons simulé le recrutement des dispositifs suivant un modèle où tous les dispositifs exécutent la tâche de collecte indépendamment les uns des autres, et suivant le modèle collaboratif, où les capteurs virtuels coordonnent l’exécution des tâches de collecte entre les dispositifs mobiles (cf. 4.5.2, page 119 ). Pour une évaluation réaliste et à grande échelle, nous utilisons des traces de mobilités réelles provenant de 10000 taxis équipés de GPS dans la ville de Pékin en Chine [67]. Ces données ont été collectées sur une période d’une semaine allant du 2 au 8 février 2008. Afin d’utiliser ces données, nous avons développé un simulateur illustré par la figure 35. Le simulateur comprend trois composants : un Manager, un ensemble d’Agents et un nœud de collecte (DataGathering Node). agents : Les agents sont responsables de générer le trafic réseau simulant les interactions entre les dispositifs mobiles et le nœud de collecte. Ces interactions sont simulées à partir d’un fichier de mobilité comprenant une série de tuples (date, latitude, longitude) représentant les déplacements d’un taxi à travers le temps. Pour l’expérience, nous avons implémenté deux types d’agents : i) les agents individuels et ii) les agents collaboratifs. Les agents individuels exécutent la tâche de collecte en continu tout au long de l’expérience, c’est-à-dire qu’ils collectent toutes les 30 secondes leur position selon le fichier de mobilité, et propagent l’ensemble des données collectées sur le nœud de collecte toutes les 5 minutes. Quant aux agents collaboratifs, ils s’enregistrent auprès des capteurs virtuels selon leur position à un instant t, et exécutent la tâche de collecte lorsqu’ils ont reçu une demande d’exécution de la part du capteur virtuel. Pour assurer une montée en charge du simulateur, les agents sont répartis auprès de plusieurs machines 146virtuelles hébergées sur la plate-forme Microsoft Windows Azure 1 . Des machines virtuelles de taille Small (A1) 2 sont utilisées, correspondant à un processeur à 1 coeur, 1,75 Go de mémoire et une carte réseau de 100 Mbit/s. datagathering node : Pour la simulation, nous avons déployé un nœud de collecte (cf. section 4.4, page 100 ) sur une machine virtuelle hébergée sur Microsoft Windows Azure. Une machine virtuelle de taille Medium (A2) est utilisée, correspondant à un processeur à 2 coeurs, 3,5 Go de mémoire et une carte réseau de 200 Mbit/s. manager : Ce dernier composant est responsable de répartir les fichiers de mobilité auprès des agents déployées sur les machines virtuelles, et de lancer le début de la simulation afin de synchroniser les agents. Figure 35 – Architecture du simulateur de traces de mobilité Pour les simulations présentées dans la suite de ce chapitre, nous utilisons les données du 3 février 2008 représentant la journée où le plus de données ont été produites. Les tâches de collecte sont déployées dans une zone de collecte de 10 km2 situés dans le centre-ville de Pékin, durant une durée de 30 minutes. 1. http://azure.microsoft.com 2. http://azure.microsoft.com/en-us/pricing/details/virtual-machines 1476.3 résultats Dans cette section, nous présentons les résultats obtenus à travers les différentes expériences menées grâce au simulateur développé. Nous discutons des résultats en fonction de la quantité, de la couverture géographique des données collectées ainsi que de l’énergie utilisée par les dispositifs mobiles durant les expériences et du surcoût engendré par notre approche. Pour évaluer les gains de notre modèle de recrutement, nous avons déployé, à travers le simulateur, la tâche de collecte présentée dans le listing 6.1 suivant trois modèles appelé individual, coll(1000 m), et coll(500 m). individual : dans ce modèle, les dispositifs exécutent la tâche de collecte indépendamment les uns des autres. Ils obtiennent une nouvelle position du GPS toutes les 30 secondes, et exécutent la tâche de collecte lorsque leur position se situe dans la zone de collecte définie. coll(1000 m) : dans ce modèle, l’exécution de la tâche de collecte est coordonnée par les capteurs virtuels déployés dans le nœud de collecte. L’objectif de couverture est fixé tous les 1000 mètres dans la zone de collecte avec 5 dispositifs attribués à la tâche (cf. section 4.5.1). coll(500 m) : ce modèle est identique au précédent sauf que nous avons fait varier l’objectif de couverture tous les 500 mètres dans la zone de collecte. Cela nous permet d’étudier l’impact de la couverture définie sur la quantité de données collectées et sur la consommation énergétique des dispositifs mobiles. 6.3.1 Quantité de données et couverture géographique Tout d’abord, nous comparons la quantité des données collectées. Les courbes illustrées par la figure 36 comparent la quantité de données collectées (en kilobyte) pour les trois tâches de collecte déployées en fonction du nombre de dispositifs. La première tâche, illustrée par la courbe individual, représente la quantité de données lorsque les dispositifs collectent individuellement la tâche de collecte. Les deux suivantes, illustrées par les courbes coll(1000 m) et coll(500 m) représentent les tâches de collecte déployées en utilisant le modèle collaboratif. Nous avons fait varier entre 500 et 10000 le nombre de dispositifs simulés durant cette expérience. Comme le montre cette figure, lorsqu’aucune collaboration n’est effectuée, la quantité de données générées augmente linéairement, allant jusqu’à 12000 KB de données produites pour 10000 dispositifs. En effectuant une collaboration, la quantité de données se stabilise autour des 6000 KB pour 148un objectif de couverture de 500 m2 et 2500 KB pour un objectif de 1000 m2 . Pour 10000 dispositifs, cela représente respectivement une diminution de 50% et 80% de quantité de données propagées vers le serveur. Ce gain s’explique, car lorsque suffisamment de dispositifs se trouvent dans une même zone (par ex. plus de 5 dispositifs dans une zone de 500 m2 pour la tâche coll(500 m)), le capteur virtuel associé à cette zone attribut seulement à 5 dispositifs la tâche de collecte, évitant ainsi aux autres dispositifs de la même zone d’exécuter la tâche de collecte. Figure 36 – Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique Cependant, pour valider notre approche, il est essentiel de comparer la quantité de données avec la couverture réellement obtenue. Pour cela, nous avons mené une deuxième expérience impliquant 10000 dispositifs mobiles, et nous avons observé la couverture géographique obtenue à travers différentes périodes de la journée par rapport à la quantité de données collectées. La couverture est définie par le pourcentage de zone couverte par les données collectées, soit 400 zones de 500 m2 dans la zone de collecte d’une surface de 10 Km2 . La figure 37 illustre le résultat de cette expérience. Dans cette figure, les courbes bleu et verte représentent respectivement la couverture obtenue par les approches individuelle (individual-SP) et collaborative (coll(500 m)- 149SP), et les colonnes rouge (individual-Data) et jaune (coll(500 m)-Data) la quantité de données collectées par ces deux approches. Comme le montre cette figure, la couverture des données obtenue varie tout au long de la journée, pour atteindre un pic à 17 H représentant une forte mobilité des taxis dans la zone de collecte. Ce que nous pouvons observer d’intéressant, c’est que les couvertures obtenues par ces deux approches sont relativement équivalentes, bien que la quantité de données collectées par l’approche collaborative soit toujours inférieure à celle de l’approche individuel. La différence des couvertures obtenues entre les deux approches est due à la mobilité des taxis. En effet, si un taxi se déplace à grande vitesse, celui-ci peut traverser une zone avant que le capteur virtuel associé n’est le temps de lui attribuer une tâche. Cependant, dans cette simulation, la perte de la couverture obtenue ne varie pas au delà des 2%. Figure 37 – Comparaison de la couverture géographique selon différentes périodes de la journée À travers ces deux expériences, nous avons montré que l’approche collaborative que nous avons proposée permet de diminuer la quantité de données propagées vers le serveur tout en gardant une couverture presque similaire à une approche classique. Nous allons maintenant évaluer les gains de cette approche sur la consommation énergétique des dispositifs mobiles. 1506.3.2 Consommation énergétique Pour évaluer l’énergie consommée par les dispositifs mobiles liée au trafic réseau et à l’acquisition de la position par le GPS, nous utilisons deux modèles énergétiques très référencés dans la littérature. Le premier modèle, proposé par Balasubramanian et al. [5], permet de déterminer l’énergie liée à la transmission de données par des réseaux sans fil. Dans le contexte de cette évaluation, nous assumons que toutes les données sont transmises par un réseau 3G. Ce modèle divise l’énergie consommée en trois parties. La première est liée à l’activation de l’interface de communication évaluée à 3,5 Joules. La deuxième est liée à la transmission des données évaluée à 0.025 Joule/KB. Et la dernière est liée au temps que l’interface de communication soit désactivée après la transmission des données. Ce temps est évalué à 12,5 secondes et l’interface consomme 0,62 Joule/s jusqu’à ce qu’elle soit désactivée. Dans le cadre où deux transmissions de données sont effectuées en dessous des 12,5 secondes, l’énergie consommée par cette dernière partie est négligée. Pour le deuxième modèle, nous utilisons celui proposé par Lin et al. [43], qui évalue l’énergie liée à l’acquisition périodique d’une position par le GPS à 1,4 Joules par position obtenue. Les courbes illustrées par la figure 38 comparent la consommation énergétique des trois tâches de collecte déployées dans la première expérience de la section précédente par rapport à la concentration de dispositifs mobiles dans la zone de collecte. L’énergie est donnée en Joule et correspond à la moyenne énergétique consommée par l’ensemble des dispositifs mobiles. Comme attendue, la consommation énergétique de la tâche individuelle (individual) est indépendante de la concentration des dispositifs mobiles, et reste constante autour des 600 Joules en moyenne par dispositif. En revanche, les tâches collaboratives (coll(1000 m) et coll(500 m)) bénéficient de cette concentration croissante en évitant de collecter des données non nécessaires pour atteindre les objectifs de couverture, et ainsi réduire la consommation énergétique moyenne par dispositif. Pour coll(1000 m), le gain sur la consommation énergétique des dispositifs varie entre 43% pour 500 dispositifs et 82% pour 10000 dispositifs, tandis que pour coll(500 m), ce gain varie entre 40% et 70%. Afin de mieux comprendre où le gain énergétique est effectué, les graphiques de la figure 39 montrent la répartition des charges énergétiques consommées durant l’expérience pour les trois tâches individual (a), coll(1000 m) (b) et coll(500 m) (c). Dans cette figure, la partie bleue (Localisation) des colonnes représente la consommation 151Figure 38 – Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte causée par l’acquisition d’une position par le GPS, la partie rouge (Sensing Task) à l’exécution des Pings réseaux (cf. listing 6.1 ligne 4) et la partie orange (VS Messages) aux communications avec les capteurs virtuels. Comme le montre cette figure, le gain de la collaboration sur la consommation énergétique est particulièrement liée à l’acquisition des positions par le GPS. En effet, dans cette approche, les dispositifs ont seulement besoin d’obtenir une position pour déterminer à quel capteur virtuel ils doivent s’enregistrer, permettant à ces dispositifs de réduire la fréquence de l’acquisition d’une nouvelle position si leur vitesse est relativement réduite ou en position statique (cf. section 4.5.2, page 121 ). Cela représente dans cette expérience un gain respectif de 86% et 80% pour les tâches coll(1000 m) et coll(500 m). Dans ce contexte, une grande perte énergétique du modèle de recrutement individuelle s’explique par le fait que même les dispositifs ne se situant pas dans la zone de collecte sont obligés de continuellement activer leur GPS afin de déterminer s’ils sont dans la zone étudiée ou non. En ce qui concerne l’énergie consommée par l’exécution des Pings réseaux, le gain reste limité lorsque peu de dispositifs sont impliqués dans l’expérience. Pour le modèle coll(1000 m), le gain est seulement de 4% et devient négatif pour coll(500 m). Ceci s’explique par le surcoût énergétique engendré par les communications des dispositifs avec les capteurs virtuels. Néanmoins, le gain énergétique s’accroît lorsque plus de dispositifs sont impliqués pour atteindre 81% pour coll(1000 m) et 55% pour le modèle coll(500 m). 152Figure 39 – Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153Comme attendu, ces chiffres montrent que le gain énergétique lié à la coordination des tâches varie selon la concentration des dispositifs mobiles dans la zone de collecte et également des objectifs de couvertures définies. Cependant cela révèle également les limitations du modèle évalué dans ce chapitre. En effet, dans le contexte où la concentration des dispositifs mobiles est trop faible pour permettre une coordination des tâches, notre modèle consommerait plus qu’un modèle classique à cause des communications nécessaires avec les capteurs virtuels. D’autre part, notre modèle reste limité si l’objectif de couverture nécessaire pour la campagne de collecte doit être très élevé (par ex. tous les 50 mètres). Cela engendrerait un trafic réseau trop important, car les dispositifs seraient sens cesse en train de communiquer avec les capteurs virtuels, spécialement dans un cas de forte mobilité. Dans ce contexte, la solution proposée ici reste principalement efficace pour les campagnes de collecte nécessitant une couverture géographique de collecte d’une centaine de mètres ou plus. Quelques exemples de ce type de campagnes sont la mesure de la qualité de l’air [19], ou la mesure de la qualité des réseaux sans fil comme présentés dans ce chapitre [61]. 6.4 conclusion Nous avons présenté dans ce chapitre l’évaluation du modèle de recrutement collaboratif proposé dans APISENSE®. Ce modèle s’appuie sur la forte concentration des dispositifs en milieu urbain pour coordonner l’exécution des tâches de collecte entre ces dispositifs selon un objectif de couverture géographique. Pour évaluer ce modèle, nous avons présenté plusieurs expériences basées sur des traces réelles de mobilités provenant de 10000 taxis. Par le biais des expériences menées, nous avons montré qu’en coordonnant l’exécution des tâches, le modèle proposé comporte principalement deux avantages par rapport à un modèle de recrutement où tous les dispositifs les exécutent de manière indépendante. Les expériences ont montré que notre approche permet dans un premier temps de diminuer la quantité de données propagée sur le serveur de plus de 50% lorsque 10000 dispositifs mobiles sont impliqués, tout en gardant une couverture géographique des données collectées similaire. Nous avons également montré que la coordination des tâches de collecte permettait de diminuer la consommation énergétique de ces dispositifs jusqu’à 70%. 154Dans le prochain chapitre, nous concluons en faisant un bilan des contributions présentées dans ce manuscrit, et discutons des perspectives de développements et de recherches issues des travaux de cette thèse. 155Quatrième partie Conclusion 1577 C O N C L U S I O N Sommaire 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 Ce chapitre, qui finalise la présentation faite au travers de ce manuscrit, s’organise de la manière suivante. La section 7.1 rappelle le contexte dans lequel se sont inscrits les travaux réalisés et la problématique qui en est à l’origine. La section 7.2 résume les contributions décrites dans ce manuscrit. Enfin la section 7.3 définit un ensemble de pistes de recherche et de développement en lien avec les travaux de cette thèse. 7.1 rappel des motivations Le Mobile crowdsensing est une nouvelle alternative exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour la collecte massive de données environnementales ou comportementales de la population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux. Malgré le potentiel du Mobile crowdsensing, les campagnes de collecte réalisées impliquant un grand nombre d’utilisateurs mobiles sont rares et restent principalement développées par des experts. Ceci est particulièrement dû à l’absence de prise en compte d’aspects non fonctionnels des systèmes proposés dédiés au MCS. En effet, réaliser une campagne de collecte impliquant un grand nombre d’utilisateurs mobiles demande de faire face à de nombreux défis. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la 159mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que de faire face à l’hétérogénéité des plate-formes mobiles disponibles (par ex. Android, iOS...). À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisable dans un contexte non anticipé. Ce manque d’approche réutilisable demande généralement de devoir réinventer la roue pour chaque nouveau système, entravant ainsi l’adoption du MCS pour de nombreux acteurs n’ayant pas les compétences, ni le temps de développer un système capable de répondre à leurs exigences. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au MCS pour adresser les limitations actuelles liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. APISENSE® propose un environnement distribué permettant de simplifier le développement et le déploiement de campagnes de collecte de données à travers des utilisateurs mobiles. Nous décrivons dans la section suivante un résumé des contributions décrites dans ce manuscrit. 7.2 rappel des contributions Dans cette section, nous synthétisons nos contributions présentées dans le chapitre 3 et le chapitre 4 au travers de l’implémentation de la plate-forme APISENSE®. 7.2.1 Collecte mobile de données Dans notre première contribution, nous avons tout d’abord proposé un modèle de programmation pour simplifier le développement de tâches de collecte de données (cf. chapitre 3 section 3.3, page 59 ). Pour concevoir ce modèle, nous avons tenu compte de trois propriétés qui sont la portabilité, la généralité, et l’accessibilité. En ce qui concerne la portabilité, nous avons basé notre modèle sur le langage de script JavaScript, qui est facilement exécutable sur de nombreux systèmes d’exploitation des dispositifs mobiles actuels. Pour l’accessibilité, nous avons proposé une interface de programmation simple et efficace fournissant une abstraction complète des technologies mobiles. Et pour la généralité, l’interface a été conçue pour supporter une grande variété d’activités de 160collecte, comprenant la collecte opportuniste et participative (cf. chapitre 2 section 2.1.2, page 26 ). Plus particulièrement, l’interface proposée permet de facilement écouter les changements d’état des capteurs mobiles pour la collecte de données opportuniste, d’interagir avec l’utilisateur mobile pour la collecte de données participative ainsi que définir les stratégies de propagation des données. Nous avons également présenté dans ce chapitre l’architecture de l’environnement mobile (cf. chapitre 3 section 3.4, page 68 ) assurant l’exécution des tâches de collecte. Cette architecture met principalement l’accent sur la sécurité et le respect de la confi- dentialité des participants. Pour atteindre cet objectif, tous les scripts sont exécutés dans un bac à sable dédié. Ainsi, cela nous permet de contrôler tous les accès des scripts vers les capteurs des dispositifs mobiles. Par le biais d’une interface graphique, nous laissons la possibilité aux utilisateurs mobiles de définir des contraintes empêchant toute activité de collecte non désirées. Ces contraintes sont classifiées en quatre catégories : temporelles, géographiques, de ressources consommées et de capteurs utilisés. 7.2.2 Collecte répartie de données Dans cette deuxième contribution, le défi adressé concerne la généralité de la plateforme pour concevoir une grande variété de campagnes de collecte ainsi que son passage à l’échelle. Pour supporter une grande diversité de campagnes de collecte, nous avons proposé un Modèle de Variabilité (MC) [32] (en anglais FM pour Feature Model), capturant les différentes configurations d’une application serveur responsable de la gestion des campagnes de collecte (cf. chapitre 4 section 4.4.1, page 101 ). Cette configuration réside en cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. Ce modèle est ensuite fourni aux utilisateurs pour leur permettre de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. À partir des ces exigences, une application serveur (appelée nœud de collecte) est générée et configurée fournissant un environnement dédié à la gestion des campagnes de collecte des utilisateurs. En ce qui concerne le passage à l’échelle de la plate-forme, nous avons proposé une architecture décentralisée, séparant les préoccupations du déploiement ainsi que de la 161collecte et l’analyse des données (cf. chapitre 4 section 4.2, page 92 ). L’architecture résultante est composée d’un ensemble de nœuds de collecte et d’un serveur central. Dans cette architecture, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrés au préalable. Les nœuds de collecte, quant à eux, fournissent un environnement dédié permettant aux utilisateurs de développer de nouvelles tâches de collecte, de les déployer auprès du serveur central, et d’exploiter les données qui ont été collectées durant l’exécution des tâches de collecte. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire (cf. chapitre 4 section 4.5, page 113 ). L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. 7.3 perspectives Dans cette section, nous présentons un ensemble de pistes de développement et de recherche en lien avec les travaux présentés dans cette thèse. Une première contribution au développement d’APISENSE® serait dans un premier temps de porter l’application mobile sur les divers systèmes d’exploitation mobiles disponibles sur le marché (par ex. iOS, Windows Mobile). Bien que nous avons effectué une preuve de concept de la portabilité de l’application mobile d’APISENSE® sur iOS, le prototype réalisé n’est pas encore opérationnel pour être déployé à grande échelle. 162Concernant la partie serveur de APISENSE®, plusieurs améliorations à court terme peuvent être envisagées. La première concerne la sécurité lors de la propagation des données des dispositifs vers les nœuds de collecte. En effet, actuellement l’emplacement du participant peut être déterminé en identifiant l’adresse IP du point d’accès utilisé pour propager les données, permettant potentiellement d’identifier son domicile même si les données en elles-mêmes ne permettent pas de révéler cette information. Dans ce contexte, une priorité serait d’utiliser des routeurs ou relais spécifiques (par ex. routeur oignon [18]) pour cacher l’adresse IP lors de la propagation des données. Une autre amélioration à court terme serait d’intégrer des outils de visualisation génériques permettant de rapidement explorer les données collectées à travers une Interface web. Par exemple, il serait intéressant d’établir des connexions entre les nœuds de collecte et des services tels que CartoDB 1 ou Google Fusion Tables 2 qui proposent ce type de fonctionnalité. Une autre amélioration serait de supporter le déploiement automatique des nœuds de collecte vers les infrastructures des utilisateurs. Cette tâche reste encore manuelle et peut demander une certaine expertise pour administrer le système responsable de leurs exécutions. Certains travaux dans notre équipe ont déjà été initiés dans ce sens [53, 54] et nous prévoyons de rapidement les intégrer dans APISENSE®. D’autres pistes de développement seraient d’implémenter les différents modèles de protection de la vie privée et de récompense proposés dans la littérature. Dans ce contexte, il serait intéressant de déployer des campagnes utilisant ces différents modèles sur des échantillons de participants, afin d’évaluer leurs impacts sur leurs participations. Nous pensons que APISENSE® peut être une plate-forme idéale pour permettre aux scientifiques travaillant sur ces problématiques pour les aider à mettre au point et valider leurs algorithmes. Bien que le modèle de programmation proposé dans cette thèse fournisse une abstraction complète des technologies mobiles, une expertise en programmation est quand même nécessaire pour le développement des tâches de collecte. Dans ce contexte, il pourrait être intéressant de proposer un niveau d’abstraction encore plus élevé ne nécessitant aucune expertise. Ce niveau d’abstraction peut s’appuyer par exemple sur certains travaux déjà existant comme App Inventor 3 ou Alice [15] qui proposent 1. http://cartodb.com 2. http://tables.googlelabs.com 3. http://appinventor.mit.edu 163des métaphores visuelles pour le développement des applications, ou encore sur le langage naturel. Dans ce contexte, le modèle de programmation que nous avons proposé pourrait être utilisé comme langage pivot avec ce nouveau niveau d’abstraction. Une autre perspective serait de mettre en place des métriques permettant d’évaluer la qualité des données collectées. Très peu de recherche ont encore été menées dans ce sens, bien que cela représente une problématique importante de ce type d’applications. En effet, de nombreux facteurs peuvent influer sur la qualité des données comme le type de matériel utilisé, la mobilité des utilisateurs, etc. En effet, sans connaître le niveau de fiabilité des données, il peut être très difficile de savoir si les données collectées sont représentatives du monde réel ou du comportement des participants. La mise en place de ces métriques pourrait également permettre de mettre en place de nouveaux modèles de recrutement des participants dans les campagnes de collecte. Dans ce contexte, selon les exigences de la campagne, les participants fournissant les données de plus grande qualité pourraient être privilégiés. Dans cette thèse, nous avons particulièrement investi sur le développement d’un système de collecte de données avec APISENSE®. Cependant, la collecte en elle même ne représente qu’une partie des futurs systèmes d’informations se basant sur le pouvoir de la foule pour atteindre une quantité massive de données. De nombreux défis doivent encore être relevés pour traiter ces données, en extraire des comportements complexes et diffuser des informations en temps réel à partir de leurs analyses [68]. Un cas d’utilisation que nous souhaitons investir est l’utilisation du Mobile crowdsensing pour élaborer un système de détection de tremblement de terre. Certaines initiatives ont déjà vu le jour comme le projet Quake-Catcher Network [13], qui permet de recueillir les données issues des capteurs de mouvement présents dans les disques durs des ordinateurs, transformant alors ceux-ci en sismographes. Comme mentionné par Faulkner et al. [23], cette approche peut être complétée en utilisant les accéléromètres intégrés dans les dispositifs mobiles qui peuvent fournir une mesure plus précise et plus complète de la distribution géographique des secousses lors d’un tremblement de terre. Cependant, développer un système fiable, capable d’analyser continuellement les données produites par des centaines de milliers de capteurs, extraire uniquement les informations pertinentes et propager une alerte sismique seulement en quelques secondes restent actuellement un véritable défi. 164B I B L I O G R A P H I E [1] Nadav Aharony, Wei Pan, Cory Ip, Inas Khayal, and Alex Pentland. Social fmri : Investigating and shaping social mechanisms in the real world. Pervasive and Mobile Computing, 7(6) :643–659, 2011. [2] Marc P Armstrong, Gerard Rushton, Dale L Zimmerman, et al. Geographically masking health data to preserve confidentiality. Statistics in medicine, 18(5) :497–525, 1999. [3] Patrick Baier, Frank Durr, and Kurt Rothermel. Psense : Reducing energy consumption in public sensing systems. In Advanced Information Networking and Applications (AINA),26th International Conference on, pages 136–143. IEEE, 2012. [4] Rajesh Krishna Balan, Khoa Xuan Nguyen, and Lingxiao Jiang. Real-time trip information service for a large taxi fleet. In Proceedings of the 9th international conference on Mobile systems, applications, and services, pages 99–112. ACM, 2011. [5] Niranjan Balasubramanian, Aruna Balasubramanian, and Arun Venkataramani. Energy consumption in mobile phones : a measurement study and implications for network applications. In Proceedings of the 9th conference on Internet measurement conference, pages 280–293. ACM, 2009. [6] Niels Brouwers and Koen Langendoen. Pogo, a middleware for mobile phone sensing. In Proceedings of the 13th International Middleware Conference, pages 21–40. Springer-Verlag New York, Inc., 2012. [7] J Burke, D Estrin, M Hansen, A Parker, N Ramanathan, S Reddy, and MB Srivastava. Participatory sensing. In In : Workshop on World-Sensor-Web (WSW’06) : Mobile Device Centric Sensor Networks and Applications, 2006. [8] Iacopo Carreras, Daniele Miorandi, Andrei Tamilin, Emmanuel R Ssebaggala, and Nicola Conci. Matador : Mobile task detector for context-aware crowd-sensing campaigns. In Pervasive Computing and Communications Workshops (PERCOM Workshops), International Conference on, pages 212–217. IEEE, 2013. 165[9] Guanling Chen, David Kotz, et al. A survey of context-aware mobile computing research. Technical report, Technical Report TR2000-381, Dept. of Computer Science, Dartmouth College, 2000. [10] NM Chowdhury and Raouf Boutaba. A survey of network virtualization. Computer Networks, 54(5) :862–876, 2010. [11] Delphine Christin, Andreas Reinhardt, Salil S Kanhere, and Matthias Hollick. A survey on privacy in mobile participatory sensing applications. Journal of Systems and Software, 84(11) :1928–1946, 2011. [12] Paul Clements and Linda Northrop. Software product lines : practices and patterns. 2002. [13] Elizabeth S Cochran, Jesse F Lawrence, Carl Christensen, and Ravi S Jakka. The quake-catcher network : Citizen science expanding seismic horizons. Seismological Research Letters, 80(1) :26–30, 2009. [14] Ionut Constandache, Shravan Gaonkar, Matt Sayler, Romit Roy Choudhury, and Landon Cox. Enloc : Energy-efficient localization for mobile phones. In INFOCOM, pages 2716–2720. IEEE, 2009. [15] Stephen Cooper, Wanda Dann, and Randy Pausch. Teaching objects-first in introductory computer science. In ACM SIGCSE Bulletin, volume 35, pages 191–195. ACM, 2003. [16] Tathagata Das, Prashanth Mohan, Venkata N Padmanabhan, Ramachandran Ramjee, and Asankhaya Sharma. Prism : platform for remote sensing using smartphones. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 63–76. ACM, 2010. [17] Linda Deng and Landon P Cox. Livecompare : grocery bargain hunting through participatory sensing. In Proceedings of the 10th workshop on Mobile Computing Systems and Applications, page 4. ACM, 2009. [18] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor : The secondgeneration onion router. Technical report, DTIC Document, 2004. [19] Prabal Dutta, Paul M Aoki, Neil Kumar, Alan Mainwaring, Chris Myers, Wesley Willett, and Allison Woodruff. Common sense : participatory urban sensing using 166a network of handheld air quality monitors. In Proceedings of the 7th ACM conference on embedded networked sensor systems, pages 349–350. ACM, 2009. [20] Shane B Eisenman, Emiliano Miluzzo, Nicholas D Lane, Ronald A Peterson, GahngSeop Ahn, and Andrew T Campbell. Bikenet : A mobile sensing system for cyclist experience mapping. ACM Transactions on Sensor Networks (TOSN), 6(1) :6, 2009. [21] Patrick Th Eugster, Pascal A Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The many faces of publish/subscribe. ACM Computing Surveys (CSUR), 35(2) : 114–131, 2003. [22] Hossein Falaki, Ratul Mahajan, and Deborah Estrin. Systemsens : a tool for monitoring usage in smartphone research deployments. In Proceedings of the sixth international workshop on MobiArch, pages 25–30. ACM, 2011. [23] Matthew Faulkner, Michael Olson, Rishi Chandy, Jonathan Krause, K Mani Chandy, and Andreas Krause. The next big one : Detecting earthquakes and other rare events from community-based sensors. In Information Processing in Sensor Networks (IPSN), 2011 10th International Conference on, pages 13–24. IEEE, 2011. [24] Zachary Fitz-Walter and Dian Tjondronegoro. Exploring the opportunities and challenges of using mobile sensing for gamification. In Proceedings of the 13th International Conference on Ubiquitous Computing (UbiComp’11) : Workshop on Mobile Sensing, 2011. [25] Jon Froehlich, Mike Y Chen, Sunny Consolvo, Beverly Harrison, and James A Landay. Myexperience : a system for in situ tracing and capturing of user feedback on mobile phones. In Proceedings of the 5th international conference on Mobile systems, applications and services, pages 57–70. ACM, 2007. [26] Sébastien Gambs, Marc-Olivier Killijian, and Miguel Núñez del Prado Cortez. Show me how you move and i will tell you who you are. In Proceedings of the 3rd ACM SIGSPATIAL International Workshop on Security and Privacy in GIS and LBS, pages 34–41. ACM, 2010. [27] Raghu K Ganti, Fan Ye, and Hui Lei. Mobile crowdsensing : Current state and future challenges. Communications Magazine, IEEE, 49(11) :32–39, 2011. [28] Chunming Gao, Fanyu Kong, and Jindong Tan. Healthaware : Tackling obesity with health aware smart phone systems. In Robotics and Biomimetics (ROBIO), 2009 IEEE International Conference on, pages 1549–1554. IEEE, 2009. 167[29] Shravan Gaonkar, Jack Li, Romit Roy Choudhury, Landon Cox, and Al Schmidt. Micro-blog : sharing and querying content through mobile phones and social participation. In Proceedings of the 6th international conference on Mobile systems, applications, and services, pages 174–186. ACM, 2008. [30] Kuan Lun Huang, Salil S Kanhere, and Wen Hu. Preserving privacy in participatory sensing systems. Computer Communications, 33(11) :1266–1280, 2010. [31] Anil K Jain and Richard C Dubes. Algorithms for clustering data. Prentice-Hall, Inc., 1988. [32] Kyo C Kang, Sholom G Cohen, James A Hess, William E Novak, and A Spencer Peterson. Feature-oriented domain analysis (foda) feasibility study. Technical report, DTIC Document, 1990. [33] Wazir Zada Khan, Yang Xiang, Mohammed Y Aalsalem, and Quratulain Arshad. Mobile phone sensing systems : a survey. Communications Surveys & Tutorials, IEEE, 15(1) :402–427, 2013. [34] Donnie H Kim, Younghun Kim, Deborah Estrin, and Mani B Srivastava. Sensloc : sensing everyday places and paths using less energy. In Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems, pages 43–56. ACM, 2010. [35] Stephen F King and Paul Brown. Fix my street or else : using the internet to voice local public service concerns. In Proceedings of the 1st international conference on Theory and practice of electronic governance, pages 72–80. ACM, 2007. [36] John Krumm. A survey of computational location privacy. Personal and Ubiquitous Computing, 13(6) :391–399, 2009. [37] Jennifer R Kwapisz, Gary M Weiss, and Samuel A Moore. Activity recognition using cell phone accelerometers. ACM SigKDD Explorations Newsletter, 12(2) :74–82, 2011. [38] Nicholas D Lane, Shane B Eisenman, Mirco Musolesi, Emiliano Miluzzo, and Andrew T Campbell. Urban sensing systems : opportunistic or participatory ? In Proceedings of the 9th workshop on Mobile computing systems and applications, pages 11–16. ACM, 2008. 168[39] Nicholas D Lane, Emiliano Miluzzo, Hong Lu, Daniel Peebles, Tanzeem Choudhury, and Andrew T Campbell. A survey of mobile phone sensing. Communications Magazine, IEEE, 48(9) :140–150, 2010. [40] Juong-Sik Lee and Baik Hoh. Dynamic pricing incentive for participatory sensing. Pervasive and Mobile Computing, 6(6) :693–708, 2010. [41] Juong-Sik Lee and Baik Hoh. Sell your experiences : a market mechanism based incentive for participatory sensing. In Pervasive Computing and Communications (PerCom), 2010 IEEE International Conference on, pages 60–68. IEEE, 2010. [42] P Lilly. Mobile devices to outnumber global population by 2017. URL http ://tinyurl. com/pbodtus [Accessedon : 2013-08-06]. [43] Kaisen Lin, Aman Kansal, Dimitrios Lymberopoulos, and Feng Zhao. Energyaccuracy trade-off for continuous mobile device location. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 285–298. ACM, 2010. [44] Pengfei Liu, Yanhua Chen, Wulei Tang, and Qiang Yue. Mobile weka as data mining tool on android. In Advances in Electrical Engineering and Automation, pages 75–80. Springer, 2012. [45] Hong Lu, Nicholas D Lane, Shane B Eisenman, and Andrew T Campbell. Bubblesensing : Binding sensing tasks to the physical world. Pervasive and Mobile Computing, 6(1) :58–71, 2010. [46] C Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter F Brown, Rebekah Metz, and Booz Allen Hamilton. Reference model for service oriented architecture 1.0. OASIS Standard, 12, 2006. [47] Nicolas Maisonneuve, Matthias Stevens, Maria E Niessen, and Luc Steels. Noisetube : Measuring and mapping noise pollution with mobile phones. In Information Technologies in Environmental Engineering, pages 215–228. Springer, 2009. [48] David J Malan and Henry H Leitner. Scratch for budding computer scientists. ACM SIGCSE Bulletin, 39(1) :223–227, 2007. [49] Emiliano Miluzzo, Nicholas D Lane, Kristóf Fodor, Ronald Peterson, Hong Lu, Mirco Musolesi, Shane B Eisenman, Xiao Zheng, and Andrew T Campbell. Sensing meets mobile social networks : the design, implementation and evaluation of the 169cenceme application. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 337–350. ACM, 2008. [50] Prashanth Mohan, Venkata N Padmanabhan, and Ramachandran Ramjee. Nericell : rich monitoring of road and traffic conditions using mobile smartphones. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 323–336. ACM, 2008. [51] Min Mun, Sasank Reddy, Katie Shilton, Nathan Yau, Jeff Burke, Deborah Estrin, Mark Hansen, Eric Howard, Ruth West, and Péter Boda. Peir, the personal environmental impact report, as a platform for participatory sensing systems research. In Proceedings of the 7th international conference on Mobile systems, applications, and services, pages 55–68. ACM, 2009. [52] Klaus Pohl, Günter Böckle, and Frank Van Der Linden. Software product line engineering : foundations, principles, and techniques. Springer, 2005. [53] Clément Quinton, Romain Rouvoy, and Laurence Duchien. Leveraging feature models to configure virtual appliances. In Proceedings of the 2nd International Workshop on Cloud Computing Platforms, page 2. ACM, 2012. [54] Clément Quinton, Nicolas Haderer, Romain Rouvoy, and Laurence Duchien. Towards multi-cloud configurations using feature models and ontologies. In Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds, pages 21–26. ACM, 2013. [55] Moo-Ryong Ra, Bin Liu, Tom F La Porta, and Ramesh Govindan. Medusa : A programming framework for crowd-sensing applications. In Proceedings of the 10th international conference on Mobile systems, applications, and services, pages 337–350. ACM, 2012. [56] Kiran K Rachuri, Mirco Musolesi, Cecilia Mascolo, Peter J Rentfrow, Chris Longworth, and Andrius Aucinas. Emotionsense : a mobile phones based adaptive platform for experimental social psychology research. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 281–290. ACM, 2010. [57] Sasank Reddy, Deborah Estrin, Mark Hansen, and Mani Srivastava. Examining micro-payments for participatory sensing data collections. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 33–36. ACM, 2010. 170[58] Mitchel Resnick, John Maloney, Andrés Monroy-Hernández, Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, Jay Silver, Brian Silverman, et al. Scratch : programming for all. Communications of the ACM, 52 (11) :60–67, 2009. [59] Xiang Sheng, Jian Tang, and Weiyi Zhang. Energy-efficient collaborative sensing with mobile phones. In INFOCOM, 2012 Proceedings IEEE, pages 1916–1924. IEEE, 2012. [60] Xiang Sheng, Xuejie Xiao, Jian Tang, and Guoliang Xue. Sensing as a service : A cloud computing system for mobile phone sensing. In Sensors, 2012 IEEE, pages 1–4. IEEE, 2012. [61] Clayton Shepard, Ahmad Rahmati, Chad Tossell, Lin Zhong, and Phillip Kortum. Livelab : measuring wireless networks and smartphone users in the field. ACM SIGMETRICS Performance Evaluation Review, 38(3) :15–20, 2011. [62] Minho Shin, Cory Cornelius, Dan Peebles, Apu Kapadia, David Kotz, and Nikos Triandopoulos. Anonysense : A system for anonymous opportunistic sensing. Pervasive and Mobile Computing, 7(1) :16–30, 2011. [63] Sebastian Sonntag, Lennart Schulte, and Jukka Manner. Mobile network measurements-it’s not all about signal strength. In Wireless Communications and Networking Conference (WCNC), 2013 IEEE, pages 4624–4629. IEEE, 2013. [64] Latanya Sweeney. k-anonymity : A model for protecting privacy. International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 10(05) :557–570, 2002. [65] Emiliano Trevisani and Andrea Vitaletti. Cell-id location technique, limits and benefits : an experimental study. In Mobile Computing Systems and Applications (WMCSA). Sixth IEEE Workshop on, pages 51–60. IEEE, 2004. [66] Yu Xiao, Pieter Simoens, Padmanabhan Pillai, Kiryong Ha, and Mahadev Satyanarayanan. Lowering the barriers to large-scale mobile crowdsensing. In Proceedings of the 14th Workshop on Mobile Computing Systems and Applications, page 9. ACM, 2013. [67] Jing Yuan, Yu Zheng, Xing Xie, and Guangzhong Sun. Driving with knowledge from the physical world. In Proceedings of the 17th ACM SIGKDD international conference on Knowledge discovery and data mining, pages 316–324. ACM, 2011. 171[68] Arkady Zaslavsky, Charith Perera, and Dimitrios Georgakopoulos. Sensing as a service and big data. arXiv preprint arXiv :1301.0159, 2013. [69] Gabe Zichermann and Christopher Cunningham. Gamification by design : Implementing game mechanics in web and mobile apps. " O’Reilly Media, Inc.", 2011. 172173 Contributions `a la v´erification et `a la validation efficaces fond´ees sur des mod`eles Alo¨ıs Dreyfus To cite this version: Alo¨ıs Dreyfus. Contributions `a la v´erification et `a la validation efficaces fond´ees sur des mod`eles. Computation and Language. Universit´e de Franche-Comt´e, 2014. French. HAL Id: tel-01090759 https://hal.inria.fr/tel-01090759 Submitted on 4 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse de Doctorat é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s U N I V E R S I T É D E F R A N C H E - C O M T É n Contributions à la vérification et à la validation efficaces fondées sur des modèles Aloïs DREYFUSThèse de Doctorat é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s U N I V E R S I T É D E F R A N C H E - C O M T É THÈSE présentée par Aloïs Dreyfus pour obtenir le Grade de Docteur de l’Université de Franche-Comté Spécialité : Informatique Contributions à la vérification et à la validation efficaces fondées sur des modèles Unité de Recherche : FEMTO-ST DISC Soutenue le 22/10/2014 devant le Jury : Pierre-Cyrille Heam ´ Directeur de thèse Professeur à l’Université de Franche-Comté Olga Kouchnarenko Directrice de thèse Professeur à l’Université de Franche-Comté Ioannis Parissis Rapporteur Professeur à Grenoble INP Pierre Rety ´ Rapporteur Maître de Conférences HDR à l’Université d’Orléans Pascal Poizat Examinateur Professeur à l’Univ. Paris Ouest Nanterre La Défense N ◦ X X XRemerciements J’aimerais tout d’abord remercier mes encadrants et mentors, Olga et Pierre-Cyrille, qui m’ont fait confiance, soutenu et conseillé pendant 6 ans (2 ans en tant qu’ingénieur, puis 4 ans pour mon doctorat). Lorsque mon moral et ma motivation étaient en berne, au point que l’idée folle de jeter l’éponge a parfois effleuré mon esprit fatigué, vous avez su trouver quoi dire et/ou quoi faire pour m’encourager et m’aider à rester dans la course. Je remercie vivement les membres du jury, qui ont accepté d’évaluer mon travail de thèse et plus particulièrement les rapporteurs, Ioannis Parissis et Pierre Réty, qui ont en plus accepté la tâche conséquente de lire, comprendre et critiquer ce mémoire. Je tiens ensuite à remercier mes parents Pierrette et Laurent, ainsi que ma grande soeur Fanny et mon petit frère Chouch, pour leur sempiternel et inconditionnel soutien. J’ai de la chance de vous avoir, et je ne vous dirai jamais assez à quel point je vous aime ♥♥♥♥. Je remercie de même Nico et le loulou, pour tout le bonheur que vous apportez à notre famille depuis que vous en faites partie. Je remercie également celles et ceux qui m’ont aidé à tenir jusqu’au bout, parfois peut-être sans même s’en rendre compte. Je pense particulièrement à Cyber, Tcharlz, Nesnours, @ngel, Fouad, Oscar, Aydeé, Richard, Justine, Lysiane et Anne-Sorya. Et je ne voudrais surtout pas oublier de remercier ma soupape de décompression dijonnaise : Cyber, Anne-Sophie, Chloé, ainsi que Féfé et Jean-Marc, pour votre hospitalité, nos délires et nos discussions, qui m’ont fait un bien fou quand j’avais le moral dans les chaussettes ! Puis j’aimerais remercier mes compagnons de galère : Jibouille, Éric, Abdallah, Hamida, Hadrien, Doudou, P.C., Kalou, Jérôme, Oscar, Séb, Mathias, Roméo, Kerkouette, Sékou, Alexandru, Julien, Lionel, Ivan, Youssou, Bety, Nicolas, Jean-Marie, Fouad, Alexander, Vincent H., Rami, John, Guillaume, Lemia, David, Valérie, Naima, Paco, Sarga, Alban, Aydeé, Yanbo, Régis, Lamiel, Elena et Alexandre, pour l’ambiance agréable et conviviale qui rend les levers du matin plus faciles (ou moins difficiles, c’est selon). Je souhaite bon courage et bon vent à ceux qui rament en ce moment même. Il reste encore tellement de monde (amis, cousins, collègues, . . .) que j’apprécie vraiment et qui méritent que je les remercie, qu’il est clair que je ne pourrai pas être exhaustif. Donc j’espère que celles et ceux que je n’ai pas cités ne m’en tiendront pas rigueur.Sommaire I Introduction 15 1 Prologue 17 1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.4 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 Préliminaires théoriques et notations 21 2.1 Automates et langages réguliers . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.1 Mots et langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.2 Automates finis et expressions régulières . . . . . . . . . . . . . . . . . 21 2.1.3 Produit d’automates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.4 Isomorphisme d’automates . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.5 Réduction d’un automate . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.1.6 Transducteurs lettre à lettre finis . . . . . . . . . . . . . . . . . . . . . . 26 2.1.7 Appliquer un transducteur à un automate . . . . . . . . . . . . . . . . . 27 2.1.8 Appliquer un transducteur à un langage . . . . . . . . . . . . . . . . . . 28 2.2 Grammaires algébriques et automates à pile . . . . . . . . . . . . . . . . . . . . 28 2.2.1 Grammaires algébriques . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.2 Automates à pile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.3 Génération aléatoire uniforme d’un arbre de dérivation dans une grammaire 31 2.2.4 D’un NPDA vers une grammaire algébrique . . . . . . . . . . . . . . . . 33 II Approximations régulières pour l’analyse d’accessibilité 35 3 Contexte et problématiques 39 3.1 Introduction et énoncé du problème . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 Technique proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3 Calcul de la sur-approximation . . . . . . . . . . . . . . . . . . . . . . . . . . . 43SOMMAIRE 8 3.4 Raffinement d’approximations . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Contribution : Critères de fusion syntaxiques 49 4.1 In et Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Left et Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3 Combinaisons de fonctions d’approximation . . . . . . . . . . . . . . . . . . . . 53 4.4 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5 Contribution : Fonction d’approximation qui utilise les états du transducteur 55 5.1 Définitions supplémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2 Critère de fusion qui utilise les états du transducteur . . . . . . . . . . . . . . . . 58 5.3 Raffiner les approximations qui utilisent les états du transducteur . . . . . . . . . 61 5.4 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6 Conclusion de la partie II 67 III Combiner génération aléatoire et critère de couverture, à partir d’une grammaire algébrique ou d’un automate à pile 69 7 Contexte et problématiques 73 7.1 Le test logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1.1 Test automatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1.2 Test à partir de modèles (MBT) . . . . . . . . . . . . . . . . . . . . . . 74 7.1.3 Critères de couverture . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.1.4 Test aléatoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.1.5 Génération aléatoire-uniforme d’un chemin dans un graphe fini . . . . . 75 7.1.6 Test à partir de modèles à pile . . . . . . . . . . . . . . . . . . . . . . . 76 7.2 Où se situe-t-on ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.2.1 Génération aléatoire de chemins contre parcours aléatoire . . . . . . . . 77 7.2.2 Combiner génération aléatoire et critères de couverture . . . . . . . . . . 78 7.2.3 Modèles réguliers (sans pile) contre modèles algébriques (à pile) . . . . . 80 7.2.4 Contribution : Combiner génération aléatoire et critères de couverture, dans des modèles à pile . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 8 Contribution : Application sur les grammaires 83SOMMAIRE 9 8.1 Calculer pX,n et pX,Y,n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.2 Calculer |EX,n(G)| et |EX,Y,n(G)| . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 9 Contribution : Application sur les automates à piles 91 9.1 Génération aléatoire-uniforme de DFA-Traces cohérentes . . . . . . . . . . . . . 93 9.1.1 Génération aléatoire de DFA-traces cohérentes . . . . . . . . . . . . . . 93 9.2 Critères de couverture d’un PDA . . . . . . . . . . . . . . . . . . . . . . . . . . 94 9.2.1 Le critère Tous les états . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 9.2.2 Le critère Toutes les transitions . . . . . . . . . . . . . . . . . . . . . . 95 9.2.3 Combiner test aléatoire et critères de couverture . . . . . . . . . . . . . . 97 9.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 9.3.1 Information technique . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.3.2 Exemple illustratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.3.3 Exemple illustratif pour les critères de couverture . . . . . . . . . . . . . 101 9.3.4 Temps d’exécution sur plus d’exemples . . . . . . . . . . . . . . . . . . 103 9.4 Cas d’étude : l’algorithme Shunting-Yard . . . . . . . . . . . . . . . . . . . . . 106 9.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.4.2 Automate sous-jacent pour l’algorithme Shunting-Yard . . . . . . . . . . 106 9.4.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 9.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 10 Conclusion de la partie III 113 IV Conclusions et perspectives 115 11 Conclusions et perspectives 117Table des figures 2.1 Aex (Exemple d’automate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Aex2 (Deuxième exemple d’automate) . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 A1 × A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4 Aex × Aex2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5 Automates isomorphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.6 Aex/∼ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.7 T(A1)/∼exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.8 In(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.9 Tex (Exemple de transducteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.10 Tex(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.11 T(A1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.12 Token ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.13 Arbre de dérivation correspondant à la séquence S, aS b, aT bb, abb . . . . . . . . 29 2.14 Apower, exemple de NPDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.15 Algorithme Génération aléatoire . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.16 Exemple d’une grammaire qui génère des DFA-traces cohérentes . . . . . . . . . 33 3.1 Approche par sur-approximation . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2 Sur-approximations successives . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3 Calcul de CRight(A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4 Semi-algorithme PointFixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.5 Token ring : semi-algorithme PointFixe avec F = Left . . . . . . . . . . . . . . 45 3.6 Situation nécessitant un raffinement de l’approximation . . . . . . . . . . . . . . 46 3.7 Algorithme Analyse en arrière . . . . . . . . . . . . . . . . . . . . . . . . 46 3.8 Principe du raffinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1 In(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2 Out(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3 A Le f t,2 ex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4 A Right,3 ex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51TABLE DES FIGURES 12 4.5 Left(Atr1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6 Right(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7 Résultats avec des critères syntaxiques . . . . . . . . . . . . . . . . . . . . . . . 54 5.1 x · Aex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.2 Aex3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3 Aex4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.4 Token ring : Appliquer un transducteur T à un QC × Q ∗ T -automate (1) . . . . . . 57 5.5 Token ring : Appliquer un transducteur T à un QC × Q ∗ T -automate (2) . . . . . . 58 5.6 Token Ring : fusion en fonction des états du transducteur (1) . . . . . . . . . . . 59 5.7 Token ring : fusion en fonction des états du transducteur (2) . . . . . . . . . . . . 59 5.8 Semi-algorithme PointFixeT . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.9 Situation nécessitant un raffinement de l’approximation . . . . . . . . . . . . . . 62 5.10 Algorithme Séparer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.11 Algorithme Raffiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.12 Exemples pour les algorithmes Séparer et Raffiner . . . . . . . . . . . . . . . 63 5.13 Semi-algorithme Vérif-avec-raffinement . . . . . . . . . . . . . . . . . . . 64 5.14 Types d’automates C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.15 Résultats avec la méthode reposant sur les états du transducteur comme critère de fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.1 Classification des différents types de tests . . . . . . . . . . . . . . . . . . . . . 74 7.2 Exemple de graphe fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3 Exemple 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.4 Exemple 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.5 Génération aléatoire - Algorithme 1 . . . . . . . . . . . . . . . . . . . . . . . . 79 7.6 Génération aléatoire - Algorithme 2 . . . . . . . . . . . . . . . . . . . . . . . . 79 7.7 Génération aléatoire - Algorithme 3 . . . . . . . . . . . . . . . . . . . . . . . . 80 7.8 Calcul des probabilités πe, afin d’optimiser la probabilité de couvrir C . . . . . . 80 7.9 Programme en C, qui calcule x n . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.10 Graphe de flot de contrôle de x n . . . . . . . . . . . . . . . . . . . . . . . . . . 81 8.1 Arbre de dérivation de la grammaire G de l’exemple 8.3 . . . . . . . . . . . . . . 86 8.2 Arbre de dérivation de la grammaire GX de l’exemple 8.3 . . . . . . . . . . . . . 86 9.1 Méthode de test aléatoire d’un programme . . . . . . . . . . . . . . . . . . . . . 92 9.2 Génération aléatoire de DFA-traces cohérentes . . . . . . . . . . . . . . . . . . . 93TABLE DES FIGURES 13 9.3 Automate sous-jacent de A6 exe . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 9.4 Automate sous-jacent de A (6,h,9) exe . . . . . . . . . . . . . . . . . . . . . . . . . . 96 9.5 Calcul des probabilités πq, afin d’optimiser la probabilité de couvrir Q . . . . . . 97 9.6 Fonctions mutuellement récursives . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.7 Amodulo : NPDA de l’exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9.8 Automate Axpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.9 Algorithme Shunting-Yard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9.10 Automate sous-jacent pour l’algorithme Shunting-Yard . . . . . . . . . . . . . . 108 9.11 Implémentation en C de l’algorithme Shunting-Yard, que nous avons testée 1/2 . 109 9.12 Implémentation en C de l’algorithme Shunting-Yard, que nous avons testée 2/2 . 110I Introduction1 Prologue 1.1/ Contexte Le développement de programmes sûrs, sécurisés et exempts de bogues est un des problèmes les plus difficiles de l’informatique moderne. Les logiciels sont omniprésents dans notre quotidien, et on leur confie des tâches de plus en plus sensibles, comme le transfert de nos données bancaires lorsque l’on commande sur internet. On parle de logiciels critiques lorsque les conséquences d’un dysfonctionnement peuvent être particulièrement graves, comme lorsque des vies ou lorsque d’importantes sommes d’argent (millions/milliards d’euros) sont en jeux. Sont concernés par exemple les logiciels utilisés pour les systèmes de transport (avions, trains, voitures, . . .), l’énergie (réseau de distribution, centrales, . . .), la santé (gestion des hôpitaux, appareils médicaux, . . .), la finance (bourse, paiement en ligne ou par carte, . . .), ou encore dans le domaine militaire (missiles, drones, communications cryptées, . . .) ou dans l’aérospatiale (fusées, satellites, . . .). Il est donc indispensable de pouvoir s’assurer de la qualité de ces logiciels. Dans ce contexte, on peut distinguer deux techniques complémentaires pour évaluer la qualité d’un système informatique : la vérification et le test. La vérification consiste à prouver mathématiquement qu’un code ou un modèle d’application ré- pond aux attentes (ou propriétés) décrites dans sa spécification. Elle peut se faire avec un assistant de preuve (par exemple Coq) qui aide l’ingénieur à construire des preuves formelles, pouvant même démontrer certains lemmes de façon automatique. La vérification peut aussi se faire par évaluation de modèle – on utilise couramment le terme anglais model-checking –, qui est une méthode qui tente de vérifier si d’après le modèle du système, l’ensemble de ses états atteignables satisfait (ou pas) des propriétés. Un des principaux inconvénients de la vérification est la complexité algorithmique des techniques existantes, qui les rend difficilement applicables à des systèmes de taille importante. Contrairement à la vérification, le test ne fournit pas de preuve formelle en amont. Mais les techniques de test sont applicables à des systèmes de grande taille, et en pratique elles sont pertinentes dans le développement de logiciels de qualité. Le test occupe une part de plus en plus importante du développement de logiciels, au point que se développent des méthodes de développement piloté par les tests – abrégé en TDD, pour l’anglais Test Driven Development –, qui préconisent d’écrire les tests avant d’écrire le code source. Au cours de la dernière décennie, afin de faire face à cette importance croissante de la phase de test, de nombreux travaux ont été réalisés dans l’objectif de passer des méthodes de test manuelles (fondées sur l’expérience) à des méthodes automatiques ou semi-automatiques fondées sur des méthodes formelles.PARTIE I. Introduction - CHAPITRE 1. PROLOGUE 18 1.2/ Contributions Cette thèse présente des contributions à la vérification et à la validation à base de modèles. Notre contribution dans le cadre de la vérification, consiste à définir deux nouvelles techniques d’approximation pour le model-checking régulier, dans le but de fournir des (semi-)algorithmes efficaces. On calcule des sur-approximations de l’ensemble des états accessibles, avec l’objectif d’assurer la terminaison de l’exploration de l’espace d’états. L’ensemble des états accessibles (ou les sur-approximations de cet ensemble) est représenté par un langage régulier, lui même codé par un automate fini. La première technique consiste à sur-approximer l’ensemble des états atteignables en fusionnant des états des automates, en fonction de critères syntaxiques simples, ou d’une combinaison de ces critères (cf. section 4). La seconde technique d’approximation consiste aussi à fusionner des états des automates, mais cette fois-ci à l’aide d’un transducteur (cf. section 5.2). De plus, pour cette seconde technique, nous développons une nouvelle approche pour raffiner les approximations (cf. section 5.3), qui s’inspire du paradigme CEGAR (cf. section 3.4). Ces deux techniques d’approximation pour le model-checking régulier ont été publiées dans [DHK13a]. Pour le test, notre contribution est la définition d’une technique qui permet de combiner la génération aléatoire avec un critère de couverture, à partir d’une grammaire algébrique ou d’un automate à pile. Dans [DGG+12], il est expliqué comment biaiser une approche de test aléatoire uniforme dans un graphe fini, en utilisant des contraintes données par un critère de couverture, afin d’optimiser la probabilité de satisfaire ce critère. Mais un graphe fini représente souvent une abstraction forte du système sous test, il y a donc un risque que de nombreux tests abstraits ne soient pas concrétisables (c’est-à-dire jouables sur l’implémentation). Nous avons enrichi cette approche afin de l’appliquer sur des modèles algébriques (des grammaires algébriques dans le chapitre 8, et des automates à pile dans le chapitre 9), ce qui permet de réduire le degré d’abstraction du modèle et donc de générer moins de tests non concrétisables. Notre technique qui permet de combiner la gé- nération aléatoire avec un critère de couverture à partir d’une grammaire algébrique a été publiée dans [DHK13b], et celle sur les automates à pile a été publiée dans [DHKM14]. 1.3/ Plan Dans le chapitre 2, nous introduisons toutes les définitions, notations, propositions et théorèmes indispensables à la lecture de cette thèse. Nous présentons tout d’abord les notions relatives aux automates et langages réguliers, puis les notions relatives aux grammaires algébriques et aux automates à pile. La partie II présente nos contributions dans le domaine de la vérification : Le chapitre 3 introduit le model-checking régulier et le raffinement d’approximations. Dans le chapitre 4, nous présentons une technique pour le model-checking régulier, qui consiste à sur-approximer l’ensemble des états atteignables en fusionnant des états des automates, en fonction de critères syntaxiques simples, ou d’une combinaison de ces critères. Le chapitre 5 présente une technique utilisant un nouveau critère de fusion, qui exploite la relation de transition du système. La partie III présente nos contributions dans le domaine du test : Le chapitre 7 présente le contexte de nos travaux. Nous combinons ensuite de la génération aléatoire avec un critère de couverture, dans une grammaire (chapitre 8), puis dans un automate à pile (chapitre 9).PARTIE I. Introduction - CHAPITRE 1. PROLOGUE 19 1.4/ Publications Cette thèse s’appuie sur des travaux ayant fait l’objet de publications. Voici une liste de celles auxquelles j’ai participé : [DHK13a] contient deux méthodes de model-checking régulier : La première méthode utilise des critères syntaxiques que l’on peut combiner avec des opérateurs logiques (cf. chapitre 4), et la seconde exploite la relation de transition du système (cf. chapitre 5). [DHK13b] expose notre méthode pour combiner de la génération aléatoire avec un critère de couverture, dans le cadre du test à partir d’une grammaire (cf. chapitre 8). [DHKM14] détaille comment combiner de la génération aléatoire avec un critère de couverture, à partir d’un automate à pile (cf. chapitre 9).2 Preliminaires th ´ eoriques et notations ´ Cette section présente les notations et définitions nécessaires à la compréhension du document. 2.1/ Automates et langages reguliers ´ 2.1.1/ Mots et langages Un alphabet est un ensemble fini d’éléments appelés lettres. Un mot u sur un alphabet Σ est une juxtaposition de lettres de Σ. Le nombre de lettres de u (comptées avec multiplicité) est appelé longueur de u. L’ensemble des mots sur un alphabet Σ est noté Σ ∗ . On appelle langage sur un alphabet Σ tout sous-ensemble de Σ ∗ . Le mot vide (le mot de longueur nulle) est noté ε. L’ensemble Σ ∗ \ {ε} est noté Σ + . 2.1.2/ Automates finis et expressions reguli ´ eres ` Un automate fini A sur un alphabet Σ est un 5-uplet (Q, Σ, E, I, F) où : — Q est l’ensemble fini des états, — E ⊆ Q × Σ × Q est l’ensemble fini des transitions, — I ⊆ Q est l’ensemble fini des états initiaux, — F ⊆ Q est l’ensemble fini des états finaux. Dans le cadre de nos recherches nous avons uniquement travaillé sur des automates finis, l’utilisation par la suite du terme "automate" désignera donc un automate fini. Le terme "automate fini" est abrégé en NFA, pour l’anglais Nondeterministic Finite Automaton. On définit la taille de A par |A| = |Q| + |E|. Un automate est déterministe si I est un singleton et pour tout (p, a) ∈ Q × Σ il existe au plus un q ∈ Q tel que (p, a, q) ∈ E. Le terme "automate déterministe" est abrégé en DFA, pour l’anglais Deterministic Finite Automaton. Un automate est complet si pour tout (p, a) ∈ Q × Σ il existe au moins un q ∈ Q tel que (p, a, q) ∈ E. Pour une transition de la forme (p, a, q), p est l’état de départ, a est l’étiquette, et q est l’état d’arrivée. Deux transitions (p1, a1, q1) et (p2, a2, q2) sont dites consécutives si q1 = p2. Un chemin de A est une suite finie (éventuellement vide) de transitions (p1, a1, q1) . . . (pn, an, qn) consécutives. Le nombre entier n est la longueur du chemin, et le mot a1 . . . an est son étiquette. On dit qu’un chemin est réussi lorsque p1 est un état initial, et qn un état final. Un mot u est reconnu par A si u est l’étiquette d’un chemin réussi de A. On appelle langage reconnu par A l’ensemble des mots reconnus par l’automate A, et on le note L(A). Si A est déterministe et complet, pour tout état p et tout mot u, il existe un unique état de A, noté p ·A u accessible en lisant à partir de l’état p, un chemin étiqueté par u. S’il n’y a pas d’ambiguïté sur l’automate A, on écrit plus simplement p · u. Par convention, soit ε le mot vide, p · ε = p. Un état p est accessible s’il existe un chemin d’un état initial vers p, et co-accessible s’il existe unPARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 22 chemin de p vers un état final. Un automate dont les états sont tous accessibles et co-accessibles est dit élagué. Si A n’est pas élagué, supprimer tous ses états qui ne sont pas à la fois accessibles et co-accessibles, ainsi que toutes les transitions liées, produit un automate élagué qui reconnaît le même langage. Dans les figures, les automates sont généralement donnés sous forme élaguée afin d’en faciliter la compréhension. Une expression régulière sur un alphabet Σ est une expression reg définie par la grammaire suivante : reg := B | (reg ∪ reg) | (reg · reg) | reg∗ , où B est un ensemble fini de mots. Par exemple ({ab, b} ∗ ∪({aa}· {a} ∗ )) est une expression régulière sur {a, b}. Pour simplifier, si u est un mot et reg une expression régulière, les expressions du type {u} ∗ , {u} · L et L · {u} sont respectivement écrites u ∗ , u · L (ou même uL) et L · {u} (et même Lu). De plus, on omet parfois les parenthèses, l’étoile étant prioritaire sur le produit, lui-même prioritaire sur l’union. L’expression ({ab, b} ∗∪({aa}·{a} ∗ )) sera simplement notée {ab, b} ∗∪aaa∗ . On confondra dans la suite une expression régulière avec le langage qu’elle reconnaît, la sémantique étant naturellement celle de l’union, produit et de l’étoile sur les langages. Exemple 2.1. La figure 2.1 et la figure 2.2 représentent Aex et Aex2, qui sont deux exemples d’automates finis. L’automate Aex (figure 2.1) reconnaît les mots de la forme a∗ba, ou a∗bb, ou a ∗bba, ou a∗bbc. L’automate Aex2 = (Qex2, Σex2, Eex2, Iex2, Fex2) (figure 2.2) reconnaît les mots de la forme b∗ c, et on a Qex2 = {1, 2}, Σex2 = {b, c}, Eex2 = {(1, b, 1), (1, c, 2)}, Iex2 = {1} et Fex2 = {2}. 1 2 3 a b b 4 a a, c Aex Figure 2.1 – Aex (Exemple d’automate) 1 2 b c Figure 2.2 – Aex2 (Deuxième exemple d’automate) Définition 2.1. Langage régulier Un langage est dit régulier s’il appartient à la plus petite famille de langages contenant les langages finis et close par union, produit et étoile.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 23 D’après le théorème de Kleene, un langage est régulier si et seulement s’il est reconnu par un automate fini. De plus, un langage est régulier si et seulement s’il est exprimable par une expression régulière. Il faut aussi noter que l’on peut montrer que l’ensemble des langages réguliers sur un alphabet donné est clos par intersection et complément. Définition 2.2. Problème régulier Un problème est dit régulier s’il est représentable avec uniquement des langages réguliers. 2.1.3/ Produit d’automates Le produit de deux automates, A1 = (Q1, Σ1, E1, I1, F1) et A2 = (Q2, Σ2, E2, I2, F2), noté A1×A2, est l’automate (Q, Σ, E, I, F) où : — Q = Q1 × Q2, — Σ = Σ1 T Σ2, — E = {((p1, p2), a, (q1, q2)) | ∃a ∈ Σ1 T Σ2, (p1, a, q1) ∈ E1, (p2, a, q2) ∈ E2}, — I = I1 × I2, — F = F1 × F2. Intuitivement, l’ensemble des chemins de A1 × A2 est composé des chemins qui existent à la fois dans A1 et dans A2 (au nom des états près). Il reconnaît les mots qui font à la fois partie du langage de A1 et du langage de A2. L(A1 × A2) = L(A1) T L(A2). Exemple 2.2. La figure 2.3 représente deux automates A1 et A2 ainsi que leur produit, notée A1 × A2. 1 2 a a, b b (a) A1 4 3 a b b a (b) A2 1, 4 2, 4 1, 3 2, 3 a a b a b b b a (c) A1 × A2 Figure 2.3 – A1 × A2 Exemple 2.3. L’automate Aex reconnaît les mots de la forme a∗ba, ou a∗bb, ou a∗bba, ou a∗bbc, et Aex2 reconnaît les mots de la forme b∗ c. Le produit Aex ×Aex2 de ces deux automates reconnaît donc le mot bbc. La figure 2.4 représente la version élaguée de l’automate Aex × Aex2 (c’est-à- dire qu’on a enlevé les états qui ne sont pas atteignables à partir d’un état initial, et les états qui n’atteignent aucun état final). 2.1.4/ Isomorphisme d’automates Deux automates A1 = (Q1, Σ, E1, I1, F1) et A2 = (Q2, Σ, E2, I2, F2) sont isomorphes s’il existe une bijection f : Q1 → Q2 qui satisfait (p, a, q) ∈ E1 si et seulement si (f(p), a, f(q)) ∈ E2, et f(I1) = I2, f(F1) = F2.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 24 1 2 3 a b b 4 a a, c Aex 1 2 b c Aex2 1, 1 2, 1 3, 1 4, 2 b b c Aex × Aex2 Figure 2.4 – Aex × Aex2 Autrement dit, deux automates sont isomorphes s’ils sont identiques à un renommage des états près. Exemple 2.4. La figure 2.5 représente deux automates isomorphes : Aex et A 0 ex. La bijection f : Qex → Q 0 ex est la suivante : f(1) = 0, f(2) = 2, f(3) = 1, f(4) = 3. 1 2 3 a b b 4 a a, c Aex 0 2 1 a b b 3 a a, c A 0 ex Figure 2.5 – Automates isomorphes 2.1.5/ Reduction d ´ ’un automate Soient A un automate, Aˆ = (Qˆ, Σ, Eˆ, ˆI, Fˆ) l’automate élagué obtenu à partir de A, et ∼⊆ Q × Q une relation d’équivalence. On note A/∼ l’automate (Qˆ/∼, Σ, E 0 , I 0 , F 0 ) où E 0 = {( ˜p, a, q˜) | ∃p ∈ p˜ et ∃q ∈ q˜ tels que (p, a, q) ∈ Eˆ}, I 0 = {p˜ | ∃p ∈ p˜ T ˆI}, et F 0 = {p˜ | ∃p ∈ p˜ T Fˆ}. Intuitivement, l’automate A/∼ est obtenu en regroupant les états de chaque classe d’équivalence de la version élaguée de A. Il est trivial que L(A) ⊆ L(A/∼). La notion de réduction d’automate peut également être étendue à toutes les relations : si ∼ est une relation sur Q alors A/∼ est l’automate A/∼, où ∼ est la fermeture réflexive, symétrique et transitive de ∼. Exemple 2.5. Soit ∼ une relation sur Q définie comme ceci : soit p et q deux états de A, p∼q si et seulement s’il existe dans A une transition qui va de p vers q et qui a pour étiquette la lettrePARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 25 c. Pour Aex on a 3∼4. La relation ∼ n’étant pas une relation d’équivalence, Aex/∼ est l’automate Aex/∼ tel que ∼ est la fermeture réflexive, symétrique, et transitive de ∼. On obtient cet automate en fusionnant l’état 3 avec l’état 4, qui font partie d’une même classe d’équivalence (cf. figure 2.6). 1 2 3 a b b 4 a a, c Aex 1 2 3, 4 a b b, a a, c Aex/∼ Figure 2.6 – Aex/∼ Exemple 2.6. D’après l’automate T(A1) (cf. figure 2.11) et la relation ∼exe dont les classes sont {(1, 4), (2, 4), (1, 3)} et {(2, 3)}, l’automate T(A1)/∼exe est représenté sur la Fig. 2.7. 1, 4 2, 4 1, 3 2, 3 b b a b a a a b (a) T(A1) 1,4 2,4 1,3 2,3 b a a, b (b) T(A1)/∼exe Figure 2.7 – T(A1)/∼exe Définition 2.3. Fonction d’approximation Une fonction d’approximation F est une fonction qui associe à tout automate A, une relation ∼ A F sur les états de A. L’automate A/∼ A F sera noté F(A). On défini inductivement F n (A) par F 0 (A) = A, et F n (A) = F(F n−1 (A)) pour n > 0. La fonction d’approximation F est isomorphisme-compatible si pour toute paire d’automates isomorphes A1, A2, et pour tout isomorphisme ϕ de A1 vers A2, p ∼ A1 F q si et seulement si ϕ(p) ∼ A2 F ϕ(q). Intuitivement, cela signifie que pour être isomorphisme-compatible, une fonction d’approximation ne doit pas dépendre du nom des états. Exemple 2.7. Soit In la fonction d’approximation qui associe à tout automate A, la relation ∼ A In sur les états de A telle que, soient p et q deux états de A, p ∼ A In q si et seulement si l’ensemblePARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 26 des étiquettes des transitions qui arrivent sur l’état p est égal à l’ensemble des étiquettes des transitions qui arrivent sur l’état q. Dans l’automate Aex de la figure 2.8, 2 ∼ Aex In 3 car l’ensemble des étiquettes des transitions qui arrivent sur l’état 2 est égal à l’ensemble des étiquettes des transitions qui arrivent sur l’état 3 (qui est égal à {b}). Pour obtenir l’automate In(Aex), on fusionne donc l’état 2 et l’état 3 de l’automate Aex (cf. figure 2.8). 1 2 3 a b b 4 a a, c Aex 1 2, 3 a b b 4 a, c In(Aex) Figure 2.8 – In(Aex) 2.1.6/ Transducteurs lettre a lettre finis ` Un transducteur lettre à lettre fini T est un automate fini dont l’alphabet Σ est de la forme Σe × Σs , où Σe est appelé alphabet d’entrée et Σs est appelé alphabet de sortie. On notera les étiquettes (ae, as) sous la forme ae|as . L’étiquette d’un chemin ae1|as1 . . . aen|asn s’écrira sous la forme d’un couple (ae1 . . . aen, as1 . . . asn). Tout transducteur T sur Σe × Σs induit une relation RT sur Σ ∗ e × Σ ∗ s définie par : pour tous aei ∈ Σe et as j ∈ Σs , (ae1 . . . aen, as1 . . . asm) ∈ RT si et seulement si n = m et le mot (ae1, as1) . . . (aen, asn) est reconnu par T. Pour tout langage I, RT (I) est l’ensemble des mots v tels qu’il existe un mot u dans I, et (u, v) ∈ RT . La clôture réflexive et transitive de RT est notée R ∗ T . La notion de transducteur est dans la littérature plus générale que la définition donnée ici. Mais comme nous n’utiliserons que des transducteurs lettre à lettre, l’utilisation dans la suite du document du terme transducteur désignera un transducteur lettre à lettre fini. Exemple 2.8. La figure 2.9 représente Tex, qui est un exemple de transducteur. Soit Tex = (Qex, Σeex × Σsex, Eex, Iex, Fex), on a Qex = {1, 2, 3}, Σeex = {a, b}, Σsex = {a, b}, Eex = {(1, a|a, 1), (1, b|b, 1), (1, b|a, 2), (2, a|b, 3), (3, a|a, 3), (3, b|b, 3)}, Iex = {1} et Fex = {1, 3}. 1 2 3 a|a, b|b a|a, b|b b|a a|b Tex Figure 2.9 – Tex (Exemple de transducteur)PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 27 2.1.7/ Appliquer un transducteur a un automate ` Soit A = (QA, ΣA, EA, IA, FA) un automate, et T = (QT , ΣeT ×ΣsT , ET , IT , FT ) un transducteur, T(A) est l’automate (Q, Σ, E, I, F) défini par : — Q = QA × QT , — Σ = ΣsT , — E = {(pA, pT ), b, (qA, qT ) | ∃a ∈ ΣA T ΣeT et ∃b ∈ ΣsT tels que (pA, a, qA) ∈ EA et (pT , a|b, qT ) ∈ ET }, — I = IA × IT , — F = FA × FT . Intuitivement, l’application d’un transducteur T à un automate A ressemble beaucoup à un produit d’automates. Sauf qu’on utilise l’alphabet d’entrée du transducteur pour trouver les chemins en commun, mais qu’on remplace ensuite la lettre d’entrée par la lettre de sortie correspondante. Par définition, L(T(A)) est l’ensemble des mots v qui satisfont (u, v) ∈ RT avec u ∈ L(A). Si T = (QT , ΣeT × ΣsT , ET , IT , FT ) est un transducteur, on note T −1 le transducteur (QT , ΣsT × ΣeT , E 0 T , IT , FT ) avec E 0 T = {(p, (b, a), q) | (p, (a, b), q) ∈ ET }. On peut démontrer que (u, v) ∈ RT si et seulement si (v, u) ∈ RT−1 . Exemple 2.9. T ex(Aex) L’automate Aex reconnaît les mots de la forme a∗ba, a ∗bb, a∗bba et a∗bbc, et le transducteur Tex reconnaît les mots de la forme [(a|a) ∪ (b|b)]∗ (b|a)(a|b)[(a|a) ∪ (b|b)]∗ . L’application Tex(Aex) du transducteur Tex à l’automate Aex reconnaît donc les mots de la forme a∗ab, a∗bab, a∗ba, a∗bb, et a∗bba. La figure 2.10 représente une version élaguée de l’automate Tex(Aex) (c’est-à-dire qu’on a enlevé les états qui ne sont pas atteignables à partir d’un état initial, et les états qui n’atteignent aucun état final). 1 2 3 a b b 4 a a, c Aex 1 2 3 a|a, b|b a|a, b|b b|a a|b Tex 1, 1 2, 1 3, 1 a b b 2, 2 a 3, 2 a 4, 3 b b 4, 1 a a Tex(Aex) Figure 2.10 – Tex(Aex) Exemple 2.10. T (A1) D’après le transducteur T et l’automate A1 (cf. figure 2.11), T(A1) est représenté sur la figure 2.11. Exemple 2.11. Token ringPARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 28 1 2 a a, b b (a) A1 4 3 a|b b|a b|a a|b (b) T 1, 4 2, 4 1, 3 2, 3 b b a b a a a b (c) T(A1) Figure 2.11 – T(A1) 1 2 b a (a) Atr 3 4 a|b a|a, b|b b|a (b) Ttr 1, 4 1, 3 2, 3 b a b a (c) Atr1=Ttr(Atr) après élagage Figure 2.12 – Token ring 2.1.8/ Appliquer un transducteur a un langage ` Soit T = (Q, Σe × Σs , E, I, F) un transducteur et K un langage, l’application de T à K donne un langage T(K) = {v ∈ Σ ∗ s |∃u ∈ K, (u, v) ∈ L(T)} (avec la convention (a|b)(c|d) = (ac, bd)). Proposition 2.12 Soit A un automate et T un transducteur, T(L(A)) = L(T(A)) L’application d’un transducteur à un automate et l’application d’un transducteur à un langage sont deux opérations étroitement liées. Il est connu que l’application d’un transducteur T au langage reconnu par un automate A donnera comme résultat le langage reconnu par T(A). 2.2/ Grammaires algebriques et automates ´ a pile ` 2.2.1/ Grammaires algebriques ´ Une grammaire algébrique – appelée aussi parfois grammaire non contextuelle ou encore grammaire hors contexte – est un 4-uplet G = (Σ, Γ, S 0, R), où : — Σ et Γ sont des alphabets finis disjoints, — S 0 ∈ Γ est le symbole initial, — R est un sous-ensemble fini de Γ × (Σ ∪ Γ) ∗ .PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 29 Les éléments de Σ sont appelés symboles terminaux, et les éléments de Γ sont appelés symboles non-terminaux. Un élément (X, u) de R est appelé une règle de la grammaire et est fréquemment noté X → u. Un mot u1 ∈ (Σ ∪ Γ) ∗ est un successeur de u0 ∈ (Σ ∪ Γ) ∗ dans la grammaire G s’il existe v ∈ Σ ∗ , w, x ∈ (Σ ∪ Γ) ∗ , S ∈ Γ tels que u0 = vS w et u1 = vxw et S → x ∈ R. Une dérivation complète 1 de la grammaire G est une séquence finie u0, . . . , uk de mots de (Σ∪Γ) ∗ telle que u0 = S 0, uk ∈ Σ ∗ et pour tout i, ui+1 est un successeur de ui . Un arbre de dérivation de G est un arbre fini dont les nœuds internes sont étiquetés par des lettres de Γ, dont les feuilles sont étiquetées par des éléments de Σ ∪ {ε}, dont la racine est étiquetée par S 0 et qui satisfait : si un nœud est étiqueté par X ∈ Γ et si ses fils sont étiquetés par α1, . . . , αk (dans cet ordre), alors (X, α1 . . . αk) ∈ R et soit α1 = ε et k = 1, soit tous les αi’s sont dans Γ ∪ Σ. La taille d’un arbre de dérivation est donnée par le nombre de nœuds de l’arbre. Notons qu’il existe une bijection entre l’ensemble des dérivations complètes d’une grammaire et l’ensemble des arbres de dérivations de cette grammaire. Pour une grammaire algébrique G, En(G) représente l’ensemble des arbres de dérivation de G composés de n nœuds. On dit qu’un arbre de dérivation couvre un élément X de Γ si au moins un de ses nœuds est étiqueté par X. Et on dit qu’un arbre de dérivation couvre une règle X → u de R si cette règle est utilisée dans la dérivation complète correspondante. Exemple 2.13. Grammaire algébrique Soit la grammaire G = ({a, b}, {S, T}, S, R), avec R = {S → T b, S → aS b, T → ε}). La séquence S, aS b, aT bb, abb est une dérivation complète de la grammaire. L’arbre de dérivation associé à cette séquence est représenté dans la figure 2.13. On peut y voir que les éléments S et T ainsi que la règle S → aS b sont couverts, puisqu’ils apparaissent dans l’arbre de dérivation. S S a b b T ε Figure 2.13 – Arbre de dérivation correspondant à la séquence S, aS b, aT bb, abb 2.2.2/ Automates a pile ` Un automate à pile est un 6-uplet A = (Q, Σ, Γ, δ, qinit, F) où : — Q est l’ensemble fini des états, — Σ (alphabet d’entrée) et Γ (alphabet de la pile) sont des alphabets finis disjoints tels que ε < Σ et ⊥ ∈ Γ, — qinit ∈ Q est l’état initial, — F est l’ensemble des états finaux, — δ est une fonction partielle de Q × (Σ ∪ {ε}) × Γ vers Q × Γ ∗ telle que pour tout q ∈ Q, pour tout X ∈ Γ \ {⊥}, et pour tout a ∈ Σ ∪ {ε} : — si δ(q, a, X) = (p,w) alors w ∈ (Γ \ {⊥}) ∗ , — si δ(q, a, ⊥) = (p,w) alors w = ⊥w 0 avec w 0 ∈ (Γ \ {⊥}) ∗ . La lettre ⊥ est appelée le symbole de pile vide, ou encore le fond de la pile. Le terme "automate à pile" est abrégé en PDA, pour l’anglais PushDown Automaton. Une configuration d’un PDA est un élément de Q × {⊥}(Γ \ {⊥}) ∗ , c’est-à-dire une paire dont le premier élément est dans Q, et le second élément est un mot qui commence par ⊥ et dont aucune des autres lettres n’est ⊥. Intuitivement, la seconde partie encode la valeur courante de la pile. La configuration initiale est 1. Comme v ∈ Σ ∗ , cette dérivation est une dérivation gauche.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 30 (qinit, ⊥). Deux configurations (q, ⊥u) et (p, ⊥v) sont a-consécutives, avec a ∈ Σ ∪ {ε}, si u = ε et δ(q, a, ⊥) = (p, ⊥v), ou si u est de la forme u0X avec X ∈ Γ \ {⊥} et qu’il existe w ∈ Γ ∗ tel que δ(q, a, X) = (p,w) et v = u0w. 0 1 2 5 4 6 7 9 8 10 a b c e push(S ) pop(S ) pop(S ) pop(S ) g h i j Figure 2.14 – Apower, exemple de NPDA Une PDA-trace de longueur n dans un PDA est une séquence C1a1C2a2 . . .CnanCn+1 où les Ci’s sont des configurations, les ai’s sont dans Σ ∪ {ε} et tels que C1 est la configuration initiale, pour tout i, Ci et Ci+1 sont ai-consécutives, et Cn+1 est de la forme (p, ⊥) avec p ∈ F. Un automate à pile normalisé – abrégé en NPDA, pour l’anglais Normalised PushDown Automaton – est un PDA tel que pour tout état q, pour tout a ∈ Σ ∪ {ε}, et pour tout X ∈ Γ, si δ(q, a, X) = (p,w) alors on se trouve dans l’un des cas suivants : (i) a = ε et w = ε, ou (ii) a = ε et w est de la forme w = XY avec Y ∈ Γ, ou (iii) a , ε et w = X. Il faut également que si δ(q, ε, X) = (p, XY), alors pour tout Z ∈ Γ, δ(q, ε, Z) = (p, ZY) – c’est-à- dire qu’une transition qui ajoute un élément au sommet de la pile peut être déclenchée indépendamment de l’état de la pile –, et que si δ(q, a, X) = (p, X), alors pour tout Z ∈ Γ, δ(q, a, Z) = (p, Z) – c’est-à-dire qu’une transition qui lit une lettre en entrée peut également être déclenchée indépendamment de l’état de la pile –. 2 Intuitivement, le cas (i) correspond à l’action de dépilement (pop) – c’est-à-dire retirer l’élément au sommet de la pile –, le cas (ii) correspond à l’action d’empilement (push) – c’est-à-dire ajouter un élément au sommet de la pile –, et le cas (iii) correspond à l’action de lecture (read) – c’est- à-dire consommer l’élément suivant de l’entrée (sans modifier la pile) –. L’automate sous-jacent d’un NPDA A = (Q, Σ, Γ, δ, qinit, F) est l’automate (Q, Σ ∪ {pop(X), push(X) | X ∈ Γ}, µ, qinit, F), où l’ensemble des transitions µ est défini par : (i) δ(q, ε, X) = (p, ε) si et seulement si µ(q, pop(X)) = p, (ii) δ(q, ε, X) = (p, XY) si et seulement si µ(q, push(Y)) = p, (iii) δ(q, a, X) = (p, X) si et seulement si µ(q, a) = p. Une NPDA-trace est une PDA-trace dans un NPDA. Les définitions ci-dessus peuvent être illustrées par le NPDA de la figure 2.14, qui correspond au graphe à droite de la figure 7.10. Pour cet automate Q = {0, . . . , 10}, Σ = {a, b, c, e, g, h, i, j}, Γ = {⊥, S }, qinit = 0, F = {4, 8, 10} et δ est 2. Ces conditions ne réduisent pas le pouvoir d’expression puisqu’il est possible d’encoder toute transition de la forme δ(q, ε, X) = (p, XY) qui requiert un X au sommet de la pile pour être déclenchée, par δ(q, ε, X) = (qnew1, ε) et pour tout Z ∈ Γ, δ(qnew1, ε, Z) = (qnew2, ZX) et δ(qnew2, ε, Z) = (p, ZY). Il en est de même pour toute transition de la forme δ(q, a, X) = (p, X) qui requiert un X au sommet de la pile pour être déclenchée, qui peut être encodée par δ(q, ε, X) = (qnew1, ε) et pour tout Z ∈ Γ, δ(qnew1, ε, Z) = (qnew2, ZX) et δ(qnew2, a, Z) = (p, Z).PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 31 défini par les flèches : pour une arête de la forme (q, a, p) avec a ∈ Σ, alors on a δ(q, a, ⊥) = (p, ⊥) et δ(q, a, S ) = (p, S ) ; pour une arête de la forme (q, pop(S ), p) alors δ(q, ε, S ) = (p, ε) ; pour une arête de la forme (q, push(S ), p) alors δ(q, ε, ⊥) = (p, ⊥S ) et δ(q, ε, S ) = (p, S S ). La séquence (0, ⊥)a(1, ⊥)c(5, ⊥)ε(0, ⊥S )a(1, ⊥S )c(5, ⊥)ε(0, ⊥S S )a(1, ⊥S S )b(2, ⊥S S ) e(4, ⊥S S )ε(6, ⊥S )h(9, ⊥S )j(10, ⊥S )ε(6, ⊥)g(7, ⊥)i(8, ⊥) est une NPDA-trace dans le NPDA. Cette trace correspond à l’exécution de power(3,2), que l’on a détaillée dans l’exemple 7.3. Notons que chaque paire (q,w) signifie que le système est dans l’état q et que la pile d’appels est w. Par exemple, (2, ⊥S S ) signifie que le système est dans l’état 2 et qu’il y a deux appels non terminés à la fonction power. Chaque NPDA-trace d’un NPDA est associée à une DFA-trace dans l’automate sousjacent selon la projection suivante : la NPDA-trace C1a1 . . . anCn est associée au chemin (q1, a1, q2) . . . (qn−1, an, qn), où les Ci’s sont de la forme (qi ,wi). Par exemple, la DFA-trace associée à la NPDA-trace ci-dessus est (0, a, 1)(1, c, 5)(5, ε, 0) . . . (6, g, 7)(7, i, 8). Cette projection est notée proj et est injective. Son image forme un sous-ensemble de DFA-traces, appelées DFA-traces cohérentes de l’automate sous-jacent, qui est en bijection avec l’ensemble des NPDA-traces. 2.2.3/ Gen´ eration al ´ eatoire uniforme d ´ ’un arbre de derivation dans une grammaire ´ Le problème de la génération aléatoire uniforme sur les grammaires peut s’écrire ainsi : Problème 2.14. Génération aléatoire d’un arbre de dérivation dans une grammaire Entrée : Une grammaire algébrique G, un nombre entier positif n Question : Générer aléatoirement avec une distribution uniforme, des arbres de dérivation de G de taille n ? Nous allons expliquer ici comment résoudre ce problème en utilisant des techniques combinatoires bien connues [FS08]. Notons que des techniques plus avancées permettent un calcul plus rapide, comme dans [DZ99]. Pour faciliter la compréhension, on utilise habituellement des lettres majuscules pour nommer les symboles non-terminaux Soit une grammaire algébrique G = (Σ, Γ, S 0, R), un symbole nonterminal X de Γ, et un entier positif i, le nombre d’arbres de dérivation de taille i généré par (Σ, Γ, X, R) est noté x(i) – c’est-à-dire qu’on utilise la lettre minuscule correspondante au symbole initial –. Soit un nombre entier positif n, pour tout symbole S ∈ Γ, on peut calculer la séquence d’entiers positifs s(1), . . . , s(k), . . .. Le calcul récursif de ces s(i) est le suivant : Pour tout entier strictement positif k et toute règle r = (S,w1S 1 . . . wnS nwn+1) ∈ R, avec wj ∈ Σ ∗ et S i ∈ Γ, on pose    βr = 1 + Pn+1 i=1 |wi |, αr(k) = P i1+i2+...+in=k−βr Qj=n j=1 sj(ij) si n , 0, αr(k) = 0 si n = 0 et k , βr , αr(βr) = 1 si n = 0. Il est connu que s(k) = P r∈R∩(S×(Σ∪Γ) ∗ ) αr(k) (cf. [FS08, Théorème I.1]). Par hypothèse, il n’y a pas de règle de la forme (S, T) dans R avec S, T ∈ Γ, donc tous les ij dans la définition de αr sont strictement inférieurs à k. Les s(i) peuvent donc être calculés récursivement.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 32 Considérons par exemple la grammaire ({a, b}, {X}, X, {r1,r2,r3}) avec r1 = (X, XX) r2 = (X, a) et r3 = (X, b). On a βr1 = 1 + 0 = 1, βr2 = 1 + 1 = 2, βr3 = 1 + 1 = 2. Donc x(k) = P i+j=k−1 x(i)x(j) si k , 2, et x(2) = 1 + 1 + P i+j=2−1 x(i)x(j) = 2, sinon. Par conséquent, x(1) = 0, x(2) = 2, x(3) = x(1)x(1) = 0, x(4) = x(1)x(2) + x(2)x(1) = 0, x(5) = x(2)x(2) = 4, etc. . .. Les deux arbres de dérivation de taille 2 sont X | a et X | b . Les quatre arbres de dérivation de taille 5 sont les arbres de la forme X /\ Z1 Z2 , où Z1 et Z2 sont des arbres de dérivation de taille 2. Pour générer des arbres de dérivation de taille n, on doit calculer tous les s(i), pour S ∈ Γ et i ≤ n, avec la méthode ci-dessus. Ce calcul peut être effectué en un temps polynomial. Ensuite, la génération aléatoire consiste à appliquer récursivement l’algorithme décrit dans la figure 2.15. Génération aléatoire Entrée : une grammaire algébrique G = (Σ, Γ, X, R), un nombre entier strictement positif n. Sortie : un arbre de dérivation t de G, de taille n. Algorithme : 1. Soit {r1,r2, . . . ,r`} l’ensemble des éléments de R dont le premier élément est X. 2. Si Pj=` j=1 αrj (n) = 0, alors retourner “Exception”. 3. Choisir i ∈ {1, . . . , `} avec une probabilité Prob(i = j) = αr i (n) Pj=` j=1 αr j (n) . 4. ri = (X, Z1 . . . Zk), avec Zj ∈ Σ ∪ Γ. 5. Le symbole racine de t est X. 6. Les fils de t sont Z1, . . . , Zk dans cet ordre. 7. {i1, . . . , im} = {j | Zj ∈ Γ}. 8. Choisir (x1, . . . , xm) ∈ N m tel que x1 + . . . + xm = n − βri avec une probabilité Prob(x1 = `1, . . . , xm = `m) = Qj=m j=1 zij (` j) αri (n) . 9. Pour tout ij , le ij-ème sous-arbre de T est obtenu en appliquant l’algorithme Génération aléatoire sur (Σ, Γ, Zij , R) et ` j . 10. Retourner t. Figure 2.15 – Algorithme Génération aléatoire Il est connu [FS08] que cet algorithme produit une génération uniforme d’arbres de dérivations de taille n – c’est-à-dire que chaque arbre de dérivation a la même probabilité d’être généré –. Notons qu’une exception est renvoyée à l’étape 2 s’il n’y a aucun élément de la taille donnée. Pour l’exemple présenté précédemment, il n’y a pas d’élément de taille 3, il n’est donc pas possible de générer un arbre de dérivation de taille 3. En exécutant l’algorithme sur cet exemple avec n = 2, à l’étape 1 on considère l’ensemble {r1,r2,r3} puisque toutes ces règles ont X comme élément gauche. Comme αr1 (2) = 0, αr2 (2) = 1, αr3 (2) = 1, à l’étape 3 la probabilité que i = 1 est 0, la probabilité que i = 2 est 1/2 et la probabilité que i = 3 est 1/2. Si la valeur i = 2 est choisie, l’arbre généré a X comme symbole racine et a comme unique fils. L’exécution de l’algorithme avec n = 3 s’arrête à l’étape 2 puisqu’il n’y a pas d’arbre de taille 3. En exécutant l’algorithme sur cet exemple avec n = 5, à l’étape 1 on considère l’ensemble {r1,r2,r3}. Comme αr1 (5) = 4, αr2 (5) = 0, αr3 (5) = 0, la valeur i = 1 est choisie avec une probabilité 1. Par conséquent, l’arbre a X comme symbole racine, et ses deux fils sont étiquetés par X. C’est pourquoi à l’étape 7, l’ensemble considéré est {1, 2}. A l’étape 8, on a n − βr1 = 5 − 1 = 4. La probabilité que i1 = 1 et i2 = 3 est 0 car x(1) = 0. De même, la probabilité que i1 = 3 et i2 = 1 est aussi 0. La probabilité que i1 = 2 etPARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 33 ΣG ={(0, a, 1), (1, c, 5), (5, push(S ), 0), (1, b, 2), (2, e, 4), (4, pop(S ), 6), (6, g, 7), (7, i, 8), (8, pop(S ), 6), (6, h, 9), (9, j, 10), (10, pop(S ), 6)}, et RG ={(T, LRD(6, g, 7)(7, i, 8)), (T, LRD(6, h, 9)(9, j, 10)), (T, (0, a, 1)(1, b, 2)(2, e, 4)), (R, LRD), (R, (0, a, 1)(1, c, 5)(5, push(S ), 0)(0, a, 1)(1, b, 2)(2, e, 4)(4, pop(S ), 6)), (L, (0, a, 1)(1, c, 5)(5, push(S ), 0)), (D, (6, g, 7)(7, i, 8)(8, pop(S ), 6)), (D, (6, h, 9)(9, j, 10)(10, pop(S ), 6))}. Figure 2.16 – Exemple d’une grammaire qui génère des DFA-traces cohérentes i2 = 2 est donc 1. L’algorithme est ensuite exécuté récursivement sur chacun des fils avec n = 2 : chacun des quatre arbres est choisi avec une probabilité 1/4. Puisqu’on peut très simplement représenter un graphe sous la forme d’une grammaire, on peut utiliser cette méthode de génération aléatoire uniforme d’un arbre de dérivation dans une grammaire afin de générer aléatoire-uniformément des chemins dans un graphe. Considérons par exemple l’automate A, sous-jacent au NPDA décrit dans la figure 2.14. Des DFAtraces cohérentes de A sont générées à partir de la grammaire (ΣG, ΓG, T, RG) de la figure 2.16, avec ΓG = {T, L, R, D}. 2.2.4/ D’un NPDA vers une grammaire algebrique ´ Plusieurs algorithmes classiques permettent la transformation d’un NPDA en une grammaire algébrique (par exemple, [Sip96]). Le théorème présenté ci-dessous est une combinaison directe de résultats bien connus sur les PDA. Théorème 2.15 Soit A un NPDA, on peut calculer en temps polynomial une grammaire G, qui satisfait les assertions suivantes : — Le nombre de règles de G est au plus quadratique de la taille de A, et G ne contient aucune règle de la forme (X, Y), avec X et Y qui sont des symboles de la pile. — Il existe une bijection ϕ de l’ensemble des dérivations complètes de G vers l’ensemble des NPDA-traces de A. — L’image par ϕ d’une dérivation complète de G peut être calculée en temps polynomial. Notons que la complexité précise des algorithmes dépend des structures de données choisies, mais qu’elles peuvent toutes être implémentées de manière efficace.II Approximations reguli ´ eres pour l ` ’analyse d’accessibilite´PARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’accessibilite´ 37 Dans cette partie, notre contribution est la définition de deux nouvelles techniques d’approximation pour le model-checking régulier, dans le but de fournir des (semi-)algorithmes efficaces. On calcule des sur-approximations de l’ensemble des états accessibles, avec l’objectif d’assurer la terminaison de l’exploration de l’espace d’états. L’ensemble des états accessibles (ou les surapproximations de cet ensemble) est représenté par un langage régulier, lui même codé par un automate fini. La première technique consiste à sur-approximer l’ensemble des états atteignables en fusionnant des états des automates, en fonction de critères syntaxiques simples, ou d’une combinaison de ces critères (cf. section 4). La seconde technique d’approximation consiste aussi à fusionner des états des automates, mais cette fois-ci à l’aide d’un transducteur (cf. section 5.2). De plus, pour cette seconde technique, nous développons une nouvelle approche pour raffiner les approximations (cf. section 5.3), qui s’inspire du paradigme CEGAR (cf. section 3.4). Les propositions sont évaluées sur des exemples de protocoles d’exclusion mutuelle (cf. section 4.4 et section 5.4).3 Contexte et problematiques ´ 3.1/ Introduction et enonc ´ e du probl ´ eme ` Dans ce chapitre, nous allons présenter le problème d’accessibilité, puis sa traduction dans le cadre plus particulier du model-checking régulier qui en est un cas particulier. Enfin, nous présenterons l’approche par approximations régulières qui est une façon d’aborder le problème de l’analyse d’accessibilité par model-checking régulier. Analyse d’accessibilite´ L’analyse d’accessibilité est une question importante dans la vérification de logiciels, car elle permet d’en assurer la sécurité et la sûreté (c’est-à-dire que quelque chose de mauvais ne se produira pas). Elle consiste à vérifier (prouver) sur une description formelle du système, que certaines confi- gurations peuvent être atteintes. On peut exprimer le problème de la façon suivante : Problème 3.1. Accessibilité Entrée : Un ensemble de configurations initiales I, une relation d’évolution du système R, un ensemble d’états B. Question : Le système décrit par I et R, peut-il atteindre un état de B ? Par exemple, savoir si un point de programme particulier est atteignable est un problème d’accessibilité, de même que de savoir si une machine de Turing reconnaît un langage non vide. Le problème d’accessibilité est indécidable dans la plupart des formalismes. Plusieurs approches ad hoc ont été développées afin de trouver des heuristiques ou de déterminer des formalismes pour lesquels le problème est décidable. Parmi ces approches, l’analyse d’accessibilité symbolique repose sur des représentations finies d’ensembles infinis d’états. Le model checking régulier – abrégé en RMC, pour l’anglais Regular Model Checking – est une approche symbolique utilisant des ensembles réguliers pour représenter des ensembles d’états : I et B sont des langages réguliers, donnés le plus souvent par des automates finis (parfois des expressions régulières) et R est les plus souvent une relation régulière donnée par un transducteur (ou un système de réécriture). Dans ce cadre, le problème d’accessibilité reste indécidable et est abordé des deux façons suivantes : — soit en travaillant sur des classes d’ensembles réguliers et des relations pour lesquelles le problème de l’accessibilité est décidable (voir par exemple [GGP08]), — soit en développant des approches semi-algorithmiques basées sur des accélérations ou des approximations (voir par exemple [DLS01, DLS02]). L’analyse d’accessibilité permet de vérifier des propriétés de sûreté : si l’ensemble d’états B est un ensemble d’états d’erreurs, et que l’analyse d’accessibilité montre que le système ne peut pas atteindre un état de B, alors on a vérifié une propriété de sûreté (c’est une propriété qui dit quePARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 40 quelque chose de mauvais ne doit pas pouvoir se produire, comme par exemple le fait que le train d’atterrissage d’un avion ne doit pas pouvoir être rentré si l’avion est au sol). D’autres types de propriétés, plus complexes, peuvent souvent se recoder dans le cadre de l’analyse d’accessibilité. Model-Checking regulier ´ Le problème de l’analyse d’accessibilité par model-checking régulier sur les mots peut se formaliser ainsi : Problème 3.2. RMC-1 Entrée : Un langage régulier I (ensemble de configurations initiales), une relation calculable R (relation d’évolution du système), un langage régulier B (propriété d’erreur). Question : R ∗ (I) T B = ∅ ? En représentant l’ensemble de configurations initiales par un automate A0, la relation d’évolution du système par un transducteur T, et la propriété d’erreur par un automate B, on peut définir le problème de l’analyse d’accessibilité par RMC sur les mots de la façon suivante : Problème 3.3. RMC-2 Entrée : Deux automates finis A0 et B sur un même alphabet Σ, et un transducteur T sur Σ × Σ. Question : R ∗ T (L(A0)) ∩ L(B) = ∅ ? Comme la sortie dépend de la fermeture réflexive et transitive, on peut supposer sans perte de généralité que pour tout u ∈ Σ ∗ , (u, u) ∈ RT . On supposera donc que toutes les relations étudiées par la suite contiennent l’identité. Depuis presque 20 ans, le model-checking régulier est un domaine de recherche actif en informatique (cf. [CGP00] et [BKe08] pour une vue d’ensemble). De nombreux travaux ont donc traité (et traitent encore) de variantes de ce problème. Par exemple, dans [KMM+97], les auteurs proposent de représenter les configurations possibles d’un tableau de processus sous la forme d’un ensemble régulier de mots – autrement dit, un langage régulier – défini par un automate A, et de représenter l’effet d’une action du système sous la forme d’une règle de réécriture qui modifie l’automate A (un transducteur). Mais ce travail traite uniquement des transducteurs qui représentent l’effet d’une seule application de la transition, et il y a de nombreux protocoles pour lesquels l’analyse d’accessibilité ne se termine pas. Puis dans [WB98], les auteurs présentent l’idée de vérifier différents types de systèmes infinis en les représentant sous la forme de langages réguliers. Les principales méthodes pour contourner le problème de non-terminaison de l’analyse d’accessibilité, et donc pour atteindre un point fixe, sont l’accélération [JN00, BJNT00, DLS01, DLS02, AJNd03, BLW03], l’élargissement (extrapolation) [BJNT00, Tou01, Leg12], et l’abstraction d’automates [BHV04]. Dans [BJNT00], les auteurs présentent le concept du model-checking régulier, et s’intéressent au calcul des états atteignables à partir d’un ensemble donné d’états initiaux, ainsi qu’au calcul de la fermeture transitive de la relation de transition. Ils proposent pour cela une technique s’appuyant sur la théorie des automates, et une technique d’accélération. Cet article est l’un des premiers à présenter la notion de model-checking régulier, et il est donc souvent utilisé comme référence pour les travaux dans ce domaine. Il s’intéresse au calcul des états atteignables à partir d’un ensemble donné d’états initiaux, et de la fermeture transitive de la relation de transition. Deux techniques y sont proposées. La première technique, basée sur la théorie des automates, consiste à considérer la relation d’évolution du système comme un transducteur T, à construire une matrice qui regroupePARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 41 tous les chemins possibles de T, à considérer cette matrice comme un unique transducteur T ∗ (dont chaque colonne est un état) que l’on va minimiser et déterminiser. Mais cette technique n’est applicable qu’à certains protocoles réguliers, car pour pouvoir construire la matrice qui regroupe tous les chemins possibles de T, il faut que celui-ci ne contienne aucune boucle. La deuxième technique consiste à deviner automatiquement l’ensemble obtenu après application d’une relation d’évolution T, à partir d’un ensemble régulier donné, puis à vérifier si celui-ci est correct. Pour deviner cet ensemble, on compare les ensembles φ et T(φ) afin de détecter une éventuelle croissance (par exemple T(φ) = φ.Λ pour un Λ régulier quelconque), puis à extrapoler en faisant l’hypothèse que chaque application de T aura le même effet. On fait ensuite un test de point fixe pour s’assurer que l’ensemble obtenu est bien une sur-approximation de T ∗ (φ). D’après l’article, cette technique a été appliquée sur les protocoles d’exclusion mutuelle de Szymanski, Burns, Dijkstra, sur le protocole de Bakery de Lamport et sur le Token passing protocol, mais seule l’application au Token passing protocol est présentée. Cette technique n’est pas non plus applicable à tous les protocoles réguliers : la relation T doit préserver la taille des mots et doit être noethérienne pour s’appliquer à un mot qu’un nombre fini de fois. Dans [AJNd03], les auteurs proposent des améliorations de ces techniques qui réduisent la taille des automates intermédiaires, lors du calcul de la clôture transitive. C’est dans la même confé- rence que Sébastien Bardin, Alain Finkel, Jérôme Leroux et Laure Petrucci proposent leur outil de vérification FAS T (pour Fast Acceleration of S ymbolic Transition systems) [BFLP03]. L’outil FAS T tente de calculer R ∗ T (I) – c’est-à-dire l’ensemble exact des configurations accessibles – en se basant sur des accélérations du transducteur T. Dans [BHV04], les auteurs proposent une technique de vérification des systèmes infinis paramétrés qui combine du model-checking régulier et de la vérification par abstraction. D’après cet article, l’explosion des états est un des plus gros problèmes du model-checking régulier, et une des sources de ce problème vient de la nature même des techniques de model-checking régulier de l’époque (2004). Ces techniques tentent de calculer l’ensemble d’accessibilité exact. Il propose donc de remplacer les techniques d’accélération précises par un calcul d’abstraction qui, lorsqu’un point fixe sera atteint, représentera une sur-approximation de l’ensemble des états atteignables. L’article propose une abstraction par fusion d’états, qui est assez proche de la technique qu’on a utilisée. Il présente également la possibilité de raffiner l’abstraction (ce qui, dans notre méthode, revient à durcir le critère de fusion avec un ET logique), au cas où l’approximation contiendrait un état d’erreur. Mais ils ne peuvent raffiner l’abstraction que si la relation ∼ sur les états est de la forme suivante : soit A un automate, p et q deux états de A, et P un ensemble fini d’automates, p ∼ A q si et seulement si quelque soit P de P, L(P) T L(A Right,p ) , ∅ si et seulement si L(P) T L(A Right,q ) , ∅ (les automates A Right,p et A Right,q sont définis dans ce mémoire, dans la section 4.2). Pour raffiner l’abstraction avec des relations de cette forme, l’article propose d’ajouter des automates dans P. Cette technique est applicable sur une grande variété de systèmes, mais ne laisse pas de liberté concernant la forme des critères de fusion (on peut seulement décider du contenu de P). Dans [LGJJ06], les auteurs s’intéressent à l’analyse et la vérification de systèmes communiquants par des files de communication non bornées. Ils proposent une méthode d’analyse et de vérifi- cation de systèmes communiquants (ce sont des systèmes formés de processus séquentiels, communiquant par des files de communication non bornées), qui consiste à travailler sur des abstractions des systèmes en question. Dans le cadre de cet article, les processus sont d’états fi- nis, et l’alphabet des messages échangés est également fini. Les protocoles étudiés sont le protocole de Connexion/Déconnexion, le Buffer infini, et l’Alternating Bit Protocol, et ils sont représentés par des systèmes de transitions étiquetés. Les auteurs proposent un treillis abstrait fondé sur les langages réguliers, afin d’étudier les systèmes avec une seule file de communication, puis ils généralisent leur proposition aux systèmes avec plusieurs files. Récemment, dePARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 42 nouveaux résultats en model-checking régulier ont été obtenus pour des protocoles spécifiques comme les CLP [FPPS11], les systèmes communiquants par des files [LGJJ06], les langages d’arbres [AJMd02, BT11], ou la vérification de chaînes relationnelles utilisant des automates multi-pistes [YBI11]), en utilisant des techniques spécifiques aux catégories de systèmes données [Boi12]. Approximations reguli ´ eres ` De nombreuses méthodes de vérification proposées jusqu’ici sont des méthodes exactes, or il est souvent difficile, voire impossible, de trouver un point fixe de façon exacte, et donc de conclure. Puisque la valeur exacte de l’ensemble des états atteignables par le système – noté R ∗ (I) (cf. fi- gure 3.1) – n’est pas forcément calculable, nous utilisons l’approche par approximations régulières. Cette approche est très utilisée pour attaquer le problème du model-checking régulier, et consiste à calculer un langage régulier K, qui contient R ∗ (I). On dit alors que K est une sur-approximation de R ∗ (I). I R(I) ... B R ∗ (I) ? ? ? K Figure 3.1 – Approche par sur-approximation L’enjeu est de démontrer que R ∗ (I) T B = ∅. Si on a K T B = ∅, on peut l’affirmer. Mais si après calcul, K T B , ∅, alors on ne peut rien déduire sur R ∗ (I) T B. On cherchera donc une sur-approximation moins grossière de R ∗ (I). La difficulté – et l’objectif même de cette partie de la thèse – est de trouver une façon automatique de calculer un ensemble K, qui permette de conclure le plus souvent possible (chaque fois que possible serait l’idéal). Or, les résultats d’une méthode de calcul par rapport à une autre diffèrent beaucoup selon le protocole qu’on souhaite vérifier. 3.2/ Technique proposee´ Nos contributions visent à améliorer la méthode générique de [BHV04] en donnant des moyens de construire des sur-approximations en fusionnant des états abstraits du système (et non du transducteur, qui n’est jamais modifié). Notre méthode utilise une approche par sur-approximations successives, qui consiste à calculer RT (I) puis à en calculer une sur-approximation I1, à calculer ensuite RT (I1) puis à en calculer une sur-approximation I2, ... et ainsi de suite jusqu’à atteindre un point fixe, qui sera notre surapproximation K de R ∗ T (I) (cf. figure 3.2). Malgré le fait que l’approche par sur-approximations successives augmente les chances de trouver un point fixe, on peut avoir besoin d’appliquer le transducteur de nombreuses fois avant d’en trouver un, ce qui multiplie à chaque fois le nombre d’états de l’automate obtenu. En fusionnantPARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 43 automate A0 langage I = L(A0) automate Ae 1 = T(A0), langage RT (I) = L(Ae 1 ) automate A1 = C(T(A0)) langage I1 = L(A1) automate Ae 2 = T(A1), langage RT (I1) = L(Ae 2 ) Ii = L(Ai) . . . automate An = C(T(An−1)) langage In = L(An) automate Ae n+1 = T(An), langage RT (In) = L(Ae n+1 ) automate An+1 = C(T(An)) langage In+1 = L(An+1) In+1 = In =⇒ K = In application du transducteur (relation d’évolution) fusion d’états (sur-approximation) . . . . . . Figure 3.2 – Sur-approximations successives des états entre eux, la sur-approximation effectuée à chaque étape (flèches en diagonale sur la figure 3.2) doit donc également empêcher l’explosion du nombre d’états. Afin de déterminer les états à fusionner, on définit un ou plusieurs critères de fusion, qui sont les points communs que doivent avoir deux états pour être fusionnés. Ces critères sont définis sous la forme de relations entre les états (deux états seront fusionnés s’ils sont en relation), qui sont elles-même obtenues à partir de fonctions d’approximations (cf. définition 2.3). Le choix de bons critères de fusion, et donc de bonnes fonctions d’approximation, est extrêmement important. Si le critère est trop large l’approximation reconnaîtra des mots de B (la propriété d’erreur) avant d’atteindre un point fixe, et s’il est trop restrictif, on ne fusionnera pas d’états et la taille de l’automate risque d’exploser. Il faut également que les critères soient rapidement calculables, et qu’ils puissent s’appliquer à tous types de problèmes réguliers (cf. définition 2.2). 3.3/ Calcul de la sur-approximation Dans cette section, on explique comment calculer une sur-approximation K de R ∗ T (I) (cf. fi- gure 3.2), à partir d’une fonction d’approximation F. Proposition 3.4 Pour tout automate A, si F est une fonction d’approximation isomorphismecompatible, alors la séquence (F n (A))n∈N est ultimement constante, à isomorphisme près. Notons CF(A) la limite de (F n (A))n∈N. Si pour tout automate A et toute paire d’états p, q de A, on peut vérifier en temps polynomial si p ∼ A F q, alors CF(A) peut également être calculé en temps polynomial. Preuve. Soit A un automate et ∼ une relation d’équivalence sur les états de A. Si ∼ n’est pas l’identité, alors A/∼ a strictement moins d’états que A. Sinon, A/∼ est isomorphe à A. C’est pourquoi, dans la séquence (F n (A))n∈N, le nombre d’états des automates diminue et si F k (A) etPARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 44 F k+1 (A) ont le même nombre d’états, alors (F n (A))n≥k, est finalement constant, à l’isomorphisme près. Si l’équivalence des états est calculée en temps polynomial, alors l’automate quotient peut également être calculé en temps polynomial : il suffit de calculer les composantes fortement connexes, du graphe de la relation ∼. De plus, puisque la convergence est obtenue en au plus n états, où n est le nombre d’états de A, CF(A) peut être calculé en temps polynomial. Exemple 3.5. La figure 3.3 représente un automate A, ainsi que le calcul de CRight(A) (la relation Right est définie plus tard, dans la section 4.2). 1 2 3 4 5 6 a a b b b b b (a) A 1 3 4 256 a a b b b (b) Right(A) 1 3 2456 a b b (c) Right2 (A)=CRight(A) Figure 3.3 – Calcul de CRight(A) Semi-Algorithme PointFixe Entrée : A, T, B, F Si L(CF(T(A))) ∩ L(B) , ∅ alors retourner Non-conclusif FinSi Si L(CF(T(A))) = L(A) alors retourner Sûr FinSi Retourner PointFixe(CF(T(A)),T,B,F) Figure 3.4 – Semi-algorithme PointFixe Dans le semi-algorithme PointFixe (cf. figure 3.4), soit un automate A (état du système), un transducteur T (relation de transition), un automate B (propriété d’erreur), et une fonction d’approximation isomorphisme-compatible F (critère de fusion), la première vérification (le vide) peut être effectuée en temps polynomial. Malheureusement, l’égalité des langages ne peut pas être vérifiée en temps polynomial (les automates impliquées ne sont pas déterministes). Cependant, des algorithmes récemment développés [DR10, ACH+10, BP12] permettent de résoudre le problème du test de l’inclusion de langages (et donc de l’égalité) très efficacement. Notons également que le test d’égalité peut être remplacé par un autre test – comme l’isomorphisme ou encore la (bi)simulation – qui implique l’égalité ou l’inclusion des langages, puisque par construction L(A) ⊆ L(CF(T(A))). Dans ce cas le test serait plus rapide, mais la convergence moins rapide. Proposition 3.6 Le semi-algorithme PointFixe est correct : s’il retourne Sûr, alors R∗ T (L(A))∩ L(B) = ∅. Preuve. Si le semi-algorithme PointFixe retourne Sûr, alors on a calculé un automate A0 tel que L(A0 ) = L(CF(T(A0 )))). On prouve tout d’abord que RT (L(A0 )) = L(A0 ) : puisque l’identité est inclue dans RT , il suffit de prouver que RT (L(A0 )) ⊆ L(A0 ). Si u ∈ RT (L(A0 )), alors APISENSER : une plate-forme r´epartie pour la conception,le d´eploiement et l’ex´ecution de campagnes de collecte de donn´ees sur des terminaux intelligents Nicolas Haderer To cite this version: Nicolas Haderer. APISENSER : une plate-forme r´epartie pour la conception,le d´eploiement et l’ex´ecution de campagnes de collecte de donn´ees sur des terminaux intelligents. Mobile Computing. Universit´e des Sciences et Technologie de Lille - Lille I, 2014. French. HAL Id: tel-01087240 https://hal.inria.fr/tel-01087240 Submitted on 25 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Département de formation doctorale en informatique UFR IEEA École doctorale SPI Lille APISENSE® : une plate-forme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données sur des terminaux intelligents THÈSE présentée et soutenue publiquement le 05/11/2014 pour l’obtention du Doctorat de l’Université Lille I (spécialité informatique) par Haderer Nicolas Composition du jury Rapporteurs : Chantal Taconet, TELECOM SudParis, France Ernesto Exposito, INSA Toulouse, France Examinateurs : Stéphane Frénot, INSA Lyon, France Luigi Lancieri, Université Lille I, France Directeur : Lionel Seinturier, Université Lille I, France Co-encadrant : Romain Rouvoy, Université Lille I, France Laboratoire d’Informatique Fondamentale de Lille – Inria Lille - Nord Europe UMR Lille 1/CNRS 8022R É S UM É Le mobile crowdsensing est une nouvelle forme de collecte de données exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour collecter massivement des données environnementales ou comportementales d’une population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans de nombreux domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements socioculturels. Cependant, le mobile crowdsensing n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que faire face à l’hétérogénéité des plateformes mobiles disponibles. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au mobile crowdsensing pour adresser les limitations liées au développement, au déploiement et à l’exécution de campagnes de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. Plus particulièrement, APISENSE® propose un environnement distribué favorisant le développement et le déploiement rapides de campagnes de collecte, tout en prenant en considération des contraintes telles que la protection de la vie privée des utilisateurs ou encore les ressources énergétiques limitées de leurs terminaux. Pour atteindre ces objectifs, APISENSE® repose sur le modèle de composant SCA et sur l’ingénierie des lignes de produits logiciels, offrant ainsi un environnement modulaire et facilement configurable pour supporter une grande diversité de campagnes de collecte. Un modèle de programmation de haut niveau a également été proposé permettant de s’affranchir de toute la complexité liée aux développements d’applications de collecte mobiles. APISENSE® a été utilisé pour réaliser une campagne de collecte de données déployée auprès d’une centaine d’utilisateurs au sein d’une étude sociologique, et évalué à travers des expériences qui démontrent la validité, l’efficacité et le passage à échelle de notre solution. iiiA B S T R A C T Mobile crowdsensing is a new form of data collection that takes advantage of millions smart devices already deployed throughout the world to collect massively environmental or behavioral data from a population. Recently, this type of data collection has attracted interest from a large number of industrials and academic players in many areas, such as the study of urban mobility, environmental monitoring, health or the study of sociocultural attitudes. However, mobile crowdsensing is in its early stages of development, and many challenges remain to be addressed to take full advantage of its potential. These challenges include privacy, limited energy resources of devices, development of reward and recruitment models to select appropriates mobile users and dealing with heterogeneity of mobile platforms available. In this thesis, we aim to reconsider the architectural design of current mobile crowdsensing systems to provide a simple and effective way to design, deploy and manage data collection campaigns. The main contributions of this thesis are organize around APISENSE®, the resulting platform of this research. In particular, APISENSE® offers a distributed environment based on the SCA component model and software product line engineering , providing a modular and flexible environment to support a wide variety of data collection campaigns. Futhemore, APISENSE® takes into account constraints, such as protecting the privacy of users or limited energy resources devices. We also propose a high-level programming model to get rid of the complexity associated with the development of mobile data collection applications. APISENSE® has been used to carry out a data collection campaign deployed over hundred of users in a sociological study and evaluated through experiments demonstrating the validity, effectiveness and scalability of our solution. vTA B L E D E S M AT I È R E S 1 introduction 9 1.1 Contexte 9 1.2 Problématiques 10 1.3 Objectif du manuscrit 12 1.4 Contributions 13 1.5 Plan du manuscrit 15 1.6 Publications 16 I État de l’art 19 2 systèmes de collecte de données 21 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 12.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 II Contributions 53 3 collecte mobile de données 55 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 4 collecte répartie de données 91 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 24.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 III Évaluations 127 5 pratiques culturelles et usages de l’informatique connectée 129 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 6 évaluation du modèle collaboratif 145 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 IV Conclusion 157 7 conclusion 159 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 3bibliographie 165 4TA B L E D E S F I G U R E S Figure 1 Vue d’ensemble de APISENSE® 15 Figure 2 Développement d’une application mobile avec FunfInABox 35 Figure 3 Architecture de Medusa [55] 41 Figure 4 Architecture de PRISM [16] 44 Figure 5 Architecture de Bubble-sensing [45] 45 Figure 6 Architecture de Anonysense [62] 48 Figure 7 Tableau comparatif des plate-formes MCS 52 Figure 8 Interface de Programmation APISENSE 61 Figure 9 Exemple de capture d’écran d’un retour utilisateur 67 Figure 10 Architecture de l’intergiciel mobile 69 Figure 11 Interaction de la couche d’exécution 69 Figure 12 Règles de confidentialité 75 Figure 13 Exemple de contenu web disponible via le FeedbackManager 78 Figure 14 Flux de données de l’expérience Manipulation de Lego NXT 82 Figure 15 Impact d’APISENSE sur la consommation énergétique 88 Figure 16 Impact des capteurs sur la consommation énergétique 89 Figure 17 Vue d’ensemble d’APISENSE® 93 Figure 18 Architecture SCA du serveur central 96 Figure 19 Modèle de caractéristiques d’une campagne de collecte 102 Figure 20 Architecture initiale d’un nœud de collecte 107 Figure 21 Processus de génération d’une architecture SCA 108 Figure 22 Architecture SCA d’une campagne de collecte 109 Figure 23 Interaction des composants APISENSE® 111 Figure 24 Exemple d’extension : Export des données au format KML 114 Figure 25 Composant SCA responsable du recrutement collaboratif 120 Figure 26 Distribution des capteurs virtuels 121 Figure 27 Données collectées par l’étude PRACTIC 132 Figure 28 Exemple de retour utilisateur PRACTIC 137 Figure 29 Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 138 5Figure 30 Nombre d’inscriptions par jour à PRACTIC 140 Figure 31 Diversité des équipements mobiles 141 Figure 32 Taux de participation à la collecte opportuniste 141 Figure 33 Taux de participation à la collecte participative et opportuniste 142 Figure 34 Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 142 Figure 35 Architecture du simulateur de traces de mobilité 147 Figure 36 Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique 149 Figure 37 Comparaison de la couverture géographique selon différentes périodes de la journée 150 Figure 38 Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte 152 Figure 39 Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153 6L I S T E D E S TA B L E A U X Table 1 Liste des fonctions d’observation d’événements prédéfinis. 61 Table 2 Liste des paramètres d’une fonction de rappel 61 Table 3 Configuration de l’observation de la position d’un utilisateur 62 Table 4 Liste des fonctions d’un objet de souscription 64 Table 5 Liste des fonctions de la façade de collecte 65 Table 6 Liste des fonctions de la façade dédiée à la création des questionnaires 66 Table 7 Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) 80 Table 8 Tableau décrivant la qualité du système de classification 85 Table 9 Comparaison de l’expressivité et du nombre de lignes de code 87 Table 10 Propriétés définissant une expérience de collecte 97 Table 11 Interface de programmation dédiée à la définition des campagnes de collecte communautaires. 116 Table 12 Façade utilisée pour les besoins de l’application PRACTIC 138 71 I N T R O D U C T I O N 1.1 contexte La dernière génération de terminaux intelligents tels que les smartphones ou les tablettes tactiles est rapidement devenue omniprésente dans notre quotidien. On recense, actuellement, plus d’un milliard de smartphones à travers le monde et ce nombre ne va cesser d’augmenter [42]. Non seulement dotés d’une grande capacité de calcul et d’une connexion Internet en continu, ces terminaux sont désormais programmables et équipés d’un grand nombre de capteurs sophistiqués permettant de prendre des images, capter des sons, mesurer la température ou la pression atmosphérique tout en donnant la position géographique. De ce fait, leurs usages permettent de générer de nombreuses traces numériques d’activités, capables d’identifier nos habitudes, nos relations sociales ainsi que l’environnement dans lequel on évolue. De par leurs fortes présences dans notre société et leurs hautes prouesses technologiques, ces terminaux ont ouvert la voie à une nouvelle forme de collecte de données à grande échelle, récemment appelée le Mobile Crowd Sensing (MCS) [27]. Plus particulièrement, le MCS fait référence à l’ensemble des applications qui impliquent des citoyens ordinaires, munis de leurs terminaux intelligents, afin de collecter et de partager des données dans le but de mesurer des phénomènes d’un intérêt commun. Ces dernières années, de nombreuses recherches ont été menées pour tenter d’exploiter le potentiel du MCS dans de nombreux domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement ou la santé [39, 11]. Quelques exemples d’applications novatrices dans ce secteur comprennent la collecte et le partage de données concernant la qualité de l’air [19], le trafic routier [51], la pollution sonore [47], les performances cyclistes [20], ou encore des informations relatives aux prix des produits de consommation [17]. 91.2 problématiques Comme la revue de la littérature l’indique, le MCS n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel [39, 27, 66]. Ces défis sont particulièrement liés à l’implication d’individus rationnels, qui sont au centre du système de collecte de données. Cela demande de prendre en considération de nombreux aspects non-fonctionnels qui ne sont pas directement liés à la collecte de données difficiles en elle-même, rendant par conséquent le développement de ces systèmes encore difficile. Plus particulièrement, il est nécessaire de prendre en compte les points suivants : énergie : Bien que la dernière génération des terminaux intelligents continue de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces terminaux restent limitées. Sans une gestion rigoureuse de l’énergie consommée par les applications de collecte, la batterie de ces terminaux peut s’épuiser en quelques heures, décourageant ainsi les individus à installer ces applications. respect de la vie privée : Sans un mécanisme de protection approprié, les applications mobiles peuvent se devenir de parfaits espions, en révélant potentiellement des informations privées sur leur propriétaire. Il est par exemple possible qu’elles puissent enregistrer des conversations intimes ou prendre des photos d’une scène privée, d’identifier des trajets quotidiennement empruntés par le propriétaire du terminal et d’observer ses principaux lieux de vie tels que son domicile ou son lieu de travail. Ce point représente également un frein majeur pour l’acceptation de ces applications par les individus. D’un autre coté, certaines de ces données peuvent se révéler indispensables pour l’objectif de la collecte de données. compromis : Prendre en compte ces deux derniers points demande généralement le développement d’algorithmes sophistiqués permettant de faire un compromis entre l’énergie consommée par les applications mobiles, leur niveau d’intrusion dans la vie privée des individus et la qualité des données collectées. diversité : De plus, les développeurs doivent également faire face à la diversité des systèmes d’exploitations mobiles disponibles sur le marché (par ex. Android, iOS). Pour déployer une application auprès d’un grand nombre d’individus, les développeurs doivent généralement étudier et développer une application pour chacun de ces systèmes, entraînant par conséquent un coût important (c.-à-d. temps de développement, monétaire). 10passage á l’échelle : Finalement, ces systèmes doivent également faire face au défi de collecter une grande quantité de données reportées par des utilisateurs répartis à travers le monde. De ce fait, déployer une application auprès de plusieurs millions d’utilisateurs qui collectent et propagent continuellement des données vers un serveur serait inefficace, et demanderait des ressources importantes en terme de CPU, de mémoire et d’espace de stockage de l’infrastructure hébergeant l’application serveur pour stocker et analyser ces données. En outre, ces applications peuvent générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. Dans ce contexte, il est nécessaire de mettre en place un modèle de déploiement adapté pour recruter les bons utilisateurs au bon moment, capable de collecter seulement les données utiles à la campagne de collecte. À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisables dans un contexte non anticipé [6]. Ces systèmes ont été conçus complètement indépendamment les uns des autres, ne partageant aucun module logiciel commun, alors qu’ils ont à faire face à des problématiques communes. La mise en place d’une nouvelle campagne de collecte demande généralement de développer un nouveau système à partir de zéro, pouvant entraîner la négligence de certains aspects non fonctionnels, comme protéger la vie privée des individus, à cause de contrainte de temps ou une expertise limitée dans ce domaine. Ce manque d’approche réutilisable, également pointé du doigt dans la littérature [39, 27, 60, 66], entrave ainsi l’adoption du MCS par de nombreux acteurs intéressés par ce type de collecte. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiées au MCS pour adresser les limitations identifiées ci-dessus liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Plus particulièrement, l’objectif des travaux de cette thèse est de proposer une plate-forme générique, favorisant le développement et le déploiement rapides de campagnes de collecte de données pouvant être menées dans une grande variété de domaines. 111.3 objectif du manuscrit Comme nous l’avons décrit dans la section précédente, le développement d’applications utilisant le MCS comme source de collecte de données est une tâche complexe, nécessitant une grande expertise. Toutefois, pour ouvrir cette forme de collecte à de nombreux acteurs académiques et industriels, nous proposons dans cette thèse une plate-forme générique qui facilite le développement et le déploiement de ces applications de collecte. Plus particulièrement, nous adressons dans cette thèse les points suivants : Simplifier le développement des applications de collecte Le premier défi concerne le développement des applications de collecte. Actuellement, ce développement nécessite une grande expertise dans les systèmes d’exploitation des terminaux mobiles disponibles sur le marché. Pour simplifier leur développement, il est nécessaire de proposer un modèle de programmation nouveau fournissant une abstraction complète de ces systèmes d’exploitation. Dans ce contexte, les principaux défis sont de proposer un modèle : i) assez général pour supporter une grande variété d’activités de collecte qui peuvent impliquer une grande variété de capteurs, ii) permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur, iii) et finalement portable pour être en mesure de s’exécuter sur les différents systèmes d’exploitation. D’autre part, il est nécessaire de fournir un environnement fiable assurant la confidentialité des utilisateurs, efficace pour ne pas empêcher une utilisation normale des terminaux mobiles et faciles d’utilisation pour les utilisateurs voulant participer aux collectes de données. Mise en œuvre d’une plate-forme générique de collecte de données Le deuxième défi concerne l’architecture de la plate-forme responsable du déploiement des applications de collecte, de la persistance et de l’analyse des données collectées. La plupart des plate-formes proposées actuellement sont souvent monolithiques, donnant très peu ou pas de possibilités de personnalisation. Cependant, les applications de collectes peuvent être menées dans une grande variété de domaines, nécessitant diffé- 12rents services de l’application serveur pour analyser et stocker les données collectées ou encore déployer ces applications. Pour prendre en compte cette diversité, la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture mise en œuvre. Cela demande par conséquent de proposer un modèle identifiant les points communs et les différentes exigences des applications de collecte qui peuvent être réalisées. Ce modèle doit s’appuyer sur les bonnes pratiques de l’ingénierie logiciel pour fournir un cadre logiciel modulaire et configurable, et être utilisé simplement par les différents acteurs voulant mener de nouvelles collectes de données pour leurs permettre d’exprimer leurs exigences. D’autre part, la plate-forme doit être capable de passer à l’échelle, c’est-à-dire d’être capable d’impliquer un grand nombre d’utilisateurs mobiles ainsi qu’un grand nombre d’acteurs voulant définir de nouvelles collectes d’un grand volume de données. 1.4 contributions En réponse à ces défis, ces travaux ont abouti à la définition, l’implémentation et l’évaluation d’une plate-forme baptisée APISENSE®. La finalité de APISENSE® est de permettre une mise en place rapide de campagnes de collectes de données à travers des terminaux mobiles intelligents. Nous proposons ici une vue d’ensemble de la solution proposée illustrée par la figure 1. APISENSE® distingue deux rôles évoluant dans la plate-forme. Le premier, appelé simplement utilisateur, peut être un acteur voulant définir et déployer de nouvelles campagnes de collecte de données à travers des terminaux mobiles. Les utilisateurs peuvent utiliser un nœud de collecte dédié (DataGathering Node), qui peut être déployé sur une infrastructure publique ou privée selon leur exigence, et se servir des services fournis par celui-ci pour définir de nouvelles tâches de collecte grâce à un langage de script dédié, déployer la tâche à travers un sous-ensemble d’individus ainsi qu’exploiter ou exposer les données collectées (par ex. visualisation, analyse). Le second rôle, appelé participant, est un individu possédant un terminal mobile. Les participants peuvent utiliser une application mobile dédiée pour télécharger les tâches de collecte, les exécuter dans un environnement sécurisé et automatiquement propager les données collectées. Dans APISENSE®, la mise en relation entre les nœuds de collecte et les participants est assurée par le serveur central (Central Server). Dans un sens, le serveur central peut être perçu comme un magasin dédié aux tâches de collecte. Typiquement, son rôle est 13d’assurer le déploiement des tâches de collecte soumises par les nœuds de collecte, et également d’assurer une première couche d’anonymat des participants. Les objectifs présentés dans la section précédente sont adressés avec APISENSE® de la manière suivante : • À l’issue d’une étude approfondie des architectures présentées dans la littérature (cf. chapitre 2 section 2.3), nous avons proposé un modèle permettant de représenter la variabilité des systèmes responsables du développement et du déploiement de campagnes de collectes de données (cf. chapitre 3 section 4.4). Ce modèle est ensuite fourni aux utilisateurs leur permettant de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. Une application serveur dédiée (c.-à-d. DataGathering Node dans la figure 1) est ensuite générée suite aux exigences définies, fournissant un ensemble de services permettant de développer et de déployer de nouvelles campagnes de collecte, d’assurer la persistance des données collectées par les dispositifs mobiles ainsi que de connecter des services additionnels pour extraire ou traiter ces données. • Nous avons défini un modèle de programmation de haut niveau permettant de s’affranchir de toute la complexité liée aux développements mobiles. Basée sur un langage de script, cette abstraction a été conçue pour être assez générale pour supporter une grande variété d’applications de collecte, facilement accessible pour des utilisateurs ayant très peu d’expertise en programmation mobile, et facilement portable pour être exécutée dans différents environnements mobiles (par ex. Android, iOS, Window Mobile)(cf. chapitre 3 section 3.3). • Pour assurer l’exécution des campagnes de collecte définies par notre modèle de programmation, nous proposons un environnement d’exécution dédié aux utilisateurs mobiles. Cet environnement est responsable du téléchargement, de l’exécution des applications de collectes et de la propagation des données collectées (cf. chapitre 3 section 3.4). Principalement, cet environnement met l’accent sur la consommation énergétique liée à l’exécution d’une campagne de collecte et la protection de la vie privée des utilisateurs. • Nous proposons des modèles et des algorithmes dédiés à l’optimisation de l’exécution de campagnes de collecte. L’optimisation proposée réside en deux points. Pour le premier, nous proposons un modèle de déploiement de tâches de collecte contextuel, permettant d’attribuer une application de collecte à un individu en fonction de propriétés temporelles, géographiques et de capacité 14de détection. Pour le second, nous proposons un algorithme permettant de coordonner l’exécution des tâches de collecte, entre les dispositifs répondant aux mêmes propriétés, afin d’équilibrer les coûts énergétiques entre les terminaux et de diminuer la redondance des données collectées(cf. chapitre 4 section 4.5). Figure 1 – Vue d’ensemble de APISENSE® 1.5 plan du manuscrit Ce manuscrit est divisé en quatre parties. La première partie donne une vue d’ensemble de l’état de l’art dans le domaine du Mobile crowdsensing. La seconde partie décrit les contributions de ce manuscrit. La troisième porte sur la validation des contributions proposées. Et finalement la quatrième conclut ce manuscrit et décrit les perspectives issues des travaux de cette thèse. Plus particulièrement, la suite de ce document est organisé comme suit. Partie 1 : État de l’art Chapitre 1 : Systèmes de collecte de données Ce chapitre a pour objectif de donner dans un premier un temps une vison plus approfondie du Mobile crowdsensing ainsi que ses problématiques. Nous décrivons par la suite des travaux proches à ceux proposés dans cette thèse et nous identifions leurs limitations. 15Partie 2 : Contributions Chapitre 3 : Collecte mobile de données Ce chapitre traite de l’environnement mobile de APISENSE®. Il décrit tout d’abord le modèle de programmation proposé permettant de minimiser le coût du développement des applications de collecte de données. Par la suite, il présente l’architecture de l’environnement mobile dédié à l’exécution des applications de collecte. Chapitre 4 : Collecte répartie de données Ce chapitre présente l’architecture et les choix d’implémentation de l’environnement serveur APISENSE® permettant de déployer des applications de collecte ainsi que d’exploiter les données collectées. Partie 3 : Validations Chapitre 5 : Pratiques culturelles et usages de l’informatique connectée Ce chapitre présente une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein d’une étude sociologique nommée PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Chapitre 6 : Performance et efficacité de APISENSE® présente une validation quantitative sur les performances de APISENSE® Partie 4 : Conclusion Chapitre 7 : Conclusion Finalement, ce chapitre conclut ce manuscrit et expose les perspectives des travaux présentés. 1.6 publications Les travaux de cette thèse ont été réalisés au sein de l’équipe SPIRALS commune à Inria et à l’Université Lille 1 au sein de l’UMR LIFL (Laboratoire d’Informatique Fondamentale de Lille). Ils ont donné lieu aux publications scientifiques suivantes. Conférence International • Dynamic Deployment of Sensing Experiments in the Wild Using Smartphones. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. In 13th International IFIP 16Conference on Distributed Applications and Interoperable Systems (DAIS), pages 43-56. • A Federated Multi-Cloud PaaS Infrastructure. Fawaz Paraiso, Nicolas Haderer, Philippe Merle, Romain Rouvoy, Lionel Seinturier. In 5th IEEE International Conference on Cloud Computing (2012), pages 392-399. Chapitre de livre • A Cloud-based Infrastructure for Crowdsourcing Data from Mobile Devices. Nicolas Haderer, Fawaz Paraiso, Christophe Ribeiro, Philippe Merle, Romain Rouvoy, Lionel Seinturier Wenjun Wu. Cloud-based Software Crowdsourcing, Springer, 2014 (To appear) Workshop • A preliminary investigation of user incentives to leverage crowdsensing activities. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. 2nd International IEEE PerCom Workshop on Hot Topics in Pervasive Computing (PerHot) (2013), pp. 199-204. • Towards Multi-Cloud Configurations Using Feature Models and Ontologies. Clément Quinton, Nicolas Haderer, Romain Rouvoy and Laurence Duchien. In Proceedings of the 1st International Workshop on Multi-Cloud Applications and Federated Clouds, Multi-Cloud’13. Prague, Czech Republic, 22 April 2013, pp. 21-26. Vulgarisation scientifique • APISENSE : Crowd-Sensing Made Easy. Nicolas Haderer, Romain Rouvoy, Christophe Ribeiro, Lionel Seinturier. ERCIM News, ERCIM, 2013, Special theme : Mobile Computing, 93, pp. 28-29. • Le capteur, c’est vous ! Nicolas Haderer, Christophe Ribeiro, Romain Rouvoy, Simon Charneau, Vassili Rivron, Alan Ouakrat, Sonia Ben Mokhtar, Lionel Seinturier L’Usine Nouvelle, L’Usine Nouvelle, 2013, 3353, pp. 74-75 • Campagne de collecte de données et vie privée. Nicolas Haderer, Miguel Nuñez Del Prado Cortez, Romain Rouvoy, Marc-Olivier Killijian and Matthieu Roy. 3ème Journées du GDR CNRS GPL (2012), pp. 253-254. Rapport de recherche • AntDroid : A distributed platform for mobile sensing. Nicolas Haderer, Romain Rouvoy, Lionel Seinturier. [Research Report], 2012, pp. 27. RR-7885 17Première partie État de l’art 192 S Y S T ÈM E S D E C O L L E C T E D E D O N N É E S Sommaire 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 2.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 212.1 mobile crowdsensing 2.1.1 Qu’est ce que le Mobile crowdsensing ? En 2010, Ganti et al. définissent le Mobile crowdsensing comme la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents qui, collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun". Typiquement, le MCS offre de nombreux avantages par rapport aux méthodes classiques de collecte de données telles que les réseaux de capteurs (WSNs), qui peuvent impliquer des coûts importants liés à l’installation d’un grand nombre de capteurs statiques et de leurs maintenances. En effet, des millions de dispositifs mobiles sont déjà déployés dans la nature, portés par des utilisateurs dans leur vie quotidienne. Avec la généralisation des magasins d’applications (par ex. App Store, Google Play), il est désormais possible pour des petites organisations comme des équipes de recherche ou des petites entreprises de rapidement délivrer une application mobile auprès de cette masse d’utilisateurs. Par exemple, au lieu d’installer un ensemble de caméras le long des routes, il est possible de collecter des données du trafic routier et de détecter les embouteillages en utilisant le GPS des dispositifs mobiles des conducteurs. Un autre avantage de l’utilisation de ces dispositifs est le nombre de capteurs multimodaux inclus dans ces appareils, permettant une collecte d’information contextuelle de haut niveau. En effet, le GPS peut fournir la position d’un utilisateur. Le microphone, quand il n’est pas utilisé pour les communications téléphoniques, peut être utilisé comme capteur acoustique. L’accéléromètre peut être, quant à lui, utilisé pour identifier les modes de transport des utilisateurs, leur activité journalière (par ex. temps passé en position assise, à dormir, à marcher, à courir) mais aussi détecter des dégâts importants sur une route. De nouveaux capteurs peuvent également facilement être ajoutés à ceux initialement préinstallés, en utilisant des connexions sans fils comme le Bluetooth pour communiquer entre eux. Quelques exemples sont les bracelets connectés qui peuvent mesurer la fréquence cardiaque 1 d’un individu, ou les capteurs qui mesure la qualité de l’air [19]. Pour finir, le dernier avantage est de pouvoir inclure les utilisateurs dans le processus de collecte, bénéficiant ainsi de l’intelligence humaine pour collecter des données sémantiquement complexes à identifier à partir de simples capteurs. Par exemple, un utilisateur peut facilement identifier la dégradation d’installations 1. http://pulseon.fi/ 22publiques, prendre une photo de ces dégâts et l’envoyer à la collectivité territoriale concernée [35]. Grâce à ces avantages, le MCS a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement et la santé [39, 11]. Cependant, l’utilisation des dispositifs mobiles possédés par des individus introduit également de nouvelles problématiques, comme la préservation de la vie privée des utilisateurs, la grande consommation énergétique des applications de collecte ou alors comment inciter les utilisateurs à installer et exécuter ces applications. Dans la suite de cette section, nous présentons tout d’abord une vue d’ensemble de ces applications avant de décrire avec plus de précision ces problématiques. 2.1.2 Classification des applications Dans la littérature, il existe un grand nombre d’applications de collecte de données, mettant en évidence l’utilisation du MCS dans une grande variété de domaines. Globalement, ces applications peuvent être classées selon deux critères : le sujet à observer et le mode d’acquisition des données. Le classement selon le sujet à observer se scinde, lui encore, en deux dimensions : les applications de collecte personnelle et les applications de collecte communautaire. Les applications de collecte personnelle visent à observer et analyser le comportement d’un individu (e.g., activité physique, mode de transport), tandis que les applications de collecte communautaire visent à observer des phénomènes (à plus grande échelle) sur l’environnement (par ex. qualité réseaux, pollution atmosphérique ou sonore) ou sur une infrastructure publique (e.g., trafic routier, place de parking disponible, dégâts de matériel public). Le classement selon le mode d’acquisition de données peut également se scinder en deux modalités appelées : collecte participative et collecte opportuniste. Dans la collecte participative, l’utilisateur est directement impliqué dans la prise de décision de la collecte (i.e., en décidant quand, comment et quelles données doivent être collectées). Au contraire, dans la collecte opportuniste, elle est complètement automatisée par l’application, sans nécessiter une intervention de l’utilisateur. 23Collecte personnelle ou communautaire Dans les systèmes de collecte personnelle, l’ objectif est d’observer des phénomènes liés à un individu. Dans ce type de système, toutes les données collectées sont géné- ralement couplées avec un identifiant unique, permettant de suivre l’évolution d’un utilisateur spécifique à travers le temps. Elles sont généralement rendues à l’utilisateur sous forme d’un rapport détaillé sur son activité, partagées à travers un réseau social ou alors agrégées à travers plusieurs utilisateurs afin d’identifier divers comportements. Ce type de collecte est généralement utilisé dans les domaines de la santé, du sport ou de l’environnement. Dans le domaine de l’environnement par exemple, PEIR [51](Personal Environmental Impact Report) est un système permettant aux utilisateurs de se servir de leurs dispositifs mobiles afin de déterminer leur exposition aux polluants présents dans leur environnement. PEIR collecte continuellement les données GPS vers un serveur pour y effectuer une série de traitement consistant à segmenter les différents déplacements des utilisateurs, identifier les modes de transports (par ex. bus, voiture) et calculer la quantité de gaz carbonique émise lors des déplacements. Pour le calcul de l’émission du gaz carbonique, PEIR couple les informations des déplacements avec plusieurs bases de données : celles des principales entreprises polluantes, et celles de la météo et du trafic routier. Sur un site Internet spécifique, les utilisateurs peuvent ensuite consulter les rapports de leurs déplacements, les aidants à modifier leurs comportements et protéger leur santé. Dans le domaine du sport, BikeNet [20] fournit aux cyclistes une application leur permettant de mesurer leurs expériences sportives. BikeNet combine les données du GPS et de l’accéléromètre pour calculer la vitesse, les calories perdues ainsi que la qualité des routes empruntées. Les données collectées peuvent être visualisées par les cyclistes eux-mêmes, ou être agrégées avec d’autres utilisateurs afin de construire une carte complète des pistes cyclables. Les systèmes de collecte personnelle sont également beaucoup utilisés dans le cadre d’expériences scientifiques. Par exemple, EmotionSense [56] est un système dédié aux études de psychologie sociale. Il tente d’établir une relation entre le bien-être d’un utilisateur et ses interactions sociales ou ses activités. Pour identifier ces informations, EmotionSense analyse continuellement trois types d’informations. Premièrement, les conversations téléphoniques des utilisateurs pour mesurer leurs émotions durant leurs appels. Deuxièmement, les périphériques Bluetooth voisins pour identifier les 24personnes se trouvant régulièrement à proximité. Et finalement l’accéléromètre pour identifier l’activité régulière de l’utilisateur. Dans un autre contexte, HealthAware [28] est une application visant à observer l’obésité des utilisateurs. Avec cette application, les utilisateurs peuvent prendre en photo leur nourriture, ce qui permet au système de leur fournir en retour des informations sanitaires complémentaires sur cette nourriture. HealthAware collecte également les données de l’accéléromètre pour mesurer l’activité physique quotidienne des utilisateurs. Le système fournit en retour un rapport complet sur l’activité effectuée, et rappelle aux utilisateurs l’importance de garder une activité physique quotidienne pour être en bonne santé. Les systèmes de collecte communautaire visent, quant à eux, à observer des phénomènes à plus grande échelle, sur l’environnement ou sur des infrastructures publiques afin d’améliorer la vie d’une communauté (par ex. toutes les personnes habitant dans une ville, les étudiants d’une université). Quelques scénarios types de ce genre de collecte comprennent la mesure de la pollution atmosphérique en milieu urbain, ou l’observation des réseaux routiers afin de détecter les embouteillages ou des dégâts importants sur la chaussée. CommonSense [19] est un exemple d’application dédié à l’observation de la pollution atmosphérique. L’application mobile de CommonSense combine les données GPS avec des données fournies par un capteur externe mesurant la qualité de l’air ambiant. La communication entre le mobile et le capteur externe est assurée par une connexion Bluetooth. Les capteurs externes ainsi que l’application sont déployés auprès de la population, qui collectivement propage leurs positions ainsi que la qualité de l’air vers un serveur. Les données sont ensuite agrégées et peuvent être visualisées sur un site Internet spécifique. Similairement, NoiseTube [47] utilise directement les microphones des dispositifs mobiles pour mesurer la pollution sonore en milieu urbain. Un autre type de collecte communautaire implique la mesure de phénomènes en relation avec des infrastructures publiques. Par exemple, Nericell [50] est un projet qui a pour objectif de mesurer différents phénomènes issus du trafic routier. Ce projet analyse continuellement la position d’un utilisateur qui, couplée avec les informations issues de l’accéléromètre, permet de détecter la dégradation d’une route ou des freinages d’urgences et, couplée avec le microphone, permet de détecter un fort trafic à partir du bruit ambiant. Dans un autre contexte, LiveCompare [17] est une application qui permet de comparer différents prix d’un même article se trouvant dans des magasins situés à proximité 25d’un utilisateur. Avec cette application, les utilisateurs peuvent se servir de leur dispositif pour prendre en photo le code-barres d’un article. Le code est ensuite décrypté, et envoyé vers un serveur avec la position de l’utilisateur et la photo. En échange, LiveCompare fournit aux utilisateurs les différents prix disponibles pour ce même produit, en fonction des magasins se trouvant à proximité. Un autre exemple d’application est CreekWatcher 2 . Cette application surveille les niveaux et la pollution des eaux, à l’aide des rapports des utilisateurs, comme des photos prises à divers endroits au bord des étendues d’eau, ou des messages texte sur le quantité de déchets. Ces informations peuvent ensuite être exploitées par des commissions de contrôle des eaux. Collecte participative ou opportuniste Indépendant du sujet à observer, un facteur déterminant du succès d’une application est le niveau d’implication des utilisateurs dans le processus de collecte [38]. Typiquement, le processus de collecte peut prendre deux formes appelées collecte opportuniste [39] et participative [7]. Dans celle dite opportuniste, la collecte de données est complètement automatisée par l’application mobile (par ex. "collecter la position toutes les cinq minutes"). Cette approche a le principal avantage de minimiser l’intervention humaine dans le processus de collecte. Cela est particulièrement utile dans le cadre d’une collecte communautaire, permettant d’assurer la propagation de données régulièrement sur le serveur (sans que l’utilisateur soit contraint à accomplir des tâches quotidiennes sur son dispositif). Cependant, ces applications sont plus difficiles à développer, et consomment également beaucoup de ressources énergétiques. En effet, la difficulté principale pour développer ce type d’application est de déterminer dans quel contexte se trouve le dispositif mobile, afin d’assurer une certaine qualité des données collectées. Par exemple dans l’application NoiseTube [47], qui a pour objectif d’observer la pollution sonore, il est nécessaire de mesurer le niveau sonore uniquement quand le dispositif est hors de la poche ou du sac de l’utilisateur. Dans ce cas, cette issue peut être résolue en utilisant le capteur de lumière, mais par conséquent, nécessite la consommation de ressources plus conséquentes. 2. http://www.ibm.com/smarterplanet/us/en/water_management/article/creek_ watch.html 26Au contraire, la collecte dite participative nécessite une plus grande implication de la part des utilisateurs. Par exemple, dans l’application LiveCompare [17], les utilisateurs doivent manuellement prendre une photo du produit qu’ils veulent comparer. Le principal avantage de cette approche est qu’elle permet de bénéficier de l’intelligence humaine pour réaliser des opérations plus complexes. Si nous reprenons l’exemple de application NoiseTube [47], l’approche participative peut permettre de résoudre facilement le problème du contexte du dispositif, en demandant aux utilisateurs de prendre une mesure du niveau sonore manuellement lorsque leur dispositif est hors de leur poche. Cependant, l’inconvénient de cette approche est que la qualité des données, ainsi que la fréquence à laquelle elles sont collectées, dépend fortement de l’enthousiasme des utilisateurs pour l’application. 2.1.3 Discussion Dans cette section, nous avons présenté une vue d’ensemble du MCS, ses principales caractéristiques ainsi que les domaines d’applications utilisant le MCS comme source d’approvisionnement de données. Cependant, jusqu’à ce jour, les applications développées ont principalement été élaborées dans un contexte applicatif spécifique, et difficilement réutilisable. En effet, ces applications ont été conçues complètement indé- pendamment des unes des autres, ne partageant aucun module logiciel commun, alors qu’elles ont à faire face à des problématiques communes. Ce manque de solutions réutilisables, largement pointé du doigt dans la littérature ces dernières années [39, 27, 60, 66], rend non seulement le développement d’une application spécifique difficile, mais il y a aussi la problématique du recrutement des participants qui doit être repris de zéro pour chaque application. Avec la popularité croissante du MCS dans de nombreuses communautés scienti- fiques, fournir une plate-forme générique permettant un rapide développement et un déploiement d’une large variété de campagnes de collecte de données devient une nécessité [27]. C’est donc dans cette lignée que s’inscrivent les travaux de cette thèse. Cependant, réaliser une telle plate-forme comporte de nombreux défis, que nous présentons dans la section suivante. 272.2 les challenges clés du mobile crowdsensing Dans cette section, nous identifions les principaux défis à relever afin proposer une plateforme générique dédiée aux développements et aux déploiements de campagne de collecte de données. Principalement, nous identifions cinq défis : Sécurité et vie privée, Gestion des ressources, Hétérogénéité des équipements et des OS, Diffusion et passage à l’échelle de applications, Implication et incitation des usagers. Pour chacun des défis, nous décrivons brièvement la problématique ainsi que les différentes solutions envisagées dans l’état de l’art. 2.2.1 Sécurité et Vie privée Respecter la vie privée des utilisateurs est peut-être la responsabilité la plus fondamentale d’une plate-forme de collecte. Les utilisateurs sont naturellement sensibles aux données collectées sur leurs dispositifs, spécialement si ces informations comprennent leurs localisations, des images sensibles ou alors des communications audios. En effet, de nombreux travaux [36] ont montré que de nombreuses données, même si elles peuvent paraître anodines prises individuellement, peuvent révéler de nombreuses informations sensibles sur les habitudes ou les relations sociales d’un individu lorsqu’elles sont agrégées dans la durée. Par exemple, les données de géolocalisation collectées avec le GPS, couplées avec des données temporelles peuvent être utilisées pour inférer les trajets quotidiens empruntés par un utilisateur, ou encore ses principaux lieux de vies tels que son domicile ou son lieu de travail [26]. Afin de protéger la vie privée des utilisateurs, de nombreuses solutions ont été envisagées dans la littérature. Christin et al. [11] donne une bonne vue d’ensemble des techniques utilisées selon le contexte de la collecte, qu’elle soit personnelle ou communautaire. Typiquement, ces techniques peuvent consister à utiliser un alias pour assurer les communications entre le serveur et le dispositif mobile, à perturber volontairement les données collectées avant de les propager vers le serveur (en modifiant par exemple les coordonnées GPS), à agréger les données entre n utilisateurs partageant des propriétés communes (par ex. n participant situés dans le même quartier), ou alors à échanger alternativement les traces de mobilités entre plusieurs utilisateurs. 28Cependant, bien que ces approches permettent d’assurer une certaine confidentialité des utilisateurs, elles impliquent également une dégradation des données qui sont collectées. Dans ce cas, il est nécessaire de faire un compromis entre qualité et confidentialité. Ce compromis peut être fait en effectuant un maximum de traitement directement dans le dispositif mobile. Par exemple, Nericell [50] adopte cette approche en analysant toutes les données issues de l’accéléromètre et du microphone localement, et propage uniquement des informations de haut niveau sur le serveur (par ex. fort trafic). Une autre solution envisagée par Christin et al. [11] est de laisser la possibilité aux utilisateurs de définir leurs exigences en matière de vie privée. En effet, la notion de vie privée peut énormément varier d’un individu à un autre. Par exemple, certain utilisateur peuvent être retissant à partager leur position contraire à d’autre. Dans ce contexte, il est nécessaire de fournir aux utilisateurs des moyens leur permettant de spécifier les données qu’ils veulent partager, dans quelles circonstances (par ex. temps, position), et surtout dans quel but. 2.2.2 Gestion des ressources Alors que les smartphones continuent de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces dispositifs restent limitées. En effet, certaines applications déployées [49] montrent que la durée de vie de la batterie d’un dispositif, peut être réduite de 20 heures à 6 heures si certaines ressources sont exploitées activement. Par exemple les ressources du CPU pour traiter un grand volume de données (par ex. traitement de données audio), les ressources de certains capteurs comme le GPS, ou encore des ressources de communications (par ex. 3G, WIFI) pour partager en temps réel les données collectées. Un aspect intéressant pour réduire la consommation énergétique de ces applications est la multimodalité de certains capteurs. En effet, cela peut permettre de faire un compromis entre la qualité des données, en terme de fréquence d’échantillonnage et de précision, et le coût énergétique lié à leurs acquisitions. L’exemple le plus courant est l’acquisition de la position d’un utilisateur, qui peut être obtenue soit par le GPS, impliquant une grande coût énergétique, mais fournissant une grande précision (5- 20 mètres), soit par WiFi ou par la triangularisation GSM, qui sont moins précis 29(20-1000 mètres), mais ont une taxe énergétique moins importante. À partir de ce constat, de nombreux travaux ont été proposés dans la littérature, essayant d’alterner l’utilisation de ces différents capteurs pour faire le plus efficacement ce compromis. Par exemple, EnLoc [14] adapte la fréquence d’échantillonnage et les capteurs haute et basse qualité en fonction de la batterie de l’utilisateur. Matador [8] propose également un algorithme adaptatif, mais pour déterminer si l’utilisateur se trouve dans une zone précise. SenseLoc [34] active le GPS uniquement si l’utilisateur se déplace en utilisant l’accéléromètre pour identifier son activité. Cependant, un inconvénient de ces approches est qu’elles ont été conçues pour un contexte applicatif spécifique, et qu’elles ne sont donc pas forcement adaptées pour un autre. De plus, ces approches restent limitées lorsque de multiples applications coexistent dans un même dispositif. Par exemple, les applications dédiées à l’observation de la pollution sonore et du trafic routier nécessitent toutes les deux des données de géolocalisation. Dans ce contexte, ces applications effectuent leurs propres échantillonnages des données GPS, pouvant entraîner une surconsommation énergétique du dispositif mobile. Cela limite ainsi les utilisateurs à participer à un nombre limité d’applications. 2.2.3 Hétérogénéité des équipements et des OS Un autre aspect à prendre en considération est l’hétérogénéité des systèmes d’exploitation et des équipements disponibles. En effet, selon Gartner Inc. 3 , les ventes de smartphones en 2013 ont totalisé plus de 1,8 milliards d’unité, réparties principalement entre trois systèmes d’exploitation (OS), Android 4 avec 78,4% de part de marché, iOS 5 avec 15,6 % et Windows Phone 6 avec 3,2%. Bien que ce marché en pleine effervescence — soit une augmentation 3.5% depuis 2012 —, confirme le potentiel du Mobile crowdsensing pour la collecte de données à grande échelle, cela induit aussi un long processus de développement pour prendre en considération tous ces systèmes d’exploitation. Pour le développement d’une application sur un OS spécifique, un ensemble d’outils et d’APIs sont fournis aux développeurs. Ces APIs sont implémentées généralement dans des langages de programmation différents, par exemple Java pour Android et 3. Gartner Inc. http://www.gartner.com/newsroom/id/2665715 4. Android : http://www.android.com 5. iOS : http://www.apple.com/fr/ios 6. Windows Phone : http://www.windowsphone.com 30Objective-C ou Apple Swift 7 pour iOS. Ceci implique qu’une application développée pour l’un de ces OS est incompatible avec les autres. Par conséquent, cela demande aux développeurs d’étudier et de développer une application spécifique pour chaque OS disponible, afin de pouvoir impliquer un maximum d’utilisateurs dans le système de collecte. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. Pour faire face à cette hétérogénéité, également identifiée par [60], il est nécessaire de concevoir les applications de collecte dans un langage de haut niveau. Dans ce contexte, le défi consiste à proposer une abstraction assez générale pour supporter le dé- veloppement d’applications variées (opportuniste et participative), qui peut également impliquer une grande variété de capteurs, portables pour supporter la diversité des plate-formes mobiles (c.-à-d. Android, iOS, Windows Mobile), et finalement accessibles pour minimiser l’expertise nécessaire dans les technologies mobiles. 2.2.4 Diffusion et passage à l’échelle des applications La diffusion des applications est un aspect crucial pour assurer le passage à l’échelle d’une plate-forme de collecte. Généralement, la diffusion des applications mobiles est assurée par les magasins traditionnels proposés par les plate-formes mobiles (par ex. Google Play pour Android, Apple Store pour iOS). Cependant, une fois disponible dans un magasin, l’application peut être potentiellement téléchargée par des millions d’utilisateurs à travers le monde. Ces utilisateurs peuvent alors générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. De plus, la période de prolifération des mises à jours de ces applications vers les utilisateurs peut prendre plusieurs heures jusqu’à plusieurs jours selon le magasin utilisé (par ex. quelques heures pour Google Play jusqu’à plusieurs heures pour Apple Store). Dans le cadre du MCS, cette période est beaucoup trop longue, spécialement si l’objectif est de collecter des données lors d’un événement ne durant que quelque jours, comme un festival ou une fête nationale. En effet, lors de ces manifestations, après avoir récolté les premières données, il peut s’avérer nécessaire de 7. https://developer.apple.com/swift 31mettre rapidement à jour l’application afin d’améliorer la qualité de la collecte ou de remédier à des défauts de programmation. Dans ce cadre, il est nécessaire de développer de nouveaux mécanismes pour déployer ces applications de collecte [39]. Ces mécanismes devront prendre en compte plusieurs considérations. La première est de maîtriser le déploiement de ces applications vers les participants les plus à même à collecter les données désirées, en limitant le nombre d’utilisateurs impliqués dans la collecte, ou en ne visant qu’une population particulière (par ex. région géographique, tranche d’âge), tout en assurant leurs confidentialités. La deuxième considération est d’assurer un rapide déploiement de leurs mises à jour pour adresser les exigences évolutives liées aux premières données collectées, ou tout simplement pour corriger des erreurs de programmation. La dernière, aussi envisagée par [27, 60], est de permettre de coordonner l’exécution des campagnes à travers plusieurs dispositifs, notamment dans les campagnes de collecte communautaire. En effet, généralement ces applications collectent périodiquement (toutes les x secondes) des données sans prendre en considération si un autre dispositif placé à proximité exécute la même application. Cela peut ainsi entraîner une forte duplication de données collectées, en particulier en milieu urbain où il peut y avoir une forte densité d’utilisateurs. Dans ce contexte, effectuer une coordination entre ces dispositifs pourrait permettre de diminuer la quantité de données redondantes sur le serveur, et également équilibrer les charges énergétiques entre les dispositifs, réduisant ainsi l’énergie globale consommée lors de l’exécution de la campagne. 2.2.5 Implication et incitation des usagers Inévitablement, sans une participation adéquate des utilisateurs, il peut être très difficile d’obtenir la masse de données critique pour l’application. Cependant, comme nous l’avons mentionné dans les sous-sections précédentes, en utilisant une application de collecte, les utilisateurs consomment de nombreuses ressources de leurs dispositifs, et peuvent potentiellement s’exposer à la divulgation d’informations confidentielles. Dans ce contexte, un utilisateur peut ne pas être intéressé à participer à l’application, à moins de recevoir une récompense adaptée. Dans ce contexte, de nombreux travaux ont porté sur la réalisation d’un modèle économique permettant d’attribuer des récompenses financières aux utilisateurs en fonction de leur participation. Ces modèles peuvent être statiques [57], en attribuant 32un prix fixe aux données partagées par les utilisateurs, ou dynamiques [40] en faisant varié le prix des données en fonction de la couverture des premières données partagée, pour inciter par exemple les utilisateurs à se déplacer dans des zones peu couvertes. Cependant, bien que ces modèles puissent favoriser la participation des utilisateurs et améliorer la qualité des données obtenues, collecter des données à grande échelle peut nécessiter un budget considérable, qui n’est pas forcément accessible par exemple pour des équipes de recherche. Dans ce contexte, de nombreux modèles alternatifs, non monétaires, ont été explorés dans la littérature ces dernières années. Ces sources de motivation peuvent par exemple s’inscrire dans le cadre d’une démarche citoyenne ou scientifique en aidant à diminuer l’émission de gaz carbonique dans la nature par exemple [51]. Ces sources peuvent également prendre la forme d’un jeu, en simulant une compétition entre les utilisateurs, en partageant ses performances sur les réseaux sociaux [49], ou en attribuant des récompenses virtuelles. Une dernière source de motivation est d’obtenir un bénéfice direct en partageant des données, par exemple dans l’application LiveCompare [17], les utilisateurs peuvent bénéficier des prix scannés par les autres utilisateurs. 2.2.6 Discussion Le principal objectif d’une plate-forme générique de collecte de données est de permettre la fédération d’une large communauté d’utilisateurs, avec des niveaux d’expertises et des exigences différentes. En effet, les campagnes de collecte de données peuvent être de différents types, qui peuvent être de type communautaire ou personnel, et peuvent également impliquer différents niveaux de participation de la part des utilisateurs (c.-à-d. collecte opportuniste et participative). Comme nous en avons discuté tout au long de cette section, la mise en place d’une campagne demande de faire de nombreux compromis. Que ce soit sur la qualité des données, leur quantité, la préservation de la vie privée des utilisateurs ou encore la consommation énergétique des applications de collecte. Nous avons également vu que dans la littérature, de nombreux modèles ou algorithmes ont été proposés pour adresser ces points. Cependant, aucun de ces modèles ne représente une solution idéale, et ne peut être appliqué seulement dans un contexte applicatif spécifique (par ex. population visée, type de de données collectées). Dans ce contexte, nous pensons que la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture logicielle d’une plate-forme générique. La flexibilité fait 33référence à la capacité de la plate-forme à s’adapter à la diversité des campagnes de collecte qui peuvent être menées. Cette diversité peut faire référence à différents types de données qui peuvent être collectées (c.-à-d. impliquant de nombreux capteurs), aux technologies utilisées pour les sauvegarder (c.-à-d. base de données), et les structurer (c.-à-d. méthode d’indexation) et les analyser. Quant à l’extensibilité, elle fait référence à la capacité de la plate-forme pour intégrer de nouvelles contributions, afin de faire face aux exigences des utilisateurs non anticipées. Dans ce cadre, la plate-forme pourrait permettre également à des scientifiques travaillant sur une problématique spécifique du MCS (par ex. vie privée, modèle de récompense, etc.), de se focaliser sur leur domaine d’expertise sans avoir à redévelopper un système complet et donc participer à l’amélioration de la plate-forme. Dans la section suivante, nous faisons une étude comparative des différentes plateformes ayant reçu beaucoup d’attention dans la littérature ces dernières années, et ayant ce même objectif. 2.3 travaux connexes Comme nous l’avons vue dans la section précédente, le développement d’application de collecte de données demande de faire face à de nombreux défis. Dans cette section, nous décrivons un certain nombre de travaux existants, proposant des plate-formes ayant pour objectif de simplifier leurs développements et leurs déploiements. Pour chaque travail présenté, nous décrivons brièvement l’architecture générale adoptée, et nous les confrontons par rapport aux défis définis dans la section précédente. 2.3.1 Funf Open Sensing Framework Funf [1] est une plate-forme open source dédié aux développements d’applications de collecte de données mobiles basées sur le système d’exploitation Android. Initialement, Funf a été développé par le MIT Media Lab, afin de proposer aux scientifiques un outil plus générique pour les aider à facilement concevoir leurs applications de collecte. Le concept de base proposé par Funf est appelé Probe. Typiquement, un Probe est un module logiciel (c.-à-d. portion de code Android) assurant la capture de données d’un capteur physique ou logique (par ex. GPS, température, contact). Pour le développement 34des applications, Funf met à disposition un service appelé FunfInABox, accessible via une interface web. L’interface propose un formulaire qui permet aux scientifiques de sélectionner et configurer un ensemble de Probe à inclure dans l’application mobile (cf. figure 2). Le formulaire validé, FunfInABox procède alors à la génération de l’application et de la mettre à disposition des scientifiques à travers un compte Dropbox, un service de stockage et de partage de fichier en ligne. L’application peut également être configurée pour propager périodiquement les données collectées vers le même compte Dropbox, ou sur un serveur HTTP. Pour des raisons de sécurité, toutes les données collectées sont encryptées, et toutes les données sensibles telles que les contacts ou les SMS sont automatiquement hachés. Funf fournit également un ensemble de scripts qui peuvent être utilisés par les scientifiques pour décrypter les données, les insérer dans une base de données relationnelle et visualiser les données. Figure 2 – Développement d’une application mobile avec FunfInABox Funf se diffère principalement par sa simplicité. En effet, l’utilisation d’un formulaire web permet de rapidement développer une nouvelle application sans nécessiter toutes sortes d’expertise en programmation. Cependant, les applications qui peuvent être développées restent très basiques, limitées à la collecte périodique de données brutes de capteurs, et ne supportent pas les interactions avec les utilisateurs. De plus, les applications générées ne proposent pas aux utilisateurs de mécanismes leur permettant de contrôler les données qui sont collectées sur leurs dispositifs ni de retour sur celles-ci. D’autres parts, Funf ne fournissent pas de service spécifique pour aider les utilisateurs à déployer leurs applications vers les dispositifs mobiles. Ils sont alors contraints d’utiliser les magasins d’applications, devant faire face aux problématiques discutées précédemment(cf. section 2.2.4). 352.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones Jon Froehlich et al. [25] proposent une approche plus flexible pour développer des applications de collecte avec MyExperience. 1 2 3 4 6 7 8 9 14 15 16 17 18 00:30 19 CallQuality 20 21 22 23 25 cellnetwork.png 26 27 Bad 28 Poor 29 Fair 30 Good 31 Excellent 32 33 34 Listing 2.1 – MyExperience : Exemple de configuration de collecte de données MyExperience facilite la définition d’une expérience collecte en proposant une abstraction appelée Sensors Triggers et Actions au-dessus du langage descriptif XML. Dans cette abstraction, les triggers combinent les flux des données fournis par les sensors et une expression logique pour déterminer quand une action doit être déclenchée. 36Pour capturer l’expérience d’un utilisateur, cette abstraction supporte la définition de questionnaires, qui peuvent être présentés à l’utilisateur périodiquement, ou après un évènement spécifique. Le listing 2.1 montre par exemple une expérience affichant à un utilisateur un questionnaire lui demandant la qualité de sa communication vocale après un appel téléphonique. Cependant, l’abstraction proposée a plusieurs limitations. La première est que les triggers qui exécutent les actions ne peuvent pas exécuter une seconde action en fonction du résultat de la première. Cela empêche par exemple de déclencher un nouveau questionnaire en fonction des premières réponses fournies. La deuxième concerne l’expressivité de l’abstraction qui reste limitée aux balises XML définies au préalable. Cette limitation par exemple empêche le développement d’algorithmes contextuels complexes (par ex. inférence de l’activité d’un utilisateur) complexe. Et finalement, MyExperience reste limité aux collectes participatives. L’architecture de la plate-forme MyExperience est composée de deux parties spéci- fiques : i) une application mobile Windows Mobile, responsable de de l’exécution des fichiers XML et ii) une application serveur, responsable de la persistance des données collectées. L’application mobile supporte également la propagation automatique des données vers le serveur. La propagation des données est effectuée lorsqu’une connexion réseau est détectée, et utilise le protocole HTTPS pour sécuriser le transfert des données. L’application fournit également une option permettant d’utiliser un algorithme de cryptographie SHA-1 pour hacher les données confidentielles des utilisateurs (par ex. SMS, contacts, numéro de téléphone). Cependant, MyExperience ne fournit pas de mécanisme particulier pour aider les scientifiques à déployer leurs expériences. L’application mobile ne supportant l’exécution que d’une seule expérience, cela empêche par exemple aux scientifiques de bénéficier des applications déjà installées chez les utilisateurs pour déployer leurs propres expériences.Néanmoins, MyExperience fournit plusieurs mécanismes permettant la mis à jours des expériences à distance, en envoyant la nouvelle expérience par SMS ou un message électronique aux utilisateurs concernés. Cependant, cela nécessite que les scientifiques aient connaissance du numéro de télé- phone ou de l’adresse électronique des utilisateurs, ce qui met en péril l’anonymat des utilisateurs. 372.3.3 Medusa : A programming framework for crowd-sensing applications Medusa, présenté par Ra et al. [55], est une plate-forme de programmation et de distribution de tâches de collecte participatives. Medusa s’adresse principalement aux utilisateurs finaux, sans expertise en programmation. Un exemple typique d’application présentée est celui du citoyen journaliste, permettant au journaliste de recruter des citoyens mobiles pour récolter des vidéos et des commentaires d’un évènement spécifique (par ex. accident, feu de forêt). Dans Medusa, la spécification d’une nouvelle tâche consiste à définir une séquence d’actions qui doivent être exécutées par les mobiles. Pour spécifier cette séquence d’actions, Medusa propose MedScript, une abstraction de haut niveau basé sur XML. MedScript propose deux niveaux d’abstractions : les stages et les connecteurs. Les stages permettent de définir une action élémentaire qui doit exécutée par le dispositif. MedScript distingue deux type de stages : i) les stages consistant à extraire des données des capteurs (par ex. GPS, accéléromètre) appelés SPC-Stage, et les stages nécessitant une intervention humaine (par ex. prendre une vidéo, documenté une photo) appelés Hit-Stage. Chaque stage inclut également plusieurs paramètres, comme une date d’expiration, un contexte d’exécution (par ex. région spécifique ou période de la journée) et également inclure une récompense financière pour inciter les utilisateurs à exécuter les stages. Par exemple, le listing 2.2 décrit l’application du citoyen journaliste. Cette application comporte quatre stages et deux connecteurs définissant l’enchaînement suivant : Recruit -> TakePicture -> GetSummary -> UploadData . Le premier stage permet de recruter les utilisateurs, le deuxième demande aux utilisateurs de prendre une photo dans une région spécifique, le troisième demande aux utilisateurs de commenter la photo prise et finalement le dernier permet d’envoyer le commentaire et la photo vers le serveur. 1 2 Citizen-Journalst 3 4 Recruit HIT 5 recruit 6 7 Citizen Journalist Demonstration 8 18:00:00 12/16/2011 9 .05 10

W_WID

3811 12 13 14 GetSummary SPC 15 medusalet_videosummary 16 immediate none 17 18 IMAGE 19

SUMMARY

20 21 22 23 TakePicture SPC 24 medusalet_mediagen 25 location=34.020259|-118.290131|40, user-initiated 26 27 -t image 28

IMAGE

29 30 31 32 UploadData SPC 33 medusalet_uploaddata 34 none textdesc 35 36 SUMMARY 37 38 39 40 41 Recruit 42 TakePicture Hiring 43 44 45 TakePicture 46 GetSummary Hiring 47 48 49 GetSummary 50 UploadData Hiring 51 52 Listing 2.2 – Le journaliste citoyen développé en MedScript language Pour le déploiement des tâches de collecte, l’architecture de Medusa (cf. figure 3) est composé d’un ensemble de service exécuté sur une infrastructure serveur, et une 39application mobile distribuée auprès d’un ensemble d’utilisateurs. Nous décrivons brièvement le rôle de ces composants. Le Interpreter est le point d’entré de Medusa, il accepte les tâches décrites en MedScript, vérifie leur validité et les envoies aux Task Tracker. Le Task Tracker est responsable de coordonner l’exécution des tâches vers les dispositifs mobiles. Pour chaque tâche, le Task Tracker lui associe une instance dédiée responsable du suivie des différents stages associés à la tâche. Dans ce cas, si la tâche doit être exécuté par 50 utilisateurs (c.-à-d. collecter 50 images dans l’exemple présenté), 50 instances seront alors instanciées dans le Task Tracker. Pour chaque stage inclus dans la tâche, l’instance associé à la tâche notifie l’application mobile assignée lui demandant d’exécuter le stage. Une fois le stage complété, l’application mobile alerte le Task Tracker et attend une instruction pour exécuter le stage suivant. Une fois tous les stages terminés, le Task Tracker averti l’initiateur de la tâche et rend les données disponibles dans le Data Repository. Le Worker Manager sert principalement d’interface avec le service Amazon Mechanical Turk (AMT) 8 , qui est utilisé pour la phase de recrutement. Lorsque le Task Tracker instancie une nouvelle tâche, une description de la tâche ainsi que sa rémunération est postée sur le service AMT. Les participants peuvent alors se connecter sur le service AMT avec leur application mobile, et s’inscrire auprès de la tâche qu’il les intéresse. Une fois inscrit, le Worker Manager notifie le Task Tracker, qui peut alors procéder à l’exécution des stages. AMT est également utilisé pour assurer les communications (c.-à-d. par SMS) entre le Task Tracker et les applications mobiles, et la rémunération des utilisateurs. Cette approche permet d’assurer l’anonymat des utilisateurs, dans le sens où Medusa n’a pas besoin de connaître l’identité réelle des utilisateurs pour communiquer avec eux et les récompenser. Le Stage Library représente la partie extensible de Medusa. Chaque stage supporté par MedScript est associé à un exécutable Android stocké dans le Stage Library. Les exécutables sont alors téléchargés par les dispositifs mobiles avant d’exécuter le stage associé. Cette approche permet d’étendre les capacités offertes par MedScript sans avoir à recompiler l’application mobile et la redéployer. L’ Application mobile est composée de deux services appelés StageTracker et MedBox. Le Stage Tracker est responsable des communications entre l’ap- 8. Amazon mechanical turk : https://www.mturk.com 40plication mobile et les services du serveur. Ces communications comprennent le téléchargement des exécutables des différents stages, d’analyser les SMS envoyés par AMT et propager les données vers le serveur. La MedBox est responsable de l’exécution des stages dans le dispositif mobile. Un stage peut être exécuté soit directement après une notification du Stage Tracker, soit en fonction du contexte de l’utilisateur (c.-à-d. zone géographique ou période de la journée). L’application mobile fournit également plusieurs mécanismes pour contrôler les ressources consommées par l’application mobile et assurer la confidentialité des participants. Pour la gestion des ressources, Medusa laisse la possibilité aux participants de définir des limites en terme de CPU, réseau ou mémoire utilisées lors de l’exécution des stages. Pour assurer la confidentialité, l’application mobile demande une confirmation aux utilisateurs avant de propager les données sur le serveur. Cela permet aux utilisateurs de vérifier si les données collectées peuvent être compromettantes vis-à-vis de leurs vies privées. Figure 3 – Architecture de Medusa [55] Medusa propose certains aspects intéressants à l’égard des considérations discutées dans la section précédente. Ces aspects sont l’intégration d’un service tiers comme AMT, pour assurer l’anonymat des utilisateurs, la possibilité d’intégrer des récom- 41penses financières, ou encore proposer une application mobile générique favorisant la participation des utilisateurs à plusieurs tâches de collecte. Cependant Medusa a plusieurs limitations. La première réside lors de la phase de recrutement des utilisateurs. En effet, si nous reprenons l’exemple du citoyen journaliste, il faudrait que, idéalement, seul les utilisateurs se situant à proximité de l’événement couvert par le journaliste, puissent être capables de s’inscrire à la tâche. Or, bien que Medusa supporte la notion de contexte d’exécution (par ex. exécuter un stage dans une zone géographique), celle-ci est interprétée uniquement par l’application mobile après la phase d’enregistrement. Ainsi, de nombreux utilisateurs peuvent s’enregistrer sans qu’ils ne soient à proximité de l’événement visé. Une autre limitation réside dans l’abstraction du modèle de programmation proposé, qui reste limité à la définition de tâche participatives et communautaires. Par exemple, cette abstraction ne permet pas de définir des tâches suivant l’évolution d’un utilisateur à travers une longue période (par ex. "collecter toutes les 5 minutes la position du GPS"). Et finalement, la dernière limitation réside dans les mécanismes d’extension de Medusa. En effet, pour étendre les fonctionnalités offertes par MedScript, les développeurs ont besoin de développer un nouveau module Java compatible Android. Ce mécanisme a deux inconvénients. Le premier concerne la sécurité. En effet, un développeur mal intentionné peut développer un stage envoyant des SMS à l’insu des participants, ou récupérer des données confidentielles (par ex. contacts) et les envoyer vers un service tiers. Et le deuxième rend exclusive Medusa uniquement pour Android, empêchant de faire face à l’hétérogénie des OS mobiles. 2.3.4 PRISM : Platform for Remote Sensing using Smartphones PRISM [16] est une plate-forme adressant particulièrement trois points qui sont la généralité, la sécurité et le passage à l’échelle. Pour adresser la généralité, PRISM propose une application mobile permettant le téléchargement de tâches de collecte écrites en code natif. Cette approche permet de faciliter la réutilisation de code et de donner une totale flexibilité pour le développement de tâches complexes et variés. Dans ce cadre, PRISM supporte le développement de tâche participatives et opportunistes. Néanmoins, cette approche a plusieurs limitations. Premièrement, le développement de code natif demande une grande expertise en programmation et dans les plate-formes mobiles. PRISM ne fournit pas d’API de 42plus haut pour simplifier leurs développements. Deuxièmement, le développement de code natif ne permet pas de faire face à l’hétérogénéité des OS mobiles. Le code développé reste alors exclusivement exécutable par OS mobile supporté par PRISM, en l’occurrence Windows Mobile. Et finalement, permettre à des développeurs tiers de déployer du code natif sur les dispositifs mobiles peut également poser des problèmes de sécurité et de confidentialité vis-à-vis des participants. Pour limiter les problèmes de sécurité, PRISM implémente un mécanisme d’interposition, empêchant les tâches d’accéder à des fonctions critiques de l’appareil. L’application mobile observe également les ressources énergétique et réseaux consommées par les tâches, et stoppe leurs exécutions si elles dépassent une valeur limite. Cela permet de renforcer la sécurité de l’appareil, en évitant que des tâches épuisent totalement la batterie des utilisateurs. Pour permettre aux utilisateur de contrôler les données collectées durant l’exécution des tâches, PRISM fournit un mécanisme de contrôle d’accès comprenant trois niveaux : i) No Sensors empêchant tous accès, ii) Location Only permettant l’accès uniquement aux capteurs de position et All Sensors autorisant tous les accès. En ce qui concerne le passage à l’échelle du système, PRISM propose une approche permettant de maîtriser le déploiement des tâches de collecte à un sous-ensemble d’utilisateurs. La figure 4 décrit l’architecture globale de PRISM comprenant deux parties spécifiques : i) une application mobile pour Window Mobile, responsable de l’exécution des tâches soumise par le serveur, et ii) le serveur PRISM, acceptant des tâches d’applications tierces pour les déployer auprès des applications mobiles. Dans PRISM, le déploiement des taches de collecte est assuré via approche push-based, c’est-à-dire permettant au serveur de pousser les applications directement vers les dispositifs mobiles. Cette approche a le principal avantage d’assurer un déploiement rapide des applications, sans que les utilisateurs soient obligés de se connecter réguliè- rement sur le serveur pour voir si une nouvelle tâche est disponible. Pour permettre aux développeurs de définir un sous-ensemble de dispositifs pour déployer leurs tâches, PRISM fournit une API comportant deux niveaux de raffinements (cf. listing 2.3). 1 // set up the first level coarse-grained predicate 2 L1pred = new FirstLevelPredicate(); 3 L1pred.location = ; 4 L1pred.radius = ; 5 L1pred.stationary = false; 6 L1pred.cameraPresent = true; 7 L1pred.numOfPhones = ; 43Figure 4 – Architecture de PRISM [16] 8 // set up the second level fine-grained predicate 9 L2pred = new SecondLevelPredicate(); 10 L2pred.location = ; 11 L2pred.radius = ; 12 // set up the application with the predicates 13 PRSIMapp = new PRISMApplication(); 14 PRSIMapp.Init(); 15 PRISMapp.SetPredicates(L1pred, L2pred); 16 PRISMapp.SetBinary(); 17 PRISMapp.DistributeToPhones(); 18 // read and process data sent by phones 19 while (appData = PRISMapp.GetData()) { 20 ; 21 } Listing 2.3 – Exemple d’application développée avec PRISM Le premier niveau permet de spécifier les capteurs nécessaires pour exécuter la tâche, le nombre de mobiles désirés et une vaste région géographique. Le deuxième niveau permet quant à lui de définir contexte plus précis (par ex. lorsque l’utilisateur se déplace, se trouve dans une zone précise). Pour être en mesure de déployer les tâches de collecte, PRISM requiert une connaissance complète des dispositifs mobiles ainsi que leurs mobilités. Cette connaissance est assurée par une phase d’enregistrement assurée par les dispositifs mobiles. Lors de l’enregistrement, les dispositifs mobiles 44reportent deux sortes d’informations comprenant des données statiques (par ex. capteurs disponibles) et des informations dynamiques (par ex. position et niveau de batterie restant). Cependant, cela nécessite que les dispositifs envoient constamment leurs positions pour permettre au serveur d’avoir une vision en temps réel de leur répartition. Cela peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur, et également négliger la confidentialité des utilisateurs. Lorsqu’une nouvelle tâche est soumise au serveur PRISM, celui-ci compare le premier niveau de raffinement avec tous les dispositifs enregistrés au préalable, et la déploie uniquement aux dispositifs correspondants au premier niveau de raffinement. Le deuxième niveau de raffinement sera ensuite interprété par l’application mobile, qui déclenchera l’exécution de la tâche en fonction des contraintes spécifiées. 2.3.5 Bubble-sensing Bubble-sensing [45] est un système dédié aux déploiements de tâches de collecte participative et communautaire. Ce système focalise principale sur les méthodes de dé- ploiements des tâches de collecte qui doivent être exécutées dans une région spécifique. La figure 5 illustre son architecture. Figure 5 – Architecture de Bubble-sensing [45] Dans le modèle proposé par Bubble-sensing, la création d’une tâche est initiée par le dispositif d’un participant (dispositif A dans la figure 5). Le dispositif joue alors le rôle de bubble anchor, et est responsable de la maintenance de la tâche de collecte dans la zone géographique d’intérêt. Une tâche est définie par un tuple : i) action qui définie 45la tâche à réalisé par les participants (par ex. prendre une photo, une vidéo), région qui définie une zone géographique représentant la bulle où la tâche doit être exécutée, et une durée qui définie la date limite ou l’action doit être réalisé. La tâche est disséminée périodiquement, par des communications à courte distance (par ex. Bluetooth, Wifi direct), jusqu’à ce qu’un autre dispositif mobile reçoive et accepte d’exécuter la tâche en question (dispositif C). Les données collectées sont ensuite envoyées sur le bubble-server. Dans le cas ou l’initiateur de la tâche quitte la zone géographique initialement définie, un message est alors disséminé à tous les autres dispositifs se trouvant à proximité. Dans le cas ou un autre dispositif reçoive le message, il devient alors le bubble anchor (dispositif B) responsable de la maintenance de la tâche dans la bulle. En utilisant cette approche, Bubble-sensing permet d’éviter aux dispositifs de reporter continuellement leur position auprès d’une entité centrale. Cependant, cela implique qu’il y est constamment la présence de participants volontaire pour jouer le rôle de bubble-anchor dans la zone géographique d’intérêt, sinon la tâche de collecte serait alors perdu. 2.3.6 Pogo, a Middleware for Mobile Phone Sensing Pogo [6] est une plate-forme proposée par Brouwers et al., qui a pour objectif d’aider les scientifiques à développer et déployer des tâches de collecte à grande échelle. Trois types d’acteurs sont identifiés dans Pogo. Les participants propriétaires des dispositifs mobiles, les scientifiques et un administrateur. Les participants mobiles exécutent une application mobile dédiée, développée pour Android. En installant l’application mobile, les participants acceptent de partager les ressources de leurs dispositifs pour exécuter des tâches développées par les scientifiques. Les scientifiques, quant à eux, peuvent exécuter une application sur leur ordinateur pour développer de nouvelles tâches et les déployer. Et finalement l’administrateur est responsable d’assigner un ensemble de participants aux scientifiques. Cette assignation est effectuée à partir d’un serveur central, qui garde également une trace de tous les dispositifs et des données qu’ils partagent. Cependant, les auteurs donnent très peu d’informations sur cette phase d’assignation, si elle est manuelle ou automatisée. Une fois un participant assigné à un scientifique, Pogo assure le déploiement des tâches par une approche push-based. Cette approche permet d’assurer un rapide déploiement des mises à jour des tâches, mais implique également un manque de transparence sur les données qui sont 46collectées sur les dispositifs des participants ni avec qui ils les partagent. Nous pensons que ce manque de transparence peut freiner leurs participations, surtout qu’aucun mécanisme d’incitation n’est proposé. Dans Pogo, les tâches de collecte peuvent être développées en JavaScript. Pour simplifier le développement des tâches, Pogo propose une abstraction basée sur le pattern publish-subcribe [21], permettant d’effectuer des communications asynchrone entre entre les scripts et les capteurs. La figure 2.4 illustre un exemple de tâches reportant toutes les minutes les points d’accès WiFi sur les ordinateurs des scientifiques. Comparée aux approches précédentes, l’utilisation du JavaScript comporte de nombreux avantages. Tout d’abord, cela permet de bénéficier de l’expressivité d’un langage générale, permettant ainsi de définir des algorithmes contextuels complexes. Ensuite, l’utilisation du JavaScript permet également de favoriser la réutilisation de code. Et finalement de nombreux projet open sources proposent des moteurs d’exécutions pour l’exécution de code JavaScript sur Android 9 , iOS 10 ou Window Mobile 11, permettant d’assurer la portabilité du code développée vers diverses plate-formes. Cependant, l’abstraction proposée par Pogo ne permet pas d’interagir avec les participants, restant exclusivement réservé à la collecte opportuniste de données. 1 function start(){ 2 3 subscribe(’wifi-scan’, function(msg){ 4 5 publish(msg,’wifi-scan’) 6 7 } , { interval : 60 * 1000 }) } Listing 2.4 – Exemple d’application développée avec Pogo Pogo protège la vie privée des utilisateurs finaux en cachant leur identité aux scientifiques. En outre, les utilisateurs finaux conservent le contrôle de leurs données et sont en mesure de contrôler les capteurs utilisés par l’application. Pogo prend également la consommation d’énergie en considération en coordonnant la transmission des données pour les faire coïncider avec les transmissions d’autres applications. Cela permet d’éviter d’activer les interfaces réseaux constamment qui engendre un grand coût énergétique. 9. Android : https://developer.mozilla.org/enUS/docs/Rhino 10. iOS :https://github.com/phoboslab/JavaScriptCore-iOS 11. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey 472.3.7 AnonySense : A System for Anonymous Opportunistic Sensing Shin et al. introduisent une plate-forme appelée AnonySense [62], adressant majoritaire les problématiques de confidentialité dans les systèmes de collecte opportuniste. Figure 6 – Architecture de Anonysense [62] 1 ( Expires 1196728453 ) 2 ( Accept (= @WiFi a/b/g ) ) 3 ( Report (LOCATION APLIST) 4 ( Every 60 seconds ) 5 ( In ( (1 1) (2 2) (3 0)))) Listing 2.5 – Exemple d’application développée en AnonyTL Pour la description des tâches de collecte, Anonysense propose sur un langage dédié appelé AnonyTL, inspiré de la syntaxe Lisp. AnonyTL permet de spécifier le comportement d’une tâche en fournissant un ensemble de conditions d’acception, des reports de données, et une date d’expiration. Le listing 2.5 décrit un exemple de tâche exprimée en AnonyTL. Cette tâche peut être acceptée uniquement par des dispositifs connectés à une borne WiFi, et collecte l’ensemble des bornes WiFi voisines ainsi que la position toutes les 60 secondes lorsque l’utilisateur se trouve dans une zone précise. Les auteurs proposent, un nouveau argument, le choix d’un nouveau langage pour fournir une notation plus concise et plus compréhensible. Cependant, cette concision diminue également l’expressivité du langage, et empêche également la réutilisation de code pré-existant. 48Le modèle proposé par Anonysense comporte les éléments suivants : un ensemble de dispositifs mobiles (MN), d’applications tierces (App), une autorité d’enregistrement (RA), un service de distribution de tâches (TS), et un service de rapport (RS) et un service d’anonymisation (AS). Dans ce modèle, un App soumet une tâche à l’autorité d’enregistrement (RA). Le RA vérifie ensuite si la tâche respecte la confidentialité des utilisateurs avant de la transmettre au service de distribution (TS). A intervalles réguliers, les MNs se connectent au TS et téléchargent l’ensemble des tâches disponibles. Les MNs choisissent ensuite les tâches qu’ils veulent accepter. Lorsqu’un rapport est prêt, les MNs l’envoient directement au RS ou au AS selon la sensibilité des données. Si le rapport contient des données sensibles, le rapport est envoyé au AS, dans le cas contraire, il est envoyé directement au RS. 2.4 synthèse et conclusion Dans cette section, nous faisons un bilan des plate-formes décrites dans la section précédente. Le tableau 7 fournit un récapitulatif de ces approches et les positionne par rapport aux défis décris en section 2.2. En ce qui concerne les abstractions proposées pour le développement des tâches de collecte, seulement PRISM [16] supporte à la fois le développement de tâche opportuniste et participative, en permettant le déploiement de code natif directement vers les dispositifs mobiles. Cependant, il ne fournit par d’abstraction particulière permettant de simplifier le développement des tâches de collecte. De plus, le déploiement de code natif reste exclusivement réservé à un système d’exploitation mobile spécifique, dans ce cas Windows Mobile. Pour le déploiement et le recrutement des tâches de collecte, principalement deux approches coexistent. La première est l’approche pull-based, adoptée par Medusa [55] et Anonysense, où les dispositifs sont responsables de télécharger les tâches de collecte auprès du serveur. Le principal avantage de cette approche est qu’elle permet d’assurer un certain degré de transparence, dans le sens où les participants peuvent sélectionner les tâches qu’ils souhaitent exécuter. Cependant, le temps de propagation des tâches peut être relativement long, et demande aux participants de vérifier constamment si une nouvelle tâche est disponible. Pour le recrutement des participants, Anonysense permet 49de sélectionner un sous ensemble de participants basé sur leur position. Pour assurer un temps de propagation rapide malgré l’approche pull-based utilisée, l’application mobile télécharge régulièrement toutes les tâches de collecte disponibles sur le serveur et exécute celles qui correspondent à son contexte. Cependant, cela peut impliquer un coût énergétique important des applications mobiles si de nombreuses tâches sont disponibles sur le serveur et ne correspondent pas au contexte du dispositif. La deuxième est l’approche push-based, adoptée par PRISM [16] et Pogo [6], où au contraire c’est le serveur qui déploie les tâches directement auprès des dispositifs mobiles. Son principal avantage est qu’elle permet un déploiement rapide des tâches de collecte, qui peut être très bénéfique dans le cadre où une rapide mise à jour de l’application doit être effectuée. Cependant, cette approche manque de transparence, dans le sens où les participants n’ont pas conscience des données qui sont collectées sur leur dispositif mobile. Pour le recrutement des utilisateurs, PRISM propose également un modèle basé sur la position des participants. Afin de permettre au système d’identi- fier les participants se situant dans une région spécifique, les applications mobiles ont besoin de reporter continuellement leur position sur le serveur, ce qui peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur. Finalement, la majorité de ces plate-formes propose une architecture centralisée, composée d’une application serveur pour le déploiement des tâches de collecte et une application mobile responsable de leurs exécutions. Cependant, ce style architectural impose à tous les utilisateurs du système de partager les ressources de l’infrastructure hébergeant la plate-forme, des mécanismes de stockage de données, le modèle financier imposé par le fournisseur de l’infrastructure et également la législation du pays où l’infrastructure est hébergée. Cela impose également les modèles mis en place pour déployer une application vers les terminaux mobiles, des mécanismes pour protéger la vie privée des utilisateurs, de récompense ainsi que la structure des données collectées. Dans ce contexte, nous pensons que ce type d’architecture limite fortement la réutilisation du système dans un contexte d’application non initialement prévu, ainsi que son passage à l’échelle. De plus, l’entité centrale représente un point unique de défaillance, qui, en cas d’attaque, peut compromettre l’ensemble des données collectées. Dans ce chapitre, nous avons présenté une vue d’ensemble du Mobile crowdsensing, ses caractéristiques, ses avantages ainsi que les défis qui doivent être adressés pour le déploiement de campagnes de collecte de données à grande échelle. À cause de ces 50nombreux défis, la mise en place de campagnes de collecte reste encore difficile, et reste réservée à des développeurs experts. Bien que de nombreuses plate-formes ont été proposées dans l’état de l’art pour simplifier le développement et le déploiement des ces campagnes, les solutions proposées restent encore restreintes à un contexte d’application particulier. De plus, la centralisation de leur architecture limite fortement la réutilisation de ces systèmes dans un autre contexte applicatif ainsi que leurs passages à l’échelle. À partir de ce constat, cela nous a mené à proposer APISENSE®, une plateforme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données. Plus particulièrement, APISENSE® c’est : 1. Un modèle de programmation facilitant le développement de tâches de collecte participatives et opportunistes 2. Un environnement mobile sécurisé assurant l’exécution des tâches de collecte 3. Une architecture décentralisée permettant d’assurer le passage à l’échelle de la plate-forme 4. Un modèle permettant de configurer une application serveur responsable du déploiement des tâches de collecte, de la persistance ainsi que de l’exploitation des données collectées. Dans le chapitre suivant, nous présentons notre première contribution concernant le modèle de programmation des tâches de collecte ainsi que l’environnement mobile dédié à leur exécution. 51Figure 7 – Tableau comparatif des plate-formes MCS 52Deuxième partie Contributions 533 C O L L E C T E M O B I L E D E D O N N É E S Sommaire 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 3.1 introduction Le Mobile Crowd Sensing (MCS) est un mode de collecte de données qui a récemment été défini comme :" la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents, qui collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun." [27]. Ces dernières années, le MCS a suscité l’intérêt d’un grand nombre d’acteurs académiques, dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux [9]. Cependant, le développement de ces applications reste une tâche complexe. En effet, ces applications ont besoin de faire face à de nombreuses propriétés non fonctionnelles telles que les ressources énergétiques limitées des dispositifs mobiles, le respect de 55la confidentialité des utilisateurs mobiles, ou encore le coût du recrutement d’un nombre important d’utilisateurs. À cause de cette complexité, il peut être très difficile pour de nombreuses acteurs de développer leurs applications capables de récolter la masse de données nécessaires pour leurs études. Ces dernières années, de nombreuses communautés scientifiques, utilisant le MCS dans leur processus expérimental, ont beaucoup discuté des bénéfices que pourrait apporter un système facilitant ce mode d’acquisition de données [27, 60, 66, 68]. Dans ce contexte, nous proposons dans cette thèse APISENSE®, une plate-forme visant de nombreux acteurs privés, publics ou académiques, leurs permettant de facilement développer et déployer des applications de collecte de données à travers des utilisateurs mobiles. Dans le chapitre section 1.4, page 13 , nous avons présenté une vue d’ensemble d’APISENSE®. Nous rappelons brièvement que le système est composé de trois entités logicielles i) un serveur central responsable du déploiement de tâches de collecte, ii) des nœuds de collecte dédiés aux utilisateurs, responsable du déploiement des tâches de collecte vers le serveur central et la persistance des données collectées, et finalement iii) un agent mobile, dédié aux participants (c.-à-d. utilisateur mobile) responsables de l’exécution des tâches de collecte. Dans ce chapitre, nous présentons notre première contribution qui consiste à proposer un modèle de programmation visant à minimiser l’expertise nécessaire liée aux développements d’applications de collecte, et la conception d’un environnement d’exécution mobile dédié à aux applications développées par notre interface de programmation. structure du chapitre La suite du chapitre est organisée comme suit : dans la section 3.2, nous faisons un bref rappel des problématiques et des solutions proposées dans l’état de l’art, et identifions les considérations prises en comptes pour la conception de notre solution. Nous présentons par la suite en section 3.3 une vue d’ensemble de l’interface de programmation proposée pour le développement des tâches de collecte. En section 3.4, nous présentons l’architecture du substrat d’exécution dédié à l’exécution des tâches de collecte. Nous présentons en section 3.5 l’évaluation d’un prototype réalisé sur Android, avant de conclure en section 3.6. 563.2 considérations et objectifs de conception Afin d’avoir une large applicabilité, permettant de définir une grande variété de tâches de collecte, nous devons proposer un modèle de programmation qui demande de prendre en considération principalement les trois points suivants : Diversité des tâches de collecte : Une tâche de collecte consiste à définir quel est le type de données (par ex. position, image), quand le processus de collecte doit être effectué (par ex. toutes les 5 minutes, lorsqu’un événement spécifique apparait) et comment une donnée doit être capturée. En ce qui concerne le comment, typiquement deux méthodes peuvent être utilisées. La première demande une interaction avec l’utilisateur (appelée collecte participative [7]), en lui demandant de répondre à un questionnaire ou prendre une photo par exemple. La deuxième s’effectue de manière autonome (appelée collecte opportuniste [39]), en interagissant directement avec les capteurs mobiles embarqués dans les terminaux mobiles. Diversité des traitements locaux : Pour la définition d’une tâche de collecte, quatre préoccupations doivent être prises en considérations : i) la limitation des ressources énergétiques, ii) la quantité des données générées et propagées vers le serveur, iii) la qualité des données et finalement iv) la confidentialité des participants. Prendre en compte ces considérations demande généralement de faire des compromis entre elles, en effectuant un traitement local avant de propager les données vers le serveur. L’objectif de ces traitements est de diminuer les données à propager sur le serveur, en remontant uniquement les données essentielles pour l’expérience, économisant ainsi la batterie de l’utilisateur par la réduction de communications réseau. Ces traitements peuvent consister à filtrer les données aberrantes, inférer une information contextuelle de haut niveau à partir de données brutes (par ex. mode de transport), ou encore alterner l’utilisation des capteurs en fonction de leurs consommations énergétiques (par ex. GPS vs géolocalisation GSM). Diversité des plate-formes mobiles : D’autre part, permettre le déploiement des tâches de collecte vers un grand nombre de participants demande également de prendre en compte la diversité des plate-formes mobiles disponibles. Ceci amène généralement à étudier et réaliser une application mobile spécifique pour chacune d’entre elles. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus 57de six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. En tant que plate-forme de collecte de données, APISENSE® a deux publics distincts : i) les utilisateurs qui veulent définir de nouvelles campagnes de collecte de données, ii) les participants qui exécuteront ces tâches de collecte sur leur dispositif mobile. Dans ce contexte, à partir des considérations décrites ci-dessus et de ces deux publics distincts évoluant dans APISENSE®, nous identifions les objectifs de conception suivants : Objectif de conception pour les utilisateurs : Afin de minimiser le niveau d’expertise nécessaire liée aux développements des applications de collecte, il est nécessaire de fournir une abstraction facilitant leurs développements. Dans ce contexte, l’objectif est de proposer un langage de programmation reposant sur trois propriétés : 1. la généralité : pour supporter une grande variété d’activités de collecte (c.-à-d. participative et/ou opportuniste), qui peuvent également impliquer une grande variété de capteurs. 2. l’accessibilité : permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur. 3. la portabilité : afin d’éviter de devoir définir plusieurs tâches de collecte pour différentes plate-formes mobiles, l’abstraction proposée doit être en mesure de s’exécuter sur ces différentes plate-formes. Objectif de conception pour les participants : Inévitablement, les participants mobiles jouent un rôle central dans le processus de collecte. Afin de favoriser leurs participations, nous pensons que la confiance et la transparence doivent être un aspect fondamental du système. Cela nécessite que les utilisateurs mobiles aient connaissance des données qui sont collectées sur leurs terminaux, avec qui ils les partagent et dans quel but. D’autre part, favoriser l’acceptabilité des utilisateurs demande de fournir un substrat d’exécution permettant de : 1. Contrôler la confidentialité : en laissant la possibilité aux utilisateurs de choisir les données qui sont partagées, les capteurs qui peuvent être utilisés par les 58applications de collecte, et dans quelle circonstance les données peuvent être partagées. 2. Minimiser l’impact énergétique : lié à l’exécution d’une application de collecte, pour ne pas empêcher une utilisation normale du dispositif. Notamment si de multiples applications doivent être exécutées sur un seul dispositif. 3. Récompense adaptée : pour favoriser la participation des utilisateurs mobiles, en rendant ludique le but de la collecte de données, ou en récompensant les utilisateurs financièrement selon la nature des données collectées. 3.3 langage de programmation des collectes Pour le développement des tâches de collecte, nous avons opté pour le langage de script JavaScript. Le choix du JavaScript est motivé principalement pour trois raisons. Premièrement, JavaScript est un langage accessible et populaire, bénéficiant de l’expressivité d’un langage générale. Cela donne aux utilisateurs une grande liberté pour définir des traitements complexes, intégrer des libraires déjà existantes de traitement de données (par ex. clustering) pour inférer des données de haut niveau directement dans le dispositif mobile. Ensuite, JavaScript est facilement transportable et exécutable sur de nombreuses plateformes mobiles, permettant un rapide déploiement et une rapide propagation des mis à jour de la tâche de collecte. Et finalement, d’un point de vue plus technique, JavaScript est nativement exécuté dans un bac à sable (sandbox en anglais), facilitant le contrôle des fonctionnalités des dispositifs mobiles accessibles par les scripts. Pour faciliter le développement des tâches de collecte, nous proposons une interface de programmation (API) dédiée à la collecte de données, au-dessus de JavaScript. Le principal objectif de l’API est de fournir une abstraction complète des technologies mobiles, permettant le développement d’application de collecte de données, sans avoir une expertise particulière dans ces technologies. Dans APISENSE, une tâche de collecte est spécifiée par un ou plusieurs scripts JavaScript, qui peuvent être déployés et exécutés sur les dispositifs mobiles des participants. Dans la suite de cette section, nous présentons une vue d’ensemble de l’API proposée. 593.3.1 Concept de l’interface de programmation Comme le montre la figure 8, notre API consiste en un ensemble de variables pré- définies, appelée façades, définissant l’ensemble des fonctionnalités accessibles par les scripts. Plus précisément, une façade permet d’interagir avec les ressources d’un dispositif, et est implémentée dans le langage natif de la plate-forme d’exécution. Ces ressources peuvent être par exemple des capteurs physiques (par ex. température, GPS), des capteurs logiciels (par ex. appel téléphonique, installation d’une application) ou encore l’interface graphique du dispositif mobile. Dans notre API, chaque façade proposée fait référence à une ressource spécifique, et délimite un sous-ensemble de fonctionnalités fourni par celle-ci. Ce procédé permet ainsi d’empêcher l’utilisation complète des fonctionnalités des dispositifs mobiles, pour des raisons de sécurité et de confidentialité vis-à-vis du participant. Par exemple, cela permet de crypter toutes les informations sensibles (par ex. contacts, numéro de téléphone, etc.), d’empêcher l’installation de nouvelles applications ou encore de faire des appels téléphoniques. Également pour des raisons de confidentialité, nous laissons la possibilité aux participants de contrôler les façades accessibles par les scripts de collecte. Par exemple, un participant peut à tout moment enlever la possibilité à un script de déterminer sa position, ou d’être notifié lorsqu’il reçoit des SMS. La communication entre les scripts et les façades peut s’effectuer de deux manières différentes. La première, de manière asynchrone, permet aux scripts d’être notifiés du changement des états des capteurs des dispositifs mobiles. La deuxième, de manière synchrone, permet aux scripts de collecte d’effectuer une action spécifique, ou alors de lire directement le dernier état d’un capteur. 3.3.2 Collecte de données dirigée par les évènements L’écoute des évènements permet de déclencher une action ou un traitement en fonction du contexte de l’utilisateur mobile. Par exemple, la collecte de données peut être déclenchée uniquement lorsque l’utilisateur est en situation de mobilité. L’observation du contexte consiste principalement à observer le changement d’état d’un capteur interne du dispositif. Pour interagir avec les capteurs, les façades proposent un ensemble de fonctions permettant aux scripts d’être notifiés de ce changement d’état. Le tableau 1 montre quelques exemples de façade et des fonctions associées dédiées à l’observation d’un événement particulier. L’observation consiste donc à souscrire une 60Figure 8 – Interface de Programmation APISENSE Façade Fonction Description $location onLocationChange Observation du changement de position $battery onBatteryStateChange Observation de l’état de la batterie $acc onAccelerometerChange Observation de l’accélération $phone onPhoneCall Observation des appels téléphonique Table 1 – Liste des fonctions d’observation d’événements prédéfinis. Paramètre Type Description configuration JSONObject Configuration de l’observation de l’état du capteur callback function(event,subscription) Fonction de rappel condition (optionnel) String Condition logique Table 2 – Liste des paramètres d’une fonction de rappel 61fonction de rappel, à une façade responsable du capteur capable de générer l’événement voulu. La souscription comprend trois paramètres, permettant la configuration du capteur, la fonction de rappel et une expression logique permettant de raffiner l’observation des événements, et retourne un objet de type Subscriber. configuration Le premier paramètre configuration laisse la possibilité de configurer l’observation du capteur en question. La configuration peut être utilisée afin de faire un compromis en qualité des données transmises par les capteurs (c.-à-d. fréquence d’échantillonnage, précision) et l’énergie consommée liée à l’observation du capteur. Un exemple classique est l’observation du changement de la position d’un utilisateur. Généralement, ce compromis peut être effectué en alternant le type de capteur utilisé — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais fournit une localisation moins précise —, ou la fréquence d’échantillonnage. Le tableau 2 illustre les configurations du capteur de position possibles. Fonction Description period Période d’échantillonnage de la position provider Capteur de position utilisé : gps ou network Table 3 – Configuration de l’observation de la position d’un utilisateur fonction de rappel Le deuxième paramètre permet d’enregistrer une fonction qui sera exécutée lors du changement d’état du capteur observé. Par exemple, le listing suivant montre la syntaxe permettant à un script de collecte d’être notifié lorsque l’utilisateur est en situation de mobilité : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque une nouvelle position est détectée }) Chaque événement est défini par un ensemble d’attributs, sérialisés par un ensemble de clés/valeurs utilisant le formalisme JSON. Chaque événement est au minimum défini par un nom, et la date de sa production. Le listing suivant illustre un exemple d’événement produit lorsqu’une nouvelle position de l’utilisateur est détectée : 62{ event : "location", time : 18005010510, latitude : 50.65, longitude : 2.11, accuracy : 100, speed : 3 } Dans cet exemple, l’événement est défini par cinq attributs indiquant la position de l’utilisateur (c.-à-d.latitude, longitude), la précision de la position (c.-à-d.accuracy) et la vitesse de l’utilisateur (c.-à-d.speed). condition logique Optionnellement, l’écoute d’événement peut être raffinée en insérant une condition lors de la souscription. La condition se définit par un opérateur appliqué à un attribut appartenant à l’événement et à une valeur. Plusieurs conditions peuvent être exprimées en ajoutant des opérateurs logiques de type et, ou ou non. (cf. listing 3.1). Le listing suivant illustre un exemple utilisant une expression logique, implémentant une solution naïve pour déterminer si l’utilisateur est en train de marcher : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque l’utilisateur marche }," &((speed > 3),(speed < 5)) ") Dans cet exemple, nous observons donc le changement de position, et nous définissons que la fonction de rappel doit être exécutée uniquement si l’utilisateur se déplace à une vitesse comprise entre trois et cinq Kilomètres/h. 1 expression ::= key’(’[condition+]’)’ | condition 2 condition ::= eventAttribute operator value 3 key ::= ( "!" | "&" | "|" ) 4 operator ::= ( "<" | "==" | ">" | "<=" | ">=" ) 5 eventName ::= alpha* 6 eventAttribute ::= alpha* 7 value ::= alphanumeric* Listing 3.1 – Grammaire BNF d’une expression logique objet de souscription Pour maintenir un lien entre la souscription et le script, un objet de type Subscriber (cf. table 4) est retourné lors de l’enregistrement. L’objet de souscription permet d’annuler la souscription à un événement particulier 63(fonction suspend), permettant d’éteindre un capteur actif afin de conserver l’énergie du dispositif mobile. La méthode resume permet de reprendre une souscription qui a été annulée. Fonction Description suspend Suppression de l’observation resume Redémarrage de la souscription Table 4 – Liste des fonctions d’un objet de souscription 3.3.3 Les actions En plus de l’observation des événements, les façades fournissent également des fonctions permettant d’exécuter des actions spécifiques. Dans la suite de cette soussection, nous présentons les principales actions prédéfinies par notre API qui sont la collecte et la propagation de données, l’interaction avec l’utilisateur mobile ou encore définir des informations pouvant être fournies en retour aux utilisateurs sur les données collectées. Collecte et propagation des données La collecte de données est effectuée à l’aide de la façade dédiée $trace. Cette façade possède trois fonctions comme le montre le tableau 5. La première permet de sauvegarder une donnée dans la base de données locale du terminal mobile (méthode add). Les données sont sous la forme d’un objet JSON, n’imposant aucune structure de données particulière pour représenter les données collectées. Cela laisse ainsi une grande flexibilité aux utilisateurs de définir leurs propres structures. Additionellement, les utilisateurs peuvent ajouter des méta-informations (méthode addHeader), permettant de diminuer la collecte de données redondantes, et leurs agrégations une fois propagées vers le serveur. Ces méta-informations représentent généralement des données statiques, c’est à dire qui n’évoluent pas dans le temps. L’API permet également de définir la stratégie pour propager les données vers les nœuds de collecte grâce à la méthode send. Lors de l’appel à cette fonction, la façade propagera les données sauvegardées dans la base de données locale si une connexion est disponible, sinon les données seront propagées une fois la connexion retrouvée. Dans le cas où aucune stratégie n’est définie, les données seront propagées automatiquement une fois que le 64dispositif est branché sur secteur et possède une connexion réseau. Cela permet de diminuer la consommation énergétique des dispositifs des participants. Fonction Description add(data) Collecter une donnée addHeader(key,value) Collecter une donnée statique send() Propagation des données collectées Table 5 – Liste des fonctions de la façade de collecte Interaction avec l’utilisateur Collecter des données de façon transparente peut ne pas être suffisant dans certains cas. En effet, certaines informations comme la satisfaction d’un utilisateur ou ses intentions sont difficilement perceptibles à partir de donnée brute. Prenons par exemple une collecte de donnée visant à observer la qualité du signal réseau d’un utilisateur mobile. Il peut être intéressant de voir comment la qualité du signal réseau influe sur la qualité de la communication vocale. Cependant, cette information peut être très difficilement inférée à partir des données brutes issues des capteurs. Dans ce contexte, une solution possible est de proposer des questionnaires d’évaluation aux utilisateurs. Ce type de collecte est également appelé collecte participative. Pour supporter la collecte participative, notre API dispose d’une façade permettant la création et la publication de questionnaire aux utilisateurs mobiles. Le tableau 6 illustre les principales fonctions fournies par cette façade. La création d’un nouveau questionnaire s’effectue à partir de la fonction create de la façade $survey. La fonction retourne un objet de type Survey, disposant d’un ensemble de fonctions permettant d’insérer des questions ouvertes (par ex. zone de texte), de question fermée (par ex. case à cocher), ainsi que des captures multimédias (c.-à-d. photo, vidéo, audio). La fonction then permet de modifier la séquence des questions proposée à l’utilisateur, qui est par défaut dans l’ordre de leurs créations. Cela permet par exemple de proposer des questions différentes selon les premières réponses données par l’utilisateur. Nous illustrerons un exemple de création de questionnaire dans la sous-section 3.5.1 . 65Facade $survey Return Fonction Description Survey create Création d’un nouveau questionnaire void publish(survey,callback) Publication du questionnaire Type Survey void close(label,question,responses) Création d’une question fermée void open(label,question) Création d’une question ouverte void image(label,format) Capture photo void audio(label,format) Capture audio void video(label,format) Capture vidéo void then(label,callback) Spécification de la prochaine fonction Table 6 – Liste des fonctions de la façade dédiée à la création des questionnaires Retour utilisateur Afin de favoriser leurs participations des utilisateurs, et surtout maintenir les utilisateurs dans la durée, nous avons intégré à notre API la possibilité d’effectuer facilement des retours visuels sur les données collectées par l’utilisateur mobile. Ces retours visuels peuvent être directement développés utilisant le couple JavaScript/HTML, fournissant une grande flexibilité pour concevoir des retours selon la nature de collecte de données. Pour simplifier leurs développements, nous proposons des modules complémentaires qui peuvent être inclus dans la tâche de collecte lors de son déploiement, ou téléchargés dynamiquement lors de l’exécution du script. Actuellement nous proposons deux modules génériques permettant de créer automatiquement des graphes ou des cartes géographiques à partir des données collectées. Par exemple, le listing 3.2 décrit un exemple l’utilisation d’un module facilitant la génération de graphe. Dans cet exemple, les trois premières permettent de charger le module (ligne 1), créer un nouveau graphique (ligne 2) et rendre disponible le graphique pour les utilisateurs (ligne 3). Les lignes suivantes permettent d’observer les évènements relatifs aux changements de la force du signal GSM (ligne 7), et d’ajouter une nouvelle valeur au graphique lorsqu’un nouvel évènement est détecté (ligne 9). La figure 9 montre une capture d’écran du rendu graphique de cet exemple. 66// signal strenght chart configuration var chartLib = require("lib-chart.js") chart = chartLib.area({name : "GSM Signal Strength Chart"}); chart.publish(); // telephony sensor monitoring initialization $telephony.onSignalStrengthChanged(function(event){ chart.add({ x : event.time, event.level }); }); Listing 3.2 – Exemple de retour utilisateur Figure 9 – Exemple de capture d’écran d’un retour utilisateur Dans cette section, nous avons présenté une vue d’ensemble de notre API, dédié aux développements des tâches de collectes de notre système. Une documentation plus détaillée est également disponible le site internet dédié à APISENSE 1 . Dans la 1. http://apisense.io 67section suivante, nous présentons les concepts et l’architecture de l’intergiciel dédié à l’exécution de l’interface de programmation présentée dans cette section. 3.4 intergiciel de collecte Dans la première section de ce chapitre, nous avons présenté une interface de programmation dédiée aux développements de tâche de collecte en environnement mobile. Dans cette section, nous présentons en détail l’architecture de l’intergiciel responsable de l’exécution des tâches de collecte. D’un point de vue utilisateur, l’intergiciel se dé- cline sous la forme d’une application mobile, qui peut être téléchargée et installée afin de participer aux expériences de collecte de données. Dans ce cadre, l’application peut être perçue comme un conteneur générique de tâches de collecte, capable d’interagir avec les différents serveurs pour la propagation des données collectées (vers les nœuds de collecte), le téléchargement des tâches de collecte (auprès du serveur central) ainsi que leurs exécutions. La figure 10 illustre une vue d’ensemble de l’architecture de l’intergiciel se déclinant en trois couches. Dans la suite de cette section, nous présentons en détails chacune de ces couches dédiées à : i) l’exécution des tâches de collecte (cf. sous-section 3.4.1), au contrôle des ressources du dispositif mobile (cf. sous-section 3.4.2), et iii) aux interactions avec les différentes entités logicielles d’APISENSE® (cf. sous-section 3.4.3). 3.4.1 Couche d’exécution Nous présentons ici la couche responsable de l’exécution des tâches de collecte développées avec l’interface de programmation que nous avons présentée dans la section précédente. La première couche de l’architecture présentée est responsable de l’exécution des tâches de collecte. La Figure 11 illustre plus en détail les différents modules et les interactions nécessaires à l’exécution des tâches de collecte. Le point d’entrée de cette couche est le Script Manager, qui est responsable de créer ou détruire une instance d’exécution d’une tâche de collecte, selon l’ordre envoyé par le Privacy Manager. Dans ce contexte, l’objectif clé est de fournir un environnement d’exécution sécurisé, permettant également aux participants de contrôler les données qu’ils partagent pour des raisons de confidentialité. Cependant, généralement tous les accès aux données brutes des capteurs peuvent constituer une menace pour la 68Figure 10 – Architecture de l’intergiciel mobile Figure 11 – Interaction de la couche d’exécution 69vie privée des participants. Par exemple, l’accès au microphone peut être utilisé pour enregistrer une conversation téléphonique souhaitant rester privée. L’accès continu au GPS peut permettre à un utilisateur anonyme d’être identifié juste en couplant des informations géographiques et temporelles [26]. Néanmoins, ce risque reste inhérent dans le domaine de la collecte de données. En effet, si nous voulons une protection parfaite, tous les accès aux capteurs devraient être bloqués. Pour mitiger ces risques, nous laissons la possibilité aux participants de contrôler les capteurs accessibles par les tâches de collecte (cf. 3.4.2). Pour la gestion de ce contrôle d’accès, chaque instance d’exécution d’une tâche de collecte est exécutée dans un bac à sable dédié (sandbox en anglais), permettant d’intercepter tous les appels entre les tâches de collecte et les capteurs du dispositif. Ainsi, toutes les fonctionnalités de l’interface de programmation sont fournies par un ensemble de façades (cf. sous-section 3.3.1), représentant également le point d’extension de notre l’architecture. Une façade est un objet, écrit en code natif de la plate-forme mobile, permettant l’interaction entre les tâches de collecte et l’environnement mobile. Le listing 3.3 montre l’exemple d’un squelette d’implémentation sous Android, de la façade permettant d’accéder aux capteurs de localisation. Dans cette façade, la fonction getReferenceName retourne le nom de la variable qui est utilisée pour accéder aux fonctions fournies par la façade. Chaque fonction annotée par une annotation @ScriptMethod, indique au moteur de script que la fonction est accessible par les tâches de collecte. Si nous reprenons l’exemple illustré dans la section précédente (cf. sous-section 3.3), la fonctionnalité $location.onLocationChanged accessible par la tâche de collecte, est implémentée par la façade LocationFacade, injectée en tant que variable $location et implémentant la fonction onLocationChanged. 1 public class LocationFacade extends AbstractAndroidFacade{ 2 3 public String getReferenceName() {return "location";} 4 5 public String getSensorDescription(){ ... 6 7 @ScriptMethod 8 public ISubscriber onLocationChanged( 9 JSONObject params,IScriptFunction callback,String... filters){ 10 // subscribe to location sensor update 11 return ... 12 } 13 14 public void shutdown() { ... // clean sensor subscription } 15 } 70Listing 3.3 – Squelette de l’implémentation d’une façade sur Android Lors de la création d’une nouvelle instance d’exécution, le Script Manager effectue une requête au Privacy Manager pour lister l’ensemble des capteurs admis par le participant. Le Script Manager injectera alors seulement les façades correspondantes aux capteurs qui auront été admis par le participant. Dans ce cadre, les façades correspondant aux capteurs non autorisés ne seront pas injectées, empêchant les scripts de bénéficier des fonctionnalités du capteur en question. Réguler l’accès aux capteurs Pour interagir avec les capteurs du dispositif mobile, les façades doivent interagir avec le Sensor Controller. Son objectif est principalement de réguler l’accès aux capteurs du dispositif et de filtrer les données sensibles. Par exemple, lorsqu’une façade demande l’accès à des informations de type SMS ou numéro de téléphone, les données retournées par la couche de contrôle seront automatiquement cryptées pour protéger la vie privée des participants. Deux types de communications peuvent être effectuées avec le Sensor Controller, des communications de type asynchrone permettant la lecture continuelle de l’état d’un capteur et de type synchrone afin de lire directement l’état d’un capteur. Pour économiser la batterie du dispositif mobile, le Sensor Controller dispose de deux mécanismes. Le premier est un mécanisme de cache, dédié aux communications synchrones. Ce mécanisme permet principalement de limiter une lecture excessive de l’état d’un capteur. Ce mécanisme consiste principalement à définir une fenêtre temporelle dans laquelle seront insérées toutes les données récupérées par le Sensor Controller via les APIs des systèmes mobiles, donnant accès aux données fournis par les capteurs physiques. Avant de procéder à un nouvel accès aux capteurs, la couche de contrôle vérifiera dans un premier temps si la donnée demandée est disponible dans la fenêtre temporelle. Si elle est disponible, la valeur du cache sera alors renvoyée. Le deuxième mécanisme mis en place tente de minimiser le nombre de souscriptions effectuées aux capteurs des dispositifs. Typiquement, un script peut être notifié du changement d’état d’un capteur en enregistrant à une façade une fonction de rappel, une expression logique permettant de filtrer les états ainsi qu’une période indiquant la fréquence des mises à jour des données. Dans le cas où plusieurs scripts procèdent 71à la souscription d’un même capteur avec une période différente, le Sensor Controller effectuera seulement une souscription aux capteurs correspondants, avec une période correspondante à la plus petite période des deux souscriptions. Prenons le cas par exemple où deux scripts effectuent une souscription au capteur GPS avec les périodes respectives de 10 et 20 secondes. Dans ce cas, le Sensor Controller effectuera une seule souscription au capteur GPS avec une fréquence d’échantillonnage égale à 10 secondes, et notifiera les deux scripts toutes les 10 secondes de la nouvelle position. 3.4.2 Couche de contrôle Cette couche est responsable du contrôle de l’exécution des scripts de collecte. Le contrôle consiste à automatiquement démarrer ou arrêter un script de collecte, à partir d’un ensemble de contraintes contextuelles définies par les participants et les expé- riences. Ces contraintes peuvent par exemple permettre aux participants d’empêcher l’exécution d’un script en dehors de la période allant de 9 heures et 18 heures ou lorsque le participant est en dehors d’une zone géographique. Un autre scénario envisagé est d’empêcher l’exécution d’un script si le niveau de la batterie est inférieur à 30 %. Ces contraintes peuvent être classifiées en quatre catégories : contrainte temporelle, contrainte géographique, contrainte de ressource et contrainte de capteur. Ces contraintes sont respectivement interprétées par les modules TimeConstraint, ZoneContraint, ResourceConstraint et SensorConstraint. Contrainte temporelle Ces contraintes, interprétées par le module Time Constraint, permettent de spécifier différentes périodes de la journée durant lesquelles les expériences ont l’autorisation d’être exécutées. Ces contraintes sont modélisées comme un ensemble de périodes où chaque période est définie par un temps de départ et un temps de fin. Pour une expérience donnée, la contrainte temporelle est vérifiée si, à instant t, t appartient au moins à une période définie par le participant et à une période définie par le contexte d’exécution de l’expérience. La surveillance contextuelle des contraintes temporelle consiste à surveiller l’horloge interne du dispositif mobile. Pour chaque contrainte définie, ce module programme une alarme, demandant au système d’être notifié au début et à la fin de la période définissant la contrainte. 72Contrainte géographique Interprétées par le module Zone Constraint, les contraintes géographiques permettent de spécifier un ensemble de lieux ou de régions, dans lesquelles les scripts peuvent être exécutés selon la position du participant. Une contrainte géographique est modélisée par un ensemble de régions circulaires en terme de latitude, longitude et un rayon en kilomètre. Pour une expérience donnée, la contrainte géographique est vérifiée si à une position p donnée, p est inclus au moins dans une zone définie par le participant ou par le contexte d’exécution de l’expérience. En ce qui concerne la surveillance contextuelle, surveiller activement la position de l’utilisateur peut engendrer une grande consommation énergétique du dispositif. Pour diminuer cette consommation énergétique, nous utilisons un algorithme fréquemment utilisé [3, 8] dans la littérature. Typiquement, l’idée principale est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance de l’utilisateur et la zone la plus proche de sa position actuelle. Contrainte de ressource Ces contraintes permettent de limiter les ressources consommées par l’application. Le participant peut par exemple définir un seuil de batterie pour stopper l’exécution de toutes les expériences de collecte pour éviter un épuisement complet de sa batterie. Une autre ressource qui peut être contrôlée est la quantité de données échangées via une connexion de données mobiles qui peut induire un coût monétaire pour le participant. Dans ce cadre, le participant peut définir un seuil maximum de données transmises lorsqu’une connexion est utilisée. Contrainte de capteur Ces contraintes permettent de spécifier les fonctionnalités permises par les scripts de collecte. Dans l’interface de programmation proposée pour définir une expérience de collecte, nous avons vu que les fonctionnalités accessibles par les scripts se font par l’intermédiaire de façades. Pour chaque façade, le participant a la possibilité de définir s’il autorise l’accès à l’ensemble des fonctionnalités proposées par la façade. Par exemple, le participant peut enlever l’autorisation de la façade $sms, qui supprimera la possibilité de recueillir des informations relatives aux SMS envoyés et lus. 73Dans l’architecture présentée précédemment en figure 10, les modules TimeConstraint, ZoneConstraint et RessourceConstraint ont pour rôle de surveiller le contexte du dispositif (e.g. horloge interne, position, niveau de batterie) et d’envoyer un message au Privacy Manager afin de notifier un changement de contexte du dispositif mobile. Lors de la notification, le Privacy Manager vérifie pour chaque expérience si les contraintes spécifiées par le participant et par l’expérience sont respectées. Dans ce cas, le Privacy Manager interprètera les contraintes de capteurs définies par le module Sensor Constraint pour générer une nouvelle instance d’exécution ou stopper l’exécution d’une expérience de collecte. 3.4.3 Couche d’interaction La dernière couche présenté dans cette section représente la couche de plus haut niveau de l’intergiciel. Cette couche est principalement responsable des interactions entre le dispositif mobile avec les différentes entités logicielles de notre architecture et le participant. Typiquement, cinq types d’interactions sont nécessaires au déroulement des expériences de collecte : i) l’enregistrement auprès du serveur central, ii) la souscription à une expérience de collecte, iii) la mise à jour des expériences, iv) l’interaction avec les participants et finalement v) la propagation des données collectées. Dans la suite de cette sous-section, nous présentons ces interactions et les modules responsables de leurs fonctionnements. Souscription du dispositif Le processus d’enregistrement, géré par le Profile Manager, permet d’informer le serveur central de la disponibilité d’un nouveau périphérique mobile pour l’exécution de nouvelles tâches de collecte. Typiquement, cette phase d’enregistrement consiste à fournir des informations générales du dispositif et du participant, permettant de proposer des expériences de collecte adéquates. Dans ce contexte, deux sortes d’informations sont principalement échangées. Les premières sont des informations relatives au dispositif mobile incluant le type du dispositif (par ex. smartphone, tablette), son système d’exploitation (par ex. Android, iOS), ses performances ainsi que les capteurs embarqués (par ex. température, GPS). Pour raffiner la proposition des expériences, les participants ont la possibilité de compléter ces informations volontairement en indiquant les différents lieux de vie dans lequel ils évoluent (par ex. maison, travail) son statut (par ex. professionnel) ainsi que son âge.Toutes les informations transmises 74Figure 12 – Règles de confidentialité resteront confidentielles, c’est-à-dire qu’elles ne seront pas directement accessibles par les nœuds de collecte du système. Ces informations seront utilisées uniquement par le serveur central lors de la phase du déploiement des expériences de collecte. D’autre part, afin de protéger la vie privée des participants, le Profile Manager permet aux participants de définir certaines règles de confidentialités (cf. figure 12). Principalement trois catégories de règles peuvent être définies. Les deux premières permettent de spécifier des zones géographiques et temporelles, indiquant à l’agent mobile une interdiction d’exécuter des tâches de collecte. La dernière catégorie permet de spécifier des règles d’autorisations, permettant d’empêcher l’activation des capteurs ou l’accès aux données brutes du capteur si l’utilisateur ne veut pas partager une information. Nous aborderons plus en détails ce point dans la sous-section suivante (cf. sous-section 3.4.2). Souscription à une expérience Une fois le dispositif enregistré, les participants ont la possibilité de lister (via le ExperimentManager), un sous ensemble d’expériences de collecte proposées par les utilisateurs. Les expériences sont retournées en fonction des informations fournies lors de la phase d’enregistrement. Chaque expérience est définie tout d’abord par un nom ainsi qu’une brève description indiquant l’objectif de la collecte de données. La description d’une expérience est également caractérisée par un contexte d’exécution définissant quand l’expérience doit être exécutée. Le contexte d’exécution est défini 75selon une dimension géographique (par ex. à l’intérieur d’une zone) et une dimension temporelle (par ex. période dans la journée). D’autre part, des informations relatives aux capteurs utilisés sont fournies pour indiquer aux participants quels sont les types de données qui peuvent être collectées sur leurs dispositifs. À partir de l’ensemble des descriptions disponibles, le participant a la possibilité de soumettre une souscription à une expérience de collecte. Dans ce cadre, la souscription déclenchera le téléchargement des scripts associés dans le système de fichier du dispositif mobile ainsi que des informations complémentaires propres aux scripts de collecte. Ces informations comprennent la version actuelle des scripts de collecte, l’adresse du serveur de collecte ayant initié l’expérience ainsi qu’un identifiant anonyme généré lors de la souscription. L’identifiant anonyme généré par le serveur central est unique pour chaque expérience. Cette identifiant servira alors de clé d’authentification lors de la propagation des données vers le serveur de collecte. Lorsque les scripts de l’expérience sont téléchargés, le module déclenche automatiquement son exécution. Néanmoins le participant garde à tout moment la possibilité d’arrêter son exécution. Mise à jour des expériences La mise à jour des expériences de collecte est gérée par le module NotificationManager. Les mise à jour sont effectuées par des communications de type push, c’est-à-dire des communications serveur vers mobile. Dans notre contexte applicatif, cela permet d’éviter de faire des requêtes périodiques vers le serveur, induisant un surcoût énergétique pour assurer une rapide prolifération. Pour assurer ce type de communication, nous utilisons des services intermédiaires proposés par les plate-formes mobiles actuelles, telles que APNs (Apple Push Notification service) pour plateformes tournant sur iOS et GCM (Google Cloud Messaging) pour les plateformes Android. Généralement, pour utiliser ce type de service, les dispositifs mobiles doivent tout d’abord procéder à une phase d’enregistrement auprès du service en question. Cette phase permet l’obtention d’un identifiant unique, qui devra ensuite être partagé avec le serveur — dans notre contexte, le serveur central— voulant envoyer des messages vers le dispositif en question. Le serveur peut ensuite faire appel au service dédié en utilisant les identifiants partagés pour propager directement des informations auprès des dispositifs mobiles. Dans ce contexte, lorsqu’une nouvelle version d’une expérience est déployée, le serveur central envoie un message à tous les participants ayant souscrits à l’expérience en question. Ce message est ensuite intercepté par le NotificationManager qui déclenchera automati- 76quement le téléchargement de la nouvelle version, sans imposer aux participants de télécharger à nouveau la tâche de collecte manuellement. Retour utilisateur Le Feedback Manager est responsable de l’interaction entre les tâches de collecte et les participants. Comme nous l’avons mentionné précédemment (cf. sous-section 3.3.3, page 66 ), l’interface de programmation proposée permet de diffuser des visualisations aux participants. Ces visualisations peuvent consister à fournir des statistiques sur les données collectées sous forme de graphique ou de carte, leur demander de prendre une photo d’un évènement particulier ou répondre à un questionnaire. Ces visualisations peuvent être directement développées en HTML/JavaScript, fournissant une grande flexibilité pour définir leurs propres visualisations en fonction de la nature de leurs expériences. D’autre part, cela permet également d’être indépendant de la plate-forme d’exécution, évitant ainsi le développement de plusieurs visualisations selon les plateformes visées. Dans ce cadre, nous tirons bénéfice des modules fournis par les plateformes mobiles (par ex. WebView 2 pour Android, UIWebView 3 pour iOS) pour faciliter l’intégration de contenus web dans une application mobile. Dans ce contexte, les tâches de collecte peuvent interagir avec le FeedBackManager, via une façade dédiée, permettant de publier un nouveau contenu accessible par le participant. Chaque contenu web est ensuite sérialisé et sauvegardé dans une base de données, et pourra être visualisé par le participant à tout moment à partir d’une interface graphique fournie par le FeedBackManager, (cf. figure 13). Propagation des données La propagation des données vers les nœuds de collecte est gérée par le TrackManager. Lors de l’exécution d’une tâche de collecte, les données collectées sont transmises au TrackManager qui les sauvegarde dans la base de donnée locale du dispositif. Pour chaque expérience, le processus de propagation (cf. sous-section 3.3.3) consiste à compresser les données collectées, ajouter des méta-informations sur la configuration du dispositif du participant (c.-à-d. filtre de vie privée) et à faire appel au service dédié du serveur de collecte ayant initié l’expérience pour l’envoi des données. Pour des raisons de sécurité, l’envoi des données s’effectue en utilisant le protocole HTTPS pour le cryptage des données. 2. Android WebView : http://tinyurl.com/android-webview 3. iOS UIWebView : http://tinyurl.com/ios-webview 77Figure 13 – Exemple de contenu web disponible via le FeedbackManager Nous venons de présenter dans cette section l’intergiciel mobile responsable de l’exécution de tâche de collecte, développée avec l’interface de programmation présentée dans la première section de chapitre. Dans la section suivante, nous présentons l’évaluation d’un prototype implémentant les concepts proposés dans ce chapitre. 3.5 évaluation du prototype Afin d’implémenter les concepts présentés dans ce chapitre sur une plate-forme mobile spécifique, celle-ci doit permettre principalement i) d’effectuer des processus en tâche de fond, ii) permettre la lecture en continue des capteurs, iii) et finalement être capable d’intégrer un moteur de script dans une application. Lorsque nous avons commencé le développement de notre prototype, la plate-forme Android correspondait parfaitement à ces caractéristiques, contrairement aux systèmes d’exploitation iOS qui ne permettaient pas d’exécuter des processus en tâche de fond limitant ainsi le développement d’application de collecte opportuniste. Cependant, les récentes mise à jour de ce système d’exploitation fournissent désormais ce support, rendant portable notre système pour iOS. Par manque de temps, nous n’avons pas pu fournir un prototype complet sur ce système d’exploitation, mais nous avons fourni une preuve de faisabilité disponible en open source 4 . Le prototype Android proposé a été conçu pour être utilisé comme application autonome ou comme librairie. En tant qu’application autonome, l’application peut être 4. https://github.com/APISENSE/APISENSE-SDK-iOS 78téléchargée par des participants voulant évoluer dans le système en flashant un QR code publié sur le site internet APISENSE® 5 . Plus particulièrement, le prototype réalisé à été développé en utilisant la version 2.3 du SDK proposé par Android. L’ensemble des modules proposés par l’architecture est inclus dans un Service de haute priorité pour prévenir que le système ne supprime notre application lorsqu’il a besoin de mémoire. Pour l’exécution des scripts, nous utilisons Rhino 6 , un moteur d’exécution JavaScript pour Java, qui permet l’interopérabilité des deux langages. L’ensemble du code réalisé représente approximativement 30000 lignes de codes, incluant l’interface graphique et l’architecture de l’application et les façades développées. Dans la suite cette section, nous présentons plusieurs cas réels d’expériences, montrant la diversité des tâches de collecte qui peuvent être réalisées à l’aide notre interface de programmation. Nous comparons par la suite son expressivité avec les différentes approches proposées dans la littérature, et discutons du coût énergétique lié à l’exécution des tâches de collecte sur les dispositifs mobiles. 3.5.1 Quelques exemples de collectes Pour démontrer l’expressivité de l’interface de programmation proposée dans ce chapitre, nous avons implémenté quatre tâches de collecte différentes (cf. table 7). Chaque tâche de collecte est inspirée de l’état de l’art, et démontre différents aspects de APISENSE. Wifi/Blutooth Scanner Wifi/Blutooth Scanner est une application opportuniste, montrant une interaction avec les capteurs Wi-Fi et Bluetooth d’un dispositif. Le listing 3.4 illustre le script implémentant cette application. L’objectif du script est de collecter, toutes les minutes, les points d’accès WIFI et les périphériques Bluetooth d’un utilisateur mobile. Dans le script, nous enregistrons une fonction de rappel aux façades $wifi et $bluetooth responsables des interactions avec ces capteurs, et nous configurons les capteurs pour qu’ils effectuent une nouvelle recherche toutes les minutes (period:"1 min"). La 5. http://www.apisense.fr 6. http://www.mozilla.org/rhino 79Application Capteurs Description Wifi-Blutooth Scanner Réseaux Application opportuniste. Collecte périodiquement les périphériques Bluetooth et Wi-Fi. Citoyen Journaliste GPS + Questionnaire Application participative. Demande à l’utilisateur de prendre une photo lorsqu’il se situe dans une zone géographique. Qualité Réseau Réseau + Questionnaire + Télé- phone Combinaison d’une application opportuniste et participatif.pour corréler la qualité d’une communication en fonction de la qualité du signal GSM. Exploiter des capteurs externes Bluetooth Communication avec un robot Lego Mindstorms NXT Inférence Conxtuelle Accéléromètre + Questionnaire Intégration d’une machine d’apprentissage pour inférer l’activité d’un utilisateur. Table 7 – Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) fonction de rappel enregistrée collecte alors les résultats donnés par les capteurs pour les propager vers le serveur ($trace.add(event)). 1 $wifi.onScan({period : "1 min"},function(event){ 2 $trace.add(event) 3 }) 4 $bluetooth.onScan({period : "1 min"}, function(event){ 5 $trace.add(event) 6 }) Listing 3.4 – Tâche de collecte : Wifi/Bluetooth Scanner Nous décrivons dans l’exemple suivant un exemple de collecte participative. Le Citoyen Journaliste L’objectif de cette application est de montrer comment une tâche de collecte peut interagir avec un utilisateur. Le Citoyen Journaliste, présenté initialement en [29], demande aux utilisateurs mobiles de prendre une image dans une région géographique spécifique, et de la commenter. Le script présenté dans le listing 3.5, crée d’abord un questionnaire (ligne 1-3). En ligne 5 nous observons la position de l’utilisateur et définissons que la fonction enregistrée (ligne 6-8) doit être exécutée uniquement lorsque la position de l’utilisateur se trouve dans le polygone précis (ligne 8). La fonction enregistrée publie le questionnaire à l’utilisateur (ligne 6), et collecte les données pour les propager vers le serveur lorsque l’utilisateur aura répondu au questionnaire. 801 var survey = $survey.create(); 2 survey.image("Take a picture"); 3 survey.open("Add a comment"); 4 5 $location.onLocationChanged(function(event){ 6 $survey.publish(survey,function(content){ 7 $trace.add(content); 8 $task.finish(); 9 }); 10 },"&((lat >= 0)(lat <= 1)(lon >= 0)(lon <= 1))") Listing 3.5 – Tâche de collecte : Le Citoyen Journalist Qualité Réseau Dans cette application, inspirée de MyExperience [25], nous voulons étudier la corrélation entre la qualité du signal réseau et la qualité de la communication vocale. Dans cette application (cf. listing 3.6), nous voulons montrer deux nouvelles propriétés de notre interface de programmation qui sont i) sa capacité à pourvoir adapter la séquence des questions d’un questionnaire en fonction des premières réponses d’un utilisateur et ii) combiner une collecte opportuniste et participative Dans la première partie du script (ligne 1-6), nous collectons la force du signal réseau GSM lorsque l’utilisateur est en situation de mobilité. Afin d’effectuer un retour sur les données collectées, nous insérons un nouveau point dans la visualisation proposée (ligne 6). Dans la deuxième partie du script (ligne 8-14), nous définissons un questionnaire et ajoutons deux questions relatives à la qualité d’une communication vocale. La première question consiste à demander la qualité de sa communication vocale. La deuxième consiste à lui demander pourquoi le participant a considéré que la communication a été mauvaise. Nous définissons ensuite l’enchaînement des questions (ligne 15-18) qui consiste à proposer uniquement la deuxième question uniquement si l’utilisateur a répondu une réponse spécifique à la première question. Ensuite, nous proposons le questionnaire lorsque l’utilisateur a terminé une communication vocale. 1 $location.onLocationChanged(function(event){ 2 $trace.add({ 3 latlng : [event.latitude,event.longitute], 4 signal : $telephony.signalStrength() 5 }) 6 }) 7 818 var qualitySurvey = $survey.create() 9 qualitySurvey.close("q1", 10 "Quelle a été la qualité de votre communication ?", 11 ["Trés Mauvaise", "Mauvaise", "Moyenne", "Bonne", "Excellente"]) 12 qualitySurvey.close("q2", 13 "Quel a été le probléme ?", 14 ["écho", "grésillement", "voix coupé"]) 15 qualitySurvey.then("q1",function(response){ 16 if (response == "Trés Mauvaise") 17 return "q2" 18 }) 19 20 $phone.onCallFinish(function(event){ 21 $survey.publish(qualitySurvey, function(content){ 22 $trace.add({ 23 latlng : $location.lastLocation(), 24 signal : $telephony.signalStrength(), 25 content : content 26 }) 27 })} Listing 3.6 – Exemple d’application participative Exploiter des capteurs externes Figure 14 – Flux de données de l’expérience Manipulation de Lego NXT Dans cette expérience, nous montrons que notre interface de programmation peut également être utilisée pour interagir avec des capteurs externes, afin de collecter des données qui ne peuvent pas être initialement capturées avec les capteurs initialement inclus dans les dispositifs mobiles. Cette expérience exploite les capteurs intégrés d’un robot Lego Mindstorms NXT (c.-à-d. capteur de contact, d’ultrason, de température et de pression atmosphérique), et permet également d’interagir avec le moteur du robot afin d’en prendre le contrôle à partir de la tâche de collecte. 82Comme le montre la figure 14, l’expérience est composée de deux scripts : NXT.js et Task.js décris par le listing 3.7. Le rôle du premier script est de faire une abstraction avec les différentes fonctionnalités des robots NXT. Ce script communique avec la façade responsable de l’interface Bluetooth, pour établir une connexion avec le robot et le manipuler à distance. Ce script peut être ensuite intégré dans le script Task.js en tant que librairie (ligne 1). Dans cet exemple, nous établissons une connexion avec un robot NXT à proximité (ligne 8), et déclenchons les moteurs du robot pour le faire avancer. Nous réagissons également lorsque le robot rencontre un obstacle pour le faire changer de direction (ligne 11-13). Les lignes (15-22) permettent ensuite de collecter des données capturées par les capteurs du dispositif mobile (par ex. GPS) et des capteurs du robot NXT (c.-à-d. pression atmosphérique et température) lorsqu’il se déplace. 1 var nxt = require("NXT.js"); 2 3 var change_direction = function(){ 4 nxt.move_back() 5 nxt.turn_left({ ’angle’ : 45 * random(), ’duration’ : ’2s’}) 6 nxt.move_forward() 7 } 8 nxt.onConnect({’timeout’: ’30s’},function(){ 9 nxt.move_forward() 10 11 nxt.onTouch(function(){ 12 change_direction() 13 }) 14 15 $location.onLocationChanged({provider : ["network"]},function(event){ 16 $trace.add({ 17 latlng : [event.latitude,event.longitude], 18 pressure : nxt.pressure(), 19 temperature : nxt.temperature() 20 }) 21 }) 22 }) Listing 3.7 – Tâche de collecte : Manipulation de Lego NXT Inférence Contextuelle Dans cette dernière expérience, l’objectif est de montrer que APISENSE® peut également être utilisé pour rapidement prototype et valider empiriquement des algorithmes contextuels. Dans ce scénario, nous voulons mettre en place un modèle d’apprentissage permettant de reconnaître l’activité d’un utilisateur (c.-à-d. assis, debout, marche, courir, monter ou descendre des escaliers). L’idée générale de l’approche est d’observer 83les données transmises par le capteur d’accélération afin de déterminer l’activité de l’utilisateur. Le script décrit dans le listing 3.8 implémente l’algorithme initialement proposé en [37]. 1 var classes = ["walk","jog","stand", "sit", "up", "down"]; 2 var current = 0; var buffer = new Array(); 3 var model = weka.newModel(["avrX","avrY",...], classes); 4 var filter = "|(dx>"+delta+")(dy>"+delta+")(dz>"+delta+")"; 5 6 var input = $accelerometer.onChange(filter, 7 function(acc) { buffer.push(acc) }); 8 9 var learn = time.schedule({ period: ’5s’ }, function(t) { 10 if (model.learn(classes[current]) >= threshold) { 11 current++; 12 } 13 if (current < classes.length) { // Learning phase 14 input.suspend(); 15 var output = $dialog.display( 16 { message: "Select movement", spinner: classes }); 17 model.record(attributes(buffer), output); 18 sleep(’2s’); 19 buffer = new Array(); 20 input.resume(); 21 } else { // Exploitation phase 22 dialog.display({message: "Learning phase completed"}); 23 learn.cancel(); 24 model.setClassifier("NAIVE_BAYES"); 25 time.schedule({ period: ’5s’ }, function(t) { 26 trace.add({ 27 position: model.evaluate(attributes(buffer)), 28 stats: model.statistics() }); 29 buffer = new Array(); 30 } } }); Listing 3.8 – Tâche de collecte : Inférence Contextuelle. Le script se décompose en deux phases : i) une phase d’apprentissage et ii) une phase d’exploitation. Pour réaliser la phase d’apprentissage, nous avons intégré un algorithme d’apprentissage [44] implémenté en Java dans l’intergiciel mobile, et nous avons ajouté une façade pour utiliser ses fonctionnalités à partir du script. Durant la phase d’apprentissage, le script génère une boite de dialogue demandant à l’utilisateur de répéter des mouvements spécifiques. Lorsque l’utilisateur exécute les mouvements demandés, nous enregistrons les données d’accélérations selon les trois axes, et calculons des métriques (c.-à-d. moyenne, l’écart type, etc. ) sur les valeurs obtenues. Ces métriques sont ensuite insérées dans l’algorithme d’apprentissage et le mouvement qui à été effectué. Une fois que suffisamment de données ont été insérées dans le modèle d’apprentissage, le 84Predicted Class Acc (%) Walk Jog Stand Sit Up Down Walk 66 0 4 0 0 0 94,3 Jog 0 21 0 0 0 0 100 Stand 4 0 40 0 0 0 90,9 Sit 0 0 2 83 0 0 97,6 Up stair 0 0 0 0 22 0 100 Down stair 0 0 0 0 0 11 100 Table 8 – Tableau décrivant la qualité du système de classification script passe en phase d’exploitation. Dans cette phase, nous évaluons, toutes les cinq secondes, les métriques des données d’accélération dans le modèle d’apprentissage. Le résultat correspondant au mouvement de l’utilisateur et ensuite sauvegardé avec les statistiques du modèle obtenu pour les reporté sur le serveur. Le tableau 8 reporte la matrice de confusion décrivant la qualité du système de classification obtenue par un utilisateur durant cette expérience. La matrice illustre le nombre de mouvements effectués durant cette expérience, et la haute précision des prédictions obtenues pour chacun des mouvements. Discussion Dans cette sous-section, nous discutons de l’expressivité et la complexité des approches décrites dans l’état de l’art avec APISENSE®. Nous utilisons le nombre de lignes de code pour comparer la complexité avec deux applications de collecte couvrant les deux formes d’acquisition de données qui sont la collecte opportuniste (application Wifi-Bluetooth Scanner) et participative (application Citoyen Journaliste). Le tableau 9 présente le nombre de lignes de code nécessaires pour développer ces applications. Le symbole X signifie que l’application ne peut pas être exprimée et le symbole ? signifie que l’application est réalisable, mais que nous n’avons pas d’information sur le nombre de lignes de code nécessaire avec l’approche concernée. En terme de lignes de code, APISENSE® est beaucoup plus concis (4 lignes) que les approches utilisant le langage déclaratif XML pour concevoir une application. C’est la cas avec MyExperience (27 lignes) et Medusa (45 lignes) pour l’application Citoyen Journaliste. De plus ces deux dernières approches ne supportent la définition d’application de collecte purement opportuniste comme l’application Wifi-Blutooth 85Scanner. Même si la concision de notre code est à peu près similaire à Anonysense (7 lignes de code) et Pogo (6 lignes de code), notre approche comporte de nombreux avantages comparés à ces approches. Par apport à Anonysense, qui utilise un DSL pour le développement des applications, le langage JavaScript nous permet d’avoir une plus grande flexibilité pour concevoir des traitements plus complexes, et surtout nous permet de facilement réutiliser du code déjà existant, comme nous l’avons montré dans l’application présentée en sous-section (cf. 3.5.1). Par rapport à Pogo, utilisant également une interface de programmation basée sur JavaScript, notre interface de programmation supporte les tâches de collecte de données participative qui n’est pas possible avec l’interface proposée par Pogo. La seule approche proposée supportant la collecte opportuniste et participative est PRISM, qui propose le déploiement d’applications de collecte écrites en code natif. Cependant PRISM ne propose pas d’abstraction pour faciliter le développement de ses applications, nécessitant une expertise approfondie en développement mobile. L’application Citoyen Journaliste nécessite par exemple 330 lignes de code. En outre, le développement natif des applications les rend exclusives pour un OS mobile, demandant par conséquent d’étudier et développer une nouvelle version de l’application pour supporter l’hétérogénéité des OS disponible. Nous avons présenté dans cette section un ensemble d’applications réalisables avec APISENSE®. Nous pensons que APISENSE® propose un bon compromis entre toutes les approches proposée dans l’état de l’art, supportant la collecte opportuniste (application Wifi/Blutooth Scanner), participative (application Citoyen Journaliste), ou une combinaison des deux (application Qualité Réseau) tout en fournissant une abstraction complète des technologies mobiles. En proposant une interface de programmation au-dessus de JavaScript, APISENSE® permet également de définir des traitements complexes (application Inférence contextuelle), et faciliter la réutilisation de code déjà existant (application Exploiter des capteurs externes). Nous pensons que la réutilisation est un aspect fondamental pour le succès APISENSE®, favorisant son utilisation par de nombreux acteurs académiques ou industriels, avec des niveaux d’expertises différents dans la collecte de données. En effet, les experts du domaine peuvent proposer des modules ou algorithmes complexes, utilisant les capteurs des dispositifs pour inférer des informations de haut niveau (par ex. activité de l’utilisateur, mode de transport), ou encore utiliser intelligemment les différents capteurs pour réduire la consommation énergétique des applications de collecte dans un contexte spécifique [14]. Ces modules pourront être ensuite réutilisés par des utilisateurs non experts. Et finalement, l’utilisation de JavaScript permet également de supporter l’hétérogénéité des OS mobiles 86Wifi-Blutooth Scanner Citoyen Journaliste APISENSE 4 9 Medusa [55] X 45 MyExperience [25] X 27 Anonysense [62] 5 X Pogo [6] 4 X PRISM [16] ? 330 Table 9 – Comparaison de l’expressivité et du nombre de lignes de code pour s’affranchir d’étudier et développer une nouvelle application pour chaque OS disponible. 3.5.2 Coût énergétique d’une expérience de collecte Dans cette section, nous comparons la consommation énergétique de notre prototype réalisé sur Android avec Funf [1], une application présentée dans l’état de l’art APISENSE® ( section 2.3.1, page 34 ). Nous rappelons que Funf est un outil permettant de générer des applications natives Android à la carte. Pour réaliser cette expérience, nous avons exécuté chaque application durant 24 heures, sur un Nexus-S réinitialisée à une configuration par défaut, pour limiter le bruit qui peut être induit par d’autres applications. Chaque application est configurée pour collecter toutes les 10 minutes des informations de la batterie du dispositif mobile. Le résultat de cette expérience est illustré par la figure 15 Dans cette courbe, l’abscisse représente le temps, et l’ordonnée la tension en millivolt représentant le niveau de la batterie du dispositif. La tension d’un dispositif varie généralement entre 4200 millivolts, représentant 100% de niveau de batterie, et 3200 millivolts. Comparé à une application native (baseline), nous pouvons observer que le surcoût énergétique de notre prototype est faible comparé à une application native, et moins important que celui imposé par Funf. Bien que notre solution soit plus consommatrice qu’une application native, notre solution ne nécessite aucune expertise particulière de la plate-forme Android, et rend également transparent le déploiement de l’application et la propagation des données pour les développeurs. Comme la consommation énergétique dépend fortement de i) la nature de l’expé- rience, ii) du type de capteur utilisé et iii) du volume des données produit, nous avons réalisé une seconde expérience permettant d’estimer l’impact des différents capteurs 87 4100 4120 4140 4160 4180 4200 0 200 400 600 800 1000 1200 1400 Voltage (mV) Time (s) Android Native Application Funf Bee.sense Figure 15 – Impact d’APISENSE sur la consommation énergétique sur la consommation de la batterie (cf. figure 16). Pour cette expérience, nous avons développé trois scripts, qui ont été exécutés séparément sur trois dispositifs mobiles. Le premier script (APISENSE + Bluetooth), déclenche un scan toutes les minutes et collecte le niveau de la batterie aussi bien que le résultat du scan. Le second (APISENSE + GPS) collecte également toutes les minutes les données GPS tandis que le dernier script collecte des données relatives au point d’accès WIFI. Cette expérience démontre que même avec un stress important sur les capteurs, il est possible de collecter des données durant une journée normale de travail sans avoir à recharger le dispositif mobile (40% d’énergie consommée après 10 Heures d’activation du GPS). 3.6 conclusion Le développement d’applications mobiles dédiées à la collecte de données est un processus long et complexe. Généralement, afin de déployer l’application vers un grand nombre d’utilisateurs, plusieurs applications ont besoin d’être développées pour faire face à la diversité des plate-formes mobiles disponibles. D’autre part, ces applications doivent généralement prendre en compte des aspects non fonctionnels tels que la 88 0 20 40 60 80 100 0 100 200 300 400 500 Battery level (%) Time (min) APISENSE APISENSE + GPS APISENSE + Bluetooth APISENSE + WiFi Figure 16 – Impact des capteurs sur la consommation énergétique protection de la vie privée des utilisateurs ainsi que la consommation énergétique de ces applications. Dans ce chapitre, nous avons présenté notre approche pour diminuer le coût lié aux développements d’applications mobiles dédiées à la collecte de données. Plus particulièrement, nous avons présenté dans un premier temps une interface de programmation de haut niveau pour la définition d’une application de collecte. L’interface proposée a été conçue pour i) faire face à la diversité des applications de collecte (i.e. participative, opportuniste), ii) supporter l’hétérogénéité des plate-formes mobiles iii) tout en permettant de s’abstraire de la complexité liée au développement mobile. Nous avons ensuite présenté l’environnement mobile dédié aux utilisateurs en charge de l’exécution de l’interface proposée. Nous avons particulièrement présenté son architecture composée de quatre couches pour i) le déploiement et la propagation des données, ii) permettre aux utilisateurs de contrôler des les données collectées sur leurs dispositifs, iii) l’exécution des applications de collecte et iv) limiter la consommation énergétique liée à l’exécution d’une application de collecte. Dans le chapitre suivant, nous allons présenter l’environnement serveur de notre architecture. 894 C O L L E C T E R É PA RT I E D E D O N N É E S Sommaire 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 4.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 4.1 introduction L’objectif des travaux de cette thèse est de proposer une solution générique, facilitant le développement et le déploiement de campagnes de collecte de données à travers des dispositifs mobiles. Dans le chapitre précédent, nous avons présenté l’environnement mobile de APISENSE®, la plate-forme résultante des travaux de cette thèse. Nous avons proposé un modèle de programmation facilitant le développement d’applications mobiles dédiées à la collecte de données et un intergiciel déployé au préalable sur les dispositifs mobiles, dédié à leurs exécutions. 91Dans ce chapitre, nous présentons notre deuxième contribution concernant l’architecture et l’implémentation de l’environnement serveur de APISENSE®, responsable du déploiement des campagnes de collecte, de la persistance des données ainsi que leurs analyses. Ce chapitre adresse particulièrement deux défis introduit en début de manuscrit, qui sont la généralité de la plate-forme, concernant la capacité de la plate-forme à supporter une grande diversité de campagnes de collecte ainsi que son passage à l’échelle. structure du chapitre La suite du chapitre est organisée comme suit : en section 4.2, nous présentons une vue d’ensemble de l’architecture proposée, et discutons des bénéfices de cette architecture par rapport aux solutions de l’état de l’art. Dans les sections 4.3 et 4.4, nous présentons en détail l’architecture des différentes entités logicielles de APISENSE®, ainsi que les méthodes de conceptions et de modélisations utilisées. Dans le chapitre 4.5, nous proposons une optimisation améliorant le passage à l’échelle du système avant de conclure en section 4.6. 4.2 infrastructure répartie de traitement des données Avant de présenter en détail l’architecture proposée dans ce chapitre, nous présentons ici une vue globale de la plate-forme APISENSE®. La figure 17 donne un aperçu simpli- fié des différentes entités logicielles qui la composent, et leurs principales interactions. L’architecture est principalement composée de trois parties distinctes : un ensemble de nœuds de collecte (DataGathering Node), un serveur central (Central Server) et un ensemble de nœuds mobiles avec une application dédiée installée au préalable par les participants. Nous avons déjà présenté les noeuds mobiles dans le chapitre précédent (cf. 3.4, page 68 ). APISENSE® adopte une architecture décentralisée, où le serveur central est assumé comme le tiers de confiance de la plate-forme. Plus particulièrement, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte, vers les nœuds mobiles du système. Afin de fournir un déploiement adapté (par ex. zone géographique, type de dispositif mobile), le serveur central a besoin de maintenir à jour un ensemble d’informations, sur les dispositifs mobiles disponibles pour exécuter des tâches de collecte. Dans ce contexte, nous supposons que le serveur central est géré par un acteur de confiance, qui peut être une organisation publique, ou une structure de recherche. 92Figure 17 – Vue d’ensemble d’APISENSE® La gestion des campagnes de collecte est assurée par les nœuds de collecte, qui peuvent être dédiés à un ou plusieurs utilisateurs. Typiquement, la gestion d’une campagne de collecte comporte quatre phases : i) définir une tâche de collecte, ii) recruter un sous-ensemble de dispositifs mobiles, iii) assurer la persistances des données collectées (c.-à-d. dans une base de données) lors de l’exécution de la tâche iv), exploiter les données. Pour réaliser ces différentes étapes, un nœud de collecte propose un environnement fournissant un ensemble de services qui peuvent être entièrement configurés par les utilisateurs. La configuration consiste en la sélection de modules implémentant la logique dédiée à la réalisation d’une étape d’une campagne de collecte. Dans ce cadre, les modules proposés peuvent implémenter différentes stratégies selon la nature de la campagne. Par exemple, la phase de collecte peut inclure un modèle particulier d’anonymisation des données pour assurer la confidentialité des participants. Ce choix de conception, séparant les préoccupations du déploiement ainsi que la collecte et l’analyse des données, nous permet de rompre avec le syndrome de l’enfermement propriétaire. Premièrement, en offrant la possibilité aux utilisateurs de déployer leurs nœuds de collecte sur l’infrastructure de leur choix, leur permettant 93ainsi de garder un contrôle total sur les données collectées durant leurs campagnes. Les nœuds de collecte peuvent ainsi être déployés vers une infrastructure publique ou privée, en fonction des préoccupations éthiques ou légales en rapport avec le stockage des données. De plus, les nœuds de collecte des utilisateurs sont complètement isolés les uns des autres, améliorant la sécurité et la disponibilité de leurs environnements, permettant d’effectuer des traitements lourds sur les données collectées sans affecter les autres instances. Et finalement, en gardant une entité centrale (c.-à-d. le serveur central), cela permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter leurs tâches de collecte, s’affranchissant ainsi d’une longue période de recrutement. Après avoir présenté une vue globale de la plate-forme APISENSE®, nous présentons dans la suite de ce chapitre l’architecture et les services fournis par le serveur central (cf. section 4.3), ainsi que les nœuds de collecte (cf. section 4.4). 4.3 architecture du serveur central Comme nous l’avons présenté dans la section précédente, APISENSE® est une plate-forme répartie dédiée aux déploiements et à l’exécution de campagnes de collectes de données. Afin de fournir une plate-forme modulaire, facilement extensible et configurable, APISENSE® est une plate-forme orientée service, utilisant un modèle à composants logiciels pour modéliser les différentes applications serveur qui la composent. Plus spécifiquement, APISENSE® est basée sur le modèle SCA [46], un standard initié par le consortium OASIS, dédié à la modélisation d’architectures tout en étant indépendant des langages de programmation, des protocoles de communication, des langages de description d’interface et des propriétés non fonctionnelles. La figure 18 illustre le modèle SCA du serveur central. Dans SCA, les bases des constructions sont les composants logiciels, qui peuvent offrir des services, ou solliciter d’autres composants via des références. Les services ainsi que les références peuvent être connectés à l’aide de fils (wire en anglais). SCA spécifie un modèle à composants hiérarchiques, laissant la possibilité d’implémenter un composant par un langage de programmation, ou par un ensemble de sous composants. Dans le dernier cas, ces composants sont appelés composite. Afin de supporter l’interaction entre des services distants, SCA spécifie la notion de communication distante (binding), permettant de décrire 94le protocole que le client devra utiliser pour invoquer un service. Dans l’architecture SCA proposée, les composants ParticipantFrontend, GatheringNodeFrontend ScientistFrontend et représentent les points d’entrés pour les différents acteurs qui interagissent avec le serveur central. Ces composants exposent leurs services en tant que ressource REST, accessibles via le protocole HTTP. Plus particulièrement, ces composants fournissent quatre types services nécessaires au fonctionnement du système, dédié à : L’enregistrement des participants : ce service (participant registration) est accessible par les dispositifs mobiles, permettant l’enregistrement d’un nouveau participant volontaire pour exécuter de nouvelles tâches de collecte. L’enregistrement des expériences de collecte : ce service (deploy scripts) est accessible par les nœuds de collecte, et permet aux utilisateurs d’enregistrer de nouvelles expériences de collecte. Le déploiement des expériences de collecte : ces services (list experiment, download script, recruit participants) assurent la propagation des expériences vers les terminaux mobiles. La gestion des nœuds de collecte : ces services (user registration, deploy data gathering node, downloads modules) représentent les points d’entré dans le système pour les utilisateurs voulant créer et configurer un nœud de collecte. Nous présentons dans la suite de cette section les services fournis par ces composants. 4.3.1 L’enregistrement des participants L’enregistrement des participants permet d’informer le serveur central de la présence et de la disponibilité des participants pour exécuter des tâches de collecte. Ce service, fourni par le composant DeploymentService, est invoqué par les nœuds mobiles lors de leurs installations sur les terminaux mobiles des participants. L’inscription inclut des informations statiques sur la configuration matérielle des terminaux des participants, ainsi que des informations confidentielles. Les informations matérielles comprennent le type du terminal (par ex. smartphone, tablette), le système d’exploitation utilisé (par ex. Android, iOS) ainsi que l’ensemble des capteurs embarqués dans le terminal. Les informations confidentielles comprennent par défaut le nom, le prénom et une adresse électronique valide. Cependant, le participant a la possibilité de raffiner ces informations, volontairement, en indiquant des lieux géographiques — à gros grain (par ex. pays, région ou ville) — où il évolue, son statut ainsi que son âge. Ces informations sont ensuite stockées dans une base de données, et serviront 95Figure 18 – Architecture SCA du serveur central lors de la phase de déploiement. Pour des raisons de confidentialité, elles pourront être accessibles uniquement par le serveur central, c’est-à-dire qu’elles ne seront pas accessibles par les nœuds de collecte du système. 4.3.2 L’enregistrement des expériences de collecte Accessible par les nœuds de collecte du système, ce service, fourni par le composant Recruitment, permet l’enregistrement d’une expérience de collecte auprès du serveur central. Cette enregistrement comprend deux catégories d’éléments. La première correspond a un ensemble de fichiers JavaScript définissant la tâche de collecte (cf. section 3.3, page 59 ). La deuxième catégorie définit les propriétés de l’expérience et également ses exigences en matière de déploiement. Ces propriétés sont définies par un ensemble de clés/valeurs utilisant le formalisme JSON. Comme le montre le tableau 10, trois catégories de propriétés sont actuellement supportées : global : définit principalement des informations générales sur l’expérience de collecte. Ces propriétés ne sont pas interprétées par le serveur central, mais 96propriété nom description global name Nom de l’expérience description Description du but de la collecte de données version Version de l’expérience de collecte privacy Description du modèle de protection de la vie privée incentive Description du modèle de récompense nodeurl URL du nœud de collecte de collecte recruitment sensors Liste des capteurs utilisées par la tâche de collecte max_numbers Nombre maximum de participants admis dans l’expé- rience de collecte area Zone globale de collecte (par ex. pays, région, ville) platform Liste de plate-formes mobiles context area Liste de zone géographique. period Liste de période journalière Table 10 – Propriétés définissant une expérience de collecte permettent d’informer les participants sur les objectifs de l’expérience (description), le modèle de confidentialité (privacy) et de récompense (incentive). recruit : permet de définir les participants autorisés à participer à une expérience de collecte. Ces propriétés permettent de limiter le nombre de participants impliqué dans l’expérience (max_numbers), de sélectionner des participants évoluant dans un lieu géographique (area) — à gros grains (par ex. pays, région ou ville) —, disposant d’un terminal ayant les capteurs nécessaires pour l’exécution de la tâche de collecte (sensors) et disposant d’une plate-forme mobile spécifique (platform). context : permet de spécifier le contexte d’exécution de la tâche de collecte une fois propagée vers les terminaux mobiles. Dans ce cadre, les propriétés permettent de spécifier une liste de zones géographiques (area) — région circulaire définie par les coordonnées du centre et un rayon exprimé en mètres —, et une liste de périodes journalières (period) dans lesquelles l’expérience doit s’exécuter. Ces propriétés seront ensuite interprétées par les nœuds mobiles, qui seront responsables de déclencher ou de stopper l’exécution de la tâche de collecte (cf. section 3.4.2, page 72 ). 974.3.3 Déploiement des tâches de collecte Une fois l’expérience enregistrée, deux stratégies principales peuvent être considérées pour propager les tâches de collecte vers les nœuds mobiles des participants [16]. La première approche (push-based) consiste à déployer automatiquement l’expérience de collecte auprès des utilisateurs mobiles. Dans la deuxième (pull-based), le nœud mobile télécharge la tâche de collecte après une action volontaire du participant, ou en effectuant une requête périodiquement vers le serveur pour voir si une nouvelle expérience est disponible [62]. Dans ce cadre le serveur central supportent ces deux approches pour la propagation des tâches de collecte. Approche pull-based La première approche (pull-based) est supportée par les composants Pull, DeploymentService et PropertyMatcher. Dans un premier temps, les participants peuvent accéder au service proposé par le Pull, via leur dispositif mobile, pour récupérer une liste d’expériences mises à disposition par les utilisateurs. Dans ce cadre, le PropertyMatcher détermine les expériences accessibles pour le participant, en faisant la correspondance entre les propriétés de recrutement des expériences, et des informations partagées par le participant lors de son inscription. Des informations générales sont fournies pour chaque expérience accessible, permettant au participant de visualiser le but de l’expérience de collecte, du modèle de confidentialité et de récompense ainsi que les capteurs utilisés lors de son exécution. À partir de ces informations, le participant a alors la possibilité de s’enregistrer à une expérience. Lors de la souscription, un identifiant anonyme est alors généré. Cet identifiant est ensuite envoyé au nœud de collecte ayant initié l’expérience et à l’agent mobile, pour l’avertir d’un nouveau recrutement dans l’expérience. Dans ce cadre, l’identifiant anonyme servira pour toutes les communications entre les nœuds de collecte et les participants, comme lors de la propagation des données. Cela permet en effet aux participants de ne pas révéler leurs identités réelles lors des interactions avec les nœuds de collecte, assurant ainsi une première couche d’anonymisation. Une fois la souscription terminée, l’agent mobile peut alors télécharger la tâche de collecte associée et déclencher son exécution. Approche push-based La deuxième approche (push-based) est supportée par les composants Push, et également par le composant PropertyMatcher. Dans ce cadre, le Push fournit un service, 98accessible par les nœuds de collecte, pour pousser directement une tâche de collecte vers les agents mobiles des participants. Ce processus comprend deux étapes. La première consiste à envoyer un message vers les agents mobiles acceptant ce mode de déploiement, et correspondant aux propriétés de l’expérience. La deuxième étape est ensuite similaire à l’approche présentée ci-dessus, c’est-à-dire composée de la phase de souscription et de téléchargement de la tâche de collecte. Pour établir ce type de propagation, il est nécessaire de supporter des communications dans le sens serveur vers terminaux mobiles. Typiquement, ce type de communication peut être effectué en utilisant des services dédiés, proposés par les fournisseurs des OS mobiles tels que GCM (Google Cloud Messaging) pour Android ou APNs (Apple Push Notification service) pour iOS. Dans ce contexte, le composant PushService est en charge de l’interaction avec ces services pour envoyer des messages vers les terminaux mobiles selon l’OS mobile visé. Indépendamment de l’approche utilisée, le composant Push permet également aux nœuds de collecte de propager des messages aux utilisateurs mobiles s’étant inscrits à leurs expériences. Ces messages peuvent être propagés soit à un participant en particulier, ou alors à l’ensemble des participants ayant souscrits à l’expérience. Deux types de messages peuvent être transmis : update : Message indiquant la disponibilité d’une nouvelle mise à jour de l’expérience. Dans ce cadre, ce message déclenchera le téléchargement de la nouvelle version de l’expérience par les nœuds mobiles. Cela permet de rapidement adapter le comportement de l’expérience une fois déployée. notification : Ces messages permettent aux utilisateurs de notifier l’état d’avancement de l’expérience en cours, en partageant des statistiques globales des données collectées avec tous les participants. 4.3.4 Gestion des nœuds de collecte Les derniers services présentés sont responsables de la création et de la configuration des nœuds de collecte. Un utilisateur voulant évoluer dans APISENSE®, peut se connecter au service géré par le composant DataGatheringRepository via une interface web, et déclencher le téléchargement de leur propre nœud de collecte. Celui-ci pourra ensuite être déployé vers une infrastructure publique ou privée, selon les exigences des utilisateurs. 99Un nœud de collecte peut être téléchargé suivant deux formats : 1. En tant qu’image virtuelle pré-configurée, permettant son déploiement au-dessus d’un environnement virtualisé. Dans ce cadre, l’image virtuelle comprend toute la pile logicielle nécessaire au bon fonctionnement du nœud de collecte. Plus particulièrement, elle est composée d’une distribution Linux, d’une machine virtuelle Java (JVM), d’une base de données MongoDb 1 pour le stockage des données, et FraSCAti responsable de l’exécution des composants SCA du nœud de collecte. 2. En tant qu’archive web (.war), permettant son déploiement directement au-dessus d’un serveur d’application (c.-à-d. Apache Tomcat). Le service fourni par le ComponentRepository propose un ensemble de composants modulaires, dédiés à la configuration d’un nœud de collecte. Les utilisateurs peuvent accéder à ce service via leur nœud de collecte nouvellement déployé, pour télécharger et assembler des composants dans leur nœud de collecte en fonction de la nature des expériences qu’ils veulent mener. Nous présentons ce point plus en détail dans la section suivante. 4.4 architecture des noeuds de collecte Dans la section précédente, nous avons présenté l’architecture et les services fournis par le serveur central de la plate-forme APISENSE®. Dans ce chapitre, nous présentons l’architecture des nœuds de collecte, et plus particulièrement comment nous tirons profit du modèle SCA pour fournir des nœuds de collecte facilement configurables. Les nœuds de collecte sont les entités logicielles de notre système responsables de la gestion des campagnes de collecte des utilisateurs. Nous rappelons qu’une campagne est essentiellement composée de quatre étapes qui consiste : 1. à définir une tâche de collecte via une interface de programmation dédiée, 2. à publier la tâche de collecte auprès du serveur central pour le recrutement des participants, 3. à assurer la persistance des données collectées par les dispositifs, 4. et finalement à analyser et exploiter les données collectées Par ailleurs, une expérience peut également comporter un modèle de protection de la vie privée des participants, ainsi qu’un modèle de récompense. 1. https://www.mongodb.org 100Pour faire face à la diversité des expériences qui peuvent être menées, les nœuds de collecte peuvent être entièrement configurés selon la nature d’une expérience. Cette configuration consiste essentiellement à assembler un ensemble de composants SCA, où chaque composant est responsable de la logique fonctionnelle d’une étape d’une expérience. Dans ce contexte, plusieurs composants peuvent être dédiés à une même étape, représentant la partie variable d’une configuration. Pour guider les utilisateurs dans ce processus d’assemblage, nous avons adopté une approche basée sur l’ingénierie des Lignes de Produits Logiciels (LDPs) [12, 52] (en anglais SPL pour Software Product Line). Typiquement, l’idée est i) de définir un Modèle de Caractéristiques (MC) [32](en anglais FM pour Feature Model) qui capture les caractéristiques communes et les points de variabilité d’une configuration d’une expérience, ii) d’implémenter le MC comme un assemblage de composants SCA et de proposer le MC aux utilisateurs pour leurs permettre de sélectionner les composants selon la nature des expériences qu’ils veulent mener. Dans la suite de cette section, nous présentons le MC dédié à la configuration des expériences de collecte en sous-section 4.4.1, un exemple d’architecture SCA généré et leurs interactions permettant la réalisation d’une campagne de collecte, et nous finissons par présenter le mécanisme d’extension permettant d’adresser les exigences non anticipées. 4.4.1 Modèle de caractèristiques d’une campagne de collecte La notion de Modèle de Caractéristiques (MC), introduite par Kang et al. [32], est une technique de modélisation permettant la description d’un ensemble d’artéfacts réutilisables, qui peuvent être utilisés pour créer une famille de logiciels qui possède des caractéristiques communes, mais exhibant également des différences. Le MC représente ainsi l’ensemble des choix proposés à un utilisateur pour lui permettre de configurer un logiciel spécifique à ses besoins. Typiquement, un MC est spécifié sous forme d’arbre, dont les nœuds représentent les caractéristiques d’un logiciel et les arcs spécifient des liens de composition entre les caractéristiques. Trois catégories de caractéristique peuvent être définies : les caractéristiques obligatoires, les caractéristiques optionnelles et les caractéristiques alternatives. Additionnellement, des règles de composition peuvent être définies, établissant une 101relation entre les caractéristiques. Ces règles peuvent prendre deux formes i) une caractéristique qui nécessite la sélection d’une autre caractéristique (définissant une interdépendance entre les caractéristiques), et ii) la sélection d’une caractéristique peut exclure la sélection d’une autre. Dans notre contexte d’utilisation, nous utilisons cette technique pour modéliser les différents choix proposés aux utilisateurs pour leur permettre de configurer les services d’une campagne de collecte selon les spécificités de celle-ci. La figure 19 illustre le MC dédié à la configuration d’une campagne de collecte. Typiquement, le MC identifie principalement cinq points de variabilités pour i) configurer l’environnement de développement des tâches de collecte (SensingTask Description), ii) choisir un modèle de recrutement des utilisateurs (Recruitment), iii) choisir une série de traitements sur les données collectées avant leurs insertions dans la base de données (OnlineProcessing), iv) spécifier l’indexation des données dans la base de données (Collector), v) exposer des services au-dessus des données collectées (Service). Nous décrivons à présent brièvement ces différents points de variabilités et les caractéristiques actuellement supportées. Figure 19 – Modèle de caractéristiques d’une campagne de collecte 102SensingTask Description Ce premier point de variabilité permet aux utilisateurs de sélectionner l’interface web dédiée aux développements des tâches de collecte vue dans le chapitre précédent (cf. section 3.3). La première interface, définie par la caractéristique CodeEditor, propose un éditeur de code en ligne — avec coloration syntaxique, complétion de code, etc. — permettant le développement des tâches de collecte directement en JavaScript. La deuxième interface, définie par la caractéristique Form, quant à elle, fournit une interface web permettant le développement des tâches à partir d’un formulaire. Le formulaire permet principalement de spécifier le type de données à collecter (par ex. position, accéléromètre, périphérique Bluetooth) avec la fréquence de collecte pour chaque donnée (par ex. toutes les cinq minutes). Après validation du formulaire, un fichier JavaScript est généré à partir des choix effectués par l’utilisateur. Le formulaire permet de rendre accessible le développement des tâches pour des utilisateurs n’ayant aucune expertise en programmation. Cependant, le formulaire limite l’expressivité des tâches qui peuvent être développées, en définissant uniquement des tâches de collecte périodique de données. Nous prévoyons dans des travaux futurs de proposer des métaphores visuelles pour développer des tâches de collecte plus complexes, tout en permettant leur développement par des utilisateurs n’ayant aucune expertise en développement. Certains travaux ont déjà été proposés dans ce sens tels que Scratch [48, 58] ou Alice [15] ou plus récemment App Inventor 2 . Le principe de ces approches consiste à fournir un environnement intuitif, dans lequel on associe des composants visuellement pour définir le comportement d’une application. Recruitment Ce deuxième point de variabilité permet de sélectionner le modèle utilisé pour recruter un sous-ensemble de participants exécutant la tâche de collecte. Dans ce contexte, le recrutement consiste essentiellement à interagir avec les services du serveur central pour déployer la tâche de collecte et assurer sa mise à jour, définir un sous-ensemble de participants autorisés à l’exécuter et son contexte d’exécution. Les deux caractéristiques associées à ce point de variabilité (Individuel et Collaborative) permettent de faire face aux différentes échelles de collecte (cf. section 2.1.2) que sont la collecte personnelle et la collecte communautaire. La caractéristique Individuel propose un modèle simple de recrutement des participants dédié à la collecte personnelle de données, qui a généralement pour objectif de suivre l’activité d’un individu à travers le temps. Nous présentons plus en détail en 2. http://appinventor.mit.edu 103sous-section 4.4.4 ce modèle et les différentes interactions entre les nœuds mobiles, le serveur central et les nœuds de collecte nécessaires. La caractéristique Collaborative propose un modèle principalement dédié à la collecte communautaire de données, qui a généralement pour objectif de surveiller des phénomènes liés à l’environnement des participants (par ex. surveiller la qualité du signal réseau dans la ville de Paris). Nous décrirons plus en détail ce modèle dans la section 4.5. Online Processing Ce point de variabilité permet de définir un ensemble de traitements à effectuer sur les données collectées avant leurs insertions dans une base de données. Les traitements peuvent consister à calculer des statistiques globales sur les données collectées (caracté- ristique Statistique), calculer un modèle d’incitation pour récompenser les participants (point de variabilité Incentive), ou encore effectuer des traitements modifiant les données collectées pour assurer leurs confidentialités (point de variabilité Privacy). Incentive Ce point de variabilité définit le modèle de récompense de l’expérience de collecte. Typiquement, l’incitation peut prendre une grande variété de formes. Par exemple, ré- compenser les participants financièrement [41] pour les données partagées, ou transférer des mécanismes de jeux dans le contexte de la collection de données [69]. Généralement, un modèle de récompense a pour objectif d’augmenter la participation des utilisateurs, et de les motiver à partager des données plus pertinentes pour l’expérience. Actuellement, nous supportons un modèle de récompense [24] basé sur la quantité et la qualité des données partagée par des participants. Ce modèle est également utilisé dans des applications mobiles populaires telles que Waze 3 ou encore Foursquare 4 . Le modèle est basé sur le concept de récompense [69] qui peut prendre deux formes différentes. La première consiste à émuler une compétition, en effectuant un classement entre les participants. Dans ce cadre, le modèle peut être configuré par les utilisateurs, en attribuant des points selon le type de données partagées. Le deuxième permet d’attribuer des badges/trophées, en fonction du nombre de points remportés par les participants. 3. https://www.waze.com 4. https://foursquare.com 104Dans l’application mobile présentée dans le chapitre précédant, plusieurs mécanismes permettent aux participants de contrôler les données qui sont collectées par leur dispositif (cf. chapitre 3 sous-section 3.4.2, page 72 ). Ce mécanisme peut être utilisé par exemple par les participants pour empêcher l’application d’activer le GPS qui consomme beaucoup d’énergie. Dans ce cas, les utilisateurs peuvent contrebalancer l’énergie utilisée par les capteurs, et la sensibilité des données — d’un point de vue vie privée —, en attribuant plus de points selon les données collectées par les participants. Par exemple, le capteur GPS est bien connu pour fournir une grande précision pour déterminer la position d’un utilisateur, mais consomme beaucoup plus d’énergie que la géolocalisation GSM, moins précise. Dans ce contexte, pour inciter les participants à partager leurs capteurs GPS, plus de points peuvent être attribués aux données collectées par le GPS. Privacy Additionnellement, un modèle de confidentialité peut être intégré dans l’expérience de collecte. Dans ce cadre, les composants implémentant ces modèles sont responsables de l’assainissement des données reportées par les participants, avant leurs insertions dans la base de données. Actuellement nous supportons un modèle classique de perturbation [2], consistant à modifier les coordonnées spatiales et temporelles en y ajoutant une perturbation aléatoire. La perturbation est introduite par un bruit gaussien à l’intérieur d’une sphère de rayon r centré sur les coordonnées d’origine. Nous envisageons d’intégrer plusieurs modèles issus de l’état de l’art [11] tels que des modèles de dissimulation spatiale [64, 30, 62]. Collector Ce point de variabilité est responsable de la persistance ainsi que de l’indexation des données collectées dans une base de données. Actuellement, la persistance des données est effectuée avec la technologie MongoDB, une base de données non-relationnelle orientée documents. Dans notre cas d’utilisation, le principal bénéfice de cette technologie est de ne pas imposer un schéma spécifique pour sauvegarder les données. En effet, de nombreux systèmes [25, 22] utilisent des bases de données SQL qui nécessitent la définition de schéma statique pour structurer les données. Ce choix de conception limite alors la réutilisation du système nécessitant la sauvegarde de données ayant une structure non prévue dans le schéma défini au préalable. Dans ce cadre, MongoDB représente une technologie fournissant la flexibilité nécessaire pour faire face à l’hétérogénéité des données qui peuvent être collectées durant les expériences. 105Les données sont sérialisées sous la forme d’un tableau JSON. Dans ce cadre, l’utilisation du formalisme JSON fournit une grande flexibilité aux utilisateurs pour représenter les données, selon le type des capteurs impliqués dans la tâche de collecte. La structure des données est définie par les utilisateurs lors du développement de la tâche de collecte (cf. sous-section 3.3.3). Les métadonnées sont générées par l’application mobile, comportant l’identifiant unique de l’utilisateur — crée par le serveur central lors de l’enregistrement du participant dans l’expérience —, la version de la tâche de collecte ainsi que la date où les données ont été générées. Les utilisateurs ont également la possibilité de compléter ces méta-informations. Dans ce cadre, ces méta-informations peuvent être utilisées pour structurer les données dans la base de données, par exemple indexer les données par jour (caractéristique DateIndex), par utilisateur (caractéristique UserIndex) ou utiliser un index géographique (caractéristique GeoIndex) pour faciliter le traitement des données à caractère géographique. Service Le dernier point de variabilité permet de sélectionner des services responsables d’exposer les données après leurs sauvegardes dans la base de données. Actuellement, nous supportons des composants génériques qui permettent de fournir une interface web donnant un accès à la base de données (caractéristique Query), de visualiser des statistiques sur données collectées sous forme de graphe (caractéristique Chart), visualiser sous forme de carte (caractéristique Map) si l’indexation sélectionnée dans la partie précédente utilise un index géographique, ou alors d’exporter les données dans divers formats (point de variabilité Export) (c.-à-d. CSV, JSON, XML). Dans cette section, nous avons présenté notre approche pour permettre de faire à face à la diversité des campagnes de collecte qui peuvent être menées par les utilisateurs. Pour prendre en compte cette diversité, nous avons proposé de modéliser l’environnement responsable de la gestion d’une campagne comme une famille de produits à l’aide de Modèle de Caractéristique (MC). Le MC présenté permet de définir les points communs et également les différences relatives aux campagnes de collecte. Ces différences peuvent consister à utiliser différents modèles de confidentialité, de recrutement ou d’incitation selon la nature de l’expérience, choisir différentes façons pour développer les tâches de collecte selon le niveau de programmation des utilisateurs ou alors structurer et exposer les données collectées durant la campagne. Ainsi, le MC définit l’ensemble des choix présentés aux utilisateurs pour leur permettre de configurer leurs campagnes de collecte en fonction de leurs exigences. Dans la section 106suivante, nous décrivons comment un nœud de collecte génère un environnement assurant la gestion d’une campagne de collecte à partir des choix effectués par les utilisateurs et comment les utilisateurs peuvent étendre les nœuds de collecte pour faire face à des exigences non anticipées. 4.4.2 Création d’une nouvelle campagne Toutes les caractéristiques initialement introduites dans la section précédente sont associées à un composites SCA. La création d’une nouvelle campagne consiste donc à intégrer et à assembler dans l’architecture initiale du nœud de collecte (cf. figure 20) un ensemble de composite SCA. Dans ce cadre, le MC permet de spécifier l’ensemble des assemblages valides pour générer une nouvelle instance de campagne de collecte. Une fois déployé, un nœud de collecte (cf. figure 20) est composé de quatre composants génériques, dédiés à la création d’une nouvelle campagne : ExperimentManager, WebManager, ModuleManager et le ReconfigurationManager. Figure 20 – Architecture initiale d’un nœud de collecte Le point d’entrée de cette architecture est le composant ExperimentManager. Ce composant est responsable du déclenchement de la génération d’une nouvelle campagne. Pour lancer cette génération, ce dernier composant a besoin de trois informations : i) le nom de la campagne de collecte, ii) une description de l’objectif de la collecte, iii) et l’ensemble des caractéristiques sélectionnées dans le MC par les utilisateurs. La 107création d’une nouvelle campagne peut également s’effectuer à partir d’une interface web fournie par le composant WebManager. La figure 21 montre une vision simplifiée de la génération d’une nouvelle campagne. Figure 21 – Processus de génération d’une architecture SCA Une fois la sélection validée, en fonction des différentes contraintes exprimées dans le MC, le composant ExperimentManager procède alors aux téléchargements des différents composites associés aux caractéristiques sélectionnées, auprès du serveur central via le composant ModuleLibrary. Une fois les composites téléchargés, le composant ExperimentManager exploite alors les capacités d’introspection du moteur d’exécution SCA via le composant ReconfigurationManager pour instancier les composites téléchargés dans l’architecture du nœud de collecte. Par exemple, la figure 22 illustre une nouvelle instance générée à partir de la sélection des caractéristiques suivantes : CodeEditor, Individuel, Badge, Pertubation, userIndex, Query, Export-KML. Cette nouvelle instance expose ainsi de nouveaux services permettant 108Figure 22 – Architecture SCA d’une campagne de collecte 109d’éditer une tâche de collecte associée à la campagne (composant SensingTask :CodeEditor), de déployer cette tâche auprès du serveur central afin de recruter un ensemble de participants (composant Recruitement :Individuel), d’anonymiser et de sauvegarder les données collectées par les participants (composant Privacy :Perturbation et Collector :UserIndex), configurer le mécanisme de récompense (composant Incentive :Ranking) et finalement exploiter les données collecter (composant Service :Query et Service :Export :KML). Nous présentons de manière plus détaillée dans la section suivante comment ces composants interagissent entre eux lors d’une campagne de collecte configurée avec un modèle de recrutement Individuel. L’exécution d’une campagne communautaire sera décrite en section 4.5. 4.4.3 Intéraction entre les composants Après avoir présenté les différents composants logiciels formant le serveur central et les nœuds de collecte de APISENSE®, nous présentons dans cette sous-section leurs interactions. La figure 23 montre un diagramme de séquence illustrant les différents messages échangés entre les acteurs du système (c.-à-d. utilisateurs et participants) et les composants de APISENSE®, lors de l’exécution d’une campagne de collecte personnelle. Comme le montre le diagramme, la réalisation d’une campagne de collecte comporte trois phases : la création de la campagne de collecte (phase 1), le déploiement d’une tâche de collecte vers les dispositifs mobiles des participants (phase 2) et la propagation des données vers un nœud de collecte. (phase 3). phase 1 - création d’une campagne de collecte La création d’une nouvelle campagne de collecte est initiée par un utilisateur à partir de son nœud de collecte. La création de la campagne consiste à sélectionner un ensemble de caractéristiques, appartenant au MC, définissant la configuration de la campagne de collecte. À partir d’une configuration valide, le composant ExperimentManager télécharge les composants SCA associés aux caractéristiques auprès du serveur central et génère une nouvelle instance de la campagne (cf. figure 22). La nouvelle instance est un composite SCA, constitué d’un ensemble de composants qui exposent automatiquement de nouveaux services permettant le développement de la tâche de collecte (composant SensingTask), de la publier (composant Recruitment), de reporter les données collectées par les dispositifs mobiles (composant DataHandler) et de récupérer les données collectées (composant Query). 110Figure 23 – Interaction des composants APISENSE® 111phase 2 - déploiement de la tâche de collecte Une fois les services de la nouvelle campagne de collecte exposés, les utilisateurs peuvent alors développer la tâche de collecte associée à la campagne de collecte via le composant SensingTask, configurer les propriétés de déploiement de la tâche de collecte (cf. section 4.3.2) et la publier auprès du serveur central via le composant Deployment. Une fois publiée, le composant Recruitment du serveur central analyse les propriétés de la tâche de collecte et notifie tous les participants, correspondant à ces propriétés, de la disponibilité d’une nouvelle tâche de collecte est disponible. Les participants volontaires peuvent alors s’y inscrire. Dans ce cas, le dispositif mobile télécharge la tâche de collecte et l’identifiant anonyme généré lors de l’inscription qui est également partagé avec le composant ExperimentManager du nœud de collecte. Une fois téléchargée, la tâche de collecte est alors exécutée sur le dispositif mobile. phase 3 - propagation des données La dernière phase consiste à reporter les données collectées durant l’exécution de la tâche de collecte. Les données sont directement reportées auprès du composant DataHandler du nœud de collecte ayant initié la tâche de collecte. Lors de la propagation des données, l’identifiant anonyme est également envoyé, permettant au nœud de collecte de vérifier si les données proviennent bien d’un utilisateur inscrit à l’expérience. Si l’identifiant est valide, le composant DataHandler fait appel au composant Privacy qui est responsable de l’assainissement des données, avant leur sauvegarde et leur indexation dans la base de données via le composant Collector. Les utilisateurs peuvent alors accéder aux données sauvegardées, exporter les données collectées, et également retourner à la phase 2 afin de modifier le comportement de la tâche de collecte en fonction des résultats observés. Nous venons de décrire l’ensemble des interactions des composants APISENSE® permettant la réalisation d’une campagne de collecte de données. La section suivante présente le mécanisme d’extension de APISENSE® permettant le développement et l’intégration de nouveau composant dans la plate-forme. 4.4.4 Extension des nœuds de collecte En définissant un nœud de collecte comme une application SCA, nous bénéficions aussi de sa modularité pour facilement étendre la plate-forme. Dans cette sous-section, nous présentons comment de nouveaux services peuvent être ajoutés à un nœud de 112collecte. L’ajout d’un nouveau service est effectué à partir d’une archive ZIP, que nous appellerons une contribution. Comme le montre l’exemple illustré par la figure 24, une contribution contient la description d’une caractéristique, associée à un composite SCA, ainsi que l’ensemble des artéfacts implémentant le composite (c.-à-d. code compilé, scripts). La contribution présentée vise donc à ajouter un nouveau service responsable d’exporter les données collectées sous le format KML 5 , un format d’encodage utilisant le formalisme XML destiné à la gestion de l’affichage de données géospatiales dans les systèmes d’information géographique. Dans ce cadre, le premier élément vise à définir la contribution comme une caracté- ristique s’inscrivant dans le MC général présenté en sous-section 4.4.1. La description de la caractéristique définit donc le nœud parent (c.-à-d. caractéristique Export dans l’exemple), identifiant un nouveau point de variabilité, les caractéristiques requises, et le composite SCA associé. Dans cet exemple, le composite définit un nouveau service (c.-à-d. export service), exposé comme une ressource REST. Afin de récupérer les données collectées, le composant déclare une référence vers un composant fournissant un service de requête vers la base de données. Et finalement, le composant, déclare son implémentation comme étant une implémentation en Java. Les nœuds de collecte et le serveur central fournissent un service dédié aux déploiements de nouvelles contributions. Dans ce cadre, un utilisateur peut déployer une contribution directement dans son nœud de collecte, ou directement sur le serveur central pour la partager avec les autres utilisateurs du système. 4.5 campagne de collecte communautaire Dans la section précédente, nous avons présenté les principaux composants des nœuds de collecte et plus particulièrement comment ces composants peuvent être assemblés pour créer des services dédiés à une campagne de collecte spécifique. Nous avons également présenté le premier modèle de recrutement Individuel, où le recrutement est basé uniquement sur les propriétés des participants. Dans cette section, nous décrivons le modèle de recrutement Communautaire. Ce type de campagne, également appelé public sensing dans la littérature [33], consiste à collecter continuellement des données relatives à l’environnement des participants (par ex. bruit ambiant, qualité réseaux, pollution de l’air) dans une zone géographique [47, 63, 50]. 5. https://developers.google.com/kml/documentation 113Figure 24 – Exemple d’extension : Export des données au format KML 114Typiquement, une approche couramment utilisée dans ce type de campagne consiste à impliquer un maximum de dispositifs mobiles dans la collecte de données. Cependant, ces dispositifs collectent périodiquement (c.-à-d. toutes les x secondes) ces données environnementales sans prendre en considération si un autre nœud mobile placé à proximité collecte les mêmes données [27]. Cette approche naïve peut s’avérer inef- ficace principalement pour deux raisons. La première est qu’elle peut impliquer la remontée d’une grande quantité de données similaires, en particulier en milieu urbain ou une forte concentration d’utilisateurs (c.-à-d. situés à proximité) peuvent collecter simultanément ces données identiques. Cela demande par conséquent beaucoup plus de ressources côté serveur pour stocker ces données et les analyser. La seconde est qu’elle implique également une grande perte énergétique des appareils mobiles qui collectent ces données similaires. Récemment, Sheng et al. [59] ont montré qu’effectuer une collaboration entre les dispositifs, en fonction d’un objectif de couverture de la zone à observer, pouvait radicalement diminuer l’énergie consommée par l’ensemble des dispositifs, et par conséquent diminuer également le volume de données transmises sur le serveur. Dans ce cas, les objectifs de couverture définissent uniquement la quantité de données nécessaire pour la campagne, permettant de faire un compromis entre la quantité des données collectées, et le coût énergétique liée à leurs acquisitions. Pour effectuer la collaboration, cette approche fais l’hypothèse que les trajets de chaque appareil mobile est connue à l’avance. À partir de ces trajets, l’algorithme proposé dans cette approche permet d’assimiler les tâches de collecte uniquement aux mobiles capables de couvrir les objectifs de couvertures définis au préalable . Cependant, faire l’hypothèse que la mobilité de chaque appareil mobile est connue à l’avance peut être difficilement appliqué en déploiement réel, dû à la difficulté de prédire les trajectoires des participants [60]. Dans ce contexte, nous présentons dans cette section un modèle de recrutement collaboratif, permettant de coordonner l’exécution des tâches de collecte sans avoir une connaissance au préalable de la mobilité des participants. Le modèle proposé a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. Dans notre architecture, ce modèle est assuré par le composant associé à la caractéristique Collaboration du MC présentée en sous-section 4.4.1. Pour assurer la coordination des tâches, le composant se base sur des propriétés de couverture géographique et temporelle décrites par les utilisateurs, leur permettant de définir seulement la quantité de données nécessaires pour leur 115campagne. Pour définir ces propriétés, ainsi que différentes exigences en relation avec leur campagne, nous proposons une interface de programmation complémentaire à celle présentée dans le chapitre précédent (cf. section 3.3). Dans la suite de cette section, nous présentons tout d’abord l’interface de programmation proposée suivie d’un exemple de campagne de collecte développée avec cette interface. Nous présentons par la suite les différents processus assurant l’exécution ainsi que la coordination des ces campagnes de collecte. 4.5.1 Extension du modèle de programmation Dans cette section, nous présentons l’interface de programmation dédié à la définition de campagne de collecte de données communautaire. La table 11 illustre les principales fonctions proposées par cette interface. Phase Méthode Description Collecte sense(callback : function()) Enregistrement d’une tâche de collecte Recrutement accept(function()) Définition des dispositifs autorisés à exécuter une tâche ranking(function(users)) Classement des dispositifs prioritaires pour l’exécution de la tâche Couverture geoCoverage(bound : Array, coverage : String) Définition des propriétés de couverture géographique timeCoverage(during : Number, every : Number) Définition des propriétés de couverture temporelle duplicate(n : Number) Nombre de dispositifs attribués à une tâche selon les propriétés de couverture. Table 11 – Interface de programmation dédiée à la définition des campagnes de collecte communautaires. Typiquement, la définition d’une campagne de collecte communautaire comprend trois phases : collecte, recrutement, couverture. collecte : La première phase consiste à enregistrer la tâche de collecte qui sera distribuée auprès des nœuds mobiles. La tâche de collecte décrit les données qui doivent être collectées et reportées par les nœuds mobiles (cf. section 3.3, page 59 ). L’enregistrement de celle-ci est effectué en insérant une fonction de rappel 116à la méthode sense. Cette tâche sera ensuite exécutée par les nœuds mobiles lorsqu’ils seront assignés à celle-ci. recrutement : La deuxième phase consiste à définir la stratégie de recrutement des nœuds mobiles. Cette phase permet de filtrer les nœuds mobiles, ou d’en privilégier certains en fonction de leur contexte lors de l’attribution de la tâche de collecte. Par exemple, cela permet de baser le recrutement sur certains attributs (par ex. type de connexion réseaux, vitesse de déplacement), ou de privilégier les nœuds mobiles ayant le niveau de batterie le plus élevé. Le filtrage des nœuds mobiles consiste à enregistrer une fonction de rappel à la méthode accept. Cette fonction sera exécutée par les nœuds mobiles avant l’attribution de la tâche de collecte à un ou plusieurs nœuds. Cette fonction a pour objectif d’observer le contexte du nœud mobile, et définir si celui-ci est autorisé à exécuter la tâche. Dans ce cas, cette fonction doit retourner une liste de propriétés (par ex. niveau de batterie, vitesse de déplacement, qualité du signal réseau), dans le cas contraire, elle doit retourner une valeur nulle. La méthode ranking permet de privilégier certains nœuds mobiles pour exécuter une tâche de collecte, basée sur les propriétés retournées par la méthode accept. couverture : La troisième phase permet de définir les objectifs de couverture temporelle et géographique de la campagne de collecte. Cela permet par exemple de faire un compromis entre le coût énergétique utilisé par l’ensemble de nœuds mobiles, et la quantité de données reportées pendant la campagne. L’objectif de couverture temporelle peut être défini par la méthode timeCoverage, qui prend deux paramètres. Ces deux paramètres permettent de spécifier pendant combien de temps la tâche de collecte doit être exécutée et à quelle fréquence (par ex. exécuter la tâche pendant 30 minutes toutes les heures). L’objectif de couverture géographique peut être défini par la méthode geoCoverage, qui prend également deux paramètres. Ces paramètres permettent de spécifier la zone géographique globale de la campagne et à quelle granularité la tâche de collecte doit être distribuée (par ex. exécuter la tâche dans la ville de Paris tous les 500 mètres). La méthode duplicate permet de définir le nombre de dispositifs attribués à la tâche de collecte en fonction des propriétés de couvertures. Exemple d’application Afin de mieux illustrer le modèle de programmation proposé, nous présentons ici un exemple de campagne de collecte de données. Nous utiliserons également cet exemple comme un fil conducteur tout au long de cette section. Dans cette campagne, décrites par le listing 4.1, nous voulons mettre en place une collecte de 117données permettant d’élaborer une cartographie représentant la qualité des réseaux GSM en fonction des opérateurs des réseaux mobiles dans la ville de Paris. La première phase consiste à enregistrer la tâche de collecte de cette campagne (ligne 2-9). La tâche de collecte consiste à exécuter 10 Ping (Packet INternet Groper) réseaux à une machine distante particulière lorsque le participant a changé de position (ligne 3), et à collecté la latence moyenne des requêtes effectuées (ligne 7), la position de l’utilisateur (ligne 6) ainsi que son opérateur de réseau mobile (ligne 5). La deuxième phase consiste à définir la stratégie de recrutement des utilisateurs. Dans cette phase, nous voulons recruter uniquement les participants disposant d’une connexion de données mobiles (ligne 13). Pour les participants ayant ce type de connexion, nous renvoyons le niveau actuel de leur batterie pour pouvoir privilé- gier l’attribution de la tâches de collecte au participant disposant du niveau de batterie le plus élevé (ligne 18-20). Dans le cas contraire, le participant n’est pas autorisé à exécuter la tâche de collecte. Dans la troisième phase, nous définissons les propriétés de couverture pour optimiser l’énergie utilisée par l’ensemble des dispositifs mobile, et minimiser la quantité de données reportées sur le serveur. Pour cela, nous définissons que la tâche de collecte doit être exécutée au maximum par deux participants (ligne 25) répartis tous les cinqcents mètres dans la ville de Paris (ligne 23), et que la tâche doit être exécutée pendant trente minutes toutes les heures (ligne 24). 1 // phase 1 : définition de la tâche de collecte 2 sense(function() { 3 $location.onLocationChanged(function(event) { 4 $trace.add({ 5 operator : $telephony.operator(), 6 loc: [event.latitude, event.longitude], 7 latency : $network.ping(10,"http://...").average}); 8 })} 9 }) 10 11 // phase 2 : définition de la stratégie de recrutement 12 accept(function(){ 13 if (network.connectionType() != "WIFI"){ 14 15 return {battery : $battery.level()} 16 }else return undefined 17 }) 18 ranking(function(users){ 19 return users.sort("battery").select(); 20 }) 21 22 //phase 3 : définition des objectifs de couverture 11823 geoCoverage([[50.614291,3.13282],[50.604159,3.15239]],"500 m") 24 timeCoverage("30 min","1 H") 25 duplicate(2) Listing 4.1 – Tâche de collecte : Observer la qualité réseau Dans cette section, nous avons présenté le modèle de programmation proposé pour définir des campagnes de collecte supportant la collecte collaborative de données. Nous décrivons dans la suite de cette section comment ces campagnes sont exécutées par les nœuds de collecte. 4.5.2 Coordonner l’exécution des tâches de collecte Dans cette section, nous décrivons le modèle et les algorithmes mis en œuvre pour supporter la coordination des tâches de collecte en fonction des propriétés de couvertures géographique et temporelle. Le principal défi qui doit être adressé pour mettre en œuvre une coordination optimisée est de permettre au nœud de collecte d’avoir une vision aussi précise que possible de la réparation géographique des nœuds mobiles disponibles. Cependant, en utilisant une approche naïve qui consisterait à reporter continuellement la position des dispositifs mobiles vers le serveur ne seraient pas efficace pour plusieurs raisons. Premièrement, cela pourrait engendrer un trafic trop important de messages échangés entre les nœuds mobiles et le serveur, spécialement si de nombreux mobiles sont impliqués dans la campagne. Deuxièmement, cela impliquerait une trop grande consommation énergique des nœuds mobiles, dû à l’activation constante de capteur comme le GPS. Et finalement, classifier les nœuds mobiles en fonction de leur distance les uns par rapport aux autres, en utilisant des algorithmes de clustering [31] par example, entraînerait un surcharge du serveur, spécialement si cette classification doit être effectuée en permanence sur un grand volume de données. Pour adresser ce défi, nous avons adopté pour une approche de virtualisation de capteur, initialement proposée dans les réseaux de capteurs (WSNs). [10]. Typiquement, la virtualisation consiste à rajouter une couche logicielle abstraite, appelée couche virtuelle, composée d’un ensemble de capteurs virtuels, superposée à une couche physique. Un capteur virtuel est une entité logicielle autonome, responsable de gérer le flux de messages entre le serveur et un groupe de capteurs caractérisés par des propriétés communes (par ex. zone géographique, type de capteurs). Dans notre approche, l’idée 119principale est de diviser la zone globale de collecte en plusieurs zone géographiques en fonction des propriétés de couverture géographique de la campagne de collecte. Pour chaque zone, nous attribuons un capteur virtuel qui sera responsable de coordonner l’exécution des tâches entre les nœuds mobiles situé dans sa zone. Dans ce contexte, les nœuds mobiles ont uniquement besoin de partager leur position lorsqu’ils entrent ou sortent de la zone gérée par un capteur virtuel. Le composant responsable de l’exécution des campagnes de collecte communautaire et de la gestion des capteurs virtuels est le composite Recruitment :Collaborative (cf. figure 25). Ce composant est associé à la caractéristique Collaborative du point de variabilité Recruitement dans le modèle de caractéristiques présenté en sous-section 4.4.1. Figure 25 – Composant SCA responsable du recrutement collaboratif Ce composite est constitué des trois composants : i) ScriptEngine responsable de l’exécution du script JavaScript définissant la campagne de collecte, ii) VSManager responsable de la création et la gestion des capteurs virtuels et iii) Deployment responsable d’interagir avec le serveur central pour déployer les scripts auprès des nœuds mobiles. L’exécution d’une campagne communautaire comprend trois phases : i) la phase de génération des capteurs virtuels, ii) la phase de connexion des nœuds mobiles avec les capteurs virtuels, iii) et la phase de coordination de l’exécution des tâches de collecte. Nous décrivons à présent l’ensemble de ces étapes. Phase 1 : Génération des capteurs virtuels L’objectif ici est de générer un ensemble de capteurs virtuels responsables de coordonner l’exécution des tâches de collecte entre les nœuds mobiles. La génération de ces capteurs virtuels est assurée par le composant VSManager. Chaque capteur virtuel est caractérisé par une propriété définissant la zone géographique incluse dans la zone 120globale de collecte des données. La génération de ces capteurs est effectuée à partir de la méthode geoCoverage(bound,coverage) de l’interface de programmation, définissant la zone géographique globale de la collecte (paramètre bound), et la taille de la zone gérée par un capteur virtuel (paramètre coverage). À partir de ces paramètres, le composant VSManager génère et instancie un ensemble de capteurs virtuels, et les distribue pour couvrir l’intégralité de la zone globale de collecte (cf. figure 26). Typiquement, un capteur virtuel est un composite SCA disposant de deux services : composant RegistrationService et CoordinationService. Le premier service est dédié à l’enregistrement des nœuds mobiles. Ce service est exposé en tant que ressource REST, accessible à partir d’une URL générée à partir de la zone géographique dont il est responsable. Dans ce cas, les nœuds mobiles sont responsables de s’enregistrer auprès du capteur virtuel en fonction de leur position. Le deuxième service est responsable d’attribuer une tâche de collecte à un ou plusieurs nœuds mobiles qui se sont enregistrés au préalable. Nous détaillons ces différents points dans les section suivantes. Figure 26 – Distribution des capteurs virtuels Phase 2 : Connexion des appareils mobiles et des capteurs virtuels La deuxième phase consiste à établir une connexion entre les nœuds mobiles et les capteurs virtuels. Pour établir cette connexion, les nœuds mobiles ont tout d’abord besoin de télécharger la tâche de collecte auprès du serveur central. Le déploiement de la tâche de collecte vers le serveur central, assurée par le composant DeploymentService, 121suit le même procédé qui celui présenté en sous-section 4.4.4. Comme le montre la figure 26, la tâche de collecte comporte deux fichiers JavaScript : sense.js correspondant au code JavaScript responsable de la collecte des données (ligne 3-8 dans l’exemple décrit par le listing 4.1), et VSmonitoring.js. Dans un premier temps, seulement le fichier VSmonitoring.js est exécuté. Ce dernier script télécharge dans un premier temps l’ensemble des propriétés des capteurs virtuels générés (c.-à-d. zone géographique et l’URL du service d’enregistrement). À partir de ces propriétés, ce script observe continuellement la position du nœud mobile pour déterminer la présence du nœud mobile se situe dans une zone gérée par un capteur virtuel, et est responsable de l’enregistrement et du dé-enregistrement auprès du capteur virtuel associé. En ce qui concerne la surveillance de la position du nœud mobile, nous utilisons un algorithme couramment utilisé dans la littérature pour déterminer si un dispositif se trouve dans une zone spécifique, tout en minimisant le coût énergétique. Typiquement, l’idée principale derrière est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui, au contraire, consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance entre l’utilisateur et le capteur virtuel le plus proche de sa position actuelle. Phase 3 : Coordonner l’exécution des tâches de collecte Dans cette section, nous présentons l’algorithme utilisé par les capteurs virtuel pour coordonner l’exécution des tâches de collecte entre les nœuds mobiles enregistrés auprès d’un capteur virtuel. Le principal défi dans cette partie est de faire face à la connectivité imprévisible des nœuds mobiles. En effet, on ne peut pas partir du postula que tous les nœuds enregistrés sont réellement disponibles pour exécuter une tâche. De nombreux phénomènes peuvent empêcher les nœuds mobiles d’avertir un capteur virtuel qu’ils ne sont plus disponibles, comme la perte d’un signal réseau, un épuisement complet de la batterie ou tout simplement l’extinction du téléphone mobile par le participant. Pour prendre en considération ces phénomènes, l’idée principale de notre approche consiste à dupliquer le nombre de nœuds mobiles assignés à une tâche de collecte, et à intégrer une phase de demande d’exécution afin d’éviter d’avoir à assigner une tâche à un nœud qui n’a pas annulé son enregistrement au capteur virtuel. 122L’algorithme (cf. algorithme 1) est déclenché périodiquement en fonction des propriétés de couverture temporelle qui peuvent être définies par l’interface de programmation avec la méthode geoCoverage(duration,every). Algorithm 1 Algorithme de coordination des tâches de collecte Require: connectedDevices : List of connected devices activeDevices : List of activated devices t : Time threshold Task(tstart,tend) : Temporal properties of the sensing task duplicate : Maximum number of devices to assign the sensing task if (size(activeDevices) < duplicate) then candidates ⇐ connectedDevices − activeDevices if notEmpty(candidates) then availableCandidates ⇐  broadcastTaskRequestEvent(candidates) repeat receive(Device(id, n)) add(availableCandidates,Device(id, properties)) until timeout t is reached for (i = 0 → (size(activeDevices) − duplicate))) do device ⇐ ranking(availableCandidates) activeDevices ⇐ device + activeDevices availableCandidates ⇐ availableCandidates − device broadcastTaskExecutionRequest(device, tstart, tstop) end for end if end if L’algorithme vérifie tout d’abord si le nombre de dispositifs mobile déjà assigné à une tâche (size(activeDevice)) est inférieur à la propriété de duplication. Dans ce cas, nous définissons une liste candidate comme un ensemble de dispositifs connectés et n’exécutant pas actuellement une tâche de collecte. Pour tous les candidats, un message leur est envoyées avec la fonction de recrutement définie par l’interface de programmation (ligne 12-17 dans l’exemple du listing 4.1), — dans notre exemple, nous voulons recruter uniquement les nœuds mobiles disposant d’une connexion GSM —. Le capteur virtuel attend ensuite un temps t la réponse des dispositifs mobiles. Les nœuds correspondant à la méthode de recrutement répondent ensuite au capteur virtuel avec un ensemble de propriétés indiquant leurs états actuels (par ex. niveau de 123batterie, type de connexion de données). Ces nœuds sont ensuite ajoutés à une liste indiquant leurs disponibilités pour exécuter la tâche de collecte. Ces nœuds sont ensuite classifiés par la méthode ranking. Cette méthode correspond à celle définie par l’interface de programmation (ligne 18-20 du listing 4.1), permettant de privilégier certains nœuds par rapport à leurs propriétés. Dans notre exemple, nous privilégions les noeuds mobiles disposant du niveau de batterie le plus élevé. À la fin du processus, un nouveau message est envoyé aux nœuds mobiles leur demandant d’exécuter la tâche de collecte. Les noeuds mobiles recevant ce message démarrent l’exécution de la tâche de collecte jusqu’à la date définie par tend ou lorsque les nœuds quittent de la zone gérée par le capteur virtuel. Cela permet de réattribuer la tâche de collecte à un autre nœud. À la fin de l’exécution, toutes les données collectées sont ensuite propagées directement sur le nœud de collecte. 4.6 conclusion APISENSE® propose un environnement facilitant la gestion de campagnes de collecte de données. Pour supporter une grande diversité de campagne de collecte, nous avons proposé un modèle permettant de configurer un environnement serveur (c.-à-d. honey) responsable de l’exécution d’une campagne de collecte. Ainsi, ce modèle est utilisé pour configurer les services d’un nœud de collecte en fonction des spécificités des campagnes de collecte. Cette configuration comprends cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. À partir de ce modèle, un nœud de collecte peut être ensuite généré et déployé par les utilisateurs vers une infrastructure qui peut être publique ou privée selon la nature des données collectées. Cela leur permet de garder un contrôle total sur l’infrastructure hébergeant les données collectées durant leurs campagnes. APISENSE® se distingue également par son architecture décentralisée, permettant d’améliorer le passage à l’échelle du système. Son architecture est ainsi composée d’un ensemble de nœuds de collecte organisé autour du serveur central. Concernant le serveur central, son principal objectif est d’assurer le déploiement des tâches de 124collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrée au préalable. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire. L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. La description des contributions de ce manuscrit est à présent terminée. Dans les chapitres suivants, nous présentons les évaluations de la plate-forme APISENSE®. 125Troisième partie Évaluations 1275 P R AT I Q U E S C U LT U R E L L E S E T U S A G E S D E L’ I N F O RM AT I Q U E C O N N E C T É E Sommaire 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 Dans cette partie, nous présentons les évaluations de la plate-forme APISENSE® en deux chapitres. Dans le premier chapitre, nous présentons une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein de l’étude PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Ce chapitre a pour objectif de montrer le gain en terme de coût de développement apporté par notre plate-forme, et également de montrer la faisabilité de notre approche dans un cas réel d’utilisation. Le deuxième chapitre évalue le passage à l’échelle de APISENSE® pour la réalisation de campagne de collecte communautaire. Nous évaluons notamment le gain du modèle de recrutement collaboratif, permettant de faire un compromis entre l’énergie consommée par les dispositifs mobiles et la quantité de données générées tout en gardant une bonne couverture de collecte. 1295.1 introduction Dans la partie précédente de ce manuscrit, nous avons présenté en intégralité APISENSE®, la plate-forme résultante des travaux de cette thèse. Comme nous l’avons déjà évoqué, le principal objectif de cette thèse est d’ouvrir l’accès du Mobile Crowd Sensing à de nombreux acteurs privés ou académiques, en leur permettant de facilement développer et déployer leurs campagnes de collecte de données. Dans ce chapitre, nous présentons une campagne réalisée au sein d’une étude sociologique nommée PRACTIC 1 (Pratiques Culturelles et Usages de l’Informatique Connectée), qui vise à comprendre l’usage des technologies numériques connectées en matière d’habitudes et de routines de consommations culturelle et médiatique. Cette étude a été réalisée par une équipe pluridisciplinaire, composée de deux ingénieurs en informatique pour le développement des scripts de collecte, et deux chercheurs en sciences de l’information et de la communication pour l’interprétation des données collectées. Par le biais de la description de cette étude, nous cherchons tout d’abord à montrer la faisabilité de notre approche pour être utilisée dans un cas réel d’utilisation, et plus particulièrement évaluer le gain en terme de cout de développement apporté par APISENSE®. 5.2 contexte et objectif de l’étude practic Le principe de l’étude PRACTIC est né de notre rencontre avec des chercheurs en sociologie, dans le cadre du projet de l’Observatoire Scientifique de l’Internet 2 initié par INRIA 3 . Un premier objectif de cette collaboration est de voir en quelle mesure les nouveaux mécanismes de collecte de données, comme le Mobile Crowd Sensing, peuvent augmenter les méthodes traditionnelles de la recherche numérique en sciences sociales. En effet, de nos jours, la nouvelle génération des terminaux intelligents comme les tablettes ou les smartphones sont fortement intégrés dans la vie sociale et culturelle des individus. Cette intégration représente de nouvelles opportunités pour les sciences sociales, qui peuvent ainsi collecter massivement et sur le long terme, des données comportementales des individus de manière non intrusive. De plus, cela nous a permis de confronter notre plate-forme à un déploiement réel, et d’être utilisée par des personnes tierces à notre équipe. 1. http ://beta.apisense.fr/practic 2. http ://metroscope.org/ 3. www.inira.fr 130L’étude PRACTIC est composée majoritaire de deux phases. La première est une phase de collecte de données auprès d’un ensemble de participants volontaires, combinant les collectes de données opportuniste et participative (c.-à-d. questionnaire). Dans le cadre de PRACTIC, la confrontation de la collecte opportuniste et participative permet de mesurer l’écart entre la représentation des individus sur l’utilisation de leur smartphone et leur pratique effective. La seconde phase comprend des traitements statistiques sur les données collectées qui aboutiront sur quelques entretiens individuels. Dans ce chapitre, nous décrivons uniquement la première phase de l’étude qui est directement en relation avec la plate-forme APISENSE®. Nous décrivons à présent le développement de cette phase de collecte. 5.3 développement de l’étude practic La phase de collecte a entièrement été développée par APISENSE®, en utilisant son modèle de programmation (cf. chapitre 3 section 3.3) pour la description des données collectées sur les environnements mobiles, et un nœud de collecte déployé sur un serveur privé pour la persistance des données. Cette phase a été développée par un Ingénieur Jeune Diplômé (IDJ) en informatique, intégré pour les besoins de l’étude, qui n’avait aucune compétence particulière en programmation mobile au début du développement. L’application PRACTIC a d’abord connu plusieurs phases de test auprès d’un sous ensemble de participants. Ces différentes itérations ont permis d’identifier certains bugs, et d’ajouter des fonctionnalités non anticipées qui ont permis de consolider APISENSE® et l’enquête. Durant cette phase de test, l’ingénieur en question été responsable de faire la transition entre les exigences des sociologues, et les capacités offertes par notre plate-forme. La figure 27 illustre les principales données collectées par l’application PRACTIC. Un aspect intéressant ici est qu’elle utilise un large éventail des fonctionnalités proposées par APISENSE®. La collecte de données comprend principalement trois parties différentes que sont la collecte opportuniste de données, la collecte participative et les retours utilisateurs, correspondant respectivement à plusieurs scripts de collecte. Nous décrivons à présent brièvement ces différents points, et comparons à la fin de cette section le gain en terme de coût de développement apporté par notre modèle de programmation. 131Figure 27 – Données collectées par l’étude PRACTIC 5.3.1 Collecte opportuniste La première partie vise à collecter la diversité des rythmes de vie ainsi que des usages sociaux ou culturels des dispositifs mobiles. Toutes ces données sont collectées automatiquement par l’application sans nécessiter une intervention des participants. Typiquement, trois types de données sont collectées : Contenu Mobile, Activité de l’utilisateur, et Contexte mobile. Chaque type de données correspond à un script de collecte spécifique. Nous présentons brièvement un exemple simplifié des scripts de collecte développés. Contenu Mobile Le contenu mobile (cf. listing 5.1) vise à identifier des profils culturels des participants en fonction du contenu de leur appareil mobile. Dans le cadre de PRACTIC, la dimension culturelle est vue à deux niveaux : le type des applications mobiles installées (c.-à-d. jeux,divertissement, communication), les genres musicaux des participants. Le listing 5.1 décrit le script de collecte associé. La première partie du script (ligne 1-6) est déclenchée une seule fois lors de la première exécution du script. Dans cette partie, un ensemble de méta-données est collecté comprenant la liste des applications installées (nom, date d’installation, catégorie), et celle des fichiers musicaux présents (nom, artiste, format d’encodage, taille en Ko). La deuxième partie vise à identifier les cycles d’installation et de désinstallation des applications. Cette partie est réalisée 132automatiquement lorsqu’un événement concernant l’installation ou la désinstallation est déclenchée par le système mobile. 1 $schedule.once(function(){ 2 // store media files meta-data 3 $trace.add($media.getAudioFiles()); 4 // store installed applications meta-data 5 $trace.add($app.getLaunchableApplications()); 6 }); 7 8 $app.onAppInstallEvent(function(app){ 9 // store new installed or uninstalled application meta-data 10 $trace.add(app); 11 }); Listing 5.1 – Collecte du contenu mobile Activité utilisateur Cette partie vise à collecter les différents rythmes de vie et d’usages des dispositifs mobiles. Les usages sont principalement séparés en deux catégories correspondant aux usages natifs des téléphones mobiles (c.-à-d. appels et SMS) et les nouveaux usages introduis par la nouvelle génération des terminaux intelligents. Le listing 5.2 décrit l’utilisation de la façade $phone permettant de collecter des données sur les appels et les SMS émis et reçus. Pour des raisons de confidentialité, le contenu des appels et des SMS ainsi que l’identifiant des correspondants ne sont pas accessibles à partir des scripts. Seules la durée des communications ainsi que la taille des SMS sont disponibles. 1 $phone.onCallCompleted(function(call){ $trace.add(call) }); 2 3 $phone.onSMS(function(sms){ $trace.add(sms) }) Listing 5.2 – Collecte des usages natifs des dispositifs mobile La deuxième catégorie, illustrée par le listing 5.4 identifie les sessions d’utilisation des dispositifs. Celles-ci comprennent les sessions générales d’utilisations (écran allumé et éteint) et les sessions d’utilisation des applications. L’identification des sessions générales peut être effectuée par le biais de la façade $screen permettant d’intercepter les événements liés à l’écran du dispositif (lignes 2 et 22). Une session commence lorsque l’événement onScreenOn est déclenché. À la suite de cet événement, le script vérifie toutes les secondes (ligne 5) l’application exécutée en premier plan du dispositif (ligne 6), et collecte une session applicative lorsque l’application détectée est différente de la précédente (lignes 7-20). La session générale se termine lorsque l’événement 133onScreenOff est déclenché, dans ce cas la vérification des applications exécutées en premier plan est annulée (ligne 30), et cela déclenche également une nouvelle collecte de données correspondant à la durée de la session générale (lignes 25-29). 1 var subscription,startSession,subscription,appName,startApp; 2 $screen.onScreenOn(function(screen){ 3 4 startSession = screen.time; 5 subscription = $schedule.every("1 s",function(event){ 6 var currentApp = $app.currentApplicationName(); 7 if (appName != currentApp){ 8 9 appName = currentApp; 10 startApp = event.time; 11 12 // store application session 13 $trace.add({ 14 event : "ApplicationSession", 15 start : startApp, 16 end : event.time, 17 name : appName 18 }); 19 }; 20 }); 21 }); 22 $screen.onScreenOff(function(event){ 23 24 // store screen session 25 $trace.add({ 26 event : "ScreenSession", 27 start : startSession, 28 end : event.time 29 }); 30 subscription.suspend(); 31 }); Listing 5.3 – Collecte des usages des applications mobile Contexte mobile Finalement, la dernière catégorie des données collectées permet de mettre en perspective l’utilisation des applications et leurs contextes (cf. listing 5.4). Cela permet d’identifier par exemple si certaines applications sont utilisées uniquement lorsque le participant se trouve à son domicile ou sur son lieu de travail,ou encore d’observer si la qualité du réseau ou le niveau de batterie influe sur l’utilisation de certaines applications. Cette catégorie comprend les cycles de chargement et le niveau de la batterie (lignes 10-12), le contexte réseau (ligne 7-9) constitué du type de connexion 134de données (c.-à-d. Wi-Fi, 3G/4G), et de la force du signal réseau GSM (lignes 1-6). Pour déterminer si l’utilisateur est en situation de mobilité, le choix a été fait de collecter uniquement les identifiants des antennes cellulaires, qui permettent d’avoir une approximation de la localisation du participant sans entraîner une consommation énergétique supplémentaire de l’application mobile [65]. 1 $telephony.onSignalStrengthChanged(function(signal){ 2 $trace.add({ 3 level : signal.level, 4 cellId : $telephony.cellId() 5 }); 6 }); 7 $network.onNetworkStateChange(function(networkEvent){ 8 $trace.add(networkEvent); 9 }); 10 $battery.onBatteryStateChange(function(batteryEvent){ 11 $trace.add(batteryEvent); 12 }); Listing 5.4 – Collecte des usages des applications mobiles 5.3.2 Collecte participative Le questionnaire vise à collecter des données déclaratives sur l’équipement, les usages et le rapport à la vie privée des participants. Il est composé de 152 questions, dont certaines ne sont pas obligatoires. Par exemple, dans la partie des usages, le fait de ne pas posséder une tablette par exemple permet de ne pas répondre à un sous-groupe de questions. Entre 20 et 30 minutes sont nécessaires pour répondre intégralement au questionnaire. Les questions sont organisées au sein de quatre grandes parties : à propos de vous (16 questions), équipements (36), pratiques culturelles et usage de l’informatique connectée (60) et publicité en ligne et privée (19). Le questionnaire peut être complété à tout moment par les participants à partir de leurs dispositifs. Le listing 5.5 montre une très brève partie du questionnaire développé. Typiquement, les réponses du questionnaire vont être croisées par les sociologues avec les données collectées automatiquement par l’application. 1 var survey = $survey.create("PRACTIC"); 2 // ... 3 var q88 = survey.close("Quel est le lecteur musical que vous utilisez le plus ?",[ 4 "Chaine Hi-Fi / Platine Vinyle", 5 "Baladeur/MP3", 1356 "Smartphone", 7 "L’ordinateur (musique enregistrée sur le disque dur ou CD)", 8 "La radio", 9 "La television (chaines musicales comme MTV)", 10 "Autre lecteur de musique" 11 ]); 12 var q88b = survey.open("Quel autre lecteur utilisez-vous ?"); 13 var q89 = survey.close("Quel est votre maniére d’écoute principale avec votre lecteur ?",[ 14 "Casque audio", 15 "Enceinte/Ampli", 16 "Sans rien" 17 ]); 18 q88.then(function(response){ 19 20 if (response == "Autre lecteur de musique"){ 21 return q88b; 22 } 23 else return q89; 24 }); Listing 5.5 – Extrait du questionnaire PRACTIC 5.3.3 Retour utilisateur La dernière partie des scripts de collecte vise à donner un aperçu aux participants des données collectées. Typiquement, l’objectif de cette partie est d’agir en toute transparence vis-à-vis des participants sur les données qui sont collectées sur leurs dispositifs, et d’apporter un aspect ludique à l’application. L’idée est de permettre aux participants de confronter leur perception de l’utilisation de leur dispositif avec leur usage réel. La figure 28 montre un exemple de retour utilisateur sur la durée totale d’utilisation de son appareil. Cette partie a été développée intégralement en HTML/JavaScript. 5.3.4 Discussions Dans cette section, nous avons décrit l’ensemble des scripts de collecte qui a été nécessaire dans le cas de l’étude PRACTIC. Nous allons maintenant identifier le gain apporté par APISENSE® pour le développement de ce cas d’étude. L’application mobile APISENSE®, responsable du téléchargement, de l’exécution des scripts et de la propagation des données collectées a été développée en utilisant la version 2.3 du SDK de Android. L’application APISENSE® fournit de nombreuses abstractions qui simplifient 136Figure 28 – Exemple de retour utilisateur PRACTIC le développement d’une application de collecte de données. La première permet tout d’abord d’avoir une abstraction complète du SDK Android pour accéder aux données fournies par Android, et intercepter les différents événements internes au dispositif mobile grâce aux façades. Le tableau 12 récapitule les façades qui ont été utilisées pour développer PRACTIC, et leur nombre de lignes de code Java qui ont été nécessaires à leur développement. Au total, ces façades comptent approximativement 6000 lignes de code. Pour les besoins de l’étude, en collaboration avec l’ingénieur responsable du développement de PRACTIC, nous avons dû intégrer deux nouvelles façades pour lister les fichiers musicaux (façade $media) et pour observer les évènements liés à l’écran d’un dispositif (façade $screen). Ces façades peuvent être à présent disponibles pour le développement de nouveaux scripts de collecte. L’application APISENSE® dispose également d’un ensemble de services responsables de l’exécution des scripts de collecte en tâche de fond,d’interagir avec le serveur central d’APISENSE® pour le téléchargement et de la mise à jour des scripts de collecte, d’interagir avec les nœuds de collecte des scientifiques pour propager automatiquement les données collectées, et de contrô- ler les ressources consommées par les scripts de collecte (cf. chapitre 3 section 3.4). Cette partie comporte approximativement plus de 20000 lignes de code. Pour finir, l’application mobile APISENSE® possède également une interface graphique générique destinée aux participants (6000 lignes de code). 137Façade Description LOC $survey Génération et publication d’un questionnaire 1277 $feedback Intégration de visualisation HTML/JavaScript 2144 $network Observation du contexte réseau 259 $telephony Observation du réseau cellulaire 400 $phone Observation des communications 600 $battery Observation des états de la batterie 158 $app Observation des applications 362 $trace Collecte et propagation des données 376 $screen (nouvelle) Observation de l’écran 235 $media (nouvelle) Liste du contenu 210 Table 12 – Façade utilisée pour les besoins de l’application PRACTIC La figure 29 met en évidence le gain en terme de lignes de codes obtenu grâce à APISENSE® par rapport aux scripts développés. Au total, seulement 7 % de codes spécifiques ont eu besoin d’être développés pour l’étude PRACTIC. Les principaux efforts de développement résident dans la description des 150 questions et leurs enchaînements (760 lignes) et dans les interfaces graphiques effectuant un retour sur les données obtenues (1600 lignes). Dans la section suivante, nous présentons le protocole de déploiement de l’application. Figure 29 – Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 1385.4 déploiement de l’étude practic Après avoir présenté dans son ensemble les scripts de collecte de l’étude PRACTIC, nous présentons dans cette section son protocole de déploiement et discutons de la participation à cette étude. 5.4.1 Protocole du déploiement Pour la mise en place de l’étude PRACTIC, un nœud de collecte a tout d’abord été déployé sur un serveur privé des scientifiques. Le nœud de collecte a été configuré pour utiliser un modèle de recrutement individuel, pour indexer les données collectées par utilisateur et pour utiliser un système de classement à point (cf. chapitre 4 section 4.4.1) afin de maximiser la participation des utilisateurs. Pour que les données collectées soient pleinement exploitables par les sociologues, ils ont besoin qu’elles soient collectées au minimum pendant 14 jours par participant, et que celui-ci ait répondu au questionnaire de l’enquête. Dans ce contexte, les points sont attribués de la manière suivante : • 50 points pour les participants ayant installé l’application sur une tablette et un smarpthone, remplis le questionnaire et ayant généré plus de 14 jours de données. • 20 points pour les participants qui ont installé sur un seul appareil (smartphone ou tablette), avec le questionnaire rempli et toujours un minimum de 14 jours de données générées. • 1 point par jour de données générées • 2 points si le questionnaire est rempli Des lots ont été prévus pour récompenser les meilleurs participants comprenant une tablette tactile, un smarpthone, une liseuse ainsi que des disques durs externes et des clés USB. Le nœud de collecte a également été utilisé pour le développement des scripts de collecte ainsi que leurs déploiements auprès d’un serveur central que nous avions au préalablement déployé sur un service Microsoft Azure 4 . Pour des raisons éthiques et légales, l’étude PRACTIC a été soumise et validée par la Commission National de l’Informatique et des Libertés 5 (CNIL). 4. http ://azure.microsoft.com/fr-fr/ 5. http://www.cnil.fr/ 139Les participants intéressés à participer à l’étude PRACTIC doivent tout d’abord télécharger et installer l’application mobile APISENSE® publiée sur le site internet APISENSE® 6 en flashant un QR code. À partir de l’application, les participants pourront alors s’enregistrer auprès de l’étude PRACTIC. L’enregistrement déclenchera automatiquement le téléchargement et l’exécution des scripts de collecte après la validation d’une charte de confidentialité. Un identifiant unique est généré et accordé à chaque participant lors de son inscription. Ce n’est qu’en acceptant de communiquer cet identi- fiant avec les chercheurs qu’ils pourront être identifiés. Nous présentons dans la suite de cette section le niveau de participation à PRACTIC, et discutons des premiers retours de l’expériences. 5.4.2 Participation L’étude PRACTIC s’est déroulée du 10 MARS au 19 Avril 2014. La figure 30 montre le nombre d’utilisateurs inscrits par jour, ainsi que l’accumulation du nombre d’inscriptions durant l’étude. Au total, 88 participants ont été recrutés durant l’étude. Figure 30 – Nombre d’inscriptions par jour à PRACTIC Un aspect intéressant des participants recrutés est la diversité de leurs équipements (cf. figure 31), ce qui nous a permis de tester APISENSE® sur 45 modèles de smartphones différents. Outre le nombre d’inscriptions, le succès de l’étude repose principalement sur le taux de participation des utilisateurs tout au long de l’étude. Pour que les données 6. http://www.apisense.fr 140Figure 31 – Diversité des équipements mobiles d’un participant soient exploitables par les chercheurs, il est nécessaire qu’elles aient été collectées au moins sur une période de 14 jours, et que celui-ci ait répondu au questionnaire de l’application. Figure 32 – Taux de participation à la collecte opportuniste 141Figure 33 – Taux de participation à la collecte participative et opportuniste Sur l’ensemble des participants, comme la montre la figure 32, 48 ont collecté des données plus de 14 jours, 21 de 4 à 13 jours, 13 de 1 à jour 6 qui n’ont collecté aucune donnée. Les participants ayant répondu au questionnaire sont au nombre de 25, et les participants ayant à la fois répondu au questionnaire et collecté au moins 14 jours de données sont au nombre de 12 (cf. figure 34). Ces derniers représentent les cas d’étude concrets pour les scientifiques. Bien que ce nombre soit inférieur à celui escompté au début de l’étude, un point positif des premiers résultats obtenus permet de valider que les dispositifs sont bien au cœur des pratiques de certains participants. La figure 34 par exemple représente le nombre de sessions applicatives, ainsi que leurs durées, sur une période de 40 jours Cette courbe met bien en évidence les différents rythmes des usages d’un participant en particulier, qui utilise son dispositif tout au long de la journée, et qui intensifie son utilisation en fin de journée. Figure 34 – Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 1425.5 conclusion Dans ce chapitre, nous avons présenté un cas réel de campagne de collecte de données développée et déployée avec APISENSE® au sein d’une étude sociologique. Nous avons montré que APISENSE® permettait réduire le temps de développement d’une campagne de collecte en proposant un modèle de programmation permettant de s’abstraire complètement des technologies mobiles. Dans le cas de cette étude, le modèle de programmation a permis d’économiser plus de 90% de code nécessaire à son développement. La campagne développée a été déployée auprès de 88 utilisateurs sur une période d’un mois et demi. 143É VA L U AT I O N D U M O D È L E C O L L A B O R AT I F 6 Sommaire 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 6.1 introduction Dans ce chapitre, notre objectif est de montrer la validité du modèle de recrutement collaboratif présenté dans le chapitre 4 en section 4.5, page 113 qui permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles. Nous rappelons que le but de cette coordination est dans un premier temps de répartir les charges énergétiques entre les dispositifs mobiles durant la campagne de collecte, puis dans un second temps de diminuer la quantité de données propagées vers les nœuds de collecte en limitant la propagation de données dupliquées. La validité du modèle est évaluée sur quatre critères : i) la quantité de données propagées sur les nœuds de collecte, ii) la quantité d’énergie utilisée par les dispositifs mobiles ainsi que iii) le surcoût induit par notre approche pour effectuer la coordination des tâches, iv) la couverture géographique des données obtenues. Pour valider notre modèle, nous avons mené une expérience et développé un environnement de simulation que nous détaillons dans la section suivante. 6.2 mise en place de l’expérience Pour cette évaluation, nous reprenons l’exemple de l’application présentée dans la section 4.5.1 page 116 qui est une version simplifiée d’une collecte de données exposée 145dans LiveLab [61]. L’objectif de cette application est d’utiliser les dispositifs mobiles pour mesurer la qualité des réseaux GSM en milieu urbain. Le listing 6.1 décrit la tâche de collecte associée à cette application qui consiste à exécuter 10 Pings réseaux (Packet INternet Groper) toutes les trente secondes et à collecter la latence moyenne des Pings effectués ainsi que la position du dispositif obtenue avec par GPS. 1 $location.onLocationChanged({period : "30s", provider : "GPS"},function(event) { 2 $trace.add({ 3 loc: [event.latitude, event.longitude], 4 latency : $network.ping(10,"http://...").average}); 5 })} Listing 6.1 – Tâche de collecte : Mesure de la latence réseau Pour évaluer notre approche, nous avons simulé le recrutement des dispositifs suivant un modèle où tous les dispositifs exécutent la tâche de collecte indépendamment les uns des autres, et suivant le modèle collaboratif, où les capteurs virtuels coordonnent l’exécution des tâches de collecte entre les dispositifs mobiles (cf. 4.5.2, page 119 ). Pour une évaluation réaliste et à grande échelle, nous utilisons des traces de mobilités réelles provenant de 10000 taxis équipés de GPS dans la ville de Pékin en Chine [67]. Ces données ont été collectées sur une période d’une semaine allant du 2 au 8 février 2008. Afin d’utiliser ces données, nous avons développé un simulateur illustré par la figure 35. Le simulateur comprend trois composants : un Manager, un ensemble d’Agents et un nœud de collecte (DataGathering Node). agents : Les agents sont responsables de générer le trafic réseau simulant les interactions entre les dispositifs mobiles et le nœud de collecte. Ces interactions sont simulées à partir d’un fichier de mobilité comprenant une série de tuples (date, latitude, longitude) représentant les déplacements d’un taxi à travers le temps. Pour l’expérience, nous avons implémenté deux types d’agents : i) les agents individuels et ii) les agents collaboratifs. Les agents individuels exécutent la tâche de collecte en continu tout au long de l’expérience, c’est-à-dire qu’ils collectent toutes les 30 secondes leur position selon le fichier de mobilité, et propagent l’ensemble des données collectées sur le nœud de collecte toutes les 5 minutes. Quant aux agents collaboratifs, ils s’enregistrent auprès des capteurs virtuels selon leur position à un instant t, et exécutent la tâche de collecte lorsqu’ils ont reçu une demande d’exécution de la part du capteur virtuel. Pour assurer une montée en charge du simulateur, les agents sont répartis auprès de plusieurs machines 146virtuelles hébergées sur la plate-forme Microsoft Windows Azure 1 . Des machines virtuelles de taille Small (A1) 2 sont utilisées, correspondant à un processeur à 1 coeur, 1,75 Go de mémoire et une carte réseau de 100 Mbit/s. datagathering node : Pour la simulation, nous avons déployé un nœud de collecte (cf. section 4.4, page 100 ) sur une machine virtuelle hébergée sur Microsoft Windows Azure. Une machine virtuelle de taille Medium (A2) est utilisée, correspondant à un processeur à 2 coeurs, 3,5 Go de mémoire et une carte réseau de 200 Mbit/s. manager : Ce dernier composant est responsable de répartir les fichiers de mobilité auprès des agents déployées sur les machines virtuelles, et de lancer le début de la simulation afin de synchroniser les agents. Figure 35 – Architecture du simulateur de traces de mobilité Pour les simulations présentées dans la suite de ce chapitre, nous utilisons les données du 3 février 2008 représentant la journée où le plus de données ont été produites. Les tâches de collecte sont déployées dans une zone de collecte de 10 km2 situés dans le centre-ville de Pékin, durant une durée de 30 minutes. 1. http://azure.microsoft.com 2. http://azure.microsoft.com/en-us/pricing/details/virtual-machines 1476.3 résultats Dans cette section, nous présentons les résultats obtenus à travers les différentes expériences menées grâce au simulateur développé. Nous discutons des résultats en fonction de la quantité, de la couverture géographique des données collectées ainsi que de l’énergie utilisée par les dispositifs mobiles durant les expériences et du surcoût engendré par notre approche. Pour évaluer les gains de notre modèle de recrutement, nous avons déployé, à travers le simulateur, la tâche de collecte présentée dans le listing 6.1 suivant trois modèles appelé individual, coll(1000 m), et coll(500 m). individual : dans ce modèle, les dispositifs exécutent la tâche de collecte indépendamment les uns des autres. Ils obtiennent une nouvelle position du GPS toutes les 30 secondes, et exécutent la tâche de collecte lorsque leur position se situe dans la zone de collecte définie. coll(1000 m) : dans ce modèle, l’exécution de la tâche de collecte est coordonnée par les capteurs virtuels déployés dans le nœud de collecte. L’objectif de couverture est fixé tous les 1000 mètres dans la zone de collecte avec 5 dispositifs attribués à la tâche (cf. section 4.5.1). coll(500 m) : ce modèle est identique au précédent sauf que nous avons fait varier l’objectif de couverture tous les 500 mètres dans la zone de collecte. Cela nous permet d’étudier l’impact de la couverture définie sur la quantité de données collectées et sur la consommation énergétique des dispositifs mobiles. 6.3.1 Quantité de données et couverture géographique Tout d’abord, nous comparons la quantité des données collectées. Les courbes illustrées par la figure 36 comparent la quantité de données collectées (en kilobyte) pour les trois tâches de collecte déployées en fonction du nombre de dispositifs. La première tâche, illustrée par la courbe individual, représente la quantité de données lorsque les dispositifs collectent individuellement la tâche de collecte. Les deux suivantes, illustrées par les courbes coll(1000 m) et coll(500 m) représentent les tâches de collecte déployées en utilisant le modèle collaboratif. Nous avons fait varier entre 500 et 10000 le nombre de dispositifs simulés durant cette expérience. Comme le montre cette figure, lorsqu’aucune collaboration n’est effectuée, la quantité de données générées augmente linéairement, allant jusqu’à 12000 KB de données produites pour 10000 dispositifs. En effectuant une collaboration, la quantité de données se stabilise autour des 6000 KB pour 148un objectif de couverture de 500 m2 et 2500 KB pour un objectif de 1000 m2 . Pour 10000 dispositifs, cela représente respectivement une diminution de 50% et 80% de quantité de données propagées vers le serveur. Ce gain s’explique, car lorsque suffisamment de dispositifs se trouvent dans une même zone (par ex. plus de 5 dispositifs dans une zone de 500 m2 pour la tâche coll(500 m)), le capteur virtuel associé à cette zone attribut seulement à 5 dispositifs la tâche de collecte, évitant ainsi aux autres dispositifs de la même zone d’exécuter la tâche de collecte. Figure 36 – Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique Cependant, pour valider notre approche, il est essentiel de comparer la quantité de données avec la couverture réellement obtenue. Pour cela, nous avons mené une deuxième expérience impliquant 10000 dispositifs mobiles, et nous avons observé la couverture géographique obtenue à travers différentes périodes de la journée par rapport à la quantité de données collectées. La couverture est définie par le pourcentage de zone couverte par les données collectées, soit 400 zones de 500 m2 dans la zone de collecte d’une surface de 10 Km2 . La figure 37 illustre le résultat de cette expérience. Dans cette figure, les courbes bleu et verte représentent respectivement la couverture obtenue par les approches individuelle (individual-SP) et collaborative (coll(500 m)- 149SP), et les colonnes rouge (individual-Data) et jaune (coll(500 m)-Data) la quantité de données collectées par ces deux approches. Comme le montre cette figure, la couverture des données obtenue varie tout au long de la journée, pour atteindre un pic à 17 H représentant une forte mobilité des taxis dans la zone de collecte. Ce que nous pouvons observer d’intéressant, c’est que les couvertures obtenues par ces deux approches sont relativement équivalentes, bien que la quantité de données collectées par l’approche collaborative soit toujours inférieure à celle de l’approche individuel. La différence des couvertures obtenues entre les deux approches est due à la mobilité des taxis. En effet, si un taxi se déplace à grande vitesse, celui-ci peut traverser une zone avant que le capteur virtuel associé n’est le temps de lui attribuer une tâche. Cependant, dans cette simulation, la perte de la couverture obtenue ne varie pas au delà des 2%. Figure 37 – Comparaison de la couverture géographique selon différentes périodes de la journée À travers ces deux expériences, nous avons montré que l’approche collaborative que nous avons proposée permet de diminuer la quantité de données propagées vers le serveur tout en gardant une couverture presque similaire à une approche classique. Nous allons maintenant évaluer les gains de cette approche sur la consommation énergétique des dispositifs mobiles. 1506.3.2 Consommation énergétique Pour évaluer l’énergie consommée par les dispositifs mobiles liée au trafic réseau et à l’acquisition de la position par le GPS, nous utilisons deux modèles énergétiques très référencés dans la littérature. Le premier modèle, proposé par Balasubramanian et al. [5], permet de déterminer l’énergie liée à la transmission de données par des réseaux sans fil. Dans le contexte de cette évaluation, nous assumons que toutes les données sont transmises par un réseau 3G. Ce modèle divise l’énergie consommée en trois parties. La première est liée à l’activation de l’interface de communication évaluée à 3,5 Joules. La deuxième est liée à la transmission des données évaluée à 0.025 Joule/KB. Et la dernière est liée au temps que l’interface de communication soit désactivée après la transmission des données. Ce temps est évalué à 12,5 secondes et l’interface consomme 0,62 Joule/s jusqu’à ce qu’elle soit désactivée. Dans le cadre où deux transmissions de données sont effectuées en dessous des 12,5 secondes, l’énergie consommée par cette dernière partie est négligée. Pour le deuxième modèle, nous utilisons celui proposé par Lin et al. [43], qui évalue l’énergie liée à l’acquisition périodique d’une position par le GPS à 1,4 Joules par position obtenue. Les courbes illustrées par la figure 38 comparent la consommation énergétique des trois tâches de collecte déployées dans la première expérience de la section précédente par rapport à la concentration de dispositifs mobiles dans la zone de collecte. L’énergie est donnée en Joule et correspond à la moyenne énergétique consommée par l’ensemble des dispositifs mobiles. Comme attendue, la consommation énergétique de la tâche individuelle (individual) est indépendante de la concentration des dispositifs mobiles, et reste constante autour des 600 Joules en moyenne par dispositif. En revanche, les tâches collaboratives (coll(1000 m) et coll(500 m)) bénéficient de cette concentration croissante en évitant de collecter des données non nécessaires pour atteindre les objectifs de couverture, et ainsi réduire la consommation énergétique moyenne par dispositif. Pour coll(1000 m), le gain sur la consommation énergétique des dispositifs varie entre 43% pour 500 dispositifs et 82% pour 10000 dispositifs, tandis que pour coll(500 m), ce gain varie entre 40% et 70%. Afin de mieux comprendre où le gain énergétique est effectué, les graphiques de la figure 39 montrent la répartition des charges énergétiques consommées durant l’expérience pour les trois tâches individual (a), coll(1000 m) (b) et coll(500 m) (c). Dans cette figure, la partie bleue (Localisation) des colonnes représente la consommation 151Figure 38 – Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte causée par l’acquisition d’une position par le GPS, la partie rouge (Sensing Task) à l’exécution des Pings réseaux (cf. listing 6.1 ligne 4) et la partie orange (VS Messages) aux communications avec les capteurs virtuels. Comme le montre cette figure, le gain de la collaboration sur la consommation énergétique est particulièrement liée à l’acquisition des positions par le GPS. En effet, dans cette approche, les dispositifs ont seulement besoin d’obtenir une position pour déterminer à quel capteur virtuel ils doivent s’enregistrer, permettant à ces dispositifs de réduire la fréquence de l’acquisition d’une nouvelle position si leur vitesse est relativement réduite ou en position statique (cf. section 4.5.2, page 121 ). Cela représente dans cette expérience un gain respectif de 86% et 80% pour les tâches coll(1000 m) et coll(500 m). Dans ce contexte, une grande perte énergétique du modèle de recrutement individuelle s’explique par le fait que même les dispositifs ne se situant pas dans la zone de collecte sont obligés de continuellement activer leur GPS afin de déterminer s’ils sont dans la zone étudiée ou non. En ce qui concerne l’énergie consommée par l’exécution des Pings réseaux, le gain reste limité lorsque peu de dispositifs sont impliqués dans l’expérience. Pour le modèle coll(1000 m), le gain est seulement de 4% et devient négatif pour coll(500 m). Ceci s’explique par le surcoût énergétique engendré par les communications des dispositifs avec les capteurs virtuels. Néanmoins, le gain énergétique s’accroît lorsque plus de dispositifs sont impliqués pour atteindre 81% pour coll(1000 m) et 55% pour le modèle coll(500 m). 152Figure 39 – Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153Comme attendu, ces chiffres montrent que le gain énergétique lié à la coordination des tâches varie selon la concentration des dispositifs mobiles dans la zone de collecte et également des objectifs de couvertures définies. Cependant cela révèle également les limitations du modèle évalué dans ce chapitre. En effet, dans le contexte où la concentration des dispositifs mobiles est trop faible pour permettre une coordination des tâches, notre modèle consommerait plus qu’un modèle classique à cause des communications nécessaires avec les capteurs virtuels. D’autre part, notre modèle reste limité si l’objectif de couverture nécessaire pour la campagne de collecte doit être très élevé (par ex. tous les 50 mètres). Cela engendrerait un trafic réseau trop important, car les dispositifs seraient sens cesse en train de communiquer avec les capteurs virtuels, spécialement dans un cas de forte mobilité. Dans ce contexte, la solution proposée ici reste principalement efficace pour les campagnes de collecte nécessitant une couverture géographique de collecte d’une centaine de mètres ou plus. Quelques exemples de ce type de campagnes sont la mesure de la qualité de l’air [19], ou la mesure de la qualité des réseaux sans fil comme présentés dans ce chapitre [61]. 6.4 conclusion Nous avons présenté dans ce chapitre l’évaluation du modèle de recrutement collaboratif proposé dans APISENSE®. Ce modèle s’appuie sur la forte concentration des dispositifs en milieu urbain pour coordonner l’exécution des tâches de collecte entre ces dispositifs selon un objectif de couverture géographique. Pour évaluer ce modèle, nous avons présenté plusieurs expériences basées sur des traces réelles de mobilités provenant de 10000 taxis. Par le biais des expériences menées, nous avons montré qu’en coordonnant l’exécution des tâches, le modèle proposé comporte principalement deux avantages par rapport à un modèle de recrutement où tous les dispositifs les exécutent de manière indépendante. Les expériences ont montré que notre approche permet dans un premier temps de diminuer la quantité de données propagée sur le serveur de plus de 50% lorsque 10000 dispositifs mobiles sont impliqués, tout en gardant une couverture géographique des données collectées similaire. Nous avons également montré que la coordination des tâches de collecte permettait de diminuer la consommation énergétique de ces dispositifs jusqu’à 70%. 154Dans le prochain chapitre, nous concluons en faisant un bilan des contributions présentées dans ce manuscrit, et discutons des perspectives de développements et de recherches issues des travaux de cette thèse. 155Quatrième partie Conclusion 1577 C O N C L U S I O N Sommaire 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 Ce chapitre, qui finalise la présentation faite au travers de ce manuscrit, s’organise de la manière suivante. La section 7.1 rappelle le contexte dans lequel se sont inscrits les travaux réalisés et la problématique qui en est à l’origine. La section 7.2 résume les contributions décrites dans ce manuscrit. Enfin la section 7.3 définit un ensemble de pistes de recherche et de développement en lien avec les travaux de cette thèse. 7.1 rappel des motivations Le Mobile crowdsensing est une nouvelle alternative exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour la collecte massive de données environnementales ou comportementales de la population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux. Malgré le potentiel du Mobile crowdsensing, les campagnes de collecte réalisées impliquant un grand nombre d’utilisateurs mobiles sont rares et restent principalement développées par des experts. Ceci est particulièrement dû à l’absence de prise en compte d’aspects non fonctionnels des systèmes proposés dédiés au MCS. En effet, réaliser une campagne de collecte impliquant un grand nombre d’utilisateurs mobiles demande de faire face à de nombreux défis. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la 159mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que de faire face à l’hétérogénéité des plate-formes mobiles disponibles (par ex. Android, iOS...). À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisable dans un contexte non anticipé. Ce manque d’approche réutilisable demande généralement de devoir réinventer la roue pour chaque nouveau système, entravant ainsi l’adoption du MCS pour de nombreux acteurs n’ayant pas les compétences, ni le temps de développer un système capable de répondre à leurs exigences. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au MCS pour adresser les limitations actuelles liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. APISENSE® propose un environnement distribué permettant de simplifier le développement et le déploiement de campagnes de collecte de données à travers des utilisateurs mobiles. Nous décrivons dans la section suivante un résumé des contributions décrites dans ce manuscrit. 7.2 rappel des contributions Dans cette section, nous synthétisons nos contributions présentées dans le chapitre 3 et le chapitre 4 au travers de l’implémentation de la plate-forme APISENSE®. 7.2.1 Collecte mobile de données Dans notre première contribution, nous avons tout d’abord proposé un modèle de programmation pour simplifier le développement de tâches de collecte de données (cf. chapitre 3 section 3.3, page 59 ). Pour concevoir ce modèle, nous avons tenu compte de trois propriétés qui sont la portabilité, la généralité, et l’accessibilité. En ce qui concerne la portabilité, nous avons basé notre modèle sur le langage de script JavaScript, qui est facilement exécutable sur de nombreux systèmes d’exploitation des dispositifs mobiles actuels. Pour l’accessibilité, nous avons proposé une interface de programmation simple et efficace fournissant une abstraction complète des technologies mobiles. Et pour la généralité, l’interface a été conçue pour supporter une grande variété d’activités de 160collecte, comprenant la collecte opportuniste et participative (cf. chapitre 2 section 2.1.2, page 26 ). Plus particulièrement, l’interface proposée permet de facilement écouter les changements d’état des capteurs mobiles pour la collecte de données opportuniste, d’interagir avec l’utilisateur mobile pour la collecte de données participative ainsi que définir les stratégies de propagation des données. Nous avons également présenté dans ce chapitre l’architecture de l’environnement mobile (cf. chapitre 3 section 3.4, page 68 ) assurant l’exécution des tâches de collecte. Cette architecture met principalement l’accent sur la sécurité et le respect de la confi- dentialité des participants. Pour atteindre cet objectif, tous les scripts sont exécutés dans un bac à sable dédié. Ainsi, cela nous permet de contrôler tous les accès des scripts vers les capteurs des dispositifs mobiles. Par le biais d’une interface graphique, nous laissons la possibilité aux utilisateurs mobiles de définir des contraintes empêchant toute activité de collecte non désirées. Ces contraintes sont classifiées en quatre catégories : temporelles, géographiques, de ressources consommées et de capteurs utilisés. 7.2.2 Collecte répartie de données Dans cette deuxième contribution, le défi adressé concerne la généralité de la plateforme pour concevoir une grande variété de campagnes de collecte ainsi que son passage à l’échelle. Pour supporter une grande diversité de campagnes de collecte, nous avons proposé un Modèle de Variabilité (MC) [32] (en anglais FM pour Feature Model), capturant les différentes configurations d’une application serveur responsable de la gestion des campagnes de collecte (cf. chapitre 4 section 4.4.1, page 101 ). Cette configuration réside en cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. Ce modèle est ensuite fourni aux utilisateurs pour leur permettre de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. À partir des ces exigences, une application serveur (appelée nœud de collecte) est générée et configurée fournissant un environnement dédié à la gestion des campagnes de collecte des utilisateurs. En ce qui concerne le passage à l’échelle de la plate-forme, nous avons proposé une architecture décentralisée, séparant les préoccupations du déploiement ainsi que de la 161collecte et l’analyse des données (cf. chapitre 4 section 4.2, page 92 ). L’architecture résultante est composée d’un ensemble de nœuds de collecte et d’un serveur central. Dans cette architecture, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrés au préalable. Les nœuds de collecte, quant à eux, fournissent un environnement dédié permettant aux utilisateurs de développer de nouvelles tâches de collecte, de les déployer auprès du serveur central, et d’exploiter les données qui ont été collectées durant l’exécution des tâches de collecte. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire (cf. chapitre 4 section 4.5, page 113 ). L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. 7.3 perspectives Dans cette section, nous présentons un ensemble de pistes de développement et de recherche en lien avec les travaux présentés dans cette thèse. Une première contribution au développement d’APISENSE® serait dans un premier temps de porter l’application mobile sur les divers systèmes d’exploitation mobiles disponibles sur le marché (par ex. iOS, Windows Mobile). Bien que nous avons effectué une preuve de concept de la portabilité de l’application mobile d’APISENSE® sur iOS, le prototype réalisé n’est pas encore opérationnel pour être déployé à grande échelle. 162Concernant la partie serveur de APISENSE®, plusieurs améliorations à court terme peuvent être envisagées. La première concerne la sécurité lors de la propagation des données des dispositifs vers les nœuds de collecte. En effet, actuellement l’emplacement du participant peut être déterminé en identifiant l’adresse IP du point d’accès utilisé pour propager les données, permettant potentiellement d’identifier son domicile même si les données en elles-mêmes ne permettent pas de révéler cette information. Dans ce contexte, une priorité serait d’utiliser des routeurs ou relais spécifiques (par ex. routeur oignon [18]) pour cacher l’adresse IP lors de la propagation des données. Une autre amélioration à court terme serait d’intégrer des outils de visualisation génériques permettant de rapidement explorer les données collectées à travers une Interface web. Par exemple, il serait intéressant d’établir des connexions entre les nœuds de collecte et des services tels que CartoDB 1 ou Google Fusion Tables 2 qui proposent ce type de fonctionnalité. Une autre amélioration serait de supporter le déploiement automatique des nœuds de collecte vers les infrastructures des utilisateurs. Cette tâche reste encore manuelle et peut demander une certaine expertise pour administrer le système responsable de leurs exécutions. Certains travaux dans notre équipe ont déjà été initiés dans ce sens [53, 54] et nous prévoyons de rapidement les intégrer dans APISENSE®. D’autres pistes de développement seraient d’implémenter les différents modèles de protection de la vie privée et de récompense proposés dans la littérature. Dans ce contexte, il serait intéressant de déployer des campagnes utilisant ces différents modèles sur des échantillons de participants, afin d’évaluer leurs impacts sur leurs participations. Nous pensons que APISENSE® peut être une plate-forme idéale pour permettre aux scientifiques travaillant sur ces problématiques pour les aider à mettre au point et valider leurs algorithmes. Bien que le modèle de programmation proposé dans cette thèse fournisse une abstraction complète des technologies mobiles, une expertise en programmation est quand même nécessaire pour le développement des tâches de collecte. Dans ce contexte, il pourrait être intéressant de proposer un niveau d’abstraction encore plus élevé ne nécessitant aucune expertise. Ce niveau d’abstraction peut s’appuyer par exemple sur certains travaux déjà existant comme App Inventor 3 ou Alice [15] qui proposent 1. http://cartodb.com 2. http://tables.googlelabs.com 3. http://appinventor.mit.edu 163des métaphores visuelles pour le développement des applications, ou encore sur le langage naturel. Dans ce contexte, le modèle de programmation que nous avons proposé pourrait être utilisé comme langage pivot avec ce nouveau niveau d’abstraction. Une autre perspective serait de mettre en place des métriques permettant d’évaluer la qualité des données collectées. Très peu de recherche ont encore été menées dans ce sens, bien que cela représente une problématique importante de ce type d’applications. En effet, de nombreux facteurs peuvent influer sur la qualité des données comme le type de matériel utilisé, la mobilité des utilisateurs, etc. En effet, sans connaître le niveau de fiabilité des données, il peut être très difficile de savoir si les données collectées sont représentatives du monde réel ou du comportement des participants. La mise en place de ces métriques pourrait également permettre de mettre en place de nouveaux modèles de recrutement des participants dans les campagnes de collecte. Dans ce contexte, selon les exigences de la campagne, les participants fournissant les données de plus grande qualité pourraient être privilégiés. Dans cette thèse, nous avons particulièrement investi sur le développement d’un système de collecte de données avec APISENSE®. Cependant, la collecte en elle même ne représente qu’une partie des futurs systèmes d’informations se basant sur le pouvoir de la foule pour atteindre une quantité massive de données. De nombreux défis doivent encore être relevés pour traiter ces données, en extraire des comportements complexes et diffuser des informations en temps réel à partir de leurs analyses [68]. Un cas d’utilisation que nous souhaitons investir est l’utilisation du Mobile crowdsensing pour élaborer un système de détection de tremblement de terre. Certaines initiatives ont déjà vu le jour comme le projet Quake-Catcher Network [13], qui permet de recueillir les données issues des capteurs de mouvement présents dans les disques durs des ordinateurs, transformant alors ceux-ci en sismographes. Comme mentionné par Faulkner et al. [23], cette approche peut être complétée en utilisant les accéléromètres intégrés dans les dispositifs mobiles qui peuvent fournir une mesure plus précise et plus complète de la distribution géographique des secousses lors d’un tremblement de terre. Cependant, développer un système fiable, capable d’analyser continuellement les données produites par des centaines de milliers de capteurs, extraire uniquement les informations pertinentes et propager une alerte sismique seulement en quelques secondes restent actuellement un véritable défi. 164B I B L I O G R A P H I E [1] Nadav Aharony, Wei Pan, Cory Ip, Inas Khayal, and Alex Pentland. Social fmri : Investigating and shaping social mechanisms in the real world. Pervasive and Mobile Computing, 7(6) :643–659, 2011. [2] Marc P Armstrong, Gerard Rushton, Dale L Zimmerman, et al. Geographically masking health data to preserve confidentiality. Statistics in medicine, 18(5) :497–525, 1999. [3] Patrick Baier, Frank Durr, and Kurt Rothermel. Psense : Reducing energy consumption in public sensing systems. In Advanced Information Networking and Applications (AINA),26th International Conference on, pages 136–143. IEEE, 2012. [4] Rajesh Krishna Balan, Khoa Xuan Nguyen, and Lingxiao Jiang. Real-time trip information service for a large taxi fleet. In Proceedings of the 9th international conference on Mobile systems, applications, and services, pages 99–112. ACM, 2011. [5] Niranjan Balasubramanian, Aruna Balasubramanian, and Arun Venkataramani. Energy consumption in mobile phones : a measurement study and implications for network applications. In Proceedings of the 9th conference on Internet measurement conference, pages 280–293. ACM, 2009. [6] Niels Brouwers and Koen Langendoen. Pogo, a middleware for mobile phone sensing. In Proceedings of the 13th International Middleware Conference, pages 21–40. Springer-Verlag New York, Inc., 2012. [7] J Burke, D Estrin, M Hansen, A Parker, N Ramanathan, S Reddy, and MB Srivastava. Participatory sensing. In In : Workshop on World-Sensor-Web (WSW’06) : Mobile Device Centric Sensor Networks and Applications, 2006. [8] Iacopo Carreras, Daniele Miorandi, Andrei Tamilin, Emmanuel R Ssebaggala, and Nicola Conci. Matador : Mobile task detector for context-aware crowd-sensing campaigns. In Pervasive Computing and Communications Workshops (PERCOM Workshops), International Conference on, pages 212–217. IEEE, 2013. 165[9] Guanling Chen, David Kotz, et al. A survey of context-aware mobile computing research. Technical report, Technical Report TR2000-381, Dept. of Computer Science, Dartmouth College, 2000. [10] NM Chowdhury and Raouf Boutaba. A survey of network virtualization. Computer Networks, 54(5) :862–876, 2010. [11] Delphine Christin, Andreas Reinhardt, Salil S Kanhere, and Matthias Hollick. A survey on privacy in mobile participatory sensing applications. Journal of Systems and Software, 84(11) :1928–1946, 2011. [12] Paul Clements and Linda Northrop. Software product lines : practices and patterns. 2002. [13] Elizabeth S Cochran, Jesse F Lawrence, Carl Christensen, and Ravi S Jakka. The quake-catcher network : Citizen science expanding seismic horizons. Seismological Research Letters, 80(1) :26–30, 2009. [14] Ionut Constandache, Shravan Gaonkar, Matt Sayler, Romit Roy Choudhury, and Landon Cox. Enloc : Energy-efficient localization for mobile phones. In INFOCOM, pages 2716–2720. IEEE, 2009. [15] Stephen Cooper, Wanda Dann, and Randy Pausch. Teaching objects-first in introductory computer science. In ACM SIGCSE Bulletin, volume 35, pages 191–195. ACM, 2003. [16] Tathagata Das, Prashanth Mohan, Venkata N Padmanabhan, Ramachandran Ramjee, and Asankhaya Sharma. Prism : platform for remote sensing using smartphones. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 63–76. ACM, 2010. [17] Linda Deng and Landon P Cox. Livecompare : grocery bargain hunting through participatory sensing. In Proceedings of the 10th workshop on Mobile Computing Systems and Applications, page 4. ACM, 2009. [18] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor : The secondgeneration onion router. Technical report, DTIC Document, 2004. [19] Prabal Dutta, Paul M Aoki, Neil Kumar, Alan Mainwaring, Chris Myers, Wesley Willett, and Allison Woodruff. Common sense : participatory urban sensing using 166a network of handheld air quality monitors. In Proceedings of the 7th ACM conference on embedded networked sensor systems, pages 349–350. ACM, 2009. [20] Shane B Eisenman, Emiliano Miluzzo, Nicholas D Lane, Ronald A Peterson, GahngSeop Ahn, and Andrew T Campbell. Bikenet : A mobile sensing system for cyclist experience mapping. ACM Transactions on Sensor Networks (TOSN), 6(1) :6, 2009. [21] Patrick Th Eugster, Pascal A Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The many faces of publish/subscribe. ACM Computing Surveys (CSUR), 35(2) : 114–131, 2003. [22] Hossein Falaki, Ratul Mahajan, and Deborah Estrin. Systemsens : a tool for monitoring usage in smartphone research deployments. In Proceedings of the sixth international workshop on MobiArch, pages 25–30. ACM, 2011. [23] Matthew Faulkner, Michael Olson, Rishi Chandy, Jonathan Krause, K Mani Chandy, and Andreas Krause. The next big one : Detecting earthquakes and other rare events from community-based sensors. In Information Processing in Sensor Networks (IPSN), 2011 10th International Conference on, pages 13–24. IEEE, 2011. [24] Zachary Fitz-Walter and Dian Tjondronegoro. Exploring the opportunities and challenges of using mobile sensing for gamification. In Proceedings of the 13th International Conference on Ubiquitous Computing (UbiComp’11) : Workshop on Mobile Sensing, 2011. [25] Jon Froehlich, Mike Y Chen, Sunny Consolvo, Beverly Harrison, and James A Landay. Myexperience : a system for in situ tracing and capturing of user feedback on mobile phones. In Proceedings of the 5th international conference on Mobile systems, applications and services, pages 57–70. ACM, 2007. [26] Sébastien Gambs, Marc-Olivier Killijian, and Miguel Núñez del Prado Cortez. Show me how you move and i will tell you who you are. In Proceedings of the 3rd ACM SIGSPATIAL International Workshop on Security and Privacy in GIS and LBS, pages 34–41. ACM, 2010. [27] Raghu K Ganti, Fan Ye, and Hui Lei. Mobile crowdsensing : Current state and future challenges. Communications Magazine, IEEE, 49(11) :32–39, 2011. [28] Chunming Gao, Fanyu Kong, and Jindong Tan. Healthaware : Tackling obesity with health aware smart phone systems. In Robotics and Biomimetics (ROBIO), 2009 IEEE International Conference on, pages 1549–1554. IEEE, 2009. 167[29] Shravan Gaonkar, Jack Li, Romit Roy Choudhury, Landon Cox, and Al Schmidt. Micro-blog : sharing and querying content through mobile phones and social participation. In Proceedings of the 6th international conference on Mobile systems, applications, and services, pages 174–186. ACM, 2008. [30] Kuan Lun Huang, Salil S Kanhere, and Wen Hu. Preserving privacy in participatory sensing systems. Computer Communications, 33(11) :1266–1280, 2010. [31] Anil K Jain and Richard C Dubes. Algorithms for clustering data. Prentice-Hall, Inc., 1988. [32] Kyo C Kang, Sholom G Cohen, James A Hess, William E Novak, and A Spencer Peterson. Feature-oriented domain analysis (foda) feasibility study. Technical report, DTIC Document, 1990. [33] Wazir Zada Khan, Yang Xiang, Mohammed Y Aalsalem, and Quratulain Arshad. Mobile phone sensing systems : a survey. Communications Surveys & Tutorials, IEEE, 15(1) :402–427, 2013. [34] Donnie H Kim, Younghun Kim, Deborah Estrin, and Mani B Srivastava. Sensloc : sensing everyday places and paths using less energy. In Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems, pages 43–56. ACM, 2010. [35] Stephen F King and Paul Brown. Fix my street or else : using the internet to voice local public service concerns. In Proceedings of the 1st international conference on Theory and practice of electronic governance, pages 72–80. ACM, 2007. [36] John Krumm. A survey of computational location privacy. Personal and Ubiquitous Computing, 13(6) :391–399, 2009. [37] Jennifer R Kwapisz, Gary M Weiss, and Samuel A Moore. Activity recognition using cell phone accelerometers. ACM SigKDD Explorations Newsletter, 12(2) :74–82, 2011. [38] Nicholas D Lane, Shane B Eisenman, Mirco Musolesi, Emiliano Miluzzo, and Andrew T Campbell. Urban sensing systems : opportunistic or participatory ? In Proceedings of the 9th workshop on Mobile computing systems and applications, pages 11–16. ACM, 2008. 168[39] Nicholas D Lane, Emiliano Miluzzo, Hong Lu, Daniel Peebles, Tanzeem Choudhury, and Andrew T Campbell. A survey of mobile phone sensing. Communications Magazine, IEEE, 48(9) :140–150, 2010. [40] Juong-Sik Lee and Baik Hoh. Dynamic pricing incentive for participatory sensing. Pervasive and Mobile Computing, 6(6) :693–708, 2010. [41] Juong-Sik Lee and Baik Hoh. Sell your experiences : a market mechanism based incentive for participatory sensing. In Pervasive Computing and Communications (PerCom), 2010 IEEE International Conference on, pages 60–68. IEEE, 2010. [42] P Lilly. Mobile devices to outnumber global population by 2017. URL http ://tinyurl. com/pbodtus [Accessedon : 2013-08-06]. [43] Kaisen Lin, Aman Kansal, Dimitrios Lymberopoulos, and Feng Zhao. Energyaccuracy trade-off for continuous mobile device location. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 285–298. ACM, 2010. [44] Pengfei Liu, Yanhua Chen, Wulei Tang, and Qiang Yue. Mobile weka as data mining tool on android. In Advances in Electrical Engineering and Automation, pages 75–80. Springer, 2012. [45] Hong Lu, Nicholas D Lane, Shane B Eisenman, and Andrew T Campbell. Bubblesensing : Binding sensing tasks to the physical world. Pervasive and Mobile Computing, 6(1) :58–71, 2010. [46] C Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter F Brown, Rebekah Metz, and Booz Allen Hamilton. Reference model for service oriented architecture 1.0. OASIS Standard, 12, 2006. [47] Nicolas Maisonneuve, Matthias Stevens, Maria E Niessen, and Luc Steels. Noisetube : Measuring and mapping noise pollution with mobile phones. In Information Technologies in Environmental Engineering, pages 215–228. Springer, 2009. [48] David J Malan and Henry H Leitner. Scratch for budding computer scientists. ACM SIGCSE Bulletin, 39(1) :223–227, 2007. [49] Emiliano Miluzzo, Nicholas D Lane, Kristóf Fodor, Ronald Peterson, Hong Lu, Mirco Musolesi, Shane B Eisenman, Xiao Zheng, and Andrew T Campbell. Sensing meets mobile social networks : the design, implementation and evaluation of the 169cenceme application. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 337–350. ACM, 2008. [50] Prashanth Mohan, Venkata N Padmanabhan, and Ramachandran Ramjee. Nericell : rich monitoring of road and traffic conditions using mobile smartphones. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 323–336. ACM, 2008. [51] Min Mun, Sasank Reddy, Katie Shilton, Nathan Yau, Jeff Burke, Deborah Estrin, Mark Hansen, Eric Howard, Ruth West, and Péter Boda. Peir, the personal environmental impact report, as a platform for participatory sensing systems research. In Proceedings of the 7th international conference on Mobile systems, applications, and services, pages 55–68. ACM, 2009. [52] Klaus Pohl, Günter Böckle, and Frank Van Der Linden. Software product line engineering : foundations, principles, and techniques. Springer, 2005. [53] Clément Quinton, Romain Rouvoy, and Laurence Duchien. Leveraging feature models to configure virtual appliances. In Proceedings of the 2nd International Workshop on Cloud Computing Platforms, page 2. ACM, 2012. [54] Clément Quinton, Nicolas Haderer, Romain Rouvoy, and Laurence Duchien. Towards multi-cloud configurations using feature models and ontologies. In Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds, pages 21–26. ACM, 2013. [55] Moo-Ryong Ra, Bin Liu, Tom F La Porta, and Ramesh Govindan. Medusa : A programming framework for crowd-sensing applications. In Proceedings of the 10th international conference on Mobile systems, applications, and services, pages 337–350. ACM, 2012. [56] Kiran K Rachuri, Mirco Musolesi, Cecilia Mascolo, Peter J Rentfrow, Chris Longworth, and Andrius Aucinas. Emotionsense : a mobile phones based adaptive platform for experimental social psychology research. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 281–290. ACM, 2010. [57] Sasank Reddy, Deborah Estrin, Mark Hansen, and Mani Srivastava. Examining micro-payments for participatory sensing data collections. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 33–36. ACM, 2010. 170[58] Mitchel Resnick, John Maloney, Andrés Monroy-Hernández, Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, Jay Silver, Brian Silverman, et al. Scratch : programming for all. Communications of the ACM, 52 (11) :60–67, 2009. [59] Xiang Sheng, Jian Tang, and Weiyi Zhang. Energy-efficient collaborative sensing with mobile phones. In INFOCOM, 2012 Proceedings IEEE, pages 1916–1924. IEEE, 2012. [60] Xiang Sheng, Xuejie Xiao, Jian Tang, and Guoliang Xue. Sensing as a service : A cloud computing system for mobile phone sensing. In Sensors, 2012 IEEE, pages 1–4. IEEE, 2012. [61] Clayton Shepard, Ahmad Rahmati, Chad Tossell, Lin Zhong, and Phillip Kortum. Livelab : measuring wireless networks and smartphone users in the field. ACM SIGMETRICS Performance Evaluation Review, 38(3) :15–20, 2011. [62] Minho Shin, Cory Cornelius, Dan Peebles, Apu Kapadia, David Kotz, and Nikos Triandopoulos. Anonysense : A system for anonymous opportunistic sensing. Pervasive and Mobile Computing, 7(1) :16–30, 2011. [63] Sebastian Sonntag, Lennart Schulte, and Jukka Manner. Mobile network measurements-it’s not all about signal strength. In Wireless Communications and Networking Conference (WCNC), 2013 IEEE, pages 4624–4629. IEEE, 2013. [64] Latanya Sweeney. k-anonymity : A model for protecting privacy. International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 10(05) :557–570, 2002. [65] Emiliano Trevisani and Andrea Vitaletti. Cell-id location technique, limits and benefits : an experimental study. In Mobile Computing Systems and Applications (WMCSA). Sixth IEEE Workshop on, pages 51–60. IEEE, 2004. [66] Yu Xiao, Pieter Simoens, Padmanabhan Pillai, Kiryong Ha, and Mahadev Satyanarayanan. Lowering the barriers to large-scale mobile crowdsensing. In Proceedings of the 14th Workshop on Mobile Computing Systems and Applications, page 9. ACM, 2013. [67] Jing Yuan, Yu Zheng, Xing Xie, and Guangzhong Sun. Driving with knowledge from the physical world. In Proceedings of the 17th ACM SIGKDD international conference on Knowledge discovery and data mining, pages 316–324. ACM, 2011. 171[68] Arkady Zaslavsky, Charith Perera, and Dimitrios Georgakopoulos. Sensing as a service and big data. arXiv preprint arXiv :1301.0159, 2013. [69] Gabe Zichermann and Christopher Cunningham. Gamification by design : Implementing game mechanics in web and mobile apps. " O’Reilly Media, Inc.", 2011. 172173 Modélisation d’une architecture orientée service et basée composant pour une couche de Transport autonome, dynamique et hautement configurable Guillaume DUGUE To cite this version: Guillaume DUGUE. Mod´elisation d’une architecture orient´ee service et bas´ee composant pour une couche de Transport autonome, dynamique et hautement configurable. Networking and Internet Architecture. Institut National des Sciences Appliqu´ees de Toulouse (INSA Toulouse), 2014. French. HAL Id: tel-01079998 https://tel.archives-ouvertes.fr/tel-01079998 Submitted on 4 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE En vue de l’obtention du DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE Délivré par : l’Institut National des Sciences Appliquées de Toulouse (INSA de Toulouse) Présentée et soutenue le 24/09/2014 par : ●✉✐❧❧❛✉♠❡ ❉✉❣✉é Modélisation d’une architecture orientée service et basée composant pour une couche de Transport autonome, dynamique et hautement configurable JURY Christian Fraboul Professeur Président du jury Abdelhamid Mellouk Professeur Rapporteur Philippe Roose Maître de conférence HDR Rapporteur Michaël Mrissa Maître de conférence Examinateur Nicolas Van Wambeke Ingénieur docteur Examinateur Christophe Chassot Professeur Directeur de thèse Khalil Drira Directeur de recherches Co-directeur de thèse Ernesto Exposito Maître de conférence HDR Invité École doctorale et spécialité : MITT : Domaine STIC : Réseaux, Télécoms, Systèmes et Architecture Unité de Recherche : Laboratoire d’Analyse et d’Architecture des Systèmes (UPR 8001) Directeur(s) de Thèse : Christophe Chassot et Khalil Drira Rapporteurs : Abdelhamid Mellouk et Philippe RooseRemerciements Les travaux présentés dans ce documents ont été réalisés au Laboratoire d’Analyse et d’Architecture des Systèmes du Centre National de la Recherche Scienti- fique (LAAS-CNRS), dont la direction a été successivement assurée par MM. R. Chatila, J.-L. Sanchez et J. Arlat que je tiens à remercier pour leur accueil. Mes remerciements vont aussi à M. F. Vernadat, initialement directeur du groupe Outils et logiciels pour la Communication (OLC), et à M. K. Drira, directeur de l’équipe Services et Architectures pour les Réseaux Avancés (SARA), structures au sein desquelles j’ai travaillé. Mes travaux ont été dirigés par MM. C. Chassot et K. Drira, que je tiens à remercier pour leurs retours et leurs conseils tout au long de ce travail. Leur expérience et leur accompagnement dans mes réflexions et mon évolution tant personnelle que professionnelle et scientifique m’ont été d’une grande aide. Les rapporteurs de ce document sont MM. A. Mellouk et P. Roose que je remercie d’avoir accepté cette charge. Je remercie les autres membres du jury, MM. M. Mrissa et N. Van Wambeke et particulièrement M. C. Fraboul qui a accepté d’en être le président. Je tiens à remercier aussi MM. C. Diop et M. Oulmahdi pour leur concours dans mes travaux, ainsi que M. N. Van Wambeke qui a toujours su être disponible en cas de besoin, dans la bonne humeur et ce même après plusieurs années. Je remercie également mes collègues, Silvia, Cédric, Lionel, Guillaume, Denis, Marc et tous les autres avec qui j’ai partagé les bons et moins bons moments et qui ont toujours su faire preuve de soutien dans cette aventure qu’eux aussi traversent ou ont traversé. Je tiens à exprimer également ma gratitude à Mme Garaïos dont le travail m’a permis d’avancer à pas de géant et sans lequel je ne pourrais pas être là où je suis aujourd’hui. Merci à mes amis et ma famille qui ont su faire preuve d’une présence sans faille, notamment mes parents qui ont su m’écouter chaque fois que j’en avais besoin, et Orélie qui m’a supporté avec courage pendant quatre années. Merci à tous car c’est à vous que je dois d’être arrivé jusque là !Résumé L’évolution des réseaux et des applications distribuées liée au développement massif de l’utilisation de l’Internet par le grand public a conduit à de nombreuses propositions, standardisées ou non, de nouveaux protocoles de Transport et à l’évolution des protocoles existants (TCP notamment), destinées à prendre en compte les nouveaux besoins en qualité de service (QoS) des applications et les caractéristiques nouvelles des réseaux sousjacents. Cependant, force est de constater que ces différentes propositions, quoi que pertinentes, ne se sont pas traduites dans les faits et que le protocole TCP reste ultra majoritairement utilisé en dépit de ses limites conceptuelles connues. Ainsi, alors que le contexte applicatif et réseau a évolué de façon extrêmement forte, les solutions protocolaires utilisées au niveau Transport restent sous optimales et conduisent à des performances moindres en termes de QoS, que celles auxquelles permettraient de prétendre les nouvelles solutions. Dans ce contexte, ce document analyse tout d’abord le pourquoi de ce constat en dégageant cinq points de problématique qui justifie la difficulté, et que nous exprimons en termes de complexité (d’utilisation), d’extensibilité, de configurabilité, de dépendance et de déploiement. Sur ces bases, et en réponse à la problématique générale, la contribution de cette thèse consiste non pas à proposer une nouvelle solution protocolaire pour le niveau Transport, mais à redéfinir l’architecture et le fonctionnement de la couche Transport et ses interactions avec les applications. Cette nouvelle couche Transport, que nous avons appelée Autonomic Transport Layer (ATL), vise à permettre l’intégration transparente de solutions protocolaires existantes et futures pour les niveaux supérieurs et inférieurs de la pile protocolaire tout en simplifiant son utilisation par une augmentation du taux d’abstraction du réseau (au sens large) du point de vue des développeurs d’applications. Afin de décharger ces derniers de la complexité d’utilisation des multiples solutions envisageables au niveau Transport, notre solution intègre des principes d’autonomie lui permettant une prise de décision du / des protocoles de Transport à invoquer sans intervention extérieure, et une dynamicité dans l’adaptation de la solution retenue en cours de communication afin de toujours délivrer le meilleur niveau de QoS aux applications quelles que soient les évolutions du contexte applicatif et réseau en cours de communication. Après un état de l’art confrontant les solutions actuelles aux points de problématique identifiés, ce document présente les principes fondamentaux de l’ATL, ainsi que son architecture globale suivant une méthodologie basée sur le formalisme UML 2.0. Deux cas d’utilisation fondamentaux sont ensuite introduits pour décrire l’ATL d’un point de vue comportemental. Finalement, nous présentons différents résultats de mesures de performances attestant de l’utilité d’une solution telle que l’ATL. iAbstract The massive development of Internet and its usage by the public and the subsequent evolution in networks and distributed applications lead to numerous proposals, standardized or not, of new Transport protocols and changes in existing ones (such as TCP) in order to take into account new arising Quality of Service (QoS) applicative needs and the new characteristics of underlying networks. However, no matter how relevant those new solutions are, they are not meeting the success they should because of TCP’s preponderance and overuse in spite of all its well known limits. Therefore, while applications and underlying networks have evolved tremendously, Transport protocols are becoming suboptimal and lead to lesser performances in terms of QoS than what one could expect from newer Transport solutions. In this context the present document analyses the reasons of this situations by indentifying five problematic points which we express in terms of complexity (of use), extensibility, configurability, dependence and deployment. Upon this basis, and trying to address the main problematic, this thesis contribution is not to propose yet another new Transport protocol but to redefine how the Transport Layer operates, its architecture and its interactions with applications. This new Transport Layer, which we call the Autonomic Transport Layer (ATL) aims for transparent integration of existing and future protocol solutions from the upper and lower layers’ point of view as long as simplifying its use by offering a better, wider network abstraction to application developers. To discharge them the complexity of use of the numerous solutions at the Transport level, our solutions integrates autonomy principles to give it decision power over the protocol(s) to instantiate without external intervention and dynamicity so as to be able to adapt the chosen solution during the communication so that it always delivers the best QoS level to applications whatever the contextual evolutions might be for applications or for the network. After a state of the art confronting the current solutions to the different problematic points we identified, this document presents the fundamental principles of the ATL and its global architecture described using UML 2.0. Two major use cases are then introduced to describe the ATL’s behavior. Finally we present several performance figures as evidence of the relevance of a solution such as the ATL. iiiTable des matières Table des matières 1 Table des figures 5 Liste des tableaux 7 Introduction générale 9 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Structure du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1 Contexte, Problématique, État de l’art et Positionnement 13 1.1 Contexte et Problématique . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.1.1 Évolution des réseaux . . . . . . . . . . . . . . . . 15 1.1.1.2 Évolution des terminaux . . . . . . . . . . . . . . . 17 1.1.1.3 Évolution des applications . . . . . . . . . . . . . . 17 1.1.1.4 Évolution des protocoles de Transport . . . . . . . 18 1.1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.1.2.1 Acteurs concernés . . . . . . . . . . . . . . . . . . 20 1.1.2.2 Problèmes soulevés . . . . . . . . . . . . . . . . . . 21 1.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.1 Protocoles de Transport . . . . . . . . . . . . . . . . . . . . 24 1.2.1.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.1.2 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.2.1.3 DCCP . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.2.1.4 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.2.1.5 MPTCP . . . . . . . . . . . . . . . . . . . . . . . . 30 1.2.1.6 CTP . . . . . . . . . . . . . . . . . . . . . . . . . . 33 1.2.1.7 ETP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1.2.2 En résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1Table des matières 1.3 Positionnement de la proposition . . . . . . . . . . . . . . . . . . . 38 1.3.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 1.3.2 Exigences générales de conception de l’ATL . . . . . . . . . 39 1.3.3 Paradigmes de conception relatifs à l’architecture de l’ATL . 39 1.3.3.1 Conception logicielle basée composants . . . . . . . 40 1.3.3.2 Conception logicielle orientée service . . . . . . . . 40 1.3.3.3 Autonomic Computing . . . . . . . . . . . . . . . . 40 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2 Architecture de l’ATL 43 2.1 Exigences de conception et principes l’ATL . . . . . . . . . . . . . . 44 2.1.1 Exigences de conception de l’ATL . . . . . . . . . . . . . . . 44 2.1.2 Principes des solutions proposées en réponse aux exigences de conception de l’ATL . . . . . . . . . . . . . . . . . . . . . 46 2.1.3 Approches d’implantation de ces principes . . . . . . . . . . 48 2.1.3.1 Approche orientée services . . . . . . . . . . . . . . 48 2.1.3.2 Approche basée composants . . . . . . . . . . . . . 50 2.1.3.3 Approche autonomique . . . . . . . . . . . . . . . . 51 2.1.3.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . 51 2.1.4 Fonctionnalités de l’ATL . . . . . . . . . . . . . . . . . . . . 53 2.1.4.1 Fonction de gestion des services . . . . . . . . . . . 53 2.1.4.2 Fonction de gestion autonomique de la communication . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.1.4.3 Fonction d’accueil, d’assemblage et de mise en œuvre des compositions . . . . . . . . . . . . . . . . . . . 54 2.2 Architecture de l’ATL . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.2.1 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.2.2 Modèle d’architecture de l’ATL . . . . . . . . . . . . . . . . 57 2.2.2.1 Modèle général . . . . . . . . . . . . . . . . . . . . 58 2.2.3 Composants de base de l’ATL . . . . . . . . . . . . . . . . . 60 2.2.3.1 Le Flow . . . . . . . . . . . . . . . . . . . . . . . . 60 2.2.3.2 L’Autonomic Manager . . . . . . . . . . . . . . . . 62 2.2.3.3 Le Data Plan . . . . . . . . . . . . . . . . . . . . . 66 2.2.3.4 Intégrateur des services et base de connaissances . 68 2.2.4 Composants secondaires . . . . . . . . . . . . . . . . . . . . 69 2.2.4.1 Flow Creator . . . . . . . . . . . . . . . . . . . . . 69 2.2.4.2 Signalization Message Controler . . . . . . . . . . 69 2.2.4.3 Multiplexage-démultiplexage entre couche réseau et Flow . . . . . . . . . . . . . . . . . . . . . . . . 70 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2Table des matières 3 Description comportementale de l’ATL 73 3.1 Création d’un point d’accès au service de Transport . . . . . . . . . 74 3.1.1 Instanciation d’un Flow . . . . . . . . . . . . . . . . . . . . 74 3.1.2 Application cliente . . . . . . . . . . . . . . . . . . . . . . . 76 3.1.2.1 Application legacy . . . . . . . . . . . . . . . . . . 77 3.1.2.2 Application ATL-aware . . . . . . . . . . . . . . . 79 3.1.2.3 Application smart . . . . . . . . . . . . . . . . . . 80 3.1.3 Application serveur . . . . . . . . . . . . . . . . . . . . . . . 80 3.1.3.1 Application legacy . . . . . . . . . . . . . . . . . . 80 3.1.3.2 Application ATL-aware . . . . . . . . . . . . . . . 81 3.1.3.3 Application smart . . . . . . . . . . . . . . . . . . 81 3.1.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.2 Reconfiguration d’un Flow . . . . . . . . . . . . . . . . . . . . . . . 83 3.2.1 Déroulement d’une reconfiguration . . . . . . . . . . . . . . 83 3.2.1.1 Classification des cas de reconfiguration possibles . 83 3.2.1.2 Suivi du plan de reconfiguration . . . . . . . . . . . 84 3.2.1.3 Déroulement selon les cas . . . . . . . . . . . . . . 85 3.3 Traitement des retransmissions lors des transitions . . . . . . . . . . 88 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4 Expérimentations et mesures 91 4.1 De la composabilité des protocoles . . . . . . . . . . . . . . . . . . . 92 4.1.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . . . . 92 4.1.2 Description de l’expérience . . . . . . . . . . . . . . . . . . . 93 4.1.2.1 Choix de l’application . . . . . . . . . . . . . . . . 93 4.1.2.2 Micro-protocoles utilisés . . . . . . . . . . . . . . . 94 4.1.2.3 Simulation . . . . . . . . . . . . . . . . . . . . . . 95 4.1.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . 97 4.1.3.1 Comparaison des performances de MPTCP avec TCP et UDP . . . . . . . . . . . . . . . . . . . . . 97 4.1.3.2 Comparaison de MPTCP avec et sans mécanismes couplés . . . . . . . . . . . . . . . . . . . . . . . . 98 4.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.2 De l’intérêt de l’adaptation dynamique . . . . . . . . . . . . . . . . 102 4.2.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . . . . 103 4.2.2 Description de l’expérience . . . . . . . . . . . . . . . . . . . 103 4.2.2.1 Choix de l’application . . . . . . . . . . . . . . . . 103 4.2.2.2 Micro-protocoles . . . . . . . . . . . . . . . . . . . 103 4.2.2.3 Simulation . . . . . . . . . . . . . . . . . . . . . . 104 4.2.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . 104 4.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3Table des matières 4.3 De l’overhead de la signalisation . . . . . . . . . . . . . . . . . . . . 106 4.3.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . . . . 106 4.3.2 Description de l’expérience . . . . . . . . . . . . . . . . . . . 107 4.3.2.1 Plateforme de test . . . . . . . . . . . . . . . . . . 107 4.3.2.2 Protocoles de signalisation . . . . . . . . . . . . . . 108 4.3.2.3 Protocole expérimental . . . . . . . . . . . . . . . . 112 4.3.3 Résultats attendus . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Conclusion générale 121 Rappel des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Flux collaboratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 A Publications de l’auteur 125 A.1 Revue internationale avec actes et comité de lecture . . . . . . . . . 125 A.2 Conférences et workshop internationaux avec actes et comité de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Acronymes 127 Bibliographie 129 4Table des figures 1.1 L’environnement présente aujourd’hui des solutions multiples à des situations multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2 Décomposition des fonctions de transport . . . . . . . . . . . . . . . . 31 1.3 Décomposition de MPTCP en sous-couches . . . . . . . . . . . . . . . 32 1.4 Organisation schématique d’ETP . . . . . . . . . . . . . . . . . . . . . 35 2.1 Cas d’utilisation impliquant les applications . . . . . . . . . . . . . . . 55 2.2 Cas d’utilisation impliquant les utilisateurs humains . . . . . . . . . . . 56 2.3 Diagramme de structure composite de premier niveau . . . . . . . . . . 59 2.4 Composition d’un Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.5 Organisation des fonctions de l’Autonomic Manager . . . . . . . . . . . 63 2.6 Caractéristiques du Touchpoint et lien avec l’Autonomic Manager . . . 64 2.7 La composition du Data Plan . . . . . . . . . . . . . . . . . . . . . . . 67 3.1 Une application de type aware ou smart ouvre un point d’accès au service de Transport via l’interface de contrôle de l’ATL . . . . . . . . 75 3.2 Diagramme de séquence de création d’un Flow . . . . . . . . . . . . . . 76 3.3 Instanciation d’un nouveau Flow . . . . . . . . . . . . . . . . . . . . . 77 3.4 Mécanisme de découverte de l’ATL . . . . . . . . . . . . . . . . . . . . 78 3.5 Suivi du plan de reconfiguration . . . . . . . . . . . . . . . . . . . . . . 86 4.1 La topologie du réseau simulé . . . . . . . . . . . . . . . . . . . . . . . 95 4.2 PNSR par image en utilisant MPTCP, scénario 4 . . . . . . . . . . . . 100 4.3 PNSR par image en utilisant MPTCP-PR, scénario 4 . . . . . . . . . . 101 4.4 PNSR par image en utilisant MPTCP-SD, scénario 4 . . . . . . . . . . 102 4.5 La topologie utilisée pour les tests . . . . . . . . . . . . . . . . . . . . . 107 4.6 Cas d’utilisation du protocole de synchronisation d’ETP . . . . . . . . 108 4.7 Diagramme de séquence du cas d’utilisation Distributed Sender Based . 110 4.8 Préparation à la reconfiguration . . . . . . . . . . . . . . . . . . . . . . 111 4.9 Caractéristiques des cinq environnements réseau et compositions associées113 4.10 Taux de pertes de l’environnement . . . . . . . . . . . . . . . . . . . . 115 4.11 Taux de pertes vu par le service de Transport . . . . . . . . . . . . . . 116 5Table des figures 4.12 Taux de pertes vu par le service sans système de reconfiguration . . . . 117 4.13 Délai induit par l’environnement . . . . . . . . . . . . . . . . . . . . . 118 4.14 Délai vu par le service . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.15 Délai vu par le service sans système de reconfiguration . . . . . . . . . 120 6Liste des tableaux 1.1 Résumé de la problématique . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2 Résumé du problème d’extensibilité . . . . . . . . . . . . . . . . . . . . 37 1.3 Résumé du problème de configurabilité . . . . . . . . . . . . . . . . . . 37 1.4 Résumé du problème d’assujettissement . . . . . . . . . . . . . . . . . 37 1.5 Résumé du problème de déploiement . . . . . . . . . . . . . . . . . . . 38 2.1 Synthèse des problèmes, exigences, principes et approches de conception de l’ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.1 Résumé des scénarios 1 et 2 . . . . . . . . . . . . . . . . . . . . . . . . 96 4.2 Résumé des scénarios 3 à 5 . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.3 Résumé des scénarios 6 et 7 . . . . . . . . . . . . . . . . . . . . . . . . 96 4.4 Les correspondances entre PNSR et MOS . . . . . . . . . . . . . . . . 97 4.5 PNSR moyen en dB des simulations 1 à 4 . . . . . . . . . . . . . . . . 97 4.6 PNSR moyen en dB des simulations 5 à 7 . . . . . . . . . . . . . . . . 98 4.7 Délai moyen en millisecondes des simulations 1 à 4 . . . . . . . . . . . 98 4.8 Délai moyen en millisecondes des simulations 5 à 7 . . . . . . . . . . . 98 4.9 Taux de pertes des simulations 1 à 4 . . . . . . . . . . . . . . . . . . . 98 4.10 Taux de pertes des simulations 5 à 7 . . . . . . . . . . . . . . . . . . . 99 4.11 Résumé des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.12 PNSR en dB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.13 PNSR obtenu sans et avec adaptation dynamique . . . . . . . . . . . . 105 7Introduction générale Contexte L’évolution du paysage numérique au cours de la dernière décennie a été radicale à différents niveaux. L’ouverture au grand public de l’Internet et l’explosion de son utilisation qui a suivi, ont ainsi considérablement modifié l’utilisation qui est faite du réseau. Les applications multimédia et interactives sont aujourd’hui plébiscitées et ajoutent aux transferts de fichiers classiques ceux de flux audio et vidéo et plus généralement des échanges de données possédant des contraintes temporelles fortes comme les jeux en ligne. Ces nouvelles applications créent de nouveaux besoins sur le transfert des flux d’informations échangés qui ne sont plus correctement pris en compte par les solutions protocolaires traditionnelles. Parallèlement les terminaux ont également suivi une évolution drastique, multipliant en leur sein les interfaces d’accès au réseau et donnant accès à de grandes capacités de stockage ou de puissance de calcul, y compris sur des machines nomades ou mobiles. Les parcs de serveurs (ou datacenters) sont devenus communs et permettent aux utilisateurs humains un accès continu et en tout lieu à leurs données personnelles. Ces machines et les communications qu’elles établissent offrent de nouvelles perspectives et créent ainsi de nouveaux contextes de besoins (en de débit ou de temps de transfert par exemple) pour lesquelles les protocoles actuels ne sont pas prévus. Enfin, les réseaux eux-mêmes ont profondément évolué, et permettent dorénavant le nomadisme et la mobilité des terminaux de façon généralisée. Dans tous les domaines, que les réseaux soient locaux ou longue distance, avec ou sans fil, les capacités ont été décuplées. De nouveaux types de systèmes intermédiaires, appelés middleboxes, ont également été introduits, créant des situations inédites (le blocage de protocoles non reconnus par exemple) auxquelles ont à faire face les développeurs de solutions protocolaires. Dans ce contexte et historiquement, les protocoles de Transport traditionnels de l’Internet, tels que TCP et UDP, ont connu plusieurs évolutions et adaptations et de nouvelles solutions ont vu le jour comme DCCP, SCTP at plus récemment 9Introduction générale MPTCP. Le paysage des solutions protocolaires s’est donc densifié et complexifié, contribuant à créer un nouveau contexte auquel il s’agit aujourd’hui de faire face. Problématique Ce nouveau contexte crée plusieurs points problématiques, tant du point de vue du développement d’applications que de la création de nouvelles solutions protocolaires. Le développement d’applications se heurte à un choix large et complexe de solutions protocolaires au niveau Transport, requérant une expertise complète des protocoles existants, tant vis-à-vis du choix du protocole à utiliser que de sa confi- guration afin d’en faire une utilisation optimale. Le développeur d’applications doit donc, en plus d’effectuer les choix de la solution et de sa configuration, implémenter la gestion du protocole même au sein de son application. Du point de vue du développeur de protocoles, la création protocolaire se heurte à deux problèmes majeurs. Le premier concerne l’extensibilité des protocoles existants. Toutes les solutions existantes ne permettent pas la création d’extensions. Certaines ne sont pas assez utilisées pour motiver la création de nouvelles options. Créer entièrement une nouvelle solution n’est pas plus aisé : en effet, celle-ci doit déjà être implémentée dans les différents systèmes d’exploitation, afin de permettre son utilisation au sein des différentes applications, qui doivent donc être mises à jour. Les middleboxes créent également des freins à l’adoption de nouvelles solutions protocolaires. Ces systèmes intervenant au niveau Transport, les nouvelles solutions doivent donc y être implémentées sous peine de se voir bloquées. De ce constat global, nous dégageons cinq points de problématique limitant l’évolution du paysage protocolaire actuel au niveau Transport, relatifs : à la complexité de choix et d’utilisation des protocoles, à la configurabilité des protocoles, à leur extensibilité, à l’assujetissement des applications aux solutions protocolaires et au déploiement des nouveaux protocoles Nous proposons dans ce manuscrit d’adresser ces cinq points via la redéfinition de l’architecture et du fonctionnement de la couche Transport actuelle, dans le but d’offrir un point d’accès générique au service de Transport qui laisse à l’application le soin de préciser le service qu’elle désire et non la solution à utiliser. Dans l’approche proposée, la solution protocolaire retenue est choisie de manière dynamique et autonome afin de fournir le service désiré par composition potentielle de plusieurs solutions protocolaires. Le but est d’offrir une abstraction plus poussée du réseau au sens large en déchargeant le développeur d’application de responsabilités qui ne devraient pas lui incomber. Le choix dynamique et autonome des solutions de Transport permet également de simplifier le déploiement de nouvelles solutions, 10rendant leur intégration transparente et leur adoption automatique à mesure que le déploiement progresse. Les contributions de ce manuscrit posent les bases architecturales et comportementales d’une telle couche de Transport que nous appelons Autonomic Transport Layer (ATL). Structure du document Le présent document est divisé en quatre chapitres. Le premier chapitre expose en détails le contexte dans lequel s’inscrivent les travaux présentés avant d’expliquer plus avant les cinq points de problématiques identifiés. Un état de l’art des solutions de Transport est ensuite exposé, décrivant le fonctionnement de différents protocoles classiques comme TCP, UDP, DCCP ou SCTP, ainsi que des solutions plus récentes ou en cours d’étude comme MPTCP, CTP ou ETP. Chacun de ces protocoles est confronté aux différents points de la problématique. Nous en déduisons les limites des solutions actuelles qui nous mènent à introduire l’approche d’une architecture nouvelle pour la couche Transport, à la fois orientée services, basée composants et dotée de capacités d’autonomie vis-à-vis des choix de composition à entreprendre pour répondre aux besoins des applications actuelles, dites legacy, et de celles à venir, conscientes de l’ATL. Le deuxième chapitre décrit le modèle architectural de l’ATL, c’est-à-dire la structure composite et le rôle de chaque composant nécessaire au fonctionnement de l’ATL. Dans un premier temps, nous décrivons les objectifs de l’ATL ainsi que les grands principes régissant sa conception : ceux architectures orientées services et des architectures basée composants. Dans un second temps, nous décrivons les trois grands types de fonctionnalités que l’ATL doit prendre en charge dans ses actions de gestion, de contrôle et de données. Ces différents principes mis en place, nous décrivons, suivant une approche top/down, la structure des différents composants de l’ATL et le rôle de chacun. Le troisième chapitre reprend les éléments introduits dans le chapitre 2 et décrit leur comportement dans deux cas majeurs d’utilisation de l’ATL. Le premier cas est celui de l’ouverture d’un point d’accès au service de Transport. Celui-ci diffère en effet notablement de l’ouverture d’un point d’accès classique (tels que via les sockets TCP/UDP) et doit prendre en compte différents cas nouveaux introduits par la présence de l’ATL. Le second cas de figure concerne la reconfiguration dynamique du service de Transport. L’ATL offrant cette possibilité inédite, il est intéressant de décrire son déroulement afin d’en étudier par la suite les impacts sur la communication. Le quatrième chapitre présente trois études réalisées autour de l’ATL. La première, menée en simulation, vise à combiner un protocole existant avec des mé- 11Introduction générale canismes génériques externes afin d’observer le bénéfice retiré lors d’un transfert multimédia interactif. La deuxième, également menée en simulation, tend à véri- fier le bénéfice induit par le passage d’une telle combinaison à une autre en cours de communication, en fonction de l’évolution des conditions du réseau. Ces deux études tendent à prouver qu’un véritable apport peut être retiré d’un tel fonctionnement de la couche Transport, mais appuient l’intérêt d’une mise en œuvre autonome comme celle apportée par l’ATL. La troisième expérience tente d’observer le coût induit par la signalisation nécessaire à une reconfiguration en cours de communication. Finalement, nous terminons ce document par une conclusion générale qui ré- sume les points abordés et les contributions apportées. Elle introduit également des perspectives de travail futur afin de préciser le modèle architectural actuel et d’étudier certaines problématiques auxquelles il est nécessaire de répondre pour offrir, via les principes de l’ATL une solution performante et utilisée. 12CHAPITRE 1 Contexte, Problématique, État de l’art et Positionnement Ce chapitre présente le contexte dans lequel s’inscrit le travail décrit plus loin dans ce manuscrit. Dans la première partie, nous présentons tout d’abord l’évolution des réseaux en termes de technologies de transmissions — passage des technologies filaires aux technologies sans-fil nomades et mobiles, mais également des évolutions des terminaux qui ont vu leurs capacités augmenter, leurs types se diversifier avec l’apparition des appareils mobiles ou des capteurs, ainsi que l’apparition d’interfaces multiples, mêlant des technologies d’accès diverses sur un même appareil. Par la suite nous évoquons les différents types de services que peuvent requérir les applications en fonction de leurs besoins de communication, ainsi que l’apparition de nouveaux besoins dus à l’avènement du multimédia et des applications interactives. Finalement, nous voyons comment ces évolutions ont été adressées au niveau Transport de la pile protocolaire. Nous tirons ensuite de ce contexte cinq points de problématiques que nous nommons configurabilité, extensibilité, assujettissement, déploiement et complexité de choix. Ces cinq points servent par la suite à confronter les différentes solutions existant au niveau Transport dans la deuxième partie du chapitre. Au cours de cet état de l’art, les protocoles classiques que sont Transmission Control Protocol (TCP) et User Datagram Protocol (UDP) et des protocoles plus récents comme Datagram Congestion Control Protocol (DCCP) ou Stream Control Transmission Protocol (SCTP) sont présentés puis mis à l’épreuve face à ces différents points. Des lacunes et mérites de chacun nous décrivons dans la troisième partie la vision scientifique dans laquelle s’inscrivent les contributions scientifiques qui seront présentées dans les chapitres suivants : celle d’une couche de Transport orientée service et basée composant, offrant un meilleur degré d’abstraction du réseau du point de vue 131. Contexte, Problématique, État de l’art et Positionnement de l’application et permettant la gestion et l’optimisation du fonctionnement des protocoles de Transport sans intervention de cette dernière. Sommaire 1.1 Contexte et Problématique . . . . . . . . . . . . . . . . . . . . 14 1.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . 19 1.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.1 Protocoles de Transport . . . . . . . . . . . . . . . . . 24 1.2.2 En résumé . . . . . . . . . . . . . . . . . . . . . . . . . 37 1.3 Positionnement de la proposition . . . . . . . . . . . . . . . . . 38 1.3.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . 38 1.3.2 Exigences générales de conception de l’Autonomic Transport Layer (ATL) . . . . . . . . . . . . . . . . . . . . . 39 1.3.3 Paradigmes de conception relatifs à l’architecture de l’ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 1.1 Contexte et Problématique Cette première partie s’articule en deux sous-parties. La première présente le contexte dans lequel s’inscrivent nos travaux, en faisant l’état de l’évolution des réseaux et de leurs utilisations en quatre temps : tout d’abord du point de vue des technologies de transmission et de leur disparité, puis des terminaux utilisant ces technologies pour communiquer entre eux et de leur diversité ; ensuite, nous nous intéressons aux applications et à l’évolution de leurs besoins avant de terminer en évoquant la manière dont les protocoles de Transport ont tenté d’apporter une réponse à ces environnements variables et nouveaux. La seconde déduit de ce contexte les cinq points de problématique auxquels nous confrontons les différentes solutions de l’état de l’art dans la partie suivante. 1.1.1 Contexte Les réseaux informatiques ont pris une place prépondérante dans notre société, notamment Internet qui a profondément modifié, et modifie encore, le tissu économique et social à un niveau mondial. Tout ceci repose aujourd’hui sur des échanges de données à très grande vitesse, sur des distances de plusieurs centaines de kilomètres, très souvent traversant plusieurs continents, connectant des terminaux très divers. 141.1. Contexte et Problématique L’évolution observée depuis l’ouverture d’Internet au grand public a considé- rablement changé les usages qui sont faits du réseau. Le web notamment, a évolué de manière à permettre un accès simple à de nombreux usages encore trop mé- connus ou complexes et leur démocratisation a permis leur utilisation aujourd’hui massive. Ainsi, à l’utilisation des mails et de l’échange de fichiers, est venue s’additionner celle de l’audio, la vidéo ou les applications interactives, comme les jeux multi-joueurs en ligne ou les vidéoconférences. Les besoins d’hébergement liés au grand nombre d’utilisateurs ont entraîné la création de datacenters. Au sein de ces structures, des centaines de serveurs topologiquement proches doivent communiquer à très grande vitesse, organisés en grille. Le monde de la finance a automatisé certains de ses processus, créant le high frequency trading, des transactions financières à raison de plusieurs milliers par secondes. Ces situations sont des exemples d’une évolution qui a emmené le réseau bien loin de ce à quoi il ressemblait quelques dizaines d’années auparavant. La diversité des technologies réseaux, des terminaux et des types d’applications n’a jamais été aussi grande. Dans la suite de cette section, nous voyons l’évolution de ces trois domaines et nous évoquons comment les protocoles de Transport ont tenté de s’adapter à cette évolution. 1.1.1.1 Évolution des réseaux Le contexte traditionnel et historique des réseaux est bien évidemment celui des réseaux filaires. Les différentes machines sont reliées ensemble par des câbles sur lesquels transitent les signaux électriques représentant les données à transmettre. De nombreux protocoles se sont développés suivant ce principe. Dans le domaine des réseaux locaux, ou LAN (Local Area Network) le protocole Ethernet [IEE12a], qui s’est imposé comme incontournable, permettait initialement des capacités de 10 Mbps, permet aujourd’hui des capacités de 10 Gbps et cette capacité continue de croître. De plus, des déclinaisons de ce protocole ont été avancées afin de l’utiliser sur des réseaux métropolitains ou MAN (Metropolitan Area Network) et sur des réseaux longue distance ou WAN (Wide Area Network). En MAN ou en WAN, les technologies xDSL (Digital Subscriber Line), connues en France pour l’ADSL (Asynchronous DSL) [ITU99a] et l’ADSL2 [ITU99b] et bientôt l’arrivée du VDSL (Very high bit-rate DSL) [ITU11b] ont permis l’accès à haut débit à la majorité des foyers, cette augmentation étant supportée dans les cœurs de réseaux par l’utilisation de protocoles comme SDH [ITU07]. L’évolution des réseaux filaires a donc été caractérisée par une augmentation des débits et un nombre croissants d’utilisateurs. Tous les types de réseaux ont également connus des évolutions via des accès sans fil. Le WiFi [IEE12b], en constante évolution et permettant déjà des débits 151. Contexte, Problématique, État de l’art et Positionnement de plusieurs dizaines voire centaines de Mbps, en accès WLAN comme WMAN, est utilisé par de plus en plus d’appareils, fixes, nomades ou mobiles. Les réseaux WMAN et WWAN ont également eu leur lot de nouveautés, grâce au WiMaX ou aux évolutions toujours constantes des réseaux mobiles, comme la 3G (UMTS et HSPA), et déjà 4G (LTE), et bien sûr les réseaux satellites [ETS13]. Ces réseaux sans-fil introduisent de nouveaux défis, le médium étant partagé entre tous les utilisateurs et sensible au bruit électromagnétique, les causes de pertes de données seront plus diverses et certaines hypothèses valables sur les ré- seaux filaires deviennent caduques. Ce type de support permet également à l’utilisateur de devenir nomade ou mobile. Il peut alors se connecter au réseau successivement depuis des localisations géographiques différentes, voire se déplacer en cours de communication. Chacun se voit connecté de manière permanente et non plus ponctuelle, via un terminal ou un autre. Au fil du temps, différents éléments ont été introduits au sein du réseau afin d’en améliorer les performances ou de pallier des problèmes de sécurité. Certains de ces éléments brisent une notion capitale dans le modèle classique de la pile OSI : le caractère de bout en bout de la couche Transport. En effet, celle-ci est supposée n’être implémentée que sur les hôtes terminaux de la communication et non sur les éléments intermédiaires, ces derniers n’implémentant que les niveaux suivants : physique, liaison de données et réseau. Certains éléments intermédiaires, nommés middleboxes [Car02], rompent cette règle. En effet, celles-ci vont intervenir sur l’entête de niveau Transport, que ce soit de manière passive, en lecture uniquement, ou active, en la modifiant. Par exemple, les Network Address Translator (NAT) ont besoin d’utiliser le numéro de port pour fonctionner, et doivent donc avoir une compréhension des différents protocoles de Transport utilisés afin d’aller lire les valeurs dont ils ont besoin dans l’en-tête de Transport. Bien qu’intervenant de manière uniquement passive sur le niveau Transport, si le NAT n’implémente pas le protocole utilisé, la communication risque d’être rompue. De la même manière, les Performance Enhancement Proxies (PEP) interrompent, de manière transparente pour les hôtes d’extrémité, la communication. Dans le cas de TCP par exemple, ceux-ci répondent à la demande de connexion à la place de l’hôte terminal visé, se faisant passer pour celui-ci, coupant ainsi la connexion de niveau Transport en deux ou plusieurs tronçons distincts quand celle-ci n’est censée être composée que d’un seul. Comme pour les NAT, si un PEP n’a pas implémenté un certain protocole de Transport, tout trafic véhiculé par celui-ci sera interrompu par le PEP. 161.1. Contexte et Problématique 1.1.1.2 Évolution des terminaux Parallèlement aux réseaux les terminaux ont également subi une forte évolution ces dernières décennies. L’arrivée des réseaux nomades et mobiles a permis la création de terminaux portables et transportables, dont les smartphones et tablettes sont les plus récents exemples. Les stations de travail ont disparu au profit d’une convergence avec les ordinateurs personnels, permettant à tous d’avoir accès à une puissance de traitement honorable. Les capacités de stockage ont également fortement évolué. L’accessibilité accrue à ces ressources a créé une explosion de la demande en terme de contenus. Ainsi, afin d’y subvenir, de nombreux datacenters ont vu le jour à travers le monde, créant des organisations topologiques de machines inédites, véritables concentrations de serveurs aux capacités de stockage se comptant parfois en exaoctets, et aux capacités de calcul de plusieurs teraflops. Tout ceci crée un environnement aux caractéristiques très hétérogènes, certains terminaux possédant des débits plus importants que d’autres, des ressources en terme d’énergie, de stockage ou de puissance de calcul différentes. Un même terminal peut également voir ses caractéristiques changer en cours de communication, à cause de la charge de la batterie des terminaux mobiles, ou lorsque l’interface réseau utilisée change, la plupart des systèmes possédants aujourd’hui plusieurs interfaces, de nature différentes ou non. En effet, la plupart des smartphones possèdent au moins aujourd’hui des interfaces WiFi, Bluetooth et USB en plus de leur antenne téléphonique, celle-ci implémentant la plupart du temps des technologies 2G et 3G, voire 4G, quand ceux-ci ne disposent pas en plus du WiMaX. Les ordinateurs portables disposent presque tous d’une interface Ethernet et WiFi. La plupart des serveurs disposent aujourd’hui de plusieurs interfaces Ethernet. 1.1.1.3 Évolution des applications L’augmentation des performances des machines et des réseaux a permis l’avènement de nouvelles applications et l’amélioration des applications existantes. Cellesci font parfois preuve de besoins radicalement différents de ce que l’on connaissait. Aux applications traditionnelles sont en effet venues s’ajouter les applications multimédia et interactives. Les applications traditionnelles, principalement basées sur l’échange de fichiers, présentaient toutes les mêmes besoins d’ordre et fiabilité totaux dans le transfert de leur données. En effet, chaque octet doit arriver intact et dans l’ordre d’émission à l’application réceptrice afin que celle-ci puisse reconstituer à l’identique le fichier d’origine, qu’il s’agisse d’un envoi de mail, d’une page web, ou d’un transfert de fichier quelconque. Les applications multimédia quant à elles présentent des besoins différents. Par exemple, un streaming vidéo aura besoin d’ordre, mais la fiabilité n’a plus 171. Contexte, Problématique, État de l’art et Positionnement à être totale. Il n’y a en effet aucun besoin de retransmettre une image dont la date d’affichage est dépassée. Certaines données deviennent donc obsolètes avec le temps. De plus, les méthodes de compression actuelles différencient les images leur attribuant des importances différentes. Il est donc possible d’appliquer un traitement discriminant à l’intérieur d’un flux de données, contrairement à un transfert de fichier, où chaque octet a la même importance que les autres. Les applications interactives, mettant en relation plusieurs personnes, réagissant les unes par rapport aux actions des autres, créent encore plus de besoins inédits. Afin que les interactions entre les participants soient fluides, qu’il s’agisse de jeu vidéo ou de vidéoconférence, le délai de transit d’un participant à l’autre doit être suffisamment court pour qu’il ne soit pas perceptible. En effet, pour un jeu vidéo de tir par exemple, type FPS, l’expérience jeu serait ruinée si lorsque vous tirez sur votre adversaire, celui-ci est en réalité à un endroit différent de celui où vous le voyez sur votre écran. Dans une communication, les délais trop longs risquent, en plus de saccader la conversation, de créer des échos très désagréables. Dans [ITU11a], l’Union Internationale des Télécommunications (ITU-T) établit une classification générale et non exhaustive des applications de types audio, vidéo et données existantes en fonction de leur tolérance aux pertes de données lors des transmissions, et des délais de transmission admissibles. Celles-ci sont réparties selon : – leur tolérance ou intolérance aux pertes ; – les délais qu’elles peuvent supporter, et sont alors subdivisées en quatre catégories : – interactivité, – réactivité, – ponctualité, – non criticité du délai. Notons que certaines catégories sont apparues grâce à l’émergence des applications audio et vidéo, et que d’autres, telle la télécopie, plus tolérante par exemple qu’un transfert de fichiers, peut être satisfaite avec l’utilisation d’un service de Transport plus stricte que ce qu’elle requiert. On observe ainsi une évolution des catégories due non seulement à l’apparition de nouveaux types d’application, mais également à la précision de certaines distinctions qui pouvaient auparavant sembler superflues. 1.1.1.4 Évolution des protocoles de Transport Dans ces environnements très hétérogènes, la couche Transport du modèle OSI remplit un rôle particulier. En effet, elle a longtemps été la couche la plus haute implémentée dans la pile protocolaire (si on excepte la couche applicative), et donc en charge de faire le lien entre le réseau et les applications. Ainsi, il a semblé naturel 181.1. Contexte et Problématique d’introduire à ce niveau les modifications nécessaires à l’adaptation à ces nouveaux environnements. Si le paysage protocolaire de cette couche a longtemps été dominé par TCP [Pos81] et UDP [Pos80], des protocoles nouveaux ou des adaptations de protocoles existants ont été étudiés et standardisés, créant ainsi une multiplication des solutions, et une multiplication des API permettant de les utiliser. Ces nouveaux protocoles se concentrent principalement sur la réponse à apporter à une situation donnée, leur conception souvent monolithique n’accordant pas la possibilité de choisir les fonctionnalités à utiliser suivant les cas. Le choix traditionnel étant alors limité à un service total en utilisant TCP, ou nul en utilisant UDP. La responsabilité de ce choix est d’ailleurs toujours à la charge du développeur d’applications. En effet, la vision de la couche Transport aujourd’hui communément admise est celle d’une collection de protocoles disjoints les uns des autres, qui sont appelés par l’application désirant les utiliser. Il revient donc à celle-ci d’invoquer la méthode d’appel du protocole qu’elle souhaite utiliser. Cet appel est décidé en design time, c’est -à-dire que le développeur choisit le protocole qu’il juge le plus pertinent et implémente l’appel à ce protocole particulier dans son application. Cette manière de faire ne laisse aucune place à une utilisation du protocole basée sur une estimation du contexte au cas par cas, sauf à implémenter ce type de prise de décision au sein de l’application, et donc à lui faire endosser une responsabilité supplémentaire. L’invocation d’une solution de Transport se faisant par l’appel à un protocole particulier, c’est également au développeur que revient la charge d’estimer quel protocole satisfait le mieux le service qu’il souhaite. Il existe ici un besoin d’abstraction supplémentaire, le développeur devant faire lui même la correspondance entre service et solution protocolaire. La figure 1.1 résume les différents défis qui se présentent dans le réseau à l’heure actuelle. 1.1.2 Problématique Un environnement aussi évolutif crée différents problèmes, notamment celui de la complexité pour un développeur d’application de faire le bon choix de protocole mais aussi la complexité pour le développeur de protocoles d’intégrer une nouvelle solution au paysage existant. Dans cette section, nous commençons par présenter les différents acteurs concernés par la problématique, avant d’effectuer un tour d’horizon détaillé des différents points de celle-ci. Comme nous le verrons plus tard, certains points peuvent concerner plusieurs acteurs à la fois. 191. Contexte, Problématique, État de l’art et Positionnement Figure 1.1: L’environnement présente aujourd’hui des solutions multiples à des situations multiples 1.1.2.1 Acteurs concernés Trois types d’acteurs portant chacun un regard différent sur l’environnement sont identifiables : – le développeur d’applications ; – le développeur de protocoles ; – le développeur de système d’exploitation. Le souci du développeur d’applications est d’une part la simplicité d’utilisation du service, et d’autre part la conformité du service fourni par le protocole aux besoins de l’application qu’il développe. Il lui serait en effet contre-productif ou sous-optimal de devoir apprendre tous les rouages d’une solution pour l’utiliser pleinement, et d’apprendre ceci pour un nombre conséquent de solutions afin de faire des choix éclairés selon les situations. De même, il est difficilement concevable d’amener le développeur d’applications à réécrire toute ou partie de son application à l’avènement de chaque nouvelle solution au niveau Transport. Le développeur de protocoles se soucie de la capacité à faire adopter facilement son protocole ou son amélioration d’un protocole existant. En effet, une fois la solution développée, il faut qu’elle soit promue : 1. auprès des développeurs d’applications pour les convaincre de l’intérêt d’apprendre à utiliser la nouvelle solution ; 2. auprès des développeurs de systèmes d’exploitation pour les convaincre de 201.1. Contexte et Problématique l’intérêt d’intégrer la solution dans leur système ; 3. auprès des équipementiers pour les convaincre de l’utilité d’implémenter cette solution dans les différentes middleboxes qu’ils produisent. Le développeur système se soucie quant à lui de la facilité d’intégrer une nouvelle solution ou de mettre à jour une solution existante. Il souhaite en effet minimiser la réécriture de son code pour chaque opération d’ajout ou de mise à jour. 1.1.2.2 Problèmes soulevés Partant de l’évolution du contexte applicatif, machine et réseau, des réponses apportées au niveau Transport et des préoccupations des différents acteurs concernés, nous idendifions cinq points de problématique. Tel qu’évoqué précédemment, certains points concernent plusieurs acteurs. Problème de complexité (vis à vis de la connaissance, du choix et de l’utilisation des protocoles) La complexité des solutions protocolaires actuelle s’exprime à différents niveaux et permet de soulever trois problèmes, décrits ci-après. – Les protocoles de Transport sont de nature assez complexe de par leurs principes de fonctionnement, les techniques sur lesquelles sont basés leurs mé- canismes, et enfin leurs algorithmes. Cette complexité a en particulier un impact direct sur la QoS offerte, dont il est important d’avoir conscience lorsque l’on souhaite répondre à des besoins en QoS des applications. Par exemple, un mécanisme de contrôle de congestion basé fenêtre, tel que celui appliqué dans la version de base de TCP, induit une variation du débit et du délai, incompatible avec les besoins en débit constant et en délai borné des applications multimédia interactives. Le premier problème alors posé résulte du constat que cette complexité n’est, dans les faits, pas transparente aux développeurs d’applications : ceux-ci doivent avoir une connaissance fine du fonctionnement du protocole sous-jacent avant de pouvoir développer leurs applications. Ceci nécessite des connaissances fines pour des développeurs dont les protocoles de Transport n’est pas le domaine d’expertise. – Les protocoles de Transport sont également complexes dans leur utilisation. En effet, l’usage du service offert se fait via une interface de programmation (ou API pour Application Programming Interface), dont la maîtrise nécessite généralement des connaissances dans plusieurs domaines, notamment en programmation système. – Enfin, la multiplication des propositions de protocoles de Transport et d’API confronte le développeur d’applications à une troisième difficulté relevant du choix de la solution la mieux adaptée aux besoins de son application. 211. Contexte, Problématique, État de l’art et Positionnement Problème de dépendance (ou d’assujetissement) (de l’application au protocole invoqué) La complexité du choix du protocole n’est pas le seul problème qui résulte du caractère évolutif des solutions. En effet, ce choix s’effectue en design time, c’est à dire au moment de la conception de l’application. Ceci implique que l’application doit être écrite pour un protocole donné et s’y tenir pendant tout son cycle de vie. Le problème vient alors du fait que la solution protocolaire choisie peut ne plus être plus adaptée aux besoins de l’application, en raison de changement des contraintes réseau par exemple, ou suite à l’évolution des besoins de l’application. Notons que ce problème ne concerne pas uniquement les nouvelles solutions protocolaires, mais également toute migration d’une application vers une autre solution protocolaire. Ceci est dû au fait que son code est spécifique et ne peut fonctionner que sur cette solution, et tout changement de protocole doit impérativement passer par des modifications (à différentes échelles d’importance) du code de l’application. Cette dépendance aux protocoles, outre ses conséquences directes, est aussi en partie à l’origine des problèmes d’extensibilité et de déploiement décrits ci-après. Problème d’extensibilité (des solutions protocolaires existantes) Le problème d’extensibilité comporte plusieurs facettes. – L’intégration d’une nouvelle solution, ou la mise à jour d’une solution existante, pose un problème pour les développeurs de systèmes d’exploitation. En effet, toute modification protocolaire, impose des modifications dans les systèmes les hébergeant. Ceci concerne leur intégration dans les nouvelles versions du système, la mise à jour des versions antérieures ou la gestion de la compatibilité entre les deux. Ces implications expliquent la réticence des développeurs de systèmes d’exploitation vis à vis de l’adoption de nouvelles solutions, et conduit au constat que les environnements systèmes sont actuellement hétérogènes en termes de solutions de Transport supportées. – Du point de vue des développeurs de protocoles, le constat précédent constitue un véritable obstacle quant à leur volonté de développer de nouvelles solutions étant donné la probabilité importante de non acceptation par les systèmes, ou au mieux, au regard des délais importants dans l’intégration (généralement plusieurs années). – Du point de vue des développeurs d’applications, ces environnements hété- rogènes les conduisent eux-aussi à prendre des précautions quant à l’usage de nouvelles solutions, personne ne pouvant accepter que son application ait des problèmes de fonctionnement pour la simple raison qu’elle tourne au sein d’un système qui ne supporte pas le protocole de Transport désiré. En résumé, les développeurs d’applications attendent que les solutions de Trans- 221.1. Contexte et Problématique port soient largement déployées pour les utiliser, pendant que dans le même temps, les développeurs de systèmes d’exploitation attendent que ces solutions soient utilisées par les applications avant de les déployer. Ce cercle vicieux fait que le problème d’extensibilité constitue la cause principale du problème de déploiement décrit ciaprès. Problème de déploiement (des nouvelles solutions protocolaires) Le déploiement de nouvelles solutions est le problème le plus restreignant dans l’évolution de la couche Transport. Il regroupe les problèmes d’extensibilité et de dépendance au protocole, en plus du problème de l’acceptabilité par le réseau. – Tel que décrit précédemment, le problème d’extensibilité est à la source des difficultés d’adoption de nouvelles solutions par les systèmes, de leur utilisation par les applications, et en conséquence de leur développement lui-même. Vient ensuite le problème de dépendance des applications aux protocoles de Transport sous-jacents qui fait que toute modification de ces derniers impose des modifications pour les applications. – A ceci vient s’ajouter le problème d’acceptabilité par le réseau. En effet, les middleboxes, quelles que soient leurs fonctions, ont souvent des politiques de fonctionnement basées sur les types de protocoles et leurs contenu. Toute modification d’un protocole existant ou intégration d’un nouveau protocole impose la mise à jour de ces middleboxes afin qu’elles puissent reconnaître la nouveauté. Comme certaines d’entre elles ne laissent passer que certains protocoles, un nouveau protocole risquerait de ne pas pouvoir les franchir bien qu’ils soient supportés par les systèmes d’extrémité. Problème de configurabilité (des services offerts) Avec l’évolution des besoins en QoS des applications, les deux catégories de services offertes par les protocoles TCP et UDP sont devenues insuffisantes. Non seulement certaines applications se trouvent dans l’obligation d’utiliser des services non nécessaires induisant des quantités de données et des délais supplémentaires inutilement, mais aussi, certaines d’entre-elles peuvent voir la qualité de leurs service se dégrader à cause de ces services supplémentaires inutiles. La non configurabilité de ces protocoles qui fait que les applications sont obligés d’utiliser l’ensemble du service proposé dans son intégralité, a eu comme conséquence la complexification de la couche Transport par la création de nouveaux protocoles ne proposant aucun nouveau service, mais seulement des sous-ensembles des services des protocoles existants. 231. Contexte, Problématique, État de l’art et Positionnement Point de problématique Acteurs concernés Complexité Développeur d’applications Assujettissement Développeur d’applications Extensibilité Développeur d’OS, de protocoles et d’applications Déploiement Développeur de protocoles Configurabilité Développeur d’applications Table 1.1: Résumé de la problématique 1.2 État de l’art Dans cette section, nous présentons les solutions de niveau Transport existantes et les confrontons aux points de problématique identifiés précédemment. Certains de ces points ont cependant une portée globale et ne peuvent pas être étudiés ainsi au cas par cas. Le problème de complexité de choix, par exemple provient de la multiplicité des solutions qui seront évoquées dans la suite de cette section, et confronter chacune d’elle à ce problème aurait ainsi peu de sens. La multiplicité des solutions de Transport repose aussi bien sur le nombre de protocoles existants que le nombre de versions de ces protocoles, en particulier TCP, qui a évolué et a été adapté à de très nombreuses reprises. On observe que les protocoles les plus récents s’orientent vers une résolution partielle des problèmes observés, sans jamais totalement les adresser cependant. 1.2.1 Protocoles de Transport Comme la majorité du trafic utilise le protocole IP au niveau réseau, la plupart des protocoles de Transport utilisés sont ceux normalisés par l’IETF. Ces protocoles sont TCP, UDP, DCCP et SCTP, les deux premiers étant les plus utilisés car historiquement les premiers à avoir été créés. Ceux-ci offrent les deux types de services qui étaient utiles au moment de leur création. TCP propose un service garantissant un ordre et une fiabilité totaux sans garantie de délai, afin de permettre les transferts de fichiers, de mails et toutes les utilisations de ce type du réseau. UDP de son côté n’offre absolument aucune garantie et suffisait alors pour toutes les autres utilisations. 1.2.1.1 TCP TCP offre un service totalement fiable et ordonné, en se basant sur un contrôle des pertes et d’erreurs par l’envoi d’acquittements cumulatifs. Tout paquet perdu ou erroné sera ainsi non acquitté, l’émetteur du dit paquet sachant alors qu’il devra retransmettre le paquet erroné et tout paquet subséquent à celui-ci. Ce système 241.2. État de l’art induit nécessairement une augmentation du délai de transit d’un paquet : la perte étant non déterministe, le nombre de retransmissions possibles d’un paquet (et donc des suivants) n’est pas borné. TCP tente également de protéger le réseau grâce à son système de contrôle de congestion, visant à limiter la quantité de paquets à traiter par les routeurs en état de saturation, et donc à limiter les pertes. Ce système implique une diminution du taux d’envoi de paquets par TCP en cas de congestion, ce qui implique de fortes variations dans les délais et les débits. TCP a connu de nombreuses évolutions et adaptations au cours de son histoire. Les principales visent l’amélioration de son contrôle de congestion, que ce soit dans l’absolu ou dans certaines conditions particulières. D’autres concernent les options, comme les Selective Acknowledgement (SACK) [Mat96], permettant d’acquitter des messages correctement reçus malgré certains messages précédents manquants (ce que ne permet pas l’acquittement cumulatif) ou le multipath [For11] (cf. 1.2.1.5). Les différents contrôles de congestion de TCP sont nombreux. Certains sont voués à se remplacer les uns les autres, les suivants étant considérés comme des améliorations des précédents. TCP New Reno [Hen12], par exemple, est considéré aujourd’hui comme l’implémentation de référence du contrôle de congestion de TCP et vise à remplacer les versions précédentes qu’étaient TCP Tahoe et Reno. Si cette version est celle retenue par certains OS, notamment FreeBSD, de nouvelles versions « non canoniques »ont été implémentées dans Windows et Linux. Compound TCP [STBT08] est la version aujourd’hui utilisée sous Windows, bien qu’une version Linux ait été développée à l’université de Caltech mais non maintenue (ce patch est incompatible avec le noyau Linux à partir de la version 2.6.17). Elle est utilisée par défaut depuis Windows Vista et Windows Server 2008 bien que des mises à jour facultatives permettent de l’inclure dans Windows XP et Windows Server 2003. Tout comme TCP Vegas [BP95] ou FAST TCP [WJLH06], Compound se base sur le temps d’attente des paquets comme indication de congestion, et non sur les pertes. Dans sa version 2.6.8, Linux utilise par défaut Binary Increase Congestion control TCP (BIC TCP) [XHR04], puis, à partir de la version 2.6.19, son évolution, CUBIC TCP [HRX08]. CUBIC n’utilise plus les retours d’acquittement comme signal d’augmentation de sa fenêtre d’émission, mais au contraire le temps écoulé depuis le dernier évènement de congestion ce qui permet une croissance de la fenêtre beaucoup plus continue. Ces différentes versions de l’algorithme de contrôle de congestion de TCP visent, tout comme HighSpeed TCP [Flo03], à améliorer les performances du protocole sur les réseaux à forte bande passante et fort délai de transit, ou Long Fat Networks, tels que définis dans [Jac88]. D’autres versions visant à adresser des contextes spécifiques, tel que Data Cen- 251. Contexte, Problématique, État de l’art et Positionnement ter TCP [AGM+10], ont également été développées. Beaucoup de ces versions visent notamment les réseaux sans fil, parfois d’un type particulier. TCP Hybla [CF04] notamment, qui cible originellement les liens comportant des sections satellites, optimise le comportement de la fenêtre de congestion sur les chemins comportant un RTT important, en décorrélant l’impact du RTT sur la taille de la fenêtre de congestion. Malheureusement, ses améliorations étant basées sur le comportement observé de la fenêtre de congestion en milieu satellitaire, elles offrent des performances bien moindres sur des réseaux classiques, les hypothèses sur lesquelles elles sont construites n’étant pas vérifiées. Le cas des réseaux mobiles ajoute en plus les pertes dues au temps de handover, lors d’un passage d’une station de base à une autre. Ceci a pu être adressé par Freeze TCP [GMPG00], qui charge l’appareil mobile de signaler la proximité d’un handover en surveillant la puissance du signal reçu. Problème d’extensibilité. TCP prévoit un système d’options, grâce notamment à un champ d’en-tête dédié de longueur variable, permettant d’adjoindre des comportements supplémentaires. C’est ainsi qu’en plus de l’acquittement cumulatif, TCP peut gérer des acquittements sélectifs [Mat96] ou utiliser plusieurs interfaces de manière concurrentes [For11] (cf. 1.2.1.5). Cependant le caractère monolithique de TCP, c’est-à-dire la non dissociation des différentes fonctions de son service de base comme le contrôle de congestion, de flux, des pertes et d’erreurs, rend difficile l’insertion de services modifiés comme de la fiabilité partielle. Certaines options de ce type avaient cependant été introduites, comme les acquittements négatifs [Fox89] ou la gestion de l’ordre partiel [Con94], mais devant l’impopularité de leur déploiement, celles-ci ont été officiellement abandonnées [Egg11]. Problème de configurabilité. TCP offre un service totalement fiable et totalement ordonné. Sa structure monolithique ne donne pas la possibilité de choisir l’une ou l’autre de ces fonctionnalités, ou de ne les utiliser que de manière partielle. Dans une certaine mesure cependant, TCP est configurable. Certains comportements, comme la concaténation de paquets de petite taille [Nag84] peuvent être désactivés manuellement. Si certains peuvent être modifiés via l’API du protocole, d’autres nécessitent une intervention dans les paramètres du système et ne peuvent donc pas être pris en charge par l’application. Problème d’assujettissement. Les capacités d’autonomie de TCP sont limitées à la variation de certains de ses paramètres, comme sa fenêtre de congestion, en fonction de l’évolution du réseau. La modification d’autres paramètres tels que l’algorithme de calcul du Retransmission Time Out (RTO) doit être prise en charge 261.2. État de l’art par l’application ou l’administrateur du système, ce qui implique une surveillance du réseau et une gestion du protocole de leur part. TCP dépend donc d’une entité extérieure à la couche Transport pour effectuer certains ajustements ayant trait au contrôle de la communication, ou qui pourraient l’optimiser. Problème de déploiement. Par son caractère historique, TCP s’est imposé comme le protocole universel. Son déploiement ne pose donc aucun souci, chaque OS qui implémente la pile protocolaire IP intégrant une version de TCP. Il est également le protocole nécessairement implémenté dans les middleboxes présentes dans le réseau. TCP est aujourd’hui le seul protocole à pouvoir être utilisé partout, même s’il peut parfois être bloqué à cause de l’utilisation de certaines options. 1.2.1.2 UDP UDP n’offre aucune garantie d’ordre ni de fiabilité. De plus, il n’implémente aucun système de contrôle de congestion. Ceci permet de limiter les fluctuations de délai évoquées dans le cas de TCP. UDP est donc mieux adapté aux applications multimédia, mais énormément de pertes peuvent être à déplorer, limitant la qualité du flux. De plus, ne disposant d’aucun contrôle de congestion, il met le réseau en péril en risquant de congestionner les routeurs intermédiaires. Problème d’extensibilité. N’offrant aucune garantie, ajouter des fonctions à UDP est possible selon le plus large spectre qui soit, cependant UDP ne prévoit aucun mécanisme permettant d’étendre celles-ci. Ainsi, toute extension devra être prise en charge par l’application ou par une couche middleware, qui invoquera ellemême UDP. Les messages de niveau middleware seront alors encapsulés dans le datagramme UDP. On ne peut donc pas littéralement parler d’extensions d’UDP. Problème de configurabilité. UDP offre le service le plus simple qui soit : aucune garantie, aucun contrôle de congestion, il se contente de multiplexer l’accès des applications à la couche Transport (via les numéros de port). Les seuls paramètres configurables concernant le fonctionnement global d’UDP sur le système et ne sont pas accessibles par l’application ni ne modifient aucun mécanisme protocolaire. La configurabilité d’UDP est donc nulle. Problème d’assujettissement. UDP offrant un service sans aucune garantie, tout mécanisme supplémentaire, tel qu’un contrôle de congestion, un mécanisme de fiabilité ou d’ordre partiel ou total, doit être pris en charge et implémenté au niveau de l’application. 271. Contexte, Problématique, État de l’art et Positionnement Problème de déploiement. UDP est, comme TCP, présent sur la majorité voire la totalité du réseau. Il fait partie de la suite protocolaire IP et est donc implémenté dans tous les systèmes d’exploitation. Du point de vue des middleboxes, UDP est accepté dans une grande majorité, notamment car il est le protocole de Transport utilisé pour le Domain Name System (DNS). 1.2.1.3 DCCP DCCP [Kho06] vise à pallier les défauts d’UDP en offrant un service non fiable et non ordonné, mais avec contrôle de congestion. Le choix du contrôle de congestion est laissé à l’application. Celle-ci peut décider d’utiliser un contrôle de congestion « à la TCP »[Flo06a], l’algorithme TCP-Friendly Rate Control (TFRC) [Flo08, Flo06b] ou bien encore TFRC for Small Packets (TFRC-SP) [Flo07, Flo09]. DCCP est ainsi plus adapté que TCP pour les applications tolérantes aux pertes et au désordre, et plus adapté qu’UDP pour les transferts sur Internet. Problème d’extensibilité. Bien que DCCP inclue un champ « options » dans son en-tête, celles-ci ne servent pas, contrairement à TCP, à étendre ses fonctionnalités, mais à spécifier un certain nombre d’informations optionnelles selon le type de paquet, et selon le contrôle de congestion choisi. DCCP n’inclue donc pas nativement de mécanisme permettant l’extension de ses fonctionnalités, et du service offert. Problème de configurabilité. DCCP est un protocole qui entre parfaitement dans la catégorie des protocoles configurables. En effet, comme nous l’avons mentionné ci-dessus, DCCP offre la possibilité de pouvoir choisir l’algorithme de contrôle de congestion entre trois possibilités. Ce changement doit cependant être fait à un niveau système et n’est donc pas paramétrable de manière différenciée pour chaque application à ce jour. DCCP est donc un protocole configurable de manière statique, et avec certaines lourdeurs. En effet, un tel changement au niveau système ne peut s’effectuer qu’avec les droits administrateur sur la machine concernée, droits que ne possèdent pas forcément toutes les applications. De plus, dû au caractère global de cette modification, deux applications ayant un choix différent sur la question pourraient entrer en conflit et se gêner l’une l’autre dans la configuration du protocole. Problème d’assujettissement. DCCP présente sur ce point le même défaut qu’UDP. En effet, hormis le contrôle de congestion qui est à présent pris en charge par le protocole, tout mécanisme supplémentaire doit être implémenté et pris en charge par l’application afin d’être disponible. 281.2. État de l’art Problème de déploiement. DCCP est à l’heure actuelle face à un problème de déploiement considérable. Seules trois implémentations ont vu le jour. La première, dans le noyau Linux, ne dispose pas d’une API complète. La deuxième vise un haut degré de portabilité et la troisième concerne la plateforme d’implémentation Google Go. mais aucune de ces deux implémentations ne dispose d’une version stable ni n’a bénéficié d’une mise à jour récente. De ce fait, DCCP n’est utilisé par aucune application grand public, ou à grande échelle. Cette faible utilisation fait écho à son implémentation tout aussi rare dans les différentes middleboxes présentes dans le réseau. Il est à noter qu’une mise à jour de [Kho06] effectuée par [Phe12] offre à DCCP la capacité d’être encapsulé dans un datagramme UDP (nommé alors DCCP-UDP), et non plus directement dans un paquet IP, afin de permettre le passage à travers les différentes middleboxes, et principalement les NATs. Notons cependant que si cette méthode permet de faciliter la transition de DCCP-UDP à DCCP, elle ne modifie rien quant à la transition d’UDP vers DCCP (ou DCCP-UDP). 1.2.1.4 SCTP SCTP [Ste07] a été proposé afin de tirer parti de la multiplicité d’interfaces offertes par les terminaux modernes, et ainsi pallier certains problèmes notamment dus à la mobilité de ces terminaux. SCTP va en effet utiliser toutes les interfaces disponibles pour un même flux applicatif. On ne parle ainsi plus de connexion, mais d’association. Le protocole peut ainsi utiliser plusieurs interfaces au sein d’une même association et utiliser une interface en tant que back up, afin d’assurer la continuité de la communication si la connexion principale venait à être défaillante. Plusieurs extensions ont été ajoutées au protocole comme un système de fiabilité partielle [Ste04], ou sont aujourd’hui à l’étude, comme la possibilité d’utiliser les différents chemins d’une même association de manière concurrente [DBA13]. Problème d’extensibilité. SCTP inclue un système similaire à celui des options de TCP. En effet, un système de champ d’en-tête optionnel permettant la définition d’extensions est présent et a notamment permis l’introduction de la gestion de la fiabilité partielle au sein du protocole [Ste04]. Problème de configurabilité. SCTP possède différentes options configurables à deux niveaux : au niveau du système et au niveau du socket. Comme pour les pré- cédentes solutions, les configurations effectuées au niveau du système ne peuvent pas être réalisées par l’application, et concernent l’ensemble des associations SCTP. Celles-ci concernent notamment le calcul du Retransmission Time Out, ou la reconfiguration dynamique d’adresses. Les options modifiables au niveau du socket concernent les adresses primaires de l’association (celles utilisées comme chemin 291. Contexte, Problématique, État de l’art et Positionnement principal de communication), l’algorithme de Nagel, la fragmentation de paquets, ou la récupération d’informations de monitoring, ainsi que le contrôle de la fiabilité partielle. SCTP possède donc une composante fondamentale configurable, le système de fiabilité partiel. Celui-ci est activable au besoin mais cependant entièrement contrôlé par l’application qui doit elle-même décider du nombre maximum de retransmissions acceptables. De plus, bien qu’encore aujourd’hui à l’étude, on peut supposer qu’une extension d’utilisation concurrente des différents chemins d’une même association, sera également optionnelle et contrôlable par l’application. Problème d’assujettissement. SCTP présente une légère différence par rapport aux précédentes solutions, dû au fait que la fiabilité partielle est optionnelle. De ce fait, le développeur d’application est moins contraint dans l’utilisation qu’il fait du protocole, puisqu’il peut choisir tout ou partie du service présent. Cependant ce choix et sa gestion restent à l’initiative et à la charge de l’application, rendant le processus lourd. Problème de déploiement. S’il est moins important que pour DCCP, SCTP est également confronté à certains problèmes de déploiement. En effet, tous les systèmes d’exploitation ne l’intègrent pas en natif ce qui limite d’autant son utilisation. De plus, le service de base offert par SCTP étant redondant avec celui de TCP, peu de développeurs d’applications décident de se former à l’utilisation de ce nouveau protocole pour mettre à jour leur application, l’utilisation de TCP étant plus sûre. En effet, ce dernier est disponible partout et implémenté dans la totalité des middleboxes du marché, contrairement à SCTP, souvent bloqué. 1.2.1.5 Multipath TCP (MPTCP) MPTCP [For11] est une extension au protocole TCP traditionnel qui consiste à lui adjoindre la capacité à utiliser plusieurs interfaces simultanément, et de manière concurrente. L’initiative de créer ce working group à l’IETF découle des soucis d’adoption que rencontre SCTP depuis sa création. Ainsi, le projet MPTCP consiste à tirer parti des avantages induits par l’utilisation de toutes les interfaces d’une machine, concept dont l’intérêt à été prouvé avec SCTP, tout en acceptant le constat que seul TCP est accepté partout dans le réseau. MPTCP est conçu de manière à être utilisé de manière transparente par les applications et par le réseau, sans modification nécessaire de ces derniers. Cependant, des applications conscientes de la présence de MPTCP peuvent en tirer parti plus conséquemment. Étant une extension de TCP, MPTCP vise à fournir le même service d’ordre et de fiabilité totaux sans garantie de délai, tout en améliorant la résilience, notamment en mobilité (par l’utilisation de plusieurs chemins simultanément), et en améliorant 301.2. État de l’art également le débit, par addition des débits possibles sur chaque interface (l’objectif étant de toujours faire au moins aussi bien que TCP dans sa version classique). Problème d’extensibilité. MPTCP se base sur une décomposition de la couche Transport en sous-couches, idée proposée dans les travaux de Transport Next Generation (Tng) [FI08], en attribuant à une sous-couche supérieure les fonctions relatives à la sémantique applicative, et à une sous-couche inférieure celles relatives à la gestion du réseau, comme décrit sur la figure 1.2. Figure 1.2: Décomposition des fonctions de transport En se basant sur ce concept, MPTCP décompose la couche Transport comme sur la figure 1.3. En offrant ce cadre, MPTCP permet l’étude et l’intégration de fonctions étendues en fonction de leur orientation réseau ou sémantique applicative. Ainsi, peuton imaginer l’intégration de différents algorithmes de contrôle de congestion dédiés aux protocoles multi-chemins tels que proposés dans [DABR12], que l’on pourrait échanger selon les conditions du réseau et les besoins de l’application. De la même manière, la sous-couche sémantique pourrait accueillir des fonctions permettant de modifier le service offert MPTCP, y intégrant de la fiabilité ou de l’ordre partiels par exemple. Cependant, les fondations même de MPTCP reposent sur un ensemble de flux à ordre et fiabilité totaux, contraignant les modifications possibles du service offert. Ainsi, introduire une contrainte de délai impliquerait impérativement un impact sur le débit, ces deux grandeurs étant liées par l’usage de TCP. 311. Contexte, Problématique, État de l’art et Positionnement Figure 1.3: Décomposition de MPTCP en sous-couches Problème de configurabilité. MPTCP étant encore en cours de standardisation et d’implémentation, sa configurabilité n’est pas encore définitivement établie. Cependant, certaines extensions à l’API socket classique ont été préconisées dans [Sch13]. Ces extensions, nommées basic API, servent à des applications qui ont conscience de la présence sous-jacente de MPTCP. Celles-ci permettent d’activer ou de désactiver l’utilisation de MPTCP (et ainsi n’utiliser que TCP en version classique), ou de modifier l’ensemble des adresses, donc des interfaces, à utiliser dans la connexion MPTCP qu’elles emploient. D’autres options permettent de récupérer des informations propres à une connexion MPTCP, comme la liste des adresses utilisées par la connexion. Il est à noter que [Sch13] suggère dix extensions supplémentaires à l’API décrite afin de constituer une API avancée, permettant un contrôle plus poussé de l’application sur le protocole, par exemple en communiquant un profil décrivant les attentes de l’application en termes de performance, ou de caractéristiques concernant la communication (débit d’émission, délai interpaquets, etc.). Cette API avancée n’est à l’heure actuelle ni standardisée, ni à l’étude. Problème d’assujettissement. Tel que les RFCs le décrivent aujourd’hui, l’application ne peut qu’utiliser le service totalement fiable et totalement ordonné fourni par MPTCP. Bien que permettant l’introduction de mécanismes modifiant ce comportement, aucun n’est aujourd’hui en cours de standardisation, le protocole étant encore jeune. La gestion du protocole respecte le paradigme communément admis dévouant cette charge à l’application, et nécessitant donc une connaissance et une expertise de la part du développeur d’applications. 321.2. État de l’art Problème de déploiement. MPTCP présente de nombreuses forces concernant son déploiement et son adoption. Du point de vue du développeur d’applications, son avantage principal est d’être géré avant tout par le système, et ne nécessite donc aucune modification dans le code des applications pour être utilisé. MPTCP est donc d’ores et déjà compatible avec toute application utilisant TCP sans réclamer de mise à jour de celles-ci. Son utilisation la plus basique ne réclame pas de formation spécifique du développeur d’applications non plus, si tant est que celui-ci soit déjà familier avec l’utilisation de TCP. Du point de vue du réseau, MPTCP est vu par ce dernier comme plusieurs flux TCP, indépendants les uns des autres. Ainsi, la majorité des middleboxes laisseront-elles ces flux circuler sans encombre. Les quelques problèmes possibles proviendront essentiellement des middleboxes bloquant les options TCP inconnues (MPTCP se manifestant par une nouvelle valeur d’option dans l’en-tête des segments TCP), ainsi que celles modifiant les numéros de séquence, MPTCP mettant en place une correspondance entre les numéros de séquence de chaque flux, et un numéro de séquence applicatif. 1.2.1.6 CTP Introduit dans [BWH+07], Configurable Transport Protocol (CTP) est un protocole visant des capacités élevées en termes de configurabilité. CTP se base sur le principe de la composition de micro-protocoles introduits dans [Exp03]. Les microprotocoles représentent chacun une fonction de Transport de base, atomique. Leur composition permet ainsi la création d’un service de Transport à la carte en fonction des besoins de l’application. CTP fonctionne sur un principe évènementiel : chaque message arrivant dans le protocole déclenche une série d’évènements en fonction des informations contenues dans son en-tête. Chaque évènement informe un micro-protocole qu’il doit prendre le message en charge. Ceci permet de paralléliser les traitements lorsqu’ils sont indépendants les uns des autres. Problème d’extensibilité. Afin de permettre le déploiement de la composition adéquate de part et d’autre de la communication, CTP utilise un champ de 32bits, associant chacun à un micro-protocole particulier. Ainsi, bien que les auteurs appellent à la création de nouveaux micro-protocoles dans [BWH+07], CTP est limité à une collection ne dépassant pas les 32 micro-protocoles. Ce nombre, s’il est suffisant pour des services de Transport « classiques » risque de se révéler faible dès que l’on considère la possibilité d’utiliser plusieurs implémentations d’un même micro-protocole en fonction des situations, ou que l’on décide d’ajouter des micro-protocoles implémentant des fonctions plus exotiques, relatives à la Qualité de Service ou à la sécurité par exemple. 331. Contexte, Problématique, État de l’art et Positionnement Problème de configurabilité. CTP a été créé dans le but d’offrir une confi- gurabilité maximale. En effet, l’application peut choisir la composition de microprotocole qu’elle désire, et ainsi la dessiner selon ses besoins, sans devoir utiliser des services qui lui seraient inutiles, ou se résigner à implémenter elle-même ceux qui manquent, comme dans le cas des solutions monolithiques classiques. De plus, même si elle est limitée, l’extensibilité de CTP offre la possibilité d’ajouter des fonctions supplémentaires nécessaires à la satisfaction des besoins de l’application. CTP n’est cependant pas reconfigurable en cours de communication, forçant l’application à conserver le même service composite tout au long de celle-ci. Problème d’assujettissement. Le manque de configurabilité dynamique contraint donc l’application dans le service qu’elle décide à l’ouverture de connexion. Ce n’est cependant pas le seul point sur lequel l’application se retrouve assujettie à CTP. En effet, la gestion complète du protocole repose sur elle. C’est ainsi à elle de décider de la meilleure composition de micro-protocoles à utiliser. Il est d’ailleurs précisé que cette composition devra être établie par l’expérience, aucun système de décision n’étant présent pour épauler l’application dans son choix. Problème de déploiement. Cette dernière contrainte est un véritable frein à l’adoption de CTP. Plus encore que pour les solutions précédentes, le développeur d’applications doit apprendre en profondeur le fonctionnement du protocole pour être capable de l’utiliser. De plus, son fonctionnement différant fortement de celui des protocoles classiques, toute application souhaitant l’utiliser devra être mise à jour. Finalement, toutes les middleboxes devront également être capable de le prendre en charge, CTP n’étant pas conçu pour être transparent du point de vue du réseau. 1.2.1.7 ETP Développé au LAAS-CNRS, Enhanced Transport Protocol (ETP) est un framework pour la composition de protocoles de Transport composites. Tout comme CTP, il repose sur la composition de micro-protocoles créant ainsi des protocoles composites répondant aux besoins de l’application. ETP adopte une structure différente de celle de CTP, préférant une approche hybride entre organisation hié- rarchique, comme le modèle OSI, et le modèle évènementiel, sur lequel repose CTP. Cette organisation schématisé sur la figure 1.4 est articulée autour de cinq conteneurs : – Application Out (AppOut) ; – Application In (AppIn) ; – Protocol Out (ProtOut) ; – Protocol In (ProtIn) ; 341.2. État de l’art – Management. Chaque conteneur se destine à recevoir les différentes fonctions nécessaires au fonctionnement des différents micro-protocoles qui vont constituer le protocole. Ainsi, le conteneur de management va-t-il accueillir les fonctions de contrôle dudit micro-protocole. Ce conteneur adopte une approche évènementielle. Les fonctions qui y prennent place vont s’activer sur notifications d’évènements produites par les fonctions qui prendront place dans les autres conteneurs. Ces quatre autres conteneurs peuvent se diviser selon deux axes. Un axe vertical sépare d’un côté les conteneurs AppOut et ProtOut, et les conteneurs AppIn et ProtIn de l’autre, formant un plan de données en sortie d’une part, qui traitera les messages émis par l’application, et un plan de données en entrée, qui traitera les messages reçus à destination de l’application. Ils se divisent également selon un axe horizontal, regroupant les conteneurs AppOut et AppIn d’une part, et ProtOut et ProtIn d’autre part. Les premiers exécutent leurs fonctions au rythme des demandes d’émission et de réception de l’application. Les seconds exécutent les fonctions qu’ils hébergent au rythme auquel le réseau les accepte ou les transmet. Ces rythmes pouvant être très différents, des buffers font office de tampon entre les deux plans horizontaux (App et Prot) pour absorber cette différence. Ces quatre conteneurs s’organisent de manière hiérarchique. Les différentes fonctions qui y sont hébergées sont empilées selon un certain ordre, et s’exécuteront sur les différents messages dans cet ordre. Figure 1.4: Organisation schématique d’ETP 351. Contexte, Problématique, État de l’art et Positionnement Problème d’extensibilité. ETP prévoit la possibilité d’accueillir de nouveaux micro-protocoles. Ceux-ci sont désignés par un identifiant unique, rendant les possibilités d’extensions quasiment illimitées. Le système de synchronisation, contrairement à celui de CTP, n’est pas limité en place ce qui permet également cette extensibilité illimitée. Chaque micro-protocole pouvant adjoindre son ou ses champs d’en-tête personnalisés, cependant, le risque créé est celui d’un overhead important lors de l’utilisation de nombreux micro-protocoles dans le même protocole composite, risquant de provoquer de la fragmentation au niveau IP. Problème de configurabilité. ETP est configurable à l’initialisation et reconfigurable dynamiquement en cours de communication. Le déploiement de la nouvelle composition du protocole s’effectue en parallèle de l’ancienne, permettant ainsi le traitement d’éventuelles retransmissions ou de paquets encore en vol. Cette méthode s’accompagne cependant d’un coût en termes de ressources utilisées la rendant peu viable sur les terminaux limités, tels que des capteurs. La reconfiguration dynamique requiert de plus une signalisation propre induisant un certain overhead sur le réseau. Problème d’assujettissement. Les configurations d’ETP sont décidées par l’application, imposant au développeur d’applications de connaître les micro-protocoles qui s’offrent à lui mais également de décider de leur organisation hiérarchique au sein des conteneurs du plan de données. C’est également à l’application de commander les différentes reconfigurations en cours de communication, lui laissant la tâche de surveiller, en plus de ses propres besoins, si l’état du réseau réclame de modifier le service fournit par le protocole. Problème de déploiement. ETP repose techniquement au dessus d’UDP et est ainsi vu par le réseau comme la charge utile du protocole de Transport. ETP peut donc être accepté par le réseau où UDP l’est, c’est-à-dire quasiment partout. ETP doit cependant être utilisé par les développeurs qui sont contraints, pour ce faire, d’apprendre son utilisation. Proche de celle d’UDP, elle doit cependant être complétée en fournissant au protocole la composition de micro-protocoles à utiliser. C’est également au développeur d’applications de décider des changements de composition. Tout ceci fait peser un besoin en connaissance et une responsabilité supplémentaire sur le développeur d’application rendant improbable le déploiement d’ETP en pratique. 361.2. État de l’art 1.2.2 En résumé Les différents tableaux suivants résument les différents points exposés sur les différents protocoles. Protocole Extensibilité TCP Par options UDP Aucune DCCP Aucune SCTP Par options MPTCP Structure en couche pouvant accueillir des extensions CTP Limitée ETP Forte Table 1.2: Résumé du problème d’extensibilité Protocole Configurabilité TCP Limitée UDP Nulle DCCP Contrôle de congestion SCTP Limitée MPTCP Basique standardisée, étendue prévue CTP Totale ETP Totale Table 1.3: Résumé du problème de configurabilité Protocole Assujetissement TCP Service monolithique UDP Service monolithique DCCP Choix du CC à la charge de l’application SCTP Choix à la charge de l’application MPTCP Choix à la charge de l’application CTP Choix à la charge de l’application ETP Choix à la charge de l’application Table 1.4: Résumé du problème d’assujettissement L’abondance de ces différents paramètres nous place face au problème de la complexité des choix qu’ont à faire les développeurs d’applications. En effet, un 371. Contexte, Problématique, État de l’art et Positionnement Protocole Déploiement TCP Disponible partout UDP Disponible partout DCCP Faible SCTP Faible MPTCP A venir CTP Aucun ETP Aucun Table 1.5: Résumé du problème de déploiement protocole donné, même s’il est faiblement déployé, peut donner de meilleures performances dans un réseau fermé, non relié à Internet, qu’un protocole plus vastement déployé. Cependant, ceci peut mener à des complications si l’application devait finalement être portée sur un contexte de réseau plus ouvert, relié à Internet. Le choix que doit faire le développeur d’application, pour être éclairé, doit être basé sur une connaissance poussée des différents protocoles disponibles. Or la complexité de certains, standardisés parfois par une grande quantité de documents, rend cette tâche ardue, consommatrice de temps et réclamant un effort sur une expertise qui ne devrait pas relever du développement logiciel. Pour cette raison, et grâce à son omniprésence, TCP est souvent le choix fait par défaut, notamment car de plus en plus d’applications utilisent HTTP pour leur transferts, et que celuici repose sur TCP. Cependant, le service de TCP est faiblement configurable, et c’est alors à l’application de prendre en charge les modifications qu’elle souhaite voir appliquées. 1.3 Positionnement de la proposition Face aux limites des protocoles de Transport, la thèse soutenue dans ce mé- moire est celle d’une architecture innovante pour la couche Transport, nommée ATL, qui permet de répondre aux différents points de la problématique discutés précédemment. Cette section en présente l’approche, les exigences générales et les principes de conception retenus en conséquence. Les chapitres 2 et 3 sont dédiés à l’explicitation et aux détails de mise en œuvre de ces trois volets. 1.3.1 Approche L’objectif n’est pas de définir un nouveau protocole, mais de tirer partie de l’ensemble des solutions protocolaires (protocoles et mécanismes) existantes ou 381.3. Positionnement de la proposition à venir, par le biais d’un environnement d’intégration et de composition au sein d’une véritable couche Transport, dans le but de répondre au mieux aux besoins des applications en tenant compte des capacités du réseau et des systèmes terminaux. La proposition présentée dans ce document traite également des considérations de déploiement de l’ATL qui doit tenir compte, d’une part, du degré de conscience de l’ATL de la part des applications, et d’autre part, de la disponibilité de l’ATL dans les différents systèmes s’interconnectant. En d’autres termes, la mise en œuvre de l’ATL sur un hôte terminal ne doit pas conduire au besoin de réécrire les applications traditionnelles dites « legacy », développées en amont de l’ATL ; de même, le déploiement de l’ATL sur un hôte terminal doit permettre à ce dernier d’interagir avec un hôte sur lequel l’ATL n’est pas déployé, que ce soit en tant qu’initiateur (client) de la communication, ou en tant que serveur. 1.3.2 Exigences générales de conception de l’ATL Cette nouvelle architecture pour la couche Transport doit permettre de faciliter l’accès aux protocoles de Transport en abstrayant le développeur d’applications de la complexité relative au choix de protocole et à son utilisation. Cette couche vise également à permettre un accès à l’ensemble des services disponibles, ceci de façon hautement configurable et personnalisé en fonction du contexte applicatif, machine et réseau, brisant ainsi la dépendance classique entre applications et protocoles de Transport dans le but d’offrir davantage de souplesse au développement et à la maintenance des applications. L’un des objectifs de conception de l’ATL est qu’il dispose de capacités d’autonomie qui lui permettent de tenir compte en temps réel, dans ses choix de composition, des évolutions des besoins applicatifs et de l’état du réseau. Par ailleurs, l’architecture de l’ATL doit faciliter le développement, la mise à jour et l’intégration des nouvelles solutions protocolaires en exonérant les développeurs d’applications, de protocoles et de systèmes des conséquences liées à toute sorte de modification dans les protocoles de Transport. Enfin, l’ATL doit prendre en compte d’autres considérations relatives au dé- ploiement de ces nouvelles solutions. 1.3.3 Paradigmes de conception relatifs à l’architecture de l’ATL Pour répondre aux exigences de conception de l’ATL, quatre paradigmes de base ont été retenus, dont l’application sera décrite dans les chapitres 2 et 3 : – le paradigme associé aux architectures dites basées-composant ; – le paradigme associé aux architectures dites orientées-services ; 391. Contexte, Problématique, État de l’art et Positionnement – le paradigme de l’Autonomic Computing (AC) ; – la dimension sémantique. 1.3.3.1 Conception logicielle basée composants La notion de « basé composants »est un paradigme de conception logicielle qui vise à faciliter le développement des systèmes complexes en séparant ces derniers en un ensemble de composant élémentaires. La facilité vient du fait que la division du système le rend moins complexe et permet en plus de déléguer chaque composant à un groupe de développeurs appropriés. Par ailleurs, les composants étant développés séparément, ils peuvent être utilisés par plusieurs autres composants par le biais d’interfaces clairement définies. Cette capacité de réutilisation permet d’économiser du temps et de l’espace. Généralement, le recours au basé composant est à des fins d’optimisation. Cependant, dans le cas d’architectures extensibles, comme le cas des drivers systèmes par exemple, l’approche de conception logicielle basée composant est la seule solution pour assurer cette extensibilité. 1.3.3.2 Conception logicielle orientée service L’« orienté services »est un autre paradigme de conception logicielle qui permet une séparation nette entre le service offert et la façon avec laquelle il est offert (son implémentation). Cette séparation offre, d’une part, une abstraction complète en réduisant les interactions à l’interface du service. D’autre part, elle permet plus de souplesse à l’architecture quant à sa maintenance et son extensibilité. La gestion des services dans de telles architectures est, par exemple, effectuée en se basant sur des descriptions sémantiques des services et de leurs interfaces. 1.3.3.3 Autonomic Computing Le concept d’AC a été proposé par IBM pour faire face à la complexité croissante dans la gestion jusque-là manuelle des différentes facettes relevant des technologies de l’information, et en particulier des systèmes logiciels. Le principe est d’intégrer des capacités d’auto-gestion dans ces systèmes induisant une intervention minimale des utilisateurs. IBM a également proposé une architecture fonctionnelle basée sur un ensemble de composants et d’interfaces bien définies ainsi que d’un cahier des charges précis du comportement individuel et collectif attendu de la part des différents composants du système. Cette architecture, dont les points d’entrée et de sortie sont équivalents à des capteurs (sensors) et à des actionneurs (actuators) distingue quatre fonctions majeures : le monitorage du système auto-géré, l’analyse des données capturées et l’identification de symptômes, la planification des actions à entreprendre pour répondre à ces symptômes, et finalement la mise en œuvre de ces actions. Dans les grandes lignes, les actions entreprises 401.4. Conclusion peuvent relever de la configuration du système, de l’optimisation de ce système, de sa réparation ou encore de sa sécurisation. 1.4 Conclusion L’objectif général de ce chapitre était de présenter la problématique adressée dans notre travail de thèse et de positionner la proposition soutenue dans l’état de l’art des protocoles de Transport sous-jacents au transfert des applications distribuées dans l’Internet. Pour cela, nous avons tout d’abord présentés les évolutions de ces 20 dernières années du contexte de notre travail, constitué des réseaux supports de l’Internet, des applications distribuées et de leurs besoins, et enfin des terminaux sur lesquelles s’exécutent ces applications. Nous avons ensuite analysé les limites des protocoles de Transport face à ces évolutions, en identifiant cinq points durs de problématique : – problème de complexité de choix ; – problème d’extensibilité ; – problème de configurabilité ; – problème d’assujetissement ; – problème de déploiement ; auxquels nous avons confronté les différentes solutions de l’état de l’art selon trois points de vue : le développeur d’application, le développeur de système d’exploitation et le développeur de protocoles. Si certains de ces protocoles répondent à différents degrés à une partie de ces points, aucune ne les satisfait tous. Notamment, la complexité de choix et l’assujettissement ne sont adressés par aucune. La démonstration de ces limites nous a conduits à positionner notre proposition, l’ATL. L’ATL n’est pas une nouvelle proposition de protocole, mais une proposition d’architecture pour la couche Transport, orientée service et basée composants, créant une véritable abstraction du service sous-jacent. Les enjeux de l’ATL sont multiples et visent en particulier à soustraire le choix et la gestion du protocole de Transport utilisé au développeur d’applications, lui permettant ainsi de concentrer sa demande sur le service requis et non plus la solution protocolaire à mettre en place pour assurer ce service. L’ATL permet ainsi l’intégration transparente de nouveaux protocoles et mécanismes protocolaires sans intervention au niveau de l’application. Dans la suite de ce document, le chapitre 2 se focalise sur la définition des différents composants de l’ATL, à différents niveaux de description, leurs rôles, leur organisation et les échanges qu’ils effectuent entre eux. Le chapitre 3 se concentre ensuite sur la description comportementale de ces composants dans deux cas d’uti- 411. Contexte, Problématique, État de l’art et Positionnement lisation centraux : l’ouverture d’un point d’accès au service de Transport par une application, et la reconfiguration dynamique d’un service de Transport. 42CHAPITRE 2 Architecture de l’ATL Ce chapitre présente le modèle architectural (ou structurel) de l’ATL suivant le plan ci-dessous. Dans la première partie (section 2.1), nous détaillons les exigences de conception de l’ATL introduites au chapitre 1. Nous présentons ensuite les principes permettant d’y répondre et enfin les approches logicielles envisagées pour implanter ces principes. De l’exposé de ces approches, nous dégageons enfin les fonctionnalités attendues de l’ATL. La seconde partie du chapitre (section 2.2) présente le modèle architectural de l’ATL suivant le formalisme UML 2.0. Les cas d’utilisation de l’ATL sont tout d’abord introduits. Le modèle général de l’ATL est ensuite présenté. Vient enfin la présentation des différents composants de l’ATL distingués en composants de premier niveau et composants secondaires. La dernière partie (section 2.3) conclut le chapitre et introduit le chapitre 3, dédié à la description comportementale de l’ATL au travers de deux cas d’utilisation. Sommaire 2.1 Exigences de conception et principes l’ATL . . . . . . . . . . . 44 2.1.1 Exigences de conception de l’ATL . . . . . . . . . . . . 44 2.1.2 Principes des solutions proposées en réponse aux exigences de conception de l’ATL . . . . . . . . . . . . . . 46 2.1.3 Approches d’implantation de ces principes . . . . . . . 48 2.1.4 Fonctionnalités de l’ATL . . . . . . . . . . . . . . . . . 53 2.2 Architecture de l’ATL . . . . . . . . . . . . . . . . . . . . . . . 54 2.2.1 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 54 2.2.2 Modèle d’architecture de l’ATL . . . . . . . . . . . . . 57 432. Architecture de l’ATL 2.2.3 Composants de base de l’ATL . . . . . . . . . . . . . . 60 2.2.4 Composants secondaires . . . . . . . . . . . . . . . . . 69 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.1 Exigences de conception et principes l’ATL Cette section présente les exigences de conception et les principes de l’ATL. Notons que cette section ne présente pas l’architecture de l’ATL, cette partie faisant l’objet de la section 2.2. 2.1.1 Exigences de conception de l’ATL Pour aborder les cinq points de la problématique énoncée au chapitre 1, l’ATL doit répondre à un certains nombre d’exigences que nous introduisons ci-après. Face à la complexité liée à la connaissance, au choix et à l’utilisation des solutions protocolaires, l’ATL doit permettre aux développeurs d’applications : – de se voir masquer la connaissance et la complexité du choix des solutions protocolaires à invoquer ; autrement dit, partant d’une spécification par le développeur d’application des caractéristiques du service souhaité, c’est à l’ATL que revient le choix de la solution protocolaire sous-jacente la plus adaptée ; notons que cette abstraction ne doit pas fermer la possibilité pour un développeur averti, d’effectuer par lui-même le choix de la solution protocolaire à mettre à œuvre ; – de se voir masquer la complexité d’utilisation des solutions protocolaires qui seront invoquées ; autrement dit, le développeur d’application doit disposer d’une Application Programming Interface (API) générique, lui permettant de caractériser le service souhaité, et non le protocole ; l’ATL doit cependant permettre la prise en compte des application existantes — applications dites legacy — traditionnellement basées sur TCP et UDP et sur les API correspondantes — il ne s’agit donc pas de réécrire ces applications — une API supplémentaire, permettant d’exprimer la solution protocolaire souhaitée, doit enfin être mise à disposition des développeurs avertis. Face au problème de dépendance des applications aux solutions protocolaires, l’ATL doit permettre une adaptation de la solution protocolaire retenue en réponse à une évolution du contexte machine/réseau, ou bien à une modification de l’expression du service requis par l’application. Cette adaptation consiste 442.1. Exigences de conception et principes l’ATL soit en la modification de certains des paramètres de la solution, soit en la modi- fication de la structure même de la solution, par exemple par remplacement d’un mécanisme protocolaire par un autre, plus adapté au nouveau contexte. – En réponse à une évolution du contexte machine/réseau, l’ATL doit donc être doté d’une capacité d’autonomie dans la prise de connaissance du contexte et de ces évolutions, en plus de celle liée au choix et à la mise en œuvre des solutions protocolaires à invoquer. – En réponse à une évolution des besoins applicatifs, la même capacité d’autonomie est requise de la part de l’ATL dans le choix et la mise en œuvre des adaptations de la solution protocolaire en cours. Vis à vis de la prise de connaissance de l’évolution des besoins applicatifs, l’ATL doit au moins offrir — via l’API générique — la possibilité aux développeurs d’applications de modifier les caractéristiques du service requis durant le temps d’exécution de l’application. Cette possibilité est donc offerte à des applications évoluées, conçues de sorte à pouvoir adapter leurs besoins aux variations du contexte considéré. Notons qu’idéalement, l’ATL pourrait être doté d’une capacité d’autonomie dans la prise de connaissance du contexte applicatif, et inférer par lui-même l’évolution des besoins applicatifs ; cette dernière possibilité n’a pas été considérée dans nos travaux et en constitue l’une des perspectives. Face au problème d’extensibilité des solutions protocolaires, lorsqu’apparaît une nouvelle version d’un protocole existant ou bien qu’émerge une nouvelle solution protocolaire — qu’il s’agisse d’un protocole ou d’un mécanisme, l’ATL doit permettre son intégration au sein de l’ensemble des services et solutions protocolaires qu’il gère déjà, en vue de la mise à disposition du service correspondant et de l’utilisation de la solution protocolaire. Face au problème de manque de configurabilité du service requis, c’est à dire la difficulté pour un développeur d’application de pouvoir requérir un service particulier plutôt que tous ceux imposés par les protocoles basés sur un principe de conception « monolithique » tels que TCP, l’ATL doit résoudre le problème grâce à la nature « composable » des différents protocoles et mécanismes protocolaires qu’il gère (chaque protocole pouvant se voir adjoindre des mécanismes externes), mais également par une connaissance complète de l’étendue de la configurabilité de chaque protocole et mécanisme protocolaire qu’elle peut instancier. Ceci permet un plus grand contrôle et une plus grande latitude dans les décisions concernant les services que l’ATL peut mettre en œuvre pour satisfaire les besoins des applications. Grâce à ces principes, l’ATL peut virtuellement configurer n’importe quel service à volonté, via les paramètres variables des composants 452. Architecture de l’ATL qu’elle instancie, ou par l’adjonction de mécanismes externes venant palier un manque. Face au problème d’acceptabilité des nouvelles solutions protocolaires, on observe les deux points suivants. – Le principal souci lié aux solutions nouvelles tient à leur capacité à être utilisées par les applications et à être acceptées par le réseau. En libérant l’application du choix de la solution protocolaire, l’ATL adresse ainsi le premier problème. Il doit par ailleurs être doté d’une capacité à choisir les solutions à instancier en fonction de l’environnement réseau — qui peut par exemple bloquer les flux non TCP via des middleboxe configurées à cet effet — pour répondre au problème d’acceptabilité par le réseau. – Le déploiement de L’ATL pose également un problème en lui-même dans la mesure où l’on ne doit pas imposer son déploiement sur toutes les machines, ni son utilisation par une application initialement conçues sur les bases de la couche Transport classique. La conception de l’ATL doit donc répondre à cette double exigence. 2.1.2 Principes des solutions proposées en réponse aux exigences de conception de l’ATL Afin de répondre aux différentes exigences précédentes, l’ATL a été conçu suivant certains principes que nous présentons ici. La mise en œuvre de ces principes est elle-même basée sur un ensemble de paradigmes de conception décrits dans la section 2.1.3. Premier principe : l’abstraction. Le principe d’abstraction est le principe clé de la solution que propose l’ATL. En effet, tout réside dans l’idée de séparer les détails d’implémentation et de gestion des solutions protocolaires, des applications qui vont en utiliser les services. Suivant ce principe, on limite les interactions entre les applications et la couche Transport à un ensemble d’interfaces génériques, ce qui a comme conséquence : – de libérer les développeurs d’applications du choix et de la difficulté d’utilisation des solutions protocolaires sous-jacentes, et répond donc au problème de la complexité protocolaire ; – de passer, du point de vue de l’application, d’un paradigme d’utilisation de protocoles à un paradigme d’utilisation de services, levant ainsi la dé- pendance des applications aux solutions protocolaires en leur permettant de pouvoir s’exécuter « au-dessus » de n’importe quel protocole offrant le service souhaité ; 462.1. Exigences de conception et principes l’ATL – d’effectuer des modifications sur les protocoles et les mécanismes protocolaires sans conséquence sur les applications, répondant ainsi — en tout ou partie — à l’objectif d’acceptabilité par les applications. Second principe : l’extensibilité. Le principe d’extensibilité réside dans la capacité de l’ATL à intégrer de nouvelles solutions protocolaires, ou à mettre à jour les solutions existantes sans aucune implication supplémentaire sur les applications ou les systèmes. Le principe d’abstraction de l’ATL répond aux besoins des applications, en ceci qu’il n’y aura aucune implication sur ces dernières si une modification se porte sur une solution. Concernant le besoin des développeurs de systèmes d’exploitation, l’architecture de l’ATL doit être telle que l’intégration de nouveaux composants impose uniquement des mises à jour de la base de connaissance de l’ATL, sans mise à jour des composants de gestion de l’ATL. Enfin, ces modifications, notamment celles conduisant à offrir de nouveaux services de Transport, doivent être communiquées de façon publique aux développeurs d’applications. Les mises à jour doivent ainsi être des opérations simples qui seront assurées par une entité de l’ATL que le développeur du protocole aura à invoquer pour que sa solution protocolaire soit prise en compte, en lui transmettant un certain nombre d’informations décrivant sa nouvelle solution. Troisième principe : la configurabilité. La configurabilité est un principe d’optimisation qui permet d’offrir à l’application l’ensemble de services dont elle a besoin et uniquement ceux-ci — c’est à dire sans service supplémentaire. Ce principe va à l’encontre du caractère monolithique de la plupart des protocoles de Transport existants qui impose aux applications tous les services pré-implantés. Cette configurabilité peut être assurée par l’ATL ou par le composant protocolaire lui-même. Dans le premier cas, l’ATL doit sélectionner et composer un ensemble optimal de composants qui offriront le service demandé par l’application. Dans le deuxième cas, l’ATL doit offrir, pour les composants qui sont à la base configurables — tels que ETP — un environnement dans lequel ils pourront conserver leur caractère configurable. Quatrième principe : l’autonomie. A l’instar de la configurabilité, l’autonomie est un principe d’optimisation qui permet à l’ATL de prendre des décisions en fonction des changements du contexte applicatif et réseau. La prise de décision est relative au choix de la composition « optimale » de protocoles/composants protocolaires en réponse à une requête de l’application, que ce soit au moment de 472. Architecture de l’ATL l’établissement de la connexion, ou durant la communication en cas de changement de contexte. Un changement de contexte se produit lorsque les besoins de l’application changent, par exemple lorsque celle-ci passe d’un type de fonctionnalité à un autre ou d’un type de donnée à un autre. Les changements de contexte peuvent aussi être liés au réseau : il peut s’agir d’une diminution ou d’une augmentation des paramètres réseau, tel que le débit, le délai, le taux de perte, ou encore l’apparition ou la disparition d’un problème de congestion ou le changement du type de réseau (Ethernet vers 3G par exemple). Dans toutes ces situations, aussi bien avant ou durant la communication, le principe d’autonomie est de permettre une adaptation de la solution protocolaire transparente pour l’application. 2.1.3 Approches d’implantation de ces principes La mise en œuvre des principes précédents repose sur un certain nombre de paradigmes de conception qui sont présentés dans cette section. 2.1.3.1 Approche orientée services L’approche orientée services vise principalement à séparer les services offerts de leur implémentation interne en réduisant les interactions entre l’application et ces derniers à une simple interface. Cette façon de faire offre une abstraction complète des solutions techniques utilisées, et constitue ainsi l’approche la plus importante de notre solution. L’objectif est de définir chaque protocole ou composant protocolaire par l’ensemble des services qu’il offre. Du point de vue de l’application, il n’y aura plus de notion de protocole de Transport, mais seulement de service de Transport, au sens où elle n’invoque plus un protocole particulier, tel que TCP ou UDP, mais un service particulier, par exemple un service orienté-connexion en mode flux d’octets avec garantie d’ordre et de fiabilité totale. Le choix du protocole et du ou des composants protocolaires qui assureront le service requis ne sera plus à la charge de l’application. Le principe de mise en œuvre repose sur la capacité de l’ATL à maintenir une liste des correspondances entre protocole ou composant protocolaire et service(s) correspondant(s) et, quand il reçoit une requête d’une application contenant une liste de services souhaités, à chercher dans la liste des correspondances la composition protocolaire la plus adaptée pour assurer l’ensemble des services. De cette façon, l’approche orientée services assure parfaitement le principe d’abstraction de l’ATL, et permet de répondre à plusieurs parties de la problématique : 482.1. Exigences de conception et principes l’ATL – en réduisant l’interface avec les applications à une liste de services accessibles, on élimine le problème de complexité relatif : – au choix du protocole de Transport, car celui-ci n’est plus de l’ordre des applications mais de l’ATL, – à l’usage de celui-ci car il n’y aura plus besoin de connaitre les détails relatifs au fonctionnement de chaque protocole ou mécanisme protocolaire comme cela se fait actuellement, l’application ayant simplement à connaitre l’ensemble des services offerts et à solliciter ceux qui lui conviennent ; – la séparation des détails techniques permet, par le biais des services, de lever la dépendance classique entre applications et protocoles et ce, sur deux plans : – tout d’abord, les applications ne seront plus écrites pour un protocole particulier mais pour un ensemble de services et peuvent donc être exécutées « au-dessus » de n’importe quelle solution protocolaire offrant les mêmes services, – ensuite, les modifications apportées aux composants protocolaires n’affecteront pas le fonctionnement des applications, puisque ces modifications ne leur seront pas visibles. La réponse au problème de dépendance permet ainsi de répondre à une partie du problème de l’extensibilité concernant les applications. Ceci signifie qu’il sera possible, avec une approche orientée services, d’ajouter ou de mettre à jour n’importe quelle solution protocolaire au sein de l’ATL sans aucune conséquence sur les applications. Pour les autres parties du problème d’extensibilité (i.e. concernant les développeurs de systèmes ou de protocoles), la solution nécessitera l’adoption d’approches complémentaires, tel que préconisé par la suite ; – Enfin, pour les protocoles qui sont à la base configurables (tels que ETP), l’approche orientée service permet de conserver leur configurabilité avec la possibilité de paramétrage des services. Chaque service peut disposer d’une liste de paramètres que l’on peut ou doit lui fournir à son invocation. Ceci concerne la configurabilité des services eux-mêmes, et pour ce qui est de la configurabilité de l’ensemble des services, c’est à dire le fait de choisir un sous ensemble des services offerts, ceci va de soit, puisque dans ce paradigme, il n’y a aucune différence entre les services offerts séparément par des composants indépendants et les services offerts séparément par un même composant. Conséquences en termes de besoins fonctionnels d’une approche orientée services. L’adoption d’une approche orientée services impose la mise en œuvre, au sein de la couche Transport, de fonctions supplémentaires relatives à la gestion des services. Ces fonctions concernent notamment : – l’intégration des nouveaux services incluant leur prise en compte par les 492. Architecture de l’ATL composants de gestion de l’ATL ; – l’association entre services et composants afin de facilement trouver quels sont les services fournis par chaque composant ; – la vérification de leurs disponibilité sur les hôtes locaux et distants. Ces différentes fonctions sont regroupées dans la fonctionnalité de gestion des services et seront déléguées à différents composants de l’architecture de l’ATL. Elles sont décrites plus en détails en section 2.1.4.1 de ce chapitre. 2.1.3.2 Approche basée composants L’approche basée composants concerne l’organisation interne des solutions protocolaires qui seront gérées par l’ATL. Le principe est de mettre chaque protocole ou composant protocolaire dans un composant logiciel indépendant offrant un ensemble de services via une interface propre. En séparant chaque protocole ou composant protocolaire en un composant logiciel indépendant, on facilite son intégration dans l’ATL. L’ajout à la bibliothèque de composants et la mise à jour de la base de connaissances de cette dernière constituent ainsi les seules étapes de l’installation d’un nouveau composant : – aucune partie du système d’exploitation ni de l’architecture de l’ATL ne sera à modifier ; cette souplesse assure une extensibilité complète de la couche Transport, et répond ainsi aux limitations d’extensibilité de la couche actuelle du point de vue des développeurs de système et de protocole ; – en conséquence, le développeur de protocole n’aura plus à se préoccuper de la prise en charge de son protocole par le système ; – en parallèle, en associant chaque composant à un ensemble de services, les mises à jour seront transparentes pour les applications ; de cette façon, nous répondons à l’ensemble des problèmes relatifs à l’extensibilité. Par ailleurs, la séparation des composants protocolaires permet d’offrir la possibilité de choisir et de composer au besoin les composants qui assureront un service donné, au sens où les applications ne seront plus obligées de fonctionner avec des services insuffisamment adéquats, comme c’est le cas avec l’architecture actuelle de la plupart des protocoles de Transport à caractère monolithique. Le principe de configurabilité est ainsi assuré. Enfin, cette approche permet la création de solutions protocolaires à granularité variable. La possibilité d’exprimer la dépendance d’un composant envers un autre ou envers un service assuré par un autre est capitale. Ainsi, un développeur souhaitant créer un mécanisme de contrôle des pertes et nécessitant un estampillage des paquets par un numéro de séquence pourra soit développer son propre estampillage, soit déclarer son composant protocolaire dépendant de l’utilisation d’un composant d’estampillage adéquat. 502.1. Exigences de conception et principes l’ATL Conséquences en termes de besoins fonctionnels d’une approche basée composants Les conséquences de l’approche basée composant concernent principalement leurs intégrations au sein de l’ATL. Les interfaces de ces composants doivent être définies de façon suffisamment générique pour qu’ils puissent être intégrés de façon transparente dans l’ATL, c’est-à-dire sans avoir à récrire le code de l’ATL. Enfin, celle-ci doit pouvoir les utiliser de façon séparée selon les besoins des applications. De plus, l’ATL doit les invoquer de façon indépendante et gérer les liens entre eux tout au long de la communication. 2.1.3.3 Approche autonomique L’autonomie de l’ATL vise à rendre transparent pour l’utilisateur humain les prises de décision relatives au choix des solutions protocolaires, à l’initiation de la communication ou en réponse à un changement du contexte du réseau. Ceci impose donc la capacité de l’ATL à trouver des compositions optimales pour satisfaire les applications en tenant compte de leurs besoins et de l’état du réseau. Dans une approche autonomique, cette prise en compte ne doit pas se limiter au moment de l’ouverture de connexion, mais doit être poursuivie tout au long de la communication pour s’adapter dynamiquement aux changement du contexte applicatif ou réseau, c’est-à-dire au changement des besoins applicatifs ou de l’état du réseau. Conséquences en termes de besoins fonctionnels d’une approche autonomique En conséquence, l’ATL doit, d’une part, effectuer une surveillance permanente du réseau afin d’en connaître l’état en temps réel, et éventuellement détecter tout changement conséquent. Par la suite l’ATL doit pouvoir trouver la composition protocolaire optimale pour le contexte courant (état du réseau et besoins des applications) à l’ouverture de la communication aussi bien qu’au cours de celle-ci. D’autre part, elle doit offrir aux applications la possibilité de pouvoir modifier leurs requêtes (services requis) durant la communication et ce sans interruption. Ces différentes fonctions sont regroupées au sein du composant gestionnaire de l’autonomie, l’Autonomic Manager, introduit en section 2.2.3.2 dans ce chapitre. 2.1.3.4 Synthèse Le tableau 2.1 fournit une vue synthétique des sections précédentes. 512. Architecture de l’ATL Problèmes Exigences de conception de l’ATL Principes de conception de l’ATL Approche logicielle d’implantation Complexité Masquer aux développeurs d’applications la connaissance et la complexité du choix des solutions protocolaires à invoquer. Masquer aux développeurs d’applications la complexité d’utilisation des solutions protocolaires qui seront invoquées. Abstraction Sémantique Approche orientée services Approche basée sémantique Dépendance Permettre une adaptation de la solution protocolaire retenue en ré- ponse à une évolution du contexte machine/réseau, ou bien à une modification de l’expression du service requis par l’application, c’est- à-dire : Abstraction Autonomie Approche autonomique – être doté d’une capacité d’autonomie dans la prise de connaissance du contexte et de ces évolutions, en plus de celle liée au choix et à la mise en œuvre des solutions protocolaires à invoquer ; – être doté d’une capacité d’autonomie dans le choix et la mise en œuvre des adaptations de la solution protocolaire en cours ; – offrir aux développeurs d’applications la possibilité de modifier les caractéristiques du service requis durant le temps d’exécution de l’application. Manque d’extensibilité Permettre son intégration au sein de son pool de services et de solutions protocolaires, en vue de la mise à disposition du service correspondant et de l’utilisation de la solution protocolaire. Extensibilité Approche basée composants Manque de configurabilité Gérer la nature composable des différents protocoles et mécanismes protocolaires, chaque protocole pouvant se voir adjoindre des mécanismes externes. Configurabilité Table 2.1: Synthèse des problèmes, exigences, principes et approches de conception de l’ATL 522.1. Exigences de conception et principes l’ATL 2.1.4 Fonctionnalités de l’ATL Cette section décrit l’ensemble des nouvelles fonctionnalités nécessaires pour mettre en œuvre les principes décrits précédemment. Ces fonctionnalités résultent directement des approches de conception de l’ATL, et sont introduites précédemment pour chacune des approches. Il s’agit en d’autres termes de toutes les fonctionnalités qui ne figurent pas dans l’approche traditionnelle de la couche et des protocoles de Transport, et qui permettent d’assurer la valeur ajoutée apportée par la nouvelle architecture de l’ATL. Ceci concerne principalement la gestion des services et l’autonomie. 2.1.4.1 Fonction de gestion des services La gestion des services est une fonctionnalité qui résulte de l’approche orientéeservices permettant de réduire la complexité de l’interface de l’ATL et d’assurer son extensibilité. Elle regroupe les tâches relatives à l’intégration de nouveaux composants protocolaires dans l’ATL et la correspondance entre ceux-ci et les services qu’ils offrent. La première tâche sera donc la constitution et le maintien de la liste des services au fur et à mesure que de nouveaux composants sont ajoutés à l’ATL. Ce rôle incombe à l’intégrateur de services. L’information sur la correspondance entre composants protocolaires et services offerts est ainsi intégrée dans la base de correspondance des composants et des services afin que les applications puissent les invoquer et que l’ATL puisse utiliser le nouveau composant lors des prochaines requêtes applicatives si nécessaire. Une fois les services stockés, les applications peuvent désormais les invoquer auprès de l’ATL. Pour ce faire, la base de correspondance des composants et des services permet sa consultation afin de retrouver les différents composants pouvant, seuls ou au sein d’un ensemble composite, assurer le service requis. 2.1.4.2 Fonction de gestion autonomique de la communication Cette fonctionnalité assure le caractère autonomique de l’ATL qui vise à décider du service composite initial à mettre en place et à adapter le comportement de celui-ci de façon autonome selon les variations du contexte réseau (changement du type du réseau ou de son état). Elle comporte quatre taches correspondant aux quatre parties de la boucle autonomique décrite un peu plus loin. La première tâche consiste à recueillir les informations utiles sur l’état du ré- seau. L’ATL doit donc disposer d’un service de monitoring du réseau, en souscrivant par exemple à un service externe ou en implantant le sien propre. Une fois ces informations recueillies (débit, délai, taux de perte . . . ), l’ATL doit les 532. Architecture de l’ATL analyser afin de détecter les variations et subséquemment le besoin éventuel d’un changement de la composition protocolaire courante. En cas de besoin d’un changement de composition, l’ATL doit revoir les composants sélectionnés pour chaque service et l’affiner, éventuellement une autre fois, afin de trouver pour chaque service le composant le plus adapté à l’état courant du réseau, en tenant compte de l’ensemble des paramètres de ces services pour lesquelles des information de surveillance ont été recueillies. 2.1.4.3 Fonction d’accueil, d’assemblage et de mise en œuvre des compositions L’ATL doit également permettre l’accueil des composants protocolaires utilisés dans la mise en place des différents services composite. Ainsi, si plusieurs implé- mentations peuvent être possibles, l’architecture doit prendre en compte le besoin d’une structure où prendra place cette composition et permettant son fonctionnement — en assurant notamment l’ordonnancement des messages à travers les différents composants, sa configuration, sa modification voire sa suppression. Les différents composants assurant ces fonctionnalités seront décrits en 2.7. 2.2 Architecture de l’ATL Cette section présente le modèle architectural de l’ATL ainsi que ses différents composants. Suivant une approche basée sur le formalisme UML 2.0, nous décrivons d’abord les cas d’utilisation de l’ATL (section 2.2.1). Nous présentons ensuite le modèle d’architecture de l’ATL et de ses principaux composants (section 2.2.3). Nous décrivons enfin les composants secondaires de l’ATL (section 2.2.4). 2.2.1 Cas d’utilisation L’architecture d’une solution telle que l’ATL doit être guidée par des cas d’utilisation faisant intervenir les différents acteurs du système. Ces acteurs peuvent être les utilisateurs du système ou d’autres éléments interagissant avec le système lors de son utilisation. Nous avons déjà évoqué les différents types d’applications utilisant l’ATL et de systèmes l’hébergeant. Ceux-ci donnent lieu aux cas d’utilisation de la figure 2.1. On peut voir sur ce diagramme que les applications représentent des acteurs primaires, placés à gauche du système, indiquant que ces acteurs sont les initiateurs des cas d’utilisations auxquels ils sont reliés. Le réseau, en revanche est un acteur secondaire. Il intervient dans la réalisation des cas d’utilisation auxquels il est relié, mais n’initie pas ces derniers. 542.2. Architecture de l’ATL Figure 2.1: Cas d’utilisation impliquant les applications Ce diagramme illustre également les prérogatives respectives des différents types d’applications. On y voit que les applications legacy ne peuvent qu’initier le cas d’utilisation « Transfer data » quand les applications aware et smart peuvent également exprimer les services à utiliser. Les applications smart peuvent également récupérer la responsabilité des choix normalement effectués par l’ATL dans la composition de composants protocolaires qui sera instanciée, via le cas d’utilisation « Select service ». Au delà des applications, l’ATL va également devoir offrir certains services aux utilisateurs humains. Ceux-ci peuvent être de plusieurs types et présentent des besoins différents, il s’agit : de l’utilisateur de la machine (ou utilisateur du système), de l’administrateur de la machine (ou administrateur du système) et du développeur de mécanismes protocolaires. Nous pouvons les voir sur le diagramme de cas d’utilisation de la figure 2.2. L’utilisateur du système doit pouvoir exprimer certaines préférences quant à l’utilisation des ressources disponibles sur sa machine. Ainsi la possibilité de modi- fier les politiques de prise de décision en fonction des différentes applications doit lui être offerte. Par exemple, l’utilisateur doit pouvoir exprimer qu’il veut que le 552. Architecture de l’ATL Figure 2.2: Cas d’utilisation impliquant les utilisateurs humains débit d’émission de son gestionnaire de téléchargement BitTorrent soit limité, afin de laisser une capacité plus importante pour le serveur web qui héberge son blog. L’administrateur du système doit également avoir la possibilité d’exercer ce genre de contrôle. Les préférences qu’il exprime doivent de plus avoir préséance sur celles exprimées par les utilisateurs du système. De plus, l’administrateur doit pouvoir aller modifier le comportement de l’ATL en influant sur les solutions que celle-ci peut instancier pour satisfaire les services requis par les applications. Un administrateur doit pouvoir interdire un protocole, ou en désactiver certaines options, modifier la connaissance qu’a l’ATL de ceux-ci afin que ses décisions futures soient conformes aux politiques de son entreprise. Par exemple, il doit pouvoir imposer d’utiliser un chiffrement via SSL au lieu de TLS, ou d’utiliser un contrôle de congestion basé sur TFRC et non sur TCP. Finalement, le dernier utilisateur humain est le développeur de composants protocolaires à intégrer à l’ATL. L’ATL doit en effet offrir les moyens pour pouvoir développer de nouveaux protocoles, de nouvelles implémentations pour tel ou tel mécanisme, et permettre leur intégration de manière transparente pour les autres acteurs. Les acteurs secondaires ont également un rôle important à jouer dans ces cas d’utilisation. Ceux-ci sont de deux types. Tout d’abord, les systèmes avec lesquels 562.2. Architecture de l’ATL on souhaite communiquer. Comme nous l’avons indiqué, ces systèmes peuvent être de deux types : les systèmes legacy qui ne disposent pas de l’ATL ; les systèmes ATL-enabled ou enabled qui en disposent. Il est capital qu’un système enabled soit capable d’initier une communication ou d’accepter une communication entrante avec un autre système enabled, bien évidemment, mais également avec un système legacy. Sans cette condition, l’adoption de l’ATL serait compromise car cela scinderait le parc informatique mondial en deux parties non interopérables. Ainsi, afin d’adapter son comportement au type de système avec lequel elle souhaite communiquer, l’ATL doit posséder un système de découverte de la présence de l’ATL sur le système distant. Le réseau constitue l’autre acteur secondaire, indispensable puisque c’est par lui que vont transiter les messages échangés entre les différentes instances de l’ATL. Comme indiqué dans le premier chapitre, celui-ci fait preuve aujourd’hui d’une grande hétérogénéité et d’une grande dynamicité au niveau de ses caractéristiques et de leurs variations au cours du temps. Les multiples technologies d’accès et la présence de différents types de middleboxes créent une variété de scénarios possibles. Le rôle de l’ATL sera de s’adapter à ces différents scénarios de manière à toujours satisfaire au mieux l’application, en fonction des préférences des utilisateurs et administrateurs, et des solutions mises à disposition par les développeurs, en tenant compte de la présence ou de l’absence d’une instance de l’ATL sur le système distant avec lequel s’établit la communication. Pour tenir compte des variations dans le réseau, l’ATL va devoir en permanence surveiller ses performances afin de prédire ou détecter les changements qui seront susceptibles d’induire une modification de la solution choisie afin de maintenir un service acceptable. 2.2.2 Modèle d’architecture de l’ATL En observant les protocoles classiques et l’architecture actuelle de l’Internet, les différents types de fonctionnalités intervenant dans une communication pour acheminer les données, contrôler cet acheminement, et gérer la communication, peuvent être répartis selon les trois plans suivants. – Le plan de données gère l’acheminement à proprement parler des données de l’utilisateur. C’est lui qui s’occupe de l’encapsulation des messages, ou du multiplexage vers les différentes applications par exemple. Les protocoles permettant l’encapsulation de données, tels que IP au niveau réseau de la pile protocolaire, sont des protocoles du plan de données. Ils offrent un service d’acheminement à un niveau supérieur le requérant. Le plan de données de l’ATL remplit ce même rôle. 572. Architecture de l’ATL – Les plans de contrôle et de gestion, qui assurent la prise en charge des deux autres types de fonctions. Au sein de l’ATL, le contrôle et la gestion servent tous deux à gérer la communication, mais à des échelles de temps différentes : les actions de contrôle sont des actions à portée temporelle réduite ou courte, à l’échelle du paquet ou de quelques RTT, comme la vérification de l’intégrité d’un paquet, ou la détection de pertes ; les actions de gestion portent sur des échelles de temps plus grandes, comme les modifications de tables de routage, ou des règles de sécurité. Nous pouvons remarquer que dans les protocoles existants, les actions de contrôles sont souvent prises en charge par le protocole du plan de données. TCP ou Ethernet vérifient par exemple eux-mêmes si les unités de données qu’ils reçoivent sont erronées ou non. A l’inverse, les actions de gestion sont généralement effectuées par des protocoles dédiés, comme les protocoles de routage, dont RIP, OSPF, ou BGP sont les représentants les plus connus ; d’autres protocoles connus sont également des protocoles prenant en charge des actions de gestion : ICMP, ARP, SNMP, etc. Notons que ces protocoles sont souvent indifféremment qualifiés de protocoles du plan de contrôle ou de protocole du plan de gestion. Le but ici n’est pas de savoir lequel des deux est juste afin de rétablir une classification claire des protocoles selon ces trois plans. Nous utilisons ce vocabulaire afin de distinguer non pas différents types de protocoles, mais différents types d’actions, et remarquons alors que les actions de transfert de données et de contrôle sont souvent gérées par un même protocole, quand les actions de gestion sont souvent gérées par un protocole dédié. Nous effectuons la même dichotomie au sein de l’ATL où une partie de l’architecture sera dédiée à l’exécution de la communication, donc au transfert de données et au contrôle de celui-ci, et où une seconde partie sera dédiée à la gestion de la communication, grâce à une relation constante avec la première et qui permettra d’influer sur celle-ci. Articulée autour de ces trois types de fonctions, l’architecture de l’ATL repose sur l’identification des besoins des utilisateurs exprimés via les cas d’utilisation précédents. De ces cas d’utilisations et des considérations exposées dans la section précédente, nous détaillons un premier niveau d’architecture composite de l’ATL (section 2.2.2.1). Les détails des composants de base de premier niveau sont présentés en section 2.2.3. 2.2.2.1 Modèle général Pour offrir les différents services présentés ci-dessus, l’architecture de l’ATL s’organise en plusieurs niveaux de composants, représentés sur la figure 2.3. On observe sur ce diagramme différents composants nécessaires au bon déroulement de la prise en charge des communications. Pour la gestion de la commu- 582.2. Architecture de l’ATL Figure 2.3: Diagramme de structure composite de premier niveau nication proprement dite, le composant plus important est le Flow, qui contient deux composants principaux : – l’Autonomic Manager qui s’occupe de la gestion autonomique de la communication avant et après l’établissement de la connexion ; – le Data Plan qui s’occupe de la communication proprement dite, en accueillant l’ensemble des composants protocolaires pour la communication, dénommée également « service composite », destinée à une communication particulière. On remarque que le Flow dispose de deux interfaces vers l’application : la première sert à l’échange de données entre l’application et le Flow ; la seconde est l’interface de contrôle, permettant à l’application d’exprimer ses besoins ainsi que ses contraintes concernant les décisions de l’ATL dans le cas d’une application smart. Chaque Flow est associé à un et un seul point d’accès au service de Transport. 592. Architecture de l’ATL Le nombre de Flow présents au sein du système est donc variable avec le temps, et peut également être nul si aucune application n’a ouvert de communication. Chaque Flow n’appartient qu’à une et une seule application, mais une application peut posséder plusieurs Flow si elle ouvre plusieurs points d’accès. Un serveur web, par exemple, aura un Flow ouvert par client visitant le site qu’il héberge. Le Flow est décrit plus avant en section 2.2.3.1. Avant que ne débute effectivement une communication, l’Autonomic Manager d’un Flow utilise la base des composants et des services pour décider de la composition adéquate selon les besoins de l’application et l’état du réseau. Cette base, commune à tous les Flow du système, recense tous les composants protocolaires disponibles et les services qui leur sont associés et permet aux Autonomic Manager de choisir parmi cet ensemble le service composite le mieux adapté. L’intégrateur de services permet l’installation de nouveaux composants au sein de l’ATL, notamment via la mise à jour de la base des composants et services. Notons que celle-ci peut également être modifiée par un utilisateur humain tel qu’un administrateur système ou par un logiciel de gestion hiérarchiquement supérieur. Le rôle du Flow Creator est l’instanciation des Flow lors de la création d’un TSAP. Le Signalization Message Controler est le composant responsable de la signalisation relative aux informations globales. Finalement, le multiplexeur-démultiplexeur réseau (Net Mx/Dmx) constitue l’interface entre les Flow et le réseau. Ces composants sont décrits dans la section 2.2.4 relative aux composants secondaires. On remarque que l’ATL dispose, en plus des interfaces avec l’application et de celle avec la couche réseau sous-jacente, d’une interface d’administration destinée aux utilisateurs humains, afin de leur permettre d’exprimer des préférences générales comme l’indique le diagramme de cas d’utilisation de la figure 2.2. C’est à travers celle-ci que les commandes des utilisateurs et des administrateurs sont intégrées dans l’ATL. C’est également grâce à elle que des programmes extérieurs peuvent venir administrer l’ATL le cas échéant. 2.2.3 Composants de base de l’ATL Cette section est consacrée à la description du composant principal de l’ATL : le Flow et ses sous-composants. Ce sont eux qui vont accueillir et gérer la composition de composants protocolaires instanciant la communication. 2.2.3.1 Le Flow Le composant principal de l’ATL est le Flow. Un Flow est mis à disposition d’une application pour chaque point d’accès qu’elle ouvre. La décomposition du Flow, illustrée sur la figure 2.4, fait apparaître deux composants principaux : le Data Plan et l’Autonomic Manager, dont les fonctions 602.2. Architecture de l’ATL permettent de distinguer la prise en charge des actions de type transfert de données et contrôle pris en charge par les composants protocolaires (Data Plan), et les actions de gestion du service composite (Autonomic Manager). Figure 2.4: Composition d’un Flow Le Flow dispose de plusieurs interfaces : – la première le relie à l’application et est composée d’une partie données, permettant l’échange de ces dernières, et d’une partie contrôle, comme introduit en section 2.2.2.1 : – la partie données est redirigée vers le Data Plan, – la partie contrôle est redirigée vers l’Autonomic Manager, afin de lui communiquer les différentes informations sur les services désirés et les diffé- rentes contraintes que l’application souhaite exprimer ; – la deuxième interface relie le Flow à la couche réseau par le biais du Data Plan afin de permettre l’échange de données utilisateurs encapsulées ou à 612. Architecture de l’ATL destination de l’application. Celle-ci est reliée directement à la couche réseau sous-jacente en sens descendant et à un démultiplexeur dans le sens montant (cf. 2.2.4.3). La liaison entre l’Autonomic Manager et le Data Plan est décrite dans la section 2.2.3.2. Notons enfin que l’Autonomic Manager est également relié au Flow Creator, décrit en 2.2.4.1, et au Signalization Message Controler, décrit en 2.2.4.2. 2.2.3.2 L’Autonomic Manager L’Autonomic Manager est un des composants internes majeur d’un Flow. Avant d’en décrire l’architecture fonctionnelle dans le cadre de l’ATL, nous introduisons tout d’abord ce concept tel que défini par IBM. État de l’art relatif au concept d’Autonomic Manager tel que défini par IBM IBM définit l’Autonomic Manager comme le composant permettant la gestion autonome d’une ressource. Dans le cas de l’ATL, la ressource s’avère être un service composite, une composition de protocoles et mécanismes protocolaires destinés à satisfaire les besoins de l’application. L’Autonomic Manager est composé d’une boucle de contrôle constituée de quatre fonctions, et d’une base de connaissance à laquelle ces quatre fonctions peuvent accéder. Ces quatre fonctions sont les suivantes. Le monitoring : Le but de cette fonction est la surveillance des informations d’état du système et leur pré-analyse afin de détecter des symptômes d’un comportement potentiellement anormal ou qui dériverait de l’état souhaité. L’analyse : La fonction d’analyse est invoquée par la fonction de monitoring lorsque cette dernière détecte un symptôme. Le symptôme est utilisé afin de modéliser l’état actuel du système qui est alors comparé à l’état souhaité. Si les deux modèles divergent, une alarme est alors levée pour avertir la fonction suivante. La planification : Lorsque la fonction d’analyse lève une alarme, la fonction de planification prend en charge la décision des actions à entreprendre pour modifier le système afin de refaire converger son état vers l’état souhaité. En résulte un plan de modification, discuté en 2.2.3.2, qui est communiqué à la dernière fonction de la boucle. L’exécution : Cette dernière fonction prend en charge les modifications décidées par la fonction de planification. La réalisation effective, l’orchestration et la synchronisation des différentes étapes du plan de modification sont à la charge de cette fonction. 622.2. Architecture de l’ATL Ces différentes fonctions s’organisent autour de la base de connaissances comme le montre la figure 2.5. Cette base de connaissance sera décrite plus loin en 2.2.3.4. Figure 2.5: Organisation des fonctions de l’Autonomic Manager La communication entre la ressource gérée et l’Autonomic Manager est assurée par une interface nommée Touchpoint et capable d’un comportement de type capteur (sensor)afin de récupérer des informations sur la ressource, et de type effecteur (effector) afin d’appliquer des modifications sur la ressource. La figure 2.6 représente les différentes interactions possibles entre l’Autonomic Manager et le Touchpoint dans les deux types de comportement. Application au sein de l’ATL Au sein d’un Flow, la liaison entre l’Autonomic Manager et le Data Plan — qui représente la ressourcée gérée — est illustrée figure 2.4. Cette liaison permet à la fonction de monitoring de l’Autonomic Manager de récupérer les informations fournies par les différents composants protocolaires, et à la fonction d’exécution d’aller modifier les paramètres de ces composants, ou de modifier la structure composite elle-même. Les décisions prises par la fonction de planification de l’Autonomic Manager peuvent avoir une portée locale ou répartie. Portée locale : les décisions de l’Autonomic Manager n’impactent que les composants de l’hôte sur lequel il se trouve. Celles-ci n’ont aucune influence sur le système distant ou la liaison entre les deux systèmes, et ne nécessitent 632. Architecture de l’ATL Figure 2.6: Caractéristiques du Touchpoint et lien avec l’Autonomic Manager donc pas d’intervention de ce dernier. Informer l’hôte distant de ces décisions n’est a priori pas nécessaire mais peut cependant présenter un intérêt dans certains cas. Portée répartie : les décisions de l’Autonomic Manager impactent les composants situés sur l’hôte distant ou la liaison entre les deux hôtes, et nécessitent une intervention de ce dernier. Une synchronisation des deux systèmes pouvant être nécessaire, la présence d’un protocole de signalisation la permettant est requise ; dans l’architecture de l’ATL, cette signalisation relève de la fonction d’exécution de la boucle de contrôle. Sur ce second point, notons qu’une signalisation sera également nécessaire au niveau de la fonction de monitoring afin de requérir des informations de l’hôte distant ou de lui en fournir, ainsi qu’au niveau de la fonction de planification afin d’établir des prises de décisions en collaboration avec l’hôte distant. Selon les cas, l’Autonomic Manager ne sera pas seul gestionnaire de la communication. En effet, si l’hôte distant possède également l’ATL, les deux Autonomic Manager (un par Flow) devront être en contact afin d’échanger certaines informations, comme précisé dans la partie Monitoring. 642.2. Architecture de l’ATL Pour la même raison, les prises de décisions doivent également pouvoir être partagées. Les deux Autonomic Manager vont avoir une double responsabilité. – Tout d’abord, ils vont gérer individuellement les modifications locales de leur service composite respectif. En effet, la décision de modifier tel ou tel paramètre, d’enlever ou ajouter tel ou tel composant protocolaire, leur incombe tant que cette modification est purement locale. Par exemple, modifier à la volée l’algorithme de calcul du RTO dans le bloc de service TCP d’un certain Channel ne requiert aucune action de la part de l’Autonomic Manager pair. – La seconde responsabilité est la prise de décision répartie. Il s’agit cette fois de gérer les modifications qui vont requérir des décisions sur chaque hôte. Les deux Autonomic Manager doivent donc être en communication, afin de se transmettre les informations de monitoring nécessaires ainsi que les consignes d’exécution. Dans une prise de décision répartie les Autonomic Manager peuvent s’organiser de différentes manières. Nous identifions ici trois hiérarchies possibles : collaborative, participative et subordinative. En mode collaboratif : les deux Autonomic Manager ont un poids égal dans la prise de décision. Chaque décision ou compromis doit donc faire consensus afin d’être appliqué. Ce mode peut-être envisagé lorsque les deux flux applicatifs sont de même importance, comme dans le cas par exemple, d’une vidéoconférence en pair à pair, ou chaque participant envoie un flux vidéo et un flux audio, souvent du même ordre de qualité. Notons que le cas d’une vidéoconférence centralisée sur serveur est différent : le serveur jouant le rôle de point d’échange central des données celui-ci aura un rôle plus important. En mode participatif : chaque Autonomic Manager peut proposer des modi- fications ou des actions sur la gestion de la communication, mais la décision finale revient à l’un des deux seulement. L’Autonomic Manager « participant » ne peut que faire des propositions qui devront être finalement approuvées par l’Autonomic Manager « décidant ». Dans ce mode, l’Autonomic Manager participant devient géré par l’Autonomic Manager décidant, sans pour autant perdre son intelligence. En mode subordinatif : un des Autonomic Manager se subordonne totalement à l’autre, c’est-à-dire que comme dans le cas précédent, il devient géré par l’Autonomic Manager pair à la différence cependant que l’Autonomic Manager subordonné abandonne toute intelligence concernant la gestion distribuée au profit de l’Autonomic Manager distant, ne devenant qu’un agent de monitoring et d’exécution de ce dernier. Ce mode peut être utile dans le cas où un des deux hôtes possède une très faible capacité de calcul (un capteur par exemple), ne pouvant ainsi pas prendre en charge plus que des décisions purement locales. 652. Architecture de l’ATL Plan de modification Une fois la décision prise sur les actions à entreprendre, le plan de modification contient la suite des actions à engager. Il décrit, point par point, quelles sont les modifications à faire, dans quel ordre, et si des conditions de transitions sont à respecter. La variété d’actions de reconfiguration possibles à entreprendre est a priori colossale, d’autant que celles-ci peuvent être spécifiques à certains composants protocolaires. Par exemple, la décision de désactiver l’algorithme de Nagel peut-être prise au sein de TCP ou de SCTP, mais n’a aucun sens dans le cas d’UDP. Si cet exemple représente une décision locale sans impact sur le pair distant de la communication, certaines reconfigurations nécessiteront par contre de synchroniser les deux Flow. Le déploiement ou le remplacement d’un ou plusieurs composants protocolaires par exemple, comme la transition de TCP vers DCCP, donne lieu à une évidente synchronisation. Le plan doit donc être organisé en étapes que chaque Autonomic Manager suivra à un rythme dépendant de leur organisation relative (cf. 2.2.3.2). Le plan mis à disposition de chacun peut différer. En effet, les actions à entreprendre ne sont pas forcément les mêmes sur chacun des deux Flow. Ainsi, chaque Autonomic Manager n’a besoin que de la connaissance de son propre plan. Ceux-ci acquièrent le dit plan par différents moyens selon la manière dont les décisions sont prises (cf. 2.2.3.2). En effet, si le mode retenu est la collaboration, chaque Autonomic Manager mettra en place son propre plan, via une négociation conjointe avec son pair. Dans le mode participatif ou subordinatif, l’Autonomic Manager maître est en charge de mettre le plan de chacun en place, puis le transmettre à son subordonné une fois ceci fait. 2.2.3.3 Le Data Plan Afin d’accueillir les instances des différents composants protocolaires, le composant géré par l’Autonomic Manager, le Data Plan, est composé de plusieurs élé- ments permettant l’assemblage et la manipulation de ceux-ci. Ces éléments sont représentés sur la figure 2.7. Le Channel Le composant principal du Data Plan est le Channel. C’est au sein de celui-ci que sera instancié le service composite qui aura la charge de gérer la communication. Un Channel n’est pas nécessairement unique. En effet, plusieurs Channel peuvent être instanciés au même moment, contenant des services composites différents, notamment dans certains scénarios de reconfiguration. Ainsi, chaque Channel possède un identifiant, permettant de savoir quel message doit être traité par quel Channel. Les composants prenant place dans le Channel sont les composants protocolaires. Tout service composite se compose d’un composant protocolaire de type protocole et d’autant de composants protocolaires de type micro-protocole que nécessaire. 662.2. Architecture de l’ATL Figure 2.7: La composition du Data Plan Ceci implique que les protocoles existants dans les systèmes actuels soient convertis en composants protocolaires pour être intégrés à l’ATL. Le cœur du protocole n’a pas à être modifié. Seule sa manière de communiquer avec le reste de la pile réseau du système doit être adaptée. Ainsi, au lieu d’être directement relié à l’application et au protocole de la couche réseau, le protocole de Transport devra récupérer les messages depuis les micro-protocoles situés au-dessus et audessous de lui dans le Channel dans lequel il prend place. Ceci peut être fait soit en reliant directement les interfaces de chaque composant protocolaire directement, soit en utilisant le Channel comme ordonnanceur. Celui-ci aurait alors la charge de faire transiter le message de composant en composant, récupérant ce dernier après chaque traitement pour le passer au suivant. 672. Architecture de l’ATL Multiplexeur-démultiplexeur Afin de permettre l’aiguillage entre les diffé- rents Channel, quand plusieurs sont présents, un multiplexeur-démultiplexeur prend position entre les Channel et l’interface vers l’application, et entre les Channel et l’interface vers le réseau. Ceux-ci effectuent leurs tâches grâce aux identifiants des différents Channel, qui ont été préalablement estampillés dans les messages. Buffers Lorsqu’un message arrive de l’application ou du réseau, il est placé dans un buffer en attendant d’être pris en charge par le multiplexeur-démultiplexeur qui l’aguillera vers le Channel adéquat. Ces buffers jouent le rôle de tampon entre l’application et les Channel ainsi qu’entre les Channel et le réseau, afin d’absorber les différences de rythme entre chaque couche. Ce sont également eux qui sont en charge d’estampiller chaque message entrant avec l’identifiant de Channel qui doit les traiter, puis de retirer l’estampille à la sortie du Data Plan, afin que celle-ci n’interfère pas avec les applications (principalement les applications legacy), avec le réseau (car on créerait alors une sorte de nouveau protocole, qui ne serait pas reconnu partout), et avec le système distant (principalement les systèmes legacy). Channel Manager Ce composant est le relais de l’Autonomic Manager au sein du Data Plan. C’est lui qui remonte les différentes informations de monitoring à l’Autonomic Manager, mais également qui gère les créations et les modifications de Channel selon les ordres de l’Autonomic Manager. Il possède également la capacité de mettre les multiplexeurs-démultiplexeurs en pause afin de geler la communication, et de notifier ceux-ci ainsi que les buffers des identifiants des nouveaux Channel, afin d’estampiller et d’aiguiller correctement les nouveaux messages, en fonction des Channel présents. 2.2.3.4 Intégrateur des services et base de connaissances La fonctionnalité de gestion des services (cf. 2.1.4.1) est notamment prise en charge par la base des composants et services et par l’intégrateur de services. Ceuxci permettent d’effectuer la correspondance entre services et composants protocolaires, ce qui peut impliquer le cas échéant une négociation avec l’hôte distant — si celui-ci dispose également de l’ATL. Correspondances entre services et composants La correspondance entre les composants protocolaires disponibles et les services qu’ils offrent est nécessaire pour la traduction des requêtes applicatives constituées de services, en solution protocolaire potentiellement composite permettant de satisfaire ces requêtes. Pour ce faire l’ATL dispose d’une base répertoriant ces services et comportant pour chaque composant protocolaire donné, la description du service qu’il offre. 682.2. Architecture de l’ATL L’Autonomic Manager de chaque Flow peut y effectuer une requête permettant de récupérer le ou les composants susceptibles de satisfaire tout ou partie des services requis — le cas d’un service partiellement couvert par un composant pouvant être pallié par sa composition avec un ou plusieurs autres fournissant les services manquants. L’intégration de nouveaux composants doit permettre leur utilisation immé- diate par les différentes applications, et donc par les différents Flow de l’ATL. Ainsi, le rôle de l’intégrateur est de maintenir la base des composants et services afin que chaque nouveau composant installé sur le système voit la description du service qu’il offre être mis à disposition des Autonomic Manager pour leurs prises de décision futures. 2.2.4 Composants secondaires 2.2.4.1 Flow Creator La création d’un Flow est effectuée par le Flow Creator. C’est lui qui reçoit les demandes de création, correspondant à l’ouverture des différents points d’accès au service de Transport, que ceux-ci soient ouverts par des applications legacy, aware ou smart. Il lui incombe donc d’intercepter les appels de méthodes classiques afin de rediriger leur prise en charge vers l’ATL, ce qui implique une modification de l’implémentation de l’API socket classique, de manière à ce que les applications legacy ne soient pas modifiées, mais appellent tout de même l’ATL (à leur insu) lors de l’ouverture de sockets. Cette API devra également être étendue afin de prendre en compte les spécificités des applications aware et smart. C’est lui également qui récupère les différentes informations passées par l’application à la création du point d’accès, comme le protocole de Transport désiré par les applications legacy ou les spécifications de besoins en qualité de service pour les applications aware ou smart, ainsi que d’éventuelles contraintes supplémentaires pour les applications smart. On voit directement sur la figure 2.3 que le Flow Creator est une nouvelle manière d’implémenter la partie Transport de l’API socket classique pour le cas des applications legacy et dans le contexte de l’ATL. Dans le cas des applications aware et smart, le Flow Creator est l’implémentation des nouvelles fonctionnalités des extensions d’API, ou de la nouvelle API, nécessaire au fonctionnement de ces nouveaux types d’applications. 2.2.4.2 Signalization Message Controler Le composant suivant présent sur la figure 2.3 est le Signalization Message Controler (SigMsgCtrlr). Ce composant est chargé de l’échange des messages de 692. Architecture de l’ATL gestion entre deux instances de l’ATL, concernant des informations sur l’état global de l’ATL sur l’hôte distant et non pas sur l’état d’un Flow en particulier. Si les deux systèmes impliqués dans une communication disposent de l’ATL, un Autonomic Manager désirant avoir une information sur l’ATL du système distant, comme par exemple la liste des services instanciables sur ce système, adressera cette requête à son Signalization Message Controler qui la reliera à celui du système distant. Si au contraire l’Autonomic Manager souhaite avoir une information concernant précisément le Flow distant auquel il est relié, telle que des informations de monitoring de la communication, il devra directement s’adresser à l’Autonomic Manager de ce Flow. C’est notamment le Signalization Message Controler qui aura la charge de découvrir si l’ATL est présente sur une machine distante à laquelle on souhaite se connecter. Afin d’économiser certaines ressources système et réseau ainsi que temporelles, ce composant peut embarquer des fonctions de cache, gardant en mémoire certaines des informations qu’il a déjà découvertes, afin de les distribuer à un Autonomic Manager les requérant sans avoir besoin qu’un message de requête ne parcourt le réseau. 2.2.4.3 Multiplexage-démultiplexage entre couche réseau et Flow Le dernier composant est un multiplexeur-démultiplexeur se situant entre les Flow et la couche réseau. Son rôle est de récupérer les différents messages provenant du réseau afin de les aiguiller vers le Flow adéquat. Pour une telle opération, les Flow doivent avoir un adressage leur permettant d’être différenciés au sein de la machine. Dans un premier temps nous voyons comment fonctionne ce type d’adressage dans les systèmes actuels avant de proposer une manière d’adresser les Flow de l’ATL. Adressage dans les systèmes actuels Sur un système legacy, un socket est identifié, en mode connecté, selon le flux auquel il appartient. Or un flux est défini par le quintuplet : (@IPsrc, @IPdest, protocole de Transport, portsrc, portdest). En mode non connecté, un socket est défini par le triplet (@IPdest, protocole de Transport, portdest). Le passage au protocole de Transport est assuré par la couche réseau. Le passage au socket est assuré alors par le protocole de Transport selon le numéro de port. Une fois le paquet arrivé sur le système hôte, l’identification locale réside donc dans le couple (protocole de Transport, portdest). Dans le cas de l’ATL cependant, tout message échangé entre deux Flow ne comporte pas toujours ces informations, comme les messages de gestion échangés entre Autonomic Manager par exemple. De plus, le service composite étant variable, le protocole utilisé dans celui-ci peut également varier, rendant obsolète le couple (protocole de Transport, portdest) pour l’identification d’un Flow dans l’ATL. 702.2. Architecture de l’ATL Adressage d’un Flow Un Flow est associé à un et un seul point d’accès au service de Transport, et réciproquement. Adresser un Flow revient donc à adresser le point d’accès associé. Un Flow comportant toujours un composant protocolaire de type protocole, et celui-ci utilisant alors un numéro de port, le couple (protocole de Transport, portdest) peut être utilisé par l’ATL pour aiguiller les paquets arrivant de la couche réseau vers le Flow correspondant. Cependant, lorsque l’Autonomic Manager n’a pas encore statué sur le protocole de Transport à utiliser, ni l’une ni l’autre des deux valeurs du couple précédemment cité n’est encore disponible. Pourtant, certains messages à destination du Flow peuvent déjà être émis et reçus, comme ceux permettant la négociation du service composite qui sera à instancier, négociation qui permettra à l’Autonomic Manager de décider du protocole de Transport à utiliser par la suite. Ceux-ci doivent disposer d’une information permettant leur identification et leur démultiplexage. Si l’application ouvrant le point d’accès est une application legacy, elle fournit comme à l’heure actuelle le protocole de Transport et le numéro de port avec lesquels elle souhaite travailler. Sinon, l’application doit fournir un identifiant traduisant le service qu’elle offre à travers ce point d’accès, suivant ainsi la construction orientée service de l’ATL. Un navigateur web pourra ainsi fournir comme identifiant CLTWEB, signifiant que le point d’accès venant d’être ouvert est destiné à être client d’une communication web (utilisant http). Le système y adjoint un numéro afin de différencier différents points d’accès ouverts et offrant le même service. Ainsi, un navigateur web souhaitant charger deux pages web simulatnément ouvrira deux points d’accès (un par page), identifiés CLTWEB par l’application, et complétés par le système en CLTWEB1 et CLTWEB2. Cet identifiant est associé automatiquement grâce à une table de traduction à un couple (protocole de Transport, portdest). Par exemple, un serveur web ouvrant un point d’accès le nommera avec l’identifiant SRVWEB, qui sera automatiquement associé au couple (tcp, 80). Si l’ATL est présente sur le système distant, alors les messages de négociation de la composition en provenance de celui-ci désignerons le Flow auquel ils sont destinés via les identifiants textuels. Sinon, on déduira que le Flow vers lequel diriger les messages entrant est celui dont le couple (protocole de Transport, no port) correspond à ce que contient le message ou on utilisera ce couple comme protocole de Transport à utiliser. Ceci sous-entend le besoin de standardiser certains identifiants textuels ainsi que leur correspondance au couple (protocole de Transport, portdest), comme sont à l’heure actuelle standardisés certains de ces couples pour des utilisations particulières. Le couple (tcp, 80) est par exemple standardisé pour les communications utilisant http. L’identifiant correspondant à ce couple ainsi que cette correspondance devront également être standardisés pour permettre la transition vers l’ATL 712. Architecture de l’ATL de manière transparente. 2.3 Conclusion Ce chapitre a présenté les différents composants qui forment la structure de l’ATL. Tout d’abord, nous avons détaillé les objectifs que doit remplir l’ATL et les paradigmes de conceptions employés pour les atteindre : la conception orientée service et basée composant. Les intérêts et impacts de ces deux approches ont été notamment abordés. Dans une seconde partie, nous avons décrit les trois types de fonctionnalités qui doivent être présentes au sein de l’ATL pour assurer le bon déroulement des communications. Ces fonctionnalités peuvent être du type données, contrôle ou gestion. Puis nous avons détaillé les différents composants permettant de mettre ceci en place, d’abord à un premier niveau de décomposition, puis plus en dé- tails dans le cas des composants dits primaires, ceux qui accueillent les flux de données, mais également les composants secondaires, permettant aux premiers de fonctionner correctement. Le chapitre suivant s’attarde sur les différents comportements dont font preuve ces composants dans deux cas particuliers : celui de l’ouverture d’un point d’accès au service de Transport par l’application, quel que soit son type — legacy, aware ou smart — et celui de la reconfiguration du service composite proposé par un Flow. 72CHAPITRE 3 Description comportementale de l’ATL : cas de la création et de la reconfiguration d’un service composite Le précédent chapitre a introduit et décrit la structure composite de l’ATL, en détaillant le rôle de chacun des composants dans le but de satisfaire les objectifs fixés à la fin du chapitre 1. Dans le présent chapitre, nous décrivons le comportement des différents élé- ments précédemment introduits dans deux cas particuliers : – la création d’un point d’accès au service de Transport ; – la reconfiguration d’un Flow. Ces deux situations revêtent une importance particulière. Le premier cas mérite d’être étudié car l’ouverture d’un point d’accès avec l’ATL diffère des solutions classiques. En effet ici, la liaison avec le protocole de Transport n’est pas directe. Pourtant, les applications legacy ne doivent pas sentir de différence afin de ne pas avoir à subir de mise à jour. De plus les applications aware et smart communiquent différemment avec la couche Transport que les applications legacy. Le second cas présente un intérêt car s’il n’est pas totalement nouveau, les problématiques de reconfiguration comportementale et structurelle, abordées en 3.2, sont ici déclinées dans le contexte de flux de données de Transport et présentent des particularités. Il s’agit de plus d’une fonctionnalité centrale de l’ATL sans laquelle ses objectifs ne seraient pas atteints. 733. Description comportementale de l’ATL La première partie du chapitre décrit le cas de l’ouverture d’un point d’accès au service de Transport, et la deuxième le cas de la reconfiguration. La troisième partie aborde les problèmes de traduction d’état dans le cadre des reconfigurations, à travers la problématique du traitement des messages nécessitant des retransmissions. Sommaire 3.1 Création d’un point d’accès au service de Transport . . . . . . 74 3.1.1 Instanciation d’un Flow . . . . . . . . . . . . . . . . . 74 3.1.2 Application cliente . . . . . . . . . . . . . . . . . . . . 76 3.1.3 Application serveur . . . . . . . . . . . . . . . . . . . . 80 3.1.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.2 Reconfiguration d’un Flow . . . . . . . . . . . . . . . . . . . . 83 3.2.1 Déroulement d’une reconfiguration . . . . . . . . . . . 83 3.3 Traitement des retransmissions lors des transitions . . . . . . . 88 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.1 Création d’un point d’accès au service de Transport Cette section décrit le comportement de l’ATL dans les différents cas de figure possibles, selon le type de l’application — legacy, aware ou smart —, du système distant avec lequel on souhaite communiquer — legacy ou enabled — et selon que l’on se place du côté client (au sens initiateur) ou serveur de la communication. Une synhèse des différents cas de figure est ensuite proposée afin de simplifier le nombre de cas à prendre en compte. 3.1.1 Instanciation d’un Flow Parmi toutes les situations citées ci-dessus, certaines actions sont nécessaires dans tous les cas. Cette suite d’actions concerne l’instanciation effective du Flow afin qu’il puisse par la suite accueillir le service composite. En effet, que le système distant soit ATL-enabled ou legacy, que l’application demandant la création du TSAP soit legacy, ATL-aware ou smart, que l’on soit serveur ou client, les actions décrites ici seront toujours menées, et correspondent à la préparation du Flow. Nous appelons cette suite d’actions : comportement commun. Lorsque l’application effectue une demande de création d’un point d’accès au service de Transport (TSAP) comme dans le diagramme de la figure 3.1, elle utilise une méthode telle la méthode socket de l’API éponyme en C, ou le constructeur de 743.1. Création d’un point d’accès au service de Transport Figure 3.1: Une application de type aware ou smart ouvre un point d’accès au service de Transport via l’interface de contrôle de l’ATL la classe Socket en Java. Dans un système comportant l’ATL, ces appels à méthode de création, qu’elles proviennent des API classiques ou d’une API dédiée à l’ATL, doivent être récupérés par le Flow Creator. Celui-ci crée alors un nouveau Flow au sein de l’ATL, et le lie au TSAP. Dans le Flow sont instanciés un Autonomic Manager et un Data Plan, dédiés à ce Flow, comme décrit sur le diagramme de la figure 3.3. Une fois le Flow instancié, ainsi que son Data Plan et son Autonomic Manager, le Flow Creator communique à ce dernier les caractéristiques du service demandé par l’application. Celles-ci vont différer selon le type d’application : – Une application legacy communiquera le protocole de Transport qu’elle souhaite utiliser ainsi que le numéro de port utilisé sur le système serveur de la communication. – Une application aware communiquera les caractéristiques qu’elle souhaite voir respectées par le service ainsi que le nom du point d’accès dont elle 753. Description comportementale de l’ATL Figure 3.2: Diagramme de séquence de création d’un Flow demande la création (cf. 2.2.4.3). – Une application smart communiquera les mêmes informations qu’une application aware, ainsi qu’un certain nombre de contraintes supplémentaires, en imposant par exemple l’utilisation d’un certain protocole comme base de la composition protocolaire (cf. 2.2.1). Le Flow est alors prêt à accueillir un nouveau Channel comportant le service composite qui assurera la communication. 3.1.2 Application cliente Cette section décrit le comportement de l’ATL lorsque l’application est cliente de la connexion, c’est-à-dire qu’elle fournit à l’ATL l’adresse IP du système distant via une demande de connexion explicite — comme par exemple, pour une 763.1. Création d’un point d’accès au service de Transport Figure 3.3: Instanciation d’un nouveau Flow application legacy ouvrant un socket TCP — ou émet un message à destination du système distant — comme par exemple une application legacy utilisant UDP. 3.1.2.1 Application legacy Une application legacy doit pouvoir ouvrir un TSAP tel qu’elle l’a toujours fait, c’est-à-dire via une méthode faisant appel à l’API socket classique. Elle indique via cette méthode, le protocole de Transport ainsi que le numéro de port à utiliser. Cette méthode lui retourne ensuite ledit socket. Du point de vue de l’application, ce comportement ne doit pas être modifié. Après avoir effectué le comportement commun, l’Autonomic Manager doit, afin de décider du service composite à déployer, récupérer certaines informations. – Il connaît déjà le protocole qui lui a été demandé par l’application et peut en déduire une contrainte de décision (qui est de fait : « utiliser ce protocole ») et un type de Qualité de Service demandée (par exemple : « ordre et fiabilité totale » si TCP est demandé) ; – Ce service peut être suffisant. Cependant, il peut-être plus adéquat de le coupler à d’autres en fonction de l’évolution des conditions réseaux. – De plus, si le système hébergeant le serveur dispose de l’ATL, il peut avoir des desiderata ou des exigences quant aux composants protocolaires à utiliser pour implanter les services requis. En conséquence de quoi l’Autonomic 773. Description comportementale de l’ATL Manager doit savoir si le serveur auquel il compte se connecter dispose ou non de l’ATL également. L’application étant cliente, l’ATL dispose de l’adresse du serveur. Ainsi, l’Autonomic Manager va effectuer une demande de découverte de la présence de l’ATL sur le serveur grâce au Signalization Message Controler. Ce dernier va alors effectuer une requête auprès de son homologue sur l’ATL distante. La réponse, positive ou négative, sera alors transmise à l’Autonomic Manager requérant. Bien que d’autres solutions soient envisageables, une solution simple de mise en œuvre de la requête du Signalization Message Controler consiste à envoyer un paquet TCP de type SYN sur un port prévu à cet effet. La réception d’un SYNACK constituera alors une réponse positive, celle d’un RST une réponse négative. L’inconvénient majeur d’une telle solution consiste bien sûr en la réservation d’un numéro de port à cette utilisation. Son avantage principal, cependant, réside dans l’utilisation d’un paquet TCP, paquet qui ne sera filtré que par une minorité de middleboxes, permettant ainsi d’être compatible avec la quasi totalité du réseau existant. Quelle que soit la méthode d’implémentation retenue, la découverte doit être rapide. Un modèle simple de type requête/réponse serait alors à privilégier, limitant ainsi le temps de découverte à un RTT maximum, comme illustré sur la figure 3.4. Figure 3.4: Mécanisme de découverte de l’ATL 783.1. Création d’un point d’accès au service de Transport En cas de réponse négative (i.e. l’hôte distant ne dispose pas de l’ATL) l’Autonomic Manager doit décider seul d’un service composite utilisant le protocole requis par l’application. En effet, l’ATL n’étant pas présente sur le système distant, on peut conclure que le protocole que celui-ci utilisera est nécessairement celui demandé par l’application. Il est donc impératif de l’utiliser. Cependant, s’il le juge utile, l’Autonomic Manager peut décider d’ajouter certains mécanismes protocolaires locaux au service composite. En cas de réponse positive, l’Autonomic Manager va entrer en relation avec son pair distant sur le serveur, afin d’entamer une négociation avec celui-ci concernant la composition du service composite à mettre en place. Cette négociation concerne les composants protocolaires distribués, ceux-ci étant répartis sur les deux systèmes. Des mécanismes protocolaires locaux peuvent y être adjoints de chaque côté de la communication, si tant est que ceux-ci ne créent pas de conflit avec les composants distribués. Une fois le service composite décidé, l’Autonomic Manager va l’instancier en demandant la création d’un nouveau Channel au Channel Manager du Data Plan (cf. 3.1.1). 3.1.2.2 Application ATL-aware Une application ATL-aware ouvre un TSAP en passant la description de ses besoins en Qualité de Service (Quality of Service) (QoS) en paramètre, ainsi que le nom qu’il attribue au TSAP (cf. 2.2.4.3). Après instanciation d’un nouveau Flow, l’Autonomic Manager ne connaît que les besoins en terme de services requis par l’application ciente. Il ignore cependant sur quel protocole se baser pour répondre aux services requis. Cette question peut facilement être résolue en négociant la composition avec l’hôte distant. Ainsi : – l’Autonomic Manager va effectuer une demande de découverte au Signalization Message Controler, comme précédemment ; – tout comme dans le cas d’une application legacy, une réponse positive va donner lieu à une négociation basée sur les critères de services requis par l’application, et les éventuelles contraintes imposées par celles-ci ; – dans le cas d’une réponse négative, l’Autonomic Manager va décider d’un service composite basé sur le protocole de Transport obtenu via traduction du nom attribué au TSAP (cf. 2.2.4.3), et comportant éventuellement un ou plusieurs blocs de service locaux s’il le juge nécessaire. Dans l’exemple où un client web ATL-aware ouvre un TSAP, si le Signalization Message Controler retourne une réponse positive, les deux Autonomic Manager (i.e. : du Flow client et du Flow serveur) entamerons une négociation pouvant 793. Description comportementale de l’ATL aboutir à l’utilisation de différents protocoles comme TCP ou SCTP, cette décision pouvant différer d’une négociation à l’autre. Si le Signalization Message Controler retourne une réponse négative, l’Autonomic Manager traduit le nom du Flow, CLTWEB (cf. 2.2.4.3), en (tcp, 80), indiquant qu’il doit utiliser le protocole TCP sur le port 80. 3.1.2.3 Application smart Dans le cas d’une application smart, le comportement sera le même que précé- demment, pour une application ATL-aware, à ceci près que l’application a la possibilité d’indiquer des contraintes supplémentaires à l’Autonomic Manager dans ses prises de décisions. Toute situation ne pouvant aboutir à cause de ces contraintes devra alors être reportée à l’application. En effet, en imposant des contraintes supplémentaires, l’application reprend en charge certaines responsabilités qui seraient assumées par l’Autonomic Manager dans le cas d’une application ATL-aware. Par exemple, une application imposant le cryptage des communications en utilisant TLS [Die08] recevra une erreur si aucun composant ne prenant en charge ce protocole n’est disponible sur le système. 3.1.3 Application serveur Le comportement décrit ici recouvre les cas où l’application est le serveur de la communication, c’est-à-dire qu’elle ouvre un point d’accès disponible pour les connexions entrantes — comme pour un serveur utilisant TCP — ou des messages émis depuis d’autres systèmes distants — comme dans le cas d’une application UDP uniquement réceptrice. 3.1.3.1 Application legacy Après avoir instancié un nouveau Flow, et comme côté client, on doit tout d’abord savoir si le système distant dispose de l’ATL. Cependant, cette fois, on ne dispose pas de l’adresse du client. Ainsi, les deux cas de figures suivants se présentent. 1. Le client (distant) dispose de l’ATL. Celui-ci a émis une requête de découverte afin de savoir si le serveur dispose de l’ATL. Celle-ci est récupérée par le Signalization Message Controler qui y répond positivement. Par la suite, le client contacte l’Autonomic Manager du Flow adéquat sur le serveur pour négocier le service composite. Le Flow dans lequel se situe cet Autonomic Manager est désigné par le nom de service qu’aura spécifié l’application cliente à l’ouverture de son TSAP (cf. 3.1.2.1). 803.1. Création d’un point d’accès au service de Transport 2. Le client ne dispose pas de l’ATL. Le premier message en provenance de celui-ci est alors récupéré et analysé par le multiplexeur-démultiplexeur situé entre les Flow et la couche réseau afin de déterminer le protocole de Transport utilisé par le client. Celui-ci doit normalement être le même que celui que nous a imposé l’application serveur lorsqu’elle a ouvert le TSAP. Ce TSAP correspond alors à un Flow notamment identifié par ce protocole de Transport et par un certain numéro de port. Le message sera alors dirigé vers le Flow identifié par le protocole de Transport et le numéro de port utilisés dans son en-tête. Dans le premier cas, la négociation a été engagée par le client afin de décider la partie distribuée du service composite à instancier, sur laquelle bâtir également la partie locale le cas échéant. Dans le second, on peut directement décider d’une composition locale basée sur le protocole demandé. 3.1.3.2 Application ATL-aware Le comportement est ici similaire au cas précédent, à la différence que, comme côté client pour une application ATL-aware (cf. 3.1.2.2), on ne dispose que des besoins en terme de services de l’application. Si on reprend les deux cas précédents, qui s’appliquent également ici, on remarque que rien ne change dans le premier de ces cas, mais que dans le second, le Flow de l’application serveur ne dispose pas d’un couple (protocole de Transport, n o de port) pour l’identifier — l’application utilisant un nom de service comme décrit dans 2.2.4.3. Dans le premier cas, le Flow vers lequel diriger le message de négociation de l’Autonomic Manager du client a été déterminé par ce nom de service. Dans le second, on ne dispose que du couple (protocole de Transport, no de port destination). La correspondance avec le nom de service du Flow auquel diriger ce message se trouve alors dans la table de traduction introduite en 2.2.4.3. 3.1.3.3 Application smart Comme côté client, deux cas se présentent ici : 1. si l’application a imposé le protocole à utiliser, le comportement sera le même que pour une application legacy ; 2. sinon, le comportement sera le même que pour une application ATL-aware. L’observation de cette dichotomie simple dans le cas d’une application serveur donne lieu à la classification alternative décrite à la section 3.1.4. 813. Description comportementale de l’ATL 3.1.4 Synthèse On remarque dans les deux sections précédentes que le comportement de l’ATL à la création d’un point d’accès au service de Transport est conditionné à deux paramètres indépendants, et donne donc lieu à quatre cas. Ces deux paramètres sont : 1. la connaissance que le système a de l’adresse IP du système distant avec lequel communiquer : – une application cliente connaît l’adresse IP du système distant, – une application serveur ne la connaît pas ; 2. le fait que l’application impose ou non le protocole de Transport à utiliser : – une application legacy l’impose, – une application aware ne l’impose pas, – une application smart peut ou non l’imposer. Quel que soit le cas, la première action à effectuer est bien évidemment d’instancier un Flow grâce au Flow Creator. Par la suite, les actions à mener vont donc être les suivantes. On dispose de l’adresse IP du système distant. Dans ce cas, la première action à effectuer est de lancer la procédure de découverte de l’ATL sur le système distant via le Signalization Message Controler. Si la réponse est positive, on peut immédiatement entamer une procédure de négociation du service à mettre en place. Sinon l’Autonomic Manager doit décider d’une composition utilisant des mécanismes protocolaires locaux, basée sur le protocole de Transport déterminé : – par l’application si celle-ci nous l’a imposé (comme le ferait une application legacy) ; – grâce à la table de traduction si l’application a seulement nommé le point d’accès au service de Transport (comme le ferait une application aware). On ne dispose pas de l’adresse IP du système distant. Dans ce cas on doit adopter un comportement « serveur » et attendre un message entrant afin de connaître l’identité du pair de la communication. Soit le premier message reçu est un message de négociation de service, et le système distant dispose donc de l’ATL. On dirige ce message vers le Flow identifié par le nom correspondant au nom de service véhiculé dans le message. On peut alors poursuivre avec lui la négociation. Soit le message reçu est un message de données et on déduit alors que le système distant ne dispose pas de l’ATL. On dirige alors le message vers le Flow correspondant au couple (protocole de Transport, no de port) du message entrant car le Flow est ainsi identifié par l’application ou via la table de traduction. On peut alors décider d’une composition locale. 823.2. Reconfiguration d’un Flow Dans tous les cas, une fois ces étapes effectuées, on peut instancier la composition et démarrer la communication. 3.2 Reconfiguration d’un Flow Une fois le service composite instancié et la communication établie, les conditions dans lesquelles ce service travaille peuvent varier. Ainsi non seulement les objectifs de qualité de service de l’application peuvent être modifiés par celle-ci, mais l’environnement réseau est par nature dynamique et peut donner lieu à des modifications importantes de ses caractéristiques, ne permettant plus à un service donné d’atteindre les objectifs pour lesquels il a été choisi. Dans une telle situation, la solution réclame la reconfiguration, plus ou moins en profondeur, du dit service. On observe principalement deux types de reconfiguration. 1. La première, dite reconfiguration « comportementale », consiste à ne pas modifier le service composite dans sa structure, c’est-à-dire, dans le cas de l’ATL, conserver les mêmes composants protocolaires, mais interviendra sur les paramètres de ces derniers afin d’altérer leur fonctionnement. Ainsi, modifier la valeur maximum que peut prendre le Retransmission Time Out (RTO) dans TCP constitue un exemple de reconfiguration comportementale. 2. La seconde est une reconfiguration dite « structurelle ». Celle-ci implique que la structure du service composite va être modifiée par l’ajout, la suppression ou le remplacement d’un ou plusieurs composants protocolaires. On peut par exemple ainsi décider de ne plus utiliser SCTP au cours d’une communication pour le remplacer par MPTCP, car l’apparition de middleboxes bloquerait alors SCTP. Cette section aborde la problématique de la reconfiguration en décrivant le comportement de l’ATL pour mener à bien les différents cas. 3.2.1 Déroulement d’une reconfiguration 3.2.1.1 Classification des cas de reconfiguration possibles Il existe deux cas de reconfiguration : – comportementale, où l’on modifie un ou plusieurs paramètres uniquement ; – structurelle, où l’on va modifier la composition en changeant un ou plusieurs composants protocolaires, ceci selon deux possibilités : – l’ajout ou le retrait des composants protocolaires concernés, – le déploiement de la nouvelle composition dans un nouveau Channel si la précédente méthode est impossible. 833. Description comportementale de l’ATL Le choix de l’une ou l’autre de ces deux possibilités peut par exemple être influencé par la manière dont on souhaite traiter les messages à retransmettre (cf. 3.3). Dans le troisième cas ci-dessus deux méthodes peuvent être utilisées pour dé- ployer la nouvelle composition : séquentielle ou parallèle. – Avec la première méthode, on déploie le nouveau Channel séquentiellement dans le temps. C’est-à-dire que l’Autonomic Manager va d’abord devoir attendre que le Channel courant ait terminé son exécution avant de la détruire puis de déployer le nouveau Channel. – La seconde méthode consiste à déployer et démarrer la nouvelle composition alors que la précédente finit son travail. Ainsi, les nouveaux envois de données passent par la nouvelle composition pendant que les retransmissions passent par l’ancienne. Ces deux méthodes sont opposées sur deux points : l’overhead temporel et l’utilisation mémoire. – Sur les systèmes très contraints en ressources, la méthode parallèle peut s’avérer coûteuse. – Cependant, la première présente l’inconvénient de devoir attendre la fin du premier Channel avant de démarrer le suivant. Si le premier instancie un service composite dont le temps d’arrêt est non déterministe, le coût en temps peut rapidement devenir trop important. 3.2.1.2 Suivi du plan de reconfiguration Toute reconfiguration se déroule en une succession d’étapes définies par le plan d’exécution qui a été décidé par la fonction de planification des Autonomic Manager selon leur organisation. Certaines étapes du plan nécessitent une synchronisation des deux Flow pour être effectuées. Afin de permettre l’adaptation à une grande variété d’actions possibles et à venir, notamment due à l’importante multiplicité des composants protocolaires et des versions de ceux-ci que permet l’ATL, le protocole de synchronisation des actions doit être le plus simple possible, laissant au plan lui-même le soin d’encapsuler la complexité. Ce type de décomposition de la complexité est déjà utilisé depuis longtemps pour la gestion de réseaux avec le protocole SNMP, possédant un nombre réduit de commandes génériques, et permettant d’aller interroger des bases de données spécifiques et potentiellement complexes, les Management Information Base (MIB) [Pre02]. Selon un principe similaire, nous proposons ici les messages suivant pour le protocole : 843.2. Reconfiguration d’un Flow – setPlan, permettant à l’Autonomic Manager décisionnaire d’imposer le plan à l’autre ; – nextStep, permettant à l’Autonomic Manager décisionnaire d’ordonner le passage à la réalisation de l’étape suivante à l’autre Autonomic Manager, celui-ci étant bloqué en attendant cet ordre ; – stepAck, permettant à un Autonomic Manager d’informer la réalisation d’une étape à l’autre Autonomic Manager. Le but de ces messages est uniquement de permettre la synchronisation d’étapes interdépendantes. Dans le cas d’Autonomic Manager collaboratifs (cf. 2.2.3.2), le plan n’est pas imposé par un Autonomic Manager sur l’autre, il est décidé par consensus. De la même manière, aucun n’autorise l’autre à passer à l’étape suivante, chacun informe l’autre de son état d’avancement dans la réalisation, et s’auto-débloque lorsqu’il le juge approprié. Ainsi le protocole reste générique en n’encodant absolument aucune des commandes spécifiques aux différents composants protocolaires utilisables par une ATL ou l’autre. Ces commandes sont indiquées dans le plan de reconfiguration, à chaque étape. La commande nextStep du protocole de reconfiguration permet donc de passer à la commande suivante à exécuter, quelle que soit celle-ci. Le protocole de reconfiguration devient ainsi scalable vis-à-vis du nombre de composants protocolaires possibles. La figure 3.5 montre le déroulement d’une reconfiguration dans le cas où un des deux Autonomic Manager orchestre l’opération. 3.2.1.3 Déroulement selon les cas Nous allons ici décrire le déroulement de chacun des quatre cas de reconfiguration : 1. comportemental ; 2. par ajout ou retrait d’un composant protocolaire dans un Channel existant ; 3. par déploiement d’un nouveau Channel en série ; 4. par déploiement d’un nouveau Channel en parallèle. Reconfiguration comportementale Le processus de décision distribué entre les Autonomic Manager a statué pour une reconfiguration comportementale, c’est- à-dire pour la reconfiguration d’un ou plusieurs paramètres au sein d’un ou plusieurs composants protocolaires du Channel en cours d’exécution. C’est à ce processus de décision de décider si les actions à entreprendre sur ces différents paramètres doivent respecter un certain ordre d’exécution s’il y en a plusieurs, pour des raisons de dépendance par exemple. 853. Description comportementale de l’ATL Figure 3.5: Suivi du plan de reconfiguration Chaque paramètre sera modifié via l’invocation d’une méthode appropriée du Channel Manager. Celui-ci, sur cet ordre, invoque la procédure de modification correspondante publiée par le composant à modifier. Nous pouvons ici remarquer qu’une modification de paramètre du point de vue des Autonomic Manager peut aboutir à une reconfiguration structurelle interne du composant protocolaire ciblé. En effet, si le composant est lui même un ensemble composite, sa composition représente un de ses paramètres. Modifier celle-ci revient à modifier ce paramètre, sans modifier la structure protocolaire du Channel, du point de vue de l’ATL, même s’il s’agit, du point de vue du composant concerné, d’une restructuration interne. L’utilisation d’ETP comme protocole au sein du Channel est un exemple de cette situation. En effet, modifier la composition du service interne d’ETP s’effectue en changeant le fichier de description de composition de ce service, donc via un changement de paramètre, du point de vue de l’Autonomic Manager. Cette modification va cependant initier une procédure de reconfiguration au sein d’ETP, 863.2. Reconfiguration d’un Flow qui possède un tel système de synchronisation avec l’entité ETP distante. Cette reconfiguration prenant du temps, il peut être nécessaire d’attendre qu’elle soit terminée avant d’effectuer l’action de reconfiguration (de niveau ATL) suivante. Retrait/ajout d’un composant protocolaire au sein d’un Channel existant Afin de modifier la composition protocolaire d’un Channel, par ajout et/ou retrait d’un composant, il est nécessaire de mettre ce Channel en pause le temps d’effectuer la modification. La première opération à effectuer sera donc le gel des Channel, à commencer par le Channel émetteur de données, puis par le récepteur. Si les deux Channel émettent chacun, alors ils doivent mettre en pause leur capacité d’émission mais toujours être capables de recevoir des données. Pour cela, les Channel Manager ont la possibilité d’ordonner le gel de la transmission des messages depuis les buffers vers le Channel concerné aux multiplexeurs/démultiplexeurs du Data Plan. Ceux-ci vont alors cesser de transmettre les messages depuis les buffers vers les Channel, permettant à ceux-ci de vider les messages en cours de traitement. Par la suite, les Autonomic Manager vont retirer ou ajouter les différents composants protocolaires prévus, éventuellement de manière synchronisée, via une méthode d’ajout ou de retrait fournie par le Channel Manager. Celui-ci retire le composant protocolaire concerné, ou insère une nouvelle instance du composant protocolaire demandé à l’emplacement désiré. Ces modifications effectuées, les Autonomic Manager synchronisent le redémarrage des capacités réceptrices de leurs Channel, puis, par la suite, leurs capacités émettrices, par le déblocage de l’activité des multiplexeurs/démultiplexeurs. Déploiement d’un nouveau Channel en série Cette opération consiste à déployer un service composite au sein d’un nouveau Channel après avoir détruit le Channel actuellement en cours d’exécution. Tout d’abord, les deux Autonomic Manager synchronisent l’arrêt de leur Channel respectif, en mettant la communication en pause, comme précédemment. A ce moment, les Channel doivent terminer leurs envois et éventuelles retransmissions. Afin que cette étape ne s’éternise pas au détriment de la QoS demandée, il est important que l’Autonomic Manager puisse signifier un temps maximum d’attente au delà duquel la destruction du Channel est effectuée, travail terminé ou non. Ce temps doit donc être calculé en fonction de l’impact négatif causé par un arrêt prématuré du Channel, et indiquant le moment ou cet impact est plus faible que celui causé par l’attente de l’arrêt total de celui-ci. Une fois le travail du Channel terminé (ou le temps d’attente maximal atteint), celui-ci est détruit par le Channel Manager, qui le remplace ensuite par un nouveau Channel, contenant le nouveau service composite. De manière synchrone 873. Description comportementale de l’ATL à nouveau, les deux Autonomic Manager vont redémarrer la communication, les messages étant alors traités par le nouveau Channel. Déploiement d’un nouveau Channel en parallèle Cette opération similaire à la précédente, déploie le nouveau Channel et le démarre en parallèle de l’ancien qui finit son travail. Chaque Autonomic Manager doit synchroniser le numéro de séquence à partir duquel les messages doivent transiter par le nouveau Channel, par exemple en l’incluant dans le plan de reconfiguration. Si le nouveau Channel n’est pas encore déployé de chaque côté alors que ces messages doivent être envoyés, ils doivent être mis en tampon dans les buffers en attendant le démarrage du Channel. Les Autonomic Manager doivent en parallèle gérer la création du dit nouveau Channel, puis, de manière synchrone, le démarrer. Tout nouveau message dont le numéro de séquence est supérieur au numéro de séquence limite doit être traité par ce nouveau Channel. L’ancien Channel continue pendant ce temps d’effectuer son travail, et donc les éventuelles retransmissions. Une fois le travail de celui-ci effectué, il est détruit. 3.3 Traitement des retransmissions lors des transitions Toute reconfiguration réclame une certaine continuité dans le service fourni. Pour cela, le nouveau service déployé doit démarrer dans un état correspondant à celui du service qu’il remplace, au moment de la prise de relai de ce dernier. Nous allons illustrer cette problématique dans cette partie à travers l’exemple de la retransmission de messages, initialement émis avant la reconfiguration mais dont la retransmission devrait être effectuée après celle-ci. Pour ceci, nous caractérisons l’environnement à un instant donné par la paire E = {B, C} où B représente l’ensemble des besoins en qualité de service demandés par l’application, et C les contraintes imposées par le réseau. Afin de répondre à cet environnement, l’ATL va mettre en place un service S correspondant. Tous les messages doivent-ils cependant transiter par le même service ? Un message est émis avec les besoins de l’application au moment où celle-ci le soumet à l’émission, mais avec les contraintes du moment où il est réellement transféré au réseau. Ceci signifie que l’environnement donné pour un message est défini en deux temps : les besoins B au moment où l’application le soumet à l’ATL, et les contraintes C par la suite lorsque l’ATL le retire des buffers pour le faire transiter dans le Channel. Ainsi, si les besoins correspondant à ce message ne vont pas varier entre la transmission initiale et la retransmission du message, 883.3. Traitement des retransmissions lors des transitions les contraintes peuvent, elles, différer entre ces deux instants, les conditions du réseaux étant dynamiques. Cas d’une retransmission idéale Nous discutons ici de la solution idéale à adopter, dans le cas de systèmes sans limite de ressources et où les temps de reconfiguration sont négligeables. Du paragraphe précédent, on déduit que ce sont les raisons du changement d’environnement qui vont conditionner le service qui servira à retransmettre les messages le nécessitant. Bien sûr, les messages dont la première émission prend place après la reconfiguration, seront retransmis (si tant est que le nouveau service le prévoit) par le nouveau service. Seuls sont concernés les messages initialement transmis par l’ancien service. Changement de besoins Avant reconfiguration, nous nous trouvons dans la situation E1 = {B1, C1}. Le changement de besoins modifie donc l’environnement en E2 = {B2, C1} les contraintes n’ayant pas changé. Les messages ayant été initialement transmis par le service S1, répondant à l’environnement E1, ont donc été soumis à l’émission par l’application durant l’environnement E1. Les besoins qui leur sont associés sont donc les besoins B1. Les contraintes n’ayant pas changé et étant toujours C1, ces messages, au moment de leur émissions correspondront toujours à l’environnement E1. Ils devraient donc dans l’idéal être retransmis avec l’ancien service, S1. Ceci est possible dans l’idéal, car le système, n’ayant pas de limite de ressources, peut déployer S2 en parallèle de S1. Changement de contraintes Avant reconfiguration, nous nous trouvons dans la situation E1 = {B1, C1}. Le changement de contraintes modifie donc l’environnement en E2 = {B1, C2} les besoins n’ayant pas changé. Les messages ayant été initialement transmis par le service S1, répondant à l’environnement E1, ont donc été soumis à l’émission par l’application durant l’environnement E1. Les besoins qui leur sont associés sont donc les besoins B1. Les besoins n’ayant pas changé et étant toujours B1, ces messages, au moment de leur émissions correspondront maintenant à l’environnement E2. Ils devraient donc dans l’idéal être retransmis avec l’ancien service, S2. On peut donc dans ce cas opter pour une reconfiguration par modification du service en place, le transformant de S1 à S2, l’ancien service n’ayant plus d’utilité. Changement de besoins et de contraintes Nous ne considérons ici que le changement de besoins et de contraintes peut-être simultané. Dans les faits, il peut 893. Description comportementale de l’ATL être considéré comme tel à cause de la latence induite par la fonction de Monitoring. Avant reconfiguration, nous nous trouvons dans la situation E1 = {B1, C1}. Le changement de situation modifie donc l’environnement en E2 = {B2, C2} les besoins et les contraintes ayant changé. Les messages ayant été initialement transmis par le service S1, répondant à l’environnement E1, ont donc été soumis à l’émission par l’application durant l’environnement E1. Les besoins qui leur sont associés sont donc les besoins B1. Les contraintes ont cette fois changé et sont à présent C2 ainsi ces messages, au moment de leur émission correspondront toujours à un environnement E3 = {B1, C2} pour lequel il n’existe pas de service. Ils devraient donc dans l’idéal être retransmis avec un service, S3 temporaire uniquement dédié à leur retransmission. Ceci est possible dans l’idéal, car le système, n’ayant pas de limite de ressources, peut déployer S3 en parallèle de S2 et détruire S1, devenu inutile, ou modifier ce dernier en S3 si possible. Considérations sur les cas réels Bien évidemment, les systèmes possèdent des limites et les temps de reconfiguration selon les réseaux considérés, ne pourront pas toujours être vus comme négligeables. Ainsi, ces trois solutions sont une simple base sur laquelle construire des prises de décisions plus poussées, prenant en compte des variables plus complexes. En effet, si le déploiement de deux services en parallèle est impossible, que faire de ces messages ? Doit-on les envoyer avec le nouveau service, et donc avec un service n’étant pas forcément parfaitement approprié ? Ou doit-on considérer leur retransmission d’une importance moindre dans le nouveau contexte et l’abandonner, tout en détruisant l’ancien service ? Ces questions ne sont que quelques exemples de la complexité de la question de la prise de décisions, centrale dans un système comme l’ATL. Ce thème de la décision réclame à lui seul un étude ultérieure poussée et exhaustive. 3.4 Conclusion Dans ce chapitre nous avons présenté le comportement des différents composants de l’ATL dans deux cas particuliers : l’ouverture d’un point d’accès et la reconfiguration d’un service au sein d’un Flow. Ceci nous a permis de mettre en lumière différents cas possibles en fonction des systèmes, des applications et des choix faits ou faisables par l’ATL, offrant ainsi tout un panel de solutions pour répondre à un maximum de situations. Nous avons ensuite, à travers l’exemple de la retransmission de messages, illustré la problématique de la transition d’un service à un autre et levé des interrogations concernant la complexité du système de décision que réclame un système tel que l’ATL. 90CHAPITRE 4 Expérimentations et mesures Dans ce chapitre, nous détaillons des expériences en simulation et émulation qui ont permis la mise en évidence de l’intérêt d’une solution tel que l’ATL, ainsi que son coût potentiel. Dans une première partie, nous décrivons une simulation dans laquelle nous combinons MPTCP avec différents mécanismes de fiabilité partielle afin de tirer partie des capacités multi-chemins du protocole à des fins d’amélioration d’une transmission vidéo. Cette simulation nous permet ainsi de confirmer l’intérêt de combiner un protocole donné avec des mécanismes externes afin de moduler le service offert par celui-ci. Dans une deuxième partie, nous décrivons une simulation dans laquelle un changement d’environnement survient en milieu de communication — une transmission vidéo — à laquelle le système réagit en modifiant la composition protocolaire, basée sur MPTCP. Les résultats sont ensuite comparés au cas témoin où la composition protocolaire reste inchangée, afin de montrer le bénéfice induit. Enfin, la troisième partie de ce chapitre présente une illustration du coût d’une solution telle que l’ATL, en étudiant le cas du protocole de synchronisation d’ETP, dont les similitudes architecturales avec l’ATL ont été montrées au chapitre 2. Sommaire 4.1 De la composabilité des protocoles . . . . . . . . . . . . . . . . 92 4.1.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . 92 4.1.2 Description de l’expérience . . . . . . . . . . . . . . . . 93 4.1.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . 97 4.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.2 De l’intérêt de l’adaptation dynamique . . . . . . . . . . . . . 102 4.2.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . 103 914. Expérimentations et mesures 4.2.2 Description de l’expérience . . . . . . . . . . . . . . . . 103 4.2.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . 104 4.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.3 De l’overhead de la signalisation . . . . . . . . . . . . . . . . . 106 4.3.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . 106 4.3.2 Description de l’expérience . . . . . . . . . . . . . . . . 107 4.3.3 Résultats attendus . . . . . . . . . . . . . . . . . . . . 114 4.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.1 De la composabilité des protocoles Cette section du chapitre propose d’étudier l’intérêt de coupler protocoles existants et micro-protocoles afin de permettre une meilleure satisfaction des besoins en qualités de service de l’application, par rapport à l’utilisation du protocole seul. Pour ceci nous prenons l’exemple d’une application de streaming vidéo communiquant via un réseau de type 3G sur des terminaux comportant plusieurs interfaces. Afin d’en tirer parti, nous utilisons un protocole multi-domicilié, MPTCP, et le composons avec des mécanismes de fiabilité partielle. 4.1.1 But de l’expérience Le but de cette expérience est de démontrer l’intérêt de coupler des mécanismes protocolaires dédiés à certaines tâches, et génériques, afin d’être réutilisables, avec des protocoles standards. Le but n’est pas d’étudier l’efficacité d’une composition de tels mécanismes avec un protocole comme le fait l’ATL, par rapport à une inté- gration d’un mécanisme au sein d’un protocole particulier, mais d’étudier l’intérêt d’un tel couplage, quelle que soit la méthode retenue. MPTCP utilise les différentes interfaces présentes sur le système, de manière concurrente, afin d’augmenter la capacité réseau disponible et réduire le délai de transmission car, étant basé sur TCP, celui-ci est lié à cette capacité. Cependant, pour cette même raison, le service offert par MPTCP est parfaitement fiable et parfaitement ordonné, rendant ainsi ses avantages moins intéressants pour des applications de type streaming multimédia, qui peuvent tolérer une certaine quantité de pertes. Le but de cette expérience est de démontrer l’intérêt de combiner des microprotocoles de fiabilité partielle avec MPTCP, afin de tirer parti de ses avantages tout en améliorant la qualité de service envers des applications pour lesquelles ce protocole ne serait pas totalement adéquat. 924.1. De la composabilité des protocoles Le caractère générique, c’est-à-dire indépendant d’un protocole particulier, de ces micro-protocoles leur permet d’être associé à d’autres protocoles, potentiellement en cours de communication (cf. 4.2). Ceci permet ainsi de mettre en évidence l’utilité de l’ATL, afin de gérer ce type de situation de manière autonome. L’expérience est menée en simulation, grâce au simulateur ns-2. 4.1.2 Description de l’expérience 4.1.2.1 Choix de l’application L’application choisie est une application de vidéo interactive basée sur le codec H.264. Ce type d’application tolère un certain niveau de perte d’information, mais requiert un délai de transit borné : les paquets dont le délai dépasse 400 ms seront considérés comme obsolètes et inutiles. Pour simuler cette application, nous utilisons une vidéo de 400 images, encodées en YUV au format QCIF, soit une résolution de 176x144. La vidéo dure 13,6 s et est émise à un rythme de 30 images par seconde. Du côté du récepteur, l’adaptation effectuée consiste à écarter les paquets dont le délai a dépassé les 400 ms. La vidéo, encodée en H.264, est composée d’images de type I, P ou B. Images I : Ces images sont autonomes. Elles peuvent être décodées indépendamment des autres. Images P : Ces images encodent uniquement les informations qui ont été modi- fiées au sein de l’image par rapport à l’image I ou P précédente qu’elle prend pour référence. Ainsi, si une image I, ou P, est perdue, toutes les images P successives qui en dépendent seront mal décodées, provoquant des erreurs d’affichage. Images B : Ces images se basent sur le même principe que les images P mais utilisent en référence une image I ou P précédente et une image I ou P suivante. Ces images sont donc fortement dépendantes du décodage correct des autres images du flux. Ainsi, toutes les images ne revêtent pas la même importance au sein du flux vidéo. La perte d’une image B sera moins pénalisante que la perte d’une image P, elle-même moins handicapante que la perte d’une image I. Notons également que selon les choix à l’encodage de la vidéo, certaines images B peuvent également servir de référence, introduisant ainsi une hiérarchie à quatre niveaux et non plus trois. L’utilisation d’une interface spécifique de type IPMH permet l’assignation de différents niveaux de priorité à chaque message applicatif, permettant à MPTCP et aux micro-protocoles de différencier le traitement qui sera appliqué à chacun. 934. Expérimentations et mesures 4.1.2.2 Micro-protocoles utilisés Pour réaliser cette simulation, les mécanismes suivants ont été implémentés dans ns-2, au sein du modèle ns-2 de MPTCP, recommandé par le working group MPTCP de l’IETF [Nis]. Chacun de ces micro-protocoles implémente un concept de fiabilité partielle dans le but d’améliorer le délai de transit afin de correspondre aux exigences de l’application, en tirant parti de la tolérance aux pertes de celle-ci. Adaptation à l’émission : le Selective Discarding Le Selective Discarding a été introduit dans [LBL89] et permet une adaptation du flux à l’émission. Ce mécanisme consiste à éliminer les paquets de moindre importance lorsque le réseau est saturé. Grâce à l’interface, MPTCP peut récupérer les informations relatives à la priorité de chaque type d’image. En utilisant cette information, notre implémentation du Selective Discarding écarte systématiquement les images de type B avant leur émission, car ce sont les images les moins importantes. Nous nous attendons ainsi à avoir une qualité de service améliorée, car le non-envoi d’un paquet conduit à moins de congestion et donc de perte sur le réseau et également à un délai moindre pour les images I et P, qui sont les images les plus importantes pour le décodage de la vidéo du côté du récepteur. Adaptation à la réception : le Time-Constrained Partial Reliability L’autre implémentation réalisée du concept de fiabilité partielle intègre l’aspect temporel de la contrainte. Puisque MPTCP utilise plusieurs chemins pour accroître la capacité réseau disponible, le risque de paquets arrivant dans le désordre s’en trouve augmenté, ces chemins possédant des caractéristiques différentes. MPTCP offrant un service d’ordre total, celui-ci place en buffers les messages arrivant dans le désordre jusqu’à réception des paquets manquants, afin de délivrer le tout dans l’ordre à l’application. Ces paquets en attente peuvent devenir obsolètes à cause de l’attente des paquets en retard, alors qu’ils sont disponibles et pourraient être utiles à l’application. Ainsi, le mécanisme a pour but que ces paquets soient délivrés avant leur obsolescence, considérant les paquets en retard comme perdus et à présent inutiles, en acquittant leur perte auprès de l’émetteur. L’implémentation proposée calcule à tout instant le délai de transit applicatif des paquets dans les buffers de réception de l’hôte puits de la communication, c’est-à-dire le délai écoulé depuis leur soumission à l’émission par l’application émettrice. Lorsque ce délai se rapproche des 400 ms de délai maximum, les paquets concernés sont délivrés à l’application et les paquets manquants, considérés à présent obsolètes, sont déclarés perdus et acquittés auprès de l’émetteur, comme si ceux-ci avaient été correctement reçus. Ainsi, l’émetteur les croyant arrivés à 944.1. De la composabilité des protocoles destination ne les réémettra pas. Si ceux-ci arrivent par la suite, ils seront tout simplement écartés. Notons que la simulation permet d’éluder la question de la synchronisation des deux hôtes. En expérimentation réelles, celle-ci devrait être prise en compte via des solutions comme NTP [Mil10] ou toute autre solution offrant une précision appropriée. Le caractère du mécanisme protocolaire resterait alors local, mais sa dépendance envers un tel système de synchronisation, par nature distribué, rendrait la composition protocolaire globalement distribuée. Rappelons enfin que le but de cette expérience est d’étudier le couplage de mécanismes protocolaires avec un protocole standard, et non l’étude du mécanisme en lui-même. 4.1.2.3 Simulation Les deux mécanismes précédents permettent trois combinaisons : 1. MPTCP-SD qui couple MPTCP au Selective Discarding ; 2. MPTCP-PR qui couple MPTCP à la Time-Constrained Partial Reliability. 3. MPTCP-PR-SD qui couple MPTCP à la Time-Constrained Partial Reliability et au Selective Discarding. Chacune d’elles a été testée sur l’environnement conseillé par le working group MPTCP. Celui-ci est représenté figure 4.1. Figure 4.1: La topologie du réseau simulé La source, abrégée S, représente le système hébergeant l’application émettrice de données, et le puits, abrégé P, le système hébergeant l’application réceptrice. Les machines r1 à r4 sont des routeurs intermédiaires. Nous disposons ainsi de deux chemins distincts utilisables par MPTCP. Ces chemins sont donc : – S, a, r1, b, r3, c, P ; – S, d, r2, e, r4, f, P. 954. Expérimentations et mesures Afin d’évaluer les performances des différentes combinaisons de mécanismes avec MPTCP, nous simulons un transfert vidéo entre S et P. Les capacités des liens d’accès a, d, c et f ont été fixés soit à 1,8 Mbps, soit à 3,6 Mbps et les liens du cœur de réseau, b et e, sont fixés à 1 Mbps ou 0,5 Mbps. Ces valeurs ont été choisies proches de débits théoriques utilisables sur des liens WWAN HSDPA. Elles ont également été choisies afin de créer des situations dans lesquelles MPTCP devra réagir à un manque de capacité. Aucun trafic concurrent n’est injecté dans le réseau simulé. Les délais des différents liens ont été fixés à 5 ms ou 10 ms. Sept scénarios ont été définis, et sont résumés dans les tableaux 4.1 à 4.3. 1 2 a et c 3,6 Mbps; 10 ms 3,6 Mbps; 10 ms b et e 1 Mbps; 5 ms 1 Mbps; 5 ms d et f 3,6 Mbps; 10 ms 1,8 Mbps; 10 ms Congestion faible faible Table 4.1: Résumé des scénarios 1 et 2 3 4 5 a et c 3,6 Mbps; 5 ms 1,8 Mbps; 5 ms 1,8 Mbps; 10 ms b et e 0,5 Mbps; 5 ms 1 Mbps; 5 ms 0,5 Mbps; 5 ms d et f 3,6 Mbps; 5 ms 1,8 Mbps; 5 ms 1,8 Mbps; 10 ms Congestion moyenne moyenne moyenne Table 4.2: Résumé des scénarios 3 à 5 6 7 a et c 3,6 Mbps; 10 ms 1,8 Mbps; 10 ms b et e 0,5 Mbps; 5 ms 0,5 Mbps; 5 ms d et f 3,6 Mbps; 10 ms 1,8 Mbps; 10 ms Congestion forte forte Table 4.3: Résumé des scénarios 6 et 7 Métrique d’évaluation La qualité est évaluée selon un calcul par image du Peak Signal to Noise Ratio (PNSR). Nous utlisons Evalvid [KRW03], un ensemble d’outils permettant dévaluer la qualité d’une transmission vidéo sur réseaux réels ou simulés. Evalvid permet notamment la mesure de différents paramètres de QoS 964.1. De la composabilité des protocoles tels que le taux de perte ou le délai de bout en bout. Il existe une correspondance entre le PNSR et une autre métrique d’évaluation vidéo, subjective celle-ci, le Mean Opinion Score (MOS), résumée dans le tableau 4.4. PNSR (dB) MOS > 37 Excellent 31 à 37 Bon 25 à 31 Moyen 20 à 25 Faible < 20 Pauvre Table 4.4: Les correspondances entre PNSR et MOS 4.1.3 Analyse des résultats 4.1.3.1 Comparaison des performances de MPTCP avec TCP et UDP Dans cette partie, nous comparons la qualité vidéo, caractérisée par le PNSR, lorsque la transmission est effectuée avec MPTCP et lorsqu’elle est effectuée TCP ou avec UDP. Les calculs du PNSR sont effectués après réception des données et rejet de celles ayant un délai de transmission applicatif supérieur à 400 ms. Les tableaux 4.5 et 4.6 montrent les bénéfices engendrés sur le PNSR par l’utilisation de MPTCP. On peut remarquer que pour UDP et TCP, la colonne 2 est vide : comme deux chemins avec des caractéristiques différentes sont utilisés par MPTCP, la comparaison avec UDP ou TCP, tous deux mono-chemins, pour ces caractéristiques est effectuée dans les cas 1 et 5. Ces chemins sont utilisés dans les simulations 1 et 4 pour TCP et UDP. Le PNSR pour TCP est parfois à 0 dB car tous les paquets, dans ces situations, ont dépassé le délai maximum de 400 ms et ont ainsi été rejetés car considérés comme obsolètes. Scénario 1 2 3 4 UDP 13,98 14 4,27 TCP 4,66 4,64 0 MPTCP 24,96 25,59 22,88 22,51 Table 4.5: PNSR moyen en dB des simulations 1 à 4 Les tableaux 4.7 et 4.8 montrent que le délai est également globalement réduit grâce à l’utilisation de MPTCP. Les tableaux 4.9 et 4.10 montrent quant à eux l’apport de MPTCP sur le taux de pertes pour chaque type d’image. 974. Expérimentations et mesures Scénario 5 6 7 UDP 4,26 4,25 4,13 TCP 0 0 0 MPTCP 23,05 19,15 17,14 Table 4.6: PNSR moyen en dB des simulations 5 à 7 Scénario 1 2 3 4 UDP 432 475 474 TCP 419 481 465 MPTCP 334 346 296 358 Table 4.7: Délai moyen en millisecondes des simulations 1 à 4 Scénario 5 6 7 UDP 516 575 616 TCP 527 581 629 MPTCP 319 403 428 Table 4.8: Délai moyen en millisecondes des simulations 5 à 7 Scénario 1 2 3 4 I UDP 95,5 95,5 100 TCP 100 100 100 MPTCP 55,5 57,7 77,7 60 P UDP 71,9 73,03 92,13 TCP 23,59 23,59 100 MPTCP 6 5,61 14,6 11,2 B UDP 72,93 73,3 87,59 TCP 0,75 14,41 100 MPTCP 7,8 6,3 6,3 5,6 Table 4.9: Taux de pertes des simulations 1 à 4 4.1.3.2 Comparaison de MPTCP avec et sans mécanismes couplés Nous allons à présent comparer la qualité de la vidéo reçu via un transfert utilisant MPTCP et utilisant les différentes combinaisons de mécanismes : – MPTCP-SD ; – MPTCP-PR. La comparaison a été effectuée dans le cadre du scénario 4 décrit dans le tableaux 4.2. 984.1. De la composabilité des protocoles Scénario 5 6 7 I UDP 100 100 100 TCP 100 100 100 MPTCP 55,5 80 82,2 P UDP 89,88 93,25 96,62 TCP 100 100 100 MPTCP 11,2 15,7 16,8 B UDP 86,09 91,72 95,86 TCP 100 100 100 MPTCP 1,12 19,17 7,1 Table 4.10: Taux de pertes des simulations 5 à 7 Si les résultats décrits 4.1.3 nous ont permis d’évaluer les bénéfices de MPTCP par rapport à TCP ou UDP, nous pouvons remarquer sur la figure 4.2 que le PNSR moyen pour MPTCP est de 22,5 dB, montrant que la qualité moyenne de la vidéo n’est pas suffisante pour une utilisation confortable. En effet, le tableau 4.4 montre que le PNSR doit être supérieur à 25 dB pour avoir une qualité vidéo satisfaisante. On remarque également sur la figure 4.2 que le PNSR descend sous 22,5 dB pendant un temps prolongé, avant l’image no 200 et aux alentours de l’image no 300. Ces résultats se confirment à la visualisation de la vidéo reconstituée après réception, et motivent l’étude de la combinaison de MPTCP avec les mécanismes précédemment introduits. Les figures 4.3 et 4.4 montrent le PNSR image par image pour l’utilisation de MPTCP-PR et MPTCP-SD respectivement, dans le contexte du scénario 4. Nous remarquons immédiatement sur la figure 4.3 que le PNSR moyen obtenu est meilleur que celui observé avec MPTCP seul. En effet, celui-ci atteint à présent 24,74 dB. Cette moyenne est cependant toujours sous la barre des 25 dB, bien que proche. Nous pouvons cependant remarquer que plusieurs fois la vidéo reconstituée s’approche d’un PNSR de 35 db, ce qui est un très bon score. Malheureusement nous notons également des performances réduites durant la seconde moitié de la vidéo (entre la 230e et la 340e image). Ceci peut s’expliquer par la perte d’informations importantes, telle qu’une image I, déclarée perdue alors que celle-ci pouvait encore être utile, non plus pour son affichage, mais pour servir de référence pour des images P et B ultérieures. Ceci pourrait être amélioré en permettant un plus grand paramétrage du mécanisme, afin de moduler la date d’obsolescence en fonction du type de l’image, et non plus utiliser une date fixe. Malgré ce léger écueil, et bien que la différence dans les chiffres puisse sembler mineure (10 %), l’amélioration est nettement visible au visionnage et on s’approche d’une utilisation confortable. 994. Expérimentations et mesures Figure 4.2: PNSR par image en utilisant MPTCP, scénario 4 La figure 4.4 représente l’évolution du PNSR par image avec utilisation de MPTCP-SD. On voit ici que le PNSR moyen dépasse 25 dB, avec une valeur de 26,04 dB. Les oscillations sont dues au fait qu’à chaque image B, le PNSR chute, en raison du rejet systématique de celle-ci. Cependant, celui-ci étant plus élevé pour les images P et I, la moyenne s’en trouve relevée. Notons malgré tout une chute du PNSR aux alentours de la 200e image. Celleci est due à la perte d’une image I ou P servant donc de référence à plusieurs images qui la suivent. Celles-ci, ne pouvant se baser sur la bonne référence, seront décodées et affichées incorrectement, créant des différences trop fortes avec la vidéo d’origine, traduites par ce creux dans la courbe. 1004.1. De la composabilité des protocoles Figure 4.3: PNSR par image en utilisant MPTCP-PR, scénario 4 4.1.4 Conclusion L’expérience présente a permis de démontrer les gains en Qualité de Service que l’on peut obtenir via la combinaison de protocoles avec des mécanismes externes. Ces bénéfices pourraient encore être améliorés, notamment par l’optimisation des mécanismes, en permettant un paramétrage plus fin de ceux-ci par exemple. En effet, ici le Selective Discarding rejette systématiquement toute image de type B. Le même mécanisme pourrait être amélioré en permettant de modifier le taux de rejet pour chaque type d’image indépendamment ou en fonction des relations de dépendance d’une image à l’autre. Un paramétrage plus fin, cependant, requerrait une adaptation dynamique afin de pouvoir tirer au mieux parti de celui-ci. Ces décisions et adaptations ne peuvent pas être requises de la part de l’utilisateur, ni de l’application. En effet, cellesci sont trop complexes, et réclament une connaissance poussée du réseau et des protocoles. L’ATL pourrait cependant, parfaitement remplir ce rôle. La section 1014. Expérimentations et mesures Figure 4.4: PNSR par image en utilisant MPTCP-SD, scénario 4 suivante étudie ce type d’adaptation dynamique. 4.2 De l’intérêt de l’adaptation dynamique Dans cette deuxième partie, nous nous intéressons à l’effet de l’adaptation dynamique de la composition protocolaire, c’est-à-dire sa modification en cours de communication. Pour ceci, nous utilisons le même contexte que l’expérimentation précédente, en utilisant un nouveau mécanisme pour MPTCP : un load balancer chargé de répartir les paquets à envoyer sur les différents chemins possibles, en fonction de la priorité des messages et de la qualité de chaque chemin. 1024.2. De l’intérêt de l’adaptation dynamique 4.2.1 But de l’expérience Le but de cette expérience est de démontrer l’intérêt de procéder à des modi- fications structurelles de la composition protocolaire en cours de communication. En effet, les adaptations comportementales, i.e. les modifications de paramètres, existent déjà dans les protocoles actuels. par exemple, TCP adapte la taille de ses fenêtres de contrôle de congestion et de contrôle de flux, en fonction de l’état de congestion du réseau, et de la saturation du système récepteur des données. Ici, nous nous intéressons à l’adjonction d’un nouveau mécanisme à une composition protocolaire existante. Contrairement à la section 4.1, le mécanisme est pensé pour les protocoles multi-domiciliés. Ceci n’est pas contradictoire vis-à-vis de l’ATL. En effet, celle-ci est pensée pour accueillir des composants pouvant avoir des conditions de dépendance envers d’autres composants. Comme pour la section 4.1, l’expérience est réalisée en simulation, grâce au simulateur ns-2. 4.2.2 Description de l’expérience 4.2.2.1 Choix de l’application L’application choisie est la même que pour l’expérience précédente. Sa description peut donc être trouvée en 4.1.2.1. 4.2.2.2 Micro-protocoles Le mécanisme implémenté ici est un load-balancer, ou répartiteur de charge. Dans le contexte des protocoles multi-domiciliés, son rôle est de répartir les paquets sur les différents chemins. Dans MPTCP, il est appelé packet scheduler. Notre implémentation de ce répartiteur se base, comme pour les mécanismes précédents, sur la différence de priorité des différentes images. Notre implémentation va donc diriger les paquets sur l’un ou l’autre chemin en fonction de l’importance de chacun. Le but étant toujours de faire en sorte que les images les plus importantes aient le plus de chances d’arriver intactes à destination, le répartiteur va diriger les paquets vers le chemin le plus sûr pour les plus importants, et le moins sûr pour les moins importants. La notion de chemin sûr est ici à préciser. Celle-ci implique bien évidemment un monitoring du réseau constant permettant une modélisation de chaque chemin. Afin de définir ensuite le plus sûr, il faut décider selon quelles caractéristiques un chemin sera qualifié de sûr : son taux de congestion, sa capacité, son délai de transit. . . La répartition doit ensuite être décidée entre les différents niveaux de priorité qui peuvent être plus ou moins nombreux que le nombre de chemins. Un para- 1034. Expérimentations et mesures métrage plus fin peut même permettre de faire passer un certain pourcentage de chaque priorité sur chaque chemin. Dans notre implémentation et pour cette expérience, les images I et P sont dirigées vers le meilleur chemin, les images B vers le moins bon. 4.2.2.3 Simulation L’environnement réseau employé est le même qu’en 4.1 et est donc représenté sur la figure 4.1. De même, nous utilisons le PNSR comme mesure de la qualité de service. Deux environnements différents ont été définis. ils sont résumés dans le tableau 4.11. 1 2 a et c 1,8 Mbps; 10 ms 1 Mbps; 10 ms b et e 1 Mbps; 5 ms 1 Mbps; 5 ms d et f 3,6 Mbps; 10 ms 3,6 Mbps; 10 ms Table 4.11: Résumé des scénarios Pour chacun de ces scénarios, nous avons simuler le transfert de la vidéo en utilisant MPTCP et MPTCP couplé à notre load-balancer, indiqué si après MPTCPLB, afin de déterminer quelle composition obtient les meilleures performances pour chaque environnement. Dans un second temps, nous avons effectué la simulation du transfert avec modification de l’environnement. A mi-chemin du transfert, l’environnement change de 1 vers 2, et la composition protocolaire s’adapte en conséquence. Nous pouvons ainsi déterminer l’apport de la reconfiguration dynamique par rapport à un transfert qui emploierait le même protocole de bout en bout, comme c’est le cas actuellement. 4.2.3 Analyse des résultats La première série de simulation compare MPTCP et MPTCP-LB sur chacun des deux environnements. Le tableau 4.12 résume ces résultats. Simulation 1 2 MPTCP 25,59 21,75 MPTCP-LB 24,56 24,20 Table 4.12: PNSR en dB 1044.2. De l’intérêt de l’adaptation dynamique Nous pouvons voir que sur le premier environnement, le PNSR obtenu avec MPTCP est meilleur que ce lui obtenu avec MPTCP-LB. En effet, les deux chemins étant très similaires, le répartiteur de charge ne peut exprimer pleinement son potentiel, et la répartition classique effectuée par MPTCP mène à de meilleurs résultats. Cependant, dans le second environnement, nous pouvons remarquer que les bénéfices du load-balancer peuvent s’exprimer, en raison de la grande dissimilarité des chemins. Ces résultats nous poussent à nous poser la question suivante : quels bénéfices pourrait-on tirer de l’activation dynamique du load-balancer selon la différence de caractéristiques entre les chemins ? Cette simulation reprend les caractéristiques de l’environnement no 1 puis, au milieu du transfert, change les conditions pour celles de l’environnement no 2. Dans cet environnement changeant, nous effectuons deux simulations. La première avec MPTCP seul, et la seconde en intégrant dynamiquement notre répartiteur de charge lors du changement d’environnement, celui-ci donnant de meilleures performances globales dans ces nouvelles conditions. Les résultats obtenus sont indiqués dans le tableau 4.13. Simulation MPTCP seul MPTCP puis MPTCP-LB PNSR 21,77 22,56 Table 4.13: PNSR obtenu sans et avec adaptation dynamique Nous pouvons remarquer une amélioration de 0,79 dB grâce à l’intégration dynamique du load-balancer. Cette valeur amène les commentaires suivants. 1. Ce bénéfice, si petit soit-il, est-il significatif, particulièrement pour un PNSR d’environ 21 dB? En effet, en dessous de 25 dB la qualité vidéo doit être améliorée. Cependant, le visionnage de la vidéo nous permet déjà d’observer une amélioration. 2. Ces améliorations sont obtenues dans le cas idéal où le changement de composition protocolaire s’effectue sans délai par rapport au changement d’environnement. Le problème du coût de cette adaptation en conditions réelles se pose donc et doit être évalué. 4.2.4 Conclusion Dans cette section, l’expérience menée a permis de mettre en évidence les bé- néfices qui peuvent être apportés par une adaptation dynamique de la composition protocolaire vis-à-vis du contexte. Ces bénéfices sont cependant à mettre en perspective du déroulement de la simulation : en effet celle-ci met en place un cas 1054. Expérimentations et mesures idéal dans lequel le temps d’adaptation au contexte est nul. Les bénéfices seront probablement donc moindres en situation réelle. Le paramétrage du mécanisme utilisé ici, cependant, et comme dans la section 4.1, devrait pouvoir être modifiable, afin de décider quelle proportion de chaque type d’image doit passer par chaque chemin. La décision de recomposition et le paramétrage doivent alors être pris en charge par un système de décision et de gestion autonome tel que l’ATL. Celui-ci devra également, dans ses décisions, prendre en compte les modifications de performances induites par le temps de reconfiguration. La section suivante s’intéresse aux temps de reconfiguration. 4.3 De l’overhead de la signalisation La troisième partie de ce chapitre étudie le coût de la signalisation sur le déroulement de la communication. En effet parmi les différentes fonctionnalités de l’ATL, certaines requièrent une synchronisation entre les deux pairs de la communication. Afin d’accomplir cette synchronisation, il est nécessaire d’avoir des échanges de messages de contrôle entre les Autonomic Manager. Cette section tente d’évaluer l’impact des échanges de signalisation liés à la reconfiguration comme décrite en section 3.2. 4.3.1 But de l’expérience Cette expérience a pour but de déterminer le coût induit par les besoins en signalisation. Pour ce faire, nous utilisons ETP comme framework de composition protocolaire. En effet, la structure d’ETP étant proche de celle de l’ATL, ce dernier pouvant être vu comme un Data Plan d’un point de vu structurel, son protocole de signalisation pour la négociation initiale et la recomposition dynamique peut être utilisé comme base de réflexion sur le coût de ces actions. En effet, la simple adjonction d’un Autonomic Manager à ETP permettrait de lui conférer toutes les caractéristique d’un Flow comme l’accueil et la composition de composants protocolaires ou le multiplexage de plusieurs Channel. ETP est capable d’accueillir des composants appelés Processing Modules. Ceuxci sont une décomposition des micro-protocoles qui prennent place au sein du framework. Afin de déployer les compositions à mettre en place, ETP intègre un protocole de synchronisation permettant aux deux entités pairs de négocier la composition à mettre en place. Afin de permettre sa reconfiguration dynamique, ETP intègre un système de déploiement correspondant au schéma de reconfiguration structurelle en parallèle décrit en 3.2.1.3. Celui-ci est accompagné d’une variation du protocole de synchronisation initiale permettant la reconfiguration. 1064.3. De l’overhead de la signalisation Nous utilisons donc ETP comme base de réflexion sur le coût de la signalisation dans le cadre de l’ATL, celle-ci étant proche structurellement nous permettant d’avoir une évaluation du coût de la signalisation liée à la reconfiguration. 4.3.2 Description de l’expérience 4.3.2.1 Plateforme de test L’expérience est ici réalisée en émulation, sur la plateforme laasNetExp hé- bergée au LAAS-CNRS. Celle-ci implémente une topologie représentée en figure 4.5. Figure 4.5: La topologie utilisée pour les tests L’accès aux différents systèmes se fait via la machine pong1. Celle-ci peut ensuite commander les différents hôtes présents sur le réseau via le réseau de commande 10.107.2.0. L’hôte pong2 accueille l’application source de données et pong4 l’application puits. Ces deux applications communiquent via les interfaces adressées 10.108.2.2 pour pong2 et 10.109.2.4 pour pong4, et à travers pong3, jouant le rôle de routeur et instanciant un émulateur de réseaux, netem. Celui-ci permet de modifier le comportement aux interfaces du système, afin de mettre en place un délai, un taux de perte, des duplications et les lois de probabilité régissant l’apparition de ces évènements. 1074. Expérimentations et mesures Les définitions de ces paramètres et leur modification dynamique, ainsi que les démarrages des applications puits et source sont centralisés sur pong1, qui utilise le réseau de commande pour effectuer ces actions. 4.3.2.2 Protocoles de signalisation ETP possède deux protocoles de signalisation pour la gestion structurelle de la composition protocolaire. Le premier est utilisé pour la synchronisation initiale et le second pour la reconfiguration. Synchronisation Cas d’utilisation Le protocole de synchronisation tient compte de plusieurs paramètres. Afin de l’établir, plusieurs cas d’utilisation ont été définis et sont représentés sur la figure 4.6. Figure 4.6: Cas d’utilisation du protocole de synchronisation d’ETP ETP ne possède pas de notion de client ou de serveur. A la place, la différence de comportement s’effectue en fonction du rôle de l’application en tant qu’émetteur ou récepteur de données. Ce caractère est identifiable par les options utilisées à 1084.3. De l’overhead de la signalisation l’ouverture du socket ETP. En effet, une application désirant émettre des données devra indiquer l’adresse IP à laquelle elle souhaite envoyer ces données. L’application est alors identifiée comme émettrice par ETP. Afin de simplifier la modélisation du protocole de synchronisation, nous considérons la communication comme unidirectionnelle. Une application source, uniquement émettrice de données, souhaite envoyer des messages à une application puits, uniquement réceptrice. Le second paramètre important est celui du caractère local ou distribué de la composition protocolaire. La composition qui est échangée entre deux entités ETP, est détaillée et précise exactement quel Processing Module doit prendre place dans quel conteneur, et à quel niveau de la pile de module hébergée par ce conteneur. Avec ETP, l’application a la charge de la gestion du protocole. C’est donc elle qui doit définir cette composition de Processing Modules. Ainsi, une application souhaitant un service de Transport n’assurant que le minimum, à l’instar d’UDP, demandera une composition vide, n’instanciant aucun micro-protocole et donc aucun module. Une telle composition est donc considérée comme nulle. Dans le cas contraire, deux cas peuvent se poser. En effet, certains micro-protocoles nécessitent l’instanciation de Processing Modules de part et d’autre de la communication, et sont dits distribués. D’autres en revanche ne nécessitent de module que sur l’émetteur, ou sur le récepteur, et sont dits locaux. Si une composition comporte au moins un micro-protocole distribué, celle-ci est également dite distribuée. Un système d’acquittement sélectif est un exemple d’un tel micro-protocole. En effet, les acquittements ont besoin d’être envoyés par le récepteur et traités par l’émetteur, impliquant un besoin de modules de chaque côté de la communication. Si une composition ne comporte que des micro-protocoles locaux, celle-ci est dite locale également. Un traffic shaper n’utilisant aucune information explicitement donnée par le récepteur est un exemple de micro-protocole local. Les sept cas d’utilisation représentés sur la figure 4.6 prennent en compte les combinaisons de ces différents paramètres afin de déterminer le comportement du protocole. Cette liste ne se veut pas exhaustive, l’hypothèse d’une communication unidirectionnelle étant déjà restrictive, mais a pour but d’offrir une réflexion suffisamment complète permettant de dériver les autres cas de ceux présents ici. Nous présentons le cas Distributed Sender Based utilisé dans cette expérience. En effet, comme décrit en 4.3.2.3, la présente expérience est basée sur une précé- dente étude dans laquelle ce type de déploiement est le plus adapté. Composition distribuée à la source, nulle au puits Le diagramme de la figure 4.7 décrit les échanges de messages entre les entités source et puits de la 1094. Expérimentations et mesures Figure 4.7: Diagramme de séquence du cas d’utilisation Distributed Sender Based communication, lorsque la source prévoit l’utilisation d’une composition distribuée et le puits d’une composition nulle. A la création du socket ETP, l’application source renseigne le protocole sur les coordonnées du puits et lui passe la composition micro-protocolaire à utiliser. Celleci est analysée par ETP et s’avère être distribuée, donc doit être communiquée à l’entité réceptrice. Cette dernière est prête à recevoir des messages. En effet lorsque l’application puits a ouvert son socket, celle-ci a précisé l’utilisation d’une composition nulle. L’entité ETP réceptrice est donc immédiatement disponible. L’entité ETP émettrice va ainsi envoyer une proposition contenant la composition distribuée. L’entité réceptrice la déploie immédiatement après réception. En effet, cette dernière n’ayant aucune composition déployée peut déployer celle demandée sans conflit avec une composition déjà existante. Après déploiement, celui-ci est acquitté auprès de l’émetteur, qui effectue à son tour le déploiement. En effet, si le récepteur avait eu un conflit entre la proposition de l’émetteur et sa propre composition, il aurait dû effectuer une contre-proposition. Attendre la ré- ponse du récepteur avant déploiement permet ainsi d’éviter un double déploiement par l’émetteur en cas de contre-proposition de la part du récepteur. 1104.3. De l’overhead de la signalisation Une fois la composition instanciée de chaque côté, la communication peut commencer. Reconfiguration La reconfiguration au sein d’ETP utilise le protocole de synchronisation existant. Ce denier se déclenche lors de la demande d’émission du premier message. Le but du protocole de reconfiguration est donc de préparer ETP à effectuer une seconde synchronisation, c’est-à-dire, comme évoqué précé- demment, de préparer un déploiement en parallèle d’une nouvelle composition. La figure 4.8 montre le déroulement de cet échange. Figure 4.8: Préparation à la reconfiguration L’échange se fait en deux temps. Lorsqu’une application, qu’il s’agisse de la source ou du puits, décide de changer la composition utilisée, l’entitée ETP associée envoie à son pair un message indiquant qu’il doit se préparer à un changement de configuration. Une fois la nouvelle composition prête à être mise en place, un acquittement est envoyé vers l’initiateur de l’échange qui peut se préparer à son tour. 1114. Expérimentations et mesures Par la suite, une synchronisation sera effectuée dans le cadre de cette nouvelle structure d’accueil, qui instanciera la nouvelle composition en parallèle de la précédente. Estimation du temps de synchronisation D’après les spécifications précé- dentes, on peut établir une première estimation du temps de synchronisation en fonction du RTT, donc du délai du réseau. Dans le cas d’étude décrit en 4.3.2.2, on remarque que l’échange se compose uniquement d’un message de proposition et de son acquittement, créant donc un RTT de délai. De plus, chaque système doit déployer la composition. Le système récepteur, cependant, effectue son dé- ploiement entre la réception de la composition et l’émission de son acquittement ce qui, en toute rigueur, l’inclue dans le RTT. Enfin nous admettons que les temps de déploiement sur chacun des hôtes sont équivalents car : – les systèmes utilisés dans le cadre de cette expérience sont les mêmes ; – le temps de déploiement est supposé être court, voire négligeable, face au délai du réseau. Le temps de synchronisation est donc estimé à : Ts = RT T + Td (4.1) où Ts représente le temps de synchronisation et Td le temps de déploiement d’une composition sur un système. Une reconfiguration demande tout d’abord sa préparation, décrite en 4.3.2.2, puis une synchronisation de la nouvelle composition. Le temps d’une reconfiguration sera donc : Tr = Tp + Ts (4.2) où Tr est le temps de reconfiguration total et Tp est le temps préparation. Or : Tp = RT T (4.3) ce qui nous permet de conclure que le temps total de reconfiguration Tr devrait s’exprimer ainsi : Tr = 2RT T + Td (4.4) 4.3.2.3 Protocole expérimental L’expérience réalisée est basée sur des mesures réalisées dans [VW09]. Un transfert de cinq minutes est réalisé, entre une application source située sur la machine 1124.3. De l’overhead de la signalisation pong2 et une application puits située sur pong4, via pong3, émulant le réseau. Ce transfert doit respecter les objectifs de qualité de service suivant : – délai maximum de 150 ms; – taux de pertes maximum de 10 %. Durant ce transfert, chaque minute, les taux de pertes et délai de l’environnement réseau sont modifiés. Les travaux réalisés dans [VW09] associent à chaque environnement, une composition protocolaire pour ETP ayant la plus forte probabilité de respecter ces objectifs en qualité de service. La succession de contextes réseau et les compositions associées sont résumées sur la figure 4.9. Figure 4.9: Caractéristiques des cinq environnements réseau et compositions associées Description des compositions EMPTY : La composition EMPTY représente une composition « vide », ce qui dans le cas spécifique d’ETP correspond à offrir un service équivalent à celui d’UDP. SACK-FR : Le Selective Acknowledgement with Full Reliability (SACK-FR), est un mécanisme de contrôle des pertes par acquittements sélectifs, équivalent à l’option SACK utilisée par le protocole TCP [Mat96]. Le mécanisme SACK disponible dans ETP permet un paramétrage du taux de pertes maximum acceptable. Nous l’utilisons ici avec une tolérance de 0 %, interdisant donc toute perte. A-EC : L’Autonomic Error Control (A-EC) adjoint un gestionnaire autonome au SACK permettant de modifier à la volée la tolérance aux pertes en fonction d’un double objectif de taux de pertes maximum d’une part et de délai de transit maximum d’autre part, tentant d’équilibrer au mieux ces deux critères. TFRC : Le mécanisme TFRC, pour TCP Friendly Rate Control, offre une implémentation pour ETP de l’algorithme TFRC [Flo08]. 1134. Expérimentations et mesures Le premier environnement, par exemple, est caractérisé par un taux de perte de 5 % et un délai de transit de 10 ms. La composition associée est une composition vide, les caractéristiques du réseau étant conformes aux objectifs en qualité de service. Après la première minute de simulation, l’environnement est modifié avec un taux de perte de 10 % et un délai de transit de 100 ms. La composition associée est alors l’A-EC, un système de reprise des pertes basé sur des acquittements sélectifs à fiabilité partielle. L’expérience originale considérait la reconfiguration comme immédiate, les deux compositions étant déployées en même temps sur chaque système. Cependant, un temps de monitoring et de décision de 5 s était déjà présent, seul le déploiement de ces décisions étant alors considéré comme immédiat. Le but de notre expérience est d’introduire le protocole de reconfiguration, afin de prendre en compte le temps de reconfiguration Tr effectif et de mesurer son impact sur les performances. 4.3.3 Résultats attendus Les résultats attendus par l’expérience ont été extrapolés à partir des résultats originaux. Pendant le temps de monitoring de l’expérience originale, l’ancien service continue de fonctionner sur le nouvel environnement. Nous avons appliqué une régression sur ce laps de temps, et l’avons étendu durant Tr après le monitoring. Taux de pertes La première métrique observée est le taux de pertes. Celuici a été mesuré au niveau de l’environnement réseau, et au dessus du service de Transport. Ainsi, nous pouvons observer l’impact du système de reconfiguration sur les performances du système. La figure 4.10 montre l’évolution du taux de pertes mesuré au niveau du réseau tout au long de l’expérience. On remarquera sur la courbe 4.11 que le taux de pertes observé reste globalement sous la barre demandée des 10 %. L’introduction du système de reconfiguration ne modifie d’ailleurs que partiellement les résultats obtenus lors de l’expérience originale, comme observé sur la courbe 4.12. En effet seul un court pic de pertes supplémentaire lors de la dernière recon- figuration est introduit dans les nouveaux résultats. Celui-ci semble être un effet de bord de notre méthode de prédiction, dû à l’application de la régression sur l’échelon observé vers 230 s, et ne devrait donc pas apparaître en situation réelle. Délai La seconde métrique observée est le délai de transit des paquets. Comme pour le taux de pertes, celui-ci a été mesuré au niveau de l’environnement et du service de Transport afin d’observer l’impact du système de reconfiguration sur les performances. 1144.3. De l’overhead de la signalisation Figure 4.10: Taux de pertes de l’environnement Comme pour le taux de pertes, le délai est peu impacté par le système de reconfiguration. Les prévisions de résultats de la courbe 4.14 n’indiquent en effet aucune différence par rapport aux résultats de l’expérience originale vus sur la courbe 4.15. Analyse Ces résultats étaient prévisibles. En effet, l’expérience originale pré- voyait un temps de monitoring et de prise de décision assez long de 5 s, devant lequel les 200 ms de déploiement maximum du système de reconfiguration sont faibles. L’overhead induit est donc négligeable. Un temps de reconfiguration total long comme celui-ci est cependant acceptable du point de vue de l’ATL. En effet, une telle reconfiguration n’aura lieu qu’initiée par l’Autonomic Manager. Or, les décisions de ce dernier ont trait à la gestion de la communication, le contrôle étant laissé à la charge des composants protocolaires ; les actions de gestion sont de plus entreprises avec une granularité temporelle longue. L’impact sur les performances, induit par cette reconfiguration sera donc 1154. Expérimentations et mesures Figure 4.11: Taux de pertes vu par le service de Transport suffisamment espacé dans le temps pour limiter la dégradation moyenne à long terme de la communication. 4.3.4 Conclusion Dans cette section nous avons observé le comportement du protocole de synchronisation d’ETP dont les caractéristiques structurelles sont proches de l’ATL. Celui-ci nous permet d’observer une tendance des dégradations de performances induites dans des systèmes tels que l’ATL. Bien que les résultats soient prometteurs, ceux-ci devront être testés sur un prototype réel, et étendus afin d’observer plus en détails les relations entre temps de reconfiguration et fréquence de reconfiguration, les variations en fonction de type d’environnement ou l’impact des caractéristiques du réseau sur une reconfiguration donnée. Ce type d’observations nous permettra alors d’enrichir la connaissance des Autonomic Manager de l’ATL afin de leur permettre un choix plus fin dans les multiples décisions auxquelles ils auront à faire face. En effet, les décisions prises 1164.4. Conclusion Figure 4.12: Taux de pertes vu par le service sans système de reconfiguration dans un contexte idéal peuvent avoir à être modifiées en fonction du contexte réel. L’étude des relations entre les différentes métriques et les différentes situations permettront de prendre ces cas en compte. 4.4 Conclusion Ce chapitre a montré par l’expérience l’intérêt que peut avoir un système tel que l’ATL. La première partie se base sur MPTCP pour montrer l’intérêt de composer des micro-protocoles avec des protocoles existants afin d’élargir le service offert par ces derniers sans nécessairement les modifier. Elle a en outre permis de mettre en avant le besoin d’autonomie dans la prise de décisions concernant la configuration et le paramétrage de chaque composant, celui-ci se révélant bien trop lourd pour l’utilisateur ou l’administrateur au cas par cas. La deuxième partie étend la première en introduisant le concept d’adaptation structurelle dynamique. En effet, ici la composition protocolaire change en cours 1174. Expérimentations et mesures Figure 4.13: Délai induit par l’environnement de communication pour s’adapter aux variations de l’environnement. Les gains tirés de cette adaptation étant positifs, nous remarquons tout de même que de tels changements sont complexes et doivent se faire sans intervention extérieure à la couche de Transport, ce qui implique à nouveau un besoin d’autonomie. La troisième partie se concentre sur le coût d’un système de reconfiguration. En effet, un système comme l’ATL doit disposer d’un protocole de signalisation adéquat permettant la reconfiguration dynamique. L’expérience ayant été soumise à des difficultés, les résultats présentés sont déduits du modèle théorique du coût du protocole de signalisation. On observe que ces résultats sont acceptables et permettent de respecter la qualité de service demandée par l’application. Des expériences plus poussées seront nécessaires sur un prototype concret de l’ATL, afin notamment d’observer les limites de celui-ci ainsi que les améliorations à y apporter. Celles-ci devront être complètes et poussées afin d’observer les effets de toutes les interactions possibles des multiples paramètres pouvant varier dans un système de cette complexité. 1184.4. Conclusion Figure 4.14: Délai vu par le service 1194. Expérimentations et mesures Figure 4.15: Délai vu par le service sans système de reconfiguration 120Conclusion générale Rappel des contributions La thèse soutenue dans ce manuscrit part du constat que l’évolution majeure de l’Internet, de ses applications, des équipements terminaux et des réseaux physiques sous jacents, ont conduit à une multiplication des propositions d’évolution ou d’adaptation des protocoles de Transport. Le chapitre 1 a décrit ce contexte et en a déduit cinq points de problématique relatifs à la complexité de choix et d’utilisation des protocoles, à la configurabilité des protocoles, à l’extensibilité des protocoles, à l’assujetissement des applications aux solutions protocolaires et au déploiement de nouveaux protocoles. Ces différents problèmes nous ont ensuite conduits à analyser les limites des solutions de Transport actuelles face au contexte moderne et de poser les bases d’une redéfinition de la couche Transport, l’Autonomic Transport Layer (ATL). L’approche soutenue est que cette dernière doit offrir aux applications supportées des points d’accès génériques leur permettant de requérir des services et non des solutions protocolaires. Les services requis sont ensuite réalisés via une composition protocolaire dont le choix revient à l’ATL de manière autonome et dynamique. Une telle couche Transport de ce type permet également l’intégration progressive et transparente de nouvelles solutions protocolaires ainsi que la combinaison de plusieurs mécanismes en un seul service composite afin de satisfaire le plus finement possible les souhaits exprimés par l’application. Le chapitre 2 a posé les bases de la structure de l’ATL. Tout d’abord, nous avons posé les objectifs du système et les paradigmes des architectures orientées service et basées composants sur lesquels reposent la construction de l’ATL. Nous avons ensuite défini une classification concernant les types d’actions à considérer (gestion, contrôle et données), les applications à prendre en compte (legacy, ATLaware et smart) et les systèmes avec lesquels interagir (legacy et ATL-enabled). Ces classifications nous ont contraint dans la construction de l’ATL pour à aboutir une solution complète pouvant s’intégrer de manière transparente dans le paysage actuel tout en permettant une évolution future souple. Le rôle des différents com- 121Conclusion générale posants constituant l’ATL ainsi que leur organisation les uns par rapport aux autres ont finalement été décrits. Le chapitre 3 a complété la description établie dans le chapitre 2 en détaillant le comportement des différents éléments de l’ATL dans deux cas d’utilisations particuliers. Le premier cas d’utilisation concerne l’ouverture d’un point d’accès au service de Transport. Ce type d’action diffère de l’ouverture d’un socket classique. Il doit en effet prendre en compte le fait que l’application l’effectuant ainsi que l’application distante à contacter peuvent être legacy, ATL-aware ou smart et que cette dernière peut être hébergée sur un système legacy ou ATL-enabled. Nous avons décrit les différentes phases de découverte et de négociation des services qui doivent avoir lieu pour mettre en place le service composite adéquat. Dans le second cas d’utilisation, nous avons décrit le comportement de l’ATL lors d’un changement de contexte en cours de communication. Le redéploiement du service composite durant le transfert des données pose en effet des problèmes de continuité du service rendu et du coût de ce changement. Nous avons clos le chapitre par des considérations sur la traduction de l’état de l’ancien service vers le nouveau en prenant l’exemple de la problématique de retransmission des messages initialement émis avant une reconfiguration. Le chapitre 4 a présenté différents résultats obtenus au cours d’expériences menées en simulation et en émulation. La première expérience, menée en simulation, a combiné Multipath TCP (MPTCP) à des mécanismes génériques orientées QoS afin d’améliorer la qualité d’un transfert vidéo interactif en altérant le comportement du protocole sans modifier l’implémentation de celui-ci. Par cette expérience, nous avons cherché à démontrer l’intérêt de l’utilisation de services composites utilisant des mécanismes génériques avec des protocoles traditionnels. Les résultats étant prometteurs, nous avons poursuivi ce travail par de nouvelles simulations portant sur l’adaptation dynamique de tels services. Le but était ici de montrer le gain perçu par le changement de composition en réponse aux changements de conditions réseaux en cours de communication. Les gains induits nous ont amené à nous interroger sur le coût induit par la signalisation inhérente à de telles actions. La troisième expérience a tenté d’établir une estimation de ce coût en observant l’impact du protocole de synchronisation utilisé dans le contexte d’une implémentation d’un protocole (ETP) aux principes proches de l’ATL. Cette étude a permis de conclure que ce coût était négligeable face à la fréquence faible de mise en œuvre des actions de gestion pour lesquelles cette signalisation est nécessaire. Perspectives De nombreuses perspectives de travail peuvent être envisagées à partir du travail décrit dans ce document. Nous les décrivons ci-après. 122Flux collaboratifs La première possibilité d’extension de ce travail consiste à l’intégrer dans la problématique des flux collaboratifs. Ce concept consiste à établir une hiérarchie d’importance dans les différents flux au sein d’une machine voire d’un réseau que plusieurs flux partagent, afin que chacun se fixe potentiellement une borne supé- rieure sur différents critères de qualité de service. Prenons l’exemple d’un réseau local domestique sur lequel un ordinateur de bureau télécharge via BitTorrent la dernière version d’un système Linux pendant qu’un ordinateur de salon diffuse un film obtenu en vidéo à la demande sur un service de streaming. Actuellement, le risque est que les différents flux BitTorrent non seulement saturent le flux entrant de l’ordinateur qui effectue le téléchargement, mais saturent également l’accès Internet de tout le réseau domestique, dégradant du même coup le visionnage en streaming. Le fait d’utiliser le paradigme de l’Autonomic Computing pour gérer chaque flux permet d’exposer une interface de contrôle similaire à celle exposée par le Touchpoint afin de diriger l’Autonomic Manager (cf. 2.2.3.2). Cette interface, notamment utilisée par les applications smart ou les applications de gestion réservées aux utilisateurs et administrateurs du système, permettrait également à un Autonomic Manager hiérarchiquement supérieur d’exprimer des préférences découlant d’une priorisation des flux sur la machine mais également sur le réseau. D’une telle utilisation de cette interface découlerait alors une répartition automatique des ressources réseau afin de donner la priorité à certains flux sur les différents critères de qualité de service. Dans notre exemple, le téléchargement pourrait automatiquement se limiter afin de permettre aux autres applications s’exécutant sur l’ordinateur d’avoir accès au réseau, mais également au flux vidéo d’être diffusé sans accroc. On peut également imaginer que de telles mesures puissent être mises en œuvre par des Autonomic Manager dont la responsabilité se porte sur la gestion de l’énergie du système, par exemple. M2M Le LAAS-CNRS et notamment le groupe SARA, travaille sur les problé- matiques de communication entre objets intelligents, en particulier dans le contexte du machine to machine, ou M2M, dans lequel la problématique des flux collaboratifs peut s’avérer prometteuse. En effet un réseau domestique faisant cohabiter des systèmes tels que les ordinateurs actuels, des capteurs et des robots, pourrait avantageusement tirer parti d’une répartition dynamique des ressources selon les flux. 123Conclusion générale Implémentation Dans le chapitre 4 nous avons mentionné l’absence de prototype de l’ATL comme première limite aux expérimentations possibles. Cette limite doit être levée. Un travail de précision du modèle dans une optique d’implémentation est obligatoire et prioritaire si nous voulons faire de l’ATL un projet sur lequel mener des études approfondies sur des problématiques complexes. Ce travail doit respecter deux objectifs. Le premier est un objectif de recherche. L’implémentation de l’ATL doit respecter son caractère modulable afin de permettre l’étude séparée de chacune de ses fonctionnalités et son influence sur les autres sans modification de ces dernières. Ainsi, l’étude de la prise de décision de la fonction de Planning au sein de l’Autonomic Manager pourrait être menée en parallèle de celle sur le Monitoring, chaque étude ne modifiant que la fonctionnalité sur laquelle elle porte sans devoir se préoccuper de l’autre. Le second objectif porte sur les performances et l’adoption du modèle. En effet, afin que celui-ci gagne en visibilité et qu’il suscite l’intérêt dans la communauté internationale, l’implémentation du modèle doit être faite de manière réaliste. Le prototype doit donc être spécifié et implémenté dans le but d’intégrer parfaitement un système d’exploitation comme un projet de production et pas uniquement d’étude. Motiver l’intérêt et l’adoption permettra d’ouvrir ce projet et favorisera la collaboration avec d’autres équipes ce qui lui apportera un poids supplémentaire et multipliera les études à son sujet. Décision et sécurité La prise de décision et la sécurité de l’ATL sont les deux études principales à mener. Nous avons vu au sein de ce document que le nombre de paramètres qui doivent être pris en compte dans les décisions de chaque Autonomic Manager peut être important. Une étude poussée sur l’incidence de ces paramètres sur les performances s’avère ainsi pertinente. Le système et l’algorithme de décision en lui-même, sujets non abordés dans le présent document, sont également des points indispensables à étudier et définir afin de donner une réalité à l’ATL. La sécurité représente l’autre point essentiel. Si l’ATL veut devenir un modèle valable, elle ne peut se permettre de représenter une faille dans un système d’exploitation. La sécurisation de l’architecture et des échanges qu’elle effectue ainsi que sa tolérance aux fautes représentent donc deux axes d’étude majeurs qui doivent être pris en compte afin de permettre à l’ATL d’évoluer et devenir un modèle dont la réalisation et l’intégration dans le paysage informatique se concrétiseraient. 124ANNEXE A Publications de l’auteur A.1 Revue internationale avec actes et comité de lecture [1] C. Diop, G. Dugué, C. Chassot, E. Exposito, and J. Gomez. Qosaware and autonomic-oriented multipath tcp extensions for mobile and multimedia applications. International Journal of Pervasive Computing and Communications, 8(4) :306–328, 2012. A.2 Conférences et workshop internationaux avec actes et comité de lecture [2] C. Diop, G. Dugué, C. Chassot, and E. Exposito. Qos-aware multipath-tcp extensions for mobile and multimedia applications. In 10th International Conferences on Advances in Mobile Computing and Multimedia (MoMM 2011), MoMM ’11, pages 139–146, New York, NY, USA, 2011. ACM. [3] C. Diop, G. Dugué, C. Chassot, and E. Exposito. Qos-oriented mptcp extensions for multimedia multi-homed systems. In 2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS 2012), WAINA ’12, pages 1119–1124, Washington, DC, USA, 2012. IEEE Computer Society. [4] G. Dugué, C. Diop, C. Chassot, and E. Exposito. Towards autonomic multipath transport for infotainment-like systems. In 3rd IEEE 125A. Publications de l’auteur International Workshop on Smart Communications in Network Technologies (SaCoNeT 2012), pages 6453–6457, June 2012. [5] C. Diop, J. Gomez-Montalvo, G. Dugué, C. Chassot, and E. Exposito. Towards a semantic and mptcp-based autonomic transport protocol for mobile and multimedia applications. In 3rd International Conference on Multimedia Computing and Systems, May 10-12, 2012 (ICMCS 2012), pages 496–501, May 2012. [6] G. Dugué, M. Oulmahdi, and C. Chassot. Design principles of a service-oriented and component-based autonomic transport layer. In 4th Track on Adaptive and Reconfigurable Service-oriented and component-based Applications and Architectures, June 2014. [7] M. Oulmahdi, G. Dugué, and C. Chassot. Towards a service-oriented and component-based transport layer. In IEEE 5th International Conference on Smart Communications in Network Technologies (SaCoNeT 2014), June 2014. 126Acronymes A-EC Autonomic Error Control. AC Autonomic Computing. API Application Programming Interface. ATL Autonomic Transport Layer. CTP Configurable Transport Protocol. DCCP Datagram Congestion Control Protocol. ETP Enhanced Transport Protocol. MPTCP Multipath TCP. PNSR Peak Signal to Noise Ratio. QoS Qualité de Service (Quality of Service). SACK Selective Acknowledgement. SACK-FR Selective Acknowledgement with Full Reliability. SCTP Stream Control Transmission Protocol. TCP Transmission Control Protocol. Tng Transport Next Generation. UDP User Datagram Protocol. 127Bibliographie [AGM+10] Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye, Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan. Data center tcp (dctcp). SIGCOMM Comput. Commun. Rev., 40(4) :63–74, August 2010. [BP95] L.S. Brakmo and L.L. Peterson. Tcp vegas : end to end congestion avoidance on a global internet. Selected Areas in Communications, IEEE Journal on, 13(8) :1465–1480, 1995. [BWH+07] Patrick G. Bridges, Gary T. Wong, Matti Hiltunen, Richard D. Schlichting, and Matthew J. Barrick. A configurable and extensible transport protocol. IEEE/ACM Trans. Netw., 15(6) :1254–1265, December 2007. [Car02] B. Carpenter. Middleboxes : Taxonomy and Issues. RFC 3234, RFC Editor, February 2002. [CF04] Carlo Caini and Rosario Firrincieli. Tcp hybla : a tcp enhancement for heterogeneous networks. INTERNATIONAL JOURNAL OF SATELLITE COMMUNICATIONS AND NETWORKING, 22, 2004. [Con94] Connolly, T. and Amer, P. and Conrad, P. An Extension to TCP : Partial Order Service. RFC 1693, RFC Editor, November 1994. Obsoleted by RFC 6247. [DABR12] Thomas Dreibholz, Hakim Adhari, Martin Becke, and Erwin Paul Rathgeb. Simulation and Experimental Evaluation of Multipath Congestion Control Strategies. In Proceedings of the 2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS), Fukuoka/Japan, March 2012. ISBN 978-0-7695-4652-0. [DBA13] Thomas Dreibholz, Martin Becke, and Hakim Adhari. SCTP Socket API Extensions for Concurrent Multipath Transfer. Internet Draft Version 06, IETF, Network Working Group, July 2013. draft-dreibholztsvwg-sctpsocket-multipath-06.txt, work in progress. 129Bibliographie [Die08] Dierks, T. and Rescorla, E. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, RFC Editor, August 2008. [Egg11] Eggert, L. Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status. RFC 6247, RFC Editor, May 2011. [ETS13] ETSI. Digital video broadcasting (dvb) ; second generation framing structure, channel coding and modulation systems for broadcasting, interactive services, news gathering and other broadband satellite applications (dvb-s2). Technical report, European Telecommunications Standards Institute, March 2013. [Exp03] Ernesto Exposito. Specification and implementation of a QoS oriented transport protocol for multimedia applications. PhD thesis, Université de Toulouse, Institut National Polytechnique de Toulouse, 2003. [FI08] Bryan Ford and Janardhan Iyengar. Breaking up the transport logjam. In In HOTNETS, 2008. [Flo03] Floyd, S. HighSpeed TCP for Large Congestion Windows. RFC 3649, RFC Editor, December 2003. [Flo06a] Floyd, S. and Kohler, E. Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2 : TCP-like Congestion Control. RFC 4341, RFC Editor, March 2006. [Flo06b] Floyd, S. and Kohler, E. and Padhye, J. Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3 : TCPFriendly Rate Control (TFRC). RFC 4342, RFC Editor, March 2006. [Flo07] Floyd, S. and Kohler, E. TCP Friendly Rate Control (TFRC) : The Small-Packet (SP) Variant. RFC 4828, RFC Editor, April 2007. [Flo08] Floyd, S. and Handley, M. and Padhye, J. and Widmer, J. TCP Friendly Rate Control (TFRC) : Protocol Specification. RFC 5348, RFC Editor, September 2008. [Flo09] Floyd, S. and Kohler, E. Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4 : TCP-Friendly Rate Control for Small Packets (TFRC-SP). RFC 5622, RFC Editor, August 2009. [For11] Ford, A. and Raiciu, C. and Handley, M. and Barre, S. and Iyengar, J. Architectural Guidelines for Multipath TCP Development. RFC 6182, RFC Editor, March 2011. [Fox89] Fox, R. TCP Big Window and Nak Options. RFC 1106, RFC Editor, June 1989. Obsoleted by RFC 6247. 130Bibliographie [GMPG00] T. Goff, J. Moronski, D.S. Phatak, and V. Gupta. Freeze-tcp : a true end-to-end tcp enhancement mechanism for mobile environments. In INFOCOM 2000. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, volume 3, pages 1537–1545 vol.3, 2000. [Hen12] Henderson, T. and Floyd, S. and Gurtov, A. and Nishida, Y. The NewReno Modification to TCP’s Fast Recovery Algorithm. RFC 6582, RFC Editor, April 2012. [HRX08] Sangtae Ha, Injong Rhee, and Lisong Xu. Cubic : a new tcp-friendly high-speed tcp variant. SIGOPS Oper. Syst. Rev., 42(5) :64–74, July 2008. [IEE12a] IEEE. Ieee standard for ethernet. IEEE Std 802.3-2012 (Revision to IEEE Std 802.3-2008), pages 1–0, 2012. [IEE12b] IEEE. Ieee standard for information technology – telecommunications and information exchange between systems local and metropolitan area networks – specific requirements part 11 : Wireless lan medium access control (mac) and physical layer (phy) specifications. IEEE Std 802.11- 2012 (Revision of IEEE Std 802.11-2007), pages 1–2793, 2012. [ITU99a] ITU. G.992.1 : Asymmetric digital subscriber line (adsl) transceivers. Technical report, International Telecommunication Union, July 1999. [ITU99b] ITU. G.992.2 : Splitterless asymmetric digital subscriber line (adsl) transceivers. Technical report, International Telecommunication Union, July 1999. [ITU07] ITU. G.707 : Network node interface for the synchronous digital hierarchy (sdh). Technical report, International Telecommunication Union, January 2007. [ITU11a] ITU. G.1010 : End-user multimedia qos categories. Technical report, International Telecommunication Union, January 2011. [ITU11b] ITU. G.993.2 : Very high speed digital subscriber line transceivers 2 (vdsl2). Technical report, International Telecommunication Union, December 2011. [Jac88] Jacobson, V. and Braden, A. TCP Extensions for Long-Delay Paths. RFC 1072, RFC Editor, October 1988. Obsoleted by RFC 1323, RFC 2018, RFC 6247. [Kho06] Kholer, E. and Handley, M. and Floyd, S. Datagram Congestion Control Protocol (DCCP). RFC 4340, RFC Editor, March 2006. 131Bibliographie [KRW03] Jirka Klaue, Berthold Rathke, and Adam Wolisz. Evalvid - a framework for video transmission and quality evaluation. In In Proc. of the 13th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation, pages 255–272, 2003. [LBL89] M.M. Lara-Barron and G.B. Lockhart. Selective discarding procedure for improved tolerance to missing voice packets. Electronics Letters, 25(19) :1269–1271, Sept 1989. [Mat96] Mathis, M. and Mahdavi, J. and Floyd, S. and Romanow, A. TCP Selective Acknowledgment Options. RFC 2018, RFC Editor, October 1996. [Mil10] Mills, D. and Martin, J. and Burbank, J. and Kasch, W. Network Time Protocol Version 4 : Protocol and Algorithms Specification. RFC 5905, RFC Editor, June 2010. [Nag84] J. Nagel. Congestion Control in IP/TCP Internetworks. RFC 896, RFC Editor, January 1984. [Nis] Yoshifumi Nishida. Ns2 implementation for mtcp. https://code. google.com/p/multipath-tcp/. [Phe12] Phelan, T. and Fairhurst, G. and Perkins, C. DCCP-UDP : A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal. RFC 6773, RFC Editor, November 2012. [Pos80] J. Postel. User Datagram Protocol. RFC 768, RFC Editor, August 1980. [Pos81] J. Postel. Transmission Control Protocol. RFC 793, RFC Editor, September 1981. [Pre02] Presuhn, R. and Case, J. and McCloghrie, K. and Rose, M. and Waldbusser, S. Management Information Base (MIB) for the Simple Network Management Protocol (SNMP). RFC 3418, RFC Editor, December 2002. [Sch13] Scharf, M. and Ford, A. Multipath TCP (MPTCP) Application Interface Considerations. RFC 6897, RFC Editor, March 2013. [STBT08] M. Sridharan, K. Tan, D. Bansal, and D. Thaler. Compound TCP : A New TCP Congestion Control for High-Speed and Long Distance Networks. Internet Draft Version 02, IETF, Network Working Group, November 2008. draft-sridharan-tcpm-ctcp-02.txt, expired. 132Bibliographie [Ste04] Stewart, R. and Ramalho, M. and Xie, Q. and Tuexen, M. and Conrad, P. Stream Control Transmission Protocol (SCTP) Partial Reliability Extension. RFC 3758, RFC Editor, May 2004. [Ste07] Stewart, R. and Ed. Stream Control Transmission Protocol. RFC 4960, RFC Editor, September 2007. [VW09] Nicolas Van Wambeke. Une approche pour la composition autonome de services de communication orientés QoS. PhD thesis, Université de Toulouse, 2009. [WJLH06] D.X. Wei, Cheng Jin, S.H. Low, and S. Hegde. Fast tcp : Motivation, architecture, algorithms, performance. Networking, IEEE/ACM Transactions on, 14(6) :1246–1259, 2006. [XHR04] Lisong Xu, K. Harfoush, and Injong Rhee. Binary increase congestion control (bic) for fast long-distance networks. In INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, volume 4, pages 2514–2524 vol.4, 2004. 133 Gestion de la variabilit´e et automatisation des processus de d´eveloppement logiciel Emmanuelle Rouill´e To cite this version: Emmanuelle Rouill´e. Gestion de la variabilit´e et automatisation des processus de d´eveloppement logiciel. Software Engineering. Universit´e Rennes 1, 2014. French. . HAL Id: tel-01061129 https://tel.archives-ouvertes.fr/tel-01061129 Submitted on 5 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.ANNÉE 2014 THÈSE / UNIVERSITÉ DE RENNES 1 sous le sceau de l’Université Européenne de Bretagne pour le grade de DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention : Informatique École doctorale Matisse présentée par Emmanuelle ROUILLÉ préparée à l’unité de recherche IRISA – UMR6074 Institut de Recherche en Informatique et Systèmes Aléatoires Gestion de la variabilité et automatisation des processus de développement logiciel Thèse soutenue à Rennes le 16 avril 2014 devant le jury composé de : Marie-Pierre GERVAIS Professeur à l’Université de Paris Ouest Nanterre La Défense / Présidente Pierre-Alain MULLER Professeur à l’Université de Haute-Alsace / Rapporteur Bernard COULETTE Professeur à l’Université de Toulouse II - Le Mirail / Rapporteur Reda BENDRAOU Maître de Conférence à l’Université Pierre et Marie Curie / Examinateur Benoit COMBEMALE Maître de Conférence à l’Université de Rennes 1 / Examinateur Olivier BARAIS Maître de Conférence à l’Université de Rennes 1 / Examinateur David TOUZET Architecte logiciel chez Sodifrance / Examinateur Jean-Marc JÉZÉQUEL Professeur à l’Université de Rennes 1 / Directeur de thèseRemerciements Je remercie le Professeur Bernard Coulette et le Professeur Pierre-Alain Muller d’avoir rapporté ce manuscrit, ainsi que pour leurs retours ayant permis de l’améliorer. Je les remercie également d’avoir fait partie de mon jury de thèse. Je remercie le Professeur Marie-Pierre Gervais d’avoir accepté de présider à ma soutenance, et je remercie le Docteur Reda Bendraou d’avoir examiné mes travaux. Merci à Jean-Marc Jézéquel d’avoir dirigé et également permis cette thèse. Un grand merci à Benoît Combemale, Olivier Barais, David Touzet, et à travers ce dernier Sodifrance, pour m’avoir encadrée, pour leur disponibilité, leur investissement et les nombreux conseils qu’ils m’ont prodigués. Merci à tous les collègues de DiverSE et de Sodifrance pour les discussions intéressantes et tous les bons moments partagés ensemble. Enfin, merci à ma famille, Clément, mes parents, pour leur présence et leur soutien.Résumé De nombreux outils ont été proposés par la communauté du génie logiciel afin de faire face à la complexité des logiciels et des projets de développement logiciel. À titre d’illustration, les systèmes de contrôle de version permettent de gérer les difficultés liées au travail collaboratif et géographiquement distribué, les outils de compilation, de test ou d’intégration continue supportent les méthodes de développement agiles, les IDE (Integrated Development Environments) permettent d’intégrer les différentes technologies utilisées sur un projet, etc. Ces outils sont d’autant plus nombreux qu’il en existent des version différentes, afin de satisfaire les besoins spécifiques à chaque projet. Par exemple des IDE différents peuvent être utilisés en fonction du langage de programmation utilisé. L’utilisation de tous ces outils est cependant à l’origine de nombreuses tâches manuelles répétitives, sources d’erreurs et coûteuses en temps. L’automatisation de ces tâches est un moyen de gagner en productivité. Mais la difficulté est de réutiliser des automatisations de tâches manuelles répétitives. En effet, toutes les automatisations ne sont pas forcément utiles pour tous les projets et elles peuvent avoir des dépendances avec d’autres tâches réalisées pendant un projet. De plus, une automatisation peut être utilisée dans des cas différents, c’est-à-dire dans des projets différents ou à des moments différents d’un même projet. Les défis sont donc de déterminer les projets et les moments d’un projet pour lesquels une automatisation doit être réutilisée, ainsi que de créer des automatisations réutilisables à travers leurs différents cas d’utilisation. Afin de répondre à ces défis, la contribution principale de cette thèse est une approche pilotant la réutilisation des automatisations de tâches manuelles répétitives par les processus de développement logiciel, où un processus de développement logiciel décrit les étapes à réaliser pour mener à bien un projet de développement logiciel. Cette approche consiste à capitaliser sur un ensemble de processus et à réutiliser des processus de cet ensemble en fonction des exigences des projets. Elle s’appuie sur une première sous-contribution, à savoir une approche permettant de réutiliser les processus indépendamment du formalisme utilisé pour les définir. L’approche principale consiste également à lier des automatisations de tâches manuelles répétitives aux étapes d’un ensemble de processus qu’elles automatisent. Ce lien permet de savoir quelles automatisations utiliser pour un projet donné et quand. L’approche principale s’appuie également sur une deuxième sous-contribution, à savoir une méthodologie fournissant un support à la création d’automatisations réutilisables à travers leurs différents cas d’utilisation. Dans cette méthodologie, le lien entre les processus et les automatisations est utilisé afin d’expliciter les différents cas d’utilisation de ces dernières et de créer des automatisations réutilisables. Afin de démontrer la faisabilité de l’approche proposée dans cette thèse, nous proposons un outillage la supportant. Cet outillage a été appliqué a deux cas d’utilisation : une famille de processus industriels de développement Java ainsi qu’une famille de processus consistant à définir et outiller un langage de modélisation.Table des matières 1 Introduction 5 1.1 La prolifération des outils de développement logiciel . . . . . . . . . . . 5 1.2 Le défi : réutiliser des automatisations de tâches manuelles récurrentes . 6 1.3 Contributions de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Contexte de réalisation de la thèse . . . . . . . . . . . . . . . . . . . . . . 8 1.5 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 I Contexte scientifique 11 2 Background 15 2.1 L’ingénierie dirigée par les modèles (IDM) . . . . . . . . . . . . . . . . . 15 2.2 Les processus de développement logiciel . . . . . . . . . . . . . . . . . . 17 2.2.1 Introduction aux processus de développement logiciel . . . . . . 17 2.2.2 Modélisation des processus de développement logiciel avec SPEM 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3 L’ingénierie des lignes de produits logiciels . . . . . . . . . . . . . . . . . 23 2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.2 CVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3 État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus 35 3.1 Support à la réutilisation des processus sans spécification de leur variabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.1.1 Identification du processus correspondant à un projet . . . . . . . 38 3.1.2 Réutilisation de processus définis en extension . . . . . . . . . . . 40 3.1.3 Les patrons de processus . . . . . . . . . . . . . . . . . . . . . . . 40 3.2 Ingénierie des lignes de processus . . . . . . . . . . . . . . . . . . . . . . 42 3.2.1 Utilisation des mécanismes d’un langage . . . . . . . . . . . . . . 43 3.2.2 Extension d’un langage de modélisation de processus . . . . . . . 44 3.2.2.1 Utilisation de processus agrégats . . . . . . . . . . . . . 44 3.2.2.2 Modification d’un processus de base . . . . . . . . . . . 46 12 TABLE DES MATIÈRES 3.2.2.3 Spécification des points de variation et des variantes d’un processus . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.2.4 Configuration de processus par composition . . . . . . . 49 3.2.2.5 Association de plusieurs techniques . . . . . . . . . . . . 50 3.2.3 Transformation en une structure pivot . . . . . . . . . . . . . . . . 50 3.2.4 Spécification de la variabilité sans réutilisation automatique . . . 51 3.2.5 Synthèse sur l’ingénierie des lignes de processus . . . . . . . . . . 52 3.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 II Automatisation des tâches manuelles récurrentes pilotée par les processus de développement logiciel 63 4 Gestion de la variabilité dans les processus 67 4.1 Exemple illustratif : une famille de processus de métamodélisation . . . 67 4.2 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2.1 Définition de la ligne de processus de développement logiciel . . 72 4.2.1.1 Méthodologie pour la modélisation des éléments de processus (étape 1) . . . . . . . . . . . . . . . . . . . . . . 72 4.2.1.2 Spécification de la variabilité des exigences des projets (étape 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.1.3 Liaison entre les exigences des projets et les processus (étape 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.2 Dérivation d’un processus en fonction des exigences d’un projet 78 4.2.2.1 Résolution de la variabilité des exigences des projets (étape 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.2.2.2 Dérivation automatique de processus (étape 5) . . . . . 78 4.2.3 Exécution d’un processus résolu . . . . . . . . . . . . . . . . . . . 79 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.3.1 Capacité de CVL à gérer la variabilité des processus en fonction de la variabilité des exigences des projets . . . . . . . . . . . . . . 80 4.3.2 Indépendance de CVL vis-à-vis des métamodèles de processus . 80 4.3.3 Validité du modèle de processus résolu . . . . . . . . . . . . . . . 80 4.3.4 Extension possible à la méthodologie pour modéliser le processus de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5 Création de composants d’automatisation réutilisables 85 5.1 Exemple illustratif : automatisation de la configuration de l’espace de travail local d’un développeur . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2 La méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.1 Définition d’une ligne de processus de développement logiciel (étape 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.1.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 90TABLE DES MATIÈRES 3 5.2.1.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.2 Spécification des composants d’automatisation (étape 2) . . . . . 91 5.2.2.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.2.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.3 Liaison entre les CA et leurs contextes d’utilisation (étape 3) . . . 92 5.2.3.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.3.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.4 Conception des composants d’automatisation (étape 4) . . . . . . 93 5.2.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.4.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.2.5 Implémentation des composants d’automatisation (étape 5) . . . 95 5.2.5.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 95 5.2.5.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.1 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.3.2 Une limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.3 Un inconvénient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 III Outillage et application 101 6 Outil pour la gestion de la variabilité et l’automatisation des processus 105 6.1 Exemples de tâches manuelles récurrentes . . . . . . . . . . . . . . . . . . 105 6.2 Vue générale de l’outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.2.1 Définition d’une ligne de processus . . . . . . . . . . . . . . . . . 109 6.2.2 Définition des CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.2.3 Dérivation d’un processus en fonction des exigences d’un projet 111 6.2.4 Automatisation de l’exécution des processus . . . . . . . . . . . . 112 6.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.3.1 Les modeleurs de VAM et de VRM . . . . . . . . . . . . . . . . . . 113 6.3.2 Les modeleurs de CA abstraits et de liaisons . . . . . . . . . . . . 115 6.3.3 Le framework support à l’implémentation des CA . . . . . . . . . . 117 6.3.3.1 Liaison entre un CA et le plug-in Eclipse l’implémentant 118 6.3.3.2 Exécution générique des plug-in Eclipse implémentant les CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.3.3.3 Gestion de l’accès aux informations contextuelles . . . . 119 6.3.4 L’assistant à la résolution de la variabilité . . . . . . . . . . . . . . 122 6.3.5 Le moteur de dérivation CVL . . . . . . . . . . . . . . . . . . . . . 124 6.3.6 L’interpréteur de processus . . . . . . . . . . . . . . . . . . . . . . 126 6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.4.1 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.4.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.5 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304 TABLE DES MATIÈRES 7 Applications de l’approche 133 7.1 Application sur une famille de processus de métamodélisation . . . . . . 133 7.2 Application sur une famille de processus de développement web Java . 139 7.3 Synthèse et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 8 Conclusion et perspectives 149 8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 8.2.1 Perspectives industrielles . . . . . . . . . . . . . . . . . . . . . . . 151 8.2.1.1 Utilisation de T4VASP quel que soit le cas d’application 151 8.2.1.2 Limitation des erreurs . . . . . . . . . . . . . . . . . . . . 151 8.2.1.3 Suppression des redondances dans le modèle de CA abstraits et de liaisons . . . . . . . . . . . . . . . . . . . . 152 8.2.2 Perspectives de recherche à court terme . . . . . . . . . . . . . . . 153 8.2.3 Perspectives de recherche à long terme . . . . . . . . . . . . . . . 153 8.2.3.1 Gestion de la variabilité des processus au moment de leur l’exécution . . . . . . . . . . . . . . . . . . . . . . . . 153 8.2.3.2 Amélioration de la réutilisation des CA . . . . . . . . . . 154 Appendices 155 A Extrait des modèles et CA de la famille de processus de métamodélisation 157 B Extrait des modèles et CA de la famille de processus de développement web Java 163 Bibliographie 169 Liste des figures 179 Liste des tables 183 Liste des publications 185Chapitre 1 Introduction 1.1 La prolifération des outils de développement logiciel La variabilité et l’évolution des exigences d’un projet de développement logiciel sont connues comme une des sources principales de complexité de l’activité de création logiciel [TI93, JMD04, Mar03]. En outre, les projets de développement logiciel sont de plus en plus réalisés de manière collaborative [HMR06], dans un contexte géographiquement distribué [CBHB07], et dans un contexte de globalisation faisant collaborer un ensemble d’entreprises au sein d’un même projet. Ces caractéristiques apportent une complexité accidentelle supplémentaire à la problématique du développement logiciel. Un des objectifs du génie logiciel est de conserver l’intelligibilité du processus de construction et de maintenance de ces applications. Dans ce cadre, de nombreux outils sont apparus afin de gérer, voire automatiser, une partie de cette complexité. Cependant, de part le nombre d’acteurs intervenant dans la construction d’un logiciel et leurs multiples préoccupations, il existe maintenant un écosystème riche et lui-même complexe lié à la problématique de développement logiciel. Parmi ces outils, sans être exhaustifs, nous pouvons citer : – des systèmes de contrôle de version (SVN, Git...) qui permettent de gérer les difficultés liées au travail collaboratif et géographiquement distribué, – des outils de compilation (Maven, Ant, PDE...) qui permettent de gérer les problé- matiques d’intégration de composants ou de librairies réutilisables au moment de la construction d’un logiciel complexe, – des outils d’analyse statique comme PMD, Findbugs ou Sonar qui aident à amé- liorer la qualité du logiciel, – des outils de support à l’exécution des différents types de test logiciel (JUnit, Selenium, Quality Center...), – des environnements de développement intégrés (IDE, Integrated Development Environment) permettant d’intégrer les différentes technologies utilisées sur un projet (langages, outils, frameworks, librairies...), – des outils d’intégration continue permettant d’automatiser une partie de l’orchestration de la problématique de production logicielle. 56 Introduction La forte variabilité des exigences entre différents projets logiciels motive l’existence d’outils différents prenant en compte des préoccupations similaires, mais chacun avec des spécificités permettant de répondre au mieux aux exigences des différents projets. Ceci permet de comprendre le nombre d’outils existants et l’utopie de viser l’émergence d’un unique outil. Ainsi, certaines équipes de développement font le choix de l’IDE Visual Studio pour développer des applications Windows afin de profiter de toutes les facilités proposées par Microsoft pour ce faire, alors que si l’application à développer a des contraintes d’indépendance vis-à-vis du système d’exploitation sur lequel elle sera déployée, une équipe de développement pourra préférer l’IDE Eclipse pour faire du développement en Java. L’utilisation de tous ces outils est généralement bénéfique au bon fonctionnement d’un projet mais elle engendre aussi un ensemble de tâches d’ingénierie logicielle qui sont réalisées manuellement par les équipes de développement. Utiliser ces différents outils peut impliquer de devoir s’en procurer une version, de devoir les installer, les configurer, ou encore les mettre à jour. Par exemple, un développeur utilisant un IDE peut être amené à installer les librairies et les plug-ins nécessaires pour un projet, ainsi qu’à configurer ces derniers. Ces tâches sont de plus récurrentes dans le sens où elles peuvent avoir lieu plusieurs fois pendant un même projet mais aussi qu’elles se répètent d’un projet à l’autre, toujours dans un contexte différent. Par exemple, dans un projet, chaque développeur doit installer un IDE conforme aux exigences de ce projet. Nous appelons dans cette thèse ces tâches répétitives et réalisées manuellement des Tâches Manuelles Récurrentes (TMR). Ces TMR, bien qu’étant toujours similaires, doivent prendre en compte le contexte particulier dans lequel elles sont réalisées. Elles se révèlent être coûteuses en temps et sources d’erreurs pour les équipes de développement [RCB+11]. 1.2 Le défi : réutiliser des automatisations de tâches manuelles récurrentes L’automatisation des TMR liées à l’utilisation des outils de développement logiciel doit permettre de gagner en productivité. Cela doit aussi permettre d’éviter les erreurs humaines inhérentes à toute activité répétitive. Cependant, l’intérêt de la mise en place d’une telle automatisation est limité si les automatisations de TMR ne sont pas réutilisées, au sein d’un même projet mais également d’un projet à l’autre. Or, la réutilisation d’automatisations de TMR est un exercice difficile pour les trois raisons suivantes : 1. Bien qu’une automatisation de TMR puisse être utile pour différents projets, toutes les automatisations de TMR ne sont pas forcément utiles pour chaque projet. La difficulté est donc de déterminer quelles automatisations de TMR réutiliser pour un projet donné. 2. Une automatisation de TMR pouvant avoir des dépendances avec d’autres tâches d’un projet, une difficulté supplémentaire est de déterminer à quels moments d’un projet utiliser une automatisation de TMR.Contributions de la thèse 7 3. La problématique du niveau de généralisation est aussi un problème complexe. Comment déterminer qu’une automatisation de TMR utile pour des projets différents, ou à des moments différents d’un même projet, soit bien réutilisable à travers ces différents cas d’utilisation ? 1.3 Contributions de la thèse Afin de répondre aux défis précédemment énoncés, la contribution de cette thèse est de piloter l’automatisation des TMR liées à l’utilisation des outils de développement logiciel par les processus de développement logiciel. Un processus de développement logiciel correspond à l’ensemble des activités d’ingénierie logicielle requises pour transformer les exigences d’un utilisateur en logiciel [Hum88]. La mise en œuvre de cette contribution s’appuie sur la définition d’une famille de processus de développement logiciel et sur la réutilisation des processus de cette famille en fonction des exigences des projets. Des formalismes différents pouvant être utilisés pour définir les processus de développement logiciel en fonction des exigences des utilisateurs [Zam01], nous proposons une approche (première sous-contribution) permettant de réutiliser les processus indépendamment du langage utilisé pour les définir. Cette approche repose sur l’ingénierie des lignes de produits [PBL05] (où ici les produits sont des processus de développement logiciel) afin de gérer la variabilité dans les processus. La mise en œuvre de la contribution consiste également à lier des automatisations de TMR aux unités de travail d’une famille de processus qu’elles automatisent. Une même automatisation de TMR peut être liée à des unités de travail différentes, appartenant ou non à un même processus. Nous proposons donc une méthodologie (deuxième sous-contribution) fournissant un support à la création d’automatisations de TMR qui soient réutilisables pour toutes les unités de travail auxquelles elles sont liées. L’idée consiste à utiliser le lien entre les automatisations de TMR et la famille de processus pour identifier ces différentes unités de travail. Cette information est ensuite utilisée afin d’implémenter des automatisations réutilisables pour toutes ces unités de travail. Lors de la réalisation d’un processus d’une famille, le lien entre les processus et les automatisations de TMR est utilisé afin de savoir quelles automatisations exécuter pour un projet donné et quand. Pour réaliser cette contribution, nous nous appuyons sur l’IDM (Ingénierie Dirigée par les Modèles) [JCV12] qui offre les outils et méthodes nécessaires pour obtenir une représentation holistique et abstraite des différentes préoccupations (exigences, variabilité et processus) et raisonner de manière uniforme au travers de celles-ci. Afin de valider notre contribution, nous avons développé un outillage supportant sa mise en œuvre. La validation de la contribution a été démontrée sur une famille de processus industriels de développement web Java issue de la société Sodifrance, ainsi que sur une famille de processus consistant à définir et outiller un langage de modélisation.8 Introduction 1.4 Contexte de réalisation de la thèse Cette thèse s’est déroulée dans le cadre d’un contrat Cifre avec la société Sodifrance. Cela nous a permis d’appréhender concrètement la difficulté majeure à laquelle sont confrontées les ESN (Entreprises de Services du Numérique) du secteur du tertiaire. En effet, afin de faire face à la concurrence, ces sociétés sont dans une situation paradoxale où elles doivent réduire leur coûts et temps de développement, tout en garantissant la qualité des produits livrés au client. C’est d’ailleurs cette difficulté qui justifie ces travaux de thèse. Ceux-ci s’inscrivent en effet dans une démarche d’augmentation de la productivité des équipes de développement de Sodifrance. Bénéficier d’une collaboration industrielle a également fait ressortir les exigences principales auxquelles des travaux de recherche doivent répondre pour être utilisés dans l’industrie : être pertinents, outillés et validés. Des travaux de recherche n’ont en effet d’intérêt pour une entreprise que s’ils apportent une solution à des problèmes rencontrés par cette entreprise. Le coût de production élevé de l’outillage support à des travaux de recherche peut de plus empêcher l’adoption d’une approche. D’autre part, les contraintes fi- nancières auxquelles sont souvent confrontées les entreprises peuvent être un frein à l’adoption d’une approche qui n’a pas fait ses preuves. Ce sont ces exigences qui ont permis d’orienter la réalisation de ces travaux de thèse et de déterminer les améliorations à leur apporter. Enfin, la collaboration avec Sodifrance nous a permis d’avoir accès à des cas concrets de projets de développement, à partir desquels nous avons pu concevoir, réaliser et appliquer les contributions de cette thèse. 1.5 Plan de la thèse Cette thèse s’organise en trois parties principales, qui sont le contexte scientifique (partie I), les contributions (partie II) et la validation des travaux de thèse (partie III). Le contexte scientifique (partie I) s’organise en deux chapitres. Le chapitre 2 introduit l’environnement scientifique sur lequel s’appuient ces travaux de thèse. Plus précisément, il introduit l’IDM, les processus de développement logiciel, ainsi que l’ingénierie des lignes de produits logiciels. Il introduit également SPEM et CVL, deux langages de l’OMG permettant respectivement de définir des processus de développement logiciel et de mettre en œuvre l’ingénierie des lignes de produits. Le chapitre 3, traite de l’état de l’art sur la réutilisation d’automatisations de TMR. Cet état de l’art porte plus particulièrement sur les approches permettant de savoir quand réutiliser des automatisations de TMR et permettant de développer des composants logiciels réutilisables. La contribution de la thèse, le pilotage de l’automatisation des TMR par les processus de développement logiciel, est présentée dans la partie II. Les sous-contributions de la thèse sont détaillées dans deux chapitres. Le chapitre 4 présente la première sous-contribution, à savoir notre approche permettant de réutiliser les processus de développement logiciel en fonction des exigences des projets et indépendamment du langage utilisé pour définir ces processus. Le chapitre 5 détaille la deuxième sous-Plan de la thèse 9 contribution, une méthodologie fournissant un support à la création d’automatisations de TMR réutilisables dans tous leurs cas d’utilisation. La validation des travaux de thèse (partie III) comprend deux chapitres. Dans le chapitre 6, nous présentons l’outillage support aux contributions de cette thèse. Dans le chapitre 7, nous appliquons cet outillage à une famille de processus consistant à définir et outiller un langage de modélisation ainsi qu’à une famille de processus de développement web Java issue de Sodifrance. Enfin, nous concluons et présentons nos perspectives de travail dans le chapitre 8.10 IntroductionPremière partie Contexte scientifique 1113 Dans cette partie, nous commençons par présenter dans le chapitre 2 les diffé- rents champs de recherche sur lesquels nous nous appuyons dans cette thèse. Nous présentons ensuite dans le chapitre 3 l’état de l’art de cette thèse.14Chapitre 2 Background Nous présentons dans ce chapitre les différents champs de recherche sur lesquels nous nous appuyons dans cette thèse. Nous commençons par présenter, dans la section 2.1, l’IDM (Ingénierie Dirigée par les Modèles), que nous utilisons pour mettre en œuvre les contributions de cette thèse. Nous présentons ensuite, dans la section 2.2, les processus de développement logiciel, ainsi que l’ingénierie des lignes de produits logiciels dans la section 2.3. En plus d’introduire, dans les sections 2.2 et 2.3, les concepts relatifs aux processus de développement logiciel et à l’ingénierie des lignes de produits, nous montrons comment l’IDM s’applique à ces domaines. Enfin, nous faisons une synthèse de ce chapitre dans la section 2.4. 2.1 L’ingénierie dirigée par les modèles (IDM) La séparation des préoccupations [Dij82] est un moyen de gérer la complexité des logiciels. En effet, il est plus simple et efficace pour l’esprit humain de résoudre un problème complexe en le décomposant en sous-problèmes de complexité moindre plutôt que de considérer le problème complexe dans son ensemble. L’IDM [JCV12] est un moyen de mettre en œuvre la séparation des préoccupations, en s’appuyant sur le principe de l’abstraction. En effet, le principe général de l’IDM est d’utiliser une représentation simplifiée d’un aspect du monde réel (c’est-à-dire un modèle) dans un objectif donné, en s’abstrayant des détails qui n’ont pas de rapport avec cet aspect. Dans le domaine de l’ingénierie logicielle, chaque aspect d’un système logiciel peut donc être représenté par un modèle. Ce modèle est lui-même exprimé avec un langage de modélisation généraliste tel qu’UML [OMG11b, OMG11c] ou avec un langage de modélisation dédié à un domaine métier particulier. L’intérêt de ces langages est qu’ils soient plus simples à appréhender pour des humains que les langages de programmation classiques (Java, C#, ...) ou que le langage machine. Un modèle peut alors être vu comme un support plus adapté pour des humains pour exprimer un aspect particulier d’un logiciel ainsi que pour réfléchir et communiquer sur cet aspect. Une problématique clé de l’IDM est également de rendre les modèles opération- 1516 Background nels. Cependant, à cette fin, ceux-ci doivent être interprétables par des machines. Le langage dans lequel ils sont exprimés doit donc être clairement défini. Comme tout langage informatique, un langage de modélisation est caractérisé par sa syntaxe abstraite, sa syntaxe concrète et sa sémantique [JCV12]. La syntaxe abstraite est la syntaxe manipulée par l’ordinateur. Dans le contexte des langages de modélisation, elle sert généralement de base à la définition de la syntaxe concrète et de la sémantique. La syntaxe concrète est la syntaxe manipulée par l’utilisateur du langage à l’aide d’un éditeur. Elle comprend des éléments syntaxiques dont le but est de faciliter l’utilisation d’un langage pour des humains. Elle associe des représentations pour chacun des élé- ments de la syntaxe abstraite. Il est tout à fait possible de définir des syntaxes concrètes différentes pour une même syntaxe abstraite, en fonction des besoins. La sémantique d’un langage de modélisation est définie en associant un sens à chacun des éléments de la syntaxe abstraite. Il est également possible de définir des sémantiques différentes pour une même syntaxe abstraite, en fonction des besoins (ex : vérification, simulation, compilation, etc.). Dans le domaine de l’IDM, la syntaxe abstraite peut prendre la forme d’un modèle, appelé métamodèle. On dit d’un modèle m qu’il est conforme à un métamodèle mm si chaque élément de m est une instance d’un élément de mm [Guy13]. Cependant, face à la prolifération des métamodèles, le besoin est apparu de les unifier avec un langage de description commun, afin de les rendre compatibles entre eux et de pouvoir définir des outils capables de les manipuler de manière générique. L’OMG a donc proposé un langage de description des métamodèles, qui prend lui aussi la forme d’un modèle : le métamétamodèle MOF (Meta-Object Facility) [OMG06]. La particularité du métamétamodèle est qu’il se définit lui-même, limitant ainsi le nombre de niveaux de modélisation. Quand le métamétamodèle MOF ne permet pas d’exprimer toutes les propriétés d’un métamodèle, il est possible d’utiliser un langage de contrainte, tel qu’OCL (Object Constraint Language) [OMG10], afin d’exprimer ces propriétés. Dans la pratique, l’utilisation de modèles de manière opérationnelle peut prendre plusieurs formes. Nous ne présentons ici que celles qui sont pertinentes pour la compréhension de cette thèse. Ainsi, les modèles peuvent être utilisés directement comme le système logiciel final à produire, en les exécutant tout comme il est possible d’exé- cuter n’importe quel programme informatique. Deux méthodes existent pour exécuter des modèles : l’interprétation et la compilation. L’interprétation consiste à analyser chaque élément d’un modèle et à l’exécuter en fonction de sa sémantique. La compilation consiste à transformer un modèle conforme à un langage en un modèle ou du texte conforme à un autre langage, et ensuite à exécuter le modèle ou le texte obtenu après transformation. Il existe à ce jour de nombreux outils support à l’IDM. Dans cette thèse, nous utilisons EMF (Eclipse Modeling Framework) [SBPM09], un framework de l’environnement de développement Eclipse 1 , afin de définir des métamodèles, de générer des éditeurs arborescents permettant de créer des modèles conformes à ces métamodèles, ainsi que de manipuler ces modèles et métamodèles en Java. EMF s’appuie sur le langage de 1. http://www.eclipse.orgLes processus de développement logiciel 17 métamodélisation Ecore [BSE03], qui est similaire au MOF. Nous faisons également référence dans cette thèse à l’utilisation d’UML afin de définir des langages de modé- lisation dédiés à un domaine métier particulier. Le mécanisme de profil UML permet en effet d’étendre UML de façon générique. Plus précisément, il permet d’ajouter de nouveaux concepts propre à un domaine métier particulier, de définir leurs propriétés, de spécifier des contraintes sur ces concepts et également de leur associer une repré- sentation graphique. Un profil est définit principalement à l’aide de stéréotypes, où un stéréotype définit un nouveau concept, mais toujours sous la forme d’une extension d’un élément UML. Un stéréotype peut avoir des propriétés ainsi qu’une représentation graphique. Des contraintes (telles que des contraintes OCL) peuvent également être définies sur ce stéréotype. 2.2 Les processus de développement logiciel 2.2.1 Introduction aux processus de développement logiciel Un processus de développement logiciel correspond à l’ensemble des activités d’ingénierie logicielle requises pour transformer les exigences d’un utilisateur en logiciel [Hum88]. La maîtrise de ces processus est un enjeu crucial pour les entreprises qui développent des logiciels. Pour preuve, le CMM (Capability Maturity Model) [Ins95] est une méthodologie qui se base sur l’amélioration des processus de développement logiciel afin d’améliorer la qualité des logiciels produits, tout en réduisant les coûts et les temps de production [HZG+97, Dio93]. La maîtrise des processus de développement logiciel passe, entre autres, par l’utilisation de formalisations de processus afin de supporter leur exécution [Ost87, Ins95]. L’exécution d’un processus de développement logiciel consiste en la réalisation des différentes unités de travail définies par ce processus, dans l’ordre dans lequel elles sont définies [Ben07]. Des méthodes 2 de développement logiciel, telles que les méthodes de développement en cascade [Roy87] ou en spirale [Boe88], ont dans un premier temps été proposées afin de définir les processus de développement logiciel. Ces méthodes donnent une vue générale des activités à accomplir pour mener à bien un projet de développement logiciel. Mais leur principale limitation est qu’elles ne fournissent pas assez de détails pour guider la réalisation concrète de ces activités [CKO92]. La notion de modèle de processus est alors apparue afin de faire face à cette limitation, où un modèle de processus capture de manière plus détaillée les informations nécessaires pour guider la réalisation d’un projet. Ces modèles de processus sont exprimés selon un langage de modélisation de processus de développement logiciel. Il existe à ce jour plusieurs langages de modélisation de processus de développement logiciel, comme SPEM [OMG08], xSPEM [BCCG07], Little-JIL [Wis06], UML4SPM [BGB06], ou encore SEMDM [ISO07]. Nous présentons plus en détails un de ces langages, SPEM, en section 2.2.2. 2. Une méthode définit comment mettre en œuvre des unités de travail et des artéfacts qui servent à la définition de processus de développement logiciel [HIMT96].18 Background Figure 2.1 – Modèle conceptuel de SPEM Un modèle de processus peut ensuite servir à guider l’exécution d’un processus. En effet, le modèle de processus peut être utilisé comme support de communication entre les différents membres d’une équipe [Ost87, Ins95]. Un modèle de processus peut aussi être utilisé comme un programme qu’il est possible d’exécuter [Ost87], afin d’automatiser les étapes de l’exécution du processus qui peuvent l’être [RGC04]. Des outils supportant l’exécution de langages de modélisation de processus ont ainsi vu le jour, comme Wilos 3 pour SPEM, Juliette [CLM+99, CLS+00] pour Little-JIL, ainsi qu’un compilateur et un interpréteur [Ben07] pour UML4SPM. 2.2.2 Modélisation des processus de développement logiciel avec SPEM 2.0 SPEM 2.0 (Software & Systems Process Engineering Metamodel) [OMG08] est le standard de l’OMG dédié à la modélisation des processus logiciels et systèmes. Il vise à offrir un cadre conceptuel pour modéliser, échanger, documenter, gérer et présenter les processus et méthodes. Les concepts de SPEM 2.0 sont décrits par un métamodèle qui repose sur l’idée qu’un processus de développement est une collaboration entre des entités actives et abstraites, les rôles, qui représentent un ensemble de compétences et qui effectuent des opérations, les activités, sur des entités concrètes et réelles, les produits. Les différents rôles agissent les uns par rapport aux autres ou collaborent en échangeant des produits et en déclenchant l’exécution de certaines activités. Ce modèle conceptuel est synthétisé sur la figure 2.1. La particularité de SPEM 2.0 est qu’il sépare les aspects contenus et données relatifs aux méthodologies de développement, de leurs possibles instanciations dans un projet particulier. Ainsi, pour pleinement exploiter ce framework, la première étape devrait être de définir toutes les phases, activités, produits, rôles, guides, outils, etc., qui peuvent composer une méthode pour ensuite, dans une deuxième étape, choisir en fonction du contexte et du projet, le contenu de la méthode appropriée pour l’utiliser dans la définition du processus. SPEM 2.0 est défini sous la forme d’un métamodèle MOF [OMG06] qui s’appuie sur les spécifications UML 2.0 Infrastructure [OMG11b] et UML 2.0 Diagram Defini- 3. www.wilos.ups-tlse.frLes processus de développement logiciel 19 Figure 2.2 – Structure du métamodèle de SPEM 2.0 [OMG08] tion [OMG12]. De UML 2.0 Infrastructure, il réutilise les concepts de base tels que Classifier ou Package. Aucun concept de UML 2.0 Superstructure [OMG11c] n’est réutilisé. Le standard est défini également sous la forme d’un profil UML où chaque élément du métamodèle de SPEM 2.0 est défini comme un stéréotype de UML 2.0 Superstructure. Le métamodèle de SPEM 2.0 est composé de sept paquetages liés avec le mécanisme «merge» [OMG11b], chaque paquetage traitant d’un aspect particulier (cf. figure 2.2). Le paquetage Core introduit les classes et les abstractions qui définissent les fondations pour tous les autres paquetages. La structure de décomposition de ce paquetage est la classe WorkDefinition, qui généralise toutes les activités de travail de SPEM 2.0. Le paquetage ProcessStructure définit les éléments permettant de représenter les modèles de processus. Cependant, la possibilité de documenter textuellement ces élé- ments (c.-à-d. ajouter les propriétés décrivant chaque élément) n’est pas fournie dans ce paquetage mais dans ManagedContent, qui définit les concepts pour gérer les descriptions textuelles des éléments de processus. Des exemples de ces concepts sont les classes ContentDescription et Guidance. Le paquetage MethodContent définit les concepts de base pour spécifier le contenu de méthodes basiques. Le paquetage ProcessWithMethod regroupe l’ensemble des éléments requis pour intégrer les processus définis avec les concepts du paquetage ProcessStructure, selon les contenus définis avec les concepts du paquetage MethodContent. Le paquetage MethodPlugin offre les mécanismes pour gérer et réutiliser des bibliothèques de contenus de méthode et processus. Ceci est assuré grâce aux concepts MethodLibrary et MethodPlugin. Une instance de MethodLibrary est un conteneur pour tout élément SPEM 2.0. C’est donc l’élément racine d’un modèle SPEM 2.0. Une instance de MethodPlugin est plus particulièrement un conteneur pour des contenus de méthodes et des processus. Enfin, le paquetage ProcessBehavior offre le moyen de lier un élément de procédé SPEM 2.0 avec un comportement externe comme des diagrammes d’activités UML 2.0 ou des modèles BPMN (Business Process Modeling Notation) [OMG11a].20 Background Figure 2.3 – Extraits de certains paquetages du métamodèle de SPEM 2.0 La figure 2.3 détaille le contenu des paquetages Core, MethodContent, ProcessStructure et ProcessWithMethod qui est utile pour la compréhension de la suite de cette thèse. Le paquetage MethodContent contient des éléments de contenu de méthode (MethodContentElement), tels que des définitions de rôles (RoleDefinition), qui réalisent des définitions de tâches (TaskDefinition) en utilisant des définitions d’outils (ToolDefinition). Une définition de tâche a des définitions de produits de travail (WorkProductDefinition) en tant qu’entrées et sorties. Le paquetage ProcessStructure définit des éléments de processus appartenant à une structure de décomposition (BreakdownElement). Parmi ces éléments de processus sont définis des produits de travail (WorkProductUse), des rôles (RoleUse), et également des éléments représentant un travail (WorkBreakdownElement). Parmi les éléments représentant un travail, une activité (Activity) est un conteneur pour d’autres éléments de processus appartenant à une structure de décomposition. Le paquetage ProcessWithMethod spécifie qu’un produit de travail se base sur une définition de produit de travail et qu’un rôle se base sur une définition de rôle. Il spécifie également un nouveau type d’élément de processus représentant un travail, la tâche (TaskUse), qui se base sur une définition de tâche. Une tâche est réalisée par un rôle, et c’est la classe ProcessPerformer qui fait le lien entre les deux. Une tâche a également des produits de travail en entrée et en sortie, et c’est un paramètre (classe ProcessParameter du paquetage ProcessStructure) qui permet de faire le lien entre une tâche et ses entrées et sorties. Le paquetage Core contient entre autres une classe ParameterDirectionKind, qui permet de définir si un produit de travail est une entrée (in) ou une sortie (out) d’un travail.Les processus de développement logiciel 21 Figure 2.4 – Syntaxe concrète de SPEM 2.0 et des diagrammes d’activités SPEM 2.0 définit également un plug-in de base, sous la forme d’une instance de MethodPlugin. Ce plug-in définit un type particulier d’activité, le processus (DeliveryProcess), qui correspond à l’approche complète pour réaliser un type de projet particulier. Un processus définit donc la séquence d’activités à réaliser pour mener à bien un projet de développement logiciel, tandis qu’une activité définit la séquence de tâches à effectuer pour réaliser cette activité. Étant donné qu’en SPEM 2.0 les tâches et les activités sont des actions (Action) UML 2.0 stéréotypées, il est possible d’utiliser les diagrammes d’activités UML 2.0 pour modéliser une séquence d’activités ou de tâches. En UML 2.0, une action, un flot de contrôle (ControlFlow), un nœud initial (InitialNode), un nœud final (ActivityFinalNode), un nœud de jointure (JoinNode), un nœud de parallélisation (ForkNode) et un nœud de décision (DecisionNode) sont des sous-types de nœud d’activité (ActivityNode). Un flot de contrôle représente l’enchaînement de deux nœuds d’activité, où un nœud d’activité source est suivi par un nœud d’activité cible. La condition d’un flot de contrôle, quand elle existe, spécifie à quelle condition ce flot de contrôle est navigable. Les nœuds initiaux et finaux spécifient respectivement le début et la fin d’un enchaînement d’activités ou de tâches. Un nœud de parallélisation divise un flot de contrôle en plusieurs flots de contrôle navigables simultanément. Un nœud de jointure fusionne plusieurs flots de contrôle en un seul. Un nœud de décision divise un flot de contrôle en plusieurs flots de contrôle alternatifs. La figure 2.4 illustre la syntaxe concrète que nous utilisons dans cette thèse pour représenter des processus SPEM 2.0 ainsi que des diagrammes d’activités. Pour terminer, nous illustrons l’utilisation de SPEM 2.0 en modélisant un exemple de processus simplifié de développement d’une application Java. Ce processus (cf. fi- gure 2.5) commence avec l’activité spécifier, durant laquelle un expert fonctionnel produit un document définissant les spécifications techniques et fonctionnelles de l’application à développer, en fonction des exigences d’un projet. L’activité spécifier est suivie par l’activité développer, pendant laquelle un développeur code manuellement l’application. Lors de l’activité tester suivante, un testeur vérifie que l’application en cours de dé- veloppement est bien conforme aux spécifications. Si cette activité révèle des erreurs, celles-ci doivent être corrigées, ce qui se traduit dans le processus par un retour à l’activité de développement. S’il n’y a pas d’erreur, le processus se termine par l’activité mettre en production, qui consiste à déployer l’application sur l’environnement du client. Dans le cas de cet exemple, l’activité de développement consiste en la création et la22 Background modification de projets Eclipse, comme illustré par la figure 2.6. Les tâches créer premier projet Eclipse, créer projet Eclipse, modifier projets Eclipse ainsi que le produit de travail projet(s) Eclipse font respectivement référence aux éléments de contenu de méthode de même nom de la figure 2.7. Figure 2.5 – Un processus simplifié de développement Java Figure 2.6 – Détail de l’activité de développement du processus de la figure 2.5L’ingénierie des lignes de produits logiciels 23 Figure 2.7 – Éléments de contenu de méthode du processus simplifié de développement Java de la figure 2.5 2.3 L’ingénierie des lignes de produits logiciels 2.3.1 Introduction Une ligne de produits logiciels, ou famille de produits logiciels, est un ensemble de produits logiciels partageant des caractéristiques communes et développés à partir d’un ensemble commun d’artéfacts [CN01]. L’ingénierie des lignes de produits logiciels [WL99, CN01, PBL05] permet la réutilisation d’artéfacts logiciels pour créer un nouveau produit logiciel, plutôt que de développer ce produit à partir de rien [Kru92]. Elle s’appuie sur l’identification de la variabilité et des parties communes d’une ligne de produits afin de réutiliser ces parties communes. L’ingénierie des lignes de produits logiciels apporte des bénéfices en termes de réduction des coûts et des temps de développement ainsi qu’en termes d’amélioration de la qualité des produits logiciels. Afin de permettre la réutilisation des artéfacts logiciels, l’ingénierie des lignes de produits logiciels s’appuie sur deux processus : l’ingénierie de domaine et l’ingénierie d’application [PBL05]. Le processus d’ingénierie de domaine consiste à identifier la variabilité et les parties communes d’une ligne de produits, ainsi qu’à développer les artéfacts communs aux produits de la ligne, en vue de leur réutilisation. Les artéfacts partagés par plusieurs produits ne sont définis qu’une seule fois, afin d’assurer leur réutilisation et d’en faciliter la maintenance [Kru06]. Le processus d’ingénierie d’application, aussi appelé processus de dérivation d’un produit logiciel, consiste à développer un produit logiciel spécifique à partir de la réutilisation des artéfacts développés pendant le processus d’ingénierie de domaine. Il s’appuie sur une phase de résolution de la variabilité, qui consiste à définir la configuration de produit souhaitée en spécifiant la valeur de chaque partie variable de la ligne de produits. On distingue deux types de variabilité : variabilité positive et variabilité néga-24 Background Figure 2.8 – Principe général de CVL, issu de la spécification de CVL 4 tive [VG07]. La variabilité positive consiste, durant le processus d’ingénierie de domaine, à ne définir que les artéfacts communs à tous les produits d’une famille. Les artéfacts spécifiques à un produit sont quant à eux créés au moment de la dérivation de ce produit, en fonction de sa spécification. Au contraire, la variabilité négative consiste, durant le processus d’ingénierie de domaine, à définir tous les artéfacts nécessaires à la définition des produits d’une famille. Lors de la dérivation d’un produit, les artéfacts ne correspondant pas à ce produit ne sont donc pas sélectionnés. Plusieurs approches s’appuient sur l’IDM afin de mettre en œuvre les concepts de l’ingénierie des lignes de produits logiciels [Jéz12]. L’IDM est ainsi utilisée pour définir des lignes produits et pour dériver des produits de ces lignes de produits. Nous présentons plus en détails une de ces approches, CVL [FHMP+11], dans la section suivante. 2.3.2 CVL CVL (Common Variability Language) 4 [FHMP+11], un standard de l’OMG en cours de spécification, est un langage de modélisation qui permet de spécifier et de résoudre de la variabilité sur n’importe quel modèle dont le métamodèle est conforme au MOF. Comme illustré en figure 2.8, CVL propose de définir un modèle de base (base model), qui est une instance de n’importe quel métamodèle conforme au MOF. Ce modèle de base contient les éléments de modèle nécessaires à la définition des différents produits d’une famille. CVL fournit également des constructions pour capturer la variabilité (VAM, Variability Abstraction Model) entre les différents produits d’une famille. Le VAM peut être comparé à un BFM (Basic Feature Model) [KCH+90], dans le sens où 4. La spécification complète de CVL peut être trouvée sur le wiki de CVL, à l’adresse http://www. omgwiki.org/variability/doku.php.L’ingénierie des lignes de produits logiciels 25 tout comme un BFM, il permet d’expliciter les différences et les similitudes entre les caractéristiques de produits logiciels d’une même famille. CVL fournit aussi des constructions pour définir la réalisation de cette variabilité sur le modèle de base (VRM, Variability Realization Model). Le VRM permet d’expliciter le lien entre le VAM et les éléments du modèle de base. Plus précisément, le VRM spécifie quels sont les éléments de modèle de base qui sont impactés par la variabilité définie dans le VAM et comment ces éléments de modèle sont impactés. En d’autres termes, le VRM spécifie comment dériver un produit du modèle de base, en fonction de la variabilité spécifiée dans le VAM. Enfin, CVL fournit des constructions permettant de résoudre la variabilité définie dans le VAM, afin de sélectionner une configuration du modèle de base (RM, Resolution Model). Le VAM, le VRM et le RM contiennent les informations nécessaires à la dérivation, à partir du modèle de base, d’un modèle résolu (resolved model), c’est-à-dire sans variabilité. Le modèle résolu est alors une autre instance du métamodèle auquel le modèle de base est conforme. Dans la suite, nous présentons les trois parties du métamodèle de CVL (abstraction de la variabilité, réalisation de la variabilité et résolution de la variabilité). Nous dé- taillons plus particulièrement les éléments du métamodèle de CVL qui seront utilisés pour illustrer la suite de cette thèse. Cependant, tous les éléments du métamodèle de CVL peuvent être utilisés pour mettre en œuvre ces travaux de thèse, en fonction des spécificités de chaque cas. Figure 2.9 – Extrait de la partie abstraction de la variabilité du métamodèle de CVL La figure 2.9 présente un extrait de la partie abstraction de la variabilité du métamodèle de CVL. Cette partie permet de définir de la variabilité à l’aide de spécifications de variabilité (VSpec). Une spécification de variabilité peut être un choix (Choice), c’est- à-dire une caractéristique qui appartiendra ou non au modèle résolu selon que ce choix sera résolu positivement ou négativement (c’est-à-dire selon que le choix sera sélectionné ou non). Une spécification de variabilité est également un conteneur pour26 Background d’autres spécifications de variabilité, qui sont alors ses enfants (child). Ces enfants peuvent être résolus à vrai seulement si leur parent (parent) est résolu à vrai. Une spécification de variabilité a aussi une multiplicité de groupe (groupMultiplicity) qui définit les nombres minimum et maximum (attributs lower et upper de la classe MultiplicityInterval) d’enfants directs qui peuvent être résolus positivement. La multiplicité de groupe permet donc d’exprimer si des spécifications de variabilité ayant le même parent direct sont mutuellement exclusives ou non. Si un choix est impliqué par son parent (attribut isImpliedByParent à vrai), alors il doit forcément être sélectionné si son parent l’est. L’implication par le parent permet donc d’exprimer qu’une spécification de variabilité enfant est optionnelle ou obligatoire. CVL fournit également le concept de dérivation de spécification de variabilité (VSpecDerivation), qui spécifie que la résolution d’une spécification de variabilité (identifiée par la référence derivedVSpec) est dérivée (c’est-à-dire calculée) de la résolution d’autres spécifications de variabilité. De ce fait, un RM ne définit pas de résolution pour une spécification de variabilité dont la résolution est dérivée. Un type particulier de dérivation de spécification de variabilité est la dérivation de choix (ChoiceDerivation), qui s’applique à un choix, identifié par la référence derivedChoice. Une dérivation de choix est associée à une contrainte de dérivation (Constraint) via la référence derivingConstraint. C’est cette contrainte de dérivation qui définit comment la résolution d’un choix est dérivée de la résolution d’autres spécifications de variabilité. Cette contrainte peut par exemple être exprimée à l’aide d’un langage de contrainte tel qu’OCL. Figure 2.10 – Exemple VAM spécifiant la variabilité d’un site d’achat en ligne À titre d’illustration (cf. figure 2.10), nous utilisons un VAM pour spécifier la variabilité d’un site d’achat en ligne. Les choix CVL permettent de spécifier les différentesL’ingénierie des lignes de produits logiciels 27 caractéristiques que peut avoir un tel site (paiement, catalogue, langue, recherche, sécurité, etc.). L’implication par le parent permet de spécifier les caractéristiques obligatoires (paiement, catalogue, langue, sécurité) et optionnelles (recherche, internationalisation). Une multiplicité de groupe dont la borne supérieure vaut 1 spécifie que des choix enfants sont mutuellement exclusifs (élevé et standard), tandis qu’une borne supérieure valant plus de 1 spécifie que plusieurs choix enfants peuvent appartenir à une même confi- guration de produit (par exemple français et anglais). La résolution du choix internationalisation est dérivée de la résolution des choix français et anglais. Plus précisément, un mécanisme d’internationalisation est utilisé pour développer un site d’achat en ligne si celui-ci doit être disponible dans les deux langues. Figure 2.11 – Extrait de la partie réalisation de la variabilité du métamodèle de CVL La figure 2.11 illustre un extrait de la partie réalisation de la variabilité du métamodèle de CVL. Le concept principal de cette partie réalisation de la variabilité est celui de point de variation (VariationPoint). Un point de variation est une opération à effectuer sur le modèle de base afin de dériver un modèle résolu. Un point de variation est effectué sur le modèle de base lorsque la spécification de variabilité qui lui est associée (bindingVSpecs) est résolue positivement. CVL définit différents types de points de variation. Parmi eux, un point de variation de choix (ChoiceVariationPoint) est un point de variation associé à une spécification de variabilité de type choix. Un point de variation de choix s’applique donc lorsque le choix associé (bindingChoice) est sélectionné. Différents types de points de variation de choix existent. Parmi eux, une substitution d’objet (ObjectSubstitution) remplace un objet du modèle de base, l’objet placement (placementObject), par un autre objet du modèle de base, l’objet remplaçant (replacementObject), et supprime l’objet placement. Une substitution de fin de lien (LinkEndSubstitution) assigne une nouvelle valeur à un lien du modèle de base. Ce lien est identifié par le nom de la référence qu’il instancie (linkEndIdentifier) ainsi que par l’objet qui contient ce lien (link). La nouvelle28 Background valeur à affecter au lien est un objet désigné par la référence replacementObject associée à la classe LinkEndSubstitution. Une existence d’objet (ObjectExistence) spécifie qu’un objet optionnel (optionalObject) du modèle de base existera toujours dans le modèle résolu. L’objet optionnel est supprimé du modèle de base (et donc du modèle résolu) si le choix associé au point de variation qui le contient n’est pas sélectionné. Ainsi, l’existence d’objet s’exécute en variabilité négative. Cela signifie qu’il n’est pas possible de créer des objets dans le modèle résolu. Si un objet appartient au modèle résolu, c’est forcément qu’il était défini dans le modèle de base. Il est uniquement possible de supprimer des objets du modèle de base pour qu’ils n’appartiennent pas à un modèle résolu. Au contraire, la variabilité positive signifie qu’il est possible de créer des objets au moment de la dérivation. Un pointeur de lien (LinkHandle) et un pointeur d’objet (ObjectHandle) permettent de référencer un objet du modèle de base via leur attribut MOFRef, qui correspond à l’URI de l’objet à référencer. Figure 2.12 – VRM de l’exemple de site d’achat en ligne Comme illustré par la figure 2.12, un VRM associé à l’exemple de site d’achat enL’ingénierie des lignes de produits logiciels 29 ligne spécifie que si le choix carte de crédit est sélectionné, alors, dans un modèle de base, la classe ClasseC doit référencer la classe ClasseD au lieu de la classe ClasseB. Si le choix recherche n’est pas sélectionné, alors la classe ClasseA du modèle de base appartiendra au modèle résolu. Enfin, si le choix standard est sélectionné, alors la classe ClasseE sera substituée par la classe ClasseH dans le modèle résolu. Figure 2.13 – Extrait de la partie résolution de la variabilité du métamodèle de CVL La figure 2.13 présente un extrait de la partie résolution de la variabilité du métamodèle de CVL. Le concept central de cette partie est celui de résolution de spécification de variabilité (VSpecResolution), qui résout une spécification de variabilité identifiée par la référence resolvedVSpec. Un type particulier de résolution de spécification de variabilité est la résolution de choix (ChoiceResolution), qui résout un choix identifié par la référence resolvedChoice. L’attribut decision d’une résolution de choix permet d’indiquer la valeur de résolution d’un choix. Un choix est en effet sélectionné ou non selon que cet attribut vaut vrai ou faux. Figure 2.14 – Exemple de RM résolvant le VAM de la figure 2.10 Le RM présenté en figure 2.14 résout la variabilité du VAM de la figure 2.10. Tous les choix sont sélectionnés sauf les choix recherche et standard. En conséquence, les substitutions de fin de lien et d’objet du VRM de la figure 2.12 sont appliquées au modèle de base afin de dériver le modèle résolu (figure 2.15), tandis que l’existence d’objet n’est pas appliquée. Dans le modèle résolu, la classe ClasseA n’existe donc pas,30 Background Figure 2.15 – Modèle résolu obtenu en fonction des modèles des figures 2.10, 2.12 et 2.14 la classe ClasseC référence la classe ClasseD au lieu de la classe ClasseB et la classe ClasseE a été substituée par la classe ClasseH. CVL propose également d’autres concepts permettant de gérer la variabilité, dont nous ne nous servirons pas pour illustrer la suite de cette thèse, bien qu’ils puissent être utilisés pour mettre en œuvre ces travaux. Nous en donnons un aperçu dans la suite de cette section. Il existe ainsi d’autres types de point de variation de choix. Parmi eux, l’affectation d’attribut permet d’assigner une nouvelle valeur à un attribut. L’existence de lien et l’existence d’attribut, de manière similaire à l’existence d’objet, permettent respectivement de spécifier l’existence d’un lien ou de la valeur d’un attribut. La figure 2.16 illustre un exemple d’utilisation de ces trois points de variation. Lorsque le choix choix 1 est sélectionné, alors la classe ClasseB est renommée en ClasseZ, le nom de la classe ClasseC existe et cette dernière hérite de ClasseZ (cf. figure 2.17). À l’inverse, lorsque le choix choix 1 n’est pas sélectionné, la classe ClasseB n’est pas renommée et le nom de la classe ClasseC est supprimé ainsi que la relation d’héritage (cf. figure 2.18). CVL permet également à ses utilisateurs de définir leurs propres points de variation, appelés points de variation opaques, en définissant des transformations d’un modèle vers un autre modèle. CVL définit aussi des points de variation paramétrables, tels que la substitution de fin de lien paramétrable, l’affectation d’attribut paramétrable et la substitution d’objet paramétrable. Ceux-ci se comportent comme leurs homologues non paramétrables, à la différence qu’une valeur à assigner ou un objet remplaçant ne sont spécifiés qu’au moment de la résolution, dans le RM. Cela est utile lorsqu’un élément du modèle de base a des variantes qui ne sont pas connues au moment de l’édition du VRM. Un point de variation paramétrable est relié à un type de spécification particulier, la variable. La valeur assignée à une variable est affectée au moment de la résolution, en utilisant un type de résolution de spécification de variabilité particulier, l’affectation de valeur à une variable. CVL propose également un point de variation dit répétable, la substitution de fragment. Exécutée une seule fois, la substitution de fragment remplace un fragment du modèle de base par un autre. Lorsqu’elle est répétée, une substitution de fragment crée une nouvelle instance du fragment remplaçant à chaque répétition. CVL définit un type de spécification de variabilité et un type de résolution de spécification de variabilité spécifiques au point de variation répétable, respectivement le classificateur de variabilité et l’instance de variabilité. Le classificateur de variabilité permet de spécifier deL’ingénierie des lignes de produits logiciels 31 Figure 2.16 – Exemple de définition d’affectation d’attribut, d’existence de lien et d’existence d’attribut Figure 2.17 – Modèle résolu obtenu lorsque le choix de la figure 2.16 est sélectionné Figure 2.18 – Modèle résolu obtenu lorsque le choix de la figure 2.16 n’est pas sélectionné la variabilité sur le nombre d’instances d’un fragment du modèle de base, tandis que l’instance de variabilité permet de déterminer ce nombre d’instances. Des exemples de VAM, VRM et modèle de base sont présentés en figure 2.19 afin d’illustrer une substitution de fragment. Si une instance de variabilité résout le classificateur de variabilité mon classificateur de variabilité, alors le fragment constitué des classes ClasseB et ClasseC est remplacé par le fragment constitué des classes ClasseD et ClasseE (cf. figure 2.20). Ce dernier est dupliqué si deux instances de variabilité résolvent mon classificateur de variabilité (cf. figure 2.21). Aucune substitution de fragment n’a lieu si aucune instance de variabilité ne résout mon classificateur de variabilité. Un autre type de point de variation introduit par CVL est le point de variation32 Background Figure 2.19 – Exemple de VAM, VRM et modèle de base pour une substitution de fragment Figure 2.20 – Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par une seule instance de variabilité Figure 2.21 – Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par deux instances de variabilité composite. Ce type de point de variation manipule des conteneurs, qui sont des objets du modèle de base contenant d’autres éléments de modèle, et sur lesquels de la variabilité est spécifiée. Comme illustré par la figure 2.22, le point de variation composite permet de cloner un conteneur (le paquetage paquetage configurable sur la figure), de résoudre la variabilité de chaque clone (paquetages une configuration du paquetage configurable etSynthèse 33 une autre configuration du paquetage configurable sur la figure), et de rediriger vers ces clones les liens des éléments du modèle de base qui les utilisent (paquetages paquetage 1 et paquetage 2 sur la figure). Ce type de point de variation est utile lorsqu’un conteneur est utilisé plusieurs fois dans un même modèle, mais que les différentes utilisations de cet objet requièrent des résolutions différentes de sa variabilité. CVL définit également un type de spécification de variabilité ainsi qu’un type de résolution de spécification de variabilité spécifiques à l’utilisation des points de variation composites, à savoir la spécification de variabilité composite et la configuration de variabilité. La spécification de variabilité composite, qui est un conteneur pour d’autres spécifications de variabilité, permet de spécifier de la variabilité au niveau du contenu d’un élément du modèle de base. La configuration de variabilité permet quant à elle de résoudre cette variabilité. Figure 2.22 – Illustration du principe du point de variation composite Enfin, CVL permet l’expression de contraintes transversales, c’est-à-dire de contraintes sur la résolution de spécifications de variabilité qui n’ont pas de relation de parent à enfant. Pour ce faire, CVL fournit le moyen d’exprimer des contraintes en utilisant la logique du premier ordre (incluant les quantificateurs universel et existentiel), ainsi que des contraintes arithmétiques. 2.4 Synthèse Nous avons présenté dans ce chapitre les différents champs de recherche sur lesquels nous nous appuyons dans cette thèse, à savoir l’IDM, les processus de développement logiciel et l’ingénierie des lignes de produits logiciels. Il est à noter que ces trois champs sont également très dynamiques dans le domaine de la recherche puisqu’ils ont leurs propres conférences (International Conference on Model Driven Engineering Languages and Systems, International Conference on Software and Systems Processes34 Background et International Software Product Line Conference) et qu’ils sont largement utilisés dans l’industrie [Nor08, HWRK11, Ins13]. Nous avons également présenté un langage de modélisation de processus de développement logiciel, SPEM 2.0, ainsi que CVL, un langage de modélisation permettant de spécifier et de résoudre de la variabilité sur des modèles. Dans cette thèse, nous proposons de lier des automatisations de TMR (Tâches Manuelles Récurrentes) à des processus de développement logiciel. Nous utilisons ensuite ce lien pour savoir : – quelles automatisations de TMR réutiliser pour un projet donné (en nous appuyant sur la réutilisation des processus de développement logiciel en fonction des exigences des projets), – à quels moments d’un projet les réutiliser – et pour identifier les différents cas d’utilisation de chaque automatisation de TMR et ainsi créer des automatisations de TMR qui soient réutilisables à travers ces différents cas d’utilisation. L’IDM nous offre pour ce faire deux langages de modélisation spécifiques à deux préoccupations distinctes : SPEM 2.0 et CVL. SPEM 2.0 nous permet de définir les processus de développement logiciel et nous l’avons choisi car c’est un standard de l’OMG. Il est cependant tout à fait possible d’utiliser un autre langage de modélisation de processus de développement logiciel pour mettre en œuvre l’approche proposée dans cette thèse, en fonction des besoins d’un groupe d’utilisateurs. CVL nous permet de réutiliser les processus de développement logiciel. Il a l’avantage d’appliquer les principes de l’ingénierie des lignes de produits de logiciel et de pouvoir être utilisé quel que soit le langage de modélisation de processus utilisé pour peu qu’il soit conforme au MOF. L’IDM nous offre de plus des outils (par exemple EMF) permettant l’implémentation de SPEM 2.0 et de CVL et la création de nouveaux langages de modélisation, tel qu’un langage spécifique aux automatisations de TMR. Enfin, l’utilisation d’un même métamétamodèle pour différents langages de modélisation permet de créer des liens entre ces langages. Il nous est ainsi possible de tisser les liens nécessaires dans le contexte de cette thèse, à savoir entre gestion de la variabilité et processus et entre processus et automatisations de TMR.Chapitre 3 État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus L’automatisation des TMR (Tâches Manuelles Récurrentes) liées à l’utilisation des outils de développement logiciel n’a qu’un intérêt limité si les mêmes automatisations de TMR sont re-développées pour chaque projet. La réutilisation d’automatisations de TMR amène cependant trois difficultés principales. La première est de savoir pour quels projets réutiliser une automatisation de TMR. En effet, une même automatisation de TMR peut être utile pour des projets différents, mais elle n’est pas forcément utile pour tous les projets. De plus, comme une automatisation de TMR peut avoir des dépendances avec d’autres tâches d’un projet, la deuxième difficulté est de déterminer à quels moments d’un projet utiliser une automatisation de TMR. La troisième difficulté est de s’assurer qu’une automatisation de TMR utile pour des projets différents, ou utile à des moments différents d’un même projet, soit bien réutilisable à travers ses différents cas d’utilisation. La difficulté est donc d’identifier le bon niveau de généricité d’une automatisation de TMR. Une méthodologie est proposée par Sadovykh et Abherve [SA09] afin de supporter l’exécution de processus SPEM. Elle consiste à définir un processus SPEM et à le transformer en un processus BPEL [OAS07] afin de l’exécuter. L’apport principal de cette méthodologie est que le processus BPEL obtenu par transformation est directement exécutable. Pour ce faire, la méthodologie consiste à assigner au processus SPEM, avant sa transformation, les informations nécessaires pour le rendre exécutable (ressources humaines concrètes associées aux rôles, nombre des itérations et durée des tâches). Durant l’exécution du processus BPEL, les TMR sont automatisées à l’aide de services web, qui sont reliés aux unités de travail du processus BPEL et sont appelés au moment de l’exécution de ces unités de travail. Le lien entre les services web (similaires à des automatisations de TMR) et les unités de travail du processus qu’ils automatisent permet donc de savoir quand lancer ces services web au cours d’un projet. Mais la limite de cette méthodologie est qu’elle ne propose pas de support à la sélection des 3536État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus automatisations de TMR à réutiliser pour un projet donné. Si des automatisations de TMR sont liées à des processus de développement logiciel, alors réutiliser un processus de développement logiciel pour un projet donné permet de connaître les automatisations de TMR à réutiliser pour ce projet. Or, réutiliser les processus de développement logiciel est un exercice difficile. En effet, la variabilité au niveau des exigences des projets est la source d’un nombre de processus trop élevé pour qu’un humain puisse tous les connaître et savoir quand les réutiliser [Rom05, CDCC+13]. De nombreuses approches sont donc apparues afin d’apporter un support à la réutilisation des processus de développement logiciel. Figure 3.1 – Représentation en extension des processus d’une famille [LS07] Dans le cadre de cette thèse, nous fixons certaines exigences qu’une telle approche doit satisfaire. Premièrement, elle doit permettre de définir un ensemble de processus et de dériver automatiquement un processus de cet ensemble, afin de permettre la réutilisation des processus. Deuxièmement, l’approche doit permettre de définir les différents processus à réutiliser en intention, c’est-à-dire en factorisant leurs parties communes, afin d’en faciliter la maintenance et de permettre leur réutilisation [RMvdT09, HBR10, KY12]. Plus précisément, la définition en intention de processus consiste à ne définir qu’une seule fois une partie commune à plusieurs processus et à y faire référence pour l’utiliser. À l’inverse, la définition en extension de processusSupport à la réutilisation des processus sans spécification de leur variabilité 37 consiste à les définir entièrement et indépendamment les uns des autres, en dupliquant leurs parties communes d’un processus à l’autre (mais pas nécessairement au sein d’un même processus puisque les flots de contrôle sont souvent utilisés pour retourner à une partie d’un processus). La figure 3.1, issue de [LS07], illustre la représentation en extension de différents processus d’une même famille. On remarque que ces processus partagent des parties communes qui sont dupliquées (par exemple la tâche T1). Cela pose des problèmes de maintenance car lorsqu’une de ces parties évolue, elle doit être mise à jour dans tous les processus auxquels elle appartient, ce qui est source d’erreurs et coûteux en temps. Cela limite de plus la réutilisation de fragments de processus. Troisièmement, une approche supportant la réutilisation des processus doit pouvoir s’appliquer quel que soit le formalisme utilisé pour définir les processus, afin que les utilisateurs de cette approche puissent utiliser le formalisme qui satisfait le mieux leurs exigences [Mee10, WKK+11, KY12]. Cela permet à un groupe d’utilisateurs de pouvoir changer de formalisme de définition de processus, mais cela permet également que l’approche puisse être utilisable par des groupes d’utilisateurs utilisant des formalismes différents. En plus de nous intéresser aux approches traitant de la réutilisation des processus de développement logiciel, nous nous intéressons aux approches traitant de la réutilisation des processus métiers, où un processus métier correspond à l’ensemble des tâches permettant de créer un résultat de valeur pour un client [Ham96]. En effet, un processus de développement logiciel est également un processus métier [Ben07]. De la même manière, comme un workflow, c’est-à-dire une automatisation partielle ou totale d’un processus métier [(WF99], peut être considéré comme un processus mé- tier [Ben07, LRvdADM13], et que les diagrammes d’activités UML sont parfois utilisés pour capturer les processus métiers [LRvdADM13], nous incluons dans cet état de l’art les approches traitant de la réutilisation des workflows et des diagrammes d’activités. Nous présentons les approches supportant la réutilisation de processus dans la suite de ce chapitre et nous les évaluons en fonction des exigences précédemment définies. La section 3.1 présente des approches apportant un support à la réutilisation des processus sans traiter de la spécification de leur variabilité. La section 3.2 porte sur les approches s’appuyant sur l’ingénierie des lignes de processus [Rom05] afin de réutiliser les processus, où l’ingénierie des lignes de processus est une activité similaire à l’ingénierie des lignes de produits mais où le produit est un processus. Nous faisons la synthèse de ces approches en section 3.3. 3.1 Support à la réutilisation des processus sans spécification de leur variabilité Nous présentons dans cette section des approches offrant des mécanismes pour supporter la réutilisation des processus sans pour autant permettre de spécifier leur variabilité. La section 3.1.1 traite des approches permettant d’identifier le processus correspondant le mieux à un projet. La section 3.1.2 présente des approches permettant de réutiliser des processus définis en extension. Enfin, la section 3.1.3 aborde les patrons38État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus de processus. 3.1.1 Identification du processus correspondant à un projet Les approches suivantes permettent d’identifier à quels types de projets correspondent quels types de processus, afin de faciliter le choix d’un processus pour un projet donné. Elles sont toutes assez abstraites pour pouvoir être appliquées quel que soit le formalisme de définition de processus utilisé. L’approche Promote (Process Models Taxonomy for Enlightening choices) [CDCC+13] définit un ensemble de caractéristiques de processus de développement logiciel et propose une classification de processus existants en fonction de ces caractéristiques. Les processus sont caractérisés selon 6 axes principaux : i) le cycle, c’est-à-dire la granularité des itérations, la durée du cycle de vie, les incréments, etc., ii) la collaboration, c’est-à- dire les différents types de relations qui existent entre les intervenants sur un projet iii) les artéfacts, c’est-à-dire les types de livrables qui doivent être produits, iv) l’utilisation recommandée, c’est-à-dire dans quels contextes un processus est le plus adapté, v) le niveau de maturité du processus, et vi) la flexibilité, c’est-à-dire la capacité du processus à être adapté. Cependant, Promote ne propose pas de mécanisme permettant d’obtenir un processus correspondant à un projet dans un formalisme permettant son exécution. D’autre part, la problématique de la définition d’une famille de processus en intention est en dehors des objectifs de cette approche. D’autres approches, en plus de proposer des caractéristiques pour définir les processus et les projets, proposent un support à la sélection du processus correspondant le mieux à un projet. Ainsi, l’approche de Pérez et al. [PEM95] propose une méthodologie permettant d’évaluer l’efficacité d’un processus pour un projet donnée, en fonction de leurs caractéristiques respectives. L’approche d’Alexander et Davis [AD91] fournit quant à elle une méthode permettant de déterminer le processus qui correspond le mieux à un projet donné, toujours en fonction des critères des processus et de ce projet. L’approche de Sharon et al. [SdSSB+10] propose un framework supportant la sélection du processus correspondant le mieux à un projet donné. Mais ces approches ne traitent pas de la définition d’une famille de processus et de la dérivation d’un processus de cette famille en fonction des exigences des projets. Comme résumé dans le tableau 3.1, les approches présentées ici, bien qu’indépendantes du formalisme utilisé pour définir les processus, ne fournissent pas tous les mécanismes nécessaires à la réutilisation des processus de développement logiciel. La définition en intention d’un ensemble de processus n’est de plus pas traitée par ces approches.Support à la réutilisation des processus sans spécification de leur variabilité 39 Approche Concepts proposés Apports réutilisation processus Limites réutilisation processus Déf. des pro- cessus en in- tention Indépendante du formalisme pour définir les processus Promote [CDCC+13] Caractéristiques de processus et classification de processus en fct. de ces caractéristiques Identification du pro- cessus correspondant à un projet Obtention d’un pro- cessus exécutable non oui Pérez et al. [PEM95] Méthodologie pour évaluer l’effica- cité d’un processus pour un projet donné Identification du pro- cessus correspondant à un projet Déf. d’une famille de processus et dériva- tion d’un processus non oui Alexander et Davis [AD91] Méthode pour déterminer le proces- sus qui correspond le mieux à un projet Identification du pro- cessus correspondant à un projet Déf. d’une famille de processus et dériva- tion d’un processus non oui Sharon et al. [SdSSB+10] Framework supportant la sélection du processus correspondant le mieux à un projet Identification du pro- cessus correspondant à un projet Déf. d’une famille de processus et dériva- tion d’un processus non oui Table 3.1 – Évaluation des approches permettant d’identifier le processus correspondant le mieux à un projet40État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus 3.1.2 Réutilisation de processus définis en extension D’autres approches permettent quant à elles de définir un ensemble de processus et de réutiliser des processus de cet ensemble. L’approche de Lu et Sadiq [LS07] permet l’extraction d’un processus depuis un ensemble de processus capturés dans un dépôt, en fonction des caractéristiques de ce processus. Elle définit pour ce faire une mesure de similarité, qui permet de déterminer quel est le processus du dépôt qui est le plus proche d’un ensemble de caractéristiques. Cette approche est cependant dépendante du formalisme utilisé pour définir les processus. En effet, la définition de la mesure de similarité dépend de la sémantique des éléments à comparer. De plus, l’approche est définie pour un formalisme de processus particulier et devrait donc être adaptée pour pouvoir être utilisée avec un formalisme différent. L’approche de Song et Osterweil [SO98] applique le principe de la programmation des processus [Ost87] à la méthodologie de conception logicielle BOOD (Booch Object Oriented Design Methodology) [Boo91]. Le principe de la programmation des processus suggère que les processus soient considérés comme des logiciels et soient donc conçus, développés et exécutés comme tels. Il est assez générique pour pouvoir être utilisé quel que soit le langage de modélisation de processus. BOOD est considérée comme étant l’architecture d’un processus de conception. Des processus de conception plus détaillés sont élaborés à partir de cette méthodologie puis exécutés, à l’aide du prototype DebusBooch. Celui-ci permet entre autres de sélectionner un processus de conception logiciel depuis une famille de tels processus. Il apporte de plus un support à cette sélection en fournissant des informations sur la nature des différents processus et des étapes qui les composent. Bien que permettant la réutilisation des processus, les deux approches précédentes ne proposent pas de mécanismes permettant de définir un ensemble de processus en intention, comme résumé dans le tableau 3.2. À défaut d’un tel mécanisme, les processus sont donc définis en extension. 3.1.3 Les patrons de processus Un patron de processus, ou composant de processus, est un fragment de processus réutilisable [GLKD98, ABC96, Amb99]. De nombreuses approches proposent des patrons de processus (par exemple [VDATHKB03, RHEdA05, KR10, BnCCG11, KYSR09, IMCH+07]). Ceux-ci peuvent être définis à des niveaux d’abstraction diffé- rents. Des patrons généraux devront donc être adaptés à un contexte particulier pour pouvoir être réutilisés, tandis que des patrons plus détaillés pourront être réutilisés tels quels [GLKD98, ABC96, GM05, Amb99]. Certains langages de modélisation de processus, comme SPEM 2.0 ou Little-JIL [Wis06], permettent quant à eux de définir des patrons de processus et de les intégrer à un processus. D’autre part, plusieurs approches proposent de définir des processus par réutilisation et composition de patrons de processus [GLKD98, ABC96, Zhu03, PS05, BBM05]. Elles fournissent les mécanismes nécessaires à la définition et à la composition de ces patrons. Mais, dans toutes les précédentes approches, la sélection et la composition de patrons de processus, ouSupport à la réutilisation des processus sans spécification de leur variabilité 41 Approche Concepts proposés Apports réutilisation processus Limites réutilisation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus Lu et Sadiq [LS07] Extraction d’un dépôt du processus le plus proche d’un ensemble de caractéristiques Définition d’un ensemble de processus et réutilisation des processus de cet ensemble aucune non non Song et Osterweil [SO98] Application du principe de la programmation des processus à BOOD Définition d’un ensemble de processus et réutilisation des processus de cet ensemble aucune non oui Table 3.2 – Évaluation des approches de Lu et Sadiq [LS07] et Song et Osterweil [SO98] leur intégration à un processus, restent manuelles. D’autres approches apportent donc un support à la réutilisation de patrons de processus. L’outil Intelligent Workflow Designer [IMCH+07] permet la modélisation de processus métiers basée sur la réutilisation de patrons de workflows. Au moment de la modélisation d’un processus, il analyse ce processus et propose des patrons à appliquer, parmi un ensemble de patrons prédéfinis. Mais la modélisation d’un processus reste en grande partie manuelle. Un processus doit d’ailleurs être modélisé manuellement une première fois avant d’être analysé en vue de détecter les patrons qui pourraient être appliqués. L’outil ne permet pas de définir un ensemble de processus en intention et l’indépendance vis-à-vis des langages de modélisation de processus n’est pas traitée. L’approche Design by Selection [ASKW11] permet également la réutilisation de composants de processus durant la modélisation d’un processus. Un processus est dans un premier modélisé manuellement et l’approche permet de définir manuellement les parties de ce processus pour lesquelles un composant doit être réutilisé. Ces parties sont alors utilisées pour faire des requêtes sur un dépôt de composants de processus, afin de récupérer un ensemble de composants pouvant correspondre à une partie de processus. La sélection d’un composant parmi l’ensemble retourné est elle aussi manuelle, même si l’approche offre un support à cette sélection en classant les composants proposés en fonction de leur pertinence. Là encore une partie de la définition des processus reste manuelle et leur réutilisation n’est donc pas complètement automatisée. L’approche est assez abstraite pour pouvoir être appliquée indépendamment d’un langage de modélisation de processus. Mais son implémentation dépend quant à elle d’un tel langage. Cette approche ne traite pas non plus de la définition de processus42État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus en intention. L’outil CAT (Composition Analysis Tool) [KSG04] assiste un utilisateur dans la défi- nition de workflows basée sur la réutilisation de composants. CAT analyse un workflow en cours de définition et suggère des actions possibles à la personne en charge de cette définition (par exemple des ajouts ou des suppressions de composants) et s’assure que le workflow produit est correct (par exemple en vérifiant que des flots de contrôle de sont pas inconsistants avec la description d’un composant). La définition de processus reste là encore en grande partie manuelle et la spécification de processus en intention ainsi que l’indépendance vis-à-vis des langages de modélisation de processus ne sont pas abordées. Aldin [Ald10] propose une méthodologie pour l’extraction de patrons de processus métiers depuis un ensemble de processus et la réutilisation de ces patrons lors de la modélisation d’un nouveau processus métier. Un patron de processus est sélectionné en fonction des exigences correspondant à un problème métier. Il est ensuite adapté à un problème métier spécifique puis intégré au processus correspondant à ce problème métier. Cette méthodologie est assez générique pour pouvoir être appliquée quel que soit le langage de modélisation de processus utilisé. En revanche, rien n’est proposé afin d’automatiser la réutilisation des patrons de processus. La spécification en intention d’un ensemble de processus n’est pas non plus abordée. Comme résumé dans le tableau 3.3, plusieurs approches apportent un support à la réutilisation de patrons de processus, mais la définition d’un processus reste en grande partie manuelle. Ces approches ne permettent pas de capturer un ensemble de processus et d’en dériver automatiquement un processus. D’autres approches permettent quant à elles de réutiliser automatiquement un processus dont la définition s’appuie sur des patrons de processus [AB12, Ist13, BDKK04, FPLPdL01]. Nous les présentons plus en détails dans la section 3.2. 3.2 Ingénierie des lignes de processus D’autres approches s’appuient sur l’ingénierie des lignes de processus [Rom05] afin de réutiliser les processus. L’ingénierie des lignes de processus est une activité similaire à l’ingénierie des lignes de produits, mais où le produit est un processus. Les approches existantes définissent une ligne de processus en spécifiant les différents processus d’une famille ainsi que leurs parties variables et communes [Ter09]. Une ligne de processus est donc définie en intention et non en extension. Ainsi, lorsqu’une partie commune à plusieurs processus évolue, celle-ci n’est mise à jour qu’une seule fois. Il est possible de réutiliser un processus d’une famille en le dérivant de la ligne de processus. Les approches existantes s’appuient sur l’IDM afin de définir une ligne de processus et d’en dériver un processus. Nous détaillons ces approches dans la suite de cette section.Ingénierie des lignes de processus 43 Approche Concepts proposés Apports réutilisation processus Limites réutilisation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus Intelligent Workflow Designer [IMCH+07] proposition de patrons à réutiliser réutilisation de patrons de workflows déf. de processus en partie manuelle non non Design by Selection [ASKW11] proposition de patrons à réutiliser réutilisation de composants de processus déf. de processus en partie manuelle non non CAT [KSG04] proposition de patrons à réutiliser réutilisation de composants de workflows déf. de processus en partie manuelle non non Aldin [Ald10] méthodologie pour la dé- couverte et la réutilisation de patrons de processus réutilisation de patrons de processus déf. de processus et réutilisation de patrons manuelles non oui Table 3.3 – Évaluation des approches apportant un support à la réutilisation de patrons de processus, mais sans permettre la réutilisation automatique de processus 3.2.1 Utilisation des mécanismes d’un langage Deux approches, d’Alegría et al. [HABQO11] et d’Alegría et Bastarrica [AB12], gèrent la variabilité des processus de développement logiciel en s’appuyant sur les mécanismes de variabilité fournis par SPEM 2.0. SPEM 2.0 offre en effet des mécanismes permettant de spécifier qu’un élément de processus est optionnel, d’ajouter des propriétés à un élément ou d’étendre ou de remplacer les propriétés d’un élément. Il permet également de définir des patrons de processus, que l’approche d’Alegría et Bastarrica permet de réutiliser automatiquement lors de la dérivation d’un processus. Cependant, ces mécanismes sont spécifiés directement dans le métamodèle de SPEM 2.0 et aucun moyen permettant de les découpler de ce métamodèle n’est proposé. En conséquence, réutiliser ces mécanismes avec un autre langage de modé- lisation de processus implique, en plus de devoir adapter ces mécanismes, de devoir modifier le métamodèle de cet autre langage.44État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus 3.2.2 Extension d’un langage de modélisation de processus Les approches de cette catégorie étendent un langage de modélisation de processus existant avec des concepts permettant de gérer la variabilité. Cependant, la plupart d’entre elles ne propose pas de mécanisme permettant d’appliquer ces concepts à un langage sans le modifier. Celles qui le font proposent quant à elles des concepts qui doivent être adaptés pour pouvoir être réutilisés avec des langages de modélisation de processus autres que celui pour lequel ils ont été initialement définis. 3.2.2.1 Utilisation de processus agrégats Figure 3.2 – Un exemple de modèle de processus agrégat [HBR10] Afin de gérer la variabilité des processus, certaines approches s’appuient sur des modèles de processus agrégats [RMvdT09]. Un processus agrégat capture les différents processus d’une famille en les combinat dans un même et unique processus à l’aide de mécanismes spécifiques à la modélisation d’un flot d’unités de travail (nœuds de décision, de jointure, de parallélisation, flots de contrôle, etc.) [KL07, RvdA07]. Par exemple, la figure 3.2 illustre un processus agrégat qui capture les différents processus d’une famille en utilisant des nœuds de décision. Néanmoins, un simple modèle de processus agrégat n’offre pas de support à la réutilisation des processus [GvdAJV07, RvdA07, HBR10]. Par exemple, il n’est pas possible de distinguer les nœuds de décision représentant des choix qui doivent être faits au moment de l’exé- cution d’un processus de ceux qui dénotent des processus différents [HBR10]. Il n’est pas non plus possible de distinguer les éléments de processus optionnels [RvdA07]. Les approches existantes proposent donc d’étendre un langage de modélisation de processus avec des mécanismes permettant d’expliciter la variabilité dans un modèle de processus agrégat, et elles offrent un support à la sélection et à la dérivation d’un processus de ce processus agrégat. Selon les approches, un processus peut ainsi être dérivé par sélection ou omission d’éléments du processus agrégat, par adaptation des éléments du processus agrégat à des exigences particulières, par ajout d’éléments spécifiques à un cas particulier, ou par instanciation (c’est-à-dire en fournissant une implémentation à un concept abstrait). Aucun moyen n’est cependant proposé afin d’étendre un langage de modélisation de processus sans le modifier. Nous présentons ces approches dans la suite de cette partie, en détaillant plus particulièrement les extensions qu’elles proposent. L’approche KobrA (KOmponenten BasieRte Anwendungsentwicklung, allemand pourIngénierie des lignes de processus 45 développement d’applications basé sur les composants) [ABM00] intègre l’ingénierie des lignes de produits logiciels et l’ingénierie logicielle basée sur les composants [Crn02]. Dans ce cadre, elle propose une notation afin de distinguer dans un processus agrégat les nœuds de décision dénotant des processus différents de ceux dénotant des choix à faire au moment de l’exécution d’un processus. L’approche Superimposed Variants [CA05] s’appuie sur les BFM (Basic Feature Model) [KCH+90] afin de gérer la variabilité de modèles et permet de faire le lien entre les BFM et les modèles desquels ils spécifient la variabilité. Cette approche étend un langage de modélisation avec des mécanismes permettant d’associer à des éléments de modèle i) des informations déterminant dans quels cas ces éléments sont sélectionnés et ii) des méta-expressions, qui spécifient comment configurer les propriétés d’un élé- ment en fonction de ses différents cas d’utilisation. Cette approche n’est pas spécifique à la gestion de la variabilité dans les processus mais est appliquée à des modèles de processus agrégats définis à l’aide de diagrammes d’activité UML 2.0. D’autres approches permettent de configurer des modèles de processus référence, où un processus de référence est un processus général qui définit les bonnes pratiques recommandées dans un domaine particulier [FL03, Fra99]. Dans ces approches, les modèles de processus de référence sont définis comme des modèles agrégats, bien que rien n’impose qu’un modèle de référence soit un modèle agrégat [Tho05]. Ainsi, l’approche C-EPC (Configurable Event-driven Process Chain) [RvdA07] permet de configurer les processus de référence définis à l’aide du langage de modélisation de processus EPC [Sch00]. Celui-ci est étendu avec des mécanismes permettant de spé- cifier qu’une unité de travail est optionnelle, qu’un connecteur (c’est-à-dire un nœud de décision, de jointure ou de parallélisation) peut être remplacé par un connecteur qui restreint son comportement, ou qu’au moment de la dérivation un seul des flots de contrôle navigables à l’issue d’un nœud de décision pourra être sélectionné. C-EPC propose également d’étendre EPC avec des mécanismes permettant d’exprimer des contraintes entre les résolutions d’éléments de modèle variables (implication, exclusion, etc.). L’approche C-iEPC (Configurable integrated EPC) [RDH+08, LRDtHM11] étend EPC avec les concepts de rôle et d’objet (où la notion d’objet est similaire à la notion de produit de travail) et avec des mécanismes permettant de spécifier que des rôles ou des objets sont optionnels, alternatifs, ainsi que le nombre minimal et maximal de rôles ou d’objets qui peuvent être sélectionnés. L’approche aEPC (Aggregate EPC) [RMvdT09] permet de déterminer les cas d’utilisation des éléments d’un processus de référence. Pour ce faire, elle étend le langage de modélisation de processus utilisé avec des mécanismes permettant d’associer aux éléments d’un modèle de processus de référence des informations déterminant dans quels cas ces éléments sont sélectionnés. L’approche Configurative Process Modeling [BDK07] étudie l’applicabilité des mécanismes utilisés pour configurer des modèles de processus de référence aux méthodes d’ingénierie logicielle. Dans ce contexte, elle propose d’étendre le formalisme utilisé pour définir une méthode logicielle avec des mécanismes permettant i) d’associer aux éléments d’une méthode des informations déterminant dans quels cas ces éléments46État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus sont sélectionnés, ii) de définir qu’un élément d’une méthode est abstrait et doit être instancié au moment de la dérivation et iii) d’associer à un élément d’une méthode des informations aidant à l’adapter aux exigences d’un projet. L’approche ADOM (Application-based DOmain Modeling) [RBSS09, RBSS10] permet de définir la variabilité d’un modèle de processus de référence, d’en dériver un processus spécifique et de vérifier qu’un processus spécifique appartient bien à la famille de processus capturée par le modèle de référence. Un processus peut être dérivé en adaptant les éléments du modèle de processus agrégat ou en lui ajoutant des éléments, en plus de pouvoir sélectionner ou omettre des éléments du processus agrégat. ADOM étend un langage de modélisation de processus avec les concepts d’indicateur de multiplicité et de classificateur de modèle de référence. Un indicateur de multiplicité permet de spécifier qu’un élément du modèle de processus de référence est optionnel, obligatoire, qu’il a des variantes et combien. Un classificateur de modèle de référence permet de spécifier à quel élément du modèle de processus de référence un élément d’un modèle de processus résolu correspond. Il permet de vérifier qu’un processus appartient bien à la famille de processus capturée par le modèle de processus de référence. L’approche Configurable Workflow [GvdAJVLR08] se concentre sur la configuration de modèles de workflows, afin de permettre la production de modèles directement exécutables. Elle propose d’étendre les unités de travail d’un langage de modélisation de workflows avec des ports d’entrée et de sortie, où un port est un endroit connectant un flot de contrôle à une unité de travail. La configuration d’un modèle de processus de référence consiste à définir si un port est activé, bloqué ou caché. Cela permet de spécifier les parties d’un workflow qui peuvent être exécutées. 3.2.2.2 Modification d’un processus de base Une limitation des approches qui s’appuient sur les modèles de processus agrégats est que lorsque les processus à capturer sont complexes et nombreux, alors le processus agrégat devient illisible et difficile à créer et à maintenir [HBR10, DB10]. Afin de faire face à cette difficulté, l’approche Provop (PROcess Variants by OPtions) [HBR10] propose de modéliser un processus de base (qui peut être un processus de référence, un processus d’une famille, le processus commun à tous les processus d’une famille, etc.) et de définir les opérations à appliquer à ce processus afin d’en dériver les différents processus d’une famille. Des points d’ajustement sont utilisés pour spécifier les parties du processus de base auxquelles des opérations sont appliquées. Cependant, aucun mécanisme n’est proposé pour définir des points d’ajustement sans modifier le langage de modélisation de processus utilisé. L’approche proposée par Mosser et Blay-Fornarino [MBF13] supporte l’évolution automatique de modèles de processus métiers, c’est-à-dire la modification automatique de modèles de processus métiers afin qu’ils soient conformes aux changements apportés à un domaine métier. Cette approche supporte également la détection d’interférences entre les évolutions apportées à un processus métier, où une interférence est une interaction entre des évolutions qui engendre un comportement non souhaité d’une ou plusieurs de ces évolutions. Une évolution est apportée à un modèle de processusIngénierie des lignes de processus 47 métier en lui composant un fragment de processus. À cette fin, le métamodèle ADORE (Activity meta-moDel supOrting oRchestration Evolution) est proposé. Il permet de définir des processus métiers, des fragments de processus ainsi que les endroits d’un processus où ces fragments peuvent être intégrés. Mais aucun mécanisme n’est proposé afin de pouvoir définir des fragments de processus ainsi que leurs points d’intégration sans modifier le langage de modélisation de processus utilisé. 3.2.2.3 Spécification des points de variation et des variantes d’un processus Plusieurs approches définissent une ligne de processus en modélisant le processus commun à tous les processus d’une famille et en spécifiant quelles sont les parties de ce processus qui varient (points de variation) et leurs différentes valeurs (variantes). Contrairement aux processus agrégats, les différents processus d’une famille ne sont pas tous intégrées dans un même processus en utilisant les mécanismes spécifiques à la modélisation d’un flot d’unités de travail. La figure 3.3 illustre un exemple de définition de points de variation et de variantes sur un modèle de processus. Elle illustre que l’unité de travail P2 est en fait un point de variation ayant pour variantes les unités de travail A1 à An. Un processus d’une famille est dérivé en remplaçant chaque point de variation par une variante, sélectionnée en fonction des exigences d’un projet. Les approches existantes étendent donc un langage de modélisation de processus avec des mécanismes permettant de définir des points de variation et des variantes. Figure 3.3 – Exemple de définition de points de variation et de variantes sur un modèle de processus [MHY08] Ainsi, l’approche vSPEM [MRGP08] étend SPEM 2.0 avec des mécanismes de variabilité évalués empiriquement comme plus compréhensibles que ceux proposés par SPEM 2.0 [MRGPM11]. Ces mécanismes permettent de définir que des activités, des produits de travail, des rôles ou des tâches sont des points de variation. Ils permettent également de définir les variantes associées à chaque point de variation ainsi que des relations de dépendance (inclusion et exclusion) entre points de variation et variantes. L’approche de Kulkarni et Barat [KB10] étend le langage de modélisation de processus BPMN (Business Process Model and Notation) [OMG11a] afin de gérer la variabilité48État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus dans les modèles de processus BPMN. L’extension proposée permet de spécifier qu’une activité ou qu’un évènement sont des points de variation, quelles sont leurs variantes, et de sélectionner les variantes à affecter aux points de variation. L’approche de Nguyen et al. [NCH11] gère la variabilité dans des services définis par des processus métiers. Elle s’attache en particulier à gérer les dépendances de variabilité entre un service et les services qui le compose. Afin de gérer la variabilité de services, elle étend BPMN avec des concepts permettant de définir des points de variation sur le séquencement d’activités, ainsi que sur les données et messages échangés par ces activités. Ces concepts permettent également de spécifier les variantes d’un point de variation ainsi que le nombre minimum et maximum de variantes qui peuvent être sélectionnées pour chaque point de variation. Trois approches, PESOA (Process Family Engineering in Service-Oriented Applications) [PSWW05], BPFM (Business Process Family Model) [MHY08] et celle proposée par Ripon et al. [RTM10], s’appuient sur les stéréotypes UML afin de spécifier la variabilité de processus capturés dans des diagrammes d’activités UML. L’approche PESOA identifie les mécanismes de variabilité pertinents pour la gestion de la variabilité dans les processus, parmi un ensemble de mécanismes existants (paramétrage, extension, remplacement, omission, ajout, etc.), et les applique aux processus. Dans ce contexte, elle propose des stéréotypes permettant de spécifier qu’une unité de travail est un point de variation, quelles sont ses variantes, si une variante peut être utilisée par défaut, si des variantes sont mutuellement exclusives et si une unité de travail est optionnelle. L’approche PESOA propose également d’utiliser les mêmes stéréotypes pour spécifier la variabilité de processus modélisés avec BPMN. Pour cela, elle propose d’étendre BPMN avec le concept de stéréotype. L’approche BPFM consiste à analyser la variabilité d’un processus métier à diffé- rents niveaux d’abstraction afin d’identifier les points de variation et les variantes de ce processus. Afin de spécifier ces derniers, elle propose des stéréotypes permettant de définir qu’une activité est optionnelle ou obligatoire, qu’elle a des variantes, le nombre minimum et maximum de variantes d’une activité qui peuvent être sélectionnées, ainsi que les dépendances entre les points de variation et les variantes. Ces stéréotypes permettent également de spécifier de la variabilité au niveau des flots de contrôle. Il est aussi possible de spécifier si de nouvelles variantes peuvent être définies au moment de la résolution. L’approche proposée par Ripon et al. se concentre sur la gestion de la variabilité dans les modèles de domaine, qui définissent les aspects conceptuels d’un système. Elle propose un stéréotype afin de spécifier les éléments d’un modèle UML qui ont des variantes. Les éléments marqués avec ce stéréotype sont également marqués avec des valeurs taguées, afin d’identifier quelles sont leurs variantes et quelles décisions un ingénieur doit prendre pour résoudre la variabilité de ces éléments. Cette approche est appliquée sur des diagrammes d’activité UML. Deux approches, l’une proposée par Ternité [Ter09] et l’autre par Ciuksys et Caplinskas [CC07], fournissent un métamodèle permettant de définir une ligne de processus. Le métamodèle proposé par Ternité permet de définir que des éléments de processus sont optionnels, obligatoires, ou alternatifs. Le métamodèle proposé parIngénierie des lignes de processus 49 Ciuksys et Caplinskas permet de spécifier de la variabilité uniquement sur des activités. Il permet de définir qu’une activité est un point de variation, quelles sont ses variantes ainsi que les dépendances entre ses variantes. Les deux métamodèles offrent également des concepts permettant de résoudre la variabilité et de spécifier les opé- rations à réaliser sur la ligne de processus afin d’en dériver un processus. Mais afin d’être concrètement utilisés, ces métamodèles doivent être spécialisés en fonction du langage de modélisation de processus. Plus précisément, les éléments d’un langage de modélisation de processus sur lesquels spécifier de la variabilité doivent hériter de certains des concepts proposés par ces métamodèles. L’approche proposée par Acher et al. [ACG+12] permet de gérer la variabilité des services qui composent un workflow, où un service est un composant qui automatise une activité de ce workflow. Des BFM sont utilisés afin de spécifier la variabilité des services. Afin de lier ces BFM aux services dont ils spécifient la variabilité, chaque service est augmenté avec un identifiant unique. Toutes les approches précédentes sont cependant dépendantes du langage de modélisation de processus utilisé. En effet, afin d’être appliquées, elles nécessitent toutes d’étendre ce langage, mais aucune approche ne propose de mécanisme permettant de réaliser cette extension sans modifier ce langage. L’approche ABIS (Adaptive Business Process Modeling in the Internet of Services) [WKK+11] introduit quant à elle des constructions pour gérer la variabilité dans des processus BPMN, mais sans modifier le métamodèle BPMN. En effet, ces constructions sont instanciées dans un fichier XML différent du fichier dans lequel sont définis les processus BPMN. Ces constructions permettent de définir de la variabilité au niveau d’une activité BPMN ou au niveau d’un attribut d’un élément de modèle BPMN. Des fragments de processus spécifient les différentes valeurs que peut prendre chaque activité variable. Des constructions sont également proposées afin de spécifier comment connecter un fragment de processus à un processus sur lequel de la variabilité est définie. Mais cette approche est dépendante de BPMN, puisque les constructions proposées doivent être adaptées pour être utilisées avec un autre langage de modélisation de processus. Par exemple, il faut définir une correspondance entre les éléments de modèle BPMN et ceux de l’autre langage pour savoir comment réutiliser les constructions proposées par ABIS. 3.2.2.4 Configuration de processus par composition L’approche proposée par Istoan [Ist13] permet de gérer la variabilité sur les aspects comportementaux d’un produit logiciel, alors que les approches actuelles se concentrent plutôt sur la gestion de la variabilité au niveau de la structure de produits logiciels. Le comportement d’un produit logiciel est défini à l’aide d’un processus mé- tier. L’approche proposée permet de définir un ensemble de fragments de processus et de composer ces fragments pour dériver le processus correspondant à un produit logiciel spécifique. Le concept d’interface est introduit afin de spécifier les éléments d’un fragment de processus qui peuvent être connectés avec d’autres fragments de processus et comment ces éléments peuvent être connectés. Cependant, aucun moyen n’est50État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus proposé afin de pouvoir définir des interfaces sans modifier le langage de modélisation de processus utilisé. 3.2.2.5 Association de plusieurs techniques L’approche Configurative Process Modeling [BDKK04] permet de créer différentes vues d’un même modèle de processus afin de ne garder que les informations qui sont pertinentes pour un groupe d’utilisateurs. Mais certains des mécanismes proposés par cette approche peuvent également être utilisés afin de configurer des modèles de processus agrégats. Ainsi, cette approche permet d’associer des termes à des élé- ments d’un modèle afin de spécifier dans quels cas ceux-ci peuvent être sélectionnés. De plus, l’approche Configurative Process Modeling a été étendue afin de permettre la configuration de processus par agrégation (c’est-à-dire par composition de fragments de processus), par instanciation (c’est-à-dire affectation d’une valeur concrète à un concept abstrait) ou par spécialisation (ajout, suppression ou modification d’éléments de modèle) [BDK07]. Cependant, pour être mis en œuvre ces mécanismes requièrent d’étendre le langage de modélisation de processus utilisé, afin de pouvoir associer à des éléments de modèles des informations concernant leurs cas d’utilisation ou afin de pouvoir définir quels sont les éléments qui peuvent être instanciés, spécialisés ou composés avec d’autres éléments. Là encore, aucun moyen n’est proposé afin de réaliser cette extension sans modifier le langage de modélisation de processus utilisé. 3.2.3 Transformation en une structure pivot Les approches de cette catégorie transforment les modèles de processus en des structures pivot sur lesquelles sont définis des mécanismes permettant de définir et de résoudre la variabilité. Une fois la variabilité résolue sur la structure pivot, une transformation de cette structure vers le métamodèle de processus utilisé permet d’obtenir un processus résolu. Les mécanismes nécessaires à la gestion de la variabilité ne sont donc plus couplés aux langages de modélisation de processus. L’approche GV2BPMN (Goal-Oriented Variability Analysis toBPMN) [SCS10] propose de transformer les modèles de processus en des modèles de buts [YLL+08], afin de faciliter la sélection d’un processus d’une famille. Un modèle de buts permet en effet de capturer les différents objectifs qu’un système doit atteindre, ainsi que la variabilité entre ces objectifs. Cette approche permet de gérer la variabilité au niveau du séquencement des unités de travail d’une famille de processus. L’approche de Meerkamm [Mee10] permet de gérer la variabilité au niveau des ressources nécessaires à la réalisation d’une unité de travail, en plus de la variabilité au niveau du séquencement de ces unités de travail. Elle permet de plus de différencier les variantes de processus (qui correspondent à des processus différents d’une même famille) des alternatives, c’est-à-dire des choix qui sont faits au moment de l’exécution d’un processus. Cette approche propose de transformer les modèles de processus en une structure arborescente qui permet de capturer à la fois les unités de travail et leurs ressources, et qui permet de gérer leur variabilité.Ingénierie des lignes de processus 51 L’approche de Kumar et Yao [KY12] permet de gérer la variabilité au niveau du sé- quencement des unités de travail d’un processus et au niveau des ressources liées à ces unités de travail. Elle permet également de découpler la logique métier des processus afin d’éviter la modification des processus lorsque la logique métier change. De plus, elle propose des techniques pour faciliter la recherche et la récupération de variantes de processus stockées dans un dépôt. Afin de gérer la variabilité des processus tout en les découplant de la logique métier, cette approche consiste à appliquer des opérations de modification à un processus afin d’en dériver des variantes. La logique métier est donc capturée dans ces opérations. Ainsi, lorsque cette logique métier change, seules les opérations sont modifiées et pas les processus. Afin que les opérations de modifi- cations puissent être réutilisées quel que soit langage de modélisation de processus, celles-ci sont définies sur une structure arborescente en laquelle sont transformés les modèles de processus. Mais ces approches restent tout de même dépendantes des langages de modélisation de processus. En effet, elles nécessitent la définition d’une transformation pour chaque langage de modélisation de processus. 3.2.4 Spécification de la variabilité sans réutilisation automatique Pour terminer, nous présentons des approches se concentrant sur la spécification de la variabilité d’une famille de processus, mais ne permettant pas la réutilisation automatique des processus de cette famille. L’approche de Razavian et Khosravi [RK08] permet de modéliser la variabilité dans les processus métiers en utilisant UML. Pour ce faire, un profil UML est proposé afin de modéliser la variabilité dans des diagrammes d’activité UML. Ce profil propose plusieurs stéréotypes permettant de spécifier la variabilité au niveau des activités, des flots de contrôle, des données consommées et produites par les activités et des magasins de données (éléments utilisés pour persister les données). Deux types de variabilité peuvent être spécifiés : l’optionnalité et les alternatives. Cette approche ne propose cependant pas de mécanisme permettant de résoudre la variabilité et de dériver un processus en fonction de cette résolution de variabilité. De plus, aucun mécanisme n’est proposé afin de pouvoir appliquer les concepts proposés pour spécifier la variabilité sans modifier le langage de modélisation de processus utilisé. L’approche de Simmonds et Bastarrica [SB11] investigue l’utilisation des BFM et des OVM (Orthogonal Variability Model) [PBL05] afin de spécifier la variabilité des processus. Les BFM sont indépendants du langage de modélisation de processus utilisé. Cependant, ils ne fournissent pas de mécanisme permettant de faire le lien avec les modèles de processus, ce qui empêche de pouvoir dériver un processus en fonction de la résolution de la variabilité spécifiée par le BFM. Les OVM fournissent quant à eux un mécanisme permettant de faire le lien avec un modèle de processus. Mais celui-ci implique de modifier le langage de modélisation de processus utilisé. En effet, afin de pouvoir définir de la variabilité sur les éléments de ce langage, ceux-ci doivent hériter de certains des éléments des OVM. D’autre part, les OVM ne fournissent pas de mécanisme pour dériver un processus.52État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus Afin de faciliter la maintenance d’une famille de processus, l’approche de Derguech et Bhiri [DB10] consiste en l’utilisation d’une structure arborescente afin de définir une famille de processus et propose un support pour mettre à jour cette structure. Les nœuds de la structure arborescente sont des fragments de processus. Lorsqu’un nœud a des enfants, cela signifie que ce nœud est un point de variation et les enfants représentent les différentes variantes de ce point de variation. Cependant, l’aspect sélection et dérivation d’un processus de cette structure arborescente n’est pas traité par cette approche. De plus, aucun mécanisme n’est proposé afin de permettre l’utilisation de cette structure indépendamment du langage de modélisation de processus utilisé. Les travaux de Simidchieva et al. [SCO07] caractérisent ce que devrait comprendre une famille de processus et introduisent une approche formelle pour définir une famille de processus en fonction de cette caractérisation. L’approche consiste à modéliser un processus de base ainsi que les éléments de processus nécessaires à la création d’autres variantes de ce processus. Une variante particulière de processus est obtenue en augmentant le processus de base à l’aide de ces éléments de processus, sélectionnés en fonction d’une spécification de buts de processus. La notion de spécification de buts de processus est proche de la notion d’exigences de projet. Cette approche est assez abstraite pour être indépendante du formalisme utilisé pour définir les processus. Cependant, elle ne fournit pas de mécanisme concret permettant d’obtenir le processus correspondant aux exigences d’un projet. Fiorini et al. [FPLPdL01] proposent une architecture de réutilisation de processus, qui permet d’organiser et de décrire des processus et de les réutiliser. Cette architecture comprend un framework de processus, qui est ici un processus capturant les différents processus d’un domaine. Certaines parties de ce framework peuvent s’appuyer sur des processus standards (par exemple CMM [Ins95]) ou des patrons de processus capturés dans un dépôt. À ce framework sont associées des directives de réutilisation, qui définissent les activités du framework qui sont obligatoires, optionnelles, celles qui doivent être spécialisées, leur contenu... Une activité peut par exemple être spécialisée en utilisant un patron de processus du dépôt, récupéré à l’aide d’une recherche par mots clés. Mais malgré ces directives, la configuration du framework reste manuelle. Il est également possible de récupérer des patrons de processus pour les réutiliser indépendamment du framework. L’architecture est assez abstraite pour être utilisée avec des langages de modélisation de processus différents. 3.2.5 Synthèse sur l’ingénierie des lignes de processus Les approches s’appuyant sur l’ingénierie des lignes de processus afin de réutiliser les processus de développement logiciel sont, à notre connaissance, dépendantes du langage de modélisation utilisé pour définir les processus de la ligne, comme résumé par le tableau 3.4. En effet, certaines utilisent les concepts natifs d’un tel langage pour gérer la variabilité d’une famille de processus. D’autres approches étendent un langage de modélisation de processus existant avec des concepts permettant de gérer la variabilité. Cependant, dans ces deux cas, il peut être nécessaire d’adapter ces concepts pour les utiliser avec un autre langage de modélisation de processus. De plus, la plu-Ingénierie des lignes de processus 53 part de ces approches ne propose pas de mécanisme permettant d’utiliser ces concepts sans modifier un langage de modélisation de processus. Or, la modification d’un tel langage implique que les outils qui lui sont spécifiques (ex : modeleurs) deviennent inutilisables à moins d’être eux-aussi adaptés. D’autres approches résolvent partiellement le problème de la dépendance vis-à-vis du langage de modélisation de processus en transformant les modèles de processus en des structures pivot permettant de gérer la variabilité. Ces approches sont cependant également dépendantes du langage de modélisation de processus. En effet, une transformation doit être définie pour chaque langage. Enfin, quelques approches se concentrent uniquement sur l’aspect spécifi- cation de la variabilité, et certaines d’entre elles sont indépendantes des langages de modélisation de processus. Mais ces approches ne permettent pas la réutilisation automatique des processus dont la variabilité a été spécifiée.54Approche Concepts proposés Apports réutilisation processus Limites État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus réutili- sation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus SPEM 2.0, d’après Alegría et al. [HABQO11] et Alegría et Bastarrica [AB12] Utilisation de SPEM 2.0 Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non KobrA [ABM00] Extension d’un langage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Superimposed Variants [CA05] Extension d’un lan- gage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non C-EPC [RvdA07] Extension d’EPC Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non C-iEPC [RDH+08, LRDtHM11] Extension d’EPC Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non aEPC [RMvdT09] Extension d’EPC Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Configurative Process Modeling [BDK07] Extension d’un langage permettant de définir des mé- thodes d’ingénierie logicielle Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui nonIngénierie des lignes de processus 55 Approche Concepts proposés Apports réutilisation processus Limites réutili- sation processus Déf. des proces- sus en intention Indépendante du formalisme pour définir les processus ADOM [RBSS09, RBSS10] Extension d’un lan- gage de modélisa- tion de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Configurable Workflow [GvdAJVLR08] Extension d’un lan- gage de modélisa- tion de workflows Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Provop (PROcess Variants by OP- tions) [HBR10] Extension d’un lan- gage de modélisa- tion de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non ADORE [MBF13] Extension d’un lan- gage de modélisa- tion de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non vSPEM [MRGP08] Extension de SPEM 2.0 Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Kulkarni et Barat [KB10] Extension de BPMN Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Nguyen et al. [NCH11] Extension de BPMN Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non PESOA [PSWW05] profil UML Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non56Approche Concepts proposés Apports réutilisation processus Limites État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus réutili- sation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus BPFM [MHY08] profil UML Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Ripon et al. [RTM10] profil UML Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Ternité [Ter09] Métamodèle Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Ciuksys et Caplinskas [CC07] Métamodèle Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Acher et al. [ACG+12] Extension des services qui composant un workflow Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non ABIS [WKK+11] Extension de BPMN Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Istoan [Ist13] Extension d’un langage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Configurative Process Modeling [BDK07] Extension d’un langage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui nonIngénierie des lignes de processus 57 Approche Concepts proposés Apports réutilisation processus Limites réutili- sation processus Déf. des proces- sus en intention Indépendante du formalisme pour définir les processus GV2BPMN [SCS10] Transformation de modèles de proces- sus en modèles de buts Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Meerkamm [Mee10] Transformation des modèles de proces- sus en une structure arborescente Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Kumar et Yao [KY12] Transformation d’un processus en une structure arborescente Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Razavian et Khosravi [RK08] profil UML pour spécifier la variabi- lité dans les dia- grammes d’activités spécification de la variabilité des processus résolution de la va- riabilité, dériva- tion de processus oui non Simmonds et Bas- tarrica [SB11] BFM et OVM pour spécifier la variabi- lité des processus spécification de la variabilité des processus dérivation de proces- sus oui oui BFM, non OVM58Approche Concepts proposés Apports réutilisation processus Limites État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus réutili- sation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus Derguech et Bhiri [DB10] Structure arborescente pour définir une famille de processus spécification de la variabilité des processus résolution de la variabilité, dérivation de processus oui non Simidchieva et al. [SCO07] Caractérisation du contenu d’une famille de processus et approche pour définir une telle famille spécification de la variabilité des processus dérivation de processus oui oui Fiorini et al. [FPLPdL01] Architecture de réutilisation de processus spécification de la variabilité des processus dérivation de processus oui oui Table 3.4 – Évaluation des approches s’appuyant sur l’ingénierie des lignes de processusSynthèse 59 3.3 Synthèse L’approche de Sadovykh et Abherve permet de savoir à quels moments d’un projet réutiliser des automatisations de TMR. Cette approche ne permet cependant pas de savoir pour quels projets réutiliser des automatisations de TMR. Une solution consiste donc à réutiliser les processus de développement logiciel afin de réutiliser les automatisations de TMR qui leurs sont liées. Parmi les approches supportant la réutilisation des processus de développement logiciel, certaines ne sont pas suffisantes pour mettre en œuvre cette réutilisation. D’autres approches permettent effectivement de réutiliser les processus de développement logiciel. Cependant, soit celles-ci ne proposent pas de mécanisme pour définir les processus en intention, soit elles sont dépendantes du langage de modélisation de processus utilisé. Le tableau 3.5 résume dans quelle catégorie se trouve chaque approche supportant la réutilisation des processus. En conclusion, aucune des approches existantes ne permet de définir un ensemble de processus en intention et de dériver un processus de cet ensemble, tout en étant indépendante du formalisme utilisé pour définir les processus. De plus, aucune approche ne traite la problématique de l’automatisation des processus de développement logiciel réutilisés, ce qui est loin d’être trivial. En effet, les contraintes d’un projet peuvent imposer de commencer l’exécution d’un processus alors que toutes les exigences de ce projet ne sont pas encore déterminées. Par exemple, afin de gagner du temps, il est possible de commencer l’exécution d’un processus de développement d’une application web Java (par exemple en écrivant les spécifications fonctionnelles) alors que le framework pour l’IHM de l’application à développer (par exemple Struts, JSF, Flex ou GWT) n’est pas encore choisi. Mais comment exécuter un processus s’il n’est que partiellement défini à cause des exigences non déterminées ? Approche Suffisante 1pour la réutilisation de processus Définition des processus en intention Indépendante du formalisme pour définir les processus Promote [CDCC+13] non non oui Pérez et al. [PEM95] non non oui Alexander et Davis [AD91] non non oui Sharon et al. [SdSSB+10] non non oui Lu et Sadiq [LS07] oui non non Song et Osterweil [SO98] oui non oui Intelligent Workflow Designer [IMCH+07] non non non Design by Selection [ASKW11] non non non CAT [KSG04] non non non60État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus Approche Suffisante 1pour la réutilisation de processus Définition des processus en intention Indépendante du formalisme pour définir les processus Aldin [Ald10] non non oui SPEM 2.0, d’après Alegría et al. [HABQO11] et Alegría et Bastarrica [AB12] oui oui non KobrA [ABM00] oui oui non C-EPC [RvdA07] oui oui non C-iEPC [RDH+08, LRDtHM11] oui oui non aEPC [RMvdT09] oui oui non Configurative Process Modeling [BDK07] oui oui non Superimposed Variants [CA05] oui oui non ADOM [RBSS09, RBSS10] oui oui non Configurable Work- flow [GvdAJVLR08] oui oui non Provop (PROcess Variants by OPtions) [HBR10] oui oui non vSPEM [MRGP08] oui oui non Kulkarni et Barat [KB10] oui oui non Nguyen et al. [NCH11] oui oui non PESOA [PSWW05] oui oui non BPFM [MHY08] oui oui non Ripon et al. [RTM10] oui oui non Ternité [Ter09] oui oui non Ciuksys et Caplinskas [CC07] oui oui non Acher et al. [ACG+12] oui oui non ABIS [WKK+11] oui oui non Configurative Process Modeling [BDK07] oui oui non Istoan [Ist13] oui oui nonSynthèse 61 Approche Suffisante 1pour la réutilisation de processus Définition des processus en intention Indépendante du formalisme pour définir les processus ADORE [MBF13] oui oui non GV2BPMN [SCS10] oui oui non Meerkamm [Mee10] oui oui non Kumar et Yao [KY12] oui oui non Razavian et Khosravi [RK08] non oui non Simmonds et Bastarrica [SB11] non oui oui BFM, non OVM Derguech et Bhiri [DB10] non oui non Simidchieva et al. [SCO07] non oui oui Fiorini et al. [FPLPdL01] non oui oui Table 3.5 – Évaluation de l’ensemble des approches supportant la réutilisation des processus Concernant la capacité des automatisations de TMR à être réutilisées à travers leurs différents cas d’utilisation, certaines approches supportent le développement de composants logiciels réutilisables. Par exemple, l’ingénierie des lignes de produits logiciels [PBL05] s’appuie sur la spécification de la variabilité de produits logiciels afin de produire des artéfacts de développement réutilisables. Plusieurs approches permettent d’implémenter des artéfacts réutilisables, comme par exemple la programmation orientée objet [Cox85], la programmation orientée aspect [CB05] ou encore l’ingénierie logicielle basée sur les composants [Crn02]. Mais pour être appliquées ces approches requièrent toutes au préalable d’avoir identifié la variabilité des artéfacts de développement, ce qu’elles ne permettent pas de faire. Des approches permettent quant à elle d’identifier la variabilité de composants logiciels. FORM (Feature-Oriented Reuse Method) [KKL+98] est une méthodologie mettant en œuvre l’ingénierie des lignes de produits logiciels. À ce titre, elle supporte la conception et le développement d’architectures et de composants réutilisables, et le développement de produits logiciels à partir de ces artéfacts. FORM fournit des directives permettant d’identifier la variabilité des artéfacts de développement qui réalisent des produits logiciels, en fonction de la spécification de la variabilité de ces produits logiciels. Un BFM est utilisé pour spécifier la variabilité d’un produit logiciel et l’identification de la variabilité d’un composant logiciel est basée sur l’analyse de la hiérarchie du BFM. Un exemple de directive proposée par FORM est que la hiérarchie des composants qui réalisent un produit logiciel correspond en grande partie à la 1. Comme défini page 36, une approche est suffisante pour la réutilisation de processus si elle permet de définir un ensemble de processus et de dériver un processus de cet ensemble.62État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus hiérarchie du BFM. L’approche de Lee et Kang [LK04] étend l’approche FORM et s’appuie sur l’analyse des dépendances opérationnelles entre les caractéristiques capturées par le BFM (c’est- à-dire lorsque la réalisation d’une caractéristique dépend de la réalisation d’autres caractéristiques) afin d’identifier la variabilité d’un composant logiciel. Un exemple de directive proposée par cette approche est que des caractéristiques alternatives peuvent implémenter une interface commune. L’approche de Lee et al. [LKCC00] étend elle aussi l’approche FORM afin d’identi- fier des objets réutilisables pour l’implémentation de composants à partir de l’analyse d’un BFM. Un exemple de directive est que des catégories d’objets peuvent être dé- duites de catégories de caractéristiques. Dans le cas de l’application de ces approches à des automatisations de TMR qui réalisent des processus de développement logiciel, le BFM spécifierait la variabilité d’une famille de processus et les automatisations de TMR seraient les composants logiciels dont la variabilité doit être identifiée. Cependant, il ne serait pas possible de réutiliser les directives proposées par ces approches telles qu’elles sont. En effet, chaque caractéristique du BFM (correspondant dans ce cas à un fragment de processus) n’est pas systématiquement réalisée par une automatisation de TMR. Ces approches ne sont donc pas adaptées pour identifier la variabilité d’automatisations de TMR. Une autre méthode permet d’identifier les parties réutilisables d’un composant en identifiant les parties communes entre les variantes des points de variation de ce composant [ZXD05]. Mais cette méthode requière au préalable d’avoir identifié les points de variation et les variantes d’un composant. Cette méthode permet donc d’aller plus loin dans l’identification de la variabilité d’un composant, mais ne peut pas être appliquée si des parties variables et communes d’un composant n’ont pas déjà été identifiées. En conclusion, il manque une approche permettant de réutiliser les processus de développement logiciel qui soit à la fois indépendante du langage de modélisation de processus utilisé, qui offre les mécanismes nécessaires à la définition en intention d’un ensemble de processus, et qui intègre réutilisation et automatisation des processus. Il manque également une approche permettant d’identifier la variabilité d’automatisations de TMR.Deuxième partie Automatisation des tâches manuelles récurrentes pilotée par les processus de développement logiciel 6365 Les travaux présentés dans cette partie ont fait l’objet d’une publication : Emmanuelle Rouillé, Benoît Combemale, Olivier Barais, David Touzet and Jean-Marc Jézéquel. Integrating Software Process Reuse and Automation. In Proceedings of the 20th Asia-Pacific Software Engineering Conference, APSEC ’13, 2013 [RCB+13b]. Nous présentons dans cette partie la contribution principale de cette thèse, à savoir notre approche pilotant la réutilisation d’automatisations de TMR (Tâches Manuelles Récurrentes) par les processus de développement logiciel. La figure 3.4 illustre le principe général de cette approche. Figure 3.4 – Principe général de la contribution principale La réutilisation des automatisations de TMR consiste dans notre approche à réutiliser les processus de développement logiciel auxquels ces automatisations sont liées. Notre approche s’appuie sur l’ingénierie des lignes de processus afin de réutiliser les processus de développement logiciel. Une ligne de processus est définie en intention et un processus peut être réutilisé en le dérivant de cette ligne, en fonction des exigences des projets. L’ingénierie des lignes de processus permet non seulement de réutiliser les processus de développement logiciel, mais également tous les fragments de processus communs à plusieurs processus, puisque ceux-ci sont factorisés (définition en intention). De plus, la définition en intention d’une famille de processus permet d’en faciliter66 la maintenance, puisque les fragments de processus communs à plusieurs processus ne sont mis à jour qu’une seule fois en cas d’évolution. D’autres part, comme des langages de modélisation de processus de développement logiciel différents sont utilisés en fonction des exigences des utilisateurs [Zam01], nous proposons, dans le chapitre 4, une approche permettant de gérer la variabilité dans les processus de développement logiciel qui est indépendante du langage de modélisation de processus utilisé. Les TMR à automatiser étant des tâches réalisées par ordinateur, nous utilisons des composants logiciels afin de les automatiser. Dans la suite de cette thèse, nous appelons composants d’automatisation (CA) un composant logiciel automatisant une TMR. Ces CA sont reliés aux unités de travail (tâches, activités...) des processus de la ligne de processus qu’ils automatisent. Cependant, un CA peut être lié à des unités de travail différentes, appartenant ou non à un même processus, ce qui peut induire de la variabilité au niveau de ce CA. Par exemple, un CA qui met du code source sous contrôle de version peut être utilisé lors de projets différents, pour lesquels le dépôt distant sur lequel partager le code source n’est pas le même. Nous proposons donc, dans le chapitre 5, une méthodologie fournissant un support à la création de CA qui soient réutilisables pour toutes les unités de travail auxquelles ils sont liés. Un processus dérivé de la ligne de processus est automatisé en lançant au fur et à mesure de son exécution les CA qui lui sont liés. Le lien entre ces CA et les unités de travail du processus qu’ils automatisent permet de savoir à quel moment de l’exécution du processus exécuter les différents CA.Chapitre 4 Gestion de la variabilité dans les processus Nous présentons dans ce chapitre notre approche permettant de gérer la variabilité dans les processus de développement logiciel indépendamment du langage utilisé pour les définir. Nous commençons par introduire dans la section 4.1 l’exemple dont nous nous servons pour illustrer cette approche. La section 4.2 détaille ensuite l’approche en elle-même. Nous discutons cette approche dans la section 4.3 et nous en faisons la synthèse dans la section 4.4. Les travaux présentés dans ce chapitre ont fait l’objet d’une publication : Emmanuelle Rouillé, Benoît Combemale, Olivier Barais, David Touzet and Jean-Marc Jézéquel. Leveraging CVL to Manage Variability in Software Process Lines. In Proceedings of the 19th Asia-Pacific Software Engineering Conference, APSEC ’12, pages 148-157, 2012 [RCB+12]. 4.1 Exemple illustratif : une famille de processus de métamodélisation Nous introduisons dans cette section un exemple de famille de processus, que nous utilisons ensuite pour illustrer l’approche proposée dans ce chapitre. Il s’agit d’une famille simplifiée de processus de métamodélisation, issue de l’équipe de recherche Triskell 1 , au sein de laquelle cette thèse a été réalisée. Un processus de métamodélisation consiste à définir et outiller un langage de modélisation spécifique à l’expression d’une préoccupation particulière, en tirant parti pour ce faire des concepts et outils 1. http://triskell.irisa.fr/ 6768 Gestion de la variabilité dans les processus Figure 4.1 – Flot de tâches de l’exemple illustratif de processus de métamodélisation Figure 4.2 – Ressources de l’exemple illustratif de processus de métamodélisation du domaine de l’IDM. Un tel langage permet de mettre en œuvre la séparation des préoccupations et ainsi maîtriser la complexité des systèmes logiciels [JCV12]. Nous introduisons d’abord un exemple simplifié de processus de métamodélisation, illustré par les figures 4.1 et 4.2. Plus précisément, la figure 4.1 illustre le flot de tâches de ce processus, tandis que la figure 4.2 illustre les ressources (outils, entrées et sorties) quiApproche 69 entrent en jeu lors de la réalisation de ces tâches. Nous détaillons ensuite des exemples de variantes de ce processus. L’exemple de processus de métamodélisation présenté ici est un processus itératif qui commence avec la définition d’un métamodèle. Des tâches parallèles suivent la définition de ce métamodèle : définition d’un éditeur textuel et d’un éditeur arborescent permettant la création de modèles conformes au métamodèle, définition d’un vérificateur permettant de vérifier qu’un modèle est bien conforme à son métamodèle, définition d’un interpréteur et définition d’un compilateur. L’outil utilisé pour définir le métamodèle et l’éditeur arborescent est EMF 2 . L’outil XText 3 est utilisé pour définir l’éditeur textuel. L’outil utilisé pour définir le vérificateur, l’interpréteur et le compilateur est Kermeta 4 , un environnement de métamodélisation. L’interpréteur est mis sous contrôle de version en utilisant SVN. Il existe des variantes de ce processus de métamodélisation. Par exemple, en fonction des exigences des projets, les tâches de définition d’un éditeur textuel ou arborescent, d’un interpréteur, d’un compilateur et d’un vérificateur peuvent ne pas avoir lieu. D’autre part, toujours selon les exigences des projets, l’outil EMFText 5 peut être utilisé à la place de XText et Git peut remplacer SVN. 4.2 Approche Des langages de modélisation de processus différents peuvent être utilisés en fonction des exigences de leurs utilisateurs. Il est donc intéressant, à des fins de réutilisation, d’avoir une approche permettant de gérer la variabilité dans les processus qui soit indépendante de ces langages. Par indépendante nous entendons qu’une approche n’ait pas à être adaptée pour être utilisée avec des langages de modélisation de processus différents et qu’elle ne nécessite pas non plus de modifier ces langages. Cela permet de pouvoir réutiliser à la fois l’approche et les langages de modélisation de processus, ainsi que les outils associés. Nous avons vu en section 2.3.2 que CVL était un langage permettant de spécifier et de résoudre de la variabilité sur des modèles, quel que soit leur métamodèle pour peu qu’il se conforme au MOF. Nous utilisons donc ici CVL afin de gérer la variabilité dans les processus de développement logiciel indépendamment de leur langage de modélisation. Nous présentons dans ce chapitre notre approche, appelée CVL4SP (CVL for Software Processes). Il s’agit de la première sous-contribution de cette thèse. La figure 4.3 illustre la partie de la contribution principale que nous détaillons ici. 2. http://www.eclipse.org/modeling/emf/ 3. http://www.eclipse.org/Xtext/ 4. http://www.kermeta.org/ 5. http://www.emftext.org70 Gestion de la variabilité dans les processus Figure 4.3 – Partie de la contribution principale réalisée par CVL4SP Figure 4.4 – Apperçu de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logicielApproche 71 Figure 4.5 – Processus de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logiciel72 Gestion de la variabilité dans les processus Comme illustré par la figure 4.4, le principe général de CVL4SP consiste à utiliser le VAM (Variability Abstraction Model, cf. section 2.3.2) de CVL afin de capturer la variabilité des exigences des projets. Nous utilisons le modèle de base de CVL afin de capturer les éléments de processus nécessaires pour définir la famille de processus attendue. Ce modèle de base devient alors un modèle de processus de base. Grâce au VRM (Variability Realization Model, cf. section 2.3.2) de CVL, nous faisons le lien entre la variabilité des exigences des projets capturée dans le VAM et les éléments de processus du modèle de processus de base. Plus précisément, nous utilisons le VRM afin de définir comment dériver un processus du modèle de processus de base en fonction des exigences des projets. Nous utilisons le RM (Resolution Model, cf. section 2.3.2) afin de sélectionner les exigences pour un projet donné. Enfin, le modèle résolu de CVL contient le processus dérivé du modèle de processus de base en fonction des exigences sélectionnées dans le RM. On parle alors de modèle de processus résolu. Notre approche préserve la séparation entre les exigences des projets et les processus, puisque les aspects exigences et processus sont définis dans des modèles distincts (le VAM et le modèle de processus de base), qui ne sont pas liés directement l’un à l’autre mais par l’intermédiaire du VRM. Cela permet donc de pouvoir réutiliser et faire évoluer les aspects exigences et processus indépendamment l’un de l’autre. De plus, en capturant dans le VAM la variabilité des exigences des projets et non la variabilité des processus, notre approche permet de relier directement les exigences des projets aux processus, en évitant une couche intermédiaire de définition de la variabilité des processus. La figure 4.5 présente le processus de notre approche. Elle implique deux rôles : un expert processus, qui connaît les différents processus d’une entreprise ainsi que leurs contextes d’utilisation, et un utilisateur d’une ligne de processus, qui est impliqué dans un projet et a besoin d’un processus spécifique à ce projet. L’expert processus capture la variabilité des exigences des projets et fait le lien entre ces exigences et une ligne de processus (étapes 1 à 3). Ensuite, l’utilisateur de cette ligne de processus lance la dérivation automatique d’un processus (de cette ligne) en fonction des exigences d’un projet spécifique (étapes 4 et 5). Les étapes 4 et 5 ont lieu à chaque fois qu’un utilisateur d’une ligne de processus souhaite dériver un processus. L’expert processus et l’utilisateur d’une ligne de processus utilisent l’outillage associé à CVL pour réaliser les étapes 2 à 5. N’importe quel langage de modélisation de processus de développement logiciel peut être utilisé pour réaliser l’étape 1. Nous détaillons dans la suite de cette section les différentes étapes de notre approche. Nous les illustrons à l’aide de l’exemple illustratif introduit dans la section 4.1. 4.2.1 Définition de la ligne de processus de développement logiciel 4.2.1.1 Méthodologie pour la modélisation des éléments de processus (étape 1) Approche L’expert processus modélise ici les éléments de processus requis pour définir la famille de processus attendue. Dans un premier temps, l’expert processus modélise, dans un modèle de processusApproche 73 de base, le processus de l’entreprise le plus souvent utilisé. Nous ne traitons pas dans cette thèse de la manière de déterminer le processus le plus souvent utilisé. Ensuite, l’expert processus modélise tous les autres éléments de processus qui n’appartiennent pas au processus le plus souvent utilisé et qui sont requis pour créer des variantes de ce processus. Dans la suite, nous appellerons ces éléments de processus des éléments de processus externes. Ces éléments de processus externes sont ajoutés au modèle contenant le processus le plus souvent utilisé (c’est-à-dire le modèle de processus de base), mais sans les relier à ce processus. Même si plusieurs processus utilisent un même élément de processus externe, celui-ci n’est modélisé qu’une seule fois dans le modèle de processus de base, afin de respecter la définition en intention de processus. De ce fait, quand un élément de processus commun à plusieurs processus évolue, il ne faut le mettre à jour qu’une seule fois. Quand différents processus utilisent un même élément de processus externe, ils peuvent requérir différentes valeurs pour les propriétés de cet élément de processus externe. Dans ce cas, dans le modèle de processus de base, l’expert processus affecte aux propriétés de cet élément de processus les valeurs correspondant au processus le plus utilisé parmi les processus qui utilisent cet élément de processus externe. Nous détaillons maintenant comment notre méthodologie s’applique dans le cas de la modélisation avec SPEM 2.0. L’expert processus commence par modéliser les éléments de contenu de méthode qui serviront à définir le processus le plus souvent utilisé ainsi que les éléments de processus externes. L’expert processus modélise ensuite le processus le plus souvent utilisé ainsi que les éléments de processus externes dans différentes activités représentant des processus. De cette manière, il n’y a pas d’opération à effectuer sur le modèle de processus de base pour dériver le processus le plus souvent utilisé. En effet, en SPEM 2.0, un processus décrivant le cycle de vie complet d’un projet est décrit dans un type d’activité particulier, le processus. De cette manière, le processus le plus souvent utilisé est déjà décrit dans ce type d’activité. Il est possible de modéliser le processus de base différemment. Par exemple, toutes les variantes de processus peuvent être modélisées dans le même processus en utilisant des branchements conditionnels. Il est également possible de modéliser des éléments de processus sans modéliser les relations entre eux et de les composer au moment de la dérivation. Une autre possibilité est de modéliser le processus commun à tous les processus d’une famille ainsi que les éléments de processus qui varient, sans les relier au processus commun. Par rapport à ces autres approches, notre méthodologie permet à un humain de visualiser directement au moins un processus d’une famille, qui plus est le processus le plus souvent utilisé de cette famille. Illustration Nous détaillons maintenant le modèle de processus de base dans le cas de l’exemple illustratif de la famille de processus de métamodélisation. La figure 4.6 illustre les éléments de contenu de méthode de la famille de processus de métamodélisation. La définition de tâche définir métamodèle produit en sortie la définition de produit de travail métamodèle et requiert l’utilisation de l’outil EMF. Les définitions de tâche définir éditeur arborescent, définir éditeur textuel, définir vérificateur, définir compilateur et définir interpréteur prennent en entrée la définition de produit de travail métamodèle, et74 Gestion de la variabilité dans les processus produisent respectivement en sortie les définitions de produit de travail éditeur arborescent, éditeur textuel, vérificateur, compilateur et interpréteur. Comme pour les éléments de processus externes, on ne modélise que les propriétés correspondant au processus le plus utilisé qui utilise ces éléments de contenu de méthode. Ainsi, la définition de tâche définir éditeur textuel utilise la définition d’outil XText et non pas la définition d’outil EMFText, et la définition de tâche définir interpréteur utilise la définition d’outil SVN et non pas Git. Figure 4.6 – Eléments de contenu de méthode de l’exemple illustratif Comme illustré par la figure 4.7, le processus le plus utilisé de la famille de processus de métamodélisation consiste uniquement en la définition d’un métamodèle et d’un éditeur arborescent. Figure 4.7 – Processus le plus souvent utilisé de l’exemple illustratif La figure 4.8 illustre les fragments de processus représentant les éléments de processus externes de la famille de processus de métamodélisation. Ces éléments de processusApproche 75 externes sont les tâches définir éditeur textuel, définir vérificateur, définir interpréteur et définir compilateur, avec leurs produits de travail respectifs (éditeur textuel, vérificateur, interpréteur et compilateur). Les éléments de processus externes comprennent également un nœud de jointure et un nœud de parallélisation, ainsi que les flots de contrôle nécessaires à la dérivation de processus de métamodélisation autres que celui qui est le plus utilisé. Figure 4.8 – Eléments de processus externes de l’exemple illustratif 4.2.1.2 Spécification de la variabilité des exigences des projets (étape 2) Approche Dans la seconde partie de notre approche, l’expert processus s’appuie sur le VAM de CVL afin de spécifier la variabilité des exigences des projets. Illustration La figure 4.9 présente un extrait du VAM des exigences des différents projets de métamodélisation de l’exemple illustratif. On y voit que les définitions d’un interpréteur, d’un compilateur, d’un vérificateur, d’un éditeur arborescent ainsi que d’un éditeur textuel (respectivement représentées par les choix interpréteur, compilateur, vérificateur, éditeur arborescent et éditeur textuel) sont des tâches optionnelles. La définition d’un éditeur textuel peut être réalisée soit avec l’outil XText soit avec l’outil EMFText (respectivement représentés par les choix XText et EMFText). L’utilisation d’un SCV (Système de Contrôle de Version), représenté par le choix SCV, est obligatoire, et il s’agit soit de SVN, soit de Git (respectivement représentés par les choix SVN et Git). Ce VAM contient également des choix dont la résolution est dérivée (éditeur textuel parallèle, vérificateur parallèle, compilateur parallèle, interpréteur parallèle, éditeur arborescent parallèle et parallélisation). Le choix parallélisation est automatiquement sélectionné lorqu’au moins deux tâches optionnelles de la famille de processus de métamodélisation sont sélectionnées. Chacun des choix éditeur textuel parallèle, vérifi- cateur parallèle, compilateur parallèle, interpréteur parallèle et éditeur arborescent parallèle est76 Gestion de la variabilité dans les processus automatiquement sélectionné si le choix parallélisation est sélectionné et si le choix de nom correspondant (c’est-à-dire éditeur textuel pour éditeur textuel parallèle, vérificateur pour vérificateur parallèle, ...) est également sélectionné. Ces choix dont la résolution est dérivée ne reflètent pas la variabilité au niveau des exigences des projets. Nous allons voir par la suite qu’ils sont utiles pour savoir quelles opérations effectuer sur le modèle de processus de base afin de dériver un processus. Figure 4.9 – Extrait du VAM de l’exemple illustratif 4.2.1.3 Liaison entre les exigences des projets et les processus (étape 3) Approche Dans la troisième étape de notre approche, l’expert processus définit dans un VRM la liaison entre la variabilité des exigences des projets (définie à l’étape 2 dans le VAM) et les processus (définis à l’étape 1 dans le modèle de processus de base). Le VRM spécifie comment dériver un processus du modèle de processus de base en fonction des exigences des projets. Illustration La figure 4.10 représente un extrait du VRM de l’exemple illustratif suffisant pour dériver un processus de métamodélisation avec définition d’un éditeur arborescent et d’un interpréteur. Pour des raisons de lisibilité, nous avons scindé ce VRM en deux dans les sous-figures 4.10(a) et 4.10(b). Dans la sous-figure 4.10(a), l’activité métamodélisation représente le processus le plus souvent utilisé. La première série d’opérations consiste à mettre dans ce processus les éléments de processus externes dont on a besoin pour dériver un processus en fonction des exigences. Ainsi, si le choix interpréteur est sélectionné, alors il faut mettre la tâche définir interpréteur, ses flots de contrôle entrants et sortants, ainsi que le produit de travail interpréteur dans l’activité métamodélisation. Si le choix parallélisation est sélectionné, cela signifie qu’au moins deux tâches optionnelles auront été sélectionnées et donc que le processus dérivé contiendra de la parallélisation car les tâches optionnelles sont exécutées en parallèle dans notre exemple. Il faut donc, dans ce cas, mettre le nœud de parallélisation, son flot de contrôle entrant, le nœud de jointure et son flot de contrôle sortant dans l’activité métamodélisation. Détaillons maintenant la sous-figure 4.10(b). Si le choix parallélisation est sélectionné,Approche 77 alors la source du flot de contrôle entrant du nœud de parallélisation doit être affectée à la tâche définir métamodèle. Le flot de contrôle sortant du nœud de jointure doit de plus être affecté au nœud de décision. Si le choix éditeur arborescent parallèle est sélectionné, cela signifie que le processus dérivé contiendra des tâches parallèles, et que la tâche définir éditeur arborescent en fera partie. Il faut donc, dans ce cas, affecter la source du flot de contrôle entrant de la tâche définir éditeur arborescent au nœud de parallélisation et il faut affecter la cible du flot de contrôle sortant de la tâche définir éditeur arborescent au nœud de jointure. De manière similaire, si le choix interpréteur parallèle est sélectionné, alors il faut affecter la source du flot de contrôle entrant de la tâche définir interpréteur au nœud de parallélisation et il faut affecter la cible du flot de contrôle sortant de la tâche définir interpréteur au nœud de jointure. Enfin, si l’outil Git est sélectionné (choix Git sélectionné), alors il faut remplacer l’outil SVN par l’outil Git. (a) Première partie du VRM (b) Deuxième partie du VRM Figure 4.10 – Extrait du VRM de l’exemple illustratif78 Gestion de la variabilité dans les processus 4.2.2 Dérivation d’un processus en fonction des exigences d’un projet 4.2.2.1 Résolution de la variabilité des exigences des projets (étape 4) Approche Un utilisateur de la ligne de processus précédemment définie résout la variabilité des exigences des projets. Il sélectionne pour ce faire dans le RM de CVL les exigences pour un projet donné, parmi les exigences spécifiées dans le VAM. Illustration La figure 4.11 présente un extrait du RM pour un processus de métamodélisation, avec uniquement éditeur arborescent, interpréteur et SVN comme choix sélectionnés. Les choix dérivés sont automatiquement résolus en fonction de la résolution des autres choix. Ici, seuls les choix dérivés parallélisation, interpreteur parallèle et éditeur arborescent parallèle sont sélectionnés. Figure 4.11 – Extrait du RM de l’exemple illustratif 4.2.2.2 Dérivation automatique de processus (étape 5) Approche La dernière étape de notre approche consiste à dériver automatiquement le processus correspondant aux exigences d’un projet donné. Dans ce but, nous utilisons le moteur de dérivation de CVL afin de permettre à l’utilisateur de la ligne de processus de dériver un modèle de processus depuis le modèle de processus de base (étape 1), en fonction i) des exigences sélectionnées dans le RM (étape 4), et ii) de la réalisation de la variabilité capturée dans le VRM (étape 3). Cette étape produit un modèle de processus résolu. Si un projet a des besoins spécifiques qui ne se retrouvent pas dans d’autres projets, alors l’utilisateur de la ligne de processus peut adapter manuellement le modèle de processus résolu à ces besoins, à l’issue de la dérivation automatique de ce modèle de processus. En effet, il n’est pas utile de capitaliser des besoins spécifiques à un projet dans une ligne de processus si ces besoins ne se retrouvent pas dans d’autres projets. Illustration Comme illustré par la figure 4.12, le processus résolu correspondant au RM de la figure 4.11 est un processus de métamodélisation avec les étapes de définitionApproche 79 d’un métamodèle, d’un éditeur arborescent, d’un interpréteur, et avec le SCV SVN. Figure 4.12 – Modèle de processus résolu 4.2.3 Exécution d’un processus résolu La difficulté au moment de l’exécution d’un processus dérivé d’une ligne de processus réside dans le fait qu’en fonction des contraintes d’un projet, ce processus peut être exécuté alors que sa variabilité n’est que partiellement résolue. Par exemple, afin de gagner du temps, il est possible de démarrer l’exécution d’un processus de développement d’une application web en Java (par exemple en écrivant les spécifications fonctionnelles) alors que le framework pour l’IHM de l’application à développer (par exemple Struts 6, JSF 7 (Java Server Faces), Flex 8 ou GWT 9 (Google Web Toolkit)) n’a pas encore été choisi. Dans ce cas, l’automatisation de l’exécution du processus peut donner lieu à des erreurs à cause de la variabilité non résolue. En effet, si une partie d’un processus contient de la variabilité non résolue, alors : – soit cette partie de processus est dans un état où elle n’est pas exécutable par un outil, car elle possède des éléments considérés comme invalides par cet outil (par exemple un flot de contrôle qui ne pointe vers rien) ; – soit cette partie est dans un état exécutable, mais qui ne correspond pas à l’état dans lequel elle aurait dû être si la variabilité avait été résolue. Dans ce cas, le résultat de l’exécution ne sera pas celui attendu. Afin de gérer les cas où la variabilité du processus en cours d’exécution n’est que partiellement résolue, notre approche consiste à demander à l’acteur courant du processus de résoudre la variabilité d’un fragment de processus dont la variabilité n’est que partiellement résolue au moment de l’exécution de ce fragment. 6. http://struts.apache.org/ 7. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 8. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 9. http://www.gwtproject.org/80 Gestion de la variabilité dans les processus 4.3 Discussion Nous discutons dans cette section de la capacité de CVL à gérer la variabilité des processus en fonction de la variabilité des exigences des projets (section 4.3.1), de l’indépendance de CVL vis-à-vis des métamodèle de processus (section 4.3.2), de la validité du modèle de processus résolu (section 4.3.3), ainsi que des extensions possibles à la méthodologie proposée pour définir le modèle de processus de base (section 4.3.4). 4.3.1 Capacité de CVL à gérer la variabilité des processus en fonction de la variabilité des exigences des projets Selon notre approche, le VAM capture la variabilité des exigences des projets, tandis que le VRM spécifie le lien entre cette variabilité des exigences et le modèle de processus de base. Le VRM permet de refléter directement la variabilité des exigences des projets sur les processus. Ces trois modèles (VAM, VRM et modèle de processus de base) constituent donc la définition d’une ligne de processus de développement logiciel. CVL permet ensuite à un utilisateur de cette ligne de processus i) de sélectionner les exigences pour un projet donné dans un RM et ii) de dériver automatiquement un modèle de processus depuis le modèle de processus de base en fonction de ce RM. CVL permet donc bien de gérer la variabilité des processus de développement logiciel en fonction de la variabilité des exigences des projets. 4.3.2 Indépendance de CVL vis-à-vis des métamodèles de processus Actuellement, le seul lien entre CVL et les modèles métiers pour lesquels il permet de gérer la variabilité est fait par l’intermédiaire des points de variation, qui permettent de faire des références aux éléments du modèle de base. Ces références sont faiblement couplées aux éléments du modèle de base. En effet, CVL utilise une chaîne de caractères dans les éléments de modèle de type ObjectHandle et LinkHandle pour référencer les éléments du modèle de base. Dans son état actuel, CVL est donc bien indépendant du langage sur lequel il s’applique. Nous allons cependant voir dans la section suivante que le couplage faible entre CVL et les langages sur lesquels il s’applique peut être à l’origine d’erreurs dans le modèle de processus résolu. 4.3.3 Validité du modèle de processus résolu Nous avons observé que l’opérateur de dérivation de CVL pouvait produire un modèle de processus résolu invalide (c’est-à-dire non conforme à son métamodèle), alors que les VAM, VRM et RM sont valides. Dans la suite de cette section, nous identifions les sources possibles de cette invalidité, et nous les classifions en fonction de la manière de les éviter. Le premier type d’erreur que nous avons observé concerne les affectations (affectation d’attribut, paramétrable ou non) ou les substitutions (substitution de fin de lien,Discussion 81 substitution de fin de lien paramétrable, substitution d’objet, substitution d’objet paramétrable, substitution de fragment) qui ne respectent pas la compatibilité de type avec le modèle de base. Ces erreurs constituent la première catégorie que nous avons identifiée. Elles ont lieu parce que CVL ne contraint pas la spécification du VRM en fonction du métamodèle auquel il s’applique. L’expression de contraintes génériques sur le métamodèle de CVL permettrait d’assurer la validité du VRM par rapport au métamodèle du modèle auquel il s’applique. Par exemple, le problème de compatibilité de type mentionné plus haut dans le contexte d’une substitution de fin de lien pourrait être évité en utilisant la contrainte suivante exprimée avec OCL (Object Constraint Language) [OMG10] sur le métamodèle de CVL : 1 c on t e x t LinkEndSubstitution inv: 2 -- où ’find ’ résoud l’URI d’un élément de modèle , ’getRef ’ retourne la référence , dont le nom est passé en paramètre , de l’élément de modèle sur lequel est appelée la fonction , ’OclType ’ retourne le type de l’élément de modèle sur lequel il est appelé et ’isOfType ’ retourne vrai si le type sur lequel il s’applique est du même type que le type passé en paramètre. 3 find(self. replacementObject .MOFRef).OclType.isOfType(find(self.link.MOFRef). getRef(self. linkEndIdentifier ).OclType) Cette contrainte spécifie en effet que dans le cas d’une substitution de fin de lien, l’objet correspondant à la nouvelle valeur d’un lien doit être du même type que la référence que ce lien instancie. Le second type d’erreur concerne le non-respect de la multiplicité d’une référence. Par exemple, lorsqu’une référence avec une borne inférieure n et une borne supérieure p est instanciée par m liens, avec m < n ou m > p. Cela a lieu lorsqu’une substitution de fin de lien ou une substitution de fin de lien paramétrable (une existence de lien) crée (supprime) un lien, rendant ainsi le nombre de liens instanciant une référence supérieur (inférieur) à sa borne supérieure (inférieure). Cela a également lieu durant une substitution de fragment, car CVL permet de créer et de supprimer des liens entrants et sortants au fragment remplaçant et à ses copies, sans assurer le respect de la multiplicité des références dont ces liens sont instances. Finalement, ce type d’erreur peut aussi arriver lors de l’exécution d’un point de variation composite, quand le conteneur du conteneur configurable ne peut pas contenir une nouvelle instance du conteneur configurable. Afin de prévenir ce type d’erreur, certaines contraintes doivent être respectées au moment de la dérivation. Un nouveau lien ne doit pouvoir être instance d’une référence dont la borne supérieure est strictement supérieure à un que si le nombre de liens qui sont déjà instances de cette référence est strictement plus petit que la borne supérieure de cette référence. Un lien peut être supprimé seulement si la référence dont il est instance avant sa suppression a un nombre de liens strictement supérieur à sa borne inférieure. Un fragment de processus peut être dupliqué seulement si ses liens entrants peuvent également être dupliqués tout en assurant le respect de la multiplicité des références dont ils sont instances. Un point de variation composite peut être exécuté seulement si le conteneur du conteneur configurable peut contenir un conteneur configurable de plus. Le troisième type d’erreur concerne le non-respect des propriétés d’un métamodèle82 Gestion de la variabilité dans les processus capturées à l’aide d’un langage de contraintes. Ce type d’erreur peut apparaître à la suite de l’exécution de n’importe quel type de point de variation. Les second et troisième types d’erreur constituent la seconde catégorie d’erreurs que nous avons identifiée. Ces erreurs sont possibles parce que CVL ne contraint pas la spécification du VRM en fonction du modèle de base auquel il s’applique et en fonction du métamodèle de ce modèle de base. Une solution pour assurer les contraintes des second et troisième types d’erreur serait un outil générique d’analyse statique qui vérifierait avant la dérivation si ces contraintes sont satisfaites. Par générique, nous entendons indépendant du métamodèle du modèle de processus de base. Il est possible d’implémenter un tel outil en raisonnant sur le métamétamodèle MOF, commun à tous les modèles de processus de base, et non pas sur un métamodèle particulier. Si ces contraintes ne sont pas satisfaites, l’outil informerait alors l’utilisateur de la ligne de processus de la contrainte qui a été violée et du point de variation ayant introduit cette violation. L’expert processus et l’utilisateur de la ligne de processus devraient alors corriger l’erreur pour pouvoir commencer la dérivation. La quatrième erreur apparaît quand le modèle de processus résolu est bien conforme à son métamodèle, mais est sémantiquement inconsistant. Un modèle de processus peut être sémantiquement inconsistant dans deux cas : soit lorsque ce modèle est trop permissif vis-à-vis d’un métier spécifique, soit lorsque ce modèle est incohérent. La figure 4.13 illustre le cas d’un modèle incohérent. En SPEM 2.0, une séquence de travail spécifie les dépendances au moment de l’exécution d’activités. Ici, la séquence de travail de type finishToFinish signifie que l’activité B peut finir quand l’activité A est terminée. La séquence de travail finishToStart signifie que l’activité B peut commencer quand l’activité A est terminée. Ici la séquence de travail de type fi- nishToFinish est inutile car elle est automatiquement respectée si la séquence de travail de type finishToStart l’est. Afin d’éviter ce problème, on doit s’assurer qu’il n’y a pas d’inconsistances au niveau de la sémantique dans le modèle de processus résolu. Figure 4.13 – Séquence de travail sur-spécifiée Ce quatrième type d’erreur constitue la troisième catégorie que nous avons identi- fiée. L’origine de ces erreurs est l’utilisation d’un métamodèle de processus non adapté à un domaine métier ou permettant la création de modèles incohérents. Comme CVL ne contraint pas la spécification du VRM en fonction du modèle de base et de son mé- tamodèle, les erreurs de la troisième catégories peuvent avoir lieu. Cependant, dans ce cas, les erreurs sont spécifiques à un métamodèle et ne peuvent pas être généralisées. Nous proposons deux solutions pour éviter ces erreurs. L’une préserve l’indépendance vis-à-vis du métamodèle de processus, l’autre non. La première solution serait de modifier le métamodèle du modèle de processus résolu afin qu’il ne permette plus de définir des instances incohérentes et qu’il satisfasse les contraintes d’un domaine mé- tier spécifique. La deuxième solution serait d’implémenter un moteur de dérivationDiscussion 83 spécifique au métamodèle de processus utilisé (ici SPEM). Il assurerait que durant la dérivation des contraintes spécifiques à ce métamodèle soient satisfaites, en plus d’effectuer les mêmes opérations que le moteur de dérivation générique de CVL. Dans le cas où une contrainte spécifique au métamodèle ne serait pas respectée, le moteur de dérivation informerait l’utilisateur de la ligne de processus de l’étape de dérivation qui a introduit cette erreur et de la contrainte qui a été violée. Le choix entre la première et la deuxième solution dépend de leur coût de mise en œuvre. En effet, dans le cas de la première solution, la modification du métamodèle de processus implique de modifier les outils le supportant (éditeurs, compilateurs, interpréteurs...). En contrepartie, on peut continuer à utiliser le moteur de dérivation générique de CVL. Cette solution pré- serve donc l’indépendance de CVL vis-à-vis du langage de modélisation de processus utilisé. La deuxième solution, étant donné qu’elle n’implique pas de modifier le métamodèle de processus, n’implique pas non plus de mettre à jour les outils supportant ce métamodèle. Elle impose en revanche de définir un moteur de dérivation spécifique à un métamodèle de processus, lorsque celui-ci n’est pas parfaitement adapté à un mé- tier ou lorsqu’il permet la création d’instances incohérentes. Il incombe donc à chaque utilisateur de CVL de déterminer la solution qui lui convient le mieux, en fonction de ses ressources et des erreurs qu’il souhaite éviter. En conclusion, même s’il est actuellement possible de dériver un modèle de processus résolu invalide, cela ne remet pas en cause l’indépendance actuelle de CVL vis-à-vis du métamodèle du modèle de base et du modèle résolu, et il existe des solutions à ce problème qui préservent cette indépendance. 4.3.4 Extension possible à la méthodologie pour modéliser le processus de base La modélisation des éléments de processus externes peut conduire à des modèles qui ne sont pas conformes à leur métamodèle. En effet, comme les éléments de processus externes sont modélisés indépendamment d’un processus, certains ne respectent pas toutes les contraintes imposées par leur métamodèle. Par exemple, le modèle de la figure 4.8 n’est pas conforme au métamodèle des diagrammes d’activité UML. En effet, tous les flots de contrôle n’ont pas forcément à la fois une source et une cible, alors que le métamodèle des diagrammes d’activité UML l’impose. Puisque certains modeleurs de processus (par exemple, SPEM-Designer 10) ne permettent pas de modéliser des éléments de processus invalides, l’application de la méthodologie que nous proposons pour définir le modèle de processus de base peut se révéler difficile. Nous proposons donc d’utiliser des approches (par exemple [RBJ07]) permettant de générer des élé- ments de modèles en fonction de contraintes prédéfinies afin de gérer ce cas. Il serait ainsi possible de générer les éléments de modèles que les modeleurs ne permettent pas de modéliser, et également de générer les éléments de modèles manquants pour les rendre valides. Ces éléments de modèle générés ne seraient bien entendu pas utilisés pour dériver des processus de la ligne de processus. 10. http://marketplace.eclipse.org/content/spem-designer-helios-version84 Gestion de la variabilité dans les processus 4.4 Synthèse Nous avons proposé dans ce chapitre une approche permettant de gérer la variabilité des processus de développement logiciel en fonction des exigences des projets, et ce quel que soit le langage de modélisation de processus utilisé pour peu qu’il se conforme au MOF. Notre approche s’appuie sur CVL afin de spécifier et de résoudre la variabilité dans les processus. Nous avons fait le choix de CVL car il préserve la séparation des préoccupations entre l’aspect gestion de la variabilité et l’aspect métier dont on souhaite gérer la variabilité. Il est donc possible de réutiliser les concepts et outils spécifiques à ces aspects, sans qu’ils soient impactés par des préoccupations externes. D’autre part, bien que CVL permette actuellement de dériver des modèles résolus invalides, il existe des solutions permettant de prévenir ce problème. Ces solutions ont également l’avantage de préserver l’indépendance vis-à-vis du domaine métier dont la variabilité est gérée. De plus, CVL permet de définir en intention les différents processus d’une famille. Il permet en effet, dans le modèle de processus de base, de ne définir qu’une seule fois les éléments de processus communs à plusieurs processus, et il fournit des mécanismes permettant d’intégrer ces éléments à un processus au moment de la dérivation. Cela facilite la maintenance d’une famille de processus puisque les redondances entre les différents processus sont évitées. Cela facilite également la réutilisation des fragments de processus communs à plusieurs processus d’une famille. D’autre part, notre approche préserve la séparation entre exigences et processus et elle permet de refléter directement la variabilité des exigences sur les processus, plutôt que de passer par une couche intermédiaire définissant la variabilité des processus. Enfin, la méthodologie que nous proposons pour définir le modèle de processus de base a l’avantage d’expliciter le processus d’une famille qui est le plus souvent utilisé.Chapitre 5 Création de composants d’automatisation réutilisables Nous avons vu au début de cette partie que la réutilisation des CA (Composants d’Automatisation, c’est-à-dire composants logiciels automatisant des TMR) était réalisée via la réutilisation des processus de développement logiciel auxquels ces CA sont liés. Chaque CA peut être lié à des processus différents ou à des unités de travail différentes d’un même processus, constituant ainsi des cas d’utilisation différents d’un CA. Nous présentons donc dans ce chapitre notre méthodologie fournissant un support à la création de CA réutilisables à travers tous leurs cas d’utilisation. Nous commençons par introduire, dans la section 5.1, l’exemple dont nous nous servirons pour illustrer cette méthodologie, qui est elle-même détaillée dans la section 5.2. Nous discutons cette méthodologie dans la section 5.3 et nous en faisons la synthèse dans la section 5.4. Les travaux présentés dans ce chapitre ont fait l’objet d’une publication : Emmanuelle Rouillé, Benoît Combemale, Olivier Barais, David Touzet and Jean-Marc Jézéquel. Improving Reusability in Software Process Lines. In Proceedings of the 39th Euromicro Conference on Software Engineering and Advanced Applications, SEAA ’13, pages 90-94, 2013 [RCB+13a]. 5.1 Exemple illustratif : automatisation de la configuration de l’espace de travail local d’un développeur Nous présentons dans cette section l’exemple dont nous nous servirons pour illustrer la méthodologie fournissant un support à la création de CA réutilisables. Il s’agit d’un script PowerShell qui automatise la configuration de l’espace de travail local d’un 8586 Création de composants d’automatisation réutilisables développeur. Ce script est utilisé pendant les projets de développement Java de l’entreprise Sodifrance. Il est exécuté au début de l’activité de développement par chaque développeur du projet. Il est également exécuté à chaque fois qu’un nouveau développeur intègre un projet de développement Java dont l’activité de développement est déjà commencée. La figure 5.1 montre un extrait de ce script PowerShell, sur lequel notre méthodologie n’a pas encore été appliquée (c’est-à-dire que le script est configuré pour être utilisé avec un projet particulier). Il prend en paramètre (ligne 1) le chemin de l’espace de travail local d’un développeur (wsPath), ainsi que les URL des dépôts contenant le code source de l’application en cours de développement (sourceUrl) et le code de build (buildUrl). Le code de build correspond à des ressources, autres que le code source, utiles à la configuration de l’espace de travail local d’un développeur. Le script automatise les étapes suivantes : 1. import, en utilisant SVN, du code source (ligne 10) et du code de build (ligne 13), 2. compilation Maven des projets Java et alimentation initiale du dépôt Maven local si nécessaire (ligne 18), 3. configuration Maven des projets Eclipse (ligne 19), 4. configuration Maven de l’espace de travail Eclipse (ligne 20), 5. import Buckminster des projets dans l’espace de travail Eclipse (à partir de la ligne 23). 5.2 La méthodologie Nous constatons que les CA peuvent contenir de la variabilité. En effet, un même CA peut être lié à des unités de travail différentes appartenant à un même processus, représentant alors des contextes d’utilisation différents de ce CA. Par exemple, dans le cas d’un processus de métamodélisation comprenant des étapes de définition d’un mé- tamodèle, d’un éditeur textuel et d’un éditeur arborescent, un CA pourrait automatiser la mise sous contrôle de version de code source lors de toutes ces étapes. De plus, une même unité de travail peut varier en fonction des exigences d’un projet (par exemple utilisation de Git au lieu de SVN), créant ainsi encore plus de contextes d’utilisation différents d’un CA. La variabilité au niveau des contextes d’utilisation d’un CA crée, quant à elle, de la variabilité au niveau des CA eux-mêmes. Par exemple, l’implémentation d’un CA qui fait de la mise sous contrôle de version sera différente selon le SCV utilisé, ou selon l’adresse du dépôt distant utilisé. Une difficulté supplémentaire concernant la réutilisation des CA est donc d’identifier les parties d’un CA qui varient et celles qui ne varient pas (c’est-à-dire identifier le niveau de réutilisation d’un CA), afin ensuite d’être capable d’implémenter des CA qui soient réutilisables à travers leurs différents contextes d’utilisation (en utilisant par exemple des mécanismes tels que le paramétrage, la modularisation...). Pour ce faire, nous présentons dans cette partie une méthodologie permettant d’améliorer l’identification du niveau de réutilisation de CA. Nous appelons cette méthodologie M4RAC (Methodology for Reusable Automation Components). Elle constitue la deuxième sous-contribution de cette thèse. La figure 5.2La méthodologie 87 1 Param ([ string] $wsPath , [string] $sourceUrl , [string] $buildUrl ) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 [...] 8 9 # Checkout of source code from URL $sourceUrl to folder $sourcePath 10 svn checkout $sourceUrl $sourcePath 11 12 # Checkout of build code from URL $buildUrl to folder $buildPath 13 svn checkout $buildUrl $buildPath 14 15 # Run Maven commands to compile and configure Eclipse projects and to configure the workspace 16 $sourcePom = $sourcePath + "/ pom.xml" 17 [...] 18 mvn compile -f $sourcePom 19 mvn eclipse:eclipse -f $sourcePom 20 Invoke - Expression (" mvn -D eclipse. workspace =" + $wsPath + " eclipse:configure - workspace ") 21 22 # Run Buckminster commands to import projects into the workspace 23 $buckyBuild = $buildPath + "/ buckybuild . properties " 24 [...] 25 $cQueryFile = $buildPath + "/ org.eclipse. buckminster . myproject .build/ buckminster / myproject -build.cquery" 26 buckminster import --properties $buckyBuild -data $wsPath $cQueryFile 27 [...] Figure 5.1 – Extrait d’un script PowerShell qui automatise la configuration de l’espace de travail d’un développeur illustre la partie de la contribution principale que nous détaillons ici, tandis que la figure 5.3 montre le processus de la méthodologie. Nous expliquons plus en détails ce processus dans la suite de cette section.88 Création de composants d’automatisation réutilisables Figure 5.2 – Partie de la contribution principale réalisée par M4RACLa méthodologie 89 Figure 5.3 – Vue générale de M4RAC90 Création de composants d’automatisation réutilisables Figure 5.4 – Première étape de M4RAC Figure 5.5 – Exemple simplifié de ligne de processus de développement Java 5.2.1 Définition d’une ligne de processus de développement logiciel (étape 1) 5.2.1.1 Méthodologie La première étape de M4RAC, illustrée par la figure 5.4, implique comme rôle un expert processus, tout comme pour CVL4SP (chapitre 4). Cet expert processus définit une ligne de processus de développement logiciel en utilisant CVL4SP. 5.2.1.2 Illustration La figure 5.5 montre un exemple simplifié de ligne de processus de développement Java. Dans le modèle de processus de base (à droite sur la figure 5.5), le processus le plus souvent utilisé est composé des tâches spécifier, développer et tester, et les outils SVN et Maven servent à réaliser la tâche développer. Le modèle de processus de base contient également un élément de processus externe, l’outil Git. Le VAM (à gaucheLa méthodologie 91 Figure 5.6 – Deuxième étape de M4RAC sur la figure 5.5) spécifie qu’un SCV (correspondant sur la figure au choix SCV) est obligatoirement utilisé pendant un projet de développement Java (correspondant sur la figure au choix développement Java), et que ce SCV peut être soit Git (correspondant sur la figure au choix Git) soit SVN (correspondant sur la figure au choix SVN). Le VRM, au centre de la figure 5.5, spécifie quant à lui que si Git est choisi comme SCV, alors, dans le modèle de processus de base, l’outil SVN doit être remplacé par l’outil Git. 5.2.2 Spécification des composants d’automatisation (étape 2) 5.2.2.1 Méthodologie La figure 5.6 met en évidence la deuxième étape de M4RAC. Cette étape implique comme rôle un architecte, c’est-à-dire une personne ayant l’expérience et le recul nécessaire pour identifier des TMR qui gagneraient à être automatisées, et capable de concevoir des CA automatisant ces TMR. Lors de la deuxième étape de M4RAC, l’architecte spécifie les CA abstraits qui sont utiles pour l’entreprise dans laquelle il travaille, à l’aide d’un modeleur de CA abstraits. Un CA abstrait est une définition conceptuelle d’un CA, où l’architecte spécifie uniquement qu’un CA existe et ce qu’il automatise, sans rentrer dans les détails de conception et d’implémentation. Durant cette étape, l’architecte ne se préoccupe pas de l’identification du niveau de réutilisation de ces CA, ni de leur conception et de leur implémentation. Il se préoccupe uniquement de la spécification, de manière abstraite, des CA existants ainsi que des CA futurs. Il détermine les CA futurs en identifiant les TMR qui gagneraient à être automatisées, et en supposant dans un premier temps que chacune de ces tâches sera automatisée par un CA.92 Création de composants d’automatisation réutilisables Figure 5.7 – Troisième étape de M4RAC 5.2.2.2 Illustration Un exemple de CA spécifié à l’issue de la deuxième étape de M4RAC est le CA dont le but est de configurer l’espace de travail local d’un développeur. 5.2.3 Liaison entre les CA et leurs contextes d’utilisation (étape 3) 5.2.3.1 Méthodologie Au moment de la troisième étape de M4RAC, mise en évidence par la figure 5.7, l’architecte modélise les liens entre les CA abstraits (spécifiés à l’étape 2) et les unités de travail (par exemple les tâches) de la ligne de processus qu’ils contribuent à automatiser. Il utilise pour ce faire un modeleur de liaisons, où ici le terme liaisons dé- signe les liens entre les CA et les unités de travail qu’ils automatisent. Si plusieurs CA contribuent à automatiser une même unité de travail, alors la liaison spécifie l’ordre dans lequel ces CA doivent s’exécuter. Si une unité de travail varie, alors la liaison spécifie quelle variante de cette unité de travail un CA contribue à automatiser. On considère qu’une unité de travail varie soit si l’unité de travail elle-même varie, soit si ce sont les éléments de modèle directement reliés à cette unité de travail (ex : outils, rôles, produits de travail, flots de contrôle) qui varient. Finalement, la liaison spécifie si un CA contribue à automatiser l’initialisation, l’exécution ou la finalisation d’une unité de travail. Définir une initialisation (une finalisation) pour une unité de travail est utile car cela permet d’empêcher l’oubli de cette initialisation (finalisation). En effet, l’initialisation (finalisation) est dans ce cas fortement couplée à l’unité de travail qu’elle initialise (finalise). Ce n’est pas le cas quand l’initialisation (la finalisation) est remplacée par une unité de travail qui a lieu avant (après) l’unité de travail initialisée (finalisée). Cette étape permet donc d’identifier les contextes d’utilisation des CA. Plus pré- cisément, ce sont les unités de travail liées à un CA, leurs ressources (c’est-à-dire lesLa méthodologie 93 Figure 5.8 – Liaison entre le CA configurant l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 outils, les rôles et les produits de travail), leurs itérations et leur séquencement qui définissent les contextes d’utilisation des CA. En effet, les variantes des unités de travail qu’un CA automatise sont ses contextes d’utilisation. Et c’est la spécification des variantes de ressources, itérations et séquencement associés à une unité de travail qui définit quelle variante d’unité de travail est considérée. De plus, nous verrons dans la prochaine partie de cette thèse que les unités de travail et leurs ressources fournissent les données (par exemple l’URL d’un dépôt) requises pour exécuter les CA. 5.2.3.2 Illustration La figure 5.8 illustre la liaison entre le CA configurant l’espace de travail local d’un développeur et la ligne de processus de la figure 5.5. Le CA configurant l’espace de travail local d’un développeur contribue à l’automatisation de l’initialisation de toutes les variantes (c’est-à-dire en utilisant Git ou SVN) de la tâche développer. Cela permet donc d’identifier que ce CA a deux contextes d’utilisation : l’un lorsque SVN est utilisé comme SCV, et l’autre lorsque c’est Git qui est utilisé à la place de SVN. 5.2.4 Conception des composants d’automatisation (étape 4) 5.2.4.1 Méthodologie Lors de la quatrième étape deM4RAC, mise en évidence par la figure 5.9, l’architecte conçoit les CA spécifiés de manière abstraite à l’étape 2. Pendant cette étape, le modèle de liaisons permet d’améliorer l’identification du niveau de réutilisation des CA. En effet, en réfléchissant à comment concevoir un CA de manière à ce qu’il soit réutilisable à travers ses différents contextes d’utilisation, l’architecte est capable de déterminer son niveau de réutilisation, c’est-à-dire les parties de ce CA qui varient et celles qui ne varient pas. Une fois cette information établie, l’architecte conçoit des CA réutilisables en s’appuyant sur des mécanismes tels que le paramétrage ou la modularisation. En concevant les CA, l’architecte peut se rendre compte que le modèle de liaisons est incorrect. Par exemple, un CA peut contenir des parties inutiles pour certains de ses contextes d’utilisation. Il sera donc, dans ce cas, plus judicieux de diviser ce CA en plusieurs CA afin de pouvoir sélectionner uniquement les parties de ce CA utiles94 Création de composants d’automatisation réutilisables Figure 5.9 – Quatrième étape de M4RAC pour chaque contexte d’utilisation. Dans ce cas, l’architecte revient à l’étape 3 afin de corriger le modèle de liaisons. 5.2.4.2 Illustration Comme abordé dans la section 5.1, la configuration de l’espace de travail local d’un développeur se compose de 5 étapes : 1. import du code source et du code de build depuis un dépôt distant, 2. compilation Maven des projets Java et alimentation initiale du dépôt Maven local si nécessaire, 3. configuration Maven des projets Eclipse, 4. configuration Maven de l’espace de travail Eclipse, 5. import Buckminster des projets dans l’espace de travail Eclipse. Le CA configurant l’espace de travail local d’un développeur doit donc réaliser ces 5 étapes. Or, l’étape 3 de M4RAC a permis de déterminer que ce CA pouvait être utilisé dans deux contextes différents : avec Git ou avec SVN. Cela permet donc de déterminer le niveau de réutilisation de ce CA, à savoir que ses parties dépendantes d’un SCV (étape 1 de la configuration de l’espace de travail local d’un développeur) peuvent varier tandis que les autres non (étapes 2 à 5 de la configuration de l’espace de travail local d’un développeur). L’architecte doit donc assurer que l’étape 1 soit découplée des étapes 2 à 5 de la configuration de l’espace de travail local d’un développeur, de manière à pouvoir réutiliser les étapes 2 à 5 indépendamment du SCV. Une manière de réaliser ce découplage est d’avoir trois CA : deux CA réalisant l’étape 1, l’un avec SVN (CA 1) et l’autre avec Git (CA 2), et un CA réalisant les étapes 2 à 5 (CA 3). L’initialisation de la tâche de développement serait alors effectuée par l’exécution des CA 1 puis 3 lorsque le SCV est SVN, et par l’exécution des CA 2 puis 3 lorsque leLa méthodologie 95 SCV est Git. Le modèle de liaisons réalisé lors de l’étape précédente de M4RAC est également mis à jour, afin de refléter cette conception, comme illustré par la figure 5.10. Figure 5.10 – Liaisons entre les CA permettant de configurer l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 5.2.5 Implémentation des composants d’automatisation (étape 5) 5.2.5.1 Méthodologie Figure 5.11 – Cinquième étape de M4RAC Finalement, lors de la dernière étape de M4RAC, mise en évidence par la figure 5.11,96 Création de composants d’automatisation réutilisables un développeur implémente les CA en fonction de leur conception (étape 4 deM4RAC). 5.2.5.2 Illustration Le script PowerShell de la figure 5.1 correspond à une implémentation de la confi- guration de l’espace de travail local d’un développeur, dans le cas où SVN est utilisé comme SCV. Il sert de base à la création des trois CA conçus lors de l’étape 4 de M4RAC. Les scripts des figures 5.12, 5.13 et 5.14 correspondent respectivement à l’implémentation des CA 1, 2 et 3 identifiés précédemment. 1 Param ([ string] $wsPath , [string] $sourceUrl , [string] $buildUrl ) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 [...] 8 9 # Checkout of source code from URL $sourceUrl to folder $sourcePath 10 svn checkout $sourceUrl $sourcePath 11 12 # Checkout of build code from URL $buildUrl to folder $buildPath 13 svn checkout $buildUrl $buildPath Figure 5.12 – Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec SVN 1 Param ([ string] $wsPath , [string] $sourceUrl , [string] $buildUrl ) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 [...] 8 9 # Checkout of source code from URL $sourceUrl to folder $sourcePath 10 git clone $sourceUrl $sourcePath 11 12 # Checkout of build code from URL $buildUrl to folder $buildPath 13 git clone $buildUrl $buildPath Figure 5.13 – Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec Git 5.3 Discussion Nous discutons dans cette partie M4RAC. Cette discussion porte sur ses bénéfices, ses limitations, ainsi que ses inconvénients.Discussion 97 1 Param ([ string] $wsPath) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 # Run Maven commands to compile and configure Eclipse projects and to configure the workspace 8 $sourcePom = $sourcePath + "/ pom.xml" 9 [...] 10 mvn compile -f $sourcePom 11 mvn eclipse:eclipse -f $sourcePom 12 Invoke - Expression (" mvn -D eclipse. workspace =" + $wsPath + " eclipse:configure - workspace ") 13 14 # Run Buckminster commands to import projects into the workspace 15 $buckyBuild = $buildPath + "/ buckybuild . properties " 16 [...] 17 $cQueryFile = $buildPath + "/ org.eclipse. buckminster . myproject .build/ buckminster / myproject -build.cquery" 18 buckminster import --properties $buckyBuild -data $wsPath $cQueryFile 19 [...] Figure 5.14 – Extrait du CA automatisant les étapes 2 à 5 de la configuration de l’espace de travail d’un développeur 5.3.1 Bénéfices Notre méthodologie fournit deux bénéfices principaux pour identifier le niveau de réutilisation de CA. Le premier bénéfice de notre méthodologie est qu’elle aide l’architecte à identifier les différents contextes d’utilisation des CA. C’est parce qu’elle permet de spécifier les différents contextes d’utilisation des CA. En effet, chez Sodifrance, nous avons répertorié au moins 512 processus de développement Java possibles en pratique, identifiés suite à l’interview d’un chef de projet. Il est bien sûr impossible pour un humain d’avoir en tête ces différents processus et les différents contextes d’utilisation de tous les CA. Le second bénéfice de notre méthodologie est qu’elle empêche l’architecte de considérer de la variabilité inutile. Cela prévient donc la conception et l’implémentation de CA inutiles. Le fait que M4RAC permette d’expliciter la variabilité des processus ainsi que les contextes d’utilisation des CA est la raison de ce bénéfice. Par exemple, dans le cas d’un CA en charge d’automatiser la mise sous contrôle de version du code source d’un projet, l’architecte pourrait concevoir trois variantes de ce CA : une utilisant CVS, une autre utilisant SVN et encore une autre utilisant Git. En effet, l’architecte pourrait déjà avoir utilisé ces trois SCV sur des projets différents. Cependant, l’architecte pourrait ne pas être au courant que CVS n’est plus utilisé (dans l’hypothèse où il est possible de déterminer que c’est le cas). Dans ce cas, implémenter un CA automatisant la mise sous contrôle de version du code source d’un projet en utilisant CVS serait une perte de temps. En revanche, si CVS n’est plus utilisé, alors il n’apparaîtra pas dans la ligne de processus comme un SCV possible. De ce fait, en appliquant notre méthodologie,98 Création de composants d’automatisation réutilisables l’architecte aurait réalisé que CVS n’était plus utilisé. Il n’aurait alors pas conçu un CA inutile. 5.3.2 Une limitation Une limitation de notre méthodologie est que son efficacité dépend des langages utilisés pour définir la ligne de processus. En effet, si ces langages ne permettent pas de capturer certaines informations concernant les contextes d’utilisation des CA (par exemple certains métamodèles de processus ne permettent pas de capturer une définition d’outil), alors l’architecte ne peut dans ce cas pas s’appuyer sur la ligne de processus pour identifier tous les contextes d’utilisation des CA. L’architecte ne peut alors s’appuyer que sur sa propre connaissance pour identifier les contextes d’utilisation qui ne sont pas capturés par la ligne de processus. Ceci est moins efficace que de s’appuyer sur la ligne de processus. En effet, l’architecte peut oublier des contextes d’utilisation ou peut considérer des contextes d’utilisation inutiles. 5.3.3 Un inconvénient Un inconvénient de M4RAC est qu’il est difficile d’identifier les contextes d’utilisation des CA. En effet, avec la définition en intention des processus, il est difficile pour un humain de visualiser explicitement chacun des processus de la ligne. Par exemple, l’architecte peut avoir des difficultés à visualiser ce qui se passe avant et après une variante d’unité de travail, et donc il peut avoir des difficultés à déterminer à quelles unités de travail il est pertinent d’associer un CA. La définition de processus en extension n’est pas une solution satisfaisante à ce problème. En effet, plus le nombre de processus est élevé, plus il est tout aussi difficile pour un humain d’identifier les différents contextes d’utilisation des CA. Une solution serait d’avoir un outil support à l’identification des contextes d’utilisation des CA (étape 3 de M4RAC). Celui-ci pourrait par exemple calculer et afficher les différents processus d’une famille en fonction de leur spécification en intention, et afficher également les CA associés aux unités de travail de ces différents processus, au fur et à mesure de leur association. Afin de limiter le nombre de processus affichés, une idée serait de définir des contextes d’utilisation de CA similaires, et donc de n’afficher qu’un seul de ces contextes. De plus, cet outil pourrait vérifier la consistance entre des pré et post-conditions associées aux CA, afin de détecter d’éventuelles erreurs au moment de l’association d’un CA à une unité de travail. 5.4 Synthèse Nous avons proposé, dans ce chapitre, une méthodologie qui permet d’améliorer l’identification du niveau de réutilisation d’un CA. Le principe de cette méthodologie consiste à lier chaque CA aux unités de travail qu’il contribue à automatiser dans une ligne de processus. Cela permet d’identifier les différents contextes d’utilisation de chacun de ces CA. Ensuite, en réfléchissant à la conception d’un CA afin qu’il soitSynthèse 99 réutilisable à travers ses différents contextes d’utilisation, il est possible d’identifier le niveau de réutilisation de ce CA. Cette méthodologie permet d’expliciter les différents contextes d’utilisation d’un CA. De ce fait, cela permet à l’architecte en charge de la conception des CA de ne pas oublier certains contextes d’utilisation et de ne pas prendre en compte des contextes d’utilisation inutiles. Une limitation de cette méthodologie en revanche est que son efficacité dépend des langages utilisés pour définir la ligne de processus. En effet, les contextes d’utilisation que la ligne de processus peut capturer dépendent des informations que les langages utilisés pour définir la ligne de processus permettent de capturer. D’autre part, avoir un outil permettant d’expliciter les différents processus d’une ligne ainsi que les CA déjà associés à ces processus aiderait l’architecte à identifier les contextes d’utilisation des CA.100 Création de composants d’automatisation réutilisablesTroisième partie Outillage et application 101103 Dans cette partie, nous commençons par présenter dans le chapitre 6 l’outil que nous avons développé afin de démontrer la faisabilité de l’approche proposée dans cette thèse. Ensuite, dans le chapitre 7, nous appliquons cet outil à une famille de processus de métamodélisation ainsi qu’à une famille de processus de développement web Java issue de Sodifrance.104Chapitre 6 Outil pour la gestion de la variabilité et l’automatisation des processus Ce chapitre traite de l’outil développé comme support à l’approche proposée dans cette thèse. Nous commençons par introduire, en section 6.1, l’exemple dont nous nous servons pour présenter cet outil. La vue générale de l’outil est présentée en section 6.2 et son implémentation est décrite en section 6.3. Nous présentons, dans la section 6.4, des éléments de méthodologie relatifs à l’utilisation de l’outil, ainsi que des extensions possibles. Enfin, nous faisons la synthèse de ce chapitre dans la section 6.5. 6.1 Exemples de tâches manuelles récurrentes Cette section introduit les exemples de TMR (Tâches Manuelles Récurrentes) utilisés pour illustrer l’utilisation de l’outil développé dans cette thèse. Ces TMR, issues de l’exécution de processus de la famille des processus de métamodélisation (présentée dans la section 4.1), gagneraient à être automatisées. Elles correspondent à la manière de réaliser des processus de métamodélisation dans l’équipe de recherche Triskell. Il existe d’autres manières de réaliser des processus de métamodélisation qui ne sont pas traitées ici (utilisation d’un outil autre que Kermeta, utilisation différente d’EMFText, etc.). TMR Unité de travail pendant laquelle la TMR a lieu Étape de l’unité de travail Itération Création projet EMF et fichier Ecore vide déf. métamodèle initialisation première Validation métamodèle déf. métamodèle finalisation toutes 105106 Outil pour la gestion de la variabilité et l’automatisation des processus TMR Unité de travail pendant laquelle la TMR a lieu Étape de l’unité de travail Itération Création fichier contenant la syntaxe concrète du métamodèle déf. éditeur arborescent initialisation première Mise à jour fichier contenant la syntaxe concrète du métamodèle déf. éditeur arborescent initialisation à partir de la seconde Génération éditeur arborescent déf. éditeur arborescent finalisation toutes Génération syntaxe textuelle déf. éditeur textuel avec EMFText initialisation première Génération éditeur textuel déf. éditeur textuel avec EMFText finalisation toutes Création projet XText déf. éditeur textuel avec XText initialisation première Génération éditeur textuel déf. éditeur textuel avec XText finalisation toutes Création projet Kermeta initilisé avec un appel à une fonction Kermeta qui vérifie qu’un modèle respecte bien les contraintes définies sur son métamodèle déf. vérificateur initialisation première Création projet Kermeta et application patron de conception interpréteur au métamodèle déf. interpréteur initialisation première Application patron de conception interpréteur aux nouvelles métaclasses du métamodèle déf. interpréteur initialisation à partir de la seconde Mise sous contrôle de version interpréteur déf. interpréteur finalisation première Propagation, sur un dépôt partagé, du code source de l’interpré- teur déf. interpréteur finalisation toutes Création projet Kermeta et application patron de conception visiteur au métamodèle déf. compilateur initialisation première Application patron de conception visiteur aux nouvelles métaclasses du métamodèle déf. compilateur initialisation à partir de la seconde Table 6.1 – Exemples de TMR réalisées durant un processus de métamodélisationExemples de tâches manuelles récurrentes 107 Nous avons identifié 16 exemples de TMR. Le tableau 6.1 les répertorie et précise pour chacune d’elle l’unité de travail, son étape (initialisation, exécution ou finalisation), ainsi que l’itération de processus concernées. Deux TMR sont liées à la définition d’un métamodèle. La première consiste à créer un projet EMF ainsi qu’un fichier Ecore vide, qui contiendra plus tard la définition d’un métamodèle. Cette TMR a lieu au moment de l’initialisation de la définition d’un métamodèle, lors de la première itération. La seconde TMR consiste à valider un métamodèle et a lieu au moment de la finalisation de la définition d’un métamodèle, à chaque itération. Trois autres TMR sont liées à la définition d’un éditeur arborescent. Celle-ci est initialisée par la création d’un fichier destiné à contenir la syntaxe concrète du mé- tamodèle, lors de la première itération. La mise à jour de ce fichier a lieu lors des itérations suivantes, toujours à l’initialisation. À chaque itération, la définition d’un éditeur arborescent est finalisée par la génération de l’éditeur en lui-même. Quatre TMR sont liées à la définition d’un éditeur textuel. Si celui-ci est défini avec EMFText, alors, dans le cadre de cet exemple, la TMR consistant à générer la syntaxe textuelle est réalisée à l’initialisation, lors de la première itération. Si l’éditeur textuel est défini avec XText, alors la TMR consistant à créer un projet XText est réalisée, à l’initialisation et lors de la première itération également. Dans les deux cas, la définition d’un éditeur textuel se termine par la TMR consistant à générer l’éditeur en lui-même. Une TMR concerne la définition d’un vérificateur. Elle consiste à créer un projet Kermeta et à l’initialiser avec un appel à une fonction Kermeta vérifiant qu’un modèle respecte bien les contraintes définies sur son métamodèle. Elle a lieu au moment de l’initialisation, lors de la première itération. Quatre TMR concernent la définition d’un interpréteur. Au moment de l’initialisation, lors de la première itération, une TMR crée un projet Kermeta et applique le patron de conception interpréteur à chaque méta-classe du métamodèle. Lors des itérations suivantes, la définition d’un interpréteur est initialisée par une TMR appliquant le patron de conception interpréteur seulement aux nouvelles méta-classes du métamodèle. Le cas des méta-classes du métamodèle supprimées ou modifiées n’est pas traité dans cet exemple. Lors de la première itération, la définition d’un interpréteur est finalisée par la TMR consistant à mettre l’interpréteur sous contrôle de version. De plus, à chaque itération, une TMR de propagation du code de l’interpréteur sur un dépôt distant a également lieu au moment de la finalisation. Enfin, deux TMR sont liées à la définition d’un compilateur. La première consiste à créer un projet Kermeta et à appliquer le patron de conception visiteur à chaque métaclasse du métamodèle. Elle initialise la définition d’un compilateur et n’a lieu que lors de la première itération. La deuxième TMR applique le patron de conception visiteur seulement aux nouvelles méta-classes du métamodèle. Elle initialise la définition d’un compilateur à partir de la deuxième itération. Tout comme pour la définition d’un interpréteur, le cas des méta-classes du métamodèle supprimées ou modifiées n’est pas non plus traité dans cet exemple. D’autres TMR non spécifiques au processus de métamodélisation, comme la confi- guration de l’environnement de développement, la configuration de l’environnement108 Outil pour la gestion de la variabilité et l’automatisation des processus d’intégration continue ou la configuration du schéma de compilation, peuvent également être réalisées dans ce contexte. 6.2 Vue générale de l’outil Figure 6.1 – Vue générale de l’architecture de T4VASP T4VASP (Tool for Variability management and Automation of Software Processes) est l’outil que nous avons développé pour valider l’approche proposée dans cette thèse . La figure 6.1 illustre ses composants : – un modeleur de VAM (Variability Abstraction Model, modèle spécifiant la variabilité (section 2.3.2 et chapitre 4)), – un modeleur de VRM (Variability Realization Model, modèle définissant comment dériver un modèle résolu du modèle de base, en fonction de la résolution de la variabilité (section 2.3.2 et chapitre 4)), – un assistant à la résolution de la variabilité, – un moteur de dérivation CVL,Vue générale de l’outil 109 – un modeleur de CA (Composants d’Automatisation, composants logiciels automatisant des TMR (partie II)) abstraits, – un modeleur de liaisons, – un framework supportant l’implémentation des CA – et un interpréteur de processus. Les modeleurs de VAM et de VRM permettent respectivement de produire des VAM et des VRM. L’assistant à la résolution de la variabilité permet de résoudre la variabilité d’un VAM (donc permet de sélectionner les exigences pour un projet particulier) et produit un RM (Resolution Model, modèle permettant de résoudre la variabilité définie dans un VAM (section 2.3.2 et chapitre 4)). Le moteur de dérivation de CVL permet de dériver un modèle de processus résolu, en fonction d’un modèle de processus de base, d’un VRM et d’un RM. Le modèle de processus de base est produit à l’aide d’un modeleur de processus SPEM que nous réutilisons. Le modeleur de CA abstraits permet, comme son nom l’indique, de spécifier des CA abstraits, qui sont des définitions conceptuelles de CA (cf. section 5.2.2). Le modeleur de liaisons permet quant à lui de lier les CA abstraits i) aux unités de travail qu’ils contribuent à automatiser dans une ligne de processus et ii) à leur implémentation. Le framework support à l’implémentation des CA offre un cadre technique pour l’implémentation des CA. Enfin, l’interpréteur de processus permet d’exécuter un processus (obtenu par dérivation d’une ligne de processus), et de lancer au fur et à mesure de son exécution les CA qui l’automatisent. Nous détaillons ces composants dans la suite de cette section, en les présentant en fonction des parties de l’approche de cette thèse qu’ils supportent. 6.2.1 Définition d’une ligne de processus Les modeleurs de VAM et de VRM supportent la définition d’une ligne de processus de développement logiciel, comme illustré par la figure 6.2. L’implémentation de ces modeleurs consiste à développer des éditeurs permettant de créer des VAM et des VRM conformes au métamodèle de la spécification de CVL. Des modeleurs autorisant la définition de VAM et de VRM dans des modèles distincts ont de plus l’avantage de permettre la réutilisation de ces modèles indépendamment les uns des autres. Ce besoin apparaît par exemple lorsqu’une même ligne de processus est définie avec deux langages de modélisation de processus différents, suite par exemple à un changement de modeleur dans l’entreprise. Dans ce cas, le même VAM est réutilisé pour spécifier la variabilité de la ligne de processus, quel que soit le langage de modélisation de processus utilisé, alors que des VRM différents sont utilisés pour chaque langage de modélisation de processus. 6.2.2 Définition des CA Le modeleur de CA abstraits, le modeleur de liaisons ainsi que le framework support à l’implémentation des CA contribuent à la définition des CA. Plus précisément, ils contribuent à la spécification de CA abstraits, à leur liaison à la ligne de processus et à leur implémentation. La figure 6.3 illustre la partie de l’approche proposée dans cette110 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.2 – Partie de l’approche supportée par les modeleurs de VAM et de VRM Figure 6.3 – Partie de l’approche supportée par les modeleurs de CA abstraits et de liaisons et le framework support à l’implémentation des CAVue générale de l’outil 111 thèse qui est supportée par ces composants. Le modeleur de liaisons permet de lier des CA abstraits (spécifiés à l’aide du modeleur de CA abstraits) aux unités de travail d’une ligne de processus qu’ils contribuent à automatiser. Le modeleur de liaisons permet également de lier les CA abstraits à leur implémentation. Lorsque plusieurs CA contribuent à l’automatisation d’une même unité de travail, ce modeleur doit permettre de spécifier l’ordre dans lequel ces CA doivent s’exécuter. Le modeleur de liaisons doit également permettre de spécifier si un CA contribue à automatiser l’initialisation, l’exécution ou la finalisation d’une unité de travail. Le framework support à l’implémentation des CA permet premièrement aux CA d’accéder à des informations contextuelles nécessaires à leur exécution. Pour s’exécuter, les CA ont en effet besoin d’avoir accès à des informations spécifiques à leur contexte d’utilisation, c’est-à-dire à des informations contextuelles. Par exemple, un CA qui met du code source sous contrôle de version doit avoir accès à l’URL du dépôt distant sur lequel partager ce code source. Selon le langage de modélisation utilisé pour définir la ligne de processus, ces informations contextuelles peuvent, ou non, être capturées dans la ligne de processus (et donc dans le modèle de processus résolu). Par exemple, en SPEM 2.0, il n’est pas possible de capturer l’URL d’un dépôt distant. En effet, même si cette information peut, par exemple, être capturée en utilisant une recommandation (Guidance), elle ne serait pas typée comme étant une information relative à l’URL d’un dépôt distant et ne pourrait donc pas être traitée comme telle par un outil recherchant des informations contextuelles. Il est donc nécessaire d’avoir un mécanisme permettant aux CA d’accéder aux informations contextuelles, qu’elles soient ou non capturées dans le modèle de processus résolu. Le framework support à l’implémentation des CA permet également d’exécuter les CA de manière générique. En effet, l’interpréteur de processus doit pouvoir être réutilisé indépendamment des CA. Or, il n’est pas possible de déterminer à l’avance un ensemble fini de CA puisque i) il n’est pas possible de prévoir toutes les évolutions qui peuvent être apportées à une famille de processus et ii) il n’est pas possible d’avoir une vision exhaustive de toutes les familles de processus existantes. Il est donc nécessaire de pouvoir, au fur et à mesure de l’exécution de processus, lancer l’exécution des CA de manière générique. Par ceci nous entendons plus précisément que le framework doit permettre de lancer automatiquement l’exécution des CA, quels qu’ils soient. 6.2.3 Dérivation d’un processus en fonction des exigences d’un projet L’assistant à la résolution de la variabilité et le moteur de dérivation CVL supportent la dérivation d’un processus de la ligne de processus en fonction des exigences d’un projet, comme illustré par la figure 6.4. L’assistant à la résolution de la variabilité offre un support à la résolution de la variabilité, étape pouvant s’avérer fastidieuse et source d’erreurs. En effet, dans le VAM, la non séparation des préoccupations entre les spécifications de variabilité nécessitant une résolution manuelle et celles dont la résolution est dérivée (c’est-à-dire calculée automatiquement en fonction de la résolution d’autres spécifications de variabilité) peut compliquer la résolution de la variabilité112 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.4 – Partie de l’approche supportée par l’assistant à la résolution de la variabilité et le moteur de dérivation CVL pour un humain. De plus, plus le nombre de contraintes entre des spécifications de variabilité du VAM sera important, plus il sera difficile pour un humain de les prendre en compte. D’autre part, un humain peut toujours faire des erreurs conduisant au nonrespect de la spécification de CVL. L’assistant à la résolution de la variabilité apporte donc un support i) en mettant en œuvre la séparation des préoccupations entre les spé- cifications de variabilité nécessitant une résolution manuelle et celles dont la résolution est dérivée, ii) en forçant le respect des contraintes entre les différentes spécifications de variabilité, et iii) en assurant le respect de la spécification de CVL. Le moteur de dérivation CVL, quant à lui, dérive un processus de la ligne de processus conformément à la spécification de CVL. Afin de créer le modèle de processus résolu, il applique donc sur le modèle de processus de base les points de variation dont les spécifications de variabilité ont été résolues positivement. 6.2.4 Automatisation de l’exécution des processus L’interpréteur de processus supporte l’automatisation de l’exécution des processus, comme illustré par la figure 6.5. Il exécute un processus résolu en fonction de la sé- mantique du langage de modélisation de processus utilisé. De plus, pour chaque unité de travail de ce processus, il lance, s’il y a lieu, l’exécution des CA associés. D’autre part, comme la réalisation de certaines unités de travail est manuelle [Ben07], l’interpréteur de processus informe l’acteur courant du processus lorsqu’une intervention manuelle est requise, afin d’assurer le bon déroulement de l’exécution. Enfin, commeImplémentation 113 Figure 6.5 – Partie de l’approche supportée par l’interpréteur de processus le processus à exécuter peut contenir de la variabilité non encore résolue, l’interpréteur de processus permet de résoudre cette variabilité au moment de l’exécution. 6.3 Implémentation Les composants de T4VASP sont implémentés en Java, sous la forme de plugins Eclipse. Nous détaillons dans la suite de cette section comment nous les avons implémentés. 6.3.1 Les modeleurs de VAM et de VRM Les modeleurs de VAM et de VRM correspondent chacun à un éditeur arborescent généré par défaut avec EMF, sur la base de fichiers Ecore capturant les parties du métamodèle de CVL relatives au VAM et au VRM. Les figures 6.6 et 6.7 illustrent respectivement des extraits du VAM et du VRM de l’exemple illustratif de famille de processus de métamodélisation, édités avec les modeleurs générés. L’extrait de VAM de la figure 6.6 comporte un choix sans enfant (Choice checker), un choix avec enfants (Choice version control system), ainsi qu’un choix dont la résolution est dérivée (Choice parallelization). Les enfants du choix version control system sont les choix SVN et Git. Ils sont mutuellement exclusifs, comme indiqué par la multiplicité de groupe valant 1 (Multiplicity Interval 1), élément spécifiant qu’un seul choix enfant peut être sélectionné. L’extrait de VRM de la figure 6.7 contient deux points de variation, qui sont des114 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.6 – Extrait du VAM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VAM Figure 6.7 – Extrait du VRM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VRM Figure 6.8 – Propriétés de l’existence d’objet tree editor de la figure 6.7 opérations à appliquer au modèle de base pour en dériver un modèle résolu (cf. section 2.3.2) : une substitution d’objet (Object Substitution replace SVN by Git) et une existence d’objet (Object Existence tree editor). Chacun de ces points de variation impacte des objets et des liens (Object Handle SVN, Object Handle Git, Object Handle tree editor definition). Les modeleurs de VAM et de VRM ne font pas apparaître toutes les propriétés de chaque élément de modèle dans la vue arborescente. Par exemple, l’extrait de VRM de la figure 6.7 ne fait pas apparaître la spécification de variabilité associée à chaque point de variation. Les modeleurs de VAM et de VRM offrent donc en plus une vue exhaustive des propriétés de chaque élément de modèle, à travers laquelle elles peuvent être éditées. La figure 6.8 illustre les propriétés de l’existence d’objet tree editor de la figure 6.7. Cette figure permet de constater que la variabilité de spécification associée à l’existence d’objet tree editor est le choix tree editor (les propriétés Binding Choice et Binding Vspec ont pour valeur Choice tree editor).Implémentation 115 6.3.2 Les modeleurs de CA abstraits et de liaisons Figure 6.9 – Métamodèle de CA abstraits et de liaisons Dans cette thèse, les modèles de CA abstraits et de liaisons sont définis dans un même modèle, à l’aide d’un modeleur commun. Nous appelons ce dernier le modeleur de CA abstraits et de liaisons. Afin de développer ce modeleur, nous avons utilisé EMF pour définir son métamodèle sous-jacent, le métamodèle de CA abstraits et de liaisons (cf. figure 6.9), et pour générer l’éditeur arborescent correspondant à ce métamodèle, c’est-à-dire le modeleur de CA abstraits et de liaisons en lui-même. Dans le métamodèle de CA abstraits et de liaisons, une liste de CA (ACL, pour Automation Component List) automatise une unité de travail (AutoWU). L’intérêt de la classe ACL est de pouvoir réutiliser une liste d’AC. Les références onStart, onDo et onEnd entre une liste de CA et une unité de travail automatisée spécifient respectivement si la liste de CA automatise l’initialisation, l’execution ou la finalisation de l’unité de travail. Une liste de CA définit un ensemble de CA abstraits (AC, pour Automation Component). Une unité de travail automatisée référence une unité de travail de la ligne de processus via un pointeur d’unité de travail (WUHandle) et son attribut MOFRef, qui correspond à l’URI de l’unité de travail dans la ligne de processus. Si une unité de travail varie, une condition de variante (référence variantCondition) spécifie de quelle variante il s’agit. Des pré-conditions (référence preConditions) et post-conditions (référence PostCond) spécifient respectivement le contexte requis pour exécuter un CA et les résultats attendus de l’exécution d’un CA. La condition de variante ainsi que les pré et post conditions sont des conditions (Condition) exprimées à l’aide d’une expression OCL [OMG10] (OCLExpr). La figure 6.10 illustre un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif, représenté sous forme de diagramme d’objets et non édité avec le modeleur de CA abstraits et de liaisons. Il comprend deux unités de travail automatisées (NewInterpGit et NewInterpSVN), qui sont deux variantes de la tâche de définition116 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.10 – Diagramme d’objets représentant un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif d’un interpréteur (référencée par le pointeur d’unité de travail InterpDef). La condition de variante NoInterpGit (NoInterpSVN) spécifie que l’unité de travail automatisée NewInterpGit (NewInterpSVN) correspond à la tâche de définition de l’interpréteur lors de la première itération du processus et avec Git (SVN) comme SCV (Système de Contrôle de Version). La liste de CA InitInterp initialise cette tâche en créant un projet Kermeta (CA NewKermetaProject) et en générant le patron de conception interpréteur pour chaque métaclasse du métamodèle (CA GeneInterp). La finalisation de cette tâche consiste à mettre le code de l’interpréteur sous contrôle de version. La liste de CA EndInterpGit (EndInterpSVN) réalise cette mise sous contrôle de version via le CA VersionProjectGit (respectivement VersionProjectSVN) quand le SCV est Git (respectivement SVN). La pré-condition ExistMM spécifie que le CA GeneInterp requière l’existence du métamodèle pour son exécution. Une action (Action) permet de lier un CA abstrait à son implémentation. Le métamodèle de CA abstraits et de liaisons définit différents types d’actions : action Kermeta (KermetaAction) et action Java Eclipse (JEclipseAction). Ils définissent la technologie utilisée pour implémenter les CA. Il est bien sûr possible d’ajouter de nouveaux types d’actions (Shell, Groovy,...) en fonction des besoins pour un cas d’application. L’implémentation d’une action Java Eclipse (respectivement d’une action Kermeta) est écrite dans un plug-in Eclipse (respectivement dans l’expression, identifiée par l’at-Implémentation 117 tribut expr, de cette action Kermeta). C’est l’identifiant de l’action Java Eclipse qui permet de faire le lien avec le plug-in Eclipse implémentant cette action, comme nous allons le voir dans la section suivante. Figure 6.11 – Extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de CA abstraits et de liaisons La figure 6.11 illustre un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif de famille de processus de métamodélisation, édité avec le modeleur de CA abstraits et de liaisons. À noter également que cet exrait est différent de celui de la figure 6.10. Cet extrait contient quatre éléments de modèle : une action Java Eclipse (Java Eclipse Action subclipse configuration), un pointeur d’unité de travail (Work Unit Handle metamodel definition), un CA (Primitive AC Create empty EMF project) et une liste de CA (ACL put under version control). 6.3.3 Le framework support à l’implémentation des CA Figure 6.12 – Composants du framework Comme illustré par la figure 6.12, le framework se compose : – du plug-in javaimplementationsupport, qui permet de faire le lien entre un CA et le plug-in Eclipse l’implémentant et qui permet également d’exécuter de manière générique ce plug-in Eclipse, – du plug-in contextualinformationdeclaration, qui permet aux CA de déclarer les informations contextuelles dont ils ont besoin pour s’exécuter, – d’un gestionnaire d’informations contextuelles, dont le but est de trouver la valeur des informations contextuelles. Nous détaillons ces trois composants dans la suite de cette section.118 Outil pour la gestion de la variabilité et l’automatisation des processus 6.3.3.1 Liaison entre un CA et le plug-in Eclipse l’implémentant Le plug-in javaimplementationsupport permet de faire le lien entre un CA spécifié dans le modèle de CA abstraits et de liaisons et le plug-in Eclipse l’implémentant. Ce plug-in fournit en effet un point d’extension, appelé activityautomationregistry, auprès duquel doit s’enregistrer un plug-in Eclipse implémentant un CA. Au moment de cet enregistrement, le lien entre un plug-in Eclipse et un CA est réalisé en spécifiant l’identifiant de l’action Java Eclipse correspondant à ce CA. La figure 6.13 illustre un exemple de déclaration de l’action Java Eclipse implémentée par un plug-in. Sur la partie droite de cette figure se trouvent les informations à renseigner au moment de l’enregistrement auprès du point d’extension activityautomationregistry. L’action Java Eclipse implémentée est déclarée en mettant son identifiant dans le champ action. Figure 6.13 – Enregistrement auprès du point d’extension activityautomationregistry 6.3.3.2 Exécution générique des plug-in Eclipse implémentant les CA Afin de pouvoir lancer de manière générique l’exécution des CA implémentés en Java avec des plug-ins Eclipse, le plug-in javaimplementationsupport fournit une interface, appelée ActivityAutomation, qui doit être implémentée par chaque plug-in. L’implémentation de cette interface consiste à implémenter une méthode run(). C’est cette méthode qui est appelée pour lancer l’exécution d’un CA. Le corps de cette mé- thode doit donc contenir l’implémentation d’un CA. Pour pouvoir appeler la méthode run() de cette interface, il est nécessaire, pour des raisons techniques, de préciser quelle est la classe (d’un plug-in Eclipse correspondant à l’implémentation d’un CA) qui implémente cette méthode. Encore une fois, cette information est fournie au moment de l’enregistrement auprès du point d’extension activityautomationregistry du plug-in correspondant à l’implémentation d’un CA. La figure 6.13 illustre également un exemple de déclaration d’une classe implémentant l’interface ActivityAutomation. Le nom de cette classe est spécifié dans le champ class dans la liste des informations à renseigner au moment de l’enregistrement auprès du point d’extension activityautomationregistry. Toujours afin de pouvoir lancer les CA de manière générique, l’interpréteur de processus doit pouvoir les instancier de manière générique. Chaque classe implémentant l’interface ActivityAutomation doit donc avoir un constructeur Java par défaut.Implémentation 119 6.3.3.3 Gestion de l’accès aux informations contextuelles Chaque CA déclare la liste des informations contextuelles nécessaires à son exé- cution en s’enregistrant auprès du point d’extension parameterregistry, fournit par le plug-in contextualinformationdeclaration. Le gestionnaire d’informations contextuelles se charge d’affecter des valeurs aux informations contextuelles déclarées par les CA. Comme illustré par la figure 6.14, si une information contextuelle peut être capturée par le modèle du processus en cours d’exécution, alors le gestionnaire récupère sa valeur dans ce modèle. Sinon, il la récupère dans un modèle de contexte, qui contient un ensemble de clés/valeurs associant une information contextuelle à sa valeur. L’interpréteur de processus crée un modèle de contexte pour chaque exécution de processus. Si une information contextuelle n’est dans aucun modèle, alors le gestionnaire la demande à l’acteur courant du processus et la sauve dans le modèle de contexte afin qu’elle puisse être réutilisée. Le gestionnaire n’a pas besoin de sauver une information contextuelle dans le modèle du processus en cours d’exécution. En effet, si une information contextuelle pouvant être capturée par le modèle de processus ne l’est pas, alors il s’agit d’un cas de variabilité non résolue qui est traité par l’interpréteur de processus. Au moment de la déclaration des informations contextuelles nécessaires à l’exécution d’un CA, il est possible de spécifier qu’une information est confidentielle. Dans ce cas, cette information n’apparait pas en clair si elle est saisie par l’acteur courant. Figure 6.14 – Comportement du gestionnaire d’informations contextuelles Lorsqu’un CA est réutilisé plusieurs fois dans un même processus, mais avec des120 Outil pour la gestion de la variabilité et l’automatisation des processus artéfacts différents, alors les informations contextuelles liées à ces artéfacts, qui ne peuvent pas être capturées dans le modèle de processus, sont à demander à l’acteur courant, tant qu’elles n’ont pas été écrites dans le modèle de contexte. Par exemple, un CA qui crée un projet Kermeta a besoin pour s’exécuter du nom du projet Kermeta à créer. Or, ce nom sera différent pour chaque projet à créer. Le gestionnaire d’informations contextuelles devra donc demander à chaque fois le nom du projet à créer à l’acteur courant. Cependant, lorsqu’une information contextuelle spécifique à un artéfact est réutilisée par un CA, il faut pouvoir la différencier d’une information contextuelle capturant le même type d’information mais spécifique à un autre artéfact. Par exemple, il faut pouvoir différencier les noms de deux projets Kermeta. Ce problème ne se pose pas avec les informations contextuelles pouvant être capturées dans le modèle de processus. Il est en effet dans ce cas possible de les différencier car elles sont liées à des artéfacts différents. Des CA différents sont utilisés pour demander des informations contextuelles qui doivent être différenciées. Par exemple, dans le cas de la création de projets Kermeta, chaque projet a son propre CA. Chaque CA déclare l’information contextuelle correspondant au nom du projet à créer avec une clé spécifique, afin que celle-ci puisse être différenciée des autres clés dans le modèle de contexte. Afin d’éviter les redondances entre les CA, les traitements métiers qui leur sont communs (par exemple la création d’un projet) sont factorisés dans une même fonction, prenant en paramètres les informations contextuelles spécifiques à chaque CA. Cette manière de gérer les informations contextuelles ne fonctionne que si tous les cas d’utilisation d’un CA sont connus au moment de la définition des CA. Cela n’est pas toujours le cas. Par exemple, lors d’un processus de développement Java, plusieurs projets Java peuvent être créés mais leur nombre n’est souvent pas connu à l’avance. Il n’est donc pas possible de créer autant de CA mettant un projet Java sous contrôle de version que de projets Java. Dans ce cas, un seul CA est créé pour automatiser une TMR particulière. Il demande à l’acteur courant les informations contextuelles spécifiques à des artéfacts et non encore sauvées dans le modèle de contexte. Il écrase l’ancienne valeur de l’information contextuelle dans le modèle de contexte si elle existe, et sinon il crée un nouveau couple clé/valeur. Cette deuxième manière de gérer les informations contextuelles ne fonctionne que si l’ancienne valeur d’une information contextuelle n’est plus utilisée. Dans le cas contraire, une information contextuelle est toujours demandée à l’acteur courant sans jamais la sauver dans le modèle de contexte. Cette dernière manière de gérer les informations contextuelles implique de solliciter plusieurs fois l’acteur courant pour lui demander la même chose, ce qui est source d’erreurs. Nous ne la réservons donc que pour les cas où les deux premières manières de procéder ne sont pas adéquates. Le gestionnaire d’informations contextuelles doit être en mesure de déterminer si i) une information n’est à demander à l’acteur courant que si elle n’est pas déjà dans le modèle de contexte, ii) une information est à demander à l’acteur courant et son ancienne valeur doit être écrasée dans le modèle de contexte, ou iii) une information est demandée à l’acteur courant sans sauvegarde dans le modèle de contexte. À cette fin, les CA, lorsqu’ils déclarent les informations contextuelles nécessaires à leur exécution,Implémentation 121 spécifient comment chaque information doit être traitée. Afin que l’acteur courant puisse se concentrer sur la réalisation d’autres tâches pendant que les CA s’exécutent, il est nécessaire qu’il n’ait pas à donner des informations contextuelles aux CA au fur et à mesure de leur exécution. Aussi, le gestionnaire récupère les valeurs de toutes les informations contextuelles nécessaires à l’exécution d’une liste de CA au début de l’exécution de cette liste. Le principal intérêt du gestionnaire d’informations contextuelles est qu’il découple l’accès aux informations contextuelles de l’implémentation des CA. Cela permet de rendre les CA plus réutilisables. En effet, l’accès aux informations contextuelles (et donc le gestionnaire d’informations contextuelles) dépend du langage de modélisation de processus utilisé, puisque selon ce langage une information contextuelle est récupérée dans le modèle du processus en cours d’exécution ou dans le modèle de contexte. Gérer l’accès aux informations contextuelles directement dans l’implémentation des CA aurait donc rendu ces CA dépendant du langage de modélisation de processus utilisé. Figure 6.15 – Extrait du modèle de contexte d’un processus de métamodélisation avec contrôle de version Figure 6.16 – Exemple de déclaration par un CA d’informations contextuelles La figure 6.15 illustre un extrait du modèle de contexte d’un processus de métamodélisation avec contrôle de version. Ce modèle de contexte contient la clé url of the remote repository, qui correspond à l’URL du dépôt distant sur lequel partager des ressources. À cette clé est associée la valeur file :///C :/Users/erouille/depotsvn. La figure 6.16 illustre un exemple de déclaration par un CA des informations contextuelles nécessaires à son exécution. Il s’agit ici d’un CA qui connecte l’espace de travail Eclipse d’un acteur courant du processus à un nouveau dépôt SVN distant. Ce CA a besoin pour s’exécuter de trois informations contextuelles : l’URL du dépôt SVN distant (url of the remote repository), le nom d’utilisateur (username to connect to the remote repository) et le mot de passe (password to connect to the remote repository) de122 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.17 – Exemple de demande d’informations contextuelles à l’acteur courant du processus l’acteur courant. Cette dernière information est ici déclarée comme confidentielle. La figure 6.17 illustre la demande de ces informations contextuelles à l’acteur courant d’un processus de métamodélisation de l’exemple illustratif. Cette demande a lieu au moment de la finalisation de la définition d’un interpréteur. Pour rappel, la finalisation de la définition d’un interpréteur consiste à mettre cet interpréteur sous contrôle de version. Plus précisément, la mise sous contrôle de version d’un interpréteur consiste à connecter l’espace de travail Eclipse du développeur de l’interpréteur à un dépôt SVN distant, puis à exporter sur ce dépôt le projet Kermeta contenant le code source de l’interpréteur. Les informations contextuelles demandées ne peuvent pas être capturées dans un modèle de processus SPEM et n’ont pas déjà été sauvées dans le modèle de contexte à ce stade de l’exécution du processus. 6.3.4 L’assistant à la résolution de la variabilité L’assistant à la résolution de la variabilité que nous avons développé parcourt un VAM et pour chaque spécification de variabilité de ce VAM dont la résolution n’est pas dérivée, il demande à l’utilisateur de la ligne de processus de résoudre la variabilité via une interface. La manière de résoudre la variabilité qui est proposée dans l’interface dépend du type de spécification de variabilité, afin d’assurer le respect de la spécification de CVL. Par exemple, pour faire un choix, l’utilisateur de la ligne de processus ne peut que donner une réponse booléenne en sélectionnant ou non une case à cocher. De plus, la résolution de certaines spécifications de variabilité peut être forcée afin d’assurer le respect des contraintes entre les spécifications de variabilité du VAM. Par exemple, si un choix est obligatoire il est automatiquement sélectionné et l’utilisateur de la ligne de processus ne peut pas modifier cette résolution. Si deux choix sont mutuellement exclusifs alors l’interface ne permet de sélectionner qu’un seul de ces deux choix. Si des choix peuvent être combinés, l’interface permet alors deImplémentation 123 sélectionner plusieurs de ces choix. L’assistant à la résolution de la variabilité crée dans un RM les résolutions de spécifications de variabilité (VSpecResolution, section 2.3.2). L’utilisateur de la ligne de processus a également la possibilité de passer la résolution d’une spécification de variabilité, dans le cas où la variabilité ne peut pas être résolue tout de suite. Dans ce cas, les résolutions de spécification de variabilité associées ne sont pas créées dans le RM. Figure 6.18 – Utilisation de l’assistant à la résolution de la variabilité avec l’exemple illustratif de famille de processus de métamodélisation La figure 6.18 illustre l’utilisation de l’assistant à la résolution de la variabilité avec l’exemple illustratif de famille de processus de métamodélisation. Cet assistant permet à un utilisateur de la ligne de processus de résoudre la variabilité du VAM de la famille de processus de métamodélisation (cf. figure 4.9 pour un extrait de ce VAM) en résolvant les choix tree editor, compiler, interpreter, checker, textual editor, XText, EMFText, SVN et Git. Le choix version control system étant obligatoire, il est déjà sélectionné et il n’est pas possible de changer cette résolution. Les choix tree editor, compiler, interpreter, checker et textual editor n’étant pas mutuellement exclusifs, des cases à cocher sont utilisées pour les résoudre. Comme les choix XText et EMFText d’une part et SVN et Git d’autre part sont mutuellement exclusifs, des boutons radio sont utilisés pour les résoudre. Il est possible de passer la résolution de la variabilité d’un choix en cochant la case skip the resolution of this variability specification associée à ce choix.124 Outil pour la gestion de la variabilité et l’automatisation des processus 6.3.5 Le moteur de dérivation CVL Figure 6.19 – Comportement du moteur de dérivation CVL Nous décrivons ici le fonctionnement du moteur de dérivation CVL que nous avons implémenté dans le cadre de cette thèse. Comme illustré par la figure 6.19, pour chaque résolution de choix d’un RM, le moteur de dérivation CVL trouve le choix correspondant dans le VAM. Ensuite, le moteur de dérivation CVL trouve les points de variation qui sont associés à ce choix. Si le choix est sélectionné, ces points de variation sont exécutés conformément à la sémantique définie dans la spécification de CVL. Le cas échéant, les objets optionnels associés à des points de variation de type ObjectExistence sont supprimés. Les points de variation s’exécutent sur une copie du modèle de processus de base, afin de créer un modèle de processus résolu sans écraser le modèle de processus de base.Implémentation 125 Figure 6.20 – Comportement de l’interpréteur de processus126 Outil pour la gestion de la variabilité et l’automatisation des processus 6.3.6 L’interpréteur de processus Nous détaillons maintenant l’interpréteur de processus développé dans le cadre de cette thèse. Son fonctionnement est illustré par la figure 6.20. Lors de son lancement, l’interpréteur de processus commence par afficher dans une vue spécifique, la vue processus, les différentes unités de travail qui composent le processus à exécuter. L’interpréteur de processus démarre ensuite l’exécution du processus, en fonction de la sémantique des diagrammes d’activités UML 2. Cependant, avant l’exécution d’un élément de processus, l’interpréteur de processus détermine si de la variabilité non ré- solue est associée à cet élément de processus. Si c’est le cas, l’interpréteur de processus appelle l’assistant à la résolution de la variabilité avec en paramètre les spécifications de variabilité non résolues associées à l’élément de processus courant, afin que l’acteur courant du processus résolve cette variabilité. Une fois la variabilité résolue, l’interpréteur met à jour le processus en cours d’exécution en fonction de la résolution de la variabilité, et met également à jour la vue processus. Pour mettre à jour le processus en cours d’exécution, l’interpréteur exécute sur ce processus les points de variation associés aux spécifications de variabilité qui viennent d’être résolues positivement. Figure 6.21 – Détection de variabilité non résolue Pour déterminer si de la variabilité non résolue est associée à un élément de processus, l’interpréteur cherche dans le VRM si des points de variation référencent cet élément de processus. Si de tels points de variation existent, l’interpréteur vérifie dans le RM si les spécifications de variabilité associées à ces points de variation sont toutes résolues. Si tel n’est pas le cas, cela signifie que de la variabilité n’est pas résolue. La figure 6.21 illustre la détection de variabilité non résolue par l’interpréteur. Si l’élément de processus à exécuter est une unité de travail, alors l’interpréteur affiche dans la vue processus l’étape (initialisation, exécution, finalisation) de cette unité de travail qui peut être lancée. L’ordre entre les étapes d’une unité de travail est respecté. C’est-à-dire qu’une étape peut être lancée seulement si les étapes précédentes ont été réalisées. Par exemple, la finalisation ne peut être lancée que si l’exécution a déjàImplémentation 127 été réalisée. De plus, une initialisation ou une finalisation ne peut être lancée que si elle est automatisée, alors qu’une exécution peut être lancée qu’elle soit automatisée ou manuelle. Lorsque la finalisation d’une unité de travail est terminée (ou son exécution si elle n’a pas de finalisation), l’interpréteur de processus exécute les éléments de processus qui suivent cette unité de travail dans le processus. C’est l’acteur courant qui lance l’initialisation, l’exécution ou la finalisation d’une unité de travail. Cela lui permet de suivre l’exécution du processus. Ainsi, s’il a une tâche manuelle à réaliser pour participer à l’exécution du processus, il saura où l’exécution en est rendue et donc ce qui a déjà été fait et qu’il n’a pas à refaire. L’initialisation ou la finalisation d’une unité de travail consiste à lancer automatiquement l’exécution de la liste de CA associée. L’exécution d’une unité de travail consiste à faire de même lorsque celle-ci est automatisée. Sinon, l’interpréteur informe l’acteur courant qu’il doit réaliser l’exécution manuellement et attend que ce soit fait avant de continuer l’exécution du processus. Lancer l’exécution d’une liste de CA consiste à lancer l’exécution de ses CA, dans leur ordre de définition. Pour lancer l’exé- cution d’un CA associé à une action Kermeta, l’interpréteur appelle une fonction qui évalue dynamiquement l’expression de cette action. Pour lancer l’exécution d’un CA associé à une action Java Eclipse, l’interpréteur trouve le plug-in qui est relié à cette action et appelle la méthode run() de la classe implémentant le CA. Si une unité de travail est optionnelle, l’interpréteur de processus offre à l’acteur courant la possibilité de passer l’exécution de cette unité de travail. Attention, ici nous considérons une unité de travail qui est optionnelle dans un processus résolu, ce qui dénote donc de la variabilité au moment de l’exécution du processus (et non au moment de sa conception), tout comme les nœuds de décision par exemple. L’interpréteur de processus capture également les traces d’exécution de processus, afin de savoir quelle est l’itération de processus en cours et par quels flots de contrôle une unité de travail est accédée ou quittée. L’exécution de certains CA dépend en effet de ce qui se passe avant ou après l’unité de travail qu’ils automatisent. Par exemple, dans le cas de la famille de processus de métamodélisation, le CA créant un nouveau projet Kermeta au début de la tâche de définition d’un interpréteur ne s’exécute que lors de la première itération du processus. La figure 6.22 illustre la vue processus d’une variante de processus de métamodélisation comprenant les tâches de définition d’un métamodèle, d’un éditeur arborescent, d’un interpréteur, d’un compilateur et d’un vérificateur. Chacune de ces tâches a des boutons on start, on do, done, on end et skip. Ces boutons permettent de lancer l’initialisation d’une unité de travail (on start), de lancer l’exécution d’une unité de travail (on do), de signaler que l’exécution manuelle d’une unité de travail est terminée (done), de lancer la finalisation d’une unité de travail (on end) et de passer l’exécution d’une unité de travail lorsque celle-ci est optionnelle (skip). Sur la figure 6.22, l’exécution du processus vient juste de démarrer. Aussi, seule l’initialisation de la tâche de définition d’un métamodèle, ici automatisée, peut être lancée. En effet, sur la figure 6.22 seul le bouton on start lié à cette tâche est actif, les autres étant grisés.128 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.22 – Vue processus d’une variante de processus de métamodélisation 6.4 Discussion Nous énonçons dans cette partie des recommandations pour implémenter les CA et les relier à leurs contextes d’utilisation (section 6.4.1), puis nous abordons les extensions possibles à T4VASP (section 6.4.2). 6.4.1 Recommandations Lorsque la ligne de processus spécifie qu’un outil peut être substitué par un autre, alors, dans l’implémentation des CA, les parties qui dépendent de cet outil doivent être découplées des parties qui n’en dépendent pas. Cela permet de pouvoir réutiliser ces dernières lorsque l’outil est remplacé. Dans le modèle de CA abstraits et de liaisons, l’architecte doit spécifier pour quels séquencements et pour quelles itérations d’une unité de travail des CA sont appropriés, si les CA dépendent de ces séquencements et de ces itérations. En effet, la variabilité de ce qui se passe avant ou après une unité de travail (entre les différentes variantes d’un processus ou au sein d’une même variante de processus) peut impliquer de la variabilité au niveau des CA qui automatisent cette unité de travail. Des CA peuvent donc être requis, inutiles ou inutilisables en fonction de ce qui se passe avant ouDiscussion 129 après une unité de travail. De plus, une unité de travail peut varier en fonction de ses itérations. Par exemple, la première itération d’une unité de travail peut consister à créer des artéfacts, tandis que les itérations suivantes consistent à modifier ces derniers. Cela peut impliquer des variations des CA qui automatisent cette unité de travail ainsi que des CA automatisant les unités de travail précédentes et suivantes. 6.4.2 Extensions Actuellement, T4VASP fonctionne uniquement dans un environnement local. Or, plusieurs personnes peuvent participer à la réalisation d’un processus de développement logiciel, chacune avec son propre poste informatique. Il est donc important que l’automatisation de l’exécution d’un processus puisse se faire dans un environnement distribué. Une extension serait donc que T4VASP devienne une application client-serveur, et que l’exécution d’un processus soit centralisée sur la partie serveur, tandis que les automatisations des TMR s’exécuteraient sur les postes clients. Ainsi, plusieurs personnes pourraient partager l’exécution d’un même processus. L’interpréteur de processus ne permet actuellement pas à l’acteur courant du processus de lancer l’initialisation ou la finalisation d’une unité de travail si ces initialisations et finalisations ne sont pas automatisées. En effet, comme SPEM 2.0 ne permet pas de définir d’initialisation et de finalisation à une unité de travail, l’interpréteur ne peut pas savoir si une unité de travail a une initialisation ou une finalisation, à moins que celle-ci soit automatisée car cela est dans ce cas spécifié dans le modèle de CA abstraits et de liaisons. Si une initialisation ou une finalisation n’est pas spécifiée elle peut être omise par l’acteur courant du processus. Lorsqu’une unité de travail a une initialisation ou une finalisation manuelle, la seule manière de le spécifier en SPEM 2.0 est de faire précéder (suivre) cette unité de travail par une autre unité de travail consistant en l’initialisation (la finalisation). Par exemple, si l’unité de travail U1 a une initialisation manuelle, cela pourra apparaître dans un modèle de processus SPEM 2.0 en faisant précéder U1 d’une unité de travail U0 consistant à réaliser l’initialisation. Mais l’inconvénient de cette solution est que les initialisations et les finalisations ne sont pas fortement couplées aux unités de travail qu’elles initialisent ou finalisent. Il est donc possible pour un humain d’omettre l’initialisation ou la finalisation d’une unité de travail lors de sa réutilisation. Par exemple lors de la création d’un nouveau modèle de processus contenant l’unité de travail U1 précédente, la personne en charge de la modélisation peut omettre de faire précéder U1 de U0. Une extension à T4VASP serait donc de faire évoluer le métamodèle de CA abstraits et de liaisons de manière à pouvoir spécifier qu’une initialisation ou une finalisation est manuelle. Dans le cas où une initialisation, exécution ou finalisation d’unité de travail est composée à la fois d’étapes automatisées et manuelles, l’outillage actuel impose de dé- finir dans le modèle de processus les unités de travail à un niveau de granularité plus fin, de sorte qu’une initialisation, exécution ou finalisation soit complètement manuelle ou complètement automatisée. L’outillage actuel ne prend en effet pas en compte les initialisations, exécutions ou finalisations partiellement automatisées. Ainsi, si l’exé- cution d’une unité de travail U1 consiste par exemple à réaliser trois actions, A1, A2130 Outil pour la gestion de la variabilité et l’automatisation des processus et A3, avec A1 et A3 automatisées et A2 manuelle, alors dans le modèle de processus U1 devra être décomposée en trois unités de travail, consistant respectivement en la réalisation des actions A1, A2 et A3. Si les actions A1 et A3 peuvent être considérées comme les initialisations et finalisations respectives de A2, une autre solution serait de définir A1 comme initialisation de U1, A2 comme exécution de U1 et A3 comme finalisation. Cela conduit à des définitions de processus plus détaillées. Afin de satisfaire le cas où les utilisateurs d’un modèle de processus préfèrent une définition plus abstraite, une extension à T4VASP serait de faire évoluer le métamodèle de CA abstraits et de liaisons de manière à pouvoir spécifier des listes d’AC qui soient entrecoupées de tâches manuelles et ainsi pouvoir gérer les initialisations, exécutions ou finalisations partiellement automatisées. 6.5 Synthèse Nous avons présenté dans ce chapitre T4VASP, l’outil support à l’approche proposée dans cette thèse. T4VASP se compose de 8 composants : un modeleur de VAM, un modeleur de VRM, un assistant à la résolution de la variabilité, un moteur de dérivation CVL, un modeleur de CA abstraits et de liaisons, un framework supportant l’implémentation des CA ainsi qu’un interpréteur de processus. T4VASP permet de définir une ligne de processus, de lier des CA à cette ligne de processus, de dériver automatiquement un processus de la ligne de processus en fonction des exigences d’un projet et d’automatiser l’exécution d’un processus. Il permet de plus de prendre en charge la variabilité non résolue au fur et à mesure de l’exécution d’un processus. T4VASP offre également des avantages dans la manière dont il met en œuvre l’approche proposée. Ainsi, au moment de la liaison des CA à la ligne de processus, T4VASP permet à l’architecte de spécifier l’étape (initialisation, exécution ou finalisation) d’une unité de travail qu’une liste de CA automatise, ainsi que l’ordre d’exécution de ces CA. Cela permet de définir plus finement l’automatisation des processus et également d’assurer que les initialisations et finalisations des unités de travail ne sont pas omises. T4VASP offre de plus un support à la résolution de la variabilité, i) en abstrayant le VAM des informations non pertinentes pour la personne en charge de la résolution de la variabilité, ii) en forçant le respect des contraintes entre les spécifications de variabilité et iii) en assurant le respect de la spécification de CVL. Au moment de l’exé- cution d’un processus, T4VASP offre un mécanisme permettant de lancer les CA qui automatisent ce processus de manière générique, ce qui en fait un outil indépendant des CA associés à une ligne de processus. De plus, les CA peuvent avoir accès aux informations contextuelles dont ils ont besoin pour s’exécuter, y compris celles qui ne peuvent pas être capturées par le modèle du processus en cours d’exécution. En effet, T4VASP demande ces informations contextuelles à l’acteur courant du processus et les sauvegarde dans un modèle contexte. Toutefois, afin que l’acteur courant du processus puisse se concentrer sur d’autres tâches pendant l’exécution d’une liste de CA, toutes les informations contextuelles nécessaires sont demandées au début de l’exécution de la liste. Pendant l’exécution d’un processus, T4VASP informe l’acteurSynthèse 131 courant du processus lorsque des interventions manuelles sont requises de sa part, afin d’assurer le bon déroulement de l’exécution. Enfin, T4VASP permet à l’acteur courant du processus de suivre l’exécution du processus, car c’est cet acteur courant qui lance les initialisations, exécutions et finalisations des unités de travail. Nous avons également identifié plusieurs extensions à T4VASP. Ainsi, faire évoluer T4VASP vers une application client-serveur permettrait l’exécution de processus en environnements distribués, ce qui correspond à la majorité des contextes de réalisation de projets de développement logiciel. D’autre part, spécifier, dans le modèle de CA abstraits et de liaisons, qu’une initialisation ou une finalisation d’unité de travail est manuelle permettrait que l’acteur courant d’un processus puisse les lancer même si elles ne sont pas automatisées. Enfin, en faisant évoluer le métamodèle de CA abstraits et de liaisons de manière à pouvoir spécifier que des listes d’AC sont entrecoupées de tâches manuelles, les utilisateurs d’un modèle de processus auraient la liberté de le définir au niveau d’abstraction qui leur convient le mieux. Ils pourraient en effet définir des unités de travail composées à la fois de tâches manuelles et automatisées. Nous avons actuellement implémenté uniquement les fonctionnalités de T4VASP dont nous avions besoin pour pouvoir l’utiliser avec les cas d’application présentés dans le chapitre suivant. Afin d’assurer que T4VASP soit utilisable quel que soit le cas d’application, il reste donc à implémenter les fonctionnalités suivantes : – prise en compte de l’ensemble de CVL par l’assistant à la résolution de la variabilité et par le moteur de dérivation, – évaluation dynamique des expressions Kermeta, – évaluation des conditions (liées aux AC ou aux unités de travail automatisées) définies dans un modèle de CA abstraits et de liaisons, – découplage de l’accès aux informations contextuelles de l’implémentation des CA, – résolution de la variabilité à l’exécution. Nous évaluons le degré de maturité de T4VASP au niveau TRL (Technology Readiness Level) 2, où le TRL est une mesure permettant d’évaluer la maturité d’une technologie [oD11]. Au niveau TRL 2, les concepts et des applications d’une technologie ont été définis, mais la technologie n’est pas encore prête à être utilisée sur n’importe quel cas d’application. Le code source de T4VASP peut être consulté à l’adresse suivante : https: //github.com/emmanuellerouille/T4VASP/tree/master/source_code.132 Outil pour la gestion de la variabilité et l’automatisation des processusChapitre 7 Applications de l’approche À ce jour, T4VASP a été appliqué à deux cas : la famille de processus de métamodé- lisation qui sert d’exemple illustratif tout au long de cette thèse, ainsi qu’une famille simplifiée de processus de développement web Java issue de Sodifrance. Pour ce faire, nous avons pour chacun de ces deux cas défini une ligne de processus de développement logiciel en nous appuyant sur CVL4SP (section 4.2). Nous avons donc spécifié dans un VAM la variabilité au niveau des exigences des projets, défini un modèle de processus de base afin de capturer les éléments de modèle nécessaires à la création des différents processus de la famille, et défini un VRM afin de spécifier comment dériver un processus résolu du modèle de processus de base en fonction des exigences des projets. Nous avons utilisé l’outil SPEM-Designer pour modéliser les processus de base. Nous avons ensuite identifié et implémenté des CA pour chaque cas d’application en suivant M4RAC (section 5.2). Nous avons pour ce faire créé un modèle de CA abstraits et de liaisons pour chacuns des deux cas d’application. Toujours pour chacun des deux cas, un modèle de processus résolu a été dérivé en fonction d’une sélection d’exigences. Ce modèle de processus a ensuite été exécuté, et les CA qui lui sont liés ont été lancés au fur et à mesure de cette exécution. Nous détaillons dans la suite de ce chapitre les deux cas d’application. Les sections 7.1 et 7.2 présentent respectivement l’application à la famille de processus de métamodélisation et l’application à la famille de processus de développement web Java. 7.1 Application sur une famille de processus de métamodélisation Nous appliquons dans cette section T4VASP à une famille de processus de métamodélisation, issue de l’équipe de recherche Triskell. Il s’agit de la famille qui a servi d’exemple illustratif à CVL4SP et T4VASP. Nous invitons donc le lecteur à se référer aux sections 4.1 et 6.1 pour une description complète de cette famille de processus et des tâches qui ont lieu durant l’exécution des processus de cette famille et qui gagneraient à être automatisées. 133134 Applications de l’approche Le VAM de la famille de processus de métamodélisation contient 39 éléments de modèle. Ce VAM permet de capturer les exigences de 128 projets différents, chacun ayant un processus différent. Le modèle de processus de base ainsi que le VRM de la famille de processus de métamodélisation contiennent quant à eux respectivement 134 et 123 éléments de modèle. Le VAM, le modèle de processus de base, ainsi que le VRM forment donc une ligne de processus permettant de capturer 128 processus différents. Le modèle de CA abstraits et de liaisons contient 27 éléments de modèle. Nous avons implémenté 10 CA en Java : 1. un CA permettant de créer un nouveau projet EMF avec un nouveau fichier Ecore vide, 2. un CA permettant de valider un métamodèle Ecore, 3. un CA permettant de générer un éditeur arborescent, 4. un CA permettant de créer un nouveau projet XText, 5. un CA permettant de créer un nouveau projet Kermeta et de l’initialiser avec un appel à une fonction Kermeta qui vérifie qu’un modèle respecte bien les contraintes définies sur son métamodèle, 6. un CA permettant de créer un nouveau projet Kermeta et de l’initialiser avec la génération du patron de conception interpréteur pour chaque méta-classe d’un métamodèle, 7. un CA permettant de créer un nouveau projet Kermeta et de l’initialiser avec la génération du patron de conception visiteur pour chaque méta-classe d’un métamodèle, 8. un CA permettant de connecter un espace de travail Eclipse à un dépôt SVN distant, 9. un CA permettant de mettre un projet sous contrôle de version, 10. un CA permettant de propager avec SVN du code source vers un dépôt distant. Le CA 1 initialise la définition d’un métamodèle. Il a besoin de deux informations contextuelles pour s’exécuter : le nom du projet EMF et le nom du fichier Ecore. Le gestionnaire d’informations contextuelles les demande à l’acteur courant du processus puis les sauvegarde dans le modèle de contexte. Le CA 2 finalise la définition d’un métamodèle et le CA 3 exécute la tâche de définition d’un éditeur arborescent. Ces deux CA ont besoin pour cela des deux mêmes informations contextuelles : le nom du projet EMF et du fichier Ecore contenant la définition du métamodèle. Le gestionnaire d’informations contextuelles trouve ces informations dans le modèle de contexte, où elles ont été préalablement écrites. Le CA 4 initialise la définition d’un éditeur textuel, lorsque celle-ci est réalisée avec l’outil XText. Ce CA utilise l’information contextuelle correspondant au nom du projet EMF contenant la définition du métamodèle. Cette information est récupérée dans le modèle de contexte par le gestionnaire d’informations contextuelles. Ce CA nécessite également une autre information contextuelle pour s’exécuter, à savoir leApplication sur une famille de processus de métamodélisation 135 Figure 7.1 – Point d’entrée du CA permettant de générer un éditeur arborescent nom du projet XText à créer. Le gestionnaire d’informations contextuelles demande cette information à l’acteur courant du processus. Les CA 5, 6 et 7 initialisent respectivement les tâches de définition d’un vérificateur, d’un interpréteur et d’un compilateur. Ils ont besoin tous les trois pour s’exécuter du nom du projet Kermeta à créer, ainsi que du nom du projet EMF et du fichier Ecore contenant la définition du métamodèle. Le gestionnaire d’informations contextuelles demande le nom du projet à créer à l’acteur courant du processus et récupère dans le modèle de contexte le nom du projet EMF et du fichier Ecore contenant la définition du métamodèle. La création d’un projet Kermeta est commune à ces trois CA et n’est pas factorisée dans son propre CA. En effet, les initialisations des projets Kermeta (appel à une fonction Kermeta vérifiant qu’un modèle respecte bien les contraintes définies sur son métamodèle et génération du patron de conception interpréteur ou compilateur) ont besoin pour s’exécuter de connaître le nom du projet à initialiser, qui est différent dans les trois cas. Il faut donc pouvoir différencier les noms des projets Kermeta. De plus, le nom d’un projet Kermeta ne peut pas être écrasé dans le modèle de contexte car il est réutilisé dans le cas de l’interpréteur pour sa mise sous contrôle de version (et l’information pourrait être écrasée avant que la mise sous contrôle de version n’ait lieu car les tâches de définition d’un interpréteur, d’un compilateur et d’un vérificateur s’exécutent en parallèle). Nous avons vu, dans la section 6.3.3, que dans ce cas des CA différents automatisent la même TMR, mais en demandant chacun des informations contextuelles spécifiques aux artéfacts qu’ils impactent. Les CA 8, 9 et 10 finalisent la tâche de définition d’un interpréteur. Le CA 8 a besoin pour s’exécuter de l’URL d’un dépôt SVN distant, ainsi que d’un nom d’utilisateur et d’un mot de passe pour se connecter à ce dépôt distant. Le gestionnaire d’informations contextuelles demande ces trois informations à l’acteur courant du processus. Les CA 9 et 10 ont besoin pour s’exécuter du nom du projet dont le contrôle de version doit être géré (ici le projet Kermeta contenant le code source de l’interpréteur). Le CA 9 a de plus besoin de connaître l’URL du dépôt SVN distant. Le gestionnaire d’informations contextuelles récupère toutes ces informations dans le modèle de contexte. Ici,136 Applications de l’approche Figure 7.2 – Méthode run de la classe GenerateTreeEditor, appelée par la méthode run de la figure 7.1 l’automatisation de la propagation avec SVN du code source vers un dépôt distant est mise dans son propre CA (ici le 10), afin de pouvoir la réutiliser indépendamment des CA 8 et 9. En effet, la première fois que la tâche de définition d’un interpréteur a lieu, il faut, lors de sa finalisation, exécuter les CA 8, 9 et 10, alors que les fois suivantes, seul le CA 10 doit être exécuté. Nous avons implémenté l’automatisation de la connexion d’un workspace Eclipse à un dépôt SVN distant et la mise d’un projet sous contrôle de version, dans des CA séparés, les CA 8 et 9, afin de séparer les préoccupations. Les figures 7.1 à 7.4 présentent des extraits de code des CA. C’est la méthode run de la figure 7.1 qui est appelée pour exécuter le CA 3, qui permet de générer un éditeur arborescent. Cette méthode fait elle-même appel à la méthode run de la figure 7.1, qui contient le code générant l’éditeur arborescent. Dans un premier temps (lignes 53 à 83) les noms du projet EMF et du fichier Ecore contenant la définition du métamodèle sont récupérés dans le modèle de contexte. Rappelons à cette occasion que commeApplication sur une famille de processus de métamodélisation 137 Figure 7.3 – Point d’entrée du CA initialisant la tâche de définition d’un interpréteur indiqué en section 6.5, le découplage de l’accès aux informations contextuelles de l’implémentation du CA, grâce au gestionnaire d’informations contextuelles, n’a pas encore été implémenté. Le code restant (de la ligne 83 à la fin) permet quant à lui de générer l’éditeur arborescent, en fonction du nom du projet EMF et du fichier Ecore précédemment récupérés. La méthode run de la figure 7.3 est appelée pour exécuter le CA 6, qui crée un nouveau projet Kermeta et l’initialise avec la génération du patron de conception interpréteur. Cette méthode appelle la méthode run de la figure 7.4. Cette dernière méthode commence par créer un nouveau projet Kermeta (lignes 59 à 67), puis elle appelle la méthode generateInterpreter (ligne 69). Cette dernière génère dans le projet Kermeta nouvellement créé le patron interpréteur pour chaque métaclasse d’un métamodèle, dont le nom du projet EMF et du fichier Ecore correspondant sont récupérés dans le modèle de contexte (cf. lignes 75 à 79). Le début de la méthode generateInterpreter est présenté à partir de la ligne 72. Pour résoudre la variabilité, au maximum 7 choix sont à faire dans ce cas. Il faut en effet déterminer si un interpréteur, un compilateur, un éditeur textuel, un éditeur arborescent ou un vérificateur sont requis pour un projet donné. Dans le cas ou un interpréteur (respectivement un éditeur textuel) est requis, la personne en charge de la résolution de la variabilité doit également déterminer si c’est l’outil SVN ou Git (respectivement XText ou EMFText) doit être utilisé. Dans le cadre de ce cas d’application, nous avons sélectionné un interpréteur, un compilateur, un éditeur arborescent ainsi qu’un vérificateur. Nous avons également sélectionné l’outil SVN comme SCV. La figure 7.5 illustre le processus résolu correspondant.138 Applications de l’approche Figure 7.4 – Extrait des méthodes permettant l’initialisation d’un interpréteur Kermeta Une démonstration du cas d’application de la famille de processus de métamodélisation peut être visualisée à l’adresse suivante : http://youtu.be/NYZT5cA5-cY. Les modèles ainsi que les CA relatifs à ce cas d’utilisation peuvent être consultés sur le dépôt SVN suivant : http://t4vasp.googlecode.com/svn/trunk/application_ metamodeling_process_line. Nous en présentons un extrait dans l’annexe A.Application sur une famille de processus de développement web Java 139 Figure 7.5 – Modèle de processus résolu du cas d’application de la famille de processus de métamodélisation 7.2 Application sur une famille de processus de développement web Java Nous présentons dans cette section l’application de T4VASP à une famille simplifiée de processus de développement d’une application web en Java, issue de Sodifrance. Nous commençons par présenter cette famille. Pour ce faire, nous introduisons d’abord un exemple simplifié de processus de développement web Java, illustré dans la figure 7.6. Nous détaillons ensuite des exemples de variantes de ce processus ainsi que les TMR qui ont lieu durant l’exécution des processus de cette famille et qui gagneraient à être automatisées. La sous-figure 7.6(a) montre le flot d’activités du processus de développement web Java illustré dans la figure 7.6, ainsi que les produits de travail consommés et produits par ces activités. L’exemple de processus de développement web Java présenté commence avec l’activité spécifier. Durant cette activité, un client produit un document définissant les spécifications techniques et fonctionnelles de l’application à développer, en fonction des exigences d’un projet. Vient ensuite l’activité développer, qui consiste à coder manuellement l’application à développer. L’activité tester suit, durant laquelle des développeurs testent l’application en cours de développement. Si cette activité révèle des erreurs dans le code de l’application, celles-ci doivent être corrigées, ce qui se traduit dans le processus par un retour à l’activité de développement. S’il n’y a pas d’erreurs, le processus se termine par l’activité mettre en140 Applications de l’approche (a) Flot d’activités et produits de travail associés (b) Détail de l’activité développer (c) Outils utilisés pendant l’activité développer Figure 7.6 – Un exemple simplifié de processus de développement web Java production, qui consiste à déployer l’application sur l’environnement du client. La sous-figure 7.6(b) détaille l’activité de développement. Celle-ci consiste, dans le cas de cet exemple, en la création et la modification de projets Eclipse. La sous-Application sur une famille de processus de développement web Java 141 figure 7.6(c) détaille les outils utilisés lors de l’activité de développement. L’environnement de développement est Eclipse, le SCV est SVN, le serveur web est Tomcat 1 , la base de données est MySQL 2 , le framework pour l’IHM web est Struts 3 et l’outil de compilation est Maven 4 . Il existe des variantes de ce processus, dont quelques exemples sont présentés dans ce paragraphe. Ainsi, si le client fournit les spécifications dans un langage interprétable par un ordinateur (par exemple UML 2), alors une activité de génération de code a lieu avant l’activité de développement. L’activité de génération de code consiste à générer le code Java qui est similaire pour toutes les entités de l’application à développer. Lorsque l’activité de génération de code a lieu, alors l’activité de développement consiste juste à rajouter manuellement le code qui n’a pas pu être généré. L’activité de mise en production peut également prendre des formes différentes. En effet, pendant cette activité, selon les exigences du client, la livraison de l’application peut se faire en livrant uniquement le code source de l’application, en livrant uniquement le code compilé de l’application, en livrant les deux (code source et code compilé), ou un ingénieur de Sodifrance peut aller chez le client pour installer lui-même l’application. Les exigences des projets peuvent également motiver l’utilisation d’outils autres que ceux présentés dans la sous-figure 7.6(c). Par exemple, une base de données Oracle 5 ou Postgresql 6 peut être utilisée à la place de la base de données MySQL, et il peut même ne pas y avoir de base de données s’il n’y a pas de donnée à persister. De même, Ant 7 peut être utilisé à la place de Maven, et un framework autre que Struts peut être utilisé pour l’IHM web, tel que JSF 8 (Java Server Faces), Flex 9 ou GWT 10 (Google Web Toolkit). Des TMR qui gagneraient à être automatisées ont lieu durant l’exécution des processus de cette famille. Nous en présentons ici quelques exemples. Ainsi, lors de l’initialisation de l’activité développer, chaque développeur et architecte doit configurer son environnement de travail Eclipse. Cette configuration consiste, entre autres, à installer les plug-ins Eclipse WTP 11 et Subclipse 12 (plug-ins permettant respectivement d’utiliser Tomcat et SVN dans Eclipse), à créer dans l’environnement de travail Eclipse un nouveau serveur Tomcat et à connecter l’espace de travail Eclipse à un dépôt SVN distant. Lors de l’initialisation de l’activité de développement, un architecte est de plus en charge de créer un nouveau dossier sur ce dépôt distant, qui contiendra le code de l’application à développer. La création d’un projet Eclipse se termine toujours par sa 1. http://tomcat.apache.org/ 2. http://www.mysql.com/ 3. http://struts.apache.org/ 4. http://maven.apache.org/ 5. http://www.oracle.com/us/products/database/overview/index.html 6. http://www.postgresql.org/ 7. http://ant.apache.org/ 8. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 9. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 10. http://www.gwtproject.org/ 11. http://www.eclipse.org/webtools/ 12. http://subclipse.tigris.org/142 Applications de l’approche mise sous contrôle de version, puis par sa propagation vers le dépôt SVN distant. En particulier, seules les sources contenues par ce projet doivent être mises sous contrôle de version, et pas les fichiers binaires contenant le code Java compilé, afin d’éviter de stocker des données inutiles sur le dépôt distant. La modification d’un projet Eclipse se termine toujours par la propagation des modifications sur le dépôt SVN distant. Le VAM de la famille de processus de développement web Java contient 27 élé- ments de modèle. Ce VAM permet de capturer les exigences de 512 projets différents, chacun ayant un processus différent. Le modèle de processus de base ainsi que le VRM de la famille de processus de développement web Java contiennent quant à eux respectivement 100 et 44 éléments de modèle. Le VAM, le modèle de processus de base ainsi que le VRM forment donc une ligne de processus capturant 512 processus différents. Le modèle de CA abstraits et de liaisons contient 25 éléments de modèle. Nous avons implémenté 9 CA en Java : 1. un CA permettant d’installer le plug-in Eclipse WTP, 2. un CA permettant d’installer le plug-in Eclipse Subclipse, 3. un CA permettant de redémarrer Eclipse, 4. un CA permettant de créer un nouveau serveur Tomcat, 5. un CA permettant de connecter un espace de travail Eclipse à un dépôt SVN distant, 6. un CA permettant de créer un nouveau dossier sur un dépôt SVN distant, 7. un CA permettant de mettre un projet Eclipse sous contrôle de version avec SVN (ce CA ne met sous contrôle de version que les sources, pas les fichiers binaires), 8. un CA permettant de propager avec SVN le code source d’un projet Eclipse spécifique vers un dépôt distant, 9. un CA permettant de propager vers un dépôt SVN distant particulier le code source de tous les projets Eclipse partagés sur ce dépôt, lorsque ceux-ci ont subit des modifications. Les CA 1 à 6 initialisent l’activité de développement. Le CA 1 a besoin pour s’exécuter du chemin, sur le poste local d’un développeur ou d’un architecte, de l’environnement Eclipse sur lequel installer le plug-in WTP. Le gestionnaire d’informations contextuelles demande cette information à l’acteur courant du processus et la sauvegarde dans le modèle de contexte. Le CA 2 a besoin pour s’exécuter de la même information contextuelle, que le gestionnaire d’informations contextuelles trouve donc dans le modèle de contexte. L’intérêt du CA 3 est de déployer dans l’environnement Eclipse les plug-ins nouvellement installés. Ce CA, tout comme le CA 4, n’a pas besoin d’informations contextuelles pour s’exécuter. Le CA 5 a besoin de trois informations contextuelles pour s’exécuter : l’URL d’un dépôt SVN distant, ainsi qu’un nom d’utilisateur et un mot de passe pour se connecter à ce dépôt distant. Le gestionnaire d’informations contextuelles demande ces trois informations à l’acteur courant du processus. Afin d’exécuter le CA 6, le gestionnaire d’informations contextuelles demande à un architecte le nom du dossier à créer sur le dépôt distant et récupère dansApplication sur une famille de processus de développement web Java 143 le modèle de contexte l’URL de ce dépôt distant. Afin de séparer les préoccupations, nous avons implémenté dans des CA différents (à savoir les CA 1 à 6) l’automatisation de l’installation des plug-ins WTP et Subclipse, le redémarrage d’Eclipse, la création d’un nouveau serveur Tomcat, la connection d’un espace de travail Eclipse à un dépôt SVN distant et la création d’un nouveau dossier sur un dépôt SVN distant. Les CA 7 et 8 finalisent la tâche de création d’un nouveau projet Eclipse. Le CA 7 a besoin de deux informations contextuelles pour s’exécuter : le nom du projet Eclipse à mettre sous contrôle de version et l’URL du dépôt distant. Le gestionnaire d’informations contextuelles demande la première information à l’acteur courant du processus, à chaque fois que le CA 7 est appelé, et sauve l’information dans le modèle de contexte en écrasant son ancienne valeur si elle existe. Cette information est en effet différente pour chaque projet, les projets à créer ne sont pas forcément connus à l’avance (il n’est donc pas possible de créer un CA spécifique à chaque projet) et l’information n’est pas réutilisée après l’exécution des CA 7 et 8 (le fait qu’elle soit écrasée ne pose donc pas de problème). Toujours pour le CA 7, le gestionnaire d’informations contextuelles récupère l’URL du dépôt distant dans le modèle de contexte. Pour le CA 8, le gestionnaire d’informations contextuelles récupère dans le modèle de contexte le nom du projet Eclipse à mettre sous contrôle de version. Nous avons implémenté dans deux CA différents (les CA 7 et 8) l’automatisation de la mise sous contrôle de version d’un projet Eclipse et la propagation de ce projet vers un dépôt SVN distant afin de séparer les préoccupations. Figure 7.7 – Code du CA permettant d’installer le plug-in Eclipse Subclipse Enfin, le CA 9 finalise la tâche de modification de projets Eclipse. Il a besoin pour144 Applications de l’approche Figure 7.8 – Code du CA créant un nouveau serveur Tomcat s’exécuter de l’URL du dépôt SVN distant. Le gestionnaire d’informations contextuelles récupère cette information dans le modèle de contexte. Les figures 7.7 et 7.8 présentent l’implémentation des CA 2 et 4 respectivement.Synthèse et discussion 145 L’implémentation du CA 2 consiste à exécuter une commande Windows installant, sur un environnement Eclipse,les archives Java relatives au plug-in Subclipse. L’implémentation du CA 4 consiste quant à elle à créer et sauvegarder un serveur Tomcat et une configuration associée. Pour résoudre la variabilité, la personne en charge de cette résolution doit faire au maximum 7 choix : déterminer le SCV, si une base de données est utilisée, et si oui de quel type de base de données il s’agit, le framework pour l’IHM, l’outil de compilation, si une partie du code est générée et le mode de livraison. Pour ce cas d’application nous avons sélectionné un processus avec SVN comme SCV, MySQL comme base de données, Struts comme framework pour l’IHM, Maven comme outil de compilation, sans génération de code, et avec livraison à la fois du code source et du code compilé. Le processus résolu correspondant est donc le même que celui de la figure 7.6. Une démonstration du cas d’application de la famille de processus de développement web Java peut être visualisée à l’adresse suivante : http://youtu.be/71shRD6ax9k. Les modèles ainsi que les CA relatifs à ce cas d’utilisation peuvent être consultés sur le dépôt SVN suivant : http://t4vasp.googlecode.com/svn/trunk/application_java_ development_process_line. Nous en présentons un extrait dans l’annexe B. 7.3 Synthèse et discussion Ces applications montrent que notre approche permet de gérer la variabilité et d’automatiser des exemples réels de processus, qui ont de nombreuses variantes ainsi que de nombreuses tâches récurrentes qui gagnent à être automatisées. Le tableau 7.1 récapitule le nombre d’éléments de modèle et de CA nécessaires à la réalisation de chacun des deux cas d’application. Cas d’application nb élts processus de base nb élts VAM nb élts VRM nb élts modèle CA abstraits et liaisons nb CA nb processus dans la famille Famille processus métamodélisation 134 39 123 27 10 128 Famille processus développement web Java 100 27 44 25 9 512 Table 7.1 – Tableau récapitulatif du nombre d’éléments de modèle et de CA pour chaque cas d’application Ces applications ont également permis d’observer des points forts de notre approche. Premièrement, pour les deux cas d’application, la modélisation des familles146 Applications de l’approche de processus avec CVL4SP s’est révélée être plus économique, en termes de nombre d’éléments à modéliser, que la modélisation en extension de ces familles. En effet, pour la famille de processus de métamodélisation, la ligne de processus est constituée de 296 éléments de modèle et capture 128 processus différents. La modélisation en extension de ces 128 processus aurait nécessité au moins 5248 éléments de modèle. En effet, la variante de processus de métamodélisation qui contient le moins d’éléments de modèle est celle qui consiste uniquement en la définition d’un métamodèle, et dans ce cas 41 éléments de processus sont nécessaires pour modéliser cette variante. Dans le cas de la famille de processus de développement web Java, la ligne de processus est constituée de 171 éléments de modèle et elle capture 512 processus différents. La modélisation en extension de ces 512 processus aurait nécessité au moins 41472 éléments de modèle. En effet, les variantes de processus qui contiennent le moins d’éléments de modèle sont celles sans génération de code et sans base de données, indépendamment des outils utilisés pour le SCV, l’IHM et la compilation, et indépendamment du mode de livraison considéré. Dans ce cas, 81 éléments de processus sont nécessaires pour modéliser une telle variante. Si, dans les deux cas d’application, la modélisation avec CVL4SP des familles de processus s’est révélée être plus économique que leur modélisation en extension, c’est parce que les familles sont modélisées en intention, et qu’assez d’éléments sont communs aux processus de chaque famille pour que leur factorisation permette de faire des économies de modélisation, même si cette factorisation implique de devoir modéliser plus d’éléments pour spécifier comment dériver un processus de la famille. D’une manière générale, quel que soit le cas d’application, plus les processus d’une famille ont d’éléments en commun, plus leur modélisation en intention permettra de réduire le nombre d’éléments à modéliser par rapport à la modélisation en extension. Le deuxième point fort observé est que l’automatisation des TMR permet de réduire l’occurrence des erreurs humaines. Par exemple, lors de la mise sous contrôle de version d’un projet Java Eclipse avec Subclipse, les fichiers binaires sont également ajoutés au contrôle de version par défaut. Il arrive que les personnes en charge de la mise sous contrôle de version d’un projet Java Eclipse oublient de retirer ces fichiers binaires du contrôle de version, ce qui n’arrive plus une fois que cette tâche est automatisée. Un troisième point fort observé lors de ces applications est que l’automatisation des TMR permet de gagner du temps lorsqu’une personne en charge de la réalisation d’une tâche ne sait pas comment la réaliser. En effet, l’automatisation d’une TMR permet à cette personne d’éviter de passer du temps à se former à la réalisation de cette tâche. Ces applications ont aussi permis de mettre en évidence une faiblesse de l’approche proposée dans cette thèse. Ainsi, M4RAC ne s’applique qu’au niveau d’une famille de processus, et ne permet donc pas d’améliorer la réutilisation de CA entre familles. Par exemple, les CA permettant de connecter un espace de travail Eclipse à un dépôt SVN distant, de mettre un projet sous contrôle de version et de propager du code source vers un dépôt distant sont communs aux deux cas d’application présentés dans ce chapitre. Or, comme M4RAC ne s’applique que sur un seul cas d’application à la fois, elle ne permet pas d’identifier le niveau de réutilisation de ces CA afin qu’ils soient réutilisables pour les deux cas d’application. Élargir M4RAC à l’ensemble des famillesSynthèse et discussion 147 de processus d’une entreprise permettrait de surmonter cette limitation.148 Applications de l’approche8 Conclusion et perspectives Dans ce chapitre, nous faisons le bilan des contributions cette thèse (section 8.1) et nous discutons les perspectives ouvertes par ces contributions (section 8.2). 8.1 Conclusion La complexité des logiciels et des projets de développement logiciel amène une multiplication des outils de développement logiciel afin de faire face à cette complexité. Par exemple, les systèmes de contrôle de version permettent de gérer les difficultés liées au travail collaboratif et géographiquement distribué, les outils de compilation, de test ou d’intégration continue supportent les méthodes de développement agiles, les IDE permettent d’intégrer les différentes technologies utilisées sur un projet, etc. De plus, des versions différentes de ces outils existent afin de satisfaire les besoins spécifiques à chaque projet, ce qui augmente le nombre d’outils existant. L’utilisation de tous ces outils est cependant à l’origine de nombreuses TMR (Tâches Manuelles Récurrentes), sources d’erreurs et coûteuses en temps. L’automatisation des TMR permet de réduire les erreurs liées à leur réalisation et donc le temps passé à corriger ces erreurs. La réutilisation des automatisations de TMR permet quant à elle de réduire le temps passé à les définir. Mais cette réutilisation est difficile. En effet, une automatisation de TMR n’étant pas forcément utile pour tous les projets et pouvant avoir des dépendances avec d’autres tâches, pour quels projets et à quels moments d’un projet réutiliser une automatisation de TMR ? De plus, une automatisation de TMR pouvant être utile dans des projets différents, ou à des moments différents d’un même projet, comment s’assurer qu’elle soit bien réutilisable à travers ses différents cas d’utilisation ? Dans la littérature, il n’y a, à notre connaissance, pas d’approche permettant à la fois de savoir pour quels projets réutiliser des automatisations de TMR et à quels moments d’un projet les réutiliser. De plus, même s’il existe des approches centrées sur la conception et le développement de composants logiciels réutilisables, celles-ci ne sont pas adaptées au cas des automatisations de TMR. En effet, elles sont spécifiques aux composants logiciel réalisant des produits logiciels et supposent que chaque caracté- 149150 Conclusion et perspectives ristique d’un produit logiciel est réalisée par un composant. Or, toutes les étapes d’un processus ne sont pas forcément réalisées par des automatisations de TMR. Afin de surmonter ces limitations, nous proposons dans cette thèse une approche pilotant l’automatisation des TMR par les processus de développement logiciel. Elle s’appuie sur une première sous-contribution, CVL4SP, afin de définir en intention une ligne de processus et d’en dériver un processus en fonction des exigences d’un projet. Des composants automatisant des TMR (CA) sont liés aux unités de travail de la ligne de processus qu’ils automatisent. L’approche proposée s’appuie sur une deuxième sous-contribution, M4RAC, afin d’améliorer la réutilisation de ces CA à travers les différentes unités de travail qu’ils automatisent. Un processus dérivé de la ligne de processus est automatisé en lançant, au fur et à mesure de son exécution, les CA qui lui sont liés. La réutilisation des CA passe donc par la réutilisation des processus de développement logiciel, le lien entre eux permettant de savoir pour quels projets et à quels moments d’un projet réutiliser ces CA. D’autre part, certaines contraintes de projet impliquant de commencer l’exécution d’un processus alors que sa variabilité n’est que partiellement résolue, l’approche proposée permet de résoudre de la variabilité lors de l’exécution d’un processus. Cela permet d’assurer le bon déroulement de l’exécution d’un processus même lorsque sa variabilité n’est que partiellement résolue. CVL4SP s’appuie sur CVL afin de gérer la variabilité des processus de développement logiciel. Le point fort de CVL4SP, en comparaison des autres approches gérant la variabilité dans les processus, est son indépendance vis-à-vis du formalisme utilisé pour définir les processus. M4RAC améliore l’identification du niveau de réutilisation des CA, c’est-à-dire des parties de ces CA qui varient et qui ne varient pas. Cette information est nécessaire à la création de CA réutilisables à travers leurs différents cas d’utilisation. M4RAC s’appuie sur le lien entre la ligne de processus et les CA afin d’identifier les différents contextes d’utilisation de ces derniers. Ce sont ces différents contextes d’utilisation qui guident l’identification du niveau de réutilisation d’un CA. L’avantage principal de M4RAC est qu’elle explicite les différents contextes d’utilisation de chaque CA, ce qui permet de ne pas en oublier et de ne pas prendre en compte des contextes d’utilisation inutiles. Afin de démontrer la faisabilité de notre approche, nous avons développé un outil la supportant : T4VASP. Il a été appliqué à deux cas d’utilisation, à savoir une famille de processus de métamodélisation et une famille de processus de développement web Java issue de Sodifrance. T4VASP permet de définir en intention une ligne de processus, de lui lier des CA, d’en dériver un processus en fonction des exigences d’un projet, d’automatiser l’exécution de ce processus et de résoudre sa variabilité non résolue au moment de son exécution. 8.2 Perspectives Les contributions de cette cette thèse ouvrent plusieurs perspectives de travail. Certaines sont d’ordre industriel, tandis que d’autres sont des pistes de recherche àPerspectives 151 investiguer à court et long terme. 8.2.1 Perspectives industrielles Nous présentons ici différents axes de travail afin de permettre l’utilisation de T4VASP dans un contexte industriel. 8.2.1.1 Utilisation de T4VASP quel que soit le cas d’application T4VASP ne fonctionne actuellement que dans un environnement local. Or, les projets de développement logiciel requièrent souvent l’intervention de plusieurs personnes, chacune ayant son propre poste de travail. Aussi, faire évoluer T4VASP vers une application client-serveur permettrait de l’utiliser en environnements distribués. Nous n’avons implémenté que les fonctionnalités de T4VASP permettant de l’utiliser avec les deux cas d’applications présentés dans cette thèse. L’implémentation des fonctionnalités restantes de T4VASP permettrait donc de pouvoir l’utiliser quel que soit le cas d’application. Les fonctionnalités non encore implémentées portent sur la prise en compte exhaustive de CVL par l’assistant à la résolution de la variabilité et par le moteur de dérivation, l’évaluation dynamique des expressions Kermeta, l’évaluation des conditions définies dans un modèle de CA abstraits et de liaisons, le découplage de l’accès aux informations contextuelles de l’implémentation des CA et la résolution de la variabilité à l’exécution. Nous avons vu dans la section 4.3.4 que la modélisation des éléments de processus externes pouvait se révéler difficile lorsqu’ils ne respectent pas toutes les contraintes définies sur leur métamodèle et que le modeleur utilisé ne permet pas de modéliser des éléments invalides. L’ajout à T4VASP d’un composant permettant de générer automatiquement ces éléments, ainsi que les éléments de modèle manquants pour les rendre valides, permettrait de faire face à cette difficulté. 8.2.1.2 Limitation des erreurs T4VASP ne permet actuellement pas à l’acteur courant du processus de lancer des initialisations ou des finalisations d’unités de travail lorsqu’elles ne sont pas automatisées. Elles sont alors traitées par l’interpréteur de processus comme si elles n’existaient pas. L’acteur courant du processus peut donc omettre de les réaliser. La solution idéale serait de pouvoir spécifier dans le modèle de processus qu’une unité de travail a une initialisation ou une finalisation, qu’elle soit manuelle ou non. Cela permettrait à l’interpréteur de processus de différencier les cas où une initialisation ou finalisation est manuelle de ceux où il n’y en a pas. Cependant, tous les langages de modélisation de processus ne permettent pas de définir qu’une unité de travail a une initialisation ou une finalisation. Une autre solution serait donc d’étendre le métamodèle de CA abstraits et de liaisons, afin que celui-ci permette de spécifier si une initialisation ou une finalisation d’unité de travail est manuelle. Cette extension pourrait prendre la forme d’une action spécifique qui serait une action manuelle. Cela permettrait que152 Conclusion et perspectives les unités de travail ayant des initialisations et finalisations manuelles soient traitées différemment de celles n’en ayant pas. CVL permet actuellement de dériver des modèles de processus résolus invalides, alors que le modèle de processus de base, le modèle d’abstraction de la variabilité (VAM), le modèle de réalisation de la variabilité (VRM) ainsi que le modèle de résolution de la variabilité (RM) sont valides. Pour rappel, nous avons identifié trois catégories d’erreurs qui rendent le modèle de processus résolu invalide. La première catégorie concerne les erreurs liées au non-respect de la compatibilité de type lorsqu’une nouvelle valeur est assignée à une instance de propriété. La deuxième catégorie englobe les erreurs liées au non-respect de la multiplicité d’une référence ou des contraintes définies sur le métamodèle du modèle de processus résolu. La troisième catégorie concerne les erreurs sémantiques, c’est-à-dire quand le modèle du processus résolu est bien conforme à son métamodèle, mais qu’il est trop permissif pour un métier donné ou qu’il contient des incohérences. Contraindre l’application des points de variation de CVL (opération à appliquer au modèle de base pour dériver un modèle résolu), à l’aide de contraintes exprimées de manière générique sur le métamodèle de CVL, permettrait d’éviter les erreurs de la première catégorie. Un outil générique d’analyse statique, qui assurerait que le modèle de processus résolu respecte bien les contraintes définies sur son métamodèle, permettrait d’éviter les erreurs de la deuxième caté- gorie. La modification du métamodèle de processus utilisé permettrait d’éviter les erreurs de la troisième catégorie. Cependant, dans les cas où cette modification s’avère trop coûteuse, un moteur de dérivation spécifique aux besoins d’un métier particulier permettrait de restreindre ce que le modèle de processus résolu peut capturer. Un outil vérifiant la consistance des pré et post conditions associées aux CA, ainsi qu’aux unités de travail qu’ils automatisent, permettrait quant à lui de s’assurer qu’un modèle de CA abstraits et de liaisons est correct. 8.2.1.3 Suppression des redondances dans le modèle de CA abstraits et de liaisons Dans le modèle de CA abstraits et de liaisons, il est actuellement nécessaire de spécifier quelle variante d’unité de travail chaque liste de CA automatise. Lorsque des variantes différentes d’une unité de travail sont automatisées par des listes différentes de CA, cela implique de définir plusieurs fois des éléments de modèle référençant la même unité de travail, en spécifiant à chaque fois à l’aide de conditions quelle est la variante de cette unité de travail. Afin de supprimer ces redondances, CVL pourrait être utilisé pour créer le modèle de CA abstraits et de liaisons correspondant à un modèle de processus résolu, en fonction des exigences d’un projet. Dans le modèle de CA abstraits et de liaisons, seule l’unité de travail automatisée par un CA serait spécifiée, sans préciser de quelle variante il s’agit. Une fois les exigences d’un projet définies, le modèle de CA abstraits et de liaisons serait transformé afin qu’il ne reste que les listes de CA correspondant aux variantes d’unités de travail qui sont dans le modèle de processus résolu.Perspectives 153 8.2.2 Perspectives de recherche à court terme En plus de l’application de notre approche à une famille de processus industriels (cf. section 7.2), une expérimentation, réalisée elle aussi dans un contexte industriel, permettrait de déterminer dans quelle proportion notre approche permet de réduire les temps de développement. Cette expérimentation pourrait consister à comparer le temps passé par un ensemble d’utilisateurs à réaliser un processus de développement logiciel manuellement et en utilisant l’approche et l’outillage de cette thèse. De plus, l’élaboration de l’approche proposée dans cette thèse ainsi que la conception et le dé- veloppement de l’outillage support et des CA implique un investissement en terme de temps. Les résultats de l’expérimentation permettraient donc de déterminer combien de processus de développement logiciel il est nécessaire d’automatiser en suivant notre approche pour obtenir un retour sur investissement. Cette information serait utile pour déterminer dans quels cas il est rentable d’appliquer notre approche. 8.2.3 Perspectives de recherche à long terme Nous abordons dans cette section les perspectives de recherche afin de gérer également la variabilité des processus qui a lieu pendant leur exécution et afin d’améliorer la réutilisation des CA. 8.2.3.1 Gestion de la variabilité des processus au moment de leur l’exécution Un processus en cours d’exécution peut avoir besoin d’être adapté à cause de changements au niveau de son environnement d’exécution ou de l’organisation d’une entreprise, parce que certaines parties d’un processus dépendent de l’exécution de parties amont, ou encore à cause des spécificités d’un projet [BFG93]. Étendre l’approche actuellement proposée dans cette thèse afin qu’elle permette de mettre à jour automatiquement le modèle du processus en cours d’exécution en fonction de certains évènements permettrait de répondre à ce besoin. Les travaux de Morin [Mor10], qui permettent de reconfigurer dynamiquement des modèles en réponse aux changements dans leur environnement d’exécution, pourraient être réutilisés à cette fin. Il faudrait également que les différents artéfacts de développement liés au processus en cours d’exécution soient adaptés, tout en assurant leur cohérence [DO04]. Pour ce faire, une piste serait de réutiliser les travaux de Fouquet [Fou13], qui permettent de piloter à partir des modèles la reconfiguration dynamique de composants dans un environnement distribué. La présence d’activités plus opportunes que celles définies par le processus peut justifier un besoin de déviation vis-à-vis de ce processus lors de son exécution [Vis90]. La difficulté est ici de dévier d’un processus tout en continuant à utiliser de manière cohérente les parties de ce processus qui restent pertinentes pour le projet [DO04]. Une piste de recherche serait donc d’étendre l’approche proposée dans cette thèse afin qu’elle permette de dévier du processus en cours d’exécution. À cette fin, les travaux de Kabbaj et al. [KLC08] pourraient être réutilisés. Ceux-ci permettent de détecter154 Conclusion et perspectives les déviations vis-à-vis d’un processus au moment de son exécution et de gérer ces déviations en les acceptant ou en les refusant. 8.2.3.2 Amélioration de la réutilisation des CA M4RAC ne s’appliquant qu’au niveau d’une famille de processus, elle ne permet pas d’améliorer la réutilisation de CA entre familles de processus. Étendre M4RAC, de manière à ce qu’elle s’applique à un ensemble de familles de processus, permettrait d’améliorer la réutilisation des CA entre familles de processus. Nous avons identifié une première directive pour implémenter les CA afin d’amé- liorer leur réutilisation : lorsque la ligne de processus spécifie qu’un outil peut être substitué par un autre, alors, dans l’implémentation d’un CA, les parties qui dépendent de cet outil doivent être découplées des parties qui n’en dépendent pas. Une perspective de travail serait d’identifier des recommandations supplémentaires pour implémenter les CA, afin d’améliorer encore leur capacité à être réutilisés. Il est difficile pour un humain d’identifier les contextes d’utilisation des CA, à cause de la définition en intention de processus, mais également à cause du nombre important de processus. En effet, il est dans ce cas difficile pour un humain de visualiser explicitement chacun des processus de la ligne et aussi de les intégrer mentalement. Un outil offrant un support à l’identification des contextes d’utilisation des CA serait une solution à ce problème. Il pourrait expliciter les différents processus d’une famille définie en intention, ainsi que les CA déjà associés à ces processus. Afin de limiter le nombre de processus affichés, il pourrait s’appuyer sur une définition de contextes d’utilisation de CA similaires, et donc n’afficher qu’un seul de ces contextes. La vérifi- cation de la consistance entre les pré et post-conditions associées aux CA permettrait quant à elle de détecter d’éventuelles erreurs au moment de l’association d’un CA à une unité de travail.Appendices 155Annexe A Extrait des modèles et CA de la famille de processus de métamodélisation Nous présentons dans cette annexe un extrait des modèles et des CA relatifs au cas d’application de la famille de processus de métamodélisation (cf. section 7.1). Un extrait du VAM de cette famille est illustré en figure A.1. Les choix tree editor, compiler, interpreter, checker, textual editor, EMFText, XText, version control system, SVN et Git doivent être résolus manuellement. De plus, les choix SVN et Git, tout comme les choix EMFText et XText, sont mutuellement exclusifs. La résolution des autres choix est quant à elle dérivée. Seul le choix version control system est obligatoire (propriété Is Implied By Parent à vrai). Dans le VRM, dont un extrait est présenté en figure A.2, les propriétés associées à la substitution de fin de lien compiler creation into metamodeling activity indiquent que la tâche de définition d’un compilateur est intégrée au processus le plus souvent utilisé (cf. figure 4.7) lorsque le choix compiler est sélectionné. Cette tâche est identifiée par le pointeur d’objet compiler creation et appartient initialement aux éléments de processus externes du modèle de processus de base (cf. figure 4.8). Les propriétés associées à la substitution de fin de lien Fork into metamodeling activity indiquent quant à elles que le nœud de parallélisation appartenant aux éléments de processus externes du modèle de processus de base est intégré au processus le plus souvent utilisé dès lors que des tâches sont exécutées en parallèle (choix parallelization résolu positivement). Le nœud de parallélisation est identifié par le pointeur d’objet Fork et le processus le plus souvent utilisé est représenté par l’activité Metamodeling Activity. La figure A.3 illustre un extrait du modèle de liaisons de la famille de processus de métamodélisation. Les propriétés des pointeurs d’unités de travail (éléments de type WorkUnitHandle sur la figure) spécifient quelles sont les étapes (initialisation, exécution, finalisation) de ces unités de travail qui sont automatisées, et par quels CA. Ainsi, l’initialisation et la finalisation de la définition d’un métamodèle sont respectivement automatisées par un CA créant un projet EMF vide (Primitive AC Create empty EMF 157158 Extrait des modèles et CA de la famille de processus de métamodélisation Figure A.1 – Extrait du VAM de la famille de processus de métamodélisation project) et par un CA validant le métamodèle créé (Primitive AC validate EMF model). L’exécution de la définition d’un éditeur arborescent est automatisée par un CA gé- nérant cet éditeur (Primitive AC generate tree editor). Les initialisations des définitions d’un compilateur, d’un interpréteur et d’un vérificateur sont automatisées par des CA créant et initialisant un projet Kermeta (Primitive AC create Kermeta compiler, Primitive AC create Kermeta interpreter, Primitive AC create Kermeta checker). Enfin, la finalisation de la définition d’un interpréteur est automatisée par une liste de CA (ACL put under version control, constituée des CA subclipse configuration, share project SVN et commit project SVN) mettant cet interpréteur sous contrôle de version. Tous les CA sont im-159 Figure A.2 – Extrait du VRM de la famille de processus de métamodélisation plémentés par des actions Java Eclipse. Parmi elles, l’action CreateEmptyEMFProject est implémentée par la classe CreateEmptyEMFProjectActivityAutomation, comme illustré par la figure A.4. La méthode run de cette classe lance deux assistants Eclipse (cf. figure A.5). Le premier demande à l’acteur courant le nom du nouveau projet EMF, sauve cette information dans le modèle de contexte et crée le nouveau projet EMF. Le deuxième réalise la même séquence d’étapes concernant le fichier Ecore contenant le métamodèle. Pour terminer, un extrait du RM est illustré par la figure A.6. Les propriétés des résolutions de choix tree editor, SVN et Git indiquent que les choix du même nom sont respectivement résolus à vrai, vrai et faux.160 Extrait des modèles et CA de la famille de processus de métamodélisation Figure A.3 – Extrait du modèle de liaisons de la famille de processus de métamodélisation161 Figure A.4 – Déclaration de la classe implémentant l’action Java Eclipse CreateEmptyEMFProject Figure A.5 – Code de la classe CreateEmptyEMFProjectActivityAutomation162 Extrait des modèles et CA de la famille de processus de métamodélisation Figure A.6 – Extrait du RM du cas d’application de la famille de processus de métamodélisation de la section 7.1Annexe B Extrait des modèles et CA de la famille de processus de développement web Java Nous présentons dans cette annexe un extrait des modèles et des CA relatifs au cas d’application de la famille de processus de développement web Java (cf. section 7.2). Figure B.1 – Extrait du VAM de la famille de processus de développement web Java 163164 Extrait des modèles et CA de la famille de processus de développement web Java Le VAM de cette famille, dont un extrait est illustré par la figure B.1, comporte 22 choix. Leur résolution est manuelle et ils permettent de déterminer le SCV, la base de données, le framework pour l’IHM web, l’outil de compilation, si une étape de génération de code intervient avant le développement manuel, ainsi que le mode de livraison. La figure B.2 illustre un extrait du VRM. La substitution d’objet SVN replaced by Git spécifie que l’outil SVN (référencé par le pointeur d’objet SVN) est remplacé par l’outil Git (référencé par le pointeur d’objet Git) lorsque le choix Git est sélectionné. L’existence d’objet MySQL spécifie que l’outil MySQL existe dans le modèle de processus résolu lorsque le choix MySQL est sélectionné. Sinon, cet outil est supprimé. La substitution d’objet MySQL replaced by Oracle spécifie quant à elle que l’outil MySQL est remplacé par l’outil Oracle lorsque le choix Oracle est sélectionné. Un extrait du modèle de liaisons est illustré par la figure B.3. Le pointeur d’unité de travail development spécifie que l’initialisation de l’activité de développement (Activity development) est automatisée par la liste de CA development initialization. Celle-ci permet : – d’installer les plug-ins WTP (Primitive AC install wtp) et Subclipse (Primitive AC install subclipse), – de rédémarrer Eclipse (Primitive AC restart), – d’initialiser un serveur Tomcat (Primitive AC new Tomcat server), – de connecter un espace de travail Eclipse à un nouveau dépôt SVN (Primitive AC subclipse configuration) – et de créer un nouveau dossier sur ce dépôt SVN (Primitive AC create directory on remote repository). Les pointeurs d’unité de travail project creation et first project creation spécifient que les tâches de création de projets (Task Use project creation et Task Use first project creation) sont finalisées par une liste d’AC (ACL share and commit project with SVN) mettant ce projet sous contrôle de version (Primitive AC share project with SVN) et propageant son contenu sur un dépôt distant (commit project with SVN). Le pointeur d’unité de travail projects modification spécifie que la tâche de modification de projets (Task Use projects modification) est finalisée par un CA propageant les modifications apportées sur un dépôt distant (Primitive AC commit the modified projects). Comme pour le cas d’application précédent, tous les CA sont implémentés par des actions Java Eclipse. Parmi elles, l’action Java Eclipse install wtp a pour identifiant installwtp. Comme illustré par les figures B.4 et B.5, cette action est implémentée par la classe InstallWTP et nécessite comme information contextuelle le chemin de l’environnement Eclipse sur lequel installer le plug-in. La méthode run de cette classe lance l’exécution d’une commande Windows installant, sur un environnement Eclipse, les archives Java relatives au plug-in WTP (cf. figure B.6). Enfin, la figure B.7 illustre un extrait du RM. Les propriétés des résolutions de choix SCV, SVN, Git et code generation indiquent que les choix du même nom sont respectivement résolus à vrai, vrai, faux et faux.165 Figure B.2 – Extrait du VRM de la famille de processus de développement web Java166 Extrait des modèles et CA de la famille de processus de développement web Java Figure B.3 – Extrait du modèle de liaisons de la famille de processus de développement web Java Figure B.4 – Déclaration de la classe implémentant l’action Java Eclipse install wtp167 Figure B.5 – Information contextuelle du CA installant le plug-in WTP Figure B.6 – Code de la classe InstallWTP168 Extrait des modèles et CA de la famille de processus de développement web Java Figure B.7 – Extrait du RM du cas d’application de la famille de processus de développement web Java de la section 7.2Bibliographie [AB12] J.A.H. Alegría and M.C. Bastarrica. Building Software Process Lines with CASPER. In ICSSP, pages 170–179, 2012. [ABC96] D. Avrilionis, N. Belkhatir, and P.-Y. Cunin. A unified framework for software process enactment and improvement. In ICSP, pages 102–111, 1996. [ABM00] C. Atkinson, J. Bayer, and D. Muthig. Component-Based Product Line Development : The KobrA Approach. In SPLC, pages 289–309, 2000. [ACG+12] M. Acher, P. Collet, A. Gaignard, P. Lahire, J. Montagnat, and R. France. ComposingMultiple Variability Artifacts to Assemble CoherentWork- flows. Software Quality Journal, 20(3-4) :689–734, 2012. [AD91] L.C. Alexander and A.M. Davis. Criteria for Selecting Software Process Models. In COMPSAC, pages 521–528, 1991. [Ald10] L. Aldin. Semantic Discovery and Reuse of Business Process Patterns. PhD thesis, School of Information Systems, Computing and Mathematics Brunel University, 2010. [Amb99] S. W. Ambler. More Process Patterns Delivering Large-Scale Systems Using Object Technology. Cambridge University Press, 1999. [ASKW11] A. Awad, S. Sakr, M. Kunze, and M. Weske. Design by Selection : A Reuse-Based Approach for Business Process Modeling. In ER, pages 332–345, 2011. [BBM05] J. Bhuta, B. Boehm, and S. Meyers. Process Elements : Components of Software Process Architectures. In SPW, pages 332–346, 2005. [BCCG07] R. Bendraou, B. Combemale, X. Cregut, and M.-P. Gervais. Definition of an Executable SPEM 2.0. In APSEC, pages 390–397, 2007. [BDK07] J. Becker, P. Delfmann, and R. Knackstedt. Adaptive Reference Modeling : Integrating Configurative and Generic Adaptation Techniques for Information Models. In RM, pages 27–58, 2007. [BDKK04] P. Becker, J. Delfmann, A. Dreiling, R. Knackstedt, and D. Kuropka. Configurative Process Modeling - Outlining an Approach to Increased Business Process Model Usability. In IRMA, pages 615–619, 2004. 169170 BIBLIOGRAPHIE [Ben07] R. Bendraou. UML4SPM : Un Langage De Modélisation De Procédés De Développement Logiciel Exécutable Et Orienté Modèle. PhD thesis, Université Pierre & Marie Curie - Paris VI, 2007. [BFG93] S.C. Bandinelli, A. Fuggetta, and C. Ghezzi. Software Process Model Evolution in the SPADE Environment. IEEE TSE, 19(12) :1128–1144, 1993. [BGB06] R. Bendraou, M.-P. Gervais, and X. Blanc. UML4SPM : An Executable Software Process Modeling Language Providing High-Level Abstractions. In EDOC, pages 297–306, 2006. [BnCCG11] S. J. Bolaños Castro, R. G. Crespo, and V. H. M. García. Patterns of Software Development Process. IJIMAI, 1(4) :33–40, 2011. [Boe88] B.W. Boehm. A Spiral Model of Software Development and Enhancement. Computer, 21(5) :61–72, 1988. [Boo91] G. Booch. Object Oriented Design : With Applications. Benjamin/- Cummings Publishing Company, 1991. [BSE03] F. Budinsky, D. Steinberg, and R. Ellersick. Eclipse Modeling Framework : A Developer’s Guide. Addison-Wesley Professional, 2003. [CA05] K. Czarnecki and M. Antkiewicz. Mapping Features to Models : A Template Approach Based on Superimposed Variants. InGPCE, pages 422–437, 2005. [CB05] S. Clarke and E. Baniassad. Aspect-Oriented Analysis and Design : The Theme Approach. Addison-Wesley, 2005. [CBHB07] M. Cataldo, M. Bass, J.D. Herbsleb, and L. Bass. On Coordination Mechanisms in Global Software Development. In ICGSE, pages 71– 80, 2007. [CC07] D. Ciuksys and A. Caplinskas. Reusing Ontological Knowledge about Business Processes in IS Engineering : Process Configuration Problem. Informatica, 18(4) :585–602, 2007. [CDCC+13] E. Céret, S. Dupuy-Chessa, G. Calvary, A. Front, and D. Rieu. A Taxonomy of Design Methods Process Models. Information and Software Technology, 55(5) :795 – 821, 2013. [CKO92] B. Curtis, M. I. Kellner, and J. Over. Process Modeling. Commun. ACM, 35(9) :75–90, 1992. [CLM+99] A. G. Cass, B. S. Lerner, E. K. McCall, L. J. Osterweil, and A. Wise. Logically Central, Physically Distributed Control in a Process Runtime Environment. Technical Report 99-65, University of Massachusetts at Amherst, 1999. [CLS+00] A. G. Cass, B. S. Lerner, S. M. Sutton, Jr., E. K. McCall, A. Wise, and L. J. Osterweil. Little-JIL/Juliette : A Process Definition Language and Interpreter. In ICSE, pages 754–757, 2000.BIBLIOGRAPHIE 171 [CN01] P. Clements and L. Northrop. Software Product Lines : Practices and Patterns. Addison-Wesley Longman Publishing Co., Inc., 2001. [Cox85] B.J. Cox. Object Oriented Programming. Addison-Wesley,Reading, MA, 1985. [Crn02] I. Crnkovic. Building Reliable Component-Based Software Systems. Artech House, Inc., 2002. [DB10] W. Derguech and S. Bhiri. Reuse-Oriented Business Process Modelling Based on a Hierarchical Structure. In BPM, pages 301–313, 2010. [Dij82] E. W. Dijkstra. On the Role of Scientific Thought. In Selected Writings on Computing : A Personal Perspective, pages 60–66. Springer-Verlag, 1982. [Dio93] R. Dion. Process Improvement and the Corporate Balance Sheet. IEEE Software, 10(4) :28–35, 1993. [DO04] J.-C. Derniame and F. Oquendo. Key Issues and New Challenges in Software Process Technology. UPGrade, The European Journal for the Informatics Professional, 5(5) :11–16, 2004. [FHMP+11] F. Fleurey, Ø. Haugen, B. Møller-Pedersen, A. Svendsen, and X. Zhang. Standardizing Variability - Challenges and Solutions. In SDL Forum, pages 233–246, 2011. [FL03] P. Fettke and P. Loos. Classification of reference models : a methodology and its application. Information Systems and e-Business Management, 1(1) :35–53, 2003. [Fou13] F. Fouquet. Kevoree : Model@Runtime pour le développement continu de systèmes adaptatifs distribués hétérogènes. PhD thesis, University of Rennes 1, 2013. [FPLPdL01] S. T. Fiorini, J. C. S. Prado Leite, and C. J. Pereira de Lucena. Process Reuse Architecture. In CAiSE, pages 284–298, 2001. [Fra99] U. Frank. Conceptual Modelling as the Core of the Information Systems Discipline – Perspectives and Epistemological Challenges. In AMCIS, pages 695–697, 1999. [GLKD98] K. Gary, T. Lindquist, H. Koehnemann, and J.-C. Derniame. Component-based Software Process Support. In ASE, pages 196–199, 1998. [GM05] R. J. Glushko and T. S. McGrath. Document Engineering : Analyzing And Designing Documents For Business Informatics & Web Services. MIT Press, 2005. [Guy13] C. Guy. Facilités de typage pour l’ingénierie des langages. PhD thesis, Université de Rennes 1, 2013. [GvdAJV07] F. Gottschalk, W. M. P. van der Aalst, and M. H. Jansen-Vullers. SAP WebFlow Made Configurable : Unifying Workflow Templates into a Configurable Model. In BPM, pages 262–270, 2007.172 BIBLIOGRAPHIE [GvdAJVLR08] F. Gottschalk, W. M.P. van der Aalst, M. H. Jansen-Vullers, and M. La Rosa. Configurable Workflow Models. Cooperative Information Systems, 17(2) :177–221, 2008. [HABQO11] J.A. Hurtado Alegría, M.C. Bastarrica, A. Quispe, and S.F. Ochoa. An MDE Approach to Software Process Tailoring. In ICSSP, pages 43–52, 2011. [Ham96] Michael Hammer. Beyond Reengineering : How the Process-Centered Organization is Changing Our Work and Our Lives. Harper Collins Publishers, 1996. [HBR10] A. Hallerbach, T. Bauer, and M. Reichert. Capturing Variability in Business Process Models : the Provop Approach. Software Maintenance, 22(67) :519–546, 2010. [HIMT96] N. Hanakawa, H. Iida, K.-i. Matsumoto, and K. Torii. A Framework of Generating Software Process Including Milestones for ObjectOriented Development Method. In APSEC, pages 120–130, 1996. [HMR06] J. D. Herbsleb, A. Mockus, and J. A. Roberts. Collaboration in Software Engineering Projects : A Theory of Coordination. In ICIS, 2006. [Hum88] W. S. Humphrey. The Software Engineering Process : Definition and Scope. SIGSOFT Softw. Eng. Notes, 14(4) :82–83, 1988. [HWRK11] J. Hutchinson, J. Whittle, M. Rouncefield, and S. Kristoffersen. Empirical Assessment of MDE in Industry. In ICSE, pages 471–480, 2011. [HZG+97] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. Paulk. Software Quality and the Capability Maturity Model. Commun. ACM, 40(6) :30–40, 1997. [IMCH+07] C. Iochpe, C. Ming Chiao, G. Hess, G. Nascimento, L. Thom, and M. Reichert. Towards an intelligent workflow designer based on the reuse of workflow patterns. In WBPM, 2007. [Ins95] Software Engineering Institute. The Capability Maturity Model : Guidelines for Improving the Software Process. Addison-Wesley, 1995. [Ins13] CMMI Institute. Maturity Profile Reports, September 2013. [ISO07] ISO/IEC. ISO/IEC 24744 :2007 Software Engineering – Metamodel for Development Methodologies, 2007. [Ist13] P. Istoan. Methodology for the derivation of product behaviour in a Software Product Line. PhD thesis, University of Rennes 1 and University of Luxembourg, 2013. [JCV12] J.-M. Jézéquel, B. Combemale, and D. Vojtisek. Ingénierie Dirigée par les Modèles : des concepts à la pratique... Ellipses, 2012. [Jéz12] J.-M. Jézéquel. Model-Driven Engineering for Software Product Lines. ISRN Software Engineering, 2012(2012), 2012.BIBLIOGRAPHIE 173 [JMD04] T. Javed, M. Maqsood, and Q. S. Durrani. A Study to Investigate the Impact of Requirements Instability on Software Defects. SIGSOFT Softw. Eng. Notes, 29(3) :1–7, 2004. [KB10] V. Kulkarni and S. Barat. Business Process Families Using ModelDriven Techniques. In BPM, pages 314–325, 2010. [KCH+90] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical report, Carnegie-Mellon University Soft. Eng. Institute, 1990. [KKL+98] C. K. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh. FORM : A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures. Annals of Software Engineering, 5 :143–168, 1998. [KL07] B. Korherr and B. List. A UML 2 Profile for Variability Models and their Dependency to Business Processes. In DEXA, pages 829–834, 2007. [KLC08] M. Kabbaj, R. Lbath, and B. Coulette. A Deviation Management System for Handling Software Process Enactment Evolution. In ICSP, pages 186–197, 2008. [KR10] M. Khaari and R. Ramsin. Process Patterns for Aspect-Oriented Software Development. In ECBS, pages 241–250, 2010. [Kru92] C. W. Krueger. Software Reuse. ACM Comput. Surv., 24(2) :131–183, 1992. [Kru06] C. W. Krueger. Introduction to the Emerging Practice of Software Product Line Development. Methods and Tools, 14(3) :3–15, 2006. [KSG04] J. Kim, M. Spraragen, and Y. Gil. An Intelligent Assistant for Interactive Workflow Composition. In IUI, pages 125–131, 2004. [KY12] A. Kumar and W. Yao. Design and management of flexible process variants using templates and rules. Comput. Ind., 63(2) :112–130, 2012. [KYSR09] E. Kouroshfar, H. Yaghoubi Shahir, and R. Ramsin. Process Patterns for Component-Based Software Development. In CBSE, pages 54–68, 2009. [LK04] K. Lee and K. Kang. Feature Dependency Analysis for Product Line Component Design. In ICSR, pages 69–85, 2004. [LKCC00] K. Lee, K. C. Kang, W. Chae, and B. W. Choi. Featured-Based Approach to Object-Oriented Engineering of Applications for Reuse. Softw. Pract. Exper., 30(9) :1025–1046, 2000. [LRDtHM11] M. La Rosa, M. Dumas, A. H.M. ter Hofstede, and J. Mendling. Configurable Multi-Perspective Business Process Models. Information Systems : Databases : Their Creation, Management and Utilization, 36(2) :313–340, 2011.174 BIBLIOGRAPHIE [LRvdADM13] M. La Rosa,W.M.P. van der Aalst,M. Dumas, and F. P.Milani. Business Process Variability Modeling : A Survey. ACM Computing Surveys, 2013. [LS07] R. Lu and S. Sadiq. On the Discovery of Preferred Work Practice Through Business Process Variants. In ER, pages 165–180, 2007. [Mar03] R. C. Martin. Agile Software Development : Principles, Patterns, and Practices. Prentice Hall/Pearson Education, 2003. [MBF13] S. Mosser and M. Blay-Fornarino. "Adore", a Logical Meta-model Supporting Business Process Evolution. Sci. Comput. Program., 78(8) :1035–1054, 2013. [Mee10] S. Meerkamm. Configuration of Multi-perspectives Variants. In BPM, pages 277–288, 2010. [MHY08] M. Moon, M. Hong, and K. Yeom. Two-Level Variability Analysis for Business Process with Reusability and Extensibility. In COMPSAC, pages 263–270, 2008. [Mor10] B. Morin. Leveraging Models from Design-time to Runtime to Support Dynamic Variability. PhD thesis, University of Rennes 1, 2010. [MRGP08] T. Martínez-Ruiz, F. García, and M. Piattini. Towards a SPEM v2.0 Extension to Define Process Lines Variability Mechanisms. In SERA, pages 115–130, 2008. [MRGPM11] T. Martínez-Ruiz, F. García, M. Piattini, and J. Münch. Modelling Software Process Variability : an Empirical Study. IET Software, 5(2) :172– 187, 2011. [NCH11] T. Nguyen, A. Colman, and J. Han. Modeling and Managing Variability in Process-Based Service Compositions. In ICSOC, pages 404–420, 2011. [Nor08] L. Northrop. Software Product Lines Essentials, 2008. [OAS07] OASIS. Web Services Business Process Execution Language Version 2.0, 2007. [oD11] United States Department of Defense. Technology Readiness Assessment (TRA) Guidance, 2011. [OMG06] OMG. Meta Object Facility (MOF) 2.0 Core Specification, 2006. [OMG08] OMG. Software and Systems Process Engineering Metamodel Speci- fication (SPEM) Version 2, 2008. [OMG10] OMG. Documents associated with Object Constraint Language, Version 2.2, 2010. [OMG11a] OMG. Documents Associated with Business Process Model and Notation (BPMN) Version 2.0, 2011. [OMG11b] OMG. OMG Unified Modeling Language (OMG UML), Infrastructure Version 2.4.1, 2011.BIBLIOGRAPHIE 175 [OMG11c] OMG. OMG Unified Modeling Language (OMG UML), Superstructure Version 2.4.1, 2011. [OMG12] OMG. Diagram Definition (DD) Version 1.0, 2012. [Ost87] L. Osterweil. Software Processes are Software Too. In ICSE, pages 2–13, 1987. [PBL05] K. Pohl, G. Böckle, and F. J. van der Linden. Software Product Line Engineering : Foundations, Principles and Techniques. Springer, 2005. [PEM95] G. Pérez, K. Emam, and N. H. Madhavji. Customising Software Process Models. In SPT, pages 70–78, 1995. [PS05] V. Pankratius and W. Stucky. A Formal Foundation for Workflow Composition, Workflow View Definition, and Workflow Normalization Based on Petri Nets. In APCCM, pages 79–88, 2005. [PSWW05] F. Puhlmann, A. Schnieders, J. Weiland, and M. Weske. Variability Mechanisms for Process Models. Technical report, PESOA-Report TR 17/2005, Process Family Engineering in Service-Oriented Applications (PESOA), 2005. [RBJ07] R. Ramos, O. Barais, and J.M. Jézéquel. Matching Model-Snippets. In MoDELS 07, pages 121–135, 2007. [RBSS09] I. Reinhartz-Berger, P. Soffer, and A. Sturm. Organisational reference models : Supporting an adequate design of local business processes. International Journal of Business Process Integration and Management, 4(2) :134–149, 2009. [RBSS10] I. Reinhartz-Berger, P. Soffer, and A. Sturm. Extending the Adaptability of Reference Models. IEEE Transactions on Systems, Man and Cybernetics, Part A : Systems and Humans, 40(5) :1045–1056, 2010. [RCB+11] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Bridging the Gap between Software Process and Software Development. In IDM, pages 103–108, 2011. [RCB+12] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Leveraging CVL to Manage Variability in Software Process Lines. In APSEC, pages 148–157, 2012. [RCB+13a] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Improving Reusability in Software Process Lines. In SEAA, pages 90–94, 2013. [RCB+13b] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Integrating Software Process Reuse and Automation. In APSEC, pages 380–387, 2013. [RDH+08] M. Rosa, M. Dumas, A. H. Hofstede, J. Mendling, and F. Gottschalk. Beyond Control-Flow : Extending Business Process Configuration to Roles and Objects. In ER, pages 199–215, 2008.176 BIBLIOGRAPHIE [RGC04] F. Ruiz-Gonzalez and G. Canfora. Software Process : Characteristics, Technology and Environments. UPGrade, The European Journal for the Informatics Professional, 5(5) :6–10, 2004. [RHEdA05] N. Russell, A. H. M. Hofstede, D. Edmond, and W. M. P. der Aalst. Workflow Data Patterns : Identification, Representation and Tool Support. In ER, pages 353–368, 2005. [RK08] M. Razavian and R. Khosravi. Modeling Variability in Business Process Models Using UML. In ITNG, pages 82–87, 2008. [RMvdT09] H. A. Reijers, R. S. Mans, and R. A. van der Toorn. Improved Model Management with Aggregated Business Process Models. Data Knowledge Engineering, 168(2) :221–243, 2009. [Rom05] H. D. Rombach. Integrated Software Process and Product Lines. In ISPW, pages 83–90, 2005. [Roy87] W. W. Royce. Managing the Development of Large Software Systems : Concepts and Techniques. In ICSE, pages 328–338, 1987. [RTM10] S. H. Ripon, K. H. Talukder, and M. K. I. Molla. Modelling Variability for System Families. Malaysian Journal of Computer Science, 16(1) :37– 46, 2010. [RvdA07] M. Rosemann and W. M. P. van der Aalst. A Configurable Reference Modelling Language. Information Systems, 32(1) :1–23, 2007. [SA09] A. Sadovykh and A. Abherve. MDE Project Execution Support via SPEM Process Enactment. In MDTPI, 2009. [SB11] J. Simmonds and M. C. Bastarrica. Modeling Variability in Software Process Lines. Technical report, Universidad de Chile, 2011. [SBPM09] D. Steinberg, F. Budinsky, M Paternostro, and E. Merks. EMF : Eclipse Modeling Framework 2.0. Addison-Wesley Professional, 2009. [Sch00] A.-W. Scheer. Aris-Business Process Modeling. Springer-Verlag New York, Inc., 2000. [SCO07] B. I. Simidchieva, L. A. Clarke, and L. J. Osterweil. Representing Process Variation with a Process Family. In ICSP, pages 109–120, 2007. [SCS10] E. Santos, J. Castro, and O. Sánchez, J.and Pastor. A Goal-Oriented Approach for Variability in BPMN. In WER, pages 17–28, 2010. [SdSSB+10] I. Sharon, M. dos Santos Soares, J. Barjis, J. van den Berg, and J. L. M. Vrancken. A Decision Framework for Selecting a Suitable Software Development Process. In ICEIS, pages 34–43, 2010. [SO98] X. Song and L. J. Osterweil. Engineering Software Design Processes to Guide Process Execution. IEEE Transactions on Software Engineering, 24(9) :759–775, 1998.BIBLIOGRAPHIE 177 [Ter09] T. Ternité. Process Lines : A Product Line Approach Designed for Process Model Development. In SEAA, pages 173–180, 2009. [Tho05] O. Thomas. Understanding the Term Reference Model in Information Systems Research : History, Literature Analysis and Explanation. In BPM, pages 484–496, 2005. [TI93] T. Tamai and A. Itou. Requirements and Design Change in LargeScale Software Development : Analysis from the Viewpoint of Process Backtracking. In ICSE, pages 167–176, 1993. [VDATHKB03] W. M. P. Van Der Aalst, A. H. M. Ter Hofstede, B. Kiepuszewski, and A. P. Barros. Workflow Patterns. Distrib. Parallel Databases, 14(1) :5– 51, 2003. [VG07] M. Voelter and I. Groher. Product Line Implementation using AspectOriented and Model-Driven Software Development. In SPLC, pages 233–242, 2007. [Vis90] W. Visser. More or Less Following a Plan During Design : Opportunistic Deviations in Specification. International Journal of Man-Machine Studies, 33(3) :247–278, 1990. [(WF99] WorkFlow Managment Coalition (WFMC). Terminology & Glossary, Document Number WFMC-TC-1011, 1999. [Wis06] A. Wise. Little-jil 1.5 language report. Technical Report UM-CS-2006- 51, Department of Computer Science, University of Massachusetts, Amherst, MA, 2006. [WKK+11] M. Weidmann, F. Koetter, M. Kintz, D. Schleicher, and R. Mietzner. Adaptive Business Process Modeling in the Internet of Services (ABIS). In ICIW, pages 29–34, 2011. [WL99] D. M. Weiss and C. T. R. Lai. Software Product-Line Engineering : A Family-Based Software Development Process. Addison-Wesley Professional, 1999. [YLL+08] Y. Yu, A. Lapouchnian, S. Liaskos, J. Mylopoulos, and J. C.S.P. Leite. From Goals to High-Variability Software Design. In ISMIS, pages 1–16, 2008. [Zam01] K. Z. Zamli. Process Modeling Languages : A Literature Review. Malaysian Journal of Computer Science, 14(2) :26–37, 2001. [Zhu03] H. Zhuge. Component-based workflow systems development. Decision Support Systems, 35(4) :517 – 536, 2003. [ZXD05] W. Zhongjie, X. Xiaofei, and Z. Dechen. A Component Optimization Design Method Based on Variation Point Decomposition. In SERA, pages 399–406, 2005.178 BIBLIOGRAPHIEListe des figures 2.1 Modèle conceptuel de SPEM . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Structure du métamodèle de SPEM 2.0 [OMG08] . . . . . . . . . . . . . . 19 2.3 Extraits de certains paquetages du métamodèle de SPEM 2.0 . . . . . . . 20 2.4 Syntaxe concrète de SPEM 2.0 et des diagrammes d’activités . . . . . . . 21 2.5 Un processus simplifié de développement Java . . . . . . . . . . . . . . . 22 2.6 Détail de l’activité de développement du processus de la figure 2.5 . . . 22 2.7 Éléments de contenu de méthode du processus simplifié de développement Java de la figure 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.8 Principe général de CVL, issu de la spécification de CVL 4 . . . . . . . . 24 2.9 Extrait de la partie abstraction de la variabilité du métamodèle de CVL . 25 2.10 Exemple VAM spécifiant la variabilité d’un site d’achat en ligne . . . . . 26 2.11 Extrait de la partie réalisation de la variabilité du métamodèle de CVL . 27 2.12 VRM de l’exemple de site d’achat en ligne . . . . . . . . . . . . . . . . . . 28 2.13 Extrait de la partie résolution de la variabilité du métamodèle de CVL . 29 2.14 Exemple de RM résolvant le VAM de la figure 2.10 . . . . . . . . . . . . . 29 2.15 Modèle résolu obtenu en fonction des modèles des figures 2.10, 2.12 et 2.14 30 2.16 Exemple de définition d’affectation d’attribut, d’existence de lien et d’existence d’attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.17 Modèle résolu obtenu lorsque le choix de la figure 2.16 est sélectionné . 31 2.18 Modèle résolu obtenu lorsque le choix de la figure 2.16 n’est pas sélectionné 31 2.19 Exemple de VAM, VRM et modèle de base pour une substitution de fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.20 Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par une seule instance de variabilité . . . . . . . . . . 32 2.21 Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par deux instances de variabilité . . . . . . . . . . . . 32 2.22 Illustration du principe du point de variation composite . . . . . . . . . 33 3.1 Représentation en extension des processus d’une famille [LS07] . . . . . 36 3.2 Un exemple de modèle de processus agrégat [HBR10] . . . . . . . . . . . 44 3.3 Exemple de définition de points de variation et de variantes sur un modèle de processus [MHY08] . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4 Principe général de la contribution principale . . . . . . . . . . . . . . . . 65 4.1 Flot de tâches de l’exemple illustratif de processus de métamodélisation 68 179180 LISTE DES FIGURES 4.2 Ressources de l’exemple illustratif de processus de métamodélisation . . 68 4.3 Partie de la contribution principale réalisée par CVL4SP . . . . . . . . . . 70 4.4 Apperçu de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logiciel . . . . . . . . . . . . . . . . 70 4.5 Processus de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logiciel . . . . . . . . . . . . . 71 4.6 Eléments de contenu de méthode de l’exemple illustratif . . . . . . . . . 74 4.7 Processus le plus souvent utilisé de l’exemple illustratif . . . . . . . . . . 74 4.8 Eléments de processus externes de l’exemple illustratif . . . . . . . . . . 75 4.9 Extrait du VAM de l’exemple illustratif . . . . . . . . . . . . . . . . . . . 76 4.10 Extrait du VRM de l’exemple illustratif . . . . . . . . . . . . . . . . . . . 77 4.11 Extrait du RM de l’exemple illustratif . . . . . . . . . . . . . . . . . . . . 78 4.12 Modèle de processus résolu . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.13 Séquence de travail sur-spécifiée . . . . . . . . . . . . . . . . . . . . . . . 82 5.1 Extrait d’un script PowerShell qui automatise la configuration de l’espace de travail d’un développeur . . . . . . . . . . . . . . . . . . . . . . . 87 5.2 Partie de la contribution principale réalisée par M4RAC . . . . . . . . . . 88 5.3 Vue générale de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4 Première étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.5 Exemple simplifié de ligne de processus de développement Java . . . . . 90 5.6 Deuxième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.7 Troisième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.8 Liaison entre le CA configurant l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 . . . . . . . . . . . . . . . . . . . . . 93 5.9 Quatrième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.10 Liaisons entre les CA permettant de configurer l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 . . . . . . . . . . . . 95 5.11 Cinquième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.12 Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec SVN . . . . . . . . . . . . . . . . . . . . . 96 5.13 Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec Git . . . . . . . . . . . . . . . . . . . . . . 96 5.14 Extrait du CA automatisant les étapes 2 à 5 de la configuration de l’espace de travail d’un développeur . . . . . . . . . . . . . . . . . . . . . 97 6.1 Vue générale de l’architecture de T4VASP . . . . . . . . . . . . . . . . . . 108 6.2 Partie de l’approche supportée par les modeleurs de VAM et de VRM . . 110 6.3 Partie de l’approche supportée par les modeleurs de CA abstraits et de liaisons et le framework support à l’implémentation des CA . . . . . . . . 110 6.4 Partie de l’approche supportée par l’assistant à la résolution de la variabilité et le moteur de dérivation CVL . . . . . . . . . . . . . . . . . . . . . 112 6.5 Partie de l’approche supportée par l’interpréteur de processus . . . . . . 113LISTE DES FIGURES 181 6.6 Extrait du VAM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VAM . . . . . . . . . . . . . . . . 114 6.7 Extrait du VRM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VRM . . . . . . . . . . . . . . . . 114 6.8 Propriétés de l’existence d’objet tree editor de la figure 6.7 . . . . . . . . . 114 6.9 Métamodèle de CA abstraits et de liaisons . . . . . . . . . . . . . . . . . . 115 6.10 Diagramme d’objets représentant un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif . . . . . . . . . . . . . . . . . . . . . 116 6.11 Extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de CA abstraits et de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.12 Composants du framework . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.13 Enregistrement auprès du point d’extension activityautomationregistry . . 118 6.14 Comportement du gestionnaire d’informations contextuelles . . . . . . . 119 6.15 Extrait du modèle de contexte d’un processus de métamodélisation avec contrôle de version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.16 Exemple de déclaration par un CA d’informations contextuelles . . . . . 121 6.17 Exemple de demande d’informations contextuelles à l’acteur courant du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6.18 Utilisation de l’assistant à la résolution de la variabilité avec l’exemple illustratif de famille de processus de métamodélisation . . . . . . . . . . 123 6.19 Comportement du moteur de dérivation CVL . . . . . . . . . . . . . . . . 124 6.20 Comportement de l’interpréteur de processus . . . . . . . . . . . . . . . . 125 6.21 Détection de variabilité non résolue . . . . . . . . . . . . . . . . . . . . . 126 6.22 Vue processus d’une variante de processus de métamodélisation . . . . . 128 7.1 Point d’entrée du CA permettant de générer un éditeur arborescent . . . 135 7.2 Méthode run de la classe GenerateTreeEditor, appelée par la méthode run de la figure 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 7.3 Point d’entrée du CA initialisant la tâche de définition d’un interpréteur 137 7.4 Extrait des méthodes permettant l’initialisation d’un interpréteur Kermeta138 7.5 Modèle de processus résolu du cas d’application de la famille de processus de métamodélisation . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.6 Un exemple simplifié de processus de développement web Java . . . . . 140 7.7 Code du CA permettant d’installer le plug-in Eclipse Subclipse . . . . . 143 7.8 Code du CA créant un nouveau serveur Tomcat . . . . . . . . . . . . . . 144 A.1 Extrait du VAM de la famille de processus de métamodélisation . . . . . 158 A.2 Extrait du VRM de la famille de processus de métamodélisation . . . . . 159 A.3 Extrait du modèle de liaisons de la famille de processus de métamodé- lisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 A.4 Déclaration de la classe implémentant l’action Java Eclipse CreateEmptyEMFProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 A.5 Code de la classe CreateEmptyEMFProjectActivityAutomation . . . . . 161182 LISTE DES FIGURES A.6 Extrait du RM du cas d’application de la famille de processus de métamodélisation de la section 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . 162 B.1 Extrait du VAM de la famille de processus de développement web Java . 163 B.2 Extrait du VRM de la famille de processus de développement web Java . 165 B.3 Extrait du modèle de liaisons de la famille de processus de développement web Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 B.4 Déclaration de la classe implémentant l’action Java Eclipse install wtp . . 166 B.5 Information contextuelle du CA installant le plug-in WTP . . . . . . . . 167 B.6 Code de la classe InstallWTP . . . . . . . . . . . . . . . . . . . . . . . . . 167 B.7 Extrait du RM du cas d’application de la famille de processus de développement web Java de la section 7.2 . . . . . . . . . . . . . . . . . . . . . 168Liste des tables 3.1 Évaluation des approches permettant d’identifier le processus correspondant le mieux à un projet . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 Évaluation des approches de Lu et Sadiq [LS07] et Song et Osterweil [SO98] 41 3.3 Évaluation des approches apportant un support à la réutilisation de patrons de processus, mais sans permettre la réutilisation automatique de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.4 Évaluation des approches s’appuyant sur l’ingénierie des lignes de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5 Évaluation de l’ensemble des approches supportant la réutilisation des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.1 Exemples de TMR réalisées durant un processus de métamodélisation . 106 7.1 Tableau récapitulatif du nombre d’éléments de modèle et de CA pour chaque cas d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 183184 LISTE DES TABLESListe des publications [RCB+11] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Bridging the Gap between Software Process and Software Development. In IDM, pages 103–108, 2011. [RCB+12] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Leveraging CVL to Manage Variability in Software Process Lines. In APSEC, pages 148–157, 2012. [RCB+13a] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Improving Reusability in Software Process Lines. In SEAA, pages 90–94, 2013. [RCB+13b] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Integrating Software Process Reuse and Automation. In APSEC, pages 380–387, 2013. 185Résumé De nombreux outils existent afin de faire face à la complexité des logiciels et des projets de développement logiciel. Leur utilisation est cependant à l’origine de tâches manuelles répétitives, sources d’erreurs et coûteuses en temps. L’automatisation de ces tâches permet de gagner en productivité. Mais la difficulté est de déterminer quand une automatisation de tâche manuelle répétitive doit être réutilisée, ainsi que de créer des automatisations réutilisables à travers leurs différents cas d’utilisation. Nous proposons donc une approche outillée pilotant la réutilisation des automatisations de tâches manuelles répétitives par les processus de développement logiciel, où un processus de développement logiciel décrit les étapes à réaliser pour mener à bien un projet de développement logiciel. Cette approche consiste à capitaliser sur un ensemble de processus et à réutiliser des processus de cet ensemble en fonction des exigences des projets, indépendamment du formalisme utilisé pour définir les processus. Des automatisations de tâches manuelles répétitives sont liées aux étapes des processus qu’elles automatisent. Ce lien permet de savoir quelles automatisations utiliser pour un projet donné et quand. Il permet également d’expliciter les différents cas d’utilisation de chaque automatisation. Cette information est utilisée afin de créer des automatisations réutilisables à travers leurs différents cas d’utilisation. L’approche ainsi que l’outillage associé ont été appliqués sur une famille de processus industriels de développement Java ainsi que sur une famille de processus consistant à définir et outiller un langage de modélisation. Abstract Many tools have been developped in order to manage the complexity of the software and of the software development projects. However, using these tools is the source of manual recurrent tasks that are error prone and time consuming. Automating these tasks enables to improve the productivity. But the difficulties are i) to determine when the automation of a manual recurrent task must be used, and ii) to create automations that are reusable across their different use cases. We propose a tool-supported approach that drives the reuse of the automations of the manual recurrent tasks by software processes. A software process defines the sequence of steps to perform in order to realize a software engineering project. This approche consists of capitalizing on a set of software processes and of reusing processes from this set according to projects’ requirements and independently of the formalism used to define the processes. The automations of the manual recurrent tasks are bound to the processes’ steps they automate. This binding enables to know which automations to reuse for a specific project and when to reuse these automations during the project. This binding also enables to explicit the different use cases of each automation. We use this information to create automations that are reusable across their different use cases. We applied this tool-supported approach on a family of Java development processes coming from the industry as well as on a family of processes consisting of designing and implementing a modeling language. Faciliter le d´eveloppement des applications de robotique Selma Kchir To cite this version: Selma Kchir. Faciliter le d´eveloppement des applications de robotique. Robotics. Universit´e Pierre et Marie Curie - Paris VI, 2014. French. . HAL Id: tel-01071062 https://tel.archives-ouvertes.fr/tel-01071062 Submitted on 3 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse de doctorat de l’Université Pierre & Marie Curie Spécialité Informatique Ecole Doctorale Informatique, Télécommunications et Électronique (Paris) Présentée par Selma Kchir Pour obtenir le grade de DOCTEUR de l’UNIVERSITÉ PIERRE ET MARIE CURIE Sujet de la thèse Faciliter le développement des applications de robotique Date de soutenance: le 26/06/2014 Devant le jury composé de: M.Xavier Blanc Professeur à l’Université Bordeaux 1 Examinateur M.Noury Bouraqadi Maître de conférences HDR à l’Ecole des mînes de Douai Rapporteur M.Jacques Malenfant Professeur à l’Université Pierre et Marie Curie Examinateur M.Bernard Pottier Professeur à l’Université de Bretagne Occidentale Examinateur M.Amar Ramdane-Chérif Professeur à l’Université de Versailles Saint Quentin en Yvelines Rapporteur M.Serge Stinckwich Maître de conférences à l’Université Caen Co-Encadrant M.Tewfik Ziadi Maître de conférences à l’Université Pierre et Marie Curie Co-Encadrant M.Mikal Ziane Maître de conférences HDR à l’Université Paris Descartes DirecteurTable des matières Table des figures vii Liste des tableaux xi Introduction générale 1 1 Contexte et problèmatique . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 I Etat de l’art 5 La variabilité dans le domaine de la robotique 7 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 La variabilité dans le domaine de la robotique . . . . . . . . . . . . . 9 3.1 La variabilité des capteurs . . . . . . . . . . . . . . . . . . . . 9 3.2 La variabilité des effecteurs . . . . . . . . . . . . . . . . . . . 11 3.3 La variabilité dans les architectures de robotique . . . . . . . . 12 3.3.1 Les architectures délibératives . . . . . . . . . . . . . 12 3.3.2 Les architectures réactives . . . . . . . . . . . . . . . 13 3.3.3 Les architectures hybrides . . . . . . . . . . . . . . . 15 3.4 La variabilité dans les algorithmes de robotique . . . . . . . . 15 4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 iTable des matières Les middleware de robotique 19 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.2 Les abstractions du matériel dans Player . . . . . . . 21 2.1.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Robot Operating System (ROS) . . . . . . . . . . . . . . . . . 23 2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2 Les abstractions du matériel dans ROS . . . . . . . . 24 2.2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3 Middleware for Robots (MIRO) . . . . . . . . . . . . . . . . . 25 2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.2 Les abstractions du matériel dans MIRO . . . . . . . 27 2.3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 28 2.4 Python Robotics (PyRo) . . . . . . . . . . . . . . . . . . . . . 29 2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 29 2.4.2 Les abstractions du matériel dans PyRo . . . . . . . 29 2.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 30 3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Langages de modélisations spécifiques à la robotique 33 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2 Langages de Modélisation Spécifiques aux domaines (DSML) . . . . . 34 2.1 Les techniques d’ingénierie dirigée par les modèles . . . . . . . 35 2.1.1 Les niveaux de modélisation . . . . . . . . . . . . . . 36 2.1.2 Les transformations . . . . . . . . . . . . . . . . . . 38 3 Cycle de vie d’un DSML . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.1 Analyse du domaine . . . . . . . . . . . . . . . . . . . . . . . 40 3.1.1 Les ontologies . . . . . . . . . . . . . . . . . . . . . . 41 3.2 Conception des DSML . . . . . . . . . . . . . . . . . . . . . . 42 3.2.1 Définition de la syntaxe abstraite . . . . . . . . . . . 42 3.2.2 Définition de la syntaxe concrète . . . . . . . . . . . 44 iiTable des matières 3.3 Intégration des plateformes : Transformations et Génération de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4 Les DSML pour la robotique . . . . . . . . . . . . . . . . . . . . . . . 46 4.1 Exigences des langages de domaine pour la robotique . . . . . 46 4.2 Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.1 BRICS Component Model (BCM) . . . . . . . . . . 48 4.2.2 Open Robot Controller Computer Aided Design (ORCCAD) . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.3 SmartSoft . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.4 The 3 View Component Meta-Model (V3CMM) . . . 53 4.2.5 GenoM3 . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.6 Robot Technology Component (RTC) . . . . . . . . 56 4.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 II Contributions 61 Robotic Modeling Language (RobotML) 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2 Vue d’ensemble sur le cycle de vie de RobotML . . . . . . . . . . . . 65 3 Analyse du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4 Conception de RobotML . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1 Syntaxe abstraite . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.1 Le modèle de domaine RobotML : méta-modèle . . . 71 4.1.2 Le profil RobotML . . . . . . . . . . . . . . . . . . . 80 4.2 Syntaxe concrète : L’éditeur graphique de RobotML . . . . . . 82 5 Intégration du middleware OROCOS : génération de code . . . . . . 84 5.1 Génération du squelette d’un composant . . . . . . . . . . . . 85 5.2 Génération de la communication entre les composants . . . . . 86 5.3 Génération du comportement d’un composant . . . . . . . . . 87 6 Utilisation : chaîne d’outillage RobotML . . . . . . . . . . . . . . . . 90 7 Validation et Expérimentations . . . . . . . . . . . . . . . . . . . . . 91 7.1 Scénario de l’AIROARP . . . . . . . . . . . . . . . . . . . . . 92 iiiTable des matières 7.2 Conception du scénario avec RobotML . . . . . . . . . . . . . 92 7.3 Génération de code vers OROCOS . . . . . . . . . . . . . . . 94 8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 99 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 2 Approche pour la gestion de la variabilité dans les algorithmes de robotique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 2.1 Identification des abstractions . . . . . . . . . . . . . . . . . . 101 2.2 Identification de l’algorithme générique . . . . . . . . . . . . . 103 2.3 Organisation de l’implantation . . . . . . . . . . . . . . . . . . 104 2.3.1 Implantation des abstractions non algorithmiques . . 105 2.3.2 Implantation des abstractions algorithmiques et de l’algorithme générique . . . . . . . . . . . . . . . . . 106 3 Application sur la famille d’algorithmes Bug . . . . . . . . . . . . . . 108 3.1 La famille d’algorithmes Bug . . . . . . . . . . . . . . . . . . . 108 3.1.1 Bug1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.1.2 Bug2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.1.3 Alg1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.1.4 Alg2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.1.5 DistBug . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.1.6 TangentBug . . . . . . . . . . . . . . . . . . . . . . . 114 3.2 Identification des abstractions de la famille Bug . . . . . . . . 114 3.3 Identification de l’algorithme générique de la famille Bug . . . 121 3.4 Organisation de l’implantation de la famille Bug . . . . . . . . 122 3.5 Expérimentations et Validation . . . . . . . . . . . . . . . . . 124 3.5.1 Environnement de simulation : Stage-ROS . . . . . . 125 3.5.2 Configurations des environnements et des capteurs . 126 3.5.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . 127 4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Conclusion générale et perspectives 131 ivTable des matières Références bibliographiques 135 vTable des figures viTable des figures I.1 Architecture verticale - paradigme hiérarchique (adaptée de [1]) . . 13 I.2 Architecture de subsomption . . . . . . . . . . . . . . . . . . . . . 15 II.3 Communication entre les noeuds ROS . . . . . . . . . . . . . . . . 24 II.4 Le regroupement des capteurs dans PyRO . . . . . . . . . . . . . . 30 III.5 Les différents niveaux de modélisation . . . . . . . . . . . . . . . . 36 III.6 Les artefacts du DSL - extrait de [2] . . . . . . . . . . . . . . . . . 44 III.7 Intégration des plateformes - basé sur [2] . . . . . . . . . . . . . . . 45 III.8 Les concepts de l’OMG appliqués à l’approche BCM - (tiré de [3]) . 48 III.9 Le méta-modèle CPC - (tiré de [3]) . . . . . . . . . . . . . . . . . . 50 III.10 Le méta-modèle RT extrait du méta-modèle d’ORCCAD - (tiré de [4]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 III.11 Le méta-modèle de SmartSoft - (tiré de [5]) . . . . . . . . . . . . . 52 III.12 Méta-modèle V3CMM - tiré de [6] . . . . . . . . . . . . . . . . . . 54 III.13 Architecture de Genom3 . . . . . . . . . . . . . . . . . . . . . . . . 55 III.14 Composant RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 IV.15 Classification des systèmes dans l’ontologie (extrait de [7]) . . . . . 67 IV.16 Intéraction entre les systèmes dans l’ontologie (extrait de [7]) . . . 68 IV.17 La classe Information dans l’ontologie (extrait de [7]) . . . . . . . . 68 IV.18 RobotML Domain Model . . . . . . . . . . . . . . . . . . . . . . 71 IV.19 RoboticArchitecture Package . . . . . . . . . . . . . . . . . . . . . 72 IV.20 La méta-classe Property . . . . . . . . . . . . . . . . . . . . . . . . 73 viiTable des figures IV.21 Le package RoboticSystem . . . . . . . . . . . . . . . . . . . . . . . 73 IV.22 RobotML Data Types . . . . . . . . . . . . . . . . . . . . . . . . 74 IV.23 physicalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 IV.24 Types composés de RobotML . . . . . . . . . . . . . . . . . . . . . 75 IV.25 Types primitifs de RobotML . . . . . . . . . . . . . . . . . . . . . 75 IV.26 Intégration des geometry_msgs de ROS à RobotML . . . . . . . . 76 IV.27 Le package Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 77 IV.28 Le package Deployment . . . . . . . . . . . . . . . . . . . . . . . . 77 IV.29 Le package RoboticBehavior . . . . . . . . . . . . . . . . . . . . . . 78 IV.30 Le package FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 IV.31 Les mécanismes de communication . . . . . . . . . . . . . . . . . . 80 IV.32 Extrait de la partie Architecture : Stéréotypes extensions de la méta-classe Class d’UML . . . . . . . . . . . . . . . . . . . . . . . 81 IV.33 Extrait de la partie communication : Stéréotypes extensions de la méta-classe Port d’UML . . . . . . . . . . . . . . . . . . . . . . . . 82 IV.34 Extrait de la partie Control : Stéréotypes extensions des métaclasses du méta-modèle d’UML . . . . . . . . . . . . . . . . . . . . 82 IV.35 À gauche, les icônes attachées aux stéréotypes, à droite la palette montrant les différentes icônes . . . . . . . . . . . . . . . . . . . . . 83 IV.36 Environnement de modélisation de RobotML . . . . . . . . . . . . 84 IV.37 Génération de code avec OROCOS . . . . . . . . . . . . . . . . . . 90 IV.38 Etapes de modélisation en utilisant RobotML . . . . . . . . . . . . 91 IV.39 Modèle des types de données AIR OARP . . . . . . . . . . . . . . 93 IV.40 Les interfaces du scénario AIR OARP . . . . . . . . . . . . . . . . 94 IV.41 Le composant AvionicSystem . . . . . . . . . . . . . . . . . . . . . 94 IV.42 Le composant CameraSystem . . . . . . . . . . . . . . . . . . . . . 95 IV.43 Modèle du scénario AIR OARP . . . . . . . . . . . . . . . . . . . . 95 V.44 Implantation des abstractions non algorithmiques : adaptateurs . . 106 V.45 Application du pattern Bridge . . . . . . . . . . . . . . . . . . . . . 107 V.46 Application du pattern Template Method . . . . . . . . . . . . . . 108 viiiTable des figures V.47 Le contournement d’obstacle : (1) le robot à droite doit tourner à droite pour se rapprocher de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle. (2) le robot à gauche doit tourner à gauche pour s’éloigner de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle . . . . . . . . . . . . . . . . . . . . 117 V.48 La détection d’obstacle devant, à gauche et à droite du robot avec des capteurs de distance . . . . . . . . . . . . . . . . . . . . . . . . 117 V.49 Exemple de getDistanceRight : la distance retournée est la moyenne des distances détectées parmi tous les rayons émanant du capteur droit du robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 V.50 Extrait du digramme de classe de la famille Bug . . . . . . . . . . . 124 V.51 Architecture de l’application correspondant à Bug1 . . . . . . . . . 125 V.52 Environnement1 : but inatteignable . . . . . . . . . . . . . . . . . . 126 V.53 Environnement2 : Environnement avec un seul obstacle . . . . . . . 126 V.54 Environnement3 : Environnement avec plusieurs obstacles . . . . . 127 ixListe des tableaux xListe des tableaux I.1 Classification des capteurs inspirée de [8] et de [9] . . . . . . . . . . 10 II.2 Exemple de sensor messages de ROS . . . . . . . . . . . . . . . . . 25 II.3 à gauche le code écrit en fonction du capteur Laser, à droite le code après sa modification avec les Infrarouges . . . . . . . . . . . . . . 26 III.4 Comparaison entre les DSML pour la robotique existants . . . . . . 60 IV.5 Correspondance entre OWL et UML . . . . . . . . . . . . . . . . . 70 IV.6 Correspondance entre le DSL Architecture et les concepts d’OROCOS 86 IV.7 Correspondance entre le DSL Communication et les concepts d’OROCOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 IV.8 Correspondance entre le DSL Communication et les concepts d’OROCOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 IV.9 Correspondance entre le DSL Contrôle et les concepts d’OROCOS . 88 xiIntroduction générale 1 Contexte et problèmatique Les roboticiens sont confrontés à plusieurs difficultés pour le développement de leurs applications en raison de l’hétérogénéïté des concepts de la robotique. En effet, dans le cas de la robotique mobile les roboticiens doivent maîtriser les détails liés aux moyens de locomotion du robot, à sa morphologie ainsi qu’à ses capteurs. De plus, la variabilité du matériel rend les applications de robotique fragiles : un changement du matériel dans une application déjà développée impliquerait la réécriture du code de celle-ci. Il faudrait alors découpler le code de l’application à travers des abstractions de haut niveau afin de la rendre plus stable vis-à-vis des changements du matériel. Pour répondre à ce constat de variabilité du matériel, certains middleware de robotique tels que ROS [10], MIRO [11], PyRO [12] et Player [13] ont proposé des abstractions du matériel pour permettre une montée en niveau d’abstractions par rapport aux détails du matériel. Ces dernières permettent d’encapsuler des données spécifiques au matériel afin de fournir des données de plus haut niveau. Cependant, ces abstractions restent de bas niveau et ne permettent pas une isolation de certains changements dans le matériel. Il serait alors plus simple pour les roboticiens de manipuler, à travers des outils, des concepts qu’ils ont l’habitude d’utiliser et qui soient de plus haut niveau que ceux proposés par les middleware. Dans cette optique qui vise à définir des abstractions de haut niveau pour les applications de robotique et à faciliter leur développement, les langages de modélisation spécifiques au domaine (en anglais DSML : Domain Specific Modeling Language) offrent à travers des notations appropriées et des abstractions, une puissance expressive axée sur, et généralement limitée à, un domaine particulier [14]. 1Introduction générale Ces abstractions sont définies par les experts du domaine d’application réduisant ainsi le fossé sémantique entre les développeurs et les experts du domaine afin de faciliter le développement des applications du domaine. L’utilisation de l’ingénierie dirigée par les modèles (IDM) (en anglais Model Driven Engineering (MDE)) [15] dans ce contexte permettrait de gérer les problèmes de dé- pendance de bas niveau (c.-à-d. variabilité du matériel et des plateformes) à travers des modèles stables basés sur des abstractions du domaine. De plus, la génération automatique de code à partir de ces modèles vers plusieurs plateformes cibles offrirait un gain de temps et une facilité pour le développement des applications de robotique. Plusieurs DSML pour la robotique ont été définis tels que BCM [3], SmartSoft [16] et ORCCAD [4] mais ils s’intéressent essentiellement aux aspects qui relèvent de l’architecture d’une application (architecture à base de composants) et à la communication entre ses composants. Les abstractions utilisées dans ces DSML sont insuffisantes car elles ne permettent pas de représenter tous les concepts d’une application tels qu’ils sont manipulés par les roboticiens. Par ailleurs, ils ne définissent pas d’abstractions pour le matériel. Il faudrait alors convenir d’un ensemble d’abstractions stables qui permettraient de représenter les concepts d’une application de robotique afin de faciliter son développement et garantir son indépendance par rapport aux plateformes cibles. Ces concepts peuvent être des concepts de haut niveau comme ceux proposés par les DSML. Cependant ces derniers manquent souvent de sémantique opérationnelle car ils représentent souvent des concepts généraux du domaine. Il faudrait alors défi- nir des abstractions de haut niveau qui permettent , indépendamment du matériel utilisé, d’obtenir des informations sur l’environnement du robot et de définir des actions de haut niveau d’une part et d’encapsuler les détails algorithmiques d’une application d’une autre part. 2 Contributions Cette thèse tente d’apporter des solutions aux problèmes présentés précédemment. Dans cette optique, nous avons contribué au développement d’un DSML pour la robotique (RobotML) dans le cadre d’un projet ANR, appelé PROTEUS. Les abstractions fournies par RobotML se basent sur une ontologie du domaine de la 2Introduction générale robotique basée sur les connaissances des experts du domaine. Des outils ont été dé- veloppés autour de RobotML permettant la modélisation de scénarios de robotique et une génération automatique de code vers une ou plusieurs plateformes cibles. – Il devient alors facile pour un expert en robotique et même pour des simples utilisateurs débutants en robotique de représenter les scénarios de leurs applications. – Les modèles représentés avec RobotML sont stables et indépendants des plateformes cibles. – La génération de code à partir de RobotML se fait vers une ou plusieurs plateformes hétérogènes (c.-à-d. simulateurs ou robots réels d’une part et middleware d’une autre part) et permet d’obtenir une application compilable ainsi que les artefacts nécessaires pour son exécution. Cependant, les expériementations basées sur RobotML ont montré que les abstractions du domaine définies dans l’ontologie sont insuffisantes. En effet, les abstractions de l’ontologie sont basées sur les connaissances du domaine et non pas sur plusieurs itérations appliquées sur des exemples concrets. Par conséquent, elles manquent de sémantique opérationnelle et sont trop générales pour pouvoir être utilisées pour la définition d’abstractions du matériel par exemple. Il faudrait alors partir d’exemples concrets et appliquer une approche complémentaire pour enrichir les abstractions du domaine avec des abstractions a posteriori. Nous avons donc proposé une approche qui, à partir de la description d’une tâche de robotique et des hypothèses sur l’environnement et sur les capacités du robot, produit : – un ensemble d’abstractions non algorithmiques représentant des requêtes sur l’environnement y compris le robot ou des actions de haut niveau ; – un ensemble d’abstractions algorithmiques représentant un ensemble d’instructions permettant de réaliser une sous-tâche de la tâche à développer ; – un algorithme générique configurable défini en fonction de ces abstractions. Ainsi, l’impact du changement du matériel et des stratégies définies dans les soustâches n’est pas très important. Il suffit d’adapter l’implantation de ces abstractions sans avoir à modifier l’algorithme générique. 3Introduction générale 3 Plan de la thèse Cette thèse s’organise comme suit : Le chapitre 1 présente tout d’abord le contexte de ce travail : la variabilité dans le domaine de la robotique. Nous pré- senterons les différentes catégories des capteurs, des effecteurs, des architectures de robotique et des algorithmes de robotique. Nous dresserons ensuite dans le chapitre 2 un état de l’art sur les abstractions proposées par certains des middlewares de robotique existants pour répondre au problème de la variabilité du matériel. Nous présenterons ensuite dans le chapitre 3 les DSML de robotique proposés pour faciliter le développement des applications de robotique et garantir leur indépendance par rapport aux plateformes cibles. Nous présenterons notre DSML pour la robotique (RobotML) ainsi que la génération de code vers un middleware de robotique (OROCOS) et un scénario que nous avons utilisé pour la validation de nos travaux dans le chapitre 4. Notre approche pour la définition des abstractions pertinentes et d’un algorithme générique à partir de la description d’une tâche de robotique ainsi que son application sur une famille d’algorithmes de navigation sera présentée dans le chapitre 5. Nous concluerons cette thèse par un rappel de nos contributions et des discussions sur les perspectives. 4Première partie Etat de l’art 5La variabilité dans le domaine de la robotique 1 Introduction La robotique mobile désigne l’étude des robots à base mobile qui, par opposition aux robots marcheurs, aux robots manipulateurs ou encore aux robots aériens, sont des robots ayant pour moyen de locomotion des roues. Les définitions du terme robot dans la littérature sont diverses, quelquefois très générales comme la définition de Brady [17] ”[...] une connexion intelligente entre la perception et l’action”. Arkin [1], quant à lui, a donné une définition plus spécifique ”Un robot intelligent mobile est une machine capable d’extraire des informations sur son environnement et d’utiliser les connaissances sur son monde afin de se déplacer de manière significative et en toute sécurité”. Par sa définition, Arkin explique qu’il existe une connexion entre la perception et l’action ; deux concepts fondamentaux en robotique qui varient d’un robot à l’autre. Cette connexion n’est autre que le système de contrôle du robot qui définit un ensemble de fonctions permettant au robot d’atteindre le but de sa mission. La perception, l’action et le système de contrôle forment une application de robotique. On peut parler alors de plusieurs types de variabilités : la variabilité liée à la perception, à l’action et au contrôle du robot qui concerne les aspects architecturaux d’une application. Dans ce chapitre, nous nous proposons de présenter les concepts de la robotique que nous allons utiliser tout au long de cette thèse ainsi que les principaux types de variabilité en robotique. 7Chapitre I. La variabilité dans le domaine de la robotique 2 Définitions En raison de la diversité des définitions présentes dans la littérature, nous nous proposons dans cette section de présenter les définitions des concepts que nous utiliserons tout au long de cette thèse. Nous nous plaçons dans le contexte de la robotique mobile non humanoïde où les robots sont équipés de capteurs et d’effecteurs afin d’intéragir avec leur environnement. Definition 1 (Robot mobile autonome). Un robot mobile autonome est un robot intelligent capable d’exécuter une tâche sans l’intervention des humains, il est capable de percevoir l’état de son environnement et de se déplacer dans celui-ci afin d’accomplir une tâche particulière (définition adaptée de la définition d’Arkin [1]). Definition 2 (Perception). La perception est l’extraction d’informations sensorielles, à partir des capteurs, indiquant l’état du robot dans son environnement. Definition 3 (Action). L’action est l’interprétation des données sensorielles ou de directives envoyées par le système de contrôle du robot en commandes envoyées aux effecteurs du robot. Definition 4 (Tâche). Une tâche est constituée d’un ensemble d’actions permettant au robot d’accomplir un but ou un sous-but. Definition 5 (Planification). La planification est l’analyse d’une séquence d’actions primitives afin de réduire l’écart entre l’état actuel du robot et le but qu’il doit atteindre. (définition adaptée de Nilsson [18] et du paradigme General Problem Solver [19]). Definition 6 (Système de contrôle). Le système de contrôle du robot est le système responsable de coordonner les parties perception et action du robot afin de réaliser une tâche particulière. Definition 7 (Paradigme). Un paradigme est une philosophie ou un ensemble d’hypothèses et/ou de techniques qui caractérisent une approche pour une classe de problèmes [20]. Definition 8 (Architecture). Une architecture de robotique est une discipline consracrée à la conception de robots hautement spécifiques et individuels à partir d’une collection de modules logiciels communs [1]. Une architecture est un pattern pour l’implémentation d’un paradigme [20]. 8I.3 La variabilité dans le domaine de la robotique Definition 9 (Middleware). Un middleware est une couche d’abstraction entre le système d’exploitation et l’application [21]. Definition 10 (Variabilité). La variabilité désigne l’étendue des différentes catégories que peut prendre un concept. En robotique, on trouve de la variabilité dans les capteurs, dans les effecteurs, dans les algorithmes, dans les architectures, etc. 3 La variabilité dans le domaine de la robotique Dans cette section, nous présentons la variabilité dans les concepts présentés dans la section précédente. La variabilité désigne la diversité des catégories ou des classifications pour un concept donné (une tâche, un capteur, un effecteur, un environnement, etc). 3.1 La variabilité des capteurs La perception, comme nous l’avons définie précédemment, est l’extraction d’informations de l’environnement du robot à travers ses capteurs. Le choix des capteurs dépend de la nature des informations dont le robot a besoin pour accomplir sa tâche. Les capteurs sont des dispositifs qui répondent à un signal ou à un stimulus. Un stimulus est une quantité, une propriété ou une condition détectée et convertie en un signal électrique [22]. À la différence des transducteurs qui convertissent un type d’énergie en un autre type d’énergie, les capteurs convertissent une énergie en un signal électrique. Dans la littérature, les capteurs sont généralement regroupés selon deux principales catégories : proprioceptifs ou exteroceptifs. – Les capteurs proprioceptifs mesurent l’état interne du robot. Comme par exemple, la vitesse du moteur, le niveau de batterie, etc. – Les capteurs exteroceptifs récupèrent les informations à partir de l’environnement du robot. Par exemple, l’intensité de la lumière, une mesure de distance, etc. Les capteurs sont également classés relativement à la nature de leur fonctionnement : – Les capteurs passifs mesurent l’énergie présente dans l’environnement, par exemple les microphones, les sondes de température, etc. – Les capteurs actifs émettent une énergie dans l’environnement et mesurent la réaction de l’environnement à celle-ci. 9Chapitre I. La variabilité dans le domaine de la robotique Une autre classification des capteurs dans la littérature dépend des données que les capteurs peuvent mesurer (stimulus), leurs spécifications, le mécanisme de conversion qu’ils utilisent et le matériel à partir duquel ils sont conçus [22]. Par exemple dans le cas des capteurs à portée (appelés aussi capteurs à rayons), nous notons une variabilité par rapport à la portée des capteurs, aux nombres de rayons, à la largeur du (ou des) rayons dont ils disposent, au champs de vision (Field of view) des capteurs, etc. Classification Capteurs Type Capteurs de localisation GPS exteroceptif actif Odométrie proprioceptif actif Capteurs à rayons Laser exteroceptif actif Infrarouge exteroceptif actif Ultrasonic exteroceptif actif Capteurs basés sur la vision Caméra exteroceptif passif Capteurs Moteur/Roues encodeurs inductifs proprioceptif passif Capteurs tactiles Bumpers, Contact switches exteroceptif passif Table I.1 – Classification des capteurs inspirée de [8] et de [9] Le tableau I.1 montre quelques exemples de capteurs proprioceptifs et exteroceptifs. Typiquement, le cas du GPS et de l’odométrie qui tous deux, servent à la localisation du robot mais ne sont pas de la même nature. La localisation consiste à indiquer la position du robot et son orientation. – l’Odométrie : Les roues motrices d’un robot sont habituellement associées à un servomoteur. Celui-ci est équipé d’un dispositif de mesure de rotation, il s’agit d’un capteur proprioceptif appelé odomètre. L’odométrie est le moyen de localisation le plus simple qui permet d’estimer la position d’un robot mobile en mouvement. À une position donnée correspondent une multitude d’orientations possibles du robot. L’orientation du robot ne peut s’obtenir qu’en connaissant son orientation de départ ainsi que son évolution sur sa trajectoire. L’utilisation de l’odométrie est basée sur l’hypothèse de roue sans glissement (contrainte non holonomique que nous présenterons dans la section suivante) et sur la supposition que les paramètres géométriques du robot sont parfaitement connus. 10I.3 La variabilité dans le domaine de la robotique – Global Positionning System (GPS) : est un système de géolocalisation qui effectue des émissions synchronisées dans le temps à des satellites. A l’aide des messages émis aux satellites, le récepteur peut calculer sa position. Le principe de calcul de la position s’appuye sur le principe de la triangulation (calcul de la distance par rapport à 3 satellites). Néanmoins, des imprécisions de la mesure du temps peuvent se produire résultant du décalage entre les horloges des satellites (très précises) et les horloges des récepteurs (moins précises). Un quatrième satellite est donc nécessaire afin d’assurer la robustesse de la mesure. Le GPS permet une localisation approximative (à quelques mètres près). En robotique, une méthode différentielle est utilisée pour obtenir des résultats plus précis. La localisation se fait alors à l’aide de deux récepteurs dont l’un est statique et positionné avec précision dans l’environnement. La précision devient alors meilleure. L’utilisation du GPS impose la navigation à l’extérieur en raison de la présence de satellites. Les applications de robotique sont implémentées en fonction des capteurs qu’elles utilisent. La variabilité des capteurs rend ces applications fragiles aux changements du matériel. D’un point de vue conceptuel, séparer l’acquisition des données du traitement de celles-ci est une étape importante pour assurer la pérennité et la consistence des applications de robotique. 3.2 La variabilité des effecteurs Un robot agit sur son environnement à travers ses effecteurs. Dans la littérature, un effecteur (appelé aussi actionneur), à l’opposé d’un capteur, convertit un signal électrique en une énergie non électrique ou un phénomène physique [22]. Par exemple, un moteur convertit un signal en une action mécanique. L’étude détaillée des effecteurs, qui relève à la fois de la cinématique, de la mécanique et l’électronique ne sera pas présentée ici. Nous nous intéresserons dans cette section aux mouvements des robots mobiles. Les robots mobiles sont généralement équipés par des roues. Chaque roue contribue au mouvement du robot et impose des contraintes sur le mouvement de celui-ci. Par conséquent, les contraintes définies sur les roues combinent les contraintes définies sur chaque roue individuelle [8]. Les mouvements des robots sont traditionnellement classés en deux catégories : les robots holonomes et les robots non-holonomes [23]. 11Chapitre I. La variabilité dans le domaine de la robotique Les robots de type holonomes n’ont pas de restriction sur le déplacement contrairement aux robots de type non-holonomes qui possèdent des contraintes cinématiques sur leurs mouvements. Lorsque le contact entre le robot et le sol est ponctuel et que les roues sont indéfomables, celà se traduit mathématiquement par une vitesse nulle entre le sol et la roue. Il s’agit de contraintes de roue sans glissement. Ces contraintes sont des contraintes non holonomes. L’existence de contraintes non-holonomes implique que le robot ne peut pas effectuer certains mouvements instantanément, il doit manoeuvrer. Les robots mobiles à roues sont typiquement des systèmes nonholonomes. Cette contrainte représente aussi une variabilité car la vitesse de rotation ou d’avancement des effecteurs diffère non seulement selon l’environnement dans lequel se trouve le robot mais aussi selon le chemin que ce dernier doit suivre. De même que pour les capteurs, les applications de robotique sont généralement écrites en fonction des effecteurs du robot. Par conséquent, un découplage du code de l’application des détails des effecteurs du robot rendrait les applications résistantes aux changements des robots plus généralement et des effecteurs plus particulièrement. 3.3 La variabilité dans les architectures de robotique Le but de choisir une architecture de robotique est de rendre la programmation d’un robot plus facile, plus flexible et plus sûre [24]. Les architectures de robotique permettent de définir la façon dont le robot doit agir de façon à satisfaire le but de sa mission. Dans cette section, nous présentons les différentes architectures définies dans la littérature. 3.3.1 Les architectures délibératives Les architectures de robotique ont apparu à la fin des années 60 avec le paradigme hiérarchique (sense-plan-act) [18] (perception - planification - action) : le robot pense d’abord puis agit. La perception dans ce cas consiste à la traduction des informations sensorielles et cognitives en un modèle du monde [18, 25, 26]. À partir de ce modèle, le planificateur détermine quelles sont les actions à effectuer et renvoie les commandes à exécuter aux effecteurs. Le schéma de cette architecture est donné par la figure I.1. Parmi les architectures hiérarchiques/délibératives, 12I.3 La variabilité dans le domaine de la robotique nous citons NASREM (The NASA Standard Reference Model for Telerobot Control System) [27] développée par la NASA au milieu des années 80. Figure I.1 – Architecture verticale - paradigme hiérarchique (adaptée de [1]) L’architecture délibérative a été adoptée dans les applications de robotique jusqu’au milieu des années 80 lorsqu’il a été constaté que le processus de planification est un processus complexe et non adapté à un environnement dynamique. En effet, le robot reste bloqué jusqu’à la réception des directives du module de planification. De plus, l’exécution d’un plan sans la prise en compte des changements qui peuvent surgir dans l’environnement rend cette architecture non adaptée à un environnement dynamique. C’est pour cette raison que les architectures réactives ont ensuite été définies afin de répondre aux situations où le robot doit agir rapidement. 3.3.2 Les architectures réactives À l’opposé du paradigme Sense-Plan-Act, les architectures réactives s’appuient sur le paradigme réactif Sense-Act (Perception - Action) : le robot ne pense pas mais agit. Un système réactif associe étroitement la perception à l’action sans l’utilisation de représentations abstraites ou d’historique du temps [1]. Le robot ne se base plus sur le modèle de son monde mais uniquement sur des collections de conditions/actions définies à partir des données des capteurs. Cette architecture est adaptée aux environnements où le robot doit agir rapidement, typiquement dans le cas des environnements dynamiques. Les architectures basées sur le comportement ont également été définies pour pallier aux problèmes des paradigmes hiérarchiques. Ces architectures sont souvent confondues avec les architectures réactives dans la littérature, notamment dans [28]. Cette confusion découle de l’utilisation des architectures basées sur le comportement de comportements réactifs dans la plupart des cas (même si la définition d’un comportement est plus sophistiquée que la définition d’une action dans les architectures réactives [29]). Un comportement est défini comme une activité primitive [30] 13Chapitre I. La variabilité dans le domaine de la robotique qui prend en entrée les données des capteurs et retourne une action à effectuer (principe de stimulus/réponse). Il peut être exprimé avec un triplet (S, R, β) où S est le stimulus, R est la réponse et β est le lien S− > R [1]. La définition et l’extraction de ces comportements ont fait l’objet de plusieurs travaux et plusieurs approches ont été définies notamment l’approche éthologique (basée sur l’observation des comportements des animaux) [30, 31], l’approche guidée par les expérimentations (consistant à définir un comportement basique et à ajouter d’autres comportements ou à raffiner les comportements définis) [32] et l’approche dirigée par les buts, etc. Afin d’assember les comportements, plusieurs approches ont été définies dont l’approche compétitive. Dans l’approche compétitive, on distingue 3 approches différentes : – La coordination basée sur la priorité [33] : Le système d’arbitrage sélectionne la réponse envoyée par le comportement ayant la priorité la plus élevée. – La coordination basée sur le vote [34] : Chaque comportement retourne un vote à une réponse et la réponse ayant le plus de votes est exécutée. – La coordination basée sur la sélection des actions [35] : Tous les comportements retournent leurs réponses à l’arbitre qui se charge de sélectionner la réponse majoritaire. Parmi les architectures basées sur le comportement, l’architecture de subsomption(subsumption architecture), proposée par Brooks [30, 32, 33] vers la fin des années 80 est une architecture purement réactive. C’est une architecture incrémentale bottom-up (du bas vers le haut) allant du comportement le plus basique (placé en bas) vers le comportement ayant le degré de compétence le plus élevé (placé en haut). Chaque comportement est modulaire et est représenté par une machine à états finis. L’architecture de subsomption s’appuye sur la notion de parallélisme, elle permet l’exécution simultanée de plusieurs comportements qui interrogent les mêmes capteurs et agissent sur les mêmes effecteurs. Le mécanisme de coordination utilisé est un mécanisme compétitif ayant un système d’arbitrage basé sur la priorité à travers l’inhibition et la suppression comme le montre la figure I.2. Un comportement peut supprimer les sorties d’un autre comportement (cercle avec un S), dans ce cas le comportement dominant remplace les sorties de l’autre comportement par ses propores commandes. Un comportement peut également inhiber (cercle avec un I) les sorties d’un autre comportement en les bloquant. L’architecture de subsomption ne permet pas l’utilisation de comportements indépendants. En effet, il y a une dépendance entre les comportements qui permet de 14I.3 La variabilité dans le domaine de la robotique Figure I.2 – Architecture de subsomption savoir comment les placer dans l’architecture (toujours en suivant un ordre de priorité). Malgré leurs avantages, les architectures basées sur le comportement ne sont pas adaptées à tous les types d’environnements. Il est difficile d’avoir la localisation du robot dans le modèle de son monde et ses connaissances par rapport à son monde sont limitées voire inexistantes [1]. 3.3.3 Les architectures hybrides L’architecture hybride a ensuite été définie afin de combiner les meilleurs aspects de l’architecture délibérative et de celle basée sur le comportement en utilisant le paradigme Plan, Sense-Act (Plannification, Perception-Action). La plannification est effectuée en une étape, la perception et l’action sont effectuées ensemble. L’architecture hybride comporte un système réactif pour le contrôle de bas niveau et un système délibératif de haut niveau pour la prise de décisions. L’architecture hybride a émergé au début des années 90 avec l’architecture AuRA [36] [37] (Autonomous Robot Architecture). Chaque application de robotique utilise une architecture particulière. Dans certains systèmes existants, il est difficile de comprendre l’architecture utilisée. En effet, l’architecture et l’implémentation spécifique au domaine (à la plateforme, au langage, etc.) sont souvent liées brouillant ainsi le style architectural utilisé [24]. Il est donc important de séparer l’architecture des détails de l’implémentation afin de garantir la modularité des composants architecturaux. 3.4 La variabilité dans les algorithmes de robotique Un autre type de variabilité concerne les algorithmes. Elle est souvent relative aux différentes variantes d’une famille d’algorithmes. Prenons le cas d’une tâche de navigation. La navigation est l’une des capacités les plus importantes des robots 15Chapitre I. La variabilité dans le domaine de la robotique mobiles. Le problème de la navigation consiste principalement à trouver un chemin sans collision pour se déplacer d’un point donné vers un autre point ou tout simplement à explorer un environnement tout en évitant les obstacles présents dans celui-ci. Il existe une grande variété de travaux permettant d’aborder le problème de la navigation. D’une façon générale, on peut distinguer deux types de navigation : – La navigation dans un environnement connu (avec un modèle du monde). Le robot dispose du modèle de son monde et planifie par conséquent les actions à exécuter pour se déplacer dans celui-ci. On retrouve alors le paradigme hié- rarchique ou le paradigme hybride. – La navigation dans un environnement inconnu. Elle consiste à appliquer un ensemble de comportements réactifs dont on estime que l’enchaînement peut permettre au robot d’atteindre son but. Par exemple, le contournement d’obstacle, la poursuite de chemin, etc. La navigation requiert des fonctionnalités que le robot doit être capable d’effectuer notamment, la localisation (qui permet au robot de se positionner dans son environnement s’il dispose du modèle de celui-ci ou par rapport à son but ou à sa position de départ) et l’évitement d’obstacles. Il existe diverses stratégies pour l’évitement d’obstacles. Ces obstacles peuvent être de formes inconnues et placés de façon arbitraire dans l’environnement du robot. Ainsi, même avec un ensemble d’hypothèses très simplifiées comme le cas de la famille Bug [38] (voir section 3.1 - chapitre 5), qui comporte environ vingt variantes, il n’est pas évident de comprendre ces algorithmes ou même de les comparer entre eux afin de décider quel algorithme est le plus efficace dans un environnement donné. Si nous pouvions utiliser une seule implémentation d’un algorithme, la comparaison entre les variantes de cet algorithme devient simple et significative. 4 Conclusion Nous avons présenté dans ce chapitre les principaux concepts de la robotique. Nous avons vu également les différents types de variabilité en robotique. Cette variabilité a un impact sur les applications de robotique les rendant ainsi – difficiles à développer car le roboticien doit maîtriser les détails des capteurs, des effecteurs et de la tâche qu’il doit développer. 16I.4 Conclusion – fragiles car elles sont dépendantes des détails de bas niveau du matériel donc le changement de matériel a un impact important sur le code de l’application. – difficiles à comprendre car elles sont confondues avec les détails d’implé- mentation des plateformes sous lesquelles elles sont développées. Nous verrons dans le chapitre suivant comment certains middleware ont tenté de pallier la dépendance des applications de robotique au matériel en proposant des abstractions du matériel. 17Chapitre I. La variabilité dans le domaine de la robotique 18Les middleware de robotique 1 Introduction Nous avons présenté dans le chapitre précédent la variabilité dans les concepts qui composent une application de robotique. Cette variabilité, notamment la variabilité du matériel, a orienté la conception de certains middleware de robotique pour (1) simplifier le processus de développement de ces applications (2) rendre ces applications indépendantes des détails du matériel (3) assurer la connexion entre les différents modules d’une application distribuée. Bakken [39] définit un middleware comme étant : “[...] une classe de technologies logicielles conçues pour aider à la gestion de la complexité et l’hétérogénéïté dans les systèmes distribués [...] Il fournit des abstractions de plus haut niveau que les APIs (Application Programming Interfaces) comme les sockets (fournies par le système d’exploitation)”. Des études détaillées qui présentent les middleware de robotique, leurs architectures ainsi que leurs propriétés peuvent être trouvées dans [21, 40, 41]. Dans ce chapitre, nous ne présenterons pas l’aspect communication des middleware mais nous nous intéresserons particulièrement à l’abstraction du matériel dans les middlewares de robotique pour la gestion de la variabilité de bas niveau. Nous présentons la description de certains des middlewares les plus utilisés en robotique : Player [13, 42], ROS [10, 43], MIRO [11] et PyRo [12, 44] ainsi que les abstractions du matériel qu’ils proposent et une discussion sur l’impact du changement du matériel illustrée sur un exemple d’évitement d’obstacles. 19Chapitre II. Les middleware de robotique 2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel Selon [21, 41], idéalement les middleware de robotique devraient permettre la communication et l’interopérabilité des modules robotiques. Ces derniers étant implantés par des développeurs différents, il est difficile de les faire interagir entre eux. Un middleware doit donc supporter l’intégration des composants et des dispositifs de bas niveau du robot, assurer une utilisation efficace des ressources disponibles et supporter l’intégration avec les autres systèmes. Comme nous l’avons mentionné précédemment, les aspects qui relèvent de la communication et des systèmes distribués ne font pas l’objet de ce travail. Nous nous intéressons essentiellement à la gestion de la variabilité du matériel. Certains middleware de robotique ont défini des données abstraites afin d’encapsuler les détails spécifiques au matériel utilisé. Dans cette section, nous présentons pour chaque middleware sa description, les abstractions du matériel proposées dans celui-ci ainsi qu’une discussion qui montre l’impact du changement du matériel sur un exemple d’évitement d’obstacles. 2.1 Player 2.1.1 Description Le but de Player [13, 42] consiste à permettre l’exécution des mêmes applications aussi bien en simulation que sur des robots réels. Il fournit un framework de développement supportant différents périphériques matériels 1 , des services communs requis pas les applications robotiques et transfère un contrôleur de la simulation à des robots réels avec le minimum d’effort possible [21]. Un programme client communique avec Player, qui s’exécute sur le robot, à l’aide d’une connexion de socket TCP pour le transfert de données. Player contient trois modèles : – Le modèle dispositif (Character device). Les character devices sont des dispositifs qui fournissent et consomment des flots de données au fil du temps. C’est typiquement le cas des capteurs et des effecteurs. L’interface Character device définit des opérations (open, close, read, write, etc.) pour l’accès et le contrôle des capteurs et des effecteurs. 1. http://playerstage.sourceforge.net/doc/Player-2.1.0/player/supported_ hardware.html 20II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel – Le modèle Interface/Pilote (Interface/Driver ) : Le modèle interface/driver regroupe les dispositifs selon des fonctionnalités logiques de façon à ce que les dispositifs capables d’effectuer la même fonctionnalité apparaissent d’une fa- çon similaire à l’utilisateur. – Le modèle Client/serveur : Player supporte plusieurs connexions clientes aux dispositifs, créant ainsi des nouvelles possibilités pour la perception et le contrôle collaboratif. 2.1.2 Les abstractions du matériel dans Player Les abstractions du matériel résident dans le modèle Interface/Driver. L’interface est une spécification du contenu des flots de données. Elle fournit un ensemble de messages communs à une certaine classe de dispositifs indépendamment de la plateforme utilisée. Le code qui implémente l’interface et qui convertit le format natif des commandes de l’API de communication en commandes requises par l’interface et inversement est appelé driver. Le modèle Character device relie les flots en entrée du programme aux données des capteurs et les flots de sortie aux commandes des effecteurs. Les drivers sont spéci- fiques aux dispositifs ou à une famille de dispositifs d’un même “vendeur”. Player sépare les fonctionnalités logiques des détails d’implémentation des dispositifs. On peut dire alors que Interface correspond à la notion de classe abstraite regroupant l’ensemble des fonctionnalités d’un type spécifique de capteurs ou d’actionneurs et que Driver est une classe concrète. /* Request and change the device ’s configuration . */ typedef struct player_ranger_config { double min_angle ; /** Start angle of scans [ rad ]. May be unfilled . */ double max_angle ; /** End angle of scans [ rad ]. May be unfilled . */ double angular_res ; /** Scan resolution [ rad ]. May be unfilled . */ double min_range ; /** Minimum range [m ]. */ double max_range ; /** Maximum range [m ]. May be unfilled . */ double range_res ; /** Range resolution [m ]. May be unfilled . */ double frequency ; /** Scanning frequency [ Hz ]. May be unfilled . */ } player_ranger_config_t ; /* The ranger device position , orientation and size . */ typedef struct player_ranger_geom { player_pose3d_t pose ; /** Device centre pose in robot CS [m , m , m , rad , rad , rad ]. */ player_bbox3d_t size ; /** Size of the device [m , m , m ]. */ uint32_t element_poses_count ; /** Number of individual elements that make up the device . */ player_pose3d_t * element_poses ; /** Pose of each individual element that makes up the device ( in device CS ). */ uint32_t element_sizes_count ; /** Number of individual elements that make up the device . */ player_bbox3d_t * element_sizes ; /** Size of each individual element that makes up the device . */ } player_ranger_geom_t ; Listing II.1 – Extrait de l’Interface RangeSensor de Player 21Chapitre II. Les middleware de robotique L’interface Ranger (voir le listing II.1) fournit une API commune aux capteurs de distance. Les attributs min_angle, max_angle, angular_res, min_range, max_angle, range_res et frequency de la structure player_ranger_config permettent de configurer un capteur de distance donné. La structure player_ranger_geom permet de spécifier la géométrie du capteur à configurer. Dans ce qui suit, nous discuterons l’impact du changement du capteur de distance dans un algorithme d’évitement d’obstacles écrit avec Player. 2.1.3 Discussion Le listing II.2 est un exemple d’algorithme d’évitement d’obstacles founi avec Player et programmé en C++ avec un capteur Sonar. Dans cet exemple, le robot avance dans son environnement. Si sa distance par rapport à l’obstacle le plus proche est inférieure à really_min_front_dist (lignes 9-13) il fait demi-tour sinon si cette distance est inférieure à min_front_dist (lignes 14-17), il s’arrête (ligne 27). Supposons maintenant que l’on veuille remplacer dans cet exemple le capteur Sonar par un capteur Laser. Il faudrait remplacer SonarProxy par LaserProxy et décomposer ensuite les rayons contenus dans l’angle de perception du capteur Laser (si leur nombre le permet) en 5 sous-ensembles afin de regrouper les rayons du capteur Laser et les traiter comme les rayons du Sonar. Cela éviterait de modifier le code. 1 PlayerClient robot ( gHostname , gPort ); 2 Position2dProxy pp (& robot , gIndex ); 3 SonarProxy sp (& robot , gIndex ); 4 pp . SetMotorEnable ( true ); 5 double newspeed = 0.0 f , newturnrate = 0.0 f; 6 for (;;) { 7 robot . Read (); 8 avoid = 0; newspeed = 0.200; 9 if ( avoid == 0) { 10 if (( sp [2] < really_min_front_dist ) || ( sp [3] < really_min_front_dist ) || 11 ( sp [4] < really_min_front_dist ) || ( sp [5] < really_min_front_dist )){ 12 avoid = 50; newspeed = -0.100; 13 } 14 else if (( sp [2] < min_front_dist ) || ( sp [3] < min_front_dist ) || 15 ( sp [4] < min_front_dist ) || ( sp [5] < min_front_dist )){ 16 newspeed = 0; avoid = 50; 17 } 18 } 19 if ( avoid > 0){ 20 if (( sp [0] + sp [1]) < ( sp [6] + sp [7])) 21 newturnrate = dtor ( -30); 22 else 23 newturnrate = dtor (30); 24 avoid - -; 25 } 26 else 27 newturnrate = 0; 28 pp . SetSpeed (2 * newspeed , newturnrate ); 29 } Listing II.2 – Evitement d’obstacle avec Sonar 22II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel Cependant cette nouvelle décomposition dépendra de la position des capteurs sur le robot, du nombre de rayons du Laser, etc. Par conséquent, le remplacement d’un capteur par un autre impliquerait une modification du code existant car celui-ci reste écrit en fonction des données de bas niveau du Sonar. En effet, les abstractions de Player sont fournies pour certaines plateformes de robotique mais elles restent de bas niveau [45] : c’est encore au système de contrôle du robot d’interpréter les nombres retournés par les capteurs et envoyés aux effecteurs. Il faudrait encapsuler ces détails de bas niveau afin de séparer les responsabilités liées au traitement des données de celles liées à leur acquisition ou à leur exécution. Cela permettrait de faciliter le développement des applications et de pouvoir gérer les changements éventuels de matériel dans l’application. 2.2 Robot Operating System (ROS) 2.2.1 Description L’un des middlewares les plus communément utilisé dans la communauté robotique de nos jours est ROS [10, 43]. Il supporte l’intégration de modules logiciels indépendants distribués, appelés noeuds (ROS nodes). ROS fournit un ensemble d’outils qui permettent de packager et de déployer (à travers les notions de package et de stack) les applications de robotique. Il fournit également un nombre important de librairies qui implémentent des drivers de capteurs (par exemple : Hokuyo Scanning range finder, Sharp IR range finder, etc) permettant ainsi d’encapsuler les données spécifiques et de fournir certaines fonctionnalités pour les robots (par exemple ROS navigation stack). Les noeuds ROS sont des blocks de code et sont implémentés dans des classes C++ ou Python. Un système ROS est un graphe composé d’un ensemble de noeuds qui communiquent entre eux à travers des messages. Ces messages sont échangés avec le mécanisme Publish/Subscribe de manière asynchrone à travers un bus de communication appelé ROS-Topic [46]. Chaque topic est typpé par le type du message ROS publié dessus. La figure II.3 montre le mécanisme de communication entre 2 noeuds. En dépit de ses nombreux avantages, ROS ne gère pas l’aspect temps-réel, il délègue cet aspect à des middlewares tiers comme OROCOS [47]. Les Topics ROS permettent la communication entre ces 2 middleware. 23Chapitre II. Les middleware de robotique Figure II.3 – Communication entre les noeuds ROS 2.2.2 Les abstractions du matériel dans ROS Les messages ROS [48] sont des structures de données comportant des attributs typpés. L’une des bibliothèques des messages ROS, appelée sensor_msgs, est dé- diée aux capteurs communément utilisés. Ces messages regroupent les propriétés définies pour chaque type de capteurs. Nous citons par exemple les messages sensor_msgs/LaserScan pour les capteurs Laser, les messages sensor_msgs/CameraInfo pour les caméras, les messages sensor_msgs/Range pour les capteurs Infrarouge, etc. En utilisant ces messages, le code de l’application ne dépend pas d’un modèle de capteurs particulier ayant une configuration particulière mais dépend uniquement du type du capteur. Le tableau II.2 montre les deux messages sensor_msgs/LaserScan et sensor_msgs/Range qui sont des capteurs de distance à rayons dont les propriétés diffèrent. Pour le message LaserScan, le header signifie le temps d’acquisition du premier rayon Laser alors que pour le Range, le header signifie le temps d’acquisition de la distance du rayon Infrarouge. Pour le message LaserScan, il est important de spécifier les attributs angles min et max de début et de fin du scan ainsi que l’attribut angle_increment qui indique la distance angulaire entre les mesures. Pour le message Range, il faut spécifier l’attribut filed_of_view qui représente la taille de l’arc où la distance est valide. Ensuite, dans les deux messages, on peut spécifier min_range et max_range qui définissent les valeurs minimales et maximales qui peuvent être perçues. 2.2.3 Discussion Afin de tester les abstractions proposées par ROS, nous avons programmé un code très simple d’un composant d’évitement d’obstacles sous OROCOS qui est un framework temps-réel à base de composants C++ [47] que nous détaillerons dans la section 5. Cet exemple a été développé en fonction d’un capteur Laser en utilisant 24II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel Sensor_msgs/LaserScan.msg Sensor_msgs/Range.msg Header header Header header float32 angle_min uint8 ULTRASOUND=0 float32 angle_max uint8 INFRARED=1 float32 angle_increment uint8 radiation_type float32 time_increment float32 field_of_view float32 scan_time float32 min_range float32 range_min float32 max_range float32 range_max float32 range float32[] ranges float32[] intensities Table II.2 – Exemple de sensor messages de ROS le topic ROS Sensor_msg : :LaserScan. Le principe est simple, si les capteurs droits du robot détectent un obstacle, le robot tourne à gauche. Si les capteurs gauches du robot détectent un obstacle, le robot tourne à droite et s’il n’y a pas d’obstacle le robot avance. Maintenant supposons que l’on veuille réutiliser ce code pour un robot disposant de 2 capteurs Infrarouges. Il faut alors adapter le code pour récupérer les informations des 2 capteurs infrarouges et faire le même traitement de données. Le listing II.3 montre les 2 codes avec Laser et Infrarouge. Le code en gris est le code qui n’a pas été modifié. Le code en bleu représente le code à modifier pour le composant écrit en fonction du capteur Laser et le code en rouge est le code qui a été modifié pour tenir compte des capteurs Infrarouges. L’impact du changement au niveau d’un composant n’est pas très important car l’exemple que nous avons pris est très simple. Imaginons maintenant une application comportant plusieurs composants qui intéragissent entre eux. Il faudrait alors faire des modifications au sein des composants et au niveau des composants avec lesquels ils intéragissent. Ces abstractions sont alors de bas niveau. Il faudrait définir des abstractions qui soient plus indépendantes des caractéristiques du matériel utilisé. 2.3 Middleware for Robots (MIRO) 2.3.1 Description Le but de MIRO est de fournir un framework général pour le développement des applications de robotique [11]. Ce but a été défini après le développement de plusieurs applications sous différentes plateformes de robotique, avec différents langages de programmation et pour différents robots mobiles lorsque les développeurs 25Chapitre II. Les middleware de robotique Capteur Laser Capteurs Infrarouge #include #include #include #include //include Orocos libraries //include Orocos libraries using namespace std ; using namespace std ; using namespace RTT ; using namespace RTT ; class AvoidObstaclesWithLaserScanRobot : class AvoidObstaclesWithIR : public RTT : :TaskContext{ public RTT : :TaskContext{ private : private : InputPortinport ; InputPortinport_infrared_left ; InputPortinport_infrared_rightt ; OutputPort OutputPort public : public : AvoidObstaclesWithLaserScanRobot AvoidObstaclesWithIRRobot (const std : :string& name) : (const std : :string& name) : TaskContext(name), TaskContext(name), inport("laser_in"), inport_infrared_left("infrared_left_in"), inport_infrared_right("infrared_right_in"), outport("twist_out") { outport("twist_out") { ports()->addPort(inport) ; ports()->addPort(inport_infrared_left) ; ports()->addPort(inport_infrared_right) ; ports()->addPort(outport) ; ports()->addPort(outport) ; } } AvoidObstaclesWithLaserScanRobot() {} AvoidObstaclesWithIRRobot() {} } ; } ; private : private : void updateHook() { void updateHook() { sensor_msgs : :LaserScan msg ; sensor_msgs : :Range msg_infrared_left ; sensor_msgs : :Range msg_infrared_right ; geometry_msgs : :Twist cmd ; geometry_msgs : :Twist cmd ; double midA, midB ; double ir_left = -1.0, ir_right = -1.0 ; if (NewData == inport.read(msg)) { if (NewData == inport_infrared_left.read(msg_infrared_left)) ir_left = msg_infrared_left.range ; if(NewData == inport_infrared_right.read(msg_infrared_right)) ir_right = msg_infrared_right.range ; bool halt = false ; bool halt = false ; for (int i = msg.angle_min ; i <= msg.angle_max ; i++) { if ( ((ir_left > msg_infrared_left.min_range) if(msg.ranges[i] < msg.range_max) { && (ir_left < msg_infrared_left.max_range)) || ((ir_right > msg_infrared_right.min_range) && (ir_right < msg_infrared_right.max_range)) ) { halt = true ; halt = true ; break ; } } } if (halt) { if (halt) { midA = std : :accumulate(msg.ranges.begin(),msg.ranges.end()-45, 0) ; midB = std : :accumulate(msg.ranges.begin()+45,msg.ranges.end(), 0) ; if (midA > midB){ cmd.angular.z = -1 ; } if(ir_left > ir_right) { cmd.angular.z = -1 ; } else { cmd.angular.z = 1 ; } else { cmd.angular.z = 1 ; } } } else { else { cmd.linear.x = 1 ; cmd.linear.x = 1 ; outport.write(cmd) ;} outport.write(cmd) ; } } } } ORO_CREATE_COMPONENT(AvoidObstaclesWithLaserScanRobot) ORO_CREATE_COMPONENT(AvoidObstaclesWithIR) Table II.3 – à gauche le code écrit en fonction du capteur Laser, à droite le code après sa modification avec les Infrarouges ont réalisé l’importance de la définition d’un framework général pour éviter de réimplémenter les mêmes applications si on change de robot. MIRO a été conçu et implé- menté en utilisant l’approche orientée objet ainsi que l’architecture du middleware CORBA (Common Object Request Broker Architecture) [49] qui permet d’assurer la communication entre les différents modules du robot et entre plusieurs robots. L’architecture de MIRO est composée de trois couches : – Une couche dispositif (device layer). – Une couche service (service layer). – La classe framework MIRO (MIRO framework class) qui fournit un ensemble 26II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel de modules fonctionnels fréquemment utilisés en robotique comme la localisation, la plannification de chemin, etc. 2.3.2 Les abstractions du matériel dans MIRO Le framework MIRO contient trois couches dont deux qui permettent d’abstraire le matériel utilisé. La couche dispositif encapsule les messages de communication de bas niveau (liés au bus de communication, etc.) dans des appels de méthodes pour l’invocation des services demandés. Cette couche fournit une interface pour les capteurs et les actionneurs d’un robot. Ces derniers sont définis comme des objets qui peuvent être interrogés et controlés par leurs méthodes. La couche dispositif est dépendante des détails des robots et de la plateforme. La couche service fournit des abstractions de services pour les capteurs et les actionneurs à travers l’interface de définition CORBA (CORBA Interface Description Language : IDL) et implémente ensuite ces services d’une manière indépendante des plateformes. L’interface RangeSensor_IDL définie dans le langage IDL permet d’abstraire les données de Laser et de l’infrarouge II.3. 1 interface RangeSensor 2 { 3 /** 4 * The specific sensor is either masked out or didn ’t provide usefull data . 5 */ 6 const long INVALID_RANGE = -2; 7 /** 8 * The scan value is bigger than the maximum distance the range 9 * sensor can measure . 10 */ 11 const long HORIZON_RANGE = -1; 12 //! The range sensor does not send events 13 const long NONE_PUSHING = 0; 14 //! The range sensor sends a full scan with its events ( @ref RangeScanEventIDL ). 15 const long FULL = 1; 16 //! The range sensor sends one sensor group scan with its events ( @ref RangeGroupEventIDL ). 17 const long GROUPWISE = 2; 18 //! The range sensor sends a bunch of sensor readings with its events ( @ref RangeBunchEventIDL ). 19 const long BUNCHWISE = 3; 20 //! Query the layout of a range sensor type . 21 ScanDescriptionIDL getScanDescription (); 22 //! Query a range sensor group . 23 RangeGroupEventIDL getGroup ( in unsigned long id ) raises ( EOutOfBounds ); 24 //! Wait and query a range sensor group . 25 RangeGroupEventIDL getWaitGroup ( in unsigned long id ) raises ( EOutOfBounds , ETimeOut ); 26 //! Query a range sensor . 27 RangeScanEventIDL getFullScan (); 28 //! Wait and query a range sensor . 29 RangeScanEventIDL getWaitFullScan () raises ( ETimeOut ); 30 }; Listing II.3 – Interface RangeSensor_IDL de MIRO 27Chapitre II. Les middleware de robotique 2.3.3 Discussion Le listing II.4 montre un exemple présenté dans les travaux de Krüger et al. [50] programmé en Python en utilisant les interfaces fournies par MIRO. Dans cet exemple, le robot est équipé par des capteurs sonar. Il avance jusqu’à ce que l’obstacle le plus proche détecté soit plus proche que 3000 millimètres, dans ce cas il s’arrête. 1 import pyMiro 2 sonar = pyMiro . getSonar () 3 loko = pyMiro . getMotion () 4 while (1): 5 scan = sonar . getFullScan () 6 front_scan = scan . range [0] 7 if min ( front_scan ) <3000: 8 loko . limp () 9 else : 10 loko . setLRVelocity (50 ,50) Listing II.4 – Evitement d’obstacle avec les abstractions de MIRO L’abstraction getFullScan() (ligne 5) est définie dans l’interface RangeSensor présentée dans la section précédente. L’abstraction limp() est définie dans une interface appelée Motion afin d’abstraire les mouvements des effecteurs, elle représente un arrêt passif (c.-à-d. le robot ne s’arrête pas complètement). Le retour d’expérience de Krüger et al. dans [50] sur l’utilisation de MIRO montre qu’on peut intégrer des nouveaux capteurs à MIRO en implémentant les interfaces fournies mais n’évoque pas le changement de capteur dans les applications existantes. Supposons maintenant que l’on veuille réutiliser ce même code mais avec un capteur Laser. On peut remplacer getSonar() (ligne 2) par getLaser(), scan.rang[0] (ligne 6) par l’identifiant du rayon Laser placé à l’avant du robot et le code fonctionnerait. Cependant, il faut tenir compte de la portée du rayon Laser, de sa position s’il est placé à gauche du centre du robot par exemple, etc. On peut dire que les abstractions de MIRO permettent une intégration de nouveaux capteurs en supposant qu’il remplit toutes les hypothèses sur les besoins du code. Cette intégration implique l’adaptation du code existant et donc des changements qui peuvent être assez importants. En revanche, il faudrait modifier les paramètres spécifiques à la portée du capteur par exemple. Typiquement dans ce cas, 3000 mm est la distance à partir de laquelle le robot doit s’arrêter. Si la portée du nouveau capteur est inférieure à 3000 millimètres, il faut modifier ce paramètre. Plus les tests sont importants, plus les paramètres à modifier le seront aussi. Ces changements ont un impact sur la visibilité du code car les détails de bas niveau seront confondus avec les détails d’implémentation et ceux 28II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel de l’algorithme. Si on prend maintenant un autre exemple où on voudrait utiliser des capteurs tactiles, il faut réécrire tout le code et implémenter les abstractions d’une nouvelle interface. Il faudrait alors encapsuler toutes les données de bas niveau à travers des abstractions de plus haut niveau sous forme de requêtes sur l’environnement par exemple. 2.4 Python Robotics (PyRo) 2.4.1 Description PyRo [12, 44] est un environnement de développement de robotique en Python qui permet aux étudiants et aux chercheurs d’explorer différents thèmes en robotique indépendamment des robots utilisés. Il a été intégré à plusieurs cours académiques car il offre un support simple pour les étudiants pour le développement des applications de robotique. Le but de PyRo est de faciliter le développement des applications de robotique et d’assurer leur portabilité, sans la modification du code, à travers des abstractions de haut niveau qui encapsulent les détails de bas niveau. PyRo est composé d’un ensemble de classes Python qui encapsulent les détails de bas niveau. Les utilisateurs programment leurs applications en utilisant une API. Cette dernière est implémentée avec une hiérarchie orientée objet offrant ainsi une couche d’abstraction. 2.4.2 Les abstractions du matériel dans PyRo Les abstractions du matériel définies dans PyRo sont les suivantes : – Range sensors : Indépendamment du capteur utilisé, cette interface définit des abstractions pour les capteurs Laser, Infratouge et Sonar. – Robot units : L’unité de la distance retournée par les capteurs peut être en mètres ou en millimètres ou simplement une valeur numérique où les grandes valeurs indiquent un espace libre et les petites valeurs indiquent la présence d’un obstacle proche. Robot unit est une nouvelle unité de mesure qui unifie toutes les autres. – Sensor groups regroupe les capteurs selon leur emplacement. L’utilisateur n’aura plus à se soucier du nombre de capteur disponibles mais utilisera sim- 29Chapitre II. Les middleware de robotique plement des abstractions du type : front, frontleft, left, etc. comme le montre la figure II.4. Les abstractions proposées sont les suivantes : front-all pour tous les capteurs avant du robot, front pour les capteurs placés à l’avant du robot, front-left pour les capteurs à l’avant gauche, front-right pour les capteurs placés à l’avant droit du robot. De la même façon, les abstractions back, back-right et back-left sont définies par rapport à l’arrière du robot. Figure II.4 – Le regroupement des capteurs dans PyRO – Motion control : définit des abstractions pour les commandes des effecteurs : move(translate, rotate) et motors(leftpower, rightpower) – Devices : Permet d’introduire des nouveaux dispositifs qui n’ont pas encore été pris en charge. 2.4.3 Discussion PyRo propose des abstractions pour le matériel sous forme d’actions de plus haut niveau que les commandes spécifiques envoyées au robot et de regroupement de capteurs selon leurs positions. Prenons maintenant un exemple défini en fonction de ces abstractions (voir listing II.5). Cet exemple représente une tâche d’évitement d’obstacle très simple, si un obstacle est rencontré à gauche le robot tourne à droite, si un obstacle est rencontré à droite le robot tourne à gauche et s’il n’y a pas d’obstacle, le robot avance. 1 # i f a p p r o ac h ing an o b s t a c l e on t h e l e f t s i d e 2 # t u rn r i g h t 3 # e l s e i f a p p r o ac h ing an o b s t a c l e on t h e r i g h t s i d e 4 # t u rn l e f t 30II.3 Conclusion 5 # e l s e go f o rw a r d 6 from pyro . b r ai n import Brain 7 c l a s s Avoid ( Brain ) : 8 def s t e p ( s e l f ) : 9 s a f e Di s t a n c e = 1 # in Robot Un i t s 10 # i f a p p r o ac h ing an o b s t a c l e on t h e l e f t s i d e , t u rn r i g h t 11 i f min ( s e l f . g e t ( ’ r o b o t / r an ge / f r o n t −l e f t / v al u e ’ ) ) < s a f e Di s t a n c e : 12 s e l f . r o b o t . move ( 0 , −0. 3 ) 13 #e l s e i f a p p r o ac h ing an o b s t a c l e on t h e r i g h t s i d e , t u rn l e f t 14 e l i f min ( s e l f . g e t ( ’ r o b o t / r an ge / f r o n t −r i g h t / v al u e ’ ) ) < s a f e Di s t a n c e : 15 s e l f . r o b o t . move ( 0 , 0 . 3 ) 16 #e l s e go f o rw a r d 17 e l s e : 18 r o b o t . move ( 0 . 5 , 0 ) Listing II.5 – Evitement d’obstacle programmé avec PyRo extrait de [12] Le code présenté est très simple grâce aux abstractions proposées, il nécessite des connaissances sur la vitesse du robot (ligne 13), son angle de rotation (ligne 10) et sur les valeurs retournées par les capteurs. La fonction min (lignes 6 et 9) est une fonction Python permettant de retourner le minimum des valeurs lues à partir des capteurs. Ce code peut être utilisé pour tout robot équipé de capteurs à rayons avant gauche et avant droit. Supposons maintenant que l’on veuille réutiliser ce même code mais avec des capteurs tactiles, il faut modifier alors les conditions sur les valeurs des capteurs et sur leurs positions. Par conséquent, bien que ces abstractions soient de plus haut niveau que les capteurs en permettant de les regrouper et de ne pas se soucier du nombre de rayons, elles restent insuffisantes. En effet, elles ne permettent pas de fournir des informations de haut niveau sur l’environnement car elles sont spécifiques à la position des capteurs et ne font que des regroupements de ces derniers. Il faudrait définir des abstractions de plus haut niveau afin de garantir une indépendance par rapport à la position des capteurs en fournissant des informations sur l’environnement du robot. 3 Conclusion Une étude complète des middleware de robotique existants est présentée dans [21] montrant les particularités de chaque middleware et les avantages de son utili- 31Chapitre II. Les middleware de robotique sation. Dans ce chapitre, nous avons présenté certains des middleware de robotique qui traitent l’aspect abstraction du matériel. Nous avons vu que ces abstractions sont insuffisantes car elles restent de bas niveau et n’isolent pas bien de certains changements sur les capteurs. En effet, le traitement des données des capteurs reste confondu avec les détails d’implantation de l’application. Ces abstractions ne permettent pas d’encapsuler les détails de bas niveau et de faciliter le développement des applications de robotique. De plus, les middleware ne traitent pas les aspects qui concernent la variabilité algorithmique. Afin de faciliter le développement de ces applications, il faudrait permettre aux roboticiens de manipuler des concepts qu’ils ont l’habitude d’utiliser pour le développement de leurs applications. Ces concepts peuvent être des concepts de haut niveau du domaine comme ceux proposés par les DSML (langage de modélisation spécifiques au domaine). Cependant, les concepts proposés par les DSML manquent souvent de sémantique opérationnelle. Il faudrait alors définir des abstractions de haut niveau qui permettent d’obtenir des informations sur l’environnement du robot et de définir des actions de haut niveau d’une part et d’encapsuler les détails algorithmiques d’autre part. ne sont autres que les concepts du domaine. Les techniques de l’ingénierie dirigiée par les modèles ont été appliquées dans ce contexte afin de définir ce qui est appelé les DSML (langage de modélisation spécifique). Dans le chapitre suivant, nous présentons les différentes phases de création d’un DSML. Nous présenterons ensuite les DSML pour la robotique existants. 32Langages de modélisations spécifiques à la robotique 1 Introduction La définition des applications de robotique est souvent considérée comme un processus complexe car ceci requiert une expertise du domaine (matériel utilisé, tâche à programmer, etc.) ainsi qu’une expertise en développement (plateforme, architecture, etc.). Nous avons présenté dans le premier chapitre la variabilité dans la robotique mobile. Les middleware ont essayé de pallier le problème de la variabilité du matériel en introduisant des abstractions qui restent toutefois de bas niveau comme nous l’avons vu dans le chapitre précédent. D’autre part, chaque middleware s’appuie sur un protocole de communication qui lui est propre ou qui s’appuie sur le standard CORBA. Par conséquent, un problème de portabilité d’un middleware vers un autre a été constaté en plus de la difficulté de faire interopérer les applications entre elles. L’une des priorités pour la communauté robotique consiste alors à définir des abstractions communes pour garantir l’indépendance des applications des middleware, assurer leur portabilité et ainsi optimiser le processus de développement. Afin de répondre à cet objectif, il faudrait tout d’abord réduire le fossé sémantique entre les développeurs et les roboticiens en utilisant un langage commun compré- hensible par les roboticiens d’un côté et par les développeurs d’un autre côté. Ce langage commun est appelé langage spécifique à un domaine ou langage dédié (DSL : domain specific language), il doit répondre au besoin de définir des spécialisations du domaine étudié [51]. Les langages de modélisation spécifiques au domaine (DSML : Domain Specific Mo- 33Chapitre III. Langages de modélisations spécifiques à la robotique deling Language) sont des DSL basés sur les modèles qui visent à définir des abstractions de haut niveau et à accélérer le processus du développement à travers l’utilisation des modèles. Ils permettent une meilleure compréhension des systèmes représentés ainsi qu’une accessibilité au développement des applications pour les roboticiens à travers des notations appropriées du domaine. Dans ce chapitre, nous commençons par une présentation générale des DSML et des techniques d’ingénierie dirigée pas les modèles. Nous présentons ensuite le cycle de vie d’un DSML puis les DSML existants pour la robotique. 2 Langages de Modélisation Spécifiques aux domaines (DSML) Un DSL est un langage de programmation ou un langage de spécification qui offre, à travers des notations appropriées et des abstractions, une puissance expressive axée sur, et généralement limitée à, un domaine particulier [14]. Les DSL sont souvent des langages déclaratifs, ils peuvent par conséquent être considérés comme des langages de spécification aussi bien que des langages de programmation [14]. Le développement d’un DSL requiert une expertise du domaine auquel il est dédié ainsi qu’une expertise en développement des langages [52]. L’un des objectifs principaux d’un DSL consiste à réduire l’ambiguïté de la terminologie et le fossé sémantique entre les experts du domaine d’application et les développeurs et ainsi convenir d’un ensemble d’abstractions communes pour un domaine particulier. Par conséquent, les experts du domaine doivent être mis au centre du développement du DSL [53]. Idéalement, un DSL apporterait plusieurs avantages aux développeurs ainsi qu’aux experts du domaine auquel il est dédié. Plusieurs travaux soulignent ces avantages, notamment Kieburtz et al. [54] qui ont réalisé une comparaison entre deux approches dans le cadre d’une étude empirique. La première consistait au développement d’une application en utilisant un ensemble de templates fournissant des fonctionnalités et des types génériques et la deuxième était l’utilisation d’un générateur de templates à partir d’un DSL. Ils ont constaté que l’utilisation de la deuxième approche améliorait considérablement la productivité des développeurs, la fiabilité de l’application et garantissait une facilité d’utilisation offrant ainsi un outil de réflexion et de communication ([55], page 41) aussi bien pour les développeurs que pour les ex- 34III.2 Langages de Modélisation Spécifiques aux domaines (DSML) perts du domaine. Grâce à cette facilité d’utilisation, les experts du domaine peuvent comprendre les programmes définis avec le DSL, les modifier et même les développer eux-même [14]. D’après Van Deursen [56], l’utilisation des DSLs renforcerait également la maintenance des applications et assurerait leur portabilité. Idéalement, un DSL devrait être réutilisable [57] dans le sens où l’on peut réutiliser les connaissances capitalisées du domaine afin de définir plusieurs programmes différents. Cette réutilisabilité découle également de l’indépendance des DSL des plateformes cibles ([55], page 43) car lors de la conception d’un DSL, une séparation des reponsabilités est réalisée entre les notations du domaine et les détails d’implémentations liés aux plateformes. En dépit de tous ces avantages, les DSLs présentent certaines limites comme par exemple, un coût non négligeable de conception, d’implémentation et d’apprentissage pour leur utilisation [14]. Un DSL bien défini apporterait alors des solutions aux limites constatées. Les DSL sont souvent définis comme des langages de modélisation spécifiques au domaine (DSML) qui incluent une infrastructure pour des transformations automatiques à partir de modèles vers un code source et des artefacts [2]. Les techniques de l’ingénierie dirigée par les modèles permettent la conception des DSML. Dans la section suivante nous présentons ces techniques. 2.1 Les techniques d’ingénierie dirigée par les modèles L’Ingénierie Dirigée par les Modèles (IDM) ou Model Driven Engineering (MDE) [15] répond au besoin de définir des abstractions du domaine en plaçant les modèles au centre du développement logiciel. Un modèle est une représentation simplifiée d’un système destiné à améliorer notre capacité à comprendre, prévoir et éventuellement contrôler le comportement de ce système [58]. Nous pouvons dire, par exemple, qu’une carte géographique est un modèle. L’interprétation de cette carte diffère d’une personne à une autre en l’absence de légende. Nous devons donc définir une légende standard pour cette carte afin de pouvoir l’interpréter de manière unique. C’est de cette même façon que nous pouvons définir le lien entre les modèles et les méta-modèles. Un méta-modéle (niveau M2 de la figure III.5) est un langage dont l’interprétation est unique car il définit les concepts d’un domaine particulier et il est lui-même conforme à un méta-méta- 35Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.5 – Les différents niveaux de modélisation modèle (MOF : Meta Object Facility) (niveau M3 de la figure III.5). Les modèles (niveau M1 de la figure III.5), instances du méta-modèle, respectent donc les notations du domaine et contiennent une combinaison particulière de ses concepts. L’OMG (Object Management Group) est un consortium d’industriels et de chercheurs dont l’objectif est d’établir des standards permettant de résoudre les problèmes d’interopérabilité des systèmes d’infomation [59]. L’architecture proposée par l’OMG pour les différents niveaux de modélisation est présentée dans la figure III.5. La MDE est une généralisation de l’approche MDA (Model Driven Architecture), proposée et soutenue par l’OMG. La MDA applique la séparation des préoccupations qui consiste à élaborer des modèles métier (indépendants des détails techniques des plateformes) et des modèles spécifiques aux plateformes (pour la partie technique d’une plateforme). L’avantage le plus important qu’offre MDA est la pérennité des modèles indépendants des plateformes grâce à la modélisation des spécifications mé- tier. Dans ce qui suit nous présentons les différents niveaux de modélisation en MDA et les transformations entre ces modèles ainsi que les outils dédiés à la modélisation et aux transformations. 2.1.1 Les niveaux de modélisation Trois niveaux de modélisation interviennent en MDA : – Les Modèles Indépendants des Plateformes (PIM : Platform Independent Model). Ces modèles sont proches des contraintes et des considérations des experts du domaine et permettent de représenter la structure et les opérations 36III.2 Langages de Modélisation Spécifiques aux domaines (DSML) du système et ce, d’un point de vue indépendant des plateformes. – Les Modèle Spécifiques aux Plateformes (PSM : Platform Specific Model). Ces modèles résultent d’une association du PIM aux détails techniques d’une plateforme donnée. À partir du PSM le code vers la plateforme cible est généré. – Les Modèles de Description des Plateformes (PDM : Platform Description Model). Ces modèles permettent de spécifier la façon dont les fonctionnalités de la plateforme sont implémentées. Ils spécifient également comment ces fonctionnalités sont utilisées. Un PIM est conforme à un méta-modèle indépendant des plateformes et un PSM est conforme à un méta-modèle représentant les concepts d’une plateforme spéci- fique. Nous allons maintenant présenter les différents outils permettant de réaliser les différents niveaux de modélisation notamment les méta-modèles et les modèles. 2.1.1.1 Outils Le projet de modélisation d’Eclipse (EMP) [60] offre une multitude d’outils dédiés au développement dirigé par les modèles. Une partie de l’EMP comprend EMF (Eclipse Modeling Framework) qui permet la définition de métamodèles sous forme de fichiers Ecore. Une instance d’un méta-modèle est un modèle défini sous forme de fichier XMI. Papyrus [61] est un outil d’édition graphique de modèles, basé sur l’environnement Eclipse EMF, pour UML2 [62]. Conformément à son objectif principal, il met en œuvre la spécification standard complète de UML2 notamment les diagrammes de structure (c.-à-d. diagramme de classe, diagramme de déploiement, etc.), les diagrammes de comportement (c.-à-d. le diagramme d’activités, diagramme de machine à états) et les diagrammes d’intéraction (c.-à-d. diagramme de séquence, etc.). Papyrus est également conforme au standard graphique DI (Diagram Interchange) qui permet d’échanger les données graphiques. Papyrus fournit aussi un support large pour les profils UML [63]. Ces derniers permettent d’étendre UML afin de l’adapter à plusieurs domaines d’applications. Dans le cadre du projet PROTEUS, nous avons utilisé Papyrus afin de définir un éditeur graphique permettant de modéliser des scénarios de robotique en utilisant les concepts du domaine. Afin d’avoir une application exécutable vers une plateforme cible à partir des diffé- rents modèles présentés précédemment, des transformations sont définies pour transformer les modèles en code exécutable. Nous les présentons dans la section suivante. 37Chapitre III. Langages de modélisations spécifiques à la robotique 2.1.2 Les transformations MDA passe par la transformation respective de ses modèles afin d’obtenir une application exécutable à partir de ces derniers. Ces transformations sont effectuées : – du PIM vers le PSM (de modèle vers modèle) : pour établir les liens entre les concepts généraux et les concepts spécifiques aux plateformes ; – du PSM vers du code (de modèle vers texte) : pour obtenir du code exécutable correspondant au modèle spécifique à la plateforme d’exécution. Théoriquement, il faudrait que le PDM intervienne dans les transformations de PIM vers PSM pour spécifier les fonctionnalités relatives à la plateforme utilisée. Cependant, pour la définition des transformations, il faudrait au préalable définir des méta-modèles du PIM, du PDM et du PSM. La définition des méta-modèles du PIM et du PSM ne pose pas de problème particulier. En revanche, le méta-modèle du PDM n’est actuellement pas réalisable car il devrait permettre de construire des modèles de toutes les plateformes et vu que ces dernières sont différentes, il n’existe pas de nos jours de solution à ce problème. Les transformations existantes se résument alors à des transformations du PIM vers le PSM (de modèle vers modèle) et du PSM vers le code (de modèle vers texte). Plusieurs outils sont proposés pour réaliser ces transformations. Nous les présentons dans la section suivante. 2.1.2.1 Outils Les outils disponibles aujourd’hui basés sur les techniques d’ingénierie dirigée par les modèles permettent de construire des méta-modèles, des modèles et leurs équivalents en XMI (XML Metadata Interchange) [64] ou en UML facilement manipulables par les outils de génération de code assurant ainsi la géné- ration de code vers multiples et diverses plateformes cibles. Une plateforme cible est une plateforme constituée de ressources logicielles et matérielles servant de support d’exécution à l’application générée. Nous soulignons la différence entre un outil de génération de code et un générateur de code. Un outil de génération de code est un compilateur qui permet de définir des règles de transformations entre le DSL et la plateforme cible tandis qu’un générateur de code est un programme qui établit des règles de transformations entre le DSL et la plateforme cible. Le générateur de code est implémenté avec un outil de génération de code. Il existe plusieurs outils de génération de code, certains de modèle vers modèle 38III.3 Cycle de vie d’un DSML comme Epsilon [65], Kermeta [66] et d’autres, de modèle vers texte, comme Acceleo [67] et TOM-EMF [68]. Acceleo permet de définir des transformations de Modèle vers Texte (approche MDA) et supporte les standards de modélisation comme UML, XMI, etc.. La syntaxe mise en oeuvre par Acceleo se base sur des templates qui contiennent des informations tirées sur les modèles en entrée (à travers des requêtes) et leur associent le code à générer à travers des conditions et des boucles. Dans le cadre de cette thèse et du projet ANR PROTEUS, nous utiliserons Acceleo comme outil de génération de code. Dans la section suivante, nous présentons les différentes étapes de conception d’un DSML. 3 Cycle de vie d’un DSML Avant de concevoir un DSML, plusieurs questions doivent être soulevées : – Par qui sera conçu le DSML ? – Pour qui sera conçu le DSML ? – Quels sont les concepts du domaine qui doivent être représentés et comment les représenter ? Ces questions permettent d’orienter les choix de conception d’un DSML afin de ré- duire le coût en terme de maintenance et de développement et garantir ainsi des solutions aux problèmes existants. La création d’un DSML est un processus itératif. Un DSML se base souvent sur une compréhension limitée et simple du domaine, puis évolue progressivement avec l’intervention des experts du domaine. Nous pouvons distinguer sans ambiguïté quatre phases qui déterminent le cycle de vie d’un DSL. Tout d’abord, une phase d’analyse du domaine afin d’identifier les abstractions appropriées. Une abstraction est un concept. Ce concept fait partie du domaine modélisé et représente une entité abstraite ou concrète dans ce domaine [69]. L’analyse du domaine est succédée d’une phase de conception afin de représenter ces abstractions puis d’une phase d’intégration des plateformes. La dernière phase est enfin l’utilisation du DSL [14]. 39Chapitre III. Langages de modélisations spécifiques à la robotique 3.1 Analyse du domaine Les deux premières questions présentées précédemment doivent être traitées dans la phase de l’analyse du domaine. L’étape de l’analyse du domaine consiste à rassembler les connaissances du domaine et à les regrouper en notions sémantiques et en opérations. La modélisation des domaines, désignée par l’ingénierie des domaines (Domain engineering) [70], est un aspect de l’ingénierie logicielle introduit afin de pallier les problèmes de réutilisabilité. L’ingénierie des domaines peut être utilisée afin de construire des librairies réutilisables pour les DSLs [14]. Selon l’utilisateur final de l’application, l’identification des concepts du domaine peut varier. Prenons par exemple le cas de la robotique mobile. Pour un expert en robotique, les concepts relevant du contrôle, de la communication, de la perception, de l’action et de l’environnment réel du robot ou de la simulation définissent les concepts de base de la robotique mobile. Un développeur, quant à lui, traitera les aspects techniques liés à la programmation et à l’architecture logicielle des plateformes de robotique (langages à base de composants, langages orientés objets, etc.). La délimitation du domaine est un processus qui pourrait être conflictuel s’il n’est pas clairement défini. Simos et al. [71] ont distingué deux catégories d’utilisation du domaine : – Le domaine comme étant un “monde réel” : Ceci désigne le domaine du monde où le travail final va être réalisé. On retrouve cette vision du domaine en intelligence artificielle, en génie cognitif ou encore en programmation orientée objet (OO). L’analyse du domaine en OO traduit souvent l’analyse du domaine en une description orientée-objet des entités et des transactions dans le monde réel. Cette description forme une base pour l’implantation d’un système qui supporte ces activités du monde réel. En d’autres termes, cette théorie se base souvent sur le principe que les experts d’un domaine ne prêtent pas beaucoup d’importance à l’aspect logiciel d’une application. – Le domaine comme étant un “ensemble de systèmes” : Cette définition du domaine se base sur la théorie de l’analyse du domaine orientée par la réutilisabilité. Par opposition au domaine en tant que monde réel, les systèmes sont eux même l’objet de l’étude du domaine dans cette catégorie. Le domaine est défini comme une famille ou un ensemble de systèmes incluant des fonctionnalités communes dans un domaine particulier. La modélisation des similarités 40III.3 Cycle de vie d’un DSML et des variabilités à travers les systèmes existants dans le domaine est la base de cette définition du domaine. Dans certains cas, les concepts d’un DSL en général et d’un DSML en particulier peuvent être extraits à partir d’un système existant et les abstractions du domaine peuvent être dérivées directement à partir de ce système existant. Si l’architecture du système existant est documentée en utilisant un langage de modélisation graphique par exemple, cette architecture peut être une source valuable pour l’obtention des abstractions du domaine [2]. Parmi les approches de modélisation des domaines, nous citons l’analyse de domaine orientée par les features (FODA : Feature Oriented Domain Analysis) [72] et les ontologies [73]. 3.1.1 Les ontologies L’ontologie est une approche de modélisation des domaines qui vise à fournir une compréhension des éléments d’un domaine particulier. Elle permet de représenter des bases de connaissances qui offrent un contenu sémantique réutilisable et accessible depuis diverses applications. Elle définit des concepts ainsi que leur signification et les relations entre eux pour représenter un domaine de connaissances. Une ontologie doit être exprimée suivant une syntaxe donnée, associée à une interprétation donnée. Le langage OWL (Ontology Web Language) est l’un des langages qui permettent de représenter les ontologies. Nous le présentons dans ce qui suit. 3.1.1.1 Le langage OWL (Ontology Web Language) Le langage OWL est un langage pour la représentation des ontologies Web. Il est compatible avec le Web sémantique ce qui permet aux utilisateurs de donner une définition formelle aux termes qu’ils créent. Ainsi les machines peuvent raisonner sur ces termes. La terminologie de OWL se base essentiellement sur espaces de nommages (namespace), les classes et les propriétés. Un namespace est un conteneur qui fournit le contexte du contenu d’un fichier OWL. Une classe encapsule la signification d’un concept. Des hiérarchies de classes peuvent être créées en déclarant qu’une classe peut être une sous-classe (subClassOf) d’une autre classe. Une propriété décrit une association entre les classes. Une hiérarchie de propriétés peut également être créée en précisant qu’une propriété est une sous propriété d’une autre propriété (Property :IsA). Une composition générique des pro- 41Chapitre III. Langages de modélisations spécifiques à la robotique priétés est exprimée avec le mode clé Property :hasA, cela veut dire qu’une propriété peut s’appliquer à d’autres propriétés. Dans le cadre du projet ANR PROTEUS qui a défini le contexte de cette thèse, nous nous baserons sur une ontologie existante du domaine de la robotique mobile, développée dans le cadre de ce projet, afin d’extraire les abstractions du domaine appropriées pour notre DSML : RobotML. L’ontologie de RobotML sera présentée dans la section 3 du chapitre 5. 3.2 Conception des DSML Dans cette section, nous tentons de répondre à la troisième question sur l’extraction des abstractions pertinentes du domaine et leur représentation. La conception d’un DSML doit permettre une définition non ambigûe d’abstractions de haut niveau représentant les concepts identifiés à partir de l’analyse du domaine. Ces abstractions doivent être indépendants des détails des plateformes (middleware) et doivent représenter les concepts du domaine. La conception d’un DSL passe par deux étapes importantes qui sont la définition de la syntaxe abstraite et la définition de la syntaxe concrète ([55], p.175). À ces deux étapes peut s’ajouter la définition de la sémantique de la syntaxe abstraite. Dans cette section nous présentons ces différentes étapes. 3.2.1 Définition de la syntaxe abstraite La syntaxe abstraite d’un DSML peut être définie de deux façons principales qui peuvent être complémentaires. La première façon consiste à définir le modèle du domaine sous forme d’un méta-modèle représentant les abstractions du domaine et les relations entre elles. La deuxième façon consiste à étendre les concepts d’UML sous forme d’un profil afin de les adapter aux abstractions identifiées dans le métamodèle. Dans cette section nous présentons donc le modèle de domaine en tant que méta-modèle ainsi que les profils UML. 3.2.1.1 Modèle du domaine : Méta-modèle La syntaxe abstraite appelée aussi modèle du domaine regroupe les concepts du domaine cible du DSL, leurs propriétés et les relations entre eux dans un modèle du domaine. Le modèle du domaine formalise les connaissances du domaine et doit être validé par les experts du domaine. Les éléments du DSL peuvent aussi avoir une sémantique. La définition de cette 42III.3 Cycle de vie d’un DSML dernière n’est pas une étape indispensable pour la conception d’un DSL. La sémantique peut être statique ou dynamique. Dans le premier cas, elle permet de définir la sémantique qui ne peut pas être exprimée directement au niveau du modèle du domaine comme par exemple les éléments invariants et les relation entre eux. Quant à la sémantique dynamique, elle permet de définir les effets comportementaux ré- sultant de l’utilisation des éléments du DSL. Elle définit également la façon dont les éléments du DSL doivent intéragir à l’exécution. Le comportement peut être exprimé de différentes façons allant de modèles de flots de contrôle de haut niveau en passant par des modèles de comportements plus détaillés jusqu’à une spécification textuelle précise. Dans le cas des DSML, le modèle du domaine est défini comme un PIM qui représente les concepts du domaine. Des modèles spécifiques aux plateformes peuvent aussi être définis afin de représenter les concepts des plateformes cibles du DSML. Ces modèles, si définis, interviendront dans l’étape intégration des plateformes des DSML. 3.2.1.2 Profil UML Un profil étend les concepts d’UML afin de les adapter à un domaine d’application. L’extension d’UML à travers les profils passe par trois concepts principaux [63] : – Stereotype : Un stéréotype étend une méta-classe existante du méta-modèle UML pour en changer la sémantique. Un stéréotype peut posséder des propriétés (tagged value) et être sujet à des contraintes. Un stéréotype est une extension limitée d’une méta-classe, on ne peut pas définir un stéréotype sans définir le lien vers la méta-classe qu’il étend. UML permet egalement d’associer à chaque stéréotype sa propre notation sous forme d’une icône et/ou un cadre (shape) pour le distinguer graphiquement du concept qu’il étend. – Tagged Value : Ce sont des propriétés des stéréotypes qui offrent un moyen de spécifier les caractéristiques du concept UML étendu. Une propriété a un type qui appartient impérativement à UML sinon il doit être défini et annexé au profil. – Constraint On peut définir des contraintes sur le méta-modèle UML afin de le spécialiser. Ces contraintes sont définies avec le langage OCL (Object Constraint Language). Le profil UML sert de support pour la définition d’un éditeur graphique qui va utiliser les différentes icônes associées aux stéréotypes par exemple. Il est également possible 43Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.6 – Les artefacts du DSL - extrait de [2] de vérifier les contraintes sur l’association et la composition des différents éléments proposés à travers cet éditeur et de valider ainsi les modèles réalisés. Dans la section suivante, nous précisions en quoi consiste la définition de la syntaxe concrète d’un DSML. 3.2.2 Définition de la syntaxe concrète La syntaxe concrète est une interface à travers laquelle sont représentées les abstractions définies dans la syntaxe abstraite [2]. Chaque DSL peut avoir plusieurs syntaxes concrètes : graphique et textuelle. Pour un DSML, la syntaxe concrète est présentée sous forme graphique. Elle est représentée à travers des outils permettant à l’utilisateur de créer des modèles qui représentent une combinaison particulière des éléments de la syntaxe abstraite. La définition de la syntaxe concrète est une étape importante du point de vue de l’utilisateur final du DSML. La figure III.6 résume les différents artefacts intervenant dans la conception d’un DSL. Un DSL correspond à un domaine, il possède une syntaxe abstraite qui peut avoir une sémantique statique ou (et) dynamique (que nous ne détaillerons pas car nous ne traitons pas ces parties dans cette thèse). Un DSL a une ou plusieurs syntaxes concrètes qui correspondent à cette syntaxe abstraite. Dans le cadre du projet PROTEUS, Papyrus a été utilisé pour la définition de la syntaxe concrète de notre DSML. Un fois que le modèle du domaine et la syntaxe concrète sont définis, il faut 44III.3 Cycle de vie d’un DSML Figure III.7 – Intégration des plateformes - basé sur [2] définir des règles de transformations qui permettront de faire le lien entre le modèle du domaine et les concepts des plateformes cibles. 3.3 Intégration des plateformes : Transformations et Géné- ration de code Comme nous l’avons indiqué précédemment, l’intégration des plateformes vient compléter la phase de conception en faisant le lien entre les concepts du domaine et les concepts des plateformes. Cette phase est aussi appelée phase d’implémentation ; elle consiste à mettre en place un compilateur qui traduit les programmes du DSL en une séquence d’appels de librairies [14]. Des transformations sont définies pour transformer les modèles définis à l’aide de la syntaxe concrète du DSML vers d’autres modèles ou vers un langage de programmation (correspondant à une plateforme cible) comme le montre la figure III.7. Il existe alors deux types de transformations : – De modèle vers modèle : elles consistent à convertir un modèle en un autre modèle du même système. – De modèle vers texte : elles consistent à convertir un modèle en code qui lui correspond. 45Chapitre III. Langages de modélisations spécifiques à la robotique 3.4 Utilisation L’étape d’utilisation consiste à représenter les programmes souhaités par l’utilisateur final et à les compiler [14]. Dans notre cas, cette étape consiste à modéliser le système souhaité et à générer le code correspondant. Le code doit être compilable et exécutable sur la ou les plateformes cibles. L’utilisation d’un DSL ne se restreint pas seulement à la modélisation et la génération de code. On peut faire également des analyses sur les modèles pour valider les fonctionnalités du système dès les premières phases de conception. 4 Les DSML pour la robotique Dans cette section, nous présentons tout d’abord les exigences que doivent respecter les DSML pour la robotique, nous présenterons ensuite les travaux qui ont adopté les techniques d’ingénierie dirigée par les modèles comme solution aux problèmes constatés dans le développement des applications de robotique et nous conclurons par une synthèse de ces travaux. 4.1 Exigences des langages de domaine pour la robotique En plus des caractéristiques des DSL présentées précédemment, idéalement un DSL pour la robotique respecterait les caractéristiques suivantes [74]. 1. Facilité d’utilisation. L’utilisation du DSL devrait être non seulement à la portée des experts en programmation mais aussi à la portée des experts en robotique et idéalement à la portée de simples utilisateurs de logiciels de robotique. 2. Spécification d’une architecture à base de composants. En supposant que la majorité des plateformes de robotique sont actuellement basées sur une architecture à base de composants, le DSL devrait permettre la spécification d’architectures à base de composants de systèmes de robotique autonomes. 3. Spécification des comportements des composants. Le DSL doit permettre la spécification des différents types de contrôle des composants. Il devrait être possible d’exprimer le contrôle sous forme algorithmique ou sous forme de machine à états finis. 46III.4 Les DSML pour la robotique 4. Neutralité vis à vis des architectures de robotique. Le DSL ne devrait pas imposer une architecture de robotique particulière : délibérative, hybride, réactive ou basée sur le comportement (voir section 3.3). 5. Plusieurs plateformes cibles hétérogènes. Les composants de l’application devraient être indépendants des plateformes cibles et devraient pouvoir s’exécuter sur des robots réels ou des simulateurs. De plus, il devrait être possible de déployer certains composants générés à partir du DSL sur une plateforme et les autres composants sur une autre plateforme. 6. Indépendance vis à vis des plateformes cibles. Même si l’indépendance par rapport aux plateformes cibles est difficile à réaliser, le DSL devrait être aussi indépendant que possible des spécificités des platesformes d’exécution. 7. Prise en charge de l’évolution des plateformes La génération de code doit être aussi agile que possible de façon à ce que si les plateformes cibles évoluent, l’impact de leur évolution n’affecte pas énormèment le code des générateurs. De plus, idéalement, si des nouvelles plateformes sont ajoutées, elles pourraient réutiliser les transformations déjà définies. 8. Evolution du DSL. Idéalement, il devrait être possible de changer au moins certains aspects du DSL sans avoir à construire une nouvelle implémentation. L’évolution du DSL peut faire partie du processus du développement. En effet, si le processus de développement du DSL est itératif, les concepts du domaine sont adaptés ou renommés selon les besoins des plateformes et des applications. Une autre façon de gérer l’évolution des DSL consisterait de partir d’exemples concrets pour la définition des concepts du DSL, la génération de code, etc. De cette façon, le DSL conçu permettra le développement de ces applications. 9. Abstractions du matériel Idéalement, le DSL offrirait un ensemble d’abstractions du matériel sous forme de librairies afin de rendre les modèles définis indépendants du matériel du robot en plus d’être indépendant des plateformes. 4.2 Travaux existants De nos jours, ils n’existe pas énormément de travaux qui mettent en oeuvre les techniques de l’ingénierie dirigée par les modèles pour la conception des DSLs pour la robotique. Certains travaux, notamment [75] et [76] ont appliqué ces techniques dans le cadre de l’étude d’un robot particulier ou d’une architecture de robotique 47Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.8 – Les concepts de l’OMG appliqués à l’approche BCM - (tiré de [3]) particulière. Dans cette section, nous nous intéressons aux travaux qui ont défini des DSML en traitant les aspects de la variabilité en robotique (à travers des abstractions) et leur indépendance des plateformes cibles. 4.2.1 BRICS Component Model (BCM) 4.2.1.1 Description BRICS [77] est un projet européen qui vise à structurer et à formaliser le processus de développement des applications robotiques en fournissant des outils, des modèles et des librairies permettant d’accélérer le processus de développement. BRICS s’appuie sur les techniques d’ingénierie dirigée par les modèles afin de fournir un modèle appelé BCM (BRICS Component Model) [3] indépendant des plateformes à partir duquel une génération automatique de code est réalisée vers des plateformes de robotique (voir figure III.8). Le niveau M3 repré- sente le méta-méta-modèle Ecore. Il s’ensuit un méta-modèle minimal et général de composants, indépendant des plateformes, de niveau M2 appelé CPC (Component Port Connector). Au même niveau, des méta-modèles spécifiques aux plateformes ROS et OROCOS sont définis. Au niveau M1, on retrouve des modèles instances 48III.4 Les DSML pour la robotique des méta-modèles du niveau M2. Le méta-modèle CPC est spécialisé par les modèles des plateformes comme ROS et OROCOS. BRIDE [78] est le générateur de code qui assure les transformations de modèle vers modèle (du modèle instance du méta-modèle général vers le modèle instance du méta-modèle spécifique à la plateforme cible) ainsi que des transformations modèle vers texte (du modèle instance du méta-modèle spécifique à la plateforme cible vers la plateforme cible). Le méta-modèle CPC est présenté dans la figure III.9, il spécifie qu’un System peut avoir plusieurs connecteur(s) (méta-classe Connector) et des composants (métaclasse Component). Un composant peut avoir des ports (méta-classe Port), une ou plusieurs propriétés (Property) et des sous-composants. Les abstractions représentées dans ce méta-modèle reflètent l’architecture des plateformes cibles (c.-à-d. une architecture à base de composants) mais ne sont pas représentatives des concepts du domaine. En dehors du BCM, le projet BRICS propose une séparation des pré- occupations entre les composants de différentes natures à travers les 5Cs : – Computation : C’est la fonctionnalité responsable de l’accès aux données en lecture ou en écriture entre les différents composants, de leurs synchronisation et de leurs traitements. – Coordination : Cette fonctionnalité détermine comment les composants d’un système doivent travailler ensemble. Elle détermine le rôle d’un composant dans un système. – Composition : C’est la fonctionnalité qui permet de définir des composants composites. – Communication : Se charge de l’envoi de données aux composants de computation. – Configuration : Cette fonctionnalité permet de configurer les composants de communication et de computation. Cependant, cette architecture n’a pas été intégrée au BCM car les auteurs argumentent que cette distinction n’est pas effectuée au niveau des plateformes cibles. 4.2.1.2 Discussion Le BCM permet une représentation de modèles à bases de composants et une génération automatique de squelettes de code vers ROS et OROCOS. Cependant, les abstractions du domaine ne sont pas représentées et la distinction entre les différentes natures des composants (c.-à-d. contrôle et matériel) 49Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.9 – Le méta-modèle CPC - (tiré de [3]) d’une application de robotique n’a pas été intégrée au BCM. Les aspects comportementaux des composants notamment, les machines à états finis et les algorithmes ne sont pas représentés dans le BCM. De plus, la génération de code est effectuée vers une et une seule plateforme cible à la fois ; la génération de code vers plusieurs plateformes cibles hétérogènes n’est pas supportée. L’évolution du BCM n’est pas envisageable éventuellement pour une intégration des 5Cs car il n’y aurait pas de correspondance avec les plateformes cibles [3]. 4.2.2 Open Robot Controller Computer Aided Design (ORCCAD) 4.2.2.1 Description ORCCAD est un framework pour la spécification de la partie contrôle et commande d’un système de robotique [79, 80] destiné aux applications de robotique temps-réel. Le but d’ORCCAD consiste à fournir un ensemble d’outils qui permettent d’aider l’utilisateur tout au long du processus de conception, de vérification et de développement de son application. Cet ensemble d’outils, appelé CASE (Computer Aided Software Engineering), a été défini en utilisant les outils du projet de modélisation d’Eclipse [60] qui se basent sur les techniques d’ingénierie dirigée par les modèles. L’approche ORCCAD utilise deux niveaux d’abstractions : un niveau fonctionnel et un niveau de contrôle [4]. Le niveau fonctionnel permet de représenter les tâches élémentaires du robot (Robot Task (RT)). Celles-ci sont décrites sous forme de comportements spécifiés dans des fichiers source écrits en ESTEREL [81] (voir figure III.10). Le niveau de contrôle (Robot Procedure (RP)) décrit ensuite la composition 50III.4 Les DSML pour la robotique Figure III.10 – Le méta-modèle RT extrait du méta-modèle d’ORCCAD - (tiré de [4]) hiérarchique des RTs. Les abstractions utilisées sont suffisament de haut niveau pour ne pas être spécifiques à une plateforme particulière et pour représenter les aspects temps-réel requis pour une application de robotique. A partir des modèles réalisés avec l’éditeur graphique d’ORCCAD (instance du méta-modèle dont une partie a été présentée précédemment), le générateur de code fournit du code C++, à partir des RTs et RPs, ainsi que le glue code qui permet de les connecter avec le système d’exploitation utilisé. 4.2.2.2 Discussion Malgré les avantages d’utilisation d’ORCCAD notamment la généricité de ses modèles et leur indépendance des détails des plateformes cibles, ORCCAD ne définit pas des abstractions du matériel et ne prend pas en charge la génération de code vers d’autres plateformes cibles de robotique. L’une des solutions possibles pour assurer la prise en charge de l’hétérogénéïté des plateformes consisterait à mettre en oeuvre un générateur de code à partir du code C++ généré vers d’autres plateformes. De plus, ces middlewares doivent prendre en charge l’aspect temps-réel, il n’est donc pas possible de générer du code vers des middlewares tel que ROS qui ne prend pas en compte cet aspect. 4.2.3 SmartSoft 4.2.3.1 Description SmartSoft [82][83] est un framework qui offre un ensemble de patterns de communication générique qui permettent l’assemblage et la composi- 51Chapitre III. Langages de modélisations spécifiques à la robotique tion des composants grâce à des interfaces structurées et consistantes correspondant à une sémantique bien définie. Ces interfaces sont basées sur des services de communication standard (client/server, master/slave, publish/subscribe, request/response, etc.). Le modèle de composants comporte également un automate générique qui gère le cycle de vie d’un composant [84]. Figure III.11 – Le méta-modèle de SmartSoft - (tiré de [5]) Le modèle de composants SmartSoft et ses mécanismes de communication ont été définis dans un méta-modèle appelé SmartMars (Modeling and Analysis of Robotic Systems) [16]. Les patterns de communication produisent différents modes de communication comme la communication dans une seule direction ou l’intéraction request/response. Par exemple, le pattern send est un mode de communication Client/Serveur dans une seule direction. Le pattern Query est un mode de communication Client/Serveur qui utilise l’intéraction request/response. Ces concepts sont représentés dans le méta-modèle SmartMars à travers les méta-classes QueryPattern, PushNewestPattern, ClientServerPort, MasterSlavePort, et CommunicationObject. Deux types de méta-modèles sont définis dans le méta-modèle SmartMars (voir fi- gure III.11) : un méta-modèle indépendant des plateformes représentant les patterns de communication de SmartSoft ainsi que la structure générale des composants et 52III.4 Les DSML pour la robotique leur cycle de vie et un méta-modèle spécifique aux plateformes permettant de spéci- fier les informations relatives à la plateforme choisie (méta-classes PSM-Connector, PSM-Target et PSM-NS dans la figure III.11). Le méta-modèle SmartMars a été implémenté sous forme de profil UML constituant ainsi une base de développement pour un outil intégré à Eclipse appelé SmartMDSD (Model Driven Software Design). SmartMDSD offre une chaîne d’outillage de la modélisation jusqu’à la génération de code (vers CORBA et ACE). 4.2.3.2 Discussion SmartSoft permet la modélisation à base de composants des applications de robotique indépendamment des plateformes cibles et permet également une spécification claire et concise des concepts de communication entre les différents composants définis. Les patterns de communication exprimés sont stables et ont été utilisés en robotique depuis plus de dix ans. Le méta-modèle de SmartSoft permet aussi de représenter le cycle de vie d’un composant à l’aide d’un automate où les états initialisent le composant, l’exécutent et peuvent indiquer l’échec de son exécution. Cependant, il n’y a pas de disctinction entre la nature des composants utilisés. En d’autres termes, on ne sait pas si ces composants sont matériel ou logiciels. Par conséquent, la prise en charge de plusieurs plateformes cibles hétérogènes n’est pas possible (c.-à-d. si on souhaite générer du code vers un simulateur et un middleware). De plus, les abstractions du domaine ne sont pas suffisantes car il n’est pas possible d’exprimer les abstractions du matériel par exemple. Concernant l’évolution des plateformes cibles et du méta-modèle, ces points n’ont pas été abordés dans les travaux de SmartSoft. 4.2.4 The 3 View Component Meta-Model (V3CMM) 4.2.4.1 Description V3CMM [6] s’appuie sur les concepts de l’OMG afin de fournir un méta-modèle indépendant des plateformes pour la conception des applications de robotique à base de composants. Ses principales caractéristiques sont la simplicité et l’économie des concepts d’un côté et la réutilisabilité des composants de l’autre. V3CMM utilise certains concepts d’UML afin d’offrir trois vues principales : (1) une vue structurelle pour la description de la structure des composants et de la communication entre eux (2) une vue de coordination décrivant le comportement de chaque composant sous forme de machine à états finis (en réutilisant les concepts 53Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.12 – Méta-modèle V3CMM - tiré de [6] d’UML) (3) une vue algorithmique pour la description de l’algorithme de chaque composant selon l’état dans lequel il se trouve (qui reprend une représentation simplifiée du diagramme d’activités d’UML). Un extrait de ce méta-modèle est présenté dans la figure III.12. Une chaîne d’outillage a été développée avec les outils de modélisation d’Eclipse permettant ainsi la génération de code en deux étapes. Tout d’abord des transformations de modèle-vers-modèle sont définies entre un modèle instance du méta-modèle V3CMM et un modèle instance du méta-modèle représentant les concepts de la programmation orientée objets. Puis, à partir du deuxième modèle, des transformations de modèle vers texte sont définies vers le langage ADA. 4.2.4.2 Discussion Il est à noter que même si V3CMM ne contient pas les concepts de la robotique, il a été testé et essentiellement utilisé en robotique et dans le domaine des réseaux de capteurs sans fils [85] et d’autres domaines comme la domotique. Actuellement, V3CMM a été étendu afin de permettre la spécification des contraintes temps-réel. Des éditeurs textuels avec une validation de modèle V3CMM ainsi que plusieurs implémentations vers différents frameworks cibles. Cependant, V3CMM ne fait pas distinction entre les composants matériel et logiciel d’une application. Ainsi, il n’est pas possible de générer du code vers plusieurs pla- 54III.4 Les DSML pour la robotique Figure III.13 – Architecture de Genom3 teformes cibles hétérogènes. De plus, il n’est pas possible d’exprimer les abstractions du matériel de haut niveau. L’évolution du méta-modèle et des plateformes cibles n’a pas été abordée dans les travaux V3CMM. 4.2.5 GenoM3 4.2.5.1 Description GenoM3 [86] a été défini dans le but d’assurer l’indépendance des composants logiciels d’une application des middleware de robotique. L’idée principale consiste à découpler la structure des composants de leurs noyaux algorithmiques. Cette idée a été réalisée en mettant en oeuvre un template par middleware pour la définition des squelettes des composants dans celui-ci. Ce template est organisé sous forme d’un fichier source. En plus de ce template, un DSL textuel a été défini permettant la description des composants et de leurs fonctionnalités, notamment les ports, les types de données, les services, les opérations (définies sous forme de codels [87]) et le contexte d’éxécution (task ou thread), sous forme de spécification formelle (voir figure III.13). Un interpréteur se charge ensuite d’instancier les composants à partir de leurs descriptions conformément au template du middleware choisi. Du code exécutable est alors généré correspondant aux composants décrits. 55Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.14 – Composant RTC 4.2.5.2 Discussion À travers plusieurs études de cas, il a été prouvé que l’indépendance des plateformes est garantie à travers l’utilisation de GenoM3 [88]. Cependant, l’architecture d’une application doit être conforme à la structure des templates définis et la spécification formelle des composants n’est pas au même niveau d’abstraction que les méta-modèles. La transformation sous forme de template de composants ne correspond pas aux meilleures pratiques du développement dirigé par les modèles [16] (MDSD : Model Driven Software Development). De plus, la génération de code vers des plateformes hétérogènes n’est pas prise en charge. De plus l’aspect abstraction des données du matériel n’est pas pris en charge. 4.2.6 Robot Technology Component (RTC) 4.2.6.1 Description OpenRTC [89] a été conçu par l’OMG afin de proposer un standard pour la robotique. Plusieurs plateformes se basent sur le standard RTC et utilisent son modèle de composants comme OpROS [90–92] et RTM [93]. Un RTC est une représentation logique du matériel et/ou d’une entité logicielle qui fournit des fonctionnalités et des services souvent utilisés. RTC étend les fonctionnalités des composants proposés par UML et s’appuie sur les technologies de la MDA pour proposer un modèle indépendant des plateformes exprimé en UML et composé de trois parties : – Lightweight RTC : un modèle basique contenant la définition de concepts simples comme composant et port comme le montre la figure III.14. Il dé- finit des interfaces avec des abstractions et des stéréotypes. – Execution semantics : C’est une extension du modèle basique (Lightweight RTC) qui supporte les patrons de conception critiques de communication utilisés en robotique. 56III.4 Les DSML pour la robotique – Introspection : Une API qui permet d’examiner les composants, leurs ports et leurs connexions à l’exécution. Trois modèles spécifiques aux plateformes (PSM) ont ensuite été définis dans le langage IDL (Interface Definition Language) de l’OMG et ont été proposés afin de spécifier les mécanismes de communication : – Local : indique que les composants communiquent entre eux et qu’ils sont placés dans le même réseau. – Lightweight CCM (Corba Component Model) Les composants sont distribués et communiquent via l’interface CCM-based middleware. – CORBA Les composants sont distribués et communiquent via CORBA. En plus des composants LightWeight RTC, RTC définit trois autres types de composants : – Le traitement des flots de données (Data flow processing/Periodic sampled data processing) : correpond à l’exécution de type périodique. Les composants de type flots de données sont exécutés périodiquement. Un composant de ce type peut aussi être un composant composite contenant d’autre composants de flots de données. De cette façon, le traitement de données peut être décomposé de manière hiérarchique. – Le traitement Stimulus/Réponse appelé également traitement de données asynchrone. Les applications utilisant ce type de composant doivent généralement réagir aux changements qui surgissent dans l’environnement du robot. Le comportement est représenté sous forme de machine à états finis (FSM). Lorsqu’un événement est signalé, la FSM change d’état en exécutant l’action associée à la transition par laquelle elle est passée. – Modes d’opération : fournit un support pour les applications qui doivent naviguer entre différentes implémentations de la même fonctionnalité. 4.2.6.2 Discussion Le modèle de composant RTC est considéré comme une spé- cification avancée proposée par l’OMG dans le domaine de la robotique. Ce modèle a servi de standard pour beaucoup de plateformes de robotique : RTM (Robot Technology Middleware) [93], OPRoS [90], GostaiRTC [94], etc. Cependant, la spécification de RTC est fortement influencée par des architectures qui se basent sur un échange de flots de données. Par conséquent, le modèle de composant RTC est influencé par un automate interne fortement lié à un modèle d’activités à l’intérieur d’un composant. Il ne permet pas la spécification de plusieurs 57Chapitre III. Langages de modélisations spécifiques à la robotique tâches à l’intérieur d’un composant. De plus, les composants de natures différentes ne sont pas distingués, il n’est pas donc pas possible de générer du code vers plusieurs plateformes hétérogènes. L’évolution du DSL et des plateformes cibles n’a pas été abordée pour le modèle RTC. Par ailleurs, les abstractions du matériel ne sont pas prises en charge. 4.3 Synthèse Les DSML existants pour la robotique répondent partiellement aux exigences présentées précédemment comme le montre le tableau III.4. BCM [3], SmartSoft [16], V3CMM [6], GenoM3 [86] et RTC [89] permettent la représentation d’une architecture à base de composants contrairement à ORCCAD [4] qui spécifie plutôt le niveau fonctionnel (Robot Task) et le niveau contrôle (Robot Procedure) d’une application. L’indépendance par rapport aux plateformes cibles a été respectée dans les DSML existants soit à travers des modèles indépendant des plateformes comme le cas de BCM, SmartSoft, V3CMM, ORCCAD et RTC ou à travers des templates comme le cas de GenoM3. Concernant la neutralité vis-à-vis des architectures de robotique elle est également gérée dans les travaux existants vu qu’aucun concept spécifique à une architecture particulière n’est spécifié. En revanche, la génération de code vers plusieurs plateformes cibles hétérogènes (c.-à-d. simulateur et middleware ou plusieurs middleware), la prise en charge de l’évolution des plateformes cibles, l’évolution du DSL ainsi que la représentation des abstractions du matériel ne sont pas actuellement prises en charge dans les travaux existants. 5 Conclusion Dans ce chapitre, nous avons présenté les DSML et leur cycle de vie. Nous avons ensuite étudié les travaux existants mettant en oeuvre les techniques d’ingénierie dirigée par les modèles afin de répondre aux problèmes constatés dans le développement des applications de robotique dûs à la variabilité du matériel, des algorithmes et des middleware et permettre ainsi une facilité d’utilisation, de développement et de réutilisabilité des applications. Nous avons vu que ces travaux ne gèrent pas l’hétérogénéïté des plateformes cibles. La distinction entre les composants matériel et les composants logiciels n’est pas 58III.5 Conclusion effectuée au niveau de la modélisation. De plus, les abstractions du domaine définies sont insuffisantes car elles sont très générales, elles sont souvent basées sur l’architecture des plateformes cibles (architecture à base de composants). SmartSort se distingue par la stabilité des patterns de communication qu’il propose et donc par des abstractions pour la communication basées sur une expertise du domaine. Certes ces DSML traitent le problème de l’indépendance par rapport aux plateformes cibles mais il devrait être possible de manipuler les concepts de robotique tels qu’ils sont utilisés par les roboticiens en fixant tout d’abord une terminologie du domaine définie par des roboticiens. De plus, il devrait être possible de générer du code vers plusieurs plateformes supportant ou non les aspects temps-réels. Dans le chapitre suivant, nous présentons notre DSML pour la robotique : RobotML et les solutions que nous proposons afin de répondre aux exigences présentées dans ce chapitre. 59Chapitre III. Langages de modélisations spécifiques à la robotique Caractéristiques V3CMM [6] SmartSoft [16] ORCCAD [ 4] BCM [3] Ge noM3 [86] RTC [89] Facilité d’utilisation Oui Oui Oui Oui Oui Oui Spécification d’une Oui Oui Non Oui Oui Oui architecture à base de composants Spécification du Oui Non Oui Non Oui Oui comportement des composants Indépendance des Oui Oui Oui Oui Oui Oui plateformes cibles Neutralité vis-à-vis Oui Oui Oui Oui Oui Oui des architectures de robotique Plusieurs plateformes Non Non Non Non Non Non cibles hétérogènes Prise en charge Non Non Non Non Non Non de l’évolution des plateformes Evolution du DSL Non Non Non Non Non Non Abstractions Non Non Non Non Non Non du matériel Table III.4 – Comparaison entre les DSML pour la robotique existants 60Deuxième partie Contributions 61Robotic Modeling Language (RobotML) 1 Introduction Notre étude des travaux existants a montré que les concepts utilisés dans les DSML de robotique actuels sont insuffisants pour représenter tous les aspects d’une application de robotique. D’une part les DSML existants se concentrent sur la repré- sentation de la partie architecturale ou (et) celle de contrôle et de communication d’une application en utilisant des modèles à base de composants généralistes qui ne se basent pas sur des abstractions du domaine. Par conséquent, ces abstractions ne permettent pas la gestion de la variabilité du matériel ou l’expression de données abstraites. De plus les travaux existants ne prennent pas en charge plusieurs plateformes cibles hétérogènes (de natures différentes : simulateurs et middlewares). Afin de faciliter le développement des applications de robotique, il devrait être possible pour un roboticien de pouvoir manipuler des concepts qu’il a l’habitude d’utiliser à travers des modèles et des outils qui leurs sont associés. Ces concepts peuvent être extraits à partir de systèmes existants telles que les ontologies qui représentent des bases de connaissance du domaine. Il devrait aussi être possible d’exprimer le comportement d’un composant à un niveau plus abstrait que le code à travers des automates par exemple. Enfin, les concepts d’un DSML devraient être suffisamment génériques pour prendre en charger plusieurs plateformes cibles hétérogènes. Nous avons ainsi contribué au développement d’un DSML pour la robotique : RobotML qui offre un langage axé sur des abstractions du domaine permettant tout d’abord de réduire le fossé sémantique entre les roboticiens et les développeurs. Ces abstractions sont basées sur une ontologie du domaine définie par des experts de 63Chapitre IV. Robotic Modeling Language (RobotML) robotique. De plus, RobotML offre une chaîne d’outillage allant de la modélisation de scénarios de robotique jusqu’à la génération de code vers plusieurs plateformes cibles hétérogènes facilitant ainsi le développement des applications de robotique. Les composants de différentes natures sont distingués dans RobotML. Par exemple, on distingue les composants matériels des composants de contrôle et des composants de déploiement. RobotML permet : – la spécification de l’architecture d’un système de robotique : composants de contrôle, composants matériel, leurs ports et les types de données qu’ils s’échangent. – la spécification de la communication entre les composants à travers des ports de flots de données ou des ports de service. Il est également possible de préciser le type de communication entre les composants (synchrone ou asynchrone). – la spécification du comportement des composants de l’architecture du système à travers des machines à états ou des algorithmes. – la spécification d’un plan de déploiement qui permet de définir plusieurs plateformes cibles hétérogènes (simulateurs et middleware). RobotML a été développé dans le cadre du projet ANR PROTEUS (Plateforme pour la Robotique Organisant les Transferts Entre Utilisateurs et Scientifiques) [95]. PROTEUS compte quinze partenaires notamment, DASSAULT Aviation [96], ECA [97], CEA [98], GOSTAI [99], Intempora [100], THALES [101], LASMEA [102], TOSA [103], GREYC [104], INRIA [105], ONERA [106], PRISME [107], EFFIDENCE [108], WIFIBOT [109] et enfin le LIP6 [110] au sein duquel cette thèse a été réalisée. Notre contribution dans le cadre du projet PROTEUS a consisté à participation aux différentes phases de développement de RobotML et à la définition des parties contrôle et communication de RobotML. De plus, nous avons défini un générateur de code à partir de RobotML vers le middleware OROCOS. Dans ce chapitre, nous décrivons le cycle de vie de RobotML et sa chaîne d’outillage. Nous présenterons enfin un exemple de scénario défini avec RobotML. 64IV.2 Vue d’ensemble sur le cycle de vie de RobotML 2 Vue d’ensemble sur le cycle de vie de RobotML Comme nous l’avons présenté dans le chapitre 3, le cycle de vie d’un DSML comporte quatre phases : l’analyse du domaine, la conception, l’intégration des plateformes cibles à travers la définition de générateurs de code et enfin l’utilisation. Pour effectuer l’Analyse du domaine, nous nous sommes basés sur un état de l’art sur les middleware, les simulateurs et les DSL existants pour la robotique. Cet état de l’art a permis d’identifier certaines exigences notamment l’indépendance par rapport aux plateformes cibles (middleware et simulateurs) et la représentation d’une architecture à base de composants. Ces dernières, combinées avec les concepts du domaine fournis par une ontologie de la robotique mobile définie dans le cadre du projet PROTEUS, ont permis de délimiter le domaine d’application (c.-à-d. la robotique mobile) et d’extraire de l’ontologie les abstractions dont les roboticiens ont besoin pour la définition de leurs applications. Après cette étape d’analyse du domaine arrive l’étape de Conception où l’on identi- fie la syntaxe abstraite ainsi qu’une syntaxe concrète qui s’articule autour de cette syntaxe abstraite afin de fournir un éditeur graphique permettant de manipuler les concepts du domaine. Plusieurs générateurs de code ont ensuite été implantés afin d’établir des règles de transformations à partir de ces abstractions vers les plateformes cibles. Enfin, la phase d’utilisation de RobotML consiste à tester toute la chaîne d’outillage de la modélisation vers la génération de code. 3 Analyse du domaine L’analyse du domaine pour la définition de notre DSML se base sur une ontologie de la robotique mobile définie dans le cadre du projet PROTEUS [7] ainsi que sur l’état de l’art des simulateurs et des middleware robotique. Une ontologie est une représentation formelle des connaissances décrivant un domaine donné [111]. L’ontologie de PROTEUS a été construite à partir de la connaissance des experts en robotique dans différents sous-domaines. Leur expertise porte sur les domaines suivants : commande, contrôle, perception, navigation, localisation, contrôle du trafic, optimisation, planification et simulation. Afin de partager leurs connaissances, des experts du domaine partenaires du projet PROTEUS, se sont réunis pour décrire des scénarios et pour exprimer leurs connaissances et leurs besoins dans la robotique 65Chapitre IV. Robotic Modeling Language (RobotML) mobile autonome. À partir de ces réunions, les exigences de l’ontologie ont été défi- nies. Ces exigences concernent la modélisation de la mécanique et des composants électroniques ainsi que des architectures de contrôle, les systèmes, les simulateurs, etc. Ces exigences incluent également la modélisation d’un robot donné ainsi que le suivi de son évolution (comportement) pendant l’exécution de son scénario. Comme il faut modéliser le comportement du robot, il est nécessaire de modéliser son environnement et sa mission. L’ontologie a été définie autour du concept System. Ce dernier représente une entité ayant des intéractions, il peut être considéré comme un composant au sens du génie logiciel. Un System est défini comme un bloc qui déclenche des intéractions et est impacté par les intéractions des autres systèmes. Le choix d’une représentation d’une telle architecture a pour but de permettre la définition des composants, de leurs comportements et des différents échanges de données entre eux. Ainsi, le code final généré à partir du DSML (dont les concepts sont extraits de l’ontologie) pourra correspondre aux concepts architecturaux utilisés par les plateformes cibles. L’ontologie de PROTEUS a été décrite avec le langage OWL que nous avons pré- senté dans la section 3.1.1.1 et est organisée de manière modulaire où les modules sont définis comme une spécialisation du module principal (le Kernel). Certains modules permettent de spécifier les classes décrivant les System, leurs ports et leurs caractéristiques. D’autres modules servent à décrire l’environnement du robot, les outils de simulation utilisés pour tester les solutions ou encore les expérimentations (validation, vérification, tests). La figure IV.15 montre la classification des différents systèmes (System) définis par l’ontologie. Comme nous l’avons dit un System est une entité ou une unité logique qui réalise une intéraction, il peut lui même comporter d’autres Systems dans ce cas, il s’agit d’un CompositeSystem. Les PhysicalObject, Software et AtomicSystem sont des Systems. Un PhysicalObject décrit toutes les entités physiques dans un scénario de robotique. Il peut être un Hardware (c.-à-d. horloge, effecteur, un bus de communication ou encore un capteur) sur lequel le Software s’exécute. Un PhysicalObject peut également être un Agent capable d’agir comme les robots (Robot) et les humains (Human). La figure IV.16 montre la relation entre les différentes Systems. Une Interaction est un concept abstrait utilisé pour décrire les intéractions entre les Systems. Elle s’effectue à travers des Ports qui représentent des interfaces pour les entrées/sor- 66IV.3 Analyse du domaine Figure IV.15 – Classification des systèmes dans l’ontologie (extrait de [7]) ties entre les Systems. Un System possède un état et un modèle d’évolution. Un EvolutionModel représente la propriété intrinsèque d’un composant d’évoluer à travers le temps. Deux types spécifiques d’EvolutionModel sont distingués mais ne sont pas représentés dans cette figure : Algorithm et StateMachine. Un Algorithm est une méthode pour la résolution d’un problème sous forme d’une séquence d’instructions. Une machine à états est définie par des transitions, des événements et s’appuie sur des états (State) pour indiquer l’évolution d’un système à travers des états. Les données échangées entre les différents Systems sont représentées dans le module Information (voir figure IV.17). Une Information est directement ou indirectement liée à une intéraction. Le lien direct indique qu’une intéraction transmet des informations. Le lien indirect indique qu’une intéraction possède un protocole qui contient des informations. Une Abstraction est une Information qui n’est pas directement interprétée par la machine. Contrairement aux abstractions, Data est une information directement interprétée par la machine. Une spécification de Data qui n’est pas représentée sur cette figure est PhysicalData ; elle désigne un objet mathématique-algébrique ayant une unité physique associée. 67Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.16 – Intéraction entre les systèmes dans l’ontologie (extrait de [7]) Figure IV.17 – La classe Information dans l’ontologie (extrait de [7]) Les classes de l’ontologie représentant les concepts du domaine peuvent être reprises, modifiées ou supprimées dans le DSML. Par exemple, Interaction permet de définir un lien entre deux Systems mais n’est pas assez explicite. Nous l’avons remplacé dans le modèle du domaine par les concepts Port et Connector pour cap- 68IV.4 Conception de RobotML turer les propriétés d’une intéraction. Le principal avantage de cette démarche est de pouvoir réutiliser les bases de connaissance des experts du domaine pour enrichir le DSML [112]. L’ontologie constitue le point d’entrée du modèle du domaine de RobotML. Dans le projet PROTEUS, le but de la définition de l’ontolgie dépasse la représentation des concepts du domaine. L’une des ambitions de son utilisation consiste à normaliser le domaine de la robotique mobile. Cet objectif n’est pas encore atteint car les abstractions définies dans l’ontologie sont basées sur les connaissances des roboticiens comme nous l’avons présenté précédemment ou sur des descriptions de scénarios qu’ils souhaitent représenter et non pas sur des exemples concrets. On ne sait donc pas comment implanter certaines de ces abstractions. Dans la section suivante nous présentons la conception de RobotML qui se base sur les concepts de l’ontologie pour représenter les abstractions du domaine. 4 Conception de RobotML La conception de RobotML est passée par les étapes suivantes : 1. Extraction des abstractions du domaine à partir de l’ontologie : Les exigences d’un langage de domaine pour la robotique présentées dans la section 4.1 du chapitre 3. sont extraites de l’ontologie d’une part et de l’état de l’art sur les simulateurs et les middleware d’une autre part. 2. Représentation de ces abstractions dans un modèle du domaine sous forme d’un méta-modèle puis dans un profil qui étend les concepts d’UML pour les adapter aux concepts du domaine. 3. Après la vérification et la validation de la syntaxe abstraite, définition de la syntaxe concrète sous forme d’un éditeur graphique basé sur le profil UML. Dans cette section nous présentons toutes ces étapes. 4.1 Syntaxe abstraite Le DSML doit correspondre aux concepts du domaine provenant de l’ontologie. Ceci constitue la première exigence du DSML afin d’utiliser une terminologie défi- nie par les experts du domaine de la robotique. À partir de l’ontolgie, les concepts 69Chapitre IV. Robotic Modeling Language (RobotML) spécifiques aux domaines sont alors extraits. Ces concepts sont filtrés pour n’en retenir que ceux dont on a besoin pour la définition d’une application de robotique : l’architecture (les composants, leurs ports, les types de données), la communication entre les composants ainsi que leurs comportements. La syntaxe abstraite de RobotML a d’abord été représentée dans un modèle du domaine (méta-modèle) puis dans un profil qui étend les concepts d’UML pour les adapter aux concepts du domaine. Les concepts du modèle du domaine ont généralement le même nom que ceux de l’ontologie sauf si ces derniers ne sont pas assez explicites comme le cas du concept Interaction que nous avons remplacé par les concepts Port et Connector. Étant donné que l’on souhaiterait que notre DSML supporte plusieurs plateformes cibles hétérogènes, les concepts du DSML sont également extraits à partir d’un état de l’art sur les simulateurs et les middlewares. Deux stratégies simples sont possibles pour extraire les concepts correspondant à plusieurs plateformes : faire l’union ou l’intersection des concepts de ces plateformes. Autrement il faudrait réaliser un travail considérable de factorisation et de construction de nouvelles abstractions ce qui n’a pas été possible dans Proteus malheureusement. Si nous choisissons l’intersection des concepts identifiés dans les plateformes, on imposerait des restrictions et les concepts de certaines plateformes ne pourraient pas être représentés. Si nous choisissons l’union, nous couvrons les concepts existants et aussi, il sera plus facile de supporter des nouvelles plateformes. Nous avons alors choisi l’union des concepts identifiés dans les plateformes. Cependant, le DSML devient ainsi plus complexe que les plateformes cibles et il est possible que des concepts ne soient pas traduisibles sur certaines plateformes Le tableau IV.5 montre la correspondance entre les concepts utilisés pour définir l’ontologie en OWL (voir section 3.1.1.1 et les concepts d’UML que nous avons utilisés pour représenter notre modèle de domaine. Classe OWL Concepts d’UML Concept Class subClassOf Inheritence Property Association, Attribute Property :IsA Inheritence Property :HasA Composition Cardinality Multiplicity Table IV.5 – Correspondance entre OWL et UML 70IV.4 Conception de RobotML Dans ce qui suit nous présentons notre modèle de domaine ainsi que le profil UML. 4.1.1 Le modèle de domaine RobotML : méta-modèle L’objectif principal de notre DSML consiste à permettre aux roboticiens de manipuler les concepts dont ils ont l’habitude d’utiliser pour la définition de leurs applications. Nous avons distingué trois parties dans notre modèle de domaine : la partie architecture, la partie communication et la partie contrôle. Cette distinction découle des principales parties à définir pour une application de robotique. La figure IV.18 montre une vue globale des principaux packages du modèle du domaine RobotML : Figure IV.18 – RobotML Domain Model – Le package RoboticArchitecture regroupe les concepts architecturaux et structurels qui définissent une application de robotique. Ce package représente la partie Architecture. – Le package RoboticBehavior permet de définir le comportement d’un composant d’une application de robotique à travers une machine à états finis ou des algorithmes. Ce package représente la partie Control. – Le package RoboticCommunications définit la communication entre les composants à travers des ports et des connecteurs. Ce package représente la partie Communication. – Le package Deployment permet de spécifier les propriétés relatives au déploiement des composants en représentant les plateformes cibles (middleware ou 71Chapitre IV. Robotic Modeling Language (RobotML) simultaurs) vers lesquelles le code des composants sera généré. 4.1.1.1 La partie Architecture Cette partie représente les concepts qui permettent de définir l’architecture d’un scénario de robotique sous forme d’un modèle à base de composants ayant des propriétés, des ports et des types. La partie Architecture comporte six packages comme le montre la figure IV.19 : le package RoboticSystem, le package SystemEnvironment, le package DataType, le package RoboticMission, le package Platform et le package Deployment que nous détaillerons dans ce qui suit. Figure IV.19 – RoboticArchitecture Package 1. Le package Robotic System (voir Figure IV.21). La méta-classe System représente un composant ayant une activité (attribut activity) et qui peut être local ou non (attribut native). Cet attribut permet d’indiquer si un composant qui satisfait le même rôle existe déjà localement sur la machine. Les attributs libraryPath et LibraryComponentName sont respectivement le chemin et le nom de ce composant existant qu’on peut associer au composant représenté. Un System a une ou plusieurs propriétés (Property), un ou plusieurs ports (Port) et des connecteurs (Connector) qui permettent de relier les ports entre eux. La méta-classe Property est soit une propriété d’un système dans le sens attribut (méta-classe BasicProperty de la figure IV.20) soit une partie d’un système (méta-classe Part de la figure IV.20). 72IV.4 Conception de RobotML Figure IV.20 – La méta-classe Property La méta-classe Port sera développée dans la partie Communication. Un System a un comportement exprimé à travers la méta-classe Evolution Model que nous détaillerons dans la partie Control. Un RoboticSystem est un System permettant de représenter un composant concret, il a une position et une orientation. La méta-classe SensorSystem représente les capteurs, l’attribut frequency est la fréquence de chargement des données des capteurs. La métaclasse ActuatorSystem représente les effecteurs. Ces deux méta-classes sont spécialisées dans d’autres types de capteurs et d’effecteurs spécifiques que nous ne présenterons pas car nous nous intéressons uniquement aux concepts du DSML et non aux détails spécifiques des capteurs et des effecteurs. Figure IV.21 – Le package RoboticSystem 73Chapitre IV. Robotic Modeling Language (RobotML) 2. Le package SystemEnvironment. Ce package définit les concepts de l’environnement où le robot évolue. Cette représentation permet de définir les environnements de simulation par exemple. 3. Le package DataType. Ce package permet de spécifier les types de données qui vont être utilisés par les ports, les propriétés, etc. (voir figure IV.22). Figure IV.22 – RobotML Data Types Un data type peut être : – une donnée physique Physical Data : Ce type représente une unité mathé- matique associée à un objet physique. Cet object mathématique peut être considéré comme une abstraction d’une donnée physique. On trouve par exemple les types Distance, Angle, Acceleration comme le montre la figure IV.23. La sémantique exacte de ces types est gérée ensuite par l’utilisateur. En effet, au niveau du DSML, ces types n’ont pas de sémantique opérationnelle. Par exemple, le type distance peut désigner une distance par rapport à un obstacle ou une distance de sécurité, etc. Figure IV.23 – physicalData 74IV.4 Conception de RobotML – un type composé ComposedData. C’est un type qui représente des données communes à des objets du domaine de la robotique. Comme par exemple GPS, Image, etc. (voir figure IV.24). Figure IV.24 – Types composés de RobotML – un type primitif PrimitiveData comme par exemple le type bool, int, char, etc. (voir figure IV.25). – une collection c.-à-d. listes, tables de hashage, séquences, etc. – un timestamped data qui associe un horodateur à une donnée pour connaître son évolution au fil du de l’exécution (si elle reste valide, etc.). Figure IV.25 – Types primitifs de RobotML Étant donné que le middleware ROS a été intégré à la plupart des plateformes cibles de RobotML (OROCOS, RT-Maps, etc.), nous avons également défini une librairie basée sur les types ROS afin de faciliter leur utilisation par les uti- 75Chapitre IV. Robotic Modeling Language (RobotML) lisateurs de RobotML. Ces types sont représentés comme des DataType comme le montre la figure IV.26 où les geometry_msgs de ROS sont représentés. Figure IV.26 – Intégration des geometry_msgs de ROS à RobotML 4. Le package Robotic Mission. Ce package décrit les concepts qui sont requis pour la définition d’une mission opérationnelle et qui sont utilisés par les composants de l’architecture qui réalisent cette mission. Ce package est typiquement utilisé pour la représentation des scénarios. 5. Le package Platform (voir figure IV.27). Il définit les plateformes qui représentent l’environnement d’exécution. La méta-classe Platform peut être un middleware (méta-classe RoboticMiddleware) ou un simulateur (RoboticSimulator). L’attribut RoboticMiddlewareKind est typpé par une énumération où les noms des middleware pris en charge par le DSML sont spécifiés. Aucune propriété des middleware n’est représentée. Le choix d’un middleware servira uniquement au déploiement. De même pour la méta-classe RoboticSimulator qui est spécialisée en trois méta-classes où il y a seulement besoin de spécifier la configuration souhaitée de l’exécution (temps-réel ou non, valeur de la gravité, etc.) selon le simulateur choisi. 6. Le package Deployment permet l’allocation d’un composant (méta-classe System) vers une plateforme (méta-classe Platform) comme le montre la figure IV.28. 76IV.4 Conception de RobotML Figure IV.27 – Le package Platform Figure IV.28 – Le package Deployment Pour résumer, à partir de la partie architecture, il est possible de représenter le squelette d’un composant : ses ports, les types de ses ports ainsi que ses propriétés. Un composant peut être un composant matériel (capteur ou effecteur) ou un composant de contrôle. Dans la section suivante, nous présentons la partie control qui permet de spécifier le comportement d’un composant. 4.1.1.2 La partie Contrôle Cette partie du DSML est la partie responsable de la spécification du comportement des composants de contrôle d’un système de robotique. Nous allons maintenant expliquer quel contrôle nous souhaitons exprimer : – Le contrôle à boucle fermée (Feedback control) : Dans ce cas le système doit avoir un retour (une connaissance) sur son état après l’exécution d’une commande. 77Chapitre IV. Robotic Modeling Language (RobotML) – Le contrôle à boucle ouverte (open loop control) : Dans ce cas le système ne récupère pas les informations sur son état après l’exécution d’une commande. On retrouve ces boucles de contrôle dans les architectures que nous avons présentées dans la section 3.3 du chapitre 1. Si l’architecture est réactive, le principe est celui de Stimulus/Réponse. Il y a donc une action qui est définie suite à un état dans lequel se trouve le robot. Si l’architecture est basée sur le comportement, il devrait être possible de suivre l’évolution des comportements du robot et de les activer/dé- sactiver. Si l’architecture est hybride ou délibérative, le contrôle se base sur un plan. Il devrait alors être possible de représenter l’état du robot dans son plan. Le contrôle peut alors être exprimé comme un automate qui permet l’expression des instructions d’un composant à un niveau plus abstrait que le code. Pour commencer, l’utilisateur peut spécifier un automate où les états par lesquels le robot pourrait passer sont représentés. Il faudrait ensuite spécifier quels sont tous les états possibles à partir d’un état donné et sous quelle condition la transition entre ces états est déclenchée. Si le contrôle se base sur une boucle ouverte, la transition d’un état à un autre est déclenchée directement à partir du premier état. En revanche lorsqu’il s’agit d’une boucle fermée, la transition est déclenchée selon le retour de la commande exécutée. La figure IV.29 montre une vue globale des packages qui interviennent pour la définition de la partie comportementale d’un composant. Le comportement des composants est défini sous forme de machines à états finis (FSM) ou avec des algorithmes. Figure IV.29 – Le package RoboticBehavior La figure IV.30 donne une vue détaillée sur le package FSM. Evolution Model, conformément à sa description dans l’ontologie, est utilisé pour décrire le cycle de vie ou le comportement d’un composant (System). La méta-classe FSM hérite de 78IV.4 Conception de RobotML la méta-classe EvolutionModel. Une FSM est un automate composé d’états et de transitions. Ce package est fortement inspiré de la spécification des machines à états du méta-modèle d’UML. Les états représentent les actions que le robot doit effectuer. Nous distinguons les états initiaux des étaux finaux dans les FSMs. L’état initial Initial State est le premier état visité lorsqu’une FSM est exécutée, il est typiquement utilisé pour effectuer les initialisations requises pour la FSM. L’état final Final State indique que l’exécution de la FSM est terminée. Les transitions (Transition) forment des liens entre les états de la FSM. Une transition a un état source incoming et un état destination outgoing. Une transition peut aussi avoir une GuardCondition et un évènement (Event). Les états et les transitions sont composés de FSM Activities spécifiant les actions à exécuter (méta-classe Effect) pendant un état ou lors d’une transition donnée. Figure IV.30 – Le package FSM Dans la section suivante, nous présentons la communication entre les différents composants d’une application. 4.1.1.3 La partie communication Cette partie doit permettre la spécification de la communication entre les composants à travers des ports et des connecteurs. Nous nous sommes inspirés des mécanismes de communication utilisés dans SmartSoft [82] et nous les avons adapté aux concepts décrits par l’ontologie. La communication est réalisée à travers un échange synchrone ou asynchrone de données ou des appels de service. La figure IV.31 décrit les ports d’un composant. La méta-classe Port représente un point d’intéraction du système. On distingue deux sortes de ports : 79Chapitre IV. Robotic Modeling Language (RobotML) – Les ports de données DataFlowPort qui permettent la communication à travers des flots de données entre les composants. La méta-classe DataFlowPort a pour type un DataType et possède un attribut direction = {In, Out, InOut} qui spécifie le sens de l’échange de données et un attribut bufferSize qui définit la taille du buffer où les données sont enregistrées. La direction des ports est l’un des exemples de l’union des concepts des plateformes cibles que nous avons évoqué lorsque nous avions parlé de l’extraction des abstractions pertinentes dans le DSML. En effet, la direction InOut n’est pas présente dans toutes les plateformes cibles. Cependant, interdire sa représentation au niveau du DSML engendrerait des contraintes pour l’utilisation des plateformes qui prennent en charge ce concept. – Les ports de service ServicePort qui sont spécifiques à la communication client/serveur. La méta-classe ServicePort a un attribut serviceKind qui indique si le port est fourni ou requis. Un ServicePort a pour type une interface qui définit un ensemble d’opérations abstraites. La méta-classe CommunicationPolicy spécifie le type de communication utilisé (attribut synchronizationPolicy= {Synchrone/Asynchrone}) et la stratégie employée par le buffer (attribut strategyPolicy= {FIFO, LIFO}). Figure IV.31 – Les mécanismes de communication 4.1.2 Le profil RobotML Le profil RobotML définit des extensions des méta-classes du méta-modèle UML afin de les adapter aux concepts identifiés dans le modèle de domaine RobotML. 80IV.4 Conception de RobotML L’objectif de notre démarche est de pouvoir définir un éditeur graphique avec Papyrus [61] qui se base sur le profil RobotML et qui permet de manipuler les concepts identifiés à travers des modèles de scénarios de robotique. Pour définir le profil, les abstractions identifiées dans les parties représentées dans le modèle de domaine RobotML ont été reprises pour étendre les méta-classes d’UML. Le profil comporte alors trois parties principales conformément au modèle de domaine RobotML : architecture, communication et contrôle. Dans la partie architecture du profil, la méta-classe System et toutes les méta-classes qui la spécialisent sont transformées en stéréotypes qui étendent la méta-classe Class du méta-modèle UML comme le montre la figure IV.32. Les propriétés des métaclasses de RobotML comme par exemple les méta-classes RoboticSystem, Robot et Software sont transformées en tagged values des stéréotypes RoboticSystem, Robot et Software du profil. Figure IV.32 – Extrait de la partie Architecture : Stéréotypes extensions de la métaclasse Class d’UML Concernant la partie communication, la méta-classe Port du modèle de domaine RobotML et toutes les classes qui la spécialisent sont également transformées en stéréotypes qui étendent la méta-classe Port du méta-modèle UML comme le montre la figure IV.33. Les propriétés des méta-classes ServicePort et DataFlowPort du modèle de domaine RobotML sont définies comme des tagged values des stéréotypes ServicePort et DataFlowPort du profil. De la même façon, les méta-classes de RobotML représentant les aspects qui relèvent du contrôle ont été représentés à travers des stéréotypes qui étendent les méta-classes définissant les machines à états dans le méta-modèle UML (State, Transition, etc.) comme le montre la figure IV.34 pour les stéréotypes State et Transition. Concernant la méta-classe Algorithm de RobotML, elle est définie comme un stéréotype qui étend la méta-classe Operation du méta-modèle UML. 81Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.33 – Extrait de la partie communication : Stéréotypes extensions de la métaclasse Port d’UML Figure IV.34 – Extrait de la partie Control : Stéréotypes extensions des méta-classes du méta-modèle d’UML Chaque stéréotype du profil que nous défini peut avoir une icône associée pour sa représentation graphique. Nous allons présenter dans ce qui suit l’éditeur graphique de RobotML. 4.2 Syntaxe concrète : L’éditeur graphique de RobotML L’éditeur graphique de RobotML a été conçu en utilisant l’outil Papyrus [61]. Afin de définir l’éditeur graphique, des icônes peuvent être rattachées graphiquement aux stéréotypes du profil de RobotML. Selon la sémantique d’utilisation l’une des icônes est affichée. La partie gauche de la figure IV.35 montre les icônes attachées aux stéréotypes SensorSystem, ActuatorSystem, DataFlowPort et ServicePort. Ces icônes sont ensuite représentées dans la palette (partie droite de la figure). Les stéréotypes SensorSystem, ActuatorSystem ont une seule icône attachée qui représente un capteur ou un effecteur. Le stéréotype DataFlowPort a trois icônes attachées, chacune 82IV.4 Conception de RobotML correspond à un type de DataFlowPort selon la direction utilisée {In, Out, InOut}. Le stéréotype ServicePort n’a que deux états possibles {Required, Provided}, chacun d’entre eux a une icône qui lui correspond. Figure IV.35 – À gauche, les icônes attachées aux stéréotypes, à droite la palette montrant les différentes icônes En plus des icônes, il est possible d’associer un ensemble de stéréotypes à des diagrammes dédiés à une représentation d’une partie du modèle. Plusieurs diagrammes sont proposés comme le montre la figure IV.36. Le model Explorer contient les élé- ments du modèle représentés à travers les différents diagrammes. Le diagramme de définition des composants permet de représenter les composants d’une application ainsi que les capteurs et les effecteurs. Le diagramme de machine à états et la palette qui lui est associé contient les concepts State, Final State, Initial State et Transition. La vue Properties permet de spécifier les propriétés des éléments du modèle. À partir des modèles représentés avec cet éditeur graphique on peut générer du code exécutable vers une ou plusieurs plateformes cibles. La section suivante présente la génération de code vers le middleware OROCOS. 83Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.36 – Environnement de modélisation de RobotML 5 Intégration du middleware OROCOS : génération de code Les concepts de RobotML étant définis à partir de l’état de l’art sur les middlewares et les simulateurs et d’une ontologie de la robotique, regroupent l’union des concepts identifiés dans les plateformes cibles ainsi que des abstractions du domaine. Par exemple, les ports d’entrée sortie présentés précédemment : le concept InOutPort n’est pas présent dans toutes les plateformes. Nous l’avons représenté dans le modèle du domaine car nous avons fait le choix de ne pas imposer de restrictions sur les concepts des plateformes. Ainsi il est possible de représenter les plateformes qui utilisent ce concept. La génération de code permet de founir à partir d’un modèle de scénario une application exécutable facilitant ainsi le développement des applications de robotique. Les plateformes cibles des générateurs peuvent évoluer mais les abstractions que nous avons utilisées sont suffisamment stables pour supporter cette évolution à court terme. En d’autres termes, le développement des générateurs de code définis à partir de RobotML est un processus plus rapide que l’évolution des plateformes cibles. Bruyninckx et al. [3] ont argumenté le fait qu’ils ne pouvaient pas intégrer leur approche de la séparation des responsabilités à leur méta-modèle (voir figure III.8) par le fait que les plateformes cibles se basaient sur des architectures stables qui ne vont pas évoluer vers d’autres architectures. Ainsi, la définition des générateurs de code faciliterait le développement des appli- 84IV.5 Intégration du middleware OROCOS : génération de code cations de robotique et permettrait d’accélérer le processus de développement. La première étape pour l’intégration des plateformes cibles est d’établir des règles de correspondance entre les éléments du DSML et les plateformes cibles. Grâce au respect de RobotML des exigences du domaine et de celles des middleware et des simulateurs de robotique, il est possible d’établir des règles de transformations à partir de RobotML vers plusieurs plateformes hétérogènes. Dans le cadre du projet PROTEUS, plusieurs générateurs de code ont été réalisés vers : OROCOS-RTT[47], RTMaps[113], Urbi [114] et Arrocam [115] et les simulateurs MORSE [116] et CycabTK [117]. Notre approche se base sur les techniques de la MDA présentées précédemment à l’exception que notre PSM est le code. Nous utilisons une API commune implantée qui permet d’interroger les éléments du modèle. En se basant sur cette API commune, chaque générateur définit les règles de transformation vers sa plateforme cible en utilisant l’outil Acceleo [67]. Le middleware ROS a joué un rôle important dans le développement des générateurs de code. Étant donné qu’il a été intégré aux plateformes cibles prises en charge par RobotML, nous utilisons les topics ROS pour l’échange des données entre les composants générés vers des plateformes hétérogènes. Nous présentons dans cette section le générateur de code OROCOS-RTT qui définit des transformations de modèle vers texte à partir de RobotML. Le générateur de code a été implanté en utilisant Acceleo. OROCOS (Open RObot COntrol Software) est un framework temps-réel à base de composants C++ [47], appelé aussi OROCOS-RTT (Real-Time Toolkit) pour son aspect temps-réel. Les composants OROCOS intéragissent par un échange de données, d’évènements ou de services à travers des ports. L’échange de données est effectué par des data flow ports d’entrée/sortie, les événements indiquent un changement dans le système et l’échange de services est effectué à travers des simples appels de méthodes. Les composants OROCOS peuvent être définis sous forme de machine à états finis hiérarchiques. 5.1 Génération du squelette d’un composant Le tableau IV.6 montre la correspondance entre les concepts du DSL architecture décrivant les concepts relavant de la structure globale d’un composant et les 85Chapitre IV. Robotic Modeling Language (RobotML) Concepts de RobotML concepts d’OROCOS Property Task Context Attribute Attribute Port – Primitive DataType C++ types Composed DataType Data structure Interface Abstract class Attribute Attribute Interface Operation Virtual Method Operation Operation Parameter Parameter Table IV.6 – Correspondance entre le DSL Architecture et les concepts d’OROCOS concepts d’OROCOS. Les composants OROCOS héritent de l’interface TaskContext et possèdent des propriétés et des threads d’exécution. Concernant les interfaces, elles sont géné- rées comme des classes abstraites ayant des méthodes virtuelles. Ces méthodes sont Concernant les Data Types, les Primitive DataTypes sont transformés en types C++. Concernant les types ComposedDataTypes ils sont générés comme des structures de données. 5.2 Génération de la communication entre les composants Concepts de RobotML concepts d’OROCOS Data Flow Port direction {In} Input Port Data Flow Port direction {Out} Output Port Service Port {Provided } this->provides(Operation) Service Port {Required} this->requires(OperationCaller) Table IV.7 – Correspondance entre le DSL Communication et les concepts d’OROCOS Les composants échangent les données et les appels de service à travers des ports de données (DataFlowPort) et des ports de service (ServicePort). Selon leurs directions, les ports de données sont transformés en InputPort ou en OutputPort comme le montre le tableau IV.7. Les ports de service, quant à eux, sont transformés en ServicePort qui fournissent ou requièrent une opération. Si le service est requis, le composant fait appel à l’opération définie dans l’interface à travers le mot clé OperationCaller en précisant le type de l’opération et ses paramètres. Dans le cas contraire (c.-à-d. si le service est fourni), le composant implémente l’opération en 86IV.5 Intégration du middleware OROCOS : génération de code question et indique qu’il la fournit en utilisant la méthode provides. L’échange de données à travers les composants est effectué à travers des ports de données. RobotML fournit un ensemble de types communément utilisés en robotique (Composed DataType) sous forme de bibliothèques. Ces bibliothèques permettent de réutiliser ces types sans avoir à les redéfinir à chaque fois. Selon la nature de ces composants et le plan de déploiement, les types de ces ports sont générés : – Si le composant est un composant de contrôle (System) et est connecté à d’autres composants de contrôle déployés sous le même middleware alors les types de ses ports sont les types indiqués dans le modèle. – Si le composant est un composant de contrôle et est connecté à un autre composant déployé sous un autre middleware alors le type de ses ports est traduit en type ROS. – Si le composant est un composant matériel (c.-à-d. capteur ou effecteur) alors les types de ses ports seront traduits en types ROS. – Si le composant est composant de contrôle et est connecté à un composant matériel alors les types de ses ports seront traduits en types ROS. Les bibliothèques définissant les types utilisés par les propriétés ou les ports d’un composant sont automatiquement importées dans le fichier source du composant. La connexion entre les composants est configurée dans un script OPS (OROCOS Program Script) qui permet la spécification de la périodicité, du type de communication entre les composants (ROS ou CORBA) comme le montre le tableau IV.8. Le plan de déploiement intervient également pour cette configuration. Une distinction est effectuée entre la communication inter-composants du même middleware (mot clé connectPeers) pour indiquer que la communication va s’appuyer sur CORBA. Autrement, le mot clé stream est utilisé pour spécifier que la connexion se fait entre des composants de natures différentes et que ROS sera utilisé. 5.3 Génération du comportement d’un composant Chaque composant a un comportement décrit en utilisant une machine à états finis (FSM) ou un algorithme. Les FSMs peuvent être définies grâce au package rFSM 2 intégré à OROCOS. Il permet la définition de scripts en Lua [118] puis de 2. http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html#sec-1 87Chapitre IV. Robotic Modeling Language (RobotML) Concepts de RobotML Fichier OPS Communication Policy setActivity("ComponentA", period, priority, scheduler) setActivity("ComponentB", period, priority, scheduler) loadComponent("ComponentA", "A") loadComponent("ComponentB", "B") Connector var connPolicy x ; (composants homogènes) x.type = DATA ; //DATA = 0, BUFFER = 1 x.size = 1 ; //size of the buffer x.lock_policy = LOCK_FREE ; //UNSYNC = 0, LOCKED = 1, LOCK_FREE = 2 x.transport = 3 ; //ROS = 3 stream("componentA", x) Connector connectPeers("ComponentA", "ComponentB") (composants hétérogènes) Table IV.8 – Correspondance entre le DSL Communication et les concepts d’OROCOS les charger par les composants OROCOS. La tableau IV.9 décrit la correspondance entre les concepts de RTT-Lua et les concepts de RobotML. Concepts de RobotML concepts d’OROCOS State Machine StateMachine Initial State initial state{ entry{} run{} exit{}} Final State final state{ entry{} run{} exit{}} State state{ entry{} run{} exit{}} Transition rfsm.transition {src="InitialState", tgt="state1" Event ,events{} Guard ,guard=function() end Effect ,effect=function() end } Table IV.9 – Correspondance entre le DSL Contrôle et les concepts d’OROCOS La correspondance entre les états est triviale. Les gardes et les effets sur les transitions sont des fonctions dont le corps est défini par l’utilisateur à travers un stéréotype d’UML appelé OpaqueBehavior. À la génération, ces fonctions sont capturées à partir du modèle et injectées à la place de la balise . Un exemple de requête permettant de récupérer les transitions définies dans une machine à 88IV.5 Intégration du middleware OROCOS : génération de code états du modèle est donné dans le listing IV.6. Cette requête retourne un ensemble de transition (sequence(Transition) et fait appel à la fonction getTransitions(org.eclipse.uml2.uml.StateMachine) du template Acceleo FSMQueries. [ query public getTransitions ( sm : StateMachine ) : Sequence ( Transition ) = invoke ( ’ org . eclipse . robotml . generators . acceleo . mmqueries . FSMQueries ’ , ’ getTransitions ( org . eclipse . uml2 . uml . StateMachine ) ’ , Sequence { sm }) /] Listing IV.6 – Requête pour récupérer les transitions d’une machine à états D’autres requêtes sont également utilisées pour générer le code d’une machine à états. Un extrait d’un tempate Acceleo définissant les règles de transformation pour chaque requête sur les transitions, leurs gardes et leurs effets sont présentées dans listing IV.7. Pour chaque transition on récupère à partir des triggers qui lui sont associés les guards et les opérations qui leur sont associés (lignes 13 - 23) ainsi que les effets (lignes 24 - 34). 1 [ l e t t r a n s i t i o n s : S equ en c e (RobotML : : T r a n s i t i o n ) = g e t T r a n s i t i o n s ( fsm ) ] 2 [ fo r ( t r a n s i t i o n : RobotML : : T r a n s i t i o n | t r a n s i t i o n s ) ] 3 r fsm . t r a n s i t i o n { s r c=" 4 ␣␣␣␣ ␣ [ t r a n s i t i o n . b a s e_T r a n s i t i o n . s o u r c e . name / ] " , 5 t g t=" [ t r a n s i t i o n . b a s e_T r a n s i t i o n . t a r g e t . name / ] " 6 [ i f ( h a s T r i g g e r s ( t r a n s i t i o n . b a s e_T r a n s i t i o n ) ) ] 7 , e v e n t s={ 8 [ fo r ( t r i g : T r i g g e r | t r a n s i t i o n . b a s e_T r a n s i t i o n . t r i g g e r ) ] 9 ’ [ t r i g . name / ] ’ 10 [ / fo r ] 11 } 12 [ / i f ] 13 [ i f ( t r a n s i t i o n . guard <> nu l l ) ] 14 [ l e t guard : RobotML : : A lgor ithm = t r a n s i t i o n . guard ] 15 , guard=f u n c t i o n ( ) 16 [ l e t op : Op e r a t i on = g e tA s s o c i a t e dO p e r a t i o n ( guard . bas e_Op erat ion ) ] 17 [ fo r ( o : OpaqueBehav ior | g etOp erat ionM ethod ( op ) ) ] 18 [ o . _body / ] 19 [ / fo r ] 20 [ / l e t ] 21 end 22 [ / l e t ] 23 [ / i f ] 24 [ i f ( t r a n s i t i o n . e f f e c t <> nu l l ) ] 25 [ l e t e f f e c t : RobotML : : A lgor ithm = t r a n s i t i o n . e f f e c t ] 26 , e f f e c t=f u n c t i o n ( ) 27 [ l e t op : Op e r a t i on = g e tA s s o c i a t e dO p e r a t i o n ( e f f e c t . bas e_Op erat ion ) ] 28 [ fo r ( o : OpaqueBehav ior | g etOp erat ionM ethod ( op ) ) ] 29 [ o . _body / ] 30 [ / fo r ] 31 [ / l e t ] 32 end 33 [ / l e t ] 34 [ / i f ] 35 } , 36 [ / fo r ] 37 [ / l e t ] Listing IV.7 – Template de génération des transitions des machines à états vers OROCOS 89Chapitre IV. Robotic Modeling Language (RobotML) Nous avons implanté des templates définissant des règles de transformation pour tous les éléments du modèle vers du code OROCOS. Le but du générateur OROCOS consiste à fournir une application compilable et exécutable. Pour ce faire, un ensemble d’artefacts est également généré notamment : – un fichier makefile – un fichier CMakeLists.txt spécifiant le chemin des composants à charger pour l’application ainsi leurs noms. – un fichier manifest.xml spécifiant les librairies à importer pour l’application. Pour résumer, le générateur de code OROCOS prend en entrée le modèle représenté avec les outils de RobotML et fournit un ensemble de fichiers correspondants aux concepts de notre DSML comme le montre la figure IV.37. Figure IV.37 – Génération de code avec OROCOS 6 Utilisation : chaîne d’outillage RobotML Afin de valider notre DSML sur des exemples industriels, plusieurs scénarios (appelées challenges) ont été proposés dans le cadre du projet PROTEUS. RobotML fournit une chaîne d’outillage pour le développement des applications de robotique allant de la modélisation jusqu’à la génération de code et le déploiement vers des simulateurs ou des robots réels. L’utilisateur de RobotML commence par modéliser sa mission en représentant les types de données et les interfaces, les composants de contrôle et matériels, ainsi que 90IV.7 Validation et Expérimentations les connexions entre eux. Une fois le modèle validé, l’utilisateur définit un plan de déploiement qui consiste en un ensemble de middlewares et/ou de simulateurs inter-connectés pour former une plateforme d’exécution pour l’application finale. Chacun des composants définis doit être alloué vers une plateforme cible d’un modèle de déploiement. Typiquement, le système de contrôle du robot modélisé est généré vers un ou plusieurs middleware (selon le plan de déploiement défini). Quant aux capteurs, aux actionneurs et à l’environnement du robot, ils sont générés vers le simulateur choisi. De plus, l’utilisateur a la possibilité de réutiliser des composants déjà existants sur la plateforme qu’il souhaite en spécifiant leur chemin et leur nom. Dans ce cas, pour ce composant, seule sa connexion avec le reste des composants est générée. L’utilisateur peut maintenant générer du code exécutable à partir du plan de déploiement qu’il a défini. Figure IV.38 – Etapes de modélisation en utilisant RobotML 7 Validation et Expérimentations Pour réaliser la validation de RobotML et de la génération de code vers OROCOS, nous avons choisi d’utiliser l’un des scénarios proposés dans le cadre du projet 91Chapitre IV. Robotic Modeling Language (RobotML) PROTEUS par l’ONERA 3 appelé le scénario aérien (AIR OARP). 7.1 Scénario de l’AIROARP Le scénario Air OARP considère le problème de la planification pour la perception et la perception pour la planification d’un véhicule aérien sans pilote. Le sujet de recherche adressé par Air OARP concerne les questions en matière de planification de mouvement pour la recherche et le suivi d’une cible. La plateforme ReSSac sera utilisée afin de réaliser les différentes expérimentations de site Caylus. Le site Caylus est une zone rurale et légèrement urbanisée. La zone comprend des routes, des pistes, des arbres et des bâtiments. Certains bâtiments comme les granges et les hangars ont de grandes portes ouvertes. Certains intrus peuvent tenter de traverser la zone, de se cacher dans cette zone ou tenter de s’échapper quand ils sont détectés. L’objectif pourrait être alors de détecter, reconnaître, identifier, localiser et suivre les intrus. La surveillance d’une zone est incluse dans un carré avec 400 mètres de long bord et est réalisée en utilisant un véhicule aérien sans pilote (UAV). Quand un intrus est reconnu dans le domaine d’un appareil photo, l’objectif peut être de le garder dans le domaine aussi longtemps que possible. Dans la section suivante, nous montrons la modélisation de ce scénario avec RobotML. 7.2 Conception du scénario avec RobotML Nous commençons tout d’abord par présenter les différents types de données nécessaires pour ce scénario (voir figure IV.39). Le type State est un type utilisateur qui est défini par un numéro de phase, un compteur de trames, une altitude en baromètre, la vélocité et d’autres attributs qui spécifient l’état dans lequel se trouve le robot. Le type Image est un type utilisateur qui désigne l’image d’une caméra. Il est défini par une largeur, une longueur, un nombre de pixels et un attribut qui indique si cette image a une couleur ou non. Le type Waypoint est un type utilisateur qui indique les propriétés d’un point cible. Ce point a des coordonnées en 3 dimensions (m_x, m_y, m_z). Ce type permet aussi d’indiquer la direction que doit prendre le robot pour atteindre ce point ainsi que la vitesse d’approche pour aller à ce point. 3. http://www.onera.fr/ 92IV.7 Validation et Expérimentations Le type Way est un type qui spécifie le chemin du robot. Enfin, les types primitifs Double, bool, unsigned et char sont représentés. Figure IV.39 – Modèle des types de données AIR OARP Après les types des données, les interfaces ont été représentées avec RobotML (voir figure IV.40). L’interface ObcInterface est l’interface qui définit les actions du robot (par exemple : move, goTo, track et l’évolution de sa trajectoire dans son environnement (par exemple wayPointadd, wayPush, obstacleAdd). L’interface CameraInterface définit les opérations relatives aux images perçues par la caméra du robot (par exemple setBrighteness, setGain, etc.). Après avoir défini les types et les interfaces qui définissent les services que les composants vont s’échanger, les composants de l’application sont maintenant repré- sentés. Le composant Obc du package AvionicSystem prend en entrée les informations des capteurs de localisation afin de récupérer les informations sur l’état du robot en implémentant les opérations de l’interface ObcInterface. Le composant m_talc_cam_driv (voir figure IV.42) est un driver qui transforme les données physiques envoyées par la caméra en données de type Image (le type utilisateur défini). Ce composant implémente aussi les opérations de l’interface CameraInterface. Ces deux composants envoient ensuite l’état du robot et l’image perçue au composant RMaxControlSystem qui va décider de l’action à effectuer. Les opérations des 93Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.40 – Les interfaces du scénario AIR OARP Figure IV.41 – Le composant AvionicSystem deux interfaces ObcInterface et CameraInterface sont des services requis par le composant de contrôle principal RMaxControlSystem. Dans la section suivante, nous présenterons la génération de code vers le middleware OROCOS. 7.3 Génération de code vers OROCOS La génération de code comme nous l’avons présentée précédemment permet de générer pour chaque concept de RobotML le code associé. Les interfaces et les types de données ont été traduits en structures de données définissant leurs propriétés et leurs opérations. Les composants représentés ont été traduits en composants OROCOS. Les interactions entre eux sont tranduites par des propriétés au niveau des fichiers de configuration ainsi qu’au niveau des ports. Enfin pour le composant de contrôle RMaxControlSystem, nous avons généré une 94IV.8 Discussion Figure IV.42 – Le composant CameraSystem Figure IV.43 – Modèle du scénario AIR OARP machine à états finis. Les résultats de cette génération de code sont disponibles sur la page 4. 8 Discussion L’objectif principal de RobotML est de fournir aux roboticiens un langage dédié qui facilite le développement de leurs applications et qui répond aux exigences du domaine. Dans ce contexte, un ensemble d’exigences a été défini dans 4.1. RobotML a apporté une réponse à ces exigences : 1. Facilité d’utilisation. Grâce à RobotML, les utilisateurs du DSL peuvent modéliser leurs applications sans avoir à connaître ou à maîtriser les lanagages 4. https://github.com/RobotML/RobotML-documentation/blob/master/ RobotMLCodeGenerators/OROCOSGenerator/index.rst 95Chapitre IV. Robotic Modeling Language (RobotML) de programmation des plateformes de robotique. En effet, les détails des plateformes sont masqués pour les utilisateurs du DSL et les concepts utilisés dans RobotML sont basés sur une ontologie définie par des experts de la robotique. 2. Spécification d’une architecture à base de composants. L’architecture utilisée est une architecture à base de composants de contrôle et matériels. 3. Spécification des comportements des composants. RobotML permet la spécification du comportement des composants à travers des machines à états finis ou des algorithmes. 4. Neutralité vis à vis des architectures de robotique. La plupart des plateformes de robotique sont basées sur une architecture à base de composants. C’est pour cette raison que RobotML n’est spécifique à aucune autre architecture (délibérative, réactive ou hybride). N’importe quelle architecture peut donc être définie avec RobotML. 5. Plusieurs plateformes cibles hétérogènes. En raison de la distinction de la nature des composants au niveau de la modélisation (matériel ou contrôle) et de la possibilité de spécifier un plan de déploiement, il est possible de gé- nérer du code vers plusieurs plateformes hétérogènes. Lorsqu’il s’agit de faire interopérer ces plateformes hétérogènes (c.-à-d. : un middleware et un simulateur ou plusieurs middlewares) la communication s’appuie sur les messages ROS (automatiquement pris en charge par les composants générés) en raison de son intégration dans la plupart des plateformes de robotique actuelles. 6. Indépendance vis à vis des plateformes cibles. Grâce à l’ontologie du domaine, les concepts de RobotML sont abstraits et se basent sur la terminologie du domaine. Cependant, ces concepts correspondent aussi aux plateformes cibles sans être spécifiques à une plateforme particulière. Il n’y a pas de restriction imposée par une plateforme. 7. Prise en charge de l’évolution des plateformes Etant donné que le DSML est indépendant des détails des plateformes cibles, l’évolution des plateformes cibles n’affecte pas le modèle de domaine RobotML. Cette évolution pourrait cependant avoir un impact sur les générateurs. Notons quand même que le temps de développement des générateurs est moins important que l’évolution des plateformes cibles). 96IV.9 Conclusion 8. Evolution du DSL. RobotML est défini de manière itérative à partir d’exemples exécutables. Cette approche a été combinée avec une approche complémentaire top-down à partir d’une ontologie du domaine de la robotique définissant des concepts précis. L’évolution du DSL est considérée comme un processus intégré et incrémental au processus du développement. Dans certains cas, une absence de correspondance entre le modèle de domaine et les plateformes cibles a été constaté. Dans ce cas, ce concept est ajouté au DSL et des nouvelles règles de transformation sont définies pour la génération de code. Par exemple, nous avons constaté que l’utilisateur doit être capable de spécifier la taille du buffer pour l’échange de données entre les composants au niveau de la modélisation. Un nouvel attribut a alors été ajouté à la méta-classe CommunicationPolicy de RobotML. 9. Abstraction du matériel Les types Physical Data permettent de définir des abstractions à partir du matériel. Cependant, ils représentent des abstractions générales et n’ayant pas de sémantique précise. C’est pour cette raison qu’ils ont été définis au niveau du modèle du domaine et pas implémentés dans la syntaxe concrète de RobotML. La validation de RobotML et du générateur de code OROCOS a été effectuée sur le scénario AIR OARP que nous présenterons dans le chapitre suivant. 9 Conclusion Nous avons présenté dans ce chapitre notre DSML pour la robotique : RobotML. Les concepts de RobotML sont des concepts du domaine définis par des experts en robotique. Nous avons montré que ces concepts nous ont permis de représenter des scénarios de robotique indépendamment des plateformes d’exécution (middleware et simulateurs). RobotML offre également un ensemble d’outils qui visent à faciliter le développement des applications de robotique. Nous avons vu également que le modèle de domaine RobotML propose des types abtraits, extraits de l’ontologie, appelés PhysicalData afin d’abstraire les données des capteurs (voir IV.23). Cependant, ces types n’ont pas de sémantique d’utilisation précise car ce sont des abstractions a priori qui n’ont pas été définies à partir d’exemples concrets. Il faudrait établir un certain nombre d’itérations à partir d’exemples concrets afin de 97Chapitre IV. Robotic Modeling Language (RobotML) convenir d’un ensemble d’abstractions ayant une sémantique bien définie et pouvoir les intégrer éventuellement à l’ontologie. Par conséquent, les méta-classes de PhysicalData n’ont pas été étendues par le profil UML et ne sont donc pas visibles pour le moment pour les utilisateurs de RobotML. Nous nous proposons alors dans le chapitre suivant de présenter une démarche, qui pourrait compléter l’ontologie, avec des abstractions définies a posteriori (c.-à- d. après une étude détaillée d’un exemple de tâche de robotique). 98Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 1 Introduction Les roboticiens sont confrontés à plusieurs difficultés pour le développement de leurs applications. La principale difficulté concerne la maîtrise des détails du matériel du robot. En effet, l’implantation d’une tâche de robotique requiert des informations sur les moyens de locomotion du robot, sa morphologie et ses capteurs. Implanter une tâche de robotique qui marcherait pour tous les moyens de locomotion et qui tiendrait compte des entrées de tous les capteurs est un processus très complexe [45]. Il faudrait au moins utiliser des abstractions comme celles proposées par les middleware ou celles proposées par l’ontologie de RobotML. Cependant, les abstractions proposées par les middleware sont de bas niveau. Il est très difficile de les appliquer dans le cas où l’on souhaite développer une application pour un robot de forme inconnue, dont les capteurs sont inconnus et où les moyens de locomotion le sont aussi. En effet, toutes ces informations doivent être connues afin de calculer les données des capteurs et exécuter les mouvements du robot [45]. D’autre part, les abstractions proposées par l’ontologie du domaine représentent des concepts du domaine [69] définis a priori et non à partir d’exemples concrets. Par conséquent, ces abstractions sont insuffisantes et n’ont pas de sémantique opérationnelle précise à savoir qu’on ne sait pas forcément comment les implanter dans un programme. 99Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Une autre difficulté peut être soulevée lorsqu’il s’agit d’une tâche de robotique où plusieurs stratégies visent à atteindre un même objectif en se basant sur les mêmes hypothèses sont définies comme la famille de navigation Bug [38]. Il s’agit alors de variabilité algorithmique. Il est difficile de comparer les variantes d’une famille ou même de les comprendre car elles sont proposées par différents auteurs dans la littérature et sont souvent implantées sous différentes plateformes. Si on pouvait définir un algorithme générique pour les variantes d’une famille d’algorithmes, il serait plus facile de les comprendre, de les implanter et plus significatif de les comparer entre elles. À notre connaissance, très peu de travaux se sont intéressés à la gestion de ce type de variabilité. Brugali et al. [119] ont proposé une ligne de produits logicielle pour la gestion de la variabilité au sein des tâches de robotique telles que la localisation, la navigation et l’évitement d’obstacles. Cependant, leurs composants sont interdépendants. En d’autres termes, ils sont spécifiques à un type de capteur en particulier : le capteur Laser. Leur implantation se base sur des messages ROS ce qui reste spécifique aux types fournis par ce middleware. Afin de faciliter le développement des applications de robotique et les rendre résistantes aux différents types de variabilité cités précédemment, il faudrait alors définir des abstractions qui soient : 1. de plus haut niveau que celles proposées par les middleware : qui encapsulent les mesures et les données retournées par les capteurs et les commandes spé- cifiques des effecteurs 2. plus précises que celles proposées par l’ontologie : elles doivent avoir une sé- mantique opérationnelle Ces abstractions masqueraient alors les détails non algorithmiques et pourraient varier indépendamment des algorithmes. Concernant les détails algorithmiques dans le cas où il s’agit d’une famille d’algorithmes, il faudrait également définir des abstractions qui masquent la variabilité au sein d’une même famille. Dans cette optique, nous proposons une approche top-down qui, à partir de la description d’une tâche de robotique et des hypothèses sur l’environnement et sur les capacités du robot, produit : – un ensemble d’abstractions non algorithmiques ainsi que des abstractions algorithmiques 100V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique – un algorithme générique défini en fonction de ces abstractions L’intervention d’un expert de robotique est requise pour l’identification de ces abstractions et leur combinaison pour définir un algorithme générique de façon analogue à un planificateur. Les hypothèses définies sur les capacités du robot ne doivent pas être liées à des capteurs ni à des effecteurs spécifiques. Elles doivent plutôt se baser sur les données requises par l’algorithme. L’expert définit donc des abstractions comme étant des requêtes sur l’environnement et des actions de plus haut niveau que les commandes spécifiques aux effecteurs. Dans ce chapitre, nous présentons notre approche pour l’identification de ces abstractions et d’un algorithme générique défini en fonction de ces dernières. Nous proposerons ensuite une démarche pour implanter les abstractions ainsi que l’algorithme générique. Nous appliquerons ensuite notre approche sur une famille d’algorithmes de navigation appelée Bug [38]. 2 Approche pour la gestion de la variabilité dans les algorithmes de robotique À partir d’une tâche de robotique, notre approche permet de produire un algorithme générique configurable en fonction d’un ensemble d’abstractions qui masquent les détails du matériel et les détails algorithmiques. Une fois l’algorithme générique défini, nous proposons une démarche pour l’implantation de ces abstractions et de l’algorithme générique de façon à faire varier l’implantation de ces abstractions sans avoir à modifier l’implantation de l’algorithme générique. Nous présentons dans cette section les différentes étapes de notre approche. 2.1 Identification des abstractions La forme des robots varie d’un robot à l’autre ce qui affecte le fonctionnement des capteurs surtout s’ils sont placés sur celui-ci comme les capteurs à rayons (range sensors). Le nombre, la nature et la position de ces capteurs varient aussi d’un robot à l’autre. Un capteur Laser a un angle de perception, les Infrarouges ont des rayons de perception, etc. Les capteurs tactiles ont un autre mode de fonctionnement mais permettent d’indiquer par exemple si un obstacle est détecté tout comme les cap- 101Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique teurs à rayons mais avec un mode de fonctionnement différent. Nous avons vu que certains middleware ont défini des interfaces pour les range sensors par exemple. Leurs abstractions sont liées aux types des capteurs. Nous avons mentionné précédemment que les abstractions que nous voulons définir sont de plus haut niveau que celles proposées par les middleware et ont une sémantique par rapport à celles proposées par l’ontologie du domaine et donc RobotML. Les abstractions dans ce travail permettent d’encapsuler les détails impertinents dans l’algorithme représentant la tâche à développer. Nous distinguons deux types d’abstractions : algorithmiques et non algorithmiques, nos définitions sont les suivantes : Definition 11 (Abstraction non algorithmique). Une abstraction non algorithmique est soit une requête qui retourne des informations sur l’environnement y compris le robot soit une action de haut niveau que le robot doit effectuer. Definition 12 (Abstraction algorithmique). Une abstraction algorithmique est liée à la tâche à développer. Elle peut encapsuler un ensemble d’instructions permettant de réaliser une sous-tâche ou des détails liés aux variantes d’un algorithme lorsqu’il s’agit d’une famille d’algorithmes. Les abstractions non algorithmiques sont des abstractions qu’on peut capitaliser car elles sont indépendantes des détails algorithmiques d’une tâche. Les abstractions algorithmiques, quant à elles, peuvent dépendre des abstractions non algorithmiques mais restent spécifiques à la tâche à développer. Lorsqu’il s’agit d’abstractions non algorithmiques, on peut distinguer deux cas : 1. L’abstraction est une requête sur l’environnement y compris le robot. Dans ce cas, cette requête indique par exemple si le robot est face à un obstacle, s’il perçoit de la lumière, etc. Les paramètres de configuration de cette requête sont spécifiés au niveau de leur implantation. 2. L’abstraction est une action de haut niveau permettant au robot d’agir dans son environnement. Cette action peut être simple comme l’action avancer ou composée d’actions simples comme suivre un obstacle dans une direction donnée. Les variables permettant de spécifier la vitesse ou la direction que doit suivre une action sont passées en paramètres à celle-ci. 102V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique Concernant les abstraction algorithmiques, elles sont de plus haut niveau que les abstractions non algorithmiques. Elles font appel à des actions et à des requêtes sur l’environnement afin d’effectuer une sous-tâche de la tâche à implanter. De notre point de vue, l’identification des abstractions ne nécessite pas de connaissances approfondies des capteurs ou des effecteurs physiques d’un robot particulier comme la démarche adoptée par les middleware. Cette étape requiert une connaissance de la tâche à développer d’où l’intervention d’un expert du domaine. Notre approche s’appuie sur la description d’une tâche de robotique ce qui permet de définir des hypothèses sur l’environnement et sur les capacités que doit avoir un robot pour qu’il puisse exécuter cette tâche. À partir de la description d’une tâche, un expert en robotique peut identifier des fonctionnalités que le robot doit effectuer en se basant par exemple sur une démarche dirigée par les buts. Ces fonctionnalités font appel à des actions, lancent des requêtes sur l’environnement et effectuent des traitements sur les données récupérées afin de se rapprocher de l’état but de la tâche à réaliser. Les requêtes sur l’environnment définissent par conséquent la catégorie des capteurs à utiliser. Par exemple, dans une tâche de navigation, l’une des fonctionnalités du robot consiste à éviter les obstacles rencontrés. Il faut que le robot soit capable de détecter cet obstacle. On peut donc définir des hypothèses sur les capacités du robot à indiquer la présence d’un obstacle dans son champs de perception. Ces requêtes pourront ensuite être appliquées sur des capteurs de distance ou de contact par exemple. Concernant les actions de haut niveau, elles sont également liées à la description de la tâche. Si par exemple le robot doit avancer ou tourner dans un environnement terreste, il doit être équipé par des roues. Nous pouvons alors définir des hypothèses sur les moyens de locomotion requis pour l’accomplissement des actions. Une fois ces abstractions identifiées, l’expert du domaine combine ensuite les abstractions algorithmiques et les abstractions non algorithmiques afin de définir un algorithme générique. 2.2 Identification de l’algorithme générique Dans cette étape, un expert en robotique organise les abstractions identifiées précédemment. Un algorithme générique est une séquence d’instructions qui utilisent les abstractions non algorithmiques et les abstractions algorithmiques. Cette 103Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique combinaison se fait sous forme d’algorithme ou sous forme de machine à états finis représentant la tâche étudiée. Étant donné que les abstractions définissent des hypothèses sur les capacités du robot à percevoir ou à agir dans son environnement, l’algorithme générique reste stable pour une catégorie de robots. De cette façon, on peut faire varier les implantations des abstractions sans avoir à modifier l’algorithme générique. Pour une tâche de robotique donnée, on ne peut pas définir un algorithme générique qui restera stable pour toutes les catégories des capteurs et des effecteurs car il faut que ces derniers correspondent aux hypothèses définies sur les abstractions. Pour résumer, notre approche comporte deux étapes principales : 1. L’identification des abstractions 2. La définition de l’algorithme générique Dans ces deux étapes, un expert de robotique doit intervenir afin de combiner les abstractions ou les valider. Ainsi, les abstractions obtenues seront extraites à partir d’exemples concrets et pourront être réutilisées. Nous verrons dans la section suivante comment ces abstractions doivent être organisées au niveau de l’implantation. 2.3 Organisation de l’implantation L’algorithme générique défini en fonction des abstractions est complètement indé- pendant des détails des capteurs, des effecteurs et des middleware. Aucune propriété spécifique à un middleware ne doit être utilisée au sein de l’application qui implante l’algorithme générique (c.-à-d. protocole de communication, types spécifiques, etc.). On voudrait maintenant organiser l’implantation des abstractions non algorithmiques et des abstractions algorithmiques. Une abstraction a une sémantique opérationnelle bien définie. Elle peut avoir un type de retour, dans ce cas, le type de retour est un type abstrait (c.-à-d. indépendant des types retournés par le matériel et des types fournis par les middleware). Un type abstrait désigne un type primitif (booléen, entier, réel, etc.) ou un type de données ayant des propriétés dont les types sont primitifs. Par exemple, le type Point est un type abstrait. Il est caractérisé par trois coordonnées x, y et z de types réels. Comme nous l’avons défini précédemment, les abstractions algorithmiques sont de plus haut niveau que les abstractions non algorithmiques et dépendent généralement de celles-ci. Il est donc essentiel des faire varier les abstractions non algorithmiques 104V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique indépendamment des abstractions algorithmiques afin d’éviter les situations où on pourrait avoir une explosion combinatoire. Dans ce qui suit, nous présentons d’abord l’implantation des abstractions non algorithmiques puis l’implantation des abstractions algorithmiques et de l’algorithme générique. 2.3.1 Implantation des abstractions non algorithmiques Afin d’implanter les abstractions non algorithmiques, il faudrait tout d’abord rassembler les abstractions qui se basent sur le (ou les) même(s) capteur(s) physique(s) ou qui agissent sur le (ou les) même(s) effecteur(s) physique(s). Pour ce faire, nous nous proposons d’utiliser des adaptateurs des capteurs qui implantent les abstractions basées sur un ou plusieurs capteurs. L’implantation des abstractions au sein des adaptateurs permettra de convertir les données physiques capturées par les capteurs en données de types abstraits séparant ainsi l’acquisition des données de leurs traitements. Un adaptateur de capteur peut prendre en entrée différents capteurs pour calculer la donnée requise en sortie, dans ce cas il s’agit d’un adaptateur mixte. De la même façon, nous utiliserons des adaptateurs pour les effecteurs qui permettent d’implanter les actions du robot. L’implantation des actions consiste à spécifier les commandes que les effecteurs doivent exécuter. Pour résumer, les adaptateurs permettent d’implanter les abstractions du matériel en convertissant les données physiques en données abstraites ou en convertissant les actions en commandes spécifiques comme le montre la figure V.44. Notons que les adaptateurs sont les seules parties de l’application qui sont spé- cifiques aux capteurs et aux effecteurs physiques. Au niveau de l’implantation, il faut spécifier certains paramètres de configuration du matériel utilisé. Les seules informations requises par le code de l’application sont les abstractions. Il ne doit pas y avoir de lien permanent entre un adaptateur et le code de l’application. Ce lien ne doit être spécifié qu’au niveau de la configuration de l’application (c.-à-d. au niveau du déploiement) afin de rendre l’application la plus indépendante possible des détails du matériel et de permettre une flexibilité pour les changements de ce dernier. La fréquence d’exécution des composants, la nature des données requises (avec ou sans Buffer par exemple), le mécanisme de transport en particulier et plus généra- 105Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Figure V.44 – Implantation des abstractions non algorithmiques : adaptateurs lement les paramètres de configuration sont délégués aux middleware. Chacun a un moyen de configuration propre à lui donc cette partie n’est pas spécifiée au niveau de l’implantation des abstractions mais au niveau du déploiement. Le design pattern Bridge [120] permet de séparer les abstractions de leurs implantations dans différentes hiérarchies de classes. Les abstractions sont définies dans une interface correspondant aux opérations qui doivent être fournies adaptateurs. Les adaptateurs implantent ensuite ces opérations comme le montre la figure V.45. L’avantage de cette approche est que le changement des implantations n’affecte pas le reste du code de l’application. De plus, les changements dans l’implantation des abstractions n’ont aucun impact sur le code de l’application. 2.3.2 Implantation des abstractions algorithmiques et de l’algorithme générique Prenons maintenant le cas d’une famille d’algorithmes qui a plusieurs variantes. Il faudrait alors définir des abstractions algorithmiques en plus des abstractions non algorithmiques. 106V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique Figure V.45 – Application du pattern Bridge Nous devons séparer l’implantation des abstractions non algorithmiques de l’implantation des abstractions algorithmiques. Afin d’organiser l’implantation de ces abstractions, nous nous proposons d’utiliser le design pattern Template Method. Le design pattern Template Method (TM) [120] permet la définition d’un squelette d’algorithme comme une template méthode d’une classe abstraite. Cette méthode n’est autre que l’algorithme générique identifié dans l’étape précédente. Les points de variations parmi les variantes d’une famille d’algorithmes sont définis en tant que méthodes abstraites, spécialisées dans chaque sous-classe. Les parties invariantes de l’algorithme sont implantées dans la classe abstraite en tant que méthodes concrètes. Les instructions qui existent dans certaines variantes et pas dans d’autres sont défi- nies en tant que hook methods (avec un corps vide dans la classe abstraite mais qui peut être spécialisé dans les sous-classes) de la classe abstraite. Par conséquent, Chaque variante de l’algorithme est implantée comme une sousclasse de la classe abstraite et les méthodes abstraites correspondant aux variabilités algorithmiques sont implantées dans chaque sous-classe comme le montre la figure V.46. Pour résumer, l’organisation de l’implantation combine les deux design pattern Bride et Template Method afin de séparer les abstractions non algorithmiques de celles algorithmiques. 107Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Figure V.46 – Application du pattern Template Method 3 Application sur la famille d’algorithmes Bug En raison de la variabilité constatée dans les algorithmes de navigation, nous nous sommes intéressés à la famille de navigation Bug [38] où l’environnement du robot est inconnu mais la position du but est connue. Dans cette section, nous commençons d’abord par présenter la famille Bug, nous présenterons par la suite l’application de notre approche sur cette famille. 3.1 La famille d’algorithmes Bug Bug est une famille d’algorithmes de navigation dans un environnement inconnu. Le robot doit se déplacer de sa position de départ vers son but tout en évitant les obstacles sur son chemin vers celui-ci. Dans la famille Bug, le robot contourne les obstacles qu’il rencontre suivant diffé- rentes stratégies. Certains comportements du robot sont réactifs, par exemple, si un obstacle est détecté, le robot contourne l’obstacle. Si le but est atteint, le robot s’arrête, etc. D’autres comportements s’appuient sur des calculs un peu plus élaborés. Par exemple, le contournement de l’obstacle rencontré consiste à maintenir une distance de sécurité par rapport à celui-ci et à chercher un point potentiel pour quitter cet obstacle. Dans ce qui suit, nous donnons une description des algorithmes Bug. 1. Hypothèses sur l’Environnement : Environnement inconnu 2 dimensions : – Un obstacle est un chemin fermé de longueur finie et d’épaisseur non nulle (car l’une des variantes de cette famille utilise l’épaisseur des obstacles dans ses hypothèses). 108V.3 Application sur la famille d’algorithmes Bug – Il existe un nombre fini d’obstacles dans l’environnement 2. Hypothèses sur le robot : (a) Forme : Le robot est un point. (b) Perception : – capacité de détecter les obstacles : capteurs tactiles ou à rayons selon les algorithmes. – localisation parfaite. (c) Action : – s’orienter vers le but. – avancer vers le but. – contourner un obstacle. – s’arrêter. (d) Notations – Données en entrée : qstart, qgoal ; où qstart et qgoal sont respectivement la position de départ et du but du robot – Variables : – q i H , appelé hitPoint dans la littérature, est le point de rencontre d’un obstacle. – q i L , appelé leavePoint dans la littérature, est le point à partir duquel le robot peut quitter l’obstacle rencontré et se dirige de nouveau vers son but. – x est la position courante du robot – distance est la distance par rapport à l’obstacle le plus proche – distM inT oGoal est la distance euclidienne minimale du robot jusqu’au but. – Step épaisseur minimale d’un obstacle. – F = r(θ) est la distance perçue le long d’un rayon r émanant du centre du robot à un angle θ où θ est la direction du but. – direction est la direction du contournement d’obstacle du robot : dans le sens des aiguilles d’une montre (clockwise) ; contre les sens des aiguilles d’une montre (counter-clockwise). – dreach est la distance minimale parmi tous les points perçus par le robot. 109Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique – df ollowed est la distance minimale parmi tous les points autour d’un obstacle et le but. Nous présentons dans les sections suivantes six algorithmes de la famille Bug : Bug1, Bug2, Alg1, Alg2, DistBug et TangentBug. 3.1.1 Bug1 L’algorithme Bug1 [38, 121] est le premier algorithme proposé dans la famille Bug. La description de Bug1 est donnée dans l’algorithme 1. Bug1 se base sur des capteurs tactiles pour la détection d’obstacles. Lorsque le robot rencontre un obstacle, il contourne l’obstacle à gauche (en le maintenant à sa droite) tout en cherchant le point ayant la distance euclidienne minimale par rapport au but. Il effectue un tour complet autour de l’obstacle pour identifier le point optimal. Une fois ce point identifié, il y retourne et reprend son chemin vers le but. Si le but est inatteignable alors le robot s’arrête et termine sa mission. Algorithm 1: Bug1 pseudo-code [38, 121] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; (1) A partir de q i L avancer vers le but jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche tout en cherchant un point y autour de l’obstacle tel que : deuclidian (y, qgoal) est minimale. Si y trouvé, q i L ← y, enregistrer le chemin de q i H vers q i L S’arrêter lorsque q i H est rencontré de nouveau. Suivre le chemin le plus court pour retourner à q i L Si but inatteignable, retourner échec Sinon retourner à l’étape (1). 3.1.2 Bug2 La description de Bug2 est donnée dans l’algorithme 2. Bug2 a été défini initialement en utilisant des capteurs tactiles. Dans Bug2 [121], lorsque le robot rencontre un obstacle, il le contourne à gauche et ne le quitte que s’il trouve un point sur une 110V.3 Application sur la famille d’algorithmes Bug ligne imaginaire appelée M-line passant par son point de départ et le but. Lorsque ce point est trouvé, le robot vérifie que ce point est plus proche que le point où il a rencontré l’obstacle et si le but est atteignable à partir de celui-ci. Si ces conditions sont satisfaites, le robot s’oriente vers son but et continue son chemin vers celui-ci sinon si aucun point correspondant à ces conditions n’est identifié, l’algorithme indique que le but est inatteignable, le robot s’arrête et termine sa mission. Algorithm 2: Bug2 pseudo-code [38, 121] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; (1) A partir de q i L avancer vers le but en suivant la ligne (qstart,qgoal) jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) un nouveau point y est trouvé sur la ligne (qstart, qgoal) tel que y est plus proche du but que q i H Si but atteignable à partir de y, q i L ← x, retourner à l’étape (1) Sinon d(q i H, qgoal) ← d(x, qgoal), continuer à contourner l’obstacle. 3.1.3 Alg1 Alg1 [122, 123] est une extension de Bug2. Sa description est donnée dans l’algorithme 3. Comme Bug1 et Bug2, Alg1 a été défini dans la littérature avec des capteurs tactiles. À la différence de Bug2, Alg1 enregistre tous les hit points et les leave points qu’il a rencontré sur la M-line. L’identification d’un leave point dans Alg1 est similaire à celle dans Bug2 (c.-à-d. un leave point est un point sur la M-line plus proche que tous les points déjà visités). Dans Alg1, lorsque le robot rencontre un ancien point visité, il retourne au dernier hit point. Une fois le dernier hit point atteint, il contourne l’obstacle dans la direction contraire à sa direction initiale (c.-à-d. contournement à droite) toujours à la recherche d’un leave point potentiel. 111Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Algorithm 3: Alg1 pseudo-code [122] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; (1) A partir de q i L avancer vers le but en suivant la ligne (qstart,qgoal) jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) un nouveau point y est trouvé sur la ligne (qstart, qgoal) tel que y est plus proche du but que q i H et le but est atteignable à partir de y, q i L ← x, retourner à l’étape (1). (C) q j H ou q j L rencontré tel que (j < i), retourner à q i H et à partir de q i H contourner l’obstacle à gauche. Cette règle ne peut pas être répétée avant qu’un nouveau q i L soit défini. 3.1.4 Alg2 Alg2 [124] est une extension de Alg1. Sa description est donnée dans l’algorithme 4. Alg2 se base aussi sur des capteurs tactiles. Le robot ne se base plus sur la condition de la M-line pour quitter l’obstacle rencontré mais sur une nouvelle condition qui consiste à trouver le premier point ayant la distance minimale par rapport au but et à partir duquel le but est atteignable. Le robot peut quitter l’obstacle sur ce point et continue son chemin vers le but. 3.1.5 DistBug Dans DitBug [125], le robot utilise une nouvelle donnée introduite par l’utilisateur ainsi que des capteurs de distance. Cette donnée est l’épaisseur minimale du mur d’un obstacle appelée STEP. Le robot utilise ses capteurs de distance et l’épaisseur minimale des obstacles présents dans l’environnement pour trouver un point qui est plus proche du but, à une valeur STEP près, que tous les points déjà visités. La description de DistBug est présentée dans l’algorithme 5. 112V.3 Application sur la famille d’algorithmes Bug Algorithm 4: Alg2 pseudo-code [124] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; double distM inT oGoal ← deuclidian (qstart, qgoal) (1) A partir de q i L avancer vers le but en suivant la ligne (qstart,qgoal) en mettant à jour distM inT oGoal si deuclidian (x, qgoal) < distM inT oGoal, jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche, vérifier si deuclidian (x, qgoal) < distM inT oGoal, si oui alors distM inT oGoal ← deuclidian (x, qgoal) jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) un nouveau point y est trouvé tel que deuclidian (y, qgoal) < distM inT oGoal et le but est atteignable à partir de y, q i L ← y, retourner à l’étape (1). (C) q j H ou q j L rencontré tel que (j < i), retourner à q i H et à partir de q i H contourner l’obstacle à gauche. Cette règle ne peut pas être répétée avant qu’un nouveau q i L soit défini. Algorithm 5: DistBug pseudo-code [125] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; double distM inT oGoal ← deuclidian (qstart, qgoal) ; double Step ← userData (1) A partir de q i L avancer vers le but en mettant à jour distM inT oGoal si deuclidian (x, qgoal) < distM inT oGoal, jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche, vérifier si deuclidian (x, qgoal) < distM inT oGoal, si oui alors distM inT oGoal ← deuclidian (x, qgoal) jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) deuclidian (x, qgoal) - F <= 0, c-à-d que le but est visible à partir de x, q i L ← x, retourner à l’étape (1). (C) deuclidian (x, qgoal) - F <= distM inT oGoal- Step alors q i L ← x, retourner à l’étape (1). 113Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 3.1.6 TangentBug L’algorithme Tangent Bug [126] (voir algorithme 6) requiert l’utilisation de capteurs de distance. À partir de n’importe quelle position, le robot doit récupérer sa distance par rapport à l’obstacle le plus proche le long d’un rayon r émanant du centre du robot à un angle θ [] tel que : distance = ϕ(x, θ) = min α∈[O,∞) d(x, x + α   cos θ sin θ  ) (V.1) tel que x + α   cos θ sin θ   ∈ ∪iBoundary(Oi) (V.2) Cette distance permet au robot de calculer les points discontinuités autour d’un obstacle. Les points de discontinuité sont des points situés sur l’obstacle détectés par les rayons des capteurs du robot et dont la valeur de la distance indique u’un intervalle de valeurs est fini et qu’un autre intervalle a commencé. Pour chaque point de discontinuité, l’algorithme calcule la distance heuristique qui est égale à la distance du robot vers un point de discontinuité et de ce point de discontinuité vers le but : dheuristic = d(x, Pi) + d(Pi , qgoal); où x est la position courante du robot comme défini plus haut et Pi est un point de discontinuité. À chaque itération, le robot cherche le point ayant la distance heuristique minimale parmi tous les points de discontinuité et se dirige vers ce point. À partir de ce point, le robot commence à effectuer le contournement d’obstacle en gardant la même direction que celle qu’il a suivi pour aller à ce point. Il calcule maintenant les deux distances dreach et df ollowed et s’arrête lorsque dreach < df ollowed pour se diriger vers son but de nouveau. 3.2 Identification des abstractions de la famille Bug Les algorithmes Bug sont très similaires fondamentalement mais diffèrent dans certains points. Il existe deux comportements principaux dans les algos de Bug : éviter les obstacles (obstacle avoidance) et se diriger vers le but (motion to goal). 1. Le comportement Motion-to-Goal. Le robot s’oriente vers son but et avance en suivant la direction qui le mène vers celui-ci. Selon les algorithmes, 114V.3 Application sur la famille d’algorithmes Bug Algorithm 6: TangentBug pseudo-code [126] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; double distM inT oGoal ← deuclidian (qstart, qgoal) (1) A partir de q i L avancer vers le but, jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Calculer points de discontinuités autour de l’obstacle rencontré. Parmi les points de discontinuité, chercher le point ayant la distance heuristique minimale et la direction vers ce dernier. Le robot se déplace jusqu’à ce point jusqu’à ce que la distance heuristique ne diminue plus. Contourner l’obstacle dans la même direction, jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) dreach < df ollowed, q i L ← y, retourner à l’étape (1). Motion-To-Goal peut être trivial ou avec un enregistrement de données qui seront utiles pour le reste de l’algorithme comme le cas de l’algorithme DistBug présenté précédemment par exemple. En effet, dans DistBug le robot doit avancer vers son but en mettant à jour sa distance euclidienne minimale par rapport au but. Cette variable sera utilisée dans la suite de l’algorithme lorsque le robot rencontrera un obstacle pour identifier le meilleur point qui lui permettra de quitter cet obstacle. Nous retrouvons le comportement trivial de Motion-To-Goal dans tous les algorithmes de Bug où il faut que le robot avance simplement vers son but. Le robot s’arrête, quitte ce mode et bascule vers le mode Obstacle-Avoidance dès qu’un obstacle est détecté. 2. Le mode Obstacle-Avoidance : Contrairement à Motion-To-Goal, ObstacleAvoidance est différent d’un algorithme à l’autre mais se base sur les mêmes étapes pour l’identification d’un leave point. Dans tous les algorithmes de Bug, lorsqu’un obstacle est détecté, le robot enregistre sa position courante et calcule dans certains cas des données supplémentaires qu’il va utiliser tout au long de l’algorithme. En effet, étant donné que l’environnement inconnu, la position du robot permet de savoir s’il a atteint la position de son but en calculant la distance euclidienne par rapport à celui-ci. D’autre part, sa po- 115Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique sition est utile lorsqu’il s’agit de retenir la position d’un point par lequel il est passé. Après l’enregistrement des données, le robot contourne l’obstacle jusqu’à ce que la condition d’évitement d’obstacle définie par l’algorithme soit satisfaite (c.-à-d. leave point identifié) ou lorsque l’algorithme indique que le but est inatteignable. Si la condition de l’algorithme est satisfaite, le robot se dirige vers le leave point identifié, et reprend son chemin vers le but en rebasculant vers le comportement Motion-To-Goal. Le robot change de comportement si un obstacle est détecté ou si un point potentiel (c.-à-d. leave Point) qui permet de quitter l’obstacle a été identifié. L’identification de ce point potentiel représente le point de variabilité principal des algorithmes de Bug. La description informelle de Bug cache la variabilité algorithmique et celle du matériel. La variabilité du matériel a un impact sur la détection d’obstacles et sur la localisation en raison de leurs dépendances des capteurs du robot utilisé. Quant à la variabilité algorithmique, elle est liée à l’identification d’un leave point pour quitter l’obstacle rencontré. En se basant sur une démarche dirigée par les buts et sur une étude détaillée des algorithmes de Bug, on a identifié les abstractions suivantes : – Motion-To-Goal : Le robot doit pouvoir se positionner face à son but et être capable d’avancer vers celui-ci : faceGoal(Point qgoal), goAhead(double speed) – Le robot s’arrête : halt() – La détection d’obstacle sur le chemin du robot : bool obstacleInFrontOfTheRobot() interroge sur les capteurs sur la présence d’un obstacle en face du robot. – La position courante : Point getPosition() – Le contournement d’obstacles consiste à suivre une direction (clockwise ou counter-clockwise) en réduisant l’écart entre la distance du robot par rapport au mur suivi et la distance de sécurité comme le montre la figure V.47. Cette abstraction est appelée wallFollowing(bool direction). – double getSafeDistance() indique la distance minimale que le robot doit maintenir par rapport à l’obstacle rencontré. – obstacleOnTheRight(), bool obstacleOnTheLeft() permettent de situer l’obstacle le plus proche détecté à gauche ou à droite du robot. Imaginons le cas où les capteurs situés à gauche détectent un obstacle et les capteurs droits 116V.3 Application sur la famille d’algorithmes Bug Figure V.47 – Le contournement d’obstacle : (1) le robot à droite doit tourner à droite pour se rapprocher de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle. (2) le robot à gauche doit tourner à gauche pour s’éloigner de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle détectent un obstacle, il est important de savoir de quel coté se trouve l’obstacle le plus proche. Ces abstractions ne sont pas spécifiques aux capteurs à rayons. Vu qu’elles se présentent sous forme de requêtes qui ne sont pas spécifiques à un type particulier elle peut aussi bien être utilisée pour des capteurs tactiles que pour des capteurs à rayons. Par exemple dans le cas des capteurs à rayons, elles désignent les cadrans à droite et à gauche du robot sur la figure V.48. Ces cadrans peuvent varier selon les champs de vision des capteurs et leurs portées. Cette figure représente le cas où le robot est un point. Figure V.48 – La détection d’obstacle devant, à gauche et à droite du robot avec des capteurs de distance – double getRightDistance(), double getLeftDistance() : afin de maintenir une distance de sécurité par rapport au mur qui représente l’obstacle, nous devons savoir quelle est la distance par rapport à l’obstacle le 117Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique plus proche à gauche ou à droite (selon la direction suivie) comme le montre la figure V.49. La distance retournée est la moyenne des distances détectées par les rayons du capteur gauche (ou droit) du robot par rapport à l’obstacle le plus proche. Figure V.49 – Exemple de getDistanceRight : la distance retournée est la moyenne des distances détectées parmi tous les rayons émanant du capteur droit du robot – Trouver un leave Point : identifyLeavePoint(bool direction, Point robotPosition, Point goalPosition). La recherche d’un leave point consiste à contourner l’obstacle tout en vérifiant les conditions définies par l’algorithme pour l’identification de celui-ci. La stratégie d’évitement d’obstacle peut se baser sur une décision locale (choisir le premier point qui répond aux conditions de l’algorithme) ou une décision globale (choisir le point parmi tous les points visités qui répond au mieux aux conditions de l’algorithme). Par consé- quent, nous avons identifié une abstraction qui sera appliquée à chaque point visité autour de l’obstacle et qui varie d’un algorithme à un autre : findLeavePoint(Point robotPosition, Point hitPoint, Point goalPosition). Les données enregistrées varient aussi d’un algorithme à l’autre, dans certains algorithmes on n’enregistre que le point de rencontre de l’obstacle. Dans d’autres, on enregistre les points perçus par le robot ayant une distance heuristique minimale. C’est pour cette raison qu’on a identifié l’abstraction computeData(Point RobotPos) Le code de identifyLeavePoint est donné dans l’algorithme 7. Algorithm 7: Identify leavePoint method identifyLeavePoint(Bool direction, P oint robotP os, P oint goalP os){ computeData(robotPos) ; wallFollowing(direction) ; findLeavePoint(robotPos, getLastHitPoint()) ; } 118V.3 Application sur la famille d’algorithmes Bug – Leave point identifié : bool isLeavePointFound() indique si un leave point a été identifié. – Recherche Complète bool researchComplete(Point robotPosition, Point hitPoint, Point goalPosition) : Dans le cas où la stratégie appliquée se base sur une décision locale, la recherche est terminée se traduit par l’identification d’un leave point qui répond aux conditions de l’algorithme. En d’autres termes, research complete est équivalent à leavePointidentified dans le cas d’une décision locale. Lorsqu’il s’agit d’une décision globale, la recherche n’est terminée que lorsque le robot a effectué un tour complet autour de l’obstacle afin d’être sûr qu’il a identifié le meilleur point qui répond aux conditions de l’algorithme. – Aller au leave point goToPoint(Point leavePoint) : Une fois le leave point identifié, le robot se dirige vers celui-ci. Ceci constitue un point de variation parmi les algorithmes car le robot peut par exemple suivre le chemin le plus court pour aller vers ce point ou appliquer d’autres stratégies. – but inatteignable : Cette condition est vérifiée si aucun leave point n’a été identifié après que le robot ait effectué un tour complet autour de l’obstacle rencontré (not isleavePointFound() and completeCycleAroundObstacle(Point robotPosition,Point hitPoint)). – but atteint : Selon le but de l’algorithme, nous définission une marge d’erreur qui indique si le robot doit atteindre son but ou s’il doit s’arrêter peu avant de l’atteindre : bool goalReached(Point robotPosition, Point goalPosition, double err). Ces abstractions combinent les abstractions algorithmiques et les abstractions non algorithmiques. Nous pouvons alors les classifier comme suit : 1. Abstractions non algorithmiques : les paramètres de configuration des capteurs sont définis au niveau du déploiement et les caractéristiques spécifiques comme par exemple le nombre de rayons des capteurs, leurs portée, etc. sont spéci- fiées au niveau des adaptateurs. Etant donné que le robot est considéré comme un point dans les hypothèses de la famille Bug, nous n’allons pas prendre en compte la position des capteurs sur le robot mais simplement de leur emplacement (devant, derrière, à gauche ou à droite) en supposant qu’ils sont placés au même niveau que la plateforme du robot. Les abstractions non algorithmiques sont classées dans 2 sous-catégories : – Abstractions non algorithmiques en tant que requêtes sur l’environnement 119Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique nécessitant des capteurs à rayons : – double getSafeDistance() – double getLeftDistance() – double getRightDistance() Nous avons vu que ces abstractions servent au contournement d’obstacle. Elles permettent de retourner la distance à gauche ou à droite du robot par rapport à l’obstacle le plus proche. C’est pour cette raison que nous avons besoin de capteurs à rayons pour pouvoir les implanter et faire des regroupements des rayons des capteurs. – Abstractions non algorithmiques en tant que requêtes générales : – bool obstacleInFrontOfTheRobot() – bool obstacleOnTheLeft() – bool obstacleOnTheRight() Ces abstractions interrogent les capteurs afin de savoir s’il y a un obstacle devant, à droite ou à gauche du robot. Concrètement ces abstractions pourrait être utilisées pour des capteurs à rayons aussi bien que pour des capteurs tactiles ou même pour d’autres types de capteurs tant qu’ils sont capables de founir ces informations. Il n’y a donc aucune contrainte sur ces abstractions qui requiert un type de capteurs particulier. – Abstractions non algorithmiques en tant qu’actions de haut niveau : – halt() – faceGoal(Point goalPosition) – goAhead(double speed) – turnRight(double translation, double angle) – turnLeft(double translation, double angle) – goToPoint(Point leavePoint) – motionToGoal() 2. Abstractions algorithmiques : – righHand() – leftHand() – wallFollowing(bool direction) – identifyLeavePoint(bool direction, Point robotPosition, Point goalPosition) – findLeavePoint(Point robotPosition, Point hitPoint, Point goalPosition) – bool isLeavePointFound() – bool researchComplete(Point robotPosition, Point hitPoint, Point goalPosi- 120V.3 Application sur la famille d’algorithmes Bug tion) – bool completeCycleAroundObstacle(Point robotPosition,Point hitPoint) – goalReached(Point robotPosition, Point goalPosition, double err) 3.3 Identification de l’algorithme générique de la famille Bug L’algorithme générique est une combinaison des abstractions identifiées dans la section précédente comme une séquence d’instructions. Notre algorithme générique est presenté dans l’algorithme 8. Algorithm 8: Algorithme générique de la famille Bug Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles input : Position of Start (qstart), Position of Target (qgoal) Initialisation: robotPos ← getPosition() ; direction ← getDirection() ; if goalReached(robotPos) then EXIT_SUCCESS ; end else if obstacleInFrontOfTheRobot() == true then identifyLeavePoint (direction, robotPos, goalPos); if leavePointFound() && researchComplete(robotPos, getHitPoint(), qgoal) then goToPoint(getLeavePoint()); faceGoal() ; end else if completeCycleAroundObstacle(robotPos, getHitPoint()) && !leavePointFound() then EXIT_FAILURE ; end end else motionToGoal() ; end 121Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 3.4 Organisation de l’implantation de la famille Bug Comme nous l’avons mentionné précédemment, le design pattern Template Method permet de gérer le problème de la variabilité en proposant de définir les sé- quences d’un algorithme dans une template méthode d’une classe abstraite écrite en fonction d’abstractions qui seront implantées dans les sous classes de celle-ci. D’autre part, le design pattern Bridge permet de séparer les abstractions de leur implantation dans différentes hiérarchies de classes. Chaque variante de l’algorithme est alors implantée dans une sous-classe de la classe abstraite. Quant aux abstractions du matériel, elles sont définies dans des interfaces et implantées par la suite par les adaptateurs correspondant aux capteurs virtuels et aux effecteurs virtuels. Nous avons besoin d’un adaptateur de capteurs qui va implanter les abstractions suivantes : – double getSafeDistance() – bool obstacleInFrontOfTheRobot() – bool obstacleOnTheLeft() – bool obstacleOnTheRight() – double getLeftDistance() – double getRightDistance() Cet adaptateur peut prendre en entrée des données d’un ou de plusieurs capteurs physiques capables de founir les informations dont on a besoin. Les paramètres de configuration des capteurs sont définis au sein de ces adaptateurs. De plus, nous avons besoin d’un adaptateur pour les effecteurs du robot qui va implanter les abstractions suivantes : – halt() – faceGoal(Point q_goal) – goAhead(double speed) – turnRight(double translation, double angle) – turnLeft(double translation, double angle) Prenons maintenant le cas d’un adaptateur Laser ayant un angle de perception de 180° et une portée de 2 mètres. Il faut arriver à extraire les informations de ce capteur afin de les adapter aux besoins des requêtes sur l’environnement. Nous avons alors défini une fonction propre à l’adaptateur appelée getDistanceSensors() qui s’occupe de regrouper les rayons en se basant sur leur nombre et leurs positions (voir 122V.3 Application sur la famille d’algorithmes Bug listing V.8). 1 vector LaserAdapter :: getDistanceSensors (){ 2 sensor_msgs :: LaserScan msg ; 3 vector rays ; 4 laser_port . read ( msg ); 5 int j = 18; 6 int nbRays = samples / nb_sensors ; 7 for(int i =0; i < nb_sensors ; i ++){ 8 rays . push_back ( std :: accumulate ( msg . ranges . begin ()+ j - nbRays , 9 msg . ranges . begin ()+ j , 0)); 10 j = j + nbRays ; 11 } 12 return rays ; 13 } Listing V.8 – implantation de getDistanceSensors() Les autres abstractions implantées dans cet adaptateur utilisent alors ce nouveau regroupement des rayons du capteur afin de renvoyer le résultat de la requête. Par exemple l’implantation de obstacleOnTheLeft() (listing V.9) qui indique si l’obstacle le plus proche est situé à gauche du robot utilise ce regroupement des rayons donné par la fonction getDistanceSensors(). 1 bool LaserAdapter :: obstacleOnTheLeft (){ 2 sensor_msgs :: LaserScan msg ; 3 vector rays = getDistanceSensors (); 4 double sensorLeft = rays [4]; 5 double sensorLeftFront = rays [3]; 6 double sensorRightFront = rays [1]; 7 double sensorRight = rays [0]; 8 9 return ( sensorRight + sensorRightFront > 10 sensorLeft + sensorLeftFront ); 11 } Listing V.9 – implantation de l’abstraction obstacleOnTheLeft() L’architecture de notre application est présentée dans la figure V.50. 123Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Figure V.50 – Extrait du digramme de classe de la famille Bug parler de l’implantion de main droite et main gauche : réduire l’écart pour maintenir le mur à droite ou à gauche. Mettre figure mur et orientation robot Les sources correspondant aux différentes variantes des algorithmes sont disponibles sur https://github.com/SelmaKchir/BugAlgorithms. 3.5 Expérimentations et Validation Nous avons choisi d’implanter notre application sous OROCOS en utilisant une architecture à base de composants. La classe abstraite BugAlgorithm contient la template method représentant l’algorithme générique. Chaque variante de la famille Bug est un composant OROCOS qui implante les méthodes abstraites et qui peut implanter les hook méthodes de la classe abstraite. Des interfaces correspondant aux abstractions du matériel sont également définies afin de préciser les services qui doivent être fournis par les adaptateurs. Chaque adaptateur est un composant OROCOS lié à un composant matériel (capteur ou actionneur). Aucun détail spécifique au matériel n’est présenté dans le code de l’application. Les composants sont déployés dans des libraries OROCOS et les liens entre les composants de contrôle et les composants matériels ne sont spécifiés qu’au niveau de 124V.3 Application sur la famille d’algorithmes Bug l’exécution à travers un fichier de configuration. Cela garantit une indépendance par rapport aux détails de bas niveau. L’architecture d’une application correspondant à la variante Bug1 de la famille Bug est présentée dans la figure V.51. Plusieurs études Figure V.51 – Architecture de l’application correspondant à Bug1 comparatives sur les performances des variantes de la famille Bug ont été réalisées dans [127]. Dans cette section, notre objectif n’est pas de comparer ces variantes mais de prouver que chaque variante de Bug peut être implantée avec notre algorithme générique. Les six variantes présentées précédemment : Bug1 [38], Bug2 [121], Alg1 [122], Alg2 [124], DistBug [125] et TangentBug [126] ont été correctement implantées à partir de notre algorithme générique sous OROCOS. 3.5.1 Environnement de simulation : Stage-ROS Stage est un environnement de simulation deux dimensions qui fait partie de l’outil de simulation Player/Stage. Il fournit des modèles simples de plusieurs dispositifs. Stage a été intégré à ROS afin de permettre la simulation de programmes développés dans ce middleware ou développés dans d’autres middleware intégrés à ROS. Le noeud stageros simule un monde défini dans un fichier .world, qui contient les détails des capteurs, des robots et des obstacles dans le monde simulé. Stageros étant un noeud de ROS, il est possible de le faire communiquer avec d’autres middleware intégrés à ROS comme OROCOS. Nous pouvons ainsi simuler notre application implantée avec OROCOS avec Stage en passant pas les messages ROS pour l’intéraction avec les capteurs et les effecteurs physiques du robot simulé. 125Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 3.5.2 Configurations des environnements et des capteurs La simulation a été réalisée au sein de trois environnements. Le premier environnement présenté dans la figure V.52 nous permet de tester si le robot est capable d’atteindre son but et si l’abstraction goalIsReachable() fonctionne correctement. Figure V.52 – Environnement1 : but inatteignable Le second environnement présenté dans la figure V.53 est un environnement de simulation simple avec un seul obstacle. Le but de l’utilisation de cet environnement est de tester simplement le contournement d’obstacle et la capacité du robot d’identifier un point pour le quitter. Nous ne pouvons pas distinguer le comportement du robot dans les algorithmes Bug2 et Alg1 à travers cet environnement car le robot ne revisite pas de points qu’il a déjà visités. Figure V.53 – Environnement2 : Environnement avec un seul obstacle 126V.3 Application sur la famille d’algorithmes Bug Nous avons alors défini un troisième environnement V.54 pour pouvoir distinguer les trajectoires d’exécution du robot dans les environnement Bug2 et Alg1 et dans les autres algorithmes. Concernant les capteurs, nous avons utilisé deux configurations de robots : le preFigure V.54 – Environnement3 : Environnement avec plusieurs obstacles mier avec un capteur Laser et le deuxième avec trois capteurs infrarouges. La première configuration a été effectuée en utilisant un capteur Laser ayant un angle de perception de 180 degré et dont les rayons de cet angle ont une portée variant de 0.02 mètres et allant jusqu’à 4 mètres. Pour la localisation, nous avons utilisé un GPS (en supposant que l’environnement de simulation est à l’extérieur). La deuxième configuration a été réalisée en utilisant trois capteurs infrarouges placés sur l’avant, sur la gauche et sur la droite du robot par rapport à son axe central. Ces capteurs ont un champs de vision (Field Of View) de 26 degré et une portée qui va jusqu’à 2 mètres. Afin de valider notre démarche nous avons testé nos algorithmes avec deux configurations différentes dans ces trois environnements. 3.5.3 Résultats Les résultats de simulation montrent une différence de trajectoire entre la première et la deuxième configuration. En effet, la trajectoire suivie par le robot ayant un capteur Laser est différente de celle suivie par le robot ayant les capteurs infrarouges. Ceci est dû au temps d’interprétation des données et aux configurations différentes. Cependant dans tous les cas le robot termine sa mission et ar- 127Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique rive à atteindre son but. Concernant les différents algorithmes, ils sont correctement exécutés dans ces trois environnements. Les résultats de simulation sont disponibles sur le lien : https://github.com/SelmaKchir/BugAlgorithms/wiki/ Implementing-Bug-Algorithms-variants 4 Discussion Nous avons démontré que les abstractions identifiées permettent d’être réutilisées indépendamment du robot utilisé grâce à l’utilisation des adaptateurs des capteurs et des effecteurs. Ces abstractions ont une sémantique car elles ont été définies à partir pour une tâche de robotique. Si nous souhaitons ajouter une nouvelle variante de la famille Bug, il faut implanter les abstractions algorithmiques, les abstractions non algorithmiques quant à elles ne doivent pas forcément être implantées s’il n’y a pas de changement de robot. Dans le cas contraire, il faut ajouter un adaptateur pour les abstractions non algorithmiques. Concernant les requêtes sur l’environnement, nous avons distingué des requêtes générales indépendantes de la classe des capteurs utilisés (range, tactiles, etc.) et des requêtes spécifiques aux capteurs à rayons. Si nous souhaitons supporter les capteurs tactiles par exemple, il faudrait alors changer l’implantation de l’abstraction wallFollowing vu qu’elle utilisait les abstractions getLeftDistance(), getRightDistance(), getSafeDistance() qui s’appuient sur les capteurs à rayons. Les abstractions algorithmiques résistent aux variations non algorithmiques. En effet, si on prend l’exemple de l’abstraction identifyLeavePoint (voir algorithme 7), même si on change la façon de contourner l’obstacle et les capteurs qu’on veut utiliser, l’implantation de cette abstraction reste inchangée. Nous avons besoin d’enregistrer plus de données donc on peut les ajouter au niveau de l’implantation de cette variante... L’ajout est alors facile, il suffit de comprendre l’algorithme et de l’intégrer. L’algorithme générique, quant à lui, est stable, il n’y a pas de changement à faire au sein de l’algorithme générique si on veut ajouter une nouvelle variante ou un nouveau matériel. 128V.5 Conclusion 5 Conclusion Dans ce chapitre, nous avons proposé une approche qui permet de produire des abstractions algorithmiques, des abstractions non algorithmiques et un algorithme générique défini en fonction de ces dernières. Nous avons présenté également comment implanter ces abstractions de façon à les faire varier dans l’application sans avoir à modifier l’algorithme générique et sans qu’il n’y ait d’explosion combinatoire. En effet, nous avons séparé l’implantation des abstractions non algorithmiques de celles algorithmiques étant donné que ces dernières sont de plus haut niveau et sont spécifiques à la tâche qu’on veut implanter. Cependant, l’inconvénient d’une telle approche est qu’il faudrait définir autant d’adaptateurs que de capteurs ou d’effecteurs physiques. Afin d’assurer la réutilisabilité de ces abstractions, on pourrait enrichir notre démarche par une librairie d’adaptateurs qui convertissent les données à partir de dispositifs physiques vers les abstractions requises (dans le cas des capteurs) ou inversement (dans le cas des effecteurs). Cette librairie pourrait compléter l’ontologie du domaine proposée dans le cadre du projet PROTEUS en apportant une sémantique aux abstractions définies. 129Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 130Conclusion générale et perspectives Le projet PROTEUS a constitué le contexte général de cette thèse dont l’objectif principal est de faciliter le développement des applications de robotique et les rendre résistantes vis-à-vis aux changements des détails de bas niveau. Ce travail de thèse a alors consisté à : 1. Choisir des abstractions indépendantes des plateformes de robotique mobile pour représenter le contrôle et la communication d’une application ; 2. traduire les abstractions de RobotML vers le middleware OROCOS à travers un générateur de code ; 3. proposer une démarche descendante pour rendre les algorithmes résistants aux changements des détails de bas niveau. Afin de faciliter le développement des applications de robotique, il faudrait permettre aux roboticiens de manipuler des concepts qu’ils ont l’habitude d’utiliser pour le développement de leurs applications. Pour ce faire et afin de traiter le point (1) présenté ci-dessus, nous avons étudié les différents concepts utilisés en robotique. Pour l’aspect contrôle, nous permettons la modélisation de plusieurs types de contrôle (à boucle fermée ou à boucle ouverte) à travers des machines à états finis. Pour l’aspect communication, nous permettons la spécification d’un échange de données synchrone ou asynchrone entre les composants d’une application ainsi que la communication à travers des services. Les abstractions de RobotML sont proposées à travers un éditeur graphique offrant ainsi une facilité d’utilisation aux roboticiens et même à des simples utilisateurs qui ne sont pas experts en robotique. À partir des modèles représentés avec l’éditeur graphique de RobotML, nous générons le code correspondant vers la plateforme OROCOS. Nous arrivons alors au point (2) ci-dessus. Cette contribution a 131Conclusion générale et perspectives consisté à l’élaboration de règles de transformations des abstractions de RobotML vers les concepts d’OROCOS. La génération de code permet d’accélérer le processus de développement d’une application. En effet, le temps passé dans la phase de conception d’une application avec RobotML est largement inférieur au temps passé à développer une application à partir de zéro. Cette contribution a été validée sur un scénario aérien proposé par l’ONERA. Les abstractions proposées par RobotML sont des abstractions de haut niveau du domaine qui permettent de spécifier les aspects généraux d’une application de robotique : architecture, contrôle et communication. Cependant, elles ne permettent pas de gérer la variabilité liée aux détails de bas niveau des capteurs et des effecteurs d’une part. D’autre part, elles ne permettent pas d’encapsuler les détails algorithmiques d’une application car elles manquent de sémantique opérationnelle. En effet, l’approche adoptée pour la définition des abstractions est une approche qui se base sur les connaissances du domaine pour l’identification des abstractions. Le dernier volet des travaux de cette thèse a été alors de proposer une approche qui permet de définir des abstractions ayant une sémantique opérationnelle. Nous sommes partis de la description d’une tâche de robotique afin d’identifier ce que nous avons appelés des abstractions non algorithmiques et des abstractions algorithmiques. Les abstractions non algorithmiques concernent essentiellement le matériel et se présentent sous forme de requêtes sur l’environnement ou des actions de haut niveau. Les abstractions algorithmiques sont de plus haut niveau que les abstractions non algorithmiques, elles encapsulent les détails algorithmiques relatifs à une sous-tâche de robotique et utilisent les abstractions non algorithmiques. Un expert de robotique combine ensuite ces abstractions afin de définir un algorithmique générique qui résiste aux changements de bas niveau ainsi qu’aux variations algorithmiques. Notre approche a été validée sur une famille d’algorithmes de navigation appelée Bug [38]. Nous avons fait varier les capteurs utilisés ainsi que les stratégies proposées par six variantes de cette famille et nous avons démontré que l’algorithme générique reste inchangé malgré ces variations. Une perspective immédiate de nos travaux serait d’enrichir les abstractions de RobotML avec une librairie d’abstractions contenant celles que nous avons identifiées pour une famille de navigation. Ainsi, il devient possible au niveau de la modélisation d’utiliser des abstractions qu’on sait comment implanter. Une deuxième perspective 132Conclusion générale et perspectives consiste à appliquer notre approche sur une autre étude de cas afin d’identifier davantage d’abstractions. L’implantation de notre approche pour la définition d’un algorithme générique en fonction d’abstractions ayant une sémantique opérationnelle se base sur les patrons de conception Template Method et Bridge. Il n’est pas encore possible avec notre approche de définir des contraintes sur les algorithmes comme par exemple les capteurs requis qui peuvent être des capteurs de distance dans certains cas. Une perspective possible serait d’utiliser les lignes de produits algorithmiques dans ce contexte afin de définir des contraintes sur l’association entre les capteurs requis pour des abstractions algorithmiques particulières. Une ébauche de cette perspective a été réalisée dans le cadre de cette thèse mais les résultats sont insuffisants pour être présentés dans ce travail. Une perspective de recherche à long terme des travaux de cette thèse serait de s’intéresser à un autre sous-domaine de la robotique comme par exemple les robots manipulateurs. À partir de notre expérience avec RobotML, nous pouvons savoir quelles sont les abstractions qui peuvent être réutilisées et celles qu’il faut ajouter afin de faciliter le développement de ce sous-domaine. 133Conclusion générale et perspectives 134Références bibliographiques [1] Ronald C. Arkin. Behavior Based Robotics (Intelligent Robotics and Autonomous Agents). The MIT Press (1998). vii, 7, 8, 13, 14, 15 [2] Mark Strembeck and Uwe Zdun. An approach for the systematic development of domain-specific languages. Softw. Pract. Exper. 39(15), 1253–1292 October (2009). vii, 35, 41, 44, 45 [3] Herman Bruyninckx, Markus Klotzbücher, Nico Hochgeschwender, Gerhard Kraetzschmar, Luca Gherardi, and Davide Brugali. The brics component model : a model-based development paradigm for complex robotics software systems. In Proceedings of the 28th Annual ACM Symposium on Applied Computing, SAC ’13, pages 1758–1764, New York, NY, USA (2013). ACM. vii, 2, 48, 50, 58, 60, 84 [4] Soraya Arias, Florine Boudin, Roger Pissard-Gibollet, and Daniel Simon. ORCCAD, robot controller model and its support using Eclipse Modeling tools. In 5th National Conference on Control Architecture of Robots, Douai, France May (2010). vii, 2, 50, 51, 58, 60 [5] Smartsoft metamodel. http://www.program-transformation.org/pub/ GPCE11/ConferenceProgram/slides-gpce11-steck.pdf. vii, 52 [6] Diego Alonso, Cristina Vicente-Chicote, Francisco Ortiz, Juan Pastor, and Barbara Alvarez. V3CMM : a 3-View Component MetaModel for Model-Driven Robotic Software Development. Journal of Software Engineering for Robotics 1(1), 3–17 (2010). vii, 53, 54, 58, 60 [7] Saadia Dhouib, Nicolas Du Lac, Jean-Loup Farges, Sebastien Gerard, Miniar Hemaissia-Jeannin, Juan Lahera-Perez, Stephane Millet, Bruno Patin, and Serge Stinckwich. Control architecture 135Références bibliographiques concepts and properties of an ontology devoted to exchanges in mobile robotics. In 6th National Conference on Control Architectures of Robots (2011). vii, 65, 67, 68 [8] Roland Siegwart and Illah R. Nourbakhsh. Introduction to Autonomous Mobile Robots. Bradford Company, Scituate, MA, USA (2004). xi, 10, 11 [9] Henrik I. Christensen and Gregory D. Hager. Sensing and estimation. In Bruno Siciliano and Oussama Khatib, editors, Springer Handbook of Robotics, pages 87–107. Springer (2008). xi, 10 [10] Morgan Quigley, Ken Conley, Brian P. Gerkey, Josh Faust, Tully Foote, Jeremy Leibs, Rob Wheeler, and Andrew Y. Ng. Ros : an open-source robot operating system. In ICRA Workshop on Open Source Software (2009). 1, 19, 23 [11] H. Utz, S. Sablatnog, S. Enderle, and G. Kraetzschmar. Miro - middleware for mobile robot applications. Robotics and Automation, IEEE Transactions on 18(4), 493–497 (2002). 1, 19, 25 [12] Douglas Blank, Deepak Kumar, Lisa Meeden, and Holly Yanco. Pyro : A python-based versatile programming environment for teaching robotics. J. Educ. Resour. Comput. 4(3) December (2003). 1, 19, 29, 31 [13] Toby H. J. Collett and Bruce A. Macdonald. Player 2.0 : Toward a practical robot programming framework. In in Proc. of the Australasian Conference on Robotics and Automation (ACRA (2005). 1, 19, 20 [14] Arie van Deursen, Paul Klint, and Joost Visser. Domain-specific languages : an annotated bibliography. SIGPLAN Not. 35(6), 26–36 June (2000). 1, 34, 35, 39, 40, 45, 46 [15] Jean Bézivin. On the unification power of models. Software and Systems Modeling 4(2), 171–188 (2005). 2, 35 [16] Christian Schlegel, Andreas Steck, and Alex Lotz. Model-driven software development in robotics : Communication patterns as key for a robotics component model. Introduction to Modern Robotics (2012). 2, 52, 56, 58, 60 [17] Michael Brady. Artificial intelligence and robotics. Artif. Intell. 26(1) apr (1985). 7 [18] Nils J. Nilsson. A mobius automation : an application of artificial intelligence techniques. In Proceedings of the 1st international joint conference 136Références bibliographiques on Artificial intelligence, IJCAI’69, pages 509–520, San Francisco, CA, USA (1969). Morgan Kaufmann Publishers Inc. 8, 12 [19] Allen Newell, J. C. Shaw, and Herbert A. Simon. Report on a general problem-solving program. In IFIP Congress, pages 256–264 (1959). 8 [20] Robin R. Murphy. Introduction to AI Robotics. MIT Press, Cambridge, MA, USA, 1st edition (2000). 8 [21] A. Elkady and T. Sobh. Robotics middleware : A comprehensive literature survey and attribute-based bibliography. Journal of Robotics 2012 (2012). 9, 19, 20, 31 [22] Jacob Fraden. Handbook of Modern Sensors : Physics, Designs, and Applications (Handbook of Modern Sensors). SpringerVerlag (2003). 9, 10, 11 [23] J.P. Laumond, S. Sekhavat, and F. Lamiraux. Robot motion planning and control chapter Guidelines in nonholonomic motion planning for mobile robots, pages 1–53. Lectures. Notes in Control and Information Sciences 229. Springer, N.ISBN 3-540-76219-1 (1998). 11 [24] David Kortenkamp and Reid G. Simmons. Robotic systems architectures and programming. In Springer Handbook of Robotics, pages 187–206. (2008). 12, 15 [25] Georges Giralt, Raja Chatila, and Marc Vaisset. An integrated navigation and motion control system for autonomous multisensory mobile robots. In IngemarJ. Cox and GordonT. Wilfong, editors, Autonomous Robot Vehicles, pages 420–443. Springer New York (1990). 12 [26] R. Chatila and J. Laumond. Position referencing and consistent world modeling for mobile robots. , 2, pages 138–145 (1985). 12 [27] James S. Albus, Harry G. McCain, and Ronald Lumia. Nasa/nbs standard reference model for telerobot control system architecture (nasrem). (1989). 13 [28] Ronald C. Arkin and Ronald Arkin. Reactive robotic systems, (1995). 13 [29] Maja J. Mataric. Behavior-based control : Examples from navigation, learning, and group behavior. Journal of Experimental and Theoretical Artificial Intelligence 9, 323–336 (1997). 13 [30] Jonathan Connell. A colony architecture for an artificial creature. Technical report, Cambridge, MA, USA (1989). 13, 14 137Références bibliographiques [31] David Zeltzer and Michael B. Johnson. Motor planning : An architecture for specifying and controlling the behaviour of virtual actors. The Journal of Visualization and Computer Animation 2(2), 74–80 (1991). 14 [32] R.A. Brooks. A robot that walks ; emergent behaviors from a carefully evolved network. In Robotics and Automation, 1989. Proceedings., 1989 IEEE International Conference on, pages 692–4+2 vol.2 (1989). 14 [33] Rodney A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation 2(10) (1986). 14 [34] Julio Rosenblatt. Damn : A distributed architecture for mobile navigation - thesis summary. In Journal of Experimental and Theoretical Artificial Intelligence, pages 339–360. AAAI Press (1995). 14 [35] Pattie Maes. The dynamics of action selection. In Proceedings of the 11th international joint conference on Artificial intelligence - Volume 2, IJCAI’89, pages 991–997, San Francisco, CA, USA (1989). Morgan Kaufmann Publishers Inc. 14 [36] Ronald C. Arkin. Path planning for a vision-based autonomous robot. Technical report, Amherst, MA, USA (1986). 15 [37] Ronald Craig Arkin. Towards cosmopolitan robots : intelligent navigation in extended man-made environments. Thèse de Doctorat, (1987). AAI8805889. 15 [38] Vladimir J. Lumelsky and Alexander A. Stepanov. Effect of uncertainty on continuous path planning for an autonomous vehicle. , 23, pages 1616 –1621 dec. (1984). 16, 100, 101, 108, 110, 111, 125, 132 [39] David Bakken. Middleware. Encyclopedia of Distributed Computing (2001). 19 [40] James Kramer and Matthias Scheutz. Development environments for autonomous mobile robots : A survey. Auton. Robots 22(2), 101–132 feb (2007). 19 [41] N. Mohamed, J. Al-Jaroodi, and I. Jawhar. Middleware for robotics : A survey. In Robotics, Automation and Mechatronics, 2008 IEEE Conference on, pages 736–742 (2008). 19, 20 [42] Richard T. Vaughan, Brian P. Gerkey, and Andrew Howard. On device abstractions for portable, reusable robot code. In Proc. of the IEEE/RSJ Intl. Conf. on Intelligent Robots and Systems (IROS), page 2121–2427, Las Vegas, Nevada (2003). 19, 20 138Références bibliographiques [43] ROS : Robot-Operating System. http://www.ros.org/. 19, 23 [44] PYRO : Python Robotics. http://pyrorobotics.com/. 19, 29 [45] William D. Smart. Is a Common Middleware for Robotics Possible ? In IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS’07) Workshop on Measures and Procedures for the Evaluation of Robot Architectures and Middleware November (2007). 23, 99 [46] ROS - Topics. http://wiki.ros.org/Topics. 23 [47] RTT : Real-Time Toolkit. http://www.orocos.org/rtt. 23, 24, 85 [48] ROS - Messages. http://wiki.ros.org/Messages. 24 [49] Corba. http://www.corba.org/. 26 [50] N. Sünderhauf R. Baumgartl P. Protzel D. Krüger, I. Lil. Using and extending the miro middleware for autonomous robots. In Towards Autonomous Robotic Systems (TAROS), Guildford, September 2006. (2006). 28 [51] Michael Jackson. Specializing in software engineering. IEEE Softw. 16(6), 120–121,119 November (1999). 33 [52] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. ACM Comput. Surv. 37(4), 316–344 December (2005). 34 [53] Diomidis Spinellis. Notable design patterns for domain-specific languages, (2001). 34 [54] Richard B. Kieburtz, Laura McKinney, Jeffrey M. Bell, James Hook, Alex Kotov, Jeffrey Lewis, Dino P. Oliva, Tim Sheard, Ira Smith, and Lisa Walton. A software engineering experiment in software component generation. In Proceedings of the 18th international conference on Software engineering, ICSE ’96, pages 542–552, Washington, DC, USA (1996). IEEE Computer Society. 34 [55] Markus Voelter, Sebastian Benz, Christian Dietrich, Birgit Engelmann, Mats Helander, Lennart C. L. Kats, Eelco Visser, and Guido Wachsmuth. DSL Engineering - Designing, Implementing and Using Domain-Specific Languages. dslbook.org (2013). 34, 35, 42 [56] Arie van Deursen and Paul Klint. Little languages : little maintenance. Journal of Software Maintenance 10(2), 75–92 March (1998). 35 139Références bibliographiques [57] David A. Ladd and Christopher J. Ramming. Two Application languages in software production. In VHLLS’94 : Proceedings of the USENIX 1994 Very High Level Languages Symposium Proceedings on USENIX 1994 Very High Level Languages Symposium Proceedings, page 10, Berkeley, CA, USA (1994). USENIX Association. 35 [58] Francis Neelamkavil. Computer simulation and modelling. John Wiley & Sons, Inc., New York, NY, USA (1987). 35 [59] Omg. http://www.omg.org/. 36 [60] Richard C. Gronback. Eclipse Modeling Project : A Domain-Specific Language (DSL) Toolkit. Addison-Wesley Professional, 1 edition (2009). 37, 50 [61] Papyrus. http://www.eclipse.org/papyrus/. 37, 81, 82 [62] Uml. http://www.uml.org/. 37 [63] L. Fuentes-Fernández and A. Vallecillo-Moreno. An Introduction to UML Profiles. UPGRADE, European Journal for the Informatics Professional 5(2), 5–13 April (2004). 37, 43 [64] OMG MOF 2 XMI Mapping Specification, Version 2.4.1, August (2011). 38 [65] Epsilon. http://www.eclipse.org/epsilon/. 39 [66] Kermeta. http://www.kermeta.org/overview/model_transformation. 39 [67] Acceleo. http://www.eclipse.org/acceleo/. 39, 85 [68] Tom-emf. http://tom.loria.fr/wiki/index.php5/Documentation:EMF. 39 [69] Paul Oldfield. Domain modelling, (2002). 39, 99 [70] G. Arango. Domain analysis : from art form to engineering discipline. In Proceedings of the 5th international workshop on Software specification and design, IWSSD ’89, pages 152–159, New York, NY, USA (1989). ACM. 40 [71] Mark A. Simos. Organization domain modeling (odm) : Formalizing the core domain modeling life cycle, (1996). 40 [72] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-oriented domain analysis (foda) feasibility study. Technical report Carnegie-Mellon University Software Engineering Institute November (1990). 41 [73] Nicola Guarino. Formal ontology and information systems. pages 3–15. IOS Press (1998). 41 140Références bibliographiques [74] Saadia Dhouib, Selma Kchir, Serge Stinckwich, Tewfik Ziadi, and Mikal Ziane. Robotml, a domain-specific language to design, simulate and deploy robotic applications. , 7628, pages 149–160. Springer Berlin Heidelberg (2012). 46 [75] Piotr Trojanek. Model-driven engineering approach to design and implementation of robot control system. CoRR abs/1302.5085 (2013). 47 [76] Xavier Blanc, Jérôme Delatour, and Tewfik Ziadi. Benefits of the MDE approach for the development of embedded and robotic systems. In Proceedings of the 2nd National Workshop on “Control Architectures of Robots : from models to execution on distributed control architectures” (CAR 2007) (2007). 47 [77] Brics. http://www.best-of-robotics.org/. 48 [78] Bride. http://www.best-of-robotics.org/bride/. 49 [79] D. Simon, B. Espiau, K. Kapellos, and R. Pissard-Gibollet. Orccad : software engineering for real-time robotics. a technical insight. Robotica 15(1), 111–115 January (1997). 50 [80] D. Simon, R. Pissard-Gibollet, and S. Arias. Orccad, a framework for safe robot control design and implementation. In 1st National Workshop on Control Architectures of Robots : software approaches and issues CAR’06, Montpellier (2006). 50 [81] Gerard Berry, Georges Gonthier, Ard Berry Georges Gonthier, and Place Sophie Laltte. The esterel synchronous programming language : Design, semantics, implementation, (1992). 50 [82] Christian Schlegel. Communication Patterns as Key Towards Component-Based Robotics. International Journal of Advanced Robotic Systems 3(1), 49–54 March (2006). 51, 79 [83] Smartsoft reference implementation. http://smart-robotics. sourceforge.net/. 51 [84] C. Schlegel, A. Lotz, and A. Steck. Smartsoft : The state management of a component. Technical report Hochschule Ulm January (2011). 52 [85] Cristina Vicente-Chicote, Fernando Losilla, Bárbara Álvarez, Andrés Iborra, and Pedro Sánchez. Applying mde to the development of flexible and reusable wireless sensor networks. Int. J. Cooperative Inf. Syst. 16(3/4), 393–412 (2007). 54 141Références bibliographiques [86] Genom3. http://homepages.laas.fr/mallet/soft/architecture/ genom3/. 55, 58, 60 [87] S. Fleury, M. Herrb, and R. Chatila. Genom : a tool for the speci- fication and the implementation of operating modules in a distributed robot architecture. , 2, pages 842–849 vol.2 (1997). 55 [88] Anthony Mallet, Cédric Pasteur, Matthieu Herrb, Séverin Lemaignan, and François Felix Ingrand. Genom3 : Building middlewareindependent robotic components. In ICRA, pages 4627–4632. IEEE (2010). 56 [89] Robotic Technology Component (RTC), August (2012). 56, 58, 60 [90] Byoungyoul Song, Seugwoog Jung, Choulsoo Jang, and Sunghoon Kim. An introduction to robot component model for opros (open platform for robotic services). (2008). 56, 57 [91] Choulsoo Jang, Byoungyoul Song, Seungwoog Jung, Sunghoon Kim, Byeongcheol Choi, Hyo-Young Lee, and Cheol-Hoon Lee. A development of software component framework for robotic services. Convergence Information Technology, International Conference on 0, 1–6 (2009). 56 [92] Mi-sook Kim and Hong Seong Park. Open platform for ubiquitous robotic services. In Proceedings of the 2012 ACM Conference on Ubiquitous Computing, UbiComp ’12, pages 892–893, New York, NY, USA (2012). ACM. 56 [93] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, and Woo-Keun Yoon. RT-middleware : distributed component middleware for RT (robot technology). In 2005 IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 3933–3938. IEEE (2005). 56, 57 [94] Gostai rtc. http://www.gostai.com/products/rtc/. 57 [95] Proteus. http://www.anr-proteus.fr/. 64 [96] Dassault aviation. http://www.dassault-aviation.com/fr/. 64 [97] ECA : Etudes et Constructions Aéronotiques. http://www.eca-robotics. com/. 64 [98] CEA : Commissariat de l’Energie Atomique. http://www.cea.fr/. 64 [99] GOSTAI. http://www.gostai.com/. 64 [100] Intempora. http://www.intempora.com/. 64 142Références bibliographiques [101] Thales. https://www.thalesgroup.com/fr. 64 [102] Lasmea. http://tims.isima.fr/lasmea.php. 64 [103] Thales optronoique sa. https://www.thalesgroup.com/fr/worldwide/ defense/notre-offre-forces-terrestres-c4isr/optronique. 64 [104] Greyc. https://www.greyc.fr/. 64 [105] Inria. http://www.inria.fr/. 64 [106] Onera. http://www.onera.fr/. 64 [107] Prisme. http://www.univ-orleans.fr/prisme. 64 [108] Effidence. http://effistore.effidence.com/. 64 [109] Wifibot. http://www.wifibot.com/. 64 [110] Lip6 : Laboratoire d’Informatique de Paris 6. http://www.lip6.fr. 64 [111] Thomas R. Gruber. Toward principles for the design of ontologies used for knowledge sharing. Int. J. Hum.-Comput. Stud. 43(5-6), 907–928 dec (1995). 65 [112] Gaëlle Lortal, Saadia Dhouib, and Sébastien Gérard. Integrating ontological domain knowledge into a robotic DSL. In Proceedings of the 2010 international conference on Models in software engineering, MODELS’10, Berlin, Heidelberg (2011). Springer-Verlag. 69 [113] RTMAPS : Real-Time, Multisensor, Advanced, Prototyping Software. http: //www.intempora.com/rtmaps4/rtmaps-software/overview.html. 85 [114] URBI : Universal Real-time Behavior Interface. http://www.urbiforge. org/. 85 [115] Arrocam. http://effistore.effidence.com/. 85 [116] Morse. http://www.openrobots.org/wiki/morse/. 85 [117] Cycabtk. http://cycabtk.gforge.inria.fr/. 85 [118] Rtt-lua. http://www.orocos.org/wiki/orocos/toolchain/luacookbook. 87 [119] Davide Brugali, Luca Gherardi, A. Biziak, Andrea Luzzana, and Alexey Zakharov. A Reuse-Oriented Development Process for ComponentBased Robotic Systems. , 7628, pages 361–374. Springer (2012). 100 143Références bibliographiques [120] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns : Elements of reusable object-oriented software. AddisonWesley Publishing (1995). 106, 107 [121] V. Lumelsky and A. Stepanov. Dynamic path planning for a mobile automaton with limited information on the environment. Automatic Control, IEEE Transactions on 31(11), 1058 – 1063 nov (1986). 110, 111, 125 [122] H. Noborio, K. Fujimura, and Y. Horiuchi. A comparative study of sensor-based path-planning algorithms in an unknown maze. , 2, pages 909 –916 vol.2 (2000). 111, 112, 125 [123] A. Sankaranarayanan and M. Vidyasagar. A new path planning algorithm for moving a point object amidst unknown obstacles in a plane. In Robotics and Automation, 1990. Proceedings., 1990 IEEE International Conference on, pages 1930 –1936 vol.3 may (1990). 111 [124] A. Sankaranarayanar and M. Vidyasagar. Path planning for moving a point object amidst unknown obstacles in a plane : a new algorithm and a general theory for algorithm development. In Decision and Control, 1990., Proceedings of the 29th IEEE Conference on, pages 1111 –1119 vol.2 dec (1990). 112, 113, 125 [125] Ishay Kamon. Sensory based motion planning with global proofs. In In Proceedings of the IROS95, pages 435–440 (1995). 112, 113, 125 [126] Ishay Kamon, Elon Rimon, and Ehud Rivlin. Tangentbug : A rangesensor-based navigation algorithm. The International Journal of Robotics Research 17(9), 934–953 September (1998). 114, 115, 125 [127] James Ng and Thomas Bräunl. Performance comparison of bug navigation algorithms. J. Intell. Robotics Syst. 50(1), 73–84 September (2007). 125 144Résumé L’un des challenges des roboticiens consiste à gérer un grand nombre de variabilités. Ces dernières concernent les concepts liés au matériel et aux logiciels du domaine de la robotique. Par conséquent, le développement des applications de robotique est une tâche complexe. Non seulement, elle requiert la maîtrise des détails de bas niveau du matériel et du logiciel mais aussi le changement du matériel utilisé dans une application entraînerait la réécriture du code de celle-ci. L’utilisation de l’ingénierie dirigée par les modèles dans ce contexte est une voie prometteuse pour (1) gérer les problèmes de dépendance de bas niveau des applications des détails de bas niveau à travers des modèles stables et (2) faciliter le développement des applications à travers une génération automatique de code vers des plateformes cibles. Les langages de modélisation spécifiques aux domaines mettent en oeuvre les techniques de l’ingénierie dirigée par les modèles afin de représenter les concepts du domaine et permettre aux experts de celui-ci de manipuler des concepts qu’ils ont l’habitude d’utiliser. Cependant, ces concepts ne sont pas suffisants pour représenter tous les aspects d’une application car ils très généraux. Il faudrait alors s’appuyer sur une démarche pour extraire des abstractions à partir de cas d’utilisations concrets et ainsi définir des abstractions ayant une sémantique opérationnelle. Le travail de cette thèse s’articule autour de deux axes principaux. Le premier axe concerne la contribution à la conception d’un langage de modélisation spécifique au domaine de la robotique mobile (RobotML). Nous extrayons à partir d’une ontologie du domaine les concepts que les roboticiens ont l’habitude d’utiliser pour la définition de leurs applications. Ces concepts sont ensuite représentés à travers une interface graphique permettant la représentation de modèles afin d’assurer une facilité d’utilisation pour les utilisateurs de RobotML. On offre ainsi la possibilité aux roboticiens de représenter leurs scénarios dans des modèles stables et indépendants des plateformes cibles à travers des concepts qu’ils ont l’habitude de manipuler. Une génération de code automatique à partir de ces modèles est ensuite possible vers une ou plusieurs plateformes cibles. Cette contribution est validée par la mise en oeuvre d’un scénario aérien dans un environnement inconnu proposé par l’ONERA. Le deuxième axe de cette thèse tente de définir une approche pour rendre les algorithmes résistants aux changements des détails de ba niveau. Notre approche prend en entrée la description d’une tâche de robotique et qui produit : – un ensemble d’abstractions non algorithmiques représentant des requêtes sur l’environnment y compris le robot ou des actions de haut niveau ; – un ensemble d’abstractions algorithmiques encapsulant un ensemble d’instructions permettant de réaliser une sous-tâche de la tâche étudiée ; – un algorithme générique configurable défini en fonction de ces abstractions. Ainsi, l’impact du changement du matériel et des stratégies définies dans les sous-tâches n’est pas très important. Il suffit d’adapter l’implantation de ces abstractions sans avoir à modifier l’algorithme générique. Cette approche est validée sur six variantes d’une famille d’algorithmes de navigation appelée Bug.Abstract One of the challenges of robotics is to manage a large number of variability. The latter concerns the concepts related to hardware and software in the field of robotics. Therefore, the development of robotic applications is a complex task. Not only it requires mastery of low-level details of the hardware and software but also if we change the used hardware in an application, this would impact the code. The use of model-driven engineering in this context is a promising way to (1) manage low-level dependency problems through stable models and (2) facilitate the development of applications through automatic code generation to target platforms . Domain Specific Modeling Languages implement the model driven engineering technologies to represent the domain concepts and enable experts to manipulate concepts they are used to use. However, these concepts are not sufficient to represent all aspects of an application because they are very general. We would then use an approach to extract abstractions from concrete use cases and thus define abstractions with an operational semantics . The work of this thesis focuses on two main axes. The first concerns the contribution to the design of a domain specific modeling language for mobile robots (RobotML). We extract from a domain ontology concepts that roboticists have used to use to define their applications. These concepts are then represented through a graphical interface representation model to ensure ease of use for RobotML users. An automatic code generation from these models can then be performed to one or more target platforms. This contribution is enabled by setting implement an air scenario, in an unknown environment, proposed by ONERA. The second focus of this thesis attempts to define an approach to make the algorithms resistant to the change of low-level details. Our approach takes as input a description of a task and produces robotic : – a set of non-algorithmic abstractions representing queries on environnment (including robot) or high-level actions ; – a set of algorithmic abstractions encapsulating a set of instructions to perform a sub-task of the studied task ; – a generic configurable algorithm defined according to these abstractions. Thus, the impact of changing hardware and strategies defined in the sub-tasks is not very important. Simply adapt the implementation of these abstractions without changing the generic algorithm. This approach is validated on six variants of a navigation algorithms family called Bug. M´eta-mod´elisation du Comportement d’un Mod`ele de Processus : Une D´emarche de Construction d’un Moteur d’Ex´ecution Sana Mallouli To cite this version: Sana Mallouli. M´eta-mod´elisation du Comportement d’un Mod`ele de Processus : Une D´emarche de Construction d’un Moteur d’Ex´ecution. Modeling and Simulation. Universit´e Panth´eon-Sorbonne - Paris I, 2014. French. HAL Id: tel-01061466 https://tel.archives-ouvertes.fr/tel-01061466 Submitted on 6 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.DE L’UNIVERSITE PARIS 1 DOCTEUR DE L’UNIVERSITE PARIS 1 Méta-modélisation du Comportement d’un Une Démarche de Construction d Soutenue le 25/07 Slimane Corine Samira Carine SOUVEYET Saïd ASSAR THESE DE DOCTORAT DE L’UNIVERSITE PARIS 1 PANTHEON – SORBONNE Réalisée par : Sana Damak Mallouli Pour l’obtention du titre de : CTEUR DE L’UNIVERSITE PARIS 1 PANTHEON Spécialité : INFORMATIQUE modélisation du Comportement d’un Modè Une Démarche de Construction d’un Moteur d’Exécution Soutenue le 25/07/2014 devant le jury composé de : Slimane HAMMOUDI Membre du jury Corine CAUVET Rapporteur amira SI SAID Rapporteur Carine SOUVEYET Directeur de thèse Saïd ASSAR Encadrant de thèse SORBONNE PANTHEON – SORBONNE Modèle de Processus : Moteur d’Exécution devant le jury composé de : de thèseii iii Remerciements iv Remerciements Comme toute thèse, cette recherche a été ponctuée de nombreux moments d’enthousiasme et de joie, mais également de nombreuses périodes de doute et de découragement. L’achèvement de ce travail n’aurait pas été possible sans la précieuse contribution de nombreuses personnes que je veux remercier ici. Je souhaiterais tout d’abord adresser mes sincères remerciements à la directrice de cette thèse Madame Carine Souveyet, Professeur à l’université Paris1 Panthéon-Sorbonne, pour la confiance qu’elle m’a accordée en acceptant de diriger cette thèse, puis pour m'avoir guidée, encouragée et conseillée, tout au long de ce travail de recherche. Je la remercie infiniment pour m’avoir fait bénéficier de sa grande compétence, de sa rigueur intellectuelle et de ces précieux conseils. Je tiens également à exprimer ma plus vive reconnaissance à mon encadrant de recherche Mr Saïd Assar, Maitre de conférences à Institut Mines Telecom -Telecom Ecole de Management. Il m’a encouragée par ses orientations sans cesser d’être une grande source de motivation et d’enthousiasme. Je le remercie sincèrement pour sa disponibilité, sa persévérance, et ses encouragements continus. Je tiens à le remercier également pour ses qualités humaines d’écoute et son soutien moral pendant les moments difficiles. Je remercie Madame Corine Cauvet, Professeur à l’université Aix-Marseille 3, et Madame Samira Si-Saïd Cherfi, Maître de conférences, HDR à la Conservatoire National des Arts et Métiers (CNAM) Paris, qui ont eu la gentillesse d’accepter le rôle de rapporteur de cette thèse. Elles ont contribué par leurs nombreuses remarques et suggestions à améliorer la qualité de ce mémoire, et je leur en suis très reconnaissante. Je remercie également Mr Slimane Hammoudi, Professeur ESEO, HDR à l’Université d’Angers d’avoir accepté de présider le jury de cette thèse. Je remercie chaleureusement, Madame Colette Rolland, Professeur Emérite à l’Université de Paris 1 Panthéon – Sorbonne, pour la confiance qu’elle m’a témoignée en m’accueillant dans son équipe. Mes remerciements vont également à Mr Camille Salinesi, Professeur - Directeur du Centre de Recherche en Informatique à l’Université de Paris 1 Panthéon – Sorbonne. Je tiens aussi à mentionner le plaisir que j'ai eu à travailler au sein du CRI (Centre de Recherche Informatique) et j'en remercie ici tous les membres pour leurs amitiés et leurs encouragements. Une pensée particulière va à Amina, Assia, Adrian, Ali, Bénédicte, Camille, Carine, Charlotte, Daniel, Elena, Ghazalleh, Hela, Ines, Islem, Kahina, Manuele, Saïd, Salma, Selmine, Raul, Rawia et Rebbeca. Ces années de thèses resteront ancrées dans ma mémoire comme une période très enrichissante de ma vie. Cet aboutissement ne pouvait se réaliser sans être associé au soutien Remerciements v des personnes les plus proches de moi. Merci à mes parents et mes grands parents pour l’affection qu’ils m’ont toujours manifestée et pour leur soutien lors des moments les plus difficiles de cette thèse même quand je suis loin d’eux. Merci à mes adorables sœurs Olfa et Wafa pour leur amour inconditionnel et leur bonne humeur. Merci infiniment à ma bellefamille, à mes proches et à mes amis notamment ma tante Souad et Faten pour leurs encouragements continus. L’affection qu’ils m’ont apportée durant ces années m’a aidée à garder le moral haut et à achever ma thèse. Je garde pour la fin un remerciement particulier pour mon mari, Wissam. Je le remercie du fond du cœur de m’avoir aidée, soutenue, encouragée et surtout aimée. Ces dernières années n’ont pas été très simples, il m’a supportée dans les moments les plus difficiles et m’a aidée à retrouver le sourire pendant les périodes de doute. Pour finir, je souhaiterais dédier ce travail à tous ceux que j’aime. Qu’ils y trouvent ici l’expression de ma profonde affection et de mes plus sincères remerciements. Sana Résumé vi Résumé De nos jours, le nombre de langages de modélisation ne cesse d’augmenter en raison de différentes exigences et contextes (par exemple les langages spécifiques au domaine). Pour être utilisés, ces langages ont besoin d'outils pour réaliser différentes fonctionnalités comme l'édition, la transformation, la validation et l'exécution de modèles conformes à ces langages. La construction de ces outils est un enjeu et un objectif important aussi bien dans la communauté du génie logiciel que celle des Systèmes d’Information. C’est une tâche nontriviale qui fait appel à des approches différentes parmi lesquelles l’utilisation des environnements méta-CASE et des langages de méta-programmation. Par rapport à une approche ad-hoc, les méta-CASE définissent un support outillé et une démarche basée sur la méta-modélisation. Ils apportent des améliorations significatives à la problématique de construction d’outils. Néanmoins, des limitations majeures persistent, notamment pour les langages de modélisation des processus, à cause de la complexité de l’expression de la sémantique opérationnelle d’un modèle de processus et la capture de la logique d’exécution de celui-ci. La construction de ces outils selon une approche ad-hoc engendre un coût élevé, des risques d’erreurs et des problèmes de maintenabilité et de portabilité. En outre, un outil d’exécution de modèle doit satisfaire un critère d’interactivité avec son environnement d’exécution. Cet aspect n’est pas suffisamment pris en compte dans les travaux de recherche actuels sur la spécification des langages de modélisation. Pour répondre à cette problématique, nous proposons dans cette thèse une démarche dirigée par les modèles qui permet de dériver l’architecture d’un moteur d’exécution à partir de la spécification conceptuelle d’un langage de modélisation de processus. Cette spécification repose sur une méta-modélisation élargie qui intègre l’expression de la sémantique d’exécution d’un méta-modèle de processus. Elle est composée, d’une part, d’une structure à deux niveaux d’abstraction qui permet de représenter de manière générique les modèles à exécuter et les instances générées lors de leur exécution. D’autre part, cette spécification est complétée par une représentation déclarative et graphique du comportement du méta-modèle de processus. Pour cette représentation, nous avons choisi un formalisme orienté événement qui reflète la vision systémique et les différentes interactions du modèle de processus avec son environnement. Finalement, afin d’exploiter la sémantique d’exécution, nous proposons des règles de transformation permettant de dériver l’architecture technique d’un outil d’exécution sous une forme standard pour pouvoir l’implémenter dans un environnement de génération de code existant, le code généré correspondra à l’outil d’exécution souhaité. La démarche proposée a été appliquée dans le cas d’un modèle de processus intentionnel appelé Map. Cette application a permis d’explorer la faisabilité de la proposition et d’évaluer la qualité de la spécification de l’outil d’exécution obtenue par rapport aux exigences fixées. La pertinence de notre proposition est qu’elle permet de guider l’ingénieur dans le processus de spécification et de construction d’un outil d’exécution tout en minimisant l’effort de programmation. De plus, en appliquant les étapes de la démarche proposée, nous sommes en mesure de fournir un outil d’exécution d’une certaine qualité ; à savoir un outil interagissant avec son environnement, facilement maintenable et à moindre coût. Abstract vii Abstract Nowadays, the number of modeling languages is increasing due to different requirements and contexts (e.g., domain-specific languages). These languages require appropriate tools to support them by achieving various functionalities such as editing, transforming, validating and implementing models that conform to these languages. The construction of such tools constitutes a challenging goal for both software engineering and information systems communities. This non obvious task is involves different approaches such as meta-CASE and meta-programming languages. Unlike ad-hoc approach, meta-CASE environments define software tools and metamodeling based approaches to improve tools construction. However, major limitations still exist, in particular for process modeling languages, due to the complexity of expressing process model operational semantics and capturing its execution logics. These limitations commonly lead to a manual construction of tools which is labor-intensive, error-prone and poses maintainability and portability issues. Besides, a process model execution tool should satisfy the criterion of interactivity with its environment. This aspect is not sufficiently taken into account in actual research works on the specification of modeling languages. To address this problem, we propose in this thesis a model driven approach to derive the software architecture of an enactment engine from the conceptual specification of the process modeling language. This specification relies on an enlarged meta-modeling approach that includes the expression of the execution semantics of a process meta-model. It consists of a structural specification incorporating both concepts structures and instances that are generated during execution. This specificaiton is completed by a declarative and graphical representation of the process behavioural meta-model. For this representation, an eventoriented paradigm is adopted to reflect the dynamic vision and the different interactions of the process model with its environment. Finally, transformation rules are proposed in order to obtain an enactment engine architecture in an object-oriented form. The enactment engine will be obtained by implementing the object-oriented architecture in an existing code-generation environment. The proposed approach has been applied to the case of an intentional process model called “Map”. This application case aims at evaluating the feasibility of the proposed approach and assessing the quality of the derived enactment engine in regard with initial requirements. The proposed approach is relevant, since on one hand, it allows better guidance for engineers during the specification of the modeling language and the implementation of an enactment tool, and on the other hand, it minimizes programming efforts. In addition, by applying the different steps of the proposed approach, we are able to guarantee a certain quality of the enactment tool ensuring interactivity, maintainability and development low cost. Table des matières Table des matières REMERCIEMENTS .................................................................................................................................... IV RESUME ...................................................................................................................................................... VI ABSTRACT .................................................................................................................................................. VII TABLE DES MATIÈRES ......................................................................................................................... VIII TABLE DES FIGURES .............................................................................................................................. XI TABLE DES TABLEAUX ......................................................................................................................... XV CHAPITRE 1 : INTRODUCTION ......................................................................................................................... 13 1.1. LES OUTILS CASE ................................................................................................................................... 13 1.2. L’IDM ET L’INGENIERIE DES LANGAGES ........................................................................................................ 14 1.3. META-CASE, INGENIERIE DES METHODES ET CAME ...................................................................................... 15 1.4. META-MODELES ET SEMANTIQUE D’EXECUTION ............................................................................................ 17 1.5. CONSTATS ET PROBLEMATIQUE .................................................................................................................. 19 1.6. OBJECTIF DE LA THESE .............................................................................................................................. 19 1.7. DEMARCHE DE RECHERCHE SUIVIE DANS CETTE THESE ..................................................................................... 20 1.8. APERÇU DE LA SOLUTION PROPOSEE ............................................................................................................ 21 1.9. PLAN DE LA THESE ................................................................................................................................... 23 CHAPITRE 2 : PROJET EXPLORATOIRE ............................................................................................................. 25 2.1. INTRODUCTION ....................................................................................................................................... 25 2.2. MOTIVATION POUR LE PROJET EXPLORATOIRE ............................................................................................... 25 2.2.1. Un outil d’exécution pour le Map .................................................................................................. 25 2.2.2. Exploration de la nouvelle technologie méta-CASE ....................................................................... 26 2.3. METHODOLOGIE DE L’EXPERIMENTATION ..................................................................................................... 26 2.4. DESCRIPTION DU PROJET EXPLORATOIRE ...................................................................................................... 28 2.4.1. L’approche d’évaluation du projet exploratoire ............................................................................ 28 2.4.2. L’outil MetaEdit+ ........................................................................................................................... 28 2.4.3. Le modèle de processus : Map....................................................................................................... 31 2.4.4. La sémantique opérationnelle du modèle Map ............................................................................. 32 2.4.5. Le cas d’application : La méthode CREWS l’Ecritoire ..................................................................... 34 2.4.6. Le développement du prototype ................................................................................................... 39 2.5. LES RESULTATS DE L’EXPERIMENTATION ....................................................................................................... 46 2.5.1. Le méta-modèle de produit ........................................................................................................... 46 2.5.2. Le méta-modèle de processus ....................................................................................................... 47 2.5.3. Le moteur d’exécution de la carte de CREWS L’Ecritoire ............................................................... 48 2.6. EVALUATION DE L’EXPERIMENTATION .......................................................................................................... 51 2.6.1. Les critères d’évaluation ................................................................................................................ 51 2.6.2. Les résultats de l’évaluation .......................................................................................................... 52 2.6.3. Exigences fondamentales pour une méta-modélisation des processus dans les outils méta-CASE 53 2.7. CONCLUSION .......................................................................................................................................... 54 CHAPITRE 3 : ETAT DE L’ART ........................................................................................................................... 56 3.1. EXEMPLES INTRODUCTIFS .......................................................................................................................... 56 3.2. PRESENTATION DES CONCEPTS ................................................................................................................... 58 3.2.1. La construction des outils .............................................................................................................. 58 3.2.2. L’ingénierie des méthodes ............................................................................................................. 59 3.2.3. Les méta-outils et les CAME .......................................................................................................... 60 3.2.4. La méta-modélisation .................................................................................................................... 61 3.2.5. Les langages de méta-modélisation .............................................................................................. 63 3.3. DE L’EXECUTION DES PROGRAMMES VERS L’EXECUTABILITE DES MODELES ........................................................... 64 3.3.1. Quelques définitions ...................................................................................................................... 64Table des matières ix 3.3.2. L’exécutabilité des modèles ........................................................................................................... 68 3.3.3. L’expression de l’exécutabilité des modèles .................................................................................. 69 3.4. EXEMPLES DE LANGAGES DE META-MODELISATION ........................................................................................ 70 3.4.1. Meta Object Facility (MOF) ........................................................................................................... 70 3.4.2. Ecore .............................................................................................................................................. 71 3.4.3. GOPRR ........................................................................................................................................... 73 3.4.4. Synthèse sur les langages de méta-modélisation .......................................................................... 75 3.5. LES APPROCHES DE CONSTRUCTION D’OUTILS D’EXECUTION DE MODELES ........................................................... 75 3.5.1. Approche ad-hoc ........................................................................................................................... 75 3.5.2. Eclipse Modeling Framework (EMF) .............................................................................................. 76 3.5.3. Méta-programmation avec Kermeta ............................................................................................ 77 3.5.4. Spécification de systèmes industriels avec TOPCASED .................................................................. 79 3.5.5. Exécution des processus d’ingénierie avec UML4SPM .................................................................. 80 3.5.6. Méta-modélisation et génération de code avec MetaEdit+ .......................................................... 81 3.5.7. Méta-modélisation déclarative avec Concept Base ...................................................................... 82 3.5.8. Méta-modélisation et grammaire des attributs avec JastAdd et JastEMF .................................... 84 3.5.9. Ingénierie des méthodes basée sur l’IDM avec Moskitt4ME ......................................................... 85 3.6. NOTRE GRILLE DE COMPARAISON................................................................................................................ 86 3.6.1. Les critères de comparaison .......................................................................................................... 86 3.6.2. Le tableau de comparaison ........................................................................................................... 89 3.7. ANALYSE DE L’ETUDE COMPARATIVE ........................................................................................................... 93 3.8. CONCLUSION .......................................................................................................................................... 93 CHAPITRE 4 : PROPOSITION D’UNE DEMARCHE IDM POUR LA CONSTRUCTION D’OUTILS D’EXECUTION ....... 95 4.1. INTRODUCTION ....................................................................................................................................... 95 4.2. UNE APPROCHE IDM POUR L’INGENIERIE D’OUTILS D’EXECUTION ..................................................................... 97 4.3. UNE VUE DETAILLEE DE LA DEMARCHE PROPOSEE ........................................................................................... 98 4.3.1. La 1ère étape : La spécification structurelle du méta-modèle de processus ................................... 99 4.3.2. La 2ème étape : Compléter la spécification structurelle par une spécification du comportement du méta-modèle ............................................................................................................................................. 102 4.3.3. La 3ème étape : Transformation pour obtenir une architecture orientée objet de l’outil d’exécution 103 4.4. ETAPE 1 : LA SPECIFICATION STRUCTURELLE DU META-MODELE DE PROCESSUS .................................................. 104 4.4.1. Le méta-modèle de diagramme de classes ................................................................................. 105 4.4.2. Exemple d’un diagramme de classes UML .................................................................................. 105 4.5. ETAPE 2 : LA SPECIFICATION GRAPHIQUE DE LA SEMANTIQUE D’EXECUTION ...................................................... 108 4.5.1. Pourquoi le modèle Remora ? ..................................................................................................... 108 4.5.2. Le modèle événementiel .............................................................................................................. 109 4.5.3. Le schéma dynamique de la sémantique opérationnelle du Méta-Modèle de Processus ........... 126 4.6. ETAPE 3: TRANSFORMATION DU MODELE COMPORTEMENTAL VERS UN MODELE OBJET TECHNIQUE STANDARD ........ 129 4.6.1. Formalisation des schémas d’entrée et de sortie pour la transformation ................................... 130 4.6.2. La dérivation de l’architecture objet de l’outil d’exécution à partir de la sémantique opérationnelle ............................................................................................................................................ 134 4.6.3. Les principes de la gestion événementielle.................................................................................. 134 4.6.4. Règle n°1 : Cas d’un événement interne ...................................................................................... 137 4.6.5. Règle n°2: Cas d’un événement externe avec réception d’un message ....................................... 144 4.6.6. Règle n°3 : Cas d’une opération externe vers un acteur externe ................................................. 149 4.6.7. Règles spécifiques à EngineContext ............................................................................................ 155 4.7. ADAPTATION DE LA SPECIFICATION OO DE L’ARCHITECTURE DE L’OUTIL A UNE PLATEFORME CIBLE ......................... 157 4.8. L’ORIGINALITE DE NOTRE PROPOSITION ...................................................................................................... 158 4.9. CONCLUSION ........................................................................................................................................ 159 CHAPITRE 5 : APPLICATION DE LA DEMARCHE AU CAS DU MAP ET VALIDATION.......................................... 160 5.1. INTRODUCTION ..................................................................................................................................... 160 5.2. ETAPE 1 : COMPLETER LE META-MODELE DU MAP PAR LA STRUCTURE DES INSTANCES ........................................ 162 5.2.1. La structure des concepts du méta-modèle Map ........................................................................ 162 5.2.2. La spécification structurelle à deux niveaux relative au méta-modèle Map ............................... 163Table des matières x 5.3. ETAPE 2 : COMPLETER LA SPECIFICATION A 2 NIVEAUX PAR L’EXPRESSION DE LA SEMANTIQUE D’EXECUTION ........... 167 5.3.1. La démarche suivie pour l’élaboration du schéma dynamique ................................................... 167 5.3.2. Le schéma dynamique relatif au méta-modèle du Map .............................................................. 168 5.4. ETAPE 3 : TRANSFORMATION DES SPECIFICATIONS VERS UNE ARCHITECTURE ORIENTE OBJET DU MOTEUR D’EXECUTION 172 5.4.1. Exemple d’application de la règle n°1 ......................................................................................... 173 5.4.2. Exemple d’application de la règle n°2 ......................................................................................... 175 5.4.3. Exemple d’application de la règle n°3 ......................................................................................... 176 5.4.4. Exemple d’applications des transformations relatives à la structure à 2 niveaux et à l’acces aux données 179 5.5. EVALUATION DE LA DEMARCHE ................................................................................................................ 180 5.6. CONCLUSION ........................................................................................................................................ 182 CHAPITRE 6 : CONCLUSION ET PERSPECTIVES ............................................................................................... 184 6.1. CONCLUSION ........................................................................................................................................ 184 6.1.1. Rappel de la problématique ........................................................................................................ 184 6.1.2. Bilan du travail réalisé ................................................................................................................. 185 6.2. PERSPECTIVES ....................................................................................................................................... 187 BIBLIOGRAPHIE .................................................................................................................................... 189 ANNEXES ................................................................................................................................................. 199 ANNEXE 1: LISTE DES FONCTIONS DU SCRIPT SCRIPT1_MAP_PROCESS ........................................................ 199 ANNEXE 2: LISTE DES JOINTURES DU SCRIPT SCRIPT4_MAP_LINKS .............................................................. 200 ANNEXE 3: PROCÉDURE FOREACH .STRATEGY, SCRIPT SCRIPT5_MAP_INIT .................................................. 200 ANNEXE 4: PROCÉDURE FOREACH .INTENTION, SCRIPT SCRIPT5_MAP_INIT ................................................ 200 ANNEXE 5: PROCESSUS DU CALCUL DES CANDIDATES .................................................................................. 201 ANNEXE 6: INITIAL GOAL IDENTIFICATION STRATEGY .................................................................................. 205 ANNEXE 7: L’INTERFACE DE LA STRATEGIE « FREE PROSE » PERMETTANT A L’UTILISATEUR DE SAISIR SON SCENARIO. .................................................................................................................................................... 206 ANNEXE 8: L’INTERFACE DE LA STRATEGIE « SCENARIO PREDEFINED STRUCTURE » QUI PERMET DE CHOISIR UN SCENARIO PREDEFINIE............................................................................................................................ 206 ANNEXE 9: L’INTERFACE DE LA STRATEGIE « MANUAL » : QUI PERMET A L’UTILISATEUR DE CONCEPTUALISER SON SCENARIO DE MANIERE MANUELLE. ..................................................................................................... 207 ANNEXE 10: SPECIFICATION EVENEMENTIELLE EN XML DE L’EXEMPLE DU WORKFLOW ............................... 207 ANNEXE 11 : L’ARCHITECTURE OO DU MOTEUR D’EXECUTION DU MAP ...................................................... 211 Table des figures Table des figures Figure 1. Les fonctionnalités d’un outil CASE dans l’ingénierie des SI ................................. 13 Figure 2. Les fonctionnalités d’un outil méta-CASE ............................................................... 16 Figure 3. Exemple de conception d’un CASE pour le modèle E/R avec l’outil MetaEdit+ .... 16 Figure 4. Schéma générique pour un moteur d’exécution ....................................................... 18 Figure 5. Les étapes de la démarche de recherche suivie ......................................................... 20 Figure 6. Aperçu de l’approche ................................................................................................ 21 Figure 7. Interface graphique principale de l’outil MetaEdit+................................................. 29 Figure 8. L’interface de l’éditeur d’objet dans MetaEdit+ ....................................................... 30 Figure 9. Extrait d’une carte de conception d’un schéma de classes ....................................... 31 Figure 10. Le méta-modèle du Map ......................................................................................... 32 Figure 11. Un exemple d’une carte Map .................................................................................. 33 Figure 12. Une illustration des sections candidates ................................................................. 33 Figure 13. Map de CREWS l’Ecritoire .................................................................................... 35 Figure 14. La structure d’un fragment de besoin ..................................................................... 37 Figure 15. Les deux niveaux d’abstraction de la structure du produit et d’un processus (Edme, 2005) ............................................................................................................................ 37 Figure 16. Relation entre parties du produit construit et réalisations d’intentions. ................. 38 Figure 17. Aperçu de la méta-démarche suivie dans le projet avec MetaEdit+ ....................... 39 Figure 18. Représentation de l’architecture de l’outil d’exécution ......................................... 40 Figure 19. Base de données générée pour notre moteur d’exécution ....................................... 43 Figure 20. Le méta-modèle de produit : formalisme Entité/Relation exprimé en GOPRR ..... 47 Figure 21. Le méta-modèle statique du formalisme de carte Map défini avec GOPRR .......... 47 Figure 22. Le modèle du processus CREWS L’Ecritoire défini dans l’outil CASE cible ....... 48 Figure 23. La structure de la DB du moteur du Map ............................................................... 49 Figure 24. Interface Graphique du Moteur d’exécution ........................................................... 49 Figure 25. Un extrait du méta-modèle SPEM (SPEM, 2008) .................................................. 57 Figure 26. Méta-modèle de workflow (Hollingsworth, 1996) ................................................. 58 Figure 27. Le croisement des préoccupations des deux communautés SI et GL ..................... 59 Figure 28. Environnement CAME ........................................................................................... 61 Figure 29. Notions de base de la méta-modélisation ............................................................... 62 Figure 30. Les concepts principaux de MOF 1.4 (Blanc, 2005) .............................................. 71 Figure 31. Les concepts du méta-modèle Ecore ..................................................................... 72 Figure 32. Les concepts du langage GOPRR ........................................................................... 74 Figure 33. Architecture d’EMF ................................................................................................ 76 Figure 34. Méta-modèle de Kermeta (Zoé et al., 2009) ........................................................... 77 Figure 35. Définition d’une opération en Kermeta (sémantique opérationnelle) .................... 79 Figure 36. Vue globale du méta-modèle UML4SPM (Bendraou, 2007) ................................. 80 Figure 37. Architecture générale de MetaEdit+ (Kelly et al., 1996) ........................................ 82 Figure 38. Éditeur graphique de l’outil ConceptBase : un exemple d’instanciation du modèle ‘entité-association’ en 4 niveaux d’abstraction ........................................................................ 83 Figure 39. Aperçu de l’approche moskitt4ME (Cervera et al., 2012) ...................................... 85 Figure 40. La grille de comparaison des méta-outils ............................................................... 86 Figure 41. Un aperçu de la démarche proposée ....................................................................... 96 Figure 42. Le synopsis de notre proposition pour la construction d’outils d’exécution .......... 97 Figure 43. La vue détaillée de notre proposition ...................................................................... 98 Figure 44. Le principe de dérivation de la structure d’instances à partir de la structure des concepts .................................................................................................................................. 100Table des figures xii Figure 45. La sémantique d’exécution par rapport aux niveaux d’abstraction d’un modèle de processus ................................................................................................................................ 100 Figure 46. L’expression explicite de la sémantique d’exécution grâce au modèle événementiel ................................................................................................................................................ 102 Figure 47. Le méta-modèle de diagramme de classes UML (Blanc, 2005) ........................... 105 Figure 48. Le diagramme de classes simplifié du méta-modèle de Workflow ...................... 106 Figure 49. L’architecture à deux niveaux du méta-modèle de Workflow ............................. 107 Figure 50. Le modèle d’événement Remora .......................................................................... 109 Figure 51. La structure du concept Objet ............................................................................... 110 Figure 52. La structure du concept Opération ........................................................................ 110 Figure 53. Le modèle événementiel et sa représentation graphique ...................................... 112 Figure 54. La forme graphique de la structure du concept Evénements ................................ 113 Figure 55. La forme textuelle de la structure du concept d’Evénement ................................ 113 Figure 56. La structure d’un événement interne. ................................................................... 114 Figure 57. Un exemple d’événement interne ......................................................................... 114 Figure 58. La représentation textuelle de l’exemple d’un événement interne ....................... 115 Figure 59. La structure d’un événement externe .................................................................... 115 Figure 60. La structure du concept Message .......................................................................... 116 Figure 61. Un exemple d’événement externe ......................................................................... 116 Figure 62. La représentation textuelle de l’exemple d’un événement externe ....................... 116 Figure 63. La structure du concept Acteur ............................................................................. 117 Figure 64. La forme textuelle de la structure du concept Acteur ........................................... 117 Figure 65. La structure du concept Opération-Externe .......................................................... 118 Figure 66. La forme textuelle de la structure du concept Opération-Externe ........................ 118 Figure 67. Un exemple illustrant les acteurs du workflow et leurs interactions avec l’outil . 119 Figure 68. Un exemple illustratif du concept Acteur ............................................................. 120 Figure 69. La structure d’un Trigger ...................................................................................... 121 Figure 70. Forme textuelle de la structure d’un Trigger ........................................................ 122 Figure 71. Les deux concepts Condition et Facteur ............................................................... 122 Figure 72. Un exemple d’un Facteur ...................................................................................... 122 Figure 73. Un exemple d’un trigger extrait du modèle dynamique de workflow .................. 123 Figure 74. Un exemple illustratif d’un Trigger ...................................................................... 124 Figure 75. La structure du modèle Remora étendu en format XML graphique ..................... 125 Figure 76. Le schéma dynamique du méta-modèle de Workflow (exemple simplifié) ......... 127 Figure 77. Un extrait de la spécification en XML du schéma dynamique de workflow ....... 128 Figure 78. La 3ème étape de la proposition: La transformation ............................................... 129 Figure 79. La relation entre le méta-modèle UML et le méta-modèle événementiel ............ 130 Figure 80. Le méta-modèle source de la transformation ........................................................ 131 Figure 81. Les documents XML qui représentent les entrées de l’étape de transformation .. 131 Figure 82. Le méta-modèle cible de la transformation .......................................................... 132 Figure 83. Les trois situations de comportement possibles dans un modèle événementiel ... 133 Figure 84. Le principe de gestion d’une interaction interne .................................................. 135 Figure 85. Le principe de gestion d’une interaction formalisée dans un événement externe 136 Figure 86. Le principe de gestion d’une interaction externe avec message sortant ............... 136 Figure 87. Schéma d’un événement interne ........................................................................... 137 Figure 88. La règle de transformation n°1 : cas d’un événement interne .............................. 140 Figure 89. Un exemple générique pour la construction des objets observés et objets dynamiques ............................................................................................................................. 140 Figure 90. Le diagramme de séquence pour la création des objets relatifs à un événement interne ..................................................................................................................................... 141Table des figures xiii Figure 91. Le diagramme de séquence pour l’exécution d’un événement interne ................. 141 Figure 92. Un extrait du diagramme de classes de workflow après application de la règle n°1 ................................................................................................................................................ 142 Figure 93. Le diagramme de séquence pour la création des objets correspondant à l’événement interne EV5 du workflow .................................................................................. 143 Figure 94. Le diagramme de séquence pour l’exécution de l’événement interne EV5 du workflow ................................................................................................................................ 143 Figure 95. Le schéma d’un événement externe : action provenant d’un acteur ..................... 144 Figure 96. Les règles de transformation dans le cas d’un événement externe ....................... 146 Figure 97. Extrait du diagramme de séquence pour la création des objets suite à l’arrivée d’un événement externe .................................................................................................................. 147 Figure 98. Le diagramme de séquence pour l’exécution d’un événement externe ................ 147 Figure 99. Un extrait du diagramme de classes de workflow obtenu par l’application de la règle n°2 ................................................................................................................................. 148 Figure 100. Extrait du diagramme de séquence obtenu par l’application de la règle n°2 pour l’initialisation de l’événement externe EV1 du modèle de workflow ................................... 148 Figure 101. Le diagramme de séquence pour l’exécution de l’événement externe EV1 du modèle de workflow ............................................................................................................... 149 Figure 102. Le schéma d’une opération externe .................................................................... 149 Figure 103. La règle n°3 pour la transformation d’une opération externe (Cas1) ................ 151 Figure 104. Extrait du diagramme de séquence pour la création des objets lors d’une opération externe (Cas1) ........................................................................................................................ 151 Figure 105. Le diagramme de séquence relatif à l’exécution d’une opération externe (Cas 1) ................................................................................................................................................ 152 Figure 106. La règle n°3 pour la transformation d’une opération externe (Cas2) ................ 153 Figure 107. Extrait du diagramme de séquence pour la création des objets lors d’une opération externe (Cas2) ........................................................................................................................ 153 Figure 108. Le diagramme de séquence relatif à l’exécution d’une opération externe (Cas 2) ................................................................................................................................................ 153 Figure 109. Un extrait du diagramme de classes de workflow après application de la règle n°3 : Exemple de l’opération externe déclenchée par l’événement EV2 .......................... 154 Figure 110. Un extrait du diagramme de séquence pour l’opération externe NotifierAffectation dans l’exemple du workflow ............................................................................... 154 Figure 111. Un exemple de diagramme de séquence relatif àl’exécution d’une opération externe (Cas1) ........................................................................................................................ 155 Figure 112. Les classes et les diagrammes générés par l’application de la règle R12 pour la gestion des liens de référence entre les classes de la structure à deux niveaux ..................... 156 Figure 113. Règle de transformation pour la gestion des classes du niveau « type » et du niveau « instance » ................................................................................................................. 157 Figure 114. Variable de classe et méthode de classe de la classe globale EngineContext ..... 157 Figure 115. Une vue globale de l’application de la démarche proposée dans le cas du Map 160 Figure 116. Les étapes de la démarche proposée appliquées dans le cas du Map ................. 161 Figure 117. Le diagramme de classes du méta-modèle du Map (M2) ................................. 162 Figure 118. Le principe de dérivation de la structure des instances pour le cas du Map ....... 163 Figure 119. La spécification à deux niveaux (concept-type et instances) duméta-modèle Map ................................................................................................................................................ 164 Figure 120. Le diagramme de séquence du méta-modèle Map .............................................. 166 Figure 121. La démarche suivie pour l’élaboration du schéma dynamique ........................... 167 Figure 122. Les modules qui interagissent avec le moteur d’exécution ................................ 170 Figure 123. Le schéma dynamique du Map en utilisant le formalisme Remora étendu ........ 170Table des figures xiv Figure 124. Le résultat de l’application de la règle de transformation n°1 au modèle Map .. 173 Figure 125. Le diagramme de séquence résultant de l’application de la règle n°1 : Exemple d’initialisation des objets pour l’événement interne EV6 du modèle Map ............................ 174 Figure 126. Le diagramme de séquence résultant de l’application de la règle n°1 : Exemple d’exécution de l’événement interne EV6 du modèle Map ..................................................... 174 Figure 127. La structure des classes obtenue par l’application de la règle de transformation n°2 au Map ............................................................................................................................. 175 Figure 128. Un extrait du diagramme de séquence résultant de l’application de la règle n°2 : Exemple d’initialisation pour l’événement externe EV1 du Map .......................................... 176 Figure 129. Le diagramme de séquence résultant de l’application de la règle n°2 : Exemple d’exécution de l’événement externe EV1 du Map ................................................................. 176 Figure 130. Les classes résultant de l’application de la règle de transformation n°3 au modèle Map ......................................................................................................................................... 177 Figure 131. Un extrait du diagramme de séquence relatif à l’application de la règle n°3 pour l’initialisation d’une opération externe : Exemple EV12 du Map ......................................... 178 Figure 132. Un extrait du diagramme de séquence relatif à l’application de la règle n°3 pour l’exécution d’une opération externe : Exemple EV12 du Map .............................................. 178 Figure 133. Exemple d’application des règles relatives à la gestion de la structure à deux niveaux ................................................................................................................................... 179 Figure 134. La Classe globale EngineContext relative au Map ............................................. 180 Figure 135. Le principe de transformation de modèle en IDM .............................................. 188 Table des tableaux Table des tableaux Tableau 1. Les intentions de la carte de CREWS L’Ecritoire .................................................. 35 Tableau 2. Les stratégies de la carte de CREWS L’Ecritoire .................................................. 35 Tableau 3. Les sections de la carte de CREWS L’Ecritoire ..................................................... 36 Tableau 4. Récapitulatif des tables de la Base de données ...................................................... 44 Tableau 5. Les critères d’évaluation ........................................................................................ 52 Tableau 6. Les résultats de l’évaluation du projet .................................................................... 52 Tableau 7. Comparaison entre langage de modélisation et langages de programmation (Kleppe, 2008) .......................................................................................................................... 65 Tableau 8. Le domaine des valeurs des attributs d’état dans le modèle Map ........................ 165 Tableau 9 . La liste des opérations de la structure des instances ........................................... 165 Tableau 10. La liste des événements du schéma dynamique du méta-modèle Map ............. 168 Tableau 11. La liste des messages du schéma dynamique du méta-modèle Map .................. 169 Tableau 12. Le tableau comparatif pour évaluation de la démarche proposée ...................... 181Chapitre 1 : Introduction 13 CHAPITRE 1 : INTRODUCTION 1.1. Les Outils CASE La complexité croissante des systèmes d’information (SI) rend le développement des SI lourd et coûteux (Giraudin, 2007). Afin de maitriser cette complexité, différentes techniques et approches sont proposées par l’ingénierie des SI (ISI). Le but des outils connus sous le nom d’Ateliers de Génie Logiciel (CASE en anglais pour Computer-Aided Software Engineering) est d’assister et d’aider l’ingénieur à concevoir et développer des SI (Fuggetta, 1993) grâce à un ensemble de fonctionnalités permettant d'alléger le travail de l’ingénieur et aussi d'introduire l'automatisation dans la mise en œuvre d’une méthode d’ingénierie (Figure 1). Figure 1. Les fonctionnalités d’un outil CASE dans l’ingénierie des SI Comme exemples d’outil CASE, on peut citer StarUML1 , Power AMC2 , WebRatio3 , NetBeans4 , Rational Rose5 , Eclipse6 . Ces outils proposent diverses fonctionnalités avec des niveaux de sophistication variables, et ne couvrent pas forcément les mêmes phases du cycle de vie d’un système. Une distinction courante est entre upper- et lower-CASE (Fuggetta, 1993). Un upper-CASE est dédié aux phases d'analyse et de conception et il est généralement associé à une méthode d’ingénierie de SI. Il inclut des interfaces graphiques pour éditer les spécifications d’un système et des dictionnaires de données pour les stocker, des fonctions pour gérer la documentation, des moyens de contrôle de qualité et de correction de schémas. Un lower-CASE est destiné aux phases d’implémentation avec des éditeurs syntaxiques, des librairies de programmes, des compilateurs, des générateur d'interfaces homme/machine, ou encore des outils pour la mise au point de programmes et la configuration des codes sources. La distinction entre lower- et upper-CASE s’estompe lorsque l’outil intègre des fonctionnalités de génération de code et de transformation de modèle, c’est ce que préconise l’ingénierie dirigée par les modèles. 1 http://staruml.sourceforge.net/en/ 2 http://wikipedia.org/wiki/PowerAMC 3 http://www.webratio.com/ 4 https://netbeans.org/ 5 http://www.ibm.com/developerworks/rational/products/rose/ 6 Eclipse : http://www.eclipse.org/ Ingénieur SI Spécification du Edition système Validation Exécution ou simulation OutilCASE Transformation ou génération de code Application Langage de modélisation Utilisateur finalChapitre 1 : Introduction 14 1.2. L’IDM et l’ingénierie des langages Les outils CASE jouent un rôle important dans l’ingénierie dirigée par les modèles (IDM ou MDE7 ). En effet, l’IDM place les modèles au centre du processus d’ingénierie des systèmes, et grâce à des outils logiciels adéquats, attribue aux modèles une fonction productive par opposition au rôle contemplatif8 habituel (Favre, 2006). Cette production s’effectue à travers des transformations, pour aller vers une génération automatique – ou semi automatique – de logiciels pour des plateformes d’implémentation cibles. Avec le développement de l’IDM, la construction des outils CASE est devenue un enjeu et un objectif important. C’est une tâche non-triviale qui fait appel à la définition de langages de modélisation et à l’implémentation de fonctionnalités non seulement de transformation et de génération de code mais aussi de test, vérification et exécution. Elle soulève des questionnements multiples : Quelle architecture pour l’outil? Quelles fonctionnalités à fournir? Est ce qu’on cherche à développer un générateur de code, un moteur d’exécution ou simplement un éditeur de modèles? Comment implémenter chacune de ces fonctionnalités? Comment garantir certaines propriétés de l’outil telles que la portabilité (en cas d’évolution de la plateforme sur laquelle s’exécute l’outil), la maintenabilité (en cas d’évolution des langages de modélisation), ou la réutilisabilité (en cas de développement de nouveaux langages)? Enfin, quelles méthodes et quels (méta-) outils pour concevoir, spécifier et implémenter ces outils? Pour traiter ces problématiques, en plus de l’IDM, un domaine de recherche complémentaire a émergé : l’ingénierie des langages pour le génie logiciel9 (Kleppe, 2009), (Favre et al., 2009). Il est à l’intersection de multiples thématiques de l’ingénierie des SI et du génie logiciel telles que la modélisation conceptuelle et la transformation de modèles, l’ingénierie des méthodes, la méta-modélisation, les outils méta-CASE, les langages spécifiques au domaine (ou DSM10) ou encore la compilation et les langages de programmation. La problématique des langages pour le génie logiciel dépasse le cadre restreint des langages de programmation (tels que C ou Java). Les langages de génie logiciel sont des artéfacts au cœur du développement de différents domaines d’ingénierie informatique. Ils sont conçus et développés pour résoudre une problématique générique de représentation de systèmes (UML, XML), ou des problématiques plus spécifiques telles que l’exécution des processus à base de services web (BPEL11), l’ingénierie des besoins (i*12 , Tropos13) ou la modélisation des processus d’ingénierie (SPEM14). La spécification de tels langages, et surtout la construction d’outils pour les accompagner, sont au cœur du sujet de cette thèse. 7 MDE: Model-Driven Engineering 8 (un modèle contemplatif est utilisé pour représenter graphiquement une spécification conceptuelle ou bien pour la documentation et la compréhension d’un projet 9 SLE: Software Language Engineering 10 DSM: Domain Specific Modeling 11 BPEL: Business Process Execution Language 12 i*: http://www.cs.toronto.edu/km/istar/ 13 Tropos: http://www.troposproject.org/ 14 SPEM: Software Process Engineering Metamodel Chapitre 1 : Introduction 15 1.3. Méta-CASE, ingénierie des méthodes et CAME Apparue dans les années 1990, l’objectif de la technologie méta-CASE est de faciliter et accélérer la conception et le développement d'outils CASE dédiés à une méthode d’ingénierie particulière (Alderson, 1991) (Smolander et al., 1991). Alors que la méthode est prédéfinie dans un outil CASE, les outils méta-CASE permettent la personnalisation et la construction de méthodes d’ingénierie afin de les adapter aux besoins spécifiques des ingénieurs (Kelly et Smolander, 1996) (Assar et al., 2012). La technologie méta-CASE introduit un niveau d’architecture supplémentaire pour la spécification de la méthode que l’ingénieur souhaite outiller. Alors qu’une méthode comporte des « produits » (tout livrable ou artéfact produit par l’application de la méthode) et des « processus » (des cheminements suivis pour aboutir aux produits) (Olle, 1988), il est fréquent dans la littérature des méta-CASE qu’une méthode soit restreinte à sa composante « produit ». C’est le cas notamment dans les premières publications de l’outil MetaEdit+ par exemple (Smolander et al., 1991) (Kelly et al., 1996), où par la suite, c’est la spécificité du « produit » pour un domaine qui est mise en avant (Kelly et Tolvanen, 2008) (Kelly et al., 2013). L’ingénierie des méthodes a grandement contribué à expliciter l’importance du processus dans la description d’une méthode (Brinkkemper et al., 1996). Et c’est dans le domaine des environnements de génie logiciel centrés processus (PCSE15 ou PSEE16) que plusieurs langages ont été proposés pour modéliser et spécifier les processus d’ingénierie logiciel (Fuggetta, 1996) (Zamli and Lee, 2001)(Arbaoui et al., 2002). Le terme CAME17 a été introduit pour désigner des outils logiciels semblables aux méta-CASE, la différence se situant surtout au niveau de la finalité : pour un méta-CASE, c’est la génération d’un outil spécifique (pour un langage de modélisation de produit) ; pour un CAME, c’est la spécification d’une méthode avec les deux perspectives « produit » et « processus » (Heym et Österle, 1993) (Saeki, 2003). Ces deux termes sont souvent semblables sinon identiques étant donné que la spécification d’une méthode nécessite la construction d’un outil correspondant. L’outil MetaEdit+ est ainsi mentionné dans la littérature en tant que méta-CASE pour l’outillage des DSM, mais aussi en tant qu’environnement CAME pour outiller des méthodes (Kelly et Tolvanen, 2008) (Niknafs and Ramsin, 2008) (Kelly et al., 2013). Le niveau d’architecture supplémentaire qu’introduit les méta-CASE et les CAME inclut, d’une part, des langages de modélisation et de méta-modélisation pour la méta-spécification d’une méthode, et d’autre part, des fonctionnalités pour la construction (ou génération semiautomatique) d’un outil CASE à partir de cette méta-spécification. Le langage de métamodélisation sert à définir les méta-modèles de la méthode, c'est-à-dire les méta-modèles de produit et de processus. Un méta-modèle de produit contient les concepts, les règles et les notations graphiques du langage de modélisation des produits dans une méthode donnée. Par exemple, un méta-modèle d’UML (ou de BPMN18 respectivement) spécifie des concepts tels que ‘classe’ et ‘héritage’ (ou ‘tâche’ et ‘événement’ respect.) et des liens entre ces concepts. 15 PCSE: Process Centred Software Engineering 16 PSEE: Process-centred Software Engineering Environments 17 CAME: Computer Aided Method Engineering 18 Business Process Modeling Notation Chapitre 1 : Introduction 16 Figure 2. Les fonctionnalités d’un outil méta-CASE L’ingénieur outil utilise le langage de méta-modélisation pour définir les méta-modèles de la méthode pour laquelle il souhaite construire un outil CASE (Figure 2). Pour la perspective « produit », cette méta-définition doit couvrir les trois facettes fondamentales d’un langage de modélisation : la syntaxe abstraite19 (les concepts et les liens entre ces concepts), la syntaxe concrète (la forme extérieure – graphique ou textuelle – des concepts et des liens) et la sémantique (le sens attribué à ces concepts). Figure 3. Exemple de conception d’un CASE pour le modèle E/R avec l’outil MetaEdit+ Dans l’outil MetaEdit+ (Kelly and Smolander, 1996) par exemple, la méta-spécification s’exprime avec le langage de méta-modélisation GOPRR 20. Un outil CASE cible dérivé à partir de cette méta-spécification comporte par défaut des fonctionnalités d’édition de modèle. 19 La syntaxe abstraite est généralement définie, en IDM, sous la forme d’un ensemble de classes et un modèle issu du langage est un ensemble d’objets, instances de ces classes. 20 GOPRR: Graph, Object, Property, Relationship, Role Ingénieur outil Méta-Spécification Du langage de modélisation Edition Validation Outil méta-CASE Langage de méta- modélisation Ingénieur SI ? Personnalisation ou dérivation de l’outil Exécution ou simulation Outil CASE Générer Méta-modèle E/R en GOPRR Scripts en MERL Éditeur de modèles E/R SQL Créer le script à partir du MM E/RChapitre 1 : Introduction 17 Le méta-modèle peut être complété par des scripts écrits dans un méta-langage spécifique (MERL). Ces scripts, qui incluent des commandes de navigation dans les instances des métamodèles, peuvent décrire un comportement permettant à l’outil CASE cible d’avoir une fonctionnalité de génération de code. La figure 3 illustre cette démarche pour construire un outil de modélisation à base de la notation Entité/Relation. Le générateur de code implémente les règles de transformation de structure du type « une entité devient une table » ou « une association de cardinalité 1- N devient une clé étrangère ». Alors que la phase de méta-modélisation se fait d’une manière déclarative et avec des outils graphiques, le processus de construction du générateur de code est de nature algorithmique à l’aide de simple éditeur de texte. Dans ces scripts séquentiels organisés en modules non paramétrés, l’ingénieur méthode utilise sa connaissance implicite de la sémantique des méta-modèles manipulés pour définir le générateur de code. 1.4. Méta-modèles et sémantique d’exécution Généralement, la pratique de la méta-modélisation consiste à spécifier des méta-modèles contemplatifs qui reflètent l’aspect statique des modèles. L’aspect statique d’un modèle représente l’ensemble des concepts qui ont servi à décrire ce modèle ainsi que les liens entre ces concepts (Jeusfeld et al., 2009). On utilise aussi le terme aspect structurel. L’aspect dynamique complète l’aspect statique et renseigne sur la manière avec laquelle les instances des concepts vont intéragir lors de l’exécution du méta-modèle. Cela revient à décrire le comportement dynamique des instances des concepts, c'est-à-dire la sémantique d’exécution du modèle. Selon le langage de méta-modélisation utilisé, un méta-modèle contemplatif peut être complété par la spécification de certaines contraintes. En utilisant UML par exemple pour construire un (méta-) diagramme de classes, il est possible de compléter cette spécification avec des contraintes exprimées avec le langage OCL. Pour un langage de modélisation de processus (tels que XPDL21, BPMN ou SPEM), la méta-modélisation telle qu’elle vient d’être illustrée avec l’outil MetaEdit+, se restreint à décrire la syntaxe abstraite des concepts qui correspond à l’aspect statique (ou structurel) de ces concepts, et ne prend pas en compte la sémantique des concepts. Par exemple, un méta-modèle de BPMN représente un « produit » avec des objets et des propriétés (les concepts), des relations et des rôles (les liens entre ces concepts). Tandis que la sémantique d’un modèle de processus BPMN correspond à un certain comportement dans un environnement d’exécution donné. Ce comportement peut être assuré par un moteur d’exécution qui interprète les instances du modèle de processus, interagit avec l’environnement et fournit un résultat qui varie en fonction de cette interaction (Figure 4). 21 XML Process Definition Language Chapitre 1 : Introduction 18 Figure 4. Schéma générique pour un moteur d’exécution Pour exécuter un processus, il est en effet souvent nécessaire de communiquer et d’interagir avec d’autres acteurs humains et/ou agents logiciels afin de déléguer des tâches ou de recevoir des éléments indispensables pour continuer l’exécution (un fragment de produit, une décision, un choix, etc.). Par ailleurs, l’évocation de l’exécution d’un modèle de processus est généralement faite à l’aide du terme anglo-saxon « enactment » pour souligner la différence qu’il y a entre « exécuter un programme » et « énacter un processus » et mettre en œuvre l’aspect distribué, coopératif et parfois asynchrone d’un processus. L’expression de la sémantique des langages est une problématique connue et bien développée depuis plusieurs décennies dans le domaine de la compilation et des langages de programmation. Les techniques les plus probantes s’appuient sur la grammaire des attributs (Knuth, 1968), (Paakki, 1995). Pour les langages de modélisation, l’intérêt pour l’expression explicite de la sémantique est assez récent (Harel and Rumpe, 2004). L’intérêt pour l’expression de la sémantique des modèles va de pair avec la question de comment rendre exécutable un modèle, à priori contemplatif, décrit à l’aide d’un méta-langage (Muller et al., 2005). La direction suivie pour résoudre ces problèmes cherche à enrichir les langages et environnements de méta-modélisation pour permettre l’expression explicite et adéquate de la sémantique d’un langage de modélisation. Dans (Paige et al., 2006) par exemple, il est proposé d’enrichir le méta-méta-modèle MOF22 avec un langage d’action qui permettra de programmer des « méta-méthodes » rattachées aux méta-classes d’un méta-diagramme MOF. 22 MOF : Meta Object Facility, formalism de méta-modélisation proposé par l’OMG (http://www.omg.org/mof/) Moteur d’exécution Spécifique à un métamodèle de processus Entrée Environnement du moteur d’exécution Modèle de processus Produit résultant de l’exécution du processus BD Acteur externe Application externe Sortie Interactions Evénements externes Agir Réagir Agir RéagirChapitre 1 : Introduction 19 1.5. Constats et problématique Nous constatons qu’aujourd’hui, par rapport à l’approche ad-hoc, les environnements méta-CASE définissent des démarches basées sur la méta-modélisation, et qui apportent des améliorations significatives aux problématiques de spécification d’un langage de modélisation et de construction d’outils correspondants. Néanmoins, trois limitations majeures persistent: • D’une part, la méta-modélisation est fortement orientée « produit » ; d’un point de vue d’ingénierie de méthode, la spécification du processus méthodologique est complexe, difficile, sinon impossible, à capturer et à énacter. Les tentatives de l’environnement MetaEdit+ dans ce sens par exemple (Koskinen et Marttiin, 1998) n’ont finalement pas été retenues dans l’outil commercialisé par la suite par l’entreprise MetaCASE23 . • D’autre part, cette spécification des « produits » n’en capture que la syntaxe abstraite et une partie réduite de la sémantique sous forme de contraintes. Si le produit est un modèle de processus, et si l’ingénieur méthode souhaite exécuter ces processus, et cherche à obtenir un moteur d’exécution de ces modèles, la construction d’un tel moteur se fait manuellement. Elle nécessite une connaissance en programmation et un effort supplémentaire de la part de l’ingénieur. De plus, cette implémentation artisanale entraine des difficultés de maintenance du moteur d’exécution car toute évolution des modèles oblige l’ingénieur outil à propager les changements dans le code (les scripts Merl dans le cas de MetaEdit+). • Enfin, la spécification du modèle de processus n’integre pas l’aspect interactif avec des acteurs externes ce qui implque que l’outil d’exécution associé ne va pas satisfaire des contraintes en termes d’interactivité avec l’environnement d’exécution. 1.6. Objectif de la thèse Notre objectif est de proposer une approche de spécification de langage de modélisation de processus et de construction d’outils d’exécution de modèles permettant de satisfaire les contraintes suivantes : • Cette approche doit offrir un support de méta-modélisation avec une prise en compte claire et explicite de la sémantique d’exécution du modèle et un formalisme graphique pour une représentation visuelle de cette spécification. • L’approche devra comporter une démarche et des techniques pour exploiter la sémantique d’exécution du méta-modèle de processus afin d’en dériver de manière systématique une architecture d’un moteur d’exécution qui satisfait des contraintes de maintenabilité et de portabilité. • La spécification du modèle de processus doit interagir avec son environnement pour que le moteur d’exécution associé à ce modèle puisse avoir ce critère d’interactivité. • Cette approche doit être suffisamment générique pour pouvoir être appliquée sur n’importe quel modèle de processus. 23 http://www.metacase.com Chapitre 1 : Introduction 20 1.7. Démarche de recherche suivie dans cette thèse La démarche de recherche de la thèse est schématisée à la Figure 5. La première étape est un projet exploratoire que nous avons mené pour acquérir une expérience pratique dans le développement d’un outil par méta-modélisation. Ce projet à été réalisé dans le cadre d’un co-encadrement d’un Master Recherche pour explorer une technologie méta-CASE pour le développement d’outil d’exécution pour un modèle de processus intentionnel (Harrous, 2011) et dont une synthèse des résultats a été publiée dans (Mallouli, 2013). A l’issue de ce projet exploratoire, nous avons déterminé un ensemble de constats qui ont permis de fixer des exigences précises pour répondre à notre problématique. La seconde étape de notre recherche est une synthèse de l’état de l’art concernant l’exécutabilité des modèles, la construction d’outils ainsi que les langages et outils de métamodélisation. Cette étape a été réalisée en parallèle avec un co-encadrement de deux mémoires de Master Recherche pour étudier et comparer les langages et les outils de métamodélisation (Souag, 2010) (Zaidi, 2010). A la fin de l’étude de l’état de l’art, nous avons réalisé une comparaison entre différentes approches de construction d’outils en se basant sur des critères définis à la lumière des exigences fixées lors de la première étape. Figure 5. Les étapes de la démarche de recherche suivie La troisième étape correspond à l’élaboration de la solution que nous proposons. Les principales idées de notre démarche consistent à élargir le périmètre d’expression d’un métamodèle en y ajoutant la spécification de sa sémantique d’exécution, et à introduire plus d’automatisation dans le processus de construction d’outils grâce à l’exploitation des spécifications du niveau « méta ». Etat de l’art
Étudier de manière approfondie différentes approches
Rebondir sur les constats du projet exploratoire
En se basant sur ces constats, définir un ensemble de critères pour comparer différentes approches Projet exploratoire
Obtenir les premiers constats en se basant sur un cas pratique de construction d’outil
Définir des exigences à satisfaire dans la solution à partir de ces constats Elaborer une solution de spécification d’outils d’exécution
Compléter le méta-modèle de processus pour prendre en compte la sémantique d’exécution en faisant appel à une notation événementielle.
Exploiter la spécification de la sémantique d’exécution pour obtenir un outil d’exécution.
Définir des règles de transformation pour obtenir une architecture technique d’un outil d’exécution. 1 2 3Chapitre 1 : Introduction 21 1.8. Aperçu de la solution proposée Contrairement aux approches classiques, qui se basent sur la structure d’un méta-modèle puis définissent la sémantique d’exécution directement dans le code ou sous forme de scripts attachés aux éléments statiques, notre démarche utilise un formalisme soigneusement choisi pour la spécification de la sémantique d’exécution, ce qui facilite la génération de l’architecture d’un outil d’exécution. Notre solution comporte trois étapes schématisées à la Figure 6 : • La première étape définit le méta-modèle structurel du langage de modélisation. • La seconde étape définit la sémantique d’exécution du modèle à travers un méta-modèle de comportement. Pour ce faire, il faut au préalable compléter le méta-modèle structurel en introduisant un second niveau de représentation qui correspond aux instances du métamodèle. Ce second niveau est nécessaire pour l’expression de la sémantique d’exécution ; en effet, celle-ci s’exprime en manipulant les instances du méta-modèle au moment de l’exécution d’un modèle afin d’extraire l’instance intéressante à un instant t précis. • La troisième étape applique des règles de transformation pour dériver une architecture d’outil d’exécution à partir de la spécification conceptuelle. Figure 6. Aperçu de l’approche Pour spécifier le comportement du modèle et sa sémantique d’exécution, nous adoptons une persepctive «systémique» du modèle de comportement et introduisons une notation basée sur les événements (Assar et al., 2011). La vision systémique préconise de voir le comportement d’un système selon un schéma où l’action est un stimulus externe de l’environnement du système et la réaction est l’activité que le système déclenche en réponse. Concrètement, notre approche consiste à introduire de nouveaux concepts (Evénement, Acteur, Transition, Trigger) dans le langage de méta-modélisation. Ces concepts serviront à spécifier le comportement dynamique des structures définies au niveau des métamodèles. De cette manière, la spécification de la sémantique d’exécution du modèle intègre Spécification structurelle à deux niveaux Schéma dynamique Spécification de la sémantique d’exécution du méta-modèle Architecture Orientée Objet de l’outil d’exécution Métamodélisation Structure statique des modèles de processus en fonction d’un MMP Structure des Processus (instances) Perspective Comportement Perspective Données Perspective Traitements UML Formalisme orienté événement Formalisme OO Ingénieur basées sur les patrons PublishSubscribe UML Formalisme OO Etape3 Etape2 Etape1 Règles de TransformationChapitre 1 : Introduction 22 une représentation des éléments de l’environnement du processus dans lequel le modèle s’exécutera ainsi que les éléments échangés avec lui. La sémantique d’exécution est ainsi exprimée à travers un schéma graphique. Cette expression de la sémantique d’exécution est de nature opérationnelle, elle montre l’interprétation du modèle par un outil d’exécution qui gère les événements, assure les interactions avec l’environnement et contrôle l’interprétation du modèle. Cette sémantique opérationnelle peut de ce fait être traduite en une architecture d’outil logiciel à l’aide d’une technique de type « par traduction » (Combemale et al., 2006). Nous élaborons donc un ensemble de règles pour transformer la spécification conceptuelle en une spécification exécutable. En raison de la nature dynamique et interactive du modèle de comportement, nous choisissons le patron publication/abonnement (publish/subscribe) comme modèle cible d’implémentation du concept d’événement au niveau conceptuel. Dans ce modèle, les abonnés (des agents ou composants logiciels) manifestent leur intérêt pour un événement, et sont automatiquement notifiés de toute occurrence de cet événement (Eugster et al., 2003). Une occurrence d’événement est donc propagée de manière synchrone ou asynchrone à tous les abonnés qui sont inscrits à cet événement. Les abonnés réagissent àla notification d’un événement par le déclenchement d’un traitement spécifié dans une méthode particulière. En appliquant un ensemble de règles de transformation, la spécification conceptuelle permet de dériver l’architecture d’un outil logiciel directement implémentable. Notre solution présente deux contributions majeures: • Un apport conceptuel qui consiste à capturer la sémantique opérationnelle du métamodèle avec une vision systémique et l’exprimer à travers des concepts événementiels. • Une démarche par méta-modélisation qui exploite les méta-modèles conceptuels pour arriver à la phase d’implémentation avec une architecture exécutable en appliquant de manière systématique des règles de transformation. L’originalité de ce travail se résume dans les points suivants : • L’approche suivie est de type « méta-démarche » et permet de guider l’ingénieur dans le processus de spécification et de construction d’un outil d’exécution. • Dans la partie spécification conceptuelle, le comportement de l’outil d’exécution à construire est représenté par un modèle orienté événement, Le modèle de comportement choisi est fondé sur le paradigme systémique, Ce modèle est largement utilisé en SI et il est bien adapté aux outils d’exécution qui sont en complète interaction avec leur environnement. • Dans la partie implémentation de cette démarche, une approche par transformation, du niveau conceptuel vers le niveau technique, des concepts liés au comportement, est appliquée afin de générer une architecture d’un outil d’exécution de manière méthodique à partir de la spécification conceptuelle. Cette approche favorise les critères de maintenabilité, de portabilité et de minimisation de coût. Langage de mashup pour l’int´egration autonomique de services de donn´ees dans des environements dynamiques Mohamad Othman-Abdallah To cite this version: Mohamad Othman-Abdallah. Langage de mashup pour l’int´egration autonomique de services de donn´ees dans des environements dynamiques. Databases. Universit´e de Grenoble, 2014. French. HAL Id: tel-01011470 https://tel.archives-ouvertes.fr/tel-01011470 Submitted on 26 Jun 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE Pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE Spécialité : Informatique Arrêté ministériel : 7 août 2006 Présentée par Mohamad OTHMAN ABDALLAH Thèse dirigée par Christine COLLET et Co-encadrée par Genoveva VARGAS-SOLAR préparée au sein du Laboratoire d’Informatique de Grenoble dans l'École Doctorale de Mathématiques, Sciences et Technologies de l'Information et de l'Informatique MELQART : un système d’exécution de mashups avec disponibilité de données Thèse soutenue publiquement le 24 février 2014, devant le jury composé de : Mme, Chirine GHEDIRA GUEGAN Professeur, IAE Lyon, Rapporteur Mme, Parisa GHODOUS Professeur, Université Claude Bernard Lyon 1, Rapporteur M. Omar BOUCELMA Professeur, Université d’Aix Marseille, Examinateur Mme Christine COLLET Professeur, Grenoble INP, Directeur de thèse Mme Genoveva VARGAS-SOLAR Chargé de recherche, CNRS, Co-encadrant1 REMERCIEMENTS Je tiens à remercier : Madame Cherine Ghedira Guegan, Professeur à l’IAE de Lyon, et Madame Parisa Ghodous, Professeur à l’Université Claude Bernard Lyon 1, de leur intérêt pour mon travail et pour avoir accepté de l’évaluer. Monsieur Omar Boucelma, Professeur à l’Université d’Aix-Marseille, pour avoir accepté d’examiner mon travail et de faire partie du jury de cette thèse. Madame Christine Collet, Professeur à Grenoble INP et responsable de l’équipe HADAS au LIG, pour avoir assuré la direction de cette thèse, et pour la confiance qu’elle m’a témoignée. Ce manuscrit doit beaucoup à ses suggestions et ses relectures attentives. Madame Genoveva Vargas-Solar, Chargé de recherche au CNRS, pour avoir assuré le coencadrement de cette thèse, et pour ses conseils avisés qui m’ont permis d’avancer vers des résultats meilleurs. Monsieur José Luis Zechinelli Martini, professeur à l’Universidad de las Americas à Puebla, Mexique, pour m’avoir accueilli dans son équipe lors de mes séjours scientifiques au Mexique. Les membres de l’équipe HADAS pour leur soutien tout au long de la réalisation de cette thèse. Un merci particulier à Noha pour son encouragement continu et à Mustafa pour sa participation active dans mes démarches administratives pour soutenir cette thèse. Je remercie, également, mes collègues du bureau pour les riches discussions que nous avons partagées. Mes remerciements vont naturellement à Mireille et aux familles Khalaf, Bibent, Messmer et Suc pour leur amitié, leur gentillesse et pour les moments agréables passés ensemble. Je tiens aussi à remercier Fatin, Sherine, Omar, Timo et Jordi pour leurs constants encouragements et pour avoir su me réconforter dans des moments difficiles. Je ne saurai terminer sans adresser tous mes remerciements à ma famille dont la confiance et le soutien n’ont jamais fait défaut.3 TABLE%DES%MATIERES CHAPITRE)1)INTRODUCTION..............................................................................................11 1.1 Contexte......................................................................................................................11 1.2 Problématique ............................................................................................................12 1.3 Objectif!et!approche ...................................................................................................13 1.4 Organisation!du!document .........................................................................................14 CHAPITRE)2)MASHUPS)ET)DISPONILBILITE)DE)DONNEES)SUR)LE)WEB ................................15 2.1 Modèles!de!Mashups..................................................................................................15 2.1.1 Modèles!de!données.............................................................................................16 2.1.2 Opérateur!de!données..........................................................................................17 2.1.3 Mashlet.................................................................................................................18 2.1.4 Wiring ...................................................................................................................19 2.1.5 Mashup .................................................................................................................19 2.1.6 Modèle!relationnel!de!mashups...........................................................................20 2.1.7 Modèle!de!Hoyer ..................................................................................................21 2.1.8 Modèle!de!mashups!MACE...................................................................................22 2.2 Systèmes!d’exécution!de!mashups.............................................................................22 2.2.1 Architecture!générale ...........................................................................................22 2.2.2 Déploiement .........................................................................................................24 2.3 Disponibilité!de!données!fraiches!sur!le!web..............................................................26 2.3.1 Mesure!de!la!disponibilité!de!données!dans!les!mashups....................................26 2.3.2 Rafraichissement!de!données!des!mashups.........................................................27 2.3.3 Disponibilité!de!données!par!la!réplication ..........................................................28 2.3.4 Disponibilité!de!données!par!le!cache ..................................................................29 2.4 Conclusion...................................................................................................................32 CHAPITRE)3)MODELE)DE MASHUPS ...................................................................................33 3.1 Données!de!mashups..................................................................................................34 3.1.1 Types!de!données.................................................................................................!34 3.1.2 Instances!des!types...............................................................................................35 3.1.3 Types!et!valeurs!d’instances.................................................................................38 3.1.4 Opérations!sur!les!instances.................................................................................38 3.2 Activité ........................................................................................................................39 3.2.1 Activités!basiques .................................................................................................!39 3.2.2 Activités!composites.............................................................................................44 3.2.3 Définition!du!domaine!des!activités!O..................................................................47 3.3 Mashlet .......................................................................................................................47 3.4 Wiring..........................................................................................................................49 3.5 Mashup .......................................................................................................................51 3.6 Conclusion...................................................................................................................534 CHAPITRE)4)EXECUTION DE)MASHUPS)AVEC)DISPONIBILITE)DE)DONNEES .........................55 4.1 Exécution!d’un!mashup...............................................................................................56 4.1.1 Exécution!d’une!activité........................................................................................57 4.1.2 Exécution!d’un!mashlet ........................................................................................62 4.1.3 Exécution!d’un!wiring ...........................................................................................62 4.2 Disponibilité!des!données!dans!les!mashups..............................................................63 4.2.1 Organisation!de!données!du!Store.......................................................................65 4.2.2 Gestion!du!Store...................................................................................................66 4.2.3 Remplacement!de!données..................................................................................68 4.2.4 Rafraichissement!de!données...............................................................................70 4.2.5 Exécution!d’un!nœud!Retrieve++ .........................................................................74 4.3 Conclusion...................................................................................................................75 CHAPITRE)5)IMPLANTATION)DE)MELQART ........................................................................77 5.1 Architecture!du!système .............................................................................................78 5.2 Valeurs!complexes ......................................................................................................80 5.3 Activité ........................................................................................................................81 5.3.1 Activités!basiques .................................................................................................!82 5.3.2 Activités!composites.............................................................................................86 5.4 Mashlet .......................................................................................................................93 5.5 Wiring..........................................................................................................................94 5.6 Mashup .......................................................................................................................94 5.7 Item.............................................................................................................................96 5.8 Store............................................................................................................................97 5.9 ReplacementManager.................................................................................................!97 5.10 FreshnessManager....................................................................................................98 5.11 Interaction!des!mashups!avec!le!Store ...................................................................100 5.12 Validation................................................................................................................101 5.12.1 ItineraryPlanner................................................................................................102 5.12.2 MyDashboard ...................................................................................................104 5.12.3 Execution!des!instances!des!mashups..............................................................105 5.13 Conclusion...............................................................................................................105 CHAPITRE)6)CONCLUSION)................................................................................................)107 6.1 Contribution!et!bilan.................................................................................................!107 6.2 Perspectives..............................................................................................................108 BIBLIOGRAPHIE ...............................................................................................................111 ANNEXE)A :))SYSTEMES)D’EXECUTION)DE)MASHUPS)ETUDIES..........................................119 ANNEXE)B :))SYNTAXE)DE)JSON........................................................................................1235 LISTE%DES%TABLEAUX Tableau!1 :!Modèle!de!données!des!mashups!dans!les!outils/modèles!étudiés...................................................17 Tableau!2 :!Opérateurs!proposés!dans!les!outils!étudiés......................................................................................18 Tableau!3 :!Gestion!de!wirings!dans!les outils!étudiés..........................................................................................19 Tableau!4 :!Protocoles!d'accès!aux!données!des!fournisseurs!dans!les!outils!de!mashups!étudiés.....................23 Tableau!5 :!Coût!des!opérations!dans!différentes!structures!de!données............................................................74 Tableau!6 :!Durées!des!vies!des!données du!mashup!ItineraryPlanner..............................................................103 Tableau!7 :!Durées!des!vies!des!données!du!mashup!MyDashboard .................................................................!1057 LISTE DES"FIGURES Figure!1!:!Le!mashup!ItineraryPlanner ..................................................................................................................12 Figure!2!:!Logique!applicative!de!mashup!ItineraryPlanner..................................................................................13 Figure!3 :!Échange!de!données!entre!les!mashlets!Map!et!Weather!défini!par!un!wiring....................................19 Figure!4!:!Modèle!de!mashups!de!Hoyer...............................................................................................................21 Figure!5!:!Les!composants!d'une!architecture!générale!d'un!système!d'exécution!de!mashups..........................23 Figure!6:!Diagra .........................................................................................................................................................!! mme!de!déploiement!des!composants!d'un!système!d’exécution!de!mashups!(côté!client)...............................24 Figure!7!:!Diagramme!de!communication!illustrant!le!fonctionnement!d'un!mashup!exécuté!côté!Client..........25 Figure!8!:!Diagramme!de!déploiement!des!composants!d'un!système!d’exécution!de!mashups!(côté!serveur)!.!25 Figure!9!:!Diagramme!de!communication!illustrant!le!fonctionnement!d'un!mashup!exécuté!côté!serveur.......26 Figure!10 :!Architecture!du!cache!distribué!proposé!dans![91] ............................................................................30 Figure!11 :!Pile!de!concepts!de!mashups ..............................................................................................................34 Figure!12!:!Représentation!graphique!d'une!activité ............................................................................................39 Figure!13!:!Représentation!graphique!d'une!activité!Sequence ............................................................................45 Figure!14!:!Représentation!graphique!d’un!exemple!d’une!activité!Sequence .....................................................45 Figure!15!:!Représentation!graphique!d'une!activité!Foreach ..............................................................................46 Figure!16!:!Représentation!graphique!d’un!exemple!d’une!activité!Foreach .......................................................46 Figure!17!:!Représentation!graphique!d'une!activité!Parallel ...............................................................................47 Figure!18!:!Représentation!graphique!d'un!mashlet.............................................................................................48 Figure!19!:!Représentation!graphique!du!mashlet!Map........................................................................................48 Figure!20!:!Représentation!graphique!du!mashlet!Weather.................................................................................49 Figure!21!:!Représentation!graphique!d'un!wiring................................................................................................50 Figure!22!:!Représentation!graphique!du!wiring!entre!les!mashlets!Map!et!Weather.........................................51 Figure!23!:!Représentation!graphique!du!mashup!ItineraryPlanner.....................................................................52 Figure!24!:!Diagramme!d’activité!UML!de!l’exécution!d’un!mashup ....................................................................56 Figure!25!:!Graphe!du!mashup!ItineraryPlanner...................................................................................................57 Figure!26!:!Exécution!du!mashup!ItineraryPlanner ...............................................................................................58 Figure!27!:!Arbre!de!l’activité!du!wiring!Map2Weather .......................................................................................58 Figure!28!:!Exécution!du!mashup!ItineraryPlanner ...............................................................................................59 Figure!29!:!Composition!d'un!nœud!d'une!activité!basique..................................................................................598 Figure!30!:!Diagramme!d’activité!UML!du!processus!d’exécution!d'une!activité!basique ....................................60 Figure!31!:!Diagramme!de!communication!entre!le!nœud!Retrieve et!le!fournisseur!de!données ......................60 Figure!32 :!Arbre!de!nœuds!d’une!activité!Sequence ...........................................................................................61 Figure!33!:!diagramme!d’activité!UML!du!processus!d’exécution!d'une!activité!Sequence..................................61 Figure!34 :!Diagramme!d’activité!UML!de!l’exécution!d’un!mashlet ....................................................................62 Figure!35!:!Diagramme!d’activité!UML!de!l’exécution!d’un!wiring .......................................................................63 Figure!36!:!Diagramme!de!communication!UML!entre!le!nœud!Retrieve++,!le!fournisseur!de!données!et!le Store .......................................................................................................................................................................63 Figure!37 :!Exécution!d’un!mashup!avec!disponibilité!de!données.......................................................................64 Figure!38!:!Représentation!du!Store .....................................................................................................................66 Figure!39!:!Utilisation!des!fonctionnalités!de!gestion!du!Store dans!l’exécution!d’un!nœud!Retrieve++.............67 Figure!40!:!Utilisation!de!la!fonction!makeroom dans!l’exécution!d’un!nœud!Retrieve++ ..................................68 Figure!41 :!Rafraichissement!des!items.................................................................................................................70 Figure!42!:!Exécution!d'un!nœud!Retrieve++ ........................................................................................................75 Figure!43!:!Approche!de!MELQART!pour!la!création!et!l’exécution!des!mashups................................................78 Figure!44 :!Interaction!des!utilisateurs!avec!MELQART.........................................................................................78 Figure!45!:!Architecture!de!MELQART...................................................................................................................79 Figure!46!:!Classe!Activity......................................................................................................................................82 Figure!47!:!Les!classes!des!activités!basiques........................................................................................................83 Figure!48!:!Les!classes!des!activités!composites....................................................................................................87 Figure!49 :!Exécution!de!la!méthode!run()!d’une!instance!de!la!classe!Sequence................................................88 Figure!50!:!Exécution!de!la!méthode!run()!d'une!instance!de!WOEIDCitySeq ......................................................89 Figure!51 :!Exécution!de!la!méthode!run()!d’une!instance!de!la!classe!Foreach...................................................90 Figure!52!:!Exécution!de!la!méthode!run()!d’une!instance!de!CitiesListForeach ..................................................91 Figure!53!:!Interactions!entre!une!activité!Parallel!et!ses!soushactivités ..............................................................92 Figure!54!:!Classe!Mashlet.....................................................................................................................................93 Figure!55!:!Interaction!entre!une!instance!de!Mashlet!et!son!activité..................................................................93 Figure!56!:!Classe!Wiring .......................................................................................................................................94 Figure!57!:!Classe!Mashup.....................................................................................................................................95 Figure!58!:!Classe!Item ..........................................................................................................................................96 Figure!59!:!Instance!de!la!classe!Item....................................................................................................................96 Figure!60!:!Classe!Store .........................................................................................................................................97 Figure!61!:!La!classe!ReplacementManager ..........................................................................................................98 Figure!62!:!La!classe!FreshnessManager ...............................................................................................................99 Figure!63!:!Exécution!de!la!méthode!run()!de!l'activité!Retrieve!avec!utilisation!du!Store ................................101 Figure!64!:!Résultats!du!mashup!ItinerayPlanner!pour!l’itinéraire!de!Grenoble!à!Paris .....................................103 Figure!65!:!Résultats!du!mashup!MyDashboard!avec!Grenoble!comme!paramètre!en!entrée. .........................104 Figure!66!:!Chronologie!des!exécutions ..............................................................................................................1069 Figure!67!:!Sources!de!données!dans!Montage...................................................................................................119 Figure!68!:!Construction!de!mashlets!dans!Yahoo!!Pipes....................................................................................120 Figure!69!:!Architecture!de!MSS..........................................................................................................................122 Figure!70!:!Syntaxe!de!JSON................................................................................................................................12311 Chapitre!1 INTRODUCTION 1.1 Contexte A l'origine, le terme mashup désigne un morceau musical hybride composé d’échantillons de musique issus de chansons différentes. Par analogie, en Informatique, un mashup est une application web qui combine des ressources (données, fonctionnalités etc.) provenant de sources hétérogènes. Ces ressources sont agrégées pour former un résultat affiché dans des composants appelés mashlets, comme iGoogle1 . Une des premières définitions des mashups apparaît en 2006 dans [1] : “Mashups are an exciting genre of interactive Web applications that draw upon content retrieved from external data sources to create entirely new and innovative services”. Les mashups sont utilisés dans différents domaines comme la biologie [2], la santé [3], l’électroménager [4], la formation en ligne (E-learning) [5][6] et la gestion des documents en entreprise [7]. Exemple de mashup Supposons qu'Alice veuille planifier un voyage de Grenoble à Paris et qu'elle veuille déterminer l'itinéraire qu'elle va prendre, ainsi que les prévisions météorologiques dans les villes de passage. Comme le voyage est long, Alice aura faim à l’arrivée. Elle voudrait choisir un restaurant parmi une liste de restaurants proposés ayant une moyenne de notes supérieure à 3 sur 5. Au lieu de contacter des services sur le Web de manière séparée, Alice veut exprimer ses besoins d’une manière globale et avoir les réponses de différents services sur une même page Web. Pour cela, Alice a recours à un mashup qui combine des données issues des services disponibles sur le web comme Google maps et Yahoo météo et Google Places. Le mashup est composé de trois mashlets affichant l’itinéraire, les conditions météorologiques et la liste de restaurants. Dans ce document, nous nous référons à ce mashup sous le nom d’ItineraryPlanner (illustré dans la Figure 1). Nous avons choisi ce scénario parce qu’il intègre des données de nature hétérogènes : dynamiques et multimédia où l’on prend en considération des données spatiales comme dans [8][9]. Un mashup fonctionne selon une logique applicative. Les deux points clés de cette logique applicative sont les services de données et la coordination des appels des services. Les services font office de fournisseurs des données par des appels des méthodes. La coordination sert à coordonner la récupération et la transformation de données afin de pouvoir les échanger entre les composants du mashup. Les fonctions de gestion de données qui en ressortent sont : 1 http://www.google.fr/ig, Google a mis fin à ce service en novembre 2013.12 Figure'1':'Le'mashup'ItineraryPlanner • La récupération de données : o À partir des services de données en appelant des méthodes exportées par ces services, par exemple obtenir l’itinéraire entre Grenoble et Paris sollicité depuis le service Google maps. o En interagissant avec les utilisateurs à travers des interfaces fournies par le mashup : par exemple, entrer la ville de départ et la destination. • La transformation de données récupérées pour les afficher de manière agrégée ou adaptée au dispositif utilisé pour les visualiser. Il s’agit de mettre en place cette transformation au sein et entre les mashlets. • L’échange de données : les données transformées peuvent servir comme entrée pour appeler d’autres services. Par exemple, les villes de passage dans l’itinéraire obtenu de Google maps, sont envoyées à Yahoo! Weather pour obtenir les informations sur les conditions météorologiques dans ces villes. La Figure 2 présente la logique applicative du mashup ItineraryPlanner définie avec l’outil Yahoo! Pipes [10]. Le mashlet Map s’adresse à Google maps pour récupérer l’itinéraire, ceci est suivi par une transformation pour récupérer les villes intermédiaires et les mettre dans le bon format pour les envoyer d’une manière itérative à Yahoo! Weather pour récupérer la météo. Les coordonnées de la ville d’arrivée sont récupérées par le mashlet Restaurants pour récupérer une liste de restaurants auprès du service Google Places. Cette gestion de données s’appuie sur une hypothèse forte et que nous adoptons : les interfaces des services ont des paramètres d’entrée/sortie typés selon un modèle de données de mashups. Ceci revient à considérer qu’il y a un mapping implicite entre les modèles des données sous-jacents aux services et le modèle de données propre aux mashups. 1.2 Problématique Les travaux existants, sur les mashups, se sont intéressés principalement à leur fonctionnement et aux différentes manières de les construire [11][12][13][14], aux domaines de leur utilisation et à l’interaction avec les utilisateurs [15][16][17]. Dans cette thèse nous nous intéressons à la gestion de données dans les mashups et plus particulièrement à la disponibilité des données fraîches dans les mashups. Améliorer la disponibilité des données au sein d’un mashup se définit à travers les aspects suivants : 13 Figure'2':'Logique'applicative'de'mashup'ItineraryPlanner • La continuité d’accès aux données même si le service est inaccessible. • La gestion de la fraîcheur de données du mashup. Ces données sont de nature dynamique et une mauvaise stratégie de mise à jour peut engendrer des mashups avec des données périmées. • Éviter de récupérer la même donnée plusieurs fois. L’approfondissement de ces problèmes nous a amené à nous poser différentes questions : • Quelles sont les données dont on a besoin pour le bon fonctionnement du mashup ? et comment les identifier dans les résultats des appels services ? • Comment retrouver ces données ? • Comment garder la fraicheur de ces données ? 1.3 Objectif)et)approche L’objectif de cette thèse est de proposer une approche pour améliorer la disponibilité des données des mashups qui garantit : • L’accès aux données même si le service est indisponible pour maintenir un mashup en état de fonctionnement. • La fraicheur de données et pour cela il faut prendre en compte la durée entre deux appels qui doit faire l’objet d’un compromis entre les caractéristiques du service et les besoins de l’utilisateur. • Un partage de données entre les mashups et les mashlets. Ce partage permet d’augmenter la probabilité de disponibilité de données.14 Pour atteindre cet objectif, nous proposons MELQART 2 un système d’exécution de mashups avec un mécanisme de disponibilité de données. Notre contribution inclut : • Une étude de l’état de l’art présentant une analyse des modèles de mashups existants et de leurs concepts ainsi que les travaux existants sur les systèmes d’exécution des mashups et sur la disponibilité et la fraicheur de données du web. L’étude de ces travaux constitue une base à partir de laquelle nous proposons notre approche pour améliorer la disponibilité des données des mashups. • La définition d’un modèle de mashups qui s’appuie sur les modèles de valeurs complexes [19]. Ce modèle permet de spécifier les caractéristiques de la disponibilité de données. Les concepts de ce modèle sont illustrés avec notre scénario ItineraryPlanner. • La définition du principe d’exécution de mashups selon le modèle de mashup proposé. Nous améliorons la disponibilité et la fraicheur des données du mashup par des fonctionnalités orthogonales à son processus d’exécution. Ces fonctionnalités prennent en charge la gestion et le rafraichissement de données 1.4 Organisation)du)document Le reste du document est organisé comme suit : • Le Chapitre 2 présente les concepts et les modèles des mashups (aspect statique des mashups) et étudie l’architecture générale des systèmes d’exécution de mashups existants (aspect dynamique des mashups). Ensuite, il s’intéresse à la disponibilité des données fraiches sur le web et aux solutions logicielles possibles pour la garantir. • Le Chapitre 3 présente les concepts de notre modèle de mashup. Parmi eux nous retrouvons les données, les mashlets etc. • Le Chapitre 4 commence par introduire les principaux éléments de l’exécution d’un mashup. Ensuite, il décrit notre proposition pour assurer la disponibilité de données lors de l’exécution des mashups et son intégration au processus d’exécution de mashups. Cette solution est à base de fonctions que nous associons d’une façon orthogonale au processus d’exécution de mashups. • Le Chapitre 5 décrit l’implantation et la validation d’un prototype de MELQART. Il commence par présenter l’architecture du système et l’implantation des concepts de notre modèle de mashups et des fonctionnalité proposées pour améliorer la disponibilité de données fraiches des mashups. L’implantation est décrite avec les diagrammes de classes et de séquence de la notation UML. Ensuite le chapitre présente la validation de notre implantation avec l’exécution de plusieurs instances de deux scenarios de mashups. • Le Chapitre 6 récapitule les principaux éléments de notre contribution et présente des orientations définissant la perspective de notre travail afin de l’améliorer et le consolider. 2 Dans la mythologie phénicienne, Melqart [18] signifie le roi (melk) de la cité (qart). Il est le dieu et protecteur de Tyr et de ses activités commerciales. Il accompagna les navigateurs phéniciens dans leur colonisation de la Méditerranée. Il est assimilé à Héraclès dans la mythologie gréco-romaine.15 Chapitre!2 MASHUPS%ET DISPONILBILITE+DE+DONNEES#SUR# LE#WEB Ce chapitre présente les travaux existants dans les domaines des mashups (modèles et systèmes d’exécution de mashups) et de la disponibilité et la fraicheur de données du web. L’étude de ces travaux constitue une base à partir de laquelle nous proposons notre approche pour améliorer la disponibilité des données des mashups. Le chapitre est organisé de la manière suivante : la section 2.1 présente les concepts et les modèles des mashups (aspect statique des mashups). La section 2.2 étudie l’architecture générale des systèmes d’exécution de mashups existants (aspect dynamique des mashups). Ensuite, la section 2.3 s’intéresse à la disponibilité des données fraiches sur le web et aux solutions logicielles possibles pour la garantir. Enfin, la section 2.4 conclut le chapitre. 2.1 Modèles)de)Mashups Cette section décrit les modèles existants de mashups. Nous avons constaté qu’il y a peu de travaux qui ont proposé des modèles de mashups (ceci est dû à l’apparition récente de cette notion de mashups) et que la plupart se sont focalisés sur les outils de création et d’exécution de mashups et leur fonctionnement. L’étude des modèles et des outils proposés (cf. Annexe A) nous a permis d’identifier les concepts nécessaires pour décrire un mashup. Donnée, Operateur, Mashlet, Wiring et Mashup. Un mashlet affiche des données définies selon un certain modèle de données. Elles sont récupérées auprès des fournisseurs de données. Des opérateurs décrivent la manipulation de ces données. Un mashup est un ensemble de mashlets qui échangent des données via des wirings. Dans le scenario ItineraryPlanner, introduit dans le Chapitre 1, ces concepts se présentent comme suit : • Les données sont récupérées depuis des fournisseurs de données : Google maps, Yahoo! Weather et Google Places. • Les opérateurs décrivent le traitement de ces données. • Les mashlets (Map, Weather, Restaurants) constituent les composants qui affichent les résultats. • Deux wirings décrivent le transfert de la liste de villes de passage de Map vers Weather, et celui des coordonnées de la ville d’arrivée de Map vers Restaurants). • Le mashup ItineraryPlanner est constitué des mashlets Map, Weather, Restaurants et des wirings sous-jacents.16 Ces concepts sont présentés dans les sous-sections 2.1.1 à 2.1.5. Ensuite les sous-sections 2.1.6, 2.1.7 et 2.1.8 présentent des modèles de mashups étudiés dans l’état de l’art. 2.1.1 Modèles)de)données Les données des mashups peuvent être définies selon différents modèles de données3 . Dans cette sous-section, nous présentons les modèles de données utilisées dans les modèles et les outils de mashups étudiés. • Le modèle relationnel [21] fut introduit pour pallier aux lacunes du modèle hiérarchique et du modèle réseau, comme la redondance et la rigidité. Il permet d’assurer une indépendance de données et d’améliorer les langages de requête. Il est basé sur les concepts de la théorie des relations. Le modèle relationnel de données est adopté dans le modèle relationnel de mashups [3] (cf. sous-section 2.1.6). Les auteurs y considèrent, également, que toutes les données (provenant de fournisseurs externes ou manipulées au sein des mashups) sont décrites selon le modèle relationnel. Ce choix de modélisation de données est justifié par les bases mathématiques du modèle relationnel. • Les modèles orientés objet furent proposés pour rapprocher les bases de données aux langages de programmation. Certains travaux ont focalisé sur l’intégration des caractéristiques de persistance et de transactions, présentes dans les SGBDs, aux langages de programmation orientées-objet. Tandis que d’autres ont focalisé sur l’intégration des caractéristiques de l’orienté-objet aux SGBDs comme l’encapsulation, la hiérarchie des classes ou l’attachement dynamique (dynamic binding). Ces travaux ont contribué au développement de SGBDs objets comme O2 [22] et SAMOS [23]. Un groupe ODMG (Object Data Management Group) fut crée. Il est responsable de la définition de standards pour les bases de données objets [24] dont le langage OQL (Object Query Language). Le modèle orienté-objet fut adopté par l’outil Popfly [25] de Microsoft. Ce choix est justifié par une proximité recherchée des langages de programmation. Nous n’avons pas pu étudier et tester cet outil, parce que Microsoft y a arrêté son développement avant le début des travaux sur cette thèse. • Les modèles de données semi-structurées sont basés sur une organisation de données dans des structures d’arbres étiquetées ou des graphes et des langages de requêtes pour accéder et modifier les données [26][27]. Les modèles de données semi-structurées sont utilisés pour décrire des données sans schéma explicite. Dans les modèles de données structurés, on distingue entre le type de données (schéma) et les données mêmes. Cependant, cette distinction est estompée dans les modèles de données semi-structurées : on parle de données auto-décrites [27]. Les données semi-structurées le plus répandues sont des données XML. La richesse d’XML provient des langages associés comme XPath, XQuery, XSLT qui facilitent la manipulation des données XML. Le Tableau 1 indique les modèles de données manipulées dans les modèles et les outils de création et d’exécution de mashups étudiés. Nous constatons que la plupart des outils de mashups utilisent des modèles à base d’XML pour représenter les données manipulées. Ceci est justifié par le fait que la plupart des données du web sont décrites avec XML. 3 Un modèle de données fournit les moyens pour (1) spécifier des structures de données, (2) définir un ensemble de contraintes associées à ces structures et (3) et les manipuler [20]. 17 Modèle de données Outil/Modèles de mashups Relationnel Modèle relationnel de mashups [3] Orientés-objet Popfly [25] Semi-structurées Montage [28] (XML), Yahoo! Pipes [10] (flux RSS), Intel MashMaker [29] (RDF), EMML/Presto [30] (XML), MSS [31] (XML), WSO2 Application Server [32] (XML) Tableau'1':'Modèle'de'données'des'mashups'dans'les'outils/modèles'étudiés 2.1.2 Opérateur)de)données Un opérateur de données est modélisé avec une fonction qui manipule des données en entrée pour en produire d’autres en sortie. Les principaux opérateurs de données, pour les différents modèles, sont la jointure, le filtrage, le tri, la troncature, le comptage, l’élimination de doublons etc. Certains fournisseurs de données (Wikipédia, Craiglist4 etc.) n’exposent pas leurs contenus via des méthodes exportées. Ainsi, certains outils offrent des opérateurs décrivant l’extraction des données avec la technique du web scraping 5 [1][33]. Les données extraites sont décrites selon le modèle de données adopté dans le mashup. Par exemple, le mashup HousingMaps6 a recours à cette technique pour extraire les annonces depuis le site Craiglist. Le Tableau 2 indique la nature des opérateurs définis dans les outils de création et d’exécution de mashups étudiés. Nous constatons que les outils, qui s’adressent à des utilisateurs sans compétence en programmation (comme Montage, Intel MashMaker), proposent peu d’opérateurs, offrant ainsi une moindre complexité pour construire un mashup. D’autre part, certains outils nécessitent des compétences en programmation comme WSO2 Mashup Server. Les outils Yahoo ! Pipes et Presto offrent des opérateurs similaires pour manipuler les données. Le modèle relationnel de mashups ne propose pas d’opérateurs pour manipuler les données ; Ils font partie des perspectives évoquées par les auteurs. L’outil MSS propose un langage de manipulation de données : Mashup Service Query Langage (MSQL). Celui-ci est basé sur le langage SQL et il est enrichi avec des opérateurs exécutant des tâches spécifiques interprétées selon une ontologie propre à MSS (par exemple, « trouver des maisons », « trouver des vols »). Modèle relationnel de mashups • Récupération de données par appel de services. • Ce modèle ne propose pas d’opérateurs pour manipuler les données. A l’heure actuelle, les données récupérées sont rendues en entier. Néanmoins, les auteurs proposent, dans leur perspective, d’enrichir le modèle avec des opérateurs de manipulation de données. (cf. soussection 2.1.6) Montage Récupération de flux RSS. 4 Craiglist est un site web américain de petites annonces 5 Un web scraper est un programme qui extrait des données depuis un site web dans le but de les exploiter. 6 http://www.housingmaps.com/18 Yahoo! Pipes L'ensemble des opérateurs de Yahoo! Pipes comprend : • Les opérateurs de récupération de données : depuis des services REST ou bien des flux RSS. • Les opérateurs de transformation de données (tri, filtrage, élimination de doublons, troncature, inverser une liste, l’extraction de données) • les opérateurs arithmétiques • les opérateurs sur les expressions régulières. Intel MashMaker Les données sont manipulées avec des formules comme dans les feuilles de calcul. WSO2 Mashup Server Les opérations sont définies avec un code JavaScript. EMML/Presto L'ensemble des opérateurs de EMML / Presto : • Les opérateurs de récupération de données : depuis des services REST, SOAP ou bien des flux RSS ou bien par le web scraping. • Les opérateurs de transformation de données (jointure, tri, filtrage, élimination de doublons, troncature, inverser une liste, extraction de données). • Des opérateurs définis par encapsulation de code JavaScript, XQuery. MSS L’ensemble des opérateurs de MSS comprend : • Des opérateurs qui réalisent des tâches que nous retrouvons dans le langage SQL comme la sélection, la jointure. • Des opérateurs exécutant des tâches spécifiques interprétées selon l’ontologie de MSS (par exemple, « trouver des maisons », « trouver des vols »). Tableau'2':'Opérateurs'proposés'dans'les'outils'étudiés 2.1.3 Mashlet Un mashlet est un composant graphique qui affiche des données sous la forme d’un widget. Il récupère des données auprès de fournisseurs de données, il les manipule avec des opérateurs de données et il les retourne en sortie. Les données produites sont alors visualisées graphiquement. Par exemple, le mashup ItineraryPlanner (défini dans le Chapitre 1) contient trois mashlets : le premier « Map » permet l'affichage de l'itinéraire entre deux villes sur une carte, le deuxième « Weather » se charge d’afficher les informations météorologiques dans les principales villes sur cet itinéraire et le troisième « Restaurants » affiche une liste de restaurants dans la ville d’arrivée. Cette définition n’est pas unique. Elle est générale et couvre les différents points de vue des modèles et les outils étudiés. En effet certains utilisent des terminologies différentes pour désigner ce concept et d’autres ne couvrent pas tous les aspects mentionnées : • Dans [3][34], un mashlet est un composant qui a des données en entrée et en sortie. Il interroge des sources des données, utilise des services web externes et définit la coordination entre ces composants. Il peut intégrer une représentation graphique de ses données.19 • Dans [35][36][37], ce concept est décrit avec le terme largement connu : widget. Un widget est une interface graphique affichant des informations récupérées auprès d’une source de données externe. • Dans [32][38][10][39], les auteurs utilisent même le terme mashup pour désigner ce concept. Un mashup est une application qui combine des données provenant de différentes sources. La combinaison est réalisée par le moyen d’un flot de données. • Enfin, dans [40], les auteurs séparent l’aspect combinaison de données et l’aspect visualisation. Ils désignent la combinaison de données sous le nom de mashup alors que le terme mashlet désigne la visualisation de ces données. 2.1.4 Wiring) Un wiring définit un échange de données entre deux mashlets [35][14][41]. Par exemple, dans le mashup ItineraryPlanner, un wiring (cf. Figure 3) est nécessaire pour envoyer les données des villes de passage depuis le mashlet « Map » au mashlet « Weather ». Dans [34][42], les auteurs intègrent ce concept dans leur outil sans y donner un nom. On parle de navigation entre mashlets. Dans [3], les auteurs intègrent le principe d’échange de données entre mashlet, mais sans lui donner de nom. Figure'3':'Échange'de'données'entre'les'mashlets'Map'et'Weather'défini'par'un'wiring Le Tableau 3 indique les modèles/outils qui permettent de définir des wirings entre les mashlets. Nous constatons que le principe d’échange de données entre les mashlets (définition de wirings) n’est pas omniprésent dans les modèles/outils de mashups étudiées. Par exemple dans iGoogle, les mashlets ne communiquent pas entre eux ; ainsi avec ce genre d’outil, nous ne pouvons pas modéliser le mashup ItineraryPlanner. Ce constat souligne l’hétérogénéité des visions de ce qu’est un mashup. Ceci est dû à l’apparition récente de cette notion de mashups Modèles/Outils intégrant le concept Wiring Modèle relationnel de mashups, Intel MashMaker, WSO2 Mashup Server, Presto Modèles/Outils ne prenant pas en charge le concept Wiring Montage, Yahoo ! Pipes Tableau'3':'Gestion'de'wirings'dans'les'outils'étudiés 2.1.5 Mashup Dans les travaux étudiés, nous avons constaté qu’un mashup est défini sous-différentes terminologies. Dans [31][36], il est défini en tant que technologie émergente qui consiste en la 20 création d’applications ad hoc par des utilisateurs finaux. Dans [1][43][37], un mashup est défini en tant qu’un nouveau type d’applications web qui permettent de combiner de données issues de différents sources. Dans [44], un mashup est défini en tant qu’une approche de développement d’applications qui permet à des utilisateurs finaux de combiner des données provenant de différentes sources. Dans ces définitions, le terme récurrent est application et l’idée sous-jacente est la combinaison de données provenant de différentes sources. Dans les modèles/outils qui intègrent le principe de transfert de données entre mashlets (définition de wirings, voit sous-section 2.1.4), un mashup est vu comme un ensemble de mashlets et de wirings qui coordonnent ces mashlets. Alors que dans les modèles/outils qui n’intègrent pas la définition de wiring, un mashup est vu comme un ensemble de mashlets seulement. Par exemple, le mashup ItineraryPlanner prend en entrée des paramètres indiquant les villes de départ et d’arrivé et un tarif moyen pour les restaurants. Il contient les trois mashlets « Map », « Weather » et « Restaurants ». Il contient aussi deux wirings : le premier pour transférer les villes de passages depuis le mashlet « Map » vers le mashlet « Weather » et le deuxième pour transférer les coordonnées géographiques du lieu d’arrivé depuis le mashlet « Map » vers le mashlet « Restaurants ». Comme indiqué dans la sous-section 2.1.3, le concept de mashlet est parfois désigné avec le terme mashup dans certains modèles/outils. Ceux ci emploient le terme « dashboard » pour faire référence au mashup (en tant qu’ensemble de mashlets). 2.1.6 Modèle)relationnel)de)mashups Dans [3], les auteurs introduisent un modèle relationnel pour définir les mashups de données. Le modèle est basé sur les relations. Ce choix de modélisation est justifié par les bases mathématiques du modèle relationnel. Un mashlet est défini comme un ensemble de relations. Celles ci sont classifiées comme suit : • Relations internes : elles sont utilisées pour contenir des données propres au mashlet et non exposées à d’autres mashlets. • Relations entrée/sortie : elles sont utilisées pour définir l’interface du mashlet via laquelle il interagit avec l’utilisateur et d’autres mashlets. • Relations de service : elles représentent des web services que le mashlet peut importer. L’interaction entre ces relations est définie par des règles actives (du style Datalog [45][46]). Par exemple, soit un mashlet !"#$ dont les relations sont liées par la règle active suivante : !!"# !"#, !"#$%%$, !"# ∶ − !!" ! , !!"#$! !, !"# , !"!"" !"#, !"#$%%$, !"# !!" est une relation qui représente un formulaire où l’utilisateur entre le nom d’une maladie !. La relation locale !!"#$! !, !"# fournit les noms des médecins spécialistes dans le traitement de la maladie !. Soit le service web !"!"" !"#, !"#$%%$, !"# qui fournit l’adresse, et le numéro de téléphone pour un médecin identifié par son nom. La relation !!"# !"#, !"#$%%$, !"# affiche le résultat contenant les noms des médecins, leurs adresses ainsi que leurs numéros de téléphones. 21 Dans le même esprit, les interactions entre mashlets (sans mention du terme wiring) peuvent être décrites avec des règles actives. Soit un mashlet !"#$%& qui affiche les adresses des médecins sur une carte. Il importe la relation de sortie du mashlet !"#$ via la règle active suivante7 : !"#$%&. !"#!" !, !, !"# ∶ − !"#$. !!"# !"#, !"#$%%$, !"# , !""#$%&'!"" !"#$%!", !, ! L’adresse, donnée par la relation !"#$. !!"# !"#, !"#$%%$, !"# , est convertie en coordonnées géographiques ! et ! via le service web !""#$%&'!"". Un mashup est vu comme un réseau de mashlets qui interagissent entre eux. Les auteurs évoquent le besoin éventuel de manipuler les données (filtrage tri etc.). Pour répondre à ce besoin, ils proposent, dans une perspective ultérieure, la possibilité d’enrichir les règles actives avec des fonctions de manipulation de données ou de déléguer ces fonctionnalités à des services web. 2.1.7 Modèle)de)Hoyer Dans [37], les auteurs proposent un modèle des concepts de mashups. Il est fait avec un digramme de classes de la notation UML (Figure 4 8 ). Ils y introduisent la notion d’usage qui correspond à l’autorisation de l’utilisation d’une ressource ou d’un mashlet (widget) par une certaine personne (client) contre certaines conditions et certains frais. Les « pipings » correspondent aux opérateurs d’agrégation de données. Un wiring y est défini comme étant un moyen de communication entre deux widgets avec des paramètres de mapping indiquant les connections entre les entrées et les sorties des widgets. Figure'4':'Modèle'de'mashups'de'Hoyer 7 Une relation ! d’un mashlet ! est notée !. ! 8 Image obtenue de [37]. 22 2.1.8 Modèle)de)mashups)MACE MACE [39] est une plateforme de cache pour les mashups. Les auteurs y intègrent une proposition d’un modèle de mashups. Un mashup9 (1) récupère des données depuis des sources différentes, (2) les manipules et (3) les retournes à l’utilisateur final. !"#$% = !"! , !"! , … , !"!!! représente l’ensemble de mashups définis dans la plateforme de mashups à un moment donnée. La plateforme de mashup inclut un ensemble de classes d’opérateurs décrivant la manipulation des données comme le tri, le filtrage, l’élimination de doublons, la troncature, la jointure, le comptage, l’extraction de données. Les auteurs introduisent deux classes d’opérateurs décrivant la récupération de données depuis une source externe (fetch) et la livraison du résultat (dispatch). !"#$% = !"! , !"! , … , !"!!! dénote l’ensemble de classes d’opérateurs disponibles dans la plateforme de mashups. Chaque classe d’opérateur définit sa propre signature. Un mashup comprend un ensemble d’instances d’opérateurs de !"#$%. Cet ensemble contient un ou plusieurs instances de l’opérateur fetch et une seule instance de l’opérateur dispatch. Un mashup est modélisé avec une structure d’arbre. Chaque nœud correspond à une instance d’opérateur. Le nœud racine correspond à l’instance de l’opérateur dispatch et les nœuds feuilles correspondent aux instances de l’opérateur fetch. La valeur de la sortie de l’instance d’opérateur d’un nœud est l’entrée (ou une des entrées) de l’instance d’opérateur du nœud parent. Les mashups, vus comme des arbres, peuvent partager les données provenant des mêmes sources. Ainsi l’ensemble des mashups forme des graphes orientés acycliques (Directed Acyclic Graphs DAGs). 2.2 Systèmes)d’exécution)de)mashups Cette section présente les composants d’une architecture générale des systèmes d’exécution de mashups (sous-section 2.2.1). Ensuite, elle présente les manières de déploiement de ces composants (sous-section 2.2.2). La présentation est accompagnée d’un positionnement des systèmes d’exécution des outils étudiés par rapport à l’architecture et au déploiement des composants. 2.2.1 Architecture)générale La Figure 5 présente l’architecture générale, d’un système d’exécution de mashups, déduite à partir de nos lectures des travaux existants. D’un point de vue architectural, les systèmes d’exécution de mashups mettent en jeu plusieurs composants disjoints qui interagissent entre eux pour réaliser l’exécution des mashups. Tous ces composants ne sont pas présents dans toutes les architectures : • Les fournisseurs de données (Providers) sont des composants autonomes que l’on peut interroger (Invoke) à l’aide d’une requête ayant un ou plusieurs paramètres. L’interrogation de ces fournisseurs se fait selon un protocole d’accès. Ils ne font pas partie des systèmes de mashups. Cependant, nous les évoquons pour illustrer et comparer les capacités des outils étudiés à interagir avec des fournisseurs hétérogènes. Le Tableau 4 indique les protocoles 9 Notons que cette définition correspond au concept mashlet présenté à la sous-section 2.1.3 où nous avons souligné que dans certains modèles/outils le concept de mashlet est parfois désigné avec le terme mashup.23 d'accès aux données des fournisseurs pris en charge dans les outils de mashups étudiés. Pour un outil de mashup, plus le nombre de protocoles d’accès pris en charge est grand, plus le choix offert de fournisseurs de données est large lors de la création de mashups. Montage Yahoo ! Pipes Intel MashMaker WSO2 Mashup Server Presto MSS REST10 REST, HTTP11 HTTP REST, SOAP12, HTTP REST, SOAP, HTTP SOAP Tableau'4':'Protocoles'd'accès'aux'données'des'fournisseurs'dans'les'outils'de'mashups'étudiés • Le Catalog est un composant optionnel qui n’est pas présent dans tous les outils de mashups. Il enregistre les mashlets et les mashups crées et les mets à disposition des utilisateurs des mashups Tous les outils d’exécution de mashups étudiés intègrent le composant Store sauf MSS où l’utilisateur doit définir son besoin sans avoir recourir à un tel composant. • Le composant MashupGUI, généralement un navigateur web, constitue l’interface via laquelle l’utilisateur choisit un mashup depuis le Catalog et demande son exécution au composant MashupEngine. • Le composant MashupEngine est responsable de l’exécution des mashups. Il interagit avec les composants Providers afin de récupérer des données. o Dans les outils Montage (comme dans iGoogle), le composant retourne ces données directement à l’utilisateur (via le composant MashupGUI). o Dans les autres outils étudiés, ce composant manipule ces données et coordonne les exécutions des mashlets et des wirings des mashups. Il contient un buffer qui offre les outils pour le stockage temporaire de données en cours de traitement. Le résultat est retourné au composant MashupGUI. Figure'5':'Les'composants'd'une'architecture'générale'd'un'système'd'exécution'de'mashups 10 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm 11 http://www.w3.org/Protocols/rfc2616/rfc2616.html 12 http://www.w3.org/TR/soap/24 2.2.2 Déploiement L’amélioration de la disponibilité de données des mashups est impactée par les choix faits au niveau du déploiement des composants présentés dans la sous-section 2.2.1. En effet, sa portée est limitée à l’endroit où les mashups sont exécutés. D’un point de vue du déploiement, les systèmes d’exécution de mashups sont classés en 2 catégories [47][48][49][11] : les systèmes où les mashups sont exécutés côté serveur (server-side mashup) et les systèmes où les mashups sont exécutés côté client (client-side mashup). (a) Côté(client Dans un mashup exécuté côté client (client-side mashup) la récupération et la manipulation de données se produisent chez le client, généralement dans un navigateur Web. La Figure 6 présente le diagramme de déploiement dans un environnement où les mashups sont exécutés côté client. On y remarque que le composant responsable de l’exécution des mashups est déployé sur la machine de l’utilisateur final. Ce choix de déploiement est adopté par l’outil Intel MashMaker [50]. Celui ci fonctionne en tant qu’une extension de navigateur web qui manipule de données contenues dans des pages web. Figure'6:'Diagramme'de'déploiement'des'composants'd'un'système'd’exécution'de'mashups'(côté'client)' La Figure 7 présente le diagramme de communication13 illustrant le fonctionnement d’un mashup exécuté côté client : 1. L’utilisateur lance le mashup via l’interface graphique (MashupGUI). Ainsi l’interface envoie une requête au serveur des mashups (MashupsServer) pour demander le code source du mashup des paramètres donnés. 2. Le code source du mashup est chargé sur la machine de l’utilisateur. Ce code comprend un script JavaScript qui contient des requêtes pour la récupération des contenus des services de données. 3. La machine du client envoie des demandes de récupération de données auprès des fournisseurs de données (Service). 4. Les fournisseurs de données retournent les données demandées. 5. Les données récupérées sont agrégées pour produire le résultat du mashup. Pour des raisons de sécurité, les navigateurs appliquent la politique « Same Origin Policy 14 » : interdisant, dans une page web, la communication entre le client et plusieurs serveurs 13 Dans la norme UML 1, le diagramme de communication s’appelait diagramme de collaboration. 14 http://www.w3.org/Security/wiki/Same_Origin_Policy Mashup User Machine Mashups Server Store& MashupGUI& MashupEngine&25 (cross-domain communication) 15 . Pour cela la plupart de outils de mashups étudiés privilégient l’exécution des mashups sur un serveur dédié et non sur les machines des clients. Figure'7':'Diagramme'de'communication'illustrant'le'fonctionnement'd'un'mashup'exécuté'côté'Client (b) Côté(serveur Dans un mashup exécuté côté serveur (server-side mashup) la récupération et la manipulation de données se produisent sur le server de mashups. La Figure 8 présente le diagramme de déploiement dans un environnement où les mashups sont exécutés côté serveur. On y remarque que le composant responsable de l’exécution des mashups est déployé sur un serveur de mashups. Ce choix de déploiement est adopté par la plupart de systèmes d’exécutions de mashups étudiés. Plusieurs raisons justifient ce choix : la politique Same Origin Policy ne s’applique pas dans ce cas (voir sous-section 2.2.2(a)) . Ce choix permet d’alléger la quantité de données envoyées au client. Le serveur peut gérer les messages d’erreur des fournisseurs des données avant de retourner un résultat au client. Figure'8':'Diagramme'de'déploiement'des'composants'd'un'système'd’exécution'de'mashups'(côté'serveur) La Figure 9 présente le diagramme de communication illustrant le fonctionnement d’un mashup exécuté côté serveur : 1. L’utilisateur lance le mashup via l’interface graphique (MashupGUI). Ainsi l’interface envoie une requête au serveur des mashups pour exécuter le mashup avec des paramètres donnés. 15 Récemment, HTML5 [51] inclut dans ses spécification une caractéristique Cross-Site XMLHttpRequest autorisant la communication du client avec plusieurs serveurs. :"User"Machine" :"Mashups"server" :"Service"" 1 : Récupération du code source du mashup 2 : code source du mashup 3 : demande de données 4 : données demandées 5 : agrégation de données Mashup User Machine Mashups Server MashupEngine, Store, MashupGUI,26 2. Le serveur de mashups (MashupsServer) envoie des demandes de récupération de données auprès des fournisseurs de données (Service). 3. Les fournisseurs de données retournent les données demandées. 4. Les données récupérées sont agrégées pour produire le résultat du mashup. 5. Le résultat du mashup est retourné à l’interface graphique. Figure'9':'Diagramme'de'communication'illustrant'le'fonctionnement'd'un'mashup'exécuté'côté'serveur 2.3 Disponibilité)de)données fraiches)sur)le)web La disponibilité désigne le fait de pouvoir être rapidement utilisé, d'être à la disposition de quelqu'un. En informatique, la disponibilité de données (data availability) signifie avoir les données obtenues et accessibles à n’importe quel moment [52][53][54]. La fraicheur caractérise l’état de ce qui est frais. En informatique, la fraicheur de données (data freshness) signifie que les données qu’un utilisateur a à disposition sont les mêmes que celles qui peuvent être fournies par le fournisseur de service au même moment [55][56][57]. Cette section étudie la disponibilité de données fraiches sur le web et en particulier dans les mashups. Lors de notre étude de l’état de l’art nous avons constaté que, bien qu’il existe des études qui ont identifié la disponibilité et la fraicheur de données comme des qualités à prendre en compte pour les mashups, il n’existe pas de travaux qui ont proposé des solutions pour garantir la disponibilité des données fraiches dans les mashups. Nous avons identifié (1) des travaux proposant des formules pour mesurer les qualités de la disponibilité et de la fraicheur de données dans les mashups et (2) d’autres travaux proposant des solutions pour améliorer la disponibilité des donnés sur le web. Généralement, la disponibilité de données est garantie et améliorée par différentes solutions logicielles [58][54] comme la réplication [59][60][61] ou le cache [62][63]. Ces solutions peuvent être accompagnées d’une solution orthogonale matérielle qui consiste en la redondance du matériel au niveau des fournisseurs des données [64][65][66]. 2.3.1 Mesure)de)la)disponibilité)de)données)dans)les)mashups) Dans les mashups, la disponibilité des données correspond à la capacité du mashup à fournir les données attendues par l’utilisateur. La disponibilité des données d’un mashup est :"Mashups"server" :"Service"" 1 : lancer l’exécution du mashup 5 : résultat du mashup 2 : demande des 3 : données données demandées :"MashupGUI 4 : agrégation de données 27 relative à la disponibilité de données des fournisseurs. L’exécution d’un mashup peut souffrir d'une indisponibilité des données qui pourrait être causée par de nombreux facteurs : • L’indisponibilité des fournisseurs de données. • La déconnexion du client. • Des limitations d'accès possibles, telles que les licences d’utilisation des services. En fonction du contexte d'utilisation, on peut considérer ces limitations comme des restrictions diminuant la qualité des fournisseurs ou une décision nécessaire pour prévenir la surcharge des fournisseurs qui peut diminuer leur disponibilité. Dans [67], les auteurs présentent cette qualité sous le nom la complétude des données. (data completeness). Celle ci fait référence à la capacité d'un mashup de produire toutes les valeurs de données attendues. Elle est évaluée en estimant le rapport entre la quantité de données récupérées !"# et la quantité de données attendues !"# : ! = !"# !"# D’autre part, les auteurs définissent la disponibilité d’un mashup comme étant la possibilité de fournir les données d’au moins un des mashlets. Ainsi elle est exprimée selon la formule suivante : !"#$% = 1 − (1 − !"#$%! ) ! !!! Dans cette formule, la valeur de !"#$% vaut 0 (non disponible) ou 1 (disponible). !"#$%! désigne la disponibilité d’un mashlet ! du mashup. Si les données d’un des mashlets sont disponibles (i.e. ∃! !"#$%! = 1) alors le produit dans la formule est nul et le mashup est considéré disponible ( !"#$% = 1 − 0 = 1 ). Inversement, si les données de tous les mashlets sont non disponibles (i.e. ∀!, !"#$%! = 0) alors le produit dans la formule vaut 1 et toutes le mashup est non disponible (!"#$% = 1 − 1 = 0). 2.3.2 Rafraichissement)de)données)des)mashups Dans certains cas, le mashup a besoin que les données soient générées et mises à jour en permanence (par exemple, marchés boursiers ou données météorologiques). Un grand nombre de décisions stratégiques, en particulier dans les entreprises, sont généralement faites selon les derniers états ou valeurs des données. Il est donc important qu'un système de mashups propage les mises à jour des sources de données pour les utilisateurs concernés. Dans [68], les auteurs définissent la qualité de la fraicheur d’une donnée sous le terme Timeliness. Elle est mesurée avec la formule suivante : !"#$%"&$'' = !"# 0, 1 − !"##$%!& !"#$%&#&' ! Dans cette formule, l’exposant ! est un facteur qui permet de contrôler la sensibilité de la valeur de la fraicheur au rapport !"##$%!& !"#$%&#&' . La valeur de ! dépend du contexte et elle est fixée d’une façon subjective et elle est sujette d’un jugement de celui qui analyse les données. Dans cette formule la valeur de !"#$%"&$'' varie de 0 à 1. La valeur de !"##$%!& exprime l’âge de la donnée alors que la valeur de !"#$%&#&' exprime la durée de vie fixée pour la donnée selon le contexte. Les données fraiches sont ceux dont le rapport !"##$%!& !"#$%&#&' est inférieur à 1. 28 Dans [67], les auteurs expriment dans une formule la qualité de la fraicheur d’un mashup par rapports aux valeurs du paramètre !"#$%"&$'' des données du mashups. La formule est la suivante : !"#$%"&$''!"#!!" = ! !"#$%"&$'!! , … , !"#$%"&$''! Où ! peut être la fonction maximum, minimum ou moyenne. Elle est définit en fonction du contexte par celui qui analyse les données. La fraicheur des données du web est assurée par un mécanisme de rafraîchissement des données. Il peut être fait suivant deux stratégies [69][70] : pull et push. À l'heure actuelle, les systèmes d’exécution de mashup n’implantent que la stratégie pull. La valeur de la fréquence de récupération est statique. Il y a deux stratégies pour gérer les intervalles de rafraichissement dans les systèmes d’exécution de mashups [69] : • Stratégie globale : Dans cette stratégie l’intervalle de rafraichissement est le même pour toutes les données. il est fixé par le système d’exécution de mashup ou l’utilisateur final. Ce choix est adopté dans : o Yahoo! Pipes : une heure selon [69]. o Popfly : l’intervalle dépend de la fréquence du chargement de la page par l’utilisateur final. o Intel MashMaker : l’intervalle est fixé par défaut par le système d’exécution du mashup. Cependant l’utilisateur final peut demander le rafraichissement d’une page. • Stratégie locale : Dans cette stratégie, un intervalle spécifique de rafraichissement est affecté à chaque source de données. Cette stratégie est adoptée par Damia [38] où les auteurs supposent les valeurs des intervalles de rafraichissement sont indiquées par les fournisseurs de données. 2.3.3 Disponibilité)de)données)par)la)réplication La réplication de données est la création de copies multiples (nœuds de réplication) des données avec l’objectif d’améliorer leur disponibilité et leur fiabilité et d’améliorer les performances d’accès à ces données [61][59]. La plupart des travaux visant à améliorer la disponibilité de données sont basés sur un processus de réplication. Malgré ces avantages, la réplication a un coût qui consiste en le maintien de la cohérence entre les copies d’une même donnée. D’où la naissance d’un compromis entre deux contradictions majeures : assurer la cohérences des copies toute en conservant des QoS de performance. Chaque copie de données est accompagnée de la copie du système d’interrogation sous-jacent. Une politique de réplication fait référence à l’algorithme gérant les différentes copies d’une même donnée [71]. Il existe deux stratégies de propagation des mises à jour : la stratégie impatiente (eager replication) [72]. et la stratégie paresseuse (lazy replication) [73]. Dans le premier cas, la mise à jour est appliquée sur toutes les copies en même temps, au sein d’une même transaction (le nœud traitant la transaction envoie des messages aux autres nœuds avant de procéder au commit). Alors que dans le second cas, la mise à jour est appliquée à une seule copie par la transaction originelle. Elle est propagée de manière asynchrone vers les autres copies. Dans [74], les auteurs proposent d’améliorer la disponibilité des bases de données en adaptant la stratégie impatiente. Ce choix est justifié par la possibilité de détection de conflits avant la fin de la transaction ce qui augmente le niveau de cohérence entre les nœuds. Leur proposition d’adaptation vise à réduire les messages (qui correspondent à des mises à jour) entre les nœuds. Pour cela ils proposent de transférer ces messages au sein d’une même transaction et ceci une fois les opérations de lecture en cours sont terminées.29 Dans [75], les auteurs proposent d’améliorer la disponibilité de données en adaptant la stratégie paresseuse. Ce choix est justifié par la rapidité de traitement des transactions. Normalement dans un processus de réplication, les opérations doivent être exécutées toutes dans le même ordre. Dans leur contribution, les auteurs décrivent un type d’opérations pouvant ne pas respecter l’ordre d’exécution donnant lieu à des meilleurs performance ceci sans altérer la cohérence des nœuds. Ils proposent trois types d’opérations (avec des exemples des opérations sur un système de messagerie, où les données sont répliquées) : • Opérations causales : l’exécution de l’une affecte l’exécution de l’autre. Par exemple : l’envoie et la lecture de messages. o Opérations forcées : elles sont ordonnées entre elles mais pas forcement par rapport aux autres opérations. Par exemple : l’ajout et la suppression d’un contact. o Opérations immédiates : elles sont exécutées en ordre par rapport à toutes les autres opérations. Par exemple : la suppression multiple. • Opérations non causales : elles n’ont aucune dépendance. Par exemple : la lecture d’un message m1 et celle d’un autre m2. Dans [61], les auteurs étudient les approches de la propagation des messages entre les nœuds afin d’assurer la disponibilité de données : • Dans l’approche de la réplication passive primaire-sauvegarde (Primary-Backup), un nœud est désigné comme étant primaire. Il reçoit la requête (d’interrogation ou de mise à jour) d’un client, l’exécute et propage le résultat aux autres nœuds (backup). Ces derniers interviennent en cas de défaillance au niveau de la copie primaire. L’avantage de cette approche est d’assurer que toutes les copies sont dans le même état. • Dans l’approche réplication active ou en chaine (Chain Replication), le client soumet sa requête à un des nœuds, cette requête est propagée en chaine d’un nœud à un autre. Chaque nœud exécute la requête et le dernier nœud transmet le résultat au client. L’avantage de cette approche est que n’importe quel nœud peut être interrogé. 2.3.4 Disponibilité)de)données)par)le)cache L’utilisation de caches de données sur le réseau Internet a suscité l’attention de différents travaux de recherche dans différents domaines : données du web [76][63][77], les systèmes de gestion de bases de données [78][79][80], les entrepôts de données [81][82][83] ainsi que les moteurs de recherche [84][85][86]. Dans [63], les auteurs ont dressé les avantages de l’utilisation du cache. Parmi ces avantages, nous trouvons l’amélioration de la disponibilité de données en cas d’une défaillance au niveau du fournisseur ou du réseau. Dans [58], les auteurs proposent une solution pour améliorer la disponibilité de données scientifiques utilisées par des chercheurs pour procéder à des calculs. Ils proposent d’utiliser les espaces disque disponibles sur leurs ordinateurs de bureau (au sein d’un réseau local LAN) pour cacher les données récupérées depuis des sources externes. Chaque ordinateur est considéré comme un nœud. Un de ces nœuds maintient des informations sur l’état des autres nœuds, la distribution des données cachées sur les nœuds et les informations sur la récupération des données (URI, protocoles de récupération etc. Le cache de données pour les services web a été étudié dans différents travaux. Dans [87], les auteurs proposent une architecture de progiciels pour cacher les réponses XML des web services. Dans [88], les auteurs estiment que la description WSDL des services web manque d’informations pour mettre en place un mécanisme de cache. Ils proposent une version étendue de WSDL pour définir les données qui doivent être cachées. Dans [89], les auteurs constatent que les 30 réponses XML des services web nécessitent une analyse (avec l’interface DOM par exemple) avant d’être exploitées. Ainsi, ils proposent de cacher le résultat de l’analyse (arbre DOM). D’autres travaux se sont intéressés au cache des résultats de services web dans les environnements mobiles où le cache permet de maintenir l’accès aux données même en cas de perte de connexion avec les fournisseurs des données. Dans [90], les auteurs présente une implantation d’un cache sur un dispositif mobile afin d’assurer la disponibilité de données en cas de déconnexion. Ils présentent ensuite des défis à traiter dans ce domaine : • Développer la sémantique des opérations offertes par le web service. Ces opérations sont hétérogènes. Il faut au moins (1) pouvoir identifier si une opération exécute une mise à jour, (2) savoir si des données obsolètes d’une opération restent acceptables pour l’utilisateur. • Maintenir la cohérence du cache. pendant la déconnexion du dispositif mobile, la cohérence ne peut pas être garantie fortement. En plus il faut prendre en compte des opérations des mises à jours qui affectent la cohérence de données dans le cache. Par exemple, supposons que le cache contient une liste de contacts. La demande de suppression d’un contact affecte la cohérence de la liste stockée dans le cache. Ainsi il faudrait mener des études qui permettent au cache de pouvoir invalider des données suite à l’exécution d’autres requêtes. • Étudier l’expérience de l’utilisateur, pour évaluer l’impact de la solution proposée. • En cas de déconnexion, comment le cache doit réagir lorsqu’il reçoit une nouvelle requête. Les auteurs proposent comment idée, d’étudier la possibilité d’une réponse par défaut adaptée à chaque requête. • Étudier et proposer des mécanismes de préchargement de données afin d’améliorer la disponibilité des données. Dans [91], les auteurs proposent un cache distribué pour améliorer la disponibilité des données dans les environnements mobiles. Les données sont cachées sur des terminaux mobiles. Chacun de ces terminaux met son cache à disposition des autres terminaux. L’architecture (cf. Figure 1016) du cache est basée sur l’attribution de rôles aux terminaux mobiles : Figure'10 :'Architecture'du'cache'distribué'proposé'dans'[91] • Nœuds de cache (Caching Nodes CNs) : ils stockent les résultats des requêtes. 16 Figure obtenue de [91]31 • Répertoires de requêtes (Request Directories RDs) : pour une requête donnée, ils indiquent les nœuds de cache qui contiennent sont résultat. • Les nœuds interrogateurs (Requesting Nodes RNs) : ce sont les terminaux qui émettent les requêtes et qui pourraient devenir ensuite des nœuds de cache s’ils sont amenés à stocker le résultat de la requête (au cas où aucun des autres nœuds de cache ne contient le résultat). • Proxys des caches (Proxy Caches PCs) : ils font office d’intermédiaires entre les nœud interrogateurs qui soumettent les requêtes et les autres terminaux et les fournisseurs de données. Cette proposition impose une bonne disponibilité matérielle des proxys des caches qui constituent un point central pour assurer la communication entre les terminaux et même avec les fournisseurs de données. En plus, ses bénéfices dépendent de la connectivité des terminaux mobiles. Les auteurs n’aborde pas dans leur proposition les problèmes liées aux remplacement et le rafraichissement des données du cache. Dans [92], les auteurs proposent un cache de navigateur associé à iMashup [93] : un outil de création de mashups exécutés côté client. Le cache sert à stocker, sur la machine de l’utilisateur, les données récupérées depuis les fournisseurs de données externes. Une entrée du cache a une durée de vie adaptative !. Celle ci est inversement proportionnelle à la fréquence d’accès à cette donnée, et proportionnelle au nombre de succès de cache lors de la demande d’accès. Elle est définie avec les formules suivantes : !"#$ = ! !×!!"_!"#$% ! !" si !"#$ > ! alors ! = !"#$ sinon ! = ! ℎ!"_!"#$% correspond au nombre des succès de cache avec un poids ! (dans l’implantation ! = 1000). ! !" est une fonction croissante par rapport à la fréquence d’accès !". Cette formule indique que pour une entrée du cache, (1) plus le nombre de succès de cache est élevé plus il faut augmenter la durée de vie, et (2) et plus la fréquence d’accès à une donnée est élevée, plus il faut diminuer la durée de vie. Dans [39], les auteurs présentent MACE un système de cache pour les données des mashups. Ils proposent un modèle de mashups (cf. sous-section 2.1.8), où chaque mashup est vu comme un arbre dont les nœuds sont des opérateurs (similaire à un « pipe » dans Yahoo! Pipes). Un arbre peut être commun à plusieurs mashups ou utilisé comme un sous-arbre dans un arbre d’un autre mashup. Les auteurs y intègrent un cache qui sélectionne dynamiquement le nœud dont les données produites doivent être cachées. Chaque nœud ! possède (1) une valeur de coût associée !"! qui correspond à la latence de son exécution et une valeur de coût cumulatif !!"! qui représente la somme définie par la formule suivante : !!"! = !"! + !"! ! !"# !" !"#$% !"#$ !" ! Le choix du nœud à cacher prend en compte la fréquence d’exécution du nœud et la fréquence des mises à jour : il est plus intéressant de cacher les données du nœud qui est le plus fréquemment exécuté et qui demande le moins de mises à jour. La différence de fréquence d’exécution entre les nœuds d’un même arbre vient du fait qu’un nœud (et ses nœuds fils) peut faire partie d’un autre arbre. Ainsi le nœud ! choisi est celui qui maximise la valeur de l’expression !"#! = !"!×!!"! − !"!×!!"! où !"! et !"! dénotent respectivement la fréquence d’exécution et la fréquence de mise à jour du nœud !. Si le cache ne peut pas contenir, dans son espace libre, les données produites par le nœud, alors les données d’un autre nœud (le suivant qui maximise 32 l’expression du !"# ) sont choisies pour être cachées. Les auteurs n’aborde pas dans leur proposition les problèmes liées aux remplacement et le rafraichissement des données du cache. 2.4 Conclusion Nous avons dressé un état de l’art des travaux sur les modèles des mashups, les systèmes d’exécution de mashups et leurs architectures ainsi que la disponibilité de données fraiches sur le web. L’étude des modèles et de certains outils de création de mashups nous a permis d’identifier les concepts nécessaires pour décrire un mashup. Nous avons remarqué que dans ces travaux, la définition du mashup n’est pas la même : certains ont défini le mashup comme étant un ensemble de mashlets alors que d’autres ont restreint la définition d’un mashup à un mashlet. D’un autre côté les outils de création de mashups qui permettent l’échange de données entre les mashlets, définissent les wirings comme des simples intermédiaires qui permettent le transfert de données. Nous trouvons que cette conception de wiring est pauvre. Ceux ci peuvent être enrichis pour permettre d’effectuer un mapping de données lors du transfert entre le mashlet envoyeur et le mashlet receveur : ceci rend le mashlet receveur indépendant du format de données envoyées par le mashlet envoyeur. En plus, nous trouvons que ces modèles n’intègrent pas la spécification des caractéristiques de la disponibilité de données dans les mashups. Lors de analyse des approches existantes pour améliorer la disponibilité de données sur le web, nous avons identifiée des solutions à base de réplication et à base de cache. Ces solutions sont difficilement applicables dans le contexte de mashups. En effet, la réplication doit être mise en place au niveau des fournisseurs de données qui sont autonomes ou bien au niveau du client de ces fournisseurs : le système d’exécution des mashups. Or, dans ce cas, il faut répliquer des données hétérogènes avec des systèmes d’interrogations spécifiques à ces données. Dans le contexte des mashups, les fournisseurs de données ne sont pas connus à l’avance (avant la création des mashups), ainsi pour chaque nouveau fournisseur identifié, il faut lui demander l’accès à ses données internes et à son systèmes d’interrogation pour les répliquer, ce que nous considérons comme non garanti. D’autre part, les solutions à base de cache sont adaptées à des applications construites par des développeurs : le choix des politiques de cache sont faites par des développeurs : ils décident quelles données et à quelles étapes de la composition des services il faut cacher. Or de telles décisions ne doivent pas être laissées aux constructeurs des mashups qui ont souvent des compétences limitées en programmation et ne maitrisent pas les aspects non fonctionnels de l’environnement de construction des mashups. Bien que la plateforme MACE propose de cacher les données des mashups, cependant le fonctionnement du cache est défini avec l’objectif de diminuer la latence de l’exécution des mashups et non pour assurer la disponibilité des données des mashups. D’autre part nous trouvons que dans la solution de cache de [92] l’estimation d’une durée de vie adaptative ne prend pas prendre en compte des facteurs comme l’ancienne valeur de la durée de vie, la date du dernier accès à la donnée et la comparaison d’une donnée récupérée à celle existante en cache. Dans toutes ces solutions il manque la prise en compte de la fraicheur de données. Dans le Chapitre 3, nous proposons un modèle de mashup basé sur les modèles de valeurs complexes [19]. Ce modèle nous permettra de spécifier les caractéristiques de la disponibilité de données dans le Chapitre 4. 33 Chapitre!3 MODELE%DE%MASHUPS Ce chapitre présente les concepts de notre modèle de mashups : Donnée, Activité, Mashlet, Wiring, et Mashup. Une activité peut être basique ou composite. Une activité basique décrit une tâche spécifique permettant d’accomplir un traitement de données (le filtrage, la projection, l’extraction, l’élimination de doublons, le tri, l’union). Ces activités sont coordonnées par des activités composites (Sequence, Foreach, Parallel). Les mashlets affichent des données produites par des activités. Tandis que les wirings définissent le flot de données entre les mashlets. Ils peuvent aussi, décrire le traitement des données nécessaire pour les délivrer sous le bon format aux mashlets destinataires. L’ensemble de ces concepts décrit des composants qui constituent des mashups. Dans le mashup ItineraryPlanner, présenté dans le Chapitre 1 (cf. Figure 1), ces concepts se présentent comme suit : • Les données sont : o récupérées depuis des services (fournisseurs de données : Google Maps, Yahoo! Weather et Google Places). Ces services sont autonomes et indépendants des mashups. o ou saisies par l’utilisateur (viles de départ de et de destination)… o ou traitées et échangés entre les mashlets (villes de passages sur l’itinéraire). • Les activités qui décrivent le traitement de ces données (extraction de données, filtrage…). • Les mashlets (Map, Weather, Restaurants) constituent les composants qui affichent les résultats produits par des activités sous-jacentes. Ces composants sont réutilisables. C’est à dire un mashlet peut être utilisé dans la définition de différents mashups. • Le transfert des données entre les mashlets se fait via des wirings (la liste de villes de passage de Map vers Weather, les coordonnées de la ville d’arrivée de Map vers Restaurants). Les wirings procèdent à la manipulation des données transférées afin de les livrer dans le bon format. • Le mashup ItineraryPlanner est constitué des mashlets Map, Weather, Restaurants et des wirings qui définissent le flot de données entre ces mashlets. La Figure 11 présente les concepts Mashup, Mashlet, Wiring et Activités sous la forme d’une pile. Chaque mashlet et wiring est associé à une activité (basique ou composite). Un mashlet est réutilisable : il peut faire partie de plusieurs mashups. Un wiring appartient au mashup qui contient les mashlets sous-jacents. 34 Figure'11 :'Pile'de'concepts'de'mashups Le chapitre est organisé comme suit. La section 3.1 présente la caractérisation des données des mashups. Les concepts Activités, Mashlet, Wiring, Mashup sont décrit respectivement dans les sections 3.2 à 3.5. Ces concepts sont illustrés avec des exemples décrivant le mashup ItineraryPlanner présenté dans le Chapitre 1. Enfin la section 3.6 conclut ce chapitre. 3.1 Données)de)mashups Nous avons besoin d’une représentation de données qui permet l’homogénéisation de données de mashups. Pour cela, nous adoptons une caractérisation de données basée sur les valeurs complexes. 3.1.1 Types)de)données Un domaine est un ensemble fini de valeurs. Nous considérons les domaines prédéfinies des chaines de caractères !, des booléens !, des entiers ℤ, des entiers naturels ℕ,! et! des! réels!ℝ.! Nous définissons le domaine des noms de types ! = !! , !! , … ⊆ ! et celui des noms des instances ! = !! ,!! , … ⊆ ! avec ! ∩ ! = ∅. Un type de valeurs complexes ! dénoté !, est défini par une paire ! ∶ !"#, où A est le nom du type (A ∈ !) et !"# est sa définition. Nous considérons les fonctions !"#$ et !"# pour accéder respectivement aux composants de la paire. Par exemple pour le type !"#$"%&!'%" ∶ ℤ , Mashups Mashlets / Wirings Activités m1# m3# m2# Mashup Mashlet Activité w1# m1 m2# m3# m2# Wiring consomme w1# Données Donnée est associé à 35 !"#$ !"#$"%&!'%" ∶ ℤ retourne !"#$"%&!'%" et !"# !"#$"%&!'%" ∶ ℤ retourne ℤ. Le nom est unique et il est utilisé pour référencer le type. L’ensemble ! de types de données est défini par les règles suivantes : • Si ! est un domaine alors ! ∶ ! est un type atomique. • Si ! est un type alors ! ∶ ! est un type liste. • Si !! ,!! , … ,!! sont des types tels que ∀ !,! !"#$ (!! ) ≠ !"#$ (!! )alors ! ∶ !! ,!! , … ,!! est un type tuple. Chaque !! est un type caractérisant un attribut de nom !"#$ (!! ). • Si !! ,!! , … ,!!,!!, … !! sont des types tels que ∀ !,! !"#$ (!! ) ≠ !"#$ (!! ), alors ! ∶ !!× !!× …× !! → !!× …×!! est un type fonction17. Pour ! ∈ 1. . ! , !! est un type paramètre d’entrée de nom !a!" !! . Pour ! ∈ !. . ! , !! est un type paramètre paramètre de sortie de nom !"#$ !! . Dans la suite de ce document, lorsque nous introduisons un type, dans un souci de simplification, nous pourrons omettre le nom du type. Cette simplification s’applique également aux paramètres des types fonction. Notons que l’ensemble de types ! est lui même un domaine. 3.1.2 Instances)des)types ! dénote l’ensemble des instances de type !. Cet ensemble est défini par induction de la manière suivante : • ! ∶ ! = ! ∶ ! ! ∈ ! . Les valeurs du domaine ! sont connues. • ! ∶ ! = ! ∶ !! , … , !! | ! ∈ ℕ !" ∀ 1 ≤ ! ≤ !, !! ∈ ! . • Pour un type tuple ! ∶ !! ,!! , … ,!! où !!est de la forme !! : d!"! , ! ∶ !! ,!! , … ,!! = ! ∶ !! : !! , !! : !! , … , !!: !! | ∀ ! ∈ 1. . ! , !! ∶ !! ∈ !! . • ! ∶ !!× !!× …×!! → !!× …×!! = !| ! !"# !"# !"#$%&"n !"#$ !" !"#$%&'() !"# !!× !!× …×!! → !!× …×!! . Nous définissons le domaine !"#" incluant toutes les instances possibles et le domaine !"#$%&'#( incluant toutes les instances possibles de type fonction. !"#" = ! !∈! !"#$%&'#( = ! ! !"# !" !"#$ !"#$%&"# !"#$%&'#( ⊂ !"#" Nommage des instances Chaque instance ! ∶ ! d’un type ! ∈ ! peut être nommée comme suit : ! = ! ∶ !. Où ! ∈ ! est le nom de l’instance. Exemples : La suite présente des exemples de types et instances utilisés dans le mashup ItineraryPlanner décrit dans le Chapitre 1 (cf. Figure 1). 17 Dans notre modèle, une fonction possède plusieurs paramètres de sortie ; ce type de fonctions a été introduit par Maurice Fréchet dans ses travaux sur l’analyse fonctionnelle.36 Le service Yahoo! Weather retourne la météo d’une localisation décrite sous format WOEID18 . Par exemple l’instance !"#$% ∶ 12724717 correspond à la localisation de la ville de Grenoble. Elle est de type !"#$% ∶ ℕ. Le type !"#$%& ∶ !"#$% ∶ ℕ décrit une liste de localisations de villes décrites sous format WOEID. Par exemple l’instance !"#$%& ∶ !"#$% ∶ 12724717, !"#$%: 12724728, !"#$% ∶ 12726958, woeid ∶ 20068148, !"#$% ∶ 20068141 correspond à la liste de localisations des villes de passage entre Grenoble et Paris dans ItineraryPlanner et décrites sous format WOEID. !"#$%&!%'$ ∶ !"#$ ∶ !, !"#$%&'%() ∶ !, !"!"#$$ ∶ !, !"#$%& ∶ ℝ décrit le type tuple !"#$%&!%'$ avec les attributs : le nom du restaurant, sa spécialité, son adresse et sa note. L’expression !"#$ = !"#$%&!%'$ ∶ 〈!"#$:"!"#1", !"#$%&'%():"!"#$ç!!"#", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5〉 définit une instance de ce type nommée !"#$. L’itinéraire entre deux villes est décrit dans un type tuple, nommé routes19, donnée ci dessous. On y retrouve par exemple les attributs suivants : • Un tuple nommé legs (manches). Il contient des attributs indiquant la distance, la durée totale, les adresses départ et d’arrivée de l’itinéraire et les étapes (steps) de l’itinéraire sous la forme d’une liste. • Chaque étape contient des informations sur sa distance (distance), durée (duration), points de départ et d’arrivée (start_location et end_location) des instructions (html_instructions). Chacune est décrite sous la forme d’une chaine de caractère. routes : 〈 bounds : 〈 northeast : 〈 lat : ℝ, lng : ℝ 〉, southwest : 〈 lat : ℝ, lng : ℝ 〉 〉, copyrights : !, legs :!〈! distance : 〈 text : !, value : ℝ 〉, duration : 〈 text : !, value : ℝ 〉, end_address : !, end_location : 〈 lat : ℝ, lng : ℝ 〉, start_address : !, 18 Un identifiant WOEID (Where on Earth IDentifier) est un identifiant de référence assigné par Yahoo! Pour identifier des points géographiques sur la terre. 19 La définition du type routes est basée sur la structure du document JSON renvoyé par le service Google Maps37 start_location : 〈 lat : ℝ, lng : ℝ 〉, steps : [ step : 〈 distance : 〈 text : !, value : ℝ 〉, duration : 〈 text : !, value : ℝ 〉, end_location : 〈 lat : ℝ, lng : ℝ 〉, html_instructions : !, polyline : 〈 points : ! 〉, start_location : 〈 lat : ℝ, lng : ℝ 〉, travel_mode : ! 〉 ] 〉 〉 L’exemple suivant présente une partie d’une instance20 de ce type donnant l’itinéraire entre Grenoble et Paris, nommé !"#$%&'. !"#$%&' = routes : 〈 bounds : 〈 northeast : 〈 lat : 48.857240, lng : 5.724690000000001 〉, southwest : 〈 lat : 45.18839000000001, lng : 2.306130 〉 〉, copyrights : "Données cartographiques ©2012 GeoBasis-DE/BKG (©2009), Google", legs :!〈! distance : 〈 text : "574 km", value : 573623 〉, duration : 〈 text : "5 heures 21 minutes", value : 19284 〉, end_address : "Paris, France", 20 Le tuple !"!"#$% est similaire à l’objet JSON obtenu par invocation du service Google Maps : http://maps.googleapis.com/maps/api/directions/json?origin=Grenoble&destination=Paris&senso r=false&38 end_location : 〈 lat : 48.857240, lng : 2.35260 〉, start_address : "Grenoble, France", start_location : 〈 lat : 45.18839000000001, lng : 5.724690000000001 〉, steps : [ step : 〈 distance : 〈 text : "92 m", value : 92 〉, duration : 〈 text : "1 minute", value : 7 〉, end_location : 〈 lat : 45.188890, lng : 5.725610000000001 〉, html_instructions : "Prendre la direction \u003cb\u003enordest\u003c/b\u003e sur \u003cb\u003ePl. Victor Hugo\u003c/b\u003e vers \u003cb\u003eRue Paul Bert\u003c/b\u003e", polyline : 〈 points : "mzxrGib}a@g@gA{@oB" 〉, start_location : 〈 lat : 45.18839000000001, lng : 5.724690000000001 〉, travel_mode : "DRIVING" 〉, step : 〈…〉, …… ], 〉, …… 〉 3.1.3 Types)et)valeurs)d’instances Pour accéder aux types et aux valeurs des instances de la forme ! ∶ !"#$%, nous définissons les fonctions !"#$ et !"# de la manière suivante : • !"#$ ! ∶ !"#$% = !. Nous rappelons qu’un type ! ∶ !"# est référencé par son nom et qu’il est possible d’inférer le type ! ∶ !"# à partir de !. • !"# ! ∶ !"#$% = !"#$%. Par exemple, si ! dénote !"#$%& ∶ !"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12724752, !"#$% ∶ 12726960, !"#$% ∶ 582081 , nous avons : • !"#$ ! = !"#$%& • !"# ! = !"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12724752, !"#$% ∶ 12726960, !"!"# ∶ 582081 3.1.4 Opérations)sur)les)instances Chaque type possède un ensemble d’opérations qui définit le comportement de ses instances. Toute opération est d’un type fonction ∈ !"#$%&'#( , en considérant qu’elle a pour paramètres de types !! ,!! , … ,!! et pour signature !× !!× !!× …×!! → !!. Pour une instance ! de ! et 39 des instances !! ∈ !! , nous adoptons une notation pointée : !. !" !! , … , !! pour designer l’appel de l’opération !" sur l’instance ! avec les instances !! en paramètres d’entrée. Parmi les opérations sur les types, nous retrouvons des opérations qui définissent les relations d’ordre entre les instances d’un type ! comme !"##, !"#$%#", !"##$%&'()!, !"##$%&'()!, !"#$%#"!"#$%&' et !"#$%. Les types de ces opérations sont de la forme !×! → !. Ces opérations comparent les instances selon une des stratégies définies dans [94][95] : • Identité d’instance : comparer les identificateurs des instances. • Comparaison superficielle : comparer les valeurs des instances. • Isomorphisme (comparaison structurelle) : égalité si les structures sont isomorphes. • Comparaison profonde : comparer les valeurs des feuilles des instances. Nous définissons également l’opération !"#$%ℎ qui, pour une instance ! de type liste, retourne sa taille. Le type de !"#$%ℎ est de la forme ! → ℕ . L’appel de l’opération se fait avec la notation !. !"#$%ℎ (). Nous considérons aussi l’opération !"#$%& définie sur tous les types fonction pour réaliser l’exécution de leurs instances. Pour une fonction !, l’opération !"#$%& l’exécute avec des valeurs des paramètres données dans une liste d’instances. Elle retourne la valeur du paramètre de sortie correspondante de la fonction !. Elle est de type !"#$%&'#(× !"#$% ∶ !"#" → !"#" . Fonction !"#$%&'()* Nous définissons la fonction !"#$%&'()* qui pour chaque type retourne la liste des opérations qui définissent le comportement de ses instances. Elle est de type ! → !"#$%&'#( . 3.2 Activité Une activité consomme et produit des données. Elle peut être basique ou composite. Une activité basique décrit une tâche spécifique permettant d’accomplir un traitement de données. Une activité composite permet de coordonner les activités qu’elles soient basiques ou composites. La représentation graphique d’une activité est donnée dans la Figure 12. Figure'12 :'Représentation'graphique'd'une'activité Une activité est de type fonction. Nous considérons le domaine des activités ! ⊂ !"#$%&'#(. Notons que, dans notre modèle, certaines fonctions ne sont pas forcement des activités. Comme les fonctions définissant le comportement des instances d’un type : elle sont définies en tant qu’opérations (sous-section 3.1.4). 3.2.1 Activités)basiques Nous considérons un ensemble fini d’activités basiques comme l’extraction (Extract), le filtrage (Filter), l’élimination de doublons (Unique), le tri (Sort), l’union (Union) et l’annexe (Append). Ces activités sont présentées dans les sous-sections 3.2.1.1 à 3.2.1.6. 40 Les fournisseurs de données exportent des méthodes représentées par des activités. Des exemples de ces activités sont donnés au cours du chapitre lors du déroulement du scénario ItineraryPlanner. 3.2.1.1 Extract Une activité Extract retourne une valeur composante d’une instance ! d’un certain type !. Le résultat est construit à partir d’un chemin d’accès !"#ℎ. • Notation : !!"#! ! L’expression du chemin d’accès !"#ℎ est construite avec la règle suivante : !"#ℎ ∶= ! !. !"#ℎ ! ! ! ! . !"#ℎ Où ! y désigne le nom d’un type tandis que ! est un entier naturel. Validité du chemin par rapport à un type Pour un type ! donné, nous définissons !"#ℎ! ! comme étant l’ensemble des expressions de chemins d’accès !"!ℎ valides par rapport à !. Cet ensemble est définit comme suit : 1. Si !"#$ ! = ! alors !"#ℎ = ! ∈ !"#ℎ! ! . 2. Si ! est de la forme ! ∶ … , ! ! : !"#! , … et !"#ℎ′ ∈ !"#ℎ! ! ! : !"#! . alors !"#ℎ = !. !"#ℎ′ ∈ !"#ℎ! ! . 3. Si ! est de la forme ! ∶ ! ∶ !"# alors !"#ℎ = ! ! ∈ !"#ℎ! ! . 4. Si ! est de la forme ! ∶ ! ∶ !"# et !"#ℎ′ ∈ !"#ℎ! ! ∶ !"# , alors !"#ℎ = ! ! . !"#ℎ′ ∈ !"#ℎ! ! . • Type de l’activité : ! ∶ ! → !′ • Sémantique de l’activité : !!"#! ! est défini comme suit La valeur de !!"#! ! est donnée par les règles suivantes : 1. Si !"#$ ! = ! et !"#ℎ = ! alors !!"#! ! = !. 2. Si ! = ! ∶ … , ! ! : ! ! , … et !"#ℎ = !. !′ alors !!"#! ! = ! ! ∶ ! ! . Cette valeur est désignée avec la notation !. ! ! . 3. Si ! = ! ∶ … , ! ! : ! ! , … et !"#ℎ = !. ! ! . !"#ℎ′ alors !!"#! ! = !! ! .!"#! ! ! ! ∶ ! ! . Cette valeur est désignée avec la notation !. ! ! . !"#ℎ ! . 4. Si ! = ! ∶ ! ∶ !! , … , ! ∶ !! , … , ! ∶ !! et !"#ℎ = ! ! alors !!"#! ! = ! ∶ !! . Cette valeur est désignée avec la notation ! ! . 5. Si ! = ! ∶ ! ∶ !! , … , ! ∶ !! , … , ! ∶ !! et !"#ℎ = ! ! . !"#ℎ′ alors !!"#! ! = !!"#! ! ! ∶ !! . Cette valeur est désignée avec la notation ! ! . !"#ℎ ! . Exemple !!"#$%&.!"#$.!!"#$ ! .!"#$.!"#$"_!"#$%&"' !"#$%&' = !"#$"_!"#$%&"' ∶ !"# ∶ 45,18839000000001, !"# ∶ 5.724690000000001 . Cette valeur est désignée avec la notation !"#$%&'. !"#$. !"#$! 0 . !"#$. !"#$"_!"#$%&"!. Et !"#$%&' est l’instance du type !"#$%, tous les deux définis dans la sous-section 3.1.2. 41 3.2.1.2 Filter Une activité Filter prend en entrée une liste ! d’instances de ! de la forme ! ∶ ! ∶ !! , … , ! ∶ !! . Elle sélectionne les éléments de ! vérifiant une condition !"#$. Elle produit comme résultat une sous-liste de !. • Notation : !!"#$ ! • Type de l’activité : ! ∶ ! → ! L’expression de !"#$ est définie comme suit : Nous commençons par définir les termes avec les règles suivantes : ! Les valeurs constantes ! des instances ! ∶ ! sont des termes constants. Par extension, les termes constants dénotent aussi leurs valeurs. ! Si ! est un chemin d’accès alors ! est un terme (chemin). ! Si ! est une fonction d’arité n et que !1 … !" sont des termes alors ! (!1 … !") est un terme (fonction). Nous définissons des conditions basiques (basic conditions bcond) sur les termes (!1 et !2) avec les règles suivantes : !"#$% ∶= !1 ! !2 ! ∶= = ≠ < > ≤ ≥ ∈ ⊂ ⊆ Les opérateurs ensemblistes et de comparaisons doivent être compatibles avec les valeurs des termes. En plus, pour faciliter le calcul de la valeur booléenne d’une condition, nous définissons l’interprétation d’un terme !, par rapport à une instance !, dénoté ! !comme suit : ! Pour les termes constants !, ! ! = ! ! Pour les termes chemins !, ! ! = !!, !!, … , !! !" !!"#! ! !"# !"# !"#$% !" !" !"#$% ! ∶ ! ∶ !!, ! ∶ !! … , ! ∶ !! !"# !! ! !"#$# Dans le deuxième cas, le chemin d’accès aboutit à une valeur atomique dont la valeur est utilisée comme opérande de la condition. ! L’interprétation d’un terme fonction ! (!! … !!) par rapport à une instance ! est la valeur de l’instance résultat de l’application de la fonction ! sur les interprétations des termes !! … !! par rapport à ! : !(!! … !!) ! = !"# ! !! ! , … , !! ! . Une condition basique de la forme !1!"2 est considérée comme étant interprétable par rapport à un type ! si !1 et !2 sont interprétables par rapport à !. Une instance ! de ! satisfait cette condition basique, si !! !!!! !est vrai. Dans ce cas, nous notons ! ⊨ !!!!! . L’expression !"#$ est définie avec la grammaire ci dessous. !"#$ ∶= !"#$% ¬ !"#$ !"#$ ∧ !"#$ !"#$ ∨ !"#$ !"#$ !"#$% !!"ℎ !"#$% ∶= ∀ ∃42 Où !"#ℎ est un chemin d’accès qui identifie une liste et dont la grammaire est définie dans la sous-section 3.2.1.1. • Sémantique de l’activité !!"#$ ! = ! ∶ ! ∶ !! , … , ! ∶ !! ∀! ∈ !, ! , ! ∶ !! est présente dans ! et ! ∶ !! ⊨ !"#$ Satisfiabilité des expressions de filtrage La satisfiabilité des conditions de filtrage par rapport à une instance ! est définie avec les règles suivantes : 1. ! ⊨ ¬!"#$ si ! ⊨ !"#$ est faux. 2. ! ⊨ !"#$! ∧ !"#$! si ! ⊨ !"#$! et ! ⊨ !"#$! 3. ! ⊨ !"#$! ∨ !"#$! si ! ⊨ !"#$! ou ! ⊨ !"#$! 4. ! ⊨ !"#$ ∀ !"#ℎ!"# si pour chaque !! ∈ !"# !!"#!!"# ! , !! ⊨ !"#$ et !!"#!!"# ! est une liste 5. ! ⊨ !"#$ ∃ !"#ℎ!"# si pour un certain !! ∈ !"# !!"#!!"# ! , !! ⊨ !"#$ et !!"#!!"# ! est une liste Exemple Soit l’instance liste suivante : ! = !"#$%&!%'$# ∶ ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"2", !"#$%& ∶ 4 , !"#$%&!%'$ ∶ !!"# ∶ "!"#3", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4.1 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#4", !"#$%&'%() ∶ "!"#$%"&'(", !""#$%% ∶ "!"4", !"#$%& ∶ 3.6 L’expression !"#$%&!"# = !!"#$%&!%'$.!"#$%&!! ! produit : ! = !"#$%&!%'$# ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5 !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"2", !"#$%& ∶ 4 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#3", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4.1 Lors de l’évaluation de !"#$%&'%(, la condition !"#$%&!%'$. !"#$%& ≥ 4 est évaluée sur tous les éléments de !. Nous traçons son évaluation sur le premier élément !! = !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !!!"#$$ ∶ "!"1", !"#$%& ∶ 4.5 : !! ⊨ !"#$%&!%'$. !"#$%& ≥ 4 si !"#$%&!%'$. !"#$%&!! ≥ 4 !!. Nous avons !"#$%&!%'$. !"#$%&!! = !"# !!"#$%&!%'$.!"#$%& !! = !"# !"#$%& ∶ 4.5 = 4.5 (deuxième cas). Nous avons également 4 !! = 4 (premier cas). Donc !"#$%&!%'$. !"#$%&!! ≥ 4 !! est vraie. Ainsi !! vérifie la condition de filtrage de !"#$%&'%(. 43 3.2.1.3 Unique Une activité Unique prend en entrée une instance !, de type liste, contenant des instances !! d’un certain type !. Pour un chemin d’accès !"#ℎ ∈ !"#ℎ! ! 21 , Elle retourne une liste avec les doublons éliminés. • Notation : ! !"#! ! • Type de l’activité : ! ∶ ! → ! • Sémantique de l’activité : ! !"#! ! = !! , … !! tel que : o ∀!, !! ∈ ! ∄!! ,! ≠ ! !!"#! !! . !"#$% !!"#! !! si une opération d’égalité !"#$% est définie sur le type sous-jacent. o Sinon ! !"#! ! = ! Exemple Soit la liste d’instances ci dessous. Elle indique les villes intermédiaires entre Grenoble et Paris sous format WOEID22 . ! = !"#$%& ∶ !"#$% ∶ 12724717, !"#$% ∶ 12724717, !"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12724728, !"#$% ∶ 12726958, !"#$% ∶ 12726958, !"#$% ∶ 20068148, !"#$% ∶ 20068141, !"#$% ∶ 20068141 L’expression !"#$!%&'()* ! = ! !"#$% ! retourne l’instance suivante : !"#$%& ∶ [!"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12726958, !"#$% ∶ 20068148, !"#$% ∶ 20068141] 3.2.1.4 Sort Nous considérons le domaine !"#$" = "!"#$%&'%(","!"#$"%!&%'" . Une activité Sort prend en entrée une instance !, de type liste, contenant des instances !! d’un certain type ! et une instance ! de type atomique défini sur le domaine !"#$". Pour un chemin d’accès !"#ℎ ∈ !"#ℎ! ! 23 , Elle retourne une liste avec les valeurs !! ordonnées d’une manière croissante ou décroissante selon la valeur de !. • Notation : !!"#! !, ! • Type de l’activité : ! ∶ ! ×!"#$" → ! • Sémantique de l’activité : !!"#! !, ! = !! , … , !! tel que ∀!, !! ∈ ! et : o ∀! ≤ ! < !. !"#$%ℎ() ∈ ℕ, nous avons !! . !"##$%&'()! !! si ! = "!"#$%&'%(" et une opération !"##$%&'()! est définie sur le type sous-jacent. o ∀! ≤ ! < !. !"#$%ℎ() ∈ ℕ, nous avons !! . !"##$%&'()! !! si ! = "!"#$"%!&%'" et une opération !"##$%&'()! est définie sur le type sous-jacent. o Sinon !!"#! !, ! = !. 21 !"#ℎ est un chemin d’accès dont la grammaire est définie dans la sous-section 3.2.1.1. 22 La présence de doublons est due au fait de la présence de plusieurs étapes de l’itinéraire dans la même ville. 23 !"#ℎ est un chemin d’accès dont la grammaire est définie dans la sous-section 3.2.1.1. 44 Exemple L’expression !"#$%&' = !!"#$%&!%'$.!"#$%& !,"!"#$%&'%(" 24 retourne la liste suivante : !"#$%&!%'$# ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5 , !"#$%&!%!" ∶ !"#$ ∶ "!"#3", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4.1 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"2", !"#$%& ∶ 4 3.2.1.5 Append Une activité Append prend en entrée deux instances ! et ! de type liste contenant des instances de même type !. Elle retourne une liste qui est le résultat de l’union des deux listes. • Notation : ! ∪ ! • Type de l’activité : ∪∶ ! × ! → ! • Sémantique de l’activité : ! ∶ !! … !! ∪ ! ∶ !! … !! = ! ∶ !! … !!, !! … !! 3.2.1.6 Concatenate Une activité Concatenate prend en entrée deux instances ! et ! de type tuple. Elle retourne un tuple ayant les attributs de ! et !. • Notation : !⨁! • Type de l’activité : ⨁ ∶ ! ∶ !! , … , !! ×! ∶ !! , … , !! → !_! ∶ !! , … , !!, !! , … , !! Il est nécessaire que !"#$ !! ≠ !"#$ !! pour chaque ! et !. • Sémantique de l’activité : Pour un tuple ! de la forme ! ∶ !! ∶ !! , … , !! ∶ !! et un tuple ! de la forme ! ∶ !! ∶ !! , … , !! ∶ !! , nous avons : !⨁! = !_! ∶ !! ∶ !! , … , !! ∶ !!, !! ∶ !! , … , !! ∶ !! . 3.2.2 Activités)composites Les activités que nous venons de présenter permettent de manipuler les instances de données dans les mashups. La coordination de ces activités définit l’ordre de leur exécution. Elle est définie avec des activités composites qui sont de type fonction. Nous considérons les activités composites suivantes25 : Sequence, Foreach et Parallel. 3.2.2.1 Sequence Une activité Sequence est définie à partir de deux ou plusieurs activités !"#! , !"#! , … !"#! ∈ ! considérées comme des sous-activités de l’activité Sequence. • Notation : ≫ !"#!,!"#!,…!"#! • Type de l’activité : ≫∶ !!× !!× …×!! → !′!× !′!× …×!′ ! • Sémantique de l’activité : o ≫ !"#!,!"#!,…!"#! !! , … , !! = !"#! … !"#! !"#! !! , … , !! o !"#! est de type !!× !!× …×!! → !!.!× …×!!.! o ∀ 2 ≤ ! ≤ !, !"#! est de type ! !!! .!× …×! !!! .! → !!.!× …×!!.! o !"#! est de type ! !!! .!× …×! !!! .! → !′!× !′!× …×!′ ! 24 ! est la liste obtenue par filtrage dans la sous-section 3.2.1.2. 25 Le modèle peut être enrichi avec d’autres activités composites dans le futur selon les besoins qui peuvent apparaître. 45 Représentation graphique La Figure 13 donne la représentation graphique d’une activité Sequence ayant deux sousactivités. Figure'13 :'Représentation'graphique'd'une'activité'Sequence Exemple : Soit le fournisseur de données Google Places qui offre une activité !"#$"%#&'(&)# de type !"#$%&' ∶ !"# ∶ ℕ, !"# ∶ ℕ → !"#$%&!%'$# ∶ !"#$%&!%'$ Nous définissons une activité Sequence !"#$%"#$&'(&)$# = ≫ !"#$"%#&'(&)#,!"#$%&'%(,!"#$%&' . Elle est de type ≫ ∶ !"#_!"#$%&"' ∶ !"# ∶ ℕ, !"# ∶ ℕ → !"#$%&!%'$# ∶ !!"#$%&$'# . L’activité !"#$"%#&'(&)# récupère la liste de restaurants présents près du point géographique défini par le paramètre d’entrée !"#$%&' . Ensuite l’activité !"#$%&'%( (définie dans la sous-section 3.2.1.2) sélectionne les restaurants dont la note est supérieure à 4. Enfin l’activité !"#$%&' (définie dans la sous-section 3.2.1.4) trie la liste des restaurants selon la valeur de la note par ordre croissant. La représentation graphique de cette activité est donnée dans la Figure 14. Figure'14 :'Représentation'graphique'd’un'exemple'd’une'activité'Sequence 3.2.2.2 Foreach Une activité Foreach prend en entrée une instance de type liste. Elle est définie à partir d’une activité !"# ∈ ! considérée comme une sous-activité de l’activité Foreach. • Notation : ∞ !"# • Type de l’activité : ∞ ∶ ! → !′ • Sémantique de l’activité : ∞ !"# ! = !"# ! 1 , !"# ! 2 , … , !"# ! ! tel que !"# est de type ! → !′ L’activité exécute itérativement sa sous-activité sur les éléments de la liste ! retourne dans une liste les résultats des exécutions. L’exécution s’arrête avec la dernière exécution de la sousactivité sur le dernier élément de la liste !. act1% act2% Sequence46 Représentation graphique La Figure 15 présente une représentation graphique d’une activité Foreach et de sa sousactivité. La discontinuité des flèches représente le découpage le l’entrée de Foreach en valeurs et leur transmission à la sous-activité. Figure'15 :'Représentation'graphique'd'une'activité'Foreach Exemple : Soit le fournisseur de données Yahoo! Weather qui offre une activité !"#$"%#ℎ!! de type !"#$% ∶ ℕ → ! , où ! est un type décrivant des données météorologiques d’une certain ville identifiée par son identifiant !"#$%. Nous définissons une activité Foreach !"#"$%&$'#ℎ!" = ∞ !"#$"%#!!" . Elle est de type ∞ ∶ !"#$%& ∶ !"#$% ∶ ℕ → !"#"$%& ∶ ! . Elle retourne les données météorologiques des villes passées en entrée. Elle est représentée graphiquement dans la Figure 16. Figure'16 :'Représentation'graphique'd’un'exemple'd’une'activité'Foreach 3.2.2.3 Parallel Une activité Parallel est définie à partir de deux ou plusieurs activités !"#! , !"#! , … !"#! ∈ ! considérées comme des sous-activités de l’activité Parallel. • Notation : ∥ !"#!,!"#!,…!"#! • Type de l’activité : ∥∶ !!× !!× …×!! → !!.!× … × !!.!×!!.!× …×!!.!× … ×!!.!× … ×!!.! • Sémantique de l’activité : !"#! est de type !!× …×!! → !!.!× …× !!.! où 1 ≤ ! ≤ ! ≤ ! !"#! est de type !!× …×!! → !!.!× …×!!.! où 1 ≤ ! ≤ ! ≤ ! … !"#! est de type !!× …×!! → !!.!× …×!!.! où 1 ≤ ! ≤ ! ≤ ! ∥ !"#!,!"#!,…!"#! !! , … , !! = !"#! !! , … , !! , !"#! !!, … , !! , … , !"#! !! , … , !! Représentation graphique La Figure 17 donne la représentation graphique d’une activité Parallel et de ses sousactivités. act$ Foreach getWeather Foreach47 Figure'17 :'Représentation'graphique'd'une'activité'Parallel 3.2.3 Définition)du)domaine)des)activités)! Le domaine des activités ! ⊂ !"#$%&'#( est construit avec les règles suivantes : • Si ! est une activité proposée par un fournisseur de données, alors ! ∈ !. • Si ! est une activité Extract de type ! ∶ ! → !′ , alors ! ∈ !. • Si ! est une activité Filter, de type ! ∶ ! → ! , alors ! ∈ !. • Si ! est une activité Unique de type ! ∶ ! → ! , alors ! ∈ !. • Si ! est une activité Sort de type ! ∶ ! ×!"#$" → ! , alors ! ∈ !. • Si ! est une activité Append, de type ∪∶ ! × ! → ! , alors ! ∈ !. • Si ! est une activité Concatenate, de type ∶ ! ∶ !! , … , !! ⨁! ∶ !! , … , !! → !_! ∶ !! , … , !!, !! , … , !! , alors ! ∈ !. • Si !! , !! , … , !! ∈ !, alors l’activité Sequence ≫ !!,!!,…,!! ∈ !. • Si ! ∈ !, alors l’activité Foreach ∞ ! ∈ !. C • Si !"#! , !"#! , … !"#! ∈ !, alors l’activité Parallel ∥ !"#!,!"#!,…!"#! ∈ !. Dans ces règles, !, !′,!! , … , !!, !! , … , !! sont des types quelconques qui appartiennent à !. Le domaine ! est extensible : il peut être enrichi dans le futur selon les besoins qui peuvent apparaître. 3.3 Mashlet Un mashlet est une entité réutilisable d’un mashup. Il affiche des données sous la forme d’un widget. Ces données sont produites par une activité. Le type !"#ℎ!"# est définit comme suit : !"#ℎ!"# ∶ !"#$%&'(#)& ∶ !! ,!! , … ,!! , !"#$"#%&$' ∶ !! , !"#$%$#& ∶ ! . Une instance de !"#ℎ!"# définit les types des entrées et des sorties et l’activité qui exécute le traitement de données. Pour chaque instance ! de !"#ℎ!"#, !"#$%$#& est une fonction de type !!× !!× …×!! → !! . !"é!"#$%&' !"#ℎ!"# = !"# ∶ !"#, !"#$"! • !"# est une opération de type !"#ℎ!"# → ! ∶ ∅ . • !"#$"! est une opération de type !"#ℎ!"# → ! ∶ ∅ . act2 act1 Parallel actn … 48 La Figure 18 montre la représentation graphique d’un mashlet avec son activité. L’entrée et la sortie du mashlet sont liées à l’entrée et la sortie de l’activité. Figure'18 :'Représentation'graphique'd'un'mashlet Exemple Soit le fournisseur de données Google maps qui offre une activité !"#$%&#" de type26 !"#$%! ∶ !"#$" ∶ !, !"# ∶ ! → !"#$%& . Dans le mashup ItineraryPlanner, le mashlet !"# reçoit en entrée une donnée contenant une ville de départ et une ville de destination. L’activité sous-jacente est !"#$%&#"' qui récupère l’itinéraire du fournisseur de données Google Maps. !"# = !"#ℎ!"# ∶ !"#$%&'(#)& ∶ !"#$%& ∶ !"#$" ∶ !, !"# ∶ ! , !"#$"#%&$' ∶ !"#$%& , !"#$%$#& ∶ !"#$%&#"' . La représentation graphique de ce mashlet est donnée dans la Figure 19. Figure'19 :'Représentation'graphique'du'mashlet'Map Dans le mashup ItineraryPlanner, le mashlet !"#$ℎ!" reçoit en entrée la liste de localisations des villes de passage sur la route. L’activité sous-jacente est l’activité Foreach !"#"$%&$'#ℎ!" (définie dans la sous-section 3.2.2.2) qui pour chaque ville, récupère les données météorologiques (activité !"#$"%#ℎ!") depuis le fournisseur de donnée Yahoo! Weather. !"#$ℎ!" = !"#ℎ!"# ∶ !"#$%&'(#)& ∶ !"#$%& ∶ !"#$% ∶ ℕ , !"#!"#$%!& ∶ !"#"$%& ∶ ! , !"#$%$#& ∶ !"#"$%&$'#ℎ!" La représentation graphique de ce mashlet est donnée dans la Figure 20. 26 Nous rappelons qu’un type peut être référencé par son nom. Ce qui est le cas de l’utilisation du type !"#$%& ici et dont la définition est donnée à la page 3. Mashlet Ac#vity( input output Map Mashlet getRoutes(49 Figure'20 :'Représentation'graphique'du'mashlet'Weather 3.4 Wiring Un wiring est une entité du mashup qui décrit le flot de données entre deux mashlets. Dans notre modèle, les wirings ne décrivent pas qu’un simple transfert de données entre mashlets : ils peuvent aussi, intégrer une transformation des données pour les délivrer sous le bon format aux mashlets destinataires. Cette transformation définie avec une activité sous-jacente. Un wiring est représenté par un type tuple : !"#"$% ∶ !"#$%&'#( ∶ ! , !"#$"#%&$' ∶ !′ , !"#$"% ∶ !"#ℎ!"# , !"#"$%"! ∶ !"#ℎ!"# , !"#$%$#& ∶ ! . Une instance de !"#"$% définit les types des entrées et des sorties, les mashlets envoyeur (!"#$"%) et receveur (!"#"$%"!) et l’activité qui exécute le traitement de données. Pour chaque instance ! de !"#"$%, nous avons : • L’entrée du wiring est du même type que la sortie de l’instance de !"#ℎ!"# définie dans l’attribut !"#$"% : !"# !. !"#$%&'#( = !"# !"# !. !"#$"% . !"#$"#%&$' • !"#$%$#& est une fonction de type ! → !′ . !"é!"#$%&' !"#"$% = !"# ∶ !"#$ℎ, !"#, !"#$%&'ℎ • !"#$ℎ est une opération de type !"#"$% → ! ∶ ∅ . • !"# est une opération de type !"#"$% → ! ∶ ∅ . • !"#$%&'ℎ est une opération de type !"#"$% → ! ∶ ∅ . Le comportement d’un Wiring est décrit comme suit : il (1) prend les données (!"#$ℎ) en entrée du mashlet envoyeur, (2) les manipule (!!"), en exécutant un processus de transformation de données (défini par l’attribut !"#$%$#& ), pour (3) envoyer le résultat (!"#$%&'ℎ) en sortie au mashlet receveur. La Figure 21 montre la représentation graphique d’un wiring avec son activité. L’entrée et la sortie du wiring sont liées à l’entrée et la sortie de l’activité. getWeather( Weather Mashlet Foreach50 Figure'21 :'Représentation'graphique'd'un'wiring Exemple Dans le mashup ItineraryPlanner, un wiring est nécessaire pour transmettre les villes de passages du mashlet !"# au mashlet !"#$ℎ!". Cependant, dans le mashlet !"#, une ville est décrite comme une paire de longitude et de latitude. D’un autre côté, le mashlet !"#$ℎ!" nécessite qu’une ville soit représentée par un identifiant WOEID. Pour cela le wiring doit procéder à une transformation entre les deux formats. La Figure 22 présente la représentation graphique du wiring !"#2!"#$ℎ!" entre les mashlets !"# et !"#$ℎ!". Soit un fournisseur de données qui offre une activité !"#$%&'( de type !"#$%&' ∶ !"# ∶ ℝ, !"# ∶ ℝ → !"#$% ∶ ℕ . 1. Le wiring prend en entrée la sortie du mashlet !"# : l’itinéraire entre les deux villes de type !"#$%&. L’activité (définie dans l’attribut !"#$%$#&) commence par extraire les villes de passage des étapes de l’itinéraire. Dans la Figure 22, pour des raisons d’espace, nous représentons cette tâche avec une seule activité ExtractRouteCities qui est une activité Sequence. Elle est composée comme suit : a. L’activité !"#$%&#'#!() est une fonction dont la signature est !"#$%& → !"#$!. Le chemin d’accès correspondant est !"#ℎ = !"#$%&. !"#$. !"#$!. Elle retourne la liste des étapes. b. Pour chaque étape de type !"#$. Il faut extraire les coordonnées géographiques du point de départ avec l’activité !"#$%&#'(#) dont la signature est !"#$ → !"#$!_!"#$%&"'. Le chemin d’accès correspondant est !"#ℎ = !"#$. !"#$"_!"#$%&"'. c. Une activité Foreach permet d’extraire les points géographiques de toutes les villes étapes : !"#$%&#'(#(!) = ∞ !"#$%&#'(#) d. Une activité Sequence permet de coordonner les activités : !"#$%&#'()#!*+#+!, = ≫ !"#$%&#'#!(), !"#$%&#'(#(!) 2. Pour chaque paire (longitude, latitude) un service est appelé pour récupérer les différentes descriptions géographiques du lieu (activité !"#$%"&' ). L’identifiant WOEID en est extrait (activité !"#$%&#'()*+ ). Ces activités sont coordonnées avec des activités Sequence et Foreach : !"#$%&'""( = ∞ ≫ !"#$%"&', !"#$%&#'()!" 3. Ensuite, il faut éliminer les doublons27 avec l’activité Unique !"#$!%&'()* décrite dans la soussection 3.2.1.3. 4. Les activités !"#$%&#'()!"#$!$"%, !"#$%& et !"#$!%&'()* sont coordonnées avec une activité Sequence !"#2!"#$ℎ!"#$% = ≫ !"#$%&#'()#!*+#+!,,!"#$%&'""(,!"#$!%&'()* En sortie le wiring !"#2!"#$ℎ!" transmet au mashlet !"#$ℎ!" la liste de localisations des villes décrites sous le format WOEID. Il est modélisé ainsi : !"#2!"#$ℎ!" = !"#"$% ∶ !"#$%&'#( ∶ !"#$%& , !"#$"#%&$' ∶ !"#$%& ∶ !"#$% ∶ ℕ , !"#$"! ∶ !"#, !"#"$%"! ∶ !"#$ℎ!", !"#$%$#& ∶ !"#2!"#$ℎ!"#$% . 27 La présence de doublons est due au fait de la présence de plusieurs étapes de l’itinéraire dans la même ville. Wiring Ac#vity( input output 51 Figure'22 :'Représentation'graphique'du wiring'entre'les'mashlets'Map'et'Weather 3.5 Mashup Un mashup est un ensemble de mashlets et de wirings. Les wirings définissent le flot de données entre les mashlets du mashup. Un mashup définit les types des ses paramètres d’entrées !"#$%&'(#)&, l’ensemble de ses mashlets !"#ℎ!"#$ et de ses wirings !"#"$%&. Il définit également un ensemble de propriétés comme la fréquence d’exécution du mashup, la définition des durées de vie (fixées en nombre d’heures, etc.) des données caractérisées par les noms de leurs types. Il est représenté par un type tuple28 : !"#ℎ!" ∶ 〈!"#$%&'!"#$ ∶ !! ,!! , … ,!! , !"#ℎ!"#$ ∶ !"#ℎ!"# , !"#"$%& ∶ !"#"$% , !"#!$"%&$' ∶ !"#$%#&'( ∶ ℕ, !!"# ∶ !"#"$$%&'( ∶ !"#"$%&'(")' ∶ !,!!" ∶ ℕ 〉 Une instance de !"#ℎ!" définit les types des entrées du mashup, les mashlets et les wirings qui constituent le mashup. !"é!"#$%&' !"#ℎ!" = !"# ∶ !"#$%&'ℎ!"#$%&, !"# !"# et !"#$%&'ℎ!"#$%& sont des opérations de type est !"#ℎ!" → ! ∶ ∅ . Le mashup ItineraryPlanner présenté dans le Chapitre 1 est défini de la façon suivante : !"#$%&'&()*'$$%& = !"#ℎ!" ∶ !"#$%&'(#)& ∶ !"#$" ∶ !, !"# ∶ ! , !"#ℎ!"#$ ∶ !"#, !"#$ℎ!", !"#$%&!%'$# , !"#"$%& ∶ !"#2!"#$ℎ!", !"#2!"#$%&'%($ , !"#!$"%&$' ∶ !"#$%#&'( ∶ 4,!!"# ∶ !"#"$$%&'( ∶ !"#"$%&!"#$! ∶ "!"#$%",!!" ∶ 720 , !"#"$$%&'( ∶ !"#"$%&'(")' ∶ "!"#$ℎ!"",!!" ∶ 6 , !"#"$$%&'( ∶ !"#"$%&'(")' ∶ "!"#$%",!!" ∶ 720 , . Où le mashlet !"#$%&'%($# et le wiring !"#2!"#$!"#!$% sont définis d’une manière similaire que les autres mashlets et wirings définis dans les sections précédentes. Ils sont explicités dans la Figure 23. Celle ci montre la représentation graphique de tous les composants du mashup !"#$%&'&()*'$$%&. Les mashlets !"# et !"#$ℎ!" et le wiring !"#2!"#$ℎ!" furent exposés dans les sections précédentes de ce chapitre. Dans cette figure, nous montrons aussi le mashlet !"#$%&!%'$# qui fournit la liste des restaurants dans la ville de destination. L’attribut !"#$%$#& correspondant est l’activité !"#$%"#$&'(&)$# présentée dans la sous-section 3.2.2.1. Un wiring !"#2!"#$%&'%($ est nécessaire pour transférer la paire (longitude, latitude) de la ville de destination depuis le mashlet !"# vers le mashlet !"#$%&!%'$# (via une activité Extract). 28 Nous rappelons que ! est le domaine des noms de types défini dans la sous-section 3.1.1 Extract Route+ Ci.es+ Foreach Map2Weather Wiring Extract WOEID+ Sequence getWOEID+ Sequence Unique WOEID+52 Figure'23 :'Représentation'graphique'du'mashup'ItineraryPlanner53 3.6 Conclusion Ce chapitre a présenté les concepts de notre modèle de mashup. Nous avons adopté un modèle de données basé sur les valeurs complexes. Des activités basiques décrivent la manipulation des données de mashups (le filtrage, la projection, l’extraction, l’élimination de doublons, le tri, l’union et l’annexe). Elle sont coordonnées par des activités composites (Sequence, Foreach, Parallel). Les activités sont utilisées par des mashlet et des wirings. Les mashlets affichent des données produites par des activités tandis que les wirings coordonnent l’exécution des mashlets. Dans notre modèle, les wirings ne décrivent pas qu’un transfert de données entre mashlets. Ils peuvent aussi, décrire le traitement des données pour les délivrer sous le bon format aux mashlets destinataires. Ces concepts décrivent des entités qui forment des mashups. Chacun de ces concepts était illustré par une représentation graphique qui sert dans la description des activités et de la coordination des mashlets. Les composants du mashup ItineraryPlanner ont été définis selon les concepts du modèle présenté et ils ont été illustrés selon la représentation graphique proposée.55 Chapitre!4 EXECUTION)DE)MASHUPS)AVEC%DISPONIBILITE% DE#DONNEES Ce chapitre présente le processus d’exécution de mashups avec disponibilité de données. L’exécution d’un mashup repose sur la disponibilité de données. Celle ci peut être réduite ou altérée à cause d'une panne au niveau du fournisseur de données ou d’une restriction de nombre de requêtes imposée par ce dernier. Ceci entraîne le dysfonctionnement du mashup. Nous avons constaté dans le Chapitre 2 que les techniques actuelles de disponibilité de données ne sont pas adaptées à des applications comme les mashups. Nous avons constaté, également, que parmi le peu de travaux qui se sont intéressés à la disponibilité des données des mashups, le problème de la fraicheur des données disponibles n’est pas abordé. Pour cela nous proposons un processus pour assurer la disponibilité de données. Ce processus permet également (1) de définir les données dont la disponibilité n’est plus à assurer et (2) d’assurer la fraicheur de données rendues disponibles. Le scénario ItineraryPlanner est utilisé comme exemple pour illustrer le processus d’exécution de mashups. Nous rappelons qu’il affiche l’itinéraire entre deux villes (mashlet !"#), les données météorologiques dans les villes de passage (mashlet !"#$ℎ!") et une liste de restaurants situés dans la ville d’arrivée (mashlet !"#$%&!%'$#). Les wirings !"#2!"#$ℎ!! et !"#2!"#$%&'%($# définissent le flot de données entre les mashlets. Des activités définissent le traitement des données dans les mashlets et les wirings. Le chapitre est organisé comme suit : la section 4.1 présente les principaux éléments de l’exécution d’un mashup. Ensuite, la section 4.2 décrit notre proposition pour assurer la disponibilité de données lors de l’exécution des mashups. Cette solution est à base de fonctions que nous introduisons d’une façon orthogonale au processus d’exécution de mashups. Elles permettent d’améliorer la disponibilité des données de mashups et d’assurer leur fraicheur. Enfin, la section 4.3 conclut ce chapitre.56 4.1 Exécution d’un)mashup Un mashup est vu comme une instance du modèle décrit dans le Chapitre 3. L’exécution d’un mashup (cf. Figure 24) déclenche les exécutions de mashlets et de wirings sous-jacents. Figure'24 :'Diagramme'd’activité UML'de'l’exécution'd’un'mashup57 Ces exécutions partagent leurs données à travers un espace mémoire (privée au mashup). Celui ci est partagé en lecture et en écriture. Ainsi les mashlets, les wirings et les activités d’un mashup partagent leurs données par des lectures et des écritures concurrentes. Le contenu de cet espace est supprimé, une fois l’exécution du mashup achevée. L’ordre des exécutions des mashlets et des wirings est représenté à travers un graphe dirigé qui constitue le plan d’exécution du mashup appelé graphe de mashup. Les nœuds de ce graphe correspondent aux wirings et mashlets du mashup. Un graphe de mashup est un quadruple !, !, !, !"#$" , où : • ! est un ensemble de nœuds mashlets. • ! est un ensemble de nœuds wirings. • ! ⊂ !×! ∪ !×! est un ensemble d’arcs construits ainsi : ∀ ! ∈ !, ∃ !! , !! ∈ ! tel que !! , ! , !, !! ∈ !. • !"#$" ⊆ ! est un ensemble de nœuds de départ. Par exemple, le graphe du mashup ItineraryPlanner est donné dans la Figure 25. Figure'25 :'Graphe'du'mashup'ItineraryPlanner L’exécution du mashup utilise le graphe pour réaliser l’exécution des mashlets et des wirings le composant, par exécution des activités correspondantes (voir sous-sections 4.1.2 et 4.1.3). Le graphe est parcouru de manière classique : un nœud est visité si tous ses prédécesseurs ont déjà été visités. La Figure 26 donne une vision globale de l’exécution du mashup ItineraryPlanner. Les numéros, dans le graphe, indiquent un ordre possible, des exécutions des nœuds, défini lors du parcours du graphe. Chaque exécution d’un nœud (mashlet et wiring) du graphe déclenche l’exécution de l’activité correspondante (cf. sous-sections 4.1.1 à 4.1.3). Les sections suivantes décrivent les processus d’exécution de mashlets et de wirings. Comme ces deux processus exécutent tous les deux des activités, nous commençons par préciser l’exécution de ces activités. 4.1.1 Exécution)d’une)activité Une activité est représentée sous la forme d’un arbre. Les feuilles d’un arbre d’activités correspondent à des activités basiques, alors que les nœuds intermédiaires correspondent à des activités composites (cf. le modèle de mashups Chapitre 3). Un arbre d’activité est définie comme suit : mashlet( Weather wiring map2Restaurants mashlet( Map mashlet( Restaurants wiring map2weather(58 • Soit ! l’ensemble des activités basiques et ℭ celui des activités composites • Un arbre est constitué : o Soit d’une feuille ! ∈ ! o Soit d’une racine ! ∈ ℭ et d’un ou plusieurs arbres disjoints s! , … , s! appelés arbres fils. On le note !, s! , … , s! . Figure'26 :'Exécution'du'mashup'ItineraryPlanner Par exemple, l’arbre de l’activité du wiring !"#2!"#$ℎ!" (cf. section 3.4) est représenté dans la Figure 27. Cette activité extrait (séquence d’activités Extract) les villes de passages sous format (longitude, latitude). Ensuite pour chaque ville (boucle Foreach) un service est appelé (via le nœud Retrieve) pour procéder à la conversion en format WOEID. Ensuite, la valeur entière est extraite (Extract). Enfin les doublons sont éliminés (Unique). Figure'27 :'Arbre'de'l’activité du'wiring'!"#$%&"'(&) Exécution du graphe : parcours des nœuds mashlet( Weather wiring map2Restaurants mashlet( Map mashlet( Restaurants wiring map2weather( 1 2 3 4 5 Map Mashlet getRoutes( getWeather( Weather Mashlet Foreach Sequence' Sequence' Retrieve' Foreach' Unique' Sequence' Extract' Foreach' Extract' Extract'59 L’exécution de l’activité consiste à parcourir l’arbre selon une stratégie en profondeur préfixe [96]. C’est un parcours récursif qui lors de la visite d’un nœud n, continue la visite en parcourant les sous-arbres de gauche à droite. L’exécution d’activités est une phase commune aux processus d’exécutions de mashlets et de wirings. La Figure 28 présente le processus d’exécution du mashup ItineraryPlanner tout en prenant en compte la représentation des arbres d’activités. Figure'28 :'Exécution'du mashup ItineraryPlanner' Chaque nœud possède son propre tampon. Celui ci stocke les adresses des valeurs entrée/sortie de l’activité sous-jacentes. Ces valeurs sont stockées dans l’espace mémoire partagé. Dans la suite de cette sous-section, nous allons décrire le nœud d’une activité basique et à titre d’exemple celui de l’arbre de l’activité composite Sequence. 4.1.1.1 Activité basique Une activité basique est représentée par un nœud feuille (Figure 29) dans un arbre d’activités. Le nœud contient les paramètres de l’activité sous-jacente, par exemple : condition de filtrage, expressions de chemins d’accès. Figure'29 :'Composition'd'un'nœud'd'une'activité'basique L’exécution d’une activité basique (cf. Figure 30) commence par la lecture de la valeur de l’entrée de l’activité. Celle ci est écrite dans la mémoire partagée et son adresse est indiquée dans Exécution du graphe : parcours des nœuds Retrieve' Mashlet Map Foreach' Retrieve Mashlet Weather entrée& sor)e& Tampon Nom de l’activité Paramètres de l’activité 60 le tampon de l’activité. La deuxième phase correspond à l’exécution de l’opération sous-jacente : filtrage extraction, élimination de doublons… Ces opérations sont proposées dans la plupart des langages de d’interrogation de données. Enfin le résultat de l’exécution est écrit dans la mémoire partagée à l’adresse indiqué dans le tampon de l’activité. Figure'30 :'Diagramme'd’activité'UML'du'processus'd’exécution'd'une'activité'basique Cas(des(activités(proposées(par(des(fournisseurs(de(données Nous introduisons le nœud de type Retrieve (cf. le diagramme de communication de la Figure 31) pour lancer l’exécution une activité proposée par un fournisseur de données et indiquée dans les paramètres du nœud. Figure'31 :'Diagramme'de'communication'entre'le'nœud'Retrieve et'le'fournisseur'de'données L’exécution d’un nœud Retrieve envoie les valeurs des paramètres d’entrée (écrites dans le champ « entrée ») d’une activité proposée par un fournisseur de données et demande son exécution. Le résultat reçu est stocké dans l’espace mémoire partagé. L’adresse de ce résultat est indiquée dans le champ « sortie » du tampon du nœud. 4.1.1.2 Activité)Sequence Pour une activité Sequence ≫ !"#!,!"#!,…!"#! , l’arbre de nœuds correspondant est présenté dans la Figure 32, où « Nœud 1 », « Nœud 2 », … et « Nœud n » sont les nœuds représentant les arbres correspondants aux sous-activités !"#! , !"#! , …, et !"#!. Les nœuds échangent les adresses des données stockées dans la mémoire partagée. Retrieve 1 : Valeurs des Paramètres d’entrée 2 : Résultat61 Figure'32 :'Arbre'de'nœuds'd’une'activité'Sequence L’exécution d’une activité Sequence (cf. Figure 33) déclenche l’exécution de ses sousactivités d’une façon séquentielle. Pour chaque sous-activité, elle (1) commence par écrire l’adresse de l’entrée dans le tampon. Pour la première sous-activité, l’entrée correspond à celle de l’activité Sequence alors que pour chacune des autres sous-activités, elle correspond à la sortie de la sousactivité précédente. Ensuite elle (2) déclenche l’exécution de la sous-activité. Enfin (3), elle récupère l’adresse de la sortie pour l’écrire dans le champ « entrée » du tampon de la sous-activité suivante. La valeur du champ « sortie » du tampon de la dernière sous-activité est écrite dans le champ « sortie » du tampon du nœud parent. Figure'33 :'diagramme'd’activité UML du'processus'd’exécution'd'une'activité'Sequence Valeur'de'l’input' de'Sequence Valeur'de'l’output' du'nœud'1'(input' du'nœud'2)' Valeur'de'l’output' du'nœud(n71)' (input'du'nœud'n)' Valeur'de'l’output' de'Sequence Valeur'de'l’output' du'nœud'2'(input' du'nœud'3)' Mémoire partagée Nœud 1 Input' Output' Nœud n Sequence Input' Output' Input' Output' Nœud 2 Input' Output' … 62 4.1.2 Exécution)d’un)mashlet La Figure 34 présente les phases du processus d’exécution d’un mashlet et montre qu’il déclenche principalement l’exécution de l’activité sous-jacente et la génération d’une visualisation définissant l’affichage graphique de la sortie du mashlet. Chaque mashlet possède son propre tampon. Celui ci stocke les adresses des valeurs de ses entrée/sortie. Ces valeurs sont stockées dans l’espace mémoire du processus exécutant le mashup. Les valeurs des entrées de certains mashlets sont connues dès le début de l’exécution du mashup comme les villes de départ et d’arrivée dans le mashlet !"# du le mashup ItineraryPlanner. Les adresses de ces valeurs sont écrites dans le tampon du mashlet avant le parcours du graphe. C’est le processus exécutant le mashup qui s’occupe de cette tâche. Les valeurs des entrées d’autres mashlets sont connues au cours de l’exécution du mashup (parcours du graphe) et transférées par des wirings (voir sous-section 4.1.3) : par exemple, la liste de villes de passages comme entrée du mashlet !"#$ℎ!" obtenue via le wiring !"#2!"#$ℎ!". Les premières phases du processus d’exécution d’un mashlet correspondent au transfert de l’adresse de l’entrée du mashlet à son activité sous-jacente ainsi qu’à l’exécution de cette activité d’activités (cf. sous-section 4.1.1). Ensuite, l’adresse de la sortie de l’activité est écrite dans le tampon du mashlet. Cette adresse peut être lue par des wirings afin qu’ils accèdent à la donnée, la manipuler, et la transférer à d’autres mashlets : par exemple les données de l’itinéraire du mashlet !"# sont manipulées par le wiring !"#2!"#$ℎ!" afin de transférer la liste de villes de passage au mashlet !"#$ℎ!". Enfin, la dernière phase consiste en la génération d’une visualisation graphique de ces données. Cette visualisation est affichée sur le terminal de l’utilisateur sous la forme d’un widget. Figure'34 :'Diagramme'd’activité UML'de'l’exécution'd’un'mashlet 4.1.3 Exécution)d’un)wiring Le processus d’exécution d’un wiring est constitué de trois phases (cf. Figure 35). La première phase consiste en la récupération de l’adresse de la valeur de la sortie du mashlet envoyeur : par exemple le wiring !"#2!"#$ℎ!" récupère l’adresse des les données de l’itinéraire 63 depuis le tampon du mashlet !"#. La deuxième phase correspond à l’exécution de l’activité correspondante. Enfin, lors de la phase de Livraison, les données produites à la fin de la phase précédente sont livrées au mashlet receveur (écriture de l’adresse dans le tampon du mashlet) : par exemple le wiring !"#2!"#$ℎ!" écrit l’adresse de la liste de villes de passage dans le tampon du mashlet !"#$ℎ!". Figure'35 :'Diagramme'd’activité'UML'de'l’exécution'd’un'wiring 4.2 Disponibilité)des)données)dans)les)mashups Nous proposons une approche pour assurer la disponibilité de données récupérées auprès des fournisseurs de données. Ces données sont stockées dans une structure que nous nommons !"#$%. Nous introduisons dans l’arbre d’activités une nouvelle famille de nœuds : Retrieve++. A la différence d’un nœud Retrieve, un nœud Retrieve++ vérifie la présence des données recherchées dans le !"#$% avant de lancer l’exécution de l’activité sous-jacente proposée par un fournisseur de données. Le processus proposé permet de rendre, disponibles, les données récupérées. Ce processus est illustré dans la Figure 36. Figure'36':'Diagramme'de'communication UML entre'le'nœud'Retrieve++,'le'fournisseur'de'données'et' le !"#$% La Figure 37 qui donne une vision globale de la phase d’exécution du mashup ItineraryPlanner avec intégration du processus de disponibilité de donnée. 64 Figure'37 :'Exécution'd’un'mashup'avec'disponibilité'de'données Dans cette section, nous présentons un diagramme d’activité décrivant le processus d’exécution d’un nœud Retrieve++. Ce diagramme est présenté dans plusieurs figures (Figure 39, Figure 40 et Figure 42). Il est dans un premier temps minimaliste. Ensuite, il sera enrichi tout au long de cette section lors de la présentation des fonctionnalités du processus de disponibilité de données. Il s’intègre au diagramme de la Figure 24, en faisant partie du processus de l’exécution des activités. Lorsque le !"#$% devient saturé (capacité maximale atteinte), une partie des données est supprimée pour libérer de l’espace et pouvoir stocker des nouvelles données. Les données des mashups sont dynamiques et ont une durée de vie limitée. Pour cela ces données doivent être rafraichies en anticipant les nouvelles demandes de récupération lors d’une exécution ultérieure d’un mashup. Ainsi, notre processus de disponibilité est basé sur des fonctions de gestion, de remplacement et de rafraichissement de données du !"#$% (sous-sections 4.2.2, 4.2.3 et 4.2.4). Celui ci est administré par un administrateur qui doit faire certains choix au niveau des fonctions du !"#$%. Ces choix seront explicités au cours des sous-sections qui suivent. Ces fonctions sont orthogonales par rapport au processus d’exécution de mashups réalisé par un moteur de mashups. La section 4.2.5 récapitule le processus d’exécution d’un nœud Retrieve++ avec exploitation du !"#$% et des fonctions associées. Comme ces fonctions opèrent sur des données rendues disponibles, nous commençons par préciser l’organisation de ces données.65 4.2.1 Organisation)de)données du)!"#$% Les données sont organisées, au sein du !"#$%, sous la forme d’items. Un item est un tuple qui possède les attributs « id » et « object ». Il est identifié avec la valeur de son attribut « id ». Dans le contexte des mashups, l’attribut « id » correspond à une activité et les valeurs de ses paramètres d’entrée (sous la forme d’une liste de valeurs) alors que l’attribut « objet » correspond à la valeur du paramètre de sortie produite par l’exécution de l’activité. Un item maintient, de plus, d’autres informations nécessaires pour assurer les fonctions comme le remplacement et le rafraichissement des données. Il est représenté par un tuple : !"#$ ∶ 〈!" ∶ 〈!"#$%$#& ∶ !, !"#$%& ∶ [!"#$% ∶ !"#"]〉, !"#$%& ∶ !"#",!!" ∶ ℕ, !""#$$%& ∶ ℕ, !"#$ℎ!"#$ ∶ !"#$, !"#$%!&' ∶ !"#$, !"#$%&&'## ∶ !"#$, !"#$%&' ∶ ℕ〉. où : • !"#$29 est une définition de type définie comme suit : !"#$%& ∶ 1,2, … 60 , ℎ!"# ∶ 1,2, … 24 , !"#$ℎ ∶ 1,2, … 12 , !"# ∶ 1,2, … 31 , !"#$ ∶ ℕ . • accessNb de type entier, il indique le nombre d’accès à item. • ttl de type entier, il indique la durée de vie de l’item (en nombre d’heures). • birthDate indique la date de création de l’item. • expireOn indique la date d’expiration de l’item. • lastAccess indique la date du dernier accès à l’item. • latency indique le temps mis pour récupérée les données depuis le fournisseur. !"#$%&'()* !"#$ = !"# ∶ !"#!"$ℎ, !"#$%!&'(, !"#$%&''( où : • Pour une instance ! de type !"#$, l’opération !"#!"$ℎ exécute l’opération !. !". !"#$%$#& avec les valeurs des paramètres indiquées par !. !". !"#$%&. Elle écrit le résultat de l’opération dans !. !"#$%&. Ensuite elle retourne un booléen indiquant le bon déroulement de l’opération. o Type de !"#!"$ℎ : !"#$ → ! o Sémantique : l’appel de !. !"#!"$ℎ() exécute l’instruction suivante30 : !. !"#$%& = !"!"#$ !. !". !"#$%$#&, !. !". !"#$%& • Pour une instance ! de type !"#$, l’opération !"#$%!&'( vérifie si la donnée enregistrée dans ! est encore fraiche. o Type de !"#$%!&'( : !"#$ → ! o Sémantique : l’appel de !. !"#$%!&'(() retourne !. !"#$%!&' < !"#() • Pour une instance ! de type !"#$ , l’opération !"#$%&''( permet de modifier la valeur de l’attribut « ttl » de ! et de lui affecter une valeur passée en entrée. La fonction retourne un booléen indiquant le bon déroulement du processus d’ajustement. o Type de !"#$%&''(: !"#$×!"#$$% ∶ ℕ → ! o Sémantique : l’appel de !. !"#$%&''( !!"#$" exécute l’instruction suivante : !.!!" = !!"#$". où !!"#$! est une instance du type du paramètre d’entrée d’!"#$%&''(. La durée de vie d’un item peut être modifiée au cours du temps. Ce point sera expliqué dans la sous-section 4.2.4.2 lors de la description du processus de rafraichissement des items. 29 Nous considérons la fonction !"#() qui retourne une instance de !"#$ correspondante à l’instant courant. 30 Nous rappelons que !"#$%& est une opération définie sur tous les types fonction pour réaliser l’exécution de leurs instances (cf. sous-section 3.1.4) 66 Exemple Nous considérons !"#$%&'($%) une instance de !"#$ . Elle correspond à la donnée !"#$%&' (cf. sous-section 3.1.2) et récupérée avec l’activité !"#$%&#"' définie dans la section 3.3. Elle est définie comme suit : !"#$%&'($%) = !"#$ ∶ 〈!" ∶ !"#$%$#& ∶ !"#$%&#"', !"#$%& ∶ !"#$% ∶ Grenoble, !"#$% ∶ Paris , !"#$%& ∶ !"#$%&', !!" ∶ 720, !""#$$%& ∶ 8, !"#$ℎ!"#$ ∶ !"#$%& ∶ 05, ℎ!"# ∶ 15 !"#$ℎ ∶ 11, !"# ∶ 1, !"#$ ∶ 2012 , !"#$%!&' ∶ !"#$%& ∶ 05, ℎ!"# ∶ 15 !"#$ℎ ∶ 12, !"# ∶ 1, !"#$ ∶ 2012 , !"#$%&&'## ∶ !"#$%& ∶ 30, ℎ!"# ∶ 7 !"#$ℎ ∶ 11, !"# ∶ 10, !"#$ ∶ 2012 , !"#$%&' ∶ 1000〉 La Figure 38 montre la représentation graphique de !"#$% contenant des items pour différents mashups. Le premier ItineraryPlanner et d’autres mashups à la iGoogle contenant des mashlets dont certains affichent la météo de la ville de résidence des utilisateurs. Les différents mashlets météo partagent leurs items. Figure'38 :'Représentation'du'!"#$% 4.2.2 Gestion)du)!"#$% La gestion du !"#$% se fait par des fonctions qui permettent d’ajouter, de supprimer et de rechercher des items. Elles sont définies comme suit : 4.2.2.1 Ajout)d’un)item Nous définissons la fonction !"#$. Elle crée une instance d’!"#$ dont les valeurs des attributs « id » « objet » et « ttl » sont passées en paramètre. La valeur de l’attribut « accessNb » est initialisée à 1. Les valeurs des attributs « birthDate » est « lastAccess » sont initialisées à la date courante. Et la valeur de l’attribut « expireOn » est calculée à partir de la date courante et la valeur de l’attribut « ttl ». Ensuite l’instance créée est ajoutée au !"#$%. La fonction retourne un booléen indiquant le bon/mauvais déroulement du processus. • Type de !"#$ : !" ∶ 〈!"#$%$#& ∶ !, !"#$%& ∶ [!"#$% ∶ !"#"] 〉, !"#$%& ∶ !"#",!!" ∶ ℕ → ! • Sémantique : Pour !"#$ !"#$%, !"#$%&,!!"#$" : o !"#$%"& = !"#$ ∶ !" ∶ !"#$%, !"#$%& ∶ !"#$%&,!!" ∶ !!"#$", !""#$$%& ∶ 1, !"#$ℎ!"#$ ∶ !"#(), !"#$%!&' ∶ !"#() + !!"#$", !"#$%&&'## ∶ !"#() Grenoble( Lyon( Road2( Paris( Weather1( Lyon( Weather2( Grenoble Weather3( entry( item( item( item( item( item( item( entry( item( Grenoble( Paris( Road1(67 o !"#$% = !"#$% + !!"#$!% o !"#$%, !"#$%&,!!"#$" sont respectivement des instances de type des paramètres d’entrée de !"#$ : !", !"#$%&,!!". 4.2.2.2 Suppression)d’un)item Nous définissons la fonction !"#$"%. Elle prend en entrée la valeur de l’attribut « id » d’une instance ! d’!"#$ présente dans !"#$%. La fonction permet de supprimer ! du !"#$%. Elle retourne un booléen indiquant le bon déroulement du processus de suppression. • Type de !"#$"% : !" ∶ !"#$%$#& ∶ !, !"#$%& ∶ !"#$% ∶ !"#" → ! • Sémantique : Pour !"#$"% !"#$% où !"#$% est une instance du type du paramètre d’entrée de !"#$"% : !". !"#$% = !"#$% − ! !. !" = !"#$% 4.2.2.3 Recherche)d’un)item Nous définissons la fonction !""#$%. Elle prend en entrée une valeur possible !"#$% de l’attribut « id » du type !"#$. La fonction vérifie si une instance ! d’!"#$ (avec !. !" = !"#$%) est présente dans !"#$% et dans ce cas elle la retourne en sortie. • Type de !""#$%: !" ∶ !"#$%$#& ∶ !, !"#$%& ∶ !"#$% ∶ !"#" → !"#$ • Sémantique : !""#$% !"#$% = ! ! ∈ !"#$% !" !. !" = !"#$% La Figure 39 présente l’utilisation des fonctions !""#$% et !"#$ dans le processus d’exécution d’un nœud Retrieve++ afin de (1) rechercher des données au sein du !"#$% avant de les récupérer auprès du fournisseur de données et (2) d’ajouter les données récupérées dans le !"#$% pour une utilisation ultérieure. Rappelons que le diagramme présenté dans la figure est une version minimaliste du processus d’exécution du nœud Retrieve++ et qu’elle sera enrichie toute au long de la section 4.2. Figure'39 :'Utilisation'des'fonctionnalités'de'gestion'du'!"#$% dans'l’exécution'd’un'nœud'Retrieve++68 4.2.3 Remplacement)de)données Le remplacement des items dans le !"#$% se fait selon une politique de remplacement. Celle-ci détermine les items devant être supprimés du !"#$% pour libérer de la place pour pouvoir stocker des nouveaux items. Elle vise à maximiser les avantages de l’utilisation du !"#$%. Nous définissons la fonction !"#$%&&!. Elle libère du !"#$% un espace dont la taille est égale ou supérieure à une valeur donnée !"#$%ℎ. Elle retourne une valeur booléenne indiquant si l’opération s’est bien exécutée ou pas. • Type de la fonction : !"#$%ℎ ∶ ℕ → ! . • Sémantique de la fonction : • Pour !"#$%&&! ! avec ! ∈ ℕ : o Taille des données dans le !"#$% avant l’exécution = ! o Taille des données dans le !"#$% après l’exécution = ! − ! La Figure 40 présente l’utilisation de la fonction !"#$%&&! dans le processus d’exécution d’un nœud Retrieve++ afin de libérer de l’espace lorsque le !"#$% devient saturé. Figure'40':'Utilisation'de'la'fonction'!"#$%&&! dans'l’exécution'd’un'nœud'Retrieve++ Le remplacement se fait selon plusieurs facteurs (sous-section 4.2.3.1) qui sont pondérés dans une formule de poids d’item (sous-section 4.2.3.2). 69 4.2.3.1 Facteurs)de)la)politique)de)remplacement La plupart des politiques de remplacement existantes (comme FIFO, LIFO, LRU (Last Recently Used), MRU (Most Recenty Used) …) sont basées sur le moment d’ajout et d’accès à une données. D’autres politiques sont basées sur des facteurs comme : • La taille des données : en effet, il est plus intéressant de supprimer des items de grande taille pour laisser la place à plusieurs items de petite taille. • La latence du fournisseur des données : en effet, il est plus intéressant de garder les items dont la récupération est plus lente. Ces facteurs sont présents en tant qu’attributs dans la définition du type !"#$. Les valeurs de certains sont déterminées lors de la création de l’item (voir la fonction !"#$ dans la sous-section 4.2.2.1) alors que les valeurs d’autres attributs évoluent avec le temps comme le nombre d’accès et la date du dernier accès à l’item. Dans le contexte des mashups les données sont dynamiques, elles ont une durée de validité déterminée dont il faut tenir compte. Les facteurs à prendre en compte sont • La durée de vie restante pour un item. En effet, il est plus intéressant de garder un item i1 dont la durée de vie restante est supérieure à celle d’un item i2. Pour un item i du !"#$% ce facteur est calculé avec la formule : !. !"#$%!&' − !"#() • Le nombre d’accès à un item i en prenant en compte son âge (calculé avec la formule !"#() − !. !"#$ℎ!"#$). En effet, il est plus intéressant de maintenir dans le !"#$% un item i1 pour lequel il y a eu 10 accès en une heure qu’un item i2 pour laquelle il y a eu 20 accès en 24 heures. Ce facteur est calculé avec la formule : !.!""#$$%& !"#()!!.!"#$!!"#$ 4.2.3.2 Le)poids)d’un)item La politique de remplacement associe un poids à chaque item présent dans le !"#$%. Le poids d’un item définit la probabilité que cet item soit accédé dans le futur. Les items dont les poids sont les moins élevés, sont retenus pour être évincés lors du processus de remplacement. L’expression du poids est définie par une formule algébrique ayant comme variables des facteurs de remplacement de données. Une politique de remplacement choisie peut être adaptative : la formule correspondante contient des paramètres (coefficients ou exposants) de poids pour favoriser des facteurs par rapport à d’autres. Ces paramètres sont modifiables par l’administrateur du !"#$%. Une politique de remplacement adaptative peut donc être définie par la formule suivante : !"!"# = !. !" + !. !" ! + ! !"# + ! !"# Où : • LT : durée de vie restante avant expiration. • A : âge de l’item. • AN : nombre d’accès à l’item. • Lat : latence de la récupération de la donnée. • Len : taille de l’item. • !, !, ! et ! sont des coefficients attachés aux facteurs de la politique remplacement de données pour définir leurs poids. 70 Le type de fonctions de poids est !"#$%#!&ℎ! ∶ !"#$ → !"#$ℎ! ∶ ℝ . Une fonction de ce type permet de définir le poids (selon une formule déterminée) d’une instance de !"#$ donnée en entrée. Lors de l’éviction des données (par appel de la fonction !"#$%&&!), les instances, dont les poids sont les moins élevés, seront supprimées. Cette fonction peut être modifiée au cours du temps. Ceci donne à la fonction de remplacement une caractéristique d’adaptabilité. 4.2.4 Rafraichissement)de)données Intuitivement, lorsqu’un item du !"#$% expire, il doit émettre une notification pour demander sa mise à jour. Ce processus nécessite d’associer à chaque item un mécanisme (thread) pour surveiller sa date d’expiration. Or le !"#$% est amené à stocker, au minimum, des milliers d’items. Techniquement, ceci revient à lancer autant de threads. Nous considérons que cette solution n’est pas optimale (gourmande en ressources) et donc nous l’écartons. Nous proposons un processus de rafraichissement où les items doivent être parcourus périodiquement, pour mettre à jour ceux qui sont périmés. Pour éviter de parcourir tous les items, nous proposons de stocker des références aux items du !"#$% dans une structure de données ordonnée : !"#$%&#'% (cf. Figure 4131 et la sous-section 4.2.4.3). Figure'41 :'Rafraichissement'des'items Les éléments de !"#$%&#'% sont des instances de type !"#$%#&. Chacune de ces instances contient une référence à un item du !"#$% et sa date d’expiration. L’ordre de ces instances dans !"#$%&#'% est défini selon la date d’expiration. Le type !"#$%#& est défini comme suit : !"#$%#& ∶ !"# ∶ !, !"#$%&'()! ∶ !"#$ où ! est l’ensemble des références des instances de type !"#$. !"#$%&'()* !"#$%#& = !"#$#"% où l’opération !"#$#"% est de type !"#$ ∶ !!"#$"% → !"#$"# ∶ !"#$ . Pour une instance ! de !"#$%#& , !. !"#$#"% retourne l’item référencé par la référence !. !". La fréquence de rafraichissement ainsi que la gestion des durées de vie des items seront étudiées dans les sous-sections 4.2.4.1 et 4.2.4.2. Ensuite, le choix de la structure de données de 31 La représentation graphique linéaire de !"#$%&#'% est indépendante de la structure de données choisie. ItemsRefs ir1 ir2 ir3 ir4 ir5 … d1 < d2 < d3 < d4 < … ! !" !" !"#$% !"#$%& !" !"#$%"# !""è! < ! !!" 10 !"#$# Où ! et ! sont des seuils définis par l’administrateur du !"#$%. (b) Item valide Si l’item est jugé encore valide, ceci constitue une justification pour considérer que la valeur de TTL est sous-estimée et qu’il faut l’augmenter. L’incrément est calculé par une fonction !"# en fonction de la valeur actuelle de TTL et des données statistiques comme le nombre d’accès à l’item, la date du dernier accès. !"# est de type !"#$$" ∶ ℕ, !" ∶ ℕ, !" ∶ !"#$ → !"#$%&%"' ∶ ℕ . Plus (1) le nombre d’accès est grand (plus grand qu’un seuil donné), ou (2) plus le temps écoulé depuis la dernière date d’accès est petit (plus petit qu’une durée donnée) alors plus l’incrément doit être petit. Et inversement, plus le nombre d’accès est petit et le temps écoulé depuis la dernière date d’accès est grand, plus l’incrément doit être grand. Ce choix est justifié par le souci de maintenir le plus possible la fraicheur (ajout d’un petit incrément) des données qui sont fréquemment ou récemment demandées. La valeur de TTL peut être incrémentée jusqu’à une valeur maximale !!"# . Ce seuil constitue une limite supérieure des valeurs TTL des items pour éviter le risque de la présence des données périmées dans le !"#$% pour longtemps. Ainsi la valeur de TTL est définie selon la formule suivante : 73 !!" = !"# !!"#, !!" + !"# !!", !", !" Où : • !!" est la valeur actuelle de la durée de vie de l’item. • !" est le nombre d’accès à l’item. • !" est la date du dernier accès à l’item. Par exemple, un incrément peut être défini selon la formule suivante : !"# !!", !", !" = !!" 10 !" !" > ! !" !" !"#!" !"#$%& !" !"#$%"# !""è! < ! !!" 2 !"#$# Où ! et ! sont des seuils définis par l’administrateur du !"#$%. 4.2.4.3 Choix)de)la)structure)de)données de)!"#$%&#'% Le choix de la structure de !"#$%&#'% peut se faire entre différentes structures comme un tableau ordonné, une liste chainée ordonnée, un arbre binaire ou un arbre rouge-noire. Pour des détails à propos de ces structures, le lecteur est invité à consulter la référence [96]. Pour toutes ces structures, La recherche d’un objet (instance de !"#$%#&) à partir de la valeur de l’attribut !"# nécessite le parcours séquentiel du tableau (Complexité ! (!)). Ceci est dû au fait que les objets sont triés par rapport à la date d’expiration de l’item référencé et non pas par rapport à la référence de l’item. Dans un tableau ordonné, les objets sont accédés par leurs indices. Les coûts de l’insertion et la suppression d’un objet sont linéaires par rapport à la taille du tableau. Dans une liste chainée, les objets sont arrangés linéairement. Les coûts de l’insertion et la suppression d’un objet sont linéaires par rapport à la taille de la liste. Dans un arbre binaire de recherche les coûts de l’insertion et de la suppression dépendent de la profondeur de l’arbre. Chacun est de l’ordre ! (ℎ) sur un arbre de profondeur maximale ℎ. Les coûts peuvent aller de ! (lg ! ) dans les cas les plus favorables (arbres binaires complets) jusqu’à ! (!) dans les cas les plus défavorable (arbre constituée d’une chaine linéaire de n nœuds). Un arbre rouge-noir est un type particulier d’arbre binaire de recherche. Chaque nœud est coloré (rouge ou noire) selon les règles suivantes : • La racine et les feuilles sont noires. • Si un nœud est rouge alors ses deux nœuds fils sont noirs. • Pour tout nœud, les chemins reliant ce nœud à des feuilles contiennent le même nombre de nœuds noirs. La coloration garantie qu’aucun des chemins allant de la racine aux feuilles n’est plus de deux fois plus long que n’importe quel autre, ce qui rend l’arbre approximativement équilibré. Les coûts de l’insertion et la suppression d’un objet sont de l’ordre logarithmique (Complexité ! (lg ! )). Le Tableau 5 dresse la complexité des opérations d’insertion, de suppression et de recherche dans différentes structures. Nous constatons que l’arbre rouge-noir offre de meilleures performances en ce qui concerne l’insertion et la suppression de nouveaux objets.74 Insertion/suppression Recherche Tableau !(!) !(!) Liste chainée !(!) !(!) Arbre binaire !(ℎ) !(!) Arbre rouge-noir !(lg (!)) !(!) Tableau'5':'Coût'des'opérations'dans'différentes'structures'de'données32 Cette comparaison nous permet de choisir l’arbre rouge-noir comme structure de données pour stocker les références des items du !"#$%. Nous définissons le type arbre rouge noir comme suit : • Si ! est un type alors ! ∶ ! ∈ ! est un type arbre rouge noir nommé !. Ses nœuds sont des instances du type !. • Pour un type arbre rouge noir ! ∶ ! , ! ∶ ! = ! ∶ ! ! ∈ ! ∪ ! × ! ∶ ! × ! ∶ ! . !"#$%&'()*(! ∶ ⌊!⌋) = {!"#$%&, !"#"$", !""#$%, !"#$%&", !"#$"%#&ℎ!"#, !"#$%!ℎ!"ℎ!"#} 4.2.5 Exécution d’un)nœud)Retrieve++)) L’interaction entre le mashup et le !"#$% se déroule lors de l’exécution des nœuds Retrieve++. Elle se fait en exploitant les fonctions associées au !"#$%. Elle est illustrée dans le diagramme d’activité de la notation UML dans la Figure 42. L’interaction se déroule comme suit : • Vérifier (avec la fonction !""#$%) si un item du !"#$% contient la donnée recherchée. o Si l’item existe : " S’il est périmé, il est rafraichi et sa durée de vie est ajustée selon la stratégie TTL incrémental décrite dans la sous-section 4.2.4.2 " Dans tous les cas, la donnée qu’il contient est prise comme résultat de l’exécution du nœud Retrieve++. o Sinon : " La donnée est récupérée directement auprès du fournisseur. Et elle est prise comme résultat de l’exécution du nœud Retrieve++. " Si le Store est plein, des items sont supprimés avec la fonction !"#$%&&! . La suppression se fait selon une formule de remplacement comme celle définie dans la sous-section 4.2.3.2. " Un nouvel item, contenant la donnée récupérée, est crée et ajouté au !"#$% avec la fonction !"#$. Nous rappelons que, parallèlement à ce processus, le !"#$% est parcouru périodiquement pour rafraichir les items périmés d’une façon proactive sans attendre l’arrivé d’une nouvelle 32 n fait référence au nombre des éléments dans la structure tandis que h fait référence à la hauteur de l’arbre (profondeur maximale d’une branche)75 demande d’accès aux items. Ce processus prend en compte des formules de rafraichissement comme celles définies dans la sous-section 4.2.4. Figure'42 :'Exécution'd'un'nœud'Retrieve++ 4.3 Conclusion Dans ce chapitre, nous avons présenté les phases du processus d’exécution d’un mashup. et notre solution pour améliorer la disponibilité de données fraiches des mashups. Celle ci est à base de fonctions orthogonales au processus d’exécution des mashups. Dans une première section, nous avons décrit la représentation d’un mashup sous la forme d’un graphe dont le parcours permet de coordonner l’exécution des mashlets et des wirings du mashup. Nous avons décrit les phases des processus d’exécution des mashlets et des wirings et de leurs activités sous-jacentes.76 Dans une deuxième section, Nous avons présenté des fonctions permettant d’améliorer la disponibilité des données récupérées auprès des fournisseurs de données. Ces données sont rendues disponibles dans un !"#$%. Pour cela, nous avons décrit l’organisation du contenu du !"#$% en un ensemble d’items. Nous avons ensuite décrit la gestion de ce contenu et les fonctions qui y sont relatives : ajouter, modifier, supprimer et rechercher des items. Ensuite, nous avons décrit les fonctions de remplacement et de rafraichissement des items. Pour le remplacement des items, nous avons dressé une liste de facteurs entrant en jeu lors de la définition de la politique de remplacement dans le contexte des mashups. Le rafraichissement des items est exécuté d’une façon incrémentale. Nous avons adopté une stratégie adaptative pour la définition des durées de vie des items ainsi nous avons adapté la stratégie TTL incrémental au contexte des mashups. Enfin nous avons illustré, avec des diagrammes d’activité de la notation UML, le processus d’exécution d’un nœud Retrieve++ avec l’exploitation du Store et des fonctions associées.77 Chapitre!5 IMPLANTATION)DE)MELQART L’implantation de MELQART consiste en la séparation et l’abstraction des concepts des mashups ainsi que des gestionnaires de cache implantant les fonctionnalités proposées pour améliorer la disponibilité des données des mashups. Ceux ci sont définis avec des classes abstraites avec des signatures d’opérations (Figure 43). Cette abstraction permet de représenter l’interdépendance entre les composants en terme d’opérations fournies et utilisées par les classes. Ainsi la modification de l’implantation d’une opération n’affecte pas les classes qui l’utilisent. Les concepts des mashups sont définis par des classes abstraites et concrètes par les programmeurs de MELQART. Lors de la définition de mashups, les classes abstraites sont spécialisées par des classes concrètes. Des instances de ces classes permettent d’obtenir des mashups. Nous avons utilisé le canevas de cache ACS [62]. Il est à base de gestionnaires ; chaque gestionnaire est un composant réalisant une fonctionnalité spécifique (gestion de données, remplacement de données etc.). Dans MELQART, nous avons adapté ces gestionnaires au contexte des mashups et nous avons introduit un gestionnaire de rafraichissement. Les gestionnaires de remplacement et de rafraichissement MELQART sont spécifiés par des classes abstraites. Leurs comportements sont spécialisés par des classes concrètes. Par exemple définir des gestionnaires de remplacement, chacun ayant sa propre politique de remplacement. Des instances de ces classes permettent de faire fonctionner un cache pour stocker les données des instances de mashups. Elles sont manipulées par des administrateurs de MELQART qui peuvent contrôler le cache : augmenter sa taille, le vider, ou changer de politique de remplacement. Le chapitre est organisé comme suit : l’architecture du système est présentée dans la section 5.1. L’implantation des concepts de notre modèle de mashups et l’adaptation des gestionnaires d’ACS sont présentées dans les sections 5.2 à 5.11. L’implantation est décrite avec les diagrammes de classes et de séquence de la notation UML. Dans la section 5.12, nous avons validé notre implantation avec l’exécution de plusieurs instances de deux scenarios de mashups. Enfin, la section 5.13 conclut ce chapitre.78 Figure'43 :'Approche'de'MELQART'pour'la'création'et'l’exécution'des'mashups 5.1 Architecture)du)système L’interaction avec le système MELQART se fait selon une architecture client-serveur (cf. Figure 44). Les mashups sont exécutés côté serveur et les résultats sont affichés sur les machines des utilisateurs (clients). Ainsi, deux utilisateurs peuvent demander l’exécution d’un même mashup. Figure'44 :'Interaction'des'utilisateurs'avec'MELQART La Figure 45 présente les composants de MELQART : MashupEngine, Mashup, Mashlet, Wiring, Activity, Store, ReplacementManager et FreshnessManager. Il interagit avec des composants externes qui représentent les fournisseurs de données : Services. Un fournisseur de donnée (Service) est un composant autonome que l’on peut interroger (Invoke) par le biais des activités qu’il propose. L’exécution d’un mashup est accomplie par le spécialiser Instancier Concepts de MELQART Définitions de mashups et des gestionnaires du cache Exécution des instances des mashups et du cache Classes abstraites/concrètes Classes concrètes Objets Ac#vity( Mashup( Wiring I#neraryPlanner Classe abstraite Classe concrète Objet Mashlet( Légendes : Data( Ac#vity( Ac#vity( Item( Replacement( Manager( Freshness Manager( Store(79 composant MashupEngine. Celui ci exécute les composants Mashup, Mashlet, Wiring! et Activity33. Il contient un buffer qui offre les outils pour le stockage temporaire de données en cours de traitement. Il interagit avec les composants Services afin de les interroger et récupérer des données. Il interagit également avec le composant Store qui stocke des résultats des activités de fournisseurs de données. Dans notre implantation, les fonctions du composant MashupEngine sont assurées par le moteur d’exécution d’Eclipse (notre environnement de développement). Figure'45 :'Architecture'de'MELQART Le composant Store est un cache. Il fournit les opérations de base permettant l’ajout (bind), la suppression (unbind) et la recherche de données (lookup). Il interagit avec le gestionnaire de remplacement (ReplacementManager). Celui ci définit les données qu’il faut supprimer pour laisser de la place à des nouvelles données. Le Store interagit également avec le gestionnaire de rafraichissement (FreshnessManager) qui vise à maintenir la fraicheur des données dans le cache. Le fonctionnement des ces composants est défini en prenant en compte le caractère dynamique des données des mashups comme décrit dans le Chapitre 4. 33 Il existe différents composants activité (Filter, Extract…). Dans cette section, nous nous y référons sous le nom générique Activity80 Dans notre implantation le cache est déployé sur le serveur d’exécution des mashups. Néanmoins, il peut très bien être déployé aussi sur un autre serveur et ceci sans affecter le principe de son fonctionnement. Nous exploitons le Store pour stocker les résultats des activités proposées par des fournisseurs de données. Ceci permet d’assurer (1) leur disponibilité même en cas de défaillance d’un des fournisseurs et (2) leur partage entre différents mashlets de différents mashups, et ceci avant de les manipuler. 5.2 Valeurs)complexes Les données consommées par les mashups sont disponibles sur le web ou saisies par l’utilisateur en entrée. Les données du web sont récupérées chez des fournisseurs de données (des services web) et chacune est identifiée par un URI (Universal Resource Identifier). Les récupérations des données se font via des appels de méthodes REST. Nous adoptons la notation JSON34 pour représenter les données. En effet, les types des valeurs complexes sont compatibles avec la notation JSON35. En principe, les objets JSON peuvent représenter les valeurs complexes de type tuple. Alors que les tableaux JSON peuvent représenter les valeurs complexes de type liste ou ensemble. Ce choix n’écarte pas les données décrites sous format XML ou un autre langage de la même famille. En effet une donnée décrite sous XML peut très bien être convertie en donnée JSON et vice versa. Dans notre environnement, nous utilisons la librairie36 de référence JSON de Java pour implanter les valeurs complexes. Classe JSONObject Nous considérons la classe JSONObject37 pour implanter les données des mashups. Cette classe est offerte par la librairie de référence JSON de Java. Elle contient des méthodes qui permettent de lire les valeurs des attributs, d’ajouter et modifier des attributs. Représentation)des)valeurs)complexes)via)JSON La représentation des valeurs complexes via JSON peut être faite avec l’ensemble de règles suivantes : 1. Une valeur complexe de type tuple de la forme ! ∶ !! ∶ !! , … , !! ∶ !! est représentée par deux objets JSON imbriqués de la forme "!" ∶ "!! " ∶ !! , … ,"!!" ∶ !! . 2. Une valeur complexe de type liste de la forme ! ∶ !′ ∶ !! , … , !′ ∶ !! est représentée par un tableau d’objets JSON imbriqué lui même dans un objet JSON de la forme "!" ∶ "!′" ∶ !! , … , "!′" ∶ !! . 3. Une valeur complexe de type ensemble de la forme ! ∶ !′ ∶ !! , … , !′ ∶ !! est représentée par un tableau d’objets JSON imbriqué lui même dans un objet JSON de la forme "!" ∶ "!′" ∶ !! , … , "!′" ∶ !! . Étant donné que les valeurs JSON n’ont pas de nom associé, à l’exception des valeurs contenues dans des objets, nous utilisons un objet JSON englobant pour spécifier les noms des valeurs complexes (tuples, listes, ensembles). Bien que ce choix puisse paraître encombrant pour 34 http://www.json.org/json-fr.html 35 La syntaxe de JSON est présentée dans l’Annexe B 36 http://www.json.org/java/ 37 http://www.json.org/javadoc/org/json/JSONObject.html81 une écriture manuelle des données JSON, il ne représente pas un problème pour une implantation de données par programmation. Exemple La valeur complexe !"#$%&!%'$# ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#4", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"1", !"#$%& ∶ 3.5 , !"#$%!"#$% ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"2", !"#$%& ∶ 4.5 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4 , !"#$%!"#$% ∶ !"#$ ∶ "!"#3", !"#$%&'%() ∶ "!"#$%"&'(", !""#$%% ∶ "!"4", !"#$%& ∶ 3.3 peut être représentée avec l’objet JSON suivant : {"restaurants" : [ { "restaurant" : { "name" : "nom4", "speciality" : "italienne", "address" : "ad1", "rating" :3.5 }, { "restaurant" : { "name" : "nom1", "speciality" : "française", "address" : "ad2", "rating " :4.5 }, { "restaurant" : { "name" : "nom2", "speciality" : "libanaise", "address" : "ad3", "rating " :4 }, { "restaurant" : { "name" : "nom3", "speciality" : "japonaise", "address" : "ad4", "rating " :3.3 } ], } 5.3 Activité Les activités sont implantées en tant que classes. La classe Activity (Figure 46), est une classe abstraite : elle ne peut pas être instanciée directement. Deux associations avec la classe JSONObject spécifient qu’une instance de la classe Activity consomme une instance de la classe JSONObject en entrée (input) et en produit une autre en sortie (output) de type JSONObject. 82 Figure'46 :'Classe'Activity La classe Activity contient une méthode abstraite run(). Les classes filles spécialisent le fonctionnement de cette méthode. Celle ci définit le traitement que l’activité doit opérer pour produire la sortie. Une activité peut être basique ou composite. Une activité basique exécute une opération alors qu’une activité composite coordonne l’exécution de certaines activités qu’elles soient basiques ou composites. 5.3.1 Activités)basiques Dans notre modèle, Nous avons considéré un ensemble fini d’activités basiques pour le filtrage (Filter), l’extraction (Extract), le tri (Sort), la récupération de données (RetrievePP) et l’élimination de doublons (Unique). L’implantation de chacune de ces activités est faite avec une classe portant le même nom. Ces classes sont données dans la Figure 47. Elles étendent la classe Activity, et spécialisent le fonctionnement de la méthode run(). Elles sont abstraites et chacune possèdent des méthodes abstraites. Celles ci sont spécialisées par des classes filles qui sont définies lors de l’implantation des mashups. Dans les sous-sections suivantes, nous présentons (1) les classes de ces activités basiques, (2) comment elles spécialisent la méthode run() et (3) illustrer comment elle peuvent être étendues (définition de classes filles) pour l’implantation du mashup ItineraryPlanner. Des instances de ces classes sont présentées dans la sous-section 5.3.2 qui définit la coordination des activités (illustrant ainsi comment ces instances peuvent interagir entre elles).83 Figure'47 :'Les'classes'des'activités'basiques 5.3.1.1 RetrievePP La classe RetrievePP contient un attribut uri de type chaine de caractères, un attribut isJSON de type booléen et un attribut ttl de type entier. Elle contient également deux méthodes abstraites buildURI() et defineFormat(). Une instance de la classe RetrievePP récupère une donnée (1) du Store si celle ci s’y trouve elle y est, ou (2) du web auprès d’un fournisseur de données avec la méthode run(). La donnée récupérée est retournée en sortie. Cette donnée est identifiée par l’attribut uri. L’activité prend en entrée une donnée dont la valeur intervient dans la construction de l’URI via la méthode buildURI(). L’attribut ttl (Time To Live) de type entier, définit la durée de vie de la donnée récupérée auprès du fournisseur des données. Sa valeur est fixée par le constructeur du mashup pour chaque classe fille de la classe Retrieve. La valeur dépend de la nature des données récupérées. Le fonctionnement de la méthode run() est décrit dans la soussection 5.11 décrivant l’interaction entre les mashups et le Store. La méthode defineFormat() définit la valeur de l’attribut isJSON. Celui ci indique si la donnée récupérée est sous format JSON (isJSON = true) ou sous format XML (isJSON = false). Dans ce dernier la méthode run() convertit la donnée dans un format JSON. Les classes filles spécialisent le fonctionnement des méthodes buildURI() et defineFormat(). Par exemple, lors de l’implantation du mashup ItineraryPlanner, le constructeur définit une classe concrète RouteRetrieve qui étend la classe Retrieve. Cette classe spécialise le fonctionnement des deux méthodes. buildURI() définit l’URI pour la récupération de l’itinéraire entre deux villes alors que defineFormat() indique que la donnée récupérée est sous format JSON. Le fonctionnement de ces méthodes est le suivant : 84 void buildURI() { depart = input.departure ; destination = input.destination ; this.uri = "http://maps.googleapis.com/maps/api/directions/json?origin="+departure+"&des tination="+destination+"&sensor=false" ; } void defineFormat () { this.isJSON = true ; } 5.3.1.2 Filter La classe Filter contient les méthodes abstraites check(JSONObject value) et extractArray(). Une instance de la classe Filter prend en entrée une instance de JSONObject contenant un tableau d’objets JSON. Celui ci est extrait avec la méthode extractArray(). La méthode run() retourne le tableau des objets qui vérifient une certaine condition. La vérification de la condition est exécutée par la méthode check(JSONObject value). Elle se fait, éventuellement, par rapport à des valeurs contenues dans l’entrée de l’activité. La méthode run() est décrite dans le pseudo-code suivant : void run() { JSONArray valuesArray = this.extractArray() ; JSONArray resultArray; for (int i=1 ; i< valuesArray.length() ; i++) { value = valuesArray[i] ; if (check(value)) then resultArray.put(value) ; } JSONObject output = {“result” : resultArray} ; this.output = output ; } Les classes filles spécialisent le fonctionnement des méthodes extractArray() et check(). Par exemple, lors de la définition du mashup ItineraryPlanner, le constructeur définit une classe concrète RestaurantFilter. L’entrée de l’activité contient la liste de restaurants sous la forme d’un tableau JSON et la note minimale pour les restaurants recherchés (“ratingMin”) Les méthodes extractArray() et check() sont décrites avec le pseudo-code suivant : JSONArray extractArray() { JSONArray valuesArray = this.input.getJSONArray(“restaurants”) ; return valuesArray ; } Boolean check(JSONObject value) { If (value.getInt((“rating”) >= this.input.getInt(“ratingMin”)) then return true ; else return false ; } 85 5.3.1.3 Unique La classe Unique contient les méthodes abstraites extractValue(JSONObject o) et extractArray(). Une instance de la classe Unique prend en entrée une instance de JSONObject contenant un tableau d’objets JSON. Celui ci est extrait avec la méthode extractArray(). La méthode run() élimine les doublons parmi les objets de ce tableau. L’élimination des doublons se fait selon des valeurs contenues dans les objets et désignées par un même chemin d’accès. La méthode extractValue (JSONObject o) retourne la valeur contenue dans l’objet o sous la forme d’une chaine de caractère. La méthode run() est décrite dans le pseudo-code suivant : void run() { JSONArray objectArray = this.extractArray() ; JSONArray resultArray; String[] objKeys for (int i=1 ; i< objectArray.length() ; i++) { obj = objectArray [i] ; if ( ! objKeys.contains(extractValue(obj))) then resultArray.put(obj) ; } JSONObject output = {“result” : resultArray} ; this.output = output ; } Les classes filles spécialisent le fonctionnement des méthodes extractArray() et extractValue(JSONObject o). Par exemple dans le mashup ItineraryPlanner, la liste de villes (sous format WOEID) de passage entre les villes de départ et de destinations contient des doublons qu’il faut éliminer. Pour cela, le constructeur définit une classe concrète UniqueWOEID qui étend la classe Unique. Le fonctionnement des méthodes extractArray() et extractValue(JSONObject o) de cette classe est décrit avec les pseudo-codes suivants : JSONArray extractArray() { JSONArray valuesArray = this.input.getJSONArray(“result”) ; return valuesArray ; } String extractValue(JSONObject o) { int woeid = o.getInt(“woeid”) ; return String(woeid) ; } 5.3.1.4 Extract La classe Extract contient la méthode abstraite path(). Une instance de la classe Extract prend en entrée une ressource, et retourne dans un objet JSON la valeur indiquée par la méthode path(). La méthode run() est décrite dans le pseudo-code suivant : void run() { this.output = this.path() } 86 Les classes filles spécialisent le fonctionnement de la méthode path(). Par exemple, lors de l’implantation du mashup ItineraryPlanner, le constructeur du mashup définit une classe concrète StepsExtractor qui étend la classe Extract. La méthode path(), de cette classe, extrait les étapes de l’itinéraire. Elle est décrite avec le pseudo-code suivant : JSONObject path() { JSONArray steps = this.input.getJSONArray("routes").getJSONObject(0). getJSONArray("legs").getJSONObject(0).getJSONArray("steps") return {"steps" : steps} ; } 5.3.1.5 Sort La classe Sort contient un attribut ascending de type booléen et les méthodes abstraites extractArray() et compare(JSONObject o1, JSONObject o2). Une instance de la classe Sort prend en entrée une ressource contenant un tableau d’objets JSON. Celui ci est extrait avec la méthode extractArray(). La méthode run() trie les objets que le tableau contient. Le tri se fait selon une relation d’ordre définie par la méthode compare() qui défini la relation d’ordre entre deux objets. Le tri des objets peut être ascendant ou descendant selon la valeur de l’attribut ascending. Les classes filles spécialisent le fonctionnement des méthodes extractArray et compare. La méthode run() est décrite par le pseudo-code suivant : void run() { JSONArray objectArray = this.extractArray() ; JSONArray resultArray; resultArray = sort(objectArray) ;38 } 5.3.2 Activités)composites Les classes des activités composites sont données dans la Figure 48. Elles étendent la classe Activity, et spécialisent le fonctionnement de la méthode run(). Dans les sous-sections suivantes, nous présentons les classes permettant de décrire des activités composites, et comment elles spécialisent la méthode run(). Nous présentons également des classes concrètes définies lors la phase de l’implantation du mashup ItineraryPlanner. Ensuite nous allons montrer comment des instances de ces classes interagissent entre elles. 38 Nous considérons que la méthode sort(JSONArray a) implante un des algorithmes de tri proposés dans l’état de l’art [97]. 87 Figure'48 :'Les'classes'des'activités'composites 5.3.2.1 Sequence La classe Sequence est une clase concrète en association avec la classe Activity. Cette association indique qu’une instance de la classe Sequence contient un ensemble ordonné d’activités appelées sous-activités (Sub-activities). L’exécution d’une instance iseq (Figure 49) de la classe Sequence (ayant deux sousactivités) lance l’exécution des sous-activités séquentiellement. Chacune des sous-activités transmet sa sortie à la sous-activité suivante. La dernière sous–activité transmet sa sortie à la sortie de iseq. La méthode run() de l’activité Sequence correspond donc au pseudo-code suivant : run() { Activity a = this.sub-activities[0] ; a.input = this.input ; a.run() ; for (int i=1 ; i ready ; this.setMashletsInputs() ; //ajouter les mashlets, prêts à l’exécution, à ready ready = prepareMashup() ; while (not ready.empty()){ object o = ready.pop() ; if type(o) = Mashlet { o.run() ; foreach w in o.wiringAfter do { notify (w) ; ready.put(w) ; } } else {// o est de type Wiring o.run() ; Mashlet m = o.receiver ; notify (m) ; ready.put(m) ; } } 96 5.7 Item La classe Item est présentée dans la Figure 58. Elle contient les attributs uri de type chaine de caractère, result de type JSONObject et des attributs donnant des informations statistiques : Figure'58 :'Classe Item • accessNb de type entier, il indique le nombre d’accès à l’item. • ttl de type entier, il indique la durée de vie de l’item. • birthDate de type Date, il indique la date de création de l’item. • expireOn de type Date, il indique la date d’expiration de l’item. • lastAccess de type Date, indique la date du dernier accès à l’item. La classe contient également trois méthodes : la première refresh() permet de rafraichir la valeur de l’attribut result en récupérant les données depuis le fournisseur via la valeur de l’attribut uri. Alors que la seconde adjustTTL(ttl : Integer) permet de modifier la durée de vie ttl d’un item au sein du cache. Enfin, la méthode isExpired() indique si la donnée enregistrée dans l’attribut result est périmée ou pas. La Figure 59 montre un exemple d’une instance de la classe. Elle correspond au document JSON routeGP défini dans l’Annexe B et récupéré avec l’uri uriGP où : uriGP = "http://maps.googleapis.com/maps/api/directions/json?origin="+departure+"&des tination="+destination+"&sensor=false" Figure'59 :'Instance'de'la'classe'Item :Item% accessNb = 8 birthDate = 1-11-12 ttl = 30 days expireOn = 30-1-13 lastAcess = 30-11-12 result = routeGP uri = uriGP 97 5.8 Store Les fonctionnalités de gestion des items sont définies dans la classe Store (Figure 60). Celle ci est en association avec la classe Item. Cette association indique qu’une instance de la classe Store contient un ensemble d’items. Elle contient un attribut length de type entier définissant la capacité du !"#$%. La classe Store contient aussi les méthodes lookup(uri : String), bind(uri : String, result : JSONObject, ttl : Integer) et unbind(uri : String). • La méthode lookup(uri : String) permet de vérifier l’existence d’un item, ayant l’identifiant uri, au sein du Store. Le résultat de cette méthode est l’item correspondant, s’il est présent, ou null sinon. Si l’item est périmé, la méthode demande au gestionnaire de rafraichissement de le rafraichir avant de le retourner. • La méthode bind(uri : String, result : JSONObject, ttl : Integer) permet de construire un item ayant l’identifiant uri, la donnée result et une durée de vie ttl. Et elle ajoute cet item au Store. • La méthode unbind(uri : String) permet de supprimer du Store l’item dont l’identifiant possède la valeur de uri. Figure'60 :'Classe'Store La classe Store est spécifiée avec un patron de conception41 singleton : c’est à dire que son instanciation est restreinte à un seul objet. En effet, dans notre architecture, il y a un seul cache pour stocker les données provenant des services de données. Lors de la poursuite de ces travaux pour les étendre aux caches distribués pour les mashups, le patron de conception singleton sera écarté. Pour s’assurer de l’unicité de l’instance, dans la représentation de diagramme de classes dans la notation UML, les constructeurs de la classe sont définis avec une visibilité privée. Pour permettre l’accès à l’instance unique on crée une méthode getInstance() qui permet de la créer, si elle n’existe pas encore, et de la retourner. 5.9 ReplacementManager La classe ReplacementManager est présentée dans la Figure 61. Elle implante les méthodes de l’interface ReplacementManager de ACS. Comme dans des implantations fournies 41 Un patron de conception (design pattern) est la description d’un problème logiciel et des éléments d’une solution à ce problème [98]98 dans ACS, La méthode addForReplacement ajoute une référence à l’item dans une liste ordonnée gérant les items éligibles lors d’un remplacement. L’ordre des éléments est défini selon les poids des items42. Les deux méthodes addForReplacement et adjustForReplacement réalisent des actions pour mettre à jour le poids de l’item utilisé par la politique de remplacement. La classe ReplacementManager est abstraite : elle contient une méthode abstraite itemWeight(Item e). Celle ci est spécialisée par des classes filles. Son objectif est de définir le poids de l’item. Lors de l’éviction des données, les items, dont les poids sont les moins élevés, seront supprimées. Les coefficients de la formule de poids sont définis comme des attributs des classes filles et sont modifiables avec des méthodes setter. La possibilité de modifier ces attributs donne au gestionnaire une caractéristique d’adaptabilité. La classe ReplacementManager est en association avec la classe Store. Cette association indique que l’instance unique de Store possède une instance de ReplacementManager pour gérer la politique de remplacement dans MELQART. Figure'61 :'La'classe'ReplacementManager 5.10 FreshnessManager La Figure 62 présente la classe FreshnessManager. Elle possède les attributs refreshFresq, ttlMin, ttlMax et itemsRefs et les méthodes run(), addForFreshness(), removeForFreshness() et les méthodes abstraites defineRefreshFreq(), increment() et decrement(). 42 Dans l’implantation des classes d’ACS, les items (entrées de cache) sont ordonnés selon une donnée temporelle.99 Figure'62 :'La'classe'FreshnessManager La classe FreshnessManager est en association avec la classe Store qui précise que l’instance unique de Store possède une instance de FreshnessManager pour gérer le rafraichissement des items. La méthode defineRefreshFreq est une méthode abstraite. Elle est spécialisée par des classes filles de la classe FreshnessManager. Elle définit la valeur de l’attribut refreshFreq. Celui ci indique la fréquence d’exécution de la méthode run(). Tandis que l’attribut itemsRefs est de type arbre rouge et noir. Les attributs ttlMin et ttlMax définissent les valeurs minimales et maximales que peuvent avoir les durées de vies des items !!"# et !!"#. Les méthodes increment et decrement sont des méthodes abstraites. Elles sont spécialisées par des classes filles de la classe FreshnessManager. Elles définissent les valeurs à ajouter à (ou à retirer de la valeur de TTL d’un item. Elles prennent en paramètres : la valeur de TTL, le nombre d’accès à l’item et la date du dernier accès à l’entrés. Par exemple, une classe fille de FreshnessManager peut implanter les méthodes increment et decrement selon les formules définies dans les sous-sections 4.2.4.2(a) et 4.2.4.2(b). Les paramètres !, !, ! !" ! sont alors définis dans des attributs. Ils sont modifiables par des méthodes setter. La méthode addForFreshness est appelée par le Store pour signaler au gestionnaire de rafraichissement l’ajout d’un nouvel item au Store (par le biais de la méthode bind). Une référence à cet item est ajoutée dans itemsRefs. La méthode removeForFreshness prend en comme paramètre un identifiant d’un item. Elle est invoquée par le Store pour signaler au gestionnaire de rafraichissement la suppression de l’item correspondant depuis le Store (par le biais de la méthode unbind). La référence correspondante est supprimée depuis itemsRefs. La méthode processItem prend en paramètres un item dont la durée de vie est expirée. Elle exécute le processus de rafraichissement selon la stratégie TTL incrémental définie dans la sous-section 4.2.4.2. La méthode run() parcourt les premiers éléments de la liste ordonnée itemsRefs et les met à jour. Elle est lancée périodiquement, selon la valeur de l’attribut refreshFreq. Elle fonctionne selon le pseudo code suivant : 100 run() { int i = 0 ; Item it= itemsRefs[i].getItem() ; while (it.isExpired() == true) { processItem(it) ; i++ ; it= itemsRefs[i].getItem ; } } 5.11 Interaction)des)mashups)avec)le)Store L’interaction entre les mashups et le Store se déroule au niveau des activités de type RetrievePP. La méthode run() fait appel aux méthodes de la classe Store. L’exécution de la méthode est illustrée dans le diagramme de séquence de la Figure 63. Elle commence par construire l’uri, et vérifier si le Store contient un item ayant un identifiant la valeur de l’attribut uri (avec la méthode lookup(uri)) et si oui, Elle retourne le résultat stocké dans le Store. Sinon, elle récupère les données auprès du fournisseur, les convertit en format JSON si nécessaire et les stocke dans le Store (bind(uri, result, ttl)). Nous rappelons que la méthode lookup vérifie l’état de l’item avant de la retourner : si elle est déjà périmée, la méthode demande au gestionnaire de rafraichissement de rafraichir l’item (avec la méthode processItem()). La méthode run() de la classe RetrievePP est décrite avec le pseudo-code suivant void run() { this.buildURI() ; Store st= Store.getInstance() ; Item it = st.lookup(this.uri) ; if (it != null) { this.output = it.getResult(); } else { String data= getData(uri) ; // conversion du résultat en JSON if ( this.isJSON()){ this.output = new JSONObject(data) } else { this.output = XML.toJSONObject(data) } st.bind(this.uri, this.output, this.ttl) ; } } 101 Figure'63 :'Exécution'de'la'méthode'run()'de'l'activité'Retrieve'avec'utilisation'du'Store 5.12 Validation Cette section présente la validation de notre contribution. Elle a pour objectif de démontrer que les fonctionnalités que nous avons proposées et implantées avec un cache adapté au contexte des mashups répondent au problème de la non disponibilité de données dans les mashups. Nous avons implanté un prototype de MELQART avec le langage Java dans un environnement Eclipse43 . Le cache de données de mashups storeM est implanté en tant qu’une instance de la classe Store. Il associée à toutes les instances de mashups avec une taille de 1000 items (dans ACS, le prototype de cache est implanté avec un gestionnaire de taille de cache basé 43 http://www.eclipse.org/ 102 sur le nombre des items). Nous avons associé à storeM des gestionnaires de remplacement et de rafraichissement rm et fm exécutant les politiques données en exemple dans le Chapitre 4. La fréquence de rafraichissement est fixée à deux heures. Nous soulignons que l’objectif de cette validation n’est pas de démontrer que telle politique (de remplacement ou de rafraichissement) est meilleure qu’une autre ou de trouver la meilleur politique (de remplacement ou de rafraichissement). Pour valider notre implantation, nous avons défini deux scenarios de mashups ItineraryPlanner (sous-section 5.12.1) et MyDashboard (sous-section 5.12.2). L’exécution de plusieurs instances de ces mashups pour valider notre approche et notre implantation. Nous ne nous sommes pas intéressé à la visualisation des données. En effet, la visualisation ne constitue pas un aspect nécessaire de la validation de notre approche pour améliorer la disponibilité de données dans les mashups. Les données des mashlets sont présentées sous la forme d’objets JSON dans des widgets. 5.12.1ItineraryPlanner Nous avons implanté le mashup ItineraryPlanner avec les mashlets Map et Weather. Ce mashup a servi de scenario pour illustrer notre approche. Son fonctionnement fut décrit tout au long de ce document. Le corps de la méthode defineMashupComponents() de la classe ItineraryPlanner et définissant la logique applicative du mashup est présenté dans le code JAVA commenté suivant : public void defineMashupComponents() { ////Mashlet Map RetrievePP rt = new RouteRetrieve(); Mashlet map = new Mashlet("map",rt); this.addMashlet(map.getName(),map); ////Mashlet Weather WeatherRetrieve wr = new WeatherRetrieve(); WeatherExtractor extractWeatherAct = new WeatherExtractor(); // Sequence Sequence weatherSeq = new Sequence(); weatherSeq.addActivity(wr); weatherSeq.addActivity(extractWeatherAct); // Foreach CitiesWeatherForeach itpWeatherForeach = new CitiesWeatherForeach(); itpWeatherForeach.setSubActivity(weatherSeq); Mashlet weather = new Mashlet("weather", itpWeatherForeach); this.addMashlet(weather.getName(),weather); ////Wiring Map2Wiring //extraction des villes de passage StepsExtractor stepsExtO = new StepsExtractor(); // conversion au format WOEID RetrieveWOEIDPlace rw = new RetrieveWOEIDPlace(); WoeidPlaceExtractor woeidExtractorAct = new WoeidPlaceExtractor(); Sequence woeidSeq = new Sequence(); woeidSeq.addActivity(rw); woeidSeq.addActivity(woeidExtractorAct); CitiesListForeach citiesListForeachAct = new CitiesListForeach(); citiesListForeachAct.setSubActivity(woeidSeq); // élimination des doublons WOEID UniqueWOEID uniqueWOEIDAct = new UniqueWOEID(); // mise en séquence Sequence stepsSeq = new Sequence();103 stepsSeq.addActivity(stepsExtO); stepsSeq.addActivity(citiesListForeachAct); stepsSeq.addActivity(uniqueWOEIDAct); Wiring map2weather = new Wiring("map2weather", map,weather, stepsSeq); this.addWiring(map2weather.getName(), map2weather); } La Figure 64 présente les résultats du mashup pour un itinéraire allant de Grenoble jusqu’à Paris. Figure'64 :'Résultats'du'mashup'ItinerayPlanner'pour l’itinéraire'de'Grenoble'à'Paris Le mashup a deux entrées : la ville de départ et la ville d’arrivées. Toutes les deux sont de type chaine de caractères. Les données, du mashlet maps, proviennent du service Google maps44 . Alors que les données du mashlet weather proviennent du service Yahoo! Weather45. Un mapping est nécessaire pour transformer les descriptions des villes de passage du format (longitude, latitude) au format WOEID. Ce mapping est fait via le service Yahoo! BOSS Geo Services46. Le Tableau 6 donne les durées de vie que nous avons estimées pour les données récupérées de chaque service. Fournisseur des données Durée de vie des données Google maps 30 jours Yahoo! Weather 5 heures Yahoo! Boss 60 jours Tableau'6':'Durées'des'vies'des'données'du'mashup'ItineraryPlanner 44 https://developers.google.com/maps/documentation/directions/ 45 http://developer.yahoo.com/weather/ 46 http://developer.yahoo.com/boss/geo/104 5.12.2MyDashboard Le deuxième mashup est nommé MyDashboard. Il contient deux mashlets. Un mashlet « Weather » qui donne la météo pour une ville saisie par l’utilisateur et un Mashlet « Programmes TV » qui affichent les programmes TV de différentes chaines de la soirée. Le corps de la méthode defineMashupComponents() de la classe MyDashboard et définissant la logique applicative du mashup définissant son implantation est présenté dans le code JAVA commenté suivant : public void defineMashupComponents() { ////Mashlet Weahter RetrieveWOEIDPlace rwc = new RetrieveWOEIDPlace(); WoeidPlaceExtractor ewc = new WoeidPlaceExtractor(); WeatherRetrieve wr = new WeatherRetrieve(); Sequence ws = new Sequence(); ws.addActivity(rwc); ws.addActivity(ewc); ws.addActivity(wr); Mashlet weather = new Mashlet("weather",ws); this.addMashlet(weather.getName(),weather); ////Mashlet TV TVProgRetrieve tvp = new TVProgRetrieve(); Mashlet myprg = new Mashlet("myprg",tvp); this.addMashlet(myprg.getName(),myprg); } La Figure 64 présente les résultats du mashup MyDashboard avec Grenoble comme paramètre en entrée. Figure'65 :'Résultats'du'mashup'MyDashboard'avec'Grenoble'comme'paramètre'en'entrée. Le mashup possède une seule entrée : la ville de l’utilisateur de type chaine de caractères. Les données du mashlet « Programmes TV » proviennent d’un flux RSS47. Alors que les données du 47 http://feeds.feedburner.com/programme-television105 mashlet « Weather » proviennent du service Yahoo! Weather. Un mapping est nécessaire pour transformer la description de la ville de l’utilisateur du format « nom de ville » au format WOEID. Ce mapping est fait via le service Yahoo! GeoPlanet48. Le Tableau 7 donne les durées de vie que nous avons estimées pour les données récupérées de chaque service. Fournisseur des données Durée de vie des données Flux TV 1 jour Yahoo! Weather 5 heures Yahoo! GeoPlanet 60 jours Tableau'7':'Durées'des'vies'des'données'du'mashup'MyDashboard 5.12.3Execution)des)instances)des)mashups Nous avons crée plusieurs instances des mashups ItineraryPlanner et MyDashboard, que nous avons lancées avec plusieurs valeurs en paramètres d’entrée (cf. Figure 66). Les exécutions se sont terminées correctement et ont retourné les résultats attendus. Par injection d’impressions de traces dans le code, nous avons pu observer la gestion des données des mashups. Les données produites par les activités de type RetrievePP sont bien stockées dans le Store. Ces données sont récupérées directement du Store, lors d’une exécution ultérieure des mêmes activités avec les mêmes valeurs de paramètres d’entrées. Ceci fut observé également avec la rapidité d’exécution des mashups et l’obtention rapide des résultats. En plus, ce qui est le plus important est le fait de pouvoir accéder aux données du Store pour exécuter des instances de mashups même en cas de rupture de communication avec les fournisseurs de données (simulée par une déconnexion de la machine du réseau) ce qui valide notre approche implantée avec un cache pour garantir la disponibilité des données dans les mashups. Le gestionnaire de remplacement évinçait les items jugés les moins importantes par la politique de remplacement choisie. Le gestionnaire de rafraichissement s’est lancé périodiquement pour vérifier l’état de validités des items. Ainsi, les items, correspondant aux données provenant du service Yahoo! Weather, furent mises à jour pendant la journée de test. En plus, lorsque nous avons lancé le mashup ItineraryPlanner, à un moment où les données météorologiques étaient périmées dans le Store (avant le déclenchement du processus périodique de rafraichissement), le Store demandait au gestionnaire de rafraichissement de rafraichir les items avant de les retourner. 5.13 Conclusion Ce chapitre a présenté l’implantation d’un prototype de MELQART notre système d’exécution de mashups avec disponibilité de données. L’architecture du système fut présentée en premier. Ensuite, nous avons présenté l’implantation des concepts de mashups et des fonctionnalités proposées pour améliorer la disponibilité de données. Pour implanter ces fonctionnalités, Nous avons adapté des gestionnaires d’ACS au contexte des mashups et nous avons introduit le gestionnaire de rafraichissement. La validation de notre implantation nous a montré que les dites fonctionnalités implantées via un cache constituent une solution crédible pour garantir la disponibilité de données dans les mashups. 48 http://developer.yahoo.com/geo/geoplanet/guide/index.html 106 Figure'66 :'Chronologie'des'exécutions t0 • Exécu&on)d’I&neraryPlanner) entre)Grenoble)et)Paris.)) • Récupéra&on)de)données) depuis)les)fournisseurs) t1 • Exécu&on)d’I&neraryPlanner) entre)Grenoble)et)Paris.)) • Récupéra&on)de)données) depuis)le)Store) • Exécu&on)de)MyDashboard) avec)Grenoble)comme)ville.)) • Récupéra&on)des)données) météorologiques)depuis)le) Store) t2 t0+2h • Les)données)météo) récupérées)lors)de)la) première)exécu&on) sont)périmées) • Exécu&ons)successives)des) instances)des)mashups)avec) différentes)entrées,)avec) interrup&on)de)connexion) t0+4h t0+5h • Lancement)du)processus)de) rafraichissement) • Rien)à)rafraichir) t0+5h10 t0+6h • Exécu&on)d’I&neraryPlanner) entre)Grenoble)et)Paris.)) • Récupéra&on)des)données)de) l’i&néraire)depuis)le)Store.) • Récupéra&on)des)données) météorologiques)depuis)le) fournisseur)) • Rafraichissement)des)données) et)adapta&on)de)la)durée)de)vie) des)données)météorologiques) • Exécu&ons)successives)des) instances)des)mashups.) • Le)processus)de)remplacement) se)déclenchait)afin)de)libérer)de) l’espace)dans)le)Store • Lancement)du)processus)de) rafraichissement) • Rafraichissement)des) données)météorologiques) récupérées)entre)t0)et)t0+1h)107 Chapitre!6 CONCLUSION L’objectif de ce travail était d’améliorer la disponibilité de données fraiches dans les mashups. Nous avons proposé MELQART : un système d’exécution de mashups avec une solution pour améliorer la disponibilité et la fraicheur de données des mashups. Dans la suite nous soulignons nos contributions et les perspectives de notre travail. 6.1 Contribution)et)bilan La première contribution de ce travail est un état de l’art sur les modèles des mashups, les systèmes d’exécution de mashups et leurs architectures ainsi que la disponibilité de données fraiches sur le web. Nous avons observé qu’il y a peu de travaux qui proposent des modèles de mashups et que ceux qui existent ne sont pas suffisamment riches pour spécifier les caractéristiques de la disponibilité de données. Nous avons également constaté que les techniques actuelles de disponibilité de données ne sont pas adaptées à des applications comme les mashups. Enfin, parmi le peu de travaux qui se sont intéressés à la disponibilité des données des mashups, le problème de la fraicheur des données disponibles n’est pas abordé. Nous avons en conséquence proposé MELQART : un système d’exécution de mashups avec une solution pour améliorer la disponibilité et la fraicheur de données des mashups. Cette solution propose des fonctionnalités orthogonales au processus d’exécution de mashups pour améliorer la disponibilité de données récupérées auprès des fournisseurs de données. Dans la suite de cette section, nous présentons nos conclusions au regard de nos contributions dans le cadre de MELQART. Nous avons défini un modèle de description de mashups basé sur les valeurs complexes. Des activités basiques décrivent la manipulation des données de mashups (le filtrage, la projection, l’extraction, l’élimination de doublons, le tri, l’union et l’annexe). Ces activités sont coordonnées par des activités composites (Séquence, Foreach, Parallel). Le modèle peut être enrichi avec d’autres activités dans le futur selon les besoins qui peuvent apparaître. Elles sont utilisées par des mashlet et des wirings. Les mashlets affichent des données produites par les activités tandis que les wirings coordonnent l’exécution des mashlets. Dans notre modèle, les wirings ne décrivent pas qu’un transfert de données entre mashlets comme c’est le cas dans les modèles existants. Ils peuvent aussi, décrire le traitement des données pour les délivrer sous le bon format aux mashlets destinataires. Notre modèle permet également de spécifier les caractéristiques de la disponibilité et de la fraicheur de données. 108 Nous avons présenté les phases du processus d’exécution d’un mashup et notre solution pour améliorer la disponibilité de données fraiches des mashups. Celle ci est à base de fonctions orthogonales au processus d’exécution des mashups. Ce processus est basé sur la représentation d’un mashup sous la forme d’un graphe dont le parcours permet de coordonner l’exécution des mashlets et des wirings du mashup. Nous avons décrit les phases des processus d’exécution des mashlets et des wirings et de leurs activités sous-jacentes. Des fonctionnalités permettant l’améliorer la disponibilité des données récupérées auprès des fournisseurs de données et d’assurer leur fraicheur. Les données sont rendues disponibles dans un !"#$%. Pour cela, nous avons décrit l’organisation du contenu du !"#$% en un ensemble d’items. Nous avons ensuite décrit la gestion de ce contenu et les fonctions qui y sont relatives : ajouter, modifier, supprimer et rechercher des items. Ensuite, nous avons décrit les fonctions de remplacement et de rafraichissement des items. Pour le remplacement des items, nous avons dressé une liste de facteurs entrant en jeu lors de la définition de la politique de remplacement dans le contexte des mashups. Le rafraichissement des items est exécuté d’une façon incrémentale. Nous avons adopté une stratégie adaptative pour la définition des durées de vie des items ainsi nous avons adapté la stratégie TTL incrémental au contexte des mashups. Nous avons implanté les concepts de mashups et les fonctionnalités proposées pour améliorer la disponibilité de données. Pour implanter ces fonctionnalités, Nous avons adapté des gestionnaires d’ACS au contexte des mashups et nous y avons introduit le gestionnaire de rafraichissement. La validation de notre implantation, via des tests sur l’exécution de deux scénarios de mashups, nous a montré que les dites fonctionnalités implantées via un cache constituent une solution crédible pour garantir la disponibilité de données dans les mashups. 6.2 Perspectives Les travaux réalisés dans cette thèse ne sont que le premier pas vers la définition d’un environnement pour la construction et l’exécution de mashups. Des nouveaux défis et améliorations doivent être traités. Les points qui nous apparaissent intéressants pour la suite sont : • Définir un langage déclaratif permettant à un utilisateur final de définir son mashup. Ce langage peut être aussi bien textuel que graphique. Ceci constitue une amélioration apportée à MELQART en vue d’une évolution vers un environnement de définition et d’exécution de mashups. Actuellement, la définition d’un langage de mashups fait partie des projets RedShine49 et Clever50 . • Considérer le cas de figure où les données du !"#$% sont périmées et qu’il est impossible de les rafraichir (dans le cas de rupture de connexion avec le fournisseur de données correspondant). Ceci implique la mise en œuvre d’un traitement d’exceptions et des actions pour palier ces exceptions en assurant un fonctionnement du mashup même détérioré. Une solution possible peut inclure la recherche d’un autre fournisseur de données offrant des données contenant l’information recherchée. Ceci nécessite la mise en place d’un processus de mapping de données pour récupérer des données décrites selon le même format. Ce travail a été démarré dans le cadre des projets Clever et e-Cloudss51 et dans un des scénarios de validation de la thèse de Javier Espinosa [99]. Ils implantent des stratégies simples de rafraîchissement. Ils doivent évoluer pour prendre en considération des stratégies adaptatives, modifiables et tenant compte des besoins de l’utilisateur. 49 http://red-shine.imag.fr/ 50 http://clever.imag.fr 51 http://e-cloudss.imag.fr/109 • Mettre en cache les résultats de certaines activités intermédiaires dans un arbre d’activités. Toutefois, pour cela, il faut prendre en considération plusieurs facteurs pour choisir l’activité ; comme le nombre d’exécutions (cette différence entre activités d’un arbre provient de la possibilité de qu’une activité peut faire partie de deux arbres ou plus), l’espace restant dans le !"#$% etc. • Mettre des données en cache sur la machine du client. Le cache, en question, pourrait être utilisé pour stocker les données des mashlets d’un mashup. Ces données sont produites sur le serveur de MELQART et envoyées à l’utilisateur. Cacher ces données permet d’assurer leur disponibilité même en cas d’une déconnexion de la machine du client. • Considérer le cas des données récupérées avec un mécanisme de pagination ou les données récupérées en continue sous la forme d’un flux. Dans ce cas Comment réorganiser le !"#$% ? Comment le gérer ? Et Comment réadapter les fonctionnalités de disponibilités de données ? • Étudier et procéder à l’amélioration d’autres qualités de services QoS. Il existe déjà des travaux comme [100][101] qui ont traité le problème de la confidentialité des données (data privacy). D’autres propriétés QoS pour la gestion des mashups et des données ont été identifiées dans [67][102][103][33][104]. Parmi ces propriétés, nous retrouvons, la sécurité des données (data security), la précision des données (data accuracy) et l’utilisabilité de la présentation (presentation usability). o La sécurité réfère aux stratégies qui assurent la sureté d’un mashup et de ses données. Comment s’assurer de l’intégrité des données : le fait que les données ne subissent aucune altération ou déformation lors du transfert des données entre les fournisseurs et le mashup ? Comment gérer les données confidentielles dans une application où les données sont mélangées ? o La précisons des données réfère à l'exactitude et la cohérence des données du mashup par rapport au monde. La précision est mesurée comme la proximité des données récupérées aux données correctes (dans le monde réelle). La précision des données d’un mashup dépend de la précision des fournisseurs de données. Dans [67], la précision des données est exprimée comme étant la probabilité que les donnés soient correctes : ! !"" = 1 − !(!"") Où !(!"") est la probabilité qu’une erreur se produise. L’erreur de précision peut se produire pour différentes raisons, telles que les fautes de frappe, la représentation erronée ou mises à jour manquantes. Comment un système d’exécution de mashups peut vérifier l’exactitude des données récupérées ? Comment détecter si un service de données n’est plus maintenu à jour par ses propriétaires ? Et comment réagir dans ce cas ? o L’utilisabilité de la présentation est une propriété qui caractérise l’expérience de l’utilisateur. Les mêmes attributs de l’utilisabilité de présentation, définis pour les pages web [105][106], peuvent être pris en compte pour l’utilisabilité de la présentation des mashups. En particulier la compréhension du fonctionnement (learnability) et la compréhension du contenu (understandability) et l’attractivité de la présentation (attractiveness). Dans le cas des mashups, est ce qu’il faut revoir ces attributs ? Quelles stratégies faut il mettre en place pour aider le constructeur de mashups à construire des mashups respectant ces attributs ? • Etudier la prise en compte des préférences de l’utilisateur. Dans [107], les auteurs proposent un système de mashups avec la prise en compte des préférences de l’utilisateur liées aux informations qu’il recherche (par exemple : préférer le moins cher etc.). Nous pensons qu’il faut également développer une étude sur les préférences de l’utilisateur en matière de qualités de service du mashup comme la sécurité, la fraicheur, la précision des données. • Étudier la répartition de la charge de l’exécution des mashups entre le serveur de MELQART et sur la machine de l’utilisateur. Comment repartir les tâches ? Et dans ce cas, la machine du client peut être faible en ressources (capacité de calcul mémoire, énergie), ainsi il faut mettre une place une stratégie d’optimisation d’exécution des mashups. Cette stratégie doit prendre en 110 considération l’ordre des exécutions des activités et le choix des algorithmes pour l’exécution des opérations de manipulation de données.111 BIBLIOGRAPHIE [1] D. Merrill, “Mashups: The new breed of Web app,” IBM Corporation, CT316, Aug. 2006. [2] F. Belleau, M.-A. Nolin, N. Tourigny, P. Rigault, and J. Morissette, “Bio2RDF: Towards a mashup to build bioinformatics knowledge systems,” Journal of Biomedical Informatics, vol. 41, no. 5, pp. 706–716, Oct. 2008. [3] S. Abiteboul, O. Greenshpan, and T. Milo, “Modeling the mashup space,” in Proceeding of the 10th ACM workshop on Web information and data management, Napa Valley, California, USA, 2008, pp. 87–94. [4] Ke Xu, Meina Song, and Xiaoqi Zhang, “Home Appliance Mashup System Based on Web Service,” in Service Sciences (ICSS), 2010 International Conference on, 2010, pp. 94–98. [5] C. Safran, D. Helic, and C. Gütl, “E-Learning practices and Web 2.0,” presented at the Proc. of the 10th International Conference of Interactive computer aided learning (ICL 2007), Villach Austria, 2007. [6] M. Eisenstadt, “Does Elearning Have To Be So Awful? (Time to Mashup or Shutup),” in Advanced Learning Technologies, 2007. ICALT 2007. Seventh IEEE International Conference on, 2007, pp. 6 –10. [7] N. Schuster, C. Zirpins, M. Schwuchow, S. Battle, and S. Tai, “The MoSaiC model and architecture for service-oriented enterprise document mashups,” in Proceedings of the 3rd and 4th International Workshop on Web APIs and Services Mashups, New York, NY, USA, 2010, pp. 5:1–5:8. [8] M. Essid, Y. Lassoued, and O. Boucelma, “Processing Mediated Geographic Queries: a Space Partitioning Approach,” in The European Information Society, S. I. Fabrikant and M. Wachowicz, Eds. Springer Berlin Heidelberg, 2007, pp. 303–315. [9] O. Boucelma, “Spatial Data Integration on the Web: Issues and Solutions,” presented at the MoMM, 2006, pp. 5–6. [10] “Pipes: Rewire the web.” [Online]. Available: http://pipes.yahoo.com/pipes/. [Accessed: 12- Jan-2011]. [11] Jin Yu, B. Benatallah, F. Casati, and F. Daniel, “Understanding Mashup Development,” Internet Computing, IEEE, vol. 12, no. 5, pp. 44–52, 2008. [12] H. Chen, B. Lu, Y. Ni, G. Xie, C. Zhou, J. Mi, and Z. Wu, “Mashup by surfing a web of data APIs,” Proc. VLDB Endow., vol. 2, no. 2, pp. 1602–1605, 2009. [13] E. M. Maximilien, A. Ranabahu, and K. Gomadam, “An Online Platform for Web APIs and 112 Service Mashups,” Internet Computing, IEEE, vol. 12, no. 5, pp. 32–43, 2008. [14] E. M. Maximilien, H. Wilkinson, N. Desai, and S. Tai, “A Domain-Specific Language for Web APIs and Services Mashups,” in Proceedings of the 5th international conference on ServiceOriented Computing, Vienna, Austria, 2007, pp. 13–26. [15] Nan Zang and M. B. Rosson, “Playing with information: How end users think about and integrate dynamic data,” in Visual Languages and Human-Centric Computing, 2009. VL/HCC 2009. IEEE Symposium on, 2009, pp. 85–92. [16] R. Ennals and D. Gay, “User-friendly functional programming for web mashups,” in Proceedings of the 12th ACM SIGPLAN international conference on Functional programming, Freiburg, Germany, 2007, pp. 223–234. [17] J. Lin, J. Wong, J. Nichols, A. Cypher, and T. A. Lau, “End-user programming of mashups with vegemite,” in Proceedings of the 13th international conference on Intelligent user interfaces, Sanibel Island, Florida, USA, 2009, pp. 97–106. [18] E. Acquaro, V. Manferto de Fabianis, and L. Cohen, Les Phéniciens trésors d’une civilisation ancienne. Vercelli (Italie); Paris: White Star, 2009. [19] S. Abiteboul and C. Beeri, “The power of languages for the manipulation of complex values,” The VLDB Journal, vol. 4, no. 4, pp. 727–794, Oct. 1995. [20] S. Abiteboul, R. Hull, and V. Vianu, Eds., Foundations of Databases: The Logical Level, 1st ed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1995. [21] E. F. Codd, “A relational model of data for large shared data banks,” Commun. ACM, vol. 13, no. 6, pp. 377–387, juin 1970. [22] F. Bancilhon, “The O2 object-oriented database system,” in Proceedings of the 1992 ACM SIGMOD international conference on Management of data, New York, NY, USA, 1992, pp. 7–7. [23] K. R. Dittrich, H. Fritschi, S. Gatziu, A. Geppert, and A. Vaduva, “SAMOS in hindsight: experiences in building an active object-oriented DBMS,” Inf. Syst., vol. 28, no. 5, pp. 369– 392, juillet 2003. [24] R. G. G. Cattell, D. K. Barry, M. D. Berler, J. Eastman, D. Jordan, C. Russel, O. Schadow, T. Stanienda, and F. Velez, The Object Data Satandard: ODMG 3.0. Morgan Kaufmann, 2000. [25] E. Griffin, Foundations of Popfly: Rapid Mashup Development. Apress, 2008. [26] S. Abiteboul, P. Buneman, and D. Suciu, Data on the Web: From Relations to Semistructured Data and Xml. Morgan Kaufmann, 2000. [27] S. Abiteboul, I. Manolescu, P. Rigaux, M.-C. Rousset, and P. Senellart, Web Data Management. Cambridge University Press, 2011. [28] C. R. Anderson and E. Horvitz, “Web montage: a dynamic personalized start page,” in Proceedings of the 11th international conference on World Wide Web, New York, NY, USA, 2002, pp. 704–712. [29] R. J. Ennals and M. N. Garofalakis, “MashMaker: mashups for the masses,” in Proceedings of the 2007 ACM SIGMOD international conference on Management of data, Beijing, China, 113 2007, pp. 1116–1118. [30] “JackBe.com - Real-Time Intelligence Solutions | Presto.” [Online]. Available: http://www.jackbe.com/products/. [Accessed: 12-Jan-2011]. [31] A. Bouguettaya, S. Nepal, W. Sherchan, Xuan Zhou, J. Wu, Shiping Chen, Dongxi Liu, L. Li, Hongbing Wang, and Xumin Liu, “End-to-End Service Support for Mashups,” Services Computing, IEEE Transactions on, vol. 3, no. 3, pp. 250–263, 2010. [32] “Mashup Server by WSO2 - Open Source Mashup Server for easy Web service composition and aggregation using JavaScript | WSO2.” [Online]. Available: http://wso2.com/products/mashup-server/. [Accessed: 12-Jan-2012]. [33] J. Palfrey and U. Gasser, “Case Study: Mashups Interoperability and eInnovation,” University of St. Gallen, 2007. [34] D. Deutch, O. Greenshpan, and T. Milo, “Navigating through Mashed-up Applications with COMPASS,” in Data Engineering (ICDE), 2010 IEEE 26th International Conference on, 2010, pp. 1117–1120. [35] V. Hoyer and M. Fischer, “Market Overview of Enterprise Mashup Tools,” in ServiceOriented Computing – ICSOC 2008, 2008, pp. 708–721. [36] Amin Andjomshoaa, G. Bader, and A. M. Tjoa, “Exploiting Mashup Architecture in Business Use Cases,” presented at the NBIS 2009, Indianapolis, USA, 2009. [37] V. Hoyer and K. Stanoevska-Slabeva, “Towards a Reference Model for Grassroots Enterprise Mashup Environmentd,” in Proceedings of the 17th European Conference on Information Systems (ECIS 2009), Verona, Italy, 2009, p. 10. [38] M. Altinel, P. Brown, S. Cline, R. Kartha, E. Louie, V. Markl, L. Mau, Y.-H. Ng, D. Simmen, and A. Singh, “Damia: a data mashup fabric for intranet applications,” in Proceedings of the 33rd international conference on Very large data bases, Vienna, Austria, 2007, pp. 1370– 1373. [39] L. Ramaswamy, J. A Miller, and O. Al-Haj Hassan, “The MACE Approach for Caching Mashups,” International Journal of Web Services Research, vol. 7, no. 4, pp. 64–88, 2010. [40] J. Crupi, “A Business Guide to Enterprise Mashups,” JackeBe Corporation, 2008. [41] V. Hoyer and K. Stanoevska-Slabeva, “Generic Business Model Types for Enterprise Mashup Intermediaries,” Value Creation in E-Business Management, 2009. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-03132-8_1. [Accessed: 11-Dec-2009]. [42] D. Deutch, O. Greenshpan, and T. Milo, “Navigating in complex mashed-up applications,” Proc. VLDB Endow., vol. 3, pp. 320–329, Sep. 2010. [43] A. Thor, D. Aumueller, and E. Rahm, “Data Integration Support for Mashups,” 2007. [44] G. Di Lorenzo, H. Hacid, H. Paik, and B. Benatallah, “Data integration in mashups,” SIGMOD Rec., vol. 38, no. 1, pp. 59–66, Jun. 2009. [45] N. Bidoit, Bases de données déductives: présentation de Datalog. Armand Colin, 1991. [46] P. G. Kolaitis and M. Y. Vardi, On the Expressive Power of Datalog: Tools and a Case Study. 114 University of California, Santa Cruz, Computer Research Laboratory, 1990. [47] E. Ort, S. Brydon, and M. Balser, “Mashup Styles, Part 1: Server-Side Mashups,” Oracle, 2007. [48] E. Ort, S. Brydon, and M. Balser, “Mashup Styles, Part 2: Client-Side Mashups in the Java EE Platform,” Oracle, 2007. [49] A. Koschmider, V. Torres, and V. Pelechano, “Elucidating the Mashup Hype: Definition, Challenges, Methodical Guide and Tools for Mashups,” in 2nd Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web in conjunction with the 18th International World Wide Web Conference, Madrid, 2009. [50] R. Ennals, E. Brewer, M. Garofalakis, M. Shadle, and P. Gandhi, “Intel Mash Maker: join the web,” SIGMOD Rec., vol. 36, no. 4, pp. 27–33, 2007. [51] S. Aghaee and C. Pautasso, “Mashup development with HTML5,” in Proceedings of the 3rd and 4th International Workshop on Web APIs and Services Mashups, New York, NY, USA, 2010, pp. 10:1–10:8. [52] K. Pfeil, “Data Security and Data Availability in the Administrative Authority,” Microsoft TechNet. [53] F. Piedad and M. W. Hawkins, High Availability: Design, Techniques, and Processes, 1st ed. Prentice Hall, 2000. [54] E. Marcus and H. Stern, Blueprints for High Availability. Wiley, 2003. [55] V. Peralta, “Data freshness and data accuracy: A state of the art,” Instituto de Computación, Facultad de Ingeniería, Universidad de la República, URUGUAY, 2006. [56] M. Bouzeghoub, “A framework for analysis of data freshness,” in Proceedings of the 2004 international workshop on Information quality in information systems, New York, NY, USA, 2004, pp. 59–67. [57] B. Shin, “An Exploratory Investigation of System Success Factors in Data Warehousing,” Journal of the Association for Information Systems, vol. 4, no. 1, Aug. 2003. [58] X. Ma, S. S. Vazhkudai, and Z. Zhang, “Improving Data Availability for Better Access Performance: A Study on Caching Scientific Data on Distributed Desktop Workstations,” J Grid Computing, vol. 7, no. 4, pp. 419–438, Dec. 2009. [59] S. Drapeau, “RS2.7 : un Canvas Adaptable de Services de Duplication,” Institut National Polytechnique De Grenoble, Grenoble, 2003. [60] R. van Renesse and R. Guerraoui, “Replication,” B. Charron-Bost, F. Pedone, and A. Schiper, Eds. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 19–40. [61] R. van Renesse and R. Guerraoui, “Replication Techniques for Availability,” in Replication, B. Charron-Bost, F. Pedone, and A. Schiper, Eds. Springer Berlin Heidelberg, 2010, pp. 19–40. [62] L. D’Orazio, “Caches adaptables et applications aux systèmes de gestion de données répartis à grande échelle,” Grenoble INP, 2007. [63] J. Wang, “A survey of web caching schemes for the Internet,” SIGCOMM Comput. 115 Commun. Rev., vol. 29, no. 5, pp. 36–46, Oct. 1999. [64] K. S. Ahluwalia and A. Jain, “High availability design patterns,” in Proceedings of the 2006 conference on Pattern languages of programs, New York, NY, USA, 2006, pp. 19:1–19:9. [65] G. Attiya and Y. Hamam, “Reliability oriented task allocation in heterogeneous distributed computing systems,” in Ninth International Symposium on Computers and Communications, 2004. Proceedings. ISCC 2004, 2004, vol. 1, pp. 68 – 73 Vol.1. [66] N. R. May, H. W. Schmidt, and I. E. Thomas, “Service Redundancy Strategies in ServiceOriented Architectures,” in Proceedings of the 2009 35th Euromicro Conference on Software Engineering and Advanced Applications, Washington, DC, USA, 2009, pp. 383– 387. [67] C. Cappiello, F. Daniel, M. Matera, and C. Pautasso, “Information Quality in Mashups,” Internet Computing, IEEE, vol. 14, no. 4, pp. 14–22, 2010. [68] D. Ballou, R. Wang, H. Pazer, and G. K. Tayi, “Modeling Information Manufacturing Systems to Determine Information Product Quality,” Manage. Sci., vol. 44, no. 4, pp. 462–484, avril 1998. [69] G. Di Lorenzo, H. Hacid, H. Paik, and B. Benatallah, “Mashups for Data Integration: An Analysis,” UNSW-CSE, 0810, 2008. [70] M. Bhide, P. Deolasee, A. Katkar, A. Panchbudhe, K. Ramamritham, and P. Shenoy, “Adaptive Push-Pull: Disseminating Dynamic Web Data,” IEEE Trans. Comput., vol. 51, no. 6, pp. 652–668, juin 2002. [71] G. Soundararajan, C. Amza, and A. Goel, “Database replication policies for dynamic content applications,” SIGOPS Oper. Syst. Rev., vol. 40, no. 4, pp. 89–102, avril 2006. [72] P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency control and recovery in database systems. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1987. [73] C. Pu and A. Leff, “Replica control in distributed systems: as asynchronous approach,” in Proceedings of the 1991 ACM SIGMOD international conference on Management of data, New York, NY, USA, 1991, pp. 377–386. [74] B. Kemme and G. Alonso, “A new approach to developing and implementing eager database replication protocols,” ACM Trans. Database Syst., vol. 25, no. 3, pp. 333–379, Sep. 2000. [75] R. Ladin, B. Liskov, L. Shrira, and S. Ghemawat, “Providing high availability using lazy replication,” ACM Trans. Comput. Syst., vol. 10, no. 4, pp. 360–391, Nov. 1992. [76] M.-K. Liu, F.-Y. Wang, and D. Zeng, “Web caching: A way to improve web QoS,” Journal of Computer Science and Technology, vol. 19, no. 2, pp. 113–127, 2004. [77] J. Yin, L. Alvisi, M. Dahlin, and A. Iyengar, “Engineering web cache consistency,” ACM Trans. Internet Technol., vol. 2, no. 3, pp. 224–259, août 2002. [78] Y. Ahmad, O. Kennedy, C. Koch, and M. Nikolic, “DBToaster: higher-order delta processing for dynamic, frequently fresh views,” Proc. VLDB Endow., vol. 5, no. 10, pp. 968–979, juin 2012.116 [79] M. Altinel, C. Bornhövd, S. Krishnamurthy, C. Mohan, H. Pirahesh, and B. Reinwald, “Cache tables: paving the way for an adaptive database cache,” in Proceedings of the 29th international conference on Very large data bases - Volume 29, 2003, pp. 718–729. [80] A. Labrinidis and N. Roussopoulos, “Exploring the tradeoff between performance and data freshness in database-driven Web servers,” The VLDB Journal, vol. 13, no. 3, pp. 240–255, Sep. 2004. [81] P. Scheuermann, J. Shim, and R. Vingralek, “WATCHMAN: A Data Warehouse Intelligent Cache Manager,” in Proceedings of the 22th International Conference on Very Large Data Bases, San Francisco, CA, USA, 1996, pp. 51–62. [82] Y. Kotidis and N. Roussopoulos, “DynaMat: a dynamic view management system for data warehouses,” SIGMOD Rec., vol. 28, no. 2, pp. 371–382, juin 1999. [83] W. Ye, N. Gu, G. Yang, and Z. Liu, “Extended derivation cube based view materialization selection in distributed data warehouse,” in Proceedings of the 6th international conference on Advances in Web-Age Information Management, Berlin, Heidelberg, 2005, pp. 245–256. [84] I. S. Altingovde, R. Ozcan, B. B. Cambazoglu, and Ö. Ulusoy, “Second chance: a hybrid approach for dynamic result caching in search engines,” in Proceedings of the 33rd European conference on Advances in information retrieval, Berlin, Heidelberg, 2011, pp. 510–516. [85] B. B. Cambazoglu, F. P. Junqueira, V. Plachouras, S. Banachowski, B. Cui, S. Lim, and B. Bridge, “A refreshing perspective of search engine caching,” in Proceedings of the 19th international conference on World wide web, New York, NY, USA, 2010, pp. 181–190. [86] Sadiye Alici, I. S. Altingovde, R. Ozcan, B. B. Cambazoglu, and Ö. Ulusoy, “Adaptive timeto-live strategies for query result caching in web search engines,” in Proceedings of the 34th European conference on Advances in Information Retrieval, Berlin, Heidelberg, 2012, pp. 401–412. [87] J. Tatemura, O. Po, A. Sawires, D. Agrawal, and K. S. Candan, “WReX: a scalable middleware architecture to enable XML caching for web-services,” in Proceedings of the ACM/IFIP/USENIX 2005 International Conference on Middleware, New York, NY, USA, 2005, pp. 124–143. [88] V. Ramasubramanian and D. B. Terry, “Caching of XML Web Services for Disconnected Operation,” Microsoft Research, 2002. [89] T. Takase and M. Tatsubori, “Efficient Web services response caching by selecting optimal data representation,” in 24th International Conference on Distributed Computing Systems, 2004. Proceedings, 2004, pp. 188 – 197. [90] D. D. Terry and V. Ramasubramanian, “Caching XML Web Services for Mobility,” Queue, vol. 1, no. 3, pp. 70–78, mai 2003. [91] H. Artail and H. Al-Asadi, “A Cooperative and Adaptive System for Caching Web Service Responses in MANETs,” in International Conference on Web Services, 2006. ICWS ’06, 2006, pp. 339 –346. [92] J. Huang, X. Liu, Q. Zhao, J. Ma, and G. Huang, “A browser-based framework for data cache in Web-delivered service composition,” in 2010 IEEE International Conference on Service-117 Oriented Computing and Applications (SOCA), 2010, pp. 1–8. [93] Qi Zhao, Gang Huang, Jiyu Huang, Xuanzhe Liu, and Hong Mei, “A Web-Based Mashup Environment for On-the-Fly Service Composition,” in Service-Oriented System Engineering, 2008. SOSE ’08. IEEE International Symposium on, 2008, pp. 32–37. [94] P. Grogono and P. Santas, “Equality in Object Oriented Languages,” presented at the EastEurOOPe’93, 1993. [95] P. Grogono and M. Sakkinen, “Copying and Comparing: Problems and Solutions,” in ECOOP 2000 — Object-Oriented Programming, E. Bertino, Ed. Springer Berlin Heidelberg, 2000, pp. 226–250. [96] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein, Introduction To Algorithms, 3rd Edition, 3rd Revised ed. Cambridge, Massachusetts - London, England: The MIT Press, 2009. [97] V. Estivill-Castro and D. Wood, “A survey of adaptive sorting algorithms,” ACM Comput. Surv., vol. 24, no. 4, pp. 441–476, décembre 1992. [98] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. USA: Addison-Wesley, 1994. [99] J. Espinosa-Oviedo, “Coordination fiable de services de données à base de politiques actives,” de Grenoble, 2013. [100] M. Barhamgi, D. Benslimane, C. Ghedira, A. N. Benharkat, and A. L. Gancarski, “PPPDM - a privacy-preserving platform for data mashup,” International Journal of Grid and Utility Computing, vol. 3, no. 2/3, p. 175, 2012. [101] R. Hasan, M. Winslett, R. Conlan, B. Slesinsky, and N. Ramani, “Please Permit Me: Stateless Delegated Authorization in Mashups,” in Computer Security Applications Conference, 2008. ACSAC 2008. Annual, 2008, pp. 182, 173. [102] C. Cappiello, F. Daniel, and M. Matera, “A Quality Model for Mashup Components,” in Web Engineering, 2009, pp. 236–250. [103] A. Koschmider, V. Hoyer, and A. Giessmann, “Quality metrics for mashups,” in Proceedings of the 2010 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists, New York, NY, USA, 2010, pp. 376–380. [104] A. Portilla, V. Hernandez-Baruch, G. Vargas-Solar, J.-L. Zechinelli-Martini, and C. Collet, “Building reliable services based mashups,” presented at the IV Jornadas CienfificoTécnicas en Servicios WEB y SOA (JSWEB 2008), Sevilla, Spain, 2008. [105] C. Calero, J. Ruiz, and M. Piattini, “A Web Metrics Survey Using WQM,” in Web Engineering, vol. 3140, N. Koch, P. Fraternali, and M. Wirsing, Eds. Springer Berlin / Heidelberg, 2004, pp. 766–766. [106] M. Matera, F. Rizzo, and G. Carughi, “Web Usability: Principles and Evaluation Methods,” in Web Engineering, E. Mendes and N. Mosley, Eds. Springer Berlin Heidelberg, 2006, pp. 143–180. [107] S. Amdouni, D. Benslimane, M. Barhamgi, A. Hadjali, R. Faiz, and P. Ghodous, “A Preference-aware Query Model for Data Web Services,” in Proceedings of the 31st International Conference on Conceptual Modeling, Berlin, Heidelberg, 2012, pp. 409–422.118 [108] O. Beletski, “End User Mashup Programming Environments,” in T-111.5550 Seminar on Multimedia, 2008. [109] “Microsoft Research FUSE Labs - Project Montage.” [Online]. Available: http://fuse.microsoft.com/page/montage. [Accessed: 27-Jun-2012]. [110] R. Ennals, E. Brewer, M. Garofalakis, M. Shadle, and P. Gandhi, “Intel Mash Maker: join the web,” SIGMOD Rec., vol. 36, no. 4, pp. 27–33, 2007. [111] D. E. Simmen, M. Altinel, V. Markl, S. Padmanabhan, and A. Singh, “Damia: data mashups for intranet applications,” in Proceedings of the 2008 ACM SIGMOD international conference on Management of data - SIGMOD ’08, Vancouver, Canada, 2008, p. 1171.119 ANNEXE$A : SYSTEMES D’EXECUTION)DE)MASHUPS ETUDIES Pendant ces dernières années, plusieurs environnements de création de mashups ont vu le jour. Chacun de ces environnements offre un ensemble de fonctionnalités et caractéristiques qui répondent à des besoins spécifiques d’un certain public. Ainsi, certains environnements sont dédiés aux constructeurs novices, alors que d’autres s’adressent aux développeurs. Dans cette section, nous présentons une sélection d’environnements de création et d’exécution de mashups. Pour des études poussées sur ces outils, le lecteur peut se référer à [35][11][108]. Montage Montage [109] est un outil de création de mashups développé par Microsoft. Il permet aux utilisateurs novices de créer des pages web personnalisées, qui peuvent afficher des données provenant de différentes sources, comme le montre la Figure 6752: vidéos, flux RSS, images, tweets … Figure'67 :'Sources'de'données'dans'Montage Le contenu est disposé sur la page sous la forme d’une grille. Celle-ci peut être décomposée horizontalement et verticalement. Chaque rectangle de la grille représente un mashlet et affiche les données choisies par l’utilisateur. Il n’y a aucune communication entre les mashlets. 52 La figure est scindée en deux, pour une raison d’espace.120 Yahoo!)Pipes Yahoo! Pipes [10] permet aux utilisateurs d’agréger des données provenant de différents sources comme des flux ou des pages web via un éditeur graphique, comme le montre la Figure 68. Figure'68 :'Construction'de'mashlets'dans'Yahoo!'Pipes Il est principalement destiné aux utilisateurs ayant quelques notions de programmation. En effet, les mashups sont créés via un mécanisme de glisser-déposer. Un « Pipe » est un ensemble de modules connectés. Un module correspond à un opérateur qui exécute une tâche spécifique. L'ensemble des opérateurs disponibles comprend les opérateurs de transformation de données (tri, filtrage ...), les opérateurs de contrôle (boucle), les opérateurs arithmétiques (comptage…) et les opérateurs sur les expressions régulières. Intel)MashMaker MashMaker [110][16][29] est un outil de construction de mashups proposé par Intel en version bêta, mis hors service en 2011. Il est fourni sous la forme d’une extension pour les navigateurs Firefox et Internet Explorer. L’outil offre des fonctionnalités qui permettent de personnaliser des pages web en ajoutant des informations supplémentaires et des widgets. L’utilisateur peut définir des extracteurs (scrapers) pour extraire des données des pages web. Les données extraites sont organisées sous la forme d’une structure arborescente qui peut être lue et enrichie par d’autres widgets. Les mashups sont construits par un mécanisme de copier-coller de widgets (qui affichent des données extraites d’autres sites) et par l’ajout de widgets qui exécutent des requêtes de transformations de données.121 WSO2)Mashup)Server WSO2 Mashup Server [32] est une plateforme open source qui est dédiée aux développeurs. Elle offre un environnement pour créer, déployer et exécuter les mashups. La plateforme est basée sur les technologies XML et JavaScript. Elle permet d’agréger des données issues de différentes sources comme les pages web, les services web, les flux ou les bases de données. Le résultat peut être exposé sous la forme d’un flux, d’un service web, d’une page web, ou d’un widget à ajouter dans iGoogle. Damia Damia [38][111] est un outil de construction de mashups proposé par IBM. Il permet d’agréger des données issues de différentes sources comme Notes, Excel, des pages web, … Les données sont agrégées par le moyen d’opérateurs comme l’union, le tri, le filtrage. La création du mashup se fait au sein d’un navigateur. Comme dans Yahoo! Pipes, le constructeur glisse les sources et les opérateurs et les branches via des connecteurs. Presto)Enterprise)Mashups Presto Enterprise Mashups [40] est une plateforme de création de mashups proposée par JackBe Corporation. La plateforme est dédiée à la création de mashups d’entreprises. Elle permet d’agréger des données issues de sources internes et d’autres issues de sources externes. La plateforme fournit également des outils pour définir les échanges entre mashlets ainsi que l’interface graphique du mashup et des mashlets. L’agrégation de données peut se faire soit d’une manière graphique, soit par programmation. Dans le premier cas, la construction est similaire à celle de Yahoo! Pipes, et se fait dans un navigateur web. Dans le second cas, le développeur est amené à écrire son code en langage EMML, via une extension Eclipse : Presto Mashup Studio. La plateforme fournit également des extensions qui permettent d’importer des données et/ou d’exporter les mashlets vers d’autres plateformes comme : • Microsoft SharePoint • Des produits Oracles. • Des terminaux mobiles • Des portails • Des fichiers Excel Mashup)Service)System Mashup Service System MSS [31] est une plateforme conçue pour les utilisateurs novices, qui leur permet de construire des mashups personnalisés qui répondent à des besoins spécifiques. Comme illustré dans la Figure 69, les données sont accessibles via des services. Ces services sont décrits selon un certain modèle sémantique de services (basé sur une certaine ontologie définie par « une communauté »), qui permet d’avoir un raisonnement automatique sur les services. L'utilisateur est invité à exprimer ses besoins, qui sont traduits en requêtes MSQL (Mashup Service Query Language, langage de type SQL). MSS recherche alors, automatiquement, les services 122 appropriés et crée le mashup en composant automatiquement les services. Le mashup est exécuté et le résultat est retourné à l’utilisateur comme réponse à sa requête. Dans [107], les auteurs proposent une approche similaire. Elle est basée également sur une description sémantique des services web et de l’expression des besoins de l’utilisateur. Ils permettent de surcroit, à l’utilisateur d’exprimer des préférences dans sa requête. Celles ci sont prises en considération lors du calcul et du tri du résultat. Figure'69 :'Architecture'de'MSS 123 ANNEXE$B : SYNTAXE'DE'JSON La syntaxe de JSON est présentée dans la Figure 7053. JSON se base sur deux structures : les objets (une collection de paires nom : valeur) et les tableaux (une liste de valeurs ordonnées). Pratiquement tous les langages de programmation proposent ces structures de données sous une forme ou une autre. Les valeurs peuvent être atomiques de type chaine de caractère, nombre, booléen ou des objets ou des tableaux. Figure'70 :'Syntaxe'de'JSON 53 Images obtenues de http://www.json.org/json-fr.html124 Un objet JSON est représenté par un ensemble de paires nom : valeurs séparées par des virgules entre deux accolades. Par exemple une valeur de l’entrée du mashlet Map du mashup ItineraryPlanner peut être représentée par un l’objet JSON entreeMashup suivant : entreeMashup = {“depart” : “Grenoble”, “destination” : “Paris”, “note” : 4} Un tableau JSON est une liste de valeurs ordonnées séparées par des virgules et délimitées par deux crochets. Par exemple, la liste de valeurs de villes intermédiaires entre Grenoble et Paris sous format WOEID54 peut être représentée par le tableau JSON listeVilles suivant : listeVilles = [{"woeid":12724717}, {"woeid":12724728}, {"woeid":12724752}, {"woeid":12726960}, {"woeid":582081}, {"woeid":12726917}, {"woeid":12726920},{"woeid":12726958}, {"woeid":12723642}, {"woeid":12728226}, {"woeid":12728378}, {"woeid":12728381}, {"woeid":20068149}, {"woeid":20068148}, {"woeid":20068141}] Un document JSON est un objet JSON. Il peut être constitué d’imbrications d’un nombre non limité d’objets et tableaux [27]. L’itinéraire entre Grenoble et Paris est décrit par le document JSON routeGP dont une partie est donnée ci dessous. {"routes" : [ { "bounds" : { "northeast" : { "lat" : 48.857240, "lng" : 5.724690000000001 }, "southwest" : { "lat" : 45.18839000000001, "lng" : 2.306130 } }, "copyrights" : "Données cartographiques ©2012 GeoBasis-DE/BKG (©2009), Google", "legs" : [ { "distance" : { "text" : "574 km", "value" : 573623 }, "duration" : { "text" : "5 heures 21 minutes", "value" : 19284 }, "end_address" : "Paris, France", "end_location" : { "lat" : 48.857240, "lng" : 2.35260 }, "start_address" : "Grenoble, France", "start_location" : { "lat" : 45.18839000000001, "lng" : 5.724690000000001 }, 54 Un identifiant WOEID (Where on Earth IDentifier) est un identifiant de référence assigné par Yahoo! Pour identifier des points géographiques sur la terre. 125 "steps" : [ { "distance" : { "text" : "92 m", "value" : 92 }, "duration" : { "text" : "1 minute", "value" : 7 }, "end_location" : { "lat" : 45.188890, "lng" : 5.725610000000001 }, "html_instructions" : "Prendre la direction \u003cb\u003enord-est\u003c/b\u003e sur \u003cb\u003ePl. Victor Hugo\u003c/b\u003e vers \u003cb\u003eRue Paul Bert\u003c/b\u003e", "polyline" : { "points" : "mzxrGib}a@g@gA{@oB" }, "start_location" : { "lat" : 45.18839000000001, "lng" : 5.724690000000001 }, "travel_mode" : "DRIVING" …… } ], "status" : "OK" } L’accès à une valeur dans un tableau se fait classiquement par une notation indexée. Par exemple listeVilles[1] ={"woeid":12724717}. Tandis que l’accès à une valeur d’une paire d’un objet JSON se fait en indiquant le nom de la paire. Par exemple entreeMashup.depart = “Grenoble”. En combinant ces 2 notations, on peut spécifier des chemins d’accès à des valeurs à l’intérieur d’un document JSON. Par exemple, le chemin d’accès suivant : routeGP.routes[0].legs[0].steps[0].start_location permet d’accéder à la donnée qui représente les coordonnées géographiques du point de départ de la première étape de l’itinéraire. {"lat" : 45.18839000000001,"lng" : 5.724690000000001}. 127 128 Cette thèse présente MELQART, un système d’exécution de mashups avec disponibilité de données. Un mashup est une application web qui combine des données provenant de fournisseurs hétérogènes (web services). Ces données sont agrégées pour former un résultat homogène affiché dans des composants appelés mashlets. Les travaux dans le domaine des mashups, se sont principalement intéressés au fonctionnement des mashups, aux différents outils de construction et à leur utilisation et interaction avec les utilisateurs. Dans cette thèse, nous nous intéressons à la gestion de données dans les mashups et plus particulièrement à la disponibilité et la fraîcheur de ces données. L’amélioration de la disponibilité tient compte du caractère dynamique des données des mashups. Elle garantit (1) l’accès aux données même si le fournisseur est indisponible, (2) la fraicheur de ces données et (3) un partage de données entre les mashups afin d’augmenter la disponibilité de données. Pour cela nous avons défini un modèle de description de mashups permettant de spécifier les caractéristiques de la disponibilité des données. Le principe d’exécution de mashups est défini selon ce modèle en proposant d’améliorer la disponibilité et la fraicheur des données du mashup par des fonctionnalités orthogonales à son processus d’exécution. Le système MELQART implante ce principe et permet de valider notre approche à travers l’exécution de plusieurs instances de mashups dans des conditions aléatoires de rupture de communication avec les fournisseurs de données. Mots clés : Mashups, Web 2.0, services web, disponibilité de données, fraicheur de données --------------------------------------------------------------------------------------------------------------------------- This thesis presents MELQART: a mashup execution system that ensures data availability. A mashup is a Web application that application that combines data from heterogeneous provides (Web services). Data are aggregated for building a homogenous result visualized by components named mashlets. Previous works have mainly focused, on the definition of mashups and associated tools and on their use and interaction with users. In this thesis, we focus on mashups data management, and more specifically on fresh mashups data availability. Improving the data availability take into account the dynamic aspect of mashups data. It ensures (1) the access to the required data even if the provider is unavailable, (2) the freshness of these data and (3) the data sharing between mashups in order to avoid the multiple retrieval of the same data. For this purpose, we have defined a mashup description formal model, which allows the specification of data availability features. The mashups execution schema is defined according to this model with functionalities that improve availability and freshness of mashed-up data. These functionalities are orthogonal to the mashup execution process. The MELQART system implements our contribution and validates it by executing mashups instances with unpredictable situations of broken communications with data providers. Keywords : mashups, Web 2.0, web services, data availability, data freshness Mesure de la fragilit´e et d´etection de chutes pour le maintien `a domicile des personnes ˆag´ees Amandine Dubois To cite this version: Amandine Dubois. Mesure de la fragilit´e et d´etection de chutes pour le maintien `a domicile des personnes ˆag´ees. Artificial Intelligence. Universit´e de Lorraine, 2014. French. HAL Id: tel-01070972 https://tel.archives-ouvertes.fr/tel-01070972 Submitted on 2 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.D´epartement de formation doctorale en informatique Ecole doctorale IAEM Lorraine ´ Sciences et T´echnologies Mesure de la fragilit´e et d´etection de chutes pour le maintien `a domicile des personnes ˆag´ees THESE ` pr´esent´ee et soutenue publiquement le 15 septembre 2014 pour l’obtention du Doctorat de l’Universit´e de Lorraine (mention informatique) par Amandine Dubois Composition du jury Pr´esident : Jean Paysant Professeur `a la Facult´e de M´edecine de Nancy Rapporteurs : Philippe Lalanda Professeur `a l’Universit´e Joseph Fourier de Grenoble Jean-Louis Vercher Directeur de Recherche au CNRS `a Marseille Examinateurs : Jacques Demongeot Professeur `a l’Universit´e Joseph Fourier de Grenoble Jacques Duchˆene Professeur `a l’Universit´e de Technologie de Troyes Michel Vacher Ing´enieur de recherche au CNRS de Grenoble Directeur de th`ese : Fran¸cois Charpillet Directeur de recherche INRIA Laboratoire Lorrain de Recherche en Informatique et ses Applications — UMR 7503Mis en page avec la classe thesul.Remerciements Je tiens à remercier tout d’abord François Charpillet de m’avoir donné l’opportunité de faire une thèse en Informatique et de m’avoir accordé sa confiance. Je remercie également les membres de mon jury : monsieur Jean Paysant pour avoir présidé ce jury, messieurs Philippe Lalanda et Jean-Louis Vercher de m’avoir fait l’honneur de rapporter ce travail de thèse et messieurs Jacques Demongeot, Jacques Duchêne et Michel Vacher pour leurs remarques et leurs questions constructives. Merci également à Abdallah, Manel, Marion, Olivier et à tous ceux que j’ai pu côtoyer pendant ces trois ans, collègues de bureau, de couloir, de bâtiment, pour les discussions, leurs suggestions et surtout pour leur bonne humeur. Je remercie mes parents et mon frère qui m’ont toujours soutenue et encouragée et sans lesquels je ne serais pas parvenue à accomplir ce travail de thèse. Je remercie mes grands-parents pour avoir été les premiers « cobayes » et surtout pour m’avoir donné l’envie de travailler sur ce sujet. Je te remercie Cédric pour ton soutien permanent. iiiSommaire Table des figures xi Liste des tableaux xv Introduction 1 1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Approche proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Partie I Approches pour la mesure de la fragilité et la détection des chutes 9 Introduction 11 Chapitre 1 Panorama des approches pour l’analyse de la fragilité à l’hôpital 1.1 L’œil expert à travers les tests cliniques . . . . . . . . . . . . . . . . . . . . . 13 1.2 Outils d’analyse du mouvement . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . . . . . 14 1.2.2 Systèmes sans capteur embarqué sur la personne . . . . . . . . . . . . 16 1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Chapitre 2 Panorama des systèmes de détection de chutes au domicile 2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . . . . . . . . . 19 iiiSommaire 2.1.1 Détecteurs de chutes automatiques . . . . . . . . . . . . . . . . . . . . 19 2.1.2 Systèmes d’alerte manuels . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Systèmes ambiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 Capteurs environnementaux : la télé-assistance . . . . . . . . . . . . . 21 2.2.2 Systèmes à base de caméra : la vidéo-vigilance . . . . . . . . . . . . . 22 2.2.3 Capteurs au sol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Conclusion 25 Partie II Algorithmes pour l’évaluation et la sécurisation au domicile 27 Introduction 29 Chapitre 3 Détecter et suivre une personne avec une caméra : état de l’art 3.1 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.1.1 Détecteur de points d’intérêt . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.2 Soustraction du fond . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.3 Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.4 Apprentissage supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 Suivi de la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Modèles d’objets animés . . . . . . . . . . . . . . . . . . . . . . . . . 35 Différentes représentations . . . . . . . . . . . . . . . . . . . . . . . . 35 Caractéristiques pour obtenir la représentation . . . . . . . . . . . . . 37 3.2.2 Suivi de l’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Objet représenté par des points . . . . . . . . . . . . . . . . . . . . . . 38 Objet représenté par des formes géométriques . . . . . . . . . . . . . . 39 Objet représenté par sa silhouette . . . . . . . . . . . . . . . . . . . . 39 3.3 Caméra de profondeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Chapitre 4 Application à la détection et au suivi de personnes avec une caméra RGB-D 4.1 Détecter la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 iv4.1.1 Extraction et apprentissage du fond . . . . . . . . . . . . . . . . . . . 44 4.1.2 Extraction du sol et changement de repère . . . . . . . . . . . . . . . 44 Etape 1 : Redressement de la scène . . . . . . . . . . . . . . . . . . . 44 Etape 2 : Sélection des points bas . . . . . . . . . . . . . . . . . . . . 45 Etape 3 : Calcul de l’équation du sol . . . . . . . . . . . . . . . . . . . 45 Etape 4 : Construction du repère sol . . . . . . . . . . . . . . . . . . . 46 Projection d’un point dans le repère sol . . . . . . . . . . . . . . . . . 46 4.1.3 Extraction des points mobiles . . . . . . . . . . . . . . . . . . . . . . . 46 4.1.4 Extraction des objets mobiles . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.5 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Suivre la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1 Représentation de la personne . . . . . . . . . . . . . . . . . . . . . . 49 4.2.2 Suivi du centre de masse . . . . . . . . . . . . . . . . . . . . . . . . . 51 Calcul du centre de masse . . . . . . . . . . . . . . . . . . . . . . . . . 51 Description de la trajectoire du centre de masse . . . . . . . . . . . . 51 Lissage de la trajectoire du centre de masse . . . . . . . . . . . . . . 52 Paramètres dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2.3 Suivi de la distribution verticale . . . . . . . . . . . . . . . . . . . . . 53 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Chapitre 5 Mesurer à domicile les paramètres de la marche 5.1 Définition et description de la marche . . . . . . . . . . . . . . . . . . . . . . 58 5.1.1 Définition de la marche . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1.2 Description du cycle de la marche . . . . . . . . . . . . . . . . . . . . 58 Phase d’appui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Phase d’oscillation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2 Indicateurs de l’analyse de la marche . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.1 Paramètres spatio-temporels . . . . . . . . . . . . . . . . . . . . . . . 59 Principaux paramètres spatiaux . . . . . . . . . . . . . . . . . . . . . 59 Principaux paramètres temporels . . . . . . . . . . . . . . . . . . . . . 60 5.2.2 Paramètres cinématiques . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.3 Paramètres dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Les forces de réaction du sol . . . . . . . . . . . . . . . . . . . . . . . 61 Pressions plantaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3 Sélection des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Troubles de la marche et risques de chute . . . . . . . . . . . . . . . . 64 vSommaire 5.3.2 Troubles de la marche et risques d’hospitalisation . . . . . . . . . . . 64 5.3.3 Troubles de la marche et troubles cognitifs . . . . . . . . . . . . . . . 64 5.4 Extraction des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.1 Longueurs de pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.2 Cadence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.3 Vitesse de marche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.4 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Chapitre 6 Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur 6.1 Approches pour détecter l’activité . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1.1 Approches non paramétriques . . . . . . . . . . . . . . . . . . . . . . 70 6.1.2 Approches volumétriques . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1.3 Approches paramétriques . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.2 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.3 Proposition d’un modèle de l’activité . . . . . . . . . . . . . . . . . . . . . . . 73 6.3.1 Modèle avec fonction d’observation seule . . . . . . . . . . . . . . . . 74 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.3.2 Utilisation d’un MMC unique . . . . . . . . . . . . . . . . . . . . . . . 75 MMC à 8 états et 3 observations . . . . . . . . . . . . . . . . . . . . . 75 MMC à 9 états et 5 observations . . . . . . . . . . . . . . . . . . . . . 76 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3.3 Utilisation de MMC combinés . . . . . . . . . . . . . . . . . . . . . . 79 Système de 8 MMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Système de 9 MMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Conclusion 83 Partie III Evaluation du système 85 Introduction 87 viChapitre 7 Expérimentations pour l’analyse de la marche 7.1 Première évaluation du système . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 89 7.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Angle de la caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Choix du filtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.2 Évaluation globale du système . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 94 7.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Résultats basés sur l’erreur de chaque séquence . . . . . . . . . . . . . 96 Résultats basés sur la moyenne de chaque paramètre de la marche . . 96 7.3 Discussion et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Chapitre 8 Expérimentations pour la reconnaissance d’activité 8.1 Cas de la personne entièrement visible . . . . . . . . . . . . . . . . . . . . . . 99 8.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 99 Protocole expérimental . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Base d’apprentissage et base de test . . . . . . . . . . . . . . . . . . . 100 8.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Représentation des bonnes classifications et des fausses détections . . 102 Comparaison entre les algorithmes Forward-Backward et de Viterbi . 103 Modèle avec fonction d’observation seule . . . . . . . . . . . . . . . . 105 MMC à 8 états et 3 observations . . . . . . . . . . . . . . . . . . . . . 105 MMC à 9 états et 5 observations . . . . . . . . . . . . . . . . . . . . . 107 Système de 8 MMC à 2 états et 3 observations . . . . . . . . . . . . . 107 Système de 8 MMC à 3 états et 3 observations . . . . . . . . . . . . . 107 Système de 9 MMC à 2 états et 5 observations . . . . . . . . . . . . . 107 Système de 9 MMC à 3 états et 5 observations . . . . . . . . . . . . . 108 Résultats pour l’activité debout . . . . . . . . . . . . . . . . . . . . . 108 8.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.2 Cas de la personne partiellement visible . . . . . . . . . . . . . . . . . . . . . 109 8.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 109 8.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 viiSommaire Chapitre 9 Tests en situations réelles 9.1 Test de l’algorithme d’analyse de la marche . . . . . . . . . . . . . . . . . . . 115 9.2 Test de l’algorithme de détection d’activité . . . . . . . . . . . . . . . . . . . 116 9.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Conclusion 121 Partie IV Système pour le maintien à domicile 123 Introduction 125 Chapitre 10 Vers une implantation au domicile 10.1 Couplage des fonctionnalités actuelles du système . . . . . . . . . . . . . . . 127 10.2 Cartographie des habitudes dans l’environnement . . . . . . . . . . . . . . . . 129 10.2.1 Limitations du système et contraintes de l’environnement . . . . . . . 129 10.2.2 Détection des cas d’occlusions partielles de la personne . . . . . . . . 130 10.2.3 Cartographie des habitudes . . . . . . . . . . . . . . . . . . . . . . . . 133 10.2.4 Détection des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . 134 10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Chapitre 11 Autres perspectives d’utilisation du système 11.1 Différenciation des personnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 11.2 Couplage de plusieurs capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 138 11.3 Observance des patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 11.4 Prévention de certains troubles . . . . . . . . . . . . . . . . . . . . . . . . . . 139 11.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Conclusion 141 viiiConclusion générale et perspectives 143 Annexe 149 Annexe A Modèle de Markov caché 149 A.1 Définition des modèles de Markov cachés . . . . . . . . . . . . . . . . . . . . 149 A.1.1 Processus de Markov . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 A.1.2 Modèle de Markov caché . . . . . . . . . . . . . . . . . . . . . . . . . 150 A.2 Algorithmes d’apprentissage et d’inférence . . . . . . . . . . . . . . . . . . . . 150 A.2.1 Inférence pour le cas du MMC unique . . . . . . . . . . . . . . . . . . 150 Algorithme Forward-Backward . . . . . . . . . . . . . . . . . . . . . . 150 Algorithme de Viterbi . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 A.2.2 Apprentissage et inférence pour les systèmes de plusieurs MMC . . . . 155 Apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Publications 157 Références 159 ixSommaire xTable des figures 1 Pyramide des âges en 2007 et 2060 selon une étude INSEE de 2010. . . . . . . . . 3 1.1 Représentation de la marche humaine en diagramme bâton par Marey. . . . . . . 14 1.2 Le système Walkmeterc est inspiré du locomètre de Bessou. . . . . . . . . . . . 15 1.3 Le tapis roulant instrumenté de la société Biometrics. . . . . . . . . . . . . . . . . 17 1.4 Le tapis actimètrique de la marque GaitRite. . . . . . . . . . . . . . . . . . . . . 17 2.1 Système d’alerte de Vitalbase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Système de détection de chute de la société Vigilio. . . . . . . . . . . . . . . . . . 20 2.3 Système d’analyse du mouvement par le sol d’INRIA à Nancy. . . . . . . . . . . . 23 3 Vision pour la conception d’un système permettant le maintien à domicile des personnes âgées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1 Détection des points d’intérêts dans une scène. . . . . . . . . . . . . . . . . . . . 34 3.2 Différentes représentations de l’objet à suivre : (a) silhouette, (b) contour, (c) points, (d) centre géométrique, (e) ellipse, (f) rectangle, (g) plusieurs ellipses et (h) squelette. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3 Détection des contours dans une scène. . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4 Différentes hypothèses utilisées pour le suivi d’un objet : (a) proximité, (b) vitesse maximale, (c) mouvement similaire, (d) constance de la vitesse et de la direction, (e) rigidité de l’objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.5 Transformation paramétrique d’une ellipse. . . . . . . . . . . . . . . . . . . . . . 39 3.6 Modèle d’apparence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.7 Le capteur Kinect de Microsoft. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1 Étapes pour détecter la personne du fond et la suivre dans le temps. . . . . . . . 44 4.2 L’extraction du sol est représentée en rouge. . . . . . . . . . . . . . . . . . . . . 47 4.3 a) Les cases bleues représentent des points mobiles et les cases vertes les points appartenant au fond, b) le filtre érosion est appliqué, c) le filtre dilatation est appliqué. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4 a) Les cases colorées représentent des points mobiles, b) l’algorithme assigne un nombre aux points mobiles, c) les points avec un nombre plus grand que ses voisins sont modifiés, d) le résultat final est atteint. . . . . . . . . . . . . . . . . . . . . 48 4.5 Déplacement horizontal théorique du centre de masse. . . . . . . . . . . . . . . . 50 4.6 Déplacement vertical théorique du centre de masse. . . . . . . . . . . . . . . . . 50 xiTable des figures 4.7 Déplacement du centre de masse extrait à partir de notre algorithme pour une personne marchant en ligne droite perpendiculairement à la caméra. La montée et la descente en début et fin de trajectoire correspondent aux entrées et sorties de la personne dans le champ de vision de la caméra. . . . . . . . . . . . . . . . . . . 51 4.8 Comparaison entre la trajectoire du centre de masse et le nombre de pixels mobiles appartenant à une personne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.9 a) Courbe non lissée, b) courbe lissée avec le filtre passe-bas, c) courbe lissée avec le filtre de Kalman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.10 Trajectoire de l’écart type vertical pour une personne qui marche. . . . . . . . . 54 4.11 Comparaison entre la trajectoire du point maximum filtrée et non filtrée pour une personne qui marche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.1 Représentation du cycle de la marche selon Viel (2000). . . . . . . . . . . . . . . 58 5.2 Représentation des paramètres spatiaux. . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Représentation des paramètres cinématiques. . . . . . . . . . . . . . . . . . . . . 61 5.4 Représentation des forces exercées lorsqu’une personne marche. . . . . . . . . . . 62 5.5 Force de réaction du sol selon l’axe vertical (bleu), antéro-postérieur (vert) et média-latéral (rouge) lors d’un cycle de marche selon Kirtley. . . . . . . . . . . . 63 5.6 Trajectoire des pressions plantaires lors de la marche. . . . . . . . . . . . . . . . . 63 5.7 Correspondance entre le cycle de la marche et la trajectoire du centre de masse sur l’axe vertical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.8 Extraction des paramètres de la marche à partir du centre de masse. . . . . . . . 67 6.1 Positionnement du problème de la reconnaissance d’activité au domicile. . . . . . 71 6.2 Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. . . . . . . . . 73 6.3 Modèle à 8 états avec fonction d’observation seule. . . . . . . . . . . . . . . . . . 75 6.4 MMC à 8 états avec des transitions définies manuellement. . . . . . . . . . . . . . 77 6.5 MMC à 9 états avec des transitions définies manuellement. . . . . . . . . . . . . . 78 6.6 Système de 8 MMC à deux états chacun. . . . . . . . . . . . . . . . . . . . . . . 80 6.7 Système de 9 MMC à deux états chacun. . . . . . . . . . . . . . . . . . . . . . . 81 7.1 Méthode utilisée comme référence pour mesurer les longueurs de pas. . . . . . . . 90 7.2 Positionnement des caméras : la plus basse avec un angle de 0˚ et la plus haute avec un angle de -27˚. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.3 Représentation des erreurs sur les longueurs de pas obtenues à partir d’une caméra avec un angle de -27˚ et avec un angle de 0˚. . . . . . . . . . . . . . . . . . . . . 92 7.4 Représentation des erreurs sur les longueurs de pas extraites à partir du filtre de Kalman et du filtre passe-bas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.5 Expérience comprenant un tapis actimètrique. . . . . . . . . . . . . . . . . . . . 95 7.6 En phase de double appui, de nombreux points mobiles sont détectés dans la partie basse de la silhouette quand le sujet porte une jupe. . . . . . . . . . . . . . . . . 98 7.7 Comparaison des oscillations de la trajectoire du centre de masse. . . . . . . . . . 98 8.1 Plan de l’appartement expérimental avec le positionnement de la caméra. . . . . 100 8.2 Suivi des situations, effectuées par un sujet, à différents pas de temps. . . . . . . 101 8.3 Différence dans l’analyse faite par les algorithmes Forward-Backward et de Viterbi, pour une séquence où la personne s’assoit puis monte sur une chaise. . . . . . . . 104 8.4 Comparaison d’une séquence où la personne s’assoit analysée par deux modèles. . 105 xii8.5 Sujet s’allongeant différemment de ce qui a été appris dans la base de donnée. . 106 8.6 Sujet s’asseyant différemment de ce qui a été appris dans la base de donnée. . . . 106 8.7 Suivi des situations où le sujet n’est pas entièrement visible à différents pas de temps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 8.8 Résultat de l’analyse avec le modèle à 9 états et 5 observations, pour une personne réalisant des demi-tours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 9.1 Utilisation de notre système avec une patiente, lors de sa consultation à l’hôpital. 116 9.2 Représentation du centre de masse, sur l’axe vertical, de quatre personnes âgées. 117 9.3 Détection de l’activité « Marche », pour une personne de 81 ans marchant à son domicile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 9.4 Représentation du centre de masse, sur l’axe vertical, pour différentes activités réalisées par une personne âgée de 81 ans. . . . . . . . . . . . . . . . . . . . . . . 118 10.1 Les différentes actions réalisées par l’algorithme selon l’état dans lequel se trouve la personne d’après le MMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 10.2 Personne sortant du champ de vision et étant à moitié détectée. . . . . . . . . . 129 10.3 Courbes des vraisemblances pour différentes activités réalisées par un sujet entiè- rement et partiellement visible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 10.4 Séquence dans laquelle le sujet réalise plusieurs activités. . . . . . . . . . . . . . . 133 10.5 Carte de l’environnement représentant les habitudes apprises d’une personne (en blanc : zones non explorées, en bleu : zones passives, en vert : zones actives et en rouge : zones se trouvant derrière un meuble). . . . . . . . . . . . . . . . . . . . 134 10.6 Carte de l’environnement sur laquelle est représentée la dernière position du centre de masse perçue par le système. . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 11.1 Proposition d’emplacement de plusieurs caméras permettant de couvrir tout un appartement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 11.2 Représentation du centre de masse, sur l’axe vertical, d’une personne de 90 ans ayant des problèmes d’équilibre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 A.1 Exemple de modèle de Markov à deux états. . . . . . . . . . . . . . . . . . . . . . 149 A.2 Représentation graphique d’une chaine de Markov. . . . . . . . . . . . . . . . . . 150 A.3 Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. . . . . . . . . 150 A.4 Représentation du calcul αt+1(j = 1) par l’algorithme Forward pour un modèle à trois états. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 A.5 Représentation du calcul pour l’état βt(i = 1) par l’algorithme Backward pour un modèle à trois états. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 A.6 Représentation du calcul δt(j = 1) et ψt(j = 1) par l’algorithme de Viterbi pour un modèle à trois états. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 A.7 Représentation du calcul de l’algorithme de Viterbi avec la rétro-propagation (en vert) pour quatre pas de temps successifs et trois états. . . . . . . . . . . . . . . . 154 xiiiTable des figures xivListe des tableaux 7.1 Comparaison des résultats, entre le tapis et la caméra, en fonction de l’angle de la caméra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.2 Précision des longueurs de pas fournies par l’algorithme, obtenues avec un filtre de Kalman et avec un filtre passe-bas (pour tous les pas, pour les pas « normaux » et pour les petits pas). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.3 Erreurs moyennes des longueurs (Long), cadences (Cad) et vitesses (Vit) pour chaque situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 7.4 Comparaison des paramètres de la marche obtenus avec le tapis et avec notre algorithme utilisant la caméra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.1 Classification des activités par l’algorithme selon le modèle utilisé. . . . . . . . . 103 8.2 Fausses détections effectuées par l’algorithme selon le modèle utilisé. . . . . . . . 104 8.3 Classification de l’activité « Debout » selon le modèle utilisé. . . . . . . . . . . . 108 8.4 Détection d’activité quand la personne n’est pas entièrement visible pour différents modèles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 xvListe des tableaux xviIntroduction 11. Contexte 1 Contexte L’un des sujets majeurs des prochaines années dans les pays développés sera le vieillissement de la population. En France, l’INSEE [Blanpain and Chardon, 2010] prévoit que le nombre de personnes de plus de 60 ans augmentera de 10,4 millions entre 2007 et 2060 pour atteindre le nombre de 23,6 millions de personnes en 2060, soit une hausse de 80 % en 53 ans. Le nombre de personnes de plus de 75 ans passera de 5,2 millions en 2007 à 11,9 millions en 2060. Quant aux personnes de plus de 85 ans, leur nombre passera de 1,3 à 5,4 millions. Ces chiffres sont représentés sur la pyramide des âges fournie par l’INSEE à la figure 1. Figure 1 – Pyramide des âges en 2007 et 2060 selon une étude INSEE de 2010. Une des conséquences de l’augmentation du vieillissement de la population est l’augmentation du nombre de personnes âgées dépendantes 1 . Selon l’INSEE en 2004, 1 200 000 personnes seraient dépendantes en 2040 contre 800 000 aujourd’hui. La problématique qui découle de ces chiffres est la prise en charge de ces personnes. En effet, le nombre d’instituts spécialisés ne devrait pas permettre de toutes les accueillir. Actuellement, les personnes ont tendance à rester au domicile. 92 % des plus de 75 ans vivent chez eux et 75 % pour les plus de 85 ans, soit pour des raisons liées au coût qu’implique un placement, ou soit parce que la personne elle-même préfère rester chez elle (80 % des personnes âgées souhaitent vivre le plus longtemps possible au domicile [Webe, 2006]). Le vieillissement de la population est donc un problème majeur et, partant de ce constat, cette thèse cherche à apporter une contribution au maintien à domicile des personnes âgées par des dispositifs technologiques. 1. La dépendance s’évalue en fonction de la capacité de la personne à accomplir les actes de la vie quotidienne. L’outil Aggir est une grille nationale évaluant le degré de dépendance chez les personnes âgées à partir des activités qu’elles peuvent effectuer seules comme s’habiller, se laver, etc. 32 Objectifs Notre objectif est de développer un dispositif simple et facile à installer, permettant de favoriser le maintien à domicile des personnes âgées. Il s’agit de proposer une démarche de prévention de l’aggravation de la fragilité de la personne et d’aider à la sécuriser chez elle. Pour savoir si la personne est en sécurité à son domicile, il est nécessaire de connaître son niveau d’autonomie, de savoir si la personne est fragile, si elle peut se débrouiller dans son logement (se faire à manger, se laver, etc.). Pour cela, l’idée est de développer un outil d’évaluation permettant de mesurer le risque initial et l’évolution du risque que prend la personne en restant chez elle. Ces mesures permettront alors de prendre des actions de prévention comme diriger la personne vers un médecin spécialisé, modifier son environnement pour le rendre plus sûr, adapter son traitement, etc. L’évaluation du degré d’autonomie peut se faire au quotidien en installant un système à domicile. Cette évaluation constitue une information supplémentaire à l’analyse faite par le médecin lors des consultations, car l’information recueillie au domicile constitue une mesure en milieu écologique forcément différente de l’évaluation qui peut être faite en milieu hospitalier. La sécurisation de la personne passe également par la mise en place de systèmes d’alerte, car maintenir les personnes âgées à domicile n’est pas sans risque. En effet, 61 % des accidents surviennent au domicile et 85 % de ces accidents sont dus aux chutes. La chute est la première cause de mortalité des plus de 65 ans provoquant chaque année 10 000 décès [Alexander et al., 1997]. Elle peut causer des blessures physiques comme des fractures (en particulier du col du fémur), des luxations, des plaies, etc. Les blessures physiques peuvent entraîner une hospitalisation prolongée, voire même le placement en institut (40 % des sujets âgés hospitalisés pour chute sont ensuite orientés vers une institution). Une cascade de complications psychologiques peut également survenir suite à la chute elle-même et/ou du fait d’être resté immobilisé au sol en état d’impuissance sans pouvoir se relever. En effet, près de 50 % des personnes ayant chuté ont besoin d’une aide pour se relever [Tinetti et al., 1993]. L’anxiété d’une deuxième chute peut entraîner chez les personnes une tendance à réduire leur mobilité et à minimiser leur activité [Gaxatte et al., 2011] (en limitant leur sortie et en restant plus souvent assise ou allongée). Cette inactivité provoque une perte d’autonomie. Des études ont montré que la perte d’autonomie pouvait directement être corrélée au temps passé au sol, 1h au sol provoque 10 % de perte d’autonomie, 3h, 30 %, 6h, 50 % et 12h, 70 %. La chute est un marqueur de fragilité et ses conséquences physiques et surtout psychologiques aggravent l’état de fragilité initiale de la personne. Cet engrenage est confirmé par des chiffres montrant que le nombre de récidives est très important : après une première chute le risque de retomber à nouveau est multiplié par vingt. Il est donc nécessaire, pour sécuriser la personne, d’être en mesure de détecter les chutes. Un tel détecteur pourrait permettre, d’une part, de limiter les conséquences physiques et psychologiques de la chute et, d’autre part, de mettre la personne en confiance pour ainsi ralentir les effets de l’inactivité (réduire l’effet engendré par le cercle vicieux). La détection précoce est cruciale, le fait d’obtenir une aide rapidement après une chute diminue le risque d’hospitalisation de 26 % et la mort de plus de 80 %. 3 Approche proposée 3.1 Problématique Dans ce travail de thèse, nous nous intéressons à développer un système couplant l’évaluation de la fragilité et la sécurisation de la personne à son domicile. Sécuriser la personne à son domicile implique de pouvoir détecter les éventuelles chutes, ou 43. Approche proposée comportements pouvant mener à une chute (comme monter sur une chaise), pour ainsi alerter des personnes extérieures et permettre d’agir au plus vite sur les conséquences physiques et psychologiques. La prise en charge rapide d’une personne ayant chuté limite l’aggravation de la perte d’autonomie. L’évaluation de la fragilité de la personne permet de mesurer sa capacité à être autonome à son domicile. Une personne est fragile, selon la définition de Fried et al. [Fried et al., 2001], si apparaît trois critères ou plus parmi les cinq suivants : une perte de poids involontaire, une faiblesse dans la force de préhension, une faible endurance, une vitesse de marche lente et une faible activité physique. La vitesse de marche diminuée et la faible activité sont les deux critères auxquels nous nous sommes intéressés pour l’évaluation de la fragilité. Notre approche vise à analyser les indicateurs de marche pour ainsi mesurer leur évolution au cours du temps et analyser l’activité de la personne pour pouvoir comptabiliser le temps passé à réaliser différentes activités. Par exemple, la perte d’autonomie, analysée à travers l’évaluation de l’activité de la personne, peut s’exprimer en fonction du temps passé debout comparé au temps passé assis et allongé sur un canapé ou un lit. Les changements d’habitudes sont également des indicateurs importants de l’évolution de la fragilité. Nous nous sommes fixé certaines contraintes pour développer un système permettant le maintien à domicile. Notamment, le système doit être basé sur une technologie réaliste, c’est-à-dire utilisable. Nous voulions, entre autres, développer des algorithmes qui puissent fonctionner sur des machines à bas coût. Pour cela, nous proposons des algorithmes simples et peu coûteux en temps de calcul et en mémoire, afin de pouvoir les insérer dans n’importe quelle machine. Pour être utilisable, l’équipement nécessaire ne doit pas être trop encombrant pour pouvoir être installé à domicile. La contrainte d’utilisation de capteurs ambiants, plutôt que de capteurs portés par la personne, a également été posée. L’idée est de laisser libre la personne sans qu’elle n’ait besoin de penser à porter le système ou à l’activer. Le choix final s’est donc porté sur le capteur Kinect de Microsoft qui est une caméra de profondeur à bas coût. 3.2 Contributions Dans l’organisation de ce mémoire, nous distinguons deux contributions. La première porte sur l’analyse du mouvement de la personne et la seconde sur l’analyse de l’activité. Ces deux contributions pourront permettre la conception d’un système d’évaluation et de sécurisation de la personne à son domicile. L’analyse du mouvement et la détection des activités d’une personne sont deux thèmes de recherche traités dans la littérature séparément, car chacun a ses propres difficultés faisant appel à des compétences différentes. Nous montrons dans cette thèse que les deux problématiques peuvent être abordées par l’analyse d’un ensemble de paramètres simples extraits d’images de profondeur. La partie I présente les systèmes existants pour d’un côté mesurer le degré de fragilité à l’hôpital et de l’autre détecter les chutes au domicile. En observant les systèmes existants et les contraintes que nous nous sommes fixées, nous expliquons les raisons pour lesquels nous avons choisi les caméras de profondeur pour développer le système. Dans une deuxième partie, nous présentons les différents algorithmes conçus à partir des informations obtenues avec la caméra. Nous y apportons, au chapitre 3, un état de l’art non exhaustif des méthodes utilisées en vision pour détecter et suivre une personne au cours du temps. Puis, au chapitre 4, nous développons nos algorithmes de détection et de suivi de la personne, fondés sur des méthodes simples que sont l’extraction de fond et le suivi de la silhouette de la personne. Ces algorithmes sont communs pour l’analyse de la marche et la détection d’activité. Plus précisément, les deux contributions sont fondées sur l’analyse des mêmes paramètres, ex- 5traits des images de profondeur fournies par la caméra, qui sont le centre de masse estimé de la personne et la distribution verticale des points de la silhouette. Nous développons dans deux chapitres distincts, les algorithmes propres à chacun des deux axes de recherche. Le chapitre 5 de ce mémoire présente les aspects concernant la marche des personnes. Ce chapitre introduit, dans un premier temps, un certain nombre de notions et de techniques, notamment dans le domaine médical, auxquelles nous faisons référence. Nous présentons les différents paramètres qu’il est possible d’analyser pour évaluer la marche d’une personne. Puis, nous présentons les paramètres que nous avons sélectionnés (longueur de pas, cadence et vitesse de marche) et les algorithmes d’extraction de ces paramètres. Cette contribution concerne la mesure de paramètres de la marche comme indicateur de l’évolution de la fragilité chez les personnes âgées. Le chapitre 6 de ce mémoire est consacré au développement d’un détecteur d’activité. Il repose sur l’utilisation du formalisme des modèles de Markov cachés, défini en annexe A. Dans ce chapitre, nous développons les différents modèles construits pour répondre au problème de la détection d’activité au domicile des personnes. La détection de l’activité apporte des informations à la fois pour la sécurisation et l’évaluation de la personne âgée. D’un côté, le travail présenté contribue à la problématique de sécurisation en détectant les chutes et les comportements anormaux. De l’autre, il contribue à la problématique d’évaluation de la perte d’autonomie permettant une analyse au long cours de l’évolution des habitudes de la personne. Les contributions des chapitres 5 et 6 sont ensuite évaluées indépendamment à la partie III de ce mémoire. Dans une première expérimentation en laboratoire nous montrons, sur des personnes jeunes, que la précision des paramètres de la marche extraits avec notre algorithme est similaire aux valeurs extraites d’un tapis actimètrique, pris comme mesure de référence. D’autres expérimentations en laboratoire ont permis de constater que certains modèles de Markov cachés fournissent une classification robuste des activités, aussi bien lorsque la personne est entièrement visible que partiellement visible. Des premiers tests ont également été effectués avec des personnes âgées en situation réelle (à l’hôpital et au domicile). Les résultats ont montré que, malgré la variabilité des trajectoires du centre de masse des sujets, l’extraction des paramètres de la marche et la reconnaissance des activités sont possibles. Enfin, la partie IV présente, dans un premier chapitre, l’association des deux contributions dans un système unique aidant à la sécurisation et à l’évaluation pour le maintien à domicile des personnes âgées. Plus précisément, nous intégrons l’algorithme de détection d’activité et celui de l’extraction des paramètres de la marche dans un seul système. Ainsi, selon l’activité détectée par l’algorithme, celui-ci enverra une alerte aux secours en cas de chute, comptabilisera le temps passé dans des activités passives (allongé ou assis) et actives (marcher ou être debout) ou analysera les paramètres de la marche quand la personne sera détectée comme marchant. Nous développons également une méthode pour cartographier les habitudes des personnes âgées, c’est-à-dire apprendre les habitudes les plus fréquentes dans les différentes zones du logement. Cela permettra de détecter les évolutions des habitudes de la personne et donc de détecter les anomalies. La carte est construite à partir de l’algorithme détectant les activités de la personne. La carte intègre aussi l’information concernant la vraisemblance permettant de distinguer les moments où la personne est entièrement ou partiellement visible. Dans le dernier chapitre, nous proposons d’autres perspectives pour le système. Nous pensons que ce système peut être utilisé avec d’autres objectifs que le maintien à domicile, comme différencier les personnes ou encore prévenir les troubles cognitifs et les risques d’hospitalisation. L’apport de ce travail de thèse se situe à la fois sur le plan méthodologique et technique. Sur le plan méthodologique, la particularité de ce travail est qu’il est guidé par l’approche expérimentale. Les différentes décisions ont été prises avec l’objectif de développer un système correspondant au « réalisme du terrain », qui une fois construit, pourrait être expérimenté au domicile des personnes 63. Approche proposée âgées. Cette nécessité de développer des approches expérimentées et évaluées, au regard des contraintes particulières que pose l’environnement d’une personne âgée, a eu des répercussions sur le plan technique et sur les choix pris pour concevoir le système. L’objectif visé était de construire un système simple en vue des expérimentations futures. Nous montrons donc qu’en utilisant des indicateurs simples, que sont la trajectoire du centre de masse de la personne et la distribution verticale des points de sa silhouette, extraits à partir d’algorithmes utilisés en vision, il est possible de créer un système à haut pouvoir de décision. A partir de ces deux indicateurs, il est possible de sécuriser la personne dans son environnement, en détectant ses chutes et ses comportements dangereux, et d’évaluer son degré de fragilité en analysant sa marche et ses activités. 78Première partie Approches pour la mesure de la fragilité et la détection des chutes 9Introduction Nous avons posé les objectifs de ce travail, à savoir développer un système permettant de détecter les chutes et de mesurer le degré de fragilité d’une personne. Dans cette première partie, nous recensons les différentes approches existantes pour traiter ces deux questions. Les systèmes détectant la chute et analysant la fragilité des personnes sont souvent conçus pour résoudre l’un ou l’autre des deux problèmes. C’est pourquoi, nous avons construit l’état de l’art en deux chapitres. Le premier chapitre présente les différentes approches pour évaluer le degré de fragilité d’une personne. Les dispositifs, décrits dans ce chapitre, sont des dispositifs utilisés dans le milieu mé- dical. Les médecins analysent la fragilité, notamment, à travers les paramètres de la marche et leur évolution. Certaines modifications sont facilement perceptibles à l’œil. Les tests cliniques peuvent alors être suffisants. Les tests cliniques sont les premiers outils des médecins pour analyser l’état général de la marche d’une personne. D’autres modifications de la marche requièrent des instruments de mesure, comme c’est souvent le cas pour évaluer les progrès réalisés en rééducation. Nous retrouvons des systèmes avec capteurs ou sans capteurs portés par la personne. Dans la catégorie des capteurs portés, les dispositifs sont nombreux, allant du simple accéléromètre au capteur plus évolué comme l’électromyographie, en passant par des systèmes de chaussures équipées de capteurs de pression ou encore des systèmes de caméras avec capteurs portés par les personnes. Les dispositifs, dans la catégorie des systèmes sans capteurs portés, sont les tapis roulants, les tapis actimètriques, ou encore les plateformes de force. Dans un deuxième chapitre, nous recensons les systèmes utilisés pour détecter la chute des personnes au domicile. Le découpage à l’intérieur de ce chapitre est effectué selon le type de capteurs utilisé : capteurs embarqués portés par la personne ou capteurs ambiants. Dans la catégorie des systèmes embarqués sur la personne, nous citons les capteurs tels que les accéléromètres ou les goniomètres. Concernant les systèmes ambiants, nous citons les capteurs environnementaux, comme les capteurs infrarouges de mouvement ou les détecteurs d’ouverture. Les systèmes à base de caméra appartiennent également à cette catégorie. Et enfin, plus récemment, des dispositifs placés au sol apparaissent. Chaque système décrit a plus ou moins d’avantages et d’inconvénients par rapport à ce que nous souhaitons développer. Les systèmes adaptés uniquement à une utilisation en cabinet médical (les systèmes à base de capteurs embarqués), fournissant peu d’information (comme les accéléromètres) ou encore ayant un prix élevé, ne correspondent pas à nos objectifs. 11Introduction 12Chapitre 1 Panorama des approches pour l’analyse de la fragilité à l’hôpital Sommaire 1.1 L’œil expert à travers les tests cliniques . . . . . . . . . . . . . . 13 1.2 Outils d’analyse du mouvement . . . . . . . . . . . . . . . . . . . 14 1.2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . . . 14 1.2.2 Systèmes sans capteur embarqué sur la personne . . . . . . . . . . . 16 1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 La fragilité des personnes est évaluée essentiellement par le corps médical à travers une analyse de leurs capacités motrices. Les médecins analysent la marche des personnes à travers des tests cliniques. Ils peuvent, également, utiliser des outils de mesure pour quantifier la marche. 1.1 L’œil expert à travers les tests cliniques L’analyse de la marche à travers l’œil humain est une méthode souvent utilisée dans le monde médical, car peu coûteuse. Les médecins observent une éventuelle pathologie ou fragilité chez les personnes âgées en s’aidant d’outils tels que la vidéo, le chronomètre, le mètre et les tests cliniques. De nombreux tests ont été mis en place pour aider l’évaluation faite par le médecin. Aucun consensus n’a été posé sur le choix des tests à effectuer. Le médecin peut donc choisir parmi un large échantillon de test. La liste suivante n’est pas exhaustive, mais elle permet de citer quelques tests couramment utilisés durant la consultation des patients en cabinet : — le test des « dix mètres de marche » où le médecin calcule le nombre de pas et/ou chronomètre le temps pour faire cette tâche ; — le test « up and go » où le médecin calcule le temps mis par la personne pour s’asseoir, se lever, marcher sur 3 m et revenir s’asseoir ; — le test de « durée de l’appui unipodal » où le médecin calcule le temps durant lequel la personne tient l’équilibre sur un pied sans se tenir ; — le test de la « vitesse de marche confortable » où le médecin calcule la vitesse du patient marchant « normalement » ; — le test de « Tinetti » permettant, à l’aide d’un questionnaire et de petits exercices, de juger de la qualité de la marche et de l’équilibre. 13Chapitre 1. Panorama des approches pour l’analyse de la fragilité à l’hôpital Figure 1.1 – Représentation de la marche humaine en diagramme bâton par Marey. Ces tests permettent de fournir une évaluation de la qualité de la marche et de l’équilibre de la personne pour ainsi évaluer son état. Chaque médecin peut avoir un regard différent sur les résultats. Pour pallier au manque d’objectivité, d’autres techniques existent. 1.2 Outils d’analyse du mouvement Les systèmes de mesure du mouvement sont utilisés dans divers domaines et pour divers objectifs. Ils peuvent être utilisés : — pour étudier la marche (normale ou pathologique) de la personne dans le domaine médical ou biomécanique ; — pour analyser le corps en activité dans le domaine du sport ; — pour étudier l’influence de différents dispositifs sur la marche en ergonomie ; — pour analyser la marche humanoïde dans le but de la comprendre et la reproduire dans le cadre de la robotique ; — pour simuler la marche et l’intégrer dans des personnages virtuels dans le domaine de l’animation et la simulation de synthèse. L’objectif commun des différents domaines est de quantifier la marche, de l’analyser dans un contexte spatio-temporel. Dès la renaissance, le sujet intéresse les scientifiques. Léonard de Vinci, Galilée et Newton analysaient déjà la marche. Mais le premier instrument de mesure naquit avec l’apparition de la chronophotographie. Cette technique consiste à prendre des photographies lors d’un mouvement pour le décomposer et le représenter sous la forme d’un diagramme de bâton comme illustré par la figure 1.1 [Marey, 1894]. En 1878 Eadweard Muybridge et en 1882 Étienne-Jules Marey utilisèrent les premiers cette technique. Muybridge analysa le mouvement du cheval et Marey le mouvement de l’oiseau en vol. Ces travaux ont constitué les prémisses du développement de nombreux outils de mesure du mouvement humain. Aujourd’hui, il existe de nombreux systèmes pour mesurer le mouvement. Nous les séparons en deux catégories : les systèmes nécessitant de placer des capteurs sur la personne et ceux sans capteurs embarqués. 1.2.1 Systèmes avec capteurs embarqués sur la personne Différents capteurs, à poser sur le corps de la personne, existent permettant de fournir plus ou moins d’indications sur la marche. Le capteur de plus bas niveau, car apportant peu d’information, est le podomètre, comptant simplement le nombre de pas effectués par la personne lorsqu’elle marche. Cet outil peut être utile également, en dehors du cabinet du médecin, pour mener des recherches. Par exemple, en 2002 Silva et al. [Silva et al., 2002] ont réalisé une étude 141.2. Outils d’analyse du mouvement Figure 1.2 – Le système Walkmeterc est inspiré du locomètre de Bessou. sur le nombre de pas par an effectués par des personnes et ont cherché des spécificités selon la catégorie de personne (homme, femme, personne obèse, etc.). Les capteurs de mouvements (les capteurs infrarouges passifs) fournissent également un seul indicateur qui est la vitesse de marche. Un exemple d’utilisation peut être donné avec l’étude en 2010 réalisée par Hagler et al. [Hagler et al., 2010]. Ils ont eu l’idée d’installer 4 capteurs infrarouges (PIR) au plafond du domicile des personnes âgées. Le but était d’observer un éventuel déclin à travers la vitesse de la marche et ainsi poursuivre l’analyse en dehors du cabinet du médecin . Le locomètre de Bessou est l’instrument représenté à la figure 1.2. Il est composé d’une boite de laquelle deux câbles sortent, pour être attachés aux deux talons. Ainsi, ce système fournit la mesure des déplacements longitudinaux des câbles. Plusieurs paramètres de la marche en sont déduits comme la longueur des pas, la fréquence du pas, la durée des appuis, etc. Ce système est limité par la longueur des câbles. Un exemple d’utilisation pour les personnes hémiplégiques est présenté dans l’article de Condouret et al. en 1987 [Condouret et al., 1987]. Il existe également des chaussures munies de capteurs de pression permettant de récupérer les positions spatio-temporelles des pieds. A partir de ces positions, des valeurs telles que la vitesse de marche, les longueurs de pas peuvent être calculées. Les accéléromètres, les gyroscopes ou les goniomètres ([Bourke et al., 2007], [Wu, 2000]) sont des capteurs posés sur la jambe de la personne. Ils permettent d’analyser la marche et plus précisément l’accélération du corps ou l’angle des différents segments de la jambe lors de la marche. Ces systèmes sont posés sur les parties molles de la jambe donc il est nécessaire de vérifier qu’ils ne bougent pas au cours de la séance. De plus, le positionnement de ces capteurs varie selon la personne qui les pose. Les systèmes optoélectroniques à marqueurs actifs s’insèrent dans cette catégorie (comme le système Selspot). La personne marche dans le champ de vision des caméras qui captent la lumière émise par les capteurs, posés sur la personne à différents endroits du corps. Cette technique permet d’obtenir très précisément les trajectoires spatiales et ainsi d’en déduire un certain nombre de paramètres comme les longueurs de pas, les angles des différents segments du corps, etc. Chaque capteur est alimenté par un câble, ce qui limite les déplacements de la personne. Il existe également des systèmes optoélectroniques à marqueurs passifs permettant aux capteurs de ne plus être reliés à des câbles d’alimentation. Les systèmes Vicon et Qualisys, par exemple, sont 15Chapitre 1. Panorama des approches pour l’analyse de la fragilité à l’hôpital des systèmes à marqueurs passifs. Ces systèmes consistent à positionner, en certains points clés du corps, des marqueurs réfléchissant un signal infrarouge émis par les caméras. Ainsi, la position 3D des différentes parties du corps est évaluée et permet, tout comme les systèmes à marqueurs actifs, de calculer les longueurs de pas, les durées, les angles entre les segments, etc. Les systèmes optoélectroniques restent des systèmes assez contraignants et coûteux. A chaque nouvelle installation du système, une phase de calibration est nécessaire pour définir un repère commun entre toutes les caméras et les renseigner sur leur position les unes par rapport aux autres. Comme tout système à capteurs embarqués, le positionnement des capteurs reste dépendant de leur pose et peut bouger au cours de la marche. De plus, certains capteurs peuvent durant la marche être occultés par les segments corporels. Pour analyser correctement le mouvement de la personne, six caméras au minimum sont généralement nécessaires. Ces dispositifs sont toutefois très utilisés dans différents secteurs, notamment en milieu hospitalier, pour la simulation de personnages virtuels, pour le sport, pour la biomécanique, etc. L’électromyographie (EMG) est un système permettant d’enregistrer l’activité électrique musculaire en positionnant des électrodes sur le corps ou à l’intérieur du corps sur les muscles à étudier. Cette technique est assez controversée, car l’activité électrique enregistrée peut provenir de l’activité de muscles voisins et non pas de celui que l’on cherche à analyser. 1.2.2 Systèmes sans capteur embarqué sur la personne Des systèmes sans capteurs embarqués sur la personne peuvent également être utilisés, la laissant libre lors de ses mouvements. Les plates-formes de force sont des outils sans capteurs embarqués sur la personne. Ces systèmes sont composés d’une simple plateforme (d’environ 60*60 cm) placée sur le parcours de marche. Ils permettent de mesurer les forces appliquées par le pied sur la plateforme lors de la marche. Les tapis roulants instrumentés (figure 1.3) constituent également des systèmes permettant d’analyser la marche. Ils sont constitués de plateformes de force. L’avantage, comparé à la simple plateforme de force, est que le tapis analyse un grand nombre de pas successifs. La personne marche au rythme imposé par le tapis. La vitesse de marche de la personne n’est donc pas naturelle et ne peut pas être prise en compte pour juger de la qualité de la marche. D’autres paramètres comme la longueur de pas et les forces du pied sur le tapis peuvent être analysés. Les tapis actimètriques (figure 1.4) permettent également d’enregistrer la pression plantaire exercée par le pied sur le tapis. La force appliquée par le pied est alors calculée, permettant de déduire des paramètres tels que la longueur de pas, la vitesse de marche, etc. Ce système laisse la personne libre de marcher mais il est limité par sa taille. Ce genre de tapis n’excède pas les 6 m de long. 1.3 Conclusion Le milieu hospitalier est le premier endroit où l’on retrouve des systèmes analysant le mouvement des personnes dans le but d’évaluer le degré de fragilité d’une personne. La plupart de ces outils sont coûteux et nécessitent une expertise technique forte pour leur mise en œuvre. C’est pourquoi, chaque institut développe ses propres protocoles d’analyse, suivant les outils qu’ils ont à leur disposition. 161.3. Conclusion Figure 1.3 – Le tapis roulant instrumenté de la société Biometrics. Figure 1.4 – Le tapis actimètrique de la marque GaitRite. 17Chapitre 1. Panorama des approches pour l’analyse de la fragilité à l’hôpital 18Chapitre 2 Panorama des systèmes de détection de chutes au domicile Sommaire 2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . 19 2.1.1 Détecteurs de chutes automatiques . . . . . . . . . . . . . . . . . . 19 2.1.2 Systèmes d’alerte manuels . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Systèmes ambiants . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 Capteurs environnementaux : la télé-assistance . . . . . . . . . . . . 21 2.2.2 Systèmes à base de caméra : la vidéo-vigilance . . . . . . . . . . . . 22 2.2.3 Capteurs au sol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Nous présentons dans ce chapitre les dispositifs existants pour détecter les chutes d’une personne. Le marché des systèmes de détection de chutes est un marché grandissant, principalement destiné à la surveillance au domicile des personnes. En recherche, le sujet de la détection de chutes est également très étudié. Nous avons regroupé les capteurs permettant de détecter les chutes en deux catégories, d’un côté les systèmes utilisant des capteurs à poser sur la personne et de l’autre les systèmes de capteurs ambiants. 2.1 Systèmes avec capteurs embarqués sur la personne La première catégorie regroupe les systèmes à base de capteurs portés sur la personne. L’avantage de ces dispositifs est que bien souvent ils peuvent fonctionner à domicile et à l’extérieur. 2.1.1 Détecteurs de chutes automatiques Les accéléromètres, les gyroscopes et les goniomètres sont des capteurs pouvant servir à détecter automatiquement les chutes des personnes âgées. Dans le domaine de la recherche, certains auteurs, comme Bourke et al. [Bourke et al., 2007] et Wu [Wu, 2000], les ont d’ailleurs utilisés avec l’objectif de tester leur efficacité à détecter les chutes. Leur idée était de positionner ces capteurs sur la personne et d’observer la vitesse de mouvement du corps lorsque la personne réalisait différentes activités. L’hypothèse est que la vitesse est différente quand une personne chute, en comparaison à d’autres activités comme s’asseoir ou s’allonger dans un canapé. 19Chapitre 2. Panorama des systèmes de détection de chutes au domicile Figure 2.1 – Système d’alerte de Vitalbase. Ces capteurs ont été évalués en recherche et aujourd’hui, dans le commerce, certains dispositifs intègrent ce genre de capteurs. Des industriels, tels que Telecom Design avec VitalBase, intègrent un accéléromètre dans un dispositif à positionner au niveau de la ceinture ou au poignet comme le montre la figure 2.1. Ce système permet de détecter la chute à travers la perte de verticalité, l’accélération, le choc de la chute et enfin l’absence de mouvement. Les chutes brutales peuvent être détectées mais pas les chutes molles. Pour éviter les fausses alarmes, une phase de vérification est intégrée au système. Lorsqu’une chute est détectée, le système se met à vibrer durant 26 secondes et la personne doit, durant cette période, réaliser un mouvement ample du bras. Ce geste permet de bloquer l’envoi de l’alerte. Le téléphone portable de l’entreprise suédoise Doro intègre également un accéléromètre. Ce téléphone détecte la chute à travers la perte de verticalité. Ce système de détection de chute doit être activé par la personne lorsqu’elle pense en avoir besoin, par exemple lorsqu’elle se retrouve seule dans son appartement. La société Vigilio a mis en place un dispositif, détectant les chutes, à base d’un capteur accéléromètrique à porter sur le torse de la personne (figure 2.2(a)). En cas de chute ou d’immobilisation prolongée (dans le cas des chutes molles par exemple), leur boitier (figure 2.2(b)) directement connecté à une ligne téléphonique pourra alerter automatiquement un numéro qui a été pré-enregistré. (a) Capteur accéléromètrique à porter sur le torse. (b) Boitier d’alerte. Figure 2.2 – Système de détection de chute de la société Vigilio. D’autres capteurs peuvent également être utilisés notamment des capteurs sensoriels pouvant détecter la perte de conscience des personnes. La société Vivago a intégré ces capteurs dans une montre. L’idée est de détecter la chute des personnes due à un malaise. En utilisant ces capteurs couplés aux capteurs de température cutanée, l’entreprise a mis au point un système de détection de l’état d’inconscience des personnes et d’alerte des secours. 202.2. Systèmes ambiants 2.1.2 Systèmes d’alerte manuels Dans le commerce, il existe également des systèmes ne détectant pas automatiquement la chute. Ces systèmes requièrent la participation de la personne. Les boutons d’alarmes, existant sous forme de collier ou bracelet à porter sur soi, jour et nuit, permettent à la personne d’appuyer dessus pour alerter d’une chute. La marque Intervox du groupe Legrand ou encore le groupe Biotel-Tunstall développent, entre autres, des médaillons à porter par la personne. L’idée est d’éviter les fausses alarmes et de permettre à la personne de se sentir rassurée d’avoir à tout moment un dispositif d’alerte. Ces dispositifs doivent être portés pour fonctionner. C’est la cause principale de leur manque d’efficacité, car les personnes ne les portent pas, soit parce qu’ils sont perçus comme stigmatisants soit parce que la personne oublie tout simplement de les porter. Des études ont aussi montré que ces dispositifs pouvait être inefficaces, même lorsqu’ils sont portés, car les personnes ne les utilisent pas forcément après une chute. Dans l’article de Wild et al. [Wild et al., 1981], les auteurs ont mené une étude sur les personnes âgées de plus de 65 ans durant un an. Dans cette expérience, ils ont formé deux groupes, un groupe de « chuteurs » (constitué de personnes ayant déjà chuté une fois) et un groupe contrôle. Parmi les neuf chuteurs ayant un système d’alerte, seulement deux ont réussi à l’utiliser pour alerter après être tombés, l’un a tenté mais n’a pas réussi à l’utiliser et les six derniers n’ont même pas tenté de l’utiliser. L’incapacité d’appuyer sur le bouton peut être due à la perte de connaissance de la personne ou à son état de choc. 2.2 Systèmes ambiants Cette catégorie de dispositif, basée sur des capteurs ambiants, ne fonctionne qu’à l’intérieur. Ces systèmes ont l’avantage de fonctionner automatiquement sans que la personne n’ait besoin de le déclencher. 2.2.1 Capteurs environnementaux : la télé-assistance Les capteurs environnementaux permettent de rendre compte de l’activité d’une personne dans son lieu de vie. On peut compter le nombre de fois où la personne ouvre le réfrigérateur, le nombre de fois où elle s’est assise, etc. Ces différentes informations permettent d’en déduire l’activité d’une personne. Par exemple, les capteurs peuvent indiquer qu’une personne est inactive depuis longtemps ce qui révèle un comportement anormal. Différents capteurs peuvent être utilisés. Les capteurs infrarouges de mouvement informent de la présence ou non d’une personne dans une pièce. Ainsi, il est possible de s’assurer que la personne est sortie de sa chambre au cours de la journée par exemple. Des détecteurs d’ouverture, posés dans des endroits tels que le réfrigérateur ou le robinet, permettent de s’assurer de l’utilisation des différents points d’intérêts. La marque Intervox propose toute une gamme de capteurs parmi lesquels figurent les capteurs de mouvements et d’ouverture. Le but est de définir des tranches horaires où la personne doit être aperçue dans telle pièce ou doit ouvrir tel point d’intérêt. En cas de non conformité avec les événements prédéfinis, une alerte est déclenchée. Senioralerte utilise également ce genre de capteurs (détecteurs de présence, d’ouverture, etc.). L’objectif de cette entreprise est d’apprendre les habitudes des personnes au cours du temps pour déceler des activités anormales. Ces systèmes, en cas de détection d’un éventuel problème, déclenchent une alerte qui sera envoyée aux proches ou à une assistance s’assurant auprès de la personne qu’un réel problème 21Chapitre 2. Panorama des systèmes de détection de chutes au domicile est apparu avant d’appeler les urgences. 2.2.2 Systèmes à base de caméra : la vidéo-vigilance Les systèmes à base de caméra sont plus intrusifs dans la conscience des gens que les capteurs environnementaux mais ils permettent d’obtenir plus d’informations. Notamment, même si certains capteurs peuvent déduire, suite à un ensemble d’événements, qu’une chute s’est produite, ils ne peuvent pas réellement l’identifier comme telle. Les systèmes à base de caméra peuvent intégrer des algorithmes analysant l’activité d’une personne et surtout des algorithmes détectant la chute, avec beaucoup plus de discernement que ne peuvent le faire les détecteurs classiques. Peu de systèmes de vidéo-vigilance sont commercialisés. En France, le système EDAO propose d’installer des caméras à domicile pour détecter les chutes des personnes en perte d’autonomie. Ce système semi-automatisé détecte des situations à risque (grâce à des algorithmes d’analyse) et prévient un opérateur qui, en visionnant les images, alerte ou non la famille ou les secours. Le sujet de la détection de l’activité et des chutes reste un sujet de recherche. Le but est de dé- velopper des algorithmes d’analyse de l’activité toujours plus performants, ne commettant aucune fausse alarme et détectant chaque situation de chute ([Jansen et al., 2007], [Rougier et al., 2011], [Nait-Charif and McKenna, 2004], [Auvinet et al., 2011b], [Anderson et al., 2009]). 2.2.3 Capteurs au sol L’intérêt de ces capteurs est qu’ils sont dissimulés, les personnes âgées peuvent donc les oublier plus facilement et ne pas se sentir surveillées en permanence. Le principe de ces capteurs posés au sol est qu’ils détectent les pressions plantaires exercées par les personnes. Ainsi, les algorithmes développés peuvent déduire certaines informations, savoir dans quelle pièce se trouve la personne au cours de la journée, s’assurer qu’elle ne soit pas allongée au sol, etc. En recherche, la thématique des sols « intelligents» commence à se développer. Rimminen et al. ([Rimminen et al., 2009], [Rimminen et al., 2010]) décrivent dans leurs deux articles une technique pour suivre la personne (en utilisant entre autres un filtre de Kalman) puis pour détecter les chutes (en utilisant notamment des chaines de Markov). Un appartement construit au sein d’INRIA à Nancy a été recouvert d’un réseau de capteurs au sol ([Pepin et al., 2009]). Le sol est composé de dalles, mesurant 60×60 cm, qui ont été construites sur mesure. 100 dalles ont été installées dans cet appartement comme le montre la figure 2.3(a). Chaque dalle est équipée d’un accéléromètre, d’un magnétomètre et de quatre jauges de contraintes (des capteurs de force) positionnées à chaque angle comme précisé à la figure 2.3(b). Les dalles peuvent envoyer un message par le réseau ZigBee à d’autres dalles. L’un des objectifs, comme dans le travail de Rimminen, est de pouvoir détecter la chute des personnes parmi d’autres activités de la vie quotidienne. Rimminen travaille sur un sol instrumenté fondé sur la mesure du champ électrique. Un certain nombre de dispositifs commerciaux commencent à voir le jour. Pour n’en citer que quelques uns, nous pouvons mentionner les dispositifs proposés par Tarkett, Elsi et le SensFloor de la société Futur-Shape. Ces systèmes sont encore un peu coûteux et sont réservés à des installations dans les établissements d’hébergement pour personnes âgées dépendantes (EHPAD) ou dans des constructions neuves. 2.3 Conclusion Les systèmes qui sont actuellement installés au domicile des personnes âgées détectent la chute ou les situations à risque. En dehors des boutons d’alerte, les systèmes de détection restent 222.3. Conclusion (a) Appartement avec un réseau de dalles au sol. (b) Dessous d’une dalle. Figure 2.3 – Système d’analyse du mouvement par le sol d’INRIA à Nancy. peu courants. 23Chapitre 2. Panorama des systèmes de détection de chutes au domicile 24Conclusion Dans cette partie, nous avons présenté un panorama des systèmes existant pour analyser la fragilité d’une personne et détecter sa chute. Ces deux fonctionnalités nous sont utiles pour développer un système de maintien des personnes âgées au domicile. Les approches pour évaluer le degré de fragilité d’une personne sont surtout développées en hôpital ou en laboratoire. L’évaluation de la fragilité est réalisée à travers l’analyse de la marche. Les tests cliniques sont la méthode la plus simple à mettre en place et donc la plus répandue dans le milieu hospitalier. Les systèmes avec capteurs embarqués et sans capteurs embarqués peuvent être des techniques assez coûteuses et encombrantes mais plus précises que les tests cliniques pour quantifier le mouvement. Ces dispositifs ne correspondent pas à nos objectifs puisqu’ils ne sont pas adaptés pour être utilisés au domicile des personnes âgées dans le cadre d’un usage quotidien. Les systèmes détectant la chute sont principalement conçus pour le domicile. Des capteurs à porter sur soi, comme des boutons d’alerte ou des bracelets détectant automatiquement la chute, existent mais sont peu utilisés, car ils sont stigmatisants pour les personnes. Des capteurs ambiants comme les capteurs environnementaux, les caméras ou les capteurs au sol sont conçus pour détecter automatiquement la chute au domicile. 25Conclusion 26Deuxième partie Algorithmes pour l’évaluation et la sécurisation au domicile 27Introduction Nous développons dans cette partie les différents algorithmes et modèles que nous avons conçus pour suivre une personne dans le temps et l’espace, analyser son activité et sa marche. Nous exposons tout d’abord une vision globale du système proposé. 1 Vision générale Nous exposons, ici, la vision que nous proposons d’un système pour favoriser le maintien à domicile des personnes âgées. L’architecture générale du dispositif est résumée par le schéma 3. L’objectif global est de sécuriser et d’évaluer la fragilité de la personne au quotidien à son domicile. Pour cela, nous prévoyons d’installer, dans chaque pièce de la maison, un capteur 3D couplé à un mini ordinateur de façon à traiter les données au domicile et ne pas transmettre d’images. Nous avons donc opté pour des algorithmes et modèles légers, ne nécessitant pas de gros calculs pour qu’ils puissent être implémentés dans des mini ordinateurs à bas coût et fonctionner en temps réel. A chaque information reçue du capteur, les algorithmes analysent la scène en détectant la personne et ses activités. Nous voulons identifier des activités de la vie quotidienne telles que s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, et des situations particulières comme chuter et être allongé au sol. Ainsi, à la fin de chaque journée, un bilan du temps d’activité et d’inactivité pourra être fait. Cet indicateur de l’évolution de la fragilité de la personne sera couplé à l’évaluation de l’évolution de sa marche. Les observations sur l’activité et la marche de la personne seront envoyées, selon le protocole de suivi, au médecin, à la famille et à la personne elle-même pour ainsi évaluer l’évolution jour après jour de son état. Le médecin pourra alors coupler ces informations avec les différents tests qu’il effectuera durant les consultations pour affiner son évaluation de la fragilité de la personne. D’une manière plus générale, le système pourrait apprendre les habitudes des personnes, comme l’heure à laquelle elle se réveille ou la vitesse à laquelle la personne marche. Ainsi, les changements d’habitudes pourront être utilisés comme des indicateurs de l’évolution de l’état général de la personne. La deuxième fonctionnalité du système serait de sécuriser la personne en alertant les secours en cas de chute. Le système pourrait également prévenir la famille en cas de détection de situations à risque telles que monter sur une chaise et s’accroupir, qui sont des activités pouvant conduire à une chute. 2 Choix des capteurs Dans l’introduction de ce mémoire, nous avons indiqué quelques contraintes à prendre en compte dans le développement de notre système, notamment, il doit être réaliste par son coût et reposer sur des capteurs ambiants pour ne pas perturber la personne. Les systèmes avec capteurs embarqués sur la personne, tels que les accéléromètres, n’ont donc pas été retenus. Les capteurs 29Introduction 500 550 600 650 700 750 800 850 900 950 1000 33.5 34 34.5 35 35.5 36 36.5 37 37.5 Y (mm) Temps (s) Walking Salle Chambre Salle de bains Cuisine Ambulance Figure 3 – Vision pour la conception d’un système permettant le maintien à domicile des personnes âgées. au sol ne sont également pas retenus, car, aujourd’hui, ils n’apportent pas encore de solution facile à adopter dans un environnement déjà existant. Les capteurs environnementaux et les caméras correspondent au besoin. Il est possible d’installer un réseau de capteurs environnementaux au domicile de la personne sans la gêner et avec un coût peu élevé. Mais l’information sortant de ces capteurs est insuffisante pour ce que nous voulons faire. Ils permettent de détecter un grand nombre d’événements, comme l’heure à laquelle la personne a ouvert le réfrigérateur ou le nombre de fois où elle s’est levée de son fauteuil. Nous ne pouvons pas, en revanche, avoir d’information sur la qualité de sa marche. De plus, ces capteurs ne peuvent pas différencier les personnes. Ils ne peuvent pas savoir si la personne ouvrant le robinet est la personne à suivre, le conjoint, les visiteurs ou encore le personnel soignant. Nous avons donc opté pour des caméras permettant, comme nous allons le montrer, aussi bien de détecter l’activité de la personne que d’analyser le degré de fragilité à travers l’évolution de sa marche. Les caméras RGB-Depth de Microsoft (les caméras Kinect) ont été choisies, car elles permettent de fournir une information de profondeur pour chaque objet en plus de l’image couleur. De plus, elles se trouvent facilement dans le commerce, sont à bas coût et fonctionnent la nuit. 3 Conception des algorithmes La détection d’activité et l’analyse de la marche, à l’aide de caméras, nécessitent de concevoir au préalable un modèle d’extraction des personnes efficace et fiable. Les pixels extraits doivent ensuite être représentés sous une forme compacte permettant de suivre l’évolution dans l’image de la personne. Suivre une personne au cours du temps soulève plusieurs questions. 30— Sous quelle forme représenter l’objet d’intérêt pour qu’il soit reconnu dans toutes les situations ? — A partir de quelles caractéristiques obtenir la représentation de l’objet ? — Comment extraire le ou les objets d’intérêts dans la scène ? — Quelle méthode est adaptée pour suivre l’objet au cours du temps ? Dans le premier chapitre, nous présentons les méthodes utilisées pour traiter un flux vidéo. De nombreux articles traitent de la question du suivi d’objets (Object tracking en anglais) dans une vidéo. La liste des méthodes, que nous présentons dans ce chapitre, n’est donc pas exhaustive. Nous nous concentrons sur les méthodes permettant de détecter et suivre une personne au domicile. Suivre une personne dans une scène au cours du temps est un défi, car cela soulève de nombreux problèmes. Les difficultés rencontrées peuvent être dues à ses mouvements, à ses changements d’apparence (changement d’habit par exemple), à sa propriété non rigide (une personne est différente assise ou debout), aux changements de la scène (une chaise qui a bougé), aux occlusions pouvant cacher partiellement ou totalement la personne ou encore aux mouvements de la caméra. Dans ce premier chapitre, nous présentons la particularité de la caméra que nous utilisons. Les méthodes en vision ont été construites pour des caméras couleur classiques. L’apparition de la caméra fournissant une information de profondeur permet de faciliter un certain nombre de traitements qui auparavant étaient moins robustes. Dans le deuxième chapitre, nous présentons les méthodes que nous avons implémentées pour détecter et suivre une personne. Nous présentons, tout d’abord, la méthode de soustraction du fond que nous avons identifiée comme peu coûteuse en temps de calcul et robuste si elle est faite à partir de l’image de profondeur renvoyée par la caméra. Puis, nous montrons qu’à travers cinq caractéristiques, extraites des images de profondeur, nous pouvons représenter une personne et la suivre au cours du temps. Ces cinq caractéristiques sont : le centre de masse, la vitesse verticale, la vitesse horizontale, la dispersion verticale et le point maximum. Ces caractéristiques ont été choisies, car elles sont faciles à extraire et peuvent être suivies en temps réel. Dans le troisième chapitre, nous abordons l’algorithme permettant l’analyse de la marche d’une personne. L’idée est d’observer au cours du temps les paramètres de la marche d’une personne, comme indicateur de l’évolution de sa fragilité. Dans un premier temps, nous allons définir et décrire la marche. Nous verrons, entre autres, les différentes phases qui caractérisent la marche humaine et les indicateurs permettant de l’analyser. Nous verrons comment une analyse de différents paramètres spatio-temporels (longueurs de pas, vitesse de marche, etc.), cinématiques (angles formés par les différentes parties du corps) et dynamiques (les forces de réaction du pied, etc.) permet de révéler en grande partie les capacités physiques d’une personne. Pour notre étude nous nous sommes restreint à la seule mesure des paramètres spatio-temporels. Pour extraire ces paramètres, nous nous basons sur le centre de masse de la personne et sur la détection des maxima locaux sur l’axe vertical. La précision des paramètres de la marche est évaluée au chapitre 7 de la prochaine partie. Le quatrième chapitre est consacré au développement d’un algorithme détectant l’activité d’une personne. Nous avons vu en introduction, l’importance de détecter au plus vite les chutes, pour éviter à la personne de rester au sol trop longtemps et pour diminuer le risque de séquelles physiques et psychologiques. La personne peut avoir peur de rechuter et, ainsi, minimise ses activités. En ce sens, la chute peut accélérer la perte d’autonomie. Cet axe de recherche a donc un double objectif. Il permet, d’un côté, de sécuriser la personne en détectant les chutes et les activités à risque, comme monter sur une chaise. Et, d’un autre côté, il permet d’évaluer le degré de fragilité de la personne et de prévenir la perte d’autonomie en détectant les comportements inhabituels, comme l’immobilité prolongée. Pour détecter l’activité d’une personne, nous avons choisi d’utiliser le formalisme des modèles de Markov cachés (MMC). Ce sont des modèles qui 31Introduction permettent d’estimer un état caché à partir d’une séquence d’observations. Nous les définissons plus largement en annexe A. Parmi les nombreuses méthodes de la littérature, les MMC ont été souvent utilisés dans le cas de la reconnaissance d’activité. Les taux de reconnaissance d’activité sont très importants avec ce type de méthodes. Cependant, bien souvent, les algorithmes utilisent un grand nombre de caractéristiques pour déterminer l’état caché. Notre objectif est de construire des modèles de Markov cachés en prenant des caractéristiques simples à extraire et peu nombreuses, tout en conservant un bon niveau de classification des activités. Les caractéristiques, que nous prenons en compte, sont la position du centre de masse, la vitesse verticale et horizontale du centre de masse, la dispersion verticale de la silhouette et le point le plus haut du corps. Nous construisons plusieurs modèles pouvant tous correspondre à notre problème. Les différences entre les différents modèles portent sur le nombre d’activités que le modèle peut dé- tecter (entre 8 et 9) et sur le nombre de caractéristiques pris en compte (entre 3 et 5). Nous avons également construit des modèles où nous fixons à la main certains paramètres et d’autres n’ayant pas de connaissance a priori. Nous avons voulu construire plusieurs modèles pour dé- terminer si, en prenant un nombre restreint de caractéristiques, le modèle peut discriminer les activités correctement ou s’il est nécessaire d’ajouter des caractéristiques pour augmenter le taux de bonnes classifications. L’évaluation expérimentale des résultats est présentée au chapitre 8 de la partie III. 32Chapitre 3 Détecter et suivre une personne avec une caméra : état de l’art Sommaire 3.1 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . 33 3.1.1 Détecteur de points d’intérêt . . . . . . . . . . . . . . . . . . . . . . 34 3.1.2 Soustraction du fond . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.3 Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.4 Apprentissage supervisé . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 Suivi de la personne . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Modèles d’objets animés . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Suivi de l’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3 Caméra de profondeur . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Ce chapitre se base, entre autres, sur le livre de Russell et Norvig [Russell and Norvig, 2010] et sur une étude réalisée en 2006 par Alper Yilmaz et al. [Yilmaz et al., 2006] recensant et classifiant les différentes méthodes utilisées dans la littérature, pour détecter et suivre une personne. Toutes les méthodes en vision ne sont pas abordées dans ce chapitre. Cet état de l’art est centré sur l’extraction d’une personne d’une scène avec une caméra fixe localisée en intérieur. Les deux grandes étapes en « vision par ordinateur » sont développées dans deux sections séparées, dédiées à la détection d’objets animés et au suivi spatio-temporel de ces objets. Ensuite, nous abordons, dans une nouvelle section, la particularité du capteur de profondeur choisi qui, comme nous le verrons, simplifie fortement les traitements nécessaires à notre proposition. 3.1 Détection de la personne La difficulté ici est de détecter dans la scène, vue par la caméra, la présence ou l’absence d’objet d’intérêt (la personne). Bien souvent la détection requiert plusieurs images. L’utilisation de seulement deux images consécutives peut provoquer de fausses détections. Par exemple, l’algorithme peut considérer qu’il y a un objet mobile alors qu’il s’agit juste d’une variation de la luminosité ou d’une ombre sur les deux images. Dans l’état de l’art, plusieurs catégories de méthodes ont été proposées : 1. des méthodes détectant des points d’intérêts ; 33Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art 2. des méthodes d’extraction de fond ; 3. des méthodes de segmentation de l’image ; 4. des méthodes d’apprentissage supervisé. 3.1.1 Détecteur de points d’intérêt Le principe, ici, est de détecter des points d’intérêt dans l’image comme observé à la fi- gure 3.1(b). L’avantage de ces méthodes est qu’elles sont robustes aux changements de lumière et indépendantes du champ de vision de la caméra. Le principe repose sur l’extraction des parties saillantes des objets à partir des variations d’intensité. Le détecteur de Moravec [Moravec, 1979], le détecteur de Harris [Harris and Stephens, 1988] et le détecteur SIFT [Lowe, 2004] (Scaleinvariant feature transform) reposent sur ce principe. Ces détecteurs ont comme particularité d’être invariants aux mouvements de la caméra et des personnes. (a) Image d’origine. (b) Résultat du détecteur de Harris. Figure 3.1 – Détection des points d’intérêts dans une scène. 3.1.2 Soustraction du fond Les méthodes dans cette catégorie consistent à obtenir une représentation de la scène sur plusieurs images. Les objets mobiles recherchés sont détectés lorsque les images fournies par la caméra sont suffisamment différentes de la représentation du fond. Les méthodes fondées sur ce principe sont plus communément regroupées sous le terme de « soustraction de fond » et ont comme objectif de séparer les objets mobiles du fond. Deux méthodes sont couramment utilisées dans la littérature pour obtenir une représentation du fond, la méthode des moyennes mobiles (Running average en anglais) et le mélange de gaussiennes (Gaussian Mixture Model en anglais). Dans la méthode des moyennes mobiles, chaque valeur de pixel, la valeur correspondant à la couleur par exemple, est moyennée sur plusieurs images pour obtenir une représentation du fond. Les valeurs des pixels des nouvelles images sont alors comparées aux valeurs des pixels du fond appris pour identifier les pixels mobiles. Des cas d’utilisation peuvent être trouvés dans la littérature, notamment dans les articles de Jansen et al.[Jansen et al., 2007], de Gómez-Conde et al. [Gómez-Conde, 2011] et de Auvinet et al. [Auvinet et al., 2011b]. Dans la méthode de mélange de gaussiennes, la valeur de chaque pixel est modélisée par un mélange de gaussienne. Pour chaque pixel, les paramètres du modèle, 343.2. Suivi de la personne à savoir les moyennes et les variances, sont appris à partir des observations obtenues sur plusieurs images consécutives. Cette technique a été utilisée pour la première fois par Stauffer et al. [Stauffer and Grimson, 2000]. Une comparaison des deux techniques a été faite par Gómez-Conde et al. [Gómez-Conde, 2011]. La méthode des moyennes mobiles est plus facile à implémenter et moins gourmande en calcul. Mais dans leur article, ils ont remarqué que cette méthode est moins robuste aux changements de couleur que le mélange de gaussienne. 3.1.3 Segmentation La segmentation correspond au processus qui permet de découper l’image en régions de pixels similaires. Les pixels ont chacun des propriétés, par exemple une certaine couleur, luminosité et texture. Les pixels appartenant à un même objet ont des valeurs aux propriétés similaires. L’idée est de repérer les changements notables dans les valeurs prises par ses propriétés, pour ainsi découper l’image en région. Chaque région délimite les frontières entre les objets. Deux caté- gories de méthodes de segmentation existent, des méthodes détectant les frontières entre les objets [Martin et al., 2004] et des méthodes détectant les régions [Shi and Malik, 2000]. Quelle que soit la méthode utilisée pour segmenter, la sélection des propriétés pour réaliser le regroupement est à définir en amont. 3.1.4 Apprentissage supervisé L’idée est de regrouper en classe des échantillons aux caractéristiques similaires. Les nouveaux objets sont associés à la classe ayant les caractéristiques les plus proches. Le choix des caracté- ristiques est très important et doit permettre une bonne discrimination entre les classes. Cette méthode requiert un grand nombre d’exemples pour chaque classe. Pour classifier les objets, différentes méthodes d’apprentissage existent comme les réseaux de neurones [Rowley et al., 1998], adaptive boosting [Viola et al., 2003] (AdaBoost), les arbres de décision [Grewe and Kak, 1995] et SVM [Papageorgiou et al., 1998] (Support Vector Machines). 3.2 Suivi de la personne Après avoir localisé la personne dans la scène (grâce aux méthodes de la section précédente), l’étape suivante est de suivre sa position dans le temps et dans l’espace. Pour suivre une personne, la première et la deuxième question de l’introduction de cette partie doivent être résolues, à savoir, sous quelle forme la personne sera représentée pour être suivi et à partir de quelles caractéristiques récupérer cette représentation. Après avoir recensé les différentes façons de représenter l’objet d’intérêt, à savoir la personne, nous citerons quelques méthodes existantes pour le suivre selon la représentation choisie. 3.2.1 Modèles d’objets animés Différentes représentations Nous nous intéressons à la personne mais pour cette section, nous nous plaçons dans le cadre plus général de la représentation des objets. Les différentes manières de représenter l’objet d’intérêt peuvent être regroupées en deux catégories : les représentations fondées d’une part sur la forme de l’objet et, d’autre part, sur son apparence. 35Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art Concernant les représentations par rapport à la forme de la personne, certains auteurs la suivent à travers la silhouette (figure 3.2(a)) et les contours(figure 3.2(b)). La silhouette représentant la région à l’intérieur des contours. Le corps peut être représenté par des points (figure 3.2(c)) ou même par un seul point (figure 3.2(d)), par exemple, par le centre géométrique de la personne [Rougier et al., 2011]. Pour représenter la personne, certains l’englobent dans une forme géométrique primitive, comme une ellipse (figure 3.2(e)) ou un rectangle (figure 3.2(f)), couramment appelée un « blob ». Anderson [Anderson et al., 2006], Jansen et al. [Jansen et al., 2007] et Auvinet et al. [Auvinet et al., 2011b] utilisent des blobs pour représenter la totalité du corps humain. D’autres techniques existent permettant de représenter plus finement le corps en distinguant les différentes parties telles que le torse, les jambes, les bras, la tête ou les pieds (fi- gure 3.2(g)). Chaque partie du corps peut être modélisée à travers un cylindre ou une ellipse, comme Rougier et al. qui entourent la tête [Rougier and Meunier, 2010] et Deeb et al. qui s’inté- ressent à la tête et aux pieds [Deeb et al., 2012]. Une dernière méthode de représentation, fondée sur la forme du corps, est fondée sur l’extraction du squelette (figure 3.2(h)). Par exemple, Zhen-Peng Bian et al. [Bian et al., 2012] et Saboune [Saboune and Charpillet, 2005] extraient le squelette dans le but d’étudier les chutes des personnes âgées. (a) (b) (c) + (d) (e) (f) (g) (h) Figure 3.2 – Différentes représentations de l’objet à suivre : (a) silhouette, (b) contour, (c) points, (d) centre géométrique, (e) ellipse, (f) rectangle, (g) plusieurs ellipses et (h) squelette. L’apparence est ce qui caractérise la ressemblance d’un objet. Deux objets se ressemblent s’ils ont la même apparence. L’apparence de certains objets varie peu c’est le cas, par exemple, d’une balle de tennis. Tous les objets n’ont pas une apparence aussi stable. Par exemple, les tables peuvent varier selon leur forme, leur couleur, leur taille et leur angle de vue. Les méthodes utilisées doivent donc être adaptées à l’apparence de l’objet à suivre. Dans notre cas, l’apparence d’une personne peut varier selon la façon dont elle est habillée, sa position, sa posture ou encore son angle de vue. Ces différentes représentations peuvent être combinées. Bien souvent le choix de la représentation s’impose de lui-même selon l’objectif poursuivi. 363.2. Suivi de la personne Caractéristiques pour obtenir la représentation L’algorithme doit se fonder sur certaines caractéristiques faciles à identifier de l’objet pour obtenir une représentation efficace (qui peut être sous la forme d’une ellipse, d’un point, d’un squelette, etc.). Plusieurs caractéristiques de l’objet peuvent être prises en compte. Sa couleur Chaque pixel a trois valeurs, une pour le rouge, une pour le vert et une dernière pour le bleu. Ses bords ou ses contours Les contours sont les lignes dans l’image où la luminosité est modifiée. En cherchant les différences de luminosité, il est possible de détecter les contours et donc de détecter des éléments importants de l’image, comme illustré à la figure 3.3(b). (a) Image d’origine. (b) Résultat de l’extraction des contours. Figure 3.3 – Détection des contours dans une scène. Son flot optique Le flot optique d’un objet révèle le mouvement d’un objet d’une image sur l’autre. Des groupes de pixels se déplaçant à la même vitesse et dans la même direction pourront alors être regroupés et associés à un objet particulier. Sa texture La texture correspond au motif qui se répète sur la surface d’un objet et qui est perceptible visuellement. La texture doit être observée, non pas pour chaque pixel, mais par zone. Les caractéristiques retenues pour représenter un objet sont choisies généralement en fonction du domaine, de l’objectif et du contexte. Des méthodes existent pour sélectionner automatiquement les caractéristiques discriminantes de l’objet. Les méthodes d’analyse en composantes principales ou la méthode Adaboost [Tieu and Viola, 2004] sont de bons exemples de méthodes ayant fait leurs preuves. 3.2.2 Suivi de l’objet Le suivi d’un objet à travers une série d’images n’est pas un problème facile à résoudre, car plusieurs facteurs peuvent venir perturber le suivi comme les occlusions, les mauvaises détections de l’objet, les entrées et sorties du champ de vision de la caméra. La méthode, pour suivre un objet, dépend du choix pris pour représenter l’objet. La méthode ne sera pas la même si l’objet 37Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art est représenté par un ou des points, par une forme géométrique ou par sa silhouette, et en fonction des hypothèses faites sur sa dynamique. Objet représenté par des points Si l’objet est représenté à travers un ou plusieurs points, le principe de la méthode de suivi consiste à apparier les points d’une image aux points des images consécutives. Le problème consistant à faire correspondre les points, à travers plusieurs images, peut être résolu en utilisant une combinaison d’hypothèses : — la position de l’objet dans des images consécutives ne doit pas énormément varier (3.4(a)) ; — la vitesse de l’objet d’une image à l’autre n’excède pas un certain seuil, ce qui permet de supposer que le point à l’image t + 1 se trouvera dans un certain rayon comparé à l’image t (3.4(b)) ; — la direction et la vitesse de l’objet ne changent pas énormément sur une succession de plusieurs images (3.4(d)) ; — la vitesse des objets dans un petit voisinage est similaire (3.4(c)) ; — l’objet en 3 dimensions est rigide, ainsi la distance entre deux points d’un même objet restera la même à la prochaine image (3.4(e)). X O t t+1 X X (a) X O t t+1 X X (b) O t t+1 X X X O O O X (c) O t t+1 X X X t+2 X X X (d) O t t+1 X X t+2 X X O (e) Figure 3.4 – Différentes hypothèses utilisées pour le suivi d’un objet : (a) proximité, (b) vitesse maximale, (c) mouvement similaire, (d) constance de la vitesse et de la direction, (e) rigidité de l’objet. A partir de ces hypothèses, deux catégories de méthodes existent pour déterminer la correspondance entre les points de différentes images consécutives. Les approches déterministes consistent à évaluer et à minimiser un coût de correspondance entre les points de deux images consécutives. A chaque image, une solution unique est sélectionnée. Plusieurs auteurs traitent de ces approches. Nous pouvons citer en particulier Sethi et Jain [Sethi and Jain, 1987], Rangarajan et Shah [Rangarajan and Shah, 1991] et Veenman et al. [Veenman et al., 2001]. Les approches statistiques (ou bayésiennes) consistent à estimer, à l’aide d’une mesure de l’incertain, la posi- 383.2. Suivi de la personne tion future de l’objet. L’idée est de supposer que l’observation peut être bruitée, ce qui induit de l’incertitude. A chaque image, ces approches fournissent un ensemble de solutions plus ou moins probables. Le filtre de Kalman (décrit à la section 4.2.2) et les filtres particulaires sont des approches bayésiennes souvent utilisées pour résoudre le problème de suivi d’une personne. Objet représenté par des formes géométriques L’objectif est de suivre l’objet en calculant le mouvement d’une image à l’autre, des formes géométriques qui l’entourent. Les mouvements des formes géométriques sont généralement sous la forme de transformations, comme la translation, la rotation et l’application affine. Un exemple de transformation d’une ellipse est présenté à la figure 3.5. Figure 3.5 – Transformation paramétrique d’une ellipse. Deux catégories de méthodes peuvent résoudre le problème du suivi du mouvement des formes géométriques d’un objet. La première catégorie se fonde sur l’hypothèse que la forme d’un objet change peu au cours du temps. L’algorithme définit un modèle d’apparence de l’objet, lorsqu’il apparaît dans la scène et recherche, au cours du temps, l’emplacement de ce modèle dans les images, pour ainsi suivre l’objet. Un exemple de modèle d’apparence est montré à la figure 3.6 représentant les différentes parties du corps par des rectangles. Chaque rectangle a ses propres dimensions et une certaine position par rapport aux autres. Plusieurs algorithmes ont été développés pour coupler le modèle à un élément de l’image, comme celui de Comaniciu [Comaniciu, 2002] et Jepson et al. [Jepson et al., 2003]. L’autre catégorie de méthodes émet l’hypothèse que l’objet peut apparaître complètement différemment d’une vue à l’autre. Le modèle défini risque, dans ce cadre, de ne pas pouvoir correspondre à toutes les vues de l’objet et de ne pas le reconnaître dans une image, perdant alors son suivi. Le but est d’apprendre plusieurs vues de l’image avant de le suivre en direct, par exemple avec des SVM [Avidan, 2004]. Objet représenté par sa silhouette La représentation par silhouette permet de suivre plus finement certaines formes complexes, comme la main, la tête, les épaules, que la représentation par forme géométrique. L’idée est d’extraire pour chaque image la silhouette de l’objet. La silhouette sera alors couplée à un modèle représentant la forme de l’objet ou représentant le contour. La forme de l’objet peut être suivie de la même manière que le suivi de modèle d’apparence du paragraphe précédent. La silhouette et son modèle associé sont recherchés à chaque image. La méthode de suivi de contour consiste à déplacer itérativement le contour initial dans l’image précédente pour le faire correspondre à celui de la nouvelle image. Le suivi de contour nécessite d’avoir un recouvrement des régions de l’objet dans les deux images consécutives. 39Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art Figure 3.6 – Modèle d’apparence. 3.3 Caméra de profondeur La caméra que nous utilisons est la caméra Kinect de Microsoft, comme montré à la figure 3.7. Elle a la particularité d’être un capteur actif fonctionnant dans l’infrarouge qui reconstitue, même de nuit, la profondeur de chaque pixel. Ses caractéristiques sont les suivantes. Elle fournit 30 images par seconde. Son champ de vision est de 57˚à l’horizontale et 43˚à la verticale. La profondeur peut être reconstruite jusqu’à 8 m avec une précision de quelques centimètres qui se dégrade au-delà de 4 m. L’apparition de ce type de caméras simplifie les méthodes utilisées en vision. Les méthodes précédentes ont été développées pour des caméras fournissant une information d’intensité ou de couleur pour chaque pixel. La caméra de Microsoft, en plus de fournir l’information couleur, indique à quelle distance chaque pixel se trouve dans la scène par rapport à la caméra. Les caméras classiques ont l’inconvénient d’être dépendantes des changements de luminosité. Ainsi, la plupart des méthodes construites pour détecter les personnes sont conçues pour résoudre ce problème. La méthode de soustraction du fond, peu robuste avec des caméras classiques puisque le fond varie avec l’éclairage ambiant, est très efficace avec une image de profondeur [Shotton et al., 2013]. Caméra couleur Caméra profondeur Micro Moteur Figure 3.7 – Le capteur Kinect de Microsoft. Microsoft a développé ses propres algorithmes de détection et suivi de la personne. Leur algorithme a été pensé pour être appliqué aux jeux où la personne est face à la caméra puisqu’à 403.4. Conclusion l’origine cette caméra est un périphérique destiné à la console de jeux vidéo Xbox360. Ces algorithmes sont très robustes. L’algorithme est fondé sur le suivi d’un modèle de squelette. Le squelette continue d’être détecté, même si la personne est à moitié visible. Il repose sur une base d’apprentissage de 500 000 images. L’inconvénient de leur algorithme est qu’il fonctionne surtout si la personne est face à la caméra. De plus, si la personne est dans certaines positions, comme allongée au sol, leur algorithme ne détecte plus la personne. Il est peu robuste aux situations nouvelles n’appartenant pas à la base d’apprentissage. L’algorithme est propriétaire mais peut être utilisé via le SDK fourni par Microsoft. Nous avons fait le choix de ne pas utiliser le SDK de Microsoft pour développer une approche plus adaptée aux situations que nous souhaitons identifier tout en montrant que cet objectif peut être atteint par l’analyse de paramètres simples, sans passer par une reconstruction de la configuration 3D du squelette. 3.4 Conclusion L’un de nos objectifs, comme nous l’avons mentionné, est de développer un système peu coûteux. En d’autres termes, le système doit pouvoir être installé sur une machine à bas coût. Les algorithmes doivent être simples et réaliser le traitement en temps réel. Les méthodes comme l’extraction du squelette, par exemple, sont des méthodes très précises mais coûteuses en temps. Une des méthodes les plus classiques pour détecter la personne en temps réel, et que nous avons sélectionnée pour développer notre système, est l’apprentissage du fond. Cette méthode est considérée comme l’une des moins robustes. Mais aujourd’hui, avec l’apparition des caméras nous fournissant l’information de profondeur, la représentation du fond peut être construite sur la profondeur de chaque pixel et non plus uniquement sur la couleur, la rendant ainsi plus robuste, car n’étant plus dépendante des changements de lumière. Nous avons choisi, pour suivre l’objet, une représentation en points du corps de la personne qui a l’avantage d’être une méthode légère. 41Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art 42Chapitre 4 Application à la détection et au suivi de personnes avec une caméra RGB-D Sommaire 4.1 Détecter la personne . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.1 Extraction et apprentissage du fond . . . . . . . . . . . . . . . . . . 44 4.1.2 Extraction du sol et changement de repère . . . . . . . . . . . . . . 44 4.1.3 Extraction des points mobiles . . . . . . . . . . . . . . . . . . . . . 46 4.1.4 Extraction des objets mobiles . . . . . . . . . . . . . . . . . . . . . 47 4.1.5 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Suivre la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1 Représentation de la personne . . . . . . . . . . . . . . . . . . . . . 49 4.2.2 Suivi du centre de masse . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.3 Suivi de la distribution verticale . . . . . . . . . . . . . . . . . . . . 53 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Dans ce chapitre, nous présentons les différentes étapes de traitement, allant de la détection de la personne, avec l’extraction des pixels mobiles, jusqu’au suivi d’une personne se déplaçant dans le champ de vision d’une caméra. Chaque étape de la détection et du suivi est schématisée sur la figure 4.1. Chaque encadré fait l’objet d’une sous section de ce chapitre. L’objectif final, de ce chapitre, est de suivre la personne à travers des paramètres simples à extraire. Nous avons choisi de suivre la personne à partir de son centre de masse et de la distribution verticale de sa silhouette. A partir de ces deux paramètres, nous pouvons déduire d’autres caractéristiques comme la vitesse verticale et la vitesse horizontale du centre de masse et le point maximum qui correspond au sommet du crâne lorsque la personne est debout. 4.1 Détecter la personne Il s’agit dans cette section de détecter la personne à partir de l’image de profondeur fournie par la caméra. Dans une image de profondeur, chaque pixel représente un point dans l’espace 3D donné dans le système de coordonnées de la caméra. Les points du plan image peuvent être projetés dans ce système de coordonnées grâce aux paramètres optiques de la caméra. Ces paramètres sont des données constructeur propres à chaque caméra. 43Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Extraction fond Detection points mobiles Detection de la personne Regroupement en objet Detection personne à suivre Detection sol Extraction centre de masse Suivi de la personne Projection repère sol Extraction distribution verticale Figure 4.1 – Étapes pour détecter la personne du fond et la suivre dans le temps. 4.1.1 Extraction et apprentissage du fond La première étape pour détecter la personne dans le champ de vision de la caméra est d’identifier les éléments fixes de la scène, que nous appelons le fond, pour pouvoir en déduire, par soustraction, les points appartenant à la silhouette de la personne. Tout d’abord, chaque pixel F0(x, y) représentant la carte de profondeur du fond au temps t = 0 est initialisé avec une valeur arbitraire nommée M axV alue et fixée à 12 mètres. Ensuite la méthode running average [Gómez-Conde, 2011] est utilisée pour apprendre le fond en moyennant, à chaque pas de temps, les distances pour chaque point de l’image. L’utilisation d’un poids α permet de donner plus d’importance au passé. La formule de mise à jour est la suivante : Ft(x, y) = (1 − α)Ft−1(x, y) + αIt(x, y) avec F la matrice des distances cumulées, It(x, y) l’image courante et α le poids. Le poids α est fixé à 0,0001. Pour les points non reconstruits (comme dans le cas des surfaces réfléchissantes), la carte de profondeurs F n’est simplement pas mise à jour et reste égale à M axV alue de façon à permettre la détection des personnes devant les surfaces réfléchissantes. Cette méthode permet de traiter le problème du fond non stationnaire. Quand un objet (comme une chaise) est déplacé, le fond est progressivement mis à jour. Un certain temps est nécessaire pour apprendre le fond. Afin d’accélérer cet apprentissage, il est possible d’initialiser α à 1, pour le faire décroitre ensuite progressivement jusqu’à 0,0001. Hormis cette phase initiale d’apprentissage du fond, mise en place pour faciliter les expérimentations, le système s’adapte automatiquement aux changements dans la scène. 4.1.2 Extraction du sol et changement de repère L’objectif de cette étape est de permettre de faire, par la suite, des calculs indépendants de la position de la caméra. Les coordonnées 3D des points de l’image sont au départ calculées dans le système de coordonnées de la caméra dont l’origine est le centre optique. Afin d’être capable de mesurer le déplacement au sol de la personne et la hauteur des points extraits, nous souhaitons travailler dans un système de coordonnées aligné sur le sol. Pour effectuer ce changement de repère, nous avons besoin d’extraire le sol. Le système de coordonnées du sol est calculé juste après l’initialisation du fond, sans nécessiter l’utilisation d’une procédure de calibration spécifique. Etape 1 : Redressement de la scène Dans le repère de la caméra, nous désignons par X l’axe horizontal, Y l’axe vertical et Z la profondeur. Les points 3D du fond subissent tout d’abord une rotation autour de l’axe X en 444.1. Détecter la personne utilisant l’angle γ d’inclinaison de la caméra obtenu à partir de son accéléromètre. Cette première transformation permet d’avoir un axe y proche de la verticale. L’équation de redressement des points Pi est la suivante : P 0 i = RγPi avec Rγ =   1 0 0 0 cos(γ) −sin(γ) 0 sin(γ) sin(γ)   . Etape 2 : Sélection des points bas Un nombre arbitraire de points sont ensuite sélectionnés parmi les points les plus bas. L’hypothèse est que la majorité de ces points appartiennent au sol. Nous prenons ainsi les 15 000 points les plus bas qui serviront à calculer l’équation du plan du sol. Etape 3 : Calcul de l’équation du sol Le sol est assimilé à un plan d’équation ax+by+cz+d = 0 dont nous calculons les paramètres a, b, c et d avec la méthode des moindres carrés. En rappelant que l’axe y est proche de la verticale suite à l’étape 1, nous pouvons considérer que b est non nul puisque l’axe y n’appartient pas au plan. L’ensemble des coefficients de l’équation du plan étant définis à une constante multiplicative près nous pouvons fixer b = 1. Chaque point P 0 i sélectionné à l’étape 2 nous donne donc une équation du type : xia + zic + 1d = −yi . Le système d’équations surdimensionné Ax = B où A =   x1 z1 1 ... xN zN 1   , x =   a c d   et B =   −y1 ... −yN   peut être résolu avec la méthode des moindres carrés qui nous donne la solution x = (A T A) −1A T B minimisant le résidu r = B − Ax. 45Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Etape 4 : Construction du repère sol Il s’agit enfin de construire le système de coordonnées du sol (Og, ~ux, ~uy, ~uz). Une origine arbitraire Og(0, y, 0) est définie telle que Og appartienne au plan calculé précédemment, ce qui nous donne : Og =   0 −d 0   . Un premier axe est construit également arbitrairement en prenant un second point sur le sol de coordonnées (1, yx, 0) ce qui nous donne le vecteur directeur ~ux = αx   1 −a 0   . L’axe Yg est défini par le vecteur normal au plan ~uy = αy   a 1 c   . L’axe Zg est enfin construit en faisant le produit vectoriel entre ux et uy : ~uz = αz(~ux ∧~uy), soit ~uz = αz   −ac −c a 2 + 1   . Les nombres αx, αy et αz sont des constantes de normalisation. Projection d’un point dans le repère sol Les points 3D P(x, y, z) peuvent, après rotation suivant l’angle γ comme montré à l’étape 1, être projetés dans le système de coordonnées du sol (Og, ~ux, ~uy, ~uz) en réalisant les produits scalaires entre le vecteur (OgP 0 ) et les vecteurs directeurs du repère. Les coordonnées P 00 de P dans le repère sol sont données par : P 00 =   1αx −aαx 0 aαy 1αy cαy acαz cαz (a 2 + 1)αz   (P 0 − Og) où P 0 = RγP. Un exemple d’extraction du sol est montré sur la figure 4.2. 4.1.3 Extraction des points mobiles Dans cette étape, nous cherchons à identifier les points mobiles de l’image, c’est-à-dire les points occupés par la personne. Pour cela, à chaque instant, le fond (l’image des distances du fond) est soustrait à l’image courante des distances, pour ne garder que les points ayant une distance plus courte dans l’image courante que dans l’image de fond. Pour éliminer le bruit, c’est-à-dire les points détectés comme mobiles mais ne l’étant pas, un filtre Erosion-Dilatation est utilisé. Tout d’abord l’étape d’érosion permet d’éliminer tous les points mobiles proches d’un point considéré comme appartenant au fond. Ainsi, tous les 464.1. Détecter la personne Figure 4.2 – L’extraction du sol est représentée en rouge. contours des objets seront éliminés et le bruit également. La figure 4.3a) est un exemple de représentation des points mobiles et fixes où sera appliqué le filtre Erosion-Dilatation. Sur cette figure les cases en bleu représentent les points détectés comme mobiles et les points en vert représentent le fond. Le filtre érosion est appliqué à la figure 4.3a). Le résultat est montré en figure 4.3b). Toutes les cases bleues, ayant une case verte dans leur voisinage, deviennent vertes. Dans l’exemple, un voisinage de taille 1 est sélectionné, c’est-à-dire seuls les points juxtaposés sont pris en compte. La deuxième étape est le filtre dilatation consistant à transformer tous les points du fond, proches des points mobiles, en des points mobiles. A la figure 4.3b) est appliqué le filtre dilatation permettant d’obtenir la figure 4.3c). Chaque case verte juxtaposée à une case bleue devient bleue. Cela permet aux objets mobiles de récupérer leurs contours. Dans notre algorithme la taille du voisinage est de 2. 4.1.4 Extraction des objets mobiles Dans cette section, l’objectif est de regrouper les points mobiles appartenant à un même objet, ainsi il sera possible de distinguer plusieurs objets dans une même scène. Pour cela, nous utilisons un étiquetage des composantes connexes [Suzuki et al., 2003]. Cette méthode consiste à affecter une étiquette (un nombre) différente à tous les points détectés comme mobiles. Dans la figure 4.4a), les cases colorées correspondent à des points détectés comme mobiles. Ainsi dans la figure 4.4b), l’algorithme assigne un nombre différent à chaque point mobile. Ensuite, la technique consiste à regarder pour chaque point p, si un de ses voisins a un nombre plus petit. Si ce cas est avéré, l’étiquette du voisin le plus petit est attribuée au point p. Cette opération est montrée à la figure 4.4c). Chaque point prend à l’étape t+2 le nombre le plus petit parmi ses voisins de l’étape t+1. Cette commande est répétée jusqu’à ce qu’il n’y ait plus de changement dans l’affectation des nombres aux points de l’image. La figure 4.4d) est la dernière étape de l’algorithme, car les étiquettes des points ne changent plus. Ainsi, tous les points ayant un même nombre seront regroupés comme étant un même objet mobile. Dans la figure 4.4d), l’algorithme a détecté deux objets différents, un objet avec les points portant le numéro 1 et un autre objet avec les points ayant le numéro 7. Cet algorithme pose la question du nombre de voisin à prendre en compte. Est-ce qu’il faut se limiter aux points juxtaposés de p ou alors déterminer un voisinage plus grand ? Un des problèmes, à ne considérer que les voisins juxtaposés du point (c’est-à-dire avec un voisinage de 47Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Erosion Dilatation a) b) c) Figure 4.3 – a) Les cases bleues représentent des points mobiles et les cases vertes les points appartenant au fond, b) le filtre érosion est appliqué, c) le filtre dilatation est appliqué. 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 7 9 11 111413 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 1 2 2 4 1 7 7 7 9 9 1111 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 1 1 1 1 1 7 7 7 7 7 7 777 77 7 7 étape 1 étape n 2 étape 13 131314 a) b) d) c) Figure 4.4 – a) Les cases colorées représentent des points mobiles, b) l’algorithme assigne un nombre aux points mobiles, c) les points avec un nombre plus grand que ses voisins sont modifiés, d) le résultat final est atteint. 484.2. Suivre la personne taille 1), est qu’il est possible que certaines parties ne soient pas détectées comme appartenant au même objet. Par conséquent, la jambe ou le bras peut être identifié comme un objet et le reste du corps comme un autre objet. La seconde solution est de prendre un voisinage de taille plus importante. L’algorithme avec un voisinage de taille 2 considérera les points positionnés en p−2, p − 1, p + 1 et p + 2. La contrepartie est alors le risque d’intégrer des points n’appartenant pas à l’objet. Pour illustrer ces deux méthodes, nous pouvons donner l’exemple suivant. La figure 4.4 montre le cas où nous considérons seulement les points juxtaposés. Deux objets sont alors détectés en figure 4.4d). Un voisinage de taille 3 modifierait le résultat, les deux blocs de points mobiles seraient rassemblés en un seul objet. Après une analyse qualitative, en variant la taille du voisinage, un voisinage de 3 est sélectionné pour notre algorithme. 4.1.5 Détection de la personne Après l’étape précédente, l’algorithme est capable de fournir tous les groupes d’objets mobiles visibles dans la scène. Nous faisons l’hypothèse qu’il n’y a qu’une personne dans la scène. Donc parmi les objets mobiles se trouvent la personne à suivre et des objets qui ont été déplacés (tels qu’une chaise, une porte). Le groupe correspondant à la personne à suivre est récupéré en prenant le groupe ayant le nombre de points mobiles le plus important. Comme nous l’avons précisé précédemment, le fond ne cesse d’être appris ce qui permet aux objets déplacés de revenir dans le fond au bout d’un certain temps. Par contre, le même effet se produit si une personne reste inactive pendant un certain temps. Pour éviter que la personne n’intègre le fond, l’algorithme d’apprentissage du fond ne prend pas en compte les pixels détectés comme mobiles et appartenant à la personne suivie. 4.2 Suivre la personne L’objectif de cette étape est de décrire la méthode utilisée dans l’algorithme pour suivre la personne au cours du temps. Comme précisé au chapitre précédent, la méthode pour suivre une personne découle du choix pris pour la représenter. Nous introduisons dans cette section une partie concernant le choix de la représentation, pour ensuite décrire la méthode pour obtenir cette représentation au cours du temps. 4.2.1 Représentation de la personne Comme nous l’avons présenté dans le chapitre précédent, plusieurs représentations de la personne sont possibles, par des points, par un squelette, par une ellipse représentant la totalité du corps ou une pour chaque partie du corps, etc. Notre objectif était de trouver une représentation assez légère en temps de calcul pour que le suivi se fasse en temps réel. Les étapes précédentes de détection de la personne nous permettent d’obtenir une série de points 3D la composant. Nous n’avons pas besoin de suivre très précisément les différentes parties du corps, une analyse globale de la personne est suffisante. Nous pouvons réduire les paramètres à un ensemble d’éléments descriptifs de la distribution verticale du corps. Un intérêt majeur de travailler avec une représentation simple est qu’elle sera moins sujette à variations et donc robuste à la diversité des situations. Le suivi des déplacements du corps dans l’espace peut être une tâche assez complexe, car chaque partie du corps peut faire l’objet d’une analyse à part entière. L’article de Saunders et al. [Saunders et al., 1953] traite du sujet des déplacements du corps en mouvement. Selon eux, 49Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D l’analyse du corps en mouvement peut être réduite à la simple analyse du centre de masse en mouvement. Plus précisément, les déplacements horizontaux et verticaux du corps, lorsqu’une personne marche, peuvent être analysés en regardant les déplacements du centre de masse. La figure 4.5 et 4.6 représentent les déplacements horizontaux et verticaux du centre de masse quand une personne marche d’après l’article de Saunders et al.. Ces déplacements forment des courbes sinusoïdales d’une certaine amplitude. Ce sont ces mécanismes effectués ainsi qui permettent de minimiser la dépense énergétique au cours de la marche. Si les déplacements du centre de masse d’une personne ne respectent pas les formes et l’amplitude habituelle des courbes, la marche est alors dite pathologique. La trajectoire du centre de masse à elle seule permet de fournir de nombreuses informations sur le corps en mouvement. Figure 4.5 – Déplacement horizontal théorique du centre de masse. Figure 4.6 – Déplacement vertical théorique du centre de masse. Pour représenter le corps de la personne et le suivre au cours du temps, nous avons choisi de coupler l’analyse de la distribution verticale et de la trajectoire du centre de masse pour représenter le corps durant le cycle de déplacement. 504.2. Suivre la personne 4.2.2 Suivi du centre de masse Calcul du centre de masse Au début de cette étape, la personne à suivre est détectée. La personne extraite avec l’algorithme est composée d’un ensemble de points 3D. Dans notre algorithme le centre de masse est calculé comme étant un centre géométrique de la silhouette, il s’agit de l’emplacement moyen, de tous les éléments mobiles, calculé à partir de la formule suivante : Cm(x, y, z) = ( 1 N X i xi , 1 N X i yi , 1 N X i zi) où xi ,yi ,zi sont les coordonnées du i eme points 3D et N est le nombre de points mobiles. La trajectoire du centre de masse d’une personne marchant perpendiculairement à la caméra, obtenue avec notre méthode, est montrée à la figure 4.7. La trajectoire horizontale de la figure 4.7(b) est difficilement interprétable. La trajectoire verticale de la figure 4.7(a) est, en revanche, similaire à la courbe théorique sinusoïdale que Saunders et al. ont décrit et qui est représentée à la figure 4.6. De plus, Saunders et al. spécifient que l’amplitude bas-haut des déplacements du centre de masse est approximativement 1,08 pouce (soit 4,8 cm), ce qui correspond à peu près à l’amplitude trouvée avec nos courbes. 600 650 700 750 800 850 900 950 1000 1050 28 28.5 29 29.5 30 30.5 31 Y (mm) Temps (s) (a) Déplacement vertical du centre de masse. -2500 -2400 -2300 -2200 -2100 -2000 -1900 -1800 -1500 -1000 -500 0 500 1000 1500 Z (mm) X (mm) (b) Déplacement horizontal du centre de masse. Figure 4.7 – Déplacement du centre de masse extrait à partir de notre algorithme pour une personne marchant en ligne droite perpendiculairement à la caméra. La montée et la descente en début et fin de trajectoire correspondent aux entrées et sorties de la personne dans le champ de vision de la caméra. Description de la trajectoire du centre de masse L’amplitude de la courbe verticale du centre de masse est accentuée par un artefact lié aux occlusions périodiques faisant varier la répartition du nombre de points visibles appartenant à la personne. La figure 4.8(a) montre que les amplitudes de la courbe du centre de masse sur l’axe vertical sont dépendantes de la variation du nombre de pixels mobiles. Sur cette figure, les maxima locaux de la trajectoire du centre de masse, pour une personne marchant perpendiculairement à la caméra, correspondent aux instants où la personne a moins de pixels mobiles détectés. La raison est qu’à cet instant la personne est sur un pied d’appui et qu’une jambe est cachée par l’autre. Quand la personne est en double appui, les deux jambes sont visibles et il y a donc plus de pixels mobiles détectés dans la partie basse de la silhouette. 51Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Ensuite la trajectoire du centre de masse, d’une personne marchant cette fois en direction de la caméra, a été tracée sur le même graphe que la courbe représentant le nombre de pixels mobiles. Le résultat est montré à la figure 4.8(b). Le nombre de pixels mobiles augmente de plus en plus parce que la personne s’approche de la caméra et occupe donc plus de place dans le champ de vision. La trajectoire du centre de masse s’élève lorsque la personne se rapproche de la caméra. Ceci est dû au fait que, la caméra étant positionnée en hauteur et plongeant vers le bas, la zone supérieure du corps de la personne est de plus en plus visible au fur et à mesure que la personne s’approche de la caméra. La trajectoire du centre de masse sur l’axe vertical forme une trajectoire sinusoïdale mais avec une amplitude plus petite comparée à la situation où la caméra est perpendiculaire à la personne comme à la figure 4.8(a). Dans le cas où la caméra est face à la personne, l’artefact du nombre de points mobiles n’intervient pas. Comme on peut le voir sur la figure 4.8(b), la dépendance entre nombre de points et maxima locaux sur la courbe du centre de masse n’est pas évidente. Ceci montre que l’artefact, dû aux occlusions de profil, amplifie le mouvement vertical du centre de masse mais n’est pas le seul facteur à l’origine de ce mouvement et, lorsque la caméra est de face, c’est bien le déplacement vertical de la personne qui est observé. 0.58 0.6 0.62 0.64 0.66 0.68 34 34.5 35 35.5 36 36.5 37 5000 10000 15000 20000 25000 Y Nombre de points Temps (s) Nombre de points Y (a) Une personne marche perpendiculairement à la caméra. 0.58 0.6 0.62 0.64 0.66 0.68 39 39.5 40 40.5 41 41.5 5000 10000 15000 20000 25000 Y Nombre de points Temps (s) Nombre de points Y (b) Une personne marche face à la caméra. Figure 4.8 – Comparaison entre la trajectoire du centre de masse et le nombre de pixels mobiles appartenant à une personne. Lissage de la trajectoire du centre de masse Les trajectoires, sur l’axe vertical du centre de masse que nous obtenons, sont filtrées. Deux méthodes pour filtrer la trajectoire ont été implémentées, un filtre passe-bas et un filtre de Kalman. Notre filtre passe-bas moyenne chaque centre de masse gt avec les deux centres de masse précédents gt−1, gt−2 et les deux centres suivants gt+1, gt+2. Cette méthode permet de filtrer la courbe. Le résultat du lissage de la courbe 4.9(a) avec le filtre passe-bas est montré à la figure 4.9(b). Le filtre de Kalman [Rabiner, 1989] est un cas particulier du filtre bayésien général, estimant l’état d’un système à partir d’une série d’observations bruitées. Dans notre cas, les observations sont les positions 3D du centre de masse. Le modèle est paramétré par, d’un côté, l’incertitude de la prédiction et, de l’autre, par l’incertitude de l’observation. Le bruit relatif R donné à l’observation, comparé au bruit de la prédiction Q, permet de définir l’inertie du filtre. Nous 524.2. Suivre la personne utilisons un filtre simple défini par : xt+1 = xt + Q gt = xt + R où gt représente l’observation à l’instant t (centre de masse calculé sur l’image t) et xt représente le résultat du filtre. Les bruits Q et R du filtre sont réglés manuellement. L’inférence est réalisée en deux étapes avec les équations de Kalman. Prédiction L’étape de prédiction permet d’estimer la position à l’instant t à partir des observations précédentes (des instants 1 à t − 1). xt|t−1 = F xt−1|t−1 Pt|t−1 = F Pt−1|t−1F T + Q Dans notre cas, la fonction de transition F est égale à la matrice identité. xt|t−1 représente l’état prédit sans prendre encore en compte l’observation à l’instant t et Pt|t−1 représente la covariance de la prédiction. Correction L’étape de correction consiste à mettre à jour la prédiction en prenant en compte l’observation à l’instant t. yt = gt − Hxt|t−1 St = HPt|t−1HT + R Kt = Pt|t−1HT S −1 t xt|t = xt|t−1 + Ktyt Pt|t = (I − KtH)Pt|t−1 . Dans notre cas, la fonction d’observation H est égale à la matrice identité. yt l’innovation, St la covariance de l’innovation et Kt le gain de Kalman sont des variables intermédiaires utilisées pour calculer l’état xt|t et la covariance Pt|t a posteriori en intégrant l’observation gt . Le résultat du lissage de la courbe 4.9(a) avec le filtre de Kalman est montré à la figure 4.9(c). La comparaison visuelle des deux filtres montre que le filtre de Kalman est moins sensible aux valeurs extrêmes. Paramètres dynamiques En plus de la position du centre géométrique, nous utilisons les paramètres représentatifs de son déplacement à savoir sa vitesse horizontale et verticale. 4.2.3 Suivi de la distribution verticale Pour compléter la représentation de la personne, nous ajoutons deux autres paramètres représentatifs de la distribution verticale qui sont l’écart type et le maximum des coordonnées verticales des points mobiles. 53Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D -1550 -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 -1000 27.5 28 28.5 29 29.5 30 30.5 Y (mm) Temps (s) -1350 -1300 -1250 -1200 -1150 -1100 -1050 27.5 28 28.5 29 29.5 30 30.5 Y (mm) Temps (s) (a) (b) -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 27.5 28 28.5 29 29.5 30 30.5 Y (mm) Temps (s) (c) Figure 4.9 – a) Courbe non lissée, b) courbe lissée avec le filtre passe-bas, c) courbe lissée avec le filtre de Kalman. L’écart type des coordonnées des points 3D mobiles, composant le corps de la personne est calculé sur l’axe y par la formule suivante : σy = sPN i=1 [yi − Cm(y)]2 N avec N le nombre de points composant le corps de la personne et Cm(y) la coordonnée sur l’axe y du centre de masse. Un exemple de variation de la distribution verticale pour une personne qui marche est illustré à la figure 4.10. 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 33.5 34 34.5 35 35.5 36 36.5 37 Ecart type Temps (s) Figure 4.10 – Trajectoire de l’écart type vertical pour une personne qui marche. 544.3. Conclusion Le point maximum des points mobiles sur l’axe vertical y est calculé par la formule suivante : Ymax = maxX N i=1 yi avec N le nombre de points composant le corps de la personne et yi la coordonnée sur l’axe y du point mobile i. Tout comme pour le centre de masse, la trajectoire du point maximum est lissée par un filtre de Kalman. La figure 4.11(a) représente la trajectoire du point maximum lorsqu’une personne marche et la figure 4.11(b) correspond à sa trajectoire filtrée. Nous pouvons voir que l’amplitude des oscillations du point maximum est moins grande que celle des oscillations du centre de masse représenté à la figure 4.7(a). 1250 1300 1350 1400 1450 1500 1550 1600 1650 1700 1750 33.5 34 34.5 35 35.5 36 36.5 37 Y (mm) Temps (s) (a) Trajectoire du point maximum sur l’axe vertical. 1250 1300 1350 1400 1450 1500 1550 1600 1650 1700 33.5 34 34.5 35 35.5 36 36.5 37 Y (mm) Temps (s) (b) Trajectoire du point maximum lissée sur l’axe vertical. Figure 4.11 – Comparaison entre la trajectoire du point maximum filtrée et non filtrée pour une personne qui marche. 4.3 Conclusion L’objectif pour détecter et suivre la personne était d’utiliser des algorithmes simples. Ainsi, notre méthode nous permet un suivi de la personne en temps réel. Nous avons opté pour une représentation de la personne à travers 5 paramètres faciles à extraire qui sont : — la position du centre de masse ; — la vitesse verticale du centre de masse ; — la vitesse horizontale du centre de masse ; — la dispersion verticale de la silhouette ; — le point maximum de la silhouette. Les traitements de plus haut niveau qui sont décrits par la suite (l’analyse des paramètres de la marche et la détection de l’activité d’une personne) se basent sur l’analyse d’un ou de l’ensemble de ces paramètres. 55Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D 56Chapitre 5 Mesurer à domicile les paramètres de la marche Sommaire 5.1 Définition et description de la marche . . . . . . . . . . . . . . . 58 5.1.1 Définition de la marche . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1.2 Description du cycle de la marche . . . . . . . . . . . . . . . . . . . 58 5.2 Indicateurs de l’analyse de la marche . . . . . . . . . . . . . . . . 59 5.2.1 Paramètres spatio-temporels . . . . . . . . . . . . . . . . . . . . . . 59 5.2.2 Paramètres cinématiques . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.3 Paramètres dynamiques . . . . . . . . . . . . . . . . . . . . . . . . 61 5.3 Sélection des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Troubles de la marche et risques de chute . . . . . . . . . . . . . . . 64 5.3.2 Troubles de la marche et risques d’hospitalisation . . . . . . . . . . 64 5.3.3 Troubles de la marche et troubles cognitifs . . . . . . . . . . . . . . 64 5.4 Extraction des indicateurs . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.1 Longueurs de pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.2 Cadence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.3 Vitesse de marche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.4 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 L’être humain effectue en moyenne 5 000 à 15 000 pas par jour soit 2 à 5 millions par an. La marche s’acquiert au travers d’un processus d’apprentissage qui est qualifié de difficile selon Viel [Viel, 2000]. L’apprentissage de la marche prend plusieurs années, pour être par la suite automatique. Le but pour les nouveaux apprenants est d’acquérir les différentes phases composant la marche, de maintenir leur équilibre et de s’adapter aux contraintes de l’environnement extérieur tout en réduisant le coût énergétique. L’objectif dans ce chapitre est de décrire ce qu’est la marche. Nous commençons par décrire la marche dans sa globalité en analysant les différentes phases qui la constituent. Puis une seconde section abordera la façon dont la marche peut être analysée en énumérant différents indicateurs utilisés pour la décrire. Cette section est inspirée des thèses de Gillet en 2004 [Gillet, 2004] et Fusco en 2008 [Fusco, 2008]. Après avoir brossé un panorama des indicateurs existants pour analyser la marche, nous proposons de sélectionner certains paramètres pertinents pour l’étude de la fragilité. Enfin, nous décrivons l’algorithme qui permet d’extraire ces paramètres. 57Chapitre 5. Mesurer à domicile les paramètres de la marche Figure 5.1 – Représentation du cycle de la marche selon Viel (2000). 5.1 Définition et description de la marche 5.1.1 Définition de la marche La marche humaine « normale » est définie par Perry[Perry and Davids, 1992] comme un phénomène complexe impliquant la coordination de mouvements de rotations des segments corporels pour maintenir l’équilibre du corps pendant son déplacement vers l’avant. Chaque être humain a sa propre façon de marcher, sa propre démarche. Malgré tout, la marche peut être découpée en séquences de mouvements cycliques, qui sont identifiables chez tous les humains, pour les deux sexes et âges confondus, et qui apparaissent à chaque pas. La description de la marche, ci-après, concerne la marche « normale », par opposition à la marche pathologique. 5.1.2 Description du cycle de la marche Un cycle de marche (une foulée) commence par le contact initial d’un pied au sol (par le talon) et se termine par le contact suivant du même pied (par le même talon). Le cycle de la marche est lui-même découpé en phases, permettant ainsi de poser les bases pour analyser la marche d’une personne. Selon le découpage de Viel [Viel, 2000], le cycle de marche est découpé principalement en deux phases, une phase d’appui et une phase d’oscillation comme illustré à la figure 5.1. La phase d’appui (droite ou gauche) dure 60 % du cycle et est définie comme la phase débutant lorsque le pied (droit ou gauche) est en contact avec le sol. La phase d’oscillation (droite ou gauche) dure 40 % du cycle et est définie comme la phase débutant lorsque la jambe (gauche ou droite), en l’air, se déplace vers l’avant et se termine lorsque le talon reprend contact avec le sol. Un découpage plus fin du cycle peut être donné à l’intérieur des phases d’appui et d’oscillation. 585.2. Indicateurs de l’analyse de la marche Phase d’appui Le double appui de réception Lors de cette phase, les deux pieds sont en contact avec le sol. Cette phase commence à 0 % du cycle avec le contact initial du talon sur le sol et se termine lorsque les orteils controlatéraux se soulèvent à 10 % du cycle. Le rôle de cette phase est de diriger le mouvement du corps vers l’avant et vers le côté lorsque le pied controlatéral quitte le sol. La phase d’appui unilatéral Après la phase de double appui de réception se produit la phase d’appui unilatéral qui dure environ 40 % du cycle. Lors de cette phase, un seul membre inférieur est en appui. La phase commence à 10 % du cycle avec le décollement des orteils controlatéraux et se termine à environ 50 % du cycle avec le contact du talon controlatéral. Cette période permet la progression du corps en avant par le pied en appui. Le double appui de propulsion Tout comme la phase de double appui de réception, les deux pieds sont en contact avec le sol. Cette phase commence lors du contact controlatéral à environ 50 % du cycle et se finit à 60 % du cycle avec le décollement des orteils du pied en appui. Le but de cette phase est de propulser le corps vers l’avant, grâce au transfert de poids vers la jambe controlatérale. Phase d’oscillation Durant cette phase, le membre oscillant ne décolle que très légèrement les orteils (1,29 cm) puis le talon frôle la surface du sol d’environ 1 cm. Habituellement, cette phase n’est pas dé- coupée plus finement. Nous pouvons tout de même noter que, lors de cette période, une phase d’accélération et une phase de décélération peuvent être distinguées. La phase d’accélération commence lorsque le pied décolle du sol et se termine lorsque les deux pieds se croisent. Ensuite une phase de décélération est observée dans laquelle le membre oscillant ralentit dans le but de préparer le prochain contact. 5.2 Indicateurs de l’analyse de la marche Pour analyser la marche d’une personne, différentes variables peuvent être prises en compte selon le but de l’analyse. Les indicateurs peuvent être regroupés selon trois catégories. 5.2.1 Paramètres spatio-temporels Tout d’abord, les paramètres spatio-temporels sont couramment étudiés, car ils informent sur les caractéristiques globales de la marche, c’est-à-dire qu’ils informent sur le déroulement de la marche dans le temps et l’espace. Les paramètres spatio-temporels ont la particularité de prendre des valeurs variables selon le sexe et l’âge de la personne. Principaux paramètres spatiaux Les paramètres souvent évalués sont la longueur du pas, la largeur du pas, la longueur et largeur d’enjambée et, l’angle du pas. Ces paramètres ont une définition parfois différente selon les articles. Il n’y a pas vraiment de consensus en analyse de la marche. Nous proposons ici des définitions inspirées de ce qui est le plus couramment proposé et nous reprenons également la thèse de Faivre de 2003 qui propose un lexique terminologique [Faivre, 2003]. 59Chapitre 5. Mesurer à domicile les paramètres de la marche La longueur du pas (droit pour notre exemple) correspond à la distance entre les deux talons lors du temps du double appui de réception (double appui de réception droit dans notre exemple). La largeur du pas est définie comme la distance entre la ligne de progression (ligne traversant tous les pas effectués par la personne) et le point médian du talon. L’enjambée correspond à la succession de deux pas. La longueur d’enjambée est alors définie comme la somme algébrique des longueurs de deux pas successifs. La largeur d’enjambée quant à elle est déterminée par la somme algébrique de la largeur de deux pas successifs. Ces paramètres sont exprimés en mètres. L’angle du pas, exprimé en degrés, correspond à l’angle formé entre la ligne de progression et le point médian du talon. Tous ces paramètres sont représentés à la figure 5.2. Longueur pas droit Longueur pas gauche Ligne de progression Longueur d'enjambée Largeur pas droit Angle pas Largeur pas gauche Largeur d'enjambée + + Figure 5.2 – Représentation des paramètres spatiaux. Principaux paramètres temporels Les paramètres souvent évalués sont la cadence (la fréquence), la vitesse de marche, le temps d’appui bipodal et unipodal (ou temps d’oscillation). Tout comme les paramètres spatiaux, les définitions de chaque terme ne sont pas des définitions « universelles ». La cadence correspond à la vitesse de marche en fonction du nombre de pas. Il s’agit de la fréquence à laquelle une personne marche. Le terme « fréquence » est d’ailleurs souvent employé à la place de « cadence ». La cadence est calculée comme le nombre de pas par minute ou par seconde. La vitesse de marche correspond à la relation mathématique entre la cadence (enjambées/min) et la longueur d’enjambée (en mètre). La vitesse de marche est exprimée en mètre par seconde. La formule est donc : Vitesse de marche = (Longueur × Cadence)/120 Bien souvent dans la réalité, la vitesse de marche est obtenue en chronométrant le temps mis par le sujet pour parcourir une distance donnée. Le temps d’appui bipodal est la durée moyenne des temps de double appui lors d’un cycle de la marche (pour rappel le cycle de marche correspond au moment entre le contact initial du talon et le contact suivant du même talon). Le temps d’appui unipodal est la durée moyenne du temps d’appui unilatéral lors d’un cycle de marche droit ou gauche. Ce temps est égal au temps d’oscillation du pied controlatéral. Les temps d’appui bipodal et unipodal sont exprimés en secondes ou en % du cycle de marche. 5.2.2 Paramètres cinématiques La deuxième catégorie correspond aux paramètres cinématiques qui sont des variables fré- quemment étudiées, car elles reflètent le mouvement des membres inférieurs au cours de la marche. 605.2. Indicateurs de l’analyse de la marche Il s’agit d’analyser l’aspect de la marche. Les paramètres correspondent aux angles permettant d’analyser la flexion de la cheville, la flexion du genou et la flexion de la hanche. La flexion de la cheville est analysée en observant l’angle formé entre le pied et le tibia (os du membre inférieur). La flexion du genou correspond à l’angle entre le tibia et le fémur (os de la cuisse). Et la flexion de la hanche représente l’angle formé entre le fémur et le bassin. Ces angles sont représentés à la figure 5.3. (a) Angle entre le pied et le tibia. (b) Angle entre le tibia et le fé- mur. (c) Angle entre le fémur et le bassin. Figure 5.3 – Représentation des paramètres cinématiques. 5.2.3 Paramètres dynamiques L’analyse dynamique constitue l’étude des forces et moments internes qui engendrent le mouvement. L’utilisation de la technique de l’électromyographie décrite dans la section 1.2.1 permet cette analyse. Mais celle-ci est invasive, elle requiert de poser des capteurs sur les muscles. Pour faciliter l’analyse dynamique, il est courant d’étudier les forces et les moments externes à travers l’analyse de l’interaction du pied avec le sol. Ainsi, les forces de réaction du sol et les pressions plantaires permettent une évaluation du pied. Les forces de réaction du sol Les forces de réaction du sol sont mesurées lors de la réception et la propulsion des pieds durant la marche. La force de réaction correspond à un vecteur se divisant selon trois axes d’après Kirtley [Kirtley, 2006], un axe vertical, antéro-postérieur et média-latéral. Composante verticale La composante verticale correspond à la force décrite à la figure 5.4(a). Il s’agit de la composante où les forces ont le plus d’amplitude. Lors d’un cycle de la marche, la courbe de cette composante évolue en forme de « M » comme représentée en bleue à la figure 5.5. Les deux pics de cette courbe représentent les phases de réception et de propulsion. Lors de la phase d’oscillation, le pied n’est plus en contact avec le sol donc la force de réaction est nulle. Composante antéro-postérieure La composante antéro-postérieure correspond à la force décrite à la figure 5.4(b). Deux phases sont identifiables sur la courbe formée par cette composante 61Chapitre 5. Mesurer à domicile les paramètres de la marche lors du cycle de la marche comme montré en vert à la figure 5.5. Lors de la phase de réception, la courbe est négative, le sujet freine, donc la force est exercée vers l’arrière. La deuxième phase, la phase de propulsion, est le moment où la courbe est positive, le sujet propulse son corps vers l’avant donc la force est exercée vers l’avant. Composante média-latérale La composante média-latérale, illustrée à la figure 5.4(c), correspond aux forces qui ont le moins d’amplitude. Toutefois il est possible de constater deux phases dans la forme de la courbe des forces, comme le montre en rouge la figure 5.5. Une phase de réception très courte où la force est orientée vers l’extérieur, vers l’axe latéral. Et une phase d’appui qui dure plus longtemps et où la force est orientée vers le centre, vers l’axe médian. (a) La force verticale. (b) La force antéro-postérieure. (c) La force média-latérale. Figure 5.4 – Représentation des forces exercées lorsqu’une personne marche. Pressions plantaires Les pressions plantaires correspondent aux points d’appui sur l’ensemble de la plante du pied lors du contact avec le sol. Les points d’appuis successifs lorsque le pied est en contact avec le sol sont représentés à la figure 5.6 et inspirés selon Allard en 1996 [Allard and Blanchi, 1996]. Tout d’abord les pressions débutent au niveau de l’extérieur du talon lorsque la personne pose son talon au sol. Ensuite, la trajectoire se poursuit sur le bord externe du pied, pour se propager vers toutes les têtes métatarsiennes et aboutir au niveau de la phalange distale de l’orteil. 5.3 Sélection des indicateurs Lorsqu’une personne vieillit, sa marche est modifiée. Plusieurs changements dans la marche des personnes âgées peuvent être cités, notamment une diminution de la vitesse de la marche [Guimaraes and Isaacs, 1980], une réduction des longueurs de pas ([Guimaraes and Isaacs, 1980], [Winter et al., 1990]), une augmentation du temps de double appui [Winter et al., 1990] et une plus grande variabilité de la marche [Guimaraes and Isaacs, 1980]. Ces modifications de la marche sont considérées comme « normales », car dues à l’avancée dans l’âge. Ce qui nous intéresse dans 625.3. Sélection des indicateurs 0 200 400 600 800 1000 -200 Force (N) 0 20 40 60 80 100 % cycle de la marche Figure 5.5 – Force de réaction du sol selon l’axe vertical (bleu), antéro-postérieur (vert) et média-latéral (rouge) lors d’un cycle de marche selon Kirtley. Figure 5.6 – Trajectoire des pressions plantaires lors de la marche. 63Chapitre 5. Mesurer à domicile les paramètres de la marche cette partie, concerne les changements « anormaux » de la marche, pouvant être des indicateurs d’une augmentation de la fragilité des personnes. Dans cette section, nous présentons des articles mettant en évidence une corrélation entre une détérioration de la santé de la personne et une évolution des indicateurs de sa marche. L’analyse de ces articles nous permettra de déterminer quels sont les indicateurs pouvant informer sur l’état d’une personne indépendamment de l’âge. 5.3.1 Troubles de la marche et risques de chute En 1980, Guimaraes et al. [Guimaraes and Isaacs, 1980] ont réalisé une étude sur l’analyse de la marche en comparant deux groupes, un groupe de 30 personnes hospitalisées pour cause de chute (sans blessure particulière) et un groupe de 22 personnes de même âge se trouvant à l’hôpital mais n’ayant pas subi de chute récente. L’étude a révélé que le groupe hospitalisé, pour cause de chute, avait une vitesse de marche réduite, de plus petite longueur et largeur de pas et une augmentation dans la variabilité des fréquences de pas. En 2001, Hausdorff et al. [Hausdorff et al., 2001] reprennent l’idée d’une dégradation des paramètres chez les personnes ayant chuté et testent l’hypothèse que la prévention des chutes est possible à partir de ces paramètres. Après un an d’expérimentation, ils ont montré que les variabilités de temps des foulées et les variabilités de temps d’oscillation sont associées à une augmentation du risque de chute dans le futur. Auvinet et al. [Auvinet et al., 2003] ont mis en place en 2003 une expérimentation où 53 sujets, dont 20 étaient considérés comme le groupe des « chuteurs », devaient marcher sur un parcours de 40 mètres. Ils ont alors pu montrer que la vitesse, la fréquence et les longueurs de pas avaient des valeurs réduites pour le groupe des « chuteurs ». L’irrégularité des longueurs de pas était considérée, dans leur étude, comme une variable fiable pour prévenir les chutes. 5.3.2 Troubles de la marche et risques d’hospitalisation D’autres articles montrent l’intérêt d’étudier les paramètres spatio-temporels pour leur corrélation avec le risque d’hospitalisation. En effet, l’analyse de la vitesse de la marche serait un bon indicateur pour prédire un risque d’hospitalisation et un déclin de la santé selon Studenskiet al. [Studenski et al., 2003]. Dans cet article, les auteurs montrent que 41 % des marcheurs lents (<0.6 m/s) sont hospitalisés au moins une fois par an, tandis que seulement 26 % des marcheurs intermédiaires (0.6-1.0 m/s) et 11 % des marcheurs rapides (>1.0 m/s) sont hospitalisés. 5.3.3 Troubles de la marche et troubles cognitifs Les troubles cognitifs les plus répondus chez les personnes âgées sont regroupés sous le terme de démence. La démence est une détérioration des fonctions cognitives, provoquant un changement dans la vie de la personne et une perte d’autonomie. Les démences couramment citées sont la maladie d’Alzheimer et la maladie de Parkinson. Les désordres liés à la marche sont plus répandus chez les personnes âgées ayant des démences que chez les sujets « normaux ». Iersel et al. [Van Iersel et al., 2004] ont comparé ces deux groupes de sujets et en ont déduit que les personnes avec des démences ont une vitesse de marche plus lente, des longueurs de pas plus petites et un temps de double appui plus grand que les sujets âgés sains. La vitesse de marche plus lente chez les personnes avec des démences est mise en évidence également dans l’article de Bramell-Risberg et al. [Bramell-Risberg et al., 2005]. Plusieurs études ont également déterminé qu’un dysfonctionnement mesuré par une vitesse de marche lente peut être un indicateur de déficits cognitifs précoces ([Holtzer et al., 2006], 645.4. Extraction des indicateurs [Kuo et al., 2007], [Waite et al., 2005]). Les déficits cognitifs sont définis comme une dégradation d’un ou des processus cognitifs mais sans provoquer de perte d’autonomie de la personne. Ce trouble peut éventuellement subvenir plusieurs années avant l’apparition des démences. En sachant que les personnes âgées atteintes de démence ou présentant un déficit cognitif précoce ont une marche altérée, en comparaison aux personnes âgées sans démence et sans déficit, d’autres chercheurs se sont intéressés à l’analyse des indicateurs de la marche pouvant permettre de prévenir une éventuelle apparition de démence ou déficit cognitif dans les mois ou années qui suivent. Bien que le principal signe de démence soit un déclin cognitif, plusieurs articles montrent que des désordres moteurs sont présents au premier stade de la maladie. Selon Camicioli et al. [Camicioli et al., 1998], une marche lente pourrait précéder des déficiences cognitives. Leur expérience consistait à évaluer 85 personnes âgées saines durant 3 ans. L’objectif était de déterminer les différences motrices entre les personnes sans problème cognitif et ceux développant des détériorations cognitives, durant 3 ans. Ils remarquèrent alors que les 18 sujets, développant des troubles cognitifs, avaient un ralentissement moteur (constat à travers le temps mis pour parcourir une certaine distance). Ces différentes études indiquent que l’analyse de la vitesse pourrait améliorer le diagnostic des problèmes cognitifs, en sachant particulièrement que 50 % des personnes affectées par la maladie d’alzheimer sont diagnostiquées et seulement 30 % au premier stade de la maladie ([Ferri et al., 2006], [Rimmer et al., 2005]). De plus, les sujets avec des démences chutent deux ou trois fois plus que les sujets sans déclin cognitif [Shaw, 2002]. 5.4 Extraction des indicateurs L’analyse des paramètres spatio-temporels s’avère être une approche intéressante pour évaluer l’état général d’une personne. Les paramètres auxquels nous allons nous intéresser sont la vitesse de marche, les longueurs de pas et la cadence. Ces paramètres sont extraits à partir des déplacements verticaux du centre de masse de la personne. Plus précisément, les paramètres sont extraits à partir de la courbe lissée (avec le filtre passe-bas ou le filtre de Kalman). 5.4.1 Longueurs de pas Comme nous l’avons déjà défini à la section 5.2.1, la longueur de pas, dans la littérature, correspond à la distance séparant les deux talons lors du double appui de réception. Notre méthode, pour récupérer la longueur de pas, consiste à chercher la position du pied d’appui. Le centre de masse est au plus haut au moment où il se trouve à la vertical du pied d’appui. La position du pied d’appui peut donc être estimée par la projection sur le sol du centre de masse au moment du point max sur la courbe, comme illustré par la figure 5.7. Dans notre cas, la longueur de pas est calculée comme la distance entre la projection de deux maxima locaux consécutifs de la trajectoire du centre de masse sur l’axe vertical. La distance est obtenue en calculant la distance euclidienne entre les deux points (A et B) en trois dimensions : da,b = p (xb − xa) 2 + (yb − ya) 2 + (zb − za) 2 L’extraction de la première longueur de pas est montrée à la figure 5.8. Nous exprimons les longueurs de pas en centimètres. 65Chapitre 5. Mesurer à domicile les paramètres de la marche 5.4.2 Cadence Nous calculons la cadence sur une séquence et non pas pour chaque pas. Pour calculer la cadence de l’ensemble des pas d’une séquence, nous appliquons la formule suivante : Cadence = N ( PN i=1 duree(i)) avec N le nombre de pas réalisés au cours de la séquence et duree(i) la durée du pas i. La cadence est exprimée ici en nombre de pas par seconde. La durée d’un pas est définie comme étant le temps entre le point de contact avec le sol d’un pied et le point de contact de l’autre pied (controlatéral). Pour obtenir la durée du pas, nous utilisons la même méthode que pour extraire les longueurs de pas. Le temps entre la projection de deux maxima locaux consécutifs sur la trajectoire du centre de masse sur l’axe vertical constitue la durée d’un pas. La durée d’un pas est exprimée en secondes. L’extraction de la durée du premier pas est montrée à la figure 5.8. 5.4.3 Vitesse de marche Les vitesses de marche moyenne et instantanée peuvent être calculées de la même façon. Dans la section 5.2.1, nous avions précisé que la vitesse de marche était souvent calculée en chronométrant le temps mis par le sujet pour parcourir une distance donnée. Nous reprenons cette idée pour extraire la vitesse moyenne. La vitesse de marche est calculée par la formule suivante : V itesse = PN i=1 longueur(i) PN i=1 duree(i) avec longueur(i) et duree(i) la longueur de pas (ici, exprimée en mètres) et la durée du pas i. Nous obtenons donc la vitesse de marche moyenne exprimée en mètre par seconde. L’extraction de la vitesse de la marche est montrée à la figure 5.8. Double Appui unilatéral droit appui Appui unilatéral gauche Double appui Double appui Déplacement vertical Figure 5.7 – Correspondance entre le cycle de la marche et la trajectoire du centre de masse sur l’axe vertical. 5.4.4 Résultat Lorsqu’une personne marche en ligne droite perpendiculairement à la caméra, nous obtenons entre 2 et 4 pas d’environ 50 à 60 cm selon les personnes. Les derniers pas de chaque séquence (une séquence correspond au moment où la personne traverse le champ de vision de la caméra 665.5. Conclusion -1600 -1550 -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 7.5 8 8.5 9 9.5 10 10.5 11 Y (mm) Temps (s) Longueur du premier pas Vitesse de marche Durée du premier pas Figure 5.8 – Extraction des paramètres de la marche à partir du centre de masse. en entrant d’un côté et en sortant de l’autre) ne sont pas pris en compte. Les derniers pas correspondent aux moments où la personne sort du champ de vision de la caméra. Une fausse détection du pas peut se produire à proximité des bords de l’image. C’est pourquoi nous préférons enlever le dernier pas de chaque séquence lorsque la personne sort du champ de vision de la caméra. 5.5 Conclusion Ce chapitre nous a permis de poser les bases et les notions à connaître pour comprendre les différentes phases de la marche. Il liste, également, les différents paramètres existants pour analyser la marche de la personne. Les paramètres spatio-temporels représentent l’analyse des longueurs, cadences et vitesses de marche. Les paramètres cinématiques correspondent à l’analyse des angles formés par le pied, le genou et la hanche. Et les paramètres dynamiques étudient les forces de réaction au sol et les pressions plantaires. Les systèmes analysant la marche des personnes sont fondés sur l’analyse d’un ou de plusieurs de ces paramètres. Par exemple, les tapis actimètriques fournissent les paramètres spatio-temporels et les paramètres dynamiques, les accéléromètres, quant à eux, calculent les paramètres cinématiques. Nous avons également présenté, dans ce chapitre, différentes études mettant en évidence des liens entre troubles de la marche et dégradation de l’état de fragilité de la personne. D’après ces articles, l’analyse de la marche peut permettre de prévenir les chutes, les risques d’hospitalisation et les troubles cognitifs. La plupart des études concordent sur le fait que la longueur de pas, la cadence et la vitesse de marche sont des paramètres fiables pour étudier l’évolution de l’état de santé de la personne. Ainsi, nous avons présenté l’algorithme d’extraction de ces trois paramètres, à partir du centre de masse et de la détection des maxima locaux sur l’axe vertical. L’évaluation de la précision des paramètres extraits est présentée dans la prochaine partie. 67Chapitre 5. Mesurer à domicile les paramètres de la marche 68Chapitre 6 Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Sommaire 6.1 Approches pour détecter l’activité . . . . . . . . . . . . . . . . . . 70 6.1.1 Approches non paramétriques . . . . . . . . . . . . . . . . . . . . . 70 6.1.2 Approches volumétriques . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1.3 Approches paramétriques . . . . . . . . . . . . . . . . . . . . . . . . 71 6.2 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.3 Proposition d’un modèle de l’activité . . . . . . . . . . . . . . . . 73 6.3.1 Modèle avec fonction d’observation seule . . . . . . . . . . . . . . . 74 6.3.2 Utilisation d’un MMC unique . . . . . . . . . . . . . . . . . . . . . 75 6.3.3 Utilisation de MMC combinés . . . . . . . . . . . . . . . . . . . . . 79 6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 De nombreuses méthodes ont été développées dans le domaine de la reconnaissance d’activité. Les méthodes de reconnaissance d’activité peuvent être regroupées en trois catégories : les méthodes non paramétriques, les méthodes volumétriques et les méthodes paramétriques. En annexe A, nous présentons en particulier une méthode paramétrique, les modèles de Markov cachés (MMC), sur laquelle nous nous sommes basés pour construire nos modèles de détection d’activité. L’un des intérêts des MMC est de posséder de bonnes capacités de généralisation et donc d’être adaptée à nos contraintes. En effet, les données disponibles pour l’apprentissage sont nécessairement limitées et partiellement représentatives de la diversité des situations pouvant être rencontrées en situation réelle. Nous cherchons à déterminer l’activité d’une personne étant données les mesures que nous pouvons effectuer avec une caméra de profondeur. Cette activité est un état caché, que nous cherchons à déterminer à partir d’une séquence d’observations extraites des images de profondeur de la caméra RGB-D. Ces observations ont été choisies pour leur robustesse et la simplicité avec laquelle elles sont extraites des images de profondeur. Ces indicateurs sont cités au chapitre 4. Il s’agit du centre de masse de la personne, de ses vitesses verticale et horizontale, de la dispersion verticale du corps et du point le plus haut de la silhouette. Nous avons construit plusieurs modèles. Certains sont constitués d’un MMC unique, d’autres plus complexes requièrent plusieurs MMC, un par activité. Nous faisons varier le nombre d’observations et le nombre d’états afin de pouvoir, 69Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur ensuite, les comparer pour déterminer le modèle étant le plus pertinent. Cette comparaison est faite dans le chapitre 8. 6.1 Approches pour détecter l’activité Plusieurs études classifiant les méthodes de détection d’activités à partir d’images vidéo ont été réalisées ces dernières années. Les classifications réalisées sont différentes d’un article à l’autre car la reconnaissance d’activités est un large sujet. Ke et al. [Ke et al., 2013] propose ainsi un dé- coupage de la problématique sur trois niveaux, faisant apparaître les grandes étapes de l’analyse d’images, identifiant plusieurs catégories de problèmes en fonction des objectifs et enfin définissant des types d’applications. Les méthodes d’analyse d’images sont en effet liées au dispositif technique et à son environnement. Il faut par exemple prendre en compte les capacités de la caméra choisie, comme le type de capteur, l’ouverture de son champ de vision, la mobilité ou non de la caméra. La classification peut également être faite en fonction des méthodes d’analyse utilisées qui sont très nombreuses et peuvent s’étudier selon les différents niveaux de traitement de l’image et du flux vidéo. Les méthodes d’analyse dépendent en particulier de la complexité et du type des activités à reconnaitre. Les méthodes pour détecter qu’une personne lève les bras et se fait un thé ne sont, par exemple, pas les mêmes. Les moyens à mettre en œuvre dépendent enfin du contexte applicatif. Par exemple, la reconnaissance d’activités anormales ne requiert pas les mêmes méthodes si on s’intéresse aux activités dangereuses d’une personne dans le métro ou aux chutes des personnes âgées à leur domicile. Le regroupement des méthodes de reconnaissance d’activités peut donc se faire de nombreuses façons et il est par conséquent difficile d’être exhaustif. Ainsi, nous retrouvons dans la littérature des études se focalisant sur les mé- thodes appliquées à la surveillance [Valera and Velastin, 2005], sur la détection des activités des piétons [Enzweiler and Gavrila, 2009] ou encore proposant une classification selon la reconnaissance d’activités d’un groupe de personnes [Aggarwal and Ryoo, 2011]. Comme illustré par la fi- gure 6.1, nous nous intéressons plus spécifiquement à la reconnaissance d’activités simples, c’est à dire ne faisant pas intervenir une séquence longue d’événements, que nous cherchons à reconnaître à l’aide d’une caméra fixe, positionnée dans un environnement relativement peu maitrisé (l’intérieur d’un habitat, avec toute la diversité des aménagements possibles). Nous reprenons, pour positionner notre contribution, la classification réalisée par Turaga et al. [Turaga et al., 2008] qui regroupent les méthodes couramment utilisées pour la détection d’activités simples en trois catégories : les approches non paramétriques, volumétriques et paramétriques. 6.1.1 Approches non paramétriques Ces approches consistent à récupérer une série de caractéristiques à chaque image de la vidéo. Cela permet d’obtenir une séquence de caractéristiques qui sera alors comparée aux séquences de caractéristiques des exemples types qui ont été pré-enregistrés. L’exemple pré-enregistré le plus similaire est considéré comme représentatif de l’activité réalisée par la personne. Cette approche peut être utilisée pour des objets extraits en 2 ou 3 dimensions. 6.1.2 Approches volumétriques Ces approches consistent à analyser en un bloc l’enregistrement vidéo de l’activité réalisée par une personne. L’idée est d’analyser la séquence d’images en une seule fois et non pas image par image. A partir d’une séquence d’images, un volume en trois dimensions est créé à partir de l’ensemble des pixels appartenant à la personne. Chaque image constitue une coupe de ce 706.2. Positionnement Reconnaissance d'activités au domicile Caméra fixe Caméra mobile Plusieurs personnes Personne seule Activités simples Approches non paramétriques Approches volumétriques Approches paramétriques Activités complexes Figure 6.1 – Positionnement du problème de la reconnaissance d’activité au domicile. volume qui représente le trajet effectué par la personne durant la séquence. A partir de ce volume, des caractéristiques sont extraites. Ces caractéristiques peuvent ensuite être comparées aux caractéristiques des exemples pré-enregistrés. 6.1.3 Approches paramétriques Les approches paramétriques consistent à construire un modèle à partir d’hypothèses faites sur la dynamique de l’activité à reconnaitre. Les paramètres spécifiques d’une activité sont appris à partir d’une base d’exemple. Les séquences d’images à reconnaitre sont ensuite confrontées aux modèles des différentes activités. Le modèle le plus représentatif de la séquence permet d’identifier l’activité réalisée. 6.2 Positionnement L’objectif est de détecter les chutes et situations à risque mais aussi de reconnaitre des activités ou postures que peut prendre la personne dans la vie de tous les jours, en différenciant les activités où la personne est passive et celles où la personne est active. Les activités ont été choisies en s’inspirant des travaux de Noury et al. [Noury et al., 2007]. Dans cet article, les auteurs indiquent comment construire un système détectant les chutes. Notamment, ils précisent que pour détecter les chutes, il est nécessaire de confronter le système à des situations réalistes pouvant se confondre aux situations de chute, qui peuvent entraîner des faux positifs. Ils précisent qu’il ne suffit pas de comparer la chute à des activités telles que la marche, mais de prendre également des situations telles que se pencher ou s’accroupir. Ils énumèrent ainsi une liste d’activités à prendre 71Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur en compte pour détecter efficacement les chutes. Nous avons identifié les activités — à risque : chuter et être allongé au sol, monter sur un obstacle ; — passives : être assis, allongé sur un lit ou sur un canapé ; — actives : marcher, s’accroupir, se pencher, debout. Les approches non paramétriques et volumétriques requièrent un grand nombre d’exemples pour rendre la détection d’activité la plus fiable possible. Dans notre cas, nous sommes partis du principe que notre base de données ne peut pas être exhaustive. En effet, il est difficile d’enregistrer toutes les activités ou les postures qu’une personne peut réaliser au cours de la journée. Enregistrer les mouvements naturels et complètement réalistes d’une personne est très difficile à faire en situation de laboratoire. Nous ne disposons, par exemple, pas d’enregistrements de chutes réelles. De plus, une même activité peut se différencier par l’angle de vue de la caméra, l’endroit où elle est réalisée ou la façon qu’ont les personnes de la réaliser. Les personnes âgées peuvent se comporter différemment du fait de leurs capacités motrices plus ou moins conservées. Nous avons donc utilisé des modèles de Markov cachés qui font partie des approches paramétriques et qui ont de bonnes capacités de généralisation à partir d’une base de données restreinte. En plus de la question de la reconnaissance de l’activité, ces modèles permettent de traiter le problème de la segmentation des activités dans les séquences d’images, alors que les autres approches nécessitent de renseigner le début et la fin de l’activité. Dans la littérature, les articles traitant la détection d’activité à l’aide de méthodes paramé- triques utilisent généralement un grand nombre de paramètres extraits des images. Par exemple, dans l’article de Peursum et al. [Peursum et al., 2005], les auteurs décrivent leur méthode pour reconnaître l’action « imprimer » ou « préparer un thé » résultant d’une succession de 15 activités comme « marcher », « s’asseoir », etc. Pour reconnaître ces activités, ils se sont basés sur 10 caractéristiques à extraire de chaque image, comme la taille de la personne, la vitesse horizontale, la longueur du torse, l’angle du torse par rapport au sol, la longueur des mains, la longueur des jambes, etc. L’extraction de ces caractéristiques nécessite d’effectuer un certain nombre de traitements comme extraire la personne, localiser sa main, son torse, ses jambes et mesurer les angles au niveau des articulations. Comme pour le choix des états, les caractéristiques ont été choisies en se basant sur l’article de Noury et al. [Noury et al., 2007]. Les auteurs ont réalisé un état de l’art sur les méthodes utilisées pour développer un système de détection de chute. Ainsi, 4 approches sont couramment utilisées (séparément) pour détecter une chute d’une autre activité : — détecter la position allongée sur le sol ; — détecter l’impact du choc lorsque la personne se cogne au sol ou dans un obstacle, repré- senté par l’inversion de polarité du vecteur d’accélération dans la direction de la trajectoire ; — détecter un manque de mouvement ; — détecter la vitesse verticale, augmentant linéairement, due à l’accélération gravitationnelle lors de la chute. Chaque approche prise séparément peut provoquer des fausses détections. Notre idée est de coupler les sources d’informations pour établir une décision plus robuste et reconnaître des activités pouvant se ressembler (comme se pencher et s’accroupir). Nous avons repris l’idée qu’une chute se produit, lorsque le corps de la personne a une vitesse verticale qui augmente et que la personne se trouve allongée au sol. Pour obtenir ces informations, nous prenons en compte, dans un premier temps, trois caractéristiques, la vitesse verticale du centre de masse, la position du centre de masse et la dispersion verticale du corps de la personne (l’écart-type) sur l’axe vertical, auxquelles nous ajouterons ensuite la vitesse horizontale et la position de la tête. La vitesse verticale du centre de masse informe sur le déplacement du corps à chaque instant. La position 726.3. Proposition d’un modèle de l’activité du centre de masse permet de savoir si la personne est proche du sol. La distribution verticale du corps renseigne sur la forme du corps, ainsi il sera possible de distinguer des activités, comme s’allonger et s’accroupir, qui sont toutes deux des activités où la position du centre de masse est proche du sol et où la vitesse verticale est nulle, mais qui auront des dispersions verticales différentes. Nous proposons une approche nécessitant peu de caractéristiques pour reconnaître l’activité d’une personne tout en étant capable de généraliser à partir d’une base de données restreinte. En effet, la base de données sur laquelle nous travaillons est formée à partir de différentes situations réalisées par 28 sujets jeunes. Ces situations correspondent aux activités que nous voulons détecter. Plus d’informations sur la constitution de cette base est donnée au chapitre 8.1. Il s’agit de trouver un compromis minimisant la complexité du modèle et en particulier le nombre d’observations tout en garantissant une bonne robustesse dans la reconnaissance. Nous proposons plusieurs modèles dont les paramètres peuvent être ajustés par apprentissage mais avec relativement peu de données. Certains de ces modèles permettent de prendre en compte une connaissance de bon sens par la définition manuelle d’une partie des paramètres. Dans la suite de ce chapitre, nous présentons différents modèles d’activité que nous avons évalués. Il différent par le nombre d’activités modélisées, le nombre d’observations et par l’insertion ou non de connaissance a priori. Ces différents modèles sont proposés dans le but d’être ensuite évalués expérimentalement afin d’identifier le niveau de complexité permettant d’obtenir une reconnaissance précise des activités tout en étant suffisamment général pour permettre la reconnaissance de situations éloignées de la base d’apprentissage. 6.3 Proposition d’un modèle de l’activité Les modèles de Markov cachés (MMC) fournissent un cadre efficace pour modéliser des phé- nomènes ou processus régis par une dynamique d’états cachés. Seules des observations partielles sur le processus sont accessibles et les états peuvent être inférés avec une certaine probabilité à partir d’une séquence d’observations. La figure 6.2 illustre un MMC évoluant dans le temps avec Xt les états cachés, représentés en gris, et Ot les observations. Un MMC est défini formellement par : — un ensemble d’états ; — une matrice aij = P(Xt = j|Xt−1 = i) représentant toutes les probabilités de transition entre chaque paire d’états ; — une probabilité initiale πi = P(X0 = i) pour chaque état i, qui est la probabilité a priori que le système se trouve dans l’état i à t = 0 ; — une fonction d’observation bi(o) = P(Ot = o|Xt = i). Des algorithmes d’apprentissage et d’inférence bien connus sont présentés en annexe A. L’objectif est de construire un modèle permettant de reconnaître l’activité réalisée par la personne filmée. X0 O0 X1 O1 Xt Ot Figure 6.2 – Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. 73Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Le modèle le plus simple que nous proposons est constitué d’un état par activité avec pour chaque état une distribution gaussienne formant la fonction d’observation. Les paramètres de ces distributions sont appris à partir de la base de données. Nous ajoutons ensuite à ce modèle de référence une fonction de transition définie manuellement qui nous permet d’injecter de la connaissance sur l’enchainement des activités. La fonction de transition est définie manuellement car nous ne disposons pas de données représentatives des enchainements possibles des situations que nous voulons reconnaitre. Cette seconde proposition prend donc la forme d’un MMC unique permettant de reconnaitre les différentes activités avec un état par activité. Enfin nous proposons d’utiliser plusieurs MMC, un MMC pour chaque activité dont les paramètres sont appris à partir de la base de données. Dans cette dernière proposition les transitions entre activités ne sont pas définies. Il n’y a donc pas de contraintes a priori sur les enchainements ce qui nous permet d’avoir un modèle plus général. 6.3.1 Modèle avec fonction d’observation seule Etats Le modèle contient 8 états correspondant à 8 activités qui sont : s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, chuter et être allongé au sol. Dans ce modèle, les activités « marcher » et « être debout » sont confondues. Observations Nous utilisons les caractéristiques suivantes : — la position du centre de masse sur l’axe vertical ; — la vitesse verticale du centre de masse ; — la dispersion verticale du corps de la personne (l’écart-type) sur l’axe vertical. La fonction d’observation, donnant la probabilité d’observer une valeur o dans l’état i, suit une loi normale multidimensionnelle pour chaque valeur de i : P(O = o|X = i) = 1 (2π)N/2|Σi | 1/2 e −1/2(o−µi) T Σ −1 i (o−µi) (6.1) avec Σi la matrice de covariance, µi la moyenne et N le nombre de dimensions (pour ce MMC le N est égal à 3, car il y a trois observations). Σi et µi sont calculés, pour chaque état i, par apprentissage à partir de la base de données. Après apprentissage, nous obtenons donc 8 lois normales, une pour chaque état. Conclusion Ce modèle sans transition est représenté à la figure 6.3. Sur cette figure, les huit carrés représentent les huit états de notre modèle. Les 8 états représentent les 8 activités réalisées par le sujet, détecté en vert par l’algorithme. Cette figure montre qu’aucune transition n’est définie entre les états. La décision de l’état dans lequel se trouve la personne repose, ici, essentiellement sur les observations. Inférence Pour réaliser l’inférence, l’état Xt le plus probable est donnée à chaque pas de temps en comparant les valeurs prises, pour l’observation ot, par les 8 distributions gaussiennes. Le calcul est le suivant : P(Xt = i|O = ot) = P(O = ot|Xt = i)P(Xt = i) P i P(O = ot|Xt = i)P(Xt = i) . 746.3. Proposition d’un modèle de l’activité Marche Assis Allongé Canapé Chute Allongé Sol Accroupi Monté Penché Figure 6.3 – Modèle à 8 états avec fonction d’observation seule. Nous n’avons pas considéré de différence a priori entre les états. La probabilité P(Xt = i) est donc uniforme pour toutes les valeurs de i et l’équation précédente se résume donc à : P(Xt = i|O = ot) = P(O = ot|Xt = i) P i P(O = ot|Xt = i) . 6.3.2 Utilisation d’un MMC unique Nous ajoutons à la proposition précédente, qui associe un état à chaque activité, une matrice de transition qui modélise l’enchainement dans le temps des activités. Nous obtenons donc un MMC représentant l’activité comme un processus dynamique partiellement observable. Nous proposons dans cette section un premier modèle à 8 états et un second à 9 états. Pour chaque modèle, nous définissons l’espace d’états (les activités à reconnaitre), la probabilité initiale qu’à le processus (l’activité) d’être dans un état donné, la dynamique (transition entre états) ainsi que les observations considérées. Dans ces modèles, la fonction d’observation est apprise à partir de la base de données. La matrice de transition est, quant à elle, définie manuellement. Nous partons en effet du principe qu’il n’est pas possible d’apprendre les transitions entre activités à partir d’une base de donnée constituée en laboratoire. Cette base de donnée, constituée à partir de situations jouées, ne peut pas être représentative de la diversité des enchainements d’activité d’une personne dans la vie de tous les jours. Il est en revanche possible d’injecter une connaissance a priori, de bon sens, par la définition manuelle des probabilités de transition. MMC à 8 états et 3 observations Etats Les états sont les mêmes que précédemment, à savoir : s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, chuter et être allongé au sol. Probabilités initiales Nous considérons qu’au début de l’analyse la personne peut se trouver dans n’importe quel état. Nous attribuons donc la même probabilité initiale pour chaque état, 75Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur soit 0,125. Matrice de transition L’activité est modélisée comme un processus stochastique. Les transitions entre les différents états expriment la dynamique de l’activité qui tient compte autant des contraintes biomécaniques que d’un a priori sur le comportement des personnes. Pour insérer les transitions possibles, nous avons fait plusieurs hypothèses. — La journée d’une personne âgée, à son domicile, peut être résumée en une succession de passages assis-debout. Nous définissons les transitions les plus probables comme étant celles qui mènent vers l’état « Marche ». — La personne marche (ou est debout) juste avant et après avoir effectué les activités « Accroupi », « Monté », « Penché », « Assis ». — Une personne ne peut pas directement passer de la position debout à allonger mais elle doit d’abord s’asseoir pour pouvoir s’allonger. — La probabilité d’aller dans l’état « Chute » est très faible comparée aux autres activités. — Une personne se trouvant allongée au sol est obligatoirement passée par l’état « Chute ». — Une fois au sol, la personne peut soit y rester soit, dans le cas où la personne est capable de se relever, passer directement à l’état « Marche » ou passer par l’état « Accroupi » qui lui permettra de passer par l’état « Marche » (ou être debout) par la suite. Le MMC construit sur la base de ces hypothèses est représenté à la figure 6.4. Les transitions correspondent aux flèches et les états aux rectangles. Nous définissons les probabilités relatives des différentes transitions sur une échelle à quatre niveaux : — pp, la plus petite probabilité de transition ; — p, une probabilité de transition faible ; — m, une probabilité de transition moyenne ; — C, la probabilité majoritaire correspondant au complément à 1 des autres probabilités sortantes de l’état. Observations Le modèle construit ici reprend les 3 mêmes observations que le précédent modèle, à savoir la position et la vitesse verticale du centre de masse et la distribution du corps sur l’axe vertical. La fonction d’observation est également conservée, elle suit une loi normale multidimensionnelle. Conclusion Avec la construction de ce MMC, nous injectons de la connaissance à travers la matrice de transition. MMC à 9 états et 5 observations Dans l’objectif de mesurer les paramètres de la marche d’une personne à son domicile et donc de pouvoir appliquer au domicile les résultats présentés au chapitre 5, il est important d’isoler précisément les moments où la personne se déplace. Cela implique de différencier l’activité « Marche » de l’activité « Debout ». Etats Dans ce nouveau modèle, nous ajoutons un état « Debout » aux huit états précédents. Probabilités initiales Comme pour les précédents modèles, nous attribuons une même probabilité de 1/9 à chaque état. 766.3. Proposition d’un modèle de l’activité Marche Assis Allongé Canapé Allongé Sol Accroupi Chute Monté Penché p C pp p pp p m C p C m C m p p C C m C m C m Figure 6.4 – MMC à 8 états avec des transitions définies manuellement. Matrice de transition Les transitions et les probabilités sont définies sur la base des mêmes hypothèses que celles du modèle précédent, en ajoutant : — l’état « Debout » précède et suit la plupart des activités. Seules les activités « Monté » et « Chute » peuvent être aussi précédées et suivies de l’état « Marche ». Le MMC construit sur la base de ces hypothèses est représenté à la figure 6.4. Les probabilités relatives des différentes transitions sont définies sur la même échelle à quatre niveaux que précédemment. Observation L’ajout de l’état « Debout » nécessite une augmentation du nombre d’observations. En effet, les trois observations précédentes ne suffisent pas à différencier les états « Debout » et « Marche ». Intuitivement, nous pouvons penser que la vitesse horizontale diffère entre les deux états. Nous ajoutons également la position verticale de la tête pour améliorer la robustesse du modèle. Ainsi, dans ce modèle nous insérons 5 observations : la position du centre de masse, la dispersion verticale du corps, la vitesse verticale et la vitesse horizontale du centre de masse et le point maximum du corps. La fonction d’observation suit toujours une loi normale multidimensionnelle avec cette fois un nombre de dimensions égal à 5 soit N = 5 dans la formule 6.1. Comme précédemment, à partir de la base de données, les moyennes µ des cinq observations et la covariance Σ sont calculées pour chacun des neuf états. Nous obtenons ici 9 lois normales. Conclusion Nous voulons ici démontrer que nous pouvons affiner les activités réalisées, notamment distinguer la personne active (marchant) de la personne statique. La contrepartie est d’augmenter la complexité du modèle en augmentant le nombre des observations en passant de 3 à 5. 77Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Marche Debout Assis Allongé Canapé Chute Allongé Sol Accroupi Penché Monté p C pp pp p C p pp p p pp m C p C m C m p p p C C m p C m C m Figure 6.5 – MMC à 9 états avec des transitions définies manuellement. 786.3. Proposition d’un modèle de l’activité Inférence Pour savoir dans quel état se trouve la personne, nous avons implémenté les algorithmes Forward-Backward et de Viterbi, décrit en annexe A. En implémentant les deux algorithmes, les plus couramment utilisés avec les MMC, nous avons voulu savoir si des différences notables pouvaient apparaître dans la décision finale de l’état dans lequel se trouve la personne. La comparaison des deux algorithmes est présentée dans le chapitre 8 lors de la présentation des résultats de l’expérimentation. 6.3.3 Utilisation de MMC combinés Dans les modèles précédents, chaque activité correspondait à un état et nous obtenions donc un MMC à 8 ou 9 états selon le modèle. Avec l’approche multi-modèles, chaque activité correspond à un MMC, nous obtenons donc 8 ou 9 MMC selon le nombre d’activités à reconnaître. Une autre différence avec les modèles précédents est que nous n’insérons aucune connaissance a priori (ni transition, ni probabilité initiale). Comme dans le cas du modèle avec les observations seules, la dynamique entre les situations n’est pas prise en compte. Système de 8 MMC Etat Nous construisons deux types de systèmes de modèles. Ces deux systèmes de modèles sont identiques à la seule différence que l’un est constitué de 8 MMC à 2 états et l’autre à trois états chacun. Nous voulions ainsi tester l’influence qu’a le nombre d’état choisi. Probabilités initiales et matrice de transition Comme nous venons de le préciser, aucune connaissance n’est insérée dans ce modèle. Cela signifie que nous ne définissons pas manuellement les probabilités de transition et les probabilités initiales. Ces probabilités sont apprises automatiquement à partir de la base de données. Observations Les observations sont les mêmes que pour les MMC à 8 états, à savoir la position et la vitesse du centre de masse sur l’axe vertical et la distribution du corps sur l’axe vertical. Chacun des huit MMC se base sur ces trois observations. La fonction d’observation reste elle aussi inchangée, elle suit une loi normale multidimensionnelle. Les paramètres de cette loi normale sont calculés à partir de la base de données. Les paramètres sont appris pour chaque état des 8 MMC. Nous obtenons donc 16 ou 24 lois normales selon le modèle à deux ou trois états par MMC. Conclusion Le système des 8 MMC à deux états chacun et sans probabilité de transition est représenté à la figure 6.6. Nous appliquons à ces systèmes de modèle l’algorithme de BaumWelch permettant d’apprendre par lui-même les paramètres du MMC, à partir de la base de données. Les paramètres qui sont appris sont les probabilités de transition entre chaque état, les probabilités initiales et les lois normales pour chaque état. Le nombre d’états pour chacun des 8 MMC est le seul paramètre que nous déterminons à la main. Système de 9 MMC Etat Comme précédemment, nous construisons deux types de systèmes de modèles. C’est-à- dire que nous développons un système de 9 modèles à 2 états et un autre système à trois états chacun. 79Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Accroupi Chute Allongé Sol Monté Marche Assis Penché Allongé Canapé Figure 6.6 – Système de 8 MMC à deux états chacun. Probabilités initiales et matrice de transition Comme précédemment aucune connaissance n’est insérée dans ce modèle. Cela signifie que les probabilités initiales et les matrices de transition sont apprises automatiquement à partir de la base de données. Observations Les observations sont les mêmes que pour les MMC à 9 états, à savoir la position et la vitesse du centre de masse sur l’axe vertical, la dispersion du corps sur l’axe vertical, la vitesse horizontale du centre de masse et la position du point maximum du corps. Chacun des neuf MMC se base sur ces cinq observations. La fonction d’observation reste elle aussi inchangée, elle suit une loi normale multidimensionnelle. Les paramètres de cette loi normale sont calculés à partir de la base de données. Les paramètres sont appris pour chaque état des 9 MMC. Nous obtenons donc 18 ou 27 lois normales selon le modèle à deux ou trois états par MMC. Conclusion Le système des 9 MMC à deux états chacun et sans probabilité de transition est représenté à la figure 6.7. Nous appliquons à ces systèmes de modèle, comme pour les 8 MMC, l’algorithme de Baum-Welch permettant d’apprendre par lui-même les paramètres du MMC à partir de la base de données. Les paramètres, qui sont appris, sont les probabilités de transition entre chaque état, les probabilités initiales et les lois normales pour chaque état. Le nombre d’états pour chacun des 9 MMC est donc le seul paramètre que nous déterminons à la main. Inférence Pour savoir dans quel état se trouve la personne, nous devons d’abord appliquer un algorithme d’apprentissage, avant d’utiliser les algorithmes d’inférence, comme décrit en annexe A. Nous avons donc utilisé l’algorithme de Baum-Welch pour apprendre les paramètres de chaque modèle à partir de la base de données que nous avons construite. L’inférence est réalisée, avec l’algorithme Forward, en calculant à chaque pas de temps la vraisemblance des différents modèles sur les 806.4. Conclusion Accroupi Chute Allongé Sol Monté Marche Assis Penché Debout Allongé Canapé Figure 6.7 – Système de 9 MMC à deux états chacun. dernières images de la séquence. L’activité la plus probable est celle qui correspond au modèle donnant la plus grande vraisemblance. 6.4 Conclusion Dans ce chapitre, nous avons présenté les différents modèles que nous avons construits pour reconnaître l’activité. Chaque modèle a des avantages et inconvénients. Certains modèles sont plus simples en ne prenant que trois observations (les modèles à 8 états ou 8 MMC combinés) mais ne font, par conséquent, pas la différence entre être debout et marcher (comme c’est le cas avec les modèles à 9 états ou 9 MMC combinés). Certains modèles n’ont pas de connaissance a priori et reposent sur un nombre plus grand de paramètres à apprendre, ce qui implique de travailler avec une base de données plus importante comparée aux modèles où l’on insère les paramètres manuellement en utilisant une connaissance humaine de l’enchainement des situations. Les résultats donnant les meilleurs taux de classification sont présentés dans le chapitre 8. 81Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur 82Conclusion Nous avons identifié la caméra de profondeur comme capteur répondant à nos besoins pour développer un système de maintien à domicile des personnes âgées. Un certain nombre de traitements sur le flux vidéo sont à effectuer pour, ensuite, pouvoir extraire de l’information de plus haut niveau, comme détecter l’activité ou analyser la marche d’une personne. Le premier chapitre nous a permis de présenter les différentes méthodes en vision pour détecter la personne et la suivre au cours du temps sur l’ensemble des images fournies par la caméra. L’état de l’art n’est pas exhaustif, mais nous avons identifié les méthodes utilisées pour détecter et suivre une seule personne en intérieur avec une caméra fixe. Le deuxième chapitre présente les algorithmes de détection de la personne et de suivi que nous avons développés. Nous avons opté pour des méthodes légères, ne nécessitant pas de temps de calcul importants pour que ces méthodes restent compatibles avec les objectifs de traitement bas coût et de temps réel, que nous nous sommes fixés. A partir des images de profondeur, fournies par la caméra, nous obtenons le fond par apprentissage, puis la silhouette de la personne est extraite par soustraction avec l’image de profondeur courante. La silhouette est représentée par un ensemble de points, dont sont extraits 5 paramètres : le centre de masse, la vitesse verticale et la vitesse horizontale du centre de masse, la dispersion verticale et le point maximum de la silhouette. L’algorithme d’analyse de la marche, développé dans le troisième chapitre, nous permettra d’évaluer le degré de fragilité de la personne en analysant l’évolution des paramètres de la marche spatio-temporels (longueurs, cadence, vitesse de marche). Cet algorithme est très simple, puisqu’il se base uniquement sur l’information du centre de masse et la détection des maxima locaux sur l’axe vertical. Ainsi, le système peut fournir, en temps réel, les paramètres de la marche de la personne suivie. Il sera alors possible d’observer des évolutions des paramètres de la marche au cours du temps, pour déterminer des éventuels risques de perte d’autonomie. Actuellement, les médecins observent certains de ces paramètres en consultation et évaluent l’évolution lors des visites suivantes. Le problème étant qu’entre chaque visite, il peut se passer quelques mois. Or, il serait possible d’effectuer une analyse quotidienne des paramètres de la marche en installant notre système au domicile des personnes. Ainsi, l’évaluation de la fragilité d’une personne pourrait être faite à partir d’un plus grand volume d’informations. Le quatrième chapitre est consacré à la présentation des algorithmes utilisés pour reconnaître l’activité d’une personne. Le but de cet axe de recherche est de sécuriser et évaluer la personne. Ainsi pour sécuriser la personne, nous voulons développer un système détectant la chute et les situations à risque telles que monter sur une chaise et s’accroupir, qui sont des activités pouvant conduire à une chute, en particulier chez les personnes âgées. Puis, pour évaluer la personne, nous voulons développer un système capable de déterminer si la personne réalise des activités actives, autres que s’asseoir et s’allonger. Ainsi, nous avons construit un algorithme qui identifie les activités suivantes : s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, chuter et être allongé au sol. 83Conclusion Parmi les méthodes existantes pour reconnaître les activités, nous avons choisi de développer un algorithme appartenant à la catégorie des méthodes paramétriques. L’une des difficultés, en reconnaissance d’activité, est la variabilité des données, du fait de la différence entre les personnes, de la façon qu’elles ont de réaliser les activités, de l’angle de vue de la caméra, etc. Nous avons choisi les modèles de Markov cachés qui ont de bonnes capacités de généralisation. Dans ce quatrième chapitre, nous avons présenté différents modèles que nous avons construits pour reconnaître l’activité. Nous avons proposé deux approches. La première utilise un modèle unique dans lequel une connaissance a priori est injectée par la définition de la matrice de transition. Dans la seconde, plusieurs modèles sont construits par apprentissage et les transitions entre activités ne sont pas modélisées. Nous avons fait varier la complexité des modèles en jouant sur le nombre d’activité à reconnaître et sur le nombre d’observations. Nous avons construit des modèles pour reconnaître 8 activités, utilisant 3 observations, la position et la vitesse verticale du centre de masse et la distribution verticale de la silhouette. Nous avons construit d’autres modèles reconnaissant 9 activités en ajoutant l’activité « Debout ». Ces modèles discriminent les 9 activités à partir de 5 observations, les trois mêmes que précédemment, en ajoutant la vitesse horizontale du centre de masse et le point le plus haut du corps. Dans le cas des systèmes de MMC, nous avons implémenté l’algorithme de Baum-Welch pour apprendre les paramètres des modèles, puis nous avons implémenté Forward pour inférer l’état dans lequel se trouve la personne. Dans le cas des MMC uniques, nous avons implémenté l’algorithme Forward-Backward et de Viterbi pour inférer l’état à partir de la séquence d’observation. Le point commun entre tous ces modèles est qu’ils sont fondés sur peu d’observations et que ces observations sont simples à extraire des images. Les différents modèles sont ensuite testés et comparés sur la base du nombre de bonnes classifications qu’ils effectuent. Les résultats sont présentés au chapitre 8. 84Troisième partie Evaluation du système 85Introduction Dans les deux chapitres précédents, nous avons présenté nos contributions à la reconnaissance d’activités et à l’analyse en milieu écologique des paramètres de la marche. Dans cette partie, nous en évaluons les performances. Plusieurs expérimentations sont mises en place. Les deux premiers chapitres présentent des expérimentations qui ont été menées dans un appartement expérimental avec des sujets jeunes. Le dernier chapitre présente quelques résultats obtenus avec des personnes âgées. Le premier chapitre décrit une expérimentation qui a été menée pour vérifier les performances du dispositif d’analyse de la marche que nous proposons, en comparaison avec les mesures fournies par un tapis actimètrique que nous considérons comme la vérité terrain. Dans cette expérimentation, nous testons la précision pour différentes situations, pouvant être rencontrées dans la réalité. Par exemple, nous avons demandé aux personnes de marcher perpendiculairement à la caméra, puis de face, ensuite nous leur avons demandé de faire des petits pas comme pourraient le faire des personnes âgées. Les résultats nous montrent que le système est précis lorsque la personne marche perpendiculairement à la caméra, et ce pour toutes les situations. Le deuxième chapitre teste l’algorithme de détection des activités. Nous avons constitué une base de données à partir de laquelle, une partie des séquences sont conservées pour que l’algorithme apprenne, automatiquement, les paramètres de chaque MMC. Nous évaluons, ensuite, les modèles sur la base du nombre de bonnes classifications des séquences restantes. Les modèles à 8 états ou 8 MMC donnent les meilleurs résultats sur des séquences proches de celles constituant la base d’apprentissage, avec la personne entièrement visible. Nous testons les capacités de gé- néralisation de l’algorithme avec une deuxième expérimentation. Nous présentons à l’algorithme des séquences où la personne n’est pas entièrement visible. Les résultats montrent que certains modèles sont robustes sur ces nouvelles séquences, ce qui est le cas pour le modèle à 9 états. Le dernier chapitre de cette partie présente des tests qui ont été effectués dans un hôpital et au domicile, avec des personnes âgées. 6 personnes âgées ont marché devant notre système. Il ne s’agit pas d’une réelle expérimentation mais de premiers tests pour lesquels nous n’avons effectué qu’une analyse qualitative des résultats. Concernant l’algorithme de la marche, les résultats montrent que, malgré l’irrégularité des trajectoires du centre de masse, comparées aux trajectoires que nous obtenions avec des sujets plus jeunes, l’algorithme réussit à extraire des paramètres de la marche. Concernant la détection des activités, seules quelques activités ont été testées. Parmi celles-ci, la marche, la position assise et la position penchée ont été reconnues. 87Introduction 88Chapitre 7 Expérimentations pour l’analyse de la marche Sommaire 7.1 Première évaluation du système . . . . . . . . . . . . . . . . . . . 89 7.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 89 7.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.2 Évaluation globale du système . . . . . . . . . . . . . . . . . . . . 94 7.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 94 7.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.3 Discussion et conclusion . . . . . . . . . . . . . . . . . . . . . . . . 97 L’expérimentation a pour but de tester la précision des paramètres de la marche fournis par notre algorithme, lorsqu’une personne marche dans le champ de vision de la caméra. Une première évaluation a tout d’abord été réalisée. L’objectif est de vérifier que l’algorithme est assez robuste pour commencer l’évaluation et de valider ou non certaines hypothèses. A la suite des résultats obtenus avec cette première évaluation, le protocole expérimental d’une seconde expérimentation a été construit. 7.1 Première évaluation du système Cette section présente la première évaluation basée sur le papier et l’encre et qui constitue notre référence pour évaluer la précision de l’algorithme à extraire les indicateurs de la marche. Nous présentons le protocole expérimental et les résultats. 7.1.1 Description de l’expérimentation 5 sujets sains ont intégré l’expérience dont une femme et quatre hommes, âgés de 20 à 53 ans. L’expérience consiste à placer, sur environ 4 m2 , du papier blanc au sol (figure 7.1(b)). Nous avons placé des tampons imbibés d’encre sur la pointe et le talon des chaussures du sujet, comme montré à la figure 7.1(a). Ainsi lorsque le sujet marche sur le papier, il le marque de ses pas. Des méthodes similaires de marquage sur le sol peuvent être trouvées dans la littérature. Notamment, Georges Gilles de la Tourette a utilisé une technique similaire pour enregistrer la marche [André et al., 2001]. Cette méthode a l’avantage d’être simple à mettre en place, peu 89Chapitre 7. Expérimentations pour l’analyse de la marche coûteuse et de ne nécessiter aucun équipement spécifique. Dans le cadre de l’expérience, la méthode « papier/encre » est considérée comme l’étalon permettant d’obtenir la vérité terrain. L’unique variable prise en compte dans cette étude est la longueur de pas. Pour obtenir les longueurs de pas, l’expérimentateur mesure manuellement la distance entre la marque du talon droit et celle du talon gauche sur le papier. Ces longueurs de pas sont alors comparées aux longueurs fournies par notre approche fondée sur une caméra RGB-D. (a) Tampons imbibés d’encre sous les chaussures. (b) Un sujet marche sur le papier et le marque. Figure 7.1 – Méthode utilisée comme référence pour mesurer les longueurs de pas. Le sujet marche perpendiculairement à la caméra. Sachant que les personnes âgées font des plus petits pas [Hageman and Blanke, 1986] que les sujets testés dans notre étude, nous évaluons la précision de l’algorithme en le sollicitant sur un large échantillon de longueurs de pas. Les sujets réalisent les deux situations suivantes : — marcher en ligne droite « normalement » ; — marcher en ligne droite en faisant des petits pas. Cette première évaluation a plusieurs objectifs : 1. évaluer si les résultats sont invariants à l’angle de la caméra, 2. évaluer la précision des mesures en fonction des différents algorithmes de filtrage choisis. Nous voulons savoir si l’angle de la caméra a une incidence sur les résultats. C’est pourquoi les sujets réalisent les deux situations citées précédemment deux fois, une fois avec un angle égal à -27˚ et l’autre à 0˚. Le placement de la caméra avec un angle à -27˚ correspond à la caméra positionnée en haut de la figure 7.2 et la caméra avec un angle à 0˚ correspond à la caméra positionnée en bas de la figure 7.2. Lors de l’expérience, une seule caméra enregistre à la fois. Nous voulons aussi tester la précision des longueurs de pas fournies par l’algorithme en fonction du filtre de lissage de la trajectoire du centre de masse sélectionné. A la section 4.2.2, deux méthodes de lissage des trajectoires ont été présentées, une méthode utilisant le filtre de Kalman et une autre utilisant un filtre passe-bas. Nous voulons savoir si la précision de l’extraction des maxima locaux, permettant d’obtenir les longueurs de pas, dépend du filtre utilisé. Pour tester la précision de notre algorithme, nous comparons les longueurs de pas fournies par le papier avec les longueurs fournies par l’algorithme utilisant soit le filtre de Kalman, soit le filtre passe-bas. 907.1. Première évaluation du système Figure 7.2 – Positionnement des caméras : la plus basse avec un angle de 0˚ et la plus haute avec un angle de -27˚. 7.1.2 Résultats Pour réaliser les différents tests statistiques et les graphes, nous avons utilisé le logiciel R (qui est un langage et un environnement pour les calculs statistiques). Angle de la caméra Afin de savoir si l’angle de la caméra modifie la qualité des résultats, les erreurs moyennes des longueurs de pas, obtenues quand la caméra a un angle à -27˚ et à 0˚, sont calculées. Plus précisément, nous calculons l’erreur entre les longueurs fournies par le papier et par notre algorithme selon l’angle de la caméra, pour chaque pas. L’erreur moyenne est calculée comme la moyenne sur toutes les erreurs, considérant d’un côté les données pour la caméra à -27˚ et de l’autre les données pour la caméra à 0˚. Les résultats sont montrés à la Table 7.1. L’erreur moyenne est donnée en centimètres et en pourcentages. Les erreurs moyennes sont similaires entre la caméra à -27˚ et à 0˚. Comme indiqué par la table, l’erreur moyenne avec l’angle à -27˚ est de 5,4 cm soit une erreur moyenne de 11,6 %. Ce résultat est proche de l’erreur moyenne de 5,2 cm, soit une erreur moyenne de 11,9 %, obtenue avec l’angle à 0˚. Un test statistique complète ces résultats, dans le but de savoir si les erreurs sur les longueurs de pas obtenues avec les deux angles sont significativement différentes. Avec un test de Student, pour deux échantillons indépendants, la p-value obtenue est de 0,4777. La p-value étant plus grande que 0, 05, nous ne pouvons pas en conclure qu’il existe une différence significative entre les résultats fournis par la caméra positionnée à -27˚ et celle positionnée à 0˚. Pour finir, le graphe, de la figure 7.3, montre que la variabilité des erreurs sur les longueurs de pas est la même pour l’angle à 0˚ que pour l’angle à -27˚. Cela est montré par la forme des deux boites à moustache. La conclusion, que nous pouvons faire, est que notre algorithme est robuste à l’angle de la caméra choisi. 91Chapitre 7. Expérimentations pour l’analyse de la marche Angle -27˚ Angle 0˚ Erreur moyenne (cm) 5,4 5,2 Erreur moyenne (%) 11,6 11,9 Nombre de pas 56 50 Table 7.1 – Comparaison des résultats, entre le tapis et la caméra, en fonction de l’angle de la caméra. Angle de 0° Angle de 27° -5 0 5 10 15 20 Erreur (cm) Figure 7.3 – Représentation des erreurs sur les longueurs de pas obtenues à partir d’une caméra avec un angle de -27˚ et avec un angle de 0˚. 927.1. Première évaluation du système Choix du filtre Dans cette partie, le système est évalué sur la précision des longueurs de pas qu’il fournit, en fonction du filtre de lissage de la trajectoire du centre de masse. La trajectoire qui est correctement filtrée, nous permet de localiser plus précisément les maxima locaux, et ainsi nous permet d’en déduire les longueurs de pas les plus justes. Nous voulons ainsi tester la précision des longueurs de pas lorsque l’algorithme utilise le filtre de Kalman et le filtre passe-bas. Suite à l’expérience effectuée sur 5 sujets, nous avons extrait les pas et selon le filtre utilisé, le filtre de Kalman ou le filtre passe-bas, nous obtenons des pas différents. 106 pas ont été récupérés en utilisant le filtre de Kalman, dont 39 sont de longueurs « normales » (supérieures à 50 cm) et 67 sont de « petites » longueurs (inférieures à 50 cm). 108 pas ont été récupéré en utilisant le filtre passe-bas dont 40 sont de longueurs « normales » et 68 sont de « petites » longueurs. Les erreurs entre les longueurs de pas fournies par le papier et par notre algorithme sont calculées pour chaque pas. L’erreur moyenne (en centimètres et en pourcentage) est calculée comme la moyenne sur toutes les erreurs, considérant toutes les données, ensuite considérant seulement les longueurs « normales » et finalement que les « petites » longueurs. Les résultats sont montrés à la Table 7.2. Les colonnes représentent la distinction entre les données, « Tous » signifie que tous les pas sont pris, « Normaux » signifie que tous les pas considérés comme « normaux » sont sélectionnés et « Petits » signifie que les petits pas sont analysés. Nous présentons les résultats pour le filtre de Kalman et pour le filtre passe-bas (noté « valeur filtre de Kalman | valeur filtre passe-bas » dans chaque case de la table). Cette table nous montre qu’il y a une différence entre l’erreur moyenne obtenue avec le filtre de Kalman et avec le filtre passe-bas. En effet, pour toutes les longueurs de pas, l’erreur moyenne pour le filtre de Kalman est 5,3 cm, soit 11,8 %, et pour le filtre passe-bas nous obtenons une erreur moyenne de 6,9 cm, soit 15,6 %. La décomposition des données en pas normaux et petit pas nous permet de constater que l’erreur moyenne sur la série de données est principalement due aux erreurs sur les petits pas. L’erreur moyenne, pour le filtre de Kalman, pour les petits pas est de 4, 7 cm, soit 12,8 % et pour les pas normaux, l’erreur est 6,4 cm, soit 10,0 %. L’erreur moyenne, avec le filtre passe-bas, pour les petits pas est de 6,5 cm, soit 18,0 % et pour les pas normaux, l’erreur est de 7,5 cm, soit 11,7 %. Les boites à moustaches de la figure 7.4 permettent d’observer la variabilité des données. Les médianes des deux filtres sont identiques (représentées par la barre du milieu dans la boite). Cependant, le filtre passe-bas ne lisse pas toujours les données correctement, ce qui provoque une erreur dans l’extraction des maxima locaux indiquée par les valeurs aberrantes de la figure. Les valeurs aberrantes sont représentées par les cercles en dehors de la boite à moustache. Tous Normaux Petits Erreur moyenne (cm) 5,3|6,9 6,4|7,5 4,7|6,5 Erreur moyenne (%) 11,8|15,6 10,0|11,7 12,8|18,0 Nombre de pas 106|108 39|40 67|68 Table 7.2 – Précision des longueurs de pas fournies par l’algorithme, obtenues avec un filtre de Kalman et avec un filtre passe-bas (pour tous les pas, pour les pas « normaux » et pour les petits pas). 93Chapitre 7. Expérimentations pour l’analyse de la marche Filtre passe-bas Filtre Kalman -10 0 10 20 30 40 20 30 40 Erreur (cm) Figure 7.4 – Représentation des erreurs sur les longueurs de pas extraites à partir du filtre de Kalman et du filtre passe-bas. 7.1.3 Conclusion Cette première expérience nous permet de conclure que la hauteur et l’angle de la caméra n’ont pas d’influence sur la précision des paramètres de la marche fournis par notre dispositif. Cette expérience nous permet également de constater qu’il est préférable de filtrer la trajectoire du centre de masse avec un filtre de Kalman. En effet, les longueurs de pas obtenues lorsque la trajectoire est filtrée par Kalman sont plus proches des valeurs réelles que les longueurs de pas obtenues lorsque la trajectoire est filtrée par un filtre passe-bas. 7.2 Évaluation globale du système Les résultats obtenus dans la première évaluation permettent de constater qu’une expérience plus importante peut être réalisée et surtout permet de construire le nouveau protocole expérimental en prenant en compte les hypothèses que nous venons de tester. 7.2.1 Description de l’expérimentation 11 sujets sains ont intégré l’expérience, dont quatre femmes et sept hommes, âgés de 22 à 53 ans. L’expérience consiste à marcher sur un tapis actimètrique (le tapis de la marque GAITRite) de 5 mètres de longueur, comme montré à la figure 7.5. L’utilisation du tapis est une méthode plus coûteuse que la méthode « papier/encre », mais l’avantage est que nous pouvons traiter plus de données, car l’obtention des paramètres de la marche est automatisée. De plus, la récupération des longueurs de pas, dans la première évaluation, pouvait comporter des erreurs, car cette tâche était effectuée manuellement. L’erreur de mesure avec le tapis est 1,27 cm, représentant la distance entre chaque capteur. Les paramètres de la marche obtenus avec le tapis sont comparés aux valeurs fournies par l’algorithme de la caméra. Dans cette expérience, les trois paramètres de la marche sont comparés : les longueurs de pas, la cadence et la vitesse de la marche. 947.2. Évaluation globale du système Figure 7.5 – Expérience comprenant un tapis actimètrique. La première évaluation permet de structurer la nouvelle expérimentation. Notamment, elle nous a permis de constater qu’il n’y avait pas de différence significative concernant la précision des longueurs de pas liée à l’angle de la caméra (entre un angle de -27˚et 0˚). Donc, dans cette nouvelle expérience, nous considérons cette hypothèse de l’angle de la caméra comme avérée et c’est pourquoi nous ne testons pas différents angles, mais gardons le même pour toute l’expérience. La caméra est positionnée en hauteur avec un angle de -27˚. De plus, la première évaluation a montré que le filtre de Kalman donnait une meilleure précision des longueurs de pas comparé au filtre passe-bas. Donc, nous analysons uniquement les paramètres extraits à partir du filtre de Kalman. Enfin, lorsque les longueurs de pas sur le papier ont été récupérées, le dernier pas n’était pas conservé, étant situé au bord de l’image à l’endroit où le sujet quitte le champ de vision de la caméra. Les derniers pas sont donc enlevés pour chaque séquence dans cette nouvelle expérience. Comme dans la première évaluation, pour tester un large échantillon de données, les sujets marchent normalement puis font des petits pas. Trois nouvelles situations sont ajoutées : — marcher avec une longue robe (allant jusqu’au pied et pour tous les sujets) pour savoir si les vêtements peuvent perturber l’extraction des paramètres de la marche ; — marcher face à la caméra, toutes les autres situations étant réalisées avec la caméra positionnée perpendiculairement aux sujets ; — marcher avec deux caméras observant la même scène pour savoir si l’interférence ne dé- grade pas la précision des résultats. Pour suivre une personne à son domicile nous avons en effet besoin de couvrir les différentes pièces avec plusieurs caméras. En plaçant dans une même pièce plusieurs caméras, il est probable qu’il y ait des recouvrements entre leurs champs de vision. Avec la dernière situation, nous voulons évaluer si dans cette zone commune les résultats sont dégradés, car la caméra RGB-D que nous utilisons est un capteur actif. Les 11 sujets réalisent les cinq situations trois fois pour permettre d’obtenir une base de données suffisantes en nombre de pas. 7.2.2 Résultats Les valeurs des longueurs de pas, de la cadence et de la vitesse de marche sont mesurées avec le tapis et avec notre dispositif pour chaque séquence. Nous traitons 165 séquences, composées chacune de 2 à 5 pas, selon les sujets et la situation analysée. Les résultats sont présentés, dans 95Chapitre 7. Expérimentations pour l’analyse de la marche un premier temps, à travers une analyse de l’erreur sur chaque séquence, puis à travers une étude évaluant la moyenne des paramètres de la marche. Résultats basés sur l’erreur de chaque séquence Les erreurs entre les moyennes des paramètres de la marche, fournies par le tapis et notre algorithme, sont calculées pour chaque séquence. Les séquences sont ensuite regroupées par situations et nous présentons l’erreur moyenne calculée pour chaque situation. La table 7.3 montre les résultats. Dans chaque case de la table, le premier chiffre correspond soit aux erreurs moyennes des longueurs de pas exprimées en centimètres, soit aux erreurs moyennes de la cadence exprimée en nombre de pas par seconde, soit aux erreurs moyennes des vitesses en mètre par seconde. Puis le deuxième chiffre correspond à l’écart-type de ces données et le troisième à l’erreur en pourcentage. Normal Petit Jupe 2 caméras Face Long (cm|σ|%) 2,5|1,6|3,7 1,9|1,7|4,7 2,7|1,8|4,6 3,8|2,8|5,5 9,0|9,5|12,5 Cad (Pas/s|σ|%) 0,09|0,08|6,2 0,10|0,08|6,7 0,06|0,07|3,9 0,09|0,06|6,0 0,14|0,13|8,8 Vit (m/s|σ|%) 0,04|0,02|3,7 0,02|0,01|3,3 0,04|0,02|4,4 0,02|0,02|2,0 0,11|0,09|10,0 Nombre de pas 50 94 61 44 34 Table 7.3 – Erreurs moyennes des longueurs (Long), cadences (Cad) et vitesses (Vit) pour chaque situation. Les erreurs moyennes des longueurs, concernant les situations « Normal », « Petit » et « Jupe », sont similaires avec une erreur moyenne de 3,7 % à 4,7 %, représentant une erreur de moins de 2,7 cm. L’erreur moyenne, pour la situation où il y a deux caméras, est un peu plus grande avec une erreur de 5,5 %. L’erreur moyenne des longueurs est extrêmement grande avec une valeur de 12,5 % pour la situation où la personne marche face à la caméra. Les erreurs concernant les cadences sont plus grandes, à part pour la situation « Jupe » qui conserve une erreur d’environ 3,9 %. Les erreurs moyennes pour « Normal », « Petit » et « 2 caméras » sont entre 6 % et 6,7 %. L’erreur moyenne pour la situation « Face » est la plus grande, avec une erreur de 8,8 %. Les erreurs commises pour les vitesses sont inférieurs aux erreurs des deux autres paramètres de la marche. Pour les situations « Normal », « Petit », « 2 caméras » et « Jupe », les erreurs moyenne vont de 2,0 % à 4,4 %. En revanche, l’erreur moyenne pour la situation « Face » est très grande, soit 10,0 %. Résultats basés sur la moyenne de chaque paramètre de la marche Une autre façon d’analyser les résultats est de calculer la moyenne, pour toutes les séquences d’une même situation, de chaque paramètres de la marche. Les résultats sont montrés à la table 7.4. Cette table représente toutes les moyennes et les écart-types (notés σ) calculés, pour chaque paramètre et chaque situation, à partir des mesures fournies par le tapis et par notre algorithme. Pour les longueurs de pas, nous pouvons voir qu’il n’y a pas de grosses différences entre les moyennes obtenues avec le tapis et avec notre algorithme quelque soit la situation. L’écart maximal, entre le tapis et la caméra, est de 2,2 cm, obtenu pour la situation où les personnes portaient une jupe. Les situations « Normal », « 2 caméras » et « Petit » sont celles pour 967.3. Discussion et conclusion Longueur(cm) Cadence(Pas/s) Vitesse(m/s) Situation Technique Moyenne | σ Moyenne | σ Moyenne | σ Pas normaux Tapis 67,6 | 7,11 1,53 | 0,15 1,09 | 0,12 Caméra 67,0 | 8,31 1,61 | 0,20 1,12 | 0,12 Petits pas Tapis 38,4 | 6,82 1,44 | 0,19 0,57 | 0,11 Caméra 38,3 | 9,09 1,51 | 0,24 0,59 | 0,12 Avec jupe Tapis 57,1 | 8,72 1,46 | 0,31 0,92 | 0,14 Caméra 59,3 | 9,93 1,49 | 0,31 0,96 | 0,13 Face caméra Tapis 68,1 | 7,18 1,64 | 0,13 1,13 | 0,16 Caméra 66,5 | 27,77 1,61 | 0,75 1,02 | 0,16 Deux caméras Tapis 66,9 | 6,91 1,55 | 0,13 1,10 | 0,16 Caméra 66,8 | 8,65 1,60 | 0,16 1,11 | 0,16 Table 7.4 – Comparaison des paramètres de la marche obtenus avec le tapis et avec notre algorithme utilisant la caméra. lesquelles les écarts entre les moyennes du tapis et de la caméra sont les plus faibles. Pour la situation « Face », nous obtenons une erreur de 1,6 cm, mais avec une très grande variabilité. L’écart entre l’écart-type pour le tapis et pour la caméra est de 20 cm. Pour la cadence, l’écart entre les moyennes du tapis et de la caméra n’excède pas une erreur de 0,08 pas par seconde. Concernant la vitesse de marche, l’erreur est plus importante pour la situation « Face » que pour les autres situations. Pour la situation « Face », l’écart entre les moyennes est de 0,11 m/s alors que dans les autres situations, elle n’excède pas 0,04 m/s. 7.3 Discussion et conclusion Une première évaluation nous a permis de constater que le système fournit des valeurs proches de la réalité. Nous en avons déduit qu’il était possible d’investir dans une expérimentation plus importante. Cette première évaluation nous a également permis de valider l’hypothèse que l’angle de la caméra n’a pas d’influence sur la précision des résultats. Aussi, elle nous a permis de remarquer que le lissage de la trajectoire du centre de masse avec le filtre de Kalman fournit une plus grande précision des longueurs de pas comparée à la précision obtenue avec le filtre passe-bas. La seconde évaluation avait pour but de tester la précision des paramètres de la marche, obtenue avec la caméra, dans diverses situations pouvant être rencontrées au domicile. Ainsi lorsque deux caméras ont le même champ de vision, les résultats sont légèrement dégradés, comparés à la situation où la personne marche devant une seule caméra. Nous avons constaté que l’habillement n’avait, apparemment, pas d’influence sur la précision des résultats obtenus. A la section 4.2.2, nous avons décrit que les oscillations de la trajectoire du centre de masse sont dues au mouvement du centre de masse de la personne, amplifié par un artefact lié aux occlusions de profil du corps. La situation où la personne porte une jupe renforce l’idée de l’existence d’un artefact. En effet, les oscillations de la trajectoire du centre de masse, de la personne portant une jupe, sont plus grandes que celles où la personne porte un pantalon, comme montré à la figure 7.7. Le nombre de points détectés en bas du corps de la personne est encore plus grand quand elle marche vêtue d’une jupe, en position de double appui comme le montre la figure 7.6. Le 97Chapitre 7. Expérimentations pour l’analyse de la marche phénomène de l’artefact explique également pourquoi beaucoup d’erreurs sont commises quand la personne marche face à la caméra. Quand la caméra est face à la personne, l’artefact n’est plus présent, rendant la trajectoire du centre de masse plus lisse. L’atténuation de l’amplitude des oscillations est également due à la position de la caméra qui se trouve en hauteur, avec un angle de -27˚comme nous l’avons déjà décrit à la section 4.2.2. La trajectoire étant plus lisse, des erreurs d’extraction des maxima locaux et, par conséquent, d’extraction des paramètres de la marche sont commises. Les résultats, de cette deuxième évaluation, nous montrent également que si l’on souhaite installer un système au domicile, analysant les paramètres de la marche, nous devons analyser les moyennes obtenues pour chaque paramètre, par exemple à la fin de la journée. Nous avons montré que les moyennes pour chaque paramètre sont justes et fidèles aux valeurs réelles et cela pour toutes les situations même celles où la personne marche face caméra. Figure 7.6 – En phase de double appui, de nombreux points mobiles sont détectés dans la partie basse de la silhouette quand le sujet porte une jupe. 500 550 600 650 700 750 800 850 900 950 1000 33.5 34 34.5 35 35.5 36 36.5 37 37.5 Y (mm) Temps (s) Walking (a) Trajectoire du centre de masse d’un sujet marchant avec une jupe. 600 650 700 750 800 850 900 950 1000 1050 1100 34 34.5 35 35.5 36 36.5 37 Y (mm) Temps (s) Walking (b) Trajectoire du centre de masse d’un sujet marchant avec un pantalon. Figure 7.7 – Comparaison des oscillations de la trajectoire du centre de masse. 98Chapitre 8 Expérimentations pour la reconnaissance d’activité Sommaire 8.1 Cas de la personne entièrement visible . . . . . . . . . . . . . . . 99 8.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 99 8.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 8.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.2 Cas de la personne partiellement visible . . . . . . . . . . . . . . 109 8.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 109 8.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Nous présentons deux expérimentations qui ont pour but de tester la capacité des différents modèles de Markov cachés à reconnaître l’activité de la personne. Nous les comparons entre eux pour identifier celui reflétant au mieux la réalité. Cette comparaison est effectuée en prenant une unique base de données pour l’apprentissage contenant des situations où les personnes sont entièrement visibles. Dans la première expérimentation, nous testons les différents modèles de Markov cachés construits pour reconnaître l’activité sur des séquences où la personne est entiè- rement visible. Puis dans la seconde expérimentation, nous évaluons le comportement de chaque modèle construit, face aux situations où la personne n’est pas entièrement visible. Cette évaluation est nécessaire, car, même en plaçant les caméras de façon à maximiser la couverture de la pièce, il est fort probable que la personne ne soit pas entièrement visible dans certaines zones. 8.1 Cas de la personne entièrement visible 8.1.1 Description de l’expérimentation Protocole expérimental 28 sujets, âgés de 20 à 53 ans, ont participé à l’expérience, dont 8 femmes et 20 hommes. Cette expérience s’est déroulée dans l’appartement laboratoire du centre de Nancy. Les sujets ont réalisés 8 situations filmés par une caméra RGB-D posée dans un angle de l’appartement. Le plan de l’appartement, avec la position de la caméra, est montré à la figure 8.1. La table représentée sur la figure, en face de la caméra, a été retirée pour permettre la réalisation des différentes situations. Chaque situation correspondait à une activité. Il s’agit des activités de la 99Chapitre 8. Expérimentations pour la reconnaissance d’activité vie quotidienne que nous avons définies précédemment, lors de la construction des modèles de Markov cachés au chapitre 6. Pour rappel, ces activités sont : s’accroupir, se pencher, s’asseoir, marcher, chuter, être allongé au sol, monter sur un obstacle et s’allonger sur un canapé. Plus précisément, la consigne donnée aux sujets était : — pour la situation « Se pencher » : ramasser un stylo en pliant le moins possible les genoux ; — pour la situation « S’accroupir » : ramasser un stylo en pliant les genoux, pour ainsi être plus proche du sol à la différence de la situation « Se pencher » ; — pour la situation « S’asseoir » : s’asseoir sur une chaise ; — pour la situation « Marcher » : marcher une fois en ligne droite et une fois en réalisant un demi-tour dans le champ de vision de la caméra. Ces deux séquences ont été regroupées dans l’unique situation « Marcher » ; — pour les situations « Chuter » et « Allongé au sol » : chuter sur un matelas et rester allongé, enregistrés en une seule séquence qui a ensuite été découpée manuellement ; — pour la situation « Monter sur un obstacle » : réaliser deux séquences, une en montant sur une chaise et une autre en montant sur un marche pied. La réalisation de deux séquences a permis d’apprendre la situation « Monté sur un obstacle » pour plusieurs tailles d’obstacle ; — pour la situation « S’allonger sur un canapé » : s’allonger sur trois chaises mises côte à côte. Les éléments tels que la chaise, le marche pied, le matelas, le stylo, étaient placés au milieu du champ de vision de la caméra. Avant d’atteindre ces éléments et de pouvoir réaliser la situation demandée, les personnes devaient d’abord marcher. Ensuite, après avoir réalisé ce qui était demandé, les sujets devaient remarcher, pour sortir du champ de vision de la caméra. Chaque situation est illustrée à la figure 8.2, montrant ainsi les étapes réalisées. Figure 8.1 – Plan de l’appartement expérimental avec le positionnement de la caméra. Par la suite, nous avons demandé à des sujets d’effectuer une situation où il devait marcher, se tenir debout à un endroit de la pièce, puis se déplacer pour rester à nouveau debout en répétant cela environ 5 fois. Ainsi, nous obtenons l’activité « Debout » à différentes distances de la caméra. Base d’apprentissage et base de test Les situations effectuées par les 28 sujets permettent de construire une base de données contenant 229 séquences. Chaque séquence a été segmentée et étiquetée manuellement. La base de données est utilisée pour apprendre les paramètres des modèles de Markov cachés et également pour tester la capacité des modèles à détecter correctement les activités réalisées. 1008.1. Cas de la personne entièrement visible Se pencher S’accroupir S’asseoir Marcher Faire un demi-tour Chute+Allongé au sol Monter S’allonger sur un canapé Figure 8.2 – Suivi des situations, effectuées par un sujet, à différents pas de temps. 101Chapitre 8. Expérimentations pour la reconnaissance d’activité 185 séquences (soit 22 sujets) sont conservées pour l’apprentissage. Pour les modèles des sections 6.3.1 et 6.3.2, avec fonction d’observation seule et n’utilisant qu’un MMC, la moyenne de chaque paramètre (position verticale du centre de masse, sa vitesse verticale et la dispersion verticale du corps de la personne et pour certains modèles, la vitesse horizontale et le point maximum) et la covariance sont apprises à partir de cette base d’apprentissage. Elles sont également apprises pour chaque état du MMC, pour ainsi construire la fonction d’observation. Pour les modèles utilisant plusieurs MMC de la section 6.3.3, la matrice de transition, les probabilités initiales et la fonction d’observation (utilisant les moyennes et les covariances des trois ou cinq paramètres selon le modèle) sont apprises, pour chaque MMC, à partir de cette même base de données et ce grâce à l’algorithme de Baum-Welch. Les 44 séquences restantes (correspondant à 6 sujets) sont utilisées pour tester le modèle. Nous fournissons à l’algorithme ces 44 séquences et nous observons si celui-ci détecte correctement l’activité réalisée. Les résultats sont montrés à la section suivante. 8.1.2 Résultats Comme indiqué précédemment, 44 séquences sont données à chacun des modèles construits. Les algorithmes Forward-Backward et de Viterbi fournissent les classifications dans le cas des modèles à un seul MMC. La vraisemblance du modèle permet de classer les situations dans le cas de l’utilisation de plusieurs MMC. Représentation des bonnes classifications et des fausses détections Deux façons de représenter les résultats sont proposées pour évaluer les modèles, tout d’abord en observant les bonnes classifications puis en calculant le nombre de fausses détections. Bonnes classifications Tout d’abord, le tableau 8.1 indique le nombre de bonnes classifications pour chaque activité selon le modèle utilisé. Les différents modèles sont exprimés dans ce tableau par des abréviations dont la signification est la suivante : — « Modèle observations seules » correspond au modèle à 8 états avec la fonction d’observation seule de la section 6.3.1 ; — « 1MMC 3 observations » représente le MMC à 8 états avec matrice de transition, définie manuellement, et 3 observations décrit à la section 6.3.2 ; — « 1MMC 5 observations » représente le MMC à 9 états avec matrice de transition, définie manuellement, et 5 observations décrit à la section 6.3.2 ; — « 8MMC 2 états » et « 8MMC 3 états » correspondent au système de 8 MMC à 2 ou 3 états et 3 observations décrit à la section 6.3.3 ; — « 9MMC 2 états » et « 9MMC 3 états » correspondent au système de 9 MMC à 2 ou 3 états et 5 observations décrit à la section 6.3.3. Les colonnes représentent les différentes activités (« Acc » : Accroupi, « All » : Allongé sur un Canapé, « Ass » : Assis, « Chu » : Chute, « Sol » : Allongé au sol, « Mar » : Marche, « Mon » : Monté sur un obstacle, « Pen » : Penché, « Dem » : Demi-tour). Nous séparons l’activité « Marche » et « Demi-tour » dans le tableau mais toutes les deux doivent être reconnues comme « Marche » par l’algorithme pour être correctes. Dans chaque case du tableau, le premier chiffre (dans certain cas l’unique chiffre) correspond au nombre de bonnes classifications. Nous considérons comme « bonne classification » toutes les activités qui ont été réalisées dans une séquence et qui ont été détectées par l’algorithme avant la fin de l’activité. Par exemple, si une personne s’assoit et que l’algorithme détecte l’activité 1028.1. Cas de la personne entièrement visible « Assis » lorsque la personne se relève, nous considérons que l’algorithme n’a pas détecté la bonne activité, car il l’a détectée trop tard. Dans certains cas, un deuxième chiffre est présent dans la case, correspondant au nombre de fois, inclus dans le premier chiffre, où l’algorithme donne la bonne activité en insérant, toutefois, une autre activité non réalisée dans la séquence. Ainsi, nous comptons comme juste cette séquence dans le premier chiffre mais nous indiquons son erreur par le deuxième chiffre. Nous considérons qu’il s’agit d’une classification correcte, car bien souvent l’insertion d’activité, non réalisée dans la séquence, se produit dans les phases de transition entre deux activités réalisées par la personne. Par exemple, lorsque la personne s’assoit, ce qui nous intéresse est que l’algorithme détecte correctement « Assis » quand la personne est effectivement assise et non pas quand elle passe de debout à assise. Pour expliquer la deuxième case du tableau, la situation « S’allonger sur un canapé », analysée par le modèle avec la fonction d’observation seule, contient « 5 | 2 » signifiant que 5 séquences ont été correctement identifiées et que, parmi ces 5 séquences, une autre activité a été indiquée 2 fois avant que la bonne activité soit finalement détectée. La ligne « Total » du tableau indique le nombre total d’occurrences qui aurait dû être trouvé pour chaque activité. Par exemple, pour la deuxième case du modèle sans transition, l’algorithme a reconnu que la personne était dans la situation « Allongé Canapé » dans 5 séquences sur 6. Acc All Ass Chu Sol Mar Mon Pen Dem Modèle observations seules 6 | 6 5 | 2 5 | 5 6 | 5 6 5 6 2 4 | 1 1MMC 3 observations 6 5 5 6 6 5 6 2 5 1MMC 5 observations 6 5 6 6 6 5 6 2 5 8MMC 2 états 6 | 3 4 6 | 1 6 4 5 | 1 4 | 1 4 5 | 1 8MMC 3 états 6 5 5 6 6 5 5 2 5 9MMC 2 états 1 5 6 6 1 5 4 4 4 9MMC 3 états 6 3 6 6 0 5 1 0 4 Total 6 6 6 6 6 5 6 4 5 Table 8.1 – Classification des activités par l’algorithme selon le modèle utilisé. Le tableau 8.1 présente le nombre de fois où une séquence a été correctement détectée. Fausses détections La deuxième représentation est de créer un tableau indiquant, quant à lui, les fausses détections. Les résultats sont présentés, pour chaque modèle, dans le tableau 8.2. Par exemple, pour le modèle sans transition, l’algorithme commet 2 fausses détections en détectant « Assis », 9 pour « Chuter » et 3 pour « Pencher ». Nous considérons une fausse détection lorsque l’activité réalisée n’est à aucun moment détectée dans la séquence ou l’est trop tard. Les activités « Chute » et « Allongé au sol » sont considérées comme des cas particuliers. A chaque fois que l’algorithme indique l’état « Chute » ou « Allongé Sol » alors que ces activités n’ont pas été réalisées, nous considérons qu’il commet une fausse détection, même si l’algorithme donne finalement la bonne activité. L’idée est de considérer la détection d’une chute (ou être allongé au sol) comme une information très importante et commettre une fausse détection de ces activités est plus grave que de produire une fausse détection des autres activités. Comparaison entre les algorithmes Forward-Backward et de Viterbi Les algorithmes Forward-Backward et de Viterbi s’utilisent dans le cas du modèle sans transition, du MMC à 8 et 9 états avec matrice de transition. Dans les tableaux 8.1 et 8.2, les résultats 103Chapitre 8. Expérimentations pour la reconnaissance d’activité Acc All Ass Chu Sol Mar Mon Pen Modèle observations seules 0 0 2 9 0 0 0 3 1MMC 3 observations 1 0 2 0 0 0 0 1 1MMC 5 observations 1 0 1 1 0 0 0 0 8MMC 2 états 4 0 0 3 0 0 0 3 8MMC 3 états 2 0 2 0 0 0 0 1 9MMC 2 états 0 0 1 3 0 2 0 6 9MMC 3 états 13 0 0 3 0 0 0 0 Table 8.2 – Fausses détections effectuées par l’algorithme selon le modèle utilisé. des trois premières lignes concernent l’algorithme Forward-Backward. La distinction entre les deux algorithmes n’est pas présentée, car peu de différences existent au niveau des résultats. La seule différence (mais elle n’est de toute façon pas prise en compte dans les tableaux) se situe au niveau des « états de transition » comme montré à la figure 8.3. Celle-ci présente les résultats de l’analyse effectuée pour les deux algorithmes, avec le MMC à 8 états et 3 observations, à partir d’une même séquence. Dans cette séquence, le sujet devait s’asseoir et se lever sur une chaise sans marcher entre les deux situations. Forward-Backward infère correctement les bonnes activités comme le montre la figure 8.3(a). L’algorithme de Viterbi de la figure 8.3(b) fournit plus d’états. Pour passer de « Assis » à « Monté sur un obstacle », le sujet ne marche pas, or l’algorithme de Viterbi infère l’état « Marche ». Cette décision de l’algorithme de Viterbi n’est pas correcte, mais il a l’avantage de coller aux contraintes fournies par le MMC. Dans l’approche à un unique MMC, où la matrice de transition est définie manuellement, l’état « Marche » est défini comme précédent et suivant l’état « Assis ». Donc la figure 8.3(b) montre que l’algorithme de Viterbi passe par l’état « Marche » avant et après l’état « Monté sur un obstacle » respectant ainsi le modèle défini, même si le sujet ne marche pas.                          (a) Analyse par l’algorithme Forward-Backward.                            (b) Analyse par l’algorithme de Viterbi. Figure 8.3 – Différence dans l’analyse faite par les algorithmes Forward-Backward et de Viterbi, pour une séquence où la personne s’assoit puis monte sur une chaise. Pour la suite, les résultats seront donnés uniquement pour l’algorithme Forward-Backward, car nous préférons conserver l’algorithme qui colle aux situations réalisées plutôt que de conserver l’algorithme qui colle au modèle défini manuellement. 1048.1. Cas de la personne entièrement visible Modèle avec fonction d’observation seule D’après le tableau 8.1, le modèle sans matrice de transition, détecte toutes les activités correspondant à « Accroupi », « Chute », « Allongé au sol », « Marche » et « Monté sur un obstacle ». Pour l’activité « Allongé Canapé », « Assis » et « Demi-tour » l’algorithme manque une détection. Malgré une bonne détection des chutes, la performance de ce modèle est atténuée par le nombre important de fausses détections concernant les chutes comme montré à la Table 8.2. Pour chaque état nécessitant une descente du corps de la personne (par exemple « Assis », « Accroupi »), l’algorithme détecte une chute puis rectifie en donnant le bon état. Les bonnes classifications sont rarement données directement comme on peut le voir par la présence du deuxième chiffre, dans les cases de la première ligne du Tableau 8.1, indiquant que la décision est bruitée. C’est-à-dire que l’algorithme, avant de donner le bon état, donne d’autres états non atteints dans la réalité. Cela peut être constaté par la figure 8.4(b) représentant la trajectoire du centre de masse sur l’axe vertical et le déroulement des décisions de l’activité dans le temps, par le modèle avec fonction d’observation seule. La figure représente le centre de masse d’une personne s’asseyant et montre que l’algorithme hésite à plusieurs reprises avant de donner la bonne activité réalisée « Assis ». -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 850 900 950 1000 1050 1100 1150 Y (mm) Temps (s) Walking Sitting Walking Sitting (a) Séquence analysée par le MMC à trois observations. -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 850 900 950 1000 1050 1100 1150 Y (mm) Temps (s) Sitting Walking Going up Walking Going up Walking Going up Sitting Bending Falling Bending Squatting Sitting Squatting Sitting Squatting Walking Falling Sitting (b) Séqunce analysée par le modèle sans transition. Figure 8.4 – Comparaison d’une séquence où la personne s’assoit analysée par deux modèles. MMC à 8 états et 3 observations Les résultats pour le MMC avec une matrice de transition montrent que les activités « Accroupi », « Chute », « Allongé au sol », « Marche » (pour les séquences où la personne marche et où elle fait un demi-tour) et « Monté sur un obstacle » sont toutes reconnues par le modèle. L’activité « Penché » est l’activité la moins bien reconnue, seulement deux fois sur quatre. Cette activité est remplacée par l’état « Assis ». Cette information est renseignée par le tableau des fausses détections 8.2. Le modèle commet une erreur pour l’activité où la personne s’allonge sur un canapé en désignant cette activité comme étant l’état « Accroupi ». Cette erreur vient du fait que la personne ne s’allonge pas complètement sur le canapé mais s’appuie sur son coude comme le montre la figure 8.5 provoquant une situation différente de ce qui a été appris par le modèle. Le modèle ne reconnaît pas non plus une situation où la personne est assise. En réalité, l’algorithme indique correctement l’état « Assis » lors de la descente et la remontée de la personne mais lorsque celle-ci est assise, le modèle reconnaît cette situation comme étant l’état « Penché », comme illustré à la figure 8.6. Sur cette figure, nous pouvons comprendre l’erreur 105Chapitre 8. Expérimentations pour la reconnaissance d’activité qui a été commise du fait que la personne en s’asseyant a remonté sa jambe sur son autre jambe. Ainsi, la trajectoire du centre de masse est remontée correspondant, pour le modèle, à l’état « Penché ». Figure 8.5 – Sujet s’allongeant différemment de ce qui a été appris dans la base de donnée. 700 750 800 850 900 950 1000 1050 1100 29 30 31 32 33 34 35 36 37 38 39 Y (mm) Temps (s) Walking Sitting Bending Sitting Walking Figure 8.6 – Sujet s’asseyant différemment de ce qui a été appris dans la base de donnée. Ce modèle détecte les bonnes activités de façon similaire au modèle sans matrice de transition. De plus, il présente l’avantage de faire moins de fausses détections comme le montre le tableau 8.2 et aucune fausse détection concernant les chutes. Ce modèle diffère également du précédent par le fait qu’il donne la bonne activité sans hésiter avec d’autres états (ceci est démontré par l’absence du deuxième chiffre dans les cases du tableau 8.1). Cette différence entre les deux modèles peut être observée à la figure 8.4. Les deux figures représentent la trajectoire du centre de masse sur l’axe vertical pour une personne marchant puis s’asseyant et enfin marchant pour sortir du champ de vision de la caméra. Ces figures indiquent les détections, par l’algorithme, des états dans lesquels est passée la personne. La figure 8.4(b) montre que le modèle sans transition est plus bruité que le modèle avec matrice de transition représenté à la figure 8.4(a). Selon nos critères, la classification pour le modèle sans transition est correcte, puisqu’au final l’algorithme 1068.1. Cas de la personne entièrement visible indique l’état « Assis », mais la décision apparaît plus lentement comparé au modèle avec des transitions, qui lui n’hésite pas sur l’activité réalisée. MMC à 9 états et 5 observations Les résultats pour le MMC à 9 états montrent que la classification des activités est semblable au modèle précédent. Dans ce modèle, les situations « Assis » sont toutes reconnues. De plus, toutes les activités sont reconnues directement, sans hésitation avec une autre activité comme le montre l’absence du deuxième chiffre dans les cases du tableau 8.1. Le modèle à 9 états fait moins d’erreur au niveau des fausses détections que le précédent modèle à 8 états. Par contre, l’inconvénient est qu’il commet une fausse détection importante en donnant l’activité « Chute » à la place de l’état « Penché ». Système de 8 MMC à 2 états et 3 observations La reconnaissance d’activité est similaire aux autres modèles avec néanmoins les activités « Monté » et « Allongé Canapé » qui sont moins bien reconnues. Toutes les activités, où la personne se penche, sont ici reconnues. Les séquences où la personne « Chute » sont toutes reconnues, par contre l’activité « Allongé au sol » suivant la chute n’est pas toujours reconnue. La matrice de transition forçant le passage de « Chute » à « Allongé au sol » n’est plus présente dans ce modèle, cela permet de détecter l’état « Chute » sans forcément être suivi de l’état « Allongé au sol ». Remarquons que, dans certain cas les sujets se levaient directement après leur chute ne passant pas forcément par la situation « Allongé au sol ». Il y a un peu d’hésitation sur l’activité réalisée, la bonne classification ne se faisant pas toujours directement (comme on peut le voir avec la présence du deuxième chiffre du Tableau 8.1). Peu de fausses détections sont présentes ici, mais l’inconvénient est qu’il y a trois détections de « Chute » non pertinentes. Système de 8 MMC à 3 états et 3 observations Le nouveau modèle classifie correctement les activités. L’état « Penché » reste celui qui est le moins bien distingué. Les décisions de l’algorithme, concernant l’état dans lequel se trouve la personne, sont directes comme on peut le voir par l’absence d’un deuxième chiffre dans la ligne « 8MMC 3 états » du Tableau 8.1. La différence avec le précédent modèle se trouve également au niveau des fausses détections. L’algorithme ne commet aucune fausse détection concernant les chutes. De plus, peu d’erreurs sont commises en règle générale par ce modèle. Système de 9 MMC à 2 états et 5 observations Le tableau 8.1 montre que ce modèle classifie correctement les activités sauf pour deux états, « Accroupi » et « Allongé Sol ». Les situations « Allongé Sol » ne sont pas reconnues mais cela ne gêne pas la détection de l’état « Chute ». Ce modèle commet peu de fausses détections. Les erreurs proviennent surtout de l’état « Accroupi » qui n’est pas détecté. L’algorithme remplace toutes les situations où la personne s’accroupit par l’état « Chute » suivi de l’état « Penché ». 107Chapitre 8. Expérimentations pour la reconnaissance d’activité Système de 9 MMC à 3 états et 5 observations Ce modèle commet de nombreuses erreurs de classification notamment pour les états « Allongé Canapé », « Monté », « Allongé Sol » et « Penché ». Les états « Allongé Sol » et « Penché » ne sont d’ailleurs jamais reconnus. L’état « Penché » est confondu avec l’état « Accroupi ». L’état « Allongé Sol » n’est jamais reconnu mais cela n’empêche pas la chute d’être quant à elle détectée. Le modèle infère l’état « Accroupi » très souvent puisque 13 fausses détections ont été ré- pertoriées pour cet état. Le modèle commet également trois fausses détections concernant l’état « Chute ». Résultats pour l’activité debout Nous avons demandé à une personne de se tenir debout dans le but de savoir ce qu’infèrent les différents modèles. Le modèle à 9 états 5 observations et les systèmes de 9 MMC ont appris à différencier l’activité « Debout », donc il devrait la reconnaître. En revanche, les modèles à 8 états et les systèmes de 8 MMC n’ont pas eu, dans leur base d’apprentissage, une telle activité. Nous voulons ainsi connaître l’activité inférée, en pensant qu’ils vont la classifier comme étant l’activité « Marche ». Les résultats sont montrés à la table 8.3. Debout Modèle observations seules Marche 1MMC 3 observations Marche 1MMC 5 observations Debout 8MMC 2 états Marche 8MMC 3 états Marche 9MMC 2 états Assis 9MMC 3 états Accroupi Table 8.3 – Classification de l’activité « Debout » selon le modèle utilisé. Les résultats montrent que seul le modèle à 9 états et 5 observations détecte l’état « Debout ». La plupart des autres modèles infèrent l’état « Marche ». 8.1.3 Conclusion L’expérimentation nous a permis de comparer les différents modèles construits sur une même base de test. Les résultats nous permettent de savoir quels sont les modèles les plus justes. La classification réalisée par le modèle sans matrice de transition, après de nombreuses hésitations entre différents états, donne finalement de bons résultats. Mais ce modèle ne peut pas être conservé, car il fournit beaucoup de fausses détections concernant les chutes. Le modèle avec transitions à 8 états et 3 observations produit peu de fausses détections et surtout aucune concernant les chutes. La probabilité de transition d’aller dans l’état « Chute » a été définie manuellement comme très faible. Ainsi, l’observation doit être vraiment « forte » pour passer dans l’état « Chute » avec ce modèle. Le modèle réalise peu d’erreurs de classification. L’état le moins bien détecté est « Penché » en omettant 2 situations sur 4. Toutes les chutes sont détectées. Le modèle à 9 états et deux observations en plus des modèles précédents n’apporte pas de meilleurs résultats de classification. Au contraire, il commet une fausse détection concernant l’état « Chute », ce que ne faisait pas le modèle précédent. L’idée en combinant plusieurs modèles de Markov cachés est de 1088.2. Cas de la personne partiellement visible tester des modèles sans connaissance a priori. Le système de 8 MMC, appris par Baum-Welch, à 3 états et 3 observations s’avère le modèle s’approchant au mieux de la réalité. Ce modèle donne de bons résultats au niveau de la classification et c’est le seul parmi les systèmes de MMC à ne faire aucune fausse détection concernant les chutes. Pour développer un algorithme capable de détecter les activités de la personne au cours de la journée et de détecter ses chutes, nous avons besoin d’un modèle classifiant les bonnes activités et surtout un modèle effectuant peu de fausses détections. L’algorithme à un modèle de Markov caché à 8 états et celui utilisant le système de 8 MMC à trois états détectent toutes les chutes sans produire de fausse détection et classifient correctement les autres activités, ce qui correspond à nos attentes. Ces deux modèles sont équivalents au niveau des résultats, mais on préfère un modèle ayant appris par lui-même les différentes probabilités. En effet, le système de 8 MMC, n’étant pas contraint au niveau de la dynamique des situations, est plus général et correspond alors mieux aux situations non prévues qu’un modèle où nous avons inséré de la connaissance. Ces résultats nous montrent que les modèles à trois observations sont tout autant, voire plus justes que les modèles à cinq observations. Bien que nous ayons ajouté un état et qu’il est donc possible de distinguer l’état « Debout » avec 5 observations, la qualité de classification s’avère dégradée pour certains modèles. Donc, en ajoutant des états et des observations, nous ajoutons de la complexité et perdons au niveau précision des résultats. 8.2 Cas de la personne partiellement visible 8.2.1 Description de l’expérimentation Nous avons demandé à une personne d’effectuer des activités en étant cachée par des objets. Ces activités correspondent à celles utilisées pour construire les MMC. Les consignes pour réaliser ces neuf situations sont les suivantes : — la personne se penche derrière une table ; — la personne s’accroupit derrière une table ; — la personne s’assoit sur une chaise placée derrière une table ; — la personne marche derrière trois chaises posées l’une à côté de l’autre ; — la personne marche et réalise plusieurs demi-tours derrière les trois chaises ; — la personne chute et s’allonge au sol derrière une table ; — la personne s’allonge sur un canapé en posant un drap sur elle ; — la personne monte sur une chaise placée derrière une table ; — la personne reste debout derrière une table. Chaque situation est illustrée à la figure 8.7, montrant ainsi les étapes réalisées par le sujet à chaque séquence. La table correspond à une table à manger d’environ 80 cm de hauteur. Lorsque la personne chute, elle n’est donc plus visible. Dans le cas des autres situations, une partie du corps de la personne reste toujours visible. 8.2.2 Résultats Chaque situation, que devait réaliser le sujet, est analysée par les différents modèles construits. Nous avons regroupé dans la table 8.4 les activités inférées par chaque modèle à chaque situation. Les colonnes représentent les différentes activités réalisées par la personne (« Acc » : Accroupi, « Ass » : Assis, « Chu » : Chute, « Mar » : Marche, « Mo » : Monté sur un obstacle, « Pen » : Penché, « Dem » : Demi-tour, « All » : Allongé sur un canapé, « De » : Debout). Chaque case 109Chapitre 8. Expérimentations pour la reconnaissance d’activité Se pencher S’accroupir S’asseoir Marcher 1108.2. Cas de la personne partiellement visible Faire des demi-tours Chute+Allongé au sol S’allonger sur un canapé Monter Debout Figure 8.7 – Suivi des situations où le sujet n’est pas entièrement visible à différents pas de temps. 111Chapitre 8. Expérimentations pour la reconnaissance d’activité indique l’activité que le modèle a inféré. Les activités inscrites en vert correspondent aux bonnes classifications. Le précédent tableau 8.1 indiquait les bonnes classifications dans le cadre de situations semblables à celles contenues dans la base de données. Dans cette nouvelle table 8.4, les erreurs de classifications sont plus fréquentes, car il s’agit de situations nouvelles, non apprises, où la personne est à moitié visible par la caméra. Le tableau nous informe que l’activité « Monté » est l’activité la mieux détectée par presque tous les modèles. La situation « S’allonger sur un canapé », sous un drap, est particulière, car sa réalisation entraîne la modification du fond appris. Lorsque la personne s’allonge, elle prend le drap pour le mettre sur elle. Ce qui a pour conséquence de cacher son corps et de sortir le drap du fond appris. Comme nous pouvons le voir sur les images de la figure 8.7, le drap est détecté comme mobile. La plupart des modèles reconnaissent l’activité « Assis », qui précède et suit l’activité « Allongé Canapé ». Cependant l’activité « Allongé Canapé » en elle-même, lorsqu’elle est réalisée sous un drap, n’est pas reconnue. Le modèle commettant le moins d’erreurs de classification est le modèle à 9 états et 5 observations. De plus, dans la situation où la personne a réalisé plusieurs demi-tours derrière des chaises, ce modèle est le seul à indiquer les demi-tours comme le montre la figure 8.8. L’activité « Demi-tour » n’est pas contenue dans la base de donnée, mais le modèle à 9 états et 5 observations infère l’état « Debout » lorsque la personne tourne sur elle-même pour réaliser le demi-tour, puis infère l’état « Marche » entre chaque deux demi-tours. 800 850 900 950 1000 1050 1100 1150 1200 1250 1300 38 40 42 44 46 48 50 52 54 56 Y Temps (s) Walking Upright Walking Upright Walking Upright Walking Upright Walking Upright Walking Upright Walking (mm) Figure 8.8 – Résultat de l’analyse avec le modèle à 9 états et 5 observations, pour une personne réalisant des demi-tours. Pour l’ensemble des modèles, nous pouvons remarquer qu’il y a confusion entre les états « Accroupi », « Penché » et « Chute ». Ce problème peut être résolu en ajoutant la notion de temps. Par exemple, pour l’état « Accroupi » et « Penché » la personne reste très peu de temps dans ces activités alors que l’activité « Chute » correspond à une situation où la personne n’est plus visible durant une certaine période. 1128.2. Cas de la personne partiellement visible Acc Ass Chu Mar Mo Pen Modèle observations seules Acc Pen Acc Mon + Ma Mo Pe 1MMC 3 observations Chu + Acc Acc Chu Ma Mo Acc 1MMC 5 observations Chu + Acc Ass Chu Ma Mo Acc 8MMC 2 états Acc Acc Acc Acc Mo Acc 8MMC 3 états Acc Acc Acc Acc Mo Acc 9MMC 2 états Acc Ass Ass Ma Mo Acc 9MMC 3 états Acc Acc Acc Acc Acc Acc Dem All De Modèle observations seules Mo +Acc + Ma Acc Ma 1MMC 3 observations Ma Acc Acc + Ma 1MMC 5 observations De +Ma Acc De 8MMC 2 états Acc Acc Acc 8MMC 3 états Acc Acc Acc 9MMC 2 états Ma Acc Ass + Ma 9MMC 3 états Acc Acc Acc Table 8.4 – Détection d’activité quand la personne n’est pas entièrement visible pour différents modèles. 8.2.3 Conclusion Avec la première expérimentation pour la reconnaissance d’activité d’une personne entièrement visible, nous avions conclu que le modèle à 8 états 3 observations et le système de 8 MMC étaient ceux commettant le moins d’erreurs de classification et peu de fausses détections. Le modèle à 9 états et 5 observations avait l’avantage de distinguer l’activité « Debout » de « Marche ». Mais ce modèle ajoutait de la complexité, en ajoutant deux observations de plus que ceux à 8 états, sans pour autant donner de meilleurs résultats. Avec la deuxième expérimentation pour la reconnaissance d’activité d’une personne partiellement visible, nous avons montré que le modèle à 9 états et 5 observations est celui donnant les meilleurs résultats pour traiter les situations d’occlusion de la personne non apprises dans la base de données. Pour le domicile, nous pensons que ce modèle fournira les meilleures classifications. 113Chapitre 8. Expérimentations pour la reconnaissance d’activité 114Chapitre 9 Tests en situations réelles Sommaire 9.1 Test de l’algorithme d’analyse de la marche . . . . . . . . . . . . 115 9.2 Test de l’algorithme de détection d’activité . . . . . . . . . . . . 116 9.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Une limite des expérimentations, décrites dans les deux chapitres précédents, est qu’elles ont été réalisées en laboratoire avec des sujets ne représentant pas la catégorie à laquelle cette thèse s’adresse. Ces expérimentations doivent être effectuées avec des sujets appropriés pour savoir si les résultats restent les mêmes. Dans ce chapitre, nous présentons des résultats de quelques tests effectués sur des personnes âgées. 9.1 Test de l’algorithme d’analyse de la marche 6 personnes âgées ont réalisé quelques séquences filmées par notre dispositif. Ces enregistrements ont été réalisés dans des milieux réels en dehors de l’appartement expérimental. Tout d’abord, nous avons demandé à deux personnes, à l’hôpital, de marcher devant notre système. Ces deux patientes, ayant des problèmes liés à la marche et à l’équilibre, sont venues pour réaliser un bilan médical avec un médecin. Les consultations durent une heure, pendant laquelle de nombreux tests cliniques sont effectués pour constituer un bilan de la fragilité de la personne. Un des tests cliniques réalisé était de marcher sur 10 mètres. Durant ce test, nous avons filmé ces deux personnes. La figure 9.1 montre la marche de l’une des deux personnes et la trajectoire de son centre de masse, sur l’axe vertical, avec les longueurs de pas détectées. Pour cette expérience, nous n’avons pas de système de référence. Nous ne savons donc pas si notre système fournit des paramètres de la marche justes par rapport à la réalité. Nous pouvons, uniquement, effectuer une analyse qualitative en observant que le système détecte, comme dans nos précédentes expérimentations effectuées sur les sujets jeunes, des oscillations et est capable d’extraire les paramètres de la marche. De plus, nous pouvons remarquer que les longueurs de pas détectées (68 cm, 53 cm et 55 cm) sont des mesures plausibles et que leur nombre est juste. Nous avons également filmé quatre personnes de plus de 80 ans, chez elles. Trois personnes sur quatre ont déjà chuté. Nous avons demandé aux personnes de marcher perpendiculairement à la caméra que nous avons posée dans le salon, sur des meubles hauts. Dans les quatre cas, les oscillations du centre de masse sont présentes comme nous pouvons le voir sur la figure 9.2. Cette figure présente les trajectoires du centre de masse, sur l’axe vertical, des quatre personnes. Les maxima des oscillations étant perceptibles, l’algorithme peut en déduire les paramètres de 115Chapitre 9. Tests en situations réelles Figure 9.1 – Utilisation de notre système avec une patiente, lors de sa consultation à l’hôpital. la marche. Nous n’avons, toutefois, pas de méthode de référence pour savoir si la localisation des oscillations permet de fournir les paramètres de la marche proche de la réalité. L’analyse qualitative nous permet de constater que la trajectoire du centre de masse la plus régulière, parmi les figures 9.2, appartient à la personne âgée n’ayant jamais chuté 9.2(a). Parmi les quatre personnes, une des personnes a d’importants problèmes d’équilibre. La personne a déjà chuté plusieurs fois. La trajectoire de son centre de masse, sur l’axe vertical, est représentée à la figure 9.2(d). Les oscillations sont moins régulières que ce que nous pouvons voir avec des personnes jeunes, mais la trajectoire reste sinusoïdale. Il est donc possible d’obtenir les paramètres de la marche. Une autre personne, de 84 ans ayant récemment chuté, a marché devant notre système. La trajectoire de son centre de masse, représentée à la figure 9.2(c), oscille peu. L’espacement des maxima indique une cadence plus lente que pour la personne représentée à la figure 9.2(a). Quand la personne a marché, nous avons pu voir qu’elle restait très droite. Pour finir, un des sujets a une jambe artificielle et a donc marché avec 2 cannes. Quand il marche, la jambe artificielle est peu soulevée du sol. La représentation de la trajectoire de son centre de masse est montré à la figure 9.2(b). Nous pouvons voir que, malgré les différentes façons de marcher, différentes de ce que nous pouvions avoir avec les sujets jeunes, le système fournit le même type de trajectoires, même si elles sont moins régulières avec les personnes âgées qu’avec les plus jeunes. 9.2 Test de l’algorithme de détection d’activité L’algorithme de détection d’activité fournit de bons résultats au niveau de la classification, comme nous l’avons vu au chapitre 8, sur des personnes jeunes. Nous avons testé l’algorithme pour quelques activités réalisées par des personnes âgées. Pour les précédentes situations où la personne marchait devant la caméra à leur domicile ou à l’hôpital, l’algorithme de détection d’activité a correctement classifié les personnes en train de marcher. Comme nous pouvons le voir à la figure 9.3, pour une personne, marchant à son domicile, l’algorithme indique qu’elle marche. Nous avons également testé la capacité de l’algorithme à détecter d’autres activités. Nous avons demandé à un des sujets de s’asseoir, de se pencher et de monter sur un marche pied. La figure 9.4 montre le résultat pour chacune des activités réalisées par le sujet. Chaque figure représente la trajectoire du centre de masse de la personne, sur l’axe vertical, avec l’évaluation par 1169.2. Test de l’algorithme de détection d’activité 550 600 650 700 750 800 850 900 34 34.5 35 35.5 36 36.5 37 37.5 38 Y (mm) Temps (s) (a) Marche d’une personne de 81 ans n’ayant jamais chuté. 500 550 600 650 700 750 800 850 900 950 36 37 38 39 40 41 42 43 44 45 Temps (s) Y (mm) (b) Marche d’une personne de 80 ans ayant une jambe artificielle. 450 500 550 600 650 700 750 800 850 900 55.5 56 56.5 57 57.5 58 58.5 59 59.5 60 Y (mm) Temps (s) (c) Marche d’une personne de 84 ans ayant chuté. 550 600 650 700 750 800 850 900 47 48 49 50 51 52 53 54 Y (mm) Temps (s) (d) Marche d’une personne de 90 ans ayant des problèmes d’équilibre. Figure 9.2 – Représentation du centre de masse, sur l’axe vertical, de quatre personnes âgées. Figure 9.3 – Détection de l’activité « Marche », pour une personne de 81 ans marchant à son domicile. 117Chapitre 9. Tests en situations réelles l’algorithme de l’état dans lequel se trouve la personne. Les situations où la personne s’assoit et où elle se penche sont correctement reconnues. Nous pouvons également constater que les phases où la personne marche avant et après la réalisation de l’activité « Assis » et « Penché » sont reconnues comme « Marche ». L’activité « Monté » n’est pas reconnue. La personne montait sur un marche pied de 13,5 cm. La personne a tout d’abord essayé de monter mais est retombée au sol très rapidement, n’arrivant pas à tenir sur le marche pied. Puis, elle est remontée et est restée immobile quelques secondes. La montée n’était peut être pas assez grande pour que l’algorithme la détecte. Dans la base de donnée, pour la situation « Monté », les personnes montaient sur une chaise et seulement 5 d’entre elles ont réalisé une deuxième séquence avec un marche pied. Nous pensons que les paramètres appris pour une chaise sont différents de ceux qui seraient appris pour un marche pied. C’est pourquoi la situation n’a pas été reconnue. 600 650 700 750 800 850 900 950 32 34 36 38 40 42 44 46 48 Y (mm) Temps (s) Walking Walking Sitting (a) Trajectoire du centre de masse pour une personne s’asseyant. 650 700 750 800 850 900 950 36 38 40 42 44 46 48 Y (mm) Walking Walking Sitting Sitting Sitting Walking Bending Temps (s) (b) Trajectoire du centre de masse pour une personne se penchant. 500 550 600 650 700 750 800 850 900 950 1000 30 35 40 45 50 55 60 65 Y (mm) Temps (s) Walking Sitting Walking (c) Trajectoire du centre de masse pour une personne montant sur un marche pied. Figure 9.4 – Représentation du centre de masse, sur l’axe vertical, pour différentes activités réalisées par une personne âgée de 81 ans. 9.3 Conclusion Les différents tests effectués avec des personnes âgées permettent de nous donner des premiers résultats de ce que nous pourrions obtenir si nous réalisions des expérimentations avec elles. Ainsi, nous pouvons constater que les trajectoires du centre de masse, sur l’axe vertical, sont plus irrégulières que ce que nous obtenions avec des personnes plus jeunes. Les courbes suivent, tout de même, une trajectoire sinusoïdale, ce qui nous permet d’extraire les paramètres de la marche. Toutefois, nous ne pouvons pas en conclure que les paramètres extraits sont précis, 1189.3. Conclusion n’ayant pas de système de référence lors des tests. Concernant la détection d’activité, les tests nous montrent que nous devons modifier la base de données sur laquelle les modèles sont appris, avant de nous lancer dans une expérimentation, notamment pour la situation « Monter sur un obstacle ». 119Chapitre 9. Tests en situations réelles 120Conclusion Différentes expérimentations ont été mises en place pour tester les algorithmes d’analyse des paramètres de la marche et de détection des activités. Les expérimentations concernant la détection d’activité nous ont permis d’identifier les modèles, que nous avons construits, les plus proches de la réalité. Nous avons également constaté que certains d’entre eux pouvaient s’adapter à des situations n’appartenant pas à la base d’apprentissage. Notamment, certains modèles se sont adaptés aux situations d’occlusions, qui sont des situations très souvent rencontrées dans une maison. Les expérimentations testant la précision des paramètres de la marche fournis par l’algorithme nous ont révélé que des erreurs subsistent, plus ou moins grandes selon les situations réalisées. La caméra Kinect étant précise à quelques centimètres près, comme nous l’avions précisé à la section 3.3, nous nous approchons de cette erreur. L’expérimentation réalisée avec les personnes âgées nous donne une idée du type de trajectoires que nous pouvons obtenir. Mais les tests effectués sont insuffisants pour pouvoir conclure que le système est adapté aux personnes âgées. De plus, avant de tester sur les personnes âgées, nous devons compléter la base d’apprentissage. Actuellement, les paramètres des modèles sont appris à partir d’une base de données contenant uniquement des images de sujets jeunes. Le système sera, dans les prochains mois, testé dans des conditions réelles et avec des personnes âgées dans le cadre du projet SATELOR. Ce projet, financé par la région Lorraine, regroupe des industriels, des hospitaliers et des chercheurs. L’objectif est d’industrialiser un système permettant de maintenir la personne à son domicile. La prochaine étape de ce projet est d’installer le système, dans un premier temps, dans une chambre de l’OHS (Office Hygiène Sociale) à Nancy et d’enregistrer l’activité d’un patient pour pouvoir, par la suite, traiter les données avec notre système. Nous pourrons ainsi constater les manques et atouts du système en situation réelle. Le but final étant d’installer le système au domicile des personnes âgées pour apprendre leurs habitudes, évaluer l’évolution de leur état au quotidien et détecter les éventuelles chutes. 121Conclusion 122Quatrième partie Système pour le maintien à domicile 123Introduction La reconnaissance d’activité et l’extraction des paramètres de la marche sont les deux axes de recherche que nous avons développés pour traiter le problème de la sécurisation de la personne à son domicile et de l’évaluation de son degré d’autonomie. Dans les parties précédentes, nous avons présenté la méthode et les résultats obtenus pour chacun des deux problèmes de manière séparée, tout en sachant que les deux contributions s’appuient sur une base commune de caractéristiques extraites des images de profondeur. L’objectif final est de développer un système unique pour le maintien à domicile. Nous présentons, dans le premier chapitre de cette partie, notre vision du système final, en intégrant la détection d’activité et l’analyse de la marche dans un seul système. Par exemple, lorsque l’algorithme détecte que la personne est dans l’état « Marche », l’algorithme analysant les paramètres de la marche est activé. Nous proposons également une méthode pour apprendre les habitudes de la personne et ainsi, détecter toutes anomalies suite à un événement inhabituel. La méthode consiste à cartographier l’environnement des habitudes de la personne. Dans un deuxième chapitre, nous indiquons d’autres problématiques pour lesquelles le système pourrait être adapté. Par exemple, ce système peut servir à discriminer plusieurs personnes dans la scène et ainsi, suivre l’évolution de l’état de fragilité de plusieurs personnes en même temps. Chaque personne pourrait être identifiée à travers un certain nombre de caractéristiques, comme sa taille, la forme de sa trajectoire de son centre de masse, etc. Ce système pourrait également prévenir, en plus des chutes et de la perte de fragilité des personnes, les troubles cognitifs. En effet, certaines études ont montré qu’une vitesse lente pouvait être un indicateur de troubles cognitifs et de démences à venir. 125Introduction 126Chapitre 10 Vers une implantation au domicile Sommaire 10.1 Couplage des fonctionnalités actuelles du système . . . . . . . . 127 10.2 Cartographie des habitudes dans l’environnement . . . . . . . . 129 10.2.1 Limitations du système et contraintes de l’environnement . . . . . . 129 10.2.2 Détection des cas d’occlusions partielles de la personne . . . . . . . 130 10.2.3 Cartographie des habitudes . . . . . . . . . . . . . . . . . . . . . . 133 10.2.4 Détection des anomalies . . . . . . . . . . . . . . . . . . . . . . . . 134 10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Actuellement, le système développé est conçu pour reconnaître différentes activités et extraire des paramètres de la marche. Dans ce chapitre, nous présentons la manière dont nous avons imaginé intégrer les deux fonctionnalités pour former un système unique, répondant à la problématique du maintien à domicile des personnes âgées. Nous présentons, dans un premier temps, comment coupler les fonctionnalités actuelles du système pour sécuriser et évaluer le degré d’autonomie de la personne. Puis, nous proposons une méthode pour apprendre les habitudes des personnes. 10.1 Couplage des fonctionnalités actuelles du système Nous avons précisé, dans l’introduction de cette thèse, que pour sécuriser la personne, nous avons besoin d’utiliser un algorithme de détection de chutes et d’activités à risque. Concernant l’évaluation du degré d’autonomie de la personne, nous avons précisé que les activités réalisées par la personne et les évolutions dans les paramètres de la marche seraient prises en compte. L’idée est de coupler les algorithmes de détection d’activités et d’extraction des paramètres de la marche pour faire un système unique répondant à la problématique du maintien à domicile des personnes âgées. Nous avons imaginé mettre au domicile une ou plusieurs caméras. L’algorithme détectant l’activité de la personne permettrait, en temps réel, de savoir quelle activité la personne réalise. Selon l’activité qui sera reconnue, l’algorithme effectuera telle ou telle tâche, comme montré à la figure 10.1. Les différentes tâches sont dépendantes de l’activité identifiée : — « Marche » : enregistrement du temps passé dans cette situation, que l’on nommera activité « active », et extraction des paramètres de la marche quand la personne est entièrement visible ; 127Chapitre 10. Vers une implantation au domicile — « Debout » : enregistrement du temps passé dans cette situation nommée activité « active » ; — « Chute » et « Allongé Sol » : envoi d’une alerte à la famille ou aux secours ; — « Monté » et « Accroupi » : envoi d’un signal à la famille ou au médecin pour avertir que la personne adopte des comportements dangereux pouvant la conduire à des situations telles que la chute ; — « Assis » et « Allongé Canapé » : enregistrement du temps passé dans cette situation que l’on nommera activité « passive ». Ainsi à la fin de chaque journée, le système pourra fournir un résumé des informations concernant : — le cumul du temps passé dans une activité « passive » ; — le cumul du temps passé dans une activité « active » ; — le nombre de changements d’activité ; — la moyenne des longueurs de pas, cadence et vitesse de marche de la journée. Il sera alors possible d’observer l’évolution dans le temps (dans la semaine, le mois ou l’année) de ces indicateurs. Cette information, couplée à l’évolution des paramètres de la marche de la personne, est un critère d’évaluation de la perte ou non d’autonomie de la personne. L’alerte automatique aux proches ou aux professionnels de la santé, en cas de chutes et d’activités à risque, permettra de sécuriser la personne au domicile. Les différents algorithmes construits permettent donc d’apporter un ensemble d’informations, qui couplées ensembles, pourront aider à maintenir la personne plus longtemps à son domicile. Marche Temps actif Mesure des paramètres Allongé Sol Alerte Chute Assis Monter Accroupi Signaler Allongé Temps passif Figure 10.1 – Les différentes actions réalisées par l’algorithme selon l’état dans lequel se trouve la personne d’après le MMC. 12810.2. Cartographie des habitudes dans l’environnement 10.2 Cartographie des habitudes dans l’environnement L’objectif dans cette section est de développer une méthode d’apprentissage des habitudes des personnes dans l’environnement. Plus précisément, nous voulons cartographier les activités courantes de la personne selon l’endroit de la pièce dans lequel elle se trouve. Ainsi, l’évolution des habitudes au cours des semaines ou des mois peut constituer un indicateur de modification de l’état de la personne, par exemple si elle reste plus longtemps allongée qu’à son habitude. Pour constituer la carte des habitudes de la personne, nous devons relever ses activités au cours du temps. Lors de l’apprentissage de cette carte, nous devons tenir compte du fait que quand la personne n’est pas entièrement visible, l’activité qu’elle réalise n’est pas certaine. Par exemple, quand la personne se trouve derrière une table à moitié visible nous ne pouvons pas connaitre avec certitude son activité. Nous devons différencier dans la carte les zones où la personne est vue entièrement des zones où elle peut être cachée. 10.2.1 Limitations du système et contraintes de l’environnement Les occlusions peuvent être de différentes natures. Comme nous l’avons étudié à la section 8.2, les occlusions peuvent être dues aux meubles de la pièce. En effet, les tables ou les chaises peuvent, par exemple, bloquer la visibilité de la personne. De la même façon, en bordure du champ de vision de la caméra, la personne n’est que partiellement visible. Donc, les problèmes d’occlusions, dues aux meubles et aux limites du champ de vision de la caméra, sont à prendre en compte lorsque l’on suit la trajectoire d’une personne. En effet, si l’analyse des activités est effectuée lorsque la personne est à moitié cachée l’activité ne sera peut être pas reconnue, comme nous l’avons vu à la section 8.2. La figure 10.2 illustre le cas d’une personne marchant à la limite du champ de vision de la caméra. L’image couleur nous montre que la personne est à moitié détectée. Son côté gauche se trouve en dehors du champ de vision de la caméra. Figure 10.2 – Personne sortant du champ de vision et étant à moitié détectée. La section 8.2 permet de constater que certains de nos modèles de Markov cachés sont robustes aux occlusions, en classifiant correctement les activités, dans des conditions non rencontrées lors de l’apprentissage. La plupart des modèles ont le même problème qui est de confondre les trois activités « Penché », « Accroupi » et « Chute ». Ainsi, même s’il est possible de reconnaitre certaines activités dans les zones d’occlusion il est important d’identifier ces zones dans lesquelles les performances du système sont différentes. Les zones de sortie du champ de 129Chapitre 10. Vers une implantation au domicile vision sont également à prendre en compte dans l’interprétation des résultats produits par le système. Ces zones de sorties se situent en bord d’image mais également dans les franchissements de portes si celles-ci se trouvent dans le champ de vision. Nous devons donc différencier les moments où la personne est cachée, des situations où elle est entièrement visible pour intégrer cette information dans la carte des habitudes. 10.2.2 Détection des cas d’occlusions partielles de la personne La méthode proposée pour détecter les cas d’occlusions est fondée sur le calcul de la vraisemblance permettant de savoir si le modèle correspond aux observations. La vraisemblance est une mesure de la probabilité des observations O sachant le modèle λ, soit P(O|λ). Elle est calculée à partir des probabilités obtenues dans la phase Forward de l’algorithme Forward-Backward. Pour rappel, la phase Forward permet de calculer le α pour chaque état, à chaque instant. La vraisemblance correspond au calcul suivant : V raisemblance(t) = logΣ N i=1αt(i). La vraisemblance à l’instant t est égale à la somme des probabilités α à t pour tous les états. Le logarithme de la vraisemblance est préféré pour représenter les résultats. L’idée ici est de comparer les valeurs prises par la vraisemblance lorsque la personne est entièrement visible, avec les valeurs prises lorsque la personne n’est pas entièrement visible. Nous avons alors demandé à une personne d’effectuer les huit activités (les mêmes qui étaient utilisées pour construire les MMC) pour obtenir l’échantillon des valeurs prises par la vraisemblance lorsque la personne effectue les différentes activités en étant entièrement visible. Ensuite nous avons demandé à la personne de réaliser les séquences derrière des obstacles pour obtenir un échantillon de valeurs prises par la vraisemblance lorsque la personne est cachée. Chaque sé- quence a été analysée avec le MMC à 8 états et 3 observations. Ces situations correspondent aux situations décrites au chapitre 8. Les valeurs de la vraisemblance pour chaque activité, réalisée en condition « Caché » et entièrement « Visible », sont représentées à la figure 10.3. Chaque courbe correspond aux valeurs de la vraisemblance à chaque pas de temps. Nous avons inscrit sur chaque graphe les situations réalisées par le sujet. Par exemple, pour le graphe correspondant à la situation « Marcher - Caché », la personne marche en étant visible jusqu’à 44,1 s, puis continue de marcher derrière des chaises en étant à moitié visible. En comparant les situations réalisées lorsque la personne est visible et cachée, nous pouvons voir que les valeurs prises par la vraisemblance sont plus petites quand la personne est cachée. En d’autres termes, le modèle correspond mieux aux observations quand la personne est entièrement visible. Ce constat est logique puisque le modèle a appris sur une base de données ne contenant que des situations où la personne est entièrement visible. Nous pouvons également constater que les valeurs de la vraisemblance effectuent un pic vers le bas lorsque la personne passe d’une activité où elle est entièrement visible à une activité où elle est en partie cachée. Par exemple, pour la situation « Marcher - Caché », le passage de l’état visible à caché est très net par rapport aux valeurs de la vraisemblance. Dans le cas des situations réalisées en étant visibles, nous pouvons également constater une descente des valeurs de la vraisemblance, mais moins prononcée, lorsque la personne change d’activité. Par exemple, les situations « S’accroupir - Visible » ou « S’asseoir - Visible » ont une légère descente des valeurs de la vraisemblance lorsque la personne passe de l’activité « Marche » à « Accroupi » ou « Assis ». Pour la situation « S’accroupir - Caché » et « Chuter+Allongé au sol - Caché », nous voyons que la courbe de la vraisemblance ne cesse de diminuer à un moment. Ce passage correspond au moment où la personne est entièrement cachée et où le modèle ne reçoit plus aucune information. 13010.2. Cartographie des habitudes dans l’environnement Se pencher - Visible Se pencher - Caché -80 -70 -60 -50 -40 -30 -20 28.5 29 29.5 30 30.5 31 31.5 32 32.5 Log Vraisemblance Temps (s) Marche Visible Marche Visible Penché Visible -90 -80 -70 -60 -50 -40 -30 -20 42 43 44 45 46 47 48 49 50 Log Vraisemblance Temps (s) Marche Visible Penché Caché Marche Visible S’accroupir - Visible S’accroupir - Caché -90 -80 -70 -60 -50 -40 -30 -20 27 27.5 28 28.5 29 29.5 30 30.5 31 31.5 Log Vraisemblange Temps (s) Accroupi Visible -90 -80 -70 -60 -50 -40 -30 -20 35 40 45 50 55 60 65 Log V raisem blance Tem p s (s) Accroupi Visible Accroupi Caché Accroupi Visible S’asseoir - Visible S’asseoir - Caché -90 -80 -70 -60 -50 -40 -30 -20 27 28 29 30 31 32 33 34 Log Vraisemblance Temps (s) Marche Visible Assis Visible Marche Visible -100 -90 -80 -70 -60 -50 -40 -30 -20 34 36 38 40 42 44 46 48 Log Vraisemblance Temps (s) Assis Caché Marche Visible Marche Visible S’allonger - Visible S’allonger - Caché -90 -80 -70 -60 -50 -40 -30 -20 30 32 34 36 38 40 42 Log Vraisemblance Temps (s) Marche Visible Allongé Visible Marche Visible -100 -90 -80 -70 -60 -50 -40 -30 -20 30 35 40 45 50 55 60 65 Log Vraisemblance Temps (s) Marche Visible Allongé Caché Marche Visible 131Chapitre 10. Vers une implantation au domicile Marcher - Visible Marcher - Caché -75 -70 -65 -60 -55 -50 -45 -40 -35 -30 -25 28 28.5 29 29.5 30 30.5 31 Log Vraisemblance Temps (s) Marche Visible -70 -65 -60 -55 -50 -45 -40 -35 -30 -25 38 39 40 41 42 43 44 45 46 47 48 Log Vraisemblance Temps (s) Marche Visible Marche Visible Marche Caché Chuter+Allongé au sol - Visible Chuter+Allongé au sol - Caché -80 -70 -60 -50 -40 -30 -20 28 30 32 34 36 38 40 42 44 46 Log Vraisemblance Temps (s) Chute Visible Marche Visible Marche Allongé Visible Visible -90 -80 -70 -60 -50 -40 -30 -20 32 34 36 38 40 42 44 46 48 50 52 54 Log Vraisemblance Temps (s) Marche Visible Chute Caché Marche Visible Allongé Caché Monter - Visible Monter - Caché -90 -80 -70 -60 -50 -40 -30 -20 28 29 30 31 32 33 34 35 Log Vraisemblance Temps (s) Marche Visible Monté Visible Marche Visible -80 -75 -70 -65 -60 -55 -50 -45 -40 -35 -30 -25 32 34 36 38 40 42 44 46 Log Vraisemblance Temps (s) Monté Visible Monté Caché Marche Visible Monté Caché Marche Visible Figure 10.3 – Courbes des vraisemblances pour différentes activités réalisées par un sujet entièrement et partiellement visible. 13210.2. Cartographie des habitudes dans l’environnement 1 2 3 4 5 6 7 8 Figure 10.4 – Séquence dans laquelle le sujet réalise plusieurs activités. Donc, à partir des valeurs de vraisemblance, il est possible de reconnaître une situation où la personne est cachée en utilisant un seuil en dessous duquel la personne sera considérée cachée par un obstacle. Ainsi, nous pouvons discriminer les situations où la personne est entièrement visible et celles où elle ne l’est pas. 10.2.3 Cartographie des habitudes Pour apprendre l’environnement, nous découpons la scène en zones de 50 cm de côté. Nous demandons à une personne d’effectuer plusieurs activités dans l’appartement expérimental. Nous y avons placé deux fauteuils mis côte à côte. Ainsi, la personne a pu s’asseoir, s’allonger, marcher derrière les fauteuils en étant cachée et marcher devant les fauteuils en étant visible. Cette séquence est montrée à la figure 10.4. Les images représentent les différentes activités réalisées par la personne. Le corps de la personne est toujours en partie visible durant toutes ces activités. L’algorithme apprend, pour chaque zone de l’environnement, la fréquence des activités réalisées par la personne, la visibilité ou non du corps de la personne et les bords du champ de vision de la caméra. Plus précisément, l’algorithme observe si la personne est cachée ou entièrement visible, par rapport à la valeur prise par la vraisemblance. Si la personne est visible, le modèle apprend pour la zone de l’environnement où elle se trouve qu’il est possible, à cet endroit, d’effectuer l’activité détectée. Si la personne est cachée par un meuble, le modèle apprend que la case, où elle se trouve, est localisée derrière un obstacle. Pour finir, nous considérons un bord comme étant l’endroit où la personne sort entièrement du champ de vision de la caméra. La figure 10.5 représente l’apprentissage de l’environnement qui a été construit lorsque la personne a effectué les différentes activités dans l’appartement expérimental. Les cases blanches correspondent aux zones non explorées. La personne n’a jamais été détectée à ces endroits. La couleur bleue représente les zones où la personne a été détectée comme réalisant une activité dite « passive ». Nous avons représenté une chaise dans cette case, pour montrer que dans cette zone se trouve une chaise, car le MMC a détecté que la personne était soit dans l’état « Allongé Canapé », soit dans l’état « Assis ». La couleur rouge représente les zones où la personne a été détectée comme étant cachée par un obstacle. La couleur verte représente les zones où la personne a été détectée réalisant une activité dite « active ». Le MMC a détecté que la personne était soit dans l’état « Marche », soit dans l’état « Debout ». Les proportions des couleurs dans chaque 133Chapitre 10. Vers une implantation au domicile case représentent les proportions des situations détectées. Nous pouvons voir que les zones rouges se situent correctement derrière les deux fauteuils. Les zones bleues, représentant les activités « passives », sont situées à l’endroit où se trouvent les deux fauteuils. Cela nous montre que les activités « Allongé Canapé » et « Assis » ont été correctement identifiées au niveau des deux fauteuils. Les zones vertes, représentant les activités « actives », sont situées à l’endroit où la personne a marché en étant entièrement visible. Sur la carte, nous pouvons également voir l’inscription « bord », placée là où la personne est sortie entièrement du champ de vision de la caméra. Figure 10.5 – Carte de l’environnement représentant les habitudes apprises d’une personne (en blanc : zones non explorées, en bleu : zones passives, en vert : zones actives et en rouge : zones se trouvant derrière un meuble). Dans la réalité, au domicile des personnes âgées, nous imaginons apprendre au fur et à mesure les activités réalisées par la personne pour construire la carte de leur environnement et de leurs habitudes. 10.2.4 Détection des anomalies La carte peut être utilisée comme une méthode de détection d’anomalies. La cartographie des habitudes de la personne permet d’identifier, à différents intervalles de temps par exemple, l’évolution des activités de la personne. L’évolution des habitudes peut être un indicateur d’une éventuelle anomalie dans l’état général de la personne. D’autres anomalies peuvent être détectées, en utilisant la carte, pouvant faire l’objet d’une alerte envoyée aux personnes extérieures. Notamment, lorsque la personne disparait du champ de vision, la carte peut renseigner sur sa proximité avec une zone d’occlusion et nous indiquer un risque de chute non visible. Nous détectons les moments où la personne est entièrement cachée après avoir visité une case rouge. L’algorithme calcule le temps passé dans cette situation. Si le temps est supérieur à un certain seuil (de quelques secondes), nous en déduisons une possibilité de chute. La figure 10.6 correspond à une situation où une personne se trouve cachée derrière un fauteuil. Sur l’image de l’apprentissage de l’environnement en haut à gauche, le cercle représente 13410.3. Conclusion la dernière position du centre de masse qui a été détectée lorsque la personne était encore visible. Nous pouvons voir que la position du cercle se trouve au dessus d’une case rouge, signifiant que cette zone a été apprise comme étant une case où la personne peut potentiellement être cachée. Un compteur est lancé à partir du moment où la personne n’a plus été visible, pour déterminer s’il y a chute ou non. A l’inverse, la carte peut nous aider à prendre en compte les zones de sorties habituelles du champ de vision. La personne peut sortir du champ de vision en bord d’image mais aussi suite au franchissement d’une porte qui serait visible dans la scène. Si la personne disparait du champ de vision à proximité d’une zone de sortie habituelle, l’alerte ne sera pas déclenchée. bord Figure 10.6 – Carte de l’environnement sur laquelle est représentée la dernière position du centre de masse perçue par le système. 10.3 Conclusion Le couplage entre la fonctionnalité de détection des activités et la fonctionnalité permettant d’extraire les indicateurs de marche permet d’obtenir de nombreuses données qui peuvent servir à sécuriser la personne à son domicile et évaluer son degré de fragilité. En mettant des outils en place, tels que la détection des occlusions et l’apprentissage de l’environnement, nous renforçons la robustesse du système pour permettre son fonctionnement au domicile, dans un environnement où les occlusions de la personne sont très courantes. 135Chapitre 10. Vers une implantation au domicile La carte de l’environnement permet de connaître les zones d’occlusions habituelles en cumulant au cours du temps l’analyse de la vraisemblance. La détection d’une occlusion peut ensuite se faire en regardant la position de la personne sur la carte, en étant robuste aux éventuelles variations ponctuelles de vraisemblance. Elle peut être utilisée pour éviter d’éventuelles fausses détections, en prenant en compte les zones d’occlusions et les activités habituelles dans la zone où l’alerte a été détectée. Enfin, la carte de l’environnement donne une représentation spatiale des habitudes qui peut être utilisée pour analyser plus finement les évolutions des habitudes de la personne. 136Chapitre 11 Autres perspectives d’utilisation du système Sommaire 11.1 Différenciation des personnes . . . . . . . . . . . . . . . . . . . . . 137 11.2 Couplage de plusieurs capteurs . . . . . . . . . . . . . . . . . . . . 138 11.3 Observance des patients . . . . . . . . . . . . . . . . . . . . . . . . 139 11.4 Prévention de certains troubles . . . . . . . . . . . . . . . . . . . 139 11.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Le système est actuellement conçu pour apporter une solution à la problématique du maintien à domicile des personnes âgées. Nous pensons que ce système pourrait avoir d’autres applications. Nous proposons ici quelques perspectives d’évolution et exemples d’utilisation du système. 11.1 Différenciation des personnes Le système actuel est prévu pour qu’il n’y ait qu’une seule personne dans le champ de vision de la caméra. Lorsque plusieurs personnes entrent dans le champ de vision de la caméra, le système analyse la marche et l’activité de l’une des personnes, qui n’est pas nécessairement la personne que l’on souhaite suivre. Ces erreurs d’attributions provoqueront des données aberrantes, pouvant gêner l’analyse de l’évolution des paramètres de la marche de la personne à suivre. Nous aimerions donc pouvoir distinguer les personnes entre elles pour analyser l’activité et la marche de la ou les personnes à suivre. Nous nous basons sur l’idée que chaque personne a une façon de marcher différente. Nous pourrions alors identifier chaque personne en prenant en compte un certain nombre de caracté- ristiques telles que sa taille, sa longueur de pas moyenne, sa cadence, sa vitesse de marche, la symétrie de sa marche, etc. La taille de la personne est une information que nous connaissons, car nous avons une méthode d’extraction du sol, comme présenté à la section 4.1, et une méthode de détection du point maximum du corps. Les longueurs, cadences et vitesses de marche sont également connues avec l’algorithme d’analyse de la marche. Et la symétrie des pas peut être obtenue en analysant la régularité des trajectoires du centre de masse. Nous pensons qu’il serait alors possible, à l’installation du système, d’apprendre les caractéristiques de la personne et de les mettre à jour au cours des évolutions. Ainsi, l’algorithme pourrait suivre plusieurs personnes en leurs attribuant les paramètres observés. 137Chapitre 11. Autres perspectives d’utilisation du système 11.2 Couplage de plusieurs capteurs Nous imaginons poser plusieurs caméras aux domiciles des personnes. Le positionnement des caméras serait effectué pour qu’il n’y ait pas de zone de recouvrement, car nous avons montré, au chapitre 7, que l’interférence entre caméras dégrade la précision des résultats. Par exemple, dans l’appartement expérimental, nous pensons installer les caméras comme montré à la figure 11.1. Une caméra serait installée pour couvrir le salon ayant une profondeur d’environ 7 m, une autre pour la cuisine et une dernière pour la chambre. Les caméras n’ayant pas de zone de recouvrement, certains endroits ne seront pas couverts. Les zones importantes où sont situés la table, les chaises, les fauteuils, le canapé et le lit doivent être vues. Une solution pour pallier au problème des zones non vues est d’effectuer les traitements concernant l’analyse de l’activité et l’apprentissage de l’environnement pour chaque caméra. Ainsi, lorsqu’une personne ne sera visible d’aucune caméra, sa dernière position visible sera recherchée. La carte de l’environnement de la caméra, où la personne est apparue visible, nous permettra de connaître la distance entre la personne et une zone d’occlusion ou une zone de bord du champ de vision. Si la personne était proche d’un bord, nous pourrons en conclure qu’elle se trouve, sûrement, entre deux champs de vision de caméra. Comme précédemment, nous pourrons ajouter la notion de temps et apprendre les habitudes de la personne. C’est-à-dire que nous pourrions apprendre combien de temps, la personne passe, généralement, entre chaque zone non visible par la caméra, pour savoir si la situation est normale. Figure 11.1 – Proposition d’emplacement de plusieurs caméras permettant de couvrir tout un appartement. Nous n’avons pas mis de caméra dans la salle de bains et les toilettes, à la figure 11.1, pour préserver l’intimité de la personne. L’idée serait de mettre d’autres capteurs, tels que des détecteurs d’ouvertures sur les robinets pour savoir si la personne est active. Ainsi, si aucune activité n’est détectée dans la pièce, nous pourrons en déduire un risque d’activité anormale. 13811.3. Observance des patients 11.3 Observance des patients Nous pensons que ce système pourrait servir au médecin, pour vérifier que le patient respecte, par exemple, les indications qui lui ont été données sur sa façon de marcher. En d’autres termes, le médecin pourrait évaluer l’observance du patient. Nous avons testé le système avec une personne âgée de 90 ans, ayant des problèmes d’équilibre. Nous lui avons demandé de marcher sans sa canne et avec sa canne. Quand la personne marche sans sa canne, la trajectoire du centre de masse n’est pas régulière comme illustré à la figure 11.2(a). A l’inverse, quand elle marche avec sa canne, la courbe du centre de masse suit une trajectoire sinusoïdale plus régulière, comme le montre la figure 11.2(b). Le médecin de cette personne lui a conseillé de marcher uniquement avec sa canne au domicile pour lui éviter de chuter et pour ne pas empirer ses problèmes d’équilibre. Ce système lui permettrait donc de pouvoir observer, à travers la régularité, ou non, de la trajectoire du centre de masse, si la personne respecte ses conseils. Ainsi, il pourrait prévenir les futures évolutions de l’état de la personne liées à la non utilisation de la canne, alors qu’actuellement le médecin constate les dégradations lorsque la personne chute. 550 600 650 700 750 800 850 900 47 48 49 50 51 52 53 54 Y (mm) Temps (s) (a) Marche sans la canne. 550 600 650 700 750 800 850 900 46 46.5 47 47.5 48 48.5 49 49.5 50 50.5 Y (mm) Temps (s) (b) Marche avec canne. Figure 11.2 – Représentation du centre de masse, sur l’axe vertical, d’une personne de 90 ans ayant des problèmes d’équilibre . En restant dans le même contexte, cet outil pourrait également être utile pour que le mé- decin évalue l’observance dans le cas des patients en rééducation, suite à un accident ou une amputation par exemple. Un des problèmes en rééducation est le retour des patients au domicile. Les personnes à l’hôpital suivent les exercices qui leur sont indiqués par le personnel soignant. Mais, une fois de retour chez eux, ils ne continuent pas l’entrainement instauré par le médecin. L’installation d’un tel système au domicile permettrait au médecin de revoir avec le patient chaque semaine, chaque mois, les trajectoires de son centre de masse. Il pourrait alors savoir si son patient continue la rééducation en marchant correctement chez elle et continue de progresser. 11.4 Prévention de certains troubles L’analyse de la marche est utilisée, dans le système actuel, comme indicateur de fragilité et de chute à venir. A la section 5.3, nous avons présenté certaines études montrant que l’analyse des troubles de la marche peut aider à détecter les risques d’hospitalisations, les troubles cognitifs et les démences. Nous pouvons imaginer, tout comme pour la prévention de la fragilité, d’évaluer au quotidien les paramètres de la marche et d’observer leur évolution dans le temps. Les personnes seraient alors orientées, assez rapidement, vers les spécialistes adéquates. Comme il a été dit à 139Chapitre 11. Autres perspectives d’utilisation du système la section 5.3.3, dans le cas des démences, l’un des problèmes majeurs est que bien souvent les personnes sont prises en charge trop tard. Avec un système analysant la marche au quotidien, nous pouvons alerter dès les premiers signes de troubles et les orienter vers des neuropsychologues par exemple, pour leur faire passer des tests cognitifs. Pour rendre le système capable de prévenir ces différents troubles, nous devons mettre en place des expérimentations pour connaître les seuils à partir desquelles nous alerterons les médecins. Aujourd’hui, il y a peu d’information à ce sujet, car l’évaluation de la marche n’est pas une pratique courante pour déceler un problème cognitif ou un risque d’hospitalisation. 11.5 Conclusion Ce système a été pensé pour répondre au besoin du maintien à domicile des personnes âgées. La détection de chutes des personnes âgées au domicile est une thématique pouvant concerner d’autres populations comme les personnes handicapées ou même les personnes épileptiques, dont un des symptômes possibles est la perte de connaissance entrainant des chutes. La chute est souvent brutale et peut entraîner des conséquences physiques empêchant la personne de se relever. Nous pouvons également imaginer que l’analyse de la marche puisse être détournée de sa fonction première qui était de prévenir les chutes et la fragilité des personnes âgées. L’analyse de la marche, au quotidien au domicile, peut être un outil supplémentaire pour le médecin pour prévenir les risques d’hospitalisations et de démences. Cet outil peut également permettre d’analyser les anomalies de symétrie de la marche et ainsi fournir une indication concernant l’évolution des progrès d’une personne suite à un accident par exemple. Sur le plan technique, nous avons identifié la possibilité d’utiliser les mêmes algorithmes pour distinguer et suivre plusieurs personnes en constatant que les caractéristiques extraites sont spécifiques à chacun. Une autre perspective d’évolution est le couplage de plusieurs caméras pour permettre une meilleure couverture du domicile. Ce couplage pose la question du non recouvrement des champs de vision et de la gestion des zones aveugles entre les caméras. Enfin, la fusion de l’information provenant de capteurs complémentaires installés dans des pièces telles que la salle de bains ou les toilettes permettrait de compléter la zone de surveillance tout en conservant l’acceptabilité du système. 140Conclusion Cette partie permet de montrer le couplage des deux contributions de la thèse, la détection d’activités et l’analyse de la marche, pour former un système permettant le maintien à domicile des personnes âgées. Le système pourrait envoyer une alerte aux personnes extérieures en cas de détection de l’activité « Chute » et des activités à risque, « Accroupi » et « Monté ». Il pourrait, également, évaluer au quotidien les paramètres de la marche de la personne et comparer ses activités à celles réalisées habituellement, dans le but d’évaluer l’état de fragilité de la personne. Ce système peut fonctionner pour une personne entièrement visible et cachée par des meubles. Une carte de l’environnement, représentant les habitudes des personnes et découpant la scène en zones d’activités possibles à cet endroit, est ajoutée au système pour le rendre plus robuste dans les cas des zones partiellement occultées par des meubles. Ce système peut également avoir d’autres applications. Il pourrait nous servir à distinguer les personnes. Actuellement, une seule personne est détectée dans la scène. Dans le cas où plusieurs personnes sont dans la scène, le système pourrait suivre la personne qui nous intéresse parmi d’autres, ou en suivre plusieurs et distinguer les informations appartenant à chacune d’entre elles. Cette distinction se ferait par l’apprentissage de caractéristiques discriminant chaque personne. Une autre utilité, que nous avons évoquée dans ce chapitre, est la possibilité de coupler les caméras entre elles et avec d’autres capteurs pour ainsi avoir des informations dans toutes les pièces de la maison. Nous avons, également, évoqué dans cette partie la possibilité d’utiliser ce système comme outil de suivi de l’observance pour les médecins. Ce système pourrait, aussi, prévenir d’autres risques comme les troubles cognitifs ou les risques d’hospitalisation. 141Conclusion 142Conclusion générale et perspectives 143L’augmentation du nombre de personnes âgées est un enjeu majeur de santé publique des prochaines années. Le maintien à domicile s’avère être une préoccupation importante pour les personnes âgées et leur famille. Mais le domicile n’est pas un endroit sans risque pour les personnes, il peut même être responsable de leur perte d’autonomie. Une des causes fréquentes de perte d’autonomie au domicile est la chute. Les séquelles physiques peuvent conduire la personne au handicap ou à des incapacités locomotrices, entrainant une perte d’autonomie pouvant mener au placement en institution. Les séquelles psychologiques sont aussi très fréquentes après une chute. Le risque de séquelles psychologiques augmente avec le temps passé au sol. Elles provoquent la diminution des activités et des sorties par peur de rechuter. Ces séquelles ont pour effet d’entraîner les personnes vers une perte d’autonomie et de compromettre leur maintien à domicile. Pour que les personnes âgées puissent rester le plus longtemps possible autonomes à leur domicile, il est nécessaire de les sécuriser chez elles en détectant les chutes pour intervenir le plus rapidement possible et diminuer les risques de séquelles physiques et psychologiques. En plus de détecter les chutes, nous pensons qu’il est également nécessaire de prévenir les chutes et plus généralement de prévenir les risques de fragilité de la personne. Actuellement, à l’hôpital, il est possible de mesurer, lors des consultations, le niveau de dépendance des personnes à l’aide de tests cliniques, analysant la marche de la personne. Ces mesures sont alors faites dans des conditions modifiées comparées aux mesures qui pourraient être faites au domicile. Notre objectif est donc de proposer un système permettant de détecter les chutes pour éviter l’aggravation des séquelles physiques et psychologiques et détecter, dans le milieu écologique, une détérioration du comportement locomoteur pour ainsi prévenir la fragilité des personnes. Ainsi, nous aurons une mesure quotidienne pour évaluer l’évolution de la personne. Dans cette thèse, nous proposons un système, pour détecter les chutes et prévenir la fragilité des personnes âgées. Pour détecter les chutes, nous avons développé un algorithme de reconnaissance des chutes et des comportements à risque pouvant entraîner une chute, comme monter sur une chaise ou s’accroupir. Pour prévenir la fragilité, nous avons développé un algorithme de détection d’activité, pour savoir si la personne continue de réaliser autant d’activité qu’à son habitude, et un algorithme d’analyse de la marche, pour évaluer l’évolution de ses comportements locomoteurs. Ces deux algorithmes permettent d’établir un degré de fragilité des personnes, comme les médecins le font en consultation avec leurs tests cliniques. En résumé, nous avons contribué à la conception d’un système d’aide au maintien à domicile des personnes âgées, par le développement d’un algorithme de détection d’activité (capable, entre autres, de nous détecter les chutes et les situations à risque) et le développement d’un algorithme d’analyse de la marche. Le système que nous avons imaginé doit, pour pouvoir être installé au domicile, être peu coûteux et ne pas perturber la vie quotidienne des personnes. Nous avons donc développé des algorithmes possibles à implémenter dans n’importe quelle machine bas coût et fonctionnant en temps réel pour pouvoir détecter les chutes le plus rapidement possible. Le système repose sur un capteur bas coût, non embarqué sur la personne. Nous avons choisi d’utiliser la caméra de profondeur de Microsoft. A partir de cette caméra, nous pouvons détecter la personne à son domicile avec un algorithme de soustraction du fond très simple et peu coûteux en temps de calcul. Le fond est appris à partir de l’image de profondeur et la personne est extraite de la scène par soustraction. Suivre la personne dans le temps peut requérir beaucoup de ressource, car chaque partie du corps a des mouvements indépendants qu’il est possible de suivre séparément. Par souci d’économie, nous extrayons quelques paramètres de l’image nous permettant de représenter la personne au cours du temps. Tout d’abord, nous nous intéressons au centre de masse, car certains auteurs ont mis en évidence que pour suivre le déplacement du corps en mouvement, la trajectoire du centre de masse est une information riche. A partir du centre de masse, nous pouvons obtenir des informations comme la position, la vitesse verticale et horizontale. Nous avons également 145extrait deux autres paramètres qui ont une importance pour détecter l’activité, il s’agit de la dispersion verticale de la silhouette et du point maximum du corps. Ces 5 paramètres, simples à extraire, sont les caractéristiques représentant la personne au cours du temps et sur lesquels nos algorithmes de détection d’activité et d’analyse de la marche sont fondés. Selon la littérature, l’analyse des paramètres de la marche, tels que les longueurs de pas, la cadence et la vitesse de marche sont de bons indicateurs de l’évolution de la fragilité des personnes âgées. L’algorithme d’extraction des paramètres de la marche d’une personne est fondé sur une seule caractéristique représentant la personne, à savoir le centre de masse. A partir du centre de masse et de la détection des maxima locaux sur l’axe vertical, nous obtenons les paramètres de la marche. En comparant les paramètres de la marche fournis par notre algorithme et ceux obtenus avec une méthode de référence, pour 10 sujets participant à l’expérience, nous obtenons des résultats assez précis puisque l’erreur obtenue est comparable à l’erreur due à la précision de la caméra. L’algorithme de détection d’activité, fondé sur des modèles de Markov cachés, permet de discriminer entre 8 et 9 activités selon le modèle construit. Il permet de reconnaître les activités s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle, s’allonger sur un lit ou un canapé, chuter, être allongé au sol et certains modèles identifient aussi l’activité être debout. Les modèles construits distinguent les activités à partir de 3 ou 5 observations représentant les personnes. Les modèles reconnaissant 8 activités se basent sur la position et vitesse du centre de masse et la distribution verticale de la silhouette. Les modèles reconnaissant 9 états se basent sur 5 paramètres en ajoutant la vitesse horizontale et le point maximum du corps. Une base de données a été construite en demandant à 28 sujets de réaliser des situations correspondantes aux activités devant être reconnues. Les paramètres des différents modèles construits, comme les probabilités de transition, les probabilités initiales, les fonctions d’observations sont apprises à partir de quelques séquences de la base de données. Les séquences restantes de la base servent à vérifier la validité des modèles pour classifier correctement les activités. Ainsi, nous avons pu constater que les modèles discriminants 8 activités classifient correctement toutes les situations sans faire de fausses détections, notamment sans déclarer une chute alors qu’il n’y en a pas. Les modèles détectant 9 activités ont des bons taux de classifications également mais indiquent trop souvent l’activité chute alors qu’elle n’est pas réalisée. Malgré l’augmentation du nombre d’observations pour discriminer les activités (5 pour les modèles discriminant 9 états, et 3 pour ceux discriminant 8 activités), l’augmentation de la complexité du modèle ne permet pas d’être plus performant pour reconnaître les activités, au contraire cela ajoute du bruit. En revanche, les modèles discriminant les activités à partir de 5 observations ont l’avantage d’être plus robustes aux situations où la personne n’est pas entièrement visible. Ces situations sont considérées comme nouvelles, car la base de données ne contenait que des situations où la personne était entièrement visible. Les algorithmes de détection d’activité et d’analyse de la marche ont été testés sur quelques personnes âgées. Les tests montrent que certaines situations sont reconnues. Pour la suite, il est toutefois nécessaire de refaire des expérimentations avec des personnes âgées pour créer une nouvelle base de données adaptée à la bonne catégorie de personnes. De plus, même si les personnes âgées ont une façon de marcher différente des personnes jeunes, l’algorithme est toujours capable d’extraire les paramètres de la marche. Une étude plus approfondie permettra de déterminer si la précision des paramètres de la marche, extrait avec notre système, est similaire à la précision obtenue dans l’expérimentation avec les sujets jeunes. Ces premiers tests nous ont également permis de constater d’autres applications possibles du système. Notamment, l’observation de la trajectoire générale du centre de masse pourrait être un indicateur d’observance pour le médecin. La trajectoire pourrait également servir comme indicateur pour discriminer plusieurs 146personnes dans une scène, car chaque trajectoire présente des irrégularités qui sont propres à chaque personne. L’une des difficultés est de concevoir un système assez générique pour pouvoir être utilisé pour une population de personnes très disparate. Nous ne pouvons pas insérer manuellement des seuils à partir desquelles alerter les personnes d’une perte d’autonomie. Le système doit être capable de s’adapter à chaque personne, à partir d’une quantité suffisante de données, pour qu’il puisse apprendre ses habitudes au fur et à mesure. Il doit également apprendre les paramètres de la marche habituels et pouvoir ainsi détecter les seuils au-delà desquels l’évolution doit être considérée comme anormale. Ces seuils doivent être appris automatiquement par l’algorithme. L’algorithme d’analyse de la marche et celui de détection d’activité peuvent être regroupés dans un système unique. Chaque caméra placée dans une pièce de la maison analyserait l’activité de la personne. Chaque détection des activités « Chute », « Accroupi » ou « Monté Obstacle » serait signalée aux personnes extérieures pour intervenir le plus rapidement possible en cas de chute. Les détections de l’activité « Marche » permettraient de lancer l’algorithme d’extraction des paramètres et de calculer le temps passé dans cette activité. Ce temps serait alors comparé au temps passé dans les situations « Assis » et « Allongé ». L’analyse de l’évolution des paramètres de la marche et l’évolution des activités constituerait des informations dans le cadre de la prévention de la fragilité. Ce système a été pensé en vue d’être expérimenté au domicile des personnes âgées. Dans les objectifs, nous avions mentionné que nous voulions construire un système réaliste, utilisable. Se pose également la question de l’acceptation du système par les personnes. Peu d’études évaluent la perception qu’ont les personnes âgées face aux nouvelles technologies pouvant être installées à leur domicile. La question de l’acceptabilité est davantage nécessaire pour l’installation de caméras qui pose le problème du respect de la vie privée de la personne. Bellotti et Sellen [Bellotti and Sellen, 1993] précise qu’il est nécessaire de répondre à quatre catégories de questions lorsque l’on crée un système ayant pour objectif d’être installé au domicile. La réponse à ces problématiques peuvent influencer la façon dont la personne perçoit l’intrusion dans sa vie privée de la technologie, à savoir : quand et quelle information est enregistrée, comment l’information est enregistrée et une fois enregistrée ce qui lui arrive, qui a accès à l’information et comment l’information est utilisée. Les systèmes doivent être techniquement fiables et inspirer la confiance chez les utilisateurs. Malgré le peu d’articles existants sur l’acceptation des caméras à domicile, nous pouvons citer quelques auteurs proposant des débuts de réponse et des pistes à prendre en compte pour développer un système qui sera mieux accepté. Selon Caine et al. [Caine et al., 2005], les personnes seraient prêtes à faire des compromis par rapport à leur vie privée si cela leur permet de rester indépendantes. Melenhorst et al. [Melenhorst et al., 2004] ont également montré que les technologies perçues comme envahissantes pour l’intimité sont susceptibles d’être acceptées si elles sont considérées comme nécessaires pour répondre à un besoin. D’autres articles montrent que l’anonymat des images pourrait être une solution pour rendre les systèmes à base de caméra moins intrusifs dans l’intimité des personnes. Notamment l’étude de Demiris et al. [Demiris et al., 2009] consistait à demander à 10 personnes d’effectuer plusieurs scénarios représentants des activités de la vie quotidienne comme s’asseoir dans le salon, accueillir un visiteur, préparer un repas, etc. Ces séquences étaient enregistrées par deux webcams et analysées de façon à rendre les images anonymes. Pour cela, ils ont utilisé une méthode de soustraction du fond pour obtenir uniquement la silhouette. Puis ils ont créé une deuxième représentation en modifiant la silhouette pour la transformer en 3 dimensions. Les deux représentations étaient alors montrées aux personnes lors d’interviews. Les interviews ont été menées autour des quatre problématiques qui ont été décrites par Bellotti et Sellen. Les réponses aux interviews ont montré que les personnes s’intéressaient à comprendre comment le système fonctionne, comment est 147extraite la silhouette. Les interviews ont également indiqué que l’utilisation des vidéos réduite au simple suivi de la silhouette atténuait les préoccupations concernant le respect de la vie privée, car pour les personnes la vidéo restait anonyme. Par contre la représentation 3D n’a pas été appréciée. Selon les commentaires des personnes, cette représentation enlevait ce qui caractérise la personne, ils ne se reconnaissaient plus et donc ils ne voyaient pas comment le système pouvait être utilisé à des fins de sécurisation. Cela confirme la nécessité pour les utilisateurs d’avoir une compréhension non seulement de la sortie du système, mais aussi de ses processus et de son but. Elles ont également exprimé le désir de contrôler le fonctionnement du système en étant en mesure de l’éteindre et de l’allumer quand elles le désiraient. De plus, elles ont souligné l’importance de pouvoir déterminer elles-mêmes les personnes qui pourront avoir accès à l’information recueillie. Selon les personnes interrogées, certaines voulaient que les proches puissent avoir accès à l’information pour les rassurer et d’autres ne le souhaitaient pas. A la question de l’intérêt d’un tel système, neuf personnes sur dix ont répondu qu’elles ne voulaient pas installer ce système chez elles, car elles ne jugeaient pas en avoir besoin, elles se sentaient indépendantes. La seule personne qui voulait installer ce dispositif avait récemment chuté et a précisé qu’un tel système aurait été utile lors de sa chute pour alerter des personnes. Pour construire le système final, nous devons donc prendre en compte ces différentes préconisations pour que le système soit accepté. Les images doivent rester anonymes. Pour cela, le système est conçu pour que l’analyse des images puisse être faite localement et que seules les mesures d’activité soient transmises ou stockées. Nous ajouterons au système la possibilité de l’éteindre ou l’allumer. Cette action est non seulement utile pour la personne suivie mais aussi pour les personnes extérieures (personnel soignant et famille) qui pourraient avoir des réticences à être filmées. L’utilisateur doit être mis dans la boucle en lui expliquant l’intérêt qu’il a d’installer un tel système, lui expliquer le fonctionnement et lui laisser la décision de qui aura accès aux données. 148Annexe A Modèle de Markov caché Le modèle de Markov caché est la méthode paramétrique choisie pour développer un algorithme de détection d’activité. Avant de définir le formalisme, nous présentons le cas plus général des processus de Markov. Nous présentons également les différents algorithmes, de la littérature, utilisés pour l’apprentissage et l’inférence dans les modèles de Markov cachés. A.1 Définition des modèles de Markov cachés A.1.1 Processus de Markov Un modèle de Markov est un processus stochastique dont le but est de représenter l’évolution dans le temps de l’état d’un système. Les modèles de Markov suivent l’hypothèse de Markov, selon laquelle l’état courant ne dépend que d’un nombre fini et fixé d’états précédents. En d’autres termes, l’état dans lequel se trouve le système au temps t ne dépend que de l’état dans lequel il se trouvait aux temps t−1, t−2, . . . , t−n, n étant le nombre d’états antérieurs que l’on souhaite prendre en compte. Les processus satisfaisant cette hypothèse sont appelés processus de Markov ou chaînes de Markov. Deux éléments composent un modèle de Markov, les états et les transitions. Une transition est définie comme la probabilité de passer d’un état à un autre. A chaque pas de temps, une transition est appliquée au modèle qui modifie son état selon une certaine probabilité. La représentation d’un modèle de Markov, à deux états, est présentée à la figure A.1. Sur cette figure sont représentés deux états et les probabilités de transition entre chaque état. Par exemple, la probabilité de passer de l’état 1 à l’état 2 est de 70 %. Etat 1 Etat 2 0,7 0,3 0,8 0,2 Figure A.1 – Exemple de modèle de Markov à deux états. Les modèles de Markov permettent d’étudier l’évolution de la séquence d’états produite par le modèle, et surtout sa probabilité d’apparition. C’est pourquoi, une autre façon de représenter les chaines de Markov est fondée sur le temps. La chaine de Markov à la figure A.2 représente une séquence d’états de 0 à t, où Xi représente l’état à l’instant i. 149Annexe A. Modèle de Markov caché X0 X1 Xt Figure A.2 – Représentation graphique d’une chaine de Markov. A.1.2 Modèle de Markov caché Un modèle de Markov caché (MMC), en anglais Hidden Markov Model (HMM), est basé sur un modèle de Markov avec la particularité que les états ne sont pas directement observables [Rabiner, 1989]. Chaque état conditionne les observations qui sont visibles et qui permettront d’estimer l’état courant. Un MMC étudie l’évolution d’une séquence d’observations mesurées dans un système, comme représenté à la figure A.3. La figure illustre un MMC évoluant dans le temps avec Xt les états cachés, représentés en gris, et Ot les observations. Un MMC est défini par : — un ensemble d’états ; — une matrice aij = P(Xt = j|Xt−1 = i) représentant toutes les probabilités de transition entre chaque paire d’états ; — une probabilité initiale πi = P(X0 = i) pour chaque état i, qui est la probabilité a priori que le système se trouve dans l’état i à t = 0 ; — une fonction d’observation bi(o) = P(Ot = o|Xt = i). X0 O0 X1 O1 Xt Ot Figure A.3 – Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. A.2 Algorithmes d’apprentissage et d’inférence L’objectif de cette section est de présenter les algorithmes capables d’inférer, pour un MMC, dans quel état se trouve la personne à chaque pas de temps. Les MMC peuvent être utilisés soit individuellement, soit par combinaison. Pour résoudre les systèmes basés sur un unique MMC, les algorithmes d’inférences couramment utilisés sont les algorithmes Forward-Backward et de Viterbi [Rabiner, 1989]. Pour résoudre les systèmes à base de combinaison de MMC, un algorithme d’inférence et un algorithme d’apprentissage, tel que l’algorithme de Baum-Welch, sont nécessaires. A.2.1 Inférence pour le cas du MMC unique Deux algorithmes peuvent résoudre l’inférence, l’algorithme Forward-Backward et l’algorithme de Viterbi. Algorithme Forward-Backward L’algorithme Forward-Backward est utilisé ici pour calculer la probabilité d’être dans tel ou tel état, connaissant les observations et le modèle. Le modèle constitue un ensemble d’hypothèses 150A.2. Algorithmes d’apprentissage et d’inférence que l’on définit comme vrai. La probabilité de chaque état est représentée par la variable γ et l’équation qui en découle est la suivante : γt(i) = P(qt = i|O, λ) avec qt l’état au temps t, O la séquence d’observation O = (o1o2 . . . oT ) et λ le modèle. La variable γ calcule donc la probabilité d’être dans l’état i au temps t, sachant la séquence d’observation O et le modèle λ. Pour calculer la variable γ, il est nécessaire de calculer des variables intermédiaires obtenues grâce à deux étapes, Forward et Backward. La phase Forward permet de calculer la probabilité jointe d’observer une séquence de valeurs passées et d’être dans tel état. La phase Backward calcule la probabilité d’être dans tel état sachant les observations futures. Ainsi, la probabilité γ de l’état sachant les observations passées et futures est calculée à partir des deux variables obtenues avec Forward et Backward. Forward L’idée est de calculer la probabilité jointe de la séquence d’observation O = (o1, o2, . . . , ot) (jusqu’au temps t) et de l’état i au temps t, sachant le modèle λ. L’équation à résoudre est la suivante : αt(i) = P(o1, o2, . . . , ot , qt = i|λ). La première étape de l’algorithme initialise la probabilité α comme la probabilité jointe de l’état i et de l’observation initiale o1 : α1(i) = πibi(o1), pour 1 ≤ i ≤ N c’est-à-dire que la valeur α de l’état i au temps t = 1 est égale à πi , la probabilité initiale de l’état i, multipliée par bi(o1), la probabilité d’observation de l’état i. Pour l’induction allant de t > 1 à t = T, le α est égal à : αt+1(j) = "X N i=1 αt(i)aij# bj (ot+1), pour 1 ≤ t ≤ T − 1 et pour 1 ≤ j ≤ N, avec N le nombre d’état, aij la probabilité de transition entre i et j, bj (ot+1) la probabilité d’observation de l’état j au temps t + 1. Ce calcul est représenté graphiquement à la figure A.4. Cette figure est une illustration, pour un MMC à trois états, du calcul de la probabilité effectué pour αt+1(j = 1) par Forward. Dans l’implémentation, une étape de normalisation est nécessaire pour permettre aux valeurs de rester dans un domaine représentable numériquement, soit : α 0 t+1(j) = αt+1(j) hPN j=1 αt+1(j) i, pour 1 ≤ j ≤ N. Backward L’idée est de calculer la probabilité d’être dans un état sachant les observations futures. Contrairement à Forward, la probabilité à l’instant t est calculée à partir de la probabilité à l’instant t + 1 c’est-à-dire que le calcul se fait à partir du dernier pas de temps T jusqu’au début de la séquence, sachant le modèle λ. L’équation à résoudre est : βt(i) = P(ot+1, ot+2, . . . , oT , qt = i|λ). 151Annexe A. Modèle de Markov caché α(i = 1) α(i = 2) α(i = 3) α(j = 1) t t + 1 i = 1 i = 2 i = 3 j = 1 j = 2 j = 3 a11 a21 a31 Figure A.4 – Représentation du calcul αt+1(j = 1) par l’algorithme Forward pour un modèle à trois états. A l’initialisation, le β vaut 1 pour tous les états : βT (i) = 1, pour 1 ≤ i ≤ N. Pour l’induction allant de t = T − 1 à t = 1, le β est égal à : βt(i) = X N j=1 aij bj (ot+1)βt+1(j), pour t = T − 1, T − 2, . . . , 1 et pour 1 ≤ i ≤ N, avec N le nombre d’état, aij la probabilité de transition entre i et j, bj (ot+1) la probabilité d’observation de l’état j au temps t + 1. Ce calcul est représenté graphiquement à la figure A.5. Cette figure est une illustration, pour un MMC à trois états, du calcul de la probabilité effectuée pour βt(i = 1) par Backward. Dans l’implémentation, une étape de normalisation est effectuée à chaque pas de temps soit : β 0 t (i) = βt(i) hPN i=1 βt(i) i, pour 1 ≤ i ≤ N. Couplage Forward-Backward Après avoir calculé α et β pour chaque pas de temps, γ est alors déduit à partir de ces deux valeurs pour ainsi donner les probabilités d’apparition de chaque état de t = 1 à t = T, sachant les observations passées et futures et le modèle. L’équation à calculer est la suivante : γt(i) = αt(i)βt(i) PN i=1 αt(i)βt(i) , pour 1 ≤ i ≤ N. L’état le plus probable à chaque pas de temps est déduit en prenant la valeur du γ la plus grande. M ax(γt(i)) conserve l’état parmi tous les états au temps t ayant le γ le plus élevé. Ainsi dans notre cas, nous obtiendrons l’état dans lequel la personne est passée. Et comme à chaque état du MMC correspond une activité, ainsi nous obtenons, en conservant l’état ayant la plus grande probabilité, l’activité qui est réalisée par la personne. 152A.2. Algorithmes d’apprentissage et d’inférence β(j = 1) β(j = 2) β(j = 3) β(i = 1) t t + 1 i = 1 i = 2 i = 3 j = 1 j = 2 j = 3 a11 a12 a13 Figure A.5 – Représentation du calcul pour l’état βt(i = 1) par l’algorithme Backward pour un modèle à trois états. Algorithme de Viterbi L’algorithme de Viterbi, à la différence de l’algorithme Forward-Backward, fournit le « chemin » le plus probable, c’est-à-dire la meilleure séquence d’état (q1, q2, . . . , qT ), sachant les observations et le modèle. Pour résoudre ce problème, il est nécessaire de passer par le calcul de δ défini par : δt(i) = max q1,q2,...,qt−1 P[q1q2 . . . qt−1, qt = i, o1o2 . . . ot |λ]. A travers le δt(i), cet algorithme calcule pour chaque état caché du modèle, le chemin le plus probable atteignant l’état i au temps t. Pour mémoriser le chemin, l’état qui maximise les probabilités à chaque pas de temps sera conservé à travers la variable ψ. Au temps t = 1, l’initialisation est définie par : δ1(i) = πibi(o1), pour 1 ≤ i ≤ N ψ1(i) = 0. Pour l’induction allant de t > 1 à t = T : δt(j) = max 1≤i≤N [δt−1(i)a(ij)] bj (ot), pour 2 ≤ t ≤ T, ψt(j) = arg max 1≤i≤N [δt−1(i)a(ij)] et pour 1 ≤ j ≤ N. ψt(j) est donc la mémorisation de l’état précédent (au temps t − 1) appartenant au meilleur chemin qui mène à l’état j au temps t. La figure A.6 représente le calcul de δ et de ψ pour l’état j au temps t, effectué par l’algorithme de Viterbi pour un modèle à trois états. Le rouge symbolise l’état et la transition atteignant l’état j qui a la plus grande probabilité. A l’implémentation, à chaque pas de temps et pour chaque état, il est nécessaire de normaliser : δ 0 t (j) = δt(j) PN j=1 δt(j) , pour 1 ≤ j ≤ N. Au dernier pas de temps, pour t = T, la plus grande probabilité entre tous les états est calculée : P ∗ = max 1≤i≤N [δT (i)], 153Annexe A. Modèle de Markov caché δ(i = 1) δ(i = 2) δ(i = 3) δ(j = 1) ψ(j = 1) t − 1 t i = 1 i = 2 i = 3 j = 1 j = 2 j = 3 a11 a21 a31 Figure A.6 – Représentation du calcul δt(j = 1) et ψt(j = 1) par l’algorithme de Viterbi pour un modèle à trois états. q ∗ T = arg max 1≤i≤N [δT (i)]. Une dernière étape est nécessaire, il s’agit d’une étape de rétro-propagation. En prenant la plus haute probabilité parmi les états du temps t = T, on retrace le meilleur chemin en remontant jusqu’au premier pas de temps : q ∗ t = ψt+1(q ∗ t+1), pour t = T − 1, T − 2, . . . , 1. La figure A.7 représente les différentes étapes effectuées par l’algorithme de Viterbi. A chaque étape de l’induction, l’algorithme se souvient de l’état le plus probable (rond rouge) et pour chaque état il se souvient de son prédécesseur le plus probable (transition rouge).Cette figure représente également la rétro-propagation à partir du dernier temps t = T sur 4 pas de temps. Le chemin le plus probable trouvé par l’algorithme de Viterbi, sur cette figure, est représenté en vert. Les chiffres correspondent aux différentes itérations de l’étape d’induction (en rouge) et de l’étape de rétro-propagation (en vert). Nous pouvons remarquer que le chemin le plus probable ne correspond pas forcément aux transitions des états les plus probables (représentées en rouge) définies par les calculs de l’induction. t = 1 T − 2 T − 1 T 1 2 3 3 2 1 Figure A.7 – Représentation du calcul de l’algorithme de Viterbi avec la rétro-propagation (en vert) pour quatre pas de temps successifs et trois états. 154A.2. Algorithmes d’apprentissage et d’inférence A.2.2 Apprentissage et inférence pour les systèmes de plusieurs MMC L’utilisation de MMC combiné permet de ne pas insérer de connaissance a priori. L’objectif est de générer un modèle appris en fonction des données qui lui sont fournies. La solution consiste à construire un modèle qui maximise la vraisemblance, c’est-à-dire la probabilité d’apparition d’une séquence d’observations O = (o1, o2, . . . , oT ). En d’autres termes, l’objectif est de trouver le modèle qui explique le mieux la séquence. Pour construire un modèle collant au plus près des données, il est nécessaire d’apprendre les paramètres du modèle qui sont les probabilités initiales, les probabilités de transition et les paramètres de la fonction d’observation (moyenne et covariance de chaque état). Pour estimer les paramètres, l’algorithme de Baum-Welch est utilisé. Cet algorithme présente le défaut de ne pas toujours converger vers la même solution. Apprentissage L’algorithme de Baum-Welch est un cas particulier de l’algorithme Espérance-Maximisation, qui sont les deux étapes à appliquer itérativement pour apprendre les paramètres du modèle. La première étape permet d’estimer la séquence d’états correspondant aux observations à partir du modèle courant. La seconde étape consiste à ré-estimer les paramètres du modèle pour augmenter sa vraisemblance. La base d’apprentissage est composée d’un ensemble d’exemples pour chaque état à modéliser. Espérance Cette première étape consiste à calculer pour chaque séquence, les probabilités a postériori. Cette étape est réalisée avec l’algorithme Forward-Backward décrit précédemment à la section A.2.1. Le résultat de cette étape est pour chaque séquence s de longueur Ts, composant les exemples de l’activité à modéliser, les valeurs α s t β s t et γ s t . Pour la première itération, les valeurs prises par le modèle sont des valeurs d’initialisation arbitraires. Pour les probabilités initiales de chaque état, nous les fixons à l’identique. Concernant la matrice de transition, toutes les probabilités sont fixées également de manière équivalente. Concernant les observations, la moyenne et la covariance, nécessaires pour former les gaussiennes multivariées de chaque état et chaque MMC, doivent être initialisées. Les moyennes pour la position du centre de masse, la vitesse, et la distribution verticale sont initialisées en prenant, de manière aléatoire, les valeurs d’une observation correspondant à une activité. A partir de ces moyennes tirées au hasard, la covariance est calculée pour chaque état. Pour les itérations suivantes, l’algorithme consiste à reprendre les paramètres estimés par l’étape de maximisation. Maximisation Dans cette étape, la moyenne et la covariance sont alors recalculées de façon à maximiser la vraisemblance, pour faire en sorte que le modèle soit plus proche de la réalité. En d’autres termes, l’ensemble des MMC est réévalué par rapport à la séquence d’observations sur laquelle nous voulons l’entraîner. L’estimation des paramètres est renouvelée jusqu’à ce qu’il y ait convergence. Réestimation de la matrice de transition Les probabilités de transition sont recalculées en comptant les transitions à partir des données obtenues à l’étape Espérance. L’équation suivante permet de calculer ξt(i, j), qui est la probabilité de transition entre les états i et j entre les instants 155Annexe A. Modèle de Markov caché t et t + 1. ξ s t (i, j) = α s t (i)aij bj (o s t+1)β s t+1(j) PN k=1 PN l=1 α s t (k)aklbl(o s t+1)β s t+1(l) où s est le numéro de la séquence dans la base d’apprentissage. La probabilité de transition entre i et j est ensuite obtenue en faisant la somme sur toutes les séquences des ξ s t (i, j) divisée par la somme des γ s t (i) qui représente la probabilité de se trouver dans l’état i : aij = PS s=1 PTs−1 t=1 ξ s t (i, j) PS s=1 PTs−1 t=1 γ s t (i) . Réestimation de la matrice des probabilités initiales La probabilité initiale est obtenue en regardant la probabilité des différents états en début de séquences dans les données de l’étape Espérance : πi = PS s=1 γ s 0 (i) S . Réestimation de la matrice des probabilités d’observations. Les moyennes et covariances des fonctions d’observations sont recalculées pour chaque état en prenant en compte à chaque instant la probabilité d’appartenir à l’état : µi = PS s=1 PTs t=1 γ s t (i)o s t PS s=1 PTs t=1 γ s t (i) , Σi = PS s=1 PTs t=1 γ s t (i)(o s t − µi)(o s t − µi) 0 PS s=1 PTs t=1 γ s t (i) . Inférence L’inférence est réalisée en calculant à chaque pas de temps la vraisemblance du modèle. L’état le plus probable est celui qui correspond au modèle donnant la plus grande vraisemblance. La vraisemblance L se calcule en reprenant les valeurs de l’étape Forward en fin de séquence : L = X N i=1 αT (i). Dans l’implémentation, il est habituel d’utiliser le logarithme de la vraisemblance qui permet de garder les valeurs dans un domaine représentable numériquement. Et comme les valeurs α ont été normalisées à chaque pas de temps, le logarithme de la vraisemblance se calcule en faisant la somme des logarithmes des coefficients de normalisation. 156Publications [1] Amandine Dubois and François Charpillet. A gait analysis method based on a depth camera for fall prevention. In 36th Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC). IEEE, 2014. [2] Amandine Dubois and François Charpillet. Detecting and preventing falls with depth camera, tracking the body center. In 12th European Association for the Advancement of Assistive Technology in Europe (AAATE), 2013. [3] Amandine Dubois and François Charpillet. Human activities recognition with RGB-Depth camera using HMM. In 35th Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC), pages 4666–4669. IEEE, 2013. [4] Amandine Dubois and François Charpillet. Automatic fall detection system with a RGB-D camera using a Hidden Markov Model. In 11th International Conference on Smart Homes and Health Telematics (ICOST), pages 259–266, 2013. [5] Amandine Dubois and François Charpillet. Système d’évaluation de la fragilité chez les personnes âgées. In Journée d’étude sur la TéléSanté (JETSAN). IEEE france, 2013. [6] Amandine Dubois and François Charpillet. Tracking mobile objects with several kinects using HMMs and component labelling. In Workshop Assistance and Service Robotics in a human environment, International Conference on Intelligent Robots and Systems (IROS). IEEE, 2012. [7] Amandine Dubois, Abdallah Dib, and François Charpillet. Using HMMs for discriminating mobile from static objects in a 3D occupancy grid. In 23rd International Conference on Tools with Artificial Intelligence (ICTAI), pages 170–176. IEEE, 2011. 157BIBLIOGRAPHIE 158Références [Aggarwal and Ryoo, 2011] J.K. Aggarwal and Michael S. Ryoo. Human activity analysis : A review. ACM Computing Surveys, 43(3), 2011. [Alexander et al., 1997] Neil B. Alexander, Jessica Ulbrich, Aarti Raheja, and Dwight Channer. Rising from the floor in older adults. Journal of the American Geriatrics Society, 45(5) :564– 569, 1997. [Allard and Blanchi, 1996] Paul Allard and Jean-Pierre Blanchi. Analyse du mouvement humain par la biomécanique. Décarie, 1996. [Anderson et al., 2006] Derek Anderson, James M. Keller, Marjorie Skubic, Xi Chen, and Zhihai He. Recognizing falls from silhouettes. In 28th Annual International Conference of the Engineering in Medicine and Biology Society, (EMBS), pages 6388–6391. IEEE, 2006. [Anderson et al., 2009] Derek Anderson, Robert H. Luke, James M. Keller, Marjorie Skubic, Marilyn Rantz, and Myra Aud. Linguistic summarization of video for fall detection using voxel person and fuzzy logic. Computer Vision and Image Understanding, 113(1) :80–89, 2009. [André et al., 2001] J.-M. André, J. Paysant, N. Martinet, J-M. Beis, and C. Beyaert. Georges Gilles de la Tourette, initiateur de l’enregistrement de la marche dans les maladies du système nerveux. Revue neurologique, 157(3) :293–296, 2001. [Auvinet et al., 2003] Bernard Auvinet, Gilles Berrut, Claude Touzard, Nadine Collet, Denis Chaleil, and Eric Barrey. Gait abnormalities in elderly fallers. Journal of Aging and Physical Activity, pages 40–52, 2003. [Auvinet et al., 2011b] Edouard Auvinet, Franck Multon, Alain Saint-Arnaud, Jacqueline Rousseau, and Jean Meunier. Fall detection with multiple cameras : An occlusion-resistant method based on 3-D silhouette vertical distribution. IEEE transactions on information technology in biomedicine : a publication of the IEEE EMBS, 15(2) :290–300, 2011. [Avidan, 2004] Shai Avidan. Support vector tracking. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 26(8) :1064–1072, 2004. [Bellotti and Sellen, 1993] Victoria Bellotti and Abigail Sellen. Design for privacy in ubiquitous computing environments. In Proceedings of the Third European Conference on ComputerSupported Cooperative Work (ECSCW), pages 77–92. Springer, 1993. [Bian et al., 2012] Zhen-Peng Bian, Lap-Pui Chau, and Nadia Magnenat-Thalmann. Fall detection based on skeleton extraction. In Proceedings of the 11th ACM SIGGRAPH International Conference on Virtual-Reality Continuum and its Applications in Industry, pages 91–94. ACM, 2012. [Blanpain and Chardon, 2010] Nathalie Blanpain and Olivier Chardon. Projections de population à l’horizon 2060. Un tiers de la population âgé de plus de 60 ans, INSEE. Octobre 2010. 159BIBLIOGRAPHIE [Bourke et al., 2007] A.K. Bourke, J.V. O’Brien, and G.M. Lyons. Evaluation of a thresholdbased tri-axial accelerometer fall detection algorithm. Gait & posture, 26(2) :194–199, 2007. [Bramell-Risberg et al., 2005] Eva Bramell-Risberg, G-B Jarnlo, Lennart Minthon, and Sölve Elmståhl. Lower gait speed in older women with dementia compared with controls. Dementia and geriatric cognitive disorders, 20(5) :298–305, January 2005. [Caine et al., 2005] Kelly E. Caine, Wendy A. Rogers, and Arthur D. Fisk. Privacy perceptions of an aware home with visual sensing devices. In Proceedings of the Human Factors and Ergonomics Society Annual Meeting, volume 49, pages 1856–1858. SAGE Publications, 2005. [Camicioli et al., 1998] R. Camicioli, D. Howieson, B. Oken, G. Sexton, and J. Kaye. Motor slowing precedes cognitive impairment in the oldest old. American Academy of Neurology, 50(5) :1496–1498, 1998. [Comaniciu, 2002] Dorin Comaniciu. Bayesian kernel tracking. In Pattern Recognition, pages 438–445. Springer, 2002. [Condouret et al., 1987] J. Condouret, M. Iehl, C. F. Roques, P. Dupui, F. Montoya, B. Pages, P. Bessou, and M. Pujol. Analyse spatio-temporelle de la marche par la technique de Bessou : résultats chez l’hémiplégique. In Annales de réadaptation et de médecine physique, volume 30, pages 267–278. Elsevier, 1987. [Deeb et al., 2012] Rada Deeb, Félix Lédée, Elodie Desserée, and Saida Bouakaz. Méthode robuste pour la détection de chute dans un environnement non-contrôlé. In Actes de la conférence RFIA, Reconnaissance des Formes et Intelligence Artificielle, 2012. [Demiris et al., 2009] George Demiris, Debra Parker Oliver, Jarod Giger, Marjorie Skubic, and Marilyn Rantz. Older adults’ privacy considerations for vision based recognition methods of eldercare applications. Technology and Health Care, 17(1) :41–48, 2009. [Enzweiler and Gavrila, 2009] Markus Enzweiler and Dariu M. Gavrila. Monocular pedestrian detection : Survey and experiments. Transactions on Pattern Analysis and Machine Intelligence, 31(12) :2179–2195, 2009. [Faivre, 2003] Arnaud Faivre. Conception et validation d’un nouvel outil d’analyse de la marche. PhD thesis, Université de Franche-Comté, 2003. [Ferri et al., 2006] Cleusa P. Ferri, Martin Prince, Carol Brayne, Henry Brodaty, Laura Fratiglioni, Mary Ganguli, Kathleen Hall, Kazuo Hasegawa, and Hugh Hendrie. Global prevalence of dementia : a Delphi consensus study. The Lancet Neurology, 2006. [Fried et al., 2001] Linda P. Fried, Catherine M. Tangen, Jeremy Walson, Anne B. Newman, Calvin Hirsch, John Gottdiener, Teresa Seeman, Tracy Russell, Willem J. Kop, Gregory Burke, and Mary Ann McBurnie. Frailty in older adults : Evidence for a phenotype. Journal of Gerontology Series A : Biological Sciences and Medical Sciences, 56(3) :146–156, 2001. [Fusco, 2008] Nicolas Fusco. Analyse, modélisation et simulation de la marche pathologique. PhD thesis, Université Rennes 2, 2008. [Gaxatte et al., 2011] C. Gaxatte, T. Nguyen, F. Chourabi, J. Salleron, V. Pardessus, I. Delabrière, A. Thévenon, and F. Puisieux. Fear of falling as seen in the multidisciplinary falls consultation. Annals of physical and rehabilitation medicine, 54(4) :248–258, 2011. [Gillet, 2004] Christophe Gillet. Analyse Biomécanique de la marche et proposition de classes de marcheurs -Application au portage de sacs à dos. PhD thesis, Université de Valenciennes et du Hainaut-Cambrésis, 2004. 160BIBLIOGRAPHIE [Gómez-Conde, 2011] Iván Gómez-Conde. Simple human gesture detection and recognition using a feature vector and a real-time histogram based algorithm. Journal of Signal and Information Processing, 02(04) :279–286, 2011. [Grewe and Kak, 1995] Lynne Grewe and Avinash C. Kak. Interactive learning of a multipleattribute hash table classifier for fast object recognition. Computer Vision and Image Understanding, 61(3) :387–416, 1995. [Guimaraes and Isaacs, 1980] R.M. Guimaraes and Bernard Isaacs. Characteristics of the gait in old people who fall. Disability & Rehabilitation, 2(4) :177–180, 1980. [Hageman and Blanke, 1986] Patricia A. Hageman and Daniel J. Blanke. Comparison of gait of young women and elderly women. Physical therapy, 66(9) :1382–1387, September 1986. [Hagler et al., 2010] Stuart Hagler, Daniel Austin, Tamara L. Hayes, Jeffrey Kaye, and Misha Pavel. Unobtrusive and ubiquitous in-home monitoring : A methodology for continuous assessment of gait velocity in elders. IEEE transactions on bio-medical engineering, 57(4) :813–820, April 2010. [Harris and Stephens, 1988] Chris Harris and Mike Stephens. A combined corner and edge detector. In 4th Alvey Vision Conference, volume 15, pages 147–151. Manchester, UK, 1988. [Hausdorff et al., 2001] Jeffrey M. Hausdorff, Dean A. Rios, and Helen K. Edelberg. Gait variability and fall risk in community-living older adults : A 1-year prospective study. Archives of physical medicine and rehabilitation, 82(8) :1050–1056, August 2001. [Hewson et al., 2007] David J. Hewson, Jacques Duchêne, François Charpillet, Jamal Saboune, Valérie Michel-Pellegrino, Hassan Amoud, Michel Doussot, Jean Paysant, Anne Boyer, and Jean-Yves Hogrel. The PARAchute project : remote monitoring of posture and gait for fall prevention. EURASIP Journal on Advances in Signal Processing, 2007. [Holtzer et al., 2006] Roee Holtzer, Joe Verghese, Xiaonan Xue, and Richard B. Lipton. Cognitive processes related to gait velocity : Results from the einstein aging study. Neuropsychology, 20(2) :215–223, March 2006. [Jansen et al., 2007] Bart Jansen, Frederik Temmermans, and Rudi Deklerck. 3D human pose recognition for home monitoring of elderly. In 29th Annual International Conference of the Engineering in Medicine and Biology Society (EMBS), pages 4049–4051. IEEE, January 2007. [Jepson et al., 2003] Allan D. Jepson, David J. Fleet, and Thomas F. El-Maraghi. Robust online appearance models for visual tracking. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 25(10) :1296–1311, 2003. [Ke et al., 2013] Shian-Ru Ke, Hoang Le Uyen Thuc, Yong-Jin Lee, Jenq-Neng Hwang, Jang-Hee Yoo, and Kyoung-Ho Choi. A review on video-based human activity recognition. Computers, 2(2) :88–131, 2013. [Kirtley, 2006] Christopher Kirtley. Clinical Gait Analysis : Theory and practice. Elsevier Health Sciences, 2006. [Kuo et al., 2007] Hsu-Ko. Kuo, Suzanne G. Leveille, Yau-Hua Yu, and William P. Milberg. Cognitive function, habitual gait speed, and late-life disability in the national health and nutrition examination survey (NHANES) 1999-2002. Gerontology, 53(15) :102–110, 2007. [Lowe, 2004] David G. Lowe. Distinctive image features from scale-invariant keypoints. International Journal of Computer Vision, 60(2) :91–110, 2004. [Marey, 1894] Etienne-Jules Marey. Le mouvement. Masson, 1894. 161BIBLIOGRAPHIE [Martin et al., 2004] David R. Martin, Charless C. Fowlkes, and Jitendra Malik. Learning to detect natural image boundaries using local brightness, color, and texture cues. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 26(5) :530–549, 2004. [Melenhorst et al., 2004] Anne-Sophie Melenhorst, Arthur D. Fisk, Elizabeth D. Mynatt, and Wendy A. Rogers. Potential intrusiveness of aware home technology : Perceptions of older adults. In Proceedings of the Human Factors and Ergonomics Society Annual Meeting, volume 48, pages 266–270. SAGE Publications, 2004. [Moravec, 1979] Hans P. Moravec. Visual mapping by a robot rover. In Proceedings of the 6th International Joint Conference on Artificial Intelligence-Volume 1, pages 598–600. Morgan Kaufmann Publishers Inc., 1979. [Nait-Charif and McKenna, 2004] H. Nait-Charif and S.J. McKenna. Activity summarisation and fall detection in a supportive home environment. In 17th International Conference on Pattern Recognition (ICPR), volume 4, pages 323–326. IEEE, 2004. [Noury et al., 2007] Norbert Noury, Anthony Fleury, Pierre Rumeau, A.K. Bourke, G.O. Laighin, Vincent Rialle, and J.E. Lundy. Fall detection-principles and methods. In Engineering in Medicine and Biology Society (EMBS), 29th Annual International Conference of the IEEE, pages 1663–1666. IEEE, 2007. [Papageorgiou et al., 1998] Constantine P. Papageorgiou, Michael Oren, and Tomaso Poggio. A general framework for object detection. In International conference on Computer Vision, 1998, pages 555–562. IEEE, 1998. [Pepin et al., 2009] Nicolas Pepin, Olivier Simonin, and François Charpillet. Intelligent tiles : Putting situated multi-agents models in real world. In International Conference on Agents and Artificial Intelligence (ICAART’09), pages 513–519, 2009. [Perry and Davids, 1992] Jacquelin Perry and Jon R. Davids. Gait analysis : Normal and pathological function. Journal of Pediatric Orthopaedics, 12(6) :815, 1992. [Peursum et al., 2005] Patrick Peursum, Hung H. Bui, Svetha Venkatesh, and Geoff West. Robust recognition and segmentation of human actions using HMMs with missing observations. EURASIP Journal on Applied Signal Processing, 2005(13) :2110–2126, 2005. [Rabiner, 1989] Lawrence Rabiner. A tutorial on hidden Markov models and selected applications in speech recognition. In Proceedings of the IEEE, pages 257–286, 1989. [Rangarajan and Shah, 1991] Krishnan Rangarajan and Mubarak Shah. Establishing motion correspondence. Conference Vision Graphies Image Process, 54(1) :56–73, 1991. [Rimmer et al., 2005] E. Rimmer, M. Wojciechowska, C. Stave, A. Sganga, and B. O’Connell. Implications of the facing dementia survey for the general population, patients and caregivers across europe. International Journal of Clinical Practice, 1(146) :17–24, March 2005. [Rimminen et al., 2009] Henry Rimminen, Juha Lindström, and Raimo Sepponen. Positioning accuracy and multi-target separation with a human tracking system using near field imaging. International Journal on Smart Sensing and Intelligent System, 2(1) :156–175, 2009. [Rimminen et al., 2010] Henry Rimminen, Juha Lindström, Matti Linnavuo, and Raimo Sepponen. Detection of falls among the elderly by a floor sensor using the electric near field. IEEE transactions on information technology in biomedicine : a publication of the IEEE Engineering in Medicine and Biology Society, 14(6) :1475–1476, November 2010. [Rose et al., 2008] Cédric Rose, Jamal Saboune, and François Charpillet. Reducing particle filtering complexity for 3D motion capture using dynamic bayesian networks. In Twenty-Third AAAI Conference on Artificial Intelligence, pages 1396–1401, 2008. 162BIBLIOGRAPHIE [Rougier and Meunier, 2010] Caroline Rougier and Jean Meunier. 3D head trajectory using a single camera. In Image and Signal Processing, pages 505–512. Springer, 2010. [Rougier et al., 2011] Caroline Rougier, Edouard Auvinet, Jacqueline Rousseau, Max Mignotte, and Jean Meunier. Fall detection from depth map video sequences. International Conference on Smart Homes and Health Telematics (ICOST), pages 121–128, 2011. [Rowley et al., 1998] Henry A. Rowley, Shumeet Baluja, and Takeo Kanade. Neural networkbased face detection. Pattern Analysis and Machine Intelligence, 20(1) :23–38, 1998. [Russell and Norvig, 2010] Stuart Jonathan Russell and Peter Norvig. Intelligence artificielle. Pearson Education France, 2010. [Saboune and Charpillet, 2005] Jamal Saboune and Francois Charpillet. Using interval particle filtering for marker less 3D human motion capture. In 17th IEEE International Conference on Tools with Artificial Intelligence (ICTAI’05). IEEE, 2005. [Saunders et al., 1953] M. Saunders, Verne T. Inman, and Howard D. Eberhart. The major determinants in normal and pathological gait. The Journal of Bone & Joint Surgery, pages 543–558, July 1953. [Sethi and Jain, 1987] Ishwar K. Sethi and Ramesh Jain. Finding trajectories of feature points in a monocular image sequence. Pattern Analysis and Machine Intelligence, IEEE Transactions on, (1) :56–73, 1987. [Shaw, 2002] Fiona E. Shaw. Falls in cognitive impairment and dementia. Clinics Geriatric Medicine, pages 18 :159–280, 2002. [Shi and Malik, 2000] Jianbo Shi and Jitendra Malik. Normalized cuts and image segmentation. Pattern Analysis and Machine Intelligence, 22(8) :888–905, 2000. [Shotton et al., 2013] Jamie Shotton, Toby Sharp, Alex Kipman, Andrew Fitzgibbon, Mark Finocchio, Andrew Blake, Mat Cook, and Richard Moore. Real-time human pose recognition in parts from single depth images. Communications of the ACM, 56(1) :116–124, 2013. [Silva et al., 2002] Mauricio Silva, Eric F. Shepherd, Walter O. Jackson, Frederick J. Dorey, and Thomas P. Schmalzried. Average patient walking activity approaches 2 million cycles per year : pedometers under-record walking activity. The Journal of Arthroplasty, 17(6) :693–697, 2002. [Stauffer and Grimson, 2000] Chris Stauffer and W. Eric L. Grimson. Learning patterns of activity using real-time tracking. Pattern Analysis and Machine Intelligence, 22(8) :747–757, 2000. [Studenski et al., 2003] Stephanie Studenski, Subashan Perera, Dennis Wallace, Julie M. Chandler, Pamela W. Duncan, Earl Rooney, Michael Fox, and Jack M. Guralnik. Physical performance measures in the clinical setting. Journal of the American Geriatrics Society, 51(3) :314– 322, March 2003. [Suzuki et al., 2003] Kenji Suzuki, Isao Horiba, and Noboru Sugie. Linear-time connectedcomponent labeling based on sequential local operations. Computer Vision and Image Understanding, 89(1) :1–23, January 2003. [Thomesse et al., 2001] Jean-Pierre Thomesse, David Bellot, Anne Boyer, Eric Campo, Marie Chan, François Charpillet, Jocelyne Fayn, Claire Leschi, Norbert Noury, Vincent Rialle, Laurent Romary, Paul Rubel, Nazha Selmaoui, François Steenkeste, and Gilles Virone. Integrated information technologies for patients remote follow-up and homecare. 3rd International Workshop on Enterprise Networking and Computing in Health Care Industry (HealthCom), 2001. 163BIBLIOGRAPHIE [Tieu and Viola, 2004] Kinh Tieu and Paul Viola. Boosting image retrieval. International Journal of Computer Vision, 56(1-2) :17–36, 2004. [Tinetti et al., 1993] Mary E. Tinetti, Wen-Liang Liu, and Elizabeth B. Claus. Predictors and prognosis of inability to get up after falls among elderly persons. Journal of the American Medical Association (Jama), 269(1) :65–70, 1993. [Turaga et al., 2008] Pavan Turaga, Rama Chellappa, Venkatramana S. Subrahmanian, and Octavian Udrea. Machine recognition of human activities : A survey. IEEE Transactions on Circuits and Systems for Video Technology, 18(11) :1473–1488, 2008. [Valera and Velastin, 2005] M. Valera and Sergio A. Velastin. Intelligent distributed surveillance systems : a review. In Vision, Image and Signal Processing, IEE Proceedings-, volume 152, pages 192–204. IET, 2005. [Van Iersel et al., 2004] M.B. Van Iersel, W. Hoefsloot, M. Munneke, B.R. Bloem, and M.G.M. Olde Rikkert. Systematic review of quantitative clinical gait analysis in patients with dementia. Zeitschrift für Gerontologie und Geriatrie, 37(1) :27–32, February 2004. [Veenman et al., 2001] Cor J. Veenman, Marcel J.T. Reinders, and Eric Backer. Resolving motion correspondence for densely moving points. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 23(1) :54–72, 2001. [Viel, 2000] Eric Viel. La marche humaine, la course et le saut. Biomécanique, explorations, normes et dysfonctionnements. Elsevier Masson, Paris, 2000. [Viola et al., 2003] Paul Viola, Michael J. Jones, and Daniel Snow. Detecting pedestrians using patterns of motion and appearance. In Proceedings of the International Conference on Computer Vision, pages 734–741. IEEE, 2003. [Waite et al., 2005] L.M. Waite, D.A Grayson, O. Piguet, H. Creasey, H.P. Bennett, and G.A. Broe. Gait slowing as a predictor of incident dementia : 6-year longitudinal data from the sydney older persons study. Journal of the Neurological Sciences, 229-230 :89–93, March 2005. [Webe, 2006] Amandine Webe. Dépendance des personnes âgées et handicap : les opinions des Français entre 2000 et 2005. DREES Études et résultats, mai 2006. [Wild et al., 1981] D. Wild, U.S. Nayak, and B. Isaacs. How dangerous are falls in old people at home ? British Medical Journal (Clinical research ed.), 282(6260) :266, 1981. [Winter et al., 1990] David A. Winter, Aftab E. Patla, James S. Frank, and Sharon E. Walt. Biomechanical walking pattern changes in the fit and healthy elderly. Physical therapy, 70(6) :340– 347, June 1990. [Wu, 2000] Ge Wu. Distinguishing fall activities from normal activities by velocity characteristics. Journal of Biomechanics, 33(11) :1497–1500, 2000. [Yilmaz et al., 2006] Alper Yilmaz, Omar Javed, and Mubarak Shah. Object tracking : A survey. ACM Computing Surveys, 38(4) :13, dec 2006. 164Résumé Le vieillissement de la population est un enjeu majeur pour les prochaines années en raison, notamment, de l’augmentation du nombre de personnes dépendantes. La question du maintien à domicile de ces personnes se pose alors, du fait de l’impossibilité pour les instituts spécialisés de les accueillir toutes et, surtout, de la volonté des personnes âgées de rester chez elles le plus longtemps possible. Or, le développement de systèmes technologiques peut aider à résoudre certains problèmes comme celui de la sécurisation en détectant les chutes, et de l’évaluation du degré d’autonomie pour prévenir les accidents. Plus particulièrement, nous nous intéressons au développement des systèmes ambiants, peu coûteux, pour l’équipement du domicile. Les caméras de profondeur permettent d’analyser en temps réel les déplacements de la personne. Nous montrons dans cette thèse qu’il est possible de reconnaître l’activité de la personne et de mesurer des paramètres de sa marche à partir de l’analyse de caractéristiques simples extraites des images de profondeur. La reconnaissance d’activité est réalisée à partir des modèles de Markov cachés, et permet en particulier de détecter les chutes et des activités à risque. Lorsque la personne marche, l’analyse de la trajectoire du centre de masse nous permet de mesurer les paramètres spatio-temporels pertinents pour l’évaluation de la fragilité de la personne. Ce travail a été réalisé sur la base d’expérimentations menées en laboratoire, d’une part, pour la construction des modèles par apprentissage automatique et, d’autre part, pour évaluer la validité des résultats. Les expérimentations ont montré que certains modèles de Markov cachés, développés pour ce travail, sont assez robustes pour classifier les différentes activités. Nous donnons, également dans cette thèse, la précision, obtenue avec notre système, des paramètres de la marche en comparaison avec un tapis actimètrique. Nous pensons qu’un tel système pourrait facilement être installé au domicile de personnes âgées, car il repose sur un traitement local des images. Il fournit, au quotidien, des informations sur l’analyse de l’activité et sur l’évolution des paramètres de la marche qui sont utiles pour sécuriser et évaluer le degré de fragilité de la personne. Mots-clés: Caméra de profondeur, Modèle de Markov caché, Reconnaissance d’activité, Analyse de la marche. Abstract Population ageing is a major issue for society in the next years, especially because of the increase of dependent people. The limits in specialized institutes capacity and the wish of the elderly to stay at home as long as possible explain a growing need for new specific at home services. Technologies can help securing the person at home by detecting falls. They can also help in the evaluation of the frailty for preventing future accidents. This work concerns the development of low cost ambient systems for helping the stay at home of elderly. Depth cameras allow analysing in real time the displacement of the person. We show that it is possible to recognize the activity of the person and to measure gait parameters from the analysis of simple feature extracted from depth images. Activity recognition is based on Hidden Markov Models and allows detecting at risk behaviours and falls. When the person is walking, the analysis of the trajectory of her centre of mass allows measuring gait parameters that can be used for frailty evaluation. This work is based on laboratory experimentations for the acquisition of data used for models training and for the evaluation of the results. We show that some of the developed Hidden Markov Models are robust enough for classifying the activities. We also evaluate de precision of the gait parameters measurement in comparison to the measures provided by an actimetric carpet. We believe that such a system could be installed in the home of the elderly because it relies on a local processing of the depth images. It would be able to provide daily information on the person activity and on the evolution of her gait parameters that are useful for securing her and evaluating her frailty. Keywords: Depth camera, Hidden Markov Model, Activity recognition, Gait analysis. Intégration de l’inférence abductive et inductive pour la repr´esentation des connaissances dans les r´eseaux de g`enes Tan Le To cite this version: Tan Le. Int´egration de l’inf´erence abductive et inductive pour la repr´esentation des connaissances dans les r´eseaux de g`enes. Automatic Control Engineering. Universit´e Paul Sabatier - Toulouse III, 2014. French. HAL Id: tel-00996894 https://tel.archives-ouvertes.fr/tel-00996894 Submitted on 27 May 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es. THÈSE En vue de l’obtention du DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE Dévilré par l’Université Toulouse III – Paul Sabatier Discipline ou spécialité : Systèmes informatiques Présentée et soutenue par LE Tan Le 28 Avril 2014 Titre : Intégration de l’inférence abductive et inductive pour la représentation des connaissances dans les réseaux de gènes JURY Gilles RICHARD Président du jury Professeur, Université Toulouse III Jacques DEMONGEOT Rapporteur Professeur, Université Joseph Fourier, Grenoble Yves LACROIX Rapporteur Professeur, Université de Toulon Jean-Charles FAYE Examinateur Directeur de Recherche INSERM, Toulouse Belaid BENHAMOU Examinateur Maître de conférences, Université de Provence, Marseille Vincent RISCH Examinateur Maître de conférences, Université de Provence, Marseille Andrei DONCESCU Directeurs de thèse Maître de conférences, Université Toulouse III Pierre SIEGEL Co-directeurs de thèse Professeur, Université de Provence, Marseille Ecole doctorale : EDSYS Unité de recherche : LAAS-CNRS Directeur(s) de Thèse : Andrei DONCESCU et Pierre SIEGEL Rapporteurs : Jacques DEMONGEOT et Yves LACROIX A ceux qui m’aiment, A ceux que j’aime, A mes filles Hanh Quynh et Hanh Quyen, je vous aime !!! i Résumé Le raisonnement diagnostique (abductif) et le raisonnement de prédiction (inductif) sont deux des méthodes de raisonnement qui permettent la découverte de connaissances nouvelles. Lorsque le raisonnement abductif est le processus permettant de trouver la meilleure explication (hypothèse) pour un ensemble d’observations (Josephson, 1994), le raisonnement de prédiction est le processus, à partir d’un ensemble d’observations, permettant de trouver tous les résultats possibles. Ces observations peuvent être les symptômes d’un patient, des expériences concernant les réseaux métaboliques et génomiques, etc. Dans cette thèse, nous nous sommes intéressés à la représentation, l’analyse et la synthèse des réseaux de signalisation génomique en utilisant la logique des hypothèses. En fait, ce mémoire se focalise sur la modélisation des voies de signalisation en réponse à la cassure double-brin de l’ADN. Pour implémenter l’abduction nous utilisons les algorithmes de production. Ensuite, la logique des défauts permet de construire des modèles de représentation minimale. Ces algorithmes de découvertes de connaissances sont prouvés sur la carte de cassure double brin de l’ADN. Cette carte est minimale en tant que graphe de causalité biologique et elle permet d’intégrer les données biomoléculaires. Mots clés : conclusion conséquente, abduction, champ de production, logique des défauts, raisonnement diagnostique, raisonnement de prédiction, cassure double-brin de l’ADN, voie de signalisation, voie métabolique, représentation, modélisation, connaissances biologiques. iii Abstract Diagnostic reasoning (abductive) and predictive reasoning (inductive) are two methods of reasoning that enable the discovery of new knowledge. When abductive reasoning is the process of finding the best explanation (hypothesis) for a set of observations (Josephson, 1994), the inductive reasoning is the process of predicting, from a set of observations, to find all possible results. These observations may be symptoms of a patient, experiments on genomic and metabolic networks, etc. In this PhD thesis, we are interested in the representation, analysis and synthesis of genomic signaling networks using hypothetical logic. In fact, this thesis focuses on modeling of signaling pathways in response to the DNA double stranded break. To implement the abduction, we use algorithms of production. Then, the default logic is used to build models of minimum representation. These algorithms are proven knowledge discovery on the map of DNA double-strand break. This map is minimal as biological causality graph and allows integrating bio-molecular data. Keywords: consistent conclusion, abduction, field of production, default logic, diagnostic reasoning, predictive reasoning, double-stranded break DNA, signaling pathway, metabolic pathway, representation, modeling, biological knowledge. v Remerciements Le travail présenté dans ce rapport a été réalisé au sein du groupe Diagnostic, Supervision et Conduite (DISCO), du Laboratoire d’Analyse et d’Architecture et des Systèmes (LAAS) du Centre National de la Recherche Scientifique (CNRS). Il a été effectué grâce au support financier du gouvernement vietnamien, et également du LAAS – CNRS, avec le support de la vie du Centre Régional des œuvres Universitaires et Scolaires (CROUS) de Toulouse. Je tiens, en premier lieu, à adresser mes plus sincères remerciements et ma plus profonde reconnaissance à Monsieur Andrei DONCESCU et Monsieur Pierre SIEGEL, pour avoir bien voulu être mes directeurs de thèse, pour leur soutien et pour leur direction souple et sécurisante tout au long de ce travail. Je souhaite exprimer ma plus profonde gratitude à Monsieur Jean ARLAT, Directeur du LAAS – CNRS, pour m’avoir accueilli au sein de laboratoire. Je tiens à exprimer ma sincère gratitude à Messieurs : Jean-Charles FAYE, Directeur de Recherche à l’Institut Claudius Regaud (ICR) Olivier SORDET, Rechercheur à l’Institut Claudius Regaud Barthélémy DWORKIN Henri BONNABAU pour leurs connaissances de la voie de réponse à la cassure double-brin de l'ADN. Finalement, je tiens également à remercier spécialement tous les amis français et vietnamiens que je côtoie pendant mon séjour en France. vii Table des matières Résumé.................................................................................................................................................i Abstract..............................................................................................................................................iii Remerciements.................................................................................................................................... v Table des matières.............................................................................................................................vii Liste des figures...................................................................................................................................ix Liste des tableaux................................................................................................................................xi Introduction......................................................................................................................................... 1 Chapitre 1. Contexte et cas d’application.......................................................................................... 5 1.1. Contexte ........................................................................................................................... 5 1.1.1. Connaissances biologiques ...................................................................................... 5 1.1.2. Inhibiteurs de Chk2 comme nouveaux agents anticancéreux................................. 27 1.1.3. Problématique ........................................................................................................27 1.1.4. Exigences................................................................................................................28 1.2. Cas d’application............................................................................................................28 1.2.1. Contexte des gènes et leurs interactions ................................................................28 1.2.2. Définitions..............................................................................................................31 1.2.3. Règles de comportements.......................................................................................34 Chapitre 2. Conclusion conséquente et la production......................................................................35 2.1. Conclusion conséquente et SOL.....................................................................................35 2.1.1. Conclusion conséquente .........................................................................................35 2.1.2. SOL.........................................................................................................................35 2.2. Production pour l’abduction et l’induction.....................................................................41 2.2.1. Définition................................................................................................................41 2.2.2. Exemple d’utilisation..............................................................................................41 2.3. Champ de production .....................................................................................................42 2.3.1. Définition................................................................................................................42 2.3.2. Exemple d’utilisation..............................................................................................44 2.4. Algorithmes de calcul de production..............................................................................45 2.4.1. Description simplifiée.............................................................................................45 2.4.2. Algorithme avec coupure........................................................................................49 2.4.3. Algorithme en Prolog .............................................................................................52 Chapitre 3. La logique des défauts..................................................................................................55 3.1. Introduction ....................................................................................................................55viii Table des matières 3.2. Notion de défaut.............................................................................................................55 3.3. Syntaxe de la logique des défauts...................................................................................57 3.4. Extensions. .....................................................................................................................58 3.4.1. Extensions - définition formelle..............................................................................58 Chapitre 4. Approche proposée et résultats....................................................................................63 4.1. Utilisation de l’algorithme de production de clauses. ....................................................63 4.2. Utilisation de la logique des défauts...............................................................................70 4.2.1. Dans le cas général ................................................................................................70 4.2.2. Utilisation dans le domaine temporel discret.........................................................77 Conclusion .........................................................................................................................................93 Bibliographie......................................................................................................................................95Liste des figures ix Liste des figures Figure 1.1. Structure d’une cellule animale eucaryote typique .............................................................. 6 Figure 1.2. Structure des nucléotides ..................................................................................................... 7 Figure 1.3. Structure des 22 acides aminés ............................................................................................ 8 Figure 1.4. Mécanismes intracellulaires de régulation de l’apoptose................................................... 12 Figure 1.5. Les étapes du cycle cellulaire : la mitose ........................................................................... 13 Figure 1.6. Les étapes du cycle cellulaire : la méiose .......................................................................... 14 Figure 1.7. Division des chromosomes dans un noyau cellulaire......................................................... 15 Figure 1.8. Les quatre phases du cycle cellulaire avec des chromosomes dans le noyau .................... 15 Figure 1.9. Cycle cellulaire avec des points de contrôle ...................................................................... 16 Figure 1.10. Molécules régulant intervenant dans le cycle cellulaire chez les mammifères................ 18 Figure 1.11. Composants de la voie de signalisation p53 .................................................................... 23 Figure 1.12. Définitions des symboles et des conventions de la carte ................................................. 28 Figure 1.13. La carte d'interaction de la réponse ATM-dépendante de la cassure double-brin............ 29 Figure 2.1 Tableaux résolus pour l’Exemple 2.1.................................................................................. 39 Figure 2.2. La procédure conséquente de recensement SOL................................................................ 40 Figure 2.3. Les étapes d’une production............................................................................................... 42 Figure 3.1. Arbre de recherche des solutions pour le calcul d'extensions............................................ 60 Figure 4.1. Interactions de la carte de Pommier................................................................................... 64 Figure 4.2. Un exemple d’interactions dans une cellule....................................................................... 70 Figure 4.3. Système équilibré de masse ............................................................................................... 77 Figure 4.4. La première relation entre les états de réaction et les changements de concentration de métabolites ............................................................................................................................................ 79 Figure 4.5. La deuxième relation entre les états de réaction et les changements de concentration de métabolites ............................................................................................................................................ 79 Figure 4.6. La troisième relation entre les états de réaction et les changements de concentration de métabolites ............................................................................................................................................ 79 Figure 4.7. Une extension de la carte de Pommier............................................................................... 92 Liste des tableaux xi Liste des tableaux Tableau 1.1. Les codes des 22 acides aminés......................................................................................... 9 Introduction 1 Introduction Une fonction biologique n’est pratiquement jamais le produit d’une seule macromolécule mais plutôt le résultat de l’interaction d’un groupe de macromolécules (gènes, protéines). Comprendre les mécanismes complexes à l’œuvre dans la cellule requiert donc une approche intégrative de la modélisation de toutes les interactions entre les macromolécules. Modéliser, identifier et éventuellement simuler les réseaux d’interactions entre macromolécules qui interviennent à différents niveaux dans la cellule forment les enjeux principaux d’une nouvelle discipline transversale qu’on appelle biologie de systèmes. Les systèmes biologiques changent sans cesse. La reconstruction de réseaux biologiques à partir de données expérimentales constitue un des éléments clefs des objectifs scientifiques en biologie moléculaire: le biologiste s’intéresse souvent à la réponse cellulaire d’un organisme ou d’un certain tissu dans un organe à un signal ou stress donné. Il cherche par exemple à définir ou à compléter le réseau de régulation impliqué dans le contrôle de cette réponse en exploitant des données expérimentales (données d’expression de gènes etc.). L’apprentissage automatique intervient alors comme une des composantes de l’activité de découverte scientifique : à partir des données, à partir d’une classe de modèles de réseaux de régulation, un algorithme d’apprentissage permet de définir une ou plusieurs solutions candidates (graphe d’interaction et paramètres des modèles) que le biologiste peut ensuite tester en générant d’autres expériences pour vérifier telle ou telle particularité du modèle. Pour cela, il est habituel de considérer qu’il y a deux modes de raisonnements, deux façons de progresser dans la connaissance : le raisonnement diagnostique, et le raisonnement de prédiction. Le raisonnement diagnostique (ou abductif) est une partie essentielle d’un grand nombre tâches du monde réel, par exemple le diagnostic médical, le débogage des programmes d’ordinateur, la découverte scientifique, etc. En règle générale, le raisonnement abductif est le processus permettant de trouver la meilleure explication pour un ensemble d’observations (Josephson, 1994). Ces observations peuvent être les symptômes d’un patient, les messages d’erreur d’un programme d’ordinateur, ou les résultats d’une expérience. La tâche de la résolution des problèmes dans chacun de ces domaines est de trouver un ensemble d’hypothèses élémentaires qui explique le mieux ces symptômes. Une autre méthode est tout aussi importante pour la représentation et le traitement des connaissances biologiques, c’est le raisonnement de prédiction par la logique des défauts. Quand un système intelligent essaye de résoudre un problème, il peut être en mesure de s’appuyer sur des informations complètes sur ce problème, et sa tâche principale est de tirer la bonne conclusion par un raisonnement classique. Dans ce cas, la logique des prédicats classique peut être suffisante. Cependant, dans de nombreuses situations, le système a seulement l’information incomplète, parce que certaines informations ne sont pas disponibles, ou bien parce qu’il doit répondre vite et n’a pas de temps de recueillir toutes les données pertinentes. La logique classique a en effet la capacité de représenter et raisonner avec certains aspects de 2 Introduction l’information incomplète. Mais il y a des occasions où l’information supplémentaire doit être remplie pour surmonter l’incomplétude, parce que certaines décisions doivent être prises. Dans ce cas, le système doit faire des conjectures plausibles, qui dans le cas du raisonnement par défaut sont basés sur des règles empiriques, appelé des défauts. Par exemple, un médecin d’urgence doit faire des conjectures sur les causes les plus probables des symptômes observés. Évidemment, il serait inapproprié d’attendre le résultat de tests éventuellement étendus et chronophages avant le début du traitement. Puisque les décisions sont fondées sur des hypothèses, elles peuvent se révéler fausses face à de nouvelles informations qui seront disponibles, à savoir les examens médicaux peuvent conduire à un diagnostic modifié. Le phénomène d’avoir à reprendre certaines conclusions précédentes est appelé non-monotonie, ça veut dire que si une déclaration X découle d’une série de prémisses M, et M est un sous-ensemble de N, X ne découle pas nécessairement de N. La logique des défauts, à l’origine présentée by Reiter [1980], fournit la méthode formelle pour soutenir ce genre de raisonnement. Elle est peut-être la méthode la plus importante pour le raisonnement non-monotone, essentiellement en raison de la simplicité de l’idée d’un défaut, et parce que les défauts prévalent dans de nombreux domaines d’application. Cependant, il existe plusieurs décisions de conceptions alternatives qui ont conduit à des variations de l’idée initiale. En fait, il y a une famille de méthodes de raisonnement par défauts qui partagent les mêmes fondements. Le travail présenté dans ce mémoire se focalise sur le raisonnement par l’abduction et par la logique des défauts pour la modélisation des voies de signalisation en réponse à la cassure double-brin de l’ADN. En fait, on a utilisé les algorithmes de production avec un champ de production pour faire le raisonnement diagnostique sur la carte d’interactions de Pommier. Ensuite, la logique des défauts a été utilisée pour faire le raisonnement de prédiction à partir de la carte. Toutefois, cette méthode ne nous permettait pas de connaitre l’ordre dans lequel se déroulaient les événements. Nous avons alors ajouté une variable temps à la logique des défauts ce qui nous a permis d’obtenir une chronologie des événements. Dans le processus de travail, on se rend compte que les algorithmes ne fonctionnent pas bien avec les variables lorsqu’ils sont implémentés en Prolog, alors on a cherché à résoudre ce problème et nous avons fourni des solutions. Introduction 3 Plan de la thèse Ce document s’organise en quatre chapitres suivants : Le chapitre 1 introduit le contexte applicatif considéré dans le cadre de la thèse, en examinant les notions de gènes, de protéines et de métabolites, ainsi que les règles de base de comportement d’une cellule. Le chapitre 2 présente les bases des outils mathématiques utilisés pour exécuter la synthèse des voies de signalisation. Ce chapitre se concentre sur la conclusion conséquence et la production. Le chapitre 3 détaille la logique des défauts, l’outil est utilisé pour représenter les interactions dans les réseaux de régulation. Le chapitre 4 propose une approche de représentation des connaissances – de la voie de signalisation cellulaire : utilisation de la production pour le raisonnement diagnostique ; et de la logique des défauts pour le raisonnement de prédiction. En conclusion, nous présentons un bilan du travail réalisé et des orientations pour développer le sujet. Contexte et cas d’application 5 Chapitre 1. Contexte et cas d’application Ce chapitre présente le contexte et le cas d’application de la thèse. Tout d’abord, il faut examiner les notions de gènes et leurs interactions dans les réseaux biologiques. 1.1. Contexte Comme nous le savons, la plupart des médicaments anticancéreux qui sont encore actuellement utilisés en clinique ciblent l’ADN. L’action de ces médicaments anticancéreux sur les tissus tumoraux est probablement due au fait qu’ils peuvent supprimer les défauts tumeur-spécifiques des points de contrôle (checkpoint en anglais) du cycle cellulaire et améliorer la réparation de l’ADN, afin d’augmenter la réponse apoptotique des cellules tumorales. Nous nous intéresserons ici à l’interaction moléculaire qui apparaît dans la voie ATM-Chk2. 1.1.1. Connaissances biologiques L’interaction moléculaire implique une liste de notions biologiques qui doivent être clarifiées. D’abord, nous étudierons la notion de cycle cellulaire. Le cycle cellulaire est l’ensemble des phases par lesquelles une cellule passe entre deux divisions successives. Le cycle des cellules eucaryotes est divisé en quatre phases : G1, S, G2 et M. L’ensemble des trois premières phases est souvent appelé l’interphase. Cellule : La cellule est une unité structurale et fonctionnelle de la plupart des organismes. Chaque organisme est structuré d’une ou plusieurs cellules. Des cellules ne sont produites qu’à partir des cellules précédentes. Toutes les fonctions vitales d’un organisme ont lieu dans la cellule. Les cellules contiennent des informations génétiques nécessaires pour diriger leurs fonctions et peuvent transmettre les matériaux génétiques aux générations suivantes. Caractères de la cellule : Chaque cellule est un système ouvert, autonome et autoproductif. La cellule peut recevoir des nutriments, les convertir en énergie, exercer des fonctions spéciales, et produire des nouvelles cellules s’il est nécessaire. Chaque cellule contient un cryptage distinct dirigeant ses actions et a les capacités suivantes : - Reproduction par la division. - Métabolisme cellulaire : Recevoir des matières brutes et les transformer en substances nécessaires pour la cellule, produire les molécules à haute énergie et les sous-produits. Pour exercer leurs fonctions, les cellules ont besoin d’absorber et d’utiliser l’énergie chimique contenue dans les molécules organiques. Cette énergie est libérée dans les voies métaboliques. - Faire la synthèse des protéines. Ce sont des molécules qui assument des fonctions fondamentales de la cellule, par exemple les enzymes. - Répondre aux stimuli ou aux changements d’environnement extérieur tels que les changements de température ou de pH ou des éléments nutritifs.6 Contexte et cas d’application - Déplacer des vésicules. Figure 1.1. Structure d’une cellule animale eucaryote typique (source : wikipedia.org) (1) Nucléole, (2) Noyau, (3) Ribosome, (4) Vésicule, (5) Réticulum endoplasmique rugueux (granuleux), (6) Appareil de Golgi, (7) Microtubule, (8) Réticulum endoplasmique lisse, (9) Mitochondrie, (10) Lysosome, (11) Cytoplasme, (12) Peroxysome, (13) Centrosome Composants d’une cellule : chaque cellule a une membrane plasmique pour l’envelopper, isoler l’intracellulaire de l’extérieur, contrôler strictement le transport des substances, maintenir le potentiel de membrane et la concentration des substances intérieures et extérieures. Chaque cellule contient des molécules d’ADN, matériels génétiques importants et des molécules d’ARN qui participent directement au processus de synthèse des protéines. À l’intérieur de la cellule, dans les temps donnés, la cellule synthétise une grande variété de molécules différentes. - Membrane plasmique : l’enveloppe d’une cellule a la fonction d’encapsulation et de distinction de cellule avec le milieu environnant. La membrane est formée par une double couche de lipides et de protéines. - Cytosquelette : un composant important compliqué et flexible. Il inclut un système de microtubules et de protéines et forme et maintient la forme de la cellule. - Cytoplasme : le cytoplasme désigne le contenu d’une cellule vivante. Il s’agit de la totalité du matériel cellulaire du protoplasme délimité par la membrane plasmique et des organites. - Matériel génétique : ce sont des molécules d’acides nucléides (ADN et ARN). L’information génétique de l’organisme est le code génétique qui prescrit toutes les protéines nécessaires pour toutes les cellules d’un organisme. - Organites : les cellules ont souvent des petits organes appelés des organites, adaptés et différenciés pour une ou plusieurs fonctions vitales. Les organites se trouvent souvent dans les cellules eucaryotes et souvent ont leurs propres membranes. Noyaux : les noyaux sont aussi entourés d’une membrane les isolant du cytoplasme et contiennent des acides nucléiques, ce sont des grandes molécules ayant la structure multimoléculaire, incluant plusieurs molécules de nucléotides. Il existe deux types d’acides nucléiques : l’acide désoxyribonucléique (ADN) et l’acide ribonucléique (ARN). L’ADN Contexte et cas d’application 7 contient l’information génétique lorsque l’ARN est la copie d’ADN, souvent en un seul brin alors que l’ADN a deux brins. Nucléotide : Un nucléotide est une molécule organique. Certains nucléotides forment la base de l’ADN et de l’ARN, d’autres sont des cofacteurs ou coenzymes. Chaque molécule nucléotidique consiste en trois composants, ce sont une base azotée, un sucre et un groupement phosphate (ou acide phosphorique). Figure 1.2. Structure des nucléotides (source : wikipedia.org) - Base azotée : Variable en fonction du type de nucléotide (purine ou pyrimidine) fixé à l’atome de carbone 1' du désoxyribose. Pour l’ADN, il existe quatre nucléotides différents correspondant aux quatre bases azotées différentes, ce sont l’adénine (A), la guanine (G), la cytosine (C), et la thymine (T). Dans l’ARN, la thymine (T) est remplacée par l’uracile (U). - Sucre : Pentose (ou désoxyribose), les acides nucléiques se différencient par la base qui est fixée sur le sucre. - Groupement phosphate (acide phosphorique) : Grâce à la liaison covalente entre l’acide phosphorique d’un nucléotide avec un sucre, des nucléotides se relient et forment une chaîne de poly-nucléotides. Cette liaison suit la règle complémentaire : une grande base est supplée par une petite base. Alors il existe deux types de liaison : le dAMP (adénine) avec le dTMP (thymine) en établissant deux liaisons hydrogènes (A-T), et le dCMP (cytosine) avec le dGMP (guanine) en établissant trois liaisons hydrogènes (G-C). Par exemple : si on a un brin A G G C T A C alors l’autre brin est T C C G A T G ADN : L’acide désoxyribonucléique (ADN) est une molécule, elle est présente dans toutes les cellules vivantes, renferme l'ensemble des informations nécessaires au développement et au fonctionnement d’un organisme. C’est aussi le support de l’hérédité car il est transmis lors de la reproduction, de manière intégrale ou non. Il porte l’information génétique et constitue le génome des êtres vivants. La structure standard de l’ADN est une double-hélice droite, composée de deux brins complémentaires. Chaque brin d’ADN est constitué d’un enchaînement de nucléotides. 8 Contexte et cas d’application La fonction de l’ADN est de préserver et de transmettre des informations sur la structure des tous les types de protéines d’un organisme, de sorte qu’elles définissent les caractères de l’organisme. L’information génétique (l’information de structure des protéines) est codée dans l’ADN. Chaque section (tranche) de molécule ADN qui porte l’information régulant la séquence d’une protéine est appelée gène de structure (cistron). Chaque acide aminé de la molécule de protéine est régulé par trois nucléotides successifs dans l’ADN (codon), c’est le code triplet. La succession de trois nucléotides correspondant à un acide aminé est appelé l’unité de code (codon). Il est facile de voir que le nombre de combinaisons des trois à partir des quatre types de nucléotides est 4 3 = 64. En fait, seulement 61 combinaisons sont utilisées pour coder 22 acides aminés. Il existe certains cas où un acide aminé correspond à plusieurs codons différents (dégénérescence du code génétique). D’autre part, il existe des codons qui ne régulent aucun acide aminé, ils ont juste la tâche de finir la synthèse de chaîne polypeptique. Ce sont UAA, UAG, et UGA. Figure 1.3. Structure des 22 acides aminés (source : wikipedia.org) Un caractère très important de l’ADN est la capacité de réplication (reproduction). Sous l’action d’enzymes, la double hélice de l’ADN est étirée, deux brins se détachent pas à pas. Chaque nucléotide dans chaque brin se combine avec un nucléotide libre suivant la règle (AT, G-C) pour former une nouvelle double hélice, donnant deux molécules enfants. Contexte et cas d’application 9 Tableau 1.1. Les codes des 22 acides aminés Code Abrév Acide aminé Nature Codons Y Tyr Tyrosine Polaire, aromatique UAU, UAC W Trp Tryptophane Apolaire, aromatique UGG (et UGA chez les mycoplasmes) V Val Valine Apolaire, aliphatique GUU, GUC, GUA, GUG U Sec Sélénocystéine Polaire UGA associé à un élément SECIS T Thr Thréonine Polaire ACU, ACC, ACA, ACG S Ser Sérine Polaire UCU, UCC, UCA, UCG, AGU, AGC R Arg Arginine Basique CGU, CGC, CGA, CGG, AGA, AGG Q Gln Glutamine Polaire CAA, CAG P Pro Proline Apolaire CCU, CCC, CCA, CCG O Pyl Pyrrolysine Polaire UAG associé à un élément PYLIS N Asn Asparagine Polaire AAU, AAC M Met Méthionine Apolaire AUG L Leu Leucine Apolaire, aliphatique UUA, UUG, CUU, CUC, CUA, CUG K Lys Lysine Basique AAA, AAG I Ile Isoleucine Apolaire, aliphatique AUU, AUC, AUA H His Histidine Basique, aromatique CAU, CAC G Gly Glycine Apolaire, aliphatique GGU, GGC, GGA, GGG F Phe Phénylalanine Apolaire, aromatique UUU, UUC E Glu Acide glutamique Acide GAA, GAG D Asp Acide aspartique Acide GAU, GAC C Cys Cystéine Polaire UGU, UGC A Ala Alanine Apolaire, aliphatique GCU, GCC, GCA, GCG ARN : l’acide ribonucléique (ARN) est une molécule biologique trouvée pratiquement dans tous les organismes vivants, y compris dans certains virus. L’ARN est une molécule très proche chimiquement de l’ADN. Selon sa fonction, l’ARN est divisée en trois types : ARN messager (ARNm), ARN de transfert (ARNt), et ARN ribosomique (ARNr). - ARNm : l’ARN messager est une chaîne poly nucléotidique copiant exactement un ou parfois plusieurs cistrons d’ADN, mais l’Uracile (U) remplace la Thymine (T). L’ARNm a la tâche de transmettre l’information génétique qui précise la séquence d’acides aminés de la protéine synthétisée. - ARNt : l’ARN de transfert a la tâche de transporter des acides aminés au lieu de synthèse des protéines (le ribosome). L’ARN de transfert a une structure caractéristique en feuille de trèfle, composée de quatre tiges appariées. L’une de ces tiges est terminée par une boucle qui contient l’anticodon, le triplet de nucléotides qui s’apparie au codon lors de la traduction d’un ARNm par le ribosome. À l’autre extrémité, l’ARNt porte l’acide aminé correspondant attaché par une liaison ester à son extrémité 3'-OH. Cette estérification est catalysée par des enzymes spécifiques, les aminoacyl-ARNt synthétases. - ARNr : L’ARN catalytique ou ribozyme constitue les composants du ribosome. 10 Contexte et cas d’application Chromosome : Un chromosome est un élément microscopique constitué de molécules d’ADN et de protéines. Chez les cellules eucaryotes, les chromosomes se trouvent dans le noyau où ils prennent la forme soit d’un bâtonnet, soit d’un écheveau, selon qu’ils sont condensés ou non. Chez les cellules procaryotes (sans noyau), le chromosome se trouve dans le cytoplasme. Le chromosome est l’élément porteur de l’information génétique. Les chromosomes contiennent les gènes et permettent leur distribution égale dans les deux cellules enfants lors de la division cellulaire. Ils sont formés d’une longue molécule d’ADN, associée à des protéines (notamment les histones). Entre deux divisions, la séparation entre les molécules d’ADN différentes (chromosomes) est peu perceptible, l’ensemble porte alors le nom de chromatine. Ils se condensent progressivement au cours de la division cellulaire pour prendre une apparence caractéristique en forme de X à deux bras courts et deux bras longs, reliés par un centromère. Au figuré, le mot chromosome est utilisé pour décrire son contenu en termes d’information génétique. Les chromosomes portent les gènes, supports de l’information génétique transmise des cellules mères aux cellules filles lors de la mitose ou de la méiose (reproduction sexuée). Les chromosomes sont habituellement représentés par paires, en parallèle avec leur homologue. Ils sont souvent illustrés sous leur forme condensée et dupliquée (en métaphase de la mitose). L’ensemble des chromosomes est représenté sur un caryotype, ou carte de chromosomes. Processus de synthèse des protéines : L’ADN régule la séquence des protéines par l’ARNm, donc la synthèse de protéine se compose de deux étapes principales : la transcription et la traduction. - Transcription : C’est le processus de synthèse de l’ARNm. La plupart de l’ARN est synthétisée sur le modèle de l’ADN. Sous l’action des enzymes ARN-polymérases, une section de molécule d’ADN correspondant à un ou plusieurs gènes est étirée, deux brins se détachent. Chaque nucléotide du brin d’origine est relié avec un ribonucléotide libre selon la règle (A-U, G-C), formant une chaîne polyribonucléotidique d’ARN. Après la synthèse, pour la cellule eucaryote, l’ARNm quitte le noyau vers le cytoplasme pour participer au processus de synthèse de protéine. - Traduction : Elle inclut deux étapes principales, activation d’acide aminé et synthèse de polypeptide. Lors de l’étape de synthèse de l’acide aminé, des acides aminés libres dans le cytoplasme sont activés par la liaison avec des composés riches en énergie adénosines triphosphates (ATP) par l’action de certains enzymes. Ensuite, grâce à d’autres enzymes spécifiques, l’acide aminé activé est lié avec l’ARNt correspondante pour former l’acide aminé – ARNt (aa-ARNt). Dans la synthèse du polypeptide, d’abord, l’ARNm se lie avec le ribosome à la place du codon de départ. Ensuite, l’ARNt porte le premier acide aminé vers le ribosome, son codon coïncide avec le code de départ de l’ARNm par la règle (A-U, G-C). aa1-ARNt arrive à la position suivante, son codon coïncide avec le codon du premier acide aminé d’ARNm. Par la Contexte et cas d’application 11 suite, la chaîne forme la structure de degré plus élevé pour former la protéine complète. Par exemple : brin origine ADN T A C G T A C G G A A T A A G brin d’ARNm A U G C A U G C C U U A U U C Décodage Méthionine Histidine Alanine Leucine Phénylalanine Mort cellulaire : La cellule ayant reçu un signal de son environnement va exprimer un programme qui entraîne sa mort (l’apoptose est un de ces mécanismes). Ce phénomène est nécessaire au développement des organismes pluricellulaires ; autant chez les végétaux (avec par exemple la mort des cellules formant le tube criblé), que chez les animaux (lors de la mise en place de la main chez l’homme : On a initialement une main palmée, la mort des cellules permet l’individualisation des doigts). Ce phénomène a aussi été découvert chez certaines bactéries (la mort cellulaire permet de limiter le nombre de bactéries lorsque les ressources sont insuffisantes). La cellule, tant pour les êtres pluricellulaires que pour les unicellulaires, constitue une structure vouée avant tout à permettre la reproduction de l’organisme et donc la transmission d’une structure de base contenant un programme génétique. Ainsi, certains auteurs ont été amenés à formuler la théorie du gène égoïste, considérant les organismes (et donc les cellules) comme de simples structures destinées à assurer la transmission et la prolifération des gènes (le gène proliférant est qualifié d’égoïste). La mort cellulaire peut se faire par nécrose, par autophagie, ou par apoptose. - Mort cellulaire par nécrose : La mort est causée par des dommages physiques ou chimiques. La nécrose est causée par des enzymes spéciales produites par les lysosomes, petites usines à enzymes de la cellule. La cassure de la membrane plasmique qui en résulte conduit à la libération dans le milieu extérieur du contenu cytoplasmique. La nécrose est accompagnée habituellement d’une réponse inflammatoire qui consiste en la présence d’exsudat et de cellules spécialisées du système hématopoïétique comme les lymphocytes et les macrophages. Une nécrose peut également être causée par une ischémie (plus ou moins) longue d’un membre. - Mort cellulaire par autophagie : La dégradation d’une partie du cytoplasme de la cellule par ses propres lysosomes. Le terme ‘autophagie’ (se manger soi-même) regroupe plusieurs voies de dégradation de lysosome des constituants cellulaires, essentielles à l’homéostasie cellulaire. Il existe trois types différents d’autophagies : la micro-autophagie, l’autophagie réalisée par des protéines chaperonnées, et la macroautophagie (c’est le type principal). - Mort cellulaire par apoptose : Ou mort cellulaire programmée, c’est un processus par lequel des cellules déclenchent leur auto-destruction en réponse à un signal. C’est l’une des voies de mort cellulaire, génétiquement programmée, nécessaire à la survie des organismes multicellulaires. Elle est en équilibre constant avec la prolifération cellulaire. Contrairement à la nécrose, l’apoptose ne provoque pas d’inflammation : les membranes plasmiques ne sont pas détruites, du moins dans un premier temps, et la cellule émet des signaux. 12 Contexte et cas d’application Figure 1.4. Mécanismes intracellulaires de régulation de l’apoptose (source : wikipedia.org) Reproduction cellulaire : Comme mentionné ci-dessus, une capacité importante de la cellule est la reproduction (réplication, ou bien duplication) par la division. Ceci est fait pendant un cycle appelé le cycle cellulaire (ou bien cycle de division cellulaire). Avant d’entrer en division cellulaire, une cellule doit accumuler des éléments nutritifs durant l’interphase. L’interphase procède en trois phases : G1, S, et G2. La division cellulaire fonctionne dans un cycle. La première phase dans l’interphase est la phase G1 (phase gap 1, ou post-mitotique phase), c’est une période principale de la croissance cellulaire. Au cours de cette phase, la biosynthèse, qui a été diminuée considérablement pendant la phase M précédente, recommence à haut taux. La cellule se prépare pour le processus de réplication de l’ADN. La cellule intègre les mitogènes, grossit et en fin de G1 la cellule peut se mettre en pause ou quitter le cycle cellulaire. Un point de contrôle important en G1 a été identifié pour toutes les cellules de levure et de mammifère. C’est le moment où la cellule va entrer dans la phase de réplication de l’ADN avant l’achèvement d’un cycle cellulaire. La phase suivante S commence quand la synthèse (réplication) de l’ADN commence. C’est une période au cours de laquelle le matériel chromosomique est doublé par réplication de l'ADN : duplication des chromosomes. Lorsque la phase est complète, tous les chromosomes ont été produits, c’est à dire chaque chromosome a deux chromatides enfants. Ainsi, au cours de la phase, la quantité d’ADN dans la cellule est effectivement doublée, quoique la ploïdie de la cellule ne change pas. Les vitesses de transcription et de synthèse protéiques sont très basses pendant cette phase.Contexte et cas d’application 13 Figure 1.5. Les étapes du cycle cellulaire : la mitose (source : wikipedia.org) Ensuite, la phase G2 est la seconde phase de croissance cellulaire, où la cellule se prépare à se diviser en deux cellules enfants. À l’issue de cette phase, chaque chromosome est parfaitement identique à son homologue sur le plan morphologique et du point de vue des gènes présents, mais chaque gène n’est pas nécessairement identique à son homologue (généralement plusieurs allèles existent).14 Contexte et cas d’application Figure 1.6. Les étapes du cycle cellulaire : la méiose (source : wikipedia.org) Enfin, c’est la phase M. La lettre M représente la mitose. La mitose est un processus dans lequel une cellule eucaryote sépare les chromosomes dans son noyau cellulaire en deux ensembles identiques dans deux noyaux. Il est généralement suivi immédiatement par la cytokinèse, qui divise le noyau, le cytoplasme, les organelles et la membrane cellulaire en deux cellules contenant des parts à peu près égales de ces composants cellulaires. L’ensemble de la mitose et la cytokinèse définissant la phase mitotique (phase M) du cycle cellulaire – la division de cellule parente en deux cellules enfantes, généralement identiques et ressemblent à leur parent. La phase M a été décomposée en plusieurs phases distinctes, successivement connues sous les noms prophase, métaphase, anaphase, télophase, et cytokinèse. Les erreurs dans une mitose peuvent tuer la cellule par l’apoptose ou causer la mutation qui peut mener au cancer.Contexte et cas d’application 15 Figure 1.7. Division des chromosomes dans un noyau cellulaire (source : wikipedia.org) Pendant le cycle cellulaire, il existe une phase supplémentaire G0. C’est une phase de repos où la cellule quitte le cycle et arrête de se diviser. Les cellules non-prolifératives dans les eucaryotes multicellulaires sont en phase G0 de G1 et peuvent rester tranquillement pour longtemps et peut être indéfiniment. La décrépitude de la cellule est un état qui a lieu en réponse au dommage de l’ADN ou à la dégradation de l’ADN qui peuvent faire un descendant cellulaire non-viable. Il est souvent une alternative biochimique à l’autodestruction par apoptose d’une telle cellule endommagée. Figure 1.8. Les quatre phases du cycle cellulaire avec des chromosomes dans le noyau (source : wikipedia.org) Point de contrôle : Un terme très important qui a été rappelé est le point de contrôle. Le point de contrôle est utilisé par la cellule pour contrôler et régler le processus de cycle cellulaire. Les points de contrôle bloquent le processus de cycle cellulaire aux points spécifiques, laissent la vérification de phase nécessaire se faire et permettent de réparer les dommages à l’ADN. En d’autres mots, le point de contrôle traite l’ensemble des signaux 16 Contexte et cas d’application régulateurs reçus par la cellule et décide si elle doit se diviser. La cellule n’a pas pu passer à la phase suivante jusqu’à ce que le point de contrôle ait été passé. Quelques points de contrôle sont désignés pour assurer que les ADN incomplets ou endommagés ne sont pas passés à la cellule enfante. Il existe deux points de contrôle principaux : le point G1/S et le point G2/M. La transition G1/S est un pas dans le cycle cellulaire et est aussi appelé le point de restriction (non-retour). Le point G1/S est le contrôle de l’état de l’ADN. Si c’est bon, il met en route la réplication par l’activation de facteurs inducteurs de la réplication. Par contre, le point G2/M est le contrôle de l’état de l’ADN répliqué et le contrôle de la duplication des centrosomes. Si c’est bon, il met en route la mitose par l’activation de facteurs mitotiques. Figure 1.9. Cycle cellulaire avec des points de contrôle (source : wikipedia.org) Bague extérieure : I – interphase, M – Mitose ; Bague intérieure : M – Mitose, G1 – Gap 1, G2 – Gap 2, S – Synthèse ; Pas dans les bagues : G0 – Gap 0/ Repos Lorsque l'ADN génomique des cellules eucaryotes est endommagé par des processus spontanés, mutagènes chimiques ou l'exposition au soleil, la réplication de l'ADN endommagé déclenche une réponse cellulaire appelée un point de contrôle post-réplication. Cette réponse empêche la progression du cycle cellulaire jusqu'à ce que les processus de la réparation postréplicative soient terminés et puissent contrôler l'activité de ces voies de réparation de l'ADN. Dans les types de cellules qui exécutent la phase S avant la mitose, comme la levure de fission et les cellules humaines, le point de contrôle post-réplicatif prend le temps de réparation en retardant le début de la mitose. Dans les types cellulaires où la mitose et la phase S sont concurrentes, tels que la levure bourgeonnante, les retards aux points de contrôle postréplicatifs sont l'état d'avancement de la mitose à la métaphase. Rôle de complexes cycline-CDK : Les complexes cycline-CDK sont des kinases capables de phosphoryler des protéines substrats. Ils sont constitués des deux sous-unités : la cycline (sous-unité activatrice de la kinase), et le CDK (sous-unité catalytique de la kinase). Les cyclines n’ont pas d’activité catalytique et les CDKs sont inactives en absence d’une Contexte et cas d’application 17 partenaire cycline. Les CDKs effectuent une commune réaction biochimique lorsqu’activées par une cycline liée appelée la phosphorylation ; ceci active ou ralentit les protéines cibles pour orchestrer l’entrée coordonnée à la phase suivante du cycle cellulaire. Des combinaisons cycline-CDK différentes déterminent les protéines ciblées en aval. Les CDKs sont exprimées constitutivement dans les cellules alors que les cyclines sont synthétisées à des étapes spécifiques du cycle, en réponse à divers signaux moléculaires. Lors de la réception d’un signal pro-mitotique extracellulaire, les complexes cycline-CDK de G1 deviennent actifs afin de préparer la cellule pour la phase S, en promouvant l’expression des facteurs de transcription qui à leur tour promeuvent l’expression des cyclines de S et des enzymes nécessaires pour la réplication de l’ADN. Les complexes cycline-CDK de G1 promeuvent également la dégradation des molécules qui fonctionnent comme les inhibiteurs de la phase S en les ciblant pour l’ubiquitination. Une fois qu’une protéine a été ubiquitinilée, elle est dégradée par le protéasome. Les complexes cycline-CDK actifs de S phosphorylent des protéines qui forment des complexes pré-réplications assemblés durant la phase G1 sur les origines de réplication de l’ADN. La phosphorylation sert à deux objets : pour activer chaque complexe pré-réplication déjà-assemblé, et pour prévenir la formation de nouveaux complexes. Ceci assure que chaque portion de génome de la cellule sera reproduite une fois et une seule fois. La raison de prévention de gaps en réplication est claire, parce que les cellules enfants manquant de tout ou partie des gènes essentiels seront mortes. Toutefois, pour les raisons liées aux effets du nombre de copies de gènes, la possession de copies extra de certains gènes est aussi délétère pour les cellules enfants. Les complexes mitotiques cycline-CDK, synthétisés mais inactifs pendant les phases S et G2, promeuvent l’initiation de mitose en stimulant les protéines en aval impliquées dans la condensation des chromosomes et l’assemblage du fuseau mitotique. L’ubiquition ligase fait partie d’un complexe (APC) indispensable à la promotion de l’anaphase. Ce complexe chargé de dégrades les protéines vise également les cyclines mitotiques. La cycline D est la première cycline produite dans le cycle cellulaire, en réponse aux signaux extracellulaires (facteurs de croissance, par exemple). La cycline D se lie à la CDK4 existante, forme le complexe de cycline D-CDK4 actif. Le complexe de cycline D-CDK4 à son tour phosphoryle la protéine du rétinoblastome susceptibilité (Rb). Le Rb hyperphosphorylée se dissocie du complexe E2F/DP1/Rb, ceci active E2F. L’activation d’E2F entraîne la transcription de divers gènes, comme cycline E, cycline A, ADN polymérase, etc… La cycline E ainsi produite se lie à CDK2, ceci forme le complexe de cycline E-CDK2, qui pousse la cellule de phase G1 à la phase S (transition G1/S). La cycline B avec le complexe cdc2 (cdc2 – levures à fission, CDK1 – mammalien) forme le complexe de cycline B-cdc2, qui prend l’initiation de la transition G2/M. L’activation du complexe cycline B-cdc2 cause la rupture de l’enveloppe nucléaire et l’initiation de la prophase. Et par la suite, sa désactivation entraîne la cellule à sortir de la mitose.18 Contexte et cas d’application Figure 1.10. Molécules régulant intervenant dans le cycle cellulaire chez les mammifères (source : wikipedia.org) cdc2 (levures) = CDK1 (mammifères) Il semble qu’un réseau semi-autonome de la transcription agit en concert avec la machinerie cycline-CDK pour régler le cycle cellulaire. Plusieurs études d’expression génique ont identifié environs 800 à 1200 gènes dont l’expression change au cours du cycle cellulaire. Ils sont transcrits à des niveaux élevés à des points spécifiques du cycle cellulaire, et restent à des niveaux faibles dans le reste du cycle cellulaire. Tandis que l’ensemble des gènes identifiés diffère entre les études en raison de méthodes de calcul et des critères utilisés pour les identifier. L’expression de nombreux gènes est modulée par des facteurs de transcription exprimés aussi périodiquement. Les profils d’expression de ces facteurs de transcription sont modulés par les facteurs de transcription exprimés dans la phase précédente, et des modèles informatiques ont montré qu’un réseau CDK-autonome des facteurs de transcription est suffisant pour produire les oscillations dans l’expression de gènes. Rôle dans la formation tumorale : Une déréglementation du cycle cellulaire peut conduire à la formation de tumeur. Certains gènes tels que les inhibiteurs du cycle cellulaire, RB, p53, etc., lorsqu’ils sont mutés, peuvent permettre à la cellule de se multiplier sans contrôle, provoquant alors l’apparition de tumeurs. Bien que la durée du cycle cellulaire dans les cellules tumorales soit égale ou supérieure au cycle cellulaire dans les cellules normales, la proportion des cellules qui se trouvent dans la division cellulaire activée (par rapport à des cellules quiescentes en phase G0) dans les tumeurs est beaucoup plus élevée que dans les tissus normaux. L’ADN des cellules activées au cours du cycle cellulaire est ciblé dans le traitement du cancer car il est relativement exposé pendant la division cellulaire et donc susceptible d’être endommagé par des médicaments (intercalant de l'ADN) ou des radiations. La radiothérapie ou la chimiothérapie en suivant la procédure de réduction tumorale tuent les cellules qui sont récemment entrées dans le cycle cellulaire. En général, les cellules sont plus radiosensibles à la fin de M et de G2, et plus résistantes à la fin de S. Le motif de la résistance Contexte et cas d’application 19 et de la sensibilité est en corrélation avec le niveau de composé de sulfhydrile dans la cellule. Les sulfhydriles sont les radio-protecteurs et tendent à être à leur plus haut niveau en phase S et à leur plus bas près de la phase M. Le cycle cellulaire est contrôlé en plusieurs points de contrôle. Lorsque les cellules subissent un stress extracellulaire ou intracellulaire, ou les deux, ces points de contrôle, spécialement G1/S et G2/M qui sont contrôlés par un nombre de complexes composés des cyclines-CDKs et leurs régulateurs négatifs, incluant la famille Cip/Kip et la famille INK4a/ARF, sont activés. Le point G1/S est la première surveillance du système pour arrêter la synthèse de l’ADN quand les cellules subissent un stress extracellulaire et il est un pas effectif de contrôle de la prolifération et l’apoptose cellulaire. Le point de contrôle G1/S est situé à la fin de phase G1, juste avant la phase S, prend la décision importante de savoir si la cellule doit se diviser, retarder la division ou entrer en phase de repos. De nombreuses cellules s’arrêtent à ce stade et entrant en phase de repos appelée G0. Les cellules du foie, par exemple, n’entrent uniquement en phase M qu’une ou deux fois par an. Réseau de p53 : p53 (aussi appelé protéine 53 ou protéine tumorale 53) joue un rôle important en causant un contrôle mécanique aux deux points de contrôle G1/S et G2/M. La perte de contrôle de stabilité génomique est un élément central dans le développement du cancer, et p53, par la régulation des réponses normales au dommage de l’ADN et autres formes de stress gèno-toxique, est un élément très important dans le maintien de la stabilité génomique. Ainsi, il n’est pas surprenant que la protéine p53 fonctionnelle est perdue dans environ la moitié de tous les cancers humains. Qu’en est-il de l’autre moitié ? Une possibilité est que les mécanismes p53-indépendants de régulation ont été perdus. Une autre possibilité est que l’inactivation des voies p53-indépendantes peut arriver à n’importe lequel de plusieurs points différents et que la p53 elle-même n’est que la cible la plus courante. Par exemple, l’inhibiteur Mdm2 de p53 est surexprimé dans les tumeurs, indépendamment de la mutation de p53. Maintenant, vu les voies de signal qui arrivent à p53, en réponse à différentes formes de stress, et les voies de signal qui sortent de p53, déclenchés par p53 activée, il est clair que la p53 est le composant central d’un réseau complexe de voies de signalisation et que les autres composants de ces voies présentent les cibles alternatives pour l’inactivation. - Signal d’entrée : La quantité de p53 augmente en réponse à une série de signaux, tels que le dommage de l’ADN, l’arrêt de la synthèse de l’ARN ou de l’ADN, ou la déplétion de nucléotides. Les mêmes stimuli activent également la p53, qui est souvent latente en l’absence de stress. Des évidences récentes ont également montré que la protéine Mdm2, qui se lie à p53, accélère la dégradation de p53, éventuellement par la voie d’ubiquitine. Le fait que le gène Mdm2 est une cible traductionnelle de p53 suggère une base moléculaire pour les protéines p53 mutantes. Par conséquent, la stabilité de ces protéines mutantes semble être due à leur incapacité à régler positivement l’expression de Mdm2, une protéine impliquée dans leur dégradation, plutôt qu’une propriété intrinsèque conférée par la résistance à la dégradation.20 Contexte et cas d’application Une augmentation dans la transactivation de p53, sans augmentation dans le niveau de concentration de la protéine, a été trouvée dans les cellules traitées avec des doses basses de radiation d’UV, et la micro-injection d’un anticorps contre le domaine Cterminal stimule également la transcription p53-dépendente, même en l’absence de dommage à l’ADN. Plusieurs processus peuvent être impliqués dans l’activation de p53, ils incluent la phosphorylation, la glycosylation, la liaison aux protéines régulatrices, l’épissage alternatif, et l’acétylation. Comment p53 « sent » les signaux ? Plusieurs protéines connues sont suspectées. La protéine kinase ADN-dépendante (DNAPK), un candidat plausible, se lie à et est activée par les extrémités cassées de l’ADN, elle peut phosphoryler des résidus 15 et 37 de p53 d’une manière ADN-dépendante. La phosphorylation de la serine 15 affecte la transactivation et les fonctions d’arrêt de croissance de p53 dans des cellules. Cependant, les cellules dépourvues de DNAPK ne montrent aucun défaut dans l’inhibition p53-médiée du cycle cellulaire, montrant que si DNAPK a un rôle dans la régulation de p53, d’autres composants doivent être en mesure de compenser sa perte. De nombreuses protéines kinases ont été montrées pour phosphoryler p53 in vitro et sont des candidats pour être des régulateurs en amont. Cependant, très peu de données in vitro existent pour le rôle de la phosphorylation dans la régulation de p53. Les travaux récents qui montrent que p53 peut être acétylée in vitro sont intrigants et suggèrent la possibilité d’un mécanisme supplémentaire de régulation. Toutefois, il est nécessaire de montrer que l’acétylation se produit en réponse à un stress. La poly (ADP-ribose) polymérase (PARP) a longtemps été connue pour avoir un rôle dans la reconnaissance de l’ADN endommagé et dans sa réparation. Les cellules PARP-KO de hamster chinois sont défectueuses dans l’activation de p53 et résistantes à l’apoptose induite par le dommage à l’ADN. Toutefois, des fibroblastes PARP-KO d’embryon des souris ont une réparation normale de l’ADN, et bien qu’il existe une diminution appréciable dans l’induction de p53 après le dommage de l’ADN ou la déplétion de nucléotide, il n’y a pas de changement dans l’activité de p53 dans les réponses cellulaires au stress. Par conséquent, bien que PARP soit impliquée dans l’augmentation de la quantité de p53 dans les fibroblastes de souris, d’autres voies de signalisation doivent être plus importantes dans l’activation de p53 en réponse aux dommages de l’ADN. La perte de l’ATM, le produit du gène de l’ataxie télangiectasie, ralentit l’induction de p53 en réponse à des ruptures de brins d’ADN causées par γ- radiation, mais pas en réponse à des dimères de pyrimidine causées par radiation d’UV. De même, p53 est induite normalement dans les cellules ATM-KO humaines après traitement avec N-(phosphonacétyl)-L-aspartate (PALA), qui bloque la biosynthèse de novo UMP, ou l’adriamycine, qui endommage l’ADN. La p53 et l’ATM peuvent à la fois être des composants de complexes qui fonctionnent dans la recombinaison. De même, le produit du gène impliqué dans le syndrome de la rupture de Nimègue (NBS) a également été placé en amont de p53 dans la voie qui répond aux rayonnements ionisants mais pas dans les réponses à d’autres agents endommageant l’ADN. Parce que les défauts dans l’induction de p53 dans les cellules ATM-KO sont Contexte et cas d’application 21 partiels ou sélectifs pour certains types de dommages de l’ADN, ces produits de gènes sont impliqués dans certains mais pas tous les signaux. Des knockouts doublés ou triplés doivent avoir un défaut plus profond dans l’induction de p53 en réponse aux dommages de l’ADN. Les défauts partiels similaires dans la signalisation de p53 ont été observés dans le syndrome de l’anémie de Fanconi (FAS) et le syndrome de Bloom (BLS) des fibroblastes, ceci suggère que de nombreuses voies régulent p53. Récemment un rôle pour l'oncogène Ras et la voie des MAP kinases a été démontré dans la modulation et le fonctionnement de p53 dans les cellules humaines et de rongeurs. L’expression élevée de Ras ou l’activation de la voie de Mos/MAPK induit des niveaux de p53 de type sauvage et cause un arrêt de la croissance permanente, semblable à la sénescence cellulaire. Les cellules dépourvues de p53 peuvent tolérer des niveaux élevés de MAPK et affichent beaucoup d’arrêts p53-dépendants du cycle cellulaire et d’instabilité génomique. Dans une lignée de cellules défectueuses dans la voie des MAP kinases et dans l’expression de p53, une expression accrue de la MAP kinase, ERK2 restaure les niveaux normaux de p53, ce qui montre clairement que ERK2 est dans une voie qui régule le niveau d'expression de p53. Cette MAPK a été montrée pour phosphoryler les résidus 73 ou 83 de p53 in vitro, et cette phosphorylation peut être importante dans la stabilisation de la protéine. D’autres kinases, comme DNAPK II, cycline A-Cdc2, et cycline B-Cdc2, sont connues pour phosphoryler la protéine p53 in vitro et peuvent jouer un rôle dans la stabilisation de p53. Les mécanismes de l’induction de p53 en réponse aux types différents de stress sont encore largement méconnus. - Signalisation post p53 : p53 est impliquée dans plusieurs aspects différents de l’arrêt du cycle cellulaire, l’apoptose, contrôle de l’intégrité du génome, et la réparation de l’ADN. Comment p53 régule de nombreux processus différents ? p53 est un tétramère qui peut se lier à des séquences spécifiques de l'ADN et donc transactiver de nombreux gènes. Plusieurs travaux ont montré que la p53 active est associée différemment sur les promoteurs, ceci entraîne la liaison et la transactivation différentielles de l’ADN. La p53 peut également inhiber l’expression de certains gènes. En outre, certains phénotypes p53-dépendents ne comportent pas de régulation de la transcription du tout. - Contrôles du cycle cellulaire : La transition G1/S – Les anticorps, qui reconnaissent l’extrémité terminale C de p53, empêchent des fibroblastes stimulés d’entrer dans la phase S. Ce résultat, à l’origine interprété comme une preuve qu’une fonction positive de p53 a été nécessaire, pose un paradoxe quand la surexpression de la p53 typesauvage a été trouvée causant un arrêt de la croissance. Le paradoxe a été résolu quand on a constaté que ces anticorps inhibent plutôt que d’activer p53. Il est maintenant mieux compris que p53 est le médiateur pour l’arrêt en G1 en réponse aux dommages de l’ADN causés par les UV ou la γ-radiation, les médicaments chimio-thérapeutiques ou la privation de nucléotides. La variabilité de type cellulaire dans l’arrêt p53- dépendant en G1 est illustré par les études avec la γ-radiation, ce qui dans les fibroblastes diploïdes normaux provoque un arrêt long-terme p53-dépendant associé à l’induction prolongée de p21/Waf1. L’irréversibilité de cet arrêt dépend de 22 Contexte et cas d’application l’incapacité de ces cellules à réparer même un petit nombre de cassures double-brin de l’ADN, de sorte que le signal d’activation persiste. En revanche, la γ-irradiation de cellules HT1080, issues d’un fibrosarcome avec la p53 type-sauvage, provoque un arrêt en G1 transitoire, tandis que la lignée tumorale colorectale RKO et la lignée tumorale mammaire MCF7, qui ont également une p53 type-sauvage, ne parviennent pas à arrêter en G1 après l’irradiation. Ces différences peuvent indiquer que la formation tumorale peut impliquer l’inactivation des composants en amont ou en aval de p53, ce qui provoque un échec de la réponse cellulaire aux dommages à l’ADN. Par exemple, la γ-irradiation active p53 pour activer la transcription de p21/Waf1, qui se lie à et inhibe les kinases cycline-dépendantes, provoque une hypo-phosphorylation de Rb, empêchant ainsi la libération de E2F et bloque la transition G1/S. La modification d’un de ces composants en aval peut avoir un effet similaire à celui de l’inactivation de p53 lui-même dans la prévention de la voie de signalisation. La p53 fuseau est impliquée dans un point de contrôle qui empêche la réplication de l’ADN lorsque le fuseau mitotique a été endommagé. Lorsque le contenu de l’ADN des fibroblastes d’embryons a été mesuré après le traitement avec du nocodazole ou autres inhibiteurs de l’assemblage des microtubules, il a été constaté que les fibroblastes normaux ont un contenu 4 N de l’ADN, tandis que les fibroblastes p53- KO atteignent des contenues de l’ADN de 8 ou 16 N. La destruction du fuseau peut bloquer la progression en mitose, ou la réplication peut être contrôlée en bloquant l’entrée à la phase S. Dans la lignée cellulaire murine avec p53 type-sauvage, la nocodazole cause un arrêt mitotique transitoire, à la suite de l’entrée en G1 sans ségrégation des chromosomes. Après la mitose, p53 est induit. La conclusion selon laquelle p53 induite en réponse aux dommages du fuseau bloque l’entrée à la phase S a été obtenue par l’analyse de la synthèse de l’ADN dans les fibroblastes exposées au nocodazole ou à la colcémide. Il est intéressant de noter que, les fibroblastes des p21/Waf1-KO de souris ne reproduisent pas leur ADN lorsqu’ils sont traités avec des poisons du fuseau. Par conséquent, p53 doit également utiliser le mécanisme p21-indépendent pour arrêter les cellules en G1 et donc inhiber la réplication en réponse à des poisons du fuseau. L’homéostasie du centrosome – Les fibroblastes p53-KO d’embryon de souris acquièrent plus de deux centrosomes, conduisant à la mitose avec plus de deux pôles du fuseau. p53 est associée aux centrosomes et donc peut affecter directement la duplication des centrosomes. Comme alternatif, la duplication impropre des centrosomes peut induire l’activation de p53, ceci peut à son tour causer l’arrêt dans G2 ou G1. Il est curieux que les MAP kinases et Cdc2, capables de phosphoryler p53, sont également liées aux centrosomes, et, comme p53, la MAP kinase est importante pour l’homéostasie de centrosomes [25]. Contexte et cas d’application 23 Figure 1.11. Composants de la voie de signalisation p53 (source : Munna et all 1998 [25]) p53 s’accumule et est modifiée et activée en réponse aux signaux générés par une variété de stresses génotoxiques. Plusieurs protéines, incluant ATM, PARP, FAS, BLS, et NBS sont impliquées dans l’activation, mais les voies qui conduisent à la modification sont largement inconnues. La voie RAS-MAP kinase est impliquée dans les niveaux de base de p53 et peut également affecter sa fonction. Certaines des fonctions cellulaires affectées par p53 peuvent être compromises par l’expression dérégulée de Myc, Bcl2, E1B, ou E2F. Le contrôle de l’activité de p53 comprend une boucle autorégulatrice liée à Mdm2. L’ensemble des voies p53-dépendentes aident à maintenir l’intégrité génomique par l’élimination des cellules endommagées, soit en les arrêtant de façon permanente ou par apoptose. p53 aide également à régler l’entrée en mitose, la formation du fuseau, et l’intégrité centrosome. - Régulation de l’apoptose : p53 joue un rôle dans le déclenchement de l’apoptose dans certains types cellulaires, par exemple pour les cellules d’origine hématopoïétique. Les stimuli tels que les dommages à l’ADN, le retrait des facteurs de croissance, et l’expression de Myc ou E1A peuvent également causer l’apoptose p53-dépendente. La p53 doit être capable de fonctionner comme un facteur de transcription pour bloquer la transition G1/S, mais l’apoptose ne requiert pas nécessairement l’activation de la transcription, car l’inhibition de la transcription par l’actinomycine D ou de la traduction par la cycloheximide n’affectent pas toujours l’apoptose p53-dépendente. En outre, les inhibiteurs de phosphatase induisent l’apoptose p53-dépendente en l’absence de transactivation. Cependant, les protéines pré-apoptotiques Bax et Igf-Bp3 sont des cibles de la transcription activée par p53, ceci suggère que la transactivation par p53 est importante dans l’induction de l’apoptose dans certaines circonstances. En outre, les anti-apoptotiques Bcl2 et la protéine adénovirus 19-kDa E1B peuvent prévenir l’apoptose p53-médiée. En réponse à un même stimulus p53 induit une apoptose dans certains types de cellules, mais un arrêt du cycle cellulaire dans les Hausse de quantité ou d’activité de p53 E2F RB Arrêt de G1 MYC Stimuli Instabilité génomique Apoptose Voie de kinases RAS/MAP Inhibition de mitose checkpoint du fuseau centrosome duplication BAX BCL2 ou E1B PARP, ATM, NBS, BLS, FAS, Modificateurs biochimiques p21 MDM2 CDK4 Cycline D + E2F Progression de phase S P RB24 Contexte et cas d’application autres. Plusieurs variables, telles que l’ampleur des dommages à l’ADN et les niveaux de p53, affectent également le choix entre l’arrêt du cycle cellulaire et l’apoptose. Également, le dialogue entre les voies de p53 et de Rb peut être important dans la détermination de ces réponses biologiques aux dommages à l’ADN. Par exemple, l’inactivation de Rb cause la perte de l’arrêt en G1 et l’induction de l’apoptose après dommages à l’ADN. Ceci peut être expliqué par la libération de E2F, qui, lorsqu’il est surexprimé à lui seul peut induire l’apoptose. Par ailleurs, la surexpression de Rb bloque l’apoptose p53-médiée. - Stabilité génomique : Le contrôle p53-dépendant du cycle cellulaire maintient l’intégrité génétique dans la population des cellules. L’amplification du gène est un modèle utilisé largement pour étudier l’intégrité génétique. Dans la plupart des cellules transformées ou immortalisées, des médicaments tels que PALA ou méthotrexate inhibent la synthèse de précurseurs nucléotidiques. La fonction de p53 est fréquemment perdue au cours du processus de tumorigenèse et dans l’immortalisation spontanée des cellules primaires, ceci indique que p53 peut être le facteur principal déterminant la permissivité pour l’amplification génique. En effet, les fibroblastes d’embryons de souris p53-KO sont permissives pour l’amplification génique, et des cellules humaines primaires de patients de Li-Fraumeni sont devenues permissives dès qu’elles ont perdu leur seul exemplaire de p53 de type sauvage. Quel signal est généré en tant que partie du mécanisme de l’amplification génique qui pourrait activer les voies p53-dépendantes et prévenir la propagation de cellules résistantes aux médicaments? Le modèle actuel de l’amplification implique, dans une première étape essentielle, de multiples cycles pont-cassé-fusions dans lesquels l’ADN cassé est formé tout au long d’une lignée entière des cellules enfants. L'importance des lésions de l'ADN dans la régulation des stades précoces de l'amplification génique a été démontrée avec des cellules REF52 transfectées avec un mutant de grand antigène T de SV40 sensible à la température. Lorsque ces cellules sont choisies avec PALA à la température basse, l’antigène T inactive p53, ceci rend les cellules permissives pour l’amplification génique. La restauration de p53 en inactivant l’antigène T à une température plus élevée très tôt dans le processus de formation des colonies PALA-résistantes arrête stablement toutes les cellules contenant l’ADN nouvellement amplifié. Des lignées cellulaires humaines peuvent acquérir une résistance à PALA par des mécanismes autres que l’amplification génique in situ, qui est de loin le mécanisme le plus commun dans les cellules de rongeurs. La plupart des colonies PALA-résistantes, provenant de plusieurs lignées cellulaires humaines, ne contiennent pas d’ADN. Cependant, dans les deux cas, les voies p53-dépendantes sont toujours impliquées. L’épuisement des nucléotides pyrimidiques causés par PALA génère un signal pour l’induction de p53 avant que tout endommagement de l’ADN ne se produise, en arrêtant les cellules et inhibant la formation des colonies PALA-résistantes. Réseau de Chk2 : Pommier et al ont montré le rôle de Chk2 (et de Chk1 aussi) dans les cellules. Les agents ciblant l’ADN ont été utilisés dans la chimiothérapie du cancer, et peuvent guérir les patients atteints de leucémies, lymphomes, et cancers des testicules. Dans de nombreux autres cancers, les réponses à ces thérapies sont limitées et la rechute est Contexte et cas d’application 25 courante. Une approche consiste à rechercher les déterminants moléculaires de réponse tumorale et à extraire les paramètres moléculaires à utiliser pour prédire la réponse tumorale. Les paramètres moléculaires comprennent le point de contrôle du cycle cellulaire, les voies de la réparation de l’ADN et de l’apoptose. Les points de contrôle cellulaires sont des voies moléculaires, qui sont activées en réponse aux dommages à l’ADN. L’Activation des points de contrôle peut tuer les cellules endommagées par apoptose ou arrêter la progression du cycle cellulaire pour réparer l’ADN avant la reproduction/division cellulaire. Deux voies bien connues sont les voies ATM-Chk2 et ATR-Chk1. La voie ATM-Chk2 est principalement activée par la cassure double-brin de l’ADN (DSB) produite par les rayonnements ionisants (IR) ou les agents endommageant de l’ADN tels que la bléomycine et la camptotécine. La voie ATR-Chk1 apparaît dans le cas de la DSB réplication-médiée, à côté de la voie ATM-Chk2. Les deux voies ATM-Chk2 et ATRChk1 semblent fonctionner comme des cascades de transduction parallèles des dommages à l’ADN. Il existe cependant un dialogue entre les deux voies, ATM peut également phosphoryler Chk1 en réponse à IR, et ATR peut phosphoryler Chk2 en réponse aux dommages réplication-associés. ATM et ATR appartiennent à la famille des kinases phosphatidylinositol-3 (PI3K), qui contient également la kinase ADN-dépendante (DNA-PK) et ATX. La fonction des PI3K est de former des grands complexes multi-protéiques dans le voisinage des dommages à l’ADN. L’Activation de la famille PI3K conduit à la phosphorylation/activation directe des effecteurs du point de contrôle (Cdc25A et Cdc25C, p53, BRCA1), et indirectement par la phosphorylation/activation des kinases Chk1 et Chk2, qui, à leur tour, phosphorylent les effecteurs du point de contrôle. Les Chk1 et Chk2 ont des rôles redondants partiellement pour l’arrêt/point de contrôle du cycle cellulaire, la réparation de l’ADN, et la transcription de l’ADN, car elles partagent une gamme de substrats, incluant p53, Cdc25A et Cdc25C. Pour la Chk2 humaine, le domaine SQ/TQ est dans la partie NTerminale, et plus spécialement, T68 est une cible de PI3K’s. La phosphorylation de T68 est une condition préalable pour l’autophosphorylation ultérieure sur T383 et T387, et l’activation de Chk2. Le domaine FHA fonctionne comme des sites de liaison pour les protéines phospho-thréonines (pT)-contenant, y compris les substrats de Chk2 aussi bien que Chk2 T68-phosphorylée. Le domaine de kinase catalytique (résidu 226-486) contient une boucle de l’activation autour de l’autophosphorylation/activation de résidus T383/387. Deux mutations, D347A ou D368N induisent une Chk2 kinase-morte. Le signal nucléaire de localisation (NLS) de Chk2 se trouve vers le C-Terminus. La phosphorylation de la Sérine 516 est impliquée dans l’apoptose en réponse aux dommages de l’ADN (DSB). Ainsi, DSB active Chk2, qui à son tour phosphoryle les substrats dont la phosphorylation réglemente des points de contrôle, qui soit tuent les cellules par l’apoptose ou arrêtent le cycle cellulaire et améliorent la survie cellulaire en laissant du temps pour la réparation. - Activation de Chk2 par les dommages à l’ADN : En réponse aux DSB, Chk2 est phosphorylée par ATM (et ATR aussi) et DNA-PK, qui à son tour active Chk2 soit directement par phosphorylation de T68, soit indirectement lorsque ATM phosphoryle/active la Plk3. La phosphorylation de T68 est une condition préalable pour l’activation de Chk2. Elle est essentielle pour la dimérisation (une T68 phosphorylée d’une Chk2 fait l’interaction avec le domaine FHA d’autre), qui autorise 26 Contexte et cas d’application la trans-phosphorylation intermoléculaire de Chk2 sur T383/387 dans la boucle d’activation du domaine kinase et la cis-phosphorylation sur S516. La phosphorylation est nécessaire à l’activation complète de Chk2 vers ses substrats hétérologues. Le domaine FHA de Chk2 est essentiel pour que la mutation I157T diminue dans la dimérisation et l’activation de Chk2. La phosphorylation ATMdépendante ne peut pas arriver librement dans le nucléoplasme, mais nécessite des complexes de protéines adaptatrices spécifiques DSB-associées contenant des motifs BRTC. Ainsi, la phosphorylation ATM-dépendante de Chk2 nécessite Nbs1 intacte, Brca1, la réparation fonctionnelle de mésappariement, et est stimulée par la liaison à la protéine liée, 53BP1. Aussi, la protéine partenaire Chk2-liée MDC1 est nécessaire pour les réponses Chk2-médiées aux dommages de l’ADN. MDC1, comme Chk2, contient un domaine FHA, et est phosphorylée d’une manière ATM/Chk2-dépendante. La suppression de l’induction de MDC1 entraîne la défection du point de contrôle de phase S. MDC1 est trouvée sur les sites de cassures de l’ADN, et associée à Chk2 T68-phosphorylée après dommages à l’ADN. Chk2 active ses cibles en aval, dont sept sont actuellement connues. Trois sont impliquées dans l’apoptose : PML, p53 et E2F1. Deux sont impliquées dans l’arrêt au point de contrôle du cycle cellulaire : Cdc25A et Cdc25C. Brca1 règle probablement la structure de la chromatine, l’induction de la réparation de l’ADN. La cible de Chk2 la plus récemment identifiée est la phosphatase-2A (PP2A), qui à son tour peut inactiver Chk2 par la déphosphorylation de T68. - Cibles en aval de Chk2 impliquées dans l’apoptose : Chk2 peut régler l’apoptose par phosphorylation de PML. Les polymères PML sont normalement concentrés dans les corps nucléaires qui contiennent au moins 30 protéines différentes impliquées dans la réparation de l’ADN, le point de contrôle du cycle cellulaire, la dégradation de protéine et l’apoptose telles que p53, Nbs1, BLM, pRb, Dax. La deuxième cible de Chk2 impliquée directement dans l’apoptose est p53. Chk2 phosphoryle p53 sur la S20, la phosphorylation active p53 par prévention de la liaison de Mdm2 à p53, et donc la dégradation Mdm2-médiée de p53. Chk2 peut également induire l’activité de transcription de p53 par dissociation de Mdm2 à p53. La liaison de Chk2 à 53BP1 (un régulateur de transcription de p53), peut également contribuer à l’activation de la transcription de p53. Chk1 et Jnk peuvent également phosphoryler p53, ce qui explique que le knockout de Chk2 ne prévient pas la phosphorylation IR-inductive de p53 sur S20. Chk2 phosphoryle aussi E2F1. Un ensemble des gènes impliqués dans l’apoptose sont transactivés par la sur-induction d’E2F1, sont inclus INK4a/ARF, p73, Apaf-1, Noxa at PUMA. La phosphorylation d’E2F1 sur S364 par Chk2 augmente sa demi-vie en bloquant sa dégradation, qui améliore l’activité de transcription d’E2F1. E2F1 est également phosphorylée sur S31 et activée directement par ATM (et ATR) en réponse aux dommages de l’ADN. Les dommages à l’ADN peuvent diriger E2F1 sur ses gènes cibles apoptotiques. - Cibles en aval de Chk2 impliquées dans l’arrêt du cycle cellulaire : Chk2 peut inactiver les kinases cycline-dépendantes et induire l’arrêt du cycle cellulaire par phosphorylation et donc inactivation de Cdc25A et Cdc25C, deux des trois kinases de Cdc25. La phosphorylation de Cdc25A induit sa dégradation, et bloque les cellules à Contexte et cas d’application 27 la frontière G1/S. Les deux Chk1 et Chk2 peuvent effectivement phosphoryler Cdc25A sur S123. La phosphorylation qui en résulte conduit à l’ubiquitination et la dégradation rapide de Cdc25A par le protéasome. La phosphorylation Chk2-médiée de Cdc25C sur S216 inactive Cdc25C par induction de sa liaison à la protéine 14-3-3 et son exportation nucléaire. Donc, l’inactivation de Cdc25C prévient l’activation de Cdk1/cycline A et Cdk1/cycline B, et donc induit l’arrêt G2/M. La phosphorylation/l’activation de p53 peut également fonctionner comme une réponse d’arrêt du cycle cellulaire G1 retardée par induction de la transcription de p21 et de Gadd45. - Rôle possible de Chk2 en réparation de l’ADN : Aucun rôle direct de Chk2 en réparation de l’ADN a encore été montré. Cependant, il y a des preuves de relier l’hyper-phosphorylation Chk2-médiée de BRCA1 au processus qui règle la réparation de DSB. BRCA1 est un gène vital de suppresseur tumoral dont l’inactivation augmente le risque de cancer du sein et de l’ovaire. Les cellules déficientes en BRCA1 présentent une hypersensibilité aux agents d’IR et d’ADN-réticulation. La phosphorylation de BRCA1 induit la dissociation de BRCA1 de Chk2, une situation appelée interaction Chk2/PML. BRCA1 libre pourrait alors fonctionner en réparation de l’ADN et en régulation de la transcription. L’évidence récente suggère que l’inhibition de la phosphorylation Chk2-médiée via la mutation de S988 sur BRCA1 prévienne la régulation positive BRCA1-dépendante de la recombinaison homologue (HR) et la régulation négative d’end-jonction non-homologue (NHEJ). En vertu de la phosphorylation de p53, Chk2 est potentiellement capable de régler un certain nombre d’événements en aval qui sont réglementés par l’activité transcriptionnelle de p53 et impliqués en réparation. Une preuve supplémentaire que Chk2 pourrait fonctionner en réparation de l’ADN provient de l’interaction de Chk2 avec Msh2, qui est impliquée dans la réparation de décalage, et avec Mus81 qui est impliquée dans la réparation de DSB. - Autres substrats potentiels de Chk2 : Deux substrats potentiels supplémentaires de Chk2 sont la Phospho-kinase-3 (Plk3) et Mdm2. Plk3 forme une boucle d’activation positive avec Chk2, les deux kinases s’activent l’une l’autre. Par ailleurs, elles sont toutes les deux activées par ATM, et elles phosphorylent Cdc25C et p53. La phosphorylation de Mdm2 soit par Chk2, soit par Chk1 pourrait activer p53 en inactivant l’interaction p53-Mdm2, qui fonctionne comme un antagoniste de p53. 1.1.2. Inhibiteurs de Chk2 comme nouveaux agents anticancéreux Pommier et al ont trouvé que l’inhibition de l’activité de p53 a amélioré la réponse apoptotique des cellules p53-défectueuses à l’IR. Ainsi, il semble rationnel de proposer l’utilisation des inhibiteurs de Chk2 pour les tumeurs p53-déficients. 1.1.3. Problématique La régulation du cycle cellulaire est un processus décidant de la survie d’une cellule, contenant la détection et la réparation de dommage génétique ainsi que la prévention de la division cellulaire incontrôlée. Les événements moléculaires contrôlant le cycle cellulaire sont 28 Contexte et cas d’application ordonnés et directionnels. C’est à dire, chaque processus se déroule de manière séquentielle et il est impossible d’inverser le cycle. Deux classes principales de molécules, cyclines et kinases cycline-dépendantes (CDKs), déterminent un progrès cellulaire dans le cycle. Un grand nombre de gènes codant pour les cyclines et CDKs sont conservés chez tous les eucaryotes, mais en général, les organismes plus complexes ont des systèmes de contrôle du cycle cellulaire plus élaborés qui intègrent des composants individuels. 1.1.4. Exigences De nombreuses études se sont penchées sur la construction des réseaux de gènes grâce à des méthodes mathématiques ou logiques (Tomshine & Kaznessis, 2006 ; Brun et al, 2004). Le logiciel SOLAR [14] est un logiciel développé au Japon (Nabeshima et al, 2003), utilisant de la programmation logique et employé pour effectuer de la conséquence finding, c'est à dire trouver des conséquences logiques à partir d'un jeu de données. La logique basée sur l'abduction fait de ce logiciel un outil de choix pour une telle étude. D'autre part, c'est aussi et surtout parce que Katsumi Inoue a participé à son élaboration que le projet lui donne un rôle prépondérant. SOLAR a déjà été utilisé en biologie des systèmes, notamment sur p53 (Inoue et al, 2010), mais les résultats n'étaient pas aussi probants qu'on aurait pu espérer : un des objectifs de travail devait alors inclure une meilleure rigueur dans les données afin d'obtenir des résultats biologiquement significatifs. 1.2. Cas d’application 1.2.1. Contexte des gènes et leurs interactions Le modèle biologique adopté a suivi celui indiqué dans la carte de Pommier [24], et a été complété par des informations trouvées dans la littérature. Dans la carte, les symboles et conventions sont définis ci-dessous Figure 1.12. Définitions des symboles et des conventions de la carte Couleurs : Noir – interaction de liaison ; bleu – modification de protéine ; vert – processus enzymatiques ou autres stimulants ; rouge – inhibitions ou autres effets négatifs ; pourpre – activation de transcription ou répression.Contexte et cas d’application 29 Symboles : (a) Protéines A et B peuvent se lier, le nœud représente le complexe A:B ; (b) Complexes multimoléculaires ; (c) Modification covalente de A ; (d) Dégradation de A ; (e) Stimulation enzymatique en transcription ; (f) Stimulation enzymatique en trans; plus spécifiquement autophosphorylation en trans ; (g) Symbole général de stimulation; (h) Une barre derrière la tête de flèche signifie la nécessité ; (i) Symbole général d’inhibition ; (j) Symbole de raccourci pour l'activation de transcription ; (k) Symbole de raccourci pour l'inhibition de transcription Figure 1.13. La carte d'interaction de la réponse ATM-dépendante de la cassure double-brin (source : Pommier et al, 2005[24]) Explication de la carte : #1.D4 : Chk2 est activé suite à la phosphorylation par ATM en réponse à DSB (en anglais : double-strand break) et la réplication blocus menant à DSB de réplication-associée30 Contexte et cas d’application #2.D4 : ATR phosphoryle et active Chk2 en réponse à UV (ultraviolet) et réplication des blocs mais pas IR (en anglais : ionizing radiation). Ainsi, Chk2 peut être activé par des voies ATM indépendants #3.D5 : Chk2 est activé par homodimérisation et phosphorylé par des kinases PI3 #4.D4 : Nbs1 est nécessaire pour la phosphorylation ATM-dépendante et l’activation de Chk2. #5.C4 : Chaque molécule Nbs1 recrute un dimère de Mre11 et Rad50 aux foyers DSB, où le complexe nucléase Mre11-Rad50 répare le DSB #6.B4: Nbs1 est phosphorylée au S343 par ATM #7.B3: H2AX est phosphorylée au S139 (γH2AX) par ATM en réponse à DSB et par ATR et DNA-PK en réponse à la réplication-médiation DSB #8.D3: MDC1 forment les foyers nucléaires avec γ-H2AX et Chk2 T68-phosphorylée en réponse à l'IR. #9.D3: 53BP1, une autre protéine BRCT-contenant, améliore également la phosphorylation à T68 de Chk2 #10.C2: BRCA1 est phosphorylée par ATM sur plusieurs sites #11.D1: ATM phosphoryle CtIP sur S664 et S745, inhibant ainsi la liaison de CtIP à BRCA1 #12.C1: BRCA1 se lie à Rad50 en réponse à DSB et co-localise avec les foyers Mre11- Rad50-Nbs1 suivante l’IR #13.E4: Polo kinase 3 (PLK3), qui, comme Chk2, est présente pendant tout le cycle cellulaire, est phosphorylée et activée dans les minutes suivant IR et MMS de manière ATMdépendante #14.D3: Kinase Polo-like (Plk1) phosphoryle Chk2 (à T68), co-IP avec Chk2, et colocalise avec Chk2 à centrosomes #15.F4: Chk2 phosphoryle p53 sur T18 et S20, ceci empêche la liaison de p53-Mdm2 et de la dégradation de p53 #16.E5: Chk2 phosphoryle PML sur S117, qui se dissocie PML de Chk2 et active l'apoptose PML-médiation #17.F6: Chk2 phosphoryle E2F1 dans les cellules traitées avec de l'étoposide #18.C2: Chk2 phosphoryle BRCA1 au S988 #19.F2: La phosphorylation de Cdc25A par Chk2 et ATM au S123 induire la destruction de Cdc25A Contexte et cas d’application 31 #20.G2: La phosphorylation de Cdc25C par Chk2 et p38 MAPK inactive Cdc25C #21.D1: ATM est requis pour l'activation de p38-gamma, ce qui conduit à l'activation de Chk2, et est suffisante pour activer un arrêt G2-M en réponse à IR #22.E1: Jnk est activé par UV, et peut activer Cdc25C et inactiver p53 par la phosphorylation S20 #23.C5: La phosphorylation de FANCD2 en réponse à l'IR au S222 est ATM-dépendante (directe ou indirecte ne sait pas) et nécessite la phosphorylation au S343 de Nbs1 #24.D6: Mus81 se lie spécifiquement au domaine FHA de Chk2 et de Mus81 #25.D6: Msh2 lie à Chk2, et MLH1 lie à l'ATM #26.E6: La protéine phosphatase 2A (PP2A) se lie à Chk2 et déphosphoryle T68, inactivant ainsi Chk2 1.2.2. Définitions Quelques définitions sont données sur le langage de programmation utilisé dans la thèse : Prolog et logiciel SWI-Prolog. Le langage a en premier été conçu par un groupe autour d’Alain Colmerauer à Marseille, France, dans les années 1970. Il a été un des premiers langages de programmation logique, et reste le plus populaire parmi ces langages aujourd’hui, avec beaucoup d’implémentations gratuites et commerciales disponibles, l’une d’elles est SWI Prolog. Prolog (PROgramming in LOGic) est un langage de programmation de but général. Il est aussi appelé le langage de programmation de notation (symbolic programming) comme les langages de programmation fonctionnelle (functional programming) ou de programmation non-numérique (non-numerical programming). Ce langage de programmation est associé avec l’intelligence artificielle et la linguistique computationnelle. Il a ses racines en logique du premier ordre, une logique formelle, et contrairement à de nombreux autres langages de programmation. Prolog est déclaratif : le programme logique est exprimé en termes de relations : il est bien adapté pour résoudre les problèmes liés à des objets et des relations entre eux. Le principe de la programmation logique est basé sur les clauses de Horn. Une clause est appelée une clause de Horn si et seulement si elle a au plus un littéral positif. Par exemple, pour dire « Tous les hommes doivent mourir » et « Socrate est un homme », on peut déclarer: Clause 1 : mourir(X) ← homme(X) Clause 2 : homme(Socrate) Ce sont des clauses de Horn. La première clause est une règle, la deuxième est un fait. Un programme Prolog peut être considéré comme une base des données qui contient des clauses de Horn en forme de faits et/ou de règles. L’utilisateur peut exécuter un programme Prolog en posant des questions sur la base des données, par exemple : est-ce que Socrate doit mourir « mourir(Socrate) »? Le système va exécuter le programme en raisonnant – cherchant 32 Contexte et cas d’application sur la connaissance – la base des données, pour donner une réponse qu’elle soit « vraie » ou « fausse ». Pour l’exemple ci-dessus, le système va répondre à la question « Est-ce que mourir(Socrate) est vrai ?» en répondant à la question « Est-ce que « homme(Socrate) est vrai ?» (Clause 1). La réponse est « oui » (Clause 2), alors mourir(Socrate) est vrai. Un autre exemple plus compliqué, parent(Tom, Bob) signifie que Tom est parent de Bob. C’est un fait, dans lequel parent est un prédicat, Tom et Bob sont des arguments. Si on a parent(Tom, Bob) et parent(Bob, Liz), alors on a grandparent(Tom, Liz), signifie que Tom est grand parent de Liz. Généralement, X est grand parent de Z si et seulement s’il existe un Y, tel que X est parent de Y et Y est parent de Z. On a une règle comme grandparent(X, Z) ⃪ parent(X, Y) ⋀ parent(Y, Z) qui signifie que si X est parent de Y et Y est parent de Z, alors X est grand parent de Z. Dans Prolog, la règle est représentée par grandparent(X, Z) :- parent(X, Y), parent(Y, Z). Ensuite, une relation plus compliquée est définie, c’est l’ancêtre. X est ancêtre de Y si X est parent de Y, ou grand parent de Y, ou parent de grand parent de Y, etc. De façon récurrente, la relation peut être définie comme ça : X est ancêtre de Y si et seulement si (X est parent de Y ou X est parent de Z qui est ancêtre de Y). Dans Prolog, ceci est représenté par deux clauses consécutives : ancestor(X,Y) :- parent(X,Y) et ancestor(X,Y) :- parent(X,Z), ancestor(Z, Y). Pour écrire et exécuter des programmes, on utilise l’implémentation gratuite SWI-Prolog. SWI-Prolog appartient à la famille Prolog Edinburgh, il est en développement continu depuis 1987. Son principal auteur est Jan Wielemaker. Le nom est dérivé de SWI : SociaalWetenschappelijke Informatica (Social Science Informatique), le nom ancien du groupe de l’Université d’Amsterdam, où Wielemaker est employé. SWI-Prolog dispose d’une bibliothèque des prédicats et de guidage riche. Il fonctionne dans l’environnement graphique d’objet orienté. SWI-Prolog est assez simple à utiliser en exploitant les caractéristiques interactives graphiques. Après le téléchargement et l’installation de SWI-Prolog en ligne : http://www.swiprolog.org/, et l’exécution de swipl-win.exe, la fenêtre de travail apparaît pour déposer des questions. SWI-Prolog fonctionne en mode interactif : l’utilisateur dépose des questions et le système répond. L’invite de commande de SWI-Prolog est un point d’interrogation avec un tiret, l’ordre indiqué pour surveiller le processus de travail de l’utilisateur, puis un curseur clignotant. Après qu’un programme de Prolog soit compilé et chargé en mémoire, l’utilisateur peut déposer des questions (finies par un point). En fonction de la question, le système répond vrai (true) ou faux (false) avec une valeur X = < value > s’il y a une variable X quelconque dans la question. Dans le cas où il y a plusieurs réponses, après la première réponse, l’utilisateur peut taper un point-virgule s’il veut que le système continue à donner d’autres réponses, jusqu’à ce que le système réponde false (c’est à dire, il n’y a plus de réponse). Ou bien l’utilisateur peut Contexte et cas d’application 33 arrêter en tapant « entrée ». L’utilisateur peut également recevoir un message d’erreur s’il y a des problèmes dans la question déposée. Retourner au problème principal. Ayant pour base la carte de Pommier, le choix du prédicat le plus simple a été de se baser sur les types d’interactions déjà existantes sur cette carte : stimulation (une réaction enzymatique générale), phosphorylation, autophosphorylation, inhibition, nécessité (désigne une interaction nécessaire en tant que condition prérequis pour qu’une autre interaction soit réalisable), liaison, activation de transcription, dégradation et déphosphorylation. Le deuxième choix de stratégie est de vouloir représenter les interactions de la voie de signalisation de façon linéaire et chronologique, c’est à dire de vouloir créer un modèle dans lequel une interaction peut être issue d’une autre interaction, et va probablement entraîner une autre encore. Il s’agit alors de trouver une façon de représenter une succession chronologique des interactions. En effet, la carte d’interaction de Pommier ne montre que les interactions en elles-mêmes, de manière générale, sans distinction quant à leur ordre d’apparition dans la cascade d’événements. Le choix est alors d’inclure le facteur temps dans le modèle d’une manière indirecte, sur les conséquences de la succession des événements dans les états différents des protéines. En connaissant leur ordre chronologique d’apparition, on peut connaître l’évolution des événements en transposant chacun de ces états dans le modèle logique [22]. Par exemple : si ‘ATM → Chk2 → p53 → Apoptose’ est lu dans la carte, après descriptions on a alors ‘ATM/ATM (se phosphoryle) → pATM (ATM phosphorylé) → Chk2 (phosphoryle) → pChk2 (Chk2 phosphorylé) → Chk2/Chk2 (se lie) → p53 (phosphoryle) → pp53 (p53 phosphorylé) → Transcription → Apoptose’ L’étape suivante dans la réalisation de la thèse est de construire un modèle contenant les interactions présentes dans la voie de signalisation en réponse à la cassure double brin de l’ADN. Ce modèle doit avant tout être un modèle biologique avant d’être un modèle logique, car il faut dans un premier temps lister les interactions avant de les implémenter dans Prolog. La nécessité de définir un modèle biologique a entraîné de faire des choix dans les informations apportées à ce modèle. Pour pouvoir établir ce modèle, il faut une compréhension de la voie de réponse à la cassure double brin, or à l’heure actuelle, elle n’est pas encore bien connue. Des informations certaines restant encore à découvrir. Pour passer du modèle biologique au modèle logique, il faut considérer plusieurs contraintes : comment modéliser les interactions, bien faire attention au sens des implications logiques, respecter l'ordre chronologique préalablement défini et vérifier la cohérence des informations. Mais l'étape la plus importante à ce niveau d'avancement a été de bien définir les prédicats. Les prédicats choisis ont été calqués sur ceux de la carte de Pommier, à savoir stimulation, phosphorylation, autophosphorylation, inhibition, nécessité, liaison, activation de transcription, dégradation et déphosphorylation. Au départ, les prédicats ont été conceptualisés, pour la majorité d'entre eux, de la façon suivante : produit ⃪ réaction(enzyme, substrat). La réaction peut être stimulation, phosphorylation, déphosphorylation, liaison, activation ou dégradation. Par exemple, p*-Y ⃪34 Contexte et cas d’application phosphorylation(X, Y). Les autres prédicats qui ne sont pas de type produit ⃪ réaction(enzyme, substrat) sont modélisés séparément : p*-Y ⃪ autophosphorylation(Y) ¬Y ⃪ inhibition(X, Y) : si X est vrai, alors Y ne peut pas l’être Y ⃪ nécessité(X, Y) : pour que Y est vrai, X doit être vrai En effet, certains prédicats ont été modifiés, ou bien supprimés, au cours d’implémentations, tandis que d’autres ont été rajoutés grâce aux mises à jours effectuées dans le modèle biologique et avec l’avancement de son implémentation dans Prolog. Par exemple, les prédicats ajoutés sont ubiquitination, méthylation et dissociation. Une fois l’inventaire des réactions réalisé, un modèle biologique adopté, les prédicats choisis et réactualisés, il faut implémenter les informations dans Prolog. Pour la thèse, le logiciel SWI-Prolog a été utilisé. Ce programme utilise un fichier qui doit posséder une syntaxe propre. En effet, le fichier doit contenir des informations en forme de clauses, plus précisément des clauses en Forme Normale Conjonctive (CNF). Une CNF est une conjonction de clauses, de laquelle chaque clause est une disjonction de littéraux. Exemple : Soient A, B, C, et D des littéraux, contenus dans les clauses (A ⋁ B) et (C ⋁ D). Une CNF possible pourra alors être [(A ⋁ B) ⋀ (C ⋁ D)]. 1.2.3. Règles de comportements Il y a des règles de comportement entre les protéines dans le réseau de gènes. Par exemple, s’il y a une relation causale directe d’une protéine A à une protéine B, elle est définie que si cause(A, B) est vrai. En autres mots, si A cause B, et si A est vrai, alors B est vrai. Le fait qu’il n’y a pas de relation causale directe d’une protéine A à une protéine B est représenté par un contraire de la forme ¬cause(A, B). Similairement, s’il y a une relation de blocage directe d’une protéine A à une protéine B, elle est définie que bloque(A, B) est vrai, etc. Le prédicat bloque peut être expliqué ci-dessous : si A bloque B, est si A est vrai, alors B est faux. Dans ce contexte, pour donner les liens entre les relations cause et bloque, la logique classique est utilisé. La solution élémentaire est alors de donner explicitement les deux règles de comportements [3]. Règle 1 : cause(A, B) ⋀ cause(B, C) → cause(A, C) Règle 2 : cause(A, B) ⋀ bloque(B, C) → bloque(A, C) La règle 1 veut dire que si A cause B, et si B cause C, alors A cause C. Similairement, la règle 2 veut dire que si A cause B, et si B bloque C, alors A bloque C. Conclusion conséquente et la production 35 Chapitre 2. Conclusion conséquente et la production 2.1. Conclusion conséquente et SOL 2.1.1. Conclusion conséquente La conclusion conséquente est la tâche de calcul des théorèmes entraînés par un ensemble d'axiomes [10]. Son importance réside dans le fait que les tâches de raisonnement sont des cas particuliers de conclusions conséquentes [11]. Par exemple, la démonstration d’un théorème est équivalente à démontrer que la clause vide est une conséquence logique des axiomes et de la négation du théorème à démontrer. Un autre exemple est le raisonnement abductif, qui consiste à construire des hypothèses, lorsqu’est ajoutée à une théorie donnée une série d'observations [16]. Mais la génération des hypothèses par raisonnement abductif est équivalente à nier les conséquences de la théorie et de la négation des observations. De cette façon, la conclusion conséquente fournit un cadre général pour résoudre une variété de problèmes de raisonnement [17]. La plupart des applications de conclusion conséquente exigent les théorèmes générés pour satisfaire certaines propriétés syntaxiques. Par exemple, dans la démonstration de théorèmes, la seule conséquence d'intérêt est la clause vide, tandis que, dans l'abduction, les conséquences doivent en général être broyant des clauses unitaires dont les prédicats sont parmi un ensemble d’abductibles. En outre, pour éviter de produire un nombre infini de clauses redondantes et intérêt, il est généralement nécessaire de générer uniquement les conséquences qui ne sont pas englobées par d'autres [18,19]. 2.1.2. SOL G. Bossu et P. Siegel ont présenté un algorithme basé sur la SL-résolution pour implémenter une logique non-monotone, la sub-implication [29,30]. Cet algorithme est basé sur la génération de clauses caractéristiques. En [26] les clauses caractéristiques sont généralisées par P. Siegel pour définir les champs de production et leurs propriétés [26,31]. La thèse de 1987 [26] donne aussi un algorithme de production qui est une méthode complète pour calculer toutes les clauses impliquées par un ensemble de clauses et appartenant à un champ de production. Ces travaux ont été repris par Inoue [12] pour proposer la SOLrésolution comme une méthode complète pour trouver les clauses caractéristiques d'une théorie. Ensuite, Iwanuma et al. [14] ont reformulé la SOL-résolution dans le cadre des tableaux de la connexion et proposé plusieurs méthodes de taille pour élaguer des branches redondantes de l'espace de recherche. Tableaux de la connexion : Dans la logique du premier ordre, une clause est un multiensemble de littéraux, écrite comme une disjonction L1 ∨ …∨ Ln. La clause vide est notée ∅. Un littéral L est général maximum, si les arguments de L sont des variables distinctes. Par exemple, p(X, Y, Z) est un littéral général maximum. Un soulignement «_» est utilisé pour représenter une variable distincte si le nom de la variable n'est pas nécessaire, par exemple, p(_, _, _). L'ensemble de toutes les instances d'un littéral L est défini comme inst(L). Pour un 36 Conclusion conséquente et la production ensemble de littéraux L = {L1,. . . , Ln}, alors inst(L) = inst(L1) ∪…∪inst(Ln). Le nombre d'éléments dans un ensemble S est noté |S|. Occ(e, S) est le nombre d'occurrences de e dans S. Le signe ⊆ms désigne la relation d'inclusion sur les multi-ensembles, c'est-à-dire S1 ⊆ms S2 si et seulement si Occ(e, S1) ≤ Occ(e, S2) pour tout e contenu dans S1 ou S2. Lorsque C et D sont des clauses, C subsume D s’il y a une substitution θ telle que Cθ ⊆ms D. C subsume correctement D si C subsume D mais D ne subsume pas C. Pour un ensemble Σ de clauses, μΣ désigne l'ensemble des clauses de Σ non subsumées correctement par une clause dans Σ. Th(Σ) représente l'ensemble des conséquences logiques de Σ. Les clauses caractéristiques sont destinées à représenter les clauses «intéressantes», et sont construites sur un sous-vocabulaire du langage sous-jacent appelé un champ de production. Définition 2.1: Un champ de production P est une paire (L, Cond), où L est un ensemble de littéraux et Cond est une condition veut être satisfaite. Si Cond n'est pas spécifié, P est juste noté (L). Une clause C appartient à P = (L, Cond) si chaque littéral dans C appartient à inst(L) et C satisfaite Cond. Pour un ensemble de clauses Σ, l'ensemble des conséquences logiques de Σ appartenant à P est noté Thp(Σ). Un champ de production P est stable si, pour deux clauses des C et D telles que C subsume D, la clause D appartient à P seulement si C appartient à P. Définition 2.2: Les clauses caractéristiques de Σ par rapport à P sont Carc(Σ, P) = μThp(Σ). Soit C une clause. Les nouvelles clauses caractéristiques de C par rapport à Σ et P sont Newcarc(Σ, C, P) = μ[Thp(Σ ∪ {C}) \ Th (Σ)]. Proposition 2.1: Une clause est une nouvelle clause caractéristique de C par rapport à Σ et P si et seulement si elle est la clause caractéristique de Σ ∪ {C} mais pas la clause caractéristique de Σ. À savoir, Newcarc (Σ, C, P) = Carc(Σ ∪ {C}, P) \ Carc(Σ, P). Soit F = C1∧…∧Cm comme une forme normale conjonctive (CNF) de formule. Alors, �������(∑, �, �) = µ ���������(∑� , �� , �) � �=1 � où Σ1 = Σ et Σi+1 = Σi ∪ {Ci} pour i = 1,…, m - 1. Noter que Σ n’est pas consistent si et seulement si Carc(Σ, P) = {∅} pour tout champ de production stable P = (L, Cond). Cela signifie que la conclusion de preuve est un cas particulier de conclusion conséquente. D'autre part, si Σ |≠ L (Σ n’entraîne pas L) et Σ |≠ ¬L (Σ n’entraîne pas ¬L) pour les littéraux L et ¬L appartenant à P, Carc(Σ, P) contient une tautologie L ∨ ¬L tant que L ∨ ¬L satisfait Cond. Les clauses caractéristiques Carc(Σ, P) peuvent être exprimées en utilisant progressivement les opérations Newcarc. Soit Taut(L) l'ensemble des tautologies de la forme L ∨ ¬L tel que L et ¬L appartiennent à inst (L). Alors, pour un ensemble Σ de clauses, une clause C et un champ de production stable P = (L, Cond), il vient que : Conclusion conséquente et la production 37 Carc(∅, P) = μ{T | T ∈ Taut(L) et T satisfait Cond}, Carc(Σ ∪ {C}, P) = μ[Carc(Σ, P) ∪Newcarc(Σ, C, P)]. Pour calculer Newcarc(Σ, C, P), SOL se concentre sur la seule production des théorèmes appartenant à P, et traite une clause C nouvellement ajoutée comme la clause de départ. Ces caractéristiques sont importantes pour la conclusion conséquente car la procédure peut directement déduire les théorèmes relatifs à l'information ajoutée. Définition 2.3: Un tableau de clauses T est un arbre ordonné étiqueté, où chaque nœud non racine de T est marqué par un littéral. Un nœud est défini avec son étiquette (soit un littéral) si aucune confusion ne se pose. Si les successeurs immédiats d'un nœud sont des littéraux L1,…, Ln, alors la clause L1 ∨…∨ Ln est appelé une clause de tableau. La clause de tableau en dessous de la racine est appelée la clause de départ. T est un tableau de clauses pour un ensemble Σ de clauses si chaque clause de tableau C en T est une instance d'une clause D dans Σ. Dans ce cas, D est appelé une clause d'origine de C dans Σ. Un tableau de connexion (serré) est un tableau de clauses tel que, pour chaque nœud nonfeuille L sauf la racine, il y a un successeur immédiat marqué avec ¬L. Un tableau marqué T est un tableau de clauses tel que des feuilles sont marquées avec des étiquettes fermé ou sauté. Les feuilles non marquées sont appelées sous-buts. Un nœud N dans T est dit être résolu si N lui-même est un nœud de feuille marqué ou tous les nœuds de feuilles de branches à N de T sont marqués. T est résolu si toutes les feuilles sont marquées. Sauté(T) désigne l'ensemble des littéraux de nœuds marqués sauté. Définition 2.4: Un tableau T est régulier si chaque nœud sur une branche en T est étiqueté avec un littéral différent. T est dit libre-tautologie si aucune clause de tableau en T n’est une tautologie. T est dit libre-complément si deux nœuds non-feuilles sur une branche en T ne sont jamais étiquetés avec des littéraux complémentaires. Un tableau T est sauté-régulier s’il n’y a pas de nœud L en T tel que ¬L ∈ sauté(T). T est TCS-libre (TCS-Tableau de Clauses Subsumées libre) pour un ensemble de clauses Σ si aucune clause tableau C en T n’est subsumée par une clause dans Σ autre que les clauses d'origine de C. Définition 2.5: Une fonction φ de sélection est une application attribution d'un sous-but à chaque tableau. φ est dite profondeur d'abord si φ choisit de tout tableau T un sous-but avec une profondeur maximale. φ est stable par substitution si, pour tout tableau T et toute substitution, φ(t) = φ(Tσ) où Tσ est le tableau qui est construit en appliquant σ à tous les littéraux de T. Définition 2.6: Soit Σ un ensemble de clauses, C une clause, P un champ de production, et φ une fonction de sélection. Un SOL-déduction dérivée d’une clause S de Σ + C et P via φ est constituée d'une séquence de tableaux T0, T1,…, Tn satisfaisant: (1) T0 se compose seulement de la clause de départ C. Tous les nœuds de feuille de T0 ne sont pas étiquetés. (2) Tn est un tableau résolu, et sauté(Tn) = S. 38 Conclusion conséquente et la production (3) Pour chaque Ti (i = 0, ..., n), Ti est régulier, libre-tautologie, libre-complément, sauté- régulier, et TCS-libre pour Σ ∪ {C}. (4) Pour chaque Ti (i = 0, ..., n), la clause sauté(Ti) appartient à P. (5) Ti+1 est construit à partir de Ti comme suit. Sélectionner un sous-but K par φ, puis appliquer une des règles suivantes à Ti pour obtenir Ti +1: (a) Si sauté(Ti) ∪ {K} appartient à P, alors marquer K avec sauté. (b) Si sauté(Ti) contient un littéral L, et K et L sont unifiables (K et L peuvent être l’inverse l’un de l’autre) avec θ, marquer K avec sauté, et appliquer θ à Ti . (c) Sélectionner une clause B de Σ ∪ {C} et obtenir une variante B’ = L1 ∨…∨ Lm en renommant. S’il y a un littéral Lj tel que ¬K et Lj sont unifiables avec θ, puis ajouter les nouveaux nœuds L1,…, Lm à K comme les successeurs immédiats. Ensuite, marquer Lj avec fermé et appliquer θ au tableau prolongée. (d) Si K a un nœud ancêtre L, et ¬K et L sont unifiables avec θ, alors marquer K avec fermé, et appliquer θ à Ti . Théorème 2.1: (Correction et exhaustivité de SOL) Pour toute fonction φ de sélection, ce qui suit s'applique: (1) Correction : S’il y a un SOL-déduction d'une clause S de Σ + C et P par φ, alors S appartient à Thp(Σ ∪ {C}). (2) Exhaustivité : Si une clause F n'appartient pas à Thp(Σ), mais appartient à Thp(Σ ∪ {C}), alors il existe une SOL-déduction d'une clause S de Σ + C et P par φ tels que S subsume F. Exemple 2.1: Une clause de départ C, un ensemble de clauses Σ et un champ de production P sont définis comme suit. Soit φ une fonction de sélection. C = p(X) ∨ s(X), Σ = {q(X) ∨ ¬p(X), ¬s(Y), ¬p(Z) ∨ ¬q(Z) ∨ r(Z)} P = (L+ , la longueur est inférieure à 2) La Figure 2.1 montre trois tableaux résolus qui sont dérivés par SOL-déduction sur Σ + C et P par φ. Dans le tableau Ta, le nœud p(X) est sauté depuis le littéral positif p(X) qui appartient à P, et s(X) est étendu à l'aide de la clause d’unité ¬s(Y). Noter que s(X) ne peut pas être sauté puisque le champ de production P limite la longueur maximale des conséquences à 1. La conséquence est sauté(Ta) = {p(X)}. Tb représente un autre tableau dérivé dont le nœud p(X) est prolongé par q(X) ∨ ¬p(X), et le nœud q(X) est sauté. La conséquence de Tb est sauté(Tb) = {q(X)}. Dans Tc, le nœud p(X) est prolongé par q(X) ∨ ¬p(X) et q(X) par ¬p(Z) ∨ ¬q(Z) ∨ r(Z) respectivement. Le nœud du bas ¬p(X) est fermé par réduction avec l'ancêtre p(X), et r(X) est sauté. La conséquence est sauté(Tc) = {r(X)}. Dans cet exemple, il y a six Conclusion conséquente et la production 39 tableaux résolus. Car les tableaux restés génèrent la même conséquence que Tc, ils sont redondants. Comme résultats, trois nouvelles clauses caractéristiques sont obtenues dans cet exemple : Newcarc(Σ, C, P) = {p(X), q(X), r(X)}. La tâche de conclusion conséquente est de trouver toutes les (nouvelles) clauses caractéristiques. Cela signifie que même si un tableau résolu est trouvé, il faut continuer à chercher d'autres tableaux résolus pour trouver toutes les clauses caractéristiques. En conclusion de preuve, le processus de calcul peut être arrêté immédiatement si une réfutation apparait. Ceci est la différence importante entre la conclusion conséquente et la conclusion de preuve. Définition 2.7: L'ensemble de SOL-dérivées de Σ + C et P par φ est: �(∑, �, �, ϕ) = {�|� ��� �é���é� ��������� ��� ���−�é������� �� ∑ + � �� � ��� ϕ} L'ensemble des clauses de production de Σ + C et P par φ est: Prod(Σ, C, P, φ) = μΔ(Σ, C, P, φ). Proposition 2.2: Pour toute fonction φ de sélection, Newcarc(Σ, C, P) = Prod(Σ, C, P, φ) - Thp(Σ). Afin de clarifier l'espace de recherche du processus de conclusion conséquente, l'arbre de recherche SOL est défini pour explicitement toutes les SOL-déductions possibles. p(X) s(X) ¬s(X) fermé Tb q(X) sauté ¬p(X) fermé p(X) sauté s(X) ¬s(X) fermé Ta Tc p(X) s(X) ¬s(X) fermé q(X) ¬p(X) fermé ¬p(X) fermé r(X) sauté ¬q(X) fermé réduction Figure 2.1 Tableaux résolus pour l’Exemple 2.1 40 Conclusion conséquente et la production Définition 2.8: L'arbre de recherche SOL de Σ + C et P par φ est un arbre T marqué avec les tableaux comme suit. Un nœud est identifié avec son étiquette (c'est à dire un tableau) si aucune confusion ne se pose: (1) La racine de T est un tableau qui se compose seulement de la clause de départ C. (2) Chaque nœud non-feuille N dans T a autant de nœuds successeurs qu’il existe d’applications réussies d'une étape d'inférence unique appliquée au sous-but sélectionné dans N par φ, et les nœuds successeurs de N sont les tableaux de résultantes respectives. La procédure conséquente de recensement SOL visite constructivement tous les nœuds dans l'arbre de recherche SOL, et énumère l'ensemble des clauses de production. Définition 2.9: La procédure conséquente de recensement SOL de Σ + C et P via φ est définie comme suit: (1) T0 est un tableau qui comprend seulement la clause de départ C, et Conqs est initialisée comme {} (Conqs est une variable globale). (2) Appeler la procédure EnumConqs(T0) dans la Figure 2.2. (3) Renvoyer l’ensemble de clauses de production Conqs. La correction de la procédure conséquente de recensement SOL tient évidemment par les définitions de clauses de production et d’EnumConqs. Proposition 2.3: Laisser Conqs être un ensemble de conséquences obtenues de la procédure conséquente de recensement SOL de Σ + C et P par φ. Alors, Conqs = Prod(Σ, C, P, φ). EnumConqs(T) T: un tableau Commencer si Conqs = {∅} alors revenir; fin / * trouvé la conséquence la plus générale * / si T est un tableau résolu alors C := sauté(T); / * trouvé une nouvelle conséquence * / Conqs := μ(Conqs ∪ {C}); / * supprimer conséquences non minimales * / revenir; fin K := φ(T); / * sélectionner un sous-but de T * / R := un ensemble de règles d'inférence qui sont applicables à K; pour chaque r ∈ R faire T’ := le tableau obtenu à partir de T en appliquant r de K; EnumConqs(T’) ; / * Correspondant à l'extension de l'arbre de recherche SOL * / fin fin Figure 2.2. La procédure conséquente de recensement SOL.Conclusion conséquente et la production 41 2.2. Production pour l’abduction et l’induction 2.2.1. Définition Selon la thèse de P.Siegel [26], une production PR de C (un ensemble des clauses) est une suite finie de couples . Chacun de ces couples est une étape (ou une inférence) de PR dans laquelle pi est une clause, la clause en production et Ai un arbre. Cette suite a les propriétés A, B et C : A. La première étape de PR est = <0, (l1) ... (lm)> où les lj sont tous les littéraux d’une même clause c de C, l’origine de la production. Chacun de ces littéraux apparaissant une et une seule fois. La clause en production est vide. B. La dernière étape est si An est l’arbre vide. La clause pn est alors la clause produite par la production. C. Si la k-ième (k = où (l s) est une branche de feuille l (le littéral à effacer), B un arbre et p la clause en production, alors l’étape suivante a l’une des forme C1 ou C2. C1. On met en production le littéral l si l’étape suivante est : C2. On effectue une résolution si l’étape suivante est : où les littéraux l’i sont tels que les conditions de C2a et de C2b sont vérifiées. C2a. Il existe une clause c’ de C, la clause appelée à cette étape, - qui contient l’opposé de l, - dont aucun littéral n’est dans la branche (l s) (les littéraux de cette branche sont les ascendants ou a-ancêtres) - dont aucun littéral n’a pour opposé une feuille de l’arbre B (les frères de l) - dont aucun littéral n’a pour opposé un littéral de la clause en production p (les littéraux de cette clause sont les littéraux en production). Les trois dernières conditions sont les conditions de non répétition. C2b. Les l’i sont alors les littéraux de cette clause c’, qui ne sont pas immédiatement effaçables, c’est à dire ceux : - dont l’opposé n’est pas dans la branche (l s), - qui ne sont pas égaux à une feuille de l’arbre B, - qui ne sont pas égaux à un littéral de la clause en production. 2.2.2. Exemple d’utilisation Soit l’ensemble C de cinq clauses : 42 Conclusion conséquente et la production ¬a b c ¬b d e f e ¬a ¬d c ¬c e f ¬e f g L’ensemble C ⋃ {a f} implique la clause f g et C ne l’implique pas. Il existe donc au moins une production d’origine a f qui produit f g. C’est par exemple le cas de : 1. <0 ,(a) (f)> 2. ¬a b c <0 ,(ba) (ca) (f)> 3. ¬b d e <0 ,(dba) (eba) (ca) (f)> 4. f e ¬a ¬d c <0 ,(eba) (ca) (f)> 5. ¬e f g <0 ,(geba) (ca) (f)> 6. 7. ¬c e f 8. ¬e f g 9. Pour visualiser globalement toutes les étapes d’une production, il est possible de faire un dessin du type : Figure 2.3. Les étapes d’une production 2.3. Champ de production La notion de champ de production dépassant le cadre restreint du calcul propositionnel, cette partie en donnera la définition dans le cadre général du calcul des prédicats. Une « formule » sera donc ici une formule de la logique du premier ordre et, bien entendu, une « formule propositionnelle » une formule du calcul propositionnel. 2.3.1. DéfinitionConclusion conséquente et la production 43 Définition 2.10: Un champ de production P est un ensemble de formules dont chacune est un résultat possible dont on a besoin de savoir s’il est vrai ou non dans un certain état de connaissance. Le but du jeu est de trouver les formules de cet ensemble vraies pour une connaissance donnée. Il s’agit donc d’une notion assez naturelle qui pourra se définir, correctement d’un point de vue logique, de manière simple. De manière très générale, deux problèmes se posent : Problème 2.1: Soit : - L un langage du premier ordre, - P un ensemble de formules de L, le champ de production, - C un ensemble de formules de L, la connaissance, Trouver l’ensemble, produites(C, P), des formules sémantiquement impliquées par C et appartenant à P. Si th(C) représente toutes les formules sémantiquement impliquées par C, on a donc : produites(C, P) = th(C) ∩ P Problème 2.2: Soit : - L, P, C définis comme précédemment, - C’ un nouvel ensemble de formules de L, la nouvelle connaissance, Trouver toutes les formules de P impliquées par C ⋃ C’, qui appartiennent à P et qui ne sont pas impliquées par C. Cet ensemble des formules se notera nouv-prod(C’, C, P) : nouv-prod(C’, C, P) = produites(C ⋃ C’, P) – produites(C, P). Définition 2.11: Si c1 et c2 sont des clauses, on dira que c1 est une sous clause de c2, ou que c1 subsume c2 si tout littéral de c1 est un littéral de c2. On dira également que c1 subsume strictement de c2 (est une sous clause stricte) si c1 subsume c2 et c2 ne subsume pas c1. Si F est un ensemble de formules qui ne sont pas des tautologies, et G un sous ensemble de F, on dit que : - G est un précurseur de F si toute formule de F est impliquée par une formule de G. « Pour toute f dans F il existe g dans G telle que g ⊨ f » 44 Conclusion conséquente et la production - G est un plus petit précurseur de F (ou précurseur minimal de F), si de plus aucune formule de G n’implique une autre formule de G. « Si G est un précurseur de F, et si g1 et g2 sont dans G et g1 ⊨ g2 alors g1 = g2 ». Propriété 2.1: Si G1 et G2 sont deux précurseurs minimaux de F, il existe une bijection bij de G1 dans G2 telle que, pour toute formule g1 de G1, il existe un unique g2 de G2 tel que g1 et bij(g2) sont logiquement équivalentes. Définition 2.12: Un champ de production P est stable pour l’implication sémantique si toute formule qui implique sémantiquement une formule de P est dans P. Propriété 2.2: Si P est un ensemble de clauses propositionnelles, alors P est stable si et seulement si toute sous clause d’une clause de P est dans P. 2.3.2. Exemple d’utilisation Si L est un langage propositionnel contenant une infinité de propositions p1, p2, ..., et si la connaissance est un ensemble de deux clauses : C = ¬p1⋁p2⋁p3 ‘si p1, alors p2 ou p3 est vrai’ p1 ‘p1 est vrai’ Si le champ de production est l’ensemble des clauses de L ne contenant que des littéraux positifs (clauses positives), on a : produites(C, P) = p1 ‘p1 est vrai’ p2⋁p3 ‘p2 ou p3 est vrai’ Si maintenant la nouvelle connaissance se compose des deux unaires : C’ = p4 ‘p4 est vrai’ ¬p3 ‘p3 est faux’ alors on obtient : nouv-prod(C’, C, P) = p4 ‘p4 est vrai’ p2 ‘p2 est vrai’Conclusion conséquente et la production 45 2.4. Algorithmes de calcul de production 2.4.1. Description simplifiée Notre problème pratique est dont de calculer toutes les clauses impliquées par un ensemble fini C de clauses et appartenant à un champ de production P. Comme P est en général très grand, il est évident que la technique consistant à vérifier, pour toute clause de P, si elle est impliquée par C ou non, est totalement inapplicable. Cette partie va étudier un algorithme basé sur la SOL résolution qui essaie de résoudre partiellement ce problème. Pour bien faire son travail, il doit s’arrêter, ne donner que des résultats corrects et donner tous les résultats. On s’assure de ceci en démontrant trois propriétés. Propriété 2.3: Un ensemble fini de clauses a un ensemble fini de productions (l’algorithme s’arrête). Propriété 2.4: Toute clause produite par une production de C est impliquée par C (les résultats sont valides). En particulier, si une production de C produit la clause vide, alors C est inconsistant. Propriété 2.5: Si une clause d est impliquée par C, il existe une production de C dont la clause produite subsume d (les résultats sont tous trouvés). En particulier, si C est inconsistant, il existe une production de C qui produit la clause vide. Propriété 2.6: Si C n’implique pas d et C ⋃ {c} implique d, il existe une production de C ⋃ {c}, d’origine c dont la clause produite subsume d. En particulier, si C ⋃ {c} est inconsistant, et C ne l’est pas, il existe une production de C d’origine c qui produit la clause vide. Il faut maintenant décrire l’algorithme qui génère toutes les clauses impliquées par un ensemble C de clauses et appartenant à un champ de production P. Cet algorithme a été implanté en SWI Prolog. Les clauses, branches et arbres sont représentés classiquement : - un littéral x s’écrira plus(x) s’il est positif et moins(x) s’il est négatif. - une liste de littéraux (clause ou branche) se notera de la manière habituelle l1. l2... ln. nil où nil représentant la liste vide. - un arbre est une liste s1. s2... sm. nil de branches. Les si sont donc des listes non vides de littéraux (donc différentes de nil). - un ensemble de clauses est identifié à une liste c1. c2... cp. nil de clauses.46 Conclusion conséquente et la production Description simplifiée : Pour produire les clauses impliquées par une liste C = c. C’ (c est une clause et C’ une liste de clauses éventuellement vide) appartenant à un champ de production P, il faut produire les clauses impliquées par C’ puis produire les clauses impliquées par c.C’ et non par C’. Pour ce faire on utilise le prédicat grande-production : grande-production(nil, P) → ; grande-production(c.C, P) → grande-production(C, P) construire-arbre(c, nil, nil, nil, A) production(nil, A, C, P) ; Le cœur de l’algorithme est la définition d’un prédicat à quatre arguments production(p, A, C, P), où p est la clause en production, A un arbre, C l’ensemble de clauses et P le champ de production. L’arbre A origine est donné par le prédicat construire-arbre, qui transforme la clause origine c = l1. l2... ln. nil en un arbre dont les branches sont composées d’un littéral de cette clause : A = (l1.nil).(l2.nil) .... (ln. nil).nil On définit production par trois clauses Prolog : (1) production(p, nil, C, P) → utiliser(p) ; (2) production(p, (l.s).B, C, P) → /* Forme C2*/ dans(c’, C) /* Prendre une clause c’ de C */ bonne-clause(c’, p, (l.s).B) /* Conditions C2a */ construire-arbre(c’, p, (l.s).B, B’) /* Construire l’arbre B’ à partir de la clause c’, conditions C2b*/ production(p, B’, C, P) ; (3) production(p, (l.s).B, C, P) → /* Forme C1*/ bon-debut-de-clause(l.p, P) /* l .p satisfaisante le champ de production P*/ production(l.p, B, C, P) ; dans(x, x.r) → ; dans(x, y.r) → dans(x,r) ; La clause (1) est le cas terminal d’une production. Ici, on l’ajoutera sous de forme d’une clause Prolog : clause-produite(p) → ; utiliser(p) → assert(clause-produite(p), nil) ;Conclusion conséquente et la production 47 Pour être en accord avec la définition, bonne-clause doit vérifier les conditions de non répétition. Il faut donc : 1- S’assurer que l’opposé de la feuille de la première branche de l’arbre est bien dans la clause candidate. 2- Vérifier que tous les littéraux de cette clause : - ne sont pas dans la première l.s de l’arbre, - n’ont pas leur opposé dans la clause en production p, - n’ont pas leur opposé égal à une feuille de l’arbre B. Ceci s’effectue de manière naturelle : bonne-clause(c’, p, (l.s).B) → oppose(l, l’) dans(l’, c’) bons-littéraux(c’, p, (l.s), B) bons-littéraux(nil, p, A) → ; bons-littéraux(l.r, p, s.B) → bons-littéraux(r, p, s.B) pas-dans(l, s) oppose(l, l’) pas-dans(l’, p) pas-dans-feuilles(l’, B) ; oppose(plus(x), moins(x)) → ; oppose(moins(x), plus(x)) → ; pas-dans(x, nil) → ; pas-dans(x, y.r) → dif(x, y) pas-dans(x, r) ; pas-dans-feuilles(x, nil) → ; pas-dans-feuilles(x, (l.s).B) → pas-dans(x, l.s) pas-dans-feuilles(x, B) ; 48 Conclusion conséquente et la production Il faut maintenant définir construire-arbre qui, à partir de la clause c’ = l1. l2... ln. nil de la clause en production p et de l’arbre (l.s).B va construire l’arbre A’ = (l’1.l.s) ... (l’p.l.s).B les l’i étant les littéraux de c’ non immédiatement effaçables. construire-arbre(nil, p, s.B, B) → ; construire-arbre(l.r, p, s.B, (l.s).B’) → /* Conditions C2a sont vérifiées*/ oppose(l, l’) pas-dans(l’, s) pas-dans(l, p) pas-dans-feuilles(l, B) / construire-arbre(r, p, s.B, B’) ; construire-arbre(l.r, p, A, A’) → /* Conditions C2a ne sont pas vérifiées*/ construire-arbre(r, p, A, A’) ; Pour vérifier qu’une clause est dans un champ de production défini par une quadruplé de bases quelconque, on peut écrire : bon-debut-de-clause(c, P.l-iste-P) → dans-le-champ(c, P) / ; bon-debut-de-clause(c, P.l-iste-P) → bon-debut-de-clause(c, l-iste-P) ; dans-le-champ(l.c, ) → eq(l, s-igne) dans(l, a-lpha) longueur-inferieure(l.c, l-ong) dans(c’, s-ous-cl) subsume(c, c’)Conclusion conséquente et la production 49 / ; subsume(nil, c) → / ; subsume(l.c’, c) → subsume(c’, c) dans(l, c) ; longueur-inferieure(c, infini) → / ; longueur-inferieure(nil, l) → ; longueur-inferieure(a.c, l) → / impasse ; longueur-inferieure(a.c, l) → val(sub(l, l), l’) longueur-inferieure(c, l’) ; 2.4.2. Algorithme avec coupure A toute étape de production, on essaie d’effacer le premier littéral de la première branche d’arbre (le littéral à effacer). Pour ce faire, il faut choisir une clause candidate contenant l’opposé de ce littéral et satisfaisant aux conditions de non répétition, en ôter tous les littéraux immédiatement effaçables (qui ne satisfont pas aux conditions C2b), puis essayer d’effacer la clause restante. Quand tous ces choix ont été effectués et résolus, il reste un choix supplémentaire qui est de mettre en production le littéral à effacer. Or, si le littéral à effacer a été, pour un certain choix, complètement effacé sans avoir eu besoin d’installer des littéraux en productions supplémentaires, il est inutile d’effectuer les choix restants. On peut formaliser ceci par une définition et une propriété. Définition 2.13: S’il existe un début de production, D, de dernière étape (j) : .............................. (i) .............................. 50 Conclusion conséquente et la production (j) telle que B1 = B2 et p1 = p2, on dira que le littéral l a été complètement effacé. Propriété 2.7: Dans ce cas toute production égale à D jusqu’à l’étape (i) incluse, ne pourra produire que des clauses subsumées par d’autres clauses produites par les productions de début D. Donc, d’après la structure de l’algorithme, qui à partir de l’étage (i+1), calcule toutes les productions ayant ces (i) premières étapes avant de faire les autres choix pour l à l’étape (i+1), il sera inutile si ce littéral est complètement effacé de faire ces autres choix. C’est principalement pour cette raison que l’on essaie d’abord d’effectuer toutes les résolutions possibles sur un littéral avant de mettre ce littéral en production (avant d’essayer d’effacer de manière classique un littéral, on regarde s’il n’existe pas une clause contenant son opposé et dont tous les littéraux sont immédiatement effaçables). Le choix inverse est possible mais donne de moins bons résultats. Démonstration : Soit PR1 une production égale à D jusqu’à (i). Cette production aura une étape (j’) dont l’arbre est B1, et peut donc s’écrire : .............................. (i) .............................. (j’) .............................. (n’) PR1 produit la clause p = r q p1 dans laquelle q et r sont des clauses éventuellement vides (la notation inclut le cas où j’ = n’). Pour prouver le théorème, il faut construire à partir de PR1 une production, PR2, dont le début est D et dont la clause produite subsume p. Le début de PR2 est donc : .............................. (i) .............................. (j) Conclusion conséquente et la production 51 L’important est que, à l’étape (j’) de PR1 et à l’étape (j) de PR2, les arbres sont égaux. À l’étape (j), la clause en production, p1, de PR2 est une sous clause de la clause en production à l’étape (j’), q p1, de PR1. Les étapes de PR2 qui suivent (j) sont construites à partir des étapes de PR1 qui suivent (j’) telles que, si la clause appelée contient un littéral de r q alors ce littéral n’est pas immédiatement effacé mais inséré dans l’arbre. Il sera mis en production à l’étape où il sera littéral à effacer de l’arbre courant. Plus précisément : 1. L’étape (j+1) de PR2 est construite à partir de l’étape (j’+1) de PR1 telle que : - si (j’+1) met en production le littéral à effacer, alors (j+1) mettra également en production ce même littéral à effacer. - si (j’+1) effectue une résolution sur une clause c, alors (j+1) effectuera également une résolution sur cette même clause c. Les branches ajoutées à l’arbre B1 (dans PR2) sont obtenues à partir des littéraux de c non immédiatement effaçables (dans PR1). Mais les littéraux de c immédiatement effaçables dans PR2, sont les littéraux de c immédiatement effaçables dans PR1, plus les littéraux de c, égaux à un des littéraux de q (les ascendants et frères sont les mêmes dans PR1 et PR2 car les arbres sont égaux à l’étape (i)). Donc les branches à ajouter dans PR2 sont les branches à ajouter dans PR1, plus éventuellement un certain nombre de branches dont les racines sont les littéraux de c qui ne sont pas dans q. 2. On répète l’opération pour les étapes suivantes de PR2, qui sont construites à partir des étapes de PR1. Les clauses appelées sont les mêmes dans PR1 et PR2. La seule différence est que dans les arbres correspondants (dans PR2) sont insérées un certain nombre de branches supplémentaires, branches dont les racines seront toujours des éléments de q. Quand le littéral à effacer (dans PR2) portera sur une de ces branches supplémentaires, ce littéral sera mis en production. On insère donc un certain nombre d’étapes qui sont toutes des mises en production de littéraux de q. La suite de couples ainsi formée est bien une production, car comme PR1 en est une, on en déduit que pour toutes les étapes de résolution de PR2 les clauses appelées satisfont aux conditions de non répétition. En effet, ces étapes sont telles que : - l’étape associée dans PR1 satisfait aux conditions de non répétition - les ascendants sont les mêmes dans PR1 et PR2 car ces étapes sont des étapes de résolution et ne portent donc pas sur les branches supplémentaires (on a dit que les étapes portant sur les branches supplémentaires mettent en production un littéral). - l’union des frères et littéraux en production de PR2 est incluse dans l’union des frères et littéraux en production de PR2. PR2 est donc bien une production et la clause produite par PR2 subsume bien celle produite par PR1 car les littéraux mis en production dans PR1 et non dans PR2 sont tous dans q. Exemple 2.2: Soit un ensemble de clause : 52 Conclusion conséquente et la production C = {a b c, ¬a b, ¬a u, ¬u v, ¬v w} On veut calculer toutes les productions d’origine a b c. L’algorithme construira, par ses appels récursifs, la première production qui produit la clause c b : 1. <0 ,(a) (b) (c)> 2. ¬a b <0 ,(b) (c)> 3. 4. Cette production est donnée par le choix de ¬a b à la deuxième étape. Il reste deux choix à cette étape : soit appeler la clause ¬a u, soit mettre a en production. En fait ces choix sont inutiles car ils ne pourront générer que des clauses subsumées par d’autres clauses produites par la production effectuée auparavant. Le premier choix donne trois productions dont la première est : 1. <0 ,(a) (b) (c)> 2. ¬a u <0 ,(ua) (b) (c)> 3. ¬u v <0 ,(vua) (b) (c)> 4. ¬v w <0 ,(wvua) (b) (c)> 5. 6. 7. En fait, c b w est subsumée par c b. 2.4.3. Algorithme en Prolog Pour produire les clauses d’un champ de production P impliquées par un ensemble C on appellera comme auparavant grande-production(C, P) : grande-production(nil, P) → ; grande-production(c.C, P) → grande-production(C, P) production(c, nil, nil, nil, p, C, P) utiliser(p) ; production(nil, A, B, p, p, C, P) → ; //le cas terminal production(l.c, A, B, p1, p3, C, P) → conc(c, B, B1) // B1=c.B, construire la liste des frères oppose(l, l’) dans(c1, C) dans(l’, c1) bonne-clause(c1, l.A, B1, p1) // Conditions C2a Conclusion conséquente et la production 53 simplifier-clause(c1, l.A, B1, p1, c2) // Conditions C2b, enlever les littéraux production(c2, l.A, B1, p1, p2, C, P) //Concaténant aux ascendants le littéral (p1 == p2 *→ !; true) //couper(p1, p2) production(c, A, B, p2, p3, C, P) ; //si p1 = p2 ou p1≠ p2 production(l.c, A, B, p1, p3, C, P) → //mettre en production si p1≠ p2 bon-debut-de-clause(l.p1, P) production(c, A, B, l.p1, p3, C, P) ; bonne-clause(nil, A, B, p) → ; bonne-clause(l.c, A, B, p) → pas-dans(l , A) oppose(l, l’) pas-dans(l’, B) pas-dans(l’, p) bonne-clause(c, A, B, p) ; simplifier-clause(nil, A, B, p, nil) → ; simplifier-clause(l.c, A, B, p, l.c’) → oppose(l, l’) pas-dans(l’, A) pas-dans(l, B) pas-dans(l, p) / simplifier-clause(c, A, B, p, c’) ; simplifier-clause(l.c, A, B, p, c’) → simplifier-clause(c, A, B, p, c’) ; conc(nil, y, y) → ; conc(a.x, y, a.z) → conc(x, y, z) ; Où : production(clause, ascendants, frères, produit-initiale, produit-finale, ensemble, champ) 54 Conclusion conséquente et la production - La clause à effacer, clause, est un bout d’une clause de c ∪ C qui contient le premier littéral (littéral à effacer). - ascendants est la liste des ascendants de ce premier littéral. - frères est la liste des frères de ce premier littéral, autres que les littéraux de clause. - A l’appel de production, produit-initiale donne la clause en production à ce moment. L’argument produit-finale donne alors la clause en production résultante. Pour que ces algorithmes travaillent avec les variables, il faut les améliorer. Par exemple, pour représenter l’idée : a est une protéine et b un substrat ; tous les substrats sont activés par les protéines, ceci doit être écrit dans la basée de données comme ci-dessous : proteine(a). substrat(b). ecrit :- proteine(X), substrat(Y), assert(clause(active(X,Y))). La logique des défauts 55 Chapitre 3. La logique des défauts 3.1. Introduction Quand un algorithme d’Intelligence Artificielle doit résoudre un problème, il peut être en mesure de s'appuyer sur des informations complètes. Sa tâche principale est alors de donner de bonnes conclusions par un raisonnement classique. Dans ce cas, la logique des prédicats peut être suffisante. Cependant, souvent l’information est incomplète, car certaines informations ne sont pas disponibles. Parfois, il peut aussi être nécessaire de répondre rapidement et il est alors impossible de recueillir toutes les données pertinentes en un temps raisonnable. Dans ce cas, le système doit faire des conjectures plausibles, c’est la problématique des logiques nonmonotones [7,9]. Pour la logique des défauts ces conjectures sont basées sur des règles empiriques, appelées défauts. Par exemple, un médecin d’urgence doit faire des conjectures sur les causes les plus probables des symptômes observés et il est impossible d'attendre le résultat de tests éventuellement étendus et chronophages avant le début du traitement. Lorsque les décisions sont fondées sur des hypothèses, elles peuvent se révéler fausses face à de nouvelles informations qui seront disponibles [13]. Par exemple les examens médicaux peuvent conduire à un diagnostic modifié. Il faut alors ajouter de nouvelles informations qui peuvent être contradictoires, avec les conclusions (le diagnostic) précédent. Cet ajout est impossible en logique classique, qui a la propriété de monotonie. Intuitivement cette propriété dit que si une conclusion C est déductible d’un ensemble de prémices P1, et que l’on ajoute des informations P2 à P1, alors C est démontrable de P1 et P2. Dans le cas de la logique du premier ordre P1, P2 et C sont des ensembles de formule et la propriété de monotonie s’écrit : P1 ⊢ C ⇒ P1 ⋃ P2 ⊢ C Si cette propriété n’est pas vérifiée, alors on a une logique non-monotone. La logique des défauts présentée par Reiter en 1980 est une des premières logiques non-monotones. Elle est très intéressante, car simple à comprendre et à utiliser. 3.2. Notion de défaut La logique des défauts définie par Reiter formalise le raisonnement par défaut. Elle permet de traiter les règles admettant des exceptions sans être obligé de remettre en cause les règles précédemment établies à chaque fois qu'une nouvelle exception apparaît. Une théorie des défauts est un couple {W, D} où W est un ensemble de formules classiques de la logique du premier ordre et D un ensemble de défauts, qui sont des règles d'inférence spécifiques. Les défauts permettent de gérer les informations incomplètes [8]. Par exemple, en hiver, une règle générale utilisée par les arbitres de football pourrait être : «Un match de football doit avoir lieu, à moins qu’il n’y ait de la neige sur le stade ». Cette règle de base est représentée par un défaut : 56 La logique des défauts ��������: ¬����� �����_���� L’interprétation du défaut est la suivante : si on n’a pas l’information explicite qu'il y aura de la neige dans le stade, il est raisonnable de supposer qu’il n’y aura pas de neige (¬neige) et de conclure que le match aura lieu. On peut donc préparer le match. Mais s’il y a une forte chute de neige pendant la nuit avant le match, cette hypothèse n’est plus valide. On sait qu'il y a de la neige, et il est donc impossible d’assumer ¬neige, donc le défaut ne peut pas être appliqué. Dans ce cas, il faut renoncer à la conclusion précédente (le match aura lieu). Le raisonnement est donc non-monotone. La logique classique n’est pas appropriée pour modéliser cette situation. En effet, on pourrait tenter d’utiliser la formule football ∧ ¬neige → avoir_lieu Le problème avec cette règle, c'est qu’il faut établir de façon définitive qu'il n'y aura pas de neige dans le stade avant d'appliquer la règle. Pour résoudre ce problème, le même exemple aurait pu être représenté par le défaut ��������: �����_���� �����_���� avec la règle de logique classique neige → ¬avoir_lieu. Si la neige est certaine alors on déduit ¬avoir_lieu par la logique classique, donc on ne peut pas inférer avoir_lieu par le défaut. Dans cette représentation, le défaut est une règle qui dit que les matchs se déroulent généralement et les exceptions de cette règle sont représentées par les règles classiques telles que celle ci-dessus. Les défauts peuvent être utilisés pour modéliser le raisonnement prototypique, ce qui signifie que la plupart des instances d’un concept ont une certaine propriété. Un exemple est l’énoncé « Typiquement, l’enfant a des parents (vivants) », qui peut être exprimé par le défaut : ������(�): �����_�������(�) �����_�������(�) Une autre forme de raisonnement par défaut est le raisonnement sans-risque. Il s'agit de situations où une conclusion peut être tirée, même si ce n'est pas le plus probable, car une autre décision peut conduire à une catastrophe. Par exemple « En l'absence de preuve contraire présumer que l'accusé est innocent, s’exprime par : �����é(�): ��������(�) ��������(�)La logique des défauts 57 On donne aussi des hiérarchies avec des exceptions qui sont en biologie. L’exemple classique est « En règle générale, les oiseaux volent », « les manchots sont les oiseaux », « les manchots ne volent pas ». On a alors le défaut: ������(�): ����(�) ����(�) avec la règle de logique classique : manchot(X) → oiseau(X)∧¬vole(X) Les défauts peuvent être aussi utilisés pour modéliser l’hypothèse du monde clos de Reiter, utilisée pour les bases de données et pour la programmation logique. Selon cette hypothèse, un domaine d’application est décrit par un ensemble de formules logiques F. En simplifiant, l’hypothèse du monde clos dit qu’une information élémentaire positive (un atome) ϕ est considéré comme faux si F n’implique pas logiquement ϕ. Ceci peut se représenter par un défaut normal sans prérequis : ����: ¬ϕ ¬ϕ On encore, s’il est consistant d’assumer ¬ϕ (ce qui est équivalent à ne pas avoir de preuve pour ϕ), on conclue ¬ϕ 3.3. Syntaxe de la logique des défauts. Une théorie des défauts ∆ = (D, W) est une paire (D, W), contenant un ensemble W de formules de la logique des prédicats (appelées faits ou axiomes) et un ensemble dénombrable D de défauts. Dans sa forme la plus générale, un défaut d s’écrit : � = �:�1,�2, … �� � où A, B1,…, Bn et C sont des formules logiques bien formées du premier ordre. La formule A est le prérequis, les formules B1,…, Bn sont les justifications et C est le conséquent. Un défaut signifie informellement : si A est vérifié, et s’il est possible que B1,…, Bn soient vrais alors C est inféré. Un défaut d est appelé normal si et seulement si sa justification est égale à son prérequis, donc s’il est de la forme : � = �: � � Un défaut peut contenir des variables libres, par exemple : ������(�): ����(�) ����(�)58 La logique des défauts Ces défauts sont appelés défauts ouverts. Dans ce cas le défaut ouvert est considéré comme l’ensemble des défauts où X a été remplacée par tous les termes terminaux (sans variables) du langage. Un défaut ouvert représente donc un ensemble de défauts fermés qui peut éventuellement être infini. 3.4. Extensions. L'utilisation des défauts augmente le nombre de formules déduites de la base de connaissance W : nous obtenons alors des extensions qui sont des ensembles de théorèmes dérivables de façon monotone. Intuitivement une extension est obtenue en utilisant un ensemble maximal consistant de défauts possibles. Cette définition va entrainer qu’il pourra exister plusieurs extensions éventuellement contradictoires. 3.4.1. Extensions - définition formelle. Une extension de la théorie des défauts ∆ = (D,W) est un ensemble E de formules, clos pour la déduction, contenant W et vérifiant la propriété suivante : si d est un défaut de D dont le prérequis est dans E, sans que la négation de sa justification soit dans E, alors le conséquent de d est dans E. Plus formellement, les extensions sont définies de la façon suivante. Définition 3.1: E est une extension de ∆ si et seulement si � = ⋃�=0,∞ �� , avec : 1) E0 = W 2) Pour tout i, ��+1 = �ℎ(�� ∪ {�/� = (�:� � ) ∈ �, � ∈ �� , ¬�∉�}) où Th(F) désigne l'ensemble des théorèmes obtenus en logique classique à partir de F, c’est à dire Th(F) = {w/F ⊢ w}. Remarque : Il est important de noter que E apparaît dans la définition de Ei+1. Donc dans le cas général il peut ne pas être possible de construire E car à cause de la condition ¬B ∉ E, il faut déjà connaître E pour construire E. La définition n’est donc pas constructive. Ceci peut être très gênant mais si l’on utilise uniquement des défauts normaux, la condition ¬B ∉ E se transforme en ¬B ∉ Ei . Cette fois, il suffit de vérifier que la négation de la justification n'appartient pas à Ei . Un algorithme récursif peut donc être utilisé pour calculer E. De plus lorsque tous les défauts sont normaux et que W est satisfaisable, l'existence d'au moins une extension est assurée. Exemple 3.1: Soit ∆ = (D, W), où W = {a}, et D contient les défauts normaux suivants : �1 = �:¬� ¬� �2 = �: � �La logique des défauts 59 On obtient avec la définition des extensions une extension E = Th({a, ¬b}) en utilisant le défaut d1. Dans ce cas d2 ne pas être utilisé car comme ¬b ∈ E, la justification de d2 n’est pas vérifiée. Exemple 3.2: C’est l’exemple classique. On sait que Les manchots sont des oiseaux et que Titi est un manchot. Ceci va s’exprimer par W composé de deux formules de la logique des prédicats : W = {∀x, Manchot(x) → Oiseau(x), Manchot(Titi)} On sait aussi que Sauf exception, les oiseaux volent et que Sauf exception, les manchots ne volent pas. On exprime ceci par un ensemble de deux défauts normaux D = {d1, d2} : d1 = Oiseau(x):Vole(x)/Vole(x) d2 = Manchot(x):¬Vole(x)/ ¬Vole(x) Le défaut d1 peut aussi s’exprimer par : Si x est un oiseau et qu'il est consistant de supposer que x peut voler, alors on conclue que x peut voler. On voit que si l’on utilisait les deux défauts en même temps on obtiendrait que Vole(Titi) et ¬Vole(Titi) ce qui est insatisfaisable. Pour cet exemple, on aura deux extensions. On a deux cas : Cas 1: Dans ce cas on va commencer à construite l’extension en utilisant le défaut d1 - On part de E0 = W = Th({Manchot(Titi) → Oiseau(Titi), Manchot(Titi), Oiseau(Titi)}) - On utilise alors d1. Le prérequis de d1, Oiseau(Titi) est dans E0. La négation de la justification de d1, ¬vole(Titi), n’est pas dans E0. Donc avec la définition d’une extension, on peut ajouter Vole(Titi) à E0 pour obtenir E1. E1 = Th({E0) ∪ Vole(Titi)}) - Ensuite on essaie d’utiliser d2 pour compléter E1. Le prérequis Manchot(Titi) est bien dans E1. Mais Vole(Titi) qui est la négation de la justification de d2, est dans E1. Il est impossible d’utiliser d2. Le calcul s’arrête et la première extension est E1. Dans cette extension, Titi vole. Cas 2: On va maintenant commencer la construction de l’extension en utilisant d2 - On part de E0 = W = Th({Manchot(Titi) → Oiseau(Titi), Manchot(Titi), Oiseau(Titi)}) - On utilise alors d2. Le prérequis de d2, Manchot(Titi) est dans E0. La négation de la justification de d2, Vole(Titi) n’est pas dans E0. Donc avec la définition d’une extension, on peut ajouter ¬Vole(Titi) à E0 pour obtenir E1. E1 = Th({E0) ∪ ¬Vole(Titi)}) - Ensuite on essaie d’utiliser d1 pour compléter E1. Le prérequis Manchot(Titi) est bien dans E1. Mais Vole(Titi) qui est la négation de la justification de d2, est dans E1. Il est impossible 60 La logique des défauts d’utiliser d2. Le calcul s’arrête et on a une deuxième extension dans laquelle Titi ne vole pas. Figure 3.1. Arbre de recherche des solutions pour le calcul d'extensions On obtient donc deux extensions qui sont contradictoires. Si nous cherchons à répondre à la question : "Est-ce que Titi vole ?", il faut pouvoir choisir entre ces deux extensions. On peut par exemple préférer les défauts les plus particuliers, ou encore établir des préférences entre les défauts. Comme nous venons de voir dans cet exemple, les théories des défauts peuvent avoir plusieurs extensions. Il y a également des cas où elles n’ont pas d’extension. Dans certains cas, ces défauts classiques peuvent donc poser des problèmes. Mais il est démontré qu’il existe toujours une extension si W est satisfaisable et tous les défauts sont normaux [23]. 3.6 Algorithme de calcul d’extensions. Avant de décrire l’algorithme, on généralise la définition d’une extension en considérant qu’un défaut peu avoir plusieurs prérequis. Pour que la logique des défauts travaille dans le domaine de temps discret, il faut ajouter un argument temporal ti . L’ensemble de faits W = {w1, w2, …} est représenté avec l’argument comme W = {(w1,t0), (w2,t0), …}. Une extension de la théorie des défauts ∆ = (D, W) est un ensemble E de formules, clos pour la déduction, contenant W et vérifiant la propriété suivante : si d est un défaut de D dont les prérequis A(X) (avec tk) sont dans E, sans que la négation des justifications Bi(X) ne soient dans E, alors le conséquent C(X) (avec tk+1) de d est dans E. Formellement, les extensions sont définies de la façon suivante : E est une extension de ∆ si et seulement si � = ⋃�=0,∞ �� , avec E0 = W (avec t0) et pour i >0, �� = �ℎ(��−1) ∪ {(�(�), t�+1)/( �(�):�� (X) �(�) ) ∈ �, (�(�), t� ), ∈ ��−1, ¬��(X)∉��−1} où Th(Ei-1) désigne l'ensemble des théorèmes obtenus de façon monotone à partir de ��−1: �ℎ(��−1) = {�/��−1├�}. La logique des défauts 61 Pour une théorie des défauts ∆ = (D, W), avec D l'ensemble des défauts et W la base de connaissance, le calcul d'extension se fait par l'algorithme : Entrée : D ; (ensemble des défauts). � = ∅; (ensemble d'extension). Sortie : � =∪�=0,� �� . calcul_extension(Ei) :{ Ei := W (en moment t0); tantque il y a un défaut � = �(�):�� (�) �(�) qui n'a pas encore été inspecté faire - Sélectionner ce défaut d, - Vérifier que les prérequis A(X) sont vrais avec Ei (en moment tk), - Vérifier que les justifications Bj(X) sont consistantes avec Ei (utiliser la négation par échec en cas d'inconsistance), - Ajouter (C(X), tk+1)) à Ei fin tantque Fin du calcul pour une extension. Backtracking (Suppression des (C(X), tk+1) ajoutés à Ei). calcul_extension(Ei). } Approche proposée et résultats 63 Chapitre 4. Approche proposée et résultats 4.1. Utilisation de l’algorithme de production de clauses. On revient à la carte d’interactions de Pommier. Pour passer du modèle biologique au modèle logique, il faut considérer plusieurs contraintes : comment modéliser les interactions, bien faire attention aux sens des implications logiques, respecter l'ordre chronologique préalablement défini et vérifier la cohérence des informations [15]. L'étape initiale est de définir correctement les prédicats. Ici les prédicats ont été calqués sur ceux de la carte de Pommier, à savoir stimulation, phosphorylation, autophosphorylation, inhibition, nécessité, liaison, activation de transcription, dégradation et déphosphorylation. Au départ, les prédicats ont été conceptualisés, pour la majorité d'entre eux, de la façon suivante : produit ⃪ réaction(enzyme, substrat). La réaction peut être stimulation, phosphorylation, déphosphorylation, liaison, activation ou dégradation. Par exemple, p*-Y ⃪ phosphorylation(X, Y). Les autres prédicats qui ne sont pas de type produit ⃪ réaction(enzyme, substrat) sont modélisés séparément : p*-Y ⃪ autophosphorylation(Y) ¬Y ⃪ inhibition(X, Y) : si X est vrai, alors Y ne peut pas l’être Y ⃪ nécessité(X, Y) : pour que Y soit vrai, X doit être vrai En effet, certains prédicats ont été modifiés, ou bien supprimés, au cours de l’implémentation, tandis que d’autres ont été rajoutés grâce aux mises à jours effectuées dans le modèle biologique et avec l’avancement de son implémentation dans Prolog. Par exemple, les prédicats ajoutés sont ubiquitination, méthylation et dissociation. Dans ce programme, cnf(nom_de_clause, type_de_clause, [littéraux]) indique une clause. Pour la partie contenant des littéraux, chaque disjonction doit être indiquée par une virgule, une négation par un signe moins, le signe plus peut être « oublié ». Voici un exemple qu’on souhaite mettre au format de Prolog : • D’abord, γH2AX se lie avec Mdc1. • Ensuite, ATM peut phosphoryler Mdc1 liée à γH2AX. • Mdc1, une fois phosphorylée, va se lier avec Rnf8. • Enfin, Rnf8 va se lier avec Ubc13. C’est modélisé par les équations logiques suivant les prédicats : • Produit(γH2AX) → liaison(γH2AX, MDC1). • Liaison(γH2AX, MDC1) → produit(γH2AX/MDC1). • Produit(γH2AX/MDC1) → phosphorylation(ATM, γH2AX/MDC1). • Phosphorylation(ATM, γH2AX/MDC1) → produit(p*-MDC1). • Produit(p*-MDC1) → liaison(p*-MDC1, MRF8).64 Approche proposée et résultats • Liaison(p*-MDC1, MRF8) → produit(MRF8_liée). • Produit(MRF8_liée) → liaison(MRF8_liée, UBC13). • Liaison(MRF8_liée, UBC13) → produit(MRF8/UBC13) De façon plus intuitive, ceci peut être présenté par l’image ci – dessous : Dans la Figure 4.1, une flèche à deux têtes présente une liaison, une flèche à une tête présente une production, et une flèche brisée est une phosphorylation. Suite, on replace les implications en utilisant les équivalences (A → B ≡ ¬A ⋁ B) : • ¬Produit(γH2AX) ⋁ liaison(γH2AX, MDC1). • ¬Liaison(γH2AX, MDC1) ⋁ produit(γH2AX/MDC1). • ¬Produit(γH2AX/MDC1) ⋁ phosphorylation(ATM, γH2AX/MDC1). • ¬Phosphorylation(ATM, γH2AX/MDC1) ⋁ produit(p*-MDC1). • ¬Produit(p*-MDC1) ⋁ liaison(p*-MDC1, MRF8). • ¬Liaison(p*-MDC1, MRF8) ⋁ produit(MRF8_liée). • ¬Produit(MRF8_liée) ⋁ liaison(MRF8_liée, UBC13). • ¬Liaison(MRF8_liée, UBC13) ⋁ produit(MRF8/UBC13) Enfin, on adapte les équations au format de Prolog : • cnf(mdc1_1, axiom, [-product(gamma_h2ax),binding(gamma_h2ax,mdc1)]). • cnf(mdc1_2, axiom, [-binding(gamma_h2ax,mdc1),product(h2ax_mdc1)]). • cnf(mdc1_3,axiom,[product(h2ax_mdc1), phosphorylation(p_atm_bound,h2ax_mdc1)]). • cnf(mdc1_4, axiom, [-phosphorylation(p_atm_bound,h2ax_mdc1),product(p_mdc1)]). • cnf(rnf_01, axiom, [-product(p_mdc1),binding(p_mdc1,rnf8)]). • cnf(rnf_02, axiom, [-binding(p_mdc1,rnf8),product(rnf8_bound)]). • cnf(rnf_03, axiom, [-product(rnf8_bound),binding(rnf8_bound,ubc13)]). • cnf(rnf_04, axiom, [-binding(rnf8_bound,ubc13),product(rnf8_ubc13)]). ATM γH2AX/MDC1 γH2AX MDC1 P*-MDC1 MRF8 MRF8_liée UBC13 MRF8/UBC13 Figure 4.1. Interactions de la carte de PommierApproche proposée et résultats 65 À partir de la carte, avec la modélisation, on a adapté la base de données au format de Prolog. Les lignes ci-dessous sont celles utilisées dans le modèle et qui relatent les événements biologiques précédemment indiques : /****************************************/ cnf(mrn_0, axiom, [-product(dsb),stimulation(dsb,dna)]). cnf(mrn_1, axiom, [-stimulation(dsb,dna),product(altered_dna)]). cnf(mrn_2, axiom, [-product(altered_dna),binding(mre11,rad50)]). cnf(mrn_3, axiom, [-binding(mre11,rad50),product(mre11_rad50)]). cnf(mrn_4, axiom, [-product(mre11_rad50),binding(mre11_rad50,nbs1)]). cnf(mrn_5, axiom, [-binding(mre11_rad50,nbs1),product(mrn)]). cnf(mrn_6, axiom, [-product(mrn),binding(mrn,altered_dna)]). cnf(mrn_7, axiom, [-binding(mrn,altered_dna),product(mrn_bound_to_dna)]). cnf(atm_1, axiom, [-product(mrn_bound_to_dna),binding(mrn_bound_to_dna,atm_atm)]). cnf(atm_2, axiom, [-binding(mrn_bound_to_dna,atm_atm),product(atm_bound_to_mrn)]). cnf(atm_3, axiom, [-product(atm_bound_to_mrn),-product(atm_atm)]). cnf(atm_4, axiom, [-product(atm_bound_to_mrn),autophosphorylation(atm_bound_to_mrn)]). cnf(atm_5, axiom, [-autophosphorylation(atm_bound_to_mrn),product(p_atm_atm_bound)]). cnf(atm_6, axiom, [-product(p_atm_atm_bound),-product(atm_atm)]). cnf(atm_7, axiom, [-product(p_atm_atm_bound),dissociation(p_atm_atm_bound)]). cnf(atm_8, axiom, [-dissociation(p_atm_atm_bound),product(p_atm_bound)]). cnf(atm_9, axiom, [-dissociation(p_atm_atm_bound),product(p_atm_free)]). %Chk1 Phosphorylation cnf(chk1_1, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,chk1)]). cnf(chk1_2, axiom, [-phosphorylation(p_atm_free,chk1),product(p_chk1)]). cnf(chk1_3, axiom, [phosphorylation(atr,chk1)]). cnf(chk1_4, axiom, [-phosphorylation(atr,chk1),product(p_chk1)]). %Other MRN needs cnf(mrn_add_1, axiom, [-product(mrn_bound_to_dna),product(p_smc1)]). cnf(mrn_add_2, axiom, [-product(mrn_bound_to_dna),product(p_mre11)]). %gamma-H2AX cnf(h2ax_1, axiom, [-phosphorylation(atr,h2ax),product(gamma_h2ax)]). cnf(h2ax_2, axiom, [-phosphorylation(p_atm_bound,h2ax),product(gamma_h2ax)]). %MDC1, Ubiquitination and BRCA1 cnf(mdc1_1, axiom, [-product(gamma_h2ax),binding(gamma_h2ax,mdc1)]). cnf(mdc1_2, axiom, [-binding(gamma_h2ax,mdc1),product(h2ax_mdc1)]). cnf(mdc1_3, axiom, [-product(h2ax_mdc1),phosphorylation(p_atm_bound,h2ax_mdc1)]). cnf(mdc1_4, axiom, [-phosphorylation(p_atm_bound,h2ax_mdc1),product(p_mdc1)]). cnf(rnf_01, axiom, [-product(p_mdc1),binding(p_mdc1,rnf8)]). cnf(rnf_02, axiom, [-binding(p_mdc1,rnf8),product(rnf8_bound)]). cnf(rnf_03, axiom, [-product(rnf8_bound),binding(rnf8_bound,ubc13)]). cnf(rnf_04, axiom, [-binding(rnf8_bound,ubc13),product(rnf8_ubc13)]). cnf(rnf_05, axiom, [-product(rnf8_ubc13),ubiquitination(rnf8_ubc13,h2a)]). cnf(rnf_06, axiom, [-ubiquitination(rnf8_ubc13,h2a),product(ub_h2a)]). cnf(rnf_07, axiom, [-product(ub_h2a),binding(ub_h2a,rnf168)]). cnf(rnf_08, axiom, [-binding(ub_h2a,rnf168),product(rnf168_bound)]). cnf(rnf_09, axiom, [-product(rnf168_bound),binding(rnf168_bound,ubc13)]). 66 Approche proposée et résultats cnf(rnf_10, axiom, [-binding(rnf168_bound,ubc13),product(rnf168_ubc13)]). cnf(rnf_11, axiom, [-product(rnf168_ubc13),ubiquitination(rnf168_ubc13,h2a)]). cnf(rnf_12, axiom, [-ubiquitination(rnf168_ubc13,h2a),product(poly_ub_h2a)]). cnf(rnf_13, axiom, [-product(poly_ub_h2a),stimulation(poly_ub_h2a,dna)]). cnf(rnf_14, axiom, [-stimulation(poly_ub_h2a,dna),product(changed_struct_dna)]). cnf(rap_01, axiom, [-product(poly_ub_h2a),binding(poly_ub_h2a,rap80)]). cnf(rap_02, axiom, [-binding(poly_ub_h2a,rap80),product(rap80_bound)]). cnf(rap_03, axiom, [-product(rap80_bound),binding(rap80_bound,abraxas)]). cnf(rap_04, axiom, [-binding(rap80_bound,abraxas),product(abraxas_bound)]). cnf(rap_05, axiom, [-product(abraxas_bound),binding(abraxas_bound,bre)]). cnf(rap_06, axiom, [-binding(abraxas_bound,bre),product(bre_bound)]). cnf(rap_07, axiom, [-product(abraxas_bound),binding(abraxas_bound,brcc36)]). cnf(rap_08, axiom, [-binding(abraxas_bound,brcc36),product(brcc36_bound)]). cnf(rap_09, axiom, [-product(brcc36_bound),binding(brcc36_bound,merit40)]). cnf(rap_10, axiom, [-binding(brcc36_bound,merit40),product(merit40_bound)]). cnf(rap_10, axiom, [-product(merit40_bound),binding(merit40_bound,brcc36_bound)]). cnf(rap_11, axiom, [-binding(merit40_bound,brcc36_bound),product(brcc36_merit40)]). cnf(rap_12, axiom, [-product(brcc36_merit40),binding(brcc36_merit40,brca1)]). cnf(rap_13, axiom, [-binding(brcc36_merit40,brca1),product(brca1_bound_to_rap80_complex)]). %53BP1 binding cnf(mmset_1, axiom, [-product(changed_struct_dna),phosphorylation(p_atm_bound,mmset)]). cnf(mmset_2, axiom, [-phosphorylation(p_atm_bound,mmset),product(p_mmset)]). cnf(mmset_3, axiom, [-product(h2ax_mdc1),binding(h2ax_mdc1,mdc1)]). cnf(mmset_4, axiom, [-binding(h2ax_mdc1,mdc1),product(mdc1_multi)]). cnf(mmset_5, axiom, [-product(mdc1_multi),-product(p_mmset),binding(mdc1_multi,p_mmset)]). cnf(mmset_6, axiom, [-binding(mdc1_multi,p_mmset),product(mmset_mdc1)]). cnf(mmset_7, axiom, [-product(mmset_mdc1),methylation(mmset_mdc1,h4)]). cnf(mmset_8, axiom, [-methylation(mmset_mdc1,h4),product(h4k20me2)]). cnf(p53bp1_1,axiom,[-product(h4k20me2),-product(brca1_bound_to_rap80_complex), binding(h4k20me2,p53bp1)]). cnf(p53bp1_2, axiom, [-binding(h4k20me2,p53bp1),product(p53bp1_bound)]). cnf(p53bp1_3, axiom, [-product(p53bp1_bound),phosphorylation(p_atm_bound,p53bp1_bound)]). cnf(p53bp1_4, axiom, [-phosphorylation(p_atm_bound,p53bp1_bound),product(p_53bp1)]). %Chk2 formation with Plk3 action (and binding with 53bp1) cnf(plk3_1, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,plk3)]). cnf(plk3_2, axiom, [-phosphorylation(p_atm_free,plk3),product(p_plk3)]). cnf(chk2_01, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,chk2)]). cnf(chk2_02, axiom, [-phosphorylation(p_atm_free,chk2),product(p_s33_35_chk2)]). cnf(chk2_03, axiom, [-product(p_s33_35_chk2),phosphorylation(p_plk3,p_s33_35_chk2)]). cnf(chk2_04, axiom, [-phosphorylation(p_plk3,p_s33_35_chk2),product(p_s33_35_s62_73_chk2)]). cnf(chk2_05,axiom,[-product(p_s33_35_s62_73_chk2), phosphorylation(p_atm_free,p_s33_35_s62_73_chk2)]). cnf(chk2_06, axiom, [-phosphorylation(p_atm_free,p_s33_35_s62_73_chk2),product(p_t68_chk2)]). cnf(chk2_07,axiom,[-product(p_s33_35_s62_73_chk2), phosphorylation(atr,p_s33_35_s62_73_chk2)]). cnf(chk2_08, axiom, [-phosphorylation(atr,p_s33_35_s62_73_chk2),product(p_t68_chk2)]). cnf(chk2_09, axiom, [-product(p_t68_chk2),binding(p_t68_chk2,p_t68_chk2)]). cnf(chk2_10, axiom, [-binding(p_t68_chk2,p_t68_chk2),product(chk2_chk2)]). cnf(chk2_11, axiom, [-product(chk2_chk2),autophosphorylation(chk2_chk2)]). cnf(chk2_12, axiom, [-autophosphorylation(chk2_chk2),product(p_active_chk2_chk2)]). cnf(chk2_13,axiom,[-product(p_active_chk2_chk2),-product(p_53bp1), binding(p_active_chk2_chk2,p_53bp1)]). Approche proposée et résultats 67 cnf(chk2_13, axiom, [-binding(p_active_chk2_chk2,p_53bp1),product(chk2_53bp1)]). %BRCA1 regulation by CtIP and Chk2 cnf(ctip_1, axiom, [binding(brca1,ctip)]). cnf(ctip_2, axiom, [-binding(brca1,ctip),product(brca1_ctip)]). cnf(ctip_3, axiom, [-product(brca1_ctip),-product(chk2_53bp1),binding(brca1_ctip,chk2_53bp1)]). cnf(ctip_4, axiom, [-binding(brca1_ctip,chk2_53bp1),product(chk2_53bp1_bound_to_brca1)]). cnf(ctip_5, axiom, [-binding(brca1_ctip,chk2_53bp1),product(brca1_ctip_bound_to_chk2)]). cnf(ctip_6,axiom,[-product(chk2_53bp1_bound_to_brca1),-product(brca1_ctip_bound_to_chk2), phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2)]). cnf(ctip_7,axiom,[-phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2), product(p_brca1_ctip_bound_to_chk2)]). cnf(ctip_8, axiom, [-product(p_brca1_ctip_bound_to_chk2),product(p_s988_brca_ctip)]). cnf(ctip_9, axiom, [-product(chk2_53bp1_bound_to_brca1),product(chk2_53bp1)]). cnf(brca1_0,axiom,[-product(p_s988_brca_ctip), phosphorylation(p_atm_bound,p_s988_brca_ctip)]). cnf(brca1_1, axiom, [-phosphorylation(p_atm_bound,p_s988_brca_ctip),product(brca_p_ctip)]). cnf(brca1_2, axiom, [-product(brca_p_ctip),-product(brca1_ctip)]). cnf(brca1_3, axiom, [-product(brca_p_ctip),dissociation(brca_p_ctip)]). cnf(brca1_4, axiom, [-dissociation(brca_p_ctip),product(brca1)]). cnf(brca1_5, axiom, [-dissociation(brca_p_ctip),product(p_ctip)]). cnf(brca1_6, axiom, [-product(brca1),phosphorylation(p_atm_bound,brca1)]). cnf(brca1_7, axiom, [-phosphorylation(p_atm_bound,brca1),product(p_brca1)]). cnf(brca1_8, axiom, [-product(brca1),phosphorylation(atr,brca1)]). cnf(brca1_9, axiom, [-phosphorylation(atr,brca1),product(p_brca1)]). %DNA repair proposed mecasism cnf(repa_1, axiom, [-product(p_brca1),-product(p_53bp1),binding(mrn_bound_to_dna,p_brca1)]). cnf(repa_2, axiom, [-binding(mrn_bound_to_dna,p_brca1),product(brca1_bound_to_mrn)]). %p53 pathway and regulation including PML cnf(pml_1, axiom, [-product(chk2_53bp1),phosphorylation(chk2_53bp1,pml)]). cnf(pml_2, axiom, [-phosphorylation(chk2_53bp1,pml),product(p_pml)]). cnf(pml_3, axiom, [-product(p_pml),stimulation(p_pml,cell)]). cnf(pml_4, axiom, [-stimulation(p_pml,cell),product(apoptosis)]). cnf(pml_5, axiom, [-product(p_pml),binding(p_pml,mdm2)]). cnf(pml_6, axiom, [-binding(p_pml,mdm2),product(pml_mdm2)]). cnf(pml_7, axiom, [-product(pml_mdm2),-binding(mdm2,p53)]). cnf(mdm2_1, axiom, [product(p53)]). cnf(mdm2_2, axiom, [-product(mdm2),-product(p53),binding(mdm2,p53)]). cnf(mdm2_3, axiom, [-binding(mdm2,p53),product(mdm2_p53)]). cnf(mdm2_4, axiom, [-product(mdm2_p53),stimulation(p53_degradation_effectors,mdm2_p53)]). cnf(mdm2_5,axiom,[-stimulation(p53_degradation_effectors,mdm2_p53), product(p53_degradation)]). cnf(p53_01,axiom,[-product(p_atm_free),-product(mdm2_p53), phosphorylation(p_atm_free,mdm2_p53)]). cnf(p53_02, axiom, [-phosphorylation(p_atm_free,mdm2_p53),product(p_s15_p53_mdm2)]). cnf(p53_03, axiom, [-product(mdm2_p53),phosphorylation(atr,mdm2_p53)]). cnf(p53_04, axiom, [-phosphorylation(atr,mdm2_p53),product(p_s15_p53_mdm2)]). cnf(p53_05,axiom,[-product(p_s15_p53_mdm2),-product(chk2_53bp1), phosphorylation(chk2_53bp1,p_s15_p53_mdm2)]). cnf(p53_06, axiom, [-phosphorylation(chk2_53bp1,p_s15_p53_mdm2),product(p_p_p53_mdm2)]). cnf(p53_07,axiom,[-product(p_s15_p53_mdm2),-product(p_chk1), phosphorylation(p_chk1,p_s15_p53_mdm2)]). 68 Approche proposée et résultats cnf(p53_08, axiom, [-phosphorylation(p_chk1,p_s15_p53_mdm2),product(p_p_p53_mdm2)]). cnf(p53_09, axiom, [-product(p_s15_p53_mdm2),-product(p53_degradation)]). cnf(p53_10, axiom, [-product(p_p_p53_mdm2),-product(p53_degradation)]). cnf(p53_11, axiom, [-product(p_p_p53_mdm2),dissociation(p_p_p53_mdm2)]). cnf(p53_12, axiom, [-dissociation(p_p_p53_mdm2),product(p_p_p53)]). cnf(p53_13, axiom, [-dissociation(p_p_p53_mdm2),product(mdm2)]). cnf(p53_14, axiom, [-product(p_atm_free),-product(mdm2),phosphorylation(p_atm_free,mdm2)]). cnf(p53_15, axiom, [-phosphorylation(p_atm_free,mdm2),product(p_mdm2)]). cnf(p53_16, axiom, [-product(p_p_p53),binding(p300,p_p_p53)]). cnf(p53_17, axiom, [-product(p_pml),-binding(p300,p_p_p53),product(active_p53)]). cnf(p53_18,axiom,[-product(active_p53), transcription_activation(active_p53,prom_p21_gadd45)]). cnf(p53_19,axiom,[-transcription_activation(active_p53,prom_p21_gadd45), product(p21_and_gadd45)]). cnf(p53_19a, axiom, [-product(p21_and_gadd45),stimulation(p21_and_gadd45,cell_cycle)]). cnf(p53_20, axiom, [-stimulation(p21_and_gadd45,cell_cycle),product(cell_cycle_arrest)]). cnf(p53_21, axiom, [-product(active_p53),transcription_activation(active_p53,prom_bnpf)]). cnf(p53_22,axiom,[-transcription_activation(active_p53,prom_bnpf), product(box_nas_puma_fas)]). cnf(p53_23, axiom, [-product(box_nas_puma_fas),stimulation(box_nas_puma_fas,cell)]). cnf(p53_24, axiom, [-stimulation(box_nas_puma_fas,cell),product(apoptosis)]). cnf(p53_21, axiom, [-product(active_p53),transcription_activation(active_p53,prom_mdm2)]). cnf(p53_22, axiom, [-transcription_activation(active_p53,prom_mdm2),product(mdm2)]). %E2F1 action cnf(e2f1_00, axiom, [product(e2f1)]). cnf(e2f1_01, axiom, [-product(e2f1),-product(chk2_53bp1),phosphorylation(chk2_53bp1,e2f1)]). cnf(e2f1_02, axiom, [-phosphorylation(chk2_53bp1,e2f1),product(p_e2f1)]). cnf(e2f1_03, axiom, [-product(e2f1),stimulation(e2f1_degradation_effectors,e2f1)]). cnf(e2f1_04, axiom, [-stimulation(e2f1_degradation_effectors,e2f1),product(e2f1_degradation)]). cnf(e2f1_05, axiom, [-product(p_e2f1),-product(e2f1_degradation)]). cnf(e2f1_06, axiom, [-product(p_e2f1),phosphorylation(p_atm_free,p_e2f1)]). cnf(e2f1_07, axiom, [-phosphorylation(p_atm_free,p_e2f1),product(p_p_e2f1)]). cnf(e2f1_08, axiom, [-product(p_e2f1),phosphorylation(atr,p_e2f1)]). cnf(e2f1_09, axiom, [-phosphorylation(atr,p_e2f1),product(p_p_e2f1)]). cnf(e2f1_10, axiom, [-product(p_p_e2f1),transcription_activation(p_p_e2f1,prom_chk2)]). cnf(e2f1_11, axiom, [-transcription_activation(p_p_e2f1,prom_chk2),product(chk2)]). cnf(e2f1_12, axiom, [-product(p_p_e2f1),transcription_activation(p_p_e2f1,prom_arf)]). cnf(e2f1_13, axiom, [-transcription_activation(p_p_e2f1,prom_arf),product(arf)]). cnf(e2f1_14, axiom, [-product(p_p_e2f1),transcription_activation(p_p_e2f1,prom_p73_apaf1)]). cnf(e2f1_15, axiom, [-transcription_activation(p_p_e2f1,prom_p73_apaf1),product(p73_apaf1)]). cnf(e2f1_16, axiom, [-product(p73_apaf1),stimulation(p73_apaf1,cell)]). cnf(e2f1_17, axiom, [-stimulation(p73_apaf1,cell),product(apoptosis)]). cnf(e2f1_18, axiom, [-product(arf),binding(arf,mdm2)]). cnf(e2f1_19, axiom, [-binding(arf,mdm2),product(arf_mdm2)]). cnf(e2f1_20, axiom, [-product(arf_mdm2),-product(mdm2_p53)]). cnf(e2f1_21, axiom, [-product(p_p_e2f1),stimulation(p_p_e2f1,unknown_atm_way)]). cnf(e2f1_22, axiom, [-stimulation(p_p_e2f1,unknown_atm_way),product(p_atm_free)]). %p38 phosphorylation (usefull for cdc25c and cdc25b) cnf(p38_1, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,p38)]). cnf(p38_2, axiom, [-phosphorylation(p_atm_free,p38),product(p_p38)]). %Cdc25 regulation cnf(cdc25a_0, axiom, [-stimulation(cdc25a,cell),-product(cell_cycle_arrest)]).Approche proposée et résultats 69 cnf(cdc25a_1, axiom, [-product(chk2_53bp1),phosphorylation(chk2_53bp1,cdc25a)]). cnf(cdc25a_2, axiom, [-phosphorylation(chk2_53bp1,cdc25a),product(p_cdc25a)]). cnf(cdc25a_3, axiom, [-product(p_chk1),phosphorylation(p_chk1,cdc25a)]). cnf(cdc25a_4, axiom, [-phosphorylation(p_chk1,cdc25a),product(p_cdc25a)]). cnf(cdc25a_5, axiom, [-product(p_cdc25a),stimulation(p_cdc25a,cdc25a_degradation_effectors)]). cnf(cdc25a_6,axiom,[-stimulation(p_cdc25a,cdc25a_degradation_effectors), product(cdc25a_degradation)]). cnf(cdc25a_7, axiom, [-product(cdc25a_degradation),-stimulation(cdc25a,cell)]). cnf(cdc25c_00, axiom, [-stimulation(cdc25c,cell),-product(cell_cycle_arrest)]). cnf(cdc25c_01, axiom, [-product(chk2_53bp1),phosphorylation(chk2_53bp1,cdc25c)]). cnf(cdc25c_02, axiom, [-phosphorylation(chk2_53bp1,cdc25c),product(p_cdc25c)]). cnf(cdc25c_03, axiom, [-product(p_plk3),phosphorylation(p_plk3,cdc25c)]). cnf(cdc25c_04, axiom, [-phosphorylation(p_plk3,cdc25c),product(p_cdc25c)]). cnf(cdc25c_05, axiom, [-product(p_chk1),phosphorylation(p_chk1,cdc25c)]). cnf(cdc25c_06, axiom, [-phosphorylation(p_chk1,cdc25c),product(p_cdc25c)]). cnf(cdc25c_07, axiom, [-product(p_p38),phosphorylation(p_p38,cdc25c)]). cnf(cdc25c_08, axiom, [-phosphorylation(p_p38,cdc25c),product(p_cdc25c)]). cnf(cdc25c_09, axiom, [-product(p_cdc25c),stimulation(p_cdc25c,cdc25c_degradation_effectors)]). cnf(cdc25c_10,axiom,[-stimulation(p_cdc25c,cdc25c_degradation_effectors), product(cdc25c_degradation)]). cnf(cdc25c_11, axiom, [-product(cdc25c_degradation),-stimulation(cdc25c,cell)]). cnf(cdc25b_1, axiom, [-stimulation(cdc25b,cell),-product(cell_cycle_arrest)]). cnf(cdc25b_2, axiom, [-product(p_p38),phosphorylation(p_p38,cdc25b)]). cnf(cdc25b_3, axiom, [-phosphorylation(p_p38,cdc25b),product(p_cdc25b)]). cnf(cdc25b_4, axiom, [-product(p_cdc25b),-stimulation(cdc25b,cell)]). %JNK actions (mechanisms quite unclear) cnf(jnk_1, axiom, [-stimulation(jnk,cdc25c),product(p_cdc25c)]). cnf(jnk_2, axiom, [-phosphorylation(jnk,p_s15_p53_mdm2),product(p_p_p53_mdm2)]). %FANCD2 first steps cnf(fancd2_1, axiom, [-product(p_atm_bound),phosphorylation(p_atm_bound,nbs1)]). cnf(fancd2_2, axiom, [-phosphorylation(p_atm_bound,nbs1),product(p_nbs1)]). cnf(fancd2_3, axiom, [-product(p_nbs1),phosphorylation(p_atm_bound,fancd2)]). cnf(fancd2_4, axiom, [-phosphorylation(p_atm_bound,fancd2),product(p_fancd2)]). cnf(fancd2_5, axiom, [-product(p_fancd2),stimulation(p_fancd2,cell)]). cnf(fancd2_6, axiom, [-stimulation(p_fancd2,cell),-product(cell_cycle_arrest)]). %Mus81 actions on DNA Repair cnf(mus81_1, axiom, [-product(chk2_53bp1),binding(chk2_53bp1,mus81)]). cnf(mus81_2, axiom, [-binding(chk2_53bp1,mus81),product(mus81_chk2)]). cnf(mus81_3, axiom, [-product(mus81_chk2),binding(mus81_chk2,altered_dna)]). cnf(mus81_4, axiom, [-binding(mus81_chk2,altered_dna),product(mus81_bound_to_dna)]). %cnf(mus81_5, axiom, [-binding(mus81_chk2,altered_dna),product(mus81_bound_to_dna)]). /****************************************/ Le résultat : Avec le champ de production champ([_,1,[stimulation(_,_)],_]), après l’exécution de programme, le résultat est donné Pour activer product(cell_cycle_arrest): -stimulation(p21_and_gadd45,cell_cycle) 70 Approche proposée et résultats % 261,290 inferences, 0.156 CPU in 20.794 seconds (1% CPU, 1674925 Lips) Pour bloquer product(cell_cycle_arrest) : -stimulation(cdc25a,cell) -stimulation(cdc25c,cell) -stimulation(cdc25b,cell) -stimulation(dsb,dna) -stimulation(p_fancd2,cell) % 18,008 inferences, 0.047 CPU in 7.993 seconds (1% CPU, 384784 Lips) Pour activer product(apoptosis) : -stimulation(p_pml,cell) -stimulation(box_nas_puma_fas,cell) -stimulation(p73_apaf1,cell) % 154,139 inferences, 0.094 CPU in 20.310 seconds (0% CPU, 1646774 Lips) Pour bloquer product(apoptosis), le résultat est un ensemble vide de clauses. 4.2. Utilisation de la logique des défauts 4.2.1. Dans le cas général La Figure 4.2 représente un exemple très simplifié d'interactions dans une cellule. Figure 4.2. Un exemple d’interactions dans une celluleApproche proposée et résultats 71 Par des mécanismes divers non indiqués ici, les ultraviolets (UV) mettent la cellule en apostase (elle devient de fait immortelle) d'où le cancer. Ceci est représenté par une flèche. D'un autre coté les UV activent la production de la protéine p53. Cette protéine va activer une protéine A qui va bloquer le cancer. Mais p53 liée à la protéine Mdm2 va produire B, qui va bloquer A. Pour un biologiste, la question est donc de bloquer le cancer en bloquant B. Les expériences biologiques ont montré que le X pourrait être un candidat pour ce blocage. Les figures (b) et (c) donnent deux types d'interactions possibles avec X pour expliquer ce blocage de B. Le problème est d'utiliser l'informatique pour compléter le graphe [3]. Pour décrire les interactions entre les gênes dans la figure, on part d’un langage L de logique classique (propositionnel ou du premier ordre). Dans L, la proposition A (resp ¬A) signifie que A est vrai (faux). Les interactions entres les gênes sont une forme très simple de causalité. Pour exprimer ces interactions il est courant d'aller à l'essentiel en donnant deux relations binaires cause(A, B) et bloque(A, B). La première relation veut dire, par exemple, qu'une protéine A déclenche la production d'une protéine B, la deuxième est l’inhibition. De manière classique, ces relations sont représentées dans le réseau de gênes, par A → B et A ⊣ B. Bien entendu, ces causalités sont élémentaires et de nombreux travaux très savants ont été écrits pour les représenter. Pour représenter les liens entre les relations, dans le langage L, il faut faire deux choses : décrire les propriétés internes aux relations cause et bloque ; décrire les liens entre ces relations. Les premières propriétés que l’on a envie de donner peuvent s’exprimer naturellement, par des règles du type : (1) Si A cause B et si A est vrai, alors B est vrai. (2) Si A bloque B et si A est vrai, alors B est faux. La solution élémentaire est alors de donner explicitement les deux schémas d'axiomes : (C1) cause(A,B) ∧ cause(B, C) → cause(A, C) (C2) cause(A, B) ∧ bloque (B, C) → bloque(A, C) La première idée est d'exprimer ces lois en logique classique par les axiomes : cause(A, B) ∧ A → B bloque(A, B) ∧ A → ¬B On peut aussi les exprimer plus faiblement par des règles d'inférences proches du modus ponens : cause(A, B) ∧ A / B bloque(A, B) ∧ A / ¬B72 Approche proposée et résultats Mais ces deux formulations posent problème dès qu'il y a conflit. Si par exemple on a un ensemble F de quatre formules F = {A, B, cause(A, C), bloque(B, C)}, alors on va dans les deux approches données ci-dessus inférer de F, C et ¬C ce qui est inconsistant. Pour résoudre ce conflit, on peut utiliser la logique des défauts. Pour résoudre les conflits vus ci-dessus, l'idée intuitive est d'affaiblir la formulation des règles de causalité en : (1') Si A cause B, et si A est vrai, et s'il est possible que B est vrai, alors B est vrai. (2') Si A bloque B, et si A est vrai, et s'il est possible que B est faux, alors B est faux. Dans la logique des défauts, les règles (1') et (2') vont s'exprimer intuitivement. (1") Si A cause B, et si A est vrai, et si B n'est pas contradictoire, alors B est vrai. (2") Si A bloque B, et si A est vrai, et si ¬B n'est pas contradictoire, alors ¬B est vrai. Ces règles vont se représenter par des défauts normaux et s'écrire : d1 : cause(A, B) ∧ A : B / B d2 : bloque(A, B) ∧ A : ¬B / ¬B Pour le cas élémentaire qui précède, si A et B sont vrais, on a : W = {A, B, cause(A,C), bloque(B,C)} D = {d1, d2} et on obtient deux extensions : E1 contient C (en appliquant d1) E2 contient ¬C (en appliquant d2) Le conflit est donc résolu, mais se pose le problème des extensions à préférer ; est-ce que C est induit ou bloqué? En fait ceci va vraiment dépendre du contexte. On peut par exemple préférer les interactions positives par rapport aux négatives ; ou bien utiliser des méthodes statistiques ou probabilistes. Plus en détail, pour l’application, on a [28]: W = {UV, Mdm2} D = { d1 = UV : cancer / cancer d2 = UV : p53 / p53 d3 = p53 : A / A d4 = p53 ∧ Mdm2: B / BApproche proposée et résultats 73 d5 = B : ¬A / ¬A d6 = A : ¬cancer / ¬cancer d7 = C : ¬B / ¬B } On a encore deux défauts généraux : d8 = Y : x /x ; où Y ∈ {UV, Mdm2} et d9 = Z ∧ x: C / C; où Z ∈ {UV, Mdm2, p53, A, B} Comme on a dit précédemment, pour que l’algorithme travaille avec des variables, il faut l’améliorer. Dans ce cas, les défauts d8 et d9 peuvent être écrits : source(uv). % UV est une source source(mdm2). substance(uv). % UV est une substance substance(mdm2). substance(p53). substance(a). substance(b). ecrit: source(Y), % « ordre 1 » assert(cl(def(Y,x))), % « ordre 2 » substance(Z), % « ordre 3 » assert(cl(def(joint(Z,x),c))). % « ordre 4 » où « ordre 1 » et « ordre 2 » peuvent dire : pour toutes les sources Y, ajouter les défauts Y:x/x à la base de données ; « ordre 3 » et « ordre 4 » peuvent dire : pour toutes les substances Z, ajouter les défauts Z∧ x:C/C à la base de données. En utilisant l’algorithme de calculer des extensions, on a 18 extensions cidessous (l’extension 12 correspond à la Figure 4.2-b, et l’extension 13 correspond à la Figure 4.2-c) : EXTENSION 1: uv -> p53 p53 -> a74 Approche proposée et résultats joint(p53,mdm2) -> b uv -> x joint(uv,x) -> c a -> -cancer EXTENSION 2: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(mdm2,x) -> c a -> -cancer EXTENSION 3: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(p53,x) -> c a -> -cancer EXTENSION 4: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(a,x) -> c a -> -cancer EXTENSION 5: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(b,x) -> c a -> -cancer EXTENSION 6: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(uv,x) -> c a -> -cancerApproche proposée et résultats 75 EXTENSION 7: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(mdm2,x) -> c a -> -cancer EXTENSION 8: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(p53,x) -> c a -> -cancer EXTENSION 9: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(a,x) -> c a -> -cancer EXTENSION 10: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(b,x) -> c a -> -cancer EXTENSION 11: uv -> p53 p53 -> a uv -> x joint(uv,x) -> c c -> -b a -> -cancer EXTENSION 12: uv -> p53 p53 -> a uv -> x joint(mdm2,x) -> c76 Approche proposée et résultats c -> -b a -> -cancer EXTENSION 13: uv -> p53 p53 -> a uv -> x joint(p53,x) -> c c -> -b a -> -cancer EXTENSION 14: uv -> p53 p53 -> a uv -> x joint(a,x) -> c c -> -b a -> -cancer EXTENSION 15: uv -> p53 p53 -> a mdm2 -> x joint(uv,x) -> c c -> -b a -> -cancer EXTENSION 16: uv -> p53 p53 -> a mdm2 -> x joint(mdm2,x) -> c c -> -b a -> -cancer EXTENSION 17: uv -> p53 p53 -> a mdm2 -> x joint(p53,x) -> c c -> -b a -> -cancer EXTENSION 18: uv -> p53 Approche proposée et résultats 77 p53 -> a mdm2 -> x joint(a,x) -> c c -> -b a -> -cancer % 599,907 inferences, 1.700 CPU in 2.402 seconds (71% CPU, 352801 Lips) 4.2.2. Utilisation dans le domaine temporel discret Bien que les cellules aient des morphologies et des structures différentes et que leurs rôles dans les organismes différents soient variés, leurs fonctionnalités de base sont les mêmes [1,4]. Une de ces fonctionnalités est d'assurer la survie de la cellule. Cette activité dans son ensemble peut être résumée en deux points [21]. Premièrement, une cellule a besoin de trouver l'énergie nécessaire pour son activité. Cette énergie est principalement obtenue par la dégradation des ressources minérales ou organiques, c’est le catabolisme. Deuxièmement, les cellules doivent fabriquer les molécules simples nécessaires à leur survie, c’est l’anabolisme. Ces deux grandes activités sont regroupées sous le nom de métabolisme, et résultent d'un grand nombre de mécanismes et de réactions biochimiques. La plupart des réactions, qui se déroulent dans une cellule, sont catalysées par des molécules spéciales appelées enzymes. Tout ceci est représenté comme un réseau, appelé voie métabolique [20]. Figure 4.3. Système équilibré de masse La Figure 4.3 représente la topologie simple d'une voie métabolique dans une cellule, qui se compose de cinq métabolites A, B, C, D et E et six réactions, dont chacune relie deux métabolites. Chaque flux est placé sur la réaction correspondante. Bien que les concentrations de A, C, D et E soient expérimentalement mesurables, la concentration de B ne peut pas être mesurée. Par conséquent, B est le métabolite intracellulaire. Sur la base de la cinétique enzymatique, le comportement dynamique du flux d'une réaction enzymatique peut être représenté comme l'équation différentielle suivante: ��� �� = ��� − ���� − ��� (4.2) où Cx est la concentration d'un métabolite X, vin (resp. vout) est la somme des flux de réactions pour la production (resp. consommation) de X, et μCX représente le taux de croissance de la biomasse dans une cellule. Si tous les métabolites sont à l'état stationnaire, le terme de gauche de l'équation (4.2) doit être nul car il n'y a pas de changements de séries chronologiques des concentrations, et aussi, on peut supposer que la dilution des éléments à cause de la croissance 78 Approche proposée et résultats de la biomasse (correspondant à la durée de la dernière équation (4.2)) est négligée. Ce fait signifie que pour chaque métabolite X, les flux de consommation de X sont équilibrés avec les flux de production de X à l'état stationnaire. L’équilibrage de flux métabolique est basé sur cette notion simple. Par exemple, son équilibrage dans la Figure 4.3 peut être représenté comme les équations linéaires suivantes: �1 = ��, �2 + �3 + = �3 − + �1, �5 = �2 + ��, �4 + �� = �5, �3 − + �� = �3 + + �4 (4.3) Ensuite, nous pouvons analyser la distribution du flux sur la base des équations (4.3) avec les flux mesurables rA, rC, rD et rE. En général, ces équations ne peuvent pas être résolues de façon déterministe parce que le nombre de valeurs inconnues comme v1,. . . , v5 correspondant aux flux de réactions enzymatiques intracellulaires devient plus grand que le nombre de valeurs connues correspondant aux flux mesurables. Des méthodes ont été proposées précédemment telles que l'analyse en mode primaire et extrêmes de la voie, des fonctions d'analyse d'utilisation d'optimisation afin de résoudre les équations. Ces fonctions introduites sont généralement construites en supposant que la maximisation de la croissance cellulaire ou la minimisation de la consommation d'énergie. Toutefois, dans le cas d'une grande échelle de la voie métabolique, nous ne pouvons pas résoudre la distribution de flux avec ces méthodes d'approximation en raison du coût de calcul énorme. Le système métabolique cellulaire dispose d'un mécanisme sophistiqué pour contrôler dynamiquement les activités des enzymes pour répondre aux besoins d'une cellule. Ce mécanisme de régulation peut être représenté comme des relations causales entre les activités enzymatiques et la concentration de métabolites changeants. Ici, nous considérons trois voies métaboliques simples: la première se compose de deux réactions avec trois métabolites, la seconde se compose de deux réactions avec trois métabolites aussi, et la troisième se compose d'une réaction avec deux métabolites. Noter que dans les figures suivantes, nous décrivons activé et non-activé par des réactions comme les cercles et barres obliques plus flèches correspondant aux réactions, respectivement. Et aussi, une hausse (resp. baisse) flèche représente l'augmentation (resp. la diminution) à une concentration de métabolites. La figure 4.4 correspond à la voie métabolique composée de trois métabolites X, Y et Z, et deux réactions. La figure dit que si la concentration de Y tend à augmenter à un certain moment, et si la réaction enzymatique Y→X (resp. X→Z) est activée (resp. non-activée) dans un état, alors la concentration de X va aussi augmenter. Cette relation causale est prise en compte par l'équation (4.2). Supposons que l'augmentation de la concentration de X est observée, ce qui est représentée par une flèche en pointillés dans les figures. Un cas possible est que la concentration de Y augmente, la réaction de Y→X est activée et la réaction X→Z n'est pas activée. Ceci parce que la production de X à partir de Y ne peut pas être consommée pour générer le Z. Approche proposée et résultats 79 Figure 4.4. La première relation entre les états de réaction et les changements de concentration de métabolites La Figure 4.5 correspond à la voie métabolique composée de trois métabolites X, Y et Z, et deux réactions. La figure montre que si la concentration de Y tend à augmenter à un certain moment, et si la réaction enzymatique Y→X (resp. X→Z) est non-activée (resp. activée) dans un l'état, alors la concentration de X va diminuer. Cette relation causale est prise en compte par l'équation (4.2). Supposons que la diminution de la concentration de X est observée, ce qui est désignée par une flèche en pointillés dans les figures. Un cas possible est que la concentration de Y augmente, la réaction de Y→X n’est pas activée et la réaction X→Z est activée. C'est parce que la production de Z à partir de X peut être consommée. Figure 4.5. La deuxième relation entre les états de réaction et les changements de concentration de métabolites Ensuite, nous considérons la Figure 4.6 qui représente une voie métabolique composée de deux métabolites X et Y, et une réaction. La figure montre que, même si la réaction Y→X est activée, la concentration de X doit diminuer en ce que la concentration de Y diminue. Par conséquent, si nous observons que la concentration de X diminue, on peut supposer une diminution de la concentration de Y et la réaction Y→X est activée comme un cas possible. Figure 4.6. La troisième relation entre les états de réaction et les changements de concentration de métabolites Les métabolites et les protéines sont considérés comme un même objet. On va souvent se restreindre ici à une représentation propositionnelle. Dans la pratique l'étude fine des interactions va demander de représenter des augmentations ou des diminutions de concentration de protéines. On sort donc du cadre propositionnel mais les problèmes de base sont les mêmes. Pour représenter une variation de concentration il est par exemple possible d'utiliser des prédicats de type "augmente" ou "diminue" et de limiter l'utilisation de ces prédicats. Pour décrire les interactions entre les métabolites dans la cellule, on part d’un langage L de logique classique (propositionnel ou du premier ordre). Dans L, la proposition A (resp ¬A) signifie que A est vrai (faux). On pourra utiliser par exemple con(A, up, ti) pour dire que la Y X Z Y X Z Y X80 Approche proposée et résultats concentration de A est augmentée au moment ti , ou encore, con(A, down, tj) pour dire que la concentration de A est diminuée au moment tj . On est dans un cadre logique, donc il est possible de représenter à peu près tout ce que l'on veut de manière naturelle. Le prix à payer, si l’on utilise la totalité du langage peut être l'explosion combinatoire des algorithmes. Les réactions entres métabolites sont une forme très simple de causalité. Pour exprimer ces réactions, il est courant d'aller à l'essentiel en donnant deux relations binaires act(A, B) et ¬act(A, B). La première relation veut dire, par exemple, qu’un métabolite A est consommé pour la production d'un métabolite B, la deuxième n’est pas consommé. De manière classique ces relations sont représentées dans le réseau de gênes, par A → B et A ⊣ B. Bien entendu cette causalité est élémentaire et de nombreux travaux très savants ont été écrits pour représenter les causalités. (C1) con(A,up,ti)∧react(A,B)∧active(A,B)∧react(B,C)∧non_active(B,C) → con(B,up,ti+1) (C2) con(A,up,tj)∧react(A,B)∧non_active(A,B)∧react(B,C)∧active(B,C) → con(B,down,tj+1) (C3) con(A,down,tk)∧ react(A,B)∧ active(A,B) → con(B,down,tk+1) L’expression (C1) veut dire que si la concentration de A est augmentée au moment ti , s’il y a une réaction entre A et B dans laquelle le métabolite A est consumée pour la production du métabolite B, et si pour toutes les réactions entre B et C le métabolite B n’est pas consommé pour la production du métabolite C, alors la concentration de B est augmentée au moment ti+1. L’expression (C2) veut dire que si la concentration de A est augmentée au moment tj , s’il y a une réaction entre A et B dans laquelle le métabolite A n’est pas consommé pour la production du métabolite B, et si pour une réaction entre B et C le métabolite B est consommé pour la production du métabolite C, alors la concentration de B est diminuée au moment tj+1. L’expression (C3) veut dire que si la concentration de A est diminuée au moment tk, s’il y a une réaction entre A et B dans laquelle le métabolite A est consommé pour la production du métabolite B, alors la concentration de B est diminuée au moment tk+1. Mais ces deux formulations posent problème dès qu'il y a un paradoxe. Si par exemple on a un ensemble F de sept formules F = {con(A, up, ti), react(A, B), react(B, C), active(A, B), non_active(B, C), non_active(A, B), active(B, C)}, alors on va dans les deux approches données ci-dessus inféré de F, con(B, up, ti+1) et con(B, down, ti+1) ce qui est paradoxe, parce que la concentration de B est augmentée et diminuée au même moment ti+1. Pour résoudre ce conflit, on peut utiliser la logique des défauts. Dans notre exemple, pour fournir des liens entre ces relations actives et non actives, l'idée intuitive est donc d'affaiblir la formulation de règles de causalité: (1) Si con(A,up,ti) , react(A,B), react(B,C), active(A,B), et non_active(B,C) sont vrais, et s’il est possible que con(B,up,ti+1), alors con(B,up,ti+1) est conclu (2) Si con(A,up,tj), react(A,B), react(B,C), non_active(A,B), et active(B,C) sont vrais, et s’il est possible que con(B,down,tj+1), alors con(B,down,tj+1) est concluApproche proposée et résultats 81 (3) Si con(A,down,tk), react(A,B), et active(A,B) sont vrais, et s’il est possible que con(B,down,tk+1), alors con(B,down,tk+1) est conclu La question est alors de formellement décrire le possible. Dans la logique des défauts, les règles (1), (2) et (3) seront exprimées de manière intuitive. �1: ���(�, ��,�� ) ∧ �����(�, �) ∧ �����(�, �) ∧ ������(�, �) ∧ ���_������(�, �): ���(�, ��,��+1) ���(�, ��,��+1) �2: �����, ��,��� ∧ �����(�, �) ∧ �����(�, �) ∧ ���_������(�, �) ∧ ������(�, �): ���(�, ����,��+1) ���(�, ����,��+1) �3: ���(�, ����,�� ) ∧ �����(�, �) ∧ ������(�, �): ���(�, ����,��+1) ���(�, ����,��+1) Le paradoxe a été résolu. Pour une théorie des défauts ∆ = (D, W), où D l'ensemble des défauts et W = {con(A, up, t0)}, en utilisant l’algorithme de calcul des extensions, on a 12 extensions ci-dessous [27]: EXTENSION 1: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), act(e,c), non_act(c,b)) → con(c,up, t4) EXTENSION 2: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), non_act(e,c), act(c,b)) → con(c,down, t4) EXTENSION 3: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), non_act(d,e), act(e,c)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 4: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1)82 Approche proposée et résultats joint(con(b,up, t1), non_act(b,d), act(d,e)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 5: joint(con(a,up, t0), non_act(a,b), act(b,c)) → con(b,down, t1) joint(con(b,down, t1), act(b,c)) → con(c,down, t2) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) EXTENSION 6: joint(con(a,up, t0), non_act(a,b), act(b,c)) → con(b,down, t1) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 7: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), act(e,c), non_act(c,b)) → con(c,up, t4) EXTENSION 8: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), non_act(e,c), act(c,b)) → con(c,down, t4) EXTENSION 9: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), non_act(d,e), act(e,c)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4)Approche proposée et résultats 83 EXTENSION 10: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), non_act(b,d), act(d,e)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 11: joint(con(a,up, t0), non_act(a,b), act(b,d)) → con(b,down, t1) joint(con(b,down, t1), act(b,c)) → con(c,down, t2) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) EXTENSION 12: joint(con(a,up, t0), non_act(a,b), act(b,d)) → con(b,down, t1) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) Cet algorithme a une complexité très grande. Il sera sans doute nécessaire de réduire les possibilités d'expression du langage pour arriver à des temps de calcul raisonnables. On retrouve ici la même problématique que pour la résolution pratique des problèmes NPComplets. Pour la carte de Pommier, après une coupe de l’algorithme pour réduire les extensions équivalentes, on a la base de données et le résultat ci-dessous, où un fait w dans W est défini « dur : --> w », et un défaut d = A:C/C dans D est défini « def : A --> C ». LA BASE DE DONNÉES: 1 dur : --> phosphorylation(atr,h2ax) 2 dur : --> stimulation(dsb,dna) 3 def : stimulation(dsb,dna) --> product(altered_dna) 4 def : product(altered_dna) --> binding(mre11,rad50) 5 def : binding(mre11,rad50) --> product(mre11_rad50) 6 def : product(mre11_rad50) --> binding(mre11_rad50,nbs1) 7 def : binding(mre11_rad50,nbs1) --> product(mrn) 8 def : product(mrn) --> binding(mrn,altered_dna) 9 def : binding(mrn,altered_dna) --> product(mrn_bound_to_dna) 10 def : product(mrn_bound_to_dna) --> binding(mrn_bound_to_dna,atm_atm) 11 def : binding(mrn_bound_to_dna,atm_atm) --> product(atm_bound_to_mrn) 12 def : product(atm_bound_to_mrn) --> bloq-product(atm_atm) 13 def : product(atm_bound_to_mrn) --> autophosphorylation(atm_bound_to_mrn) 14 def : autophosphorylation(atm_bound_to_mrn) --> product(p_atm_atm_bound) 84 Approche proposée et résultats 15 def : product(p_atm_atm_bound) --> bloq-product(atm_atm) 16 def : product(p_atm_atm_bound) --> dissociation(p_atm_atm_bound) 17 def : dissociation(p_atm_atm_bound) --> product(p_atm_bound) 18 def : dissociation(p_atm_atm_bound) --> product(p_atm_free) 19 def : product(p_atm_free) --> phosphorylation(p_atm_free,chk1) 20 def : phosphorylation(p_atm_free,chk1) --> product(p_chk1) 21 dur : --> phosphorylation(atr,chk1) 22 def : phosphorylation(atr,chk1) --> product(p_chk1) 23 def : product(mrn_bound_to_dna) --> product(p_smc1) 24 def : product(mrn_bound_to_dna) --> product(p_mre11) 25 def : phosphorylation(atr,h2ax) --> product(gamma_h2ax) 26 def : phosphorylation(p_atm_bound,h2ax) --> product(gamma_h2ax) 27 def : product(gamma_h2ax) --> binding(gamma_h2ax,mdc1) 28 def : binding(gamma_h2ax,mdc1) --> product(h2ax_mdc1) 29 def : product(h2ax_mdc1) --> phosphorylation(p_atm_bound,h2ax_mdc1) 30 def : phosphorylation(p_atm_bound,h2ax_mdc1) --> product(p_mdc1) 31 def : product(p_mdc1) --> binding(p_mdc1,rnf8) 32 def : binding(p_mdc1,rnf8) --> product(rnf8_bound) 33 def : product(rnf8_bound) --> binding(rnf8_bound,ubc13) 34 def : binding(rnf8_bound,ubc13) --> product(rnf8_ubc13) 35 def : product(rnf8_ubc13) --> ubiquitination(rnf8_ubc13,h2a) 36 def : ubiquitination(rnf8_ubc13,h2a) --> product(ub_h2a) 37 def : product(ub_h2a) --> binding(ub_h2a,rnf168) 38 def : binding(ub_h2a,rnf168) --> product(rnf168_bound) 39 def : product(rnf168_bound) --> binding(rnf168_bound,ubc13) 40 def : binding(rnf168_bound,ubc13) --> product(rnf168_ubc13) 41 def : product(rnf168_ubc13) --> ubiquitination(rnf168_ubc13,h2a) 42 def : ubiquitination(rnf168_ubc13,h2a) --> product(poly_ub_h2a) 43 def : product(poly_ub_h2a) --> stimulation(poly_ub_h2a,dna) 44 def : stimulation(poly_ub_h2a,dna) --> product(changed_struct_dna) 45 def : product(poly_ub_h2a) --> binding(poly_ub_h2a,rap80) 46 def : binding(poly_ub_h2a,rap80) --> product(rap80_bound) 47 def : product(rap80_bound) --> binding(rap80_bound,abraxas) 48 def : binding(rap80_bound,abraxas) --> product(abraxas_bound) 49 def : product(abraxas_bound) --> binding(abraxas_bound,bre) 50 def : binding(abraxas_bound,bre) --> product(bre_bound) 51 def : product(abraxas_bound) --> binding(abraxas_bound,brcc36) 52 def : binding(abraxas_bound,brcc36) --> product(brcc36_bound) 53 def : product(brcc36_bound) --> binding(brcc36_bound,merit40) 54 def : binding(brcc36_bound,merit40) --> product(merit40_bound) 55 def : product(merit40_bound) --> binding(merit40_bound,brcc36_bound) 56 def : binding(merit40_bound,brcc36_bound) --> product(brcc36_merit40) 57 def : product(brcc36_merit40) --> binding(brcc36_merit40,brca1) 58 def : binding(brcc36_merit40,brca1) --> product(brca1_bound_to_rap80_complex) 59 def : product(changed_struct_dna) --> phosphorylation(p_atm_bound,mmset) 60 def : phosphorylation(p_atm_bound,mmset) --> product(p_mmset) 61 def : product(h2ax_mdc1) --> binding(h2ax_mdc1,mdc1) 62 def : binding(h2ax_mdc1,mdc1) --> product(mdc1_multi)Approche proposée et résultats 85 63 def : product(mdc1_multi), product(p_mmset) --> binding(mdc1_multi,p_mmset) 64 def : binding(mdc1_multi,p_mmset) --> product(mmset_mdc1) 65 def : product(mmset_mdc1) --> methylation(mmset_mdc1,h4) 66 def : methylation(mmset_mdc1,h4) --> product(h4k20me2) 67 def : product(h4k20me2), product(brca1_bound_to_rap80_complex) --> binding(h4k20me2,p53bp1) 68 def : binding(h4k20me2,p53bp1) --> product(p53bp1_bound) 69 def : product(p53bp1_bound) --> phosphorylation(p_atm_bound,p53bp1_bound) 70 def : phosphorylation(p_atm_bound,p53bp1_bound) --> product(p_53bp1) 71 def : product(p_atm_free) --> phosphorylation(p_atm_free,plk3) 72 def : phosphorylation(p_atm_free,plk3) --> product(p_plk3) 73 def : product(p_atm_free) --> phosphorylation(p_atm_free,chk2) 74 def : phosphorylation(p_atm_free,chk2) --> product(p_s33_35_chk2) 75 def : product(p_s33_35_chk2) --> phosphorylation(p_plk3,p_s33_35_chk2) 76 def : phosphorylation(p_plk3,p_s33_35_chk2) --> product(p_s33_35_s62_73_chk2) 77 def : product(p_s33_35_s62_73_chk2) --> phosphorylation(p_atm_free,p_s33_35_s62_73_chk2) 78 def : phosphorylation(p_atm_free,p_s33_35_s62_73_chk2) --> product(p_t68_chk2) 79 def : product(p_s33_35_s62_73_chk2) --> phosphorylation(atr,p_s33_35_s62_73_chk2) 80 def : phosphorylation(atr,p_s33_35_s62_73_chk2) --> product(p_t68_chk2) 81 def : product(p_t68_chk2) --> binding(p_t68_chk2,p_t68_chk2) 82 def : binding(p_t68_chk2,p_t68_chk2) --> product(chk2_chk2) 83 def : product(chk2_chk2) --> autophosphorylation(chk2_chk2) 84 def : autophosphorylation(chk2_chk2) --> product(p_active_chk2_chk2) 85 def : product(p_active_chk2_chk2), product(p_53bp1) --> binding(p_active_chk2_chk2,p_53bp1) 86 def : binding(p_active_chk2_chk2,p_53bp1) --> product(chk2_53bp1) 87 dur : --> binding(brca1,ctip) 88 def : binding(brca1,ctip) --> product(brca1_ctip) 89 def : product(brca1_ctip), product(chk2_53bp1) --> binding(brca1_ctip,chk2_53bp1) 90 def : binding(brca1_ctip,chk2_53bp1) --> product(chk2_53bp1_bound_to_brca1) 91 def : binding(brca1_ctip,chk2_53bp1) --> product(brca1_ctip_bound_to_chk2) 92 def : product(chk2_53bp1_bound_to_brca1), product(brca1_ctip_bound_to_chk2) --> phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2) 93 def : phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2) --> product(p_brca1_ctip_bound_to_chk2) 94 def : product(p_brca1_ctip_bound_to_chk2) --> product(p_s988_brca_ctip) 95 def : product(chk2_53bp1_bound_to_brca1) --> product(chk2_53bp1) 96 def : product(p_s988_brca_ctip) --> phosphorylation(p_atm_bound,p_s988_brca_ctip) 97 def : phosphorylation(p_atm_bound,p_s988_brca_ctip) --> product(brca_p_ctip) 98 def : product(brca_p_ctip) --> bloq-product(brca1_ctip) 99 def : product(brca_p_ctip) --> dissociation(brca_p_ctip) 100 def : dissociation(brca_p_ctip) --> product(brca1) 101 def : dissociation(brca_p_ctip) --> product(p_ctip) 102 def : product(brca1) --> phosphorylation(p_atm_bound,brca1) 103 def : phosphorylation(p_atm_bound,brca1) --> product(p_brca1) 104 def : product(brca1) --> phosphorylation(atr,brca1) 105 def : phosphorylation(atr,brca1) --> product(p_brca1) 106 def : product(p_brca1), product(p_53bp1) --> binding(mrn_bound_to_dna,p_brca1)86 Approche proposée et résultats 107 def : binding(mrn_bound_to_dna,p_brca1) --> product(brca1_bound_to_mrn) 108 def : product(chk2_53bp1) --> phosphorylation(chk2_53bp1,pml) 109 def : phosphorylation(chk2_53bp1,pml) --> product(p_pml) 110 def : product(p_pml) --> stimulation(p_pml,cell) 111 def : stimulation(p_pml,cell) --> product(apoptosis) 112 def : product(p_pml) --> binding(p_pml,mdm2) 113 def : binding(p_pml,mdm2) --> product(pml_mdm2) 114 def : product(pml_mdm2) --> bloq-binding(mdm2,p53) 115 dur : --> product(p53) 116 def : product(mdm2), product(p53) --> binding(mdm2,p53) 117 def : binding(mdm2,p53) --> product(mdm2_p53) 118 def : product(mdm2_p53) --> stimulation(p53_degradation_effectors,mdm2_p53) 119 def : stimulation(p53_degradation_effectors,mdm2_p53) --> product(p53_degradation) 120 def : product(p_atm_free), product(mdm2_p53) --> phosphorylation(p_atm_free,mdm2_p53) 121 def : phosphorylation(p_atm_free,mdm2_p53) --> product(p_s15_p53_mdm2) 122 def : product(mdm2_p53) --> phosphorylation(atr,mdm2_p53) 123 def : phosphorylation(atr,mdm2_p53) --> product(p_s15_p53_mdm2) 124 def : product(p_s15_p53_mdm2), product(chk2_53bp1) --> phosphorylation(chk2_53bp1,p_s15_p53_mdm2) 125 def : phosphorylation(chk2_53bp1,p_s15_p53_mdm2) --> product(p_p_p53_mdm2) 126 def : product(p_s15_p53_mdm2), product(p_chk1) --> phosphorylation(p_chk1,p_s15_p53_mdm2) 127 def : phosphorylation(p_chk1,p_s15_p53_mdm2) --> product(p_p_p53_mdm2) 128 def : product(p_s15_p53_mdm2) --> bloq-product(p53_degradation) 129 def : product(p_p_p53_mdm2) --> bloq-product(p53_degradation) 130 def : product(p_p_p53_mdm2) --> dissociation(p_p_p53_mdm2) 131 def : dissociation(p_p_p53_mdm2) --> product(p_p_p53) 132 def : dissociation(p_p_p53_mdm2) --> product(mdm2) 133 def : product(p_atm_free), product(mdm2) --> phosphorylation(p_atm_free,mdm2) 134 def : phosphorylation(p_atm_free,mdm2) --> product(p_mdm2) 135 def : product(p_p_p53) --> binding(p300,p_p_p53) 136 def : product(p_pml), binding(p300,p_p_p53) --> product(active_p53) 137 def : product(active_p53) --> transcription_activation(active_p53,prom_p21_gadd45) 138 def : transcription_activation(active_p53,prom_p21_gadd45) --> product(p21_and_gadd45) 139 def : product(prom_and_gadd45) --> stimulation(prom_and_gadd45,cell_cycle) 140 def : stimulation(p21_and_gadd45,cell_cycle) --> product(cell_cycle_arrest) 141 def : product(active_p53) --> transcription_activation(active_p53,prom_bnpf) 142 def : transcription_activation(active_p53,prom_bnpf) --> product(box_nas_puma_fas) 143 def : product(box_nas_puma_fas) --> stimulation(box_nas_puma_fas,cell) 144 def : stimulation(box_nas_puma_fas,cell) --> product(apoptosis) 145 def : product(active_p53) --> transcription_activation(active_p53,prom_mdm2) 146 def : transcription_activation(active_p53,prom_mdm2) --> product(mdm2) 147 dur : --> product(e2f1) 148 def : product(e2f1), product(chk2_53bp1) --> phosphorylation(chk2_53bp1,e2f1) 149 def : phosphorylation(chk2_53bp1,e2f1) --> product(p_e2f1) 150 def : product(e2f1) --> stimulation(e2f1_degradation_effectors,e2f1) 151 def : stimulation(e2f1_degradation_effectors,e2f1) --> product(e2f1_degradation) 152 def : product(p_e2f1) --> phosphorylation(p_atm_free,p_e2f1) Approche proposée et résultats 87 153 def : phosphorylation(p_atm_free,p_e2f1) --> product(p_p_e2f1) 154 def : product(p_e2f1) --> phosphorylation(atr,p_e2f1) 155 def : phosphorylation(atr,p_e2f1) --> product(p_p_e2f1) 156 def : product(p_p_e2f1) --> transcription_activation(p_p_e2f1,prom_chk2) 157 def : transcription_activation(p_p_e2f1,prom_chk2) --> product(chk2) 158 def : product(p_p_e2f1) --> transcription_activation(p_p_e2f1,prom_arf) 159 def : transcription_activation(p_p_e2f1,prom_arf) --> product(arf) 160 def : product(p_p_e2f1) --> transcription_activation(p_p_e2f1,prom_p73_apaf1) 161 def : transcription_activation(p_p_e2f1,prom_p73_apaf1) --> product(p73_apaf1) 162 def : product(p73_apaf1) --> stimulation(p73_apaf1,cell) 163 def : stimulation(p73_apaf1,cell) --> product(apoptosis) 164 def : product(arf) --> binding(arf,mdm2) 165 def : binding(arf,mdm2) --> product(arf_mdm2) 166 def : product(arf_mdm2) --> bloq-product(mdm2_p53) 167 def : product(p_p_e2f1) --> stimulation(p_p_e2f1,unknown_atm_way) 168 def : stimulation(p_p_e2f1,unknown_atm_way) --> product(p_atm_free) 169 def : product(p_atm_free) --> phosphorylation(p_atm_free,p38) 170 def : phosphorylation(p_atm_free,p38) --> product(p_p38) 171 def : product(chk2_53bp1) --> phosphorylation(chk2_53bp1,cdc25a) 172 def : phosphorylation(chk2_53bp1,cdc25a) --> product(p_cdc25a) 173 def : product(p_chk1) --> phosphorylation(p_chk1,cdc25a) 174 def : phosphorylation(p_chk1,cdc25a) --> product(p_cdc25a) 175 def : product(p_cdc25a) --> stimulation(cdc25a,cell) 176 def : stimulation(cdc25a,cell) --> bloq-product(cell_cycle_arrest) 177 def : product(p_cdc25a) --> stimulation(p_cdc25a,cdc25a_degradation_effectors) 178 def : stimulation(p_cdc25a,cdc25_degradation_effectors) --> product(cdc25a_degradation) 179 def : product(cdc25a_degradation) --> bloq-stimulation(cdc25a,cell) 180 def : product(chk2_53bp1) --> phosphorylation(chk2_53bp1,cdc25c) 181 def : phosphorylation(chk2_53bp1,cdc25c) --> product(p_cdc25c) 182 def : product(p_plk3) --> phosphorylation(p_plk3,cdc25c) 183 def : phosphorylation(p_plk3,cdc25c) --> product(p_cdc25c) 184 def : product(p_chk1) --> phosphorylation(p_chk1,cdc25c) 185 def : phosphorylation(p_chk1,cdc25c) --> product(p_cdc25c) 186 def : product(p_p38) --> phosphorylation(p_p38,cdc25c) 187 def : phosphorylation(p_p38,cdc25c) --> product(p_cdc25c) 188 def : product(p_cdc25c) --> stimulation(cdc25c,cell) 189 def : stimulation(cdc25c,cell) --> bloq-product(cell_cycle_arrest) 190 def : product(p_cdc25c) --> stimulation(p_cdc25c,cdc25c_degradation_effectors) 191 def : stimulation(cdc25b,cell) --> bloq-product(cell_cycle_arrest) 192 def : product(p_p38) --> phosphorylation(p_p38,cdc25b) 193 def : phosphorylation(p_p38,cdc25b) --> product(p_cdc25b) 194 def : product(p_cdc25b) --> bloq-stimulation(cdc25b,cell) 195 def : stimulation(jnk,cdc25c) --> product(p_cdc25c) 196 def : phosphorylation(jnk,p_s15_p53_mdm2) --> product(p_p_p53_mdm2) 197 def : product(p_atm_bound) --> phosphorylation(p_atm_bound,nbs1) 198 def : phosphorylation(p_atm_bound,nbs1) --> product(p_nbs1) 199 def : product(p_nbs1) --> phosphorylation(p_atm_bound,fancd2) 200 def : phosphorylation(p_atm_bound,fancd2) --> product(p_fancd2)88 Approche proposée et résultats 201 def : product(p_fancd2) --> stimulation(p_fancd2,cell) 202 def : stimulation(p_fancd2,cell) --> bloq-product(cell_cycle_arrest) 203 def : product(chk2_53bp1) --> binding(chk2_53bp1,mus81) 204 def : binding(chk2_53bp1,mus81) --> product(mus81_chk2) 205 def : product(mus81_chk2) --> binding(mus81_chk2,altered_dna) 206 def : binding(mus81_chk2,altered_dna) --> product(mus81_bound_to_dna) LE RÉSULTAT def 3 : (stimulation(dsb,dna), up, t0) ==> (product(altered_dna), up, t1) def 4 : (product(altered_dna), up, t1) ==> (binding(mre11,rad50), up, t2) def 5 : (binding(mre11,rad50), up, t2) ==> (product(mre11_rad50), up, t3) def 6 : (product(mre11_rad50), up, t3) ==> (binding(mre11_rad50,nbs1), up, t4) def 7 : (binding(mre11_rad50,nbs1), up, t4) ==> (product(mrn), up, t5) def 8 : (product(mrn), up, t5) ==> (binding(mrn,altered_dna), up, t6) def 9 : (binding(mrn,altered_dna), up, t6) ==> (product(mrn_bound_to_dna), up, t7) def 10 : (product(mrn_bound_to_dna), up, t7) ==> (binding(mrn_bound_to_dna,atm_atm), up, t8) def 11 : (binding(mrn_bound_to_dna,atm_atm), up, t8) ==> (product(atm_bound_to_mrn), up, t9) def 12 : (product(atm_bound_to_mrn), up, t9) ==> (product(atm_atm), down, t10) def 13 : (product(atm_bound_to_mrn), up, t9) ==> (autophosphorylation(atm_bound_to_mrn), up, t10) def 14 : (autophosphorylation(atm_bound_to_mrn), up, t10) ==> (product(p_atm_atm_bound), up, t11) def 16 : (product(p_atm_atm_bound), up, t11) ==> (dissociation(p_atm_atm_bound), up, t12) def 17 : (dissociation(p_atm_atm_bound), up, t12) ==> (product(p_atm_bound), up, t13) def 18 : (dissociation(p_atm_atm_bound), up, t12) ==> (product(p_atm_free), up, t13) def 19 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,chk1), up, t14) def 20 : (phosphorylation(p_atm_free,chk1), up, t14) ==> (product(p_chk1), up, t15) def 23 : (product(mrn_bound_to_dna), up, t7) ==> (product(p_smc1), up, t8) def 24 : (product(mrn_bound_to_dna), up, t7) ==> (product(p_mre11), up, t8) def 25 : (phosphorylation(atr,h2ax), up, t0) ==> (product(gamma_h2ax), up, t1) def 27 : (product(gamma_h2ax), up, t1) ==> (binding(gamma_h2ax,mdc1), up, t2) def 28 : (binding(gamma_h2ax,mdc1), up, t2) ==> (product(h2ax_mdc1), up, t3) def 29 : (product(h2ax_mdc1), up, t3) ==> (phosphorylation(p_atm_bound,h2ax_mdc1), up, t4) def 30 : (phosphorylation(p_atm_bound,h2ax_mdc1), up, t4) ==> (product(p_mdc1), up, t5) def 31 : (product(p_mdc1), up, t5) ==> (binding(p_mdc1,rnf8), up, t6) def 32 : (binding(p_mdc1,rnf8), up, t6) ==> (product(rnf8_bound), up, t7) def 33 : (product(rnf8_bound), up, t7) ==> (binding(rnf8_bound,ubc13), up, t8) def 34 : (binding(rnf8_bound,ubc13), up, t8) ==> (product(rnf8_ubc13), up, t9) def 35 : (product(rnf8_ubc13), up, t9) ==> (ubiquitination(rnf8_ubc13,h2a), up, t10) def 36 : (ubiquitination(rnf8_ubc13,h2a), up, t10) ==> (product(ub_h2a), up, t11) def 37 : (product(ub_h2a), up, t11) ==> (binding(ub_h2a,rnf168), up, t12) def 38 : (binding(ub_h2a,rnf168), up, t12) ==> (product(rnf168_bound), up, t13) def 39 : (product(rnf168_bound), up, t13) ==> (binding(rnf168_bound,ubc13), up, t14) def 40 : (binding(rnf168_bound,ubc13), up, t14) ==> (product(rnf168_ubc13), up, t15) def 41 : (product(rnf168_ubc13), up, t15) ==> (ubiquitination(rnf168_ubc13,h2a), up, t16) def 42 : (ubiquitination(rnf168_ubc13,h2a), up, t16) ==> (product(poly_ub_h2a), up, t17) def 43 : (product(poly_ub_h2a), up, t17) ==> (stimulation(poly_ub_h2a,dna), up, t18) def 44 : (stimulation(poly_ub_h2a,dna), up, t18) ==> (product(changed_struct_dna), up, t19) def 45 : (product(poly_ub_h2a), up, t17) ==> (binding(poly_ub_h2a,rap80), up, t18) Approche proposée et résultats 89 def 46 : (binding(poly_ub_h2a,rap80), up, t18) ==> (product(rap80_bound), up, t19) def 47 : (product(rap80_bound), up, t19) ==> (binding(rap80_bound,abraxas), up, t20) def 48 : (binding(rap80_bound,abraxas), up, t20) ==> (product(abraxas_bound), up, t21) def 49 : (product(abraxas_bound), up, t21) ==> (binding(abraxas_bound,bre), up, t22) def 50 : (binding(abraxas_bound,bre), up, t22) ==> (product(bre_bound), up, t23) def 51 : (product(abraxas_bound), up, t21) ==> (binding(abraxas_bound,brcc36), up, t22) def 52 : (binding(abraxas_bound,brcc36), up, t22) ==> (product(brcc36_bound), up, t23) def 53 : (product(brcc36_bound), up, t23) ==> (binding(brcc36_bound,merit40), up, t24) def 54 : (binding(brcc36_bound,merit40), up, t24) ==> (product(merit40_bound), up, t25) def 55 : (product(merit40_bound), up, t25) ==> (binding(merit40_bound,brcc36_bound), up, t26) def 56 : (binding(merit40_bound,brcc36_bound), up, t26) ==> (product(brcc36_merit40), up, t27) def 57 : (product(brcc36_merit40), up, t27) ==> (binding(brcc36_merit40,brca1), up, t28) def 58 : (binding(brcc36_merit40,brca1), up, t28) ==> (product(brca1_bound_to_rap80_complex), up, t29) def 59 : (product(changed_struct_dna), up, t19) ==> (phosphorylation(p_atm_bound,mmset), up, t20) def 60 : (phosphorylation(p_atm_bound,mmset), up, t20) ==> (product(p_mmset), up, t21) def 61 : (product(h2ax_mdc1), up, t3) ==> (binding(h2ax_mdc1,mdc1), up, t4) def 62 : (binding(h2ax_mdc1,mdc1), up, t4) ==> (product(mdc1_multi), up, t5) def 63 : (product(mdc1_multi), up, t5), (product(p_mmset), up, t21) ==> (binding(mdc1_multi,p_mmset), up, t22) def 64 : (binding(mdc1_multi,p_mmset), up, t22) ==> (product(mmset_mdc1), up, t23) def 65 : (product(mmset_mdc1), up, t23) ==> (methylation(mmset_mdc1,h4), up, t24) def 66 : (methylation(mmset_mdc1,h4), up, t24) ==> (product(h4k20me2), up, t25) def 67 : (product(h4k20me2), up, t25), (product(brca1_bound_to_rap80_complex), up, t29) ==> (binding(h4k20me2,p53bp1), up, t30) def 68 : (binding(h4k20me2,p53bp1), up, t30) ==> (product(p53bp1_bound), up, t31) def 69 : (product(p53bp1_bound), up, t31) ==> (phosphorylation(p_atm_bound,p53bp1_bound), up, t32) def 70 : (phosphorylation(p_atm_bound,p53bp1_bound), up, t32) ==> (product(p_53bp1), up, t33) def 71 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,plk3), up, t14) def 72 : (phosphorylation(p_atm_free,plk3), up, t14) ==> (product(p_plk3), up, t15) def 73 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,chk2), up, t14) def 74 : (phosphorylation(p_atm_free,chk2), up, t14) ==> (product(p_s33_35_chk2), up, t15) def 75 : (product(p_s33_35_chk2), up, t15) ==> (phosphorylation(p_plk3,p_s33_35_chk2), up, t16) def 76 : (phosphorylation(p_plk3,p_s33_35_chk2), up, t16) ==> (product(p_s33_35_s62_73_chk2), up, t17) def 77 : (product(p_s33_35_s62_73_chk2), up, t17) ==> (phosphorylation(p_atm_free,p_s33_35_s62_73_chk2), up, t18) def 78 : (phosphorylation(p_atm_free,p_s33_35_s62_73_chk2), up, t18) ==> (product(p_t68_chk2), up, t19) def 79 : (product(p_s33_35_s62_73_chk2), up, t17) ==> (phosphorylation(atr,p_s33_35_s62_73_chk2), up, t18) def 81 : (product(p_t68_chk2), up, t19) ==> (binding(p_t68_chk2,p_t68_chk2), up, t20) def 82 : (binding(p_t68_chk2,p_t68_chk2), up, t20) ==> (product(chk2_chk2), up, t21) def 83 : (product(chk2_chk2), up, t21) ==> (autophosphorylation(chk2_chk2), up, t22) def 84 : (autophosphorylation(chk2_chk2), up, t22) ==> (product(p_active_chk2_chk2), up, t23) def 85 : (product(p_active_chk2_chk2), up, t23), (product(p_53bp1), up, t33) ==> 90 Approche proposée et résultats (binding(p_active_chk2_chk2,p_53bp1), up, t34) def 86 : (binding(p_active_chk2_chk2,p_53bp1), up, t34) ==> (product(chk2_53bp1), up, t35) def 88 : (binding(brca1,ctip), up, t0) ==> (product(brca1_ctip), up, t1) def 89 : (product(brca1_ctip), up, t1), (product(chk2_53bp1), up, t35) ==> (binding(brca1_ctip,chk2_53bp1), up, t36) def 90 : (binding(brca1_ctip,chk2_53bp1), up, t36) ==> (product(chk2_53bp1_bound_to_brca1), up, t37) def 91 : (binding(brca1_ctip,chk2_53bp1), up, t36) ==> (product(brca1_ctip_bound_to_chk2), up, t37) def 92 : (product(chk2_53bp1_bound_to_brca1), up, t37), (product(brca1_ctip_bound_to_chk2), up, t37) ==>(phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2), up, t38) def 93 : (phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2), up, t38) ==> (product(p_brca1_ctip_bound_to_chk2), up, t39) def 94 : (product(p_brca1_ctip_bound_to_chk2), up, t39) ==> (product(p_s988_brca_ctip), up, t40) def 96 : (product(p_s988_brca_ctip), up, t40) ==> (phosphorylation(p_atm_bound,p_s988_brca_ctip), up, t41) def 97 : (phosphorylation(p_atm_bound,p_s988_brca_ctip), up, t41) ==> (product(brca_p_ctip), up, t42) def 99 : (product(brca_p_ctip), up, t42) ==> (dissociation(brca_p_ctip), up, t43) def 100 : (dissociation(brca_p_ctip), up, t43) ==> (product(brca1), up, t44) def 101 : (dissociation(brca_p_ctip), up, t43) ==> (product(p_ctip), up, t44) def 102 : (product(brca1), up, t44) ==> (phosphorylation(p_atm_bound,brca1), up, t45) def 103 : (phosphorylation(p_atm_bound,brca1), up, t45) ==> (product(p_brca1), up, t46) def 104 : (product(brca1), up, t44) ==> (phosphorylation(atr,brca1), up, t45) def 106 : (product(p_brca1), up, t46), (product(p_53bp1), up, t33) ==> (binding(mrn_bound_to_dna,p_brca1), up, t47) def 107 : (binding(mrn_bound_to_dna,p_brca1), up, t47) ==> (product(brca1_bound_to_mrn), up, t48) def 108 : (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,pml), up, t36) def 109 : (phosphorylation(chk2_53bp1,pml), up, t36) ==> (product(p_pml), up, t37) def 110 : (product(p_pml), up, t37) ==> (stimulation(p_pml,cell), up, t38) def 111 : (stimulation(p_pml,cell), up, t38) ==> (product(apoptosis), up, t39) def 112 : (product(p_pml), up, t37) ==> (binding(p_pml,mdm2), up, t38) def 113 : (binding(p_pml,mdm2), up, t38) ==> (product(pml_mdm2), up, t39) def 114 : (product(pml_mdm2), up, t39) ==> (binding(mdm2,p53), down, t40) def 148 : (product(e2f1), up, t0), (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,e2f1), up, t36) def 149 : (phosphorylation(chk2_53bp1,e2f1), up, t36) ==> (product(p_e2f1), up, t37) def 150 : (product(e2f1), up, t0) ==> (stimulation(e2f1_degradation_effectors,e2f1), up, t1) def 151 : (stimulation(e2f1_degradation_effectors,e2f1), up, t1) ==> (product(e2f1_degradation), up, t2) def 152 : (product(p_e2f1), up, t37) ==> (phosphorylation(p_atm_free,p_e2f1), up, t38) def 153 : (phosphorylation(p_atm_free,p_e2f1), up, t38) ==> (product(p_p_e2f1), up, t39) def 154 : (product(p_e2f1), up, t37) ==> (phosphorylation(atr,p_e2f1), up, t38) def 156 : (product(p_p_e2f1), up, t39) ==> (transcription_activation(p_p_e2f1,prom_chk2), up, t40) def 157 : (transcription_activation(p_p_e2f1,prom_chk2), up, t40) ==> (product(chk2), up, t41) def 158 : (product(p_p_e2f1), up, t39) ==> (transcription_activation(p_p_e2f1,prom_arf), up, t40) Approche proposée et résultats 91 def 159 : (transcription_activation(p_p_e2f1,prom_arf), up, t40) ==> (product(arf), up, t41) def 160 : (product(p_p_e2f1), up, t39) ==> (transcription_activation(p_p_e2f1,prom_p73_apaf1), up, t40) def 161 : (transcription_activation(p_p_e2f1,prom_p73_apaf1), up, t40) ==> (product(p73_apaf1), up, t41) def 162 : (product(p73_apaf1), up, t41) ==> (stimulation(p73_apaf1,cell), up, t42) def 164 : (product(arf), up, t41) ==> (binding(arf,mdm2), up, t42) def 165 : (binding(arf,mdm2), up, t42) ==> (product(arf_mdm2), up, t43) def 166 : (product(arf_mdm2), up, t43) ==> (product(mdm2_p53), down, t44) def 167 : (product(p_p_e2f1), up, t39) ==> (stimulation(p_p_e2f1,unknown_atm_way), up, t40) def 169 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,p38), up, t14) def 170 : (phosphorylation(p_atm_free,p38), up, t14) ==> (product(p_p38), up, t15) def 171 : (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,cdc25a), up, t36) def 172 : (phosphorylation(chk2_53bp1,cdc25a), up, t36) ==> (product(p_cdc25a), up, t37) def 173 : (product(p_chk1), up, t15) ==> (phosphorylation(p_chk1,cdc25a), up, t16) def 175 : (product(p_cdc25a), up, t37) ==> (stimulation(cdc25a,cell), up, t38) def 176 : (stimulation(cdc25a,cell), up, t38) ==> (product(cell_cycle_arrest), down, t39) def 177 : (product(p_cdc25a), up, t37) ==> (stimulation(p_cdc25a,cdc25a_degradation_effectors), up, t38) def 180 : (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,cdc25c), up, t36) def 181 : (phosphorylation(chk2_53bp1,cdc25c), up, t36) ==> (product(p_cdc25c), up, t37) def 182 : (product(p_plk3), up, t15) ==> (phosphorylation(p_plk3,cdc25c), up, t16) def 184 : (product(p_chk1), up, t15) ==> (phosphorylation(p_chk1,cdc25c), up, t16) def 186 : (product(p_p38), up, t15) ==> (phosphorylation(p_p38,cdc25c), up, t16) def 188 : (product(p_cdc25c), up, t37) ==> (stimulation(cdc25c,cell), up, t38) def 190 : (product(p_cdc25c), up, t37) ==> (stimulation(p_cdc25c,cdc25c_degradation_effectors), up, t38) def 192 : (product(p_p38), up, t15) ==> (phosphorylation(p_p38,cdc25b), up, t16) def 193 : (phosphorylation(p_p38,cdc25b), up, t16) ==> (product(p_cdc25b), up, t17) def 194 : (product(p_cdc25b), up, t17) ==> (stimulation(cdc25b,cell), down, t18) def 197 : (product(p_atm_bound), up, t13) ==> (phosphorylation(p_atm_bound,nbs1), up, t14) def 198 : (phosphorylation(p_atm_bound,nbs1), up, t14) ==> (product(p_nbs1), up, t15) def 199 : (product(p_nbs1), up, t15) ==> (phosphorylation(p_atm_bound,fancd2), up, t16) def 200 : (phosphorylation(p_atm_bound,fancd2), up, t16) ==> (product(p_fancd2), up, t17) def 201 : (product(p_fancd2), up, t17) ==> (stimulation(p_fancd2,cell), up, t18) def 203 : (product(chk2_53bp1), up, t35) ==> (binding(chk2_53bp1,mus81), up, t36) def 204 : (binding(chk2_53bp1,mus81), up, t36) ==> (product(mus81_chk2), up, t37) def 205 : (product(mus81_chk2), up, t37) ==> (binding(mus81_chk2,altered_dna), up, t38) def 206 : (binding(mus81_chk2,altered_dna), up, t38) ==> (product(mus81_bound_to_dna), up, t39) Ce résultat est représenté dans la Figure 4.7. Les chiffres rouges sont les défauts utilisés dans le résultat.92 Approche proposée et résultats Figure 4.7. Une extension de la carte de PommierConclusion 93 Conclusion Les voies de signalisation sont très importantes pour la compréhension des mécanismes des fonctions biologiques. Cette thèse étudie la synthèse automatique des voies de signalisation à partir d’informations trouvées dans des bases de connaissances. Une composante essentielle de cette approche est l’utilisation du raisonnement logique pour représenter la connaissance biologique de la communication intracellulaire. En choisissant la représentation adéquate des connaissances biologiques la partie « raisonnement » est capable d’assigner un ordre dans l’acquisition des faits et d’extraire les interactions nécessaires à la synthèse des voies métaboliques ou de signalisation. La première partie de la thèse est consacrée à la synthèse des voies pharmaco-cinétiques par des algorithmes de production. Cet algorithme est décidable, cohérent et complet. La deuxième partie utilise la logique des défauts pour représenter les interactions dans les réseaux de gènes. Le problème de l'implémentation et de la complexité algorithmique n'a pas été abordé. Il sera sans doute nécessaire de réduire les possibilités d'expression du langage pour arriver à des temps de calcul raisonnables. On retrouve ici la même problématique que pour la résolution pratique des problèmes NP-Complets. Bien entendu le problème est ici plus compliqué. La complexité pratique peut alors rester accessible en contrôlant l'écriture des règles. Par exemple dans un premier temps on peut essayer de se restreindre à quelque chose qui ressemble à des clauses de Horn (clauses qui contiennent au plus un littéral positif [2]). Bibliographie 95 Bibliographie [1] Demongeot J, “Multi-stationarity and cell differentiation”, J. Biol. Systems., 6, 1-2 (1998). [2] Doncescu A. , Inoue K. and Yamamoto, “Knowledge-based discovery in systems biology using CF-induction”. New Trends in Applied Artificial Intelligence: Proceedings of the 20th International Conference on Industrial, Engineering and Other Applications of Applied Intelligent Systems (IEA / AIE 2007), Lecture Notes in Artificial Intelligence, volume 4570, pages 395-404, Springer-Verlag. [3] Doncescu A, and Siegel P, “Utilisation de la logique des hypothèses pour la modélisation des voies de signalisation dans la cellule”, JIAF 11, Lyon 8-10, June 2011. [4] Doncescu A., Waissman J.,Richard G.,Roux G. “Characterization of bio-chemical signals by inductive logic programming”, Knowledge-Based Systems 15 (1), 129-137, 2002. [5] Christophe Chassagnole, Juan Carlos, A Rodriguez, Andrei Doncescu, Laurence T Yang “Differential evolutionary algorithms for in vivo dynamic analysis of glycolysis and pentose phosphate pathway in Escherichia Coli”, Parallel Computing for Bioinformatics and Computational Biology: Models, Enabling Technologies, and Case Studies, 59-78, John Wiley & Sons, Inc.,2006. [6] Montseny E., Doncescu A., “Operatorial Parametrizing of Controlled Dynamic SystemsApplication to the Fed-Batch Bioreactor Control Problem”, 17th World Congress The International Federation of Automatic Control. Seoul, Korea, June 2008. [7] Forget L, Rish V. , P Siegel. “Preferential Logics are X-logics” Journal of Computational Logic, 10, 2000, pp. 1-13. [8] Ginsberg, ML, Smith, DE (July 1988). “Reasoning about action II: the qualification problem”. Artificial Intelligence Vol. 35 No. 3 pp.311-342. [9] Giunchiglia, E., Lee, J., Lifschitz, V., McCain, N., & Turner, H. (March 2004). “Nonmonotonic causal theories”. Artificial Intelligence No. 1-2 vol.153 pp.49-104. [10]Inoue K, “Induction as Consequence Finding”. Machine Learning, 55 (2) :109-135, 2004. [11]Inoue K, Saito H. “Circumscripta Policies for Induction” Proceedings of 14th Conf. on Inductive Logic Programming, LNAI 3194, pp.164-179, Springer, September 2004. [12]K. Inoue, T. Sato, M. Ishihata, Y. Kameya and H. Nabeshima, “Evaluating abductive hypotheses using an em algorithm on bdds”, in: Proceedings of IJCAI-09, Pasadena, CA, 2009, pp. 810–815. [13]Kayser D., Levy F. “Modeling symbolic causal reasoning”, Intellecta 2004 / 1, 38, pp 291-232 [14]Nabeshima H. , Iwanuma K., Inoue K. Ray O. “SOLAR: An automated deduction system for Finding consequence”. AI Commun. 23 (2-3): 183-203 (2010) [15]Roux-Rouquié M., L. Hood, Imbeaud S., Auffray C. “Issues in Computational Methods for Functional Genomics and Systems Biology”. CMSB 2003 : 182-186 [16]Schwind P. , Siegel P: “Modal Logic for Hypothesis Theory”, Fundamentae Informaticae, cal 21, No. 1-2 89-101. [17]Synnaeve G, Inoue K, Doncescu A, Nabeshima N, Kameya Y, Ishihata M., Sato T, “Kinetic models and qualitative abstraction for relational learning in systems biology”, BIOSTEC Bioinformatics 2011 [18]Siegel P. : “A modal language for Nonmonotonic Reasonning”, Proc. Workshop DRUMS / EEC Marseille 24-27 February 90. [19]P. Siegel , C. Schwind, “Modal logic based theory for nonmonotonic reasoning”. Journal of Applied Non-classical Logic, Volume 3 - No. 1 / 1993, P 73-92. [20]Synnaeve G., Doncescu A., Inoue K., “Kinetic models for logic-based hypothesis finding in metabolic pathways”, Int’l Conf. on Inductive Logic Programming (ILP-09), 2009. [21]Tran N. , C. Baral (2007) “Hypothesizing and reasoning about signaling networks”. Journal of Applied Logic 7 (2009) 253-274 96 Bibliographie [22]Barthélémy DWORKIN “Utilisation de SOLAR dans la voie de signalisation ATM-dépendante de la cassure double-brin de l'ADN”. Mémoire de master 2 / Université Paul Sabatier, Toulouse 2011. [23]Toulgoat I. “Modélisation du comportement humain dans les simulations de combat naval”. Thèse doctorat / Université du Sud, Toulon-Var [s.n] 2011. [24]Pommier Y et al. “Targeting Chk2 kinase: Molecular interaction maps and therapeutic rationale”. 2005 [25]Munna L. Agarwal et al. “The p53 Network”, Journal of Biological Chemistry, Vol. 273, No 1, Issue of January 2, pp. 1-4, 1998 [26]P. Siegel, “Représentation et utilization de la connaissance en calcul propositionnel”, Thèse d’État, Université d’Aix-Marseille II, Luminy, France, 1987. [27]Tan Le, A. Doncescu, P. Siegel, “Default Logic for Diagnostic of Discrete Time System”, 8th international conference BWCCA, October 28-30 2013, Compiegne, France, pp. 488-493. [28]Tan Le, A. Doncescu, P. Siegel, “Utilization of Default Logic for Analyzing a Metabolic System in Discrete Time”, 13th international conference ICCSA, June 24-27 2013, Ho Chi Minh City, Vietnam, pp. 130-136. [29]G. Bossu, P. Siegel, “Nonmonotonic Reasoning and databases”, Workshop Logic and Data Bases. CERT - Toulouse - Décembre 1982 [30]G. Bossu, P. Siegel, “Saturation, Nonmonotonic Reasoning and the Closed World Assumption”, Artificial Intelligence 25, Janvier 1985, p. 13-63 [31]J.M. Boi, E. Innocenti, A. Rauzy, P. Siegel, “Production Fields : a New approach to Deduction Problems and two Algorithms for propositional Calculus”, Revue d'Intelligence Artificielle, vol 6 - n° 3/1992 , p 235, 255. Equilibrage de charge dynamique avec un nombre ´ variable de processeurs bas´e sur des m´ethodes de partitionnement de graphe Cl´ement Vuchener To cite this version: Cl´ement Vuchener. Equilibrage de charge dynamique avec un nombre variable de processeurs ´ bas´e sur des m´ethodes de partitionnement de graphe. Distributed, Parallel, and Cluster Computing. Universit´e de Bordeaux, 2014. French. HAL Id: tel-00952777 https://tel.archives-ouvertes.fr/tel-00952777 Submitted on 27 Feb 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THESE ` PRESENT ´ EE´ A` L’UNIVERSITE DE BORDEAUX ´ ECOLE DOCTORALE DE MATH ´ EMATIQUES ET ´ D’INFORMATIQUE Par Cl´ement VUCHENER POUR OBTENIR LE GRADE DE DOCTEUR SPECIALIT ´ E : INFORMATIQUE ´ Equilibrage de charge dynamique avec un nombre ´ variable de processeurs bas´e sur des m´ethodes de partitionnement de graphe Soutenue le : 7 f´evrier 2014 Apr`es avis des rapporteurs : Pierre Manneback Professeur Bora U¸car . . . . . . . . Charg´e de Recherche Devant la commission d’examen compos´ee de : Florent Duchaine . Senior Researcher . . . . Examinateur Aur´elien Esnard . . Maˆıtre de Conf´erences Directeur de Th`ese Pierre Manneback Professeur . . . . . . . . . . . . Pr´esident du Jury & Rapporteur Fran¸cois Pellegrini Professeur . . . . . . . . . . . . Examinateur Jean Roman . . . . . Professeur . . . . . . . . . . . . Directeur de Th`ese Bora U¸car . . . . . . . . Charg´e de Recherches Rapporteur 2014iiiii Remerciements Avant tout, je remercie mes directeurs de th`ese Jean Roman et Aur´elien Esnard qui ont accept´e d’encadrer cette th`ese. Et plus particuli`erement Aur´elien pour tout le temps qu’il m’a accord´e, ces longues discussions qui ont permis `a cette th`ese d’avancer et tous les conseils donn´es. Je remercie Pierre Manneback et Bora U¸car qui ont accept´e de rapporter cette th`ese malgr´e des d´elais tr`es courts, ainsi que les autres membres du jury : Fran¸cois Pellegrini et Florent Duchaine pour l’int´erˆet port´e `a mes travaux. Je remercie ´egalement S´ebastien Fourestier et, encore une fois, Fran¸cois Pellegrini pour toute leur aide sur Scotch et comment y ajouter ma m´ethode de partitionnement. Je remercie toute l’´equipe INRIA HiePACS au sein de laquelle j’ai effectu´e cette th`ese et plus particuli`erement les autres doctorants de l’´equipe qui m’ont tenu compagnie pendant pr`es de trois ans pour certains.ivv Equilibrage de charge dynamique avec un nombre variable ´ de processeurs bas´e sur des m´ethodes de partitionnement de graphe R´esum´e L’´equilibrage de charge est une ´etape importante conditionnant les performances des applications parall`eles. Dans le cas o`u la charge varie au cours de la simulation, il est important de redistribuer r´eguli`erement la charge entre les diff´erents processeurs. Dans ce contexte, il peut s’av´erer pertinent d’adapter le nombre de processeurs au cours d’une simulation afin d’obtenir une meilleure efficacit´e, ou de continuer l’ex´ecution quand toute la m´emoire des ressources courantes est utilis´ee. Contrairement au cas o`u le nombre de processeurs ne varie pas, le r´e´equilibrage dynamique avec un nombre variable de processeurs est un probl`eme peu ´etudi´e que nous abordons ici. Cette th`ese propose diff´erentes m´ethodes bas´ees sur le repartitionnement de graphe pour r´e´equilibrer la charge tout en changeant le nombre de processeurs. Nous appelons ce probl`eme « repartitionnement M × N ». Ces m´ethodes se d´ecomposent en deux grandes ´etapes. Dans un premier temps, nous ´etudions la phase de migration et nous construisons une « bonne » matrice de migration minimisant plusieurs crit`eres objectifs comme le volume total de migration et le nombre total de messages ´echang´es. Puis, dans un second temps, nous utilisons des heuristiques de partitionnement de graphe pour calculer une nouvelle distribution optimisant la migration en s’appuyant sur les r´esultats de l’´etape pr´ec´edente. En outre, nous proposons un algorithme de partitionnement k-aire direct permettant d’am´eliorer le partitionnement biais´e. Finalement, nous validons cette th`ese par une ´etude exp´erimentale en comparant nos m´ethodes aux partitionneurs actuels. Mots-cl´es Simulation num´erique, parall´elisme, ´equilibrage de charge dynamique, redistribution, partitionnement de graphe, repartitionnement.vi Dynamic Load-Balancing with Variable Number of Processors based on Graph Partitioning Abstract Load balancing is an important step conditioning the performance of parallel programs. If the workload varies drastically during the simulation, the load must be redistributed regularly among the processors. Dynamic load balancing is a well studied subject but most studies are limited to an initially fixed number of processors. Adjusting the number of processors at runtime allows to preserve the parallel code efficiency or to keep running the simulation when the memory of the current resources is exceeded. In this thesis, we propose some methods based on graph repartitioning in order to rebalance the load while changing the number of processors. We call this problem “M × N repartitioning”. These methods are split in two main steps. Firstly, we study the migration phase and we build a “good” migration matrix minimizing several metrics like the migration volume or the number of exchanged messages. Secondly, we use graph partitioning heuristics to compute a new distribution optimizing the migration according to the previous step results. Besides, we propose a direct k-way partitioning algorithm that allows us to improve our biased partitioning. Finally, an experimental study validates our algorithms against state-of-the-art partitioning tools. Keywords Numerical simulation, parallelism, dynamic load-balancing, redistribution, graph partitioning, repartitioning.Table des mati`eres 1 Introduction 1 2 Etat de l’art ´ 5 2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Mod´elisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 M´ethodes de partitionnement de graphe . . . . . . . . . . . . . . . . . . . 9 2.2.3 Etat de l’art des outils de partitionnement . . . . . . . . . . . . . . . . . . 11 ´ 2.3 Repartitionnement pour l’´equilibrage dynamique . . . . . . . . . . . . . . . . . . 13 2.3.1 Mod´elisation du probl`eme de repartitionnement . . . . . . . . . . . . . . . 13 2.3.2 M´ethodes de repartitionnement de graphe . . . . . . . . . . . . . . . . . . 14 2.4 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3 Mod`ele de migration pour le repartitionnement M × N 25 3.1 Notations et d´efinitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 G´en´eralit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2 D´efinitions pour le repartitionnement M × N . . . . . . . . . . . . . . . . 27 3.2 Matrices de migration optimales dans le cas ´equilibr´e . . . . . . . . . . . . . . . . 28 3.3 Construction des matrices de migration . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.1 M´ethode bas´ee sur la chaˆıne (1D) . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.2 M´ethode d’appariement (Matching) . . . . . . . . . . . . . . . . . . . . . 42 3.3.3 M´ethode gloutonne (Greedy) . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.4 Programme lin´eaire (LP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4 Evaluation des m´ethodes et conclusion . . . . . . . . . . . . . . . . . . . . . . ´ . . 62 4 Repartitionnement M × N 67 4.1 Repartitionnement M × N bas´e sur le partitionnement biais´e (BIASED) . . . . . 67 4.1.1 M´ethodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1.2 Limitations des partitionneurs . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2 Partitionnement k-aire direct (KGGGP) . . . . . . . . . . . . . . . . . . . . . . . 73 4.2.1 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.2.2 Crit`eres de s´election . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.3 Complexit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.4 Am´eliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 ´ 4.3 Repartitionnement M × N bas´e sur la diffusion (DIFF) . . . . . . . . . . . . . . 85 4.4 Partitionnement biais´e `a l’aide d’hyper-arˆetes de repartitionnement . . . . . . . . 89 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 viiviii TABLE DES MATIERES ` 5 R´esultats 91 5.1 M´ethodologie exp´erimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2 Influence du coˆut de migration et du facteur de repartitionnement . . . . . . . . 94 5.3 Influence du nouveau nombre de processeurs . . . . . . . . . . . . . . . . . . . . . 97 5.4 Comparaison sur des graphes complexes . . . . . . . . . . . . . . . . . . . . . . . 101 5.5 Etude de la complexit´e en temps . . . . . . . . . . . . . . . . . . . . . . . . . ´ . . 110 6 Conclusion et Perspectives 115 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 A Programmes lin´eaires pour optimiser les diff´erentes m´etriques 119 A.1 Minimisation de TotalV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.2 Minimisation de MaxV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 A.3 Minimisation de TotalZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 A.4 Minimisation de MaxZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 B Documentation du KGGGP dans Scotch 123 C R´esultats suppl´ementaires 125 C.1 Influence du coˆut de migration et du facteur de repartitionnement . . . . . . . . 125 C.2 Comparaison sur des graphes complexes . . . . . . . . . . . . . . . . . . . . . . . 126 Bibliographie 133 Liste des publications 137Chapitre 1 Introduction Une simulation num´erique mod´elise g´en´eralement l’´evolution en temps d’un ph´enom`ene physique dans un domaine de l’espace. Souvent, on utilise un sch´ema it´eratif en temps et une discr´etisation de l’espace via un maillage d’´el´ements g´eom´etriques (triangles, carr´es, t´etra`edres, etc.). Des simulations de plus en plus complexes demandent une plus grande puissance de calcul. Pour cela, ces applications doivent fonctionner en parall`ele sur plusieurs nœuds de calcul. Les donn´ees sont alors r´eparties sur les diff´erentes unit´es de traitement ou « processeurs ». Les processeurs ne pouvant pas acc´eder directement et rapidement aux donn´ees des autres processeurs, ce parall´elisme induit un surcout dˆu aux communications sur le r´eseau. La m´emoire ´etant distribu´ee, la r´epartition des calculs implique une distribution des donn´ees. Dans ce contexte, la distribution des donn´ees est une ´etape importante conditionnant les performances d’une simulation num´erique et elle est faite selon deux objectifs : — la charge de calcul affect´ee aux diff´erents processeurs doit ˆetre ´equilibr´ee pour minimiser le temps de calcul de chacun ; — les communications inter-processeurs induites par la distribution doivent ˆetre minimis´ees. Certaines simulations num´eriques complexes ont une charge de calcul qui peut ´evoluer de fa¸con impr´evisible ; c’est le cas par exemple des simulations de type AMR (Adaptive Mesh Refinement) o`u la discr´etisation de l’espace ´evolue pour ˆetre plus fine autour de points d’int´erˆet. La charge de certains processeurs peut augmenter plus rapidement que d’autres et il n’est alors plus possible de garder une mˆeme distribution tout le long de la simulation. De nouvelles distributions doivent ˆetre recalcul´ees pour r´e´equilibrer la charge lorsque le d´es´equilibre devient trop important. On parle alors d’´equilibrage dynamique. En plus des deux objectifs pr´ec´edents, la nouvelle distribution doit r´epondre `a deux nouvelles contraintes : — la nouvelle partition doit ˆetre calcul´ee rapidement en parall`ele ; — la migration des donn´ees n´ecessaire pour passer de l’ancienne distribution `a la nouvelle doit ˆetre la plus rapide possible, c’est-`a-dire qu’il faut que le moins possible de donn´ees ne change de processeurs. Le probl`eme de calcul de telles distributions peut ˆetre r´esolu `a l’aide du partitionnement d’un graphe non-orient´e en k parties. Les sommets du graphe repr´esentent les calculs et les arˆetes repr´esentent les d´ependances entre ces calculs. Chaque partie repr´esente l’ensemble des calculs affect´es `a un processeur. Deux sommets connect´es qui se trouvent dans deux parties diff´erentes (on dira que l’arˆete est coup´ee) induisent un besoin de communication entre ces deux processeurs. L’objectif de la distribution devient alors de construire une partition dont les parties sont de mˆeme taille et coupant un minimum d’arˆetes. Dans le cas de l’´equilibrage dynamique, on parlera de « repartitionnement ». Le partitionnement de graphe est un probl`eme d´ej`a bien ´etudi´e, que 12 CHAPITRE 1. INTRODUCTION ce soit dans le cas statique o`u une seule partition est calcul´ee, ou dynamique o`u la partition est recalcul´ee r´eguli`erement. Augmentation de la charge M = 4 N = 6 Figure 1.1 – Allocation dynamique de processeurs pour un code parall`ele dont la charge augmente. Lorsque la charge de calcul varie de fa¸con importante, il peut devenir int´eressant de changer le nombre de processeurs allou´es. Cela peut permettre de continuer la simulation quand toute la m´emoire des processeurs est utilis´ee, ou ainsi d’am´eliorer la consommation des ressources pour garder une bonne efficacit´e au cours de la simulation. Par exemple, un code AMR utilise initialement un maillage tr`es simple avec peu d’´el´ements, qu’il ne serait pas efficace de distribuer sur un grand nombre de processeurs. Avec le raffinement du maillage, la quantit´e de calcul augmente de fa¸con importante, et la parall´elisation sur un plus grande nombre de processeurs devient plus int´eressante, voire n´ecessaire si la taille du probl`eme d´epasse la capacit´e m´emoire des processeurs d´ej`a allou´es. Il faut alors ˆetre capable de calculer une nouvelle distribution pour un plus grand nombre de processeurs, comme illustr´e en figure 1.1. Augmentation de la charge relative A/B M + M' = 6 N + N' = 6 A B A B Figure 1.2 – Allocation dynamique de processeurs pour deux codes coupl´es A et B dont la charge relative de A par rapport `a B augmente. L’allocation dynamique de processeurs est ´egalement utile dans le cas des codes coupl´es. Ce sont diff´erents codes s’ex´ecutant en parall`ele et collaborant pour r´ealiser une simulation plus complexe. Ces codes doivent r´eguli`erement ´echanger des donn´ees entre eux durant la « phase de couplage » qui induit une synchronisation plus ou moins explicite. Il est donc n´ecessaire que les diff´erents codes avancent `a la mˆeme vitesse pour ne pas se ralentir entre eux. Cet ´equilibrage entre les codes peut s’av´erer tr`es difficile `a cause des natures tr`es diff´erentes de ces codes, ou dans le cas o`u au moins un des codes a une charge de calcul qui ´evolue dynamiquement. La figure 1.2 pr´esente un exemple avec deux codes coupl´es A et B utilisant initialement 3 processeurs chacun. Si le code B devient trop rapide par rapport `a A, on peut transf´erer un processeur du code B vers A. Cette th`ese propose un ensemble de m´ethodes permettant de r´esoudre le probl`eme d’´equilibrage dynamique de la charge avec changement du nombre de processeurs, et ce en se basant sur3 le repartitionnement de graphe. Nous appellerons ce probl`eme, le repartitionnement M × N. Ce repartitionnement doit r´ealiser les diff´erents objectifs d´ej`a cit´es : — ´equilibrage de la charge ; — minimisation des communications dues aux d´ependances de calculs ; — rapidit´e de calcul de la nouvelle partition ; — minimisation des communications dues `a la redistribution. Ceci devra ˆetre fait en prenant en compte `a la fois une charge variable et un nombre de processeurs variable. Ces m´ethodes de repartitionnement se divisent en deux ´etapes : la construction d’une matrice de migration puis le repartitionnement bas´e sur cette matrice de migration. Plusieurs m´ethodes de construction de matrices de migration permettent d’optimiser diff´erentes m´etriques relatives `a la migration des donn´ees. Deux m´ethodes de repartitionnement sont pr´esent´ees : l’une de partitionnement biais´e et l’autre diffusive. De plus, des limitations des m´ethodes de bissections r´ecursives utilis´ees habituellement sont mises en ´evidence dans le cadre du partitionnement biais´e et nous proposons une m´ethode de partitionnement k-aire direct pour y rem´edier. Nous commencerons par pr´esenter un ´etat de l’art du partitionnement et repartitionnement de graphe (chapitre 2). Puis, dans le chapitre 3, nous d´efinirons et construirons des mod`eles pour la migration. Le chapitre 4 pr´esentera des m´ethodes de repartitionnement s’appuyant sur les mod`eles de migration introduits au chapitre pr´ec´edent. Puis, nous ´evaluerons nos m´ethodes au travers d’une s´erie d’exp´eriences comparatives avec d’autres outils de repartitionnement de graphe (chapitre 5). Finalement, nous conclurons et pr´esenterons quelques pistes d’am´eliorations de ces m´ethodes dans le chapitre 6. Plusieurs annexes compl`etent ce manuscrit.4 CHAPITRE 1. INTRODUCTIONChapitre 2 Etat de l’art ´ Sommaire 2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Mod´elisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 M´ethodes de partitionnement de graphe . . . . . . . . . . . . . . . . . 9 2.2.3 Etat de l’art des outils de partitionnement . . . . . . . . . . . . . . . . ´ 11 2.3 Repartitionnement pour l’´equilibrage dynamique . . . . . . . . . . 13 2.3.1 Mod´elisation du probl`eme de repartitionnement . . . . . . . . . . . . . 13 2.3.2 M´ethodes de repartitionnement de graphe . . . . . . . . . . . . . . . . 14 2.4 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Contexte Une simulation num´erique mod´elise l’´evolution d’un ph´enom`ene physique dans le temps sur un domaine de l’espace. Ces simulations s’appuient sur une discr´etisation en temps et en espace. Le domaine de l’espace simul´e est discr´etis´e `a l’aide d’un maillage d’´el´ements g´eom´etriques : triangles, carr´es, t´etra`edres, ... La discr´etisation en temps permet de calculer l’´etat du syst`eme `a un instant donn´e `a partir de l’´etat pr´ec´edent. Plus pr´ecis´ement, l’´etat d’un ´el´ement est calcul´e `a partir de son ´etat pr´ec´edent et de l’´etat de quelques autres ´el´ements en fonction du mod`ele physique ; g´en´eralement, ce sont les ´el´ements voisins dans le maillage. Ces simulations, de plus en plus complexes, n´ecessitent d’ˆetre ex´ecut´ees en parall`ele. Le domaine doit donc ˆetre distribu´e parmi plusieurs unit´es de calcul. Le maillage est donc d´ecoup´e en autant de parties que de processeurs utilis´es. Le calcul de l’´etat d’un ´el´ement d´ependant de l’´etat d’autres ´el´ements, le plus souvent dans son voisinage, cette distribution induit des communications entre processeurs quand l’un d’entre eux n´ecessite les donn´ees poss´ed´ees par un autre. Ces communications sont synchronisantes et tous les processeurs doivent donc faire progresser la simulation au mˆeme rythme. Une bonne distribution ou partition des donn´ees doit donc fournir des parties ´equilibr´ees et minimisant le nombre de d´ependances de donn´ees entre processeurs, minimisant ainsi le temps de calcul et de communication. Par exemple, un code simulant la diffusion de la chaleur sur un maillage calcule la chaleur de chaque ´el´ement `a partir de sa propre chaleur et de celle des ´el´ements voisins `a l’it´eration pr´ec´edente. Une unit´e de calcul travaillant 56 CHAPITRE 2. ETAT DE L’ART ´ sur un domaine doit donc recevoir les temp´eratures des ´el´ements sur la fronti`ere des domaines voisins. La distribution des donn´ees peut ˆetre statique, c’est-`a-dire fix´ee au d´ebut de la simulation, ou dynamique qui ´evolue au cours de la simulation. Certaines simulations utilisent des maillages dynamiques : le domaine de simulation peut s’´etendre, par exemple pour la simulation d’une explosion, ou le maillage peut ˆetre raffin´e autour de certains points d’int´erˆet permettant ainsi d’utiliser peu d’´el´ements tout en gardant une bonne pr´ecision l`a o`u c’est n´ecessaire. Cette derni`ere m´ethode est appel´ee Adaptive Mesh Refinment (AMR). Au cours de ces simulations dynamiques, la charge de calcul des processeurs ´evolue de fa¸con h´et´erog`ene. Il est donc n´ecessaire de r´e´equilibrer r´eguli`erement cette charge en calculant une nouvelle partition des donn´ees. Une fois cette nouvelle partition r´ealis´ee, les donn´ees doivent ˆetre migr´ees vers leur nouveau propri´etaire. La nouvelle partition doit optimiser cette phase de migration en plus des crit`eres pr´ec´edents. Il existe une grande vari´et´e de m´ethodes pour partitionner des maillages. Les plus courantes sont les m´ethodes g´eom´etriques, s’appuyant uniquement sur les coordonn´ees des ´el´ements dans l’espace, et les m´ethodes bas´ees sur les graphes utilisant les d´ependances de calcul entre ´el´ements et ne s’int´eressant plus qu’`a la topologie et non `a la g´eom´etrie du probl`eme. 2.2 Partitionnement Le partitionnement de maillages `a l’aide de graphes utilise les d´ependances de calcul entre les ´el´ements pour construire un graphe. Certains partitionneurs utilisent un mod`ele d’hypergraphe, plus g´en´eral que le mod`ele de graphe. Un partitionneur de graphe ou d’hypergraphe calcule des partitions en prenant en compte deux objectifs : — les parties doivent ˆetre ´equilibr´ees, c’est-`a-dire de mˆeme taille. Les partitionneurs sont g´en´eralement tol´erants et se contentent de cr´eer des parties `a peu pr`es ´equilibr´ees `a un « facteur de d´es´equilibre » pr`es. Un facteur de d´es´equilibre de 5% veut dire qu’une partie pourra atteindre jusqu’`a 1, 05 fois sa taille id´eale. Ce premier objectif permet d’optimiser le temps de calcul de la simulation. — une fonction de coˆut, appel´ee coupe du graphe, est minimis´ee. Cette fonction de coˆut varie suivant les mod`eles mais repr´esente le temps de communication entre les processeurs. 2.2.1 Mod´elisation Pour pouvoir appliquer le partitionnement de graphe ou d’hypergraphe `a un probl`eme donn´e, il est n´ecessaire de mod´eliser celui-ci. Il est important de choisir une mod´elisation adapt´ee au probl`eme pour que le partitionneur puisse cr´eer une partition optimisant les bons crit`eres pour cette simulation. a) Mod´elisation `a l’aide de graphes L’approche la plus courante consiste `a mod´eliser les ´el´ements `a distribuer sous forme d’un graphe. Le graphe construit doit mod´eliser les contraintes du calcul distribu´e : ´equilibrage de charge et r´eduction de communications. Un graphe est d´efini par un ensemble de sommets et un ensemble d’arˆetes connectant les sommets par paires. Le graphe est donc construit avec un sommet pour repr´esenter chaque ´el´ement. Les arˆetes de ce graphe servent `a repr´esenter les d´ependances entre les ´el´ements. Par exemple, le calcul sur un ´el´ement peut n´ecessiter les donn´ees des ´el´ements voisins dans le maillage. Un sommet est donc connect´e `a tous les sommets repr´esentant les ´el´ements voisins dans le maillage.2.2. PARTITIONNEMENT 7 Si des ´el´ements sont associ´es `a des charges de calcul diff´erentes, il est possible d’associer des poids aux sommets repr´esentant ces charges de calcul. De la mˆeme fa¸con, si certaines communications sont plus coˆuteuses que d’autres, un poids peut ˆetre affect´e aux arˆetes. Un partitionneur de graphe optimise deux objectifs : l’´equilibrage et la coupe. La taille d’une partie est le nombre de sommets dans cette partie ou, s’ils sont pond´er´es, la somme des poids de ceux-ci. La fonction de coˆut la plus g´en´eralement utilis´ee dans les partitionneurs de graphe est le nombre d’arˆetes coup´ees (ou la somme de leurs poids). Une arˆete est dite « coup´ee » lorsque ses deux extr´emit´es sont affect´ees `a des parties diff´erentes. On vise ainsi `a r´eduire le volume de donn´ees `a communiquer entre processeurs. La figure 2.1 pr´esente la mod´elisation d’un maillage : une grille de 2 × 3 carr´es sous forme de graphe. Chaque sommet du graphe correspond `a un carr´e de la grille et est reli´e aux sommets correspondant `a ses voisins dans le maillage. Figure 2.1 – Un maillage de 6 ´el´ements et le graphe associ´e mod´elisant les d´ependances. Cette mod´elisation, bien que tr`es r´epandue, ne mod´elise pas toujours parfaitement le volume de communication n´ecessaire pour la distribution induite. On pourrait penser que comme une arˆete relie deux sommets, chaque arˆete coup´ee induit deux sommets devant communiquer. Mais un sommet peut avoir plusieurs arˆetes coup´ees par la mˆeme partie et la coupe du graphe peut sur´evaluer le volume de communication induit par cette partition. Sur la figure 2.2, un maillage de 6 ´el´ements est partitionn´e en deux : une partie bleue et une partie verte. Il y a 4 ´el´ements qui ont au moins un voisin dans l’autre partie, ce sont les ´el´ements qui ont besoin d’ˆetre communiqu´es avec l’autre processeur. Mais 3 arˆetes sont coup´ees par la partition. Figure 2.2 – Maillage et graphe partitionn´es en deux.8 CHAPITRE 2. ETAT DE L’ART ´ Figure 2.3 – Un maillage de 6 ´el´ements et l’hypergraphe associ´e mod´elisant les d´ependances. Pour ne pas surcharger le dessin, seule l’hyper-arˆete correspondant `a l’´el´ement rouge est repr´esent´ee. b) Mod´elisation `a l’aide d’hypergraphes Il est ´egalement possible d’utiliser une mod´elisation `a partir d’hypergraphe. Le partitionnement d’hypergraphe est depuis longtemps utilis´e pour le partitionnement de VLSI [33, 59], mais il est ´egalement int´eressant dans le cas du partitionnement de matrices ou de maillages [63]. Les hypergraphes sont des extensions des graphes, o`u une arˆete appel´ee hyper-arˆete, ne connecte plus deux sommets mais un nombre quelconque de sommets. Un graphe peut ˆetre consid´er´e comme un hypergraphe particulier contenant uniquement des hyper-arˆetes de taille 2. Ces hyper-arˆetes plus complexes rendent la repr´esentation graphique des hypergraphe plus difficile. Il existe plusieurs fa¸cons de repr´esenter une hyper-arˆete ; par exemple, on peut dessiner une courbe entourant les sommets inclus dans l’hyper-arˆete. Il est aussi possible de repr´esenter une hyper-arˆete par un sommet sp´ecial reli´e aux sommets qu’elle connecte. Cette repr´esentation est en fait celle d’un graphe biparti dont les parties sont l’ensemble des sommets et l’ensemble des hyper-arˆetes. Comme avec les graphes, chaque ´el´ement d’un maillage est repr´esent´e par un sommet de l’hypergraphe. Mais les hyper-arˆetes permettent de mod´eliser diff´eremment les d´ependances. Une hyper-arˆete est associ´ee `a chaque sommet, repr´esentant toutes les d´ependances de cet ´el´ement. Une hyper-arˆete contient donc le sommet auquel elle est associ´ee, ainsi que tous les sommets qui d´ependent de celui-ci. La figure 2.3 montre une hyper-arˆete de l’hypergraphe mod´elisant la grille 2×3. Cette hyperarˆete est associ´ee au sommet rouge et contient tous les sommets voisins. Cette nouvelle mod´elisation des d´ependances permet d’utiliser des mod`eles de coupe diff´erents repr´esentant mieux les communications induites par le partitionnement. La coupe connectivit´e−1, aussi app´el´ee λ−1, permet de repr´esenter fid`element les communications [63]. Ce mod`ele de coupe prend en compte le nombre de parties coupant une arˆete. Si une hyper-arˆete est coup´ee par λ parties, son poids est compt´e λ−1 fois dans la coupe finale. En effet, une hyper-arˆete est associ´ee `a un ´el´ement et λ parties poss`edent des ´el´ements appartenant `a cette hyper-arˆete. Ces ´el´ements sont soit ceux qui ont une d´ependance sur l’´el´ement associ´e `a l’hyper-arˆete, soit l’´el´ement luimˆeme. Parmi ces λ parties, une poss`ede l’´el´ement et les λ−1 autres devront recevoir les donn´ees associ´ees `a cet ´el´ement. La figure 2.4 montre la mˆeme partition que la figure 2.2 mais en utilisant un mod`ele d’hypergraphe. Parmi les 6 hyper-arˆetes de cet hypergraphe, 4 sont coup´ees (en rouge). Ce sont les hyper-arˆetes associ´ees aux sommets se trouvant sur la fronti`ere. La mod´elisation `a l’aide d’hypergraphe permet de mod´eliser exactement la quantit´e de donn´ees se trouvant sur la fronti`ere des domaines contrairement `a la mod´elisation `a l’aide de graphe.2.2. PARTITIONNEMENT 9 Figure 2.4 – Maillage et hypergraphe partitionn´e en deux. Les hyper-arˆetes en rouge sont coup´ees par les deux parties. c) Sommets fixes Certains partitionneurs permettent d’utiliser des sommets fixes. Ces sommets sont initialement fix´es dans une partie et le partitionneur ne remettra pas en cause cette affectation, mais en tiendra compte dans l’´equilibrage et l’optimisation de la coupe. Les sommets fixes ont ´et´e largement utilis´es dans le cadre du partitionnement de VLSI [7] mais ont ´egalement trouv´e une utilisation dans le cadre du r´e´equilibrage dynamique [2, 9]. Le probl`eme de partitionnement `a sommets fixes est une version plus contrainte du partitionnement de graphe ou hypergraphe compl`etement libre. Bien que le probl`eme puisse paraitre plus simple, comme il y a moins de sommets `a placer dans les diff´erentes parties, les heuristiques ´elabor´ees pour le partitionnement libre peuvent avoir du mal `a prendre en compte ces nouvelles contraintes [3, 7]. 2.2.2 M´ethodes de partitionnement de graphe Le partitionnement d’un graphe ou d’un hypergraphe est un probl`eme NP-complet [20, GRAPH PARTITIONING]. On utilise donc diverses heuristiques pour pouvoir calculer une partition en un temps raisonnable. La plupart des m´ethodes utilis´ees s’appliquent aussi bien sur des graphes que sur des hypergraphes. La plupart des partitionneurs de graphe ou d’hypergraphe utilisent des m´ethodes appel´ees « multi-niveaux » [4, 22, 36]. L’approche multi-niveaux permet d’acc´el´erer les m´ethodes de partitionnement classiques tout en gardant une bonne qualit´e. Cette approche se d´ecompose en trois ´etapes, comme indiqu´e en figure 2.5. G0 G1 Gk ... P0 P1 Pk ... Contraction Expansion Partitionnement Initial Figure 2.5 – Phases d’un partitionnement multi-niveaux.10 CHAPITRE 2. ETAT DE L’ART ´ La phase de contraction : Dans un premier temps, la taille du graphe est r´eduite en fusionnant des sommets. Cela est r´ep´et´e pendant plusieurs it´erations, jusqu’`a obtenir un graphe suffisamment petit. Une suite de graphes de taille d´ecroissante a ainsi ´et´e cr´e´ee : (G0, G1, . . . , Gk). Le partitionnement initial : Une fois que le graphe a ´et´e suffisamment contract´e, on applique une heuristique de partitionnement pour calculer la partition Pk du graphe Gk. N’importe quelle strat´egie de partitionnement peut ˆetre appliqu´ee ici. Certaines seront d´etaill´ees par la suite. La phase d’expansion : La suite des diff´erents graphes construits pendant l’´etape de contraction est alors « remont´ee ». La partition Pi+1 du graphe Gi+1 est prolong´ee sur le graphe Gi puis cette nouvelle partition Pi est raffin´ee `a l’aide d’une heuristique am´eliorant localement la coupe. a) Strat´egies de contraction Il existe plusieurs heuristiques pour s´electionner les sommets `a fusionner. La plus connue, appel´ee Heavy Edge Matching (HEM), recherche les arˆetes de poids les plus ´elev´es et en fusionne les deux extr´emit´es. Cette op´eration est r´ep´et´ee jusqu’`a obtenir un graphe suffisamment petit. Dans un partitionneur supportant les sommets fixes, ces derniers doivent ˆetre trait´es de mani`ere particuli`ere pendant la phase de contraction. En effet, le graphe contract´e doit garder les mˆemes informations sur les sommets fixes. Dans certains partitionneurs, il peut ˆetre d´ecid´e de ne jamais fusionner ces sommets fixes. Dans d’autres, il peut ˆetre d´ecid´e de les fusionner seulement avec des sommets non fix´es ou fix´es dans la mˆeme partie. Dans ce cas, le sommet obtenu apr`es fusion est consid´er´e comme un sommet fixe dans le graphe contract´e. b) Strat´egies de partitionnement initial La strat´egie de partitionnement utilis´ee au niveau le plus bas dans un partitionneur multiniveaux peut ˆetre n’importe quelle strat´egie de partitionnement, y compris un autre algorithme multi-niveaux. Il existe une tr`es grande vari´et´e de m´ethodes de partitionnement ou de bissection comme par exemple des algorithmes gloutons ajoutant les sommets un `a un dans les parties [5, 6, 29], ou des algorithmes spectraux utilisant des propri´et´es d’alg`ebre lin´eaire pour obtenir une partition [53]. La strat´egie la plus utilis´ee est celle des bissections r´ecursives. Le graphe est coup´e r´ecursivement en deux parties jusqu’`a obtenir le nombre de parties souhait´e. Il est possible d’obtenir un nombre de parties qui n’est pas une puissance de 2 en cr´eant des parties d´es´equilibr´ees. Par exemple pour obtenir 3 parties, on cr´ee deux parties avec les proportions 1/3 et 2/3, la partie de taille 2/3 est ensuite coup´ee en deux parties ´egales de 1/3 chacune. Son int´erˆet r´eside dans la grande vari´et´e et qualit´e des heuristiques de bissection souvent mieux maˆıtris´ees que les heuristiques de partitionnement k-aires [35]. Le graphe peut ´egalement ˆetre partitionn´e directement en k parties ; on parlera de partitionnement k-aire direct. Ces strat´egies peuvent ˆetre plus rapides que les bissections r´ecursives car une seule partition est calcul´ee. Th´eoriquement, le partitionnement k-aire direct permet une meilleure qualit´e car il profite d’une vision globale du probl`eme que les bissections r´ecursives n’ont pas [60]. Mais en pratique, il est plus difficile de calculer une bonne partition k-aire directement et la m´ethode des bissections r´ecursives donne souvent de meilleurs r´esultats [35].2.2. PARTITIONNEMENT 11 c) Strat´egies de raffinement utilis´ees dans la phase d’expansion Les strat´egies de raffinement modifient une partition d´ej`a existante en changeant quelques sommets de partie pour am´eliorer la coupe. L’algorithme de Kernighan et Lin [39] (KL) raffine une bissection en cherchant des paires de sommets dont l’´echange am´eliore le plus la coupe (ou la d´egrade le moins). Un sommet d´eplac´e ne sera plus consid´er´e pour un ´echange dans la mˆeme passe. Ces ´echanges sont consid´er´es mˆeme s’ils d´egradent la coupe, cela permettant de ne pas rester bloqu´e sur une solution localement optimale mais qui pourrait ˆetre am´elior´ee en s’en ´eloignant plus. A la fin de la passe, seuls les ´echanges ` menant `a la meilleure coupe sont conserv´es. L’´echange par paires permet de conserver l’´equilibre mais rend l’algorithme complexe. Plusieurs passes peuvent ˆetre appliqu´ees pour am´eliorer encore plus la coupe. Fiduccia et Mattheyses [17] (FM) s’inspirent de cet algorithme pour d´ecrire un raffinement lin´eaire en temps en ne d´epla¸cant les sommets que un par un et grˆace `a une structure de donn´ees adapt´ee. L’´equilibre est conserv´e en se refusant d’effectuer des d´eplacements qui d´es´equilibreraient trop la partition, c’est-`a-dire que la partition d´epasserait la taille maximale donn´ee par le facteur de d´es´equilibre. Cet algorithme, initialement con¸cu pour les bissections, a ´egalement l’avantage de s’´etendre facilement aux k-partitions. Le principe g´en´eral reste le mˆeme, mais il y a plusieurs d´eplacements `a consid´erer pour chaque sommet. Les sommets fixes s’int`egrent facilement aux m´ethodes de types KL/FM, car il suffit de ne pas consid´erer ces sommets parmi les d´eplacements possibles. Comme un algorithme de raffinement se contente d’am´eliorer une partition d´ej`a existante en ne d´epla¸cant souvent que les sommets le long de la fronti`ere, il n’est pas toujours n´ecessaire de l’appliquer sur le graphe entier. Ces strat´egies sont souvent appliqu´ees sur un graphe « bande » ne contenant que les sommets `a une certaine distance de la fronti`ere entre les parties, les autres sommets ´etant r´eunis en un seul sommet fixe pour chaque partie appel´e « ancre ». La taille du probl`eme est ainsi largement r´eduite [10]. D’autres m´ethodes de raffinement s’inspirent de la diffusion d’un liquide dans le graphe [42,49]. Ces m´ethodes se basent sur des graphes bandes : un type liquide diff´erent pour chaque partie est inject´e dans chaque sommet ancre. Le liquide se diffuse it´erativement dans le graphe le long des arˆetes et est d´etruit lorsqu’il rencontre un autre type de liquide. Quand un sommet re¸coit plusieurs type de liquide, il choisit la partie dont il en re¸coit le plus. Cette heuristique tend `a cr´eer des parties aux formes tr`es lisses mais la coupe n’est pas toujours optimale. Elle aussi pour avantage d’ˆetre locale et donc d’ˆetre plus efficace en parall`ele que les heuristiques de type KL/FM. 2.2.3 Etat de l’art des outils de partitionnement ´ Il existe une grande vari´et´e d’outils de partitionnement. Le tableau 2.1 pr´esente quelques partitionneurs de graphe ou d’hypergraphe et quelques unes de leurs fonctionnalit´es. Les sommets fixes sont surtout support´es par les partitionneurs d’hypergraphe car ils sont utilis´es depuis longtemps pour le partitionnement de circuits int´egr´es (VLSI). Beaucoup de partitionneurs offrent le choix entre un partitionnement multi-niveaux r´ecursif ou directement k-aire, mais le partitionnement initial du multi-niveaux direct utilise le plus souvent des bissections r´ecursives. Metis [31] est un des partitionneurs les plus connus et utilis´es. Il poss`ede deux m´ethode de partitionnement : r´ecursif ou k-aire mais la m´ethode k-aire se base sur des bissections r´ecursives pour son partitionnement initial. Il existe ´egalement une version parall`ele : ParMetis permettant de cr´eer une partition en parall`ele sur au moins 2 processus. ParMetis propose ´egalement une m´ethode de repartitionnement permettant de r´e´equilibrer une partition existante [57]. hMetis est un partitionneur d’hypergraphe ´egalement disponible en version r´ecursive ou k-aire. Il supporte12 CHAPITRE 2. ´ETAT DE L’ART Outil Type Sommets fixes Parall`ele Type de multi-niveaux Partitionnement initial Metis [31] graphe non non bissections [34] — k-aire [35] bissections ParMetis [32] graphe non oui k-aire [37] bissections hMetis [30] hypergraphe oui non bissections [33] — non k-aire [38] bissections PaToH [64] hypergraphe oui non bissections — kPaToH [3] hypergraphe oui non k-aire bissections + matching Zoltan [1] hypergraphe oui oui bissections — Scotch [48] graphe oui non bissections — k-aire bissections PT-Scotch [48] graphe non oui bissections RM-Metis [2] graphe oui (exactement k) non k-aire k-aire direct (GGGP) Mondriaan [62] hypergraphe non non bissections — ML-Part [47] hypergraphe oui non bissections — Parkway [61] hypergraphe non oui k-aire bissections Chaco [24] graphe non non bissections — Table 2.1 – Partitionneurs de graphe et d’hypergraphe.2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 13 les sommets fixes mais ne peut optimiser que le nombre d’hyper-arˆetes coup´ees et non la coupe λ − 1. Scotch [48] est un partitionneur de graphe et de maillage sous licence libre. Il est tr`es configurable et modulaire. Il propose une grande vari´et´e de m´ethodes de partitionnement, mais seulement des m´ethodes de bissections sont disponibles pour le partitionnement initial. Depuis sa derni`ere version (6.0), il permet d’utiliser des sommets fixes et de r´e´equilibrer une partition existante. PT-Scotch est la version parall`ele multi-thread et multi-processus de Scotch. Zoltan [1] est une biblioth`eque permettant de g´erer la distribution des donn´ees pour des applications parall`eles. Il offre en particulier des fonctionnalit´es de partitionneur. Il est possible d’utiliser ParMetis ou Scotch, mais il contient ´egalement son propre partitionneur d’hypergraphe. Le partitionneur d’hypergraphe de Zoltan utilise des bissections r´ecursives et supporte les sommets fixes. Il est ´egalement capable de r´e´equilibrer la distribution des donn´ees lorsque celles-ci ´evoluent dynamiquement [8, 9]. 2.3 Repartitionnement pour l’´equilibrage dynamique Dans certaines simulations num´eriques, la charge varie dynamiquement. C’est par exemple le cas des simulations AMR (Adaptive Mesh Refinement) dans lesquelles la r´esolution du maillage s’adapte dynamiquement pour r´eduire la quantit´e de calcul tout en gardant une pr´ecision suffi- sante l`a o`u elle est n´ecessaire. La charge ne varie pas de fa¸con homog`ene et il devient n´ecessaire apr`es un certain temps de simulation de r´e´equilibrer la charge entre les diff´erents processeurs. Le graphe repr´esentant les donn´ees doit alors ˆetre « repartitionn´e ». Les objectifs du repartitionnement de graphe sont : — la charge de calcul doit ˆetre ´equilibr´ee entre tous les processeurs ; — le volume de donn´ees `a communiquer entre les processeurs doit ˆetre minimal ; — le temps de calcul de la nouvelle partition doit ˆetre minimal ; — la migration des donn´ees, c’est `a dire l’envoi depuis l’ancien propri´etaire des sommets vers le nouveau, doit ˆetre le plus rapide possible. Aux deux premiers objectifs communs avec le partitionnement classique, on ajoute la minimisation du temps de repartitionnement (calcul de la nouvelle partition et migration induite par celle-ci). Notons que pour obtenir une partition de qualit´e (d’apr`es les deux premiers crit`eres), il est souvent n´ecessaire de migrer beaucoup de sommets. 2.3.1 Mod´elisation du probl`eme de repartitionnement On peut exprimer le temps total de la simulation (Ttotal) `a minimiser sous la forme [8, 57] : Ttotal = α × (Tcalcul + Tcomm) + Trepart + Tmig avec : — α le nombre d’it´erations avant que la partition devienne trop d´es´equilibr´ee et qu’un repartitionnement devienne n´ecessaire ; — Tcalcul le temps d’une it´eration de calcul, pris sur le processeur le plus lent et donc minimis´e par l’´equilibrage ; — Tcomm le temps des communications entre processeurs, correspondant `a la coupe du graphe ; — Trepart le temps pass´e `a calculer la nouvelle partition ; — Tmig le temps de migration des sommets vers leur nouvelle partie.14 CHAPITRE 2. ETAT DE L’ART ´ Ce mod`ele d’une simulation it´erative est repr´esent´e en figure 2.6. Apr`es chaque it´eration de calcul, les processeurs effectuent une phase de communication collective qui les synchronise ; le temps de calcul en parall`ele est donc celui du processeur le plus lent. Apr`es α = 3 it´erations, la partition devient trop d´es´equilibr´ee ; une nouvelle partition est calcul´ee lors du repartitionnement puis les sommets sont migr´es pour respecter cette nouvelle partition. En pratique, le repartitionnement n’est pas effectu´e apr`es un nombre fixe d’it´erations mais quand le d´es´equilibre d´epasse un certain seuil. On peut alors consid´erer que α est le nombre moyen d’it´erations avant que ce seuil soit d´epass´e. Obtenir une nouvelle partition de qualit´e (c’est-`a-dire avec Tcalcul et Tcomm faibles), impose un repartitionnement plus complexe et une nouvelle partition plus ´eloign´ee de l’ancienne (Trepart et Tmig plus ´elev´es). Il est donc n´ecessaire de r´ealiser un compromis suivant la valeur de α entre la qualit´e de la nouvelle partition et la rapidit´e de sa construction et mise en place. Si le besoin de repartitionnement est rare (α ´elev´e), il faut privil´egier la qualit´e de la partition avant celle de la migration. Mais pour les applications tr`es dynamiques qui n´ecessitent des repartitionnements fr´equents (α faible), il faut mieux privil´egier la migration devant la qualit´e de la partition qui se d´egradera de toute fa¸con rapidement. Concernant la migration, diff´erents crit`eres peuvent ˆetre optimis´es [44]. L’objectif le plus souvent optimis´e est le volume total des donn´ees migr´ees, appel´e volume total de migration. Mais il peut aussi ˆetre int´eressant de minimiser le volume de migration par processeur, ou encore le nombre de messages n´ecessaires `a la migration d’un point de vue global ou par processeur. Les communications de migration peuvent ˆetre mod´elis´ees par une matrice que nous appellerons matrice de migration dans laquelle chaque ´el´ement repr´esente le volume de donn´ees d’un message. Chaque ligne est associ´ee `a un processeur (et `a son ancienne partie) et chaque colonne est associ´ee `a une nouvelle partie. L’´el´ement (i, j) repr´esente le volume de donn´ees que le processeur i enverra au processeur associ´e `a la nouvelle partie j. La figure 2.7 pr´esente deux exemples de repartitionnement. La partition initiale sur la fi- gure 2.7a est d´es´equilibr´ee : la partie 1 poss`ede quatre sommets alors que la partie 3 n’en a que deux. Les figures 2.7b et 2.7c pr´esentent deux nouvelles partitions et les matrices de migrations associ´ees. Les sommets migrants (en rouge) correspondent aux ´el´ements hors diagonale alors que les sommets ne migrant pas correspondent aux ´el´ements de la diagonale (les messages qu’une partie « s’envoie » `a elle-mˆeme). Par exemple, sur la figure 2.7c, la nouvelle partie 4 contient deux sommets de l’ancienne partie 4 et un de l’ancienne partie 1 : la quatri`eme colonne de la matrice contient donc un 1 sur la premi`ere ligne et un 2 sur la quatri`eme. 2.3.2 M´ethodes de repartitionnement de graphe Pour ´equilibrer la charge, il existe diff´erentes approches bas´ees sur le repartitionnement de graphe dont les plus courantes sont le Scratch-Remap, les m´ethodes diffusives et le partitionnement biais´e. Il existe d’autres approches bas´ees des m´ethodes g´eom´etriques (bissections r´ecursives ou SFC [52]) ou encore des m´ethodes spectrales modifi´ees pour prendre en compte la migration [23]. Nous allors maintenant pr´esenter les trois approches les plus courantes. a) Scratch-Remap La m´ethode la plus simple et la plus ´evidente est le « Scratch-Remap ». Cette m´ethode se d´ecompose en deux ´etapes. Dans un premier un temps, le graphe est partitionn´e « from scratch », c’est-`a-dire sans prendre en compte l’ancienne partition. Ensuite les parties obtenues sont renum´erot´ees pour optimiser la migration.2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 15 Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Repartitionnement Migration Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Repartitionnement Migration Figure 2.6 – Etapes d’un code se r´e´equilibrant toutes les ´ α = 3 it´erations.16 CHAPITRE 2. ETAT DE L’ART ´ 1 2 3 4 (a) Partition initiale d´es´equilibr´ee en 4 parties. 4 3 1 2     1 0 0 3 0 0 3 0 0 2 0 0 2 1 0 0     (b) Partition en 4 parties avec une mauvaise correspondance des parties. 1 2 4 3     3 0 0 1 0 3 0 0 0 0 2 0 0 0 1 2     (c) Mˆeme partition que pr´ec´edemment mais avec une bonne correspondance. Figure 2.7 – Exemples de repartitionnement. Les sommets migrants sont dessin´es en rouge. La figure 2.7 pr´esente deux exemples de repartitionnement produisant la mˆeme nouvelle partition, mais avec une num´erotation diff´erente des nouvelles parties. Un repartitionnement « from scratch » peut tout `a fait donner la partition de la figure 2.7b o`u tous les sommets sauf un sont migr´es, alors qu’en renum´erotant les nouvelles parties par rapport `a l’ancienne partition comme sur la figure 2.7c, seulement deux sommets doivent ˆetre migr´es. Dans PLUM, Oliker et Biswas [45] proposent une heuristique gloutonne pour r´esoudre le probl`eme d’association des nouvelles parties aux processeurs (remap). Cette heuristique est d´ecrite par l’algorithme 1. Il parcourt les ´el´ements Ci,j de la matrice de migration du plus grand au plus petit ´el´ement. La partie j est associ´ee au processeur i d`es que c’est possible, c’est-`a-dire si le processeur i est libre (free[i] est vrai) et si la partie j n’est pas d´ej`a associ´ee `a un processeur (unassigned[j] est vrai). L’algorithme se termine lorsque toutes les parties ont ´et´e affect´ees `a un processeur. Comme la m´ethode Scratch-Remap recalcule une partition sans prendre en compte la migration, celle-ci poss`ede g´en´eralement une bonne coupe car c’est le seul crit`ere optimis´e lors du partitionnement. En revanche, la migration n’est minimis´ee que dans un second temps et peut ˆetre tr`es sup´erieure `a l’optimal. Il est possible d’apporter quelques am´eliorations au Scratch-Remap. Pour obtenir un volume de migration plus faible, Oliker et Biswas [45] repartitionne en kM parties au lieu de M. Lors de la phase de remapping, k nouvelles parties sont associ´ees `a chaque processeur. Ce grain plus fin permet un volume de migration moindre mais une coupe un peu plus ´elev´ee. Schloegel et al. [58] proposent une autre variante du Scratch-Remap appel´ee LMSR (Locally Matched Scratch Remap) dans laquelle la phase de contraction du partitionnement multi-niveaux est contrainte pour ne fusionner que des sommets appartenant `a une mˆeme ancienne partie en esp´erant cr´eer une nouvelle partition avec des fronti`eres plus proches de l’ancienne partition. b) Diffusion Les m´ethodes diffusives s’inspirent du ph´enom`ene physique de diffusion de la chaleur pour r´e´equilibrer la charge. L’id´ee de base des m´ethodes diffusives est que chaque processeur ´echange2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 17 Algorithme 1 R´eaffectation des nouvelles parties aux anciens processeurs (remap) Entr´ee : Matrice de migration C de taille M × M map : vecteur d’association des nouvelles parties unassigned : vecteur de bool´eens initialement vrais free : vecteur de bool´eens initialement vrais n ← M L ← liste tri´ee des Ci,j par ordre d´ecroissant tant que n > 0 faire Prendre et retirer le premier ´el´ement Ci,j de L si free[i] ∧ unassigned[j] alors map[j] ← i free[i] ← faux unassigned[j] ← faux n ← n − 1 fin si fin tant que retourner map des sommets avec ses voisins selon le d´es´equilibre de charge entre les deux parties. Ces ´echanges locaux de sommets `a la fronti`ere des parties concern´ees permettent de r´e´equilibrer la charge. Dans la version it´erative de cette m´ethode, un r´e´equilibrage partiel est r´ep´et´e `a chaque it´eration. Lors de ce r´e´equilibrage partiel, deux processeurs voisins ´echangent un nombre de sommets proportionnel `a leur diff´erence de charge. Cybenko [12] calcule la nouvelle charge w (t+1) i d’une partie i `a l’it´eration t + 1, `a l’aide la formule : w (t+1) i = w (t) i + X j αij (w (t) j − w (t) i ). (2.1) Les αij sont des coefficients positifs ou nuls et tels que ∀i,P j αij ≤ 1 (chaque partie ne peut pas donner plus de charge qu’elle n’en poss`ede), permettant de choisir si les parties i et j ´echangeront facilement des sommets. Cela permet de favoriser les ´echanges entre parties proches dans le graphe ou entre processeurs proches sur le r´eseau. Apr`es plusieurs it´erations, cette m´ethode tend `a homog´en´eiser la charge, conform´ement au principe de diffusion de la chaleur. Le r´e´equilibrage peut ´egalement ˆetre r´ealis´e directement en cherchant la solution finale du probl`eme de diffusion `a l’aide d’un solveur. Hu et Blake [26] montrent que chercher la solution optimisant la norme 2 de la migration (la racine carr´e de la somme des carr´es de la taille de chaque message) est ´equivalent au probl`eme de diffusion. La solution est calcul´ee `a l’aide de la m´ethode du gradient conjugu´e. Ou et Ranka [46] expriment le probl`eme sous forme d’un programme lin´eaire pour minimiser la norme 1 de la migration (la somme des tailles de chaque message). Ce programme est r´esolu `a l’aide de la m´ethode du simplexe [43]. Une fois que la charge `a ´echanger entre chaque processeur a ´et´e d´ecid´ee, il faut choisir quels seront les sommets `a migrer. Ce choix est fait de fa¸con `a optimiser la coupe de la partition finale et peut ˆetre r´ealis´e `a l’aide d’un algorithme de type FM. Comme les d´eplacements de sommets s’effectuent entre des pairs de parties, il est n´ecessaire de trouver un bon ordonnancement de ses migrations [58]. En effet un processeur peut avoir besoin de transmettre plus de sommets qu’il n’en poss`ede initialement et il a donc besoin de recevoir des sommets avant de pouvoir en envoyer.18 CHAPITRE 2. ETAT DE L’ART ´ 1 2 3 (a) Partition d´es´equilibr´ee. 0 0 1 1 2 3 (b) Echanges de sommets entre ´ parties. 1 2 3 (c) Partition finale r´e´equilibr´ee. Figure 2.8 – Exemple de diffusion. Un exemple de repartitionnement par diffusion est illustr´e sur la figure 2.8. Tous les sommets sont de poids unitaires. A partir de la partition initialement d´es´equilibr´ee (figure 2.8a) ` , on calcule la migration optimale (figure 2.8b). Il faut alors d´eplacer un sommet de la partie 3 vers la partie 2. Ce sommet est choisi de fa¸con `a obtenir la meilleure coupe possible et ainsi obtenir la partition finale ´equilibr´ee de la figure 2.8c. Les m´ethodes diffusives permettent d’obtenir de faibles volumes de migration. Mais les heuristiques locales utilis´ees se comportent mal si il y a de grandes variations de charge. c) Partitionnement biais´e Le partitionnement peut ˆetre biais´e pour optimiser la migration. Les heuristiques habituelles sont modifi´ees pour ne plus optimiser seulement la coupe mais un compromis entre la coupe et le volume total de migration. Au lieu de modifier les heuristiques, il est ´egalement possible de modifier le graphe `a partitionner pour biaiser le partitionnement. Plusieurs ´etudes [2, 8, 9] montrent qu’il est possible de mod´eliser le probl`eme de repartitionnement `a l’aide de sommets fixes. Le graphe `a partitionner est enrichi pour mod´eliser les objectifs du repartitionnement : la coupe des arˆetes ajout´ees repr´esente la migration des sommets. Cette m´ethode est utilis´ee par le partitionneur d’hypergraphe Zoltan [9] et le partitionneur de graphe RM-Metis [2]. Des sommets sont ajout´es dans ce graphe pour mod´eliser les processeurs. Les processeurs ne sont pas des calculs `a distribuer ; le poids de ces sommets est donc nul et ils sont fix´es dans la partie du processeur qu’il mod´elise, c’est-`a-dire que le partitionneur ne pourra pas les placer dans une autre partie. Ces sommets fixes sont ensuite connect´es `a tous les sommets contenus dans l’ancienne partie associ´ee au sommet fixe. Ces nouvelles arˆetes permettent de mod´eliser la migration et sont donc appel´ees arˆetes de migration. En effet, si un sommet est migr´e, l’arˆete le connectant au sommet fixe de son ancienne partie sera coup´ee, ajoutant ainsi un coˆut de migration dans la taille de la coupe de la nouvelle partition. Le poids de l’arˆete de migration permet donc de repr´esenter la taille des donn´ees `a migrer. Sur la figure 2.9, on peut voir un exemple de repartitionnement qui illustre cette m´ethode. La partition en 5 parties est initialement d´es´equilibr´ee ; 5 sommets fixes (carr´es) sont ajout´es et reli´es par des arˆetes de migration aux sommets de leur partie respective (figure 2.9a). Apr`es l’utilisation d’un partitionneur `a sommets fixes, une nouvelle partition ´equilibr´ee est obtenue (figure 2.9b). Les arˆetes de migration associ´ees aux sommets ayant migr´e sont coup´ees (en rouge). La plus2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 19 (a) Graphe colori´e selon l’ancienne partition auquel les sommets fixes ont ´et´e ajout´es. (b) Graphe colori´e selon la nouvelle partition. Les arˆetes de migration coup´ees sont colori´ees en rouge. Figure 2.9 – Exemple de repartitionnement bas´e sur des sommets fixes.20 CHAPITRE 2. ETAT DE L’ART ´ grande partie des arˆetes n’est pas coup´ee (en vert). Le partitionneur a donc cr´e´e une nouvelle partition avec peu de migration (15 sommets migrent correspondant aux 15 arˆetes de migration coup´ees). Scotch [18,19] utilise une m´ethode de repartitionnement biais´e : sa m´ethode de raffinement par « diffusion » est modifi´ee dans le cas du repartitionnement. Pour prendre en compte la migration des sommets, une nouvelle source de « liquide » est ajout´ee pour chaque sommet l’incitant `a rester dans sa partie d’origine. Hendrikson et al. [23] proposent une autre approche du repartitionnement biais´e o`u chaque sommet u a un d´esir dk(u) d’ˆetre dans un partie k. Au lieu de minimiser le coˆut de migration, le but est de maximiser les d´esirs de chaque sommet (si p(u) est la partie de u, on maximise la somme P u dp(u)(u)). Deux approches sont pr´esent´ees : un raffinement de type FM modifi´e et une m´ethode de partitionnement spectrale prenant en compte les d´esirs des sommets. Le partitionnement biais´e permet un compromis entre qualit´e de la nouvelle partition et volume de migration grˆace `a un coˆut de migration introduit dans la coupe `a optimiser, par exemple, `a l’aide du poids des arˆetes de migration. Mais le repartitionnement est plus complexe car une nouvelle partition est compl`etement recalcul´ee avec des heuristiques modifi´ees. Le partitionnement biais´e peut ´egalement ˆetre hybride [57]. Dans le cadre d’un partitionnement multi-niveaux, le partitionnement initial est r´ealis´e `a l’aide d’une m´ethode Scratch-Remap ou diffusive, mais le raffinement appliqu´e lors de la phase d’expansion est biais´e pour optimiser la migration. 2.4 Positionnement Toutes les m´ethodes de repartitionnement pour l’´equilibrage dynamique pr´esent´ees ici ne s’int´eressent qu’au cas o`u le nombre de processeurs reste fixe. Le probl`eme de l’´equilibrage dynamique avec variation du nombre de processeurs est peu ´etudi´e. Iqbal et Carey [27,28] ont pourtant montr´e que faire varier le nombre de processeurs au cours de la simulation permet d’optimiser la consommation de ressources et mˆeme, dans certains cas, le temps d’ex´ecution. Bien choisir le nombre de processeurs allou´es `a une simulation est essentiel pour avoir une bonne performance ou efficacit´e. Si une simulation est lanc´ee en parall`ele sur un trop grand nombre de processeurs, le temps pass´e `a communiquer peut devenir trop important par rapport au temps de calcul. Utiliser le maximum de processeurs possible n’est pas toujours un bon choix suivant la taille du probl`eme. La taille du probl`eme pouvant varier au cours de la simulation, le nombre de processeurs devrait varier en cons´equence. Augmentation de la charge M = 4 N = 6 Figure 2.10 – Allocation dynamique de processeurs pour un seul code dont la charge augmente. Par exemple, un code AMR (Adaptive Mesh Refinement) commence sa simulation sur un maillage grossier contenant peu d’´el´ements. Puis, au cours de la simulation, le maillage est raf-2.4. POSITIONNEMENT 21 Augmentation de la charge relative A/B M + M' = 6 N + N' = 6 A B A B Figure 2.11 – Allocation dynamique de processeurs pour deux codes coupl´es A et B dont la charge relative de A par rapport `a B augmente. fin´e l`a o`u c’est n´ecessaire. La charge de calcul, initialement tr`es faible, croˆıt avec le temps. La simulation tr`es l´eg`ere au d´ebut finit par demander beaucoup de ressources, que ce soit en puissance de calcul ou en m´emoire. En commen¸cant le calcul sur tr`es peu de processeurs puis en l’augmentant quand la limite m´emoire est atteinte, il est possible de garder une meilleure efficacit´e tout le long de la simulation. Les surcoˆuts dus au parall´elisme inutile en d´ebut de simulation sont ´evit´es quand c’est possible. C’est la cas pr´esent´e sur la figure 2.10 : apr`es une augmentation significative de la charge, deux processeurs suppl´ementaires sont allou´es, et il faut donc effectuer un repartitionnement de 4 processeurs vers 6. L’allocation dynamique de processeurs peut aussi ˆetre utile dans le cas du couplage de codes. Dans un couplage de codes, plusieurs codes parall`eles s’ex´ecutent simultan´ement et doivent r´eguli`erement ´echanger des donn´ees. Cette phase d’´echange est synchronisante. Il est donc important que tous les codes concern´es progressent `a la mˆeme vitesse pour minimiser le temps d’attente lors de cette synchronisation. Le choix du nombre de processeurs utilis´es par chaque code doit ˆetre fait en prenant en compte les charges relatives de chacun. Cette ´equilibrage entre plusieurs codes peut ˆetre difficile, plus particuli`erement si la charge de ces codes peut varier dynamiquement. Pour r´e´equilibrer ces codes, une solution serait donc de r´eallouer des ressources d’un code vers un autre. Le nombre id´eal de processeurs allou´es `a chaque code peut donc ˆetre approch´e exp´erimentalement en corrigeant au cours de la simulation les d´es´equilibre qui surviendraient. Par exemple, sur la figure 2.11, le code A est devenu trop lent par rapport `a B, un processeur est donc r´eallou´e du code B vers le code A. Il faut repartitionner chacun des deux codes : de 3 processeurs vers 4 pour A, et de 3 vers 2 pour B. Pour r´ealiser ce changement du nombre de ressources, il est n´ecessaire de mettre en place une m´ethode repartitionnement prenant en compte le changement du nombre de parties. Nous appelons ce probl`eme, le repartitionnement M × N. Les objectifs du repartitionnement sont similaires `a ceux du repartitionnement classiques : — ´equilibrer la charge parmi les N processeurs ; — minimiser la coupe du graphe ; — calculer rapidement la nouvelle partition ; — minimiser la migration (diff´erentes m´etriques seront pr´esent´ees). Les outils de repartitionnement suivent d´ej`a ces objectifs mais ne sont pas pr´evus pour le changement du nombre de processeurs. La m´ethode de Scratch-Remap est facilement adaptable au repartitionnement M × N. Lors du partitionnement from scratch, l’ancienne partition, et donc l’ancien nombre de processeurs, n’a pas d’influence. L’algorithme de Remapping peut ˆetre facilement adapt´e en prenant en compte le fait que certaines parties ne seront pas associ´ees `a un ancien processeur (lors de l’ajout de processeurs), ou que des anciens processeurs ne recevront pas de nouvelles parties (lors de la suppression de processeurs).22 CHAPITRE 2. ETAT DE L’ART ´ Nous proposons donc une nouvelle m´ethode de repartitionnement adapt´ee au cas o`u le nombre de processeurs varie. La m´ethode propos´ee est pr´esent´ee sur la figure 2.12. Elle se d´ecompose en deux ´etapes. Dans un premier temps, nous cherchons `a construire des matrices de migrations adapt´ees `a ce probl`eme. Apr`es une ´etude de quelques matrices optimales, plusieurs m´ethodes seront pr´esent´ees dans le chapitre 3. La construction de la matrice de migration ne s’int´eresse pas aux sommets du graphe individuellement mais seulement aux parties, `a leurs tailles et `a leurs positions respectives. Ainsi, la construction de la matrice s’effectue `a partir du graphe quotient des parties. Ensuite, la matrice de migration construite est utilis´ee pour guider un repartitionnement du graphe remplissant les objectifs habituels du partitionnement de graphe : l’´equilibre et la coupe tout en fournissant une migration telle que pr´evue par la matrice construite `a l’´etape pr´ec´edente. Plusieurs approches sont possibles : un partitionnement biais´e utilisant des sommets fixes pour imposer une matrice de migration lors du repartitionnement ; une approche diffusive adapt´ee pour le repartitionnement M × N ; et un partitionnement biais´e utilisant des hyper-arˆetes pour optimiser les messages de migration sans utiliser de matrice de migration calcul´ee `a l’avance. Les m´ethodes de partitionnement biais´e mettent en ´evidence les limites des bissections r´ecursives utilis´ees dans les partitionneurs usuels. Un module de partitionnement k-aire utilisant une heuristique de greedy graph growing est ajout´ee dans le partitionneur Scotch pour am´eliorer la qualit´e de nos partitionnements.2.4. POSITIONNEMENT 23 Méthode d'appariement (Matching) Méthode de la chaîne (1D) Méthode gloutonne (Greedy) Méthode de partitionnement biaisé (Biased) Méthode diffusive (Diff) Hyper-arêtes de repartitionnement Matrice de migration Graphe quotient Nouvelle partition en N Graphe partitionné en M Construction de la matrice de migration M×N Repartitionnement M×N Programme linéaire (LP) Figure 2.12 – Vue d’ensemble de nos m´ethodes de repartitionnement M × N.24 CHAPITRE 2. ETAT DE L’ART ´Chapitre 3 Mod`ele de migration pour le repartitionnement M × N Sommaire 3.1 Notations et d´efinitions . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 G´en´eralit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2 D´efinitions pour le repartitionnement M × N . . . . . . . . . . . . . . 27 3.2 Matrices de migration optimales dans le cas ´equilibr´e . . . . . . . 28 3.3 Construction des matrices de migration . . . . . . . . . . . . . . . . 35 3.3.1 M´ethode bas´ee sur la chaˆıne (1D) . . . . . . . . . . . . . . . . . . . . . 35 3.3.2 M´ethode d’appariement (Matching) . . . . . . . . . . . . . . . . . . . 42 3.3.3 M´ethode gloutonne (Greedy) . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.4 Programme lin´eaire (LP) . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4 Evaluation des m´ethodes et conclusion . . . . . . . . . . . . . . . . 62 ´ La premi`ere ´etape de notre m´ethode de repartitionnement consiste `a construire une matrice de migration optimis´ee. Pour r´ealiser cela, il n’est pas n´ecessaire de disposer de toute l’information sur le graphe partitionn´e mais seulement du graphe quotient. Nous proposons plusieurs algorithmes permettant de construire des matrices de migration optimisant diff´erents crit`eres. Cette ´etape est r´esum´ee en figure 3.1. Dans un premier temps, nous ´enoncerons quelques d´efinitions g´en´erales sur le graphe et le partitionnement, puis des d´efinitions particuli`eres pour nos algorithmes de repartitionnement. Ensuite, nous ´etudierons plus en d´etails les matrices de migration dans le cas o`u l’ancienne partition est d´ej`a ´equilibr´ee. Enfin, nous d´ecrirons nos algorithmes de construction de matrice de migration, avant de conclure sur une comparaison de ces diff´erents m´ethodes. 3.1 Notations et d´efinitions Dans cette section, nous d´efinissons les notations et termes qui seront utilis´es dans cette th`ese. Nous rappelons d’abord les d´efinitions relatives au partitionnement, puis nous introduisons les nouvelles notations que nous utiliserons pour le repartitionnement M × N. 2526 CHAPITRE 3. MODELE DE MIGRATION ` Méthode d'appariement (Matching) Méthode de la chaîne (1D) Méthode gloutonne (Greedy) Matrice de migration Graphe quotient Graphe partitionné en M Construction de la matrice de migration M×N Programme linéaire (LP) Figure 3.1 – Vue d’ensemble de nos algorithmes de construction des matrices de migration. 3.1.1 G´en´eralit´es Soit G = (V, E), un graphe o`u V est l’ensemble des sommets et E l’ensemble des arˆetes. A` chaque sommet v est associ´e un poids wv repr´esentant la charge de calcul associ´e `a ce sommet. P Une arˆete e peut avoir un poids we repr´esentant le coˆut de la communication. On notera W = v∈V wv le poids total du graphe. D´efinition 1 (Partition). Une k-partition P de V est un ensemble de k sous-ensembles deux `a deux disjoints (Pi)i∈J1,kK de V tels que l’union de tous les sous-ensembles couvre V . D´efinition 2 (Poids d’une partie). Le poids d’une partie Pi not´e w(Pi) est la somme des poids des tous les sommets de la partie : w(Pi) = P v∈Pi wv. D´efinition 3 (Partition ´equilibr´ee). La k-partition P est dite ´equilibr´ee au facteur de d´es´equilibre ǫ ≥ 0 pr`es si ∀Pi ∈ P, w(Pi) ≤ (1 + ǫ) W k . En pratique, le facteur de d´es´equilibre souvent utilis´e est de l’ordre de quelques pour cent. Avec un facteur de 5 % (ǫ = 0, 05), une partie qui aurait une taille id´eale de 1000 ´el´ements, ne devra pas d´epasser 1050. D´efinition 4 (Coupe d’un graphe). On appelle taille de la coupe (ou par abus de langage, coupe) d’un graphe pour une partition donn´ee, le nombre d’arˆetes coup´ees ou la somme de leurs poids si elles sont pond´er´ees. Les arˆetes coup´ees sont les arˆetes dont les deux extr´emit´es sont dans des parties diff´erentes. D´efinition 5 (Graphe quotient). La graphe quotient Q = G/P d’un graphe G par rapport `a la partition P est obtenu `a partir de G en fusionnant les sommets appartenant `a une mˆeme partie de P. Les arˆetes devenues identiques apr`es la fusion des sommets sont ´egalement fusionn´ees et leurs poids sont additionn´es. Si les arˆetes n’´etaient pas pond´er´ees, le poids des arˆetes du graphe quotient est le nombre d’arˆetes fusionn´ees. Le graphe quotient Q = G/P poss`ede autant de sommets qu’il y a de parties dans P. Le poids de chaque sommet est le poids de la partie correspondante (la somme des poids des sommets de cette partie). Les sommets sont connect´es aux sommets correspondant aux parties voisines et le poids des arˆetes est la somme des poids des arˆetes coup´ees entre ces deux parties.3.1. NOTATIONS ET DEFINITIONS ´ 27 (a) Partition d’un graphe en 5 parties. 4 3 2 1 4 7 7 (b) Graphe quotient correspondant `a la partition. Figure 3.2 – Exemple de construction d’un graphe quotient pour une grille 10 × 10. La figure 3.2 montre la partition d’un graphe issu d’une grille 2D de taille 10 × 10 et le graphe quotient associ´e. La partition est en 5 parties et le graphe quotient poss`ede 5 sommets colori´es de la mˆeme couleur que la partie `a laquelle il est associ´e. La partition ´etant parfaitement ´equilibr´ee, le poids de chaque sommet est ´egal, et vaut 20. Le poids des arˆetes est plus variable : par exemple, l’arˆete entre le sommet jaunes et cyan a un poids 7, comme il y a 7 arˆetes dans le graphe partitionn´e connectant des sommets jaunes et cyan. 3.1.2 D´efinitions pour le repartitionnement M × N Dans le cas du repartitionnement, on distinguera deux partitions : la partition initiale P en M parties et une partition finale d´esir´ee P ′ en N parties. D´efinition 6 (Matrice de migration). On appelle matrice de migration, la matrice C de dimension M × N d´ecrivant les volumes de donn´ees `a migrer entre les diff´erents parties. L’´el´ement Ci,j correspond au nombre d’´el´ements en commun entre l’ancienne partie i et la nouvelle partie j. C’est aussi la quantit´e de donn´ees envoy´ee par le processeur i au processeur j si i 6= j ; si i = j, Ci,i est la quantit´e de donn´ees ne migrant pas, c’est-`a-dire restant « sur place ». Chaque ligne repr´esente une ancienne partie, donc la somme des ´el´ements sur cette ligne est ´egale `a sa taille. De la mˆeme fa¸con, une colonne repr´esente une nouvelle partie et la somme des ´el´ements de chaque colonne est ´egale `a sa taille. Pour ´evaluer la qualit´e des matrices de migration, nous d´efinissons plusieurs m´etriques : TotalV et MaxV sont d´ej`a introduits par Oliker et al. [45] ; nous y ajoutons deux nouvelles m´etriques TotalZ et MaxZ. Le volume total de migration, not´e TotalV, est la quantit´e de sommets qui migrent (ou la somme de leurs poids s’il sont pond´er´es). Cela correspond donc `a la somme des ´el´ements non-diagonaux de la matrice de migration. Le volume maximum par processeur, not´e MaxV, correspond `a la plus grande quantit´e de sommets (ou somme des poids) re¸cus et envoy´es par un mˆeme partie. Il correspond `a la plus grande somme sur une ligne et une colonne de mˆemes num´eros des ´el´ements hors diagonale de la matrice de migration.28 CHAPITRE 3. MODELE DE MIGRATION ` Le nombre total de messages n´ecessaires `a la migration, not´e TotalZ, correspond au nombre de non-z´eros hors diagonale. De la mˆeme fa¸con, on d´efinit le nombre maximal de messages (envoy´es et re¸cus) par processeur, not´e MaxZ. TotalZ vaut au plus M × N − min(M, N) dans le cas o`u tous les ´el´ements non-diagonaux de C sont non nuls. La figure 3.3 montre plusieurs cas de repartitionnement de la partition initiale de la figure 3.3a. Pour chaque repartitionnement, la matrice de migration et les diff´erentes m´etriques sont donn´ees. Les figures 3.3b et 3.3c montrent la mˆeme nouvelle partition mais avec une num´erotation diff´erente. Il est important de bien faire correspondre les anciennes et nouvelles parties pour avoir une faible migration. En effet, le volume total de migration TotalV est bien plus important dans le cas de la figure 3.3b. La figure 3.3d montre une partition diff´erente ayant une meilleure coupe mais une migration plus ´elev´ee. D´efinition 7 (Graphe biparti de migration). Le graphe biparti de migration est le graphe biparti G = ((A, B), E) o`u A est l’ensemble des M anciennes parties et B l’ensemble des N nouvelles parties. Il existe une arˆete dans E entre une ancienne et une nouvelle partie si elles partagent des sommets. Le poids de cette arˆete est la somme des poids des sommets partag´es. La matrice d’adjacence de ce graphe biparti est la matrice de migration C. Il existe une arˆete entre les sommets i et j si et seulement si Ci,j est non nul et si le poids de cette arˆete vaut Ci,j . Des exemples de graphes biparti de migration sont pr´esent´es sur la figure 3.3. Chaque arˆete du graphe repr´esente soit un message de migration, soit les donn´ees qui restent sur place lorsque l’arˆete relie une ancienne partie `a sa nouvelle partie associ´ee. D´efinition 8 (Hypergraphe de repartitionnement). L’hypergraphe de repartitionnement est l’hypergraphe comportant M sommets correspondant aux anciennes parties et N hyper-arˆetes correspondant aux nouvelles parties. Une hyper-arˆete contient tous les sommets correspondant aux anciennes parties avec lesquelles la nouvelle partie ´echange des sommets. Les hyper-arˆetes ne sont pas pond´er´ees. La matrice d’adjacence de cet hypergraphe est la matrice de migration sans prendre en compte les valeurs : on ne s’int´eresse qu’aux z´eros et non-z´eros. Le sommet v appartient `a l’hyper-arˆete e si et seulement si Cv,e est non nul. Chaque ligne de la matrice ou ancienne partie correspond `a un sommet de l’hypergraphe et chaque colonne ou nouvelle partie correspond `a une hyper-arˆete. Une hyper-arˆete contient tous les sommets dont l’´el´ement dans la matrice est non nul. Les hypergraphes de repartitionnement correspondant `a chaque matrice de migration sont donn´es dans la figure 3.3. La renum´erotation des parties entre les figures 3.3b et 3.3c ne change pas l’hypergraphe de repartitionnement mais seulement les num´eros des hyper-arˆetes. L’utilisation de ces graphes bipartis et hypergraphes permet de repr´esenter le sch´ema de communication utilis´e lors de la migration. Les hypergraphes de repartitionnement permettent une repr´esentation plus graphique des relations entre une ancienne et une nouvelle partition : c’est ce que l’on constate par exemple sur la figure 3.4 en le superposant avec le graphe quotient de l’ancienne partition. 3.2 Matrices de migration optimales dans le cas ´equilibr´e Dans un premier temps, nous allons ´etudier les matrices de migration dans le cas particulier o`u la partition initiale est d´ej`a parfaitement ´equilibr´ee. Plus pr´ecis´ement, on consid`ere que les partitions initiales et finales sont parfaitement ´equilibr´ees. Dans ce cas, W doit ˆetre un multiple commun de M et de N. On a donc W = k × ppcm(M, N) avec k un entier strictement positif.3.2. MATRICES DE MIGRATION OPTIMALES DANS LE CAS EQUILIBR ´ E´ 29 1 2 3 Coupe : 8 (a) Partition initiale d´es´equilibr´ee en 3 parties. 4 3 1 2 Coupe : 11 TotalV : 11 MaxV : 8 TotalZ : 4 MaxZ : 3   1 0 0 3 0 0 3 0 2 3 0 0   1 2 3 1 2 3 4 1 3 2 4 2 1 3 (b) Partition en 4 parties avec une mauvaise correspondance des parties. 1 2 4 3 Coupe : 11 TotalV : 3 MaxV : 3 TotalZ : 2 MaxZ : 2   3 0 0 1 0 3 0 0 0 0 3 2   1 2 3 1 2 3 4 1 3 2 1 3 4 2 (c) Mˆeme partition que pr´ec´edemment mais avec une bonne correspondance. 2 1 4 3 Coupe : 10 TotalV : 4 MaxV : 3 TotalZ : 3 MaxZ : 2   3 1 0 0 0 2 0 1 0 0 3 2   1 2 3 1 2 3 4 1 3 2 1 3 2 4 (d) Autre exemple de repartitionnement en 4 parties. Figure 3.3 – Exemples de repartitionnement avec les matrices de migration, graphes bipartis de migration, hypergraphes de repartitionnement et mesures associ´ees.30 CHAPITRE 3. MODELE DE MIGRATION ` 1 2 3 4 1 3 2 Figure 3.4 – Superposition de l’hypergraphe de repartitionnement de la figure 3.3c et du graphe quotient de la partition de la figure 3.3a. Pour simplifier notre discussion, on supposera que les poids des sommets sont unitaires. Ainsi le probl`eme de la partition du graphe est ´equivalent `a la partition de l’entier correspondant `a son poids. D´efinition 9 (Matrice de migration optimale). Nous appelons matrice de migration optimale, une matrice de migration C minimisant `a la fois le volume de total de migration (TotalV) et le nombre de messages (TotalZ). Lemme 1. Le volume total de migration optimal v´erifie : TotalVopt ≥ W  1 − min(M, N) max(M, N)  . D´emonstration. Il y a min(M, N) parties communes entre les partitions initiale et finale et |M − N| parties diff´erentes. Comme les partitions sont ´equilibr´ees, les tailles des parties initiales et finales sont respectivement W M et W N . Donc au plus, min(W M , W N ) = W max(M,N) donn´ees restent en place pour chaque partie commune. Le reste des donn´ees migre, donc TotalVopt ≥ W − min(M, N) × W max(M,N) = W × (1 − min(M,N) max(M,N) ). Lemme 2. Une matrice de migration minimisant le nombre de messages poss`ede au moins M + N − pgcd(M, N) coefficients non nuls. Le nombre minimal de messages v´erifie : TotalZopt ≥ max(M, N) − pgcd(M, N). D´emonstration. Le volume total de donn´ees est W = k × ppcm(M, N) = kaM = kbN avec a et b deux entiers strictement positifs premiers entre eux. Chaque partie poss`ede initialement ka sommets et finalement kb sommets. Soit G = ((A, B), E) le graphe biparti de migration. Pour d´enombrer les ´el´ements non nuls dans la matrice de migration, il suffit de compter le nombre d’arˆetes dans le graphe biparti de migration. On note (Gi = ((Ai , Bi), Ei))i∈J1,KK , les K composantes connexes de G. Pour chaque composante Gi , Mi = |Ai | processeurs envoient Mika sommets `a Ni = |Bi | processeurs qui re¸coivent Nikb sommets. Dans Gi , on a donc Wi = Mika = Nikb sommets qui sont ´echang´es, avec Mi et Ni non nuls. Comme Wi est un multiple commun de ka et kb et comme a et b sont premiers entre eux, le plus petit multiple commun de ka et kb est kab. Donc Wi ≥ kab. Le volume total ´echang´e W = PK i=1 Wi est donc sup´erieur ou ´egal `a Kkab. Autrement dit, K ≤ W kab = M b .3.2. MATRICES DE MIGRATION OPTIMALES DANS LE CAS EQUILIBR ´ E´ 31 D’autre part, on sait que MN = pgcd(M, N) × ppcm(M, N) et ppcm(M, N) = bN. On a donc M b = pgcd(M, N). On obtient alors K ≤ pgcd(M, N). Comme Gi est un graphe connexe, il poss`ede au moins Mi + Ni − 1 arˆetes. Donc le nombre total d’arˆetes |E| = PK i=1 |Ei | est au moins PK i=1 Mi + PK i=1 Ni − K = M + N − K. Comme K ≤ pgcd(M, N), on obtient |E| ≥ M + N − pgcd(M, N). Le nombre de coefficients non nuls dans la matrice de migration est donc au moins M + N − pgcd(M, N). TotalZ est le nombre de coefficients non nuls hors de la diagonale. Il y a au plus min(M, N) coefficients non nuls sur la diagonale. Donc TotalZ ≥ M + N − pgcd(M, N) − min(M, N) = max(M, N) − pgcd(M, N). B A×B 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 A 8 11 12 ka kb kab Figure 3.5 – Partitionnement d’un graphe chaˆıne en 8 et 12 parties, le motif de l’intersection A × B permet de construire la matrice de migration « en escalier ». Il existe diff´erentes m´ethodes pour obtenir de telles matrices avec un nombre minimal d’´el´ements non nuls. Une premi`ere m´ethode s’inspire du partitionnement d’un graphe « chaˆıne » ou d’un tableau, comme pr´esent´e sur la figure 3.5. Pour compter le nombre de messages, il faut compter le nombre d’arˆetes du graphe biparti. En reprenant les notations de la d´emonstration du lemme 2, la taille des parties de A est ka et celle des parties de B est kb. Tous les ppcm(ka, kb) = kab sommets, les s´eparateurs des anciennes parties et des nouvelles parties sont juxtapos´es. Le graphe biparti de migration est coup´e en sous-graphes (composantes connexes), chacun avec b anciennes parties de taille ka et a nouvelles parties de taille kb. Ce motif de longueur kab est donc r´ep´et´e W kab = M b = N a = pgcd(M, N) fois. Chacun de ces sous-graphes contient b + a − 1 arˆetes. Le nombre total d’arˆetes est donc (b + a − 1) × pgcd(M, N) = M + N − pgcd(M, N). Sur l’exemple de la figure 3.5, on a ppcm(8, 12) = 24 donc a = 3 et b = 2. Chacune des pgcd(8, 12) = 4 composantes connexes contient 3 + 2 − 1 = 4 arˆetes. Le graphe biparti contient 16 arˆetes. Cette construction donne une matrice « en escalier » comme montr´e sur la figure 3.7a. Il est ´egalement possible de construire une telle matrice r´ecursivement. On remplit la matrice avec des blocs qui sont des matrices carr´ees diagonales de taille min(M, N), et le bloc restant est rempli en r´ep´etant la mˆeme m´ethode sur le nouveau sous-probl`eme. Pour que la matrice soit une matrice de migration, il faut que les sommes sur les lignes ou colonnes soient respectivement les tailles des anciennes et nouvelles parties. Les valeurs diagonales sont donc W max(M,N) . La figure 3.6 donne un exemple de telle construction dans le cas 7 × 10 avec W = 7 × 10 en trois ´etapes. Calculer le nombre de non-z´eros avec cette m´ethode, revient `a appliquer l’algorithme d’Euclide. La division euclidienne de M par N donne M = qN + r : on commence `a remplir q blocs carr´es de taille N × N et on recommence r´ecursivement sur le bloc restant de taille r × N32 CHAPITRE 3. MODELE DE MIGRATION ` avec r < N. L’algorithme d’Euclide donne une suite d’´equations : M = q2N + r2 (3.1) . . . (3.2) ri−2 = qiri−1 + ri (3.3) . . . (3.4) rn−3 = qn−1rn−2 + rn−1 (3.5) rn−2 = qnrn−1 (3.6) avec r0 = M, r1 = N et rn−1 = pgcd(M, N). A chaque ´etape de l’algorithme, ` qiri−1 ´el´ements non nuls sont ajout´es dans la matrice : ce sont les ´el´ements diagonaux des qi blocs carr´es. Le nombre total d’´el´ements non nuls est donc Pn i=2 qiri−1. En faisant la somme de toutes les ´equations pr´ec´edentes, on obtient : nX−2 i=0 ri = Xn i=2 qiri−1 + Xn i=2 ri (3.7) Xn i=2 qiri−1 = r0 + r1 − rn−1 − rn (3.8) Xn i=2 qiri−1 = M + N − pgcd(M, N). (3.9) D’apr`es l’´equation 3.9, cette m´ethode construit bien une matrice avec un nombre minimal de non-z´eros. La figure 3.7d pr´esente un exemple d’une telle matrice. Th´eor`eme 3. Les bornes inf´erieures donn´ees dans les lemmes 1 et 2 sont atteintes. C’est-`a-dire : TotalVopt = W  1 − min(M, N) max(M, N)  (3.10) TotalZopt = max(M, N) − pgcd(M, N). (3.11) D´emonstration. La m´ethode de construction bas´ee sur l’algorithme d’Euclide construit une matrice de migration avec M + N − pgcd(M, N) coefficients non nuls. Les min(M, N) ´el´ements sur la diagonale sont maximis´es et valent W max(M,N) . On a donc TotalV = W  1 − min(M,N) max(M,N)  et TotalZ = max(M, N) − pgcd(M, N). Proposition 4. Soient M et N deux entiers tels que M < N. Soient D une matrice diagonale de dimension M × M dont les ´el´ements diagonaux sont W N et A une matrice de migration de dimension M × (N − M) minimisant le nombre de messages. Alors, la matrice D A
est une matrice de migration optimale au sens de la d´efinition 9. De mˆeme, dans le cas o`u M > N, si D est de taille N × N avec des ´el´ements diagonaux valant W M et si A est de taille (M − N) × N, alors  D A  est une matrice de migration optimale. D´emonstration. La d´emonstration est faite dans le cas M < N. La d´emonstration du cas M > N est similaire. La quantit´e de donn´ees qui reste sur place correspond `a la premi`ere diagonale de la matrice, soit D. Donc, on a W M N donn´ees qui restent sur place, ce qui est bien le cas optimal.3.2. MATRICES DE MIGRATION OPTIMALES DANS LE CAS EQUILIBR ´ E´ 33   7 7 7 7 reste 7 7 7   10 = 1 × 7 + 3   7 3 7 3 7 3 7 3 7 3 7 3 7 reste   7 = 2 × 3 + 1   7 3 7 3 7 3 7 3 7 3 7 3 7 1 1 1   3 = 3 × 1 + 0 Figure 3.6 – Exemple de construction r´ecursive (avec les divisions euclidiennes associ´ees `a chaque ´etape) d’une matrice de migration avec un nombre minimal de communications. D contient M ´el´ements non nuls et A contient par hypoth`ese un nombre minimal d’´el´ements non nuls pour sa taille : M + (N − M) − pgcd(M, N − M) = N − pgcd(M, N). Le nombre total d’´el´ements non nuls est donc M + N − pgcd(M, N) qui est bien le nombre minimal. La matrice D A
remplit bien les deux crit`eres pour ˆetre optimale. La figure 3.7 pr´esente quelques exemples de matrices de migration. La matrice de la figure 3.7a a ´et´e obtenue par la m´ethode inspir´ee du repartitionnement d’une chaˆıne qui donne une forme en escalier. Le nombre de messages est optimal mais pas le volume de migration. Seules 12 donn´ees restent sur place (les nombres en rouges) contre W M × N
= 49 dans le cas d’une migration optimale. Le volume de migration peut ˆetre am´elior´e `a l’aide d’une simple renum´erotation des parties similaires au « remapping » de la m´ethode Scratch-Remap (cf. section 2.3). La matrice obtenue est pr´esent´ee sur le figure 3.7b, 45 donn´ees restent alors sur place, ce qui est tr`es proche de l’optimal. D’apr`es le th´eor`eme pr´ec´edent, il nous suffit de combiner une matrice diagonale et une matrice minimisant le nombre de message pour obtenir une matrice optimale. La figure 3.7c montre la combinaison d’une matrice diagonale et d’une matrice en escalier. Dans le cas de la figure 3.7d, on construit r´ecursivement une matrice optimale `a l’aide de matrices diagonales en se basant sur l’algorithme d’Euclide. Bien que ces deux matrices soient optimales pour les m´etriques d´esir´ees (TotalV et TotalZ), la matrice construite `a partir de la matrice en escalier donne un nombre de messages par processeur (MaxZ) plus faible que la m´ethode r´ecursive. En pratique, les partitions ne sont pas parfaitement ´equilibr´ees car cela n’est pas n´ecessaire : on se contente d’une partition `a peu pr`es ´equilibr´ee `a un facteur de d´es´equilibre pr`es. Cette ´equilibre parfait peut mˆeme ˆetre impossible lorsque W n’est pas divisible par M ou N ou que le34 CHAPITRE 3. MODELE DE MIGRATION `   7 3 4 6 1 7 2 5 5 2 7 1 6 4 3 7   1 2 3 4 7 5 6 a b c d e f g h i j (a) Matrice « en escalier ».   7 3 6 4 1 7 2 5 5 7 1 2 6 4 7 3   1 2 3 4 7 5 6 a h b c d i e f j g (b) Matrice « en escalier » avec permutation des colonnes pour minimiser TotalV.   7 3 7 3 7 1 2 7 3 7 2 1 7 3 7 3   1 2 3 4 5 6 7 a b c d e f g h i j (c) Matrice optimale utilisant une sousmatrice en escalier.   7 3 7 3 7 3 7 3 7 3 7 3 7 1 1 1   1 2 4 3 5 6 7 a b c d e f g h i j (d) Exemple de matrice optimale construite par ajout de blocs diagonaux r´ecursivement. Figure 3.7 – Exemples de matrices de migration pour le cas 7 × 10 et leurs repr´esentations en hypergraphe de repartitionnement. Les ´el´ements nuls ne sont pas montr´es. Les lignes num´erot´ees de 1 `a 7 correspondent aux sommets et les colonnes num´erot´ees de a `a j correspondent aux hyper-arˆetes. Les ´el´ements en rouge montrent les donn´ees qui restent en place. Les ´el´ements en noir sont ceux qui migrent, la somme de ces ´el´ements donne le volume de migration.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 35 poids des sommets de permet pas un d´ecoupage en parties rigoureusement ´egales. Les r´esultats pr´esent´es dans cette section sur le nombre de messages restent vrais pour des d´es´equilibres faibles. En effet, il est possible de profiter de la tol´erance au d´es´equilibre des nouvelles parties pour mieux s’adapter aux anciennes parties l´eg`erement d´es´equilibr´ees et ´economiser des messages. Le volume de migration optimal reste proche. Dans le cas o`u la partition initiale est fortement d´es´equilibr´ee, il est difficile de donner des valeurs optimales pour tous les cas. Il est toujours possible d’effectuer la migration en max(M, N)−1 messages (le nombre minimal d’arˆetes d’un graphe biparti connexe ´etant M + N − 1), mais ce nombre n’est pas toujours minimal. 3.3 Construction des matrices de migration 3.3.1 M´ethode bas´ee sur la chaˆıne (1D) a) Cas ´equilibr´e Dans le cas d’une partition initiale ´equilibr´ee, la m´ethode la plus simple pour construire une matrice de migration permettant `a la fois une bonne migration (m´etriques TotalV, MaxV, TotalZ et MaxZ) et une bonne coupe, consiste `a r´eutiliser le principe du partitionnement de la chaˆıne pr´esent´ee dans la section 3.2. De telles matrices de migration peuvent ˆetre obtenues `a l’aide d’un repartitionnement bas´e sur des courbes de remplissage ou space filling curve (SFC) [52,54]. Ce repartitionnement g´eom´etrique construit une courbe remplissant l’espace `a partitionner, comme par exemple `a l’aide d’une courbe de Hilbert [54] (cf. figure 3.8). On peut facilement obtenir une partition en M parties en coupant cette courbe en M sections ´egales. Si on construit une nouvelle partition en N parties en utilisant la mˆeme courbe de remplissage, on obtient un repartitionnement bas´e sur la chaˆıne (la chaˆıne ´etant la courbe de remplissage). Cette m´ethode a l’inconv´enient de n´ecessiter des informations g´eom´etriques sur les donn´ees `a partitionner et donne une coupe assez ´elev´ee `a cause de la nature fractale des courbes utilis´ees. Pour appliquer le principe du partitionnement de la chaˆıne sur un graphe quelconque, il suffit de trouver un chemin dans le graphe quotient. L’utilisation du graphe quotient au lieu du graphe `a partitionner permet de laisser `a une heuristique de partitionnement classique le choix de la distribution des sommets. Ainsi, le probl`eme de coupe des courbes de remplissage est r´egl´e tout en gardant le mˆeme sch´ema de communication. Le chemin de M sommets dans le graphe quotient est alors d´ecoup´e en N nouvelles parties, un sommet (correspondant `a une ancienne partie) pouvant ˆetre partag´e entre plusieurs nouvelles parties. Le choix de ce chemin influence directement la coupe de la partition finale. En effet, comme une nouvelle partie peut prendre des sommets de plusieurs anciennes parties cons´ecutives dans ce chemin, il est pr´ef´erable que ces parties soient bien connect´ees entre elles. Il faudra donc trouver un chemin dont les arˆetes ont des poids ´elev´es dans le graphe quotient. Pour optimiser la migration, une renum´erotation des nouvelles parties est n´ecessaire, car en num´erotant les parties dans l’ordre du chemin, les num´eros sont d´ecal´es par rapport `a la partition initiale comme on peut le voir sur la figure 3.9. L’utilisation d’un chemin peut aussi ˆetre vue comme une renum´erotation des anciennes parties apr`es laquelle on applique le repartitionnement de la chaˆıne sur le nouvel ordre des parties. Donc, deux renum´erotations sont en fait n´ecessaires : l’une permutant les anciennes parties (ou lignes de la matrice de migration) en fonction du chemin, l’autre permutant les nouvelles parties (ou colonnes de la matrice de migration) pour optimiser la migration.36 CHAPITRE 3. MODELE DE MIGRATION ` (a) Partitionnement en 3. (b) Partitionnement en 5.   13 8 5 12 5 8 13   (c) Matrice de migration. Figure 3.8 – Partitionnement et repartitionnemnent d’une grille 8 × 8 bas´es sur une courbe de remplissage de Hilbert. B 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 A 8 11 12 (a) Num´erotation des nouvelles parties dans l’ordre du chemin. B 1 2 3 4 5 6 7 1 9 2 3 10 4 5 11 6 7 A 8 12 8 (b) Renum´erotation pour optimiser la migration. Figure 3.9 – Exemple de num´erotations des nouvelles parties. Les arˆetes en pointill´es correspondent aux « communications » d’un processeur vers lui-mˆeme. Les donn´ees qui ne migrent pas sont en gris clair.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 37 Nœud courant Partie suivante Partie précédente Figure 3.10 – Exemple d’´etape de l’algorithme de recherche de chemin `a partir de l’arbre des bissections. La zone verte contient les nœuds dont l’ordre est d´ej`a fix´e, la zone rouge ceux dont on ne connait pas encore l’ordre. Le choix de l’ordre est `a faire entre les deux sommets de la zone bleue claire. La recherche d’un tel chemin dans le graphe quotient est un probl`eme analogue `a celui du voyageur de commerce, qui est NP-complet [20, TRAVELING SALESMAN]. Il existe de nombreuses m´ethodes pour obtenir des chemins non optimaux mais assez proches de l’optimal, comme par exemple des algorithmes probabilistes. Mais certains « bons » chemins peuvent cr´eer des probl`emes dans le cas d’un partitionnement par bissections r´ecursives. En effet, une bissection devra couper ce chemin en deux en mˆeme temps que le graphe. La bissection du chemin est forc´ee par la num´erotation des nouvelles parties : elle s´epare les plus petits num´eros des plus grands. Une bissection du chemin par le milieu doit donc laisser la possibilit´e d’une bonne bissection du graphe. Dans le cas o`u la partition initiale a ´et´e r´ealis´ee par un partitionneur utilisant des bissections r´ecursives, l’arbre des bissections peut ˆetre utilis´e pour trouver rapidement un chemin. Les parties issues d’une bissection r´ecursive sont num´erot´ees dans l’ordre des feuilles. Les nœuds internes repr´esentent l’union des parties dans le sous-arbre. A l’aide d’un parcours en largeur de l’arbre, ` chaque nœud interne est visit´e. L’ordre de ses deux fils est choisi de fa¸con `a maximiser les connexions avec les parties (ou unions de parties) pr´ec´edentes et suivantes. Comme tout l’arbre n’a pas encore ´et´e visit´e, l’ordre de toutes les parties n’a pas encore ´et´e d´ecid´e. On prend donc la partie pr´ec´edente au mˆeme niveau dans l’arbre et la partie suivante au niveau sup´erieur comme indiqu´e sur la figure 3.10. La figure 3.12 pr´esente un exemple d’ex´ecution de cet algorithme sur le graphe quotient de la figure 3.11. L’arbre initial est celui de la figure 3.12a. Au niveau de la racine, il n’y a pas de choix `a faire car il n’y a ni partie pr´ec´edente ni suivante. Le premier choix arrive avec le nœud unissant 0 et 1. La partie suivante est 2–4 dont la connexion avec 0 est 39 + 14 = 53 et celle avec 1 est 17 + 34 = 51. La partie 0 est donc plac´ee en second comme indiqu´e sur la figure 3.12b. Sur la figure 3.12c, les connexions des parties 2 et 3–4 avec la partie pr´ec´edente 0 sont compar´ees. Enfin, les connexions des parties 3 et 4 avec les parties pr´ec´edente 0 et suivante 2 sont compar´ees, et l’ordre est conserv´e (figure 3.12d). En pratique, pour am´eliorer la qualit´e du chemin en gardant un algorithme rapide, toutes les solutions possibles sont recherch´ees quand on arrive sur un sous-arbre suffisamment petit. Une fois la nouvelle partition obtenue, il faut renum´eroter les parties pour optimiser la migration comme montr´e sur la figure 3.9. De la mˆeme fa¸con que le Scratch-Remap, il faut chercher la meilleure association entre anciennes et nouvelles parties. Mais dans le cas du partitionnement38 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65 0 1 2 3 4 Figure 3.11 – Exemple de partition initiale en 5 partie et du graphe quotient associ´e. de la chaˆıne, le choix est plus simple : — si M < N, pour chaque ancienne partie, on choisit la nouvelle partie qui re¸coit le plus de donn´ees ; — si M > N, pour chaque nouvelle partie, on choisit l’ancienne partie qui lui en envoie le plus. Les nouvelles parties qui ne sont pas associ´ees `a une ancienne prennent alors de nouveaux num´eros qui n’existaient pas dans l’ancienne partition : ce sont les N − M plus grands. On peut v´erifier par l’absurde que ces choix sont possibles dans le cas M < N. Cette m´ethode de renum´erotation poserait probl`eme si et seulement si une mˆeme nouvelle partie est le meilleur choix pour deux anciennes. Si une ancienne partie partage des donn´ees avec trois ou plus nouvelles parties, une de ces nouvelles parties ne re¸coit des donn´ees que de cette ancienne partie et ne serait le meilleur choix que pour celle-ci. Ces deux anciennes parties n’ont donc chacune des donn´ees partag´ees qu’avec deux nouvelles : les nouvelles parties ´etant plus petites, il y en a au moins deux. La nouvelle partie qui serait le meilleur choix pour les deux anciennes doit donc recevoir plus de la moiti´e des donn´ees de chacune des deux anciennes parties. Elle serait donc plus grande que les anciennes, ce qui est en contradiction avec l’hypoth`ese M < N. On peut faire un raisonnement similaire dans le cas M > N, en inversant les rˆoles des anciennes et nouvelles parties. b) Illustration dans le cas ´equilibr´e La figure 3.13 pr´esente un exemple de repartitionnement dans le cas o`u il y a 5 parties initiales ´equilibr´ees (1400 ´el´ements chacune) et 7 parties finales qui doivent contenir 1000 ´el´ements chacune pour ˆetre ´equilibr´ees. On commence par construire une matrice correspondant au repartitionnement de la chaˆıne comme pr´esent´e dans la section 3.2 (matrice en escalier) :   1000 400 0 0 0 0 0 0 600 800 0 0 0 0 0 0 200 1000 200 0 0 0 0 0 0 800 600 0 0 0 0 0 0 400 1000  3.3. CONSTRUCTION DES MATRICES DE MIGRATION 39 0–4 0–1 2–4 0 1 2 3–4 3 4 (a) Arbre de bissections initial. 0–4 0–1 2–4 1 0 2 3–4 3 4 (b) Permutation de 0 et 1. 0–4 0–1 2–4 1 0 3–4 3 4 2 (c) Permutation de 2 et 3–4. 0–4 0–1 2–4 1 0 3–4 3 4 2 (d) L’ordre entre 3 et 4 est pr´eserv´e. Figure 3.12 – Exemple de recherche de chemin par permutation de l’arbre des bissections. Ensuite, un chemin est recherch´e dans le graphe, maximisant la connexion entre les sommets successifs (les anciennes parties). Ici, le chemin choisi est 1, 0, 3, 4 et 2. Les lignes de la matrice sont permut´ees en cons´equence. Enfin, il faut renum´eroter les nouvelles parties pour minimiser le volume de migration. On choisit les nouvelles parties recevant le plus d’´el´ements des anciennes parties. Les nouvelles parties correspondant aux anciennes 1, 0, 3, 4 et 2, sont respectivement 0, 2, 3, 4 et 6. Renum´eroter les nouvelles parties revient `a permuter les colonnes de la matrice de migration. Les nouvelles parties non associ´ees aux anciennes (1 et 5) prennent de nouveaux num´eros, ici 5 et 6. Les colonnes sont permut´ees en cons´equence, les colonnes suppl´ementaires (5 et 6) peuvent ˆetre dans un ordre quelconque. La figure 3.14 pr´esente les hypergraphes de repartitionnement dans trois cas de repartitionnement. Dans les cas ou les nombres de parties initial et final ne sont pas premiers entre eux (8×12 et 12×14), les chemins sont coup´es en plusieurs parties : ce sont les composantes connexes utilis´ees dans la d´emonstration du lemme 2. On remarque ´egalement que les hyper-arˆetes sont de petites tailles et regroupent des anciennes parties voisines comme on le souhaitait. c) G´en´eralisation au cas d´es´equilibr´e Cette m´ethode peut ˆetre facilement adapt´ee dans le cas o`u la partition initiale est d´es´equilibr´ee. Il faut d’abord trouver un chemin dans le graphe quotient. Ensuite, connaissant cet ordre des parties, il suffit de le red´ecouper en parties de tailles ´egales. Dans le cas d´es´equilibr´e, toutes40 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65   800 0 0 0 0 0 600 0 1000 0 0 0 0 400 0 0 1000 0 0 400 0 200 0 0 1000 200 0 0 0 0 0 0 800 600 0   TotalV = 2400 MaxV = 1000 TotalZ = 6 MaxZ = 2 Figure 3.13 – Exemple de repartitionnement bas´e sur la chaˆıne dans le cas 5×7 (cas ´equilibr´e). 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21. Figure 3.14 – Applications du repartitionnement bas´e sur la chaˆıne dans le cas ´equilibr´e.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 41 900 500 1500 1700 2400 1000 1 0 3 4 2 1 0 3 4 6 2 5 39 39 14 34 17 62 65   400 100 0 0 0 0 0 0 900 0 0 0 0 0 0 0 1000 0 0 1000 400 600 0 0 900 0 0 0 0 0 0 100 1000 0 600   TotalV = 2800 MaxV = 1400 TotalZ = 6 MaxZ = 2 Figure 3.15 – Exemple de repartitionnement bas´e sur la chaˆıne dans le cas 5×7 (cas d´es´equilibr´e). les parties ne se valent pas. La forme de l’hypergraphe de repartitionnement utilis´e peut varier suivant l’ordre choisi. Par exemple, consid´erons le cas 5 × 7 o`u les parties sont initialement d´es´equilibr´ees avec comme poids dans l’ordre de 0 `a 4 : 500, 900, 2400, 1500 et 1700. En reprenant le mˆeme chemin 1 que dans le cas ´equilibr´e (figure 3.12), l’ordre des poids devient 900, 500, 1500, 1700 et 2400, et on obtient le repartitionnement pr´esent´e sur la figure 3.15. La figure 3.16 pr´esente alors les hypergraphes de repartitionnement obtenus avec la m´ethode de la chaˆıne dans le cas d´es´equilibr´e. Contrairement au cas ´equilibr´e, il n’est plus garanti que certaines s´eparations entre parties soient communes entre l’ancienne partition et la nouvelle. Le nombre de messages peut donc atteindre, au pire, M+N −1 messages. On peut voir que les hyperarˆetes forment les mˆemes chemins que ceux de la figure 3.14 mais « sans ˆetre coup´ees ». Dans le cas ´equilibr´e, le chemin ´etait d´ecoup´e en pgcd(M, N) parties correspondant aux composantes connexes du graphe biparti de repartitionnement utilis´ees dans la section 3.2. 1. Le chemin ne d´epend que de la connectivit´e du graphe quotient, pas du poids de ses sommets.42 CHAPITRE 3. MODELE DE MIGRATION ` 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21. Figure 3.16 – Applications du repartitionnement bas´e sur la chaˆıne dans le cas d´es´equilibr´e. 3.3.2 M´ethode d’appariement (Matching) Dans le cas ´equilibr´e, nous avons vu en section 3.2 qu’il est possible de construire des matrices de migration optimales, c’est-`a-dire optimisant `a la fois le volume de migration et le nombre de messages. Mais l’optimisation de la coupe n’est pas consid´er´ee. Comme on l’a vu avec la m´ethode de la chaˆıne, il peut ˆetre n´ecessaire de permuter la matrice de migration pour obtenir une bonne coupe. Mais une matrice optimale ne correspond pas toujours `a une chaˆıne : il ne suffit plus de trouver un bon chemin dans le graphe quotient. On cherche donc `a apparier correctement la matrice de migration avec le graphe quotient pour que la partition finale ait une bonne coupe. Comme les valeurs des ´el´ements de la matrice de migration n’influencent pas cet appariement, nous utiliserons l’hypergraphe de repartitionnement dans cette section. Le choix de la matrice de migration ou de l’hypergraphe repartitionnement conditionne la qualit´e de la migration. Nous d´ecidons de prendre une matrice de migration optimale (d’apr`es la d´efinition 9), plus pr´ecis´ement la matrice optimale compos´ee d’une diagonale et compl´et´ee avec une sous-matrice « chaˆıne » (comme celle de la figure 3.7c). En plus de minimiser T otalV et T otalZ, cette matrice a l’avantage de garder un M axZ plus faible que les autres matrices optimales. a) Probl`eme d’appariement entre le graphe quotient et l’hypergraphe de repartitionnement Une bonne matrice de migration ne suffit donc pas pour obtenir un bon repartitionnement. Elle ne permet que d’optimiser la migration et l’´equilibre. Un bon repartitionnement doit aussi fournir une coupe basse. La coupe sera principalement d´ecid´ee lors de l’´etape de repartitionnement, mais la matrice de migration a une influence sur la coupe. Une matrice de migration indique l’emplacement des nouvelles parties : elles seront l`a o`u se trouvent les anciennes parties dont elles prennent les sommets. Pour permettre au partitionneur de bien optimiser la coupe, il faut que les anciennes parties communiquant avec une mˆeme nouvelle partie soient proches. Pour obtenir ce r´esultat, on apparie l’hypergraphe de repartitionnement avec le graphe quotient, c’est-`a-dire qu’on cherche une correspondance entre les sommets de l’hypergraphe et ceux du graphe quotient comme pr´esent´e sur la figure 3.17. En effet, les hyper-arˆetes regroupent les anciennes parties donnant des sommets `a une mˆeme nouvelle partie, alors que les arˆetes du graphe quotient connectent les anciennes parties proches.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 43 1 2 3 4 5 6 7 7 2 1 4 3 6 5 Figure 3.17 – Appariement d’un graphe quotient et d’un hypergraphe de repartitionnement. Par exemple, il y a plusieurs fa¸cons d’apparier l’hypergraphe de repartitionnement pour repartitionner la partition initiale d’un maillage en grille visible sur la figure 3.18a. Les figures 3.18b et 3.18c pr´esentent deux possibilit´es d’appariement de l’hypergraphe de repartitionnement en le superposant au graphe quotient. Dans le premier cas, les hyper-arˆetes regroupant plusieurs sommets contiennent des sommets « proches » organis´es en cliques. En cons´equence la partition finale sur la figure 3.18d a des parties bien form´ees, alors que, dans le second cas, les hyper-arˆetes regroupent des sommets « ´eloign´es » et la partition finale sur la figure 3.18e a des parties d´econnect´ees sur le maillage. Les m´etriques pour ´evaluer la migration (TotalV, MaxV, TotalZ et MaxZ) sont les mˆemes dans ces deux cas, mais la coupe du graphe est bien meilleure dans le premier cas. Pour ´eviter de tels sc´enarios, une m´etrique suppl´ementaire est introduite pour estimer la qualit´e de la coupe finale. Cette m´etrique doit favoriser les nouvelles parties prenant des donn´ees `a un ensemble d’anciennes parties bien connect´ees, autrement dit des quasi-cliques. Cette m´etrique s’exprime `a l’aide du graphe quotient de l’ancienne partition et de l’hypergraphe de repartitionnement. b) D´efinition d’un score d’appariement Une fois la matrice choisie, il faut trouver une bonne correspondance entre les sommets du graphe quotient et ceux de l’hypergraphe de repartitionnement associ´e `a la matrice. Cet appariement n´ecessite la d´efinition d’un score. Notons Q = (VQ, EQ) le graphe quotient par rapport `a l’ancienne partition, H = (VH, EH) l’hypergraphe de repartitionnement d´ej`a appari´e (on consid`ere que les sommets de Q et de H sont les mˆemes, on pose V = VQ = VH) et ES(e) l’ensemble des arˆetes du sous-graphe de Q induit par l’hyper-arˆete e. Une premi`ere version simple de ce score compte la somme des poids des arˆetes des sous-graphes induits par chaque hyper-arˆete e : Score = X e∈EH   X e ′∈ES (e) we ′   (3.12) o`u ES(e) = {(i, j) ∈ EQ : i ∈ e ∧ j ∈ e} .44 CHAPITRE 3. MODELE DE MIGRATION ` (a) Hypergraphe de repartitionnement et partition initiale. (b) Exemple de bonne correspondance. (c) Exemple de mauvaise correspondance. (d) La partition est bien form´ee. (e) Certaines parties sont d´econnect´ees. Figure 3.18 – Deux cas d’application d’un mˆeme hypergraphe de repartitionnement.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 45 Il est possible d’´ecrire ce score sous forme matricielle. Notons X la matrice d’appariement (ou de permutation) de taille M × M `a trouver : Xi,i′ vaut 1 si et seulement si le sommet i de l’hypergraphe de repartitionnement est associ´e au sommet i ′ du graphe quotient, sinon 0. La matrice H repr´esente l’hypergraphe de repartitionnement 2 . Elle est de taille M × N et Hi,j vaut 1 si est seulement si le sommet i est inclus dans l’hyper-arˆete j. Q est la matrice d’adjacence du graphe quotient de taille M × M, Qi,j est le poids de l’arˆete entre les sommets i et j. Ces notations sont r´esum´ees sur la figure 3.19. i' j' j i k Qi',j' Xi,i' = 1 Xj,j' = 1 Figure 3.19 – Illustration des notations utilis´ees dans la formule de score avec une arˆete (i ′ , j′ ) du graphe quotient Q `a gauche et une hyper-arˆete k `a droite. Grˆace aux matrices `a valeurs binaires X et H, on peut ´ecrire la somme du poids des arˆetes ei ′ ,j′ dont les extr´emit´es i ′ et j ′ sont respectivement associ´ees `a deux sommets i et j dans la mˆeme hyper-arˆete k : Score = X i,j,i′ ,j′ ,k Xi,i′Xj,j′Hi,kHj,kQi ′ ,j′ soit (3.13) Score = X i,i′  Xi,i′ X j,j′ Xj,j′ X k Hi,kHj,k! Qi ′ ,j′ ! . (3.14) D´efinition 10 (Produit de Kronecker). Le produit de Kronecker de deux matrices A ⊗ B, A de taille m × n et B de taille m′ × n ′ , est une matrice de taille mm′ × nn′ , d´ecrite par la matrice bloc suivante :   A1,1B · · · A1,nB . . . . . . . . . Am,1B · · · Am,nB   . En notant A = HHT ⊗ Q, o`u ⊗ est le produit de Kronecker, et x le vecteur colonne de taille M2 tel que xiM+i ′ = Xi,i′ , le score s’´ecrit comme la forme quadratique : Score = x T Ax. (3.15) Dans l’´equation 3.14, on reconnait le coefficient de la matrice A = HHT ⊗ Q : AiM+i ′ ,jM+j ′ = X k Hi,kHj,k! Qi ′ ,j′ , 2. Par abus de langage, on confond les graphes et hypergraphes avec leurs matrices d’adjacence.46 CHAPITRE 3. MODELE DE MIGRATION ` 20 20 (a) Chaine de 3 parties r´eunies dans une mˆeme hyper-arˆete. Les deux parties aux extr´emit´es sont ´eloign´ees l’une de l’autre. 15 20 5 (b) Clique de 3 parties r´eunies dans une mˆeme hyper-arˆete. Figure 3.20 – Deux exemples de sous-graphes quotients appari´es avec une hyper-arˆete. P k Hi,kHj,k correspondant au coefficient (i, j) de la matrice HHT . Cette m´etrique favorise les hyper-arˆetes regroupant des sommets fortement connect´es. Mais elle est loin d’ˆetre parfaite, car elle ne prend pas en compte le nombre d’arˆetes du graphe quotient associ´ees `a une hyper-arˆete. A score ´egal, il apparait plus avantageux de favoriser trois sommets ` connect´es par trois arˆetes plutˆot que par deux. Sur l’exemple de la figure 3.20, les deux appariements d’une hyper-arˆete avec un graphe de 3 sommets ont le mˆeme score : 40. Pourtant, dans le cas de la figure 3.20a, les deux parties aux extr´emit´es de la chaˆıne peuvent ˆetre ´eloign´ees et la nouvelle partie cr´e´ee devra alors ˆetre ´etir´ee, ce qui n’est pas optimal pour la coupe. On pr´ef´ererait favoriser les cas de cliques comme sur la figure 3.20b, o`u les 3 parties sont bien regroup´ees. Pour corriger ces d´efauts, nous allons modifier le score pour prendre en compte la quantit´e d’arˆetes et la taille des hyper-arˆetes 3 . On propose la nouvelle formule de score suivante. Soient ES(e) l’ensemble des arˆetes du sous-graphe induit par l’hyper-arˆete e et K(e) l’ensemble des arˆetes d’une clique entre les sommets de l’hyper-arˆete e. La m´etrique s’exprime : ScoreR = X e∈EH   |ES(e)| |K(e)| X e ′∈ES (e) we ′   (3.16) o`u  ES(e) = {(i, j) ∈ EQ : i ∈ e ∧ j ∈ e} K(e) =  (i, j) ∈ V 2 : i 6= j ∧ i ∈ e ∧ j ∈ e . En reprenant l’exemple 3.20, les anciens scores sont multipli´es par 2/3 dans le cas de la chaˆıne (fig. 3.20a) et par 1 dans le cas de la clique (fig. 3.20b), ce qui donne les scores 26 et 40 : la clique est maintenant favoris´ee par rapport `a la chaˆıne. c) Choix d’un appariement par une m´ethode d’optimisation du score Afin de choisir un bon appariement, nous allons utiliser une m´ethode d’optimisation du score d´efini pr´ec´edemment. La maximisation de l’´equation 3.15 est un probl`eme d’optimisation quadratique `a valeurs binaires. C’est un probl`eme NP-difficile [20, QUADRATIC PROGRAMMING] mais d´ej`a beaucoup ´etudi´e, en particulier dans le domaine de la vision num´erique [15,41]. Une premi`ere solution consiste `a utiliser une m´ethode spectrale. Comme x T x = M est une constante, maximiser revient 3. On rappelle que la taille d’une hyper-arˆete est le nombre de sommets qu’elle regroupe.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 47 `a maximiser le quotient de Rayleigh-Ritz [25] x T Ax xT x . Dans le cas o`u x est `a coefficient r´eels, ce quotient atteint son maximum pour un vecteur propre associ´e `a la plus grande valeur propre. Mais ici x est `a valeur binaire, et la relaxation du probl`eme ne donne pas de solution convenable. En effet, approcher le vecteur propre avec un vecteur correspondant `a une permutation est une approximation trop importante. D’autres heuristiques pour trouver un bon appariement sont possibles, comme par exemple des algorithmes probabilistes, combinatoires de type branch & bound, ... Nous avons choisi d’utiliser un algorithme de recuit simul´e [40] qui donne des r´esultats satisfaisants. En partant d’une correspondance quelconque, des permutations de deux sommets al´eatoires sont appliqu´ees. Si la nouvelle correspondance a un meilleur score, elle est conserv´ee. Sinon, elle est conserv´ee ou non avec une probabilit´e qui d´ecroit exponentiellement avec le nombre d’it´erations. Apr`es un nombre d’it´erations fix´e, l’algorithme s’arrˆete. Cette m´ethode peut s’appliquer `a n’importe quelle forme de score et notamment `a la formule du score 3.16. d) Illustration de la m´ethode de matching La figure 3.21 pr´esente un exemple de repartitionnement bas´e sur le matching. Dans un premier temps, une matrice de migration optimale est choisie. Ici, on choisit une matrice combinant une sous-matrice diagonale avec une sous-matrice en escalier dont l’hypergraphe de repartitionnement associ´e est repr´esent´e dans la figure 3.21a. Cette classe de matrice a l’avantage de fournir un nombre de messages par partie souvent plus faible que les matrices construites r´ecursivement (cf. section 3.2). Ensuite, cet hypergraphe de repartitionnement est mis en correspondance avec le graphe quotient `a l’aide de l’heuristique de recuit simul´e optimisant la fonction ScoreR (´equation 3.16). Le r´esultat est visible sur la figure 3.21b. Cette appariement correspond `a une permutation des lignes de la matrice mais aussi des 5 premi`eres colonnes pour garder une diagonale optimisant le volume de migration. La figure 3.22 pr´esente des r´esultats d’application de la m´ethode d’appariement dans diff´erents cas. On remarque que dans le cas 8×12 (figure 3.22a), le r´esultat est le mˆeme qu’avec la m´ethode de la chaˆıne. En effet, les matrices 8×12 choisies dans les deux m´ethodes sont ´equivalentes `a une permutation pr`es dans ce cas pr´ecis. Dans le cas 12×14 (figure 3.22b), il y a de tr`es grandes hyperarˆetes. Cela risque de poser probl`eme pour la construction des parties associ´ees `a ces grandes hyper-arˆetes. Ce probl`eme vient du choix de la matrice optimale qui concentre les non-z´eros dans les derni`eres colonnes de la matrice. Cela aurait pu ˆetre ´evit´e en choisissant un autre type de matrice, mais le volume total de migration n’aurait pas ´et´e optimal. Le recuit simul´e ne trouve pas toujours de bonne solution : sur la figure 3.22c, l’hyper-arˆete contenant les sommets 0, 4, 7 et 15 ne contient que deux arˆetes (4–7 de poids 25 et 0–15 de poids 4), mais les autres hyper-arˆetes sont assez bien plac´ees. Notons que cette m´ethode de repartitionnement ne peut pas ˆetre appliqu´ee dans le cas o`u les parties sont initialement d´es´equilibr´ees. La mise en correspondance de l’hypergraphe de repartitionnement et du graphe quotient n´ecessite que les parties initiales soient interchangeables, ce qui n’est le cas que quand les parties initiales ont toutes le mˆeme poids. 3.3.3 M´ethode gloutonne (Greedy) Dans le cas g´en´eral, il n’est pas possible de choisir une matrice avant de l’apparier au graphe quotient : les anciennes parties ont chacune un poids diff´erent et elles ne sont plus interchangeables. Il faut construire la matrice de migration directement en tenant compte de la connectivit´e entre les parties et de leurs diff´erents poids.48 CHAPITRE 3. MODELE DE MIGRATION `   1000 0 0 0 0 400 0 0 1000 0 0 0 400 0 0 0 1000 0 0 200 200 0 0 0 1000 0 0 400 0 0 0 0 1000 0 400   (a) Matrice de migration optimale et hypergraphe de repartitionnement associ´e pour le cas 5 × 7. 39 39 14 34 17 62 65   1000 0 0 0 0 0 400 0 1000 0 0 0 400 0 0 0 1000 0 0 400 0 0 0 0 1000 0 0 400 0 0 0 0 1000 200 200   TotalV = 2000 MaxV = 1000 TotalZ = 6 MaxZ = 3 (b) Hypergraphe appari´e au graphe quotient et matrice de migration finale. Figure 3.21 – Exemple de repartitionnement bas´e sur le matching dans le cas 5 × 7.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 49 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21. Figure 3.22 – Application du repartitionnement bas´e sur le matching. a) Construction de la matrice de migration par une m´ethode gloutonne La matrice de migration C est construite par l’algorithme 2 selon une m´ethode gloutonne en prenant en entr´ee le graphe quotient Q = (V, E) et le nouveau nombre de parties N. On note (Pi)i∈J0,M−1K les anciennes parties et (P ′ j )j∈J0,N−1K les nouvelles parties. L’algorithme commence avec une matrice vide, puis les colonnes de la matrice (correspondant aux hyper-arˆetes de l’hypergraphe de repartitionnement) sont remplies une par une. Ce remplissage s’effectue de fa¸con `a respecter les contraintes sur les sommes des lignes et des colonnes qui correspondent respectivement aux poids des anciennes parties (w(Pi)) et des nouvelles parties (w(P ′ j )). La migration peut ˆetre minimis´ee (optdiag = vrai en entr´ee de l’algorithme) en construisant une hyper-arˆete de taille 1 pour chaque sommet du graphe quotient quand cela est possible, c’est-`a-dire quand l’ancienne partie est plus grosse que la nouvelle (w(Pi) > w(P ′ j )). Les hyper-arˆetes suivantes sont construites de fa¸con gloutonne en commen¸cant par une sommet pseudo-p´eriph´erique (voir d´efinition 12) de faible degr´e, puis en ajoutant des sommets v un `a un dans l’hyper-arˆete h en cherchant `a maximiser un score inspir´e de celui pr´esent´e dans la section 3.3.2 : score (v, h) =|ES(h) ∩ EV (v)| |EV (v)| × |ES(h)| × P e∈ES (h)∩EV (v) we P e∈EV (v) we × X e∈ES (h) we avec  ES(h) = {(u, v) ∈ E : u ∈ h ∧ v ∈ h} EV (v) = {e ∈ E : v ∈ e} . (3.17) ES(h) est l’ensemble des arˆetes du sous-graphe d´efini par l’hyper-arˆete h. EV (v) est l’ensemble des arˆetes dont une extr´emit´e est v (son voisinage). Le score de l’´equation 3.17 reprend du score 3.16 le produit du nombre d’arˆetes et de leur poids permettant d’obtenir des groupes d’anciennes parties bien connect´ees et le multiplie par la proportion des arˆetes autour du nouveau sommet v qui sont dans l’hyper-arˆete h, en nombre et en poids. Cette modification du score permet de mieux guider l’algorithme glouton qui pr´ef´erera alors choisir des sommets sur le bord ou encercl´es par l’hyper-arˆete, laissant de meilleurs choix pour la construction des hyper-arˆetes suivantes. Pour chaque sommet ajout´e dans l’hyper-arˆete, on remplit le coefficient correspondant dans la matrice avec la valeur maximale permettant de respecter les contraintes de poids sur les lignes et colonnes. Comme les coefficients de la matrice doivent ˆetre positifs, la somme des valeurs sur la ligne (et respectivement la colonne) ne doit pas d´epasser la taille d’une partie initiale (et respectivement finale). A une it´eration de notre algorithme, la valeur choisie pour l’´el´eme ` nt Ci,j50 CHAPITRE 3. MODELE DE MIGRATION ` est donc min(w(Pi) − P k Ci,k, w(P ′ j ) − P k Ck,j ). Comme on veut obtenir une partition finale ´equilibr´ee, on pose ∀j, w(P ′ j ) = wf inal = W N . Le volume total de migration peut ˆetre minimis´e en commen¸cant par remplir la diagonale de la matrice de migration avec les plus grandes valeurs possibles. Le reste de la matrice est alors rempli normalement selon l’heuristique gloutonne. Algorithme 2 Construction de la matrice de migration C (Greedy1) Entr´ee : Nombre d’anciennes parties M Entr´ee : Nombre de nouvelles parties N Entr´ee : Graphe quotient de l’ancienne partition Q = (V, E) Entr´ee : Bool´een optdiag indiquant l’optimisation de la diagonale C ← matrice nulle de dimension M × N j ← 0 /* Indice de l’hyper-arˆete en cours de construction. */ /* Construction d’hyper-arˆetes de taille 1. */ si optdiag alors pour tout v ∈ V correspondant `a l’ancienne partie Pi faire si wv ≥ wf inal et j < N alors Ci,j ← wf inal wv ← wv − wf inal j ← j + 1 fin si fin pour fin si /* Construction gloutonne des hyper-arˆetes */ tant que j < N faire v ← sommet pseudo-p´eriph´erique de Q d’indice i et de poids wi non nul h ← {v} /* Hyper-arˆete d’indice j en cours de construction. */ Ci,j ← min(wi , wf inal) wi ← wi − Ci,j tant que P k Ck,j < wf inal faire v ← sommet de V d’indice i, de poids wi non nul tel que score(v, h ∪ {v}) soit maximal h ← h ∪ {v} Ci,j ← min(wi , wf inal − P k Ck,j ) wi ← wi − Ci,j fin tant que j ← j + 1 fin tant que retourner C Notre algorithme se base sur la notion de sommet pseudo-p´eriph´erique pour trouver un sommet sur le « bord » du graphe. Rechercher un sommet p´eriph´erique 4 est plus complexe et n’est pas n´ecessaire pour l’application de notre heuristique. D´efinition 11 (Excentricit´e). L’excentricit´e d’un sommet v dans un graphe, not´ee ǫ(v), est la plus grande distance entre v et n’importe quel autre sommet du graphe. 4. Un sommet p´eriph´erique est un sommet d’excentricit´e maximale.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 51 D´efinition 12 (Sommet pseudo-p´eriph´erique). Un sommet v est un sommet pseudo-p´eriph´erique si pour tous les sommets u les plus ´eloign´es de v, on a ǫ(v) = ǫ(u) = d(u, v). Plus formellement v est pseudo-p´eriph´erique si ∀u ∈ V, d(u, v) = ǫ(v) =⇒ d(u, v) = ǫ(u). Un sommet pseudo-p´eriph´erique peut ˆetre facilement trouv´e comme le montre l’algorithme 3. En partant d’un sommet quelconque, on cherche, `a l’aide d’un parcours en largeur, un sommet le plus loin possible (calculant ainsi l’excentricit´e du sommet de d´epart) et de faible degr´e. Cette recherche est r´ep´et´ee `a partir du nouveau sommet jusqu’`a trouver un sommet dont l’excentricit´e est ´egale `a celle du sommet pr´ec´edent. En pratique cet algorithme termine en tr`es peu d’it´erations [21] (2 ou 3 it´erations lors de nos tests). Algorithme 3 Recherche d’un sommet pseudo-p´eriph´erique de degr´e faible Entr´ee : Graphe G u ← sommet quelconque de G ǫnouveau ← 0 r´ep´eter Effectuer un parcours en largeur du graphe G en partant de u v ← sommet avec une distance maximale et un degr´e minimal ǫcourant ← ǫnouveau ǫnouveau ← d(u, v) /* correspond `a l’excentricit´e de u */ u ← v jusqu’`a ǫnouveau = ǫcourant retourner u b) Optimisation du nombre de messages par une recherche de sous-ensembles L’algorithme 2 construit une matrice de migration avec M + N − 1 messages. A chaque ` it´eration, la valeur de l’´el´ement est choisie pour satisfaire la contrainte de poids sur la ligne ou la colonne, sauf `a la derni`ere it´eration o`u les contraintes sur la ligne et la colonne de l’´el´ement sont satisfaites. Comme il y a M lignes et N colonnes, il y a au plus M + N − 1 it´erations et ´el´ements non nuls. Il est possible de diminuer ce nombre de messages en d´ecomposant le probl`eme de construction de la matrice de migration en plusieurs sous-probl`emes de repartitionnement sur des sousensembles disjoints de parties, comme le montre la d´emonstration du lemme 2. Pour d´ecomposer le probl`eme en K sous-probl`emes, l’ensemble des parties (Pi)i∈J1,MK est partitionn´e en K sous-ensembles (Sj )j∈J1,KK . Pour chaque sous ensemble Sj , la somme des poids des parties qu’il contient est `a peu pr`es un multiple de la taille id´eale d’une partie finale. Plus formellement, avec un facteur de d´es´equilibre ǫ, un sous-ensemble Sj est de « bonne taille » si il existe un entier Nj tel que P j Nj = N et (1 − ǫ) × Nj W N < X Pi∈Sj w(Pi) < (1 + ǫ) × Nj W N . On note Mj = |Sj | la taille de chaque sous-ensemble. Comme les sous-ensembles sont une partition de l’ensemble des parties, on a P j Mj = M. Chaque sous probl`eme est donc de taille Mj × Nj et construit une sous-matrice de migration avec Mj + Nj − 1 messages. Le nombre de messages total est donc M + N − K. Pour minimiser le nombre de messages, il faut donc trouver le plus possible de sous-ensembles. Dans le cas ´equilibr´e, on trouvait pgcd(M, N) tels sous-ensembles de chacun M/pgcd(M, N) parties.52 CHAPITRE 3. MODELE DE MIGRATION ` La recherche de tels sous-ensembles est une version plus g´en´erale du probl`eme de la somme d’un sous-ensemble 5 qui est NP-complet [20, SUBSET SUM]. Ces sous-ensembles peuvent ˆetre construits avec un algorithme glouton similaire `a celui de construction de la matrice de migration. Dans l’algorithme 4, on commence par trouver un sommet pseudo-p´eriph´erique dans le graphe quotient, puis on cherche parmi ses voisins si il existe un sommet permettant de cr´eer un sousensemble de la bonne taille, sinon on en choisit un qui maximise le score du sous-ensemble comme dans l’algorithme 2. Puis on recommence `a chercher parmi les voisins du sous-ensemble jusqu’`a construire un sous-ensemble de bonne taille. Au pire, l’algorithme termine en s´electionnant tous les sommets du graphe quotient dans un seul sous-ensemble, puisque par d´efinition de la taille id´eale, le poids total du graphe vaut N fois celle-ci. Algorithme 4 Construction de la matrice de migration avec une recherche de sous-ensembles (Greedy2) Entr´ee : Nombre d’anciennes parties M Entr´ee : Nombre de nouvelles parties N Entr´ee : Graphe quotient Q = (V, E) R ← V /* Ensemble des sommets restants */ tant que R 6= ∅ faire u ← un sommet pseudo-p´eriph´erique du sous-graphe de Q restreint `a R S ← {u} R ← R \ {u} tant que S n’est pas un sous-ensemble de bonne taille pour N′ nouvelles parties faire si il existe v ∈ R tel que v est connect´e `a S et S ∪ {v} est de bonne taille alors S ← S ∪ {v} /* S´electionner v */ R ← R \ {v} sinon u ← sommet maximisant le score du sous-ensemble S ∪ {u} S ← S ∪ {u} /* S´electionner u */ R ← R \ {u} fin si fin tant que Construire la sous-matrice |S| × N′ associ´ee au sous-ensemble S (appel de l’algorithme 2 (Greedy1) sur le sous-graphe de Q restreint `a S) fin tant que Un exemple d’application de ces algorithmes est pr´esent´e sur les figures 3.23 `a 3.25 avec le cas 5 × 7 d´es´equilibr´e. La figure 3.23 pr´esente la recherche des sous-ensembles, alors que les figures 3.24 et 3.25 pr´esentent respectivement les constructions des sous-matrices pour chacun des sous-ensembles. Les poids des parties initiales sont dans l’ordre 500, 900, 2400, 1500 et 1700. Les parties finales devront ˆetre de poids 1000. Les valeurs indiqu´ees `a cot´e des sommets correspondent aux donn´ees des anciennes parties qui n’ont pas encore ´et´e affect´ees dans une nouvelle. Les ´el´ements de la matrice ne faisant pas partie de la sous-matrice concern´ee sont gris´es. L’algorithme commence par chercher un sous-ensemble en partant d’un sommet pseudop´eriph´erique (figure 3.23a). Parmi les voisins, la partie 3 permet d’avoir un sous-ensemble adapt´e 5. Etant donn´e un ensemble d’entiers, existe-t-il un sous-en ´ semble non vide dont la somme vaut une valeur donn´ee ?3.3. CONSTRUCTION DES MATRICES DE MIGRATION 53 39 39 14 34 17 62 65 500 1 900 2 2400 3 1500 4 1700 (a) Premi`ere ´etape de la construction des sousensembles. 39 39 14 34 17 62 65 500 1 900 2 2400 4 1700 (b) Seconde ´etape de la construction des sousensembles : le premier sous-ensemble est termin´e. 39 39 14 34 17 62 65 500 900 (c) Cinqui`eme et derni`ere ´etape de la construction des sousensembles. Figure 3.23 – Construction des sous-ensembles. au repartitionnement en 2 parties (500+1500 = 2×1000) (figure 3.23b). L’algorithme de construction de la matrice de migration est alors appliqu´e sur le sous-ensemble {0, 3}. La partie 0 est trop petite pour cr´eer une hyper-arˆete de taille 1 (figure 3.24a). La partie 3 a un poids suffisant donc 1000 est ajout´e sur la diagonale (figure 3.24b). Il reste alors une hyper-arˆete `a construire : elle part du sommet 0 (figure 3.24c) et s’´etend sur le seul sommet voisin 3 (figure 3.24d). Les deux hyper-arˆetes n´ecessaires sont donc construites et toutes les donn´ees de 0 et 3 ont ´et´e redistribu´ees. Le second sous-ensemble est construit avec le reste du graphe quotient (figure 3.23c). Les parties 1, 2 et 4 seront repartitionn´ees vers 5 parties (900 + 2400 + 1700 = 5 × 1000). On commence par construire les hyper-arˆetes de taille 1 (figure 3.25a) pour optimiser la diagonale de la matrice, ici 2 et 4 sont de poids suffisants. L’hyper-arˆete suivante est construite `a partir de 1 (figure 3.25b) et s’´etend sur le voisin « libre » le plus connect´e `a 1 : 2 (figure 3.25c). La suivante est construite `a partir de 2 qui a encore assez de donn´ees (1300) pour construire une hyper-arˆete de taille 1 (figure 3.25d). La derni`ere hyper-arˆete part de 2 (figure 3.25e) et s’´etend sur le seul sommet restant, la partie 4 (figure 3.25f). Par la suite, nous utiliserons syst´ematiquement la recherche des sous-ensembles (Greedy2) pour notre algorithme glouton (Greedy). c) Illustration de la m´ethode gloutonne Les figures 3.26 et 3.27 pr´esentent des r´esultats de la m´ethode gloutonne avec optimisation de la diagonale dans les cas ´equilibr´es et d´es´equilibr´es. Comme avec la m´ethode d’appariement, de grandes hyper-arˆetes sont cr´e´ees. Cela est dˆu au remplissage de la diagonale qui laisse de petits restes pour cr´eer les parties suppl´ementaires. Dans le cas d´es´equilibr´e, cet effet est att´enu´e : la diagonale ne peut pas toujours ˆetre remplie et les restes peuvent ˆetre plus importants. Les figures 3.28 et 3.29 montrent les r´esultats dans les mˆemes cas, mais sans l’optimisation de la diagonale. Les tailles des hyper-arˆetes sont bien plus raisonnables. Comme avec la m´ethode de la chaˆıne, les nouvelles parties sont souvent plac´ees entre deux anciennes parties voisines.54 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65 0 500 1 0 2 0 3 1500 4 0   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   (a) Premi`ere ´etape du remplissage de la diagonale. 39 39 14 34 17 62 65 0 500 1 0 2 0 500 4 0   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 0 0 0 0 0 0 0 0 0 0   (b) Seconde ´etape du remplissage de la diagonale. 39 39 14 34 17 62 65 0 1 0 2 0 500 4 0   500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 0 0 0 0 0 0 0 0 0 0   (c) Premi`ere ´etape de la construction de la seconde hyper-arˆete. 39 39 14 34 17 62 65 0 1 0 2 0 4 0   500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 0 0 0   (d) L’hyper-arˆete est construite. Figure 3.24 – Construction des sous-ensembles et de la sous-matrice correspondant au premier sous-ensemble {0, 3}.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 55 39 39 14 34 17 62 65 1 900 1400 700   500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (a) Remplissage de la diagonale. 39 39 14 34 17 62 65 1400 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 0 1000 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (b) Premi`ere ´etape de la construction de la troisi`eme hyper-arˆete. 39 39 14 34 17 62 65 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (c) Seconde ´etape de la construction de la troisi`eme hyper-arˆete. 39 39 14 34 17 62 65 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 1000 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (d) Construction de la quatri`eme hyper-arˆete. 39 39 14 34 17 62 65 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 1000 300 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (e) Premi`ere ´etape de la construction de la cinqui`eme hyper-arˆete. 39 39 14 34 17 62 65   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 1000 300 500 0 0 1000 0 0 0 0 0 0 0 1000 0 700   (f) Seconde ´etape de la construction de la cinqui`eme hyper-arˆete et fin de l’algorithme. Figure 3.25 – Construction de la sous-matrice correspondant au second sous-ensemble {1, 2, 4}.56 CHAPITRE 3. MODELE DE MIGRATION ` 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 ´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 ´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16×21 ´equilibr´e. Figure 3.26 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton avec op ´ timisation de la diagonale dans des cas ´equilibr´es. 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 d´es´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 d´es´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21 d´es- ´equilibr´e. Figure 3.27 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton avec op ´ timisation de la diagonale dans des cas d´es´equilibr´es.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 57 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 ´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 ´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16×21 ´equilibr´e. Figure 3.28 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton sans opt ´ imisation de la diagonale dans des cas ´equilibr´es. 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 d´es´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 d´es´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21 d´es- ´equilibr´e. Figure 3.29 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton sans opt ´ imisation de la diagonale dans des cas d´es´equilibr´es.58 CHAPITRE 3. MODELE DE MIGRATION ` 3.3.4 Programme lin´eaire (LP) Les m´ethodes de repartitionnement diffusives [26,46] optimisent le volume de migration en effectuant des communications entre les parties voisines sur le graphe quotient (cf. section 2.3.2 b)). Nous proposons d’´etendre la m´ethode en utilisant un programme lin´eaire dans le cas du repartitionnement avec changement dynamique du nombre de processeurs et pour optimiser les diff´erentes m´etriques TotalV, MaxV, TotalZ et MaxZ. Le principal probl`eme de cette adaptation est que le graphe quotient ne prend en compte que les anciennes parties et non les nouvelles. Il faut donc adapter celui-ci pour prendre en compte ce changement de nombre de parties. Pour un repartitionnement de M vers N parties, on utilise un graphe d´ecrivant les messages possibles entre max(M, N) parties. Le poids de certaines parties peut ˆetre initialement nul, si elles n’existaient pas dans l’ancienne partition (cas o`u M < N) ; on peut aussi vouloir un poids final nul pour les parties qui n’existent pas dans la nouvelle partition (cas o`u M > N). Dans le cas o`u le nombre de parties augmente (M < N), il faut ajouter des nouveaux sommets dans le graphe quotient et, pour que la migration soit possible, connecter ces nouveaux sommets avec le reste du graphe. En effet, Hu et al. [26] montrent que pour qu’une solution soit possible, le graphe doit ˆetre connexe. On veut donc construire `a partir du graphe quotient Q, un nouveau graphe quotient enrichi Q˜. La fa¸con dont sont connect´es ces nouveaux sommets influence grandement la migration optimale possible, mais aussi la coupe de la partition finale. Pour obtenir une bonne migration, il faut placer les nouvelles parties proches des anciennes parties capables de fournir les sommets n´ecessaires. Pour obtenir une bonne coupe, il faut connecter les nouvelles parties avec des anciennes proches entre elles. Une m´ethode na¨ıve pour trouver de tels placements est de rechercher dans le graphe quotient de petites cliques de parties bien connect´ees entre elles et poss´edant un poids ´elev´e. Dans le cas o`u le nombre de parties diminue, le graphe quotient n’a pas besoin d’ˆetre modifi´e mais il faut choisir les parties qui seront supprim´ees, c’est-`a-dire dont le poids final vis´e est nul. a) Optimisation du volume total de migration TotalV Une fois le graphe Q˜ des messages autoris´es construit, il faut d´ecider du volume de donn´ees `a communiquer sur chaque arˆete. Pour minimiser le volume total de migration, il est possible d’utiliser le programme lin´eaire suivant : minimiser X i,j eij . Contraintes lin´eaires : ∀i ∈ V, vi = X j (eji − eij ). (3.18) Bornes : ∀i ∈ V, vi ≤ di + ub. (3.19) ∀(i, j) ∈ E, 0 ≤ eij . (3.20) On note eij la quantit´e de donn´ees envoy´ees par la partie i vers la partie j. Cette variable est toujours positive ou nulle (´equation 3.20) ; si le message se passe dans l’autre sens, eij est nul et eji contient le volume de donn´ees ´echang´ees. vi est la variation de la quantit´e de donn´ees de la partie i et est ´egale `a la diff´erence des donn´ees re¸cues et envoy´ees (´equation 3.18). di est3.3. CONSTRUCTION DES MATRICES DE MIGRATION 59 1 2 3 1 3 2 4 4 3 5 2 3 3 0 Figure 3.30 – Exemple de partition initiale et de son graphe quotient enrichi. la variation souhait´ee de la quantit´e de donn´ees de la partie i, c’est-`a-dire la diff´erence entre le poids initial et le poids souhait´e. vi doit ˆetre `a peu pr`es ´egal `a di `a une tol´erance de d´es´equilibre ub pr`es (´equation 3.19). Par exemple, en prenant la partition en trois parties de la figure 3.30, on construit un graphe quotient de trois sommets auquel on ajoute un quatri`eme pour repartitionner en 4 parties. Ici, le nouveau sommet est connect´e aux trois autres. L’application des contraintes 3.18 donne : v1 = e21 − e12 + e31 − e13 + e41 − e14 v2 = e12 − e21 + e21 − e23 + e42 − e24 v3 = e13 − e31 + e23 − e32 + e43 − e34 v4 = e14 − e41 + e24 − e42 + e34 − e43 et les bornes 3.19 : v1 ≤ −1 v2 ≤ 0 v3 ≤ −2 v4 ≤ 3. De plus tous les eij sont positifs ou nuls. La solution de ce probl`eme est : e41 = 1 e43 = 2 et tous les autres eij sont nuls. Ce qui veut dire que la partie 1 devra envoyer un sommet `a la partie 4 et la partie 3 devra en envoyer deux. Il n’y a pas d’autre communication. b) Extension `a d’autres m´etriques Il est possible d’´etendre le programme lin´eaire pour d’autres objectifs, tels que : MaxV, TotalZ, MaxZ ou n’importe quelle combinaison lin´eaire de ceux-ci. Pour optimiser MaxV, il suffit d’ajouter une variable v repr´esentant le volume maximal de migration par partie. On cherche donc `a minimiser v = maxi∈V P j (eij + eji)  . Cela se traduit par les contraintes suppl´ementaires :60 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65 0 2020 1 1984 2 1986 3 2014 4 1996 (a) Graphe quotient. 39 39 14 34 17 62 65 (b) Groupes de sommets retenus pour les nouvelles parties ajout´ees. 0 1 2 3 4 5 6 (c) Graphe quotient enrichi avec les nouveaux sommets.   1500 0 0 0 0 520 0 0 1184 0 0 0 0 800 0 0 1428 0 0 0 558 0 0 0 1500 0 514 0 0 172 0 0 1500 324 0   (d) Matrice de migration obtenue pour l’optimisation de TotalV. Figure 3.31 – Enrichissement du graphe quotient puis construction de la matrice de migration pour le cas 5 × 7. ∀i ∈ V,X j (eij + eji) ≤ v. (3.21) v ´etant minimis´e, il vaut bien la plus grande des valeurs P j (eij + eji). Lorsque les valeurs eij sont enti`eres, on peut ajouter des variables binaires xij pour chaque arˆete donnant l’existence ou non d’un message sur cette arˆete grˆace aux contraintes : xij ≤ eij ≤ W xij . (3.22) W est le poids total du graphe, aucun message ne peut d´epasser cette taille. En ´etudiant les deux cas possibles suivant la valeur de xij , on obtient : eij = 0 si xij = 0 1 ≤ eij ≤ W si xij = 1. (3.23) xij correspond donc bien `a l’existence d’un message de la partie i vers la partie j. Il est alors possible de minimiser TotalZ en minimisant la somme des xij et MaxZ en utilisant une m´ethode similaire `a celle pour MaxV. Les programmes lin´eaires complets pour les diff´erentes m´etriques sont d´ecrits dans l’annexe A. c) Application du programme lin´eaire Pour enrichir le graphe quotient, un algorithme recherche, pour chaque nouvelle partie suppl´ementaire, de petits groupes de sommets (de taille 1, 2 ou 3) bien connect´es et de poids importants.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 61 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 ´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 ´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16×21 ´equilibr´e. Figure 3.32 – Application de la construction de la matrice de migration `a l’aide du programme lin´eaire dans des cas ´equilibr´es. Nous ne d´etaillerons pas ici cet algorithme qui utilise une approche gloutonne selon un crit`ere comparable `a celui de la m´ethode Greedy, mais en bornant la taille des hyper-arˆetes (entre 1 et 3). Sur l’exemple de la figure 3.31, pour passer de 5 `a 7 parties, il faut ajouter deux nouvelles parties : un groupe de trois sommets et un groupe de deux sont choisis (fig. 3.31b). Les deux nouveaux sommets sont connect´es aux anciens sommets d’apr`es ces ensembles (fig. 3.31c). En appliquant le programme lin´eaire pour l’optimisation de TotalV sur ce graphe quotient enrichi, on obtient 6 messages : 5 messages correspondant aux arˆetes ajout´ees pour cr´eer les nouvelles parties suppl´ementaires et un message entre les parties 4 et 1. Pr´esent´es sous forme de matrice de migration, ces r´esultats donnent la matrice sur la figure 3.31d. Les valeurs sur la diagonale (en gris) ne sont pas obtenues directement par le programme lin´eaire mais calcul´ees indirectement d’apr`es les tailles des messages et les tailles des anciennes parties. 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 d´es´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 d´es´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21 d´es- ´equilibr´e. Figure 3.33 – Application de la construction de la matrice de migration `a l’aide du programme lin´eaire dans des cas d´es´equilibr´es. Les r´esultats obtenus pour diff´erents cas avec l’optimisation de TotalV sont pr´esent´es sur62 CHAPITRE 3. MODELE DE MIGRATION ` les figures 3.32 et 3.33. Les tailles des hyper-arˆetes finales correspondant aux nouvelles parties sont effectivement limit´ees `a un maximum de 3 et les autres communications se font uniquement le long des arˆetes du graphe quotient. Cet algorithme optimise la m´etrique souhait´ee, mais relativement `a un graphe quotient enrichi donn´e dont la construction ne permet pas toujours une migration optimale. 3.4 Evaluation des m´ethodes et conclusion ´ Nous comparons les m´ethodes de construction de matrice de migration pr´esent´ees dans ce chapitre : la m´ethode bas´ee sur la chaˆıne (1D), la m´ethode d’appariement (Matching, seulement dans le cas ´equilibr´e), les deux variantes de l’algorithme glouton avec optimisation de la diagonale (GreedyD) et sans (Greedy) et le programme lin´eaire optimisant TotalV (LP). Les m´ethodes pr´esent´ees sont ´evalu´ees sur six cas ´equilibr´es et d´es´equilibr´es. Les trois cas ´equilibr´es sont : — 8×12 avec des anciennes parties de taille 1500 et donc des nouvelles parties de taille 1000 ; — 12 × 14 avec des anciennes parties de taille 1000 et donc des nouvelles parties de taille 857 ; — 16 × 21 avec des anciennes parties de taille 1000 et donc des nouvelles parties de taille 761. Les trois cas d´es´equilibr´es utilisent les mˆemes nombres de parties : — 8 × 12 avec un d´es´equilibre de 49 % et des nouvelles parties de taille 1509 ; — 12 × 14 avec un d´es´equilibre de 58 % et des nouvelles parties de taille 1311 ; — 16 × 21 avec un d´es´equilibre de 50 % et des nouvelles parties de taille 922. Ces d´es´equilibres ont ´et´e r´ealis´es avec la m´ethode utilis´ee par l’article [56] : pour chaque partie, un nombre al´eatoire de sommets sont s´electionn´es pour avoir leur poids tripl´es, conduisant `a un d´es´equilibre d’environ 50 %. Les tableaux 3.1 et 3.2 pr´esentent les m´etriques associ´ees aux applications pr´esent´ees dans les sections pr´ec´edentes. Les quatre m´etriques pr´esent´ees ne permettent pas d’´evaluer la qualit´e de la coupe finale mais seulement la qualit´e de la migration. La coupe ne pourra ˆetre ´evalu´ee qu’apr`es le repartitionnement dans le chapitre 5. En dehors du repartitionnement 8×12 dans le cas ´equilibr´e, on remarque que les optimisations de TotalV et MaxZ sont contradictoires. En effet, comme expliqu´e avec la m´ethode d’appariement, l’optimisation de la diagonale oblige les nouvelles parties suppl´ementaires `a prendre les donn´ees depuis de nombreuses anciennes parties, ce qui favorise des hyper-arˆetes de grandes tailles et donc l’augmentation de MaxZ. Les m´ethodes 1D et Greedy donnent un MaxZ bas mais un TotalV plus ´elev´e, contrairement aux m´ethodes Matching (avec choix d’une matrice diagonale) et GreedyD qui optimisent en priorit´e TotalV. Le cas du programme lin´eaire est particulier : bien que le programme lin´eaire minimise TotalV, la construction du graphe quotient enrichi impose un degr´e faible. Malgr´e cette minimisation, TotalV peut ˆetre plus ´elev´e qu’avec d’autres m´ethodes mais MaxZ est maintenu bas. TotalV aurait pu ˆetre plus bas avec un choix de graphe quotient enrichi diff´erent. Il est ´egalement possible d’utiliser le programme lin´eaire pour optimiser d’autres crit`eres. Dans le cas 8 × 12 ´equilibr´e, il existe une solution donnant `a la fois un TotalV bas et un MaxZ bas que toutes les m´ethodes trouvent. Le programme lin´eaire est capable de donner un TotalV plus bas que l’optimal (4000) en profitant de la tol´erance au d´es´equilibre. Le MaxV varie peu d’une m´ethode `a l’autre et il est g´en´eralement proche de la taille d’une nouvelle partie. Une nouvelle partie devant recevoir l’int´egralit´e de ses donn´ees, il n’est pas3.4. EVALUATION DES M ´ ETHODES ET CONCLUSION ´ 63 possible d’avoir un MaxV inf´erieur `a la taille id´eale d’une nouvelle partie. Dans le cas ´equilibr´e, le TotalZ optimal est bien atteint pour toutes les m´ethodes sauf le programme lin´eaire qui n’optimise pas ce crit`ere. Dans le cas d´es´equilibr´e, l’optimal n’est pas connu. La m´ethode de la chaˆıne atteint max(M, N) − 1 messages et les algorithmes gloutons donne un nombre de messages inf´erieur grˆace `a la recherche des sous-ensembles. Bien que le programme lin´eaire n’optimise pas le nombre de messages, celui-ci reste tr`es bas. C’est un effet de bord de la minimisation de TotalV. Dans la suite de cette th`ese, nous retiendrons les m´ethodes utilisant l’algorithme glouton (Greedy et GreedyD) et le programme lin´eaire (LP). L’algorithme glouton permet de minimiser TotalZ et offre deux variantes permettant au choix de minimiser fortement TotalV ou de garder MaxZ bas. La m´ethode d’appariement (Matching) n’est pas utilisable dans le cas g´en´eral et la m´ethode 1D donne des r´esultats comparables `a la m´ethode Greedy (MaxZ faible mais TotalV plus ´elev´e) mais avec de moins bons r´esultats. La construction de matrices de migration `a partir du graphe quotient est la premi`ere ´etape de notre m´ethode de repartitionnement dont la d´emarche globale est rappel´ee en figure 3.34. Les matrices de migration ainsi construites vont ˆetre utilis´ees par les algorithmes de repartitionnement de graphe pr´esent´es dans le chapitre suivant.64 CHAPITRE 3. MOD `ELE DE MIGRATION 1D (fig. 3.14) Matching (fig. 3.22) GreedyD (fig. 3.26) Greedy (fig. 3.28) LP (fig. 3.32) Cas 8 × 12 TotalV 4000 4000 4000 4000 3960 MaxV 1000 1000 1000 1000 900 TotalZ 8 8 8 8 8 MaxZ 2 2 2 2 2 Cas 12 × 14 TotalV 3427 1714 1714 3426 2900 MaxV 857 857 857 857 939 TotalZ 12 12 12 12 13 MaxZ 2 6 6 2 3 Cas 16 × 21 TotalV 5239 3808 3808 5335 5606 MaxV 762 762 762 762 1150 TotalZ 20 20 20 20 20 MaxZ 2 4 4 3 3 Table 3.1 – R´esultats des diff´erentes m´ethodes dans le cas ´equilibr´e.3.4. EVALUATION DES M ´ ETHODES ET CONCLUSION ´ 65 1D (fig. 3.16) GreedyD (fig. 3.27) Greedy (fig. 3.29) LP (fig. 3.33) Cas 8 × 12 TotalV 7453 6266 7127 6299 MaxV 1871 1869 1869 1862 TotalZ 11 10 10 10 MaxZ 2 4 3 2 Cas 12 × 14 TotalV 5064 5960 5769 5261 MaxV 1311 1372 1372 2013 TotalZ 13 12 12 13 MaxZ 2 3 3 4 Cas 16 × 21 TotalV 6200 5504 6138 5858 MaxV 922 922 923 1103 TotalZ 20 18 18 19 MaxZ 2 5 3 4 Table 3.2 – R´esultats des diff´erentes m´ethodes dans le cas d´es´equilibr´e.66 CHAPITRE 3. MOD `ELE DE MIGRATION Méthode d'appariement (Matching) Méthode de la chaîne (1D) Méthode gloutonne (Greedy) Méthode de partitionnement biaisé (Biased) Méthode diffusive (Diff) Hyper-arêtes de repartitionnement Matrice de migration Graphe quotient Nouvelle partition en N Graphe partitionné en M Construction de la matrice de migration M×N Repartitionnement M×N Programme linéaire (LP) Figure 3.34 – Vue d’ensemble.Chapitre 4 Repartitionnement M × N Sommaire 4.1 Repartitionnement M×N bas´e sur le partitionnement biais´e (BIASED) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.1.1 M´ethodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1.2 Limitations des partitionneurs . . . . . . . . . . . . . . . . . . . . . . 71 4.2 Partitionnement k-aire direct (KGGGP) . . . . . . . . . . . . . . . 73 4.2.1 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . 73 4.2.2 Crit`eres de s´election . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.3 Complexit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.4 Am´eliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 ´ 4.3 Repartitionnement M × N bas´e sur la diffusion (DIFF) . . . . . . . 85 4.4 Partitionnement biais´e `a l’aide d’hyper-arˆetes de repartitionnement 89 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Dans ce chapitre, nous pr´esentons nos algorithmes de repartitionnement M × N, r´esum´es en figure 4.1. Nos m´ethodes de repartitionnement biais´e (BIASED) et diffusive (DIFF) s’inspirent des m´ethodes de repartitionnement classiques du mˆemes noms mais sont ´etendues dans le cas du repartitionnement avec un nombre de processeurs variable. Ces deux m´ethodes se basent sur une matrice de migration obtenue `a l’aide d’un des algorithmes pr´esent´es dans le chapitre pr´ec´edent. De plus, dans le cadre de notre partitionnement biais´e, nous mettons en ´evidence des limitations de la m´ethode des bissections r´ecursives largement utilis´ee par les diff´erents outils de partitionnement actuels, et nous proposons une m´ethode de partitionnement k-aire direct (KGGGP) qui surmonte ces limitations. 4.1 Repartitionnement M × N bas´e sur une m´ethode de partitionnement biais´e (BIASED) Nous pr´esentons dans cette section une m´ethode partitionnement biais´e permettant de r´ealiser un repartitionnement M × N en respectant un mod`ele de migration donn´e par une matrice C. Cette m´ethode n’impose que les messages donn´es dans le mod`ele de migration et non leur volume. N´eanmoins, les volumes sont respect´es lorsque le nombre de messages de C est minimal, comme 6768 CHAPITRE 4. REPARTITIONNEMENT M × N Méthode de partitionnement biaisé (Biased) Méthode diffusive (Diff) Hyperarêtes de repartitionnement Matrice de migration Nouvelle partition en N Graphe partitionné en M Repartitionnement M×N Figure 4.1 – Vue d’ensemble de nos algorithmes de repartitionnement M × N d’un graphe. nous le verrons dans la section suivante. Cette m´ethode est donc d´econseill´ee pour les mod`eles de migration n’optimisant pas TotalZ, en particulier ceux obtenus `a l’aide du programme lin´eaire optimisant seulement TotalV, MaxV ou MaxZ. Cette m´ethode de partitionnement biais´e s’inspire des m´ethodes de repartitionnement utilisant des sommets fixes [2, 8, 9] (cf. section 2.3.2). Le graphe est enrichi avec des sommets fixes et de nouvelles arˆetes puis il est partitionn´e avec un partitionneur acceptant les sommets fixes. 4.1.1 M´ethodologie Pour cr´eer un nouvelle partition respectant le mod`ele de communication construit grˆace aux m´ethodes pr´esent´ees dans le chapitre 3, on utilise une m´ethode de repartitionnement `a sommet fixes. De la mˆeme fa¸con que dans le cas du repartitionnement sans changement du nombre de processeurs, on ajoute N sommets fixes de poids nuls repr´esentant les processeurs. Mais au lieu de les connecter aux sommets de leur ancienne partie, ils sont connect´es aux sommets des parties dont on accepte qu’ils re¸coivent des donn´ees, conform´ement `a la matrice C. Plus pr´ecis´ement, pour repartitionner un graphe G de M parties vers N et obtenir une nouvelle partition P ′ , ´etant donn´e une ancienne partition P = (Pi)i∈J1,MK et une matrice de migration C, il faut : 1. construire un graphe enrichi G˜ = (V , ˜ E˜) `a partir de G avec : — N sommets fixes (fj )j∈J1,NK de poids nuls, chacun fix´e dans une nouvelle partie diff´erente j ; — des arˆetes suppl´ementaires dont le poids est appel´e « coˆut de migration », telles que pour chaque ´el´ement Ci,j > 0 de la matrice de migration, les sommets de l’ancienne partie i soient connect´es au sommet fixe de la nouvelle partie j. Plus formellement, ∀i ∈ J1, MK, ∀j ∈ J1, NK, ∀v ∈ Pi ,  Ci,j 6= 0 ⇐⇒ (v, fj ) ∈ E˜  . 2. partitionner le nouveau graphe enrichi G˜ en N parties avec un partitionneur acceptant les sommets fixes ;4.1. PARTITIONNEMENT BIAISE´ 69 3. restreindre la partition de G˜ au graphe original G pour obtenir P ′ . Le rˆole des arˆetes ajout´ees, dites « de migration », n’est pas exactement le mˆeme que dans les m´ethodes classiques. Elles ne servent pas, ici, `a minimiser la migration directement mais `a imposer le sch´ema de communication choisi. Un sommet est souvent reli´e `a plusieurs sommets fixes et au plus une de ses arˆetes de migration peut ne pas ˆetre coup´ee. Avec un poids suffisamment ´elev´e, le partitionneur laissera exactement une arˆete de migration par sommet non-coup´ee, pour minimiser la coupe. Ainsi, en cherchant `a remplir ses objectifs habituels, le partitionneur impose le sch´ema de migration choisi. Un exemple de repartitionnement est propos´e en figure 4.2. En partant de l’ancienne partition en M = 5 parties (figure 4.2a), on veut construire une nouvelle partition en N = 7 parties. A l’aide ` du graphe quotient associ´e (figure 4.2b), on construit une matrice de migration (ici repr´esent´ee par l’hypergraphe de repartitionnement) comme indiqu´e dans le chapitre pr´ec´edent (figure 4.2c). Les arˆetes de migration sont ajout´ees d’apr`es cet hypergraphe sur la figure 4.2d : par exemple, le sommet fixe de la nouvelle partie 3 est reli´e `a tous les sommets des parties contenues dans l’hyper-arˆete correspondante (les anciennes parties 3 et 4). Le partitionneur calcule ensuite une nouvelle partition de ce graphe enrichi. La figure 4.2e montre les arˆetes de migration coup´ees (en rouge) et internes (en vert). Enfin, la partition de G˜ est restreinte graphe G pour obtenir la partition finale (figure 4.2f). Cette m´ethode utilise n’importe quel outil de partitionnement classique capable de prendre en compte le cas des sommets fixes 1 . Il est aussi possible d’utiliser des partitionneurs d’hypergraphe, les arˆetes de migration deviennent alors des hyper-arˆetes de taille 2, la coupe de telles hyper-arˆetes ´etant ´equivalente `a celle des arˆetes du graphe. Les sommets fixes et les arˆetes de migration imposent le sch´ema de communication mais pas le volume des messages ´echang´es. Affecter un sommet `a une partie de fa¸con `a engendrer un message non autoris´e correspond `a une arˆete de migration coup´ee en plus. Un sommet est reli´e par des arˆetes de migration `a un ou plusieurs sommets fixes chacun dans une partie diff´erente. Au mieux une seule de ces arˆetes de migration n’est pas coup´ee (le sommet ne peut ˆetre que dans une seule partie), alors la migration de ce sommet est autoris´e par la matrice de migration. Si le sommet est dans une partie diff´erente de celles des sommets fixes auxquels il est connect´e, la migration de ce sommet n’est pas autoris´ee et toutes les arˆetes de migration de ce sommets sont coup´ees. Le partitionneur choisira donc de placer un sommet dans l’une des parties des sommets fixes auxquels il est connect´e. La contrainte sur la taille des parties n’empˆeche pas ce choix car, par construction de la matrice de migration, il y a toujours assez de sommets reli´es au sommet fixe pour cr´eer la partie de la taille souhait´ee parmi ces derniers. Bien que seul le sch´ema de communication soit impos´e, les tailles des messages sont respect´ees lorsque le nombre de message (TotalZ) est minimal. Le partitionneur est libre de cr´eer n’importe quelle partition induisant une matrice de migration avec les non-z´eros souhait´es. On cherche le nombre de matrices de migration C ′ qu’il est possible d’obtenir apr`es le partitionnement. L’espace des matrices de migration possibles peut ˆetre d´efini par un syst`eme d’´equations lin´eaires avec autant d’inconnues, not´ees C ′ i,j , que de messages (d’une ancienne partie i vers une nouvelle partie j). Les ´equations sont les contraintes de sommes sur les lignes et les colonnes ; il y en a M +N. Il y a autant d’inconnues C ′ i,j que d’´el´ements Ci,j non nuls dans la matrice de migration C souhait´ee. En notant Vi le poids de l’ancienne partie i, V ′ j la poids de la nouvelle partie j et W le poids 1. Il est en fait possible d’obtenir un partitionnement ´equivalent sans sommets fixes : il suffit de donner aux sommets « fixes » un poids suffisamment grand, pour qu’il ne puisse pas y en avoir deux dans une mˆeme partie. Les nouvelles parties sont ensuite renum´erot´ees pour que les sommets fixes soient dans les bonnes parties. Le d´efaut de cette m´ethode est que le d´es´equilibre tol´er´e est plus important `a cause du poids de ces sommets.70 CHAPITRE 4. REPARTITIONNEMENT M × N (a) Partition initiale de G en 5 parties. 1 2 3 4 5 (b) Graphe quotient Q de la partition initiale. 1 2 3 4 5 6 7 (c) Hypergraphe de repartitionnement dessin´e par dessus le graphe quotient. (d) Graphe G˜ auquel est ajout´e les sommets fixes et arˆetes de migration. (e) Partition de G˜ en 7 parties. Les arˆetes de migration coup´ees sont en rouge, les arˆetes de migration non-coup´ees en vert. (f) Partition finale de G en 7 parties. Figure 4.2 – Repartitionnement de 5 vers 7 parties.4.1. PARTITIONNEMENT BIAISE´ 71 total du graphe (W = P i Vi = P j V ′ j ), on a : ∀i ∈ J1, MK , X j∈J1,NK Ci,j>0 C ′ i,j = Vi (4.1) ∀j ∈ J1, NK , X i∈J1,MK Ci,j>0 C ′ i,j = V ′ j (4.2) La somme des ´equations sur les lignes (´equations 4.1) est ´equivalente `a la somme des ´equations sur les colonnes (´equations 4.2) et donnent : X i∈J1,MK j∈J1,NK Ci,j>0 C ′ i,j = W Ce syst`eme poss`ede donc M + N − 1 ´equations ind´ependantes 2 . On sait que l’ensemble des solutions n’est pas vide car la matrice de migration C est une solution. La dimension de l’espace solution est donc ´egale `a la diff´erence entre le nombre d’inconnues (le nombre de messages dans la matrice C) et le rang du syst`eme. Si le nombre de messages dans C n’est pas minimal (il n’atteint pas le rang du syst`eme), il existe une infinit´e de solutions C ′ possibles. Le partitionneur peut donner une de ces matrice C ′ (´eventuellement diff´erente de C) en minimisant la coupe du graphe enrichi. Plus le nombre de messages dans C est important plus il y a de libert´e dans le partitionnement. La matrice de migration C ′ effectivement obtenue apr`es repartitionnement peut ne pas ˆetre aussi bonne que la matrice C choisie. On pr´ef´erera donc utiliser ce partitionnement biais´e avec des matrices de migration donnant un faible nombre de messages (TotalZ). 4.1.2 Limitations des partitionneurs Cette m´ethode partitionnement `a sommets fixes peut poser quelques probl`emes avec certains partitionneurs, plus particuli`erement ceux utilisant des bissections r´ecursives [3]. Le premier probl`eme est que le placement et la num´erotation des nouvelles parties peut ne pas ˆetre favorable aux bissections r´ecursives. Comme expliqu´e dans la section 3.3.1, lors d’une bissection, chaque moiti´e regroupera plusieurs parties suivant leurs num´eros : g´en´eralement les parties avec les plus petits num´eros sont regroup´ees dans une moiti´e et les plus grand num´eros dans l’autre. Il est possible qu’une moiti´e regroupe des parties qu’on souhaite ´eloign´ees. Les heuristiques peuvent avoir plus de mal `a cr´eer des parties et devoir travailler avec des graphes non connexes. Mais, certains cas sont encore plus graves. Mˆeme avec des bissections parfaites et un poids tr`es important sur les arˆetes de migration, un partitionneur `a bissections r´ecursives peut ne pas 2. Il est possible de r´eduire encore le nombre d’´equations ind´ependantes lorsqu’il existe une somme partielle de poids d’anciennes parties ´egale `a une somme partielle de poids de nouvelles parties. C’est-`a-dire que s’il existe A ⊂ J1, MK et B ⊂ J1, NK tels que P i∈A Vi = P j∈B V ′ j et que pour tout (i, j) ∈ J1, MK × J1, NK tels que (i ∈ A ∧ j /∈ B) ∨ (i /∈ A ∧ j ∈ B), Ci,j = 0, alors la somme des ´equations sur les lignes correspondant aux anciennes parties de A est ´equivalente `a la somme des ´equations sur les colonnes correspondant aux nouvelles parties de B : X i∈A j∈B Ci,j>0 C ′ i,j = X i∈A Vi = X j∈B V ′ j72 CHAPITRE 4. REPARTITIONNEMENT M × N 1 2 3 4 (a) Partition intiale et sommets fixes. 3 3 4 (b) Graphe quotient et hypergraphe de repartitionnement. (c) Partition finale k-aire direct. 1–2 3–4 (d) Premi`ere bissection. (e) Partition finale avec bissections r´ecursives. Figure 4.3 – Exemple d’´echec de partitionnement avec bissections r´ecursives. respecter le sch´ema de communication impos´e alors qu’un partitionneur k-aire direct trouverait une solution [3, 60]. Par exemple, la figure 4.3 pr´esente un cas o`u la m´ethode des bissections r´ecursives ´echoue. La grille est initialement partitionn´ee en 3 (figure 4.3a) et on souhaite la repartitionner en 4 en utilisant l’hypergraphe de repartitionnement de la figure 4.3b. Un exemple de partition finale respectant ce sch´ema est pr´esent´e sur la figure 4.3c. On essaye d’appliquer les bissections r´ecursives sur ce graphe. Lors de la premi`ere bissection (figure 4.3d), le partitionneur regroupe les parties 1 et 2 d’un cot´e, et 3 et 4 de l’autre. La meilleure bissection possible est de coup´ee le graphe verticalement par le milieu. Les parties 1 et 2 seront donc dans la partie gauche et les parties 3 et 4 dans la partie droite. Il n’est donc pas possible pour la partie 4 de reprendre des sommets de l’ancienne partie 2. Chaque moiti´e est ensuite `a nouveau bipartitionn´ee pour obtenir la partition finale pr´esent´ee sur la figure 4.3e. Sa matrice de migration est :   6 6 3 9 9 3   ,4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP) 73 alors que celle attendue, qui est celle de la partition de la figure 4.3c, est :   9 3 9 3 9 3   . La partition de bissections r´ecursives coupent 39 arˆetes de migration alors qu’il est possible de n’en couper seulement 36, mˆeme si on a suppos´e que les bissections ´etaient parfaites et le poids des arˆetes de migration bien plus important que celui des arˆetes internes. En pratique, la plupart des outils utilisent un multi-niveaux k-aire avec une partition initiale du graphe contract´e calcul´ee par bissections r´ecursives. Dans le cas o`u les bissections r´ecursives ´echouent `a calculer une bonne partition initiale, le raffinement k-aire appliqu´e pendant la phase d’expansion doit alors grandement modifier la partition initiale pour optimiser la coupe. Quand l’heuristique de raffinement r´eussit `a corriger la partition initiale, ce qui est difficile comme ces heuristiques sont souvent incr´ementales, le partitionneur est alors tr`es ralenti par la phase d’expansion. Pour cette raison, nous proposons une heuristique de partitionnement k-aire direct pouvant ˆetre utilis´ee `a la place des bissections r´ecursives en tant que m´ethode de partitionnement initiale dans un partitionneur. 4.2 Partitionnement k-aire direct (KGGGP) L’heuristique du Greedy Graph Growing Partitioning (GGGP) est une heuristique gloutonne largement utilis´ee dans le cadre du bipartitionnement [5, 11, 29]. En partant de deux sommets « graines », les autres sommets sont ajout´es un `a un dans chacune des parties. Nous proposons d’´etendre cette m´ethode dans le cas du partitionnement k-aire. Nous l’appellerons dans ce cas KGGGP (k-way greedy graph growing partitioning). 4.2.1 Description de l’algorithme Cette heuristique s’inspire en grande partie de celle de Fiduccia et Mattheyses [17] (abr´eg´ee FM), `a la diff´erence que les sommets ne sont initialement dans aucune partie et sont `a distribuer dans k parties. Cette m´ethode peut ˆetre vue comme un raffinement FM k + 1-aire o`u la partie suppl´ementaire (que l’on num´erotera −1) contient initialement tous les sommets et doit ˆetre vide dans la partition finale. Pour r´ealiser cet algorithme, on consid`ere tous les d´eplacements possibles des sommets sans parties vers une des k parties. Chaque it´eration de l’algorithme 5 place un sommet sans partie dans une partie p. A chaque it´eration, on s´electionne le meilleur d´eplacement, d’ ` apr`es un crit`ere de s´election bas´e sur la coupe, qui respecte l’´equilibre final (c’est-`a-dire que le poids Wp de la partie p ne d´epassera pas la taille maximum permise avec un facteur de d´es´equilibre ǫ). Il existe plusieurs crit`eres de s´election qui seront d´etaill´es plus loin dans cette section. Il est possible qu’aucun sommet ne respecte la contrainte d’´equilibre, particuli`erement dans le cas d’un graphe contract´e dans le cadre d’un algorithme multi-niveaux, o`u des sommets peuvent avoir un poids tr`es important par rapport au poids total du graphe. Dans ce cas, l’´equilibre ne pourra pas ˆetre respect´e et le meilleur d´eplacement est choisi ind´ependamment du poids du sommet et de la partie cible. Une fois un sommet s´electionn´e, il est alors d´eplac´e et verrouill´e, c’est-`a-dire qu’il ne sera plus consid´er´e pour d’autres d´eplacements. Le crit`ere de s´election calcule le score si(u) d’un d´eplacement `a partir des parties de ses voisins (cf. section suivante). Ainsi lorsqu’un sommet est d´eplac´e, le crit`ere de s´election de chacun de ses voisins doit ˆetre mis `a jour.74 CHAPITRE 4. REPARTITIONNEMENT M × N p v s = sp(v) = sp'(v') déplacement de v dans p tableau des scores tableau des déplacements p' v' déplacement de v' dans p' ... score min score max Figure 4.4 – Structure de donn´ees inspir´ee de Fiduccia et Mattheyses, illustrant le cas des d´eplacements de v dans p et de v ′ dans p ′ ayant un mˆeme score s. L’algorithme 5 s´electionne le meilleur d´eplacement globalement. Mais il existe d’autres variantes possibles pour s´electionner un d´eplacement afin d’obtenir une partition ´equilibr´ee [29]. Par exemple, la partie de destination du d´eplacement est choisie l’une apr`es l’autre (m´ethode appel´ee round-robin), ou elle peut ˆetre la partie dont le poids courant est le plus faible. Dans ces deux cas, on choisit le meilleur d´eplacement seulement vers la partie choisie. Pour trouver rapidement le meilleur d´eplacement d’apr`es le crit`ere choisi, la structure de donn´ees pr´esent´ee par Fiduccia et Mattheyses est utilis´ee. Cette structure de donn´ees (r´esum´ee sur la figure 4.4) utilise un tableau `a chaque case duquel est associ´ee une valeur du score utilis´ee comme crit`ere de s´election (le gain de coupe du d´eplacement dans le cas de FM). Chaque case de ce tableau donne la liste doublement chain´ee des d´eplacements correspondant `a ce score. Ce tableau des scores permet de s´electionner rapidement un d´eplacement avec un gain donn´e (ici, le plus grand). Un autre tableau r´ef´eren¸cant les ´el´ements des listes chain´ees par leur num´ero de sommet permet de les retrouver rapidement pour effectuer une mise `a jour du gain. Dans notre algorithme k-aire ce tableau est ´etendu avec une seconde dimension correspondant `a la partie du d´eplacement. Le double chainage permet d’effectuer en temps constant le changement de liste d’un ´el´ement apr`es une mise `a jour ou son retrait quand le sommet est plac´e dans une partie. En pratique, notre mise en œuvre de cet algorithme utilise deux tableaux de score pour classer les d´eplacements. Initialement, le premier contient tous les d´eplacements et le second est vide. Les d´eplacements sont recherch´es d’abord dans la premi`ere structure, lorsque qu’un d´eplacement ne respectant pas la contrainte d’´equilibre est trouv´e, il est d´eplac´e dans la seconde. En effet, le poids des parties ne faisant que croˆıtre, il ne respectera pas la contrainte d’´equilibre dans le futur, il est inutile de le consid´erer `a nouveau pour ˆetre d´eplacer. Quand la premi`ere structure4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP) 75 est vide, il n’y a plus de d´eplacements respectant la contrainte d’´equilibre, la seconde structure est alors utilis´ee jusqu’`a la fin de l’algorithme et le poids de la partie n’est plus v´erifi´e. Il est tr`es simple de g´erer le cas des sommets fixes avec cette m´ethode. En effet, les sommets fixes sont simplement plac´es dans leur parties respectives initialement et ne sont pas consid´er´es dans les d´eplacements possibles. Algorithme 5 Heuristique de partitionnement gloutonne (KGGGP) Entr´ee : Graphe G `a partitionner Entr´ee : k parties ne contenant que les sommets fixes Entr´ee : Partition o`u tout les sommets fixes sont dans leur partie respective, et les autres sommets sont dans la partie −1 tant que il existe des sommets dans la partie −1 faire S´electionner un sommet v sans partie dont le d´eplacement vers une partie p a un crit`ere de s´election sp(v) maximal et tel que Wp + wv ≤ (1 + ǫ) × W/k si un tel sommet n’existe pas alors S´electionner un sommet v sans partie dont le d´eplacement vers une partie p a un crit`ere de s´election sp(v) maximal fin si Placer le sommet v dans la partie p Wp ← Wp + wv pour tout voisin u de v faire pour tout partie i faire Mettre `a jour le crit`ere de s´election si(u) fin pour fin pour fin tant que retourner Partition de G en k parties 4.2.2 Crit`eres de s´election Il existe plusieurs crit`eres pour ´evaluer la qualit´e des d´eplacements. On note sp(v), le score du d´eplacement du sommet v vers la partie p. Les d´eplacements sont ´evalu´es en fonction des arˆetes les connectant aux diff´erentes parties. On notera Ni(u) le poids des arˆetes connectant le sommet u `a des voisins dans la partie i, et N−1(u) le poids des arˆetes le connectant `a des sommets sans partie. On appelle arˆete interne, une arˆete dont les deux extr´emit´es sont dans la mˆeme partie et on appelle arˆete externe (ou coup´ee), une arˆete dont les deux extr´emit´es sont dans des parties diff´erentes. Comme avec la m´ethode FM, il est possible d’utiliser la formule du gain de coupe en consid´erant que les sommets sans parties sont dans une partie num´erot´ee −1. Le gain d’un sommet u d´eplac´e de la partie i vers j se calcule par la diff´erence entre les arˆetes vers la nouvelle partie j, qui ´etaient coup´ees mais ne le seront plus, et les arˆetes vers l’ancienne partie i, qui ´etaient internes et seront coup´ees. En reprenant la formule du gain : gi→j (u) = Nj (u) − Ni(u), le crit`ere de s´election bas´e sur le gain pour d´eplacer u dans i est si(u) = g−1→i(u) = Ni(u) − N−1(u). Battiti et Bertossi [5] proposent d’utiliser un autre crit`ere, appel´e diff. Bien que con¸cu pour le bipartitionnement, ce crit`ere peut ´egalement s’appliquer dans le cas du partitionnement k-aire. Ce crit`ere ne s’int´eresse plus aux voisins sans partie, mais utilise la diff´erence entre les nouvelles arˆetes internes (voisins dans la partie vis´ee) et les nouvelles arˆetes coup´ees (voisins dans les autres76 CHAPITRE 4. REPARTITIONNEMENT M × N i j –1 u Figure 4.5 – Diff´erentes arˆetes autour du sommet sans partie u qui se trouve `a la fronti`ere des parties i et j. parties) : si(u) = diffi (u) = Ni(u) − P j6=i Nj (u). En effet, minimiser la coupe avec la partie −1 qui finira par disparaitre peut paraitre inutile alors que les arˆetes vers les autres parties font partie de la coupe finale. D’autre part, en maximisant le nombre d’arˆetes internes (Ni(u)), on esp`ere r´eduire le nombre d’arˆetes qui devront ˆetre coup´ees plus tard. La figure 4.5 pr´esente les diff´erentes arˆetes autour du sommet u : en vert, les arˆetes correspondant `a Ni(u) ; en rouge `a Nj (u) ; et en bleu `a N−1(u). On suppose que toutes les arˆetes de cet exemple ont un poids unitaire. Si on consid`ere le d´eplacement de u dans la partie i, le gain est g−1→i(u) = 0 : initialement 3 arˆetes sont coup´ees (en vert et rouge), apr`es d´eplacement 3 arˆetes sont toujours coup´ees (cette fois en bleu et rouge). Le crit`ere diff ne s’int´eresse pas aux arˆetes avec les sommets sans partie (en bleu) mais seulement `a la diff´erence entre les futures arˆetes internes (en vert) et les arˆetes externes avec les « vraies » parties (en rouge). On a donc diffi (u) = 2 − 1 = 1. 4.2.3 Complexit´e L’algorithme de partitionnement d´eplace une fois chaque sommet libre. Il y a donc autant d’it´erations de la boucle principale que de sommets non fixes (au plus |V |). La boucle principale comporte les ´etapes de s´election, d´eplacement et mise `a jour des structures de donn´ees. Lors de la s´election, chaque d´eplacement n’est consid´er´e qu’une ou deux fois : s’il n’est pas accept´e la premi`ere fois, il est retir´e de la premi`ere liste des d´eplacements et plac´e dans la seconde ; dans la seconde liste, un d´eplacement n’est jamais rejet´e. La complexit´e en temps totale de la s´election est donc au pire proportionnelle au nombre de d´eplacements possibles, c’est-`a-dire O(k|V |). Le d´eplacement est une op´eration simple en temps constant. Cela n’est que le changement d’une valeur dans le tableau repr´esentant la partition. La mise `a jour des structures de donn´ees apr`es le d´eplacement d’un sommet, n´ecessite de visiter tous les voisins du sommet d´eplac´e. Pour chaque voisin, il est n´ecessaire de mettre `a jour le crit`ere de s´election vers chacune des k parties. Comme ces op´erations sont effectu´ees pour chaque sommet du graphe, la complexit´e en temps totale des mises `a jour est au pire O(k|E|). La complexit´e en temps de l’algorithme est donc au pire O(k|E|), en consid´erant que |V | est domin´e par |E|. La complexit´e en m´emoire est principalement due au stockage des d´eplacements possibles, elle est donc au pire O(k|V |).4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP) 77 4.2.4 Am´eliorations Plusieurs variantes peuvent ˆetre utilis´ees pour am´eliorer la qualit´e des partitions produites par l’algorithme. a) S´election al´eatoire et r´ep´etition Lors de la s´election des sommets, plusieurs peuvent avoir le mˆeme score. Si le premier sommet trouv´e est choisi, la s´election est biais´ee par l’ordre de parcours des sommets ou par le dernier d´eplacement. En effet, lors de la mise `a jour, les voisins dont le score s’est am´elior´e se retrouvent en d´ebut de liste, ce qui tend `a faire grossir la partie toujours dans la mˆeme direction. En s´electionnant un sommet al´eatoire parmi les meilleurs, on ´evite ce biais. Cela permet d’obtenir des partitions diff´erentes avec diff´erentes ex´ecutions de l’algorithme. Comme cet algorithme est tr`es rapide lorsqu’il est appliqu´e dans le cadre d’un partitionnement multi-niveaux, il devient int´eressant de le r´ep´eter plusieurs fois et de garder la meilleure partition. Cela permet aussi une version parall`ele triviale o`u chaque nœud calcule une partition puis partage la meilleure. b) Graines Bien que l’algorithme puisse s’appliquer sans aucun sommet initialement dans une partie, les crit`eres de s´election ne seront pas tr`es efficaces pour le choix des premiers sommets. Il est donc int´eressant de choisir avant le d´ebut de l’algorithme certains sommets qui initieront les parties. Il existe plusieurs possibilit´es pour choisir ces sommets qu’on appelle « graines ». Graines al´eatoires. k sommets sont choisis al´eatoirement dans le graphe pour servir de graines `a chacune des parties. Ces techniques se combinent bien avec la r´ep´etition de l’heuristique et permettent encore plus de vari´et´e dans les tentatives pour trouver la meilleure partition possible. Graines au centre des parties. La r´ep´etition de l’heuristique peut ´egalement ˆetre utilis´ee pour trouver des graines de fa¸con plus intelligente. Apr`es une premi`ere passe `a l’aide de graines choisies d’une mani`ere quelconque, les centres 3 ou des « pseudo-centres 4 » des parties sont calcul´es et servent de graine `a l’it´eration suivante. Cette m´ethode est propos´ee par Diekmann et al. dans le cadre du Bubble Partitioning [14]. Graines ´eloign´ees. Diekmann et al. [14] proposent ´egalement un algorithme pour optimiser l’ensemble des graines initiales. L’algorithme 6 permet de construire un ensemble de k graines bien ´eloign´ees les unes des autres. En partant d’un sommet quelconque, on recherche le sommet le plus ´eloign´e `a l’aide d’un parcours en largeur. Les graines suivantes sont trouv´ees de fa¸con similaire en initialisant le parcours en largeur avec les n graines d´ej`a trouv´ees. La seconde boucle permet d’am´eliorer cet ensemble. On retire une `a une les graines de l’ensemble et on en cherche une nouvelle, toujours `a l’aide d’un parcours en largeur. Cette derni`ere boucle peut ˆetre r´ep´et´ee jusqu’`a ce que l’ensemble ne change plus ou r´ep´et´ee un nombre limit´e de fois. La complexit´e d’un parcours en largeur ´etant O(|E|), la complexit´e de la cr´eation de l’ensemble initiale ou d’une passe d’optimisation est O(k|E|). 3. Le centre d’un graphe est un sommet avec une excentricit´e minimale. 4. La recherche du centre d’un graphe est complexe. Nous pr´ef´erons donc chercher un « pseudo-centre » `a l’aide d’un parcours en largeur `a partir de la fronti`ere de la partie. Le dernier sommet parcouru est le plus ´eloign´e de la fronti`ere, il est donc s´electionn´e en tant que « pseudo-centre »78 CHAPITRE 4. REPARTITIONNEMENT M × N Algorithme 6 Cr´eation d’un ensemble de k graines ´eloign´ees Entr´ee : Graphe G Entr´ee : Nombre de parties k v ← sommet quelconque de G graines ← {sommet le plus ´eloign´e de v dans G} n ← 1 tant que n < k faire v ← sommet le plus ´eloign´e des sommets dans graines Ajouter v dans graines n ← n + 1 fin tant que r´ep´eter pour tout v ∈ graines faire u ← sommet le plus ´eloign´e des sommets dans graines \ {v} si u est plus loin que v alors Remplacer v par u dans graines fin si fin pour jusqu’`a Aucune graine n’a ´et´e chang´ee retourner graines c) Raffinement `a la fin Les derniers choix de d´eplacement lors du KGGGP sont souvent tr`es limit´es et les derniers sommets se retrouvent plac´es dans les parties qui pouvaient encore accepter des sommets malgr´e une tr`es mauvaise coupe. Pour corriger ces d´efauts, il est n´ecessaire d’appliquer un l´eger raffinement de type FM `a la partition obtenue. Bien que tr`es l´eger, ces raffinements peuvent grandement am´eliorer la coupe, il est donc int´eressant de le prendre en compte dans la r´ep´etition de l’algorithme glouton, que ce soit pour d´ecider la partition `a garder ou calculer de nouvelles graines `a l’aide des centres des parties. 4.2.5 Evaluation ´ Cette m´ethode de partitionnement a ´et´e mise en œuvre dans un module Scotch [48]. L’avantage de Scotch est d’ˆetre un logiciel libre tr`es modulaire. Cela permet de r´eutiliser les autres m´ethodes d´ej`a pr´esentes dans Scotch, en particulier l’approche multi-niveaux et les m´ethodes de raffinement. Pour combiner ces diff´erentes strat´egies de partitionnement, Scotch utilise des chaˆınes de strat´egies permettant de configurer l’enchainement, l’imbrication et les param`etres des diff´erentes strat´egies. Notre strat´egie de KGGGP est document´ee dans l’annexe B. Pour ´evaluer le KGGGP, notre m´ethode est compar´ee `a la strat´egie de bissections r´ecursives de Scotch. La strat´egie utilis´ee pour les bissections r´ecursives (RB) dans les exp´eriences suivantes est celle utilis´ee par d´efaut dans Scotch, elle est donn´ee par la chaˆıne de strat´egie suivante : r{job=t,map=t,poli=S,bal=0.01,sep= m{vert=120,low=h{pass=10}f{bal=0.01,move=120}, asc=b{bnd=f{bal=0.01,move=120},org=f{bal=0.01,move=120}}}| m{vert=120,low=h{pass=10}f{bal=0.01,move=120}, asc=b{bnd=f{bal=0.01,move=120},org=f{bal=0.01,move=120}}}| m{vert=120,low=h{pass=10}f{bal=0.01,move=120},4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP) 79 Graphe Description |V | |E| d grid3d32 Grille 3D r´eguli`ere 32 768 95 232 5,81 grid3d100 Grille 3D r´eguli`ere 1 000 000 2 970 000 5,94 cfd2 M´ecanique des fluides num´eriques (CFD) 123 440 1 482 229 24,02 crankseg 2 Probl`eme structurel 63 838 7 042 510 220,64 thermal2 Probl`eme thermique 1 228 045 3 676 134 5,99 brack2 Probl`eme 2D/3D 62 631 366 559 11,71 wave Probl`eme 2D/3D 156 317 1 059 331 13,55 cage12 Electrophor`ese d’ADN ´ 130 228 951 154 14,61 Table 4.1 – Description des graphes utilis´es pour nos exp´eriences. d est le degr´e moyen du graphe qui vaut 2×|E| |V | . asc=b{bnd=f{bal=0.01,move=120},org=f{bal=0.01,move=120}}} } C’est-`a-dire que, pour chaque bissection, trois partitionnements multi-niveaux (m) sont calcul´es et la meilleure partition est retenue. Ces partitionnements multi-niveaux pour les bissections sont utilis´es en plus du multi-niveaux principal dans lequel cette strat´egie de bissections r´ecursives est ´eventuellement utilis´ee. Ils utilisent comme strat´egie de partitionnement initial une m´ethode de greedy graph growing (h) d´ej`a pr´esente dans Scotch mais seulement pour les bissections, et comme raffinement un algorithme FM (f). Le tableau 4.1 pr´esente les diff´erents graphes utilis´es dans les exp´eriences. Les graphes grid3d32 et grid3d100 sont des grilles cubiques de tailles respectives 32 × 32 × 32 et 100 × 100 × 100. Les autres graphes sont issus de la collection de matrices creuses de l’Universit´e de Floride [13]. a) Cas du partitionnement classique Plusieurs configurations du KGGGP sont ´evalu´ees. Les deux crit`eres de s´election bas´es sur le gain de coupe (type=g) et diff (type=d) sont utilis´es pour chaque cas : — Une seule passe et sans raffinement : g-noref-1p g{bal=0.01,type=g,pass=1,ref=} d-noref-1p g{bal=0.01,type=d,pass=1,ref=} — Quatre passes avec deux passes de raffinement FM chacune : g-ref-4p g{bal=0.01,type=g,pass=4,ref= f{bal=0.01,pass=2,move=200}} d-ref-4p g{bal=0.01,type=d,pass=4,ref= f{bal=0.01,pass=2,move=200}} — Quatre passes avec deux passes de raffinement FM chacune et l’utilisation de graines al´eatoires (seeds=r) : g-ref-4p-rand g{bal=0.01,type=g,pass=4,seeds=r,center=n,ref= f{bal=0.01,pass=2,move=200}} d-ref-4p-rand g{bal=0.01,type=d,pass=4,seeds=r,center=n,ref= f{bal=0.01,pass=2,move=200}} — Quatre passes avec deux passes de raffinement FM chacune et l’utilisation de graines ´eloign´ees (seeds=o) pour la premi`ere passe puis des « centres » des parties (center=y) pour les suivantes :80 CHAPITRE 4. REPARTITIONNEMENT M × N 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0 20 40 60 80 100 120 140 Temps (s) Nombre de parties RB KGGGP (g-noref-1p) Figure 4.6 – Temps du partitionnement de la grille 32×32×32 sans multi-niveaux, avec KGGGP (une passe et sans raffinement) en comparaison avec RB suivant le nombre de parties. g-ref-4p-opt g{bal=0.01,type=g,pass=4,seeds=o,center=y,ref= f{bal=0.01,pass=2,move=200}} g-ref-4p-opt g{bal=0.01,type=d,pass=4,seeds=o,center=y,ref= f{bal=0.01,pass=2,move=200}} La figure 4.7 pr´esente la coupe et la figure 4.8 pr´esente le temps obtenus pour le partitionnement des diff´erents graphes avec la m´ethode KGGGP relativement `a la m´ethode des bissections r´ecursives (RB), toutes sans utiliser de multi-niveaux. Les deux premi`eres strat´egies ne faisant qu’une passe et n’utilisant pas de raffinement donnent une coupe beaucoup plus ´elev´ee. En effet, le KGGGP a g´en´eralement du mal `a bien placer les derniers sommets, le raffinement FM permet de corriger les mauvais choix faits par l’algorithme glouton. Le temps d’ex´ecution de ces strat´egies est ´evidement plus rapide que celles faisant plusieurs passes et utilisant un raffinement. On remarque ´egalement que, parmi les deux types de crit`ere de s´election utilis´es, celui bas´e sur le gain de coupe donne toujours de meilleurs r´esultats que le diff. L’utilisation de graines a g´en´eralement peu d’influence sur la coupe, bien qu’on remarque une l´eg`ere am´elioration sur quelques cas. La coupe des meilleures strat´egies KGGGP est ´egale ou sup´erieure (jusqu’`a 20 % plus ´elev´ee) `a celle des bissections. Le KGGGP est ´egalement plus lent : en effet, sa complexit´e en temps est O(k|E|) alors que celle des bissections r´ecursives est O(log(k)|E|). La figure 4.6 donne les temps d’ex´ecution des bissections r´ecursives et du KGGGP (avec 1 passe et sans raffinement). Les courbes sans multi-niveaux correspondent bien aux complexit´es attendues. Mais, en pratique, ces strat´egies sont utilis´ees syst´ematiquement avec une m´ethode multiniveaux. Les figures 4.9 et 4.10 montrent les r´esultats dans le mˆeme cas que les figures pr´ec´edentes mais en utilisant les strat´egies (RB et KGGGP) dans une approche multi-niveaux utilisant un4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP ) 81 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 brack2cage12cfd2 crankseg_2 grid3d32thermal2wave Coupe g-noref-1p g-ref-4p g-ref-4p-rand g-ref-4p-opt d-noref-1p d-ref-4p d-ref-4p-rand d-ref-4p-opt RB Figure 4.7 – Coupe de partitions en 32 parties sans multi-niveaux.82 CHAPITRE 4. REPARTITIONNEMENT M × N 0 2 4 6 8 10 12 14 16 18 brack2cage12cfd2 crankseg_2 grid3d32thermal2wave Temps g-noref-1p g-ref-4p g-ref-4p-rand g-ref-4p-opt d-noref-1p d-ref-4p d-ref-4p-rand d-ref-4p-opt RB Figure 4.8 – Temps de partitionnement en 32 parties sans multi-niveaux.4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP ) 83 0.95 1 1.05 1.1 1.15 1.2 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave Coupe g-noref-1p g-ref-4p g-ref-4p-rand g-ref-4p-opt d-noref-1p d-ref-4p d-ref-4p-rand d-ref-4p-opt RB Figure 4.9 – Coupe de partitions en 32 parties avec un m´ethode multi-niveaux.84 CHAPITRE 4. REPARTITIONNEMENT M × N 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave Temps g-noref-1p g-ref-4p g-ref-4p-rand g-ref-4p-opt d-noref-1p d-ref-4p d-ref-4p-rand d-ref-4p-opt RB Figure 4.10 – Temps de partitionnement en 32 parties avec un m´ethode multi-niveaux.4.3. REPARTITIONNEMENT M × N BASE SUR LA DIFFUSION ( ´ DIFF) 85 raffinement FM k-aire. Les r´esultats en coupe et temps sont beaucoup plus proches : les phases de contraction et de raffinement prennent le plus de temps alors que la le partitionnement initial est plus rapide comme il s’applique sur un graphe de petite taille ; la coupe finale est largement due au raffinement du multi-niveaux, le partitionnement initial ne lui sert que d’initialisation. L’absence de raffinement n’a plus autant d’importance, le raffinement utilis´e lors de la phase d’expansion corrige d´ej`a la plupart des d´efauts du partitionnement initial. Le type de crit`ere de s´election a toujours un impact significatif sur la coupe finale. Dans le cas de grid3d100, les bissections r´ecursives sont capables de trouver une bonne partition directement grˆace `a la nature r´eguli`ere du graphe. La phase de raffinement est donc plus plus courte. Le partitionnement RB est donc dans ce cas beaucoup plus rapide que le KGGGP qui profite moins de la r´egularit´e du graphe. La coupe obtenue avec les strat´egies KGGGP (en utilisant le crit`ere de s´election bas´e sur le gain) est tr`es proche des bissections r´ecursives : entre −5 % et +5 %. Notre algorithme de partitionnement KGGGP offre des partitions de qualit´e similaire au partitionnement utilisant des bissections r´ecursives. Mais cette m´ethode de partitionnement souffre d’une complexit´e plus importante par rapport au nombre de parties. b) Partitionnement avec sommets fixes Dans la section 4.1.2, nous avons mis en ´evidence les difficult´es des partitionneurs utilisant des bissections r´ecursives `a partitionner les graphes construits dans le cadre de notre partitionnement biais´e avec sommets fixes. Nous ´evaluons donc notre m´ethode de partitionnement KGGGP appliqu´ee sur les graphes d´ej`a pr´esent´es mais modifi´es selon la m´ethode de la section 4.1. Les graphes sont enrichis pour un repartitionnement 16×21 avec un poids 1 pour les arˆetes du graphe original et un poids 10 pour les arˆetes de migration. Les figures 4.11 et 4.12 donnent les coupes et temps obtenus pour partitionner ces graphes enrichis. Nous utilisons un partitionnement multi-niveaux avec KGGGP en 4 passes avec raf- finement relativement aux bissections r´ecursives. Dans tous les cas, la coupe du KGGGP est inf´erieure `a celle des bissections r´ecursives, parfois de fa¸con tr`es importante (plus de 40% de r´eduction dans les meilleurs cas). Comme les arˆetes de migration ont un poids beaucoup plus important, les valeurs de coupes donn´ees concernent principalement les arˆetes des migration. Les temps de partitionnement sont g´en´eralement plus ´elev´es qu’avec les bissections r´ecursives mais restent du mˆeme ordre de grandeur. Bien que notre algorithme KGGGP ne donnait pas des meilleurs r´esultats que les bissections r´ecursives pour des partitionnements de graphes classiques, les r´esultats sont bien meilleurs dans le cas de graphes modifi´es avec des sommets fixes et des arˆetes de migration. Cela confirme les inconv´enients d’utiliser des bissections r´ecursives pour partitionner des tels graphes. 4.3 Repartitionnement M ×N bas´e sur la diffusion (DIFF) Nous proposons dans cette section une autre approche pour repartitionner un graphe en se basant sur une matrice de migration donn´ee. Cette approche s’inspire des m´ethodes de repartitionnement diffusives d´ej`a utilis´ees dans le cas du repartitionnement classique. La m´ethode de repartitionnement biais´e n’impose pas correctement les messages choisis lorsque ceux-ci sont trop nombreux. Cela peut poser probl`eme dans le cas o`u on veut utiliser une matrice de migration avec un nombre de messages plus ´elev´e, en particulier les matrices de migration obtenues `a l’aide de programmes lin´eaires ne minimisant pas TotalZ. Le repartitionnement bas´e sur la diffusion r`egle ce probl`eme en migrant exactement le nombre de sommets souhait´e.86 CHAPITRE 4. REPARTITIONNEMENT M × N 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 brack2 cage12 cfd2 crankseg_2 grid3d32 thermal2 wave Coupe g-ref-4p RB Figure 4.11 – Coupe de partitionnement en 21 parties (avec une m´ethode multi-niveaux) des graphes enrichis pour un repartitionnement 16 × 21. 0.5 1 1.5 2 2.5 3 3.5 brack2 cage12 cfd2 crankseg_2 grid3d32 thermal2 wave Temps g-ref-4p RB Figure 4.12 – Temps de partitionnement en 21 parties (avec une m´ethode multi-niveaux) des graphes enrichis pour un repartitionnement 16 × 21.4.3. REPARTITIONNEMENT DIFFUSIF 87 Le repartitionnement classique bas´e sur la diffusion [55] modifie l’ancienne partition en migrant des sommets d’une partie `a l’autre en se basant sur une matrice de migration C donn´ee. Pour chaque ´el´ement Ci,j de la matrice migration, exactement Ci,j sommets de la partie i sont d´eplac´es dans la partie j. Les sommets `a migrer sont choisis d’une fa¸con similaire `a l’heuristique FM mais en arrˆetant les d´eplacements quand le poids souhait´e (d’apr`es la matrice de migration) a ´et´e d´eplac´e, au lieu de s’arrˆeter lorsque la coupe optimale est atteinte. Cette heuristique fonctionne bien quand il est n´ecessaire de d´eplacer peu de sommets le long d’une fronti`ere s´eparant deux parties. Dans le cas du repartitionnement avec changement du nombre de parties, cette heuristique rencontre quelques probl`emes. D’une part, certaines parties connaissent une migration importante : les parties cr´ees ou supprim´ees au cours du repartitionnement. D’autre part, certaines migrations de sommets doivent ˆetre d´ecid´ees alors qu’il n’existe initialement aucune fronti`ere. C’est le cas des parties initialement vides lorsque le nombre de parties augmente (N > M). Si une partie ne poss`ede initialement aucun sommet, une heuristique choisissant les sommets suivant leur gain de coupe, commencera par s´electionner les sommets de plus petit degr´e parmi ceux des parties qui doivent donner des sommets `a la nouvelle. Ces sommets peuvent ˆetre ´eloign´es les uns des autres, ce qui va cr´eer une partie en petits morceaux dispers´es. Un tel cas est visible sur la figure 4.13. La partition initiale en 5 parties (figure 4.13a) est ´equilibr´ee permettant ainsi de se concentrer sur l’ajout des nouvelles parties. Dans ce cas, il n’y a pas d’´echanges de sommets entre les anciennes parties. Les deux nouvelles parties prennent chacune des sommets depuis trois anciennes parties : bleu fonc´e, gris clair et orange pour la partie vert fonc´e et bleu fonc´e, bleu clair et rouge pour la partie vert clair. La figure 4.13b montre un exemple de repartitionnement o`u l’heuristique a construit les nouvelles parties aux mauvais endroits : les parties ajout´ees (en vert) sont d´ecoup´ees en plusieurs bouts, augmentant ainsi la taille de la fronti`ere. Pour r´egler ce probl`eme de parties initialement vides, il est n´ecessaire d’ajouter quelques sommets qui permettront d’initier la cr´eation de la nouvelle partie. Le choix de ces graines doit se faire `a l’aide d’une m´ethode plus globale, id´ealement au centre de la future partie et ayant des voisins parmi toutes les anciennes parties intervenant dans la migration de la nouvelle partie `a cr´eer. Trouver de telles sommets peut demander des algorithmes complexes. Une m´ethode na¨ıve est de rechercher les sommets ayant des voisins parmi les autres anciennes parties voulues et d’en prendre un au hasard. De telles sommets n’existent pas toujours comme il n’est pas toujours possibles de cr´eer des parties connexes pour certaines matrices de migration choisies. La figure 4.13d montre un repartitionnement obtenu `a l’aide de graines ajout´ees `a la fronti`ere des trois anciennes parties donnant des sommets `a une mˆeme nouvelle partie comme indiqu´e sur la figure 4.13c. Que la migration soit faite par paire de parties ´emettrice–r´eceptrice ou globalement, l’ordre dans lequel sont effectu´es les d´eplacements de sommets a une grande influence sur le r´esultat final. En effet, les sommets peuvent g´en´eralement ˆetre d´eplac´es vers plusieurs autres parties et il faut donc choisir dans quel ordre consid´erer ces parties. Schloegel et al. [58] ´etudie se probl`eme dans le cas de repartitionnement classique. Les solutions les plus simples sont un ordre al´eatoire ou de consid´erer en priorit´e les parties ´emettrices qui ont d´ej`a re¸cu tous les sommets dont elles ont besoin. Si ce dernier ordonnancement est choisi, cela peut poser probl`eme lors de la cr´eation de nouvelles parties. Ces nouvelles parties seraient alors traiter en dernier car elles ne sont que r´eceptrices. Mais les d´eplacements pr´ec´edents changent les fronti`eres et ´eventuellement la forme du graphe quotient qui a ´et´e utilis´e pour choisir l’emplacement de ces nouvelles parties. Les anciennes parties donnant `a une mˆeme nouvelle partie peuvent ne plus ˆetre proches quand arrive le moment de construire cette nouvelle partie. Notre r´ealisation pr´eliminaire du repartitionnement diffusif utilise le graphe entier sans approche multi-niveaux et sans utiliser de raffinement, ce qui limite la qualit´e de la coupe finalement88 CHAPITRE 4. REPARTITIONNEMENT M × N (a) Ancienne partition en 5 parties. (b) Nouvelle partition en 7 parties sans utiliser de graines. (c) Ajout de graines sur l’ancienne partition. (d) Nouvelle partition en 7 parties en utilisant des graines. Figure 4.13 – Exemple d’ajout de deux nouvelles parties prenant des sommets depuis trois anciennes chacune `a l’aide de la diffusion.4.4. REPARTITIONNEMENT AVEC HYPER-ARETES ˆ 89 obtenue. Les migrations sont effectu´ees par paires de parties en commen¸cant par les parties initialement vides (les processeurs ajout´es) puis les paires d’anciennes parties en commen¸cant par celles o`u les parties ´emettrices ont d´ej`a re¸cu tous leurs sommets. 4.4 Partitionnement biais´e `a l’aide d’hyper-arˆetes de repartitionnement En utilisant un mod`ele hypergraphe (plutˆot que graphe) et la coupe connectivit´e − 1 (not´ee λ − 1), il est possible d’optimiser le nombre de messages lors du repartitionnement avec une nouvelle approche. Cette m´ethode optimise directement la migration lors du repartitionnement et ne n´ecessite pas de matrice de migration en entr´ee, comme le sugg`ere la figure 4.1. En ajoutant, pour chaque ancienne partie, une hyper-arˆete regroupant tous les sommets de cette partie, le crit`ere de coupe sera modifi´e pour prendre en compte le nombre de messages. En effet, ces hyper-arˆetes seront coup´ees par λ parties qui prendront des sommets de cette ancienne partie. Chaque nouvelle partie qui coupe une de ces hyper-arˆetes induit un message de migration avec l’ancienne partie associ´ee `a cette hyper-arˆete. On note λi , le nombre de parties qui coupent l’hyper-arˆete correspondant `a l’ancienne partie i et wmsg le poids de ces hyper-arˆetes. λi est ´egale au nombre de non-z´eros sur la ligne i de la matrice de migration C. Comme le poids de chaque hyper-arˆete est compt´e λi − 1 fois, la coupe totale de toutes ces hyper-arˆetes ajout´ees est : X i∈J1,MK (λi − 1) × wmsg =   X i∈J1,MK λi − M   × wmsg = (nnz(C) − M) × wmsg o`u nnz(C) est le nombre de non-z´eros dans la matrice de migration C. En notant G l’hypergraphe initial et G′ l’hypergraphe enrichi des hyper-arˆetes de poids wmsg, on obtient : cut(G ′ ) = cut(G) + wmsg × (nnz(C) − M) ≈ cut(G) + wmsg × TotalZ Remarquons que nnz(C) − M est `a peu pr`es le nombre total de messages. TotalZ est le nombre d’´el´ements non nuls hors diagonale de la matrice de migration. Dans le cas o`u la diagonale ne poss`ede aucun ´el´ement nul, on a TotalZ = nnz(C) − min(M, N). Ainsi en minimisant la coupe du graphe enrichi, le partitionneur minimise donc un compromis entre la coupe du graphe initial et le nombre de messages. Si le poids wmsg de ces arˆetes est suffisamment grand, cela revient `a minimiser le nombre de messages dans un premier temps puis `a minimiser la coupe dans un second temps. Par ailleurs, cette m´ethode optimisant TotalZ peut ˆetre combin´ee avec une strat´egie de partitionnement biais´e optimisant le volume de migration TotalV. Pour cela, on reprend la m´ethode de repartitionnement `a sommets fixes [2, 9] : on construit l’hypergraphe enrichi G′′ en ajoutant un sommet fixe pour chaque ancienne partie, et des hyper-arˆetes de taille 2 reliant les sommets fixes aux autres sommets appartenant `a l’ancienne partie correspondante avec un poids wmig. La coupe du nouveau graphe G′′ devient alors : cut(G ′′) = cut(G ′ ) + wmig × TotalV ≈ cut(G) + wmsg × TotalZ + wmig × TotalV90 CHAPITRE 4. REPARTITIONNEMENT M × N Bien que cette m´ethode soit capable de bien mod´eliser les objectifs du repartitionnement, l’application `a l’aide d’un partitionneur d’hypergraphe ne donne pas de bons r´esultats. Partitionner un tel graphe enrichi `a la fois avec de grandes hyper-arˆetes et les sommets fixes connect´es `a de nombreux sommets est effectivement tr`es complexe. Comme il a d´ej`a ´et´e expliqu´e dans la section 4.1.2, les strat´egies de bissections r´ecursives couramment utilis´ees par les partitionneurs peuvent avoir du mal `a trouver de bonnes partitions pour certains types de graphes ou d’hypergraphes. Dans le cas des hypergraphes, en plus des probl`emes avec les sommets fixes, les bissections optimisent moins bien la coupe connectivit´e−1 des grandes hyper-arˆetes. Il serait n´eanmoins possible d’am´eliorer le partitionnement `a l’aide d’un algorithme k-aire direct adapt´e aux hypergraphes [3] 5 . Mais mˆeme avec un partitionnement k-aire, la phase de contraction dans un partitionnement multi-niveaux peut aussi ˆetre perturb´ee par ces grandes hyper-arˆetes : il peut ˆetre d´ecid´e de fusionner des sommets tr`es ´eloign´es s’ils appartiennent `a la mˆeme hyper-arˆete. Il donc important d’utiliser un algorithme de contraction adapt´e qui donnerait moins d’importance, voire ignorerait, ces grandes hyper-arˆetes malgr´e leur poids important. 4.5 Conclusion Dans ce chapitre, nous avons pr´esent´e trois m´ethodes de repartitionnement M × N. Notre partitionnement biais´e (BIASED) permet d’obtenir un bon partitionnement (´equilibre et coupe faible) tout en imposant un sch´ema de communication donn´e, mais cette m´ethode n’impose pas toujours la matrice de migration souhait´ee. Notre partitionnement diffusif (DIFF) permet d’appliquer strictement une matrice de communication mais la coupe est moins bien optimis´ee, en particulier pour les nouvelles parties, qui induisent d’importantes migrations. Nous avons aussi pr´esent´e une m´ethode de partitionnement biais´e bas´e sur des hyper-arˆetes permettant de minimiser directement TotalZ et TotalV sans utiliser de matrice de migration en entr´ee. Mais cette derni`ere m´ethode ne donne pas de bonne partition avec les outils actuels et ne sera pas ´evalu´ee par la suite. 5. Le partitionneur kPaToH pr´esent´e par Aykanat et al. n’est malheureusement pas disponible.Chapitre 5 R´esultats Sommaire 5.1 M´ethodologie exp´erimentale . . . . . . . . . . . . . . . . . . . . . . . 91 5.2 Influence du coˆut de migration et du facteur de repartitionnement 94 5.3 Influence du nouveau nombre de processeurs . . . . . . . . . . . . . 97 5.4 Comparaison sur des graphes complexes . . . . . . . . . . . . . . . 101 5.5 Etude de la complexit´e en temps . . . . . . . . . . . . . . . . . . . . 110 ´ Dans ce chapitre, nous pr´esentons plusieurs exp´eriences permettant d’´evaluer nos m´ethodes de repartitionnement en les comparant aux partitionneurs actuels. 5.1 M´ethodologie exp´erimentale Pour rappel, les objectifs du repartitionnement M × N sont : — ´equilibrer la charge des diff´erentes parties ; — minimiser la coupe du graphe ; — calculer rapidement la nouvelle partition ; — optimiser la migration. Le premier objectif, l’´equilibrage, est toujours atteint par les partitionneurs : dans les ´evaluations suivantes la tol´erance au d´es´equilibre est de 1%, c’est-`a-dire que la plus grosse partie ne d´epassera pas de plus de 1% la taille moyenne des parties. Pour les trois autres objectifs, des m´etriques sont utilis´es : la coupe ; TotalV, MaxV, TotalZ, MaxZ pour la migration ; et le temps d’ex´ecution du partitionneur. Dans ce chapitre, nous ´evaluons les m´ethodes de repartitionnement M × N Biased et Diff que nous avons propos´es, dans deux variantes chacunes. La premi`ere m´ethode combine la construction de la matrice de migration `a l’aide de l’algorithme glouton (plus pr´ecis´ement l’algorithme Greedy2 optimisant le nombre de messages) et le partitionnement biais´e utilisant les sommets fixes. L’algorithme glouton peut optimiser ou non la diagonale de la matrice de migration. Dans le chapitre 3, il a ´et´e montr´e que ces deux variantes permettent d’obtenir un TotalZ bas. L’optimisation de la diagonale permet de minimiser TotalV mais en augmentant MaxZ. Ces deux strat´egies seront appel´ees BiasedGreedyD pour la variante optimisant la diagonale, BiasedGreedy sinon. Le partitionnement biais´e est r´ealis´e `a l’aide de Scotch et de la m´ethode de partitionnement k-aire direct pr´esent´ees dans la section 4.2 9192 CHAPITRE 5. RESULTATS ´ et int´egr´ee `a Scotch. Notons que le partitionnement est biais´e en modifiant le graphe fourni au partitionneur et non en utilisant les fonctionnalit´es de repartitionnement disponibles dans Scotch. La seconde m´ethode construit la matrice de migration `a l’aide du programme lin´eaire minimisant soit TotalV, soit MaxV. Cette construction de la matrice de migration ne donne pas un TotalZ minimal (mais garantit un MaxZ faible), il est donc pr´ef´erable d’utiliser la m´ethode diffusive pour repartitionner le graphe d’apr`es ces matrices de migration. On nommera DiffTV la strat´egie minimisant TotalV et DiffMV la strat´egie minimisant MaxV. Ces m´ethodes seront compar´ees `a des m´ethodes de repartitionnement classiques : — une m´ethode de Scratch-Remap ; — la m´ethode de repartitionnement de Zoltan ; — celle de ParMetis ; — et celle de Scotch. La m´ethode de Scratch-Remap est mise en œuvre `a l’aide du partitionnement from scratch (sans repartitionnement) de Scotch et de l’algorithme 1 de remapping. Il est important de noter que les partitionneurs Zoltan, ParMetis et Scotch n’ont pas ´et´e d´evelopp´es pour le repartitionnement M × N mais il est tout de mˆeme possible des les utiliser dans ce cas. Cela revient `a un repartitionnement N × N o`u certaines parties sont initialement vides lorsque le nombre de processeurs augmente (M < N) ou certains sommets sont sans partie lorsque le nombre de processeurs diminue (M > N). Zoltan est un partitionneur d’hypergraphe 1 poss´edant une m´ethode de repartitionnement biais´ee `a l’aide de sommets fixes. Le poids des arˆetes de migration choisi est 1 comme celui des arˆetes du graphe `a partitionner. Cela permet d’obtenir un bon compromis entre coupe et migration. Bien que Zoltan soit un partitionneur parall`ele, il est utilis´e avec un seul processus dans nos exp´eriences. ParMetis utilise une m´ethode de repartitionnement hybride choisissant le meilleur r´esultat entre un repartitionnement diffusif et un Scratch-Remap pour le partitionnement initial d’un repartitionnement multi-niveaux [58]. Le raffinement utilis´e est biais´e pour prendre en compte un compromis entre coupe et volume de migration. ParMetis prend en compte un rapport de coˆut entre la coupe et le volume de migration. Comme avec Zoltan, ce param`etre est fix´e `a 1. ParMetis est un partitionneur parall`ele qui ne peut pas ˆetre utilis´e avec moins de deux processus. Dans les exp´eriences suivantes, ParMetis profite donc de deux processus, alors que les autres partitionneurs sont utilis´es en s´equentiel. Scotch est capable de repartitionner `a l’aide d’une m´ethode de partitionnement biais´e. La strat´egie de partitionnement de Scotch peut ˆetre choisie en d´etail `a l’aide d’une chaˆıne de strat´egie. Mais dans le cas du repartitionnement, nous laissons Scotch construire la chaˆıne de strat´egie pour obtenir une partition ´equilibr´ee (SCOTCH_STRATBALANCE), de qualit´e (SCOTCH_STRATQUALITY) et adapt´ee au repartitionnement (SCOTCH_STRATREMAP). Scotch permet aussi de choisir l’importance relative de la coupe et de la migration. La valeur choisie pour ce param`etre est encore 1. Pour ´evaluer ces m´ethodes de repartitionnement, nous avons besoin de cr´eer des partitions initiales d´es´equilibr´ees. Les anciennes partitions utilis´ees dans les repartitionnements suivants sont cr´e´ees `a partir de partitions ´equilibr´ees dont le poids des sommets, valant initialement 1, est modifi´e pour simuler un raffinement du maillage. En parcourant les parties dans un ordre al´eatoire, la charge de la premi`ere partie n’est pas modifi´ee, la charge de la seconde est augment´ee d’une certaine quantit´e, celle de la troisi`eme de deux fois cette quantit´e, etc., la charge de la derni`ere partie augmente de M − 1 fois cette quantit´e. L’augmentation de la charge est choisie 1. Il est utilis´e ici pour partitionner des graphes. Un graphe n’est qu’un hypergraphe particulier ne poss´edant que des hyper-arˆetes de taille 2. La coupe connectivit´e − 1 ´equivalent `a la coupe du graphe pour les hyper-arˆetes de taille 2.5.1. METHODOLOGIE EXP ´ ERIMENTALE ´ 93 (a) Partition en 12 parties. (b) Modification du poids des sommets. Figure 5.1 – Exemple de d´es´equilibrage d’une partie en 12. de fa¸con `a ce que l’augmentation totale de la charge soient proportionnelle `a l’augmentation du nombre de ressources. Par exemple, en partant d’une ancienne partition ´equilibr´ee en M = 8 parties, si la charge totale augmente de 50 %, l’ancienne partition (poss´edant maintenant un d´es´equilibre de 33 %) est repartitionn´ee en N = 12 parties. Pour augmenter la charge d’une partie, des sommets sont choisies al´eatoirement pour avoir un poids plus ´elev´e. Pour chaque partie, ce nouveau poids est choisi pour ˆetre minimal. Par exemple, si la charge augmente mais sans doubler la charge de la partie, le nouveau poids sera 2 ; si la charge augmente plus que le double, il n’est plus possible d’atteindre la charge d´esir´ee, le nouveau poids est donc 3 voire plus. Dans une partie donn´ee, les poids des sommets sont alors 1 ou le nouveau poids choisi pour cette partie. Un exemple d’un tel d´es´equilibrage est pr´esent´e sur la figure 5.1. Une grille d’´el´ements carr´e est initialement partitionn´ee en 12 parties ´equilibr´ees (figure 5.1a). Les poids des sommets sont ensuite modifi´es comme indiqu´e sur la figure 5.1b : en noir, les sommets qui ont gard´e un poids de 1 ; en gris, les sommets qui ont un poids 2 ; et en blanc un poids 3. La densit´e des poids dans une mˆeme partie est `a peu pr`es uniforme. Mais la charge de chaque partie augmente d’une quantit´e diff´erente : de celle ne contenant que des sommets de poids 1 `a celle contenant les sommets de poids 3. Les exp´eriences suivantes sont r´ep´et´ees plusieurs fois : 10 fois pour toutes les exp´eriences sauf celles sur la complexit´e en temps (le nombre d’it´erations varie suivant le cas). A chaque ` repartitionnement le d´es´equilibre est diff´erent : l’ordre des parties utilis´e lors du d´es´equilibrage et les sommets dont les poids sont modifi´es sont tir´es al´eatoirement `a chaque fois mais la variation de la charge totale est toujours la mˆeme et identique `a la variation du nombre de processeurs.94 CHAPITRE 5. RESULTATS ´ 5.2 Influence du coˆut de migration et du facteur de repartitionnement Comme il a ´et´e dit dans le chapitre 4, il est important de bien choisir le poids des arˆetes de migration ajout´ees dans le graphe original. Comme les partitionneurs utilisent g´en´eralement des poids entiers pour les arˆetes, il n’est pas possible d’avoir un poids inf´erieur `a 1. Pour pouvoir appliqu´e un poids moins important aux arˆetes de migration, nous r´eutilisons la m´ethode utilis´ee par Zoltan : les poids de toutes les arˆetes du graphe original sont multipli´es par le facteur de repartitionnement (repart multiplier). Ainsi le poids des arˆetes de migration devient moins important relativement aux autres arˆetes. Dans cette section, nous ´etudions le comportement de notre m´ethode de repartitionnement M × N biais´ee en fonction du rapport du poids des arˆetes « normales » par rapport `a celui des arˆetes de migration repartmult migcost . Les exp´eriences pr´esent´ees dans cette section correspondent au repartitionnement d’une grille 3D 100 × 100 × 100 (1 000 000 sommets et 2 970 000 arˆetes, ce qui donne un degr´e moyen de 5, 94). Nous ´etudions le cas 8 × 10 o`u la charge augment de +25 % (le d´es´equilibre est 17 %). Quelque graphiques pour le cas 8 × 12 o`u la charge augment de +50 % (le d´es´equilibre est 33 %) sont pr´esent´ees dans l’annexe C.1. Les valeurs donn´ees sont les r´esultats moyens et les barres d’erreurs donnent les r´esultats minimums et maximums. Le coˆut de migration et le facteur de repartitionnement ne concerne que le partitionnement biais´e mais les valeurs moyennes de la strat´egie Scratch-Remap sont donn´ees comme rep`eres. Comme le repartitionnement biais´e impose le sch´ema de communication, un moyen simple de v´erifier son efficacit´e et de regarder les valeurs de TotalZ effectivement obtenues apr`es le repartitionnement. Les figures C.1 et 5.2 pr´esentent les valeurs de TotalZ dans deux cas de repartitionnement, respectivement 8 × 12 et 8 × 10. Comme il a d´ej`a ´et´e d´ecrit au chapitre 3, l’optimisation de la diagonale (GreedyD) cr´ee de trop grande hyper-arˆetes (une nouvelle partie re¸coit des sommets d’un trop grand nombre d’anciennes parties). On v´erifie ici que cela rend le partitionnement plus difficile : un coˆut de migration de 4 ne suffit plus `a imposer le sch´ema de communication pour cette strat´egie. On voit sur la figure 5.2 que TotalZ est minimis´e `a partir d’un coˆut de migration 4 fois sup´erieur pour la m´ethode BiasedGreedy. Ce seuil est un peu plus ´elev´e pour BiasedGreedyD. Un rapport repartmult migcost de 1 offre un nombre de message bas, sans ˆetre optimale alors qu’avec un facteur de repartitionnement plus important le nombre de messages augmente tr`es rapidement. Dans le cas du repartitionnement 8 × 12 (figure C.1), la strat´egie GreedyD cr´ee de moins grande hyper-arˆetes et la diff´erence entre biasedGreedy et BiasedGreedyD s’estompe. Le coˆut de migration et le facteur de repartitionnement permettent de param´etrer le compromis entre migration et coupe. En effet, la coupe, donn´ee sur la figure 5.3, est l´eg`erement plus basse avec un coˆut de migration faible et un facteur de repartitionnement important. Cette variation est plus marqu´ee avec la m´ethode BiasedGreedyD car le partitionnement est plus difficile. Cette diff´erence de coupe reste assez faible et devient mˆeme n´egligeable dans des cas plus favorable comme le repartitionnement 8 × 12 (figure C.2). Sur la figure 5.4, le volume total de migration TotalV ´evolue dans le sens contraire de la coupe : un coˆut de migration important minimise le volume de migration, alors qu’un facteur de repartitionnement plus important donne un volume ´equivalent au Scratch-Remap. La variation plus importante de la coupe avec la m´ethode BiasedGreedyD s’explique par son optimisation plus agressive de la migration. Contrairement `a la coupe, la variation de TotalV est bien plus importante. Le coˆut de migration et le facteur de repartitionnement influencent ´egalement le temps de partitionnement. La figure 5.5 montre que le temps de partitionnement augmente avec un coˆut5.2. COUT DE MIGRATION ET FACTEUR DE REPARTITIONNEMENT ˆ 95 15 20 25 30 35 40 45 50 1/64 1/16 1/4 1/1 4/1 16/1 64/1 TotalZ facteur de repartitionnement / cout de migration BiasedGreedy BiasedGreedyD Scratch-Remap Figure 5.2 – TotalZ 8 × 10 suivant repartmult/migcost. 40000 42000 44000 46000 48000 50000 52000 54000 56000 58000 1/64 1/16 1/4 1/1 4/1 16/1 64/1 Coupe facteur de repartitionnement / cout de migration BiasedGreedy BiasedGreedyD Scratch-Remap Figure 5.3 – Coupe 8 × 10 suivant repartmult/migcost.96 CHAPITRE 5. RESULTATS ´ 150000 200000 250000 300000 350000 400000 450000 500000 550000 600000 1/64 1/16 1/4 1/1 4/1 16/1 64/1 TotalV facteur de repartitionnement / cout de migration BiasedGreedy BiasedGreedyD Scratch-Remap Figure 5.4 – TotalV 8 × 10 suivant repartmult/migcost. 0 5 10 15 20 25 1/64 1/16 1/4 1/1 4/1 16/1 64/1 Temps (s) facteur de repartitionnement / cout de migration BiasedGreedy BiasedGreedyD Scratch-Remap Figure 5.5 – Temps 8 × 10 suivant repartmult/migcost.5.3. INFLUENCE DU NOUVEAU NOMBRE DE PROCESSEURS 97 de migration ou un facteur de repartitionnement plus important. Les poids plus important affect´es aux arˆetes ralentissent les algorithmes de partitionnement, en particulier, les algorithmes de raffinement de type FM, o`u il faut s´electionner un d´eplacement dans un intervalle de gain plus important. Il est donc n´ecessaire de choisir un coˆut de migration suffisamment ´elev´e pour obtenir une bonne migration mais sans le prendre plus haut que n´ecessaire pour ´eviter un ralentissement du partitionnement. Utiliser un facteur de repartitionnement important n’a pas d’int´erˆet : TotalZ et TotalV sont alors ´equivalents, au Scratch-Remap mais la coupe et le temps de repartitionnement sont plus importants. Dans les exp´eriences suivantes, le coˆut de migration utilis´e sera fix´e `a 10 pour un facteur de repartitionnement de 1. Cela permettra d’obtenir une bonne migration au prix d’une l´eg`ere augmentation du temps de partitionnement et de la coupe. 5.3 Influence du nouveau nombre de processeurs La prochaine s´erie d’exp´erience ´etudie l’influence du nouveau nombre de processeurs. Une grille 3D 100×100×100 est repartitionn´ee depuis 8 anciennes parties vers un nombre variable N de nouvelles parties. Dans chaque cas, la charge est augment´ee proportionnellement `a l’augmentation de ressources, soit N 8 . La figure 5.6 pr´esente la coupe obtenue pour les diff´erents repartitionneurs. La m´ethode Scratch-Remap offre la meilleure coupe comme on pouvait s’y attendre : c’est son seul objectif en dehors de l’´equilibrage. Nos m´ethodes de repartitionnement donnent une coupe un peu plus ´elev´ee que le Scratch-Remap mais globalement meilleure que ParMetis et Zoltan. En particulier, les m´ethodes BiasedGreedy et BiasedGreedyD donnent une bonne coupe comme celle du repartitionneur Scotch. Il est ´egalement int´eressant de remarquer que, bien que g´en´eralement tr`es proches, les m´ethodes BisaedGreedy et BiasedGreedyD donnent une coupe diff´erente pour les petites valeurs de N (8 × 9 et 8 × 10) : en effet, la m´ethode BiasedGreedyD donne de trop grandes hyper-arˆetes pour les petites variations du nombre de processeur ce qui rend le repartitionnement plus difficile et d´egrade en cons´equence la coupe pour cette m´ethode. Les m´ethodes diffusives (DiffTV et DiffMV) donnent une coupe plus ´elev´ee que nos m´ethodes biais´es mais meilleures que Zoltan et ParMetis. La diffusion est r´ealis´ee en une seule passe sans profiter d’un partitionnement multi-niveaux complet. La partition obtenue est donc de moins bonne qualit´e. Le volume total de migration TotalV est donn´e sur la figure 5.7. La m´ethode Scratch-Remap donne le volume de migration le plus ´elev´e mais celui-ci varie peu et il est asymptotiquement rejoint par les autres m´ethodes de repartitionnement quand N devient tr`es grand compar´e `a M = 8. La strat´egie BiasedGreedyD donne le meilleur volume de migration quelle que soit la valeur de N. Sa variante sans optimisation de la diagonale de la matrice de migration BiasedGreedy donne un TotalV plus ´elev´e, surtout quand N et M sont proches et donne mˆeme la plus importante migration (hors Scratch-Remap) dans le cas 8 × 9. La m´ethode diffusive DiffTV optimisant TotalV donne ´egalement un volume de migration tr`es bas. Il n’est pas toujours aussi bas que BiasedGreedyD `a cause du choix du graphe quotient augment´e limitant les possibilit´es de migration. La variante DiffMV optimisant MaxV donne un volume de migration total un peu plus ´elev´e, mais celui reste assez bas. Les autres partitionneurs, en particulier ParMetis et Scotch donnent aussi un volume de migration tr`es bas, alors que Zoltan se comporte un peu moins bien. La figure 5.8 donne le volume de migration maximal par partie MaxV. Plusieurs courbes98 CHAPITRE 5. R ´ESULTATS 30000 40000 50000 60000 70000 80000 90000 100000 8 10 12 14 16 18 20 22 24 26 28 Coupe Nouveau nombre de parties Scratch-Remap Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Figure 5.6 – Coupe suivant N pour un repartitionnement 8 × N.5.3. INFLUENCE DU NOUVEAU NOMBRE DE PROCESSEURS 99 100000 200000 300000 400000 500000 600000 700000 800000 8 10 12 14 16 18 20 22 24 26 28 TotalV Nouveau nombre de parties Scratch-Remap Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Figure 5.7 – TotalV suivant N pour un repartitionnement 8 × N.100 CHAPITRE 5. R ´ESULTATS 100000 200000 300000 400000 500000 600000 700000 800000 900000 8 10 12 14 16 18 20 22 24 26 28 MaxV Nouveau nombre de parties Scratch-Remap Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Figure 5.8 – MaxV suivant N pour un repartitionnement 8 × N.5.4. COMPARAISON SUR DES GRAPHES COMPLEXES 101 sont confondues et donnent le MaxV le plus bas : BiasedGreedy, BiasedGreedyD, DiffMV et ParMetis. Il apparait ici que MaxV est une m´etrique minimis´ee par ParMetis mais pas par les autres repartitionneurs Zoltan et Scotch. La strat´egie DiffTV donne un MaxV l´eg`erement plus ´elev´e. Il apparait que les m´etriques TotalV et MaxV ne peuvent pas ˆetre minimis´ees en mˆeme temps mais minimiser l’une suffit pour maintenir l’autre tr`es basse. Quand N est grand compar´e `a M, les valeurs optimales de MaxV augmentent lin´eairement `a la mˆeme vitesse que les pires (la strat´egie Scratch-Remap). La diff´erence relative devient donc moins importante quand N est tr`es grand. Les figures 5.9 et 5.10 montrent respectivement le nombre de messages total (TotalZ) et par partie (MaxZ). Le nombre de messages est une m´etrique qui n’est pas habituellement prise en compte par les repartitionneurs. Toutes nos m´ethodes donnent un nombre de messages tr`es bas alors que Zoltan et le Scratch-Remap donnent le nombre de message le plus ´elev´e. ParMetis et Scotch donnent des r´esultats interm´ediaires. Les m´ethodes BiasedGreedy et BiasedGreedyD donnent le TotalZ le plus bas. En effet ces m´ethodes essayent de minimiser ce crit`ere par construction `a l’aide de la recherche des sousensembles (cf. section 3.3.3). L’optimisation de la diagonale n’influe pas sur ce crit`ere. Bien que cette m´etrique n’est pas minimis´ee par la m´ethode DiffTV, la minimisation de TotalV semble ´egalement minimiser TotalZ dans la plupart des cas. Le nombre de messages pour DiffMV est plus ´elev´e mais reste inf´erieur aux m´ethodes classiques de repartitionnement. Le nombre maximal de messages par partie MaxZ fait apparaitre la diff´erence entre BiasedGreedy et BiasedGreedyD : quand N et M sont proches, BiasedGreedyD donne un plus grand nombre de messages par partie. En particulier, dans le cas 8 × 9, MaxZ devient tr`es ´elev´e pour BiasedGreedyD et d´epasse les repartitionneurs classiques. A partir du cas 8 ` × 15, les deux m´ethodes deviennent quasiment identiques. Nous avons vu que nos m´ethodes permettent une meilleure migration selon les m´etriques TotalV, MaxV, TotalZ et MaxZ mais avec une coupe l´eg`erement plus ´elev´ee. Le gain en terme de volume de migration se r´eduit quand N devient grand devant M mais la diff´erence de coupe reste la mˆeme. Nos m´ethodes sont donc plus int´eressantes quand l’´ecart entre l’ancien nombre de processeurs et le nouveau n’est pas trop grand. Malgr´e cela, nos m´ethodes de repartitionnement garde l’avantage d’un faible nombre de messages dans tous les cas. La diff´erence entre les deux variantes de notre repartitionnement biais´e BiasedGreedy et BiasedGreedyD se r´eduit avec l’augmentation du nombre de nouvelles parties : sauf lorsque la variation du nombre de processeurs est tr`es petite, ces m´ethodes sont quasiment identiques. 5.4 Comparaison sur des graphes complexes Pour valider nos approches de repartitionnement, nous pr´esentons dans cette section, des r´esultats obtenus pour des graphes issus d’applications vari´ees. Ces graphes, pr´esent´es dans le tableau 5.1, sont disponibles dans la collection de matrice creuse de l’universit´e de Floride [13], `a l’exception de grid3d100 qui est une grille cubique r´eguli`ere de 100 × 100 × 100. Les mesures des diff´erentes m´etriques sont donn´ees relativement au Scratch-Remap. On ´etudie plus particuli`erement le cas 8×12, la charge de la partition initiale a ´et´e augment´ee de 50 %, ce qui donne un d´es´equilibre de 33 %. Les r´esultats dans le cas du repartitionnement 8×10 (augmentation de la charge de 25 % et d´es´equilibre de 17 %)sont disponibles dans l’annexe C.2. La figure 5.11 donne les coupes obtenues avec les diff´erents repartitionneurs relativement `a celle du Scratch-Remap. Les repartitionneurs classiques, Zoltan, ParMetis et Scotch, donnent une coupe g´en´eralement l´eg`erement sup´erieure `a celle du Scratch-Remap, parfois ´egale. Dans le cas de102 CHAPITRE 5. R ´ESULTATS 10 20 30 40 50 60 70 80 90 8 10 12 14 16 18 20 22 24 26 28 TotalZ Nouveau nombre de parties Scratch-Remap Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Figure 5.9 – TotalZ suivant N pour un repartitionnement 8 × N.5.4. COMPARAISON SUR DES GRAPHES COMPLEXES 103 0 5 10 15 20 25 8 10 12 14 16 18 20 22 24 26 28 MaxZ Nouveau nombre de parties Scratch-Remap Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Figure 5.10 – MaxZ suivant N pour un repartitionnement 8 × N.104 CHAPITRE 5. R ´ESULTATS 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave Coupe Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure 5.11 – Coupe relative au Scratch-Remap pour un repartitionnement 8 × 12.5.4. COMPARAISON SUR DES GRAPHES COMPLEXES 105 Graphe Description |V | |E| d grid3d100 Grille 3D r´eguli`ere 1 000 000 2 970 000 5,94 cfd2 M´ecanique des fluides num´eriques (CFD) 123 440 1 482 229 24,02 crankseg 2 Probl`eme structurel 63 838 7 042 510 220,64 thermal2 Probl`eme thermique 1 228 045 3 676 134 5,99 brack2 Probl`eme 2D/3D 62 631 366 559 11,71 wave Probl`eme 2D/3D 156 317 1 059 331 13,55 cage12 Electrophor`ese d’ADN ´ 130 228 951 154 14,61 Table 5.1 – Description des graphes utilis´es pour nos exp´eriences. Le degr´e moyen d est calcul´e `a l’aide de la formule 2×|E| |V | . thermal2, Zoltan ne trouve pas de bonne partition. Les strat´egies BiasedGreedy et BiasedGreedyD donnent une coupe comparable `a ces partitionneurs classiques. Les m´ethodes diffusives (DiffTV et DiffMV ), ne profitant pas d’un partitionneur multi-niveaux complet, donnent une coupe souvent plus ´elev´ee. Comme on peut le voir sur la figure 5.12, toutes nos m´ethodes donnent un nombre de messages TotalZ bien inf´erieur aux autres repartitionneurs. Les deux strat´egies Greedy donnent un TotalZ `a peu pr`es ´equivalent et l´eg`erement inf´erieur aux m´ethode diffusives. Bien que cette m´etrique ne soit pas minimis´ee par les programmes lin´eaires utilis´es, le TotalZ obtenu est bas. C’est un effet de bord de la minimisation de TotalV ou MaxV par le programme lin´eaire : en minimisant le volume de migration, beaucoup de communications possibles, d’apr`es le graphe quotient enrichi choisi Q˜, sont de volume nul. Le petit nombre d’arˆetes ajout´ees dans Q˜ pour les nouvelles parties favorise ´egalement un nombre de messages bas. Pour le graphe crankseg 2, on remarque que le nombre de messages pour les strat´egies biais´ees est anormalement ´elev´e. Le partitionneur n’a pas trouv´e de partition respectant le sch´ema de communication impos´e par les sommets fixes. Malgr´e l’utilisation d’un algorithme de partitionnement k-aire direct, les heuristiques utilis´ees ne permettent pas toujours de trouver une bonne solution. Cette ´echec est sˆurement dˆu au degr´e ´elev´e de ce graphe qui rend le partitionnement plus difficile. Les m´ethodes diffusives appliquent strictement la matrice de migration et n’ont pas ce probl`eme. Seule la coupe peut ˆetre d´egrad´ee avec ces m´ethodes diffusives, si l’heuristique choisissant les sommets `a migrer fonctionne mal. Les volumes totaux de migrations TotalV sont pr´esent´es sur la figure 5.13. A l’exception de ` crankseg 2 pour lequel les m´ethodes biais´ees ´echouent, BiasedGreedyD donne toujours le volume de migration total le plus bas et aussi le plus stable (d’apr`es les barres d’erreur). Comme on l’a d´ej`a vu, DiffTV est contraint par le graphe quotient enrichi utilis´e et ne peut pas autant r´eduire le volume de migration que BiasedGreedyD. Concernant MaxV (figure 5.14), la comparaison entre DiffTV et DiffMV est invers´ee par rapport `a TotalV. Les minimisations de TotalV et de MaxV ne sont pas li´ees. Minimiser l’un ne suffit pas `a avoir l’autre minimal. Les deux m´ethodes Greedy donnent ´egalement un MaxV tr`es bas. Parmi les autres repartitionneurs, seul ParMetis semble minimiser ce crit`ere. Zoltan, Scotch et le Scratch-Remap donnent des volumes de migrations par partie (MaxV) beaucoup plus ´elev´es. Toutes nos m´ethodes de repartitionnement donnent un nombre de messages par partie (MaxZ) plus faible que les autres repartitionneurs (figure 5.15). La m´ethode BiasedGreedy donne g´en´eralement les meilleurs MaxZ bien que les heuristiques peuvent mal fonctionner dans certains cas (cage12 et crankseg 2). La m´ethode BiasedGreedyD donne un MaxZ l´eg`erement plus ´elev´e que BiasedGreedy : dans le cas 8 × 12, les anciens et nouveaux nombres de parties ne sont pas106 CHAPITRE 5. R ´ESULTATS 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave TotalZ Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure 5.12 – TotalZ relatif au Scratch-Remap pour un repartitionnement 8 × 12.5.4. COMPARAISON SUR DES GRAPHES COMPLEXES 107 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave TotalV Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure 5.13 – TotalV relatif au Scratch-Remap pour un repartitionnement 8 × 12.108 CHAPITRE 5. R ´ESULTATS 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave MaxV Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure 5.14 – MaxV relatif au Scratch-Remap pour un repartitionnement 8 × 12.5.4. COMPARAISON SUR DES GRAPHES COMPLEXES 109 0 0.2 0.4 0.6 0.8 1 1.2 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave MaxZ Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure 5.15 – MaxZ relatif au Scratch-Remap pour un repartitionnement 8 × 12.110 CHAPITRE 5. RESULTATS ´ trop proches. La distinction entre BiasedGreedy et BiasedGreedyD est plus significative quand le nombre de parties change peu, par exemple dans le cas 8×10 (figure C.7). Les m´ethodes DiffTV et DiffMV ont ´egalement un MaxZ bas. En effet, MaxZ est limit´e par le degr´e du graphe quotient enrichi utilis´e par le programme lin´eaire et celui-ci est construit de fa¸con `a garder un degr´e faible (au plus 3 arˆetes pour chaque partie ajout´ee). Le cas 8×10 pr´esent´e dans l’annexe C.2, donne des r´esultats similaires mais la diff´erence entre BiasedGreedy et BiasedGreedyD est plus marqu´e par rapport aux crit`eres TotalV et MaxZ. Les r´esultats dans le cas 8 × 10 sont assez similaires mais avec une diff´erence plus marqu´ee entre BiasedGreedy et BiasedGreedyD sur les crit`eres TotalV et MaxV. Ces exp´eriences valident nos algorithmes de repartitionnement M × N sur des graphes complexes pour une augmentation de charge de 50 % (8 × 12) ou de 25 % (8 × 10). Nos m´ethodes sont capables de mieux optimiser les diff´erentes m´etriques li´ees `a la migration (TotalV, MaxV, TotalZ et MaxZ) que les autre repartitionneurs, en obtenant une coupe l´eg`erement sup´erieure `a une m´ethode Scratch-Remap et comparable aux autres repartitionneurs. Les m´ethodes utilisant le partitionnement biais´e donnent les meilleurs r´esultats mais manquent de fiabilit´e. Le partitionnement est biais´e pour pr´ef´erer appliquer une matrice de migration donn´ee mais les heuristiques de partitionnement peuvent faire des mauvais choix (par exemple dans le cas de crankseg 2. Les m´ethodes diffusives sont plus fiables : la matrice de migration est strictement appliqu´ee mais les r´esultats sont de moins bonne qualit´e. La migration peut ˆetre mal optimis´ee `a cause d’un mauvais choix du graphe quotient enrichi. De plus, notre mise en œuvre rudimentaire de repartitionnement diffusif ne profite pas d’une approche multi-niveaux et se fait en une seule passe ; la coupe n’est donc pas tr`es bien minimis´ee. 5.5 Etude de la complexit´e en temps ´ Dans cette section, nous ´etudions le temps d’ex´ecution du partitionnement biais´e et des repartitionneurs classiques. Les m´ethodes diffusives ne sont pas ´evalu´es car leur mise en œuvre actuelle n’est que pr´eliminaire 2 . Les deux param`etres importants conditionnant la complexit´e du repartitionnement sont la taille du graphe (|V | et |E|) et le nombre de parties finales (N). Pour ´etudier l’influence du nombre de parties (figure 5.16), nous repartitionnons la grille 3D 100×100×100 dans le cas M ×N avec M et N variables mais en gardant le rapport N/M = 3/2 fixe. Alors que la m´ethode de Scratch-Remap et les autres repartitionneurs ont une complexit´e en temps logarithmique par rapport au nombre de parties grˆace `a la m´ethode des bissections r´ecursives, notre partitionnement biais´e est tr`es rapidement ralenti avec l’augmentation du nombre de parties. Lorsque le nombre de parties est petit, le temps d’ex´ecution de notre partitionnement biais´e est l´eg`erement sup´erieur au repartitionneur de Scotch mais suit la mˆeme progression. Notre partitionnement biais´e et le repartitionnement de Scotch se basent sur le mˆeme partitionneur (ils utilisent les mˆemes algorithmes de contraction et de raffinement du graphe) mais notre 2. En effet, l’heuristique de type FM utilis´ee pour migrer le sommets de chaque message, ne profite pas d’une approche multi-niveaux et chaque message est trait´ee comme un partitionnement complet.5.5. ETUDE DE LA COMPLEXIT ´ E EN TEMPS ´ 111 0 10 20 30 40 50 60 70 80 90 100 0 20 40 60 80 100 120 140 Temps (s) N Scratch-Remap Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD Figure 5.16 – Temps d’ex´ecution du repartitionnement M × N suivant le nouveau nombre de parties N avec M = 23N.112 CHAPITRE 5. RESULTATS ´ partitionnement biais´e utilise un graphe enrichi qui poss`ede plus d’arˆetes (chaque message ajoute autant d’arˆetes qu’il y a de sommets dans une ancienne partie). Quand le nombre de parties est plus important, le partitionnement biais´e ralentit beaucoup plus rapidement. Le KGGGP utilis´e en tant que partitionnement initial dans l’algorithme multiniveaux devient pr´edominant par rapport aux phases de contraction et d’expansion, `a cause de sa complexit´e lin´eaire par rapport au nombre de parties (cf. section 4.2.3). Dans une seconde exp´erience, nous g´en´erons des grilles 3D cubiques de tailles variables qui sont repartitionn´ees dans le cas 8×12. La figure 5.17 donne les temps d’ex´ecution en fonction du nombre de sommets |V | qui est `a peu pr`es proportionnel au nombre d’arˆetes |E| (il y a environ 3 arˆetes pour chaque sommet). Comme les autres m´ethodes, notre partitionnement biais´e a une complexit´e en temps lin´eaire par rapport `a la taille du graphe.5.5. ETUDE DE LA COMPLEXIT ´ E EN TEMPS ´ 113 0 5 10 15 20 0 500000 1e+06 1.5e+06 2e+06 Temps (s) |V| Scratch-Remap Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD Figure 5.17 – Temps d’ex´ecution du repartitionnement 8 × 12 suivant la taille du graphe (|V |).114 CHAPITRE 5. RESULTATS ´Chapitre 6 Conclusion et Perspectives 6.1 Conclusion Nous avons pr´esent´e dans cette th`ese plusieurs m´ethodes de r´e´equilibrage dynamique avec un nombre variable de processeurs, bas´ees sur le repartitionnement de graphe. Les objectifs de ce repartitionnement sont de r´e´equilibrer la partition et de minimiser la coupe tout en optimisant la migration caract´eris´ee par les m´etriques TotalV (le volume total de migration), MaxV (le volume maximal de migration par partie), TotalZ (le nombre total de messages) et MaxZ (le nombre maximal de messages par partie). Notre m´ethode se d´ecompose en deux grandes ´etapes : d’abord une matrice de migration est construite pour optimiser les diff´erentes m´etriques de migration ; puis un algorithme de repartitionnement calcule une nouvelle partition du graphe en prenant en compte la matrice de migration pr´ec´edemment construite. Une ´etude th´eorique du repartitionnement dans le cas o`u l’ancienne partition est ´equilibr´ee nous a permis de trouver les valeurs optimales pour TotalV et TotalZ. Plusieurs algorithmes ont ´et´e pr´esent´es pour essayer de construire des matrices de migration optimales. Les m´ethodes 1D, Matching, Greedy et GreedyD permettent d’obtenir une nombre de messages TotalZ quasi optimal. De plus, les m´ethodes Matching et GreedyD minimisent TotalV mais au coˆut d’un MaxZ parfois tr`es ´elev´e. Les m´ethodes 1D et Greedy gardent un MaxZ faible, mais donnent un TotalV l´eg`erement plus ´elev´e. La m´ethode Matching n’est utilisable que dans le cas ´equilibr´e ou quasiment ´equilibr´e, ce qui limite son int´erˆet en pratique. Nous avons ´egalement pr´esent´e un programme lin´eaire (PL) permettant d’optimiser une des diff´erentes m´etriques TotalV, MaxV, TotalZ ou MaxZ, ou combinaison lin´eaire de celles-ci, ´etant donn´e un graphe quotient enrichi indiquant les messages autoris´es. Un mauvais choix du graphe quotient enrichi limite la qualit´e des r´esultats de cette m´ethode. Nous avons ensuite propos´e deux m´ethodes de repartitionnement de graphe (Biased et Diff ) se basant sur une matrice de migration construite `a l’´etape pr´ec´edente. Le partitionnement biais´e utilisant des sommets fixes permet d’obtenir une nouvelle partition de qualit´e offrant une bonne coupe mais rend le partitionnement plus difficile et donc plus lent. Cette m´ethode a aussi l’inconv´enient de n´ecessiter une nombre de message TotalZ minimal. On pr´ef´erera donc l’utiliser conjointement avec les m´ethodes de construction de matrice minimisant cette m´etrique. Le partitionnement diffusif permet d’appliquer strictement une matrice de migration quel que soit son nombre de messages. Mais notre mise œuvre pr´eliminaire n’utilise qu’une passe sans 115116 CHAPITRE 6. CONCLUSION ET PERSPECTIVES multi-niveaux et donne par cons´equent une coupe plus ´elev´ee. Nous avons aussi montr´e qu’il est possible de mod´eliser le nombre de messages TotalZ et le volume de migration total TotalV `a l’aide de la coupe d’un hypergraphe enrichi. Il est ainsi possible de repartitionner sans calculer une matrice de migration `a l’avance. Mais l’hypergraphe ainsi cr´e´e est tr`es complexe et tr`es difficile `a partitionner avec les outils actuels. Dans le cadre de notre m´ethode de partitionnement biais´e, nous avons mis en ´evidence des limitations du partitionnement bas´e sur les bissections r´ecursives. Nous avons donc r´ealis´e une m´ethode de partitionnement k-aire direct int´egr´ee dans le partitionneur Scotch. Cette m´ethode de KGGGP (k-way greedy graph growing partitioning) permet de mieux appliquer notre m´ethode de partitionnement biais´e mais poss`ede une complexit´e par rapport au nombre de parties plus importante que les m´ethodes de bissections r´ecursives. Les m´ethodes de repartitionnement biais´e et diffusif ont ´et´e ´evalu´ees par une suite d’exp´eriences. Nous avons vu que ces approches sont plus int´eressantes quand le nombre de processeurs varie peu. Quand le nombre de processeurs varie beaucoup, une m´ethode Scratch-Remap donne un volume de migration ´equivalent mais une meilleure coupe, tout en ´etant plus simple `a r´ealiser. N´eanmoins, mˆeme dans ce cas, nos m´ethodes permettent d’obtenir un nombre de messages bien plus faible. Nous avons valid´e ces m´ethodes sur une s´erie de graphes complexes issus d’applications r´eelles. Le partitionnement biais´e offre de bons r´esultats mais il ralentit rapidement avec l’augmentation du nombre de parties. Les r´esultats obtenus `a l’aide du partitionnement diffusif sont encourageants mais laissent place `a des am´eliorations. L’´etat de la mise en œuvre du partitionnement diffusif ne nous permet pas actuellement de conclure sur sa rapidit´e d’ex´ecution. La mise en œuvre de ces algorithmes et les modifications apport´ees `a Scotch pour le KGGGP sont int´egr´ees dans la biblioth`eque LBC2 [16] dont le code source est disponible `a l’adresse : https://gforge.inria.fr/frs/download.php/33277/lbc2-r1844.tar.gz. 6.2 Perspectives En vue d’am´eliorer les diff´erents algorithmes pr´esent´es dans cette th`ese, plusieurs pistes sont envisag´ees. Nous avons vu que la qualit´e de la matrice de migration obtenue par le programme lin´eaire est limit´ee par le choix du graphe quotient enrichi. Un meilleur algorithme d’enrichissement du graphe quotient devrait ˆetre d´evelopp´e pour pouvoir effectivement atteindre des volumes de migration minimaux. De plus, l’algorithme pr´esent´e dans cette th`ese ne permet pas de traiter le cas o`u le nombre de processeurs diminue. Le programme lin´eaire construisant la matrice de migration permet de minimiser une combinaison lin´eaire des m´etriques de migration. Cet objectif m´elange des m´etriques de natures tr`es diff´erentes. La recherche des coefficients permettant d’obtenir un bon compromis est un probl`eme complexe qui m´eriterait d’ˆetre ´etudi´e. Pour am´eliorer `a la fois la qualit´e de la coupe et le temps d’ex´ecution de notre m´ethode diffusive, il faudrait utiliser celle-ci avec une approche multi-niveaux. Ce repartitionnement serait alors une m´ethode hybride utilisant un algorithme de local matching [58] pour la phase de contraction (permettant ainsi de garder l’information de l’ancienne partition sur le graphe contract´e), le partitionnement diffusif lors du partitionnement initial, puis une m´ethode de raffinement biais´e lors de l’expansion.6.2. PERSPECTIVES 117 Le principal probl`eme de notre m´ethode de partitionnement biais´e est son temps d’ex´ecution. Celui-ci est principalement dˆu `a notre partitionnement KGGGP en O(k|E|). Pour r´eduire sa complexit´e, il faudrait ne pas consid´erer pour chaque sommet tous les d´eplacements vers les k parties, mais par exemple seulement vers les parties voisines ou en s’inspirant de certaines m´ethodes de raffinement k-aire ayant une bonne complexit´e en O(|E|) [35]. Une autre cause de ralentissement du partitionnement biais´e est l’ajout d’un grand nombre d’arˆetes. Une solution serait l’utilisation d’arˆetes virtuelles : au lieu d’ajouter des sommets fixes et des arˆetes de migration, les heuristiques de partitionnement sont modifi´ees pour prendre directement en compte le repartitionnement M × N. C’est, par exemple, l’approche d´ej`a utilis´ee dans Scotch [18]. Pour pouvoir appliquer ces m´ethodes dans le cadre d’applications r´eelles, il serait n´ecessaire de rendre nos algorithmes parall`eles. Pour parall´eliser le repartitionnement, il est possible de r´eutiliser les partitionneurs parall`eles (PT-Scotch, Zoltan, ParMetis, ...). Pour parall´eliser la m´ethode KGGGP, comme celle-ci est utilis´ee sur un petit graphe contract´e grˆace au multi-niveaux, une m´ethode na¨ıve serait de profiter de l’al´eatoire pour calculer des partitions diff´erentes sur chaque processeur, puis de diffuser la meilleure partition obtenue [9, 50]. Le repartitionnement M × N pourrait aussi trouver une application dans l’optimisation des communications entre des codes coupl´es. Actuellement chaque code est partitionn´e ind´ependamment de l’autre alors que les processeurs des diff´erents codes communiquent r´eguli`erement entre eux. Pour optimiser ces communications, il faudrait utiliser une m´ethode de co-partitionnement. Une approche consisterait `a commencer par partitionner l’un des codes, puis de partitionner le second code en prenant en compte la partition de l’autre (comme dans un repartitionnement). Dans ce contexte, il n’est pas n´ecessaire de minimiser le volume total de migration TotalV, car toutes les donn´ees de couplage sont syst´ematiquement ´echang´ees lors de cette ´etape. En revanche, il est toujours possible d’optimiser le nombre de messages (TotalZ ou MaxZ) ainsi que la taille de chacun (MaxV).118 CHAPITRE 6. CONCLUSION ET PERSPECTIVESAnnexe A Programmes lin´eaires pour optimiser les diff´erentes m´etriques Dans chaque programme, les entr´ees sont : — la variation de charge di id´eale pour chaque processeur i (la diff´erence entre la nouvelle charge ´equilibr´ee pour la partition en N parties et l’ancienne charge dans la partition d´es´equilibr´ee en M parties) ; — une tol´erance au d´es´equilibre ub qui correspond `a la surcharge maximale autoris´ee. On cherche `a calculer les valeurs optimales des eij qui est la quantit´e de donn´ees envoy´ees du processeur i vers le processeurs j. A.1 Minimisation de TotalV minimiser X i,j eij Contraintes lin´eaires : ∀i ∈ V, vi = X j (eji − eij ) Bornes : ∀i ∈ V, vi ≤ di + ub ∀(i, j) ∈ E, 0 ≤ eij 119120 ANNEXE A. PROGRAMMES LINEAIRES ´ A.2 Minimisation de MaxV minimiser v Contraintes lin´eaires : ∀i ∈ V, vi = X j (eji − eij ) ∀i ∈ V, v′ i = X j (eji + eij ) − v Bornes : ∀i ∈ V, vi ≤ di + ub ∀i ∈ V, v′ i ≤ 0 ∀(i, j) ∈ E, 0 ≤ eij 0 ≤ v A.3 Minimisation de TotalZ xij et eij entiers. minimiser X ij xij Contraintes lin´eaires : ∀i ∈ V, vi = X j (eji − eij ) ∀(i, j) ∈ E, aij = eij − xij ∀(i, j) ∈ E, bij = eij − W xij Bornes : ∀i ∈ V, vi ≤ di + ub ∀i ∈ V, 0 ≤ aij ∀i ∈ V, bij ≤ 0 ∀(i, j) ∈ E, 0 ≤ eij ∀(i, j) ∈ E, 0 ≤ xij≤ 1A.4. MINIMISATION DE MAXZ 121 A.4 Minimisation de MaxZ xij et eij entiers. minimiser z Contraintes lin´eaires : ∀i ∈ V, vi = X j (eji − eji) ∀(i, j) ∈ E, aij = eij − xij ∀(i, j) ∈ E, bij = eij − W xij ∀i ∈ V, zi = X j (xij + xji) − z Bornes : ∀i ∈ V, vi ≤ di + ub ∀i ∈ V, 0 ≤ aij ∀i ∈ V, bij ≤ 0 ∀i ∈ V, zi ≤ 0 ∀(i, j) ∈ E, 0 ≤ eij ∀(i, j) ∈ E, 0 ≤ xij≤ 1 0 ≤ z122 ANNEXE A. PROGRAMMES LINEAIRES ´Annexe B Documentation du KGGGP dans Scotch Notre m´ethode de partitionnement KGGGP a ´et´e r´ealis´ee en modifiant Scotch 6.0. Cette m´ethode est indiqu´ee dans les chaˆınes de strat´egie par la lettre g. Cette strat´egie accepte les param`etres suivants : — bal indique la tol´erance au d´es´equilibre utilis´ee. La valeur par d´efaut est 0.05 (5 %). — type indique le crit`ere de s´election utilis´e. Les valeurs accept´ees sont : — g pour le gain de coupe (par d´efaut) ; — d pour le crit`ere diff. — seed indique le type de graines `a utiliser : — n pour n’utiliser aucune graine (par d´efaut) ; — r pour utiliser des graines al´eatoire ; — o pour utiliser des graines ´eloign´ees. Les graines r et o ne sont pas compatibles avec le partitionnement `a sommets fixes. — pass indique le nombre de passes `a effectuer. La meilleure partition est retenue. — center indique s’il faut utiliser les centres des parties comme graines `a la passe suivante. Les valeurs possibles sont y pour les utiliser ou n pour ne pas les utiliser (par d´efaut). Si les centres sont utilis´es comme graines, le type de graine donn´e par seed n’est utilis´e que pour la premi`ere passe. — ref donne la strat´egie de raffinement `a appliquer apr`es chaque passe. Aucune strat´egie de raffinement n’est utilis´ee par d´efaut. Plus de d´etails sur les chaˆınes de strat´egies en g´en´eral peuvent ˆetre trouv´es dans le manuel de Scotch 6.0 [51]. 123124 ANNEXE B. DOCUMENTATION DU KGGGP DANS SCOTCHAnnexe C R´esultats suppl´ementaires C.1 Influence du coˆut de migration et du facteur de repartitionnement 15 20 25 30 35 40 45 50 55 1/64 1/16 1/4 1/1 4/1 16/1 64/1 TotalZ facteur de repartitionnement / cout de migration BiasedGreedy BiasedGreedyD Scratch-Remap Figure C.1 – TotalZ 8 × 12 suivant repartmult/migcost. 125126 ANNEXE C. RESULTATS SUPPL ´ EMENTAIRES ´ 44000 46000 48000 50000 52000 54000 56000 58000 60000 1/64 1/16 1/4 1/1 4/1 16/1 64/1 Coupe facteur de repartitionnement / cout de migration BiasedGreedy BiasedGreedyD Scratch-Remap Figure C.2 – Coupe 8 × 12 suivant repartmult/migcost. C.2 Comparaison sur des graphes complexesC.2. COMPARAISON SUR DES GRAPHES COMPLEXES 127 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave Coupe Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure C.3 – Coupe relative au Scratch-Remap pour un repartitionnement 8 × 10128 ANNEXE C. R ´ESULTATS SUPPL ´EMENTAIRES 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave TotalV Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure C.4 – TotalV relatif au Scratch-Remap pour un repartitionnement 8 × 10C.2. COMPARAISON SUR DES GRAPHES COMPLEXES 129 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave TotalZ Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure C.5 – TotalZ relatif au Scratch-Remap pour un repartitionnement 8 × 10130 ANNEXE C. R ´ESULTATS SUPPL ´EMENTAIRES 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave MaxV Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure C.6 – MaxV relatif au Scratch-Remap pour un repartitionnement 8 × 10C.2. COMPARAISON SUR DES GRAPHES COMPLEXES 131 0 0.2 0.4 0.6 0.8 1 1.2 1.4 brack2cage12cfd2 crankseg_2 grid3d100 thermal2wave MaxZ Zoltan Parmetis Scotch BiasedGreedy BiasedGreedyD DiffTV DiffMV Scratch-Remap Figure C.7 – MaxZ relatif au Scratch-Remap pour un repartitionnement 8 × 10132 ANNEXE C. RESULTATS SUPPL ´ EMENTAIRES ´Bibliographie [1] Zoltan : Parallel partitioning, load balancing and data-management services. http://www. cs.sandia.gov/Zoltan/Zoltan.html. [2] Cevdet Aykanat, B. Barla Cambazoglu, Ferit Findik et Tahsin Kurc : Adaptive decomposition and remapping algorithms for object-space-parallel direct volume rendering of unstructured grids. J. Parallel Distrib. Comput., 67:77–99, janvier 2007. [3] Cevdet Aykanat, B. Barla Cambazoglu et Bora U¸car : Multi-level direct k-way hypergraph partitioning with multiple constraints and fixed vertices. J. Parallel Distrib. Comput., 68:609–625, mai 2008. [4] Stephen T Barnard et Horst D Simon : Fast multilevel implementation of recursive spectral bisection for partitioning unstructured problems. Concurrency : Practice and Experience, 6(2):101–117, 1994. [5] Roberto Battiti et Alan Bertossi : Differential greedy for the 0-1 equicut problem. In in Proceedings of the DIMACS Workshop on Network Design : Connectivity and Facilities Location, pages 3–21. American Mathematical Society, 1997. [6] Roberto Battiti et Alan Bertossi : Greedy, prohibition, and reactive heuristics for graph partitioning. IEEE Transactions on Computers, 48:361–385, 1998. [7] Andrew E Caldwell, Andrew B Kahng et Igor L Markov : Hypergraph partitioning with fixed vertices. In Proceedings of the 36th annual ACM/IEEE Design Automation Conference, pages 355–359. ACM, 1999. [8] U. V. ¸Catalyurek ¨ , E. G. Boman, K. D. Devine, D. Bozdag˘, R. Heaphy, et L. A. Fisk : Hypergraph-based dynamic load balancing for adaptive scientific computations. Proceedings of 21st International Parallel and Distributed Processing Sympsosium (IPDPS), 2007. [9] Umit V. ¸Catalyurek ¨ , Erik G. Boman, Karen D. Devine, Doruk Bozdag˘, Robert T. Heaphy et Lee Ann Riesen : A repartitioning hypergraph model for dynamic load balancing. J. Parallel Distrib. Comput., 69(8):711–724, 2009. [10] C´edric Chevalier et Fran¸cois Pellegrini : Improvement of the efficiency of genetic algorithms for scalable parallel graph partitioning in a multi-level framework. In Euro-Par 2006 Parallel Processing, volume 4128, pages 243–252, Dresden, septembre 2006. Springer. [11] Jr. Ciarlet, P. et F. Lamour : On the validity of a front-oriented approach to partitioning large sparse graphs with a connectivity constraint. Numerical Algorithms, 12(1):193–214, 1996. [12] G. Cybenko : Dynamic load balancing for distributed memory multiprocessors. Journal of Parallel and Distributed Computing, 7(2):279–301, octobre 1989. [13] Timothy A. Davis et Yifan Hu : The university of Florida sparse matrix collection. ACM Trans. Math. Softw., 38(1):1 :1–1 :25, d´ecembre 2011. 133134 BIBLIOGRAPHIE [14] Ralf Diekmann, Robert Preis, Frank Schlimbach et Chris Walshaw : Shape-optimized mesh partitioning and load balancing for parallel adaptive FEM. Parallel Computing, 26(12): 1555–1581, 2000. [15] Olivier Duchenne, Francis R. Bach, In-So Kweon et Jean Ponce : A tensor-based algorithm for high-order graph matching. In CVPR, pages 1980–1987. IEEE, 2009. [16] Aur´elien Esnard et Cl´ement Vuchener : Library for Balancing Code Coupling. http: //gforge.inria.fr/projects/mpicpl/. [17] C. M. Fiduccia et R. M. Mattheyses : A linear-time heuristic for improving network partitions. 19th Design Automation Conference, pages 175–181, 1982. [18] S´ebastien Fourestier : Redistribution dynamique parall`ele efficace de la charge pour les probl`emes num´eriques de tr`es grande taille. Th`ese de doctorat, Universit´e Bordeaux 1, juin 2013. [19] S´ebastien Fourestier et Fran¸cois Pellegrini : Adaptation au repartitionnement de graphes d’une m´ethode d’optimisation globale par diffusion. In Proc. RenPar’20, SaintMalo, France, mai 2011. [20] Michael R. Garey et David S. Johnson : Computers and Intractibility : A Guide to the Theory of NP-Completeness. W. H. Freeman, 1979. [21] Norman E. Gibbs, William G. Poole, Jr. et Paul K. Stockmeyer : An algorithm for reducing the bandwidth and profile of a sparse matrix. SIAM Journal on Numerical Analysis, 13(2):236–250, 1976. [22] B. Hendrickson et R. Leland : A multilevel algorithm for partitioning graphs. In Proceedings of 1995 ACM/IEEE conference on Supercomputing, 1995. [23] Bruce Hendrickson, Robert W. Leland et Rafael Van Driessche : Skewed graph partitioning. In Eighth SIAM Conf. Parallel Processing for Scientific Computing, 1997. [24] Bruce Hendrickson et Tobert Leland : Chaco : Software for partitioning graphs. http: //www.sandia.gov/~bahendr/chaco.html. [25] Roger A. Horn et Charles R. Johnson : Matrix Analysis. Cambridge University Press, 1985. [26] Y. F. Hu et R. J. Blake : An optimal dynamic load balancing algorithm. Rapport technique, Daresbury Laboratory, 1995. [27] Saeed Iqbal et Graham F. Carey : Performance analysis of dynamic load balancing algorithms with variable number of processors. Journal of Parallel and Distributed Computing, 65(8):934 – 948, 2005. [28] Saeed Iqbal et Graham F. Carey : Performance of parallel computations with dynamic processor allocation. Engineering with Computers, 24:135–143, 2008. [29] Sachin Jain, Chaitanya Swamy et K. Balaji : Greedy algorithms for k-way graph partitioning. In the 6th international conference on advanced computing, 1998. [30] George Karypis : hMETIS. http://glaros.dtc.umn.edu/gkhome/metis/hmetis/ overview. [31] George Karypis : METIS. http://glaros.dtc.umn.edu/gkhome/metis/metis/ overview. [32] George Karypis : PARMETIS. http://glaros.dtc.umn.edu/gkhome/metis/parmetis/ overview.135 [33] George Karypis, Rajat Aggarwal, Vipin Kumar et Shashi Shekhar : Multilevel hypergraph partitioning : Applications in VLSI domain. IEEE Transactions on VLSI Systems, 7(1):69–79, 1999. [34] George Karypis et Vipin Kumar : A fast and high quality multilevel scheme for partitioning irregular graphs. In International Conference on Parallel Processing, pages 113–122, 1995. [35] George Karypis et Vipin Kumar : Multilevel k-way partitioning scheme for irregular graphs. Journal of Parallel and Distributed Computing, 48:96–129, 1998. [36] George Karypis et Vipin Kumar : A fast and high quality multilevel scheme for partitioning irregular graphs. SIAM Journal on Scientific Computing, 20(1), 1999. [37] George Karypis et Vipin Kumar : Parallel multilevel k-way partitioning scheme for irregular graphs. SIAM Review, 41(2):278–300, 1999. [38] George Karypis et Vipin Kumar : Multilevel k-way hypergraph partitioning. VLSI Design, 11(3):285–300, 2000. [39] B. W. Kernighan et S. Lin : An efficient heuristic procedure for partitioning graphs. Bell System Technical Journal, 49:291–307, f´evrier 1970. [40] Scott Kirkpatrick, C. D. Gelatt et Mario P. Vecchi : Optimization by simmulated annealing. science, 220(4598):671–680, mai 1983. [41] Marius Leordeanu et Martial Hebert : A spectral technique for correspondence problems using pairwise constraints. In Proceedings of the Tenth IEEE International Conference on Computer Vision - Volume 2, ICCV ’05, pages 1482–1489, Washington, DC, USA, 2005. IEEE Computer Society. [42] Henning Meyerhenke, Burkhard Monien et Stefan Schamberger : Graph partitioning and disturbed diffusion. Parallel Comput., 35(10-11):544–569, octobre 2009. [43] Katta G. Murty : Linear programming. John Wiley & Sons, 1983. [44] Leonid Oliker et Rupak Biswas : Efficient load balancing and data remapping for adaptive grid calculations. In 9th ACM Symposium on Parallel Algorithms and Architectures, pages 33–42, 1997. [45] Leonid Oliker et Rupak Biswas : PLUM : parallel load balancing for adaptive unstructured meshes. J. Parallel Distrib. Comput., 52:150–177, aoˆut 1998. [46] Chao-Wei Ou et Sanjay Ranka : Parallel incremental graph partitioning using linear programming. In Proceedings Supercomputing ’94, pages 458–467, 1994. [47] David A. Papa et Igor L. Markov : Hypergraph partitioning and clustering. In In Approximation Algorithms and Metaheuristics, 2007. [48] Fran¸cois Pellegrini : SCOTCH. http://www.labri.fr/perso/pelegrin/scotch/. [49] Fran¸cois Pellegrini : A parallelisable multi-level banded diffusion scheme for computing balanced partitions with smooth boundaries. In T. Priol A.-M. Kermarrec, L. Boug´e, ´editeur : Euro-Par 2007 Parallel Processing, volume 4641 de Lecture Notes in Computer Science, pages 195–204, Rennes, France, aoˆut 2007. Springer. [50] Fran¸cois Pellegrini : PT-Scotch and libPTScotch 6.0 user’s guide, 2012. [51] Fran¸cois Pellegrini : Scotch and libScotch 6.0 user’s guide, 2012. [52] J.R. Pilkington et S.B. Baden : Dynamic partitioning of non-uniform structured workloads with spacefilling curves. Parallel and Distributed Systems, IEEE Transactions on, 7(3):288 –300, mars 1996.136 BIBLIOGRAPHIE [53] Alex Pothen, Horst D. Simon et Kan-Pu Liou : Partitioning sparse matrices with eigenvectors of graphs. SIAM J. Matrix Anal. Appl., 11(3):430–452, mai 1990. [54] Hans Sagan : Space-Filling Curves. Springer-Verlag, 1994. [55] Kirk Schloegel, George Karypis et Vipin Kumar : Multilevel diffusion schemes for repartitioning of adaptive meshes. Journal of Parallel and Distributed Computing, 47(2):109 – 124, 1997. [56] Kirk Schloegel, George Karypis et Vipin Kumar : Parallel multilevel diffusion algorithms for repartitioning of adaptive meshes. Rapport technique, University of Minnesota, Department of Computer Science and Army HPC Center, 1997. [57] Kirk Schloegel, George Karypis et Vipin Kumar : A unified algorithm for load-balancing adaptive scientific simulations. In Proceedings of the 2000 ACM/IEEE conference on Supercomputing (CDROM), Supercomputing ’00, Washington, DC, USA, 2000. IEEE Computer Society. [58] Kirk Schloegel, George Karypis et Vipin Kumar : Wavefront diffusion and LMSR : Algorithms for dynamic repartitioning of adaptive meshes. IEEE Trans. Parallel Distrib. Syst., 12(5):451–466, mai 2001. [59] Daniel G Schweikert et Brian W Kernighan : A proper model for the partitioning of electrical circuits. In Proceedings of the 9th Design Automation Workshop, pages 57–62. ACM, 1972. [60] Horst D. Simon et Shang-Hua Teng : How good is recursive bisection ? SIAM J. Sci. Comput, 18:1436–1445, 1995. [61] Aleksandar Trifunovic et William J. Knottenbelt : Parkway 2.0 : A parallel multilevel hypergraph partitioning tool. In in Proc. 19th International Symposium on Computer and Information Sciences, pages 789–800. Springer, 2004. [62] Brendan Vastenhouw et Rob H. Bisseling : A two-dimensional data distribution method for parallel sparse matrix-vector multiplication. SIAM Review, 47(1):67–95, 2005. [63] Umit V. ¸Catalyurek ¨ et Cevdet Aykanat : Hypergraph-partitioning based decomposition for parallel sparse-matrix vector multiplication. IEEE Transactions on Parallel and Distributed Systems, 10(7):673–693, juillet 1999. [64] Umit ¨ V. ¸Catalyurek ¨ et C. Aykanat : PaToH : A Multilevel Hypergraph Partitioning Tool. http://bmi.osu.edu/~umit/software.html#patoh, 1999.Liste des publications [65] Cl´ement Vuchener et Aur´elien Esnard : Repartitionnement d’un graphe de M vers N processeurs : application pour l’´equilibrage dynamique de charge. In 20`eme Rencontres francophones du parall´elisme (RenPar’20), page 8, Saint-Malo, France, 2011. [66] Cl´ement Vuchener et Aur´elien Esnard : Dynamic Load-Balancing with Variable Number of Processors based on Graph Repartitioning. In Proceedings of High Performance Computing (HiPC 2012), pages 1–9, Pune, Inde, 2012. 9 pages. [67] Cl´ement Vuchener et Aur´elien Esnard : Equilibrage dynamique avec nombre variable ´ de processeurs par une m´ethode de repartitionnement de graphe. Technique et Science Informatiques (TSI), 31(8-9-10/2012):1251–1271, juin 2012. [68] Cl´ement Vuchener et Aur´elien Esnard : Graph Repartitioning with both Dynamic Load and Dynamic Processor Allocation. In International Conference on Parallel Computing - ParCo2013, Advances of Parallel Computing, Munchen, Allemagne, 2013. ¨ 137 Addition formulae on hyperelliptic curves : applications to cryptography Christophe Tran To cite this version: Christophe Tran. Addition formulae on hyperelliptic curves : applications to cryptography. Cryptography and Security. Universit´e de Rennes 1, 2014. French. HAL Id: tel-01096316 https://tel.archives-ouvertes.fr/tel-01096316 Submitted on 17 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.N o d’ordre : 00000 ANNÉE 2014 THÈSE / UNIVERSITÉ DE RENNES 1 sous le sceau de l’Université Européenne de Bretagne pour le grade de DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention : Mathématiques et applications École doctorale Matisse présentée par Christophe TRAN préparée à l’unité de recherche 6625 CNRS - IRMAR Institut de Recherche de Mathématiques de Rennes U.F.R. de Mathématiques Formules d’addition sur les jacobiennes de courbes hyperelliptiques : applications à la cryptographie Thèse soutenue à Rennes le 1er décembre 2014 devant le jury composé de : David KOHEL Professeur, Université d’Aix-Marseille / Rapporteur Pierrick GAUDRY Directeur de recherche, CNRS / Rapporteur Christophe RITZENTHALER Professeur, Université de Rennes 1 / Examinateur David LUBICZ Ingénieur, DGA-MI / Examinateur Damien ROBERT Chargé de recherche, INRIA Bordeaux / Examinateur Sylvain DUQUESNE Professeur, Université de Rennes 1 / Directeur de thèseRemerciements A tous : Salut, merci, et bonne lecture. 12 RemerciementsTable des matières Introduction 7 0.1 Histoire des courbes elliptiques . . . . . . . . . . . . . . . . . . . 7 0.1.1 Le début de l’histoire avec Diophante . . . . . . . . . . . . 7 0.1.2 Ellipses et intégrales elliptiques . . . . . . . . . . . . . . . 8 0.1.3 Des intégrales aux fonctions elliptiques . . . . . . . . . . . 9 0.1.4 Des fonctions aux courbes elliptiques . . . . . . . . . . . . 10 0.2 Les courbes elliptiques en cryptographie . . . . . . . . . . . . . . 11 0.3 Quatre articles à la genèse d’une thèse en deux parties . . . . . . 13 0.4 Résumé du document . . . . . . . . . . . . . . . . . . . . . . . . . 15 Notations 17 1 Préliminaires 19 1.1 Arithmétique des courbes . . . . . . . . . . . . . . . . . . . . . . 19 1.2 Couplages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.2.2 Exemples d’utilisation . . . . . . . . . . . . . . . . . . . . 23 1.2.2.1 Le protocole de Joux [25] . . . . . . . . . . . . . 24 1.2.2.2 Le chiffrement de Boneh et Franklin [6] . . . . . . 24 1.2.2.3 La signature courte de Boneh Lynn et Shacham [7] 25 1.2.3 Le couplage de Tate . . . . . . . . . . . . . . . . . . . . . 25 1.2.4 Une variante : le couplage ate . . . . . . . . . . . . . . . . 27 1.3 Fonctions thêta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.3.1 Le cas elliptique . . . . . . . . . . . . . . . . . . . . . . . . 28 1.3.1.1 Définition et premières propriétés . . . . . . . . . 28 1.3.1.2 Arithmétique des fonctions thêta . . . . . . . . . 31 1.3.2 Fonctions thêta en tout genre . . . . . . . . . . . . . . . . 35 1.4 La théorie des hyperelliptic nets . . . . . . . . . . . . . . . . . . . 39 1.4.1 Le cas elliptique . . . . . . . . . . . . . . . . . . . . . . . . 39 1.4.2 Le cas hyperelliptique . . . . . . . . . . . . . . . . . . . . 41 34 Table des matières 2 Deux méthodes de calculs de couplages 43 2.1 Couplages et fonctions thêta . . . . . . . . . . . . . . . . . . . . . 43 2.2 Couplages et nets . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.2.1 Le cas g ≡ 1, 2 (mod 4) . . . . . . . . . . . . . . . . . . . 46 2.2.2 Le cas g ≡ 0, 3 (mod 4) . . . . . . . . . . . . . . . . . . . 51 2.2.3 Un exemple en genre 3 . . . . . . . . . . . . . . . . . . . . 53 2.2.4 Analyse théorique de coûts . . . . . . . . . . . . . . . . . . 55 2.3 Résultats en genre 1 . . . . . . . . . . . . . . . . . . . . . . . . . 57 3 Unification de ces deux méthodes 59 3.1 Réécriture des elliptic nets . . . . . . . . . . . . . . . . . . . . . . 59 3.2 Fonctions de niveau 2 et elliptic nets . . . . . . . . . . . . . . . . 61 3.3 Fonctions de niveau l (pair) et elliptic nets . . . . . . . . . . . . . 63 3.4 Fonctions de niveau l (toujours pair) et hypelliptic nets . . . . . . 64 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4 Polynômes de sommation 67 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2 Rappels sur les travaux de Gaudry et Semaev . . . . . . . . . . . 68 4.2.1 Cadre général : le calcul d’index . . . . . . . . . . . . . . . 68 4.2.2 L’algorithme dans le cas des courbes elliptiques et hyperelliptiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2.3 Polynômes de Semaev . . . . . . . . . . . . . . . . . . . . 70 4.3 Nouvelle construction des polynômes de sommation en genre 1 . . 71 4.3.1 Deux théorèmes fondamentaux . . . . . . . . . . . . . . . 71 4.3.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4 Extension aux courbes hyperelliptiques . . . . . . . . . . . . . . . 78 4.4.1 Enoncé des deux théorèmes pour tout genre . . . . . . . . 79 4.4.2 Polynômes de sommation hyperelliptiques . . . . . . . . . 81 4.4.3 Utilisation pour le calcul d’index . . . . . . . . . . . . . . 84 4.4.4 Un exemple en genre 2 . . . . . . . . . . . . . . . . . . . . 85 4.4.5 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.5 Constructions alternatives . . . . . . . . . . . . . . . . . . . . . . 88 4.5.1 Peut-on utiliser moins de fonctions ∆n,g ? . . . . . . . . . . 89 4.5.2 Cas elliptique : peut on utiliser un autre automorphisme que [−1] ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.5.2.1 Quels automorphismes ? . . . . . . . . . . . . . . 91 4.5.2.2 Le cas j = 1728 . . . . . . . . . . . . . . . . . . . 92 4.5.2.3 Le cas j = 0 . . . . . . . . . . . . . . . . . . . . . 95 4.5.2.4 Théorème final avant de passer au cas hyperelliptique . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.5.3 Le cas général . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.5.4 Analyse et comparaisons . . . . . . . . . . . . . . . . . . . 105Table des matières 5 4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Bibliographie 1076 Table des matièresIntroduction Cette thèse s’intéresse aux courbes elliptiques et hyperelliptiques et à leur utilisation en cryptographie. Je rappellerai donc dans cette introduction leurs places dans l’histoire des mathématiques, avant de les resituer dans un contexte cryptographique. Ceci fait, j’évoquerai les principaux articles qui m’ont poussé à choisir mes axes de recherche. Enfin, je donnerai un plan détaillé de ce document. 0.1 Histoire des courbes elliptiques 0.1.1 Le début de l’histoire avec Diophante Les courbes elliptiques sont de vieux objets d’étude mathématique. Outre la géométrie algébrique d’où elles proviennent, ces courbes apparaissent aussi bien en théorie des nombres qu’en analyse. On verra dans cette thèse quelques applications de leur loi de groupe en cryptographie, mais on peut noter qu’elles interviennent également en mécanique des fluides, science des matériaux ou électrostatique. Pour résumer la riche histoire de ces courbes, je me suis basé sur [24], [46], [8], [40]. La première apparition de ces courbes se trouve dans l’oeuvre la plus importante du mathématicien grec du IIIième siècle Diophante : les Arithmétiques. Cette somme en 13 livres ne sera "redécouverte" en occident qu’après la chute de Constantinople. Après plus de 1000 ans d’absence, cet ouvrage influencera énormément les savants de la Renaissance et du siècle des Lumières, faisant par exemple réfléchir Newton ou Euler. Fermat travailla beaucoup sur les problèmes posés par Diophante : c’est d’ailleurs dans une traduction latine de ces Arithmétiques que Fermat livrera en annotations son fameux dernier théorème. Mais n’allons pas trop vite, et revenons à Diophante. Diophante étudia à la Bibliothèque d’Alexandrie les mathématiques de son époque : géométrie, trigonométrie, mécanique. Il s’intéressa à trouver des méthodes de construction (aujourd’hui on dirait des algorithmes) de solutions rationnelles à des équations algébriques à plusieurs variables. 78 INTRODUCTION C’est dans ce cadre qu’il inventa, sans le savoir, la méthode "corde-et-tangente" pour l’addition sur une courbe. Pour comprendre ce coup de force, prenons d’abord l’exemple des équations quadratiques. C’est un problème bien plus vieux que Diophante : les babyloniens par exemple connaissaient déjà les triplets pythagoriciens 1 . Diophante fit pourtant une découverte importante : Proposition 0.1.1. Soit f(x, y) ∈ Q[x, y] un polynôme quadratique. Si l’équation f(x, y) = 0 admet au moins une solution rationnelle, alors elle en admet une infinité. En effet, si on note P cette solution initiale, alors toute droite de pente rationnelle coupe la courbe d’équation f(x, y) = 0 en une autre solution rationnelle. Diophante appliqua cette même méthode aux cubiques. Plus précisément, le problème 24 du livre IV de ses Arithmétiques se réécrit de façon moderne ainsi : Étant donné un paramètre a, trouver les solutions rationnelles à l’équation y(a − y) = x 3 − x. Diophante traite le cas a = 6 en faisant le changement de variable x = 3y − 1 : autrement dit, Diophante a regardé l’intersection entre la courbe et sa tangente au point (−1, 0). C’est bien la méthode de doublement d’un point sur une courbe elliptique. Par la suite, il faudra attendre le XVIIième siècle pour que Fermat donne en toute généralité les formules algébriques pour l’addition et le doublement ; puis ce sera Newton qui donnera l’interprétation géométrique (corde-et-tangente) de ces formules. 0.1.2 Ellipses et intégrales elliptiques La seconde partie de l’histoire débute au XVIIième avec Wallis (qui le premier parla d’intégrales elliptiques) pour finir au XIXième siècle avec Jacobi, Abel, Weierstrass et Eisenstein. Commençons par introduire la définition suivante : Définition 0.1.2. Soit R ∈ C(x, y) une fonction rationnelle et f ∈ C[t] sans facteur carré. La différentielle R(t, q f(t))dt est dite hyperelliptique. Elle est dite elliptique si f est de degré 3 ou 4. 1. Pythagore vécut au VIième siècle av. JC, les Babyloniens environ 3000 ans avant cela.Histoire des courbes elliptiques 9 Ces quantités apparaissent naturellement dans les problèmes de rectification d’une courbe, c’est-à-dire de calcul de longueur d’arc. Ainsi, si y = f(x) est une courbe C 1 sur un intervalle [a, b], alors la longueur d’arc est donnée par la formule L b a = Z b a q 1 + f 0 (x) 2dx. On comprend maintenant pourquoi Wallis parla d’intégrales elliptiques : il voulait dire par là intégrales dont le calcul permet de calculer la longueur d’arc d’une ellipse. Voyons rapidement leur histoire. Au bout de 40 ans de travail, Legendre publia entre 1825 et 1828 un traité en trois volumes 2 dans lequel il conclut notamment que toute intégrale provenant de la rectification d’une ellipse peut s’exprimer comme une des trois types suivants, qu’il appela naturellement intégrales elliptiques de première, seconde et troisième espèce : F(x) = Z x 0 dt q (1 − t 2 )(1 − k 2 t 2 ) , G(x) = Z x 0 (1 − k 2x 2 )dt q (1 − t 2 )(1 − k 2 t 2 ) , Π(x) = Z x 0 dt (1 + nx2 ) q (1 − t 2 )(1 − k 2 t 2 ) . 0.1.3 Des intégrales aux fonctions elliptiques Par la suite, Abel réalisa que plutôt que d’essayer de calculer ces intégrales, par exemple u = F(x), il était bien plus intéressant de regarder les fonctions inverses : x = f(u). Cette idée provient de la trigonométrie : ainsi, si la fonction x 7→ Z x 0 dt √ 1 − t 2 est importante, son inverse, la fonction sinus, est elle fondamentale. Il appela ainsi fonctions elliptiques les inverses des intégrales elliptiques. Jacobi partit de cette idée et trouva le résultat suivant : Théorème 0.1.3. Aucune fonction méromorphe ne peut avoir plus de deux pé- riodes indépendantes. Les fonctions méromorphes doublement périodiques sont exactement les fonctions elliptiques. 2. Traité des fonctions elliptiques et intégrales Eulériennes.10 INTRODUCTION C’est bien là la définition moderne des fonctions elliptiques, celle que l’on retrouve dans le livre de Silverman [42] par exemple. Il ne reste qu’une dernière étape pour retrouver nos courbes elliptiques. 0.1.4 Des fonctions aux courbes elliptiques Utilisant cette double périodicité, Eisenstein décrivit les fonctions elliptiques comme des séries entières : Théorème 0.1.4. La série suivante y(z) = X∞ m,n=−∞ (z + mω1 + nω2) −2 − X∞ m,n=−∞ (mω1 + nω2) −2 où ω1, ω2 ∈ C et ω1/ω2 ∈/ R définit une fonction elliptique. Elle vérifie une équation différentielle de la forme y 0 (z) 2 = p(y(z)), pour un polynôme p de degré 3 sans facteur carré. Finalement, en 1863, Weierstrass introduisit sa fameuse fonction ℘ : ℘(z) = z −2 + X∞ m,n=−∞ (m,n)6=(0,0) [(z + mω1 + nω2) −2 − (mω1 + nω2) −2 ]. Théorème 0.1.5. Toute fonction elliptique de double période ω1 et ω2 est une fonction rationnelle en ℘ et ℘ 0 . Ces deux fonctions vérifient l’équation ℘ 0 (z) 2 = 4℘(z) 3 − g2℘(z) − g3, où g2 et g3 sont des constantes ne dépendant que de ω1 et ω2. Ces courbes cubiques, on les a déjà rencontrées avec Diophante et Fermat. Newton avait montré la méthode corde-et-tangente d’addition de points. Et Weierstrass montra qu’effectivement ses fonctions ℘ et ℘ 0 admettaient bien une formule d’addition qui est celle des points de la courbe. Ainsi, ces courbes cubiques paramétrées par les fonctions elliptiques prirent elles le nom de courbes elliptiques. La boucle est bouclée.Les courbes elliptiques en cryptographie 11 0.2 Les courbes elliptiques en cryptographie En 1976, Diffie et Hellman inventèrent la cryptographie à clef publique. Encore appelée cryptographie asymétrique, elle repose sur l’existence supposée de fonctions à sens unique, qui permettent de chiffrer facilement des messages, mais dont le calcul de l’inverse doit être impossible pour qui ne connaît pas le secret. On peut grosso modo diviser les protocoles de cryptographie asymétrique en deux familles. Le très célèbre RSA, inventé en 1977, fut la première réalisation pratique à clef publique. Le protocole commence par la multiplication de deux grands nombres premiers, et repose sur la difficulté, connaissant seulement le résultat du produit, de retrouver les deux facteurs. Les protocoles de la seconde famille reposent sur le problème suivant, dit du logarithme discret : me donnant un groupe (G, ×) et deux éléments g et g 0 de ce groupe reliés par la relation g 0 = g x , comment puis je retrouver x ? Il est par exemple à la base du protocole d’échange de clefs Diffie-Hellman (1976) ou du chiffrement Elgamal (1989). Dans les implémentations originales de ces protocoles, le groupe utilisé est le groupe multiplicatif d’un corps fini F ∗ p , pour un grand premier p. En 1985, Koblitz et Miller proposèrent tous deux de façon indépendante d’utiliser un autre groupe : celui des points d’une courbe elliptique définie sur un corps fini. La raison à cela est l’absence d’algorithme en temps sous-exponentiel pour attaquer le problème du logarithme discret sur ces groupes (plus de détails sont donnés dans le chapitre 4). Ainsi, à niveau de sécurité égal, la taille du groupe de points d’une courbe elliptique à utiliser est plus petite que celle du groupe multiplicatif d’un corps fini. En pratique, cela signifie de plus petites tailles de clefs et de messages chiffrés échangés. Ces avantages sont particulièrement significatifs dans le domaine des systèmes embarqués qui sont très restreints en capacité de mémoire et de borne passante. Comme rappelé dans [26], la cryptographie basée sur courbes elliptiques 3 divisa d’abord les cryptographes : du fait de son exotisme (les courbes elliptiques étant alors peu connues et peu étudiées par les cryptographes), elle suscita chez certains enthousiasme et curiosité, et chez d’autres scepticisme et méfiance. Ces derniers arguèrent que les problèmes de la factorisation et du logarithme discret sur corps finis avaient été à ce moment là déjà intensivement étudiés, et qu’il faudrait at- 3. en anglais, ECC pour elliptic curve cryptography.12 INTRODUCTION tendre un certain temps avant que la communauté cryptographique s’empare et comprenne vraiment la nature des courbes elliptiques. Ainsi, ECDSA (Elliptic Curve Digital Signature Algorithm), proposé en 1992 ([51]), ne fut finalement unanimement accepté et inclus dans les standards que presque 10 ans plus tard (en 2000 par la NSA : [37]). Finalement, juste quand l’utilisation des courbes elliptiques en cryptographie fut bien acceptée, apparurent les premiers protocoles basés sur les couplages 4 . Vieil outil mathématique, le couplage de Weil n’était pas à ce moment là inconnu des cryptographes, puisque Menezes, Okamoto et Vanstone dans [32] en 1993 avaient déjà montré comment transporter le problème du logarithme discret des points d’une courbe elliptique vers un groupe F ∗ q k (ici k est le degré de plongement, notion définie dans le chapitre 1). Cet article avait d’ailleurs à l’époque jeté un peu plus la suspicion sur les courbes elliptiques, notamment celles de petit degré de plongement. Ces nouveaux protocoles ([25], [6] et [7], présentés plus en détail au chapitre 1) marquèrent les esprits en répondant de façon simple et élégante à de vieilles questions cryptographiques. Ainsi, les schémas d’échange de clef Diffie-Helman étaient bien connus et étudiés avant Joux ([25]), mais ils nécessitaient tous plus d’un tour d’échanges de données. Quant au chiffrement basé sur l’identité, c’est une vielle question posée par Shamir en 1984 à laquelle Boneh et Franklin ([6]) répondirent pour la première fois. Ces articles ouvrirent une décennie de recherches actives sur les couplages : constructions de nouvelles primitives cryptographiques, impossibles sans l’utilisation de couplages, nouvelles techniques pour accélérer le calcul de couplages, nouvelles méthodes de sélections de courbes adaptées aux couplages (au passage, les courbes admettant un petit degré de plongement furent à cette occasion ré- habilitées)... En 1989, soit quelques années seulement après l’introduction des courbes elliptiques en cryptographie, Koblitz suggéra pour la première fois dans [27] d’utiliser leurs généralisations aux genres plus élevés : les courbes hyperelliptiques. Contrairement à la situation dans le cas elliptique, l’ensemble des points de ces courbes ne forme pas un groupe. Par contre, on peut toujours associer à chacune de ces courbes un groupe algébrique : sa jacobienne (la définition précise, et plus de détails seront donnés dans le chapitre 1). L’intérêt de considérer ces nouveaux groupes réside dans leur cardinal : en effet, une courbe hyperelliptique de genre g définie sur un corps fini Fq admet une jacobienne de cardinal environ q g . Ainsi, utiliser une courbe de grand genre permet, à niveau de sécurité comparable, de travailler sur des corps finis plus petits, et ainsi de diminuer la taille des clefs et 4. pairing en anglais.Quatre articles à la genèse d’une thèse en deux parties 13 des messages chiffrés. Pour savoir si un groupe est utilisable en cryptographie, un critère majeur à considérer est l’efficacité de sa représentation et de son arithmétique. Et malheureusement, pendant longtemps, les courbes hyperelliptiques futrent considérées comme inutilisables en cryptographie en pratique à cause de la grande difficulté de leur arithmétique (voir par exemple [44]). Le premier algorithme pour calculer dans la jacobienne d’une courbe hyperelliptique fut proposé par Cantor ([11]). Comme on le verra dans le chapitre 1, cet algorithme repose sur la représentation dite de Mumford des éléments de la jacobienne. Des améliorations de cet algorithme furent progressivement obtenus en étudiant les formules explicites pour un genre fixé (voir par exemple [29] pour le cas g = 2). Dans [21], Gaudry utilisa les fonctions thêta au lieu de la représentation de Mumford pour donner un algorithme très compétitif pour calculer sur les jacobiennes des courbes de genre 2. Il nous faut maintenant évoquer la sécurité des courbes hyperelliptiques en cryptographie, c’est-à-dire la difficulté du problème du logarithme discret dans leur jacobienne. Pour résoudre ce problème, il y a deux familles d’algorithmes : les algorithmes dits génériques, parce qu’ils fonctionnent dans n’importe quel autre groupe, dont la complexité est exponentielle ; et les algorithmes de type calcul d’index, de complexité sous-exponentielle, qui exploitent l’arithmétique particulière des courbes hyperelliptiques. Le principe de ces algorithmes sera rappelé dans le chapitre 4. Ces algorithmes firent leur apparition pour la première fois en 1994 dans [1], mais n’étaient valables que quand le genre était suffisamment grand par rapport à la taille du corps de définition. Depuis, de nombreuses variantes et améliorations de ces algorithmes furent publiées : aujourd’hui, les algorithmes de type calcul d’index sont plus efficaces que les algorithmes génériques dès lors que le genre vaut au moins 3. Ainsi, aujourd’hui, comme le souligne [2], tant la sécurité que les performances arithmétiques des courbes hyperelliptiques de genre 2 en font une alternative solide aux courbes elliptiques. 0.3 Quatre articles à la genèse d’une thèse en deux parties Je venais tout juste de débuter ma thèse lorsque je trouvai deux articles ([45] et [30]) proposant deux nouvelles méthodes de calcul de couplages, originales car totalement indépendantes du traditionnel algorithme de Miller. Après une lecture même superficielle, une chose frappe très nettement : la similitude entre les formules de calcul de couplages introduites dans ces articles. Pourtant, ces14 INTRODUCTION deux travaux semblaient totalement déconnectés, et n’utilisaient pas les mêmes objets : alors que David Lubicz et Damien Robert parlent de fonctions thêta et de formules d’addition, Katherine Stange, elle, introduit des elliptic nets 5 , qu’elle inscrit très clairement dans la théorie des suites récurrentes, les reliant par exemple aux elliptic divisibility sequences. Trois mois plus tard, à l’heure de faire un premier bilan de mon travail, voilà où j’en étais arrivé : — En réalité, les fonctions thêta d’une courbe elliptique E ne sont pas des fonctions proprement définies sur E : on ne peut pas les évaluer individuellement sur un point P ∈ E, il faut ou bien effectuer un quotient de fonctions thêta pour obtenir une véritable fonction elliptique, ou bien considérer ensemble tout un paquet de fonctions thêta bien choisies (on parle alors de coordonnées thêta). Pour schématiser, la première méthode est utilisée dans [45], et la seconde dans [30]. — Les fonctions thêta d’une courbe elliptique vérifient toute une série de formules d’addition, dérivées des relations de Riemann, qui traduisent l’arithmétique de la courbe. Ce sont ces formules d’addition qui sont à la base de l’algorithme donné dans [30], qui permet par un double-and-add de calculer les coordonnées thêta d’un point Q + rP, pour un grand entier r. — La fonction σ de Weierstrass est une fonction thêta particulière, qui permet de construire tous les elliptic nets. Or, il se trouve que la relation de récurrence définissant les elliptic nets est une conséquence des formules d’addition vérifiées par cette fonction thêta. Quant aux autres fonctions thêta, ce sont presque des elliptic nets : elles vérifient une relation de récurrence assez similaire à celles des elliptic nets, mais un peu plus compliquée. Ceci explique la similitude relevée plus haut entre les formules de couplages données dans les deux articles [45] et [30]. — Une autre application des elliptic nets est mise en avant dans [41] : il s’agit d’attaquer le problème du logarithme discret sur une courbe elliptique. Plus précisément, il s’agit de décider quand un ensemble de n points P1, . . . , Pn d’une courbe vérifie une relation du type P1 ± · · · ± Pn = O. Ces relations se détectaient en pratique via les polynômes de Semaev ([43]) : le but de [41] est justement de relier elliptic nets et polynômes de Semaev. Ces notions se généralisent aux genres supérieurs : le travail de [30] concerne d’ailleurs les variétés abéliennes en toute généralité, tandis que [50], paru au 5. aucune traduction française de ce terme ne sera proposé dans ce document.Résumé du document 15 printemps 2012, généralise la notion d’elliptic nets aux courbes hyperelliptiques. Ainsi, en partant de ces quatre articles [30], [45], [50] et [41], j’avais mes deux thèmes de recherche pour ma thèse : travailler sur les couplages d’une part, et sur la recherche de relations pour les algorithmes de type calcul d’index attaquant le logarithme discret. 0.4 Résumé du document Cette thèse s’organise en quatre chapitres : un premier chapitre de rappels, et trois autres dans lesquels je donne mes résultats. Chapitre 1 Dans ce chapitre je rappelle les notions mathématiques nécessaires à la lecture du manuscrit. Je commence par donner la définition des courbes hyperelliptiques et de leur jacobienne, ainsi que la représentation de Mumford des diviseurs. Je rappelle ensuite la définition des fonctions de Miller, et leur utilisation pour le calcul de couplages. Enfin, je rappelle la théorie des fonctions thêta, et celle des elliptic (et hyperelliptic) nets. Chapitre 2 Ce chapitre traite de calcul de couplages. Après avoir rappelé la méthode de calcul de couplages via les fonctions thêta donnée dans [30], je donne l’algorithme basé sur [45] permettant de calculer les couplages sur une courbe hyperelliptique avec les hyperelliptic nets. Cet algorithme est le premier résultat neuf énoncé dans cette thèse. Il admet deux variantes, selon que le genre de la courbe vérifie g ≡ 1, 2 (mod 4) ou g ≡ 0, 3 (mod 4). Ces deux variantes sont énoncées respectivement dans les sections 2.2.1 et 2.2.2. Je donne une analyse des coûts de ces deux variantes dans la section 2.2.4. Enfin, ce chapitre se termine par une comparaison des coûts pour l’utilisation des elliptic nets et celle des fonctions thêta en genre 1 (section 2.3). Chapitre 3 Jusqu’à présent, les méthodes de calcul de couplages par les fonctions thêta ([30]) et par les nets ([45] et [50]) étaient traitées comme si elles étaient indépendantes. Le chapitre 3 est dédié à leur réunification. Je mets ainsi en évidence le fait que tout système de coordonnées de niveau l pair admet une loi d’addition (théorème 3.4.1), et que ces formules d’addition ont pour16 INTRODUCTION conséquence une relation de récurrence (théorème 3.4.2), que j’appelle ré- currence des hyperelliptic nets généralisés (en particulier, pour l = 2 on retombe sur la récurrence des hyperelliptic nets classiques). Chapitre 4 Dans ce chapitre, je passe à ma deuxième thématique de recherches : la recherche de relations dans l’algorithme de calcul d’index. Contrairement à [41], je ne réécris pas les polynômes de Semaev en fonction des elliptic nets, mais directement avec la fonction sigma de Weierstrass : je montre en effet que c’est bien la loi d’addition vérifiée par cette fonction qui lui permet de détecter des relations. Je construis ainsi des polynômes avec la fonction sigma dans le lemme 4.3.4 puis le théorème 4.3.5. Puis je montre que ces polynômes sont bien les polynômes de Semaev dans la proposition 4.3.8 et le corollaire 4.3.9. A partir de ce travail préparatoire en genre 1, je généralise la notion de polynômes de sommation aux genres supérieurs (théorème 4.4.7), ce qui n’avait pas été fait jusque là. J’étudie ensuite l’impact de ces nouveaux polynômes dans la complexité de l’algorithme de calcul d’index (section 4.4.5). Je termine le chapitre par la construction de polynômes de sommation alternatifs (section 4.5), toujours basés sur la fonction sigma et ses lois d’addition. En effet, ma construction originelle des polynômes de sommation était dictée par les choix et le travail de Semaev dans [43]. Il s’agit alors pour moi de discuter de la pertinence de ces choix. Hormis dans un cas particulier, ces polynômes alternatifs ne semblent pas être plus efficaces que les originaux.Notations Dans l’ensemble de cette thèse : — K est un corps, dont K dénote une clôture algébrique ; — Fq le corps fini à q éléments ; sa caractéristique sera notée p ; — E désignera toujours une courbe elliptique, C une courbe hyperelliptique et J la jacobienne d’une courbe ; — les courbes considérées seront toujours dans le modèle imaginaire (voir définition 1.1.1) ; ∞ désigne le point à l’infini de la courbe, et O l’élément neutre de J ; — si f : C → C0 est une application rationnelle non constante entre deux courbes définies sur un corps K, on note f ∗ : K(C 0 ) → K(C) son pullback défini par f ∗ (r 0 ) = r 0 ◦ f; — avec les mêmes notations, est également défini l’homomorphisme f ∗ : Div(C 0 ) → Div(C) (Q) 7→ X P ∈C f(P)=Q ef (P)(P), où ef (P) est l’index de ramification de f en P ; — un homomorphisme classique qui sera utilisé dans cette thèse est le morphisme de translation ; si P ∈ E est un point de la courbe elliptique E, alors τP : E → E est le morphisme défini par τP (Q) = P + Q; — a ∈R A signifie que l’on doit choisir un élément a uniformément aléatoirement dans l’ensemble fini A ; — {0, 1} ∗ désigne l’ensemble des chaînes de bits de longueur finie ; — pour un entier n et un point P ∈ E, la multiplication scalaire de n et P est notée [n]P : [n]P = P + P + · · · + P | {z } n ; 1718 Notations — pour un entier n, J [n] est la n-torsion de J , i.e. J [n] = {D ∈ J | [n]D = O}.Chapitre 1 Préliminaires Dans cette partie, je commencerai par rappeler des notions basiques sur l’arithmétique des courbes. Je consacrerai ensuite une section aux couplages, avant de rappeler les résultats de [30] sur le calcul de couplages via les fonctions thêta d’une part, et de [45] et [50] sur leur calcul par les (hyper)elliptic nets d’autre part. 1.1 Arithmétique des courbes Cette section est volontairement succincte. Plus de détails seront trouvés dans les références classiques que sont par exemple le chapitre 4 de [3], [18] ou les deux premiers chapitres de [42]. Définition 1.1.1. Une courbe hyperelliptique C de genre g sur un corps K est une courbe non singulière donnée par une équation du type C : y 2 + H(x)y = F(x), avec H et F ∈ K[x], 2g + 1 ≤ deg(F) ≤ 2g + 2, deg(H) ≤ g + 1. Je ne considérerai que les courbes hyperelliptiques imaginaires 1 , c’est à dire avec F de degré 2g + 1 et deg(H) ≤ g. Dans ce cas, C a un point à l’infini, noté ∞. Remarque 1.1.2. Si on travaille sur un corps de caractéristique différente de 2, via la transformation y 7→ y + H(x)/2, la courbe C donnée dans 1.1.1 est isomorphe à y 2 = F 0 (x) avec deg(F 0 ) = 2g + 1. 1. Plus précisément, les cryptographes ne considèrent généralement que les courbes imaginaires. La raison à cela est que l’arithmétique de ces courbes est plus rapide. 1920 Préliminaires À chacune de ces courbes, est associé un groupe abélien : sa jacobienne. Je commence par rappeler la notion de diviseur. Définition 1.1.3. Soit C/K une courbe hyperelliptique. Un diviseur D de C est une somme formelle finie de points de C : D = X Pi∈C ni(Pi), où les ni sont des entiers relatifs presque tous nuls. L’ensemble des diviseurs muni de la somme formelle de points est un groupe commutatif noté Div(C). Définition 1.1.4. Le degré d’un diviseur est la somme de ses coefficients : deg   X Pi∈C ni(Pi)   = Xni . L’ensemble des diviseurs de degré 0 forme un sous groupe Div0 (C) de Div(C). Parmi les diviseurs de degré zéro, on distingue les diviseurs principaux : Définition 1.1.5. Si f ∈ K(C), on lui associe un diviseur de degré 0 : div(f) = X PiC ordPi (f)(Pi). Un diviseur D de C est dit principal s’il existe une fonction f ∈ K(C) tel que D = div(f). L’ensemble P rinc(C) des diviseurs principaux forme un sous groupe de Div0 (C). Finalement, voici la jacobienne de C : Définition 1.1.6. La jacobienne J de C est le groupe des diviseurs de degré zéro quotienté par le groupe des diviseurs principaux : J = Div0 (C)/P rinc(C). L’élément neutre de J est noté O. Deux diviseurs D et D0 sont dits linéairement équivalents s’ils sont dans la même classe modulo P rinc(C). On note alors D ∼ D 0 .Arithmétique des courbes 21 Le théorème de Riemann Roch est un outil essentiel pour l’étude des courbes algébriques. Pour le moment, il va nous servir à énoncer la représentation de Mumford. Avant l’énoncé de ce théorème, il faut rappeler deux définitions. Définition 1.1.7. Un diviseur D est dit effectif si tous ses coefficients sont positifs. On note D ≥ 0. Plus généralement, pour deux diviseurs D et D0 , on note D ≥ D0 si le diviseur D − D0 est effectif. Définition 1.1.8. Soit D un diviseur de C. L’espace de Riemann Roch associé à D est l’espace vectoriel L(D) = {f ∈ K(C) ∗ | div(f) ≥ −D} ∪ {0}. C’est un K-espace vectoriel de dimension finie, sa dimension est notée l(D). Exemple 1.1.9 ([42]). — Si D < 0, alors L(D) = {0}. — Si D ∼ D0 , alors L(D) ' L(D0 ). Théorème 1.1.10 (Riemann-Roch). Il existe un diviseur KC de C appelé diviseur canonique tel que pour tout D ∈ Div(C), l(D) − l(KC − D) = deg(D) − g + 1. Si deg(D) > 2g − 2, alors l(D) = deg(D) − g + 1. Munis de ce théorème, nous avons le résultat suivant : Proposition 1.1.11. Toute classe D ∈ J admet un représentant unique de la forme D ∼ Xr i=1 (Pi) − r(∞) avec r ≤ g et pour tout i 6= j, Pi 6= −Pj . Définition 1.1.12. Une telle écriture de D est appelée forme réduite de D. Elle sera notée ρ(D). Corollaire 1.1.13. Tout D ∈ J se représente de façon unique par une paire de polynômes u, v ∈ K[x] tels que — u est unitaire ; — deg(v) < deg(u) ≤ g ; — u|v 2 + vh − f.22 Préliminaires En pratique, cela signifie que pour D ∼ Xr i=1 (Pi) − r(∞), où pour tout i, Pi = (xi , yi), on a — u(x) = Q i (x − xi) et — pour tout i, v(xi) = yi . Définition 1.1.14. Une telle paire de polynômes (u, v) est la représentation de Mumford de D. Dans [11], Cantor donne un algorithme prenant en entrée deux diviseurs réduits D1 et D2 pour donner en sortie la représentation réduite de D1 + D2. J’aurai besoin dans la suite de la notation suivante : Définition 1.1.15. Pour D = P Pi ni(Pi) ∈ J , on note (D) la partie effective de D, c’est-à-dire (D) = X Pi ni>0 ni(Pi). Exemple 1.1.16. Si D est réduit, alors D = Pr i=1(Pi) − r(∞) pour un r ≤ g, et alors on a simplement (D) = Xr i=1 (Pi). Enfin, un dernier objet à définir ici : le diviseur Θ. Définition 1.1.17. Le diviseur Θ ⊂ J est l’ensemble des diviseurs dont la forme réduite admet r < g points. Ainsi, J \Θ = {D ∼ (P1) + · · · + (Pg) − g(∞)|∀i 6= j, Pi 6= −Pj}. On note également pour i < g, les sous ensembles Θ [i] = {D ∼ X j k=1 (Pk) − r(∞) | j ≤ i}. On a donc {O} = Θ[0] ⊂ Θ [1] = {(P) − (∞)} ⊂ · · · ⊂ Θ = Θ[g−1] .Couplages 23 Exemple 1.1.18. Les courbes qu’on étudiera le plus ici sont les courbes elliptiques et les courbes hyperelliptiques de genre 2. Pour g = 1, on a Θ = {O}. Pour g = 2, Θ [1] = {O} ⊂ Θ = {(P) − (∞) | P ∈ C}, tandis que J \ Θ = {(P1) + (P2) − 2(∞) | P1 6= −P2}. 1.2 Couplages Je commence par rappeler ce qu’est un couplage 2 en cryptographie, et par donner quelques brefs exemples de protocoles les utilisant. J’expliquerai ensuite comment sont calculés ces couplages en pratique. Il existe plusieurs résumés récents de l’état de l’art sur les couplages, tel que [4] et [19] par exemple. 1.2.1 Définition Définition 1.2.1. En cryptographie, un couplage est une application bilinéaire non dégénérée e : G1 × G2 → GT , où (G1, +), (G2, +) et (GT , ×) sont trois groupes. Remarque 1.2.2. En pratique, ces groupes seront supposés cryptographiques, c’est-à-dire dont l’arithmétique soit assez rapide pour permettre les calculs, mais sur lesquels le problème du logarithme discret soit difficile. 1.2.2 Exemples d’utilisation En 2000, Joux ([25]) présenta le premier protocole cryptographique utilisant les couplages. Depuis, des centaines d’articles 3 ont démontré l’utilité de cet outil. Ici, je présenterai rapidement, outre l’échange de clef tripartite à un tour de Joux, le chiffrement basé sur l’identité de Boneh et Franklin ([6]) et le schéma de signature courte de Boneh, Lynn et Shacham ([7]). Ces protocoles sont en effet les plus souvent cités dans les articles résumant la cryptographie basée sur les couplages. Dans tous ces exemples, r sera un grand nombre premier, et le cardinal des trois groupes G1, G2 et GT . Le point P ∈ G1 sera un générateur du groupe. 2. en anglais, pairing. 3. le chapitre 10 de [5] en recensait 28 mi-2002 et environ 100 début 2004.24 Préliminaires 1.2.2.1 Le protocole de Joux [25] Dans ce protocole, on suppose que G1 = G2. Trois parties A1, A2, et A3 ont chacune une clef secrète ai ∈ Z/rZ, et une clef publique correspondante [ai ]P ∈ G1. Durant le tour d’échange, chaque participant envoie simplement sa clef publique aux deux autres participants. Chaque participant Ai ayant reçu les deux autres clefs publiques [aj ]P et [ak]P est alors en mesure de calculer avec sa propre clef secrète la clef commune : e([aj ]P, [ak]P) ai = e(P, P) aiajak . 1.2.2.2 Le chiffrement de Boneh et Franklin [6] Dans un schéma de chiffrement basé sur l’identité, la clef publique de chaque utilisateur est dérivée de son identité (typiquement, de son adresse mail), ce qui règle le problème de la distribution des clefs. Dans un schéma de chiffrement basé sur l’identité, si Alice veut envoyer un message à Bob, elle chiffre son message avec l’identité de Bob. Recevant le message, ce dernier s’authentifie auprès d’une autorité de confiance, le PKG (private key generator), qui lui remet sa clef privée. Voici le premier protocole de chiffrement basé sur l’identité, proposé par Boneh et Franklin : Setup On suppose que G1 = G2. On se donne un point P ∈ G1. Soient s ∈R Z/rZ, et Ppub = [s]P. On se donne également deux fonctions de hachage H1 : {0, 1} ∗ → G1 et H2 : GT → {0, 1} n , où n est la taille des messages. La clef maîtresse est s, et la clef publique globale est Ppub. Extraction Étant donnée une identité (publique) Bob ∈ {0, 1} ∗ , la clef publique se calcule par QBob = H1(Bob) ∈ G1, et la clef privée par SBob = [s]QBob. Chiffrement Alice commence par calculer gBob = e(QBob, Ppub) Soit k ∈R Z/rZ, le message M se chiffre en C = h[k]P, M ⊕ H2(g k Bob)i.Couplages 25 D´echiffrement Bob reçoit C = hU, V i de la part d’Alice. Il calcule alors V ⊕ H2(e(SBob, U)) pour retrouver le message M. 1.2.2.3 La signature courte de Boneh Lynn et Shacham [7] G´en´eration On se donne une fonction de hachage H : {0, 1} ∗ → G2, une clef secrète s ∈R Z/rZ, et une clef publique Ppub = [s]P ∈ G1. Signature Étant donné le secret s et le message m ∈ {0, 1} ∗ , la signature se calcule simplement par σ = [s]H(m). V´erification Bob reçoit le couple hm, σi. Il accepte la signature si et seulement si l’égalité e(P, σ) = e(Ppub, H(m)) est vérifiée. 1.2.3 Le couplage de Tate Les couplages sont des outils mathématiques importants pour l’étude de la théorie des courbes. Ainsi, Weil introduisit son couplage en 1940 ([55]), et en 1985, Miller ([33]) publia son algorithme pour le calculer, et montra comment l’utiliser pour réduire le problème du logarithme discret sur la courbe elliptique au même problème sur le groupe multiplicatif d’un corps fini. Les couplages utilisés en cryptographie sont le couplage de Tate et ses avatars (ate, ate-i, Rate...), dont voici la définition : Définition 1.2.3. Soit C une courbe hyperelliptique de genre g définie sur le corps Fq, et J sa jacobienne. Soit r un grand diviseur premier de ]J (Fq). On suppose que r est premier à q. Le degré de plongement 4 est le plus petit entier k tel que r|(q k − 1). Cela signifie que Fq k est la plus petite extension de Fq à contenir les racines r-ièmes de l’unité µr. On avait supposé que r|]J (Fq), on doit maintenant également demander que r 2 - ]J (Fq) : ceci permet d’identifier J (Fq k )[r] et J (Fq k )/rJ (Fq k ). Alors, pour D1 ∈ J (Fq k )[r], on note fr,D1 la fonction 5 de diviseur div(fr,D1 ) = rD1. 4. en anglais, embedding degree. 5. fr,D1 est uniquement définie à constante multiplicative près.26 Préliminaires Soit D2 ∈ J (Fq k )[r]. On suppose que supp(D1)∩supp(D2) = ∅. Alors la quantité (fr,D1 (D2)) q k−1 r = Y P fr,D1 (P) vP (D2) !q k−1 r définit une application bilinéaire non dégénérée t : J (Fq k )[r] × J (Fq k )[r] → µr. Comme noté dans [20], si D1 est correctement choisi, on a l’amélioration suivante : Lemme 1.2.4 ( [20]). On suppose que k > 1, et que D1 ∈ J (Fq)[r]. Alors t(D1, D2) = fr,D1 ((D2)) q k−1 r . Ainsi, pour des raisons d’efficacité, le domaine de définition du couplage de Tate est réduit à G1 × G2, où les groupes G1 et G2 sont définis de la façon suivante : Définition 1.2.5. On note π le morphisme de Frobenius π : C → C donné par π(x, y) = (x q , yq ), qui se prolonge naturellement sur J . Les groupes notés G1 et G2 sont alors : G1 = J [r] ∩ Ker(π − [1]) = J (Fq)[r] et G2 = J (Fq k )[r] ∩ Ker(π − [q]). Ainsi, G1 6= G2 sont deux Z/rZ espaces vectoriels de dimension au moins 1, et G1 × G2 ⊂ J (Fq k ) est au moins de dimension 2. Dans la suite, G1 et G2 désigneront toujours les groupes introduits dans la défi- nition 1.2.5, et on aura toujours D1 ∈ G1 et D2 ∈ G2. Voyons maintenant l’algorithme de Miller ([33]) pour calculer fr,D1 (D2). Définition 1.2.6. Pour tout i ∈ N, notons Di = ρ(iD). Par définition, Di ∼ iD, et la i-ième fonction de Miller fi,D est définie par div(fi,D) = iD − Di . Le but est alors de calculer fr,D, ce qui se fait par un algorithme double-and-add, via la relation fi+j,D = fi,D · fj,D · hDi,Dj , où hDi,Dj est la fonction apparaissant dans l’addition de Di et Dj : div(hDi,Dj ) = Di + Dj − ρ(Di + Dj ).Couplages 27 1.2.4 Une variante : le couplage ate Il s’agit d’une variante, plus rapide à calculer, du couplage de Tate. Avant de la présenter, il faut commencer par évoquer la normalisation des fonctions de Miller. Définition 1.2.7. Soit f ∈ K(C) avec v∞(f) = −n. Soit u∞ une uniformisante en ∞. 6 Le coefficient dominant de f en ∞ est lc∞(f) = (u n ∞f)(∞). Ainsi, si f est définie en ∞, on a simplement lc∞(f) = f(∞). Alors la normalisation de f est le multiple de f f norm = f/lc∞(f) qui a pour coefficient dominant 1 en l’infini. Muni de cette définition, voici le couplage ate : Théorème 1.2.8. L’application a : G2 × G1 → µr (D2, D1) 7→ f norm q,ρ(D2) ((D1)) est un couplage bilinéaire non dégénéré. . Dans le cas malheureux où supp((D1)) ∩ supp(ρ(D2)) 6= ∅, on est obligé de remplacer (D1) par un autre diviseur D0 ∼ D1. Définition 1.2.9. Ce couplage a(D2, D1) est appelé couplage ate. Voyez les deux grandes différences entre Tate et ate : dans le premier couplage, il faut calculer fr,D, tandis que dans le second on ne va que jusqu’à fq,D. Je rappelle que r|]J (Fq) ≈ q g , ainsi la boucle de Miller est de l’ordre de g fois plus courte pour le calcul de ate que pour le calcul de Tate. Ensuite, on remarquera qu’il n’y a pas d’exponentiation finale pour le calcul de ate. Remarque 1.2.10. Toujours dans l’optique de diminuer la taille de la boucle de Miller, d’autres variantes de Tate et ate ont été introduit, tels que les couplages R-ate, ou ate-i. Je ne le présente pas ici : quel que soit le couplage choisi, il est nécessaire de calculer une quantité du type fs,D(D 0 ). 6. par exemple, on peut prendre u∞ = x 2g/y.28 Préliminaires 1.3 Fonctions thêta On a vu précédemment que l’algorithme de Miller est le moyen traditionnel de calcul de couplages. Je présente maintenant la théorie des fonctions thêta, qui est à la base de la méthode alternative introduite par Lubicz et Robert dans [30]. Pour plus de clarté, je présente d’abord ces outils en genre 1, avant de généraliser à g quelconque. La référence classique est [34]. 1.3.1 Le cas elliptique 1.3.1.1 Définition et premières propriétés Provisoirement, je me place sur une courbe elliptique E définie sur le corps des complexes C. Je rappelle que cela signifie qu’il y a un réseau Λ ⊂ C tel que E ∼= C/Λ. Concrètement, Λ est défini par : Λ = (Z + τZ), où τ ∈ C est traditionnellement choisi avec Im(τ ) > 0. Pour z ∈ C, z (mod Λ) est le représentant de z dans le parallélogramme fondamental, c’est-à-dire celui engendré par 1 et τ . Proposition 1.3.1. Soit a, b ∈ Q. La série θ " a b # (z, τ ) = X n∈Z exp  πi(a + n) 2 τ + 2πi(n + a)(z + b)  définit une fonction holomorphe sur C. Définition 1.3.2. Cette fonction est appelée fonction thêta avec caractéristiques a et b. L’évaluation d’une fonction thêta en z = 0 est appelée une constante thêta. Remarque 1.3.3. — Si a = b = 0, θ " 0 0 # est simplement noté θ. — En pratique, on considérera a, b ∈ {0, 1 2 }, c’est-à-dire les fonctions thêta avec caractéristiques semi entières. Parmi les fonctions thêta, il y en a une particulière qu’on utilisera souvent : la fonction sigma, dont voici la définition :Fonctions thêta 29 Définition 1.3.4. Le produit infini z Y ω∈Λ ω6=0  1 − z ω  e (z/ω)+ 1 2 (z/ω) 2 définit une fonction holomorphe sur tout C appelée fonction σ de Weierstrass (attachée à E). C’est une fonction θ dans le sens où il existe des constantes (que je ne précise pas) C et K telles que : σ(z) = C.exp  K.z2  θ " 1/2 1/2 # (z, τ ). L’importance de cette fonction vient du fait qu’elle permet de construire n’importe quel fonction elliptique. Plus de détails sur σ pourront être trouvées dans [42], chapitre 6. Proposition 1.3.5. Pour tout n ∈ Z, θ " a b # (z + n, τ ) = exp(2πian) θ " a b # (z, τ ), et θ " a b # (z + nτ, τ ) = exp  −2πibn − πin2 τ − 2πinz θ " a b # (z, τ ). Définition 1.3.6. Toute fonction vérifiant les égalités de la proposition 1.3.5 est dite quasi périodique modulo Λ. En particulier, cette proposition signifie que les fonctions θ ne sont pas des fonctions elliptiques : si z ≡ z 0 (mod Λ), on n’a pas θ " a b # (z, τ ) = θ " a b # (z 0 , τ ), parce que ces deux termes diffèrent d’un terme exponentiel. Par contre, ce terme exponentiel n’empêche pas leur lieu d’annulation d’être bien défini sur E : Proposition 1.3.7. On fixe les caractéristiques a et b. Alors, dans le parallélogramme fondamental, θ " a b # (z, τ ) admet comme seul zéro le point (a + 1 2 ) + (b + 1 2 )τ .30 Préliminaires Remarque 1.3.8. En particulier, θ " 1/2 1/2 # (et donc la fonction σ) admet un zéro simple en chaque point du réseau Λ et nulle part ailleurs. Chacune des trois autres θ " a b # avec a, b ∈ {0, 1 2 } semi entières s’annule sur un des trois autres points de 2-torsion de E. Pour P ∈ E, comme la quantité θ " a b # (P) seule n’a pas de sens, la stratégie de [30] est alors de calculer ensembles plusieurs évaluations de fonctions thêta bien choisies. Définition 1.3.9. Soit l ∈ N. Une fonction f sur C est quasi Λ-périodique de niveau l si, pour tout z ∈ C et n ∈ Z, f(z + n) = f(z), and f(z + nτ ) = exp  −πiln2 τ − 2πilnz f(z). L’ensemble de ces fonctions est un espace vectoriel de dimension finie noté Rτ l . Les fonctions thêta avec caractéristiques nous donnent des bases de ces espaces : Proposition 1.3.10. [[34] p. 124] On fixe un niveau l ∈ N. — Les ensembles ( θ " a/l 0 # (lz, lτ ) | 0 ≤ a ≤ l − 1 ) et ( θ " 0 b/l#  z, l−1 τ  | 0 ≤ b ≤ l − 1 ) sont deux bases de Rτ l . — Si 2|l, alors l’ensemble    θ " 0 b/l# (z, 2τ/l) !2 | 0 ≤ b ≤ l − 1    est une autre base de Rτ l . — Enfin, si l = k 2 est un carré, alors une base alternative de Rτ l est : ( θ " a/k b/k# (kz, τ ) | 0 ≤ a, b ≤ k − 1 ) . Remarque 1.3.11. Pour faire le lien avec ce qui a été rappelé en 1.1, notons que Rτ l est isomorphe à l’espace de Riemann-Roch L(lO). J’ai dit avant la définition 1.3.9 qu’il allait nous falloir évaluer plusieurs fonctions thêta d’un coup en un point de la courbe. La proposition suivante nous explique comment :Fonctions thêta 31 Proposition 1.3.12. [[34] p. 127] On fixe un niveau l ∈ N. Soit φ (l) 1 , . . . , φ(l) l une base de Rτ l . Alors la fonction suivante est bien définie : Φl : C/Λ → P l−1 z 7→  φ (l) 1 (z), . . . , φ(l) l (z)  . Si l ≥ 3, Φl est un plongement. Ce n’est pas tout à fait le cas pour l = 2 : Φ2 est en fait un plongement de K vers P 1 , où K désigne la variété de Kummer associée à E, i.e. K ∼= E/{±1}. En pratique, on utilise les fonctions thêta de niveau 2 et 4. Les relations de Riemann (voir [34] p.20) nous donnent alors des formules d’addition satisfaites par les fonctions thêta avec caractéristiques semi entières. On a aussi la proposition suivante : Proposition 1.3.13. Soit z1, z2 ∈ C. Pour tout b ∈ {0, 1/2}, θ " 0 b # (z1 + z2; τ )θ " 0 b # (z1 − z2; τ ) = X a∈{0,1/2} (−1)4abθ " a 0 # z1; τ 2  θ " a 0 # z2; τ 2  . Résumons ce que l’on a énoncé sur les fonctions thêta. Soit P, Q ∈ E. La proposition 1.3.12 nous explique que ces points peuvent être représentés par l’évaluation de certaines fonctions thêta bien choisies en eux. La proposition 1.3.13 nous explique comment représenter le point P +Q, dès lors qu’on a la représentation des points P, Q et P − Q via les fonctions thêta. Avant de rappeler le calcul de couplages expliqué dans [30], je donne quelques formules pour expliciter mon propos. Remarque 1.3.14. On aura remarqué que j’ai présenté ici la théorie classique des fonctions thêta, définies sur C. Evidemment, pour une utilisation cryptographique, il est nécessaire de la transposer aux corps finis. Cela se fait via le principe de Lefschetz. Ainsi, les propositions 1.3.10, 1.3.12 et 1.3.13 restent vraies pour une courbe E définie sur un corps fini. Comment se calculent alors les fonctions thêta ? C’est ce que j’énonce dans la proposition suivante 1.3.15. 1.3.1.2 Arithmétique des fonctions thêta Dans cette section, on travaille sur un corps fini Fq. On supposera toujours que la caractéristique p de Fq est différente de 2. Tout d’abord, voyons comment faire le passage entre la représentation de Weierstrass usuelle d’une courbe et sa représentation par les fonctions thêta. La proposition suivante est le cas g = 1 du théorème 7.6 de [35] (p. 3.113).32 Préliminaires Proposition 1.3.15. Soit E/Fq une courbe elliptique. On suppose que E est donnée par une équation de Weierstrass y 2 = (x − a1)(x − a2)(x − a3). Si tous les aj − ai, 1 ≤ i < j ≤ 3 sont des carrés dans Fq, alors on a : — si P ∈ E\O :   θ " 0 0 # (P, τ ) θ " 1/2 1/2 # (P, τ )   2 = xP − a2 q (a2 − a1)(a3 − a2) ,   θ " 1/2 0 # (P, τ ) θ " 1/2 1/2 # (P, τ )   2 = xP − a3 q (a3 − a1)(a3 − a2) ,   θ " 0 1/2 # (P, τ ) θ " 1/2 1/2 # , τ )   2 = xP − a1 q (a3 − a1)(a2 − a1) ; — si P = O :   θ " 0 0 # O, τ ) θ " 1/2 0 # (O, τ )   2 = √ a3 − a1 √ a2 − a1 ,   θ " 0 1/2 # (O, τ ) θ " 1/2 0 # (O, τ )   2 = √ a3 − a2 √ a2 − a1 , θ " 1/2 1/2 # (O, τ ) = 0. Les bases décrites dans la proposition 1.3.10 de niveau deux seront désignées ainsi : — [uP : vP ] = " θ " 0 0 # (P, τ ) 2 : θ " 1/2 0 # (P, τ ) 2 # , — [u 0 P : v 0 P ] = " θ " 0 0 # (2P, 2τ ) : θ " 1/2 0 # (2P, 2τ ) # ,Fonctions thêta 33 — [˜uP : ˜vP ] = " θ " 0 0 # (P, τ/2) : θ " 0 1/2 # (P, τ/2)# , Et les constantes thêta ainsi : — a = θ " 0 0 # (O, τ/2), b = θ " 0 1/2 # (O, τ/2); — α = θ " 0 0 # (O, 2τ ), β = θ " 1/2 0 # (O, 2τ ); En niveau 4, la même proposition 1.3.10 nous donne la base suivante : [XP : YP : ZP : TP ] = " θ " 0 0 # (2P, Ω) : θ " 1/2 0 # (2P, Ω) : θ " 0 1/2 # (2P, Ω) : θ " 1/2 1/2 # (2P, Ω)# . Les constantes thêta sont désignées ainsi : A = θ " 0 0 # (O, Ω), B = θ " 1/2 0 # (O, Ω), C = θ " 0 1/2 # (O, Ω). Remarque 1.3.16. Notons que θ " 1/2 1/2 # (O, Ω) = 0. La proposition 1.3.13 nous donne les formules de changement de bases suivantes : Proposition 1.3.17. Pour tout point P ∈ E, — uP = 1 2 (au˜P + bv˜P ), vP = 1 2 (au˜P − bv˜P ); — u 0 P = 1 2 (˜uP + ˜vP ), v 0 P = 1 2 (˜uP − v˜P ). En particulier, en prenant P = O, on obtient les relations entre les constantes thêta. Les formules d’addition que vérifient les bases de niveau 2 décrivent l’arithmétique de K : Proposition 1.3.18. Soient P et Q ∈ E. — pour la base (u, v), on a : uP +QuP −Q = (uP + vP )(uQ + vQ) + α 2 β 2 (uP − vP )(uQ − vQ) !2 , vP +QvP −Q = (uP + vP )(uQ + vQ) − α 2 β 2 (uP − vP )(uQ − vQ) !2 ;34 Préliminaires — pour (u 0 , v0 ) : u 0 P +Qu 0 P −Q = (u 02 P + v 02 P )(u 02 Q + v 02 Q) + A2 B2 (u 02 P − v 02 P )(u 02 Q − v 02 Q), v 0 P +Qv 0 P −Q = (u 02 P + v 02 P )(u 02 Q + v 02 Q) − A2 B2 (u 02 P − v 02 P )(u 02 Q − v 02 Q); — enfin, pour (˜u, v˜) : u˜P +Qu˜P −Q = (˜u 2 P + ˜v 2 P )(˜u 2 Q + ˜v 2 Q) + A2 B2 (˜u 2 P − v˜ 2 P )(˜u 2 Q − v˜ 2 Q), v˜P +Qv˜P −Q = (˜u 2 P + ˜v 2 P )(˜u 2 Q + ˜v 2 Q) − A2 B2 (˜u 2 P − v˜ 2 P )(˜u 2 Q − u˜ 2 Q). Regardons maintenant ce qui se passe en niveau 4 : La courbe E peut alors être décrite avec les fonctions de niveau 4 par le théorème suivant : Théorème 1.3.19. On reprend notre courbe E d’équation y 2 = (x − a1)(x − a2)(x − a3). On demande maintenant à ce que les aj − ai soient des puissances quatrièmes dans Fq. Alors, l’application E → T P = [xP : yP ] 7→ [XP : YP : ZP : TP ] O 7→ [A : B : C : 0] établit une équivalence birationnelle entre E et la courbe T : ( X2A2 = Z 2C 2 + Y 2B2 T 2A2 = Z 2B2 − Y 2C 2 Explicitement, ce morphisme est : XP = (xP − a2) 2 + (a2 − a1)(a3 − a2), YP = (xP − a1) 2 + (a3 − a2)(a3 − a1), ZP = (xP − a3) 2 + (a3 − a1)(a2 − a1), TP = ((a3 − a1)(a3 − a2)(a2 − a1)) 1 4 2 yP . Proposition 1.3.20. Les formules d’addition sur T sont données par les relations de Riemann : XP +QXP −QA 2 = X 2 P X 2 Q + T 2 P T 2 Q YP +QYP −QB 2 = X 2 P X 2 Q − Z 2 P Z 2 QFonctions thêta 35 ZP +QZP −QC 2 = X 2 P X 2 Q − Y 2 P Y 2 Q TP +QTP −QA 2 = T 2 P X 2 Q − X 2 P T 2 Q Pour le doublement, si on remplace Q par P dans la dernière équation, on n’obtient rien d’autre que 0 = 0. À la place, il faut utiliser la formule suivante : T2PABC = 2XP YP ZP TP Remarque 1.3.21. — Sur T , l’opposé du point [X : Y : Z : T] est [X : Y : Z : −T]. — Le lien entre niveau 2 et niveau 4 peut se faire via les relations de Riemann : par exemple XA3 =u 2 + t 2 = v 2 + w 2 Y B3 =u 2 − w 2 = v 2 − t 2 ZC3 =u 2 − v 2 = w 2 − t 2 T A2B 2C 2 =4uvwt. L’application [X : Y : Z : T] 7→ [u : v] est donc bien 2 : 1, et la fibre au dessus de chaque point [u : v] consiste en un couple {[X : Y : Z : T], [X : Y : Z : −T]}. 1.3.2 Fonctions thêta en tout genre Après cette longue introduction en genre 1, il va être plus simple de comprendre la généralisation au cas hyperelliptique. Le parcours est le même : je commence par rappeler ce que sont les fonctions thêta, j’évoque ensuite les fonctions de niveau l, et finalement j’explique les coordonnées thêta, c’est-à-dire le plongement projectif de la jacobienne (ou de la kummer) donné par les fonctions thêta. Encore une fois, plus de détails se trouveront dans [34]. Comme en genre 1, on commence par travailler sur C avant de revenir à nos corps finis. Ainsi, soit C/C une courbe hyperelliptique de genre g. Alors J ∼= C g / (Z g + ΩZ g ), où Ω est une matrice symétrique de taille g, que l’on choisit avec Im(Ω) définie positive. Le réseau Z g + ΩZ g est noté Λ. Définition 1.3.22. Soient a, b ∈ Qg . La fonction thêta de caractéristiques rationnelles (a, b) est la fonction analytique sur C g définie par la série : θ " a b # (z; Ω) = X n∈Zg exp  πit (a + n)Ω(n + a) + 2πit (n + a)(z + b)  .36 Préliminaires Exemple 1.3.23. En genre 1, il y avait 4 fonctions thêta avec caractéristiques semi entières. En genre 2, on voit qu’il y en a maintenant 16. Toujours comme en genre 1, ces fonctions nous donnent des bases des espaces de fonctions de niveau l (c’est l’équivalent de la proposition 1.3.10) : Définition 1.3.24. Soit l ∈ N. Une fonction f sur C g est quasi Λ-périodique de niveau l si, pour tout z ∈ C g et m, m0 ∈ Z g , f (z + m + Ωm0 ) = f(z)exp  −πiltm0Ωm0 − 2πilt zm0  . Proposition 1.3.25 ([34] p. 124). L’ensemble des fonctions de niveau l forme un espace vectoriel de dimension l g noté RΩ l . Fixons un niveau l. Les fonctions thêta nous donnent plusieurs bases de RΩ l . On a par exemple les bases suivantes : — ( θ " a 0 # (lz, lΩ) | a ∈  1 l Z g/Z g  ) , — ( θ " 0 b # (z, l−1Ω) | b ∈  1 l Z g/Z g  ) , — si 2|l, ( θ " a b #  2z, 4Ω l  | a ∈  1 2 Z g/Z g  , b ∈  2 l Z g/Z g  ) , — si l = k 2 , ( θ " a b # (kz, Ω) | a, b ∈  1 k Z g/Z g  ) . Remarque 1.3.26. Pour g = 1, on avait vu le lien entre les fonctions de niveau l et les espaces de Riemann Roch. Pour g quelconque, ce lien demeure : R Ω l = L(lΘ). Voici maintenant l’équivalent de la proposition 1.3.12 : le plongement projectif induit par les fonctions thêta. Proposition 1.3.27 ([34] p. 127). On fixe un niveau l ∈ N. Soit φ (l) 1 , . . . , φ(l) l g une base de RΩ l . Alors la fonction suivante est bien définie : Φl : C g /Λ → P l g−1 z 7→  φ (l) 1 (z), . . . , φ(l) l g (z)  . Si l ≥ 3, Φl est un plongement. Ce n’est pas le cas pour l = 2 : Φ2 est en fait un plongement de K vers P 2 g−1 , où K est la variété de Kummer associée à J : K ' J /{±1}.Fonctions thêta 37 Exemple 1.3.28. Les formules d’addition vérifiées par les fonctions thêta en genre 2, et les algorithmes dérivés se trouvent par exemple dans [21]. Enfin, faisons le lien entre les fonctions θ et le diviseur Θ : Proposition 1.3.29 ([35] pp. 3.80-3.82). Soit δ = t  1 2 , . . . , 1 2  , δ0 = t  g 2 , g − 1 2 , . . . , 1 2  ∈ Q g . On note θ " δ δ 0 # . Alors div(θ 0 ) = Θ Exemple 1.3.30. Pour g = 1, on a θ 0 = θ " 1/2 1/2 # , et on retrouve le fait que θ 0 admet un unique zéro simple en O. Je rappelle que quand on étudiait le cas g = 1, on avait spécifié une fonction thêta spéciale : la fonction sigma de Weierstrass. Quand g > 1, son équivalent s’appelle fonction sigma de Klein. Comme pour g = 1, elle est reliée à θ 0 : Définition 1.3.31 ([39]). Pour définir sigma, on a besoin des différentielles suivantes : pour 1 ≤ j ≤ g ηj = 1 2y 2 X g−j k=j (k + 1 − j)fk+1+jx k dx, où les fi sont les coefficients de l’équation de C : y 2 = f(x) = x 2g+1 + f2gx 2g + · · · + f0. On réunit ces différentielles dans un vecteur : η = (ηj )1≤j≤g. Alors, il y a une constante c telle que la fonction sigma hyperelliptique soit la fonction de C g définie par : σ(z) = cexp( 1 2 t zηz)θ " δ δ 0 # (z; Ω). Une dernière proposition utile à garder en tête est la suivante :38 Préliminaires Proposition 1.3.32 ([34] proposition 3.14 p.167). La fonction θ " a b # est paire ou impaire si et seulement si ses caractéristiques a et b sont semi entières. Elle est alors de la parité de 4 tab. En particulier, σ est impaire pour g ≡ 1, 2 (mod 4), et paire dans les deux autres cas. Étudions encore un peu σ avant d’aller plus loin : Définition 1.3.33. Pour i, j, k ∈ {1, 2, . . . , g} et u ∈ C g , les ℘−fonctions hyperelliptiques sont définies de la façon suivante : ℘ij (u) = − ∂ 2 ∂ui∂uj logσ(u), ℘ijk(u) = − ∂ 3 ∂ui∂uj∂uk logσ(u). Ce sont des fonctions bien définies sur J ' C g/Λ. Proposition 1.3.34. [10] Soit D1, D2 ∈ J . Il existe des polynômes Fg(D1, D2) et Gg(D1) ∈ Z[℘ij (D1), ℘ijk(D1), ℘ij (D2), ℘ijk(D2)] tels que σ(D1 + D2)σ(D1 − D2) σ(D1) 2σ(D2) 2 = Fg(D1, D2). σ(2D1) σ(D1) 4 = Gg(D1). Remarque 1.3.35. • Les ℘ fonctions sont un moyen alternatif de représenter les éléments de J . Elles sont reliées à la représentation de Mumford via u = x g − X g l=1 ℘lg(D)x l−1 , v = X g l=1 ℘lgg(D) 2 x l−1 . Plus de détails se trouveront dans [9]. • En réalité, cette propriété n’est pas simplement une propriété d’existence : les polynômes Fg sont bien construits. Comme je n’ai pas besoin de leurs valeurs exactes, je ne les donne pas ici. Elles se trouvent par exemple dans [10]. Le corollaire suivant est à la base de la théorie des hyperelliptic nets : Corollaire 1.3.36. [50] Soit m > 2 g un entier. On se donne m points u (1), . . . , u(m) ∈ C g . La matrice  σ(u (i) + u (j) )σ(u (i) − u (j) )  1≤i,j≤m est de déterminant nul.La théorie des hyperelliptic nets 39 1.4 La théorie des hyperelliptic nets Dans cette section, je rappelle une autre théorie permettant le calcul des couplages : celle des hyperelliptic nets 7 . Comme je l’ai fait pour les fonctions thêta, je commencerai par présenter le cas elliptique avant sa généralisation aux genres supérieurs. 1.4.1 Le cas elliptique Cette section rappelle les résultats de Stange dans [45]. Définition 1.4.1. Soit G un groupe abélien libre de type fini, et A un anneau intègre. Une fonction W : G → A est appelé elliptic net si pour tout quadruplet (a, b, c, d) ∈ G4 : W(a + b)W(a − b)W(c + d)W(c − d) + W(a + c)W(a − c)W(d + b)W(d − b) + W(a + d)W(a − d)W(b + c)W(b − c) = 0. Remarque 1.4.2. On notera pour faire le lien avec le cas hyperelliptique que ceci est équivalent à demander à ce que pour tout quadruplet (u1, . . . , u4) ∈ G4 , on ait det (W(ui + uj )W(ui − uj ))1≤i,j≤4 = 0. Dans un cadre cryptographique, et dans le but de calculer des couplages, G sera Z 2 et A le corps sur lequel l’on travaille : C dans un premier temps pour mettre en place la théorie, un corps fini Fq k ensuite pour faire les calculs en pratique. Soit donc E une courbe elliptique, que je suppose pour le moment définie sur C. Utilisant la fonction σ de Weierstrass, Stange commence par construire un premier elliptic net : Proposition 1.4.3 ([45]). Pour tout couple v = (v1, v2) ∈ Z 2 , Ψv(z1, z2) = σ(v1z1 + v2z2) σ(z1) v 2 1−v1v2 σ(z1 + z2) v1v2 σ(z2) v 2 2−v1v2 est une fonction bien définie E × E. 7. dans ce document, le terme hyperelliptic nets regroupera les cas g = 1 et g > 1.40 Préliminaires Remarque 1.4.4. • Je précise le sens de cette proposition : à priori σ (comme les autres fonctions theta) est définie sur C, et quasi Λ-périodique. Cette proposition signifie qu’en prenant un quotient bien choisi de fonctions sigma, on construit une fonction bien définie sur E, c’est-a-dire qui soit vraiment Λ-périodique. • Dans son article [45], Stange définit des nets sur Z n en toute généralité. Mais comme je l’ai signalé précédemment, pour le calcul de pairings, nous n’aurons besoin que du cas n = 2. Ainsi, dans la proposition précédente, le couple v = (v1, v2) ∈ Z 2 est fixé pour construire une fonction Ψv sur E × E. L’idée maintenant est d’inverser les rôles des zi et des vi : Proposition 1.4.5 ([45]). Fixons donc z1 et z2 ∈ C, avec z1, z2 et z1 + z2 ∈/ Λ. La fonction W : Z 2 → C v 7→ Ψv(z1, z2) est un elliptic net. Remarque 1.4.6. Remarquons dès à présent qu’elle vérifie : W(1, 0) = W(0, 1) = W(1, 1) = 1. Je rappelle que σ admet un zéro simple en O. Cette information permet d’avoir facilement le diviseur de Ψv : Théorème 1.4.7 ([45]). Soit s : E 2 → E et, pour i = 1 or 2, pi : E 2 → E respectivement la somme des composantes et la projection sur la i-ième composante. Leurs pullbacks sont notés s ∗ et p ∗ i . Avec ces notations, le diviseur de Ψv est : DE,v = (([v1] × [v2])∗ s ∗O) − v1v2 (s ∗O) − (v 2 1 − v1v2)p ∗ 1O − (v 2 2 − v1v2)p ∗ 2O. Remarque 1.4.8. En langage humain, ce théorème signifie en particulier que pour (z1, z2) ∈ C correspondant aux points (P1, P2) ∈ E, W(v1, v2) = 0 ⇔ [v1]P1 + [v2]P2 = O.La théorie des hyperelliptic nets 41 Ce théorème a des conséquences importantes. D’abord, Stange établit le théorème de transport de C vers les autres corps (et notamment les corps finis) suivant : Théorème 1.4.9 ([45]). Soit E une courbe elliptique défini sur un corps K quelconque. Soient P1 et P2 deux points de E. Il existe un elliptic net WE,(P1,P2) : Z 2 → K avec les propriétés suivantes : — WE,(P1,P2)(0, 1) = WE,(P1,P2)(1, 0) = WE,(P1,P2)(1, 1) = 1 ; — WE,(P1,P2)(v1, v2) = 0 ⇔ [v1]P1 + [v2]P2 = O sur la courbe E. Définition 1.4.10. Un elliptic net vérifiant les propriétés du théorème 1.4.9 est dit associé à la courbe E et aux points P1 and P2. Ensuite, elle montra comment calculer les couplages avec ces nets. Je rappellerai ce théorème dans le chapitre 2, justement dédié aux couplages. Passons maintenant à la généralisation de cette théorie aux genres plus grands. 1.4.2 Le cas hyperelliptique Ici, je rappelle les résultats qu’Uchida et Uchiyama ont énoncé dans [50]. Le point de départ de leur article est de généraliser la proposition 1.4.3. Comme dans le travail de Stange, la théorie débute sur C : Proposition 1.4.11. Soit C/C une courbe hyperelliptique de genre g. Pour v = (v1, v2) ∈ Z 2 , Ψv(z1, z2) = σ(v1z1 + v2z2) σ(z1) v 2 1−v1v2 σ(z1 + z2) v1v2 σ(z2) v 2 2−v1v2 est une fonction bien définie sur J × J . Remarque 1.4.12. Les mêmes remarques que pour le genre 1 sont ici valables. Vient ensuite la généralisation du théorème 1.4.7 : Théorème 1.4.13. Soient s : J 2 → J et, pour i = 1 et 2, pi : J 2 → J respectivement la somme de toutes les composantes et les projections sur la iième composante. Pour v 6= 0 ∈ Z 2 , le diviseur de Ψv est : DC,v = (([v1] × [v2])∗ s ∗Θ)−v1v2 ((p ∗ 1 × p ∗ 2 )s ∗Θ)−(v 2 1 −v1v2)p ∗ 1Θ−(v 2 2 −v1v2)p ∗ 2Θ.42 Préliminaires Enfin, voici le théorème de transport (équivalent du théorème 1.4.9) Théorème 1.4.14. Soit C/K une courbe hyperelliptique définie sur un corps quelconque K, et D1et D2 deux diviseurs de C. Alors il existe une application WC,(D1,D2) : Z 2 → K vérifiant les deux propriétés suivantes : — WC,(D1,D2) = 0 ⇔ [v1]D1 + [v2]D2 ∈ Θ. — Soit m > 2 g un entier. On se donne v1, . . . vm, et w1, . . . wm dans 1/2Z tels que pour tout i et j, vi ± vj et wi ± wj ∈ Z. Alors, la matrice  WC,(D1,D2)(vi + vj , wi + wj )WC,(D1,D2)(vi − vj , wi − wj )  1≤i,j≤m est de déterminant nul. Définition 1.4.15. La fonction WC,(D1,D2) établie dans le théorème précédent 1.4.14 est appelée hyperelliptic net associé à C et (D1, D2). Exemple 1.4.16. Pour g = 1 et m = 4, on retrouve la définition initiale des elliptic nets. Le fait que v 7→ Ψv soit un hyperelliptic net est une conséquence du corollaire 1.3.36. Plus précisément, et comme dans la proposition 1.4.5 en genre 1 : Théorème 1.4.17. Fixons z1 et z2 ∈ C g . La fonction W : Z 2 → C v 7→ Ψv(z1, z2) est un hypelliptic net.Chapitre 2 Deux méthodes de calculs de couplages Dans le chapitre précédent, j’ai rappelé les théories des fonctions thêta et des hyperelliptic nets, sous-jacentes respectivement à [30] et [50]. Ici, je m’intéresse maintenant aux méthodes de calculs de couplages qui y sont exposées. Après avoir rappelé les résultats déjà existants (théorèmes 2.1.1 et 2.2.1 1 ), je donnerai mes propres résultats : l’algorithme de calcul de couplages en tout genre utilisant les hyperelliptic nets. Enfin, je ferai une comparaison des coûts théoriques en genre 1. De prime abord, cette juxtaposition de deux théories à priori indépendantes pourra sembler décousue, mais ce sera justement l’objet du troisième chapitre d’expliquer les liens profonds les unissant. 2.1 Couplages et fonctions thêta Maintenant que les définitions et propriétés des fonctions thêta ont été rappelées, voici le résultat principal de [30] : Théorème 2.1.1 ([30], théorème 2). On se replace dans la situation de la défi- nition 1.2.3 : C est une courbe hyperelliptique de genre g définie sur le corps Fq, et J sa jacobienne ; r est un grand diviseur premier de ]J (Fq) premier à q ; k est le degré de plongement ; D1 est un élément de J (Fq k )[r]. On se donne θ " a b # de niveau l, où l et r sont premiers entre eux. Alors on a la 1. en fait, comme expliqué plus bas, 2.2.1 est ma version améliorée du théorème énoncé dans [50]. 4344 Deux méthodes de calculs de couplages formule suivante pour le couplage de Tate de D1 et D2 : (t(D1, D2))l = θ " a b # (D2 + rD1) θ " a b # (D2) θ " a b # (0) θ " a b # (D1 + D2) . Ainsi, dans [30], la stratégie pour calculer le couplage de D1 et D2 avec la formule 2.1.1 est de chercher les coordonnées thêta du point D2 + rD1. Remarque 2.1.2. Rappelons que les fonctions thêta ne sont pas Λ-périodiques. Ainsi, même si D1 est dans la r-torsion de J , nous n’avons pas forcément θ " a b # (D2 + rD1) = θ " a b # (D2) Cela se fait par une échelle de Montgomery construite avec les formules d’addition satisfaites par les fonctions thêta : à chaque étape, connaissant les coordonnées de jD1, (j+1)D1 et jD1+D2, on va chercher les coordonnées de 2jD1, (2j+1)D1 et 2jD1 +D2 ou celles des points (2j + 1)D1, (2j + 2)D1 et (2j + 1)D1 +D2, selon la décomposition binaire de r. En pratique, les fonctions thêta les plus efficaces sont celles de niveau 2 et 4, c’est-à-dire celles qui ont été exposées dans la seconde partie de la section 1.3.1.1. 2.2 Couplages et nets Grâce au théorème 1.4.13, Uchida et Uchiyma ([50]) ont exprimé les couplages en fonction des hyperelliptic nets, généralisant par là le travail de Stange : Théorème 2.2.1. On reste dans la situation de la définition 1.2.3. Soit W l’hyperelliptic net associé à D1 ∈ G1 et D2 ∈ G2 défini dans le théorème 1.4.17 (c’est-à-dire issu de la fonction Ψ définie dans la proposition 1.4.11). Le couplage de Tate de D1 et D2 peut se calculer grâce à W : t(D1, D2) = W(r + 1, 1) W(1, 1) !q k−1 r . Ceci est une légère amélioration du théorème donné dans [50] : en effet, la formule initiale est fr,D1 (D2) = W(r + 1, 1)W(1, 0) W(r + 1, 0)W(1, 1). Pour simplifier cette formule, j’utilise le lemme suivant :Couplages et nets 45 Lemme 2.2.2. Dans les conditions du théorème, en particulier avec W l’hyperelliptic net associé à D1 ∈ G1 et D2 ∈ G2 défini dans le théorème 1.4.17, le fait que D1 soit dans J (Fq) nous assure que, pour tout i ∈ N, W(i, 0) ∈ Fq. Démonstration. Grâce à la proposition 1.3.34, pour tout a, b ∈ Z : W(a + b, 0)W(a − b, 0) W(a, 0)2W(b, 0)2 = Fg([a]D1, [b]D1), W(2a, 0) W(a, 0)4 = Gg([a]D1). Or, comme Fg(D1, D2), Gg(D1) ∈ Z[℘ij (D1), ℘ijk(D1), ℘ij (D2), ℘ijk(D2)], si D1 ∈ J (Fq) , alors Fg([a]D1, [b]D1) ∈ Fq. Enfin, dans le théorème 1.4.14 définissant les nets, je peux choisir W(1, 0) ∈ Fq (en pratique, on prendra même W(1, 0) = 1) pour s’assurer par récurrence qu’on ait bien tous les W(i, 0) dans Fq. Ainsi, avec ce lemme et l’exponentiation finale, j’obtiens la formule donnée dans le théorème 2.2.1. Maintenant que le lien entre couplages et nets est établi, il faut expliquer comment construire les algorithmes exploitant ce théorème. Ils sont dérivés de la formule définissant les nets : det(W(vi + vj , wi + wj )W(vi − vj , wi − wj ))1≤i,j≤m = 0. (2.1) Ce travail a été fait en genre 1 par Stange dans [45], et en genre 2 par Uchida et Uchiyama dans [50]. J’ai par la suite généralisé pour tout genre dans [48], ce que j’expose maintenant. Soient D1 et D2 les deux diviseurs dont je veux calculer le couplage. L’hyperelliptic net associé à ces deux diviseurs est noté W. L’algorithme se déroule en deux phases : Initialisation Dans cette phase, on utilise les polynômes Fg et Gg pour calculer un certain nombre (je préciserai plus loin) de valeurs W(a, 0) et W(a, 1), via : W(a + b, 0)W(a − b, 0) W(a, 0)2W(b, 0)2 = Fg([a]D1, [b]D1), W(2a, 0) W(a, 0)4 = Gg([a]D1).46 Deux méthodes de calculs de couplages Double − and − add Une fois cela fait, on utilise l’équation 2.1 pour obtenir les formules qui donneront au final la quantité W(r, 1) souhaitée. Il faut signaler ici que ces formules utilisées dans la seconde phase diffèrent selon que g ≡ 1, 2 (mod 4) ou g ≡ 0, 3 (mod 4). En effet, dans le premier cas, σ est impaire, donc les nets v 7→ Ψv construits dans 1.4.11 aussi. Ainsi, la matrice apparaissant dans l’équation 2.1 est antisymétrique. Cela implique deux choses : d’abord, si on choisit une taille m de matrice impaire, la seule équation que l’on obtient est 0 = 0 (une matrice antisymétrique de taille impaire est toujours de déterminant nul). Ceci explique en particulier pourquoi dans le cas g = 1, Stange a travaillé avec m = 4. D’autre part, pour m = 2n, le déterminant d’une matrice antisymétrique A est le carré d’un polynôme de degré n, son pfaffien, noté Pf(A) : Pf(A) = 1 2 nn! X σ∈S2n sgn(σ) Yn i=1 aσ(2i−1),σ2i , où S2n est le groupe symétrique et sgn(σ) est la signature de σ. Dans le cas g ≡ 0, 3 (mod 4) au contraire σ est paire, la matrice de 2.1 est symétrique, et il faudra trouver d’autres formules. 2.2.1 Le cas g ≡ 1, 2 (mod 4) Avant de donner les théorèmes formels, j’explique le type de formules qu’on utilisera. Notons A la matrice apparaissant dans l’équation 2.1 : A = (W(vi + vj , wi + wj )W(vi − vj , wi − wj ))1≤i,j≤m . Comme signalé plus haut, la taille m de la matrice doit vérifier deux propriétés : m est paire et m > 2 g . Evidemment, pour avoir les formules les plus simples possibles, on prend la valeur m = 2g + 2 minimale. Choisissons les familles d’indices (vi) et (wi) de façon à rendre l’équation Pf(A) = 0 intéressante. Par exemple, pour a un entier, on choisit : • pour tout i, wi = 0 ; • v1 = a + 1, v2 = a − 1 ; • pour tous les autres i /∈ {1, 2}, vi = m − i. Je l’ai déjà signalé plus haut : A est antisymétrique. En particulier, ses termes diagonaux sont nuls, et ses autres coefficients valentCouplages et nets 47 • A12 = W(2a, 0)W(2, 0), et pour i ≥ 3, A1i = W(a + 1 + m − i, 0)W(a + 1 − m + i, 0); • A21 = −A12, et pour i ≥ 3, A2i = W(a + m − i − 1, 0)W(a − m + i − 1, 0); • enfin, pour i et j ∈ {3, . . . , m}, les autres Aij valent Aij = W(2m − i − j, 0)W(j − i, 0). Autrement dit, l’équation Pf(A) = 0 est une relation polynomiale permettant de calculer W(2a, 0) à partir • des W(a + i, 0), pour −(m − 2) ≤ i ≤ m − 2 ; • des W(j, 0), pour 1 ≤ j ≤ m − 3 2 . On voit donc se dégager l’idée de l’algorithme : c’est bien un double-and-add, mais il faut faire attention au fait que W(2a, 0) ne s’obtient pas à partir de seulement W(a, 0) et de quelques valeurs initiales. On a également besoin de termes autour de W(a, 0). Par ailleurs, je rappelle que pour le calcul de couplage je dois calculer le terme W(r + 1, 1). Autrement dit, il faut que je donne les formules permettant de calculer des termes du type W(2a, 1) ou W(2a + 1, 1). Cela se fait naturellement avec d’autres choix d’indices vi et wi que j’expliciterai plus loin. Pour le moment, il me suffira de dire que le même phénomène observé intervient : on n’aura pas seulement besoin de W(a, 0) ou W(a, 1), mais également de tout un tas d’autres valeurs de W autour de (a, 0). Muni de cette observation, définissons comme l’ont fait Stange, puis Uchida et Uchiyama respectivement pour les genres 1 et 2 la notion de bloc centré autour d’un entier a : Définition 2.2.3. Les termes dits initiaux du net W sont : — les 2m − 7 termes {W(i, 0) | 1 ≤ i ≤ 2m − 7} (ou dans le cas g = 1 et m = 4, les deux termes W(1, 0) and W(2, 0)), — les 2m − 2 termes {W(i, 1) | 1 − m ≤ i ≤ m − 2}. Soit a ∈ N, le bloc centré autour de a est formé des — 4m − 8 termes {W(k + i, 0) | − 2m + 4 ≤ i ≤ 2m − 5}, 2. Je rappelle que W est impaire : W(−j, 0) = −W(j, 0).48 Deux méthodes de calculs de couplages — 2m − 5 termes {W(k + i, 1) | 3 − m ≤ i ≤ m − 3}. Remarque 2.2.4. • Dans mon exemple, j’avais décomposé 2a en (a+1)+ (a−1). On pourrait se demander s’il n’aurait pas été plus simple de tout simplement écrire 2a = a + a, autrement dit de faire le choix (v1, w1) = (v2, w2) = (a, 0). En réalité, un tel choix est impossible, et ce pour deux raisons : tout d’abord, parce qu’en faisant ainsi, on aurait eu les deux premières lignes de ma matrice A égales, et donc en calculant son pfaffien, on n’aurait pas obtenu d’autre équation que 0 = 0 ; et de toute manière, on aurait eu A12 = W(2a, 0)W(0, 0), et je rappelle que W(0, 0) = 0 : ainsi, le terme W(2a, 0) ne serait en réalité pas apparu dans l’équation. • Toujours dans l’exemple, on peut observer que j’ai arbitrairement placé le terme intéressant à calculer dans la case A12 de ma matrice ; que les autres coefficients des deux premières lignes sont formés de termes qui sont dans le bloc calculé à l’étape précédente du double-and-add ; et que les autres coefficients de la matrice sont des termes initiaux. • Ces termes initiaux sont apparus du fait de mon choix ∀3 ≤ i ≤ m, vi = m − i. De façon triviale, on peut dire que les deux indices vraiment intéressants sont v1 et v2, puisque ce sont avec eux que j’obtiens le terme à calculer W(2a, 0). Les autres vi ne sont en somme que du remplissage, et je rappelle qu’il ne m’est pas possible de prendre pour deux indices i et j différents (vi , wi) = (vj , wj ), ce qui explique mon choix pour ces valeurs de vi : j’ai pris les m − 2 plus petits entiers. • Une remarque sur la définition maintenant. On remarquera qu’un bloc est constitué de deux niveaux : le niveau 0, constitué des termes du type W(i, 0), et le niveau 1 avec tous les termes du type W(i, 1). Les termes W(i, 0) ne dépendent que de D1 et des coefficients de la courbe C, et vivent donc dans le corps de base Fq, tandis que les W(i, 1) dépendent de D1 et de D2, et seront donc des éléments de Fq k . Ainsi, le calcul d’un bloc se déroulera en deux temps : d’abord on calculera les termes de niveau 0, et ces opérations seront peu couteuses puisque dans Fq ; puis on réglera le compte du niveau 1, et pour cela il faudra payer un peu plus, puisqu’on évoluera dans Fq k . • Enfin, on remarquera qu’avec g = 1 et 2, ma définition de bloc coïncide bien avec celles de [45] et [50]. Définition 2.2.5 (Paramétrages). Voici les différents choix des paramètres vi et wi qu’on va utiliser dans notre algorithme.Couplages et nets 49 Pour le niveau 0, c’est-à-dire pour le calcul des termes W(2a + c, 0), 4 − 2m ≤ c ≤ 2m − 4, on utilise le choix suivant : — pour tout 1 ≤ i ≤ m, wi = 0, — v1 = l + l 0 + 1, — v2 = l − 1, — pour tout 3 ≤ i ≤ m, vi = m − i, où l = a +  c 2  et l 0 = ( 0 si c est pair. − 1 sinon. Un tel choix sera désormais appelé param´etrage (l, l 0 , 0), et vérifie a − (m − 2) ≤ l ≤ a + (m − 2). Pour le niveau 1 maintenant, on calcule W(2a + c, 1) (−(m − 3) ≤ c ≤ m − 2) avec le choix suivant : — w1 = 1 et tous les autres wi valent 0 ; — v1 = a ; — v2 = a + c ; — for 3 ≤ i ≤ m, vi = m − i. Un tel choix est appelé param´etrage (a, c, 1). Regardons maintenant précisément les formules que l’on obtient avec ces différents paramétrages. Je note Aˆ ij la matrice carrée de taille m − 2 obtenue en retirant les lignes et colonnes numéro i et j de A. De même, Aˆ ijkl est la matrice de taille m − 4 obtenue en retirant les 4 lignes et 4 colonnes numéro i, j, k et l de A. Le pfaffien de A se développe alors de la façon suivante : Pf(A) = A12Pf(Aˆ 12) + Xm i=3 (−1)iA1iPf(Aˆ 1i) = A12Pf(Aˆ 12) + Xm i=3 X j6=i 3≤j≤m (−1)i+jA1iA2jPf(Aˆ 12ij ). Or, on remarquera que dans tous les paramétrages (l, l0 , 0) et (a, c, 1), les lignes 3 à m de A sont identiques (seules les 2 premières varient). Ainsi, les coefficients Pf(Aˆ 12) et Pf(Aˆ 12ij ) de nos équations sont constants tout le long de l’algorithme : il faudra les précalculer. Finalement, les formules obtenues sont les suivantes :50 Deux méthodes de calculs de couplages Définition 2.2.6 (Formules). — Pour −m + 2 ≤ b ≤ m − 2, W(2a + 2b, 0) = X j6=i 3≤i,j≤m (−1)i+j+1Pf  Aˆ 12ij Pf  Aˆ 12 W(2, 0) A1iA2j avec A1i = W(a + b + m + 1 − i, 0)W(a + b + 1 + i − m, 0) et A2j = W(a + b + m − 1 − j, 0)W(a + b − 1 + j − m, 0); — pour −m + 3 ≤ b ≤ m − 2, W(2a + 2b + 1, 0) = X j6=i 3≤i,j≤m (−1)i+j+1Pf  Aˆ 12ij Pf  Aˆ 12 W(1, 0) A1iA2j avec A1i = W(a + b + m + 1 − i, 0)W(a + b + 1 + i − m, 0) et A2j = W(a + b + m − j, 0)W(a + b + j − m, 0); — pour −m + 3 ≤ b ≤ m − 2, W(2a + b, 1) = X j6=i 3≤i,j≤m (−1)i+j+1Pf  Aˆ 12ij Pf  Aˆ 12 W(−b, 1) A1iA2j avec A1i = W(a + m − i, 1)W(a + i − m, 1) et A2j = W(a + b + m − j, 0)W(a + b + j − m, 0). A partir de ces formules, on obtient notre algorithme de type double-and-add, ce qu’énonce le théorème suivant : Théorème 2.2.7. Soit a un entier. On suppose qu’aucun des termes suivants n’est nul : — W(1, 0) et W(2, 0); — W(b, 1), pour −m + 2 ≤ b ≤ m − 3 ; — Pf  Aˆ 12 . Dans ces conditions, si on dispose des termes initiaux de W et du bloc centré en a, alors on est en mesure de calculer le bloc centré en 2a et celui centré en 2a+1. Démonstration. Les conditions du théorème permettent de s’assurer que les dé- nominateurs des formules énoncées ne s’annulent pas. Une fois ces précautions prises, il ne reste alors plus qu’à vérifier que les termes apparaissant dans les membres de droite des différentes formules sont bien tous ou bien initiaux, ou bien dans le bloc centré en a.Couplages et nets 51 Remarque 2.2.8. — Comme signalé dans la preuve du lemme 2.2.2, en pratique on aura W(1, 0) = W(0, 1) = 1. — Pour g = 1 et m = 4, on a tous les Pf  Aˆ 12ij égaux à 1, ce qui nous redonne les équations de [45]. Enfin, remarquons que parmi tous ces coefficients A1j et A2j dont on a besoin, certains sont redondants : — les A1j du paramétrage (l + 1, −1, 0) sont les mêmes que ceux du paramé- trage (l, 0, 0), — les A2j du paramétrage (l, −1, 0) sont les mêmes que ceux du paramétrage (l, 0, 0), — les A2j du paramétrage (l + 2, −1, 0) sont les A1j du paramétrage (l, 0, 0), — les A1j du paramétrage (k, c, 1) sont indépendants de c, — les A2j du paramétrage (a, c, 1) sont les mêmes que ceux du paramétrage (a + c + 1, 0, 0). Ainsi, les seuls coefficients à calculer sont : — les A1j , 3 ≤ j ≤ m, pour les 2m − 4 paramétrages (l, 0, 0); — les A2j , 3 ≤ j ≤ m, pour les paramétrages (a−m+2, 0, 0) et (a−m+3, 0, 0), ou (a − m + 3, 0, 0) et (a − m + 4, 0, 0); — les A1j , 3 ≤ j ≤ m, du paramétrage (a, −m + 3, 1). 2.2.2 Le cas g ≡ 0, 3 (mod 4) La stratégie est la même que précédemment : étant donné un bloc centré en a, on désire calculer le bloc centré en 2a ou celui centré en 2a + 1, de façon à finalement sortir W(r + 1, 1). Les différences avec le cas g ≡ 1, 2 (mod 4) sont les suivantes : — la matrice A est maintenant symétrique ; — on n’a plus besoin de prendre m pair, donc je peux prendre m = 2g + 1 ; — malheureusement, on ne dispose plus du pfaffien, mais seulement du dé- terminant. Ceci va alourdir les équations qu’on obtiendra. La nouvelle définition de termes initiaux et de bloc est la suivante : Définition 2.2.9. Les termes initiaux sont les — 2m − 3 termes {W(i, 0) | 0 ≤ i ≤ 2m − 4}, — 2m − 2 termes {W(i, 1) | 0 ≤ i ≤ 2m − 3}. Pour a un entier, le bloc centré en a est constitué des — 4m − 6 valeurs {W(a + i, 0) | − 2m + 4 ≤ i ≤ 2m − 3},52 Deux méthodes de calculs de couplages — 2m − 2 valeurs {W(a + i, 1) | 0 ≤ i ≤ 2m − 3}. On donne maintenant la définition des paramétrages choisis : Définition 2.2.10 (Paramétrages). Pour calculer W(2a + 2b, ), on prend — pour tout 1 ≤ i ≤ m, wi = /2, — v1 = a + b, — pour 2 ≤ i ≤ m, vi = m − i. Ce réglage sera noté (b, 0, ), pour  = 0, 1, et −m + 2 ≤ b ≤ m − 1 si  = 0, ou 0 ≤ b ≤ m − 1 si  = 1. Pour calculer W(2a + 2b + 1, ), où  = 0, 1, et −m + 2 ≤ b ≤ m − 2 si  = 0, ou 0 ≤ b ≤ m − 2 si  = 1, on prend le réglage (b, 1, ), à savoir : — pour tout 1 ≤ i ≤ m, wi = /2, — v1 = a + b + 1/2, — pour 2 ≤ i ≤ m, vi = m − i + 1/2. Comme pour g ≡ 1, 2 (mod 4), il faut maintenant donner les formules précises qui découlent de ces réglages. Je note Aˆ i,j la matrice carrée de taille m − 1 obtenue en ôtant la i-ième ligne et la j-ième colonne de A. De même, j’obtiens Aˆ ij,kl en retirant les lignes numéro i et j et les colonnes k et l de A. Je développe alors le déterminant de A de la façon suivante : 0 = A11det  Aˆ 1,1  + X 1≤i,j≤m (−1)i+jA1iA1jdet  Aˆ 1i,1j  . Les coefficients det  Aˆ 1,1  et det  Aˆ 1i,1j  sont précalculés. Malheureusement, et contrairement au cas g ≡ 1, 2 (mod 4), ces déterminants diffèrent selon le réglage utilisé. Je les noterai donc respectivement par les lettres B, C, D et E pour les réglages (b, 0, 0), (b, 1, 0), (b, 0, 1) and (b, 1, 1). Les formules obtenues sont alors les suivantes : Définition 2.2.11 (Formules). — Pour −m + 2 ≤ b ≤ m − 1, W(2a + 2b, 0) = X 2≤i,j≤m (−1)i+j+1det  Bˆ 1j,1i  det  Bˆ 1,1  W(0, 0) A1iA1j avec A1i = W(a + b + m − i, 0)W(a + b + i − m, 0);Couplages et nets 53 — pour −m + 2 ≤ b ≤ m − 2, W(2a + 2b + 1, 0) = X 2≤i,j≤m (−1)i+j+1det  Cˆ 1j,1i  det  Cˆ 1,1  W(0, 0) A1iA1j avec A1i = W(a + b + m + 1 − i, 0)W(a + b + i − m, 0); — pour 0 ≤ l ≤ m − 1, W(2k + 2l, 1) = X 2≤i,j≤m (−1)i+j+1det  Dˆ 1j,1i  det  Dˆ 1,1  W(0, 0) A1iA1j avec A1i = W(a + b + m − i, 1)W(a + b + i − m, 0); — pour 0 ≤ l ≤ m − 2, W(2k + 2l + 1, 1) = X 2≤i,j≤m (−1)i+j+1det  Eˆ 1j,1i  det  Eˆ 1,1  W(0, 0) A1iA1j avec A1i = W(a + b + m + 1 − i, 1)W(a + b + i − m, 0). Alors, avec le même raisonnement que dans le cas g ≡ 1, 2 (mod 4), on obtient à partir de ces formules notre algorithme en double-and-add : Théorème 2.2.12. Si aucune des valeurs det  Bˆ 1,1  , det  Cˆ 1,1  , det  Dˆ 1,1  et det  Eˆ 1,1  ne s’annule, alors, à partir des termes initiaux et du bloc centré en a, on est en mesure de calculer le bloc centré en 2a et celui centré en 2a + 1. Hélas, une autre différence pénible avec le cas g ≡ 1, 2 (mod 4) apparaît : il n’y a aucune redondance parmi les coefficients A1i et A2j , et il faudra tous les calculer. 2.2.3 Un exemple en genre 3 En genre 3, notre courbe a pour équation C : y 2 = x 7 + λ6x 6 + · · · + λ0. La représentation de Mumford d’un diviseur D ∈ J \Θ est D = [U, V ] avec U = x 3 + U2x 2 + U1x + U0, V = V2x 2 + V1x + V0. On se donne une courbe C et deux diviseurs D1 et D2 dont on veut calculer le couplage. Comme expliqué plus haut, on commence par la phase d’initialisation,54 Deux méthodes de calculs de couplages c’est-à-dire par le calcul des {W(i, 0) | i = 0, . . . , 14} et {W(i, 1) | i = 0, . . . , 15}. Pour cela, on prend W(1, 0) = W(0, 1) = 1, et on obtient les autres avec les polynômes F3 et G3 (voir proposition 1.3.34) : ∀a, b, i ∈ Z,    W(a + b, i)W(a − b, i) W(a, i) 2W(b, 0)2 = F3([a]D1 + [i]D2, [b]D1), W(2a, 0) W(a, 0)4 = G3([a]D1). Les valeurs de F3 et G3 se trouvent par exemple dans [10] et [49] : F3(u, v) = (℘31(v) − ℘31(u))(℘22(v) − ℘22(u)) − (℘31(v) − ℘31(u))2 + (℘32(v) − ℘32(u))(℘21(v) − ℘21(u)) + (℘33(v) − ℘33(u))(℘11(v) − ℘11(u)), G3(u) = ℘113(u)℘223(u) + ℘133(u)℘122(u) − 2℘133(u)℘113(u) − ℘123(u) 2 − ℘233(u)℘112(u) + ℘133(u)℘113(u) + ℘333(u)℘111(u). Je rappelle que les ℘i3 et ℘i33, 1 ≤ i ≤ 3 d’un diviseur D se lisent directement sur ses coordonnées de Mumford. Les autres évaluations des ℘ fonctions s’obtiennent à partir des formules se trouvant dans l’appendice C de [13]. Plus précisément, on utilise les trois premières formules pour calculer successivement ℘22, ℘12 et ℘11. Puis on utilise les formules de poids (−18) de ce même document pour obtenir les sept produits ℘ijk℘lmn intervenant dans le calcul de G3. Par exemple, considérons la courbe C d’équation y 2 = x 7 + 3x 6 + 2x 5 + 10x 4 + 9x 3 + 3x 2 + 11 définie sur F29. Avec r = 41, le degré de plongement est 40, donc l’exponentiation finale est e = 2940 − 1 41 = 764075121631975351615803381072559018207546756758889888800. Soit a ∈ F29 une racine de X 40 + X 5 + 4 ∈ F29[X], alors F2940 ' F29(a). Soit D1 ∈ J (F29)[41] donné par sa représentation de Mumford : [x 3 + 2x 2 + 9x + 24, 23x 2 + 24x + 4].Couplages et nets 55 Soit D2 ∈ J (F2940 ) donné par : U =x 3 + (27a 5 + 27a 2 + 28a + 16)x 2 + (4a 7 + 2a 6 + 21a 5 + 2a 3 + 21a 2 + 5a + 10)x+ 25a 8 + 26a 7 + 24a 6 + 18a 5 + 24a 3 + 18a 2 + a + 8 V =(26a 39 + 16a 38 + 14a 37 + 7a 36 + 27a 35 + 19a 34 + 7a 33 + 19a 32 + 15a 31 + a 30+ 21a 29 + 2a 28 + 5a 27 + 22a 26 + 27a 25 + 21a 24 + 4a 23 + 5a 22 + 6a 21 + 27a 20 + 6a 19+ 27a 18 + 13a 17 + 12a 16 + 15a 15 + 10a 14 + 23a 13 + 23a 12 + 25a 11 + 2a 10 + 4a 9 + 14a 8+ a 26 + 21a 25 + 26a 24 + 28a 23 + 10a 22 + 14a 21 + 3a 20 + 23a 19 + 14a 18 + 26a 17 + 7a 16+ 23a 7 + 3a 6 + 28a 5 + 2a 4 + 26a 3 + 12a 2 + 27a + 4)x 2 + (a 39 + 15a 38 + 6a 37 + 13a 36+ 20a 35 + 5a 34 + 23a 33 + 28a 32 + 8a 31 + 20a 30 + 16a 29 + a 28 + 12a 27 + 13a 15 + 28a 14+ 15a 13 + 25a 12 + a 11 + 19a 10 + 11a 9 + 17a 8 + 21a 7 + 11a 6 + 12a 5 + 16a 4 + 8a 2 + 21a+ 22)x + 15a 39 + 14a 38 + 23a 37 + 25a 36 + 27a 35 + 14a 34 + 13a 33 + 10a 31 + 3a 30+ 14a 29 + 13a 28 + 27a 27 + 14a 26 + 21a 25 + 13a 24 + 8a 23 + 25a 22 + 27a 21 + 23a 19+ 24a 18 + 11a 17 + 6a 16 + a 15 + 3a 14 + 18a 13 + a 12 + 21a 11 + 2a 10 + 26a 9+ 26a 8 + 11a 7 + 4a 6 + 18a 5 + 9a 4 + 28a 3 + 5a 2 + 4a + 6. On trouve alors que (WD1,D2(42, 1))e = 4a 39 + 14a 38 + 21a 37 + · · · + 5a 2 + 4a + 16. On peut vérifier que τ : J (Fq)[r] × J (Fq k )/rJ (Fq k ) → µr (D1, D2) 7→ (WD1,D2 (r + 1, 1))e est bien bilinéaire : — on prend D3 ∈R J (Fq k ) et vérifie que (WD1,D2+rD3 (r + 1, 1))e = (WD1,D2 (r + 1, 1))e ; — on prend deux entiers aléatoires m and n et vérifie que (WmD1,nD2 (r + 1, 1))e = (WD1,D2 (r + 1, 1))emn . 2.2.4 Analyse théorique de coûts Comptons le nombre d’opérations effectuées à chaque itération de notre doubleand-add. Il faudra distinguer les opérations faisant intervenir uniquement les coordonnées de P ∈ J (Fq) et ceux faisant également intervenir Q ∈ J (Fq k ). Ainsi, je note M et S les coûts respectifs d’une multiplication et d’une mise au carré dans Fq k , M56 Deux méthodes de calculs de couplages et S les coûts de ces opérations dans Fq, et Mk le coût d’une multiplication mixte, c’est-à-dire entre un terme dans Fq k et un autre dans Fq. Le coût des additions sera négligé. Je rappelle qu’à chaque itération il faudra calculer tous les termes d’un bloc. Ce bloc est constitué de termes de la forme W(a, 0) ∈ Fq et de termes de la forme W(a, 1) ∈ Fq k . Ces termes se calculent avec les formules données dans les sous sections 2.2.1 et 2.2.1. Ces formules sont toutes de la forme W(a, b) = XKijA1iA2j avec • W(a, b) le terme à calculer ; • les coefficients Kij ∈ Fq si b = 0 et Fq k si b = 1 ; • dans le cas où g ≡ 1, 2 (mod 4), ces Kij sont précalculés avant de rentrer dans la boucle du double-and-add ; dans l’autre cas, il faudra les recalculer à chaque fois ; • enfin, les éléments A1i et A2j de la matrice sont dans Fq si b = 0 ; certains d’entre eux sont dans Fq k sinon. L’analyse tiendra ainsi compte du coût de calcul des termes Kij , A1i et A2j des équations, puis du coût des opérations à effectuer entre ces termes. Je rappelle que dans le cas où g ≡ 1, 2 (mod 4) il y aura moins de termes A1i et A2j à calculer que dans le cas où g ≡ 0, 3 (mod 4). On obtient finalement le nombre suivants d’opérations : — 8 · 2 3g − 9 · 2 2g + 5 · 2 g − 2 M, — 2 g+1 + 2 S, — 2 g (2g − 1)(2g+1 − 1) + 2 Mk, — 2 g+1 + 2g − 4 M, — 1 S si g ≡ 1, 2 (mod 4); et — (4m3 − 8m2 + 4m − 4) M, — 2(m − 1)2 Mk, — (2m3 − 6m2 + 8m − 4) M, — 2(m − 1)2 S si g ≡ 0, 3 (mod 4).Résultats en genre 1 57 2.3 Résultats en genre 1 Ici, je compare les coûts des algorithmes basés respectivement sur les fonctions thêta ([30]) et sur les nets ([45]) pour le genre 1. Dans le premier cas, je rappelle que les bases de fonctions de niveau 2 introduites dans la partie 1.3.1.1 sont les suivantes : — [uP : vP ] = " θ " 0 0 # (P, Ω)2 : θ " 1/2 0 # (P, Ω)2 # , — [u 0 P : v 0 P ] = " θ " 0 0 # (2P, 2Ω) : θ " 1/2 0 # (2P, 2Ω)# , — [˜uP : ˜vP ] = " θ " 0 0 # (P, Ω/2) : θ " 0 1/2 # (P, Ω/2)# . La stratégie a été rappelée dans la section 2.1 : c’est un double-and-add, et, à chaque itération, à partir des coordonnées de jD1, (j + 1)D1 et jD1 + D2, on va chercher les coordonnées de 2jD1, (2j + 1)D1 et 2jD1 + D2 ou celles des points (2j + 1)D1, (2j + 2)D1 et (2j + 1)D1 + D2, selon la décomposition binaire de r. Ainsi, à chaque itération, on utilise toujours les formules données dans la proposition 1.3.18 pour effectuer deux additions et un doublement. En étudiant ces formules, on remarque que les coûts de l’arithmétique des coordonnées (u 0 , v0 ) sont les mêmes que ceux pour les coordonnées (˜u, v˜). Avec les notations de la section précédente, nous avons donc les coûts suivants pour une itération : Coordonnées (u, v) (u 0 , v0 ) ou (˜u, v˜) Coûts 2S + 1M + 3Mk + 6S + 6M 2S + 1M + 2Mk + 10S + 7M Du côté elliptic net, dans [45], le coût d’une étape est de 1S + 2M + 6Mk + 6S + 26M. Pour comparer ces coûts, plusieurs approximations sont faites. Ainsi, en pratique, on considère généralement que 1Mk ' kM. De plus, en cryptographie, le corps Fq k est construit à partir de Fq comme une tour d’extensions. On prendra volontiers k comme un entier de la forme 2 i3 j , et ainsi Fq k s’obtient grâce à une succession d’extensions quadratiques et cubiques. Grâce aux méthodes de Karatsuba et Toom-Cook, on a donc M ' 3 i6 jM et S ' 2 iM5 jS (voir par exemple [12] pour plus de détails). Si finalement on admet l’approximation M ' S, on obtient le tableau suivant pour les premières valeurs de k :58 Deux méthodes de calculs de couplages k Coordonnées (u, v) Coordonnées (u 0 , v0 ) ou (˜u, v˜) Méthode Elliptic Nets 4 41M 42M 78M 6 65M 64M 108M 8 79M 76M 142M 12 143M 136M 214M 16 173M 162M 306M 18 274M 261M 406M 24 299M 280M 486M 36 644M 613M 996M 48 721M 678M 1210M Si on compare le coût d’utilisation des coordonnées (u, v) avec celui pour les deux autres jeux de coordonnées, on remarque qu’un petit nombre d’opérations dans le corps de base (4S et 1M) est échangé contre une multiplication mixte. Cela explique que pour les grandes valeurs de k, les coordonnées (u 0 , v0 ) et (˜u, v˜) sont plus efficaces que les coordonnées (u, v). Pour les petites valeurs de k par contre la différence est négligeable. Concernant l’algorithme des elliptic nets, le nombre prohibitif de multiplications mixtes le rend non compétitif par rapport à l’algorithme basé sur les formules d’addition des fonctions thêta. Enfin, comparons les performances de ces algorithmes avec celles des méthodes traditionnelles de calcul de couplage, basées sur l’algorithme de Miller. Selon [28], le coût d’une étape est de 1S + 1M + 1Mk + 11M. Ainsi que noté dans [31], ces résultats rendent les algorithmes étudiés dans ce chapitre très peu compétitifs en genre 1. Ainsi, le coût de l’utilisation de l’algorithme de type Miller donné dans [28] varie selon les valeurs de k entre 68 et 86% celui de l’utilisation des coordonnées (u 0 , v0 ).Chapitre 3 Unification de ces deux méthodes Observant les théorèmes 2.1.1 et 2.2.1, on remarque une grande similitude entre la formule de couplages fournie par les nets, et celle donnée par les fonctions thêta. L’objet de ce chapitre est d’expliquer cette ressemblance. Plus exactement, je montre ici que les deux théorèmes 2.1.1 et 2.2.1 sont en fait des "sous cas" des propriétés suivantes des fonctions de niveau l (i.e. des bases des espaces de Riemann L(lO)) : (i) si l est pair, alors tout ensemble de coordonnées de niveau l vérifie une loi d’addition, à partir de laquelle on peut en extraire un algorithme tel que celui de [30] ; (ii) si l est pair, cette loi d’addition a pour conséquence que ces coordonnées forment ce que j’appelle des generalized hyperelliptic nets; en particulier, si l = 2, ce sont des hyperelliptic nets au sens classique de [50] (cette dé- finition est rappelée dans le théorème 1.4.14). Dans ce chapitre, et comme je l’ai déjà fait plusieurs fois, je m’intéresserai d’abord au cas elliptique. Il sera ensuite aisé de généraliser le résultat aux genres supé- rieurs. 3.1 Réécriture des elliptic nets Je rappelle qu’un des théorèmes fondamentaux de Stange dans [45] est le théorème 1.4.7, établissant le diviseur de sa fonction Ψ, à partir de laquelle sont bâtis ses elliptic nets. Ainsi, ce théorème lui-a-t’il permis de reconstruire les fonctions de Miller, puisque ceux-ci sont eux mêmes définis par leur diviseur. Son théorème 1.4.7, elle l’a établi connaissant le diviseur de sigma : cette fonction admet un zéro simple en O, et rien d’autre. Il est aisé de faire le même travail en utilisant une autre fonction thêta. Ainsi, dans le théorème suivant, nous allons étendre la construction des fonctions Ψ de Stange : 5960 Unification de ces deux méthodes Théorème 3.1.1. Soit E une courbe elliptique, pour le moment définie sur C. Soient a, b ∈ {0, 1/2} des caractéristiques semi-entières. Pour v = (v1, v2) ∈ Z 2 , Ψv(z1, z2) = θ " a b # (v1z1 + v2z2) θ " a b # (z1) v 2 1−v1v2 θ " a b # (z1 + z2) v1v2 θ " a b # (z2) v 2 2−v1v2 est une fonction bien définie sur E × E. Démonstration. Pour le premier point, il s’agit de montrer que pour tout couple (N1, N2) ∈ N 2 , on a Ψv(z1 + N1, z2 + N2) = Ψv(z1, z2) et Ψv(z1 + N1τ, z2 + N2τ ) = Ψv(z1, z2). Etudions la première égalité. En se servant du fait que pour tout entier n, θ " a b # (z + n, τ ) = exp(2πian) θ " a b # (z, τ ), on a Ψv(z1 + N1, z2 + N2) = exp(2πiaA)Ψv(z1, z2), avec A =v1N1 + v2N2 − (v 2 1 − v1v2)N1 − v1v2(N1 + N2) − (v 2 2 − v1v2)N2 =(v1 − v 2 1 )N1 + (v2 − v 2 2 )N2. On remarque alors que A ≡ 0 (mod 2), ce qui nous permet bien de conclure que Ψv(z1 + N1, z2 + N2) = Ψv(z1, z2). On passe maintenant à la seconde égalité. La formule dont on doit se servir est la suivante : pour tout entier n, θ " a b # (z + nτ, τ ) = exp  −2πibn − πin2 τ − 2πinz θ " a b # (z, τ ). Ainsi, on a Ψv(z1 + N1τ, z2 + N2τ ) = exp(−2πibA − πiτB − 2πiC)Ψv(z1, z2), où A est l’entier calculé plus haut (on a donc toujours exp(−2πibA) = 0), alors que B et C sont deux quantités qui restent à calculer, et que nous allons voirFonctions de niveau 2 et elliptic nets 61 nuls. En effet, on a B =(v1N1 + v2N2) 2 − (v 2 1 − v1v2)N 2 1 − v1v2(N1 + N2) 2 − (v 2 2 − v1v2)N 2 2 =0. et C =(v1N1 + v2N2)(v1z1 + v2z2) − (v 2 1 − v1v2)N1z1 − v1v2(N1 + N2)(z1 + z2) − (v 2 2 − v1v2)N2z2 =0. Ainsi, on a bien Ψv(z1 + N1τ, z2 + N2τ ) = Ψv(z1, z2), et donc Ψv est bien une fonction bien définie sur E × E. Il reste alors à faire le lien entre ces nouvelles fonctions Ψ et les elliptic nets : Proposition 3.1.2. Soient a, b ∈ {0, 1/2}, et P, Q ∈ E. La fonction W : Z 2 → C (p, q) 7→ Ψp,q(P, Q) définie dans le théorème précédent 3.1.1 est un elliptic net au sens de Stange. Démonstration. Pour 1 ≤ i ≤ 4, soient ui,1 et ui,2 ∈ Z. Il faut voir que det (W(ui,1 + uj,1, ui,2 + uj,2,)W(ui,1 − uj,1, ui,2 − uj,2,)) = 0. En utilisant les formules de Riemann, (qui se trouvent par exemple dans [34] p.22), cela peut se faire via un logiciel de calcul formel. Ainsi, on a vu que les fonctions thêta de caractéristiques semi entières fournissent des elliptic nets. On passe maintenant aux autres fonctions de niveau l, pour l pair, en commençant par le cas l = 2. 3.2 Fonctions de niveau 2 et elliptic nets Dans cette section et la suivante, je travaille avec E/K une courbe elliptique définie sur un corps quelconque K. La variété de Kummer de E est notée K (je62 Unification de ces deux méthodes rappelle que K ∼= E/{±1}). Les deux théorèmes suivants nous donnent deux méthodes possibles en doubleand-add pour obtenir des quantités du type κ1([r]P + Q) pour un grand premier r. La première est d’utiliser la loi d’addition vérifiée par {κ1, κ2} : Théorème 3.2.1. On reprend κ = [κ1 : κ2] : E → P1 un plongement projectif de la variété de Kummer de E, avec {κ1, κ2} une base de L(2O). Alors il existe des applications bilinéaires B11, B12 et B22 telles que, pour tous points P et Q ∈ E, l’on ait • κ1(P + Q)κ1(P − Q) = B11 −−−→ κ(P)2, −−−→ κ(Q)2  , • κ1(P + Q)κ2(P − Q) + κ1(P − Q)κ2(P + Q) = B12 −−−→ κ(P)2, −−−→ κ(Q)2  , • κ2(P + Q)κ2(P − Q) = B22 −−−→ κ(P)2, −−−→ κ(Q)2  , où −−−→ κ(P)2 et −−−→ κ(Q)2 désignent les vecteurs colonnes suivants : −−−→ κ(P)2 =   κ1(P) 2 κ1(P)κ2(P) κ2(P) 2   , −−−→ κ(Q)2 =   κ1(Q) 2 κ1(Q)κ2(Q) κ2(Q) 2   , Démonstration. Si on prouve l’existence de telles Bi pour une base particulière {v1, v2} de L(2O), alors le résultat sera vrai pour toutes les autres bases. Il se trouve justement que la proposition 1.3.18 nous donne trois bases différentes satisfaisant cette propriété. La seconde est d’utiliser l’algorithme des elliptic nets : Théorème 3.2.2. Dans le même contexte, κ1 et κ2 vérifient la récurrence des elliptic nets : det (κ1(xi + xj )κ1(xi − xj ))1≤i,j≤4 = det (κ2(xi + xj )κ2(xi − xj ))1≤i,j≤4 = 0. Démonstration. Notons : — A11 et A22 les matrices associées aux applications bilinéaires B11 et B22 établies dans le théorème précédent, — pour 1 ≤ i ≤ 4, −→κi = −−−→ κ(xi)2. On a donc, pour tout 1 ≤ i, j ≤ 4, κ1(xi + xj )κ1(xi − xj ) = t−→κiA11 −→κj . κ2(xi + xj )κ2(xi − xj ) = t−→κiA22 −→κj . Les deux matrices ( t−→κiA11 −→κj ) 1≤i,j≤4 et ( t−→κiA22 −→κj ) 1≤i,j≤4 sont de rang ne dépassant pas 3, et donc de déterminant nul.Fonctions de niveau l (pair) et elliptic nets 63 3.3 Fonctions de niveau l (pair) et elliptic nets D’un point de vue pratique, le cas l = 2 est le plus efficace. Toutefois, il n’est pas compliqué de généraliser les théorèmes 3.2.1 et 3.2.2 aux niveaux plus élevés. Ce sont les deux théorèmes suivants : Théorème 3.3.1. Soit m = l(l + 1)/2. On fixe deux indices 1 ≤ i, j ≤ l. Il existe alors une application bilinéaire Bi,j telle que pour tous P et Q ∈ E l’on ait κi(P + Q)κj (P − Q) + κj (P + Q)κi(P − Q) = Bi,j −−−→ κ(P)2, −−−→ κ(Q)2  , où −−−→ κ(P)2 et −−−→ κ(Q)2 sont les vecteurs colonnes m × 1 : −−−→ κ(P)2 =   κ1(P) 2 . . . κa(P)κb(P) . . . κl(P) 2   , −−−→ κ(Q)2 =   κ1(Q) 2 . . . κa(Q)κb(Q) . . . κl(Q) 2   , Démonstration. Comme précédemment, il suffit d’établir le résultat pour un choix particulier de bases et il sera vrai pour toutes les autres. Et, comme précédemment, les fonctions thêta nous donnent les relations voulues : le résultat se trouve par exemple dans le théorème 1 de [30]. Théorème 3.3.2. Avec les notations précédentes, on a pour tout n > m det (κi(xa + xb)κi(xa − xb))1≤a,b≤n = 0. Démonstration. C’est exactement la même preuve que pour le théorème 3.2.2. Remarque 3.3.3. • Si l est impair, on peut toujours calculer les fonctions de Miller avec les fonctions de niveau l. Par contre, on ne dispose plus du théorème 3.3.1 établissant les formules d’addition pour mes fonctions de niveau l : on est donc privé de tout moyen pour aller chercher la quantité κ1(rP + Q). • Pour l = 2 on a m = 3 et donc, avec n > m, la matrice du théorème 3.3.2 est de taille au moins 4 : on retombe bien sur la définition des elliptic nets. Si l > 2 par contre, on obtient un résultat moins fort, qui nécessite de prendre des matrices de plus grande taille, et donnent donc des formules plus compliquées à utiliser.64 Unification de ces deux méthodes 3.4 Fonctions de niveau l (toujours pair) et hypelliptic nets Jusqu’ici dans ce chapitre, j’ai travaillé en genre 1 : c’est la situation la plus courante en cryptographie, et c’est la plus simple à comprendre. En réalité, les résultats s’étendent de façon immédiate au cas hyperelliptique. J’énonce donc ici les équivalents des théorèmes 3.3.1 et 3.3.2. Dans cette section, je travaille donc sur une courbe C de genre g. Je me donne un entier l ≥ 2 pair, et {κ1, . . . , κl 2 } une base de L(lΘ). Théorème 3.4.1. On pose m = l g (l g + 1)/2. On fixe deux indices 1 ≤ i, j ≤ l g . Il existe une application bilinéaire Bi,j telle que pour tous D1 et D2 ∈ J on ait κi(D1 + D2)κj (D1 − D2) + κj (D1 + D2)κi(D1 − D2) = Bi,j −−−−→ κ(D1)2, −−−−→ κ(D2)2  , avec −−−−→ κ(D1)2 et −−−−→ κ(D2)2 les vecteurs m × 1 suivants : −−−−→ κ(D1)2 =   κ1(D1) 2 . . . κa(D1)κb(D1) . . . κl 2 (D1) 2   , −−−−→ κ(D2)2 =   κ1(D2) 2 . . . κa(D2)κb(D2) . . . κl 2 (D2) 2   , Démonstration. Les formules d’addition de Riemann montrent que les fonctions thêta admettent bien de telles relations bilinéaires. Ainsi, par exemple, le théorème 1 de [30] montre que le théorème est vrai pour la base ( θ " 0 b #  z, l−1Ω  | b ∈  1 l Z g /Z g ) . Comme on a démontré le résultat pour une base donnée, il est vrai pour toutes les bases. Théorème 3.4.2. Avec les notations du théorème précédent, κi vérifie ce que j’appelle la récurrence des hyperelliptic nets généralisés : pour tout n > m, det (κi(xa + xb)κi(xa − xb))1≤a,b≤n = 0. Démonstration. Reprenons la démonstration du théorème 3.2.2, et notons : — Aij les matrices associées aux applications bilinéaires Bij établies dans le théorème précédent,Conclusion 65 — pour 1 ≤ a ≤ n, −→κa le vecteur m × 1 −−−−→ κ(Da)2. Autrement dit, pour tout couple (a, b) avec 1 ≤ a, b ≤ l g , et pour tout entier 1 ≤ i ≤ l, la situation est la suivante : κi(Da + Db)κi(Da − Db) = t−→κaAii −→κb . Or, les matrices ( t−→κaAii −→κb ) 1≤a,b≤n , pour tout 1 ≤ i ≤ l, sont de rang ne dépassant pas m, et on a pris soin dans les hypothèses du théorème de prendre ces matrices de taille n > m : leur déterminant est nul. 3.5 Conclusion Dans ce chapitre, on a commencé par voir que la construction des hyperelliptic nets avec la fonction sigma pouvaient se généraliser aux autres fonctions thêta de caractéristiques semi entières. Plus encore, toutes les fonctions de niveau 2 nous fournissent des hyperelliptic nets, tandis que les fonctions de niveau pair supé- rieur aboutissent à une relation plus faible, appelée ici relation des hyperelliptic nets généralisée. Surtout, ce chapitre permet de faire le lien entre l’algorithme des fonctions thêta pour le calcul de couplages, et celui des nets : la formule de récurrence des nets est une conséquence directe des formules d’addition qui sont à la base de l’algorithme des fonctions thêta. Ainsi, pour un même outil (un ensemble de coordonnées de niveau pair), il existe deux méthodes pour le calcul de couplages. Nous avons vu dans le chapitre pré- cédent que, pour les fonctions thêta, les formules d’addition donnaient un algorithme bien plus efficace que la relation des nets. Une question ouverte serait de trouver une famille de coordonnées pour laquelle les formules d’addition sont optimales.66 Unification de ces deux méthodesChapitre 4 Polynômes de sommation 4.1 Introduction La sécurité de l’utilisation des courbes hyperelliptiques en cryptographie repose sur la difficulté du problème du logarithme discret. Les algorithmes pour traiter ce problème sur un groupe G se classent en deux catégories : 1. les algorithmes génériques, c’est-à-dire qui sont valables sur tout groupe ; si G est un groupe cyclique d’ordre premier n, ces algorithmes ont un coût en O( √ n), aussi sont-ils également appelés algorithmes en racine carré ; 2. et puis il y a les algorithmes sous-exponentiels, qui utilisent la structure du groupe étudié pour aller plus vite. Ainsi, pour les courbes elliptiques définies sur une extension Fqn /Fq, Gaudry combina dans [22] les polynômes de sommation de Semaev ([43]) et la descente de Weil pour produire un algorithme de calcul d’index dont la complexité est sousexponentielle. Dans le cas des courbes hyperelliptiques, l’idée générale de l’algorithme de Gaudry reste valable. Malheureusement, jusqu’ici aucun équivalent des polynômes de Semaev ne fût trouvé. Ainsi, Nagao ([36]) passa par les espaces de Riemann-Roch pour exhiber des systèmes polynomiaux à résoudre pour la phase de recherche de relations dans le calcul d’index. Dans ce chapitre, je vais commencer par rappeler la construction des polynômes de sommation par Semaev et leur utilisation par Gaudry pour le calcul d’index. Dans le but d’étendre ces polynômes aux courbes hyperelliptiques, je vais avoir besoin de donner une construction alternative en genre 1, utilisant la fonction sigma de Weierstrass. Je montrerai ensuite l’impact des nouveaux polynômes de sommation hyperelliptique sur le problème du logarithme discret. Enfin, je discuterai de divers choix possibles de polynômes alternatifs. 6768 Polynômes de sommation 4.2 Rappels sur les travaux de Gaudry et Semaev 4.2.1 Cadre général : le calcul d’index Je commence par rappeler le principe général du calcul d’index, avant de considérer spécifiquement le groupe généré par un point P ∈ E(Fq k ). Soit G = hPi un groupe général. La loi de groupe est notée additivement et le neutre désigné O. Soit Q ∈ G, on veut trouver un entier n tel que Q = nP. L’algorithme s’initialise par la construction d’un sous ensemble de G appelé base de factorisation F = {F1, . . . , Fk}. Ce sera plus explicite par la suite, mais F est choisi de façon à ce que — pour tout élément R ∈ G il soit facile de décider si R peut se décomposer R = m1F1 + · · · + mkFk, avec ∀i, mi ∈ Z (4.1) (un tel élément est dit F-friable, ou juste friable) ; — et, lorsque c’est le cas, il soit facile d’exhiber une telle décomposition. En pratique, cette décomposition s’obtient par la résolution d’un système polynomial. L’algorithme de calcul d’index en lui même se déroule en deux étapes : (1) la recherche de relations : On génère aléatoirement des entiers α et β ∈ N, et on construit R = αP + βQ, jusqu’à obtenir un point R qui soit friable, et on calcule alors sa décomposition. On répète l’opération jusqu’à obtenir k + 1 relations ∀i, Ri = αiP + βiQ = X k j=1 mi,jFj , où k est le cardinal de F. On stocke ces relations dans une matrice M = (mij ), qui est donc de taille (k + 1) × k. (2) la phase d0alg`ebre lin´eaire : À part cas exceptionnel (auquel cas on recommence l’étape 1), il y a un vecteur non nul (γi) dans le noyau de M. Un tel vecteur nous donne X i γi(αiP + βiQ) = O.Rappels sur les travaux de Gaudry et Semaev 69 Encore une fois, sauf en cas de malchance, on a P i γiβi 6= 0, ce qui nous permet de déduire : Q = − P i γiαi P i γiβi ! P, où la quantité − P i P γiαi i γiβi  est calculée modulo le cardinal de G. Le coût de la construction de F et de la phase 1 dépend du groupe G et de sa représentation. Plus précisément, l’analyse de l’algorithme prend en compte — le coût de l’arithmétique dans G ; — la probabilité pour un élément R aléatoire d’être friable ; — le coût du test de friabilité ; — le coût du calcul de la décomposition d’un élément friable. Au contraire, la phase d’algèbre linéaire ne dépend que de k. Ainsi, quand k augmente, les relations de la phase 1 s’obtiennent plus rapidement, tandis que la phase 2 devient plus lente. L’idée est donc de trouver k pour équilibrer les coûts des deux phases. 4.2.2 L’algorithme dans le cas des courbes elliptiques et hyperelliptiques Spécifier l’algorithme de calcul d’index pour un groupe G donné, c’est préciser la base de factorisation F, ainsi que la phase de recherche de relations. Dans le cas où G =< P >⊂ E(Fqn ) est généré par un point d’une courbe elliptique, le choix de F fait par Gaudry est F = {R ∈ E(Fqn )| x(R) ∈ Fq}. L’algorithme s’étend aux courbes hyperelliptiques. Dans ce cas, la base de factorisation est F = {D ∼ (P) − (∞)| x(P) ∈ Fq}. Il reste maintenant à expliquer comment tester une relation. Pour le cas hyperelliptique, la solution donnée par Gaudry dans [22] est de calculer le polynôme u de la représentation de Mumford (voir chapitre 1) du diviseur R = αP + βQ, et de tester s’il se scinde totalement dans Fq. Dans le cas elliptique, la méthode la plus rapide est d’utiliser les polynômes de Semaev que j’expose à présent.70 Polynômes de sommation 4.2.3 Polynômes de Semaev Ici, je rapporte les principaux résultats de [43] : la définition des polynômes de sommation et leurs propriétés. On se donne E une courbe elliptique définie sur un corps K de caractéristique différente de 2, dont l’équation de Weierstrass est y 2 = x 3 + Ax + B. Définition 4.2.1 ([43]). Pour tout entier n ≥ 2, le polynôme de sommation Sn ∈ K[X1, . . . , Xn] est défini par la récurrence : S2(X1, X2) =X1 − X2, S3(X1, X2, X3) = (X1 − X2) 2X 2 3 − 2((X1 + X2)(X1X2 + A) + 2B)X3 + ((X1X2 − A) 2 − 4B(X1 + X2)), ∀n ≥ 4, 1 ≤ k ≤ n − 3, Sn(X1, . . . , Xn) = ResX(Sn−k(X1, . . . , Xn−k−1, X), Sk+2(Xn−k, . . . , Xn, X)). L’intérêt de ces polynômes réside dans le théorème suivant : Théorème 4.2.2 ([43]). Soit Sn le n-ième polynôme de sommation de E/K. Soit x1, . . . , xn dans K . Alors Sn(x1, . . . , xn) = 0 si et seulement si il existe y1, . . . , yn dans K tel que pour tout i, Pi = (xi , yi) soit un point de E et P1 + · · · + Pn = O. Remarque 4.2.3. On peut réécrire ce théorème de la façon suivante : ayant les xi tels que Sn(x1, . . . , xn) = 0, le théorème me dit qu’il existe pour chaque i deux choix de yi tels que (xi , yi) soit un point de E (si yi est un de ces choix, l’autre est évidemment −yi). Une fois les bons choix effectués, j’obtiens des points P1, . . . , Pn tels que P1 ± · · · ± Pn = O. On revient à notre algorithme de calcul d’index. Soit R = (xR, yR) un point de E(Fqn ) que l’on veut décomposer comme somme de n points de F. On veut donc résoudre Sn+1(xR, X1, . . . , Xn) = 0, ∀i, Xi ∈ Fq. On décompose alors xR et chacun des coefficients de Sn+1 dans la base {1, t, . . . , tn−1} de Fqn /Fq choisie, et on obtient donc une équation de la forme k X−1 i=0 S (i) n+1(X1, . . . , Xn)t i = 0, où chaque S (i) n+1 est dans Fq[X1, . . . , Xn], soit donc un système de n équations à n indéterminées dans Fq.Nouvelle construction des polynômes de sommation en genre 1 71 4.3 Nouvelle construction des polynômes de sommation en genre 1 Il est maintenant temps pour moi d’exposer mes contributions à ce problème de logarithme discret. Comme énoncé en introduction dans cette partie, je me suis attaché à étendre la notion de polynôme de sommation aux courbes hyperelliptiques. Dans le cas elliptique, Nous avons vu que les polynômes de Semaev sont définis par récurrence via un calcul de résultant. Ceci ne sera plus le cas dans le cas hyperelliptique, aussi ai-je été obligé de réécrire ces polynômes en genre 1 avec d’autres formules, en utilisant la fonction sigma de Weierstrass. La définition et les propriétés élémentaires de cette fonction ont été rappelées au chapitre 1. Je me contenterai donc ici de seulement rapporter les deux théorèmes sur cette fonction que j’utiliserais spécifiquement. 4.3.1 Deux théorèmes fondamentaux Les théorèmes cités ici sont anciens : ainsi, le premier est dû à Weierstrass ([53], [54]), tandis que le second a été énoncé en premier par Frobenius et Stickelberger dans [17]. Théorème 4.3.1 (Loi d0addition). Soit u1, u2 ∈ E. En posant x1 = x(u1) et x2 = x(u2), on a σ(u1 − u2)σ(u1 + u2) σ 2 (u1)σ 2 (u2) =      1 x1 1 x2      . Je rappelle que σ admet un zéro d’ordre 1 uniquement en O. Ce théorème est donc très facile à lire : deux points u1 et u2 vérifient u1 ±u2 = O si et seulement si x1 = x2. De plus, comme la fonction x admet comme seul pôle le point O (et c’est un pôle d’ordre 2), un tel test est possible si et seulement si on a bien vérifié que u1 6= O et u2 6= O. Le théorème suivant est une généralisation du précédent pour n ≥ 2 points : Théorème 4.3.2 (Frobenius-Stickelberger). Soit n ≥ 2 un entier, et u1, . . . , un ∈ E, avec ui = (xi , yi). On a l’égalité72 Polynômes de sommation (−1)(n−1)(n−2)/2 σ(u1 + · · · + un) Q i 1. En effet, je rappelle que la preuve de cette formule est le point (v) de la proposition 4.3.8 : j’utilisais la formule ResX(σ (n−k) (X1, . . . , Xn−k−1, X), σ(k+2)(Xn−k, . . . , Xn, X)) =a m Y i σ (n−k) (X1, . . . , Xn−k−1, αi), où — a = lcX(σ (k+2)(Xn−k, . . . , Xn, X)) = σ (k+1)(Xn−k, . . . , Xn); — les αi sont ses racines ; — m = degX(σ (n−k) (X1, . . . , Xn−k−1, X)) = 2n−k−2 ; et la définition de σ (n) : σ (n) (u1, . . . , un) = Q ∈En σ( · u) ( Qn i=1 σ[(ui))2n−1 . Maintenant, si j’essaye d’imiter cette preuve pour g > 1, je fais face à trois problèmes. Tout d’abord, je n’ai pas de jolie description des αi comme pour le genre 1 (point (iv) de 4.3.8) ; ainsi, les racines de X 7→ σ (n,g) (X1, . . . , Xn−1, X) sont maintenant : {x (P1, 2P2, . . . , nPn + Q1 + · · · + Qg−1)|Qi ∈ C}; dans le cas elliptique, le miracle g − 1 = 0 permettait d’avoir au numérateur de Y i σ (n−k) (X1, . . . , Xn−k−1, αi) = Y i Q  σ(P1 + 2P2 + · · · + n−k−1Pn−k−1 + nαi) Qn−k−1 1 σ(Pj )  σ(αi) la quantité Y  σ( · P). Le second problème est que le degré de σ (n,g) n’est plus 2 n−2 , mais 2 n−2 g. Enfin, troisième problème : si g > 2, σ[ 6= σ.84 Polynômes de sommation 4.4.3 Utilisation pour le calcul d’index Je rappelle que la base de factorisation ici est F = {u = (P) − (∞) ∈ Θ [1]|x(P) ∈ Fq}. On a un point R = aD1 + bD2, pour des entiers a et b choisis aléatoirement, et on veut décider de la décomposition de R dans F. Soient P1, . . . , Pg les points intervenant dans la représentation réduite de R, avec Pi = (xi , yi). On considère le n + g-ième polynôme de sommation σ (n+g,g) , et on veut résoudre le système ( σ (n+g,g) (x1, . . . , xg, Xg+1, . . . , Xg+n) = 0, Xg+1, . . . , Xg+n ∈ Fq. Ici, les xi sont donnés par l’énoncé et mes inconnues sont les n variables Xi . On utilise alors une base de Fqn /Fq pour obtenir un système de n polynômes sur Fq à n variables. On le résout par un calcul de base de Gröbner. Comme Gaudry l’a remarqué pour g = 1, les nouveaux polynômes σ (n+g,g) sont symétriques. On peut donc les exprimer avec les polynômes symétriques élémentaires e1, . . . , en en Xg+1, . . . , Xg+n : on obtient ainsi des polynômes de degré total 2 n+g−2 g. Malheureusement, et contrairement à la situation rencontrée pour g = 1, ré- soudre ce système n’est pas suffisant pour trouver une décomposition de R. En effet, trouver une solution (Xg+1, . . . , Xg+n) signifie que l’on a des points Pg+1, . . . , Pg+n ∈ F (Pi = (Xi , Yi) pour un certain Yi) tel qu’il existe certains points (inconnus) Q1, . . . , Qg−1 avec : P1 ± P2 ± · · · ± Pg+n ∼ Q1 + · · · + Qg−1. A ce point, il reste à traiter les problèmes suivants : (i) Les relations que l’on veut en réalité sont P1 + · · · + Pg ± Pg+1 · · · ± Pg+n ∈ Θ, i.e. les g−1 premiers signes sont imposés comme étant positifs. Cela arrive avec une probabilité 2 1−g . (ii) Même si les signes sont bons, il reste à calculer ces points Qi : on les obtient en calculant tous les diviseurs P1 + · · · + Pg ± Pg+1 · · · ± Pg+n. (iii) Enfin, il faut vérifier si, pour l’un des choix de signes effectués en (ii), l’on a bien x(Qi) ∈ Fq pour tout i. J’illustre maintenant la recherche de relations en genre 2.Extension aux courbes hyperelliptiques 85 4.4.4 Un exemple en genre 2 Je rappelle qu’en genre 2, Θ = {(P)−(∞)} = Θ[1], c’est-à-dire L = Θ[1] ⊂ F. La situation est la suivante : on a un diviseur R = (P1) + (P2) − 2(∞) dont on veut tester la friabilité. Dans cet exemple, on travaille sur Fq 2 avec q = 1048583 et Fq 2 ' Fq(a) , a véri- fiant a 2 + a + 1 = 0. La courbe choisie est définie par y 2 = x 5 + (956 + 16a)x + 560. Comme l’extension est de degré 2, on doit utiliser le g + 2 = 4-ième polynôme de sommation σ (4,2). Si le point que l’on souhaite décomposer est R ∼ (P1) + (P2) − 2(∞), avec P1 = (822466a+1019211, 208059a+779837) et P2 = (964315a+809425, 207076a+760154), dans σ (4,2)(x1, x2, x3, x4), on doit remplacer les inconnues x1 et x2 par les valeurs connues x(P1) et x(P2) respectivement. On obtient alors un polynôme symétrique en x3 et x4. Si on l’exprime en fonction des polynômes symétriques élémentaires e1 = x3 + x4 et e2 = x3x4, on obtient quelque chose qui commence comme e 8 1 − (86278a + 469901)e 7 1 e2 + (413036a + 304842)e 7 1 + · · · = 0. Remarquons que le degré total de ce polynôme est bien 2 n−2 g = 8. Comme on veut des solutions dans Fq, cette équation est équivalente au système ( e 8 1 − 469901e 7 1 e2 + · · · = 0, −86278e 7 1 e2 + · · · = 0. Après calcul de la base de Gröbner de ce système, on obtient les quatre couples de solutions {(48993, 5391),(−890, 86741),(−72562, −313),(145643, 17928)}, et finalement, les solutions dans Fq sont (x3, x4) ∈ {(97763, 999813),(47880, 999813),(97763, 47880),(640319, 335702)}. On calcule les points P3 et P4 correspondants, et on voit que les trois premiers couples nous donnent effectivement une décomposition de R : R ∼ (47880, 467662a+247545)+(999813, 350820a+258681)+(97763, 7563a−232022), alors que le dernier couple nous donne une décomposition de −(P1)+(P2)−2(∞), ce dont on n’a pas besoin.86 Polynômes de sommation 4.4.5 Complexité On retourne au cas g quelconque pour analyser le coût de la recherche de relations avec ces polynômes de sommation hyperelliptiques. On considère donc une courbe C de genre g définie sur un corps fini Fqn , et on veut décomposer un élément R ∼ (P1) + · · · + (Pg) − g(∞) ∈ J en somme de n points de F. On doit ainsi utiliser le polynôme σ (n+g,g) ∈ Fqn [X1, . . . , Xg+n]. Comme expliqué dans l’exemple précédent en genre 2, on remplace les g premières variables de σ (n+g,g) par les xi = x(Pi) fournis par R, et on obtient alors, après symétrisation, un système de n équations polynomiales sur Fq en n variables de degré total 2 n+g−2 g. Dans sa thèse ([52], section 7.2.2), Vitse étudie le coût d’un test de décomposition d’un point R en utilisant les polynômes de sommation elliptiques. En suivant son analyse, j’obtiens le résultat suivant : Proposition 4.4.9. En notant c(g, n, q) le coût d’un test de décomposition d’un point R ∈ J de la jacobienne d’une courbe de genre g en la somme de n points de la base de factorisation F, on a c(g, n, q) = O˜(23n(n+g−2)g 3nn) quand q → ∞. Démonstration. En fait, c(g, n, q) correspond au coût de la résolution du système polynomial sur Fq obtenu à partir de la relation σ (n+g,g) (x1, . . . , xg, Xg+1, . . . , Xg+n) = 0. Cette résolution se fait par un calcul de bases de Gröbner. La stratégie usuelle est en deux temps : d’abord utiliser l’algorithme F4 de Faugère pour calculer une base pour l’ordre degrevlex, puis appliquer l’algorithme de changement d’ordre FGLM pour en déduire une base pour l’ordre lexicographique. Ces algorithmes ont été proposés respectivement dans [15] et [16]. Pour estimer c(g, n, q), il faut regarder la complexité de ces deux étapes. Sans rentrer dans les détails, la complexité du calcul d’une base de Gröbner d’un idéal I = hf1, . . . , fN i de dimension zéro d’un anneau de polynômes K[X1, . . . , XN ] avec l’algorithme F4 est majorée par O˜ N + dreg N !ω! ,Extension aux courbes hyperelliptiques 87 où le degré de régularité dreg est majoré par la borne de Macaulay dreg ≤ X i (deg(fi) − 1) + 1, et ω est l’exposant intervenant dans la complexité du produit matriciel. Ici, on a N = n et la borne de Macaulay donne dreg ≤ n2 n+g−2 g − n + 1. Après utilisation de la formule de Stirling, on trouve finalement une complexité en O˜ 2 n(n+g−2)g n e nn −1/2 ω . On passe maintenant à la complexité de l’algorithme de changement d’ordre F GLM. Pour un idéal de degré D de polynômes à N variables, elle est de O(ND3 ). Le degré D peut s’estimer par la borne de Bézout : dans notre cas, l’idéal est généré par n polynômes, tous de même degré 2 n+g−2 g, ce qui nous donne la majoration suivante D ≤ 2 n(n+g−2)g n . La coût de cette étape est donc O(23n(n+g−2)g 3nn). Comme le coût de la seconde étape domine celui de la première, c’est lui qui donne l’estimation de c(g, n, q). Maintenant qu’on a obtenu le coût c(g, n, q) d’une utilisation des polynômes hyperelliptiques de sommation, il s’agit d’estimer le coût global de la méthode de calcul d’indice. Pour cela, il est nécessaire d’estimer : — le cardinal de la base de factorisation (puisque le but est d’obtenir plus de relations qu’il n’y a d’éléments dans cette base) ; — la probabilité qu’un diviseur choisi aléatoirement se décompose dans la base. Pour estimer ces quantités, nous continuons de suivre la thèse de Vitse ([52], section 7.2.3) : la base de factorisation contient environ q/2 points, quand q est88 Polynômes de sommation suffisamment grand, tandis qu’une analyse heuristique donne une probabilité de décomposition de l’ordre de : ]C ng/ Sng ]F = 1 (ng)!. Il faut maintenant faire attention au fait que les polynômes de sommation hyperelliptiques ne testent pas la nullité d’une somme, mais seulement sa présence dans le diviseur Θ. Pour plus de clarté, reprenons notre exemple de la section 4.4.3 : partant d’un diviseur R = P1+· · ·+Pg que l’on veut décomposer, l’utilisation de σ (n+g,g) permet d’obtenir les abscisses xg+1, . . . , xg+n de n points Pg+1, . . . , Pg+n nous donnant la relation P1 + · · · + Pg+n ∈ Θ, c’est-à-dire P1 + · · · + Pg+n ∼ Q1 + · · · + Qg−1, pour certains points Qi inconnus de la courbe C. Cela aboutit à une relation à la double condition que tous les xi soient dans Fq, puis que tous les x(Qi) soient également dans Fq. Selon l’analyse heuristique citée plus haut, la première condition est vérifiée avec une probabilité 1/(g + n)!. Quant à la seconde, les g − 1 quantités x(Qi) sont à priori dans Fqn , et on leur demande à être dans Fq : ceci arrive avec une probabilité en q (1−n)(1−g) . Ainsi, pour obtenir de l’ordre de q/2 relations, il faudra résoudre en moyenne (g+n)!(g−1)!q/2 systèmes polynomiaux provenant des polynômes de sommation, et, finalement, le coût global de la méthode est de l’ordre de O˜  q (1+(n−1)(g−1))2 3n(n+g−2)g 3nn(g + n)! quand q → ∞. 4.5 Constructions alternatives Faisons le point : en réécrivant la théorie de Semaev, j’ai pu étendre ses polynômes de sommation aux courbes hyperelliptiques. Ces nouveaux polynômes méritent effectivement le nom de polynômes de sommation hyperelliptiques, en référence aux polynômes de sommation de Semaev, car : — comme dans le genre 1, ils permettent de trouver des relations pour l’algorithme de calcul d’index ; — comme dans le genre 1, ils ne dépendent que de la coordonnée x des points de la courbe ;Constructions alternatives 89 — si on remplace g par 1 dans mes σ (n,g) , on retrouve bien les polynômes de Semaev. Dans cette section, je m’intéresse maintenant à l’étude de polynômes de sommation alternatifs. En particulier, j’expliquerai pourquoi ces polynômes sont moins performants que ceux que j’ai précédemment exposés. Dans un premier temps, je m’attaque à deux défauts de mes polynômes : ils sont chers à calculer, car ils nécessitent la multiplication de 2 n−1 déterminants de taille n ; et ils ne détectent une relation qu’avec une probabilité 2 1−g . En multipliant moins de déterminants, pourrait on obtenir des polynômes de sommation plus efficaces ? Dans un second temps, je donne mes résultats sur une question soulevée par Guénaël Renault lors d’un exposé à Rennes que je réécris de la façon suivante : pour tester des égalités de type R + P1 + · · · + Pn = O sur une courbe E, peut on utiliser une coordonnée c et un automorphisme Ψ de E tels que πc(E) ∼ E/Ψ pour obtenir des polynômes de sommation dépendant uniquement des c(Pi) ? Ainsi, dans le cas des polynômes de Semaev, l’automorphisme Ψ est simplement [−1] : (x, y) 7→ (x, −y) et ma coordonnée c est x. 4.5.1 Peut-on utiliser moins de fonctions ∆n,g ? Considérons par exemple le polynôme σ (3,2). Pour le construire, on doit multiplier au numérateur ∆3,2(P1, P2, P3) × ∆3,2(P1, −P2, P3) × ∆3,2(P1, P2, −P3) × ∆3,2(P1, −P2, −P3). Mais, parmi ces déterminants, seulement la moitié nous sont utiles : ∆3,2(P1, P2, P3) × ∆3,2(P1, P2, −P3) = 0 ⇔ P1 + P2 ± P3 ∈ Θ, tandis que les deux autres nous donnent de mauvaises relations : ∆3,2(P1, −P2, P3) × ∆3,2(P1, −P2, −P3) = 0 ⇔ P1 − P2 ± P3 ∈ Θ. Remarque 4.5.1.90 Polynômes de sommation — Cet exemple est un peu artificiel : j’ai déjà expliqué que pour g = 2, le premier polynôme de sommation intéressant était σ (4,2). Pour des n plus grands, ce sont exactement les mêmes idées qui entrent en jeu. La seule différence est que de tels exemples sont plus longs à écrire. — Pour g = 1, il ne se passe rien du tout : les nouveaux polynômes que je vais construire σ˜ (n,g) sont alors égaux à σ (n,g) . Je rappelle que pour g = 1, on avait démontré le lemme de réduction 4.3.4. Pour le cas général, ce lemme est démontré dans la preuve du théorème 4.4.7. En utilisant ce lemme, j’obtiens la construction suivante de polynômes σ˜ (n,g) alternatifs : Théorème 4.5.2. Soit n ∈ N, et soient P1, . . . , Pg+n ∈ C. On veut décomposer le diviseur R = (P1) + · · · + (Pg) − g(∞) . On doit considérer séparément les cas n = 2 et n > 2 : • si n = 2, on considère la fonction σ˜ (g+2,g) construite ainsi : ∆g+2,g(R, Pg+1, Pg+2)∆g+2,g(R, Pg+1, −Pg+2)∆g+2,g(R, −Pg+1, Pg+2)∆g+2,g(R, −Pg+1, −Pg+2) ∆2(Pg+1, Pg+2) Q i6=g+1 i6=g+2 ∆2(Pg+1, Pi)∆2(Pg+2, Pi) !2 . C’est un polynôme en xg+1 et xg+2. Il est symétrique et est de degré 2g en chaque variable. • si n > 2, la fonction est σ˜ (n+g) (R, Pg+1, . . . , Pg+n) = Q ∈{±1}n ∆n+g,g(P1, . . . , Pg, 1Pg+1 + · · · + nPg+n) Q i6=g+1 ∆2(Pg+1, Pi) 2n−1 . C’est un polynôme en les xi (g + 1 ≤ i ≤ g + n). Il n’est pas symétrique. Il est de degré 2 n−1 (2g + n − 2) en chaque xi pour i ≤ g + 2, et de degré 2 n−1 g en xg+1. Démonstration. A priori, les deux quantités évoquées dans ce théorème sont des fonctions rationnelles en les xi et les yi . Il faut d’abord voir que ce sont en fait des fonctions rationnelles ne dépendant que des xi (c’est le second point du lemme), puis que ce sont en fait des polynômes (c’est le troisième point du lemme). Remarque 4.5.3. On ne peut pas utiliser moins de déterminants que les 2 n impliqués dans la construction de σ˜ (g+n,g) . En effet, sans eux, on ne peut plus utiliser correctement le lemme de réduction 4.3.4 afin de se débarrasser des variables yi.Constructions alternatives 91 Ainsi, sauf pour n = 2, le défaut de symétrisation des nouveaux σ˜ (g+n,g) les rend inutilisables. En effet, après symétrisation, les polynômes σ (g+n,g) sont de degré total 2 n+g−2 g, contre 2 n−1 ((2n − 1)g + (n − 2)(n − 1)) pour les σ˜ (g+n,g) . Pour n = 2 par contre, σ˜ (g+2,g) est plus efficace que σ (g+2,g) : en effet, ils sont tous les deux symétriques, mais le premier est de degré 2g alors que le second est de degré 2 g g. 4.5.2 Cas elliptique : peut on utiliser un autre automorphisme que [−1] ? Comme énoncé dans l’introduction de cette section, l’idée est d’utiliser une coordonnée c et un automorphisme ξ de E tels que πc(E) ' E/ξ. À partir de c et ξ, je veux obtenir des polynômes de sommation σˆ (n) alternatifs : Définition 4.5.4. J’appelle polynômes de sommation relatifs à c des polynômes σˆ (n) ∈ K[C1, . . . , Cn] tels que σˆ (n) (c1, . . . , cn) = 0 ⇔ ∃ Pi ∈ E tq c(Pi) = ci , ∃ i2, . . . , in ∈ N, P1 + [ξ i2 ]P2 + · · · + [ξ in ]Pn = O. Dans le cadre du calcul d’index, la base de factorisation à considérer devient naturellement {P ∈ E(Fq k ) | c(P) ∈ Fq}. Remarque 4.5.5. Cette section est basée sur les résultats de [14]. Plus précisé- ment, dans cet article, les auteurs ont construit les polynômes que j’appelle σˆ (2) et σˆ (3) de mes théorèmes 4.5.7, 4.5.11, 4.5.12 et 4.5.4 (il s’agit des propositions 5.1, 5.4 et 6.2 de [14]). La construction de σˆ (n) pour tout n n’était pas le but de leurs travaux, et fait donc l’objet d’un travail original de ma part. 4.5.2.1 Quels automorphismes ? Je me place en caractéristique 6= 2, 3. Je rappelle (voir [42] par exemple) que92 Polynômes de sommation Aut(E) '    µ2 si j 6= 0, 1728 µ4 si j = 1728 µ6 si j = 0, avec [ξ](x, y) = (ξ 2x, ξ3 y). Ainsi, dans le cas j 6= 0, 1728, nous n’avons rien de plus que l’automorphisme [−1] utilisé par Semaev, avec la coordonnée c = x. 4.5.2.2 Le cas j = 1728 Le modèle de Weierstrass de E est y 2 = x 3 + Ax. Si on fixe i racine carrée de −1, les deux nouveaux automorphismes qu’on obtient sont (x, y) 7→ (−x, ±iy). Autrement dit, on a c = x 2 . On considère le polynôme suivant : f(x1, . . . , xn) = Y σ (n) (x1, ±x2, . . . , ±xn). Ce polynôme vérifie presque la définition 4.5.4 : f(x1, . . . , xn) = 0 signifie qu’il existe des points Pi = (xi , yi) ∈ E tels que P1 ± [ξ] i2P2 ± · · · ± [ξ] in Pn = O, où [ξ](x, y) = (−x, iy). Remarque 4.5.6. La racine carrée de −1, i, ne devra pas être confondue avec les entiers 0 ≤ ik ≤ 3. Il ne manque donc plus qu’une chose à montrer pour que f rentre bien dans le cadre de la définition : le fait que f soit un élément de K[x 2 1 , . . . , x2 n ], c’est-à-dire que, comme fonction de x1, . . . , xn, f soit paire. Cela se fait en trois étapes : — d’abord on montre que f est paire en tant que fonction en x2 ; — en remarquant que f est symétrique en x2, . . . , xn, on obtient alors gratuitement la parité en x3, . . . , xn ; — enfin on montre séparément la parité en x1. Pour la parité en x2, il n’y qu’à écrire : f(x1, −x2, . . . , xn) = Y  σ (n) (x1, −2x2, 3x3 . . . , nxn) = Y  0 σ (n) (x1, 0 2x2, 0 3x3 . . . , 0 nxn) = f(x1, x2, . . . , xn),Constructions alternatives 93 où  = (2, . . . , n) et  0 = (−2, . . . , n). Pour x1, on va devoir développer l’expression de f : f(x1, x2, . . . , xn) = Y σ (n) (x1, ±x2, . . . , ±xn) = Y σ (n) (P1, [ξ] i2P2, . . . , [ξ] in Pn) = Y ik∈{0,1}   Q k∈{±1} ∆n(P1, 2[ξ] i2P2, . . . , n[ξ] in Pn) Q j>1 (∆2(P1, [ξ] ijPj ))4n−2 Q 2≤k1 Y ij∈{0,1}  ∆2(P1, [ξ] ijPj ) 4 n−2 = Y j      1 x1 1 xj      ·      1 x1 1 −xj      !4 n−2 =   Y j (x 2 j − x 2 1 )   4 n−2 . En particulier, c’est bien un polynôme en c1, . . . , cn. On traite de même la seconde partie du dénominateur : Y k1  ∆2(P1, [ξ] ijPj ) 6 n−2 Y 2≤k1 Y ik∈{0,1,2}  ∆2(P1, [ξ] ik Pk) 6 n−2 = Y k      1 x1 1 xk      ·      1 x1 1 Jxk      ·      1 x1 1 J 2xk      !6 n−2 =   Y j (x 3 j − x 3 1 )   6 n−2 =   Y j (y 2 j − y 2 1 )   6 n−2 car on rappelle que y 2 = x 3 + B. On effectue ensuite un travail similaire pour la seconde moitié du dénominateur et on a notre égalité. Ensuite, avec exactement les mêmes arguments que pour 4.5.7, on voit que cette quantité est bien symétrique en P2, . . . , Pn, et qu’elle permet bien de tester les égalités voulues : P1 + [ξ i2 ]P2 + · · · + [ξ in ]Pn = O, pour l’automorphisme [ξ] : (x, y) 7→ (Jx, −y). Enfin il reste à voir que c’est bien un polynôme en ci = y 2 i . Si on note provisoirement f(P1, . . . , Pn) = Y 0≤ik≤5 σ (n) (P1, [ξ] i2P2, . . . , [ξ] in Pn), ceci revient à dire que f(P1, . . . , Pn) = f([ξ]P1, . . . , Pn) = · · · = f([ξ] 5P1, . . . , Pn), d’une part, et f(P1, P2 . . . , Pn) = f(P1, [ξ]P2, . . . , Pn) = · · · = f(P1, [ξ] 5P2, . . . , Pn) d’autre part : la symétrie en (P2, . . . , Pn) permettra de conclure.Constructions alternatives 97 Ceci se traite exactement comme pour 4.5.7 : la dépendance en c1 se résout en considérant le produit Y k∈{±1} 0≤ik≤5 ∆n(P1, 2[ξ] i2P2, . . . , n[ξ] in Pn) qui apparaît au numérateur du développement de f, tandis que la dépendance en c2 se voit directement dans l’expression f(P1, . . . , Pn) = Y 0≤ik≤5 σ (n) (P1, [ξ] i2P2, . . . , [ξ] in Pn). Mais il existe encore une autre construction possible de polynômes de sommation, cette fois-ci relatifs à la variable c = y. Elle est inspirée de [14]. Théorème 4.5.12. • Pour n = 2, on a l’égalité σ(P + Q)σ(P + [ξ]Q)σ(P + [ξ 2 ]Q) σ(P) 3σ(Q) 3 = yP − yQ. Ceci est le second polynôme de sommation relatif à c = y. Pour comparer avec le second point, on pourra remarquer qu’il est de degré 3 2−2 = 1 en yQ. • Soit n > 2. Soient P1, . . . , Pn ∈ E de coordonnées (xi , yi). Pour 2 ≤ k ≤ n, soit 0 ≤ ik ≤ 2 un entier. On a alors l’égalité Q 0≤ik≤2 σ(P1 + [ξ] i2P2 + · · · + [ξ] in Pn) ( Qn i=1 σ(ui))3n−1 = Q 0≤ik≤2 ∆n(P1, [ξ] i2P2, · · · + [ξ] in Pn) Q i1 (∆2(P1, [ξ] ijPj ))(2r)n−2 Q 2≤k1 Y 0≤ik≤r−1  ∆2(P1, [ξ] ik Pk) (2r) n−2 = Y k Y ik      1 x1 1 (ξ) 2ik xk      !(2r) n−2 = Y k (x r k − x r 1 ) !(2r) n−2 = Y k (c 2 j − c 2 1 ) !(2r) n−2 On effectue ensuite un travail similaire pour la seconde moitié du dénominateur et on a notre égalité.104 Polynômes de sommation Maintenant que l’égalité est démontrée, il s’agit de voir que cette quantité nous donne bien le n-ième polynôme relatif à la variable c, c’est-à-dire que c’est un polynôme en les ci qui permet de tester les égalités P1 ± [ξ] i2 ± · · · ± [ξ] in Pn ∈ Θ. Pour le moment, notons f(P1, . . . , Pn) cette quantité. Le fait que f permette de tester les égalités voulues provient simplement de la définition de σ (n,g) . A priori, grâce au membre de gauche de l’égalité définissant f, on sait qu’il s’agit d’un polynôme en x1, . . . , xn. Il faut voir qu’en réalité c’est un polynôme en les ci . Pour cela, montrons dans un premier temps que, vis-à-vis de P1 et de P2, f ne dépend que des variables c1 et c2. Ceci revient à dire que f(P1, . . . , Pn) = f([ξ]P1, . . . , Pn) = · · · = f([ξ] 2r−1P1, . . . , Pn), d’une part, et f(P1, P2 . . . , Pn) = f(P1, [ξ]P2, . . . , Pn) = · · · = f(P1, [ξ] 2r−1P2, . . . , Pn) d’autre part. La dépendance en c1 se résout en considérant le produit Y k∈{±1} 0≤ik≤2r−1 ∆n(P1, 2[ξ] i2P2, . . . , n[ξ] in Pn) qui apparaît au numérateur du développement de f, tandis que la dépendance en c2 se voit directement dans l’expression f(P1, . . . , Pn) = Y 0≤ik≤2r−1 σ (n) (P1, [ξ] i2P2, . . . , [ξ] in Pn). Grâce au membre de droite de l’égalité, on voit que f est symétrique en P2, . . . , Pn. Ceci permet de conclure que f est bien un polynôme en les ci . Enfin il ne reste plus qu’à démontrer le degré. Fixons un indice i. On a degxi σ (n,g) = 2 n−2 g. Pour construire f, il faut, d’après le terme de gauche de l’égalité, multiplier r n−1 tels polynômes, d’où degxi f = (2r) n−2 rg. Pour avoir le degré en ci , il suffit de diviser cette quantité par r.Constructions alternatives 105 Remarque 4.5.21. • Il ne semble pas y avoir d’équivalent au théorème 4.5.12 pour g > 1, ni de résultat pour s 6= 1. • Les deux modèles de courbes qu’on considère sont y 2 = x 2g+1 + µ1x et y 2 = x 2g+1 + µ0. • Si g > 1, la formule du résultant est fausse pour σˆ (n,g) , et ce pour les mêmes raisons qu’elle était fausse pour σ (n,g) . 4.5.4 Analyse et comparaisons Dans cette section, nous devons discuter de l’efficacité de ces polynômes de sommation alternatifs, relatifs à d’autres choix de coordonnées c que le choix initial c = x fait par Semaev. Il s’agit ainsi de reprendre l’analyse faite dans la proposition 4.4.9, et de l’adapter à ces nouveaux polynômes. Dans cette proposition, je rappelle qu’on avait noté c(g, n, q) le coût de la résolution du système polynomial sur Fq obtenu à partir de la relation σ (n+g,g) (x1, . . . , xg, Xg+1, . . . , Xg+n) = 0. Remarque 4.5.22. Dans cette section, on prendra garde de ne pas confondre la lettre c qui désigne une variable et la lettre gothique c qui désigne un coût. Proposition 4.5.23. On est dans la situation et avec les notations du théorème 4.5.20. On considère donc le polynôme de sommation suivant : σ˜ n+g,g(c2, . . . , cn+g) = Y 0≤ik≤r−1 σ (n,g) (P1, [ξ] i2P2, . . . , [ξ] in+gPn+g). Le coût de la résolution du système polynomial sur Fq déduit de la relation σ˜ n,g(c2, . . . , cn+g) = 0 est noté c 0 (g, n, q) et vaut O˜((2r) 3n(n+g−2)g 3nn) quand q → ∞. Démonstration. On rappelle qu’un tel coût est directement lié au nombre de variables (ici n : ce sont cg+1, . . . , cg+n) et au degré des polynômes du système à résoudre (ici (2r) g+n−2 g, soit 4 g+n−2 g g+n−1 ou (4g+2)g+n−2 g selon la valeur de r). Suivons maintenant les mêmes étapes que dans la démonstration de la proposition 4.4.9. On commence donc par une utiliser la borne de Macaulay pour estimer le degré de régularité. Ici dreg ≤ n(2r) n+g−2 g − n + 1. Muni de ce premier résultat, on peut estimer le coût de l’utilisation de l’algorithme F4 pour calculer une base de Gröbner pour l’order degrevlex : ce coût est majoré par O˜ n + dreg n !ω! .106 Polynômes de sommation Utilisant le fait que n soit négligeable devant n + dreg et la formule de Stirling, ce coût devient O˜ (2r) n(n+g−2)g n e nn −1/2 ω . Il s’agit maintenant d’étudier la complexité de l”algorithme de changement d’ordre F GLM. Pour cela, on commence par utiliser la borne de Bézout pour majorer le degré D de l’idéal polynomial que l’on souhaite étudier : D ≤ (2r) n(n+g−2)g n . Le coût de cette étape est alors O((2r) 3n(n+g−2)g 3nn). Comme le coût de la seconde étape domine celui de la première, c’est lui qui donne l’estimation de c 0 (g, n, q). Je rappelle qu’avec les polynômes de sommation classiques, le coût était de O˜(23n(n+g−2)g 3nn) : ainsi, l’utilisation des polynômes alternatifs aboutit à des systèmes dont la résolution est environ r 3n(n+g−2) plus chère, avec r qui est de l’ordre de 2g. D’un autre côté, il faut tenir compte du fait que ces nouveaux polynômes dé- tectent r fois plus de relations. En effet, avec les polynômes de sommation classiques, on recherchait les relations du type D1 ± D2 + · · · ± Dg+n ∈ Θ, tandis que les nouveaux polynômes recherchent plus de relations : σˆ (n) (c1, . . . , cg+n) = 0 ⇔ D1 + [ξ i2 ]D2 + · · · + [ξ ig+n ]Dg+n ∈ Θ, pour les indices ik dans {0, . . . , 2r}. Ainsi, utiliser les polynômes alternatifs permet de devoir tester r fois moins de relations avant d’en trouver une, mais chaque relation devient r 3n(n+g−2) fois plus chère à tester : très clairement, ces nouveaux polynômes ne sont pas du tout compétitifs par rapport aux polynômes de sommation classiques.Conclusion 107 Exemple 4.5.24. Regardons la situation en genre 1 sur les courbes de j invariant 1728, c’est-à-dire d’équation de Weierstrass y 2 = x 3 + Ax. Si on a un point R ∈ E(Fqn ) de la courbe à décomposer, on peut utiliser le polynôme de Semaev σ n+1(xR, x1, . . . , xn), qui s’annule sur les abscisses des points Pi vérifiant R ± P1 ± · · · ± Pn = O; ou bien on peut utiliser le polynôme σˆ n+1 = Y σ (n) (x1, ±x2, . . . , ±xn), qui détecte les relations du type R + [ξ i1 ]P1 + [ξ i2 ]P2 + · · · + [ξ in ]Pn = O, avec les ik dans {0, . . . , 3}. En rappelant que [ξ i ]P =    P si i = 0 P 0 si i = 1 −P si i = 2 −P 0 si i = 3 avec P 0 = (−x, iy) quand P = (x, y), on voit qu’effectivement σˆ n+1 détecte 2 fois plus de relations que σ n+1 . D’un autre côté, comme σ n+1 est de degré 2 n−1 tandis que σˆ n+1 de degré 4 n−1 , utiliser σˆ n+1 entraîne un surcoût très important : chaque test de relation coûte 2 3n(n−1) fois plus. 4.6 Conclusion Le but premier de de chapitre était la généralisation des polynômes de Semaev aux courbes hyperelliptiques. Celle ci passe par une réécriture de ces polynômes de sommation comme produit de déterminants. En effet, la construction initiale de Semaev était basée sur une formule de résultants, qui n’est plus valide en genre supérieur à 1. Une fois ces polynômes de sommation hyperelliptiques construits, on a pu étudier leurs propriétés : symétrie, degré, impact sur le coût de la recherche de relations. Suite à cela, j’ai également cherché à construire des polynômes de sommation alternatifs, non plus rattachés à l’automorphisme de degré 2 (x, y) 7→ (x, −y), mais à d’autres automorphismes de degré 2r. L’idée sous jacente à cette recherche est la suivante : plus le degré de l’automorphisme est élevé, plus le nombre de relations détectés par l’égalité σˆ (n+g) = 0 est important. Malheureusement, l’analyse montre que finalement le trop haut degré de ces nouveaux polynômes les rend inutilisables.108 Polynômes de sommationBibliographie [1] J. Adleman, J.DeMarrais, et M. Huang. A subexponential algorithm for discrete logarithms over the rational subgroup of the Jacobians of large genus hyperelliptic curves over finite fields. Leonard M. Adleman and Ming-Deh Huang, editors, Algorithmic Number Theory, volume 877 of Lecture Notes in Computer Science, pp 28–40, Berlin, 1994. Springer-Verlag. [2] R. Avanzi. Aspects of Hyperelliptic Curves over Large Prime Fields in Software Implementations , Cryptographic Hardware and Embedded Systems - CHES 2004, Lecture Notes in Computer Science Volume 3156, 2004, pp 148-162 [3] R. Avanzi, H. Cohen, C. Doche, G. Frey, T. Lange, K. Nguyen and F. Vercauteren. Handbook of elliptic and hyperelliptic curve cryptography, Discrete mathematics and its applications, 2005. [4] J. Balakrishnan, J. Belding, S. Chisholm, K. Eisenträger, K. Stange et E.Teske. Pairings on hyperelliptic curves, CoRR Vol. abs/0908.3731, 2009. [5] I. Blake, G. Seroussi, N. Smart. Advances in elliptic curve cryptography. London Mathematical Society Lecture Note Series 317, Cambridge University press (2005), pp. 183-212. [6] D. Boneh et M. Franklin, “Identity-based encryption from the Weil pairing, Advances in Cryptology – CRYPTO 2001, Lecture Notes in Computer Science, 2139 (2001), 213–229. [7] D. Boneh, B. Lynn et H. Shacham, Short signatures from the Weil pairing, Advances in Cryptology – ASIACRYPT 2001, Lecture Notes in Computer Science, 2248 (2001), 514–532. [8] E. Brown et B. T. Myers. Elliptic curves from Mordell to Diophantus and back (se trouve à l’adresse : http://www.math.vt.edu/people/brown/doc/ dioellip.pdf). [9] V. Buchstaber et V. Enolskii. Explicit Algebraic Description of Hyperelliptic Jacobians on the Basis of the Klein σ-Functions, Functional Analysis and Its Applications, Vol. 30, No. 1, 1996. [10] V. Buchstaber, V. Enolskii, et D. Leykin, A Recursive Family of Differential Polynomials Generated by the Sylvester Identity and Addition Theorems for 109110 Bibliographie Hyperelliptic Kleinian Functions, Functional Analysis and Its Applications, Vol. 31, No. 4, 1997. [11] D. Cantor. Computing in the Jacobian of a hyperelliptic curve. Mathematics of computation 48 (1987), no. 177, 95-101. [12] A. Devegili, C.hEigeartaigh, M. Scott, R. Dahab. Multiplication and squaring on pairing-friendly fields. Cryptology ePrint Archive, Report 2006/471 [13] J. Eilbeck, M. England, Y. Ônishi. Abelian functions associated with genus three algebraic curves , LMS J. Comput. Math., vol. 14 (2011), pp.291-326. [14] J.C. Eilbeck, S. Matsutani, Y. Onishi. Addition formulae for abelian functions associated with specialized curves, Phil. Trans. R. Soc., A2011 369, février 2011. [15] J-C Faugère. A new efficient algorithm for computing Gröbner bases (F4). Journal of Pure and Applied Algebra, 139(1–3) :61–88, June 1999. [16] J-C Faugère, P. Gianni, D. Lazard et T. Mora. Efficient computation of zero-dimensional Gröbner bases by change of ordering. Journal of Symbolic Computation, 16(4) :329–344, 1993. [17] F. Frobenius et L. Stickelberger, Zur Theorie der elliptischen Functionen, J. reine angew. Math. 83 (1877), 175–179. [18] W. Fulton. Algebraic curves. Math. Lec. Note Series, W. A. Benjamin Inc, 1969 [19] S. Galbraith, F. Hess et F. Vercauteren. Hyperelliptic pairings, Pairing-Based Cryptography -Pairing 2007, Lecture Notes in Computer Science Volume 4575, 2007, pp 108-131 . [20] R. Granger, F. Hess, R. Oyono, N. Thériault et F. Vercauteren, Ate pairing on hyperelliptic curves, Advances in Cryptology - Eurocrypt 2007, LNCS, vol. 4515, Springer-Verlag, 2007, pp. 419–436. [21] P. Gaudry. Fast genus 2 arithmetic based on theta functions, J.Math.Cryptol.1 (2007), 243–265. [22] P. Gaudry. Index calculus for abelian varieties of small dimension and the elliptic curve discrete logarithm problem, Journal of Symbolic Computation, vol. 44, no. 12, pp. 1690-1702, 2009. [23] P. Gaudry, E. Thome, N. Theriault, C. Diem. A double large prime variation for small genus hyperelliptic index calculus, Mathematics of computation, vol. 76, pp. 475-492, 2007. [24] P. Hewitt. A brief history of elliptic curves, notes de cours (se trouve à l’adresse : http://livetoad.org/Courses/Documents/132d/ Notes/history_of_elliptic_curves.pdf) [25] A. Joux. A one round protocol for tripartite Diffie-Hellman, Algorithmic Number Theory :4th International Symposium, ANTS-IV, Lecture Notes in Computer Science, 1838 (2000), 385–393.Bibliographie 111 [26] A. Koblitz, N. Koblitz, A. Menezes. Elliptic curve cryptography : The serpentine course of a paradigm shift, Journal of Number theory, vol. 131, issue 5 (2011), pp 781-814. [27] N. Koblitz, Hyperelliptic cryptosystems, J. Cryptology, 1 (1989), pp. 139- 150. [28] N. Koblitz, A. Menezes, Pairing-based cryptography at high security levels, Proceedings of Cryptography and Coding 2005, volume 3796 of LNCS, pp. 13-36. [29] T. Lange, Formulae for Arithmetic on Genus 2 Hyperelliptic Curves, Applicable Algebra in Engineering, Communication and Computing, vol. 15 (2003), pp. 295-328. [30] D. Lubicz, D. Robert. Efficient pairing computation with theta functions. Algorithmic Number Theory, 9th international symposium, ANTS-IX, Nancy, France, July 2010, Proceedings. [31] D. Lubicz, D. Robert. A generalisation of Miller’s algorithm and applications to pairing computations on abelian varieties. Journal of Symbolic Computation, vol. 67, March–April 2015, pp. 68-92. [32] A. Menezes, T. Okamoto et S. Vanstone, Reducing elliptic curve logarithms to logarithms in a finite field, IEEE Transactions on Information Theory, 39 (1993), pp. 1639-1646. [33] V. Miller. Short programs for functions on curves, IBM Thomas J. Watson Research Center (se trouve à l’adresse : http://crypto.stanford.edu/ miller/miller.ps), 1986. [34] D. Mumford. Tata Lectures on Theta I. Volume 28 of Progress in Mathematics. Birkhäuser Boston Inc., Boston, MA, 1983. With the assistance of C. Musili, M. Nori, E. Previato and M. Stillman. [35] D. Mumford. Tata Lectures on Theta II. Volume 28 of Progress in Mathematics. Birkhäuser Boston Inc., Boston, MA, 1983. With the assistance of C. Musili, M. Nori, E. Previato and M. Stillman. [36] K. Nagao. Decomposition attack for the jacobian of a hyperelliptic curve over an extension field, Algorithmic number theory, Lecture notes in computer science, vol. 6197, pp. 285-300, 2010. [37] National Institute of Standards and Technology, “Digital Signature Standard,” Federal Information Processing Standards Publication 186-2, 2000. [38] N. Ogura, N. Kanayama, S. Uchiyama and E. Okamoto. Cryptographic pairings based on elliptic nets, Advances in information and computer security (2011), pp. 65-78. [39] Y. Onishi. Determinant expressions for hyperelliptic functions (with an appendix by Shigeki Matsutani), Tokyo journal of mathematics, vol. 27, n. 2, pp. 299-312, 2007.112 Bibliographie [40] A. Rice et E. Brown, Why Ellipses are not elliptic curves, Mathematics Magazine, Vol. 85, No. 3 (June 2012), pp. 163-176. [41] T. Saito, S. Yokoyama, T. Kobayashi et G. Yamamoto, Some relations between Semaev’s summation polynomials and Stange’s elliptic nets, J. Mathfor-Ind. 3A (2011) 89-92. [42] J. Silverman. The arithmetic of elliptic curves, Springer-Verlag, New York, 1985, pp 157-178. [43] I. Semaev. Summation polynomials and the discrete logarithm problem on elliptic curves, Cryptologie ePrint Archive, Report 2004/031, 2004. [44] N. Smart. On the performance of hyperelliptic cryptosystems, Advances in cryptology -Eurocrypt 99, Lecture notes in computer science, vol. 1892, 1999, pp. 165–175. [45] K. Stange. The Tate pairing via elliptic nets, Pairing based cryptographyPairing 2007, Lecture Notes in Computer Science Volume 4575, 2007, pp 329-348. [46] P. Stevenhagen et B. de Smit. Kernvak Algebra, notes de cours (se trouve à l’adresse : http://websites.math.leidenuniv.nl/algebra/ellcurves. pdf) [47] N. Theriault. Index calculus attack for hyperelliptic curves of small genus, Advances in Cryptology- ASIACRYPT 2003, lectures notes in computer science vol. 2894, pp. 75-92. [48] C. Tran. Formulae for computation of Tate pairing on hyperelliptic curve using hyperelliptic nets, Progress in Cryptology - AFRICACRYPT 2014, Lecture Notes in Computer Science Volume 8469, 2014, pp 199-214 [49] Y. Uchida. Division polynomials and canonical local heights on hyperelliptic Jacobians, Manuscrypta Mathematica, vol. 134, issue 3-4 (2011), pp 273-308. [50] Y. Uchida, S. Uchiyama. The Tate-Lichtenbaum pairing on a hyperelliptic curve via hyperelliptic nets, Pairing based cryptography-Pairing 2012, pp. 218-233 [51] S. Vanstone, Responses to NIST’s Proposal, Communications of the ACM, 35, July 1992, 50-52 (communicated by John Anderson). [52] V. Vitse, Attaques algébriques du problème du logarithme discret sur courbes elliptiques, dissertation de thèse, soutenue le 20 octobre 2011. [53] K. Weierstrass Zur Theorie der Abelschen Functionen, Journ.reine angew.Math., 47 :289–306, 1854. [54] K. Weierstrass Gesammelte Werke, volume 4. Teu ?bner, 1902. [55] A. Weil. Sur les fonctions algébriques à corps de constantes finis, C.R.Acad.Sci.Paris,210 :592–594, 1940 (= Oeuvres Scientifiques, Volume I, pp. 257–259).Résumé Dans cette thèse, j’étudie deux aspects distincts de la cryptographie basée sur les courbes elliptiques et hyperelliptiques. Dans une première partie, je confronte deux méthodes de calcul de couplages, originales car ne reposant pas sur le traditionnel algorithme de Miller. Ainsi, dans [45], K. Stange calcula le couplage de Tate sur une courbe elliptique à partir d’un nouvel outil, les elliptic nets. Y. Uchida et S. Uchiyama généralisèrent ces objets au cas hyperelliptique ([50]), mais ne donnèrent un algorithme pour le calcul de couplages que dans le cas des courbes de genre 2. Mon premier travail dans cette thèse fut de donner cet algorithme pour le cas général. De leur côté, D. Lubicz et D. Robert donnèrent dans [30] une autre méthode de calcul de couplage, basée sur les fonctions thêta. Le second résultat de ma thèse est de réunifier ces deux méthodes : je montre que la formule de récurrence à la base des nets est une conséquence des formules d’addition des fonctions thêta utilisées dans l’algorithme de Lubicz et Robert. Dans la seconde partie de ma thèse, je me suis intéressé à l’algorithme de calcul d’index attaquant le problème du logarithme discret sur les courbes elliptiques et hyperelliptiques. Dans le cas elliptique, une des étapes principales de cette attaque repose sur les polynômes de Semaev. Je donne une nouvelle construction ces polynômes en utilisant la fonction sigma de Weierstrass, pour pouvoir ensuite les généraliser pour la première fois au cas hyperelliptique. Abstract In this thesis, I study two different aspects of elliptic and hyperelliptic curves based cryptography. In the first part, I confront two methods of pairings computation, whose original feature is that they are not based the traditional Miller algorithm. Therefore, in [45], K. Stange computed Tate pairings on elliptic curves using a new tool, the elliptic nets. Y. Uchida and S. Uchiyama generalized these objects to hyperelliptic case ([50]), but they gave an algorithm for pairing computation only for the genus 2 case. My first work in this thesis was to give this algorithm for the general case. Meanwhile, D. Lubicz and D. Robert gave in [30] an other pairing computation method, based on theta functions. The second result of my thesis is the reunification of these two methods : I show that the recurrence equation which is the basis of nets theory is a consequence of the addition law of theta functions used in the Lubicz and Robert’s algorithm. In the second part, I study the index calculus algorithm attacking the elliptic and hyperelliptic curve discrete logarithm problem. In the elliptic case, one of the main steps of this attack requires the Semaev polynomials. I reconstruct these polynomials using Weierstrass sigma function, with the purpose of giving their first hyperelliptic generalization. Qualification et am´elioration de la pr´ecision de syst`emes de balayage laser mobiles par extraction d’arˆetes Martyna Poreba To cite this version: Martyna Poreba. Qualification et am´elioration de la pr´ecision de syst`emes de balayage laser mobiles par extraction d’arˆetes. Other. Ecole Nationale Sup´erieure des Mines de Paris, 2014. French. . HAL Id: pastel-01068828 https://pastel.archives-ouvertes.fr/pastel-01068828 Submitted on 26 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.N°:  2009 ENAM XXXX MINES ParisTech CAOR, Centre de Robotique – Département Mathématiques et Systèmes 60, Boulevard Saint Michel, 75272 Paris cedex 06, France École doctorale n° 432 : Sciences des Métiers de l’Ingénieur présentée et soutenue publiquement par Martyna POREBA le 18 juin 2014 Qualification et amélioration de la précision de systèmes de balayage laser mobiles par extraction d’arêtes ~~~ Edge-based accuracy assessment and improvement of mobile laser scanning systems Doctorat ParisTech T H È S E pour obtenir le grade de docteur délivré par l’École nationale supérieure des mines de Paris Spécialité « Informatique temps-réel, robotique et automatique » Directeur de thèse : François GOULETTE T H È S E Jury M. Pierre GRUSSENMEYER, Professeur, INSA de Strasbourg Rapporteur M. Nicolas PAPARODITIS Directeur de recherche, IGN Rapporteur M. Laurent TRASSOUDAINE, Professeur, Université Blaise Pascal de Clermont-Ferrand Président du jury M. Jean-Emmanuel DESCHAUD, Docteur, MINES ParisTech Examinateur M. François GOULETTE, Professeur, MINES ParisTech Directeur de thèse N°:  2009 ENAM XXXX1 0 Remerciements 0. Remerciements Je tiens tout d’abord à remercier François Goulette, mon directeur de thèse, pour toute son aide, sa disponibilité et le suivi qu’il m’a apportés le long de ma thèse, tout en me laissant une grande autonomie. Mes vifs remerciements vont aux membres de jury qui ont accepté de juger mes travaux. En particulier, je remercie chaleureusement M. Pierre Grussenmeyer et M. Nicolas Paparoditis d'avoir rapporté mon travail de thèse. Leurs remarques précieuses m’ont permis d’approfondir des explications sur certaines parties et d’envisager mon travail sous un autre angle. Je remercie également M. Laurent Trassoudaine de m'avoir fait l'honneur de présider mon jury de thèse. Enfin, je remercie M. Jean-Emmanuel Deschaud d'avoir participé à mon jury. Aussi, je voudrais exprimer ma sincère gratitude envers toute l’équipe du CAOR pour la bonne ambiance et l’accueil qui m’a été réservée. Notamment, je remercie Arnaud de la Fortelle de m’avoir donné l’opportunité d’intégrer son laboratoire et de travailler sur cette thèse. Une pensée particulière va à mes collègues doctorants et post-doctorants, pour l’encouragement et les formidables moments passés ensemble. Merci à vous tous d’avoir partagé avec moi ces moments de travail et de détente. Une spéciale dédicace à Jorge, Olivier, Martin, Fernando, Bruno, Zhuowei, Tao-Jin, Axel, Houssem, Victor, Anne-Sophie et Fatin. Cette thèse n'aurait pu aboutir sans le soutien financier de l’Ambassade de France en Pologne, facilité par l’actuel adjoint à l’attaché pour la science et la technologie M. Nicolas Frichot-Manoury. 3 0 Résumé 0. Résumé Au cours de ces dernières décennies, le développement de Systèmes Mobiles de Cartographie, soutenu par un progrès technologique important, est devenu plus proéminent. Il a été stimulé par le besoin grandissant de collecte d’informations géographiques précises sur l’environnement. Nous considérons, au sein de cette thèse, des solutions pour l’acquisition des nuages de points mobiles de qualité topographique (précision centimétrique). Il s’agit, dans cette tâche, de mettre au point des méthodes de qualification des données, et d’en améliorer les erreurs systématiques par des techniques d’étalonnage et de recalage adéquates. Nous décrivons une nouvelle démarche d’évaluation de l’exactitude et/ou de la précision des relevés laser mobiles. Celle-ci repose sur l’extraction et la comparaison des entités linéaires de la scène urbaine. La distance moyenne calculée entre les segments appariés, étant la distance modifiée de Hausdorff, sert à noter les nuages par rapport à des références existantes. Pour l’extraction des arêtes, nous proposons une méthode de détection d’intersections entre segments plans retrouvés via un algorithme de RANSAC enrichi d’une analyse de composantes connexes. Nous envisageons également une démarche de correction de relevés laser mobiles à travers un recalage rigide fondé, lui aussi, sur les éléments linéaires. Enfin, nous étudions la pertinence des arêtes pour en déduire les paramètres de l’étalonnage extrinsèque du système mobile. Nous testons nos méthodes sur des données simulées et des données réelles acquises dans le cadre du projet TerraMobilita. Mots clés : Nuage de points, Système Mobile de Cartographie, Exactitude, Précision, Arête, Segmentation, Évaluation, RANSAC, Recalage, Étalonnage, Mise en correspondance 4 0 Abstract 1. Abstract Over the past few decades, the development of Mobile Mapping Systems (MMS), supported by significant technological progress, has become more prominent. It has been motivated by the growing need for precise geographic information about the environment. In this thesis, we consider approaches for the acquisition of mobile point clouds with topographic quality (centimeter-level accuracy). The aim is to develop techniques for data quality assessment and improvement. In particular, we eliminate the systematic errors inherent to an MMS data using appropriate calibration and registration methods. We describe a novel approach to assess the accuracy and/or the precision of mobile laser point clouds. It is based on the extraction and comparison of line features detected within the urban scene. The computed average distance between corresponding pairs of line segments, taking advantage of a modified Hausdorff distance, is used to evaluate the MMS data with respect to a reference data set. For edge extraction, we propose a method which relies on the intersections between planes modelled via the RANSAC algorithm refined by an analysis of connected components. We also consider an approach to correct point clouds using a linebased rigid registration method. Finally, we study the use of edges for estimating the boresight angles of a land-based mobile mapping system. We apply our methods to synthetic data and to real data acquired as part of the TerraMobilita project. Keywords: Point Cloud, Land-based mobile mapping system (MMS), Accuracy, Precision, Edge, Segmentation, Assessment, RANSAC, Registration, Calibration, Matching 5 0 Table des matières 1. Introduction ........................................................................................................................... 7 1.1 Contexte général ......................................................................................................................... 7 1.1.1 Projet TerraMobilita ........................................................................................................................ 8 1.1.2 Motivations ......................................................................................................................................... 9 1.2 Apports de la thèse .................................................................................................................. 12 1.3 Plan du mémoire ...................................................................................................................... 13 2. Acquisition et qualification de relevés laser ................................................................. 15 2.1 Systèmes mobiles terrestres voués à la numérisation d’environnement ....................... 16 2.1.1 Principes fondamentaux d’un système mobile de cartographie ............................................. 18 2.1.2 Description du prototype L3D2 ................................................................................................... 21 2.1.3 Autres exemples de systèmes mobiles de cartographie ........................................................... 23 2.2 Sources de données expérimentales ..................................................................................... 24 2.3 Qualification de données ........................................................................................................ 28 2.3.1 Différents types d’erreurs en topographie.................................................................................. 28 2.3.2 Critères servant à décrire la qualité de nuages mobiles .......................................................... 31 2.3.3 État de l’art sur l’évaluation de l’exactitude de relevés laser mobiles .................................. 32 2.4 Expérimentation ...................................................................................................................... 35 3. Erreurs relatives au système MMS .................................................................................. 39 3.1 Analyse des erreurs liées à la cartographie mobile ........................................................... 40 3.1.1 Erreurs causées par le système de positionnement .................................................................. 40 3.1.2 Erreurs dues au capteur laser ....................................................................................................... 41 3.2 Amélioration des relevés laser mobiles ............................................................................... 43 3.2.1 Correction de la localisation en cours d’acquisition ................................................................. 43 3.2.2 Correction en post-traitement ...................................................................................................... 46 3.3 Étalonnage extrinsèque .......................................................................................................... 47 3.3.1 État de l’art sur l’étalonnage des excentricités linéaires ......................................................... 48 3.3.2 Étalonnage des systèmes embarqués de caméras ..................................................................... 49 3.3.3 Étalonnage des systèmes dotés de scanners .............................................................................. 51 3.4 Impact d’un faux étalonnage sur la géométrie du nuage ................................................. 54 4. Extraction d’arêtes ............................................................................................................. 57 4.1 Méthode générale - vue d’ensemble ..................................................................................... 58 4.2 État de l’art sur l’extraction d’arêtes ................................................................................... 59 4.3 Segmentation en éléments plans - état de l’art .................................................................. 61 4.3.1 Segmentation par croissance de surface (régions) .................................................................... 62 4.3.2 Transformée de Hough 3D ............................................................................................................ 63 4.3.3 Algorithme de RANSAC ................................................................................................................ 65 4.4 Contribution à la détection de plans .................................................................................... 676 4.4.1 Motivation ........................................................................................................................................ 68 4.4.2 Extraction séquentielle de plans .................................................................................................. 69 4.4.3 Connectivité de plans basée sur la théorie des graphes .......................................................... 71 4.5 Méthode proposée d’extraction d’arêtes ............................................................................. 77 4.6 Exemples de résultats .............................................................................................................. 82 4.6.1 Détection de plans ........................................................................................................................... 82 4.6.2 Extraction d’arêtes .......................................................................................................................... 84 5. Qualification à partir d’entités linéaires ........................................................................ 87 5.1 Problématique ........................................................................................................................... 87 5.1.1 Comment mesurer la distance entre deux segments dans l’espace ? ................................... 88 5.1.2 Contraintes ....................................................................................................................................... 90 5.2 Mesure de distance proposée ................................................................................................. 91 5.2.1 Distance de Hausdorff ..................................................................................................................... 92 5.2.2 Matrice de similarité ....................................................................................................................... 94 5.2.3 Mise en correspondance ................................................................................................................ 96 5.3 Résultats et évaluation ............................................................................................................ 99 5.3.1 Données expérimentales ................................................................................................................ 99 5.3.2 Évaluation de l’algorithme d’appariement ............................................................................... 100 5.3.3 Exactitude et précision................................................................................................................. 105 6. Recalage à partir d’entités linéaires ............................................................................. 107 6.1 Introduction ............................................................................................................................ 108 6.2 État de l’art du recalage rigide ............................................................................................ 109 6.2.1 Mise en correspondance automatique ....................................................................................... 109 6.2.2 Classification des méthodes existantes de recalage ............................................................... 111 6.2.3 Aperçu des méthodes basées sur les entités linéaires ............................................................ 113 6.3 Recalage basé-lignes : caractérisation des méthodes ..................................................... 115 6.4 Évaluation des méthodes présentées .................................................................................. 116 6.4.1 Données pour les expérimentations .......................................................................................... 117 6.4.2 Algorithmes implémentés ........................................................................................................... 118 6.4.3 Outils d’évaluation ........................................................................................................................ 118 6.4.4 Résultats – recalage des données bruitées ............................................................................... 119 6.4.5 Impact du bruit sur la distance de Hausdorff ........................................................................... 122 6.5 Approche proposée : RLMR-FMII2.................................................................................... 124 6.5.1 Recalage grossier – principe ....................................................................................................... 126 6.5.2 Évaluation avec données simulées ............................................................................................. 127 6.5.3 Tests sur données réelles ............................................................................................................ 130 7. Perspectives et conclusion ............................................................................................. 133 7.1 Conclusion ............................................................................................................................... 133 7.2 Perspectives et futurs travaux ............................................................................................. 136 7.2.1 Étalonnage extrinsèque du système : esquisse de solution .................................................. 136 Publications ............................................................................................................................... 139 Bibliographie ............................................................................................................................. 141 Annexe A .................................................................................................................................... 153 Annexe B .................................................................................................................................... 157 Annexe C .................................................................................................................................... 161 Annexe D .................................................................................................................................... 163 Annexe E .................................................................................................................................... 169 7 CHAPITRE 1 Introduction Sommaire : 1. Introduction ........................................................................................................................... 7 1.1 Contexte général ......................................................................................................................... 7 1.1.1 Projet TerraMobilita ........................................................................................................................ 8 1.1.2 Motivations ......................................................................................................................................... 9 1.2 Apports de la thèse .................................................................................................................. 11 1.3 Plan du mémoire ...................................................................................................................... 12 1. Introduction 1.1 Contexte général Depuis plusieurs siècles, les instruments essentiels de l’arpenteur et le savoir-faire de l’homme permettaient de cartographier la surface de la Terre. La technologie employée n’a cessé d’évoluer. Durant ce temps, nous notons quelques développements remarquables qui ont révolutionné la façon de mesurer. À ce titre, nous pouvons mentionner des mesures au moyen d’une lunette et d’une planchette (XVIIe siècle), celles réalisées à l’aide des photographies (XIXe siècle), des théodolites (XXe siècle), jusqu’à l'apparition de l'électronique et l’informatique qui ont donné naissance à de nouvelles techniques de levé et de traitement des données telles que la station totale, le positionnement par satellites et le télémètre laser. Cette évolution tire ainsi son origine dans les besoins sans cesse croissants d’informations tridimensionnelles, rapides et précises sur notre environnement. Cependant, nous observons que les méthodes dites conventionnelles dénotent quelques faiblesses, lorsqu’elles sont employées pour numériser des objets de grande dimension (au niveau des villes) ou de forme allongée (canyon urbain). La cartographie mobile par LiDAR (Light Detection And Ranging), intégrant ordinairement trois sous-systèmes : le télémètre laser, le système de navigation inertielle INS (Inertial Navigation System) et le système de positionnement par satellites GNSS (Global Navigation Satellite System), tous installés à l’intérieur d’une plate-forme mobile, a relégué les levés traditionnels par la vitesse de collecte de données à une toute autre place. Elle a permis d’accéder à des endroits où la réalisation des mesures serait pratiquement impossible avec d’autres méthodes. Dès lors, il est envisageable de produire rapidement des cartes topographiques, numériques et précises du terrain. Les systèmes aériens, installés dans un avion ou hélicoptère, sont capables de produire une impressionnante quantité de points 3D géo-référencés. Néanmoins, leur 8 richesse en détail restant limitée, la technologie seule ne permet pas de reconstruire des modèles 3D complets de ville. Les systèmes mobiles terrestres embarqués sur un camion sont alors perçus comme un compromis entre le balayage laser fixe et celui aéroporté. Toutefois, la rapidité des acquisitions présenterait peu d’intérêt si la qualité des données collectées n’était pas garantie. Afin de s’adapter aux nouvelles réalités, les systèmes mobiles de cartographie doivent être concurrentiels au regard des techniques conventionnelles. Or, nous insistons sur le fait que l’exactitude des points laser soit équivalente aux levés traditionnels, mais avec un temps d’acquisition et de traitement nettement plus rapide. Pour cadrer avec cet objectif, c’est-à-dire de mettre au point des systèmes mobiles de qualité topographique, il est primordial d’être en mesure de qualifier l’exactitude et la précision des données collectées afin d’améliorer celles-ci sur les erreurs systématiques. Ces systèmes étant récents, et bien que cette question soit essentielle, ces aspects ont encore été peu étudiés. 1.1.1 Projet TerraMobilita Notre travail est effectué dans le cadre du projet TerraMobilita, dont le but est de mettre au point de nouveaux processus automatiques de création et de mises à jour des cartes 3D de voirie urbaine, avec une précision centimétrique. Pour ce faire, des données laser et images, issues d’un système mobile de cartographie développé, entre autres, au sein du Centre de Robotique CAOR de MINES ParisTech, sont employées. Il s’agit alors de construire des modèles 3D complets de l’espace public afin de pouvoir étudier minutieusement l’encombrement de divers éléments (stationnement, poubelles, etc.), de gérer l’entretien des voiries, de produire des Plans de Déplacement Urbain (PDU) pour les besoins de circulations douces (piéton, vélo, rollers, poussette, chaise roulante, etc.) et de diagnostics d’accessibilité de la voirie pour les Personnes à Mobilité Réduite (PMR). L’objectif à atteindre est de fournir des solutions pour l’acquisition, le traitement de données 3D et la production de cartes, plus automatisées et moins coûteuses que les méthodes actuelles. Mais, on se doit de garder à l’esprit la contrainte de relevé couvrant plusieurs km2 de l’espace public en un temps court, et de volume importante de données à traiter. Figure 1.1 Diagramme de décomposition fonctionnelle du projet TerraMobilita. CHAPITRE 1. Introduction 9 1.1.2 Motivations Le projet TerraMobilita intègre plusieurs sous-projets, répertoriés principalement en trois catégories dont nous présentons la décomposition fonctionnelle dans la Figure 1.1. La partie concernant nos travaux est encadrée en rouge. Il s’agit dans la tâche de ce sous-projet (SP2) de mettre au point des techniques de numérisation 3D de qualité topographique. Ainsi, le dessein de cette thèse est de qualifier des données laser brutes acquises en environnement urbain, mais aussi d’améliorer, par des méthodes adéquates de recalage et d’étalonnage, la plate-forme mobile en terme de précision. Depuis l’avènement de la technologie laser, les géomètres sont obligés de recueillir des données de terrain selon une autre philosophie. Le relevé laser est acquis d’un point de vue surfacique et non plus par un choix de points caractéristiques comme c’est le cas avec un tachéomètre. Il est donc primordial de réfléchir, à quoi le terme « exactitude » doit se référer – à un point particulier du nuage, ou à un élément extrait à partir de nuages tel qu’une surface plane, une arête. Aussi, en dépit des gains de résolution et de précision des scanners laser récents, la nature des nuages de points (bruit, densité) peut toujours gêner son traitement (Figure 1.2). Cet état de fait devrait être pris en compte lors du choix des méthodes appropriées. Figure 1.2 Exemple de relevés laser acquis en 2009 au sein d’une même zone de test (rue Soufflot à Paris) par : a) LARA3D ; b) Stéréopolis ; c) Scanner laser fixe (Riegl VZ-400) Sachant que nous avons l’intention de fournir des solutions universelles, et ce quelle que soit la densité des données laser collectées, nous choisissons de ne pas utiliser de points de contrôle sélectionnés du nuage. Puisque l’identification précise des cibles, due aux caractéristiques des données laser, peut être ardue, voire impossible, nos solutions ont été conçues pour négliger l’influence de la densité des nuages de points sur le résultat de reconstruction des primitives. Nous avons donc posé l’hypothèse suivante : Les entités linéaires (dont la position est connue) extraites à partir de nuages de points de scènes urbaines numérisées par un système de balayage laser mobile, permettent de quantifier et d’améliorer l’exactitude des données produites. Dans ce travail, nous cherchons à démontrer la validité de 10 cette affirmation. Ainsi, nous vérifierons la pertinence des arêtes de pli, représentant les intersections entre les segments plans principaux dans le nuage de points. Les travaux décrits au sein de ce mémoire abordent le processus d’extraction d’arêtes, par l’intermédiaire desquelles nous pourrons ensuite qualifier les données mobiles et développer des outils servant, à leur tour, à améliorer la précision de celles-ci. Plusieurs axes de recherche peuvent être imaginés, à partir desquels nous listons sur la (Figure 1.3) les questions que nous allons aborder dans ce manuscrit. Quant à l’étalonnage intrinsèque des scanners, cette tâche ne fait pas l’objet de cette thèse, car ses paramètres, étant fournis par le constructeur, nous les considérons comme un modèle valable. Néanmoins, il faut se rendre à l’évidence que des unités incorrectement étalonnées propageront aussi des erreurs entachant le nuage de points. Figure 1.3 Principaux axes de recherche Les éléments linéaires sont omniprésents dans les scènes urbaines ce qui les rend de fait comme une source riche en informations. D’après [Sappa et al., 2006] et [Alshawa, 2006], les arêtes (les points de discontinuité) peuvent être regroupées en deux catégories (Figure 1.4) : 1) Les arêtes de pli (discontinuité de la dérivée première) qui apparaissent entre deux surfaces d’orientation différente. Elles peuvent être retrouvées par l’intersection des plans adjacents. 2) Les arêtes de pas (discontinuité d’ordre zéro) représentées par les points aux bords des trous et des fenêtres. Elles sont dues à la limitation du scanner laser, aux propriétés des surfaces numérisées pouvant absorber le signal émis, ou au manque de visibilité scanner – objet causé par des artefacts. Dans le premier cas, il est préférable, afin de minimiser le bruit, que les deux sous-nuages soient acquis sous un angle direct. Ce critère n’est pas toujours aisé à satisfaire. Tout en considérant les arêtes de pas, il faut garder à l’esprit que la nature hétérogène d’un nuage de point ne permet pas de garantir que la ligne extraite corresponde fidèlement à l’arête réelle. Nous préférons alors utiliser les droites sous forme d’intersections, soit des arêtes de pli, puisqu’elles peuvent être facilement extraites et décrites, même si les nuages de points sont peu denses et assez bruités. Dans ce manuscrit, le terme « arêtes » signifiera donc une droite d’intersection (limitée) entre deux plans voisins. CHAPITRE 1. Introduction 11 Figure 1.4 Différents types d’arêtes 1.2 Apports de la thèse La qualité des relevés laser est un facteur clef à prendre en considération. Elle comprend plusieurs aspects, dont l’exactitude des mesures. Le principe consiste toujours à utiliser une référence dont l’exactitude est plus élevée que celle des données étudiées. La plupart des travaux actuels se réalisent, soit par une analyse de coordonnées de points de contrôle, soit par une comparaison avec d’autres types de données (nuage de points, modèle de ville 3D). Notre première contribution est de fournir une nouvelle approche de qualification de l’exactitude et de la précision, fondée sur les arêtes. S’agissant de la référence, nous pouvons imaginer des éléments linéaires mieux géopositionnés qu’ils soient 2D ou 3D, acquis lors du levé topographique, ou bien encore extraits du nuage de points statique (relevé par scanner laser fixe) ou du plan 2D (emprise de bâtis, bordure de trottoir, etc.) (Figure 1.5). L’éloignement des deux sous-ensembles de segments, exprimés en tant que la distance de Hausdorff adaptée aux lignes, représentera désormais une mesure de la qualité. Figure 1.5 Arêtes de pli : a) Données de référence – nuage statique ; b) Relevé laser mobile 12 Notre deuxième contribution se veut de proposer une méthode automatique pour l’appariement des entités linéaires en s’appuyant sur leur similitude. Nous combinons, entre deux nuages, les lignes les plus semblables au sens du score attribué. En troisième lieu, nous évaluons quelques approches existantes permettant le recalage rigide basé sur des entités linéaires, en examinant leur pertinence vis-à-vis de notre problématique. Notre but est plutôt d’affiner les différents nuages déjà géo-référencés pour corriger le décalage (shift) survenu lors de l’estimation de trajectoire du véhicule par un système de navigation. C’est pourquoi nous portons un regard critique sur les méthodes actuelles qui paraissent peu robustes au bruit. Au vu de ces éléments, nous développons une chaîne complète, comprenant un appariement et une estimation des paramètres de pose par des segments de droite. La quatrième contribution réside dans la mise en évidence des arêtes afin de pouvoir en déduire l’étalonnage extrinsèque du système intégral, c’est-à-dire la matrice de rotation (boresight matrix) et le bras de levier (lever-arm) entre le scanner laser et la centrale inertielle, les deux étant embarqués sur une plate-forme terrestre. Nous démontrons que ces paramètres, ayant un impact sur les positions et orientations des lignes extraites d’une scène urbaine, sont observables, et que par conséquent, leurs valeurs numériques peuvent être estimées. Nous esquissons, un concept d’approche, devant être encore approfondie et testée, permettant un étalonnage extrinsèque du système doté d’un scanner à double balayage. Concernant l’extraction des arêtes de pli, nous employons, dans nos recherches, une méthode amenant à déterminer des droites d’intersection entre les plans détectés auparavant à l’aide de l’algorithme de RANSAC. Ce dernier est enrichi d’une analyse de composantes connexes. Nous proposons une solution alternative, étant notre dernier apport, pour vérifier la connectivité des plans, celle-ci faisant appel aux éléments de la théorie des graphes. Ces travaux ont donné lieu à plusieurs publications listées à la page 139 du manuscrit. 1.3 Plan du mémoire Ce mémoire de thèse est structuré en trois parties principales : l’extraction d’arêtes, la qualification des relevés laser et l’amélioration par consolidation. En souhaitant s’affranchir des limitations du système mobile de cartographie et pour répondre aux exigences imposées par le projet TerraMobilita, la qualité des données laser doit être étudiée et évaluée, pour pouvoir par la suite proposer des améliorations utiles et efficientes. Chacun des chapitres, s’articulant autour de ces objectifs, est accompagné par un état de l’art permettant de s’inspirer des moyens et des méthodes mis en œuvre. Nous caractérisons, dans un premier temps (Chapitre 2), le système mobile de cartographie. Nous commençons par décrire le principe de son fonctionnement. Nous présentons des données avec lesquelles nous travaillons, acquises dans le cadre du projet TerraMobilita ou d’une autre manière. Nous définissons les notions d’erreurs telles que liées au levé topographique, et introduisons les termes d’exactitude et de précision. En outre, nous testons quelques méthodes simples permettant d’évaluer l’exactitude relative des relevés laser mobiles. Ensuite (Chapitre 3), nous listons non seulement les sources d’anomalies envisageables contribuant à l’erreur globale du système, mais aussi nous présentons des solutions récentes pour pallier à ces difficultés. Ainsi, différentes méthodes applicables en temps réel et en posttraitement y compris l’étalonnage extrinsèque sont discutées. Les effets du défaut d’étalonnage précis des excentricités angulaires (boresight angles) entre les capteurs de perception et la centrale inertielle, sur la qualité géométrique des nuages de points, sont aussi expliqués. CHAPITRE 1. Introduction 13 Notre point de départ est l’extraction des arêtes de pli à partir de relevés laser (Chapitre 4). Nous mettons en avant une procédure de détection des droites d’intersections via des segments plans retrouvés. Ensuite, nous nous penchons sur les algorithmes de reconstruction automatique des primitives planes dans un nuage, étant donné un modèle connu a priori, notamment sur l’estimateur de RANSAC. Nous nous imposons une contrainte de connectivité entre les points formant chaque segment plan, et résolvons cette question grâce à la théorie des graphes, plus précisément par la structuration propre du nuage et la décomposition Dulmage-Mendelsohn. Ensuite (Chapitre 5), nous proposons une approche de qualification des relevés laser basée sur des entités linéaires. Celle-ci délivre une mesure de qualité en s’appuyant sur la distance de Hausdorff modifiée. Pour déterminer sa valeur, nous développons un algorithme de mise en correspondance visant à repérer les entités analogues ou très proches dans deux jeux de données. Nous appliquons cette méthode aux lignes 3D extraites au sein d’une zone de test, et présentons les résultats obtenus. De surcroît (Chapitre 6), nous suggérons de corriger les données laser mobiles par un recalage rigide bénéficiant des segments de droite. Après avoir détaillé les contraintes apportées par une paire de primitives linéaires appariées, nous expliquons, et évaluons trois algorithmes de calcul des poses, par minimisation de ces contraintes entre deux ensembles de segments. Par la suite, nous avançons une solution complète aboutissant à raffiner, par consolidation, des nuages de points distincts. Nous montrons l’efficacité de notre approche, et présentons les résultats obtenus sur quelques jeux de données simulées et réelles acquises dans le cadre du projet TerraMobilita. Pour terminer (Chapitre 7), nous soumettons une brève discussion relative aux conclusions et perspectives issues de ces recherches. Nous suggérons également une approche d’étalonnage extrinsèque, conçue pour des scanners 3D. 15 CHAPITRE 2 Acquisition et qualification de relevés laser Sommaire : 2. Acquisition et qualification de relevés laser ................................................................. 15 2.1 Systèmes mobiles terrestres voués à la numérisation d’environnement ....................... 16 2.1.1 Principes fondamentaux d’un système mobile de cartographie ............................................. 18 2.1.2 Description du prototype L3D2 ................................................................................................... 21 2.1.3 Autres exemples de systèmes mobiles de cartographie ........................................................... 23 2.2 Sources de données expérimentales ..................................................................................... 24 2.3 Qualification de données ........................................................................................................ 28 2.3.1 Différents types d’erreurs en topographie.................................................................................. 28 2.3.2 Critères servant à décrire la qualité de nuages mobiles .......................................................... 31 2.3.3 État de l’art sur l’évaluation de l’exactitude de relevés laser mobiles .................................. 32 2.4 Expérimentation ...................................................................................................................... 35 2. Acquisition et qualification de relevés laser Dans ce premier chapitre, nous expliquons brièvement les principes fondamentaux d’un système mobile MLS positionné avec une navigation hybride GNSS/INS. Nous présentons quelques récentes platesformes de cartographie. Puis, nous décrivons le prototype L3D2 développé au CAOR de MINES ParisTech ainsi que d’autres systèmes dont les données ont été employées pour tester des approches proposées au cours de cette thèse. Ensuite, nous caractérisons différentes sources d’erreurs ayant un impact sur la qualité des mesures. Aussi, les notions complémentaires d’exactitude et de précision de données sont introduites afin d’expliciter la nature de ces erreurs. Notre objectif principal est de nous pencher sur les méthodes récentes traitant du problème de qualification. Notamment, l’exactitude de relevés laser mobiles, mesurée par rapport à diverses références et éléments de contrôle, est étudiée. Un aperçu de techniques existantes dévoile que la plupart d’entre elles souffraient du manque d’automatisation. Finalement, deux approches sont implémentées puis testées pour vérifier l’exactitude relative du nuage de points mobile. Les données référence sont les suivantes : 1) un ensemble de points aux coordonnées connues et mesurées à l’aide d’un tachéomètre électronique ; 2) un nuage de points statique. Les points faibles des techniques mises en œuvre sont notés. Résumé 16 2.1 Systèmes mobiles terrestres voués à la numérisation d’environnement Soutenus par un progrès constant dans le génie informatique et le traitement automatique d’informations, les systèmes mobiles basés sur LiDAR évoluent à un rythme rapide. Leur développement comprend des modifications technologiques importantes en termes de capteurs, d’architecture du système et de traitement de données. De nouveaux scanners laser offrent une large plage de fonctionnement. Les fabricants ont considérablement avancé sur l’ergonomie des appareils en les rendant plus légers et améliorant par conséquent leur portabilité. Alors qu’un scanner laser nécessitait auparavant une équipe de deux personnes, une seule suffit désormais pour effectuer un balayage laser fixe. D’après les études publiées en 2013 par la société de recherche et de conseil américaine ARC Advisory Group [Evans, 2013], le marché des scanners laser 3D va continuer à pénétrer de nouveaux secteurs doublant ainsi les ventes sur les quatre prochaines années. Avec cette variété de capteurs laser, une baisse massive des prix et une simplification de leur utilisation, le nombre de systèmes mobiles aussi bien que leurs applications possibles ne cessent de croître. Dès lors, les plates-formes mobiles aériennes ALS (Airborne Laser Scanning) et terrestres MLS (Mobile Laser Scanning) ainsi que les systèmes portatifs (Hand-Held Mobile Mapping) sont de plus en plus utilisés, permettant une exploitation de ce matériel dans des secteurs qui autrefois n’auraient pas envisagé leur utilisation. En outre, avec le développement des capteurs miniaturisés LiDAR pouvant être embarqués sur les petits drones, la prolifération des systèmes UAV (Unmanned Aerial Vehicle)/ UAS (Unmanned Aircraft System) est devenue une réalité. Figure 2.1 Exemple de systèmes commerciaux : a) Lynx Mobile Mapper M1 de Chung Hsing Surveying ; b) Garmin Corporation de Taïwan ; c) Riegl VMX-250 de SGS ; d) MMS série X de Mitsubishi Electric CHAPITRE 2. Acquisition et qualification de relevés laser 17 Les acquisitions par l’intermédiaire d’un système MLS peuvent être réalisées, selon la façon de combiner les données provenant des capteurs, soit en mode dynamique (On Drive) soit Stop&Go. Le premier mode permet de numériser l’environnement en mouvement, c’est-à-dire les informations sont intégrées en temps réel pendant le déplacement de la plate-forme. Lorsque la seconde technique est employée, le véhicule reste immobile et le scanner effectue un scan complet tournant sur deux axes. Après avoir fini les mesures, le système se déplace à une autre position. Figure 2.2 Quelques récents et « légers » systèmes mobiles de cartographie : a) ZEB1 de 3DLaserMapping ; b) BackPack Mobile Mapping System [Liao et al., 2013] ; c) Trekkeur de Google Street View ; d) Système mobile de l’Université de Floride (FLREC Geomatics) ; e) VERDINO2 de l’Université La Laguna de Ténérife Dans tous les cas, une source d’alimentation, un ordinateur portable et deux modules produisent ses fonctionnalités basiques. À bord d’une plate-forme mobile, les capteurs de positionnement (p.ex. un récepteur GNSS, une centrale inertielle INS, un odomètre DMI (Distance Measurement Instrument)) et les capteurs d’imagerie (scanners laser, caméras), tous en une configuration propre à chaque constructeur, doivent trouver leur place. En revanche, du fait de la polyvalence des systèmes, ils peuvent être déployés sur les différents types de 18 véhicules y compris le camionnette, le véhicule 4x4, le quad, le chariot, le vélo, le bateau ou la locomotive, comme l’illustrent la Figure 2.1 et la Figure 2.2. 2.1.1 Principes fondamentaux d’un système mobile de cartographie Puisque chaque système mobile MMS (Mobile Mapping System) intègre de nombreux capteurs, c’est une technologie de plus en plus complexe. Tout système est capable de fournir des données correctes, pour autant que les conditions suivantes soient remplies : 1) Les capteurs entre eux-mêmes doivent être précisément synchronisés ; 2) Le système est tenu d’être rigide, c’est-à-dire qu’il n’existe aucun déplacement relatif entre les composantes au cours de l’acquisition ; 3) La position et l’attitude de la plate-forme doivent être déterminées avec une précision suffisante ; 4) Les excentricités linéaires et angulaires à savoir les translations et les rotations entre les capteurs de perception et l’IMU (Inertial Measurement Unit) doivent être connues. Chacun des capteurs mis en place travaille avec son propre système de référence. Le Tableau 2.1 caractérise les repères pouvant être définis lors du fonctionnement d’un système mobile, qu’il soit terrestre ou aérien. Tableau 2.1 Repères de référence Sigle Nom du repère Description s Repère du capteur (Sensor Frame) Repère laser/caméra. b Repère body (Body Frame) Repère représenté par les axes du système de navigation inertielle. L’origine de ce système est située au centre de l’IMU. Les angles de rotation associés sont nommés : roulis (roll), tangage (pitch), lacet (yaw). l Repère véhicule (Local Level Frame) Ce cadre est généralement utilisé comme référence pour les angles d’orientation mesurés par le système intégré GNSS/INS. Autrement dit, c’est un repère local terrestre mobile. Son origine peut être définie comme l’intersection de la verticale locale, déterminée à partir de la position actuelle du capteur, avec l’ellipsoïde terrestre global. e Repère de l’objet (ECEF Frame) Système géodésique cartésien géocentré (attaché à la Terre). L’origine de ce système est fixée au centre de la Terre. La direction de l'axe OX est donnée par l'intersection de l’équateur terrestre et par le méridien de Greenwich. Quant à l'axe OY, il se situe dans le plan de l’équateur et de l’orthogonal à OX. Pour l'axe OZ, il correspond à l'axe de rotation de la Terre. De ce fait, le résultat du calcul de la trajectoire est principalement fourni dans ce repère sous forme de coordonnées géocentriques ou de coordonnées géographiques : λ - latitude, φ - longitude, h – hauteur ellipsoïdale. M Repère terrain (Mapping Frame) Ce repère est employé pour exprimer les coordonnées des points d’un nuage/image. Il peut être aussi représenté par une surface de référence, par projection ainsi que par le système de référence (national, reconnu dans le pays). Afin de générer un nuage de points, dans un repère terrain, à partir de données brutes enregistrées par les capteurs, trois changements successifs de repère sont nécessaires (Figure CHAPITRE 2. Acquisition et qualification de relevés laser 19 2.3). D’abord, le passage distance-angle (coordonnées sphériques) aux coordonnées cartésiennes dans le repère lié au scanner laser (s) est effectué. Ensuite, nous passons aux coordonnées dans le repère IMU (b) défini par la centrale inertielle pour réaliser la transformation dans le repère terrain (M). Le premier passage se fait en prenant également en compte les paramètres d’étalonnage intrinsèque. Quant au deuxième, il exige un étalonnage extrinsèque permettant de déterminer les excentricités linéaires ݎ௕/௦ ௕ et angulaires ܴ௦ ௕ entre les capteurs de perception et la centrale inertielle. Enfin, la dernière transformation est envisageable grâce aux données ܴ௕ ெሺݐሻ mesurées par la centrale inertielle. La notation employée pour décrire la transformation d’un repère à l’autre est la suivante : ܴ symbolise la matrice de rotation, et ݎ la translation. En outre, l’indice désigne le capteur concerné, tandis que l’exposant (indice supérieur) indique le repère dans lequel cette grandeur est mesurée. Par exemple, ݎ௕/ீேேௌ ௕ correspond au bras de levier entre l’unité inertielle et le récepteur GNSS, exprimé dans le repère body (b). La formulation mathématique de géo-référencement direct d’un système équipé de scanners laser peut être exprimée comme suit : ௣ݎ ெ ൌ ݎ௕/ீேௌௌ ெ ሺݐሻ ൅ ܴ௕ ெሺݐሻ ∙ ൫ݎ௕/௦ ௕ ൅ ܴ௦ ௕ܺ௟௔௦௘௥൯ (2.1) où : ேௌௌீ/௕ݎ ெ ሺݐሻ : position mesurée par le système intégré GNSS/INS/DMI exprimée dans le repère terrain (M) ; ܴ௕ ெሺݐሻ : matrice de rotation du repère body (b) vers le repère terrain (M). Elle peut être représentée par trois angles : la rotation autour de l’axe X - roulis (߮), celle autour de l’axe Y – tangage (ߠ), et celle autour de l’axe Z – lacet (߰). Toutes les trois varient au cours du temps (t) ; La convention utilisée pour ces trois rotations par les centrales inertielles les plus courantes (IXSEA et Applanix) est la convention roll-pitch-yaw (2.2) : ܴ௕ ெሺݐሻ ൌ ܴ௓ሺ߰ሻ ∙ ܴ௒ሺߠሻ ∙ ܴ௑ሺ߮ሻ (2.2) où : ܴ௑ሺ߮ሻ ൌ ൥10 0 0 ܿݏ݋ሺ߮ሻ െݏ݅݊ሺ߮ሻ 0 ݏ݅݊ሺ߮ሻ ܿݏ݋ሺ߮ሻ ൩ ; ܴ௒ሺߠሻ ൌ ൥ ܿݏ݋ሺߠሻ 0 ݏ݅݊ሺߠሻ 0 10 െݏ݅݊ሺߠሻ 0 ܿݏ݋ሺߠሻ ൩ ; (2.3) ܴ௓ሺ߰ሻ ൌ ൥ܿݏ݋ሺ߰ሻ െݏ݅݊ሺ߰ሻ 0 ݏ݅݊ሺ߰ሻ ܿݏ݋ሺ߰ሻ 0 0 01 ൩ ; ܺ௟௔௦௘௥ : Coordonnées de points laser mesurés dans le repère scanner (b). Pour un scanner de profil 2D (balayage plan) SICK LMS 221, le passage des données brutes au repère scanner (s) se réalise selon la formule (2.4) ܺ௟௔௦௘௥ ൌ ൥ ݏߩ݅݊ሺ݅ߠ ൅ ߮ሻ ሻ߮ ൅ ߠ݅ሺݏ݋ܿߩെ 1 ൩ (2.4) où ߩ :mesure de distance objet-scanner ; ߮ : angle de début du balayage ; ߠ : résolution du scanner ; ݅ : index du faisceau laser. 20 ௦/௕ݎ ௕ : excentricité linéaire (bras de levier) entre le centre du scanner et le centre de la centrale inertielle, exprimée dans le repère de l’IMU (b). Cette valeur est supposée constante au cours du temps (t) ; ܴ௦ ௕ : Matrice de rotation (matrice de boresight) du repère laser (s) vers le repère body (b). Ses angles ݁௑, ݁௒, ݁௓ sont constants dans le temps (t). Nonobstant, dans le cadre des systèmes mobiles dotés de caméras, la formule (2.1) garde sa forme initiale, sauf que la composante ܺ௟௔௦௘௥ doit être remplacée par ݎߤ௣ ௖. Le caractère ߤ symbolise le facteur d’échelle, tandis que ݎ௣ ௖ contient des coordonnées d’images du point dans le repère caméra. Figure 2.3 Concept du géo-référencement direct Selon [Ellum et El-Sheimy, 2002], la qualité des nuages de points dépendra alors, dans la même mesure, de la précision de l’étalonnage du système et des erreurs de mesures laser. Ils proposent, à cet effet, d’estimer l’influence des différents composants à travers la dérivation du premier ordre de l’équation (2.1). ௣ݎߜ ெ ൌ ݎߜ௕/ீேௌௌ ெ ሺݐሻ Erreur de position GNSS (2.5) ௕ܴߜ൅ ெሺݐሻ൫ݎ௕/௦ ௕ ൅ ܴ௦ ௕ܺ௟௔௦௘௥൯ Erreur d’attitude IMU ൅ܴ௕ ெሺݐሻߜܴ௦ ௕ܺ௟௔௦௘௥ Erreur sur l’excentricité angulaire (boresight) ൅ܴ௕ ெሺݐሻݎߜ௕/௦ ௕ Erreur sur l’excentricité linéaire ൅ܴ௕ ெሺݐሻܴ௕ ௦ߜܺ௟௔௦௘௥ Erreur de mesures du scanner laser CHAPITRE 2. Acquisition et qualification de relevés laser 21 ൅ݐߜ ቀݒሺݐሻ ൅ ߱ሺݐሻ൫ݎ௕/௦ ௕ ൅ ܴ௦ ௕ܺ௟௔௦௘௥൯ቁ Erreur de synchronisation Il en ressort que la multitude d’éléments associés au système mobile produit plusieurs types d’erreurs affectant les résultats d’acquisitions. Le Chapitre 3 abordera leur origine, mais il expliquera aussi la contribution de chacune des composantes au bilan global des erreurs du système. 2.1.2 Description du prototype L3D2 Un système mobile est développé au sein du CAOR de MINES ParisTech depuis 2002. Il s’agit du prototype L3D2. C’est une nouvelle plate-forme de numérisation 3D, basée sur les mêmes principes, mais plus performante que son prédécesseur appelé LARA3D (LA Route Automatisée). Le but de ce développement en cours est, dans le cadre du projet TerraMobilita, de rivaliser avec la précision des techniques et des méthodes topographiques conventionnelles (tachéométrie, GPS, nivellement direct, balayage laser terrestre). Figure 2.4 Évolution du prototype LARA3D Figure 2.5 Prototype L3D2 (version de mai 2012) Un tel système est configuré pour accueillir de nombreux capteurs et il a donc dû subir, depuis sa conception, plusieurs améliorations. La Figure 2.4 présente ce prototype dans la version de 2002, 2008, et de 2010. Le système le plus récent avec lequel nous sommes en train de travailler est représenté par la Figure 2.5. 22 Le système de positionnement de notre prototype est composé d’un récepteur GNSS Novatel Flexpak6, d’une centrale inertielle PHINS d’IXSEA et d’un odomètre (DMI). Les capteurs de perception sont constitués, optionnellement, de deux scanners laser SICK LMS 221 en balayage plan vertical à droite et à gauche du véhicule, situés dos à dos. Chaque télémètre laser, fonctionnant à temps de vol (le temps de parcours de l’onde entre son départ et son retour sert à déduire une mesure de distance), numérise une zone de 180 degrés. À l’heure actuelle, notre objectif principal est de remplacer ces scanners par un Velodyne HDL-32E (High Definition LiDAR), contenant trente-deux fibres inclinées dans un plan vertical tournant sur lui-même. Le laser Velodyne sera installé en arrière du véhicule et penché d’environ 60°. Par conséquent, environ 700 000 de points par seconde seront mesurés. Nous pouvons aussi ajouter, selon les usages, un ou plusieurs autres capteurs. Le véhicule (Citroën Jumper) est également doté d’un ordinateur embarqué avec un logiciel robuste RTMaps v.3.4.10 permettant la synchronisation, en temps réel, des données datées provenant de différents capteurs. La trajectoire du véhicule est calculée grâce au filtrage de Kalman, un outil puissant servant à établir la synergie entre trois capteurs de navigation : GNSS, INS et DMI, puisqu’il peut tirer les avantages de ces trois systèmes de localisation distincts. Une fois le véhicule localisé, c’est-à-dire sa position et sa rotation connue dans un repère terrain, il est possible de géo-référencer toutes les données issues des capteurs de perception. Pour ce faire, la datation des données de cartographie est synchronisée avec celle de la localisation, avec si nécessaire une interpolation entre deux positions successives. Figure 2.6 Diagramme RTMaps utilisé pour la génération des nuages de points : a) Module de localisation ; b) Module de géo-référencement ; c) Données de cartographie La Figure 2.6 montre le diagramme RTMaps, utilisé lors de la génération des nuages de points, comprenant trois composants principaux de traitement : 1) Module de localisation (parseur de la sortie de centrale) – package PhinsStandard v.1.0 CHAPITRE 2. Acquisition et qualification de relevés laser 23 2) Module de géo-référencement (reconstruction du nuage de points) – package GeoScanSickXsea v.1.0 3) Visualiseur de nuage de points – package PointscloudViewer v.1.0 Figure 2.7 Nuage de points acquis par LARA3D – LARA3Dv2010_Orsay 2.1.3 Autres exemples de systèmes mobiles de cartographie Dans le cadre de notre étude (extraction d’arêtes, détection de plans, qualification, recalage rigide), nous avons utilisé différents types de relevés laser. Figure 2.8 Stéréopolis II, système mobile de l’IGN [Paparoditis et al., 2012] La Figure 2.8 montre le système de cartographie mobile développé par l’IGN. Son système actuel de vision comprend des capteurs de haute résolution, notamment un ensemble de dix caméras HD assurant une couverture horizontale complète, deux scanners laser Riegl LMSQ120i avec une ouverture de 80 degrés et un Velodyne®HDL-64E. La partie concernant la navigation est constituée d’un système hybride composé de deux récepteurs GNSS, d’une centrale inertielle Applanix (POSPac / POS LV V4), et d’un odomètre. L’architecture du couplage de capteurs est de type lâche (tightly coupled). Pour plus d’informations relatives au système Stéréopolis II, le lecteur pourra se référer à [Paparoditis et al., 2012]. 24 Figure 2.9 Exemple de nuages de points produits par le système Stéréopolis II – Stereopolis2009_Soufflot Le second système mobile de cartographie terrestre, dont les données ont été exploitées, est un système commercial de Riegl VMX-250. Il est doté de deux scanners laser de Riegl VQ- 250, de quatre caméras et de compteurs très précis de positionnement (la spécificité plus détaillée du système se retrouve sur le site web du Riegl). Figure 2.10 Gabarit ferroviaire numérisé par Riegl VMX-250 – Riegl2012_Slomniki 2.2 Sources de données expérimentales Relevé laser Nous traitons, au sein de ce travail, des nuages de points produits par des systèmes terrestres fixes ou mobiles notamment : 1) Les relevés laser mobiles collectés par LARA3D (version 2010) (Figure 2.7) ; CHAPITRE 2. Acquisition et qualification de relevés laser 25 2) Les relevés laser mobiles produits par Stéréopolis II de l’Institut Géographique National (IGN) (Figure 2.9) ; 3) Les relevés laser mobiles acquis par un système mobile de Riegl VMX-250 (Figure 2.10) ; 4) Les relevés laser statiques obtenus par scanner fixe Trimble®GX, Timble®VX et Leica C10. Les nuages de points de haute résolution (statique) servent de référence à notre étude comparative (qualification, recalage). Le premier nuage, nommé Orsay2009_statique, a été fourni par Trimble 3D Scanning System lors des travaux réalisés dans le cadre du projet TerraNumerica (projet antérieur à TerraMobilita). Les acquisitions ont été faites de façon complémentaire avec une station spatiale Trimble®VX présentant les fonctionnalités du scan 3D et un scanner Trimble®GX. Vingt-six stations, dont 10 stations de GX, ont été placées afin d’assurer une bonne couverture des deux façades du Musée d’Orsay (nord et ouest) et d’éviter au maximum les masques. Enfin, la résolution finale du nuage a été limitée à 2cm. Le second nuage Sulpice2013_statique (Figure 2.11), a été collecté lors d’une acquisition de terrain que nous avons réalisée le 14 novembre 2012 en collaboration avec l’ENSG (École Nationale des Sciences Géographiques). La Figure 2.12 représente le schéma des emplacements de différentes stations Leica ScanStation C10, ainsi que des stations GNSS stationnées avec un Trimble®R8. Des scans de très haute résolution (4mm) ont été acquis et ensuite géo-référencés dans le système Lambert-93. Le logiciel LGO (Leica Geo Office) de Leica a été choisi pour traiter les données GNSS. Les nuages de points, grâce aux coordonnées obtenues, ont été géopositionnés à l’aide de Leica Cyclone 7.0.2. Au final, la précision relative des relevés laser est de l’ordre de 3mm. Concernant la précision absolue, nous estimons qu’il existe des erreurs d’environ 3cm confirmant que notre référence est fiable. En conséquence, nous disposons d’une base abondante de données ayant des caractéristiques complètement différentes (taux de bruit, densité, qualité). Figure 2.11 Nuage de points consolidé - Sulpice2013_statique26 Figure 2.12 Plan de l’acquisition statique (Croisement des rues du Vieux-Colombier et Madame, Paris) Levé topographique Un levé topographique Orsay2011_topo a été réalisé le 27 février 2011 avec une TCR 803 de Leica (Figure 2.13b). Un cheminement ouvert comportant cinq stations intermédiaires, situées à une distance d’au maximum 30m de la façade, a été mis en place (Figure 2.13a). Le nombre et l’emplacement de points de canevas ont été planifiés de telle manière que le tachéomètre émette un rayonnement pour lequel l’angle d’incidence ne soit pas inférieur à 60° (voir l’information sur l’angle d’incidence dans la section 3.1.2). Cette contrainte a été choisie pour assurer une bonne qualité de données de référence, saisies en mode sans prisme réflecteur. D'autre part, toutes les mesures ont été géo-référencées dans un système local établi par deux stations (St4 et St5). Figure 2.13 a) Cheminement réalisé lors du levé topographique ; b) TCR 803 de LeicaCHAPITRE 2. Acquisition et qualification de relevés laser 27 Au total, le levé opéré dans une seule position du cercle a contenu 344 points dont 297 appartenant à une coupe horizontale prise environ 7.2m au-dessus du sol (Figure 2.14). Le transfert des données depuis la station totale a été fait sous LGO, tandis que le traitement (décodage, calcul de coordonnées, etc.) à l’aide du logiciel WinKalk 3.78. Toutes ces mesures constituent une référence pour les analyses présentées dans la poursuite des travaux. Figure 2.14 Répartition de points de contrôle (en jaune), et la coupe horizontale (en vert) Les points de contrôle à viser ont été représentés par des détails architecturaux tels que les coins de bâtiments, les arêtes de piliers, les intersections d’éléments caractéristiques. Les piquets se trouvent alors sur un coin convexe ou concave dont la mesure à l’aide d’un télémètre laser peut poser certains problèmes. Nous obtenons, suivant les cas, un arrondi ou un congé entre deux surfaces voisines, tous deux dus à la généralisation de l’information lors de la réception du signal de retour [Klimkowska et Wrobel, 2006]. La Figure 2.15 illustre la situation typique rencontrée pendant le mesurage d’une bordure (edge effect) - les coordonnées obtenues ne correspondront quasiment jamais à la vraie position d’arête. Aussi, la distance mesurée entre l’emplacement actuel et une cible s’écarte de la valeur réelle. Figure 2.15 Résultats de mesure : a) Coin concave ; b) Coin convexe Étant donné que l’empreinte laser possède une certaine taille dépendant de l’ouverture du dispositif, de la longueur de faisceau laser, mais aussi de la divergence de celui-ci, elle ne se matérialisera jamais sous la forme d’un point. En réalité, un laser produit une lumière qui va diverger de son origine. La cible balayée renvoie ainsi des retours multiples - une partie du signal proviendra de l’objet lui-même et une autre sera rétrodiffusée ; selon le cas, par une surface adjacente ou par une autre située derrière (Figure 2.16). Cependant, cette énergie ne 28 sera jamais retournée s’il n’y a pas d’autres éléments à portée du scanner. En fin de compte, la mesure finale de la distance sera toujours la moyenne des énergies retournées. L’erreur de mesures peut donc varier de quelques millimètres voire même de quelques centimètres. En ce qui concerne la mesure de coins concaves, le problème est moins complexe. La distance obtenue sera toujours plus petite que la valeur réelle. Quelle que soit l’origine de ces imprécisions, les cibles doivent être choisies avec soin. Figure 2.16 Empreinte du rayon laser sur les surfaces voisines 2.3 Qualification de données La qualité de données quelconques est un facteur clef à prendre en compte. À cet égard, la qualification devrait se fonder sur des procédures claires et précises. Son objectif se veut de satisfaire des besoins bien déterminés : ceux des fournisseurs (entre autres les topographes) étant obligés de valider des mesures, ainsi que ceux des futurs utilisateurs devant être au fait pour exploiter au mieux ces données. La qualification n'est pas un élément négligeable, car elle atteste que les données acquises permettront de créer un produit final avec une qualité attendue. Nous observons qu'il existe deux approches traitant de cette question [Boulaassal, 2010], [Boudet, 2007]. L’une, nommée évaluation qualitative, consiste à effectuer une analyse visuelle et à noter la qualité avec un sens sémantique, en lui attribuant des coefficients (par exemple : faux, approché ou correct). Elle permet de constater la présence de fautes (erreurs grossières). La seconde, quantitative, se réalise ultérieurement avec un calcul d’indices de qualité. Elle fournit une statistique descriptive, son but étant par définition, de décrire par des statistiques (la moyenne, l’écart, etc.) des données. Dans cette partie, nous nous intéresserons à l’évaluation de la qualité, en termes d’exactitude et de précision, des relevés laser acquis par un système mobile. Après avoir précisément défini ce qui est entendu par les notions susmentionnées (2.3.2), nous examinerons l’état de l’art des moyens actuellement disponibles pour les mesurer (2.3.3). Aussi, on se devra d'évoquer les autres critères complétant les informations sur la qualité de nuages de points. 2.3.1 Différents types d’erreurs en topographie Divers types de levés topographiques exigent, certes, des niveaux de précision différents. Connaître l’exactitude des résultats nécessite une bonne maîtrise des appareils utilisés, la CHAPITRE 2. Acquisition et qualification de relevés laser 29 prise en considération de cas particuliers et de situations défavorables, mais aussi, un savoirfaire pour les compenser. Les observations peuvent être entachées par : 1) des erreurs parasites ou des fautes – étant des incertitudes grossières dues à des inadvertances opératoires, un oubli ou bien encore un défaut de réglage de l’appareil. La faute est aisément repérable donc, peut et doit être supprimée. Pour déceler d'éventuelles fautes susceptibles d'être commises, des mesures de contrôles doivent être réalisées. 2) des erreurs systématiques, parfois appelées biais, étant une composante de l’erreur de mesure qui, lors des mesurages répétés, demeure constante en valeur absolue et en signe ou varie de façon prévisible. Ces erreurs sont cumulatives par voie d’addition et dues souvent aux imprécisions de l’instrument (qualité des composants, défauts d’étalonnage, temps de réponse, réglage de zéro, etc.) et aux contraintes de sa mise en œuvre. Les erreurs systématiques influencent l’exactitude (ou la justesse) d’une mesure et ne peuvent être atténuées par une augmentation du nombre de mesurages. La distribution des mesures sera, par la suite, déplacée de la valeur réelle. 3) des erreurs accidentelles (aléatoires) – les plus fréquentes, se produisant de manière aléatoire, en valeur et en signe, même quand les conditions de mesures sont identiques. Or, d’une mesure à l’autre, la valeur obtenue est surévaluée ou sous- évaluée. Les origines sont multiples : ce peut être dû à l’opérateur (par exemple : l’exactitude avec laquelle l’œil observe), à la qualité inévitablement limitée de nos instruments, mais aussi au milieu en lui-même (température ambiante, humidité, etc.). Ces erreurs subsisteront et entacheront la grandeur que l’on recherche et provoqueront une dispersion des résultats. Elles affectent essentiellement la précision des mesures. Dès que nous commençons à envisager la qualité des données collectées, nous souhaitons l’interpréter comme la confiance accordée en vue de la performance des techniques mises en œuvre et de la capacité des appareils utilisés. Partant de cette connaissance antérieure à l’acquisition, on peut en déduire une inexactitude théorique (a priori) entachant les données. Une fois l’acquisition achevée, des écarts empiriques (a posteriori) par rapport à une valeur attendue ou bien encore des propriétés de distributions des mesurages (ex. la moyenne, l’écart-type) peuvent être calculés. Ces valeurs servent à décrire l’exactitude et la précision. Ces deux qualificatifs, par ailleurs, sont quelquefois confondus ce qui amène à les considérer improprement comme des synonymes. Pour aller plus loin dans notre propos, on se doit de clarifier ces deux notions en les définissant, puisqu’elles se réfèrent à deux propriétés bien distinctes. La précision ou la fidélité (precision) des données est l’étroitesse de l’accord entre les valeurs mesurées ݉ෞప obtenues par des acquisitions répétées de même grandeur. Elle est quantifiable à partir d’un seul jeu de données et permet de définir la dispersion des résultats (l’erreur apparente ܸ௜). Selon les conditions, la précision peut être représentée par la répétabilité (repeatability) ou la reproductibilité (reproducibility) d’une mesure. La répétabilité, contrairement à la reproductibilité, est définie à travers des mesurages effectués par une même personne, dans un même lieu, avec le même appareil et dans un laps de temps très court. En revanche, dans le cas des nuages de points, il est quasiment impossible de remesurer un point plusieurs fois. En effet, une estimation de la précision des données demeure complexe. L’exactitude (accuracy) représente une concordance entre une valeur mesurée et une autre considérée conventionnellement comme exacte. Elle n’est quantifiable que par rapport à une véritable référence extérieure aux mesures. Son évaluation est toujours délicate puisque l’on ne dispose jamais de valeur réelle ܯ. Au-delà, pour des mesures multiples, la notion de justesse de mesure (trueness) définie par un écart du barycentre de l’ensemble de mesures (moyenne arithmétique) par rapport à la valeur 30 de référence ܯ, est également employée. C’est ainsi l’erreur vraie de la moyenne arithmétique. Afin de caractériser la précision d’opérations de mesures, nous pouvons introduire l’Erreur Moyenne Arithmétique ܣܯܧ correspondant à la moyenne des résidus ݁௜ pris en valeur absolue, soit : ܣܯܧ ൌ ∑ |݁௜| ே ௜ୀଵ ܰ (2.6) On note alors ݁௜ ൌ ݉ෞെܯ ప l’erreur vraie d’une mesure (écart de la valeur observée d’une des mesures ݉ෞ݅ par rapport à la valeur vraie ܯ), tandis que ܸ௜ ൌ ݉ෞെܯ ప ഥ l’erreur apparente d’une mesure (écart de la valeur observée ݉ෞ݅ par rapport à la moyenne arithmétique ܯഥ). Sur cette base, nous définissons le carré moyen des erreurs, soit l’Erreur Quadratique Moyenne ܧܳܯ (MSE pour Mean Square Error). C’est la moyenne arithmétique des carrés des écarts ݁௜ entre les prévisions ܯ et les observations ݉ෞ݅, souvent utilisée pour comparer plusieurs estimateurs, notamment lorsque l’un d’eux est biaisé. Nous la définissons via la formule mathématique : ൌ ඨ1 ܯܳܧ ܰ෍ ሺ݁௜ሻଶ ே ௜ୀଵ (2.7) Puisque la définition (2.7) exige que les erreurs vraies soient connues ce qui n’est pratiquement jamais le cas, nous utilisons généralement à la place l’écart-type ߪ de la distribution des valeurs de ݉ෞ݅ défini par : σ ൌ ඨ∑ ܸ௜ ே ଶ ௜ୀଵ ܰെ1 (2.8) C’est la racine carré du quotient de la somme des carrées des erreurs ܸ௜ par le nombre ܰ de ces erreurs ou résidus, moins 1. La Figure 2.17 contient une représentation classique des concepts de tir sur cible, envisageant quatre configurations possibles. Elle illustre les deux termes évoqués qui seront dorénavant utilisés dans ce mémoire pour quantifier les relevés laser mobiles. Nous remarquons que les données peuvent être exactes sans être précises (Figure 2.17c) et inversement (Figure 2.17b). Or, l’exactitude et la précision d’un résultat se vérifient toujours séparément. Figure 2.17 Exactitude vs. Précision d’une série de mesurages CHAPITRE 2. Acquisition et qualification de relevés laser 31 Les définitions ci-dessus s’inspirent du VIM (Vocabulaire International de Métrologie) [JCGM 200:2012] disponible sur le site internet du Bureau International des Poids et Mesures (BIPM) et sont semblables à celles introduites par des éditoriaux de [Brabant, 2011] [Newby, 2011] et [Hullo, 2013]. 2.3.2 Critères servant à décrire la qualité de nuages mobiles La problématique de l’évaluation de données laser n’étant pas triviale, nous pouvons définir plusieurs critères fournissant des informations sur la qualité des données. Pour leur part [Cahalane et al., 2010], affirment que la performance du système de cartographie mobile doit être étudiée en termes de résolution, d’exactitude et de répétabilité des données acquises. Quant à la résolution, elle se calcule en prenant en compte la répartition des points, à savoir l’espacement entre les profils voisins, mais aussi celui entre les points appartenant au même profil. Par le terme de répétabilité, nous exigeons que le système mobile soit capable de produire des données de même qualité lors de chaque acquisition. Mais, il faut garder à l’esprit que le fonctionnement du système mobile dépend fortement de la qualité du signal GNSS. Par conséquent, le balayage effectué quelque temps après pourra être exposé aux différentes configurations des satellites. Une procédure semblable de validation est développée par [Yoo et al., 2010], effectuant une analyse des relevés laser mobiles. Trois critères de qualité notamment la précision, la résolution et la complétude sont parallèlement étudiés. Toutes ces notions servent à attribuer une note unique synthétisant l’évaluation globale des nuages mobiles. La résolution permet de vérifier la répartition spatiale des points et donc le niveau de détail dans la scène numérisée. Il est évident que si les scanners fonctionnent à résolution angulaire fixe, l’emplacement entre les points varie fortement en fonction de la distance scanner-objet. Les zones très éloignées de la plate-forme seront donc acquises avec une résolution sousdensifiée et celles plus proches avec une résolution sur-densifiée. Cependant, dans une configuration optimale, les points doivent être répartis de manière homogène. Afin de bien étudier cette problématique, deux termes sont introduits : la densité locale et la densité moyenne. Tous deux représentent le nombre de points par m2. La densité locale (2.9) associée à chaque point se calcule pour un voisinage local, étant incluse dans le rayon d’une sphère (r). La distribution des points dans le nuage, d’après ce critère, sera visualisée par un outil statistique appelé « boîtes à moustache ». Enfin, nous complétons ultérieurement les analyses avec la densité moyenne (2.10). ௜݊ ൌ ௜ܦ ଶݎߨ (2.9) ܦഥ ൌ 1 ்݊ ௜ܦ ෍ ௡೅ ௜ୀଵ (2.10) où : ݊௜ – nombre de points dans le voisinage du point i ்݊ – nombre total de points dans le nuage S'appuyant sur les calculs effectués, le Taux de Bonne Résolution (TBR) est aussi déterminé selon l’équation (2.11). Celui-ci représente le pourcentage de zones ayant une densité satisfaisante. ൌ ܴܤܶ ݊ ்݊ (2.11) où : n – nombre de points pour lesquels la densité est supérieure à la densité minimale souhaitée. 32 Le dernier critère, la complétude, interprète et mesure la surface totale couverte par les points, puisque les acquisitions mobiles souffrent de problèmes d’occultations et de manque de visibilité. [Mano et al., 2012] développent un autre processus de qualification des nuages de points mobiles. Ils regroupent quatre indicateurs décrivant : 1) la qualité du trajet dérivée à partir du nombre de satellites visibles et du coefficient DOP ; 2) la précision ; 3) l’exactitude absolue ; et 4) l’exactitude relative. Sachant que le système étudié est équipé de quatre scanners laser, déployés dans une configuration spécifique, la vérification de la précision des données consiste à comparer différents nuages de points captés indépendamment lors d’un seul passage. L’information redondante entre les parties se chevauchant partiellement sert à délivrer une note. Quant à l’exactitude absolue, elle peut être déterminée à l’aide des points de contrôle mesurés au préalable. Le dernier critère, l’exactitude relative, suit le même principe que l’étude de précision. La seule différence réside dans le fait que l’acquisition des données est répétée au bout d’un certain temps. En assimilant les termes introduits dans la section précédente, nous pouvons constater que cette notion correspond à la définition de reproductibilité de données. Tous les paramètres de qualité susnommés semblent être pertinents pour les besoins d’évaluation des nuages de points. Néanmoins, comme le rapporte [Williams, 2012], le comité d’ASPRS (American Society of Photogrammetry and Remote Sensing) recommande de standardiser les procédures existantes, et de quantifier les relevés laser à l’aide seulement de deux paramètres : la résolution et l’exactitude. Ces facteurs amènent à attribuer une note commune (rating), tout en maintenant une distinction sur neuf niveaux de qualité (Figure 2.18). Une telle solution permettra aux utilisateurs de choisir des données satisfaisant leurs exigences. Alors, la note 3A attribuée signifiera la densité élevée par-devers l’exactitude faible, et cetera. Toutefois, ces données peuvent être suffisantes pour certaines applications telles que la vérification du nombre de poteaux le long de la rue. Néanmoins, l’auteur ne précise pas les valeurs numériques de résolution et d’exactitude prédéterminant les notes. Figure 2.18 Niveaux de qualité définis ralliant l’exactitude et la résolution de données 2.3.3 État de l’art sur l’évaluation de l’exactitude de relevés laser mobiles L’évaluation de l’exactitude et/ou de la précision de relevés lasers mobiles occupe une place particulière dans les recherches actuelles. Nombreux sont les ouvrages décrivant différents types de travaux à ce sujet. L’exactitude peut être considérée comme absolue et relative. L’exactitude absolue est une estimation de la qualité réalisée par rapport à la véritable position dans un cadre de référence terrestre. Elle répond à cette interrogation : Comment un nuage de point est positionné dans un référentiel. Cependant, l’exactitude relative estime la qualité de CHAPITRE 2. Acquisition et qualification de relevés laser 33 la mesure d’un vecteur entre deux points. En la mesurant, nous recherchons l'exactitude des points les uns par rapport aux autres, ou bien encore par rapport à l’origine du scanner laser. Dans toutes les approches que nous allons aborder, l’exactitude sera déterminée par rapport à des données plus précises que celles étudiées. Une référence de grande qualité, saisie par opérateur et géo-référencée, est ordinairement employée. Celle-ci peut être établie lors d’un levé topographique (tachéométrie, GPS), une acquisition laser statique, ou bien encore extraite de différentes bases de données telles que : des orthoimages, des modèles de ville 3D, des nuages LiDAR aéroporté, des bases de données topographiques ou des plans cadastraux 2D. La plupart des méthodes aboutissent à une comparaison de coordonnées de points de contrôle homologues, distinguables dans les données étudiées. Ces éléments sont fréquemment sélectionnés comme : 1) des sommets de marquages au sol [Gandofi et al., 2008], [Barber et al., 2008], [Guan et al., 2013] ; 2) des poteaux et des lampadaires [Yoo, 2010], [Ridene, 2010] ; 3) des coins de bâtiments et de trottoirs [Kaartinen et al., 2012], [Guan et al., 2013] , 4) des détails architecturaux [Poreba et Goulette, 2012] ; 5) des mires 3D spécialement conçues [Feng et al., 2008]. Certes, une telle approche souffre d’incertitude quant aux points sélectionnés, puisque nous ne pouvons quasiment jamais indiquer deux points homologues dans les nuages de points distincts. Ceci est causé par la nature des données laser mobiles qui sont hétérogènes et anisotropes (leur distribution varie suivant la direction). Ainsi, plus la densité des nuages de points est faible, plus la capacité de sélectionner de points appropriés est limitée. Même si des cibles sont employées, il n’existe aucune certitude que le faisceau laser balayera leurs centres. En outre, la qualité de chacun des points laser dépend fortement de la réflectance de matériaux et de l’orientation d’objet vers le scanner. La vérification de l’exactitude fait alors face à un certain nombre de défis. Comme il a été explicité par [Barber et al., 2008] et [Williams, 2012], l’évaluation de l’exactitude altimétrique est assez aisée par rapport à celle planimétrique. Ceci est dû au fait que le calcul du biais planimétrique, contrairement à celui altimétrique, exige souvent l’identification manuelle de points correspondants qui est ardue, malgré l’utilisation d’informations supplémentaires telles que l’intensité (Figure 2.19). Figure 2.19 Incertitude portant sur la mesure de l'exactitude : a) estimation de l'exactitude verticale ; b) estimation de l'exactitude horizontale (Illustration reproduite à partir de [Williams, 2012]) C’est pourquoi [Ray et Graham, 2008] proposent une méthode d’analyse d’exactitude planimétrique fondée sur les primitives linéaires (des bords de marquages au sol) extraites, à la fois, depuis des données LiDAR et des orthoimages. Mais, une telle approche paraît être inappropriée pour évaluer les nuages de points captés par une plate-forme terrestre, puisqu’elle est censée fournir des données de précision et de résolution beaucoup plus élevée. Concernant l’erreur verticale, d’après [Kaartinen et al., 2012], elle peut être calculée à l’aide d’un modèle numérique de terrain (MNT). 34 Un autre point de vue est mis en avant par [Haala et al., 2008] qui choisissent comme référence des modèles de bâti 3D à partir desquels les surfaces planes seront isolées de manière semi-automatique. Il existe aussi d’autres méthodes indépendantes d’extraction de points de contrôle. Elles amènent à comparer des relevés laser entre eux. [Alshawa 2010] confrontent les données mobiles avec les nuages statiques. Dans la même veine [Mano et al., 2012] appliquent un algorithme nommé LS3D (Least Squares 3D) de [Gruen et Akca, 2005] afin d’évaluer la précision et l’exactitude relative. Dès lors, le recalage rigide basé sur différentes formes extraites depuis les données laser est réalisé. À titre d’explication, nous observons que les trois dernières techniques considèrent l’écart résiduel calculé entre deux nuages de points comme une mesure de qualité. [Feng et al., 2008] élaborent une méthode comprenant l’évaluation qualitative et quantitative des données laser. Dans un premier temps, un contrôle visuel de l’angle entre les façades est effectué. En admettant que les murs adjacents d’un bâtiment forment un angle droit, la qualité est notée comme faible ou élevée en fonction de la déviation observée. Plus le nuage est déformé, plus la valeur d’angle est loin de 90°. La dernière étape vise à vérifier l’exactitude absolue au sein d’une zone de test. À cet effet, des cibles 3D conçues pour faciliter l’extraction de détails caractéristiques sont employées. L’exactitude est déterminée par comparaison de coordonnées de cibles correspondantes : celles mesurées avec une station totale avec celles extraites dans les données laser. [Alshawa, 2010] propose une évaluation de l’exactitude par rapport à différentes références. D’abord, un profil horizontal extrait au niveau du sol du relevé laser est comparé avec l’emprise des bâtiments du plan CAO (plan cadastral 2D). Une autre solution envisagée consiste à rapprocher, par recalage basé sur l’ICP (Iterative Closest Point), les données laser et à calculer la distance résiduelle – l’indice de qualité. Deux approches possibles sont suggérées : la comparaison mobile-statique mais aussi celle mobile-aéroporté. Néanmoins, il est à noter que l’utilisation des données LiDAR comme référence soulève des préoccupations bien qu’un avion soit équipé d'une centrale inertielle de haut de gamme et qu'une réception du signal GNSS ne souffre pas trop de masques. Un nuage LiDAR, ayant souvent une densité moins élevée, est censé avoir une précision relativement supérieure que des nuages mobiles terrestres. Pourtant, en raison du faible recouvrement et d'une densité moins importante de données laser aéroportées, une comparaison basée sur le calcul de distances mutuelles est délicate à entreprendre. Afin de surmonter cet obstacle, il est possible d’ajouter des plans aux sous-nuages afin de déterminer l’écart. Au contraire, quand on utilise un nuage acquis en mode fixe, il est possible de calculer directement des écarts sous forme de distances entre les points du nuage mobile et le maillage généré. Une méthode tout à fait différente est développée par [Williams, 2012]. Elle aboutit à une comparaison des coupes verticales 2D extraites depuis un nuage de points avec celles mesurées à l’aide d’une station totale. Un carrefour a été choisi comme zone de test et quatre profils en travers ont été disposés, un sur chaque aile du croisement. Puis des points équidistants situés le long des profils ont été mesurés. Cette référence a permis de calculer et de comparer des pentes correspondantes. L’évaluation de l'exactitude étant fastidieuse, nous pouvons saisir pourquoi, grâce à quelques approches mises en œuvre par les chercheurs cités ci-dessous. Il est indéniable que la solution la plus répandue consiste à qualifier, sitôt après une acquisition, les relevés laser mobiles. Néanmoins, la précision théorique est aussi abordée pour déterminer, par l’intermédiaire des incertitudes, le facteur a priori affectant les nuages de points [Barber et al., 2008], [Shaer, 2010], [Alshawa, 2010] et [Bitenc et al., 2011]. Puisque les erreurs élémentaires de capteurs interagissent entre elles, la valeur finale suit alors la formule de propagation d'erreurs. Comme nous l’observons dans le Chapitre 3 les sources d’erreurs liées au fonctionnement d’un système mobile sont multiples. [Barber et al., 2008] concluent CHAPITRE 2. Acquisition et qualification de relevés laser 35 qu’elles proviennent principalement de la qualité du positionnement, mais aussi de la justesse des scanners laser et enfin, de manière moins importante, de la synchronisation de ces différentes données. Quant au récepteur GNSS, chaque point de la trajectoire reçoit une estimation de qualité, caractérisant sa contribution à une erreur totale du système. Concernant les scanners laser, à défaut de spécifications techniques suffisantes, fournies par le constructeur et décrivant les éventuelles erreurs, il nous appartient d’opérer un étalonnage. Dans le but de prévoir la précision des nuages de points LiDAR, un modèle de propagation d’erreur a été proposé par [Shaer, 2010]. Il y dévoile quatorze états d’erreurs, à savoir : 1) six erreurs de navigation – trois erreurs de positionnement en absolu, ainsi que trois erreurs d’orientation, toutes estimées lors de la fusion GNSS/INS ; 2) six erreurs d’étalonnage – erreurs résiduelles liées à l’étalonnage de l’ensemble du système dont trois décrivent les bras de levier et d’autres étant associées aux angles boresight ; 3) deux erreurs internes de capteur laser – la précision des mesures d’angles et de distances. La transmission de toutes ces imprécisions suit la formule de géo-référencement direct (2.1) afin de dériver la précision finale. Comme le souligne [Shaer, 2010], les études peuvent être également complétées par une analyse d’influence de la géométrie du balayage sur la qualité des nuages de points. Pour ce faire, nous prenons en compte deux critères : l’angle d’incidence et la taille de l’empreinte laser. Étant donné que la qualité des relevés laser est une accumulation d’erreurs aléatoires et systématiques propagées par le modèle de géoréférencement et celles dues à l’analyse de géométrie, toutes ces composantes contribueront à la valeur globale d’erreur. Cette constatation nous permet d’attribuer un indicateur de qualité unique (nommé q-indicateur) à chaque point laser. La qualification des nuages de points peut être désormais effectuée automatiquement durant l’acquisition (à la volée). [Bitenc et al., 2011] cherchent, eux aussi, à vérifier la précision du système de cartographie mobile terrestre. Leur démarche se traduit par une absence de données pouvant servir de référence fiable, car les études ont été orientées vers la numérisation de dunes sans cesse mouvantes. La procédure mise en œuvre, étant similaire à celle de [Shaer, 2010], fait appel au modèle de géo-référencement direct. Nonobstant, elle se limite, telle que présentée, à l’évaluation de la précision horizontale. Pareillement, les erreurs systématiques du système ont été prises en compte ainsi que la géométrie de balayage performé. 2.4 Expérimentation Comme nous venons de le constater, toutes les méthodes estimant l'exactitude, observées dans la section précédente, visent à acquérir une référence plus précise que les données étudiées. Cette solution prend du temps et semble être coûteuse, nécessitant aussi la recherche de cibles suffisamment bien représentatives. Nous avons relevé ce défi en décidant d’examiner la pertinence de quelques approches similaires à celles relevées dans la littérature. Pour les besoins de nos analyses, nous avons voulu éviter la mise en place de cibles et donc, nous nous sommes référés à des détails caractéristiques d’une scène conçue par l’homme. La zone de test a été choisie à Paris à proximité du Musée d’Orsay. La qualité du nuage de points LARA3Dv2010_Orsay (Figure 2.7) acquis par notre plate-forme mobile pour laquelle : la vitesse approximative était de 5km/h, la résolution des scanners SICK était de 0.25 degré et sa fréquence de 18Hz, a été vérifiée. Comme l’affirme [Deschaud, 2010], la spécificité de ce nuage est la suivante : la distance moyenne entre deux points voisins dans un profil est de 6.7 cm, tandis que celle entre points de profils successifs est égale à 7.4 cm. Le nuage est alors hétérogène et localement anisotrope. En particulier, les distances d’un point à un autre 36 le plus proche varient entre 5 cm à 15 cm. Notre point de départ était l’évaluation qualitative permettant d’observer si les relevés laser subissaient des déformations. Ensuite, l’exactitude a été examinée à l’aide de deux références différentes : un levé topographique Orsay2011_topo, et un nuage de points acquis en mode fixe Orsay2009_statique. Ces données ont été collectées indépendamment après une acquisition mobile comme il a été décrit précédemment (2.2). C'est pourquoi, dans cette section, nous détaillerons toutes les démarches effectuées, ainsi que les avantages et inconvénients des techniques employées. Comparaison avec le levé topographique En raison du manque de géo-référencement – chaque jeu de données n’a pour référentiel qu’un système local - l’estimation de qualité s’est donc limitée à l’exactitude relative. Les levés topographiques ont été ajustés sur un nuage mobile à travers une transformation rigide calculée à partir de trois points de contrôle observables dans les deux ensembles. Dans un premier temps, les relevés laser mobiles ont été étudiés visuellement par rapport à la coupe horizontale mesurée préalablement. Un profil correspondant, dont l’épaisseur était suffisamment large pour inclure celui de référence, a été extrait du nuage de points. Nous avons remarqué que nos données laser étaient suffisamment cohérentes même si elles étaient localement entachées par certaines déformations ; c’est-à-dire, quelquefois étendues en direction du véhicule, puis décalées (Figure 2.20). Cet état de fait est probablement dû aux imperfections liées à l’implémentation du filtre de Kalman à l’étape de géo-référencement, mais aussi aux capteurs de navigation de basse de gamme mise en place (notamment le récepteur GPS mono-fréquence calculant la position sans corrections différentielles). Figure 2.20 Coupe horizontale dans une superposition : levé topométrique (en rouge) – nuage de points (en vert) Pour compléter nos analyses, une évaluation quantitative a été faite à l’aide des points de détails mesurés. Au lieu de nous appuyer sur les coordonnées, comme c’était ordinairement le cas, nous avons pris en compte les distances mutuelles. La longueur de 43 tronçons reliant les points entre eux sous différentes combinaisons était calculée. Les mêmes éléments ont été manuellement retrouvés et mesurés dans le nuage de points mobiles. La comparaison effectuée a démontré que l’exactitude de nos relevés laser mobiles, étant une moyenne des différences de segments contrôlés, était de l’ordre de quelques décimètres. Les chiffres obtenus ont révélé ainsi que les différences absolues ne dépassaient pas 20 cm pour 79% de segments. CHAPITRE 2. Acquisition et qualification de relevés laser 37 Figure 2.21 Diagramme des différences de longueur de 43 segments de contrôle La Figure 2.21 montre les erreurs obtenues en fonction de la longueur de segments comparés. Leur grandeur a été différenciée par des couleurs évoluant avec un intervalle de 10cm. Nous pouvons alors constater que plus le tronçon est long, plus l’erreur mesurée est importante, ce qui revient à dire que le nuage mobile est légèrement étiré. En dépit de cette remarque, une différence de longueur égale ou inférieure à 10cm équivaut à une incertitude avec laquelle nous distinguons les détails dans le nuage mobile, parce que sa résolution moyenne était de 7cm. Quoi qu’il en soit, la sélection de points réalisée de manière interactive demeure le point faible de cette méthode. Cette tâche est fastidieuse dans le cas de nuages de points peu denses, et nécessite un temps de traitement conséquent. D’où aussi une source importante d’erreurs, puisque la faible résolution de nuages de points empêche une identification correcte de détails. Recalage mobile-statique En définitive, comme le suggère [Alshawa, 2010], un recalage rigide basé sur l’ICP a été réalisé. Puisque cet algorithme ne permet pas d’aligner des nuages positionnés et orientés de manière quelconque, comme c’est notre cas, nous avons d’abord recalé grossièrement les deux relevés laser. Tout le traitement a été réalisé à l’aide de Cloud Compare v.2.5.1. Étant donné que le nuage mobile étudié peut être localement déformé à cause d’une qualité temporairement faible du système de positionnement, l’évaluation a été menée de deux façons. Commençant par le recalage global de l’ensemble du nuage, nous avons obtenu une distance moyenne de 18.5cm (calculée sur 26% de points) par rapport à la référence. Pour contrôler la justesse de ce chiffre, quatre coupes transversales ont été créées à des hauteurs différentes afin d’être visuellement vérifiées. Ainsi, une importante perte de qualité du nuage, croissant avec la hauteur de plan sécant, a été notée. Des mesures prises manuellement ont révélé que la distance entre deux nuages de points variait jusqu’à 28.5cm. Figure 2.22 Sous-nuages extraits -0,400 -0,300 -0,200 -0,100 0,000 0,100 0,200 0,300 0 20 40 60 80 100 120 140 Différence [m] Longueur de segments [m]38 De ce fait, l’estimation itérative par morceau, ce qui ramène à découper le nuage de points en six sous fragments comme l’illustre la Figure 2.22, a été effectuée. La comparaison, réalisée séparément entre ces sous-nuages, a indiqué l’exactitude finale du nuage de points égale à 9.6cm (Tableau 2.2). Vu que la partie I était considérablement déformée, nous l’avons exclue du processus de qualification. Tableau 2.2 Distances moyennes calculées pour chaque sous-nuage Jeu de données I II III IV V VI Distance moyenne [cm] pour 75% points 17.2 7.1 11.9 9.8 11.0 9.2 Moyenne [cm] 9.6 Pour conclure, l’utilisation du recalage permet d’évaluer rapidement l’exactitude relative des données mobiles, particulièrement lorsqu'une référence précise est déjà disponible. Néanmoins, si les nuages de points présentaient des déformations locales, dues à la dérive de la centrale et au masquage GNSS, une application d’ICP provoquerait des déplacements encore plus importants entre les données traitées. C'est pourquoi la valeur de distance calculée n’exprimera correctement ni le shift entre les nuages ni l’échelle de ces déformations. 39 CHAPITRE 3 Erreurs relatives au système MMS Sommaire : 3. Erreurs relatives au système MMS .................................................................................. 39 3.1 Analyse des erreurs liées à la cartographie mobile ........................................................... 40 3.1.1 Erreurs causées par le système de positionnement .................................................................. 40 3.1.2 Erreurs dues au capteur laser ....................................................................................................... 41 3.2 Amélioration des relevés laser mobiles ............................................................................... 43 3.2.1 Correction de la localisation en cours d’acquisition ................................................................. 43 3.2.2 Correction en post-traitement ...................................................................................................... 46 3.3 Étalonnage extrinsèque .......................................................................................................... 47 3.3.1 État de l’art sur l’étalonnage des excentricités linéaires ......................................................... 48 3.3.2 Étalonnage des systèmes embarqués de caméras ..................................................................... 49 3.3.3 Étalonnage des systèmes dotés de scanners .............................................................................. 51 3.4 Impact d’un faux étalonnage sur la géométrie du nuage ................................................. 54 3. Erreurs relatives au système MMS Nous discutons, au sein de ce chapitre, de toutes les anomalies pouvant survenir lors du fonctionnement d’un système MMS et entacher les données laser produites. Elles sont dues notamment aux capteurs mal étalonnés, aux facteurs divers influençant la qualité de balayage laser et à l’étalonnage inexact de l’ensemble du système. Il se peut aussi que le système de positionnement ne parvienne pas à acquérir une localisation suffisante pour collecter des données précises au niveau du canyon urbain. En particulier, les masques fréquents GNSS empêchent la bonne réception des signaux. Ces perturbations entraînent une erreur absolue sur l’estimation de la trajectoire du véhicule qui n’est que partiellement compensée par les informations de la centrale inertielle. De ce fait, un décalage (une dérive) entre la trajectoire fournie par le système de positionnement et la trajectoire idéale est observé. Pour pallier cet inconvénient, il existe un certain nombre de méthodes qui s’appliquent en temps réel ou lors de l’étape de post-traitement. Elles visent à améliorer soit le trajet du véhicule, soit les données laser collectées. Néanmoins, en raison du coût relativement élevé, la majorité des solutions apportées consiste à corriger les nuages après l’acquisition, notamment par un recalage fondé sur l’ICP. Étant donné qu’un faux étalonnage extrinsèque influencera la qualité de la localisation et par la suite les relevés laser, nous donnons un aperçu des méthodes étalonnant le système intégral. Nous en Résumé 40 ressortons que la plupart des approches nécessitent une zone de test adéquate, munie de cibles bien reparties et mesurées précisément. Concernant les solutions appropriées lorsque des scanners de profil 2D sont embarqués, elles ne sont pas nombreuses et permettent surtout d’étalonner des systèmes aéroportés ALS. Cependant, dans le cas des systèmes MLS dotés de scanners 2D placés latéralement, nous constatons un manque de souplesse quand il s’agit de numériser un environnement plusieurs fois. Un tel dispositif empêche le balayage multiple d’un même objet à partir de directions opposées. Par conséquent, les méthodes conçues pour les systèmes ALS ne répondent pas aux exigences imposées par les plates-formes terrestres. Pour combler cette lacune, les techniques appropriées doivent être avancées. En dernier lieu, nous démontrons que les écarts d’angles boresight sont observables sur les arêtes extraites, et donc ces dernières pourraient, en théorie, être utilisées pour étalonner le système. 3.1 Analyse des erreurs liées à la cartographie mobile Nous venons de voir dans le chapitre précèdent que chacun des composants du système peut contribuer à la qualité des nuages de points collectés. Parmi les erreurs les plus notables, ce sont celles provenant du système de positionnement intégrant GNSS/INS/DMI. Les autres sources d’anomalies, étant dans la hiérarchie sitôt après le GNSS, viennent du manque de précision des points laser, c’est-à-dire qu’elles sont causées par des erreurs instrumentales imputables au scanner laser lui-même, mais aussi à la nature de l’objet numérisé et à l’environnement. Ces erreurs affectent les mesures angulaires et les distances, nous les assimilons à celles connues par les tachéomètres. Elles peuvent être de types systématiques et aléatoires. Enfin, de manière moins importante, les relevés laser mobiles sont entachés par des erreurs de synchronisation de différents capteurs, et par de multiples imprécisions survenues lors de leur étalonnage intrinsèque. L’étalonnage extrinsèque du système aussi ne peut pas être négligé [Barber et al., 2008]. Dans cette section, les sources d’erreurs les plus fréquentes liées au fonctionnement du système MMS, et par conséquent, pouvant empêcher la chaîne d’acquisition, vont être présentées. Il s’agit des erreurs provoquées par le système de positionnement (3.1.1), aussi bien que celles dues au scanner laser (3.1.2). La compréhension des relations entre l’environnement et la grandeur d’erreur survenue est nécessaire pour quantifier la précision des données. 3.1.1 Erreurs causées par le système de positionnement Le système de positionnement est, parmi les autres capteurs, l’élément le plus prédisposé à être affecté par des erreurs [Glennie et al., 2007]. Nous discuterons dans ce paragraphe des problèmes typiques liés à son fonctionnement. La fusion multi-capteurs a pour finalité d’optimiser la précision de la position calculée en profitant d’un capteur pour pallier aux défauts des autres, notamment en recalant en permanence la dérivée de l’IMU par l’information GNSS, voire de fournir une trajectoire même en l’absence de signal GNSS. Pour mettre en évidence les erreurs propres aux capteurs, nous observerons deux composants principaux du système : le positionnement par GNSS et la navigation inertielle INS. Dans le cas d’un système mobile de cartographie, le positionnement à corrections différentielles dGPS se trouve être le plus répandu. Une telle solution permet, par défaut, de réduire plusieurs erreurs inhérentes au système telles que celles d’horloges, d’éphémérides, la propagation du signal dans l’ionosphère et la troposphère. Pourtant, la qualité de la position demeure toujours fortement liée à la configuration des satellites, c’est-à-dire à leur constellation. Des satellites uniformément répartis sont une situation préférable contrairement à celle où ils se retrouvent tous dans la même portion du ciel. La dégradation de la précision géométrique GDOP (Geometric Dilution Of Precision) est un indice quantifiant cet impact. Il faut encore mentionner les problèmes des multi-trajets et ceux des masques CHAPITRE 3. Erreurs relatives au système MMS 41 GNSS, inextricablement liés à des canyons urbains. Ces derniers sont dus au blocage du signal, engendrés par les arbres, les tunnels ou les hauts bâtiments. Tandis que les premiers provoquent des erreurs dans la mesure de distance entre le satellite et le récepteur, pouvant atteindre plusieurs mètres (mesures de pseudo-distance) ou quelques centimètres (mesures de phase), les trajets multiples sont difficiles à éliminer puisque les conditions de réflexions des signaux sur des surfaces ne sont pas les mêmes d’un site à l’autre [Abuhadrous, 2005]. La centrale inertielle sert en permanence au calcul de trajectoire. La navigation inertielle étant un système autonome, son avantage est d’avoir une bonne précision à court terme, sans aucune information extérieure. En revanche, ces capteurs sont peu fiables, s’il s’agit de positionnement sur une longue période de temps. Cet état de fait est causé par trois principales sources d’anomalies : des erreurs d’alignement initial (pour les angles roulis, tangage et lacet), des erreurs de capteur inertiel (dérive de gyromètres, biais d’accéléromètres) et de calcul [Titterton et Weston, 2004]. Toutefois, la question de la précision de la centrale inertielle est bien plus complexe qu’il n’y paraît. Mais, les fabricants n’exposent guère le modèle mathématique de calcul de la mécanisation et de la compensation de l’INS. En fin de compte, toutes les plates-formes mobiles se localisant grâce à des systèmes hybrides GNSS/INS souffrent d’un biais observable entre les nuages de points redondants. Les pertes temporaires du signal GNSS s’avèrent être la cause d’un décalage dans l’estimation de la trajectoire du véhicule. Pareillement, les données laser récoltées avec un système LiDAR aérien sont encombrées par des écarts planimétriques et altimétriques, résultant, cette fois-ci, de la dérive (drift) de la centrale inertielle. 3.1.2 Erreurs dues au capteur laser Plusieurs sources d’erreurs peuvent affecter les données acquises par un scanner laser seul. De plus, elles varient d’un instrument à l’autre et dépendent de la qualité du dispositif et de son étalonnage. Ce dernier ayant pour but de corriger les erreurs systématiques inhérentes au système, l’étalonnage doit être régulièrement effectué et non seulement lors de la première utilisation. Aussi, les spécifications techniques transmises par les constructeurs de scanners doivent être vérifiées, puisqu’elles sont obtenues dans des conditions idéales de mesures et ont tendance à être surestimées. Pour pouvoir estimer l’exactitude/la précision de chaque point laser, il faut considérer l’ensemble des facteurs intervenants. [Steiger, 2005] propose, conformément au schéma affiché par la Figure 3.1, de lister toutes les caractéristiques importantes influençant la qualité des nuages de points. La discussion exhaustive, concernant le principe du balayage laser terrestre, mais aussi toutes les sources d’erreurs inhérentes au fonctionnement d’un scanner, est présentée par [Pawleta et Igielska, 2009], [Boulaassal, 2010], [Landes et Grussenmeyer, 2011] et [Landes et al., 2012]. Puisqu’un scanner laser effectue des mesures au même titre que le ferait un tachéomètre, aussi leurs modèles s’avèrent relativement semblables. Plus précisément, il est préférable de mettre en évidence deux caractéristiques – l’imprécision d’angles et de distance. Les deux angles (vertical et horizontal) souffrent des erreurs typiques d’un tachéomètre comme l’erreur de collimation horizontale, l’erreur d’index et l’inclinaison de l’axe vertical. Mais, l’incertitude de la distance est indépendante de celle des angles, car le principe des mesures de chaque grandeur est différent. Parmi ces erreurs, le facteur d’échelle et l’erreur de zéro peuvent être cités. La qualification de la précision de mesure angulaire s’effectue en mesurant de courtes distances verticales et horizontales entre les cibles déployées (p.ex. des sphères). Celles-ci sont comparées ensuite aux mesures de référence obtenues grâce à des appareils beaucoup plus précis. De son côté, l’exactitude de mesure des distances est aussi vérifiable. Étant donné que le bruit affectant le nuage de points lui donne une certaine épaisseur, l’une des façons de le mesurer consiste à balayer une cible plane orientée perpendiculairement au 42 scanner laser. L’exactitude sur la mesure de distance, exprimée en tant que l’écart-type, peut ainsi correspondre à la dispersion des points autour du plan moyen. Figure 3.1 Sources d’erreurs sur des mesures avec le scanner laser terrestre *facteur valable uniquement pour le balayage laser statique De surcroît, d’autres facteurs ayant un impact sur les points mesurés méritent d’être également envisagés tels que la résolution spatiale, la portée (la distance minimale et maximale à laquelle le scanner laser est capable de fournir des mesures fiables), la taille de l’empreinte laser, l’impact de différentes propriétés des matériaux composant la surface, le problème d’angle d’incidence et la rencontre par faisceau laser d’une arête (échos moyennés). Plusieurs études concernant le comportement du faisceau laser sur les surfaces composées de multiples matériaux ont été effectuées entre autres par [Boehler et al., 2003], [Hanke et al., 2006], [Feng et al., 2008], [Hiremagalur et al., 2009], [Pawleta et Igielska, 2009] et [Boulaassal, 2010], [Landes et al., 2012]. La caractéristique prise en compte était la couleur, le type de matériel (papier, verre, bois, métal, crépis, pierre), son humidité et sa rugosité. Différentes cibles ont été proposées (Figure 3.2) non seulement pour tester la performance des scanners laser existants, mais aussi pour les comparer. Les résultats obtenus montrent que l’élément influençant davantage la qualité est la réflectivité de l’objet à une longueur d’onde et l’orientation de l’objet envers le capteur laser [Pesci et al., 2008]. Une source d’erreurs significatives, à laquelle il nous faut faire attention, est la manière avec laquelle un matériau numérisé renvoie la lumière laser. Tandis que le retour depuis les surfaces blanches est fort, la quantité de lumière retournée par celles noires est beaucoup plus faible. Des matériaux très réfléchissants tels que le marquage au sol, les diapositifs rétro-réfléchissants peuvent produire aussi des effets supplémentaires comme la saturation et le flou lumineux CHAPITRE 3. Erreurs relatives au système MMS 43 (bloom effect) [Vosselman, 2010]. La saturation étant causée par un excès d’énergie renvoyée, elle apparaît sous forme de points répartis le long de la ligne de visée. Cependant, le flou lumineux se manifeste par un élargissement de l’objet [Williams, 2012]. Pour résumer, la réflectance d’un objet (albédo) joue sur la quantité de lumière reçue par l’instrument après réflexion, en lui permettant de faire la mesure. De manière générale, plus le signal rétrodiffusé est faible (que ce soit par réflectivité faible du matériau ou bien encore par angle d’incidence), plus l’observation sera bruitée. Les analyses de [Soudarissanane et al., 2009] montrent que, dans un cas pratique, un angle d’incidence inférieur à 60 degrés prévaut sur la qualité des nuages de points. Figure 3.2 Exemple de cibles permettant de tester la performance du scanner laser terrestre :a) Précision angulaire ; b) Angle d’incidence ; c) Échos moyennés – effet de bord (edge effect) ; d) Résolution ; e) Réflectance [Boehler et al., 2003] 3.2 Amélioration des relevés laser mobiles C’est sur cette base que nous observons une nécessité d’améliorer les résultats produits par un système de cartographie terrestre MLS. Au regard des solutions apportées, conçues à cet effet, il semble raisonnable de les élaborer en deux paragraphes. La section 3.2.1 se penchera sur les approches visant à renforcer la précision du système de positionnement en temps réel. Les techniques appliquées lors de l’étape de post-traitement seront discutées dans la section 3.2.2. Cependant, la problématique d’étalonnage extrinsèque est élaborée séparément (3.3). 3.2.1 Correction de la localisation en cours d’acquisition Pseudolites (PL) Puisque la qualité des données « mobiles » est déterminée par la précision du positionnement, la performance de l’ensemble du système en dépendra aussi. Le système intégré GNSS/INS joue un rôle important, mais en même temps, son fonctionnement peut se voir affecté du fait des obstructions du signal GNSS dans un environnement urbain (atténuations, masquages, trajets multiples). Aussi, un nombre suffisant de satellites dits « visibles » ne peut pas être garanti partout. De plus, même si certains satellites, situés sur l’horizon, sont censés être suivis, nous remarquons que leurs signaux sont entachés par un bruit assez élevé. Une méthode tenant à déployer une constellation locale de satellites grâce à une augmentation des niveaux de signaux GNSS a été mise au point. Son but est d’améliorer la précision de la localisation, mais aussi de rendre accessible le signal GNSS en intérieur (localisation en indoor). Il s’agit des pseudolites (pseudo-satellites), à savoir des émetteurs terrestres de signaux dont le format est identique ou similaire à ceux émis par les satellites. La portée de ces signaux est variable - elle dépend de leur puissance et de leur utilisation. Le principe est de mettre en place, dans une zone dite de « contraintes » non couverte par le GNSS, des transmetteurs permettant à un récepteur d’acquérir un nombre suffisant de signaux et de calculer sa position 3D. Autrement dit, les émetteurs jouent localement le rôle des satellites et leurs signaux sont traités de la même manière que ceux des satellites. La Figure 3.3 illustre le principe de positionnement avec un réseau de pseudolites (ܲܵ௜). 44 Figure 3.3 Positionnement des pseudolites en : a) indoor (Image reproduite à partir de [Vervisch-Picois, 2010]) ; b) outdoor Plusieurs équipes à travers le monde travaillent sur la localisation avec les pseudolites. Parmi les derniers travaux concernant la localisation en indoor, nous pouvons citer ceux présentés par [Vervisch-Picois, 2010], [Selmi, 2013]. Néanmoins, l’efficacité d’une telle solution, c’est-à-dire la fusion GNSS/PL/IMU pour les besoins du système mobile terrestre MMS a été aussi testée par [Wang et al., 2001], [Babu et Wang, 2009] et [GrejnerBrzezinska et al., 2010]. Le concept de la mise en œuvre des pseudolites est toujours en cours de développement, mais les résultats obtenus montrent déjà leur potentiel. [Ning et al., 2007] affirment que les mesures effectuées à l’aide de pseudolites ont un facteur DOP (Dilution of precision) réduit d’au moins 35%. En revanche, comme l’explique [Selmi, 2013], la nécessité de synchroniser les pseudolites constitue la phase la plus coûteuse et la plus complexe de cette technique. Terrain Referenced Navigation (TRN) Le Terrain Referenced Navigation System (TRN) sert à calculer la position de la plate-forme en mouvement (avion, UAV, véhicule), en comparant sa position actuelle par rapport au sol, sans recourir au GNSS dont le signal peut être brouillé par l’ennemi (application militaire), ou voire tout simplement indisponible. Dans ce cas, il nous faut fournir des outils de navigation alternative, lorsque le système GNSS n’est plus joignable. En l’absence de données GNSS, la localisation d’un véhicule est habituellement réalisée en utilisant une combinaison d’odométrie roue (DMI) et de capteurs inertiels. Par contre, une telle solution a deux limitations principales : les centrales inertielles sont sujettes, au fil du temps, à la dérive, et le DMI reste sensible aux dérapages et aux glissements de roues. De plus, l’odométrie roue ne donne qu’une information 2D dans le plan de la route. Grâce au TRN, la position et l’attitude sont déterminées, toutes deux étant un support à la navigation inertielle. L’idée consiste donc à combiner la navigation inertielle avec les informations provenant directement du terrain. La performance d’un tel système dépendra de la qualité du capteur INS employé. Plus il est exact, plus précise sera la position calculée. Il existe plusieurs approches permettant d’établir la navigation TRN y compris le filtre de Kalman étendu (EKF), le filtre de Kalman inodore (UKF) ou le filtre particulaire [Lee et al., 2013]. Des informations de la scène provenant des images/nuages de points sont employées CHAPITRE 3. Erreurs relatives au système MMS 45 afin d’estimer la trajectoire du véhicule, tout en se référant à des méthodes de l’odométrie visuelle. Or, le déplacement relatif d’un capteur optique (caméra, télémètre laser) entre deux points de vue sera déterminé à travers une analyse des images successives. Les méthodes existantes visent à identifier les « features » (amers) sous forme de points, lignes ou surfaces pour les mettre ensuite en correspondance. Cette tâche n’étant pas triviale, il existe plusieurs techniques susceptibles d’être appliquées. Dans le cas de l’odométrie basée vision, le mouvement est estimé à partir d’une séquence d’images après la mise en correspondance robuste de points d’intérêts du type Harris [Harris et Stephens, 1988], SIFT (Scale-Invariant FeatureTransform) [Lowe, 2004], ou SURF (Speeded Up RobustFeature). Aussi, l’algorithme d’ICP (Iterative Closest Point) permettant de recaler toute sorte d’entités géométriques entre elles (2D et 3D) peut être utilisé. Pour plus d’informations concernant l’odométrie 3D basée LiDAR et vision, le lecteur pourra se référer à [Frémont, 2009]. Néanmoins, comme le constatent [Toth et al., 2009], le rapport du TRN avec les applications de la cartographie mobile est double : 1) La localisation précise en position et en orientation (en temps réel) se base sur l’extraction de caractéristiques et elle dépend tout particulièrement de la capacité de la procédure d’isolement des objets mobiles parmi ceux étant statiques. En effet, dans un environnement routier, plusieurs objets sont en mouvement (piétons, automobiles, cyclistes, motos, etc.) et conjointement avec la dynamique propre du véhicule (accélération, décélération), ils constituent un challenge supplémentaire, pouvant altérer la perception. 2) L’utilisation de données déjà existantes telles que des modèles numériques de terrain (MNT), des données vectorielles et du SIG (Système d’Information Géographique) peut indubitablement soutenir les processus d’extraction de caractéristiques. D’après [Toth et al., 2009], l’utilisation du TRN présente plusieurs intérêts. Mais, il y a des défis à relever pour rendre cette navigation opérationnelle dans des environnements complexes de cartographie mobile. Tout d’abord, la grande quantité de données à traiter (Big Data) reste un objet certain de préoccupation. Ensuite, le traitement en temps réel pose un vrai problème tant en terme de capacité que de complexité d’espace numérisé contenant une variété d’objets provenant de dynamiques différentes. Toutefois, une solution semblable est aussi proposée par [Narayana, 2011]. Il emploie, comme outil complémentaire à la localisation, des scanners laser de profil 2D. Son approche peut être assimilée à la solution conçue pour la localisation en intérieur d’un robot ou d’un véhicule autonome - connue sous le nom de cartographie et de localisation simultanées (SLAM). L’ensemble des démarches mises en œuvre fait appel à l’odométrie basée laser, puisque le déplacement relatif est mesuré par rapport à des propriétés invariables de l’environnement balayé par scanner. Notamment les surfaces planes fortement présentes dans les environnements aménagés par l’homme, sont utilisées pour en déduire un mouvement en 3D. Autres solutions moins complexes Nous venons d’observer un exemple de solutions à l’aide de localisation qui s’avèrent assez complexes lors de l’étape de l’implémentation. Alternativement [Zampa et Confortie, 2009], font appel à une technique couramment utilisée. Il s’agit d’augmenter la précision de la trajectoire à travers des stations de référence GNSS supplémentaires mises en place. De plus, des points de contrôle déployés tous les 50 à 80 mètres le long du trajet servent ultérieurement à corriger les relevés laser. Une approche tout à fait similaire a été aussi décrite par [Gandofi et al., 2008], sauf que la position optimale des stations GNSS a été retrouvée grâce à des « pré-acquisitions » réalisées quelques jours auparavant. En dépit de 46 tous les avantages de cette solution, l’emplacement des stations de contrôle au sol s’avère très coûteux. 3.2.2 Correction en post-traitement Le second groupe de techniques d’amélioration de performance de système mobile contient des outils permettant la correction de données en post-traitement. Les travaux de [Tournaire et al., 2006], [Ridene, 2010] et [Monnier et al., 2013] s’appuient sur un recalage entre les données mobiles et les bases de données géographiques mieux géopositionnées mais beaucoup moins détaillées. [Tournaire et al., 2006] améliorent l’étape de géo-référencement du véhicule à l’aide de l’imagerie aérienne (résolution d’au moins 20cm). Les informations 3D extraites des stéréos – paires sont fusionnées avec celles des orthoimages. À cet égard, des marquages au sol, à savoir les passages piétons, ont été détectés et reconstruits à partir de ces deux types de données image. Ensuite, les coordonnées 3D des points extraits du marquage au sol ont été incorporées lors de la triangulation photogrammétrique (Photogrammetry Bundle Adjustment) afin de corriger la localisation absolue des images terrestres. [Ridene, 2010], quant à lui, examine des solutions permettant de mettre en cohérence différents types de données. Il propose certains scénarios de corrections de relevés laser mobiles par rapport à des données externes au système de cartographie mobile (p.ex. nuage de points statique, modèle numérique de surface). Il s’agit du recalage rigide de la famille ICP des données 3D. Enfin, le processus de [Monnier et al., 2013] se base sur un recalage non rigide fondé, lui aussi, sur le principe d’ICP d’un point à un plan. L’hypothèse que l’erreur de positionnement varie lentement, au fil du temps, de façon non linéaire a été faite. Dès lors, la trajectoire de la plate-forme est déformée itérativement, morceau par morceau, afin de minimiser la distance des points du nuage mobile aux primitives planes du modèle. Ce dernier constitue une base de données géographiques (2D ou 3D) composée de primitives ponctuelles (poteaux, repères de nivellement, sommets d’objets polyédriques), linéaires (arêtes, cadastre, limites de trottoirs) ou bien encore surfaciques (faces d’objets). Nous pouvons aussi nous confronter aux méthodes semblables à celles de l’odométrie visuelle, mais cette fois-ci, appliquées après les acquisitions. [Cazzaniga et al., 2007] développent une solution s’inspirant de la photogrammétrie, particulièrement de la stéréovision. Leur approche est assez limpide. Il s’agit de comparer la position de la caméra calculée à partir des images stéréoscopiques avec celle prévue par le système de positionnement GNSS/INS. Plus précisément, le but est d’évaluer les éléments d’orientation externe (EOZ) déterminés indépendamment pour identifier et corriger les interruptions temporaires dans la réception du signal GNSS. De même [Shi, 2008] suggère d’effectuer la triangulation des images à partir des points de contrôle précis, extraits, cette fois-ci, à partir des données fusionnées images/laser - afin d’améliorer la position et l’orientation de la caméra. [Yousif et al., 2010] étudient la validité de théorie de l’assimilation de [Reichle, 2008] pour renforcer le positionnement du véhicule. Selon cette théorie, le processus mis en œuvre vise à s’appuyer sur la corrélation existante entre deux observations différentes d’un phénomène de manière à obtenir la meilleure estimation de l’état réel. C’est pourquoi deux nuages de points acquis lors d’un trajet aller-retour au sein de la même zone sont intégrés. [Alshawa, 2010] envisage une méthode radicalement différente. Un récepteur GPS de « haute sensibilité » (HSGPS) est utilisé simultanément avec un GPS différentiel (dGPS). Ce premier étant moins précis, il fournit, contrairement au dGPS, des informations en continu sur la trajectoire. Pour pouvoir traiter une telle configuration, les trajets déterminés indépendamment par deux récepteurs sont comparés. D’abord, l’écart entre ces échantillons est réduit en appliquant, à des données moins précises, une transformation permettant de les CHAPITRE 3. Erreurs relatives au système MMS 47 faire coïncider avec celles ayant la précision plus élevée. Une fois les trajectoires fusionnées, une courbe ajustant au mieux ces données, est retrouvée. La dernière étape nous amène à interpoler des points du trajet. Autre possibilité [Narayana, 2011] présente une méthode visant à corriger, par lissage des données, la trajectoire enregistrée, puisqu’elle souffre de certaines erreurs provoquées par des limitations de capteurs de positionnement. Il en conclut qu’une telle solution étant insuffisante pour surmonter les problèmes dus aux lacunes GNSS, que celle-ci peut être toutefois très utile pour corriger les sauts d'altitude et les anomalies d'azimut (lacet) de la trajectoire enregistrée. 3.3 Étalonnage extrinsèque L’étalonnage géométrique des systèmes mobiles basés sur LiDAR revient à estimer et à éliminer les erreurs systématiques qui affectent les nuages de points collectés. Ces erreurs sont causées par les biais de paramètres du système, notamment le biais des paramètres de montage de capteurs (relations spatiales entre les modules), ainsi que par les incertitudes des mesures d’angles et de distance inhérentes aux composantes du scanner utilisé [Habib et al., 2011]. L’étalonnage dans le contexte des systèmes mobiles désigne alors deux pistes à suivre : 1) l’étalonnage de chaque scanner laser (étalonnage intrinsèque) ; 2) l’étalonnage du système intégral (étalonnage extrinsèque). L’étalonnage extrinsèque contient des procédures nécessaires pour estimer les constantes de calcul, à savoir la position et l’orientation des capteurs de perception (caméra, laser) dans le repère lié à la centrale inertielle (b). Nous les exprimons par : trois composantes de translation ݎ௕/௦ ௕ (excentricité linéaire entre le centre de l’unité inertielle IMU et le centre du scanner), et trois en rotation ܴ௦ ௕ (matrice de boresight). Au-delà, nous pouvons mentionner d’autres excentricités linéaires (bras de levier) entre les capteurs de localisation, à savoir la distance ݎ௕/ீேேௌ ௕ entre le centre de phase de l’antenne GNSS et le centre de masse de l’IMU, et la distance ݎ௕/஽ெூ ௕ entre le centre de l’IMU et l’odomètre. Lors de l’étape de géo – référencement direct (formule 2.1), ces deux paramètres servent à calculer la trajectoire de la plate-forme dans le repère local (M). L’étalonnage réalisé avec beaucoup de soin, est alors indispensable pour, d’une part rendre le système opérationnel, d’autre part pour fournir des données de qualité élevée. Sinon, chaque erreur commise dans l’étalonnage du système intégral influencera la qualité de la localisation, et par suite les relevés laser. Cette section donnera un aperçu des méthodes récentes d’étalonnage extrinsèque d’un système mobile de cartographie, et expliquera brièvement leurs principes. Puisque les translations peuvent être souvent déterminées par des mesures conventionnelles, nous présentons l’une des solutions envisageables. Concernant les composantes en rotation ൫݁ݔ, ݁ݕ, ݁ݖ൯ formant la matrice de boresight ܴ௦ ௕, celles-ci doivent être déterminées indirectement. Cette résultante est due au fait qu’il s’avère impossible de les mesurer en utilisant des instruments employés habituellement pour les levés topographiques et géodésiques. Il existe plusieurs approches permettant d’estimer des excentricités angulaires, mais la majorité nécessite une zone de test munie de cibles uniformément réparties et mesurées. Nous aborderons, au sein de cette section, les techniques existantes en les regroupant en deux catégories : 1) celles dédiées aux systèmes basés sur les caméras (3.3.2) ; 2) celles appropriées aux systèmes embarqués des scanners laser (3.3.3). Ensuite (3.4), nous présenterons une étude d’impact d’un étalonnage imprécis sur la géométrie des arêtes extraites. Les notations employées ont été précédemment expliquées avec la Figure 2.3, dans le Chapitre 2. 48 3.3.1 État de l’art sur l’étalonnage des excentricités linéaires L’une des manières de connaître les excentricités linéaires est de les mesurer tout simplement à l’aide des techniques traditionnelles (tachéomètre, récepteur GNSS, etc.). Une seule condition requise est de pouvoir mener une observation directe des points caractéristiques. Les deux cibles visées doivent alors être visibles et identifiables. Autrement, l’étalonnage demeure assez compliqué à effectuer et les grandeurs ne pourront pas être déterminées avec une précision suffisante. La Figure 3.4 illustre une procédure concevable pour mesurer le bras de levier entre l’antenne GNSS et la centrale inertielle. C’est une adaptation de l’approche discutée par [Shear, 2010] et utilisée, par défaut, lors de l’étalonnage des systèmes aériens ALS. Figure 3.4 Procédure pour déterminer le bras de levier entre les capteurs de localisation Après avoir fait des mesures GNSS et tachéométriques, les translations ݎ௕/ீேேௌ ௕ se calculent comme suit : ேேௌீ/௕ݎ ௕ ൌ ܽோாி ௕ െ ܴ௟ ௕ܴெ ேௌௌீ/௕ݎ ௟ ெ (3.1) où : ܽோாி ௕ : offset fourni par le constructeur en raison de l’impossibilité d’observer le centre de l’IMU ேேௌீ/௕ݎ ெ : position de l’antenne GNSS déterminée dans le repère terrain (M) CHAPITRE 3. Erreurs relatives au système MMS 49 ܴ௟ ௕ : matrice de passage du repère lié à l’IMU (b) vers le repère véhicule (l), définie par trois angles (roulis, tangage et lacet) ܴெ ௟ : matrice de rotation permettant un changement du repère véhicule (l) au repère terrain (M), calculée selon la formule ܴெ ௟ ൌ ሺܴ௟ ௘ሻ௧ܴெ ௘ Également, toutes les excentricités linéaires notamment ݎ௕/௦ ௕ et ݎ௕/஽ெூ ௕ peuvent être spécifiées à travers une telle procédure. Comme l’affirment [Ellum et El-Sheimy, 2002], [Shear, 2010] et [Li-Chee-Ming et al., 2011], la principale limite de cette méthode est l’impossibilité à observer directement les centres de capteurs. De ce fait, les bras de levier seront connus avec une précision centimétrique. C’est pourquoi cette approche peut être parfois insuffisante et le calcul des paramètres doit se faire d’une autre manière. 3.3.2 Étalonnage des systèmes embarqués de caméras Les premiers systèmes mobiles de cartographie étaient conçus pour recueillir des informations sur un environnement en se servant des images. Leur principe consistait à adapter des algorithmes bien connus dans le domaine de photogrammétrie. Il s’agissait alors de mettre en pratique une stéréoscopie permettant de reconstituer le relief de la scène à partir d’images prises sous différents points de vue de l’objet. En conséquence, la question de l’étalonnage des systèmes basés sur des caméras était largement discutée dans la littérature. Excentricités angulaires Afin d’identifier les excentricités angulaires, deux méthodes semblent être le plus souvent évoquées [El-Sheimy, 2011]. La première possibilité nommée « 1-step » amène à incorporer les trois paramètres de rotation ൫݁௫, ݁௬, ݁௭൯ (3.2) comme inconnues supplémentaires, dans un ajustement par faisceaux, ou dans une compensation par moindres carrés. ܴ௦ ௕ ൌ ܴ௭ሺ݁௭ሻܴ௒൫݁௬൯ܴ௑ሺ݁௫ሻ (3.2) Une autre solution, plus répandue, est le procédé « 2-step ». Il comprend deux étapes principales. Dans un premier temps, nous déterminons, pour chacune des images, deux matrices de rotation : 1) ܴ௕ ெ du repère lié à la centrale inertielle (b) vers le repère terrain (M). Elle représente les mesures de l’IMU effectuées lors de l’acquisition. 2) ܴ௦ ெ du cadre capteur (s) vers le repère terrain (M). Ses composants sont calculés par une terra-triangulation assistée par GNSS. Ensuite, les deux matrices, c’est-à-dire, celle dérivée de l’IMU et celle déterminée par photogrammétrie, sont comparées selon la formule : ܴ௦ ௕ ൌ ൫ܴ௕ ெሺݐሻ൯ ିଵܴ௦ ெ (3.3) Pour chaque image prise, il en découle une matrice de boresight ܴ௦ ௕. La moyenne de ses éléments individuels correspond aux excentricités angulaires recherchées. Néanmoins, il faut noter qu’il apparaît impossible de prendre la moyenne directement puisque la matrice de rotation n’est probablement pas orthogonale. Elle doit être d’abord représentée par les angles eulériens ou par les quaternions afin de pouvoir reconstruire la matrice de boresight finale. 50 Bras de levier Le classement des méthodes étalonnant les excentricités linéaires entre les caméras et le centre de navigation ressemble à celui évoqué pour les excentricités angulaires. Se référant à des techniques indirectes, ces paramètres sont calculés soit pendant l’ajustement : ௦/௕ݎ ௕ ൌ ሺݔ௦ ெ, ݕ௦ ெ, ݖ௦ ெሻ் (3.4) soit, pour chaque image ; la position dérivée par système intégré GNSS/INS/DMI sera comparée avec celle fournie par la terra-triangulation : ௦/௕ݎ ௕ ൌ ሺܴ௦ ெሻିଵ ∙ ൫ݎ௕/ீேௌௌ ெ ሺݐሻ െ ݎ௦ ெ൯ (3.5) Enfin, la moyenne de tous les paramètres obtenus décrira l’excentricité linéaire ݎ௕/௦ ௕ . Aperçu des méthodes Le Tableau 3.1 récapitule quelques approches récentes traitant du sujet de l’étalonnage. Leur exactitude dépendra fortement de la zone de test qui doit être appropriée en vue d’utiliser simultanément le positionnement par GNSS et la photogrammétrie. Pour pallier le problème de blocage du signal GNSS, [Hassan et El-Sheimy., 2008] suggèrent de placer sur un véhicule un prisme réflecteur et de le suivre avec une station totale en utilisant le mode continu de mesure (tracking). Cette information constituera un support au système de navigation inertielle travaillant de façon automne. Tableau 3.1 Exemple de travaux étalonnant indirectement les deux types d’excentricités : caméra/IMU Auteurs Zone de test Excentricité linéaire Excentricités angulaires [Li-Chee-Ming et al., 2011] Amers naturels Procédé « 2-step » [Rau et al., 2011a] 67 cibles Nouveau procédé « 1-step » pour l’étalonnage des systèmes multicaméras [Rau et al., 2011b] Cibles déployées sur les façades Procédé « 2-step » [Chen et al., 2013] Deux zones de test, chacune munie de points de contrôle Indoor-et-outdoor étalonnage (procédé 2-step) Les études comparatives entre les techniques existantes ont été effectuées par [Ellum et ElSheimy, 2003] et [Rau et al., 2011a]. Le Tableau 3.2 résume leurs observations, en juxtaposant les avantages et les inconvénients propres à chaque méthode. CHAPITRE 3. Erreurs relatives au système MMS 51 Tableau 3.2 Synthèse des approches d’étalonnage Méthode Avantage Inconvénient Mesures conventionnelles (bras de levier uniquement) Indépendant de l’ajustement Observation ardue du centre de capteurs « 2-step » prendre la moyenne des résultats obtenus simultanément par le système hybride GNSS/INS et la photogrammétrie Conception simple, sans modifications apportées au modèle d’ajustement Zone de test munie de cibles précises et uniformément réparties « 1-step » insérer des paramètres d’étalonnage comme des inconnus supplémentaires dans un ajustement Matrice de covariance contenant une information complète La corrélation avec d’autres paramètres implique que les résultats peuvent ne pas être fiables. Modifications indispensables au niveau du modèle mathématique. L’étalonnage du système multi-caméras est aussi abordé par [Cannelle et al., 2012]. Leur objectif est d’estimer, à la fois, les excentricités entre les caméras mises en place, ainsi que celles existantes par rapport au système de positionnement GNSS/IMU. À cet effet, deux méthodes sont discutées et comparées. La première, nommée « OFF-line », consiste à étalonner séparément chaque caméra. Pour ce faire, une zone de test équipée de cibles 3D dont les coordonnées sont connues avec la précision submillimétrique, servira de référence. Ensuite, les paramètres pourront être déterminés en adaptant une méthode similaire à l’ajustement par faisceaux. L’autre démarche est l’étalonnage « ON-line » qui s’avère une solution entièrement automatique, ne nécessitant plus de points de contrôle. Il est fondé sur les images prises durant l’acquisition à partir desquelles les points d’intérêt sont extraits et appariés (p.ex. à l’aide de l’algorithme SIFT). Les tests effectués par les auteurs montrent que les deux approches fournissent des résultats assez similaires. L’étalonnage dit « ONline » est exact et efficace. Mais, il peut être peu fiable lorsqu’il est employé dans un environnement empêchant une extraction de points d’intérêt (forêt, etc.). 3.3.3 Étalonnage des systèmes dotés de scanners Les approches dédiées à l’étalonnage des systèmes dotés d’un LiDAR (MLS et ALS) peuvent être appropriées, en fonction du type de scanner embarqué, soit pour un scanner à double balayage (3D), soit pour un scanner de profil 2D. Cette section esquissera quelques travaux se rapportant à ce sujet. Tandis que les techniques conçues pour les scanners 3D s’inspirent de celles développées pour les systèmes basés sur des caméras, la problématique d’étalonnage d’une plate-forme MLS équipée des scanners 2D est assimilée à celle d’étalonnage d’un ALS. C’est dans cet esprit que [Talaya et al., 2004] déploient des cibles réfléchissantes dont les coordonnées sont connues. Ensuite, ils adaptent la technique similaire au procédé « 1-step » afin de déterminer les excentricités linéaires et angulaires entre le scanner laser 3D et le système de positionnement. D’après [Chan et al., 2013], les techniques récentes d’étalonnage des excentricités angulaires ൫݁௫, ݁௬, ݁௭൯ peuvent être classifiées, compte tenu du principe d’estimation, en deux catégories : 1) l’estimation au sens des moindres carrés, fondée sur les primitives planaires introduisant 52 des contraintes lors de l’ajustement [Filin, 2003], [Skaloud et Lichti, 2006], [AtanacioJiménez et al., 2011], [Glennie, 2012], [Chan et al., 2013] ; 2) le recalage par ICP minimisant l’écart entre les points d’une surface (plane ou non plane) extraite à partir de données laser redondantes [Rieger, 2010], [Habib et al., 2010], [Kumari, 2011]. Une autre classification, répandue au sein de la communauté LiDAR, est donnée par [Habib et al., 2011]. Ainsi, deux procédures sont distinguées : 1) system-driven (étalonnage) ; 2) data-driven (ajustement des bandes). L’approche « system-driven » se réfère au modèle physique de capteurs permettant d’effectuer des liens entre les mesures des dispositifs individuels d’un système et les coordonnées terrain (M) des nuages de points générés. Vu que l’accès à des données brutes peut être limité, le développement des méthodes « data-driven » utilisant uniquement des coordonnées XYZ du nuage, est devenu nécessaire. Or, les effets des erreurs systématiques sont modélisées par une transformation arbitraire entre les bandes LiDAR et le repère de référence. [Habib et al., 2010] et [Habib et al., 2011] proposent deux solutions alternatives pour l’étalonnage des systèmes ALS. Elles étaient nommées respectivement : 1) Simplified Method ; 2) Quasi-rigorous Method. La première, étant une approche dite « data driven », requiert des bandes parallèles LiDAR acquises au sein d’une zone avec un faible dénivelé. En revanche, la seconde procédure, ne nécessitant plus le strict respect des plans de vol (bandes non parallèles autorisées), exige des nuages de points horodatés, ainsi que des données de navigation (uniquement la position de la trajectoire). Cependant, les deux algorithmes minimisent les écarts entre les primitives correspondantes point/maillage triangulaire TIN (Triangulated Irregular Network) afin de déterminer les paramètres d’étalonnage. De son côté [Kumari, 2011], suggère une approche d’ajustement des bandes LiDAR adjacentes, appropriée à des big data (données volumineuses) où les structures créées par l’homme ne sont pas présentes. L’algorithme a besoin de données d’entrée (nuage de points et trajectoire) et fournit des paramètres de transformation rigide en sortie. Pour ce faire, un échantillon de points d’une bande LiDAR est mis en correspondance avec la surface de l’autre la plus proche. L’ajustement des scans consécutifs se réalise à l’aide d’une méthode similaire à l’algorithme ICP point à plan. L’étalonnage d’un ALS est aussi une tâche entreprise par [Skaloud et Lichti, 2006]. Une méthode rigoureuse basée sur des surfaces planes telles qu’un terrain de football, des toits inclinés de bâtiments, est discutée. L’idée est d’estimer simultanément des excentricités angulaires et des paramètres de plans à partir des primitives choisies, en ayant seulement une connaissance a priori de leur forme (aucune information ni sur leur position, ni orientation n’est demandée). [Rieger et al., 2010] de Riegl GmbH présentent, pour étalonner un MLS, une procédure basée sur l’algorithme d’ICP appliqué sur des primitives planaires extraites automatiquement de nuages distincts. Il s’agit alors de choisir une zone de test contenant un nombre important de surfaces planes (comme les façades de bâtiments) orientées diversement les unes par rapport aux autres. Elles seront balayées plusieurs fois par un scanner à double balayage (Riegl VZ-400). La direction de déplacement du véhicule aussi bien que l’angle de balayage laser changent après chaque passage. L’extraction des angles ൫݁௫, ݁௬, ݁௭൯ s’effectue avec la procédure appelée « boresight alignement and scan data adjustment », connue pour les applications d’un ALS. Son principe repose sur le fait que les nuages collectés doivent coïncider lors des acquisitions répétées d’un même objet, si les deux étalonnages extrinsèque et intrinsèque sont justes. En supposant que les erreurs dues au scanner sont compensées, nous constatons que plus la matrice de boresight est exacte, plus la différence entre ces nuages est petite. Un faux étalonnage extrinsèque devrait donc entraîner un décalage entre les surfaces balayées depuis les directions opposées de la plate-forme terrestre. Les tests réalisés dévoilent que la méthode proposée requiert des nuages collectés sous de bonnes conditions CHAPITRE 3. Erreurs relatives au système MMS 53 de réception GNSS, car le résultat de l’estimation en dépendra. Par contre, l’applicabilité de la méthode au regard des systèmes dotés d’un scanner 2D n’a pas encore été publiée. En choisissant cette approche, il nous faudra aussi trouver une solution pour déterminer le bras de levier ݎ௕/௦ ௕ . Les démarches de [Chan et al., 2013] consistent à employer différentes primitives pour les besoins de l’auto-étalonnage (self-calibration) d’un système MLS équipé de quatre scanners de profil 2D (Riegl LMS-Q120i). Pour améliorer la procédure de l’estimation, ils suggèrent de prendre en compte, en plus des plans, le modèle 3D de courbe caténaire. Ainsi, la formule classique de géo-référencement et les modèles géométriques respectifs élaborent un modèle fonctionnel d’étalonnage. Les trois composantes en rotation ൫݁௫, ݁௬, ݁௭൯, trois en translation ሺ∆ݔ, ∆ݕ, ∆ݖሻ, aussi bien que les paramètres de modèles (quatre pour un plan, et trois pour une caténaire) participent à l’ajustement fondé sur le modèle de Gauss-Helmert. Cependant, il existe plusieurs travaux portant sur l’étalonnage d’une plate-forme équipée d’un Velodyne [Atanacio-Jiménez et al., 2011], [Levinson, 2011], [Glennie, 2012], [Chan et Lichti, 2013], [Zhu et Liu, 2013], [Wiart, 2013], [Elsberg et al., 2013]. Le Velodyne est un scanner qui, selon le modèle, possède 32 ou 64 fibres laser alignées le long d’un axe. Un tel dispositif positionné sur un système mobile permet une acquisition à 360° de l’espace. [Atanacio-Jiménez et al., 2011] et [Glennie, 2012] apportent des méthodes d’étalonnage extrinsèque et intrinsèque du Velodyne HDL-64E. L’ajustement, par la méthode des moindres carrés, des primitives planaires fournit alors les valeurs recherchées. Figure 3.5 a) Nuage de points captés par un Velodyne HDL-32E : a) faux étalonnage extrinsèque ; b) après l’étalonnage extrinsèque [Wiart, 2013] Dans la même veine [Wiart, 2013] discute des solutions appropriées lorsqu’un Velodyne HDL-32E est monté sur un véhicule terrestre. Plusieurs méthodes automatiques de recherche d’étalonnage extrinsèque, toutes faites par itération multi-échelle, ont été analysées. Il s’agit de la méthode de Levinson [Levinson, 2011], et de deux nouvelles approches développées par l’auteur : 1) l’algorithme de planéité qui amène à vérifier la planéité locale dans un petit voisinage d’un point ; 2) l’algorithme Local – ICP Point-to-Plan qui s’inspire de l’ICP. Ce genre de techniques ne nécessite ni cibles spéciales, ni de mesures manuelles, évitant ainsi une tâche très fastidieuse. La démarche de Levinson utilise la redondance d’information pour calculer la compacité du nuage de points, et ensuite améliorer, par optimisation, l’étalonnage extrinsèque. Nous observons que plus l’étalonnage extrinsèque est faux, plus le désordre (entropie) au sein du nuage de points est important 54 (Figure 3.5). L’hypothèse que le nuage de points d'une fibre forme, à condition que l’étalonnage intrinsèque soit juste, des surfaces planes sur des objets plans, est devenue le point de départ de la méthode de Levinson. Les tests effectués par [Wiart, 2013] ont montré l’efficacité de cette approche, mais les résultats optimaux ont été obtenus pour des nuages possédant certaines caractéristiques (p.ex. acquisition dans un virage). Deux autres méthodes, c’est-à-dire l’algorithme de planéité et l’algorithme Local-ICP Point-to-Plan permettent aussi d’estimer précisément les excentricités angulaires. En revanche, les translations, comme avec la méthode de Levinson, sont très peu observables et doivent être déjà connues. L’inconvénient majeur de ces solutions est le temps d’exécution qui empêche l’étalonnage« ON-line ». Enfin [Elsberg et al., 2013] mettent en avant une méthode permettant d’effectuer simultanément un étalonnage intrinsèque et extrinsèque d’un scanner à double balayage (Riegl VZ-400) positionné dans un SLAM. Leur approche n’exige pas non plus de mesures à la main des points de contrôle ni de zone de test conçue à cet effet. Au contraire, ils s’appuient sur une métrique de qualité calculée à partir de données laser, et sur la méthode de Powell comme l’algorithme d’optimisation. Les points du nuage sont modélisés par une fonction de répartition de probabilité ݀ሺ݈ሻ représentant la probabilité que l’emplacement ait été déjà mesuré. Les erreurs d’étalonnage entraînent donc des surfaces apparaissant à plusieurs positions. Étant la mesure de qualité, l’entropie de la probabilité ݀ሺ݈ሻ, augmente avec ces erreurs et diminue considérablement lorsque le nuage est compact. 3.4 Impact d’un faux étalonnage sur la géométrie du nuage Étant donné qu’un faux étalonnage extrinsèque introduit certaines déformations et que leur impact est observable (Figure 3.6), il paraît intéressant de déduire, par l’analyse de la structure des relevés laser, de vrais paramètres d’étalonnage. Nous examinons alors la pertinence des lignes à étalonner le système intégral basé sur des scanners, qu’ils soient 2D et 3D. Figure 3.6 Impact de chacune des excentricités angulaires sur un profil laser : a) lacet ݁ݖ ; b) tangage ݁ݕ ; c) roulis ݁ݔ (en vert - nuage généré pour l’un des angles faux ; en rouge - nuage correct) Pour comprendre l’impact des excentricités angulaires ܴ௕ ௦ entre le capteur laser et la centrale inertielle, nous régénérons des nuages acquis auparavant par notre prototype L3D2 équipé de deux scanners SICK LMS 221. Nous introduisons de faux paramètres d’étalonnage extrinsèque. La simulation est faite à l’aide du logiciel RTMaps. L’un de ses avantages CHAPITRE 3. Erreurs relatives au système MMS 55 principaux est certes la possibilité d’enregistrer des données datées et synchronisées de manière à pouvoir effectuer un rejeu (replay) de ces dernières pendant des tests « hors lignes ». En effet, cinq nuages de points sont obtenus après avoir modifié des angles eulériens de la matrice de boresight selon les valeurs du Tableau 3.3. Les relevés laser ainsi que les segments extraits (à la main sous MicroStation v8i SSE2 pour éviter des erreurs possibles), au sein d’un petit fragment de la scène balayée, sont visualisés par la Figure 3.7. Nous remarquons que les excentricités angulaires erronées ont une grande influence sur la géométrie du nuage, et donc sur la qualité. De plus, si un seul angle boresight est incorrect, l’écart de cet angle est aisé à observer. Une analyse plus approfondie nous permet de retrouver ces valeurs numériques, en examinant des angles entre les arêtes correspondantes (Figure 3.8). Figure 3.7 Impact de faux étalonnage extrinsèque sur le nuage : a) Nuage correct ; b)c)d)e) Nuages respectivement N1,N2,N3,N4 obtenus en prenant en compte les valeurs du Tableau 3.3 56 Tableau 3.3 Angles d’Euler formant la matrice de boresight, prise en compte pour générer des nuages de points Nuage ݁௭ (lacet) [°] ݁௬ (tangage) [°] ݁௫ (roulis) [°] Réf* -90.0000 0.0000 0.0000 N1 -90.0000 0.0000 10.0000 N2 -90.0000 10.0000 0.0000 N3 -80.0000 0.0000 0.0000 N4 -80.0000 10.0000 10.0000 *Nuage correct En se basant sur les études effectuées, nous concluons que : 1) L’écart de lacet est visible sur les arêtes horizontales et à la fois perpendiculaires à la direction de déplacement du système ; 2) L’écart de tangage est notable non seulement sur les segments verticaux, mais aussi sur ceux horizontaux et perpendiculaires à la direction de la plate-forme ; 3) L’écart de roulis est identifiable dans les lignes verticales. En revanche, si tous les angles sont biaisés, il faut trouver une façon de quantifier l’écart de chacun des angles ൫݁௫, ݁௬, ݁௭൯. Figure 3.8 Étude de l’impact des écarts d’excentricités angulaires sur la géométrie des lignes En conclusion, l’utilisation d’arêtes extraites dans les nuages de points devrait permettre l’étalonnage du système. 57 CHAPITRE 4 Extraction d’arêtes Sommaire : 9. Extraction d’arêtes ............................................................................................................. 57 4.1 Méthode générale - vue d’ensemble ..................................................................................... 58 4.2 État de l’art sur l’extraction d’arêtes ................................................................................... 59 4.3 Segmentation en éléments plans - état de l’art .................................................................. 61 4.3.1 Segmentation par croissance de surface (régions) .................................................................... 62 4.3.2 Transformée de Hough 3D ............................................................................................................ 63 4.3.3 Algorithme de RANSAC ................................................................................................................ 65 4.4 Contribution à la détection de plans .................................................................................... 67 4.4.1 Motivation ......................................................................................................................................... 68 4.4.2 Extraction séquentielle de plans .................................................................................................. 69 4.4.3 Connectivité de plans basée sur la théorie des graphes ........................................................... 71 4.5 Méthode proposée d’extraction d’arêtes ............................................................................. 77 4.6 Exemples de résultats ............................................................................................................. 82 4.6.1 Détection de plans ........................................................................................................................... 82 4.6.2 Extraction d’arêtes .......................................................................................................................... 84 9. Extraction d’arêtes Dans ce chapitre un état de l’art des algorithmes récents d’extraction d’arêtes et de détection de plans dans le nuage de points est présenté. Pour satisfaire à nos exigences, à savoir, celles de recueillir des éléments linéaires (arêtes de bâtiments) pouvant remplacer les points de contrôle employés ordinairement, une méthode de détection des plis est proposée. Son idée repose sur l’intersection des plans principaux extraits dans le nuage. La recherche des plans sécants consiste avant tout à analyser l’angle d’intersection, ainsi que la distance réciproque entre toutes les combinaisons possibles de segments plans. Enfin, seules les entités linéaires dont la longueur est supérieure à un seuil prédéfini sont retenues. Concernant la segmentation en éléments plans, qui est une phase déterminante, nous utilisons l’estimateur de RANSAC pour détecter précisément les plans principaux de la scène. Mais, malgré tous ses avantages, l’algorithme de RANSAC seul peut parfois donner des résultats erronés. Plus précisément, il cherche « le meilleur plan » sans tenir compte de la particularité de l’objet. Par Résumé 58 conséquent, les relations topologiques sont omises et les segments plans détectés ne coïncident pas toujours avec la scène réelle du point de vue sémantique. C’est pourquoi nous avons renforcé l’algorithme de RANSAC par une analyse des composantes connexes. Pour résoudre le problème de connectivité de plan, une approche innovante basée sur la théorie des graphes est proposée. Nous suggérons de systématiser, au sein du nuage, les relations entre les points en tenant compte de l’information sur leur voisinage local. Le nuage est désormais considéré comme un graphe non orienté défini par un ensemble de sommets ܸ et d’arêtes ܧ. Ensuite, la recherche des composantes connexes se résume à déterminer tous ses sous-graphes connexes. Nous nous référons, au lieu d’employer l’un des algorithmes récursifs d’exploration du graphe, à une décomposition de Dulmage-Mendelsohn. Enfin, des résultats d’extraction d’arêtes sur quelques jeux de données sont illustrés. 4.1 Méthode générale - vue d’ensemble En vision par ordinateur et tout particulièrement en traitement d’image, la détection de différentes caractéristiques y compris des contours demeure un champ de recherche souvent abordé. La représentation d’une image par des contours peut significativement réduire la quantité des données et permet d’éliminer les informations jugées moins pertinentes, tout en préservant les propriétés structurelles de l’objet. Il existe un grand nombre d’algorithmes de détection, applicables à des images. Cependant, lorsqu’ il s’agit des nuages de points 3D, les travaux relatifs à ce sujet ne sont pas nombreux, même si l’extraction des arêtes reste une étape primordiale dans la modélisation tridimensionnelle. Concernant l’extraction des arêtes, nous proposons une méthode de détection de plis, conçue afin de diminuer l’influence de la densité de nuages de points sur le résultat final. Les intersections réalisées entre les plans principaux, à savoir, entre les façades elles-mêmes, mais aussi entre les façades et le sol, devraient répondre à nos besoins – fournir des entités linéaires précises, servant, à leur tour, à la qualification des données laser, au recalage ou bien encore à l’étalonnage. Du fait du manque, à notre connaissance, de description exhaustive de ce genre d’algorithmes, nous expliquons, dans ce chapitre, toutes les démarches effectuées, permettant d’extraire des droites d’intersection à partir de nuage de points. Figure 9.1 Organigramme de l’approche d’extraction d’arêtes proposée L’approche proposée comporte deux étapes cruciales, comme illustré par la Figure 9.1. Dans un premier temps, le nuage est segmenté en éléments plans avec l’algorithme de RANSAC. Nous procédons ensuite à une analyse des composantes connexes pour vérifier, de façon robuste et précise, la connectivité et la sémantique des points formant chaque segment plan. CHAPITRE 4. Extraction d’arêtes 59 Nous obtenons alors un ensemble de segments plans ∏ accompagnés par les paramètres du plan ajustant au mieux ces points. Nous entendons par le terme « segment plan » un ensemble de points coplanaires à une tolérance près, et avec des limites bien définies. Autrement dit, c’est un plan limité possédant une certaine épaisseur. Nous étudions ensuite les relations de voisinage entre tous les segments plans détectés. Leur analyse va nous amener à la reconstruction des arêtes ayant une longueur supérieure à une tolérance admise ܶ௦௘௚. Nos travaux se concentrent, dans un premier temps, sur la détection de plans indispensables dans le processus d’extraction d’arêtes. Ce chapitre est structuré de la manière suivante. Nous commençons par présenter l’état de l’art traitant de l’extraction d’arêtes (4.2) et de la reconnaissance de plans (4.3) dans les nuages de points. Nous caractériserons quelques méthodes, les plus souvent utilisées pour la segmentation des nuages 3D. En second lieu (4.4), nous détaillerons notre approche de segmentation basée sur l’algorithme de RANSAC. Comme la réalité n’est pas toujours compatible avec le modèle mathématique, nous proposons d’intégrer une contrainte de connectivité entre les points constituant chaque sousnuage (segment plan) extrait. Cette problématique étant déjà connue, nous développons une solution alternative ne nécessitant plus de conversion d’un nuage 3D en une image 2D. Ainsi, la perte possible d’information lors de la transformation du nuage, causée habituellement par le nombre impropre de pixels par unité de longueur (résolution pix/m), ne se produira jamais. De cette façon, les erreurs apparaissant quand différents objets architecturaux de la scène se trouvent sur le même plan mathématique peuvent être corrigées et les plans détectés correspondront aux façades réelles. Ensuite (4.5), nous décrivons l’étape de recherche des intersections entre les segments plans. Par la suite (4.6), nous montrerons l’efficacité de notre algorithme en illustrant les résultats obtenus sur quelques nuages de points mobiles. Nous finirons par une brève discussion concernant les points forts et faibles d’une telle approche. 4.2 État de l’art sur l’extraction d’arêtes La majorité des méthodes visant à indiquer les zones contenant « des points candidats », c’est-à-dire les points situés à l’intersection de deux surfaces, consiste à calculer la normale au point. Alternativement, il est possible de construire un maillage pour ensuite étudier la normale de chaque triangle. Dès qu’un changement important dans la direction des normales s’opère, l’existence d’une arête est perçue [Alshawa, 2006], [Demarsin, 2007]. Figure 9.2 Exemple de résultats intermédiaires d’extraction d’arêtes :a) façade triangulée ; b) points de contours [Boulaassal, 2010] 60 Les travaux de [Boulaassal, 2010] visent à extraire des points de contour représentant les deux types d’arêtes (Figure 9.2b). Dans son approche, quatre étapes essentielles se distinguent : 1) la détection des plans ; 2) la triangulation de Delaunay ; 3) l’analyse de la longueur des côtés des triangles ; 4) la vectorisation des contours. Les sommets, reliant les côtés longs des triangles (marqués par un cercle vert dans la Figure 9.2a) dont la longueur change brusquement, et est à la fois supérieure à un seuil fixé, seront considérés comme des points de contour. L’algorithme de [Wang et al., 2011] permet de détecter automatiquement, dans le nuage de point mobile, des ouvertures sous forme de fenêtre et de porte. Il s’appuie, lui aussi, sur la détection préalable des façades de bâtiments. Ensuite, le voisinage local de chaque point du nuage est examiné suivant deux directions : verticale et horizontale. Pour faciliter cette tâche, un paramètre connu a priori, notamment celui de l’écartement entre deux fenêtres voisines, est pris en compte. Dans le même contexte [Tuttas et Stilla, 2011] détectent des fenêtres dans les nuages acquis par un système mobile aéroporté ALS. Ces données d’entrée se caractérisent par une faible densité (seulement 5 points par m2). Leur approche est basée sur deux hypothèses : 1) Le faisceau laser passe toujours à travers les vitres des fenêtres. C’est pourquoi la présence des fenêtres peut être assimilée à des points se trouvant derrière la façade principale ; 2) Toutes les fenêtres sont disposées de manière régulière. Afin d’extraire des points notablement éloignés et situés derrière la façade, les distances entre tous les points du nuage et le plan approximant sont calculées. La dernière phase consistera à faire une corrélation entre deux images : celle créée à partir des points détectés lors de l’étape précédente et un marqueur (motif linéaire) horizontal ou vertical. Cependant [Soria-Medina et al., 2011] cherchent à extraire des éléments d’une façade en s’appuyant non seulement sur l’information géométrique, mais aussi sur l’intensité. Les démarches proposées font référence à des outils dédiés au traitement d’image 2D. Ils proposent alors une solution intégrant l’algorithme des K-moyennes (K-means) et les opérateurs de la morphologie mathématique afin d’extraire des contours. Un autre point de vue est envisagé par [Bienert, 2008]. Une méthode de détection des arêtes dans un nuage de points dense est proposée. Son idée repose sur le lissage du nuage avec un élément structurant. En effet, la position de chaque point est recalculée à partir de son voisinage. Ensuite, tous les points englobés par cet élément structurant participeront à l’ajustement d’une droite. Nous venons de voir que la plupart des algorithmes d’extraction de segments, dédiés au nuage de points, permettent de détecter des points de contour appartenant potentiellement à l’arête. Néanmoins, il faut souligner qu’une telle entité linéaire peut être loin de la représentation de l’arête réelle. Les points du nuage seront d’autant plus proches de l’arête que la résolution du balayage effectué est petite. Mais, les tests des télémètres laser démontrent qu’il est très difficile, voire impossible, de mesurer précisément des bordures d’un objet, en raison de la diffraction subie par le faisceau laser à cet endroit [Kilmkowska et Wrobel, 2006]. L’une des pistes d’amélioration du processus d’extraction s’oriente vers la fusion des informations liées aux points 3D avec celles des images. L’utilisation conjointe de ces deux types de données est examinée entre autres par [Yong et Huayi, 2008], [Wang et al., 2013] et [Wang et al., 2014]. Les résultats obtenus mettent en évidence les avantages de cette solution. CHAPITRE 4. Extraction d’arêtes 61 4.3 Segmentation en éléments plans - état de l’art Le traitement des relevés laser en vue de leur reconstruction fait l’objet de très nombreux travaux. La reconnaissance de différentes surfaces est considérée comme un problème de segmentation. Son objet est de séparer des formes de l’environnement en fonction de leur homogénéité, étant vérifiée au regard de la position des points, de la courbure, de la planéité ou de la direction de normale. Elle constitue également l’une des premières étapes de la modélisation tridimensionnelle puisque son but est de faciliter l’interprétation ultérieure des données. Les méthodes existantes de la segmentation des nuages 3D s’inspirent, en général, des approches largement connues en vision par ordinateur. Le problème se réduit souvent à l’analyse de l’image de profondeur obtenue par la projection de nuage de points sur un plan image, où la valeur du pixel correspond à la distance du point au plan [Hernandez et Marcotegui, 2008], [Serna et Marcotegui, 2013]. D’après [Boulaassal, 2010], les algorithmes de segmentation dédiés aux relevés laser peuvent être regroupés en deux catégories. La première famille, bénéficiant des relations de proximités et de similitude, comprend des approches fondées sur la fusion notamment la segmentation par croissance de surface, la segmentation par division-fusion (split-and-merge), ou bien encore la segmentation par profils de balayage. Le second groupe adapte les techniques de reconnaissance automatique de formes. Celles-ci étant plus robustes, elles ne peuvent être employées qu’afin de subdiviser le nuage en primitives géométriques définies par l’ensemble de paramètres. Il s’agit des modèles 3D a priori tels que la sphère, le plan, le cône, ou le tore. Les techniques les plus utilisées font appel à la transformée de Hough [Hough, 1962] ou à l’algorithme de RANSAC (RANdom SAmple Consensus) de [Fischler et Bolles, 1981]. Les deux approches s’avèrent particulièrement robustes au bruit, entachant les nuages de points. La détection de plans ou l’approximation par un plan s’avère un problème spécifique de la segmentation de données 3D permettant de séparer une scène complexe en deux parties : les zones planes et non planes. Durant ces dernières années, plusieurs méthodes d’extraction de plans ont été proposées. Un aperçu de quelques techniques est donné par [Vosselman et al., 2004]. Les travaux de [Bauer, 2005] et [Boulaassal, 2010] s’appuient sur l’utilisation de l’algorithme de RANSAC dans le but de détecter les façades de bâtiments à partir du nuage de points dense. Cependant, plusieurs améliorations de cet estimateur ont été apportées afin de l’optimiser et de le rendre encore plus efficace et fiable. [Delmerico et al., 2011] et [Awwad et al., 2011] proposent de prendre en compte des normales en chaque point. De même [Bretar et Roux, 2005] détectent les plans de toits dans les nuages de points aériens à l’aide de l’algorithme ND-RANSAC (Normal Driven RANSAC). À cet effet, ils calculent les normales au point. Puis, le tirage aléatoire d’un échantillon minimal composé de trois points ayant les vecteurs normaux d’orientation identique est effectué. L’approche de [Yang et al., 2010] consiste à diviser un nuage de points en petits blocs. Ensuite, une méthode combinant l’algorithme de RANSAC avec la longueur de description minimale MDL (Minimum Description Length) est exécutée au sein de chaque sous-nuage de points. La tâche de ce dernier est de vérifier le nombre de plans retrouvés, étant entendu que ce nombre varie, d’un bloc à l’autre, de zéro à trois plans. En même temps [Gallo et al., 2010] développent un algorithme appelé CC-RANSAC dont l’idée repose sur la recherche de la composante connexe la plus grande dans l’image de profondeur. De leur côté [Tasha-Kurdi et al., 2007], [Borrmann et al., 2011] et [Borowiec, 2012] emploient la transformée de Hough 3D comme un outil de détection des plans. Les méthodes de [Deschaud, 2010], [Jarzabek-Rychard et Borkowski, 2010] et [Tuttas et Stilla, 2010] sont fondées sur un algorithme de croissance de surface. L’idée consiste toujours à identifier tout d’abord des régions graines et de les faire croître selon certaines 62 conditions comme nous l’expliquerons dans le paragraphe 4.3.1. Son avantage principal est d’être rapide lorsqu’il y a de nombreux petits plans à extraire. Sinon, lors de détection des plans grands (par exemple les plans de taille d’une façade) l’algorithme tend à être plus en plus lent [Deschaud, 2010]. Parmi les travaux portant sur la détection des toits de bâtiment dans les données laser aéroportées, nous pouvons remarquer un certain nombre d’études comparatives. [JarzabekRychard et Borkowski, 2010] analysent les résultats obtenus avec la croissance de surface et l’algorithme de RANSAC. Ils en concluent que ce dernier est plus efficace pour la segmentation de modèles peu compliqués. En revanche, il est plus susceptible d’unir des points situés sur le même plan mathématique, mais appartenant, en réalité, à différentes structures architecturales. Dans ce même contexte [Tarsha-Kurdi, 2008] améliore l’algorithme de RANSAC pour le comparer, par la suite, avec la transformée de Hough. Il constate que l’algorithme de RANSAC est plus adapté aux données 3D, tant en termes de traitement que d’insensibilité au bruit. Pour tirer profit des deux méthodes de segmentation, [Tuttas et Stilla, 2013] proposent une approche de détection de façades en deux étapes : le traitement grossier et fin. Dans un premier temps, la segmentation par croissance de surface basée sur deux critères (seuil de normale et de distance) est effectuée. Ensuite, chaque plan est analysé afin de vérifier s’il doit être subdivisé en plusieurs segments plans. Le plan final est retrouvé avec l’algorithme de RANSAC. Pareillement [Oehler et al., 2011], emploient la transformée de Hough combiné avec l’algorithme de RANSAC. D’abord, les normales sont calculées et la pré-segmentation est réalisée avec la transformée de Hough. Puis, l’algorithme de RANSAC est directement employé sur les segments plans détectés auparavant. Finalement [Borowiec, 2008], s’appuie, afin de détecter de toits, sur une approche basée sur l’algorithme de division-fusion. L’étude des travaux actuels révèle que la majorité des approches optent pour la détection de plans dans le nuage de points à l’aide de l’algorithme de RANSAC, de la transformée de Hough, ou éventuellement de la croissance de surface. C’est pourquoi nous détaillerons dans cette section les principes de fonctionnement propres aux techniques susmentionnées. 4.3.1 Segmentation par croissance de surface (régions) La segmentation par croissance de surface est conceptuellement une adaptation, dans l’espace Թଷ, d’une méthode de croissance de régions. Son objectif est d’isoler des zones les plus homogènes possibles, tout en respectant des conditions arbitraires imposées. Nous distinguons deux étapes principales de l’algorithme : 1) Trouver les points de départ – régions graines (seed) ; 2) Rassembler des points/pixels voisins entre eux suivant les critères prédéfinis Or, cette méthode consiste à faire progressivement grossir les régions autour de leurs points de départ. Les zones grandissent alors par incorporation des points les plus similaires. L'agglomération des points n'exploite aucune connaissance a priori du nuage ou du bruit qui le dégrade. La décision d’intégrer à la région un point voisin repose sur un seul voire deux critères tels que la proximité des points (seulement les points proches peuvent être ajoutés), la planéité locale (la distance orthogonale du point au plan doit être inférieure à un seuil fixé), le champ de vecteurs normaux (les angles entre la normale du plan et les normales de tous les points voisins appartenant au plan doivent être inférieurs à un seuil choisi) [Vosselman et al., 2004]. Par conséquent, les variantes se distinguent surtout par la manière de sélectionner des plans initiaux et par les critères de croissance définis. Le choix des régions graines est la phase la plus critique de l’algorithme puisqu’elle joue sur la qualité des résultats obtenus et sur le temps de calcul. CHAPITRE 4. Extraction d’arêtes 63 4.3.2 Transformée de Hough 3D La transformée de Hough [Hough, 1962] est un outil de reconnaissance de formes basé sur une connaissance a priori. Cette méthode fait partie de la famille des algorithmes de votes. Elle est souvent utilisée dans la détection de lignes 2D (en analyse d’images). Mais, l’extension à d’autres primitives géométriques représentées par une fonction mathématique simple (par exemple plan, cercle, ellipse) ou à des espaces de dimension quelconque est aussi possible. Cas 2D - ligne Afin d’expliquer le principe de la transformée de Hough, nous commençons par un exemple typique – une ligne 2D. Figure 9.3 Correspondance géométrique entre l’espace cartésien (à gauche) et l’espace paramétrique de Hough (à droite) (Illustration reproduite à partir de [Poncelet et Cornet, 2010]) Étant donné une droite notée ݕ ൌ ݉ݔ ൅ ܾ (où m : coefficient directeur et b : ordonnée à l’origine) dans l’espace Euclidien, il nous faut, conformément à l’idée de Hough, changer l’espace de représentation de cette droite et l’exprimer désormais par ܾ ൌ െ݉ݔ ൅ ݕ. Nous obtenons l’équation d’une droite passant par un point ሺ݉, ݌ሻ dans l’espace de paramètres (l’espace de Hough). Cette forme la plus classique, servant à représenter la droite, n’est cependant pas sans problème, car les droites verticales et horizontales auront des valeurs infinies pour m et b. Pour pallier cet inconvénient, il est donc préférable d’exploiter les coordonnées polaires (l’équation normale) d’une droite au lieu de sa formulation cartésienne (9.1) [Duda et Hart, 1971]. 64 (9.1) ߠ݊݅ݏݕ ൅ ߠݏ݋ܿݔ ൌ ߩ où : ߩ : distance de la ligne à l’origine ߠ : angle (l’orientation du vecteur normal de la droite depuis l’origine) Cas 3D - plan Le même principe s’applique à la détection de plans. Chaque plan de l’espace Euclidien est défini par la formulation normale donnée par : (9.2) ߮݊݅ݏݖ ൅ ߮ݏ݋ܿߠ݊݅ݏݕ ൅ ߮݊݅ݏߠݏ݋ܿݔ ൌ ߩ La Figure 9.4 explique la notation employée dans l’équation (9.2). Figure 9.4 Formulation normale d’une droite De manière analogue, les trois paramètres ሺߠ, ߮, ߩሻ définissent l’espace de paramètres. Chaque point ሺߠ, ߮, ߩሻ de cet espace correspondra à un plan de l’espace cartésien et vice versa. Étant donné un point quelconque du plan ∏, tous les plans auxquels ce point appartient doivent être trouvés. Figure 9.5 Espace de paramètres : a) Sinusoïde 3D calculée à partir d’un point de l’espace cartésien ; b) Transformée de Hough de trois points et le point d’intersection (carré noir) [Borrmann et al., 2011] CHAPITRE 4. Extraction d’arêtes 65 En traçant ces points dans l’espace de Hough, une courbe sous forme d’une sinusoïde 3D est obtenue (Figure 9.5a). Par conséquent, un plan passant par ܰ points est, dans l’espace de paramètres, le point d’intersection de ܰ sinusoïdes (Figure 9.5b). Finalement, le pic de l’accumulateur correspond à un maximum de points dans un même alignement. Plus des courbes se coupent en un même point de l’espace de paramètres, plus des points appartiennent au plan détecté. La transformée de Hough cherche à trouver le meilleur plan qui est perçu comme celui contenant un nombre maximal de points. De ce fait, le plan optimal n’est pas calculé au sens des moindres carrés. 4.3.3 Algorithme de RANSAC L’algorithme de RANSAC [Fischler et Bolles, 1981] est très largement utilisé dans le domaine de la vision par ordinateur pour l’estimation des paramètres. Son avantage est d’être robuste et rapide, même en présence d’observations aberrantes. L’une de ses applications est la détection, de manière interactive, de plans. [Zuliani, 2012] rapporte que cet estimateur résiste très bien à la présence de données non valables (outliers) en supportant jusqu’à 50% d’erreurs grossières. Cette marge rend, de ce fait, la méthode particulièrement intéressante pour traiter les nuages de points contenant pourtant des mesures bruitées. Son principe est simple : il s’agit toujours de sélectionner au hasard un nombre minimum de données afin de calculer les paramètres d’un modèle mathématique, puis d’identifier parmi toutes les données, celles ayant une chance raisonnable d’appartenir à ce modèle. Le processus étant itératif, il s’arrête lorsque l’on trouve un sous-ensemble de points le plus nombreux. Deux phases essentielles de l’algorithme de RANSAC peuvent être distinguées. La première nommée « Initialisation » consiste à tirer aléatoirement un nombre minimum de points (un quorum) ܵ parmi ܰ points de l’ensemble. Un plan est défini par quatre paramètres, dont trois ሺߠଵ, ߠଶ, ߠଷሻ étant indépendants, sont les composantes de la normale au plan et ߠସ est la distance du plan à l’origine. Alors, l’échantillon minimal contiendra trois points ܵ ൌ ሼ݌ଵ, ݌ଶ, ݌ଷሽ à partir desquels tous ces indices seront déterminés. Nous désignons par ܯሺߠሻ le modèle mathématique du plan défini de la manière suivante : ܯሺߠሻ ൌ ሼߠଵஸ௜ஸସ ∈ Թ: ߠଵݔ൅ߠଶݕ൅ߠଷݖ൅ߠସ ൌ 0ሽ (9.3) La seconde étape « Test », exécutée après le calcul du modèle, vérifie un score, perçu généralement comme le nombre de points ajustant au mieux le plan. Nous considérons qu’un point quelconque appartient au plan, si et seulement si, il est situé à une distance inférieure à une tolérance prédéfinie ߜ. Nous introduisons les termes inhérents à l’utilisation de RANSAC. On appelle désormais EC « Ensemble de Consensus » (Consensus Set), l’ensemble de points satisfaisant au modèle prédéfini auparavant par un quorum de points. On note Card(EC) le nombre de points valables (inliers). (9.4) ൟߜ ൑ ሻ൯ߠሺܯ ,௜݌ெ൫݁ :ܰ ∋ ௜݌൛ ሻ ൌܥܧሺ݀ݎܽܥ Dans la formule (9.4) l’écart entre le point p et le modèle ܯሺߠሻ se calcule de la manière suivante : ௜݌ ,௜݌ሺݐݏ݅݀ ≝ ሻ൯ߠሺܯ ,௜݌ெ൫݁ ∗ሻ (9.5) ௜݌ où ∗ symbolise la projection orthogonale du point p sur le modèle ܯሺߠሻ. 66 Les deux phases sont répétées ܰ௜௧௘௥ fois. À ce moment, le plan est retenu s’il contient suffisamment de points, c’est-à-dire si le nombre de points Card(EC) appartenant au « meilleur modèle » est le plus grand (Figure 9.6). Figure 9.6 Vue de profil de la zone d’épaisseur ߜ contenant les points valables (vert) satisfaisants au modèle défini par un quorum de points (rouge) L’estimation du nombre d’itérations qui permettrait d’interrompre l’algorithme reste une question délicate. L’algorithme de RANSAC, dans sa version de base, vise à garantir un nombre optimal de tirages indispensables pour estimer le meilleur plan avec une probabilité ܲ. En admettant que ܹ désigne la probabilité de choisir, à chaque itération, un point valable, la probabilité que les trois points du quorum appartiennent tous au plan final est de ܹଷ. De ce fait, il y a une probabilité égale à ሺ1െܹଷሻ qu’au moins un de ces points ne fasse pas partie des points valables. Nous pouvons relier les probabilités ܲ et ܹ avec le nombre d’itérations ܰ௜௧௘௥ par l’équation suivante : ሺ1െܲሻ ൌ ሺ1െܹଷሻே೔೟೐ೝ ⇔ ܰ௜௧௘௥ ൌ ݈݋݃ሺ1െܲሻ ݈݋݃ሺ1െܹଷሻ (9.6) La formule (9.6) démontre qu’afin de déterminer le nombre d’itérations, la connaissance de ܲ et ܹ est primordiale. Le choix de ces valeurs se fait de manière empirique. La probabilité ܲ est choisie de préférence élevée ሺܲ ൒ 0.95ሻ. Quant à la valeur ܹ, elle doit être estimée en fonction des données. Cette probabilité, pour un seul point, est exprimée par : CHAPITRE 4. Extraction d’arêtes 67 ܹ ൌ ሻܥܧሺ݀ݎܽܥ ሺܰሻ݀ݎܽܥ (9.7) Il est difficile de choisir dûment la probabilité ܹ car souvent nous ne connaissons pas le nombre de points valables restant dans le nuage de points. L’algorithme est ainsi initialisé en utilisant une estimation grossière de ܹ, ce qui augmente le risque d’accepter un nombre inapproprié d’itérations. Pour surmonter cet inconvénient, une version adaptative de RANSAC a été développée par [Hartley et Zisserman, 2003]. L’idée consiste à sélectionner dynamiquement le nombre de tirages à réaliser, en adaptant la valeur ܹ grâce au cardinal de l’ensemble de consensus trouvé. En d’autres termes, le nombre maximal d’itérations sera mis à jour avant le démarrage de la prochaine sélection d’un quorum de points. L’avantage principal d’un tel raisonnement est d’être plus efficace et de réduire considérablement le temps de calcul. 4.4 Contribution à la détection de plans Pour notre application, nous souhaitons pouvoir détecter de grands plans (plans principaux) tels que les façades des bâtiments, le sol, tout en étant suffisamment rapide. L’analyse de l’état de l’art, nous a encouragé de choisir l’estimateur de RANSAC comme l’algorithme de base puisqu’il paraît le plus robuste pour traiter de nombreux points. Nous implémentons sa version adaptative décrite dans la section précédente et caractérisée par [Zuliani, 2012]. La segmentation en segments plans s’effectue de manière séquentielle. Une fois un plan détecté, les points qui lui appartiennent sont retirés du nuage. L’algorithme s’interrompt lorsqu’il n’y a plus de données à classer, ou lorsque les points restants ne permettent pas d’obtenir de segment plan contenant un nombre suffisant de points, ou bien encore quand le nombre de plans désirés ܰ௣௟ a été retrouvé. Sachant que les segments plans obtenus à l’aide de l’algorithme de RANSAC ne peuvent pas toujours coïncider avec la scène réelle du point de vue sémantique, il nous faut aussi prendre en compte les relations topologiques entre les points formant un plan. Nous avons donc enrichi l’algorithme de RANSAC d’une analyse des composantes connexes. La problématique de connectivité a été largement étudiée en traitement d’images 2D. Elle vise à vérifier si deux pixels sont voisins et s’ils respectent, en même temps, une condition arbitraire par exemple l’égalité des niveaux de gris. En conséquence, nous pouvons nous en inspirer pour incorporer une contrainte de connectivité entre les points formant un segment plan. Dans cet esprit [Boulaassal, 2010] et [Gallo et al., 2010], transforment un plan 3D détecté par l’algorithme de RANSAC en une image 2D. Le passage est réalisé par la projection des points du nuage sur le plan moyen. Cette étape nécessite de choisir soigneusement la résolution de l’image créée (le nombre de pixels par unité de longueur) afin d’éviter les problèmes d’échantillonnage. Des valeurs trop larges ou trop petites ne permettront pas d’étudier la connectivité de pixel. La séparation ultérieure des différentes régions consiste à calculer la différence entre les valeurs de pixels voisins. Étant donné que la conversion en image peut être une source importante d’erreurs, nous avons proposé un algorithme fonctionnant directement sur des nuages de points. Il fait appel aux éléments de la théorie des graphes et attend seulement quelques paramètres initiaux pour s’exécuter. Ainsi, nous structurons les nuages, et effectuons une décomposition de Dulmage–Mendelsohn [Dulmage et Mendelsohn, 1958] aboutissant à décomposer de façon unique un graphe biparti non orienté en composantes connexes. Ce premier est défini grâce à l’analyse du voisinage de chaque point du nuage. Nous systématisons les points du segment plan, étant naturellement désordonnés, en les représentant par un ensemble de sommets (points) ܸ et d’arêtes ܧ établissant les relations topologiques entre ces sommets. 68 L’extraction de segments plans est menée en deux étapes comme l’illustre la Figure 9.7. Nous présenterons dans le paragraphe 4.4.2 l’algorithme de RANSAC tel qu’il est implémenté. Ensuite, nous discuterons des principes de notre méthode de détection de composantes connexes basée sur la théorie des graphes (paragraphe 4.4.3). Figure 9.7 Schéma global de l’algorithme d’extraction de segments plans implémenté 4.4.1 Motivation Un plan est une entité fondamentale à deux dimensions et nous l’imaginons comme une feuille d’épaisseur nulle qui s’étend à l’infini. Cependant, les plans extraits à partir du nuage de points n’ont pas forcément ces deux caractéristiques. D’une part, nous devons prendre en compte la troisième dimension – l’épaisseur provenant principalement du comportement du faisceau laser sur différentes surfaces. D’autre part, un plan quelconque approximant une façade, un trottoir ou une route a des limites bien définies. Mais, l’estimateur de RANSAC fournit un plan illimité, rassemblant tous les points qui appartiennent à un même plan mathématique. Figure 9.8 Détection de trois plans successifs par RANSAC. Une couleur correspond à un plan CHAPITRE 4. Extraction d’arêtes 69 La Figure 9.8 montre trois plans successifs extraits à partir du nuage mobile Stereopolis2009_Soufflot avec cet algorithme. Les deux façades (marquées en orange), étant en réalité séparées, ont été classifiées comme une seule entité planaire. De plus, nous observons de nombreuses régions éparpillées autour des régions principales qui ne devraient pas être intégrées au modèle final. Nous visons à supprimer ces petits plans pouvant fausser les résultats du traitement ultérieur, notamment l’extraction d’arêtes basée, par défaut, sur les plans. Étant donné que nous cherchons à conserver les plans les plus précis possibles et reconstruisant correctement la scène réelle, il nous semble primordial d’effectuer une analyse du nombre d’entités constituant le segment plan et d’en conserver une seule partie – celle ayant l’aire la plus grande. La Figure 9.9 illustre le plan détecté via l’algorithme de RANSAC et celui que l’on souhaiterait extraire. C’est pourquoi nous proposons une extraction innovante des composantes connexes dédiée au nuage. Il s’agit d’étudier le voisinage de points pour s’en servir lors de l’extraction des composantes connexes. Figure 9.9 Exemple d’erreurs de connectivité : plan détecté (à gauche) ; plan recherché (à droite) 4.4.2 Extraction séquentielle de plans L’inconvénient majeur de l’algorithme de RANSAC classique est la détection d’une forme unique. Pour y remédier, l’une des stratégies à envisager consiste à l’implémenter dans un mode séquentiel. L’idée de cette approche nous amène à retirer du nuage les points valables appartenant au segment plan détecté au préalable. Cette opération est de nouveau appliquée sur les points restants jusqu’à ce que le nombre prédéfini de plans ܰ௣௟ ait été extrait ou jusqu’à ce qu’il n’y ait plus de points permettant une détection de surfaces désirées. Du fait de la présence de bruit ߪ provenant de l’état d’objet balayé par scanner, sa couleur, nature et rugosité (voir le Chapitre 3), les nuages de points ont habituellement une épaisseur non négligeable. C’est pourquoi l’ajustement de plans s’effectue avec une certaine souplesse. La sélection du seuil ߜ – la zone tampon autour du plan moyen, joue un rôle important au niveau de la stabilité de l’algorithme de RANSAC puisqu’il peut provoquer des problèmes de sous-segmentation et de sur-segmentation (Figure 9.10). La valeur de ce seuil ߜ doit être fixée en tenant compte des caractéristiques du nuage comme sa densité et son degré de 70 bruitage. Ainsi, elle a tendance à être égale à l’épaisseur du nuage de points brut – sans filtrage préalable. Figure 9.10 Impact du choix du seuil ߜ sur les résultats de détection des plans : a) Segmentation avec un seuil faible (0.03m) ; b) Segmentation avec un seuil élevé (0.15m) D’après [Hartley et Zisserman, 2003] suivis par [Zuliani, 2012], le seuil ߜ peut se calculer en supposant que tous les points suivent une distribution normale autour du plan moyen. Nous faisons l’hypothèse que les nuages sont entachés par un bruit gaussien ߟ~ܰሺ0, ܫߪሻ pour ߟൌ݌െ݌∗. La valeur ߜ relie désormais, avec une probabilité ܲ, l’erreur générée par les points valables affectés par le bruit ߪ. L’épaisseur de la zone de tampon δ se calcule de la manière suivante : ܨఎටߪൌߜ ఞమ మ ିଵሺܲሻ (9.8) où : ܲ : probabilité considérée (ܲ ൒ 0.95) ܨ ߯2 2 െ1 : valeur de la fonction de répartition de la loi chi-2 ሺ߯݉ 2 ሻ à m ൌ 2 degrés de liberté (Tableau 9.1) ߪ : degré de bruitage Tableau 9.1 Table de distribution ߯2 2 selon la valeur de probabilité P Degré de liberté P=0.900 P=0.950 P=0.975 P=0.990 P=0.999 2 4.605 5.991 7.378 9.210 13.861 Si nous souhaitons récupérer 99% des points d’un plan, nous avons P=0.99, et donc ܨ ߯2 2 െ1ሺ0.99ሻ ൎ 9.21. L’analyse du Tableau 9.1 permet de constater que plus la valeur de la probabilité ܲ est proche de l’unité, plus le seuil ߜ est important et, que l’épaisseur de la zone tampon augmente. Le modèle risque, en réalité, de contenir beaucoup de points aberrants. En outre, une probabilité ܲ trop petite génère un seuil insuffisant, et les points potentiellement valables sont susceptibles d’être exclus du modèle. Dans notre approche, nous avons employé la formule (9.8), au lieu de définir la tolérance de distance maximale, pour tester l’appartenance des points au plan. Un point est considéré comme valable si l’écart au carré entre ce point et le plan est inférieur à ߜ2 . Plus précisément, le test statistique se fait de la manière suivante : ൝ ሻ൯ߠሺܯ ,݌൫ܯ݁ ݅ܵ 2 2ߜ ൑ ݊݋݌݉ܽݐ ݁݊݋ݖ ݈ܽ ݏ݊ܽ݀ éݑݐ݅ݏ ݈ܾ݈݁ܽܽݒ ݐ݊݅݋݌ ሻ൯ߠሺܯ ,݌൫ܯ݁ ݅ܵ 2 2ߜ ൒ ሻ ݁ݏ݅݉݀ܽ ݁ܿ݊ܽݎé݈݋ݐ ݏݎ݋݄ሺ ݐ݊ܽݎݎܾ݁ܽ ݐ݊݅݋݌ (9.9) CHAPITRE 4. Extraction d’arêtes 71 Cette solution avec un degré de bruit ߪ associé au nuage est censée estimer une valeur optimale du seuil ߜ. Nous avons implémenté l’algorithme de RANSAC dans la version cidécrite (voir aussi le pseudo-code 4.1 dans l’Annexe E). Pour la détection de plans, nous avons besoin en entrée d’un nuage de points ܰ relativement homogène. Néanmoins, il faut noter que l’utilisation de cet estimateur implique un réglage de trois paramètres : ܲ, ߪ et éventuellement un nombre de plans désiré ܰ݌݈. Le symbole ܲ correspond à la probabilité d’avoir les points correspondants au plan, tandis que la valeur ߪ est l’écart-type des distances calculées par rapport au plan. Ces deux indices sont d’ores et déjà nécessaires pour déterminer la valeur du seuil ߜ. Elle est alors assimilée à la distance maximale point – modèle, et elle représente l’épaisseur du segment plan à extraire. En sortie, nous obtenons des sous-ensembles de points formant des plans ∏ et leurs paramètres associés ሺߠ1, ߠ2, ߠ3, ߠ4ሻ. 4.4.3 Connectivité de plans basée sur la théorie des graphes Une fois le segment plan détecté, nous procédons à l’analyse des composantes connexes ܥܥ, c’est-à-dire de toutes les parties surfaciques constituant cette entité. Le terme connectivité dérive de la notion de voisinage. On dit que deux points de l’espace sont connectés s’ils appartiennent à la même composante. Quant au critère de décision permettant de distinguer les points voisins, il s’appuie sur le calcul de distance qui sera ensuite confronté avec un seuil prédéfini ߩ (distance maximale). En effet, il s’agit de vérifier si un plan se constitue en un seul « morceau ». Nous entendons par « connectivité » du plan sa continuité spatiale – le segment plan doit constituer une entité contigüe et non pas un ensemble de surfaces séparées par des vides comme le montre la Figure 9.9. Sinon, chacun de ses éléments est l’une des composantes connexes. La Figure 9.11 illustre notre raisonnement. D’abord, un segment plan est extrait via l’algorithme de RANSAC tel qu’il est présenté dans la section 4.4.2. Ensuite, nous étudions les relations de voisinage entre chaque point du sous-nuage. Dès que toutes les composantes connexes sont déterminées, leurs surfaces sont calculées et comparées les unes par rapport aux autres. Puis, la partie dont l’aire est la plus importante sera retenue, tandis que les points des autres régions seront réintégrés dans le nuage pour participer à la recherche ultérieure de meilleurs plans. Figure 9.11 Correction d’extraction du plan : a) Premier plan détecté via l’algorithme de RANSAC ; b) Étiquetage des composantes connexes ; c) Segment plan retenu après intégration du critère de connectivité Afin de résoudre le problème de connectivité, le nuage de points ܰ est traité comme un graphe non orienté pour lequel tous ses sous-graphes ܩ′ seront recherchés. À ce stade, il nous faut rappeler que nous travaillons directement sur les données laser 3D. Nous constatons que les points appartiennent à la même composante connexe, si est seulement si, il existe au moins un chemin reliant n’importe quel couple de points de cette composante. 72 Nous distinguons deux phases dans notre approche de détection de composantes connexes d’un segment plan (Figure 9.12) : 1) la recherche du voisinage de chaque point du nuage en respectant les seuils renseignés avec la construction d’une liste de paires de points (sommets) de telle sorte que chaque paire correspondra à une arête au sens de la théorie des graphes ; 2) l’étiquetage des composantes connexes. Figure 9.12 Organigramme de l’algorithme d’extraction de composantes connexes Structuration du nuage de points Concernant la théorie des graphes, un graphe simple non orienté ܩ ൌ ሺܸ, ܧሻ est défini par la donnée d’un ensemble de sommets ܸ et d’un ensemble d’arêtes ܧ ⊆ ሼሺݑ, ݒሻ: ݑ, ݒ ∈ ܸ, ݑ ് ݒሽ. En d’autres termes, un graphe est constitué de sommets ܸ, dont certains sont reliés par des arêtes, si est seulement si, ces sommets sont adjacents les uns par rapport aux autres (Figure 9.13ab). Si un graphe est non orienté, dans ce cas-là, la relation binaire entre les sommets est symétrique (si ݑ→ݒ alors ݒ→ݑ). On utilise la notion « ordre du graphe » pour décrire le nombre de sommets de ce graphe. Un sous-graphe d’un graphe ܩ est défini comme un ′ܩ graphe composé de certains sommets de ܩ, ainsi que de toutes les arêtes reliant ces sommets dans ܩ : ′ܩ :ܩ ⊇ ′ܩ ′ܸ൫݄݁݌ܽݎ݃ ′ܧ , (9.10) ܧ ∋ ′ܧ ݐ݁ ܸ ∋ ′ܸ ܿ݁ݒܽ ൯ D’un point de vue pratique, le processus de recherche des composantes connexes d’un graphe non orienté quelconque aboutit à trouver ses sous-graphes connexes maximaux. Dans ce contexte, « connexe » signifie qu’il existe une suite d’arêtes permettant d’atteindre ݒ à partir .ݑ de Pour systématiser les relations entre les points d’un nuage, il est possible de les représenter sous forme d’une matrice d’adjacence servant ordinairement à caractériser des graphes non orientés. Il s’agit de la matrice symétrique ܣሺܩሻ de dimension ܰൈܰ (ܰ – nombre de points du nuage) de telle sorte que ܣሺܩሻ ൌ ൫ܽ௜௝൯: 1 ൑ ݅, ݆ ൑ ܰ. S’il existe une arête (en terme des graphes) entre deux points i et j, alors ݆ܽ݅ est égal à l’unité, sinon on lui attribue une valeur égale à zéro. L’inconvénient majeur d’une telle représentation des nuages de points est que l’on a besoin d’une énorme quantité de mémoire pour son stockage. Cependant, tous les graphes peuvent être classés en deux catégories : les graphes denses et creux (sparse). Ces derniers contiennent beaucoup moins d’arêtes que le nombre de sommets au carré ሺ|ܧ| ൑ |ܸ| 2ሻ. Or, la construction de matrice d’adjacence est superflue pour ce type de graphes. Elle ne peut pas être aussi applicable à des nuages de points. L’idée de notre approche consiste à créer plutôt une liste d’adjacence (liste de successeurs) puisque c’est une représentation alternative de la matrice d’adjacence. En fait, elle comprend, pour chaque point (sommet), une liste de sommets voisins à celui étant examiné (Figure 9.13c). Pour ce faire, il faut mettre en œuvre un algorithme de recherche de voisinage local comme nous l’expliquerons plus loin. Son choix va imposer un mode de création des connexions entre les points du nuage et donc, un nombre d’arêtes obtenues en dépendra. Tous les points relativement proches de celui analysé seront reliés par une arête adéquate. CHAPITRE 4. Extraction d’arêtes 73 Figure 9.13 Représentation d’un nuage de points : a) Nuage de points de départ ; b) Graphe non orienté ; c) Liste d’adjacence Voisinage local Au regard de récentes publications, deux définitions de voisinage local s’avèrent plus répandues [Rabbani et al., 2006]. La première, utilisée par [Castillo et Zhao, 2009], amène à prendre un échantillon, autour d’un point, composé des k voisins les plus proches k-NN (k-Nearest Neighbors) selon une distance à définir. La métrique peut être donnée par la distance Euclidienne, de Manhattan ou autre. En outre, la recherche des k-NN est souvent optimisée à l’aide de différentes stratégies de partitionnement de l’espace comme l’arbre kd (kd-tree) ou un octree. L’inconvénient majeur de cette technique est de dépendre de la densité du nuage. En admettant un nuage peu dense, le k-ème point peut être très éloigné du point envisagé et ne devrait pas être considéré comme voisin. En revanche, le fait d’être indépendant de la distance rend cette méthode plus avantageuse pour certaines applications. La seconde approche, employée entre autres dans les travaux de [Deschaud, 2010], mieux adaptée aux données de densité élevée, consiste à percevoir comme voisins tous les points inclus dans la sphère de rayon ߩ. Un tel raisonnement permet d’être partiellement indépendant de la répartition des points. Par contre, cette méthode nécessite que la densité du nuage reste assez homogène. Sinon, le voisinage va inclure trop de points dans les régions denses et pas suffisamment de points dans celles ayant une densité faible. Dans le même esprit [Lari et al., 2011] proposent un algorithme similaire dont l’idée consiste à établir le voisinage de chaque point par l’intermédiaire d’un cylindre adaptif, tout en prenant en compte la densité locale et la tendance de surface. L’analyse de nos relevés laser mobile, en terme de répartition de point, confirme que les points au sein du nuage ne sont pas uniformément répartis sur la surface balayée. En effet, l’espacement entre les points n’est pas constant – il augmente avec la distance croissante objet-scanner. De plus, nous observons qu’il varie suivant deux directions. La distance entre deux points voisins en profil laser est plus petite que celle mesurée dans le sens de la direction de la plate-forme. Cette première va dépendre de la résolution angulaire du scanner laser, tandis que l’emplacement entre les profils laser change du fait de la vitesse du véhicule et de la fréquence du scanner. En fin de compte, nous avons décidé d’unir les deux premières définitions et de déterminer le voisinage local comme un échantillon inclus dans la sphère de rayon ߩ, mais en même temps de limiter le nombre de points autorisés à ݇. Dans ce cas, nous pouvons tirer profit des deux techniques. Le voisinage établi au sein des régions sur-densifiées ne sera jamais trop chargé, et celui créé pour les zones sous-densifiées ne contiendra pas de voisins inexacts. 74 Étiquetage des composantes connexes Une fois le voisinage de chaque point du nuage établi, la matrice creuse A contenant une liste de toutes les paires est créée. L’étape précédente étant primordiale, nous pouvons procéder à l’extraction des composantes connexes à partir d’un graphe ܩ. Figure 9.14 a) Graphe non orienté ; b) Trois composantes connexes détectées L’une des façons de faire consiste à appliquer l’algorithme de parcours en profondeur DFS (Depth First Search) [Sarni et Lemarchand, 2011], [Corman et al., 2001]. C’est un algorithme de recherche explorant un chemin « à fond », sommet par sommet, jusqu’à ce que l’on ne puisse plus avancer dans le graphe. Nous associons donc à un point de départ et à chacun des sommets visités lors de l’exploration, un même numéro de composante connexe. Après cette recherche deux cas peuvent se présenter : 1) Tous les sommets du graphe ont été atteints. Alors, le graphe est connexe et nous obtenons une seule composante connexe ; 2) Certains sommets n’ont pas été visités et, par conséquent, nous relançons l’algorithme à partir de l’un d’entre eux, en incrémentant l’indice de composante connexe. Nous continuons ainsi tant qu’il subsiste des sommets non explorés. La Figure 9.14 illustre un exemple de résultats obtenus grâce à cet algorithme. Alternativement, il est possible d’employer l’algorithme de parcours en largeur BFS (Breadth First Search) qui réalise le parcours itératif d’un graphe en utilisant un fil. Il diffère du DFS par le fait qu’il liste d’abord les sommets voisins du point examiné pour ensuite les explorer un par un. Ces deux solutions paraissant être coûteuses en temps de calcul, nous proposons de nous référer à une méthode plus efficace, rapide et facile à implémenter. Il s’agit d’appliquer l’un des algorithmes classiques de la théorie des graphes notamment la décomposition de Dulmage-Mendelsohn, notée la DM-Décomposition [Dulmage et Mendelsohn, 1958] de la matrice non carrée A formée au préalable. Celle-ci consiste à permuter les colonnes Q et les lignes P de la matrice creuse A (beaucoup plus grande que dense) représentant le graphe afin d’obtenir la forme bloc triangulaire inférieur (9.11). ܣሺܲ, ܳሻ ൌ ൦ܣଵଵ 0 0 0 ଵଶܣ 0 0 0 ଵଷܣ ଶଷܣ 0 0 ଵସܣ ଶସܣ ଷସܣ ସସܣ ൪ (9.11) où : les sous-matrices ܣ12, ܣ23, ܣ34 sont carrées avec une diagonale entièrement non nulle. CHAPITRE 4. Extraction d’arêtes 75 En d’autres termes, nous allons partitionner les lignes ܮ (respectivement, les colonnes ܥ) en trois sous-ensembles ce qui revient à partitionner la matrice ܣ en neuf blocs, dont trois vont s’avérer être nuls (Figure 9.15). Pour rappel, chaque entrée non-nulle de la matrice creuse ܣ représente une arête du graphe. Une telle matrice rectangulaire décrit naturellement un graphe biparti non-orienté où il y a deux types de nœuds, les sommets « lignes » ܮ et les sommets « colonnes » ܥ. Nous effectuons, pour mettre sous forme triangulaire par bloc la matrice d’adjacence ܣ, la décomposition de Dulmage – Mendelsohn. Son idée consiste à calculer un couplage maximum (matching) ܯ dans le graphe, c’est-à-dire, un sous-ensemble des arêtes le plus grand possible tel qu’elles n’aient aucun sommet en commun [Cormen et al., 2001]. ௩ܥ ௦ܥ ௛ܥ A B ௛ܯ ௛ܮ ܮ௦ 0 ܯ௦ C ܮ௩ 0 0 ܯ௩ Figure 9.15 Décomposition canonique de la matrice d’adjacence ܣ Nous introduisons, conformément à [Pothen et Fan, 1990], la terminologie suivante. Étant donné un couplage ܯ, un sommet insaturé n’appartient à aucune arête du couplage. Une chaîne alternée est un chemin dans le graphe qui ne repasse pas deux fois par le même sommet, et dont une arête sur deux appartient au couplage. Une chaîne alternée est dite augmentante si elle relie deux sommets insaturés. Sur cette base, nous constatons qu’un couplage est maximal, si est seulement si, il n’existe pas de chaîne alternée augmentante relativement à ܯ. Une fois le couplage maximum calculé, le graphe ܩ est alors partitionné comme suit : ܮ௩ : sommets de ܮ accessibles par une chaîne alternée depuis un sommet insaturé de ܮ ; ܮ௛ : sommets de ܮ accessibles par une chaîne alternée depuis un sommet insaturé de ܥ ; ܥ௩ : sommets de ܥ accessibles par une chaîne alternée depuis un sommet insaturé de ܮ ; ܥ௛ : sommets de ܥ accessibles par une chaîne alternée depuis un sommet insaturé de ܥ ; ܮ௦ ൌܮെ ሺܮ௩ ∪ ܮ௛ሻ ܥ௦ ൌܥെ ሺܥ௩ ∪ ܥ௛ሻ Comme l’affirme [Bouillaguet, 2011], il est aussi démontrable que : 1) Tous ces ensembles sont deux-à-deux disjoints ; 2) Le couplage relie les lignes de ܮ௩ à des colonnes de ܥ௩ et respectivement les lignes de ܮ௛ à des colonnes de ܥ௛. Par conséquent, |ܮ௩| ൐ |ܥ௩| et |ܮ௛| ൏ |ܥ௛| ; 3) Le couplage relie parfaitement les lignes de ܮ௦ aux colonnes de ܥ௦. Il en découle que |ܮ௦| ൌ |ܥ௦|. 4) Dans le graphe de départ il n’y a pas d’arêtes entre ܥ௛ et ܮ௦, ni entre ܥ௛ et ܮ௩, ni entre ܥ௦ et ܮ௩. Pour mieux illustrer la DM-Décomposition d’une matrice ܣ, nous présentons le résultat obtenu avec la fonction dmperm (accessible sous Matlab et implémentée aussi dans notre algorithme) sur le nuage de la Figure 9.9a. Ainsi, la permutation des lignes ܲ et des colonnes ܳ transforme la matrice d’adjacence ܣ en forme illustrée par la Figure 9.16. 76 Figure 9.16 DM-Décomposition sur données réelles Ensuite, les indices de points ܦܫܺ du nuage ܰ appartenant à la même composante connexe sont déterminés de la manière suivante : ܦܫܺ ൌ ܲሺݎሺ݅ሻ: ݎሺ݅൅1ሻ െ 1ሻ (9.12) où : ܲ : liste permutée de colonnes ݎ : vecteur indiquant les limites de blocs pour la décomposition ‖ݎ‖ െ 1 : nombre de composantes connexes retrouvées Figure 9.17 Composantes connexes extraites à l’aide de l’algorithme proposé. Paramètres fixés : R=0.10m, k=25, ܰ݉݅݊=0. Une couleur correspond à une composante. L’étiquetage des composantes connexes se fait de façon itérative, en incrémentant la valeur ݅ jusqu’à ce que l’on atteigne le nombre de régions recherchées. À ce stade, nous pouvons introduire une contrainte concernant le nombre minimal de points ܰ݉݅݊ formant la CHAPITRE 4. Extraction d’arêtes 77 composante connexe. Tous les sous-ensembles ne satisfaisant pas aux exigences sont immédiatement rejetés. La Figure 9.17 présente les résultats d’étiquetage de composantes connexes en tenant compte de la décomposition effectuée (Figure 9.16). Surface d’un sous-ensemble de points Dès que toutes les composantes connexes sont extraites, nous calculons leurs surfaces. Nous entendons par ce terme l’aire de l’enveloppe convexe 2D (convex hull) englobant l’ensemble fini de points d’une composante. Nous cherchons ainsi le contour du plus petit polygone fermé et convexe délimité par tous les points (Figure 9.18). Le calcul de l’enveloppe convexe se fait à l’aide du plan moyen Π sur lequel les points de la région sont projetés. Plusieurs algorithmes de complexité diverse ont été développés pour résoudre un tel problème notamment : la marche de Jarvis (Gift wrapping algorithm) [Jarvis, 1973], le parcours de Graham (Graham’s scan) [Graham, 1972], l’heuristique de AklToussaint, ou le diagramme de Voronoï. Nous avons employé la bibliothèque CGAL (Computational Geometry Algorithms Library) mettant à disposition l’algorithme Quickhull de [Bykat, 1978]. Finalement, l’aire de l’enveloppe convexe représente la taille de la composante connexe. Nous conservons uniquement, cette composante dont la surface est la plus importante. Les autres points reviennent au nuage pour participer de nouveau à la recherche d’un segment plan par l’algorithme de RANSAC. Figure 9.18 Aire du segment plan Le pseudo-code 4.2 (Annexe E) présente notre approche d’analyse de composantes connexes telle qu’elle est décrite dans cette section. Trois paramètres sont attendus en entrée notamment le rayon de sphère ߩ et la valeur ݇ afin d’établir le voisinage du chaque point du nuage. Optionnellement, le nombre minimal de points ܰ݉݅݊, peut être pris en compte afin de définir la taille de la plus petite composante connexe autorisée. 4.5 Méthode proposée d’extraction d’arêtes Une fois tous les plans principaux détectés, nous procédons à extraire les segments de ligne. Nous cherchons à retenir uniquement les arêtes réelles figurant dans la scène. Étant donné que lors du processus de segmentation des surfaces planes décrit ci-dessus nous bénéficions non seulement d’un ensemble de modèles de plans ∏, mais aussi des sous-ensembles de points - segments plans (ܵܲ௜), le processus d’identification d’arêtes est assez aisé (Figure 9.19). Quant à l’ensemble ∏, il est défini de telle sorte que chacun de ces éléments soit caractérisé par un vecteur directeur ݊݅ et un point ܣ݅ (par lequel le plan ∏i passe). Par conséquent, la droite d’intersection ܫ entre deux plans ∏j et ∏k peut être facilement 78 retrouvée. Le vecteur directeur ݑሬԦ de cette ligne est le produit vectoriel de deux vecteurs normaux : ݑሬԦ ൌ ݆݊ ሬሬሬԦ ൈ ݊݇ ሬሬሬԦ (9.13) Figure 9.19 Segments plans extraits par RANSAC Néanmoins, à cette étape deux questions doivent se poser : 1) Quels segments plans de l’ensemble ∏ sont sécants ?; 2) Comment définir les extrémités du segment de ligne résultant de cette intersection ? Pour répondre à ces interrogations, nous proposons une méthode qui s’attache à analyser toutes les combinaisons possibles des plans afin de dissocier ceux étant voisins. La Figure 9.20 contient le schéma complet de l’approche discutée. Figure 9.20 Procédure proposée d’extraction d’arêtes CHAPITRE 4. Extraction d’arêtes 79 Premier rejet des paires de plans – analyse de l’angle Dans un premier temps, l’angle ߚ entre toute paire candidate de plans est calculé, ainsi que le poids ܳ – critère de la qualité de cette intersection. Les deux valeurs peuvent être quantifiées en considérant les vecteurs normaux ݆݊ et ݊݇ des deux plans étudiés. Du point de vue géométrique, la norme de leur produit vectoriel se définit comme : ‖ݑሬԦ‖ ൌ ฮ݊ఫ ሬሬሬԦฮ ∙ ‖݊ሬሬሬሬ (9.14) |ߚ݊݅ݏ| ∙ ‖Ԧ௞ Puisque les deux vecteurs sont unitaires (la norme est égale à l’unité), le poids ܳ peut se calculer de la manière suivante : ܳ ൌ ‖ݑሬԦ‖ଶ ൌ ݏ݅݊ଶߚ (9.15) Il est évident que l’intersection est la meilleure si l’angle  est droit. Or, le poids ܳ associé doit être égal ou proche de l’unité. Si ܳ est petit, alors la longueur du vecteur ݑሬԦ est faible et, par conséquent, la droite d’intersection est mal définie. De même, l’intersection n’existe pas, si deux plans sont parallèles (ܳൌ0). L’analyse des poids ܳ nous permet de réduire la taille de l’ensemble contenant des paires « potentielles » de plans. Dans ces conditions, lors du premier rejet, nous ne conservons que les paires dont le facteur ܳ est supérieur à ܶொ. La valeur ܶொ a été fixée à 0.5, ce qui revient à dire que nous ne prenons en considération que les paires de plans se coupant sous l’angle de 45° à 135°. Toutefois, rien n’empêche d’accroître les exigences envers les intersections recherchées et d’augmenter la limite basse ܶொ. Deuxième rejet des paires de plans – analyse de la distance L’étape suivante nous amène à vérifier la distance ݀ entre les paires restantes et à garder uniquement celles composées par les plans voisins. Considérant deux segments plans chacun doté d’un sous-ensemble de points valables ܵܲ௝ et ܵܲ௞ isolé lors de la segmentation, mais aussi l’équation du plan approximant ∏j et ∏k passant par ce nuage (Figure 9.19), nous pouvons vérifier leur distance réciproque. Nous calculons simplement les distances Euclidiennes les plus courtes des points du nuage ܵܲ௝ au plan ∏K et vice versa (9.16). Il en résulte que les distances minimales ݀1 et ݀ଶ, sont requises afin de pouvoir juger si les plans sont suffisamment proches l’un de l’autre. Les segments plans sont considérés comme adjacents, si est seulement si, la distance ݀ définie comme ݀ ൌ ݉݅݊ሺ݀ଵ, ݀ଶሻ est proche de zéro, avec une certaine tolérance. ݀1 ൌ min ݆∈Յ ൛݀൫݆ܵܲ, ∏݇൯:݆ ∈ ሺ1, ܰሻൟ ݀2 ൌ min ݇∈Յ ቄ݀ ቀܵܲ݇, ∏݆ ቁ :݇∈ ሺ1, ܯሻቅ (9.16) pour ܰ,ܯ : nombre de points respectivement dans les sous-nuages ܵܲ௝ et ܵܲ௞. Cette condition de proximité étant primordiale, elle peut être toutefois insuffisante dans certains cas. La Figure 9.21 illustre un exemple particulier où les deux segments plans ܵܲ௝ et ܵܲ௞ (violet et vert) sont loin d’être sécants, alors que la distance ݀ est égale à zéro. De ce fait, ils sont censés aboutir à une droite d’intersection. Nous souhaitons reconstruire fidèlement les arêtes existantes dans le nuage et éviter de créer ce genre de faux segments. 80 Figure 9.21 Exemple d’appariement devant être rejeté Troisième rejet – analyse des extrémités des segments Pour remédier aux faux appariements, nous examinons la longueur et les extrémités des segments obtenus par cette intersection. Sachant que les paires « candidates » parallèles ont déjà été rejetées, nous déterminons la droite ܫ entre deux plans sécants, de sorte que ∏௝ ∩ ∏௞ ൌ ܫ, à l’aide de la formule (9.13). Ensuite, les points ܵܲ௝ et ܵܲ௞ situés à une distance inférieure à une tolérance prédéfinie ܶௗ sont projetés sur cette droite. Plus précisément, les points se trouvant autour de leur ligne d’intersection servent à identifier les extrémités d’arête de pli. De cette façon, deux segments de ligne ܵ௝ et ܵ௞ sont retrouvés puisque chaque nuage a des limites différentes (Figure 9.22). La dernière étape – l’analyse de la position spatiale des extrémités appartenant aux segments d’intersection créés ܵ௝ et ܵ௞, permet de mettre de côté les paires de plans indûment classées et d’établir la longueur de l’arête finale. Nous ne conservons que les paires de plans dont l’intersection aboutit à deux segments se chevauchant au moins partiellement. L’étude de la position relative de ces segments colinéaires est menée en analysant la distance entre leurs milieux (ܯ௝, ܯ௞ሻ, ainsi que leurs longueurs (ܮ௝, ܮ௞). Trois cas peuvent se présenter : 1) L’un des segments est complètement inclus dans l’autre (Figure 9.23a) : ฮܯ௝ܯ௞ฮ ൑ หܮ௝⁄2 െ ܮ௞⁄2ห. En conséquence, la longueur de l’arête créée correspond au plus court segment ; 2) Les segments se chevauchent partiellement (Figure 9.23b) : หܮ௝⁄2 െ ܮ௞⁄2ห ൏ ฮܯ௝ܯ௞ฮ ൏ หܮ௝⁄2 ൅ ܮ௞⁄2ห et donc la longueur de l’arête retenue est exactement la même que celle de la zone de chevauchement ; 3) Les segments sont disjoints (Figure 9.23c) : ฮܯ௝ܯ௞ฮ ൒ หܮ௝⁄2 ൅ ܮ௞⁄2ห alors l’arête n’existe pas et la paire de plans est supprimée. CHAPITRE 4. Extraction d’arêtes 81 Figure 9.22 Droite d’intersection entre les plans ∏j et ∏k et les extrémités de segments ܵ௝ et ܵ௞ Sachant que nous cherchons à extraire les segments les plus longs possible, nous pouvons, optionnellement, prendre en compte une contrainte ܶ௦௘௚, c’est-à-dire la longueur minimale d’une arête recherchée. Dès lors les arêtes trop petites seront exclues des résultats. Figure 9.23 Relations spatiales entre les extrémités de segments ܵ௝ et ܵ௞ : a)b) arête retenue ; c) arête rejetée 82 Le pseudo-code 4.3 (Annexe E) détaille notre algorithme d’extraction d’arêtes de pli. Nous avons besoin en entrée de segments plans (ܵܲ௜) isolés lors de la segmentation ainsi que les paramètres de plan (∏i) approximant chaque sous-ensemble de points. Nous obtenons, à la sortie, un ensemble d’arêtes ܵܦ de longueur supérieure à ܶ௦௘௚. 4.6 Exemples de résultats L’algorithme d’extraction d’arêtes discuté dans ce chapitre a été testé avec plusieurs nuages de points, qu’ils soient mobiles ou statiques. Nous présentons dans cette partie quelques résultats finaux (4.6.2), ainsi que ceux intermédiaires concernant la détection de segments plans (4.6.1). Sachant que notre algorithme a été développé entièrement sous Matlab, inadapté pour traiter de gros nuages de points, nous ne renseignons pas le temps de calcul (étant assez conséquent en Matlab). Mais, on parle d'environ 50 minutes (sous Intel Core x2 T7600 2.33GHz/4 Go Ram/Win7 64bits) en ce qui concerne les résultats illustrés par la Figure 9.25 (au total 265 266 points ont été traités). 4.6.1 Détection de plans La Figure 9.24 montre soixante plans successifs extraits pour un fragment du nuage de points Stereopolis2009_Soufflot. Les valeurs de tous les paramètres nécessaires pour faire fonctionner notre algorithme sont listées au-dessous de l’image. Nous remarquons que le plan perpendiculaire au sens du déplacement du véhicule, couvrant une superficie assez grande, n’a pas été retrouvé. Cet état de fait est dû à l’angle d’incidence du faisceau laser qui était important, et influençait le taux de bruit entachant les données élevées. En outre, la position de la façade vis-à-vis de la tête du scanner fait que peu de profils laser l’interceptent. La distance moyenne entre les profils consécutifs est donc faible. Nous dénombrons environ 15 lignes sur 5m linéaires de mur, ce qui donne localement une ligne sur 30cm. Nous pourrions ipso facto mettre en doute le fait que ces points forment un plan satisfaisant aux exigences imposées. Quant aux autres plans, nous observons le phénomène de sursegmentation se dévoilant quand les surfaces uniformes en réalité sont segmentées en au moins deux plans distincts. Figure 9.24 Détection de plans - Stereopolis2009_Soufflot. Paramètres fixés : σ=0.015m, P=0.99, ܰ௣௟=60, R=0.30m, k=25, ܰ௠௜௡=100. Une couleur correspond à un plan (points non segmentés en noir) CHAPITRE 4. Extraction d’arêtes 83 La Figure 9.25 illustre les plans extraits à partir du nuage Riegl2012_Slomniki se caractérisant d’un faible taux de bruit. Les résultats sont corrects, mais le problème de sursegmentation apparaît toujours, surtout lors de la segmentation du sol. Figure 9.25 Détection de plans – Riegl2012_Slomniki. Paramètres fixés : σ=0.01m, P=0.99, ܰ௣௟=16, R=0.200m, k=25, ܰ௠௜௡=200. Une couleur correspond à un plan (points non segmentés en noir) D’autres types de problèmes rencontrés lors de l’utilisation de l’algorithme de RANSAC sont montrés par la Figure 9.26. Elle illustre la recherche du premier plan dans le nuage de points mobile. Les études étaient menées sur les données brutes. Le plan mis en évidence était pour l’estimateur la meilleure solution en raison de la forte accumulation des points acquis durant l’arrêt forcé de la plate-forme. Pour pallier ces fausses détections, l’étape de prétraitement des données laser paraît indispensable – le débruitage, la décimation ou bien encore la contrainte de distance minimale entre les points voisins. 84 Figure 9.26 Exemple de problèmes survenus lors de la détection des plans via RANSAC (en rouge les points appartenant au premier plan détecté). Nuage de points du système L3D2 Nous pouvons constater que l’algorithme de RANSAC est sensible à la densité des nuages de points. Par contre, il fournit de très bons résultats, en peu de temps, si le nuage est homogène et sa densité élevée. L’approche proposée d’analyse de composantes connexes vérifie correctement la connectivité du segment plan. Néanmoins, elle exige un temps considérable afin de trouver le voisinage local de chaque point, ce qui est son seul point faible. L’accélération de recherche des voisins faite par un arbre kd ou un octree, au lieu d’un parcours linéaire, serait appréciée. L’un des futurs travaux sera de tester sa robustesse par rapport aux autres méthodes d’extraction des composantes connexes, notamment les algorithmes récursifs d’exploration de graphe (DFS, BFS), ou bien encore la solution d’analyse du voisinage à l’aide d’image 2D. 4.6.2 Extraction d’arêtes La Figure 9.27 illustre des résultats d’extraction d’arêtes dans le nuage de points acquis par les systèmes mobiles. Tandis que la Figure 9.28 montre les segments extraits à partir du nuage Sulpice2013_statique. Notre algorithme arrive à détecter correctement toutes les arêtes, mais leur précision et le nombre dépendra fortement des segments plans pris en compte. Dès lors, l’algorithme choisi de segmentation prédéterminera la complétude et la qualité de la solution. CHAPITRE 4. Extraction d’arêtes 85 Figure 9.27 Arêtes extraites à l’aide de l’algorithme proposé (Tseg=2.000m). a) Riegl2012_Slomniki ; b) Stereopolis2009_Soufflot Figure 9.28 Arêtes extraites à l’aide de l’algorithme proposée (Tseg=1.000m) : Sulpice2013_statique a) b) 87 CHAPITRE 5 Qualification à partir d’entités linéaires Sommaire : 5. Qualification à partir d’entités linéaires ........................................................................ 87 5.1 Problématique .......................................................................................................................... 87 5.1.1 Comment mesurer la distance entre deux segments dans l’espace ? .................................... 88 5.1.2 Contraintes ........................................................................................................................................ 90 5.2 Mesure de distance proposée ................................................................................................. 91 5.2.1 Distance de Hausdorff ..................................................................................................................... 92 5.2.2 Matrice de similarité ....................................................................................................................... 94 5.2.3 Mise en correspondance ................................................................................................................. 96 5.3 Résultats et évaluation ........................................................................................................... 99 5.3.1 Données expérimentales ................................................................................................................ 99 5.3.2 Évaluation de l’algorithme d’appariement ............................................................................... 100 5.3.3 Exactitude et précision ................................................................................................................. 105 5. Qualification à partir d’entités linéaires Dans ce chapitre, une nouvelle approche de qualification de relevés laser mobiles, son implémentation et les résultats sont présentés. Celle-ci, basée sur les arêtes, semble être efficace et tout particulièrement pour les besoins d’évaluation des nuages dont la densité faible empêche une identification précise des points de contrôle. Adressée principalement à des zones urbaines, riches en primitives linéaires, notre méthode délivre une mesure de qualité en s’appuyant sur la distance modifiée de Hausdorff (LHD). La mise en correspondance de segments homologues, menée simultanément, joue un rôle crucial et, par conséquent, elle doit être fiable. Nous proposons alors un algorithme entièrement automatique, consistant à analyser la similitude entre les arêtes extraites de données mobiles et celles de référence. Sa valeur, recueillie par la matrice de similarité, est déterminée en tenant compte de la distance et de l’angle. Enfin, nous testons la robustesse d’un tel algorithme d’appariement, et qualifions les relevés laser mobiles en termes d’exactitude et de répétabilité. 5.1 Problématique Dans le dessein de développer une méthode de qualification de relevés laser mobiles acquis dans un environnement urbain, nous proposons une approche basée sur les entités linéaires. Celles-ci, représentant des intersections entre des plans principaux modelés dans le nuage, Résumé 88 peuvent être extraites à l’aide de l’algorithme présenté dans le Chapitre 4. Ensuite, la technique mise en œuvre se résume à une comparaison de deux ensembles de segments. Le premier ensemble Test, contenant des droites à qualifier, sera confronté avec le second nommé Model. Ce dernier, considéré désormais comme référence, se compose des segments plus précis provenant, entre autres de levés topographiques, de nuages de points collectés en mode fixe, mais aussi d’autres bases de données, qu’elles soient 2D ou 3D. Notre solution, contrairement à celles envisagées par les méthodes se référant aux points de contrôle, vise à diminuer les problèmes liés à l’identification correcte de cibles correspondantes. Toutes les démarches détaillées au fur à mesure dans ce chapitre ne nécessiteront plus l’intervention d’opérateur. L’appariement des segments s’effectue automatiquement, en examinant la similitude des droites. Grâce à la comparaison des segments entre eux, il est possible de repérer les entités linéaires Model (M) identiques ou très proches de celles de l’ensemble Test (T). Mais, cette tâche devient encore plus complexe, quand on présume que le nombre de segments peut varier d’un ensemble à un autre, et que leur longueur ne sera pas forcément la même. En outre, nous observons également des droites pour lesquelles aucun homologue n’existe dans l’ensemble de référence (Figure 5.1). Ce constat est dû au fait que le processus d’extraction des segments peut engendrer des phénomènes de sur-segmentation et de soussegmentation. Figure 5.1 Exemple d’arêtes à comparer : a) segments ܶ݁ݐݏ ; b) segments ݋ܯ݈݀݁ ; c) les deux ensembles superposés Dans ce chapitre, une méthode de qualification sera présentée (Section 5.2), ainsi que les résultats obtenus. Aussi, l’algorithme de mise en correspondance des segments 3D sera examiné par rapport à la vérité-terrain (Section 5.3). Pour compléter ces analyses, l’impact du décalage réciproque entre les segments étudiés sur la robustesse de l’algorithme d’appariement sera vérifié. Une fois le couplage créé, nous proposerons d’évaluer les nuages de points en termes d’exactitude et de précision (répétabilité). C’est pourquoi la distance moyenne calculée à partir de segments, étant la distance modifiée de Hausdorff LHD (Line Hausdorff Distance), servira à noter les nuages. Finalement, les avantages et les inconvénients d’une telle procédure de qualification de relevés laser seront mis en avant. 5.1.1 Comment mesurer la distance entre deux segments dans l’espace ? L’utilisation des arêtes, au lieu des points de contrôle, pour les besoins de qualification, exige d’élaborer une métrique qui permettrait de comparer deux ensembles d’entités linéaires. Certes, nous ne pouvons plus nous référer uniquement aux extrémités, puisque les segments correspondants ne sont pas censés ni partager les mêmes coordonnées ni avoir la même longueur. L’une des façons de faire peut être de définir la moyenne des distances ݀ calculées entre les segments homologues provenant de différentes sources. La plupart des méthodes abordant cette question s’appuient sur le calcul de la distance Euclidienne. Nous pouvons aboutir à différentes variantes, comme l’illustre la Figure 5.2, visant, par exemple, à déterminer la distance minimale, la distance entre les milieux de segments correspondants (ܯ௉, ܯொ), ou leurs extrémités (ܲ଴, ܲଵ, ܳ଴, ܳଵ). CHAPITRE 5. Qualification à partir d’entités linéaires 89 Figure 5.2 Définition de la distance entre deux segments 3D : a) Distances déterminées entre les extrémités ; b) Distance calculée entre les milieux ; c) Distance perpendiculaire d’une extrémité de segment à l’autre segment ; d) Distance minimale ; En considérant la distance ݀ entre les extrémités des segments (Figure 5.2a), nous calculons tout simplement les distances d’un point 3D à l’autre : ݀ሺܲ଴, ܳ଴ሻ ൌ ඨ෍ ൫ܲ଴೔ െ ܳ଴೔ ൯ ଶ ଷ ௜ୀଵ ݀ሺܲଵ, ܳଵሻ ൌ ඨ෍ ൫ܲଵ೔ െ ܳଵ೔ ൯ ଶ ଷ ௜ୀଵ (5.1) Sachant que les coordonnées du milieu d'un segment sont les demi-sommes de chacune des coordonnées des extrémités, nous introduisons, de manière similaire (formule (5.1)), la distance ݀ calculée, cette fois-ci, entre les milieux respectifs (Figure 5.2b). De même, nous pouvons envisager la distance des extrémités du premier segment (ܲ଴, ܲଵ) par rapport à la droite ܮ passant par le second segment, et vice versa (Figure 5.2c). Il s’agit alors de la distance minimale d’un point à une droite ܮ, mesurée suivant la formule ci-dessous : ݀ሺܲଵ, ܮሻ ൌ ฮܳ଴ܲଵ ሬሬሬሬሬሬሬሬሬԦ˄ݒԦฮ ‖Ԧݒ‖ (5.2) pour la droite ܮ définie par un point ܳ଴ et un vecteur ݒԦ non nul. L’indice ˄ symbolise le produit vectoriel de deux vecteurs. Dans tous les cas mentionnés, l’étape dernière nous amène à prendre la moyenne ou le minimum des distances ݀ obtenues. Cependant, la formulation de la distance minimale entre deux segments n’est pas aisée (Figure 5.2d). Aussi, elle ne peut pas être confondue avec la distance minimale entre les droites traversant ces segments puisque ces valeurs sont souvent différentes (Figure 5.3). Or, 90 le point d’une ligne désigné comme le plus proche de l’autre ligne peut ne pas être situé sur la partie de droite délimitée par deux points fixes (extrémités). Figure 5.3 a) Distance entre deux droites; b) Distance entre deux segments de droite [van Verth et Bishop, 2008] avancent une solution de [Sunday, 2001] permettant de résoudre cette tâche. Étant donné que la distance entre deux objets géométriques ܲ et ܳ est définie comme la distance entre deux points quelconques ݌∈ܲ et ݍ∈ܳ (5.3), le problème se résume toujours à trouver ces points minimisant la distance ݀. ݀ሺܲ, ܳሻ ൌ min ௣ఢ௉,௤ఢொ ݀ሺ݌, ݍሻ (5.3) Quant à la distance entre deux segments, nous l’assimilons au calcul de la distance d’une ligne à l’autre. Nous représentons le segment ܵଵ ൌ ሾܲ଴, ܲଵሿ par l’équation paramétrique de droite ܮଵ: ܲሺݏሻ ൌ ܲ଴ ൅ ݏሺܲ଴ െ ܲଵሻ ൌ ܲ଴ ൅ ݑݏሬԦ et le segment ܵଶ ൌ ሾܳ଴, ܳଵሿ comme ܮଶ: ܳሺݐሻ ൌ ܳ଴ ൅ ݐሺܳ଴ െ ܳଵሻ ൌ ܳ଴ ൅ ݒݐԦ pour 0 ൑ ݏ, ݐ ൑ 1. Ainsi, nous cherchons, pour ܮଵ et ܮଶ, les paramètres ݏ஼ et ݐ஼ de telle sorte qu’ils décrivent la position des points les plus proches ܲሺݏ஼ሻ et ܳሺݐ஼ሻ. Une seule différence réside dans le fait que la recherche de ces points est restreinte à l’intervalle défini par les extrémités de chacun des segments. Finalement, la distance minimale entre deux segments ܵଵ et ܵଶ correspond à la norme du vecteur ݓሬሬሬሬሬ ஼Ԧ dont les coordonnées sont données par les points ܲሺݏ஼ሻ et ܳሺݐ஼ሻ. ݀ሺܵଵ, ܵଶሻ ൌ ‖ݓሬሬሬሬሬ ஼Ԧ‖ ൌ ‖ܲሺݏ஼ሻ െ ܳሺݐ஼ሻ‖ (5.4) En minimisant la norme de ݓሬሬሬሬሬ ஼Ԧ nous arrivons à déterminer les paramètres ݏ஼ et ݐ஼. La description plus exhaustive de cette approche fait partie de l’Annexe A. 5.1.2 Contraintes Afin d’être en mesure de vérifier la qualité (l’exactitude et la précision) à partir des segments de droite, la distance réciproque ݀ሺݐ, ݉ሻ entre eux doit être définie de manière à refléter leur véritable éloignement. Cependant, les approches listées auparavant ne sont pas suffisamment robustes pour nos applications puisqu’elles n’envisagent ni orientation de droites ni situation où les segments se chevauchent seulement partiellement. Nous en avons pour preuve quelques exemples présentés par la Figure 5.4. Nous y voyons clairement que, dans certains cas, les distances déterminées ne restituent pas de vraies relations mutuelles entre les segments. Ainsi, pour les droites quasiment parallèles (Figure 5.4a,b), cette valeur peut être importante, et inversement, les deux segments orientés différemment (Figure 5.4c,d,e) peuvent être classés comme relativement proches (distance faible, voire égale à zéro). CHAPITRE 5. Qualification à partir d’entités linéaires 91 Figure 5.4 Exemples générant des calculs de distances erronés : a) Distances déterminées entre les extrémités ; b) Distance calculée entre les milieux ; c) Distance perpendiculaire d’une extrémité de segment à l’autre segment ; d)e) Distance minimale ; Afin de surmonter ce genre d’inconvénients [Gao et Leung, 2002] suivis par [Chen et al., 2003] ont proposé une approche dédiée à la comparaison des segments 2D extraits à partir des logos (images). Nous nous en sommes inspirés pour notre méthode en l’adaptant à un espace tridimensionnel. Dès lors, la distance entre les segments 3D ralliera l’écartement, mais aussi l’angle formé entre chaque paire de droites homologues. La section suivante abordera en détail ce sujet. 5.2 Mesure de distance proposée La Figure 5.5 présente un aperçu général des étapes de calcul constituant l’approche proposée. Dans un premier temps, la similarité entre toutes les combinaisons possibles de droites, provenant de deux ensembles ܶ (ܶ݁ݐݏ) et ܯ (݋ܯ݈݀݁), sera notée sous forme d’un score ݀ሺݐ, ݉ሻ. Celui-ci étant le coefficient de la matrice de similarité, il fera, par la suite, l’objet d’une étude particulière. Sa valeur servira à vérifier si les deux segments sont suffisamment similaires pour être appariés, et s’ils sont susceptibles d’être employés pour déterminer la distance moyenne – notre mesure de qualité. Étant donné que seuls les segments quasiparallèles peuvent être appariés, on se devra de prendre en compte l’orientation et la position des segments pour calculer chaque score ݀ሺݐ, ݉ሻ. Le paragraphe 5.2.2 se penchera sur ce sujet. Passons à présent à la mise en correspondance des segments. Nous devons trouver le moyen permettant de conclure que les deux entités comparées sont semblables. Nous mémoriserons uniquement les paires dont les scores sont jugés négligeables, c’est-à-dire, inférieurs ou égaux à un seuil que l’on s’est fixé automatiquement en fonction de valeurs ݀ሺݐ, ݉ሻ sélectionnées. Toutes les paires retenues formeront ensuite la matrice binaire de correspondance ݎ݋ܥ, systématisant les interactions entre les éléments linéaires de deux ensembles étudiés ܶ݁ݐݏ et ݋ܯ݈݀݁. Une fois l’appariement retrouvé, nous déterminerons l’écartement des données traitées. Cette mesure, étant la distance modifiée de Hausdorff LHD (Line Hausdorff Distance), évaluera, d’une manière objective, l’exactitude du relevé laser en calculant sa distance par rapport à la référence. Également, la qualification de la précision deviendra possible à réaliser, sous réserve que des nuages redondants soient collectés au sein de zones d’intérêt. Comme nous 92 l’expliquerons plus loin, toutes les opérations seront menées dans deux sens : l’ensemble ܶ݁ݐݏ sera comparé avec le ݋ܯ݈݀݁ et vice versa. Par conséquent, deux matrices de correspondance seront obtenues, ainsi que deux distances relatives de Hausdorff OLHD (Oriented Line Hausdorff Distance). Figure 5.5 Calcul de distance entre segments : algorithme proposé 5.2.1 Distance de Hausdorff En géométrie, la métrique de Hausdorff est un outil de détermination de la proximité de deux sous-ensembles de points dans un espace fini. Cette mesure de similarité naturelle est très utilisée pour le traitement d’image. Elle permet de qualifier les dissemblances entre les formes, de numériser une image ou bien encore de reconnaître une forme. Nombreux sont les chercheurs faisant appel à cette métrique par exemple [Huttenlocher et al., 1993], [Grussenmeyer et al., 1994], [Abbas et al., 1995], [Choi et al., 2001], [Gao et Leung, 2002], [Chen et al., 2003], [Benhabiles et al., 2009], [Wang et Tan, 2012], [Gao et al., 2012]. Contrairement à la majorité des méthodes d’analyse de forme, la distance de Hausdorff ne requiert pas de mise en correspondance explicite des points ܶ݁ݐݏ et ݋ܯ݈݀݁. Considérant deux ensembles de points ܶ ൌ ൛ݐଵ, ݐଶ,…,ݐ௣ൟ et ܯ ൌ ൛݉ଵ, ݉ଶ,…,݉௤ൟ, la distance de Hausdorff (ܪ) est la distance maximale de deux quantités : ݄ሺܶ, ܯሻ et ݄ሺܯ, ܶሻ (5.5). ܪሺܶ, ܯሻ ൌ ݉ܽݔ൫݄ሺܶ, ܯሻ, ݄ሺܯ, ܶሻ൯ (5.5) Ces deux composants, nommés distances relatives de Hausdorff, n’ont quasiment jamais la même valeur (Figure 5.6). La distance de Hausdorff n’est pas alors symétrique (݄ሺܶ, ܯሻ ് ݄ሺܯ, ܶሻ). La première distance ݄ሺܶ, ܯሻ est le maximum parmi toutes les distances ݀ሺݐ, ݉ሻ, calculées entre chaque point d’un sous-ensemble ܶ et un autre point le plus proche de l’ensemble ܯ (5.6). La seconde ݄ሺܯ, ܶሻ, est définie pareillement, mais en direction de calcul opposée. Quant à ݀ሺݐ, ݉ሻ, c’est une distance quelconque – généralement exprimée en tant que distance Euclidienne. Cependant, rien n’empêche l’utilisation des autres métriques telle que la distance de Manhattan par exemple. ݄ሺܶ, ܯሻ ൌ max ௧∈் min ௠∈ெ ݀ሺݐ, ݉ሻ (5.6) CHAPITRE 5. Qualification à partir d’entités linéaires 93 Figure 5.6 Définition de la distance de Hausdorff entre deux polygones Nonobstant [Dubuisson et Jain, 1994] définissent 24 formes différentes de la distance de Hausdorff, dont une version modifiée MHD (Modified Hausdorff Distance). La principale différence réside dans la façon de définir la distance relative ݄ሺܶ, ܯሻ qui sera désormais calculée comme suit : ݄ሺܶ, ܯሻ ൌ 1 ܰ௧ ሻܯ ,ݐሺ݀ ෍ ௧∈் (5.7) où : ܰݐ : nombre de points dans l’ensemble ܶ Il s’agit de la moyenne de toutes les distances minimales obtenues. Ainsi, chaque point de l’ensemble a un impact sur la valeur finale. Ce même constat ne peut s’observer lorsque la distance classique de Hausdorff est employée, même si les points sont assez proches les uns des autres. Cette définition non seulement ne néglige donc aucun des points, mais encore, selon les études complémentaires effectuées par [Benhabiles et al., 2009], elle donne de meilleurs résultats que la définition de Hausdorff classique. En d’autres termes, la distance de Hausdorff définie par les équations (5.5) et (5.6) est censée être très sensible aux points aberrants. Par conséquent, quelques points aberrants, même un seul, peuvent considérablement perturber le calcul. Néanmoins, il faut souligner que sa valeur n’est pas une distance à proprement parler, car elle ne vérifie pas le principe d’inégalité triangulaire. Line Hausdorff Distance comme mesure d’écartement entre deux jeux de segments La définition de la distance modifiée de Hausdorff telle quelle n’est pas appropriée pour les besoins de comparaison des entités linéaires, puisqu’elle ne prend pas en compte l’orientation de celles-ci [Gao et Leung, 2002]. Un exemple de problèmes rencontrés est illustré par la Figure 5.7. Il en ressort très clairement que la distance renvoyée par la Figure 5.7a peut être identique à celle calculée entre les segments 3 et 4 (Figure 5.7b). Cependant, les droites sur la Figure 5.7a, dans la perception humaine, sont plus proches que ces deux dernières. De même, en analysant à l’aide de la distance de Hausdorff les segments présentés par la Figure 5.7c, nous comparerons l’extrémité de la partie la plus haute de 7 avec la ligne 5, tandis que celle la plus basse avec la ligne 6. Cette démarche n’est pas correcte puisque la droite 7 doit être intuitivement perçue comme une seule entité, et sa distance mesurée par rapport, soit au segment 5, soit au segment 6. 94 Figure 5.7 Exemple de problèmes liés à la distance modifiée de Hausdorff appliquée à des lignes (Image reproduite à partir de [Gao et Leung, 2002]) Afin de faire face à toutes ces contraintes [Gao et Leung, 2002] ont proposé, pour l’imagerie 2D, une extension de la distance introduite par [Dubuisson et Jain, 1994] applicable, cette fois-ci, à des droites. La distance directe OLHD (Oriented Line Hausdorff Distance) se calcule de la manière suivante : ܱܦܪܮሺܶ, ܯሻ ൌ 1 ∑௠ೕ∈ெ ܮ௠ೕ ೕ௠ܮ ෍ ݀൫ݐ௜, ݉௝൯ ௠ೕ∈ெ (5.8) où : ݆݉ܮ : longueur du segment de l’ensemble Model (référence) ݀൫ݐ௜, ݉௝൯ : distance entre deux segments Une telle solution, fondée sur la moyenne pondérée, semble plus robuste lorsque les segments plus longs sont privilégiés. Cette définition est devenue le point de départ pour notre approche de qualification basée sur les entités linéaires. Afin qu’elle soit capable de décrire l’exactitude et la précision de données étudiées, elle doit être modifiée. Ceci est dû au fait que nous voulons insister sur le fait que la distance de Hausdorff représente un chiffre aisé à interpréter, nous permettant de connaître l’écartement réel entre les segments examinés. Or, les distances directes ܱܦܪܮሺܶ, ܯሻ et ܱܦܪܮሺܯ, ܶሻ seront déterminées, selon la formule (5.9), à partir de segments couplés et ordonnés par la matrice de correspondance Cor que nous détaillons plus loin (paragraphe 5.2.3) ܱܦܪܮሺܶ, ܯሻ ൌ 1 ∑௠ೕ∈ெ ܮ௠ೕ ೕ௠ܮ ෍ ݀൫ݐ௜, ݉௝൯ ሺ௜,௝ሻ∈஼௢௥ (5.9) 5.2.2 Matrice de similarité L’étape cruciale de l’algorithme de qualification proposé consiste à créer une matrice de similarité, dont chaque coefficient ሺ݅, ݆ሻ indiquera un score (une distance) ݀ሺݐ, ݉ሻ attribué à une paire étudiée. L’objectif consiste à analyser toutes les combinaisons possibles de segments entre deux jeux. La matrice de similarité de taille ሺ݌, ݍሻ, déterminée par le nombre d’éléments dans les ensembles respectifs ܶ݁ݐݏ et ݋ܯ݈݀݁, est obtenue selon la formule cidessous : CHAPITRE 5. Qualification à partir d’entités linéaires 95 ݀൫ݐ௜, ݉௝൯ ൌ ටܹ ∙ ቀ݀ఈ൫ݐ௜, ݉௝൯ቁଶ ൅ ቀ݀ூூ൫ݐ௜, ݉௝൯ቁଶ ൅ ቀ݀⟘൫ݐ௜, ݉௝൯ቁଶ (5.10) Le score ݀൫ݐ௜, ݉௝൯ étant la mesure de similitude, représente, en pratique, « l’effort » nécessaire pour superposer deux segments quelconques : l’un provenant de l’ensemble ܶ et l’autre de ܯ. Sa valeur intègre : la distance angulaire ݀ఈሺݐ, ݉ሻ, la distance parallèle ݀ூூሺݐ, ݉ሻ et la distance perpendiculaire ݀⟘ሺݐ, ݉ሻ. La constante ܹ, étant choisie empiriquement, permet de mieux mettre en évidence l’éventuelle divergence d’orientation des droites. Plusieurs tests ont été réalisés pour choisir la valeur optimale de ce poids. Nous en ressortons que le poids ܹ égale à 10 donne le meilleur résultat, c’est-à-dire, il facilite nettement l’analyse ultérieure de la matrice de similarité notamment lors de la recherche du seuil approprié. De plus, il n’affecte pas de manière importante la distance angulaire, puisque sa valeur, pour les droites quasiment parallèles, reste toujours pratiquement nulle. La Figure 5.8 présente toutes les distances que nous définissons pour mesurer la dissemblance entre les segments 3D. La distance angulaire ݀ఈሺݐ, ݉ሻ se calcule de la manière suivante : ݀ఈ൫ݐ௜, ݉௝൯ ൌ ݉݅݊ ቀ||ܮ௧೔ ೕ௠ܮ|| ,|| ||ቁ ∙ ݏ݅݊ߙ൫ݐ௜, ݉௝൯ (5.11) où  : angle d’intersection de deux droites ݐ௜ et ݉௝ ; ೔௧ܮ ,ܮ௠ೕ : longueur respective des segments ݐ௜ et ݉௝. Figure 5.8 Mesure de déplacement de la droite : a) Distance angulaire ; b) Distance parallèle ; c) Distance perpendiculaire Puisqu’en réalité, aucune paire de segments n’est jamais totalement parallèle, nous effectuons une rotation de chaque droite ܶ݁ݐݏ autour de son milieu. Cette étape est indispensable pour obtenir une orientation cohérente des entités linéaires et pour calculer, par la suite, les deux distances manquantes : parallèle et perpendiculaire. Le calcul de la distance parallèle (Figure 96 5.8b) exige une étude des extrémités de deux segments. Nous assimilons ce problème à l’analyse des positions relatives de deux cercles circonscrits à ces segments (comme dans le chapitre précédent – voir la Figure 4.22). Leurs centres respectifs ܯ௧ et ܯ௠ (milieux de segments) ainsi que les rayons ܴ௧ ൌ ܮ௧/2 et ܴ௠ ൌ ܮ௠/2 seront étudiés. Plus précisément, il faut chercher si les deux cercles se croisent. Pour ce faire, le segment ܶ݁ݐݏ est projeté sur la droite ݋ܯ݈݀݁. Il n’y aura donc aucun point, ou alors un ou deux points d’intersection de cercles qui permettent de distinguer deux cas : 1) L’un des segments est complètement inclus dans l’autre, ou bien ils sont tangents intérieurement, alors ‖ܯ௧ܯ௠‖ ൑ |ܴ௧ െ ܴ௠|. En conséquence, la distance parallèle ݀ூூ൫ݐ௜, ݉௝൯ est nulle ; 2) Les segments se chevauchent partiellement (|ܴ௧ െ ܴ௠ ൏ ‖ܯ௧ܯ௠‖ ൏ ܴ௧ ൅ ܴ௠|), ou ils sont disjoints (|ܯ௧ܯ௠| ൐ ܴ௧ ൅ ܴ௠), ou bien encore ils sont tangents extérieurement (|ܯ௧ܯ௠| ൌ ܴ௧ ൅ ܴ௠). Alors la distance parallèle ݀ூூ൫ݐ௜, ݉௝൯ ൌ ݉݅݊ሺ݀ܫܫଵ, ݀ܫܫଶሻ (Figure 5.8c). Autrement dit, sa valeur correspondra au déplacement minimal nécessaire pour superposer soit les extrémités droites, soit les extrémités gauches de deux segments appariés. En résumé, la distance parallèle se calcule selon la formule ci-dessous : ௜ݐ௝݉ ݑ݋ ௝݉ ௜ݐ ݅ݏ ൯ൌ൜0௝݉ ,௜ݐூூ൫݀ ݐ݊݁݉݁ݎݐݑܽ ଶሻܫܫ݀ ,ଵܫܫ݀ሺ݊݅݉ (5.12) Finalement, la distance perpendiculaire ݀⟘൫ݐ௜, ݉௝൯ est tout simplement la distance minimale entre deux droites parallèles ܦ௧ et ܦ௠. Soit la droite ܦ௧ passant par ܯ௧ et de direction de vecteur ܸ௧ ሬሬሬԦ, et la droite ܦ௠ passant par ܯ௠ et de direction ܸ௠ሬሬሬሬԦ. La distance est alors égale à : ݀⟘൫ݐ௜, ݉௝൯ ൌ ݇ ฮܸ௧ ሬሬሬԦ˄ܸ௠ሬሬሬሬԦฮ (5.13) où ݇ est le produit mixte de trois vecteurs ൣ ܯ௧ܯ௠ ሬሬሬሬሬሬሬሬሬሬሬሬԦ, ܸ௧ ሬሬሬԦ, ܸ௠ሬሬሬሬԦ൧ (déterminant de la matrice formée par les trois vecteurs). 5.2.3 Mise en correspondance Dès que la matrice de similarité est créée (Figure 5.9a), nous procédons à l’analyse de celle-ci pour fixer un seuil ߜ, nécessaire dans le processus de rejet des paires erronées et de mise en correspondance des segments. Bien entendu, les correspondances recherchées ne seront quasiment jamais de 1 à 1, mais plutôt de 1 à plusieurs, de plusieurs à 1, voire de 1 à nul. Afin d’établir la valeur appropriée du seuil, nous commençons par un appariement préliminaire de segments ܵ. Cette étape nous amène à apparier, à chaque droite de l’ensemble T, un homologue le plus semblable de ܯ, c’est-à-dire, le segment le plus proche au sens de la distance ݀ሺݐ, ݉ሻ. La tâche est aisée à remplir, puisque l’on peut toujours relier deux segments entre eux, même si leur score est significatif et même si la paire formée de cette manière n’existe pas en réalité (Figure 5.9b). CHAPITRE 5. Qualification à partir d’entités linéaires 97 Figure 5.9 Estimation des correspondances : a) Matrice de similarité ; b) Appariement préliminaire ܵ (carrés blancs) Se fondant sur cet appariement grossier ܵ, la recherche d’un seuil optimal se limite à l’analyse des différences entre les distances associées aux paires sélectionnées. Figure 5.10 Recherche du seuil ߜ La soustraction membre à membre des valeurs ݀ሺݐ, ݉ሻ d’une telle suite ܵ est exécutée deux fois. Nous partons d’abord des distances classées selon un ordre ascendant ce qui amène à créer une nouvelle liste des valeurs Diff1 - première dérivée (courbe verte sur la Figure 5.10). L’opération est effectuée encore une fois, mais cette fois-ci, pour les termes du suite Diff1. Comme résultat, nous obtenons une courbe violette (Figure 5.10). Le premier pic (parmi les 98 valeurs Diff2 – deuxième dérivée) ayant la hauteur supérieure à la sensibilité admise (U=0.5m) et détecté à l’aide d’une fonction localisant des maxima locaux, désigne l’indice du couple de segments dont le score sera admis comme le seuil de couplage ߜ. Cette procédure étant conçue pour les échantillons importants (nombre de paires ܰ supérieur à 10), nous envisageons aussi une solution pour les cas ne remplissant pas cette condition. L’équation (5.14) résume la façon de calculer le seuil ߜ, quel que soit le nombre de paires traitées. ߜൌቐ ݉ܽݔሺܵሻ ܥܽݎ݀ሺܦ݂݂݅ଵ ൏ ܷሻ ൌܰെ1 ᇱ݊ ݈ܽܿ݋݈ ݉ݑ݉݅ݔܽ݉ ݈݁ ݅ݏ ߪé݀݅ܽ݊݁ሺܵሻ ൅ 2݉ 10 ൑ ܰ ˄ ݏܽ݌ ݁ݐݏ݅ݔ݁ ݐ݊݁݉݁ݎݐݑܽ ܷ ൒ ଶሻ݂݂݅ܦሺ݈ܽܿ݋݈ ݉ݑ݉݅ݔܽ݉ ݎ݁݅݉݁ݎ݌ ݈݁ (5.14) Dans le cas des échantillons petits, mais aussi ceux pour lesquels aucun maximum local n’existe, deux résolutions du problème sont envisagées : 1) Toutes les paires de l’appariement préliminaire ܵ sont correctes et donc les différences successives Diff1 sont négligeables (inférieures à ܷ). Le seuil ߜ sera la valeur maximale parmi toutes les distances ݀ሺݐ, ݉ሻ ordonnées par la suite ܵ ; 2) L’existence de paires aberrantes au sein de l’ensemble ܵ est constatée et le seuil ߜ est fixé comme la médiane de celui-ci, agrandie ensuite par une tolérance de 2ߪ. Ainsi, toutes les valeurs inférieures ou égales à la médiane sont mises de côté, pour participer au calcul du σ représentant l’écart –type de leur moyenne. Une fois le seuil retrouvé, la matrice de correspondance ݎ݋ܥ est générée comme suit : ݎ݋ܥ ൌ ൛ሺ݅,݆ሻ ∈ Յଶ: ∀൫ݐ௜ ∈ ܶ, ݉௝ ∈ ܯ൯, ݀൫ݐ௜, ݉௝൯ ൑ ߜൟ (5.15) Figure 5.11 Matrice de correspondance : a) ܶ݁ݐݏ → ݋ܯ݈݀݁ ; b) ݋ܯ݈݀݁ → ܶ݁ݐݏ En d’autres termes, le seuillage de la matrice de similarité fournit un appariement définitif. Il convient de rappeler que la procédure décrite ci-dessus est menée dans deux sens, surtout pour des raisons de contrôle, mais aussi pour remplir les conditions imposées par la CHAPITRE 5. Qualification à partir d’entités linéaires 99 définition de la métrique de Hausdorff. En effet, deux matrices de correspondance sont indépendamment déterminées, en supposant pour la seconde fois que l’ensemble ܶ݁ݐݏ est la référence (Figure 5.11). Dès lors, les distances directes ܱܦܪܮሺܶ, ܯሻ et ܱܦܪܮሺܯ, ܶሻ peuvent être calculées entre les segments grâce à la formule (5.9). Quant à la distance indirecte (LHD), elle est obtenue à l’aide de l’équation (5.5). 5.3 Résultats et évaluation Dans cette partie, nous validerons notre méthode de qualification des relevés laser mobile. Nous commencerons par vérifier l’algorithme de mise en correspondance des segments, puisqu’il influencera les résultats finaux (Paragraphe 5.3.2). Pour ce faire, les données réelles seront employées. Trois critères : l’exactitude, la sensibilité et la spécificité nous permettront de noter l’algorithme développé. L’appariement créé sera confronté avec la vérité-terrain. Ensuite nous compléterons les analyses effectuées par une étude de l’impact d’éloignement réciproque des nuages sur l’appariement des segments. En dernier lieu (Paragraphe 5.3.3), nous qualifierons les relevés laser, en termes d’exactitude absolue et de précision (répétabilité). 5.3.1 Données expérimentales Figure 5.12 Zone de test : a) Prise de vue de la zone avec les trajets de la plate-forme superposés ; b) Vue de dessus des relevés laser mobiles acquis La zone de test est située à Paris, à proximité du croisement des rues du Vieux-Colombier et Madame. Le choix de ce carrefour s’explique non seulement par la forte présence de façades orientées différemment (la multitude d’arêtes), mais aussi par sa diversité. Il contient des espaces « dégagés », ainsi que ceux considérés comme très problématiques du point de vue des acquisitions mobiles. La géométrie des rues (canyons urbains souvent à sens unique) et les bâtiments de hauteur importante rendent les conditions de réception du signal GNSS particulièrement difficile. Ceci nous a permis d’acquérir des données mobiles de qualité différente. Des relevés laser y ont été collectés par le système mobile Stéréopolis II d’IGN100 dans la configuration décrite dans la section 2.1.3. Quelques passages de la plate-forme ont été réalisés dans ce périmètre comme on peut l’observer dans la Figure 5.12. En revanche, pour les besoins de l’analyse, seulement trois nuages de points S1, S2 et S3 ont été employés. Figure 5.13 Segments extraits à partir des nuages mobiles (les couleurs de segments correspondent aux différents passages de la plate-forme - Figure 5.12 Les intersections entre les plans principaux (arêtes de pli) ont été retrouvées, constituant une base exhaustive à tester. Dans le cas des nuages mobiles, la géométrie de balayage (seulement le sol et le rez-de-chaussée de bâtiments constitué, en général, des devantures de magasins, ont été balayés) nous a obligés à extraire manuellement les arêtes (Figure 5.13). La détection précise de plans verticaux était impossible due au taux de bruit important. Quant à la référence, nous employons le nuage Sulpice2013_statique (voir la Figure 2.21 dans la Section 2.2) à partir duquel les arêtes (ܨ) ont été extraites avec l’algorithme proposé au sein du Chapitre 4 (Figure 4.27). 5.3.2 Évaluation de l’algorithme d’appariement Appariement des segments Au premier abord, la mise en correspondance réalisée à travers l’approche développée a été comparée avec la vérité-terrain. De ce fait, la capacité de l’algorithme à prédire si une paire existe a été mesurée. À chaque fois, une matrice de confusion a été créée afin d’observer le nombre de paires de segments : 1) correctement appariées VP (Vrais Positifs) ; 2) correctement rejetées VN (Vrais Négatifs) ; 3) mal identifiées FP (Faux Positifs) ; 4) omises FN (Faux Négatifs). La Figure 5.14 visualise un exemple de résultats de la mise en correspondance des segments réalisée entre le nuage mobile (S3) et celui statique (F). Sur cette base, trois critères servant à noter notre algorithme d’appariement, largement employés en statistique, ont été définis de la manière suivante : ݔܧܽܿݐ݅ݑݐ݀݁ ൌ ሺܸܲ ൅ ܸܰሻ/ሺ݌∙ݍሻ (5.16) ܵ݁݊ݏܾ݈݅݅݅ݐé ൌ ܸܲ/ሺܸܲ ൅ ܨܰሻ (5.17) ܵ݌é݂ܿ݅݅ܿ݅ݐé ൌ ܸܰ/ሺܸܰ ൅ ܨܲሻ (5.18) CHAPITRE 5. Qualification à partir d’entités linéaires 101 Figure 5.14 Comparaison avec la vérité-terrain : a) ܶ݁ݐݏ → ݋ܯ݈݀݁ ; b) ݋ܯ݈݀݁ → ܶ݁ݐݏ Le Tableau 5.1 résume les valeurs obtenues pour les données réelles, séparément pour chaque direction de calcul, et accompagnées par la distance ܱܦܪܮ. Il en ressort que l’appariement réalisé entre les segments est suffisamment exact (les valeurs de tous les trois critères définis sont élevées). Tableau 5.1 Validation de l’algorithme de mise en correspondance (T-ܶ݁ݐݏ, M-݋ܯ݈݀݁) Nombre de segments N Exactitude [%] Sensibilité [%] Spécificité [%] OLHD[m] Test (p) Model (q) T→M M→T T→M M→T T→M M→T T→M M→T S1-S2 36 28 11 99.8 99.8 100.0 91.7 99.9 99.8 0.518 0.472 S1-S3 36 41 29 99.5 99.5 93.1 93.1 99.7 99.7 0.302 0.297 S2-S3 28 41 12 99.7 99.7 91.7 91.7 99.8 99.8 0.481 0.560 S1-F 36 64 21 99.6 99.6 85.7 95.2 99.7 99.6 0.671 0.656 S2-F 28 64 22 99.3 98.9 90.9 90.9 99.4 99.0 1.104 1.257 S3-F 41 64 24 99.7 99.5 91.7 91.7 99.7 99.6 0.563 0.657 Moyenne 99.6 92.3 99.7 La probabilité que l’algorithme dissocie correctement les vraies paires parmi toutes les combinaisons possibles (exactitude) est élevée et oscille autour de 99.6%. En moyenne, 92.3% des paires (voir la sensibilité) ont été retrouvées, indépendamment de l’éloignement de deux ensembles de droites, ܶ݁ݐݏ et ݋ܯ݈݀݁. Quant à la probabilité de dénombrer les appariements erronés, elle peut être décrite comme faible. Puisque la spécificité atteint moyennement un niveau de 99.7%, le nombre de FP constitue 0.3% de tous les VN. Par contre, le taux de FP (détection d’une paire inexistante) paraît dépendre de la distance réciproque entre les segments de deux jeux traités. En réalité, cet impact sur l’écartement se traduit par une augmentation du nombre de droites couplées qui, dans le cas étudié, sont enrichies par 73% 102 de paires de plus pour une distance ܦܪܮ égale à 1.257m. D’un point de vue pratique, les segments très proches de l’ensemble ܶ݁ݐݏ seront appariés à un même élément de ݋ܯ݈݀݁, car leur distance est suffisamment petite. Notamment, comme le montre la Figure 5.15a (à gauche), un grand décalage horizontal ݀ܲ exerce une influence sur le seuil ߜ devenant plus grand. Les segments 17-18 et 15-16 seront ipso facto couplés avec les segments 47-48 et 5-6 respectivement, même si en réalité, leur homologue n’existe pas. Ceci est dû au fait que les distances ݀ሺݐ, ݉ሻ calculées sont inférieures au seuil fixé. Pour y remédier, nous pouvons imaginer deux solutions. La première consisterait à introduire une contrainte de couplage. Nous autorisons une correspondance unique entre deux segments. Néanmoins, le processus d’appariement nécessite que l’on affronte un phénomène de sur-segmentation. Les segments n’auront que très rarement une seule entité correspondante. Un autre défaut, une telle restriction dévoilera un accroissement du nombre de FN (non-détection d’une paire présente) et par conséquent, la probabilité d’identification correcte des paires existantes de segments (sensibilité) baissera. La seconde solution envisageable amènerait à rapprocher des segments avant de démarrer l’algorithme de mise en correspondance (voir le Chapitre 6). Figure 5.15 Exemple d’erreurs de mise en correspondance : a) FP ; b) FN La Figure 5.15b illustre un autre problème noté lors du couplage d’entités linéaires. Le segment 51-52 n’a pas pu être apparié avec le segment 29-30, du fait de la distance parallèle ݀ூூ supérieure au seuil ߜ. Nous avons aussi observé que, dans certains cas particulier, le poids ܹ introduit (voir la formule (5.10)) pour mettre en évidence l’orientation incompatible des droites peut être parfois insuffisant. Comme le présente la Figure 5.15a (à droite), le segment 33-34 a été apparié avec le segment 25-26 à cause de la distance ݀ୄ très petite et de celle ݀ூூ étant nulle, par-devers les orientations différentes. Impact de l’écartement entre les ensembles Test et Model Après avoir effectué ces analyses, nous voyons que la mise en correspondance semble dépendre du décalage réciproque des segments. Plus les ensembles à comparer sont proches l’un de l’autre, plus le résultat sera précis. CHAPITRE 5. Qualification à partir d’entités linéaires 103 Figure 5.16 Exemple des résultats obtenus à partir de S1 et F (une seule direction de calcul) en fonction de la distance LHD : a) Distance faible ; b) Distance importante 104 Dans un premier temps, nous avons vérifié cette propriété à l’aide de données réelles S1 et F (originales, ensuite décalées). Deux cas sont illustrés : a) la distance réciproque ܦܪܮ entre les ensembles est égale à 0.803m (Figure 5.16a) ; b) la distance est de 8.734m (Figure 5.16b). Nous observons, à cause de l’écartement notable, que les scores ݀ሺݐ, ݉ሻ attribués aux paires présentes sont à peu près de la même grandeur que ceux caractérisant les paires erronées. Dès lors, il est impossible d’entreprendre correctement une classification. Le seuil fixé est suffisamment important pour que les paires présentes soient détectées, par contre, il laisse également incorporer des paires erronées (FP). Figure 5.17 Problèmes d’appariement dus à l’écartement de segments Test (bleu) et Model (rouge) : a) Segments proches ; b) Segments Test déplacés T=[0.0m, 5.5m] ; c) Segments Test déplacés T=[5.5m 0.0m] ; d) Segments Test déplacés T=[5.5m, 5.5m] Tableau 5.2 Matrices de similarité créées à partir des segments illustrés par la Figure 5.17 (sens de calcul ܶ݁ݐݏ → ݋ܯ݈݀݁) a) δ=0.33m b) δ=3,72m 0.28* 10.37 14.98 8.95 15.53 10 5.78 10.28 12.05 3.46* 10.05 13.50 0.32* 8.96 13.39 15.30 11 15.88 3.19* 4.32 12.16 11.42 9.53 8.82 10.09 0.32* 6.47 12 15.03 9.25 10.08 5.82 1.86* 17.89 4.10 0.32* 12.72 9.98 13 21.98 9.04 4.34 14.96 9.45 1 2 3 4 5 1 2 3 4 5 4.91* 12.60 17.55 9.97 16.82 10 7.58 12.53 15.13 5.60* 11.94 13.72 5.82 12.09 13.47 15.63 11 16.07 5.82* 9.20 12.25 11.87 10.91 11.68 13.88 4.83* 9.53 12 15.94 12.01 13.87 7.56 7.24 17.76 4.28* 5.82 12.46 9.98 13 21.88 9.13 7.26 14.74 9.45 c) δ=5.12m d) δ=7.09m CHAPITRE 5. Qualification à partir d’entités linéaires 105 L’origine de ce problème réside dans la matrice de similarité elle-même dont l’analyse, en présence du décalage significatif, ne permet plus de restituer de vraies relations entre les segments. Par l’intermédiaire du Tableau 5.2 (matrices de similarité) associé à la Figure 5.17, nous fournissons un exemple justifiant nos conclusions. Pour simplifier notre expérience, nous n’envisageons alors que le cas 2D. Le déploiement des segments sur la Figure 5.17a permet, sans aucun doute, de constater (visuellement) que les entités linéaires doivent être appariées de la manière suivante : 10-1, 11-2, 12-4, 13-3, nul-5. Aussi, les scores ݀ሺݐ, ݉ሻ attribués à ces paires par notre algorithme sont moindres et le seuil δ=0.33m dissocie les paires de la même manière. Nonobstant, cette certitude disparaît quand les segments sont de plus en plus éloignés (Figure 5.17b,c,d). Nous les relions désormais d’une autre façon en tenant compte de la contrainte de choisir les paires ayant la distance réciproque la plus petite, et les directions conformes. Les carrés gris du Tableau 5.2 représentent l’appariement préliminaire ܵ, sur lequel notre algorithme d’appariement va s’appuyer afin de calculer le seuil ߜ. Les paires retenues après le seuillage sont marquées par un astérisque (*). Par conséquent, le résultat de mise en correspondance effectuée par notre algorithme est suivant : 1) Figure 5.17a :VP=4, VN=16, FP=0, FN=0 ; 2) Figure 5.17b :VP=1, VN=14, FP=2, FN=3 ; 3) Figure 5.17c : VP=2, VN=15, FP=1, FN=2 ; 4) Figure 5.17d : VP=1, VN=14, FP=1, FN=3 ; Au vu de ces résultats, nous constatons que l’algorithme fournit l’appariement adéquat à l’emplacement actuel des segments. En souhaitant trouver des segments homologues parmi deux ensembles éloignés, il faut se rendre compte que cette tâche peut être irréalisable. Néanmoins, pour nos applications, c’est-à-dire l’appariement des segments lors de leur qualification, cette remarque n’est pas trop pertinente. Premièrement, les nuages de points ainsi que les données de référence sont géopositionnés dans un référentiel commun. En second lieu, l’exactitude des systèmes mobiles récents est loin d’être métrique. C’est pourquoi la contrainte de distance réciproque faible entre deux ensembles d’arêtes sera toujours satisfaite. La mise en correspondance peut ainsi être précisément effectuée. Sinon, faute de précision requise, il sera nécessaire de rapprocher des données avant d’exécuter l’algorithme de couplage. 5.3.3 Exactitude et précision Passons à présent à la qualification des relevés laser mobiles à l’aide des arêtes extraites. Nous employons deux critères : 1) l’exactitude absolue calculée par rapport à la référence précise (données statiques) ; 2) la précision consistant à comparer plusieurs passages de la plate-forme mobile (S1- S2, S1-S3, S2-S3). Le Tableau 5.1 récapitule les distances relatives de Hausdorff (ܱܦܪܮ) déterminées pour les deux sens de calcul : en comparant d’abord les entités linéaires ܶ݁ݐݏ (S1, S2, S3) entre elles – mêmes, et ensuite avec celles de référence (F). À chaque fois, la valeur maximale ܦܪܮ décrit, selon le cas, soit l’exactitude, soit la précision des données étudiées. Les tests effectués montrent que, dans les zones urbaines, la précision du système mobile examiné est de 0.30m. Cependant, une précision plus faible a été constatée lors de comparaison avec le passage S2. Or, ce nuage a été très probablement affecté par une mauvaise qualité des mesures GNSS. Cette hypothèse a pu être vérifiée par l’exactitude dont la valeur était égale à 1.257 m. En revanche, dans les autres cas, l’exactitude absolue est d’environ 0.70m. Le Tableau 5.3 récapitule les valeurs de distance indirecte de Hausdorff ሺܦܪܮሻ retenues et décrivant la qualité des données traitées. Aussi, le temps d’exécution CPU sous Matlab est renseigné. 106 Même si l’algorithme exige d’être encore optimisé, le temps de calcul est de l’ordre de quelques secondes. Tableau 5.3 Mesure de qualité :distance de Hausdorff retenue Nombre de segments N LHD[m] CPU* [s] Test (p) Model (q) S1-S2 36 28 11 0.518 1.39 S1-S3 36 41 29 0.302 1.99 S2-S3 28 41 12 0.560 1.54 S1-F 36 64 21 0.671 3.11 S2-F 28 64 22 1.257 2.36 S3-F 41 64 24 0.657 3.51 * Intel Core x2 T7600 2.33Ghz / 4Go Ram / Win7 64bits Il convient aussi de souligner, que la distance moyenne évaluant la qualité des nuages à partir des segments non seulement représente l’exactitude, mais aussi l’erreur survenue lors de la procédure d’extraction d’arêtes. Cette dernière est propre à l’algorithme employé. Quant à la distance de Hausdorff ܦܪܮ, ses autres propriétés seront encore abordées au Chapitre suivant. Notre algorithme de qualification est décrit par le pseudo-code 5.1(Annexe E). Son but est de fournir une mesure de qualité ܦܪܮ, ainsi qu’une matrice binaire de correspondance ݎ݋ܥ entre deux ensembles de segments. Nous obtenons également deux distances relatives de Hausdorff : ܱܦܪܮ்ெ et ܱܦܪܮெ், une pour chaque direction de calcul. Nous nous en servons pour contrôler la justesse de l’algorithme d’appariement. Si leurs valeurs diffèrent significativement, il en résulte que la mise en correspondance n’est pas correcte. Il est donc recommandé de changer, dans un premier temps, la sensibilité ܷ de la fonction de recherche des maxima locaux (par défaut ܷ ൌ 0.5) puisqu’elle décide du seuil ߜ. L’algorithme attend en entrée que l’on saisisse une liste de coordonnées des extrémités de segments ்ܺ௘௦௧ et ܺெ௢ௗ௘௟ dans le format ሾܰݎ, ܺ, ܻ, ܼሿ. 107 CHAPITRE 6 Recalage à partir d’entités linéaires Sommaire : 6. Recalage à partir d’entités linéaires ............................................................................. 107 6.1 Introduction ............................................................................................................................ 108 6.2 État de l’art du recalage rigide ........................................................................................... 109 6.2.1 Mise en correspondance automatique ....................................................................................... 109 6.2.2 Classification des méthodes existantes de recalage ................................................................ 111 6.2.3 Aperçu des méthodes basées sur les entités linéaires ............................................................ 113 6.3 Recalage basé-lignes : caractérisation des méthodes ..................................................... 115 6.4 Évaluation des méthodes présentées ................................................................................. 116 6.4.1 Données pour les expérimentations .......................................................................................... 117 6.4.2 Algorithmes implémentés ............................................................................................................ 118 6.4.3 Outils d’évaluation ........................................................................................................................ 118 6.4.4 Résultats – recalage des données bruitées ............................................................................... 119 6.4.5 Impact du bruit sur la distance de Hausdorff ........................................................................... 122 6.5 Approche proposée : RLMR-FMII2 ................................................................................... 124 6.5.1 Recalage grossier – principe ....................................................................................................... 126 6.5.2 Évaluation avec données simulées ............................................................................................. 127 6.5.3 Tests sur données réelles ............................................................................................................. 130 6. Recalage à partir d’entités linéaires Dans ce chapitre un état de l’art de techniques de recalage rigide basé sur les entités linéaires est effectué. Trois méthodes d’estimation sont choisies et examinées avec des données simulées, afin de vérifier leur robustesse et leur précision vis-à-vis notre problématique. Au vu des analyses effectuées, l’une des méthodes existantes est adaptée à nos besoins, puis renforcée d’un algorithme permettant parallèlement la mise en correspondance. Sachant que notre technique d’appariement impose une contrainte – la distance réciproque des segments doit être assez faible, nous procédons d’abord à rapprocher des arêtes pour faciliter et améliorer leur couplage ultérieur. Nous proposons une chaîne complète nommée ܴܯܮܴ െ ܫܫܯܨଶ comprenant le recalage grossier (utilisation complémentaire de l’algorithme de RANSAC et celui de ܫܫܯܨଶ) et un recalage fin (raffinement des segments approchés par le ܫܫܯܨଶ). Finalement, la performance d’une telle procédure est évaluée avec des données simulées et réelles. Résumé 108 6.1 Introduction La consolidation des nuages de points a pour but d’assembler des données devant servir à la reconstruction tridimensionnelle d’environnements et de base à des études géométriques. L’existence de zones d’ombre dues à la complexité des formes numérisées ainsi qu’aux artefacts (voitures, piétons ou autres obstacles) présents sur la zone durant l’acquisition se manifeste par un accroissement du nombre de stations du scanner laser fixe – les poses [Landes et al., 2011]. Lorsqu’il s’agit d’un robot mobile se mouvant, les nuages de points consécutifs contiennent toujours une même partie de l’environnement, mais avec des points de vue différents. Ces données doivent être mises en cohérence pour en déduire le déplacement relatif. Aussi, pour les zones d’intérêts numérisées deux ou plusieurs fois, au fil du temps, la question de la consolidation se pose. D’autre part, pour des plates-formes aériennes ou terrestres se localisant grâce à des systèmes hybrides IMU/GNSS, nous observons un biais entre les nuages de points distincts. Alors, dans le cas de la cartographie terrestre des zones de taille allongée (cartographie des corridors) les pertes du signal GNSS apparaissent sous la forme d’un décalage de la trajectoire estimée. Enfin, tous les relevés acquis par scanner laser aérien ALS sont encombrés par des écarts planimétriques et altimétriques causés, cette fois-ci, par la dérive de la centrale. Quel que soit le moyen de collecter les données, tous les relevés laser doivent être affinés dans un système de référence commun, autrement dit consolidés (recalés). La solution au problème de calage se réduit à déterminer une bonne transformation géométrique (rigide ou non rigide), applicable aux données. Le référentiel commun est arbitrairement choisi parmi l’un des nuages de points. Par essence, le recalage rallie trois problématiques : 1) la reconstruction des primitives facilement identifiables dans la scène balayée ; 2) la mise en correspondance et la planification de la stratégie des manipulations sur des entités couplées ; 3) la résolution du système de contraintes amenant à estimer les paramètres optimaux de passage d’un repère à un autre – généralement un vecteur de translation ܶ ൌ ൣܶ௫, ܶ௬, ܶ௭൧ et une matrice de rotation ܴଷ௫ଷ. Nous nous concentrons, dans le cadre de notre travail, sur le recalage rigide de relevés laser issus du système mobile de cartographie. Deux tâches principales sont à réaliser. D’une part, l’intégration « multidonnées » visera, à améliorer le géo-référencement absolu, ainsi qu’à incorporer d’autres types de données, externes au système d’acquisition, mais fournissant souvent des informations complémentaires. Cependant, le principe du co-recalage de relevés sera de rechercher à assembler, de manière relative, ces différents nuages acquis lors de plusieurs passages. Son inconvénient principal réside dans le fait qu’aucune information extérieure ne corrige le cumul des erreurs, si bien que l’exactitude du calcul final ne peut pas être calculée. Rappelons que les entités géométriques choisies sont des segments de droite (arêtes de pli), car les nuages de points bruts (sans traitement), avec lesquels nous travaillons, peuvent empêcher la reconnaissance précise des points de contrôle, même sous forme de cibles placées volontairement dans la scène. Dans ce chapitre, on s’attardera, dans un premier temps (Section 6.2), sur un état de l’art des techniques de recalage et d’appariement des entités linéaires. Puis (Section 6.3), trois approches d’estimation des paramètres de pose à partir des lignes 3D seront présentées en détail notamment : EIGEN [Zhang et Faugeras, 1991], ICL (forme ICP) [Alshawa, 2006] et FMII [Kamgar-Parsi et Kamgar-Parsi, 2004]. Ces algorithmes ont été implémentés et examinés avec des données simulées afin de vérifier leur robustesse, la résistance au bruit et l’exactitude des résultats obtenus vis-à-vis de notre problématique (Section 6.4). C’est sur cette base qu’une chaîne complète, nommée ܴܯܮܴ െ ܫܫܯܨଶ (Robust Line Matching and Registration – FMIIଶ) permettant un recalage qui s’appuie sur l’appariement des primitives linéaires, a été proposé (Section 6.5). La mise en correspondance s’effectue à l’aide de l’algorithme présenté dans le Chapitre 5. Néanmoins, cette méthode requiert que les deux CHAPITRE 6. Recalage à partir d’entités linéaires 109 ensembles de segments à apparier soient relativement proches l’un de l’autre. Sinon, l’appariement n’est qu’approximatif. Nous proposons, par conséquent, de rapprocher d’abord les entités linéaires dans l’intention d’améliorer et de faciliter leur couplage ultérieur. Cette étape étant réalisée par une approche couplant RANSAC et ܫܫܯܨଶ amène à trouver un échantillon optimal à partir duquel les paramètres de recalage grossier seront calculés (Paragraphe 6.5.1). Ensuite, la mise en correspondance explicite des segments sert à un recalage fin, possible grâce à l’algorithme ܫܫܯܨଶ étant la version modifiée de ܫܫܯܨ. Nous présenterons, à la fin du chapitre, l’analyse qualitative et quantitative des résultats obtenus avec une telle procédure. 6.2 État de l’art du recalage rigide Dans cette partie, le premier paragraphe (6.2.1) fera un bref état de l’art de divers algorithmes d’appariements des entités linéaires. Puis, nous passerons à présenter une classification des méthodes de recalage (6.2.2), pour finalement décrire quelques techniques de minimisation des contraintes à partir des lignes, visant à déterminer les paramètres de transformation rigide (6.2.3). 6.2.1 Mise en correspondance automatique La raison principale pour laquelle le recalage est difficile vient du fait que les appariements, c’est-à-dire les vraies associations entre les primitives extraites, sont inconnus. La mise en correspondance de plusieurs éléments, reconstruits depuis des nuages de points distincts, est une tâche cruciale puisqu’elle établit un système de contraintes à minimiser lors de l’estimation des paramètres de pose (Figure 6.1). La convergence de l’algorithme de recalage dépendra alors directement de ces associations. En d’autres termes, l’exactitude des appariements créés, se manifestant par un nombre de paires erronées ou manquées, influencera la qualité des paramètres déterminés. Figure 6.1 Exemple de mise en correspondance entre deux nuages de points à partir de descripteurs [Latulippe, 2013] Considérant une technique itérative avec une présence de mauvais appariements, dans le meilleur des cas, on ralentit sa convergence, et dans le pire de cas, on cause sa divergence. Par conséquent, avec un algorithme comme ICP (Iterative Closest Point) (expliqué en 6.2.2), on n’est jamais certain d’arriver à une solution optimale, car ces associations sont seulement approximatives. Ainsi, lorsque l’écartement entre deux nuages est grand au départ, cet algorithme reste facilement bloqué dans un minimum local. Pour remédier à ce problème, l’une des idées serait de développer des méthodes permettant d’estimer des correspondances avant de réaliser le recalage global. Ce résultat peut être atteint, comme expliqué par [Latulippe, 2013], à l’aide d’un descripteur, à savoir un ensemble de valeurs caractéristiques, attribué à un point et décrivant la géométrie locale autour de lui. Il existe de nombreuses approches qui incorporent une étape d’extraction de points d’intérêt, auxquels sont ensuite 110 attribuées les valeurs de description. Ces dernières sont calculées à partir des coordonnées (X,Y,Z) de ce point et de ses voisins. Nous pouvons citer, par ordre chronologique, quelques types de descripteurs, applicables aux nuages de points par exemple : la variation de la courbure ; les moments invariants ; les spin images ; les points fingerprints ; les shape contexts 3D ; le SIFT (Scale-Invariant Feature Transform) ; les PFH (Point Feature Histograms) ; les FPFH (Fast Point Feature Histograms) ; les SHOT (Signature of Histograms and Orientations), etc. [Tangelder et Veltkamp, 2008] et [Latulippe, 2013]. Mise en correspondance des segments de ligne Nous nous intéressons à réaliser le recalage par l’intermédiaire des entités linéaires 3D appariées au préalable. Néanmoins, les travaux traitant de ce problème n’exposent presque jamais la question de la mise correspondance, en supposant que celle-ci soit déjà établie. Pour satisfaire ces besoins, un nombre de techniques d’appariement a été développé. La plupart des revues liées à ce sujet dévoilent que les algorithmes utilisés se heurtent aux difficultés suivantes : la sur-segmentation des segments et le bruit. Nous détaillerons dans cette section quelques méthodes récentes d’estimation de correspondances. Une étude montre que la distance Euclidienne « classique » peut toutefois ne pas être suffisante pour créer un appariement relativement correct [Douadi, 2006]. Par conséquent, [Wang et al., 2012] suggèrent de prendre en compte d’autres attributs de segments tels que la longueur, la direction, la position ou le taux de chevauchement. [Yao et al., 2010] proposent un algorithme bénéficiant de rigidité des droites pendant la transformation, ce qui veut dire que les écartements et les angles entre les entités restent toujours les mêmes. Pour chaque paire de segments de l’ensemble ܣ, des paires homologues sont recherchées dans l’ensemble ܤ qui satisfont à deux conditions : les valeurs absolues de différence de distances et celles d’angles sont inférieures à des seuils fixés. Afin de réduire le temps de recherche, seulement les ݇ meilleures paires de ܤ sont retenues. De la même manière, [Li et al., 2012] appliquent la même hypothèse afin d’établir de vraies associations entre les segments 3D. La solution proposée consiste à attribuer, à toutes les entités linéaires de l’ensemble, deux vecteurs, chacun comprenant quatre composantes décrivant leur relation angulaire et l’éloignement vis-à-vis des autres éléments de l’ensemble. Il s’agit de former le vecteur contenant : le maximum, le minimum, la moyenne et l’écarttype de mesures calculées. Ensuite, on détermine la distance entre i-ème vecteur de l’ensemble ܣ et tous les vecteurs de ܤ. Les segments sont appariés à condition que les deux normes (concernant l’angle et la distance) soient minimales. [Jaw et Chuang, 2008] développent une approche s’exécutant en deux étapes. Dans un premier temps, les angles spatiaux (ߠ௜௝, ߠ௜௞ …) entre un segment et ses voisins successifs dans chaque ensemble sont déterminés en utilisant, à cet effet, les extrémités (Figure 6.2a et Figure 6.2b). Deux segments de droites sont appariés, si et seulement si, la différence angulaire ne dépasse pas un certain seuil. Ces associations préalables permettent ensuite d’estimer les paramètres de transformation censés rapprocher les nuages de points (Figure 6.2c). La dernière phase nous amène à calculer la distance spatiale ܦ équivalente à la moyenne des distances (ܦଵ et Dଶ) servant à retrouver des lignes homologues (Figure 6.2d). CHAPITRE 6. Recalage à partir d’entités linéaires 111 Figure 6.2 Estimation de correspondances selon [Jaw et Chuang., 2008] : a) b) Calcul des angles spatiaux pour l’ensemble ܣ et ܤ respectivement ; c) Deux ensembles d’entités après la transformation ; d) Définition de distance spatiale Un regard tout à fait différent est énoncé avec des approches cherchant à apparier des points au lieu des lignes. L’une des possibilités est de discrétiser chaque droite en un certain nombre de points et de s’en servir pendant le couplage réalisé souvent à l’aide d’ICP. Ainsi [Belton et al., 2011] proposent d’extraire des vertex représentant des intersections entre les lignes 2D. La technique mise en œuvre consiste à étudier, au sein de chaque ensemble, les distances Euclidiennes entre toutes les combinaisons possibles de points. Pour ce faire, une méthode de vote est employée dont l’objectif est de trouver, sous une certaine tolérance, des distances semblables. Pendant ce processus une matrice de correspondance est créée, de telle manière que ses coefficients décrivent la probabilité que le point ݌௜ de l’ensemble ܣ appartienne au point ݌௝ de l’ensemble ܤ. De surcroît [Huh et al., 2013] cherchent à apparier des polygones. Cette problématique est similaire à la nôtre puisqu’un polygone est considéré comme la réunion de segments appelés côtés. D’abord, les calculs des régions de confiance des segments sont effectués à partir des erreurs de position de leurs extrémités. Puis, des sommets ainsi que des « vertex virtuels » étant l’intersection des droites dérivées depuis les segments, sont extraits. Enfin, un algorithme de recherche de sous-chaîne (string matching algorithm) est employé afin d’estimer des paires de points correspondants. 6.2.2 Classification des méthodes existantes de recalage Il existe plusieurs techniques de calage de données laser. Nous pouvons l’effectuer par consolidation (best fit/ICP) en nous appuyant sur la géométrie des objets numérisés, par un relèvement sur les cibles disposées (Figure 6.3) ou bien encore sur les « cibles naturelles » en les assimilant à des primitives géométriques (sphères, plans, cylindres, cônes, etc.) fortement présentes dans les environnements bâtis et industriels aménagés par l’homme. Quant aux cibles/primitives, elles peuvent servir également pour dissocier des entités géométriques (le centre, l’axe principal, le sommet, l’intersection, etc.), ainsi que des invariants géométriques tels que le rayon [Hullo, 2013]. 112 Figure 6.3 Différents types de cibles propres pour les constructeurs du scanner La classification des méthodes de recalage proposée par [Gressin et al., 2013] peut être une bonne démarche introductive pour les algorithmes existants. En effet, trois familles d’approches sont considérées : 1) les méthodes basées sur la mise en correspondance de primitives géométriques remarquables dans deux nuages et invariants lors d’un mouvement rigide ; 2) les approches employant le modèle de surface (ordinairement un maillage) au lieu des nuages de points 3D ; 3) les techniques focalisées sur les points et donc ne nécessitant ni l’extraction préalable de primitives ni la phase de modélisation (p.ex. ICP, RANSAC). Néanmoins, cette classification n’est pas unique. [Alshawa, 2006] suggère de classer des algorithmes de la manière suivante : 1) les méthodes basées sur les entités géométriques, dont la connaissance préalable et précise, est primordiale ; et 2) celles indépendantes des entités d’intérêt. Parmi ces dernières deux sous-groupes sont distingués : 1) les techniques de vote ; 2) les méthodes de correspondance sous-jacente telles que la méthode ICP et la méthode DARCES (Data-Aligned Rigidity-Constrained Exhaustive Search) [Chen et al., 1999] basée sur RANSAC. Il faut souligner que les algorithmes dépendants des primitives nécessitent un temps considérable pour les extraire et que leur handicap se dévoile lors du manque de détails caractéristiques. En revanche, ils n’exigent quasiment pas de valeurs initiales pour se réinitialiser en permettant de réduire le nombre de combinaisons possibles d’appariement. Quant aux calculs des inconnus de pose, ils sont effectués en assimilant des méthodes indépendantes des entités géométriques, mais à une différence près, après avoir extrait des primitives. C’est pourquoi certaines personnes considèrent ces méthodes comme un cas particulier de ces dernières. L’Iterative Closest Point (ICP), proposé concurremment par [Besl et McKay, 1992] et [Chen et Medioni, 1992] est un algorithme itératif le plus souvent utilisé. Il est utilisé soit pour recaler deux vues partielles d’un même objet, soit pour corriger des relevés laser mobiles [Ridene, 2010]. L’idée est d’itérer deux étapes : celle de la mise en correspondance et celle de l’estimation des paramètres afin d’établir la meilleure transformation recalant des scans dont le recouvrement s’avère assez important. Au bout de chaque itération, une liste d’éléments appariés est de nouveau fournie, servant à son tour à déterminer une nouvelle estimation des paramètres de pose. Ces derniers seront utilisés par la suite, pour la mise à jour de la position des données. Toutes ces étapes seront répétées jusqu’à l’obtention de la convergence de l’algorithme. Celle-ci est atteinte lorsque l’erreur résiduelle ne dépasse pas un certain seuil, ou bien que le nombre maximum d’itérations allouées à l’algorithme est atteint. Cependant, l’ICP « classique » présente des limitations qui font, jusqu’à présent, l’objet de nombreuses études. C’est pourquoi plusieurs améliorations y ont déjà été apportées. Elles visent à intervenir à chaque étape de cet algorithme [Rusinkiewicz et Levoy, 2001], [Douadi, 2007], [Gressin, 2013]. Cela concerne la façon de choisir des entités à apparier [Masuda et Yokoya, 1995], [Gelfand et al., 2003], la stratégie d’appariement employée [Pulli,1999], [AlDurgham et al., 2011], la pondération des paires appariées [Gressin et al., 2012], le rejet de mauvais appariements [Zhang, 1994] et enfin le type de critère à minimiser et/ou l’algorithme de minimisation. L’objectif est toujours de minimiser un score, une distance ou une erreur entre les parties communes. Le critère le plus simple à utiliser est la somme des erreurs de distance quadratiques entre les points appariés (ICP Point à Point). Mais, les CHAPITRE 6. Recalage à partir d’entités linéaires 113 méthodes fondées sur la somme des carrés des distances entre les points d’un scan et le plan de l’autre sont aussi couramment employées (ICP Point à Plan). L’estimation de la transformation rigide s’effectue à l’aide de plusieurs approches telles que la technique SVD (décomposition en valeurs singulières) [Arun et al., 1987], l’utilisation des quaternions unitaires [Besl et McKay, 1992] ou l’algorithme d’optimisation non linéaire de LevenbergMarquardt [Fitzgibbon, 2001]. L’inconvénient majeur de l’ICP dans sa forme originale vient du fait qu’il peut converger vers un faux minimum lorsque les données sont très bruitées et qu’il a besoin d’un nombre important d’itérations. Pour atteindre le minimum global et accélérer la convergence, une initialisation préalable fournissant de bonnes valeurs initiales est requise. En dépit de toutes les études, une intervention de l’opérateur est souvent obligatoire puisque cette opération n’est généralement pas résolue automatiquement. 6.2.3 Aperçu des méthodes basées sur les entités linéaires L’utilisation des entités linéaires au lieu des points, pour les besoins de consolidation, constitue d’un point de vue algorithmique un défi plus important. Par contre, il a été démontré que seules deux paires de droites non colinéaires permettent de dériver la solution [Alshawa, 2006], [Yao et al., 2010]. Toutefois, compte tenu des bruits qui entachent les données, il est conseillé d’employer un nombre de paires ܰ supérieur à deux et de résoudre un système surdéterminé de ܰ équations afin de trouver la meilleure estimation. Les méthodes de recalage conçues pour les entités linéaires ne sont pas nombreuses, nous en citerons quelques – unes. Dans ces travaux [Zhang et Faugeras, 1991] analysent plusieurs algorithmes de minimisation, y compris le Filtre de Kalman Étendu (EKF), la minimisation par la méthode de moindres carrés et la décomposition en valeurs singulières, pour étudier le déplacement à partir des segments 3D. Cette problématique étant similaire à la nôtre, elle permet d’estimer les paramètres optimaux d’une transformation rigide. Différents scénarios ont été vérifiés, en supposant que l’appariement des entités est connu, afin de juger la façon optimale de représenter la matrice de rotation et de calculer des estimées. Finalement, la représentation par un axe et un angle (axis-angle representation) avec l’utilisation simultanée du Filtre de Kalman est la solution la plus précise. En revanche, lorsque l’on considère exclusivement le temps de calcul, c’est l’approche EIGEN basée sur la rotation exprimée par des quaternions et estimée par la SVD qui paraît la plus prometteuse. Dans le même contexte [Alshawa, 2006] propose deux variantes de méthode ICL (Iterative Closest Line) servant à déterminer des paramètres de transformation rigide à partir de droites : 1) ICL (forme ICP) ; 2) ICL forme alternative. La première est identique à l’algorithme ICP de base si l’on envisage uniquement la rotation. Mais, elle présente un aspect différent sur la façon de calculer le vecteur de translation, comme nous pourrons l’observer ultérieurement. La seconde solution inspirée de [Habib et al., 2004] est une approche itérative et non de solution analytique (closed-form). Son principe consiste à procéder à une consolidation en employant la transformation de similitude 3D (transformation conforme 3D) de sept paramètres dont: R - rotation, T - translation et s – facteur d’échelle, tous utilisés afin d’écrire la relation entre deux points homologues d’une paire de segments : ൥ ܺ ܻ ܼ ൩ ൌ ݏܴ ቈݔ ݕ ݖ ቉൅ܶ (6.1) Il faut noter que le système d’équations obtenu à partir de la formule (6.1) est non-linéaire, tandis que l’ajustement par la méthode des moindres carrés requiert un processus de linéarisation et une bonne approximation initiale des paramètres recherchés. Quant à la valeur du facteur d’échelle s, elle est égale à l’unité puisque les scanners laser produisent les données à l’échelle réelle. Néanmoins, cette procédure suppose que les extrémités des 114 segments se conjuguent avec un autre, ce qui peut ne pas avoir lieu en réalité. Les deux versions d’algorithmes implémentées par [Alshawa, 2006] permettent de coupler itérativement des entités linéaires quasi-parallèles. Au cours de chaque itération, les deux lignes les plus proches sont appariées, sous condition que leur distance réciproque soit inférieure à un certain seuil. La procédure est répétée plusieurs fois. Nous partons de la pose corrigée jusqu’à ce que l’appariement obtenu soit le même que celui de l’étape précédente. Étant donné que les segments correspondants, extraits lors d’un processus automatique, se caractérisent souvent par des longueurs différentes (sur-segmentation due au problème des masques) une amélioration de la méthode de [Habib et al., 2004] a été suggérée par [Renaudin et al., 2011]. Or, un vecteur des écarts ݀ܺԦ entre les extrémités des segments correspondants est déterminé le long d’une entité linéaire (Figure 6.4) et rajouté au modèle mathématique (6.1). Ensuite, la technique traditionnelle des moindres carrés a été modifiée afin d’éliminer cette inconnue du processus d’estimation. Cet objectif a été atteint par une nouvelle définition des poids associés au vecteur d’erreurs de mesures (bruit blanc). Cependant, aucune des modifications effectuées n’a d’impact sur le calcul. L’algorithme de minimisation de Gauss-Newton peut toujours être employé pour trouver la solution : les paramètres de similitude spatiale entre deux ensembles de segments. Ce genre d’algorithmes nécessite une transformation initiale et peut offrir une mauvaise estimation lorsque cette dernière est loin de la réalité, ce qui est son inconvénient majeur. L’évaluation qualitative (visuelle) et quantitative du recalage réalisé grâce à un tel algorithme a été effectuée par [Canaz et Habib, 2013]. À cet effet, les paramètres de pose obtenus ont été comparés avec ceux fournis par d’autres méthodes, notamment par le recalage basé sur les plans [Ghanma, 2006] et l’algorithme ICPP (Iterative Closest Projected Point) de [Al-Durgham et al., 2011] étant l’une des variantes d’ICP. Son idée consiste à minimiser la distance entre chaque point d’un scan et sa projection sur trois points de l’autre. Quant à la technique examinée, certains problèmes au niveau d’alignement vertical ont été observés. L’une des causes de cette imprécision vient de la nature des lignes elles-mêmes. Par conséquent, la droite extraite à partir des images et associée à l’arête reconstruite du nuage de points peut être sensiblement différente. Figure 6.4 Principe du recalage se référant à la transformation de similitude 3D (Illustration reproduite à partir de [Renaudin et al., 2011]) Sous un autre point de vue [Guerra et Pascucci, 1999] discutent de différentes méthodes de recalage d’entités linéaires pour lesquelles l’appariement n’est pas connu. Ils proposent d’utiliser un triplet de paires de segments afin de trouver des paramètres de transformation rigide. Le but à atteindre est celui de tester un très large nombre de transformations, toutes calculées à partir des échantillons tirés aléatoirement. La distance déterminée, à chaque fois, entre les lignes permet d’indiquer le meilleur couplage. L’inconvénient de cette méthode est d’avoir une complexité de calcul relativement élevée. De plus, elle suppose implicitement que les milieux des segments doivent être des points correspondants. CHAPITRE 6. Recalage à partir d’entités linéaires 115 [Kamgar-Parsi et Kamgar-Parsi, 2004] ont développé des algorithmes applicables, quelles que soient les lignes : finies ou infinies. La solution adaptée à des segments de ligne de même longueur est présentée par [Kamgar-Parsi et Kamgar-Parsi, 1997]. Pour des segments de longueur différente, trois cas sont envisagés. En désignant des entités linéaires à déplacer par Image (I), tandis que celles de référence comme Model (M), nous distinguons des approches : 1) FMFI (Finite Model, Finite Image) conçu pour dériver la transformation à partir de deux ensembles de segments ; 2) IMII (Infinite Model, Infinite Image) destiné aux lignes infinies et 3) FMII (Finite Model, Infinite Image) approprié à des cas mixtes. En revanche, tous les calculs associés s’appuient sur le schéma développé pour les segments égaux. La fonction de coût minimise la distance entre les points correspondants de chaque paire de droites. Ces derniers sont établis par le paramètre shift ሼs୧ሽ. Finalement, l’estimation de la meilleure transformation se fait itérativement, par la résolution d’un système non linéaire de ሺ6൅ܰሻ équations, en partant de valeurs initiales de ሼݏ௜ሽ, actualisées au bout de chaque boucle. Les analyses effectuées par les auteurs montrent que l’algorithme converge presque toujours vers un minimum, et indépendamment des paramètres initiaux choisis. Le temps de calcul et le nombre d’itérations dépendent de la précision souhaitée. Deux des algorithmes mentionnés auparavant sont devenus l’élément de base des autres méthodes. [Yao et al., 2010] ont cherché à combler le manque d’informations sur l’appariement des entités linéaires à travers une approche s’effectuant en deux étapes. Dans un premier temps, une transformation initiale est calculée à l’aide d’algorithme de [Zhang et Faugeras, 1991], afin d’être ensuite affinée avec l’une des solutions de [Kamgar-Parsi et Kamgar-Parsi, 2004] modifiée de telle façon qu’elle soit moins susceptible de s’appuyer sur des segments de qualité différente. Il se peut que l’incertitude associée à chaque ligne ne soit pas la même, car elle résulte de la densité du nuage diminuant avec l’augmentation de la distance objet-scanner. À chaque phase, le calcul est mené à partir d’un nombre minimal de paires ሺܰ൒2ሻ, excepté que les résultats pour ܰൌ3 sont plus robustes et fiables que ceux pour ܰൌ2. 6.3 Recalage basé-lignes : caractérisation des méthodes Plusieurs approches traitant du problème de recalage rigide basé sur les entités linéaires 3D ont été proposées dans la littérature, comme il a été montré dans la section précédente. Ce paragraphe va aborder en détail trois méthodes méritant notre attention, puisqu’elles donnent un autre regard sur la question mise en avant. Dans un premier temps, la solution nommée EIGEN de [Zhang et Faugeras, 1991] ayant pour but d’estimer le mouvement à partir des segments 3D sera détaillée. Ensuite, l’algorithme ICL de [Alshawa, 2006] conceptuellement inspiré de l’algorithme ICP sera présenté – ICL(forme ICP). Enfin, l’essentiel de l’approche FMII de [Kamgar-Parsi et Kamgar-Parsi, 2004] sera discuté. Chacune des méthodes mentionnées auparavant profite d’une autre représentation du segment dans un espace tridimensionnel et s’appuie sur une autre notation mathématique décrivant la rotation d’objet telle que les quaternions, les angles d’Euler ou bien encore la matrice traditionnelle de rotation. Ces méthodes sont spécifiées respectivement à l’Annexe B, Annexe C et Annexe D. Les signes apparaissant dans toutes les équations se présentent de la manière suivante : ‖ݒ‖ symbolise la longueur (norme) du vecteur ݒ, t indique la transposition, l’inverse d’une matrice est marqué par l’indice (-1), le produit vectoriel est signalé par « ˄ » et bien entendu chaque vecteur s’exprime verticalement. Le Tableau 6.1 résume les trois méthodes d’estimation de la transformation présentées dans la section précédente. Les approches ICL (forme ICP) et EIGEN sont assez similaires, si nous envisageons seulement les démarches nécessaires pour calculer la matrice de rotation – elles s’appuient toutes deux sur l’orientation de lignes. Aussi, la SVD est employée afin de dériver la rotation optimale. Néanmoins, elles présentent un regard diffèrent quand il s’agit 116 de déterminer la translation, résultant principalement de la représentation différente de ligne 3D. Contrairement à EIGEN, l’approche ICL(forme ICP) permet simultanément d’apparier les entités linéaires ce qui devient son point fort. Ce processus se fait de façon itérative et implique le temps de calcul adéquat. Si jamais l’appariement explicite est connu, la solution peut être immédiatement trouvée (non itérativement). Quant à la méthode EIGEN, elle se réfère à des points correspondants et non plus des lignes. Leurs coordonnées sont déterminées grâce au paramètre shift ሼݏ௜ሽ, étant calculé de manière itérative. Nous devons alors introduire ses valeurs initiales, proches de celles réelles. Sinon, l’algorithme peut donner de mauvais résultats. Chacune des méthodes aboutit, quelles que soient les démarches proposées, à estimer les paramètres de transformation en deux étapes : d’abord la rotation ܴ suivie ensuite par la translation ܶ. Tableau 6.1 Récapitulatif de méthodes présentées Auteurs [Zhang et Faugeras, 1991] [Alshawa, 2006] [Kamgar–Parsi et Kamgar–Parsi 2004] Nom EIGEN ICL (forme ICP) FMII Appariement connu Oui Non Oui Représentation du segment Deux vecteurs perpendiculaires : vecteur directeur normalisé et vecteur parallèle à la normale d’un plan passant par cette ligne et l’origine Deux points (extrémités) et vecteur directeur Ligne finie : (milieu, vecteur directeur unitaire, longueur) Ligne infinie : (point de la ligne le plus proche de l’origine, vecteur directeur unitaire) Représentation de la matrice de rotation Quaternion Matrice traditionnelle de rotation Quaternion Fonction à minimiser Orientation de lignes Orientation de lignes Distances entre points correspondants Approche SVD SVD Méthode d’optimisation non-linéaire (valeurs initiales du paramètre shift demandées) Besoin d’itérations ? Non Oui (si appariement à faire) Oui 6.4 Évaluation des méthodes présentées Dans cette partie, nous contrôlerons la robustesse des trois algorithmes détaillés ci-dessus et récapitulés dans le Tableau 6.1. Pour ce faire, plusieurs tests ont été proposés, puis effectués sur des données simulées pour lesquelles l’appariement était déjà connu. Les segments ont été obtenus par modification des arêtes extraites à partir du nuage Sulpice2013_statique, acquis au sein d’une zone test (description détaillée se trouve en section paragraphe 2.2). Nous avons évalué la précision des paramètres estimés par chacune des méthodes en admettons le taux de bruit. À chaque fois, les erreurs ݁ோ ݁ݐ ்݁ des paramètres de transformation estimés ܴ෠ ݁ݐ ܶ෠ ont été calculées. Aussi, la distance de Hausdorff orientée CHAPITRE 6. Recalage à partir d’entités linéaires 117 (OLHD) entre deux ensembles de segments, avant et après la transformation, a été déterminée comme cela est expliqué dans le Chapitre 5. 6.4.1 Données pour les expérimentations Quant aux données simulées, elles étaient générées à partir de 64 segments (F) nommés désormais Model, en appliquant les paramètres prédéfinis de transformation. Deux scénarios ont été examinés : 1) les extrémités des segments originaux, en système Lambert93, ont été dégénérées en leur ajoutant un bruit blanc gaussien centré et de variance connue ߪ ; 2) de plus, la position des points a été modifiée en appliquant les paramètres prédéfinis de transformation rigide ܴ et ܶ. Figure 6.5 Données expérimentales à recaler : a) Test2a ; b) Test2b Dans un premier temps, de petites rotations dans l’espace 3D, exprimées par les trois angles d’Euler (1.0000º ; -1.0000º ; 1.0000º), ont été introduites. Le vecteur de translation ܶ ൌ [-1.000m ; 0.500m ; 1.000m] y associé a été aussi pris en compte. De surcroît, les coordonnées de ces entités linéaires ont été bruitées par tirage aléatoire suivant une loi 118 normale centrée d’écart-type ߪ. Les tests ont été menés pour différentes valeurs de bruit, en partant de ߪ ൌ0.000m et en finissant sur ߪ ൌ0.050m, avec l’intervalle constant de 0.001m. En résulte, des centaines de nouveaux ensembles de données Test, chacun contenant 64 segments, ont été obtenus. Ils constituent d’ores et déjà les données nommées Test2a (Figure 6.5a). Les données Test2b (Figure 6.5b) étaient obtenues de façon identique, mais cette fois-ci, les angles d’Euler ainsi que la translation introduits étaient plus importants et égaux respectivement (3.0000° ;-7.0000° ; 6.0000°) et (3.000m ; 1.000m ; -2.000m). La distance LHD mesurée entre les données Test2a était égale environ à 2.7m, tandis que celle entre les entités Test2b est de 27.5m, en ignorant le bruit ajouté. Nous avons généré un autre jeu de données (Test3), pour lequel la transformation Ƭ fixée en entrée était nulle. Nous avons uniquement simulé le bruit gaussien de variance ߪ pour obtenir l’ensemble Test à partir de Model. 6.4.2 Algorithmes implémentés Le travail réalisé avec l’implémentation sous Matlab® R2010a a permis d’évaluer chaque approche en termes de sensibilité au bruit, de précision de résultats et de temps d’exécution. Les méthodes mises en œuvre suivent le raisonnement présenté dans la section précédente. Parmi les approches proposées par [Kamgar – Parsi et Kamgar-Parsi, 2004] nous avons décidé d’examiner l’algorithme ܫܫܯܨ, en dépit du fait qu’il est dédié à recaler des lignes infinies avec des lignes finies. Notre choix s’explique, conformément à la suggestion des auteurs, par le fait que le ܫܨܯܨ, dédié aux segments de ligne, peut échouer si le segment plus court d’une paire n’est pas complètement inclus dans son homologue. Nous avons légèrement modifié l’algorithme FMII pour le rendre mieux adapté à nos besoins. Nous lui accordons le nom ܫܫܯܨଶ pour le différencier de la version de base. D’abord, la représentation d’entités à déplacer (Image) a été remplacée par celle utilisée pour les droites finies, à une différence près, nous ne prenons pas toujours en compte les longueurs de segments. Chaque élément Image ܺ௜ ൌ ሺݔ௜, ݒ௜ ᇱ ሻ est alors représenté par ݔ௜ étant son milieu (et non plus le point le plus proche de l’origine du système de coordonnées) et ݒ௜ ᇱ son vecteur directeur. Cette solution paraît plus adéquate et accélère la recherche ultérieure des points correspondants qui seront désormais déterminés par rapport aux milieux des segments. En conséquence nous avons dû changer la façon de calculer le paramètre shift ሼݏ௜ሽ en s’inspirant aussi de l’algorithme ܫܨܯܨ. Celui-ci est obtenu par la résolution de l’équation ߲ܯ/߲ݏ௜ ൌ 0, où la distance M(A,ƬX), introduite pour le ܫܨܯܨ (6.2), se calcule en fonction de la longueur des segments. ܯሺܣ௜, Ƭܺ௜ሻ ൌ ൝݈௜‖ܽ௜ ൅ ݏ௜ݒ௜ െ ܶ െ ܴݔ௜‖ଶ ൅ ݈௜ ଷ൫1 െ ݒ௜ ௧ ௜ݒܴ ௜ܮ ൑ ௜݈ ݅ݏ ൯/6 ′ ௜ݒ௜ݏ ൅ ௜ݔฮܽ௜ െ ܶ െ ܴ൫௜ܮ ′ ൯ฮଶ ௜ܮ ൅ ଷ൫1 െ ݒ௜ ௧ ௜ݒܴ ௜ܮ ൐ ௜݈ ݅ݏ ൯/6 ′ (6.2) où : ܮ௜ : longueur du segment Model ݈௜ : longueur du segment Image Sachant que nous considérons les entités linéaires Image comme infinies, leur longueur ሺ݈௜ሻ sera toujours plus grande que celles Model. De ce fait, la formule (D.10) est substituée en : ݏ௜ ൌ ሺܽ௜ െ ܶ െ ܴݔ௜ሻ௧ܴݒ௜ ᇱ (6.3) 6.4.3 Outils d’évaluation La justesse des paramètres de transformation estimés à l’aide de chacune des méthodes a été validée selon les formules : CHAPITRE 6. Recalage à partir d’entités linéaires 119 ݁ோ ൌ 100% ∙ ‖ݎെݎ̂‖/‖ݎ‖ (6.4) ்݁ ൌ 100% ∙ ฮܶ െ ܶ෠ฮ/‖ܶ‖ (6.5) où : ݎ : rotation réelle (paramètre fixé en entrée) ݎ̂ : rotation estimée ܶ : vecteur tridimensionnel de translation (paramètre fixé en entrée) ܶ෠ : vecteur de translation estimée L’équation (6.4) est exacte pour la rotation exprimée à l’aide de quatre paramètres (forme axe-angle de rotation) : un angle ߠ et un axe dirigé par un vecteur unitaire ݎ ൌ ൣ݁௫, ݁௬, ݁௭൧ ௧ (alors avec ݁௫ ଶ ൅ ݁௬ ଶ ൅ ݁௭ ଶ ൌ 1). Il est donc nécessaire de remplacer la représentation classique de rotation ܴ par ݎ de la manière suivante : ߠ ൌ ܽݎܿܿݏ݋ ቆݎݐܽܿ݁ሺܴሻ െ 1 2 ቇ (6.6) ൌ ݎ 1 ൭ ߠ݊݅ݏ2 ܴଷଶ െ ܴଶଷ ܴଵଷ െ ܴଷଵ ܴଶଵ െ ܴଵଶ ൱ (6.7) 6.4.4 Résultats – recalage des données bruitées Ensemble Test2a La Figure 6.6 illustre les erreurs de la rotation ݁ோ et de la translation ்݁, par rapport à ses valeurs réelles. Les tests effectués avec les données Test2a, montrent que les algorithmes ICL(forme ICP) et EIGEN produisent des résultats à un niveau de précision similaire, avec des estimations légèrement plus précises pour EIGEN. Même si les deux approches bénéficient d’une représentation différente de segments, et que la translation est calculée dissemblablement, ceci n’a pas une réelle importance. Dans les deux cas, la fonction de coût est uniquement définie à partir des orientations de segments. Aussi, la matrice de rotation est retrouvée par une décomposition SVD d’une matrice de covariance croisée. Rappelons que l’utilisation de SVD impose de considérer trois possibilités : 1) Les segments ne sont pas colinéaires : donc ݀݁ݐሺܴሻ ൌ 1, la solution unique existe ܴ ൌ ܸܷ௧ ; 2) Les segments sont coplanaires, mais pas colinéaires : alors ݀݁ݐሺܴሻ ൌ െ1, la solution unique existe nommée la réflexion ܴ∗ ൌ ܸ∗ܷ௧ où ܸ∗est créé en changeant le signe de la troisième colonne de V ; 3) Les segments sont colinéaires : il existe une infinité de solutions. Quant à l’évaluation des approches implémentées, les deux méthodes mentionnées présentent une faible résistance au bruit. L’estimation de la rotation atteint un niveau de précision de 5% pour un écart-type du bruit ߪ ne dépassant pas 0.015m. L’erreur de la translation est plus importante et peut arriver, dans cet intervalle, jusqu’à 27%. De loin, le meilleur algorithme le ܫܫܯܨଶ donne, indépendamment du bruit introduit (ߪ ∈ [0.000 ;0.005]), des résultats précis. L’erreur de la matrice de rotation ݁ோ est inférieure à 0.5% pour un ߪ ൏0.02m et oscille entre 0.5% et 3.6% pour les autres valeurs ߪ, afin d’atteindre son maximum pour ߪ ൌ0.047. L’erreur de translation ்݁, quant à elle, est supérieure à ݁ோ et reste dans un intervalle de 2.9% à 8.5%. 120 Figure 6.6 Comparaison de différentes méthodes d'estimation de transformation rigide – données Test2a Figure 6.7 Méthode ܫܫܯܨଶ : évaluation de chaque composant de la rotation et de la translation par rapport aux valeurs réelles CHAPITRE 6. Recalage à partir d’entités linéaires 121 Afin d’obtenir une évaluation plus complète du ܫܫܯܨଶ, une analyse exhaustive de chaque composant du vecteur de translation et de tous les angles d’Euler () a été faite. Des différences entre les paramètres estimés et réels ont été calculées et illustrées dans la Figure 6.7. Quant aux valeurs angulaires, aucune tendance n’a été constatée pouvant indiquer l’angle le moins bien estimé. Mais, en tenant compte du vecteur de translation, l’alignement selon l’axe Y est déterminé inexactement dans la plupart de cas. Pour un écart-type du bruit raisonnable, c’est-à-dire un ߪ inférieur à 0.02m, il est clairement visible qu’il existe une dépendance entre les erreurs relatives de déplacements. Ainsi, l’erreur d’alignement selon l’axe Z est la plus petite, suivie ensuite d’erreur selon l’axe X et Y. Ensemble Test2b Des tests tout à fait identiques ont été aussi menés pour des valeurs beaucoup plus importantes de rotation et de translation – données Test2b. Plusieurs combinaisons d’angles de rotation ont été examinées. La Figure 6.8 illustre les erreurs ݁ோ et ்݁ obtenues pour différents écarts-types du bruit ߪ. Les résultats confirment que les trois méthodes sont adéquates pour recaler deux ensembles de segments à condition que les angles d’Euler décrivant une rotation soient petits (inférieurs à 2-3 degrés) et la distance relative assez faible. Cette constatation n’est pas très surprenante puisque les méthodes semblables à l’ICP sont censées fournir un bon recalage local. Ceci est dû à l’étape de linéarisation indispensable pour résoudre le problème non-linéaire de rotation. Ainsi, la fonction ne peut plus décrire les vraies interactions entre les éléments. Il est alors nécessaire que les deux nuages soient à peu près alignés. Une transformation grossière doit être appliquée avant de démarrer ces algorithmes. Aussi, le ܫܫܯܨଶ, comme il a été démontré, exige des estimées initiales, si la rotation mutuelle des éléments à affiner est trop importante. Figure 6.8 Comparaison de différentes méthodes d'estimation de transformation rigide – données Test2b 122 Pour conclure, nous constatons alors que les méthodes ICL(forme ICP) et EIGEN, contrairement au ܫܫܯܨଶ, présentent une faible robustesse au bruit et ne peuvent être employées qu’afin de recaler des segments dont la position des extrémités est précisément connue (ߪ ൏ 0.005m). De plus, l’emplacement relatif de deux ensembles d’entités linéaires joue un rôle important en rendant ces trois approches appropriées pour affiner des données proches. Temps de calcul En outre, une analyse complémentaire (avec les données Test2a) ayant pour but de mesurer le temps de calcul (CPU time) en fonction du bruit simulé a été effectuée. La Figure 6.9 présente la performance des trois approches, examinée sur 64 segments. La méthode EIGEN s’avère légèrement plus rapide (avec en moyenne 2ms de différence) que l’algorithme itératif ICL(forme ICP). Cependant, les deux techniques convergent trois fois plus rapidement que le ܫܫܯܨଶ. Néanmoins, il faut noter que chaque algorithme a été appliqué sur l’appariement déjà connu et donc l’approche ICL(forme ICP) s’exécute en une seule itération. Figure 6.9 Comparaison des temps d’exécution (Matlab® R2010a)* * Intel Core x2 T7600 2.33Ghz / 4Go Ram / Win7 64bits 6.4.5 Impact du bruit sur la distance de Hausdorff Pour compléter les analyses présentées précédemment et pour mieux visualiser l’impact de la précision des paramètres estimés sur la qualité du recalage, la distance orientée de Hausdorff (OLHD) a été utilisée comme il a été vu et défini dans le Chapitre 5. Un autre jeu de données (Test3) a été employé. Nous rappelons que cette fois-ci, les paramètres fixés servant à créer les segments Test étaient nuls, et seulement la position des segments Model a été dégénérée par un bruit gaussien prédéfini. Nous attendons que les paramètres estimés (ܴ෠ ݁ݐ ܶ෠) par chacun des algorithmes testés soient égaux, quasiment équivalents ou proches de zéro. Aussi, la position des segments transformés (Test) devrait rester pratiquement inchangée. Nous vérifions alors l’éloignement entre les entités linéaires, en tant que la distance OLHD. Les valeurs obtenues après le recalage réalisé à l’aide de la méthode ICL(forme ICP) et ܫܫܯܨଶ sont confrontées avec les écarts initiaux (Figure 6.10). L’approche EIGEN a été exclue de l’analyse puisqu’elle est censée fournir les paramètres de transformation ayant les erreurs similaires à l’algorithme ICL(forme ICP). CHAPITRE 6. Recalage à partir d’entités linéaires 123 Nous observons, dans le cas d’ICL, une forte influence du bruit sur le résultat d’évaluation. Même si l’inexactitude des extrémités de segments est faible, cet algorithme empêche de parvenir aux paramètres optimaux. Par conséquent, la distance réciproque entre les segments consolidés augmente par rapport à celle de départ. Cela veut dire que le recalage, lui-même, est loin d’être correct et satisfaisant. Le problème mentionné n’existe pas lorsque l’algorithme ܫܫܯܨଶ est implémenté. Figure 6.10 Distance orientée de Hausdorff (OLHD) : a) algorithme ICL(forme ICP) ; b) algorithme ܫܫܯܨଶ Propriété de la distance de Hausdorff De surcroît, une propriété intéressante de la métrique de Hausdorff employée a été constatée. Il s’agit de la relation entre la distance OLHD et l’écart-type de bruit gaussien ߪ rajouté à des extrémités de segments. Nous avons démontré que plus le taux de bruit est important plus la valeur de distance OLHD augmente. Plusieurs échantillons ont été créés à partir de 124 données réelles (S1,S2,S3,F), comme celui illustré dans la Figure 6.11, pour retrouver cette constante (coefficient de proportionnalité). Finalement, l’équation d’une droite ayant une meilleure approximation (régression linéaire) notée sous la forme ݕ ൌ ܽݔ ൅ ܾ a été déterminée, de sorte que le coefficient directeur de la droite ሺܽሻ est égal à 5.8 ∓ 0.17 et que le nombre ܾ est 0.000 ∓ 0.001. Pour être plus précis, il y a une proportionnalité entre la distance obtenue (OLHD) et l’écart-type de bruit ߪ, ce que l’on peut exprimer par ܱܦܪܮ ∝ ߪ. C’est pourquoi, si la distance de Hausdorff entre deux ensembles de segments est connue, nous pouvons estimer l’écart-type de bruit ߪ associé aux segments et vice versa. Figure 6.11 Représentation graphique d’une droite d’approximation retrouvée à partir des distances OLHD calculées pour les différents écarts-types de bruit ߪ 6.5 Approche proposée : RLMR-FMII2 Nous avons pu observer dans la section précédente que l’imprécision du recalage vient de l’algorithme d’estimation et voire même plus, de la particularité géométrique d’une entité linéaire. Comme le rapporte [Hullo, 2013], l’incertitude d’une ligne 3D, à la différence de celle d’un point 3D, n’est pas bien définie. En outre, elle varie d’une représentation à une autre pouvant provoquer des difficultés lors de l’optimisation des contraintes sur ces lignes. Les analyses effectuées au sein de cette thèse le confirment aussi. Les algorithmes EIGEN et ICL(forme ICP) basés entièrement sur des segments ont la précision en deçà du ܫܫܯܨଶ minimisant la distance entre les points correspondants. Ils ne peuvent être employés que sur des segments dont les extrémités ne sont pas bruitées. Ce constat nous a encouragés à choisir le ܫܫܯܨଶ, comme notre algorithme de base. Néanmoins, cette méthode offre des résultats précis à condition que l’appariement explicite des entités linéaires soit connu. Nous avons voulu combler ce défaut en suggérant une chaîne complète, nommée ܴܯܮܴ െ ܫܫܯܨଶ, comprenant la mise en correspondance des segments, suivie par l’estimation des paramètres de pose. Pour apparier des entités linéaires, nous proposons d’utiliser l’approche déjà discutée dans le cadre de ce manuscrit, et détaillée au chapitre précédent. Sa performance a été vérifiée à travers plusieurs tests dont les résultats ont dévoilé une dépendance forte entre l’exactitude du couplage effectuée et l’écartement de deux ensembles de segments. Ceci est dû au fait que la mise en correspondance des segments peut s’effectuer incorrectement, puisque la méthode employée se heurte à un seuil inapproprié, ou bien encore les ressemblances entre les segments ne peuvent plus être reconnues proprement. Il se peut alors qu’au bout d’une certaine distance, le taux de Faux Positif (FP) soit élevée par-devers le nombre de Vrais Positifs faible. Nous avons aussi conclu que l’un des remèdes à ce genre de problème pouvait consister à rapprocher des segments avant de démarrer l’algorithme. Nous avons fait recours à cette solution en proposant des CHAPITRE 6. Recalage à partir d’entités linéaires 125 démarches complémentaires (recalage grossier) ayant pour but de diminuer l’éloignement entre les données traitées et faciliter leur mise en correspondance ultérieure. Notre but est donc de développer une méthode de recalage 3D résistante au bruit, aux paires aberrantes, mais aussi permettant d’apparier simultanément des segments, puisque cette tâche n’est pas triviale et surtout impossible avec le ܫܫܯܨଶ seul. Figure 6.12 Schéma général du recalage proposé ܴܯܮܴ െ ܫܫܯܨଶ De manière générale, nous pouvons distinguer quatre étapes principales de l’approche développée : 1) l’appariement combinatoire (approximatif) d’entités linéaires 3D ; 2) le recalage grossier à partir d’un triplet de paires ; 3) l’appariement fin; 4) le raffinement du recalage (Figure 6.12). La mise en correspondance, qu’elle soit approximative ܣ௜௡௜ ou explicite ܣ௙, est réalisée conformément à la solution proposée pour la méthode de qualification. C’est pourquoi nous ne revenons plus sur cette procédure. Rappelons seulement qu’une fois cet algorithme exécuté, les calculs sont menés dans deux sens : en comparant l’ensemble Test (segments à déplacer) avec le Model (segments immobiles) et vice versa. Ainsi, à la sortie, deux matrices de correspondance sont indépendamment déterminées. Cette information redondante peut être utile pour contrôler la justesse de l’appariement. Afin de diminuer le nombre de paires erronées (FP) et de garantir un bon appariement approximatif ܣ௜௡௜, les segments sont initialement couplés en relation de 1 à 1 au plus. Mais, cette contrainte n’est plus valable avec l’appariement explicite ܣ௙. Les deux recalages – grossier et fin, sont calculés de la même façon, à savoir, à l’aide de l’approche ܫܫܯܨଶ. La seule différence réside dans le fait que la consolidation initiale (ܴ௜௡௜, ܶ௜௡௜) est atteinte à partir d’un sous-ensemble minimal (k), considéré comme « le meilleur » possible. Une technique de tirage aléatoire (RANSAC) de ݇ paires de l’ensemble ܣ௜௡௜ amène à assurer un échantillon optimal, ne contenant plus de mauvaises associations. Or, la méthode combinée RANSAC-FMII2 fournit une estimation initiale de la transformation en prenant en compte l’appariement préalable ܣ௜௡௜. Pourtant, la position des segments, après le recalage grossier, est suffisamment proche de l’optimum, nous pouvons créer un appariement explicite ܣ௙ servant, à son tour, au recalage fin réalisé avec le ܫܫܯܨଶ seul. En fin de compte, chacun de ces algorithmes constitue une partie intégrale de notre procédure ܴܯܮܴ െ ܫܫܯܨଶ.126 6.5.1 Recalage grossier – principe La finalité du recalage grossier cherche à rapprocher deux ensembles d’entités linéaires pour faciliter leur appariement. En présumant l’existence de mauvaises paires au sein de l’appariement ܣ௜௡௜ résultante de la distance mutuelle importante entre deux ensembles de segments, nous ne pouvons pas l’utiliser tel quel lors de l’estimation des paramètres par ܫܫܯܨଶ. Se référant aux tests menés par [Yao et al., 2010], nous avons décidé de nous appuyer sur seulement trois paires de segments (k=3) pour trouver les estimées initiales. Ces dernières sont calculées à l’aide de la méthode ܫܫܯܨଶ. Plusieurs tirages aléatoires doivent être effectués avec l’algorithme de RANSAC, afin de découvrir le meilleur triplet de paires parmi celles recueillies par l’appariement initial ܣ௜௡௜. Pour obtenir les bons paramètres, le nombre d’itérations (ܰ௜௧௘௥) est choisi dynamiquement en fonction des « inliers » présents dans la boucle précédente (équations (6.8) et (6.9)). ܰ௜௧௘௥ ൌ logሺߝሻ logሺ1 െ ݍሻ (6.8) ൌ ݍ ቀ ܰூ ݇ ቁ ቀ ܰ ݇ቁ ൌ ܰூ! ሺܰെ݇ሻ! ܰ! ሺܰூ െ ݇ሻ! ൌ ෑܰூ െ ݅ ܰെ݅ ൎ ൬୍ܰ ܰ൰ ௞ ௞ିଵ ௜ୀଵ (6.9) où : ܰூ ൌ ܿܽݎ݀ሺܥܧሻ : nombre de paires de segments (inliers) satisfaisants la transformation effectuée ; ܰ ൌ ܿܽݎ݀ሺܣ௜௡௜ሻ : nombre de paires de l’appariement initial ܣ௜௡௜ ; ݇ : nombre minimal de paires de segments pour estimer la transformation optimale, la valeur adoptée k=3 ; ߝ : taux de fausses alertes (false alarm rate), la valeur adoptée ߝ ൌ 1݁ െ 6 ; En raison de la faible probabilité de parvenir à la même combinaison de triplet de segments deux fois, nous n’avons pas modifié l’algorithme de RANSAC, en exigeant la mise en place d’une liste de combinaisons d’entités linéaires déjà prises. Pour chaque échantillon, la transformation du repère est calculée (avec FMIIଶ), et suivie par un recalage correspondant. Dès lors, les distances ݀൫ݐ௜, ݉௝൯ entre toutes les paires de segments listées par l’appariement approximatif ܣ௜௡௜ sont recalculées (équation 5.10), afin de mesurer le nombre de valeurs aberrantes (outliers) définies comme หሼሺ݅, ݆ሻ߳ܣ௜௡௜ሽ: ∀൫ݐ௜ ∈ ܦܽݐܽ, ݉௝ ∈ ݋ܯ݈݀݁൯, ݀൫ݐ௜, ݉௝൯ ൐ ߜห. Le seuil ߜ est fixé du fait que la distance de Hausdorff orientée (OLHD) entre deux ensembles de lignes n’est jamais inférieure à 5.8ߪ; comme il a été démontré préalablement (Paragraphe 6.4.5). Cette constatation nous a permis de garder « le meilleur » triplet de paires. Celui-ci est désigné à partir du nombre de segments recalés ayant la distance réciproque inférieur au seuil prédéfini ߜ. En conséquence, plus le nombre de segments est important, plus la transformation calculée est meilleure. Nous avons également examiné la précision des paramètres estimés ܴ෠ et ܶ෠ lors du recalage grossier. Les données du Test2a ont été employées pour calculer les erreurs ݁ோ et ்݁, selon les équations (6.4) et (6.5). La Figure 6.13 présente les résultats obtenus par rapport à l’état de l’art. Il en résulte que le recalage grossier basé sur trois paires de segments est moins précis que celui réalisé par l’algorithme ܫܫܯܨଶ seul sur toutes les paires connues a priori. Cela n’est guère surprenant puisque la qualité de la solution reçue avec le ܫܫܯܨଶ augmente de plus en plus, quand nous rajoutons d’autres couples. Par contre, ce recalage garantit une bonne estimation initiale, si les deux ensembles de segments ne sont pas très éloignés, et si les angles de rotation à estimer ne sont pas trop importants. CHAPITRE 6. Recalage à partir d’entités linéaires 127 Figure 6.13 Exactitude du recalage basé sur un triplet de paires de segments (données Test2a) 6.5.2 Évaluation avec données simulées La qualité des estimations obtenues par notre approche ܴܯܮܴ െ ܫܫܯܨଶ a été vérifiée, tout d’abord, à l’aide des données simulées (Test 2a). La Figure 6.14 visualise le chemin détaillé de notre parcours et les résultats intermédiaires d’appariement avec leur évaluation qualitative (VP, VN, FP, FN marqués par différentes couleurs), tous les deux obtenus à partir du jeu dégénéré par le bruit gaussien dont le ߪ ൌ0.03m. Conformément aux hypothèses posées, l’appariement approximatif ܣ௜௡௜ contient à peine quelques Faux Positifs au détriment du nombre de Faux Négatif. Mais, il constitue une bonne base de départ pour calculer rapidement des paramètres initiaux, même si l’algorithme de RANSAC est généralement assez coûteux en temps de calcul. Quant à l’appariement final ܣ௙ déterminé de nouveau à partir des segments déjà recalés grossièrement, il se caractérise par une précision beaucoup plus élevée (par exemple, dans le cas étudié Sensibilité=100%, Spécificité=99.95% alors que seulement 0.05% des combinaisons envisagées avaient été examinées de manière incorrecte). Aussi, les tests procédés sur d’autres données simulées ont confirmé que la solution proposée permet d’améliorer significativement la mise en correspondance de segments. En revanche, le résultat dépend également du taux de bruit, moyennant quoi les faux appariements peuvent être toujours présents. Afin d’analyser l’impact de ces mauvaises paires (notamment les FP) sur la qualité des estimations, nous avons analysé les erreurs ݁ோ et ்݁ calculées selon les formules (6.4) et (6.5). Ensuite, une comparaison de ces valeurs par rapport à celles obtenues par l’algorithme ܫܫܯܨଶ basé sur l’appariement précis connu a priori, a été entreprise. La Figure 6.15 présente le résultat d’une telle expérimentation. Nous pouvons constater que plus l’écart-type de bruit σ est petit, plus l’appariement est précis, et donc que les erreurs d’estimation sont du même 128 ordre de grandeur. Néanmoins, la méthode ܴܯܮܴ െ ܫܫܯܨଶ paraît donner des résultats légèrement moins précis, surtout quand le ߪ est supérieur à 0.025m et une présence de Faux Positifs est incontestable. Figure 6.14 Mise en correspondance des segments Test2a (σ=0.03m) et le recalage rigide selon l’approche proposée ܴܯܮܴ െ ܫܫܯܨଶ. Les couleurs employées pour évaluer l’appariement : Vrai Positif(VP)-vert ; Vrai Négatif(VN) – gris ; Faux Positif(FP) – jaune ; Faux Négatif(FN) – rouge ; CHAPITRE 6. Recalage à partir d’entités linéaires 129 Figure 6.15 Qualité de la solution (données Test2a) : Algorithme ܫܫܯܨଶ vs. Approche ܴܯܮܴ െ ܫܫܯܨଶ avec la mise en correspondance de segments effectuée simultanément L’histogramme de répartition de différences d’erreurs d’estimation créé à partir de la Figure 6.15 montre que pour 95% des valeurs de ߪ, les différences de ݁ோ sont comprises dans un intervalle de [-1.28% ; 1.28%], tandis que celles de ்݁ sont dans un intervalle de [-2.82% ; 2.82%] (Figure 6.16). Figure 6.16 Histogramme de différences d'erreurs Pour mieux comprendre la grandeur de cette imprécision d’estimation de paramètres sur la position relative des segments recalés, nous avons déterminé la distance LHD. La Figure 6.17 illustre les différences entre la distance calculée après le recalage basé sur l’algorithme ܫܫܯܨଶ et celle obtenue après avoir mis en œuvre le ܴܯܮܴ െ ܫܫܯܨଶ. Ces valeurs sont négligeables et ne dépassent pas 0.004m, même si la présence de quelques paires erronées avait été constatée. Notre algorithme, effectuant à la fois l’appariement des entités linéaires et l’estimation des paramètres de pose, donne des résultats fiables. En ce qui concerne la mise en correspondance ܣ௙, elle se caractérise d’une précision élevée, atteinte grâce au recalage grossier convenable. 130 Figure 6.17 Vérification des différences de distances LHD 6.5.3 Tests sur données réelles La performance de l’approche ܴܯܮܴ െ ܫܫܯܨଶ a été aussi vérifiée à l’aide de données réelles (voir Figure 5.13). Le Tableau 6.2 représente les valeurs numériques (les paramètres de transformation estimée, l’éloignement des deux nuages de points, le temps de calcul, etc.) obtenues avec ces segments. À cet effet, les relevés laser mobiles de différents passages ont été recalés entre eux (S1_S2 ; S1_S2 ; S2_S3), ainsi qu’avec le nuage de points statique (F) dans l’intention de corriger leur position absolue. À chaque fois, une amélioration importante de l’appariement initial ܣ௜௡௜ a été relevée (Figure 6.18). De plus, la vérification d’ajustement des nuages de points après les deux recalages successifs grossier et fin a été réalisée à travers la distance OLHD. Les valeurs obtenues confirment que la méthode proposée permet d’estimer une transformation optimale, à condition que les angles de rotation et la distance réciproque soient petits. Cette modalité est aisée à remplir puisque les nuages de points issus d’une plate-forme mobile sont déjà géo-référencés dans un système de référence commun. Dès lors, leur position relative est assez proche et l’orientation pratiquement parallèle. Par conséquent, la suppression d’erreur systématique, plus précisément d’erreur de mesure restant constante pendant l’acquisition, peut être corrigée par la méthode de recalage proposée. Pour justifier notre démarche nécessitant la mise en correspondance des segments à deux reprises (d’abord l’appariement approximatif ܣ௜௡௜ suivi par l’appariement affiné ܣ௙), nous avons également envisagé une solution consistant à appliquer l’algorithme ܫܫܯܨଶ directement sur l’ensemble de paires ܣ௜௡௜. La dernière ligne du Tableau 6.2 contient la distance LHD déterminée lors d’un tel recalage. Celle-ci est plus importante que l’écart atteint avec la méthode proposée ܴܯܮܴ െ ܫܫܯܨଶ. Nous pouvons noter que l’utilisation de l’algorithme RANSAC habituellement très coûteux en temps de calcul a été compensée par la mise en correspondance explicite des segments. La consolidation précise de nuages de points devient possible. Quant au temps de calcul, il est de l’ordre de dizaines de secondes (code non optimisé). Le plus important a été observé lors du recalage avec les segments S2. Mais, c’est un cas particulier car d’une côté la zone de chevauchement entre ces deux nuages est petite. De l’autre côté, la qualité du nuage S2 est faible (comme il est démontré au Chapitre 5) et il devient difficile à trouver un échantillon optimal satisfaisant aux exigences imposées (les mêmes pour tous les jeux de données). D’où un grand nombre d’itérations de RANSAC. CHAPITRE 6. Recalage à partir d’entités linéaires 131 Tableau 6.2 Résultats de l’approche combinée Jeu de données S1-S2 S1-S3 S2-S3 S1-F S2-F S3-F Distance initiale [m] 0,516 0,230 0,560 0,671 1,257 0,657 Nombre d'itérations 248 58 563 88 1640 109 Distance après le recalage grossier [m] 0,346 0,223 0,481 0,266 0,451 0,320 Distance FINALE [m] 0,304 0,213 0,377 0,189 0,220 0,140 Angle d'Euler estimés [°]: Ω 0,35196 -0,15530 0,68971 0,30821 -0,00763 0,03841 Φ -0,12854 -0,00760 -0,19781 -0,17301 -0,14627 -0,08465 Κ -0,43047 -0,21210 0,28428 -0,01031 0,09351 0,18708 Translation estimée [m]: Tx 0,950 -0,205 1,172 -0,646 -0,331 -0,205 Ty -0,833 0,108 -1,048 0,014 -0,525 -0,461 Tz 0,189 0,177 -0,708 -0,494 -0,285 -0,507 CPU Time* [s] 18,1 10,4 50,4 7,8 183,6 16,4 Distance [m]: FMII2+Aini 0,328 0,214 0,391 0,254 0,861 0,334 * Intel Core x2 T7600 2.33Ghz / 4Go Ram / Win7 64bits Le pseudo-code 6.1 (Annexe E) est notre approche du recalage telle qu’elle est implémentée. Nous avons besoin en entrée de coordonnées de deux ensembles de segments : ்ܺ௘௦௧ et ܺெ௢ௗ௘௟. Aussi, quelques paramètres sont attendus notamment l’écart-type du bruit ߪ et le nombre d’un échantillon minimal (k), tous les deux indispensables pour initialiser l’estimateur de RANSAC. L’algorithme rend une solution optimale, c’est-à-dire les paramètres de transformation rigide ܴ et ܶ. Optionnellement, nous pouvons obtenir l’information sur l’appariement créé ݎ݋ܥ, ainsi que les résidus calculés (distances) entre les segments recalés. 132 Figure 6.18 Mise en correspondance de segments réel S2 (en vert) et F(en rouge) avec l’évaluation des résultats 133 CHAPITRE 7 Perspectives et conclusion Sommaire : 7. Perspectives et conclusion ............................................................................................. 133 7.1 Conclusion ............................................................................................................................... 133 7.2 Perspectives et futurs travaux ............................................................................................. 136 7.2.1 Étalonnage extrinsèque du système : esquisse de solution .................................................. 136 7. Perspectives et conclusion 7.1 Conclusion Dans cette thèse, nous nous sommes intéressés à la cartographie mobile terrestre. Notre étude se place dans le cadre du projet TerraMobilita dont l’objectif est de développer des technologies optimisées de relevé des voiries et de l’espace public avec une précision topographique élevée. Les travaux présentés proposent alors des solutions pour la qualification des nuages de points collectés, ainsi que des méthodes de recalage de données multi-sources. Nous nous sommes également penchés sur l’étalonnage du système intégral. Ce manuscrit se divise en quatre parties principales : 1) L’acquisition de nuages de points mobiles et l’étude bibliographique sur les erreurs ayant un impact sur leur qualité ; 2) L’extraction d’arêtes ; 3) La qualification à partir d’entités linéaires ; 4) Le recalage rigide basé sur des arêtes. Nous avons commencé par présenter de manière générale les différents systèmes de numérisation 3D mobile terrestre afin de nous focaliser sur les systèmes et les données utilisées dans cette thèse. La problématique d’évaluation de l’exactitude des données mobiles et des protocoles de contrôle de la qualité géométrique sont ensuite abordés en détail. Après, de différentes anomalies entachant le fonctionnement d’un système de cartographie mobile ont été analysées. Le but a été d’aider à établir une connaissance profonde des facteurs primordiaux affectant les nuages de points. Nous pouvons ici citer à titre d’exemple la précision du système de positionnement hybride à base de GNSS et INS, l’angle d’incidence du rayon laser, la distance scanner-objet, le manque d’étalonnage juste (extrinsèque ou intrinsèque). La prise en conscience de leur nature ouvre également la porte à des améliorations et des développements possibles. Cette partie fortement théorique nous a permis de converger vers des solutions innovantes d’évaluation et de correction de données laser produites. Nous avons ainsi présenté nos travaux se rapportant à la qualification et l’amélioration du système de balayage laser 134 mobile. Les méthodes que nous avons adoptées sont celles basées sur les entités linéaires. D’ailleurs, toutes les parties de notre manuscrit ont été accompagnées par un état de l’art exhaustif permettant de repérer la place de notre travail par rapport à l’état actuel de la recherche. La Figure 7.1 nous montre un schéma général des tâches réalisées, avec extraction des entités linéaires, servant à leur tour à la qualification et au recalage. La problématique de l’étalonnage basé sur les segments reste toujours à poursuivre. Mais, une procédure possible à mettre en place est décrite ci-dessous. Figure 7.1 Schéma des travaux réalisés et travaux futurs La deuxième partie de notre thèse se focalise sur l’extraction des arêtes à partir de nuage de points de densité faible. Même si la détection de lignes est une tâche primordiale dans la modélisation 3D, les travaux existants ne sont pas nombreux. Certains algorithmes permettent de détecter des ouvertures en forme de fenêtre et de porte (arêtes de pas). Une autre possibilité est d’examiner la normale au point. Le changement brusque de son orientation permet de constater la présence d’intersection de deux surfaces adjacentes. Néanmoins, l’arête reconstituée à l’aide de telles méthodes sera d’autant plus proche de l’arête réelle que la densité du nuage est élevée. Puisque notre but est de parvenir à extraire des segments précis, quelle que soit la densité du nuage, nous avons développé une méthode de détection des plis (intersections entre segments plans principaux de la scène). Celle-ci comporte deux étapes : 1) la segmentation en éléments plans via l’algorithme de RANSAC enrichi d’une analyse des composantes connexes ; 2) la reconstruction des arêtes. En ce qui concerne l’étude de la connectivité et de la sémantique, nous avons proposé une nouvelle méthode fondée sur la théorie des graphes. Le nuage est structuré en tenant compte du voisinage local de chaque point. Puis, la décomposition de Dulmage-Mendelsohn est effectuée. Les résultats obtenus avec des relevés laser mobiles confirment que cette méthode d’extraction de composantes connexes est efficace et robuste. Son étape la plus coûteuse en temps de calcul est celle de la détermination du voisinage. Concernant la performance de l’algorithme de RANSAC implémenté dans l’intention d’isoler les plans principaux, elle dépend de deux grandeurs : du taux de bruit et de la densité du nuage. Il se peut alors que certains plans, les plus souvent perpendiculaires à la direction de la plate-forme, ne soient pas détectés puisque ces sous-nuages se caractérisent par une densité plus faible et par un bruit important. Ce constat signifie pour nous qu’un nombre d’arêtes ne sera jamais extrait, du fait de l’incomplétude des plans fournis par l’algorithme de RANSAC. Par la suite, nous avons élaboré une démarche de qualification, en termes d’exactitude et de précision, de relevés laser mobiles. Certes, l’évaluation des nuages de points pose des défis particuliers en raison de la nature de données traitées. Plusieurs méthodes portant un intérêt sur l’exactitude ont été déjà discutées, toutes nécessitant une référence externe au système d’acquisition. Les travaux aboutissent soit à une analyse de coordonnées des points de contrôle, soit à une mesure d’éloignement dérivée grâce à des approches traitant du problème de manière plus globale (algorithme de type ICP). Dans le cas d’une comparaison de cibles, la résolution limitée de nuage mobile peut empêcher l’identification précise de détails. Cette tâche étant fastidieuse, son automatisation est difficile à atteindre. Quant à la qualification basée sur l’ICP, elle ne vérifie que l’exactitude relative puisque la valeur de qualité obtenue représente la distance résiduelle entre deux ensembles de données. De plus, la mise en œuvre de l’ICP exige CHAPITRE 7. Perspectives et conclusion 135 que les données à comparer soient à peu près alignées. Étant donné que nous avons souhaité déterminer l’exactitude absolue, l’évaluation des relevés laser par recalage demeure inappropriée. Nous avons proposé une procédure de qualification basée sur des entités linéaires. Notre objectif a été de développer une solution entièrement automatique. L’éloignement de deux sous-ensembles d’arêtes, exprimé en tant que la distance de Hausdorff modifiée adaptée aux lignes est notre indicateur de qualité. Mais, d’abord nous apparions, entre deux nuages, les segments les plus proches au sens de la métrique définie. Nous prenons en compte la distance et l’angle entre toutes les combinaisons de segments afin de déterminer, pour chaque couple de segment, un score. Ce dernier est alors composé d'un écart angulaire, d’un indicateur de recouvrement et de la distance entre les segments parallélisés. La mise en correspondance entre les segments de référence et les segments extraits des scans se fait via le seuillage d’une matrice de similarité dont les coefficients sont un score mentionné. Les données réelles ont permis d’observer que notre algorithme d’appariement devient de plus en plus robuste lorsque l’éloignement est moindre. Nous admettons, avec une marge importante, que la distance réciproque inférieure à 2.5 m garantit un taux élevé de bons appariements. Puisque l’exactitude des données produites par des systèmes mobiles récents est loin d’être métrique, cette contrainte de distance sera toujours satisfaite. La mise en correspondance peut ainsi être précisément effectuée, permettant une qualification robuste et efficace. Quant à la métrique de Hausdorff introduite, elle est tout à fait adaptée pour mesurer l’écart géométrique entre segments potentiellement homologues. De plus, elle se caractérise par une propriété intéressante. Nous constatons que sa grandeur est proportionnelle à l’écart-type de bruit entachant des arêtes. Par conséquent, la connaissance de la distance entre deux ensembles de segments permet d’estimer l’incertitude associée aux extrémités et vice versa. Résumant, la méthode proposée paraît pertinente, et également transposable en photogrammétrie notamment pour l’évaluation de la qualité d’une stéréorestitution ou de modèles 3D. Notre solution peut être perçue comme un compromis entre les deux familles d’algorithmes de qualification : ceux profitants de cibles ou de détails « naturels », et ceux se référant au recalage. Nous nous sommes ensuite intéressés aux problèmes de recalage rigide basé, lui aussi, sur les entités linéaires. Une grande partie de ce chapitre traite la problématique d’estimation des paramètres de transformation rigide à partir de lignes. Nous avons porté un regard critique sur quelques méthodes conçues à cet effet. Les analyses effectuées ont eu pour but de vérifier leur efficacité et leur précision vis-à-vis de notre problématique. Il s’agit de corriger le décalage (shift) survenu entre les nuages redondants acquis par une plate-forme mobile terrestre. Il en ressort que : 1) l’utilisation de primitives linéaires telles que les arêtes de plis (intersections de plans) est appropriée pour les environnements urbains et permet la réduction du nombre de cibles nécessaires ; 2) le gain de précision du recalage dépend de l’incertitude d’une ligne 3D qui, quant à elle, est due à la présence du bruit, et peut varier d’une représentation de droite à une autre ; 3) la mise en correspondance explicite des entités linéaires joue un rôle crucial dans le processus de recalage ; 4) le bruit affectant les extrémités de segments 3D peut provoquer des difficultés de convergence lors de l’optimisation de contraintes sur ces lignes ; 5) en l’absence de précision requise, le recalage basé sur les segments peut toujours servir à trouver les estimées initiales, indispensables pour initialiser certains algorithmes. Sur cette base, nous avons proposé d’étendre l’étude à la chaîne complète comprenant une mise en correspondance suivie par une estimation des paramètres de recalage à travers de segments. Une nouvelle approche nommée ܴܮܯܴ െ ܫܫܯܨଶ est développée, puis évaluée. Nous avons testé 136 sa robustesse face à différentes valeurs du bruit ajoutées aux extrémités et ayant l’effet sur l’incertitude d’une ligne. Par ailleurs, pour diminuer les anomalies affectant la génération de données laser 3D, nous nous sommes penchés sur l’étalonnage extrinsèque. Nous avons étudié, si et dans quelle mesure, les arêtes doivent être prises en compte pour déterminer la matrice de boresight. Les résultats d’une analyse préliminaire étant prometteurs, cet axe de recherche mérite d’être approfondi. Avant tout, des solutions dédiées aux systèmes terrestres équipés de scanners de profil 2D doivent être développées. En conclusion, les arêtes sont appropriées pour qualifier et recaler les relevés laser mobiles acquis en environnement urbain. Étant donné qu’avec le fort développement des SIG, les bases de données vectorielles sont devenues de plus en plus nombreuses (et souvent accessibles en tant que l’Open Data - données librement réutilisables), il serait envisageable de s’en servir lors du processus de qualification. Nous avons donc démontré notre hypothèse avancée tout au début de ce manuscrit. 7.2 Perspectives et futurs travaux Au terme de ce travail, nous pouvons envisager plusieurs pistes de recherche qui mériteraient d'être approfondies. Tout d'abord, il pourrait être intéressant de comparer notre méthode d’extraction des composantes connexes non seulement avec d’autres algorithmes récursifs de parcours d’un graphe (DFS, BFS), mais aussi avec la méthode aboutissant à convertir un nuage de points 3D en image 2D. Puisque la justesse et le nombre de segments extraits par notre algorithme sont liés à la qualité de plans détectés auparavant, il paraîtrait aussi nécessaire de rendre l’étape de segmentation en plans encore plus efficace. Cette remarque est surtout pertinente quand les données peu denses sont traitées. L’une des solutions possibles serait de diviser un nuage en petits blocs et d’y exécuter l’algorithme proposé. Étant donné que la distance moyenne LHD évaluant la qualité des nuages à partir de deux ensembles de segments non seulement représente l’exactitude, mais aussi l’erreur survenue lors de la procédure d’extraction des arêtes, il serait judicieux de caractériser son apport à la grandeur de qualité obtenue. Enfin, d'autres voies de recherche peuvent être favorisées, telles que l’étalonnage extrinsèque basé sur des lignes. Des solutions adéquates aux scanners laser à double balayage (3D), mais aussi celles dédiées aux scanners de profil 2D devraient être avancées. 7.2.1 Étalonnage extrinsèque du système : esquisse de solution Concernant l’étalonnage extrinsèque du système mobile doté d’un scanner 3D, nous présentons une étude théorique, exigeant d’être encore approfondie et testée sur des données réelles. Aussi, la précision des paramètres obtenus de cette façon devrait être confrontée avec d’autres méthodes. En revanche, si le système mobile commercial est étalonné, une comparaison avec l’étalonnage renseigné par le fabricant sera appréciée. Nous cherchons une solution pour laquelle aucun déploiement antérieur de cibles n’est demandé. Une seule contrainte est de balayer un endroit riche en entités linéaires orientées différemment. La référence fiable ܺோாி ெ peut être établie après l’acquisition. Outre, des arêtes de pli doivent être extraites à partir du nuage mobile et comparer par la suite avec celles de référence. Nous supposons que les données de trajectographie sont bonnes et le nuage de points lié au repère scanner ܺ௟௔௦௘௥ est fiable (étalonnage intrinsèque connu). Nous nous référons, pour passer du repère laser (s) aux coordonnées terrain (M), à la formule (2.1) du géo-référencement direct qui s’écrit en coordonnées homogènes : CHAPITRE 7. Perspectives et conclusion 137 ܺெ ൌ Ƭ௕ ெ ∙ Ƭ௦ ௕ ∙ ܺ௟௔௦௘௥ (7.1) où : Ƭ௕ ெ ൌ ൤ܴ௕ ெ ݎ௕/ீேௌௌ ெ 0 1 ൨ ସ௫ସ : position et altitude de l’unité inertielle IMU dans un repère terrain (M), connues grâce à la fusion GNSS/INS ; Ƭ௦ ௕ ൌ ൤ܴ௦ ௦/௕ݎ ௕ ௕ 0 1 ൨ ସ௫ସ : position et altitude du scanner laser dans le repère IMU (b), les paramètres d’étalonnage extrinsèque comprenant la matrice de boresight ܴ௦ ௕ et le bras de levier ݎ௕/௦ ௕ ; ܺ௟௔௦௘௥ : points laser dans le repère capteur (s) en coordonnées homogènes ሾܺ, ܻ, ܼ, 1ሿ௧ Sur cette base, la formule pour passer des données laser ܺ௟௔௦௘௥ au repère IMU (b) est suivante : ܺூெ௎ ൌ Ƭ௦ ෢௕ ∙ ܺ௟௔௦௘௥ (7.2) Le nuage de points est généré, en tenant compte des valeurs initiales d’étalonnage extrinsèque ݏƬ ෡ܾ assez proche de celui que l’on cherche à déterminer. Nous visons ensuite à raffiner ces paramètres à travers une comparaison avec des données extérieures au système d’acquisition. En admettant que nous disposions d’une référence ܺோாி ெ plus précise que le nuage mobile, et dont les coordonnées sont connues dans un repère global (M), sa position dans le repère IMU (b) se calcule comme suit : ܺோாி ௕ ൌ ሺƬ௕ ெሻିଵ ∙ ܺோாி ெ (7.3) Par conséquent, plus les deux nuages ܺூெ௎ et ܺோாி ௕ sont proches, plus l’étalonnage extrinsèque Ƭ௦ ෢௕ est bon. Puisqu’ils représentent la même scène, nous pouvons déterminer les paramètres de transformation rigide du nuage ܺூெ௎ au nuage ܺோாி ௕ . À cet effet, nous suggérons d’effectuer un ajustement de deux ensembles de lignes à l’aide de l’algorithme de recalage proposé dans la section précédente : ܴܯܮܴ െ ܫܫܯܨଶ. Néanmoins, rien d’empêche d’utiliser un autre algorithme semblable à l’ICP. En sortie, nous obtenons toujours une matrice de rotation ܴ et un vecteur de translation ܶ permettant de rapprocher, de manière optimale, des données : ܺோாி ௕ ൌ ߜƬ ∙ ܺூெ௎ (7.4) où ߜƬ ൌ ቂܴ ܶ 0 1ቃ ସ௫ସ . De l’autre côté, si nous connaissions de vrais paramètres d’étalonnage Ƭ௦ ௕ , la position des données laser dans le repère IMU (b) devrait coïncider à celle de référence : ܺோாி ௕ ൌ Ƭ௦ ௕ ∙ ܺ௟௔௦௘௥ (7.5) En tant que les formules (7.4) et (7.5) déterminent la même grandeur, nous arrivons à formuler la relation : ߜƬ ∙ ܺூெ௎ ൌ Ƭ௦ ௕ ∙ ܺ௟௔௦௘௥ (7.6)138 En remplaçant, dans la formule (7.6), les coordonnées du nuage de points liées au repère IMU par (7.2), nous obtenons : ߜƬ ∙ Ƭ௦ ෢௕ ∙ ܺ௟௔௦௘௥ ൌ Ƭ௦ ௕ ∙ ܺ௟௔௦௘௥ (7.7) Allons plus loin, la dépendance entre l’étalonnage extrinsèque initial et celui recherché est exprimée par : ߜƬ ∙ Ƭ௦ ෢௕ ൌ Ƭ௦ ௕ (7.8) La formule (7.8) peut s’écrire également sous forme matricielle : ቂ ܴ ܶ 0 1ቃ ସ௫ସ ∙ ቈܴ௦ ෢௕ ݎ௦/௕ ෢௕ 0 1 ቉ ସ௫ସ ൌ ൤ܴ௦ ௕/௦ݎ ௕ ௕ 0 1 ൨ ସ௫ସ (7.9) Nous en déduisons, par multiplication de matrices, que les valeurs initiales ቀܴ௦ ෢௕, ݎ௕/௦ ෢௕ ቁ de l’étalonnage extrinsèque pris en compte au départ doivent être corrigées de la manière suivante : ܴ௦ ௕ ൌܴ∙ܴ௦ ෢௕ (7.10) ௕/௦ݎ ௕ ൌܴ∙ݎ௦/௕ ෢௕ ൅ ܶ La Figure 7.2 récapitule toutes les démarches de la procédure proposée qui mènent à déterminer l’étalonnage extrinsèque du système en partant de ses valeurs approchées. L’idée consiste alors à effectuer des scans avec un scanner laser 3D travaillant en mode statique et monté sur la plate-forme mobile. Les acquisitions depuis plusieurs points de vue ou bien encore au sein de différentes zones, sont prévues à réaliser pour améliorer la précision des résultats. Ensuite, la moyenne des paramètres calculés indépendamment lors de chaque stationnement décrit l’étalonnage extrinsèque ൫ܴ௦ ௕/௦ݎ ,௕ ௕ ൯ (7.10). Conceptuellement, une telle approche peut être alors assimilée au procédé « 2-step » étalonnant les systèmes mobiles basés sur des caméras. Figure 7.2 Organigramme de l’approche envisagée. Paramètres recherchés : ܴ௦ ௕/௦ݎ ,௕ ௕139 0 Publications 7. Publications Publications dans des revues avec comité de lecture et dans des conférences avec actes o Articles liés à la thèse : Poreba M., Goulette F., 2014. A linear feature-based solution for robust and accurate registration of point clouds. Sensors (en cours de soumission). Poreba M., Goulette F., 2014. Recalage rigide de relevés laser par mise en correspondance robuste basée sur des segments. Revue Française de Photogrammétrie et de Télédétection RFPT, vol.207, (accepté). ↦ Deuxième Prix Étudiant du meilleur article soumis en 2013 à la RFPT, décerné par la Société Française de Photogrammétrie et de Télédétection (SFPT) Poreba M., Goulette F., 2013. Line Segment-based Approach for Accuracy Assessment of MLS point clouds in Urban Areas. Conference Proceedings of the 8th International Symposium on Mobile Mapping Technology MMT 2013, 1-3 May, Tainan, Taïwan. ↦ Prix internationaux du Best Student Paper Award et du Best Presentation Award Poreba M., Goulette F., 2012. RANSAC algorithm and elements of graph theory for automatic plane detection in 3D point clouds. Archives of Photogrammetry, Cartography and Remote Sensing, vol. 24, pp.301-310. Poreba M., Goulette F., 2012. Assessing the Accuracy of Land-Based Mobile Laser Scanning Data. Geomatics and Environmental Engineering, vol. 6/3, pp.83-91. Pyka K., Borowiec N., Poreba M., Slota M., Kundzierewicz T., 2012. Airborne laser scanning data for railway lines survey. PAK Measurement Automation and Monitoring, vol.58, pp.260-263. 140 o Articles antérieurs : Poreba M., 2011. Use of integrated GPS and INS systems in aerial photogrammetry. Geomatics and Environmental Engineering, vol.5, no.3, pp.79-87. Poreba M., 2009. Modern methods of earth mass volume determination. Archives of Photogrammetry, Cartography and Remote Sensing, vol.19, pp.351-361. Séminaires sans actes Marcotegui, B., Serna, A., Goulette, F., Poreba, M., Frauciel, L., Mittet, M.A., Rialland, S., Benjemaa, R., Hervieu, A., Soheilian, B., Paparoditis, N., 2013. TerraMobilita : urban scene analysis. 13th International Scientific and Technical Conference « From imagery to map: digital photogrammetric technologies », 23-26 September 2013, Fontainebleau, France. Poreba, M., Goulette, F., 2013. Registration of 3D point clouds using extracted line segments. VIII Colloque national en Géomatique intitulé «Géo - informatique comme un outil intégré d’analyses spatiales », 11-13 Septembre 2013, Université de Varsovie, Varsovie, Pologne. Poreba, M., Goulette, F., 2012. Extraction d’arêtes et comparaison avec des données de référence pour la qualification de relevés laser mobiles, Journée du GDR ISIS, Thème B – Analyse de scènes en image et vision, 8 Novembre 2012, Télécom ParisTech, Paris, France. 141 0 Bibliographie 0. Bibliographie Abbas, I., Grussenmeyer, P., Hottier, P., 1995. Contrôle de la planimétrie d’une base de données vectorielles : une nouvelle méthode basée sur la distance de Hausdorff : la méthode du contrôle linéaire. Revue de la Société Française de Photogrammétrie et de Télédétection (1995-1), n°137, ISSN 0244-6014, pp. 6-11. Abuhadrous, I., 2005. Système embarqué temps réel de localisation et de modélisation 3D par fusion multi-capteur. Thèse de Doctorat, MINES ParisTech. Al-Durgham, M., Detchev I., Habib, A., 2011. Analysis of Two Triangle-Based MultiSurface Registration Algorithms of Irregular Point Clouds. International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVIII-5/W12, pp.61-66. Alshawa, M., 2006. Consolidation des nuages de Points en Lasergrammétrie Terrestre. Thèse de Master, École Nationale Supérieure d’Architecture de Nancy. Alshawa, M., 2010. Contribution à la cartographie mobile : développement et caractérisation d’un système base sur un scanner laser terrestre. Thèse de Doctorat, INSA Strasbourg. Arun, K.S., Huang, T.S., Blostein, S.D., 1987. Least-Squares Fitting of Two 3-D Point Sets. IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 9, No.5. pp. 698-700. Atanacio-Jiménez, G., Gonzalez-Barbarosa, J-J., Hurtado-Ramos, J.B., Ornelas-Rodriguez, F.J., Jiménez-Hernandez, H., Garcia-Ramirez, T., Gonzalez –Barbarosa, R., 2011. LIDAR Velodyne HDL-64E Calibration Using Pattern Planes. International Journal of Advanced Robotic Systems, vol.8, no.5, pp.70-82. Awwad, T. M., Zhu, Q., Du, Z., Zhang, Y., 2010. An improved segmentation approach for planar surfaces from unstructured 3D point clouds. The Photogrammetric Record, 25(129), pp. 5-23. Babu, R., Wang, J., 2005. Ultra-Tight GPS/INS/PL integration: a system concept and performance analysis. GPS Solution, vol.13, pp.75-82. Barber, D., Mills, J., 2008. Geometric validation of a ground-based mobile laser scanning system. ISPRS Journal of Photogrammetry & Remote Sensing, Vol. 63, pp.128-141. 142 Bauer, J., Karner, K., Schindler, K., Klaus, A., Zach, C., 2005. Segmentation of building from dense 3D point-clouds. Proceedings of the ISPRS Workshop Laser scanning, September 12- 14, Enschede, Netherlands. Belton, D., Mooney, B., Snow, T., Kwang-Ho, B., 2011. Automated Matching of Segmented Point Clouds to As-built Plans. Proceedings of the Surveying & Spatial Sciences Biennial Conference, 21-25 November, Wellington, New Zealand. Benhabiles, H., Vanderborr, J-P., Lavoué, G., Daoudi, M., 2009. Une collection de modèles 3D avec vérité – terrain pour l’évaluation des algorithmes de segmentation. Proceedings of CORESA (COmpression et REpresentation des Signaux Audiovisuels), 19-20 mars 2009, Toulouse, France. Besl, P.J., McKay, N.D., 1992. A method for registration of 3-D shapes. IEEE Transactions of Pattern Analysis and Machine Intelligence, vol. 14, no. 2, pp.239-256. Bienert, A., 2008. Vectorization, Edge Preserving Smoothing and Dimensioning of Profiles in Laser Scanner Point Clouds. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVII, part. B5, pp. 507-512. Bitenc, M., Lindenbergh, R., Khoshelham, K., van Waarden, A.P., 2011. Evaluation of a LIDAR Land-Based Mobile Mapping System for Monitoring Sandy Coasts. Remote Sensing, vol. 3, pp. 1472-1491. Boehler, W., Bordas, V., Marbs, A., 2003. Investigating laser scanner accuracy. Proceedings of the XIXth CIPA Symposium, 30 September – 4 October, Antalya, Turkey. Borowiec, N., 2009. Generowanie trójwymiarowego modelu budynku na podstawie danych lidarowych. Archiwum Fotogrametrii, Kartografii i Teledetecji, vol. 20, pp.47-56. Borowiec, N., 2012. Transformata Hough’a jako narzedzie wspomagające wykrywanie dachów budynków. Archiwum Fotogrametrii, Kartografii i Teledetekcji, vol. 25, pp.45-54. Borrmann, D., Elseberg, J., Lingemann, K., Nüchter, A., 2011. The 3D Hough Transform for Plane Detection in Point Clouds: A Review and a new Accumulator Design. 3D Research, vol. 02, pp.1-13. Boudet, L., 2007. Auto-qualification de données géographiques 3D par appariement multiimage et classification supervisée. Application au bâti en milieu urbain dense. Thèse de doctorat, Université Paris-EstMarne-la-Vallée. Bouillaguet, Ch.,. 2011. Algorithmique et Programmation. Projet :permutations de matrices creuses et décompositions de graphes Cours en-ligne, École Nationale Supérieure : http://www.lifl.fr/~bouillag/teaching/ens_2011/sparse1.pdf Boulaassal, H., 2010. Segmentation et modélisation géométrique de façades de bâtiments à partir de relevés laser terrestres. Thèse de Doctorat, INSA Strasbourg. Brabant, M., 2011. In : Topographie opérationnelle: Mesure – Calculs – Dessins - Implémentations. Editeur Eyrolles. Bretar, F., Roux, M., 2005. Hybrid image segmentation using lidar 3D planar primitives. Proceedings of ISPRS Workshop Laser scanning, September 12-14, Enschede, the Netherlands, 2005, pp 72-78. Bykat, A., 1978. Convex hull of a finite set of points in two dimensions. Information Processing Letters, vol. 7, pp.296–298. Bibliographie 143 Cahalane C., McCarthy, T., McElhinney, C., 2010. Mobile mapping system performance – an initial investigation into the effect of vehicle speed on laser scan lines, RSPSoc no.2005. Canaz, S., Habib, A., 2013. Planar and linear feature –based registration of terrestrial laser scans with minimum overlap using photogrammetric data. Proceedings of the 8th International Symposium on Mobile Mapping Technology, 1-3 May, Tainan, Taiwan. Cannelle, B., Paparoditis, N., Pierrot-Deseilligny, M., Papelard, J-P., 2012. Off-line vs. Online calibration of a panoramic-based mobile mapping system. ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. I-3, pp. 31-36. Castillo, E., Zhao, H.,2009. Point Cloud Segmentation via Constrained Nonlinear Least Squares Surface Normal Estimates. Computational Geometry. Cazzaniga, N.E., Fornali, G., Roncella, R., 2007. Improving the reliability of a GPS/INS Navigation Solution for MM Vehicles By Photogrammetry. Proceedings of the 5th International Symposium on Mobile Mapping Technology, Padua, Italy. Chan, T. O., Lichti, D. D., Feature-based self-calibration of Velodyne HDL-32E LiDAR for terrestrial mobile mapping applications. 2013. Proceedings of the 8th International Symposium on Mobile Mapping Technology, 1-3May, Tainan, Taiwan. Chan, T-O., Lichti, D.D., Glennie, C.L., 2013. Multi-feature based boresight self-calibration of a terrestrial mobile mapping system. ISPRS Journal of Photogrammetry and Remote Sensing, vol. 82, pp.112-124. Chen, C., Hung, Y., Cheng, J., 1999. RANSAC-based DARCES: A New Approach to Fast Automatic Registration of Partially Overlapping Range Image. IEEE Transactions on Pattern Analysis and Machine Intelligence, vol.21, no. 11, pp.1229-1234. Chen, J., Leung, M.K., Gao, Y., 2003. Noisy logo recognition using line segment Hausdorff distance. The Journal of the Pattern Recognition Society, vol.36, pp.943-955. Chen, Y., Medioni, G., 1992. Object modelling by registration of multiple range images. Image Vision Computing, vol. 10(3), pp.145-155. Chen, Y-Ch., Tseng, Y-H., Wang, P-Ch., 2013. The calibration of a portable panoramic image mapping system. Proceedings of the 8th International Symposium on Mobile Mapping Technology, Mai 1-3, Tainan, Taiwan. Choi, W-P., Lam, K-M., Siu, W-Ch., 2001. A robust Line-Feature-Based Hausdorff Distance for Shape Matching. Proceedings of Advances in Multimedia Information Processing – PCM 2001, Second IEEE Pacific Rim Conference on Multimedia, 24-26 Octobre, Bejing, Chine, pp.764-771. Cormen, T., Leiserson, Ch., Rivest, R., Stein, C., 2001. Introduction à l’algorithmique. Cours et exercices. The Massachusetts Institute of Technology, 2e édition. pp.1-1176. Guan, H., Li, J., Yu, Y., Wang, Ch., 2013. Geometric validation of a mobile laser scanning system for urban applications. Proceedings of the 8th International Symposium on Mobile Mapping Technology, 1-3 May, Tainan, Taiwan. Delmerico, J.A., David, P., Corso, J.J., 2011. Building Facade Detection, Segmentation, and Parameter Estimation for Mobile Robot Localization and Guidance, Proceedings of the International Conference of Intelligent Robots and System (IROS)., pp.1632-1639. 144 Demarsin, K., Vanderstraeten, D., Volodine, T., Roosea, D., 2007. Detection of closed sharp edges in point clouds using normal estimation and graph theory. Computer-Aided Design, vol. 39, pp.276-283. Deschaud, J-E., 2010. Traitement de nuages de points denses et modélisation 3D d’environnements par système mobile LiDAR/Caméra. Thèse de Doctorat, MINES ParisTech. Douadi, L., 2006. Contribution à l’étude du recalage de données 3D/couleur. Thèse de doctorat, Université Montpellier II. Dubuisson, M.P., Jain, A.K., 1994. A modified Hausdorff distance for object matching. Proceedings 12th International Conference on Pattern Recognition, Jerusalem, Israel, pp.566-568. Duda, R.O., Hart, P.E., 1971. Use of the Hough Transformation to Detect Lines and Curves in Pictures. Technical Note 36, Artificial Intelligence Center, SRI International. Feng, J., Zhong, R., Yang, Y., Zhao, W., 2008. Quality Evaluation of Spatial Point-Cloud Data Collected by Vehicle-Borne Laser Scanner. International Workshop on Education and Training & International Workshop on Geosciences and Remote Sensing. Dulmage, A.L., Mendelsohn, N.S., 1958. Coverings of bipartite graphs. Canadian Journal of Mathematics, vol.10, pp. 517–534. Ellum, C., El-Sheimy, N., 2002. The calibration of Image-Based Mobile Mapping Systems. Proceedings of the 6th Conference on Optical 3D Measurements Techniques, September 22- 25, Zurich, Swiss. Ellum, C., El-Sheimy, N., 2003. Investigations in boresight and lever-arm calibration. Elsbourg, J., Borrmann, D., Nüchter, A., 2013. Automatic and Full Calibration of Mobile Laser Scanning Systems. Experimental Robotics, Springer Tracts in Advanced Robotics, Vol.88, part. XIII, pp.907-917. El-Sheimy, N., 2011. Land-based MMT: State of the Art and Future Trends. Proceedings of the 7th International Symposium on Mobile Mapping Technology, June 13-16, Cracow, Poland. Evans, S., 2013. 3D Laser Scanning Market Continues Trend of Robust Growth. Publication en-ligne : http://www.arcweb.com/press-center/2013-07-11/3d-laser-scanning-market-continuestrend-of-robust-growth-1.aspx (accessible le 16.04.2014). Feng, J., Zhong, R., Yang, Y., Zhao, W., 2008. Quality Evaluation of Spatial Point-Cloud Data Collected by Vehicle-Borne Laser Scanner. Proceedings of the International Workshop on Education and Training & 2008 International Workshop on Geosciences and Remote Sensing, pp. 320-323. Filin, S., 2003. Recovery of systematic biases in laser altimetry data using natural surfaces. Photogrammetric Engineering and Remote Sensing, vol.69(11), pp.1235-1242. Fischler, M.A. et Bolles, R.C., 1981. Random sample consensus: A paradigm for model fitting with applications to image analysis and automated cartography. Communications of the ACM, vol.24(6), pp.381-395. Fitzgibbon, A., 2001. Robust registration of 2D and 3D point sets. The British Machine Vision Conference. Frémont, V., 2009. Odométrie 3D vision/lidar pour les véhicules intelligents. Journées Nationales de la Recherche en Robotique, Neuvy-sur-Barangeon, France. Bibliographie 145 Gallo, O., Manduchi, R., Rafii, A., 2010. CC-RANSAC: Fitting planes in the presence of multiple surfaces in range data. Pattern Recognition Letters, vol. 32, pp. 403–410. Gandofi, S., Barbarelle, M., Ronci, E., Bruchi, A., 2008. Close photogrammetry and laser scanning using a mobile mapping system for high detailed survey of a high-density urban area. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol. XXXVII, part B5, pp.909-914. Gao, J., Sun, J., Wu, K., 2012. Image Matching Method Based on Hausdorff Distance of Neighborhood Grayscale. Journal of Information & Computational Science, vol.10, pp. 2855- 2863. Gao, Y., Leung, M.K., 2002. Line segment Hausdorff distance on face matching. The Journal of the Pattern Recognition Society, vol.35, pp.361-371. Gelfand, N., Ikemoto, L., Rusinkiewicz, Sz., Levoy, M., 2003. Geometrically Stable Sampling for the ICP Algorithm. 2003. Proceedings of the 4th International Conference on 3D Digital Imaging and Modeling (3DIM), pp.260-267. Ghanma, M., 2006. Integration of Photogrammetry and LIDAR. Thèse de doctorat, Université de Calagary, Canada. Glennie, C., 2007. Rigorous 3D error analysis of kinematic scanning LIDAR systems. Journal of Applied Geodesy, vol.1, pp.147-157. Glennie, C., 2012. Calibration and kinematic analysis of the Velodyne HDL-64E S2 LiDAR sensor. Photogrammetric Engineering and Remote Sensing, vol. 78(4), pp.339-347. Graham, R.L., 1972. An Efficient Algorithm for Determining the Convex Hull of a Finite Planar Set. Information Processing Letters, vol. 1, pp.132-133. Grejner-Brzezinska, D., Toth, Ch., 2010. High-Accuracy Multi-Sensor Geolocation Technology to Support Geophysical Data Collection at MEC Sites. Final Report SERDP Project MR-1564 Gressin, A., Mallet, C., David, N., 2012. Improving 3D LIDAR point cloud registration using optimal neighborhood knowledge. ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. I-3, pp. 111-116. Gressin, A., Mallet, C., Damantké, J., David, N., 2013. Towards 3D lidar point cloud registration improvement using optimal neighborhood knowledge. ISPRS Journal of Photogrammetry and Remote Sensing, vol. 79, pp. 240-251. Gruen, A., Akca, D., 2005. Least squares 3D surface and curve matching. ISPRS Journal de Photogrammetry and Remote Sensing, vol.59(3), pp.151-174. Grussenmeyer, P., Hottier, P., Abbas, I., 1994. Le contrôle topographique d’une carte ou d’une base de données constituées par voie photogrammétrique. Revue de l’Association Française de Topographie, XYZ 2e trim. 1994 N°59, ISSN 0290-9057, pp. 39-45. Guerra, C., Pascucci, V., 1999. On matching Sets of 3D Segments. Proceedings SPIE, vol. 3811, pp.157-167. Haala, N., Peter, M., Kremer, J., Hunter, G., 2008. Mobile LIDAR Mapping for 3d point cloud collection in urban areas – a performance test. Proceedings of XXIth ISPRS Congress. 146 Habib, A.F., Ghanma, M.S., Tait, M., 2004. Integration of LIDAR and photogrammetry for close range applications. ISPRS Proceedings of XXth Congress, July12-23, Istanbul, Turkey. Habib, A., Bang; K., Kersting, A.P., Chow, J., 2010. Alternatives methodologies for LiDAR system calibration. Remote Sensing, vol.2, pp.874-907. Habib, A.F., Kersting, A.P. Shaker, A., Yan, W-Y., 2011. Geometric Calibration and Radiometric Correction of LiDAR Data and Their Impact on the Quality of Derived Products. Sensors, vol.11, pp.9069-9097. Hanke, K., Grussenmeyer, P., Grimm-Pitzinger, A., Weinold, T., 2006. First Experiences with Trimble GX Scanner. International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVI, part 5. Harris, C., Stephens, M.A., 1988. A Combined Corner and Edge Detector. Proceedings of 4th Alvey Vision Conference, pp. 147-151. Hartley, R., Zisserman, A., 2003. Multiple view geometry in computer vision. Cambrige University Press, Second edition, pp.117-121. Hassan, T., El-Sheimy, N., 2008. System calibration of land-based mobile mapping systems. Proceedings of the International Calibration and Orientation Workshop EuroCOW 2008, 30 January-1 February, Castelldefels, Spain. Hernandez, J., Marcotegui, B., 2008. Segmentation de Nuages de Points pour la Modélisation d’Environnement Urbains. Revue Française de Photogrammétrie et de Télédétection, vol.191, pp.28-35. Hiremagalur, J., Yen, K.S., Lasky, T.A., Ravani, B., 2009. Testing and Performance Evaluation of Fixed Terrestrial 3D Laser Scanning Systems for Highway Applications. Transportation Research Board TBR 88th Metting CD-ROM, pp. 1-19. Hough, P.C.V., 1962. Method and Means for Recognizing Complex Patterns. US Patent 3.069.654. Huh, Y., Yang, S., Ga, Ch., Yu, K., Shi, W., 2013. Line segment confidence region-based string matching method for map conflation. ISPRS Journal of Photogrammetry and Remote Sensing, vol.78, pp.69-84. Hullo, J-F., 2013. Consolidation de relevés laser d’intérieurs construits : pour une approche probabiliste initialisée par géolocalisation. Thèse de doctorat, Université de Strasbourg. Huttenlocher, D.P., Klanderman, G.A., Kl, G.A, Rucklifge, W.J., 1993. Comparing Images Using the Hausdorff Distance. IEEE Transactions on Pattern Analysis and Machine Intelligence, vol.15, pp. 850-863. Jarvis, R. A., 1973. On the identification of the convex hull of a finite set of points in the plane. Information Processing Letters vol.2, pp.18–21. Jarzabek-Rychard, M., Borkowski, A., 2010. Porównanie algorytmów RANSAC oraz rosnacych płaszczyzn w procesie segmentacji danych z lotniczego skaningu laserowego. Archiwum Fotogrametrii, Kartografii i Teledetecji, vol. 21, pp.119-129. Jaw, J-J., Chuang, T-Y., 2008. Registration of ground-based LIDAR point clouds by means of 3D line features. Journal of the Chinese Institute of Engineers, vol. 31, no. 6, pp.1031- 1045. JCGM 200 :2012. Vocabulaire international de métrologie – Concepts fondamentaux et généreux et termes associés (VIM), BIPM, pp.18-28. Bibliographie 147 Jibrini, H., 2002. Reconstruction automatique des bâtiments en modèles polyédriques 3-D à partir de donnés cadastrales vectorisées 2D et d’un copule d’images aériennes à haute résolution. Thèse de doctorat de Télécom Paris. Kaartinen, H., Hyyppä, J., Kukko, A., Jaakkola, A., Hyyppä, H., 2012. Benchmarking the Performance of Mobile Laser Scanning Systems Using a Permanent Test Field. Sensors, vol. 12, pp. 12814-12835. Kamgar-Parsi, B., Kamgar-Parsi, B., 1997. Matching Sets of 3D Line Segments with Application to Polygonal Arc Matching. IEEE Transactions on Pattern Analysis and Machine Intelligence, vol.19, No. 10. Kamgar-Parsi, B., Kamgar-Parsi, B., 2004. Algorithms for Matching 3D Line Sets. IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 26, No.5. Klimkowska, H., Wróbel, A., 2006. Uwagi o wykorzystaniu Tachymetrów Bezlustrowych w Inwentaryzacji Architektonicznej (Some Remarks Concerning the Use of Reflector less Total Stations for Architectural Recording). Archiwum Fotogrametrii, Kartografii i Teledetekcji, vol.16, pp.297-303. Kumari, P., Carter, W.E., Shrestha, R.L., 2011. Adjustment of systematic errors in ALS data through surface matching. Advances in Space Research, vol.47, pp. 1851-1864. Landes, T., Grussenmeyer, P., 2011. Les principes fondamentaux de la lasergrammétrie terrestre : systèmes et caractéristiques. Revue XYZ, no. 128/3, pp.37-49. Landes, T., Grussenmeyer, P., Boulaassal, H., 2011. Les principes fondamentaux de la lasergrammétrie terrestre : acquisition, traitement des données et applications. Revue XYZ, no. 129/4, pp.25-38. Landes, T., Boulaassal, H., Grussenmeyer, P., 2012. Quality Assessment of geometric façade models reconstructed from TLS data. The Photogrammetric Record, no. 27(138), pp.137- 154. Lari, Z., Habib, A.F., Kwak, E., An adaptive approach for segmentation of 3D laser point clouds. International Archives of Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVIII-5/W12, pp.103-108. Latulippe, M., 2013. Calage robuste et accéléré de nuages de points en environnements naturels via l’apprentissage automatique. Thèse de Master, Université Laval, Québec, Canada. Lee, D., Kim, Y., Bang, H., 2013. Vision-based Terrain Referenced Navigation for Unmanned Aerial Vehicles using Homography Relationship. Journal of Intelligent and Robotic Systems, vol.69(1-4), pp. 489-497. Levinson, J.S., 2011. Automatic laser calibration, mapping, and localization for autonomous vehicles. Thèse de Doctorat, Stanford Artificial Intelligence Laboratory. Li, W., Li, X., Bian, Y., Zhao, H., 2012. Multiple View Point Cloud Registration Based on 3D Lines. Proceedings of the 2012 International Conference on Image Processing, Computer Vision & Pattern Recognition, Las Vegas, USA. Li-Chee-Ming, J., Armenakis, C., Lee, R., 2011. Mobile Stereo-Mapper: a Portable Kit for Unmanned Aerial Vehicles. International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVIII-1/C22, pp.1-6. 148 Liao, H-M., Liu, H-S., Chen, C., 2013. Develop Backpack Mobile Mapping System Based on Open Source Software and Hardware Platform. Proceedings of the 8th International Symposium on Mobile Mapping Technology, 1-3 May, Tainan, Taiwan. Lowe, D.G., 2004. Distinctive image features from scale – invariant key points. International Journal of Computer Vision, vol.60(2), pp.91-110. Mano, K., Ishii, K., Hirao, M., Tachibana, K., Yoshimura, M., Akca, D., Gruen, A., 2012. Empirical accuracy assessment of MMS Laser point clouds. International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXIX-B5, pp. 495-498. Masuda, T., Yokoya, N., 1995. A robust Method for Registration and Segmentation of Multiple Range Images. Computer Vision and Image Understanding, vol. 16, no.3, pp.295- 307. Monnier, F., Vallet, B., Paparoditis, N., Papelard, J-P., David, N., 2013. Mise en cohérence de données laser mobile sur un modèle cartographique par recalage non-rigide. Revue Française de Photogrammétrie et de Télédetection, no. 202, pp.27-41. Narayana, K.S., 2011. Solutions for the localization of Mobile Mapping Systems in structured environments. Thèse de Doctorat, MINES ParisTech. Newby, P. R. T., 2011. Editorial: Accuracy, precision, extraction, citation and valediction. The Photogrammetric Record, 26(134): 149-153. Ning, F-S., Kao, S-P., Chang, Ch-Ch, Meng, X., 2007. A simulation of the effect of GPS Pseudolite observations on the obstructed sky view. Survey Review, vol. 39, pp.34-42. Oehler, B., Stueckler, J., Welle, J., Schulz, D., Behnke S., 2011. Efficient Multi-Resolution Plane Segmentation of 3D Point Clouds. Proceedings of the 4th International Conference on Intelligent Robotics and Applications (ICIRA), Aachen, Germany. Paparoditis, N., Papelard, J-P., Cannelle, B., Devaux, A., Soheilian, B., Nicolas, D., Houzay, E., 2012. Stéréopolis II: A multi-purpose and multi-sensor 3D mobile mapping system for street visualization and 3D metrology. Revue Française de Photogrammetry et de Télédetection, pp.69-79. Pawleta, M., Igielska, A., 2009. Analiza dokładnosci wybranych modeli naziemnych skanerów laserowych. Thèse de Master, AGH de Cracovie. Pesci, A., Teza, G., 2008. Effects of surface irregularities on intensity data from laser scanning: an experimental approach. Annals of Geophysics, vol. 51/1, pp.839-848. Poncelet, N., Cornet, Y., 2010. Transformée de Hough et détection de linéaments sur images satellitaires et modèles numériques de terrain. Bulletin de la Société Géographique de Liège, vol.54, pp.145-156. Poreba, M., Goulette, F., 2012. Assessing the Accuracy of Land-Based Mobile Laser Scanning Data. Geomatics and Environmental Engineering, vol.6, no. 3, pp.73-81. Pothen, Al., Fan, Ch-J., 1990. Computing the Block Triangular Form of a Sparse Matrix. ACM Transactions on Mathematical Software, vol.16, no.4, pp.303-324. Pulli, K., 1999. Multiview Registration for Large Data Sets. Proceedings of the International Conference on 3D Digital Imaging for the ICP Algorithm (3DIM), Ottawa, pp. 160-168. Bibliographie 149 Rabbani, T., van den Heuvel, F. A., Vosselman, G., 2006. Segmentation of Point Clouds using Smoothness Constraint. ISPRS Commission V Symposium on Image Engineering and Vision Metrology, pp.248-253. Rau, J-Y., Habib, A.F., Kersting, A.P., Chiang, K-W., Bang, K-I., Tseng, Y-H., Li, Y-H., 2011a. Direct Sensor Orientation of a Land-Based Mobile Mapping System. Sensors, vol.11, pp. 7243-7261. Rau, J-Y., Chen, L-Ch., Hsieh, Ch-Ch., Huang, T-M., 2011b. Static error budget analysis for a land-based dual-camera mobile mapping system. Journal of the Chinese Institute of Engineers, vol. 34, no. 7, pp.849-862. Ray, J.A., Graham, L., 2008. New horizontal accuracy assessment tools and techniques for LIDAR data. Proceedings of the ASPRS Annual Conference, Portland, Oregon. Reichle, R.H., 2008. Data assimilation Methods in the Earth sciences. Advances in Water Resources, vol.31, no.11, pp.1411-1418. Renaudin, E., Habib, A., Kersting, A.P., 2011. Feature-Based Registration of Terrestrial Laser Scans with Minimum Overlap Using Photogrammetric Data. ETRI Journal, vol. 33, no. 4, pp.517-527. Ridene, T., 2010. Co-recalage de données hétérogènes 3D géo-référencées: contributions à la correction de relevés laser mobiles. Thèse de doctorat, MINES ParisTech. Rieger, P., Studnicka, N., Pfennigbauer, M., Zach, G., 2010. Boresight alignment method for mobile laser scanning systems. Journal of Applied Geodesy, vol. 4, pp. 13-21. Rusinkiewicz, Sz., Levoy, M., 2001. Efficient Variants of the ICP Algorithms. Proceedings of the International Conference on 3D Digital Imaging and Modeling (3DIM), Québec, Canada, pp.145-152. Shear, P., In-flight Quality Assessment and Data Processing for Airborne Laser Scanning. Thèse de Doctorat, École Polytechnique Fédérale de Lausanne. Sappa, A., Restrepo-Specht, A., Devy, M., 2001. Range Image Registration by using an Edge-based Representation. Proceedings of the 9th International Symposium on Intelligent Robotic Systems (SIRS’01), Toulouse, France, pp.167-176. Sarni D., Lemarchande L., 2011. Graphes, Université de Brest, cours en-ligne http://www.lisyc.univ-brest.fr/pages_perso/lemarch/Cours/polyGraphes.pdf, pp.1-63. Selmi, I., 2013. Optimisation de de l'infrastructure d'un système de positionnement indoor à base de transmetteurs GNSS. Thèse de Doctorat, Télécom SudParis. Serna, A., Marcotegui, B., 2013. Urban accessibility diagnosis from mobile laser scanning data, ISPRS Journal of Photogrammetry and Remote Sensing, vol.84, pp.23-32. Shaer, P., 2010. In-Flight Quality Assessment and Data Processing for Airborne Laser Scanning. Thèse de doctorat, École Polytechnique Fédérale de Lausanne. Shi, Y., 2008. Advanced Mobile Mapping System Development with Integration of Laser Data, Stereo Image and other Sensor Data. Publication of Tokyo City University, no.10, pp. 24-31. Skaloud, J., Lichti, D.D., 2006. Rigorous approach to boresight self-calibration in airborne laser scanning. ISPRS Journal of Photogrammetry and Remote Sensing, vol. 61(1), pp.47-59. 150 Soria-Medina, A., Martinez, J., Buffara-Antunes, A.F., Arias, P., Gonzalez-Jorge, H., 2011. An approach to extracting façade features using the intensity value of terrestrial laser scanner with mathematical morphology. The 28th International Symposium on Automation and Robotics in Construction, Republic of Korea, pp.552-557. Soudarissanane, S., Lindenbergh, R., Menenti, M., Teunissen, P.J.G., 2009. Incidence angle influence on the quality of terrestrial laser scanning points. Proceedings of ISPRS Workshop Laser Scanning; Paris, France, vol. XXXVIII, part 3/W8, pp.183-188. Steiger, R., 2005. The Geometrical Quality of Terrestrial Laser Scanner (TLS). Proceedings of FIG Working Week, Egypt. Sunday, D., 2001. Distance between lines and segments with their closest point of approach. Technical report, en-ligne : http://geometryalgorithms.com. Talaya, J., Alamus, R., Bosch, E., Serra, A., Kornus, W., Baron, A., 2004. Integration of a Terrestrial Laser Scanner with GPS/IMU Orientation Sensors. Proceedings of the XX ISPRS Congress (Commission V), July 12-23, Istanbul, Turkey. Tangelder, J.W.H., Veltkamp, R.C., 2008. A survey of content based 3D shape retrieval methods. Multimedia Tools Applications, vol.39(3), pp.441-471. Tarsha-Kurdi, F., Landes, T., Grussenmeyer, P., 2007. Hough Transform and Extended RANSAC algorithms for automatic detection of 3D building roof planes from LIDAR data. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol.XXXVI, part 3/W52, pp.407-412. Tarsha-Kurdi, F., 2008. Extraction et reconstruction de bâtiments en 3D à partir de relevés lidar aéroportés. Thèse de doctorat, Université de Strasbourg. Titterton, D.H., Weston, J.L., 2004. Strapdown Inertial Navigation Technology – 2nd Edition. The institution of Electrical Engineering. 557 pages. Toth, C., Grejner-Brzezinska, D., Oh, J.H., Markiel, J.N., 2009. Terrain-based navigation: a tool to improve navigation and feature extraction performance of mobile mapping systems. Boletim de Ciências Geodésicas – Special Issue on Mobile Mapping Technology, vol. 15, no.5, p. 807-823. Tournaire, O., Soheilian, B., Paparoditis, N., 2006. Towards a sub-decimetric georeferencing of a ground-based mobile mapping systems in urban areas :matching ground-based and aerial-based imagery using road marks. Proceedings of the ISPRS Commission I Symposium, volume Part A, Marne-la-Vallée, France. Tuttas, S., Stilla, U., 2011. Window Detection In Sparse Point Clouds Using Indoor Points. International Archives of Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. 38(3/W22), pp. 131-136. Tuttas, S., Stilla, U., 2013. Reconstruction of façades in point clouds from multi-aspect oblique ALS. ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol.II-3/W3, pp.91-96. van Verth, J.M., Bishop, L.M., 2008. Essential Mathematics for Games & Interactive Applications. A programmer’s guide. Second Edition, (674 pages). Vervisch-Picois, A., 2010. Etude de Systèmes de Positionnement en Intérieur Utilisant des Mesures de Phase du Code ou de Phase de la Porteuse de Signaux de Navigation par Satellites. Thèse de Doctorat, Université Pierre et Marie Curie - Paris 6. Bibliographie 151 Vosselman, G., Gorte, B.G.H., Sithole, G., Rabbani, T., 2004. Recognizing structure in laser scanner point clouds. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVI, pp.33-38. Vosselman; G., Maas, H.G., 2010. Airborne and terrestrial laser scanning. Whittles Publishing, 2010 - Technology & Engineering, 318 pages. Wang, J., Dai, L., Tsujii, T., Rizos, Ch., 2001. GPS/INS/Pseudolite Integration: Concepts, Simulation and Testing. Proceedings of the 14th International Technical Meeting of the Satellite Division of the Institute of Navigation. Salt Lake City, UT, 11-14 September, 2708- 2715. Wang, J., Tan, Y., 2012. Hausdorff Distance with k-Nearest Neighbors. Advances in Swarm Intelligence, Third International Conference, ICSI, 17-20 Juin, Shenzhen, Chine, pp.272-281. Wang, R., Bach, J., Ferrie, F., 2011. Window Detection form Mobile LiDAR Data. IEEE Workshop on Applications of Computer Vision (WACV), 5-7 Janvier, Kona, Hawaii. Wang, W., Lou, A., Wang, J., 2012. The research of line matching algorithm under the improved homograph matrix constraint condition. International Archives of Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXIX-B3, pp. 345-350. Wang, Y., Ewert, D., Schilberg, D., Jeschke, S., 2013. Edge Extraction by Merging 3D Point Cloud and 2D Image Data. 10th International Conference & Expo on Emerging Technologies for a Smarter World (CEWIT), 21-22 Octobre, Melville, New York. Wang, Y., Ewert, D., Schilberg, D., Jeschke, S., 2014. A New Approach for 3D Edge Extraction by Fusing Point Clouds and Digital Images. Applied Mechanics and Materials, vol. 457-458, pp.1012-1016. Wiart, A., 2013. Calibration extrinsèque d’un scanner laser multi-fibre. Test sur le laser Velodyne. Rapport de stage de fin d’étude. MINES ParisTech & ENSG. Williams, K.E., 2012. Accuracy Assessment of LIDAR Point Cloud Geo-Referencing. These de Master, Oregon State University. Yang, M.Y., Forstner, W., 2010. Plane Detection in Point Cloud Data. Technical Report Nr.1, Department of Photogrammetry, Institute of Geodesy and Geoinformation, University of Bonn. Yao, J., Ruggeri, M.R., Taddei, P., Sequeira, V., 2010. Robust range image registration using 3D lines. Proceedings of 2010 IEEE 17th International Conference on Image Processing, September 26-29, Hong Kong, pp.4321-4324. Yong, L., Huayi, W., 2008. Adaptive building edge detection by combining Lidar data and aerial images. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVII, pp.197-202. Yoo, H-J., 2010. Analyse et conception de scanners laser mobiles dédiés à la cartographie 3D d’environnements urbains. Thèse de doctorat, MINES ParisTech. Yousif, H., Li, J., Chapman, M., Shu, Y., 2010. Accuracy enhancement of terrestrial mobile LIDAR data using theory of assimilation. IAPRS International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. XXXVIII, part.5, pp. 639-645. 152 Zampa, F., Conforti, D., 2009. Mapping with Mobile Radar. GIM International, vol. 23, no.4, pp.35-37. Zhang, Z., Faugeras, O.D., 1991. Determining Motion from 3D Line Segment Matches: a comparative Study. Journal Image and Vision Computing, vol. 9, no.1, pp.10-19. Zhang, Z., 1994. Iterative Point Matching for Registration of Free – Form Curves and Surfaces. International Journal of Computer Vision, vol. 13, pp.119-152. Zhu, Z., Liu, J., 2013 Unsupervised Extrinsic Parameters Calibration for Multi-beam LIDARs, Proceedings of the 2nd International Conference on Computer Science and Electronics Engineering, ICCSEE. Zuliani M., 2012. RANSAC for Dummies, Technical Report. en-ligne: http://vision.ece.ucsb.edu/~zuliani/Research/RANSAC/docs/RANSAC4Dummies.pdf153 Annexe A Distance minimale entre deux segments 0. Distance minimale entre deux segments Nous présentons dans cette annexe la méthode de [Sanday, 2001] permettant de déterminer la distance la plus courte entre deux segments. Puisqu’elle s’inspire de la définition de distance minimale entre deux lignes, nous commençons par expliquer son calcul. Soient ܮଵ, et ܮଶ deux droites représentées respectivement par les points ܲ଴, ܳ଴ et les vecteurs non nuls ݑሬԦ, ݒԦ (Figure A.1) : ܮଵ: ܲሺݏሻ ൌ ܲ଴ ൅ ݑݏሬԦ ܮଶ: ܳሺݐሻ ൌ ܳ଴ ൅ ݒݐԦ (A.1) Les paramètres ݏ஼ et ݐ஼ indiquent la localisation des deux points plus proches sur les lignes ܮଵ, et ܮଶ. Nous désignons par ݓሬሬԦ஼ le vecteur défini par les deux points ܲሺݏ஼ሻ et ܳሺݐ஼ሻ. Sa norme correspond à la distance minimale entre deux lignes (A.2). ݓሬሬԦ௖ ൌ ܲሺݏ஼ሻ െ ܳሺݐ஼ሻ (A.2) Figure A.1 Définition de la distance minimale entre deux segments de droite En remplaçant dans la formule (A.2) les points ܲሺݏ஼ሻ et ܳሺݐ஼ሻ par (A.1), nous obtenons : 154 ݓሬሬԦ஼ ൌ ݓ଴ ሬሬሬሬሬԦ ൅ ݏ஼ݑሬԦ െ ݐ஼ݒԦ (A.3) où ݓ଴ ሬሬሬሬሬԦ ൌ ሺܲ଴ െ ܳ଴ሻ. Par définition, le vecteur ݓሬሬԦ஼ doit être, à la fois, perpendiculaire à ܮଵ et ܮଶ tant qu’il représente la distance minimale entre ces deux lignes. Sachant que les deux vecteurs sont orthogonaux si est seulement si, leur produit scalaire est nul, nous notons : ൜ ሬݓሬሬሬሬ ஼Ԧ ∙ ݑሬԦ ൌ 0 ሬሬሬሬሬݓ ஼Ԧ ∙ ݒԦ ൌ 0 (A.4) En prenant en compte de l’équation (A.3), la formule (A.4) prend forme : ൜ ൌ 0 Ԧݒ ∙ Ԧሬݑ஼ݐ ሬԦ െݑ ∙ Ԧሬݑ஼ݏ ൅ Ԧሬݑ ∙ Ԧሬሬሬሬሬ ଴ݓ ൌ 0 Ԧݒ ∙ Ԧݒ஼ݐ െ Ԧݒ ∙ Ԧሬݑ஼ݏ൅Ԧݒ ∙ ଴Ԧሬሬݓ (A.5) La résolution de ce système d’équations linéaires à deux inconnues nous amène à déterminer les valeurs ݏ஼ et ݐ஼ de la manière suivante : ݏ௖ ൌ ܾ݁ െ ܿ݀ ܽܿ െ ܾଶ (A.6) ݐ௖ ൌ ܽ݁ െ ܾ݀ ܽܿ െ ܾଶ (A.7) pour les ܽ, ܾ, ܿ, ݀, ݁ s’interprètent comme le produit scalaire de deux vecteurs (A.8). ܽൌݑሬԦ ∙ ݑሬԦ ܾൌݑሬԦ ∙ ݒԦ ܿൌݒԦ ∙ ݒԦ ݀ൌݑሬԦ ∙ ݓሬሬԦ଴ ݁ൌݒԦ ∙ ݓሬሬԦ଴ (A.8) Il faut noter que le dénominateur ܽܿ െ ܾଶ de deux équations (A.6) et (A.7) doit être positif. S’il est égal à zéro, les deux lignes sont parallèles. La recherche de distance minimale entre deux lignes se résume alors à employer les paramètres ݏ஼ et ݐ஼ obtenus pour trouver la norme du vecteur ݓሬሬԦ஼ défini selon la formule (A.2). Passant à présent au cas de deux segments ܵଵ et ܵଶ représentés par les équations paramétriques : ܵଵሺݏሻ ൌ ܲ଴ ൅ ݑݏሬԦ,ݏ ∈ ሾ0,1ሿ (A.9) ܵଶሺݏሻ ൌ ܳ଴ ൅ ݒݐԦ,ݐ ∈ ሾ0,1ሿ Nous commençons, de manière similaire, par calculer la distance entre deux segments en minimisant la norme du vecteur ݓሬሬԦ௖ (‖ݓሬሬԦ௖‖ሻଶ). Ainsi, la position des points les plus proches sur les deux droites ܮଵ et ܮଶ est retrouvée grâce aux équations (A.6) et (A.7). Ensuite, nous procédons à vérifier si les valeurs de ݏ஼ et ݐ஼ sont comprises dans l’intervalle de 0 à 1, puisque ݏ஼ ∈ ሾ0,1ሿ et ݐ஼ ∈ ሾ0,1ሿ. Si c’est le cas, les points ܲሺܵ஼ሻ et ܳሺݐ஼ሻ appartiennent Annexe A. Distance minimale entre deux segments 155 aux segments (c’est-à-dire sont situés à l’intérieur du segment délimité par ces extrémités) et nous nous en servons pour déterminer la distance minimale. Si par contre, ils se trouvent au-delà d’un segment, il faut recalculer les paramètres ݏ஼ et ݐ஼ de façon qu’ils minimisent la norme de ݓሬሬԦ஼. Nous testons plusieurs scénarios (A.10) comme nous l’expliquons au fur et à mesure. Valeur calculée Valeur admise (A.10) ൌ0ݏ 0൏ݏ ൌ1ݏ 1൐ݏ ൌ0ݐ 0൏ݐ ൌ1ݐ 1൐ݐ Alors, si ݏ൏0, nous changeons sa valeur qui sera désormais égale à zéro (ݏൌ0). Par conséquent, l’équation (A.3) s’écrit comme : ݓሬሬԦ஼ ൌ ݓሬሬԦ଴ െ ݐ஼ݒԦ (A.11) et la distance à minimiser : ݓሬሬԦ஼ ∙ ݓሬሬԦ஼ ൌ ሺݓሬሬԦ଴ െ ݐ஼ݒԦሻ ∙ ሺݓሬሬԦ଴ െ ݐ஼ݒԦሻ (A.12) La dérivée partielle selon ݐ஼ de l’équation (A.12) amène à la formule suivante : െ2ݒԦ ∙ ሺݓሬሬԦ଴ െ ݐ஼ݒԦሻ ൌ 0 (A.13) dont la résolution donne la valeur de ݐ஼ : ଴Ԧሬሬݓ ∙ Ԧݒ ൌ ஼ݐ Ԧݒ ∙ Ԧݒ (A.14) En admettant que le ݏൌ0 pour le segment ܵଵ (qui correspond nota bene à l’une des extrémités du segment ܵଵ), nous obtenons la valeur de ݐ pour le segment ܵଶ. Lorsque ݏ൐1, on fixe ݏൌ1. Puis, nous entreprenons les mêmes démarches. La distance minimisée est : ݓሬሬԦ஼ ∙ ݓሬሬԦ஼ ൌ ሺݓሬሬԦ଴ ൅ ݑሬԦ െ ݐ஼ݒԦሻ ∙ ሺݓሬሬԦ଴ ൅ ݑሬԦ െ ݐ஼ݒԦሻ (A.15) De même, nous calculons la dérivée partielle de (A.15) selon ݐ஼ : െ2ݒԦ ∙ ሺݓሬሬԦ଴ ൅ ݑሬԦ െ ݐ஼ݒԦሻ ൌ 0 (A.16) afin d’obtenir, par résolution du système linéaire, le ݐ஼ : Ԧݒ ∙ Ԧሬݑ ൅ ଴Ԧሬሬݓ ∙ Ԧݒ ൌ ஼ݐ Ԧݒ ∙ Ԧݒ (A.17)156 De cette façon, nous déterminons, sur le segment ܵଶ, le point le plus proche du segment ܵଵ. Si aucun des cas envisagés ci-dessus n’aboutit pas à parvenir le paramètre ݐ஼ dont la valeur se trouve dans l’intervalle de 0 à 1, nous appliquons la même procédure pour ݐ conformément aux variantes affichées par (A.10). 157 Annexe B Méthode EIGEN 0. Méthode EIGEN Dans leur travail [Zhang et Faugeras, 1991] discutent de différentes représentations d’une ligne ܮ dans l’espace 3D. Celle-ci peut être intuitivement définie par deux points quelconques (représentation étant plutôt utilisée lorsque l’on s’intéresse à un segment de ligne) (Figure B.1a), ou bien encore par un point m et un vecteur directeur ݑ (Figure B.1b). Une autre possibilité se réfère à la représentation de Plücker d’une ligne, c’est-à-dire celle par deux vecteurs perpendiculaires ሺݑ, ݀ሻ de telle sorte que ݑ soit le vecteur directeur unitaire et le vecteur ݀ soit perpendiculaire au plan passant par cette ligne et l’origine (Figure B.1c). Le vecteur ݀ est alors le produit vectoriel de deux vecteurs ݑ et ݉ (point arbitraire sur la ligne ܮ). Cette dernière définition a été employée par les auteurs afin de dériver la solution analytique d’une transformation rigide - la combinaison d’une rotation ሺܴሻ suivie d’une translation ሺܶሻ. Figure B.1 Différentes représentations d'une ligne 3D 158 Admettons que ሺݑ, ݀ሻ sont les paramètres de segments à transformer et que ሺݑᇱ , ݀ᇱ ሻ ceux de segments de référence, la relation entre les entités linéaires s’écrit alors : ݑᇱ ൌ ܴݑ (B.1) ݀ᇱ ≜ ݑᇱ ˄ ݉ᇱ ൌ ܴ݀ ൅ ݑᇱ ˄ ܶ (B.2) En conséquence, nous insistons sur le fait que les segments transformés doivent être parallèles aux segments de référence. L’estimation des inconnues de pose aboutit à envisager deux sous-problèmes distincts. Rotation Tout d’abord, la matrice de rotation ሺܴሻ est déterminée par minimisation de la fonction (B.3) qui bénéfice seulement de l’orientation de toutes les paires de segments ሺݑ௜, ݑ௜ ᇱ ሻ. ௜ݑ‖෍݊݅ܯ ሺܴሻ ൌݎݎܧ ᇱ െ ܴݑ௜‖ଶ ே ௜ୀଵ (B.3) Évidemment, l’appariement créé se traduit implicitement par le système d’indiçage ce qui veut dire que: pour tout i, la ligne ሺݑ௜, ݀௜ሻ correspond à la ligne ሺݑ௜ ᇱ , ݀௜ ᇱ ሻ. Tous les calculs sont adaptés à la rotation représentée par un quaternion unitaire q ൌ ሾλ଴, λଵ, λଶ, λଷሿ୲ . Étant donné que le produit Ru peut être également exprimé comme la multiplication des quaternions (∗) et que ‖ݍ‖ ൌ 1, la formule (B.3) est modifiée en (B.4) : (ത (B.4ݍ ∗ ݑ ∗ ݍ ൌ ݑܴ où ݍത symbolise le conjugué du quaternion, par définition, obtenu en conservant sa partie scalaire et en prenant l’opposé de sa partie vectorielle. La fonction à minimiser prend alors la forme suivante : ௜ݑ‖෍݊݅ܯ ሺܴሻ ൌݎݎܧ ଶ‖௜ݑ∗ݍെݍ∗ ᇱ ே ௜ୀଵ (B.5) Se référant à la définition du produit de deux quaternions l’expression ݑ௜ peut ௜ݑ∗ݍെݍ∗ ᇱ être remplacée par une fonction linéaire ܣ௜ݍ telle que : ܣ௜ ൌ ቈ 0 ሺݑ௜ െ ݑ௜ ᇱ ሻ௧ ௜ݑ െ ௜ݑെሺ ᇱ ሻ ൫ݑ෥ప ൅ ݑప ෩ᇱ ൯ ቉ ସ௫ସ (B.6) où la notation ݑ෤ signifie la matrice antisymétrique créée pour le vecteur ݑ ൌ ሾݔ, ݕ, ݖሿ௧ selon la formule (B.7). ݕ ݖൌ ൥ 0 െ ෤ݑ ݔ0 െ ݖ െݕ ݔ 0 ൩ (B.7) Avec toutes ces informations, l’équation (B.5) s’exprime finalement de la manière suivante : Annexe B. Méthode EIGEN 159 ௜ܣ௧ݍ ෍݊݅ܯ ሺܴሻ ൌݎݎܧ ௧ ௜ܣ ே ௜ୀଵ ݍ ൌ ܯ݅݊ሺݍ௧ݍܣሻ (B.8) où la matrice symétrique ܣ ൌ ∑ ܣ௜ ௧ ௡ ௜ܣ ௜ୀଵ est calculée progressivement pour chaque paire de segments. Le vecteur propre de la matrice ܣ convenant à la plus petite valeur propre est le quaternion ݍ ൌ ሾߣ଴, ߣଵ, ߣଶ, ߣଷሿ௧ qui représentera la rotation optimale. En revanche, il existe toujours deux quaternions correspondant à la rotation. Ce constat n’est pas surprenant puisque la rotation autour de l’axe ݑ et d’angle ߠ et la même que celle de l’axe « െݑ » et d’angle 2ߨ െ ߠ. Néanmoins, dans la plupart de cas, la rotation ne dépasse presque jamais ߨ. Nous pouvons alors présumer que le premier élément du quaternion (composante réelle) doit être positif. La matrice orthogonale correspondant à la rotation au moyen du quaternion unitaire est donnée par : ଴ߣ቎ൌܴ ଶ ൅ ߣଵ ଶ െ ߣଶ ଶ െ ߣଷ ଶ 2ሺߣଵߣଶ െ ߣ଴ߣଷሻ 2ሺߣଵߣଷ ൅ ߣ଴ߣଶሻ ଴ߣ ଷሻߣ଴ߣ ൅ ଶߣଵߣ2ሺ ଶ െ ߣଵ ଶ ൅ ߣଶ ଶ െ ߣଷ ଶ 2ሺߣଶߣଷ െ ߣ଴ߣଵሻ ଴ߣ ଵሻߣ଴ߣ ൅ ଷߣଶߣଶሻ 2ሺߣ଴ߣ ଷ െߣଵߣ2ሺ ଶ െ ߣଵ ଶ െ ߣଶ ଶ ൅ ߣଷ ଶ ቏ (B.9) Translation Une fois la rotation calculée, la détermination de la translation ܶ est assez aisée. Sachant que tous les paramètres de segments sont des constantes, et que seulement les trois composants de vecteur ܶ sont des variables, le calcul de ceux-ci s’effectue par la méthode des moindres carrés, ce qui revient à minimiser : ݎݎܧሺܶሻ ൌ ܯ݅݊෍‖݀௜ ᇱ െ ܴ݀௜ െ ݑ௜ ᇱ ˄ ܶ‖ଶ ே ௜ୀଵ (B.10) La dérivée partielle selon ܶ de l’équation (B.10) amène à la formule suivante : ෍ 2൫݀௜ ᇱ െ ܴ݀௜ െ ݑప ෩ᇱ ܶ൯௧ ௜ݑ ᇱ ൌ 0 ே ௜ୀଵ (B.11) dont la solution est : ܶ ൌ ൭෍ ݑప ෩ᇱ ൫ݑప ෩ᇱ ൯ ௧ ே ௜ୀଵ ൱ ିଵ ቌ෍൫ݑప ෩ᇱ ൯ ௧ ே ௜ୀଵ ሺ݀௜ ᇱ െ ܴ݀௜ሻቍ (B.12)161 Annexe C Méthode ICL(forme ICP) 0. Méthode ICL(forme ICP) La méthode ICL (forme ICP) suit les mêmes étapes que l’approche EIGEN. Elle cherche à résoudre deux tâches : le problème non linéaire de rotation et celui linéaire de translation. Mais, nous observons une différence au niveau de représentation des segments et de calcul du vecteur de translation. Chaque droite de l’ensemble ܣ est décrite par sa forme paramétrique ሺ݌௜, ݒ௜ሻ où ݌ symbolise un point aléatoire de la droite et ݒ son vecteur directeur unitaire. Pareillement, les segments de référence ܯ sont caractérisés par ሺ݌௜ ᇱ ௜ݒ , ᇱ ሻ. Rotation La matrice de rotation est calculée à partir de direction de toutes les paires de lignes ሺݒ௜, ݒ௜ ᇱ ሻ. La fonction d’erreur à minimiser est tout à fait similaire à la formule (B.3). La solution par moindres carrés d’un tel système non linéaire d’équations avait été aussi proposée par [Arun et al., 1987]. Il s’agit de mettre en œuvre la décomposition en valeurs singulières (SVD) de la matrice de covariance croisée ∑௩௩ᇲ formée pour l’appariement composé de ܰ paires de segments comme suit : ෍ ൌ 1 ௩௩ᇲ ܰ෍ሺݒ௜ െ ݒ̅ሻሺݒ௜ ᇱ െ ݒഥᇱሻ௧ ே ௜ୀଵ (C.1) Sachant que les vecteurs ݒ̅ et ݒ ഥᇱ sont les centres de masse qui valent respectivement : ଵ ≜̅ݒ ே ∑ ݒప ሬሬሬԦ ே ௜ୀଵ et ݒ ഥᇱ ≜ ଵ ே ∑ ݒప ே ሬሬሬԦᇱ ௜ୀଵ (C.2) nous arrivons à la formule suivante : ෍ ൌ 1 ܰ෍ቀݒప ሬሬሬԦ ൫ݒప ሬሬሬԦᇱ ൯ ௧ ݒሺ̅ݒ െ ഥᇱሻ௧ቁ ே ௜ୀଵ ௩௩ᇲ (C.3) La décomposition de matrice carrée (3x3) ∑௩௩ᇲ s’écrit : ෍ ൌ ܷܸܵ௧ ௩௩ᇲ (C.4)162 où la matrice ܵ contient les valeurs singulières de la matrice ∑௩௩ᇲ , et les matrices ܷ et ܸ comprennent chacune un ensemble de vecteurs orthonormés. Ceci nous permet de calculer la matrice de rotation d’une manière simple : ܴ ൌ ܸܷ௧ (C.5) Translation Dès que la rotation ܴ est déterminée, le vecteur de translation ܶ peut être calculé par les moindres carrés. À cet effet, deux points quelconques ሺܽ௜, ܾ௜ሻ appartenant à i-ème droite de ܣ, mais aussi leurs points homologues ሺܽ௜ ᇱ , ܾ௜ ᇱ ሻ de ܯ, sont utilisés. Leurs positions sur les droites respectives sont déterminées grâce à l’équation paramétrique : ܽ௜ ൌ ݌௜ ൅ ݐଵݒ௜ et ܾ௜ ൌ ݌௜ ൅ ݐଶݒ௜ (C.6) ܽ௜ ᇱ ൌ ݌௜ ௜ݒଷݐ ൅ ᇱ ᇱ et ܾ௜ ᇱ ൌ ݌௜ ௜ݒସݐ ൅ ᇱ ᇱ (C.7) Puisque ሺ݌௜ ᇱ ௜ݒ , ᇱ ሻ caractérisent une ligne de référence ܯ (immobile), la correspondance avec son homologue fournit également la contrainte : ൜ ௜݌ ௜ݒଷݐ ൅ ᇱ ᇱ ൌ ܴሺ݌௜ ൅ ݐଵݒ௜ሻ ൅ ܶ ௜݌ ௜ݒସݐ ൅ ᇱ ᇱ ൌ ܴሺ݌௜ ൅ ݐଶݒ௜ሻ ൅ ܶ (C.8) Allons plus loin, la formule (C.8) est substituée par : ە ۖ ۖ ۔ ۖ ۖ ൭ۓ ᇱݔ ᇱݕ ᇱݖ ൱൅ݐଷ ቌ ௫ݒ ᇱ ௬ݒ ᇱ ௭ݒ ᇱ ቍൌܴቆݔ ݕ ݖ ቇ൅ݐଵܴ ൭ݒ௫ ௬ݒ ௭ݒ ൱൅ቌܶ௫ ܶ௬ ܶ௭ ቍ ൭ ᇱݔ ᇱݕ ᇱݖ ൱൅ݐସ ቌ ௫ݒ ᇱ ௬ݒ ᇱ ௭ݒ ᇱ ቍൌܴቆݔ ݕ ݖ ቇ൅ݐଶܴ ൭ݒ௫ ௬ݒ ௭ݒ ൱൅ቌܶ௫ ܶ௬ ܶ௭ ቍ (C.9) Cela permet aussi de l’écrire sous la forme matricielle d’un système linéaire ܣܺ ൌ ܮ possédant sept inconnues, dont trois composants du vecteur de translation et quatre variables : ۉ ۈ ۈ ۈ ۇ ݔݒെ ܴݔݒ ′ 0 0 100 ݕݒെ ܴݕݒ ′ 0 0 010 ݖݒെ ܴݖݒ ′ 0 0 001 0 0ݔݒܴ െݔݒ ′ 100 0 0ݕݒܴ െݕݒ ′ 010 0 0ݖݒܴ െݖݒ ی001 ′ ۋ ۋ ۋ ۊ ᇣᇧᇧᇧᇧᇧᇧᇧᇧᇧᇧᇧᇤᇧᇧᇧᇧᇧᇧᇧᇧᇧᇧᇧ6݊ݔ7ᇥ ஺ ۉ ۈ ۈ ۈ ۇ 1ݐ 3ݐ 2ݐ 4ݐ ݔܶ ݕܶ یݖܶ ۋ ۋ ۋ ۊ ᇣᇧᇤᇧ7ݔ1ᇥ ௑ = ۉ ۈ ۈ ۈ ۇ ܴݔ െ ′ݔ ܴݕ െ ′ݕ ܴݖ െ ′ݖ ܴݔ െ ′ݔ ܴݕ െ ′ݕ یܴݖ െ ′ݖ ۋ ۋ ۋ ۊ ᇣᇧᇧᇧᇤᇧᇧᇧ6ݔ1ᇥ ௅ (C.10) où : ൭ ோݔ ோݕ ோݖ ൱ൌܴቆݔ ݕ ݖ ቇ et ൭ ௫ோݒ ௬ோݒ ௭ோݒ ൱ൌܴ൭ݒ௫ ௬ݒ ௭ݒ ൱ (C.11) La résolution du système revient alors à chercher les inconnues ܺ satisfaisantes simultanément toutes les équations de la formule (C.10). Ainsi, ܺ ൌ ሺܣ௧ܣሻିଵܣ௧ܮ.163 Annexe D Méthode FMII 0. Méthode FMII Dans nos travaux, nous nous intéressons tout particulièrement à la variante FMII permettant de résoudre le problème du recalage de deux jeux de lignes, dont les entités linéaires de référence (Model) sont finies et celles à recaler (Image) infinies. Ce choix peut s’expliquer, conformément à [Kamgar-Parsi et Kamgar-Parsi, 2004], par le fait que le FMFI, conçu pour les segments de ligne, risque d’échouer si le segment plus court d’une paire n’est pas complètement inclus dans son homologue. Dans un cas général, cette approche n’est pas exploitable puisque les segments provenant de différentes sources ne se chevauchent souvent que partiellement. L’alternative serait plutôt de remplacer des segments Image par des lignes et de suivre, par la suite, des démarches envisagées pour la procédure FMII, comme nous l’expliquerons au fur et à mesure dans cette section. Étant donné deux ensembles d’entités linéaires, de telle sorte que ܣ ൌ ሼܣଵ,…,ܣ௜,…,ܣேሽ comprend des segments de référence (Model) par rapport auxquels des lignes Image ܺ ൌ ሼܺଵ,…,ܺ௜,…,ܺேሽ seront déplacés, la représentation de chacun des éléments est la suivante : ܣ௜ ൌ ሺܽ௜, ݒ௜, ܮ௜ሻ et ܺ௜ ൌ ሺݔ௜, ݒ௜ ᇱ ሻ (D.1) où : ܽ௜ : milieu du segment Model ௜ݒ et ௜ݒ ᇱ : vecteur directeur unitaire de la ligne Model et Image x୧ : point de la ligne Image le plus proche de l’origine ce qui implique ݔ௜ ௧ ௜ݒ ᇱ ൌ 0 ܮ௜ : longueur du segment Model Les lignes Image seront désormais considérées comme illimitées. Distance entre les segments de longueur identique Comme il a déjà été démontré (Chapitre 5), le calcul de la distance entre deux jeux de segments 3D n’est pas trivial. Pour leur part [Kamgar-Parsi et Kamgar-Parsi, 2004], la définissent comme la somme des carrés des distances obtenues entre les points correspondants appartenant à ܣ et ܺ. Ces derniers sont considérés comme les points ayant la même distance ݑ par rapport à des points de départ admis. La Figure D.1 illustre deux segments de longueur identique ܮ pour lesquels les points correspondants ݌ et ݍ ont été définis à l’égard de leurs milieux ܽ et ݔ. 164 Figure D.1 Choix des points correspondants p et q par rapport aux milieux a et x (Illustration reproduite à partir de [Kamgar-Parsi et Kamgar-Parsi, 1997]) Envisageant ce cas, nous pouvons utiliser la variable ݑ, de sorte que െܮ/2 ൑ ݑ ൑ ܮ/2, pour paramétrer les segments ܣ et ܺ. Nous notons les coordonnées de points correspondants : ᇱݒݑ ൅ ݔ ൌ ݍ et ݒݑ ൅ ܽ ൌ ݌ . D’où, le carré de la distance Euclidienne entre ces deux points se calcule : ܦଶሺݑሻ ൌ ‖ሺܽെݔሻ ൅ ݑሺݒെݒᇱ ሻ‖ଶ (D.2) ce qui amène à la formule suivante : ܯሺܣ௜, ܺ௜ሻ ൌ න ݀ܦݑଶሺݑሻ ൌ ܮ௜‖ܽ௜ െ ݔ௜‖ଶ ൅ ௜ܮ ଷ 6 ሺ1െݒ௜ ௧ ௜ݒ ᇱ ሻ ௅/ଶ ି௅/ଶ (D.3) Nous en ressortons que la distance M(A,X) dépend de l’orientation des lignes, mais aussi de l’écartement entre leurs milieux. Par conséquent, sa valeur est nulle, si est seulement si, les deux segments sont parallèles et leurs milieux coïncident. Étant donné que chaque ensemble est composé de ܰ segments correspondants, la distance mesurée entre eux s’exprime par l’équation (D.4). ܯሺܣ, ܺሻ ൌ෍ܯሺܣ௜, ܺ௜ሻ ൌ ෍ ቈܮ௜‖ܽ௜ െ ݔ௜‖ଶ ൅ ௜ܮ ଷ 6 ሺ1െݒ௜ ௧ ௜ݒ ᇱ ሻ቉ ே ௜ୀଵ ே ௜ୀଵ (D.4) Admettons que les segments Model ሺܣሻ sont fixes, nous souhaitons, dans un premier temps, tourner les segments ܺ et ensuite les déplacer. C’est pourquoi, la nouvelle position de segment après la transformation Ƭ, consistant en rotation ܴ suivie par la translation ܶ, est suivante : ൜ ௜ݔܴ ൅ ܶ ൌ ௜ݔ ௜ݒ ᇱ ൌ ܴݒ௜ ᇱ (D.5) La distance entre les segments transformés peut être remplacée par : ܯሺܣ, ܺሻ ൌ෍ܯሺܣ௜, ܺ௜ሻ ൌ ෍ ቈܮ௜‖ܽ௜ െ ܶ െ ܴݔ௜‖ଶ ൅ ௜ܮ ଷ 6 ሺ1െݒ௜ ௧ ௜ݒ ᇱ ሻ቉ ே ௜ୀଵ ே ௜ୀଵ (D.6) Annexe D. Méthode FMII 165 Distance entre les segments de longueur différente La définition introduite (D.6) a été modifiée par les auteurs afin qu’elle soit susceptible d’être employée pour les lignes – finies et infinies. Nous passons donc à présenter l’approche FMII dédiée au cas mixte, où les segments sont définis par la formule (D.1). Sachant que, quel que soit le point ܽ௜ ∈ ܣ௜, il existe sur la ligne ܺ௜ son homologue ݔ௜ ൅ ݏ௜ݒ௜ ᇱ pour ݏ௜ ∈ Թ, la distance ܦሺܣ௜, ܺ௜ሻ entre ces deux points correspondants se calcule, conformément à la formule (D.3), comme : ௜ݒ௜ݏ ൅ ௜ݔ , ௜ݒݑ ൅ ௜ܽሺݐݏ݅݀ ∙ ݑ݀ ሻ ൌ න௜ܺ ,௜ܣሺܦ ௜ݒݑ ൅ ᇱ ᇱ ሻ Ω೔ (D.7) où : ݑ : scalaire caractérisant la droite (équation paramétrique) Ω௜ : chevauchement entre les segments ݀݅ݐݏ : fonction de distance employée (distance Euclidienne) Nous limitons le calcul de la distance ܦሺܣ௜, ܺ௜ሻ à la partie de chevauchement entre les segments. Cet intervalle étant défini par Ω௜, nous l’attribuons la longueur ܮ௜, puisque seulement les entités linéaires ܣ௜ sont finies. Compte tenu de la transformation Ƭ de l’ensemble Image, la distance mesurée s’exprime de la manière suivante : ܯሺܣ, Ƭܺሻ ൌ ෍ ܦሺܣ௜, Ƭܺ௜ሻ ே ௜ୀଵ (D.8) afin d’être finalement déterminée, par la norme euclidienne L2 selon la formule ci-dessous : ܯሺܣ, Ƭܺሻ ൌ ෍ሾܮ௜ ‖ܽ௜ െܶെܴሺݔ௜ ൅ ݏ௜ݒ௜ ᇱ ሻ‖ଶ ൅ ܮ௜ ௜ݒଷሺ1െ ௧ ௜ݒܴ ᇱ ሻ/6ሿ ே ௜ୀଵ (D.9) Rotation L’estimation de la transformation rigide dans la procédure d’alignement de segments consiste à minimiser leur distance réciproque ܯሺܣ, Ƭܺሻ sur tous les Ƭ et ሼݏ௜ሽ possibles. La solution proposée s’avère autour du problème d’optimisation non-linéaire, résolue grâce à la technique itérative, d’un système à ሺ6൅ܰሻ variables avec six paramètres de la transformation rigide et N variables pour identifier les points correspondants. La complexité de l’algorithme est ܱሺܰሻ, alors il est considéré comme rapidement exécutable. Lorsqu’on minimise la distance en fonction de ܴ, ܶ et l’ensemble ሼݏ௜ሽ, il faut résoudre l’équation ߲ܯ ߲ݏ ⁄ ௜ ൌ 0, ce qui nous amène à calculer le paramètre shift ݏ௜ ∈ Թ selon la formule (D.10). ݏ௜ ൌ ሺܽ௜ െ ܶሻ௧ܴݒ௜ ᇱ en supposant que ሺܴݔ௜ሻ௧ܴݒ௜ ᇱ ൌ ݔ௜ ௧ ௜ݒ ᇱ ൌ 0 (D.10) En remplaçant, dans la formule (D.9), la translation ܶ calculée selon l’équation (D.18), nous pouvons obtenir la mesure de distance se référant uniquement à la rotation ܴ : ܯሺܣ, Ƭܺሻ ൌ෍ܮ௜ ቆ‖ܽప ́‖ଶ ൅ ‖ݔప ́‖ଶ ൅ ௜ܮ ଶ 6 ቇെ2෍ܮ௜ ቆܽ́ ௜ ௧ పݔܴ ́ ൅ ௜ܮ ଶ ௜ݒ 12 ௧ ௜ݒܴ ᇱ ቇ ே ௜ୀଵ ே ௜ୀଵ (D.11)166 où : ܽప ́ ൌ ܽ௜ െ ܽത et ݔప ௜ݒ௜ݏ ൅ ௜ݔ ൌ ́ ′ െ ݔ̅ (D.12) Le premier composant de la formule (D.11) est constant puisqu’il ne dépend pas de la matrice de rotation ܴ. Afin de minimiser la distance M(A,ƬX), il est nécessaire de maximaliser la seconde somme. Pour ce faire, la matrice de covariance croisée ∑஺,௑ est créée entre les segments correspondants de la manière suivante : ෍ ൌ෍ሾܮ௜ሺܽ௜ െ ܽതሻሺݔ௜ ൅ ݏ௜ݒ௜ ᇱ െ ݔ̅ሻ௧ ൅ ܮ௜ ௜ݒሺ௜ݒଷ ᇱ ሻ௧ /12ሿ ே ௜ୀଵ ஺,௑ (D.13) où les centres de masse ܽത et ݔ̅ sont donnés par la formule (D.14). ܽത ൌ ଵ ௜ܽ௜ܮ ∑ ௐ ே ௜ୀଵ et ݔ̅ൌ ଵ ݅ݒ݅ݏ ൅ ݅ݔሺ݅ܮ ∑ ௐ ′ ሻ ܰ ݅ൌ1 pour ܹ ൌ ∑ ܮ௜ ே ௜ୀଵ (D.14) La matrice de rotation est représentée par un quaternion unitaire ce qui nécessite, dans un premier temps, de former la matrice symétrique ܥସ௫ସ dont les éléments sont définis à partir de ∑஺,௑ . ܥଵଵ ൌ ∑ଵଵ ൅ ∑ଶଶ ൅ ∑ଷଷ ; ܥଵଶ ൌ ܥଶଵ ൌ ∑ଶଷ െ ∑ଷଶ ; ܥଵଷ ൌ ܥଷଵ ൌ ∑ଷଵ െ ∑ଵଷ ; ܥଵସ ൌ ܥସଵ ൌ ∑ଵଶ െ ∑ଶଵ ; ܥଶଶ ൌ ∑ଵଵ െ ∑ଶଶ െ ∑ଷଷ ; ܥଶଷ ൌ ܥଷଶ ൌ ∑ଵଶ ൅ ∑ଶଵ ; ܥଶସ ൌ ܥସଶ ൌ ∑ଷଵ ൅ ∑ଵଷ ; ܥଷଷ ൌ ∑ଶଶ െ ∑ଷଷ െ ∑ଵଵ ; ܥଷସ ൌ ܥସଷ ൌ ∑ଶଷ ൅ ∑ଷଶ ; ܥସସ ൌ ∑ଷଷ െ ∑ଵଵ െ ∑ଶଶ ; (D.15) Ensuite, les quatre valeurs propres de la matrice ܥ sont calculées en tant que solution analytique. Le vecteur propre correspondant à la plus grande valeur propre représente la rotation optimale ܴ exprimée en quaternion unité ݍ ൌ ሾߣ଴, ߣଵ, ߣଶ, ߣଷሿ௧. Le passage entre le quaternion et la matrice de rotation traditionnelle est réalisé selon l’équation (B.9). Nous pouvons aussi envisager une autre solution consistant à employer la SVD. Étant donné que la seconde somme de la formule (D.11) doit être maximisée pour minimiser tout terme, nous arrivons à obtenir : ́ܽቆ ௜ܮ ෍ ௜ ௧ పݔܴ ́ ൅ ௜ܮ ଶ ௜ݒ 12 ௧ ௜ݒܴ ᇱ ቇ ൌ ݎݐܽܿ݁൫ߑ஺,௑ܴ௧ ൯ ே ௜ୀଵ (D.16) Par conséquent, la décomposition en valeurs singulières de ∑஺,௑ amène à calculer la rotation ܴ. Pour plus de détails le lecteur pourra se référer à [Kamgar-Parsi et Kamgar-Parsi, 1997]. Translation Dès que la rotation est déterminée, le vecteur de translation ܶ peut être retrouvé en minimisant la formule (D.9). Pour y arriver, la dérivée partielle de ܯሺܣ, Ƭܺሻ par rapport à la variable ܶ est calculée : Annexe D. Méthode FMII 167 ܯ߲ ߲ܶ௜ ൌ െ2෍ ܮ௜ ௜ ݁Ԧ௜ ௧ሺܽ௜ െ ܶ െ ܴݔ௜ሻ ൌ 0 (D.17) Les équations ci-dessus étant linéaires, nous procédons alors à la résolution : ܶൌܽത െ ܴݔ̅ (D.18) Vu que les paramètres shift ሼݏ௜ሽ sont inconnus, les calculs des paramètres optimaux de transformation Ƭ seront effectués de manière itérative jusqu’à ce que le changement de valeurs ሼݏ௜ሽ ne dépasse plus un certain seuil. Le schéma récapitulatif à suivre est illustré par la Figure D.2. Figure D.2 Schéma général de l’approche *Valeurs initiales recommandées pour tous les ݏ௜ sont des zéros. Les tests effectués par [Kamgar-Parsi et Kamgar-Parsi, 2004] montrent que le nombre d’itérations ݐܫ݁ݎ est fortement lié à la précision désirée et oscille, pour un seuil de convergence égal à 10-3 (valeur adimensionnelle), entre trois et vingt. .169 Annexe E Pseudo-codes 0. Pseudo-codes Pseudo-code 4.1: Détection de plans via RANSAC Entrée: ܰ : nuage de points Paramètres : ܲ : probabilité ߪ : écart-type de bruit ܰ௣௟ : nombre de plans 1 Début 2 Initialiser des variables : ܥܧ ← 0; ܰ௜௧௘௥ ← ∞; ݅ ← 1; ܲ; ߪ 3 PourChaque ݆ ← 1: ܰ௣௟ Faire 4 Seuil :ߜଶ ← ߪଶܨఞమ మ ିଵሺܲሻ 5 TantQue ݅൑ܰ௜௧௘௥ Faire 6 S ← Choisir aléatoirement un échantillon ݇ൌ3 de ܰ 7 Estimer le modèle: ܯሺߠሻ 8 Distance au modèle: ݀←݁ெ൫݌௜, ܯሺߠሻ൯ 9 Si ݀ଶ ൑ ߜଶ Alors 10 Retour ܥܧ௜ 11 FinSi 12 Mettre à jour le nombre d'itérations: ܰ௜௧௘௥ ← ݈݋݃ሺ1െܲሻ/݈݋݃ሺ1െݍሻ 13 pour ݍ ൌ ൫ܥܽݎ݀ሺܥܧ௜ሻ/ܥܽݎ݀ሺܰሻ൯ ଷ 14 Meilleur plan: ܥܧ ൌ ݉ܽݔሺܥܧ௜ሻ 15 Incrémenter: ݅←݅൅1 16 FinTantQue 17 CC ← Analyser des composantes connexes d’EC (Pseudo-code 4.2) ܥܥ ;ߠ 18 Retour 19 ܰ ← ܰ െ ܥܥ 20 FinPour 21 Fin170 Pseudo-code 4.2: Détection et étiquetage des composantes connexes Entrée: N : nuage de points Paramètres : ρ: rayon de sphère k: nombre de points voisins ܰ௠௜௡: nombre minimal de points d’une composante connexe ܥܥ 1 Début 2 PourChaque point ݌௜ De ܰ Faire 3 Établir le voisinage ܸ௜ de ݌௜ en respectant les seuils imposés (ρ et K) 4 Générer la matrice creuse ܣ de ܯ paires de points voisins 5 FinPour 6 Décomposition de Dulmage-Mendelsohn de A : dmperm(A)=[P,Q,r,s] 7 PourChaque colonne ݆ ൌ 1: |ݎ| െ 1 De vecteur d'indices r Faire 8 Étiqueter des composantes connexes ܥܥ 9 Si หܥܥ௝ห൒ܰ௠௜௡ Alors 10 Calculer la surface ܵ௝ de ܥܥ௝ 11 SinonSi CCj est trop petite Alors 12 ܵ௝ ← 0 13 FinSi 14 Conserver la plus grande composante connexe ܥܥ 15 FinPour 16 FinAnnexe E. Pseudo-codes 171 Pseudo-code 4.3: Extraction d’arêtes de pli Entrée: ∏ : paramètres associés au plan Paramètres: ܶொ : Seuil poids Q ܵܲ : segment plan ܶ௦௘௚:longueur minimale d'une arête ܶ : tolérance distance 1 Début 2 ܲ ← Générer toutes les combinaisons possibles à partir de l’ensemble de plans ∏ 3 {Phase 1 : Tester l’angle β entre deux plans quelconques} 4 PourChaque paire ∏j et ∏k De ܲ Faire 5 Calculer l'angle β 6 ܳ ൌ ݏ݅݊ଶߚ 7 Si ܳ൑ܶொ Alors 8 Rejeter la paire de la liste ܲ 9 FinSi 10 FinPour 11 {Phase2: Tester si deux plans de ܲ sont voisins} 12 PourChaque paire ܵܲ௝ et ܵܲ௞ De ܲ Faire 13 ݀ ← Calculer la distance entre deux plans 14 Si ݀൑ܶ Alors 15 ܫ ← Déterminer la droite d'intersection 16 ܵ௝ ← projeter ܵܲ௝ sur ܫ 17 ܵ௞ ← projeter ܵܲ௞ sur ܫ 18 {Phase3: Tester si les segments ܵ௝ et ܵ௞ se chevauchent} 19 Si ฮܯ௝ܯ௞ฮ ൑ หܮ௝/2 െ ܮ௞/2ห Alors 20 Conserver le segment de droite (ܵܦ) de longueur ܮ ൌ min ሺܮ௝, ܮ௞ሻ si ܮ൒ܶ௦௘௚ 21 SinonSi ฮܯ௝ܯ௞ฮ ൐ หܮ௝/2 ൅ ܮ௞/2ห Alors 22 Conserver ܵܦ de longueur ܮൌܮ௝ ∩ ܮ௞ si ܮ൒ܶ௦௘௚ 23 SinonSi 24 Rejeter ܵܦ 25 FinSi 26 FinSi 27 FinPour 28 Fin172 Pseudo-code 5.1: Qualification à partir d'entités linéaires Entrée : ்ܺ௘௦௧ : coordonnées des segments ܶ݁ݐݏ Paramètres: ܷ : sensibilité ܺெ௢ௗ௘௟ : coordonnées des segments ݋ܯ݈݀݁ ݎ݋ܥ ;ܦܪܮ ;்ெܦܪܮܱ ;ெ்ܦܪܮܱ : Sortie 1 Début 2 ܷ ← 0.5 3 ܶ݁ݐݏ ← ்ܺ௘௦௧; ݋ܯ݈݀݁ ← ܺெ௢ௗ௘௟; 4 PourChaque Segment ݅ ∈ 〈1; ܰ〉 De Test Faire 5 PourChaque Segment ݆ ∈ 〈1; ܯ〉 De Model Faire 6 Calculer les distances ݀ூூ; ݀ୄ; ݀ఈ 7 FinPour 8 FinPour 9 Créer la matrice de similarité ܵܯܫ de dimension ܰܯݔ 10 Créer l'appariement préliminaire ܵ contenant ܰ paires 11 ܦ݂݂݅ଵ ← ܵேାଵ െ ܵே 12 ܦ݂݂݅ଶ ← ܦ݂݂݅ଵೖశభ െ ܦ݂݂݅ଵೖ 13 Si ܥܽݎ݀ሺܦ݂݂݅ଵ ൏ ܷሻ ൌܰ൅1 Alors 14 ߜ ← max ሺܵሻ 15 SinonSi 16 ݌݅ܿ ←trouver le premier maximum local : ܦ݂݂݅ଶ ൒ ܷ 17 Si ݌݅ܿ ൌ Ø Alors 18 ߜ ← ݉é݀݅ܽ݊݁ሺܵሻ ൅ 2ߪ 19 SinonSi 20 ߜ ← ܵሺ݌݅ܿ ൅ 1ሻ 21 FinSi 22 FinSi 23 ݎ݋ܥ்ெ ← ሺܵܯܫ ൑ ߜሻ 24 Calculer ܱܦܪܮ்ெ 25 ܶ݁ݐݏ ← ܺெ௢ௗ௘௟; ݋ܯ݈݀݁ ← ்ܺ௘௦௧; 26 Reprendre les démarches de 4 à 24 27 Retour ݎ݋ܥெ்; ܱܦܪܮெ் ்ெݎ݋ܥ ∩ ெ்ݎ݋ܥ ← ݎ݋ܥ 28 29 ܦܪܮ ← max ሺܱܦܪܮ்ெ, ܱܦܪܮெ்ሻ 30 Fin Annexe E. Pseudo-codes 173 Pseudo-code 6.1: Recalage à partir d'entités linéaires Entrée : ܺܶ݁ݐݏ : coordonnées des segments ܶ݁ݐݏ Paramètres: ߪ : écart-type de bruit ܺெ௢ௗ௘௟ : coordonnées des segments ݋ܯ݈݀݁ ݇ : échantillon minimal ݎ݋ܥ ;ܶ ;ܴ : Sortie 1 Début 2 Initialiser des variables ܰூ_௎௣ௗ௔௧௘ ← 0; ܰ௜௧௘௥ ← 100; ݅ ← 1; ߝ ← 1݁ െ 6; ݇; ߜ ← 5.8ߪ 3 ܣ௜௡௜,ܰ← Créer l'appariement préliminaire entre ்ܺ௘௦௧ et ܺெ௢ௗ௘௟ (Pseudo-code 5.1) 4 TantQue ݅൑ܰ௜௧௘௥ Faire 5 ܵ ← Tirer aléatoirement un échantillon ݇ de ܣ௜௡௜ 6 ܴ௜, ܶ௜ ← Calculer les paramètres de transformation rigide par ܫܫܯܨଶ à partir de ܵ 7 Recaler ்ܺ௘௦௧ et ܺெ௢ௗ௘௟ : ்ܺ௘௦௧_௎௣ௗ௔௧௘ ൌ ்ܺ௘௦௧ ∙ ܴ௜ ൅ ܶ௜ 8 ݀௜ ← Calculer les distances entres les segments appariés ܣ௜௡௜ (équation 5.10) 9 ܰூ ← ሺ݀௜ ൑ ߜሻ 10 Si ܰூ ൒ ܰூ_௎௣ௗ௔௧௘ Alors 11 ܴ௜௡௜ ← ܴ௜ 12 ܶ௜௡௜ ← ܶ௜ 13 ܰூ_௎௣ௗ௔௧௘ ൌ ܰூ 14 FinSi 15 Mettre à jour le nombre d'itérations : ݍ ← ሺܰூ/ܰሻ௞ ; ܰ௜௧௘௥ ← ݈݋݃ሺߝሻ/݈݋݃ሺ1 െ ݍሻ 16 Incrémenter : ݅←݅൅1 17 FinTantQue 18 ܣ௙ ← Créer l'appariement fin entre ்ܺ௘௦௧_௎௣ௗ௔௧௘ et ܺெ௢ௗ௘௟ (Pseudo-code 5.1) 19 ܴ෠, ܶ෠ ← Calculer les paramètres des transformation rigide par ܫܫܯܨଶ à partir de ܣ௙ 20 ܴൌܴ௜௡௜ ∙ ܴ෠ 21 ܶൌܴ෠ ∙ ܶ௜௡௜ ൅ ܶ෠ ௙ܣ ← ݎ݋ܥ 22 23 Fin Qualification et amélioration de la précision de systèmes de balayage laser mobiles par extraction d’arêtes RESUME : Au cours de ces dernières décennies, le développement de Systèmes Mobiles de Cartographie, soutenu par un progrès technologique important, est devenu plus proéminent apparent. Il a été stimulé par le besoin grandissant de collecte d’informations géographiques précises sur l’environnement. Nous considérons, au sein de cette thèse, des solutions pour l’acquisition des nuages de points mobiles de qualité topographique (précision centimétrique). Il s’agit, dans cette tâche, de mettre au point des méthodes de qualification des données, et d’en améliorer les erreurs systématiques par des techniques d’étalonnage et de recalage adéquates. Nous décrivons une nouvelle démarche d’évaluation de l’exactitude et/ou de la précision des relevés laser mobiles. Celle-ci repose sur l’extraction et la comparaison des entités linéaires de la scène urbaine. La distance moyenne calculée entre les segments appariés, étant la distance modifiée de Hausdorff, sert à noter les nuages par rapport à des références existantes. Pour l’extraction des arêtes, nous proposons une méthode de détection d’intersections entre segments plans retrouvés via un algorithme de RANSAC enrichi d’une analyse de composantes connexes. Nous envisageons également une démarche de correction de relevés laser mobiles à travers un recalage rigide fondé, lui aussi, sur les éléments linéaires. Enfin, nous étudions la pertinence des arêtes pour en déduire les paramètres de l’étalonnage extrinsèque du système mobile. Nous testons nos méthodes sur des données simulées et des données réelles acquises dans le cadre du projet TerraMobilita. Mots clés : Nuage de points, Système Mobile de Cartographie, Exactitude, Précision, Arête, Segmentation, Évaluation, RANSAC, Étalonnage, Calibrage, Mise en correspondance Edge-based accuracy assessment and improvement of mobile laser scanning systems ABSTRACT : Over the past few decades, the development of Mobile Mapping Systems (MMS), supported by significant technological progress, has become more prominent. It has been motivated by the growing need for precise geographic information about the environment. In this thesis, we consider approaches for the acquisition of mobile point clouds with topographic quality (centimeter-level accuracy). The aim is to develop techniques for data quality assessment and improvement. In particular, we eliminate the systematic errors inherent to an MMS data using appropriate calibration and registration methods. We describe a novel approach to assess the accuracy and/or the precision of mobile laser point clouds. It is based on the extraction and comparison of line features detected within the urban scene. The computed average distance between corresponding pairs of line segments, taking advantage of a modified Hausdorff distance, is used to evaluate the MMS data with respect to a reference data set. For edge extraction, we propose a method which relies on the intersections between planes modelled via the RANSAC algorithm refined by an analysis of connected components. We also consider an approach to correct point clouds using a line-based rigid registration method. Finally, we study the use of edges for estimating the boresight angles of a land-based mobile mapping system. We apply our methods to synthetic data and to real data acquired as part of the TerraMobilita project. Keywords : Point Cloud, Land-based mobile mapping system (MMS), Accuracy, Precision, Edge, Segmentation, Assessment, RANSAC, Registration, Calibration, Matching Collaboration de techniques formelles pour la v´erification de propri´et´es de sˆuret´e sur des syst`emes de transition A. Champion To cite this version: A. Champion. Collaboration de techniques formelles pour la v´erification de propri´et´es de sˆuret´e sur des syst`emes de transition. Databases. ISAE - Institut Sup´erieur de l’A´eronautique et de l’Espace, 2014. French. HAL Id: tel-01092412 https://hal.archives-ouvertes.fr/tel-01092412 Submitted on 8 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Acknoledgments First, I would like to thank my supervisors Rémi Delmas and Michael Dierkes for their support, knowledge, time and energy. They provided me with the best environment I could wish for. Everything I did during these last three years, I owe to them. I also thank the reviewers, Daniel Le Berre and Cesare Tinelli, for taking the time to read the manuscript and giving me constructive feedback, which lead to interesting discussions. Many thanks to all the members of the jury: Yamine Aït Ameur for making the defense possible and for his interest and insightful questions on my work; Virginie Wiels for making this PhD possible at all, along with Rémi Delmas and Michael Dierkes; Steve Miller for flying all the way to Toulouse, for his interest in my work, for his tricky questions on Boolean differential calculus and for all his reviews on the manuscript; Viktor Kuncak for following my work, and for the great discussions we had about both our research topics; Last, I thank again Daniel Le Berre and Cesare Tinelli for taking the time to come to Toulouse and attend the defense. A few lines to thank the people close to me. I will only mention their names, the support they gave me cannot be put into words. Thanks, love and apologies to Yves et Marie-Claire, Claire, Yohann, X , Emy et Salomé, Tonton Chips, Rémi, Tof, Foufou, St Pouf, Étienne et Maud et Chouquette.Contents Extended Abstract (French) 1 1 Introduction 5 1.1 Cas d’Étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Notations et Notions Mathématiques . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3 Vérification de Systèmes de Transition . . . . . . . . . . . . . . . . . . . . . . . 12 2 Découverte d’Invariants 17 2.1 Élimination de Quantificateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Une Architecture Collaborative . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.3 Découverte d’Invariants Potentiels par QE . . . . . . . . . . . . . . . . . . . . 29 2.4 Le Framework Formel Stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3 Conclusion 37 3.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 I Introduction 1 4 Problem 3 4.1 Lustre: A Synchronous Programming Language . . . . . . . . . . . . . . . . . 3 4.2 Safety Critical Avionics Systems Verification . . . . . . . . . . . . . . . . . . . 9 5 Mathematical Background and Notation 13 5.1 Many-Sorted First-Order Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 SAT and SMT Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3 SMT: Standard, Implementations and Additional Features . . . . . . . . . . . 32 6 Transition Systems, State Invariant Verification 35 6.1 Transition Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.2 Bounded Model Checking and k-induction . . . . . . . . . . . . . . . . . . . . 39 6.3 Invariant Discovery and Other Techniques . . . . . . . . . . . . . . . . . . . . 476.4 Motivation and Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . 53 II Invariant Discovery Powered By Quantifier Elimination 55 7 SMT-Based Quantifier Elimination 59 7.1 Monniaux’s QE Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.2 Extension to Booleans and Integer Octagons . . . . . . . . . . . . . . . . . . . 60 7.3 Improving Extrapolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.4 Benchmarking Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 8 Invariant Discovery in a K-induction-based Framework 73 8.1 A Proof Engine Architecture Allowing Continuous Invariant Integration . . . 73 8.2 Invariant Discovery as a Quantifier Elimination Problem . . . . . . . . . . . . 75 8.3 Property Directed Reachability Modulo Theory . . . . . . . . . . . . . . . . . . 76 9 HullQe: QE And Convex Hull Computation 83 9.1 Extracting Potential Invariants From Pre-Images . . . . . . . . . . . . . . . . . 84 9.2 Exhaustive Exact Convex Hull Enumeration . . . . . . . . . . . . . . . . . . . 89 9.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 9.4 End-to-end Verification Of A Functional Chain . . . . . . . . . . . . . . . . . . 100 III The Stuff Formal Framework 103 10 Architecture and Transition System Representation 105 10.1 The Actor Formalism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 10.2 Stuff: Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 10.3 Stream Systems and Unrolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 11 Assumptio: an SMT-lib 2 Compliant Solver Wrapper 121 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 11.2 Architecture and Backend Solvers . . . . . . . . . . . . . . . . . . . . . . . . . 124 11.3 Source Code, User Manual and Integration in Stuff . . . . . . . . . . . . . . . . 127 IV Conclusion 129 12 Summary and Perspectives 131 12.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 12.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13213 References 137 V Appendices 147 A Use Cases 149 A.1 The Rockwell Collins Triplex Voter . . . . . . . . . . . . . . . . . . . . . . . . . 149 A.2 A Reconfiguration Logic System . . . . . . . . . . . . . . . . . . . . . . . . . . 151List of Figures 1.1 A Single Computation Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Triple Channel Functional Chain. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Règles de calcul de l’analyse structurelle. . . . . . . . . . . . . . . . . . . . . . 24 2.2 Une architecture collaborative basée sur la k-induction. . . . . . . . . . . . . . 28 2.3 Polyhedra examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4 ECH de polyhèdres entiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.5 Découverte d’invariant relationnels sur le système de reconfiguration. . . . . 32 2.6 Logique de vote en dimension deux. . . . . . . . . . . . . . . . . . . . . . . . . 34 2.7 Une chaîne fonctionnelle simplifiée. . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1 A simple Lustre program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Network representation of the bounded node. . . . . . . . . . . . . . . . . . . 7 4.3 The observer pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 Bounded liveness property as a safety property. . . . . . . . . . . . . . . . . . 9 4.5 A Single Computation Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6 Triple Channel Functional Chain. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7 The shuffle mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Push and pop example, assertion stack on the right. . . . . . . . . . . . . . . . 33 6.1 Reachable state space of SDC(4, 2), nodes show the values of x and y. . . . . 42 7.1 Activation conditions and cause propagation rules. . . . . . . . . . . . . . . . 66 7.2 Benchmark results part 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.3 Benchmark results part 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.4 Experimental results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 8.1 k-induction based collaborative framework. . . . . . . . . . . . . . . . . . . . . 74 8.2 Asynchronous exact convex hull computation. . . . . . . . . . . . . . . . . . . 80 9.1 Polyhedra examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 9.2 HullQe abstract view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 9.3 Discovering new relations using convex hulls. . . . . . . . . . . . . . . . . . . 869.4 ECH calculation on the double counter with nx = 10 and ny = 6. . . . . . . . 86 9.5 Duplex voter equations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 9.6 Simple voting logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 9.7 Hullification redundancy issues. . . . . . . . . . . . . . . . . . . . . . . . . . . 93 9.8 View of HullQe internal processes. . . . . . . . . . . . . . . . . . . . . . . . . . 95 9.9 Reconfiguration subsystem with observer. . . . . . . . . . . . . . . . . . . . . . 96 9.10 Triplex voter equations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.11 Running example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 10.1 Message handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 10.2 A code extract of the handleMessage function of the k-induction Method. . 112 10.3 Actor hierarchy in Stuff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 10.4 A trace of a Stream System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 10.5 Traces of the double counter system. . . . . . . . . . . . . . . . . . . . . . . . . 117 11.1 Hi-level view of user interaction and internal architecture. . . . . . . . . . . . 125PART Extended Abstract (French) Les systèmes critiques sont des systèmes dont les défaillances ont des conséquences catastrophiques telles que la perte de vies humaines ou de fortes retombées économiques. On les trouve typiquement dans des domaines tels que l’aérospatiale, l’aéronautique, l’automobile, le ferroviaire, le nucléaire, les équipements médicaux, la conception de matériel informatique. . . Il est donc d’un grand intérêt (i) d’établir une spécification précise de ces systèmes, et (ii) de s’assurer de la correction du produit final par rapport à sa spécification, i.e. de vérifier le produit final. L’étude présentée dans ce mémoire se concentre sur la vérification de composants logiciels de systèmes critiques embarqués avioniques. Il y a encore peu de temps, les industriels de notre domaine suivaient une approche dite d’assurance qualité basée sur les processus. Cette approche consiste à examiner minutieusement les processus menant à la création d’un produit. Si les processus sont jugés comme étant de confiance, le produit final est également jugé de confiance. En avionique par exemple, la conception ainsi que la production des composants matériels sont suivi de près au niveau processus. Des échantillons sont ensuite préleés afin de tester leur cohérence avec la spécification du produit. Les récentes normes avioniques DO-178C –et sont supplément DO-333 concernant les méthodes formelles– publiées par la RTCA1 – montrent une volonté de consolider cette approche basée sur les processus, par une assurance qualité davantage basée sur les produits. C’est à dire de vérifier mathématiquement l’adéquation entre le produit final et sa spécifi- cation. Dans le domaine du logiciel, il existe des méthodes automatisables permettant de prouver de telles propriétés. Ces méthodes mises au point par la communauté informatique sont appelées méthodes formelles. Contrairement aux composants matériels, les logiciels sont constitués de “0” et de “1” pouvant être dupliqués sans erreur, renforçant l’intérêt de les vérifier. Les systèmes critiques embarqués avioniques sont généralement développés au moyen de language haut-niveau (niveau modèle) différant du language d’implémentation final (niveau code). Les méthodes formelles fournissent des outils pour toutes les étapes du 1http://www.rtca.org/développement : • la spécification formelle [71, 35] propose des languages à la sémantique mathématique permettant d’exprimer ce que le système doit faire ; • la vérification des modèles par rapport à leur spécification formelle [16, 17, 23, 55, 12, 6] permettent de prouver que la spécification est respectée ; • la génération de code à partir des modèles [13] produit du code respectant la sémantique du language de conception haut-niveau, préservant ainsi l’effort de vérification au moyen de compilateurs certifiés ou prouvés. L’étude présentée dans ce mémoire se concentre sur la vérification automatique de mod- èles. En effet, même si les organismes de certification encouragent leur utilisation, les méthodes formelles ne sont pas capables à l’heure actuelle de résoudre les problèmes rencontrés dans l’industrie. En pratique la vérification de propriétés fonctionnelles arbitraires sur des systèmes réalistes demande souvent un travail d’expert autant sur le plan des systèmes analysés que sur la (les) technique(s) employée(s). L’essort des méthodes formelles dans le monde industriel est limité par ces interventions coûteuses financiérement et temporellement. L’ambition de cette thèse est d’améliorer l’état de l’art de la vérification formelle dans notre domaine d’application en (i) améliorant son automatisation sur des systèmes correspondant à des patrons de conception rencontrés dans les systèmes avioniques ; (ii) trouvant des preuves pouvant être rapidement vérifiées par différents outils afin d’assurer leur véracité. Pour atteindre ces objectifs nous proposons d’étudier la collaboration de méthodes formelles existantes –telles que la résolution SMT, la k-induction, l’élimination de quantificateurs, etc.– afin d’introduire une méthodologie visant à la découverte automatique de lemmes facilitant la conduite d’une preuve. De plus, cette étude s’intéresse en particulier aux algorithmes parallèles, suivant la tendance actuelle des multi-cœurs. Cette étude s’intéresse à l’analyse de systèmes réactifs embarqués [38]. Ces systèmes échantillonnent leur environnement au moyen de capteurs, et calculent une commande destinée à un actuateur. L’échantillonage est effectué à intervalles réguliers spécifiés par la fréquence du système. Plus particulièrement nous considérons des composants logiciels de systèmes réactifs, contribuant à la sûreté de chaînes fonctionnelles, i.e. de systèmes rassemblant des capteurs, des unités de calcul en réseau, des actuateurs, etc. Nous introduisons plus précisemment ces systèmes dans le Chapitre 1, dans lequel nous introduisons également les notions sous-jacentes à leur représentation mathématique, 2ainsi que l’état de l’art en vérification formelle. Nous introduisons ensuite notre contribution principale dans le Chapitre 2. Tout d’abord nous proposons des améliorations à l’algorithme d’élimination de quantificateurs de Monniaux [56] permettant de calculer des pré-images sur nos systèmes industriels. Nous exposons ensuite nos heuristiques de génération d’invariants potentiels dans le cadre d’un framework collaboratif basé sur la k-induction, et présentons nos expérimentation sur nos systèmes. La Section 2.4 présente Stuff2 , notre implémentation de l’architecture et des techniques présentées en Section 2.2. Enfin, le Chapitre 3 conclut sur les résultats de l’étude et offre quelques éléments de perspective. 2 Suff’s The Ultimate Formal Framework 3CHAPTER 1 Introduction Ce chapitre est un résumé en francais de la Partie I du mémoire. Comme mentionné précédemment, l’aspect logiciel de ces systèmes est tout d’abord dévelopé au niveau modèle avant que le code bas niveau destiné à des architectures temps réel ne soit généré automatiquement en préservant la sémantique du modèle. Nous nous intéressons en particulier au langage flot de données synchrone Lustre [36] décrit en détail dans le Chapitre 4.1. Un modèle Lustre a une sémantique de système de transition dans lequel des calculs instantannés sont effectués à une certaine fréquence afin de produire un signal de sortie en fonction des signaux d’entrée. Nous présentons les systèmes auquels nous nous intéressons, appelés chaînes fonctionnelles, en Section 1.1. Avant d’analyser un modèle Lustre, il est nécessaire d’en extraire sa sémantique sous forme d’un système de transition. Ce chapitre présente, en Section 1.2, les notions mathématiques nécessaires pour la représentation et l’analyse des systèmes de transitions. La Section 1.3 présente l’état de l’art des méthodes s’intéressant à leur vérification. 1.1 Cas d’Étude La Figure 1.1 présente une chaîne de calcul correspondant à la fonction de “controle de l’angle de tangage de l’avion”. Les capteurs sont tripliqués afin de réduire le taux de dé- faillance de l’échantillonnage. Lors de chaque cycle, la chaîne échantillonne les capteurs de Channel Sensors Order (x3) Speed (x3) Pitch (x3) SMon SMon SMon Voter Voter Voter Law AMon Actuator Figure 1.1: A Single Computation Channel.1.1 Cas d’Étude Introduction Sensors Order (x3) Speed (x3) Pitch (x3) Channel1 Channel2 Channel3 Reconf Reconf1 Reconf2 Reconf3 Actuator Figure 1.2: Triple Channel Functional Chain. vitesse (Speed), de tangage (Pitch) ainsi que la commande produite par le pilote (Order). Des moniteurs de capteurs (SMon) examinent ces signaux afin de détecter des défaillances temporaires ou permanentes, telles que des valeurs en dehors de l’intervalle légal du capteur. Les signaux entrent ensuite dans un système de vote (Voter) chargé de produire un signal unique à partir de ses trois entrées. Le bloc suivant est la loi de commande (Law) de la chaîne qui calcule le signal commandant l’actuateur grâce à une unique valeur de vitesse, tangage et d’ordre du pilote. Le signal passe ensuite par un moniteur d’actuateur (AMon) s’assurant que la commande est correctement réalisée. En pratique, les concepteurs de chaînes fonctionnelles tripliquent les canaux de calcul afin de réduire davantage le taux de défaillance. Comme présenté sur la Figure 1.2, les calculs sont effectués par trois chaînes redondantes évoluant sur des unités de calcul sé- parées et communiquant au moyen de câbles distincts. Un mécanisme de reconfiguration (Reconf) distribué sur les trois unités de calcul décide de la chaîne contrôlant effectivement l’actuateur, et est capable de reconfigurer le système dans le cas où une chaîne est jugée corrompue. Quels que soit les signaux produits par les différentes chaînes, la reconfiguration doit s’assurer qu’aucune commande dangereuse pour l’actuateur ou pour l’avion n’est produite par l’architecture tripliquée, et doit prévenir le pilote en cas de défaillance. Il est à noter qu’une valeur de sortie incorrecte ne doit pas immédiatement faire basculer le statut de la chaîne la produisant à “corrompue”. La défaillance peut n’être que temporaire, par exemple à cause d’une perturbation électromagnétique causée par le passage de la foudre à proximité de l’avion. C’est pourquoi la défaillance n’est considérée permanente que si la valeur de sortie reste incohérente pendant plus de n cycles. Les chaînes fonctionnelles sont donc des systèmes extrêmement complexes, et il en est de même pour leur spécification [67]. La vérification de la partie logicielle d’une chaîne fonctionnelle complète est donc d’une grande difficulté pour les outils actuels. Même en suivant une approche modulaire, il loin d’être trivial de vérifier la correction des soussystèmes séparément. L’objectif des travaux présentés dans ce mémoire est de fournir des 6Introduction 1.2 Notations et Notions Mathématiques techniques génériques pour la vérification automatique de systèmes tels que ceux implé- mentant la logique de vote, ou la logique de reconfiguration. Ces systèmes utilisent largement l’arithmétique entière linéaire au travers des nombreux compteurs qu’ils utilisent pour confirmer les défaillances et transférer le contrôle de l’actuateur d’une chaîne à une autre. La logique de vote par exemple se doit de maintenir une certaine continuité dans les valeurs qu’elle produit : la loi de commande est pensée pour des valeurs en accord avec le monde réel et pourrait avoir un comportement imprévisible en cas de discontinuités irréalistes dans ses signaux d’entrée. Plus précisemment nous nous focaliserons sur le “triplex voter”, un système fourni par Rockwell Collins implémentant une logique de vote. Le code de ce système est disponible dans l’annexe A. Les systèmes de loi de commande diffèrent du vote et de la reconfiguration car ils sont basés sur des équations différentielles. Ils peuvent être nonlinéaires ou n’être analysable qu’au moyen de méthodes non-linéaires et sortent du cadre de cette étude. 1.2 Notations et Notions Mathématiques 1.2.1 Logique du Premier Ordre Multi-Sortée La formalisation de la notion de système de transition s’appuie traditionellement sur le système formel appelé logique du premier ordre1 multi-sortée, ou Many-Sorted First-Order Logic (MSFOL), défini en Section 5.1 de façon similaire au standard SMT-LIB 2 [4]. MSFOL permet de définir des logiques permettant à leur tour de construire des termes en combinant des symboles dans le cadre de règles assurant le typage des expressions obtenues. Syntaxe. Les symboles représentent des fonctions n’ayant pas d’interprétation fixée, mais auquelles sont associées des rangsfaisant intervenir les types ou sortes autorisés par la logique. Le symbole “+” par exemple aurait typiquement pour rangs (Int, Int) : Int et(Real, Real) : Real. Le symbole “3”, respectivement “3.0”, peut avoir un unique rang () : Int, respectivement () : Real. Les sortes sont des noms et n’ont pas non plus, à ce niveau, d’interprétation. La notion de signature (Définition 5.1.1) déclare les sortes, les symboles, leurs rangs, ainsi que les variables –sur lesquelles nous reviendrons un peu plus tard– composant la logique. Les règles de typage définissent les termes légaux : avec les symboles et les rangs introduits ci-dessus par exemple, le terme +(3, 3), c’est à dire “l’application du symbole + aux symboles 3 et 3” est bien typé, de sorte Int. Le terme +(3, 3.0) au contraire n’est pas bien typé. Dans la suite de ce mémoire, un terme sera toujours supposé bien typé, sauf indication 1Les lecteurs initiés à la logique du premier ordre remarqueront que nous ne mentionnerons quasiment pas les quantificateurs dans cette section. En effet nous ne considérerons que des termes n’en utilisant pas par la suite. Les quantificateurs sont formellement traités dans la Section 5.1 de la partie anglaise du mémoire. 71.2 Notations et Notions Mathématiques Introduction contraire. Il est à noter qu’en pratique, on impose que toutes les signatures contiennent au moins les sortes et les symboles –ainsi que leurs rangs– de la signature Core. Core signature. Core est la signature composée du sorte Bool ainsi que des symboles et des signatures ∨ (Bool, Bool) : Bool ∧ (Bool, Bool) : Bool ¬ (Bool) : Bool > () : Bool ⊥ () : Bool = (Bool, Bool) : Bool Les termes de sorte Bool sont appelées formules, et les symboles “∨”, “∧”, “¬” sont appelés respectivement disjonction (ou), conjonction (et), négation. De plus, nous exigeons également que pour chaque sorte σ apparaissant dans une logique le symbole “=” ait, entre autres, le rang (σ, σ) : Bool. Sémantique. Les notions introduites ci-dessus définissent la syntaxe de la logique. Pour donner une sémantique aux termes, il est nécessaire d’y associer une sémantique. Une structure (Définition 5.1.8) interprète les sortes d’une signature en ensembles de valeurs concrètes, et les symboles comme des fonctions sur ces ensembles de façon consistante avec leur rang. Une structure permet également d’interpréter des termes de la logique au moyen d’une fonction d’interprétation I. Une application de symbole s(terme1, . . . , termen) est évaluée récursivement : I(s)  I(terme1), . . . , I(termen)  . Une structure se doit de respecter les contraintes suivantes : • l’interprétation du sorte Bool est l’ensemble {T, F} (True et False) ; • I(>) est T ; • I(⊥) est F ; • I(¬)(p) est T si et seulement si p est F ; • I(∨)(p, q) est T si et seulement si p ou q est T ; • I(∧)(p, q) est T si et seulement si p et q est T ; • I(=)(p, q) est T si et seulement si p est la même valeur concrète que q. Étant donnée une signature Σ, une formule φ est satisfiable s’il existe une structure de Σ qui évalue φ à T. Une telle structure est appelée un modèle de φ. Si toute structure de Σ est un modèle de φ, alors φ est une tautologie ou est valide. Validité et satisfiabilité sont 8Introduction 1.2 Notations et Notions Mathématiques des notions duales. En effet, si φ est valide alors sa négation, ¬φ, n’est pas satisfiable, ou insatisfiable. Inversement, si φ est insatisfiable alors ¬φ est valide. Soit Σ un signature et φ et ψ deux formules. Alors • φ et ψ sont equisatisfiables si φ est satisfiable si et seulement si ψ est satisfiable ; • ψ est une conséquence sémantique de φ, noté φ |= ψ, si tout modèle de φ est un modèle de ψ ; • ψ est équivalente sémantiquement à φ, noté φ ≡ ψ, si φ |= ψ et ψ |= φ. Satisfiabilité modulo théorie. La notion de sémantique introduite ci-dessus n’est pas suffisante pour les problèmes auquels nous nous intéressons. Malgré la possibilité d’obtenir des résultats tels que • φ ∧ ¬φ est insatisfiable, • φ ∨ ¬φ est valide, • ¬(φ ∧ ¬φ) ≡ φ ∨ ¬φ, . . . Il n’est pas réaliste de raisonner au niveau arithmétique sans contraindre l’interprétation de symboles tels que “+”, “42”, “7.13” dans des signatures les autorisant. C’est pourquoi une logique est également composée d’une ou plusieurs théorie(s) restreignant l’interprétation des symboles et sortes non purement propositionnels, les symboles et sortes autres que ceux apparaissant dans Core. Une formule φ est alors satisfiable modulo théorie si elle admet un modèle autorisé par la ou les théories de la logique considérée. Dans la suite de ce mé- moire, nous utiliserons majoritairement des fragments de MSFOL permettant de construire des termes arithmétiques linéaires réels ou entiers au moyen des symboles habituels “+”, “−”, “0”, “1”, . . . , “0.0”, “2.3”, . . . dont l’inteprétation correspond à la sémantique usuelle de l’arithmétique. Nous dirons dans la suite de ce mémoire qu’une formule φ est satisfiable pour “satisfiable modulo théorie” pour des raisons de lisibilité. Précisions sur la notion de variable d’une signature. Comme c’est le cas dans le standard SMT-LIB 2, les variables d’une signature ne peuvent apparaître dans des termes bien typés que si elles sont liée par un quantificateur (∃ ou ∀) ou un let-binding (parallèle). Nous ne considérerons pas de termes quantifiés dans ce mémoire et omettons leur définition pour le moment ; davantage d’informations sont disponibles dans les sections 5.1.1 et 5.1.2 définissant formellement MSFOL, en particulier dans la Définition 5.1.3 pour la syntaxe abstraite, la Définition 5.1.4 pour le typage, et la Définition 5.1.10 pour leur sémantique. Nous utilisons 91.2 Notations et Notions Mathématiques Introduction les let-binding-s pour définir formellement le déroulement de la relation de transition d’un système de transition en Section 6.1, mais nous n’en ferons pas usage dans ce résumé étendu en français par soucis de concision. Nous renvoyons donc le lecteur aux sections et définitions cîtées pour les quantificateurs traitant également de la syntaxe et de la sémantique des let-binding-s dans MSFOL. Les solveurs SAT et SMT sont des outils extrêmement efficaces capables, étant donnée une formule φ exprimée dans un fragment de MSFOL, de répondre à la question “φ est-elle satisfiable?”. Si c’est le cas, le solveur produit un modèle de φ. Par la suite nous abrégerons souvent “satisfiable” par “sat” et “insatisfiable” par “unsat”. Le niveau de performance actuel de ces outils est le fruit de plusieurs décennies de recherche et d’optimisation dé- clenchées par les travaux précurseurs de [27, 28] mettant au point l’algorithme aujourd’hui standard, nommé DPLL en l’honneur de ses créateurs (Davis-Putnam-Logemann-Loveland). Les premiers solveurs ne s’intéressaient qu’au problème de la satisfiabilité de formules purement propositionnel, appelé “problème SAT”. Les avancées considérables [9] dûes, entre autres, à l’équipe à l’origine du solveur SAT Chaff [59] ont à terme rendu possible d’adapter l’approche au problème de la satisfiabilité modulo théorie (SMT). La Section 5.2 de ce mé- moire présente l’algorithme DPLL dans le cas SAT ainsi que dans le cas SMT au travers du formalisme abstract DPLL [60]. L’initiative SMT-LIB [4] vise a fédérer les différents solveurs en proposant des descriptions rigoureuses des théories qu’ils utilisent, ainsi qu’un langage d’entrée commun permettant la construction d’une librairie de benchmarks impressionnante. L’objectif est de faciliter l’utilisation et la comparaisons des solveurs disponibles. Les solveurs majeurs actuels sont compatible avec le récent standard SMT-LIB 2 [4], les principaux étant les suivants : • Z3 [29], developpé à Microsoft Research, • MathSAT 5 [20] de l’Université de Trento, et • CVC4 [3], developpé conjointement par l’Université d’Iowa et l’Université de New York. 1.2.2 Systèmes de Transition Les systèmes de transition encodent une sémantique de trace d’états partant d’états dits initiaux. Les états représentent l’état interne du système à un moment donné. Un système de transition encode les transitions légales pour le système lui permettant de passer d’un état à un autre. Les systèmes de transition ayant un nombre fini d’états peuvent, en théorie, être représentés de façon exhaustive en listant tous les états initiaux et tous les couples détats se succédant. En pratique malheureusement les systèmes finis que nous considérons ne sont 10Introduction 1.2 Notations et Notions Mathématiques pas représentables de cette façon à cause du nombre gigantesque d’états qu’ils peuvent atteindre, sans parler des systèmes infinis. Il est donc plus réaliste de spécifier les états initiaux ainsi que la relation de transition au moyen de formules dans un fragment de MSFOL. Étant donnée une logique L, l’état interne du système de transition S est représenté par un vecteur de variables d’états Var ∆= hv 1 , . . . , vn i. Une fonction D associe à chaque variable un sorte de L. Une formule d’init I(Var) portant sur les variables d’états défini les états initiaux : ses modèles sont exactement les états initiaux du système. Un deuxième formule T(Var, Var0 ) porte sur Var vu comme “l’état courant” ainsi que sur une version primée de Var représentant “l’état suivant”. Les modèles de cette formule de transition sont exactement les paires d’états du système se succédant. Afin d’encoder des traces d’états semous forme de formules, nous augmentons la logique avec les symboles v 1 0 , . . . , vn 0 , v1 1 , . . . , vn 1 , . . . que nous appelons des variables d’état déroulées. Nous notons la logique ainsi obtenue L(S). Par soucis de lisibilité, nous notons si le vecteur hv 1 1 , . . . , vn 1 i. Il est à présent possible de construire une formule dont les modèles sont , par exemple, exactement les états atteignables en deux transitions à partir des états initiaux du système : φ ∆= I(s0) ∧ T(s0, s1) ∧ T(s1, s2). Si φ est satisfiable, un modèle de φ assigne des valeurs concrètes à s0, s1 et s2 telles que s0 est initial et les transition entre s0 et s1 et entre s1 et s2 sont légales. Soit Scpt le système de transition composé d’une seule variable d’état n de sorte Int, de la formule initiale I(n) ∆= (n = 0) et de la formule de transition T(n, n0 ) ∆= (n 0 = n + 1). Scpt représente un simple compteur initializé à zéro et s’incrémentant à chaque transition. Dans ce cas, la formule φ ci-dessus est donc φ ∆= n0=0 z }| { I(n0) ∧ n1=n0+1 z }| { T(n0, n1) ∧ n2=n1+1 z }| { T(n1, n2). Il est alors possible de demander à un solveur SMT si φ est satisfiable, ce qui est le cas, puis d’en obtenir un modèle : {n0 7→ 0, n1 7→ 1, n2 7→ 2}. Il est de plus possible d’ajouter des contraintes aux variables d’état déroulées, comme suit. n0=0 z }| { I(n0) ∧ n1=n0+1 z }| { T(n0, n1) ∧ n2=n1+1 z }| { T(n1, n2) ∧ contrainte sur n2 z }| { (n2 ≤ 0) Le solveur SMT nous répond alors que la formule n’est pas satisfiable. Nous lui avons donc fait prouver qu’il n’était pas possible qu’un état à deux transitions d’un état initial soit négatif ou nul. Il est important de noter à ce stade que les modèles de la formule de transition ne dénotent pas forcemment des états successeurs atteignables du système. Dans l’exemple décrit 111.3 Vérification de Systèmes de Transition Introduction ci-dessus, {n0 7→ −10, n1 7→ −9} est un modèle de la formule T(n0, n1), mais ni l’un ni l’autre ne sont atteignable. 1.3 Vérification de Systèmes de Transition Nous nous intéressons à la vérification de propriétés de sûreté sur des systèmes de transition. Ce problème correspond à une analyse d’atteignabilité. Étant donnés un système de transition S et un objectif de preuve PO, existe-t-il un entier n ≥ 0 tel que I(s0) ∧ T(s0, s1) ∧ · · · ∧ T(sn-1, sn) ∧ ¬PO(sn) (1.1) soit satisfiable ? Si c’est le cas un modèle peut être extrait et constitue un contre-exemple, c’est à dire une trace partant d’un état initial menant à une falsification de l’objectif de preuve PO. Si ce n’est pas le cas, PO est un invariant de S : aucun état atteignable du système ne falsifie PO. Un argument mathématique, une preuve en attestant doit être produit. Dans le reste de ce mémoire nous nous focaliserons sur la recherche de preuve dans le cas ou PO est effectivement un invariant de S. 1.3.1 K-induction Pour ce faire nous utilisons la technique classique de la k-induction2 , consistant à trouver un entier k ≥ 1 tel que deux formules soient unsat : Basek (I, T, PO) ≡ Initial state z }| { I(s0) ∧ trace of k-1 transitions z ^ }| { i∈[0,k−2] T(si , si+1) ∧ PO falsified on some state z _ }| { i∈[0,k−1] ¬PO(si) Stepk (T, PO) ≡ ^ i∈[0,k−1] T(si , si+1) | {z } trace of k transitions ∧ ^ i∈[0,k−1] PO(si) | {z } PO satisfied on first k states ∧ ¬PO(sk) | {z } PO falsified by last state . La formule Basek aussi appelée instance de base est satisfiable si une falsification de l’objectif de preuve peut être atteinte en k −1 transitions à partir des états initiaux. Un mod- èle de l’instance de base est donc un contre-exemple exhibant une falsification de l’objectif de preuve. Si Basek n’est pas satisfiable, alors tous les états atteignables en k − 1 transitions à partir des états initiaux vérifient l’objectif de preuve. La formule Stepk aussi appelée instance de step n’est pas satisfiable si à partir du dernier état d’une trace de k états vérifiant PO, il n’est pas possible d’atteindre une falsification de PO en une transition. Si les deux formules sont insatisfiable, toute trace partant des états initiaux ne peut atteindre une falsification de PO en k − 1 transitions car l’instance de base n’est pas satisfiable. Le 2 Introduite formellement dans la Section 6.2. 12Introduction 1.3 Vérification de Systèmes de Transition fait que Stepk ne soit pas satisfiable permet de conclure qu’il n’est pas possible d’atteindre une falsification de PO en une transition à partir d’une trace initialisée de k états (k − 1 transitions). Par récurrence, il n’existe donc pas d’entier n ≥ 0 tel que l’Équation 1.1 soit satisfiable, et PO est bien un invariant de S. En revanche, le fait que l’instance de step soit satisfiable ne permet pas de conclure. La formule de step ne prend pas en compte les états initiaux et il n’y a aucune garantie que ses modèles dénotent des états atteignables. On parle dans ce cas de contre-exemple fallacieux. Il est cependant possible, en théorie, de chercher itérativement à établir une preuve de k-induction à partir de k = 1 en augmentant la valeur de k jusqu’à ce que les deux formules soient insatisfiable –ou que l’instance de base soit satisfiable, indiquant l’existence d’une falsification de PO. Malheureusement, la complexité des formules augmente rapidement à chaque incré- ment de k et il n’est pas réaliste sur des systèmes réalistes de dérouler la formule de transition un grand nombre de fois. Les instances de base et de step deviennent rapidement trop complexe et le solveur SMT n’est plus capable de les traiter efficacement. Pour remédier à ce problème il est nécessaire de renforcer l’objectif de preuve : en découvrant des invariants du système. L’intérêt est de contraindre l’instance de step dans le but de bloquer les contre-exemples fallacieux. Les invariants non-relationels sont en général faciles à découvrir car ils ne mentionnent qu’une seule variable d’état et correspondent à des bornes souvent présentes dans la description du système, comme par exemple la valeur maximale d’un compteur. Les invariants relationels en revanche expriment un lien entre plusieurs variables d’état et ne sont que rarement apparents ce qui rend difficile leur découverte. Ils sont en général plus informatifs que les invariants non-relationels et donc plus efficaces pour l’exclusion de contre-exemples de step fallacieux. 1.3.2 État de l’art Les techniques formelles récentes se concentrent sur la recherche d’invariants du système permettant de renforcer un objectif de preuve afin de pouvoir le prouver par k-induction pour un k relativement petit. L’interprétation abstraite (AI [23]) est une technique travaillant sur une abstraction de la sémantique du système qu’elle analyse. Cette approche est correcte dans la mesure ou tout invariant pour la sémantique absraite est également un invariant pour la sémantique concrète du programme. L’inverse n’est pas vrai cependant, AI n’est donc pas une technique complète car l’abstraction peut être trop grossière et donc rater des invariants pour la séman- 131.3 Vérification de Systèmes de Transition Introduction tique concrète. Les deux outils d’AI les plus intéressants dans notre cadre sont (i) Astrée [10] qui analyse du code C, et (ii) NBac [43] analysant des modèles Lustre en combinant des calculs de point fixes avants et arrières. L’interprétation abstraite est une technique puissante, mais elle est loin d’être automatique. En effet de nombreux paramètres contrôle les techniques d’abstraction et doivent être spé- cifiés par un expert en AI ayant une bonne compréhension du système analysé. Interpolation-based Model Checking (IMC) est une technique proposée par McMillan [55] basée sur les solveurs SMT et le calcul d’interpolants paramétré par un entier n. Cette approche consiste à calculer itérativement une suite de sur-approximations des états atteignables en n transitions excluant de plus en plus de contre-exemples de l’instance destep de n-induction à chaque itération. L’algorithme s’arrête quand il détecte que tous les contreexemples de step sont bloqués, indiquant qu’un invariant du système permettant de prouver l’objectif de preuve par n-induction a été découvert. Malheureusement IMC nécessite de dérouler la relation de transition un nombre relativement important de fois. Le méchanisme d’abstraction rend l’approche moins explosive que la k-induction, mais limite considérablement son passage à l’échelle sur des systèmes tels que les notres. Property Directed Reachability (PDR, aussi appelé IC3 [12, 34]) ne construit pas de formule déroulant la formule de transition plus d’une fois. L’approche consiste a diviser la complexité de l’analyse en un grand nombre de problèmes plus simples. Une séquence de frames bloquant des états dangereux est construite incrémentalement en mélangeant analyse arrière de la négation de l’objectif de preuve et propagation en avant prenant en compte les états initiaux. Cette technique a originellement été mise au point pour des systèmes purement propositionels ; des généralizations au cas SMT ont été proposées [40, 19] et montrent des résultats intéressants. Nous présentons notre propre généralisation dans la Section 8.3. 1.3.3 Motivation et Plan du Mémoire La découverte d’invariants pour des systèmes industriels est un exercice difficile. Découvrir des invariants relationnels dirigés par l’objectif de preuve est cependant souvent indispensable au succès d’une analyse. Les méthodes décrites ci-dessus ne fonctionnent pas sur nos systèmes car ils ne sont pas capables d’inférer des invariants relationels, à l’exception de l’interprétation abstraite qui nécessite généralement une intervention experte pour les découvrir. Notre intuition est qu’il peut s’avérer plus efficace de les deviner, i.e. de produire des invariants potentiels grâce à une heuristique et de laisser à un moteur de k-induction le soin de séparer les invariants potentiels falsifiables de ceux étant prouvables. 14Introduction 1.3 Vérification de Systèmes de Transition Le moteur de preuve Kind [47] suit cette approche : des templates tirés d’une base de données sont instanciés sur les variables d’états et les constantes apparaissant dans le systèm [46]. Un moteur de k-induction est en suite chargé d’identifier les invariants. Cependant les invariants ainsi trouvés ne sont pas dirigés par l’objectif de preuve, il n’y a donc pas de garantie qu’ils aident à prouver l’objectif de preuve en bloquant des contre-exemples fallacieux. De plus, cette approche est problématique sur des systèmes complexe car le moteur de k-induction peut se retrouver noyé par le nombre d’invariants potentiels générés. Le fait que la base de données de templates grossit généralement avec le temps ne fait qu’augmenter ce risque. Notre contribution se sépare en deux parties. Premiérement, nous définissons une architecture parallèle basée sur un moteur de k-induction permettant à des méthodes de dé- couverte d’invariants de collaborer entre elles et avec la k-induction. Deuxiémement, nous proposons une heuristique de génération d’invariants potentiels dirigée par l’objectif de preuve. Nous démontrons sa capacité à découvrir des invariants relationnels renforçant les objectifs de preuve sur des systèmes standards dans le domaine des systèmes embarqués critiques avioniques. Le Chapitre 2 décrit notre méthodologie. Nous commençons par améliorer l’algorithme d’élimination de quantificateurs (QE) introduit par Monniaux dans la Section 2.1, en termes de performance mais aussi de pouvoir d’expression des formules qu’il est capable de traiter. Nous introduisons ensuite notre architecture parallèle collaborative dans la Section 2.2 et présentons une technique de découverte d’invariants par QE dans ce cadre. Nous présentons HullQe dans la Section 2.3, notre heuristique générant des invariants potentiels dirigée par l’objectif de preuve combinant élimination de quantificateurs et calcul d’enveloppes convexes. Enfin, nous concluons et donnons des perspectives pour des travaux poursuivant cette étude dans le Chapitre 3. 15CHAPTER 2 Découverte d’Invariants par Élimination de Quantificateurs L’élimination de quantificateurs est un problème fondamental en mathématiques, et constitue l’objet de recherches continues depuis des décennies. Cette section rapelle la chronologie des progrès majeurs en QE et présente les applications les plus fréquentes de la QE pour l’analyse de systèmes réactifs. En 1951, Tarski prouve la décidabilité des corps algébriquement clos en exhibant une procédure d’élimination de quantificateurs [73]. Pour décider une formule, on élimine succsessivement toutes les variables quantifiées, chaque nouvelle formule obtenue étant equi-satisfiable à la précédente, pour obtenir une formule ground, dont la valeur de vérité peut facilement être réduite à vrai ou faux. L’algorithme de Tarski étant d’une complexité non élémentaire, il est d’une utilité pratiquement nulle pour toute application. En 1975, G. E. Collins publie la technique de Décomposition Cylindrique Algébrique (CAD) [21], avec une complexité de 2 2 n où n est le nombre de variables à éliminer, certes toujours élevée mais grandement améliorée par rapport à la technique de Tarski, et permettant d’envisager quelques applications. Les premières implémentations de CAD apparaissent au début des années 1980 et ont depuis été continuellement améliorées [41]. Un autre saut en performance est effectué par Weispfenning et Loos à la fin des années 1980 avec la méthode des Substitutions Virtuelles (VS) sur les réels, d’abord pour les systèmes linéaires [52], puis pour les systèmes au plus quadratiques [79] [80]. La méthode VS est très rapide mais tend à produire des formules dont la taille explose, si bien que récemment, certains travaux comme [72] proposent d’utiliser une combinaison de CAD, VS et de simplification de formule à la volée pour traiter des problèmes non linéaires de QE issus de problèmes de vérification difficiles. Aujourd’hui, des implémentations de ces techniques de QE générales sont disponibles dans des suites logicielles telles que QEPCAD, Redlog, Matlab, Maple, etc.. Globalement, les méthodes de QE générales non linéaires restent très coûteuses, ce qui justifie l’intéret de la recherche sur les algorithmes de QE très efficaces pour l’arithmétique linéaire réelle, entière, ou combinée réelle-entière. En effet, le cadre linéaire suffit pour mod- éliser de nombreuses classes de systèmes très courants dans les applications critiques : les2.1 Élimination de Quantificateurs Découverte d’Invariants automates hybrides linéaires, les automates temporisés, les programmes manipulant des compteurs entiers, les programmes synchrones mêlant Booléens, entiers et réels etc. La QE linéaire s’utilise principalement de la même manière que la QE générale : calcul de préimage [26], synthèse d’invariants par patrons [50], abstraction automatique de portions de programmes [57]. Donc, se doter de techniques efficaces pour ces fragments peut être extrêmement gratifiant dans les applications de vérification. La plus significative et récente des avancées dans ce domaine est celle de la QE par énumération paresseuse et projection polyé- drique publiée dans [56], et reprise dans [58]. Cette méthode capitalise les derniers progrès de la satisfiabilité modulo théories (SMT), et apporte un gain de performance notable sur les approches préexistantes. Cette méthode de QE basée SMT se trouve au cœur de notre cadre logiciel pour l’analyse de systèmes réactifs synchrones : dans [16], un calcul de préimage itéré est utilisé pour alimenter un générateur de lemmes potentiels afin de prouver une propriété sur un système de transitions. Dans cette application, c’est l’étape de QE qui constituait le principal goulot d’étranglement, ce qui nous conduisit à améliorer l’algorithme original de [56], en modifiant la phase d’extrapolation de l’algorithme. 2.1 Élimination de Quantificateurs Definition 2.1.1 (Élimination de quantificateurs) Étant donnée une formule φ de QF_LRIA et une collection V de variables de φ, l’élimination de quantificateurs consiste à produire une autre formule O de QF_LRIA telle que O soit équivalente à ∃V, φ en éliminant les variables V de φ. Cette opération est notée QE(V, φ). Par exemple, si φ ≡ (x = 39 ∧ y ≥ 3 + x) ∨ (x ≥ 7 ∧ y = 11 − x) alors un résultat possible pour QE(x, φ) serait O ≡ y ≥ 42 ∨ y ≤ 4. L’algorithme d’élimination de quantificateurs par énumération paresseuse de modèles de [56] est donné dans l’algorithme 1. Dans l’article original, φ est supposée appartenir au fragment QF_LRA et V ne contient donc que des variables réelles. Dans cet algorithme, chaque itération comporte trois phases. Premièrement, l’extraction de modèle, qui utilise un solveur SMT pour trouver un modèle de φ ∧ ¬O tant qu’il en existe, sinon l’algorithme termine. Ensuite, la phase d’extrapolation qui produit, à partir d’un modèle M de φ, une nouvelle formule E qui se veut plus générale que le modèle dont elle est issue et qui implique φ. Une définition formelle de la notion d’extrapolant, tirée de [62], est donnée ci-après : Definition 2.1.2 (Extrapolant) Soient deux formules A et B. Une formule C est un extrapolant de A et B si elle est telle que : – si A ∧ B est unsat alors C ≡ ⊥ – si A ∧ B est sat alors A ∧ C est sat et C ∧ ¬B est unsat. 18Découverte d’Invariants 2.1 Élimination de Quantificateurs Algorithm 1 QE par énumération paresseuse de modèles. Require: φ : une formule QF_LRIA Require: V : collection de variables à éliminer de φ. Ensure: O : une formule en forme DNF telle que O ≡ ∃V, φ function QE(V, φ) O ← ⊥ while isSatisfiable(φ ∧ ¬O) do M ← getModel(φ ∧ ¬O) . génération d’un modèle E ← extrapolate(φ, M) . extrapolation du modèle P ← project(E, V ) . projection de l’extrapolant O ← O ∨ P . construction incrémentale du résultat end while return O . retrouner la formule DNF end function Cette définition est instanciée de la manière suivante dans le cadre de la QE : si M est un modèle de φ, en prenant A ≡ ( V v∈Vars(φ) v = M (v)) pour caractériser le modèle et B ≡ φ, un extrapolant E est tel que : • A ∧ E est satisfiable, i.e. M(E) ≡ M(φ) ≡ >, i.e. M |= E ; • E ∧ ¬φ est insatisfiable, i.e. E =⇒ φ. Par extension, le calcul d’un tel E est appelé “extrapoler M par rapport à φ”. Dans la QE de [56], l’extrapolation de M est réalisée par la technique appelée SMTtest, par laquelle on considère l’ensemble des atomes de φ noté Atoms(φ), et l’on construit l’ensemble des littéraux impliqués par le modèle : L ≡ {si M (a) alors a sinon ¬a | a ∈ Atoms(φ)} (2.1) On a alors ( V l∈L l) =⇒ φ, i.e. ( V l∈L l) ∧ ¬φ est insatisfiable. Ensuite, on minimise L en en retirant successivement chaque littéral l 0 tel que ((V l∈L, l6=l 0 l) ∧ ¬φ) devienne satisfiable. Enfin, on retourne l’extrapolant ( V l∈Lmin l). Enfin, la phase de projection élimine de E les variables de V par une projection polyé- drique, fournie par exemple par la Parma Polyhedra Library [2]. Le résultat de chaque projection nourrit la construction de la formule DNF résultat O, qui est équivalente à (∃V, φ) et ne contient plus aucune variable de V lorsque l’algorithme termine, i.e. lorsque φ ∧ O n’a plus de modèle. Il est important de retenir le rôle clef joué par l’extrapolation dans l’algorithme de QE. C’est en effet sa capacité à généraliser le modèle qui va permettre de limiter le nombre d’itérations de la boucle principale. Plus un extrapolant est général, plus sa projection est 192.1 Élimination de Quantificateurs Découverte d’Invariants générale, et sa négation bloque davantage de modèles de la formule φ. Dans l’algorithme original, la plus grande partie de l’exécution est passée à généraliser les modèles. C’est ce qui justifie notre travail sur l’extrapolation afin d’améliorer l’algorithme de QE. 2.1.1 Projection combinée d’atomes booléens, entiers et réels L’algorithme de QE original imposait que les formules appartiennent au fragment linéaire réel QF_LRA (variables réelles, relations et combinateurs booléens uniquement). Nous généralisons ici l’approche à QF_LRIA, ce qui implique d’éliminer des variables pouvant être booléennes, entières ou réelles. C’est la méthode de projection qu’il faut adapter ici. En effet, en supposant qu’un solveur SMT compatible QF_LRIA soit utilisé, les phases d’énumération de modèles et de génération d’extrapolants restent inchangées, l’essentiel du raisonnement spécifique aux théories arithmétiques et booléennes étant délégué au solveur SMT. Un extrapolant n’est maintenant plus un polyèdre de variables réelles, mais un cube c contenant des littéraux booléens, entiers et réels. Compte tenu de l’absence d’intersection de types entre entiers et réels dans le langage QF_LRIA, ce cube peut être divisé en trois cubes cbool, cint et creal tels que cbool (resp. cint, creal) ne contient que des littéraux booléens (resp. entiers, réels), et c ≡ cbool ∧ cint ∧ creal. L’ensemble V des variables à éliminer peut lui aussi être divisé en trois sous-ensembles disjoints Vbool, Vint et Vreal tels que Vbool (resp. Vint, Vreal) ne contient que des variables booléennes (resp. entières, réelles). Enfin, la propriété suivante nous permet d’obtenir trois problèmes de projection distincts : projection des variables booléennes, entières et réelles, qui peuvent être traitées en parallèle avec des méthodes dédiées. Property 2.1.1 (Séparation de quantificateurs) Soient deux formules φ1 et φ2, et deux ensembles de variables V1 et V2 tels que V1 ∩ F V (φ2) = ∅, V2 ∩ F V (φ1) = ∅, et F V (φ1) ∩ F V (φ2) = ∅, alors (∃V1 ∪ V2, φ1 ∧ φ2) ≡ (∃V1, φ1) ∧ (∃V2, φ2). Cette adaptation de l’algorithme de QE à QF_LRIA permet d’aborder des systèmes typiques du domaine avionique, dans lesquels les booléens supportent la logique de contrôle, les entiers supportent l’implémentation de diverses primitives temporelles telles que les timers, les watchdogs, etc. et les réels supportent les flots de données. Ces systèmes s’expriment dans la théorie des octogones entiers et nous permettent d’éviter d’avoir à recourir à l’opérateur modulo lors de l’élimination de quantificateurs. En effet, QE(y, x = 7 ∗ y) où x et y sont des entiers devrait normalement renvoyer x%7 = 0 où % est l’opérateur "modulo". En nous limitant aux octogones, nous pouvons donc projeter les atomes entiers comme des atomes réels. Dans un contexte plus général le résultat de la projection pourrait être faux. Avec notre méthode, QE(x, {0 < x, x < 1}) où x est un entier 20Découverte d’Invariants 2.1 Élimination de Quantificateurs aurait pour résultat > ; cependant, l’algorithme de QE de Monniaux ne projetant que des atomes satisfiables modulo théorie, ce genre de cas ne peut donc pas se présenter au sein de la procédure. 2.1.2 Extrapolation : utilisation des cœurs insatisfiables Le but de l’extrapolation est de dériver une formule E à partir d’un modèle M |= φ qui soit plus générale que M , tout en impliquant φ. Si nous considérons tous les extrapolants pouvant être construits à partir des atomes de φ, un meilleur extrapolant pour un modèle M aurait un nombre minimal de littéraux. Un tel extrapolant peut être obtenu en prenant la conjonction du sous-ensemble de littéraux U ⊆ L impliqué dans tout cœur insatisfiable minimal de la formule ((V l∈L l) ∧ ¬φ), où L est l’ensemble défini dans l’équation (7.1). Calculer des extrapolants très généraux permet de limiter le nombre total d’itérations de la boucle principale de QE. Cependant, l’extraction de cœurs insatisfiables minimaux pour déterminer U se révèle trop coûteuse en pratique. Il est bénéfique pour la performance globale de la QE de se contenter d’approximer les meilleurs extrapolants. Le coût des quelques itérations supplémentaires de la boucle principale, du à la moindre qualité des extrapolants, est amorti par le gain sur l’extrapolation plus rapide. L’extrapolation SMT-test décrite en section 2.1 a de bonnes capacités de généralisation, mais reste coûteuse en raison des tests SMT utilisés pour décider, pour chaque littéral de la formule, de l’éliminer ou de le garder dans l’extrapolant. Le nombre de tests SMT peut être réduit en utilisant les informations découvertes par le solveur SMT sur les formules insatisfiables. Lorsqu’un littéral l 0 ∈ L tel que G ≡ ((V l∈L, l6=l 0 l) ∧ ¬φ) est insatisfiable est considéré, le solveur peut être interrogé pour savoir quels littéraux ont été utilisés dans le graphe du dernier conflit. Ces littéraux font partie d’un cœur unsat de la formule G, pas nécessairement minimal, et on peut éliminer de L tous les littéraux n’étant pas dans ce graphe. On élimine ainsi plus d’un littéral de l’extrapolant par itération. Cette idée est détaillée dans l’algorithme 2. 2.1.3 Extrapolation par analyse structurelle Limiter l’utilisation du solveur SMT dans l’extrapolation est un progrès, mais la supprimer totalement pourrait être encore mieux. Nous présentons ici une analyse structurelle permettant d’identifier rapidement un sous-ensemble de littéraux expliquant la satisfiabilité d’une formule par rapport à un modèle, et d’en générer un extrapolant. Cette méthode est inspirée de [11], où les modèles découverts par un model-checker pour Simulink sont simplifiés avant d’être présentés à l’utilisateur. Les portions du réseau à flots de données impliquées dans la falsification de l’objectif de preuve sont identifiées par des règles structurelles. De [11], nous retenons principalement les notions d’activité et de cause. L’idée de 212.1 Élimination de Quantificateurs Découverte d’Invariants Algorithm 2 SMT-test avec cœurs insatisfiables. Require: φ une formule QF_LRIA, M un modèle de φ. Ensure: Un extrapolant de M par rapport à φ sous la forme d’un ensemble de littéraux. function smtTestCores(φ, M ) toCheck ← L . Ensemble L de littéraux à tester (cf. Eq 7.1) toKeep ← ∅ while toCheck 6= ∅ do . ensemble des littéraux de l’extrapolant solver .assert(¬φ) literal ← toCheck.first . prendre le prochain littéral à tester toCheck ← (toCheck \ {literal}) . supprimer le littéral de l’ensemble for lit ∈ toKeep ∪ toCheck do solver .assert(lit) . supposer les littéraux à garder/tester end for if solver .checksat() = sat then toKeep ← (toKeep ∪ {literal}) . ajouter le littéral dans l’ensemble résultat else . supprimer les littéraux n’étant pas dans le cœur unsat toCheck ← solver .getUnsatCore() ∩ toCheck end if solver .restart() . réinitialiser le solveur pour la prochaine itération end while return toKeep . retourner l’ensemble de littéraux formant l’extrapolant end function base ici est de ne pas juste considérer l’ensemble des littéraux de la formule “à plat”, mais plutôt de garder une vision arborescente de la formule et de définir des règles permettant d’identifier les sous-arbres expliquant la valeur de la racine. Definition 2.1.3 (Activité d’une sous-formule) Soit f une formule et g une de ses sousformules directes. On dit que g est active par rapport à f dans M si et seulement si la valeur de g dans M est telle que la changer en préservant les valeurs des autres sous-formules directes de f change la valeur de f, ou bien si cette valeur permet de déterminer complètement la valeur de f dans M . L’activation d’une sous-formule peut être résumée à une condition logique sur les valeurs impliquées par un modèle pour la sous-formule et ses soeurs. Par exemple, si on considère que a ∧ b, une sous-formule de φ, est active, alors une des situations suivantes se produit : (a) si M (¬a) et M (b), la valeur de a dans M suffit à déterminer que a ∧ b est fausse dans M , mais pas la valeur de b. Donc a est active et b ne l’est pas ; (b) si M (a) et M (¬b), la valeur de b dans M suffit à déterminer que a ∧ b est fausse dans M , mais pas la valeur de a. Donc b est active et a ne l’est pas ; (c) si M (¬a) et M (¬b), alors la valeur de a ou celle de b dans M permet indépendamment de déterminer que a ∧ b est fausse dans M . Donc a et b sont 22Découverte d’Invariants 2.1 Élimination de Quantificateurs actives, c’est un cas combinaison de causes indépendantes ; (d) si M (a) et M (b), la connaissance des valeurs de a et b est nécessaire pour déterminer que a ∧ b est vraie dans M . Donc a et b sont actives, c’est un cas de combinaison de causes dépendantes. La condition d’activation de a peut être réduite à M (¬a ∨ b), et celle de b à M (¬b ∨ a). Definition 2.1.4 (Causes) Soient une formule φ et un de ses modèles M , une cause pour une sous-formule g active par rapport à φ est un cube k sur les variables libres de φ tel que M |= k et pour tout M 0 tel que M 0 |= k, M 0 (g) = M (g). Puisqu’il peut exister plusieurs causes pour g dans un même modèle, l’ensemble des causes de g est noté KM (g), ou bien K(g) quand M est évident d’après le contexte. L’ensemble des causes d’une formule peut être construit inductivement à partir des ensembles de causes de ses sous-formules. Pour l’opérateur unaire ¬a, les causes sont celles de a. Pour un opérateur binaire hopi ∈ (∧, ∨), KM (a hopi b) est égal à : • KM (a) si seulement a est active ; • KM (b) si seulement b est active ; • KM (a) ∪ KM (b) si a et b sont actives et leurs causes sont indépendantes ; • {Ca ∧ Cb | (Ca, Cb) ∈ KM (a) × KM (b)} si a et b sont actives et leurs causes sont dépendantes. Ces règles de construction et la définition d’une cause font que si a (resp. b) était active par rapport à a hopi b dans M , alors elle l’est toujours dans tout M 0 |= k où k ∈ KM (a hopi b). Donc, si M |= φ, tout k ∈ KM (φ) est en fait un extrapolant de M par rapport à φ, car M |= k et tout M 0 |= k est tel que M 0 (φ) = M (φ) = >, ce qui est équivalent à k =⇒ φ, on retrouve bien la définition 7.1.1 instanciée dans le cadre de la QE. Il est donc possible de calculer des extrapolants pour M par rapport à φ en calculant des causes pour φ dans M . Nous avons constaté expérimentalement que les combinaisons de causes indépendantes augmentent la taille des ensembles de causes (par union), menant indirectement à une explosion du nombre de causes lors du traitement des causes dépendantes (produit cartésien). Nous avons donc décidé de n’extraire qu’un seul extrapolant par modèle, en ne traitant que les combinaisons de causes dépendantes et en ne calculant que la cause de la sous-formule active la plus à gauche lors de combinaisons de causes indépendantes. L’algorithme 7 donne le parcours récursif de l’arbre de la formule et la combinaison des causes utilisés pour générer des extrapolants. Le Tableau 2.1 résume toutes les règles définissant les fonctions active et combine. La colonne Terme spécifie l’opérateur en question. La colonne Condition spécifie la condition logique à évaluer. La colonne Sous-formule active donne le comportement de la fonction 232.1 Élimination de Quantificateurs Découverte d’Invariants Algorithm 3 Extrapolation par méthode structurelle. Require: f une formule, M une fonction d’évaluation. Ensure: Si M |= f alors le résultat est un extrapolant de M par rapport à f. function struct(f, M) activeSubFormulas ← active(f, M) . sous-formules actives (cf. Tableau 2.1) subCauses ← activeSubFormulas map {x → struct(x, M)} . appel récursif return combine(f, subCauses, M) . combinaison des sous-causes (cf. Tableau 2.1) end function active, qui retourne la liste des sous-formules actives d’une formule. La colonne Causes générées/Combinaison donne le comportement de la fonction combine, qui retourne soit une cause fraîchement générée dans les cas d’arrêt de la récursion (quand active renvoie une liste vide), ou bien une cause obtenue par combinaison. Par exemple, la cinquième ligne du tableau se lit : si la formule courante est de la forme x = y, la récursion s’arrête et alors si M (x) est égal à M (y), la cause x = y est retournée, sinon si M (x) < M (y), alors la cause x < y est retournée, sinon si M (y) < M (x), la cause y < x est retournée. Terme Condition Sous-formules Causes générées/ actives Combinaison hidi booléen T [] hidi si M (hidi), ¬hidi sinon ¬a T [a] K(a) a ∧ b M (¬a) [a] K(a) M (a ∧ ¬b) [b] K(b) M (a ∧ b) [a, b] K(a) ∧ K(b) a ∨ b M (a) [a] K(a) M (¬a ∧ b) [b] K(b) M (¬a ∧ ¬b) [a, b] K(a) ∧ K(b) x = y M (x = y) [] (x = y) M (x < y) [] (x < y) M (y < x) [] (y < x) x < y M (x < y) [] (x < y) M (¬(x < y)) [] ¬(x < y) Figure 2.1: Règles de calcul de l’analyse structurelle. 2.1.4 Combinaison de techniques d’extrapolation L’analyse structurelle peut être intégrée dans l’algorithme 2, en remplaçant simplement la première ligne toCheck ← L par toCheck ← struct(φ, M) où struct est la fonction de 24Découverte d’Invariants 2.1 Élimination de Quantificateurs Algorithm 4 hybrid(φ, M ) . Extrapolation hybride. Require: φ une formule, M un modèle de φ. Ensure: Un extrapolant de M par rapport à φ, sous la forme d’un ensemble de littéraux. toCheck ← struct(φ, M ) . ensemble de littéraux par analyse structurelle (cf. Alg. 7) toKeep ← ∅ solver .assert(¬φ) . insérer ¬φ au niveau 0 solver .push(1) . à niveau 1 (littéraux à garder) while toCheck 6= ∅ do literal ← toCheck.first . prendre un littéral dans l’ensemble toCheck toCheck ← (toCheck \ {literal}) . le supprimer de l’ensemble solver .push(1) . à niveau 2 (littéral à tester) for lit ∈ toCheck do solver .assert(lit) . insérer le littéral à tester à niveau 2 end for if solver .checksat() = sat then toKeep ← (toKeep ∪ {literal}) solver .pop(1) solver .assert(literal) . insérer le littéral à garder à niveau 1 else . éliminer les littéraux hors du cœur insatisfiable solver .pop(1) toCheck ← (solver .getUnsatCore() ∩ toCheck) end if end while return toKeep l’algorithme 7. Pour encore améliorer la performance, on peut utiliser la pile d’assertions du solveur SMT sous-jacent. L’algorithme 8 illustre cette combinaison. La formule ¬φ est insérée au bas de la pile d’assertions, les littéraux à garder pour former l’extrapolant sont placés au niveau 1 de la pile, le littéral à tester est inséré en haut de la pile. Un simple pop nous ramène au niveau 1, où l’on peut insérer le littéral à garder et passer au prochain littéral à tester après un push, préservant ainsi au sein du solveur la majorité du contexte de l’algorithme. 2.1.5 Évaluation de l’Approche Nous avons implémenté chacune des techniques d’extrapolation discutées ci-dessus ainsi qu’un algorithme de QE générique paramétré par la fonction d’extrapolation. Le solveur SMT Microsoft Z3 [29] est utilisé pour couvrir les besoins SMT. Pour la projection sur contraintes arithmétiques, décrite en section 2.1.1, nous avons utilisé la Parma Polyhedra Li- 252.1 Élimination de Quantificateurs Découverte d’Invariants brary [2] 1 , la projection de Booléens étant réalisée par nos soins. Dans le tableau 7.4, nous présentons les résultats obtenus avec les techniques d’extrapolation suivantes : • SMT-test la technique de [56], fournie comme référence ; • struct la technique purement structurelle de l’algorithme 7 ; • hybrid la technique mêlant analyse structurelle, SMT-test et cœurs insatisfiables de l’algorithme 8. Les formules de test sont des problèmes de vérification générés par notre outil Stuff [16], et correspondent à des itérations de calcul de préimage symbolique à partir de la négation d’un objectif de preuve sur un système de transition. Plus précisément, si T(s, s0 ) est la relation de transition du système, appliquée à l’état courant s et à un successeur s 0 , le calcul de préimage itéré est défini ainsi : G1(s) ≡ QE(s 0 , P O(s) ∧ T(s, s0 ) ∧ ¬PO(s 0 )) Gi+1(s) ≡ QE(s 0 ,PO(s) ∧ T(s, s0 ) ∧ Gi(s 0 )) La formule de chaque nouvelle itération contient donc le résultat de l’itération précédente et grossit rapidement. Comparaison de performances expérimentales. Reconf Triplex 1 2 3 4 5 1 2 3 Durée totale ms SMT-test 53 172 114 371 99 953 131 855 318 257 13 855 30 163 119 771 struct 800 883 2 063 5 587 10 078 1 627 4 785 23 413 hybrid 25 078 27 837 31 024 50 160 51 913 7 005 16 978 42 063 Nb. cubes dans O SMT-test 55 106 125 119 264 33 38 84 struct 37 38 84 153 243 26 31 51 hybrid 37 39 45 70 74 23 28 48 Durée ms / itération SMT-test 966 1 078 799 1 108 1 205 419 793 1 425 struct 21 23 24 36 41 62 154 459 hybrid 677 713 689 716 701 304 606 876 Extrapol. ms / itération SMT-test 938 1 049 768 1 075 1 163 369 618 919 struct 1.810 0.684 0.595 0.483 0.427 0.115 0.290 0.117 hybrid 652 687 661 686 667 261 361 392 Projection ms / itération SMT-test 11 9 6 8 9 8 11 14 struct 5 6 5 5 5 19 30 42 hybrid 10 10 9 9 8 8 11 14 Check-sat ms / itération SMT-test 16 19 24 23 32 42 163 491 struct 14 16 18 31 35 43 123 416 hybrid 14 16 17 21 25 34 234 469 Nous donnons ici les résultats sur deux systèmes2 : le premier est une logique triplex fournie par Rockwell-Collins, qui mêle Booléens et réels, pour laquelle nous calculons les 1Outil disponible à https://cavale.enseeiht.fr/redmine/projects/smt-qe/files 2Disponibles à https://cavale.enseeiht.fr/redmine/projects/smt-qe/files 26Découverte d’Invariants 2.2 Une Architecture Collaborative trois premières préimages ; le second est une logique de reconfiguration distribuée mêlant Booléens et entiers, pour laquelle nous calculons les cinq premières préimages. Nous ne les détaillons pas plus ici et dirigeons le lecteur intéressé vers [16]. Le tableau 7.4 montre la performance des techniques d’extrapolation au travers de différentes métriques. D’abord, la durée totale d’exécution en millisecondes. Ensuite, le nombre d’itérations de la boucle principale de QE, qui correspond aussi au nombre de cubes dans la formule DNF résultat. Nous donnons ensuite la durée moyenne d’une itération de la boucle principale de QE, en détaillant les contributions de : (i) l’extrapolation, (ii) la projection, (iii) l’obtention du modèle. Les tests nous ont permis de remarquer que la durée d’exécution et le nombre total d’itérations de la QE avec SMT-test pouvait varier grandement, jusqu’à ±50% d’une exé- cution à l’autre, sur une même formule. Ceci est dû à la sensibilité à l’ordre dans lequel SMT-test considère chaque littéral et – comme pour les méthodes struct et hybrid, à l’ordre dans lequel les modèles sont découverts. La méthode struct est la plus stable de toutes avec des variations de durée d’exécution de seulement ±5%. Les bénéfices de l’analyse structurelle sans tests SMT sont clairement mis en avant : la méthode de QE avec extrapolation struct est de loin la plus rapide de toutes les techniques, parfois de plusieurs ordres de grandeur (cf. Reconf 5, struct termine en 10 secondes contre 300 secondes pour SMT-test, en produisant un nombre de cubes comparable). La contrepartie est aussi apparente : en ne considérant pas finement la sémantique des littéraux manipulés, mais seulement leur rôle structurel dans la formule, des littéraux inutiles peuvent s’accumuler dans l’extrapolant et le rendre moins général. Mais, dans les rares cas où les DNF produites contiennent plus de cubes (cf. Reconf 4), elles sont malgré tout produites beaucoup plus rapidement qu’avec les autres techniques. Si la taille de la formule produite est importante pour l’application en question, le meilleur compromis entre rapidité d’exécution et pouvoir de généralisation semble être atteint avec la méthode d’extrapolation hybrid : elle produit des formules DNF jusqu’à trois fois plus petites en nombre de cubes que struct ou SMT-test (cf. Reconf 5, 74 cubes en 50 secondes contre 243 cubes en 10 secondes avec struct, et 264 cubes en 300 secondes pour SMT-test), montrant donc une capacité de généralisation supérieure. En outre, hybrid s’est avérée beaucoup plus rapide que la technique SMT-test de référence dans tous les tests conduits, et la variance des temps d’exécution est aussi beaucoup plus faible qu’avec SMT-test, de l’ordre de ±10%. 2.2 Une Architecture Collaborative Notre architecture est paramétrée par un entier n indiquant la profondeur maximale à laquelle le moteur de k-induction est autorisé à dérouler la formule de transition. La Figure 2.2 illustre le fonctionnement de l’architecture à haut niveau. Des méthodes générent 272.2 Une Architecture Collaborative Découverte d’Invariants Potential Invariant Generator Potential Invariant Generator Potential Invariant Generator k-induction if contains PO Done if contains PO Minimization potential invariants Un (contains PO) Fn Vn counter example V proof found new invariants Vmin Figure 2.2: Une architecture collaborative basée sur la k-induction. des invariants potentiels et les envoient au moteur de k-induction en charge d’identifier ceux étant effectivement des invariants. Pour ce faire la k-induction construit de manière incrémentale trois ensembles Fn, Un et Vn à partir d’un ensemble d’invariants potentiels s contenant l’objectif de preuve comme suit. L’ensemble Fn contient les invariants potentiels falsifiables par n-induction, i.e. ceux pour lesquels l’instance de base est satisfiable. L’ensemble Un contient ceux pour lesquels l’instance de base est insatisfiable mais l’instance de step est satisfiable : leur statut est non-défini (Undefined). Enfin, l’ensemble Vn contient les invariants potentiels prouvables par n-induction. Si l’objectif de preuve PO est dans l’ensemble Vn, alors l’analyse est terminée, PO a été renforcé et est prouvable par n-induction. Si PO est dans l’ensemble Fn, alors un contreexemple existe et PO n’est pas un invariant. Si PO est dans Un alors la k-induction recommence l’analyse décrite ci-dessus avec les nouveaux invariants potentiels générés par les autres méthodes de l’architecture. Les invariants découverts durant une analyse –les élé- ments de Vn– sont quant à eux communiqués aux méthodes de génération d’invariants potentiels dans le but de raffiner les analyses qu’elles effectuent. Nous illustrons à présent la découverte d’invariants par instanciation de templates via élimination de quantificateurs bénéficiant des améliorations apportées à l’algorithme de Monniaux présentées en Section 2.1. Cette méthode, appelée BrutalIQe, est fortement inspirée des travaux de Kapur [49, 50]. Nous supposons l’existence d’une base de données de fonctions de la forme template(vars)(params) retournant une formule, comme par exemple template(var1, var2)(min, max ) ∆= (min ≤ var1 + var2) ∧ (var1 + var2 ≤ max ). L’argument vars de la fonction représente des variables d’état du système et params les paramètres de la template. L’idée est de trouver des valeurs p pour ces paramètres. Notons tout d’abord que le fait que la formule produite est (1-)inductive est équivalent à l’insatisfiabilité de la formule instance de base z }| { (I(s) ∧ ¬template(sv)(p)) ∨ instance de step z }| { (template(sv)(p) ∧ T(s, s0 ) ∧ ¬template(sv0 )(p)). 28Découverte d’Invariants 2.3 Découverte d’Invariants Potentiels par QE Nous construisons ensuite la formule suivante, dont les modèles sont exactement les valeurs des paramètres pour lesquelles la template est inductive : ∀s, s0 , ¬  (I(s) ∧ ¬template(sv)(fresh)) ∨ (template(sv)(fresh) ∧ T(s, s0 ) ∧ ¬template(sv0 )(fresh)) où fresh est un vecteur de nouvelles variables. Cette formule peut être réécrite en ¬  ∃s, s0 , (I(s) ∧ ¬template(sv)(fresh)) ∨ (template(sv)(fresh) ∧ T(s, s0 ) ∧ ¬template(sv)(fresh)) . Il est à présent possible d’utiliser l’élimination de quantificateurs pour éliminer les variables d’état du système pour obtenir un caractérisation sans quantificateurs des paramètres : C ∆= ¬QE s ∪ s 0 , (I(s) ∧ ¬template(sv)(fresh)) ∨ (template(sv)(fresh) ∧ T(s, s0 ) ∧ ¬template(sv0 )(fresh)) . C ne porte que sur les variables fresh ; si elle est insatisfiable, alors aucune valeur de fresh ne peut rendre la template inductive sans davantage de renforcement. Si au contraire C est satisfiable, un modèle fournit des valeurs pour les paramètres de la template permettant d’obtenir des invariants inductifs par construction. La formule obtenue est alors envoyée au moteur de k-induction dans l’espoir de renforcer l’objectif de preuve mais également afin de communiquer l’invariant découvert aux autres méthodes du framework. En pratique, nous utilisons BrutalIQe pour découvrir des bornes sur les variables détat du système. Cela permet de réduire fortement l’espace d’états considéré par la k-induction et les autres méthodes, leur permettant de raffiner leurs analyses. 2.3 Découverte d’Invariants Potentiels par QE Nous abordons à présent la contribution principale de ce mémoire, une heuristique de génération d’invariants potentiels combinant le calcul de préimages par élimination de quantificateurs avec le calcul d’enveloppes convexes. L’approche, nommée HullQe, bénéfi- cie grandement des améliorations apportées à l’algorithme de QE de Monniaux présentées dans la Section 2.1 et se décompose en deux parties. Premièrement, un calcul de pré-images de la négation de l’objectif de preuve PO construit itérativement une caractérisation des états gris. Les états gris sont des états vérifiant l’objectif de preuve desquels une falsification 292.3 Découverte d’Invariants Potentiels par QE Découverte d’Invariants de PO peut être atteinte en un certain nombre de transitions. Dans un second temps, une analyse des partitionnements de la représentation partielle des états gris essaie d’infèrer des relations entre les variables envoyées au moteur de k-induction en tant qu’invariants potentiels. 2.3.1 Calcul de Pré-images Cette première étape de notre heuristique de génération d’invariants potentiels consiste à calculer une caractérisation de tous les états gris pouvant atteindre une falsification de l’objectif de preuve PO en une transition. Ce calcul est itéré afin d’identifier des états gris de plus en plus éloignés des états falsifiant PO. En pratique, nous nous intéressons à la suite de formules suivante : G1(s) ∆= QE(s 0 , PO(s) ∧ T(s, s0 ) ∧ ¬PO(s 0 )) Gi(s) ∆= QE(s 0 , PO(s) ∧ T(s, s0 ) ∧ Gi−1(s 0 )) (for i > 1). Ainsi, Gi(s) caractérise tous les états pouvant atteindre une falsification de l’objectif de preuve en i transitions ou moins. Si pour un certain i, Gi+1(s) ne caractérise pas davantage d’états que Gi(s), un point fixe est atteint et tous les états gris ont été découverts. Si aucun d’eux n’intersecte les états initiaux, i.e. ( V 0≤j≤i Gj (s))∧I(s) n’est pas satisfiable, alors PO est un invariant du système. Malheureusement, il n’est pas réaliste de s’attendre à atteindre un point fixe sur des système complexe tels que ceux qui nous intéressent. Les caractérisations partielles des états gris sont donc envoyées au fur et à mesure au second composant de notre heuristique en charge de faire apparaitre des relations entre les variables par calcul d’enveloppes convexes. 2.3.2 Extraction d’Invariants Potentiels par Calcul d’Enveloppes Convexes Notons tout d’abord que l’algorithme que nous utilisons pour le calcul de pré-images a la propriété de produire des formules en forme normale disjonctive ou DNF, i.e. des disjonctions de conjonctions de littéraux. Dans cette section nous utiliserons couramment le terme polyhèdre pour nous référer à une conjonction de littéraux. D’un point de vue géometrique, une formule en DNF correspond à une union de polyhèdres tels que ceux représenté sur la Figure 2.3a et la Figure 2.3b. En raison du grand nombre de polyhèdres apparaissant dans les pré-images calculées sur nos systèmes, il n’est pas réaliste de calculer toutes les enveloppes convexes possible. De plus, il est important de préserver la localité des polyhèdres. Il est donc nécessaire d’établir des critères conditionnant le calcul des enveloppes covexes dans le but d’identifier les groupes de polyhèdres proches les uns des autres. 30Découverte d’Invariants 2.3 Découverte d’Invariants Potentiels par QE x ≥ y x y (a) x ≥ y x ≥ y x ≥ 3 y ≤ 8 x y (b) x ≥ y ∧ x ≥ 3 ∧ y ≥ 8 Figure 2.3: Polyhedra examples. Enveloppes Convexes Exactes Le premier critère que nous proposons consiste à ne valider l’enveloppe convexe h de deux polyhèdres p1 et p2 que si celle-ci est exacte ; c’est à dire si elle décrit exactement les mêmes points que l’union des deux polyhèdres dont elle est issue. Plus précisemment, cela signifie que h a exactement les mèmes modèles que p1 ∨ p2. Ce critère est particulièrement intéressant pour des polyhèdres dont les littéraux sont dans l’arithmétique entière linéaire. La Figure 2.4 illustre les nouvelles relations pouvant apparaître lors du calcul d’ECH sur des polyhèdres entiers. Dans le cas réel, aucune de ces enveloppes convexes ne serait exacte, et de façon plus générale il n’est pas possible de faire apparaître de nouvelles relations entre des variables réelles au moyen d’ECH. Nous verrons que nous utilisons un critère différent pour les traiter. x y 0 1 2 3 4 0 1 2 3 s1 s2 s3 s4 s5 Figure 2.4: ECH de polyhèdres entiers. Nous proposons un algorithme hautement optimisé décrit dans la Section 9.2.1 permettant de calculer efficacement toutes les ECHs calculables à partir d’un ensemble non redondant de polyhèdres. Cela nous permet de faire apparaître de nouvelles relations entre les variables d’états dirigées par le calcul de pré-images présenté dans la section précédente. Cependant, les enveloppes convexes ainsi générées caractérisent des états gris, c’est à dire des états que nous souhaitons bloquer lors d’une tentative de preuve par k-induction. 312.3 Découverte d’Invariants Potentiels par QE Découverte d’Invariants tobs ti 0 boundobs boundi tobs − ti < (max obs − max i − 1) 0 ≤ tobs ≤ max obs ∧ 0 ≤ ti ≤ max i First pre-image Second pre-image Figure 2.5: Découverte d’invariant relationnels sur le système de reconfiguration. C’est pourquoi l’extraction d’invariants potentiels considère l’ensemble des littéraux découverts indépendamment de l’enveloppe convexe à laquelle ils appartiennent. Les invariants potentiels envoyés à la k-induction sont finalement l’ensemble des négations de chacun de ces littéraux. Les éléments de cet ensemble confirmés comme étant des invariants par le moteur de k-induction sont garantis de bloquer au moins une partie des contre-exemples de step fallacieux apparaissant dans un tentative de preuve par k-induction. Nous illustrons à présent l’intérêt de cette approche sur notre système de reconfiguration. L’objectif de preuve PO de ce système est que “aucune chaîne n’est en contrôle de l’actuateur” ne peut pas être vrai pendant plus de n cycles. Pour détecter une falsification de PO un observateur du système utilise un compteur s’incrémentant tant qu’aucune chaîne de calcul n’est en contrôle, et est remis à zéro sinon. Aucun outil de vérification formelle n’est capable, à notre connaissance, de conclure sur ce système. La difficulté de l’analyse réside dans le besoin d’identifier des relations entre les compteurs du système pour la confirmation des défaillances, ainsi que le transfert de contrôle d’une chaîne à une autre. Grâce au calcul exhaustif d’enveloppes convexes exactes, notre outil est capable de renforcer l’objectif de preuve en quelques secondes. Après le calcul de la deuxième pré-image, 150 invariants potentiels sont envoyés à la k-induction. 70 sont prouvés et renforcent PO. Il s’avère que seulement trois sont nécessaire au renforcement de l’objectif de preuve, exprimant des relations entre le compteur de l’observateur et ceux apparaissant dans le système de reconfiguration. La Figure 2.5 illustre le processus de découverte de ces relations. Il est à noter que les résultats obtenus ne dépendent pas de la valeur des bornes des compteurs, auxquelles sont sensibles la plupart des autres techniques formelles. Ces compteurs peuvent être amenés à compter des centaines, voire des milliers de cycles suivant la spécification du système. La k-induction, IMC, ainsi que PDR doivent dérouler la relation de transition un nombre de fois proportionnel ce qui provoque la divergence de l’analyse. 32Découverte d’Invariants 2.3 Découverte d’Invariants Potentiels par QE Enveloppes Convexes Modulo Intersection Le second critère que nous proposons consiste à n’accepter l’enveloppe convexe h de deux polyhèdres p1 et p2 que si p1 et p2 ont au moins un point en commun, c’est à dire si p1 ∧ p2 est exacte. Si h est légale par ce critère, nous dirons que h est l’ICH de p1 et p2. Ce critère n’est pas plus permissif que ECH. En effet, les ECH présentées ci-dessus dans le cadre de la vérification du système de reconfiguration ne sont pas légales par rapport à ce second critère. Les ICHs diffèrent également des ECH de par le fait qu’elle font apparaître de nouveaux points dans les enveloppes convexes qu’elles calculent. Leur but est de surapproximer des régions de l’espace d’états gris tout en évitant de fusionner des polyhèdres distants. Sur nos systèmes, le nombre d’ICH calculable est en général beaucoup trop grand pour adopter une approche exhaustive. C’est pourquoi nous proposons, dans la Section 9.2.4, un algorithme consistant à éliminer les polyhèdres fusionnables et à les remplacer par leur ICH avant de rechercher d’autres combinaisons de polyhèdre légales. Ce faisant, une abstraction des zones disjointes de l’espace d’états gris est calculée. Nous appliquons ensuite la même stratégie d’extraction d’invariants potentiels que pour les ECHs : L’ensemble des négations de chaque littéral apparaissant dans le résultat de l’algorithme est envoyé à la k-induction. Nous illustrons l’intérêt de cette approche sur le système de logique de vote fournit par Rockwell Collins. L’objectif de preuve que nous considérons est que si les entrées du système sont bornées, alors c’est également le cas de sa sortie. Des invariants relationels renforçant la propriété ont été trouvés à la main [32] au prix de longues simulations, une approche inadaptée à la vérification de systèmes critiques dans le cadre d’un processus de développement. À notre connaissance, aucun outil de vérification formelle n’est capable de vérifier ce système. La difficulté de l’analyse réside dans la nécessité de trouver des invariants reliant les trois variables d’égalisation du système desquelles dépend directement la valeur du signal de sortie. Grâce au calcul d’ICHs, notre outil est capable de vérifier ce système industriel en quelques secondes. Environ 60 invariants potentiels sont générés, dont 30 sont prouvés par k-induction et renforcent l’objectif de preuve. Il s’avère que seulement deux sont nécessaires. La Figure 2.6 illustre le processus de découverte de ces invariants, les invariants trouvés par simulation sont représentés en gris clair. La Figure 2.6a montre la première préimage de la négation de l’objectif de preuve en noir, alors que la Figure 2.6b montre le résultat du calcul d’ICH. Comme c’est le cas pour le calcul d’ECHs sur le système de reconfiguration présenté dans la section précédente, l’analyse menée ici n’est pas sensible à la taille des intervalles de validité supposés sur les entrées du système de vote ni de celui à prouver sur sa sortie. Ce n’est pas le cas de la k-induction, ni d’IMC ou de PDR qui doivent dérouler la relation de 332.4 Le Framework Formel Stuff Découverte d’Invariants (a) Logique de vote, première pré-image (en noir). (b) Résultat du calcul d’ICHs (en noir). Figure 2.6: Logique de vote en dimension deux. transition un nombre de fois proportionnel à la taille de ces intervalles, et donc ne parviennent pas à conclure. 2.4 Le Framework Formel Stuff Nous avons implémenté l’architecture collaborative parallèle décrite dans la Section 2.2 dans notre framework formel Stuff (Stuff’s The Ultimate Framework). Ce dernier est écrit en Scala et utilise le framework Akka qui propose une API, basée sur le formalisme des acteurs [39], pour le développement de logiciels parallèles. Nous détaillons notre utilisation des acteurs dans la Section 10.1 du mémoire. Le framework Akka confère à Stuff la possibilité de spécifier, après compilation, comment déployer ses composants sur plusieurs coeurs, voire même sur plusieurs machines au travers d’un réseau. De plus, Stuff est également extensible dans l’implémentation de nouvelles techniques qui se fait sans impact sur le code existant. Comme décrit dans la Section 10.2, les techniques sont gérées à l’exécution au moyen du patron de conception des chaînes de responsabilité, permettant au framework de gérer des techniques avec un minimum de connaissance sur la façon dont elles fonctionnent. Enfin, les solveurs SMT utilisés par Stuff peuvent être spécifiés après compilation, grâce à une librairie générique implémentée par nos soins. Cette librairie, appelée Assumptio, est détaillée dans le Chapitre 11. Assumptio est compatible avec les principaux solveurs SMT respectant le standard SMT-LIB 2 : Z3, CVC4 et MathSat 5. Stuff s’est montré très utile dans nos récents travaux visant à la vérification d’une chaîne fonctionnelle complète. En le combinant avec un interprétateur abstrait [65] développé à l’Onera, nous avons pu vérifier la stabilité en boucle ouverte de la chaîne représentée en Fig- 34Découverte d’Invariants 2.4 Le Framework Formel Stuff ure 2.7. Bien que considérablement plus simple que les chaînes fonctionnelles industrielles, la vérification de cet exemple exécutable est un premier pas vers l’analyse de systèmes plus complexe. Les moniteurs de capteurs (Sat) sont vérifiés par interprétation abstraite en utilisant des intervalles en tant que domaines abstraits. Stuff se charge de vérifier la correction des systèmes de vote au moyen de l’analyse basée sur les enveloppes convexes modulo intersection présentée en Section 2.3.2. Enfin, l’interpréteur abstrait conduit une analyse utilisant des ellipsoides permettant de prouver la stabilité de la loi de commande. La stabilité de la chaîne est ainsi vérifiée de bout en bout. u Controller in0_d in1_d Triplex in0 Triplex in1 System in0_v in1_v in0a Sat in0b Sat in0c Sat in1a Sat in1b Sat in1c Sat Figure 2.7: Une chaîne fonctionnelle simplifiée. 35CHAPTER 3 Conclusion 3.1 Conclusion La vérification de logiciels est un domaine de recherche très actif, mais malgré les impressionnantes avancées de ces dernières décennies certains systèmes restent hors de portée des techniques actuelles. Le but de cette étude était d’améliorer l’état de l’art sur le problème de la vérification automatique des composants logiciels issus de systèmes critiques embarqués avioniques, présentés dans le Chapitre 1. Nous nous sommes en particulier concentrés sur la découverte d’invariants relationels dans le cadre d’un framework collaboratif centré autour d’un moteur de k-induction. Nous espérons que nos travaux aideront à la diffusion de la vérification formelle dans la communauté industrielle. Tout d’abord, nous avons formalisé la notion de systèmes de transition en termes de prédicats dans MSFOL (logique du premier ordre multi-sortée) en Section 1.2.1 et Section 1.2.2. La formalisation complète est donnée en Chapitre 5 et Chapitre 6. Nous avons défini une catégorie de signatures MSFOL dans laquelle les notions de trace, d’objectif de preuve, de validité, etc. sont précisemment formalisés. Ce type de représentation est très répandu dans la littérature, mais les détails mathématiques et en particulier la sémantique précise du déroulement de la relation de transition sont souvent omis. Nous avons présenté notre contribution principale dans le Chapitre 2, exposée en détail dans la Partie II. Nous avons commencé par améliorer l’algorithme d’élimination de quantificateurs (QE) de Monniaux sur l’arithmetique réelle linéaire en Section 2.1 (correspondant au Chapitre 7). Cela nous a permis de gagner plusieurs ordres de grandeur dans le calcul de pré-images sur des systèmes de transition, gain mis en évidence par nos expérimentations sur un grand nombre de benchmarks. Nous avons également adapté l’algorithme aux formules mélangeant arithmétique réelle, octogones entiers et booléens. Nous avons ensuite proposé des méthodes de découverte d’invariants profitant des améliorations apportées à l’algorithme de QE. Premièrement, une méthode basée sur des templates, appelée BrutalIQe, s’inspirant des travaux de Kapur [49] en Section 2.2 (cf. Section 8.2). En pratique cette technique est utilisée pour decouvrir des invariants sous forme d’intervalles en-3.2 Perspectives Conclusion cadrant les variables d’état du système. Dans un deuxième temps, nous avons proposé, HullQe, une nouvelle heuristique de découverte d’invariants en Section 2.3 –correspondant au Chapitre 9. HullQe calcule des pré-images d’états dangereux et étudie leurs partitionnements pour en extraire des invariants potentiels relationels. Enfin, nous avons proposé une architecture de moteur de preuve parallèle collaboratif centré autour de la k-induction en Section 2.2 (voir Section 8.1). Cette architecture permet aux techniques de découverte d’invariants de coopérer grâce à l’intégration continue des invariants découverts. Stuff est l’implémentation de cette architecture, présentée en Section 2.4 –et détaillée dans la Partie III. Nous avons présenté le formalisme des acteurs sur lequel Stuff est bâti, ainsi que son caractère extensible, notamment par rapport à l’ajout de technique sans impact sur les techniques déjà implémentées, et par rapport aux solveurs SMT utilisés pouvant être spécifiés après compilation. Nous avons évalué l’intêret de notre approche collaborative proposée dans ce mémoire sur un système de reconfiguration et un système de vote fourni par Rockwell Collins. Stuff conclut en quelques secondes grâce à la collaboration entre les différentes méthodes du framework. Enfin, nous avons étudié la combinaison de notre outil avec un interpréteur abstrait [65] dans l’optique de la vérification d’une chaîne fonctionnelle complète. Grâce à cette combinaison nous avons pu vérifier automatiquement une partie d’une chaîne fonctionnelle comportant des entrées correspondant à des capteurs tripliqués, des moniteurs de capteurs, des systèmes de vote et une loi de commande contrôllant un actuateur. Les résultats obtenus sur un système exécutable représentatif sont une avancée vers la vérification de chaînes fonctionnelles industrielles. 3.2 Perspectives 3.2.1 Élimination de Quantificateurs L’élimination de quantificateurs (QE) est une brique de base utilisée par toutes les techniques de découverte d’invariants présentées dans ce mémoire. Une direction naturelle de recherche est donc d’étendre notre technique de QE à des fragments plus généraux, tels que l’arithmétique entière linéaire et l’arithmétique réelle non-linéaire. De telles extensions impacteraient l’ensemble du framework et permettraient d’évaluer la pertinence de notre approche sur des systèmes s’exprimant dans des fragments plus complexes. De ce point de vue, les limitations se situent au niveau de la phase de projection. En effet, les solveurs SMT actuels sont déjà capables de traiter ces fragments, et notre analyse structurelle est tout à fait compatible avec eux. 38Conclusion 3.2 Perspectives Pour ce qui est de la projection de (conjonction de) littéraux, les techniques Cylindrical Algebraic Decomposition (CAD [21]) et Virtual Substitution (VS [79, 80]) sont capables de manipuler l’arithmétique entière non-linéaire. Malheureusement, elles sont loin de passer à l’échelle sur des problèmes d’élimination de quantificateurs extraits de la vérification de systèmes industriels tels que les notres. Augmenter le pouvoir d’expression des formules d’entrée de la procédure de QE ne doit pas se faire au détriment de ses performances : toutes nos techniques, excepté la k-induction, s’appuient fortement sur la rapidité de la procédure de QE. Changer la phase de projection pour CAD ou VS causerait une baisse en performance conséquente, et pourrait rendre le framework dans son ensemble inutilisable. Nous pensons que davantage de recherche sur ce sujet est nécessaire, par exemple en identifiant des sous-fragments de l’arithmétique non-linéaire pour lesquels des algorithmes de QE efficaces existent. Une autre direction d’intêret est la combinaison des approches susnommées [72]. 3.2.2 HullQe La méthode HullQe est composée de deux parties : un calcul incrémental de pré-image et les heuristiques étudiant celles-ci afin d’en extraire des invariants potentiels. Des invariants relationel pertinents sont découverts en fusionnant les différents polyhèdres apparaissant dans les pré-images. L’explosion du nombre d’invariants potentiels générés est limitée par des critères conditionnant la fusion de deux polyhèdres. Une première heuristique n’autorise une fusion que si celle-ci est exacte, la deuxième impose que les deux polyhè- dres aient au moins un point en commun. Il serait intéressant d’évaluer des critères plus permissifs sur des systèmes réalistes. De plus, introduire un mécanisme d’abstraction dans le calcul de pré-image pourrait accélérer le calcul des états gris et permettre de découvrir de nouveaux invariants. Des travaux récents [22] introduise une technique d’abstraction adaptable a priori dans le calcul de pré-images : si une trace contre-exemple partant des états initiaux est découverte, un algorithme détermine quelles approximations la rendent possible –dans le cas où cette trace ne constitue pas un vrai contre-exemple– et les annule. 3.2.3 Property-Directed Reachability PDR est une technique très prometteuse, conçue à l’origine pour des systèmes purement propositionnels. Généraliser cette approche au cas SMT n’est pas simple : les auteurs de [19] proposent une adaptation de PDR à l’analyse de programmes sous la forme de Control Flow Graphs (CFG) contenant de l’arithmétique. Ils proposent une version “ramifiée” de PDR qui réduit l’explosion combinatoire de l’espace de recherche en bloquant des cubes pour des branches abstraites du propramme au lieu d’essayer de les bloquer pour le système entier. Il serait très intéressant d’adapter cette approche à l’analyse de programmes Lustre. 393.2 Perspectives Conclusion 3.2.4 Stuff Les travaux présentés dans ce mémoire omettent le cas où l’objectif de preuve n’est pas un invariant du système considéré. Il est alors important de produire un ou plusieurs contreexemple(s) de manière efficace, ce qui peut s’avérer problématique pour des systèmes réalistes. PDR prend en compte les états initiaux tout au long de l’analyse, et effectue une exploration en arrière des antécédents de la négation de l’objectif de preuve. Cette stratégie rend PDR capable de trouver des contre-exemples bien plus rapidement que le BMC et la plupart des autres méthodes formelles, a fortiori dans sa version ramifiée. La recherche de contre-exemples est d’un grand intêret pour les industriels de notre domaine et dans le cadre de la coûteuse phase de détection et correction de bugs. Malheureusement les traces contre-exemple produites par les méthodes formelles sont généralement constituées d’états concrets trouvés par des solveurs SMT. Il est donc souvent difficile pour les dévelopeurs d’identifier l’origine du bug dans le modèle, en particulier pour des traces de centaines ou de milliers d’états. PDR diffère de la plupart des autres méthodes et produit, non pas une unique trace, mais une classe de contre-exemples sous la forme d’une séquence de cubes. Il serait intéressant d’évaluer l’intêret de ces contre-exemples abstraits pour les concepteurs de systèmes critiques lors de la phase de correction de bugs dans un contexte industriel. Enfin, nous projetons de continuer nos travaux visant à la vérification de chaînes fonctionnelles complètes grâce à la combinaison de notre framework et de l’interpréteur abstrait introduit dans [65]. Nous insistons sur le besoin de cas d’étude, idéalement industriels. Nous avons étudié avec succès une famille importante de propriété en boucle ouverte, mais davantage de recherche est nécessaire pour étendre et améliorer ces résultats. En particulier pour automatiser la décision de la méthode à employer pour analyser chaque sous-système. Il est également primordial d’assurer le passage à l’échelle de l’approche aux système réels, pouvant utiliser plus de dix fois plus de variables d’état. 40PART I Introduction Critical systems are systems the failure of which has catastrophic consequences such as human casualties, economic loss, etc. They are typically encountered in fields such as aerospace, avionics, automotive, rail transport, nuclear plants, medical equipment, hardware design. . . There is thus a strong interest in (i) establishing precise specifications of those systems, and (ii) making sure that the final product is correct with respect to the specifications. The work presented in this thesis focuses on the latter in the context of software components of avionics critical embedded systems. Until recently, the industry in our domain is mostly relying on a process-based quality assurance approach. The introduction of the DO-178C avionics norm and of its formal methods supplement DO-333 published by RTCA1 shows a will to consolidate this process-based approach with a product-based quality assurance one. Process-based quality assurance consists in a thorough inspection of the process leading to the creation of the product. If the process is deemed trustworthy, then so is the resulting product. For avionics hardware parts for example the design and production of components are closely monitored at the process level. They are then tested against their specification by sampling the global production rather than testing all of them. Product-based quality assurance on the other hand aims at verifying, in a sound way, that the final product itself meets its specification. This especially applies to software, for which there exists methods amenable to automation to prove mathematically that the software itself respects its specification. These methods, established by the research community in computer science, are called formal methods. The interest of the approach is strengthened by the fact that software is made of zeros and ones which can be easily duplicated without any margin of error, which is not the case of hardware. Avionics critical embedded systems are traditionally developed in a high-level language (model level) different from the final implementation language (code level). Formal methods are available for each phase of this development process: • formal specification [71, 35] provides languages with mathematical semantics and al- 1http://www.rtca.org/lows one to express what the system should do; • verification of models against high-level specifications [16, 17, 23, 55, 12, 6] proves mathematically that the design of the system respects its specification; • code generation from high-level models [13] produces code respecting the semantics of the high-level language, thus preserving the verification effort thanks to certified / proved compilers. The work presented in this thesis focuses on the automatic verification of models against their specification. Indeed, while certification organisms acknowledge the existence of formal methods and advise to use them, there is a gap to bridge between their capabilities and the systems and specifications encountered in the industry. In practice verification of arbitrary functional properties on realistic systems often requires expert knowledge about the systems analyzed and the verification technique(s) used. The spread of formal verification in the industrial community is hindered by this need for costly and time-consuming expert intervention. The goal of this thesis is to improve on the state of the art of formal verification in our application domain by (i) improving its automation on common design patterns found in avionics systems; (ii) finding proofs that can be quickly re-checked and are thus trustworthy. To achieve these goals we propose to study the collaboration of existing formal methods – such as SMT solving, k-induction, Quantifier Elimination, etc. – to propose a methodology for the automatic discovery of lemmas easing the process of concluding the proof. Also, this work focuses on parallel algorithms, consistently with the current trend of multi-core and many-core computers. In this part of the thesis, we expose further the problem of formal verification of avionics critical systems at the model level in Chapter 4. We discuss languages used in model level conception in Section 4.1 and present common avionics design patterns in Section 4.2. Chapter 5 introduces basic formal notions to model the verification problems in Section 5.1 and presents building blocks to work on said verification problems, SAT and SMT solvers, in Section 5.2. Then, Chapter 6 formalizes the representation of critical systems thanks to transition systems in Section 6.1 and reviews the state of the art of transition system verification in Section 6.2 and Section 6.3. Part II presents our main contribution, a parallel collaborative proof engine architecture as well as invariant discovery methods to incorporate in this framework. Part III presents the most interesting aspects of our implementation of this proof engine, called Stuff. 2CHAPTER 4 Problem In this thesis, we focus on the analysis of embedded reactive systems [38]. These systems sample their environment using sensors, and compute an output used as a command for an actuator. Sampling is performed at regular intervals specified by the frequency of the system. We consider embedded reactive software functions which contribute to the safe operation of collections of hardware sensors, networked computers, actuators, moving surfaces, etc. called functional chains. A functional chain can for instance be in charge of "controlling the aircraft pitch angle", and must meet both qualitative and quantitative safety requirements depending on the effects of its failure. Effects are ranked from MIN (minor effect with no casualties) to CAT (catastrophic effect with casualties). For instance, the failure of a pitch control function is ranked CAT, and it shall be robust to at least a double failure and have an average failure rate of at most 10 −9 per flight hour. In order to meet these requirements, engineers must introduce hardware and software redundancy and implement several fault detection and reconfiguration mechanisms in their software. Software development is hard, even more so when developing real-time systems. To address this issue, programmers first design their programs in a language abstracting away real-time constraints. A code generator then produces low-level code targeted in real-time operating systems. We present design languages, and in particular the Lustre language, in Section 4.1. We then present our use case in Section 4.2, a typical avionics functional chain. We will focus in particular on the reconfiguration and voting subsystems. 4.1 Lustre: A Synchronous Programming Language Embedded systems in general and functional chains in particular have to comply with real-time constraints such as release dates and deadlines on the computations, assuming a non-faulty hardware. Low-level Application Programming Interfaces (API) such as POSIX [37] are now widely used for development of small real-time systems. To develop complex functional chains however, using such a low-level approach is tedious and error-prone, and overall unrealistic. This is why during the eighties synchronous languages such as Lustre [36], Esterel [7] and Signal [5] were proposed. The idea behind the synchronous paradigm is to4.1 Lustre: A Synchronous Programming Language Problem provide designers with a language which (i) allows one to design real-time systems at a higher level of abstraction; (ii) is formal, i.e. the semantics of a program is not ambiguous. In the following we will refer to this level of abstraction as the model level, as opposed to code level which is the code generated from a synchronous language. At the model level, realtime constraints are abstracted to the notion of steps or cycles, and the following hypothesis is assumed. Definition 4.1.1 (Synchronous Hypothesis) The Synchronous Hypothesis consists in viewing time as a succession of discrete instants at which computations take place instantly. Each of these instants defines a global state, yielding a state machine or transition system semantics. System design the at model level has many benefits. The most immediate from an industrial point of view is that it shortens development processes by letting the code generator handle the difficult part of implementing the high-level design by generating the low-level code. It is thus not surprising that synchronous languages have been rapidly adopted by embedded system designers. Most notably, the Esterel Technologies company1 provides them with a complete suite of tools, the SCADE SuiteR , including the KCG code generator certified/qualified according to international rail transport, nuclear energy, automotive and avionics standards. The SCADE suite is centered around the SCADE language, which is similar to Lustre. Verification, debug, coverage analysis. . . techniques are applied at the model level, on SCADE programs. Verification at the model level is a rewarding approach: as the code generator is trustworthy, a proof at the model level ensures the code generated respects the specification. Let us now give a brief overview of the Lustre language. It is the input language of the verification tool in which the techniques discussed in this thesis have been implemented. In addition to being a synchronous language, Lustre is a dataflow language: every variable or expression is an infinite flow, or stream, of values following the rhythm of a clock. Every Lustre program has a base clock, which represents the smallest, indivisible discrete steps for the program. All the other clocks are streams of Boolean values for each instant defined by the base clock and sample streams at a different, slower rate than the base clock. Consider for instance the following Lustre program defining a node, i.e. a set of equations. Counter c1 counts the number of cycles of the base clock and c2 counts the number of times clock, the Boolean input of the system, is true. 1http://www.esterel-technologies.com/ 4Problem 4.1 Lustre: A Synchronous Programming Language node counters(clock: bool) returns (c1,c2: int); let c1 = 0 -> pre(c1) + 1; c2 = 0 -> if clock then (pre(c2) + 1) else pre(c2); tel The equations linking the counters to the input are between the let and tel keywords. Output c1 is initially zero, and at each step after that – operator -> – is equal to its value in the preceding step plus one. Keyword pre is a unit delay operator defining a memory or latch. The memory contains the value of the expression given as argument at the previous step. So pre(c1) represents the value of stream c1 at the previous step. Stream c2 is also initially zero but must stay the same when clock is false, and be equal to its previous value plus one otherwise. Now, this node is observationally equivalent to the following one. node counters(clock: bool) returns (c1,c2: int); var c2C: int; let c1 = 0 -> pre(c1) + 1; c2C = (0 -> (pre(c2C) + 1)) when (true -> clock); c2 = current(c2C); tel A local variable, c2C, has been introduced and follows a different clock than the base one. The when keyword indicates that c2C is present – its clock ticks and its value is defined – when (true -> clock) is true, i.e. in the initial state and whenever clock is true. When it is not present, c2C is absent: it has no value. An example of trace – sequence of legal values for the flows of the system – follows. With the exception of the line corresponding to c2C, it is also a trace for the first version of the counters node since they are equivalent. base clock true true true true true true true . . . pre(c1) – 0 1 2 3 4 5 . . . c1 = 0 -> pre(c1) + 1 0 1 2 3 4 5 6 . . . clock false false true true false false true . . . true -> clock true false true true false false true . . . c2C 0 – 1 2 – – 3 . . . c2 0 0 1 2 2 2 2 . . . Notice that Lustre is a declarative language: "=" denotes a constraint via an equation, and is not an assignment. Hence the body of the node is defined in a declarative manner by a set of equations. Now, consider the Lustre program on Figure 4.1. Node middleValue returns the middle value of its three inputs. It also outputs a Boolean flag faulty which 54.1 Lustre: A Synchronous Programming Language Problem -- Returns the absolute value of its input. node abs(n: int) returns (result: int); let result = if (n < 0) then -n else n; tel -- "ok" becomes and stays false as soon as "in" escapes -- the -"bound", +"bound" interval. node bounded(in, bound: real) returns (ok: bool); let assert(bound > 0); ok = true -> pre(ok) and (abs(in) < bound); tel -- Returns the middle value of "in1", "in2" and "in3", and -- "faulty" which is true as soon as an input escapes its interval. node middleValue(in1, in2, in3, bound: real) returns (middle: real; faulty: bool); var c12, c13, c23, toProve: bool; let assert(bound > 0); c12 = in1 > in2; c23 = in2 > in3; c31 = in3 > in1; middle = if (c12 = c23) then in2 else if (c23 = c31) then in3 else in1; faulty = not (bounded(in1,bound) and bounded(in2,bound) and bounded(in3,bound)); tel Figure 4.1: A simple Lustre program. indicates whether the inputs have always been in a specified interval or not, i.e. it becomes true as soon as an input escapes its bounds, and stays that way forever. This nodes use the assert keyword specifying a constraint on the flows. 6Problem 4.1 Lustre: A Synchronous Programming Language bounded in bound ok true abs < and → pre Figure 4.2: Network representation of the bounded node. A Lustre program is a hierarchical network of nodes and operators connected by dataflow variables. Figure 4.2 for instance represents the bounded node in SCADE-like representation. Note the instantiation of the abs node, which means that an instance of the network corresponding to abs should be placed here. As another example, the middleValue node instantiates the bounded node three times, each with their different pre memories. The result is clear and unambiguous semantics for the Lustre programs. Verification. The node observer on Figure 4.3 illustrates the usual approach to the verifi- cation of Lustre programs. Its inputs correspond to the inputs and outputs of the middleValue node. It produces the value true at steps for which the value of result is within a certain range, and at steps where faulty is true. Node top instantiates nodes of the system and returns the status of the observers – only one in this example. The verification challenge is to prove that the observers always produce the value true. If this is the case on our example, then in all possible executions, whenever an input escapes its legal boundaries the faulty flag is raised and stays that way. Such properties are called safety properties: they specify the correct behavior of the system and should hold in any state of the system. They differ from liveness properties which express that "if is true, then eventually it must be true that ". For instance, it could be the case that the faulty flag is not raised immediately when an input escapes its bound. Instead, the system could wait for the input to stay out of its bounds for n steps to confirm that the input is indeed faulty. The specification could then be the bounded liveness property "if an input stays out of bounds for n consecutive steps, then the faulty flag is raised". Bounded liveness properties can be seen as safety properties as illustrated on Figure 4.4 using a counter node to count the number of cycles the inputs have been out of bounds for. This is not the case for unbounded liveness properties, such as "if an input stays out of bounds (for an arbitrary long time), then eventually the faulty flag will be raised", unless the system has a finite number of states [8], or for some special classes of infinite state systems [68]. 74.2 Safety Critical Avionics Systems Verification Problem node observer(in1, in2, in3, bound, result: real; faulty: bool) returns( toProve: bool ); let assume(bound > 0); -- As long as "faulty" is false, "result" is bounded by "bound". toProve = bounded(result,bound) or faulty; tel node top(in1, in2, in3, bound: real) returns (ok: bool) var result: real; faulty: bool; let assume(bound > 0); (result,faulty) = middleValue(in1,in2,in3,bound); ok = observer(in1,in2,in3,bound,result,faulty); tel Figure 4.3: The observer pattern. The last category of properties are those of fairness, which express the fact that if something is always possible then it must be done infinitely often. These properties are typically used to specify that when some concurrent processes run in parallel and try to access a resource concurrently, then if a process can always gain access to it then at some point it will. In the following however we will only consider safety properties. As we shall see in the presentation of our use case, industrial critical embedded systems are very complex: this results in what is known as the combinatorial explosion of the state space. The reachable state space, the set of all states the system can reach from its initial states, is so huge that it cannot be represented, or is simply infinite. Chapter 6 discusses a compact representation to conduct formal analyses on. 8Problem 4.2 Safety Critical Avionics Systems Verification node counter(condition: bool; max: int) returns (maxed: bool); var cpt: int; let assume(max > 0); cpt = 0 -> if (condition) pre(cpt)+1 else 0; maxed = cpt > max; tel node observer( in1, in2, in3, bound, result: real; faulty: bool ) returns(ok: bool) let assume(bound > 0); problemConfirmed = counter(not bounded(result,bound),42); ok = (not problemConfirmed) or faulty; tel Figure 4.4: Bounded liveness property as a safety property. Channel Sensors Order (x3) Speed (x3) Pitch (x3) SMon SMon SMon Voter Voter Voter Law AMon Actuator Figure 4.5: A Single Computation Channel. 4.2 Safety Critical Avionics Systems Verification Figure 4.5 presents a computation channel corresponding to the function "controlling the aircraft pitch angle" as usually found in avionics functional chains. Note that the sensors are triplicated to tolerate sensor faults and hence reduce the failure rate of the sampling. At each cycle, the channel samples the Speed, Pitch, and Order2 sensors. All the values sampled go through sensor monitors (SMon) in charge of detecting temporary or permanent failures such as out-of-bounds values. The signals then enter a triplex voter (Voter); the voter 2Order is the command from the pilot. 94.2 Safety Critical Avionics Systems Verification Problem Sensors Order (x3) Speed (x3) Pitch (x3) Channel1 Channel2 Channel3 Reconf Reconf1 Reconf2 Reconf3 Actuator Figure 4.6: Triple Channel Functional Chain. performs additional failure detection and outputs one single signal for, say, speed based on the three speed values sampled – the simple Lustre program from Figure 4.1 can be seen as a toy example of voting logic. The next block is the control law (Law) which computes the signal to send to the actuator using a single input value for order, speed and pitch. The signal also goes through an actuator monitor (AMon) which makes sure that the command is indeed enforced by the actuator. If it is not the case, a failure flag is raised. In order to further reduce the failure rate of this critical function of the aircraft, computation channels are triplicated (Figure 4.6): the computations are performed by three redundant channels running on separate hardware, each using distinct communication wires. To decide which channel actually controls the actuator, a reconfiguration mechanism (Reconf) is distributed over the three channels. It is responsible of the safety aspect of the triplication, reconfiguring the system in case a channel is considered corrupted because it either consumes or produces invalid data. In fact, whatever the output of each channel is, the reconfiguration mechanism should ensure that no command dangerous for the actuator or the aircraft is output by the triplicated architecture, and that proper flags are raised to inform the pilot whenever a failure is detected. Note that an incorrect output should not immediately mark a channel as corrupted. It could be that the disturbance is temporary, e.g. because of a thunderbolt nearby causing an electromagnetic perturbation. So, only if the output is incoherent for more than n cycles will the failure be considered permanent. To detect incoherent outputs and be able to produce a correct command while a timer counts the n cycles, functional chain designers can use a technique called shuffle. It typically takes place after the control law computation, as illustrated on Figure 4.7: each channel has access to the control law output computed by the other channels. The actual output of a channel is the result of a vote between those three values. This allows a channel to detect that it is incoherent on its own and count the n cycles while still producing a correct output. There is also a timer used before switching between a corrupted channel and a safe one; it can be the case that because of a temporary perturbation the channel in control stops sending a command for a short time. Also, channels 10Problem 4.2 Safety Critical Avionics Systems Verification Law Voter Law Voter Law Voter Figure 4.7: The shuffle mechanism. usually need to perform several checks before taking control to assess precisely the state of the actuator. As mentioned above, each channel runs on separate hardware, but it can be the case that the different parts of one channel also run on different hardware components. In that case functional chain designers can go further and allow the system to deactivate only part of a channel. For instance, assume channel 1 has control but realizes that the voter after the control law does not produce any output anymore because of a hardware failure. If the control law of channel 1 – running on different hardware than the voter – is still operative then it could be decided that control is transferred to channel 2, but that the control law of channel 1 keeps computing and participates in the voting now taking place on channel 2. Functional chains are extremely complex, and so is their specification [67]. Verification of the software of a full functional chain is thus a challenge for current techniques and tools. Even with a modular approach, individual verification problems are far from trivial. The objective of this thesis is to provide generic techniques for the verification of systems such as voting and reconfiguration logic implementations. These systems make extensive use of linear integer arithmetic because of the many timers they rely on for fault confirmation and transition between faulty channels, as well as linear real arithmetic when handling a signal. The voting logic for instance has to maintain a certain continuity in its output: the control law expects values consistent with the real world and unexpected behavior could arise, were its inputs to show discontinuities because of sensor failures. In particular, we will focus on the Rockwell Collins triplex voter system and an implementation of reconfiguration logic, the code of which is available in Appendix A. Control law systems differ from voting and reconfiguration in that they are based on differential equations. They can be non-linear or require a non-linear analysis and are outside the scope of this study. 11CHAPTER 5 Mathematical Background and Notation This chapter gives notation and notions in order to define the problem of Boolean satisfi- ability (SAT) and Satisfiability Modulo Theory (SMT). We will use SMT solvers extensively in this thesis. We begin by defining many-sorted first-order logic in Section 5.1. We then present the modern approach to solving SAT and SMT problems in Section 5.2. Last, we discuss the SMT-LIB 2 standard and additional features encountered in most state of the art solvers in Section 5.3. 5.1 Many-Sorted First-Order Logic This section formalizes the concepts required to define many-sorted first-order logic. The syntax of the logic allows the construction of sequences of symbols and is defined in Subsection 5.1.1 with the notions of many-sorted first-order signature and formula. In Subsection 5.1.2, semantics is given by structures over a many-sorted signature. Semantics gives meaning to the sequences of symbols allowed by the syntax. We then formally introducing logics in Subsection 5.1.3 before briefly discuss proof systems in Subsection 5.1.4. 5.1.1 Syntax Definition 5.1.1 (Many-sorted signature) A many-sorted first-order signature Σ is a tuple h Sorts, Var, Fun, Rank i consisting of: • a set of sorts Sorts containing at least the sort Bool; • a countably infinite set of variable symbols Var ∆= {v1, v2, . . . }, usually implicit when defining an actual signature; • a set of function symbols Fun such that Fun ∩ Var is empty and Fun contains ∧, ∨, ¬, ⊥, >, and =; • a left-total relation Rank on Fun × Sorts+. Each sort sequence associated to f by Σ is a rank of f.5.1 Many-Sorted First-Order Logic Mathematical Background and Notation Intuitively, the sorts of a signature are types used by the function symbols to specify their ranks. Note that overloading is supported: a function can have multiple ranks. We will rely heavily on the following notation to discuss function symbols ranks. Given a signature Σ, we write f(σ1, . . . , σn) : σ for (f, σ1 . . . σn σ) ∈ Rank and f : σ if n = 0, in place of f() : σ. Core signature. Core is the many-sorted signature h{Bool}, ∅, Funcore , Rank core i composed of the following function symbols: ∨ (Bool, Bool) : Bool ∧ (Bool, Bool) : Bool ¬ (Bool) : Bool > () : Bool ⊥ () : Bool = (Bool, Bool) : Bool Definition 5.1.2 (Legal many-sorted signatures) A legal many-sorted signaturehSorts, Var, Fun, Ranki is a many-sorted signature such that Bool ∈ Sorts, Fun ∈ Funcore , Rank ∈ Rank core , and for all σ ∈ Sorts: = (σ, σ) : Bool ∈ Rank. In the following we consider only legal signatures. For the sake of readability we will omit the word "legal". Definition 5.1.3 (Abstract syntax) Given a many-sorted signature Σ, the abstract syntax of Σ-terms is given by the following Extended Backus-Naur Form (EBNF [53]): T ::= v | f T∗ | f σ T ∗ | ∃(x : σ) + T | ∀(x : σ) + T | let (x = T) + in T | (T) where f ∈ Fun, σ ∈ Sorts and v ∈ Var. f T∗ is called a function application, and so is f σ T ∗ . let . . . in . . . is called a (parallel) let-binding. Symbols ∀ and ∃ are called quantifiers. Function application f σ distinguishes between applications of function symbols with more than one rank. This is made explicit in the rule (sfun) in the following rules of wellsortedness. Definition 5.1.4 (Rules of well-sortedness) Given a many-sorted signature Σ, an environment E is a set of statements v : σ, read as “v has sort σ”, where v ∈ Var and σ ∈ Sorts. We say that “term t is well-sorted of sort σ in E”, written E ` t : σ, if t is derivable by the following sorting rules: E ` v : σ (var) if v : σ ∈ E E ` t1 : σ1 . . . E ` tn : σn E ` (f t1 . . . tn) : σ (fun) if    f(σ1, . . . , σn) : σ ∈ Σ and f(σ1, . . . , σn) : σ 0 6∈ Σ for all σ 0 6= σ; E ` t1 : σ1 . . . E ` tn : σn E ` (f σ t1 . . . tn) : σ (sfun) if    f(σ1, . . . , σn) : σ ∈ Σ and f(σ1, . . . , σn) : σ 0 ∈ Σ for some σ 0 6= σ; 14Mathematical Background and Notation 5.1 Many-Sorted First-Order Logic E ∪ {v1 : σ1, . . . , vn : σn} ` t : Bool E ` (Q v1 : σ1 . . . vn : σn t) : Bool (Q) if Q ∈ {∃, ∀} and n > 0; E ` t1 : σ1 . . . E ` tn : σn E ∪ {v1 : σ1, . . . , vn : σn} ` t : σ E ` (let v1 = t1 . . . vn = tn in t) : σ (let) if n > 0. We say that a term t is well-sorted of sort σ if it is well-sorted of sort σ in {}, the empty environment. A well-sorted term is quantifier free if no quantifier appears in it – the (Q) rule is never used in its well-sortedness derivation. A well-sorted formula in E is a well-sorted term of sort Bool in E. Definition 5.1.5 An atom is a formula in which the logical connectives ∧ (conjunction), ∨ (disjunction) and ¬ (negation) do not appear. A literal is a or ¬(a) where a is an atom. A cube (resp. a clause) is a conjunction (resp. a disjunction) of literals. A formula is in Disjunctive Normal Form (DNF) if it is a disjunction of cubes. A formula is in Conjunctive Normal Form (CNF) if it is a conjunction of clauses. Additional notation. It is possible to define a concrete syntax using Polish prefix notation: an application of f(σ1, . . . , σn) : σ is of the form (f t1 . . . tn). While this notation is ideal for machines as it is easy to parse and print, it is usually painful to process for humans who are more accustomed to infix notation for applications of common function symbols, e.g. (n + 1 > 3) ∧ b instead of (∧ (> (+ n 1) 3) b). In this thesis we will manipulate terms extensively. We thus lighten their representation: application of f(σ1, . . . , σn) : σ will usually be written f(t1, . . . , tn) instead of f t1 . . . tn with the following alternatives: (t1 f t2) if n = 2, (f t1) if n = 1, or simply f if n = 0. Also, we allow ourselves to write Q(v1 : σ1, . . . , vn : σn) t for Q v1 : σ1 . . . vn : σn t where Q ∈ {∀, ∃}, and let (v1 = t1, . . . , vn = tn) in t for let v1 = t1 . . . vn = tn in t. The following operator precedence rules apply, where Q is a quantifier: = ¬ ∧ ∨ Q(. . .). where means “has precedence over”. Also, in a signature with function symbols ∗, −, +, ≥, ≤, >, < the following precedence convention will be followed: ∗ − + {≥, ≤, >, < } = For example, n + 1 > 3 ∧ b is the same as ((n + 1) > 3) ∧ b and as ∧(> (+(n, 1), 3), b). Last, we will often use the shorthand ⇒ defined as φ ⇒ ψ ∆= ¬φ ∨ ψ where φ and ψ are formulas. Note that "∆=" represents meta-equality and should be read as "is defined as". It differs from "=" which is just a function symbol in the signature. 15 Méthodes s´equentielles de Monte Carlo pour le suivi d’objets multiples h´et´erog`enes en donn´ees brutes de t´el´em´etrie laser Elodie Vanpoperinghe ´ To cite this version: Elodie Vanpoperinghe. M´ethodes s´equentielles de Monte Carlo pour le suivi d’objets multiples ´ h´et´erog`enes en donn´ees brutes de t´el´em´etrie laser. Other. Universit´e du Littoral Cˆote d’Opale, 2014. French. . HAL Id: tel-00983352 https://tel.archives-ouvertes.fr/tel-00983352 Submitted on 25 Apr 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse de doctorat De l’Université du Littoral Côte d’Opale Présentée par Élodie Vanpoperinghe Pour obtenir le grade de Docteur de l’Université du Littoral Côte d’Opale Domaine Automatique, génie informatique, traitement du signal et de l’image Méthodes séquentielles de Monte Carlo pour le suivi d’objets multiples hétérogènes en données brutes de télémétrie laser Thèse soutenue le 27 janvier 2014 devant le jury composé de Michèle ROMBAUT Professeur des Universités Université Joseph Fourier Président Régis LHERBIER Maître de Conférences Université du Littoral Côte d’Opale Examinateur Véronique CHERFAOUI Maître de Conférences - HDR Université de Technologie de Compiègne Rapporteur Yassine RUICHEK Professeur des Universités Université de Technologie de Belfort Montbéliard Rapporteur Jean-Charles NOYER Professeur des Universités Université du Littoral Côte d’Opale Co-directeur Martine WAHL Chargé de Recherche Institut Français des Sciences et Technologies des Transports, de l’Aménagement et des Réseaux Co-directeur Année 2013 École Doctorale SPI Numéro d’ordre : Sciences pour l’ingénieuri À tous ceux que j’aimeiiRemerciement Ce travail de thèse a été réalisé au laboratoire électronique, ondes et signaux pour les transports (LEOST du département COSYS de l’Ifsttar) dirigé successivement par Mme Marion Berbineau et M. Charles Tatkeu que je tiens à remercier. C’est avec bonne humeur et sympathie qu’ils m’ont accueillie au sein de leur équipe durant ma thèse. Je tiens à remercier l’Ifsttar et la région Nord-Pas-De-Calais pour avoir financé ce travail. Je tiens tout particulièrement à remercier M. Jean-Charles Noyer, mon directeur de thèse sans qui celle-ci n’aurait pu aboutir. Je suis reconnaissante du temps qu’il m’a accordé, ses qualités pédagogiques et scienti- fiques, son écoute, ses conseils, sa franchise et sympathie. J’ai beaucoup appris grâce à lui et je lui adresse ma gratitude pour cela. J’adresse de chaleureux remerciements à mon encadrant de thèse Mme Martine Wahl, pour son attention de tout instant sur mes travaux, pour ses conseils et son écoute qui ont mené à la réussite de cette thèse. Je souhaite remercier Dominique Gruyer pour m’avoir permis d’utiliser les données SiVIC qui ont été utilisées dans cette thèse. Je souhaite également remercier Sébastien Lefebvre pour m’avoir aidée dans l’utilisation de ce logiciel. Je souhaite remercier l’ensemble des membres du jury Véronique CHERFAOUI, Yassine RUICHEK, Régis LHERBIER, Michèle ROMBAUT qui m’ont fait l’honneur de lire ma thèse et participer à ma soutenance. Je voudrais leur témoigner ma gratitude et les remercier de l’intérêt qu’ils ont porté à mon travail. Comment ne pas remercier les membres du site de Villeneuve d’Ascq qui m’ont accueillie, conseillée et ont rendu agréable ces années : Isabelle, Corinne, Lidwine pour leurs attentions, leurs accompagnements administratifs et leurs échanges amicaux, Émilie, Mohamed qui m’ont supportée comme voisine de bureau. Manu qui a tout essayé pour avoir une JSS sans succès. Et enfin tous ceux que je ne cite pas mais avec qui j’ai eu l’honneur de discuter et d’échanger des idées. Un merci tout particulier a ceux qui ont parsemé ces trois années de souvenirs inoubliables : Sonia, Aurélie, Stephen, Élody, Paola, Camille, Wilfried, Cyril, Philippe, Greg, Manu et tant d’autres qui se reconnaitront. Sur un plan plus personnel, je tiens à remercier mes parents et grand-parents pour leur soutien sans faille depuis tant d’année. Merci à eux de toujours être là pour moi dans les bons comme les mauvais moments. Enfin je terminerais par mes amis sans qui rien ne serait possible, sans qui ma vie ne serait pas la même. Pour tous les moments de détente, les week-ends, les rires et les larmes que nous avons partagées. Pour leur présence et leur soutien dans ce voyage qui se termine. Fanny, Anne-Laure, Daisy, Béatrice, Jimmy, Élody, Aurélie et Florent, les mots ne suffisent pas pour exprimer ma gratitude et mon amour pour vous. iiiivTable des matières Liste des figures xiii Liste des tableaux xv Glossaire xvii Introduction 1 I Problématique, capteurs et architectures de traitement 3 I.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 I.2 Capteurs et architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 I.2.1 Capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 I.2.1.1 Système de vision par caméra . . . . . . . . . . . . . . . . . . . . . . . . 7 I.2.1.2 Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 I.2.1.3 Lidar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 I.2.2 Architectures de traitement de données . . . . . . . . . . . . . . . . . . . . . . . . 11 I.2.2.1 Architectures multicapteur classiques . . . . . . . . . . . . . . . . . . . . 11 I.2.2.2 Exemple d’une architecture autonome dans le domaine automobile . . . . 13 I.2.2.3 Architecture monocapteur pour lidar . . . . . . . . . . . . . . . . . . . . 13 I.3 Le télémètre laser à balayage : capteur lidar . . . . . . . . . . . . . . . . . . . . . . . . . . 15 I.3.1 Principe du télémètre laser à balayage . . . . . . . . . . . . . . . . . . . . . . . . . 15 I.3.2 Exemple de mesures lidar issue de capteur monoplan et multiplan . . . . . . . . . . 17 I.3.3 Évolution des capteurs lidar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 I.3.3.1 Capteur IBEO LD Automotive . . . . . . . . . . . . . . . . . . . . . . . . 20 I.3.3.2 Capteur IBEO LD-ML (Ladar Digital MultiLayer) . . . . . . . . . . . . . 20 I.3.3.3 Capteur ALASCA (Automotive Laser SCAnner) . . . . . . . . . . . . . . 21 I.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 II Problème de détection et suivi d’objets multiples 23 II.1 Architecture fonctionnelle classique du problème de détection et de suivi d’obstacles . . . . 23 II.2 Détection dans les données télémétriques . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 II.2.1 Partitionnement de données (clustering) . . . . . . . . . . . . . . . . . . . . . . . . 25 II.2.1.1 Algorithme de partitionnement . . . . . . . . . . . . . . . . . . . . . . . 25 II.2.1.2 Seuil adaptatif de Dietmayer et al. (2001) . . . . . . . . . . . . . . . . . 26 II.2.1.3 Seuil adaptatif de Santos et al. (2003) . . . . . . . . . . . . . . . . . . . 26 II.2.1.4 Seuil adaptatif de Borges et Aldon (2004) . . . . . . . . . . . . . . . . . 27 II.2.2 Segmentation de partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 II.2.2.1 Approche incrémentale . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 II.2.2.2 Approche Split and Merge . . . . . . . . . . . . . . . . . . . . . . . . . . 28 II.2.2.3 Approche RANSAC (Random Sample Consensus) . . . . . . . . . . . . . 30 vvi TABLE DES MATIÈRES II.2.2.4 Transformée de Hough . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 II.2.2.5 Approche de maximisation de l’espérance (EM, Expectation-Maximization) 33 II.2.3 Identification et classification d’objets . . . . . . . . . . . . . . . . . . . . . . . . . 34 II.3 Modélisation des objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 II.4 Association de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 II.5 Méthode de suivi : filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 II.6 Filtre de Kalman et ses filtres dérivés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 II.6.1 Filtre de Kalman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 II.6.2 Filtre de Kalman étendu (EKF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 II.6.3 Filtre de Kalman sans parfum (UKF) . . . . . . . . . . . . . . . . . . . . . . . . . 39 II.7 Filtrage particulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 II.7.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 II.7.2 Échantillonnage d’importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 II.7.3 Problème de la dégénérescence des particules . . . . . . . . . . . . . . . . . . . . . 43 II.7.3.1 Résolution de la dégénérescence par choix d’une densité d’importance optimale pour une application donnée . . . . . . . . . . . . . . . . . . . . . 43 II.7.3.2 Résolution de la dégénérescence par rééchantillonnage des poids . . . . . 44 II.8 Présentation de différents filtres particulaires . . . . . . . . . . . . . . . . . . . . . . . . . . 46 II.8.1 Filtre à échantillonnage séquentiel par importance (SIS) . . . . . . . . . . . . . . . 46 II.8.2 Filtre Bootstrap ou SIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 II.8.3 Filtre à rééchantillonnage adaptatif (SIR adaptatif) . . . . . . . . . . . . . . . . . . 48 II.8.4 Filtre particulaire auxiliaire (APF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 II.8.5 Filtre de Rao-Blackwell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 II.9 Exemples d’application au suivi de cibles . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 II.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 III Approche conjointe de détection et suivi 55 III.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 III.2 Présentation du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 III.3 Architecture fonctionnelle proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 III.4 Module de surveillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 III.4.1 Détecteur d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 III.4.1.1 Restriction des mesures d’un balayage à une zone d’étude . . . . . . . . . 60 III.4.1.2 Algorithme de partitionnement des mesures d’un balayage utilisant le seuil de Santos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 III.4.1.3 Algorithme de segmentation basé sur la théorie de Split and Merge . . . . 62 III.4.1.4 Calcul du centre de gravité de la partition . . . . . . . . . . . . . . . . . . 64 III.4.1.5 Résultats de détection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 III.4.2 Gestionnaire de pistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 III.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 III.5 Module de détection, association et suivi DAT . . . . . . . . . . . . . . . . . . . . . . . . . 70 III.6 Approche conjointe de détection et suivi (ITPF) . . . . . . . . . . . . . . . . . . . . . . . . 70 III.6.1 Modélisation d’état du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 III.6.1.1 Équation dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 III.6.1.2 Équation de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 III.6.2 Approche proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 III.6.2.1 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 III.6.2.2 Évolution des particules . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 III.6.2.3 Pondération des particules : exploitation du modèle d’état . . . . . . . . . 74 III.6.2.3.1 Calcul du poids sur la zone complète . . . . . . . . . . . . . . . 75TABLE DES MATIÈRES vii III.6.2.3.2 Calcul du poids sur une restriction de l’espace d’observation . . 75 III.6.2.4 Redistribution des particules . . . . . . . . . . . . . . . . . . . . . . . . 79 III.6.2.5 Prédiction de la partie linéaire (Kalman) du filtre de Rao-Blackwell . . . . 79 III.6.2.6 Estimation d’état . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 III.7 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 III.7.1 Cas synthétique de suivi multivéhicule . . . . . . . . . . . . . . . . . . . . . . . . . 80 III.7.1.1 Scénario et caractéristiques du capteur . . . . . . . . . . . . . . . . . . . 80 III.7.1.2 Comparaison de l’approche proposée ITPF à une approche classique (CDG) sur les données du simulateur de la thèse . . . . . . . . . . . . . . . . . . 82 III.7.2 Résultats obtenus avec les données du logiciel SiVIC . . . . . . . . . . . . . . . . . 92 III.7.2.1 Scénario et caractéristiques du capteur . . . . . . . . . . . . . . . . . . . 92 III.7.2.2 Comparaison de l’approche proposée ITPF à une approche classique (CDG) sur des données du simulateur SiVIC . . . . . . . . . . . . . . . . . . . . 94 III.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 IV Approche conjointe de détection et de suivi d’objets multiples hétérogènes par laser multiplans109 IV.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 IV.2 Détection et suivi d’objets multiples hétérogènes (approche VS-ITPF) . . . . . . . . . . . . 110 IV.2.1 Problématique du cas multi-objets . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 IV.2.2 Adaptation du module de surveillance au cas multi-objets hétérogènes . . . . . . . . 111 IV.2.3 Résumé des algorithmes du module de surveillance dans le cas multi-objets hétérogènes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 IV.2.4 Adaptation du module DAT au cas multi-objets hétérogènes . . . . . . . . . . . . . 115 IV.2.5 Résultats expérimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 IV.2.5.1 Scénario et caractéristiques du capteur pour le simulateur de la thèse . . . 116 IV.2.5.2 Résultat de l’approche multi-objets pour les données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 IV.2.5.3 Scénario et caractéristiques du capteur pour le simulateur SiVIC . . . . . 125 IV.2.5.4 Résultat de l’approche VS-ITPF pour les données du simulateur SiVIC . . 126 IV.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 IV.3 Détection et suivi d’obstacles multiples homogènes avec un lidar multiplan (approche MLITPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 IV.3.1 Problématique et mesures d’un capteur multiplan . . . . . . . . . . . . . . . . . . . 130 IV.3.2 Notation : extension au cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . 132 IV.3.3 Adaptation du détecteur d’objet du module de surveillance au cas multiplan . . . . . 132 IV.3.4 L’approche ML-ITPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 IV.3.4.1 Modélisation du problème . . . . . . . . . . . . . . . . . . . . . . . . . . 134 IV.3.4.2 Filtrage de Rao-Blackwell . . . . . . . . . . . . . . . . . . . . . . . . . . 135 IV.3.4.3 Évolution des particules . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 IV.3.5 Résultats expérimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 IV.3.5.1 Scénario et caractéristiques du capteur . . . . . . . . . . . . . . . . . . . 137 IV.3.5.2 Résultats de l’approche ML-ITPF . . . . . . . . . . . . . . . . . . . . . . 138 IV.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Conclusion 149 A Simulateur de données 153 A.1 Le capteur lidar à balayage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 A.1.1 Principe du générateur de données télémétriques . . . . . . . . . . . . . . . . . . . 154 A.1.2 Modélisation d’un scénario routier . . . . . . . . . . . . . . . . . . . . . . . . . . . 154viii TABLE DES MATIÈRES A.1.3 Modélisation de la trajectoire des véhicules cibles . . . . . . . . . . . . . . . . . . . 156 A.1.4 Construction d’une image pour un balayage donné . . . . . . . . . . . . . . . . . . 156 A.1.4.1 Représentation d’un véhicule dans le repère cartésien du capteur . . . . . 156 A.1.4.2 Représentation d’un véhicule dans le repère polaire du capteur . . . . . . 158 A.1.4.3 Calcul d’une image d’un véhicule dans le repère polaire du capteur . . . . 158 A.1.4.4 Calcul de l’image capteur d’une scène multivéhicule pour un balayage donné158 A.1.5 Exemple de données obtenues à partir du simulateur . . . . . . . . . . . . . . . . . 158 A.2 Le simulateur SiVIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 A.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 A.2.2 Fonctionnalités du simulateur SiVIC . . . . . . . . . . . . . . . . . . . . . . . . . . 161 A.2.3 Exemple de données obtenues avec le simulateur SiVIC pour un lidar multiplan . . . 161 Références bibliographiques 174Table des figures I.1 Nombre de tués sur les routes de 1950 à 2011 (Sécurité-routière, 2012) . . . . . . . . . . . . 3 I.2 Évolution du nombre de tués sur les routes en fonction des nouvelles législations (Sécurité- routière, 2012) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 I.3 Architecture minimale de détection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 I.4 Une camera avec objectif de type Fisheye à gauche et photo du ciel prise avec la caméra à droite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 I.5 Système stéréoscopique expérimental (LEOST) à gauche et image d’une scène prise par un système stéréoscopique et sa carte de disparité à droite . . . . . . . . . . . . . . . . . . . . 8 I.6 Image d’un radar SRR extraite de (Bank, 2007) . . . . . . . . . . . . . . . . . . . . . . . . 9 I.7 Principe du lidar multicouche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 I.8 Architecture de fusion centralisée extraite de (Waltz et Llinas, 1990) . . . . . . . . . . . . . 11 I.9 Architecture de fusion autonome extraite de (Waltz et Llinas, 1990) . . . . . . . . . . . . . 12 I.10 Architecture de fusion hybride extraite de (Waltz et Llinas, 1990) . . . . . . . . . . . . . . . 12 I.11 Architecture du système de fusion de données du projet CARSENSE extraite de Wahl (2002) 13 I.12 Architecture de traitement monocapteur lidar extraite de (Kiehn et al., 2002) . . . . . . . . . 14 I.13 Architecture de traitement monocapteur lidar extraite de Jida (2008) . . . . . . . . . . . . . 15 I.14 Principe du balayage horizontal (en haut) et vertical (en bas) extrait de (Besesty, 1999) . . . 15 I.15 Schéma de fonctionnement du télémètre laser à balayage extrait de (Besesty, 1999) . . . . . 16 I.16 Principe de mesure du temps de vol d’une onde émise par le télémètre laser à balayage extrait de (Besesty, 1999) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 I.17 Image CCD de la scène et le balayage capteur associé vu par le lidar monoplan (en bas à gauche) et par le lidar multiplan (en bas à droite) . . . . . . . . . . . . . . . . . . . . . . . 18 I.18 Agrandissement de la représentation de la scène vue par le lidar multiplan (figure I.18 à gauche) sur le véhicule en bas de la voie droite (à gauche) et sur le véhicule voie centrale (à droite) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 I.19 Présentation des capteurs DENSO, SICK LD-MRS et Velodyne HDL-64E (de gauche à droite) extrait de (com, 2014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 I.20 Le capteur IBEO LD-ML (à gauche) et ses caractéristiques (à droite) . . . . . . . . . . . . . 20 I.21 Le capteur IBEO ALASCA XT (à gauche) et ses caractéristiques (à droite) . . . . . . . . . 21 II.1 Étapes classiques d’un algorithme de détection et de suivi . . . . . . . . . . . . . . . . . . . 23 II.2 Seuil SNA fixe d’un algorithme non adaptatif . . . . . . . . . . . . . . . . . . . . . . . . . . 25 II.3 Paramètres du seuil adaptatif SSantos selon Santos et al. (2003) . . . . . . . . . . . . . . . . 26 II.4 Paramètres du seuil adaptatif SBorges selon Borges et Aldon (2004) . . . . . . . . . . . . . . 27 II.5 Exemple de dispersion des inliers et outliers . . . . . . . . . . . . . . . . . . . . . . . . . . 30 II.6 Paramètres (Θ,ρ) tels que Θ est l’angle polaire de la normale à la droite (d) (Duda et Hart, 1971) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 II.7 Biais de l’estimateur de Kalman étendu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 II.8 Évolution des particules (figure extraite de Diginext (1996)) . . . . . . . . . . . . . . . . . 42 ixx TABLE DES FIGURES II.9 Rééchantillonnage des particules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 II.10 Sélection des particules selon le vecteur U . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 III.1 Illustration d’un scénario de détection et de suivi . . . . . . . . . . . . . . . . . . . . . . . 56 III.2 Représentation d’un véhicule dans le repère du capteur . . . . . . . . . . . . . . . . . . . . 57 III.3 Représentation des impacts lidar pour différentes orientations de véhicules dans le référentiel du capteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 III.4 Architecture fonctionnelle de l’approche ITPF proposée . . . . . . . . . . . . . . . . . . . . 58 III.5 Architecture fonctionnelle simplifiée du module de surveillance . . . . . . . . . . . . . . . 59 III.6 Entités étudiées du détecteur d’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 III.7 Zone d’étude d’une autoroute à trois voies : la zone est construite de façon à rejeter les points de bordures de routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 III.8 Point de rupture d’un ensemble de mesures dont on cherche les droites d’interpolation . . . . 63 III.9 Illustration des cinq configurations possibles d’une partition selon la position relative de l’objet au capteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 III.10Estimation du centre de gravité des partitions détectées (données SiVIC) . . . . . . . . . . . 67 III.11Gestion des pistes d’une famille d’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 III.12Véhicule particulaire reconstruit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 III.13Une région d’intérêt (ROI) de la zone d’étude considérée . . . . . . . . . . . . . . . . . . . 76 III.14Paramètres (θ ROI min , θ ROI max , ρ ROI min , ρ ROI max ) d’une zone de suivi ou région d’intérêt (ROI) . . . . . 77 III.15Région ROI+ d’une région d’intérêt ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 III.16Cas limite de la région ROI+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 III.17Illustration des trajectoires relatives au véhicule porteur du capteur pour le scénario établi aux tableaux III.1 et III.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 III.18Comparaison du nombre de pistes créées avec le nombre de véhicules pour les méthode ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . 83 III.19Perception du lidar au temps t = 5s (mesures en rouge) superposée aux modèles estimés des véhicules (rectangle en bleu) : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 III.20Agrandissement des véhicules de la scène figure III.19, au temps t = 5s, véhicule de la voie centrale en haut et de la voie de gauche en bas : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . 84 III.21Perception du lidar au temps t = 10s (mesures en rouge) superposée aux modèles estimés des véhicules (rectangle en bleu) : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 III.22Agrandissement du véhicule de la voie de droite, au temps t = 10s, de la figure III.21 : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . 85 III.23Agrandissement du véhicule de la voie de gauche, au temps t = 10s, de la figure III.21 : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . 86 III.24Agrandissement du véhicule de la voie centrale, au temps t = 10s, de la figure III.21 : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . 86 III.25Courbes des Vitesses et accélérations de référence et estimées, du véhicule de la voie de droite en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 III.26Courbes des Vitesses et accélérations de référence et estimées, du véhicule de la voie de gauche en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 III.27Courbes des Vitesses et accélérations de référence et estimées, du véhicule de la voie centrale en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90TABLE DES FIGURES xi III.28Erreur sur la position du véhicule de la voie de droite en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . . . . 91 III.29Erreur sur la position du véhicule de la voie de gauche en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . 91 III.30Erreur sur la position du véhicule cible de la voie centrale en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur de la thèse . . . . . . 92 III.31Illustration des trajectoires des véhicules relativement au véhicule porteur du capteur pour le scénario établi au tableau III.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 III.32Quatre images de la scène au temps t = 0s, t = 2,5s, t = 5s et t = 10s . . . . . . . . . . . . 94 III.33Comparaison du nombre de pistes créées avec le nombre de véhicules détectés pour les méthodes ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . 95 III.34Nombre de pistes créées avec le nombre de véhicules détectés pour la méthode ITPF appliquées aux données du simulateur SiVIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 III.35Illustration de la perte d’un véhicule par masquage, image de la scène à t = 6,3s, t = 6,5s et t = 6,7s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 III.36Image CCD de la scène, au temps t = 5s et la même scène perçue par le laser à balayage (en rouge) superposée aux modèles estimés des véhicules (rectangle en bleu) : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . . . . . . . . . . 99 III.37Agrandissement du véhicule de la voie de droite haut, au temps t = 5s, de la figure III.36 : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . 99 III.38Agrandissement du véhicule de la voie centrale, au temps t = 5s, de la figure III.36 : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . . 100 III.39Agrandissement du véhicule de la voie de droite bas, au temps t = 5s, de la figure III.36 : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . 100 III.40Agrandissement du véhicule de la voie de gauche, au temps t = 5s, de la figure III.36 : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . 101 III.41Image CCD de la scène, au tempst = 10s et la même scène perçue par le laser à balayage (en rouge) superposée aux modèles estimés des véhicules (rectangle en bleu) : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . . . . . . . . . . 101 III.42Agrandissement des véhicules de la scène figure III.41, au temps t = 10s, véhicule de la voie de gauche en haut, de la voie de droite au centre et de la voie centrale en bas : approches ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . . . . . . 102 III.43Courbes de vitesse selon x en haut et y estimées du véhicule de la voie de droite en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données SiVIC . . . . 104 III.44Courbes d’accélération selon x en haut et y estimées du véhicule de la voie de droite en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données SiVIC 105 III.45Courbes de vitesse selon x en haut et y estimées du véhicule de la voie centrale en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données SiVIC . . . . 106 III.46Courbes d’accélération selon x en haut et y estimées du véhicule de la voie centrale en fonction du temps : approches ITPF à gauche et CDG à droite appliquées aux données SiVIC 107 IV.1 Calcul du nouveau centre de gravité après modification du modèle véhicule . . . . . . . . . 115 IV.2 Illustration des trajectoires relatives au véhicule porteur pour le scénario (défini par les tableaux IV.1 et IV.2), constitué d’un camion et de deux voitures . . . . . . . . . . . . . . . . 118 IV.3 Comparaison du nombre de pistes actives avec le nombre de véhicules estimé par le détecteur au cours de la simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 IV.4 Perception du lidar aux temps t = 5s (figure haut gauche), t = 7,5s (figure haut droite), t = 11s (figure bas gauche) et t = 14s (figure bas droite) superposée aux modèles de véhicules estimés par le filtre ITPF, pour un cas multi-objets . . . . . . . . . . . . . . . . . . . . . . . 119xii TABLE DES FIGURES IV.5 Courbes des vitesses à gauche et accélération à droite en fonction du temps, du camion situé à droite (figure du haut), du véhicule central (figure du centre) et du véhicule de gauche (figure du bas), pour un cas multi-objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 IV.6 Longueur et largeur estimées des boîtes englobantes des véhicules de la simulation en fonction du temps, en haut le camion et en bas les deux voitures . . . . . . . . . . . . . . . . . . 122 IV.7 Courbes d’erreur sur la position en fonction du temps, du camion situé voie de droite (figure haut gauche), pour la voiture voie centrale (figure haut droite) et pour la voiture voie de gauche (figure du bas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 IV.8 Illustration des trajectoires relatives au véhicule porteur pour le scénario du simulateur SiVIC 125 IV.9 Quatre images de la scène au temps t = 1s, t = 4s, t = 7,5s et t = 10s . . . . . . . . . . . . 126 IV.10Scènes aux instants t = 1s (figure haut gauche), t = 4s (figure haut droite), t = 7,5s (figure bas gauche) et t = 10s (figure bas droite) et véhicules estimés par le filtre VS-ITPF . . . . . 127 IV.11Longueur et largeur estimées des véhicules en fonction du temps à gauche l’Espace et à droite la Mini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 IV.12Représentation de l’Espace avant à t = 1s (à gauche) et après à t = 4s (à droite) mise à jour des dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 IV.13Architecture fonctionnelle de l’approche VS-ITPF modifiée . . . . . . . . . . . . . . . . . . 129 IV.14Exemple de deux véhicules vus par un capteur lidar multiplan au temps t = 5s (en bleu tir à 0˚ d’élévation, en rouge tir à 0,4˚ d’élévation, en vert tir à 0,8˚ d’élévation et en cyan tir à 1,2˚ d’élévation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 IV.15Nombre de véhicules détectés en fonction du temps pour les plans 1 (à gauche) et 3 (à droite) 132 IV.16Illustration d’un véhicule vu par quatre plans capteur et la détection qui en découle . . . . . 134 IV.17Double restriction, ROI+ d’une région d’intérêt ROI de la zone d’étude considérée . . . . . 136 IV.18Trajectoires relatives au véhicule porteur de l’ensemble des véhicules de la scène . . . . . . 138 IV.19Quatre images de la scène au temps t = 0s, t = 2,5s, t = 5s et t = 10s . . . . . . . . . . . . 138 IV.20Comparaison du nombre de pistes créées avec le nombre de véhicule estimé par le détecteur présent au cours de la simulation, pour les méthodes ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC . . . . . . . . . . . . . . . . . . . . . . . . . 140 IV.21Image CCD de la scène, au temps t = 5s et la même scène perçue par le laser à balayage (en rouge) superposée aux modèles estimés des véhicules (rectangle en bleu) : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 IV.22Agrandissement du véhicule de la voie de droite haut, au temps t = 5s, de la figure IV.21 : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 IV.23Agrandissement du véhicule de la voie centrale, au temps t = 5s, de la figure IV.21 : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 IV.24Agrandissement du véhicule de la voie de gauche, au temps t = 5s, de la figure IV.21 : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 IV.25Image CCD de la scène, au temps t = 10s et la même scène perçue par le laser à balayage (en rouge) superposée aux modèles estimés des véhicules (rectangle en bleu) : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 IV.26Agrandissement du véhicule de la voie de droite, au temps t = 10s, de la figure IV.25 : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143TABLE DES FIGURES xiii IV.27Agrandissement du véhicule de la voie centrale, au temps t = 10s, de la figure IV.25 : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 IV.28Agrandissement du véhicule de la voie de gauche, au temps t = 10s, de la figure IV.25 : approches ML-ITPF à gauche et CDG à droite appliquées aux données du simulateur SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 IV.29Courbes de vitesse selon x en haut et y en bas estimées du véhicule de la voie de droite en fonction du temps : approches ML-ITPF à gauche et CDG à droite appliquées aux données SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 IV.30Courbes d’accélération selon x en haut et y en bas estimées du véhicule de la voie de droite en fonction du temps : approches ML-ITPF à gauche et CDG à droite appliquées aux données SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 IV.31Courbes de vitesse selon x en haut et y en bas estimées du véhicule de la voie de gauche en fonction du temps : approches ML-ITPF à gauche et CDG à droite appliquées aux données SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 IV.32Courbes d’accélération selon x en haut et y en bas estimées du véhicule de la voie de gauche en fonction du temps : approches ML-ITPF à gauche et CDG à droite appliquées aux données SiVIC, pour un cas multiplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 A.1 Modélisation de la route, du capteur et des véhicules cibles . . . . . . . . . . . . . . . . . . 155 A.2 Modèle de la voiture dans les repères cartésien et polaire du capteur . . . . . . . . . . . . . 157 A.3 Données générées pour le scénario considéré (deux véhicules V1, V2 dont l’un change de voie)160 A.4 Modélisation de la rotation du capteur lidar pour générer des données multiplans . . . . . . 162 A.5 Exemple de données générées par le simulateur SiVIC . . . . . . . . . . . . . . . . . . . . 163xiv TABLE DES FIGURESListe des tableaux I.1 Comparaison des capteurs DENSO, SICK LD-MRS et Velodyne HDL-64E extrait de (com, 2014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 III.1 Paramètres de simulation du capteur positionné relativement à la route (données du simulateur de la thèse) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 III.2 Paramètres de simulation initiaux des véhicules cibles relativement à la route (données du simulateur de la thèse) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 III.3 Écart-type de l’erreur d’estimation des positions, vitesses et accélérations pour les véhicules cibles sur une période de convergence de les méthodes ITPF et CDG appliquées aux données du simulateur de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 III.4 Paramètres de simulation du capteur positionné relativement à la route (données SiVIC) . . . 93 IV.1 Paramètres de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 IV.2 Paramètres de simulation initiaux des véhicules cibles relativement à la route et au véhicule porteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 IV.3 Écart-type de l’erreur d’estimation des positions, vitesses et accélérations pour les véhicules cibles sur une période de convergence de la méthode VS-ITPF appliquées aux données du simulateur de la thèse, dans un cas multi-objets . . . . . . . . . . . . . . . . . . . . . . . . 124 IV.4 Paramètres de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 IV.5 Paramètres du capteur positionné relativement à la route . . . . . . . . . . . . . . . . . . . 137 A.1 Données paramétrables pour un scénario donné . . . . . . . . . . . . . . . . . . . . . . . . 155 A.2 Données paramétrables pour chaque sous-ensemble du scénario . . . . . . . . . . . . . . . 156 A.3 Paramètres de simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 A.4 Paramètres du véhicule V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 A.5 Paramètres du véhicule V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 A.6 Paramètres de simulation du véhicule capteur, du capteur et de la route pour un scénario donné associé au simulateur SiVIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 xvxvi LISTE DES TABLEAUXGlossaire (i) une particule. N le nombre de particules. Xt le vecteur d’état de position, vitesse et accélération à l’instant t, Xt = [x, y, vx, vy, ax, ay]. X (i) t le vecteur d’état estimé à l’instant t pour la particule (i). Zt le vecteur des mesures du balayage capteur de l’instant t, Zt = {zθ ;θ ∈ {θmin,θmin +∆θ,...,θmax}} . t l’indice de l’échantillon de mesure. w (i) t le poids de la particule (i) à l’instant t. (ρ,θ) les mesures en sortie du capteur. (θmin,θmax) l’ouverture angulaire du capteur. Z (i) t le vecteur à l’instant t des échos reconstitués d’un véhicule à partir de la particule (i). ∆θ la résolution angulaire du capteur. ∆t la période d’échantillonnage du capteur. Pt l’ensemble des partitions de Zt , Pt = n P(n);n ∈ [0,Nmax],Nmax ≤ θmax−θmin ∆θ +1,P(0) = ∅ o . ρ la distance de l’impact au capteur. θ la résolution angulaire du capteur (pas de tir du capteur). z + θ la mesure de l’écho par le capteur à l’angle de tir suivant, θ + = θ +∆θ . z − θ la mesure de l’écho à l’angle de tir précédent, θ − = θ −∆θ . zθ la mesure d’un écho exprimée en coordonnées polaires, zθ=(ρθ ,θ), ou en coordonnées cartésiennes, zθ=(xθ ,yθ ). xviixviii GlossaireIntroduction Avec l’augmentation globale du trafic routier, la sécurité est devenue une problématique de plus en plus importante. Limiter les risques d’accidents et les dégâts corporels sont des soucis permanents tant chez les constructeurs automobiles que pour l’État. Ces dernières années, on a pu voir de nombreuses campagnes publicitaires et de nombreuses lois visant à limiter ces risques. Depuis les années 80, de nombreuses recherches sont effectuées dans le domaine de la sécurité routière et notamment sur les systèmes d’aide à la conduite dits « intelligents » tels que les ADAS (Advance Driver Assistance System). Ceux-ci exploitent les informations de l’environnement proche du véhicule afin de mettre en place des systèmes d’aide à la conduite. La difficulté réside dans le choix des systèmes de perception et des traitements associés. Les travaux effectués durant cette thèse se placent dans ce cadre général. On s’intéresse à un système coopératif de perception active distribué et interconnecté par réseaux de communication (véhicule à véhicule ou V2V). Ce type de système a pour but d’accroître le champ de vision de chacun des véhicules d’une scène par la prise en compte de données provenant des véhicules situés dans son voisinage. Pour cela, chaque véhicule est composé d’un système de perception local (pour la détection et le suivi des objets) et d’un système de communication (pour la réception et le transfert des données). Dans cette thèse, nous nous sommes intéressés, plus particulièrement, au système de perception local avec l’étude des problèmes de détection et de suivi multi-objet à partir de données télémétriques de type lidar à balayage. Ainsi, notre objectif est de surveiller en permanence l’environnement proche du véhicule, par une détection et un suivi des obstacles afin de détecter les situations potentiellement dangereuses. L’étude générale du problème de détection et de suivi a attiré notre attention sur les problèmes de pertes d’informations et les cas de fausses alarmes. Les mesures issues des capteurs de type lidar sont de nature spatialement distribuées ce qui conduit généralement à l’utilisation d’une étape de prétraitement (composée, dans ce cas, de la détection et de l’association des objets de la scène). Cette phase permet d’extraire les vé- hicules présents dans la scène et de délivrer une information sur leur position et vitesse relative. Il est connu que cette étape de prétraitement peut engendrer des pertes d’informations menant à des cas de non détection ou à des données aberrantes. Par ailleurs, les non-linéarités liées à la transformation polaire-cartésien des mesures lidar ne permettent plus de préserver la statistique des bruits de mesure après traitement. La conclusion qui en découle est que seule une approche exploitant directement les données brutes permet de garantir l’optimalité des traitements (association, suivi, etc.). Pour cela, on s’est intéressé plus particulièrement aux méthodes de Monte Carlo séquentielles (également appelées filtrage particulaire) pour leur aptitude à traiter toute non-linéarité de modèle de manière naturelle. Pour résoudre ce problème, nous avons développé une approche conjointe de détection et de suivi, que nous appellerons Integrated Tracking Particle Filter (ITPF). Parmi l’ensemble des méthodes particulaires disponibles, nous nous sommes focalisés sur les approches de filtrage hybride de type Rao-Blackwell. Ces méthodes permettent d’exploiter les linéarités du modèle d’état de manière indépendante par un filtre conditionnellement linéaire de type Kalman, optimal dans ce contexte. Le traitement de la partie non-linéaire est dévolu au filtre particulaire. Le problème ainsi posé repose sur une exécution conjointe des phases de dé- tection et de suivi des objets dans l’espace d’étude. Nous excluons de notre approche, tout recours à une phase de détection isolée, utilisée comme entrée de l’étape de suivi. L’information utilisée correspond donc à la mesure en sortie de capteur et non pas à une information potentiellement tronquée par un détecteur. 12 INTRODUCTION Comme tout filtre récursif, il est connu que la vitesse de convergence de la méthode peut dépendre de l’information dont on dispose a priori sur l’environnement. C’est pourquoi, nous mettons en place un module de surveillance dont le but est de fournir au filtre ITPF une information a priori sur les objets présents. Ce module agit alors comme un module de « veille » qui observe en permanence l’environnement du véhicule porteur et alimente en continu le filtre de détection/suivi. Comme dans toute méthode de suivi, une place importante doit être laissée à la validation des approches proposées sur des données expérimentales. Nous avons donc choisi de les évaluer sur deux simulations dont les détails sont donnés en annexe : – un premier simulateur dont l’objectif est d’évaluer les performances en estimation qui permet, par une connaissance exacte des paramètres dynamiques de tester les performances limites de la méthode ; – le simulateur SiVIC développé par le LIVIC qui permet, par un rendu très proche de la réalité, d’évaluer la robustesse de nos approches vis-à-vis des géométries variables d’objets, de non détection et de fausse alarme. Dans ce contexte, il est toujours difficile de pouvoir qualifier une nouvelle approche vis-à-vis de l’état de l’art sur le domaine. Nous avons donc choisi de comparer notre approche ITPF à une méthode classique basée sur un suivi du centre de gravité après une étape de détection, pour la même méthode de filtrage particulaire. Cette méthode CDG (centre de gravité) est fondée sur la mise en œuvre séquentielle de la détection, de l’association et du suivi des centres de gravité des objets de la scène. Ceci permet également d’évaluer l’apport d’une approche conjointe de détection et suivi. Cette thèse s’articule autour de quatre chapitres : Le premier chapitre expose le contexte général applicatif de la thèse. Il met en avant les différentes dif- ficultés liées aux choix du capteur et de l’architecture fonctionnelle à mettre en place. Ce chapitre permettra d’amorcer nos choix pour la résolution du problème. Le second chapitre propose un état de l’art des techniques de détection et de suivi d’objets multiples à partir de mesures lidar. Nous nous sommes inspirés des différentes étapes de détection, association et suivi d’une architecture fonctionnelle de traitement classique pour présenter les différentes étapes. Ce chapitre permet d’exposer, d’une part, les techniques de détection et de suivi les plus couramment utilisées dans la littérature et, d’autre part, il permet de proposer une comparaison de quelques méthodes de filtrage (particulaire) par rapport au filtre de Kalman (plus classiquement utilisé pour le suivi de véhicule). Ce dernier point permettra de détailler les raisons de notre choix de méthode de filtrage. Maintenant que nous avons parcouru l’ensemble du problème, le chapitre trois propose de décrire notre méthode conjointe de détection et de suivi multi-objet (ITPF). Cette méthode a la particularité de ne pas utiliser de phase de détection ni d’association, puisque la détection et le suivi sont réalisées par le filtre particulaire mis en place. La méthode présentée propose d’utiliser, tout au long des traitements, la mesure brute en sortie du capteur. On s’intéressera, dans ce chapitre, au cas simplifié d’une détection et d’un suivi multi-objet de forme et taille semblable sur des données lidar monoplan (c’est-à-dire que le capteur lidar balaye la scène sur un seul plan vertical durant toute la simulation). Les capteurs lidar monoplans ayant montré, sur route, leur vulnérabilité au tangage et roulis, le chapitre quatre se propose de traiter le cas de capteur lidar multiplan. Afin de traiter le problème dans sa globalité, nous choisissons également d’accroître notre champ de recherche à l’étude d’objet de différentes natures (tels que camion, piéton...) dans ce chapitre. De même, la possibilité d’obtenir plusieurs plans verticaux de balayage va modifier les structures de détection et de filtrage afin de prendre en compte les informations des différents plans de balayage. L’intégration des différents plans de mesures va ainsi être discutée dans un second temps. Enfin, nous conclurons sur les apports et perspectives de nos travaux.Chapitre I Problématique, capteurs et architectures de traitement I.1 Problématique Les accidents de la route sont la première cause de mortalité chez les 15−29 ans et restent importants dans les autres classes d’âges. Le parc automobile français, constitué de l’ensemble des véhicules immatriculés en France, est passé de 4,5 millions en 1955 contre plus de 38 millions de véhicules au premier janvier 2012. Selon les chiffres de la sécurité routière (figure I.1), issus de l’observatoire national interministériel de sécurité routière (ONISR), nous sommes passés d’environ 18000 tués sur les routes dans les années 70 à 3963 personnes tuées en 2011. FIGURE I.1. Nombre de tués sur les routes de 1950 à 2011 (Sécurité-routière, 2012) Il existe plusieurs causes et facteurs de risque d’accident dont nous faisons une liste non-exhaustive : – comportement des usagers (non respect du code, ingestion de substances influençant le comportement, téléphone...), – fatigue, baisse de vigilance et somnolence, – vitesse, – infrastructures routières, – véhicules automobiles. Bien qu’il soit impossible d’agir sur l’ensemble de ses facteurs, de nombreuses mesures sont mises en 34 Problématique, capteurs et architectures de traitement place pour en limiter les risques. Par exemple, dans les années 70 où le taux de mortalité sur les routes atteint un pic, le port obligatoire de la ceinture de sécurité et l’apparition des limitations de vitesse sur routes et autoroutes ont initié une baisse du nombre de tués sur les routes (figure I.2 issue de l’observatoire national interministériel de sécurité routière (ONISR)). Par la suite, de nouvelles législations relatives au code de la route apparaissent. Leur mise en place permet la poursuite de la baisse de mortalité sur les routes. Les plus récentes (2012) concernent l’interdiction des avertisseurs radar et le durcissement des sanctions contre l’utilisation du téléphone portable au volant. FIGURE I.2. Évolution du nombre de tués sur les routes en fonction des nouvelles législations (Sécurité- routière, 2012) Dans le même temps, les constructeurs automobiles conçoivent des véhicules de plus en plus sûrs. Ils mettent en place des systèmes de sécurité dits actifs ou passifs : – les systèmes passifs n’interviennent pas directement sur la conduite. Ils permettent de sécuriser les passagers ou les usagers de la route. Citons par exemple, la ceinture de sécurité, les airbags (coussins gonflables de sécurité) ou également les études sur l’optimisation des déformations de la structure du véhicule. – les systèmes actifs eux interviennent directement sur la conduite. Ils permettent d’aider le conducteur. L’aide au freinage ABS (Anti Blockier System), par exemple, est apparu pour la première fois en 1966 (Wikipedia, 2013). Cependant, ces systèmes ne permettent pas d’anticiper des situations à risque mais seulement de répondre à un problème survenu. Idéalement, un système de freinage va s’activer lorsque la pédale de frein est activée. Par contre, les systèmes d’aide à la conduite dits « intelligents » sont capables d’interagir avec le conducteur sans s’y substituer. C’est ce genre de système qui est étudié dans cette thèse. Comme nous venons de le voir, la sécurité routière est, de nos jours, très importante. Limiter les risques d’accidents est un souci permanent tant chez les constructeurs automobiles que pour l’État. Actuellement, les recherches sont centrées sur les systèmes d’aide à la conduite dits « intelligents » tels que les ADAS (Advanced Driver Assistance Systems). Les ADAS exploitent les informations de l’environnement proche du véhicule afin de mettre en place des systèmes d’aide à la conduite. Les recherches portent sur des aspects perceptifs comme la détection de signalisation, la détection d’obstacle, les systèmes de conduite autonome.Problématique 5 La détection et le suivi d’obstacle s’avèrent prometteurs pour anticiper les collisions, principales causes d’accidents corporels. Depuis les années 90, de nombreux travaux ont été menés sur ce sujet. La difficulté réside ici dans le choix du système de perception, d’une méthode de détection et de suivi. Dans la suite, nous faisons une rapide étude des techniques d’exploitation des informations de l’environnement qui se basent sur trois principales étapes dont l’architecture est présentée en figure I.3. FIGURE I.3. Architecture minimale de détection Les travaux portés par les chercheurs diffèrent en particulier par le système de perception utilisé : radar (Tan et al., 2007; Bank, 2007), lidar (Takagi et al., 2006) et image (Tango et al., 2008; Richter et al., 2008). Dans la suite, nous présentons des exemples utilisant l’un ou l’autre de ces capteurs. Dans ce cadre, une thématique importante est la détection d’obstacle au voisinage du véhicule. Dans notre contexte d’étude autoroutier, nous considérerons comme l’a fait (Perrollaz, 2008) qu’un obstacle est un objet de taille significative susceptible de couper la route de notre véhicule dans un laps de temps court, compte tenu du temps de réaction du conducteur et des vitesses mises en jeu. Le problème peut être étudié selon deux points de vue, que cherche-t-on à détecter, et quels outils de détection peut-on mettre en œuvre ? Dans le premier cas, nous cherchons à déterminer des obstacles potentiels au voisinage du véhicule. Le type d’obstacle diffère selon l’environnement dans lequel nous nous trouvons. Par exemple, sur autoroute, les principaux objets à suivre sont des véhicules motorisés (tels que véhicule, camion...), par contre, à un carrefour, il faut également prendre en compte les piétons, les cyclistes, etc. Citons les travaux de (Koller et al., 1992) qui proposent une détection des véhicules dans des séquences d’images et les travaux de (Sato et al., 2010; Ogawa et al., 2011) qui travaillent à partir de données lidar, pour la détection de piétons. Après avoir décrit quel type d’objet nous cherchons à détecter, le deuxième aspect de la détection concerne les outils. Comment détecter ces objets dans des séquences d’images ou de données ? Pour cela, plusieurs méthodes existent pouvant être utilisées à la fois dans le cas de séquences d’images et dans le cas de séquences de données (radar, lidar). Deux types d’algorithmes de détection existent : – les algorithmes de partitionnement qui consistent à regrouper les mesures qui partagent un caractère commun. Citons, par exemple, l’algorithme de K-means, méthode dont le but est de diviser des observations en K partitions dans lesquelles chaque observation appartient à la partition avec la moyenne la plus proche, ou encore les algorithmes reposant sur la comparaison de critère de distance entre deux données successives telles que les seuils adaptatifs de Santos (Santos et al., 2003), de Borges (Borges et Aldon, 2000, 2004) et de Dietmayer (Dietmayer et al., 2001). – les algorithmes de segmentation qui consistent à retrouver des formes (droites, rectangles, etc) dans des ensembles de données. Leur but est d’extraire les contours des objets. Citons quelques exemples d’algorithmes. L’algorithme Split and merge (Ray et Ray, 1995) permet de réaliser des approximations polygonales de lignes par une succession de division de ces lignes en deux, puis par une phase de fusion. La transformée de Hough (Duda et Hart, 1971) cherche à déterminer les paramètres géomé- triques d’une forme donnée au moyen de vote. L’approche de maximisation de l’espérance (Dempster et al., 1977) repose sur la recherche du maximum de vraisemblance ou du maximum a posteriori pour estimer les paramètres de modèle statistique. L’algorithme de Ransac, méthode destinée à estimer les6 Problématique, capteurs et architectures de traitement paramètres d’un modèle mathématique à partir d’un ensemble de données observées contenant un grand nombre de valeurs aberrantes. Il reste une étape à étudier, le suivi des objets détectés. Cette étape est indispensable afin de déterminer si un objet est un futur obstacle ou non. Là encore, différentes méthodes existent. En effet, au début des années 90, dans le contexte automobile, c’est le filtre de Kalman (KF) qui est utilisé pour le suivi des objets car il a prouvé son efficacité dans de nombreux domaines applicatifs. Différentes méthodes seront alors mises en œuvre comme l’utilisation de plusieurs capteurs (Baig et al., 2011; Darms et al., 2008), l’utilisation des lignes de la route qui permettent d’améliorer les précisions de modèle (Tan et al., 2007). Cependant, ce filtre ne permet pas l’étude de système non-linéaire. Des extensions du filtre de Kalman prenant en compte ce type de systèmes existent : le filtre de Kalman étendu (EKF) permettant de linéariser les systèmes non-linéaires et le filtre de Kalman sans parfum (UKF) qui est une extension de la transformation sans parfum (méthode pour calculer les statistiques d’une variable aléatoire issue d’une transformation non-linéaire). De même que pour le filtre de Kalman, ces filtres sont exploités. Depuis les années 2000, une nouvelle catégorie de filtres, reposant directement sur l’estimation de la densité de probabilité conditionnelle, solution du problème de filtrage, fait son apparition. Ces filtres, appelés filtres particulaires ou méthodes de Monte-Carlo séquentielles ont été introduis en 1992. Contrairement au filtre de Kalman et ses extensions, ces derniers sont applicables quelles que soient les non-linéarités de modèle. Une autre difficulté réside dans l’environnement dans lequel nous nous trouvons. En effet, la technique mise en œuvre pour suivre un véhicule de jour sera différente de celle de nuit, compte tenu des différences de visibilité. Le jour, les véhicules sont entièrement visibles (s’ils ne sont pas occultés par les autres), par contre de nuit, les véhicules sont partiellement visibles (sans pour autant être occultés). Cela implique des méthodes de suivi variées. Considérons l’exemple de O’Malley et al. (2011), où les auteurs partent du constat que, la nuit, les premiers éléments visibles des véhicules sont ses phares. C’est pourquoi, ils proposent un système de traitement des images vidéo pour détecter et suivre les véhicules de nuit à partir de leurs phares. Pour le suivi de jour, il existe plusieurs méthodes, par exemple, celle de Tan et al. (2007), qui met en place un système de vision monoculaire guidé par radar combiné à la détection et au suivi de la signalisation horizontale de la route afin de détecter les véhicules et prédire leur intention de changer de voie. Leur but est de mettre en place des systèmes d’aide à la conduite et de prévention de collision. On peut constater le même phénomène avec le suivi des piétons. Olmeda et al. (2009) proposent de dé- tecter et suivre, de nuit, des piétons à partir d’une caméra infrarouge avec laquelle ils peuvent extraire les caractéristiques de distribution de la chaleur du corps humain. Dans les travaux de Masoud et Papanikolopoulos (2001), les auteurs s’intéressent à la modélisation et au suivi des piétons, de jour, aux intersections de type carrefour. Pour cela, ils présentent un système temps réel pour le suivi de piétons dans des séquences d’images acquises par caméra fixe. Compte tenu du nombre important de recherches sur le sujet, il est évident que nous n’avons pas balayé l’intégralité des techniques et méthodes utilisées pour la détection et le suivi d’obstacles sur route. Cependant, nous avons mis en évidence que le choix d’un capteur, d’un outil et plus généralement d’une méthode de détection et de suivi est déterminé par le système que nous souhaitons étudier. Toute la difficulté réside donc dans les choix réalisés pour la mise en place de notre approche de détection et de suivi multicible. Quel capteur est le plus approprié ? De quels outils de détection et de suivi avons-nous besoin ? Et enfin quelle méthode allons-nous mettre en place ? Le paragraphe suivant sera consacré à l’étude des capteurs utilisés dans le domaine automobile et aux architectures fonctionnelles existantes.Capteurs et architectures 7 I.2 Capteurs et architectures La section précédente a mis en évidence la complexité des systèmes de suivi multi-objets, liés aux contraintes du domaine autoroutier et à l’environnement. Dans cette section, nous cherchons des solutions à ces contraintes en étudiant les différents capteurs utilisés et également les différentes architectures de traitement qui existent, pour la détection d’objets sur route. Nous étudierons dans un premier temps les différents capteurs, puis dans un second temps les architectures existantes. I.2.1 Capteurs I.2.1.1 Système de vision par caméra Les systèmes de vision par caméra sont utilisés dans les systèmes d’aide à la conduite. Suivant le système mis en place, ils sont composés d’une ou plusieurs caméras. Elles permettent d’accéder à une grande quantité d’informations sur un champ de vue large (les données maximales peuvent atteindre 180˚ d’angle de vue sur environ 90m). L’image résultante peut être en couleur, en niveau de gris ou encore une image infrarouge, cela dépend de la caméra utilisée. L’un des inconvénients de la caméra pour ce type d’application est qu’elle ne fournit pas directement l’information de mesure des distances. Pour cela, elle doit faire appel à des algorithmes de traitement d’image plus ou moins complexes pour réaliser la détection. Dans la littérature, différents systèmes sont mis en place à partir de caméra. – Les systèmes de vision par caméra monoculaire se distinguent généralement par le type d’objectif qui les composent. Nous pouvons distinguer deux types d’objectif, ceux de petit angle de vue, celui-ci correspond généralement à un objectif de longue focale et ceux de grand angle de vue, qui peuvent atteindre jusqu’à 180˚ dans la diagonale. Dans cette dernière catégorie, il existe des objectifs de type Fisheye (figure I.4 gauche). FIGURE I.4. Une camera avec objectif de type Fisheye à gauche et photo du ciel prise avec la caméra à droite L’intérêt premier de ces caméras est leur grand angle de champ, cependant, celui-ci cause une distorsion de l’image. La figure I.4 de droite montre une photo prise par la caméra Fisheye appartenant au LEOST, c’est une vue du ciel qui présente des distorsions (le centre est grossi par rapport aux cô- tés de l’image). L’utilisation de ce type de caméra implique donc de mettre en place des traitements particulier afin de réduire ces effets de champ. Dans le contexte routier, la plupart des algorithmes de détection visent à trouver dans l’image un modèle d’objet connu, le plus souvent voiture ou piéton. Selon (Perrollaz, 2008), deux étapes sont nécessaires pour la détection. La première consiste à extraire des primitives pouvant appartenir à des obstacles (par exemple, utiliser les contours images des objets, utiliser les symétries des objets à suivre, les textures et les ombres, l’utilisation de capteur particulier comme les caméras infrarouges permettent de distinguer efficacement les sources de chaleur), et la deuxième cherche à vérifier que celles-ci correspondent effectivement aux modèles d’obstacles recherchés.8 Problématique, capteurs et architectures de traitement – Les systèmes stéréoscopiques sont généralement constitués de deux caméras identiques fixées sur un support rigide. Elles sont alignées, et ont leur objectif parallèle, pointant vers la même direction, sans pour autant converger. La figure I.5 de gauche montre un système stéréoscopique appartenant au LEOST. Il est composé de deux caméras positionnées sur un support rigide à une distance connue l’un de l’autre. Le système est tel que les deux caméras sont déclenchées au même instant. Ceci implique une synchronisation importante d’autant plus si le ou les objets à suivre sont mobiles. L’utilisation de ce genre de système permet d’obtenir des informations de profondeur de la scène. Il est également possible de faire de la vision stéréoscopique avec une unique caméra en utilisant deux instants successifs et la donnée temps, les traitements des images sont ensuite similaires. FIGURE I.5. Système stéréoscopique expérimental (LEOST) à gauche et image d’une scène prise par un système stéréoscopique et sa carte de disparité à droite La stéréovision permet d’obtenir une image 3D de la scène à partir des deux images prisent au même instant. Pour cela, il existe plusieurs techniques décrites dans (Perrollaz, 2008) que nous présentons rapidement : Les approches par appariement qui correspondent à la mise en correspondance des informations issues des différentes images du système stéréoscopique. Cette méthode correspond à l’algorithme de stereo matching qui cherche à définir les pixels en correspondance, c’est-à-dire, ceux formés par un seul point de l’objet observé sur chacune des images. Cela permet de construire une image ou carte de disparité, la segmentation de celle-ci permet de réaliser la détection des objets. La figure I.5 de droite, prise avec le matériel du LEOST, montre une scène prise sur autoroute à gauche, et à droite sa carte de disparité associée. La carte de disparité correspond à une image de profondeur, on l’interprète ainsi, lorsque les couleurs tendent vers le rouge foncé, cela signifie que l’on est proche du véhicule porteur, à l’inverse lorsque les couleurs tendent vers le bleu foncé, cela signifie que l’on est loin du véhicule porteur. Les approches par rectification homographique qui consistent à appliquer une transformation homographique à l’une des images, ou une transformation perspective inverse aux deux, pour que l’apparence de la route soit semblable dans les deux images. Les pixels n’appartenant pas au plan de la route sont alors extraits par la différence entre les deux images, associés à un seuillage. Ces pixels sont alors segmentés et correspondent aux objets. Les systèmes de vision par caméra sont intéressants car ils permettent d’obtenir des informations sur une distance pouvant atteindre les 90 mètres. En dépit de leurs hautes performances en vision de la scène, on distingue quatre types de contraintes relatives à l’information transmises par une caméra : – les problèmes de synchronisation des différentes caméras entre elles, – les temps de transfert, – les temps de traitement, – les problèmes de stockage. Les trois dernières sont consécutives à la quantité d’information à traiter. En effet, la quantité d’information contenue dans une image est importante (2048x1944 pixels) suivant la résolution de l’objectif, le temps de transfert, le temps de traitement et les problèmes de stockage d’une image dépendent de la quantité d’information qu’elle contient. Il est possible de réduire cette quantité d’information en réduisant la taille de l’imageCapteurs et architectures 9 cependant, cette manipulation implique une perte de précision qui, si elle est trop prononcée, implique une perte de précision au niveau des traitements. Une autre possibilité pour "réduire" la quantité d’information à traiter est de choisir de ne pas traiter toutes les images en provenance de la caméra. Cela permet de stocker une quantité d’information moins importante mais également de réduire le coût de traitement. I.2.1.2 Radar Le radar est un système utilisant les ondes radio afin de détecter la présence, la position et la vitesse d’objets. Pour cela, il émet une onde produite par un oscillateur radio. C’est la réflexion de cette onde sur un objet qui sera analysée à son retour. Le temps de vol aller et retour mesuré permet de localiser l’objet détecté. Il existe différentes façons d’émettre ces ondes. Les plus utilisées sont : – les radars à impulsions, où le radar émet périodiquement une impulsion et attend son retour. Le temps de vol aller et retour de l’onde entre l’antenne et la cible est alors mesuré. – les radars à émission continue qui émettent continuellement à partir d’une antenne et reçoivent à l’aide d’une seconde. L’analyse du signal réfléchi offre la possibilité de localiser et d’identifier l’objet responsable de la ré- flexion, ainsi que le calcul de sa vitesse de déplacement grâce à l’effet Doppler (dans le cas des radars cohérents). Ainsi, le radar peut détecter des objets ayant une large gamme de propriétés réflectives alors que les autres types de signaux, tels que le son ou la lumière visible revenant de ces objets, seraient trop faibles pour être détectés. De plus, les ondes radio peuvent se propager avec une faible atténuation à travers l’air et divers obstacles tels les nuages, le brouillard ou la fumée, qui absorbent rapidement un signal lumineux. Cela rend possible la détection et le pistage dans des conditions qui paralysent les autres technologies. Dans le domaine automobile, citons à titre d’exemple les travaux de Bank (2007) qui introduisent un algorithme de traitement du signal Radar pour le développement d’une fonction d’alerte de collision latéral. Pour cela, ils utilisent un capteur radar SRR (figure I.6) de fréquence 24,125GHz pour la détection d’objets de 0,2m à 30m avec une résolution en distance de 0,15m. Ils utilisent un filtre de Kalman pour réaliser le suivi multicapteur, multicible. Pour appliquer ce filtre, un modèle de vitesse constante est choisi. Enfin, l’approche globale du plus proche voisin est utilisée pour associer les nouveaux objets avec des pistes existantes. FIGURE I.6. Image d’un radar SRR extraite de (Bank, 2007) Skutek et al. (2003) mettent en place un système anticollision pour voiture, fonctionnant sous toutes les conditions météorologiques. Il est basé sur quatre radars courte portée de 24GHz et un système de traitement du signal associé. Ce dernier fournit l’information sur une situation de collision potentielle. Le système est décrit en quatre étapes, d’abord, les mesures passent dans un filtre d’entrée qui crée un masque et filtre la distance entre objet et radar. Ensuite, la vitesse relative des objets est estimée. Puis, les auteurs estiment les distances critiques entre deux véhicules et enfin, ils classifient les objets par rapport à cette distance. Perrollaz (2008) montre que le radar présente quelques limites pour les applications automobiles. En premier lieu, l’angle de vue du capteur est faible, environ 10 degrés pour un radar longue portée (∼ 120m) et10 Problématique, capteurs et architectures de traitement 70 degrés pour les radars courtes portées (∼ 30m). Cette faible résolution angulaire ne permet pas toujours de distinguer deux objets situés côte à côte par exemple. En second lieu, la présence de nombreux échos parasites dans la chaussée ou sur les bords de la route provoque un grand nombre de fausses détections. Pour limiter ces fausses détections, les objets situés en milieu de voie et immobiles par rapport au véhicule porteur sont filtrés, par comparaison de leur vitesse avec celle du porteur. Enfin, ce type de capteur ne permet pas la détection fiable des piétons car ceux-ci créent peu d’échos. I.2.1.3 Lidar Un télémètre laser permet de réaliser une mesure précise entre le capteur et un obstacle. Ce système de mesure, également appelé LIDAR (LIght Detection And Ranging) est conçu à l’aide de lasers. C’est un système utilisant la lumière afin d’estimer la distance d’un objet. Pour cela, il émet une onde lumineuse, la distance à un objet ou à une surface est donnée par le délai entre le temps d’émission de l’impulsion et le temps de détection du signal réfléchi. Contrairement au radar, le lidar permet de détecter tout type d’objets (aussi bien véhicule que piéton) à partir du moment où celui-ci renvoie tout ou une partie de la lumière incidente. Les mesures transmises par le lidar correspondent à une distance et un angle. À la différence du radar, le capteur lidar émet une onde très focalisée et non sur un cône d’ouverture angulaire donnée. Dans le domaine autoroutier, ce sont les capteurs télémétriques à balayage qui sont géné- ralement utilisés car ils permettent de balayer la scène par envoi de multiple rayons. L’orientation du rayon est permise par un miroir rotatif, commandé par un moteur électrique. Cette technique permet d’orienter le rayon dans un grand nombre de direction, ainsi un angle de vue large peut être étudié et ce avec une grande précision angulaire. En raison de sa directivité plus grande, le capteur lidar est plus sensible aux mouvements du véhicule que les autres capteurs. Le tangage de celui-ci peut provoquer une désorientation du rayon capteur et ainsi toucher la route émettant un écho factice. L’utilisation d’un capteur télémétrique multicouche permet de remédier partiellement à cette difficulté en donnant une vision 3D de la scène. Ce type de capteur émet plusieurs niveaux de tir comme le montre la figure I.7. Des traitements et un paramétrage supplémentaire sont donc indispensables. FIGURE I.7. Principe du lidar multicouche Takagi et al. (2006) présentent un algorithme de reconnaissance de l’environnement routier à partir d’un capteur lidar. Pour cela, ils utilisent un capteur DENSO multiplan à trois nappes pour détecter les véhicules et les signalisations horizontales jusqu’à 120m. Dans cet article, la fréquence est de 10Hz, l’élévation du rayon est de (−4˚, 4˚) et son azimut est de (−18˚, 18˚) avec une résolution angulaire de 0,08˚. Les auteurs utilisent un algorithme de détection en trois étapes, reconnaissance des objets, reconnaissance des signalisations horizontales et reconnaissance de l’environnement routier par l’intégration des deux premières étapes. Nous choisissons de nous focaliser sur le capteur lidar pour résoudre notre problème de détection et de suivi d’obstacle. En effet, ce capteur permet d’obtenir une grande quantité d’informations concernant laCapteurs et architectures 11 scène, et ceci avec une faible demande en mémoire. Ceci a notamment un impact sur les temps de transfert et les problèmes de stockage. La capacité du capteur à détecter tous types d’objets et cela sur une distance pouvant atteindre 120m sur une ouverture angulaire de (−18˚, 18˚) (exemple de (Takagi et al., 2006)) correspond à nos besoins. Un dernier aspect est la capacité des fournisseurs à gérer les difficultés liées au domaine automobile, avec notamment la mise en place d’un balayage horizontal et d’un balayage vertical pour pallier les difficultés liées au contexte routier (déplacement sur la route, tangage). La section I.3 concernant le lidar réalise une étude plus poussée des capteurs lidar avec notamment un tour d’horizon des différents capteurs du marché. I.2.2 Architectures de traitement de données Dans cette section, nous cherchons à caractériser les différentes architectures de traitement des systèmes de détection et de suivi d’obstacles. Ces systèmes sont représentés par une suite de tâches liées, qui effectuées les unes après les autres, permettent d’obtenir l’objet suivi ou à suivre à partir des données reçues en entrée du système. L’architecture de traitement d’un problème de détection et de suivi d’objets varie suivant plusieurs points : le nombre de capteurs utilisés, l’utilisation d’une tâche de fusion de données, le nombre d’objets à suivre. Nous présentons ici les architectures permettant la détection et le suivi d’un ou plusieurs objets à partir d’un ou plusieurs capteurs. Les cas multicapteur et monocapteur sont étudiés séparément. I.2.2.1 Architectures multicapteur classiques La présence de plusieurs capteurs implique la présence d’une étape de fusion de données. Dans les livres (Waltz et Llinas, 1990; Hall, 1992; Hall et Llinas, 1997), les auteurs présentent trois types distincts d’architecture basés sur la fusion des données que nous présentons ci-après : – architecture de fusion centralisée (figure I.8). Dans cette approche, les données brutes de chaque capteur sont transmises à une unité de traitement composée successivement d’une étape de fusion centralisé qui réalise l’association des données, suivie par une étape de corrélation, une étape de filtrage qui réalise l’estimation dynamique et enfin une étape de classification des objets ciblés. Ce type d’architecture permet d’obtenir à la fois une estimation du vecteur d’état de chaque objet mais également une classification des objets suivis. FIGURE I.8. Architecture de fusion centralisée extraite de (Waltz et Llinas, 1990) – architecture de fusion autonome (figure I.9). Les données brutes de chaque capteur sont localement prétraitées pour générer un vecteur d’état et classifier les objets. Les informations résultantes sont transmises à l’unité de traitement, identique à celle de l’architecture de fusion centralisée, pour le calcul de l’estimation d’état.12 Problématique, capteurs et architectures de traitement FIGURE I.9. Architecture de fusion autonome extraite de (Waltz et Llinas, 1990) – architecture de fusion hybride (figure I.10). Cette architecture est une combinaison des architectures centralisées et autonomes. On a donc deux étapes distinctes. La première partie de l’architecture est identique à celle de fusion autonome. Ensuite, une deuxième partie récupère les informations brutes en sortie des capteurs et les transmet à une unité centrale qui effectue la détection suivant le même schéma que l’architecture de fusion centralisée. Les informations résultantes sont transmises à l’unité de filtrage qui calcule l’estimation des vecteurs d’états et classe les objets. FIGURE I.10. Architecture de fusion hybride extraite de (Waltz et Llinas, 1990) Dans ces trois cas, on utilise les données brutes de chacun des capteurs. Il existe également une autre alternative qui ajoute une étape de prétraitement local associé à chaque capteur (en pointillés sur les figures). Cette étape permet d’extraire des données brutes les vecteurs caractéristiques pour chaque objet détecté. C’est cette étape de prétraitement qui diffère suivant le capteur utilisé. Dans ce type d’architecture, l’abondance de capteurs peut vite devenir problématique et ce pour diffé- rentes raisons. L’utilisation de capteurs de types différents implique des prétraitements de données locaux afin de fusionner des informations de même type, ce qui peut augmenter le coût de calcul. Par contre, cette multiplicité des informations est un avantage majeur qui permet la redondance des informations. Ainsi, un objet peut être vu par plusieurs capteurs. Cela a pour avantage de limiter les fausses alarmes, non détection et autres. Ceci implique également que la défaillance d’un capteur peut être compensé par les autres ce qui n’est pas le cas dans les architectures monocapteurs. Quand plusieurs capteurs coexistent, un autre souci est la synchronisation des données. En effet, il est possible que les informations émises par les différents capteurs ne proviennent pas des mêmes instants rendant nécessaire l’utilisation d’une étape de synchronisation.Capteurs et architectures 13 I.2.2.2 Exemple d’une architecture autonome dans le domaine automobile Le projet européen CARSENSE (Wahl, 2002) a conçu un démonstrateur de fusion de données multicapteurs pour détecter les objets devant le véhicule porteur. Son architecture comporte (figure I.11) deux capteurs extéroceptifs autonomes dotés de capacité locale de suivi (laser scanner) et de traitement d’images (unité vidéo) et des capteurs proprioceptifs fournissant au système de fusion de données et aux capteurs extéroceptifs les informations d’angle de braquage, de vitesse, de vitesse de lacet et d’accélération latérale du véhicule. Dans cette architecture, l’unité de fusion est en charge de la gestion centralisée du bus capteur auquel sont connectés les unités vidéo et laser scanner. Elle transfère périodiquement du bus véhicule au bus capteur, les informations proprioceptives nécessaires aux capteurs extéroceptifs. Elle réalise également la fusion des informations du laser scanner et de l’unité vidéo sur un matériel spécifiquement conçu pour accueillir les algorithmes de fusion de données. FIGURE I.11. Architecture du système de fusion de données du projet CARSENSE extraite de Wahl (2002) I.2.2.3 Architecture monocapteur pour lidar Dans le cas d’une détection et d’un suivi monocapteur, l’architecture de traitement est simplifiée quant au nombre de capteurs mais reste similaire au niveau des étapes de traitement. Prenons l’exemple monocapteur (figure I.12) du projet CARSENCE (Kiehn et al., 2002). L’objectif est le suivi des objets, via des informations de haut niveau, obtenues à partir d’un laser à balayage. Les données brutes sont segmentées puis transmises à un module d’affectation, correspondant à la fusion. Celui-ci associe les données provenant de la segmentation à celles de la prédiction des objets (de l’instant précédent). Les informations résultantes sont transmises à un module de classification des objets puis à un module de mise à jour, il en ressort l’objet suivi.14 Problématique, capteurs et architectures de traitement FIGURE I.12. Architecture de traitement monocapteur lidar extraite de (Kiehn et al., 2002) Si maintenant nous observons le choix d’architecture monocapteur de Jida (2008) présenté en figure I.13. On remarque que l’architecture est simplifiée au niveau des capteurs, a contrario elle se complique fortement au niveau de l’unité de traitement. Dans cette thèse (Jida, 2008), l’auteur cherche à estimer les paramètres dynamiques des objets observés sur une scène afin de mettre en place un système d’aide au conducteur. Pour cela, il part du constat que la nature du suivi multi-objets implique d’associer, efficacement et à chaque instant, les mesures disponibles à chaque objet présent dans la scène pour permettre une estimation de leurs paramètres dynamiques. Dans un premier temps, les paramètres prédéfinis des objets sont extraits par trois phases : – une phase d’acquisition des signaux qui utilise un capteur rotatif laser, – une phase de prétraitement qui met en forme les signaux sous forme de mesures, – une phase de détection des objets qui identifie des groupes de mesures correspondant à des objets à suivre selon différents critères et connaissances, a priori, de la forme des obstacles. Dans un second temps, il met en relation les objets détectés avec les données précédentes. Cela correspond à l’étape d’association. Il s’en suit une étape d’estimation, de suivi et enfin de prédiction correspondant notamment aux différentes phases d’un filtre prédictif de Kalman et à la gestion du suivi des objets dans le temps. Des pistes sont créées (une piste est un ensemble de variables caractérisant les objets suivis), d’autres sont maintenues et mises à jour en fonction des apparitions et disparitions des objets détectés devant le véhicule, enfin certaines sont détruites lorsqu’aucune nouvelle observation ne leur a été affectée depuis un temps prédéfini.Le télémètre laser à balayage : capteur lidar 15 FIGURE I.13. Architecture de traitement monocapteur lidar extraite de Jida (2008) I.3 Le télémètre laser à balayage : capteur lidar I.3.1 Principe du télémètre laser à balayage La technologie laser est directive, elle permet d’envoyer un signal lumineux dans une direction donnée. Dans les systèmes embarqués, la directivité du signal lumineux a pour conséquence le décrochage régulier de l’obstacle suivi, qui entre et sort régulièrement de la ligne de tir. Pour pallier cette directivité, les concepteurs de capteur télémétrique ont, à partir des années 2000, augmenté l’ouverture angulaire horizontale des capteurs (Fuerstenberg et al., 2001c; Velodyne, 2013; Ogawa et Takagi, 2006). Ainsi le signal balaye la scène (figure I.14 haut) sur l’ouverture angulaire. Ce balayage est rendu possible par l’utilisation d’un prisme rotatif couvrant 360˚. La résolution angulaire varie en général de 0,25˚ à 1˚ et dépend de la fréquence du balayage. La portée du laser dépend de la taille et de la réflectivité de l’objet. Par exemple, pour un objet de forte réflectivité, la portée peut atteindre 250m à l’inverse pour un objet peu réflectif (5% de réflectivité) la portée atteint les 40m (Fuerstenberg et Willhoeft, 2001a,b; Fuerstenberg et al., 2001c). Ces capteurs sont également sensibles au roulis et au tangage du véhicule, dans ce cas, le signal lumineux change d’inclinaison, cela a pour conséquence le décrochage de l’obstacle suivi, menant comme précédemment à des pertes du signal. Dans les années 2000−2002 la société IBEO a conçu, à partir d’une première expérience (capteur laser scanner IBEO LD), une nouvelle génération de capteurs capables de mesurer les distances sur différents plans verticaux de balayage (IBEO LDML). Ceci correspond au balayage vertical (figure I.14 bas) de la scène et permet d’être moins sensible au tangage du véhicule (Fuerstenberg et al., 2002a,b, 2003). Le capteur balaye ainsi la scène suivant deux plans, un vertical et un horizontal. FIGURE I.14. Principe du balayage horizontal (en haut) et vertical (en bas) extrait de (Besesty, 1999)16 Problématique, capteurs et architectures de traitement Dans notre contexte d’étude, c’est la technologie laser à balayage qui est donc utilisée. Le laser émet une onde lumineuse par son émetteur laser et la reçoit via son récepteur comme le montre la figure I.15. La distance à la cible étant proportionnelle à l’intervalle de temps entre transmission et réception de l’impulsion, c’est le temps de vol aller et retour de l’émetteur au récepteur en passant par la cible qui donne la distance à l’objet. FIGURE I.15. Schéma de fonctionnement du télémètre laser à balayage extrait de (Besesty, 1999) Selon (Besesty, 1999), il existe deux méthodes pour mesurer les temps de parcours : – un faisceau lumineux est modulé, dans ce cas, c’est la notion de retard de phase qui est importante pour la mesure. Cette méthode est le plus souvent employé pour mesurer des distances courtes, – une impulsion optique courte est générée, le système mesure alors le temps mis par la lumière pour revenir au récepteur. Cette méthode est la plus souvent utilisée pour déterminer des grandes distances. La distance correspond alors à : D = c 2 (Tstop −Tstart) (I.1) où D est la distance du capteur à la cible, c est la vitesse de la lumière, Tstart est le temps de départ du signal et Tstop celui de fin d’émission (comme le montre la figure I.16). FIGURE I.16. Principe de mesure du temps de vol d’une onde émise par le télémètre laser à balayage extrait de (Besesty, 1999)Le télémètre laser à balayage : capteur lidar 17 I.3.2 Exemple de mesures lidar issue de capteur monoplan et multiplan Le capteur lidar est généralement muni d’un système interne de traitement qui permet de transformer le signal présenté ci-dessus en échos (ρ, θ). Ce sont ces échos qui sont délivrés par le lidar et que nous étudions, c’est pourquoi nous les présentons, dans cette section. Les mesures télémétriques d’un lidar décrivent la scène par un ensemble de points, appelés impacts ou échos, correspondant à la scène qu’il balaye. Dans cette scène, les véhicules présents sont représentés par des ensembles d’impacts correspondant à la partie visible de leurs contours. Ces ensembles de points contiennent un nombre variable d’impacts suivant l’orientation et la distance de l’objet. Ils peuvent être séparés en segment contour du véhicule représentant un ou deux côtés du véhicule (Fuerstenberg et al., 2003). Les figures présentées ci-après sont issues d’une simulation, d’un capteur de type télémètre laser à balayage, avec le logiciel SiVIC (Livic, 2011). Le véhicule porteur du capteur est situé voie centrale. Les figures I.17 du bas présentent deux types de mesures, converties dans le repère cartésien. La première (à gauche) représente les mesures de la scène prises par un capteur monoplan et l’autre (à droite) celles prises par un capteur multiplan. La scène représentée par les deux figures est celle présentée en figure I.17 du haut où quatre véhicules, situés à des distances différentes, évoluent sur les trois voies de la route. Sur la figure I.17 de gauche, le capteur lidar monoplan visualise les données de la route sur une ouverture angulaire de 180˚ avec une résolution angulaire de 0,25˚. La portée du capteur est de 10m à 180m (les éléments considérés à l’infini sont à 180m). La fréquence d’échantillonnage est de 20Hz. Le capteur lidar multiplan (à droite) visualise les données de la scène avec les mêmes caractéristiques que le capteur monoplan. Les tirs capteurs sont effectués suivant une élévation de 0˚ en bleu, 0,4˚ en rouge, 0,8˚ en vert et 1,2˚ en cyan. Sur la figure I.18 de gauche, un agrandissement, du véhicule situé en bas à droite de la scène vue par le capteur lidar multiplan (figure I.17 à droite), permet de montrer les différents plans déterminant un objet. Ce véhicule est proche du véhicule porteur du capteur, l’élévation du tir permet de voir tous les plans, par contre pour le véhicule situé voie centrale, seuls les plans d’élévation 0˚ et 0,4˚ sont visibles (figure I.18 de droite ). Cette disparition des informations constitue la principale difficulté de l’étude de ces données capteurs multiplans.18 Problématique, capteurs et architectures de traitement −8 −6 −4 −2 0 2 4 6 8 0 20 40 60 80 100 120 140 160 180 x (m) y (m) scène monocouche −60 −50 −40 −30 −20 −10 0 10 20 30 0 20 40 60 80 100 120 140 160 180 x (m) y (m) scène multicouche FIGURE I.17. Image CCD de la scène et le balayage capteur associé vu par le lidar monoplan (en bas à gauche) et par le lidar multiplan (en bas à droite) 2 2.5 3 3.5 4 4.5 5 15 15.5 16 16.5 17 17.5 18 18.5 19 19.5 20 x (m) y (m) zoom véhicule voie de gauche bas de la scène multicouche −1.5 −1 −0.5 0 0.5 1 1.5 94 94.5 95 95.5 96 96.5 97 97.5 98 98.5 99 x (m) y (m) zoom véhicule voie centrale de la scène multicouche FIGURE I.18. Agrandissement de la représentation de la scène vue par le lidar multiplan (figure I.18 à gauche) sur le véhicule en bas de la voie droite (à gauche) et sur le véhicule voie centrale (à droite)Le télémètre laser à balayage : capteur lidar 19 I.3.3 Évolution des capteurs lidar Après avoir vu le fonctionnement des capteurs lidar, nous nous focalisons sur leur évolution, dans le domaine automobile, en décrivant quelques exemples de capteur. Bien que similaires dans leur fonctionnement, ils diffèrent par leurs caractéristiques et leurs évolutions. Différents fournisseurs réalisent et commercialisent des capteurs de type lidar, tel que DENSO, IBEO, SICK et Velodyne. Dans la littérature, beaucoup d’articles font références aux capteurs de la gamme IBEO. Par contre pour les fournisseurs DENSO, SICK et velodyne, peu d’articles y font référence et nous trouvons peu d’informations concernant les capteurs qu’ils réalisent. (com, 2014) donne tout de même une comparaison rapide des capteurs DENSO, SICK LD-MRS et Velodyne HDL-64E présentés en figure I.19 et tableau I.1. FIGURE I.19. Présentation des capteurs DENSO, SICK LD-MRS et Velodyne HDL-64E (de gauche à droite) extrait de (com, 2014) DENSO SICK LD-MRS Velodyne HDL-64E Distance 120m > 50m pour 10% de réflectivité 50m pour 10% de réflectivité, 120m pour 80% de réflectivité Précision en distance < 10m < 100mm < 20mm Angle d’ouverture horizontale 36˚ 110˚ (2 plans), 85˚ (4 plans) 360˚ Angle d’ouverture verticale 8˚ 1,6˚ (2 plans) 3,2˚ (4 plans) 26,8˚ Fréquence de balayage 10Hz 12,5Hz, 50Hz 5−15Hz Résolution angulaire 0,08˚ 0,25˚ (à 12,5Hz) et 0,5˚ (à 50Hz) 0,09˚ Nombre de plan 6 2 ou 4 64 Tableau I.1. Comparaison des capteurs DENSO, SICK LD-MRS et Velodyne HDL-64E extrait de (com, 2014) Nous choisissons d’étudier les capteurs de la gamme IBEO et leurs évolutions. La société IBEO , créée en 1998 et située à Hambourg en Allemagne devient « IBEO Automobile Sensor » en devenant filiale de la société SICK. Son activité est concentrée sur les lasers à balayage pour l’automobile.20 Problématique, capteurs et architectures de traitement I.3.3.1 Capteur IBEO LD Automotive Le premier capteur réalisé et commercialisé par IBEO, est un capteur laser à balayage « IBEO LD Automotive » à forte résolution. Le système mis en place est généralement muni d’un capteur et d’un ordinateur pour le traitement interne des données. Le champ de vision de ce capteur est ouvert à 270˚, il peut détecter un véhicule à partir de 3m jusqu’à 250m suivant la réflectivité de l’objet (40m pour un objet à 5% de réflectivité) avec une précision de ±5cm. Sa résolution varie de 0,25˚ à 1˚ pour une fréquence allant de 10Hz à 40Hz (Fuerstenberg et Willhoeft, 2001a,b; Fuerstenberg et al., 2001c). Fuerstenberg et Willhoeft (2001a) partent du constat que la classification des objets détectés est importante pour estimer la dangerosité des obstacles. Ils constatent, par ailleurs, qu’il est intéressant d’obtenir des informations sur le risque potentiel des objets environnants afin de protéger les piétons en cas de collision. Les auteurs présentent, dans cet article, le laser « IBEO LD Automotive » et leurs algorithmes de détection, suivi et classification. Les mesures brutes, en sortie du capteur, sont divisées en groupes représentant un même objet. Un filtre de Kalman est utilisé pour estimer la vitesse longitudinale et latérale de l’objet. Enfin, les objets sont classés suivant les données. Ce capteur a également été utilisé dans le projet CHAMELEON (« Pre-crash application all around the vehicle »). Ce projet portait sur le développement d’une plateforme sensorielle de détection de collision imminente, autour du véhicule et pour tout type de scénario (Fuerstenberg et al., 2001d; Chameleon, 2013). Dans ce projet, le capteur « IBEO LD Automotive » a été utilisé pour la détection, le suivi et la classification des objets (voiture, piéton, ...). I.3.3.2 Capteur IBEO LD-ML (Ladar Digital MultiLayer) (Fuerstenberg et al., 2002a,b, 2003) partent du constat que le capteur « IBEO LD Automotive » est sensible aux mouvements du véhicule, perturbant ainsi la détection. La société IBEO présentent alors une nouvelle génération du capteur IBEO (décrit dans ces articles) permettant de pallier ce problème : le capteur « IBEO LD-ML » (Ladar Digital MultiLayer). Celui-ci possède des caractéristiques similaires à celle du capteur « IBEO LD Automotive ». Elles sont présentées en figure I.20. FIGURE I.20. Le capteur IBEO LD-ML (à gauche) et ses caractéristiques (à droite) Ce capteur a la capacité de détecter deux distances avec un unique tir laser. Cela se produit si le faisceau frappe une cible à faible réflectivité et transmission élevée ou des cibles de petites tailles tels que le verre ou les gouttes de pluie. Dans ce cas, une partie du faisceau est déviée vers le capteur, déclenchant la première mesure. Par la suite, le faisceau restant frappe une seconde cible, et l’écho de cette cible déclenche la seconde mesure. Ainsi pour un angle donné, le capteur peut recevoir jusqu’à huit valeurs de distance en prenant en compte le balayage vertical. Avec un capteur monocible, la réception du faisceau dévié arrêterait la mesure, et l’objet resterait caché. Concrètement, le capteur « IBEO LD-ML » attend la pulsation du second écho pourLe télémètre laser à balayage : capteur lidar 21 générer la mesure d’un objet. À moins que trop de lumière soit absorbée par la distorsion, ceci permet au laser à balayage de voir à travers la pluie (Fuerstenberg et al., 2002a,b). Le capteur laser « IBEO LD-ML » a été développé pour supporter une large gamme d’application automobile, incluant le freinage d’urgence, le « Stop and Go », la reconnaissance de piéton et le « Pre-Crash » (Fuerstenberg et al., 2002a). Une application de ce type de capteur est donnée dans (Gidel et al., 2008). Les auteurs de cet article présentent une méthode de détection, d’identification et de suivi de piétons à partir d’un unique capteur laser quatre plans. Pour cela, les points du balayage sont regroupés en différentes classes géométriques, dont le but est de filtrer le fond de l’image (murs, voiture, ...). Les auteurs utilisent ensuite une méthode exploitant la technique de fenêtrage de Parzen afin d’isoler les piétons. Enfin, ils utilisent un filtre à particules pour caractériser la trajectoire du piéton. I.3.3.3 Capteur ALASCA (Automotive Laser SCAnner) Le successeur du capteur « IBEO LD-ML » est l’ALASCA (Automotive Laser SCAnner). La version suivante est l’ALASCA XT. Ces deux capteurs IBEO comptent jusqu’à quatre réflexions par impulsion laser contrairement au capteur « IBEO LD-ML » qui n’en comptait que deux. Ces capteurs ont la capacité de dé- terminer si la mesure reçue provient d’un signal retourné par un réflecteur (type plaque d’immatriculation, ...) ou d’une autre surface à moindre pouvoir réfléchissant. En effet, la réflexion totale ou diffuse d’un objet crée des différences dans le rayonnement de l’impulsion de l’écho. Ces disparités se situent au niveau du récepteur du capteur et peuvent être mesurées grâce au rayonnement qui provient de la distance et de l’angle d’incidence de la cible. Cette principale évolution permet d’améliorer le pistage des objets et leur classification (Fuerstenberg et al., 2004). FIGURE I.21. Le capteur IBEO ALASCA XT (à gauche) et ses caractéristiques (à droite) Ce capteur est notamment utilisé dans le projet INTERSAFE qui a débuté en 2004 et s’est terminé en 2007. Il portait sur la création d’une approche Européenne pour augmenter la sécurité aux intersections (Rössler et Fürstenberg, 2013). L’objectif de celui-ci était d’augmenter la sécurité et réduire (à long terme, éliminer) les collisions fatales aux intersections (Fuerstenberg, 2005a,b). La méthode est basée sur deux approches parallèles. La première utilise un capteur et les infrastructures de communication de véhicule. La communication est bidirectionnelle entre le véhicule et les infrastructures. La seconde utilise un simulateur de conduite qui analyse les situations potentiellement dangereuses.22 Problématique, capteurs et architectures de traitement I.4 Conclusion De nos jours, la sécurité routière est de plus en plus importante. Limiter les risques d’accidents est un souci permanent tant chez les constructeurs automobiles que pour les nations. Aujourd’hui, les recherches sont notamment axées sur les systèmes d’aide à la conduite permettant à la fois de prédire une situation potentiellement dangereuse et d’aider le conducteur à en limiter les conséquences, voire les neutraliser. Ce chapitre a notamment permis de mettre en évidence les contraintes qu’implique la mise en œuvre d’un système de détection et de suivi d’obstacle mobile sur route. Le type d’application mis en œuvre est fonction de l’environnement dans lequel nous nous trouvons, mais également du capteur choisi et des outils. Nous avons vu que le choix d’un système monocapteur ou multicapteur est complexe et est fortement dé- pendant du résultat recherché. Dans notre cas, nous cherchons à mettre en place un système proche du temps réel. L’étude a montré que la multiplicité de capteur peut vite devenir lourde à gérer au niveau mémoire, temps de transfert des données et temps de traitement. Compte tenu de ces difficultés, nous choisissons de mettre en place un système monocapteur plus proche de nos besoins, limitant les coûts de traitement. Une rapide étude des capteurs automobiles a permis de choisir le capteur lidar comme notre source de données. En effet, sa capacité à détecter tous types d’objets et ce sur une distance pouvant atteindre 120m pour un balayage de la scène pouvant atteindre 160˚ répond à nos besoins. De plus, ce capteur permet d’obtenir une grande quantité d’informations concernant la scène et notamment les distances capteur/objet sans nécessité de traitement. Cependant, une difficulté de ce type de mesure est leur nature spatialement distribué dans le cas monoplan. Dans le cas multiplan, la difficulté réside dans la disparition d’informations (due à une élévation du tir trop élevé) sur certain plan. La section suivante est dédiée à l’état de l’art des techniques de détection et de suivi d’objets multiples à partir de données de type lidar.Chapitre II Problème de détection et suivi d’objets multiples II.1 Architecture fonctionnelle classique du problème de détection et de suivi d’obstacles Les mesures télémétriques d’un lidar décrivent les véhicules par un ensemble de points correspondant à la partie visible de leurs contours. Une difficulté de ce type de données est leur nature : l’ensemble de mesures décrivant un véhicule est spatialement corrélé. C’est pourquoi une étape préliminaire d’agrégation avant le processus de suivi est généralement nécessaire, comme l’illustre la figure II.1. FIGURE II.1. Étapes classiques d’un algorithme de détection et de suivi Ainsi, dans un premier temps, les mesures brutes, en sortie du capteur physique, sont utilisées pour détecter les objets présents dans le champ de vision du capteur. Un module de détection prend en compte des attributs caractéristiques du capteur et de son environnement pour extraire, des mesures du capteur, les paramètres d’objets d’intérêt (Nashashibi et Bargetin, 2008). Dans un deuxième temps, une étape d’association temporelle associe les objets en sortie du module de détection à ceux en sortie du module de suivi en vue de mettre à jour le module d’estimation et de suivi. Le module d’association temporelle crée et maintient une liste des objets en cours de suivi. Ceci lui permet de mettre en relation les objets qui viennent d’être détectés avec ceux de sa liste. Il associe des objets détectés aux estimés d’objets présents dans la liste et en identifie d’autres comme des objets venant d’apparaître dans le champ de vision. Enfin, il élimine, de cette liste, les objets identifiés comme étant disparus du champ de vision du capteur. Plusieurs méthodes ont été proposées pour réaliser cette étape d’association. On peut citer, parmi les plus populaires, les approches de suivi à hypothèses multiples, Multiple Hypothesis Tracking (MHT), et celles d’association probabiliste conjointe de données ou Joint Probabilistic Data Association (JPDA). Les méthodes MHT envisagent, pour un horizon temporel donné, toutes les associations possibles entre les mesures et les pistes (Reid, 1979). JPDA modélise le problème d’association de manière probabiliste (Bar-Shalom et Fortmann, 1988; Bank, 2007). 2324 Problème de détection et suivi d’objets multiples Dans un troisième temps, une étape de filtrage rafraîchit l’estimation des paramètres des objets suivis à partir des informations d’associations de la liste d’objets, précédemment mises à jours. Elle initie celle des objets nouvellement détectés à partir des informations de création. Différents filtres peuvent être appliqués selon la nature de la modélisation du système. Si le système est décrit par un modèle linéaire ou qui a été rendu linéaire, un filtre de Kalman (Bank, 2007; Sato et al., 2010) ou un filtre de Kalman étendu (Tango et al., 2008) sera choisi. S’il est décrit par un modèle non-linéaire, un filtre de Kalman sans parfum (Julier et Uhlmann, 2004; Richter et al., 2008), une approche à base de grille (Homm et al., 2010) ou encore une approche de Monte Carlo séquentielle sera utilisé. Les approches de Monte Carlo séquentielles, également connues sous le nom de filtrage particulaire (Doucet et al., 2000a), ont également été plus récemment mises en œuvre dans des algorithmes de suivi pour des applications routières (Idler et al., 2006; Thuy et Leon, 2009). Lorsque le système de détection et de suivi comporte plusieurs capteurs de détection d’objets, une étape de fusion peut être ajoutée entre les capteurs physiques et le module de détection (fusion signal), après les modules de détection des capteurs physiques (fusion d’objets), ou encore après les modules d’estimation et de suivi des capteurs logiques (fusion de pistes) (Hall, 1992; Liggins et al., 1997; Herpel et al., 2008; Nashashibi et Bargetin, 2008; Baig et al., 2011). II.2 Détection dans les données télémétriques Les lidars automobiles délivrent un ensemble de mesures (ρ,θ) à chaque nouvelle rotation de leur laser (balayage capteur t). Ces mesures sont séparées d’une distance angulaire fixe ∆θ (le pas de tir). Le capteur télémétrique calcule chaque distance ρθ (distance délivrée à l’angle θ) en divisant la vitesse de la lumière par la mesure du temps qui s’est écoulée entre la date d’émission du signal laser et celle de la réception du signal réfléchi correspondant (temps de propagation). Chaque ensemble de mesures délivré est un agglomérat d’échos pouvant être représentatif de différents objets détectés, de pertes de signal et de non détection. Détecter un objet parmi ces mesures nécessitent donc de les regrouper en une information objet. Pour cela, généralement on distingue trois étapes (Jida, 2008) : – le partitionnement des données d’un balayage en groupes de mesures (clustering) ; – la segmentation de chacune des partitions trouvées, afin d’en extraire des contours d’objets ; – l’identification et la classification des objets issus de l’étape de segmentation. Nous considérons, dans la suite de ce document, que chaque tour de rotation du lidar correspond à notre fréquence d’échantillonnage, ∆t, d’une image capteur. t est l’indice ou numéro du balayage (tour de rotation), par conséquent, t.∆t est la date du balayage. Nous utilisons, aussi, les expressions des mesures d’un même échantillon suivantes : – Zt l’ensemble des mesures d’un balayage t ; – Zt = {zθ ;θ ∈ {θmin,θmin +∆θ,...,θmax}} ; – Pt l’ensemble des partitions de Zt ; – Nmax le nombre maximal d’objets d’une image à t d’au moins un point – Pt = n P(n);n ∈ [0,Nmax],Nmax ≤ θmax−θmin ∆θ +1,P(0) = ∅ o ; – P(n) =  zθ ;θ ∈  θa,θa +∆θ,...,θa+f , f le nombre de points de P(n) et P(1) T ...T P(n) = ∅ ; – zθ=(ρθ ,θ) lorsque la mesure est exprimée en coordonnées polaires ; – zθ=(xθ ,yθ ) lorsqu’elle l’est en coordonnées cartésiennes ; – z − θ indique la mesure de l’impact à l’angle de tir précédent (θ − = θ −∆θ) ; – z + θ indique celle de l’impact à l’angle de tir suivant (θ + = θ +∆θ) ; – ∆θ est la résolution angulaire du lidar, c’est-à-dire le pas de tir durant le balayage. D’autre part, le passage du repère polaire au repère cartésien se fait classiquement selon le systèmeDétection dans les données télémétriques 25 d’équations suivant :  xθ = ρθ cosθ yθ = ρθ sinθ (II.1) II.2.1 Partitionnement de données (clustering) L’étape de partitionnement de données regroupe, au sein de partitions, les mesures qui partagent un caractère commun. Dans le cas d’un échantillon de mesures lidar, l’étape de partitionnement consiste à regrouper les mesures correspondant à un même objet. Les algorithmes de partitionnement reposent alors sur la comparaison d’un critère de distance avec un critère seuil. Jida (2008) part du constat que les données lidar sont naturellement ordonnées, lors du balayage de la scène, pour éliminer un certain nombre d’algorithmes tels que le K-Means basés sur le calcul de centroïdes selon un processus itératif. Il s’intéresse alors aux approches de partitionnement reposant sur la comparaison de critère de distance entre deux mesures successives. Nous nous plaçons dans cette continuité et reprenons ci-après la description de la méthode générale de l’algorithme de partitionnement, puis nous nous intéressons aux déclinaisons adaptatives de Dietmayer et al. (2001); Santos et al. (2003); Borges et Aldon (2004). II.2.1.1 Algorithme de partitionnement L’algorithme de partitionnement consiste en la comparaison, mesure après mesure d’un balayage, de la distance d(zθ− ,zθ ) entre deux mesures successives à une valeur de distance seuil. Si cette distance d(zθ− ,zθ ) est inférieure à la valeur seuil, alors la mesure zθ au pas de tir courant est affectée à la même partition que la précédente zθ− . Si ce n’est pas le cas, elle est affectée à un nouveau groupe. La distance la plus utilisée est la distance euclidienne définie comme suit : – d(zθ− ,zθ ) = q ρ 2 θ− +ρ 2 θ −2(ρθ− )(ρθ ) cos(∆θ) lorsqu’elle est déclinée en coordonnées polaires ; – d(zθ− ,zθ ) = p (xθ− −xθ ) 2 + (yθ− −yθ ) 2 lorsqu’elle l’est en coordonnées cartésiennes. La détermination de la valeur du seuil est la principale difficulté des algorithmes de partitionnement. Le seuil peut être fixe (algorithme non adaptatif) ou calculé à chaque itération (algorithme adaptatif). Une valeur de seuil fixe ne tient cependant pas compte des grandes différences de distances qui peuvent être calculées entre deux points d’un même objet selon l’orientation et la distance au lidar de cet objet. Ceci est illustré en figure II.2. Ainsi, on préfèrera l’utilisation d’une distance seuil adaptative, qui est calculée à chaque comparaison entre deux mesures zθ− et zθ consécutives. Dietmayer et al. (2001); Santos et al. (2003) et Borges et Aldon (2004) proposent différents seuils adaptatifs que nous présentons maintenant. FIGURE II.2. Seuil SNA fixe d’un algorithme non adaptatif26 Problème de détection et suivi d’objets multiples II.2.1.2 Seuil adaptatif de Dietmayer et al. (2001) Dietmayer et al. (2001) définissent une distance seuil qui ne dépend que de la distance entre la surface d’impact et le repère du télémètre. Sa formulation est la suivante : SDietmayer = CDietmayer min{ρθ− ,ρθ }+Cbruit avec – CDietmayer = p 2(1−cos(∆θ)) le paramètre de raffinement du partitionnement ; – Cbruit une constante traduisant l’influence du bruit en distance des impacts sur le calcul du seuil, classiquement Cbruit = 3σρ où σρ est une donnée constructeur de l’ordre de quelques centimètres correspondant à l’erreur expérimentale sur la mesure de la distance ρ (Jida, 2008). Comme le remarque Jida (2008), le calcul du paramètre CDietmayer prend pour hypothèse que la surface est perpendiculaire à la bissectrice de la droite passant par les points zθ− à zθ . Ainsi, ni l’orientation ni l’inclinaison de la surface d’impact ne sont considérées et le calcul du seuil est donc très fortement dépendant de la distance du capteur à la surface d’impact. Il devient alors difficile de séparer les groupes de mesures lorsque les impacts sont très éloignés du capteur. II.2.1.3 Seuil adaptatif de Santos et al. (2003) L’approche de Santos et al. (2003) reprend celle de Dietmayer et al. (2001). Mais, ils y introduisent une valeur d’angle constante, β, permettant de prendre en compte l’inclinaison maximale de la surface (figure II.3). β réduit la dépendance du partitionnement, précédemment constatée dans l’approche de Dietmayer et al. (2001), à la distance entre l’objet et le lidar. La valeur de β est à choisir expérimentalement. Si β est choisi trop grand, il sera plus difficile de séparer deux objets proches, à l’inverse s’il est choisi trop petit, deux mesures successives provenant d’un même objet risquent d’être séparées (Santos et al., 2003). FIGURE II.3. Paramètres du seuil adaptatif SSantos selon Santos et al. (2003) La distance seuil devient alors : SSantos = CDietmayer cot(β) cos(∆θ/2)−sin(∆θ/2) min{ρθ− ,ρθ }+Cbruit avec β angle d’inclinaison maximal de la surface d’impact, fixé expérimentalement, généralement autour de 60˚ (Jida, 2008).Détection dans les données télémétriques 27 II.2.1.4 Seuil adaptatif de Borges et Aldon (2004) Borges et Aldon (2004) prennent en compte, comme Santos et al. (2003), l’orientation maximale de la surface entre les impacts et le capteur télémétrique pour son calcul de la distance seuil. Cependant, ils n’utilisent pas la mesure de distance zθ de l’angle de tir courant, mais seulement celle zθ− de l’angle de tir précédent. Ils font en outre intervenir l’angle λ non orienté mais construit, dans le sens trigonométrique, au niveau du point d’impact sur la surface et à partir de « la droite de tir de l’impact zθ− » (figure II.4). Cet angle λ joue, en quelque sorte, le rôle « d’angle limite à la surface en deçà duquel le capteur télémétrique ne pourra délivrer de mesures », car, en deçà, la surface et le faisceau se rapproche du parallélisme et l’angle de réflexion du signal empêche alors le retour de l’écho vers le capteur. L’angle limite de tir à la surface est fixée par les constructeurs de lidar aux alentours de 10˚. L’angle λ peut être légèrement supérieur à cette valeur, jusqu’à 25˚ selon Jida (2008), mais un λ trop grand peut rendre impossible la séparation en partition. Ce paramètre est donc à régler expérimentalement. FIGURE II.4. Paramètres du seuil adaptatif SBorges selon Borges et Aldon (2004) La formulation de la valeur de la distance seuil selon l’approche de Borges et Aldon (2004) est la suivante : SBorges = (ρθ− ) sin(∆θ) sin(λ −∆θ) +Cbruit avec λ angle limite en deçà duquel le lidar ne délivre plus de mesure (perte du signal). II.2.2 Segmentation de partitions Les algorithmes de partitionnement de mesures ont eu pour objectif de regrouper les mesures partageant une ou plusieurs caractéristiques communes. Ceux de segmentation ont pour finalité de retrouver des formes dans ces ensembles de mesures. Afin d’identifier des contours d’objets, nous nous intéressons aux algorithmes d’extraction de ligne dans des données laser 2D et nous nous appuyons en particulier sur les travaux de Nguyen et al. (2005, 2007). Nous présentons ainsi ci-après les cinq méthodes de segmentation répertoriées : l’approche incrémentale, l’approche par décomposition et fusion (Split and merge), l’approche RANSAC (Random Sample Consensus), l’approche par transformée de Hough et, enfin, l’approche par maximixation de l’espérance (EM, Expectation-Maximization).28 Problème de détection et suivi d’objets multiples II.2.2.1 Approche incrémentale Les approches incrémentales de segmentation sont apparues dans les années 70. Elles consistent en la recherche de forme, dans un ensemble ordonné P de mesures. À partir des premiers points constituant la forme, elles vérifient pour chaque nouvelle mesure son appartenance à la forme en cours de construction selon un critère de décision. Le choix de ces critères repose sur des conditions simplifiées. Un exemple de critère de décision dans le cas de l’extraction d’une droite est le respect d’une valeur seuil maximale par la distance orthogonale entre la mesure considérée et la droite. Cette approche est fondée sur le calcul successif des paramètres de la droite en ajoutant le point zθ+ . 1. Soit un ensemble P de N points P =  zθa ,...,zθa+N 2. Construire une droite (d) entre les deux premiers points 3. Ajouter le point suivant zθ+ au modèle de droite courant (d) et réestimer les paramètres de la droite (d) 4. Si les conditions de la droite sont satisfaites, retour à l’étape 3, 5. Sinon – Éliminer le dernier point zθ+ de la droite (d) – Réestimer les paramètres de la droite (d) – Mémoriser la droite (d) – Retour à l’étape 2 avec comme modèle de droite (d) ce dernier point zθ+ et le suivant. L’algorithme incrémental de segmentation est simple à mettre en œuvre. Les critères de décision sont facilement modifiables et il ne nécessite pas que l’acquisition des données soit terminée pour être exécuté. Cependant, avoir un seuil fixe est un inconvénient. Le choisir trop petit implique un morcellement des droites détectées à une distance très éloignée de la position du capteur. À l’inverse, un seuil trop grand conduit à des associations aberrantes de points pour des droites détectées à une distance proche du capteur. II.2.2.2 Approche Split and Merge L’approche Split and Merge est probablement la plus populaire des méthodes d’extraction de droites. C’est un algorithme itératif qui provient du traitement d’images, il est ainsi capable de traiter les points d’échantillonnage d’un balayage laser qui sont peu nombreux par rapport aux pixels d’une image. Il est plus rapide qu’un algorithme de groupement (Einsele, 1997). Dans la littérature, on retrouve cette technique de segmentation dans beaucoup de travaux, notamment dans la robotique, sur des données télémétriques de laser 2D (Einsele, 1997; Borges et Aldon, 2004; Siadat et al., 1997; Zhang et Ghosh, 2000). Les algorithmes Split and Merge permettent de réaliser des approximations polygonales de lignes par une succession de division de ces lignes en deux (Split), puis par une phase de fusion (Merge), selon un ou plusieurs critères de validation. Selon Ray et Ray (1995), le problème fondamental de ces techniques est la segmentation initiale. Par exemple, la technique Split and Merge de Pavlidis et Horowitz (1974) (cité dans (Ray et Ray, 1995)) cherche à adapter à un contour des lignes droites dont la définition provient d’une première segmentation. Elle calcule pour cela l’erreur quadratique des points du contour à la droite. Si l’erreur est trop grande, la ligne est divisée ; deux lignes seront fusionnées si elle est trop petite. Dans (Ray et Ray, 1995), des polygones insensibles à l’orientation et à l’échelle de courbes chaînées sont générés en utilisant trois critères de validation. Le premier est la distance (non perpendiculaire) d’un point k d’une courbe à un segment de droite i j divisée par la longueur du segment li j afin de la rendre indépendante à l’échelle (normalisation), critère dki j/li j. Les segments de courbes sont séparés aux points k pour lesquels dki j/li j atteint un maximum. Le second, le ratio de la longueur de l’arc à la longueur du segment de ligneDétection dans les données télémétriques 29 (ai j/li j), comparé à une valeur seuil, permet de vérifier que les points k de la courbes compris entre i et j sont colinéaires. En cas de dépassement du seuil, un troisième critère, la somme des dki j/li j pour les points k de la courbe variant entre (i + 1) et (j − 1), sert à trancher la décision de colinéarité ou non colinéarité. En fonction de la valeur de ces trois critères, des lignes sont tout d’abord divisées (phase Split). Des lignes seront par la suite fusionnées selon ces critères (phase Merge). La phase de division peut utiliser la méthode IEPF (Iterative-End-Point-Fit) (Borges et Aldon, 2000). Celle-ci permet, si le critère de validation est satisfait, la division des points d’un ensemble ordonné P en deux sous-ensembles à partir du point de rupture de l’ensemble. Le point candidat au titre de point de rupture de l’ensemble P est le point pour lequel la distance à la ligne, construite à partir des deux points extrêmes de P, est maximale (par exemple distance orthogonale à la droite, distance de Mahalanobis...). Si en ce point, la valeur de la distance est supérieure à une distance seuil, l’ensemble est divisé en deux sous-ensembles en ce point de rupture. De façon récursive, ces sous-ensembles vont eux-même être divisés tant que le critère de validation est satisfait. Borges et Aldon (2000) présentent un algorithme SMF (Split and Merge Fuzzy) dans une liste de droites, selon un schéma proche de la méthode IEPF. Par contre, ils utilisent un critère de validation basé sur la dispersion des points supports (i.e. points à l’origine de la définition des droites), aussi bien au moment de la phase de division que celle de fusion. Les droites de la liste sont, chacune, définies par leurs paramètres en coordonnées polaires, leur centre de gravité en coordonnées cartésiennes et un vecteur comportant les indices des points supports. Une droite sera séparée en deux droites lorsque la valeur de dispersion maximale trouvée en un point support est supérieure à une valeur de dispersion maximale donnée. Lors de la phase de fusion, pour toute ligne de la liste, on cherche à savoir si deux lignes sont candidates à la fusion. Ce sont les deux lignes les plus proches en termes de distance entre leur centre de gravité et celui de la ligne initiale. Parmi les deux possibilités, la ligne fusionnée résultante sera celle dont la dispersion est la plus petite, si toutefois elle satisfait le critère de dispersion. Un algorithme Split and Merge basé sur une technique de division IEPF peut être schématisé ainsi : 1. Soit un ensemble P de N points, P =  zθa ,...,zθa+N 2. Placer P dans la liste L 3. Créer une droite (d), selon la méthode choisie, à partir des données de P 4. Chercher le point zθR pour lequel la distance choisie à la droite d(zθR,(d)) est maximale 5. Si d(zθR,(d)) est inférieure à un seuil, retour à l’étape 3 6. Sinon – Diviser l’ensemble P au niveau de zθR en Pa et Pb – Remplacer P par Pa et Pb dans L – Retourner à l’étape 3 7. quand tous les sous-ensembles de L ont été étudiés, fusionner les segments colinéaires selon le ou les critères de validation choisis. L’approche Split and Merge est simple à mettre en œuvre. Cependant, cet algorithme récursif ne peut être exécuté que sur un ensemble de point déterminé. Ceci implique que le traitement ne peut commencer qu’après la fin de la phase d’acquisition des mesures. Comme pour l’algorithme incrémental, le choix du seuil est une difficulté. L’article de (Fortin et al., 2012) montre d’ailleurs cette difficulté et propose une nouvelle méthode qui définit un critère de détection de segments de lignes dépendant uniquement des paramètres intrinsèques du capteur.30 Problème de détection et suivi d’objets multiples II.2.2.3 Approche RANSAC (Random Sample Consensus) L’algorithme RANSAC, publié pour la première fois par Fischler et Bolles (1981), est une méthode itérative destinée à estimer les paramètres d’un modèle mathématique à partir d’un ensemble de données observées contenant un grand nombre de valeurs aberrantes (appelées outliers). L’algorithme RANSAC repose sur deux hypothèses fortes : – les inliers sont les données dont la distribution peut être expliquée par un ensemble de paramètres du modèle considéré ; – les outliers sont des données qui ne correspondent pas au modèle choisi. RANSAC suppose qu’étant donné un ensemble petit d’inliers, il existe une procédure qui permet d’estimer les paramètres du modèle de façon à expliquer de manière optimale ces données. L’algorithme cherche donc à estimer le modèle par ses inliers en éliminant ses outliers, comme le montre la figure II.5. FIGURE II.5. Exemple de dispersion des inliers et outliers À l’inverse des techniques conventionnelles qui, à partir d’un grand ensemble de données P, éliminent les points aberrants, l’algorithme de Ransac utilise le plus petit ensemble de données initiales possible et l’accroît en associant les données les plus compatibles avec la modélisation antérieurement réalisée à partir de l’ensemble des données initiales (Fischler et Bolles, 1981). L’algorithme consiste en deux étapes répétées de manière itérative : – un ensemble minimal de n points est sélectionné de manière aléatoire dans l’ensemble des données d’entrée P, à partir duquel les paramètres du modèle sont estimés ; – chacun des éléments de l’ensemble de données P est testé pour vérifier s’il correspond au modèle. L’algorithme de Ransac s’arrête lorsque la probabilité de trouver un meilleur sous-ensemble est inférieure à un seuil (Zuliani, 2012). Nous considérons maintenant l’exemple de Jida (2008) qui cherche à estimer une droite parmi un ensemble de points (figure II.5). Deux points (zθa, zθb) sont choisis aléatoirement parmi l’ensemble des données à traiter. Les paramètres de la droite (d) passant par ces points sont estimés. La distance de chacun des autres points zθ j à la droite (d) est alors calculée. Un point sera associé à (d) si sa distance à cette droite est inférieure à un seuil fixé. Ces points sont appelés inliers candidats. Si le nombre des inliers candidats est suffisant, alors les paramètres de la droite sont réestimés en les prenant en compte. Ces inliers candidats sont ensuite éliminés du groupe de points initial. On réitère la procédure jusqu’à ce qu’il n’y ait plus suffisamment de points dans le groupe ou jusqu’au nombre maximum d’itération. L’algorithme est résumé ci-dessous :Détection dans les données télémétriques 31 – Soit un ensemble P de N points P =  zθa ,...,zθa+N – Répéter : Choisir aléatoirement deux points (zθa, zθb) Créer une droite (d) entre ces deux points et estimer ses paramètres Calculer les distances des autres points à la droite d(zθ j ,(d)) ∀zθ j ∈ P− {zθa, zθb} Construire l’ensemble des inliers candidats de distance inférieure à un seuil S’il y a un nombre suffisant d’inliers candidats – Réestimer les paramètres de la droite (d) en prenant en compte les inliers candidats – Mémoriser la droite (d) – Éliminer les inliers candidats de l’ensemble P – Tant que le maximum de N itérations n’est pas atteint ou que le nombre de points de P soit insuffisant. La méthode RANSAC est populaire en vision par ordinateur. Simple à mettre en œuvre, elle oblige cependant d’attendre la fin de l’acquisition pour démarrer les traitements. Elle permet d’estimer les paramètres avec un degré élevé de précision, même si une quantité importante d’outliers est présente. Dans notre cas, un des problèmes est le caractère aléatoire de la recherche des droites, on peut obtenir des droites qui n’ont pas d’existence réel en termes d’obstacles présents dans le champ de vision du capteur. Cet algorithme nécessite également de fixer un seuil spécifique au problème traité. Enfin, l’approche RANSAC est une approche à modèle unique. C’est-à-dire lorsque plusieurs modèles coexistent, l’algorithme n’arrive pas à déterminer les différents modèles (Forsyth et Ponce, 2003). II.2.2.4 Transformée de Hough Selon (Duquenoy et Taleb-Ahmed, 2006), la transformée de Hough permet la détection, dans une image, de formes décrites analytiquement, formes incluant des lignes droites, cercles et ellipses. Elle permet aussi sous certaines conditions toute détection de forme quelle qu’en soit leur description. Elle est utilisée dans de nombreuses applications telles que la détection d’objets, la détection de mouvement, la reconnaissance de caractère... Duquenoy et Taleb-Ahmed la décrivent ainsi. La transformée de Hough cherche à déterminer les paramètres géométriques d’une forme au moyen d’une procédure de vote : chaque point de l’image, de la forme, vote pour un ou plusieurs points dans l’espace des paramètres. La dimension de cet espace dépend de la forme recherchée (deux dimensions pour une droite, trois pour un cercle). Plusieurs approches de vote existent. Nous présentons ci-après l’approche décrite dans (Duda et Hart, 1971, 1972), approche qualifiée de transformation one-to-many par Duquenoy et Taleb-Ahmed. Duda et Hart (1971) proposent de détecter des lignes (ou des courbes) dans des images en travaillant dans l’espace des paramètres (Θ,ρ). Dans cet espace, l’équation d’une droite est : ρ = x · cos(Θ) +y ·sin(Θ). En restreignant Θ à l’intervalle [0,π], toute droite (d) dans le plan xy correspond à un unique point dans le plan Θρ pour lequel l’angle Θ est l’angle polaire de la normale à la droite (d) (figure II.6). Considérant l’ensemble de points {(x1,y1),...,(xn,yn)}, ils y cherchent des lignes droites en transformant chaque point (xj ,yj) en une courbe sinusoïdale dans le plan Θρ, courbe définie par l’expression (II.2). ρ = xj · cos(Θ) +yj ·sin(Θ) (II.2) Les courbes correspondant à des points colinéaires ont un point d’intersection commun dans le plan Θρ, qui définit la ligne passant par les points colinéaires. Duda et Hart en déduisent que le problème de la détection de points colinéaires est celui de la recherche des courbes (II.2) concurrentes. Les intervalles de recherche en ρ et en Θ doivent être quantifiés. Des indices correspondant aux valeurs de ρ et de Θ définissent les lignes et colonnes d’un tableau, appelé accumulateur. Pour chaque point (xj ,yj) de l’image, la courbe correspondante, décrite par l’équation (II.2), est enregistrée dans l’accumulateur en incrémentant le compteur de points des cellules (indΘ,indρ ) traversées par la courbe. Ainsi, une recherche des cellules dont la valeur du compteur est supérieure à un seuil permet de trouver les paramètres (Θj ,ρj)32 Problème de détection et suivi d’objets multiples des normales aux droites par lesquelles passent le plus grand nombre de points, à l’erreur de quantification (∆ρ et ∆Θ) près. FIGURE II.6. Paramètres (Θ,ρ) tels que Θ est l’angle polaire de la normale à la droite (d) (Duda et Hart, 1971) L’algorithme est le suivant : 1. Soit un ensemble P de N points, P = {z1,...,zn} où zj = (xj ,yj), ∀ j ∈ [1,n] ; 2. Soit le problème ainsi quantifié : ∀zj , ρ ∈ [ρmin,ρmax], ρ est arrondi à ∆ρ près, Θ ∈ [0,π] avec Θ incrémenté de ∆Θ 3. Soit Acc jρ , jΘ un tableau de Nρ lignes et de NΘ colonnes, dimensions définies conformé- ment au choix de quantification du problème. 4. Début – Pour tout zj , j ∈ [1,n], Pour tout Θ ∈ [0,π] incrémenté de ∆Θ Calculer ρ selon II.2 indρ = f(ρ), où f(ρ) respecte les règles de quantification adoptées Acc indρ ,indΘ + = 1 Fin pour – Fin pour – ∀(indρ ,indΘ), rechercher les valeurs max de Acc indρ ,indΘ supérieures à un seuil. 5. Fin Dans le cas de données issues d’un télémètre le principe est le même. Ainsi Pfister et al. (2003) cherchent à trouver des droites à partir de chacun des points de l’ensemble P étudié. Chaque point est transformé en une ligne discrétisée dans l’espace de Hough. Cette transformation est basée sur la paramétrisation d’une ligne en coordonnées polaires avec une distance normale à l’origine ρ et un angle Θ (figure II.6). De même que pour l’image, pour chaque point de l’ensemble, les paramètres ρ et Θ de chaque ligne sont calculés et enregistrés dans un accumulateur. Quand une cellule (indρ ,indΘ) de l’espace de Hough est incrémentée, la coordonnée du point est associée et sauvegardée. Ainsi, quand un pic est déterminé, les points associés sont extraits. Dans ce cas, les auteurs peuvent trier les points du balayage en sous-ensembles colinéaires et déterminer l’orientation du segment de ligne. La transformée de Hough est une approche récursive, obligeant ainsi d’attendre la fin de l’acquisition pour démarrer les traitements. Elle est sensible à la quantification choisie. Un échantillonnage trop fin, en ρ et Θ augmente le temps de calcul. D’autre part, elle ne regarde pas la continuité des points colinéaires. Par conséquent, la position d’une droite peut être perturbée par la présence de points se trouvant dans une autre partie de l’image considérée, et donc sans relation avec la forme recherchée. Techniques visuelles pour la d´etection et le suivi d’objets 2D Rafiq Sekkal To cite this version: Rafiq Sekkal. Techniques visuelles pour la d´etection et le suivi d’objets 2D. Computer Vision and Pattern Recognition. INSA de Rennes, 2014. French. HAL Id: tel-00981107 https://tel.archives-ouvertes.fr/tel-00981107 Submitted on 20 Apr 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Techniques visuelles pour la détection et le suivi d’objets 2D N° ordre : 14ISAR02/D14-02 Thèse soutenue le 28/02/2014 devant le jury composé de : Joseph RONSIN Professeur à INSA de Rennes / Président Luc BRUN Professeur à ENSI de Caen / Rapporteur Vincent FREMONT Maître de conférences HDR UT de Compiègne / Rapporteur Ferran MARQUES Professeur à UPC Barcelone / Examinateur Muriel PRESSIGOUT Maître de conférences à l'INSA de Rennes / Examinatrice Marie BABEL Maître de conférences HDR à l'INSA de Rennes / Directrice de thèse THESE INSA Rennes sous le sceau de l’Université européenne de Bretagne pour obtenir le titre de DOCTEUR DE L’INSA DE RENNES Spécialité : Traitement de signal et de l’image présentée par Rafiq SEKKAL ECOLE DOCTORALE : MATISSE LABORATOIRE : IRISA – UMPR6047Techniques visuelles pour la détection et le suivi d’objets 2D Rafiq SEKKAL Résumé De nos jours, le traitement et l'analyse d'images trouvent leur application dans de nombreux domaines. Dans le cas de la navigation d’un robot mobile (fauteuil roulant) en milieu intérieur, l’extraction de repères visuels et leur suivi constituent une étape importante pour la réalisation de tâches robotiques (localisation, planification, etc.). En particulier, afin de réaliser une tâche de franchissement de portes, il est indispensable de détecter et suivre automatiquement toutes les portes qui existent dans l’environnement. La détection des portes n’est pas une tâche facile : la variation de l’état des portes (ouvertes ou fermées), leur apparence (de même couleur ou de couleur différentes des murs) et leur position par rapport à la caméra influe sur la robustesse du système. D’autre part, des tâches comme la détection des zones navigables ou l’évitement d’obstacles peuvent faire appel à des représentations enrichies par une sémantique adaptée afin d’interpréter le contenu de la scène. Pour cela, les techniques de segmentation permettent d’extraire des régions pseudo-sémantiques de l’image en fonction de plusieurs critères (couleur, gradient, texture…). En ajoutant la dimension temporelle, les régions sont alors suivies à travers des algorithmes de segmentation spatio-temporelle. Dans cette thèse, des contributions répondant aux besoins cités sont présentées. Tout d’abord, une technique de détection et de suivi de portes dans un environnement de type couloir est proposée : basée sur des descripteurs géométriques dédiés, la solution offre de bons résultats. Ensuite, une technique originale de segmentation multirésolution et hiérarchique permet d’extraire une représentation en régions pseudosémantique. Enfin, cette technique est étendue pour les séquences vidéo afin de permettre le suivi des régions à travers le suivi de leurs contours. La qualité des résultats est démontrée et s’applique notamment au cas de vidéos de couloir. N° d’ordre : XXXXXXXX Abstract Nowadays, image processing remains a very important step in different fields of applications. In an indoor environment, for a navigation system related to a mobile robot (electrical wheelchair), visual information detection and tracking is crucial to perform robotic tasks (localization, planning…). In particular, when considering passing door task, it is essential to be able to detect and track automatically all the doors that belong to the environment. Door detection is not an obvious task: the variations related to the door status (open or closed), their appearance (e.g. same color as the walls) and their relative position to the camera have influence on the results. On the other hand, tasks such as the detection of navigable areas or obstacle avoidance may involve a dedicated semantic representation to interpret the content of the scene. Segmentation techniques are then used to extract pseudosemantic regions based on several criteria (color, gradient, texture...). When adding the temporal dimension, the regions are tracked then using spatiotemporal segmentation algorithms. In this thesis, we first present joint door detection and tracking technique in a corridor environment: based on dedicated geometrical features, the proposed solution offers interesting results. Then, we present an original joint hierarchical and multiresolution segmentation framework able to extract a pseudo-semantic region representation. Finally, this technique is extended to video sequences to allow the tracking of regions along image sequences. Based on contour motion extraction, this solution has shown relevant results that can be successfully applied to corridor videos. Idéalisation d’assemblages CAO pour l’analyse EF de structures Flavien Boussuge To cite this version: Flavien Boussuge. Id´ealisation d’assemblages CAO pour l’analyse EF de structures. Other. Universit´e de Grenoble, 2014. French. . HAL Id: tel-01071560 https://tel.archives-ouvertes.fr/tel-01071560 Submitted on 6 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THESE ` Pour obtenir le grade de DOCTEUR DE L’UNIVERSITE DE GRENOBLE ´ Specialit ´ e : ´ Mathematiques et Informatique ´ Arretˆ e minist ´ erial : 7 ao ´ ut 2006 ˆ Present ´ ee par ´ Flavien Boussuge These dirig ` ee par ´ Jean-Claude Leon ´ et codirigee par ´ Stefanie Hahmann prepar ´ ee au sein ´ Laboratoire Jean Kuntzmann - INRIA Grenoble, et AIRBUS Group Innovations et de l’Ecole Doctorale Mat ´ ematiques, Sciences et Technologies de ´ l’Information, Informatique Idealization of CAD assemblies for FE structural analyses Idealisation d’assemblages CAO ´ pour l’analyse EF de structures These soutenue publiquement le ` TBD, devant le jury compose de : ´ Prof., Cecil Armstrong Queen’s University Belfast, Rapporteur Dr., Bruno Levy ´ Directeur de recherche, INRIA Nancy, Rapporteur Dr., Lionel Fine AIRBUS Group Innovations, Suresnes, Examinateur Prof., Jean-Philippe Pernot Arts et Metiers ParisTech, Aix en Provence, Examinateur ´ Prof., Jean-Claude Leon ´ INP-Grenoble, ENSE3, Directeur de these ` Prof., Stefanie Hahmann INP-Grenoble, ENSIMAG, Co-Directeur de these ` M., Nicolas Chevassus AIRBUS Group Innovations, Suresnes, Invite´ M., Franc¸ois Guillaume AIRBUS Group Innovations, Suresnes, Invite´iiThe research described in this thesis was carried out at the Laboratoire Jean Kuntzmann LJK-INRIA research team Imagine and the SPID team of AIRBUS Group Innovations. This work was supported by a CIFRE convention of the ANRT and the French Ministry of Higher Education and Research. �c 2014, F. Boussuge, all rights reserved. iiiivIdealization of CAD assembly for FE structural analysis Abstract Aeronautical companies face a significant increase in complexity and size of simulation models especially at the level of assemblies, sub-systems of their complex products. Pre-processing of Computer Aided Design (CAD) models derived from the digital representation of sub-systems, i.e., Digital Mock-Ups (DMUs), into Finite Elements Analysis (FEA) models requires usually many tedious manual tasks of model preparation and shape transformations, in particular when idealizations of components or assemblies have to be produced. Therefore, the purpose of this thesis is to make a contribution to the robust automation of the time-consuming sequences of assembly preparation processes. Starting from an enriched DMU with geometrical interfaces between components and functional properties, the proposed approach takes DMU enrichment to the next level by structuring components’ shapes. This approach extracts a construction graph from B-Rep CAD models so that the corresponding generative processes provide meaningful volume primitives for idealization application. These primitives form the basis of a morphological analysis which identifies the sub-domains for idealization in the components’ shapes and their associated geometric interfaces. Subsequently, models of components as well as their geometric representation get structured in an enriched DMU which is contextualized for FEA application. Based on this enriched DMU, simulation objectives can be used to specify geometric operators that can be robustly applied to automate components and interfaces shape transformations during an assembly preparation process. A new idealization process of standalone components is proposed while benefiting from the decomposition into sub-domains and their geometric interfaces provided by the morphological analysis of the component. Interfaces between sub-domains are evaluated to robustly process the connections between the idealized sub-domains leading to the complete idealization of the component. Finally, the scope of the idealization process is extended to shape transformations at the assembly level and evolves toward a methodology of assembly pre-processing. This methodology aims at exploiting the functional information of the assembly and interfaces between components to perform transformations of groups of components and assembly idealizations. In order to prove the applicability of the proposed methodology, corresponding operators are developed and successfully tested on industrial use-cases. Keywords : Assembly, DMU, idealization, CAD-CAE integration, B-Rep model, generative shape process, morphological analysis vviId´ealisation d’assemblages CAO pour l’analyse EF de structures R´esum´e Les entreprises a´eronautiques ont un besoin continu de g´en´erer de grands et complexes mod`eles de simulation, en particulier pour simuler le comportement structurel de soussyst`emes de leurs produits. Actuellement, le pr´e-traitement des mod`eles de Conception Assist´ee par Ordinateur (CAO) issus des maquettes num´eriques de ces sous-syst`emes en Mod`eles El´ements Finis (MEF), est une tˆache qui demande de longues heures de travail de la part des ing´enieurs de simulation, surtout lorsque des id´ealisations g´eom´etriques sont n´ecessaires. L’objectif de ce travail de th`ese consiste `a d´efinir les principes et les op´erateurs constituant la chaˆıne num´erique qui permettra, `a partir de maquettes num´eriques complexes, de produire des g´eom´etries directement utilisables pour la g´en´eration de maillages ´el´ements finis d’une simulation m´ecanique. A partir d’une maquette num´erique enrichie d’information sur les interfaces g´eom´etriques entre composants et d’information sur les propri´et´es fonctionnelles de l’assemblage, l’approche propos´ee dans ce manuscrit est d’ajouter un niveau suppl´ementaire d’enrichissement en fournissant une repr´esentation structurelle de haut niveau de la forme des composants CAO. Le principe de cet enrichissement est d’extraire un graphe de construction de mod`eles CAO B-Rep de sorte que les processus de g´en´eration de forme correspondants fournissent des primitives volumiques directement adapt´ees `a un processus d’id´ealisation. Ces primitives constituent la base d’une analyse morphologique qui identifie dans les formes des composants `a la fois des sous-domaines candidats `a l’id´ealisation mais ´egalement les interfaces g´eom´etriques qui leurs sont associ´ees. Ainsi, les mod`eles de composants et leurs repr´esentations g´eom´etriques sont structur´es. Ils sont int´egr´es dans la maquette num´erique enrichie qui est ainsi contextualis´ee pour la simulation par EF. De cette maquette num´erique enrichie, les objectifs de simulation peuvent ˆetre utilis´es pour sp´ecifier les op´erateurs g´eom´etriques adaptant les composants et leurs interfaces lors de processus automatiques de pr´eparation d’assemblages. Ainsi, un nouveau proc´ed´e d’id´ealisation de composant unitaire est propos´e. Il b´en´eficie de l’analyse morphologique faite sur le composant lui fournissant une d´ecomposition en sous-domaines id´ealisables et en interfaces. Cette d´ecomposition est utilis´ee pour g´en´erer les mod`eles id´ealis´es de ces sous-domaines et les connecter `a partir de l’analyse de leurs interfaces, ce qui conduit `a l’id´ealisation compl`ete du composant. Enfin, le processus d’id´ealisation est ´etendu au niveau de l’assemblage et ´evolue vers une m´ethodologie de pr´e-traitement automatique de maquettes num´eriques. Cette m´ethodologie vise `a exploiter l’information fonctionnelle de l’assemblage et les informations morphologiques des composants afin de transformer `a la fois des groupes de viicomposants associ´es `a une mˆeme fonction ainsi que de traiter les transformations d’id´ealisation de l’assemblage. Pour d´emontrer la validit´e de la m´ethodologie, des op´erateurs g´eom´etriques sont d´evelopp´es et test´es sur des cas d’application industriels. Mots-cl´es : Assemblage, Maquette Num´erique, int´egration CAO-calcul, mod`ele B-Rep, graphe de construction , processus g´en´eratif de forme, id´ealisation viiiTable of contents Abstract v R´esum´e vii Acronyms xxiii Introduction 1 Context of numerical certification of aeronautical structures . . . . . . . . . 1 Some limits faced in structural simulations . . . . . . . . . . . . . . . . . . . 2 Work Purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 From a Digital Mock Up to Finite Element Assembly Models: Current practices 5 1.1 Introduction and definition DMU concept . . . . . . . . . . . . . . . . 5 1.2 Geometric representation and modeling of 3D components . . . . . . . 7 1.2.1 Categories of geometric families . . . . . . . . . . . . . . . . . . 7 1.2.2 Digital representation of solids in CAD . . . . . . . . . . . . . . 9 1.2.3 Complementary CAD software capabilities: Feature-based and parametric modeling . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3 Representation and modeling of an assembly in a DMU . . . . . . . . . 16 1.3.1 Effective DMU content in aeronautical industry . . . . . . . . . 16 1.3.2 Conventional representation of interfaces in a DMU . . . . . . . 19 1.4 Finite Element Analysis of mechanical structures . . . . . . . . . . . . 22 1.4.1 Formulation of a mechanical analysis . . . . . . . . . . . . . . . 22 1.4.2 The required input data for the FEA of a component . . . . . . 24Table of contents 1.4.3 FE simulations of assemblies of aeronautical structures . . . . . 27 1.5 Difficulties triggering a time consuming DMU adaptation to generate FE assembly models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.5.1 DMU adaption for FE analyses . . . . . . . . . . . . . . . . . . 31 1.5.2 Interoperability between CAD and CAE and data consistency . 33 1.5.3 Current operators focus on standalone components . . . . . . . 34 1.5.4 Effects of interactions between components over assembly transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 1.6 Conclusion and limits of current practices about DMU manual adaption for FE assembly models generation . . . . . . . . . . . . . . . . . . . . 39 1.7 Research objectives: Speed up the DMU pre-processing to reach the simulation of large assemblies . . . . . . . . . . . . . . . . . . . . . . . 40 2 Current status of procedural shape transformation methods and tools for FEA pre-processing 43 2.1 Targeting the data integration level . . . . . . . . . . . . . . . . . . . . 43 2.2 Simplification operators for 3D FEA analysis . . . . . . . . . . . . . . . 45 2.2.1 Classification of details and shape simplification . . . . . . . . . 45 2.2.2 Detail removal and shape simplification based on tessellated models 47 2.2.3 Detail removal and shape simplification on 3D solid models . . . 49 2.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.3 Dimensional reduction operators applied to standalone components . . 53 2.3.1 Global dimensional reduction using the MAT . . . . . . . . . . 53 2.3.2 Local mid-surface abstraction . . . . . . . . . . . . . . . . . . . 55 2.3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.4 About the morphological analysis of components . . . . . . . . . . . . 58 2.4.1 Surface segmentation operators . . . . . . . . . . . . . . . . . . 58 2.4.2 Solid segmentation operators for FEA . . . . . . . . . . . . . . . 60 2.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2.5 Evolution toward assembly pre-processing . . . . . . . . . . . . . . . . 64 2.6 Conclusion and requirements . . . . . . . . . . . . . . . . . . . . . . . . 67 3 Proposed approach to DMU processing for structural assembly simxTable of contents ulations 69 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.2 Main objectives to tackle . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.3 Exploiting an enriched DMU . . . . . . . . . . . . . . . . . . . . . . . . 71 3.4 Incorporating a morphological analysis during FEA pre-processing . . . 75 3.4.1 Enriching DMU components with their shape structure as needed for idealization processes . . . . . . . . . . . . . . . . . . . . . . 77 3.4.2 An automated DMU analysis dedicated to a mechanically consistent idealization process . . . . . . . . . . . . . . . . . . . . . 78 3.5 Process proposal to automate and robustly generate FEMs from an enriched DMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.5.1 A new approach to the idealization of a standalone component . 81 3.5.2 Extension to assembly pre-processing using the morphological analysis and component interfaces . . . . . . . . . . . . . . . . . 81 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4 Extraction of generative processes from B-Rep shapes to structure components up to assemblies 85 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.2 Motivation to seek generative processes . . . . . . . . . . . . . . . . . . 86 4.2.1 Advantages and limits of present CAD construction tree . . . . 87 4.2.2 A new approach to structure a component shape: construction graph generation . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.3 Shape modeling context and process hypotheses . . . . . . . . . . . . . 91 4.3.1 Shape modeling context . . . . . . . . . . . . . . . . . . . . . . 91 4.3.2 Generative process hypotheses . . . . . . . . . . . . . . . . . . . 93 4.3.3 Intrinsic boundary decomposition using maximal entities . . . . 96 4.4 Generative processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.4.1 Overall principle to obtain generative processes . . . . . . . . . 98 4.4.2 Extrusion primitives, visibility and attachment . . . . . . . . . . 100 4.4.3 Primitive removal operator to go back in time . . . . . . . . . . 103 4.5 Extracting the generative process graph . . . . . . . . . . . . . . . . . . 107 4.5.1 Filtering out the generative processes . . . . . . . . . . . . . . . 107 xiTable of contents 4.5.2 Generative process graph algorithm . . . . . . . . . . . . . . . . 109 4.6 Results of generative process graph extractions . . . . . . . . . . . . . . 110 4.7 Extension of the component segmentation to assembly structure segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5 Performing idealizations from construction graphs 119 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.2 The morphological analysis: a filtering approach to idealization processes 120 5.2.1 Morphological analysis objectives for idealization processes based on a construction graph . . . . . . . . . . . . . . . . . . . . . . 121 5.2.2 Structure of the idealization process . . . . . . . . . . . . . . . . 124 5.3 Applying idealization hypotheses from a construction graph . . . . . . 125 5.3.1 Evaluation of the morphology of primitives to support idealization126 5.3.2 Processing connections between ‘idealizable’ sub-domains Dij . . 133 5.3.3 Extending morphological analyses of Pi to the whole object M . 137 5.4 Influence of external boundary conditions and assembly interfaces . . . 141 5.5 Idealization processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 5.5.1 Linking interfaces to extrusion information . . . . . . . . . . . . 146 5.5.2 Analysis of GS to generate idealized models . . . . . . . . . . . 147 5.5.3 Generation of idealized models . . . . . . . . . . . . . . . . . . . 153 5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 6 Toward a methodology to adapt an enriched DMU to FE assembly models 159 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 6.2 A general methodology to assembly adaptions for FEA . . . . . . . . . 160 6.2.1 From simulation objectives to shape transformations . . . . . . 161 6.2.2 Structuring dependencies between shape transformations as contribution to a methodology of assembly preparation . . . . . . . 164 6.2.3 Conclusion and methodology implementation . . . . . . . . . . 167 6.3 Template-based geometric transformations resulting from function identifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 xiiTable of contents 6.3.1 Overview of the template-based process . . . . . . . . . . . . . . 169 6.3.2 From component functional designation of an enriched DMU to product functions . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.3.3 Exploitation of Template-based approach for FE models transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 6.3.4 Example of template-based operator of bolted junctions transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 6.4 Full and robust idealization of an enriched assembly . . . . . . . . . . . 183 6.4.1 Extension of the template approach to idealized fastener generation185 6.4.2 Presentation of a prototype dedicated to the generation of idealized assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Conclusion and perspectives 191 Bibliography 211 Appendices I A Illustration of generation processes of CAD components I A.1 Construction process of an injected plastic part . . . . . . . . . . . . . I A.2 Construction process of an aeronautical metallic part . . . . . . . . . . I B Features equivalence IX C Taxonomy of a primitive morphology XV D Export to CAE software XIX xiiiTable of contents xivList of Figures 1.1 The Digital Mock-Up as the reference representation of a product, courtesy of Airbus Group Innovations. . . . . . . . . . . . . . . . . . . . . . 6 1.2 Regularized boolean operations of two solids. . . . . . . . . . . . . . . . 9 1.3 CSG and B-Rep representations of a solid. . . . . . . . . . . . . . . . . 10 1.4 Examples of non-manifold geometric models. . . . . . . . . . . . . . . . 12 1.5 CAD construction process using features. . . . . . . . . . . . . . . . . . 15 1.6 Example of an aeronautical CAD assembly: Root joint model (courtesy of Airbus Group Innovations). . . . . . . . . . . . . . . . . . . . . . . . 16 1.7 Example of complex DMU assembly from Alcas project [ALC08] and Locomachs project [LOC16]. . . . . . . . . . . . . . . . . . . . . . . . . 18 1.8 Representation of a bolted junction in a structural DMU of an aircraft. 20 1.9 Classification of Conventional Interfaces (CI) under contact, interference and clearance categories. . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.10 Process flow of a mechanical analysis. . . . . . . . . . . . . . . . . . . . 23 1.11 Example of FE mesh models . . . . . . . . . . . . . . . . . . . . . . . . 24 1.12 Example of a FE fastener simulating the behavior of a bolted junction using beam elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.13 Example of aeronautical FE models. . . . . . . . . . . . . . . . . . . . 31 1.14 Illustration of a shim component which does not appear in the DMU model. Shim component are directly manufacture when structural components are assembled. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1.15 Illustration of a manual process to generate an idealized model. . . . . 35 1.16 Example of contact model for a FE simulation. . . . . . . . . . . . . . . 38 2.1 Identification of a skin detail . . . . . . . . . . . . . . . . . . . . . . . . 46 2.2 Illustration of the MAT method . . . . . . . . . . . . . . . . . . . . . . 48 xvLIST OF FIGURES 2.3 Details removal using the MAT and detail size criteria [Arm94]. . . . . 49 2.4 Topology adaption of CAD models for meshing [FCF∗08]. . . . . . . . . 50 2.5 Illustration of CAD defeaturing using CATIA. . . . . . . . . . . . . . . 51 2.6 Illustration of the mixed dimensional modeling using a MAT [RAF11]. 54 2.7 Illustration of mid-surface abstraction [Rez96]. . . . . . . . . . . . . . . 56 2.8 An example of particular geometric configuration not addressed by facepairs methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.9 Illustration of different connection models for idealized components. . . 58 2.10 Mesh Segmentation techniques. . . . . . . . . . . . . . . . . . . . . . . 59 2.11 Automatic decomposition of a solid to identify thick/thin regions and long and slender ones, from Makem [MAR12]. . . . . . . . . . . . . . . 60 2.12 Idealization using extruded and revolved features in a construction tree, from [RAM∗06]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.13 Divide-and-conquer approach to idealization processes using a maximal volume decomposition (by Woo [Woo14]). . . . . . . . . . . . . . . . . 62 2.14 Assembly interface detection of Jourdes et al. [JBH∗14]. . . . . . . . . . 65 2.15 Various configurations of the idealization of a small assembly containing two components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.1 Current process to prepare assembly structures. Each component of the assembly is transformed individually. . . . . . . . . . . . . . . . . . . . 70 3.2 Structuring a DMU model with functional properties. . . . . . . . . . . 73 3.3 DMU enrichment process with assembly interfaces and component functional designations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 3.4 Interactions between simulation objectives, hypotheses and shape transformations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.5 Proposed approach to generate a FEM of an assembly structure from a DMU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.1 An example of a shape generation process. . . . . . . . . . . . . . . . . 87 4.2 An example of shape analysis and generative construction graph. . . . . 91 4.3 Modeling hypotheses about primitives to be identified in a B-Rep object. 92 4.4 Entities involved in the definition of an extrusion primitive in a B-Rep solid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 xviLIST OF FIGURES 4.5 Illustrations of two additive primitives: (a) an extrusion primitive and (b) a revolution one. The mid-surfaces of both primitives lie inside their respective volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.6 Example of two possible decompositions into primitives from a solid. . 96 4.7 Pipeline producing and exploiting generative shape processes. . . . . . 97 4.8 Examples of configurations where faces must be merged to produce a shape-intrinsic boundary decomposition. . . . . . . . . . . . . . . . . . 98 4.9 Overall scheme to obtain generative processes. . . . . . . . . . . . . . . 99 4.10 An example illustrating the successive identification and removal of primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.11 An example illustrating the major steps to identify a primitive and remove it from an object . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.12 Example of geometric interface . . . . . . . . . . . . . . . . . . . . . . 103 4.13 Example of a collection of primitives identified from a B-Rep object. . . 103 4.14 Illustration of the removal of Pi. . . . . . . . . . . . . . . . . . . . . . . 105 4.15 Illustration of the removal operator for interface of surface type 1a. . . 106 4.16 Illustration of the removal operator for interface of volume type 3. . . . 107 4.17 Illustration of the simplicity concept to filtering out the generative processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.18 Criteria of maximal primitives and independent primitives. . . . . . . . 110 4.19 Extraction of generative processes for four different components. . . . . 111 4.20 Result of generative process graph extractions. . . . . . . . . . . . . . . 113 4.21 Illustration of the continuity constraint. . . . . . . . . . . . . . . . . . . 114 4.22 A set of CAD construction trees forming a graph derived from two consecutive construction graph nodes. . . . . . . . . . . . . . . . . . . . . . 115 4.23 Illustration of the compatibility between the component segmentation (a) and assembly structure segmentation (b). . . . . . . . . . . . . . . . . . 116 4.24 Insertion of the interface graphs between primitives obtained from component segmentations into the graph of assembly interfaces between components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.1 From a construction graph of a B-Rep shape to a full idealized model for FEA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2 Global description of an idealization process. . . . . . . . . . . . . . . . 124 xviiLIST OF FIGURES 5.3 Determination of the idealization direction of extrusion primitives using a 2D MAT applied to their contour . . . . . . . . . . . . . . . . . . . . 126 5.4 Example of the morphological analysis of a component. . . . . . . . . . 129 5.5 Idealization analysis of components. . . . . . . . . . . . . . . . . . . . . 130 5.6 Illustration of primitives’ configurations containing embedded sub-domains Dik which can be idealized as beams or considered as details. . . . . . . 131 5.7 Example of a beam morphology associated with a MAT medial edge of a primitive Pi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.8 Synthesis of the process to evaluate the morphology of primitives Pi. . . 134 5.9 Taxonomy of connections between extrusion sub-domains. . . . . . . . 135 5.10 Illustration of propagation of the morphological analysis of two primitives.139 5.11 Propagation of the morphology analysis on Pi to the whole object M. . 140 5.12 Influence of an assembly interface modeling hypothesis over the transformations of two components . . . . . . . . . . . . . . . . . . . . . . . 141 5.13 Illustration of the inconsistencies between an assembly interface between two components and its projection onto their idealized representations. 143 5.14 Two possible schemes to incorporate assembly interfaces during the segmentation process of components. . . . . . . . . . . . . . . . . . . . . . 144 5.15 Illustration of an interface graph derived from the segmentation process of a component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 5.16 Illustration of an interface cycle between primitives. . . . . . . . . . . . 148 5.17 Examples of medial surface positioning improvement. (a) Offset of parallel medial surfaces, (b) offset of L-shaped medial surfaces. . . . . . . . 150 5.18 Example of identification of a group of parallel medial surfaces and border primitives configurations. . . . . . . . . . . . . . . . . . . . . . . . 151 5.19 Example of a volume detail configuration lying on an idealized primitive. 152 5.20 Interfaces connection operator . . . . . . . . . . . . . . . . . . . . . . . 154 5.21 Illustration of the idealization process of a component that takes advantage of its interface graph structures. . . . . . . . . . . . . . . . . . . . 155 5.22 Illustration of the successive phases of the idealization process. . . . . . 156 6.1 Setting up an observation area consistent with simulation objectives. . 162 6.2 Entire idealization of two components. . . . . . . . . . . . . . . . . . . 162 6.3 Transformation of groups of components as analytical models. . . . . . 163 xviiiLIST OF FIGURES 6.4 Influence of interfaces over shape transformations of components. . . . 163 6.5 Synthesis of the structure of an assembly simulation preparation process. 166 6.6 Use-Case 1: Simplified solid model with sub-domains decomposition around bolted junctions. . . . . . . . . . . . . . . . . . . . . . . . . . . 168 6.7 Overview of the main phases of the template-based process. . . . . . . 170 6.8 Subset of TF N , defining a functional structure of an assembly. . . . . . 171 6.9 Principle of the template-based shape transformations. . . . . . . . . . 174 6.10 Compatibility conditions (CC) of shape transformations ST applied to T. 174 6.11 Checking the compatibility of ST (T) with respect to the surrounding geometry of T. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 6.12 Multi-scale simulation with domain decomposition around bolted junctions, (courtesy of ROMMA project [ROM14]). . . . . . . . . . . . . . 177 6.13 Template based transformation ST (T) of a bolted junction into simple mesh model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 6.14 User interface of a template to transform ‘assembly Bolted Junctions’. . 181 6.15 Results of template-based transformations on CAD assembly models. . 182 6.16 Idealized surface model with FE fasteners to represent bolted junctions. 183 6.17 Illustration of Task 2: Transformation of bolted junction interfaces into mesh nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 6.18 Results of the template-based transformation of bolted junctions. . . . 184 6.19 User interface of the prototype for assembly idealization. . . . . . . . . 187 6.20 Illustration of a component segmentation which extracts extruded volumes to be idealized in task 3. . . . . . . . . . . . . . . . . . . . . . . . 187 6.21 Illustration of task 4: Identification and transformation of groups of idealized surfaces connected to the same assembly interfaces. . . . . . . 188 6.22 Final result of the idealized assembly model ready to be meshed in CAE software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 A.1 Example of a shape generation process 1/5 . . . . . . . . . . . . . . . . II A.2 Example of a shape generation process 2/5 . . . . . . . . . . . . . . . . III A.3 Example of a shape generation process 3/5 . . . . . . . . . . . . . . . . IV A.4 Example of a shape generation process 4/5 . . . . . . . . . . . . . . . . V A.5 Example of a shape generation process 5/5 . . . . . . . . . . . . . . . . VI xixLIST OF FIGURES A.6 Example of a shape generation process of a simple metallic component VII B.1 Examples of Sketch-Based Features . . . . . . . . . . . . . . . . . . . . X B.2 Examples of Sketch-Based Features . . . . . . . . . . . . . . . . . . . . XI B.3 Examples of Dress-Up Features . . . . . . . . . . . . . . . . . . . . . . XII B.4 Examples of Boolean operations . . . . . . . . . . . . . . . . . . . . . . XIII D.1 Illustration of the STEP export of a Bolted Junction with sub-domains around screw. (a) Product structure open in CATIA software, (b) associated xml file containing the association between components and interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XX D.2 Illustration of the STEP export of a Bolted Junction. Each component containing volume sub-domains is exported as STEP assembly. . . . . . XX D.3 Illustration of the STEP export of a Bolted Junction. Each inner interface between sub-domains is part of the component assembly. . . . . . . XXI D.4 Illustration of the STEP export of a Bolted Junction. Each outer interface between components is part of the root assembly. . . . . . . . . . . XXII D.5 Illustration of the STEP export of the full Root Joint assembly. . . . . XXIII xxList of Tables 1.1 Categories of Finite Elements for structural analyses. . . . . . . . . . . 25 1.2 Connector entities available in CAE software. . . . . . . . . . . . . . . 28 1.3 Examples of interactions or even dependencies between simulation objectives and interfaces as well as component shapes. . . . . . . . . . . . 30 5.1 Categorization of the morphology of a primitive using a 2D MAT applied to its contour. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 C.1 Morphology associated with a MAT medial edge of a primitive Pi. 1/2 XVI C.2 Morphology associated with a MAT medial edge of a primitive Pi. 2/2 XVII xxiLIST OF TABLES xxiiAcronyms B-Rep Boundary representation. 10–14, 17, 20, 21, 34, 45, 49, 50, 52, 62, 63, 77, 78, 85, 86, 89, 91–93, 96–98, 101, 102, 114, 116–118, 120, 140, 141, 147, 171, 192–195 CAD Computer Aided Design. IX, 2, 3, 5–7, 9–14, 16–19, 21, 24–26, 29, 30, 33–36, 39–41, 43, 44, 47–53, 55, 59, 60, 63, 65, 67, 70, 73, 77–79, 86–93, 97–99, 114, 116, 118–120, 122, 123, 140, 144, 155, 156, 159, 169, 179, 180, 183, 186, 189, 191, 193, 195 CAD-FEA Computer Aided Design to Finite Element Analysis(es). 12, 43, 191–193 CAE Computer Aided Engineering. 11, 12, 23, 25, 26, 33, 35, 37–41, 43–45, 47, 50–53, 67, 77, 123, 156, 165, 180, 189 CSG Constructive Solid Geometry. 9–11, 13, 62, 63 DMU Digital Mock-Up. XIX, 2, 3, 5–8, 11, 12, 16–21, 23, 30–35, 37–41, 43, 64, 67–75, 77–79, 82, 83, 85, 86, 142, 157, 159, 160, 167, 168, 171, 172, 178–180, 183, 189, 191–193, 196 FE Finite Elements. 5, 7, 22, 25, 27–32, 38–41, 44–47, 49, 52, 54, 64, 70, 72, 77, 79, 82, 85, 121–123, 125, 136, 145, 152, 153, 157, 159, 162, 165, 169, 177, 180, 183, 185, 186, 189, 191, 193 FEA Finite Element Analysis(es). 1–3, 5, 7, 12, 22, 28, 30–32, 40, 43, 45, 46, 49, 57, 58, 60, 64, 67–70, 72, 74–79, 83, 85, 87–89, 96, 117, 119–121, 123, 141, 156, 160, 168, 172, 173, 176, 177, 180, 191 FEM Finite Element Models. 1, 22–24, 26, 27, 29, 44, 46, 69–72, 76, 79, 82, 88, 121, 147, 183 KBE Knowledge Based Engineering. 168 MAT Medial Axis Transform. XV, 44, 47–49, 53–57, 60, 126, 128, 131–133, 137, 145, 166, 195 xxiiiAcronyms PDMS Product Data Management System. 72 PDP Product Development Process. 1–3, 5–7, 9, 12, 19, 32, 39, 44, 46, 88, 89, 180 PLM Product Lifecycle Management. 6, 16, 21, 32, 72 xxivIntroduction Context of numerical certification of aeronautical structures Aeronautical companies face increasing needs in simulating the structural behavior of product sub-assemblies. Numerical simulation plays an important role in the Product Development Process (PDP) of a mechanical structure: it allows engineers to numerically simulate the mechanical behavior of this structure submitted to a set of physical constraints (forces, pressures, thermal field, . . . ). The local or global, linear or nonlinear, static or dynamic analyses of structural phenomena using Finite Element Analysis(es) (FEA) simulations are now widespread in industry. These simulations play an important role to reduce the cost of physical prototyping, to justify and certify structural design choices. As an example, let us consider the last Airbus Program A350. There, a major physical test program is still required to support the development and certification of the aircraft. However, it is based on predictions obtained from Finite Element Models (FEM). Consequently, the test program validates the internal load distributions which have been computed numerically. Today, FEAs are not restricted anymore to the simulation of components alone; they can be applied to large assemblies of components. Simulation software capabilities associated with optimized mathematical resolution methods can process very large numbers of unknowns derived from their initial mechanical problems. Such simulations require few days of computations, which is an acceptable amount during a product development process in aeronautics. However, it is important to underline that these numerical simulations require the setting of a mathematical model from the physical object or assembly being analyzed. On purpose, the FEA method incorporates simplification hypotheses applied to the geometric models of components or assemblies compared to their real shapes and, finally, produces an approximate solution. To obtain the most faithful results with a minimum bias within a short amount of time, engineers are encouraged to spend a fair amount of time on the generation of simulation models. They have to stay critical with respect to the mathematical method used, the consequences of simplification hypotheses, in order to understand the deviations of the simulation model compared to the real tests to judge the validity of the simulation results. 1Introduction Some limits faced in structural simulations Numerical simulations of assemblies remain complex and tedious due to the preprocessing of assembly 3D models available from Digital Mock-Ups(DMUs) that stands as the virtual product reference in industry. This phase is highly time consuming compared to the numerical computations’ one. In the past, the use of distinct software tools between the design and simulation phases required generating once again the Computer Aided Design (CAD) geometry of a component in the simulation software. Today, the development and use of DMUs in a PDP, even with a rather small assembly models, bring 3D models at hand for engineers. The concept of DMU was initially developed for design and manufacture purposes as a digital representation of an assembly of mechanical components. Consequently, DMUs are good candidates to support digital analyses of several PDP processes, e.g. part assembly ones. In industry, DMUs are widely used during a PDP regarded as the virtual product geometry reference. This geometric model contains a detailed 3D representation of the whole product structure that is made available for simulation engineers. To prepare large sub-structure models for simulation, such as wings or aircraft fuselage sections; the DMU offers a detailed and precise geometric input model. However, speeding up the simulation model generation strongly relies on the time required to perform the geometric transformations needed to adapt a DMU to FEA requirements. The pre-processing phase implies reworking all DMU 3D data to collect subsets of components, to remove unnecessary or harmful areas leading to simplified shapes, to generate adequate FE meshes, to add the boundary conditions and material properties as needed for a given simulation goal. All these operations, the way they are currently performed, bring little added value to a PDP. Currently, time and human resources involved in pre-processing CAD models derived from DMUs into FE models can even prevent engineers from setting up structural analyses. Very tedious tasks are required to process the large amount of DMU components and the connections between them, like contact areas. Commercial software already provide some answers to the interactions between design and behavioral simulation processes for single components. Unfortunately, the operators available are restricted either to interactive geometric transformations, leading to very tedious tasks, or to automated simulation model generation adapted to simple models only. A rather automated generation of complex assembly simulation models still raises real difficulties and it is far too tedious to process groups of components as well as sub-assemblies. As detailed in Chapter 1, these difficulties arise because shape transformations are needed since designers and simulation engineers work with different target models, resulting in the fact that DMUs cannot be easily used to support the preparation of structural analysis models. Scientific research work has mainly focused on the use of global geometric transformations of standalone CAD components. Few contributions have addressed the au- 2Introduction tomation of assembly pre-processing (see Chapter 2) leaving engineers to interactively process each assembly component. Aeronautical structures are particularly complex to transform due to the large amount of transformations on hundred thousands of parts and interfaces joints. These operators are still not generic enough to be adapted to engineers’ needs, especially when idealizations of components or assemblies must be produced. Indeed, it still is a common practice for engineers to generate interactively their own models because preparation operations are still not generic enough. Consequently, some simulations are not even addressed because their preparation time cannot fit within the schedule of a PDP, i.e. simulation results would be available too late. Work Purposes To reach the needs of large assembly simulation model preparation, improvements in processing DMUs are a real challenge in aircraft companies. The contributions in this thesis are mainly oriented toward the transformation of 3D CAD models extracted from a DMU, and their associated semantics, for Finite Element analysis of large assembly structure. To handle large models, it is mandatory that the proposed principles and operators speed up and to automate as much as possible the DMU transformations required. This work will be guided by input DMU data defining the exact content of the simulation models to be built and will use mechanical and geometric criteria for identifying the necessary geometric adaptation. This research thesis is divided into 6 chapters: • Chapter 1 describes the current practices in aeronautical industries about the generation, from DMUs, of geometric models supporting the generation of simulation models. It will define the different geometric entities used in CAD software as well as the notion of mechanical analysis using the FE method. Also, it will detail the problematic of DMU geometry preparation for FE assembly models; • Chapter 2 is a current bibliographical and technological status on the methods and tools proposed for the preparation and adaptation of geometric models for FEA. This analysis will consider the review of component pre-processing as well as their assembly counterpart; • Chapter 3 presents the proposed contribution to assembly pre-processing based on the recommendations of chapter 1 and the analysis of chapter 2. This approach uses, as input model, an enriched DMU at an assembly level with geometric interfaces between its components, functional properties of these components and, at the component level, a structured volume segmentation using graph structure. From this enriched model, an analysis framework is able to connect the simulation hypotheses with the shape transformations. This chapter will also identify the geometric operators segmenting a component to transform it in accordance with the user’s simulation requirements; 3Introduction • Chapter 4 exposes the principles of the geometric enrichment of a component using a construction graph. An algorithm extracting generative processes from B-Rep shapes will be detailed. It provides a powerful geometric structure containing simple primitives and geometric interfaces between them. This structure contributes to an analysis framework and it remains compatible with an assembly structure containing components and geometric interfaces; • Chapter 5 details the analysis framework through the exploitation of the construction graph to analyze the morphology of component. Then, geometric operators are specified that can be robustly applied to automate components’ and interfaces’ shape transformations during an assembly preparation process; • Chapter 6 extends this approach toward a methodology using the geometric operators previously described that performs idealizations and template based transformations of groups of components. Results of this methodology will also be presented to illustrate it through aeronautical examples that use the transformation operators developed; 4Chapter 1 From a Digital Mock Up to Finite Element Assembly Models: Current practices This chapter presents the problematic of DMU adaptation for the generation of Finite Elements (FE) assembly models. In a first step, the technical context is addressed through the description of the DMU data content. This description deals with the geometrical entities and concepts used to represent 3D CAD components as well as with the representation of assemblies currently available before DMU pre-processing. Then, the notion of mechanical analysis using the FE method is defined and the main categories of geometric models within FEA are described. The analysis of current industrial processes and practical DMU data content highlights the issues regarding assembly simulation model preparation and points out the lack of tools in industrial software to reach the level of abstraction required by FEA, especially when idealizations are needed. The main time consuming shape transformations and the missing information about components’ interfaces in DMUs are identified as a starting point to improve the robustness of DMU pre-processing. 1.1 Introduction and definition DMU concept To speed up a Product Development Process (PDP), as stated in the introduction, aeronautical, automotive and other companies face increasing needs in setting up FE simulations of large sub-structures of their products. Their challenge covers the study of standalone components but it is now expanding to simulate the structural behavior of large assembly structures containing up to thousands of components. Today, aeronautical companies have to manage a range of products during their entire lifecycle, from their early design phase to their manufacture and even up to their destruction and recycling. The corresponding digital data management concept 5Chapter 1: From a DMU to FE Assembly Models: current practices Design Manufacturing Pre-Sales Maintenance Industrial Means Digital Mock-Up (DMU) as a Master Figure 1.1: The Digital Mock-Up as the reference representation of a product, courtesy of Airbus Group Innovations. aggregating all the information about each product is called Product Lifecycle Management (PLM). This concept includes the management of a digital product definition for all the functions involved in a PDP. To replace a physical mock up by its digital counterpart, the concept of a virtual representation of a product has been developed, i.e., the Digital Mock Up (DMU) (see Figure 1.1). As Drieux [Dri06] explained, a DMU is an extraction from the PLM of a product at a given time. The DMU was initially created for design and manufacture purposes as a digital representation of an assembly of mechanical components. Consequently, DMUs are convenient to support a virtual analysis of several processes, e.g., part assembly ones. For instance, DMU may be extracted at the manufacturing level, which let engineers to quickly generate and simulate trajectories of industrial robots and to set and validate assembly tolerances. During project reviews of complex products such as an aircraft, DMUs contribute to the technical analysis of a product, as conducted by engineering teams. Connected to virtual reality technology, a DMU can be at the basis of efficient immersive tools to analyze interferences among the various subsystems contained into the corresponding product [Dri06, IML08]. During the design phase, the DMU is considered as the reference geometry of the product representation. It provides engineers all the digital information needed during their PDP. The various CAD models representing different stages of the product during its development or meta data related to specific applications such as manufacturing are 6Chapter 1: From a DMU to FE Assembly Models: current practices examples of such information. The development and use of DMUs in a PDP bring 3D assembly models at hand for engineers. Because this reference model contains detailed 3D geometry, it offers new perspectives for analysts to process more complex shapes while speeding up their simulation model generation up to the FE mesh. However, speeding up the simulation model generation strongly relies on the time required to perform the geometric transformations needed to adapt the DMU to FE requirements. In order to understand the challenges involved in the preparation phase from DMUs of large sub-structure models for FE simulations, it seems appropriate to initially present the various concepts and definitions related to the Finite Element Analysis (FEA) of mechanical structures as well as those related to the current models and information available in DMUs. This chapter describes the current practices regarding shape transformations needed to generate the specific geometric models required for FEA from a DMUs model. Starting from the theoretical formulation of a mechanical analysis to the effective shape transformations faced by engineers to generate FE models, this chapter raises the time consuming preparation process of large assembly structures as an issue. This is detailed at section 1.5 and refers to the identification of key information content during current FE simulation preparation processes from two perspectives: a component point of view as well as an assembly point of view. In the last section 1.7, the research objectives are presented to give the reader an overview of the research topic addressed in this thesis. 1.2 Geometric representation and modeling of 3D components A DMU is straightforwardly related to the representation of the 3D components contained in the product. As a starting point, this section outlines the principles of mathematical and computer modeling of 3D solids used in CAD software. Also, it describes the common schemes available for designers to generate components through a construction process. Because a component is used in a DMU as a volume object, this section focuses on solids’ representations. 1.2.1 Categories of geometric families Prior to explanations about the common concepts for representing 3D components, it is important to recall that the geometric model describing a simulation model contains different categories of geometric entities used in the CAD and FEA software environments. These entities can be classified, from a mathematical point of view, in accordance to their manifold dimension. 7Chapter 1: From a DMU to FE Assembly Models: current practices 0-dimensional manifold: Point These entities, the simplest geometric representation, are not intended to represent the detailed geometry of components. However, they are often used in structural analysis, as abstraction of a component, i.e., its center of mass or a key point of a component where concentrated forces are applied, . . . . They are also frequently encountered to represent interfaces between aeronautical systems and structures in a DMU. They are also the lowest level entity in the description of a component’s solid model. 1-dimensional manifold: Line, Circle, Curve These entities, such as lines, circles and more generally curves, are mainly involved in the definition of models of higher dimension like surfaces. In structural analysis, they represent long and slender shapes, e.g., components behaving like beams, with the complement of section inertia. During a solid modeling process, they are part of the definition of 2D sketches (see Figure 1.5 for an example of sketch based form feature), or as profile curves in other shape design processes. Also, they represent the location of geometric interfaces between components, e.g., the contact of a cylinder onto a plane. 2-dimensional manifold: Surface Surfaces are used to represent the skin, or boundary, of a 3D object. Initially, they were introduced to represent complex shapes of an object, commonly designated as free-form surfaces. Polynomial surfaces like B´ezier, B-Spline, NURBS (Non-Rational B-Spline), Coons surfaces are commonly used for modeling objects with curved surfaces and for the creation of simulation models, e.g., CFD simulations for aerodynamics or simulations using the isogeometric paradigm. Here, surface models will be essentially reduced to canonical surfaces, i.e., plane, sphere, cylinder, cone, torus, which are also described by classical implicit functions. This restriction is set for simplicity purposes though it is not too restrictive for mechanical components because they are heavily used. In structural analysis, using a surface model is frequent practice to represent idealized models equivalent a volume component resembling a sheet. The notion of idealization will be specified in subsection 1.3.2. Even if a surface model can represent complex shapes, they are not sufficient to represent a 3D object as a volume, which requires an explicit representation of the notion of inside, or outside. 3-dimensional manifold: Solid A solid contains all the information to define comprehensively the volume of the 3D object it represents. Based on Requicha’s mathematical definition [Req77, Req80], a solid is a subset of the 3D Euclidian space. Its principal properties are: • A solid have a homogeneous three dimensionality. It contains a homogeneous interior. Solid’s boundary cannot have isolated portions; 8Chapter 1: From a DMU to FE Assembly Models: current practices A Ç B A È B A - B A Ç* B A È* B A -* B Additional Face (a) (b) A B A B Figure 1.2: Boolean operator of two solids: (a) Conventional boolean operator produce additional face, unclosed boundary. (b) CAD uses regularized boolean operator producing valid solid • A solid must be closed. When applied to solid, rigid motions (translation, rotation) or operations that add or remove material, must produce others solids; • The boundary of a solid must determine unambiguously the interior and exterior of the solid. To describe a solid, topological properties are mandatory in addition to the geometric entities defining this object. This requirement is particularly important when describing complex shapes because they are generated using a process that combines simple primitives to progressively increase the shape complexity until reaching the desired solid. Indeed, the principle of generation process exists for complex free-form surfaces is similar to that of complex solids. During the design process, the constructive processes used to combine elementary primitives are key information to enable efficient modification processes that are frequently required during a PDPIt is commonly admitted that 80% of the design time is spent on modifications processes. 1.2.2 Digital representation of solids in CAD Geometric modeling is the core activity of a CAD system. It contains all the geometric information describing 3D objects. Although there are various digital representations of 3D components falling into the category of solids, the two major representations used in CAD software are detailed in the following paragraphs. Constructive Solid Geometry (CSG) representation This representation designates Constructive Solid Geometry approaches devoted to the design and generation of 3D components. It is important to note that the ’usual’ set of Boolean operations cannot be directly applied on solid model. Otherwise, it would create invalid solids. As illustrated on Figure 1.2a, the conventional intersection 9Chapter 1: From a DMU to FE Assembly Models: current practices + - CSG Tree Resulting Solid (a) Face Edge Vertex B-Rep Decomposition (b) Figure 1.3: (a) Representation of the construction tree of a CSG component. (b) B-Rep solid decomposed into faces, edges and vertices (after Stroud [Str10]). operator applied to two solids would create a non regular solid with an isolated face, in Figure 1.2b the intersection of two cubes would generate a face and not a solid or the empty set. Therefore, it is necessary to define a new set of Boolean operations, the so-called regularized set intersection, union and difference (see Figure 1.2b). These operators are a modified version of the conventional operators and will be used in the algorithm presented in chapters 4 and 5. The CSG approaches represents a solid as a sequence of Boolean operations of elementary solids (cylinder, sphere, extrusion, revolution), i.e., primitives (see Figure 1.3a). The modeler stores primitives (cylinders, cubes, . . . ) and operations that have been applied to them, essentially regularized Boolean operations (union, intersection, difference). It can be visually represented as a tree structure but a CSG representation does not necessarily form a binary tree. The advantage of this model is to give a structure which can be easily modified, if the modification is compatible with the construction tree. The location of a simple primitive, e.g., a hole created with the subtraction of a cylinder, can be easily changed without modification of the CSG structure. Weaknesses are: the difficulty to represent complex geometric shapes with free-form surfaces, the complete tree re-evaluation under modifications and the non uniqueness of this tree with regard to a given shape. Boundary representation (B-Rep) In a B-Rep representation, the CAD kernel processes the skin of the object and the inside/outside of material. The B-Rep model contains the result of the operations, i.e., the information defining the shape of the solid (see Figure 1.3b). The volume of a solid is represented by a set of surfaces describing its boundary. Two categories of information are stored in a B-Rep model, a topological structure and a set of geometric entities: 10Chapter 1: From a DMU to FE Assembly Models: current practices • The geometric information: it consists into a set of surfaces defining the boundary of the solid and locating it in 3D space. These surfaces are bounded by trimming curves; • The topological information: this datastructure enables the expression of the mandatory topological properties, i.e., closure, orientation, that leads to the description of shells, faces, wires, edges, vertices, expressing the adjacency relationships between the topological entities. It can be represented using incidence graphs such as face-edge and edge-vertex graphs. In a B-Rep model, the set of surfaces is closed and Euler operators express the necessary conditions to preserve the consistency of a solid’s topology during modifications. The advantage of this representation holds in its ability to use non-canonical surfaces, i.e., NURBS, allowing a user to represent more complex shapes than CSG representation. Among the disadvantages of B-Rep models, the representation of the solid’s boundary contains information only about its final shape and this boundary is not unique for given shape. Today, the B-Rep representation is widespread in most of CAD geometric modelers and it is associated with a history tree to enable the description and use of parametric models. Nowadays, CAD modelers incorporate the B-Rep representation as well as Boolean operators and the B-Rep representation is the main representation used in aeronautical DMUs. In this thesis, the input CAD model of a 3D component is considered as extracted from a DMU and defined as a solid via a B-Rep representation. Representation of manifold and non-manifold geometric models To understand the different properties used in CAD volume modelers and Computer Aided Engineering (CAE) modelers, the notions of manifold solid and non-manifold objects have to be defined. One of the basic properties of a CAD modeler representing solids is that the geometric models of 3D components have to be two-manifold to define solids. The condition for an object to be two-manifold is that, ’at every point of its boundary, an arbitrary small sphere cuts the object’s boundary in a figure homomorphic to a disc’. This condition ensures that a solid encloses a bounded partition of the 3D space and represents a physical object. Practically, in a B-Rep representation, the previous condition reduces partly to the another condition at every edge of a manifold solid where it must be adjacent to two faces exactly. Because a solid is a two-manifold object, its B-Rep model always satisfies the Euler-Poincar´e formula as well as all the associated operators performing the solid’s boundary transformations required during a modeling process: v − e + f − h = 2 ∗ (s − g) (1.1) where v, e, f, h, s and g represent the numbers of vertices, edges, faces, hole-loops and the numbers of connected components (shells) and the genus of the solid, respectively. 11Chapter 1: From a DMU to FE Assembly Models: current practices Non-Manifold Connection Surface Volume Line Figure 1.4: Examples of non-manifold geometric models. As a difference, an object is said to be non-manifold when it does not satisfy the conditions to be a manifold. To address the various needs of object representation, the concept of manifold has been extended to represent a wider range of shapes as needed through a PDP. As illustrated in Figure 1.4, a non-manifold geometric modeling kernel incorporates the ability to describe geometric regions of different manifold dimensions, connected or not along other geometric regions of lower manifold dimensions. Consequently, an edge can be adjacent to more than two faces. However, some basic properties of solids are no longer valid, which increases the difficulty in defining the consistency of such models. In the context of the Computer Aided Design to Finite Element Analysis(es) (CAD-FEA), this also referred to as ‘cellular modeling’ [TNRA14] and few geometric modeling kernels, natively incorporate this category of models [CAS14] These models are commonly used in structural analysis where surfaces often intersect along more than one edge (see Figure 1.11c). Therefore, CAE software proposes datastructures to generate non-manifold geometry. However, most of the commercial FEA softwares contains manifold geometric modelers with extensions to be able to model non-manifold objects, which does not bring the desired end-user performances. Here, the input CAD models are considered as manifold solids and the generated models for FEA can be non-manifold. 1.2.3 Complementary CAD software capabilities: Feature-based and parametric modeling CAD software incorporate a volume geometric modeling kernel to create manifold solids and a surface modeler to enable the generation of two-manifold objects with free-form surfaces, i.e., two-manifold with boundary objects. CAD tools are essential for the generation of DMU because they are used to design and to virtually represent the components of a product. In addition to the presentation of the geometric models used in CAD software, (see Section 1.2.2), it is also crucial to mention some CAD practices contributing to the design of mechanical components. This will help understanding the additional information associated to B-Rep models which are also available in a DMU. 12Chapter 1: From a DMU to FE Assembly Models: current practices Concept of feature: As stated in Section 1.2.2, B-Rep models only describe the final shape of solids. To ease the generation process of 3D mechanical models and to generate a modeling history, CAD software uses pre-defined form features as primary geometric regions of the object [Sha95]. A feature is a generic concept that contains shape and parametric information about a geometric region of a solid. The features can represent machining operations such as holes, pockets, protrusions or more generic areas contributing to the design process of 3D components like extrusions or revolutions. Generative processes: The following chapters of this thesis use the term ”generative processes” to represent an ordered sequence of processes emphasizing the shape evolution of the B-Rep representation of a CAD component. Each generative process corresponds to the generation of a set of volume primitives to be added or to be removed from a 3D solid representing the object at one step of its construction. Features Taxonomy: The features of solid modeling processes can be categorized into two sets [Fou07]: • Features independent from any application: – Geometric entities: points, axes, curves, sketches; – Adding/removing material: extrusion, revolution, sweeping. Boolean operators; – Surface operations: fillets, chamfers, fillings; – Repetitions, symmetries. • Features related to an application (hole drilling, sheetmetal forming, welding). As an example, a material addition extrusion feature is illustrated in Figure 1.5. Its generative process consists in drawing a 2D sketch using lines, circles or planar curves to define a planar face and then, to submit it to a translation using an extrusion vector to generate a volume. The principle of feature-based modeling is to construct a part ”from a simple shape to a complex one” and it is similar to the CSG principle. As illustrated in Figure 1.5 and, more generally, in Appendix A where a complete part design is represented, the user starts with the design of simple volumes to represent the overall solid’s shape of a component and to add progressively shape details such as fillets and holes to reach its final shape. This qualitative morphological approach to a solid’s construction process 13Chapter 1: From a DMU to FE Assembly Models: current practices can be partly prescribed by company modeling rules but a user stays particularly free to choose the features and their sequence during a construction process. This is a consequence of a design process enabling the user to monitor step by step, with simple features, the construction process of a solid. In CAD software, the sequence of features to create a component is represented and stored in a construction tree (see Figure 1.5). Dependences between features and construction tree: The construction tree of a solid is connected to the notion of parametric modeling. In addition to the feature concept, parametric modeling has been introduced in CAD software to enable the regeneration of a solid when the user wants to apply a local shape modification. With parametric modeling, the user input defines the geometric constraints and dimensions of a feature in relation with others. In most cases, the localization of a new feature is not applied in the global coordinates system of the solid. A feature uses an existing geometric entity of the solid, e.g., a planar face, as basis for a new sketch (see Figure 1.5). The sketching face creates another dependency between features in addition to the parent/ child relationships that are stored in the construction tree. Conclusion Solid modeling is a way to represent a digital geometric model of a 3D component. The B-Rep representation used in commercial CAD software allows a user to design complex shapes but it provides only a low level volume description because it does not give a morphological description of a solid. As a complement, feature modeling is easy to learn for a CAD user because it allows him, resp.her, to naturally design mechanical components without an in-depth understanding of CAD modeling kernel. Construction trees structure a 3D object using simple feature models, extending the use of B-Rep models with a history representing their construction processes. Parametric modeling is also efficient to produce a parameterized representation of a solid to enable easy modifications of some of its dimensions. 14Chapter 1: From a DMU to FE Assembly Models: current practices 16 100 100 50 Extrusion Extrusion Cut Extrusion Fillet Fillet Hole Mirror Figure 1.5: CAD construction process using form features. The modeling sequence is stored in a construction tree. 15Chapter 1: From a DMU to FE Assembly Models: current practices X 21 X 24 X 45 X 4 X 2 Figure 1.6: Example of an aeronautical CAD assembly: Root joint model (courtesy of Airbus Group Innovations). 1.3 Representation and modeling of an assembly in a DMU Any mechanical system is composed of different components assembled together with mechanical joints. This section aims at presenting how an assembly is represented and created in a DMU. It underlines how an assembly is processed with a non-formal conventional representation. In particular, this section deals with the current content of a DMU extracted from a PLM in an aeronautic industrial context (data that are actually available for structural simulation). 1.3.1 Effective DMU content in aeronautical industry Assembly structure in a CAD environment In a CAD software, an assembly is a structure that organizes CAD components into groups. Each component contains the geometrical and topological data as described in Section 1.2.2. Then, the component is instantiated in the assembly structure as many times as it should appear. The Figure 1.6 represents an aeronautical structure (wing fuselage junction of an aircraft) with a sub-assembly for each composite part and instantiation of standard components such as screws and nuts. 16Chapter 1: From a DMU to FE Assembly Models: current practices To create an assembly structure in 3D, the user iteratively positions components in 3D space relatively to other components, (axis alignment of holes, surface mating, . . . ). These connections between components, called position constraints, connect degrees of freedom from each component involved in the corresponding constraints. However, these constraints may not represent the common geometric areas connecting the corresponding components. For instance, to connect a screw with the through hole of a plate, a coaxiality constraint can be applied between the cylindrical surface axis of the screw and the hole axis, independently from any contact between the surfaces. The radii of the cylindrical surfaces of these two components are not involved, i.e., any screw can be inserted in the hole. This does not match the reality and can lead to assembly inconsistencies. In a CAD environment, the assembly structure is stored in a product tree which connects each of its components to others with assembly constraints. On top of the B-Rep representation, each component can contain complementary information such as a name or a product reference, a contextual description of the component’s function, modification monitoring information, color, material designation. During a product design process, a CAD environment also offers capabilities to share external references to other components not directly stored in a product structure, to parameterize components’ dimensions with mathematical formulas, . . . DMU evolution during a PDP All along the product construction process in a PDP, its digital representation evolves. The information related to the product definition such as its 3D geometric representation gets modified. In addition, the product development process is shared among several design departments that address different engineering areas: the product mechanical structure, electrical systems, . . . All these areas have to share their design information and sub-assemblies definitions. Whether it is geometry or parameters, this information should be integrated in a common product representation. The DMU concept is a means to support the geometric definition and evolution of components while maintaining the product assembly updated. As an example, depending on the maturity of the product, a DMU can be reduced to a simple master geometry at the early stage of the product design using functional surfaces or, it can contain the full 3D representation of all its components as required for manufacturing. All these needs require that a Product Data Management System (PDMS) be used to support the definition and evolution of a DMU. The PDMS structures the successive versions, adaptions to customer requirements as well as the various technical solutions that can be collectively designated as variants. A product is represented as a tree referencing the CAD components and their variants. The various product sub-assemblies of the design team, initially created in a CAD environment, are transferred and centralized in the PDMS. It is based on this environment that an engineer can formulate a request to extract a DMU used as input model for his, resp. her, simulations. 17Chapter 1: From a DMU to FE Assembly Models: current practices Complex details Complex component geometry Large number of junctions in aeronautical products DMU reduced to a set of individual component, no positionning constraints Size constraint (large number of components) Various categories of Bolted junctions Figure 1.7: Example of complex DMU assembly from Alcas project [ALC08] and Locomachs project [LOC16]. The DMU content and management in the aeronautical industry: a pragmatic point of view. Today, as described previously, a DMU stands for the reference geometric representation of a product used by structural and systems engineers. A DMU is the input model to generate their simulation models. In practice however, the information of a DMU extracted from the PDMS reduces to a set of CAD components positioned in 3D space with respect to a global reference frame and a tree structure representing a logical structure of this product [Fou07, FL∗10]. This fair loss of information originates from: • The size and the fragmented location of a DMU: it contains a large amount of components (see Figure 1.7) created by different design teams during a PDP, e.g., in aeronautics, the extraction of a DMU from the PDMS requires one day (no centralized data); • The robustness of a DMU: Positioning constraints between components are not available. Components are standalone objects in a common reference frame. A DMU is an extraction from the PDMS at a given time. During the evolution of a PDP, engineers cannot maintain the interfaces between the geometric models 18Chapter 1: From a DMU to FE Assembly Models: current practices of the components; the corresponding geometric constraints, if they were set, have to be removed because their management becomes too complex. As an example, if a component is removed, the removal of its corresponding geometric constraints could propagate other modifications throughout the whole assembly. Additionally, the amount of geometric constraints gets very large for complex products and their consistency is still an open problem [LSJS13]. It can reach more than three hundreds for an assembly with less than fifty components. This is what motivates the solution to locate all components into a global coordinate system. Consequently, each component is positioned independently of the others, which increases the robustness of the DMU regarding to its modifications even though the consistency of the DMU becomes more difficult to preserve. As a result, if a product is complex and has a large amount of components created by different design teams during a PDP, the PDMS does not contain information specifying assemblies. Information about proximity between components is not available. The relational information between parts in an assembly created in a CAD environment, e.g., the assembly constraints, is lost during the transfer between the CAD environment and the PDMS. The DMU is restricted to a set of individual CAD components and a tree decomposition of a product. As Drieux explained in its DMU analysis [Dri06], a DMU is a geometric answer to design specifications, it does not contain multiple representations adapted to the various users’ specifications during a PDP, including the structural analysis requirements. 1.3.2 Conventional representation of interfaces in a DMU In order to carry on the pragmatic analysis of a configuration where a simulation engineer receives a DMU as input model, this section defines the notion of assembly interfaces between components and their conventional representations in industry. Lacking conventional representation of components Shahwan et al. showed [SLF∗13] that the shapes of digital components in a DMU may differ from the shape of the physical object they represent. These differences originates from a compromise between the real object shape that can be tedious to model and the need for their shape simplifications to ease the generation of a DMU. This is particularly true for standard parts such as components used in junctions (bolted, riveted). Regarding their large number, each geometric detail, e.g., a threaded area, are not represented because it would unnecessarily complicate the DMU without improving its efficiency during a design process. Since there is no standard geometric model of assembly components used in 3D junctions, each company is likely to set its own representation. As illustrated in Figure 1.8, in large aeronautical DMUs, bolted junctions as well as 19Chapter 1: From a DMU to FE Assembly Models: current practices Line to highlight The head position Line defining the shank of the fasterner Figure 1.8: Representation of a bolted junction in a structural DMU of an aircraft. riveted junctions may be represented with a simplified representation defined with two perpendicular lines. This representation is sufficient to generate an equivalent volume model using basic information of bolt type, nominal diameter and length. However, no information exists about the connections between the bolt and the junction’s components the bolt is related to. There is neither a logical link between the screw and nut with the plates they connect nor a geometric model of the interface between the screw and nut forming the junction. More generally, the lack of geometric interface exists for every interface between assembly components. As explained at Section 1.5.3, this poor representation complicates the generation of equivalent simulation models. This complexity issue applies also to deformable components1, which are represented under an operating configuration. Definition of interfaces between components Based on the description of the DMU content given at Section 1.3.1, there is no explicit information about the geometric interaction between components. Even the content of geometric interfaces between components can differ from one company to another. In this thesis, the definition of Conventional Interface (CI) of L´eon et al. [FL∗10, LST∗12, SLF∗13] is used. From their DMU analysis, they formalized the representation of conventional interfaces between components. To cover all the possible interactions between two B-Rep objects C1 and C2, they classified the CIs into three categories (see Figure 1.9): 1. Contacts: these are configurations where the boundary surfaces of the components C1 and C2 and relatives positions of these components are such that: ∂C1 ∩ ∂C2 = S �= ∅ and ∂C1 ∩∗ ∂C2 = ∅ where ∂C1 and ∂C2 represent the boundary surfaces of C1 and C2, respectively. S refers to one or more geometric 1Here, deformable components refer to a category of components with plastic or rubber parts whose displacements under loading conditions are of a magnitude such that the designer take them into account when setting up the DMU. This is to oppose to metal parts where their displacements are neglected. 20Chapter 1: From a DMU to FE Assembly Models: current practices Surface Interface δC ∩ δC Volume Interface δC ∩* δC Contact Interference Clearance C1 C2 1 2 1 2 Figure 1.9: Classification of Conventional Interfaces (CI) under contact, interference and clearance categories. elements that can be surface-type, line-type or point-type. Figure 1.9a illustrates contacts between CAD components; 2. Interferences: these are configurations where the boundary surfaces of the components C1 and C2 and the relative positions of these components are such that: ∂C1 ∩∗ ∂C2 = C12 �= ∅ where C12 is the intersection volume. Interferences are detected and analyzed during a DMU review to ensure that there is no physical integration problem between components. However, according to L´eon et al., interferences, also named clashes, may occur when components’ shapes are simplified with respect to their physical models (see Figure 1.9b), or in case of incorrect relative positions of components. Interferences resulting from these partial positions make a DMU virtually inconsistent, which requires user’s analysis. Interferences between standard components generate specific classes of interferences, which is used to process DMUs in the present work; 3. Clearances: they represent 3D domains without a clear geometric definition, which is difficult to identify and to represent, (see Figure 1.9c). In this work, clearances are considered as functional clearances and are identified as design features. The concept of CI can be used in our assembly context, since it is independent from any modeling context. Section 3.3 explains how CI can be extracted from a DMU. Conclusion The development and use of DMUs in a PDP bring 3D models at hand for engineers. The DMU extracted from a PLM contains the complete geometric representation of the product using a B-Rep representation and CAD construction trees. Complex shapes are directly available without having to be rebuilt them in a simulation software environment. However, due to considerations of robustness and size, a DMU is reduced 21Chapter 1: From a DMU to FE Assembly Models: current practices to a set of isolated components without an explicit geometric representation of the interfaces between them. 1.4 Finite Element Analysis of mechanical structures This section aims at introducing some principles of the Finite Element Method (FEM) for structural analysis. Because the scope of this thesis covers the pre-processing of geometrical data for FEA, this section does not detail the resolution method but focuses on the input data required by FEA. First of all, it introduces the concept of mechanical model for FEA. Then, it enumerates the data needed for FEA ranging from the geometric model of each component using a FE mesh to the representation of connections between meshes as required to propagate displacements and stress fields over the assembly that stand for the mechanical models of the interfaces between components. Subsequently, it describes the industrial approach to various mechanical analyses of an aircraft structure at different levels of physical phenomena from large coarse models representing global deformations to detailed small assemblies devoted to the analysis of stress distributions, as examples. Within each category, the geometric models representing the components and their connections are described. 1.4.1 Formulation of a mechanical analysis The goal of a numerical simulation of the mechanical behavior of a structure is to anticipate or even supersede a physical test. It allows engineers to simulate a mechanical behavior of a virtual structure, i.e., without the existence of the real structure. The mechanical analysis process Independently from a resolution method, e.g., the finite element analysis or the finite difference method, as stated in Fine [Fin01], the mechanical analysis process may be split into three main steps (see Figure 1.10): 1. The formulation of the model behavior: Just as in a physical test, each virtual simulation has a specific objective: a simulation objective (type of behavior to be observed such as displacements in a particular area, maximal loads under a prescribed mechanical behavior, accuracy of the expected results, . . . ). As Szabo [Sza96] describes, the first formulation phase consists in building a theoretical model integrating the mechanical behavior laws representative of the physical system. The analyst specifies and identifies the key attributes of the physical system and the characteristic values of the mechanical behavior: the simulation hypotheses. Then, the analyst applies a 22Chapter 1: From a DMU to FE Assembly Models: current practices Pre-processing Formulate the model mechanical behaviour from hypotheses relative to the simulation objective. Adapt the input DMU data (geometry, physical properties, boundary condition) to resolution method requirements. 01 step Apply the resolution method (e.g. Finite Element Method) to the simulation model and obtain results Resolution Analyse the results. Determine the accuracy, discuss with design team, validate and integrate in the PDP Post-processing. 03 step 02 step Figure 1.10: Process flow of a mechanical analysis. set of modeling rules related to the simulation hypotheses in order to create a reduced numerical simulation model ready to be sent to the resolution system. The choice of the modeling rules implies decisions on the mechanical behavior of the structure. When defining the shape of the structure derived from its real shape (see Section 1.4.2) and setting up the constraints and hypotheses related to analytical resolution methods, the mechanical engineer limits its range of observations to the simulation objectives. In practice, the formulation of the model behavior may be viewed as the transformation of the DMU input, which is regarded as the digital representation of the physical structure, into the numerical simulation model. Section 1.5 gives details of this crucial integration phase; 2. The resolution of the model behavior: Once the simulation model is generated, the mechanical engineer launches the resolution process. This phase is performed automatically by the CAE software. Currently, the main resolution method used for structural analysis is the FEM, which sets specific constraints at the level of the mesh generation process; 3. The results analysis: Once the resolution process has ended, the mechanical engineer has to analyze the results, i.e., the solutions fields computed and the output parameters that can be derived from these fields. He, resp. she, determines the solutions’s accuracy, discusses with design teams to decide about shape modifications, validates and integrates the results in the PDP. 23Chapter 1: From a DMU to FE Assembly Models: current practices CAD Model Volume Mesh Shell Mesh (a) (b) (c) Figure 1.11: Example of FE mesh models: (a) CAD initial model of a structure, (b) Meshed model with 3D volume elements,(c) Meshed model with idealized 2D shell elements. 1.4.2 The required input data for the FEA of a component Although other resolution methods exist (analytical or numerical, e.g., finite difference method), in mechanical simulation, the FEM is a method widespread in industry. The FEM is a general numerical method dedicated to the resolution of partial differential equations and its applicability is not restricted to structural simulation, it covers thermal, electromagnetism, thermodynamics, . . . Many documents exist which relate in detail the principles of this method, reference books of Zienkiewicz [ZT00], Bathe [Bat96] are among them. This section concentrates on the data requirements of the method to formulate a simulation model and addresses pragmatically how the engineer can collect/generate these data. Geometry: Finite Element Mesh To solve partial differential equations applied to a continuum, i.e., a continuous medium, the FEM defines an equivalent integral formulation on a discretized domain. This discrete domain is called a Finite Element Mesh and is produced by decomposing the CAD model representing the structure into geometric elements of simple and well known geometry, i.e., triangles, tetrahedra forming the finite elements, . . . , whose individual physical behavior reduces to a simple model (see Figure 1.11). When the structure is subjected to a set of physical constraints, the equilibrium equations of the overall structure percolate through all the elements once they have been assembled under a matrix form. The model size, i.e., the number of finite elements, has a direct influence on the computation time to obtain the solution fields and it may introduce approximation errors if not set correctly. The engineer must efficiently identify the right level of mesh refinement related to the mechanical phenomenon he, resp. she, wants to observe. In practice, to ease the meshing phase, the input CAD geometry is simplified to adapt its shape to the simulation objectives and the mesh generation requirements. If this 24Chapter 1: From a DMU to FE Assembly Models: current practices Finite Element Geometry Morphological properties 1D-element: Beam << L l ,l << L 1 2 L l2 l1 L Long and slender sub domain having two dimensions that are small enough compared to the third one. These two dimensions define the beam section parameters. 2D-element: Shell, plate, membrane e l 1 l 2 2 e << l ,l 1 Thin sub domain having one dimension which is small compared to the two others. This dimension defines the thickness parameter. 3D-element: Volume Sub domain without any specific morphological property that must be processed with a three-dimensional mechanical behavior. Table 1.1: Categories of Finite Elements for structural analyses. simplification is carried out properly, it would not only generate a good mesh but this mesh is obtained quickly also. This simplification phase incorporates shape transformations and all their inherent issues are discussed in Section 1.5. Finite Element Choice and families When setting up a simulation model, the choice of finite elements is essential. Each finite element has an approximation function (polynomial function) which has to locally approximate at best the desired solution. As explained in Section 1.4.1, it is the engineer who chooses the type of finite element in adequacy with the prescribed simulation objectives. There are many types of finite elements to suit various applications and their selection is conducted during the early phase of the CAD model pre-processing. It is a matter of compromise between the geometry of the components, the desired accuracy of the simulation results as well as the computation time required to reach this accuracy. Figure 1.1 presents the main categories of finite elements classified in accordance with their manifold properties (see Section 1.2.1). Idealized elements Based on the shell theory of Timoschenko [TWKW59], specific finite elements are available in CAE software to represent a thin volume, e.g., shell elements. These elements can significantly reduce the number of unknowns in FE models, leading to 25Chapter 1: From a DMU to FE Assembly Models: current practices a shorter computation time compared to volume models. Also, using shell elements rather than volume ones gives access to different mechanical parameters: section rotation and stress distribution in the thickness is implicitly described in the element. Rather than discretizing a volume into small volume elements, it is represented by its medial surface (see Table 1.1 2D-element). The thickness becomes a numerical parameter associated with the element. Long and slender sub domains can be processed analogously. A beam element is well suited to represent these volume sub domains using an equivalent medial line (see Table 1.1 1D-element). From the sections of these volumes, their inertia parameters are extracted and they become numerical parameters assigned to the beam elements. Such elements imply a dimensional reduction of the initial volume, a 1-dimensional reduction for shells and 2-dimensional reduction for beams. This modeling hypothesis is called idealization. In a CAD-CAE context, the idealization refers to the geometric transformation converting a initial CAD solid into an equivalent medial surface or medial line which handles the mechanical behavior of a plate, a shell or a beam, respectively. This geometrically transformed model is called idealized model. Such an example is given on Figure 1.11c. Idealized sub domains are particularly suited to aeronautical structures, which contain lots of long and thin components (panels, stringers, . . . ). Using idealized representations of these components can even become mandatory to enable large assembly simulations because software license upper bounds (in terms of number of unknowns) are exceeded when these components are not idealized. However, Section 1.5.3 illustrates that the practical application of such an idealization process is not straightforward. The sub domains candidates for idealization are subjected to physical hypotheses: • The simulation objectives must be compatible with the observed displacements or stress field distributions over the entire idealized sub-domains, i.e., there is no simulation objective related to a local phenomenon taking place in the thickness or section of an idealized domain; • The sub domains satisfy the morphological constraints of idealization hypotheses, e.g., a component thickness must be at least 10 times smaller than the other two dimensions of its corresponding sub domain. Material data, loads and boundary conditions On top of the definition of a mesh geometry and its associated physical properties, e.g., sections, thickness, inertias, the FEM requires the definition of material parameters, loads and boundary conditions. Material data are associated with each finite element in order to generate the global stiffness matrix of the equivalent discretized sub domains representing the initial CAD model. The material properties (homogeneity, isotropy, linearity, . . . ) are themselves inherent to the model of constitutive law representative of the component’s mechanical 26Chapter 1: From a DMU to FE Assembly Models: current practices behavior. In case of a component made of composite material, the spatial distribution of the different layers of fibers should be carefully represented in the meshed model of this component. Loads and boundary conditions are essential settings of a mechanical simulation to describe the mechanical effects of other components on the ones of interest. Consequently, loads and boundary conditions are also part of the mechanical simulation pre-processing. A load can be a punctual force applied at a finite element node, a pressure distributed over the surface of a set of finite elements or even a force field, e.g., gravity force. Similarly, boundary conditions have to be attached to a particular set of nodes. Boundary condition settings interact with idealization processes (see Section 1.5.3), e.g., a force acting on an elongated side of a long slender volume is applied to a linear sequence of nodes of the idealized equivalent model defined as a beam model. Consequently, the boundary condition is also dimensionally reduced. In practice, an engineer defines the loads and boundary conditions areas over a component using partitioning operators prior to mesh the component. 1.4.3 FE simulations of assemblies of aeronautical structures The FEM issues have been extensively addressed for standalone components and integrated in a PDP. However, the FE simulation target is now evolving toward assembly structures, which are under focus in the next section. An assembly can be regarded as a set of components interacting with each other through their interfaces. These interfaces contribute to mechanical functions of components or sub-assemblies [BKR∗12, KWMN04, SLF∗13]. An assembly simulation model derives from shape transformations interacting with these functions to produce a mechanical model containing a set of sub domains discretized into FEs and connected together to form a discretized representation of a continuous medium. Interactions between sub domains in assembly models and associated hypotheses An assembly simulation model is not just a set of meshed sub domains positioned geometrically in a global coordinate system. These sub domains must be connected to each other to generate global displacement and stress fields over the assembly. To process every assembly interface (see Section 1.3.2), the user should decide which mechanical behavior to apply. Connections between components through their interfaces can be of type kinematic or physical and associated with physical data (stiffness, friction coefficient, . . . ) and material parameters, as necessary. The selection of connector types is subjected to user’s hypotheses regarding the relative behavior of sub domains representing the components, e.g., motion and/or relative interpenetration. Here, a sub domain designates either an entire component or a subset of it when it has been 27Chapter 1: From a DMU to FE Assembly Models: current practices With relative motion Without relative motion With interpenetration Deformable junctions models: used to model complete mechanical connections with deformable connectors elements, i.e., springs, dampers, . . . Rigid junctions models: used to model rigid connections, i.e., ball joints, welds, rivets, bolts, . . . Deformable fastener Hinge Junction Without interpenetration Normal and tangential contact: Used to model the normal and tangential stresses (friction) transmitted between two solids in contact during the simulation. Kinematic constraints: used to model relationships expressed as displacement/velocity between nodes, e.g., tie constraints, rigid body, . . . Contact Kinematic Constraint Table 1.2: Connector entities available in CAE software. idealized. The connection types are synthesized in Figure 1.2. The introduction in a FEA of a relative motion between components (contacts condition) considerably increases the complexity of this analysis. Indeed, a contact is not a linear phenomenon and requires the use of a specific nonlinear computational model, which slows down the simulation time. Setting up a contact is a strong hypothesis, which leads to the definition of the potential contact areas on both components. The sets of FEs in contact must be carefully specified. On the one hand, they should contain sufficient elements, i.e., degrees of freedom, to cover the local phenomenon while limiting the interpenetration between meshes. On the other hand, they should not contain too many elements to avoid increasing unnecessarily the computation time. During the early design phases, in addition to idealized models of components, it is common to perform simulations using simplified representation of junctions. In this case, the junction simulation objectives aim at transferring plate loads throughout the whole assembly and FE beam elements are sufficient to model the bolts’ behavior. In this configuration, the whole group of components taking part of the junction is replaced by a unique idealized model (see Figure 1.12). When applied to a FEA of large aeronautical structures, these models are called FE connections with fasteners and they are widely used to integrate component interactions with or without contact conditions. A fastener connection may be applied either to mesh nodes or may be 28Chapter 1: From a DMU to FE Assembly Models: current practices A Fastening point defined with region of influence FE Fastener Bolted Junction Beam connection B C A B C Region of Influence Figure 1.12: Example of a FE fastener simulating the behavior of a bolted junction using beam elements. mesh-independent, i.e., a point to point connection is defined between surfaces prior to the mesh generation process. Interactions between simulation objectives and the simulation model preparation process Simulation objectives drive the shape transformations of CAD solids and interact with the simulation hypotheses to model connections between components. During a PDP, simulations may be used at various steps of a design process to provide different informations about the mechanical behavior of components and sub systems. Based on Troussier’s [Tro99] classification, three simulation objectives are taken as examples in Table 1.3 to illustrate how simulation objectives influence the idealization process and the models of interactions between components as part of different simulation models. As an illustration of the influence of simulation objectives on the generation of different simulation models, Figure 1.13 presents two FE models derived from the same assembly structure of Figure 1.6: • A simplified model used at a design stage of pre-dimensioning and design choices (see Figure 1.13a). The simulation objective is to estimate globally the load transfer between plates through the bolted junctions and to identify the critical junctions. This model contains idealized components with shell FE in order to reduce the number of degrees of freedom. The junctions are modeled with FE fasteners containing beam elements and a specific stiffness model, i.e., the Huth’s law [Hut86]. This model contains 145 000 degrees of freedom and solving it takes 15 minutes, which allows the engineer to test various bolted junctions layouts, part thicknesses and material characteristics; • A full 3D FEM to validate design choices and check conformity with the certi- fication process prior to physical testing (see Figure 1.13b). The simulation objectives contain the validation of the load transfer distribution among the bolted junctions and the determination of the admissible extreme loads throughout the structure. To adapt the FE model to these simulation objectives while repre- 29Chapter 1: From a DMU to FE Assembly Models: current practices Element of a simulation process Pre-dimensioning and design choices Validation of mechanical tests Contribution to phenomenon understanding Simulation objectives Determine of the number of junctions, a component thickness or material, . . . Analyze the distribution of the stress field in a structure. Locate possible weaknesses. Understand the behavior of the structure to correlate with results after physical tests Internal Connections (Interfaces) Physical junction simpli- fied, no contact (rivet and pin models associated to fasteners). Physical junction simpli- fied or use of volume patch model. Contact interactions between components. Complete physical junction, use of volume model with contact interactions. Components’ shape Large number of components. Idealized: thin parts represented as shell models. Simplified (shell models) for large assemblies, volume model or mixed dimensional model accepted if rather small number of components. Small number of components. Complete volume model. Simulation model Linear Linear or nonlinear Nonlinear Table 1.3: Examples of interactions or even dependencies between simulation objectives and interfaces as well as component shapes. senting the physical behavior of the structure, an efficient domain decomposition approach [CBG08, Cha12] uses a coarse 3D mesh (tetrahedral FE) far enough from each bolted junction and a specific sub domain around each bolted junction (structured hexahedral mesh) where friction and pretension phenomena are part of the simulation model. Here, the objective is not to generate a detailed stress distribution everywhere in this assembly but to observe the load distribution areas among bolts using the mechanical models set in the sub domain, i.e., the patch, around each bolt. This model contains 2.1106 degrees of freedom and is solved in 14 hours. Only one such model is generated that corresponds to the physical test. Conclusion This section described the main categories of geometric models used in the FEA of structures. The simulation objectives drive the generation of the simulation models, i.e., FE meshes, boundary conditions, . . . , used as input data for solving the FE models. In addition to each component definition, a FE assembly must integrate connection models between meshed components. In Section 1.5, the different modeling hypotheses are analyzed with regard to the geometric transformations applied on the DMU input in order to obtain a new adapted CAD model that can be used to support the generation of a FE mesh model. 30Chapter 1: From a DMU to FE Assembly Models: current practices Full 3D FEM Volume Model Idealized FEM Shell model (a) (b) Fastener Refined Mesh in subdomains around junction Figure 1.13: Example of aeronautical FE models: (a) an idealized model with fasteners, (b) a full 3D model with a decomposition of plates around each bolted junction and a fine mesh in the resulting sub domain around each bolted junction. 1.5 Difficulties triggering a time consuming DMU adaptation to generate FE assembly models This section aims at illustrating the complexity of the generation of FE models from DMUs. It highlights the differences between a component’s shape in a DMU with respect to the level of abstraction required for a given FEA, especially when a FEA requires an idealization process. This section characterizes and analyzes some specific issues about assembly simulation model preparation and exposes the lack of tools in industrial software, which leads engineers to process manually all the shape transformations and strongly limit the complexity of assemblies that can be processed in a reasonable amount of time. 1.5.1 DMU adaption for FE analyses Today mechanical structures used in mechanical simulations contain a large number of components, each with a complex shape, binded together with mechanical junctions. In the aeronautic industry, the dimensioning and validation of such structures leads engineers to face two digital challenges: • The formulation of mechanical simulation models, as developed in Section 1.4, 31Chapter 1: From a DMU to FE Assembly Models: current practices that can simulate the mechanical behavior of a structure lead to the components’ dimensioning as well as the validation of the joint technologies selected (bolting, welding, riveting). During this phase, the engineers have to determine the most adapted simulation model regarding the physical phenomena to observe. They need to set up a FEA and its associated simulation hypotheses that produce the FE model which best meets the simulation objectives with the simulation software environment and technologies available. In practice, a simulation engineer supervises the DMU extraction processes to specify the components to be extracted and/or those having negligible mechanical influences with respect to the simulation objectives. Yet, this assessment is qualitative and is strongly dependent upon the engineer’s know-how. Another issue about data extraction stands in the component updates during the PDP. Any geometrical change of a DMU component has to be analyzed by the simulation engineer. Due to the tedious interactive transformations required, a trade-off has to be reached between the time required for the shape update in the FE model and the mechanical influence of the component with respect to the simulation objectives. Here, we face a qualitative judgment; • The generation of appropriate component shapes from a DMUs to support the generation of simulation models. As explained at Section 1.1, the DMU stands for the geometric reference of a product definition. Through the PLM software, engineers have typically access to DMUs containing the geometry of the 3D assembly defining the product and additional information, essentially about the material properties of each component. However, the extracted DMU representation is not directly suited for numerical FE simulations. Shape transformations are mandatory because designers and mechanical engineers work with different component shapes, resulting in the fact that a DMUs cannot directly support the mesh generation of structural analysis models. These models must meet the requirements of the simulation hypotheses, which have been established when setting up the simulation objectives and the specifications of the mechanical model as part of the FEA. The component shapes generated for the FEA have to be adapted to the level of idealization derived from the specifications of the desired mechanical model, the shape partitioning required for the application of the boundary conditions and loads as well as the level of details of the shape with respect to the FE size required when generating the FE mesh. During the generation of mechanical assembly models, the engineer must also take into account the total number of components, the representation of multiple interfaces between components and a higher level of idealization and larger details than for standalone components, to produce coarse enough assembly models. To increase the scope of physical assembly simulations, these two challenges lead engineers to use models with simplified 3D representations using idealized shells rather than representations using solids, from a geometric point of view and, from a compu- 32Chapter 1: From a DMU to FE Assembly Models: current practices tational mechanics point of view, models with specific component interfaces models. These targets require specific treatments during the preparation process of a simulation. Now, the purpose is to describe the major difficulties encountered by engineers during the preparation of assembly simulation models. 1.5.2 Interoperability between CAD and CAE and data consistency The first difficulty to generate assembly simulation models derives from the interoperability between the CAD and CAE systems. CAD tools have been initially developed in the 60s to help designers modeling solids for applications such as machining or freeform surfaces. CAD has evolved along with CAM (Computer Assisted Manufacturing), driving the functionalities of CAD software. However, simulation software has evolved independently. CAD systems do not support a full native integration of simulation preparation modules. The current practice is to export a DMU to subcontracting companies in charge of the simulation pre-processing, which themselves use specialized CAE software to read and transform the CAD components geometry. Each of these two software, (CAD and CAE), efficiently supports its key process. CAD software are efficient to manage robustly and intuitively modify B-rep solids, to generate large assembly models but they contain basic meshing strategies and most of them are able to model non-manifold objects. CAE software are dedicated to simulation processes, they provide capabilities to describe non-manifold geometry (useful for idealized models) but are limited in modeling non-manifold models. They incorporate robust meshing tools (with topological adaption capabilities) and extensive capabilities to describe contact behaviors, material constitutive laws, . . . . However, CAE software relies on a different geometric kernel than CAD, which breaks the link between them and leaves open the needs for shape transformation operators. Also, a transfer of a component from a CAD to a CAE environment has a severe impact on the transferred information. The geometry has to be translated during its import/export between softwares that use different datastructures and operators. This translation can be achieved through a neutral format like STEP (Standard for The Exchange of Product model data) [ISO94, ISO03]. However, this translation may lead to solid model inconsistencies resulting from different tolerance values used in the respective geometric modeling kernels of CAD and CAE software. These inconsistencies may prevent the use of some transformation operators, involving manual corrections. Additionally, the coherence of the input assembly data is crucial. An assembly containing imprecise spatial locations of components and/or components shapes that do not produce consistent CIs (see Section 1.3.2) between components or even the non existence of a geometric model of some components (such as shim components which are not always designed as illustrated in Figure 1.14) implies their manual repositioning or even their redesign to meet the requirements of the simulation model. In the proposed 33Chapter 1: From a DMU to FE Assembly Models: current practices Functional Gap to assemble components Shim component (not design in DMU) to fill the gap Figure 1.14: Illustration of a shim component which does not appear in the DMU model. Shim component are directly manufacture when structural components are assembled. approach, the input DMU is assumed to be free of the previous inconsistencies and therefore, it is considered as coherent. 1.5.3 Current operators focus on standalone components To transform the shape of an initial B-Rep CAD model of a standalone component into a new one as required for its simulation model, the mechanical engineer in charge of the simulation pre-treatment sequentially applies different stages of shape analysis and geometric transformations. His, resp. her, objectives is to produce a new CAD model that can support the mesh generation process. This mesh must be consistent with respect to the simulation objectives and produced in a reasonable amount of time. Based on the simulation objectives reduced to this component, the engineer evaluates qualitatively and a priori, the interactions between its boundary conditions and its areas of simulation observation, e.g., areas of maximum displacements or maximum stresses, to define whether or not some sub domains of this component should be suppressed, idealized. Currently, engineering practices iteratively apply interactive shape transformations: 1. Idealizations, which are the starting transformations, because they are of highest shape transformation level since they perform manifold dimension reductions; 2. Details removal comes after with topological and skin detail categories [Fin01] that can be also grouped together under the common concept of form feature; 3. Mesh generation requirements leading to solid boundary and volume partitioning are the last step of shape transformations that can be achieved with the socalled ‘virtual topology’ operators or, more generally, meshing constraints [She01, FCF∗08]. 34Chapter 1: From a DMU to FE Assembly Models: current practices 1 : Extract Pair of faces from CAD geometry 2 : Generate medial face from Pair of Faces (Automatic) 3 : Connect all medial faces together 4: Assign thickness/offset to medial surface P1 P2 P3 P1 P2 P3 P1 P2 P3 P1 P2 P3 x 14 Shell model with thickness 3D initial model Repetitive Process on each Medial Surface connections (a) (b) Figure 1.15: Illustration of a manual process to generate an idealized model: (a) initial solid superimposed with its idealized model, (b) iterative process using face pairing identification and mid-surface extensions to connect mid-surfaces. Commercial softwares already provide some of these operators to adapt DMUs to CAE processes but they are restricted to simple configurations of standalone components. Fewer software, like Gpure [GPu14], offer capabilities to process specific DMU configurations using large facetted geometric models. Component shape transformations, which is the current target of high level operators, are reduced to manual interactions to apply defeaturing operations on CAD parts such as blend removal [ZM02, VSR02], shape simplifications [LAPL05] or to directly remove features on polyhedral models [MCC98, Tau01, LF05]. In all cases, the flow of interactions is monitored by the engineer. This results in very tedious and time consuming tasks requiring a fair amount of resources. When an idealization is required, engineers can create the resulting mid-surface with a manual and qualitative identification of face pairs [Rez96] or using a medial axis surface generation process [ABD∗98, AMP∗02]. However, information in between idealizable areas is not available and the engineer has to manually create the connections by extending and trimming mid-surfaces, which is highly tedious and relies also on his, resp. her, mechanical interpretation. Figure 1.15 illustrates a manual idealization process where the user identifies faces pairs, then generates mid-surfaces and creates manually new faces to connect medial faces together while locating the idealized object as much as possible inside the initial volume. Applied to complex shapes, e.g., aircraft structure machined parts, this process flow is highly time consuming as a consequence of the numerous connection areas required and can be hardly automated because slight 35Chapter 1: From a DMU to FE Assembly Models: current practices shape modifications strongly influence the process flow. Creating idealized domains in areas where face paring cannot be applied rather than leaving a volume domain in these areas, is a common industrial practice to reduce the number of degrees of freedom of a simulation model and reduce the use of mix dimensional models, thus avoiding transfers between shell and volume finite elements because it is not recognized as a good mechanical model. A volume mesh in connection areas is only beneficial if it brings a gain in accuracy, pre-processing or simulation time. Today, generating volume meshes in connection areas requires lots of manual interventions because these volume shapes can be quite complex. Often, the main difficulty is to partition the initial object into simple volumes to generate structured meshes. The lack of robust and generic operators results in a very time consuming CAD pre-processing task. These geometric operators are analyzed in detail in Chapter 2 to understand why they are not generic and robust enough. 1.5.4 Effects of interactions between components over assembly transformations The amount of shape transformations to be performed significantly increases when processing an assembly. The engineer has to reiterate numerous similar interactive operations on series of components, the amount of such components being large. Unlike modeling a standalone component having no adjacent component, an assembly model must be able to transmit displacements/stresses from one component to another. Therefore, the preparation of an assembly model compared to a standalone component implies a preparation process of their geometric interfaces. Consequently, to obtain a continuous medium, the engineer must be able to monitor the stress distribution across components by adding either kinematic constraints between components or prescribing a non-interpenetration hypothesis between them by adding physical contact models. Thus, modeling hypotheses must be expressed by the engineer at each component interface of an assembly. Today, the interactive preparation of the assembly depicted at Figure 1.13 requires a 5 days preparation to produce either an idealized model or a model based on simplified solids. When looking at this model, some repetitive patterns of groups of components can be observed. Indeed, these patterns are 45 bolted junctions that can be further subdivided into 3 groups of identical bolt junctions, i.e., same diameter. Each group can be further subdivided in accordance with the number of components tightened. The components forming each of these attachments belong to a same function: holding tight in position and transferring forces between the plates belonging to the wing and the fuselage. While a standalone component contributes to a function, an assembly is a set of components that fulfill several functions between them. During an interactive simulation preparation process, even if the engineer has visually identified repetitive 36Chapter 1: From a DMU to FE Assembly Models: current practices configurations of bolts, he, resp. she, has to transform successively each component of each bolt. A property, by which some components share similar interactions than others and could be grouped together because they contribute to the same function, cannot be exploited because there is no such functional information in the DMU and the geometric models of the components are not structured with their appropriate boundary decomposition to set up the connection with their function, e.g., imprint of contact areas are not generated on each component boundary and the contact areas are connected to a function. Thus, the engineer has to repeat similar shape transformations for each component. However, if the geometric entities contributing to the same function are available, grouped together and connected to their function before applying shape transformations, the preparation process could be improved. For instance, bolted junctions would be located and transformed directly into a fastener model through a single operator. Further than repetitive configurations, it is here the impossibility to identify and locate the components and geometric entities forming these repetitive patterns that reduces the efficiency of the preparation process. Processing contacts Hypothesizing the non-interpenetration of assembly components produces non linearity and discontinuities of the simulation model. In this case, the engineer must locate the potential areas of interpenetration during the analysis. Due to the lack of explicit interfaces between components in the DMU, all these contact areas must be processed interactively. At each contact interface, the analyst has to manually subdivide the boundary of each component to generate their geometric interface and then, assign mechanical parameters, such as a friction coefficient, to this interface. In the use-case represented in Figure 1.6, every bolted junction contains between 5 and 7 geometric interfaces at each of the 45 junctions, which amounts to 320 potential contact conditions to define interactively. To avoid these tedious operations, in a context of non linear computations, there is a real need to automate the generation of contacts models in assembly simulations. This automation can be applied to a DMUs with the: • Determination of geometric interface areas between components, i.e., – Localize geometric interfaces between components likely to interpenetrate during the simulation; – Estimate and generate the extent of contact areas over component boundaries. Meshed areas of the two components can be compatible or not depending on the capabilities of CAE software; • Generation of functional information to set the intrinsic properties of contact models, i.e. – Define the friction parameters; 37Chapter 1: From a DMU to FE Assembly Models: current practices Functional Tolerance Loose fit Fitted Snug fit User’s choice Mechanical components DMU Nominal diameter for bearing and shaft CAE Preprocessing Virtualization Simplified representation of a bearing Shaft Contact Area Bearing Simulation Model with Friction contact Figure 1.16: Example of contact model for a FE simulation. – Define the kinematic relations between component meshes in contact areas with respect to the dimensional tolerances between surfaces. Figure 1.16 exemplifies a contact between a shaft and a bearing. Commonly, a DMU exhibits CIs [SLF∗12, SLF∗13] where components’ representations can share the same nominal diameter while they can fulfill different functions according to their fitting (clearance, loose fit, snug fit), thus requiring different settings in their FE respective contact models. As a result, DMUs do not contain enough information to automate the generation of contact models. FE models need geometric and functional information about components interfaces to delineate contact areas as well as to assign contact model parameters. Contribution of component functions to the simulation preparation To automatically handle these repetitive configurations related to components contributing to the same function in an assembly, the simulation preparation process must be able to identify these functions from the input DMU. Currently, the engineer is unable to automate these repetitive tasks because he, resp. she, has no information readily identifying connections in the assembly. Simulation models chosen by the engineer in a CAE library to replace the junctions are geometrically simple and basic interactive operators are available to achieve the necessary shape transformations. As shown in Figure 1.12, an idealized model of a bolted connection modeled with a fastener consists in a set of points connected by line elements to describe the fastener. Using a mesh-independent fastener, the points representing the centers of the bolt holes in the tightened components do not even need to coincide with a surface mesh node. These idealization transformations are rather simple locally, given the component shapes. Hence, the challenge is neither the 38Chapter 1: From a DMU to FE Assembly Models: current practices geometric complexity nor the mesh generation. Indeed, it holds in the term ‘bolted junction’ to identify this geometric set of components and generate geometric relationships between areas of their boundaries. The issue consists in determining the function of each component in an assembly in order to group them in accordance with identical functions and to make decisions about modeling hypotheses (simplification, idealization) on component shapes associated with these identified functions. Conclusion Shape transformations taking place during an assembly simulation preparation process interact with simulation objectives, hypotheses and functions attached to components and to their interfaces. To improve the robustness of the geometric operators applied during simulation preparation, and to make them applicable not only to components but also to assemblies, is a first objective to reduce the amount of time spent on assembly pre-processing. 1.6 Conclusion and limits of current practices about DMU manual adaption for FE assembly models generation Currently, configuring rather complex assembly models for simulations is difficult to handle within the time scale prescribed by an industrial PDP. The pre-processing of CAD models derived from DMUs to produce FE models is far too long compared to the simulation time, it may represent 60% of the whole simulation process (see Section 1.4.1). Consequently, some simulations are not even addressed because their preparation time cannot fit within the schedule of a PDP, i.e., simulation results would be available too late. Because the shape of CAD models obtained from the engineering design processes is neither adapted to the simulation requirements nor to the simulation solvers, shape transformations are mandatory to generate the simulation models. Consequently, DMUs cannot directly support the preparation process of structural analysis models. Today, the operators available in CAD/CAE software allow an engineer to perform either interactive geometric transformations leading to very tedious tasks or automated model generation adapted to simple models only or models containing only a restricted set of form features [TBG09, RG03, SGZ10, CSKL04, LF05, LAPL05, ABA02, SSM∗10, DAP00]. Unfortunately, these operators are still not generic enough to be adapted to analysts’ needs and a rather automated generation of complex component simulation models still raises numerous difficulties, especially when component idealizations must be performed. 39Chapter 1: From a DMU to FE Assembly Models: current practices To generate assembly simulation models, in addition to its component transformations, the engineers need to generate all the connections between its components. Simulation models for assemblies strongly need geometric interfaces between components to be able to set up boundary conditions between them and/or meshing constraints, e.g., to satisfy conformal mesh requirements. Studying the content and structure of an assembly model, as available in a PDMS, reveals that product assemblies or DMUs are reduced to a set of components located in 3D space without geometric relationships between them. The information about the interfaces between components are generally very poor or nonexistent, i.e., real contact surfaces are not identified or not part of each component boundary. As a consequence, it is common practice for engineers to generate interactively the connections between components, which is error prone, due to the large number of repetitive configurations such as junction transformation. Finally, processing complex DMUs for the simulation of large assembly models is a real challenge for aircraft companies. The DMUs, used in large industrial groups such as Airbus Group, consist in hundreds of thousands of components. Thus, engineers in charge of such simulations can hardly consider applying the usual methods involving manual processing of all components as well as their interfaces. To meet the needs for large assembly simulation models, improvements in processing DMUs are a real challenge in aircraft companies and it is mandatory to robustly speed up and automate, as much as possible, the DMU transformations required. 1.7 Research objectives: Speed up the DMU preprocessing to reach the simulation of large assemblies To improve the simulation preparation process of large assembly simulation models, this thesis aims at defining the principles that can be set up to automate the shape adaption of CAD models for the simulation of large assembly structures and developing the associated shape transformation operators. The range of CAD models addressed is not restricted to standalone components but covers also large assembly structures. The tasks planned are mainly oriented toward the transformation of 3D geometric models and the exploitation of their associated semantics for the FEA of structural assemblies applicable to static and dynamic analyses. The task breakdown is as follows: • Analyze FE simulation rules to extract and classify modeling criteria related to user-defined simulation objectives; • Based on CAE discipline’s rules, specifications and process structure, formalize shape transformations operators to increase the level of automation of component transformations as well as the transformation of its geometric interfaces; 40Chapter 1: From a DMU to FE Assembly Models: current practices • Implement and validate idealization operators to transform assembly component shapes and assembly interfaces between components while preserving the semantics of the mechanical behavior intended for this assembly; • Specify the transformation process monitoring and the methodology contributing to the generation of mechanical (CAE) models exploiting a functionally enriched DMUs. Prior to any automation, a first step outlined in Chapter 2 analyzes in detail the available operators and scientific contributions in the field of data integration and shape transformations for mechanical simulations. The objective is to understand why the current operators and approaches are not robust enough to be applied to aeronautical assemblies. From this analysis, Chapter 3 refines the thesis objectives and exposes a new approach to speed up the shape adaption of CAD assembly models derived from DMUs as needed for FE assembly models. The proposed method is able to adapt a component shape to the simulation objectives and meshing constraints. It incorporates the automation of tedious tasks part of the CAD component idealization process, specifically the treatment of connections between idealizable areas. The proposed algorithms detailed in Chapters 4 and 5 have to be robust, applicable for CAD aeronautical components and preserve the semantic of the mechanical behaviors targeted. These operators contribute to an assembly analysis methodology, presented in Chapter 6, that definitively generalizes assembly transformation requirements in order to prove the capacity of the proposed approach to challenge the generation of large assembly simulation models. 41Chapter 1: From a DMU to FE Assembly Models: current practices 42Chapter 2 Current status of procedural shape transformation methods and tools for FEA pre-processing The transformation of DMUs into structural analysis models requires the implementation of methods and tools to efficiently adapt the geometric model and its associated information. Therefore, this chapter proposes a review of the current CAD-FEA integration related to data integration and shape transformations. In this review, the procedural transformations of CAD components are analyzed, from the identification of details to the dimensional reduction operations leading to idealized representations. The geometrical operators are also analyzed with regard to the problem of assembly simulation preparation. Moreover, this chapter identifies that current geometric operators are lacking application criteria of simplification hypotheses. 2.1 Targeting the data integration level Chapter 1 described the industrial needs to reduce the time spent on assembly preparation pre-processing for FEA, now the objective of this chapter is to understand why the available procedural geometric modeling methods and operators still do not meet the engineers’ requirements, leading them to generate interactively their own models. Different approaches have been proposed for a better interoperability between CAD and CAE, which can be mainly classified into two categories [DLG∗07, HLG∗08]: • Integration taking place at a task level: It refers to the integration of activities of design and structural engineers, hence it relates to design and FEA methodologies and knowledge capitalization in simulation data management; 43Chapter 2: Current status of methods and tools for FEA pre-processing • Data integration level: It addresses data structures and algorithms performing shape transformations on 3D models of standalone components. More generally, these data structures and operators help connecting CAD and CAE software. To support the integration of simulation tasks into a PDP, Troussier [Tro99] explains that the knowledge involved in the generation of geometric models is not explicitly formalized. The simulation model definition and generation are based on the collective knowledge of some structure engineers. Therefore, the objective of CAD/CAE integration is not only to reduce the pre-processing time but also to decrease the level of expertise needed to choose and apply the correct transformations to CAD models. Eckard [Eck00] showed that the early integration of structural simulation in a design process could improve a PDP leading to a shorter time-to-market, which applies to assembly processing as well as to standalone components. Badin et al. [Bad11, BCGM11] proposed a specific method of knowledge management used in several interacting activities within a design process. According to them, structure engineers and designers collaborate and exchange design information. However, the authors assume that relationships between dimensional parameters of CAD and simulation models of components are available, which is not necessarily the case. Additionally, they refer to configurations where the shapes of components are identical in both the design and simulation contexts, which is not common practice for standalone components and hardly applicable to assemblies where the reduction of complexity is a strong issue. To help structure engineers, Bellenger [BBT08], Troussier [Tro99] and Peak [PFNO98] formalized simulation objectives and hypotheses attached to design models when setting up simulations. These objectives and hypotheses are subsequently used for capitalization and reuse in future model preparations. This integration at a task level underlines the influence of simulation objectives and hypotheses without setting up formal connections with the shape transformations required. Since the industrial problems addressed in this thesis focus on the robust automation of shape transformations, it seems appropriate to concentrate the analysis of prior research on the data integration level. These research contributions can categorized in: • Detail removals performed either before or after meshing a component [LF05, LAPL05, FMLG09, GZL∗10]; • Shape simplifications applied to facetted models [FRL00, ABA02]; • Idealization of standalone components [CSKL04, SRX07, SSM∗10, RAF11, Woo14] using surface pairing or Medial Axis Transform (MAT) operators. Section 2.2 analyzes the two first categories of shape simplifications and Sections 2.3 concentrates on the specific transformation of dimensional reduction, which is widely used to generate assembly FEMs as illustrated in Section 1.4. Section 2.4 explores morphological approaches such as the geometric analysis and volume decomposition of 3D solids to enforce the robustness of FE models generation. Finally, Section 2.5 44Chapter 2: Current status of methods and tools for FEA pre-processing addresses the evolution of the procedural simplification and idealization during component pre-processing from standalone components toward an assembly context. 2.2 Simplification operators for 3D FEA analysis In CAE applications, the removal of details to simplify a component before meshing it has led to local shape transformations based on B-Rep or polyhedral representations. These transformations create new geometric entities that can incorporate acceptable deviations of a FEA w.r.t. reference results. This section analyzes the different operators and methods aiming at identifying and removing the regions considered as details on 3D solids. 2.2.1 Classification of details and shape simplification As explained in Section 1.4, the level of detail of a solid shape required for its FE mesh is related to the desired accuracy of its FEA. The removal or simplification of a sub-domain of a solid is valid depending when its associated FEA results meet the accuracy constraint. Armstrong and Donaghy [DAP00] and Fine [Fin01] define details as geometric features which do not significantly influence the results of an FE simulation. Starting from this definition, Fine [Fin01] classifies the details under three categories: • Skin details: They represent geometric regions which can be removed without changing neither the 3-dimensional manifold property of the solid (see Section 1.2.1) nor its topology (see Section 1.2.2). This category includes the removal of fillets, chamfers, bosses, . . . ; • Topological details: This category represents geometric regions which can be removed without changing the 3-dimensional manifold property of the solid but their removal modifies the solid’s topology. For example, removing a through hole changes the topology of the solid and the number of hole-loops in the EulerPoincar´e formula decreases; • Dimensional details: This category represents geometric regions which can be removed and reduce locally the manifold dimension of the solid along with a modification of its topology. This category is related to the idealization process where entire solid models can be represented either with surfaces (dimensional reduction of 1), lines (dimensional reduction of 2) or may even be replaced by a point (dimension reduction of 3). In this categorization L´eon and Fine [LF05] define the concept of detail from a physical point of view. According to them, the result of a FEA can be evaluated with 45Chapter 2: Current status of methods and tools for FEA pre-processing CAD Model FEM Volume FEM idealized Volume region which does not influence the result of FE simulation ➱ to be considered as detail Volume which is not represented in idealized model ➱ cannot be considered as detail using idealized FEM model Figure 2.1: Identification of a skin detail related to the accuracy of a FE volume model. With an idealized model, a skin detail cannot be characterized. ‘a posteriori error estimators’ [EF11, BR78, LL83]. These error estimators characterize the influence of a discretization process, i.e., the FE mesh generation, over the solution of the partial differential equations describing a structure behavior. However, as explained in Section 1.4.3, the behavior simulation of large assemblies is heavily based on idealized models to reduce the size, as much as possible, of simulation models and improve their use during a PDP. In this context, skin and topological details cannot be related to the accuracy of the FEA since the error estimators cannot be applied to shape transformations subjected to a dimensional reduction. Indeed, a volume region which does not satisfy the idealization conditions (see Section 1.4.2) is part of an idealized model but not dimensionally reduced. Therefore, as illustrated in Figure 2.1, evaluating the physical influence of small volume details using an idealized FEM has no meaning because the notion of discretization process is not meaningful over the entire model. When considering idealizations, there is currently no ‘error estimators’ to evaluate the influence of the dimensional reductions achieved through these transformations. The definition of skin and topological details has to be discussed and extended in the context of dimensionally reduced models. Even if this classification cannot address idealized models, the simplification operators have to be studied to determine the geometry they are able to process and the information they are able to provide to reduce the complexity of an idealization process. Effectively, it is important to evaluate into which extent skin and topological simpli- fication operators should be applied prior to dimensional reduction or if dimensional reduction takes place first and further simplifications should operate on the dimensionally reduced model. Therefore, the next sections detail the principles of the geometric operators identifying and removing details and determine their suitability to interact with a dimensional reduction process. As mentioned in [Fou07], these operators aim at identifying the geometric regions on the 3D object considered as details and then, remove them from the object in order to generate a simplified model. Approaches to detail removals can be subdivided in two categories depending on the geometric model 46Chapter 2: Current status of methods and tools for FEA pre-processing describing the component: those which act on tessellated models1 and those which modify an initial CAD model. 2.2.2 Detail removal and shape simplification based on tessellated models Although a tessellated object is a simplified representation of an initial CAD model, its geometric model is a collection of planar facets, which can be processed more generically than CAD models. Therefore, the operators based on tessellated models are generic enough to cover a large range of geometric configurations. In what follows, shape simplification operators applicable to the object skin are analyzed first then, a particular attention is paid to the Medial Axis Transform (MAT) operator which extracts an object structure. Shape simplification Different approaches have been proposed to simplify the shape of a CAD component using an intermediate faceted model or modifying a FE mesh of this component. These approaches can be synthesized as follows: • Dey [DSG97] and Shephard [SBO98] improve directly the FE mesh quality by eliminating small model features based on distance criteria compared to the targeted level of mesh refinement. The objective is to avoid poorly-shaped elements and over-densified mesh areas and the treatments proposed are generic; • Clean-up operators [JB95, BS96, RBO02] repair the degeneracies of CAD models when they have lost information during a transfer between CAD/CAE environments or when they contain incorrect entity connections. Their main issue is the computational cost to recalculate new geometries more suitable for analysis [LPA∗03] and the ability of the algorithms to process a wide range of con- figurations. Furthermore, the geometric transformations are inherently small compared to the model size, which may not be the case for simulation details; • Others methods [BWS03, HC03, Fin01, QO12] generate and transform an intermediate tessellated model derived from the CAD component. Fine [Fin01] analyses this tessellated geometry using a ‘tolerance envelope’ to identify and then, remove skin details. Andujar [ABA02] generates new, topologically simpli- fied, models by discretizing the solid object input using an octree decomposition. The advantage of these approaches, dedicated to 3D volume FE, holds in their 1Here, it is referred to tessellated models rather than meshes, as commonly used in computer graphics, to distinguish faceted models used in computer graphics from FE meshes that are subjected to specific constraints for FE simulations. Here, the term mesh is devoted to FE mesh. 47Chapter 2: Current status of methods and tools for FEA pre-processing (a) MAT 2D (b) MAT 3D Medial Axis Medial Surface Figure 2.2: Illustration of the MAT: (a) in 2D, (b) in 3D. independence with respect to the CAD design model. These approaches can support of a wide variety of shapes while avoiding inherent CAD systems issues, i.e., surfaces connections, tolerances, . . . . Nevertheless, any shape modification of the CAD model cannot be taken into account easily and trigger new iterations of the simplification process; • Hamri and L´eon [OH04] propose an intermediate structure, the High Level Topology, in order to preserve a connection between the tessellated model and the CAD model. As a result, bi-directional mappings can be set between these models, e.g., boundary conditions, B-rep surface types, . . . . However, the shape transformations are still performed on the tessellated model. Detail removal using the MAT To identify shape details in sketches, Armstrong [Arm94, ARM∗95] uses the MAT. The MAT has been initiated by Blum [B∗67] and represents, in 2D, the shape defined by the locus of centroids of the maximal inscribed circles in a contour (see Figure 2.2a) or, in 3D, by the maximal spheres inscribed in a solid (see Figure 2.2b). The combination of the centerlines and the diameter of the inscribed circle on these centerlines, respectively the center-surfaces in 3D, forms the skeleton-like representation of the contour in 2D, respectively the solid in 3D, called MAT. As described in [ARM∗95], The MAT operator is particularly suited to provide simplification operators with geometric proximity information in 3D and to identify geometric details on planar domains. The authors use a size criterion to identify: • Details in 2D sketches using the ratio between the length of boundary sketch edges and the radius of the adjacent maximal circle; • Narrow regions using an aspect ratio between the length of the medial edge to the maximal disk diameter on this local medial edge. A region is regarded as narrow when this ratio is lower than a given threshold. In addition, the authors refer to 48Chapter 2: Current status of methods and tools for FEA pre-processing Geometric model Simplified model remove remove Groove reduced to line Hole reduced to point Inner MA Outer MA Figure 2.3: Details removal using the MAT and detail size criteria [Arm94]. the principle of Saint-Venant that relates to the boundary conditions location, to categorize a region as a detail. This method demonstrates the efficiency of the MAT in 2D to analyze, a priori, the morphology of sketch contours. It can compare and identify local regions smaller than their neighborhood. Figure 2.3 illustrates the analysis of a 2D sketch with the MAT [Arm94] to identify details to be removed or idealized. Here, the MAT is addressed as a detail removal operator because the manifold dimension of the 2D domain is not reduced. Nevertheless, it can act also as a dimensional reduction operator. An analysis of the pros and cons of the MAT as a dimensional reduction operator is performed in Section 2.3.1. Operators based on tessellated models may be applied to a large range of configurations because the input model uses a simple polyhedral definition to represent surfaces in 3D. These operators are efficient to remove skin details before meshing. Yet, large modifications of CAD models are difficult to take into account. 2.2.3 Detail removal and shape simplification on 3D solid models As explained in the introduction of this chapter, simplifying CAD solids before meshing is a way to enable a robust mesh generation and to obtain directly the shape required for a FEA without local adjustments of the FE mesh. Transformations can be classified into two complementary categories: transformations modifying the boundary decomposition of a B-Rep model without changing the model’s shape, transformations modifying the shape as well as its boundary decomposition. Topology adaption Virtual topology approaches [SBBC00, She01, IIY∗01, LPA∗03, ARM∗95] have been developed to apply topological transformations to the boundary of an initial B-Rep 49Chapter 2: Current status of methods and tools for FEA pre-processing Narrow regions Edge deletion Face simplification (a) (b) (c) Figure 2.4: Topology adaption of CAD models for meshing [FCF∗08]: (a) CAD model, (b) Meshing Constraint Topology obtained with the adaption process, (c) Mesh model generated with respect to Meshing Constraint Topology. model in order to generate a new boundary decomposition that meet the simulation objectives of this B-Rep model and express the minimum required constraints for mesh generation. Virtual topology approaches belong to the first category of transformations. To anticipate the poorly-shaped mesh elements resulting from B-rep surfaces having a small area, the operation include splitting, merging edges and clustering faces. Anyhow, the objective is to contribute to the generation of a boundary decomposition of a B-Rep model that is intrinsic to the simulation objectives rather being tied to the decomposition constraints of a geometric modeling kernel. Foucault et al. [FCF∗08] propose a complementary topology structure called ‘Meshing Constraint Topology’ with automated adaption operators to enable the transformation of CAD boundary decomposition with mesh-relevant faces, edges and vertices for the mesh generation process (see Figure 2.4). In addition to the topological transformations (edge deletion, vertex deletion, edge collapsing and merging of vertices), the data structure remains intrinsic to the initial object which makes it independent from any CAD kernel representations. Topology adaption is an efficient operator before mesh generation and it is available in most CAE software. However, virtual topology operators are neither generic across CAE software nor they form a complete set of transformations. Form feature extraction The main category of solid model simplification is the extraction or recognition of features (holes, bosses, ribs, . . . ). Different application domains’ requirements lead to a wide variety of feature definitions. Here, a feature is defined as in [Sha95] and refers to a primary geometric region to be removed from a B-Rep object and hence, simplifies its shape. The corresponding operators belong to the second category of transformations. The simplification techniques initially define a set of explicit geometric areas identified on an object. Then, specific criteria are applied, for example metrics, to evaluate and select the candidate features to remove. The construction tree resulting from components’ design (see Section 1.3) directly provides features that can be evaluated. 50Chapter 2: Current status of methods and tools for FEA pre-processing (a) (b) Figure 2.5: Illustration of CAD defeaturing using CATIA: (a) CAD initial model, (b) Simplified CAD model with holes, fillets and chamfers suppressions. However, this approach relies on the availability of this tree, which is not always the case (see Section 1.5.2 on interoperability). Feature recognition approaches are based on the fact that the construction tree is not transferred from a CAD to a CAE system, and they process directly the B-rep model to recognize features. A reference survey of CAD model simplification covering feature recognition techniques has been performed by Thakur [TBG09]. For specific discussions on geometric feature recognition see Shah et al. [AKJ01]. A particular domain, mostly studied in the 80-90s is the recognition of machining features. The methods [JC88, VR93, JG00, JD03] in this field are efficient in recognizing, classifying and removing negative features such as holes, slots or pockets. Han et al. [HPR00] give an overview of the state-of-the-art in manufacturing features recognition. Machining feature recognition has been pioneered by Vandenbrande [VR93]. Woo et al. [WS02, Woo03] contributed with a volume decomposition approach using a concept of maximal volume and observed that some of them may not be meaningful as machining primitives. In the field of visualization, Lee et al. [LLKK04] address a progressive solid model generation. Seo [SSK∗05] proposes a multi-step operator, called wrap-around, to simplify CAD component. To reduce the complexity of assembly models, Kim [KLH∗05] uses this operator and proposes a multi-resolution decomposition of an initial B-rep assembly model for visualization purposes. These operators simplify the parts after detecting and removing small or negative features and idealize thin volume regions using face pairing. Simplification is based on local information, i.e., edge convexity/concavity, inner loops, . . . The obtained features are structured in a feature tree depending on the level of simplification. A wide range of shapes is generated with three basic operators. However, the multi-resolution model is subjected to visualization criteria, which may not produce shape transformations reflecting the application of simulation hypotheses, in general. Lockett [LG05] proposes to recognize specific positive injection molding features. Her method relies on an already generated Medial Axis (MA) to find features from idealized models. However, it is difficult to obtain a MA in a wide range of configurations. Tautges [Tau01] uses size measures and virtual topology to robustly identify geometric regions considered as details but is limited to local surface modification. 51Chapter 2: Current status of methods and tools for FEA pre-processing One common obstacle of feature recognition approaches is their difficulty to set feature definitions that can be general enough to process a large range of configurations. This is often mentioned by authors when features are interacting with each other because the diversity of interactions can lead to a wide range of configurations that cannot be easily identified and structured. In addition, in most cases, the definition of the geometric regions considered as features is based on a particular set of surfaces, edges and vertices extracted from the boundary of the B-Rep object. The assumption is that the detection operations based on the neighboring entities of the features are sufficient to construct both the volume of the features and the simplified object. However, the validity of this assumption is difficult to determine in a general setting, e.g., additional faces may be required to obtain a valid solid, which fairly reduces the robustness of these approaches. Blend removal Removal of blends can be viewed as a particular application of features recognition. Automatic blend features removal, and more precisely, finding sequences of blend features in an initial shape, is relevant to FE pre-processing and characterizes shape construction steps. Regarding blends removal, Zhu and Menq [ZM02] and Venkataraman [VSR02] detect and classify fillet/round features in order to create a suppression order for removing these features from a CAD model. CAD software has already proposed blend removal operators and it is these operators that are considered in this thesis (see Figure 2.5 for a example of a CAD component defeaturing result). In general, blend removal can be viewed as a first phase to prepare the model for further extraction and suppression of features. 2.2.4 Conclusion This section has shown that detail removals essentially address 3D volume simulations of standalone components. The suitability of these simplification operators for assembly structures has not been investigated, up to now. Additionally, the approaches to the automation of detail removal have not been developed for idealization. The definition of details addresses essentially volume domains and refers to the concept of discretization error that can be evaluated with posteriori error estimators. As a result, the relationship between detail removal and idealization has not been addressed. Approaches based on tessellated models produce a robust volume equivalent model but incorporating them with idealization processes, which are often refering to B-Rep NURBS models, does not seem an easy task. Many features-based approaches exist but they are not generic enough to process a wide range of shapes. The operators presented in this section can be employed in a context of CAD to CAE adaption, provided the areas being transformed are clearly delineated. The difficulty is to determine the relevant operator or sequence of operators in relation to the user 52Chapter 2: Current status of methods and tools for FEA pre-processing simulation objective. For now, only operators simplifying surfaces of 3D objects have been presented, in the following section idealization operators introduce categories of complexity with the dimensional reduction of standalone components. 2.3 Dimensional reduction operators applied to standalone components As explained in Section 1.4, to generate idealized models, operators are required to reduce the manifold dimension of 3D solids to surfaces or lines. Different approaches have been proposed to generate automatically idealized models of components for CAE. These approaches can be divided into two categories: • Global dimensional reduction. These approaches refer to the application of a geometric operator over the whole 3D object, e.g., using the MAT that can be globally applied to this object, to generate an overall set of medial surfaces; • Local mid-surface abstraction. Mid-surface abstraction addresses the identification of local configurations characterizing individual medial surfaces (using face pairs, deflation) on CAD models and, subsequently, handles ithe connection of these medial surfaces to generate an idealized model. 2.3.1 Global dimensional reduction using the MAT Armstrong et al. [DMB∗96, ABD∗98, RAF11] come up with the MAT to generate idealized models from 2D sketches and 3D solids. To identify geometric regions in shell models, which may be represented in an FE analysis with a 1D beam, Armstrong et al. [ARM∗95, DMB∗96, DAP00] analyze a skeleton-based representation generated with the MAT. Although the MAT produces a dimensionally reduced geometry of an input 2D contour, local perturbations (end regions, connections) need to be identified and transformed to obtain a model suitable for FEA. As for the details identification of Section 2.2, an aspect ratio (ratio of the minimum length between the medial edge and its boundary edges to the inscribed maximum disk along this medial edge) and a taper criterion (maximum rate of diameter change with respect to medial edge length) are computed to automatically identify entities that must be either reduced or suppressed. Based on a user input threshold for aspect ratio and taper, the corresponding areas of the MAT are categorized into regions idealized either as 1D beam element, or regions kept as 2D elements, or regions idealized as 0D element (concentrated mass). Beam ends, that differ from the resulting MAT methodology, are also identified through the topology of the MAT in order to extend the idealizable regions. More recently, Robinson and Armstrong [RAM∗06, RAF11] generalize the approach to 3D solid to identify 3D regions which, potentially, could be idealized as 2D shell 53Chapter 2: Current status of methods and tools for FEA pre-processing Volume Mesh in Interface area Idealized areas Interface offset for coupling Perturbation in ends MA (a) (b) (c) Figure 2.6: Illustration of the mixed dimensional modeling using a MAT [RAF11]: (a) the MAT representation, (b) the model partitioned into thin and perturbations features, (c) the resulting mixed dimensional model. elements. In a first step, a 3D MAT is used to identify potential volume regions. Then, the MATs of these regions are analyzed by a second 2D MAT to determine the inner sub-regions which fully meet an aspect ratio between their local thickness and MAT dimensions. The final candidates for idealization should satisfy the 2D ratio within the face resulting from the 3D MAT as well as the 3D ratio. Similarly to 2D end regions derived from a 2D MAT, the residual boundary faces from the MAT 3D are extended. Some limitations of the MAT with respect to idealization processes are: • The generation of the MAT. Although progress has been made in MAT generation techniques for 3D objects, the computation of an accurate 3D MAT is still a research topic [RAF11]. Even if approaches [CBL11, RG03] exist which enable the computation of a MAT as a G0 geometric object, 3D MAT from free-form surfaces [RG10, BCL12], B-splines surfaces [MCD11] and planar polyhedra [SRX07], the most efficient algorithms are still based on a discrete representations. The most efficient way to obtain a MAT derives from Voronoi diagrams or from distance fields [FLM03]. An efficient implementation of an algorithm has been proposed by Amenta [ACK01] and, more recently, by Miklos [MGP10]. However, the result is also a discrete representation, which has to be somehow approximated to produce a more global geometric object; • The need for processing local perturbations (see Figure 2.6b). For mechanical analysis purposes, the topological features in ending regions have to be modified to extend the medial surfaces. These undesirable regions complicate and restrain the analysis domain of the MAT; • The connection areas. The MAT generates complex configurations in connection areas. Armstrong and Robinson [RAF11] produce mixed dimensional FE models with idealized surfaces or lines and volume domains in the connections between 54Chapter 2: Current status of methods and tools for FEA pre-processing these regions (see Figure 2.6). These mixed dimensional models, which involve specific simulation techniques using mixed dimensional coupling, do not contain idealized models in connections areas. In addition, to ensure an accurate load transfer from one surface to another, they increase the dimensions of volume connections based on the Saint-Venant’s principle (see Figure 2.6c). As a result, the idealized areas are reduced. However, the current industrial practice, as explained in Section 1.4.3, aims at generating fully idealized models incorporating idealized connections. This practice reduces the computational time, reducing the number of degrees of freedom, and ensures a minimum model accuracy based on user’s know-how. In this context, the major limit of MAT methods is the processing of these connections areas which do not contain proper information to link medial surfaces. 2.3.2 Local mid-surface abstraction To generate fully idealized models, alternative approaches to MAT identify sets of boundary entities of the CAD models as potential regions to idealize. Then, midsurfaces are extracted from these areas and connected together. Face pairing techniques Rezayat [Rez96] initiated the research in mid-surface abstraction from solid models. His objective was to combine the geometric and topologic information of the B-rep model to robustly produce idealized models while transforming geometric areas. This method starts with the identification of surfaces which can be paired based on a distance criterion between them. During this identification phase, an adjacency graph is generated representing the neighbouring links between face-pairs. This graph uses the topological relationships of the initial B-rep model. Then, for each face-pair, a midsurface is generated as the interpolation of this geometric configuration, as illustrated in Figure 2.7a. During the final step,the mid-surfaces are connected together using the adjacency graph of the B-Rep model (see Figure 2.7b). Although this method generates fully idealized models close to manually created ones, the underlying issue is the identification of areas that could potentially be idealized. Indeed, the identification of face-pairs does not ensure that the thickness, i.e., the distance between face-pairs, is as least ten times smaller than the other two directions (see idealization conditions described in Section 1.4.2). The areas corresponding to these face pairs is designated here as tagged areas. In addition, the connection between mid-surfaces requires the definition of new geometric entities which result from an intersection operator. This intersection operator solely relies on the boundary of the areas to be connected, i.e, the face-pairs. There is no information about the boundary of the regions to be idealized as well as the interface areas between their mid-surfaces, e.g., limits of valid connections areas. As illustrated in Figure 2.8d, this information does not appear directly 55Chapter 2: Current status of methods and tools for FEA pre-processing F2 F1 Mid-surface (a) (b) Figure 2.7: Illustration of mid-surface abstraction [Rez96], (a) creation of mid-surfaces from face-pairs, (b) connection of mid-surfaces to generate a fully idealized model. F1 F2 F3 F5 F4 F6 F1 F3 F4 F6 F3 F6 F1 F2 F3 F5 F4 F6 Fi / Fj Invalid face pair Valid face pair Fi / Fj F1 F3 F4 F6 Tagged boundary Non-tagged boundary Interface between regions to be idealized Regions to be idealized Rejected configuration Rejected configuration Accepted configuration CAD Mid-surface results Face-pair information (a) (b) (c) (d) Figure 2.8: An example of particular geometric configuration not addressed by face-pairs methods: (a) Valid configuration without mid-surface connection, (b) and (c) rejection of an invalid face-pair due the overlapping criterion, (d) information on non-tagged areas and interfaces between idealizable regions that are not evaluated with face-pairs methods. on the initial model. These areas are the complement of tagged areas with respect to the boundary of the initial model; they are named non-tagged areas. As a result, mid-surface abstraction are reduced to specific geometric configurations when the facepairs overlap each other. As depicted in Figure 2.8, the face-pairs F3-F6 and F2-F5 are rejected due to the overlapping criterion. So, the idealized configurations 2.8b and c are rejected whereas they could be suitable for FEA. In order to improve the robustness of idealized areas processing, Lee and al. [LNP07a] use a propagation algorithm through the B-rep model topology to identify face-pairs. However, this approach is limited to configurations where the face-pairs can be connected in accordance with predefined schemes. Ramanathan and Gurumoorthy [RG04] identify face-pairs through the analysis of mid-curve relationships of all the faces of the solid model. For each face, its mid-curve is generated using a 2D MAT. This generation is followed by the analysis of the mid-curve graph in order to identify face-pairs. The resulting mid-faces, derived from face-pairs, are then connected to each other in 56Chapter 2: Current status of methods and tools for FEA pre-processing accordance with the mid-curve adjacency graph. This method increases the robustness of face-pairing, indirectly using the morphology of the paired faces. Analyzing the midcurve relationships of adjacent faces enables a morphological comparison of adjacent faces. Since mid-curves have been obtained through a MAT, the face-pairs identifi- cation depends on the accuracy of this mid-curve generation. This method comes up with face-pairs close to each other and sufficiently large along the two other directions to meet the idealization hypothesis. However, this approach is limited to planar areas. Negative offsetting operations Sheen et al. [SSR∗07, SSM∗10] propose a different approach to generate mid-surfaces: the solid deflation. The authors assume that a solid model can be seen as the result of the inflation of a shell model. Their principle is to deflate the solid model, shrinking it down to a degenerated solid with a minimum distance between faces close to zero. This generates a very thin solid model looking like an idealized model. In a next step, faces are extracted and sewed together to create a non-manifold connected surface model. The issue of this method lies in the generation of the deflated model. Indeed, a facepairs detection is used to generate the mid-surfaces input to the shrinking operation. This face-pair detection does not cover configurations with a thickness variation, which is common for aeronautical parts and other mechanical components. This approach is similar to a straightforward MAT generation [AA96, AAAG96], which applies a negative offset to boundary lines in 2D, surfaces in 3D, respectively, in order to obtain a skeleton representation. Yet, this representation being an approximation of the MAT, it does not meet everywhere the equal distance property of a mid-surface and does not provide an answer for all polyhedral solids [BEGV08]. 2.3.3 Conclusion As explained in Section 1.4 and 1.5, the shape of a component submitted to a mesh generation depends on the user’s simulation objectives. This analysis of dimensional reduction operators highlighted the lack of idealization-specific information to delimit their conditions of application. All geometric regions do not satisfy the idealization conditions and hence, these idealization operators cannot produce correct results in these areas. A purely geometric approach cannot produce directly a fully idealized model adapted to FEA requirements. An analysis process is necessary to evaluate the validity of the idealization hypotheses and determine the boundary and interfaces of the regions to be idealized. The MAT is a good basis to produce a 3D skeleton structure and provides geometric proximity information between non adjacent faces. However, it is difficult to obtain in 3D and requires post-processing local perturbations and connection areas. Face-pair techniques are efficient in specific configurations, especially for planar objects. Yet, their main issues remain in their validity with respect to the idealization hypotheses and 57Chapter 2: Current status of methods and tools for FEA pre-processing 1 2 Kinematic connection Shortest distance Offset connection Perpendicular connection 1 2 Figure 2.9: Illustration of different connection models for idealized components. difficulties to process the connection between mid-faces. As illustrated in Figure 2.9, the connection areas derive from specific modeling hypotheses. The user may decide on the connection model that is most appropriate for his, resp. her, simulation objectives. To improve the dimensional reduction of components, the objectives are expressed as: 1. Identify the volume sub-domains candidate to idealization, i.e., the regions that meet the idealization hypotheses; 2. Obtain additional information on interfaces between sub-domains to generate robust connections there. 2.4 About the morphological analysis of components As a conclusion of the previous Section 2.3, geometric operators require a pre-analysis of a component shape to determine their validity conditions. Shape decomposition is a frequent approach to analyze and then structure objects. This section aims at studying the operators dedicated to a volume decomposition of 3D objects with an application to FEA. 2.4.1 Surface segmentation operators There are many methods of 3D mesh2 segmentation developed in the field of computer graphics. They are mainly dedicated to the extraction of geometric features from these 3D meshes. A comparative study of segmentation approaches of 3D meshes, including 2The word mesh is used in the computer graphics context, which refers to a faceted model with no constraint similar to FE meshes. 58Chapter 2: Current status of methods and tools for FEA pre-processing (a) (b) Figure 2.10: Mesh Segmentation: (a) face clustering of Attene [AFS06], (b) shape diameter function of Shapira [SSCO08]. CAD components, is proposed by Attene et al. [AKM∗06]. Reference work by Hilaga [HSKK01] applies a Reeb-graph approach to find similarities between 3D shapes. Watershed [KT03, Kos03], spectral analysis [LZ04], face clustering [AFS06], regions growing [ZPK∗02, LDB05], shape diameter functions [SSCO08] are other techniques to subdivide a 3D mesh for shape recognition, part instantiation, or data compression. Figure 2.10 illustrates two mesh segmentation techniques [AFS06, SSCO08] on a mechanical part. These algorithms are not subjected to parameterization issues like B-Rep CAD models are. They partition a mesh model into surface regions but do not give a segmentation into volume sub-domains and region boundaries are sensitive to the discretization quality. A post-processing of the surface segmentation has to be applied to obtain volume partitions. The main objective of the methods cited above is to divide the object in accordance with a “minima rule” principle introduced by Hoffman and Richards [HR84]. This rule consists in dividing this object to conform to the human perception of segmentation. The authors state that human vision defines the edges of an object along areas of high negative curvature. Hence, the segmentation techniques divide a surface into parts along contours of negative curvature discontinuity. In these areas, the quality of an algorithm is based on its ability to meet this “minima rule”. Searching for regions of high concavity, algorithms are sensitive to local curvature changes. Depending on the threshold value of extreme curvature, the object may be either over-segmented or under-segmented. Even if this threshold is easier to monitor for CAD components because they contain many sharp edges, the curvature criterion is not related to the definition of idealized areas. Consequently, the methods using this criterion do not produce a segmentation into regions satisfying the idealization hypotheses and regions that can be regarded as volumes. This section has covered surface segmentation operators that are not appropriate in the context of a segmentation for idealization. The next section studies volume segmentation operators producing directly a decomposition of a solid model into volume partitions. 59Chapter 2: Current status of methods and tools for FEA pre-processing Thin-sheet region in green (thin-sheet meshable) (a) (b) Semi-structured hybrid mesh of thick region (c) Long/slender region in blue (swept mesh) Complex region in yellow (unstructured mesh) Figure 2.11: Automatic decomposition of a solid to identify thick/thin regions and long and slender ones, from Makem [MAR12]: (a) initial solid model, (b) segmented model, (c) semi-structured hybrid mesh of thick regions. 2.4.2 Solid segmentation operators for FEA Recently, researches concentrated on the identification of specific regions to automatically subdivide a complex shape before meshing. They address shape transformations of complex parts. The automatic segmentation of a mechanical component into volume regions creates a positive feature decomposition, i.e., the component shape can be generated by the successive merge of the volume regions. This principle particularly applies to dimensional reduction processes, i.e, idealizations. Volume region identification for meshing In FEA, solid segmentation methods have been developed to simplify the meshing process. The methods of Lu et al. [LGT01] and Liu and Gadh [LG97] use edge loops to find convex and sweepable sub-volumes for hex-meshing. More recently, the method proposed by Makem [MAR12] automatically identifies long, slender regions (see Figure 2.11). Makem [MAR12] shows that the decomposition criteria have to differ from the machining ones. Heuristics are set up to define the cutting strategy and to shape the sub-domains based on loops characterizing the interaction between sub domains. Setting up these heuristics is difficult due to the large diversity of interactions between sub-domains. Criteria for loop generation aim at generating a unique decomposition and are not able to evaluate alternatives that could improve the meshing scheme. To reduce the complexity of detecting candidate areas for dimensional reduction, Robinson and al. [RAM∗06] use preliminary CAD information to identify 2D sketches employed during the generation of revolving or sweepable volume primitives in construction trees. Figure 2.12 illustrates this process: the sketches are extracted from the construction tree, analyzed with a MAT to determine thin and thick areas forming a feature. Then, this feature is reused as an idealized profile to generate a mixed dimensional model. However, in industry, even if the construction tree information exists in a native CAD model, the creation of features depend on the designer’s modeling choices, 60Chapter 2: Current status of methods and tools for FEA pre-processing 2D Sketch of a revolution feature Slender regions to revolve as surface 3D CAD Component (volume) Mix dimensional Model (volumes and surfaces) Figure 2.12: Idealization using extruded and revolved features in a construction tree, from [RAM∗06]. which do not ensure to obtain appropriate sketches mandatory to get efficient results. Divide-and-conquer approaches An alternative to the complexity of the idealization process can be found in divideand-conquer approaches. Firstly, the solid is broken down into volume sub-domains, which are smaller to process. Then, idealizing these sub-components and combining them together produces the final idealized model. Chong [CSKL04] proposes operators to decompose solid models based on shape concavity properties prior to mid-surface extractions that reduce the model’s manifold dimension. Mid-surfaces are identified from closed loops of split edges and sub-domains are processed using mid-surfaces. The solid model decomposition algorithm detects thin configurations if edge pairs exist in the initial model and matches an absolute thickness tolerance value. Some volume regions remain not idealized because of the nonexistence of edges-pairs on the initial object. In the feature recognition area, Woo et al. [WS02, Woo03] set a volume decomposition approach using a concept of maximal volume. Their decomposition is based on local criteria, i.e., concave edges, to produce the cell decomposition. Consequently, Woo et al. observe that some maximal volumes may not be meaningful as machining primitives and further processing is required in this case to obtain machinable sub-domains. Recently, Woo [Woo14] describes a divide-and-conquer approach for mid-surface abstraction (see Figure 2.13). A solid model is initially decomposed into simple volumes using the method of maximal volume decomposition [WS02, Woo03] as well as feature recognition of Sakurai [Sak95, SD96]. The mid-surfaces are extracted from these simple volumes using face-pairing. Then, face-pairs are connected using a union Boolean operation, thus creating a non-manifold surface model. Finally, a ge- 61Chapter 2: Current status of methods and tools for FEA pre-processing Figure 2.13: Divide-and-conquer approach to idealization processes using a maximal volume decomposition (by Woo [Woo14]). ometric operator identifies and removes local perturbations of mid-surfaces which do not correspond to the faces of the original model. The major objective of this approach is the complexity reduction of the initial mid-surface abstraction. It increases the robustness of the face paring algorithm by applying it on simpler volumes. However, the connections between mid-surfaces are based on the topology of the initial solid without any analysis of its shape related to the user’s simulation objectives. Some solids can be topologically identical but differ in their morphology. Consequently, a morphological analysis of their shape is mandatory to identify the sub-domains subjected to dimensional reduction and to understand the interactions between these sub-domains through their interfaces. Here, the idealization processes are still restricted to a purely geometrical operator that does not integrate user’s simulation objectives. Additionally, this method faces difficulties to handle general configurations and connections between idealized sub-domains through mid-surface extension operations. B-Rep decomposition through feature trees As observed in Section 2.2, the feature recognition techniques are a way to extract volume sub-domains from B-Rep solids. They support segmentation processes for detail removal but do not provide construction process structures of these B-Rep solids. To this ens, different approaches have been proposed to decompose an object shape into a feature tree. Shapiro [SV93] and Buchele [BC04] address the B-Rep to CSG conversion as a means to associate a construction tree with a B-Rep model. Buchele [BC04] applies this principle to reverse engineering configurations. CSG tree representations can be categorized into either half-space or bounded solid decompositions. In [SV93, BC04] B-Rep to half-space CSG representation is studied and it has been demonstrated that half- 62Chapter 2: Current status of methods and tools for FEA pre-processing spaces solely derived from a volume boundary cannot always be integrated into a CSG tree forming a valid solid. In Buchele [BC04], Shapiro and Vossler’s approach [SV93] is complemented to generate a CSG representation from scanned objects and to obtain both its geometry and topology. There, additional algorithms must be added to produce complementary half-spaces. Moreover, the meaning of half-space aggregations is not addressed, i.e., there is no connection between the volume faces and primitives that can be used to create it. Li and al. [LLM06, LLM10] introduce a regularity feature tree used to highlight symmetry in a solid that differs from CSG and construction trees. This tree structure is used to highlight symmetry properties in the object but it neither provides a CSG tree nor primitive entities that could serve as basis for idealization applications. Belaziz et al. [BBB00] propose a morphological analysis of solid models based on form features and B-Rep transformations that are able to simplify the shape of an object and enable simplifications and idealizations. Somehow, this method is close to B-Rep to CSG conversion where the CSG operators are defined as a set of shape modifiers instead of Boolean operators. Indeed, the shape modifiers are elementary B-Rep operators that do not convey peculiar shape information and each stage of the morphological analysis produces a single tree structure that may not be adequate for all simplifications and idealizations. All the approaches generating a CSG type tree structure from a B-Rep bring a higher level shape analysis with connections to a higher level monitoring of shape transformations, symmetry properties. . . However, the corresponding framework of B-Rep to CSG conversion must be carefully applied to avoid unresolvable boundary configurations. Furthermore, producing a single tree structure appears too restrictive to cover a wide range of shape transformation requirements. 2.4.3 Conclusion Solid segmentation operators directly provide a volume decomposition of the initial object. A segmentation brings a higher level of geometric information to the initial B-Rep solid. Previous methods have shown the possibility to generate a segmentation or, even construction processes, from an initial CAD model. Therefore, the current operators: • do not always produce a complete segmentation, e.g., not all features are identified, and this segmentation is not necessarily suited for idealization due to algorithms focusing on other application areas; • may be reduced to simple configurations due to a fairly restrictive definition of the geometric areas being removed from the solid. Furthermore, if these operators generate also a construction process, it is restricted to a single process for a component; 63Chapter 2: Current status of methods and tools for FEA pre-processing • could produce a complete segmentation, e.g., divide and conquer approaches, but they do not ensure that the volume partitions are also simple to process and usable for mid-surfacing. A more general approach to volume decomposition should be considered to depart from a too restrictive feature definition while producing volume partitions relevant for idealization purposes. Therefore, the difficulty is to find adequate criteria to enable a segmentation for dimensional reduction and connections operators. The previous sections have presented the main methods and tools for FEA preprocessing and, more specifically, for idealization processes in a context of standalone components. The next section describes the evolution of these operators toward an assembly context. 2.5 Evolution toward assembly pre-processing Currently, the industrial need is to address the simulation of assembly structures. However, few contributions address the automation of assembly pre-processing. Automated simplifications of assembly for collaborative environment like the multi-resolution approach of Kim [KWMN04] or surface simplification of Andujar [ABA02] transform assembly components independently from each other. This is insufficient to pre-process FE assembly models because mechanical joints and interfaces tightening the different components must take part to these pre-treatment (see Chapter 1.4). Group of components transformations In the assembly simplification method of Russ et al. [RDCG12], the authors propose to set component dependencies to remove groups of components having no influence on a simulation, or to replace them by defeatured, equivalent ones. However, the parent/child relationships created from constraint placement of components does not guarantee to obtain the entire neighborhood of a component because these constraints are not necessarily related to the components’ geometric interfaces. As explained in Section 1.3.1, these positioning constraints are not necessarily equivalent to the geometric areas of connections between components. Additionally, DMUs don’t contain components’ location constraints when assemblies are complex, which is the case in the automotive and aeronautic industries to ease design modifications during a PDP. Moreover, part naming identification used in this approach is not sufficient because it locates individual components contained in the assembly, only. Relations with their adjacent components and their associate geometric model are not available, i.e., replacing a bolted junction with an idealized fastener implies the simplification of its nut and its screw as well as the hole needed to connect them in the tightened components. 64Chapter 2: Current status of methods and tools for FEA pre-processing Small areas difficult to mesh (c) (d) (e) (a) (b) Figure 2.14: Assembly interface detection of Jourdes et al. [JBH∗14]: (a) CAD bolted junction with three major plates, (b) some interfaces, (c) cut through of a bolt of this junction, (d) corresponding interfaces, (e) detail of a small geometric area between an interface and the boundary of the component. Interface detection To provide mesh compatibility connectivity, i.e., an interface between two components ensures the same mesh distribution in the interface area of each component, Lou [LPMV10] and Chouadria [CV06] propose to identify and re-mesh contact interfaces. Quadros [QVB∗10] establishes sizing functions to control assembly meshes. Yet, these methods are used directly on already meshed models and address specific PDP configurations where CAD models are not readily available. Clark [CHE08] detects interfaces in CAD assemblies to create non-manifold models before mesh generation but he does not consider the interactions between interfaces and component shape transformation processes. In [BLHF12], it is underlined that if a component is simplified or idealized, its shape transformation has an influence on the transformation of its neighbors, e.g., a component idealized as a concentrated mass impacts its interfaces with its neighboring components. Assembly operators available in commercial software are reduced to, when robust enough, the automated detection of geometric interfaces between components. However, their algorithms use a global proximity tolerance to find face-pairs of components and they don’t produce explicitly the geometric contact areas. From a STEP representation of an assembly model, Jourdes and al. [JBH∗14] describe a GPU approach 65Chapter 2: Current status of methods and tools for FEA pre-processing 1 2 1 2 1 2 1 Idealized with contact V1 Assembly interfaces Component 1 interfaces CAD assembly of two components Idealizable areas of components FEM models Full idealized Mix dimensional with contact Specific Connector 1 2 1 2 1 Idealized with contact V2 1 2 Idealized with contact V3 1 2 Idealized with contact V4 Kinematic connection Figure 2.15: Various configurations of the idealization of a small assembly containing two components. to automatically detect the exact geometric regions of interfaces between components (see Figure 2.14). The results of this technique are used in this thesis as input assembly interfaces data. Yet, obtaining the geometric regions of interfaces is not sufficient, they have to be analyzed to evaluate their suitability with respect to meshing constraints. Figure 2.14e shows the creation of small surfaces, which are difficult to mesh, resulting from the location of an interface close to the boundary of component surfaces. To reach the requirements of assembly idealizations, the current geometric operators have to take into account the role of assembly interfaces between components, with respect to the shape transformations of groups of components. Figure 2.15 shows the idealization of an assembly containing two components. The idealization of ‘component 1’ interacts with the idealization of ‘component 2’, and both interact with the user’s choice regarding the assembly interface transformation. Depending on the simulation objectives, the user may obtain either an idealized model of the two components with contact definition, or a globally idealized model from the fusion of the two component. The user may even apply a specific connector model which does not require any geometry other than its two extreme points. Assemblies bring a new complexity level into idealization processes since the shape of the components and their interactions with their neighbors have to be analyzed before applying geometric operators. 66Chapter 2: Current status of methods and tools for FEA pre-processing 2.6 Conclusion and requirements The research review in this chapter combined with the context described in Chapter 1 shows that CAD/CAE integration is mainly oriented toward the data integration of standalone components, preparations of assembly models under global simulation objectives require an in-depth analysis and corresponding contributions. Regarding standalone component processing, although automated operators exist, they are currently effective on simple configurations only. To process complex models, the engineer interactively modifies the component using shape transformation operators according to his/her a priori expertise and evaluation of the simulation model being created. These specific operators, among which some of them are already available in CAE software, have to be selected and monitored by the engineer. Their applications still require lots of manual interactions to identify the regions to transform and correct unintended geometric perturbations. Because of the diversity of simulation contexts, the preconceived idea of applying a generic geometric operator to every component to perform any simplification or idealization, is not valid and must evolve toward simulation context-dependent operators. The selection of mechanical hypotheses, because of their impact on the DMU model, should also be part of the automation of a mechanical analysis pre-processing. This issue is particularly crucial when performing dimensional reductions on a component. Generating an idealized equivalent model cannot be reduced to the simple application of a dimensional reduction operator. The effects of idealization hypotheses are supposed to have established the connection between the component shape and its simulation objectives. This connection can be made through the identification of geometric areas candidates to idealizations and associated with the connections between idealized subdomains. An analysis of the component shape, subdividing it into idealizable areas and interfaces between them (see Figure 2.15), is a means to enrich the input CAD solid and prepare the geometry input to dimensional reduction operators. The current volume segmentation operators are restricted to configurations focusing on particular application domains. They often produce a single segmentation into sub-volumes and instantiate the same problem on rather simple configurations. Achieving good quality connections between idealized sub-domains in a robust manner is still a bottleneck of many approaches processing CAD solids for FEA, which requires new developments. Regarding assembly model processing, there is currently a real lack in scientific research and software capabilities, both. To reach the objective of large assembly structural simulation, pre-processing the DMU, which conveys the product definition, has also to be automated. Assembly simulation models, not only require the availability of the geometric model of each component, but they must also take into account the kinematics and physics of the entire assembly to reach the simulation objectives. This suggests that the entire assembly must be considered when specifying shape transformations rather than reducing the preparation process to a sequence of individu- 67Chapter 2: Current status of methods and tools for FEA pre-processing ally prepared components that are correctly located in 3D space. As mentioned in Section 1.5.4, to adapt an assembly to FEA requirements, it is mandatory to derive geometric transformations of groups of components from simulation objectives and component functions. As it results from Chapter 1, the knowledge of interface’s geometries and additional functional information on components and their interfaces is a good basis to specify these geometry transformation operators on assemblies. In addition, to perform assembly idealizations, structuring geometric models of components in areas to be idealized and component interfaces, is consistent with the assembly structure, i.e., its components and their interfaces. Such a component geometric structure helps preserving the DMU consistency. 68Chapter 3 Proposed approach to DMU processing for structural assembly simulations This chapter sets the objectives of the proposed approach to DMU pre-processing for the simulation of FE structural assembly models. To obtain an efficient transformation of a DMU into a FEM requires geometric operators that process input geometric models which have been structured and enriched with additional functional information. With respect to the objectives set up, the proposed approach uses this enriched DMU, both at 3D solid and assembly levels, to analyze its geometry and connect it to the simulation hypotheses with the required shape transformations. 3.1 Introduction Chapter 1 has pointed out the industrial context and identified the general problem definition addressed in this thesis. The current practices about model generation for structural mechanical analyses have been described, especially when the resolution is performed using the FE method. Chapter 2 has analyzed the approaches of academia that investigate the automation of FE models generation. The need for shape analysis as a basis of robust geometric transformation operators has been underlined and the lack of research in assembly pre-processing has been pointed out. Figure 3.1 summarizes the manual processes of a DMU transformation for the FEA of assembly structures. The analysis of the ongoing practices has been stated in Section 1.5. A main issue, observed in the aeronautical industry, is the manual and isolated application of geometric transformations on each component of the assembly. An assembly component is considered as a standalone part and the user iterates his, resp. her, global simulation objective on each component as well as on each assembly interface. As a result, the 69Chapter 3: Proposed approach to DMU processing for structural assembly simulations · Pure CAD geometric model; · No contact; · Junction considered as individual component. DMU EXTRATION PREPROCESSING · Manual transformation of individual component (idealization); · Manual definition of contacts between components; SIMULATION x45 x45 DMU FEM CAD/CAE weak link Non standardized processes and tools for all category of assembly component Lessons learned Simulation Objective Simulation Objective Simulation Objective DATA PROCESSES : Processes : Data Figure 3.1: Current process to prepare assembly structures. Each component of the assembly is transformed individually. use of FEA in aeronautical industry is bounded by the time required to set up its associated FEM. Now, the major challenge is the automation of some FEA preparation tasks so that more simulations can be performed on assembly models. 3.2 Main objectives to tackle As stated in Chapter 2: ‘generating an idealized equivalent model cannot be reduced to the simple application of a dimensional reduction operator’. Indeed: 1. Generating simulation models from DMUs requires the selection of the CAD components having an influence on the mechanical behavior the engineer wants to analyze. Setting up the simulation requires, as input, not only the 3D geometric model of component shapes but also their functional information that help selecting the appropriate components (see Section 1.5.4); 2. A DMU assembly is defined by a set of 3D components and by the interactions between them. To automate the preparation of FE assembly models, it is mandatory to take into account the interfaces between components (see Section 1.4.3). An assembly interface, not only contains the geometric information delimiting the contact/interference areas on each component, but contains also the ‘functional’ information characterizing the behavior of the interface, e.g., clamping, friction, . . . ; 70Chapter 3: Proposed approach to DMU processing for structural assembly simulations 3. To generate idealized components, i.e., the dimensional reduction process of 3D volumes into equivalent medial surfaces/lines, two main aspects have to be considered: • A 3D shape is generally complex and requires different idealizations over local areas depending on the morphology of each of these areas (see Section 2.3); • Interfaces between components have an influence on the choice made for these local idealizations. Therefore, the idealization operator has to take into account this information as a constraint, which is not the case of current idealization operators (see Section 2.5). To address the problem of the FEM preparation of large assembly structures, this chapter introduces an analysis-oriented approach to provide enriched DMUs before geometric transformations. The following sections explain the principles and contributions of this approach, which are subsequently detailed in the next chapters: • Section 3.3: This section shows that existing approaches are able to provide a certain level of functional information. Two main approaches have been exploited. The method of Jourdes et al. [JBH∗14] generates assembly interfaces from DMU models and the method of Shahwan et al. [SLF∗12, SLF∗13] provides functional designation of components. These methods can be used in our current preprocessing approach to provide enriched DMUs before geometric transformations take place. Nevertheless, some improvements are proposed to take into account the geometric structure of components required for an idealization process; • Section 3.4: idealization operators necessitate an estimation of the impact of the idealization hypotheses over a component shape, i.e., the identification of areas candidate to idealization. This section sets our objectives to achieve a robust assembly idealization process. They consist in structuring a component’s shape and taking advantage of this structure to perform a morphological analysis to identify areas conforming to the user’s simulation hypotheses. Subsequently, these hypotheses are used to trigger the appropriate idealization operator over each area; • Section 3.5: this section outlines the proposed processes exploiting an enriched DMU to robustly automate the major time-consuming tasks of a DMU preparation. 3.3 Exploiting an enriched DMU Efforts have been made to improve: 71Chapter 3: Proposed approach to DMU processing for structural assembly simulations • the coordination between engineers in charge of structure behavior simulations and designers; • the use of simulation results during a design process. However, as described in Section 1.3, the DMUs automatically extracted from the PLM are not suited for FE simulations. Because of the product structure, DMUs do not contain structural components, only. DMU components have to be filtered during the early phase of FEA pre-processing to avoid unnecessary geometric treatments on components which are considered as details at the assembly level. As explained in Section 1.5.1, this process is based on a qualitative judgment exploiting engineers’ know-how. A way to increase robustness of this extraction process, is to have available more useful information for the engineers. At least, this information must contain the functional properties of components. In addition, considering that the extracted DMU is coherent and contains the exact set of components subjected to shape transformations, the amount of information which can be extracted from the PLM system is not sufficient to set up a robust and automated pre-processing approach to simulations. Even though the extraction of additional meta-data can be improved (see Section 1.5.4), FEM pre-processing requires the exact interface areas between components as well as the functional designation of each component, which are not available in PLM systems, at present. A main objective of this thesis is to prove that a quantitative reasoning can be made from an enriched and structured DMU to help engineers determining the mechanical influence of components under specific simulation objectives. Benefiting from existing methods that identify functional interfaces and functional designation of components in DMUs The method of Jourdes et al. [JBH∗14] presented in Section 2.5, detects geometric interfaces between components. Starting from an input B-Rep model, i.e., a STEP [ISO94, ISO03] representation of an assembly, the algorithm identifies two categories of interfaces as defined in Section 1.3.2: surface and linear contacts, and interferences. The information regarding assembly interfaces are used by Shahwan et al. [SLF∗13] to provide, through a procedural way, functional information linked to DMUs. Even if Product Data Management System (PDMS) technology provides the component with names referring to their designation, this information is usually not suf- ficient to clearly identify the functions of components in an assembly. For example, in AIRBUS’s PLM, a component starting with ‘ASNA 2536’ refers to a screw of type ‘Hi-Lite’ with a 16mm diameter. This component designation can be associated under specific conditions to an ‘elementary function’, e.g., fastening function in the case of ‘ASNA 2536’. However, information about each component designation does not iden- 72Chapter 3: Proposed approach to DMU processing for structural assembly simulations Bolted junction Nut Counter nut Planar Support Planar Support Planar Support Threaded Link Cap-screw Initial Geometry Functional Interfaces Functional Designation Head Tightened Components Thread Shaft Figure 3.2: Structuring a DMU model with functional properties after analyzing the assembly geometric interfaces and assigning a functional designation to each component (from Shahwan et al. [SLF∗12, SLF∗13]). tify its relation with other components inside the scope of a given function, i.e., the geometric model of a component is not structured with respect to its function. How an algorithm can determine which component is attached to another one to form a junction? Which screw is associated with which nut? Additionally, there is a large range of screw shapes in CAD component libraries. How to identify specific areas on these screws through names only? Also, the word screw is not a functional designation; it does not uniquely refer to a function because a screw can be a set screw, a cap screw, . . . Therefore, to determine rigorously the functional designation of components, Shahwan et al. [SLF∗12, SLF∗13] inserted a qualitative reasoning process that can relate geometric interfaces up to the functional designation of components, thus creating a robust and automated connection between 3D geometric entities and functional designations of components. This is a bottom-up approach that fits with our current requirements. The complete description of a DMU functional enrichment can be found in [SLF∗13]. Figure 3.2 shows the result of the functional enrichment of the aeronautical root-joint use-case presented in Figure 1.6. Initially, the DMU was a purely geometric model. Now, it is enriched with the functional designation of components. Using the definition of Shahwan et al. [SLF∗13], a functional designation of a component is an unambiguous denomination that functionally distinguishes one class of components from another. It relates the geometric model of a component with its functional interfaces (derived from the conventional interfaces described in Section 1.3.2) and with the functional 73Chapter 3: Proposed approach to DMU processing for structural assembly simulations DMU 1 DMU 1 2 DMU 1 2 3 C1 C2 C3 C1 C2 C3 CAD + PLM Product Structure 3- Functional designations 1- PLM information 2- Assembly interfaces I1/3 I2/3 S1 S2 S3.1 C2 S3.2 C1 C3 Fct.1 C3 C1 C2 S1 S2 I1/3 S3.1 S3.1 I2/3 Graph of assembly interfaces and functions CAD + assembly interfaces + component functional designation Fct.1 C1 C2 C3 C1 : Plate C2 : Plate C3 : Screw C1 C2 S1 S2 Imprint of interface CAD + assembly interfaces C1 C2 S1 S2 I1/2 Graph of assembly interfaces Interface Figure 3.3: DMU enrichment process with assembly interfaces and component functional designations. interfaces of its functionally related components. The functional designation of a component binds its 3D model and functional interfaces to a symbolic representation of its functions. Regarding screws, illustrative examples of functional designations are: cap screw, locked cap screw, set screw, stop screw, . . . As a result, a component model as well as its geometric model gets structured. As illustrated in Figure 3.3, its B-Rep model contains imprints of its functional interfaces and geometric relationships with functional interfaces of functionally related components. The functional interfaces contain the lowest symbolic information describing the elementary functions of a component and each functional designation expresses uniquely the necessary relations between these elementary functions. Functional analysis and quantitative reasoning This enriched DMUs makes available information required to perform a functional analysis of the assembly being prepared for FEA. This analysis allows us to implement a quantitative reasoning which can be used to increase the robustness of the automation of shape transformations of components and their interfaces during an assembly preparation process. Geometric entities locating functional interfaces combined with the functional designation of each component enable the identification and location of groups of components to meet the requirements specified in Section 1.5.4. In the research work described in the following chapters, the fully enriched functional DMU 74Chapter 3: Proposed approach to DMU processing for structural assembly simulations Simulation Objectives Hypotheses Components Components’ interfaces Shape transformations Shape transformations : Affect : Interact Figure 3.4: Interactions between simulation objectives, hypotheses and shape transformations. with functional interfaces stands as input data to geometric transformations. Need to extend the DMU enrichment to a lower level: the component shape Thanks to a better extraction and functional enrichment of the geometric models of DMU components, new operators are able to identify components and their interfaces that will be subjected to shape transformations. However, this enrichment is not suffi- cient to determine the geometric areas to be idealized or transformed in the assembly (see Section 2.3). Prior to any shape transformation, we propose to extend this functional assembly enrichment up to the component level. This enrichment is driven by the component’s shape and its interaction with the simulation objectives and related hypotheses. The next section highlights the requirements of this enrichment approach. 3.4 Incorporating a morphological analysis during FEA pre-processing According to Chapter 1, component shapes involved in assembly simulation preparation processes interact with simulation objectives, hypotheses, and shape transformations applied to components and their interfaces. Figure 3.4 shows interactions between shape transformations and FEA modeling hypotheses. To be able to specify the shape analysis tools required, the interactions between shape transformations acting on components as well as on assemblies, on the one hand, and FEA hypotheses, on the other hand, should be formalized. The suggested analysis framework’s objective is the reconciliation of simulation hypotheses with geometric transformations. A morphological analysis driven by idealization needs As stated in Chapter 2, a morphological analysis dedicated to assembly components can improve the robustness of a geometric idealization process. 75Chapter 3: Proposed approach to DMU processing for structural assembly simulations The natural way would be to automate the user’s approach. Indeed, during the current generation of FE meshes, as explained in Section 1.5, this morphological analysis phase is conducted by the engineer, on each component, individually. Based on his, resp. her, own experience, the engineer visually analyzes the component shape and selects the areas to preserve, to suppress, or to modify. Troussier [Tro99] highlighted the lack of tools helping engineers to build and validate their models. She proposed to refer to previous case studies and make them available to the engineer when a new model has to be built. This knowledge capitalization-based method helps engineers analyze their models through the comparison of the current simulation target with respect to the previously generated simulation models. Indeed, referring to already pre-processed FEM enforces the capitalization principle set up. However, even if the engineer is able to formalize the simulation hypotheses, one dif- ficulty remains regarding the concrete application of the shape transformations derived from these hypotheses. A visual interpretation of the required geometric transformations, based on past experiences, is feasible for simple components with more or less the same morphology than previous models. A complex geometry contains numerous regions with their own specific simplification hypotheses. These regions can interact with each other, leading the engineer to reach compromises about the adequate model to generate. For example, many variants of mechanical interactions can appear in interface areas between sub-domains generated for idealized components (see Figure 2.15). It can be difficult for the engineer to get a global understanding of all the possible connections between medial surfaces. As long as no precise mechanical rule exists in these connection areas, each person could have his, resp. her, own interpretation of the hypotheses to apply there. When processing assembly configurations, as illustrated in Section 2.5, its assembly interfaces influence the idealization of the components interacting there. In the case of large assembly structures, on top of the huge amount of time required to analyze all the repetitive configurations, an engineer can hardly anticipate all the interactions between components. Such an interactive analysis process, using the engineer’s know-how, does not seem tractable. Beyond potential lessons learned from previous FEA cases and because current automatic analysis tools are not suited to engineers’ needs (see Section 2.4), it is of great interest to develop new automated shape analyzing tools in order to help engineers understand the application of their simplification hypotheses on new shapes. The following objectives derive from this target. 76Chapter 3: Proposed approach to DMU processing for structural assembly simulations 3.4.1 Enriching DMU components with their shape structure as needed for idealization processes A shape analysis-based approach derives from the information available upstream, i.e., the DMU geometry content before FEA pre-processing that reduces to CAD components. Due to the interoperability issue between CAD and CAE software (see Section 1.5.2), the prevailing practice extracts the B-Rep representation of each component. During component design, successive primitive shapes, or form features, are sequentially added into a construction tree describing a specific modeling process (see Section 1.2.2). This tree structure is editable and could be analyzed further to identify, in this construction tree, a shape closer to the FE requirements than the final one in order to reduce the amount of geometric transformations to be applied. Often, this modeling process relies on the technology used to manufacture the solid. From this perspective, a machined metal component design process differs, for example, from a sheet metal component one. This difference appears in CAD systems with different workshops, or design modules, targeting each of these processes. As an example, the solid model of a sheet metal component can be obtained from an initial surface using an offset operator. This surface is close to the medial surface that can be used as an idealized representation of this component. However, directly extracting a simpler shape from a construction tree is not a generic and robust procedure for arbitrary components. Such a procedure: • cannot eliminate all the geometric transformations required to generate a FE model; • is strongly dependent upon the modeling process of each component; • and is specific to each CAD software. Above all and independently of the extracted geometry, it is essential to analyze a component shape before applying it any geometric transformation. To achieve a robust shape processing, the component shape needs to be structured into regions that can be easily connected to the simulation hypotheses. Proposal of a volume segmentation of a solid as a component shape structure Following the recommendations of Section 2.4, we propose to set up a volume segmentation of a 3D solid to structure it as an enriched input model to generate a robust morphological analysis dedicated to mechanical simulations. As stated in the conclusion of Section 2.4, the generic methods for 3D object decomposition segment mesh1 models only. Volume decompositions of B-Rep models are 1In the computer graphics context. 77Chapter 3: Proposed approach to DMU processing for structural assembly simulations restricted to specific applications that do not cover the FEA needs. Here, the objective is set on a proposal of a robust segmentation of a B-Rep solids to enrich them. Because the robust generation of quality connections between idealized sub-domains is still a bottleneck of many approaches that process CAD solids for FEA, the proposed segmentation should incorporate the determination of interfaces between the volumes resulting from the segmentation. The proposed method is based on the generation of a construction graph from a B-Rep shape. This contribution is detailed in Chapter 4. 3.4.2 An automated DMU analysis dedicated to a mechanically consistent idealization process An analysis can cover multiple purposes: physical prediction, experimental correlation,. . . The proposed analysis framework is oriented toward the geometric issues about the idealization of assemblies for FEA. Section 2.3 has revealed that a major difficulty encountered by automated methods originates from their lack of identification of the geometric extent where simplification and idealization operators should be applied. Using the new structure of a component shape, our objective is placed on a morphological analysis process able to characterize the idealization transformations that can take place on a component shape. Therefore, this process should incorporate, during the pre-processing of DMU models, a set of operators that analyze the initial CAD geometry in order to connect it to simulation hypotheses and determine the geometric extent of these hypotheses. Chapter 5 is dedicated to this contribution. The objectives of this morphological analysis enumerate: • The identification of regions considered as details with respect to the simulation objectives. The DMU adapted to FEA should contain only the relevant geometric regions which have an influence on the mechanical behavior of the structure; • The identification of relevant regions for idealization compared to regions regarded as volumes. The morphology of a component has to be analyzed in order to determine the thin regions to be transformed into mid-surfaces and the long and slender regions to be transformed into beams. Also, this morphological analysis has to provide the engineer with a segmentation of components into volume sub-domains which have to be expanded into the whole assembly; • The characterization of interfaces between idealizable regions. These interfaces contain significant information regarding the interaction between idealizable regions. They are used to connect medial surfaces among each other. 78Chapter 3: Proposed approach to DMU processing for structural assembly simulations Finally, the DMU enrichment process is completed with assembly information as well as information about the shape structure of each component. Consequently, this enriched DMU is geometrically structured. It is now the purpose the next section to carry on setting up objectives to achieve a robust pre-processing from DMU to FEM. 3.5 Process proposal to automate and robustly generate FEMs from an enriched DMU Figure 3.5 summarizes the corresponding bottom-up approach proposed in this thesis. The first phase uses the methods Jourdes et al. [JBH∗14] and Shahwan et al. [SLF∗12, SLF∗13] to enrich the DMU with assembly interfaces and functional designations of components as recommended in Section 1.5.4. The initial CAD solids representing components are also enhanced with a volume decomposition as suggested in Section 2.4 to prepare a morphological analysis required to process the idealization hypotheses. The second phase analyses this newly enriched DMU to segment it in accordance with the engineer’s simulation objectives (see Section 3.4), i.e., to identify areas that can be idealized or removed when they are regarded as details. This results in the generation of a so-called contextualized DMU. Providing the engineer with a new contextualized DMU does not completely fulfill his, rep. her, current needs to create geometric models for structural analysis. Consequently, the proposed scheme should not only develop and validate methods and tools to structure and analyze a DMU up to its component level, but also contain processes to effectively generate FE assembly models. In the third phase, the functional and morphological analyses lead to the definition of the assembly transformation process as planed in the second phase, i.e., the transformation of groups of components including dimensional reduction operations. Exploiting the contextualized DMU, it is proposed to develop a two level adaption process of a DMU for FEA as follows: • One process is dedicated to standalone geometric component idealization. The objective of this new operator is the exploitation of the morphological analysis and hence, to provide the engineer with a robust and innovative approach to 3D shape idealization; • Another process extending the idealization operator to assembly idealization. This operator is a generalization of the standalone operator adapted to assembly transformation requirements. To implement this process, we set up a generic methodology taking into account the simulation requirements, the functional assembly analysis and assembly interfaces. 79Chapter 3: Proposed approach to DMU processing for structural assembly simulations 1- PLM information DMU EXTRATION Contextualized DMU for mechanical simulation Enriched DMU Adapted DMU for FEA DMU ENRICHMENT 4- Volume segmentation of 3D Solid 2- Assembly interfaces 3- Functional designations ... FEM Lessons learned DATA PROCESSES Analysis-based Pre-processing SIMULATION 1 : Processes : Data Phase 1 Phase 2 Phase 3 Proposed Approach Settings of geometric process transformations Definition of assembly process transformations ANALYSIS DMU TRANSFORMATION DMU DMU 1 2 3 4 Morphological analysis Functional assembly analysis Operators Library Simulation Objective Contributions Figure 3.5: Proposed approach to generate a FEM of an assembly structure from a DMU. 80Chapter 3: Proposed approach to DMU processing for structural assembly simulations 3.5.1 A new approach to the idealization of a standalone component When components have to be fully idealized, their pre-processing requires the development of a robust idealization process containing a dimensional reduction operator associated with a robust one that connects medial surfaces. As shown in Section 2.3, existing approaches face two issues: • The extraction of a mid-surface/medial line from an idealized sub-domain. Current dimensional reduction operators focus directly on the generation of midsurface/medial line without having completely evaluated the idealization hypotheses and determined the sub-regions associated to these hypotheses; • The connection of the set of extracted mid-surfaces/medial lines. Current operators encounter difficulties to generate consistent idealized models in connections areas, i.e., regions which usually do not satisfy the idealization conditions. To cover these issues, we propose to analyze the morphology of the shape before applying a dimensional reduction operator. Therefore, this operator focuses on the extraction of medial surfaces only in the sub-domains morphologically identified as plate/shell models and on the extraction of medial lines in the sub-domains morphologically identified as beam models. Simultaneously, this morphological analysis is used to provide information on internal interfaces between sub-domains to be idealized. We propose to exploit this new information within the idealization operator to produce consistent geometric models, i.e., on-purpose idealization of sub-domains with on-purpose connections between them. This process is detailed in Section 5.5. 3.5.2 Extension to assembly pre-processing using the morphological analysis and component interfaces The second process required addresses the transformation of assembly models. The proposed operators have to be applicable to volume sub-domains, which can originate from components or from a group of components. Evolving the concept of details in the context of assembly structures Section 2.2 has shown that the relationship between detail removal and idealization processes has not been investigated. The definition of details stated in [LF05, RAF11] addresses essentially volume domains and refers to the concept of discretization error that can be evaluated with a posteriori error estimators. Assemblies add another complexity to the evaluation of details. It is related to the existence of interfaces between components. As illustrated in Section 1.5.4, interfaces 81Chapter 3: Proposed approach to DMU processing for structural assembly simulations are subjected to hypotheses to define their simulation model and Table 1.2 points out the diversity of mechanical models that can be expressed with simulation entities. Recently, Bellec [BLNF07] described some aspects of this problem. Yet, comparing the respective influences of rigid versus contact interface models is similar to the evaluation of idealization transformations: this is also a complex issue. The concept of detail, apart from referring to the real physical behavior of a product, is difficult to characterize for assembly idealization. The structural engineer’s knowhow is crucial to identify and remove them with interactive shape transformations. Benefiting from the morphological analysis of components’ shapes, another objective of this thesis is to provide the user with tools that show areas that cannot be regarded as details (see Sections 5.3.1 and 5.5.2). This way, the concept of details evolves from standalone component to assembly level pre-processing. Automated transformations of groups of components As explained in Section 1.5.4, the transformation of groups of components, e.g., junctions, by pre-defined FE simplified geometry, e.g., fasteners, is a top requirement to reduce the FEM preparation time. Focusing on these specific configurations, the main issue remains the robust identifi- cation of the components and assembly interfaces to be transformed. Another objective of this thesis is also to provide a robust operator to identify and transform configurations of groups of components involved in the same assembly function, which is detailed in Chapter 6. From the analysis of DMU transformation requirements for FE assembly model preparation [BLHF12], the proposed method relies on a qualitative reasoning process based on the enriched DMU as input. From this enriched model, it is shown that further enrichment is needed to reach a level of product functions where simulation objectives can be used to specify new geometric operators that can be robustly applied to automate component and assembly interface shape transformations. To prove the validity of this approach, Section 6.3 presents a template-based operator to automate shape transformations of bolted junctions. The method anticipates the mesh generation constraints around the bolts, which also minimizes the engineer’s involvement. 3.6 Conclusion This chapter has introduced the main principles and objectives of the proposed analysisoriented approach of DMU pre-processing for the simulation of FE structural assembly models. This approach covers: • The enrichment of the input geometry, both at 3D solid and assembly levels. 82Chapter 3: Proposed approach to DMU processing for structural assembly simulations It is critical to provide a volume decomposition of the geometric model of each component in order to access and fully exploit their shape. This structure is a good starting point for the identification of areas of interest for idealization hypotheses. At the assembly level, the DMU is enriched with geometric interfaces between its components, i.e., contacts and interferences, and with the functional designation of components; • The development of an analysis framework for the simulation of mechanical structures. From the enriched DMU model, the analysis framework can be used to specify geometric operators that can be robustly applied to automate component and interface shape transformations during an assembly preparation process. In accordance with the context of structural simulations, this framework evaluates the conditions of application of idealization hypotheses. It provides the engineer with the operators dedicated to shape adaption after idealizable volume subdomains have been identified. Also, after the areas considered as details have been identified and information about sub-domains interfaces have been added, the user’s modeling rules can be applied in connection areas; • The specification of geometric operators for the idealization of B-rep shapes and operators transforming groups of components, such as bolted junctions, bene- fiting from the previously structured DMU. Through the development of such operators, the proposed approach can be sequenced and demonstrated on aeronautical use-cases. The next chapters are organized in accordance with the proposed approach, as described in the current one. Chapter 4 details the B-Rep volume decomposition using the extraction of generative construction processes. Chapter 5 describes the concepts of the FEA framework using a construction graph to analyze the morphology of components and derive idealized equivalent models. Chapter 6 extends this approach to a methodology for assembly idealization and introduces a template-based operator to transform groups of components. 83Chapter 3: Proposed approach to DMU processing for structural assembly simulations 84Chapter 4 Extraction of generative processes from B-Rep shapes to structure components up to assemblies Following the global description of the proposed approach to robustly process DMUs for structural assembly simulation, this chapter exposes the principles of the geometric enrichment of components using a construction graph. This enrichment method extracts generative processes from a given B-Rep shape as a high-level shape description and represents it as a graph while containing all non trivial construction trees. Advantageously, the proposed approach is primitivebased and provides a powerful geometric structure including simple primitives and geometric interfaces between them. This high-level object description is fitted to idealizations of primitives and to robust connections between them and remains compatible with an assembly structure containing components and geometric interfaces. 4.1 Introduction Based on the analysis of DMU transformation requirements for FE assembly model preparation in Chapter 1 as well as the analysis of prior research work in Chapter 2, two procedures are essential to generate the mechanical model for the FEA of thin structures: • The identification of regions supporting geometric transformations such as simplifications or idealizations. In Section 1.4.2, the analysis of thin mechanical shell structures introduces a modeling hypothesis stating that there is no normal stress in the thickness direction. This hypothesis is derived from the shape of 85Chapter 4: Extraction of generative processes from B-Rep shapes the object where its thin volume is represented by an equivalent medial surface. The idealization process connects this hypothesis with the object shape. Section 2.3 illustrates that idealization operators require a shape analysis to check the idealization hypothesis on the shape structure and to delimit the regions to be idealized; • The determination of interface areas between regions to be idealized. Section 2.3 showed that the interface areas contain the key information to robustly connect idealized regions. In addition to idealizable areas, the determination of interfaces is also essential to produce fully idealized models of components. The proposed pre-processing approach, described in Chapter 3, is based on the enrichment of the input DMU data. More precisely, the B-rep representation of each CAD component has to be geometrically structured to decompose the complexity of their initial shape into simpler ones. At the component level, we propose to create a 3D solid decomposition into elementary volume sub-domains. The objective of this decomposition is to provide an efficient enrichment of the component shape input to apply the idealization hypotheses. This chapter is dedicated to a shape decomposition method using the extraction of a construction graph from B-Rep models [BLHF14b, BLHF14a]. Section 4.2 justifies the extraction of generative construction processes suited for idealization processes1. Section 4.3 sets the modeling context and the hypotheses of the proposed approach. Section 4.4 describes how to obtain generative processes of CAD components, starting from the identification of volume primitives from a B-Rep object to the removal process of these primitives. Finally, Section 4.5 defines the criteria to select the generative processes generating a construction graph for idealization purposes. This construction graph will be used in Chapter 5 to derive idealized models. In a next step, the component perspective is extended to address large assembly models. Consequently, the segmentation approach is analyzed with respect to CAD assembly representation in Section 4.7. 4.2 Motivation to seek generative processes This section presents the benefits of modeling processes to structure a B-Rep component. It shows the limits of CAD construction trees in mechanical design and explains why it is mandatory to set-up generative processes adapted to idealization processes. 1 generative processes represent ordered sequences of processes emphasizing the shape evolution of the B-Rep representation of a CAD component. 86Chapter 4: Extraction of generative processes from B-Rep shapes 4.2.1 Advantages and limits of present CAD construction tree As observed in Section 1.2.3, a mechanical part is progressively designed in a CAD software using successive form features. This initial generation of the component shape can be regarded as the task where the component shape structure is generated. Usually, this object structure is described by a binary construction tree containing the elementary features, or primitives, generating the object. This construction tree is very efficient to produce a parameterized model of a CAD object. Effectively, the user can easily update the shape of the object when modifying parameters defined within a user-selected feature and then, re-processing the subset of the construction tree located after this primitive. As illustrated in Section 2.4, Robinson et al. [RAM∗06] show that a construction tree with adapted features for FEA can be used to easily generate idealized models. 1 3 (b) (a) St B B 6 T 8 11 15 17 18 20 B T B T T T 23 33 34 T B T B 2 4 - 5 7 9 - 10 16 19 21 12 ® 14 22 24 ® 32 Figure 4.1: An example of a shape generation process: (a) final object obtained after 34 modeling steps and viewed from top (T) and bottom (B), (b) some intermediate shapes obtained after the i th modeling step. The letter T or B appearing with step number indicates whether the object is viewed from top or bottom. 87Chapter 4: Extraction of generative processes from B-Rep shapes However, the construction tree produced during the design phase may not be suited for the shape decomposition taking place at other stages of a PDP, e.g., during process planning and FEA. Three main issues are preventing the use of current CAD construction trees from FEM pre-processing: • The complexity of the final object shape and feature dependencies. The concept of feature-based design eases the generation of an object shape by adding progressively, and one by one, simple form features. This way, the user starts from a simple solid, i.e., a primitive, and adds or removes volumes using pre-defined features (extrusion, revolution, sweeping, . . . ) one after the other until he, resp. she, has reached the desired shape of the object. As a consequence of this principle “from simple to complicated”, the resulting construction tree can be complex and contains numerous features. Because, the user inserts one form feature at a time, the construction tree is necessarily binary, i.e., each tree node contains one form feature and the object shape obtained after combining this form feature with the object resulting from the previous tree node. As an example, Figure 4.1 illustrates this configuration with a rather complex component where the user’s entire modeling process consists of 37 steps, some of them containing multiple contours producing simultaneously several features. Two views, defined as top and bottom in Figure 4.1b, show the major details of the object shape. Figure 4.1a depicts some of the 34 steps involving either extrusion or revolution operations and incorporating either material addition or removal as complementary effects when shaping this object. The parent/child dependencies between form features further increase the complexity of this construction process. The suppression or modification of a parent feature is not always possible due to geometric inconsistencies generated in subsequent tree steps when parent/child dependencies cannot be maintained or when the object boundary cannot produce a solid. This is particularly inconvenient in the context of FEM pre-processing which aims at eliminating detail features to simplify component shapes; • The non-uniqueness and user dependence. Construction trees are not unique, i.e., different users often generate different construction trees for the same final shape. The choice of the sequence of features is made by the designer and depends on his, resp. her, own interpretation of the shape structure of the final object. In current industrial practices, specific modeling rules limit the differences in construction tree generation but they are not dedicated to FEM requirements as explained in Section 3.3; • The construction tree availability. Construction trees contain information which is very specific to each CAD system and each software has its own data structures to represent this construction scheme. Most of the time, this information is lost when transferring objects across CAD systems or even across the 88Chapter 4: Extraction of generative processes from B-Rep shapes different phases of a PDP. Practically, when using STEP neutral format [ISO94, ISO03], definition of construction tree structures associated with parametric modeling are not preserved. Indeed, to edit and to modify a shape, the parametric relations taking part to the construction tree would need also to be exported. This is difficult to obtain, e.g., even during the upgrade of CATIA software [CAT14] from V4 to V5, the transfer was not fully automatic and some information in construction trees was lost. As it appears in Figure 4.1, a shape generative process can be rather complex and, even if it is available, there is no straightforward use or transformation of this process to idealize this object (even though its shape contains stiffeners and thin areas that can be modeled with plate or shell elements rather than volume ones). With respect to the idealization objectives, it appears mandatory to set-up another generative process that could incorporate features or primitives with their shapes being close enough to that of stiffeners and thin wall areas. 4.2.2 A new approach to structure a component shape: construction graph generation Construction trees are important because an object submitted to a FEA preparation process can be subjected to different simplifications at different levels of its construction process. One key issue of these trees is their use of primitives that are available in common industrial CAD software. Another problem lies in the storage of the shape evolution from the initial simple primitive shape to the final object. This principle ‘from simple to complicated’ matches the objective of using the tree contents for idealization and simplification purposes. Indeed, obtaining simpler shapes through construction processes could already reduce the number of geometric transformations. However, because the CAD construction tree is presently unique, not always available and complicated to modify, its use is difficult. The proposed approach here, structuring the shape of a component, consists in producing generative processes of its B-Rep model that contain sets of volume primitives so that their shapes are convenient for FE simulation. The benefits of extracting new generative processes, as ordered sequences of processes emphasizing the shape evolution of the B-Rep representation of a CAD component, are: • To propose a compact shape decomposition adapted to the idealization objectives. Extraction of compact generative processes aims at reducing their complexity while getting a maximum of information about their intrinsic form features. The proposed geometric structure decomposes an object into volume sub-domains which are independent from each other and close enough to regions that can be idealized. This segmentation method differs from the divide and conquer approaches of [Woo14] because generative processes contain volume prim- 89Chapter 4: Extraction of generative processes from B-Rep shapes itives having particular geometric properties, e.g., extruded, revolved or swept features. The advantage of these primitives is to ease the validation of the idealization criteria. Indeed, one of their main dimensional characteristics is readily available. For example, the extrusion distance, revolve angle or sweep curve, reduces the primitive analysis to the 2D sketch of the feature. Moreover, interfaces between primitives are identified during the extraction of each generative process to extend the analysis of individual primitives through the whole object and to enable the use of the engineer’s FE connection requirements between idealizable regions; • To offer the user series of construction processes. In a CAD system, a feature tree is the unique available definition of the component’s construction but is only one among various construction processes possible. Furthermore, in a simulation context, it is difficult to get an adequate representation of the simulation model which is best matching the simulation requirements because the engineer’s know-how takes part to the simulation model generation (see Section 3.4). Consequently, the engineer may need to refer to several construction processes to meet the simulation objectives as well as his, resp. her, shape transformation requirements. Providing the engineer with several construction processes helps him, resp. her, generate easily a simulation model. The engineer will be able to navigate shape construction processes and obtain a simpler one within a construction tree that meets the idealization requirements in the best possible way; • To produce a shape parameterization independent from any construction tree. The construction tree is a well-known concept for a user. Parent/child dependencies between features, generated through sketches and their reference planes, ease the interactive design process for the user but creates geometric dependencies difficult to understand for the user. Performing modifications of a complex shape remains difficult to understand for the user, e.g., the cross influence between features located far away in the construction tree is not easy to anticipate. Considering the generation of a construction graph, the proposed approach does not refer to parent/child dependencies between features, i.e., features are geometrically independent each other. The morphological analysis required (see Section 3.4) does not refer to a need for a parameterized representation of components, i.e., each primitive does not need to refer to dependencies between sketch planes. Components can be modified in a CAD software and their new geometry can be processed again to generate a construction graph without referring to the aforementioned dependencies. As a conclusion, one can state that enabling shape navigation using primitive features similar to that of CAD software is an efficient complement to algorithmic approaches reviewed in Chapter 2 and construction trees. More globally, construction graphs can support both efficiently. 90Chapter 4: Extraction of generative processes from B-Rep shapes Shape modeling processes Segmentation CAD Mesh Idealization M M-1 M-2 Pi(M/M ) -1 Pi(M /M ) -1 -2 Pi(M ) -2 Figure 4.2: An example of shape analysis and generative construction graph. To this end, this chapter proposes to extract a construction graph from B-Rep CAD models so that the corresponding generative processes are useful for mechanical analysis, particularly when idealization processes are necessary. The graph is extracted using a primitive removal operator that simplifies progressively the object’s shape. One could says that the principle is to go ‘backward over time’. This characteristic of construction trees is consistent with the objective of simplification and idealization because the shapes obtained after these operations should get simpler. Figure 4.2 illustrates the extraction of a shape modeling process of a CAD component. Primitives Pi are extracted from a sequence of B-Rep objects Mi which become simpler over time. The set of primitives Pi generates a segmented representation of the initial object which is used to derive idealized FE models. The following sections detail the whole process of extraction of generative processes from B-Rep shapes. 4.3 Shape modeling context and process hypotheses Before describing the principles of the extraction of generative processes from a BRep shape, this section sets the modeling context and the hypotheses of the proposed approach. 4.3.1 Shape modeling context As a first step, the focus is placed on B-Rep mechanical components being designed using solid modelers. Looking at feature-based modeling functions in industrial CAD systems, they all contain extrusion and revolve operations which are combined with addition or removal of volume domains (see Figure 4.3a). The most common version of the extrusion, as available in all CAD software, is defined with an extrusion direction 91Chapter 4: Extraction of generative processes from B-Rep shapes variant with material removal material blend as part of addition extrusion contour blend variable radius V H Extrusion Contour (a) (b) (c) (d) Slanted extrusion Cutting Plane Figure 4.3: (a) Set of basic volume modeling operators, (b) sketch defining an extrusion primitive in (a), (c) higher level volume primitive (slanted extrusion), (d) reference primitive and its first ‘cut’ transformation to generate the object in (c). orthogonal to a plane containing the primitive contour. Such an extrusion, as well as the revolution, are defined here as the reference primitives. These feature-based B-Rep operations can be seen as equivalent to regularized Boolean operations as available also in common hybrid CAD modelers, i.e., same primitive shapes combined with union or subtraction operators. Modelers also offer other primitives to model solids, e.g., draft surfaces, stiffeners, or free-form surfaces from multiple sections. Even though we don’t address these primitives here, it is not a limitation of our method. Indeed, draft surfaces, stiffeners, and similar features can be modeled with a set of reference primitives when extending our method to extrusion operations with material removal and revolutions. Appendix B illustrates the simple features and boolean operations available in CAD software and show that it can mainly be reduced to additive/removal extrusion/revolution features in order to cover the present software capabilities . Figure 4.3c illustrates some examples, e.g., an extrusion feature where the extrusion direction is not orthogonal to the sketching plane used for its definition. However, the resulting shape can be decomposed into an extrusion orthogonal to a sketching plane and ‘cuts’ (see Figure 4.3d) if the generation of a slanted extrusion is not available or not used straightforwardly. Indeed, these construction processes are equivalent with respect to the resulting shape. Another category of form features available from B-Rep CAD modelers are blending radii. Generally, they have no simple equivalence with extrusions and revolutions. Generated from B-Rep edges, they can be classified into two categories: 1- constant radius blends that can produce cylindrical, toroidal or spherical surfaces; 92Chapter 4: Extraction of generative processes from B-Rep shapes 2- constant radius blends attached to curvilinear edges and variable radius blends. Category 1 blends include extrusion and revolution primitives and can be incorporated in their corresponding sketch (see Figure 4.3a). This family of objects is part of the current approach. Category 2 blends are not yet addressed and are left for future work. Prior work in this field [VSR02, ZM02, LMTS∗05] can be used to derive M from the initial object MI to be analyzed, possibly with user’s interactions. In summary, all reference primitives considered here are generated from a sketching step in a plane defining at least one closed contour. The contour is composed of line segments and arcs of circles, (see Figure 4.3b). This is a consequence of the previous hypothesis reducing the shapes addressed to closed surfaces bounded by planes, cylinders, cones, spheres, tori, and excluding free-form shapes in the definition of the object boundary. This is not really restrictive for a wide range of mechanical components except for blending radii. The object M to be analyzed for shape decomposition is assumed to be free of blending radii and chamfers that cannot be incorporated into sketched contours. The generative processes are therefore concentrated on extrusion primitives, in a first place, in order to reduce the complexity of the proposed approach. Further hypotheses are stated in the following sections. 4.3.2 Generative process hypotheses Given a target object M to be analyzed, let us first consider the object independently of the modeling context stated above. M is obtained through a set of primitives combined together by adding or removing material. Combinations of primitives thus create interactions between their bounding surfaces, which, in turn, produce intersection curves that form edges of the B-Rep M. Consequently, edges of M contain traces of generative processes that produced its primitives. Hence, following Leyton’s approach [Ley01], these edges can be seen as memory of generation processes where primitives are sequentially combined. Current CAD modelers are based on strictly sequential processes because the user can hardly generate simultaneous primitives without looking at intermediate results to see how they combine/interact together. Consequently, B-Rep operators in CAD modelers are only binary operators and, during a design process, the user-selected one combines the latest primitive generated to the existing shape of M at the stage t of this generative process. Additionally, CAD modelers providing regularized Boolean operators reduce them to binary operators, even though they are n-ary ones, as classically defined in the CSG approaches [Man88]. Here, the proposed approach does not make any restriction on the amount of primitives possibly generated ‘in parallel’, i.e., the arity of the combination operators is n ≥ 2. The generated processes benefit from this hypothesis by compacting the construction trees nodes. This property is illustrated in the result Section 4.6 of this chapter in Figure 4.22. 93Chapter 4: Extraction of generative processes from B-Rep shapes d (a) (b) Top Bottom (c) IG (face 2) contour edge (convex) lateral face (transparent) Fb2 contour edge (concave) Fb1 (transparent) IG (face 1) fictive lateral edge lateral edge Attachment contour( , ) Fb1 Fb2 Figure 4.4: a) Entities involved in an extrusion primitive. Visible extrusion feature with its two identical base faces F b1 and F b2. (b) Visible extrusion feature with its two different base faces F b1 and F b2. (c) Visible extrusion feature with a unique base face F b1 (detail of Figure 4.1a - 34B). Hypothesis 1: Maximal primitives The number of possible generative processes producing M can be arbitrary large, e.g., even a cube can be obtained from an arbitrary large number of extrusions of arbitrary small extent combined together with a union operator. Therefore, the concept of maximal primitives is introduced so that the number of primitives is finite and as small as possible for generating M. A valid primitive Pi identified at a stage t using a base face Fb1 is said to be maximal when no other valid primitive Pj at that stage having F� b1 as base face can be entirely inserted in Pi (see Section 4.4.2 and Figure 4.4a): ∀Pj , Pj �⊂ Pi. Fb1 is a maximal face as defined at Section 4.3.3. Maximal primitives imply that the contour of a sketch can be arbitrary complex, which is not the case in current engineering practice, where the use of simple primitives eases the interactive modeling process, the parameterization, and geometric constraint assignments to contours. The concept of maximal primitive is analog to the concept of maximal volume used in [WS02, Woo03, Woo14]. Yet, this concept is no used in feature recognition techniques [JG00]. Even if making use of maximal primitives considerably reduces the number of possible generative processes, they are far from being unique for M. Hypothesis 2: Additive processes 94Chapter 4: Extraction of generative processes from B-Rep shapes (a) (b) Extrusion contour Extrusion Revolution Mid-surface Mid-surface d Direction of extrusion Revolution contour Angle of revolution Figure 4.5: Illustrations of two additive primitives: (a) an extrusion primitive and (b) a revolution one. The mid-surfaces of both primitives lie inside their respective volumes. We therefore make the further hypothesis that the generative processes we are looking for are principally of type additive, i.e., they are purely based on a regularized Boolean union operator when combining primitives at each stage t of generative modeling processes. This hypothesis is particularly advantageous when intending to tailor a set of generative processes that best fit the needs of idealization processes. Indeed, idealized structures, such as mid-surfaces, lie inside such primitives, and connections between primitives locate also the connections between their idealized representatives. Figure 4.5 illustrates an extrusion and a revolution primitives. With both of them, the 3D solid of the primitive includes its mid-surface. Therefore, the idealized representation of M can be essentially derived from each Pi and its connections, independently of the other primitives in case of additive combinations. Figure 4.6 gives an example where M can be decomposed into two primitives combined with a union (b). M in Figure 4.6, (b) can thus be idealized directly from these two primitives and their interface. On the contrary, when allowing material removal, idealization transformations are more complex to process, while the resulting volume shapes are identical. Figure 4.6c shows two primitives which, combined by Boolean subtraction, result also in object (a). However, computing an idealization of (a) by combining idealizations of its primitives in (c) is not possible. Performing the idealization of M from its primitives strengthens this process compared to previous work on idealization [CSKL04, Rez96, SSM∗10] of solids presented in Section 2.3.1 for two reasons. Firstly, each Pi and its connections bound the 3D location of and the connections with other idealized primitives. Secondly, different categories of connections can be defined, which is important because idealization processes still rely on the user’s know-how to process connections significantly differing from reference ones. The next Chapter 5 explains in details how to connect mid-surfaces using a taxonomy of connections between extrusion primitives. Hypothesis 3: Non trivial variants of generative processes To further reduce the number of possible generative processes, the processes described should be non trivial variants of processes already identified. For example, the 95Chapter 4: Extraction of generative processes from B-Rep shapes (a) (b) (c) + - OR Figure 4.6: a) Simple shape with idealizable sub-domains, (b) Primitives to obtain (a) with an additive process, (c) Primitives to obtain (a) with a removal process. same rectangular block can be extruded with three different face contours and directions but they create the same volume. Two primitives generating the same shape are considered as the same non-trivial primitive. If the resulting shape of two processes at the jth-level of a construction is the same then, these two processes are said equivalent and are reduced to a single one and the object shape at the (j−1)th-level is also unique. These equivalent processes can be detected when comparing the geometric properties of the contours generating this same shape. Other similar observations will be addressed in the following sections when describing the criteria to select meaningful generative processes. The above hypotheses aim at reducing the number of generative processes producing the same object M while containing primitives suited to idealization transformations, independently of the design process initially set up by engineers. Conclusion The overall approach can be synthesized through the process flow of Figure 4.7. The input STEP file contains the B-Rep model M. A set of generative processes is extracted that form sets of construction trees, possibly producing a graph. To this end, application dependent criteria are used to identify one or more construction trees depending on the application needs. Here, we focus on criteria related to idealization for FEA. 4.3.3 Intrinsic boundary decomposition using maximal entities In order to extract generative processes from the B-Rep decomposition of M, it is important to have a decomposition of M, i.e., topology description, that is intrinsic to 96Chapter 4: Extraction of generative processes from B-Rep shapes Selection of generative process(es) Application dependent criteria STEP file (input Model) Generation of generative process graph Shape transformations (idealization) Figure 4.7: Pipeline producing and exploiting generative shape processes. its shape. A B-Rep decomposition of an object is however not unique (and thus not suitable), because it is subjected to two influences: • Its modeling process, whether it is addressed forward during a design process or backward as in the present work. Indeed, each operation involving a primitive splits/joins boundary faces and edges of the solid. When joining adjacent faces or edges, their corresponding surfaces or curves can be identical. Their decomposition is thus not unique. However, CAD modelers may not merge the corresponding entities, thus producing a boundary decomposition that is not changing the object shape (see Figure 4.8a). For the proposed approach purposes, such configurations of faces and edges must lead to a merging process so that the object boundary decomposition is unique for a given shape, i.e., it is intrinsic to the object shape; • The necessary topological properties to setup a consistent paving of an object boundary, i.e., the boundary decomposition must be a CW-complex. Consequently, curved surfaces need to be partitioned. As an example, a cylinder is decomposed into two half cylinders in most CAD modelers or is described with a self connected patch sewed along a generatrix (see Figure 4.8b). In either case, the edge(s) connecting the cylindrical patches are adjacent to the same cylindrical surface and are not meaningful from a shape point of view. Hence, for the proposed approach purposes, they must not participate to the intrinsic boundary decomposition of the object. Following these observations, the concepts of maximal faces and edges introduced by [FCF∗08] is used here as a means to produce an intrinsic and unique boundary decomposition for a given object M. Maximal faces are identified first. For each face of M, a maximal face F is obtained by repeatedly merging an adjacent face Fa sharing a common edge with F when Fa is a surface of same type and same parameters than F, i.e., same underlying surface. F is maximal when no more face Fa can be merged with F. Indeed, maximal faces coincide with ‘c-faces’ defined in [Sil81] that have been proved to uniquely defined M. Similarly, for each edge of M, a maximal edge E with 97Chapter 4: Extraction of generative processes from B-Rep shapes (a) (b) Couples of faces that can be merged Figure 4.8: Examples of configurations where faces must be merged to produce a shapeintrinsic boundary decomposition: (a) face decomposition due to the modeling process, (b) face decomposition due to topological requirements. adjacent faces F1 and F2 is obtained by repeatedly merging an adjacent edge Ea when Ea is also adjacent to F1 and F2. Again, E is maximal when no more edge Ea can be merged with E. As a consequence of these merging processes, it is possible to end up with closed edges having no vertex or with closed faces having no edge. An example for the first case is obtained when generating the maximal face of the cylinder in Figure 4.8b. A sphere described with a single face without any edge and vertex is an example for the second case. Because of maximal edges without vertices and faces without edges, merging operations are performed topologically only, i.e., the object’s B-Rep representation is left unchanged. Maximal faces and edges are generated not only for the initial model M but also after the removal of each primitive when identifying the graph of generative processes. Consequently, maximal primitives (see Hypothesis 1) are based on maximal faces and edges even if not explicitly mentioned throughout this document. Using the concept of maximal faces and edges the final object decomposition is independent of the sequence of modeling operators. 4.4 Generative processes Having define the modeling hypotheses and context in the previous Section 4.3, this section presents the principles of the construction of generative processes from B-Rep object. It explains how the primitives are identified and how to remove them from an object M. 4.4.1 Overall principle to obtain generative processes Preliminary phase As stated in Section 4.3.1, a preliminary step of the method is to transform it into a blending radii-free object M. To this end, defeaturing functions available in most CAD 98Chapter 4: Extraction of generative processes from B-Rep shapes Identification of extrusion primitives Pi Going back over time Generating M from primitives Object M M®M’ Removal of primitives from M’ M’ empty? No Yes End Set of construction trees producing M Set of extrusion primitives Pi Construction graph of primitives Figure 4.9: Overall scheme to obtain generative processes. Object M End Object M-1 Object M-2 Removal of Pi Identification of extrusion primitives Pi in M Identification of extrusion primitives Pi in M-1 Identification of extrusion primitives Pi in M-2 Pi Removal of Pi Figure 4.10: An example illustrating the successive identification and removal of primitives. systems are applied. This operation is a consequence of the modeling context defined in Section 4.3.1. Even though these functions may not be sufficient and robust enough, this is the current working configuration. In contrast to blending radii, most chamfers are included in the present approach because they can be part of extrusion primitives and hence, included in the sketched contours used to define extrusion primitives. Even if CAD software provide specific functions for chamfers, they are devoted to the design context but basic operators of extrusion with material addition or removal could produce the same result, in general. This analysis regarding chamfers shows the effect of the concept of maximal primitives (see Hypothesis 1). Main phase Starting with the solid M, the generative processes are obtained through two phases: 99Chapter 4: Extraction of generative processes from B-Rep shapes • M is processed by iterative identification and removal of primitives. The objective of this phase is to ‘go back in time’ until reaching root primitives for generative processes. The result of this phase is a set of primitives; • Based on hypotheses of Section 4.3.2, a set of generative processes is produced using the primitives obtained at the end of the first phase to meet the requirements of an application: here idealization (see Chapter 5). Finally, the decomposition D of M into extrusion primitives is not limited to a single construction tree but it produces a construction graph GD iteratively generated from M. GD contains all possible non trivial construction trees of M (see Hypothesis 3). The process termination holds whenever M is effectively decomposable into a set of extrusion primitives. Otherwise, D is only partial and its termination produces either one or a set of volume partitions describing the most simplest objects D can reach. Figure 4.9 summarizes the overall scheme just described previously. When generating GD, we refer to M = M0 and evolutions M−j of it backward at the jth step of D. Figure 4.10 illustrates the major steps of the extraction of a generative process graph, i.e., from the primitive identification up to its removal from M, and will be further explained in Sections 4.4.2 and 4.4.3. 4.4.2 Extrusion primitives, visibility and attachment In order to identify extrusion primitives Pi in M = M0 and evolution M−j of it, backward at the jth step of the generation of the generative process graph, it is mandatory to define its geometric parameters as well as the hypotheses taken in the present work (see Figure 4.4). First of all, let us notice that a ‘reference primitive’ Pi is never appearing entirely in M or M−j unless it is isolated like a root of a construction tree, i.e., Pi = M or Pi = M−j . Apart from these particular cases, Pi are only partly visible, i.e., not all faces of Pi are exactly matching faces of M−j . For simplicity, we refer to such Pi as ‘visible primitives’. Pi is the memory of a generative process that took place between M−j and M−(j+1). Extracting Pi significantly differs compared to feature recognition approaches [Rez96, LGT01, WS02, SSM∗10, JG00]. In feature recognition approaches, Pi is identified through validity constraints with its neighboring attachment in M, i.e., faces and edges around Pi. These constraints limits the number of possible primitives by looking to the best interpretation of some visible boundaries of the object M. Here, identifying visible primitives enables the generation of reference ones having simpler contours. Only the visible part of the primitive is used to identify the primitive in M, without restricting the primitive to the visible boundaries of M. The proposed identi- fication process of Pi is more general, it does not integrate any validity constraint on 100Chapter 4: Extraction of generative processes from B-Rep shapes the attachment of Pi with M. This constraint released, this process enables the identi- fication of a greater number of primitives which can be compared with each other not only through their attachment to M but also through their intrinsic shape complexity. Definition of the primitive The parameters involved in a reference extrusion Pi are the two base faces, F b1 and F b2, that are planar and contain the same sketched contour where the extrusion takes place. Considering extrusions that add volume to a pre-existing object, the edges of F bi are called contour edges which are all convex. Indeed, Pi being standalone primitive, all its contour edges are convex. A convex edge is such that the outward normals of its adjacent faces define an angle α where: 0 < α < π. When Pi belongs to M−j , the contour edges along which Pi is attached to M−j can be either convex or concave depending on the neighborhood of Pi in M−j (see Figure 4.4a). In the direction d of the extrusion, all the edges are straight line segments parallel to each other and orthogonal to F bi. These edges are named lateral edges. Faces adjacent to F bi are called lateral faces. They are bounded by four edges, two of them being lateral edges. Lateral edges can be fictive lateral edges when a lateral face coincides with a face of M−j adjacent to Pi (see Figure 4.4a). When lateral faces of Pi coincide with adjacent faces in M−j , there cannot be edges separating Pi from M−(j+1) because of the definition of maximal faces. Such a configuration refers to fictive base edges (see Figure 4.11 with the definition of primitive P1). Principle of primitive identification: Visibility The visibility of Pi depends on its insertion in M−j and sets the conditions to identify Pi in ∂M−j 2. An extrusion primitive Pi can be visible in different ways depending on its insertion in a current object M−j . The simplest visibility is obtained when Pi’s base faces F bi in M−j exist and when at least one lateral edge connects F bi in M−j (see Figure 4.4a and 4.11(step1)). More generally, the contour of F b1 and F b2 may differ from each other (see Figure 4.4b) or the primitive may have only one base face F b1 visible in M−j together with one existing lateral edge that defines the minimal extrusion distance of F b1 (see Figure 4.4c). Our two hypotheses on extrusion visibility thus state as follows: • First, at least one base face F bi is visible in M−j , i.e., the contour of either F b1 or F b2 coincides with a subset of the attachment contour of Pi in M−j ; • Second, one lateral edge exists that connects F bi in M−j . This edge is shared by two lateral faces and one of its extreme vertices is shared by F bi. 2∂M−j is the boundary of the volume object M, i.e., the B-Rep representation 101Chapter 4: Extraction of generative processes from B-Rep shapes d d P1 P2 Primitive to Remove Interface Identical Faces Volume to remove from Primitive Reduced Primitive Included in Solid Simplified Solid 1 - Find Extrusion Primitives 2 - Keep included Primitives 3 - Find Interfaces 4 - Remove Primitives from Solid Fb1 contour edge P1 P2 P1 P1 Not Included in Solid Figure 4.11: An example illustrating the major steps to identify a primitive Pi and remove it from the current model M−j . Pi is entirely defined by F bi and the extrusion length obtained the maximum length of the generatrix of Pi extracted from its lateral faces partly or entirely visible in M−j . Notice that the lateral edges mentioned may not be maximal edges when lateral faces are cylindrical because maximal faces may remove all B-Rep edges along a cylindrical area. These conditions of definition of extrusion distance restricts the range of extrusion primitives addressed compared to the use of the longest lateral segment existing in the lateral faces attached to F bi. However, it is a first step enabling to address a fair set of mechanical components and validate the major concepts of the proposed approach. This generalization is left for future work. Figure 4.4b, c give examples involving two or one visible base faces, respectively. Attachment An extrusion primitive Pi is attached to M−j in accordance to its visibility in M−j . The attachment defines a geometric interface, IG, between Pi and M−(j+1), i.e., IG = Pi ∩ M−(j+1). This interface can be a surface or a volume or both, i.e., a nonmanifold model. One of the simplest attachments occurs when Pi has its base faces F b1 and F b2 visible. This means that Pi is connected to M−(j+1) through lateral faces only. Consequently, IG is a surface defined by the set of lateral faces not visible in Pi. Figure 4.4a illustrates such a type of interface (IG contains two faces depicted in yellow). Simple examples of attachment IG between Pi and M−(j+1) are given in Figure 4.4. 102Chapter 4: Extraction of generative processes from B-Rep shapes (b) Pi M-(j+1) IG S e1 e2 (a) Pi M-(j+1) IG Volume Interface Figure 4.12: Example of geometric interface IG between Pi and M−(j+1): (a) surface type, (b) volume type. M-j Valid Primitives Primitive (Pi) Non Valid Primitive Direction of extrusion (a) (b) Fb1 Figure 4.13: Collection of primitives identified from M−j : (a) Valid primitives included in M−j , (b) invalid primitive because it is not fully included in M−j . Green edges identify the contour of the base face of the primitive. 4.4a involves a surface interface and 4.4b illustrates a volume one. Let us notice that the interface between Pi and M−(j+1) in 4.4b contains also a surface interface located at the bottom of the primitive that is not highlighted. However, as we will see in Section 4.5, all possible variants of IG must be evaluated to process the acceptable ones. In a first step, Pi can be translated directly into an algorithm to identify them (procedure f ind visible extrusion of algorithm 1). The visibility of Pi does not refer to its neighboring faces in M−j . Next, they are subjected to validity conditions described in the following section. 4.4.3 Primitive removal operator to go back in time The purpose is now to describe the removal operator that produces a new model M−(j+1) anterior to M−j . This removal operator is defined as a binary operator with Pi and M−j as operands and M−(j+1) as result. In the context of a generative process, M−j relates to a step j and M−(j+1) to a step (j + 1). 103Chapter 4: Extraction of generative processes from B-Rep shapes Characterization of interfaces In order to be able to generate M−(j+1) once Pi is identified, it is necessary to reconstruct faces adjacent to Pi in M−j so that M−(j+1) defines a volume. To this end, the faces of M−j adjacent to Pi and IG must be characterized. Here, Pi is considered to be adjacent to other subsets of primitives through one edge at least. The removal operator depends on the type of IG. Due to manifold property of M, two main categories of interfaces have been identified: 1- IG is of surface type. In this category, the removal operator will have to create lateral faces and/or the extension of F b2 so that the extended face coincides with F b1. Indeed, this category needs to be subdivided into two sub categories: a- IG contains lateral faces of Pi only (see Figure 4.4a) or IG contains also an extension of F b2 and edges of this extension are concave edges in M−(j+1); b- IG may contains lateral faces of Pi but it contains an extension of F b2 and the edges of this extension are fictive base edges in M−j . These edges would be convex edges in M−(j+1), (see P1 in Figure 4.11); 2- IG contains at least one volume sub-domain. In addition, considering that F b1 at least is visible and Pi is also visible (see Section 4.4.2), the attachment contour may not be entirely available to form one or more edge loops (see Figure 4.4a). Also, IG can contain more than one connected component when Pi is resembling a handle connected to M−(j+1), which produces more than one edge loop to describe the attachment of Pi to M−(j+1) in IG. Validity Whatever the category of interface, once Pi is identified and its parameters are set (contour and extrusion distance), it is necessary to validate it prior to define its interface (step 2 of Figure 4.11). Let Pi designates the volume of the reference primitive, i.e., the entire extrusion Pi. To ensure that Pi is indeed a primitive of M−j , the necessary condition is formally expressed using regularized Boolean operators between these two volumes: (M−j ∪∗ Pi) −∗ M−j = φ. (4.1) This equation states that Pi intersects M−j only along the edge loops forming its attachment to M−(j+1), i.e., Pi does not cross the boundary of M−j at other location than its attachment. The regularized Boolean subtraction states that limit configurations producing common points, curve segments or surface areas between Pi and M−j at other locations than the attachment of Pi are acceptable. This condition strongly reduces the number of primitives over time. Figure 4.13 illustrates the list of 9 primitives identified from an object M−j . 8 primitives in 4.13a satisfy the validity criterion as they are included in M−j . The primitive in 4.13b is not fully included in M−j and is 104Chapter 4: Extraction of generative processes from B-Rep shapes IG ( type 1a surface ) (a) (b) (c) IG ( type 1b surface ) IG ( type 2 volume ) Pi Pi Pi Fictive edge e1 e2 Figure 4.14: Illustration of the removal of Pi with three different interface types: (a) type 1a, (b) type 1b, (c) type 2. removed from the set. Another example in Figure 4.11 at step 2 shows that primitives P2 and P3 can be discarded. Removal of Pi The next step is the generation of M−(j+1) once Pi has been identified and removed from M−j . Depending of the type of IG, some faces of Pi may be added to ensure that M−(j+1) is a volume (see Figure 4.11 steps 3 and 4). For each category of interface between Pi and M−j , the removal operation is described as follow: • Type 1a: If IG is of type 1a, then the faces adjacent to the contour edges of F b1 are orthogonal to F b1. These faces are either planar or cylindrical. IG contains the faces extending these faces, Fa1 , to form the lateral faces of Pi that were ‘hidden in M−j ’. Edges of the attachment of Pi belonging to lateral faces of Pi can be lateral edges (either real or fictive ones) or arbitrary ones. Lateral edges bound faces in Fa1 , arbitrary edges bound the extension of the partly visible lateral faces of Pi, they belong to: Fa2 . Then, IG may contain the extension of F b2 called Fa3 such that: F b2 ∪ Fa3 = F b1. Then: ∂M−(j+1) = (∂M−j − ∂Pi) ∪ (Fa1 ∪ Fa2 ∪ Fa3 ), (4.2) where ∂M−j is the set of connected faces bounding M−j , ∂Pi is the set of connected faces bounding the visible part of Pi. ∂M−(j+1) defines a closed, orientable surface, without self intersection. M−(j+1) is therefore a volume. Figure 4.14 a and Figure 4.15 illustrate this process for interface of type 1a; • Type 1b: If IG is of type 1b, IG contains a set of faces extending lateral faces of Pi: Fa1 . To reduce the description of the various configurations, let us focus on the key aspect related to the extension of F b2 contained in IG. If this extension 105Chapter 4: Extraction of generative processes from B-Rep shapes Fb1 Partly visible base face Fb2 Partly visible lateral face of Pi Visible lateral faces of Pi Fa1 Fa3 Fa2 Lateral edge ¶M_ j (¶M_ j - ¶Pi) ¶M_ (j+1) Figure 4.15: Illustration of the removal of Pi for interface of surface type 1a and generation of ∂M−(j+1) with the extension of lateral and base faces. can be defined like Fa3 above, it has to be observed that fictive edges of this extension in M−j are replaced by convex edges in M−(j+1), i.e., edges of the same type (convex) as their corresponding edges in F b1 (see Figure 4.11 step 3 left image). Without going into details, these fictive edges can be removed to simplify the contour of Pi since they bring unnecessary complexity to Pi and does not affect the complexity of M−(j+1). In addition to simplify progressively the object’s shape, reducing the complexity of primitives’ contours is a way to obtain primitives having a form as simple as possible. The corresponding effect is illustrated on Figure 4.11 steps 3 and 4 and on Figure 4.14b. This contour simplification can influence the contents of the sets Fa1 and Fa3 above but it has no impact on the integrity of the volume M−(j+1) obtained; • Type 2: If IG belongs to category 2, it contains at least one volume sub-domain. Here again the diversity of configurations can be rather large and it is not intended to give a detailed description of this category. A first condition to generate a volume interface relates to surfaces adjacent to Pi. If S is the extension of such a surface and S ∩∗ Pi �= φ, S may contribute to the generation of a volume sub-domain. Then, each of these surfaces has to be processed. To this end, all the edges attaching Pi in M−(j+1) and bounding the same surface in M−(j+1) are grouped together since they form a subset of the contour of faces possibly contributing to a volume sub-domain. These groups are named Ea. Such an example of edge grouping is given in Figure 4.14b where e1 and e2 are grouped because of their adjacency between Pi and the same cylindrical surface. Ea, together with other sets of edges are used to identify loops in S that define a volume sub-domain of IG that must satisfy validity conditions not described here for sake of conciseness. Figure 4.16 illustrates the identification of a volume interface, S divides Pi into two volume sub-domains and generates a volume interface. There may be several valid volume sub-domains defining alternative sets of faces to replace the visible part of Pi, ∂Pi, in ∂M−j by sets of faces that promote either the 106Chapter 4: Extraction of generative processes from B-Rep shapes Fb1 ¶M_ j (¶M_ j - ¶Pi) Pi S + Volume interface type 2 Surface interface type 1a ¶M_ (j+1) = Ea1 Ea2 Ea3 Figure 4.16: Illustration of the removal of Pi containing a volume interface of type 2. extension of surfaces adjacent to Pi or the imprint of Pi in M−(j+1) with the use of faces belonging to the hidden part of Pi in M−j . All the variants are processed to evaluate their possible contribution to the generative process graph. If, in a general setting, there may be several variants of IG to define M−(j+1), these variants always produce a realizable volume, which differs from the half-space decomposition approaches studied in [SV93, BC04] where complement to the halfspaces derived from their initial boundary were needed to produce a realizable volume. 4.5 Extracting the generative process graph Having defined the primitive removal operator, the purpose is now to incorporate constraints on variants of IG so that a meaningful set of models M−j , j > 0, can be generated to produce a generative process graph. 4.5.1 Filtering out the generative processes As mentioned earlier, the principle of the proposed approach is to ‘go back in time’ from model M to single primitives forming the roots of possible construction trees. The main process to select primitives to be removed from M−j is based on a simplification criterion. Primitive selection based on a shape simplicity concept 107Chapter 4: Extraction of generative processes from B-Rep shapes nj = 8 F1 F2 F5 F3 F4 F8 F6 F1 F3 F2 F4 F4 F7 n(j+1) = 4 1 n(j+1) = 7 2 n(j+1) = 6 3 F1 F6 F5 F2 F3 F7 F1 F2 F3 F4 F5 F6 Volume Interface P1 P2 P3 M-j M-(j+1) M-(j+1) M-(j+1) 2 3 1 δj1 = 4 δj1 = 1 δj1 = 2 Figure 4.17: Illustration of the simplicity concept to filtering out the generative processes. The number of maximal faces of is greatly reduced with P1 than P2 and P3. Any acceptable primitive removal at step j of the graph generation must produce a transformation of M−j into k objects M−(j+1)k using IGk , one of the variants of IG, such that M−(j+1)k is simpler than M−j . This simplicity concept is a necessary condition for the graph generation to converge toward a set of construction trees having a single primitive as root. Consequently, the simplicity concept applied to the transition between M−j and M−(j+1)k is sufficient to ensure the convergence of the graph generation process. The shape simplification occurring between M−j and M−(j+1)k can be defined as follows. First of all, it has to be considered that ∂M−j and ∂M−(j+1)k contain maximal faces and edges. In fact, after Pi is removed and replaced by IGk to produce M−(j+1)k , its boundary decomposition is re-evaluated to contain maximal faces and edges only. Then, let nj be the number of (maximal) faces in M−j and n(j+1)k be the same quantity for M−(j+1)k , the quantity δjk: δjk = nj − n(j+1)k (4.3) characterizes the shape simplification under the variant IGk if: δjk ≥ 0. (4.4) This condition is justified because it enforces a ‘diminishing number of maximal faces over time’, which is an intrinsic quantity to each shape. Figure 4.17 illustrates the simplicity criterion between three primitives P1, P2, and P3 to be removed from a solid M−j . M−j , the initial solid, contains nj = 8 (maximal) faces. When removing P1 from M−j , the resulting solid M−(j+1)1 contains n(j+1)1 = 4 (maximal) faces. Identically, the resulting solids from P2 and P3 contains respectively n(j+1)2 = 7 and n(j+1)3 = 6 (maximal) faces. As a result, the primitive P1 is selected because the quantity δj1 = 4 is greater than δj2 and δj3. By removing P1, the resulting object M−j is simpler than with P2 or P3. 108Chapter 4: Extraction of generative processes from B-Rep shapes 4.5.2 Generative process graph algorithm Having defined the condition to evolve backward in the generative process graph, the graph generation is summarized with algorithm 1. Algorithm 1 Extract generative process graph 1: procedure Extract graph � The main procedure to extract generative processes of a solid M 2: inputM 3: node list ← root; current node ← root; 4: arc list ← nil; current arc ← nil; node list(0) = M 5: while size(node list) > 0 do � Stop when all solids M−j reach a terminal primitive root 6: current node = last element of list(node list) 7: M−j = get solid(current node) 8: conf ig list = P rocess variant(M−j ) 9: compare conf ig(get all conf ig(graph), conf ig list) � Compare new variants with the existing graph nodes 10: for each conf ig in conf ig list do 11: M−(j+1) = remove primitives(M−j , conf ig) � Remove the identified primitives from M−j 12: node = generate node(M−(j+1), conf ig) 13: add node(graph, node) 14: arc = generate arc(node, current node) 15: add arc(graph, arc) 16: append(node list, node) 17: end for 18: remove element from list(node list, current node) 19: end while 20: end procedure 21: procedure conf ig list = P rocess variant(M−j ) � Process each variant M−j to go ’backward in time’ 22: initialize primitive list(prim list) 23: ext list = f ind extrusion(M−j ) 24: for each Pi in ext list do 25: Pi = simplif y prim contour(Pi, M−j ) 26: interf list = generate geom interfaces(Pi, M−j ) 27: interf list = discard complex(interf list, Pi, M−j ) 28: if size(interf list) = 0 then 29: remove from list(Pi, ext list); 30: end if 31: append(prim list, interf list(i)) 32: end for 33: sort primitive(prim list) 34: conf ig list = generate independent ext(prim list, M−j , ) 35: end procedure 36: procedure ext list = f ind extrusion(M−j ) � Find sets of primitives to be removed from M−j 37: ext list = f ind visible extrusions(M−j ); 38: ext list = remove ext outside model(M−j , ext list); � Reject primitives not totally included in M−j 39: ext list = remove ext included ext(ext list); � Process only maximal primitives 40: end procedure The main procedure Extract graph of the algorithm 1 processes the node list containing the current variants of the model at the current step ‘backward in time’ using the procedure P rocess variant and compares the new variants to the existing graph nodes using compare conf ig. If variants are identical, graph nodes are merged, which creates cycles. Then, Extract graph adds a tree structure to a given variant corresponding to the new simpler variants derived from M−j . The graph is completed when there is no more variant to process, i.e., node list is empty. Here, the purpose is to remove (using remove primitives) the largest possible amount of primitives Pi whose interfaces IGk are not overlapping each other, i.e., ∀(i, j, k, l), i �= j, IGk ∈ Pi, IGl ∈ Pj , 109Chapter 4: Extraction of generative processes from B-Rep shapes P1 P2 P3 (a) (b) Criterion of Maximal Primitive Criterion of Independence dependent edges independent edges Figure 4.18: Selection of primitives: (a) Maximal primitive criterion not valid for P2 and P3 because they are included in P1, (b) two dependent primitives with common edges in red. IGl ∩ IGk = φ, otherwise δjk would not be meaningful. Selecting the largest possible amount of Pi and assigning them to a graph node is mandatory to produce a compact graph. Each such node expresses the fact that all its Pi could be removed, one by one, in an arbitrary order, which avoids describing trivial ordering changes. The primitive removal operator, described in Section 4.4.3, generates not only simpler solids’ shapes but also simplify the primitives’ contours (using simplify prim contour). Both simpli- fication effects reduce considerably the complexity of the extracted generative processes compared to the initial construction tree of the CAD component. To process each variant M−j of M, P rocess variant starts with the identification of valid visible extrusion primitives in M−j using f ind extrusion (see Sections 4.4.2 and 4.4.3 respectively). However, to produce maximal primitives (see Hypothesis 1), all valid primitives which can be included into others (because their contour or their extrusion distance is smaller than the others) are removed (remove ext included ext). Figure 4.18a shows two primitives P2 and P3 included in a maximal primitive (see Hypothesis 1) P1. Once valid maximal primitives (see Hypothesis 1) have been identified, processing the current variant M−j carries on with contour simplification: simplify prim contour, if it does not impact the shape complexity of M−(j+1) (see Section 4.4.3). Then, all the valid geometric interfaces IGk of each primitive are generated with generate geom interf aces (see Section 4.4.3) and interfaces IGk increasing the shape complexity are discarded with discard complex to ensure the convergence (see Section 4.5.1). Sets of independent primitives are ordered to ease the user’s navigation in the graph. As illustrated in Figure 4.18, two primitives are independent if there is no geometric intersection between them. 4.6 Results of generative process graph extractions The previous process described in Section 4.5 has been applied to a set of components whose shapes are compatible with extrusion processes to stay consistent with 110Chapter 4: Extraction of generative processes from B-Rep shapes (c) (d) (a) T T T B T T B T T T (b) Figure 4.19: Extraction of generative processes for four different components: a, b, c, d. Orange sub-domains highlight the set of visible primitives removed at each step of the graph generation. Construction graph reduces to a tree for each of these components: (a) T and B indicate Top and Bottom views to locate easily the primitives removed. Other components use a single view. 111Chapter 4: Extraction of generative processes from B-Rep shapes algorithm 1 though they are industrial components. The results have been obtained automatically using algorithm 1 implemented using Python and bindings with Open Cascade (OCC) library [CAS14]. The complexity of Algorithm 1 is O(n2). Regarding time, most consuming operations refer to the procedure f ind extrusion which uses boolean operations to verify the validity of each primitive. Therefore, the practical performance of the algorithm is dependent on the robustness and complexity of the boolean operators. Statistics given are the amount of calls to a generic Boolean type operator available in the OCC [CAS14] library, the total number of visible primitives (f ind visible extrusions), nv, and the final number of Pi in the graph, np. Results on industrial shapes Figure 4.19 shows the generative processes extracted from four different and rather simple components. They are characterized by triples (nB; nv; np), (2183; 220; 8), (9353; 240; 31), (8246; 225; 15), (1544; 132; 6), for (a), (b), (c) and (d), respectively. The graph structure reduces to a tree one for each of them. It shows that merging all extrusions in parallel into a single node can be achieved and results into a compact representation. These results also show the need for a constraint that we can formalize as follows: configurations produced by generate independent ext must be such that each variant M−(j+1)k generated from M−j must contain a unique connected component as it is with M. However, this has not been implemented yet. This continuity constraint expresses the fact that M is a continuous medium and its design process follows this concept too. Figure 4.21 illustrates this constraint on the construction graph of a simple solid. The object M−11 is composed of 5 solids which represent a non continuum domain. Consequently, any of its transformation stages must be so to ensure that any simplified model, i.e., any graph node, can stand as basis for an idealization process. Then, it is up to the idealizations and their hypotheses to remove such a constraint, e.g., when replacing a primitive by kinematic boundary conditions to express a rigid body behavior attached to one or more primitives in the graph. Figure 4.20 shows the graph extracted from the component analyzed in Figure 4.1. It is characterized by (111789; 1440; 62). Two variants appear at step 4 and lead to the same intermediate shape at step 8. It effectively produces a graph structure. It can be observed that the construction histories are easier to understand for a user than the one effectively used to model the object (see Figure 4.1). Clearly, the extrusion primitives better meet the requirements of an idealization process and they are also better suited to dimension modification processes as mentioned in Section 4.1. The current implementation of Algorithm 1 uses high-level operators, e.g., boolean operations, rather than dedicated ones. This implementation limits the time reduction which could be achieved compared to the interactive transformations. Issues also lies in the robustness of CAD boolean operators which use quite complex modeling techniques. In a future work, instead of boolean operators, specific operators can be developed for an efficient implementation. 112Chapter 4: Extraction of generative processes from B-Rep shapes M M-1 M-2 M-3 M-3 M-8 M-42 M-52 M-62 M-72 M-7 1 M-6 1 M-5 1 M-4 1 L2 L1 Figure 4.20: Construction graph GD of a component. Orange sub-domains indicate the removed primitives Pi at each node of GD. Labels M−jk indicate the step number j when ‘going back over time’ and the existence of variants k, if any. Arrows described the successive steps of D. Arcs of GD are obtained by reversing these arrows to produce construction trees. Steps M−61 and M−62 differ because of distinct lengths L1 and L2. 113Chapter 4: Extraction of generative processes from B-Rep shapes M M-1 M 2 -11 Non continuous medium ( 5 solids) Continuous medium ( 1 solid) Figure 4.21: Illustration of the continuity constraint with two construction processes of an object M. The generated object M−11 is composed of 5 independent solids which represent a non continuum domain. Object M−12 contains one solid which represents a continuum domain. Equivalence between a graph representation and a set of construction trees Also, GD is a compact representation of a set of construction processes. Figure 4.22 illustrates the equivalence between a set of construction trees and the graph representation GD. There, the set of primitives removed from M−j to obtain M−(j+1) is characterized by the edge α−j,−(j+1) of GD that connects these two models. The cardinality of this set of primitives is nj . If these nj primitives are related to different sketching planes, they must be attached to nj different steps of a construction tree in a CAD software. Without any complementary criterion, the ordering of these nj primitives can be achieved in nj ! different ways involving nj additional nodes and edges in GD to represent the corresponding construction tree. Here, it is compacted into a single graph edge α−j,−(j+1) in GD between M−j and M−(j+1). Furthermore, the description of this set of tree structures requires the expansion of α−j,−(j+1) into the nj ! construction tree structures ending up to M−j . This modification of GD generates new cycles in GD between M−j and M−(j+1). Indeed, the graph structure of GD is a much more compact structure than the construction tree of CAD software. All the previous results and observations show that GD is a promising basis for getting a better insight about a shape structure and evaluating its adequacy for idealizations. 4.7 Extension of the component segmentation to assembly structure segmentation This section explains how the generative processes used for single B-Rep component can be adapted to assembly structures of several B-Rep components. 114Chapter 4: Extraction of generative processes from B-Rep shapes M-j M-(j+1) Contruction Trees Graph GD Compact representation of nj primitives in one edge α-j,-(j+1) 1 - 4 5 7 6 8 9 9 7 - 8 1 - 6 7 1 - 6 7 9 8 ... !nj ordering possibilities corresponding the nj primitives Figure 4.22: A set of CAD construction trees forming a graph derived from two consecutive construction graph nodes. 115Chapter 4: Extraction of generative processes from B-Rep shapes P7 P3 P17 P1 P2 P4 P6 P8 P9 P10 P11 P12 P13 P14 P15 P16 P18 P5 Interface Graph between primitives C1 C2 C3 C4 Interface Graph between components (a) Component (b) Assembly Figure 4.23: Illustration of the compatibility between the component segmentation (a) and assembly structure segmentation (b). Equivalence between generative processes of components and assembly structures As explained in 1.3.1, a CAD assembly structure contains a set of volume B-Rep components located in a global reference frame. The method of Jourdes et al. [JBH∗14] enriches the assembly with geometric interfaces between components. Shahwan et al. [SLF∗12, SLF∗13] further enrich the results of Jourdes et al. with functional designation of components. As a result, the final assembly model is composed of a set of 3D solid components connected to each other through functional interfaces. An equivalence can be made between this enriched assembly structure (see Figure 4.23b) and generative processes of components. Indeed, a solid decomposition of each component can be derived from its generative processes expressed with GD. It provides intrinsic structures of components made of 3D solid primitives linked by geometric interfaces (see Figure 4.23a). These structures are compatible with the assembly structure also described using 3D solids and interfaces. The decomposition of each component, GD, can be integrated into an assembly graph structure. Figure 4.24a illustrates an assembly of two components C1 and C2 connected by one assembly interface I1,2. In 4.24b, each component is subdivided into two primitives (P1,1, P1,2) and (P2,1, P2,2), respectively, linked by geometric interfaces I11,12 and I21,22 , respectively. Now, the assembly structure can be represented by a graph GA where nodes represent the assembly components and edges contains functional assembly interfaces. Each solid decomposition of a component Ci also constitutes a graph structure GDi which can be nested into the nodes of GA, see 4.24c, in a first place. 116Chapter 4: Extraction of generative processes from B-Rep shapes Graph of the final enriched assembly model P1.1 P1.2 C1 C2 I1/2 I1/2 P1.1 P1.2 P2.2 P2.1 I1.1/1.2 P2.1 P2.2 I1/2 I2.1/2.2 I1.1/1.2 Assembly structure Components segmentation (a) (b) (c) Figure 4.24: Insertion of the interface graphs between primitives obtained from component segmentations into the graph of assembly interfaces between components GA: (a) The assembly structure with its components and assembly interfaces between these components, (b) the components segmented into primitives and interfaces between these primitives forming GDi , (c) the graph of the final enriched assembly model. Advantages for the shape analysis of components and assemblies The compatibility of the component segmentation with the assembly graph structure is a great benefit for the analysis algorithms dedicated to the determination of the simulation modeling hypotheses. Considering sub-domains and interfaces as input data to a general framework enabling the description of standalone components as well as assemblies, the analysis algorithms can be applied at the level of a standalone component as well as at the assembly level. This property extends the capabilities of the proposed FEA pre-processing methods and tools from the level of standalone components to an assembly level and contributes to the generation of FE analyses of assembly structures. However, it has to be pointed out that the nesting mechanism of GA and GDi has been briefly sketched and a detailed study is required to process configurations in which component interfaces are not exactly nested into component primitive faces, e.g., interface I1,2 that covers faces of P2,1 and P2,2. Additionally, interfaces used for illustration are all of type surface, whereas interfaces between primitives can be of types surface or volume and geometric interfaces between components can be of type contact or interference. If, in both cases, this leads to common surfaces or volumes, the detailed study of these configurations is left to future work to obtain a thorough validation. 4.8 Conclusion This chapter has described a new approach to decompose a B-Rep shape into volume sub-domains corresponding to primitive shapes, in order to obtain a description that is intrinsic to this B-Rep shape while standing for a set of modeling actions that will be used to identify idealizable sub-domains. 117Chapter 4: Extraction of generative processes from B-Rep shapes Construction trees and shape generation processes are common approaches to model mechanical components. Here, it has been shown that construction trees can be extracted from the B-Rep model of a component. Starting with a B-Rep object free of blends, the proposed approach processes it by iteratively identifying and removing a set of volume extrusion primitives from the current shape. The objective of this phase is to ‘go back in time’ until reaching root primitives of generative processes. As a result, a set of non-trivial generative processes (construction trees) is produced using the primitives obtained at the end of this first phase. It has been shown that construction trees are structured through a graph to represent the non trivial collection of generative processes that produce the input B-Rep model. This graph contains non trivial construction trees in the sense that neither variants of extrusion directions producing the same primitive are encoded nor are the combinatorial variants describing the binary construction trees of CAD software, i.e., material addition operations that can be conducted in parallel are grouped into a single graph node to avoid the description of combinatorial combinations when primitives are added sequentially as in CAD software. Thus, each node in the construction graph can be associated with simple algorithms to generate the trivial construction variants of the input object. The proposed method includes criteria which generate primitives with simple shapes and which ensure that the shape of intermediate objects is simplified after each primitive suppression. These properties guarantee the algorithm to be convergent. Finally, a graph of generative processes of a B-Rep component is a promising basis to gain a better insight of a shape structure and to evaluate its adequacy for idealizations. It has been illustrated that this process can also be extended to the assembly context with the nesting of the primitive-interface structure with respect to the componentinterface one. The next Chapter 5 describes how a construction graph can be efficiently used in an idealization process. 118Chapter 5 Performing idealizations from construction graphs Benefiting from the enrichment of a component shape with its construction graph, this chapter details the proposed morphological approach and the idealization process to generate idealized representations of a component shape’ primitives. Based on this automated decomposition, each primitive is analyzed in order to define whether it can be idealized or not. Subsequently, geometric interfaces between primitives are taken into account to determine more precisely the idealizable sub-domains. These interfaces are further used to process the connections between the idealized sub-domains generated from these primitives to finally produce the idealized model of the initial object. Also it is described how the idealization process can be extended to assembly models. 5.1 Introduction According to Section 1.5.4, shape transformations taking place during an assembly simulation preparation process interact with simulation objectives, hypotheses, and shape transformations applied to standalone components and to their assembly interfaces. Section 2.3 underlines the value of a shape analysis prior to the application of these transformations to characterize their relationship with geometry adaption and FEA modeling hypotheses, especially in the scope of idealization processes which need to identify the candidate regions for idealization. As explained in Chapter 2, prior research work has concentrated on identifying idealizable areas rather than producing simple connections between sub-domains [LNP07b, SSM∗10, MAR12, RAF11]. Recent approaches [CSKL04, Woo14] subdivide the input CAD model into simpler sub-domains. However, these segmentation algorithms do not aim at verifying the mechanical hypotheses of idealization processes and the identified features found do not necessarily produce appropriate solids for dimensional reduction operators. The idealization process proposed in this chapter benefits from the shape 119Chapter 5: Performing idealizations from construction graphs IP2/P3 C1 IP2/P3 Graph of volume primitives of C1 P1 P2 P3 IP1/P3 P3 P1 P2 IP1/P3 Component C1 Medial Surfaces e1 e2 e3 P1 P2 P3 Idealizable subdomains Non idealizable subdomains e1 e2 e3 Thickness Morphological analysis of component Full idealized CAD model Construction graph Figure 5.1: From a construction graph of a B-Rep shape to a full idealized model for FEA. structure produced by construction graphs generated from a component as a result of the process described in Chapter 4 and containing volumes extrusion primitives which can be already suited to idealization processes. This construction graph directly offers the engineer different segmentation alternatives to test various idealization configurations. Starting from a construction graph of a B-Rep model, this chapter describes a morphological analysis approach to formalize the modeling hypotheses for the idealization of a CAD component. This formalization leads to the generation of a new geometric structure of a component that is now dedicated to the idealization process. Figure 5.1 illustrates the overall process which is then described in the following sections. Section 5.2 explains the advantages of applying a morphological analysis on a component shape and states the main categories of morphology that needs to be located. Section 5.3 describes the general algorithm proposed to analyze the morphology of a B-Rep shape from its generative processes containing extrusion primitives. The algorithm evaluates each primitive morphology and process interfaces between these primitives to extend the morphological analysis to the whole object. Section 5.4 studies the influence of external boundary conditions and of assembly interfaces on the new component structure. There, the objective is to determine the adequacy of the proposed approach with an assembly structure. Section 5.5 illustrates the process to derive idealized models from a set of extrusion primitives and geometric interfaces. 5.2 The morphological analysis: a filtering approach to idealization processes A common industrial principle of the FEA of mechanical structures is to process the analysis step-by-step using a top-down approach. To simulate large assembly struc- 120Chapter 5: Performing idealizations from construction graphs tures, i.e., aeronautical assemblies, a first complete idealized mesh model is generated to evaluate the global behavior of the structure. Then, new local models are set up to refine the global analysis in critical areas. At each step of this methodology, the main purpose of the pre-processing task is to generate, as quickly as possible, a well suited FE model. In the industry, guidelines have been formalized to help engineers defining these FE models and correctly applying the required shape transformations. Although these guidelines are available for various simulation objectives, there are still difficulties about: • The model accuracy needed to capture the mechanical phenomenon to be evaluated. An over-defined model would require too many resources and thus, would delay the results. In case of large assemblies, the rules set in the guidelines are very generic to make sure a global model can be simulated in practice. This way, the FEM is not really optimized. As an example, the mesh size is set to a constant value across all geometric regions of the components and is not refined in strategic areas. Section 1.4 points out current engineering practices to generate large FE assembly models; • The application of modeling rules. The engineer in charge of the FEM creation has difficulties when identifying the regions potentially influencing or not the mechanical behavior of the structure, prior to the FEA computation results. In addition, evaluating the geometric extent of the regions to be idealized as well as determining the cross influences of geometric areas on each other are difficult tasks for the engineer because they can be performed only mentally, which is even harder for 3D objects. Section 2.3 highlights the lack of idealization operators to delimit their conditions of application. In case of large assembly data preparation, automated tools are required (due to model size and time consuming tasks). These tools have to produce simulation models in line with the two previous challenges (model accuracy and rule-based modeling). In the following sections, we introduce approaches to deal with such challenges using morphological analysis tools. These tools support the engineers when comparing the manufactured shape of a component with the simplification and idealization hypotheses needed to meet some simulation hypotheses. 5.2.1 Morphological analysis objectives for idealization processes based on a construction graph As introduced in Chapter 3, a major objective of this thesis aims at improving the robustness of FE pre-processing using a shape analysis of each component before the application of shape transformation operators. For a simulation engineer, the purpose is to understand the shape, support the localization of transformations, and to build 121Chapter 5: Performing idealizations from construction graphs the different areas to transform in the initial CAD models. This scheme contributes to an a priori approach that illustrates the application of modeling hypotheses, especially the idealization hypotheses. In addition, this approach is purely morphological, i.e., it does not depend on discretization parameters like FE sizes. Morphological categories identified in solid models The first requirement of the idealization process is to identify which geometric regions of the object contain proportions representing a predefined mechanical behavior. In the scope of structural simulations, the predefined categories representing a specific mechanical behavior correspond to the major finite element families listed in Table 1.1. These categories can be listed as follows: • Beam: a geometric sub-domain of an object with two dimensions being signifi- cantly smaller than the third one. These two dimensions define the beam cross section; • Plate and shell: a geometric sub-domain of an object with one dimension being significantly smaller than the two others. This dimension defines the thickness of the plate or the shell, respectively; • 3D thick domain: a geometric sub-domain that does not benefit from any of the previous morphological properties and that should be modeled with a general 3D general continuum medium behavior. From a geometric perspective, the principle of the idealization process corresponds to a dimensional reduction of the manifold representing a sub-domain of the solid object, as defined in 1.2.1. A detailed description of the idealization hypotheses is available in Section 1.4.2. To construct fully idealized models derived from an object M, geometric connection operations between idealized sub-domains must be performed. As stated in Chapter 2, automated geometric transformations do not produce accurate results in connections areas. The main issue lies in the determination of the geometric boundaries where the connection operators must process the idealized sub-domains (see Figure 2.8). Currently, the engineer applies these operators manually to define the direction and the extent of the connection areas (see Figure 1.15 illustrating a manual process to connect medial surfaces). The proposed idealization process benefits from an enriched initial component model with a volume segmentation into sub-domains and into interfaces between them that contain new geometric information to make the connections operators robust. This segmentation gives the engineer, a visual understanding of the impact of simulation hypotheses on the component geometry. Additionally, the proposed analysis framework identifies the regions that can be regarded as details, independently of the resolution method. These regions represents areas having no significant mechanical influence with respect to the morphological category of their neighboring regions. 122Chapter 5: Performing idealizations from construction graphs In case of assembly structures, the categories presented above are still valid at the difference that the identified geometric domains are not anymore a sub-domain restricted to a single solid. Indeed, a group of components can be considered as a unique beam, plate, or shell element. In this case, if the interfaces between a group of connected sub-domains from different components have been defined as mechanically rigid connections by the engineer, this group of sub-domains can also be identified as a unique continuum, hence distinguishing components is not necessary anymore. The effects of assembly interfaces are detailed in Section 5.4. Adequacy of generative construction graphs with respect to the morphological analysis A shape decomposition is a frequent approach to analyze and structure objects for FEA requirements. Section 2.4 has highlighted the limits of current morphological analysis methods and underlined the need of more robust automatic techniques adapted to FE model generation. The proposed approach uses the generative construction graph GD to perform a morphological analysis of CAD components adapted to FEA requirements. Section 4.2 has addressed the advantages of construction graphs to structure the shape of a component. It proposes a compact shape decomposition of primitives containing a fair amount of information that is intrinsic to this shape. The geometric structure of GD with sub-domains and associated interfaces is close to the structure described in Section 5.2.1 with regions candidate to idealization. GD also offers various construction processes which enable the engineer to construct and study various simulation models that can be derived from the same component using different construction processes. Generating the idealization of an object M from a set of primitives, obtained from its construction graph GD, is more robust compared to the prior idealization methods for three reasons: • The information contained in GD is intrinsic to the definition of primitives. Each maximal primitive Pi ∈ GD and its associated interfaces determine both the 3D location of the idealized representation of Pi and its connections with its neighboring idealized primitives; • The effective use of connections between sub-domains to be idealized. A taxonomy of categories of connections can be defined. This classification determines the most suitable geometric operator to process each connection. Currently, the idealization process still relies on the engineer’s expertise to manage complex connections whereas a CAD or a CAE software is bound to much simpler connections; • Shape modification processes of components. When a component shape modification is performed, only the impacted primitives have to be revised in its 123Chapter 5: Performing idealizations from construction graphs · Global morphological analysis of each primitive Pi using extrusion distance · Morphological analysis of the extrusion contour of each primitive Pi and determination of the geometric sub-domains Dj(Pi)to be idealized in Pi Morphological analysis of the primitives Pi 01 step Extension of the morphological analysis of primitives Pi to the whole object 02 step · Categorization of the interfaces IG between primitives Pi · Segmentation of the primitives Pi in new partitions P’ based on the interfaces IG typology · Merge or make independent the new partitions P’ with the primitives Pi to obtain a segmentation which is most suited for idealization Idealization of the primitives Pi and processing connections · Generation of mid-surface and mid-lines of the primitives Pi to be idealized · Connections of the idealized models of the primitives Pi 03 step Figure 5.2: Global description of an idealization process. construction graph. Therefore, the idealization process can be locally updated and does not have to be restarted over from its shape decomposition. The next section details the structure of the proposed idealization process from the exploitation of the geometric information provided with the construction graph GD of a component to the generation of its idealized models. 5.2.2 Structure of the idealization process The idealization process of an object M is based on morphological analysis operations, idealization transformations and connections between idealized sub-domains. Its objective is to produce the idealized model, denoted by MI , of the initial object M. Figure 5.2 contains a comprehensive chart illustrating the various steps of the proposed idealization process. In a first step, the decomposition of M into primitives Pi, described in the graph GD, leads to a first morphological analysis of each primitive Pi. For each extrusion primitive, this morphological analysis determines whether Pi has a morphology of type plate, shell, or a morphology of type thick 3D solid (see Section 5.2 describing the morphology categories). This first step is described in Section 5.3.1. Then, a second morphological analysis is applied to each primitive Pi to determine whether or not it can be subdivided into sub-domains Dij , morphologically different from the one assigned to Pi. This analysis is performed using the 2D extrusion contour 124Chapter 5: Performing idealizations from construction graphs of the primitive Pi. The resulting decomposition of Pi generates new interfaces IG, integrated in GD. In a second phase, using a typology of connections between the different categories of idealizations, the interfaces IG between Dij are used to propagate and/or update the boundary of the primitives Pi. This step, described in Section 5.3.3, results in the decomposition of the object M into sub-domains with a morphology of type beam, plate/shell, or 3D thick solid. The third phase consists in generating the idealization of each primitive Pi and then, it connects the idealized domains of Pi using the typology and the location of the interfaces IG. During this operation, the morphology of each Pi, combined with the typology of each of its interfaces IG, is used to identify regions to be considered as details, independently from any FE size. The generation of an idealized model is described in Section 5.5. Overall, the different phases illustrated in Figure 5.2 fit into an automated process. The engineer can be involved in it to select some connection model between idealized sub-domains or some boundary adjustment category of idealized sub-domain depending on its types of connections. The next sections detail each step of the proposed idealization process. 5.3 Applying idealization hypotheses from a construction graph The purpose of this section is to illustrate how the construction graph GD of an object M obtained with the algorithm described at Section 4.5.2 can be used in shape idealization processes. In fact, idealization processes are high level operations that interact with the concept of detail because the idealization of sub-domains, i.e., Pi obtained from GD, triggers their dimensional reduction, which, in turn, influences the shape of areas around IGs, the geometric interfaces between these sub-domains. Here, the proposed approach is purely morphological, i.e., it does not depend on discretization parameters like FE sizes. It is divided into two steps. Firstly, each Pi of GD is evaluated with respect to an idealization criterion. Secondly, according to IGs between Pis, the ‘idealizability’ of each Pi is propagated in GD through the construction graph up to the shape of M. As a result, an engineer can evaluate effective idealizable areas. Also, it will be shown how variants of construction trees in GD can influence an idealization process. Because the idealization process of an object is strongly depending on the engineer’s know-how, it is the principle of the proposed approach to give the engineer access to the whole range of idealization variants. Finally, some shape details will appear subsequently to the idealization process when the engineer will define FE sizes to mesh the idealized representation of M. 125Chapter 5: Performing idealizations from construction graphs e Thickness Max Diameter d d (a) (b) e Figure 5.3: Determination of the idealization direction of extrusion primitives using a 2D MAT applied to their contour. (a) Configuration with an extrusion distance (i.e., thickness d = e) much smaller than the maximal diameter obtained with the 2D MAT on the extrusion contour, the idealization direction corresponds to the extrusion direction (b) Configuration with an extrusion distance much larger than the maximal diameter obtained with the 2D MAT on the extrusion contour, the idealization direction is included in the extrusion contour. 5.3.1 Evaluation of the morphology of primitives to support idealization Global morphological analysis of each primitive Pi In a first step, each primitive Pi extracted from GD is subjected to a morphological analysis to evaluate its adequacy for idealization transformation into a plate or a shell. Because the primitives are all extrusions and add material, analyzing their morphology can be performed with a MAT [MAR12, RAM∗06, SSM∗10]. A MAT is particularly suited to extrusion primitives having constant thickness since it can be applied in 2D. Furthermore, it can be used to decide whether or not subdomains of Pi can be assigned a plate or shell mechanical behavior. In the present case, the extrusion primitives obtained lead to two distinct configurations (see Figure 5.3). Figure 5.3a shows a configuration with a thin extrusion, i.e., the maximal diameter Φ obtained with the MAT from Pi’s contour is much larger than Pi’s thickness defined by the extrusion distance d. Then, the idealized representation of Pi would be a surface parallel to the base face having Pi’s contour. Figure 5.3b shows a configuration where the morphology of Pi leads to an idealization that would be based on the content of the MAT because d is much larger than Φ. To idealize a sub-domain in mechanics [TWKW59], a commonly accepted reference proportion used to decide whether a sub-domain is idealizable or not is a ratio of ten between the in-plane dimensions of the sub-domain and its thickness, i.e., xr = 10. Here, this can be formalized with the morphological analysis of Pi obtained from the MAT using: x = max((max Φ/d),(d/max Φ)). Consequently, the ratio x is applicable for all morphologies of extrusion primitives. 126Chapter 5: Performing idealizations from construction graphs d: extrusion distance d = 2 (b) (c) d < max Ø x = d > max Ø x d = max Ø max Ø Ratio x MAT 2D d = 35 0 3 xu xr 1.5 < <25 x 1.5 = 25 = 16.6 d = 1.5 (a) Max Diameter Ø = 25 Max Diameter Ø = 10 d = 25 Max Diameter Ø = 25 Primitive Morphology (d) 35 > 10 x 10 = 35 = 3.5 2 < 10 x 2 = 10 = 5 25 = 25 x 25 = 25 = 1 10 Max Diameter Ø = 10 d Table 5.1: Categorization of the morphology of a primitive using a 2D MAT applied to the contour of extrusion primitives. Violet indicates sub-domains that cannot be idealized as plates or shells (see component d), green ones can be idealized (see component a) and yellow ones can be subjected to user decision (see component b and c). 127Chapter 5: Performing idealizations from construction graphs Because idealization processes are heavily know-how dependent, using this reference ratio as unique threshold does not seem sufficient to help an engineer analyze sub-domains, at least because xr does take precisely into account the morphology of Pi’s contour. To let the engineer tune the morphological analysis and decide when Pi can/cannot be idealized a second, user-defined threshold, xu < xr, is introduced that lies in the interval ]0, xr[. Figure 5.3b illustrates a configuration where the morphological analysis does not produce a ratio x > xr though a user might idealize Pi as a plate. Let xu = 3 be this user-defined value, Table 5.1 shows the application of the 2D MAT to the contours of four extrusion primitives. This table indicates the three categories made available to the engineer to visualize the morphology of Pi. Primitives with a ratio of x > xr, e.g., primitive (a), are considered to be idealizable and are colored in green. Primitives with a ratio of xu < x < xr, e.g., primitives (b) and (c), are subjected to a user’s decision for idealization and are colored in yellow. Finally, primitives with a ratio x < xu, e.g., primitive(d), indicate sub-domains that cannot be idealized and are colored in violet. Figure 5.4 illustrates the evaluation of the morphology of the primitives of a component prior to its idealization. The component has been initially segmented into 15 extrusion primitives using the algorithm presented at Section 4.5.2. Then, the 2D MAT has been applied to the extrusion contour of each primitive to determine the maximal diameter Φ. Finally, this diameter is compared to the extrusion distance of the corresponding primitive to determine the ratio x. Three morphological evaluations are presented in Figure 5.4 that correspond to different values of the thresholds xu and xr, which are set to (a) (3, 10), (b) (6, 10), and (c) (2, 10), respectively. Figure 5.5 shows the result of the interactive analysis the user can perform from the graphs GD obtained with the components analyzed in Figures 5.5a, b, c, and d. It has to be mentioned that the morphological analysis is applied to GD rather than to a single construction tree structure so that the engineer can evaluate the influence of D with respect to the idealization processes. However, the result obtained on the component in Figure 4.20 shows that the variants in GD have no influence with respect to the morphological analysis criterion, in the present case. Consequently, Figure 5.5 displays the morphological analysis obtained from the variant M−j2 in Figure 4.20. Results on components in 5.5a, c also show the clear use of this criterion because some nonidealizable sub-domains (see indications in Figure 5.5 regarding violet sub-domains) are indeed well proportioned to be idealized with beams. Now, considering the morphological classification of sub-domains stated in Section 5.2.1, this first morphological analysis of Pi acts as a necessary condition for Pi to fall into a category of: • plate/shell but Pi can contain sub-domains Dij where Φ can get small enough to produce a beam-like shape embedded in Pi, see Figure 5.6a. In any case, Pi 128Chapter 5: Performing idealizations from construction graphs Ø 0 3 10 x Ø Ø Ø Max Diameter Ø Extrusion distance d xr xu v 0 6 x xr xu Ratio x 0 2 x xr xu 10 10 Ø Ø Ø Ø Ø Evaluation of sub domain for idealization Identification of Maximal diameter in 2D sketch using MAT Segmentation from Construction Graph d < max Ø x = d > max Ø x d = max Ø max Ø d (a) (b) (c) Figure 5.4: Example of the morphological evaluation of the extrusion primitives extracted during the construction process of a component. Violet indicates sub-domains that cannot be idealized as plates or shells, green ones can be idealized and yellow ones are up to the user’s decision. 129Chapter 5: Performing idealizations from construction graphs T T B B sub domains idealizable as beams (a) (c) T B 0 3 10 x xr xu T B (b) (d) Figure 5.5: Idealization analysis of components. T and B indicate Top and Bottom views of the component, respectively. The decomposition of a is shown in Figure 4.20 and decompositions of b, c and d are shown in Figure 4.19. Violet indicates sub-domains that cannot be idealized as plates or shells, green ones can be idealized and yellow ones can be subjected to user’s decisions. 130Chapter 5: Performing idealizations from construction graphs Beam local sub-domain to idealize as beam local sub-domain to consider as detail local sub-domain to idealize as beam Beam Primitive Pi Dij Dik d local Ø ≈ d << max Ø max Ø local Ø local Ø ≈ d << max Ø d d local Ø << d ≈ max Ø Detail (a) (b) (c) Figure 5.6: Illustration of primitives’ configurations containing embedded sub-domains Dik which can be idealized as beams or considered as details. (a) Primitive morphologically identified as a plate which contains a beam sub-domain, (b) primitive morphologically identified as a plate which contains a volume sub-domain to be considered as a detail, (c) primitive morphologically identified as a thick domain which contains a beam sub-domain cannot contain a sub-domain of type 3D thick domain because the dominant sub-domain Dij is morphologically a plate/shell. If there exists a sub-domain Dik, adjacent to Dij , such that x < xu, i.e., it is morphologically thick, Dik is not mechanically of type 3D thick domain because it is adjacent to Dij . Indeed, Dik can be regarded as a detail compared to Dij since the thickness of Dij will be part of the dimensional reduction process. Figure 5.6b shows an example of such configuration; • 3D thick domain because Pi contains at least one dominant sub-domain Dij of this category. However, it does not mean that Pi does not contain other subdomains Dik that can be morphologically of type plate/shell or beam. Figure 5.6b illustrates a beam embedded in a 3D thick domain. Indeed, all green sub-domains and yellow ones validated by the engineer can proceed with the next step of the morphological analysis. Similarly, violet sub-domains cannot be readily classified as non idealizable. Such configurations show that the classification described in Section 5.2.1 has to take into account the relative position of sub-domains Dij of Pi and they are clearly calling for complementary criteria that are part of the next morphological analysis where Pi needs to be decomposed into sub-domains Dij to refine its morphology using information from its MAT. 131Chapter 5: Performing idealizations from construction graphs Determination of geometric sub-domains Dij to be idealized in Pi Then, in a second step, another morphological analysis determines in each primitive Pi if some of its areas, i.e., sub-domains Dij , can be associated with beams and, therefore, admit further dimensional reduction. Indeed, the previous ratio x determines only one morphological characteristic of a sub-domain Dij , i.e., the dominant one, of Pi because the location of the MAT, where x is defined, is not necessarily reduced to a point. For example, Figure 5.7 illustrates a configuration where x holds along a medial edge of the MAT of the extrusion contour. Similarly to the detail removal using MAT conducted by Armstrong et al. [Arm94], a new ratio y is introduced to compare the length of the medial edge to the maximal disk diameter along this local medial edge. The parameter y is representative of a local elongation of Pi in its contour plane and distinguishes the morphology of type beam located inside a morphology of type plate or shell when the starting configuration is of type similar to Figure 5.3a. If Pi is similar to Figure 5.3b, then the dominant Dij is of type beam if x appears punctually or of type plate/shell if x appears along a medial edge of the MAT of the extrusion contour of Pi. Appendix C provides two Tables C.1 and C.2 with 18 morphological configurations associated with a MAT medial edge of a primitive Pi. The two tables differ according to whether the idealization direction of Pi corresponds to the extrusion direction, see Table C.1 (type similar to Figure 5.3a), or whether the idealization direction of Pi is included in the extrusion contour, see Table C.2 (type similar to Figure 5.3b). The reference ratio xr and user ratio xu are used to specify, in each table, the intervals of morphology differentiating beams, plates or shells and 3D thick domains. Therefore, nine configurations are presented in Table C.1 illustrating the elongation of the extrusion contour of Pi. Table C.1 allows both the elongation of the extrusion distance and the elongation of the extrusion contour, this produces also nine configurations. These tables illustrates 18 morphological possible configurations when the medial edge represents a straight line with a constant radius for the inscribed circles of the MAT. Other configurations can be found when the medial edge is a circle, or more generally, a curve or when the radius is changing along the medial edge. These configurations have not been studied in detail and are left for future work. L1 L2 max Ø x = L1 / max Ø y = L2 / max Ø xu = 10 (user threshold) L1 < xu . max Ø L2 > xu . max Ø Figure 5.7: Example of a beam morphology associated with a MAT medial edge of a primitive Pi. 132Chapter 5: Performing idealizations from construction graphs Tables C.1, C.2 of Appendix C represents a morphological taxonomy associated with one segment of the MAT of Pi. Because the extrusion contour of Pi consists in line segments and arcs of circles, the associated MAT has straight and curvilinear medial edges which can be categorized as follows: 1. Medial edges with one of their end point located on the extrusion contour of Pi, the other one being connected to another medial edge; 2. Medial edges with their two end points connected to other medial edges. In the special case of a segment having no end point, e.g., when the extrusion contour is a circular ring, its MAT reduces to a closed circle and falls into this category. Segments of category 1 are deleted and the morphological analysis focuses on the segments of category 2 which are noted Sij . On each of these edges, the ratio y includes a maximum located at an isolated point or it is constant along the entire edge. ymax represents this maximum and is assigned to the corresponding medial edge, Sij . The set of edges Sij is automatically classified using the taxonomy of Tables C.1, C.2 or some of them can be specified by the engineer wherever yu < y < yr. This is the interactive part left to the engineer to take into account his, resp. her, know-how. Pi is segmented based on the changes in the morphological classification of the edges Sij . This decomposition generates a set of sub-domains Dij of each primitive Pi. These sub-domains Dij are inserted with their respective morphological status and their geometric interfaces in the graph GD. Figure 5.8 summarizes the different phases of the morphological analysis of each extrusion primitive Pi extracted from the construction graph GD of on object M. Because each sub-domain Dij is part of only one primitive Pi, it can also be considered as a new primitive Pk. To reduce the complexity in the following process, the sub-domains Dij are regarded as independent primitives Pk. These results are already helpful for an engineer but it is up to him, or her, to evaluate the mechanical effect of IGs between primitives Pi. To support the engineer in processing the stiffening effects of IGs, the morphological analysis is extended by a second step described as follows. 5.3.2 Processing connections between ‘idealizable’ sub-domains Dij The morphological analysis of standalone primitives Pi is the first application of GD. Also, the decomposition obtained can be used to take into account the stiffening effect of interfaces IG between Pi or, more generally, between Dij , when Pi 1 are iteratively 1From now on Pi designates sub-domains that correspond to primitives Pi obtain from the segmentation of M or one subdivision domain Dkj of a primitive Pk decomposed after the morphological analysis described at Section 5.3.1. 133Chapter 5: Performing idealizations from construction graphs For each extrusion primitivePi MAT 2D on extrusion contour of Pi Input: set of primitives Pi from construction graph GD of an object M Output: set of sub-domains Dij of morphology type beams, plates or shells and 3D thick domains Determination of Pi global morphology (x =max((max Φ / d), (d / max Φ)) For each medial edge Sij of the MAT 2D of category 2 Determination of the morphology associated with Sij (y = LSij / max Φ ) If morphology (Sij) ≠ morphology (Pi) and Sij not a detail Segmentation of Pi in sub-domains Dij and insertion in GD Primitive Pi Figure 5.8: Synthesis of the process to evaluate the morphology of primitives Pi. merged together along their IG up to obtain the whole object M. As a result, new sub-domains will be derived from the primitives Pi and the morphological analysis will be available on M as a whole, which will be easier to understand for the engineer. To this end, a taxonomy of connections between extrusion sub-domains is mandatory. Taxonomy of connections between extrusion sub-domains to be idealized This taxonomy, in case of ”plate sub-domain connections”, is summarized in Figure 5.9a. It refers to parallel and orthogonal configurations for simplicity but these configurations can be extended to process a larger range of angles, i.e., if Figure 5.9 refers to interfaces IG of surface type, these configurations can be extended to interfaces IG of volume type when the sub-domains S1 and S2 are rotated w.r.t. each other. More specifically, it can be noticed that the configuration where IG is orthogonal to the medial surfaces of S1 and S2 both is lacking of robust solutions [Rez96, SSM∗10] and other connections can require deviation from medial surface location to improve the mesh quality. Figure 5.18c illustrates such configurations and further details are given in Section 5.5.2. Figure 5.9 describes all the valid configurations of IG between two sub-domains S1 and S2 when a thickness parameter can be attached to each Pi, which is presently the case with extrusion primitives. Figure 5.9a depicts the four valid configurations: named type (1), (2), (3), (4). These configurations can be structured into two groups: type (1) and type (4) form the 134Chapter 5: Performing idealizations from construction graphs (b) S2 S2 S1 S1 S2 S1 S2 S1 (c) Fb1S1 Fb1S2 Fb1S2 IG IG Orthogonal to S1 and Parallel to S2: Orthogonal: Parallel: Parallel: S1 // S2 Orthogonal: Medial Surface S1 vs Medial Surface S2 Interface IG vs Medial Surface S1 & S2 S1 S1 S1 S1 S2 S2 S2 S2 IG IG IG IG IG ^ S1 IG // S2 type (1) I'G I'G I'G I'G IG ^ S1 IG ^ S2 IG // S1 IG // S2 type (1) e1 e2 e1 e1 e1 e2 e2 e2 e1+e2 e1+e2 e1+e2 I'G I'G S'1 S'2 S'3 type (4) e2 e1 e2 e1 e2 I'G I'G S''21 S''22 S'21 S'22 type (2) (a) type (2) type (3) type (4) type (2) type (2) type (2) type (1) type (4) C2 C1 C1 C2 Figure 5.9: (a) Taxonomy of connections between extrusion sub-domains Pi. (b) Decomposition of configurations type(1) and type(4) into sub-domains Pi showing that the decomposition produced reduces to configurations type (2) only. (c) example configurations of types (1) and (4) where S1 and S2 have arbitrary angular positions that generate volume interfaces IG where base faces Fb1S1 and Fb1S2 are intersection free in configuration type (1) and Fb1S2 only is intersection free in configuration type (4). 135Chapter 5: Performing idealizations from construction graphs group C1, and (2) and type (3) form the group C2. Figure 5.9b illustrates the effect of the decomposition of configurations type (1) and type (4) that produces configurations (2) only. Reduced set of configurations using the taxonomy of connections Configuration type (1) of C1 is such that the thicknesses e1 and e2 of S1 and S2 respectively, are influenced by IG, i.e., their overlapping area acts as a thickness increase that stiffens each of them. This stiffening effect can be important to be incorporated into a FE model as a thickness variation to better fit the real behavior of the corresponding structure. Their overlapping area can be assigned to either S1 or S2 or form an independent sub-domain with a thickness (e1 + e2). If S1 and S2 are rotated w.r.t. each other and generate a volume IG, the overlapping area still exists but behaves with a varying thickness. Whatever the solution chosen to represent mechanically this area, the sub-domains S1 and S2 get modified and need to be decomposed. The extent of S2 is reduced to produce S� 2 now bounded by I� G. Similarly, the extent of S1 is reduced to S� 1 now bounded by another interface I� G. A new sub-domain S� 3 is created that contains IG and relates to the thickness (e1 + e2) (see Figure 5.9b). Indeed, with this new decomposition IG is no longer of interest and the new interfaces I� G between the sub-domains S� i produce configurations of type (2) only. Similarly, configuration (4) is such that S2 can be stiffened by S1 depending on the thickness of S1 and/or the 2D shape of IG (see examples in Figure 5.11). In this case, the stiffening effect on S2 can partition S2 into smaller sub-domains and its IG produces a configuration of type (2) with interfaces I� G when S2 is cut by S1. The corresponding decomposition is illustrated in Figure 5.9b and Figure 5.10. This time, IG is still contributing to the decomposition of S1 and S2 but S2 can be decomposed in several ways (S� 21 , S� 22 ) or (S�� 21 , S�� 22 ) producing interfaces I� G. Whatever, the decomposition selected to represent mechanically this area, the key point is that I� G located on the resulting decomposition are all of same type that corresponds to configuration (2). Configuration (1) reduces the areas of S1 and S2 of constant thicknesses e1 and e2, which can influence their ‘idealizability’. Configuration (4) reduces the area of S2 of thickness e2 but it is not reducing that of S1, which influences the ‘idealizability’ of S2 only. As a result, it can be observed that processing configurations in C1 produce new configurations that always belong to C2. Now, considering configurations in C2, none of them is producing stiffening effects similar to C1. Consequently, the set of configurations in Figure 5.9a is a closed set under the decomposition process producing the interfaces I� G. More precisely, there is no additional processing needed for C2 and processing all configurations in C1 produces configurations in C2, which outlines the algorithm for processing iteratively interfaces between Pi and shows that the algorithm always terminates. Figure 5.9a and b refers to interfaces IG of surface type. Indeed, GD can produce 136Chapter 5: Performing idealizations from construction graphs interfaces of volume type between Pi. This is equivalent to configurations where S1 and S2 departs from parallel or orthogonal settings as depicted in Figure 5.9. Such general configurations can fit into either set C1 or C2 as follows. In the 2D representations of Figure 5.9a, b, the outlines of S1 and S2 define the base faces Fb1 and Fb2 of each Pi. What distinguishes C1 from C2 is the fact that configurations (1) and (4) each, contains at least S2 such that one of its base face (Fb1S2 in Figure 5.9c) does not intersect S1 and this observation applies also for S1 in configuration (1) (Fb1S1 in Figure 5.9c). When configurations differ from orthogonal and parallel ones, a first subset of configurations can be classified into one of the four configurations using the distinction observed, i.e., if a base face of either S1 or S2 does not intersect a base face of its connected subdomain, this configuration belongs to C1 and if this property holds for sub-domains S1 and S2 both, the corresponding configuration is of type (1). Some other configurations of type (4) exist but are not detailed here since the purpose of the above analysis is to show how the reference configurations of Figure 5.9a can be extended. The completeness of configurations has not been entirely investigated yet. 5.3.3 Extending morphological analyses of Pi to the whole object M Now, the purpose is to use the stiffening influence of some connections as analyzed in Section 5.3.2 to process all the IG between Pi, to be able to propagate and update the ‘idealizability’ of each Pi when merging Pis. This process ends up with a new subdivision of some Pi as described in the previous section and a decomposition of M into a new set of sub-domains Pi 2, each of them having an evaluation of its ‘idealizability’ so that the engineer can evaluate more easily the sub-domains he, or she, wants to effectively idealize. The corresponding algorithm can be synthesized as follows (see algorithm 2). The principle of this algorithm is to classify IG between two Pi such that if IG belongs to C1 (configurations 1 and 4 in algorithm 2), it must be processed to produce new interface(s) I� G and new sub-domains that must be evaluated for idealization (procedure Propagate morphology analysis). Depending on the connection configuration between the two primitives Pi, one of them or both are cut along the contour of IG to produce the new sub-domains. Then, the MAT is applied to these new sub-domains to update their morphology parameter (procedure MA morphology analysis) that reflects the effect of the corresponding merging operation taking place between the two Pi along IG that stiffens some areas of the two primitives Pi involved. The algorithm terminates when all configurations of C1 have been processed. Among the key features of this algorithm, it has to be observed that the influence 2Here again like in Section 5.3.1, Pi designates also the set of sub-domains Dkj that can result from the decomposition of a primitive Pk when merging it with some other Pl sharing an interface with Pk. 137Chapter 5: Performing idealizations from construction graphs Algorithm 2 Global morphological analysis 1: procedure P ropagate morphologyanalysis(GD, xu) � The main procedure to extend morphological analyses of sub-domains to the whole object 2: for each P in list prims(GD) do 3: if P.x > xu then � If the primitive has to be idealized 4: for each IG in list interfaces prim(P) do 5: P ngh = Get connectedprimitive(P, IG) 6: if IG.conf ig = 1 or IG.conf ig = 4 then 7: interV ol = Get interfaceV ol(P, P ngh, IG) 8: Pr = Remove interfaceV ol(P, interV ol) � Update the primitive by removing the volume resulting from interfaces with neighbors 9: for i = 1 to Card(Pr) do � New morphological analysis of the partitions Pr 10: P� = Extract partition(i, Pr) 11: P� .x = MA morpho analysis(P� ) 12: P ngh.x = MA morph analysis(P ngh) 13: if IG.conf ig = 1 then 14: if P ngh.x > xu then 15: P rngh = Remove interV ol(P ngh, interV ol) 16: interV ol.x = MA morph analysis(interV ol) 17: for j = 1 to Card(P rngh) do 18: P� ngh = Extract partition(j, P rngh) 19: P� ngh.x = MA morpho analysis(P� ngh) 20: if interV ol.x < xu then � If the interVolume is ‘idealizable’ 21: Merge(P, P ngh, interV ol) � Merge the intervolume either with P or P ngh 22: end if 23: end for 24: else � If the interVolume is not ‘idealizable’ 25: P = P� 26: Merge(P ngh, interV ol) � Merge the interVolume with the neighboring primitive which is non ‘idealizable’ 27: end if 28: Remove prim(P ngh, list prims(GD)) 29: end if 30: if P� .x < xu then � if a partition is not ‘idealizable’ 31: Merge(P ngh, P� ) � Merge the partition with the non ‘idealizable’ primitive neighbor 32: end if 33: end for 34: end if 35: end for 36: end if 37: end for 38: end procedure 39: procedure MA morphology analysis(Pi) � Procedure using the 2D MAT on the extrusion contour of a primitive 40: Cont = Get Contour(Pi) 41: listof pts = Discretize contour(Cont) 42: vor = V oronoi(listof pts) � MAT generated using Voronoi diagram of a set of points 43: maxR = Get max radius of inscribed Circles(vor) 44: x = Set primitive idealizableT ype(maxR, Pi) 45: return x 46: end procedure 138Chapter 5: Performing idealizations from construction graphs Init CAD model Modeling processes Evaluation of sub domains morphology Same results of morphology analysis IG (4) (4) IG A B Modeling processes OR New Sub domains Volume Interface I’G New Sub domains Volume Interface I’G Figure 5.10: Propagation of the morphology analysis of each Pi to the whole object M. A and B illustrates two different sets of primitives decomposing M and numbers in brackets refer to the configuration category of interfaces (see Section 5.3.2.) of the primitive neighbor Pngh of Pi, is taken into account with the update of Pi that becomes Pr. Indeed, Pr can contain several volume partitions, when Card(Pr) > 1, depending on the shapes of Pi and Pngh. Each partition P� of Pr may exhibit a different morphology than that of Pi, which is a more precise idealization indication for the engineer. In case of configuration 1, the overlapping area between Pngh and Pi must be analyzed too, as well as its influence over Pngh that becomes Prngh . Here again, Prngh may exhibit several partitions, i.e., Card(Prngh ≥ 1), and the morphology of each partition P� ngh must be analyzed. If the common volume of P� ngh and P� is not idealizable, it is merged with either of the stiffest sub-domains Pngh or Pi to preserve the sub-domain the most suited for idealization. In case a partition P� of Pr is not idealizable in configuration 4, this partition can be merged with Pngh if it has a similar morphological status. Figure 5.10 illustrates this approach with two modeling processes of a simple component. Both processes contain two primitives to be idealized by plate elements and interacting with a surface interface of type (4). The stiffening effect of one primitive on the other creates three sub-domains with interfaces I� G of type (2). The sub-domain in violet, interacting with both sub-domains to be idealized, can be merged with each of the other sub-domains to create a fully idealized geometry or it can be modeled with a specific connection defined by the user. Full examples of the extension of the morphological analysis to the whole object M using the interfaces IG between the primitives of GD, are given in Figure 5.11. Figures 5.11a, b and c show the sub-domain decomposition obtained after processing the interfaces IG between primitives Pi of each object M. The same figures illustrate also the update of the morphology criterion on each of these sub-domains when they are iteratively merged through algorithm 2 to form their initial object M. Areas A and B show the stiffening effect of configurations of category (1) on the morphology 139Chapter 5: Performing idealizations from construction graphs (a) (b) T T B B (c) C A D B T T B B Figure 5.11: Propagation of the morphology analysis on Pi to the whole object M. a, b and c illustrate the influence of the morphology analysis propagation. The analyzed sub-domains are iteratively connected together to form the initial object. T and B indicate the top and bottom views ob the same object, respectively. of sub-domains of M. Areas C and D are examples of the subdivision produced with configurations of type (4) and the stiffening effects obtained that are characterized by changes in the morphology criterion values. After applying algorithm 2, one can notice that every sub-domain strictly bounded by one interface IG of C2 or by one interface I� G produced by this algorithm gives a precise idealization information about an area of M. Areas exhibiting connections of type (1) on one or two opposite faces of a sub-domain give also precise information, which is the case for examples of Figure 5.11. However, if there are more piled up configurations of type (1), further analysis is required and will be addressed in the future. Conclusion This section has shown how a CAD component can be prepared for idealization. The initial B-Rep geometry has been segmented into a set of extrusion primitives Pi using its construction graph GD. Using a taxonomy of geometric interfaces, a morphological analysis has been applied to these primitives to identify the ‘idealizable’ areas over the whole object. As a result, the geometric model is partitioned into volume subdomains which can be either idealized by shell or beams or not idealized at all. At that stage, only a segmentation of a standalone component has been analyzed. Neither the compatibility with an assembly structure nor the influence of external boundary conditions have been addressed yet, as this is the purpose of the next section. 140Chapter 5: Performing idealizations from construction graphs C1 C2 I1/2 Assembly interface F Boundary condition: Load F =500N Boundary condition: rigid condition to wall C3 C3 = C1 U C2 F Assembly interface considered as a rigid connection between C1 and C2 Figure 5.12: Influence of an assembly interface modeling hypothesis over the transformations of two components 5.4 Influence of external boundary conditions and assembly interfaces As explained in Section 4.7, an assembly model is composed of a set of 3D solid components linked to each other through functional interfaces. A boundary condition that is external to the assembly, as defined in Section 1.4.2, also acts as an interface between the object and its external environment. Figure 5.12 illustrates two types of boundary conditions, a load acting on component C1 and a rigid connection with the environment on C2. These areas are defined by the user and are represented as a geometric region on its B-Rep surface which is equivalent to an assembly interface, except that the interface is only represented on one component. Each component of the assembly can be segmented using respective construction graphs. However, the segmentation of components generates new geometric interfaces between primitives which can be influenced by the assembly interfaces. Therefore, this section aims at studying the role of assembly interfaces and boundary conditions in the idealization process. They can be analyzed either before the morphological analysis as input data or after the segmentation of components. Impact of the interface modeling hypotheses Depending on the simulation objectives, the engineer decides if he, resp. she, wants to apply some mechanical behavior over some assembly interfaces (see Table 1.2). This first choice highly influences the components’ idealization. As it is highlighted in Section 6.2.1, the engineer may decide not to apply any mechanical behavior at a common interface between two components, e.g., with the definition of rigid connections between their two mesh areas to simulate a continuous medium between components at this interface. This modeling hypothesis at assembly interfaces influences directly the geometric transformations of components. As illustrated in Figure 5.12, a set of components connected by rigid connections can be seen as a unique component after merging them. Therefore, to reduce the complexity of the FEA pre-processing, the 141Chapter 5: Performing idealizations from construction graphs morphological analysis can be applied to this unique component instead of applying it to each component individually. In case the engineer wants to assign a mechanical behavior to interfaces between components, these interfaces ought to appear in the final idealized model. Now, defining when this assignment can take place during the pre-processing enumerates: a) at the end of the idealization process, i.e., once the components have been idealized; b) during the segmentation process, i.e., during the construction graph generation of each component or during their morphological analysis. These two options are addressed in the following parts of this section. In this section, only the geometric aspect of assembly interfaces is addressed. The transfer of meta-information, e.g., friction coefficient, contact pressure is not discussed here. Applying assembly interfaces information after components’ idealization In a first step, this part of the section studies the consequences of integrating assembly interfaces at the end of the idealization process, i.e., option (a) mentioned above. These assembly interfaces represent information that is geometrically defined by the interactions between components. These interactions have a physical meaning because the contacts between components exist physically in the final product though a physical contact may not be always represented in a DMU as a common area between the boundaries of two components [SLF∗13] (see Section 1.3.2). For sake of simplicity, let us consider that physical contacts are simply mapped to common areas between components. Then, the assembly interfaces are initially prescribed in contrast with geometric interfaces, IG between primitives of a component that have been created during its segmentation process and aim at facilitating the geometric transformations performed during the idealization process of a component. One can observe that these assembly interfaces have to be maintained during the dimensional reduction operations of each component. However, these interfaces can hardly be transferred using the only information provided by the idealized models. For example, Figure 5.13b shows that a projection of the assembly interface on the idealized model of C1 could generate narrow areas which would be difficult to mesh and, on that of C2, could produce areas that fall outside the idealized model of C2. This assembly interface has been defined on the initial solid models of C1 and C2. If this link is lost during the idealization process, a geometric operator, i.e., like the projection operator just discussed, has to recover this information to adapt this interface on the idealized assembly model. Therefore, to obtain robust transformations of assembly interfaces, these interfaces have to be preserved during the dimensional reduction processes of each 142Chapter 5: Performing idealizations from construction graphs Assembly interface Generation of narrow mesh areas C1 C2 CAD + assembly interfaces Idealized representation Projection of assembly interface (a) (b) Non-correspondance between interface and idealized surfaces Figure 5.13: Illustration of the inconsistencies between an assembly interface defined between initial CAD components C1 and C2 (a) and its projection onto their idealized representations (b). component. Each of these interfaces, as a portion of the initial solid boundary of a component, has a corresponding representation in its idealized model. This equivalent image would have to be obtained through the transformations applied to the initial solid model of this component to obtain its idealized representation. Integration of assembly interfaces during the idealization process In a second step, this part of the section addresses the option (b) mentioned above. As stated in Section 5.4, assembly interfaces have to be generated before the dimensional reduction of assembly components. Now, the purpose is to determine at which stage of the proposed morphological analysis process the interfaces should be integrated. This analysis incorporates the segmentation process, which prepares a component shape for idealization and is dedicated to a standalone 3D solid. This approach can be extended to an assembly model from two perspectives described as follows: b1) The assembly interfaces and boundary conditions can be used to monitor the definition of specific primitives, e.g., primitives containing the whole assembly interface. Figure 5.14a illustrates such a decomposition with two components C1 and C2 fitting the assembly interface with only one primitive in both segmentations. The benefit of this approach lies in avoiding splitting assembly interfaces across various component primitives, which would divide this assembly interface representation across all the primitives boundaries; b2) The segmentation process is performed independently of the assembly interfaces. Then, they are introduced as additional information when transforming the set of primitives derived from each component and these interfaces are incorporated into the idealized representation of each component. In this case, the intrinsic 143Chapter 5: Performing idealizations from construction graphs Constrained extrusion face Integration of external interfaces after segmentation (cat. b2) (a) (b) External assembly interface Internal segmentation interface Integration of external interfaces before segmentation (cat. b1) P1.1 P1.2 I1/2 I1/2 I1/2 I1.1/1.2 I2.1/2.2 I2.1/2.2 I1.1/1.2 P1.1 P1.2 P2.2 P2.2 P2.1 P2.1 C1 C2 C1 C2 Figure 5.14: Two possible schemes to incorporate assembly interfaces during the segmentation process of components C1 and C2: (a) The assembly interface is used to identify extrusion primitives of C1 and C2 containing entirely the assembly interface in one extrusion contour, (b) The assembly interface is integrated after the segmentation of components C1 and C2 and propagated on each of their primitives. property of the proposed segmentation approach is preserved and the assembly interfaces are propagated as external parameters on every primitive they are respectively related to. Figure 5.14b shows the imprints of the assembly interface on the primitives derived from the segmentation of components C1 and C2. As a conclusion of the previous analyses, the choice of the idealization process made in this thesis falls into category (b2). Though a fully detailed analysis would bring complementary arguments to each of the previous categories, it appears that category (a) is less robust than category (b), which is an important point when looking for an automation of assembly pre-processing. Within category (b), (b1) leads to a solution that is not intrinsic to the shape of a component, which is the case for (b2). With the current level of analysis, there is no strong argument favoring (b1) over (b2) and (b2) is chosen to keep the level of standalone component pre-preprocessing decoupled from that of the assembly level. Therefore, assembly interfaces are not constraining the extraction of each the construction graph GD for each component. During the segmentation process, assembly interfaces are propagated only. Rigid connections only are assembly interfaces that can be processed prior the component segmentation process without interfering with it. Indeed, the first part of this section has shown that these interfaces lead to merge the components they connect. Consequently, the rigid interfaces only can be removed from the initial CAD components after the corresponding components have been merged, which simplifies the geometry to be analyzed. From a mechanical point of view, this operation is equivalent to extending the continuum medium describing each compo- 144Chapter 5: Performing idealizations from construction graphs nent because their material parameters and other mechanical parameters are strictly identical. Then, the other assembly interfaces and external boundary conditions, where a mechanical behavior has to be represented, are propagated through the segmentation process and taken into account during the dimensional reduction process. Chapter 6 carries on with the analysis of interactions between simulation objectives, hypotheses and shape transformations for assembly pre-processing. This helps structuring the preparation process of an assembly in terms of methodology and scope of shape transformation operators. Section 6.4 shows an example of automated idealization of an aeronautical assembly using the idealization process presented in this chapter which is also taken into account in the methodology set in Chapter 6. Now that the roles of assembly interfaces and external boundary conditions have been clarified, the next section focuses on the dimensional reduction of a set of extrusion primitives connected through geometric interfaces, IG. The objective is to set up a robust idealization operator enabling the dimensional reduction of extrusion primitives and performing idealized connections between medial surfaces through the analysis of the interface graph GI of an object M. 5.5 Idealization processes Having decomposed a assembly component M into extrusion primitives Pi, the last phase of the idealization process consists in the generation and connection of idealized models of each primitive Pi. Now, the interfaces IG between Pis are precisely identified and can be used to monitor the required deviations regarding medial surfaces. These deviations are needed to improve the idealization process and to take into account the engineer’s know-how when preparing a FE model (see discussions of Chapter 2). Based on the morphological analysis described in Sections 5.2 and 5.3, each Pi has a shape which can be classified in idealization categories of type plate, shell, beam or 3D thick solid. Therefore, depending on Pi’s morphological category, a dimensional reduction operator can be used to generate its idealized representation. The geometric model of the idealized Pi is: • A planar medial surface when Pi has been identified as a plate. This surface corresponds to the extrusion contour offset by half the thickness of this plate along the extrusion direction; • A medial surface when the primitive has been identified as a shell (see the detailed taxonomy in Tables C.1, C.2). This medial surface is generated as the extrusion of the medial line extracted from the extrusion contour of Pi. This medial line can be generated by applying the 2D MAT to the extrusion contour, as proposed 145Chapter 5: Performing idealizations from construction graphs P1 P2 P3 Solid Primitives P1 P2 P3 Initial CAD model Interfaces P7 P3 Interface of type (2) Interface of type (4) P17 P1 P2 P4 P6 P8 P9 P10 P11 P12 P13 P14 P15 P16 P18 P5 Interface Graph GI Figure 5.15: Illustration of an interface graph containing IGs derived from the segmentation process of M producing GD. by Robinson et al. [RAM∗06]. The shell thickness varies in accordance with the diameter of circles inscribed in the extrusion contour; • A medial line when the primitive has been identified as a beam. This line is generated through the extrusion of the point representing the barycenter of the extrusion contour if the beam direction is aligned with the extrusion direction. If the beam direction is orthogonal to the extrusion direction, the medial line corresponds to the medial line of the extrusion contour, offset by half of the extrusion distance; • The volume domain of Pi when Pi is identified as a 3D thick solid; since every Pi reduces to an extrusion primitive. Now that each primitive Pi is idealized individually, the purpose of the following section is to show how the medial surfaces can be robustly connected based on the taxonomy of interfaces IG illustrated in Figure 5.9. 5.5.1 Linking interfaces to extrusion information From the construction graph GD and the geometric interfaces IG between its primitives Pi, the interface graph GI can be derived. Figure 5.15 illustrates GI for a set of extrusion primitives extracted from one component of the aeronautical use-case presented in Figure 1.6. In GI , each node, named Ni, is a primitive Pi ∈ GD and each arc is a geometric interface IG between any two primitives Pi and Pj , as IG has appeared during the segmentation process of M. In a first step, GI is enriched with the imprints of the 146Chapter 5: Performing idealizations from construction graphs boundary of each IG on each primitive Pi and Pj that defines this IG. The jth boundary of an IG w.r.t. a primitive Pi is noted Cj(Pi). A direct relationship can be established between Cj(Pi) and the information related to the extrusion property of Pi. The interface boundary Cj(Pi) is classified in accordance with its location over ∂Pi. To this end, each node Ni of GI representing Pi is subdivided into the subsets: Ni(Fb1), Ni(Fb2), Ni(Fl), that designates its base face Fb1, its base face Fb2 and its lateral faces Fl, respectively. Then, Cj(Pi) is assigned to the appropriate subset of Ni. As an example, if Cj(Pi) has its contours located solely on the base face F b1 of Pi, its is assigned to Ni(Fb1), or if Cj(Pi) belongs to one at least of the lateral faces Fl, it is assigned to Ni(Fl). Figure 5.16 illustrates the enrichment of the interface graph GI of a simple model containing three primitives P1, P2 and P3. For example, the boundary C1(P1), resulting from the interaction between P1 and P3, is assigned to F b1 of P1. Reciprocally, the equivalent C1(P3) refers to a lateral face of P3. The following step determines potential interactions of Cj(Pi)s over Pi. When a pair of Cj(Pi)s shares a common geometric area, i.e., their boolean intersection is not null: Cj(Pi) ∩ Ck(Pi) �= φ, (5.1) the resulting intersection produces common points or curve segments that are de- fined as an interface between the pair of interface boundaries (Cj(Pi), Ck(Pi)) and the nth interface is noted IDnCj/Ck . Three interfaces between Cj(Pi) have been identified on the example of Figure 5.16, e.g., ID1C1/C2 represents the common edge interaction between C1(P1) and C2(P1). These new relations between Cj(Pi)s form a graph structure GID where the nodes represent the boundary Cj(Pi) and the arcs define the interface IDnCj/Ck . The graph structure GID related to a primitive Pi is strictly nested into the i th node of GI . More globally, the graph structure GID is nested into GI . The graph structures GID derived from the relations between the boundaries of interfaces IG of each Pi can be ‘merged’ with the interface graph GI . Let us call GS this graph (see Figure 5.16d). 5.5.2 Analysis of GS to generate idealized models Using GS, algorithms may be applied to identify specific configurations of connections between idealized primitives. These algorithms are derived from the current industrial practices of idealized FEM generation from B-Rep models. Specific configurations of interface connections can be identified automatically from GS while allowing the engineer to locally modify the proposed results based on his, resp. her, simulation hypotheses. So, nodes in GS can be either of type Cj(Pi) if there exists a path between Cj(Pi)s in Pi or they are Pis if there is no such path. Arcs are built up on either IGs or IDnCj/Ck depending on the type of node derived from Cj(Pi) and Pi. To generate a fully idealized model, i.e., a model where the medial surfaces are 147Chapter 5: Performing idealizations from construction graphs Fb1 FLs Fb2 Fb1 Fb2 Fb2 Fb1 Fb2 FLs Fb2 FLs C1 (P1) C2 (P1) C1 (P2) C2 (3) C2 (P1) C1 (P3) IP1/ P3 IP1/ P2 IP2/ P3 ID1 C1/C2 ID3 C1/C2 ID2 C1/C2 IP1/ P3 IP1/ P2 IP2/ P3 P1 P3 P2 Pi Primitive Base Faces Lateral Faces Interface between primitives Interface boundary on primitive ID Cm/Cn Cm (Pi) I Pi/Pj FLs Fb1,2 Interface between contours Fb1 FLs Fb1 FLs Fb1 FLs Fb2 P3 P2 P1 P1 P3 P2 IP1/ P2 IP2/ P3 IP1/ P3 Graph GI Fb1 FLs Fb2 Fb1 Fb2 Fb2 Fb1 Fb2 FLs Fb2 FLs C1 (P1) C2 (P1) C1 (P2) C2 (P1) C2 (3) C1 (P3) ID1 C1/C2 ID2 C1/C2 ID3 C1/C2 Fb1 FLs Fb1 FLs Fb1 FLs Fb2 P P3 P2 1 Graph GID of P1 Graph GID of P2 Graph GID of P3 Graph GS (a) (b) (c) (d) Figure 5.16: Enrichment of the graph GI with the decomposition of each node into subsets Ni(Fb1), Ni(Fb2), Ni(Fl). Illustration of an interface cycle between primitives P1, P2 and P3 built from GI and GID. (a) Initial primitives segmentation, (b) GI graph, (c) GID for P1, P2 and P3, (d) GS graph. 148Chapter 5: Performing idealizations from construction graphs connected, three algorithms have been developed to identify respectively: • interface cycles; • groups of parallel medial surfaces; • and L-shaped primitives configurations. The locations of medial surfaces are described here with orthogonal or parallel properties for sake of simplicity. Therefore, each of them can be generalized to arbitrary angular positions as described in Section 5.3.2. Each algorithm is now briefly described. Interface cycles Cycles of interfaces are of particular interest to robustly generate connections among idealized sub-domains. To shorten their description, the focus is placed on a common configuration where all the interfaces between primitives are of type (4). To define a cycle of interfaces of type (4), it is mandatory, in a first step, to identify a cycle in GI from connections between Pi. In a second step, the structure of connections inside each Pi, as defined in GID, must contain themselves a path between their interface boundaries Cj(Pi)s that extends the cycle in GI to a cycle in GS = GI∪GID. An example of such a cycle is illustrated in Figure 5.16. This level of description of interfaces among sub-domains indicates dependencies between boundaries of medial surfaces. Indeed, such a cycle is a key information to the surface extension operator to connect the set of medial surfaces simultaneously. The medial surfaces perpendicular to their interfaces IG (of P3 in Figure 5.16) have to be extended not only to the medial surfaces parallel to their interfaces (of P1 and P2 in Figure 5.16), but they have also to be extended in accordance with the extrusion directions of their adjacent primitives. For example, to generate a fully idealized model of the three primitives of Figure 5.16, the corner point of the medial surface of P3, corresponding to the ID3C1/C2 edge, has to be extended to intersect the medial surface of P1 as well as to intersect the medial surface of P2. As described, the information available in an interface cycle enables a precise and robust generation of connections among idealized sub-domains. Interface cycles appear as one category of specific idealization processes because they appear frequently in mechanical products and they fall into one category of connection types in the taxonomy of Figure 5.9. Groups of parallel medial surfaces Connections of parallel medial surfaces can be handled with medial surface repositioning (see P1 and P2 on Figure 5.17a) corresponding to the adjustment of the material thickness on both sides of the idealized surface to generate a mechanical model consistent with the shape of M. This is a current practice in linear analysis that has been advantageously implemented using the relative position of extrusion primitives. 149Chapter 5: Performing idealizations from construction graphs P2 P1 Offset of parallel medial surfaces (a) (b) P2 P1 Offset of L-shaped medial surfaces Figure 5.17: Examples of medial surface positioning improvement. (a) Offset of parallel medial surfaces, (b) offset of L-shaped medial surfaces. These groups of parallel medial surfaces can be identified in the graph GI as the set of connected paths containing edges of type (2) only. Figure 5.18a shows two groups of parallel medial surfaces extracted from GI presented in Figure 5.16. As a default processing of these paths, the corresponding parallel medial surfaces are offset to a common average position of the medial surfaces and weighted by their respective areas. However, the user can also snap a medial surface to the outer or inner skins of an extrusion primitive whenever this prescription is compatible with all the primitives involved in the path. Alternatively, he, or she, may even specify a particular offset position. Surfaces are offset to the reference plane as long as the surface remains within the limits of the original volume of the component M. This restriction avoids generating interferences between the set of parallel primitives and the other neighboring primitives. For example, in Figure 5.18, the resulting medial surface of the group of parallel primitives, containing P1 and P2, cannot intersect the volumes of its perpendicular primitives such as P3. This simple process points out the importance to categorize the interfaces between primitives. Like interface cycles, groups of parallel medial surfaces refer to the taxonomy of Figure 5.9 where they fall into the type (2) category. L-shaped primitives configurations When processing an interface of type (4) in GI , if an interface boundary Cj(Pi) is located either on or close to the boundary of the primitive Pj which is parallel to the 150Chapter 5: Performing idealizations from construction graphs Independent Medial Surfaces P1 P2 P3 P1 P2 P3 Aligned Medial Surfaces (c) d2 d1 d3 P4 Primitives in connection through only interfaces of type (4) Border primitives P7 Interface of type (2) P17 P1 P2 P6 P8 P9 P10 P13 P14 P15 Group of parallel medial surfaces (a) (b) Interface Graph GI P11 P5 P12 P16 P18 P11 P7 P3 Interface of type (2) Interface of type (4) P17 P1 P2 P4 P6 P8 P9 P10 P11 P12 P13 P14 P15 P16 P18 P5 P3 P2 P10 P14 P12 P1 P15 P6 P9 P13 P8 P4 P5 P16 P18 P17 P7 P3 Figure 5.18: Example of identification of a group of parallel medial surfaces and border primitives configurations from the interface graph GI : (a) extraction of type (2) subgraphs from GI , (b) set of L-shaped primtives extracted from GI , (c) initial and idealized configurations of M when groups of parallel primitives and L-shaped configurations have been processed. 151Chapter 5: Performing idealizations from construction graphs Fb2 Fb1 Fb2 FLs IP1/ P2 P1 C1 (P1) P2 IP1/ P2 Fb1 C1 (P1) Fs C1 (P2) P1 (surface) P2 (volume) Figure 5.19: Example of a volume detail configuration lying on an idealized primitive. interface (see P1 and P2 on Figure 5.17b or P2 and P3 in Figure 5.18c), the medial surfaces needs to be relocated to avoid meshing narrow areas along one of the subdomain boundaries (here P3 is moved according to d3). This relocation is mandatory because Cj(Pi) being on or close to the boundary of Pj , the distance between the idealized representation of Pi and the boundary of Pj is of the order of magnitude of the thickness of Pi. Because Pi is idealized, it means that the dimension of FEs is much larger than the thickness of Pi, hence meshing the areas between Cj(Pi) and the boundary of Pj would necessarily result in badly shaped FEs. The corresponding configurations are designated as L-shaped because Pi and Pj are locally orthogonal or close to orthogonal. If this configuration refers to mesh generation issues, which have not been addressed yet, L-shaped configurations where a subset of Cj(Pi) coincides with the boundary of a connected primitive (see P2 in Figure 5.18c) can be processed unambiguously without mesh generation parameters, as justified above. Processing configurations where Cj(Pi) is only close to a primitive contour requires mesh parameters handling and is left for future work. Primitives connected through interfaces of type (4) only, as illustrated in Figure 5.18b, are part of L-shaped configurations if they have at least a primitive contour Cj(Pi) close to Pj boundary. In Figure 5.18b, only P11, which is located in the middle of P9 and P14, is not considered as an L-shaped primitive. L-shaped con- figurations can be processed using the precise location of IG so that the repositioning operated can stay into IG to ensure the consistency of the idealized model. Identification criteria of Pi details The relationships between extrusion information and primitive interfaces may also be combined to analyze more precisely the morphology of standalone primitives, such as small protrusions that can be considered as details. As an example, Figure 5.19 shows the interaction between a primitive P1, which can be idealized as a plate and a primitive P2, morphologically not idealizable. The enriched interface graph with GID indicates that the boundary C1(P1) lies on a base face, F b1, of P1 whose boundary is used to idealize P1. Then, if the morphological analysis of F b1 is such that: F = (F b1−∗FC1(P1) ) shows that F is still idealizable, this means that P2 has no morphological influence 152Chapter 5: Performing idealizations from construction graphs relatively to P1, even though P2 is not idealizable. As a result, P2 may be considered as a detail of P1 and processed accordingly when generating the mesh of P1, P2. This simple example illustrates how further analyses can be derived from the graph structures GID and GI . Identifying details using the morphological properties of primitives is a way to be independent from the FE mesh size. With the proposed idealization process, a volume can be considered as a detail with respect to the surrounding geometry before the operation of dimensional reduction. This is an a priori approach satisfying the requirement of Section 2.2.1 which stated that a skin detail cannot be directly identified in an idealized model. Though the criterion described above is not generic, it is illustrative of the ability of the graph structures GID and GI to serve as basis of other criteria to cover a much wider range of configurations where skin and topological details could be identified with respect to the idealization processes. A completely structured approach regarding these categories of details is part of future work. 5.5.3 Generation of idealized models To illustrate the benefits of the interface graph analyses of GID and GI , which have been used to identify specific configurations with the algorithms described in Section 5.5.2, an operator has been developed to connect the medial surfaces. Once the groups of parallel medial surfaces have been correctly aligned, the medial surfaces involved in interfaces of type (4) are connected using an extension operator. Because the precise locations of the interfaces between primitives Pi and Pj are known through their geometric imprint Cj(Pi) on these primitives, the surface requiring extension is bounded by the imprint of Cj(Pi) on the adjacent medial surface. The availability of detailed interface information in GI and GID increases the robustness of the connection operator and prevents the generation of inconsistent surfaces located outside interface areas. Connection operator Firstly, the connection operator determines the imprints Cj(Pi) on the corresponding medial surface of the primitive Pj . This image of Cj(Pi) on the medial surface of the neighbor primitive Pi is noted Img(Cj(Pi)). Figure 5.20a shows, in red, three interface boundaries on the medial surfaces Img(Cj(Pi)) of the three primitives P1, P2, P3. When adjusting Cj(Pi), the medial surface boundary of Pi is also transferred on Img(Cj(Pi)). Such regions, in green in Figure 5.20a, are noted ImgMS(Cj(Pi)). The next step extends the medial surfaces involved in interfaces of type (4). The medial surfaces are extended from Img(Cj(Pi)) to ImgMS(Cj(Pi)) (the red lines to the green lines in Figure 5.20a). The extensions of the medial surfaces split Img(Cj(Pi)) into two or more sub-regions. The sub-regions which contains edges coincident with edges of the primitive medial surface are removed to avoid small mesh areas. 153Chapter 5: Performing idealizations from construction graphs Imprint of interface on primitive: C1(P2) Medial surface boundary Image of C1(P2) on medial surface: Img(C1(P2)) P2 P1 P2 P1 P2 P1 P2 P1 P2 P1 P2 P1 Image of the medial surface boundary of P2 on the medial surface of P1 : ImgMS(C1(P2)) Suppression of non-connected areas of Img(C1(P2)) Extension of medial surface Offset of the medial surface of P2 Offset of medial surface image Idealization without offset Idealization with offset (b) C1 (P8) : interface boundary on primitive P2 P8 P3 C2 (P2): interface boundary on primitive ImgMS (C2 (P2) ): medial Surface representation on Interface Boundary Representation of geometric interfaces on Medial Surfaces (a) Img(C1(P2)): image of C1 (P8) on the medial Surface Figure 5.20: (a) Representation of the interface imprints on primitives and on medial surfaces. (b)Connection process of two primitives P1 and P2 with and without offsetting their medial surfaces. 154Chapter 5: Performing idealizations from construction graphs Mesh Aligned Medial Surfaces Independent Medial Surfaces with Interface boundary Connected Medial Surfaces · CAD Medial Surfaces · Interfaces Figure 5.21: Idealization process of a component that takes advantage of its interface graph structures GID and GI . It must be noticed that the regions ImgMS(Cj(Pi)) lie into Pj and can be obtained easily as a translation of Cj(Pi). Therefore, it is not comparable to a general purpose projection operator where existence and uniqueness of a solution is a weakness. Here, ImgMS(Cj(Pi)) always exists and is uniquely defined from Cj(Pi) based on the properties of extrusion primitives. The interface cycles previously detected are used to identify intersection points within ImgMS(Cj(Pi)). Figure 5.20a illustrates the interaction between the three ImgMS(Cj(Pi)) corresponding to the intersection between the three green lines. When processing L-shaped primitives, in case the medial surface of Pi is shifted to the boundary of Pj , the corresponding images Img(Cj(Pi)) and ImgMS(Cj(Pi)) are also shifted with the same direction and amplitude. This update of these images preserves the connectivity of the idealized model when extending medial surfaces. Figure 5.20b illustrates the connection process of two primitives P1 and P2 with and without moving the medial surface of the primitive P2. This figure shows how the connection between the idealized representations of P1 and P2 can preserve the connectivity of the idealized model. Results of idealized models As shown in Figure 5.18b and c, the repositioning of medial surfaces inside P1, P2 and P3 improves their connections and the overall idealized model. Figure 5.21 illustrates the idealization of this component. Firstly, the medial surface of each primitive is generated. Then, the groups of parallel medial surfaces are aligned before the generation of a fully connected idealized model. Finally, the complete idealization process is illustrated in Figure 5.22. The initial CAD model is segmented using the construction graph generation of Chapter 4 to produce GD. It produces a set of volume primitives Pi with interfaces between them resulting in the graph structures GI and GID. A morphological analysis is applied on each Pi as described in Section 5.3.1. Here, the user has applied a threshold ratio 155Chapter 5: Performing idealizations from construction graphs Idealized Mesh model Init CAD model Segmented model Interfaces Dimensional reduction Analysis of interfaces Final CAD idealized model Morphological analysis Figure 5.22: Illustration of the successive phases of the idealization process (please read from the left to the right on each of the two rows forming the entire sequence). xu = 2 and an idealization ratio xr = 10. Using these values, all the primitives are considered to be idealized as surfaces and lines. The final CAD idealized model is generated with the algorithms proposed in Section 5.5.3 and exported to a CAE mesh environment (see Chapter 6). 5.6 Conclusion In this chapter, an analysis framework dedicated to assembly idealization has been presented. This process exploits construction graphs of components that produce their segmentation into primitives. Morphological criteria have been proposed to evaluate each primitive with respect to their idealization process. The benefits of generative process graphs have been evaluated in the context of idealization processes as needed for FEA. A morphological analysis forms the basis of an analysis of ’idealizability’ of primitives. This analysis takes advantage of geometric interfaces between primitives to assess stiffening effects that potentially propagate across the primitives when they are iteratively merged to regenerate the initial component and to locate idealizable subdomains over this component. Although the idealization concentrates on shell and plates, it has been observed that the morphological analysis can be extended to derive beam idealizations from primitives. This morphological analysis also supports the characterization of geometric details in relation to local and to idealizable regions of a component, independently of any nu- 156Chapter 5: Performing idealizations from construction graphs merical method used to compute solution fields. Overall, the construction graph allows an engineer to access non trivial variants of the shape decomposition into primitives, which can be useful to evaluate different idealizations of a component. Finally, this decomposition produces an accurate description into sub-domains and into geometric interfaces which can be used to apply dimensional reduction operators. These operators are effectively robust because interfaces between primitives are precisely defined and they combine with the primitives to bound their idealized representations and monitor the connections of the idealized model. The principle of component segmentation appears also to be compatible with the more general needs to process assembly models. Indeed, components are sub-domains of assemblies and interfaces are also required explicitly to be able to let the engineer assign them specific mechanical behavior as needed to meet the simulation objectives. The proposed idealization process can now take part to the methodology dedicated to the adaption of a DMU to FE assembly models, as described in the next chapter. 157Chapter 5: Performing idealizations from construction graphs 158Chapter 6 Toward a methodology to adapt an enriched DMU to FE assembly models Having detailed the idealization process as a high-level operator taking benefits from a robust shape enrichment, this chapter extends the approach toward a methodology to adapt an enriched DMU to FE assembly models. Shape transformations resulting from user-specified hypotheses are analyzed to extract preprocessing tasks dependencies. These dependencies lead to the specification of a model preparation methodology that addresses the shape transformation categories specific to assemblies. To prove the efficiency of the proposed methodology, corresponding operators have been developed and applied to an industrial DMU. The obtained results point out a reduction in preparation times compared to purely interactive processes. This time saved enables the automation of simulation processes of large assemblies. 6.1 Introduction Chapter 3 set the objectives of a new approach to efficiently adapt CAD assembly models derived from DMUs as required for FE assembly models. Chapters 4 and 5 significantly contributed to solve two issues regarding the proposed approach. The first challenge addresses the internal structure of CAD components that has to be improved to provide the engineer with a robust segmentation that can be used as basis for a morphological analysis. The second challenge deals with the implementation of a robust idealization process automating the tedious tasks of dimensional reduction operations and particularly the treatment of connections between idealized areas. Then, the proposed algorithms have been specified to enable the transformations of solid primitives as well as their associated interfaces. The set of solid primitives can result either from a component segmentation or an assembly structure decomposed 159Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models into components in turn decomposed into solid primitives. Thus, the method allows an engineer to transform components’ shapes while integrating the semantics of assembly interfaces. This chapter goes even further to widen the scope of shape transformations at the assembly level and evolve toward a methodology of assembly pre-processing. The aim is to enforce the ability of the proposed approach to challenge the current practices to generate large assembly simulation models. The analysis of dependencies among component shape transformations applied to assemblies will help us to formalize this methodology. Thanks to the geometric interfaces of components and functional information expressed as functional designations of components obtained with the method of Shahwan et al. [SLF∗13] summarized in Section 3.3, new enriched DMU are now available to engineers. Thanks also to the component segmentation into solid primitives and their interfaces that can be used to idealize sub-domains as described in Chapter 5, the models input to FEA pre-processing contains much more information available to automate the geometric transformations required to meet the simulation objectives. The method described in Section 6.1 of this chapter uses this enriched DMU as input to structure the interactions between shape transformations, leading to a methodology which structures the assembly preparation process. To prove the validity of the proposed methodology, Sections 6.3 and 6.4 illustrate it with two test cases of an industrial assembly structure (see Figure 1.6) to create a simplified volume model and an idealized surface model. To this end, new developments are presented that are based on operators that perform shape transformations using functional information to efficiently automate the pre-processing. Section 6.3 develops the concept of template-based transformation operators to efficiently transform groups of components. This operator is illustratively applied to an industrial aeronautical use-case with transformations of bolted junctions. Section 6.4 deploys the methodology using the idealization algorithms of Chapter 5 to generate a fully idealized assembly model. Finally, the software platform developed in this thesis is presented at the end of Section 6.4. 6.2 A general methodology to assembly adaptions for FEA Chapter 1 pointed out the impact of interactions between components on assembly transformation. The idealization of components is not the only time consuming task during assembly preparation. When setting up large structural assembly simulations, processing contacts between components as well as transforming entire groups of components are also tedious tasks for the engineer. The conclusion of Section 1.5.4 showed that the shape transformations taking place during an assembly simulation preparation process interact with simulation objectives, hypotheses and functions attached to components and to their interfaces. Therefore, to reduce the amount of time spent 160Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models on assembly pre-processing, the purpose is now to analyze and structure the interactions between shape transformations. This leads to a methodology that structures the assembly preparation process. 6.2.1 From simulation objectives to shape transformations How do shape transformations emerge from simulation objectives and how do they interact between themselves? This is to be analyzed in the following section. However, the intention is not to detail interactions but to focus on issues that help to structure the shape transformations. Transformation criteria related to time that may influence simulation objectives are not relevant, i.e., manual operations that have been performed to save time are irrelevant. Indeed, the purpose is to structure shape transformations to save time and improve the efficiency of preparation processes. 6.2.1.1 Observation areas From the simulation objectives, the structural engineer derives hypotheses that address components and/or interfaces among them, hence the concept of observation area. Even if this engineer has to produce an efficient simplified model of the assembly to meet performance requirements, anyhow he/she must be able to claim that his/her result is correct and accurate enough in critical observations areas that are consistent with the simulation objectives. Therefore, the mechanical model set up in these areas must remain as close as possible to the real behavior of the assembly. Thus, the geometric transformations performed in these areas must be addressed in a first place. As an example, in Figure 6.1, the simulation objective is to observe displacements in the identified region (circled area) due to the effects of local loading configurations, the section of the domain being complex. A possible engineers hypothesis can be to model precisely the 3D deformation in the observation area with a volume model and a fine mesh and set up a coarse mesh or even idealized sub-domains outside the area of interest. To explicit this hypothesis over the domain, the circled area should be delimited before meshing the whole object. During a preparation process, setting up observation areas and thus, subdividing an assembly into sub-domains, independently of the component boundaries and their interfaces, acts as a prominent task. 6.2.1.2 Entire idealization of components Idealizations have inherently a strong impact on shape transformations because of their dimensional reduction. Applied to a standalone component, idealization is meaningful to transform 3D domains up to 1D ones. In the context of assemblies, to meet simulation objectives, performances, and reduce the number of unknowns, the engineer 161Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Observation Area Geometric transformation Surface model Mixed dimensional model (Line + Surface) Fine Mesh Coarse Mesh Idealized element Load F Figure 6.1: Setting up an observation area consistent with simulation objectives. A B Analytical model Global Idealization A + B Figure 6.2: Entire idealization of two components. can idealize a component up to a point (0D), e.g., a concentrated mass, or even replace it by a pre-defined solution field, e.g., a rigid body behavior or a spring-damper field. When analytical models are available, some groups of components, like the bolts in Figure 6.3a, do not appear geometrically in the FE assembly. The planar flange connected by the bolts forming the major interface is used as location of a section in the FE assembly model to determine resulting internal forces and moments in that section. Then, the analytical model is independent of the FE one and it is fed with these parameters to determine the pre-stress parameters of the bolts. Figure 6.3b illustrates the complete idealization of pulleys as boundary conditions. This time, an analytical model has been used prior to the FE assembly model. Such categories of idealizations can be also applied to a set of connected components (see Figure 6.2). In either case, such transformations have a strong impact on the interfaces between the idealized components and their neighboring ones. Consequently, interfaces between idealized components can no longer be subjected to other hypotheses, e.g., contact and/or friction. Again, this observation highlights the prominence of idealization transformations over interfaces ones. 6.2.1.3 Processing Interfaces Interfaces between components are the location of specific hypotheses (see Table 1.2) since they characterize junctions between components. Naturally, they interact with hypotheses and shape transformations applied to the components they connect. Let 162Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Idealization of groups of components Idealization of component as BCs (a) (b) Figure 6.3: (a) Transformation of groups of components as analytical models and, (b) idealization of components as BCs (courtesy of ANTECIM). A C B ABC Interface Idealization (a) (b) (c) A B C A B C Figure 6.4: Influence of interfaces over shape transformations of components. us consider the example of Figure 6.4. In a first place, a simulation objective can be stated as: modeling the deformation of the assembly with relative movements of plates A, B, C under friction. Under this objective, hypotheses are derived that require modeling interfaces (A, C) and (B, C) with contact and friction. Then, even if A, B and C, as standalone components, can be candidate to idealization transformations, these idealizations cannot be idealized further because the interfaces would need to be removed, which is incompatible with the hypotheses. In a second place, another simulation objective can be stated as: modeling the deformation of the assembly where the junctions between plates A, B, C are perfect, i.e., they behave like a continuous medium. There, plates A, B, C can still be idealized as standalone components but the hypothesis on interfaces enables merging the three domains (Figure 6.4b) and idealizing further the components to obtain an even simpler model with variable thickness (see Figure 6.4c). Thus, there are priorities between shape transformations deriving from the hypotheses applied to interfaces. Indeed, this indicates that hypotheses and shape transformations addressing the interfaces should take place before those addressing components as standalone objects. Effectively, interfaces are part of component boundaries; hence 163Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models their transformations modify these boundaries. It is more efficient to evolve the shape of interfaces alone first and to process component shapes, as isolated domains, afterwards. As explained in Section 5.4, once the role of interfaces has been defined in the assembly according to the user’s simulation objectives and the corresponding transformations have been performed, each individual component can be transformed on its own to take into account these interfaces as external boundary conditions during its idealization/simplification process. 6.2.2 Structuring dependencies between shape transformations as contribution to a methodology of assembly preparation Section 6.2.1 has analyzed the relationships between simulation objectives, hypotheses, and shape transformations of assemblies. One outcome of this section structures the dependencies between hypotheses and shape transformations that address an assembly at different levels. The purpose is now to exploit these dependencies to organize the various steps of an assembly simulation preparation process so that it appears as linear as possible to be efficiently automatized. Dependencies of geometric transformations of components and interfaces upon simulation hypotheses Section 6.2.1.1 has shown the dependency of observation areas upon the simulation objectives. Defining observation areas acts as a partitioning operation of an assembly, independently of its components boundaries. Section 6.2.1.2 introduced the concept of entire idealization of components and pre-defined solutions fields. Indeed, the shape transformations derived from Section 6.2.1.2 cover also sub-domains over the assembly that can be designated as ‘areas of weak interest’. There, the assembly interfaces contained in these areas are superseded by the transformations of Section 6.2.1.2. From a complementary point of view, areas of interest, once defined, contain sub-domains, i.e., components or parts of components, that can still be subjected to idealizations, especially transformations of volumes sub-domains into shells/membranes and/or plates. Consequently, areas of weak interest are regarded as primary sub-domains to be de- fined. Then, entire idealization of components and pre-defined solutions fields will take place inside these areas, in a first place (identified as task 1 in Figure 6.5). These areas are necessarily disjoint from the areas of interest, therefore their processing cannot interfere with that of areas of interest. Sections 1.5.4 and 6.2.1.3 have shown that hypotheses about assembly interfaces influence the transformations of component boundaries. Hence, these hypotheses must be located outside of areas of weak interest to preserve the consistency of the overall simulation model. Subsequently, these hypotheses about interfaces are known once the 164Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models areas of weak interest have been specified. Consequently, they come as a task 2, after the definition of the areas of weak interest and the corresponding shape transformations of assembly interfaces should be applied at that stage. As highlighted at Sections 1.5.3, 1.5.4, and 6.2.1.3, idealizations are shape transformations having an important impact on component shapes. As mentioned at Section 2.2, the order of detail removal operations and idealizations has not been studied precisely yet. However, once idealizations have been assigned to sub-domains corresponding to primitives Pi of components, these transformations produce new interfaces between these sub-domains (see Figure 5.1) in addition to the assembly interfaces originated from the interactions between components. Independently of skin and topological details, idealizations can be regarded as task 3 in the preparation process flow. Effectively, these new interfaces are the consequences of idealizations of sub-domains that result from idealization processes. Therefore, these new interfaces cannot be processed during the second task. These new interfaces should be processed in a first place after the idealizations performed during the third task. The corresponding shape transformations attached to these new interfaces form task 4. Now, as pointed out at Section 6.2.1.3, idealizations can interact between themselves because the idealized sub-domains can be extended/merged in accordance to their geometric configurations to produce a connected idealized model wherever it is required by the simulation objectives. This new set of shape transformations can be regarded as task 5 that could indeed appear as part of an iterative process spanning tasks three and four. This has not yet been deeply addressed to characterize further these stages and conclude about a really iterative process or not. Even though task two addresses hypotheses attached to assembly interfaces and their corresponding shape transformations, it cannot be swapped with task three to contribute to iterative processes discussed before. Indeed, task 2 is connected to assembly interfaces between components and their processing could be influenced by component idealizations, e.g., in a shaft/bearing junction, idealizing the shaft influences its contact area with the bearings that guide its rotational movement. Hypotheses and shape transformations previously mentioned enable the definition of a mechanical model over each sub-domain resulting from the tasks described above but this model must be available among the entities of CAE software. This is mandatory to take advantage of this software where the FE mesh will be generated. Consequently, if an engineer defines interface transformations consistent with the simulation hypotheses, there may be further restrictions to ensure that the shapes and mechanical models produced are effectively compatible with the targeted CAE software capabilities. For sake of conciseness, this aspect is not addressed here. Toward a methodology of assembly model preparation This section has identified dependencies among shape transformations connected to 165Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Task1 – Definition of areas of weak interest Entire idealization of components, pre-defined solution fields Task2 – Specification and transformations of components interfaces Task3 – Idealization of sub-domains outside the areas of weak interest Task4 – Specification and transformations of interfaces resulting from idealization Task5 – Interaction and transformations of idealized sub-domains Task6 – Skin or topological transformations of sub-domains Figure 6.5: Synthesis of the structure of an assembly simulation preparation process. simulation objectives and hypotheses. Shape details on components can be identified using the morphological analysis, as illustrated in Section 5.5.2. This analysis has shown that the primitives Pi obtained from the construction graph GD could be further decomposed into sub-domains after analyzing the result of a first MAT. This analysis has also shown its ability to categorize sub-domains relatively to each other. However, detail removal, which originates from different components or even represents an entire component, needs to be identified through a full morphological analysis of the assembly. This has not been investigated further and is part of future research. Currently, detail removals can take place after task two but they can be prior or posterior to idealizations. The definition of areas of interest has connections with the mesh generation process to monitor the level of discretization of sub-domains. This definition acts as a partitioning process that can take place at any time during the process flow of Figure 6.5. 166Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models 6.2.3 Conclusion and methodology implementation As a conclusion, the difference between a simulation model of a standalone component and that of an assembly relates to: • The interactions between components. The engineer formulates a hypothesis for each interface between components. These hypotheses derive from assembly simulation objectives; • The ordering of shape transformations. The entire idealization of components and the specification of pre-defined solution fields followed by shape transformations of component interfaces are prioritized; • The interactions between idealizations and assembly interface transformations. To be able to model large assemblies, not only components but groups of components have to be idealized, which can significantly increase the amount of interactions between idealizations and transformations of assembly interfaces. The simulation objectives are expressed through hypotheses that trigger shape transformations. Studying the interactions between simulation objectives, hypotheses, and shape transformations has revealed dependencies between categories of shape transformations. These dependencies have been organized to structure the assembly simulation model preparation process in terms of methodology and scope of shape transformation operators. The proposed methodology aims at successfully selecting and applying the geometric transformation operators corresponding to the simulation objectives of the engineer. Starting from an enriched structure of DMU as proposed in Section 3.3, the purpose of the next sections is to illustrate how this methodology can be applied to industrial use-cases. Two implementations are proposed and both are based on the exploitation of functional features of the assembly using the interfaces between components (see Figures 2.14 and 3.2). As a first methodology implementation, Section 6.3 develops the concept of templatebased operators. This concept uses functional information and the geometry of assembly interfaces to identify configurations such as bolted junctions and to apply specific simulation hypotheses to transform their assembly interfaces. This transformation creates a simplified volume model with a sub-domain decomposition around bolted junctions, as required by the simulation objectives (see Figure 6.6). The second methodology implementation, presented in Section 6.4, leads to a full idealization of an assembly use-case. This implementation confirms that the idealization process of Chapter 5 can be generalized to assembly structures. 167Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Clearance Fitted contact Hypothesis: bolted junctions represented by a simplified bolt model Geometric transformations: cylindrical volume interface representing a screw/hole clearance transformed into a fitted contact. (a) Figure 6.6: Use-Case 1: simplified solid model with sub-domains decomposition around bolted junctions. Area enlarged (a): Illustration of task 2 that transforms bolted junction interfaces into fitted contacts. 6.3 Template-based geometric transformations resulting from function identifications As illustrated in Section 1.5.4, repetitive configurations, e.g., junctions, and their processing are critical when preparing assembly structures, justifying the need to automate the preparation of large assembly models. To improve the efficiency of DMU transformations for FEA, Section 3.5.2 has proposed to set up relationships between simulation objectives and geometric transformations through the symbolic representation of component functions and component interfaces. The method is based on an enriched DMU as input (see Section 3.3) which contains explicit geometric interfaces between components (contacts and interferences) as well as their functional designations. This enriched DMU has been generated based on the research work of Shahwan et al. [SLF∗12, SLF∗13]. The geometric interfaces feed instances of conventional interfaces (CI) (see Section 1.3.2) classes structured into a taxonomy, TCI , that binds geometric and symbolic data, e.g. planar contact, spherical partial contact, cylindrical interference, . . . Simultaneously, CI and assembly components are organized into a CI graph: CIG(C, I) where the components C are nodes and CI are arcs. Starting from this enriched model, Section 6.3.2 extends the functional structure to reach a level of product functions. Therefore, simulation objectives can be used to specify new geometric operators using these functions to robustly identify the components and assembly interfaces to transform [BSL∗14]. If close to Knowledge Based Engineering (KBE), this scheme is nonetheless more generic and more robust than KBE approaches due to the fact that functional designations and functions are generic concepts. KBE aims at structuring engineering knowledge and at processing it with symbolic representations [CP99, Roc12] using language-based approaches. Here, the focus is on a robust connection between geometric models and symbolic representations 168Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models featuring functions. To prove the validity of this approach and of the methodology proposed in Section 6.2.2, this section presents a template-based operator dedicated to the automation of shape transformations of bolted junctions (see Figure 6.6). The template operator is described in Section 6.3.3. Using functional information and geometric interfaces, this operator applies a user-defined template to simplify bolts and sets control sub-domains around them in their associated tightened components to enable the description of the friction phenomenon between these components. This template is used to precisely monitor the mesh generation process while preserving the consistency of contacts and adapting the assembly model to simulation objectives. Finally, Section 6.3.4 illustrates the result of the different tasks of the proposed methodology applied to the transformation of the bolted junctions of the root joint model presented in Figure 1.6. 6.3.1 Overview of the template-based process The overall principle of the template-based approach is introduced in Figure 6.7. It uses the available functional information and geometric interfaces, see (1) in Figure 6.7, as well as a library of pre-defined parametric templates, see (2). From this library, the templates are selected by the user according to his, resp. her, simulation objectives. Once the templates have been selected, the operator automatically identifies the functions in the assembly the templates are related to, see (3). Then, as explained in Section 6.3.2, the operator identifies in the CAD assembly the components and interfaces to be transformed, see (4). In (5), the templates definition are fitted to the real geometry, i.e. the components and interfaces dimensions involved in the geometrical transformations are updated in the pre-definition of the templates. Section 6.3.3.1 detailed the compatibility conditions required by the templates insertion in the real geometry. Finally, the real geoemtry is transformed according to the compatibility conditions and the templates are inserted in the assembly model, see task 6. Section 6.3.4 describes the application of template operator on two aeronautical use-cases. It results in a new CAD assembly model adapted to simulation objectives. 6.3.2 From component functional designation of an enriched DMU to product functions Though the bottom-up approach of Shahwan et al. [SLF∗12, SLF∗13] summarized in Section 3.3 provides assembly components with a structured model incorporating functional information that is independent of their dimensions, their functional designation does not appear as an appropriate entry point to derive shape transformation operators as required for FE analyses. Indeed, to set up FE assembly models, an engineer looks for bolted junctions that he, resp. she, wants to transform to express friction phenomena, pre-stressed state in the screw, . . . Consequently, the functional level needed is not 169Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Template library: pre-defined parametric templates Definition of assembly interfaces and functional designations Geometrical adjustment of the template to real shapes Functions available for transformation Identification of components and interfaces involved in selected functions Adaptation of real shapes with template insertion Real shape Template 1 2 3 4 5 6 Adapted assembly Figure 6.7: Overview of the main phases of the template-based process. 170Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Assembly Disassemblable Obstacle Bolted adjusted Screw + nut Blocked nut Adherence Dependent function Dependent function Bolted ... ... ... Nut Screw Plates Counter nut Figure 6.8: Subset of TF N , defining a functional structure of an assembly. the functional designation, which is bound to a single component, it is the product function itself that is needed to address the corresponding set of components and their functional interfaces. To this end, it is mandatory to refer to product functions. This is achieved with a taxonomy of functions, TF N , that can produce a functional structure of an assembly (see Figure 6.8). Blue items define the sub-path in TF N hierarchy that characterizes bolted junctions. Each instance of a class in TF N contains a set of components identified by their functional designation, i.e., it contains their structured geometric models and functional interfaces. As a result of the use of TF N , a component of a DMU can be automatically identified when it falls into the category of cap screws, nuts, locking nuts, that are required to define bolted junctions. This means that their B-Rep model incorporates their geometric interfaces with neighboring components. The graph of assembly interfaces set up as input to the process of functional designation assignment, identifies the components contained in a bolted junction. Each component is assigned a functional designation that intrinsically identifies cap screws, nuts, locking nuts, . . . , and connects it with an assembly instance in TF N . It is now the purpose of Section 6.3 to take advantage of this information to set up the template-based transformations. 6.3.3 Exploitation of Template-based approach for FE models transformations As a result of the functional enrichment process, the DMU is now geometrically structured, components are linked by their geometric interfaces, and groups of components can be accurately identified and located in the DMU using their function and geo- 171Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models metric structure, e.g., adjusted bolted junctions with (screw+nut) (see Figure 6.8). Now, the geometric transformations needed to adapt the DMU to FEA objectives are strengthened because screws, nuts, locking nuts can be robustly identified, groups of tightened components are also available through the load cycles attached to cap screws (see Section 3.3). Two possible accesses are proposed to define a function-based template T related to an assembly function: • A component C through a user-defined selection: from it and its functional designation, a data structure gives access to the functions it contributes to. After selecting C, the user selects the function of interest among the available functions attached to C in TF N and compatible with T. Other components are recovered through the selected function this component participates to; • The function itself in TF N that can lead to the set of components needed to define this function and all the instances of this function existing in the targeted assembly. These accesses can be subjected to constraints that can help identifying the proper set of instances. Constraints aim at filtering out instances when a template T is defined from a function to reduce a set of instances down to the users needs, e.g., assembly function with bolts ‘constrained with’ 2 tightening plates componenti and component j . Constraints aim at extending a set of instances when a template is defined from a component, i.e., a single function instance recovered, and needs to be extended, e.g., assembly function with bolts ‘constrained with’ same tightened components and screw head functional interface of type ‘planar support’ or ‘conical fit’. 6.3.3.1 Function-based template and compatibility conditions of transformations The previous section has sketched how component functions can be used to identify sets of components in an assembly. Indeed, this identification is based on classes appearing in TF N . Here, the purpose is to define more precisely how the template can be related to TF N and what constraints are set on shape transformations to preserve the geometric consistency of the components and their assembly. Shape transformations are application-dependent and the present context is structural mechanics and FEA to define a range of possible transformations. The simplest relationship between a template T and TF N is to relate T to a leaf of TF N . In this case, T covers instances defining sets of components that contain a variable number of components. T is also dimension independent since it covers any size of component, i.e., it is a parameterized entity. Shape transformations on T are designated as ST and the template devoted to an application becomes ST (T). Now, reducing the 172Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models scope to disassemblable assembly functions and more specifically bolted junctions, one leaf of TF N can be used to define more precisely T and ST (T). Conforming to Figure 6.8, let us restrict first to the leaf ‘screw+nut’ of TF N . Then, T contains the following functional interfaces: one threaded link, two or more planar supports (one between nut and plate and at least one between two plates), either one planar support or one conical fit between the screw head and a plate, as many cylindrical loose fits as plates between the screw and plates because the class of junctions is of type adjusted. The shape transformations ST (T) of T set up to process bolted junctions can be summarized as (see Figure 6.9): • ST 1: merging screw and nut (see Section 6.3.3.1); • ST 2: localization of friction effects with a sub-domain around a screw (see Section 6.3.3.1); • ST 3: removal of the locking nut if it exists (see Section 6.3.3.2); • ST 4: screw head transformation for mesh generation purposes (see Section 6.3.3.3); • ST 5: cylindrical loose fit around the screw shaft to support the contact condition with tightened plates (see Section 6.3.4). Each of these transformations are detailed throughout the following sections. Now, the purpose is to define ST so that ST (T) exists and preserves the consistency of the components and the assembly. This defines compatibility conditions, CC, between T and ST that are conceptually close to attachment constraints of form features on an object [vdBvdMB03] (see Figure 6.9). CC applied to ST are introduced briefly here. Given the set of components contained in T, this set can be subdivided into two disjoint subsets as follows: • IC is the set of components such that each of its components has all its functional interfaces in T, e.g., the screw belongs to IC. Consequently, components belonging to IC are entirely in T (see the green rectangle in Figure 6.9); • PC is the set of components such that each of its components has some of its functional interfaces in T, e.g., a plate belongs to PC. Components belonging to PC are partially in T (see the red rectangle in Figure 6.9). IC can be used to define a 3D sub-domain of T, TI defined as the union of all components belonging to IC. Now, if a transformation ST takes place in IC and geometrically lies inside TI , ST (T) is valid because it cannot create interferences with other components of the assembly, i.e., CC are satisfied. Let us consider some of these transformations to illustrate some CC. As an objective of FEA, the purpose of the assembly model is to analyze the stress distribution between 173Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Functionally enriched DMU CIG Function FD (screw, nut, locking nut) FI CI Ci Cn T Cc Ic Pc Geometric Transformations ST1 : C’ ← merge (C ,C ) screw nut i j ST3 ST5 : remove (C ) locking nut i : (C’ ,C’ )←preserve FI(C ,C ) j screw i screw i j S : (C’ ,C’ ,…) ← subdivide(C ,C ,...) T2 ST4 i j i j k : (C’ i ,C’ j ) ← transform(C ,C ) i j screw screw Updated components (C’, C’,...C’ ) i j m (Automated) Ci : component i CI: conventional interface CIG: conventional interface graph CC: compatibility conditions between T and ST ; FD: functional designation of a component; FI: functional interface IC: set of components such that each of its components has all its FI in T PC: set of components such that each of its components has some of its FI in T ST : shape transformation incorporated in a template, hence ST (T); T: function-based template performing shape transformations; Figure 6.9: Principle of the template-based shape transformations. The superscript of a component C, if it exists, identifies its functional designation. Threaded link Pre- Load pressure Friction IC : Counter nut Nut Screw PC: Plates Domain decomposition (CC to verify) (a) (b) (c) (d) (e) ST4 (CC to verify) ST2 (CC satisfied) (CC satisfied) ST1 ST3 Figure 6.10: Compatibility conditions (CC) of shape transformations ST applied to T. (a) through (e) are different configurations of CC addressed in Section 6.3.3. 174Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models plates and their interactions with bolts. To this end, the stress distribution around the threaded link between a screw and a nut is not relevant. Therefore, one shape transformation, ST 1 is the removal of the threaded link to merge the screw and the nut (see Figure 6.10c). ST 1 is always compatible since the screw and the nut belong to IC, hence the CC are always valid. Now, let us consider another transformation, ST 2, that specifies the localization of friction effects between plates around the screw shaft and the representation of the stress distribution nearby the screw shaft. This is modeled with a circular area centered on the screw axis and a cylindrical sub-domain around the screw shaft (see Figure 6.10d). Indeed, ST 2, is a domain decomposition [CBG08, Cha12] taking place in the plates belonging to T. Because the plates belong to PC, CC are not trivial. However, ST 2, takes place inside the plates so they cannot interfere with other components, rather they can interfere with the boundary of the plates or they can interfere between them when several screws are close to each other on the same plate (see Figure 6.11). In this case, CC can be simply expressed, in a first place, as a non interference constraint. Other shape transformations are listed when describing one example template in Section 6.3.4. 6.3.3.2 Shape transformations and function dependency The previous section has connected T to TF N in the simplest way possible, i.e., using a leaf that characterizes a single function. The purpose of this section is to analyze into which extent T can connect to classes of TF N that perform several functions in the assembly. In a first place, let us review shortly some concepts of functional analysis [Ull09]. There, it is often referred to several categories of functions that are related to a design process, i.e., external, internal, auxiliary, . . . However, this does not convey consistency conditions among these functions, especially from a geometric point of view. Here, the current content of TF N refers to internal functions, i.e., functions strictly performed by components of the assembly. The ‘screw+nut’ function, as part of bolted junctions, is one of them. Bolted junctions can contain other functions. Let us consider the locking function, i.e., the bolt is locked to avoid any loss of tension in the screw when the components are subjected to vibrations. The locking process can take place either on the screw or on the nut. For the purpose of the analysis, we consider here a locking process on the nut, using a locking nut (see Figure 6.12a). In functional analysis, this function is designated as auxiliary function but this concept does not characterize geometric properties of these functions. From a geometric point of view, it can be observed that functional interfaces of the screw, nut and locking nut are located in 3D such that the functional interfaces (planar support) between the nut and locking nut cannot exist if the nut does not tighten the plates. Consequently, the locking function cannot exist if the tightening 175Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Interference No interference User meshing tolerance Ø subdomains = user ratio ´ Ø screw Figure 6.11: Checking the compatibility of ST (T) with respect to the surrounding geometry of T. function does not exist. Rather than using the designation of auxiliary function, which is geometrically imprecise, it is referred to dependent function. The concept of dependent functions is inserted in TF N at different levels of TF N to attach the corresponding functions when they exist (see Figure 6.8). Based on the concept of dependent function, it is possible to extend the connection rule between T and TF N . Rather than connections at the leaf level, higher level classes can be connected to T if the dependent functions are taken into account in the CC of shape transformations ST so that ST (T) exists and preserves the consistency of the assembly. As an illustration, let us consider T connected to ‘Bolted adjusted’ (see Figure 6.8). Now, ST can cover the class of bolted junctions with locking nut. Let ST 3, be the transformation that removes the locking nut of a bolted junction, which meets also the FEA objectives mentioned earlier. Because ST 3, applies to a dependent function of ‘screw+nut’, the CC are always satisfied and the resulting model has a consistent layout of functional interfaces, i.e., the removal of the locking nut cannot create new interfaces in the assembly (see Figure 6.9 and 6.10b). Consequently, T can be effectively connected to ‘Bolted adjusted’, which is a generalization of T. 6.3.3.3 Template generation T is generated on the basis of the components involved in its associated function in TF N . T incorporates the objectives of the FEA to specify ST . Here, ST covers all the transformations described previously, i.e., ST 1, ST 2, ST 3. Figure 6.10 and 6.11 illustrates the key elements of these shape transformations. Other shape transformations, ST 4, can be defined to cover screw head transformations and extend the range of screws to flat head ones. However, this may involve 176Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models (a) (b) Figure 6.12: (a) Multi-scale simulation with domain decomposition around bolted junctions, (b) Load transfers at critical holes (courtesy of ROMMA project [ROM14]). geometric transformations where the volume of a screw head gets larger. In this case, ST 4 takes place in PC and the compatibility conditions are not intrinsic to T (see Figure 6.9). Consequently, it is mandatory to perform an interface/interference checking with the other components of the assembly to make sure that the transformation is valid (see Figure 6.10). Then, the set of shape transformations structures the dialog with the user to allow him, resp. her, to select some of these transformations. However, the user settings are applied to instances whenever possible, i.e., when the instance belongs to a class where the shape transformations are applicable. 6.3.4 Example of template-based operator of bolted junctions transformation In an aeronautical company, simulation engineers perform specific FEAs on assembly sub-structures such as the aircraft junction between wings and fuselage. Based on pre-existing physical testing performed by ROMMA project [ROM14] partners, this structure can be subjected to tensile and compressive forces to analyze: • The distribution of the load transfer among the bolted junctions; • The admissible extreme loads throughout this structure. From the physical testing and preliminary numerical models, the following simulation objectives have been set up that initiate the requirements for the proposed template-based transformations. To adapt the FE model to these simulation objectives while representing the physical behavior of the structure, an efficient domain decomposition approach [CBG08, Cha12] uses a coarse mesh far enough from the bolted junctions and a specific sub-domain around each bolted junction with friction and preload phenomena (see Figure 6.12a, b). The objective is not to generate a detailed stress distribution everywhere in this assembly but to observe the load distribution areas among bolts using the mechanical models set in the sub-domains. 177Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models The objective of this section is to validate the methodology of Section 6.2 through the template-based approach. The proposed demonstrator transforms automatically the bolts into simplified sub-domains ready for meshing with friction areas definition while preserving the consistency of the assembly. Consequently, there is no area of weak interest. All the above transformations are aggregated into a parameterized template whose input is the functional designation of components to locate the cap screws in the assembly. Then, the template adapts to the screw dimensions, the number of plates tightened, . . . , to apply the operators covering tasks 2 through 6. The template features are aligned with the needs for setting up a simulation model able to exhibit some of the physical phenomena observed during testing and expressed in the above simulations results. Operator description Having enriched the assembly with functional information, the template interface lets the engineer select a node of TF N that is compatible with T. In this example, the function to select is: ‘assembly with Bolted junction’ (see Figure 6.14). Now, several ST are either pre-set or user-accessible. Figures 6.6a and 6.13 illustrates the task 2 of the methodology. An hypothesis focuses on the interfaces between screw shafts and plate holes: the clearances there are regarded as small enough in the DMU to be reduced to a fitted configuration where shafts and holes are set to the same nominal diameter to produce a conform mesh with contact condition at these interfaces. To precisely monitor the stress distribution around bolts and friction between plates, ST 2 is user-selected. It a simplified model of the Rotschers cone [Bic95] that enables generating a simple mesh pattern around bolts. In this task also, hypothesizing that locking nuts, nuts, and screws can be reduced to a single medium leads to the removal of assembly interfaces between them. ST 3 is user-accessible and set here to remove the dependent function ‘locking with locking nut’. Then, there is no idealization taking place, hence no action in tasks 3 and 5. Task 4 connects to a hypothesis addressing the interfaces resulting from task 2, i.e., the interfaces between plates need not to model contact and friction over the whole interface. Friction effects can be reduced to a circular area around each screw, which produces a subdivision of these interfaces. ST 5 is pre-set in T to preserve the cylindrical loose fit between screw and plates to set up contact friction BCs without inter-penetration over these functional interfaces. ST 1 is also pre-set as well as ST 4. Finally, task 6 concentrates on skin and topological transformations. These are achieved with locking nut, nut, and screw shape transformations. The latter is performed on the functional interface (planar support) between the screw head/nut and the plates to obtain a meshing process independent of nut and screw head shapes. Now, T can cover any bolted junction to merge screw, nut and locking-nut into a single do- 178Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models Rotscher’s cone Sub-domains Structured hex Mesh (a) (b) (c) Figure 6.13: Template based transformation ST (T) of a bolted junction into simple mesh model with friction and contact areas definition around screw and nut. (a) the bolted junction in the DMU, (b) the bolted junction after simplification to define the simulation model, (c) the desired FE mesh of the bolted junction. main, reduce the screw and nut shapes to a simple shape of revolution while preserving the consistency of its interfaces. Based on T, ST (T) is fairly generic and parameterized to intelligently select and transform bolts, i.e., it is independent of the number and thicknesses of plates, of the screw diameter, the length and head type (cylindrical (see Figure 6.13a) versus flat ones) in addition to the location of each bolt. Here, ST (T) contains ST 2, a generation of sub-domains taking into account the physical effects of the Rotschers cone. This geometric transformation could interact with plate boundaries to change the shape of these sub-domains and influence the mesh generation process. Presently, templates are standalone entities and are not taking into account these effects left for future developments. At present, the engineer can adjust the sub-domain to avoid these interactions (see Figure 6.14a). Implementation and results The developed prototype is based on OpenCascade [CAS14] and Python scripting language. The DMU is imported as STEP assembly models, the geometric interfaces between components are represented as independent trimmed CAD faces with identifiers of the initial face pairs of the functional interfaces. The assembly functional description is imported as a text file from the specific application performing the functional enrichment described in [SLF∗13] and linked to the assembly model by component identifiers. Figure 6.14a shows the user interface of the prototype. When selecting the ‘assembly with Bolted Junction’ function, the user has a direct access to the list of bolted junctions in the assembly. To allow the user filtering his selection, DMU parameters are extracted from the functional designation of components, e.g., the screw and nut types, the number of tightened components, or from geometry processing based on functional interfaces, e.g., screw diameter. Using these parameters, the user is able 179Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models to select bolted junctions within a diameter range, e.g., between 10 and 16 mm (see Figure 6.14b) or bolted junctions with screw and locking nut (see Figure 6.14c), etc. The user can monitor the Rotschers cone dimension with a FEA parameter called ‘sub domain ratio’ that represents the ratio between the screw nominal diameter and the sub-domain diameter (see Figure 6.14d and e). Then, the user-defined ‘meshing tolerance’ is used during the verification phase to check the compatibility conditions, CC, between instances and their surrounding geometry (see Figure 6.9 and 6.11). Figure 6.15 shows two results of the template-based transformations on aircraft structures: Aircraft structure 1: A junction between the wing and the fuselage. The assembly contains 45 bolted junctions with 3 different diameters and 2 different screw heads; Aircraft structure 2: An engine pylon. The assembly contains over 250 bolted junctions with identical screws and nuts. The final CAD assembly (see Figure 6.14b) with simplified bolted junctions has been exported to a CAE software, i.e., Abaqus [FEA14]. STEP files [ISO94, ISO03] transfer the geometric model and associated xml files describes the interfaces between components to trigger meshing strategies with friction area definitions. Appendix D illustrates the STEP data structure used to transfer the Aircraft structure 1. Comparing with the process pipeline used with existing industrial software (see Section 1.4.3), the improvements are as follows. The model preparation from CAD software to an Abaqus simulation model takes 5 days of interactive work for ‘Aircraft structure 1’ mentioned above (see Figure 1.13b). Using the pipeline performing the functional enrichment of the DMU and the proposed template-based shape transformations to directly produce the meshable model in Abaqus and perform the mesh in Abaqus, the overall time is reduced to one hour. The adequacy of this model conforms to the preliminary numerical models set up in ROMMA project [ROM14] and extending this conformity to testing results is ongoing since the template enables easy adjustments of the mesh model. Regarding the ‘Aircraft structure 2’, there is no reference evaluation of its model preparation time from CAD to mesh generation because it is considered as too complex to fit into the current industrial PDP. However, it is possible to estimate the time reduction since the interactive time can be linearly scaled according with the number of bolted junction. This ends up with 25 days of interactive work compared to 1.5 hour with the proposed approach where the time is mostly devoted to the mesh generation phase rather than the template-based transformations. Though the automation is now very high, the template-based approach still leaves the engineer with meaningful parameters enabling him/her to adapt the shape transformations to subsets of bolted junctions when it is part of FE requirements. 180Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models (b) (d) (c) (e) (a) Figure 6.14: (a) User interface of a template to transform ‘assembly Bolted Junctions’. Results obtained when filtering bolts based on diameters (b) or screw type (c). Results of the template-based transformations with (d) or without (e) sub-domains around bolts. 181Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models (a) (b) (c) Aircraft structure 1 Aircraft structure 2 Figure 6.15: Results of template-based transformations on CAD assembly models: (a) CAD models with functional designations and geometric interfaces, (b) models (a) after applying ST (T) on bolts, (c) mesh assembly models obtained from (a) with friction area definition. 182Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models DMU Analysis for idealization Geometric Operations CAD Interfaces Simplify fastener SIMULATION Volume Segmentation Assembly Idealization Assembly analysis Components Idealization Interfaces Graph Idealized Assembly · Geometric Interfaces · Functinal Information · User Simulation Objectives · Idealized CAD assembly ready for meshing · Boundary conditions (contact) · Physical information (thickness, offset) Figure 6.16: Illustration of the idealization process of a CAD assembly model. All components are fully idealized and bolted junctions are represented with FE fasteners. Solid plates and stiffeners are idealized as surfaces. 6.4 Full and robust idealization of an enriched assembly The methodology of Section 6.2.2 has also been applied to create an idealized plate model of the ‘Root joint’ use-case presented in Figure 1.6. The simulation objectives are set on the global analysis of the stress field in the structure and the analysis of the maximal loads transferred through the bolted junctions. Consequently (see Section 1.4.3), the generated FEM contains idealized components with shell FE and each junction can be simplified with a fastener model (see Figure 6.17). Figure 6.16 illustrates the different data and processes used to transform the initial DMU model into the final FE mesh model. Once the CAD data associated with functional interfaces have been imported, all bolted connections are transformed into simplified fastener models (see Section 6.4.1) in a first step. Then, a second step segments and idealizes all components in accordance with the method described in Chapter 5 (see Section 6.4.2). 183Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models A B C A B C Hypothesis: bolted junctions represented by fasteners’ models Geometric transformations: a cylindral interfaces transformed into a single mesh node (a) Figure 6.17: Illustration of Task 2: Transformation of bolted junction interfaces into mesh nodes. Fastener connection points Figure 6.18: Results of the template-based transformation of bolted junctions. The blue segment defines the screw axis. Red segments are projections of interfaces between the plates and the screw. Yellow points are the idealizations of these interfaces to connect the screw to the plates. 184Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models 6.4.1 Extension of the template approach to idealized fastener generation Given the above simulation objectives, the first step of transformations is related to the transfer of plate loads throughout the assembly and FE beam elements are sufficient to model the bolts behavior. This hypothesis implies, in task 2 of the methodology, a transformation of cylindrical interfaces between bolts and plate holes into single mesh nodes (see Figure 6.17a) linked to beam elements that represent the idealized fasteners. A specific template-based operator has been developed to automate the transformation of bolted junctions into idealized fasteners. As in Section 6.3, the bolted junctions are identified among all 3D components through the function they are involved in: ‘adjusted bolted junctions with screw+nut’. Then, the template applies a set of shape transformations ST to generate the beam elements with their associated connection points. These shape transformations are described as follows: • ST 1: merging screw and nut (identical to Section 6.3.3.1); • ST 2: removal of the locking nut if it exists (identical to Section 6.3.3.2); • ST 3: screw transformation into beam elements (see Figure 6.18). FE beam elements are represented by line segments. The axis of the screw is used as location for the line segments; • ST 4: transfer of interfaces between plates and screw as points on the line segments. The blue part in Figure 6.18 represents the whole screw, the red parts are the projections of the interfaces between the plates and the screw while yellow points represent the idealization of these interfaces and define the connections between each plate and the screw; • ST 5: reduce junction holes in plates to single points. The fastener model used to represent bolted junctions does not represent holes in the final idealized model (see Figure 6.19). Different idealizations, i.e., the set of ST , can be generated to match different simulation objectives. For instance, one ST can focus on the screw stiffness in addition to the current simulation objectives. To this end, a new objective can be set up to compare the mechanical behavior when screws are modeled as beams and when they are perfectly rigid. Consequently, the screws must now be represented as rigid bodies. This means that the blue part (see Figure 6.18) representing the FE beam element is no longer needed. Then, the yellow points (see Figure 6.18) can be used directly to generate the mesh connection points in the final medial surfaces of the plate components. These points can be used to set kinematic constraints. Indeed, the list of previous geometric operations describes a new category of shape transformation, ST i that would be needed to meet this new simulation objective. Be- 185Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models cause these transformations are close the templates described, this shows how the principle of the template-based transformations can be extended to be adapted to new simulation objectives using additional elementary transformations. Here, ST 3 would be replaced by ST i that would produce the key points needed to express the kinematic constraints. Now that the bolted junctions have been simplified into FE fasteners, the next section illustrates the idealization of the whole assembly. 6.4.2 Presentation of a prototype dedicated to the generation of idealized assemblies In order to generalize the idealization approach presented in Chapter 5, a prototype has been developed to process not only components but also whole assemblies. Likewise the template demonstrator, the prototype is based on OpenCascade [CAS14] and Python scripting language. The CAD assembly as well as the geometric interfaces are imported as STEP models. Figure 6.19 illustrates the user interface of the prototype. Here, the 3D viewer shows the result of task 2 where the bolted junctions of the CAD assembly have been transformed into simple fasteners using the template-based approach. The interface graph in the graph tag shows all the neighboring relationships between assembly components (including the fasteners). Figure 6.20 illustrates task 3 where the assembly components are segmented into sub-domains according to shape primitives organized into a construction graph. The set of solid primitives in red is extracted using the algorithm described in Section 4.5.2. The primitives are then removed from the initial solid to obtain a simpler component shape. Once the construction graph is generated, the user selects a construction process which creates a component segmentation into volume sub-domains. Then, each sub-domain is idealized wherever the primitive extent versus its thickness satisfies the idealization criterion. The interfaces resulting from this idealization can be associated with new transformations of assembly interfaces, e.g., a group of parallel idealized surfaces linked to the same assembly interface can be aligned and connected. The analysis of interactions between independently idealized sub-domains can guide geometric transformations such as sub-domain offsets and connections. These transformations are part of task 4. Figure 6.21 illustrates an intermediate result of the idealization process of a component (task 5). The graph of primitives’ interfaces has been analyzed in task 4 to identify and align groups of parallel medial surfaces. For example, the medial surface highlighted in brown is offset by 2.9 mm from its original position. The medial surfaces are then connected with the operator described in Section 5.5.3. The result is a fully idealized representation of the component. Finally, other idealized components are incorporated in the idealized assembly 186Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models List of interfaces List of components 3D Viewer Output/ Input console Graph of interfaces Figure 6.19: User interface of the prototype for assembly idealization. The 3D viewer shows the assembly after the transformation of bolted junctions into FE fasteners. Configurations of component’s segmentation 3D Visualization of a set of primitives to be removed from solid Configuration of the primitives extraction algorithm Figure 6.20: Illustration of a component segmentation which extract extruded volumes to be idealized in task 3. The primitives to be removed from the initial solid are highlighted in red. 187Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models List of interfaces between primitives List of component’s primitives 3D Vizualization of component idealization Primitive attributes Graph of interfaces between primitives Figure 6.21: Illustration of task 4: Identification and transformation of groups of idealized surfaces connected to the same assembly interfaces. model using complementary sub-domain transformations applied to each of them as illustrated in Figure 6.22. List of idealized components and fasteners 3D Vizualization of assembly idealization Figure 6.22: Final result of the idealized assembly model ready to be meshed in CAE software. Again, functional information about components and successive decomposition into 188Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models sub-domains as well as idealization processes reduce the preparation process to minutes: up to approximately ten minutes to process all the components including all the user interactions required to load each component, select the appropriate template or process the components subjected to the segmentation process and the morphological analysis. This is a significant time reduction compared to the days required when performing interactively the same transformations using tedious interactions with low level operators existing in current CAE software. Yet, the constraints related to mesh generation through mesh size constraints, have not been taken into account in the current analysis of preparation processes. These constraints have to be addressed in future research work. It has also to be noted that the process flow of Figure 6.5 turns into a sequential flow in all the simulation frameworks illustrated. 6.5 Conclusion In this chapter, dependencies between categories of shape transformations have been organized to structure the assembly simulation model preparation process in terms of methodology and scope of shape transformation operators. The proposed methodology empowers the use of DMUs enriched with geometric interfaces and functional information to automate CAD assembly pre-processing and to generate a ‘FE-friendly’ equivalence of this assembly. The template-based method has shown that shape transformations highly benefit from functional information. Using functional information strengthens the transformation of complex models like assemblies where many components interact with each other. The template can be instantiated over the whole assembly to quickly transform repetitive configurations such as bolted junctions that are highly time-consuming when processed purely interactively. The idealization method introduces a robust geometric operator of assembly idealization. This operator takes advantage of the assembly decomposition into sub-domains and their associated geometric interfaces as produced in Chapter 5. This structure has been used successfully to idealize sub-domains and address some general mesh generation constraints to ensure obtaining high quality meshes. Finally, a demonstrator has been implemented to prove the validity of the proposed methodology. This prototype has been applied to an industrial use-case proposed in ROMMA project [ROM14] to create a simplified solid model and an idealized, surfacebased model, using the operators currently developed. This use-case has demonstrated the benefits of the proposed methodology to: 1. Efficiently process real 3D assemblies extracted from large DMU; 189Chapter 6: Toward a methodology to adapt an enriched DMU to FE assembly models 2. Enable the implementation of a robust approach to monitor automated shape transformations. Thanks to this methodology, the preparation time can be drastically shortened compared to purely interactive processes as commonly practiced by today’s engineers. 190Conclusion and perspectives Assemblies, as sets of components, bring a new complexity level for CAD-FEA data processing of mechanical structures. Here, new principles and associated operators have been developed to automate the adaptation of CAD assembly models. The objective targeted robust transformations to process the large amount of repetitive geometric configurations of complex assemblies and to reduce the time spent by engineers to prepare these assemblies. Summary of conclusions Now, each of the contributions stated in the previous chapters can be synthesized and summarized. In-depth analysis of FE pre-processing rules The first contribution stands in the analysis of the current pre-processing of CAD models derived from DMUs to produce FE models. Due to the lack of assembly-related information in a DMU, very tedious tasks are required to process the large amount of components as well as their connections. Preparing each component is already a tedious task, especially when idealizations are necessary, that increases significantly with the number of components and their interfaces. Additionally, these interfaces form new entities to be processed. It has been observed that repetitive configurations and their processing are also an issue of assembly preparation, justifying the need to automate the preparation of large assembly models. This first analysis has concluded that the adaption of an assembly to FEA requirements and geometric transformations derive from simulation objectives and component functions are needed as well to geometrically transform groups of components. Also, it has been shown that functional information can be an efficient enrichment of a DMU to identify and process repetitive configurations. Challenging assembly models preparation Studying the current CAD-FEA methods and tools related to data integration 191Conclusion and perspectives reveals that operators currently available focus on the transformation of standalone components. One main contribution of this thesis is the proposal of an approach to assembly model preparation. Rather than reducing the preparation process to a sequence of separately prepared parts, the entire assembly has been considered when specifying shape transformations to reach simulation objectives, taking into account the kinematics and physics associated with assembly interfaces. The proposed approach to assembly pre-processing uses, as input model, a DMU enriched at an assembly level with interface geometry between components, additional functional properties of these components, and, at the component level, a structured volume segmentation using a graph structure. Geometrically enriched components A new approach has been proposed to decompose a B-Rep solid into volume subdomains. This approach robustly enriches a CAD component using a construction graph and provides a volume decomposition of each component shape. This construction graph is generated by iteratively identifying and removing a set of extrusion primitives from the current B-Rep shape. It has been shown that, compared to any initial construction process performed by a designer, the extracted graph is unique for a given object and is intrinsic to its shape because it overcomes modeling, surface decomposition, and topological constraints. In addition, it provides non trivial construction trees, i.e., variants of extrusion directions producing the same primitive are not represented and variants in primitives ordering are grouped into a single node. This generates a compact representation of a large set of shape construction processes. Moreover, the proposed approach, while enriching a standalone component shape, can be extended to assembly structures after they have been enriched with component interfaces. Each component construction graph can be nested into the component-interface assembly structure, thus forming a robust data structure for CAD-FEA transformation processes. Finally, a graph of generative processes of a B-Rep component is a promising basis to gain a better insight about a shape structure. The criteria used to generate this graph bring meaningful and simple primitives which can be subsequently used to support the idealization process of component shapes. Formalizing a shape idealization process through a morphological analysis It has been shown that generating a fully idealized model cannot be reduced to a pure application of a dimensional reduction operator such that this model is a mechanical equivalence of the initial component. The incorporation of idealization hypotheses requires the identification of candidate geometric areas associated with the connections between idealized sub-domains. The proposed idealization process benefits from the new enrichment of components with their shape structure. The segmentation of the component into meaningful primitives and interfaces between them has been used as a first step of a morphological analysis. This analysis evaluates each primitive with re- 192Conclusion and perspectives spect to its dominant idealized shape. Then, using a taxonomy of geometric interfaces between idealized sub-domains, this analysis is propagated over the whole component and results in the decomposition of its shape into ’idealizable’ areas of type ’plate/shell, beam and ’non-idealizable’ areas. Overall, the morphological analysis is independent from any resolution method and is able to characterize geometric details in relation to local and to ’idealizable’ regions of a component. Finally, an idealization operator has been developed which transforms the sub-domains into medial surfaces/lines and robustly connects them using the precise geometric definition of interfaces between primitives. Laying down the basis of a methodology to assembly preparation To address the current industrial needs about assembly pre-processing for structural simulation, the analysis of dependencies between geometric transformations, simulation objectives, and simplification hypotheses led to a first methodology increasing the level of automation of FE assembly model pre-processing. Using an enriched DMUs containing geometric interfaces between components and their primitives as well as functional information to end up with the generation of a ‘FE-friendly’ equivalence of this assembly, the methodology is in line with the industrial needs to develop a new generation of DMU: the Functional DMU. Finally, the development of a prototype platform has illustrated that the methodology fits well with the methods and tools proposed in this thesis. The template-based transformation, empowering the use of functional information, has illustrated how repetitive configurations, such as assembly junctions, can be automatically transformed. Then, the generation of the complete idealization of an aeronautical structure has demonstrated the ability of the proposed idealization approach to efficiently process CAD assemblies extracted from a large DMU. As a final conclusion, compared to purely geometric operators currently available in CAD-FEA integration, this thesis has proposed an approach based on a shape analysis of a enriched DMU model that significantly shortens the time commonly spent by today’s engineers and robustly performs repetitive idealization transformations of components and assemblies as well. Research perspectives From the proposed approach of DMU pre-processing for structural assembly simulation, future work can extend and build further on the methods and tools described in this thesis. The perspectives presented in this section refers to the generation of construction graph of B-Rep shapes and to the morphological analysis of DMU models. 193Conclusion and perspectives Construction graph Regarding the generation of construction graphs from B-Rep shapes, perspectives are listed as follows: • Extend the definition of primitive to include material removal as well as additional operations (revolution, sweep,. . . ). In a first step, to reduce the complexity of this research work, the choice has been made to concentrate the extraction of generative processes on extrusion primitives. Primitives are combined solely using a material addition operator. Clearly, future work will focus on incorporating material removal operations and revolutions to extend the range of objects that can be processed. Allowing new definitions of primitives may increase the amount of primitives. However, the construction graph can be even more compact. Indeed, groups of extrusion primitives can be replaced by a unique revolution, or a sweeping primitive in the construction graph. To reduce the complexity of the dimensional reduction of primitives, the presented idealization process favored primitives adding material instead of primitives removing material. Including primitives which removes material can be convenient for other applications, e.g., to simplify components’ shapes for 3D simulation or to identify cavities in components for computational fluid simulations. • Extend the attachment condition of primitives. Regarding the attachment of a primitive into an object, it has been shown all the benefits to avoid constraining the primitive identification process with their attachment conditions and to avoid looking at prioritizing primitives with geometric criteria such as: largest visible boundaries within the object. Identifying primitives without restriction on their ’visible’ boundaries is a way to release this constraint. However, to validate the major concepts of the proposed approach, two restrictions have been set on the primitive definition. The extrusion distance had to be represented by a lateral edge and one of the primitive’s base face had to be totally ’visible’. A future target stands in the generalization of the primitive definition to enlarge the number of valid primitives and hence, will produce a more generic algorithm; • Reduce the interaction between primitives. Currently, the computation time is highly dependent on the number of extracted primitives which are compared with each others. To reduce the complexity of the algorithm, future work may integrate the identification of repetitions and symmetries [LFLT14]. It is not only the global symmetries or repetitions, e.g., reflective symmetries valid at each point of an object, which may directly reduce the extent of a shape being analyzed, more frequently partial symmetries and repetitions are more efficient to identify specific relationships between primitives. Partial symmetries and repetitions initiated by the location of identical primitives convey a strong meaning from a shape point of view. They can be used after the extraction of primitives to generate groups of symmetrical/repetitive primitives or even before that 194Conclusion and perspectives stage to help identifying primitives, e.g., selecting a set of base faces sharing the same plane and the same orientation. Finally, symmetries and repetitions are very relevant to structure an idealized model to propagate these shape structure information across the mesh generation phase. • Further applications of construction graphs. A construction graph structures the shape of a B-Rep object independently from any CAD modeler. Applied to hex-meshing, a shape intrinsic segmentation into extrusion primitives extracted from its construction graph can be highly beneficial. Indeed, it directly provides simple meshable volumes. Moreover, the complementary information about the connections between primitive interfaces can help to generate a complete component 3D mesh. Applied to 3D direct modeling CAD software, this intrinsic shape structure can be used to significantly extend this approach with larger shape modification as well as parametrization capabilities. Because primitives are geometrically independent of each other, the parametrization of a primitive can be directly related to the object shape, i.e., the influence of the shape modification of a primitive can be identified through the interface of this primitive with the object. Morphological analysis of assemblies. The morphological analysis method of Chapter 5 has been presented as a preliminary step for dimensional reduction operations. The perspectives related to this morphological analysis are as follows: • Extend the taxonomy of reference morphologies. The determination of idealizable volume sub-domains in a component is based on a taxonomy of morphologies. Each morphology is associated with one medial edge of the MAT applied to the extrusion contour of a primitive. Clearly, this taxonomy is not complete. Only morphologies associated with straight medial edges with constant radius has been studied. To enable the processing of a larger range of component shapes, this taxonomy can be extended, in a first step, to curved edges, with or without radius variation, and, in a second step, to other types of primitives (revolution, sweeping, . . . ); • Extend the taxonomy of connections. Regarding the propagation of the morphological analysis of primitives to the whole object, the current taxonomy of connections covers extrusion sub-domains to be idealized with planar medial surfaces only. The detailed study of these configurations has demonstrated all the robustness of the proposed approach. Here too, this taxonomy can be enlarged to process beams, shells, or thick domains. In addition, the taxonomy of connections is currently restricted to couples of sub-domains. In case of groups of connected sub-domains, a new level of morphology may emerge, e.g., a set of piled up thin extrusion primitives forming a beam. Analyzing and formalizing 195Conclusion and perspectives this new taxonomy of connections between sub-domains will enlarge the shape configurations which can be processed; • Extend the approach to the morphological analysis of assemblies. Although construction graph structures (primitives/interfaces) is compatible with assembly structures (components/interfaces), the morphological analysis has been applied on standalone components. When the input model is an assembly structure, the assembly interfaces brings a new level of information. The influence of assembly interfaces on the established taxonomies have to be studied to extend the morphology analysis to assembly. For example, on large assemblies models, a group of component can be viewed as a unique morphology. Propagating the morphological analysis of components to the whole assembly will give the user a complete access to multi-resolution morphological levels of a DMU. Finally, we can mention the report from a 2013 ASME Panel on Geometric Interoperability for Advanced Manufacturing [SS14]. The panelists involved had considerable experience in the use of component geometry throughout various design and manufacturing softwares. They stated that current CAD systems have hit hard limit with the representation of 3D products. They came to the same conclusions that we have highlighted about the need of a better interoperability of geometric models and design systems with current DMUs. The proposed approaches made in this thesis with construction graph and morphological analysis of assembly offers new opportunities to adapt a model to the needs of the different applications involved in a product development process. 196Bibliography [AA96] Aichholzer O., Aurenhammer F.: Straight skeletons for general polygonal figures in the plane. In Computing and Combinatorics, Cai J.-Y., Wong C., (Eds.), vol. 1090. Springer Berlin Heidelberg, 1996, pp. 117–126. 57 [AAAG96] Aichholzer O., Aurenhammer F., Alberts D., Grtner B.: A novel type of skeleton for polygons. In J.UCS The Journal of Universal Computer Science, Maurer H., Calude C., Salomaa A., (Eds.). Springer Berlin Heidelberg, 1996, pp. 752–761. 57 [ABA02] Andujar C., Brunet P., Ayala D.: Topology-reducing surface simplification using a discrete solid representation. ACM Trans. Graph.. Vol. 21, Num. 2 (avril 2002), 88–105. 39, 44, 47, 64 [ABD∗98] Armstrong C. G., Bridgett S. J., Donaghy R. J., Mccune R. W., Mckeag R. M., Robinson D. J.: Techniques for interactive and automatic idealisation of CAD models. In Proceedings of the Sixth International Conference on Numerical Grid Generation in Computational Field Simulations (Mississippi State, Mississippi, 39762 USA, 1998), NSF Engineering Research Center for Computational Field Simulation, ISGG, pp. 643–662. 35, 53 [ACK01] Amenta N., Choi S., Kolluri R. K.: The power crust, unions of balls, and the medial axis transform. Computational Geometry. Vol. 19, Num. 2 (2001), 127–153. 54 [AFS06] Attene M., Falcidieno B., Spagnuolo M.: Hierarchical mesh segmentation based on fitting primitives. The Visual Computer. Vol. 22, Num. 3 (2006), 181–193. 59 [AKJ01] Anderson D., Kim Y. S., Joshi S.: A discourse on geometric feature recognition from cad models. J Comput Inform Sci Eng. Vol. 1, Num. 1 (2001), 440–746. 51 [AKM∗06] Attene M., Katz S., Mortara M., Patane G., Spagnuolo ´ M., Tal A.: Mesh segmentation-a comparative study. In Shape 197BIBLIOGRAPHY Modeling and Applications, 2006. SMI 2006. IEEE International Conference on (2006), IEEE, pp. 7–7. 59 [ALC08] ALCAS: Advanced low-cost aircraft structures project. http:// alcas.twisoftware.com/, 2005 – 2008. xv, 18 [AMP∗02] Armstrong C. G., Monaghan D. J., Price M. A., Ou H., Lamont J.: Engineering computational technology. Civil-Comp press, Edinburgh, UK, UK, 2002, ch. Integrating CAE Concepts with CAD Geometry, pp. 75–104. 35 [Arm94] Armstrong C. G.: Modelling requirements for finite-element analysis. Computer-aided design. Vol. 26, Num. 7 (1994), 573–578. xvi, 48, 49, 132 [ARM∗95] Armstrong C., Robinson D., McKeag R., Li T., Bridgett S., Donaghy R., McGleenan C.: Medials for meshing and more. In Proceedings of the 4th International Meshing Roundtable (1995). 48, 49, 53 [B∗67] Blum H., et al.: A transformation for extracting new descriptors of shape. Models for the perception of speech and visual form. Vol. 19, Num. 5 (1967), 362–380. 48 [Bad11] Badin J.: Ing´enierie hautement productive et collaborative `a base de connaissances m´etier: vers une m´ethodologie et un m´eta-mod`ele de gestion des connaissances en configurations. PhD thesis, BelfortMontb´eliard, 2011. 44 [Bat96] Bathe K.-J.: Finite element procedures, vol. 2. Englewood Cliffs, NJ: Prentice-Hall, 1996. 24 [BBB00] Belaziz M., Bouras A., Brun J.-M.: Morphological analysis for product design. Computer-Aided Design. Vol. 32, Num. 5 (2000), 377–388. 63 [BBT08] Bellenger E., Benhafid Y., Troussier N.: Framework for controlled cost and quality of assumptions in finite element analysis. Finite Elements in Analysis and Design. Vol. 45, Num. 1 (2008), 25– 36. 44 [BC04] Buchele S. F., Crawford R. H.: Three-dimensional halfspace constructive solid geometry tree construction from implicit boundary representations. CAD. Vol. 36 (2004), 1063–1073. 62, 63, 107 198BIBLIOGRAPHY [BCGM11] Badin J., Chamoret D., Gomes S., Monticolo D.: Knowledge configuration management for product design and numerical simulation. In Proceedings of the 18th International Conference on Engineering Design (ICED11), Vol. 6 (2011), pp. 161–172. 44 [BCL12] Ba W., Cao L., Liu J.: Research on 3d medial axis transform via the saddle point programming method. Computer-Aided Design. Vol. 44, Num. 12 (2012), 1161 – 1172. 54 [BEGV08] Barequet G., Eppstein D., Goodrich M. T., Vaxman A.: Straight skeletons of three-dimensional polyhedra. In Algorithms-ESA 2008. Springer, 2008, pp. 148–160. 57 [Bic95] Bickford J.: An Introduction to the Design and Behavior of Bolted Joints, Revised and Expanded, vol. 97. CRC press, 1995. 178 [BKR∗12] Barbau R., Krima S., Rachuri S., Narayanan A., Fiorentini X., Foufou S., Sriram R. D.: Ontostep: Enriching product model data using ontologies. Computer-Aided Design. Vol. 44, Num. 6 (2012), 575–590. 27 [BLHF12] Boussuge F., Leon J.-C., Hahmann S., Fine L. ´ : An analysis of DMU transformation requirements for structural assembly simulations. In The Eighth International Conference on Engineering Computational Technology (Dubronik, Croatie, 2012), B.H.V. Topping, Civil Comp Press. 65, 82 [BLHF14a] Boussuge F., Lon J.-C., Hahmann S., Fine L.: Extraction of generative processes from b-rep shapes and application to idealization transformations. Computer-Aided Design. Vol. 46, Num. 0 (2014), 79 – 89. 2013 {SIAM} Conference on Geometric and Physical Modeling. 86 [BLHF14b] Boussuge F., Lon J.-C., Hahmann S., Fine L.: Idealized models for fea derived from generative modeling processes based on extrusion primitives. In Proceedings of the 22nd International Meshing Roundtable (2014), Sarrate J., Staten M., (Eds.), Springer International Publishing, pp. 127–145. 86 [BLNF07] Bellec J., Ladeveze P., N ` eron D., Florentin E. ´ : Robust computation for stochastic problems with contacts. In International Conference on Adaptive Modeling and Simulation (2007). 82 [BR78] Babuvˇska I., Rheinboldt W. C.: Error estimates for adaptive finite element computations. SIAM Journal on Numerical Analysis. Vol. 15, Num. 4 (1978), 736–754. 46 199BIBLIOGRAPHY [BS96] Butlin G., Stops C.: Cad data repair. In Proceedings of the 5th International Meshing Roundtable (1996), pp. 7–12. 47 [BSL∗14] Boussuge F., Shahwan A., Lon J.-C., Hahmann S., Foucault G., Fine L.: Template-based geometric transformations of a functionally enriched dmu into fe assembly models. Computer-Aided Design and Applications. Vol. 11, Num. 4 (2014), 436–449. 168 [BWS03] Beall M. W., Walsh J., Shephard M. S.: Accessing cad geometry for mesh generation. In IMR (2003), pp. 33–42. 47 [CAS14] CASCADE O.: Open cascade technology, version 6.7.0 [computer software]. http://www.opencascade.org/, 1990 – 2014. 12, 112, 179, 186 [CAT14] CATIA D.: Dassault syst`emes catia, version v6r2013x [computer software]. http://www.3ds.com/products-services/catia/, 2008 – 2014. 89, I, IX [CBG08] Champaney L., Boucard P.-A., Guinard S.: Adaptive multianalysis strategy for contact problems with friction. Computational Mechanics. Vol. 42, Num. 2 (2008), 305–315. 30, 175, 177 [CBL11] Cao L., Ba W., Liu J.: Computation of the medial axis of planar domains based on saddle point programming. Computer-Aided Design. Vol. 43, Num. 8 (2011), 979 – 988. 54 [Cha12] Champaney L.: A domain decomposition method for studying the effects of missing fasteners on the behavior of structural assemblies with contact and friction. Computer Methods in Applied Mechanics and Engineering. Vol. 205 (2012), 121–129. 30, 175, 177 [CHE08] Clark B. W., Hanks B. W., Ernst C. D.: Conformal assembly meshing with tolerant imprinting. In Proceedings of the 17th International Meshing Roundtable. Springer, 2008, pp. 267–280. 65 [CP99] Chapman C., Pinfold M.: Design engineeringa need to rethink the solution using knowledge based engineering. Knowledge-Based Systems. Vol. 12, Num. 56 (1999), 257 – 267. 168 [CSKL04] Chong C., Senthil Kumar A., Lee K.: Automatic solid decomposition and reduction for non-manifold geometric model generation. Computer-Aided Design. Vol. 36, Num. 13 (2004), 1357–1369. 39, 44, 61, 95, 119 200BIBLIOGRAPHY [CV06] Chouadria R., Veron P.: Identifying and re-meshing contact interfaces in a polyhedral assembly for digital mock-up. Engineering with Computers. Vol. 22, Num. 1 (2006), 47–58. 65 [DAP00] Donaghy R. J., Armstrong C. G., Price M. A.: Dimensional reduction of surface models for analysis. Engineering with Computers. Vol. 16, Num. 1 (2000), 24–35. 39, 45, 53 [DLG∗07] Drieux G., Leon J.-C., Guillaume F., Chevassus N., Fine ´ L., Poulat A.: Interfacing product views through a mixed shape representation. part 2: Model processing description. International Journal on Interactive Design and Manufacturing (IJIDeM). Vol. 1, Num. 2 (2007), 67–83. 43 [DMB∗96] Donaghy R., McCune W., Bridgett S., Armstrong D., Robinson D., McKeag R.: Dimensional reduction of analysis models. In Proceedings of the 5th International Meshing Roundtable (1996). 53 [Dri06] Drieux G.: De la maquette numrique produit vers ses applications aval : propositions de modles et procds associs. PhD thesis, Institut National Polytechnique, Grenoble, FRANCE, 2006. 6, 19 [DSG97] Dey S., Shephard M. S., Georges M. K.: Elimination of the adverse effects of small model features by the local modification of automatically generated meshes. Engineering with Computers. Vol. 13, Num. 3 (1997), 134–152. 47 [Eck00] Eckard C.: Advantages and disavantadges of fem analysis in an early state of the design process. In Proc. of the 2nd Worldwide Automotive Conference, MSC Software Corp, Dearborn, Michigan, USA (2000). 44 [EF11] E. Florentin S.Guinard P. P.: A simple estimator for stress errors dedicated to large elastic finite element simulations: Locally reinforced stress construction. Engineering Computations: Int J for Computer-Aided Engineering (2011). 46 [FCF∗08] Foucault G., Cuilliere J.-C., Franc¸ois V., L ` eon J.-C., ´ Maranzana R.: Adaptation of cad model topology for finite element analysis. Computer-Aided Design. Vol. 40, Num. 2 (2008), 176–196. xvi, 34, 50, 97 [FEA14] FEA A. U.: Dassault syst`emes abaqus unified fea, version 6.13 [computer software]. http://www.3ds.com/products-services/ simulia/portfolio/abaqus/overview/, 2005 – 2014. 180, XIX 201BIBLIOGRAPHY [Fin01] Fine L.: Processus et mthodes d’adaptation et d’idalisation de modles ddis l’analyse de structures mcaniques. PhD thesis, Institut National Polytechnique, Grenoble, FRANCE, 2001. 22, 34, 45, 47 [FL∗10] Foucault G., Leon J.-C., et al. ´ : Enriching assembly cad models with functional and mechanical informations to ease cae. In Proceedings of the ASME 2010 International Design Engineering Technical Conferences & Computers and Information in Engineering Conference IDETC/CIE 2010 August 15-18, 2010, Montr´eal, Canada (2010). 18, 20 [FLM03] Foskey M., Lin M. C., Manocha D.: Efficient computation of a simplified medial axis. In Proceedings of the eighth ACM symposium on Solid modeling and applications (2003), ACM, pp. 96–107. 54 [FMLG09] Ferrandes R., Marin P. M., Leon J. C., Giannini F. ´ : A posteriori evaluation of simplification details for finite element model preparation. Comput. Struct.. Vol. 87, Num. 1-2 (janvier 2009), 73– 80. 44 [Fou07] Foucault G.: Adaptation de modles CAO paramtrs en vue d’une analyse de comportement mcanique par lments finis. PhD thesis, Ecole ´ de technologie sup´erieure, Montreal, CANADA, 2007. 13, 18, 46 [FRL00] Fine L., Remondini L., Leon J.-C.: Automated generation of fea models through idealization operators. International Journal for Numerical Methods in Engineering. Vol. 49, Num. 1-2 (2000), 83–108. 44 [GPu14] GPure: Gpure, version 3.4 [computer software]. http://www. gpure.net, 2011 – 2014. 35 [GZL∗10] Gao S., Zhao W., Lin H., Yang F., Chen X.: Feature suppression based cad mesh model simplification. Computer-Aided Design. Vol. 42, Num. 12 (2010), 1178–1188. 44 [HC03] Haimes R., Crawford C.: Unified geometry access for analysis and design. In IMR (2003), pp. 21–31. 47 [HLG∗08] Hamri O., Leon J.-C., Giannini F., Falcidieno B., Poulat ´ A., Fine L.: Interfacing product views through a mixed shape representation. part 1: Data structures and operators. International Journal on Interactive Design and Manufacturing (IJIDeM). Vol. 2, Num. 2 (2008), 69–85. 43 202BIBLIOGRAPHY [HPR00] Han J., Pratt M., Regli W. C.: Manufacturing feature recognition from solid models: a status report. Robotics and Automation, IEEE Transactions on. Vol. 16, Num. 6 (2000), 782–796. 51 [HR84] Hoffman D. D., Richards W. A.: Parts of recognition. Cognition. Vol. 18, Num. 1 (1984), 65–96. 59 [HSKK01] Hilaga M., Shinagawa Y., Kohmura T., Kunii T. L.: Topology matching for fully automatic similarity estimation of 3d shapes. In Proceedings of the 28th annual conference on Computer graphics and interactive techniques (2001), ACM, pp. 203–212. 59 [Hut86] Huth H.: Influence of fastener flexibility on the prediction of load transfer and fatigue life for multiple-row joints. Fatigue in mechanically fastened composite and metallic joints, ASTM STP. Vol. 927 (1986), 221–250. 29 [IIY∗01] Inoue K., Itoh T., Yamada A., Furuhata T., Shimada K.: Face clustering of a large-scale cad model for surface mesh generation. Computer-Aided Design. Vol. 33, Num. 3 (2001), 251–261. 49 [IML08] Iacob R., Mitrouchev P., Leon J.-C. ´ : Contact identification for assembly–disassembly simulation with a haptic device. The Visual Computer. Vol. 24, Num. 11 (2008), 973–979. 6 [ISO94] ISO:. ISO TC184-SC4: ISO-10303 Part 203 - Application Protocol: Configuration controlled 3D design of mechanical parts and assemblies, 1994. 33, 72, 89, 180, XIX [ISO03] ISO:. ISO TC184-SC4: ISO-10303 Part 214 - Application Protocol: Core data for automotive mechanical design processes, 2003. 33, 72, 89, 180, XIX [JB95] Jones M.R. M. P., Butlin G.: Geometry management support for auto-meshing. In Proceedings of the 4th International Meshing Roundtable (1995), pp. 153–164. 47 [JBH∗14] Jourdes F., Bonneau G.-P., Hahmann S., Leon J.-C., Faure ´ F.: Computation of components interfaces in highly complex assemblies. Computer-Aided Design. Vol. 46 (2014), 170–178. xvi, 65, 71, 72, 79, 116 [JC88] Joshi S., Chang T.-C.: Graph-based heuristics for recognition of machined features from a 3d solid model. Computer-Aided Design. Vol. 20, Num. 2 (1988), 58–66. 51 203BIBLIOGRAPHY [JD03] Joshi N., Dutta D.: Feature simplification techniques for freeform surface models. Journal of Computing and Information Science in Engineering. Vol. 3 (2003), 177. 51 [JG00] Jha K., Gurumoorthy B.: Multiple feature interpretation across domains. Computers in industry. Vol. 42, Num. 1 (2000), 13–32. 51, 94, 100 [KLH∗05] Kim S., Lee K., Hong T., Kim M., Jung M., Song Y.: An integrated approach to realize multi-resolution of b-rep model. In Proceedings of the 2005 ACM symposium on Solid and physical modeling (2005), ACM, pp. 153–162. 51 [Kos03] Koschan A.: Perception-based 3d triangle mesh segmentation using fast marching watersheds. In Computer Vision and Pattern Recognition, 2003. Proceedings. 2003 IEEE Computer Society Conference on (2003), vol. 2, IEEE, pp. II–27. 59 [KT03] Katz S., Tal A.: Hierarchical mesh decomposition using fuzzy clustering and cuts. ACM Trans. Graph.. Vol. 22, Num. 3 (juillet 2003), 954–961. 59 [KWMN04] Kim K.-Y., Wang Y., Muogboh O. S., Nnaji B. O.: Design formalism for collaborative assembly design. Computer-Aided Design. Vol. 36, Num. 9 (2004), 849–871. 27, 64 [LAPL05] Lee K. Y., Armstrong C. G., Price M. A., Lamont J. H.: A small feature suppression/unsuppression system for preparing b-rep models for analysis. In Proceedings of the 2005 ACM symposium on Solid and physical modeling (New York, NY, USA, 2005), SPM ’05, ACM, pp. 113–124. 35, 39, 44 [LDB05] Lavoue G., Dupont F., Baskurt A. ´ : A new cad mesh segmentation method, based on curvature tensor analysis. Computer-Aided Design. Vol. 37, Num. 10 (2005), 975–987. 59 [Ley01] Leyton M.: A Generative Theory of Shape (Lecture Notes in Computer Science, LNCS 2145). Springer-Verlag, 2001. 93 [LF05] Leon J.-C., Fine L. ´ : A new approach to the preparation of models for fe analyses. International journal of computer applications in technology. Vol. 23, Num. 2 (2005), 166–184. 35, 39, 44, 45, 81 [LFLT14] Li K., Foucault G., Leon J.-C., Trlin M.: Fast global and partial reflective symmetry analyses using boundary surfaces of mechanical components. Computer-Aided Design, Num. 0 (2014), –. 194 204BIBLIOGRAPHY [LG97] Liu S.-S., Gadh R.: Automatic hexahedral mesh generation by recursive convex and swept volume decomposition. In Proceedings 6th International Meshing Roundtable, Sandia National Laboratories (1997), Citeseer, pp. 217–231. 60 [LG05] Lockett H. L., Guenov M. D.: Graph-based feature recognition for injection moulding based on a mid-surface approach. ComputerAided Design. Vol. 37, Num. 2 (2005), 251–262. 51 [LGT01] Lu Y., Gadh R., Tautges T. J.: Feature based hex meshing methodology: feature recognition and volume decomposition. Computer-Aided Design. Vol. 33, Num. 3 (2001), 221–232. 60, 100 [LL83] Ladeveze P., Leguillon D.: Error estimate procedure in the finite element method and applications. SIAM Journal on Numerical Analysis. Vol. 20, Num. 3 (1983), 485–509. 46 [LLKK04] Lee J. Y., Lee J.-H., Kim H., Kim H.-S.: A cellular topologybased approach to generating progressive solid models from featurecentric models. Computer-Aided Design. Vol. 36, Num. 3 (2004), 217–229. 51 [LLM06] Li M., Langbein F. C., Martin R. R.: Constructing regularity feature trees for solid models. In Geometric Modeling and ProcessingGMP 2006. Springer, 2006, pp. 267–286. 63 [LLM10] Li M., Langbein F. C., Martin R. R.: Detecting design intent in approximate cad models using symmetry. Computer-Aided Design. Vol. 42, Num. 3 (2010), 183–201. 63 [LMTS∗05] Lim T., Medellin H., Torres-Sanchez C., Corney J. R., Ritchie J. M., Davies J. B. C.: Edge-based identification of dp-features on free-form solids. Pattern Analysis and Machine Intelligence, IEEE Transactions on. Vol. 27, Num. 6 (2005), 851–860. 93 [LNP07a] Lee H., Nam Y.-Y., Park S.-W.: Graph-based midsurface extraction for finite element analysis. In Computer Supported Cooperative Work in Design, 2007. CSCWD 2007. 11th International Conference on (2007), pp. 1055–1058. 56 [LNP07b] Lee H., Nam Y.-Y., Park S.-W.: Graph-based midsurface extraction for finite element analysis. In Computer Supported Cooperative Work in Design, 2007. CSCWD 2007. 11th International Conference on (2007), pp. 1055–1058. 119 205BIBLIOGRAPHY [LOC16] LOCOMACHS: Low cost manufacturing and assembly of composite and hybrid structures project. http://www.locomachs.eu/, 2012 – 2016. xv, 18 [LPA∗03] Lee K., Price M., Armstrong C., Larson M., Samuelsson K.: Cad-to-cae integration through automated model simplification and adaptive modelling. In International Conference on Adaptive Modeling and Simulation (2003). 47, 49 [LPMV10] Lou R., Pernot J.-P., Mikchevitch A., Veron P. ´ : Merging enriched finite element triangle meshes for fast prototyping of alternate solutions in the context of industrial maintenance. Computer-Aided Design. Vol. 42, Num. 8 (2010), 670–681. 65 [LSJS13] Lee-St John A., Sidman J.: Combinatorics and the rigidity of cad systems. Computer-Aided Design. Vol. 45, Num. 2 (2013), 473–482. 19 [LST∗12] Li K., Shahwan A., Trlin M., Foucault G., Leon J.-C. ´ : Automated contextual annotation of b-rep cad mechanical components deriving technology and symmetry information to support partial retrieval. In Proceedings of the 5th Eurographics Conference on 3D Object Retrieval (Aire-la-Ville, Switzerland, Switzerland, 2012), EG 3DOR’12, Eurographics Association, pp. 67–70. 20 [LZ04] Liu R., Zhang H.: Segmentation of 3d meshes through spectral clustering. In Computer Graphics and Applications, 2004. PG 2004. Proceedings. 12th Pacific Conference on (2004), IEEE, pp. 298–305. 59 [Man88] Mantyla M.: An Introduction to Solid Modeling. W. H. Freeman & Co., New York, NY, USA, 1988. 93 [MAR12] Makem J., Armstrong C., Robinson T.: Automatic decomposition and efficient semi-structured meshing of complex solids. In Proceedings of the 20th International Meshing Roundtable, Quadros W., (Ed.). Springer Berlin Heidelberg, 2012, pp. 199–215. xvi, 60, 119, 126 [MCC98] Mobley A. V., Carroll M. P., Canann S. A.: An object oriented approach to geometry defeaturing for finite element meshing. In Proceedings of the 7th International Meshing Roundtable, Sandia National Labs (1998), pp. 547–563. 35 [MCD11] Musuvathy S., Cohen E., Damon J.: Computing medial axes of generic 3d regions bounded by b-spline surfaces. Computer-Aided 206BIBLIOGRAPHY Design. Vol. 43, Num. 11 (2011), 1485 – 1495. ¡ce:title¿Solid and Physical Modeling 2011¡/ce:title¿. 54 [MGP10] Miklos B., Giesen J., Pauly M.: Discrete scale axis representations for 3d geometry. ACM Transactions on Graphics (TOG). Vol. 29, Num. 4 (2010), 101. 54 [OH04] O. Hamri J-C. Leon F. G.: A new approach of interoperability between cad and simulation models. In TMCE (2004). 48 [PFNO98] Peak R. S., Fulton R. E., Nishigaki I., Okamoto N.: Integrating engineering design and analysis using a multi-representation approach. Engineering with Computers. Vol. 14, Num. 2 (1998), 93– 114. 44 [QO12] Quadros W. R., Owen S. J.: Defeaturing cad models using a geometry-based size field and facet-based reduction operators. Engineering with Computers. Vol. 28, Num. 3 (2012), 211–224. 47 [QVB∗10] Quadros W., Vyas V., Brewer M., Owen S., Shimada K.: A computational framework for automating generation of sizing function in assembly meshing via disconnected skeletons. Engineering with Computers. Vol. 26, Num. 3 (2010), 231–247. 65 [RAF11] Robinson T., Armstrong C., Fairey R.: Automated mixed dimensional modelling from 2d and 3d cad models. Finite Elements in Analysis and Design. Vol. 47, Num. 2 (2011), 151 – 165. xvi, 44, 53, 54, 81, 119 [RAM∗06] Robinson T. T., Armstrong C. G., McSparron G., Quenardel A., Ou H., McKeag R. M.: Automated mixed dimensional modelling for the finite element analysis of swept and revolved cad features. In Proceedings of the 2006 ACM symposium on Solid and physical modeling (2006), SPM ’06, pp. 117–128. xvi, 53, 60, 61, 87, 126, 146 [RBO02] Rib R., Bugeda G., Oate E.: Some algorithms to correct a geometry in order to create a finite element mesh. Computers and Structures. Vol. 80, Num. 1617 (2002), 1399 – 1408. 47 [RDCG12] Russ B., Dabbeeru M. M., Chorney A. S., Gupta S. K.: Automated assembly model simplification for finite element analysis. In ASME 2012 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (2012), American Society of Mechanical Engineers, pp. 197–206. 64 207BIBLIOGRAPHY [Req77] Requicha A.: Mathematical models of rigid solid objects. Tech. rep., Technical Memorandum - 28, Rochester Univ., N.Y. Production Automation Project., 1977. 8 [Req80] Requicha A. G.: Representations for rigid solids: Theory, methods, and systems. ACM Computing Surveys (CSUR). Vol. 12, Num. 4 (1980), 437–464. 8 [Rez96] Rezayat M.: Midsurface abstraction from 3d solid models: general theory and applications. Computer-Aided Design. Vol. 28, Num. 11 (1996), 905 – 915. xvi, 35, 55, 56, 95, 100, 134 [RG03] Ramanathan M., Gurumoorthy B.: Constructing medial axis transform of planar domains with curved boundaries. Computer-Aided Design. Vol. 35, Num. 7 (2003), 619 – 632. 39, 54 [RG04] Ramanathan M., Gurumoorthy B.: Generating the mid-surface of a solid using 2d mat of its faces. Computer-Aided Design and Applications. Vol. 1, Num. 1-4 (2004), 665–674. 56 [RG10] Ramanathan M., Gurumoorthy B.: Interior medial axis transform computation of 3d objects bound by free-form surfaces. Computer-Aided Design. Vol. 42, Num. 12 (2010), 1217 – 1231. 54 [Roc12] Rocca G. L.: Knowledge based engineering: Between {AI} and cad. review of a language based technology to support engineering design. Advanced Engineering Informatics. Vol. 26, Num. 2 (2012), 159 – 179. Knowledge based engineering to support complex product design. 168 [ROM14] ROMMA: Robust mechanical models for assemblies. http://romma. lmt.ens-cachan.fr/, 2010 – 2014. xix, 177, 180, 189 [Sak95] Sakurai H.: Volume decomposition and feature recognition: Part 1polyhedral objects. Computer-Aided Design. Vol. 27, Num. 11 (1995), 833–843. 61 [SBBC00] Sheffer A., Bercovier M., Blacker T., Clements J.: Virtual topology operators for meshing. International Journal of Computational Geometry & Applications. Vol. 10, Num. 03 (2000), 309–331. 49 [SBO98] Shephard M. S., Beall M. W., O’Bara R. M.: Revisiting the elimination of the adverse effects of small model features in automatically generated meshes. In IMR (1998), pp. 119–131. 47 208BIBLIOGRAPHY [SD96] Sakurai H., Dave P.: Volume decomposition and feature recognition, part ii: curved objects. Computer-Aided Design. Vol. 28, Num. 6 (1996), 519–537. 61 [SGZ10] Sun R., Gao S., Zhao W.: An approach to b-rep model simplifi- cation based on region suppression. Computers & Graphics. Vol. 34, Num. 5 (2010), 556–564. 39 [Sha95] Shah J. J.: Parametric and feature-based CAD/CAM: concepts, techniques, and applications. John Wiley & Sons, 1995. 13, 50 [She01] Sheffer A.: Model simplification for meshing using face clustering. Computer-Aided Design. Vol. 33, Num. 13 (2001), 925–934. 34, 49 [Sil81] Silva C. E.: Alternative definitions of faces in boundary representatives of solid objects. Tech. rep., Tech. Memo. 36, Production Automation Project, Univ. of Rochester, Rochester, N.Y., 1981, 1981. 97 [SLF∗12] Shahwan A., Leon J.-C., Fine L., Foucault G., et al. ´ : Reasoning about functional properties of components based on geometrical descriptions. In Proceedings of the ninth International Symposium on Tools and Methods of Competitive Engineering, Karlsruhe, Germany) (2012), TMCE12. 38, 71, 73, 79, 116, 168, 169 [SLF∗13] Shahwan A., Leon J.-C., Foucault G., Trlin M., Palombi ´ O.: Qualitative behavioral reasoning from components interfaces to components functions for dmu adaption to fe analyses. ComputerAided Design. Vol. 45, Num. 2 (2013), 383–394. 19, 20, 27, 38, 71, 72, 73, 79, 116, 142, 160, 168, 169, 179 [SRX07] Stroud I., Renner G., Xirouchakis P.: A divide and conquer algorithm for medial surface calculation of planar polyhedra. Computer-Aided Design. Vol. 39, Num. 9 (2007), 794–817. 44, 54 [SS14] Shapiro V., Srinivasan V.: Opinion: Report from a 2013 asme panel on geometric interoperability for advanced manufacturing. Comput. Aided Des.. Vol. 47 (fvrier 2014), A1–A2. 196 [SSCO08] Shapira L., Shamir A., Cohen-Or D.: Consistent mesh partitioning and skeletonisation using the shape diameter function. The Visual Computer. Vol. 24, Num. 4 (2008), 249–259. 59 [SSK∗05] Seo J., Song Y., Kim S., Lee K., Choi Y., Chae S.: Wraparound operation for multi-resolution cad model. Computer-Aided Design & Applications. Vol. 2, Num. 1-4 (2005), 67–76. 51 209BIBLIOGRAPHY [SSM∗10] Sheen D.-P., Son T.-g., Myung D.-K., Ryu C., Lee S. H., Lee K., Yeo T. J.: Transformation of a thin-walled solid model into a surface model via solid deflation. Comput. Aided Des.. Vol. 42, Num. 8 (aot 2010), 720–730. 39, 44, 57, 95, 100, 119, 126, 134 [SSR∗07] Sheen D.-P., Son T.-g., Ryu C., Lee S. H., Lee K.: Dimension reduction of solid models by mid-surface generation. International Journal of CAD/CAM. Vol. 7, Num. 1 (2007). 57 [Str10] Stroud I.: Boundary Representation Modelling Techniques, 1st ed. Springer Publishing Company, Incorporated, 2010. 10 [SV93] Shapiro V., Vossler D. L.: Separation for boundary to csg conversion. ACM Trans. Graph.. Vol. 12, Num. 1 (1993), 35–55. 62, 63, 107 [Sza96] Szabo B.: The problem of model selection in numerical simulation. Advances in computational methods for simulation (1996), 9–16. 22 [Tau01] Tautges T. J.: Automatic detail reduction for mesh generation applications. In Proceedings 10th International Meshing Roundtable (2001), pp. 407–418. 35, 51 [TBG09] Thakur A., Banerjee A. G., Gupta S. K.: A survey of {CAD} model simplification techniques for physics-based simulation applications. Computer-Aided Design. Vol. 41, Num. 2 (2009), 65 – 80. 39, 51 [TNRA14] Tierney C. M., Nolan D. C., Robinson T. T., Armstrong C. G.: Managing equivalent representations of design and analysis models. Computer-Aided Design and Applications. Vol. 11, Num. 2 (2014), 193–205. 12 [Tro99] Troussier N.: Contribution to the integration of mechanical calculation in engineering design : methodological proposition for the use and the reuse. PhD thesis, University Joseph Fourier, Grenoble, FRANCE, 1999. 29, 44, 76 [TWKW59] Timoshenko S., Woinowsky-Krieger S., Woinowsky S.: Theory of plates and shells, vol. 2. McGraw-hill New York, 1959. 25, 126 [Ull09] Ullman D. G.: The mechanical design process, vol. Fourth Edition. McGraw-Hill Science/Engineering/Math, 2009. 175 [vdBvdMB03] van den Berg E., van der Meiden H. A., Bronsvoort W. F.: Specification of freeform features. In Proceedings of the Eighth ACM 210BIBLIOGRAPHY Symposium on Solid Modeling and Applications (New York, NY, USA, 2003), SM ’03, ACM, pp. 56–64. 173 [VR93] Vandenbrande J. H., Requicha A. A.: Spatial reasoning for the automatic recognition of machinable features in solid models. Pattern Analysis and Machine Intelligence, IEEE Transactions on. Vol. 15, Num. 12 (1993), 1269–1285. 51 [VSR02] Venkataraman S., Sohoni M., Rajadhyaksha R.: Removal of blends from boundary representation models. In Proceedings of the seventh ACM symposium on Solid modeling and applications (2002), ACM, pp. 83–94. 35, 52, 93 [Woo03] Woo Y.: Fast cell-based decomposition and applications to solid modeling. Computer-Aided Design. Vol. 35, Num. 11 (2003), 969– 977. 51, 61, 94 [Woo14] Woo Y.: Abstraction of mid-surfaces from solid models of thinwalled parts: A divide-and-conquer approach. Computer-Aided Design. Vol. 47 (2014), 1–11. xvi, 44, 61, 62, 89, 94, 119 [WS02] Woo Y., Sakurai H.: Recognition of maximal features by volume decomposition. Computer-Aided Design. Vol. 34, Num. 3 (2002), 195– 207. 51, 61, 94, 100 [ZM02] Zhu H., Menq C.: B-rep model simplification by automatic fillet/round suppressing for efficient automatic feature recognition. Computer-Aided Design. Vol. 34, Num. 2 (2002), 109–123. 35, 52, 93 [ZPK∗02] Zhang Y., Paik J., Koschan A., Abidi M. A., Gorsich D.: Simple and efficient algorithm for part decomposition of 3-d triangulated models based on curvature analysis. In Image Processing. 2002. Proceedings. 2002 International Conference on (2002), vol. 3, IEEE, pp. III–273. 59 [ZT00] Zienkiewicz O. C., Taylor R. L.: The Finite Element Method: Solid Mechanics, vol. 2. Butterworth-heinemann, 2000. 24 211BIBLIOGRAPHY 212Appendix A Illustration of generation processes of CAD components This appendix shows the construction process of two industrial use-cases. The components have been designed in CATIA [CAT14] CAD software. A.1 Construction process of an injected plastic part The followings figures present the complete shape generation process of the use-case as shown in Figure 4.1. The component has been designed with the successive application of 37 modeling features. The used features are: 1. Material addition or removal; 2. Surface operations: fillets, chamfers. Two views, defined as top and bottom view, are associated with the construction tree to present all modeling step of the object shape. A.2 Construction process of an aeronautical metallic part The following figures present a complete shape generation of a simple metallic component which is commonly found in aeronautical structures. The component has been designed using the successive application of boolean operations of type addition and removal. This is a common practice for aeronautical metallic design. This technique shows directly the machining steps in the component design but turn the shape generation process quite complex. The simple example presented in Figure A.6 contains nine main operations which could be reduced to three majors operations ( one extrusion and two hole drillings). IAppendix A: Illustration of CAD component generation Construction Tree TOP view BOTTOM view 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Figure A.1: An example of a shape generation process of an injected plastic part 1/5 IIAppendix A: Illustration of CAD component generation Construction Tree TOP view BOTTOM view 9 10 11 12 13 14 15 16 9 10 11 12 13 14 15 16 Figure A.2: An example of a shape generation process of an injected plastic part 2/5 IIIAppendix A: Illustration of CAD component generation Construction Tree TOP view BOTTOM view 17 18 17 18 19 20 21 22 23 24 19 20 21 22 23 24 Figure A.3: An example of a shape generation process of an injected plastic part 3/5 IVAppendix A: Illustration of CAD component generation Construction Tree TOP view BOTTOM view 25 26 27 28 29 30 31 32 25 26 27 28 29 30 31 32 Figure A.4: An example of a shape generation process of an injected plastic part 4/5 VAppendix A: Illustration of CAD component generation Construction Tree TOP view BOTTOM view 33 34 35 36 37 33 34 35 36 37 Figure A.5: An example of a shape generation process of an injected plastic part 5/5 VIAppendix A: Illustration of CAD component generation Main Solid Solids removed or added with boolean operations Construction Tree 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 Figure A.6: An example of a shape generation process of a simple metallic component. The component has been mainly designed using boolean operations. VIIAppendix A: Illustration of CAD component generation VIIIAppendix B Features equivalence This appendix illustrates the main modeling features used in CAD software to design components (Illustrations courtesy of Dassault Syst`emes [CAT14]) IXAppendix B: Features equivalence Additive extrusion Non perpendicular additive extrusion Removal extrusion Additive revolution Removal revolution Sketch-Based Features Figure B.1: Examples of Sketch-Based Features XAppendix B: Features equivalence Hole Drilling 1 removal extrusion or 1 removal revolution Equivalent to: Hole type: 2 Removal extrusion or 1 removal revolution 1 removal revolution 1 removal revolution 1 removal revolution Additive sweep Removal sweep Stiffener Equivalent to additive extrusion Sketch-Based Features Figure B.2: Examples of Sketch-Based Features XIAppendix B: Features equivalence Fillet Fillet which can be included in extrusion contour Usual fillet Chamfer Equivalent to removal extrusion of can be included in additive extrusion contour Draft angle feature can be equivalent to various additive and removal extrusions Draft angle Simple draft can be included in additive extrusion contour Shell Equivalent to removal extrusion Equivalent to additive extrusion Thickness Dress-Up Features Figure B.3: Examples of Dress-Up Features XIIAppendix B: Features equivalence Boolean operations Difference Union Intersection Figure B.4: Examples of Boolean operations XIIIAppendix B: Features equivalence XIVAppendix C Taxonomy of a primitive morphology This appendix illustrates 18 morphological configurations associated with a MAT medial edge of a volume primitive Pi of type extrusion. The two tables differ according to whether the idealization direction of Pi corresponds to the extrusion direction, see Table C.1, or whether the idealization direction of Pi is included in the extrusion contour, see Table C.2. The reference ratio xr and user ratio xu are used to specify, in each table, the intervals of morphology differentiating beams, plates or shells and 3D thick domains. XVAppendix C: Features equivalence y = L2 / max Ø x = max Ø / L1 y < xu xu < y < xr xr < y xr < x xr < x < xu x < xu L1 < max Ø / xr max Ø < L2 < xu . max Ø max Ø / xr < L1 < max Ø / xu max Ø < L2 < xu . max Ø xu . max Ø < L1 < max Ø max Ø < L2 < xu . max Ø L1 < max Ø / xr xu . max Ø < L2 < xr . max Ø L1 < max Ø / xr xu . max Ø < L2 max Ø / xr < L1 < max Ø / xu xu . max Ø < L2 < xr . max Ø xu . max Ø < L1 < max Ø xu . max Ø < L2 < xr . max Ø max Ø / xr < L1 < max Ø / xu xu . max Ø < L2 xu . max Ø < L1 < max Ø xu . max O < L2 x = max Ø / L1 if max Ø > L1 x = L1 / max Ø if max Ø <= L1 y = L2 / max Ø L1 Ø L2 L1 Ø L2 Ø L2 L1 L1 Ø L2 L1 Ø L2 L1 Ø L2 L1 Ø L2 L1 Ø L2 L1 Ø L2 L1 Ø L2 PLATE THICK PLATE under user hypothesis (in plane Ø ) BEAM under user hypothesis (direction L2) BEAM to PLATE under user hypothesis BEAM to BAND under user hypothesis PLATE (plane orthogonal Ø ) to BEAM (direction L2) BAND under user hypothesis BAND Table C.1: Morphology associated with a MAT medial edge of a primitive Pi. 1/2 XVIAppendix C: Features equivalence L1 > 10 . L2 x < xu xu < x < xr xr < x max Ø < L1 < xu . max Ø max Ø < L2 < xu . max Ø L1 Ø L2 xu . max Ø < L1 < xr . max Ø max Ø < L2 < xu . max Ø L1 Ø L2 xr . max Ø < L1 max Ø < L2 < xu . max Ø L1 L Ø 2 max Ø < L1 < xu . max Ø xu . max Ø < L2 < xr . max Ø max Ø < L1 < xu . max Ø xu . max Ø < L2 xu . max Ø < L1 < xr . max Ø xu . max Ø < L2 < xr . max Ø xr . max Ø < L1 xu . max Ø < L2 < xr . max Ø xu . max Ø < L1 < xr . max Ø xu . max Ø < L2 xr . max Ø < L1 xu . max Ø < L2 L1 Ø L2 L1 Ø L2 L1 Ø L2 L1 > 10 . L2 L1 Ø L2 L1 Ø L2 L2 > 10 . L1 BAND MASSIF BEAM under user hypothesis (direction L1) BEAM (direction L1) BEAM (direction L2) SHELL under user hypothesis (plane L1/L2) SHELL (plan L1/L2) BAND SHELL under user hypothesis (plane L1/L2) BEAM (direction L1) to SHELL under user hypothesis (plane L1/L2) BEAM L1 Ø L2 y = L2 / max Ø x = max Ø / L1 y < xu xu < y < xr xr < y x = max Ø / L1 if max Ø > L1 x = L1 / max Ø if max Ø <= L1 y = L2 / max Ø L1 Ø L2 SHELL under user hypothesis (plane L1/L2) Ø Table C.2: Morphology associated with a MAT medial edge of a primitive Pi. 2/2 XVIIAppendix C: Features equivalence XVIIIAppendix D Export to CAE software This appendix illustrates the data structure used to transfer the adapted DMU to a CAE software, i.e., Abaqus [FEA14]. STEP files [ISO94, ISO03] are used to transfer the geometric model and associated xml files. XIXAppendix D: Export to CAE software BoltedJunction_patch (a) (b) Figure D.1: Illustration of the STEP export of a Bolted Junction with sub-domains around screw. (a) Product structure open in CATIA software, (b) associated xml file containing the association between components and interfaces BoltedJunction_patch Figure D.2: Illustration of the STEP export of a Bolted Junction. Each component containing volume sub-domains is exported as STEP assembly. XXAppendix D: Export to CAE software BoltedJunction_patch Inner Interfaces Figure D.3: Illustration of the STEP export of a Bolted Junction. Each inner interface between sub-domains is part of the component assembly. XXIAppendix D: Export to CAE software BoltedJunction_patch Outer Interfaces Figure D.4: Illustration of the STEP export of a Bolted Junction. Each outer interface between components is part of the root assembly. XXIIAppendix D: Export to CAE software Root Joint Patchs CAD assembly Interfaces Figure D.5: Illustration of the STEP export of the full Root Joint assembly. XXIII Modélisation et d´etection statistiques pour la criminalistique num´erique des images Thanh Hai Thai To cite this version: Thanh Hai Thai. Mod´elisation et d´etection statistiques pour la criminalistique num´erique des images. Statistics. Universit´e de Technologie de Troyes, 2014. French. HAL Id: tel-01072541 https://tel.archives-ouvertes.fr/tel-01072541 Submitted on 8 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.PHD THESIS to obtain the degree of DOCTOR of UNIVERSITY of TECHNOLOGY of TROYES Speciality: Systems Optimization and Dependability presented and defended by Thanh Hai THAI August 28th 2014 Statistical Modeling and Detection for Digital Image Forensics COMMITTEE: Mrs. Jessica FRIDRICH Professor Reviewer M. Patrick BAS Chargé de recherche CNRS Reviewer M. William PUECH Professeur des universités Examinator M. Igor NIKIFOROV Professeur des universités Examinator M. Rémi COGRANNE Maître de conférences Examinator M. Florent RETRAINT Enseignant-Chercheur SupervisorTo my Mom, my Dad, and my little brother, To Thu Thao, my fiancée, for their unlimited support, encouragement, and love.iii Acknowledgments This work has been carried out within the Laboratory of Systems Modeling and Dependability (LM2S) at the University of Technology of Troyes (UTT). It is funded in part by the strategic program COLUMBO. This work has been accomplished under the supervision of M. Florent RETRAINT. I would like to express my deepest gratitude to him for his highly professional guidance and incessant support. He has accompanied with me from my master’s internship and encouraged me to discover this field. I highly value the friendly yet professional environment created during my three-year doctoral. The high confidence he has given to me is possibly the greatest reward of my endeavors. I am greatly indebted to my PhD co-advisor, M. Rémi COGRANNE who has assisted me with high efficiency and availability. It was my honor and pleasure to work with him. His personal and professional help during my doctoral is invaluable. I would like to express my special thanks to Mrs. Jessica FRIDRICH and M. Patrick BAS for accepting to review my PhD thesis. I would also like to thank M. Igor NIKOFOROV and M. William PUECH for agreeing to examine this thesis. Valuable remarks provided by the respectful experts in this field like them would improve the thesis’s quality. I would like to thank the members of LM2S for the friendly and adorable environment which they have offered me since I joint the LM2S team.v Résumé Le XXIème siècle étant le siècle du passage au tout numérique, les médias digitaux jouent maintenant un rôle de plus en plus important dans la vie de tous les jours. De la même manière, les logiciels sophistiqués de retouche d’images se sont démocratisés et permettent aujourd’hui de diffuser facilement des images falsifiées. Ceci pose un problème sociétal puisqu’il s’agit de savoir si ce que l’on voit a été manipulé. Cette thèse s’inscrit dans le cadre de la criminalistique des images numériques. Deux problèmes importants sont abordés : l’identification de l’origine d’une image et la détection d’informations cachées dans une image. Ces travaux s’inscrivent dans le cadre de la théorie de la décision statistique et proposent la construction de dé- tecteurs permettant de respecter une contrainte sur la probabilité de fausse alarme. Afin d’atteindre une performance de détection élevée, il est proposé d’exploiter les propriétés des images naturelles en modélisant les principales étapes de la chaîne d’acquisition d’un appareil photographique. La méthodologie, tout au long de ce manuscrit, consiste à étudier le détecteur optimal donné par le test du rapport de vraisemblance dans le contexte idéal où tous les paramètres du modèle sont connus. Lorsque des paramètres du modèle sont inconnus, ces derniers sont estimés afin de construire le test du rapport de vraisemblance généralisé dont les performances statistiques sont analytiquement établies. De nombreuses expérimentations sur des images simulées et réelles permettent de souligner la pertinence de l’approche proposée. Abstract The twenty-first century witnesses the digital revolution that allows digital media to become ubiquitous. They play a more and more important role in our everyday life. Similarly, sophisticated image editing software has been more accessible, resulting in the fact that falsified images are appearing with a growing frequency and sophistication. The credibility and trustworthiness of digital images have been eroded. To restore the trust to digital images, the field of digital image forensics was born. This thesis is part of the field of digital image forensics. Two important problems are addressed: image origin identification and hidden data detection. These problems are cast into the framework of hypothesis testing theory. The approach proposes to design a statistical test that allows us to guarantee a prescribed false alarm probability. In order to achieve a high detection performance, it is proposed to exploit statistical properties of natural images by modeling the main steps of image processing pipeline of a digital camera. The methodology throughout this manuscript consists of studying an optimal test given by the Likelihood Ratio Test in the ideal context where all model parameters are known in advance. When the model parameters are unknown, a method is proposed for parameter estimation in order to design a Generalized Likelihood Ratio Test whose statistical performances are analytically established. Numerical experiments on simulated and real images highlight the relevance of the proposed approach.Table of Contents 1 General Introduction 1 1.1 General Context and Problem Description . . . . . . . . . . . . . . . 1 1.2 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Publications and Authors’ Contribution . . . . . . . . . . . . . . . . 6 I Overview on Digital Image Forensics and Statistical Image Modeling 9 2 Overview on Digital Image Forensics 11 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Image Processing Pipeline of a Digital Camera . . . . . . . . . . . . 12 2.2.1 RAW Image Formation . . . . . . . . . . . . . . . . . . . . . 13 2.2.2 Post-Acquisition Processing . . . . . . . . . . . . . . . . . . . 15 2.2.3 Image Compression . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Passive Image Origin Identification . . . . . . . . . . . . . . . . . . . 19 2.3.1 Lens Aberration . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.2 Sensor Imperfections . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.3 CFA Pattern and Interpolation . . . . . . . . . . . . . . . . . 25 2.3.4 Image Compression . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 Passive Image Forgery Detection . . . . . . . . . . . . . . . . . . . . 27 2.5 Steganography and Steganalysis in Digital Images . . . . . . . . . . . 29 2.5.1 LSB Replacement Paradigm and Jsteg Algorithm . . . . . . . 32 2.5.2 Steganalysis of LSB Replacement in Spatial Domain . . . . . 33 2.5.3 Steganalysis of Jsteg Algorithm . . . . . . . . . . . . . . . . . 38 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3 Overview on Statistical Modeling of Natural Images 41 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2 Spatial-Domain Image Model . . . . . . . . . . . . . . . . . . . . . . 41 3.2.1 Poisson-Gaussian and Heteroscedastic Noise Model . . . . . . 42 3.2.2 Non-Linear Signal-Dependent Noise Model . . . . . . . . . . . 44 3.3 DCT Coefficient Model . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.1 First-Order Statistics of DCT Coefficients . . . . . . . . . . . 45 3.3.2 Higher-Order Statistics of DCT Coefficients . . . . . . . . . . 46 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46viii Table of Contents II Statistical Modeling and Estimation for Natural Images from RAW Format to JPEG Format 47 4 Statistical Image Modeling and Estimation of Model Parameters 49 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2 Statistical Modeling of RAW Images . . . . . . . . . . . . . . . . . . 50 4.2.1 Heteroscedastic Noise Model . . . . . . . . . . . . . . . . . . . 50 4.2.2 Estimation of Parameters (a, b) in the Heteroscedastic Noise Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.3 Statistical Modeling of TIFF Images . . . . . . . . . . . . . . . . . . 57 4.3.1 Generalized Noise Model . . . . . . . . . . . . . . . . . . . . . 57 4.3.2 Estimation of Parameters (˜a, ˜b) in the Generalized Noise Model 59 4.3.3 Application to Image Denoising . . . . . . . . . . . . . . . . . 61 4.3.4 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . 62 4.4 Statistical Modeling in DCT Domain . . . . . . . . . . . . . . . . . . 65 4.4.1 Statistical Model of Quantized DCT Coefficients . . . . . . . 65 4.4.2 Estimation of Parameters (α, β) from Unquantized DCT Coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4.3 Estimation of Parameters (α, β) from Quantized DCT Coeffi- cients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4.4 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . 71 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 III Camera Model Identification in Hypothesis Testing Framework 75 5 Camera Model Identification Based on the Heteroscedastic Noise Model 77 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.2 Camera Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3 Optimal Detector for Camera Model Identification Problem . . . . . 80 5.3.1 Hypothesis Testing Formulation . . . . . . . . . . . . . . . . . 80 5.3.2 LRT for Two Simple Hypotheses . . . . . . . . . . . . . . . . 80 5.4 GLRT with Unknown Image Parameters . . . . . . . . . . . . . . . . 83 5.5 GLRT with Unknown Image and Camera Parameters . . . . . . . . . 86 5.6 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.6.1 Detection Performance on Simulated Database . . . . . . . . 89 5.6.2 Detection Performance on Two Nikon D70 and Nikon D200 Camera Models . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.6.3 Detection Performance on a Large Image Database . . . . . . 91 5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.8 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Table of Contents ix 5.8.1 Expectation and Variance of the GLR Λhet(z wapp k,i ) under Hypothesis Hj . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.8.2 Expectation and Variance of the GLR Λehet(z wapp k,i ) under Hypothesis Hj . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6 Camera Model Identification Based on the Generalized Noise Model 99 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.2 Camera Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.3 Optimal Detector for Camera Model Identification Problem . . . . . 102 6.3.1 Hypothesis Testing Formulation . . . . . . . . . . . . . . . . . 102 6.3.2 LRT for Two Simple Hypotheses . . . . . . . . . . . . . . . . 103 6.4 Practical Context: GLRT . . . . . . . . . . . . . . . . . . . . . . . . 105 6.4.1 GLRT with Unknown Image Parameters . . . . . . . . . . . . 105 6.4.2 GLRT with Unknown Image and Camera Parameters . . . . . 106 6.5 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.5.1 Detection Performance on Simulated Database . . . . . . . . 108 6.5.2 Detection Performance on Two Nikon D70 and Nikon D200 Camera Models . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.5.3 Detection Performance on a Large Image Database . . . . . . 110 6.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.7 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7 Camera Model Identification Based on DCT Coefficient Statistics115 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2 Camera Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2.1 Design of Camera Fingerprint . . . . . . . . . . . . . . . . . . 116 7.2.2 Extraction of Camera Fingerprint . . . . . . . . . . . . . . . . 117 7.2.3 Property of Camera Fingerprint . . . . . . . . . . . . . . . . . 119 7.3 Optimal Detector for Camera Model Identification Problem . . . . . 120 7.3.1 Hypothesis Testing Formulation . . . . . . . . . . . . . . . . . 120 7.3.2 LRT for Two Simple Hypotheses . . . . . . . . . . . . . . . . 121 7.4 Practical Context: GLRT . . . . . . . . . . . . . . . . . . . . . . . . 123 7.4.1 GLRT with Unknown Parameters αk . . . . . . . . . . . . . . 123 7.4.2 GLRT with Unknown Parameters (αk, c˜k,1, ˜dk,1) . . . . . . . . 124 7.5 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 126 7.5.1 Detection Performance on Simulated Database . . . . . . . . 127 7.5.2 Detection Performance on Two Canon Ixus 70 and Nikon D200 Camera Models . . . . . . . . . . . . . . . . . . . . . . 128 7.5.3 Detection Performance on a Large Image Database . . . . . . 129 7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.7 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.7.1 Relation between the Parameters (˜a, ˜b, γ) and (αu,v, βu,v) . . 132 7.7.2 Laplace’s Approximation of DCT Coefficient Model . . . . . . 133x Table of Contents 7.7.3 Expectation and Variance of the LR Λdct(Ik,i) under Hypothesis Hj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7.7.4 Asymptotic Expectation and Variance of the GLR Λedct(Ik,i) under Hypothesis Hj . . . . . . . . . . . . . . . . . . . . . . . 135 IV Statistical Detection of Hidden Data in Natural Images 137 8 Statistical Detection of Data Embedded in Least Significant Bits of Clipped Images 139 8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 8.2 Cover-Image Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 8.2.1 Non-Clipped Image Model . . . . . . . . . . . . . . . . . . . . 141 8.2.2 Clipped Image Model . . . . . . . . . . . . . . . . . . . . . . 142 8.3 GLRT for Non-Clipped Images . . . . . . . . . . . . . . . . . . . . . 142 8.3.1 Impact of LSB Replacement: Stego-Image Model . . . . . . . 142 8.3.2 Hypothesis Testing Formulation . . . . . . . . . . . . . . . . . 143 8.3.3 ML Estimation of Image Parameters . . . . . . . . . . . . . . 144 8.3.4 Design of GLRT . . . . . . . . . . . . . . . . . . . . . . . . . 145 8.4 GLRT for Clipped Images . . . . . . . . . . . . . . . . . . . . . . . . 148 8.4.1 ML Estimation of Image Parameters . . . . . . . . . . . . . . 148 8.4.2 Design of GLRT . . . . . . . . . . . . . . . . . . . . . . . . . 148 8.5 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 151 8.5.1 Detection Performance on Simulated Database . . . . . . . . 151 8.5.2 Detection Performance on Real Image Database . . . . . . . . 153 8.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.7 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 8.7.1 Denoising Filter for Non-Clipped RAW Images Corrupted by Signal-Dependent Noise . . . . . . . . . . . . . . . . . . . . . 155 8.7.2 Statistical distribution of the GLR Λbncl(Z) under hypothesis H0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 8.7.3 Statistical distribution of the GLR Λbncl(Z) under hypothesis H1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 8.7.4 ML Estimation of Parameters in Truncated Gaussian Data . 159 8.7.5 Statistical distribution of the GLR Λbcl(Z) . . . . . . . . . . . 160 9 Steganalysis of Jsteg Algorithm Based on a Novel Statistical Model of Quantized DCT Coefficients 163 9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.2 Optimal Detector for Steganalysis of Jsteg Algorithm . . . . . . . . . 164 9.2.1 Hypothesis Testing Formulation . . . . . . . . . . . . . . . . . 164 9.2.2 LRT for Two Simple Hypotheses . . . . . . . . . . . . . . . . 165 9.3 Quantitative Steganalysis of Jsteg Algorithm . . . . . . . . . . . . . 168 9.3.1 ML Estimation of Embedding Rate . . . . . . . . . . . . . . . 168Table of Contents xi 9.3.2 Revisiting WS estimator . . . . . . . . . . . . . . . . . . . . . 169 9.4 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 169 9.4.1 Detection Performance of the proposed LRT . . . . . . . . . . 169 9.4.2 Accuracy of the Proposed Estimator . . . . . . . . . . . . . . 172 9.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 10 Conclusions and Perspectives 175 10.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 10.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 10.2.1 Perspectives to Digital Forensics . . . . . . . . . . . . . . . . 178 10.2.2 Perspectives to Statistical Image Modeling . . . . . . . . . . . 180 10.2.3 Perspectives to Statistical Hypothesis Testing Theory Applied for Digital Forensics . . . . . . . . . . . . . . . . . . . . . . . 180 A Statistical Hypothesis Testing Theory 181 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 A.2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 A.3 Test between Two Simple Hypotheses . . . . . . . . . . . . . . . . . . 183 A.4 Test between Two Composite Hypotheses . . . . . . . . . . . . . . . 187 A.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Bibliography 193List of Figures 1.1 Example of falsification. . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Structure of the work presented in this thesis. . . . . . . . . . . . . . 4 2.1 Image processing pipeline of a digital camera. . . . . . . . . . . . . . 13 2.2 Sample color filter arrays. . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 JPEG compression chain. . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Typical steganographic system. . . . . . . . . . . . . . . . . . . . . . 29 2.5 Operations of LSB replacement (top) and Jsteg (bottom). . . . . . . 31 2.6 Diagram of transition probabilities between trace subsets under LSB replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1 Scatter-plot of pixels’ expectation and variance from a natural RAW image with ISO 200 captured by Nikon D70 and Nikon D200 cameras. The image is segmented into homogeneous segments. In each segment, the expectation and variance are calculated and the parameters (a, b) are estimated as proposed in Section 4.2.2. The dash line is drawn using the estimated parameters (a, b). Only the red channel is used in this experiment. . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2 Scatter-plot of pixels’ mean and variance from JPEG images with ISO 200 issued from Nikon D70 and Nikon D200 cameras. The red channel is used in this experiment. The image is segmented into homogeneous segments to estimate local means and variances. The generalized noise model is used to fit to the data. . . . . . . . . . . . 58 4.3 Estimated parameters (˜a, ˜b) on JPEG images issued from different camera models in Dresden image database. . . . . . . . . . . . . . . 63 4.4 Comparison between the proposed method and Farid’s for estimation of gamma factor on JPEG images issued from Nikon D200 camera model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.5 Comparison between the Laplacian, GΓ and proposed model of DCT coefficients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.6 Comparison between the quantized Laplacian, quantized GΓ and proposed model for quantized AC coefficient. . . . . . . . . . . . . . . . 68 4.7 Averaged χ 2 test statistics of GG, GΓ and proposed model for 63 quantized AC coefficients . . . . . . . . . . . . . . . . . . . . . . . . 71 5.1 Estimated camera parameters (a, b) on 20 RAW images of different camera model with ISO 200 and different camera settings. . . . . . . 79 5.2 Estimated camera parameters (a, b) of different devices per camera model with ISO 200 and different camera settings. . . . . . . . . . . 79xiv List of Figures 5.3 The detection performance of the GLRT δ ? het with 50 pixels selected randomly from simulated images. . . . . . . . . . . . . . . . . . . . . 85 5.4 The detection performance of the GLRT δe? het with 50 pixels selected randomly on simulated images. . . . . . . . . . . . . . . . . . . . . . 88 5.5 The detection performance of the test δ ? het with 200 pixels selected randomly on simulated images for a0 = 0.0115 and different parameters a1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.6 The detection performance of the test δ ? het and δe? het on simulated images for different numbers of pixels. . . . . . . . . . . . . . . . . . 89 5.7 The detection performance of the GLRTs δ ? het and δe? het on the Dresden database for different numbers of pixels. . . . . . . . . . . . . . . . . 91 5.8 Comparison between the theoretical false alarm probability (FAP) and the empirical FAP, from real images of Dresden database, plotted as a function of decision threshold τ . . . . . . . . . . . . . . . . . . . 92 6.1 Empirical distribution of noise residuals z˜ res k,i in a segment compared with theoretical Gaussian distribution. . . . . . . . . . . . . . . . . . 101 6.2 Estimated parameters (˜a, ˜b) on JPEG images issued from Canon Ixus 70 camera with different camera settings. . . . . . . . . . . . . . . . 102 6.3 Estimated parameters (˜a, ˜b) on JPEG images issued from different devices of Canon Ixus 70 model. . . . . . . . . . . . . . . . . . . . . 103 6.4 Detection performance of the proposed tests for 50 and 100 pixels extracted randomly from simulated JPEG images with quality factor 100. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.5 Detection performance of the GLRT δe? gen for 100 pixels extracted randomly from simulated JPEG images with different quality factors. 109 6.6 Detection performance of the GLRT δ ? gen and δe? gen for 50 and 100 pixels extracted randomly from JPEG images of Nikon D70 and Nikon D200 cameras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.7 Comparison between the theoretical false alarm probability (FAP) and the empirical FAP, plotted as a function of decision threshold τ . 111 7.1 Estimated parameters (α, β) at frequency (0, 1) and (8, 8) of uniform images generated using a˜ = 0.1, ˜b = 2, γ = 2.2. . . . . . . . . . . . . 117 7.2 Estimated parameters (α, β) at frequency (8, 8) of natural JPEG images issued from Canon Ixus 70 and Nikon D200 camera models. . . 119 7.3 Estimated parameters (˜c, ˜d) at frequency (8, 8) of natural JPEG images issued from different camera models in Dresden database. . . . . 120 7.4 Detection performance of proposed tests on simulated vectors with 1024 coefficients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.5 Detection performance of proposed tests on simulated vectors with 4096 coefficients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125List of Figures xv 7.6 Detection performance of proposed GLRTs for 1024 coefficients at frequency (8, 8) extracted randomly from simulated images with different quality factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 7.7 Detection performance of proposed tests for different number of coefficients at frequency (8, 8) of natural JPEG images taken by Canon Ixus 70 and Nikon D200 camera models. . . . . . . . . . . . . . . . 127 7.8 Detection performance of the GLRT δe? dct for 4096 coefficients at different frequencies of natural JPEG images taken by Canon Ixus 70 and Nikon D200 camera models. . . . . . . . . . . . . . . . . . . . . 128 7.9 Comparison between the theoretical false alarm probability (FAP) and the empirical FAP, plotted as a function of decision threshold τ , of the proposed tests at the frequency (8,8) of natural images. . . . . 129 8.1 Detection performance on non-clipped simulated images for embedding rate R = 0.05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 8.2 Detection performance on clipped simulated images for embedding rate R = 0.05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.3 Detection performance on real clipped images for embedding rate R = 0.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 8.4 Detection performance on real clipped images for embedding rate R = 0.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 8.5 Detection performance on real clipped images for embedding rate R = 0.6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 8.6 Detection performance on 12-bit images taken by Canon 400D with ISO 100 from BOSS database for embedding rate R = 0.05. . . . . . 153 8.7 Detection performance on 5000 images from BOSS database for embedding rate R = 0.05. . . . . . . . . . . . . . . . . . . . . . . . . . . 153 8.8 Empirical false-alarm probability from real images of BOSS database plotted as a function of decision threshold, compared with theoretical FAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 9.1 Detection performance of the test δ ? jst based on the proposed model with embedding rate R = 0.05 on the simulated images and real images.167 9.2 Detection performance of the test δ ? jst based on the quantized Laplacian, quantized GG, quantized GΓ, and proposed model on the BOSSBase with embedding rate R = 0.05. . . . . . . . . . . . . . . . . . . 170 9.3 Detection performance of the test δ ? jst based on the quantized Laplacian, quantized GG, quantized GΓ, and proposed model on the subset of 1000 images from the BOSSBase with embedding rate R = 0.05. . 171 9.4 Comparison between the proposed test δ ? jst, ZMH-Sym detector, ZP detector, WS detector and quantized Laplacian-based test. . . . . . . 172 9.5 Mean absolute error for all estimators. . . . . . . . . . . . . . . . . . 172 9.6 Mean absolute error for proposed ML estimator, standard WS estimator and improved WS estimator. . . . . . . . . . . . . . . . . . . . 173xvi List of Figures 9.7 Comparison between the proposed test δ ? jst, standard WS detector and improved WS detector. . . . . . . . . . . . . . . . . . . . . . . . 174List of Tables 4.1 Parameter estimation on synthetic images . . . . . . . . . . . . . . . 63 4.2 PSNR of the extended LLMMSE filter . . . . . . . . . . . . . . . . . 64 4.3 χ 2 test statistics of Laplacian, GG, GΓ, and proposed model for the first 9 quantized coefficients of 3 testing standard images. . . . . . . 71 5.1 Camera Model Used in Experiments (the symbol * indicates our own camera) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2 Detection performance of the proposed detector. . . . . . . . . . . . 93 5.3 Detection performance of PRNU-based detector for ISO 200. . . . . 93 6.1 Camera Model Used in Experiments . . . . . . . . . . . . . . . . . . 112 6.2 Performance of proposed detector . . . . . . . . . . . . . . . . . . . . 112 6.3 Performance of SVM-based detector (the symbol * represents values smaller than 2%) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.4 Performance of PRNU-based detector . . . . . . . . . . . . . . . . . 113 7.1 Camera Model Used in Experiments . . . . . . . . . . . . . . . . . . 129 7.2 Detection performance of proposed detector δe? dct (the symbol * represents values smaller than 2%) . . . . . . . . . . . . . . . . . . . . . 130 7.3 Detection performance of SVM-based detector . . . . . . . . . . . . 130 7.4 Detection performance of PRNU-based detector . . . . . . . . . . . 131 7.5 Detection performance of proposed detector δ ? dct . . . . . . . . . . . 131 7.6 Detection performance of proposed detector δe? dct on 4 camera models of BOSS database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 10.1 List of proposed statistical tests. . . . . . . . . . . . . . . . . . . . . 177List of Abbreviations Acronym What (it) Stands For AC Alternating Current. AUMP Asymptotically Uniformly Most Powerful. AWGN Additive White Gaussian Noise. cdf cumulative distribution function. CCD Charge-Coupled Device. CFA Color Filter Array. CLT Central Limit Theorem. CMOS Complementary Metal-Oxide Semiconductor. CRF Camera Response Function. DC Direct Current. DCT Discrete Cosine Transform. DSC Digital Still Camera. DSLR Digital Single Lens Reflex. EXIF Exchangeable Image File. GG Generalized Gaussian. GLR Generalized Likelihood Ratio. GLRT Generalized Likelihood Ratio Test. GOF goodness-of-fit. GΓ Generalized Gamma. IDCT Inverse Discrete Cosine Transform. i.i.d independent and identically distributed. JPEG Join Photographic Expert Group. KS Kolmogorov-Smirnov. LSB Least Significant Bit. LR Likelihood Ratio. LRT Likelihood Ratio Test. LS Least Squares. mAE Median Absolute Error. MAE Mean Absolute Error. MGF Moment-Generating Function ML Maximum Likelihood. MM Method of Moments. MP Most Powerful. MSE Mean Squared Error. NP Neyman-Pearson. PCE Peak to Correlation Energy. pdf probability density function. PRNU Photo-Response Non-Uniformity. RLE Run-Length Encoding.xx List of Tables ROC Receiver Operating Characteristic. R/T Rounding and Truncation. SPA Sample Pair Analysis. SPN Sensor Pattern Noise. SVM Support Vector Machine. TIFF Tagged Image File Format. UMP Uniformly Most Powerful. WLS Weighted Least Squares. WS Weighted Stego-image. ZMH Zero Message Hypothesis. ZP Zhang and Ping.Glossary of Notations Notation Definition α0 False alarm probability. β(δ) Power of the test δ. χ 2 K Chi square distribution with K degree of freedom. γ Gamma factor. δ Statistical test. η Noise. κ Quantization step in the spatial domain. µ Expectation. ν Bit-depth. σ Standard deviation. τ Decision threshold. ξ Number of collected electrons, which is modeled by Poisson distribution. ϕ 2-D normalized wavelet scaling function. φ Probability density function of a standard Gaussian random variable. ∆ Quantization step in the DCT domain. Λ Likelihood Ratio. Φ Cumulative distribution function of a standard Gaussian random variable. Θ Parameter space. Cov Covariance. E Mathematical expectation. P[E] Probability that an event E occurs. R Set of real numbers. Var Variance. Z Set of integer numbers. B(n, p) Binomial distribution where n is the number of experiments and p is the success probability of each experiment. D Denoising filter. G(α, β) Gamma distribution with shape parameter α and scale parameter β. H0, H1 Null hypothesis and alternative hypothesis. I Set of pixel indices. Kα0 Class of tests whose false alarm probability is upper-bounded by α0. L Log-likelihood function. N (µ, σ2 ) Gaussian distribution with mean µ and variance σ 2 .xxii List of Tables P(λ) Poisson distribution with mean λ and variance λ. Q∆ Quantization with step ∆. S Source of digital images. U[a, b] Uniform distribution on the interval [a, b]. Z Set of possible pixel values. Z N Image space. C Cover-image that is used for data hiding. D Quantized DCT coefficients. F Fisher information. HDM Linear filter for demosaicing. I Unquantized DCT coefficients. Idn Identity matrix of size n × n. K PRNU. M Secret message to be embedded. PCFA CFA pattern. S Stego-image that contains hidden data. Z Natural image. (a, b) Parameters of heteroscedastic noise model. (˜a, ˜b) Parameters of generalized noise model. c Color channel. (˜c, ˜d) Parameters characterizing the relation between α and β, which are the parameters of DCT coefficient model. fCRF Camera response function. fX(x) Probability density function of a random variable X. gWB Gain for white-balancing. pX(x) Probability mass function of a random variable X. r Change rate, r = R 2 . B Boundary of the dynamic range, B = 2ν − 1. L Secret message length. N Number of pixels in the image Z, N = Nr × Nc if Z is a grayscale image and N = Nr × Nc × 3 if Z is a full-color image. Nblk Number of blocks. Nc Number of columns. Nr Number of rows. Ns Number of sources. Pθ Probability distribution characterized by a parameter vector θ. QR,θ Probability distribution after embedding at rate R. R Embedding rate.Chapter 1 General Introduction 1.1 General Context and Problem Description Traditionally, images are considered as trustworthy since as they are known as being captured through analog acquisition devices to depict the real-world happenings. This traditional trustworthiness is built on remarkable difficulties of image content modification. Indeed, modifying the content of a film-based photo requires special skills, yet time-consuming and costly, through dark room tricks. Therefore, this modification is of limited extent. In the past decades, we have witnessed the evolution of digital imaging technology with a dramatic improvement of digital images’ quality. This improvement is not only due to advances in semiconductor fabrication technology that makes it possible to reduce the pixel size in an image sensor and thus raises the total number of pixels, but also advances in image processing technology that allows to reduce noise introduced in a camera and enhance details of the physical scene. The digital revolution largely replace their analog counterparts to enable ease of digital content creation and processing at affordable cost and in mass scale. Nowadays, digital still cameras (DSCs) are taking over a major segment of the consumer photography marketplace. Only at the very high end (large format, professional cameras with interchangeable and highly adjustable lenses) and very low end (inexpensive automated snapshot cameras) are traditional film cameras holding their own. Besides, the development of communication and networking infrastructure allows digital content to be more accessible. One of the greatest advantage of digital images acquired by DSCs is the ease of transmission over communication networks, which film cameras are difficult to enable. Unfortunately, this path of technological evolution may provide means for malicious purposes. Digital images can be easily edited, altered or falsified because of a large availability of low-cost image editing tools. Consequently, falsified photographs are appearing with a growing frequency and sophistication. The credibility and trustworthiness of digital images have been eroded. This is more crucial when falsified images that were utilized as evidence in a courtroom could mislead the judgement and lead to either imprisonment for the innocent or freedom for the guilty. In general, the falsification of digital images may result in important consequences in terms of political, economic, and social issues. One example of falsification that causes political issues is given in Figure 1.1. In the left corner image, President G.W. Bush and a young child are both reading from America: A Patriotic Primer by Lynne Cheney. But if we look closely, it2 Chapter 1. General Introduction (a) Forged image. (b) Original image. Figure 1.1: Example of falsification. appears that President Bush is holding his book upside down. An unknown hoaxer has horizontally and vertically flipped the image on the back of the book in Bush’s hands. This photo of George Bush holding a picture book the wrong way up during a visit to a school delighted some opponents of the Republican president, and helped foster his buffoonish image. But press photos from the event in 2002 revealed that Mr Bush had been holding the book correctly, i.e. hoaxers had simply used photo editing software to rotate the cover. The original version of the photo (right corner) was taken in the Summer of 2002 while Bush was visiting George Sanchez Charter School in Houston. It was distributed by the Associated Press. By comparing the forged photo and original photo, it can be noted that a dark blue spot is close to the spine of Bush’s book, but this same spot in the girl’s copy is near the left-hand edge of the book. This forensic clue can be considered as evidence of forgery. However in most of the cases, the forgery is not as easy to detect. The human eyes can hardly differentiate a genuine scene from a deliberately forged scene. Overall, the digital revolution has raised a number of information security challenges. To restore the trust to digital images, the field of digital image forensics was born. Because of importance of information security in many domains, digital image forensics has attracted a great attention from academic researchers, law enforcement, security, and intelligence agencies. Conducting forensic analysis is a difficult mission since forensic analysts need to answer several questions before stating that digital content is authentic: 1. What is the true origin of this content? How was it generated? By whom was it taken? 2. Is the image still depicting the captured original scene? Has its content been altered in some way? How has it been processed? The first question involves the problem of image origin identification. Source information of digital images represents useful forensic clues because knowing the1.2. Outline of the Thesis 3 source device that captures the inspected image can facilitate verification or tracing of device owner as well as the camera taker. This situation is as identical as bullet scratches allowing forensic analysts to match a bullet to a particular barrel or gun and trace the gun owner.1 Besides, knowing device model or brand information can help forensic analysts know more about characteristics of acquisition devices, which leads to a potential improvement of detecting the underlying forgeries that could be performed in the inspected image. Another issue is to determine what imaging mechanism has been used to generate the inspected image (e.g. scanners, cell-phone cameras, or computer graphics) before assuming that the inspected image is taken by a digital camera, which can significantly narrow down the search range for the next step of the investigation. The second problem is image content integrity. An image has to be proven authentic and its content has not be forged before it can be used as forensic clues or as evidence in a legal context. Determining whether an image is forged, which manipulation has been performed on the image, or which region of the image has been altered are fundamental tasks. Beside some basic manipulations such as adding, splicing, and removal, the image can be also manipulated by embedding a message into image content directly. The message remains secret such that it is only known by the sender and receiver and an adversary does not recognize its existence visually. This concept is called steganography, which is a discipline of the field of information hiding. However, the concept of steganography has been misused for illegal activities. Detecting existence of secret messages and revealing their content are also the tasks of forensic analysts. This task is called steganalysis. The field of digital image forensics, including steganalysis, is part of an effort to counter cyber-attacks, which is nowadays one of strategy priorities for defence and national security in most countries. 1.2 Outline of the Thesis The main goal of this thesis is to address information security challenges in the field of digital image forensics. In particular, the problems of image origin identification and hidden data detection are studied. The thesis is structured in four main parts. Apart from the first part providing an overview on the field of digital image forensics and statistical image modeling, the rest of the thesis involves many contributions. All the work presented in this thesis is illustrated in Figure 1.2. Part II establishes a profound statistical modeling of natural images by analyzing the image processing pipeline of a digital camera, as well as proposes efficient algorithms for estimation of model parameters from a single image. Typically, the image processing pipeline is composed of three main stages: RAW image acquisition, 1Evidently, tracing an imaging device owner is more difficult as average users have rights to buy a camera easily in a market with millions of cameras while the use of guns is banned or controlled in many countries and a gun user has to register his identities.4 Chapter 1. General Introduction Figure 1.2: Structure of the work presented in this thesis. post-acquisition enhancement, and JPEG compression that employs Discrete Cosine Transform (DCT). Therefore, the statistical image modeling in Part II is performed both in the spatial domain and the DCT domain. By modeling the photo-counting and read-out processes, a RAW image can be accurately characterized by the heteroscedastic noise model in which the RAW pixel is normally distributed and its variance is linearly dependent on its expectation. This model is more relevant than the Additive White Gaussian Noise (AWGN) model widely used in image processing since the latter ignores the contribution of Poisson noise in the RAW image acquisition stage. The RAW image then undergoes post-acquisition processes in order to provide a high-quality full-color image, referred to as TIFF image. Therefore, to study image statistics in a TIFF image, it is proposed to start from the heteroscedastic noise model and take into account non-linear effect of gamma correction, resulting in a generalized noise model. This latter involves a non-linear relation between pixel’s expectation and variance. This generalized noise model has not been proposed yet in the literature. Overall, the study of noise statistics in the spatial domain indicates the non-stationarity of noise in a natural image, i.e. pixel’s variance is dependent on the expectation rather than being constant in the whole image. Besides, pixels’ expectations, namely the image content, are also heterogeneous. Apart from studying image statistics in the spatial domain, it is proposed to study DCT coefficient statistics. Modeling the distribution of DCT coefficients is not a trivial task due to heterogeneity in the natural image and complexity of image statistics. It is worth noting that most of existing models of DCT coefficients, which are only verified by conducting the goodness-of-fit test with empirical data, are given without a mathematical justification. Instead, this thesis provides a mathematical framework of modeling the statistical distribution of DCT coefficients by relying on the double stochastic model that combines the statistics of DCT coefficients in a block whose variance is constant with the variability of block variance in a natural image. The proposed model of DCT coefficients outperforms the others including the Laplacian, Generalized Gaussian, and Generalized Gamma model. Numerical1.2. Outline of the Thesis 5 results on simulated database and real image database highlight the relevance of the proposed models and the accuracy of the proposed estimation algorithms. The solid foundation established in Part II emphasizes several aspects of interest for application in digital image forensics. Relying on a more relevant image model and an accurate estimation of model parameters, the detector is expected to achieve better detection performance. Part III addresses the problem of image origin identification within the framework of hypothesis testing theory. More particularly, it involves designing a statistical test for camera model identification based on a parametric image model to meet the optimality bi-criteria: the warranting of a prescribed false alarm probability and the maximization of the correct detection probability. Camera model identification based on the heteroscedastic noise model, generalized noise model, and DCT coefficients is respectively presented in Chapter 5, Chapter 6, and Chapter 7. The model parameters are proposed to be exploited as unique fingerprint for camera model identification. In general, the procedure in those chapters is similar. The procedure starts from formally stating the problem of camera model identification into hypothesis testing framework. According to Neyman-Pearson lemma, the most powerful test for the decision problem is given by the Likelihood Ratio Test (LRT). The statistical performance of the LRT can be analytically established. Moreover, the LRT can meet the two required criteria of optimality. However, this test is only of theoretical interest because it is based on an assumption that all model parameters are known in advance. This assumption is hardly met in practice. To deal with the difficulty of unknown parameters, a Generalized Likelihood Ratio Test (GLRT) is proposed. The GLRT is designed by replacing unknown parameters by their Maximum Likelihood (ML) estimates in the Likelihood Ratio. Consequently, the detection performance of the GLRT strongly depends on the accuracy of employed image model and parameter estimation. It is shown in Chapter 5, 6, and 7 that the proposed GLRTs can warrant a prescribed false alarm probability while ensuring a high detection performance. Moreover, the efficiency of the proposed GLRTs is highlighted when applying on a large image database. The problem of hidden data detection is addressed in Part IV. This problem is also formulated into hypothesis testing framework. The main idea is to rely on an accurate image model to detect small changes in statistical properties of a cover image due to message embedding. The formulation in the hypothesis testing framework allows us to design a test that can meet two above criteria of optimality. Chapter 8 addresses the steganalysis of Least Significant Bit (LSB) replacement technique in RAW images. More especially, the phenomenon of clipping is studied and taken into account in the design of the statistical test. This phenomenon is due to to limited dynamic range of the imaging system. The impact of the clipping phenomenon on the detection performance of steganalysis methods has not been studied yet in the literature. The approach proposed in Chapter 8 is based on the heteroscedastic noise model instead of the AWGN model. Besides, the approach proposes to exploit the state-of-the-art denoising method to improve the estimation of pixels’ expectation and variance. The detection performance of the proposed6 Chapter 1. General Introduction GLRTs on non-clipped images and clipped images is studied. It is shown that the proposed GLRTs can warrant a prescribed false alarm probability and achieve a high detection performance while other detectors fail in practice, especially the Asymptotically Uniformly Most Powerful (AUMP) test. Next, Chapter 9 addresses the steganalysis of Jsteg algorithm. It should be noted that Jsteg algorithm is a variant of LSB replacement technique. Instead of embedding message bits in the spatial domain, Jsteg algorithm utilizes the LSB of quantized DCT coefficients and embeds message bits in the DCT domain. The goal of Chapter 9 is to exploit the state-of-the-art model of quantized DCT coefficients in Chapter 4 to design a LRT for the steganalysis of Jsteg algorithm. For the practical use, unknown parameters of the DCT coefficient model are replaced by their ML estimates in the Likelihood Ratio. Experiments on simulated database and real image database show a very small loss of power of the proposed test. Furthermore, the proposed test outperforms other existing detectors. Another contributions in Chapter 9 are that a Maximum Likelihood estimator for embedding rate is proposed using the proposed model of DCT coefficients as well as the improvement of the existing Weighted Stego-image estimator by modifying the technique of calculation of weights. 1.3 Publications and Authors’ Contribution Most of the material presented in this thesis appears in the following publications that represent original work, of which the author has been the main contributor. Patents 1. T. H. Thai, R. Cogranne, and F. Retraint, "Système d’identification d’un modèle d’appareil photographique associé à une image compressée au format JPEG, procédé, utilisations and applications associés", PS/B52545/FR, 2014. 2. T. H. Thai, R. Cogranne, and F. Retraint, "Système d’identification d’un modèle d’appareil photographique associé à une image compressée au format JPEG, procédé, utilisations and applications associés", PS/B52546/FR, 2014. Journal articles 1. T. H. Thai, R. Cogranne, and F. Retraint, "Camera model identification based on the heteroscedastic noise model", IEEE Transactions on Image Processing, vol. 23, no. 1, pp. 250-263, Jan. 2014. 2. T. H. Thai, F. Retraint, and R. Cogranne, "Statistical detection of data hidden in least significant bits of clipped images", Elsevier Signal Processing, vol. 98, pp. 263-274, May 2014. 3. T. H. Thai, R. Cogranne, and F. Retraint, "Statistical model of quantized DCT coefficients: application in the steganalysis of Jsteg algorithm", IEEE Transactions on Image Processing, vol. 23, no. 5, pp. 1980-1993, May 2014.1.3. Publications and Authors’ Contribution 7 Journal articles under review 1. T. H. Thai, F. Retraint, and R. Cogranne, "Generalized signal-dependent noise model and parameter estimation for natural images", 2014. 2. T. H. Thai, F. Retraint, and R. Cogranne, "Camera model identification based on the generalized noise model in natural images", 2014. 3. T. H. Thai, R. Cogranne, and F. Retraint, "Camera model identification based on DCT coefficient statistics", 2014. Conference papers 1. T. H. Thai, F. Retraint, and R. Cogranne, "Statistical model of natural images", in IEEE International Conference on Image Processing, pp. 2525- 2528, Sep. 2012. 2. T. H. Thai, R. Cogranne, and F. Retraint, "Camera model identification based on hypothesis testing theory", in European Signal Processing Conference, pp. 1747-1751, Aug. 2012. 3. T. H. Thai, R. Cogranne, and F. Retraint, "Steganalysis of Jsteg algorithm based on a novel statistical model of quantized DCT coefficients", in IEEE International Conference on Image Processing, pp. 4427-4431, Sep. 2013. 4. R. Cogranne, T. H. Thai, and F. Retraint, "Asymptotically optimal detection of LSB matching data hiding", in IEEE International Conference on Image Processing, pp. 4437-4441, Sep. 2013. 5. T. H. Thai, R. Cogranne, and F. Retraint, "Optimal detector for camera model identification based on an accurate model of DCT coefficient", in IEEE International Workshop on Multimedia Signal Processing (in press), Sep. 2014. 6. T. H. Thai, R. Cogranne, and F. Retraint, "Optimal detection of OutGuess using an accurate model of DCT coefficients", in IEEE International Workshop on Information Forensics and Security (in press), Dec. 2014.Part I Overview on Digital Image Forensics and Statistical Image ModelingChapter 2 Overview on Digital Image Forensics Contents 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Image Processing Pipeline of a Digital Camera . . . . . . . 12 2.2.1 RAW Image Formation . . . . . . . . . . . . . . . . . . . . . 13 2.2.2 Post-Acquisition Processing . . . . . . . . . . . . . . . . . . . 15 2.2.3 Image Compression . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Passive Image Origin Identification . . . . . . . . . . . . . . . 19 2.3.1 Lens Aberration . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.2 Sensor Imperfections . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.3 CFA Pattern and Interpolation . . . . . . . . . . . . . . . . . 25 2.3.4 Image Compression . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 Passive Image Forgery Detection . . . . . . . . . . . . . . . . 27 2.5 Steganography and Steganalysis in Digital Images . . . . . 29 2.5.1 LSB Replacement Paradigm and Jsteg Algorithm . . . . . . . 32 2.5.2 Steganalysis of LSB Replacement in Spatial Domain . . . . . 33 2.5.2.1 Structural Detectors . . . . . . . . . . . . . . . . . . 33 2.5.2.2 WS Detectors . . . . . . . . . . . . . . . . . . . . . 35 2.5.2.3 Statistical Detectors . . . . . . . . . . . . . . . . . . 36 2.5.2.4 Universal Classifiers . . . . . . . . . . . . . . . . . . 37 2.5.3 Steganalysis of Jsteg Algorithm . . . . . . . . . . . . . . . . . 38 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.1 Introduction The goal of this chapter is to provide an overview on the field of digital image forensics. As described in Section 1.1, digital image forensics involve two key problems: image origin identification and image forgery detection. In general, there are two approaches to address these problems. Active forensics aims to authenticate image content by generating extrinsically security measures such as digital watermarks [1–6] and digital signatures [7–10] and adding them to the image file. These12 Chapter 2. Overview on Digital Image Forensics security measures are referred to as extrinsic fingerprints. Although active forensics can provide powerful tools to secure a digital camera and restore the credibility of digital images, it is of limited extent due to many strict constraints in its protocols. In order to solve these problems in their entirety, passive forensics has been quickly evolved. In contrast to active forensics, passive forensics does not impose any constraint and do not require any prior information including the original reference image. Forensic analysts have only the suspect image at their disposal and must explore useful information from the image to gather forensic evidence, trace the acquisition device and detect any act of manipulation. Passive forensics works on an assumption that the image contains some internal traces left from the camera. Every stage from real-world scene acquisition to image storage can provide clues for forensic analysis. These internal traces are called intrinsic fingerprints. Extrinsic and intrinsic fingerprints are two forms of digital fingerprints in digital forensics, which are analogous to human fingerprints in criminal domain. Since passive forensics does not require neither any external security measures generated in the digital camera, nor any prior information, it can authenticate an image in a blind manner and can widely be applied to millions of images that circulate daily on communication networks. This thesis mainly addresses the problem of origin identification and integrity based on passive approach. The chapter is organized as follows. Before discussing active and passive forensics, it is vital to understand deeply the creation and characteristics of digital images. Section 2.2 briefly introduces the typical image processing pipeline of a digital camera, highlighting several aspects of potential interest for applications in digital image forensics. Section 2.3 analyzes passive methods proposed for image origin identification. Section 2.4 briefly discusses passive methods for image forgery detection. Next, Section 2.5 introduces the concept of steganography, which is a type of image content manipulation, and presents prior-art methods for detecting secret data embedded in digital images. Finally, Section 2.6 concludes the chapter. 2.2 Image Processing Pipeline of a Digital Camera This thesis only deals with DSCs and digital images acquired by them. By terminology, a natural image means a digital image acquired by a DSC. Other sources of digitized images such as scanners are not addressed in this thesis but a similar methodology can be easily derived. Image processing pipeline involves several steps from light capturing to image storage performed in a digital camera [11]. After measuring light intensity at each pixel, RAW image that contains exactly information recorded by the image sensor goes through some typical post-acquisition processes, e.g. demosaicing, whitebalancing and gamma correction, to render a full-color high-quality image, referred to as TIFF image. Image compression can be also performed for ease of storage and transmission. The image processing pipeline of a digital camera is shown in2.2. Image Processing Pipeline of a Digital Camera 13 Figure 2.1: Image processing pipeline of a digital camera. Figure 2.1. It should be noted that the sequence of operations differs from manufacturer to manufacturer but basic operations remain similar. In general, the image processing pipeline designed in a digital camera is complex, with trade-offs in the use of buffer memory, computing operations, image quality and flexibility [12]. This section only discusses some common image processing operations such as demosaicing, white balancing, gamma correction and image compression. Other processing operations, e.g. camera noise reduction and edge enhancement, are not included in this discussion. A full-color digital image consists of three primary color components: red, green, and blue. These three color components are sufficient to represent millions of colors. Formally, the full-color image of a DSC can be represented as a three-dimensional matrix of size Nr × Nc × 3 where Nr and Nc are respectively the number of rows and columns. Let c ∈ {R, G, B} denote a color channel where R, G and B stand for respectively the red, green and blue color. Typically, the output image is coded with ν bits and each pixel value is a natural integer. The set of possible pixel values is denoted by Z = {0, 1, . . . , B} with B = 2ν − 1. Therefore, an arbitrary image belongs to the finite image space Z N with N = Nr × Nc × 3. In general, the image space Z N is high dimensional because of a large number of pixels. To facilitate discussions, let Z denote an image in RAW format and Ze denote an image in TIFF or JPEG format. Each color component of the image Z is denoted by Z c and a pixel of the color channel c at the location (m, n) is denoted by z c (m, n), 1 ≤ m ≤ Nr, 1 ≤ n ≤ Nc. 2.2.1 RAW Image Formation Typically, a digital camera includes an optical sub-system (e.g. lenses), an image sensor and an electronic sub-system, which can be regarded as the eye, retina, and brain in the human visual system. The optical sub-system allows to attenuate effects of infrared rays and to provide an initial optic image. The image sensor consists of a two-dimensional arrays of photodiodes (or pixels) fabricated on a silicon14 Chapter 2. Overview on Digital Image Forensics Figure 2.2: Sample color filter arrays. wafer. Two common types of an image sensor are Charge-Coupled Device (CCD) and Complementary Metal-Oxide Semiconductor (CMOS). Each pixel enables to convert light energy to electrical energy. The output signals of the image sensor are analog. These signals are then converted to digital signals by an analog-to-digital (A/D) converter inside the camera. The RAW image is obtained at this stage. Depending on the analog-to-digital circuit of the camera, the RAW image is recorded with 12, 14 or even 16 bits. One key advantage is that the RAW image exactly contains information recorded by the image sensor and it has not yet undergone post-acquisition operations. This offers more flexibility for further adjustments. Although the image sensor is sensitive to light intensity, it does not differentiate light wavelength. Therefore, to record a color image, a Color Filter Array (CFA) is overlaid on the image sensor. Each pixel records a limited range of wavelength, corresponding to either red, green or blue. Some examples of CFA patterns are shown in Figure 2.2. Among available CFA patterns, the Bayer pattern is the most popular. It contains twice as many green as red or blue samples because the human eye is more sensitive to green light than both red or blue light. The higher rate of sampling for the green component enables to better capture the luminance component of light and, thus, provides better image quality. There are few digital cameras that allow to acquire a full-resolution information for all three color components (e.g. Sigma SD9 or Polaroid x530 ). This is not only due to high production cost but also due to the requirement of a perfect alignment of three color planes together. Let Z represent the RAW image recorded by the image sensor. Because of the CFA sampling, the RAW image Z is a single-channel image, namely that it is represented as a two-dimensional matrix of size Nr × Nc. Each pixel value of the RAW image Z corresponds to only one color channel. For subsequent processing operations, each color component is extracted from the RAW image Z. A pixel of each color component is given by z c (m, n) = ( z(m, n) if PCFA(m, n) = c 0 otherwise, (2.1) where PCFA is the CFA pattern. The RAW image acquisition stage is not ideal due to the degradation introduced by several noise sources. This stage involves two predominant random noise sources. The first is the Poisson-distributed noise associated with the stochastic nature of the photo-counting process (namely shot noise) and dark current generated by the thermal energy in the absence of light. Dark current is also referred to as Fixed Pattern Noise (FPN). While shot noise results from the quantum nature of light and it can not be eliminated, dark current can be subtracted from the image [13].2.2. Image Processing Pipeline of a Digital Camera 15 The second random noise sources account for all remaining electronic noises involved in the acquisition chain, e.g. read-out noise, which can be modeled by a Gaussian distribution with zero-mean. Apart from random noises, there is also a multiplicative noise associated with the sensor pattern. This noise accounts for differences of pixels response to the incident light due to imperfections during the manufacturing process and inhomogeneity of silicon wafers. Therefore, this noise is referred to as PhotoResponse Non-Uniformity (PRNU). The PRNU, which is typically small compared with the signal, is a deterministic component that is present in every image. FPN and PRNU are two main components of Sensor Pattern Noise (SPN). The PRNU is unique for each sensor, thus it can be further used for forensic analysis. 2.2.2 Post-Acquisition Processing Although the use of the CFA allows to reduce the cost of the camera, this requires to estimate the missing color values at each pixel location in order to render a full-color image. It means that all the zero values in the sub-images need to be interpolated. This estimation process is commonly referred to as CFA demosaicing or CFA interpolation [14]. Technically, demosaicing algorithms estimate a missing pixel value by using its neighborhood information. The performance of CFA demosaicing affects greatly the image quality. Demosaicing algorithms can be generally classified into two categories: non-adaptive and adaptive algorithms. Non-adaptive algorithms apply the same interpolation technique for all pixels. The nearest neighborhood, bilinear, bicubic, and smooth hue interpolations are typical examples in this category. For example, the bilinear interpolation can be written as a linear filtering Z c DM = Hc DM ~ Z c , (2.2) where ~ denotes the two-dimensional convolution, Z c DM stands for the demosaiced image of the color channel c, and Hc DM is the linear filter for the color channel c HG DM = 1 4   0 1 0 1 4 1 0 1 0   , HR DM = HB DM = 1 4   1 2 1 2 4 2 1 2 1   . (2.3) Although non-adaptive algorithms can provide satisfactory results in smooth regions of an image, they usually fail in textured regions and edges. Therefore, adaptive algorithms, which are more computationally intensive, employ edge information or inter-channel correlation to find an appropriate set of coefficients to minimize the overall interpolation error. Because the CFA interpolation commonly estimates a missing pixel value using its neighbors, it thus creates a correlation between adjacent pixels. This spatial correlation may be amplified during subsequent processing stages. Furthermore, to improve the visual quality, the RAW image needs to go through another processing step, e.g. white balancing [11]. In fact, an object may appear different in color when it is illuminated under different light sources. This is due to the color temperature difference of the light sources, which causes the shift of the16 Chapter 2. Overview on Digital Image Forensics reflection spectrum of the object from the true color. In other words, when a white object is illuminated under a light source with low color temperature, the reflection become reddish. On the other hand, a light source with high color temperature can cause the white object to become bluish. The human visual system can recognize the white color of the white object under different light sources. This phenomenon is called color constancy. However, the digital camera does not have such luxury of millions of year of evolution as human visual system. Therefore, the white balance adjustment is implemented in the digital camera to compensate this illumination imbalance so that a captured white object is rendered white in the image. Basically, white balance adjustment is performed by multiplying pixels in each color channel by a different gain factor. For instance, one classical white balancing algorithm is the Gray World assuming that the average value of three color channels will average to a common gray value z R DM = z G DM = z B DM, (2.4) where z c DM denotes the average intensity of the demosaiced image Z c DM z c DM = 1 Nr · Nc X Nr m=1 X Nc n=1 z c DM(m, n). (2.5) In this algorithm, the green channel is fixed because human eye is more sensitive to this channel (i.e. g G WB = 1). The gain factor for other color channels is given by g R WB = z G DM z R DM , and g B WB = z G DM z B DM , (2.6) where g c WB denotes the gain factor of the color channel c for white balance adjustment. Therefore, the white-balanced image Z c WB is simply given by Z c WB = g c WB · Z c DM. (2.7) Other white-balancing algorithms may be also designed using different gain factors. Actually, the white balance adjustment is a difficult task due to estimation or selection of appropriate gain factors to correct for illumination imbalance. In this task, the prior knowledge of light sources is critical so that the camera knows to select appropriate gain factors. Therefore, some typical light sources such as daylight, incandescent or fluorescent are stored in the camera. The white balance can be done automatically in the camera. Some expensive cameras employ preprogrammed or manual white balance for adapting to illumination conditions correctly. Generally, the pixel intensity is still linear with respect to scene intensity before gamma correction [11, 12]. However, most displays have non-linear characteristics. The transfer function of these devices can be fairly approximated by a simple power function that relates the luminance L to voltage V L = V γ . (2.8)2.2. Image Processing Pipeline of a Digital Camera 17 Figure 2.3: JPEG compression chain. Typically, γ = 2.2. To compensate this effect and render the luminance into a perceptually uniform domain, the gamma correction is done in the image processing pipeline. Gamma correction is roughly the inverse of Equation (2.8), applying to each input pixel value z c GM(m, n) = z c WB(m, n)
1 γ . (2.9) After going through all post-acquisition processes, a full-color high-quality image, referred to as TIFF image, is rendered. For the sake of simplicity, let ZeTIFF denote the final full-color TIFF image. 2.2.3 Image Compression The TIFF format does not make ease of storage or transmission. Therefore, most digital cameras commonly apply lossy compression algorithms to reduce the image data size. Lossy compression algorithms allow to discard information that is not visually significant. Therefore, lossy compression algorithms are irreversible when the image reconstructed from the compressed image data is not as identical as the original image. Moreover, the use of a lossy compression algorithm is a balancing act between storage size and image quality. An image which is compressed with a high compression factor requires little storage space, but it will probably be reconstructed with a poor quality. Although many lossy compression algorithms have been proposed, most manufacturers predominately utilize JPEG compression. The JPEG compression scheme consists of three fundamental settings: color space, subsampling technique, and quantization table. Even though JPEG was already proposed by the standard Independent JPEG Group [15], manufacturers typically design their own compression scheme for optimal trade-off of image quality versus file size. Fundamental steps of the typical JPEG compression chain are shown in Figure 2.3. The JPEG compression scheme works in the different color space, typically YCbCr color space, rather than the RGB color space. The transformation to the YCbCr color space is to reduce correlations among red, green and blue components. It allows for more efficient compression. The channel Y represents the luminance of18 Chapter 2. Overview on Digital Image Forensics a pixel, and the channels Cb and Cr represent the chrominance. Each channel Y, Cb and Cr is processed separately. In addition, the channels Cb and Cr are commonly supsampled by a factor of 2 horizontally and vertically. The transformation from the RGB color space to the YCbCr color space is linear   Y Cb Cr   =   0.299 0.587 0.114 −0.169 −0.331 0.5 0.5 −0.419 0.081     R G B   +   0 128 128   . (2.10) To avoid introducing too many symbols, let ZeTIFF denote also the image obtained after this transformation. The JPEG compression algorithm consists of two key steps: Discrete Cosine Transform (DCT), and quantization. It works separately on each 8 × 8 block of a color component. The DCT operation converts pixel values from the spatial domain into transform coefficients I(u, v) = 1 4 TuTv X 7 m=0 X 7 n=0 z˜TIFF(m, n) × cos  (2m + 1)uπ 16  cos  (2n + 1)vπ 16  , (2.11) where z˜TIFF(m, n) is a pixel in a 8 × 8 block, 0 ≤ m, n ≤ 7, I(u, v) denotes the two-dimensional DCT coefficient, 0 ≤ u, v ≤ 7, and Tu is the normalized weight Tu = ( √ 1 2 for u = 0 1 for u > 0 . (2.12) The index of color channel Y, Cb, and Cr is omitted for simplicity as each color channel is processed separately. The coefficient at location (0, 0), called the Direct Current (DC) coefficient, represents the mean value of pixels in the 8 × 8 block. The remaining 63 coefficients are called the Alternating Current (AC) coefficients. The DCT is known as sub-optimal transform with two important properties: energy compaction and decorrelation. In a natural image, the majority of the energy tends to be more located in low frequencies (i.e. the upper left corner of the 8 × 8 grid) while high frequencies contains information that is not visually significant. Then, the DCT coefficients go through the quantization process. The quantization is carried out by simply dividing each coefficient by the corresponding quantization step, and then rounding to the nearest integer D(u, v) = round  I(u, v) ∆(u, v)  , (2.13) where D(u, v) is the quantized DCT coefficient and ∆(u, v) is the corresponding element in the 8 × 8 quantization table ∆. The quantization table is designed differently for each color channel. The quantization is irreversible, which results in an impossibility of recovering the original image exactly. The final processing2.3. Passive Image Origin Identification 19 step is entropy coding that is a form of lossless process. It arranges quantized DCT coefficients into the zig-zag sequence and then employs the Run-Length Encoding (RLE) algorithm and Huffman coding. This step is perfectly reversible. The JPEG decompression works in the reverse order: entropy decoding, dequantization, and Inverse DCT (IDCT). When the image is decompressed, the entropy is decoded, we obtain the two-dimensional quantized DCT coefficients. The dequantization is performed by multiplying the quantized DCT coefficient D(u, v) by the corresponding quantization step ∆(u, v) I(u, v) = ∆(u, v) · D(u, v), (2.14) where I(u, v) stands for the dequantized DCT coefficient. The IDCT operation is applied to dequantized DCT coefficients to return to the spatial domain z˜IDCT(m, n) = X 7 uh=0 X 7 uv=0 1 4 TuTvI(u, v) × cos  (2m + 1)uπ 16  cos  (2n + 1)vπ 16  . (2.15) After upsampling color components and transforming into the RGB color space, the values are rounded to the nearest integers and truncated to a finite dynamic range (typically [0, 255]) z˜JPEG(m, n) = trunc roundh z˜IDCT(m, n) i, (2.16) where z˜JPEG(m, n) is the final decompressed JPEG pixel. In general, the JPEG pixel z˜JPEG(m, n) differs from the original TIFF pixel z˜TIFF(m, n) due to the quantization, rounding and truncation (R/T) errors in the process. Note that in this image processing pipeline, R/T errors are only take into account one time for the sake of simplification. The way that JPEG compression works separately on each 8×8 block generates discontinuities across the boundaries of the blocks, which are also known as block artifacts [16]. The blocking artifacts are more severe when the quantization steps are coarser. Moreover, because of the quantization in the DCT domain, the DCT coefficients obtained by applying the DCT operation on the decompressed JPEG image will cluster around integer multiples of ∆(u, v), even though those DCT coefficients are perturbed by R/T errors. These two artifacts provide a rich source of information for forensic analysis of digital images. 2.3 Passive Image Origin Identification Basically, when an image is captured by a camera, it is stored with the metadata headers in a memory storage device. The metadata, e.g. Exchangeable Image File (EXIF) and JPEG headers, contain all recording and compression history. Therefore, a simplest way to determine the image’s source is to read out directly from the20 Chapter 2. Overview on Digital Image Forensics metadata. However, such metadata headers are not always available in practice if the image is resaved in a different format or recompressed. Another problem is that the metadata headers are not reliable as they can be easily removed or modified using low-cost editing tools. Therefore, the metadata should not be considered in forensic analysis. The common philosophy of passive approach for image origin identification is to rely on inherent intrinsic fingerprints that the digital camera leaves in a given image. The fingerprint can discriminate different camera brands, camera models, and even camera units. Any method proposed for image origin identification must respond to following questions: 1. Which fingerprints are utilized for origin identification? 2. How to extract these fingerprints accurately from a given image? 3. Under which frameworks is the method designed to exploit the discriminability of fingerprints extracted from images captured by different sources1 and to calculate the similarity of fingerprints extracted from images captured by the same source? Every stage from real-world scene acquisition to image storage can provide intrinsic fingerprints for forensic analysis (see Figure 2.1). Although the image processing pipeline is common for most cameras, each processing step is performed according to manufacturers’ own design. Thus the information left by each processing step is useful to trace down to the device source. A fingerprint must satisfy three following important requirements: • Generality: the fingerprint should be present in every image. • Invariant: the fingerprint does not vary for different image contents. • Robustness: the fingerprint survives non-linear operations such as lossy compression or gamma correction. The second question involves a challenge for any forensic method since the fingerprint extraction may be severely contaminated by non-linear operations (e.g. gamma correction and lossy compression). Generally, the image origin identification problem can be formulated into two frameworks: supervised classification [17–19] and hypothesis testing [20]. Compared with hypothesis testing framework, supervised classification framework is utilized by most of existing methods in the literature. The construction of a classifier typically consists of two stages: training stage and testing stage. It is assumed that the entire image space Z N that includes all images from all the sources in the real world can be 1The term source means an individual camera instance, a camera model, or a camera brand. Other sources such as cell-phone cameras, scanners, computer graphic are not addressed in this thesis.2.3. Passive Image Origin Identification 21 divided into disjoint subsets in which images with same characteristics from the same source are grouped together. Let {S1, S2, . . . , SNs} be Ns different sources that are required to be classified. Typically, each source Sn, 1 ≤ n ≤ Ns, is a subset of Z N . In the training stage, suppose that Nim images are collected to be representative for each source. Each image in the source Sn is denoted by Zn,i. Then a feature vector is extracted from each image. Formally, a feature vector is a mapping f : Z N → F where each image Z is mapped to a Nf-dimensional vector v = f(Z). Here, F is called feature space and Nf is the number of selected features, which is also the dimension of the feature space F. The number of features Nf is very small compared with the number of pixels N. Working in a low-dimensional feature space F that represent the input images is much simpler than working on high-dimensional noisy image space Z N . The choice of an appropriate feature vector is primordial in supervised classification framework since the accuracy of a classifier highly depends on it. Thus we obtain a set of feature vectors {vn,i} that is representative for each source. In this training stage feature refinement can be also performed such as dimensionality reduction or feature selection to avoid overtraining and redundant features. The knowledge learnt from the set of refined feature vectors helps build a classifier using supervised machine learning algorithms. A classifier typically is a learned function that can map an input feature vector to a corresponding source. Therefore, in the testing stage, the same steps such as feature selection and feature refinement are performed on the testing images. The output of the trained classifier is the result predicted for input testing images. Among many existing powerful machine learning algorithms, Support Vector Machines (SVM) [18, 19] seem to be the most popular choice in passive forensics. SVM are established in a solid mathematical foundation, namely statistical learning theory [18]. Moreover, their implementation is available for download and is easy to use [21]. Supervised classification framework involves two main drawbacks. To achieve high accuracy, supervised classification framework requires an expensive training stage that involves many images with different characteristics (e.g. image content or camera settings) from various sources for representing a real-world situation, which might be unrealistic in practice. Another drawback of this framework is that the trained classifier can not establish the statistical performances analytically since it does not rely on knowledge of a priori statistical distribution of images. In the operational context, such as for law enforcement and intelligent agencies, the design of an efficient method might not be sufficient. Forensic analysts also require that the probability of false alarm should be guaranteed and below a prescribed rate. The analytic establishment of statistical performances still remains an open problem in machine learning framework [22]. On the other hand, the problem of image origin identification problem lends itself to a binary hypothesis testing formulation. Definition 2.1. (Origin identification problem). Given an arbitrary image Z under investigation, to identify the source of the image Z, forensic analysts decide between22 Chapter 2. Overview on Digital Image Forensics two following hypotheses ( H0 : Z is acquired by the source of interest S0 H1 : Z is acquired by a certain source S1 that differs from the source S0. (2.17) Suppose that the source S0 is available, so forensic analysts can have access to its characteristics, or its fingerprints. Therefore, they can make a decision by checking whether the image in question Z contains the fingerprints of the source. Relying on a priori statistical distribution of the image Z under each source, forensic analysts can establish a test statistic that can give a decision rule according to some criteria of optimality. Statistical hypothesis testing theory has been considerably studied and applied in many fields. Several statistical tests as well as criteria of optimality have been proposed. While supervised learning framework only requires to find an appropriate set of forensic features, the most challenging part in hypothesis testing framework is to establish a statistical distribution to accurately characterize a high-dimensional real image. In doing so, hypothesis testing framework allows us to establish analytically the performance of the detector and warrant a prescribed false alarm probability, which are two crucial criteria in the operational context that supervised classification framework can not enable. However, hypothesis testing framework is of limited exploitation in forensic analysis. For the sake of clarity, hypothesis testing theory will be more detailed in Chapter A. There are many passive forensic methods proposed in the literature for image origin identification. In this thesis, we limit the scope of our review to methods for identification of the source of a digital camera (e.g. camera brand, camera model, or individual camera instance). The methods to identify other imaging mechanisms such as cell-phone cameras, scanners, and computer graphics will not be addressed. It is important to distinguish the problem of camera instance identification and the problem of camera model/brand identification. More specifically, fingerprints used for camera instance identification should capture individuality, especially cameras coming from the same brand and model. For camera model/brand identification, it is necessary to exploit fingerprints that are shared between cameras of the same model/brand but discriminative for different camera models/brands. Existing methods in the literature can be broadly divided into two categories. Methods in the first category exploit differences in image processing techniques and component technologies among camera models and manufacturers such as lens aberration [23], CFA patterns and interpolation [24–26] and JPEG compression [27,28]. The main challenge in this category is that the image processing techniques remain identical or similar, and the components produced by a few manufacturers are shared among camera models. Methods in the second category aim to identify unique characteristics or fingerprints of the acquisition device such as PRNU [29–36]. The ability to reliably extract this fingerprint from an image is the main challenge in the second category since different image contents and non-linear operations may2.3. Passive Image Origin Identification 23 severely affect this extraction. Below we will present the methods according to the position of exploited fingerprints in the image acquisition pipeline of a digital camera. 2.3.1 Lens Aberration Digital cameras use lenses to capture incident light. Due to the imperfection of the design and manufacturing process, lenses cause undesired effects in output images such as spherical aberration, chromatic aberration, or radial distorsion. Spherical aberration occurs when all incident light rays end up focusing at different points after passing through a spherical surface, especially light rays passing through the periphery of the spherical lens. Chromatic aberration is a failure of lens to converge different wavelengths at the same position on the image sensor. Radial distorsion causes straight lines rendered as curved lines on the image sensor and it occurs when the transverse magnification (ratio of the image distance to the object distance) is not a constant but a function of the off-axis image distance. Among these effects, radial distorsion may be the most severe part that lens produces in output images. Different manufacturers design different lens systems to compensate the effect of radial distorsion. Moreover, focal length also affects the degree of radial distorsion. As a result, each camera brand or model may leave an unique degree of radial distorsion on the output images. Therefore, radial distorsion of lens is exploited in [23] to identify the source of the image. The authors in [23] take the center of an image as the center of distorsion and model the undistorted radius ru as a non-linear function of distorted radius rd ru = rd + k1r 3 d + k2r 5 d . (2.18) Distorsion parameters (k1, k2) are estimated using the straight line method [37,38]. Then the distorsion parameters (k1, k2) are exploited as forensic features to train a SVM classifier. Although experiments provided a promising result, experiments were only conducted on three different camera brands. Experiments on large database including different devices per camera model and different camera models are more desirable. However, this lens aberration-based classifier would fail for a camera with possibly interchangeable lenses, e.g. Digital Single Lens Reflex (DSLR) camera. 2.3.2 Sensor Imperfections As discussed in Section 2.2, imperfections during the manufacturing process and inhomogeneity of silicon wafers leads to slight variations in the response of each pixel to incident light. These slight variations are referred as to PRNU, which is unique for each sensor pattern. Thus PRNU can be exploited to trace down to individual camera instance. The FPN was also used in [39] for camera instance identification. However, the FPN can be easily compensated, thus it is not a robust fingerprint and no longer used in later works.24 Chapter 2. Overview on Digital Image Forensics Generally, PRNU is modeled as a multiplicative noise-like signal [30, 32] Z = µ + µK + Ξ, (2.19) where Z is the output noisy image, µ is the ideal image in the absence of noise, K represents the PRNU, and Ξ accounts for the combination of other noise sources. All operations in (2.19) are pixel-wise. Like supervised classification, the PRNU-based method also consists two stages. The training stage involves collecting Nim images that are acquired by the camera of interest S0 and extracting the PRNU K0 characterizing this camera. This is accomplished by applying a denoising filter on each image to suppress the image content, then performing Maximum Likelihood (ML) estimation of K0 K0 = PNim i=1 Z res i Zi PNim i=1 Zi
2 , (2.20) where Z res i = Zi −D Z
is the noise residual corresponding to the image Zi , 1 ≤ i ≤ Nim, and D stands for the denoising filter. Note that when the PRNU is extracted from JPEG images, it may contain artifacts introduced by CFA interpolation and JPEG compression. These artifacts are not unique to each camera instance and shared among different camera units of the same model. To render the PRNU unique to the camera and improve the accuracy of the method, a preprocessing step is performed to suppress these artifacts by subtracting the averages from each row and column, and applying the Wiener filter in the Fourier domain [30]. In the testing stage, given an image under investigation Z, the problem of camera source identification (2.17) is rewritten as follows ( H0 : Z res = µK0 + Ξe H1 : Z res = µK1 + Ξe, (2.21) where the noise term Ξe includes the noise Ξ and additional terms introduced by the denoising filter. This formulation must be understood as follows: hypothesis H0 means that the noise residual Z res contains the PRNU K0 characterizing the camera of interest S0 while hypothesis H1 means the opposite. It should be noted that the PRNU detection problem in [30, 32] is formulated in the reverse direction. The sub-optimal detector for the problem (2.21) is the normalized cross correlation between the PRNU term µK and the noise residual Z res [30]. In fact, the normalized cross correlation is derived from the Generalized Likelihood Ratio Test (GLRT) by modeling the noise term Ξe as white noise with known variance [40]. A more stable statistic derived in [32] is the Peak to Correlation Energy (PCE) as it is independent of the image size and has other advantages such as its response to the presence of weak periodic signals. Theoretically, the decision threshold for the problem (2.21) is given by τ = Φ −1 (1 − α0)
2 where α0 is the prescribed false alarm probability, Φ(·) and Φ −1 (·) denotes respectively the cumulative distribution function (cdf) of the standard Gaussian random variable and its inverse. If the2.3. Passive Image Origin Identification 25 PCE is smaller than a threshold τ , the image Z is claimed taken by the camera in question. The detection performance can be improved by selecting an appropriate denoising filter [33], attenuating scene details in the test image [34,35], or recognizing the PRNU term with respect to each sub-sample of the CFA pattern [36]. Beside individual camera instance identification, the fingerprint PRNU can be also used for camera model identification [31]. This is based on an assumption that the fingerprint obtained from TIFF or JPEG images contains traces of postacquisition processes (e.g. CFA interpolation) that carry information about the camera model. In this case, the above preprocessing step that removes the linear pattern from the PRNU will not be performed. The features extracted from the PRNU term including statistical moments, cross correlation, block covariance, and linear pattern, are used to train a SVM classifier. 2.3.3 CFA Pattern and Interpolation Based on the assumption that different CFA patterns and CFA interpolation algorithms are employed by different manufacturers, even in different camera models, thus they can be used to discriminate camera brands and camera models. Typically, both CFA pattern and interpolation coefficients are unknown in advance. They must be estimated together from a single image. An algorithm has been developed in [24] to jointly estimate CFA pattern and interpolation coefficients, which has shown the robustness to JPEG compression with low quality factors. Firstly, a search space including 36 possible CFA patterns is established based on the observation that most cameras use a RGB type of CFA with a fixed periodicity of 2 × 2. Since a camera may employ different interpolation algorithms for different types of regions, it is desirable to classify the given image into three types of regions based on gradient information in a local neighborhood of a pixel: region contains parts of the image with a significant horizontal gradient, region contains parts of the image with a significant vertical gradient, and region includes the remaining smooth parts of the image. For every CFA pattern PCFA in the search space, the interpolation coefficients are computed separately in each region by fitting linear models. Using the final output image Z and the assumed CFA pattern PCFA, we can identify the set of pixels that acquired directly from the image sensor and those obtained by interpolation. The interpolated pixels are assumed to be a weighted average of the pixels acquired directly. The interpolation coefficients are then obtained by solving these equations. To overcome the difficulty of noisy pixel values and interference of non-linear post-acquisition processes, singular value decomposition is employed to estimate the interpolation coefficients. These coefficients are then use to re-estimate the output image Zb, and find the interpolation error Zb − Z. The CFA pattern that gives the lowest interpolation error and its corresponding coefficients are chosen as final results [24]. As soon as the interpolation coefficients are estimated from the given image, they are used as forensic features to train a SVM classifier for classification of cam-26 Chapter 2. Overview on Digital Image Forensics era brands and models [24]. The detection performance can be further enhanced by taking into account intra-channel and inter-channel correlations and more sophisticated interpolation algorithms in the estimation methodology [26]. Other features can be used together with interpolation coefficients such as the peak location and magnitudes of the frequency spectrum of the probability map [41]. 2.3.4 Image Compression Image compression is the final step in the image processing pipeline. As discussed in Section 2.2, manufacturers have their own compression scheme for optimal tradeoff of image quality versus file size. Different component technologies (e.g. lenses, sensors), different in-camera processing operations (e.g. CFA interpolation, whitebalancing), together with different quantization matrices will jointly result in statistical difference of quantized DCT coefficient. Capturing this statistical difference and extracting useful features from it may enable to discriminate different camera brands or camera models. To this end, instead of extracting statistical features directly from quantized DCT coefficients, features are extracted from the difference JPEG 2-D array [28]. The JPEG 2-D array consists of the magnitudes (i.e. absolute values) of quantized DCT coefficients. Three reasons behind taking absolute values are the followings: 1. The magnitudes of DCT coefficients decrease along the zig-zag order. 2. Taking absolute values can reduce the dynamic range of the resulting array. 3. The signs of DCT coefficients mainly carry information of the outlines and edges of the original spatial-domain image, which does not involve information about camera models. Thus by taking absolute values, all the information regarding camera models remains. Then to reduce the influence of image content and enhance statistical difference introduced in image processing pipeline, the difference JPEG 2-D array, which is defined by taking the difference between an element and one of its neighbors in the JPEG 2-D array, is introduced. The difference can be calculated along four directions: horizontal, vertical, main diagonal, and minor diagonal. To model the statistical difference of quantized DCT coefficients and take into account the correlation between coefficients, the Markovian transition probability matrix is exploited. Each difference JPEG 2-D array from a direction generates its own transition probability matrix. Each probability value in the transition matrix is given by P h X(uh + 1, uv) = k   X(uh, uv) = l i = PNh uh=1 PNv uv=1 1X(uh,uv)=l,X(uh+1,uv)=k PNh uh=1 PNv uv=1 1X(uh,uv)=l , (2.22) where X(uh, uv) denotes an element in the difference JPEG 2-D array and 1E is an indicator function 1E = ( 1 if E is true 0 otherwise. (2.23)2.4. Passive Image Forgery Detection 27 These steps are performed for the Y and Cb components of the compressed JPEG image. Totally, we can collect 324 transition probabilities for Y component and 162 transition probabilities for Cb component. The transition probabilities are then used as forensic features for SVM classification. Experiments are then conducted on a large database including 40000 images of 8 different camera models, providing a good classification performance [28]. In this method it is more desirable to perform feature refinement to reduce the number of features and the complexity of the algorithm. 2.4 Passive Image Forgery Detection Image forgery detection is another fundamental task of forensic analysts, which aims to detect any act of manipulation on image content. The main assumption is that even though a forger with skills and powerful tools does not leave any perceptible trace of manipulation, the manipulation creates itself inconsistencies in image content. Depending on which type of inconsistencies is investigated and how passive forensic methods operate, they can broadly be divided into five categories. A single method can hardly detect all types of forgery, so forensic analysts should use these methods together to reliably detect a wide variety of tampering. 1. Universal Classifiers: Any act of manipulation may lead to statistical changes in the underlying image. Instead of capturing these changes directly in a high-dimensional and non-stationary image, which is extremely difficult, one approach is to detect changes in a set of features that represent an image. Based on these features, supervised classification is employed to provide universal classifiers to discriminate between unaltered images and manipulated images. Some typical forensic features are higher-order wavelet statistics [42], image quality and binary similarity measures [43, 44]. These universal classifiers are not only able to detect some basic manipulations such as resizing, splicing, contrast enhancement, but also reveal the existence of hidden messages [45]. 2. Camera Fingerprints-Based: A typical scenario of forgery is to cut a portion of an image and paste it into a different image, then create the so-called forged image. The forged region may not be taken by the same camera as remaining regions of the image, which results in inconsistencies in camera fingerprints between those regions. Therefore, if these inconsistencies exist in an image, we could assume that the image is not authentic. For authentication, existing methods have exploited many camera fingerprints such as chromatic aberration [46], PRNU [30,32], CFA interpolation and correlation [25, 47–49], gamma correction [50, 51], Camera Response Function (CRF) [52–54]. 3. Compression and Coding Fingerprints-Based: Nowadays most commercial cameras export images in JPEG format for ease of storage and transmission. As discussed in Section 2.2, JPEG compression introduces two important artifacts: clustering of DCT coefficients around integer multiples of the quan-28 Chapter 2. Overview on Digital Image Forensics tization step, and blocking artifacts. Checking inconsistencies in these two artifacts can trace the processing history of an image and determine its origin and authenticity. A possible scenario is that while the original image is saved in JPEG format, a forger could save it in a lossless format after manipulation. Existence of these artifacts in an image in a lossless format can show that it has been previously compressed [55–57]. Another scenario is that the forger could save the manipulated image in JPEG format, which means that the image has undergone JPEG compression twice. Detection of double JPEG compression can be performed by checking periodic patterns (e.g. double peaks and missing centroids) in the histogram of DCT coefficients due to different quantization steps [51, 58, 59], which are not present in singly compressed images, or using the distribution of the first digit of DCT coefficients [60, 61]. The detection of double JPEG compression is of greater interest since it can reveal splicing or cut-and-paste forgeries due to the fact that the the forged region and remaining regions of the image may not have the same processing history. Inconsistencies can be identified either in DCT domain [62–65] or in spatial domain via blocking artifacts [66, 67]. Furthermore, the detection of double JPEG compression can be applied for detecting hidden messages [58, 59]. 4. Manipulation-Specific Fingerprints-Based: Each manipulation may leave specific fingerprints itself within an image, which can be used as evidence of tampering. For example, resampling causes specific periodic correlations between neighboring pixels. These correlations can be estimated based on the Expectation Maximization (EM) algorithm [68], and then used to detect the resampling [68, 69]. Furthermore, resampling can be also detected by identifying periodicities in the average of an image’s second derivative along its row and columns [70], or periodicities in the variance of an image’s derivative [71]. Contrast enhancement creates impulsive peaks and gaps in the histogram of the image’s pixel value. These fingerprints can be detected by measuring the amount of high frequency energy introduced into the Fourier transform of an image’s pixel value histogram [72]. Median filtering introduces streaking into the signals [73]. Streaks correspond to a sequence of adjacent signal observations all taking the same value. Therefore, median filtering can be detected by analyzing statistical properties of the first difference of an image’s pixel values [74–77]. Splicing disrupts higher-order Fourier statistics, which leaves traces to detect splicing [78]. 5. Physical Inconsistencies-Based: Methods in this category do not make use of any form of fingerprints but exploit properties of lighting environment for forgery detection. The main assumption is that all the objects within an image are typically illuminated under the same light sources, so the same properties of lighting environments. Therefore, difference in lighting across an image can be used as evidence of tampering, e.g. splicing. To this end, it is necessary to estimate the direction of the light source illuminating an object. This can be accomplished by considering two-dimensional [79] or three-dimensional [80]2.5. Steganography and Steganalysis in Digital Images 29 Figure 2.4: Typical steganographic system. surface normals, and illumination under a single light source [79] or even under multiple light sources [81]. The lighting environment coefficients of all objects in an image are then used for checking inconsistencies. 2.5 Steganography and Steganalysis in Digital Images Steganography is the art and science of hiding communication. The concept of steganography is used for invisible communication between only two parties, the sender and the receiver, such that the message exchanged between them can not be detected by an adversary. This communication can be illustrated by prisoners’ problem [82]. Two prisoners, Alice and Bob, want to develop an escape plan but all communications between them are unfortunately monitored by a warden named Wendy. The escape plan must be kept secret and exchanged without raising Wendy’s suspicion. It means that the communication does not only involve the confidentiality of the escape plan but also its undetectability. For this purpose, a practical way is to hide the the escape plan, or the secret message in a certain ordinary object and send it to the intended receiver. By terminology, the original object that is used for message hiding is called cover-object and the object that contains the hidden message is called stego-object. The hiding technique does not destroy the object content perceptibly to not raise Wendy’s suspicion, nor modify the message content so the receiver could totally understand the message. The advances in information technologies make digital media (e.g. audio, image, or video) ubiquitous. This ubiquity facilitates the choice of a harmless object in which the sender can hide a secret message, so sending such media is inconspicuous. Furthermore, the size of digital media is typically large compared to the size of secret message. Thus the secret message can be easily hidden in digital media without visually destroying digital content. Most of researches focus on digital images, which are also the type of media addressed in this thesis. A typical steganographic system is shown in Figure 2.4. It consists of two stages:30 Chapter 2. Overview on Digital Image Forensics embedding stage and extraction stage. When Alice wants to send a secret message M, she hides it into a cover-image C using a key and an embedding algorithm. The secret message M is a binary sequence of L bits, M = (m1, m2, . . . , mL) T with mi ∈ {0, 1}, 1 ≤ i ≤ L. The resulting stego-image S is then transmitted to Bob via an insecure channel. Bob can retrieve the message M since he knows the embedding algorithm used by Alice and has access to the key used in embedding process. Bob does not absolutely require the original cover-image C for message extraction. From the Kerckhoffs’ principle [83], it is assumed that in digital steganography, steganographic algorithms are public so that all parties including the warden Wendy have access to them. The security of the steganographic system relies solely on the key. The key could be secret key exchanged between Alice and Bob through a secure channel, or public key. In general, steganographic systems can be evaluated by three basic criteria: capacity, security, and robustness. Capacity is defined as the maximum length of a secret message. The capacity depends on the embedding algorithm and properties of cover-images. The security of a steganographic system is evaluated by the undetectability rather than the difficulty of reading the message content in case of cryptographic system. However, we can see that steganographic systems also exploit the idea of exchange of keys (secret and public) from cryptographic system to reinforce the security. Robustness means the difficulty of removing a hidden message from a stego-image, so the secret message survives some accidental channel distortions or systematic interference of the warden that aims to prevent the use of steganography. It can be noted that longer messages will lead to more changes in the cover image, thus less security. In brief, these three criteria are mutually dependent and are balanced when designing a steganographic system. The purpose of steganography is to secretly communicate through a public channel. However, this concept has been misused by anti-social elements, criminals, or terrorists. It could lead to important consequences to homeland security or national defence when, for example, two terrorists exchange a terrorist plan. Therefore, it is urgent for law enforcement and intelligence agencies to build up a methodology in order to detect the mere existence of a secret message and break the security of steganographic systems. Embedding a secret message into a cover-image is also an act of manipulating image content, so steganalysis is one of important tasks of forensic analysts, or steganalysts in this case. Unlike in cryptanalysis, the steganalyst Wendy does not require to retrieve the actual message content. As soon as she have detected its existence in an image, she can cut off the communication channel by putting two prisoners in separate cells. This is the failure of steganography. Besides, the task of steganalysis must be accomplished blindly without knowledge of original cover image. Generally, the steganalyst Wendy can play either active or passive role. While the active steganalyst is allowed to modify exchanged objects through the public channel in order to prevent the use of steganography, the passive steganalyst is not. The only goal of passive steganalyst is to detect the presence of a hidden message in a given image, which is also the typical scenario on which most of researches mainly2.5. Steganography and Steganalysis in Digital Images 31 Figure 2.5: Operations of LSB replacement (top) and Jsteg (bottom). focus. It can be noted that the steganalysis is like the coin-tossing game since the decision of steganalysts is made by telling that the given image is either a coverimage or a stego-image. Hence in any case, steganalysts can get a correct detection probability of 50%. However, steganalysts should establish the problem of hidden message detection in a more formal manner and design a powerful steganalysis tool with higher correct detection probability, rather than a random guess. Apart from detecting the presence of a hidden message, it may be desirable for steganalysts to estimate the message length or brute-force the secret key and retrieve the message content. The estimation of the message length is called quantitative steganalysis. Brute-forcing the secret key and extraction of the message content are referred to as forensic steganalysis. As stated above, designing a steganographic system is a trade-off between three basic criteria. Thus many steganographic algorithms have been proposed for different purposes such as mimic natural processing [84–86], preserve a model of coverimages [87, 88], or minimize the distorsion function [89, 90]. Among available algorithms, Least Significant Bit (LSB) replacement might be the oldest embedding technique in digital steganography. This algorithm is simple and easy to implement, thus it is available in numerous low-cost steganographic softwares on the Internet despite its relative insecurity. In addition, LSB replacement inspires a majority of other steganographic algorithms (e.g. LSB matching [91], Jsteg [92]). Jsteg algorithm is simply the implementation of LSB replacement in the DCT domain. Therefore, understanding LSB replacement paradigm is a good starting point before addressing more complex embedding paradigms. In this thesis, we only review LSB replacement and Jsteg algorithm, and their powerful steganalysis detectors proposed in the literature. The readers can be referred to [93–95] for other steganographic and steganalysis methods.32 Chapter 2. Overview on Digital Image Forensics 2.5.1 LSB Replacement Paradigm and Jsteg Algorithm Considering the cover-image C as a column vector, the LSB replacement technique involves choosing a subset of L cover-pixels {c1, c2, . . . , cL}, and replacing the LSB of each cover pixel by a message bit. The LSB of a cover-pixel ci is defined as follows LSB(ci) = ci − 2 j ci 2 k , (2.24) where b·c is the floor function. The LSB of the cover-pixel ci takes values in {0, 1}. Therefore, by embedding a message bit mi into the cover-pixel ci , the stego-pixel si is given by si = 2j ci 2 k + mi . (2.25) We see that when LSB(ci) = mi , the pixel value does not change after embedding, si = ci . By contrast, when LSB(ci) 6= mi , the stego-pixel si can be defined as a function of the cover-pixel ci in the following manner si = ci + 1 − 2 · LSB(ci) = ci + (−1)ci , ci , (2.26) where ci is the pixel with flipped LSB. In other words, even values are never decremented whereas odd values are never incremented. The absolute difference between a cover-pixel ci and a stego-pixel si is smaller than 1, |ci − si | ≤ 1, thus the artifact caused by the insertion of secret message M could be imperceptible under human vision. The operation of LSB replacement technique is illustrated in Figure 2.5. One problem that remains to be solved is the choice of the subset of cover-pixels or the sequence of pixel indices used in embedding process. To increase the complexity of the algorithm, the sender could create a pseudorandom path generated from the secret key shared between the sender and the receiver so that the secret message bits are spread randomly over the cover-image. Therefore, the distance between two embedded bits is also determined pseudorandomly, which would not raise the suspicion of the warden. We can see that the number of message bits that can be embedded does not exceed beyond the number of pixels of the image Z: L ≤ N, which leads us to define an embedding rate R R = L N . (2.27) This embedding rate R is a measure of the capacity of the steganographic system based on LSB replacement technique. Jsteg algorithm is a variant of LSB replacement technique in spatial domain. Jsteg algorithm embeds the secret message into the DCT domain by replacing LSBs of quantized DCT coefficients by message bits. The difference from the LSB replacement technique in spatial domain is that Jsteg algorithm does not embed message bits in the coefficients that are equal to 0 and 1 since artifacts caused by such embedding can be perceptibly and easily detected. The DC coefficient is not used as well for the same reason. The AC coefficients that differ from 0 et 1 are usable2.5. Steganography and Steganalysis in Digital Images 33 coefficients. Consequently, the embedding rate R in Jsteg algorithm is defied as the ratio of the length L and the number of usable coefficients in the cover-image C R = L P64 k=2 nk . (2.28) where nk is the number of usable coefficients at the frequency k, 2 ≤ k ≤ 64. 2.5.2 Steganalysis of LSB Replacement in Spatial Domain Like the origin identification problem (2.17), the steganalysis problem can be also formulated as a binary hypothesis testing. Definition 2.2. (Steganalysis problem). Given a suspect image Z, to verify whether the image Z contains a secret message or not, the steganalyst decides between two following hypotheses ( H0 : Z = C, no hidden message. H1 : Z = S, with hidden message. (2.29) To solve the steganalysis problem (2.29), several methods have been proposed in the literature. Even though the secret message is imperceptible to human eye, the act of embedding a secret message modifies the cover content and leaves itself artifacts that can be detected. Steganalysis methods of LSB replacement can be roughly divided into four categories: structural detectors, Weighted Stego-image (WS) detectors, statistical detectors, and universal classifiers. Typically, structural detectors and WS detectors are quantitative detectors that provide an estimation of secret message length while statistical detectors and universal classifiers attempt to separate stego-images from cover-images based on changes in statistical properties of cover-images due to message embedding. Below we briefly discuss each category of detectors. 2.5.2.1 Structural Detectors Structural detectors exploit all combinatorial measures of the artificial dependence between sample differences and the parity structure of the LSB replacement in order to estimate the secret message length. Some representatives in this category are the Regular-Singular (RS) analysis [96], the Sample Pair Analysis (SPA) [97– 99], and the Triple/Quadruple analysis [100, 101]. The common framework is to model effects of LSB replacement as a function of embedding rate R, invert these effects to approximate cover-image properties from the stego-image, and find the best candidate Rb to match cover assumptions. Both RS and SPA methods rely on evaluating groups of spatially adjacent pixels. The observations made in RS analysis were formally justified in SPA. For pedagogical reasons, we discuss the SPA method. For the representation of the SPA method, we34 Chapter 2. Overview on Digital Image Forensics E2k+1 O2k E2k O2k−1 R 2 (1− R 2 ) R 2 (1− R 2 ) R 2 (1− R 2 ) R 2 (1− R 2 ) R 2 4 R 2 4 (1− R 2 ) 2 (1− R 2 ) 2 (1− R 2 ) 2 (1− R 2 ) 2 Figure 2.6: Diagram of transition probabilities between trace subsets under LSB replacement. use the extensible alternative notations in [95, 101]. Given an image Z, we define a trace set Ck that collect all pairs of adjacent pixels (z2i , z2i+1) as follows Ck = n (2i, 2i + 1) ∈ I2    j z2i 2 k = j z2i+1 2 k + k o , (2.30) where I is the set of pixel indices. Each trace set Ck is then partitioned into four trace subsets, Ck = E2k ∪ E2k+1 ∪ O2k ∪ O2k−1, where Ek and Ck are defined by    Ek = n (2i, 2i + 1) ∈ I2    z2i = z2i+1 + k, z2i+1 is eveno Ok = n (2i, 2i + 1) ∈ I2    z2i = z2i+1 + k, z2i+1 is oddo . (2.31) We can observe that the LSB replacement technique never changes the trace set Ck of a sample pair but can move sample pairs between trace subsets. Therefore, we establish transition probabilities as functions of the embedding rate R, which is shown in Figure 2.6. Thus we can derive the relation between trace subsets of a stego-image and those of a cover-image   |Es 2k+1| |Es 2k | |Os 2k | |Os 2k−1 |   =   1 − R 2
2 R 2 1 − R 2
R 2 1 − R 2
R2 4 R 2 1 − R 2
1 − R 2
2 R2 4 R 2 1 − R 2
R 2 1 − R 2
R2 4 1 − R 2
2 R 2 1 − R 2
R2 4 R 2 1 − R 2
R 2 1 − R 2
1 − R 2
2     |Ec 2k+1| |Ec 2k | |Oc 2k | |Oc 2k−1 |   , (2.32) where E c k and Oc k are trace subsets of the cover-image, and E s k and Os k are trace subsets of the stego-image. Here |S| denotes the cardinality of the set S. After inverting the transition matrix and assuming that |Ec 2k+1| = |Oc 2k+1|, we obtain a quadratic equation 0 = R 2  |Ck| − |Ck+1|  + 4 |Es 2k+1| − |Os 2k+1|  + 2R  |Es 2k+2| + |Os 2k+2| − 2|Es 2k+1| + 2|Os 2k+1| − |Es 2k | − |Os 2k |  . (2.33)2.5. Steganography and Steganalysis in Digital Images 35 The solution of Equation (2.33) is an estimator of the embedding rate R. The SPA method was further improved by combining with Least Squares (LS) method [98] and Maximum Likelihood [99], or generalizing from analysis of pairs to analysis of k-tuples [100, 101]. 2.5.2.2 WS Detectors WS detectors were originally proposed by J. Fridrich in [102] and then improved in [103, 104]. The key idea of WS is that the embedding rate can be estimated via the weight that minimizes the distance between the weighted stego image and the cover image [95]. The weighted stego-image with scalar parameter λ of the image Z is defined by ∀i ∈ I, z (λ) i = (1 − λ)zi + λzi , with zi = zi + (−1)zi . (2.34) The estimator Rb can be provided by minimizing the Euclidian distance between the weighed stego-image and the cover image Rb = 2 arg min λ X N i=1 wi z (λ) i − ci
2 , (2.35) where the normalized weight vector w with PN i=1 wi = 1 is taken into account in the minimization problem (2.35) to reflect the heterogeneity in a natural image. By solving the root of the first derivative in (2.35), a simplified estimator is given as Rb = 2X N i=1 wi(zi − zi)(zi − ci). (2.36) Since the cover-pixels ci are unknown in advance, a local estimator for each pixel from its spatial neighborhood can be employed, or more generally, a linear filter D, to provide an estimate of cover-image: Cb = D(Z). The estimator Rb in (2.36) follows immediately. From above observations, the choices of an appropriate linear filter D and weight vector w are crucial for improvement of WS detectors’ performance [95, 103, 104]. Both structural detectors and WS detectors are established into quantitative steganalysis framework, which means that instead of indicating a suspect image Z is either a cover-image or stego-image, the output of those detectors is a real-value estimate of the secret message length. In other words, even no secret message is embedded in the image, i.e. R = 0, we could still obtain a negative or positive value. Nevertheless, quantitative detectors offer an additional advantage over statistical detectors, namely that the detection performance can be measured by evaluating the deviation of the estimator Rb from the true embedding rate R. Some criteria can be used as measures of performance such as • Mean Absolute Error (MAE): 1 Nim X Nim n=1 |Rbn − R|, (2.37)36 Chapter 2. Overview on Digital Image Forensics where Nim is number of images. • Median Absolute Error (mAE): mediann|Rbn − R|. (2.38) 2.5.2.3 Statistical Detectors In contrast to structural detectors and WS detectors, statistical detectors rely on changes in statistical properties due to message embedding to detect the presence of the secret message. The output of statistical detectors is a binary decision. Some representatives are χ 2 detector [105] and Bayesian approach-based detector [106]. Another interesting approach is the one proposed in [107] that is based on the statistical hypothesis testing theory. To this end, two preliminary assumptions are given in the following proposition: Proposition 2.1. In the LSB replacement embedding technique, we assume that 1. The secret message bits are uniformly distributed over the cover-image, namely that the probability of embedding a message bit into every cover-pixel is identique. Moreover, message bits and cover pixels are statistically uncorrelated [107]. 2. Secret message bits are independent and identically distributed (i.i.d), and each message bit mi is drawn from the Binomial distribution B(1, 1 2 ) P[mi = 0] = P[mi = 1] = 1 2 , (2.39) where P[E] denotes the probability that an event E occurs. Therefore, from the mechanism of LSB replacement, we can see that the probability that the pixel does not change after embedding is 1 − R 2 while the probability that its LSB is flipped is R 2 P[si = ci ] = 1 − R 2 and P[si = ci ] = R 2 . (2.40) Let P0 be the probability distribution of cover-images. Due to message embedding at rate R whose properties are given in Proposition 2.1, the cover image moves from the probability distribution P0 to a different probability distribution, denoted PR. Thus the steganalysis problem (2.29) can be rewritten as follows ( H0 : Z ∼ P0 H1 : Z ∼ PR. (2.41) Based on the assumption that all pixels are independent and identically distributed, the authors in [107] have developed two schemes depending on the knowledge of the probability distribution P0. When the probability distribution P0 is not known,2.5. Steganography and Steganalysis in Digital Images 37 the authors study the asymptotically optimal detector (as the number of pixels N → ∞) according to Hoeffding’s test [108]. When the probability distribution P0 is known in advance, an optimal detector is given in the sense of NeymanPearson [20, Theorem 3.2.1]. Although the statistical detector proposed in [107] is interesting from theoretical point of view, its performance in practice is quite moderate due to the fact that the cover model used in [107] is not sufficiently accurate to describe a natural image. The assumption of independence between pixels does not hold since the image structure and the non-stationarity of noises during image acquisition process are not taken into account. Some later works [109–114] rely on a simplistic local polynomial model in which pixel’s expectations are different in order to design a statistical detector, providing high detection performance compared with structural and WS ones. Far from assuming that all the pixels are i.i.d as in [107], those works propose to model each cover-pixel by the Gaussian distribution, ci ∼ N (µi , σ2 i ), in order to design the Likelihood Ratio Test (LRT) in which the Likelihood Ratio (LR) Λ can be given by Λ(Z) ∝ X i 1 σ 2 i (zi − zi)(zi − µi). (2.42) The LRT is the most powerful test in the sense of Neyman-Pearson approach [20, Theorem 3.2.1] that can meet simultaneously two criteria of optimality: warranting a prescribed false alarm probability and maximizing the correct detection probability. Moreover, the specificity in this approach is to show that the WS detector [102–104] is indeed a variant of the LRT, which justifies the good detection performance of such ad hoc detector. Besides, hypothesis testing theory has been also extended to other complex embedding algorithm, e.g. LSB matching [115, 116]. 2.5.2.4 Universal Classifiers Three previous families of detectors are targeted to a specific steganographic algorithm, namely LSB replacement. In other words, these three families work on an assumption that steganalysts know in advance the embedding algorithm used by the steganographer. Such scenario may not be realistic in the practical context. Universal classifiers are employed by steganalysts to work in a blind manner in order to discriminate stego-images and cover-images. Even though universal classifiers have lower performance than specific embedding-targeted detectors, they are still important because of their flexibility and ability to be adjusted to completely unknown steganographic methods. Typically, universal classifiers can be divided into two types: supervised and unsupervised. Supervised classification [45, 76, 117–120] has been already discussed in Section 2.3. While supervised classification requires to know in advance the label of each image (i.e. cover-image or stego-image) and then build a classifier based on labeled images, unsupervised classification works in a scenario of unlabeled images and classifies them automatically without user interference. The accuracy of supervised classifiers is limited if the training data is not perfectly representative of38 Chapter 2. Overview on Digital Image Forensics cover source, which may result in mismatch problem [121]. Unsupervised classifiers try to overcome this problem of model mismatch by postponing building a cover model until the classification stage. However, to the best of our knowledge, there has not been yet a reliable method dealing with this scenario in steganalysis. In universal steganalysis, the design of features is of crucial importance. Features used for classification should be sensitive to changes caused by embedding, yet insensitive to variations between covers including also some non-steganographic processing techniques. In general, the choice of suitable features and machine learning tools remains open problems [121]. 2.5.3 Steganalysis of Jsteg Algorithm Like steganalysis of LSB replacement in spatial domain, existing methods for steganalysis of Jsteg algorithm can be also divided into four categories. Structural detectors detect the presence of secret message by employing the symmetry of the histogram of DCT coefficients in natural images, which is disturbed by the operation of Jsteg embedding. Some representative structural detectors are Zhang and Ping (ZP) detector [122], DCT coefficient-based detector [123], and category attack [124, 125]. Furthermore, the power of structural detectors can be combined with theoretically well-founded ML principle [99] or the concept of Zero Message Hypothesis (ZMH) [96]. These two approaches have been formally analyzed in [126]. Similar to structural detectors for steganalysis of LSB replacement technique, the ZHM framework starts by choosing a feature vector x of the cover-image (e.g. trace subsets in case of SPA method), establishes the change in the feature vector x due to embedding algorithm Emb, then inverts embedding effects to provide a hypothetical feature vector ˆx ˆx = Emb−1 (x r , r), (2.43) where x r is the stego vector and r is the change rate defined as the ratio between the number of modified DCT coefficients and the maximum number of usable coefficients, thus r = R 2 . Using cover assumptions and zero message properties (e.g. natural symmetry of the histogram of DCT coefficients), an appropriate penalty function zmh(x) ≥ 0 is defined so that it returns zero on cover features and nonzero otherwise. Therefore, the change rate estimator rˆ is defined as the solution of a minimization problem rˆ = arg min r≥0 zmh(ˆx) = arg min r≥0 zmh(Emb−1 (x r , r)). (2.44) The minimization in (2.44) can be performed either analytically or numerically by implementing a one-dimensional gradient-descent search over r. The main interest in [126] is that all features proposed in [104,122,124,125] have been revisited within ZHM framework. The detector proposed in [123] has been also improved in [126] within ML framework using a more accurate model of DCT coefficients, namely Generalized Cauchy distribution. It can be noted that although ZMH is only a2.6. Conclusion 39 heuristic framework and less statistically rigorous than ML framework, it has some important advantages in terms of low computational complexity and flexibility. Although Jsteg algorithm replaces LSBs by secret message bits in DCT domain, the mathematical foundation of WS detectors can be also applied for steganalysis of Jsteg [127, 128]. Given a vector of AC coefficients D = {D1, D2, . . . , DN }, the WS-like detector is given by Rb ∝ X i wi(Di − Di)Di . (2.45) The difference between the WS detector in (2.36) and the one in (2.45) is that the local predictor for cover AC coefficients is omitted since the expected value of AC coefficients is zero in natural images. The weigh wi for each coefficient Di is estimated by taking the coefficients at the same location as Di but in four adjacent blocks. More details were provided in [128]. The hypothesis testing theory was also applied to the steganalysis of Jsteg algorithm. By relying the Laplacian model of DCT coefficients, a statistical test was designed in [129]. However, a considerable loss of power was revealed due to the fact that the Laplacian model is not accurate enough to characterize DCT coefficients. 2.6 Conclusion This chapter discusses the emerging field of digital image forensics consisting of two main problems: image origin identification and image forgery detection. To address these problems, active forensic approach has been proposed by generating extrinsically fingerprints and adding them into the digital image in the image formation process, thus creates a trustworthy digital camera. However, active approach is of limited application due to many strict contraints in its protocols. Therefore, passive forensic approach has been considerably evolved to help solve these problems in their entirety. This approach relies on intrinsic traces left by the digital cameras in the image processing pipeline and by the manipulations themselves to gather forensic evidence of image origin or forgery. Some intrinsic fingerprints for identification of image source such as lens aberration, PRNU, CFA pattern and interpolation, and JPEG compression are reviewed. The task of steganalysis that aims to detect the mere presence of a secret message in a digital image is also discussed in this chapter. The state of the art has shown that most of existing methods have been designed within classification framework. Hypothesis testing framework is of limited exploitation although this framework offers many advantages, namely that the statistical performance of detectors can be analytically established and a prescribed false alarm probability can be guaranteed. Besides, existing methods are designed using simplistic image models, which results in overall poor detection performance. This thesis focuses on applying the hypothesis testing theory in digital image forensics based on an accurate image model, which is established by modeling the main steps in the image processing pipeline. These aspects will be discussed in the rest of the thesis.Chapter 3 Overview on Statistical Modeling of Natural Images Contents 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2 Spatial-Domain Image Model . . . . . . . . . . . . . . . . . . 41 3.2.1 Poisson-Gaussian and Heteroscedastic Noise Model . . . . . . 42 3.2.2 Non-Linear Signal-Dependent Noise Model . . . . . . . . . . 44 3.3 DCT Coefficient Model . . . . . . . . . . . . . . . . . . . . . . 45 3.3.1 First-Order Statistics of DCT Coefficients . . . . . . . . . . . 45 3.3.2 Higher-Order Statistics of DCT Coefficients . . . . . . . . . . 46 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1 Introduction The application of hypothesis testing theory in digital image forensics requires an accurate statistical image model to achieve high detection performance. For instance, the PRNU-based image origin identification [30,32] takes into account various noise sources during image acquisition inside a digital camera, which provides an image model allowing to accurately extract the fingerprint for source identification. An inaccurate image model will result in a poor detection performance, e.g. in case of statistical detectors [107, 129]. Therefore in this chapter, the state of the art on statistical modeling of natural images is reviewed. The statistical image modeling can be performed either in spatial domain or DCT domain. The chapter is organized as follows. Section 3.2 analyzes noise statistics in spatial domain and presents some dominant image models widely used in image processing. Section 3.3 discusses empirical statistical models of DCT coefficients. Finally, Section 3.4 concludes the chapter. 3.2 Spatial-Domain Image Model In this section, we adopt the representation of an arbitrary image Z as a column vector of length N = Nr × Nc. The representation as a two-dimensional matrix is of42 Chapter 3. Overview on Statistical Modeling of Natural Images no interest in the study of statistical noise properties. The index of color channel is omitted for simplicity. Due to the stochastic nature of noise, a pixel is regarded as a random variable. Generally, the random variable zi , i ∈ I, can be decomposed as zi = µzi + ηzi , (3.1) where I = {1, . . . , N} denotes the set of pixel indices, µzi denotes the expectation of the pixel zi in the absence of noise, and ηzi accounts for all noise sources that interfere with the original signal. By convention, µX and σ 2 X denote respectively the expectation and variance of a random variable X. Here, the expectation µzi is considered deterministic and will not be modeled. However, the expectations differ from each other due to heterogeneity in a natural image. From (3.1), it is easily seen that the variance of noise ηzi is equal to the variance of pixel zi , i.e. σ 2 zi = σ 2 ηzi . Some models have been proposed in the literature for the noise ηzi in an uncompressed image. They can be classified into two groups: signal-independent and signal-dependent noise models. While signal-independent noise models assume the stationarity of noise in the whole image, regardless original pixel intensity, signal-dependent noise models take into account the proportional dependence of noise variance on the original pixel intensity. A typical example for the group of signal-independent noise is the Additive White Gaussian Noise (AWGN). Besides, signal-dependent noise includes Poisson noise or film-grain noise [130], PoissonGaussian noise [131, 132], heteroscedastic noise model [133, 134], and non-linear noise model [135]. Although the AWGN model is widely adopted in image processing because of its simplicity, it ignores the contribution of Poisson noise to the image acquisition chain, which is the case of an image acquired by a digital camera. Noise sources in a natural image are inherently signal-dependent. Therefore, a signal-dependent noise model is more expected to be employed in further applications. Since our works mainly focus on signal-dependent noise, only the group of signal-dependent noise models are discussed in this section. 3.2.1 Poisson-Gaussian and Heteroscedastic Noise Model The study of noise statistics requires to take into account the impact of Poisson noise related to the stochastic nature of photon-counting process and dark current [131–134, 136]. Let ξi denote the number of collected electrons with respect to the pixel zi . The number of collected electrons ξi follows the Poisson distribution with mean λi and variance λi ξi ∼ P(λi). (3.2) This Poisson noise results in the dependence of noise variance on original pixel intensity. The number of collected electrons is further degraded by the AWGN read-out noise ηr with variance ω 2 . Therefore, the RAW image pixel recorded by the image sensor can be defined as [136] zi = a · ξi + ηr
, (3.3)3.2. Spatial-Domain Image Model 43 where a is the analog gain controlled by the ISO sensitivity. This leads to the statistical distribution of the RAW pixel zi zi ∼ a · h P(λi) + N (0, ω2 ) i . (3.4) This model is referred to as Poisson-Gaussian noise model [131,132]. One interesting property of this model is the linear relation of pixel’s expectation and variance. Taking mathematical expectation and variance from (3.4), we obtain µzi = E[zi ] = a · λi , (3.5) σ 2 zi = Var[zi ] = a 2 · (λi + ω 2 ), (3.6) where E[X] and Var[X] denote respectively the mathematical expectation and variance with respect to a random variable X. Consequently, the heteroscedastic relation is derived as σ 2 zi = a · µzi + b, (3.7) where b = a 2ω 2 . In some image sensors, the collected electrons ξi may be added by a base pedestal parameter p0 to constitute an offset-from-zero of the output pixel [133] zi ∼ a · h p0 + P(λi − p0) + N (0, ω2 ) i . (3.8) Hence, the parameter b is now given by b = a 2ω 2 − a 2p0. Therefore, the parameter b can be negative when p0 > ω2 . To facilitate the application of this signal-dependent noise model, some works [133, 134] have attempted to approximate the Poisson distribution by the Gaussian distribution in virtue of a large number of collected electrons P(λi) ≈ N (λi , λi). (3.9) In fact, for λi ≥ 50, the Gaussian approximation is already very accurate [133] while full-well capacity is largely above 100000 electrons. Finally, the statistical distribution of the RAW pixel zi can be approximated as zi ∼ N µzi , a · µzi + b
. (3.10) This model is referred to as heteroscedastic noise model in [134]. The term "heteroscedasticity" means that each pixel exposes a different variability with the other. Both Poisson-Gaussian and heteroscedastic noise models are more accurate to characterize a RAW image than the conventional AWGN, but they do not take into account yet non-linear post-acquisition operations. Therefore, they are not appropriate for modeling a TIFF or JPEG image. Besides, it should be noted that the Poisson-Gaussian and heteroscedastic noise model assume that the effect of PRNU is negligible, namely that all the pixels respond to the incident light uniformly. The very small variation in pixel’s response does not strongly affect its statistical distribution [136].44 Chapter 3. Overview on Statistical Modeling of Natural Images 3.2.2 Non-Linear Signal-Dependent Noise Model To establish a statistical model of a natural image in TIFF or JPEG format, it is necessary to take into account effects of post-acquisition operations in the image processing pipeline. However, as discussed in Section 2.2, the whole image processing pipeline is not as simple. Some processing steps that are implemented in a digital camera are difficult to model parametrically. One approach is to consider the digital camera as a black box in which we attempt to establish a relation between input irradiance and output intensity. This relation is called Camera Response Function (CRF), which is described by a sophisticated non-linear function fCRF(·) [137]. Gamma correction might be the simplest model for the CRF with only one parameter. Other parametric models have been proposed for CRF such as polynomial model [137] or generalized gamma curve model [138]. Therefore, the pixel zi can be formally defined as [135, 139] zi = fCRF Ei + ηEi
, (3.11) where Ei denotes the image irradiance and ηEi accounts for all signal-independent and signal-dependent noise sources. We can note that although some methodologies have been proposed for estimation of CRF [50, 137, 140], it is also difficult to study noise statistics with those sophisticated models. To facilitate the study of noise statistics, the authors in [135] exploit the first order of Taylor’s series expansion zi = fCRF Ei + ηEi
≈ fCRF Ei
+ f 0 CRF Ei
ηEi , (3.12) where f 0 CRF denotes the first derivative of the CRF fCRF. Therefore, a relation between noises before and after transformation by the CRF is obtained ηzi = f 0 CRF Ei
ηEi . (3.13) It can be noted that even when noise before transformation is independent of the signal, the non-linear transformation fCRF generates a dependence between pixel’s expectation and variance. Based on experimental observations, the authors in [135] obtain a non-linear parametric model zi = µzi + µ γ˜ zi · ηu, (3.14) where ηu is zero-mean stationary Gaussian noise, ηu ∼ N (0, σ2 ηu ), and γ˜ is an exponential parameter to account for the non-linearity of the camera response. Here, taking variance on the both sides of (3.14), we obtain σ 2 zi = µ 2˜γ zi · Var[ηu] = µ 2˜γ zi · σ 2 ηu . (3.15) In this model, the pixel zi still follows the Gaussian distribution and the noise variance σ 2 ηzi is non-linearly dependent on the original pixel intensity µzi zi ∼ N µzi , µ2˜γ zi · σ 2 ηu
. (3.16) This model allows to represent several kinds of noise such as film-grain, Poisson noise by changing the parameters γ˜ and σ 2 ηu (e.g γ˜ = 0.5).3.3. DCT Coefficient Model 45 3.3 DCT Coefficient Model 3.3.1 First-Order Statistics of DCT Coefficients Apart from modeling an image in the spatial domain, many researches attempt to model it in the DCT domain since the DCT is a fundamental operation in JPEG compression. The model of DCT coefficients has been considerably studied in the literature. However, a majority of DCT coefficient models has just been proposed without giving any mathematical foundation and analysis. Many researches focus on comparing the empirical data with a variety of popular statistical models by conducting the goodness-of-fit (GOF) test, e.g. the Kolmogorov-Smirnov (KS) or χ 2 test. Firstly, the Gaussian model for the DCT coefficients was conjectured in [141]. The Laplacian model was verified in [142] by performing the KS test. This Laplacian model remains a dominant choice in image processing because of its simplicity and relative accuracy. Other possible models such as Gaussian mixture [143] and Cauchy [144] were also proposed. In order to model the DCT coefficients more accurately, the previous models were extended to the generalized versions including the Generalized Gaussian (GG) [145] and the Generalized Gamma (GΓ) [146] models. It has been recently reported in [146] that the GΓ model outperforms the Laplacian and GG model. Far from giving a mathematical foundation of DCT coefficient model, these empirical models were only verified using GOF test on a few standard images. Thus, they can not guarantee the accuracy of the chosen model to a wide range of images, which leads to a lack of robustness. The first mathematical analysis for DCT coefficients is given in [147]. It relies on a doubly stochastic model combining DCT coefficient statistics in a block whose variance is constant with the variability of block variance in a natural image. However, this analysis is incomplete due to the lack of mathematical justification for the block variance model. Nevertheless, it has shown an interest for further improvements. Therefore, here we provide a discussion about this mathematical foundation. Let I denote AC coefficient and σ 2 blk denote block variance. The DC coefficient is not addressed in this work [147]. The index of frequency is omitted for the sake of clarity. Using the conditional probability, the doubly stochastic model is given by fI (x) = Z ∞ 0 fI|σ 2 blk (x|t)fσ 2 blk (t)dt x ∈ R, (3.17) where fX(x) denotes the probability density function (pdf) of a random variable X. This doubly stochastic model can be considered as infinite mixture of Gaussian distributions [148, 149]. From the establishment of DCT coefficients in (2.11), it is noted that each DCT coefficient is a weighted sum of random variables. If the block variance σ 2 blk is constant, the AC coefficient I can be approximated as a zero-mean Gaussian random variable based on the Central Limit Theorem (CLT) fI|σ 2 blk (x|t) = 1 √ 2πt exp  − x 2 2t  . (3.18)46 Chapter 3. Overview on Statistical Modeling of Natural Images Even though the pixels are spatially correlated in a 8 × 8 block due to demosaicing algorithms implemented in a digital camera, the CLT can still be used for Gaussian approximation of a sum of correlated random variables [150]. It remains to find the pdf of σ 2 blk to derive the final pdf of the AC coefficient I. To this end, it was reported in [147] that from experimental observations, the block variance σ 2 blk can be modeled by exponential or half-Gaussian distribution. These two distributions can lead to the Laplacian distribution for the DCT coefficient I [147]. However, as stated above, due to the fact that the pdf of block variance σ 2 blk is not mathematically justified, this mathematical framework is incomplete. 3.3.2 Higher-Order Statistics of DCT Coefficients The above discussion only considers the first-order statistics (i.e. histogram) of DCT coefficients. The DCT coefficients at the same frequency are collected and treated separately. An implicite assumption adopted in this procedure is that the DCT coefficients at the same frequency are i.i.d realizations of a random variable. However, this is not always true in a natural image because DCT coefficients exhibit dependencies (or correlation) between them. There are two fundamental kinds of correlation between DCT coefficients [151], which have been successfully exploited in some applications [126, 151, 152] 1. intra-block correlation: A well-known feature of DCT coefficients in a natural image is that the magnitudes of AC coefficients decrease as the frequency increases along the zig-zag order. This correlation reflects the dependence between DCT coefficients within a same 8×8 block. Typically, this correlation is weak since coefficients at different frequencies correspond to different basis functions. 2. inter-block correlation: Although the DCT base can provide a good decorrelation, resulting coefficients are still correlated slightly with their neighbors at the same frequency. We refer this kind of correlation as inter-block correlation. In general, the correlation between DCT coefficients could be captured by adjacency matrix [126]. 3.4 Conclusion This chapter reviews some statistical image models in spatial domain and DCT domain. In spatial domain, two groups of signal-independent and signal-dependent noise models are discussed. From above statistical analysis, we can draw an important insight: noise in natural images is inherently signal-dependent. In DCT domain, some empirical models of DCT coefficient are presented. However, most of DCT coefficient models are given without mathematical justification. It is still necessary to establish an accurate image model that can be exploited in further applications.Part II Statistical Modeling and Estimation for Natural Images from RAW Format to JPEG FormatChapter 4 Statistical Image Modeling and Estimation of Model Parameters Contents 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2 Statistical Modeling of RAW Images . . . . . . . . . . . . . . 50 4.2.1 Heteroscedastic Noise Model . . . . . . . . . . . . . . . . . . 50 4.2.2 Estimation of Parameters (a, b) in the Heteroscedastic Noise Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.2.1 WLS Estimation . . . . . . . . . . . . . . . . . . . . 53 4.2.2.2 Statistical Properties of WLS Estimates . . . . . . . 54 4.3 Statistical Modeling of TIFF Images . . . . . . . . . . . . . . 57 4.3.1 Generalized Noise Model . . . . . . . . . . . . . . . . . . . . . 57 4.3.2 Estimation of Parameters (˜a, ˜b) in the Generalized Noise Model 59 4.3.2.1 Edge Detection and Image Segmentation . . . . . . 59 4.3.2.2 Maximum Likelihood Estimation . . . . . . . . . . . 60 4.3.3 Application to Image Denoising . . . . . . . . . . . . . . . . . 61 4.3.4 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . 62 4.4 Statistical Modeling in DCT Domain . . . . . . . . . . . . . 65 4.4.1 Statistical Model of Quantized DCT Coefficients . . . . . . . 65 4.4.1.1 Statistical Model of Block Variance and Unquantized DCT Coefficients . . . . . . . . . . . . . . . . . . . . 65 4.4.1.2 Impact of Quantization . . . . . . . . . . . . . . . . 68 4.4.2 Estimation of Parameters (α, β) from Unquantized DCT Coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.4.3 Estimation of Parameters (α, β) from Quantized DCT Coeffi- cients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4.4 Numerical Experiments . . . . . . . . . . . . . . . . . . . . . 71 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7350 Chapter 4. Statistical Image Modeling and Estimation of Model Parameters 4.1 Introduction Chapter 3 has presented an overview on statistical modeling of natural images in spatial domain and DCT domain. Most of existing models in the literature were provided empirically. The goal of this chapter is to establish a mathematical framework of studying statistical properties of natural images along image processing pipeline of a digital camera. The study is performed in spatial domain and DCT domain. In the spatial domain, the heteroscedastic noise model is firstly recalled, and a method for estimating the parameters of the heteroscedastic noise model following the Weighted Least Square (WLS) approach is proposed in Section 4.2. The analytic establishment of WLS estimates allows us to study their statistical properties, which is of importance for designing statistical tests. The WLS estimation of parameters (a, b) has been presented in [134]. Next, Section 4.3 presents the study of noise statistics in a TIFF image by starting from the heteroscedastic noise model and take into account the effect of gamma correction, resulting in the generalized signal-dependent noise model. It is shown that the generalized noise model is also relevent to characterize JPEG images with moderate-to-high quality factors (Q ≥ 70). This section also proposes a method that can estimate the parameters of the generalized noise model accurately from a single image. Numerical results on a large image database show the relevance of the proposed method. The generalized noise model could be useful in many applications. A direct application for image denoising is proposed in this section. The foundation of generalized noise model and estimation of model parameters have been presented in [153]. Section 4.4 describes the mathematical framework of modeling the statistical distribution of DCT coefficients. To simplify the study, the approach is based on the main assumption that the pixels are identically distributed (not necessarily independent) within a 8 × 8 block. Consequently, the statistical distribution of block variance can be approximated, thus the model of unquantized DCT coefficients is provided. Moreover, it is proposed to take into account the quantization operation to provide a final model of quantized DCT coefficients. The parameters of DCT coefficient model can be estimated following the ML approach. Numerical results show that the proposed model outperforms other existing models including Laplacian, GG, and GΓ model. Section 4.5 concludes the chapter. The foundation of DCT coefficient model has been presented in [154]. 4.2 Statistical Modeling of RAW Images 4.2.1 Heteroscedastic Noise Model The RAW image acquisition has been discussed in Section 2.2.1. Let Z = (zi)i∈I denote a RAW image acquired by the image sensor. Typically, the model of RAW pixel consists of a Poissonian part that addresses the photon shot noise and dark current and a Gaussian part for the remaining stationary disturbances, e.g. read-4.2. Statistical Modeling of RAW Images 51 estimated expectation: µˆk estimated variance: ˆσ 2 k 0 0.05 0.1 0.15 0.2 0.25 0 0.4 0.8 1.2 1.6 2 ×10−5 Nikon D70: Estimated data Nikon D70: Fitted data Nikon D200: Estimated data Nikon D200: Fitted data Figure 4.1: Scatter-plot of pixels’ expectation and variance from a natural RAW image with ISO 200 captured by Nikon D70 and Nikon D200 cameras. The image is segmented into homogeneous segments. In each segment, the expectation and variance are calculated and the parameters (a, b) are estimated as proposed in Section 4.2.2. The dash line is drawn using the estimated parameters (a, b). Only the red channel is used in this experiment. out noise. For the sake of simplification, the Gaussian approximation of the Poisson distribution can be exploited because of a large number of collected electrons, which leads to the heteroscedastic noise model [133, 134] zi ∼ N µi , aµi + b
, (4.1) where µi denotes the expectation of the pixel zi . The heteroscedastic noise model, which gives the noise variance as a linear function of pixel’s expectation, characterizes a RAW image more accurately than the conventional AWGN model. The heteroscedastic noise model (4.1) is illustrated in Figure 4.1. It is assumed that the noise corrupting each RAW pixel is statistically independent of those of neighbor pixels [133, 136]. In this section it is assumed that the phenomenon of clipping is absent from a natural RAW image for the sake of simplification, i.e. the probability that one observation zi exceeds over the boundary 0 or B = 2ν−1 is negligible. More details about the phenomenon of clipping are given in [133, 155] and in Chapter 8. In practice, the PRNU weakly affects the parameter a in the heteroscedastic noise model (4.1). Nevertheless, in the problem of camera model identification, the PRNU is assumed to be negligible, i.e. the parameter a remains constant for every pixel.52 Chapter 4. Statistical Image Modeling and Estimation of Model Parameters 4.2.2 Estimation of Parameters (a, b) in the Heteroscedastic Noise Model Estimation of noise model parameters can be performed from a single image or multiple images. From a practical point of view, we mainly focus on noise model parameter estimation from a single image. Several methods have been proposed in the literature for estimation of signal-dependent noise model parameters, see [133–135, 139, 156]. They rely on similar basic steps but differ in details. The common methodology starts from obtaining local estimates of noise variance and image content, then performing the curve fitting to the scatter-plot based on the prior knowledge of noise model. The existing methods involve two main difficulties: influence of image content and spatial correlation of noise in a natural image. In fact, homogeneous regions where local expectations and variances are estimated are obtained by performing edge detection and image segmentation. However, the accuracy of those local estimates may be contaminated due to the presence of outliers (textures, details and edges) in the homogeneous regions. Moreover, because of the spatial correlation between pixels, the local estimates of noise variance can be overestimated. Overall, the two difficulties may result in inaccurate estimation of noise parameters. For the design of subsequent tests, the parameters (a, b) should be estimated following the ML approach and statistical properties of ML estimates should be analytically established. One interesting method is proposed in [133] for ML estimation of parameters (a, b). However, that method can not provide an analytic expression of ML estimates due to the difficulty of resolving the complicated system of partial derivatives. Therefore, ML estimates are only numerically solved by using the Nelder-Mead optimization method [157]. Although ML estimates given by that method are relatively accurate, they involve three main drawbacks. First, the convergence of the maximization process and the sensitivity of the solution to initial conditions have not been analyzed yet. Second, the Bayesian approach used in [133] with a fixed uniform distribution might be doubtful in practice. Finally, it seems impossible to establish statistical properties of the estimates. This section proposes a method for estimation of parameters (a, b) from a single image. The proposed method relies on the same technique of image segmentation used in [133] in order to obtain local estimates in homogeneous regions. Subsequently, the proposed method is based on the WLS approach to take into account heteroscedasticity and statistical properties of local estimates. One important advantage is that WLS estimates can be analytically provided, which allows us to study statistical properties of WLS estimates. Moreover, the WLS estimates are asymptotically equivalent to the ML estimates in large samples when the weights are consistently estimated, as explained in [158, 159].4.2. Statistical Modeling of RAW Images 53 4.2.2.1 WLS Estimation The RAW image Z is first transformed into the wavelet domain and then segmented into K non-overlapping homogeneous segments, denoted Sk, of size nk, k ∈ {1, . . . , K}. The readers are referred to [133] for more details of segmentation technique. In each segment Sk, pixels are assumed to be i.i.d, thus they have the same expectation and variance. Let z wapp k = (z wapp k,i )i∈{1,...,nk} and z wdet k = (z wdet k,i )i∈{1,...,nk} be respectively the vector of wavelet approximation coefficients and wavelet detail coefficients representing the segment Sk. Because the transformation is linear, the coefficients z wapp k,i and z wdet k,i also follow the Gaussian distribution z wapp k,i ∼ N µk, kϕk 2 2 σ 2 k
, (4.2) z wdet k,i ∼ N 0, σ2 k
, (4.3) where µk denotes expectation of all pixels in the segment Sk, σ 2 k = aµk + b, and ϕ is the 2-D normalized wavelet scaling function. Hence, the ML estimates of local expectation µk and local variance σ 2 k are given by µˆk = 1 nk Xnk i=1 z wapp k,i , (4.4) σˆ 2 k = 1 nk − 1 Xnk i=1 z wdet k,i − z wdet k
2 , with z wdet k = 1 nk Xnk i=1 z wdet k,i . (4.5) The estimate µˆk is unbiased and follows the Gaussian distribution µˆk ∼ N  µk, kϕk 2 2 nk σ 2 k  , (4.6) while the estimate σˆ 2 k follows a scaled chi-square distribution with nk − 1 degrees of freedom. This distribution can also be accurately approximated as the Gaussian distribution for large nk [160]: σˆ 2 k ∼ N  σ 2 k , 2 nk − 1 σ 4 k  , (4.7) Figure 4.1 illustrates a scatter-plot of all the pairs {(ˆµk, σˆ 2 k )} extracted from real natural RAW images of Nikon D70 and Nikon D200 cameras. The parameters (a, b) are estimated by considering all the pairs {(ˆµk, σˆ 2 k )} K k=1 where the local variance σˆ 2 k is treated as a heteroscedastic model of the local expectation µˆk. This model is formulated as follows σˆ 2 k = aµˆk + b + skk, (4.8) where k are independent and identically distributed as standard Gaussian variable and sk is a function of local mean µk. A direct calculation from (4.8) shows that s 2 k = Var σˆ 2 k − Var aµˆk + b = 2 nk − 1 σ 4 k − a 2 kϕk 2 2 nk σ 2 k = 2 nk − 1 (aµk + b) 2 − a 2 kϕk 2 2 nk (aµk + b). (4.9) Inférence d’invariants pour le model checking de systèmes paramétrés Alain Mebsout To cite this version: Alain Mebsout. Inf´erence d’invariants pour le model checking de syst`emes param´etr´es. Other. Universit´e Paris Sud - Paris XI, 2014. French. . HAL Id: tel-01073980 https://tel.archives-ouvertes.fr/tel-01073980 Submitted on 11 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Université Paris-Sud École Doctorale d’Informatiqe Laboratoire de Recherche en Informatiqe Discipline : Informatiqe Thèse de doctorat soutenue le 29 septembre 2014 par Alain Mebsout Inférence d’Invariants pour le Model Checking de Systèmes Paramétrés Directeur de thèse : M. Sylvain Conchon Professeur (Université Paris-Sud) Co-encadrante : Mme Fatiha Zaïdi Maître de conférences (Université Paris-Sud) Composition du jury : Président du jury : M. Philippe Dague Professeur (Université Paris-Sud) Rapporteurs : M. Ahmed Bouajjani Professeur (Université Paris Diderot) M. Silvio Ranise Chercheur (Fondazione Bruno Kessler) Examinateurs : M. Rémi Delmas Ingénieur de recherche (ONERA) M. Alan Schmitt Chargé de recherche (Inria Rennes)À Magali.Résumé Cette thèse aborde le problème de la vérication automatique de systèmes paramétrés complexes. Cette approche est importante car elle permet de garantir certaines propriétés sans connaître a priori le nombre de composants du système. On s’intéresse en particulier à la sûreté de ces systèmes et on traite le côté paramétré du problème avec des méthodes symboliques. Ces travaux s’inscrivent dans le cadre théorique du model checking modulo théories et ont donné lieu à un nouveau model checker : Cubicle. Une des contributions principale de cette thèse est une nouvelle technique pour inférer des invariants de manière automatique. Le processus de génération d’invariants est intégré à l’algorithme de model checking et permet de vérier en pratique des systèmes hors de portée des approches symboliques traditionnelles. Une des applications principales de cet algorithme est l’analyse de sûreté paramétrée de protocoles de cohérence de cache de taille industrielle. Enn, pour répondre au problème de la conance placée dans le model checker, on présente deux techniques de certication de notre outil Cubicle utilisant la plate-forme Why3. La première consiste à générer des certicats dont la validité est évaluée de manière indépendante tandis que la seconde est une approche par vérication déductive du cœur de Cubicle. Abstract This thesis tackles the problem of automatically verifying complex parameterized systems. This approach is important because it can guarantee that some properties hold without knowing a priori the number of components in the system. We focus in particular on the safety of such systems and we handle the parameterized aspect with symbolic methods. This work is set in the theoretical framework of the model checking modulo theories and resulted in a new model checker: Cubicle. One of the main contribution of this thesis is a novel technique for automatically inferring invariants. The process of invariant generation is integrated with the model checking algorithm and allows the verication in practice of systems which are out of reach for traditional symbolic approaches. One successful application of this algorithm is the safety analysis of industrial size parameterized cache coherence protocols. Finally, to address the problem of trusting the answer given by the model checker, we present two techniques for certifying our tool Cubicle based on the framework Why3. The rst consists in producing certicates whose validity can be assessed independently while the second is an approach by deductive verication of the heart of Cubicle. vRemerciements Mes remerciements vont en tout premier lieu à mes encadrants de thèse, qui m’ont accompagné tout au long de ces années. Ils ont su orienter mes recherches tout en m’accordant une liberté et une autonomie très appréciables. Les discussions aussi bien professionnelles que personnelles ont été très enrichissantes et leur bonne humeur a contribué à faire de ces trois (et cinq) années un plaisir. Merci à Fatiha pour sa disponibilité et son soutien. Je tiens particulièrement à remercier Sylvain d’avoir cru en moi et pour son optimisme constant. Il m’apparaît aujourd’hui que cette dernière qualité est essentielle à tout bon chercheur et j’espère en avoir tiré les enseignements. Merci également à mes rapporteurs, Ahmed Bouajjani et Silvio Ranise, d’avoir accepté de relire une version préliminaire de ce document et pour leurs corrections et remarques pertinentes. Je remercie aussi les autres examinateurs, Philippe Dague, Rémi Delmas et Alan Schmitt, d’avoir accepté de faire partie de mon jury. Le bon déroulement de cette thèse doit aussi beaucoup aux membres de l’équipe VALS (anciennement Proval puis Toccata). Ils ont su maintenir une ambiance chaleureuse et amicale tout au long des divers changements de noms, déménagements et remaniements politiques. Les galettes des rois, les gâteaux, les paris footballistiques, et les discussions du coin café resteront sans aucun doute gravés dans ma mémoire. Pour tout cela je les en remercie. Je tiens à remercier tout particulièrement Mohamed pour avoir partagé un bureau avec moi pendant près de cinq années. J’espère avoir été un aussi bon co-bureau qu’il l’a été, en tout cas les collaborations et les discussions autour d’Alt-Ergo furent très fructueuses. Merci également à Régine pour son aide dans la vie de doctorant d’un laboratoire de recherche et pour sa capacité à transformer la plus intimidante des procédures administratives en une simple tâche. Merci à Jean-Christophe, Guillaume, François, Andrei, Évelyne et Romain pour leurs nombreux conseils et aides techniques. Merci aussi à Sava Krstic et Amit Goel d’Intel pour ` leur coopération scientique autour de Cubicle. Enn un grand merci à toute ma famille pour leur soutien moral tout au long de ma thèse. Je souhaite remercier en particulier mes parents qui ont cru en moi et m’ont soutenu dans mes choix. Merci également à mes sœurs pour leurs nombreux encouragements. Pour nir je tiens à remercier ma moitié, Magali, pour son soutien sans faille et pour son aide. Rien de ceci n’aurait été possible dans elle. viiTable des matières Table des matières 1 Table des figures 5 Liste des Algorithmes 7 1 Introduction 9 1.1 Model checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.1 Systèmes nis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1.2 Systèmes innis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 Model checking de systèmes paramétrés . . . . . . . . . . . . . . . . . . . 14 1.2.1 Méthodes incomplètes . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.2 Fragments décidables . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.4 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Le model checker Cubicle 19 2.1 Langage d’entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.1 Algorithme d’exclusion mutuelle . . . . . . . . . . . . . . . . . . . 23 2.2.2 Généralisation de l’algorithme de Dekker . . . . . . . . . . . . . . 25 2.2.3 Boulangerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4 Cohérence de Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.3 Non-atomicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.4 Logique multi-sortée et systèmes à tableaux . . . . . . . . . . . . . . . . . 36 2.4.1 Syntaxe des formules logiques . . . . . . . . . . . . . . . . . . . . . 37 2.4.2 Sémantique de la logique . . . . . . . . . . . . . . . . . . . . . . . . 39 2.4.3 Systèmes de transition à tableaux . . . . . . . . . . . . . . . . . . . 41 2.5 Sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.5.1 Sémantique opérationnelle . . . . . . . . . . . . . . . . . . . . . . . 44 2.5.2 Atteignabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.5.3 Un interpréteur de systèmes à tableaux . . . . . . . . . . . . . . . . 47 1TABLE DES MATIÈRES 3 Cadre théorique : model checking modulo théories 49 3.1 Analyse de sûreté des systèmes à tableaux . . . . . . . . . . . . . . . . . . 50 3.1.1 Atteignabilité par chaînage arrière . . . . . . . . . . . . . . . . . . 50 3.1.2 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.1.3 Eectivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2 Terminaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.2.1 Indécidabilité de l’atteignabilité . . . . . . . . . . . . . . . . . . . . 57 3.2.2 Conditions pour la terminaison . . . . . . . . . . . . . . . . . . . . 59 3.2.3 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.3 Gardes universelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.3.1 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.3.2 Calcul de pré-image approximé . . . . . . . . . . . . . . . . . . . . 69 3.3.3 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.3.4 Relation avec le modèle de panne franche et la relativisation des quanticateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 3.4.1 Exemples sans existence d’un bel ordre . . . . . . . . . . . . . . . . 74 3.4.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4 Optimisations et implémentation 79 4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.2 Optimisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.1 Appels au solveur SMT . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.2 Tests ensemblistes . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.2.3 Instantiation ecace . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.3 Suppressions a posteriori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.4 Sous-typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.5 Exploration parallèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.6 Résultats et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5 Inférence d’invariants 105 5.1 Atteignabilité approximée avec retour en arrière . . . . . . . . . . . . . . . 107 5.1.1 Illustration sur un exemple . . . . . . . . . . . . . . . . . . . . . . 107 5.1.2 Algorithme abstrait . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.1.3 Algorithme complet pour les systèmes à tableaux . . . . . . . . . . 113 5.2 Heuristiques et détails d’implémentation . . . . . . . . . . . . . . . . . . . 117 5.2.1 Oracle : exploration avant bornée . . . . . . . . . . . . . . . . . . . 117 5.2.2 Extraction des candidats invariants . . . . . . . . . . . . . . . . . . 119 5.2.3 Retour en arrière . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 2TABLE DES MATIÈRES 5.2.4 Invariants numériques . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.2.5 Implémentation dans Cubicle . . . . . . . . . . . . . . . . . . . . . 124 5.3 Évaluation expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.4 Étude de cas : Le protocole FLASH . . . . . . . . . . . . . . . . . . . . . . . 130 5.4.1 Description du protocole FLASH . . . . . . . . . . . . . . . . . . . 131 5.4.2 Vérication du FLASH : État de l’art . . . . . . . . . . . . . . . . . 133 5.4.3 Modélisation dans Cubicle . . . . . . . . . . . . . . . . . . . . . . . 135 5.4.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.5 Travaux connexes sur les invariants . . . . . . . . . . . . . . . . . . . . . . 139 5.5.1 Génération d’invariants . . . . . . . . . . . . . . . . . . . . . . . . 139 5.5.2 Cutos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 5.5.3 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6 Certification 145 6.1 Techniques de certication d’outils de vérication . . . . . . . . . . . . . . 145 6.2 La plateforme de vérication déductive Why3 . . . . . . . . . . . . . . . . 147 6.3 Production de certicats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 6.3.1 Invariants inductifs pour l’atteignabilité arrière . . . . . . . . . . . 147 6.3.2 Invariants inductifs et BRAB . . . . . . . . . . . . . . . . . . . . . . 152 6.4 Preuve dans Why3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 7 Conclusion et perspectives 161 7.1 Résumé des contributions et conclusion . . . . . . . . . . . . . . . . . . . . 161 7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 A Syntaxe et typage des programmes Cubicle 165 A.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 A.2 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Bibliographie 173 Index 187 3Table des figures 2.1 Algorithme d’exclusion mutuelle . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2 Code Cubicle du mutex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 Graphe de Dekker pour le processus i . . . . . . . . . . . . . . . . . . . . . 26 2.4 Code Cubicle de l’algorithme de Dekker . . . . . . . . . . . . . . . . . . . . 27 2.5 Code Cubicle de l’algorithme de la boulangerie de Lamport . . . . . . . . . 29 2.6 Diagramme d’état du protocole German-esque . . . . . . . . . . . . . . . . 31 2.7 Code Cubicle du protocole de cohérence de cache German-esque . . . . . . 32 2.8 Évaluation non atomique des conditions globales par un processus i . . . . 34 2.9 Encodage de l’évaluation non atomique de la condition globale ∀j , i. c(j) 35 2.10 Grammaire de la logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1 Machine de Minsky à deux compteurs . . . . . . . . . . . . . . . . . . . . 58 3.2 Traduction d’un programme et d’une machine de Minsky dans un système à tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.3 Dénition des congurations M et N . . . . . . . . . . . . . . . . . . . . . 61 3.4 Plongement de M vers N . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.5 Séquence nie d’idéaux inclus calculée par l’algorithme 4 . . . . . . . . . . 64 3.6 Trace fallacieuse pour un système avec gardes universelles . . . . . . . . . 71 3.7 Transformation avec modèle de panne franche . . . . . . . . . . . . . . . . 72 3.8 Trace fallacieuse pour la transformation avec modèle de panne franche . . 73 3.9 Relations entre les diérentes approches pour les gardes universelles . . . 74 3.10 Séquence innie de congurations non comparables pour l’encodage des machines de Minksy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.11 Séquence innie de congurations non comparables pour une relation binaire quelconque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.12 Diérences de restrictions entre la théorie du model checking modulo théories et Cubicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.1 Architecture de Cubicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.2 Benchmarks et statistiques pour une implémentation naïve . . . . . . . . . 83 4.3 Arbre préxe représentant V . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.4 Benchmarks pour tests ensemblistes . . . . . . . . . . . . . . . . . . . . . . 87 5TABLE DES FIGURES 4.5 Benchmarks pour l’instantiation ecace . . . . . . . . . . . . . . . . . . . 91 4.6 Graphes d’atteignabilité arrière pour diérentes stratégies d’exploration sur l’exemple Dijkstra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.7 Suppression a posteriori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.8 Préservation de l’invariant après suppression d’un nœud . . . . . . . . . . 95 4.9 Benchmarks pour la suppression a posteriori . . . . . . . . . . . . . . . . . 95 4.10 Système Cubicle annoté avec les contraintes de sous-typage . . . . . . . . 97 4.11 Benchmarks pour l’analyse de sous-typage . . . . . . . . . . . . . . . . . . 98 4.12 Une mauvaise synchronisation des tests de subsomption eectués en parallèle 100 4.13 Utilisation CPU pour les versions séquentielle et parallèle de Cubicle . . . 101 4.14 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.1 Système de transition à tabeaux du protocole German-esque . . . . . . . . 108 5.2 Exécution partielle de BRAB sur le protocole German-esque . . . . . . . . 110 5.3 Transition sur un état avec variable non-initialisée . . . . . . . . . . . . . . 119 5.4 Apprentissage à partir d’une exploration supplémentaire avant redémarrage 122 5.5 Architecture de Cubicle avec BRAB . . . . . . . . . . . . . . . . . . . . . . 125 5.6 Résultats de BRAB sur un ensemble de benchmarks . . . . . . . . . . . . . 128 5.7 Architecture FLASH d’une machine et d’un nœud . . . . . . . . . . . . . . 130 5.8 Structure d’un message dans le protocole FLASH . . . . . . . . . . . . . . . 132 5.9 Description des transitions du protocole FLASH . . . . . . . . . . . . . . . 134 5.10 Résultats pour la vérication du protocole FLASH avec Cubicle . . . . . . 138 5.11 Protocoles de cohérence de cache hiérarchiques . . . . . . . . . . . . . . . 143 6.1 Invariants inductifs calculés par des analyses d’atteignabilité avant et arrière 148 6.2 Vérication du certicat Why3 de German-esque par diérents prouveurs automatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 6.3 Invariant inductif calculé par BRAB . . . . . . . . . . . . . . . . . . . . . . 154 6.4 Vérication par diérents prouveurs automatiques du certicat (Why3) de German-esque généré par BRAB . . . . . . . . . . . . . . . . . . . . . . . . 154 6.5 Vérication de certicats sur un ensemble de benchmarks . . . . . . . . . 155 6.6 Informations sur le développent Why3 . . . . . . . . . . . . . . . . . . . . 158 6.7 Aperçu d’une technique d’extraction . . . . . . . . . . . . . . . . . . . . . 159 A.1 Grammaire des chiers Cubicle . . . . . . . . . . . . . . . . . . . . . . . . 167 A.2 Règles de typage des termes . . . . . . . . . . . . . . . . . . . . . . . . . . 169 A.3 Règles de typage des formules . . . . . . . . . . . . . . . . . . . . . . . . . 170 A.4 Règles de typage des actions des transitions . . . . . . . . . . . . . . . . . 170 A.5 Vérication de la bonne formation des types . . . . . . . . . . . . . . . . . 171 A.6 Règles de typage des déclarations . . . . . . . . . . . . . . . . . . . . . . . 171 6Liste des Algorithmes 1 Code de Dekker pour le processus i . . . . . . . . . . . . . . . . . . . . . . . 26 2 Pseudo-code de la boulangerie de Lamport pour le processus i . . . . . . . . 29 3 Interpréteur d’un système à tableaux . . . . . . . . . . . . . . . . . . . . . . 47 4 Analyse d’atteignabilité par chaînage arrière . . . . . . . . . . . . . . . . . . 53 5 Test de satisabilité naïf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6 Analyse d’atteignabilité abstraite avec approximations et retour en arrière (BRAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7 Analyse d’atteignabilité avec approximations et retour en arrière (BRAB) . . 115 8 Oracle : Exploration avant limitée en profondeur . . . . . . . . . . . . . . . 116 71 Introduction Sommaire 1.1 Model checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.1 Systèmes nis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1.2 Systèmes innis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 Model checking de systèmes paramétrés . . . . . . . . . . . . . . . 14 1.2.1 Méthodes incomplètes . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.2 Fragments décidables . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.4 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Les systèmes informatiques sont aujourd’hui omniprésents, aussi bien dans les objets anodins de la vie courante que dans les systèmes critiques comme les contrôleurs automatiques utilisés par l’industrie aéronautique. Tous ces systèmes sont généralement très complexes, il est donc particulièrement dicile d’en construire qui ne comportent pas d’erreurs. On peut notamment constater le succès récent des architectures multi-cœurs, multi-processeurs et distribuées pour les serveurs haut de gamme mais aussi pour les terminaux mobiles personnels. Un des composants les plus complexes de telles machines est leur protocole de cohérence de cache. En vaut pour preuve le célèbre dicton : « Il y a seulement deux choses compliquées en informatique : l’invalidation des caches et nommer les choses. » — Phil Karlton En eet pour fonctionner de manière optimale chaque composant qui partage la mémoire (processeur, cœur, etc.) possède son propre cache (une zone mémoire temporaire) lui permettant de conserver les données auxquelles il a récemment accédé. Le protocole en question assure que tous les caches du système se trouvent dans un état cohérent, ce qui en 9Chapitre 1 Introduction fait un élément vital. Les méthodes les plus courantes pour garantir la qualité des systèmes informatiques sont le test et la simulation. Cependant, ces techniques sont très peu adaptées aux programmes concurrents comme les protocoles de cohérence de cache. Pour garantir une ecacité optimale, ces protocoles sont souvent implantés au niveau matériel et fonctionnent par échanges de messages, de manière entièrement asynchrone. Le moment auquel un message arrivera ou un processeur accédera à la mémoire centrale est donc totalement imprévisible [36]. Pour concevoir de tels systèmes on doit alors considérer de nombreuses « courses critiques » (ou race conditions en anglais), c’est-à-dire des comportements qui dépendent de l’ordre d’exécution ou d’arrivée des messages. Ces scénarios sont par ailleurs très compliqués, faisant intervenir plusieurs dizaines d’échanges de messages. Ainsi, la rareté de leurs apparitions fait qu’il est très dicile de reproduire ces comportements par des méthodes de test et de simulation. Une réponse à ce problème est l’utilisation de méthodes formelles pouvant garantir certaines propriétés d’un système par des arguments mathématiques. De nombreuses techniques revendiquent leur appartenance à cette catégorie, comme le model checking, qui s’attache à considérer tous les comportements possibles d’un système an d’en vérier diérentes propriétés. 1.1 Model checking La technique du model checking a été inventée pour résoudre le problème dicile de la vérication de programmes concurrents. Avant 1982, les recherches sur ce sujet intégraient systématiquement l’emploi de la preuve manuelle [131]. Pnueli [137], Owicki et Lamport [132] proposèrent, vers la n des années 70, l’usage de la logique temporelle pour spécier des propriétés parmi lesquelles : — la sûreté : un mauvais comportement ne se produit jamais, ou — la vivacité : un comportement attendu nira par arriver. Le terme model dans l’expression « model checking » peut faire référence à deux choses. Le premier sens du terme renvoie à l’idée qu’on va représenter un programme par un modèle abstrait. Appelons ce modèle M. Le deuxième sens du terme fait référence au fait qu’on va ensuite essayer de vérier des propriétés de M, autrement dit que M est un modèle de ces propriétés. Le model checking implique donc de dénir « simplement » ce qu’est (1) un modèle, et (2) une propriété d’un modèle. 1. Un modèle doit répondre aux trois questions suivantes : a) À tout instant, qu’est-ce qui caractérise l’état d’un programme ? b) Quel est l’état initial du système ? c) Comment passe-t-on d’un état à un autre ? 101.1 Model checking 2. Les propriétés qu’on cherche à vérier sont diverses : Est-ce qu’un mauvais état peut être atteint (à partir de l’état inital) ? Est-ce qu’un certain état sera atteint quoiqu’il advienne ? Plus généralement, on souhaite vérier des propriétés qui dépendent de la manière dont le programme (ou le modèle) évolue. On exprime alors ces formules dans des logiques temporelles. 1.1.1 Systèmes finis Les travaux fondateurs de Clarke et Emerson [38] et de Queille et Sifakis [140] intègrent cette notion de logique temporelle à l’exploration de l’ensemble des états du système (espace d’état). Dans leur article de 1981 [38], Clarke et Emerson montrent comment synthétiser des programmes à partir de spécications dans une logique temporelle (appelée CTL, pour Computational Tree Logic). Mais c’est surtout la seconde partie de l’article qui a retenu l’attention de la communauté. Dans celle-ci, ils construisent une procédure de décision fondée sur des calculs de points-xes pour vérier des propriétés temporelles de programmes nis. L’avantage principal du model checking par rapport aux autres techniques de preuve est double. C’est d’abord un processus automatique et rapide, de sorte qu’il est souvent considéré comme une technique « presse-bouton ». C’est aussi une méthode qui fonctionne déjà avec des spécications partielles. De cette façon, l’eort de vérication peut être commencé tôt dans le processus de conception d’un système complexe. Un de ses désavantages, qui est aussi inhérent à toutes les autres techniques de vérication, est que la rédaction des spécications est une tâche dicile qui requiert de l’expertise. Mais l’inconvénient majeur du model checking est apparu dans les années 80, et est connu sous le nom du phénomène d’explosion combinatoire de l’espace d’états. Seuls les systèmes avec un nombre petit d’états (de l’ordre du million) pouvaient être analysés à cette époque, alors que les systèmes réels en possèdent beaucoup plus. Par conséquent, un important corpus de recherche sur le model checking aborde le problème du passage à l’échelle. Une avancée notoire pour le model checking a été l’introduction de techniques symboliques pour résoudre ce problème d’explosion. Alors que la plupart des approches avant 1990 utilisaient des représentations explicites, où chaque état individuel est stocké en mémoire, Burch et al. ont montré qu’il était possible de représenter de manière symbolique et compacte des ensembles d’états [29]. McMillan reporte dans sa thèse [116] une représentation de la relation des états de transition avec BDD [27] (diagrammes de décision binaire) puis donne un nombre d’algorithmes basés sur des graphes dans le langage du µ-calcul. L’utilisation de structures de données compactes pour représenter de larges ensembles d’états permet de saisir certaines des régularités qui apparaissent naturellement dans les circuits ou autres systèmes. La complexité en espace du model checking symbolique a été grandement diminuée et, pour la première fois, des systèmes avec 1020 états ont été vériés. Cette limite a encore été repoussée avec divers ranements du model checking 11Chapitre 1 Introduction symbolique. Le point faible des techniques symboliques utilisant des BDD est que la quantité d’espace mémoire requise pour stocker ces structures peut augmenter de façon exponentielle. Biere et al. décrivent une technique appelée le model checking borné (ou BMC pour Bounded Model Checking) qui sacrie la correction au prot d’une recherche d’anomalies ecace [19]. L’idée du BMC est de chercher les contre-exemples parmi les exécutions du programme dont la taille est limitée à un certain nombre d’étapes k. Ce problème peut être encodé ecacement en une formule propositionnelle dont la statisabilité mène directement à un contre-exemple. Si aucune erreur n’est trouvée pour des traces de longueur inférieure à k, alors la valeur de la borne k est augmentée jusqu’à ce qu’une erreur soit trouvée, ou que le problème devienne trop dicile à résoudre 1 . La force de cette technique vient principalement de la mise à prot des progrès fait par les solveurs SAT (pour la satisabilité booléenne) modernes. Elle a rencontré un succès majeur dans la vérication d’implémentations de circuits matériels et fait aujourd’hui partie de l’attirail standard des concepteurs de tels circuits. Comme l’encodage vers des contraintes propositionnelles capture la sé- mantique des circuits de manière précise, ces model checkers ont permis de découvrir des erreurs subtiles d’implémentation, dues par exemple à la présence de débordements arithmétiques. Une extension de cette technique pour la preuve de propriétés, plutôt que la seule recherche de bogues, consiste à ajouter une étape d’induction. Cette extension de BMC s’appelle la k-induction et dière d’un schéma d’induction classique par le point suivant : lorsqu’on demande à vérier que la propriété d’induction est préservée, on suppose qu’elle est vraie dans les k étapes précédentes plutôt que seulement dans l’étape précédente [52, 151]. Une autre vision du model checking est centrée sur la théorie des automates. Dans ces approches, spécications et implémentations sont toutes deux construites avec des automates. Vardi et Wolper notent une correspondance entre la logique temporelle et les automates de Büchi [164] : chaque formule de logique temporelle peut être considérée comme un automate à états ni (sur des mots innis) qui accepte précisément les séquences satisfaites par la formule. Grâce à cette connexion, ils réduisent le problème du model checking à un test de vacuité de l’automate AM ∩A¬φ (où AM est l’automate du programme M et A¬φ est l’automate acceptant les séquences qui violent la propriété φ) [161]. 1.1.2 Systèmes infinis Le problème d’explosion combinatoire est encore plus frappant pour des systèmes avec un nombre inni d’états. C’est le cas par exemple lorsque les types des variables du 1. Dans certains cas un majorant sur la borne k est connu (le seuil de complétion) qui permet d’armer que le système vérie la propriété donnée. 121.1 Model checking programme sont innis (e.g. entiers mathématiques) ou les structures de données sont innies (e.g. buers, les d’attente, mémoires non bornés). Pour traiter de tels systèmes, deux possibilités s’orent alors : manipuler des représentations d’ensembles d’états innis directement, ou construire une abstraction nie du système. Dans la première approche, des représentations symboliques adaptées reposent par exemple sur l’utilisation des formules logiques du premier ordre. Pour cela, les techniques utilisant précédemment les solveurs SAT (traitant exclusivement de domaines nis encodés par de la logique propositionnelle) ont été peu à peu migrées vers les solveurs SMT (Satisabilité Modulo Théories). Ces derniers possèdent un moteur propositionnel (un solveur SAT) couplé à des méthodes de combinaison de théories. La puissance de ces solveurs vient du grand nombre de théories qu’ils supportent en interne, comme la théorie de l’arithmétique linéaire (sur entiers mathématiques), la théorie de l’égalité et des fonctions non interprétées, la théorie des tableaux, la théorie des vecteurs de bits, la théorie des types énumérés, etc. Certains solveurs SMT supportent même les quanticateurs. Par exemple, une application récente de la technique de k-induction aux programmes Lustre (un langage synchrone utilisé notamment dans l’aéronautique) utilisant des solveurs SMT est disponible dans le model checker Kind [85, 86]. La seconde approche pour les systèmes innis – qui peut parfois être utilisée en complément de la technique précédente – consiste à sacrier la précision de l’analyse en simpliant le problème an de se ramener à l’analyse d’un système ni. La plupart de ces idées émergent d’une certaine manière du cadre de l’interprétation abstraite dans lequel un programme est interprété sur un domaine abstrait [46,47]. Une forme d’abstraction particulière est celle de l’abstraction par prédicats. Dans cette approche, la fonction d’abstraction associe chaque état du système à un ensemble prédéni de prédicats. L’utilisateur fournit des prédicats booléens en nombre ni pour décrire les propriétés possibles d’un système d’états innis. Ensuite une analyse d’accessibilité est eectuée sur le modèle d’états nis pour fournir l’invariant le plus fort possible exprimable à l’aide de ces prédicats [81]. Généralement, les abstractions accélèrent la procédure de model checking lorsqu’elles sont les plus générales possibles. Parfois trop grossières, ces abstractions peuvent empêcher l’analyse d’un système pourtant sûr en exposant des contre-exemples qui n’en sont pas dans le système réel. Il devient alors intéressant de raner le domaine abstrait utilisé précédemment de manière automatique an d’éliminer ces mauvais contre-exemples. Cette idée a donné naissance à la stratégie itérative appelée CEGAR (pour Counter-Example Guided Abstraction Renement, i.e. ranement d’abstraction guidé par contre-exemples) [13, 35, 147]. Elle est utilisée par de nombreux outils et plusieurs améliorations ont été proposées au l des années. On peut mentionner par exemple les travaux de Jahla et al. [89, 94] sur l’abstraction paresseuse implémentés dans le model checker Blast [18] ainsi que ceux de McMillan [119] qui combine cette technique avec un ranement par interpolation de Craig [48] permettant ainsi de capturer les relations entre variables utiles à la preuve de la propriété souhaitée. 13Chapitre 1 Introduction Un système peut aussi être inni, non pas parce que ses variables sont dans des domaines innis, mais parce qu’il est formé d’un nombre non borné de composants. Par exemple, un protocole de communication peut être conçu pour fonctionner quelque soit le nombre de machines qui y participent. Ces systèmes sont dits paramétrés, et c’est le problème de leur vérication qui nous intéresse plus particulièrement dans cette thèse. 1.2 Model checking de systèmes paramétrés Un grand nombre de systèmes réels concurrents comme le matériel informatique ou les circuits électroniques ont en fait un nombre ni d’états possibles (déterminés par la taille des registres, le nombre de bascules, etc.). Toutefois, ces circuits et protocoles (e.g. les protocoles de bus ou les protocoles de cohérence de cache) sont souvent conçus de façon paramétrée, dénissant ainsi une innité de systèmes. Un pour chaque nombre de composants. Souvent le nombre de composants de tels systèmes n’est pas connu à l’avance car ils sont conçus pour fonctionner quelque soit le nombre de machines du réseau, quelque soit le nombre de processus ou encore quelque soit la taille des buers (mémoires tampons). En vérier les propriétés d’une manière paramétrée est donc indispensable pour s’assurer de leur qualité. Dans d’autres cas ce nombre de composants est connu mais il est tellement grand (plusieurs milliers) que les techniques traditionnelles sont tout bonnement incapables de raisonner avec de telles quantités. Il est alors préférable dans ces circonstances de vérier une version paramétrée du problème. Apt et Kozen montrent en 1986 que, de manière générale, savoir si un programme P paramétré par n, P (n) satisfait une propriété φ(n), est un problème indécidable [10]. Pour mettre en lumière ce fait, ils ont simplement créé un programme qui simule n étapes d’une machine de Turing et change la valeur d’une variable booléenne à la n de l’exécution si la machine simulée ne s’est pas encore arrêtée 2 . Ce travail expose clairement les limites intrinsèques des systèmes paramétrés. Même si le résultat est négatif, la vérication automatique reste possible dans certains cas. Face à un problème indécidable, il est coutume de restreindre son champ d’application en imposant certaines conditions jusqu’à tomber dans un fragment décidable. Une alternative consiste à traiter le problème dans sa globalité, mais avec des méthodes non complètes. 1.2.1 Méthodes incomplètes Le premier groupe à aborder le problème de la vérication paramétrée fut Clarke et Grumberg [39] avec une méthode fondée sur un résultat de correspondance entre des 2. Ce programme est bien paramétré par n. Bien qu’il ne fasse pas intervenir de concurrence, le résultat qui suit peut être aussi bien obtenu en mettant n processus identiques P (n) en parallèle. 141.2 Model checking de systèmes paramétrés systèmes de diérentes tailles. Notamment, ils ont pu vérier avec cette technique un algorithme d’exclusion mutuelle en mettant en évidence une bisimulation entre ce système de taille n et un système de taille 2. Toujours dans l’esprit de se ramener à une abstraction nie, de nombreuses techniques suivant ce modèle ont été développées pour traiter les systèmes paramétrés. Par exemple Kurshan et McMillan utilisent un unique processus Q qui agrège les comportements de n processus P concurrents [105]. En montrant que Q est invariant par composition parallèle asynchrone avec P, on déduit que Q représente bien une abstraction du système paramétré. Bien souvent l’enjeu des techniques utilisées pour vérier des systèmes paramétrés est de trouver une représentation à même de caractériser des familles innies d’états. Par exemple si la topologie du système (i.e. l’organisation des processus) n’a pas d’importance, il est parfois susant de « compter » le nombre de processus se trouvant dans un état particulier. C’est la méthode employée par Emerson et al. dans l’approche dite d’abstraction par compteurs [64]. Si l’ordre des processus importe (e.g. un processus est situé « à gauche » d’un autre) une représentation adaptée consiste à associer à chaque état un mot d’un langage régulier. Les ensembles d’états sont alors représentés par les expressions régulières de ce langage et certaines relations de transition peuvent être exprimées par des transducteurs nis [1, 99]. Une généralisation de cette idée a donné naissance au cadre du model checking régulier [24] qui propose des techniques d’accélération pour calculer les clôtures transitives [96, 128]. Des extensions de ces approches ont aussi été adaptées à l’analyse de systèmes de topologies plus complexes [22]. Plutôt que de chercher à construire une abstraction nie du système paramétré dans son intégralité, l’approche dite de cuto (coupure) cherche à découvrir une borne supérieure dépendant à la fois du système et de la propriété à vérier. Cette borne k, appelée la valeur de cuto, est telle que si la propriété est vraie pour les système plus petits que k alors elle est aussi vraie pour les systèmes de taille supérieure à k [62]. Parfois cette valeur peut-être calculée statiquement à partir des caractéristiques du système. C’est l’approche employée dans la technique des invariants invisibles de Pnueli et al. alliée à une génération d’invariants inductifs [12, 138]. L’avantage de la technique de cuto est qu’elle s’applique à plusieurs formalismes et qu’elle permet simplement d’évacuer le côté paramétré d’un problème. En revanche le calcul de cette borne k donne souvent des valeurs rédhibitoires pour les systèmes de taille réelle. Pour compenser ce désavantage, certaines techniques ont été mises au point pour découvrir les bornes de cuto de manière dynamique [4, 98]. 1.2.2 Fragments décidables Il est généralement dicile d’identier un fragment qui soit à la fois décidable et utile en pratique. Certaines familles de problèmes admettent cependant des propriétés qui en font des cadres théoriques intéressants. Partant du constat que les systèmes synchrones sont souvent plus simples à analyser, Emerson et Namjoshi montrent que certaines propriétés 15Chapitre 1 Introduction temporelles sont en fait decidables pour ces systèmes [63]. Leur modèle fonctionne pour les systèmes composés d’un processus de contrôle et d’un nombre arbitraire de processus homogènes. Il ne s’applique donc pas, par exemple, aux algorithmes d’exclusion mutuelle. L’écart de méthodologie qui existe entre les méthodes non complètes et celles qui identient un fragment décidable du model checking paramétré n’est en réalité pas si grand. Dans bien des cas, les chercheurs qui mettent au point ces premières mettent aussi en évidence des restrictions susantes sur les systèmes considérés pour rendre l’approche complète et terminante. C’est par exemple le cas des techniques d’accélération du model checking régulier ou encore celui du model checking modulo théories proposé par Ghilardi et Ranise [77, 79]. À la diérence des techniques pour systèmes paramétrés mentionnées précédemment, cette dernière approche ne construit pas d’abstraction nie mais repose sur l’utilisation de quanticateurs pour représenter les ensembles innis d’états de manière symbolique. En eet lorsqu’on parle de systèmes paramétrés, on exprime naturellement les propriétés en quantiant sur l’ensemble des éléments du domaine paramétré. Par exemple, dans un système où le nombre de processus n’est pas connu à l’avance, on peut avoir envie de garantir que quelque soit le processus, sa variable locale x n’est jamais nulle. Le cadre du model checking modulo théories dénit une classe de systèmes paramétrés appelée systèmes à tableaux permettant de maîtriser l’introduction des quanticateurs. La sûreté de tels systèmes n’est pas décidable en général mais il existe des restrictions sur le problème d’entrée qui permettent de construire un algorithme complet et terminant. Un autre avantage de cette approche est de tirer parti de la puissance des solveurs SMT et de leur grande versatilité. Toutes ces techniques attaquent un problème intéressant et important. Celles qui sont automatiques (model checking) ne passent pourtant pas à l’échelle sur des problèmes réalistes. Et celles qui sont applicables en pratique demandent quant à elles une expertise humaine considérable, ce qui rend le processus de vérication très long [33,49,118,134,135]. Le problème principal auquel répond cette thèse est le suivant. Comment vérier automatiquement des propriétés de sûreté de systèmes paramétrés complexes ? Pour répondre à cette question, on utilise le cadre théorique du model checking modulo théories pour concevoir de nouveaux algorithmes qui infèrent des invariants de manière automatique. Nos techniques s’appliquent avec succès à l’analyse de sûreté paramétrée de protocoles de cohérence de cache conséquents, entre autres. 1.3 Contributions Nos contributions sont les suivantes : 161.4 Plan de la thèse — Un model checker open source pour systèmes paramétrés : Cubicle. Cubicle implémente les techniques présentées dans cette thèse et est librement disponible à l’adresse suivante : http://cubicle.lri.fr. — Un ensemble de techniques pour l’implémentation d’un model checker reposant sur un solveur SMT. — Un nouvel algorithme pour inférer des invariants de qualité de manière automatique : BRAB. L’idée de cet algorithme est d’utiliser les informations extraites d’un modèle ni du système an d’inférer des invariants pour le cas paramétré. Le modèle ni est en fait mis à contribution en tant qu’oracle dont le rôle se limite à émettre un jugement de valeur sur les candidats invariants qui lui sont présentés. Cet algorithme fonctionne bien en pratique car dans beaucoup de cas les instances nies, même petites, exhibent déjà la plupart des comportements intéressants du système. — Une implémentation de BRAB dans le model checker Cubicle. — L’application de ces techniques à la vérication du protocole de cohérence de cache de l’architecture multi-processeurs FLASH. À l’aide des invariants découverts par BRAB, la sûreté de ce protocole a pu être vériée entièrement automatiquement pour la première fois. — Deux approches pour la certication de Cubicle à l’aide de la plate-forme Why3. La première est une approche qui fonctionne par certicats (ou traces) et vérie le résultat produit par le model checker. Ce certicat prend la forme d’un invariant inductif. La seconde approche est par vérication déductive du cœur de Cubicle. Ces deux approches mettent en avant une autre qualité de BRAB : faciliter ce processus de certication, par réduction de la taille des certicats pour l’une, et grâce à son ecacité pour l’autre. 1.4 Plan de la thèse Ce document de thèse est organisé de la façon suivante : Le chapitre 2 introduit le langage d’entrée du model checker Cubicle à travers diérents exemples d’algorithmes et de protocoles concurrents. Une seconde partie de ce chapitre présente la représentation formelle des systèmes de transitions utilisés par Cubicle ainsi que leur sémantique. Le chapitre 3 présente le cadre théorique du model checking modulo théories conçu par Ghilardi et Ranise. Les résultats et théorèmes associés sont également donnés et illustrés dans ce chapitre, qui constitue le contexte dans lequel s’inscrivent nos travaux. Le chapitre 4 donne un ensemble d’optimisations nécessaires à l’implémentation d’un model checker reposant sur un solveur SMT comme Cubicle. Nos travaux autour de l’inférence d’invariants sont exposés dans le chapitre 5. On y présente et illustre l’algorithme BRAB. Les détails pratiques de son fonctionnement sont également expliqués et son intérêt est appuyé par une 17Chapitre 1 Introduction évaluation expérimentale sur des problèmes diciles pour la vérication paramétrée. En particulier on détaille le résultat de la preuve du protocole de cohérence de cache FLASH. Le chapitre 6 présente deux techniques de certication que nous avons mis en œuvre pour certier le model checker Cubicle. Ces deux techniques reposent sur la plate-forme de vérication déductive Why3. Enn le chapitre 7 donne des pistes d’amélioration et d’extension de nos travaux et conclut ce document. 182 Le model checker Cubicle Sommaire 2.1 Langage d’entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.1 Algorithme d’exclusion mutuelle . . . . . . . . . . . . . . . . . 23 2.2.2 Généralisation de l’algorithme de Dekker . . . . . . . . . . . . 25 2.2.3 Boulangerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4 Cohérence de Cache . . . . . . . . . . . . . . . . . . . . . . . . 30 2.3 Non-atomicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.4 Logique multi-sortée et systèmes à tableaux . . . . . . . . . . . . . 36 2.4.1 Syntaxe des formules logiques . . . . . . . . . . . . . . . . . . . 37 2.4.2 Sémantique de la logique . . . . . . . . . . . . . . . . . . . . . . 39 2.4.3 Systèmes de transition à tableaux . . . . . . . . . . . . . . . . . 41 2.5 Sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.5.1 Sémantique opérationnelle . . . . . . . . . . . . . . . . . . . . . 44 2.5.2 Atteignabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.5.3 Un interpréteur de systèmes à tableaux . . . . . . . . . . . . . . 47 L’outil issu des travaux présentés dans ce document est un model checker pour systèmes paramétrés, dénommé Cubicle. Le but de ce chapitre est de familiariser le lecteur avec l’outil, tout particulièrement son langage d’entrée et sa syntaxe concrète. Quelques exemples variés de tels systèmes sont formulés dans ce langage an d’orir un premier aperçu des possibilités du model checker. On donne également une description plus formelle de la sémantique des systèmes décrits dans le langage de Cubicle. 19Chapitre 2 Le model checker Cubicle 2.1 Langage d’entrée Cubicle est un model checker pour systèmes paramétrés. C’est-à-dire qu’il permet de vérier statiquement des propriétés de sûreté d’un programme concurrent pour un nombre quelconque de processus 1 . Pour représenter ces programmes, on utilise des systèmes de transition car ils permettent facilement de modéliser des comportements asynchrones ou non déterministes. Ces systèmes décrivent les transitions possibles d’un état du programme à un autre. Ils peuvent être considérés comme un langage bas niveau pour la vérication. Étant donné que les systèmes manipulés par Cubicle sont paramétrés, les transitions qui le composent le sont également. Dans cette section, on présente de manière très informelle le langage d’entrée de Cubicle 2 . La description d’un système commence par des déclarations de types, de variables globales et de tableaux. Cubicle connaît quatre types en interne : le type des entiers (int), le type des réels (real), le type des booléens (bool) et le type des identicateurs de processus (proc). Ce dernier est particulièrement important car c’est par les éléments de ce type que le système est paramétré. Le paramètre du système est la cardinalité du type proc. L’utilisateur a aussi la liberté de déclarer ses propres types abstraits ou ses propres types énumérés. L’exemple suivant dénit un type énuméré state à trois constructeurs Idle, Want et Crit ainsi qu’un type abstrait data. type state = Idle | Want | Crit type data Les tableaux et variables représentent l’état du système ou du programme. Tous les tableaux ont la particularité d’être uniquement indexés par des éléments du type proc, leur taille est par conséquent inconnue. C’est une limitation de l’implémentation actuelle du langage de Cubicle qui existe pour des raisons pratiques et rien n’empêcherait d’ajouter la possibilité de déclarer des tableaux indexés par des entiers. Dans ce qui suit on déclare une variable globale Timer de type real et trois tableaux indexés par le type proc. var Timer : real array State[proc] : state array Chan[proc] : data array Flag[proc] : bool Les tableaux peuvent par exemple être utilisés pour représenter des variables locales ou des canaux de communication. 1. Un programme concurrent est souvent paramétré par son nombre de processsus ou threads mais ce paramètre peut aussi être la taille de certains buers ou le nombre de canaux de communication par exemple. 2. Une description plus précise de la syntaxe et de ce langage est faite en annexe A de ce document. 202.1 Langage d’entrée Les états initiaux du système sont dénis à l’aide du mot clef init. Cette déclaration qui vient en début de chier précise quelles sont les valeurs initiales des variables et tableaux pour tous leurs indices. Notons que certaines variables peuvent ne pas être initialisées et on a le droit de mentionner seulement les relations entres elles. Dans ce cas tout état dont les valeurs des variables et tableaux respectent les contraintes xées dans la ligne init sera un état initial correct du système. Par exemple, la ligne suivante dénit les états initiaux comme ceux ayant leurs tableaux Flag à false et State à Idle pour tout processus z, ainsi que leur variable globale Timer valant 0.0. Le paramètre z de init représente tous les processus du système. init (z) { Flag[z] = False && State[z] = Idle && Timer = 0.0 } Remarque. On ne précise pas le type des paramètres car seuls ceux du type proc sont autorisés Le reste du système est donné comme un ensemble de transitions de la forme garde/action. Chaque transition peut être paramétrée (ou non) par un ou plusieurs identicateurs de processus comme dans l’exemple suivant. transition t (i j) requires { i < j && State[i] = Idle && Flag[i] = False && forall_other k. (Flag[k] = Flag[j] || State[k] <> Want) } { Timer := Timer + 1.0; Flag[i] := True; State[k] := case | k = i : Want | State[k] = Crit && k < i : Idle | _ : State[k]; } Dans cet exemple, la transition t est déclenchable s’il existe deux processus distincts d’identicateurs i et j tels que i est inférieur à j. Les tableaux State et Flag doivent contenir respectivement la valeur Idle et la valeur false à l’indice i. En plus de cette garde locale (aux processus i et j), on peut mentionner l’état des autres processus du système. La partie globale de la garde est précédée du mot clef forall_other. Ici, on dit que tous les autres processus (sous-entendu diérents de i et j) doivent soit avoir la même valeur de Flag que j, soit contenir une valeur diérente de Want dans le tableau State. Remarque. Dans Cubicle, les processus sont diérenciés par leur identicateurs. Ici, les paramètres i et j de la transition sont implicitement quantiés existentiellement et doivent 21Chapitre 2 Le model checker Cubicle être des identicateurs de processus deux à deux distincts. L’ensemble des identicateurs de processus est seulement muni d’un ordre total. La présence de cet ordre induit une topologie linéaire sur les processus. La comparaison entre identicateurs est donc autorisée et on peut par exemple écrire i < j dans une garde. La garde de la transition est donnée par le mot clef requires. Si elle est satisfaite, les actions de la transition sont exécutées. Chaque action est une mise à jour d’une variable globale ou d’un tableau. La sémantique des transitions veut que l’ensemble des mises à jour soit réalisé de manière atomique et chaque variable qui apparaît à droite d’un signe := dénote la valeur de cette variable avant la transition. L’ordre des aectations n’a donc pas d’importance. La première action Timer := Timer + 1.0 incrémente la variable globale de 1 lorsque la transition est prise. Les mises à jour de tableaux peuvent être codées comme de simples aectations si une seule case est modiée. L’action Flag[i] := True modie le tableau Flag à l’indice i en y mettant la valeur true. Le reste du tableau n’est pas modié. Si la transition modie plusieurs cases d’un même tableau, on utilise une construction case qui précise les nouvelles valeurs contenues dans le tableau à l’aide d’un ltrage. State[k] := case ... mentionne ici les valeurs du tableau State pour tous les indices k (k doit être une variable fraîche) selon les conditions suivantes. Pour chaque indice k, le premier cas possible du ltrage est exécuté. Le cas | k = i : Want nous demande de vérier tout d’abord si k vaut i, c’est-à-dire de mettre de la valeur Want à l’indice i du tableau State. Le deuxième cas | State[k] = Crit && k < i : Idle est plus compliqué : si le premier cas n’est pas vérié (i.e. k est diérent de i), que State contenait Crit à l’indice k, et que k est inférieur à i alors la nouvelle valeur de State[k] est Idle. Plus simplement, cette ligne change les valeurs Crit du tableau State se trouvant à gauche de i (k < i) en Idle. Enn tous les ltrages doivent se terminer par un cas par défaut noté _. Dans notre exemple, le cas par défaut du ltrage | _ : State[k] dit que toutes les autres valeurs du tableau restent inchangées (on remet l’ancienne valeur de State[k]). La relation de transition, décrite par l’ensemble des transitions, dénit l’exécution du système comme une boucle innie qui à chaque itération : 1. choisit de manière non déterministe une instance de transition dont la garde est vraie dans l’état courant du système ; 2. met à jour les variables et tableaux d’état conformément aux actions de la transition choisie. 222.2 Exemples Les propriétés de sûreté à vérier sont exprimées sous forme négative, c’est-à-dire qu’on caractérise les états dangereux du système. On les exprime dans Cubicle à l’aide du mot clef unsafe, éventuellement suivi d’un ensemble de variables de processus distinctes. La formule dangereuse suivante exprime que les mauvais états du système sont ceux où il existe au moins deux processus distincts x et y tels que le tableau State contienne la valeur Crit à ces deux indices. unsafe (x y) { State[x] = Crit && State[y] = Crit } On dira qu’un système est sûr si aucun des états dangereux ne peut être atteint à partir d’un des états initiaux. Remarque. Bien que Cubicle soit conçu pour vérier des systèmes paramétrés, il est tout de même possible de l’utiliser pour vérier des systèmes dont le nombre de processus est xé à l’avance. Pour cela, il sut d’inclure la ligne “number_procs n” dans le chier, où n est le nombre de processus. Dans ce cas, on pourra mentionner explicitement les processus 1 à n en utilisant les constantes #1 à #n. Remarque. Le langage d’entrée de Cubicle est une version moins riche mais paramétrée du langage de Murφ [57] et similaire à Uclid [28]. Bien que limité pour l’instant, il est assez expressif pour permettre de décrire aisément des systèmes paramétrés conséquents (75 transitions, 40 variables et tableaux pour le protocole FLASH [106] par exemple). 2.2 Exemples Dans cette section, on montre comment utiliser Cubicle et son expressivité pour modéliser diérents algorithmes et protocoles de la littérature. Ces exemples sont donnés à titre didactique et sont choisis de manière à illustrer les caractéristiques fondamentales du langage. Le but de cette section est de donner au lecteur une bonne intuition des possibilités oertes par l’outil de manière à pouvoir modéliser et expérimenter le model checker sur ses propres exemples. 2.2.1 Algorithme d’exclusion mutuelle L’exclusion mutuelle est un problème récurrent de la programmation concurrente. L’algorithme décrit ci-dessous résout ce problème, i.e. il permet à plusieurs processus de partager une ressource commune à accès unique sans conit, en communiquant seulement au travers de variables partagées. C’est une version simpliée de l’algorithme de Dekker (présenté en 2.2.2) qui fonctionne pour un nombre arbitraire de processus identiques. Sur la gure 2.1, on matérialise n processus concurrents qui exécutent tous le même protocole. Chaque processus est représenté par le graphe de transition entre ses états : Idle, 23Chapitre 2 Le model checker Cubicle Process 1 Idle Want Crit Turn = 1 Turn := ? Process 2 Idle Want Crit Turn = 2 Turn := ? Process n Idle Want Crit Turn = n Turn := ? . . . Process 3 Idle Want Crit Turn = 3 Turn := ? Figure 2.1 – Algorithme d’exclusion mutuelle Want, et Crit, l’état initial étant Idle. Un processus peut demander l’accès à la section critique à tout moment en passant dans l’état Want. La synchronisation est eectuée au travers de la seule variable partagée Turn. La priorité est donnée au processus dont l’identiant i est contenu dans la variable Turn, qui peut dans ce cas passer en section critique. Un processus en section critique peut en sortir sans contrainte si ce n’est celle de « donner la main » à un de ses voisins en changeant la valeur de Turn. Cette dernière est modiée de façon non-déterministe (Turn := ? dans le schéma), donc rien n’interdit à un processus de se redonner la main lui-même. La propriété qui nous intéresse ici est de vérier la sûreté du système, c’est-à-dire qu’à tout moment, au plus un processus est en section critique. Le code Cubicle correspondant à ce problème est donné ci-dessous en gure 2.2. Pour modéliser l’algorithme on a choisi de représenter l’état des processus par un tableau State contenant les valeur Idle, Want, ou Crit. On peut aussi voir State[i] comme la valeur d’une variable locale au processus d’identicateur i. La variable partagée Turn est simplement une variable globale au système. On dénit les états initiaux comme ceux où tous les processus sont dans l’état Idle, quelque soit la valeur initiale de la variable Turn. Prenons l’exemple de la transition req. Elle correspond au moment où un processus demande l’accès à la section critique, passant de l’état Want à Idle. Elle se lit : la transition req est possible s’il existe un processus d’identiant i tel que State[i] a pour valeur Idle. Dans ce cas, la case State[i] prend pour valeur Want. La formule unsafe décrit les mauvais états du système comme ceux dans lesquels il existe (au moins) deux processus distincts en section critique (i.e. pour lesquels la valeur de State est Crit). Autrement dit, on veut s’assurer que la formule suivante est un invariant du système : ∀i,j. (i , j ∧ State[i] = Crit) =⇒ State[j] , Crit 242.2 Exemples mutex.cub type state = Idle | Want | Crit array State[proc] : state var Turn : proc init (z) { State[z] = Idle } unsafe (z1 z2) { State[z1] = Crit && State[z2] = Crit } transition req (i) requires { State[i] = Idle } { State[i] := Want } transition enter (i) requires { State[i] = Want && Turn = i } { State[i] := Crit; } transition exit (i) requires { State[i] = Crit } { Turn := ? ; State[i] := Idle; } Figure 2.2 – Code Cubicle du mutex Pour vérier que le système décrit dans le chier mutex.cub précédent est sûr, la manière la plus simple d’invoquer Cubicle est de lui passer seulement le nom de chier en argument : cubicle mutex.cub On peut voir ci-après la trace émise par le model checker sur la sortie standard. Lorsque ce dernier ache sur la dernière ligne “The system is SAFE”, cela signie qu’il a été en mesure de vérier que l’état unsafe n’est jamais atteignable dans le système. node 1: unsafe[1] 5 (2+3) remaining node 2: enter(#2) -> unsafe[1] 7 (2+5) remaining node 3: req(#2) -> enter(#2) -> unsafe[1] 8 (1+7) remaining The system is SAFE 2.2.2 Généralisation de l’algorithme de Dekker L’algorithme de Dekker est en réalité la première solution au problème d’exclusion mutuelle. Cette solution est attribuée au mathématicien Th. J. Dekker par Edsger W. Dijkstra qui en donnera une version fonctionnant pour un nombre arbitraire de processus [54]. En 1985, Alain J. Martin présente une version simple de l’algorithme généralisé à n processus [115]. C’est cette version qui est donnée ici sous forme d’algorithme (Algorithme 1) et sous forme de graphe de ot de contrôle (Figure 2.3). La variable booléenne x (i) est utilisée par un processus pour signaler son intérêt à entrer en section critique. La principale diérence avec l’algorithme original est l’utilisation d’une valeur spéciale pour réinitialiser t. Dans Cubicle, les constantes de processus ne sont pas explicites donc on ne peut pas matérialiser l’identiant spécial 0 dans le type proc. Pour 25Chapitre 2 Le model checker Cubicle Algorithme 1 : Code de Dekker pour le processus i [115] Variables : x (i) : variable booléenne, initialisée à false t : variable partagée, initialisée à 0 p(i) : NCS while true do x (i) := true; WANT while ∃j , i. x (j) do AWAIT x (i) := false; await [ t = 0 ∨ t = i ]; TURN t := i; x (i) := true; CS // Section critique; x (i) := false; t := 0; NCS CS WANT ∃j , i. x (j) AWAIT t = 0 t = i TURN x (i):= true x (i):= false x (i):= false t:= 0 t:= i x (i):= true Figure 2.3 – Graphe de Dekker pour le processus i modéliser t, on a choisit d’utiliser deux variables globales : T représente t lorsque celle-ci est non nulle et la variable booléenne T_set vaut False lorsque t a été réinitialisée (à 0). Le tableau P est utilisé pour représenter le compteur de programme et peut prendre les valeurs des étiquettes de l’algorithme 1. On peut remarquer que dans notre modélisation, la condition de la boucle while est évaluée de manière atomique. Les transitions wait et enter testent en une seule étape l’existence (ou non) d’un processus j dont la variable x (j) est vraie. De la même manière que précédemment, on veut s’assurer qu’il y ait au plus un processus au point de programme correspondant à l’étiquette CS, i.e. en section critique. Cubicle est capable de prouver la sûreté de ce système. À vue d’œil, la correction de l’algorithme n’est pas triviale lorsqu’un nombre arbitraire de processus s’exécutent de manière concurrente. Pour illustrer ce propos, admettons que le concepteur ait fait une erreur et qu’un processus i puisse omettre de passer sa variable x (i) à true lorsqu’il arrive à l’étiquette TURN. Il sut alors de rajouter la transition suivante au système pour modéliser les nouveaux comportements introduits : 262.2 Exemples dekker_n.cub type location = NCS | WANT | AWAIT | TURN | CS array P[proc] : location array X[proc] : bool var T : proc var T_set : bool init (i) { T_set = False && X[i] = False && P[i] = NCS } unsafe (i j) { P[i] = CS && P[j] = CS } transition start (i) requires { P[i] = NCS } { P[i] := WANT; X[i] := True; } transition wait (i j) requires { P[i] = WANT && X[j] = True } { P[i] := AWAIT; X[i] := False; } transition enter (i) requires { P[i] = WANT && forall_other j. X[j] = False } { P[i] := CS } transition awaited_1 (i) requires { P[i] = AWAIT && T_set = False } { P[i] := TURN } transition awaited_2 (i) requires { P[i] = AWAIT && T_set = True && T = i } { P[i] := TURN } transition turn (i) requires { P[i] = TURN } { P[i] := WANT; X[i] := True; T := i; T_set := True; } transition loop (i) requires { P[i] = CS } { P[i] := NCS; X[i] := False; T_set := False; } Figure 2.4 – Code Cubicle de l’algorithme de Dekker transition turn_buggy (i) requires { P[i] = TURN } { P[i] := WANT; T := i; T_set := True; } Si on exécute Cubicle sur le chier maintenant obtenu, il nous fait savoir que la propriété n’est plus vériée en exposant une trace d’erreur. On peut voir sur la trace suivante qu’un mauvais état est atteignable en dix étapes avec deux processus. Error trace: start(#2) -> enter(#2) -> start(#1) -> wait(#1, #2) -> loop(#2) -> awaited_1(#1) -> turn_buggy(#1) -> enter(#1) -> start(#2) -> enter(#2) -> unsafe[1] 27Chapitre 2 Le model checker Cubicle UNSAFE ! Des constantes sont introduites pour chaque processus entrant en jeu dans la trace et sont notées #1, #2, #3, . . . . La notation “. . . wait(#1, #2) -> . . . ” signie que pour reproduire la trace, il faut prendre la transition wait instanciée avec les processus #1 et #2. Remarque. Un état dangereux de ce système est en réalité atteignable en seulement huit étapes mais il faut pour cela qu’au moins trois processus soient impliqués. On peut s’en rendre compte en forçant Cubicle à eectuer une exploration purement en largeur grâce à l’option -postpone 0. De cette façon, on est assuré d’obtenir la trace d’erreur la plus courte possible : Error trace: start(#1) -> start(#3) -> wait(#1, #3) -> awaited_1(#1) -> turn_buggy(#1) -> enter(#1) -> start(#2) -> enter(#2) -> unsafe[1] 2.2.3 Boulangerie L’algorithme de la boulangerie a été proposé par Leslie Lamport en réponse au problème d’exclusion mutuelle [110]. Contrairement aux approches précédentes, la particularité de cet algorithme est qu’il est résistant aux pannes et qu’il fonctionne même lorsque les opérations de lecture et d’écriture ne sont pas atomiques. Son pseudo-code est donné dans l’algorithme 2 (voir page suivante). On peut faire le parallèle entre le principe de base de l’algorithme et celui d’une boulangerie aux heures de pointe, d’où son nom. Dans cette boulangerie, chaque client (matérialisant un processus) choisi un numéro en entrant dans la boutique. Le client qui souhaite acheter du pain ayant le numéro le plus faible s’avance au comptoir pour être servi. La propriété d’exclusion mutuelle de cette boulangerie se manifeste par le fait que son fonctionnement garantit qu’un seul client est servi à la fois. Il est possible que deux clients choisissent le même numéro, celui dont le nom (unique) est avant l’autre a alors la priorité. La modélisation faite dans Cubicle est reprise de la version modélisée dans PFS par Abdulla et al. [3] et est donnée ci-dessous. C’est une version simpliée de l’algorithme original de Lamport dans laquelle le calcul du maximum à l’étiquette Choose et l’ensemble des tests de la boucle for à l’étiquette Wait sont atomiques. Les lectures et écritures sont aussi considérées comme étant instantanées. Cet algorithme est tolérant aux pannes, c’est à dire qu’il continue de fonctionner même si un processus s’arrête. Un processus i a le droit de tomber en panne et de redémarrer en section non critique tout en réinitialisant ses variables locales. Ce comportement peut être modélisé dans Cubicle en rajoutant un point de programme spécial Crash représentant le fait qu’un processus est en panne. On ajoute une transition sans garde qui dit qu’un processus peut tomber en panne à tout moment, ainsi qu’une transition lui permettant de redémarrer (voir page 30). 282.2 Exemples Algorithme 2 : Pseudo-code de la boulangerie de Lamport pour le processus i [110] Variables : choosing[i] : variable booléenne, initialisée à false number[i] : variable entière initialisée à 0 p(i) : NCS begin choosing[i] := true; Choose number[i] := 1 + max(number[1], . . . , number[N]); choosing[i] := false; for j = 1 to N do Wait await [ ¬ choosing[j] ]; await [ number[j] = 0 ∨ (number[i], i) < (number[j], j) ]; CS // Section critique; number[i] := 0; goto NCS; bakery_lamport.cub type location = NCS | Choose | Wait | CS array PC[proc] : location array Ticket[proc] : int array Num[proc] : int var Max : int init (x) { PC[x] = NCS && Num[x] = 0 && Max = 1 && Ticket[x] = 0 } invariant () { Max < 0 } unsafe (x y) { PC[x] = CS && PC[y] = CS } transition next_ticket () { Ticket[j] := case | _ : Max; Max := Max + 1; } transition take_ticket (x) requires { PC[x] = NCS && forall_other j. Num[j] < Max } { PC[x] := Choose; Ticket[x] := Max; } transition wait (x) requires { PC[x] = Choose } { PC[x] := Wait; Num[x] := Ticket[x]; } transition turn (x) requires { PC[x] = Wait && forall_other j. (PC[j] <> Choose && Num[j] = 0 || PC[j] <> Choose && Num[x] < Num[j] || PC[j] <> Choose && Num[x] = Num[j] && x < j) } { PC[x] := CS; } transition exit (x) requires { PC[x] = CS } { PC[x] := NCS; Num[x] := 0; } Figure 2.5 – Code Cubicle de l’algorithme de la boulangerie de Lamport 29Chapitre 2 Le model checker Cubicle type location = NCS | Choose | Wait | CS | Crash ... transition fail (x) { PC[x] := Crash } transition recover (x) requires { PC[x] = Crash } { PC[x] := NCS; Num[x] := 0; } 2.2.4 Cohérence de Cache Dans une architecture multiprocesseurs à mémoire partagée, l’utilisation de caches est requise pour réduire les eets de la latence des accès mémoire et pour permettre la coopération. Les architectures modernes possèdent de nombreux caches ayant des fonctions particulières, mais aussi plusieurs niveaux de cache. Les caches qui sont les plus près des unités de calcul des processeurs orent les meilleures performances. Par exemple un accès en lecture au cache (succès de cache ou cache hit) L1 consomme seulement 4 cycles du processeur sur une architecture Intel Core i7, alors qu’un accès mémoire (défaut de cache ou cache miss) consomme en moyenne 120 cycles [113]. Cependant l’utilisation de caches introduit le problème de cohérence de cache : toutes les copies d’un même emplacement mémoire doivent être dans des états compatibles. Un protocole de cohérence de cache fait en sorte, entre autres, que les écritures eectuées à un emplacement mémoire partagé soient visibles de tous les autres processeurs tout en garantissant une absence de conits lors des opérations. Il existe plusieurs types de protocoles de cohérence de cache : — cohérence par espionnage 3 : la communication se fait au travers d’un bus central sur lequel les diérentes transactions sont visibles par tous les processeurs. — cohérence par répertoire 4 : chaque processeur est responsable d’une partie de la mémoire et garde trace des processeurs ayant une copie locale dans leur cache. Ces protocoles fonctionnent par envoi de messages sur un réseau de communication. Bien que plus dicile à mettre en œuvre, cette dernière catégorie de protocoles est aujourd’hui la plus employée, pour des raisons de performance et de passage à l’échelle. Les architectures réelles sont souvent très complexes, elles implémentent plusieurs protocoles de cohérence de manière hiérarchique, et utilisent plusieurs dizaines voire centaines de variables. Néanmoins leur fonctionnement repose sur le même principe fondamental. Un protocole simple mais représentatif de cette famille à été donné par Steven German à 3. Ces protocoles sont aussi parfois qualiés de snoopy. 4. On qualie parfois ces protocoles par le terme anglais directory based. 302.2 Exemples la communauté académique [138]. L’exemple suivant dénommé German-esque est une version simpliée de ce protocole. E S I Shr[i] := true Exg := true Exg := true Shr[i] := true Shr[i] := false Exg := false Exg := false Shr[i] := false Figure 2.6 – Diagramme d’état du protocole German-esque L’état d’un processeuri est donné par la variable Cache[i] qui peut prendre trois valeurs : (E)xclusive (accès en lecture et écriture), (S)hared (accès en lecture seulement) ou (I)nvalid (pas d’accès à la mémoire). Les clients envoient des requêtes au responsable lorsqu’un défaut de cache survient : RS pour un accès partagé (défaut de lecture), RE pour un accès exclusif (défaut d’écriture). Le répertoire contient quatre informations : une variable booléene Exg signale par la valeur true qu’un des clients possède un accès exclusif à la mémoire principale, un tableau de booléens Shr, tel que Shr[i] est vrai si le client i possède une copie (avec un accès en lecture ou écriture) de la mémoire dans son cache, Cmd contient la requête courante (ϵ marque l’absence de requête) dont l’émetteur est enregistré dans Ptr. Les états initiaux du système sont représentés par la formule logique suivante : ∀i. Cache[i] = I ∧ ¬Shr[i] ∧ ¬Exg ∧ Cmd = ϵ signiant que les caches de tous les processeurs sont invalides, aucun accès n’a encore été donné et il n’y a pas de requête à traiter. La Figure 2.6 donne une vue assez haut niveau de l’évolution d’un seul processeur. Les èches pleines montrent l’évolution du cache du processeur selon ses propres requêtes, alors que les èches pointillées représentent les transitions résultant d’une requête d’un autre client. Par exemple, un cache va de l’état I à S lors d’un défaut de lecture : le répertoire lui accorde un accès partagé tout en enregistrant cette action dans le tableau Shr[i] := true. De 31Chapitre 2 Le model checker Cubicle germanesque.cub type msg = Epsilon | RS | RE type state = I | S | E (* Client *) array Cache[proc] : state (* Directory *) var Exg : bool var Cmd : msg var Ptr : proc array Shr[proc] : bool init (z) { Cache[z] = I && Shr[z] = False && Exg = False && Cmd = Epsilon } unsafe (z1 z2) { Cache[z1] = E && Cache[z2] <> I } transition request_shared (n) requires { Cmd = Epsilon && Cache[n] = I } { Cmd := RS; Ptr := n ; } transition request_exclusive (n) requires { Cmd = Epsilon && Cache[n] <> E } { Cmd := RE; Ptr := n; } transition invalidate_1 (n) requires { Shr[n]=True && Cmd = RE } { Exg := False; Cache[n] := I; Shr[n] := False; } transition invalidate_2 (n) requires { Shr[n]=True && Cmd = RS && Exg=True } { Exg := False; Cache[n] := S; Shr[n] := True; } transition grant_shared (n) requires { Ptr = n && Cmd = RS && Exg = False } { Cmd := Epsilon; Shr[n] := True; Cache[n] := S; } transition grant_exclusive (n) requires { Cmd = RE && Exg = False && Ptr = n && Shr[n] = False && forall_other l. Shr[l] = False } { Cmd := Epsilon; Exg := True; Shr[n] := True; Cache[n] := E; } Figure 2.7 – Code Cubicle du protocole de cohérence de cache German-esque 322.3 Non-atomicité façon similaire, si un défaut en écriture survient dans un autre cache, le répertoire invalide tous les clients enregistrés dans Shr avant de donner l’accès exclusif. Cette invalidation générale a pour eet de passer les caches dans les états E et S à l’état I. La modélisation qui est faite de ce protocole est assez immédiate et est donnée ci-dessous. On peut toutefois remarquer qu’on s’intéresse ici seulement à la partie contrôle du protocole et on oublie les actions d’écriture et lecture réelles de la mémoire. La seule propriété qu’on souhaite garantir dans ce cas est que si un processeur a son cache avec accès exclusif alors tous les autres sont invalides : ∀i,j. (i , j ∧ Cache[i] = E) =⇒ Cache[j] = I Le responsable du répertoire est abstrait et on ne s’intéresse qu’à une seule ligne de mémoire donc l’état du répertoire est représenté avec des variables globales. 2.3 Non-atomicité Dans la plupart des travaux existants sur les systèmes paramétrés, on fait la supposition que l’évaluation des conditions globales est atomique. La totalité de la garde est évaluée en une seule étape. Cette hypothèse est raisonnable lorsque les conditions globales masquent des détails d’implémentation qui permettent de faire cette évaluation de manière atomique. En revanche, beaucoup d’implémentations réelles d’algorithmes concurrents et de protocoles n’évaluent pas ces conditions instantanément mais plutôt par une itération sur une structure de donnée (tableau, liste chaînée, etc.). Par exemple, l’algorithme de Dekker (voir Section 2.2.2) implémente le test ∃j , i.x (j) de l’étiquette WANT par une boucle qui recherche un j tel que x (j) soit vrai. De même, on a modélisé la boucle d’attente de l’algorithme de la boulangerie (Section 2.2.3, algorithme 2, étiquette Choose) par une garde universelle dans la transition turn. En supposant que des conditions sont atomiques, on simplie le problème mais cette approximation n’est pas conservatrice. En eet, l’évaluation d’une condition peut être entrelacée avec les actions des autres processus. Il est possible par exemple, qu’un processus change la valeur de sa variable locale alors que celle-ci à déjà été comptabilisée pour une condition globale avec son ancienne valeur. Il peut dans ce cas exister dans l’implémentation des congurations qui ne sont représentées par aucun état du modèle atomique. Si on veut prendre en compte ces éventualités dans notre modélisation, on se doit de reéter tous les comportements possibles dans le système de transition. La vérication de propriétés d’exclusion mutuelle dans des protocoles paramétrés comme l’algorithme de la boulangerie à déjà été traitée par le passé [32, 114]. Ces preuves ne sont souvent que partiellement automatisées et font usage d’abstractions ad-hoc. La première approche permettant une vérication automatique de protocoles avec gardes non atomiques a été développée en 2008 [5]. Les auteurs utilisent ici un protocole annexe de ranement 33Chapitre 2 Le model checker Cubicle pour modéliser l’évaluation non atomique des conditions globales. L’approche qu’on présente dans la suite de cette section est identique en substance à celle de [5]. On montre cependant qu’on peut rester dans le cadre déni par Cubicle pour modéliser ces conditions non atomiques. Comme les tests non atomiques sont implémentés par des boucles, on choisit de modéliser les implémentations de la gure 2.8. La valeur N représente ici le paramètre du système, ∀j , i. c(j) ∃j , i. c(j) j := 1 ; while (j ≤ N) do if j , i ∧ ¬c(j) then return false ; j := j + 1 end ; return true j := 1 ; while (j ≤ N) do if j , i ∧ c(j) then return true ; j := j + 1 end ; return false Figure 2.8 – Évaluation non atomique des conditions globales par un processus i c’est-à-dire la cardinalité du type proc. Pour une condition universelle, on parcourt tous les éléments (de 1 à N) et on s’assurent qu’ils vérient la condition c. Si on trouve un processus qui ne respecte pas cette condition on sort de la boucle et on renvoie false. Malheureusement dans Cubicle, on ne peut pas mentionner ce paramètre N explicitement (car le solveur SMT ne peut pas raisonner sur la valeur de la cardinalité des modèles). On ne peut dès lors pas utiliser de compteur entier. Pour s’en sortir, on construit une boucle avec un compteur abstrait pour lequel on peut seulement tester si sa valeur est 0 ou N 5 . On peut également incrémenter, décrémenter, et aecter ce compteur à ces mêmes valeurs. Dans Cubicle on modélise ce compteur par un tableau de booléens représentant un encodage unaire de sa valeur entière. Le nombre de cellules contenant la valeur true correspond à la valeur du compteur. Incrémenter ce compteur revient donc à passer une case de la valeur false à la valeur true. Pour modéliser l’évaluation non atomique de la condition ∀j , i. c(j) 6 , on utilise un compteur Cpt. Comme on veut qu’il soit local à un processus, on a besoin d’un tableau bi-dimensionnel. Le tableau en Cpt[i] matérialise le compteur local au processusi. Le résultat de l’évaluation de cette condition sera stocké dans la variable Res[i] à valeurs dans le type énuméré {E,T,F}. Res[i] contient E initialement ce qui signie que la condition n’est pas nie d’être évaluée. Lorsqu’elle contient T alors la condition globale a été évalué à vrai, et si elle contient F la condition globale est fausse. Les transitions correspondantes sont données gure 2.9. Avec cette modélisation, on spécie juste que la condition locale c(j) doit être vériée 5. On peut généraliser à tester si sa valeur est k ou N − k où k est une constante positive entière. 6. L’encodage de l’évaluation de la condition duale ∃j , i. c(j) est symétrique. 342.3 Non-atomicité Transition Commentaire type result = E | T | F array Cpt[proc,proc] : bool array Res[proc] : result transition start (i) requires { ... } { Res[i] := E Cpt[x,y] := case | x=i : False | _ : Cpt[x,y] } On initialise le compteur à 0 et on signale que la condition est en cours d’évaluation avec la variable locale Res. transition iter (i j) requires { Cpt[i,j] = False && c(j) } { Cpt[i,j] := True } La condition c(j) n’a pas encore été vériée. Comme elle est vraie on incrémente le compteur. transition abort (i j) requires { Cpt[i,j] = False && ¬c(j) } { Res[i] := F } La condition c(j) n’a pas encore été vériée mais elle est fausse. On sort de la boucle, la condition globale est fausse. transition exit (i) requires { forall_other j. Cpt[i,j] = True } { Res[i] := T } Toutes les conditionsc(j) ont étés véri- ées. On sort de la boucle, la condition globale est vraie. Figure 2.9 – Encodage de l’évaluation non atomique de la condition globale ∀j , i. c(j) 35Chapitre 2 Le model checker Cubicle pour tous les processus, indépendamment de l’ordre. Cette sous-spécication reste conservatrice. Il est toutefois possible d’ajouter des contraintes d’ordre sur la variable j si c’est important pour la propriété de sûreté. On peut remarquer qu’on se sert d’une garde universelle dans la transition exit. Ceci n’inue en rien la « non-atomicité » de l’évaluation de la condition car le quanticateur est seulement présent pour encoder le test Cpt[i] = N. Remarque. Avec cette garde universelle, on risque de tomber dans le cas d’une fausse alarme à cause du traitement détaillé en section 3.3 du chapitre suivant. L’intuition apportée par le modèle de panne franche, nous permet d’identier ces cas problématiques. Si la sûreté dépend du fait qu’un processus puisse disparaître du système pendant l’évaluation d’une condition globale, alors on risque de tomber dans ce cas défavorable. Les versions non atomiques des algorithmes sont bien plus compliquées que leurs homologues atomiques. Les raisonnements à mettre en œuvre pour dérouler la relation de transition (aussi bien en avant qu’en arrière) sont plus longs. C’est ce qui en fait des candidats particulièrement coriaces pour les procédures de model checking. 2.4 Logique multi-sortée et systèmes à tableaux On a montré dans la section précédente que le langage de Cubicle permet de représenter des algorithmes d’exclusion mutuelle ou des protocoles de cohérence de cache à l’aide de systèmes de transitions paramétrés. Le lecteur intéressé par la dénition précise de la syntaxe concrète et des règles de typage de ce langage trouvera leur description en annexe A. Dans cette section, on dénit formellement la sémantique des programmes Cubicle. Pour ce faire, on utilise le formalisme des systèmes à tableaux conçu par Ghilardi et Ranise [77]. Ainsi, on montre dans un premier temps que chaque transition d’un système paramétré peut simplement être interprétée comme une formule dans un fragment de la logique du premier ordre multi-sortée. Ce fragment est déni par l’ensemble des types et variables déclarés au début du programme (ainsi que ceux prédénis dans Cubicle). Dans un deuxième temps, on donne une sémantique opérationnelle à ces formules à l’aide d’une relation de transition entre les modèles logiques de ces formules. On rappelle ici brièvement les notions usuelles de la logique du premier ordre multisortée et de la théorie des modèles qui sont utilisées pour dénir les systèmes à tableaux de Cubicle. Des explications plus amples peuvent être trouvées dans des manuels traitant du sujet [92, 152]. Le lecteur familier avec ces concepts peut ne lire que la section 2.4.3 qui présente plus en détail la construction des ces systèmes. 362.4 Logique multi-sortée et systèmes à tableaux 2.4.1 Syntaxe des formules logiques La logique du premier ordre multi-sortée est une extension classique qui possède essentiellement les mêmes propriétés que la logique du premier ordre sans sortes [149]. Son intérêt est qu’elle permet de partitionner les éléments qu’on manipule selon leur type. Dénition 2.4.1. Une signature Σ est un tuple (S,F ,R) où : — S est un ensemble non vide de symboles de sorte — F est un ensemble de symboles de fonction, chacun étant associé à un type de la forme — s pour les symboles d’arité 0 (zéro) avec s ∈ S. On appelle ces symboles des constantes. — s1 × . . . × sn → s pour les symboles d’arité n, avec s1,. . . ,sn,s ∈ S — R est un ensemble de symboles de relation (aussi appelé prédicats). On associe à chaque prédicat d’arité n un type de la forme s1 × . . . × sn avec s1,. . . ,sn ∈ S. Dans la suite on supposera que le symbole d’égalité = est inclus dans toutes les signatures qui seront considérées et qu’il a les types s × s quelque soit la sorte s ∈ S 7 . On notera par exemple par f : s1 × . . . × sn → s un symbole de fonction f dans F dont le type est s1 × . . . × sn → s. L’en-tête du chier Cubicle est en fait une façon de donner cette signature. Par exemple l’en-tête du code de l’exemple du mutex de la section 2.2.1 correspond à la dénition de la signature Σ suivante : en-tête Cubicle signature Σ = (S,F ,R) type state = Idle | Want | Crit array State[proc] : state var Turn : proc S = {state,proc} F = {Idle : state,Want : state, Crit : state, State : proc → state, Turn : proc} R = {= : state × state : proc × proc} Remarque. Le mot-clef var ne permet pas d’introduire une variable dans la logique mais permet de déclarer une constante logique avec son type. Le choix des mots-clefs var et array reète une vision plus intuitive des systèmes Cubicle comme des programmes. 7. On pourrait éviter cette formulation avec un symbole d’égalité polymorphe mais cela demande d’introduire des variables de type. 37Chapitre 2 Le model checker Cubicle Remarque. Cubicle connaît en interne les symboles de sorte proc, bool, int et real ainsi que les symboles de fonction +, −, les constantes 0,1,2,. . . ,0.0,1.0,. . . et les relations < et ≤. Par convention, ils apparaîtront dans la signature Σ seulement s’ils sont utilisés dans le système. On distinguera parmi ces signatures celles qui ne permettent pas d’introduire de nouveaux termes car il est important pour Cubicle de maîtriser la création des processus. Dénition 2.4.2. Une signature est dite relationnelle si elle ne contient pas de symboles de fonction. Dénition 2.4.3. Une signature est dite quasi-relationnelle si les symboles de fonction qu’elle contient sont tous des constantes. On dénit les Σ-termes, Σ-atomes (ou Σ-formules atomiques), Σ-littéraux et Σ-formules comme les expressions du langage déni par la grammaire décrite en gure 2.10. Les types des variables quantiées ne sont pas indiqués par commodité. Σ-terme : hti ::= c où c est une constante de Σ | f (hti, . . . , hti) où f est un symbole de fonction de Σ d’arité > 0 | ite (hφi, hti, hti) Σ-atome : hai ::= false | true | p(hti, . . . , hti) où p est un symbole de relation de Σ Σ-littéral : hli ::= hai | ¬hai Σ-formule : hφi ::= hli | hφi ∧ hφi | hφi ∨ hφi | ∀i. hφi | ∃i. hφi Figure 2.10 – Grammaire de la logique En plus de cette restriction syntaxique, on impose que les Σ-termes et Σ-atomes soient bien typés en associant des sortes aux termes : 1. Chaque constante c de sorte s ∈ S est un terme de sorte s. 2. Soient f un symbole de fonction de type s1 × . . . × sn → s, t1 un terme de sorte s1, . . . , et tn un terme de sorte sn alors f (t1,. . . tn) est un terme de sorte s. 3. Soit p un symbole de relation de type s1 × . . . ×sn. L’atome p(t1,. . . ,tn) est bien typé ssi t1 est un terme de sorte s1, . . . , et tn est un terme de sorte sn. 382.4 Logique multi-sortée et systèmes à tableaux On appelle une Σ-clause une disjonction de Σ-littéraux. On dénote par, Σ-CNF (resp. Σ-DNF) une conjonction de disjonction de littéraux (resp. une disjonction de conjonction de littéraux). Conventions et notations Pour éviter la lourdeur de la terminologie on dénotera par termes, atomes (ou formules atomiques), littéraux, formules, clauses, CNF et DNF respectivement les Σ-termes, Σ-atomes (ou Σ-formules atomiques), Σ-littéraux, Σ-formules, Σ-clauses, Σ-CNF et Σ-DNF lorsque le contexte ne permet pas d’ambiguïté. Les termes de la forme ite (φcond ,tthen,telse ) correspondent à la construction conditionnelle classique if φcond then tthen else telse . On suppose l’existence d’une fonction elim_ite qui prend en entrée une formule sans quanticateurs dont les termes peuvent contenir le symbole ite et renvoie une formule équivalente sansite. De plus on suppose que elim_ite renvoie une formule en forme normale disjonctive (Σ-DNF). Par exemple, elim_ite(x = ite (φ,t1,t2)) = (φ ∧ x = t1) ∨ (¬φ ∧ x = t2) On notera par i¯ une séquence i1,i2,. . . ,in. Pour les formules quantiées, on écrira ∃x,y. φ (resp. ∀x,y. φ) pour ∃x∃y. φ (resp. ∀x∀y. φ). En particulier, on écrira ∃i¯. φ pour ∃i1∃i2 . . . ∃in. φ. 2.4.2 Sémantique de la logique Dénition 2.4.4. Une Σ-structure A est une paire (D,I) où D est un ensemble appelé le domaine de A (ou l’univers de A) et dénoté par dom(A). Les éléments de D sont appelés les éléments de la structure A. On notera |dom(A)| le cardinal du domaine de A et on dira qu’une structure A est nie si |dom(A)| est ni. I est l’interprétation qui : 1. associe à chaque sorte s ∈ S de Σ un sous ensemble non vide de D. 2. associe à chaque constante de Σ de type s un élément du sous-domaine I(s). 3. associe à chaque symbole de fonction f ∈ F d’arité n > 0 et de type s1 × . . . × sn → s une fonction totale I(f ) : I(s1) × . . . × I(sn) → I(s). 4. associe à chaque symbole de relation p ∈ R d’arité n > 0 et de type s1 × . . . × sn une fonction totale I(p) : I(s1) × . . . × I(sn) → {true,false}. Cette interprétation peut être étendue de manière homomorphique aux Σ-termes et Σ- formules – elle associe à chaque terme t de sorte s un élément I(t) ∈ I(s) et à chaque formule φ une valeur I(φ) ∈ {true,false}. Dénition 2.4.5. On appelle une Σ-théorie T un ensemble (potentiellement inni) de Σ-structures. Ces structures sont aussi appelées les modèles de T . 39Chapitre 2 Le model checker Cubicle Dénition 2.4.6. On dit qu’un Σ-modèle M = (A,I) satisfait une formule φ ssi I(φ) = true, dénoté par M |= φ. Dénition 2.4.7. Une formule φ est dite satisable dans une théorie T (ou T -satisable) ssi il existe un modèle M ∈ T qui satisfait φ. Une formule φ est dite conséquence logique d’un ensemble Γ de formules dans une théorie T (et noté par Γ |=T φ) ssi tous les modèles de T qui satisfont Γ satisfont aussi φ. Dénition 2.4.8. Une formule φ est dite valide dans une théorie T (ou T -valide) ssi sa négation est T -insatisable, dénoté par T |= φ ou ∅ |=T φ. Dénition 2.4.9. Soient A et B deux Σ-structures. A est une sous-structure de B, noté A ⊆ B si dom(A) ⊆ dom(B). Dénition 2.4.10. Soient A une Σ-structure et X ⊆ dom(A), alors il existe une unique plus petite sous-structure B de A tel que dom(B) ⊆ X. On dit que B est la sous-structure de A générée par X et on note B = hXiA. Les deux dénitions suivantes seront importantes pour caractériser la théorie des processus supportée par Cubicle. Dénition 2.4.11. Une Σ-théorie T est localement nie ssi Σ est nie, chaque sous ensemble ni d’un modèle de T génère une sous-structure nie. Remarque. Si Σ est relationnelle ou quasi-relationnelle alors toute Σ-théorie est localement nie. Dénition 2.4.12. Une Σ-théorie T est close par sous-structure ssi chaque sous-structure d’un modèle de T est aussi un modèle de T . Exemple. La théorie ayant pour modèle la structure de domaine N et signature ({int}, {0,1}, {=,≤}) où ces symboles sont interprétés de manière usuelle (comme dans la théorie de l’arithmétique de Presburger) est localement nie et close par sous-structure. Si on étend cette signature avec le symbole de fonction + alors elle n’est plus localement nie mais reste close par sous-structure. Une théorie ayant pour modèle une structure nie, avec une signature (_,∅,{=,R}) où R est interprétée comme une relation binaire qui caractériserait un anneau est localement nie mais n’est pas close par sous-structure. Le problème de la satisabilité modulo une Σ-théorie T (SMT) consiste à établir la satisabilité de formules closes sur une extension arbitraire de Σ (avec des constantes). Une extension de ce problème, beaucoup plus utile en pratique, est d’établir la satisabilité modulo la combinaison de deux (ou plus) théories. 402.4 Logique multi-sortée et systèmes à tableaux Exemples de théories. La théorie de l’égalité (aussi appelée théorie vide, ou EUF) est la théorie qui a comme modèles tous les modèles possibles pour une signature donnée. Elle n’impose aucune restriction sur l’interprétation faite de ses symboles (ses symboles sont dits non-interprétés). Les fonctions non-interprétées sont souvent utilisées comme technique d’abstraction pour s’aranchir d’une complexité ou de détails inutiles. La théorie de l’arithmétique est une autre théorie omniprésente en pratique. Elle est utilisée pour modéliser l’arithmétique des programmes, la manipulation de pointeurs et de la mémoire, les contraintes de temps réels, les propriétés physiques de certains systèmes, etc. Sa signature est {0,1,...,+,−,∗,/,≤} étendue à un nombre arbitraire de constantes, et ses symboles sont interprétés de manière usuelle sur les entiers et les réels. Une théorie de types énumérés est une théorie ayant une signature Σ quasi-relationnelle contenant un nombre ni de constantes (constructeurs). L’ensemble de ses modèles consiste en une unique Σ-structure dont chaque symbole est interprété comme un des constructeurs de Σ. Dans ce qui va suivre on verra que ces théories seront utiles pour modéliser les points de programme de processus et les messages échangés par ces processus dans les systèmes paramétrés. 2.4.3 Systèmes de transition à tableaux Cette section introduit le formalisme des systèmes à tableaux conçu par Ghilardi et Ranise [77]. Il permet de représenter une classe de systèmes de transition paramétrés dans un fragment restreint de la logique du premier ordre multi-sortée. Pour ceci on aura besoin des théories suivantes : — une théorie des processus TP sur signature ΣP localement nie dont le seul symbole de type est proc, et telle que la TP -satisabilité est décidable sur le fragment sans quanticateurs — une théorie d’éléments TE sur signature ΣE localement nie dont le seul symbole de type est elem, et telle que la TE-satisabilité est décidable sur le fragment sans quanticateurs. TE peut aussi être l’union de plusieurs théories TE = TE1 ∪ . . . ∪ TEk , dans ce cas TE a plusieurs symboles de types elem1, . . ., elemk . — la théorie d’accès TA sur signature ΣA, obtenue en combinant la théorie TP et la théorie TE de la manière suivante. ΣA = ΣP ∪ ΣE ∪ Q où Q est un ensemble de symboles de fonction de type proc × . . . × proc → elemi (ou constantes de type elemi ). Étant donnée une structure S, on note par S|ty la structure S dont le domaine est restreint aux éléments de type ty. Les modèles de TA sont les structures S où S|proc est un modèle de TP et S|elem est un modèle de TE et S|proc×...×proc→elem est l’ensemble des fonctions totales de proc × . . . × proc → elem. 41Chapitre 2 Le model checker Cubicle On suppose dans la suite que les théories TE et TP ne partagent pas de symboles, i.e. ΣE ∩ ΣP = {=} (seule l’égalité apparaît dans toutes les signatures). Dénition 2.4.13. Un système (de transition) à tableaux est un triplet S = (Q,I,τ ) avec Q partitionné en Q0,. . . ,Qm où — Qi est un ensemble de symboles de fonction d’arité i. Chaque f ∈ Qi a comme type proc × . . . × proc | {z } i fois → elemf . Les fonctions d’arité 0 représentent les variables globales du système. Les fonctions d’arité non nulle représentent quand à elles les tableaux (indicés par des processus) du système. — I est une formule qui caractérise les états initiaux du système (où les variables de Q peuvent apparaître libres). — τ est une relation de transition. La relation τ peut être exprimée sous la forme d’une disjonction de formules quantiées existentiellement par zéro, une, ou plusieurs variables de type proc. Chaque composante de cette disjonction est appelée une transition et est paramétrée par ses variables existentielles. Elle met en relation les variables globales et tableaux d’états avant et après exécution de la transition. Si x ∈ Q est un tableau (ou une variable globale), on notera par x ′ la valeur de x après exécution de la transition et par Q ′ l’ensemble des variables et tableaux après exécution de la transition. La forme générale des transitions qu’on considère est la suivante : t(Q,Q ′ ) = ∃i¯. γ (i¯,Q) | {z } garde ∧ ^ x∈Q ∀j¯.x ′ (j¯) = δx (i¯,j¯,Q) | {z } action où — γ est une formule sans quanticateurs 8 appelée la garde de t — δx est une formule sans quanticateurs appelée la mise à jour de x Les variables de Q peuvent apparaître libres dans γ et les δx . Cette formule est équivalente à la variante suivante où les fonctions x ′ sont écrites sous forme fonctionnelle avec un lambda-terme : t(Q,Q ′ ) = ∃i¯. γ (i¯,Q) ∧ ^ x∈Q x ′ = λj¯. δx (i¯,j¯,Q) 8. On autorise une certaine forme de quantication universelle dans γ en section 3.3. 422.4 Logique multi-sortée et systèmes à tableaux Intuitivement, une transition t met en jeu un ou plusieurs processus (les variables quantiées existentiellement i¯, ses paramètres) qui peuvent modier l’état du système (cf. Section 2.5). Ici γ représente la garde de la transition et les δx sont les mises à jour des variables et tableaux d’état. Un tel système S = (Q,I,τ ) est bien décrit par la syntaxe concrète de Cubicle et de manière analogue, sa sémantique est une boucle innie qui, à chaque tour, exécute une transition choisie arbitrairement dont la garde γ est vraie, et met à jour les valeurs des variables de Q en conséquence. Soit un système S = (Q,I,τ ) et une formule Θ (dans laquelle les variables de Q peuvent apparaître libres), le problème de la sûreté (ou de l’atteignabilité) est de déterminer s’il existe une séquence de transitions t1,. . . ,tn dans τ telle que I (Q 0 ) ∧ t1 (Q 0 ,Q 1 ) ∧ . . . ∧ tn (Q n−1 ,Q n ) ∧ Θ(Q n ) est satisable modulo les théories mises en jeu. S’il n’existe pas de telle séquence, alors S est dit sûr par rapport à Θ. Autrement dit, ¬Θ est une propriété de sûreté ou un invariant du système. Exemple (Mutex). On prend ici l’exemple d’un mutex simple paramétré par son nombre de processus (dans type proc) dont un aperçu plus détaillé a été donnée en section 2.2.1. Pour cet exemple, on prendra TP la théorie de l’égalité de signature ΣP = ({proc},∅,{=}) ayant pour symbole de type proc. On considère comme théorie des éléments, l’union d’une théorie des types énumérés TE de signature ΣE = ({state},{Idle,Want,Crit},{=}) où Idle, Want, et Crit en sont les constructeurs de type state et de la théorie TP . La théorie d’accès TA est dénie comme la combinaison de TP et TE. Elle a pour signature ΣA = ΣP ∪ ΣE ∪ (_,{State,Turn},∅) où State est un symbole de fonction de type proc → state, et Turn est une constante de type proc. Avec le formalisme décrit précédemment, le système S = (Q,I,τ ) représentant le problème du mutex s’exprime de la façon suivante. L’ensemble Q contient les symboles State et Turn. Les états initiaux du système sont décris par la formule I ≡ ∀i. State(i) = Idle La relation de transition τ est la disjonction treq ∨ tenter ∨ texit avec : treq ≡ ∃i. State(i) = Idle ∧ ∀j. State′ (j) = ite (i = j, Want, State(j)) ∧ Turn′ = Turn tenter ≡ ∃i. State(i) = Want ∧ Turn = i ∧ ∀j. State′ (j) = ite (i = j, Crit, State(j)) ∧ Turn′ = Turn texit ≡ ∃i. State(i) = Crit ∧ ∀j. State′ (j) = ite (i = j, Idle, State(j)) 43Chapitre 2 Le model checker Cubicle Enn la formule caractérisant les mauvais états du système est : Θ ≡ ∃i,j. i , j ∧ State(i) = Crit ∧ State(j) = Crit La description de ce système faite dans la syntaxe concrète de Cubicle donnée en section 2.2.1 est l’expression directe de cette représentation. Pour plus de simplicité, on notera les transitions avec le sucre syntaxique (de Cubicle) transition t (i¯) requires { д } { a } dans la section suivante. Par exemple, la première transition treq sera notée par transition treq (i) requires {State[i] = Idle} { State[j]:= case i = j : Want | _ : State′ [j] } . 2.5 Sémantique La sémantique d’un programme décrit par un système de transition à tableaux dans Cubicle est dénie pour un nombre de processus donné. On xe n la cardinalité du domaine proc. C’est-à-dire que tous les modèles qu’on considère dans cette section interprètent le type proc vers un ensemble à n éléments. Remarque. On peut aussi voir un Σ-modèle M comme un dictionnaire qui associe les éléments de Σ aux éléments du domaine de M. Soit S = (Q,I,τ ) un système à tableaux, et TA la combinaison des théories comme dénie en section 2.4.3. Dans la suite de cette section, on verra les modèles de TA comme des dictionnaires associant tous les symboles de ΣA à des éléments de leur domaine respectif. La première partie de ce chapitre donne au lecteur tous les éléments nécessaires pour réaliser un interprète du langage d’entrée de Cubicle et s’assurer qu’il soit correct. 2.5.1 Sémantique opérationnelle On dénit la sémantique opérationnelle du système à tableaux S pour n processus sous forme d’un triplet K n = (Sn,In,−→) où : — Sn est l’ensemble potentiellement inni des modèles de TA où la cardinalité de l’ensemble des éléments de proc est n. — In = {M ∈ Sn | M |= I} est le sous ensemble de Sn dont les modèles satisfont la formule initiale I du système à tableaux S. 442.5 Sémantique — −→ ⊆ Sn × Sn est la relation de transition d’états dénie par la règle suivante : transition t (i¯) requires { д } { a } σ : i¯7→ proc M |= дσ A = all(a,i¯) M −→ update(Aσ,M) oùA = all(a,proc) est l’ensemble des actions de a instanciées avec tous les éléments de proc et σ est une substitution des paramètres i¯ de la transition vers éléments de proc. L’application de substitution de variables sur les actions s’eectue sur les termes de droite. On note Aσ l’ensemble des actions de A auxquelles on a appliqué la substitution σ : x := t ∈ A ⇐⇒ x := tσ ∈ Aσ A[i¯] := case c1 : t1 | . . . | cm : tm | _ : tm+1 ∈ A ⇐⇒ A[i¯] := case c1σ : t1σ | . . . | cmσ : tmσ | _ : tm+1σ ∈ Aσ update(Aσ,M) est le modèle obtenu après application des actions de Aσ. On dénit une fonction d’évaluation ⊢I telle que : M ⊢I e : v ssi l’interprétation de e dans M est v L’union des dictionnaires M1 ∪ M2 est dénie comme l’union des ensembles des liaisons lorsque ceux-ci sont disjoints. Lorsque certaines liaisons apparaissent à la fois dans M1 et M2, on garde seulement celles de M2. On note la fonction update par le symbole ⊢up dans les règles qui suivent. M ⊢up a1 : M1 M ⊢up a2 : M2 M ⊢up a1; a2 : M1 ∪ M2 M ⊢I t : v M ⊢up x := t : M ∪ {x 7→ v} M 6|= c1 M ⊢up A[i¯]:= case c2:t2 | . . . | _ : tn+1 : M′ M ⊢up A[i¯]:= case c1:t1 | c2:t2 | . . . | _ : tn+1 : M′ M |= c1 M ⊢I t1 : v1 M ⊢I A : fA M ⊢I i¯: vi M ⊢up A[i¯]:= case c1:t1 | c2:t2 | . . . | _ : tn+1 : M ∪ {A 7→ fA ∪ {vi 7→ v1}} M ⊢up M ⊢I t : v M ⊢I A : fA M ⊢I i¯: vi M ⊢up A[i¯]:= case _ : t : M ∪ {A 7→ fA ∪ {vi 7→ v}} 45Chapitre 2 Le model checker Cubicle Exécuter l’action x := t revient à changer la liaison de x dans le modèle M par la valeur de t, comme montré par la deuxième règle. L’avant dernière règle dénit quant à elle l’exécution d’une mise à jour du tableau A en position i¯. Si la première condition c1 de la construction case est satisable dans le modèle courant, l’interprétation de la fonction correspondant à A est changée pour qu’elle associe maintenant la valeur de t aux valeurs de i¯. Remarque. La construction case du langage de Cubicle est similaire aux constructions traditionnelles de certains langages de programmation comme le branchement conditionnel switch . . .case . . .break de C, ou match de ML. En eet les instructions d’un cas sont exécutées seulement si toutes les conditions précédentes sont fausses. Le dernier cas _ permet de s’assurer qu’au moins une instruction est exécutée. En utilisant la forme logique de la section 2.4.3, une mise à jour avec case s’exprime sous la forme de termes ite (ifthen-else) imbriqués. Une fois les ite éliminés, l’ensemble des conditions obtenues forme une partition (i.e. elles sont mutuellement insatisables et leur disjonction est valide). Ces règles montrent notamment qu’on évalue les termes des aectations dans le modèle précédent et non celui qu’on est en train de construire. Le caractère ; dans les actions ne représente pas une séquence car les actions d’une transition sont exécutées simultanément et de manière atomique. Un système paramétré a alors toutes les sémantiques {K n | n ∈ N}. On peut aussi voir la sémantique d’un système à tableaux paramétré comme une fonction qui à chaque n associe K n 9 . 2.5.2 Atteignabilité Ici on ne s’intéresse qu’aux propriétés de sûreté des systèmes à tableaux, ce qui revient au problème de l’atteignabilité d’un ensemble d’états. Soit K n = (Sn,In,−→) un triplet exprimant la sémantique d’un système à tableaux S = (Q,I,τ ) comme déni précédemment. On note par −→∗ la clôture transitive de la relation −→ sur Sn. On dit qu’un état s ∈ Sn est atteignable dans K n et on note Reachable(s,K n ) ssi il existe un état s0 ∈ In tel que s0 −→∗ s Soit une propriété dangereuse caractérisée par la formule Θ. On dira qu’un système à tableaux S est non sûr par rapport à Θ ssi ∃n ∈ N. ∃s ∈ Sn. s |= Θ ∧ Reachable (s,K n ) 9. On peut remarquer que K n est en réalité une structure de Kripke innie pour laquelle on omet la fonction de labellisation L des états de la structure de Kripke car elle correspond exactement aux modèles, i.e. L(M) = M. 462.5 Sémantique Au contraire, on dira que S est sûr par rapport à Θ ssi ∀n ∈ N. ∀s ∈ Sn. s |= Θ =⇒ ¬Reachable (s,K n ) 2.5.3 Un interpréteur de systèmes à tableaux À l’aide de la sémantique précédente, on peut dénir diérentes analyses sur un système à tableaux. Par exemple, un interpréteur de systèmes à tableaux est un programme dont les états sont des états de K n = (Sn,In,−→), qui démarre en un état initial de In et qui « suit » une séquence de transitions de −→. Comme dans la section précédente, l’interpréteur pour un système à tableaux S = (Q,I,τ ) représente l’état du programme par un dictionnaire sur Q (i.e. un modèle de TA). On suppose ici que In est non vide, c’est-à-dire qu’il existe au moins un modèle de I où proc est de cardinalité n. Dans ce cas, on note Init la fonction qui prend n en argument et qui retourne un état de In au hasard. L’interpréteur consiste en une procédure run (Algorithme 3) prenant en argument le paramètre n et la relation de transition τ . Elle maintient l’état du système dans le dictionnaire M et exécute une boucle innie qui modie M en fonction des transitions choisies. Algorithme 3 : Interpréteur d’un système à tableaux Variables : M : l’état courant du programme (un modèle de TA) procedure run(n,τ ) : begin M := Init(n); while true do let L = enabled(n,τ ,M) in if L = ∅ then deadlock (); let a,σ = select(L) in M := update(all(a,proc)σ,M); La fonction enabled(n,τ ,M) renvoie l’ensemble des transitions de τ dont la garde est vraie pour M. Autrement dit, (transition t (i¯) requires { д } { a }) ∈ enabled(n,τ ,M) =⇒ M |= ∃i¯. д(i¯) où д est la garde de la transition t et i¯ en sont les paramètres. Si aucune des transitions n’est possible alors on sort de la boucle d’exécution avec la fonction deadlock. Si M 47Chapitre 2 Le model checker Cubicle correspond à un état nal du système, le programme s’arrête. Sinon on est dans une situation d’interblocage (ou deadlock). La fonction select choisit de manière aléatoire une des transitions de L et retourne les actions a correspondantes ainsi qu’une substitution σ des arguments vers les éléments du domaine de proc telle que M |= д(i¯)σ. Ensuite la fonction update(all(a,proc)σ,M) retourne un nouveau dictionnaire où les valeurs des variables et tableaux sont mises à jour en fonction des actions de l’instance de la transition choisie, comme déni précédemment. Remarque. On peut aussi ajouter une instruction assert(¬M |= Θ) à l’algorithme 3 qui lève une erreur dès qu’on passe par un état mauvais, i.e. lorsque M |= Θ. Exemple (Mutex). Prenons l’exemple du mutex de la section précédente avec deux processus #1 et #2. Une conguration de départ satisfaisant la formule initiale I possible est le modèle M ci-dessous. En exécutant la transition treq pour le processus #1, on change la valeur de State(#1) et obtient le nouveau modèle M′ . M = F dom(M) Turn 7→ #2 State 7→ ( #1 7→ Idle #2 7→ Idle . . . tr eq [i\#1] −−−−−−−−−−−−→ M′ = F dom(M′ ) Turn 7→ #2 State 7→ ( #1 7→ Want #2 7→ Idle . . . Maintenant qu’il est aisé de se faire une idée du langage de description et de sa sémantique qu’on utilise pour les systèmes de transition paramétrés, on montre dans la suite de ce document comment construire un model checker capable de prouver la sûreté des exemples de la section 2.2. Les algorithmes présentés dans ce chapitre sont des systèmes jouets, dans le sens où ils représentent des problèmes de vérication formelle de taille assez réduite. Cependant les preuves manuelles de ses systèmes paramétrés ne sont pas pour autant triviales et les outils automatiques sont souvent mis au point sur ce genre d’exemples. On s’eorcera bien sûr d’expliquer comment développer des algorithmes qui passent à l’échelle sur des problèmes plus conséquents. 483 Cadre théorique : model checking modulo théories Sommaire 3.1 Analyse de sûreté des systèmes à tableaux . . . . . . . . . . . . . . 50 3.1.1 Atteignabilité par chaînage arrière . . . . . . . . . . . . . . . . 50 3.1.2 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.1.3 Eectivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.2 Terminaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.2.1 Indécidabilité de l’atteignabilité . . . . . . . . . . . . . . . . . . 57 3.2.2 Conditions pour la terminaison . . . . . . . . . . . . . . . . . . 59 3.2.3 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.3 Gardes universelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.3.1 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.3.2 Calcul de pré-image approximé . . . . . . . . . . . . . . . . . . 69 3.3.3 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.3.4 Relation avec le modèle de panne franche et la relativisation des quanticateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 3.4.1 Exemples sans existence d’un bel ordre . . . . . . . . . . . . . . 74 3.4.2 Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Le cadre théorique sur lequel repose Cubicle est celui du model checking modulo théories proposé par Ghilardi et Ranise [77]. C’est un cadre déclaratif dans lequel les systèmes manipulent un ensemble de tableaux innis d’où le nom de systèmes à tableaux. Un système est décrit par des formules logiques du premier ordre et des transitions gardées (voir 49Chapitre 3 Cadre théorique : model checking modulo théories Section 2.4.3). Une des forces de cette approche réside dans l’utilisation des capacités de raisonnement des solveurs SMT et de leur support interne pour de nombreuses théories. On rappelle dans ce chapitre les fondements de cette théorie et certains résultats et théorèmes associés. Dans la suite de ce chapitre on se donne un système à tableaux S = (Q,I,τ ) et une formule Θ représentant des états dangereux. Rappelons que la relation τ peut s’exprimer sous la forme d’une disjonction de transitions paramétrées de la forme : t(Q,Q ′ ) = ∃i¯. γ (i¯,Q) | {z } garde ∧ ^ x∈Q ∀j¯.x ′ (j¯) = δx (i¯,j¯,Q) | {z } action avecγ et δx des formulessans quanticateurs. Ces restrictions sont très importantes car elles permettent à la théorie exposée dans ce chapitre de caractériser des conditions susantes pour lesquelles l’atteignabilité (ou la sûreté) est décidable. Cubicle implémente le cadre du model checking modulo théories mais va au-delà en relâchant certaines contraintes, au prix de la complétude et de la terminaison, mais reste correct. 3.1 Analyse de sûreté des systèmes à tableaux Cette section présente les conditions sous lesquelles l’analyse de sûreté d’un système à tableau peut être mise en œuvre de façon eective. En particulier on caractérise un fragment de la logique qui est clos par les opérations de l’algorithme d’atteignabilité arrière et on montre que cette approche est correcte. 3.1.1 Atteignabilité par chaînage arrière Plusieurs approches sont possibles pour résoudre les instances du problème de sûreté (ou d’atteignabilité). Une première approche consiste à construire l’ensemble des états atteignables (par chaînage avant) à partir des états initiaux, une autre approche, celle qui sera adoptée dans la suite, consiste à construire l’ensemble des états qui peuvent atteindre les mauvais états du système (atteignabilité par chaînage arrière). Dénition 3.1.1. La post-image d’une formule φ(X) par la relation de transition τ est dénie par Postτ (φ)(X ′ ) = ∃X. φ(X) ∧ τ (X,X ′ ) Elle représente les états atteignables à partir de φ en une étape de τ . 503.1 Analyse de sûreté des systèmes à tableaux Dénition 3.1.2. La pré-image d’une formule φ(X ′ ) par la relation de transition τ est dénie par Preτ (φ)(X) = ∃X ′ . τ (X,X ′ ) ∧ φ(X ′ ) De manière analogue la pré-image d’une formule φ(X ′ ) par une transition t est dénie par Pret (φ)(X) = ∃X ′ . t(X,X ′ ) ∧ φ(X ′ ) et donc Preτ (φ)(X) = W t∈τ Pret (φ)(X). La pré-image Preτ (φ) est donc une formule qui représente les états qui peuvent atteindre φ en une étape de transition de τ . La clôture de la pré-image Pre∗ τ (φ) est dénie par :     Pre0 τ (φ) = φ Pren τ (φ) = Preτ (Pren−1 τ (φ)) Pre∗ τ (φ) = W k∈N Prek τ (φ) La clôture de Θ par Preτ caractérise alors l’ensemble des états qui peuvent atteindre Θ. Une approche générale pour résoudre le problème d’atteignabilité consiste alors à calculer cette clôture et vérier si elle contient un état de la formule initiale. L’algorithme d’atteignabilité par chainage arrière présenté ci-après, fait exactement ceci de manière incrémentale. Si, pendant sa construction de Pre∗ τ (Θ), on découvre qu’un état initital (un modèle de I) est aussi un modèle d’un des Pren τ (Θ), alors le système n’est pas sûr vis-à- vis de Θ. Le système est sûr si, a contrario, aucune des pré-images ne s’intersecte avec I. L’algorithme peut décider une telle propriété seulement si cette clôture est aussi un point-xe. Plusieurs briques de base sont nécessaires pour construire un tel algorithme. La première est d’être capable de calculer les pré-images successives. Pour une recherche en avant, il faut pouvoir calculer Postn (I) ce qui est souvent impossible pour les systèmes paramétrés à cause de la présence de quanticateurs universels dans la formule initiale I. En revanche, le calcul du Pre est eectif dans les systèmes à tableaux si on restreint la forme des formules exprimant les états dangereux. Dénition 3.1.3. On appelle cube une formule de la forme ∃i¯.(∆ ∧ F ), où les i¯sont des variables de la théorie TP , ∆ est une conjonction de diséquations entre les variables de i¯, et F est une conjonction de littéraux. Proposition 3.1.1. Si φ est un cube, la formule Preτ (φ) est équivalente à une disjonction de cubes. 51Chapitre 3 Cadre théorique : model checking modulo théories Démonstration. Soit φ = ∃p.(∆ ∧ F ) un cube, Preτ (φ) est la disjonction des Pret (φ) pour chaque transition de t de τ . Prenons une transition t de τ , Pret (φ)(Q) = ∃Q ′ . t(Q,Q ′ ) ∧ ∃p.(∆ ∧ F (Q ′ )) se réécrit en ∃Q ′ . ∃i¯. γ (i¯,Q) ∧ ^ x∈Q x ′ = λj¯. δx (i¯,j¯,Q) ∧ ∃p.(∆ ∧ F (Q ′ )) (3.1) Par la suite, on utilisera la notation traditionnellement employée en combinatoire  A k  pour l’ensemble des combinaisons de A de taille k. Soit j¯ = j1,. . . jk . Étant donné x ∈ Q et x ′ = λj¯. δx (i¯,j¯,Q) une des mises à jour de la transition t, on notera σx ′ la substitution x ′ (pσ )\δx (i¯,pσ ,Q) pour tout pσ ∈  p k  . Maintenant, la formule ∃p.(∆ ∧ F (Q ′ ))[σx ′] correspond en essence à la réduction de l’application d’une lambda expression apparaissant dans l’équation (3.1). La réduction de toutes les lambda expressions conduit à la formule suivante : ∃Q ′ . ∃i¯. γ (i¯,Q) ∧ ∃p.(∆ ∧ F (Q ′ )[σx ′,x ′ ∈ Q ′ ]) F (Q ′ )[σx ,x ∈ Q] n’est pas tout à fait sous forme de cube car les σx peuvent contenir des termes ite. Notons Fd1 (i¯,Q) ∨ . . . ∨ Fdh (i¯,Q) = elim_ite(F (Q ′ )[σx ,x ∈ Q]) la disjonction résultant de l’élimination des ite des mises à jour. Les Fd (i¯,Q) sont des conjonctions de littéraux. En sortant les disjonctions, on obtient : ∃Q ′ . _ Fd (i¯,Q) ∈elim_ite(F (Q′ )[σx ,x∈Q]) ∃i¯. γ (i¯,Q) ∧ ∃p.(∆ ∧ Fd (i¯,Q)) et donc : Pret (φ)(Q) = _ Fd (i¯,Q) ∈ elim_ite(F (Q′ )[σx ,x∈Q]) ∃i¯.∃p. (∆ ∧γ (i¯,Q) ∧ Fd (i¯,Q)) Dans ce qui suit on supposera que la formule caractérisant les états dangereux Θ est un cube. La clôture construite par l’algorithme sera donc une disjonction de cubes et pourra être vue comme un ensemble de cubes V. On donne une analyse d’atteignabilité par chaînage arrière classique dans l’algorithme 4. Cet algorithme maintient une le à priorité Q de cubes à traiter et la clôture partielle ou l’ensemble des cubes visités V dont la disjonction des éléments caractérise les états pouvant atteindre Θ. On démarre avec en ensemble V vide matérialisant la formule false et une le Q où seule la formule Θ est présente. La fonction BWD calcule itérativement la clôture Pre∗ τ (Θ) et si elle termine, renvoie un des deux résultats possibles : 52 Segmentation supervisée d’actions à partir de primitives haut niveau dans des flux vid´eos Adrien Chan-Hon-Tong To cite this version: Adrien Chan-Hon-Tong. Segmentation supervis´ee d’actions `a partir de primitives haut niveau dans des flux vid´eos. Signal and Image Processing. Universit´e Pierre et Marie Curie - Paris VI, 2014. French. . HAL Id: tel-01084604 https://tel.archives-ouvertes.fr/tel-01084604 Submitted on 19 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Université Pierre et Marie Curie École doctorale des Sciences mécaniques, acoustique, électronique et robotique de Paris Laboratoire de Vision et Ingénierie des Contenus (CEA, LIST, DIASI) Segmentation supervisée d’actions à partir de primitives haut niveau dans des flux vidéos Par Adrien CHAN-HON-TONG Thèse de doctorat de Génie informatique, automatique et traitement du signal Dirigée par Catherine ACHARD et encadrée par Laurent LUCAT Présentée et soutenue publiquement le 29/09/2014 Devant un jury composé de : CAPLIER Alice, Professeur, Rapporteur CANU Stéphane, Professeur, Rapporteur CORD Matthieu, Professeur, Examinateur EL YACOUBI Mounim A., Maitre de conférences, Examinateur ACHARD Catherine, Maitre de conférences, Directeur de thèse LUCAT Laurent, Ingénieur – Chercheur, Encadrant de thèseA mes parents. A ma femme et mes enfants. Factorisation matricielle, application `a la recommandation personnalis´ee de pr´ef´erences Julien Delporte To cite this version: Julien Delporte. Factorisation matricielle, application `a la recommandation personnalis´ee de pr´ef´erences. Other. INSA de Rouen, 2014. French. . HAL Id: tel-01005223 https://tel.archives-ouvertes.fr/tel-01005223 Submitted on 12 Jun 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE Présentée à : L’Institut National des Sciences Appliquées de Rouen En vue de l’obtention du titre de : Docteur en Informatique Par : Julien DELPORTE Intitulée : Factorisation Matricielle, Application à la Recommandation Personnalisée de Préférences
soutenue le 3 février 2013 Devant le jury composé de : Rapporteurs : Younès BENNANI - Université Paris-Nord Gérard GOVAERT - Université de Technologie de Compiègne Examinateurs : Anne BOYER - Université de Lorraine Michèle SEBAG - Université Paris-Sud Dominique FOURDRINIER - Université de Rouen Directeur : Stéphane CANU - INSA de Rouen Lh*rs p2p : une nouvelle structure de donn´ees distribu´ee et scalable pour les environnements Pair `a Pair Hanafi Yakouben To cite this version: Hanafi Yakouben. Lh*rs p2p : une nouvelle structure de donn´ees distribu´ee et scalable pour les environnements Pair `a Pair. Other. Universit´e Paris Dauphine - Paris IX, 2013. French. . HAL Id: tel-00872124 https://tel.archives-ouvertes.fr/tel-00872124 Submitted on 11 Oct 2013 Services de r´epartition de charge pour le Cloud : application au traitement de donn´ees multim´edia. Sylvain Lefebvre To cite this version: Sylvain Lefebvre. Services de r´epartition de charge pour le Cloud : application au traitement de donn´ees multim´edia.. Computers and Society. Conservatoire national des arts et metiers - CNAM, 2013. French. . HAL Id: tel-01062823 https://tel.archives-ouvertes.fr/tel-01062823 Submitted on 10 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS École Doctorale Informatique, Télécommunications et Électronique (Paris) CEDRIC THÈSE DE DOCTORAT présentée par : Sylvain LEFEBVRE soutenue le : 10 Décembre 2013 pour obtenir le grade de : Docteur du Conservatoire National des Arts et Métiers Spécialité : INFORMATIQUE Services de répartition de charge pour le Cloud : Application au traitement de données multimédia THÈSE dirigée par M. GRESSIER-SOUDAN Eric Professeur, CEDRIC-CNAM, Paris Encadrée par Mme. CHIKY Raja Enseignant-Chercheur, LISITE-ISEP, Paris RAPPORTEURS Mme. MORIN Christine Chercheur Titulaire, INRIA-IRISA, Rennes M. PIERSON Jean-Marc Professeur, IRIT, Université Paul Sabatier, Toulouse EXAMINATEURS M. ROOSE Philippe Directeur de recherche, LIUPPA, Pau M. SENS Pierre Directeur de recherche, LIP6, UPMC, Paris M. PAWLAK Renaud Directeur technique, IDCapture, Paris Mme. SAILHAN Françoise Maitre de conférence, CEDRIC-CNAM, Paris"When they first built the University of California at Irvine they just put the buildings in. They did not put any sidewalks, they just planted grass. The next year, they came back and put the sidewalks where the trails were in the grass." Larry WallRemerciements Les travaux menés durant ces trois ans ont été possible grâce à la confiance et aux encouragements que mes encadrants Eric Gressier-Soudan, Renaud Pawlak puis Raja Chiky m’ont accordé, à la fois lors du recrutement et tout au long de ces 36 derniers mois. Je tiens à remercier particulièrement Raja Chiky, pour son optimisme, ses conseils et ses encouragements en toutes circonstances. Je tiens aussi à remercier tous les membres de l’équipe de Recherche et Développement Informatique du LISITE : Yousra pour les filtres de Bloom, Zakia, Bernard et Matthieu pour leurs conseils et commentaires avisés, et Olivier pour les probabilités. En restant à l’ISEP je remercie aussi mes collègues de bureaux : Giang, Sathya, Adam, Ahmad, Fatima, Maria et Ujjwal. Mes sincères remerciements vont aux membres du jury qui ont accepté de juger mon travail : MM. Pierson et Roose, Mme Morin ainsi que le professeur P. Sens pour ses conseils lors de ma soutenance de mi-parcours et pour m’avoir donné accès à la plateforme GRID5000. Je dois aussi adresser des remerciements à ceux qui m’ont encouragé dans ma poursuite d’études : Professeurs B. Marchal, F. Pommereau, M. Bernichi de l’ESIAG et A. Ung d’Essilor sans lesquels je ne me serais pas lancé dans cette aventure. Enfin, ce travail n’aurait pu être mené sans les encouragements de ma famille, de mes amis, et de Clara. iiiREMERCIEMENTS ivRésumé Les progrès conjugués de l’algorithmique et des infrastructures informatiques permettent aujourd’hui d’extraire de plus en plus d’informations pertinentes et utiles des données issues de réseaux de capteurs ou de services web. Ces plateformes de traitement de données "massives" sont confrontées à plusieurs problèmes. Un problème de répartition des données : le stockage de ces grandes quantités de données impose l’agrégation de la capacité de stockage de plusieurs machines. De là découle une seconde problématique : les traitements à effectuer sur ces données doivent être à leur tour répartis efficacement de manière à ne surcharger ni les réseaux, ni les machines. Le travail de recherche mené dans cette thèse consiste à développer de nouveaux algorithmes de répartition de charge pour les systèmes logiciels de traitement de données massives. Le premier algorithme mis au point, nommé "WACA" (Workload and Cache Aware Algorithm) améliore le temps d’exécution des traitements en se basant sur des ré- sumés des contenus stockés sur les machines. Le second algorithme appelé "CAWA" (Cost Aware Algorithm) tire partie de l’information de coût disponible dans les plateformes de type "Cloud Computing" en étudiant l’historique d’exécution des services. L’évaluation de ces algorithmes a nécessité le développement d’un simulateur d’infrastructures de "Cloud" nommé Simizer, afin de permettre leur test avant le déploiement en conditions réelles. Ce déploiement peut se faire de manière transparente grâce au système de distribution et de surveillance de service web nommé "Cloudizer", développé aussi dans le cadre de cette thèse, qui a servi à l’évaluation des algorithmes sur l’Elastic Compute Cloud d’Amazon. Ces travaux s’inscrivent dans le cadre du projet de plateforme de traitement de données Multimédia for Machine to Machine (MCube). Ce projet requiert une infrastructure logicielle adaptée au stockage et au traitement d’une grande quantité de photos et de sons, issus de divers réseaux de capteurs. La spécificité des traitements utilisés dans ce projet a nécessité le développement d’un service d’adaptation automatisé des programmes vers leur environnement d’exécution. Mots clés : Répartition de charge, Cloud, Données Massives vAbstract Nowadays, progresses in algorithmics and computing infrastructures allow to extract more and more adequate and useful information from sensor networks or web services data. These big data computing platforms have to face several challenges. A data partitioning issue ; storage of large volumes imposes aggregating several machines capacity. From this problem arises a second issue : to compute these data, tasks must be distributed efficiently in order to avoid overloading networks and machines capacities. The research work carried in this thesis consists in developping new load balancing algorithms for big data computing software. The first designed algorithm, named WACA (Workload And Cache Aware algorithm) enhances computing latency by using summaries for locating data in the system. The second algorithm, named CAWA for "Cost AWare Algorithm", takes advantage of cost information available on so-called "Cloud Computing" platforms by studying services execution history. Performance evaluation of these algorithms required designing a Cloud Infrastructure simulator named "Simizer", to allow testing prior to real setting deployment. This deployement can be carried out transparently thanks to a web service monitoring and distribution framework called "Cloudizer", also developped during this thesis work and was used to assess these algorithms on the Amazon Elastic Compute Cloud platform. These works are set in the context of data computing platform project called "Multimedia for Machine to Machine" (MCube). This project requires a software infrastructure fit to store and compute a large volume of pictures and sounds, collected from sensors. The specifics of the data computing programs used in this project required the development of an automated execution environement adaptation service. Keywords : Load balancing, Cloud Computing, Big Data viiAvant propos Cette thèse se déroule dans l’équipe Recherche et Développement en Informatique (RDI) du laboratoire Laboratoire d’Informatique, Signal et Image, Électronique et Télécommunication (LISITE) de l’Institut Supérieur d’Électronique de Paris. L’équipe RDI se focalise principalement sur la thématique des systèmes complexes avec deux axes forts. Le premier axe vise la fouille de données et l’optimisation dans ces systèmes. L’optimisation est en effet pour la plupart du temps liée à la traçabilité et à l’analyse des données, en particulier les données liées aux profils d’utilisation. Le deuxième axe concerne l’étude de langages, de modèles, et de méthodes formelles pour la simulation et la validation des systèmes complexes, en particulier les systèmes biologiques et les systèmes embarqués autonomes sous contraintes fortes. Les travaux de cette thèse s’inscrivent dans le cadre d’un projet européen de mise au point de plateforme de services Machine à Machine permettant d’acquérir et d’assurer l’extraction et l’analyse de données multimédia issues de réseaux de capteurs. Ce projet, baptisé Mcube pour Multimedia for machine to machine (Multimédia pour le machine à machine) est développé en partenariat avec le fond Européen de Développement Régional et deux entreprises de la région Parisienne : CAP 2020 et Webdyn. Il permet de réunir les différentes problématiques de recherches de l’équipe RDI au sein d’un projet commun, en partenariat avec les membres de l’équipe de recherche en traitement du signal du LISITE. La particularité de ce projet est qu’il se concentre sur la collecte de données multimédias. Les difficultés liées au traitement de ces données nécessitent de faire appel à des technologies spécifiques pour leur stockage. Cette plateforme ne se limite pas au stockage des données, et doit fournir aux utilisateurs la possibilité d’analyser les données récupérées en ligne. Or, ces traitements peuvent s’exécuter dans un environnement dynamique soumis à plusieurs contraintes comme le coût financier, ou la consommation énergétique. La répartition des traitements joue donc un rôle prépondérant dans la garantie de ces contraintes. La répartition des données sur les machines joue aussi un rôle important dans la performance des traitements, en permettant de limiter la quantité de données à transférer. Ces travaux ont été encadrés par Dr. Renaud Pawlak puis suite à son départ de l’ISEP en septembre 2011, par Dr. Raja Chiky, sous la responsabilité du professeur Eric Gressier-Soudan de l’équipe Systèmes Embarqués et Mobiles pour l’Intelligence Ambiante du CEDRIC-CNAM.RÉSUMÉ xTable des matières 1 Introduction 1 2 MCube : Une plateforme de stockage et de traitement de données multimédia 9 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1 Architecture du projet MCube . . . . . . . . . . . . . . . . . . . . . 9 2.1.2 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Composants des plateformes de stockage de données multimédia . . . . . . . 12 2.2.1 Stockage de données multimédia . . . . . . . . . . . . . . . . . . . . 13 2.2.2 Distribution des traitements . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.3 Plateformes génériques de traitements de données multimédias . . . 20 2.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4 Architecture de la plateforme MCube . . . . . . . . . . . . . . . . . . . . . . 23 2.4.1 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4.3 Architecture de la plateforme MCube . . . . . . . . . . . . . . . . . . 24 2.4.4 Description des algorithmes de traitement de données multimédia . . 26 2.5 Développement du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 xiTABLE DES MATIÈRES 3 Le framework Cloudizer : Distribution de services REST 31 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Architecture du canevas Cloudizer . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1 Les nœuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.2 Le répartiteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.3 Déploiement de services . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3 Intégration au projet MCube . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4 Considérations sur l’implémentation . . . . . . . . . . . . . . . . . . . . . . 38 3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4 Simizer : un simulateur d’application en environnement cloud 41 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.1.1 Simulateurs de Cloud existants . . . . . . . . . . . . . . . . . . . . . 42 4.2 Architecture de Simizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.1 Couche Evénements . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2 Couche architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.3 Fonctionnement du processeur . . . . . . . . . . . . . . . . . . . . . 48 4.2.4 Exécution d’une requête . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.3 Utilisation du simulateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.1 Génération de nombres aléatoires . . . . . . . . . . . . . . . . . . . . 53 4.4.2 Fonctionnement des processeurs . . . . . . . . . . . . . . . . . . . . . 55 4.5 Discussion et travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5 Algorithmes de répartition de charge 59 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 xiiTABLE DES MATIÈRES 5.2 Classification et composition des algorithmes de répartition de charge . . . . 61 5.2.1 Familles d’algorithmes de répartition de charge . . . . . . . . . . . . 61 5.2.2 Composition d’algorithmes de répartition de charge . . . . . . . . . . 63 5.3 Algorithmes de répartition par évaluation de la charge . . . . . . . . . . . . 65 5.4 Algorithmes de répartition fondés sur la localité . . . . . . . . . . . . . . . . 66 5.4.1 Techniques exhaustives . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.4.2 Techniques de hachage . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.4.3 Techniques de résumé de contenus . . . . . . . . . . . . . . . . . . . 69 5.5 Stratégies basées sur le coût . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6 WACA : Un Algorithme Renseigné sur la Charge et le Cache 77 6.1 Contexte et Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.1.1 Localité des données pour les traitements distribués . . . . . . . . . 77 6.2 Filtres de Bloom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.2.1 Filtres de Bloom Standards (FBS) . . . . . . . . . . . . . . . . . . . 80 6.2.2 Filtres de Bloom avec compteurs (FBC) . . . . . . . . . . . . . . . . 82 6.2.3 Filtres de Bloom en Blocs (FBB) . . . . . . . . . . . . . . . . . . . . 82 6.3 Principe Général de l’algorithme WACA . . . . . . . . . . . . . . . . . . . . 83 6.3.1 Dimensionnement des filtres . . . . . . . . . . . . . . . . . . . . . . . 84 6.3.2 Choix de la fonction de hachage . . . . . . . . . . . . . . . . . . . . . 85 6.4 Algorithme sans historique (WACA 1) . . . . . . . . . . . . . . . . . . . . . 87 6.4.1 Tests de WACA 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.5 Algorithme avec historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.5.1 Compléxité de l’algorithme et gain apporté . . . . . . . . . . . . . . 92 6.5.2 Experimentation de WACA avec historique . . . . . . . . . . . . . . 93 xiiiTABLE DES MATIÈRES 6.6 Block Based WACA (BB-WACA) . . . . . . . . . . . . . . . . . . . . . . . . 95 6.6.1 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . 95 6.6.2 Analyse de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.7 Evaluation de la politique BB WACA . . . . . . . . . . . . . . . . . . . . . 102 6.7.1 Évaluation par simulation . . . . . . . . . . . . . . . . . . . . . . . . 102 6.7.2 Évaluation pratique sur l’Elastic Compute Cloud . . . . . . . . . . . 107 6.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7 CAWA : Un algorithme de répartition basé sur les les coûts 113 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.2 Approche proposée : Cost AWare Algorithm . . . . . . . . . . . . . . . . . . 115 7.2.1 Modélisation du problème . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2.2 Avantages de l’approche . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3 Phase de classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.1 Représentation et pré-traitement des requêtes . . . . . . . . . . . . . 118 7.3.2 Algorithmes de classification . . . . . . . . . . . . . . . . . . . . . . . 120 7.4 Phase d’optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.4.1 Matrice des coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.4.2 Résolution par la méthode Hongroise . . . . . . . . . . . . . . . . . . 122 7.4.3 Répartition vers les machines . . . . . . . . . . . . . . . . . . . . . . 123 7.5 Évaluation par simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.5.1 Preuve de concept : exemple avec deux machines . . . . . . . . . . . 124 7.5.2 Robustesse de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . 125 7.6 Vers une approche hybride : Localisation et optimisation des coûts . . . . . 127 7.7 Conclusion et travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 8 Conclusion 131 xivTABLE DES MATIÈRES A Cloud Computing : Services et offres 139 A.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 A.2 Modèles de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 A.2.1 L’Infrastructure à la Demande (Infrastructure as a Service) . . . . . 140 A.2.2 La Plateforme à la demande (Platform as a Service) . . . . . . . . . 140 A.2.3 Le logiciel à la demande (Software As a Service) . . . . . . . . . . . 141 A.3 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 B Code des politiques de répartition 143 B.1 Implémentation de WACA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.2 Implémentation de l’algorithme CAWA . . . . . . . . . . . . . . . . . . . . . 145 C CV 147 Bibliographie 149 Glossaire 161 Index 163 xvTABLE DES MATIÈRES xviListe des tableaux 2.1 Propriétés des systèmes de traitements de données multimédias . . . . . . . 23 3.1 Protocole HTTP : exécution de services de traitement de données . . . . . . 37 4.1 Lois de probabilité disponibles dans Simizer . . . . . . . . . . . . . . . . . . 44 4.2 Résultats des tests du Chi-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3 Comparaison de Simizer et CloudSim, temps d’exécution de tâches . . . . . 56 6.1 Configurations des tests de la stratégie WACA . . . . . . . . . . . . . . . . 103 A.1 Caractéristiques des instances EC2 . . . . . . . . . . . . . . . . . . . . . . . 141 xviiLISTE DES TABLEAUX xviiiTable des figures 2.1 Architecture du projet MCube . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 Architecture pour la fouille de données multimédia . . . . . . . . . . . . . . 12 2.3 Architecture de la plateforme MCube . . . . . . . . . . . . . . . . . . . . . . 25 2.4 Modèle de description d’algorithme . . . . . . . . . . . . . . . . . . . . . . . 27 3.1 Architecture de la plateforme Cloudizer . . . . . . . . . . . . . . . . . . . . 33 3.2 Modèle des stratégies de répartition de charge . . . . . . . . . . . . . . . . . 35 4.1 Architecture de Simizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 Entités de gestion des événements . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3 Entités de simulation système . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4 Comparaison des distributions aléatoires de Simizer . . . . . . . . . . . . . . 54 5.1 Stratégies de sélection possibles [GPS11, GJTP12] . . . . . . . . . . . . . . 64 5.2 Graphique d’ordonnancement, d’après Assunçao et al. [AaC09] . . . . . . . 72 6.1 Relation entre nombre d’entrées/sorties et temps d’éxécution . . . . . . . . 78 6.2 Exemples de Filtres de Bloom . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.3 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.4 Comparaison des fonctions MD5, SHA-1 et MumurHash . . . . . . . . . . . 86 6.5 Mesures du temps d’exécution des requêtes, WACA version 1 . . . . . . . . 90 xixTABLE DES FIGURES 6.6 Mesures du temps d’exécution des requêtes, WACA version 2 . . . . . . . . 93 6.7 Comparaisons de WACA 1 et 2 . . . . . . . . . . . . . . . . . . . . . . . . . 94 6.8 Flot d’exécution de l’algorithme BB WACA . . . . . . . . . . . . . . . . . . 96 6.9 Schéma du tableau d’index . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.10 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.11 Distribution des temps de réponses simulés, 1000 requêtes, distribution Uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.12 Distribution des temps de réponses simulés, 1000 requêtes, distribution Gaussienne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.13 Distribution des temps de réponses simulés, 1000 requêtes, distribution Zip- fienne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.14 Répartition des requêtes sur 20 machines, (Zipf) . . . . . . . . . . . . . . . 107 6.15 Résultats de simulation : temps de sélection des machines . . . . . . . . . . 108 6.16 Résultats d’exécutions sur le cloud d’Amazon . . . . . . . . . . . . . . . . . 110 7.1 Description de la phase de classification / optimisation . . . . . . . . . . . . 116 7.2 Distribution cumulative des temps de réponses, 2 machines . . . . . . . . . 124 7.3 CAWA : Distribution cumulative des temps de réponse, 10 machines . . . . 126 xxChapitre 1 Introduction Ces dernières années, le besoin de traiter des quantités de données de plus en plus grandes s’est fortement développé. Les applications possibles de ces analyses à grande échelle vont de l’indexation de pages web à l’analyse de données physiques, biologiques ou environnementales. Le développement de nouvelles plateformes de services informatiques comme les réseaux de capteurs et les "nuages", ces plateformes de services de calcul à la demande, accentuent ce besoin tout en facilitant la mise en œuvre de ces outils. Les réseaux de capteurs ne sont pas une technologie récente, mais la capacité de traiter des grandes quantités de données issues de ces réseaux est aujourd’hui facilement accessible à un grand nombre d’organisations, en raison du développement de l’informatique en "nuage" : le Cloud Computing. Ce nouveau modèle de service informatique est, d’après la définition du National Institute of Standards and Technologies (NIST), un service mutualisé, accessible par le ré- seau, qui permet aux organisations de déployer rapidement et à la demande des ressources informatiques [MG11]. Dans ce contexte, les applications combinant plateformes d’acquisition de données autonomes et les "nuages" pour traiter les données acquises, se développent de plus en plus et permettent de fournir de nouveaux services en matière d’analyse de données, dans le domaine commercial [Xiv13], ou académique [BMHS13, LMHJ10]. 1Cadre applicatif Les travaux de cette thèse s’inscrivent dans le cadre d’un projet de recherche financé par le Fond Européen de DEveloppement Régional (FEDER) d’Ile de France 1, nommé Multimedia pour le Machine à Machine (MCube) 2. Ce projet consiste à mettre au point un ensemble de technologies permettant de collecter, transférer, stocker et traiter des données multimédias collectées à partir de passerelles autonomes déployées géographiquement. L’objectif est d’en extraire des informations utiles pour les utilisateurs du service. Par exemple, il peut s’agir de détecter la présence d’une certaine espèce d’insecte nuisible dans un enregistrement sonore, afin de permettre à l’agriculteur d’optimiser le traitement insecticide de ses cultures, en épandant que lorsque cela est nécessaire. Ce projet pose plusieurs difficultés de réalisation : en premier lieu, l’intégration et le stockage de volumes de données importants, pouvant venir de différentes sources comme un réseau de capteurs ou de multiples services WEB, implique de sélectionner les technologies appropriées pour traiter et stocker ces données[Lan01]. À titre d’exemple, les cas d’études utilisés pour le projet MCube consistent en un suivi photographique du développement de plans de tomates et des écoutes sonores pour la détection de nuisibles. Ces deux cas d’études effectués sur un seul champ durant les trois campagnes d’acquisition du projet (2011,2012 et 2013) ont nécessité la collecte d’un téraoctet et demi de données, soit environ 466,6 gigaoctets par utilisateur et par an. Le service définitif devant s’adresser à un nombre plus important de clients, l’espace requis pour ces deux applications représentera donc un volume non négligeable, en utilisation réelle. Le deuxième aspect de ces travaux consiste à mettre au point un système pouvant adapter ces applications à un environnement dynamique tel que les plateformes de cloud computing, de manière à pouvoir bénéficier de ressources importantes à la demande lorsqu’un traitement le requiert. La troisième difficulté concerne les traitements d’images eux mêmes, qui sont réalisés par des scientifique ayant peu ou pas d’expériences de la programmation exceptés dans des langages spécifiques comme MATLAB 3, dont l’utilisation sur les plateforme de type 1. http://www.europeidf.fr/index.php, consulté le 5 octobre 2013 2. http://mcube.isep.fr/mcube, consulté le 5 octobre 2013 3. http://www.mathworks.fr/products/matlab/, consulté le 5 octobre 2013 2"nuage" n’est pas facile. En effet, ces programmes ne sont pas écrits par des experts de la programmation parallèle ou des calculs massifs, mais sont écrits pour traiter directement un ou deux fichiers à la fois. Or, le contexte du projet MCube impose de traiter de grandes quantités de fichiers avec ces mêmes programmes, ce qui requiert un système permettant de les intégrer le plus simplement possible dans un environnement parallèle. Ces trois verrous s’inscrivent dans des problématiques scientifiques plus larges liées aux "nuages" et aux services distribués en général. Problématiques scientifiques Les problématiques scientifiques abordées dans ce document sont au nombre de trois. La première d’entre elle consiste à assurer la répartition de requêtes dans un système distribué déployé sur un "Cloud", en tenant compte des aspects particuliers de ce type de plateformes. La deuxième problématique, plus spécifique au projet MCube, concerne l’adaptation automatique de traitements à leur environnement d’exécution. Troisièmement, Le développement de nouvelles stratégies de répartition a nécessité de nombreux tests en amont du déploiement sur une infrastructure réelle, or il n’existe pas, à notre connaissance, de simulateur d’applications distribuées sur le "cloud" approprié pour tester ce type de développements. Distribution de requêtes dans le "Cloud" Les stratégies de répartition fournies par les services de "Cloud Computing" sont limitées dans leurs fonctionnalités ou leur capacité. Par exemple, le répartiteur élastique de la plateforme Amazon Web Services (ELB : Elastic Load Balancer), distribue les requêtes selon une stratégie en tourniquet (Round Robin) sur les machines les moins chargées du système 4. Seule cette stratégie de répartition est disponible pour les utilisateurs. Or, les applications déployées sur les plateformes d’informatique en nuage sont diverses, par conséquent une stratégie générique n’est pas toujours adaptée pour obtenir la meilleure performance du système. De plus, Liu et Wee [LW09] ont démontré que déployer son propre répartiteur d’applications web sur une machine vir- 4. https://forums.aws.amazon.com/message.jspa?messageID=129199#129199, consulté le 5 octobre 2013 3tuelle dédiée était plus économique et permettait de répondre à un plus grand nombre de requêtes concurrentes que le service de répartition de charge élastique fournit par Amazon. Les fournisseurs de plateformes Cloud imposent souvent à leurs utilisateurs des stratégies de répartition génériques pour pouvoir répondre à un grand nombre de cas d’utilisation, mais ces stratégies ne sont pas toujours les plus efficaces : Un exemple notable est celui de la plateforme Heroku 5, qui utilisait une stratégie de répartition aléatoire pour attribuer les requêtes à différents processeurs. Or, cette répartition aléatoire se faisait sans que les multiples répartiteurs du système ne communiquent entre eux pour surveiller la charge des machines. Par conséquent, certains répartiteurs envoyaient des requêtes vers des machines déjà occupées, ce qui créait des files d’attentes inattendues 6. Utiliser des stratégies de répartition de charge appropriées, tenant compte des spécificités des plateformes de type "Cloud Computing" est donc indispensable. Les spécificités de ces plateformes sont notamment : Des performances difficilement prévisibles : L’infrastructure physique de ces plateformes est partagée par un grand nombre d’utilisateurs (cf. annexe A). La consé- quence de ce partage est qu’en fonction de l’utilisation des ressources faite par les multiples utilisateurs, il peut arriver que deux machines virtuelles identiques sur le papier ne fournissent pas obligatoirement le même niveau de performance [BS10, IOY+11]. Des latences réseaux plus élevées : La taille des centres de données utilisés dans les plateformes de Cloud Computing, ainsi que leur répartition géographique a pour conséquence une latence plus importante dans les communications réseaux, qu’il convient de masquer le plus possible à l’utilisateur final. Une plateforme d’informatique à la demande doit donc permettre aux utilisateurs de choisir la stratégie de distribution la plus adaptée à leur cas d’utilisation. De plus, il est nécessaire de prendre en compte les spécificités de ces environnements pour développer de nouvelles stratégies de répartition adaptées. 5. https://www.heroku.com/, consulté le 5 octobre 2013 6. https://blog.heroku.com/archives/2013/2/16/routing_performance_update, consulté le 5 octobre 2013 4Adaptation d’applications de traitements de données multimédia Ces nouvelles plateformes sont par définition simples d’utilisation, flexibles et économiques. Cependant, pour tirer parti des avantages de ces services, il est nécessaire de mettre en place des processus automatisés de déploiement, de distribution et de configuration des applications [AFG+09, ZCB10, MG11]. Les plateformes de cloud computing promettent à leurs utilisateurs l’accès à une infinité de ressources à la demande, mais toutes les applications ne sont pas nécessairement conçues pour être distribuées dans un environnement dynamique. Quelles sont donc les caractéristiques des applications pouvant être déployées dans les environnements de type "Cloud Computing" ? Quels mécanismes peuvent être mis en œuvre pour assurer le déploiement de ces applications de manière plus ou moins transparente ? Comment amener ces traitements à s’exécuter de manière distribuée ou parallèle pour pouvoir tirer parti des avantages fournis par les plateformes de "Cloud Computing" ? Test et performance A ces questions s’ajoute la problématique du test de l’application. Il n’existe à ce jour pas de simulateur fiable permettant d’évaluer le comportement d’applications déployées dans le Cloud, car les efforts actuels, tels que les simulateurs CloudSim[RNCB11] et SimGrid[CLQ08], se concentrent sur la simulation des infrastructures physiques supportant ces services plutôt que sur les applications utilisant ces services [SL13]. Or, le développement de protocoles et d’algorithmes distribués nécessite des tests sur un nombre important de machines. L’ajustement de certains paramètres peut requé- rir de multiples tests sur diverses configurations (nombre de machines, puissance, type de charge de travail), mais il n’est pas toujours aisé de devoir déployer des tests grandeur nature pour ce type d’ajustements. Il faut donc développer ou adapter les outils existants pour faciliter ces tests, en fournissant une interface de programmation de haut niveau pour développer les protocoles à tester, sans que l’utilisateur n’ait à programmer à la fois la simulation et le protocole qu’il souhaite étudier. Approche développée L’approche développée pour répondre à ces problématiques a consisté à mettre au point une plateforme de distribution de services web destinée aux environnements de type 5Service d’Infrastructure à la Demande (Infrastructure As A Service, IaaS, cf. annexe A), permettant de déployer et de distribuer des services web ou des applications en ligne de commande en les transformant en services Web. Cette application, nommée Cloudizer, a permis l’étude de différentes stratégies de distribution et de leur impact sur les différentes applications déployées à travers plusieurs publications [PLCKA11, SL12, LKC13]. Cette plateforme a été utilisée dans le projet MCUBE, pour distribuer les programmes de traitements des images collectées. Les volumes de données concernés par ce projet sont tels que l’utilisation d’une stratégie de distribution des requêtes fondée sur la localité des données [DG04, PLCKA11] permet de réduire efficacement les temps de traitement. Dans ce domaine, les algorithmes de distribution les plus utilisés sont ceux fondés sur la technique du hachage cohérent [KLL+97, KR04], qui est mise en œuvre dans plusieurs systèmes de stockage de données massives. Le but de ces travaux est de montrer à travers différentes simulations que les filtres de Bloom [Blo70, FCAB98, DSSASLP08] peuvent être facilement combinés à d’autres algorithmes de répartition de charge, pour fournir une alternative performante au hachage cohérent, dans certaines conditions. Ce travail a permis la mise au point d’une stratégie de répartition de charge fondée sur des filtres de Bloom indexés appelée WACA (Workload And Cache Aware Algorithm, Algorithme Renseigné sur la Charge et le Cache). Les Clouds de type Infrastructure à la Demande constituent l’environnement de déploiement cible de ces services. La propriété de ces plateformes est de facturer leurs services à l’utilisation. Afin de prendre ce facteur en compte, nous avons développé une stratégie fondée sur le coût comme indicateur de performance, et nommée CAWA (Cost-AWare Algorithm, Algorithme Renseigné sur le Coût) dont le fonctionnement a été testé à travers des simulations. Tel que montré en section 1 de cette introduction, il n’existe pas encore de simulateur adéquat pour les utilisateurs de plateformes de Cloud Computing. Le logiciel Simizer a donc été développé pour permettre la simulation d’applications orientées services déployées sur des infrastructures Cloud. Ce simulateur a permis de simuler et tester les stratégies de distribution développées pour la plateforme Cloudizer, et d’étudier leur comportement à large échelle. 6Organisation du présent document Le reste de ce document est organisé en deux parties principales. La première partie, composée des chapitres 2 à 4, décrit les développements des différentes plateformes logicielles évoquées dans la section précédente. Le chapitre 2 présente les particularités du projet MCube et ce qui le différencie des plateformes de traitement de données multimédia existantes. Le chapitre 3 décrit le fonctionnement de la plateforme Cloudizer et son utilisation dans le cadre du projet MCUBE, puis le chapitre 4 décrit les particularités et le fonctionnement du simulateur Simizer. La seconde partie de ce document se concentre sur les stratégies de distribution de requêtes mises au point au cours de cette thèse. L’état de l’art en matière de répartition de charge est présenté dans le chapitre 5. les chapitres suivants décrivent respectivement la stratégie WACA, (chapitre 6), qui utilise des résumés compacts pour assurer une distribution des tâches en fonction de la localisation des données dans le système, et la stratégie CAWA (chapitre 7) qui se fonde sur une estimation du coût d’exécution des tâches pour effectuer la répartition. Le chapitre 8 présentera les conclusions et perspectives de l’ensemble de ces travaux. 78Chapitre 2 MCube : Une plateforme de stockage et de traitement de données multimédia 2.1 Introduction L’objectif technique du projet MCube (Multimedia 4 Machine 2 Machine) est de développer une technologie Machine à Machine pour la capture et l’analyse de données multimédia par des réseaux de capteurs avec des problématiques de faible consommation et de transmission GPRS/EDGE. Le projet couvre la chaîne complète : l’acquisition des données, la transmission, l’analyse, le stockage, et le service d’accès par le WEB. Il s’appuie sur les infrastructures M2M actuellement offertes par les opérateurs du secteur comme les réseaux 3G/GPRS pour la communication des données. Le but de cette plateforme est de fournir des services d’analyse de données multimédia à faible coût permettant diverses applications telles que la surveillance de cultures et de sites industriels (détections d’intrusions ou d’insectes nuisibles). 2.1.1 Architecture du projet MCube L’architecture globale de la technologie MCube correspond à l’état de l’art en matière d’architecture M2M et est résumée en figure 2.1. Les "passerelles" sont des systèmes embarqués permettant de piloter des périphériques d’acquisition de données multimédia comme des appareils photos ou des microphones USB. Les passerelles assurent la transmission des 92.1. INTRODUCTION Figure 2.1 – Architecture du projet MCube données collectées vers la plateforme MCube, via une connexion 3G si un accès Ethernet n’est pas disponible. La communication s’effectue via le protocole HTTP. La plateforme est un serveur accessible via le web, dont le rôle consiste à : Stocker les données collectées La plateforme assure le stockage des données multimé- dia capturées et remontées par les passerelles. Ceci nécessite un large espace de stockage redondant et distribué afin de limiter les risques de pertes de données, ainsi que des méthodes efficaces pour retrouver les données stockées. Configurer les passerelles Le système offre la possibilité de communiquer avec les passerelles afin de les mettre à jour dynamiquement et de changer différents paramètres tels que le type de capture à effectuer (sons, images ou vidéos) ou la fréquence de ces captures. Cette communication se fait via une interface de programmation prenant la forme d’un service web REST[Fie00], déployée sur les serveurs de la plateforme. Traiter et analyser les données multimédia Les utilisateurs du système MCube peuvent développer leurs propres programmes d’analyse de données, et les stocker sur la plateforme pour former leur propre bibliothèque de traitements. Ces traitements doivent pouvoir être exécutés par lots, en parallèle sur un grand nombre de fichiers, mais aussi en temps réel au fur et à mesure de la collecte des données. Par conséquent, mis à part le rôle de communication avec les passerelles, la plateforme MCube devrait reposer sur une base de données multimédia. Ces systèmes stockent et 102.1. INTRODUCTION traitent des données en volumes importants (plusieurs giga/téraoctets). Les données concernées peuvent être de types différents (sons, images, vidéos,...) et sont séparées en un nombre important de petits fichiers pouvant provenir de différents périphériques d’acquisition. De plus, ces données sont généralement peu ou pas structurées. Afin d’assurer l’efficacité des traitements sur les données multimédia, il est nécessaire de les exécuter de façon parallèle. À nouveau, le résultat de ces traitements doit être stocké dans le système, ce qui permet la réutilisation des données pour des analyses supplémentaires. La somme de toutes ces données exige une capacité de stockage importante. 2.1.2 Problématiques Une contrainte primordiale du projet MCube est d’aboutir à un service suffisamment flexible pour pouvoir être personnalisé à chaque scénario d’utilisation, dans le but d’optimiser le modèle économique du client en fonction de nombreux critères. Ainsi, les traitements des données multimédia pourront être faits aussi bien côté passerelle que côté plateforme suivant les critères à optimiser. La plateforme fournira des services d’aide à la décision permettant d’optimiser au mieux la solution. Les choix d’architecture logicielle décrits en section 2.4 reflètent ces besoins. La plateforme MCube permet d’exécuter des analyses poussées sur les données reçues des passerelles. Les algorithmes utilisés pour ces analyses sont souvent soit expérimentaux, soit développés spécifiquement pour certains clients, et ne sont pas disponibles dans les librairies de traitements de données multimédias existantes telles que Image Terrier[HSD11] ou OpenCV[Bra00]. La conséquence est que ces algorithmes ne sont pas toujours directement parallélisables. Or, la collecte d’un nombre important de fichiers dans les passerelles MCube impose de pouvoir être en mesure d’exécuter les traitements sur une grande quantité de données en parallèle. Cet état de fait a des conséquences sur les choix d’architecture à effectuer car il est nécessaire de fournir un accès aux données à la fois au niveau fichier pour que les données soient accessibles aux différents programmes de traitements et un accès automatisé, via une interface de programmation, pour permettre aux utilisateurs d’interroger leurs données en temps réel. 112.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA Ce chapitre expose donc dans un premier temps les composants des systèmes de stockage et de traitement de données multimédias en section 2.2, et analyse les différentes plateformes existantes de ce domaine par rapport aux besoins de la plateforme MCube en section 2.3. La section 2.4 décrit la solution adoptée pour la mise au point de l’architecture de la plateforme MCube et les problématiques qui découlent de ces choix sont discutées en section 2.6. 2.2 Composants des plateformes de stockage de données multimédia Il est possible de définir une plateforme de traitement de données multimédias comme un système logiciel distribué permettant de stocker des fichiers contenant des données photographiques, vidéos ou sonores, et de fournir les services nécessaires à l’extraction et au stockage d’informations structurées issues de ces fichiers. Les systèmes d’analyse de données multimédia possèdent un ensemble hiérarchisé de composants permettant de transformer les données brutes en informations précises [CSC09, HSD11]. Le schéma 2.2 montre l’articulation de ces différents composants, que l’on retrouvera dans la plupart des systèmes décrits dans ce chapitre. Données multimédias Extraction descripteurs Stockage descripteurs Indexation Detection Index informations Figure 2.2 – Architecture pour la fouille de données multimédia Le premier composant de ces systèmes correspond à la couche de stockage des données. Ce composant doit assurer le stockage et la disponibilité des données brutes, c’est à dire les documents audiovisuels dans leur format d’origine (RAW, MPEG, AVI, WAV), mais aussi des données intermédiaires nécessaires pour les traitements (les descripteurs) et les résultats des algorithmes d’indexation et d’analyse. Les descripteurs permettent de décrire le contenu des documents audiovisuels stockés 122.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA dans le système. Il s’agit de représentations intermédiaires des données multimédias, comme par exemple les valeurs obtenues après l’application d’une transformée de Fourrier à un enregistrement sonore. Il existe un nombre important de représentations différentes, chacune dépendant du type d’information que l’utilisateur souhaite extraire des données collectées. Les systèmes de stockage multimédia fournissent une bibliothèque d’algorithmes divers permettant de procéder à l’extraction de plusieurs types de représentations. À partir de ces descripteurs, l’information obtenue peut être traitée de plusieurs manières : elle peut être utilisée pour construire un index des données afin de faciliter la recherche de contenu dans la banque de données multimédia (indexation), ou bien les données peuvent être traitées pour en extraire des informations précises, à travers l’utilisation d’algorithmes de détection d’objets, d’artefacts ou de mouvements (détection). Les composants génériques décrits dans cette section sont présents dans la plupart des systèmes évoqués dans la suite de ce chapitre. Chaque système doit cependant relever un certain nombre de défis pour parvenir à indexer ou extraire des informations des contenus. 2.2.1 Stockage de données multimédia Les données multimédia sont dans la plupart des cas des données extrêmement riches en informations et donc très volumineuses. Les données ainsi stockées doivent aussi faire l’objet de traitements et pré-traitements, dont il faut stocker les résultats pour pouvoir les analyser à l’aide d’outils appropriés. Les volumes de stockage atteints deviennent très vite handicapant pour les systèmes de gestion de base de données traditionnels. Différentes stratégies de stockage distribué peuvent être utilisées pour résoudre ce problème. Les données multimé- dias recouvrent généralement des espaces disque importants et sont difficilement compressibles sans perte d’information. Par conséquent, la distribution des données sur plusieurs machines à la fois apparaît comme la solution simple et économique. Plusieurs stratégies coexistent dans le domaine pour parvenir à ce but : les données peuvent être stockées dans un système de fichiers distribué [SKRC10], dans une base de données distribuée [Kos05] ou encore dans une base de données distribuée non relationnelle [Cor07, CDG+06]. 132.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA Système de fichiers distribués Un système de fichiers distribué est un système dans lequel l’espace disque de plusieurs machines est mis en commun et vu par toutes les machines du système comme une seule entité de manière transparente. Cela permet d’augmenter l’espace disponible en partageant la capacité des disques de chaque machine du système, ou d’augmenter la fiabilité du système en autorisant la réplication des données. Des exemples de systèmes de fichiers distribués sont le Network File System (NFS) [SCR+00], XTreemFS[HCK+07] ou encore le Hadoop Distributed File System [SKRC10]. Cette approche est utilisée dans de nombreux projets de stockage et de traitement de données multimédia. Par exemple, les projets RanKloud [Can11] et ImageTerrier [HSD11] reposent sur le système de fichiers distribué issu du projet Hadoop, le Hadoop Distributed File System [SKRC10]. Ce système de fichiers a la particularité de ne permettre que l’ajout et la suppression de fichiers. La modification des données n’est pas possible. Cette limitation ne pose pas de problème dans les systèmes de stockage et traitement de données multimédia, car les fichiers bruts ne font pas l’objet de modifications internes, mais sont copiés puis lus plusieurs fois de suite. Ce type de système est particulièrement adapté lorsque les données doivent être traitées en parallèle sur plusieurs machines par divers programmes, comme dans le système de traitement de données parallèle Hadoop [Whi09]. Stockage en base de données La solution la plus directe pour fournir l’accès à des données dans une plateforme de services est la mise au point d’une base de données relationnelle. D’après [Kos05] l’arrivée dans les années 90 des systèmes de bases de données orientés objets tels qu’Informix 1 ou Oracle 2 a permis l’émergence de systèmes plus efficaces pour représenter les données multimédia. Les standards MPEG-7 [MPE12b] et MPEG- 21 [Mpe12a], par exemple, ont fourni un cadre de représentation des données multimédia pouvant servir de référence pour la mise au point de schémas de base de données spéci- fiques. C’est cette approche qui a été retenue dans le projet de “base de donnée MPEG-7”, développée par M. Döller et décrite dans [Döl04]. En utilisant un système de gestion de bases de données objet, M. Döller a créé un nouveau schéma respectant le format de re- 1. http://www.ibm.com/software/data/informix/, consulté le 5 octobre 2013 2. http://www.oracle.com/us/products/database/overview/index.html, consulté le 5 octobre 2013 142.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA présentation fourni par le standard MPEG-7. Afin de parvenir à utiliser le langage SQL pour rechercher les données, les méthodes d’indexation ont aussi été étendues pour pouvoir indexer des données multi-dimensionnelles. Ceci permet aux utilisateurs de bénéficier de tous les mécanismes des bases de données traditionnelles et notamment d’utiliser le langage SQL pour la manipulation et la recherche de données multimédia. Les fichiers sont stockés soit en tant qu’objets binaires (BLOBs), comme simples champs d’une table, soit dans le système de fichiers, et seul le chemin vers les données figure dans la base. La principale limite de cette approche réside dans le fait que le système soit implémenté comme une extension du système commercial de bases de données Oracle. Il est donc difficilement envisageable d’ajouter de nouvelles fonctionnalités au système, en raison de l’interface de programmation de bas niveau nécessaire à ces changements. L’autre limite de cette approche est que le système n’est pas distribué, or, le volume de données généralement associé avec les bases de données multimédia peut nécessiter un fonctionnement réparti afin de multiplier la capacité de stockage et de traitement, ce qui n’est pas le cas dans ces travaux. Bases de données distribuées : Les bases de données distribuées permettent d’agréger la capacité de stockage de plusieurs machines au sein d’un seul système de base de données. Retenue par K. Chatterjee et al. [CSC09], cette approche consiste à utiliser les capacités existantes de systèmes de bases de données distribuées, comme par exemple MySql Cluster 3, et à adapter la base de données en ajoutant un index réparti permettant de retrouver rapidement les données recherchées sur l’ensemble des machines. IrisNet [GBKYKS03] est un réseau de capteurs pair à pair sur lequel les images et données des différents capteurs sont stockées dans une base de données XML. Les nœuds sont divisés en deux catégories : les "Sensing Agents" (SA) qui sont des machines de puissance moyenne reliées aux capteurs (webcam, météo, . . . ) et les "Organizing Agents" (OA) qui sont des serveurs sur lesquels sont déployés les services du réseau de capteurs. Les capteurs eux-mêmes sont des machines de puissance moyenne, avec peu ou pas de contraintes environnementales, et un espace de stockage important. 3. http://www.mysql.com, consulté le 5 octobre 2013 152.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA Ces nœuds appelés “Sensing Agents” sont utilisés pour déployer des “Senselets”, qui filtrent les données issues des capteurs. La base de données est distribuée sur les OA. Les utilisateurs peuvent requêter la base de données en utilisant le langage XPATH (langage de requêtage de données XML). Ces deux approches reposent sur les systèmes de base de données traditionnels fournissant de fortes garanties de cohérence des données, suivant le principe ACID (Atomicité, Cohérence, Isolation, Durabilité). Or, il a été démontré que lorsque la taille d’un système distribué augmente, fournir une garantie sur la cohérence des données du système ne permet pas d’assurer à la fois disponibilité et la performance de celui-ci. C’est le théorème de CAP, Consistency, Availability et Partition Tolerance (Cohérence, Disponibilité et Tolérance aux partitions) démontré par Gilbert et Lynch dans [GL02]. Les systèmes multimédias distribués ne nécessitent pas de supporter de fortes garanties de cohérence sur les données : les fichiers à traiter ne sont écrits qu’une seule fois puis lus à plusieurs reprises pour mener à bien les analyses voulues. Par conséquent, certains acteurs ont construit leur propre système de gestion de données multimédia en s’abstrayant de ces garanties, comme Facebook 4 l’a fait avec le système Haystack [Vaj09]. Les composants de ce système ne reposent pas sur une base de données relationnelle mais sur un index distribué permettant de stocker les images dans des fichiers de grandes tailles (100Go), ce qui permet de grouper les requêtes et de réduire les accès disques nécessaires à l’affichage de ces images. La particularité de ce système est que les images y sont peu recherchées, mais sont annotées par les utilisateurs pour y ajouter des informations sur les personnes présentes dans l’image et la localisation de la prise de vue. Un autre exemple de base de données distribuée utilisée pour stocker les données multimédia est celui de Youtube 5, qui utilise la base de données orientée colonnes BigTable [CDG+06, Cor07], pour stocker et indexer les aperçus de ses vidéos. Agrégation de bases de données : Le canevas AIR créé par F. Stiegmaier et al. [SDK+11] se concentre sur l’extensibilité en utilisant un intergiciel pour connecter plusieurs bases de données entre elles, et utilise des requêtes au format MPEG-7 [MPE12b]. 4. http://facebook.com, consulté le 5 octobre 2013 5. http://youtube.com, consulté le 5 octobre 2013 162.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA Cependant ces travaux restent dirigés sur la recherche de contenus plutôt que sur la détection d’éléments précis dans les images. Les données et leurs métadonnées (descripteurs) sont réparties sur différents systèmes de gestion de bases de données (SGBD) pouvant fonctionner sur différentes machines. Lorsque le système reçoit une requête, deux cas se présentent : soit les nœuds sont homogènes et la requête est envoyée à chaque machine puis les résultats sont fusionnés et / ou concaténés, soit les nœuds sont des systèmes différents (bases de données différentes) et seule la partie la plus adaptée de la requête est transmise au noeud le plus approprié. Les intergiciels LINDO[BCMS11] et WebLab[GBB+08] fournissent des modèles de représentations de données communs à plusieurs systèmes et permettent les transferts de données entre des services de traitements adoptant ce modèle. Ces systèmes ne reposent sur aucun système de stockage particulier mais permettent d’agréger différentes sources de données et différents services de traitements hétérogènes. La problématique de cette approche est la nécessité de devoir adapter les services et les traitements au modèle exposé par les interfaces d’un tel système. Une grande variété de solutions existent au problème du stockage des données multimédia. Un critère de choix possible est le type d’utilisation qui sera fait des données : par exemple un système d’extraction des connaissances fonctionnera mieux avec un système de fichiers distribué dans lequel les données sont accessibles de manière transparente, au contraire d’une base de donnée SQL qui requiert une interface particulière pour accéder aux données stockées. Dans le cadre du projet MCube l’accès aux données doit être possible de plusieurs manières : il faut pouvoir fournir un accès permettant de traiter les données en parallèle ainsi qu’une interface permettant de requêter les données générées par les ré- sultats des analyses effectuées. Le système se rapprochant le plus de ce cas d’utilisation est donc l’utilitaire HADOOP [Whi09], qui fournit à la fois un système de haut niveau pour requêter les données et un accès de bas niveau via le système de fichiers distribué. 2.2.2 Distribution des traitements Un volume important de données à analyser se traduit par la nécessité de paralléliser le traitement des données, de manière à réduire les temps d’exécution. Cependant, tous 172.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA les systèmes de stockage de données multimédia ne permettent pas de traitement parallèle des données. Dans le domaine des traitements de données multimédia il est possible de distinguer deux manières de traiter les données[Can11] : les traitements à la chaîne (Multiple Instruction Multiple Data, MIMD) et les traitements parallèles (Single Instruction Multiple Data, SIMD). Traitements à la chaîne : Multiple Instruction Multiple Data Le système est constitué de plusieurs unités, chacune exécutant une étape particulière d’une chaine de traitements. Les données passent d’une étape à l’autre en étant transférées d’une entité à l’autre, de sorte que plusieurs données sont à différents stades de traitement au même instant. Le projet WebLab [GBB+08] est une architecture de traitement de données multimé- dia orientée service qui permet de faciliter le développement d’applications distribuées de traitement multimédia. Cette plateforme repose sur un modèle de données commun à tous ses composants représentant une ressource multimédia. Ce modèle ne repose pas sur un standard mais permet de créer des ressources conformes au standard MPEG-7. La raison de ce choix est que le standard MPEG-7 a été créé en 2002 et ne permet pas de bénéficier des dernières avancées en matière de descripteurs de données multimédias. Cette repré- sentation générique permet d’associer à chaque ressource des “annotations” représentant le contenu extrait de la ressource (appelés “morceaux de connaissance”). Les services disponibles se divisent en services d’acquisition, services de traitements, services de diffusion. Le modèle de données commun permet à ces différents services de pouvoir être composés pour créer des flux de traitements, de l’acquisition à la diffusion du contenu multimédia. Cette solution se veut très flexible et générique mais ne propose pas de solution en ce qui concerne la répartition des traitements. Le système SAPIR (Search in Audio-visual content using Peer-to-peer Information Retrieval) [KMGS09] est un moteur de recherche multimédia implémentant la recherche par l’exemple : il permet de retrouver à partir d’un document multimédia donné les documents similaires ou correspondant au même objet. SAPIR utilise le Framework apache UIMA [UIM12] pour extraire les informations nécessaires à l’indexation des données au 182.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA format MPEG-7. Les flux ou fichiers reçus sont divisés en plusieurs modalités : par exemple dans le cas d’une vidéo, un “splitter” va séparer le son des images, puis la suite d’images va aussi être divisée en plusieurs images fixes, chaque élément ainsi extrait va ensuite être traité par un composant spécifique pour le son, la vidéo et les images le tout de façon parallèle. Une fois la phase d’extraction terminée le fichier d’origine est recomposé en intégrant les métadonnées qui en ont été extraites. UIMA rend la main au système SAPIR, qui va insérer le fichier dans son index distribué en se basant sur les métadonnées que le fichier contient désormais. Le système utilise une architecture pair à pair pour stocker et répartir les données. Cependant, la dépendance du système SAPIR avec Apache UIMA, destine ce système uniquement à la recherche de contenus multimédia plutôt qu’à servir de plateforme de traitement de données multimédia générique. Traitement en parallèle : Single Instruction Multiple Data (SIMD) Ce type de système sépare les étapes du traitement dans le temps plutôt que dans l’espace : à chaque étape du traitement, toutes les machines du système exécutent le même traitement en parallèle sur l’ensemble des données. C’est le modèle suivi par le framework Hadoop [Whi09] pour traiter les données. Ce framework générique de traitement de données massives en parallèle est utilisé dans plusieurs systèmes de traitements de données multimédia. Par exemple, les travaux menés dans le cadre du projet RanKloud [Can11] utilisent et étendent le framework HADOOP [Whi09] pour répondre à des requêtes de classement, ainsi que pour permettre des jointures dans les requêtes portant sur plusieurs ensembles de données. Pour cela le système échantillonne les données et évalue statistiquement leur répartition pour optimiser certaines procédures (notamment les opérations de jointures). Un index des données locales est construit sur chaque machine du système, permettant à chaque nœud de résoudre les requêtes localement et d’envoyer les résultats à une seconde catégorie de nœuds qui assureront la finalisation des requêtes. Cependant ce système est conçu pour analyser une grande quantité de données et non pas pour répondre à des requêtes en temps réel, et se destine plutôt à des requêtes de recherche de contenus. Le projet Image Terrier [HSD11] est un système d’indexation et de recherche d’images 192.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA et de vidéos fondé sur le système de recherche textuelle Terrier 6. Ce système utilise lui aussi la technique de distribution des traitements fournie par le canevas HADOOP afin de construire incrémentalement l’index des images. Ce système présente l’avantage d’être très ouvert, mais il est uniquement destiné à la recherche de contenus. Limites des outils existants Ces deux types de répartitions ne sont pas exclusives et les deux approches peuvent être combinées de manière à augmenter l’efficacité d’un système. Il est ainsi possible de créer des flux de travaux enchaînant différentes étapes de traitement ou les exécutant en parallèle. La principale limite des outils existants réside dans le fait que les traitements répartis font partie d’une bibliothèque logicielle utilisant un canevas donné, comme ImageTerrier [HSD11] et Hadoop. Or, dans le projet MCube, les traitements à répartir sont codés et compilés sans suivre d’API ou de canevas logiciel particulier. Il est aussi parfois nécessaire d’exécuter les traitements à la demande au fur et à mesure de l’arrivée des données. Dans ce contexte il apparait donc nécessaire de faire appel à des plateformes de plus haut niveau permettant d’adapter les traitements à leur contexte d’exécution. 2.2.3 Plateformes génériques de traitements de données multimédias La recherche en matière de traitement des données multimédia se concentre aussi pour une large part sur la conception de nouveau algorithmes d’extraction d’informations. Le système doit fournir un catalogue de services permettant de procéder aux extractions de données et aux analyses voulues par l’utilisateur. Cette librairie doit être extensible afin de permettre aux utilisateurs d’y implanter leurs propres analyses. L’ouverture d’un système se mesure à sa disponibilité, et à sa capacité à s’interfacer avec d’autres systèmes de manière à pouvoir être utilisé dans différents contextes. Plusieurs systèmes de stockage évoqués dans ce chapitre sont décrits dans la littérature mais ne sont pas disponibles pour évaluation, du fait du peu de cas d’utilisations qu’ils permettent de résoudre. Par exemple le système Haystack développé par Facebook ne fait pas l’objet d’un développement à l’extérieur de l’entreprise. Le projet RanKloud bien que décrit dans diverses publications, n’est pas 6. http://terrier.org/, consulté le 5 octobre 2013 202.2. COMPOSANTS DES PLATEFORMES DE STOCKAGE DE DONNÉES MULTIMÉDIA publiquement disponible. De même, peu de projets sortent du simple cadre du prototype de recherche, comme par exemple le projet LINDO [BCMS11]. Le projet LINDO [BCMS11] a pour objectif de développer une infrastructure géné- rique de traitement de données multimédia permettant de distribuer les traitements et les données, en assurant l’interopérabilité de différents systèmes de traitement de données multimédias. Il a permis la mise au point d’une infrastructure d’indexation générique et distribuée. Pour cela, un modèle de données représentatif a été créé pour les données multimédia et pour les algorithmes d’indexation de ces données. Les données sont donc réparties sur un système de fichiers distribué et le système sélectionne l’algorithme d’indexation le plus approprié en fonction des requêtes les plus féquemment envoyées par l’utilisateur. Ce système a été appliqué à la vidéosurveillance, pour détecter des événements dans les flux vidéo. C’est une plateforme multi-utilisateurs, qui peut être utilisée dans plusieurs domaines à la fois, et permet de représenter les données au format MPEG-7 ou MPEG-21. Cependant les informations ne sont extraites qu’à la demande explicite des utilisateurs (à travers une requête) et traversent toutes un serveur central qui contrôle les machines indexant les contenus. Ce système risque donc de limiter l’élasticité de la solution. L’élasticité d’un système est sa capacité à s’adapter à l’apparition ou la disparition dynamique de nouvelles ressources. Cette notion est particulièrement importante dans le contexte des plateformes de Cloud Computing, où les ressources peuvent être allouées et disparaître rapidement. Le projet WebLab est un projet libre 7, il est construit sur le même principe d’interface et de modèle d’échange de données que le projet LINDO. Le projet WebLab ne modélise pas les traitements, mais seulement le format des données à échanger entre différentes plateformes de traitements hétérogènes. Ce système repose sur le bus de service Petals 8 pour ses communications, or ce composant semble posséder des problèmes de performance comme le montre les résultats de différents bancs d’essais successifs 9. Ces deux systèmes servent donc d’intergiciels pour la communication entre différentes plateformes de traitements et permettent l’agrégation de différents sites ou grilles spécialisés 7. http://weblab-project.org/, consulté le 5 octobre 2013 8. http://petals.ow2.org/, consulté le 5 octobre 2013 9. http://esbperformance.org/display/comparison/ESB+Performance+Testing+-+Round+6, consulté le 5 octobre 2013 212.3. ANALYSE dans certaines étapes de traitement. Le propos du projet MCube est au contraire de concentrer les données des différents utilisateurs afin de mutualiser la plateforme de traitement et permettre des économies d’échelles en matière de stockage et de capacité de calcul. Ce projet se situe à un niveau intermédiaire entre les systèmes de traitements de données de bas niveau (ImageTerrier, Hadoop, ...) et ces plateformes de fédération que sont les projets LINDO et WebLab. Il s’agit donc d’un système multi-tenant, car il sert plusieurs clients en mutualisant ses ressources. 2.3 Analyse Les systèmes de stockage et de traitements multimédias décrits ici possèdent diverses architectures. Les architectures fondées sur les bases de données traditionnelles laissent peu à peu place à des systèmes basés sur les technologies issues des plateformes Web à large échelle telles que le canevas Hadoop [Whi09]. Bien que l’adoption de ces solutions se démocratise, il n’existe pas pour le moment d’alternative permettant de tirer parti des différents services de ces plateformes sans nécessiter de développement supplémentaire pour être adapté à l’environnement cible. De plus, hormis les initiatives telles que LINDO, Weblab ou ImageTerrier, peu de projets dépassent le stade du prototype de recherche. Pour une large part, ces projets servent de plateformes d’évaluation des algorithmes d’extraction de connaissances et d’indexation, ou sont orientés vers la recherche de contenus. Le tableau 2.1 résume les propriétés disponibles pour chacun des systèmes listés dans les sections précédentes, par rapport aux défis décrits dans la section 2.1.2 de ce chapitre. L’examen des différentes plateformes de stockage et de traitement de données multimé- dias montre qu’il n’existe pas, actuellement, de projets remplissant le cahier des charges du projet MCube. Il existe des plateformes de traitements de données génériques, qui ne sont pas spécialisées dans les données multimédia, comme le canevas Hadoop, et qui peuvent donc servir de base à la plateforme MCube. 222.4. ARCHITECTURE DE LA PLATEFORME MCUBE Table 2.1 – Propriétés des systèmes de traitements de données multimédias Stockage Traitements Mutualisation ouverture Elasticité Système Données Descripteurs Informations Descripteurs Indexation Informations Mpeg-7 DB oui oui non oui oui non oui non non AIR distribué distribué non oui distribué non oui non limitée Lindo distribué distribué non distribué distribué oui oui limitée limitée Weblab distribué distribué non non non non oui limitée limitée SAPIR distribué distribué non oui oui non oui limité oui IrisNet distribué distribué distribués oui distribué oui oui oui oui [CSC09] distribué distribué non oui distribué non oui non oui RanKloud distribué distribué non distribué distribué non oui non oui Haystack distribué distribué distribués distribué distribué oui non non oui ImageTerrier distribué distribué non distribué distribué non non oui oui 2.4 Architecture de la plateforme MCube 2.4.1 Architecture matérielle Passerelles MCube. Les passerelles MCube sont des appareils mis au point par la société Webdyn 10. Il s’agit d’un système embarqué reposant sur le système Linux et un processeur ARM. La présence du système d’exploitation complet permet de connecter divers périphériques d’acquisition de données multimédias comme des appareils photos ou des micros. Le système de la passerelle exécute un planificateur de tâches pouvant être configuré à distance en recevant des commandes depuis les serveurs MCube. Le rôle des passerelles est d’assurer l’exécution à intervalles réguliers (configurés par l’utilisateur) d’un programme appelé "librairie passerelle" actuellement déployé sur le système. Les passerelles sont équipées d’un port Ethernet et d’un modem 3G permettant de se connecter à internet pour dialoguer avec le serveur MCube. Serveurs MCube. Les serveurs MCube sont trois machines Dell équipées chacune de deux processeurs intel Xeon embarquant 8 cœurs chacun. L’espace de stockage important sur les machines (8 téraoctets par serveur) permet d’anticiper sur la quantité de données à stocker dans le cadre du projet MCube, dont les collectes annuelles peuvent représenter dans certains cas plusieurs centaines de gigaoctets par mois. 10. http://www.webdyn.com, consulté le 5 octobre 2013 232.4. ARCHITECTURE DE LA PLATEFORME MCUBE 2.4.2 Architecture logicielle L’architecture logicielle du projet MCube a été conçue de manière à permettre aux utilisateurs de pouvoir eux-mêmes développer les applications déployées sur les passerelles et la plateforme. Pour cela, une interface de programmation a été mise au point par le constructeur de la passerelle, la société WebDyn 11, permettant de séparer les tâches d’acquisition des données de leur planification. Les composants développés sur cette interface sont appelés "librairies passerelles". Les librairies de passerelles sont des librairies dynamiques implantant les fonctions de l’interface de programmation MCube, ce qui permet de les déployer à la demande depuis la plateforme Web du projet. Ces librairies sont développées pour remplir deux fonctions principales : – L’acquisition des données : C’est la fonction essentielle de ces librairies, elle consiste à piloter les différents périphériques de capture de données multimédia connectés à la passerelle pour acquérir des données brutes : photos, sons, vidéos. – Filtrage des données : Dans certains cas, les données capturées peuvent être volumineuses. Par exemple, un cas d’utilisation possible du service MCube consiste à détecter la présence d’insectes nuisibles à partir d’enregistrements sonores. Dans ce cas précis les données enregistrées ne sont envoyées au serveur que lorsqu’un signal suspect est détecté dans l’enregistrement. Un traitement plus précis exécuté à la demande sur le serveur permet ensuite de confirmer ou d’infirmer la détection. La communication entre les passerelles et les serveurs repose sur un protocole HTTP/ REST qui permet aux passerelles : – d’envoyer des données collectées à la plateforme MCube via le serveur Web, – de recevoir une nouvelle librairie, – de recevoir des commandes à transmettre à la librairie déployée sur la passerelle. 2.4.3 Architecture de la plateforme MCube La plateforme MCube a un rôle de gestion des équipements et d’agrégation d’information. Elle assure la communication avec les passerelles déployées, en permettant aux utilisateurs de les configurer à l’aide d’une interface web. La plateforme fournit aux utilisa- 11. http://www.webdyn.com/, consulté le 5 octobre 2013 242.4. ARCHITECTURE DE LA PLATEFORME MCUBE teurs l’accès aux librairies et programmes d’analyse de données qu’ils ont développés. Les données transférées par les passerelles sont stockées sur les serveurs de la plateforme, et une interface web permet aux utilisateurs de lancer ou de programmer les analyses qu’ils souhaitent exécuter sur les données téléchargées depuis les passerelles. L’architecture finale de la plateforme MCube repose sur trois composants logiciels : Demandes de traitements mcube.isep.fr Cloudizer Utilisateurs Passerelles Envoi de données Consultation des données Configuration HDFS HDFS HDFS Noeuds de stockage / traitement Stockage / consultation données passerelles et traitements Requêtes de traitements Service Web MCube Figure 2.3 – Architecture de la plateforme MCube L’interface Web C’est l’interface utilisateur du système. Elle permet aux agriculteurs de gérer leurs passerelles et d’accéder à leurs données afin de les récupérer dans le format qu’ils souhaitent ou de lancer / planifier les traitements à effectuer. De plus l’interface permet aux utilisateurs de charger de nouveaux programmes de traitements de données. Le canevas Hadoop Le système Hadoop permet de stocker les données de manière répartie via le système de fichiers distribué HDFS [SKRC10]. Il permet d’avoir un système de fichiers redondant pouvant accueillir un grand nombre de machines. De plus, les données ainsi stockées peuvent être accédées à l’aide de langages de plus haut niveau tel que le langage de requêtage HQL (Hive Query Language) [TSJ+09] 252.4. ARCHITECTURE DE LA PLATEFORME MCUBE Le canevas Cloudizer Le framework Cloudizer est un canevas logiciel développé durant cette thèse qui permet de distribuer des requêtes de services web à un ensemble de machines. Ce système est utilisé pour traiter les fichiers envoyés par les passerelles au fur et à mesure de leur arrivée dans le système. La figure 2.3 montre comment s’articulent les différents composants de la plateforme. Les données de configuration, les informations utilisateurs, et les coordonnées des passerelles sont stockées dans une base de données SQL traditionnelle (MySql 12). Les données remontées par les passerelles, ainsi que les librairies et les programmes d’analyses sont stockés dans le système HDFS [SKRC10]. Chaque utilisateur possède un répertoire dédié sur le système de fichiers distribué. Ce répertoire contient les fichiers reçus des passerelles et classés par nom de la librairie d’origine des données. Les résultats des traitements effectués sur ces données sont stockés dans un répertoire dédié et classés par noms de traitements et date d’exécution. Ceci permet aux utilisateurs de pouvoir retrouver leurs données de manière intuitive. Les utilisateurs peuvent choisir deux modes de traitement des données : un mode évé- nementiel et un mode planifié. Lorsque le mode événementiel est sélectionné, l’utilisateur définit le type d’événement déclenchant le traitement voulu : ce peut par exemple être l’arrivée d’un nouveau fichier ou le dépassement d’un certain volume de stockage. Le traitement est alors exécuté sur les données désignées par l’utilisateur. Le mode planifié correspond à une exécution du traitement régulière et à heure fixe. Le déclenchement des traitements est géré par la plateforme Cloudizer décrite dans le chapitre suivant. 2.4.4 Description des algorithmes de traitement de données multimédia Les utilisateurs de la plateforme peuvent charger de nouveaux algorithmes de traitement de données multimédia. Pour que le système puisse utiliser cet algorithme, il est nécessaire d’en fournir une description afin de le stocker dans la base de données. Le terme "algorithme" désigne ici par abus de langage l’implantation concrète d’un algorithme donné, compilée sous la forme d’un programme exécutable. Un modèle type de ces algorithmes a donc été conçu, il est représenté en figure 2.4. Ce schéma est inspiré des travaux sur 12. www.mysql.com, consulté le 5 octobre 2013 262.4. ARCHITECTURE DE LA PLATEFORME MCUBE l’adaptation de composants de [AGP+08, BCMS11] et [GBB+08]. Figure 2.4 – Modèle de description d’algorithme Un programme et l’ensemble de ses fichiers sont décrits par la classe "Algorithm". Cette classe contient une liste qui permet de spécifier les fichiers exécutables et de configurations nécessaires à l’exécution du programme. Un programme est généralement exécuté avec des paramètres fournis sur l’entrée standard, la liste des paramètres (la classe "Parameter") décrit les paramètres à fournir à l’exécutable ainsi que leurs positions et préfixes respectifs si besoin. La classe "OutputFormat" permet de décrire le type de donnée en sortie de l’exécution du programme. Par exemple, la sélection du format ”TextOuput” signifie que la sortie du programme sur l’entrée standard correspond à des données textes tabulaires, séparées par un caractère spécifique. D’autres formats sont disponibles et peuvent être ajoutés à la librairie. Exemple de modèle d’algorithme : Calcul de tailles de tomates Le listing 2.1 présente un exemple de modèle d’algorithme pour un programme développé dans le cadre du projet MCube. Dans ce cas d’utilisation, un dispositif expérimental a été mis au point par les membres de l’équipe de traitement du signal de l’ISEP, afin de prendre en photo un 272.4. ARCHITECTURE DE LA PLATEFORME MCUBE plant de tomates selon deux angles différents. Grâce à ce décalage et un calibrage précis du dispositif, il est possible de donner une estimation de la taille des tomates détectées dans les photos, si leurs positions sont connues. Cet algorithme prend en entrée deux listes de points correspondants respectivement aux contours droit et gauche d’une tomate du plant photographié, et fournit une estimation de la taille du fruit. Listing 2.1 – Exemple d’instance du modèle d’algorithme tomate_measurement 1. 0 U j jwal Verma Detection de visages methode de Viola!Jones , l i b r a i r i e OPEN!CV t x t tomate_measurement . j a r leftImageContours rightImageContours

Cet algorithme est implémenté en java sous la forme d’une archive JAR. Cependant le système le voit comme une boite noire et ne connait donc que les paramètres à lui fournir en entrée et le type de données en sortie. Cette information sur les paramètres à fournir permet de pouvoir commander l’exécution du programme à la demande, via un service 282.5. DÉVELOPPEMENT DU PROJET Web utilisant le canevas Cloudizer décrit au chapitre 3. 2.5 Développement du projet La conception détaillée de la plateforme Web MCube et son modèle de données a été faite par l’auteur de ce document. Le développement de l’interface Web permettant la gestion des passerelles et le stockage des librairies ont été fait par trois stagiaires de niveau Master 1 et 2. Le mode de développement s’est fondé sur des itérations courtes (une à deux semaines), en donnant des objectifs de fonctionnalités précises à développer durant ce laps de temps, via une feuille de route établie à l’avance. Chaque nouvelle fonctionnalité était testée manuellement puis déployée sur le serveur de production du projet 13. Cette approche de développement d’application rapide a été facilitée par l’utilisation du canevas Grails comme base au projet. L’interface web de la plateforme représente un volume de 4000 lignes de code en langage Groovy. Mon rôle au niveau du développement de ce système s’est donc limité à la conception de la base de données, puis à la supervision et aux tests fonctionnels des développements réalisés, ainsi qu’à la correction de quelques bogues éventuels trouvés lors des phases de tests. Le code doit encore faire l’objet d’une intégration avec le projet Cloudizer pour assumer l’ensemble des fonctionnalités attendues. Il sera à terme disponible sous forme de programme libre, sous réserve d’acceptation par les parties prenantes du projet. 2.6 Discussion Le projet MCube est une architecture logicielle de collecte et de traitement de données multimédias destinée à fournir des services avancés de détection et de surveillance aux agriculteurs. La mise au point de ce système nécessite de faire interagir différents composants logiciels hétérogènes. La problématique de la distribution et de l’exécution en parallèle de traitements de nature spécifique, a des conséquences sur le choix de la plateforme utilisée pour cette répartition et sur son efficacité. L’architecture finale s’appuie donc sur trois services : un serveur d’applications destiné à la communication avec les utilisateurs du 13. http://mcube.isep.fr, consulté le 5 octobre 2013 292.6. DISCUSSION système et les services extérieurs, un système de fichiers distribués permettant de stocker différents fichiers tout en permettant différents modes d’accès aux données stockées en son sein, et un système de gestion de services et de distribution de requêtes qui assurera la répartition de la charge lors du traitement des données. Ce service, appelé Cloudizer et développé au cours de cette thèse, permet à l’utilisateur de choisir différentes stratégies de répartition de charge, et de comparer leur performances respectives pour un même service. La mise au point de stratégies de répartition adéquates est donc nécessaire. Le chapitre suivant décrit l’architecture technique du projet Cloudizer et son intégration au projet MCube. 30Chapitre 3 Le framework Cloudizer : Distribution de services REST 3.1 Introduction Cloudizer est une plateforme logicielle ouverte permettant de déployer, répartir et superviser des services web REST. Cette plate-forme est destinée à faciliter le déploiement et la répartition d’applications existantes sur les plateformes d’informatique dans les nuages de type "infrastructure à la demande". Cloudizer a été développé avec deux objectifs : premièrement faciliter le développement et le déploiement de stratégies de répartition de charge adaptées aux applications, en fournissant une interface de programmation suffisamment expressive et claire pour le programmeur. Deuxièmement la plateforme doit assurer la disponibilité de plusieurs services différents en permettant de choisir la stratégie de répartition de charge la plus appropriée pour chacun de ces services. Pour assurer cette répartition, le problème de conservation de l’état du service se pose. Lorsqu’un service web maintient des informations sur chacun des clients qui lui sont connectés par exemple, il est nécessaire de toujours renvoyer les requêtes de ce client vers la machine qui possède les informations le concernant, ce qui réduit considérablement les possibilités de répartition de la charge. Ce constat a été établi par Roy T. Fielding dans sa thèse publiée en 2000 [Fie00], où il propose d’organiser les services client-serveur autour du principe "Representational State Transfer" (REST). Selon ce principe, les séquences de requêtes et de réponses des systèmes clients serveurs sont considérées comme une suite 313.2. ARCHITECTURE DU CANEVAS CLOUDIZER d’échanges d’objets appelés "ressources". A chaque échange, une représentation particulière de la ressource considérée est transmise. Le client transmet au serveur les informations né- cessaires pour retrouver la ressource associée à chaque requête, de sorte que le serveur n’ait pas à maintenir d’information sur la séquence d’échange en cours. Le serveur ne maintient donc pas d’état entre les requêtes, ce qui simplifie sa distribution car il n’y a pas d’état à synchroniser entre les machines. Le système Cloudizer permet de gérer et répartir l’exécution de services web sur un ensemble de machines de deux manières : soit en exécutant les requêtes au fil de l’eau, soit en les exécutant en parallèle, par lots de requêtes. Ce comportement est approprié dans le contexte de la plateforme MCube, qui a besoin de ces deux modes de fonctionnement pour gérer les traitements des données multimédia. La première partie de ce chapitre décrit donc l’architecture et le fonctionnement gé- néral de la plateforme Cloudizer 3.2. La seconde partie de ce chapitre est consacrée aux mécanismes permettant d’intégrer Cloudizer dans la plateforme MCube 3.3. La conclusion de ce chapitre (section 3.5) discutera des limites de cette approche et les développements nécessaires pour l’améliorer. 3.2 Architecture du canevas Cloudizer Cloudizer tire partie de l’architecture multi-tiers de la plupart des applications Web pour permettre la répartition de charge. Comme le montre la figure 3.1, le code du service à distribuer est répliqué sur toutes les machines du système. La gestion des données est déléguée à une base de données répartie, et la gestion des fichiers d’application est déléguée à un système de fichiers distribué. Ce découplage permet à la plateforme de n’assurer que la répartition des traitements. Les composants de cette plateforme communiquent via des services REST. Ces composants sont au nombre de trois, il s’agit du répartiteur, du contrôleur et de la librairie déployée sur les machines du système, appelées "nœuds". La répartition est assurée par le répartiteur qui filtre les requêtes. Lorsqu’une requête d’exécution destinée à un service déployé arrive, elle est envoyée vers les nœuds Cloudizer selon la stratégie de répartition sélectionnée par l’utilisateur et appliquée par le répartiteur. 323.2. ARCHITECTURE DU CANEVAS CLOUDIZER Contrôleur Cloudizer Application Serveur HTTP Internet Serveur Maître Système de fichiers distribué Base de données fragmentée Librairie Cloudizer Service Web Répliqué Serveur HTTP Noeud Cloudizer Système de fichiers distribué Base de données fragmentée Librairie Cloudizer Service Web Répliqué Serveur HTTP Noeud Cloudizer Système de fichiers distribué Base de données fragmentée Appel aux services non-répliqués Réplication Répartiteur Appel au service web répliqué Figure 3.1 – Architecture de la plateforme Cloudizer Dans tous les autres cas, la requête est transmise à l’application déployée sur le serveur maître. Le but de ce système est de parvenir à répartir le service de manière transparente. Pour cela le code de l’application est répliqué sur tous les nœuds, mais les fichiers ou les bases de données sont répartis via l’utilisation d’un système de fichiers distribué type “HDFS” ([SKRC10]) ou d’une base de données utilisant la fragmentation horizontale. 3.2.1 Les nœuds Les nœuds de la plateforme Cloudizer sont des machines sur lesquelles la librairie Cloudizer est déployée. Cette librairie fournit les routines nécessaires à l’enregistrement et au déploiement de nouveaux services sur la machine où elle s’exécute. Le seul paramètre de configuration nécessaire au fonctionnement du programme est l’adresse du Contrôleur. Quand un nœud (nœud Cloudizer ) s’enregistre dans le système, il envoie à une fréquence pré-configurée des "battements de coeur" au contrôleur afin que celui-ci puisse connaître 333.2. ARCHITECTURE DU CANEVAS CLOUDIZER les nœuds actifs. Les nœuds enregistrent également la liste des services web actifs sur la machine. Chaque nœud est donc responsable de la supervision des services de la machine sur laquelle il est déployé et reporte son statut au contrôleur. Ce statut contient les informations décrivant la machine telles que le nombre de cœurs, la capacité de stockage, la taille de la mémoire et le taux d’utilisation du processeur. Les nœuds dialoguent avec le contrôleur via une interface de programmation REST. Une seconde interface de programmation est utilisée entre les nœuds pour procéder à des appels de méthodes à distance. Les souches d’appels sont générées dynamiquement par le nœud Cloudizer à partir de l’inspection de l’interface des méthodes cibles par réflexion. Les paramètres effectifs sont automatiquement encodés au format U.R.L (Universal Resource Locator). Les données de résultats de ces invocations sont, quant à elles, converties au format XML et décodées lors de la réception. Les machines peuvent donc servir de mandataires pour appeler des services distribués. 3.2.2 Le répartiteur Le rôle de ce composant est d’appliquer la politique de répartition de charge spécifiée par l’utilisateur pour transférer les requêtes aux services déployés dans le système. Différentes politiques de répartition de charge peuvent être appliquées en fonction de l’application. Une interface Java permet l’implémentation de nouvelles stratégies de répartition. L’utilisateur précise ensuite le nom de la classe implémentant la politique de répartition voulue dans la configuration du répartiteur pour l’appliquer sur le service qu’il souhaite répartir. La figure 3.2 montre le modèle utilisé pour implanter ces stratégies. La classe abstraite Policy fournit la méthode virtuelle loadBalance qui renvoie une machine cible après avoir pris en paramètre la liste des machines disponibles et les paramètres de la requête en cours. Lorsqu’une requête concernant un service déployé sur la plateforme arrive au niveau du répartiteur, la servlet CloudFrontend est appelée et exécute la méthode loadbalance définie pour le service cible. Les stratégies sont chargées lors de l’initialisation du répartiteur, en fonction de la confi- guration définie par l’utilisateur. Lorsque le répartiteur reçoit une nouvelle requête, il vérifie que la requête vise un service pour lequel des machines sont disponibles en interrogeant le 343.2. ARCHITECTURE DU CANEVAS CLOUDIZER Figure 3.2 – Modèle des stratégies de répartition de charge contrôleur. Si aucune machine n’est disponible, une erreur est renvoyée. Si des machines sont disponibles pour le service demandé, le répartiteur peut procéder au transfert de la requête de deux manières différentes : à la volée, c’est à dire que chaque requête reçue est immédiatement transférée à la machine implantant le service, soit en parallèle : la requête et ses paramètres sont découpés de manière à former un ensemble de plusieurs requêtes distinctes, qui sont envoyées en même temps et de manière asynchrone à un ensemble de machines pour être exécutées en parallèle. Exécution requête par requête Pour chaque requête reçue, le répartiteur applique la stratégie de répartition sélectionnée par l’utilisateur pour choisir une machine cible, puis transfère directement la requête à la machine sélectionnée. Exécution des requêtes en parallèle Un service peut être appelé de plusieurs machines / clients à la fois. Toutefois, certains services peuvent être appelés en parallèle sur plusieurs machines en cas de besoin, ce qui permet de réduire le temps d’exécution total. Le résultat sera donc l’agrégation de plusieurs résultats produits sur différentes machines. Pour cela deux modes d’appels sont possibles : un mode d’appel parallèle simple où chaque nœud disponible reçoit une part égale de requêtes à exécuter pour le service appelé, et un mode avec équilibrage de charge où les requêtes d’exécution à agréger sont réparties en 353.3. INTÉGRATION AU PROJET MCUBE suivant une politique de distribution choisie par l’utilisateur. 3.2.3 Déploiement de services Cloudizer permet de superviser et déployer des services web. Lorsqu’un nœud Cloudizer est déployé, le service est configuré via un fichier de propriétés décrivant les différentes informations nécessaires à l’identification du service. Un service est identifié par un nom et un numéro de port. Lors du lancement du nœud cloudizer, la librairie enregistre la machine et le service correspondant auprès du Contrôleur, qui met à jour le statut du service dans sa base de données et fait apparaître cette instance comme disponible. 3.3 Intégration au projet MCube La plupart des algorithmes de traitement d’images ou de sons destinés à la plateforme MCube sont écrits sans considération pour le traitement de gros volumes de données. Or, dans le contexte de ce projet, les programmes de traitement des fichiers multimédias doivent s’exécuter sur un nombre important de fichiers à la fois, qui plus est sur une architecture de stockage distribuée. Afin d’adapter de manière transparente les algorithmes utilisés à ce contexte, le projet Cloudizer a été utilisé pour déployer et exécuter les programmes à la demande en fonction des besoins. Ainsi, un binaire exécutable peut être converti en service web à l’aide d’une description XML du programme suivant le schéma représenté en figure 2.4. Il est plus efficace d’envoyer le programme exécutable vers les données plutôt que de lui faire lire les données depuis le réseau. Ce principe est au centre des plateformes de traitement de données massives comme le système Hadoop[Whi09]. Un fichier de description XML comme celui figurant dans le listing 2.1 doit être créé pour représenter un programme et le déployer dans le système. La librairie Cloudizer contient un utilitaire permettant de créer une arborescence où seront stockés les binaires du programme et tous les dossiers et dépendances nécessaires. Deux autres dossiers sont créés par défaut : un dossier INPUT et un dossier OUTPUT. Le dossier INPUT est destiné à stocker les fichiers en entrée du programme, et le dossier OUTPUT à stocker les fichiers en sortie, à la suite d’une exécution. Une fois l’arborescence créée, il est possible d’y exécuter un serveur 363.3. INTÉGRATION AU PROJET MCUBE Méthode Paramètres Action GET - Nom du service, - Paramètres tels que décrits dans le fichier description.xml Renvoie le contenu d’un fichier de résultat correspondant aux paramètres donnés. Renvoie une erreur 404 si le fichier n’existe pas. POST Nom du service, Paramètres Exécute le programme représenté par le service. Renvoie une erreur 500 en cas de problème à l’exécution. PUT Nom du service, fichier à transférer Copie le fichier donné en paramètre dans le répertoire INPUT du service. DELETE Nom du service, nom de fichier Supprime le fichier indiqué en paramètres des répertoires du service Table 3.1 – Protocole HTTP : exécution de services de traitement de données HTTP, qui sera identifié par le nom du programme précisé dans le fichier XML. Ce serveur répond aux requêtes HTTP GET, POST, PUT et DELETE avec la sémantique détaillée en tableau 3.1. Sécurité des exécutions Les exécutables convertis de cette manière en services web peuvent être exposés à des attaques par des utilisateurs malicieux. Limiter le risque d’attaques est primordial, dans la mesure où les programmes déployés sur la plateforme sont des boites noires dont le fonctionnement est inconnu. Le serveur utilise donc l’utilitaire "Jail" [KW00] qui permet d’exécuter des binaires dans un environnement limité au strict minimum, ce qui réduit les risques d’opérations illégales ou accidentelles sur des fichiers de configuration ou système. De plus, le fichier de description précise rigoureusement les types de données attendus pour les paramètres du programme, ce qui permet au serveur de refuser les requêtes qui ne respectent pas la signature attendue de l’appel. La dernière contre-mesure est de limiter autant que possible l’exposition de ces services en leur interdisant l’accès au réseau, qui n’est donc obtenu que par le serveur généré par Cloudizer. Exécution asynchrone L’exécution du service en mode asynchrone permet d’alléger la charge de la machine appelant le service en raccourcissant le temps de la connexion entre le client et le serveur, via l’utilisation d’une fonction de rappel distribuée. Ceci est particulièrement utile lorsque le service demandé a une latence élevée et met donc un temps 373.4. CONSIDÉRATIONS SUR L’IMPLÉMENTATION significatif à s’exécuter : maintenir une connexion ouverte pendant plusieurs secondes sans que des données ne circulent n’est pas utile. La contrepartie est que la machine appelante doit rester à l’écoute du serveur qui lui enverra le résultat d’une requête GET sur les mêmes paramètres une fois le service achevé. Ce fonctionnement est similaire à celui d’une fonction de rappel distribué. Ce rôle de client appelant peut être assuré par le répartiteur ou le contrôleur en cas de besoin. Ce mécanisme est particulièrement utile en conjonction de l’invocation parallèle décrite en section 3.2.2, car cela permet d’alléger la charge de l’entité appelante. La gestion des erreurs et des résultats retournés fonctionne de la même manière que pour un appel synchrone. 3.4 Considérations sur l’implémentation Au cours de cette thèse, l’effort principal de développement s’est concentré sur la réalisation du répartiteur du système Cloudizer. Les premières versions de ce système de répartition étaient implantées directement dans l’interface web du système et souffraient des problèmes de performance du langage Groovy. Le principal facteur d’amélioration de la performance de ce système a donc été déplacer les classes assurant la répartition des requêtes dans une librairie séparée, permettant de découpler l’interface Web du répartiteur. Le répartiteur en lui-même est un projet de taille modeste, représentant environ 400 lignes de code Java, et 964 lignes de code Groovy pour l’interface Web. Les politiques de répartitions implémentées sur le répartiteur représentent quant à elles environ 2000 lignes de code. Cet aspect quantitatif ne permet pas de mesurer avec certitude l’effort total réalisé car l’ensemble de cette base de code a subi de multiples changements au cours du temps, principalement concernant l’optimisation ou la correction de bogues détectés lors des simulations. Parmi les optimisations réalisées, le passage en pur Java a été le plus efficace en terme de gains de performance brute. De même, le passage d’un modèle de traitement des requêtes événementiel plutôt que par fil d’exécution a permis un fort gain dans la capacité de traitement du répartiteur. Le générateur de service Web représente environ 1800 lignes de code Java entre l’implémentation du serveur, l’intégration avec Cloudizer et un module d’intégration avec le 383.5. DISCUSSION système Hadoop permettant d’utiliser ce système pour répartir les traitements. Ces développements spécifiques et de petite taille n’ont pas fait l’objet d’une méthode de développement particulière. Un soin particulier a été apporté à là modularité de ces projets, en permettant une extension facile de leurs fonctionnalités respectives : ajouts de nouvelles politiques de distribution pour le répartiteur ou de nouveaux environnements d’exécution pour le générateur de services. 3.5 Discussion L’architecture de Cloudizer permet donc de déployer et d’exécuter un grand nombre d’applications différentes en déléguant la gestion des données à d’autres systèmes. Les services pouvant tirer partie de Cloudizer vont de l’application Web standard ou la Web Archive. À cela s’ajoute la possibilité d’utiliser un binaire comme service web ce qui peut être particulièrement utile dans le cadre d’applications héritées. Cette capacité a été développée pour permettre une intégration simple de ce projet dans la plateforme MCube afin d’assurer la répartition des requêtes de services de traitement de données. Ce service est suffisamment générique pour assurer à la fois la distribution des services de traitements de données de la plateforme MCube mais aussi de la partie Web fournissant l’interface utilisateur et la communication avec les passerelles. Le fait de pouvoir sélectionner la stratégie de répartition la plus appropriée pour un service donné dans la plateforme Cloudizer permet d’évaluer et de comparer la performance des différentes stratégies. Cependant le comportement des stratégies mises au point ainsi que leur tests en environnement réels sont longs et fastidieux. Les nouveaux environnements de déploiements tels que les plateformes de Cloud Computing permettent d’utiliser de grands nombres de machines, il est donc nécessaire d’utiliser des outils de simulations appropriés afin de faciliter le développement de ces stratégies. 393.5. DISCUSSION 40Chapitre 4 Simizer : un simulateur d’application en environnement cloud 4.1 Introduction La conception du simulateur Simizer a commencé comme un simple programme de test pour les stratégies de répartition de charge en amont de leur déploiement dans le projet Cloudizer. Ses fonctionnalités ont été étendues par la suite, dans le but de fournir des résultats de plus en plus réalistes et de permettre la réalisation de simulations plus diverses, comme des simulations de protocoles de synchronisation de processus dans les systèmes distribués. Le développement des grilles de calcul, et plus récemment du cloud computing, a donné naissance à de nombreux simulateurs de plateformes de traitement à large échelle. Les simulateurs de grilles, conçus pour simuler de grands nombres de machines partagées par plusieurs utilisateurs, ont été naturellement adaptés pour prendre en compte la virtualisation et simuler les plateformes de calcul à la demande : les "clouds". Par exemple le Grid Sim toolkit [MB02] a servi de base au développement du simulateur CloudSim [RNCB11], et l’utilitaire SimGrid [CLQ08] intègre aujourd’hui de nombreuses options permettant de simuler le fonctionnement des centres de virtualisation. Simizer a donc été conçu de manière à combler un vide dans les solutions de simulation existantes se rapportant au Cloud Computing. 414.1. INTRODUCTION 4.1.1 Simulateurs de Cloud existants Les principaux représentants des simulateurs de clouds sont les projets SimGrid[CLQ08] et CloudSim[RNCB11]. Ces projets permettent de simuler entièrement une infrastructure de type cloud en écrivant un programme utilisant les objets mis à disposition par l’interface de programmation fournie par la librairie. Ces deux utilitaires sont principalement destinés à la recherche en matière de conception et d’évaluation de l’architecture sous-jacente des plateformes de services informatiques à la demande. I ls permettent d’obtenir un modèle du comportement du centre de données dans son ensemble. Par exemple, des travaux menés avec CloudSim par Beloglazov et Buyya [BB12] ont permis d’analyser l’influence de diffé- rentes stratégies d’allocation de ressources sur la qualité de service rendue aux utilisateurs et la consommation électrique d’un centre de données. L’utilitaire SimGrid [BLM+12] a été conçu pour simuler de manière transparente le comportement d’applications de calculs distribués massifs, avant leur déploiement effectif sur une grille. Cependant, l’application de ce logiciel au domaine du Cloud Computing se limite à la simulation du fonctionnement interne des infrastructures. Le simulateur GreenCloud [KBAK10] est destiné à modéliser la consommation électrique des centres de données. Il se fonde sur le simulateur de protocoles réseaux NS-2[MFF], ce qui rend son modèle de simulation de réseau extrêmement fiable. Le projet iCanCloud[NVPC+12] utilise un modèle mathématique pour simuler les coûts engendrés par l’utilisation d’une plateforme de Cloud Computing comme le service EC2 d’Amazon 1. Cependant, ces simulateurs sont destinés aux fournisseurs de services Cloud, et permettent de modéliser facilement des prototypes de plateformes ou les coûts engendrés par les infrastructures en fonction d’un modèle d’utilisation du service. Il n’existe pas à ce jour de simulateurs d’infrastructure cloud permettant de simuler le comportement d’une application déployée dans ce type d’environnement [SL13]. Bien que des efforts aient été récemment faits dans cette direction, comme le simulateur CDOSim[FFH12] ce logiciel n’est pas publiquement disponible. Il n’existe donc pas à ce jour de simulateur permettant d’établir finement l’influence de protocoles de niveau applicatif utilisés par un système. Ce besoin existe car il a été montré à plusieurs reprises que les plateformes d’infrastructures à 1. http://aws.amazon.com, consulté le 5 octobre 2013 424.2. ARCHITECTURE DE SIMIZER la demande souffrent par leur nature partagée, d’une dépendance entre le niveau d’utilisation global de la plateforme et la performance des applications. Pouvoir évaluer à l’avance le comportement d’une application dans ce type de contexte d’exécution présente donc un avantage certain. La conception de Simizer vise donc à remplir ce besoin en permettant l’évaluation de la performance théorique d’applications de type services web déployées sur des plateformes de cloud computing. L’architecture du simulateur Simizer et le fonctionnement de ses différents composants sont décrits en section 4.2, puis l’utilisation pratique du simulateur est détaillée en section 4.3. La section 4.4 fournit à travers deux expérimentations une validation du fonctionnement du simulateur par rapport à la librairie CloudSim, et la section 4.5 discutera des futurs développements de l’utilitaire. 4.2 Architecture de Simizer Simizer est un simulateur à événements discrets écrit en JAVA. Il est fondé sur une architecture à trois couches : une couche de bas niveau fournissant les classes de gestion des événements, une couche Architecture utilisant les classes de gestion d’événements pour simuler le comportement des machines virtuelles et des réseaux, et une couche de niveau Application, qui permet d’implémenter les protocoles à tester dans le simulateur. Couche Evénements - Traitement des événements Couche Architecture - Simulation réseau - Simulation du matériel (machines virtuelles) Couche Application - Haut niveau de simulation - Simulation des protocoles applicatifs Figure 4.1 – Architecture de Simizer 434.2. ARCHITECTURE DE SIMIZER Table 4.1 – Lois de probabilité disponibles dans Simizer loi paramètres Exponentielle espérance (!) Gaussienne moyenne (µ) Poisson espérance (!) Uniforme densité Zipf biais (s) 4.2.1 Couche Evénements La couche de traitement des événements est la couche de plus bas niveau du simulateur. Elle fournit une boucle de traitement d’événements permettant de garantir l’ordre d’exécution des événements et d’optimiser le traitement de ces objets. Elle fournit aussi un ensemble de classes utilitaires permettant la génération de nombre aléatoires selon différentes lois de distribution. Génération de nombres aléatoires La génération des événements produisant l’exécution de la simulation est régie par les lois de distribution aléatoires décrites dans le tableau 4.1. Le générateur de nombre aléatoire utilisé est celui de la Java Virtual Machine. Grâce à cette classe il est possible de générer trois types de valeurs aléatoires : – des entiers distribués uniformément sur les valeurs comprises entre 0 et un nombre donné en paramètre, – des flottants double précision : distribués uniformément sur les valeurs comprises entre 0 et un nombre donné en paramètre, – des flottants double précision distribués selon une loi Gaussienne d’espérance 0 et d’écart type 1. Les distributions utilisées sont donc générées à partir de ces trois types de valeurs. Deux contraintes principales sont posées : les valeurs obtenues pour la simulation doivent être entières, et l’intervalle des valeurs possibles est limité entre 0 et un paramètre spécifié. Les lois Gaussiennes, Uniformes et Zipfiennes sont utilisées principalement pour décrire les distributions de requêtes utilisateurs. La distribution Zipfienne décrit correctement divers phénomènes utilisés dans les simulations informatique [BCC+99, Fei02] tels que la distribution des tailles des fichiers d’un système, ou la distribution des pages les plus fréquemment 444.2. ARCHITECTURE DE SIMIZER accédées sur un site Web. Il est donc intéressant d’étudier le comportement de différentes stratégies de répartition par rapport à des requêtes distribuées selon cette loi. Plus récemment il a été observé que les effets dus à la mise en cache des données les plus fréquemment accédées, en particulier dans les systèmes web, avait des conséquence visibles sur la distribution des requêtes observées, ces dernières ne suivant plus strictement une loi de Zipf [DCGV02, GTC+07]. Il est donc nécessaire de pouvoir tester le comportement des politiques de répartition par rapport à d’autres distributions possibles comme loi Gaussienne ou Uniforme. Les lois de Poisson et Exponentielles sont utilisées pour décrire le comportement des utilisateurs. La loi de Poisson est utilisée pour générer les arrivées de nouveaux clients du système simulé et la loi Exponentielle est utilisée pour déterminer la durée d’utilisation du système par chaque utilisateur, ainsi que l’intervalle de temps séparant les réponses et les requêtes d’un utilisateur [Fei02]. Traitement des événements Le diagramme 4.2 montre les classes composant l’architecture du moteur d’événements utilisé par Simizer. Une simulation est constituée de plusieurs entités appelées "Producteurs d’événements" (EventProducer) qui produisent chacun un ensemble d’événements particuliers (classe ConcreteEvent). Un événement est caractérisé par une donnée, une cible et un horodatage, qui indiquent respectivement à quel instant et à quel objet de la simulation cet événement doit être signalé. Les producteurs d’évé- nements servent à implanter les divers modèles de systèmes nécessaires à la simulation. Chaque Producteur crée des événements et les planifie en choisissant l’horodatage selon les règles du système simulé. C’est la production de nouveaux événements par les Producteurs d’événements qui fait avancer la simulation. Les événements ainsi produits sont stockés dans une file d’attente ordonnée : le Canal (Channel). À intervalles réguliers au cours de la simulation, le Répartiteur d’événements (EventDispatcher) interroge le Canal pour savoir si il y a des événements en attente. Le cas échéant, le Répartiteur retire de la file l’événement ayant la datation la moins avancée, et le signale à la cible correspondante. Les événements sont signalés l’un après l’autre dans l’ordre croissant des horodatages. Ce choix permet d’éviter les conflits dits de causalité qui peuvent se produire lorsqu’un événement 454.2. ARCHITECTURE DE SIMIZER qui n’est pas encore "arrivé" est exécuté avant ou en même temps qu’un événement qui le précède, ce qui peut provoquer un résultat incohérent voire un blocage de la simulation. Les événements sont spécialisés en fonction du type d’action à réaliser. Ces actions sont Figure 4.2 – Entités de gestion des événements implantées dans la couche supérieure du simulateur : la couche d’architecture. 4.2.2 Couche architecture La couche d’architecture de Simizer représente les différentes entités faisant l’objet de la simulation. En l’occurrence, Simizer est conçu pour simuler des systèmes informatiques distribués. Les entités simulées représentées dans le diagramme de classes 4.3 peuvent être définies ainsi : Le Réseau (Network) permet de simuler les délais et erreurs inhérentes au fonctionnement des réseaux modernes comme internet ou les réseaux locaux. Les Nœuds (Nodes) correspondent aux machines composant le système simulé. Ils communiquent via les Réseaux (Network). Il existe trois catégories de Nœuds : les Clients (ClientNode) repré- sentent les machines clientes de services disponibles sur les Serveurs (ServerNode). Lorsque les serveurs et les clients sont sur des réseaux différents, un Répartiteur (LBNode) sert d’intermédiaire entre les clients et les serveurs. Le comportement des clients est géré par la classe ClientManager, qui ordonne la création de nouveaux clients selon une loi de pro- 46 Vers une capitalisation des connaissances orient´ee utilisateur : extraction et structuration automatiques de l’information issue de sources ouvertes Laurie Serrano To cite this version: Laurie Serrano. Vers une capitalisation des connaissances orient´ee utilisateur : extraction et structuration automatiques de l’information issue de sources ouvertes . Computer Science. Universt´e de Caen, 2014. French. HAL Id: tel-01082975 https://hal.archives-ouvertes.fr/tel-01082975 Submitted on 14 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Universit´e de Caen Basse-Normandie Ecole doctorale SIMEM ´ Th`ese de doctorat pr´esent´ee et soutenue le : 24/01/2014 par Laurie Serrano pour obtenir le Doctorat de l’Universit´e de Caen Basse-Normandie Sp´ecialit´e : Informatique et applications Vers une capitalisation des connaissances orient´ee utilisateur Extraction et structuration automatiques de l’information issue de sources ouvertes Directrice de th`ese : Maroua Bouzid Jury Laurence Cholvy Directrice de recherche DTIM, ONERA (Rapporteur) Thierry Poibeau Directeur de recherche LaTTiCe, ENS (Rapporteur) Fatiha Sa¨ıs Maˆıtre de conf´erences LRI, Univ. Paris 11 (Examinatrice) Ga¨el Dias Professeur des universit´es GREYC, Univ. de Caen (Examinateur) Stephan Brunessaux Senior expert Cassidian, EADS (Co-directeur de th`ese) Thierry Charnois Professeur des universit´es LIPN, Univ. Paris 13 (Co-encadrant de th`ese) Maroua Bouzid Professeur des universit´es GREYC, Univ. de Caen (Directrice de th`ese)Mis en page avec la classe thloria.Résumé Face à l’augmentation vertigineuse des informations disponibles librement (notamment sur le Web), repérer efficacement celles qui présentent un intérêt s’avère une tâche longue et complexe. Les analystes du renseignement d’origine sources ouvertes sont particulièrement concernés par ce phénomène. En effet, ceux-ci recueillent manuellement une grande partie des informations d’intérêt afin de créer des fiches de connaissance résumant le savoir acquis à propos d’une entité. Dans ce contexte, cette thèse a pour objectif de faciliter et réduire le travail des acteurs du renseignement et de la veille. Nos recherches s’articulent autour de trois axes : la modélisation de l’information, l’extraction d’information et la capitalisation des connaissances. Nous avons réalisé un état de l’art de ces différentes problématiques afin d’élaborer un système global de capitalisation des connaissances. Notre première contribution est une ontologie dédiée à la représentation des connaissances spécifiques au renseignement et pour laquelle nous avons défini et modélisé la notion d’événement dans ce domaine. Par ailleurs, nous avons élaboré et évalué un système d’extraction d’événements fondé sur deux approches actuelles en extraction d’information : une première méthode symbolique et une seconde basée sur la découverte de motifs séquentiels fréquents. Enfin, nous avons proposé un processus d’agrégation sémantique des événements afin d’améliorer la qualité des fiches d’événements obtenues et d’assurer le passage du texte à la connaissance. Celui-ci est fondé sur une similarité multidimensionnelle entre événements, exprimée par une échelle qualitative définie selon les besoins des utilisateurs. Mots-clés: Gestion des connaissances, exploration de données, représentation des connaissances, renseignement d’origine sources ouvertes, ontologies (informatique), Web sémantique. Abstract Due to the considerable increase of freely available data (especially on the Web), the discovery of relevant information from textual content is a critical challenge. Open Source Intelligence (OSINT) specialists are particularly concerned by this phenomenon as they try to mine large amounts of heterogeneous information to acquire actionable intelligence. This collection process is still largely done by hand in order to build knowledge sheets summarizing all the knowledge acquired about a specific entity. Given this context, the main goal of this thesis work is to reduce and facilitate the daily work of intelligence analysts. For this sake, our researches revolve around three main axis : knowledge modeling, text mining and knowledge gathering. We explored the literature related to these different domains to develop a global knowledge gathering system. Our first contribution is the building of a domain ontology dedicated to knowledge representation for OSINT purposes and that comprises a specific definition and modeling of the event concept for this domain. Secondly, we have developed and evaluated an event recognition system which is based on two different extraction approaches : the first one is based on hand-crafted rules and the second one on a frequent pattern learning technique. As our third contribution, we proposed a semantic aggregation process as a necessary post-processing step to enhance the quality of the events extracted and to convert extraction results into actionable knowledge. This is achieved by means of multiple similarity measures between events, expressed according a qualitative scale which has been designed following our final users’ needs. Keywords: Knowledge management, data mining, knowledge representation (information theory), open source intelligence, ontologies (information retrieval), Semantic Web.Remerciements Cette thèse ayant été réalisée dans le cadre d’une convention industrielle, je tiens tout d’abord à remercier les personnes de mon entreprise et de mon laboratoire qui en sont à l’origine : notamment Stephan Brunessaux et Bruno Grilheres pour m’avoir recrutée et encadrée en stage puis proposé cette collaboration, mais aussi mes encadrants académiques, Maroua Bouzid et Thierry Charnois. Je vous suis à tous extrêmement reconnaissante pour le temps que vous m’avez consacré du début à la fin de cette thèse ainsi que pour toutes nos discussions enrichissantes qui ont permis à mes travaux d’avancer. Je tiens par ailleurs à remercier l’ensemble des membres du jury : Laurence Cholvy et Thierry Poibeau pour avoir accepté de rapporter mon travail ainsi que Fatiha Saïs et Gaël Dias pour leur participation au jury de soutenance. Mes remerciements les plus sincères vont également aux deux équipes au sein desquelles j’ai été intégrée pendant ces trois ans. Je remercie tous les membres de l’équipe MAD pour leur accueil et leurs conseils notamment lors des groupes de travail. Mais aussi et bien sûr tous les membres de l’équipe IPCC : vous m’avez accueillie les bras ouverts et je garderai une place pour vous tous dans ma petite tête, je ne pouvais pas rêver mieux comme équipe pour une première expérience professionnelle. Je te remercie encore Stephan de m’avoir recrutée, Bruno pour ton encadrement justement dosé qui m’a guidé tout en favorisant mon autonomie, Khaled mon cher collègue de bureau pour tes conseils mais aussi pour nos rires même dans les moments de rush. Yann, Arnaud, Emilien, Amandine pour votre aide précieuse quand je venais vous embêter avec mes questions et tous les autres bien sûr qui m’ont spontanément apporté leur aide et soutien. Fred (je ne t’oublie pas non non), notre "chef de centre" farceur et toujours là pour entretenir cette bonne humeur qui caractérise notre équipe, je te remercie pour toutes nos rigolades. Toi aussi, Dafni, ma grecque préférée, je te dois énormément, professionnellement et personnellement, tu as su me comprendre et me conseiller à tout moment et je ne l’oublierai pas. Véro, ma tata, mon amie, tu as été là pour moi depuis le tout premier jour quand tu es venue me chercher à la gare et que nous avons tout de suite sympathisé. Je te remercie pour tout ce que tu as fait pour moi et tout ce que tu continues d’apporter à cette équipe avec ton grand cœur. Je pense aussi à mes amis qui ont été présents pendant cette aventure, tout proche ou à distance, ponctuellement ou en continu, dans les moments difficiles ou pour le plaisir, mais tous toujours là. Milie, Manon, Laure, Lucile, Rosario, Chacha, Marlou, je vous remercie mes chers Talistes/Taliens pour votre soutien, votre écoute, votre folie, nos retrouvailles, nos fiestas et bien d’autres moments passés avec vous. Un gros merci également à mes amis et colocs rouennais, Romain, Etienne, mon Aldricou, Nico, Juline, Manuella, Camille et bien d’autres, vous avez su me changer les idées durant nos traditionnelles soirées à l’Oka, à la coloc, nos escapades au ski, à Brighton et ailleurs. Je suis fière de vous avoir rencontrés et je ne vous oublierai pas. Une pensée pour toi aussi ma Lady, toi qui m’a soutenue dans l’un des moments les plus difficiles de cette thèse. Je vous remercie Julien, Xavier, Mariya et Laura, mes chers amis de Caen, avec vous j’ai pu partager mes petits soucis de thésarde et passer de très agréables soirées caennaises. Last but not least, vous mes Trouyiens adorés, mes amis de toujours, éparpillés en France et ailleurs, Bolou, Maelion, Solenou, Loicou, Tildou, Emilie et Quitterie, sans même vous en rendre compte, vous m’avez aidée pendant cette thèse oui oui, car cette thèse n’est qu’une petite partie d’une aventure bien plus enrichissante... Enfin, je veux remercier mes parents, los de qui cau, qui, drets sus la tèrra, m’ont transmis des valeurs chères à mes yeux et m’ont poussée à aller au bout de ce que j’entreprends et de ce que j’aime. iii Copyright c 2013 - CASSIDIAN - All rights reservediv Copyright c 2013 - CASSIDIAN - All rights reservedTable des matières Résumé i Abstract i Remerciements iii Table des figures x Liste des tableaux xi Introduction 1 1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Renseignement d’Origine Sources Ouvertes . . . . . . . . . . . . . . . . . . 3 1.2 Media Mining & la plateforme WebLab . . . . . . . . . . . . . . . . . . . . 5 2 Objectifs et axes de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Contributions de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 I État de l’art 13 1 Représentation des connaissances 17 1.1 Données, informations et connaissances . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2 L’information sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.1 Le Web sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.2 Les ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.3 Les langages de représentation . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.2.4 Inférence et bases de connaissances . . . . . . . . . . . . . . . . . . . . . . 23 1.2.5 Les éditeurs d’ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3 Modélisation des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.3.1 Qu’est-ce qu’un événement ? . . . . . . . . . . . . . . . . . . . . . . . . . 26 v Copyright c 2013 - CASSIDIAN - All rights reservedTable des matières 1.3.1.1 Les événements en extraction d’information . . . . . . . . . . . . . . 27 1.3.1.2 Les ontologies orientées "événement" . . . . . . . . . . . . . . . . . . 28 1.3.2 Modélisation du temps et de l’espace . . . . . . . . . . . . . . . . . . . . . 33 1.3.2.1 Représentation du temps . . . . . . . . . . . . . . . . . . . . . . . . . 33 1.3.2.2 Représentation de l’espace . . . . . . . . . . . . . . . . . . . . . . . . 34 1.3.3 Spécifications dédiées au ROSO . . . . . . . . . . . . . . . . . . . . . . . . 35 1.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2 Extraction automatique d’information 39 2.1 Définition et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.2 Approches d’extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.2.1 Extraction d’entités nommées et résolution de coréférence . . . . . . . . . . 43 2.2.2 Extraction de relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.2.3 Extraction d’événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3 Plateformes et logiciels pour l’EI . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.4 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.5 Évaluation des systèmes d’EI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.5.1 Campagnes et projets d’évaluation . . . . . . . . . . . . . . . . . . . . . . . 54 2.5.2 Performances, atouts et faiblesses des méthodes existantes . . . . . . . . . . 56 2.6 Problèmes ouverts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3 Capitalisation des connaissances 61 3.1 Fusion de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.1.1 Réconciliation de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.1.2 Web de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.1.3 Similarité entre données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.2 Capitalisation appliquée aux événements . . . . . . . . . . . . . . . . . . . . . . . 66 3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 II Contributions de la thèse 69 4 Modélisation des connaissances du domaine 73 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.2 Notre modèle d’événement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.2.1 La dimension conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.2 La dimension temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 vi Copyright c 2013 - CASSIDIAN - All rights reserved4.2.3 La dimension spatiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.2.4 La dimension agentive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.3 WOOKIE : une ontologie dédiée au ROSO . . . . . . . . . . . . . . . . . . . . . . 78 4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5 Extraction automatique des événements 83 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2 La plateforme GATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3 Extraction d’entités nommées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.1 Composition de la chaine d’extraction . . . . . . . . . . . . . . . . . . . . . 87 5.3.2 Développement du module de règles linguistiques . . . . . . . . . . . . . . 88 5.4 Extraction d’événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.4.1 Approche symbolique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.4.2 Apprentissage de patrons linguistiques . . . . . . . . . . . . . . . . . . . . 97 5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6 Agrégation sémantique des événements 101 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.2 Normalisation des entités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.3 Similarité sémantique entre événements . . . . . . . . . . . . . . . . . . . . . . . . 105 6.3.1 Similarité conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.3.2 Similarité temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.3.3 Similarité spatiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.3.4 Similarité agentive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.4 Processus d’agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7 Expérimentations et résultats 115 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2 Évaluation du système d’extraction . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2.1 Protocole d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2.2 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.2.3 Bilan de l’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.3 Premières expérimentions sur l’agrégation sémantique . . . . . . . . . . . . . . . . 122 7.3.1 Implémentation d’un prototype . . . . . . . . . . . . . . . . . . . . . . . . 122 7.3.2 Jeu de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.3.3 Exemples d’observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.3.4 Bilan de l’expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 vii Copyright c 2013 - CASSIDIAN - All rights reservedTable des matières 7.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Conclusion et perspectives 131 1 Synthèse des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 1.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 1.2 Un modèle de connaissances pour le ROSO . . . . . . . . . . . . . . . . . . 133 1.3 Une approche mixte pour l’extraction automatique des événements . . . . . 134 1.4 Un processus d’agrégation sémantique des événements . . . . . . . . . . . . 134 1.5 Évaluation du travail de recherche . . . . . . . . . . . . . . . . . . . . . . . 135 2 Perspectives de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Annexes 139 A WOOKIE : taxonomie des concepts 141 B WOOKIE : événements spécifiques au ROSO 143 C WOOKIE : relations entre concepts 145 D WOOKIE : attributs des concepts 147 E GATE : exemple de chaine de traitement 149 F Gazetteer pour la détection de personnes en français 151 G L’ontologie-type pizza.owl 153 H Extrait de l’ontologie pizza.owl au format OWL 155 I Exemple de document WebLab contenant des événements 159 J Exemple de règle d’inférence au formalisme Jena 163 K Extrait d’un document du corpus d’apprentissage 165 L Extrait d’un document du corpus de test 167 M Source s12 : dépêche de presse à l’origine des événements Event1 et Event2 169 N Source s3 : dépêche de presse à l’origine de l’événement Event3 171 Bibliographie 173 viii Copyright c 2013 - CASSIDIAN - All rights reservedTable des figures 1 Architecture de la plateforme WebLab . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Système de capitalisation des connaissances proposé . . . . . . . . . . . . . . . . . . . 9 1.1 Linking Open Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2 L’environnement Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.3 L’ontologie Event : modélisation des événements . . . . . . . . . . . . . . . . . . . . . 29 1.4 LODE : modélisation des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1.5 LODE : alignements entre propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1.6 SEM : modélisation des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.7 DUL : modélisation des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.8 CIDOC CRM : taxonomie des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.9 CIDOC CRM : modélisation des événements . . . . . . . . . . . . . . . . . . . . . . . 33 1.10 Algèbre temporel d’Allen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1.11 Les relations topologiques RCC-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1 Le pentagramme du renseignement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.1 Exemple de règle d’extraction exprimée dans le formalisme JAPE . . . . . . . . . . . . 85 5.2 Règle d’extraction de dates en français . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.3 Règle d’extraction de dates en anglais . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.4 Extrait du gazetteer org_key.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5 Règle d’extraction d’organisations en anglais . . . . . . . . . . . . . . . . . . . . . . . 91 5.6 Extrait du gazetteer person_pre.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.7 Règle d’extraction de personnes en français . . . . . . . . . . . . . . . . . . . . . . . . 92 5.8 Extrait du gazetteer loc_key.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.9 Règle d’extraction de lieux en français . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.10 Gazetteer bombings.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.11 Exemple d’analyse syntaxique en dépendance . . . . . . . . . . . . . . . . . . . . . . . 96 5.12 Extraction des événements : différentes étapes . . . . . . . . . . . . . . . . . . . . . . 96 5.13 Extraction des événements : chaine de traitement GATE pour l’anglais . . . . . . . . . . 97 5.14 Extraction des événements : exemple d’annotation GATE . . . . . . . . . . . . . . . . 97 5.15 Visualisation et sélection des motifs avec l’outil Camelis . . . . . . . . . . . . . . . . . 100 6.1 Désambiguïsation des entités spatiales : exemple de triplets RDF/XML produits . . . . . 104 7.1 Exemples de motifs séquentiels fréquents sélectionnés . . . . . . . . . . . . . . . . . . 118 7.2 Nombre de motifs retournés en fonction des paramètres choisis . . . . . . . . . . . . . . 119 7.3 Un exemple d’événement issu de la base GTD . . . . . . . . . . . . . . . . . . . . . . . 125 ix Copyright c 2013 - CASSIDIAN - All rights reservedTABLE DES FIGURES 7.4 Similarités entre événements : extrait représenté en RDF/XML . . . . . . . . . . . . . . 126 7.5 Visualisation des 3 événements extraits sur une carte géographique . . . . . . . . . . . 128 x Copyright c 2013 - CASSIDIAN - All rights reservedListe des tableaux 5.1 Classes argumentales pour l’attribution des rôles sémantiques . . . . . . . . . . . . . . 96 6.1 Normalisation des dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.1 Chaines d’extraction d’événements : variantes évaluées . . . . . . . . . . . . . . . . . . 119 7.2 Extraction d’événements : précision, rappel et F-mesure . . . . . . . . . . . . . . . . . . 120 7.3 Extraction d’événements : apport de l’analyse syntaxique . . . . . . . . . . . . . . . . . 121 7.4 Extraction d’événements : influence de la REN . . . . . . . . . . . . . . . . . . . . . . 121 7.5 Alignement des types d’événement entre le modèle GTD et l’ontologie WOOKIE . . . . 124 7.6 Événements extraits et leurs dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.7 Exemple de 3 événements agrégés automatiquement . . . . . . . . . . . . . . . . . . . 127 7.8 Fiches d’événements de référence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 xi Copyright c 2013 - CASSIDIAN - All rights reservedLISTE DES TABLEAUX xii Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction Sommaire 1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Renseignement d’Origine Sources Ouvertes . . . . . . . . . . . . . . . . 3 1.2 Media Mining & la plateforme WebLab . . . . . . . . . . . . . . . . . . . 5 2 Objectifs et axes de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Contributions de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction Le savoir occupe aujourd’hui et depuis toujours une place centrale dans notre société, il est au cœur de toute activité humaine. Épanouissement intellectuel pour certains et capital pour d’autres, la connaissance est considérée comme une richesse pouvant servir un large panel d’objectifs. Que ce soit à des fins personnelles ou professionnelles, la principale visée de l’acquisition du savoir quel qu’il soit est, sans aucun doute, de mieux appréhender et de comprendre notre environnement. Dans des situations variées et en constante mutation, la capacité à observer et à analyser ce qui nous entoure (objets, personnes, situations, relations, faits, etc.) est un préalable fondamental à tout processus de prise de décision. L’essor d’Internet et des nouvelles technologies de l’information a récemment déstabilisé les principaux mécanismes traditionnels de gestion de la connaissance. Passé d’un ensemble restreint et structuré de silos à la Toile, le savoir est de plus en plus accessible à tous et partout. Ce changement provient principalement de la démocratisation des moyens de communication et de publication de l’information. Deux problématiques principales émergent alors : – Comment faire face à cette nouvelle masse disponible qui constitue une mine d’or mais peut également s’avérer néfaste à notre acquisition de connaissance ? – Quels moyens mettre en place pour extraire un savoir homogène à partir de contenus de plus en plus diversifiés sur le fond et sur la forme ? Celles-ci occupent une place centrale dans divers domaines pour lesquels l’acquisition du savoir est stratégique : le Renseignement d’Origine Sources Ouvertes (ROSO) est l’un de ces domaines. 2 Copyright c 2013 - CASSIDIAN - All rights reserved1. Contexte 1 Contexte En guise d’introduction de nos travaux, nous proposons tout d’abord un rapide tour d’horizon du contexte de cette étude, réalisée dans un cadre à la fois académique et applicatif. Nous parlerons, dans un premier temps, du Renseignement d’Origine Sources Ouvertes constituant le fil directeur de nos recherches en termes de besoins opérationnels. Puis, nous introduirons un champ de recherche visant à répondre à ces besoins et dans lequel se situe plus précisément notre sujet de recherche, à savoir la fouille de documents multimédia, plus communément désignée par le terme de Media Mining. 1.1 Renseignement d’Origine Sources Ouvertes Le Renseignement d’Origine Sources Ouvertes (dit ROSO) désigne toute activité de recueil et d’analyse de l’information disponible publiquement et légalement (presse écrite, blogs, sites internet, radio, télévision, etc.) [Best and Cumming, 2007]. Initialement définie dans le domaine de la défense, cette activité est aujourd’hui menée plus largement à des fins stratégiques et économiques sous le nom de veille à partir de sources ouvertes. En effet, les Sources Ouvertes (SO) sont très prolifiques et peuvent, par exemple, fournir les données nécessaires pour analyser la situation d’un pays : caractéristiques géopolitiques et sociales, diffé- rents acteurs économiques, politiques, militaires, terroristes ou criminels, etc. Lors d’une crise, l’analyse systématique des médias nationaux et internationaux peut permettre, par exemple, de produire automatiquement une synthèse qui facilitera les prises de décision. Des processus de veille peuvent également être mis en œuvre pour effectuer une recherche pro-active d’informations liées à l’environnement, aux opportunités ou aux menaces qui constituent des signaux faibles et qui doivent faire l’objet d’une écoute anticipative. Les objectifs premiers du ROSO sont les suivants : – Savoir : s’informer sur les intentions d’un acteur intérieur ou extérieur, comprendre cet acteur et la situation ; – Prévoir : anticiper les évolutions, prévenir les menaces, influencer les situations. Le cycle du renseignement a été défini pour répondre à ces deux objectifs et est constitué de 5 étapes : 1. Orientation : il s’agit de définir le besoin en renseignement et spécifier les indicateurs permettant de valider la réussite de l’action de renseignement, 2. Planification : elle consiste à trouver les sources et les gisements d’information d’intérêt et à définir le besoin de veille, 3. Recherche : elle vise à réaliser l’acquisition et le pré-traitement des données à partir des gisements précédemment définis, 4. Exploitation : il s’agit d’analyser le contenu des données, de les filtrer pour en faire émerger de la connaissance, 5. Diffusion : elle consiste à faire la synthèse et à remonter l’information utile vers le décideur. Le ROSO est aujourd’hui devenu un processus complexe à mettre en œuvre. En effet, avec la croissance du Web 2.0 et la multiplication des gisements d’information, les spécialistes du renseignement 3 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction et les veilleurs se trouvent confrontés, d’une part, à une masse de données toujours plus importante et, d’autre part, à une diversité croissante des formats et structures. Face à ce nouveau phénomène, des systèmes d’information plus performants sont désormais nécessaires pour accéder et traiter cette masse d’information. Ces systèmes sont notamment indispensables pour dépasser les limites des moteurs de recherche "grand public" et proposer une collecte ciblée et précise de l’information à la fois dans le Web public, mais aussi dans le Web profond. Ils doivent également être capables de détecter les informations pouvant constituer des signes précoces de changement ou de menace. Dès lors, le développement et l’utilisation de tels outils deviennent des tâches de plus en plus complexes. L’essor des nouveaux moyens de communication favorise l’émergence des sources d’information mettant à disposition des informations aux caractéristiques particulières. La prise en compte de celles-ci est primordiale pour obtenir un système adapté à la fois aux besoins des analystes du renseignement mais également aux informations que ceux-ci sont amenés à traiter. Ainsi, les principales problématiques rencontrées lors du traitement des informations issues de sources ouvertes sont les suivantes : – L’hétérogénéité des formats et structures : les informations disponibles sont proposées dans des formats variés (pages HTML, flux RSS, réseaux sociaux, wiki, blogs, forums, etc.) et ne sont pas toujours structurées. Le traitement de ces ressources implique l’utilisation d’un ensemble varié d’outils dont l’interopérabilité n’est pas assurée. Pour atteindre ses objectifs, le veilleur doit se former à leur utilisation combinée, ce qui augmente encore la complexité de son travail. – Le multilinguisme : avec la démocratisation de l’accès à Internet, le nombre de langues employées sur la Toile a fortement augmenté ces dernières années, ce qui pose des problèmes d’intercompréhension. Les outils de traduction automatique deviennent donc clés afin de donner un accès à ces contenus dans des langues non maitrisées par l’analyste. – La quantité d’information à traiter : la quantité et le volume des informations mises à disposition aujourd’hui en sources ouvertes, notamment avec la croissance des contenus audio et vidéo en ligne, sont tels qu’il devient impossible de collecter manuellement toutes ces informations. En effet, la collecte de ces grands volumes nécessite des connexions réseaux rapides, du temps, ainsi qu’un espace de stockage important, dont on ne dispose généralement pas. De plus, face à cette quantité d’informations disponibles, le veilleur se trouve submergé et il devient impossible pour lui de traiter efficacement ces nouvelles données, et de discerner clairement les informations pertinentes pour sa tâche. – La qualité et l’interprétation des informations : les informations disponibles en sources ouvertes peuvent être peu fiables, contradictoires, dispersées, et il s’avère souvent difficile, voire impossible de savoir quel crédit leur accorder au premier abord. Il convient alors de recouper et d’analyser ces informations pour leur donner un sens et une valeur, ce qui reste une étape manuelle et donc coû- teuse, à la fois en termes de temps et de moyens. Comment rassembler et sélectionner efficacement dans la masse d’informations, les plus pertinentes, qui seront ensuite interprétées et auxquelles on tachera de donner un sens et évaluer une crédibilité ? Aujourd’hui, les plateformes de veille tentent de répondre à ces premières problématiques, mais du fait de l’évolution rapide des technologies, des formats et des structures d’information, ces systèmes ne sont pas toujours cohérents et évolutifs. S’il existe de nombreux outils publics et accessibles sur Internet (moteurs de recherche généralistes ou verticaux), une veille qui repose uniquement sur ceux-ci se trouve rapidement limitée. Pour répondre à des besoins d’information précis et garder une réactivité importante face à de nouveaux types d’information, la sélection des techniques les plus pertinentes reste indispensable. De plus, la prise en main de ces outils s’avère coûteuse en temps pour les analystes, 4 Copyright c 2013 - CASSIDIAN - All rights reserved1. Contexte c’est pourquoi l’efficacité d’un travail de veille va dépendre de l’intégration de ces divers outils au sein d’une seule et même plateforme, mais aussi et surtout des performances de chacun des composants de traitement de l’information. 1.2 Media Mining & la plateforme WebLab La coordination d’un ensemble de techniques de traitement de l’information pour les besoins que nous venons d’évoquer est notamment l’objet de recherche de la fouille de documents multimédia ou Media Mining. En effet, l’exploitation d’un tel volume d’informations requiert l’automatisation de tout ou partie des traitements d’analyse, d’interprétation et de compréhension des contenus. Il s’agit donc de rechercher, de collecter, d’extraire, de classer, de transformer ou, plus généralement, de traiter l’information issue des documents disponibles et, enfin, de la diffuser de façon sélective en alertant les utilisateurs concernés. Cet ensemble d’analyses est généralement implémenté sous forme d’une même chaine de traitement. Ceci permet de diminuer la quantité d’outils que l’analyste doit maîtriser et utiliser durant sa veille et par là même de faciliter le passage de l’information entre les différents services d’analyse. Ces chaines de traitement apportent une valeur ajoutée dans la recherche d’informations à partir de sources ouvertes mais également dans le traitement de l’ensemble des informations numériques. Dans le cadre du ROSO, elles implémentent des technologies principalement issues des domaines de l’Intelligence Artificielle (IA) et de la gestion des connaissances (KM pour Knowledge Management). Concernant le traitement des données textuelles, par exemple, différentes approches complémentaires peuvent être utilisées. Ainsi, des techniques statistiques permettent d’analyser les contenus d’un grand nombre de documents pour déterminer automatiquement les sujets abordés en fonction des termes les plus discriminants. Par ailleurs, des techniques probabilistes peuvent également être utilisées avec succès pour identifier la langue d’un document. Des techniques d’analyse linguistique à base de grammaires permettent de réaliser d’autres types de traitement en Extraction d’information (EI) tels que la recherche d’expressions régulières, d’amorces de phrases, de noms de personnes, de dates d’événements, etc. Une analyse sémantique permet, quant à elle, de traduire les chaines de caractères ou les données techniques contenues dans les documents multimédia par des concepts de haut niveau. Par ailleurs, des ontologies de domaine peuvent être définies et utilisées pour annoter et rechercher les documents selon un modèle commun bien défini. La même variété de technologies et approches se retrouve dans le domaine du multimédia. La transcription de la parole, par exemple, permet de réaliser des fonctions similaires aux documents texte sur les documents audio ou vidéo. Une fois transcrit, le document peut être indexé puis retrouvé de façon rapide et efficace. De plus, des outils de traduction peuvent également être intégrés dans une chaîne de traitement. Dans le domaine de l’image, la détection ou la reconnaissance de visages, la recherche par similarité peuvent permettre de retrouver automatiquement une information d’intérêt. La combinaison des techniques de fouille de textes et de fouilles de documents audio ou vidéo ouvre la voie à des traitements de plus en plus puissants. Côté logiciels, il existe un grand nombre de solutions et de briques technologiques mises à disposition par des éditeurs commerciaux ou en open-source et par la communauté scientifique. Le choix de la meilleure brique est souvent très difficile car les critères sont nombreux, variés et évolutifs. Pour composer des offres "sur mesure" bien adaptées au besoin, des plateformes dites d’intégration permettent d’assembler et de faire inter-opérer les outils sélectionnés. Le choix d’une plateforme devient 5 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction alors un enjeu essentiel pour produire un système de traitement des informations structurées et non structurées. Seule une plateforme basée sur des standards largement répandus peut permettre d’assurer l’interopérabilité des outils retenus. WebLab est une de ces plateformes d’intégration, elle est développée et maintenue par la société Cassidian et constitue le socle fonctionnel et technque au sein duquel nos recherches se sont déroulées [Giroux et al., 2008] La plateforme WebLab vise à faciliter l’intégration de composants logiciels plus particulièrement dédiés, au traitement de documents multimédia et d’informations non-structurées (texte, image, audio et vidéo) au sein d’applications dédiées à diverses activités de veille telles que le ROSO mais aussi la veille économique et stratégique. Différents composants spécifiques viennent ré- gulièrement enrichir cette plateforme pour lui offrir des fonctionnalités de collecte de données sur des sources ouvertes (Internet, TV ou radio, presse écrite, etc.) ou dans des entrepôts privés, de traitement automatique des contenus (extraction d’information, analyse sémantique, classification, transcription de la parole, traduction, segmentation, reconnaissance d’écriture, etc.), de capitalisation (stockage, indexation, enregistrement dans des bases de connaissance, etc.) et d’exploitation des connaissances (recherche avancée, visualisation et synthèse graphique, aide à la décision, etc.). Les objectifs scientifiques et technologiques de la plateforme sont multiples : – Il s’agit de définir un modèle de référence, basé sur les standards du Web Sémantique (XML, RDF, RDFS, OWL, SPARQL, etc.), permettant à des composants logiciels hétérogènes d’échanger efficacement des données brutes, des méta-données associées ou des informations élaborées de façon automatique. – Il s’agit également de proposer des interfaces génériques de services afin de normaliser les interactions entre les composants et de simplifier la construction de chaînes de traitement au sein desquelles ils sont mis en œuvre conjointement. – Il s’agit enfin de proposer et de mettre à disposition un ensemble de briques logicielles réutilisables et composables pour construire rapidement des applications adaptées à un besoin particulier. Ces briques prennent la forme de services qui couvrent un large spectre de fonctionnalités et de composants d’IHM 1 qui permettent de piloter les services et d’en exploiter les résultats côté utilisateur. Enfin, l’IHM est constituée par assemblage de composants qui s’exécutent au sein d’un portail Web personnalisable par l’utilisateur final. Pour des besoins nouveaux ou spécifiques, les services et composants d’IHM peuvent être créés de toute pièce ou développés en intégrant des composants du commerce et/ou open-source. L’architecture de cette plateforme est résumée par la figure 1. 2 Objectifs et axes de recherche Étant donné le contexte que nous venons de décrire, cette thèse a pour objectif de faciliter et de réduire le travail des analystes dans le cadre du ROSO et de la veille plus généralement. Face à l’augmentation croissante des informations disponibles pour tous librement et légalement, notamment sur le Web, et face à l’hétérogénéité des contenus, il s’agit de proposer un système global de capitalisation des connaissances permettant aux acteurs du ROSO d’exploiter cette masse d’informations. 1. Interface Homme-Machine 6 Copyright c 2013 - CASSIDIAN - All rights reserved2. Objectifs et axes de recherche FIGURE 1 – Architecture de la plateforme WebLab Nos recherches s’articulent autour de trois axes principaux, correspondant à trois des nombreuses problématiques de l’Intelligence Artificielle : – Modélisation de l’information – Extraction d’information – Capitalisation des connaissances Nos travaux au sein de ce premier axe visent à définir l’étendue et la nature des informations d’intérêt pour le domaine du ROSO, c’est-à-dire mettre en place un modèle de connaissances. Plus concrètement, il s’agira de recenser, définir et formaliser sémantiquement l’ensemble de concepts utilisés par les experts de ce domaine et leurs relations. Ce modèle servira de socle de référence à notre processus global de capitalisation des connaissances : pour exprimer l’ensemble des informations de façon unifiée mais aussi assurer une communication entre les différents services de traitement de l’information développés. Nous explorerons pour cela les travaux existants et notamment les représentations sous forme d’ontologie de domaine qui est, à l’heure actuelle, le mode de représentation le plus utilisé dans ce but. Le second axe a pour objectif de proposer une approche nouvelle d’extraction d’information à partir de textes en langage naturel. Celle-ci devra permettre de repérer automatiquement l’ensemble des entités et événements d’intérêt pour le ROSO définis au sein du premier axe de recherche. Pour ce faire, 7 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction nous nous intéresserons notamment à la combinaison de différentes techniques actuelles (linguistiques, statistiques ou hybrides) afin d’améliorer la qualité des résultats obtenus. Le dernier axe de recherche vise à définir un processus de transformation des informations extraites en réelles connaissances, c’est-à-dire les normaliser, les structurer, les relier, considérer les problématiques de continuité (redondance/contradiction, temps/espace), etc. Ces traitements doivent aboutir à la création de fiches de connaissances destinées aux analystes, résumant l’ensemble du savoir acquis automatiquement au sujet d’une entité d’intérêt. Celles-ci seront stockées et gérées au sein d’une base de connaissances pour permettre leur mise à jour lors du traitement de nouveaux documents mais également des mécanismes de raisonnement/inférence afin d’en déduire de nouvelles connaissances. Une place importante sera réservée à l’articulation de ces trois axes de recherche au sein d’un processus global de capitalisation des connaissances que nous souhaitons maintenir le plus générique et flexible possible. La figure 2 présente de façon synthétique la problématique et les objectifs de nos recherches. 3 Contributions de la thèse Nos travaux de recherche ont donné lieu à plusieurs contributions selon les objectifs que nous venons de définir ainsi qu’à un certain nombre de publications que nous listons ci-dessous. Nous avons tout d’abord réalisé un état de l’art des différents axes de recherche abordés par le sujet. Suite à cela, nous avons mis en place une ontologie de domaine nommée WOOKIE (Weblab Ontology for Open sources Knowledge and Intelligence Exploitation) dédiée à la représentation des connaissances spécifiques au ROSO et à la veille de façon plus générale. Nous avons notamment défini, et intégré au sein de WOOKIE, un modèle de représentation de l’événement en prenant pour base les conclusions de l’état de l’art. Un événement y est défini comme une entité complexe à quatre dimensions : une dimension conceptuelle (le type de l’événement), une dimension temporelle (la date de l’événement), une dimension spatiale (le lieu de l’événement) et une dimension agentive (les participants de l’événement). Dans un second temps, nous avons élaboré et évalué un système d’extraction d’événements dit "mixte". En effet, les travaux explorés dans le domaine de l’extraction d’information ayant mis en évidence un certain nombre de limites aux techniques existantes (symboliques et statistiques), nous nous sommes orientés vers une approche combinant deux techniques actuelles. La première méthode proposée consiste en des règles d’extraction élaborées manuellement couplées avec une analyse syntaxique en dépendance. La seconde est basée sur un apprentissage dit "symbolique" de patrons linguistiques par extraction de motifs séquentiels fréquents. Nous avons implémenté ces deux extracteurs en prenant pour base l’ontologie de domaine WOOKIE ainsi que notre représentation des événements et en assurant une possible intégration au sein de la plateforme WebLab. Une première évaluation de ces deux extracteurs a été mise en œuvre et publiée (voir les publications ci-dessous). Chacune des deux méthodes a obtenu des résultats satisfaisants et comparables à l’état de l’art. Cette évaluation a également montré qu’un processus d’agrégation adapté permettra d’exploiter au mieux les points forts de ces deux approches et d’ainsi améliorer significativement la qualité de l’extraction d’événements. Ce processus d’agrégation constitue notre troisième contribution. Pour cela, nous avons exploré notamment les travaux existants en fusion de données et plus particulièrement en fusion d’informations textuelles. Nous avons choisi d’élaborer un processus d’agrégation sémantique multi-niveaux : une simi- 8 Copyright c 2013 - CASSIDIAN - All rights reserved3. Contributions de la thèse FIGURE 2 – Système de capitalisation des connaissances proposé 9 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction larité entre événements est estimée au niveau de chaque dimension puis nous définissons un processus d’agrégation global basé sur ces similarités intermédiaires pour aider l’utilisateur à déterminer si deux événements extraits réfèrent ou non à un même événement dans la réalité. Les similarités sont exprimées selon une échelle qualitative définie en prenant en compte les besoins des utilisateurs finaux. Enfin, nous avons implémenté un prototype d’évaluation permettant l’agrégation des événements suivant le processus. Nos travaux de recherche ont donné lieu à plusieurs publications dans des conférences nationales et internationales dans les domaines abordés par cette thèse : – Serrano, L., Grilheres, B., Bouzid, M., and Charnois, T. (2011). Extraction de connaissances pour le renseignement en sources ouvertes. In Atelier Sources Ouvertes et Services (SOS 2011) en conjonction avec la conférence internationale francophone (EGC 2011), Brest, France – Serrano, L., Charnois, T., Brunessaux, S., Grilheres, B., and Bouzid, M. (2012b). Combinaison d’approches pour l’extraction automatique d’événements (automatic events extraction by combining multiple approaches) [in french]. In Actes de la conférence conjointe JEP-TALN-RECITAL 2012, volume 2: TALN, Grenoble, France. ATALA/AFCP – Serrano, L., Bouzid, M., Charnois, T., and Grilheres, B. (2012a). Vers un système de capitalisation des connaissances : extraction d’événements par combinaison de plusieurs approches. In Atelier des Sources Ouvertes au Web de Données (SOS-DLWD’2012) en conjonction avec la conférence internationale francophone (EGC 2012), Bordeaux, France – Caron, C., Guillaumont, J., Saval, A., and Serrano, L. (2012). Weblab : une plateforme collaborative dédiée à la capitalisation de connaissances. In Extraction et gestion des connaissances (EGC’2012), Bordeaux, France – Serrano, L., Bouzid, M., Charnois, T., Brunessaux, S., and Grilheres, B. (2013b). Extraction et agrégation automatique d’événements pour la veille en sources ouvertes : du texte à la connaissance. In Ingénierie des Connaissances 2013 (IC 2013), Lille, France – Serrano, L., Bouzid, M., Charnois, T., Brunessaux, S., and Grilheres, B. (2013a). Events extraction and aggregation for open source intelligence: from text to knowledge. In IEEE International Conference on Tools with Artificial Intelligence (ICTAI 2013), Washington DC, USA 4 Organisation du mémoire Ce mémoire est organisé en deux parties reflétant l’ensemble du travail de recherche accompli durant cette thèse : – la première partie État de l’art est divisée en trois chapitres et présente l’étude de l’état de l’art réalisée ; – la seconde partie Contributions de la thèse, composée de quatre chapitres, expose l’ensemble des contributions réalisées. Le premier chapitre, intitulé Représentation des connaissances, propose un tour d’horizon, centré sur notre problématique, du domaine de la représentation et de la modélisation des connaissances. Nous commençons par rappeler succinctement les concepts de base dans ce cadre avant d’aborder la thématique de l’information sémantique avec notamment les travaux autour du Web sémantique et des ontologies. En- fin, nous centrons notre présentation sur l’objet central à cette thèse – les événements – afin de rappeler comment ce concept et ses propriétés ont été définis et modélisés jusqu’à nos jours au sein des différents 10 Copyright c 2013 - CASSIDIAN - All rights reservedaxes de recherche mentionnés précédemment. Le second chapitre Extraction automatique d’information réalise un état de l’art autour de la problé- matique principale de nos travaux, à savoir l’extraction automatique d’information. Dans celui-ci nous recensons notamment les différentes recherches menées récemment autour des trois grands types d’objets de l’EI que sont kes entités nommées, les relations et enfin les événements. Puis, nous nous focalisons sur des aspects plus applicatifs à travers la présentation de quelques plateformes/logiciels pour l’EI et un certain nombre de cas d’application dans ce domaine. Nous clôturons ce chapitre en abordant les problé- matiques d’évaluation et les performances des méthodes proposées en EI. Le chapitre Capitalisation des connaissances termine cette partie d’état de l’art par une présentation d’ensemble de la problématique nouvelle que constitue la capitalisation des connaissances. Celle-ci aborde tout d’abord les travaux liés à notre sujet de recherche dans des domaines tels que la fusion et la réconciliation de données mais également le mouvement nouveau autour du Web de données. Enfin, nous présentons un ensemble d’approches existantes visant à appliquer les techniques de capitalisation au traitement des événements. En seconde partie, le quatrième chapitre, intitulé Modélisation des connaissances du domaine, dé- taille la première contribution proposée durant nos travaux de thèse : une modélisation des événements ainsi qu’une ontologie de domaine nommée WOOKIE. Celles-ci ont été élaborées en fonction des conclusions de notre état de l’art et de façon adaptée à notre problématique et notre cadre de recherche, à savoir l’extraction automatique des événements dans le cadre du ROSO. Le chapitre Extraction automatique des événements constitue le cœur de nos recherches et présente notre seconde contribution, c’est-à-dire l’ensemble de nos réalisations autour du second axe de nos recherches. Nous y détaillons, tout d’abord, la méthode que nous avons élaborée pour l’extraction automatique des entités nommées pour les langues anglais et française. Puis, est explicitée et exemplifiée notre contribution centrale, à savoir la conception et la réalisation d’une approche pour l’extraction automatique des événements fondée sur deux méthodes issues de l’état de l’art que nous améliorées et adaptées à notre problématique et à notre cadre applicatif. Le chapitre suivant Agrégation sémantique des événements présente les recherches que nous avons menées dans le cadre du troisième axe "Capitalisation des connaissances". Tout d’abord, nous nous sommes intéressés à la réconciliation de divers méthodes et systèmes pour proposer une méthodologie générique d’agrégation sémantique des événements issus des outils d’extraction. Ce chapitre présente ses fondements autour d’une approche permettant d’estimer la similarité sémantique entre événements et ensuite de les agréger pour faciliter le travail des analystes du ROSO. Notre mémoire se poursuit avec le dernier chapitre nommé Expérimentations et résultats dans lequel sont exposées deux expérimentations réalisées dans le cadre de cette thèse dans le but d’estimer les apports et limites des contributions présentées. La première évaluation concerne notre approche pour l’extraction automatique des événements : pour ce faire nous avons employé un corpus de test issu d’une campagne d’évaluation en EI ainsi que des métriques classiques dans cette discipline. La seconde évaluation est qualitative est montre l’apport de notre méthode d’agrégation sémantique des événements au travers d’exemples réels issus de nos travaux. Pour chacune de ces expérimentations nous exposons également leurs limites ainsi que les perspectives envisagées. Nous conclurons ce mémoire de recherche en rappelant l’ensemble des contributions réalisées, puis nous exposerons les différentes perspectives ouvertes par nos travaux. 11 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction 12 Copyright c 2013 - CASSIDIAN - All rights reservedPremière partie État de l’art 13 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction Cette première partie a pour objectif de réaliser un tour d’horizon de l’existant dans les principaux domaines abordés par cette thèse. Le premier chapitre de cet état de l’art (chapitre 1) sera centré sur les concepts et approches actuels en représentation des connaissances. L’accent sera mis ici sur les technologies du Web sémantique et la modélisation des événements. Le chapitre suivant (chapitre 2) explorera les principales recherches et réalisations dans le domaine de l’extraction d’information et plus particuliè- rement les travaux concernant l’une de nos principales problématiques, à savoir l’extraction automatique des événements. Pour finir, nous aborderons, au travers du chapitre 3, un ensemble de travaux menés autour de la capitalisation des connaissances, notamment en fusion de données et résolution de coréfé- rence entre événements. Pour conclure chacun de ces trois chapitres, nous dresserons un bilan des forces et faiblesses des approches explorées et nous introduirons chacune de nos contributions en réponse à cet état de l’art. 15 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction 16 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1 Représentation des connaissances Sommaire 1.1 Données, informations et connaissances . . . . . . . . . . . . . . . . . . . . . 18 1.2 L’information sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.1 Le Web sémantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.2 Les ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.2.3 Les langages de représentation . . . . . . . . . . . . . . . . . . . . . . . 22 1.2.4 Inférence et bases de connaissances . . . . . . . . . . . . . . . . . . . . . 23 1.2.5 Les éditeurs d’ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3 Modélisation des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.3.1 Qu’est-ce qu’un événement ? . . . . . . . . . . . . . . . . . . . . . . . . 26 1.3.1.1 Les événements en extraction d’information . . . . . . . . . . . . . 27 1.3.1.2 Les ontologies orientées "événement" . . . . . . . . . . . . . . . . 28 1.3.2 Modélisation du temps et de l’espace . . . . . . . . . . . . . . . . . . . . 33 1.3.2.1 Représentation du temps . . . . . . . . . . . . . . . . . . . . . . . 33 1.3.2.2 Représentation de l’espace . . . . . . . . . . . . . . . . . . . . . . 34 1.3.3 Spécifications dédiées au ROSO . . . . . . . . . . . . . . . . . . . . . . . 35 1.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 17 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances Dans ce premier chapitre nous réalisons un tour d’horizon, centré sur notre problématique de recherche, des domaines de la représentation et de la modélisation des connaissances. Nous commençons par rappeler succinctement les concepts de base de donnée, information et connaissance, avant d’aborder la thématique de l’information sémantique avec notamment les travaux autour du Web sémantique et des ontologies. Enfin, nous centrons notre présentation sur l’objet central à cette thèse – les événements – afin de déterminer comment ce concept et ses propriétés sont définis et modélisés par les différents travaux actuels. 1.1 Données, informations et connaissances La distinction entre les termes "donnée", "information" et "connaissance" est couramment abordée dans la littérature liée à la gestion des connaissances [Balmisse, 2002] [Crié, 2003] [Paquet, 2008]. Celleci est nécessaire afin, d’une part, de mieux comprendre les différentes problématiques soulevées par le traitement de l’information (au sens large) et, d’autre part, de pointer à quel niveau d’analyse se situent les différents technologies et outils existants. Une donnée est généralement définie comme un élément brut non traité et disponible hors de tout contexte. Une fois collectées et traitées, par le cerveau humain ou par une machine, ces données deviennent des informations. Une information est le résultat de la contextualisation d’un ensemble de données afin d’en saisir les liens et de leur donner un sens. L’information est statique et périssable, sa valeur diminue dans le temps (car dépendante de son contexte qui est amené à varier). A l’inverse, la connaissance est le résultat d’un processus dynamique visant à assimiler/comprendre les principes sous-jacents à l’ensemble des informations obtenues. Cette compréhension permet de prévoir l’évolution future d’une situation et d’entreprendre des actions en conséquence. Sous réserve de cette interprétation profonde, une plus grande quantité d’information mène à une meilleure connaissance d’un sujet donné. Prenons par exemple la donnée brute "11/20", sans indication de contexte, cette suite de symboles peut véhiculer diverses informations et ne peut être exploitée en l’état. Toutefois, si cela fait référence à la note obtenue an mathématiques par Pierre, cette donnée contextualisée prend du sens et devient une information. Par ailleurs, si cette première information est associée avec le fait que la moyenne de la classe s’élève à 13/20, chacun peut faire le lien entre ces deux informations et savoir (obtenir la connaissance) que Pierre a des difficultés dans cette matière. Ainsi, cette connaissance acquise, les parents de Pierre pourront, par exemple, prendre la décision de l’inscrire à du soutien scolaire. La distinction entre ces trois concepts correspond à la dimension hiérarchique de la connaissance proposée par [Charlot and Lancini, 2002]. Les auteurs définissent quatre autres dimensions dont la dimension épistémologique introduisant deux grandes formes de connaissance : celle dite "explicite" qui peut être codifiée et partagée, d’une part, et celle dite "tacite", d’autre part, difficilement exprimable dans un langage commun et donc peu transmissible. Cette définition suggérée par [Polanyi, 1966] est largement partagée par les cogniticiens. Depuis les débuts du Web, ce passage des données aux connaissances s’est placé au centre des pré- occupations de divers secteurs d’activité (industriel, gouvernemental, académique, etc.). En effet, avec l’explosion de la quantité d’information mise en ligne, il est devenu primordial, en particulier pour les organisations, de pouvoir exploiter cette masse afin d’en obtenir des connaissances. Nous sommes passés ainsi de l’époque des bases de données à celle des bases de connaissances. 18 Copyright c 2013 - CASSIDIAN - All rights reserved1.2. L’information sémantique 1.2 L’information sémantique Le développement du Web et des NTIC 2 a mis en avant un nouvel enjeu : le partage des connaissances. D’un Web de documents (Web 1.0) voué à la publication/visualisation statique des informations grâce au langage HTML, nous avons évolué vers un Web plus collaboratif et dynamique. Ce Web 2.0, introduit aux débuts des années 2000, a constitué une première évolution dans ce sens en remettant l’homme au centre de la toile grâce aux blogs, réseaux sociaux, wikis et autres moyens lui permettant de créer, publier et partager ses propres connaissances. Dès les début du Web 2.0, Tim Berners-Lee évoquait déjà la prochaine "version" du World Wide Web : le Web sémantique [Berners-Lee et al., 2001]. Les sections suivantes présentent ce Web 3.0 et les différentes technologies associées. 1.2.1 Le Web sémantique Le Web sémantique désigne un projet d’évolution de notre Web actuel (Web 2.0) initié par le W3C3 . Cette initiative est aussi connue sous les noms de Web de données, Linked Data, Linked Open Data ou encore Linking Open Data. L’objectif principal de ce mouvement est de faire en sorte que la quantité de données exposée sur le Web (qui ne cesse de croître) soit disponible dans un format standard, accessible et manipulable de manière unifiée par toutes les applications du Web. Le Web sémantique de Tim Berners-Lee est voué à donner du sens à l’ensemble des données mises en ligne afin de faciliter la communication entre les hommes et les machines et permettre ainsi à ces dernières de réaliser des tâches qui incombaient jusqu’alors aux utilisateurs. Par ailleurs, le nom Web de données met en avant la nécessité de créer des liens entre données pour passer d’un Web organisé en silos de données déconnectés (ayant leur propres formats, protocoles, applications, etc.) à un espace unifié sous la forme d’une collection de silos inter-connectés. La figure 1.1 présente l’état actuel du LOD 4 sous la forme d’un graphe où les noeuds correspondent à des bases de connaissances respectant les principes du Web sémantique et les arcs représentent les liens existants. Parmi les plus renommés des silos de données, la base sémantique DBPedia fournit une grande partie du contenu de Wikipedia et incorpore des liens vers d’autres bases de connaissances telles que Geonames, par exemple. Ces relations (sous la forme de triplets RDF 5 , voir la section 1.2.3) permettent aux applications Web d’exploiter la connaissance supplémentaire (et potentiellement plus précise) issue d’autres bases de connaissances et de fournir ainsi de meilleurs services à leurs utilisateurs. 2. Nouvelles Technologies de l’Information et de la Communication 3. World Wide Web Consortium, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴ 4. Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch. ❤tt♣✿✴✴❧♦❞✲❝❧♦✉❞✳♥❡t✴ 5. Resource Description Framework, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴❘❉❋✴ 19 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances As of September 2011 Music Brainz (zitgist) P20 Turismo de Zaragoza yovisto Yahoo! Geo Planet YAGO World Factbook El Viajero Tourism WordNet (W3C) WordNet (VUA) VIVO UF VIVO Indiana VIVO Cornell VIAF URI Burner Sussex Reading Lists Plymouth Reading Lists UniRef UniProt UMBEL UK Postcodes legislation data.gov.uk Uberblic UB Mannheim TWC LOGD Twarql transport data.gov. uk Traffic Scotland theses. fr Thesaurus W totl.net Telegraphis TCM Gene DIT Taxon Concept Open Library (Talis) tags2con delicious t4gm info Swedish Open Cultural Heritage Surge Radio Sudoc STW RAMEAU SH statistics data.gov. uk St. Andrews Resource Lists ECS Southampton EPrints SSW Thesaur us Smart Link Slideshare 2RDF semantic web.org Semantic Tweet Semantic XBRL SW Dog Food Source Code Ecosystem Linked Data US SEC (rdfabout) Sears Scotland Geography Scotland Pupils & Exams Scholarometer WordNet (RKB Explorer) Wiki UN/ LOCODE Ulm ECS (RKB Explorer) Roma RESEX RISKS RAE2001 Pisa OS OAI NSF Newcastle LAAS KISTI JISC IRIT IEEE IBM Eurécom ERA ePrints dotAC DEPLOY DBLP (RKB Explorer) Crime Reports UK Courseware CORDIS (RKB Explorer) CiteSeer Budapest ACM riese Revyu research data.gov. uk Ren. Energy Generators reference data.gov. uk Rechtspraak. nl RDF ohloh Last.FM (rdfize) RDF Book Mashup Rådata nå! PSH Product Types Ontology Product DB PBAC Poké- pédia patents data.go v.uk Ox Points Ordnance Survey Openly Local Open Library Open Cyc Open Corporates Open Calais OpenEI Open Election Data Project Open Data Thesaurus Ontos News Portal OGOLOD Janus AMP Ocean Drilling Codices New York Times NVD ntnusc NTU Resource Lists Norwegian MeSH NDL subjects ndlna my Experiment Italian Museums meducator MARC Codes List Manchester Reading Lists Lotico Weather Stations London Gazette LOIUS Linked Open Colors lobid Resources lobid Organisations LEM Linked MDB LinkedL CCN Linked GeoData LinkedCT Linked User Feedback LOV Linked Open Numbers LODE Eurostat (Ontology Central) Linked EDGAR (Ontology Central) Linked Crunchbase lingvoj Lichfield Spending LIBRIS Lexvo LCSH DBLP (L3S) Linked Sensor Data (Kno.e.sis) Klappstuhlclub Goodwin Family National Radioactivity JP Jamendo (DBtune) Italian public schools ISTAT Immigration iServe IdRef Sudoc NSZL Catalog Hellenic PD Hellenic FBD Piedmont Accomodations GovTrack GovWILD Google Art wrapper gnoss GESIS GeoWord Net Geo Species Geo Names Geo Linked Data GEMET GTAA STITCH SIDER Project Gutenberg Medi Care Eurostat (FUB) EURES Drug Bank Diseasome DBLP (FU Berlin) Daily Med CORDIS (FUB) Freebase flickr wrappr Fishes of Texas Finnish Municipalities ChEMBL FanHubz Event Media EUTC Productions Eurostat Europeana EUNIS EU Institutions ESD standards EARTh Enipedia Population (EnAKTing) NHS (EnAKTing) Mortality (EnAKTing) Energy (EnAKTing) Crime (EnAKTing) CO2 Emission (EnAKTing) EEA SISVU educatio n.data.g ov.uk ECS Southampton ECCOTCP GND Didactal ia DDC Deutsche Biographie data dcs Music Brainz (DBTune) Magnatune John Peel (DBTune) Classical (DB Tune) Audio Scrobbler (DBTune) Last.FM artists (DBTune) DB Tropes Portuguese DBpedia dbpedia lite Greek DBpedia DBpedia dataopenac-uk SMC Journals Pokedex Airports NASA (Data Incubator) Music Brainz (Data Moseley Incubator) Folk Metoffice Weather Forecasts Discogs (Data Incubator) Climbing data.gov.uk intervals Data Gov.ie data bnf.fr Cornetto reegle Chronicling America Chem2 Bio2RDF Calames business data.gov. uk Bricklink Brazilian Politicians BNB UniSTS UniPath way UniParc Taxono my UniProt (Bio2RDF) SGD Reactome PubMed Pub Chem PROSITE ProDom Pfam PDB OMIM MGI KEGG Reaction KEGG Pathway KEGG Glycan KEGG Enzyme KEGG Drug KEGG Compound InterPro Homolo Gene HGNC Gene Ontology GeneID Affymetrix bible ontology BibBase FTS BBC Wildlife Finder BBC Program mes BBC Music Alpine Ski Austria LOCAH Amsterdam Museum AGROV OC AEMET US Census (rdfabout) Media Geographic Publications Government Cross-domain Life sciences User-generated content FIGURE 1.1 – Linking Open Data 20 Copyright c 2013 - CASSIDIAN - All rights reserved1.2. L’information sémantique Pour mettre en œuvre les principes du Web sémantique, le W3C recommande un ensemble de technologies du Web sémantique (RDF, OWL, SKOS, SPARQL, etc.) fournissant un environnement dans lequel les applications du Web peuvent partager une modélisation commune, interroger "sémantiquement" le LOD (Linked Open Data), inférer de nouvelles connaissances à partir de l’existant, etc. 1.2.2 Les ontologies Le concept d’ontologie s’avère aujourd’hui indissociable du Web sémantique. Toutefois, les ontologies ne sont pas nouvelles et sont les héritières des travaux en Ontologie (la science de l’Être) menés par des philosophes de le Grèce antique tels qu’Aristote ou Platon. L’ontologie telle qu’on l’entend en informatique est maintenant assez éloignée de ces études menées au carrefour entre la métaphysique et la philosophie. Plusieurs définitions ont été proposées dont celles de [Gruber, 1993] et [Neches et al., 1991]. Le premier donne une définition très abstraite des ontologies mais largement admise dans la littérature : "Une ontologie est une spécification explicite d’une conceptualisation" 6 . Le second propose celle-ci : "Une ontologie définit les termes et les relations de base du vocabulaire d’un domaine ainsi queMaître de conférences les règles qui permettent de combiner les termes et les relations afin de pouvoir étendre le vocabulaire" 7 . La définition de [Gruber, 1993] renvoie à deux caractéristiques principales des ontologies à savoir, d’une part, l’élaboration d’un modèle abstrait de l’existant (conceptualisation) et, d’autre part, sa formalisation en vue d’une exploitation par des machines (spécification explicite). Les ontologies à l’ère du Web sémantique sont aux bases de connaissances ce que les modèles de données sont aux bases de données [Charlet et al., 2004]. Elles définissent l’ensemble des objets du domaine de connaissances ciblé ainsi que les attributs et relations caractérisant ces objets. Les objets sont représentés sous forme de concepts hiérarchisés constituant la taxonomie de classes de l’ontologie. Cette relation de subsomption se retrouve dans toutes les ontologies, quelque soit le domaine concerné : les classes de plus haut niveau dans la hiérarchie correspondent à des concepts généraux et les classes inférieures représentent des concepts plus spécifiques. S’ajoutent à cette taxonomie des relations entre concepts de nature diverse ainsi que des attributs de concepts. Les premières ont pour domaine ("domain" en anglais) et co-domaine ("range" en anglais) des classes de l’ontologie tandis que les seconds ont pour domaine une classe et pour co-domaine une valeur d’un certain type (chaine de caractères, nombre, date, booléen, etc.). Ce type de modélisation implique un phénomène d’héritage : chaque classe de l’ontologie hérite des propriétés (relations et attributs) de sa classe supérieure (dite "classe mère"). Pour résumer, nous pouvons dire qu’une ontologie définit sémantiquement et de façon non-ambigüe un ensemble de concepts et propriétés issus d’un consensus. Un exemple commun dans la communauté d’ingénierie des connaissances est l’ontologie des pizza.owl servant couramment de base aux tutoriels dédiés aux ontologies. Cet exemple-type très complet contient un ensemble de classes, propriétés, attributs et instances du domaine ainsi que des fonctionnalités plus avancées de contraintes, cardinalités et axiomes. L’annexe G présente une vue d’ensemble de cette ontologie grâce au logiciel Protégé (présenté en section 1.2.5). 6. traduction de l’anglais "An ontology is an explicit specification of a conceptualization" 7. traduction de l’anglais "An ontology defines the basic terms and relations comprising the vocabulary of a topic area as well as the rules for combining terms and relations to define extensions to the vocabulary" 21 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances Par ailleurs, on distingue différents types d’ontologie selon la portée de la modélisation [Guarino, 1998] : les ontologies dites "générales" ou "de haut niveau", les ontologies de domaine, de tâche ou d’application. Les premières visent à décrire les objets du monde communs à plusieurs domaines tels que le temps et l’espace alors que les trois autres types modélisent des concepts spécifiques. La création d’ontologies de haut niveau est parfois vue comme une utopie et la majorité des travaux de la littérature se fondent sur des ontologies de domaine. Plusieurs aspects peuvent rendre la construction d’une ontologie délicate et coûteuse en temps. En effet, ce travail de modélisation comporte une part de subjectivité car plusieurs visions d’un même domaine sont possibles et le temps pour arriver à un consensus peut s’en trouver allongé. Ce phénomène s’amplifie avec la complexité du domaine à modéliser mais également avec la taille de la communauté concernée. Afin de faciliter la tâche d’élaboration d’une ontologie des travaux tels que [Noy and Mcguinness, 2001], [Mizoguchi, 2003a] ou encore [Mizoguchi, 2003b] suggèrent un ensemble de bonnes pratiques. 1.2.3 Les langages de représentation Pour permettre aux ordinateurs d’exploiter cette modélisation, des langages informatiques de spéci- fication d’ontologie ont été créés dans le cadre du Web Sémantique. Les premiers langages ont été développés par la DARPA au début des années 2000, il s’agit de DAML 8 , OIL 9 [Fensel et al., 2001] ou DAML+OIL [Horrocks, 2002]. Ceux-ci sont les ancêtres des langages RDFS et OWL 10 devenus les recommandations actuelles du W3C. La majorité d’entre eux est fondée sur des formalismes inspirés du modèle des assertions en logique de premier ordre. RDF est le formalisme recommandé par le W3C mais d’autres existent tels que Common Logic 11 [Bachmair and Ganzinger, 2001], DOGMA 12 [Jarrar and Meersman, 2009], KIF 13 [Genesereth, 1991], F-Logic 14 [Kifer et al., 1995], etc. RDF est un formalisme pour la représentation de faits sur le Web fondé sur la notion de triplet. Tel les assertions en logique des prédicats, un triplet RDF est composé de trois éléments : un sujet, un prédicat et un objet. Le sujet et le prédicat sont des ressources et, dans le cas du Web sémantique, il s’agit de tout objet pouvant être identifié (une page Web, une personne, une propriété, etc.). Une ressource Web est représentée par un URI 15 qui peut être, par commodité, raccourci grâce à un espace de nom (namespace). L’objet du triplet, quant à lui, peut être soit une ressource (le triplet exprime une relation entre objets) soit une valeur (le triplet exprime un attribut d’un objet). L’ensemble des valeurs possibles en RDF est emprunté du format XML. Bien que le W3C recommande l’utilisation du formalisme RDF/XML, d’autres types de sérialisation existent telles que les formats N3 (Notation3), N-triples, Turtle, JSON, etc. 8. DARPA Agent Markup Language 9. Ontology Inference Layer 10. Ontology Web Language, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴❚❘✴♦✇❧✲❢❡❛t✉r❡s✴ 11. ❤tt♣✿✴✴✐s♦✲❝♦♠♠♦♥❧♦❣✐❝✳♦r❣✴ 12. Developing Ontology-Grounded Methods and Applications, ❤tt♣✿✴✴✇✇✇✳st❛r❧❛❜✳✈✉❜✳❛❝✳❜❡✴r❡s❡❛r❝❤✴❞♦❣♠❛✳ ❤t♠ 13. Knowledge Interchange Format, ❤tt♣✿✴✴✇✇✇✳❦s❧✳st❛♥❢♦r❞✳❡❞✉✴❦♥♦✇❧❡❞❣❡✲s❤❛r✐♥❣✴❦✐❢✴ 14. Frame Logic 15. Uniform Resource Identifier 22 Copyright c 2013 - CASSIDIAN - All rights reserved1.2. L’information sémantique Le langage RDFS est une première extension de RDF visant à structurer les ressources pour la spécification des ontologies. Les propriétés les plus utilisées du formalisme RDFS sont les suivantes : rdfs :Class, rdfs :subClassOf, rdfs :domain, rdfs :range et rdfs :label. Les deux premières servent à défi- nir la taxonomie de l’ontologie, les deux suivantes permettant de formaliser la notion de sujet et d’objet et enfin, la propriété label sert à nommer les éléments de l’ontologie (classes et propriétés). Enfin, le langage largement privilégié aujourd’hui pour la modélisation des ontologies est OWL. Dé- veloppé depuis 2002 par un groupe de travail du W3C, celui-ci constitue une seconde extension plus expressive du standard RDF/XML. OWL permet notamment grâce à des constructeurs d’exprimer des contraintes supplémentaires sur les classes et propriétés définies : disjonction, union et intersection de classes, propriétés symétriques, inverses, etc. Une majeure partie de ces constructeurs est directement issue des logiques de description permettant des mécanismes d’inférence sur les connaissances de l’ontologie. Précisons également que le langage OWL se décline en plusieurs sous-langages selon leurs niveaux d’expressivité : OWL-Lite, OWL-DL et OWL-Full. Nous présentons en annexe H un extrait de l’ontologie pizza.owl exprimée au format OWL. 1.2.4 Inférence et bases de connaissances Nous pouvons définir l’inférence comme le fait de déduire de nouvelles connaissances par une analyse de l’existant. Dans le cas des ontologies, il s’agit concrètement de découvrir de nouveaux triplets à partir des triplets connus en exploitant la structure de l’ontologie et les contraintes logiques spécifiées. Autrement dit, l’inférence permet de faire apparaître automatiquement des faits implicites que l’œil humain ne peut détecter car ils sont masqués par la complexité de la modélisation. Ce genre de raisonnement peut être effectué au niveau de l’ontologie en elle-même (terminological box ou TBox) ou au niveau des instances de l’ontologie (assertional box ou ABox). Il faut noter que plus le langage de représentation utilisé est expressif, plus l’inférence sera complexe voire impossible à mettre en œuvre. Dans le cas du langage OWL, la complexité de l’inférence est croissante lorsque l’on passe du sous-langage OWL-Lite à OWL-DL et enfin à OWL-Full. Ces mécanismes d’inférence sont implémentés dans des raisonneurs tels que Pellet 16, Fact++ 17 ou encore Hermitt 18. Lorsque la complexité de la modélisation est trop élevée pour ces raisonneurs, il est possible de définir des règles d’inférence manuellement grâce à des langages tels que SWRL 19 ou Jena rules 20 . Ces mécanismes de déduction constituent une réelle plus-value des ontologies car ils permettent, d’une part, de vérifier la qualité des bases de connaissance construites et, d’autre part, d’y ajouter de nouvelles connaissances de façon entièrement automatique. Les systèmes de gestion de base de données classiques (MySQL, Oracle Database, IBM DB2, etc.) ont vu se créer leurs équivalents sémantiques, nommés triplestores, permettant le stockage et le requêtage de triplets RDF. Les grands fournisseurs de SGBD propriétaires adaptent aujourd’hui leurs solutions au Web sémantique et des triplestores opensource sont également disponibles comme Sesame 21, Virtuoso 22 ou encore Fuseki 23. La récupération 16. ❤tt♣✿✴✴❝❧❛r❦♣❛rs✐❛✳❝♦♠✴♣❡❧❧❡t✴ 17. ❤tt♣✿✴✴♦✇❧✳♠❛♥✳❛❝✳✉❦✴❢❛❝t♣❧✉s♣❧✉s✴ 18. ❤tt♣✿✴✴✇✇✇✳❤❡r♠✐t✲r❡❛s♦♥❡r✳❝♦♠✴ 19. Semantic Web Rule Language, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴❙✉❜♠✐ss✐♦♥✴❙❲❘▲✴ 20. ❤tt♣✿✴✴❥❡♥❛✳❛♣❛❝❤❡✳♦r❣✴❞♦❝✉♠❡♥t❛t✐♦♥✴✐♥❢❡r❡♥❝❡✴ 21. openRDF, ❤tt♣✿✴✴✇✇✇✳♦♣❡♥r❞❢✳♦r❣✴ 22. OpenLink, ❤tt♣✿✴✴✈✐rt✉♦s♦✳♦♣❡♥❧✐♥❦s✇✳❝♦♠✴ 23. Apache Jena, ❤tt♣✿✴✴❥❡♥❛✳❛♣❛❝❤❡✳♦r❣✴ 23 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances de ces données sémantiques est réalisée majoritairement grâce au langage SPARQL 24, l’équivalent sé- mantique du langage SQL 25 dont l’usage est recommandé par le W3C pour l’interrogation de bases de connaissances sémantiques. La requête ci-dessous, par exemple, permet de récupérer l’ensemble des entités de type foaf :Person dont le nom de famille commence par la lettre S. PREFIX r d f : < h t t p : / / www. w3 . o r g / 1 9 9 9/ 0 2/ 2 2 − r d f −s y nt a x −n s #> PREFIX f o a f : < h t t p : / / xmlns . com / f o a f / 0 . 1 / > SELECT ? f ? l WHERE { ? p r d f : t y p e f o a f : P e r s o n . ? p f o a f : f i r s t N a m e ? f . ? p f o a f : l a stN am e ? l . FILTER ( r e g e x ( ? l , "^ S " ) ) } 1.2.5 Les éditeurs d’ontologies Bien que l’intérêt pour les ontologies sur le Web soit relativement récent, de nombreux outils ont été développés dans le but de modéliser et de manipuler des ontologies. Le principal atout de ces logiciels est la possibilité de gérer une ontologie dans l’un des formats cités précédemment sans avoir à modifier manuellement le code sous-jacent. Nous présentons ici quelques logiciels distribués librement et gratuitement. Tout d’abord, SWOOP 26 est un éditeur simplifié d’ontologies open-source, développé par l’université du Maryland. Implémenté en Java, cet outil supporte les formats RDF (différentes sérialisations) et OWL. Parallèlement à ses fonctions d’édition, Swoop permet d’effectuer des raisonnements et propose un service de recherche des ontologies existantes. D’autre part, OntoWiki 27 est une application Web conçue comme un wiki permettant de gérer une ontologie de manière simple et collaborative. Cet outil est développé par le groupe de recherche AKSW 28 de l’université de Leipzig, également connu pour leur projet DBPedia. Cet outil supporte plusieurs formats tels que RDF/XML, Notation3, Turtle ou encore Talis(JSON). L’accent est également mis sur l’aspect Linked Data et l’intégration de ressources externes. Des extensions sont disponibles pour par exemple attacher des pages de wiki à des ressources de l’ontologie, visualiser des informations statistiques grâce à CubeViz ou encore intégrer des fonds de carte géographiques. L’outil TopBraid Composer 29 est fourni par la société anglo-saxonne TopQuadrant et s’insrcit dans la suite d’outils professionnels TopBraid Suite. Plusieurs versions de TopBraid Composer sont disponibles dont une édition gratuite Free Edition (FE). Cette application est implémentée en Java grâce à la plateforme Eclipse et exploite les fonctionnalités de la librairie Apache Jena. Elle supporte l’import et 24. SPARQL Protocol and RDF Query Language, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴❚❘✴s♣❛rq❧✶✶✲♦✈❡r✈✐❡✇✴ 25. Structured Query Language 26. ❤tt♣✿✴✴❝♦❞❡✳❣♦♦❣❧❡✳❝♦♠✴♣✴s✇♦♦♣✴ 27. ❤tt♣✿✴✴♦♥t♦✇✐❦✐✳♥❡t✴Pr♦❥❡❝ts✴❖♥t♦❲✐❦✐ 28. Agile Knowledge engineering and Semantic Web 29. ❤tt♣✿✴✴✇✇✇✳t♦♣q✉❛❞r❛♥t✳❝♦♠✴♣r♦❞✉❝ts✴❚❇❴❈♦♠♣♦s❡r✳❤t♠❧ 24 Copyright c 2013 - CASSIDIAN - All rights reserved1.3. Modélisation des événements l’export de fichiers en langage RDF(S), OWL et OWL2 et son système de built-ins ouvre de nombreuses autres fonctionnalités telles que l’utilisation de divers moteurs d’inférence, le requêtage en SPARQL, le développement de règles d’inférence en SWRL, les vérification d’intégrité et gestion des exceptions. L’application Apollo 30 est développée par le Knowledge Media Institute (KMI). Cet outil implémentée en Java fournit les fonctions basiques de création d’ontologie et présente une bonne flexibilité grâce à son système de plug-ins. Toutefois, Apollo ne permet pas de mécanismes d’inférence et est fondé sur son propre métalangage ce qui ne facilite pas l’interopérabilité avec d’autres outils. NeOn Toolkit 31 est un autre environnement open-source très complet d’ingénierie des ontologies issu du projet européen NeOn. Cet outil est particulièrement adapté à la gestion d’ontologies multi-modulaires ou multilingues, à la fusion d’ontologies et à leur intégration dans des applications sémantiques plus larges. L’accent y est mis sur la contextualisation et la mise en réseau de modélisations hétérogènes et sur les aspects collaboratifs de la gestion d’ontologies. Fondé sur l’environnement de développement Eclipse, NeOn Toolkit propose l’intégration de divers plugins pour la modélisation visuelle, l’apprentissage et l’alignement d’ontologie, la définition de règles d’inférence, etc. Son architecture ouverte et modulaire est compatible avec les architectures orientées services (SOA) [Haase et al., 2008]. Terminons par l’éditeur d’ontologies le plus renommé et le plus utilisé dans la communauté d’ingé- nierie des connaissances : l’environnement Protégé 32. Créé par les chercheurs de l’université de Stanford, Protégé est développé en Java, gratuit et open-source. Il s’agit d’une plateforme d’aide à la création, la visualisation et la manipulation d’ontologies dans divers formats de représentation (RDF, RDFS, OWL, etc.). Ce logiciel peut également être utilisé en combinaison avec divers moteurs d’inférence (tels que RacerPro ou Fact) afin d’effectuer des raisonnements et d’obtenir de nouvelles assertions. De plus, de par la flexibilité de son architecture, Protégé est facilement configurable et extensible par les plugins dé- veloppés au sein d’autres projets. La figure 1.2 présente une vue de l’ontologie-exemple pizza.owl dans l’environnement Protégé. Enfin, les créateurs de cet outil mettent l’accent sur l’aspect collaboratif dans la modélisation d’ontologies en proposant Collaborative Protégé et WebProtégé. Le premier est une extension intégrée à Protégé permettant à plusieurs utilisateurs d’éditer la même ontologie et de commenter les modifications effectuées par chacun. Un système de vote rend également possible la concertation sur tel ou tel changement. WebProtégé est une application Web légère et open-source reprenant les principes de Collaborative Protégé dans le contexte du Web. Elle permet une édition d’ontologies collaborative et à distance. Pour une description plus détaillée et une comparaison plus poussée de ces éditeurs, nous renvoyons le lecteur aux présentations faites par [Alatrish, 2012] et [Charlet et al., 2004]. 1.3 Modélisation des événements Le concept d’événement étant au centre de nos travaux, les sections suivantes visent à définir plus précisément cette notion complexe. Nous nous intéressons aux différentes visions de l’événement dans la littérature et plus particulièrement dans les domaines de l’extraction d’information et du Web sémantique. Nous résumons les grands courants de représentation des événements dans le but de les extraire 30. ❤tt♣✿✴✴❛♣♦❧❧♦✳♦♣❡♥✳❛❝✳✉❦✴ 31. ❤tt♣✿✴✴♥❡♦♥✲t♦♦❧❦✐t✳♦r❣ 32. ❤tt♣✿✴✴♣r♦t❡❣❡✳st❛♥❢♦r❞✳❡❞✉✴ 25 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances FIGURE 1.2 – L’environnement Protégé automatiquement. Puis, nous réalisons un état des lieux des ontologies existantes centrées sur la modé- lisation des événements. Enfin, un focus est proposé sur les questions de représentation du temps et de l’espace qui sont des aspects importants dans le traitement des événements. 1.3.1 Qu’est-ce qu’un événement ? Considéré comme une entité aux propriétés bien spécifiques, l’événement a initialement été étudié par des philosophes [Davidson, 1967] puis par des linguistes [Van De Velde, 2006] [Desclés, 1990] (voir [Casati and Varzi, 1997] pour une bibliographie exhaustive). [Higginbotham et al., 2000] compare quelques définitions de l’événement et met notamment l’accent sur deux courants traditionnels opposés : les événements comme concepts universaux (généraux et répé- tables) d’une part, et particuliers (spécifiques et uniques), d’autre part. Dans le premier courant, on peut citer [Montague, 1969] pour lequel les événements sont des propriétés attribuées à des instants (ou des intervalles) dans le temps, ou encore [Chisholm, 1970] qui les définit comme des situations ("states of affairs") pouvant décrire le même intervalle de temps de façon différente. Par ailleurs, [Quine, 1960] et [Kim, 1973] appartiennent au second courant : les événements sont définis comme des objets particuliers ("individuals"). Le premier considère que les événements ont le même statut que les objets physiques et portent le contenu (parfois hétérogène) d’une portion de l’espace-temps. Il n’y a donc qu’un seul et même événement possible par région spatio-temporelle mais ce même événement peut donner lieu à différentes descriptions linguistiques. [Kim, 1973] se place à l’opposé de cette vision en permettant à un nombre 26 Copyright c 2013 - CASSIDIAN - All rights reserved1.3. Modélisation des événements indéfini d’événements d’occuper un seul et même moment. L’événement est ici un objet concret (ou une collection d’objets) exemplifiant une propriété (ou un ensemble de propriétés) à un moment donné. Enfin, une position intermédiaire est celle de [Davidson, 1969] qui considère les événements selon leur place dans un réseau de causalité : des événements sont identiques s’ils partagent les mêmes causes et les mêmes effets. Cependant, ce même auteur reviendra plus tard vers la thèse de Quine. Suite à ces réflexions sur la nature des événements (qui est encore débattue à l’heure actuelle), d’autres recherches ont vu le jour en linguistique, analyse du discours et philosophie du langage. En effet, les événements étant avant tout des objets sociaux, leur étude doit se faire entre étroite corrélation avec la manière dont ils sont relatés et exprimés par l’homme. Parmi ces travaux nous pouvons citer [Krieg-Planque, 2009]. Celle-ci donne une définition simple de l’événement mais qui nous paraît très juste : "un événement est une occurrence perçue comme signifiante dans un certain cadre". Ici, le terme "occurrence" met l’accent sur la notion de temporalité qui est reconnue comme partie intégrante de ce concept par la quasi totalité des travaux. Le "cadre" selon Krieg-Planque réfère à "un système d’attentes donné" qui "détermine le fait que l’occurrence acquiert (ou non) [...] sa remarquabilité [...] et, par conséquent, est promue (ou non) au rang d’événement.". C’est ici qu’est fait le lien avec la sociologie et l’histoire : tout événement prend place dans un milieu social qui détermine l’obtention de son statut "remarquable". Enfin, [Neveu and Quéré, 1996] s’attachent à décrire plus précisément l’apparition des événements dits "modernes", façonnés et relayés par les médias actuels. Ils soulignent que l’interprétation d’un évé- nement est étroitement liée au contenu sémantique des termes utilisés pour nommer cet événement. Pour plus de clarté nous appellerons ces termes des "noms d’événement". Ces "noms d’événement" transposent en langage naturel la "propriété sémantique" des événements mentionnée par [Saval, 2011]. Cette description de l’événement est également au centre d’un phénomène plus large, que [Ricœur, 1983] nomme "mise en intrigue" : celui-ci vise à organiser, selon le cadre mentionné plus haut, un ensemble d’éléments circonstants ou participants de l’événement. 1.3.1.1 Les événements en extraction d’information On distingue actuellement deux grandes visions de l’événement dans la communauté de l’extraction d’information [Ahn, 2006]. D’une part, l’approche TimeML provient de recherches menées en 2002 dans le cadre du programme AQUAINT 33 fondé par l’ARPA 34. D’autre part, le modèle ACE a été défini dans la tâche Event Detection and Recognition (VDR) des campagnes d’évaluation du même nom à partir de 2005. L’approche TimeML [Pustejovsky et al., 2003] définit les événements de la façon suivante : "situations that happen or occur [...] predicates describing states or circumstances in which something obtains or holds true". Ceux-ci peuvent être ponctuels ou duratifs et sont organisés en sept types : Occurrence, State, Reporting, I-Action, I-State, Aspectual, Perception. L’événement est considéré conjointement à trois autres types d’entité : TIMEX, SIGNAL et LINK. Les objets TIMEX correspondent aux entités temporelles simples telles que les expressions de dates et heures, durée, fréquence, etc. (annotées par des étiquettes TIMEX3 36). Les entités SIGNAL correspondent à des mots fonctionnels exprimant des rela- 33. Advanced Question Answering for Intelligence, ❤tt♣✿✴✴✇✇✇✲♥❧♣✐r✳♥✐st✳❣♦✈✴♣r♦❥❡❝ts✴❛q✉❛✐♥t✴ 34. ancien nom de la DARPA, Defense Advanced Research Projects Agency, 35 36. ❤tt♣✿✴✴t✐♠❡♠❧✳♦r❣✴s✐t❡✴t✐♠❡❜❛♥❦✴❞♦❝✉♠❡♥t❛t✐♦♥✲✶✳✷✳❤t♠❧ 27 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances tions temporelles. Il peut s’agir de prépositions de temps (pendant, après, etc.), de connecteurs temporels (quand, lorsque, etc.), de mots subordonnants (si, etc.), d’indicateurs de polarité (négation) ou encore de quantifieurs (dix fois, souvent, etc.). Enfin, les annotations LINK font le lien entre les différentes entités temporelles (EVENT, TIMEX et SIGNAL). Ces liens sont de trois types : TLINK (liens temporels entre événements ou entre un événement et une autre entité de type TIMEX), SLINK (liens de subordination entre deux événements ou entre un événement et une entité SIGNAL), ALINK (liens aspectuels entre un événement aspectuel et son argument). Dans le modèle ACE [NIST, 2005] un événement est vu comme une structure complexe impliquant plusieurs arguments pouvant également être complexes. L’aspect temporel correspond ici à un type d’argument mais n’est pas au centre de la modélisation. Ce modèle définit un ensemble de types et sous-types d’événement (8 types comme Life, Movement, Business, etc. et 33 sous-types comme Marry, DeclareBankruptcy, Convict, Attack, etc.) et associe à chaque événement un ensemble d’arguments autorisés pouvant être des entités ou des valeurs et auxquels est associé un rôle (parmi 35 rôles dont Time, Place, Agent, Instrument, etc. [LDC, 2005]). Par ailleurs, les événements tels que définis dans la campagne ACE possèdent des attributs tels que le temps, la modalité, la polarité ou encore la généricité. Enfin, comme pour les autres types d’entité, on distingue la notion de mention d’événement, d’une part, qui correspond à une portion de texte constituée d’une ancre d’événement et de ses arguments et, d’autre part, l’événement en lui-même, c’est-à-dire un ensemble de mentions d’événement qui réfère au même objet du monde réel. Ces deux modèles sont différents sur plusieurs aspects, la divergence principale étant que la première approche vise à annoter tous les évènements d’un texte, alors que la seconde a pour cibles uniquement les événements d’intérêt pour une application donnée. Le modèle TimeML, considérant un événement comme tout terme temporellement ancré, est généralement choisi dans des projets où cet aspect est central (pour la construction de chronologies par exemple). L’approche ACE est la plus utilisée car elle s’applique aux besoins de divers domaines mais implique toutefois un processus d’annotation plus complexe à mettre en place (la représentation de l’événement étant elle-même plus complexe). 1.3.1.2 Les ontologies orientées "événement" Plusieurs ontologies disponibles sur le Web proposent une modélisation spécifique au concept d’évé- nement. Nous présentons ci-après les caractéristiques principales de cinq d’entre elles : – The Event Ontology (EO) 37 – Linking Open Descriptions of Events (LODE) 38 – Simple Event Model (SEM) 39 – DOLCE-UltraLite (DUL) 40 – CIDOC Conceptual Reference Model (CIDOC CRM) 41 The Event Ontology a été développée par les chercheurs Yves Raimond et Samer Abdallah du Centre for Digital Music à Londres [Raimond et al., 2007] et sa dernière version date d’octobre 2007. Cette 37. ❤tt♣✿✴✴♠♦t♦♦❧s✳s♦✉r❝❡❢♦r❣❡✳♥❡t✴❡✈❡♥t✴❡✈❡♥t✳❤t♠❧ 38. ❤tt♣✿✴✴❧✐♥❦❡❞❡✈❡♥ts✳♦r❣✴♦♥t♦❧♦❣② 39. ❤tt♣✿✴✴s❡♠❛♥t✐❝✇❡❜✳❝s✳✈✉✳♥❧✴✷✵✵✾✴✶✶✴s❡♠✴ 40. ❤tt♣✿✴✴♦♥t♦❧♦❣②❞❡s✐❣♥♣❛tt❡r♥s✳♦r❣✴♦♥t✴❞✉❧✴❉❯▲✳♦✇❧ 41. ❝✐❞♦❝✲❝r♠✳♦r❣✴ 28 Copyright c 2013 - CASSIDIAN - All rights reserved1.3. Modélisation des événements ontologie est centrée sur la notion d’événement telle que [Allen and Ferguson, 1994] la définissent : "[...] events are primarily linguistic or cognitive in nature. That is, the world does not really contain events. Rather, events are the way by which agents classify certain useful and relevant patterns of change.". Cette ontologie des événements à été développée dans le cadre du projet Music Ontology et est donc particulièrement adaptée à la représentation des événements dans ce domaine (concerts, représentations, etc.). Comme le montre la figure 1.3, cette modélisation se veut générique et s’appuie sur des ontologies largement utilisées telles que FOAF, ainsi que sur des standards de représentation spatio-temporelle recommandés par le W3C42. Toutefois, la classe Event n’est pas sous-typée et les propriétés factor et product paraissent vaguement définies (pas de co-domaine). FIGURE 1.3 – L’ontologie Event : modélisation des événements L’ontologie LODE [Troncy et al., 2010] a été créée dans le cadre du projet européen EventMedia 43 [Fialho et al., 2010]. Ce projet vise à concevoir un environnement Web permettant aux internautes d’explorer, de sélectionner et de partager des événements. L’ontologie est au centre de cette initiative car elle constitue le socle commun pour représenter et stocker des événements provenant de sources hétérogènes. Les concepteurs de cette ontologie la présente comme un modèle minimal dont l’objectif premier est, dans la mouvance du LOD (Linked Open Data), de créer des liens entre les ontologies existantes afin de représenter les aspects faisant consensus dans la communauté de représentation des événements. Pour ce faire, un certain nombre d’alignements entre ontologies est implémenté dans LODE tels que des équivalences de classes et propriétés avec les ontologies DUL, EO, CIDOC CRM, etc. Cette interopérabilité permet notamment d’obtenir des connaissances supplémentaires lors des mécanismes d’inférence. Cette ontologie n’est donc pas réellement une ontologie des événements mais plutôt un outil d’alignement des modélisations existantes. Enfin, les concepteurs ont exclu pour le moment tout travail sur la sous-catégorisation des événements et la définition de relations entre événements (inclusion, causalité, etc.). Les figures 1.4 et 1.5 schématisent respectivement les relations entre concepts et les relations entre propriétés dans LODE. 42. ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴✷✵✵✻✴t✐♠❡★ et ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴✷✵✵✸✴✵✶✴❣❡♦✴✇❣s✽✹❴♣♦s★ 43. ❤tt♣✿✴✴❡✈❡♥t♠❡❞✐❛✳❝✇✐✳♥❧✴ 29 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances FIGURE 1.4 – LODE : modélisation des événements FIGURE 1.5 – LODE : alignements entre propriétés L’ontologie SEM a été créée par le groupe Web & Media de l’université d’Amsterdam [van Hage et al., 2011]. Elle décrit les événements dans le but de répondre à la question "who did what with what to whom, where and when ?" mais aussi dans une perspective d’interopérabilité entre différents domaines. Une particularité de SEM est l’accent mis sur la représentation des rôles associés aux acteurs impliqués dans un événement. SEM permet de modéliser la nature du rôle, des informations temporelles sur sa validité mais également la source l’ayant attribué à l’acteur. Dans le même objectif que LODE, SEM fournit de nombreux liens (sous la forme de propriétés SKOS 44) avec une dizaine d’ontologies existantes : ontologies dédiées aux événements (EO, LODE, etc.), standards W3C (Time, WGS84), ontologies de haut niveau reconnues (SUMO, OpenCyc, etc.), etc. Toutefois, les événements dans cette ontologie ne sont pas sous-typés et, mise à part la propriété hasSubEvent, aucune autre relation entre événements n’est mo- 44. Simple Knowledge Organization System, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴✷✵✵✹✴✵✷✴s❦♦s✴ 30 Copyright c 2013 - CASSIDIAN - All rights reserved1.3. Modélisation des événements délisée. La figure 1.6, fournie par les développeurs de l’ontologie, schématise les concepts et relations principaux dans SEM. FIGURE 1.6 – SEM : modélisation des événements DUL (DOLCE+DnS-UltraLite) est une ontologie développée par le laboratoire italien STLab 45 à la suite de DOLCE 46, une ontologie de haut niveau créée dans le cadre du projet WonderWeb 47. Un événement y est défini comme suit : "Any physical, social, or mental process, event, or state.". Plus concrètement, la classe Event est spécifiée en deux sous-classes Action et Process, la première se diffé- renciant de la seconde par la propriété executesTask indiquant l’objectif de l’action. Comme le montre la figure 1.7, cette ontologie de haut niveau ne comporte pas de liens vers d’autres modélisations et notamment la représentation spatio-temporelle des événements y reste peu définie. Pour finir, le modèle CIDOC CRM est un standard international ISO pour le partage d’information dans le domaine du patrimoine culturel. Celui-ci est développé depuis 1994 et distribué au format OWL par les chercheurs de l’Université d’Erlangen-Nuremberg en Allemagne 48. L’événement est une sousclasse de TemporalEntity et y est défini comme un changement d’état : "changes of states in cultural, social or physical systems, regardless of scale, brought about by a series or group of coherent physical, cultural, technological or legal phenomena.". La figure 1.8 présente une vue globale de l’organisation des différents concepts de cette ontologie avec un focus sur la classe Event. Les différentes propriétés de l’événement sont schématisées dans la figure 1.9. Les remarques faites sur DUL (absence de liens vers d’autres ontologies et représentation spatio-temporelle peu définie) s’appliquent également à cette ontologie. Par ailleurs, la distinction entre les concepts Event, Period et Condition State n’est pas clairement 45. Semantic Technology laboratory 46. Descriptive Ontology for Linguistic and Cognitive Engineering 47. ❤tt♣✿✴✴✇♦♥❞❡r✇❡❜✳s❡♠❛♥t✐❝✇❡❜✳♦r❣✴ 48. ❤tt♣✿✴✴❡r❧❛♥❣❡♥✲❝r♠✳♦r❣ 31 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances FIGURE 1.7 – DUL : modélisation des événements définie. Enfin, bien que CIDOC CRM se veuille générique et définisse de nombreuses sous-classes de l’événement, cette taxonomie ne paraît pas s’appliquer à tous les domaines. FIGURE 1.8 – CIDOC CRM : taxonomie des classes 32 Copyright c 2013 - CASSIDIAN - All rights reserved1.3. Modélisation des événements FIGURE 1.9 – CIDOC CRM : modélisation des événements 1.3.2 Modélisation du temps et de l’espace Comme l’ont montré les sections précédentes, la définition des événements est indissociable des notions de temps et d’espace. Bien que ces concepts soient intuitivement compréhensibles par tous, leur modélisation en vue de traitements automatisés n’est pas chose aisée. En effet, le temps et l’espace peuvent revêtir différentes dimensions sociologiques et physiques donnant lieu à diverses représentations. Nous proposons ci-après un résumé des grands courants théoriques de représentation temporelle et spatiale ainsi que quelques exemples d’ontologies associées. 1.3.2.1 Représentation du temps On distingue classiquement deux types de représentation temporelle : d’une part, une vue sous forme de points/instants et, d’autre part, un découpage du continuum temporel en intervalles/périodes. Les travaux les plus connus sont ceux de [McDermott, 1982] pour la représentation en points et ceux de [Allen, 1983] pour les intervalles. Le premier considère l’espace temps comme une succession de points et définit les relations suivantes entre deux points ti et tj : (ti < tj ) ∨ (ti > tj ) ∨ (ti = tj ) Allen définit l’unité temporelle de base comme étant un intervalle de temps et propose une algèbre composée de 13 relations (voir la figure 1.10). Ces deux modèles temporels sont les plus utilisés mais d’autre types ont été proposés pour, par exemple, hybrider ces deux approches. De nombreuses recherches sont menées également dans diverses disciplines (philosophie, informatique théorique, bases de données, etc.) sur d’autres problématiques liées au temps telles que les logiques et les contraintes temporelles, le raisonnement sur le temps, etc. [Allen, 1991] [Hayes, 1995] Parmi ces travaux, [Ladkin, 1987] propose un système de représentation du temps faisant le lien entre les nombreux modèles théoriques développés et les besoins applicatifs de traitement du temps. Il s’agit 33 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances FIGURE 1.10 – Algèbre temporel d’Allen du Time Unit System (TUS), une approche hiérarchique et granulaire qui représente toute expression temporelle en un groupe de granules (c’est-à-dire des unités temporelles indivisibles). Un granule (ou unité de temps) est une séquence finie d’entiers organisés selon une hiérarchie linéaire : année, mois, jour, heure, etc. De plus, ce formalisme introduit la notion de BTU (Basic Time Unit) qui correspond au niveau de granularité choisi en fonction de la précision nécessitée par une application (e.g. les jours, les secondes, etc.). Par exemple, si le BTU est fixé à heure, chaque unité temporelle sera exprimée comme une séquence d’entiers i telle que : i = [année,mois,jour,heure]. De plus, TUS définit la fonction maxj ([a1, a2, ..., aj−1]) donnant la valeur maximale possible à la position j pour qu’une séquence temporelle soit valide en tant que date. Cet opérateur est nécessaire car, selon notre actuel système calendaire, le granule jour dépend des granules mois et année. Depuis les débuts du Web sémantique, les chercheurs se sont intéressés à l’application des modèles théoriques existants pour la construction d’ontologies temporelles. L’ontologie OWL Time 49, issue d’un groupe de travail du W3C, est la plus connue et la plus utilisée actuellement. Celle-ci définit un concept de base TemporalEntity, spécifié en instants et intervalles. On y trouve également les relations temporelles issues de l’algèbre d’Allen ainsi qu’un découpage calendaire du temps (année, mois, jour, heure, minute et seconde). 1.3.2.2 Représentation de l’espace Du côté de la représentation spatiale, les premières approches proviennent des mathématiques : d’une part, Euclide définit plusieurs catégories d’objets géométriques de base (points, lignes, surfaces, etc.) ainsi que leurs propriétés et relations ; d’autre part, Descartes considère le point comme élément fondamental et propose un modèle numérique de représentation géographique en associant à chaque point un ensemble de valeurs pour chacune de ses dimensions (coordonnées cartésiennes). Ces deux modélisations constituent la vision classique de l’espace en termes de points. 49. ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴❚❘✴♦✇❧✲t✐♠❡✴ 34 Copyright c 2013 - CASSIDIAN - All rights reserved1.3. Modélisation des événements Plus récemment, se développe une vision alternative où l’unité de base de modélisation spatiale est la région. Introduite par [Whitehead, 1920], celle-ci se fonde sur une perception plus commune de l’espace et est également désignée sous le nom de "géométrie du monde sensible". Cette représentation dite aussi qualitative (en contraste avec les premières approches quantitatives) permet de décrire toute entité spatiale selon les trois concepts suivants : intérieur, frontière et extérieur. Ce principe est à l’origine de l’analyse topologique visant à décrire les relations spatiales selon cette notion de limite. Cette proposition de Whitehead a donné lieu à l’élaboration de diverses théories de l’espace fondées sur les régions dont [Tarski, 1956]. Ce mode de représentation a été celui adopté par la communauté de l’Intelligence Artificielle parce qu’étant plus proche de la vision humaine et donc plus applicatif. Le modèle RCC-8 de [Randell et al., 1992] est le formalisme de premier ordre le plus utilisé pour modéliser et raisonner sur des entités spatiales. Il s’agit d’une transposition de l’algèbre d’Allen au problème de la représentation spatiale. Ce modèle comprend huit types de relation entre deux régions spatiales schématisés par la figure 1.11. FIGURE 1.11 – Les relations topologiques RCC-8 Du côté du Web sémantique, [Minard, 2008] propose un état de l’art de quelques ontologies d’objets géographiques développées notamment par des laboratoires spécialisés tels que l’INSEE, l’IGN ou AGROVOC. S’ajoutent à ces ontologies de nombreux thésaurus et bases de connaissances géographiques telles que la plus renommée GeoNames 50. Il nous faut mentionner également le groupe de travail W3C Geospatial Incubator Group (GeoXG) 51 et le consortium international OGC52 qui collaborent depuis quelques années pour faciliter l’interopérabilité entre les systèmes d’information géographique (SIG) dans le cadre du Web sémantique. Plusieurs initiatives en découlent dont le vocabulaire WGS84 Geo Positioning 53, le langage de balisage GML 54 ou encore le langage de requête GeoSPARQL 55 . 1.3.3 Spécifications dédiées au ROSO Nous proposons ici un tour d’horizon des modélisations réalisées et exploitées dans le domaine militaire et de la sécurité au sens large. 50. ❤tt♣✿✴✴✇✇✇✳❣❡♦♥❛♠❡s✳♦r❣ 51. ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴✷✵✵✺✴■♥❝✉❜❛t♦r✴❣❡♦✴❳●❘✲❣❡♦✲♦♥t✲✷✵✵✼✶✵✷✸✴ 52. Open Geospatial Consortium, ❤tt♣✿✴✴✇✇✇✳♦♣❡♥❣❡♦s♣❛t✐❛❧✳♦r❣✴ 53. ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴✷✵✵✸✴✵✶✴❣❡♦✴✇❣s✽✹❴♣♦s★ 54. Geography Markup Language, ❤tt♣✿✴✴✇✇✇✳♦♣❡♥❣❡♦s♣❛t✐❛❧✳♦r❣✴st❛♥❞❛r❞s✴❣♠❧ 55. ❤tt♣✿✴✴❣❡♦s♣❛rq❧✳♦r❣✴ 35 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances Une première catégorie de ressources existantes sont les standards OTAN 56 dits STANAGs 57. Ceuxci sont des accords de normalisation ratifiés par les pays de l’Alliance pour faciliter les interactions entre leurs armées. Ces documents définissent des procédures, termes et conditions formant un référentiel commun (technique, opérationnel ou administratif) dédié à être mis en œuvre au sein des différents services militaires de l’OTAN. Certains sont spécifiques aux systèmes d’information et de communication (SIC) tels que les NATO Military Intelligence Data Exchange Standard [NATO, 2001] et Joint Consultation Command Control Information Exchange Data Model [NATO, 2007]. Le premier, également nommé STANAG 2433 ou AINTP-3(A), a pour objectif l’échange de l’information et de l’intelligence au sein de l’Alliance et la proposition d’un ensemble de standards d’implémentation. Les structures de données qui y sont définies constituent un exemple pour les pays membres qui, pour la plupart, s’en sont inspirés dans la conception de leurs bases de données. Le second accord, dit STANAG 5525 ou JC3IEDM, sert d’interface commune pour l’échange d’informations sur le champ de bataille. Il vise une interopérabilité internationale entre les systèmes d’information de type C2 (Command and Control) pour faciliter le commandement des opérations interarmées. Ces standards militaires ne sont pas des ontologies mais définissent un ensemble de concepts (et relations entre ces concepts) spécifiques à certaines procédures. Ceux-ci sont organisés de façon hiérarchique et décrits le plus précisément possible en langage naturel. Ces modèles sont généralement très complets et très bien documentés car ils sont destinés à des opérateurs humains spécialistes du sujet traité. Par ailleurs, nous pouvons citer l’agence de recherche américaine IARPA 58 et son programme OSI 59 dont l’objectif est le développement de méthodes pour l’analyse des données accessibles publiquement. Cette organisation finance des projets d’innovation technologique pour la détection automatique et l’anticipation d’événements sociétaux tels que les situations de crise, catastrophes naturelles, etc. Dans le cadre de ce programme a été développée la typologie IDEA 60 incluant environ 250 types d’événements sociaux, économiques et politiques ainsi que des entités simples avec lesquelles ils sont en relation [Bond et al., 2003]. Du côté des ontologies, on recense notamment les modélisations swint-terrorism [Mannes and Golbeck, 2005], reprenant les concepts principaux nécessaires au domaine du terrorisme, et AKTiveSA [Smart et al., 2007], dédiée à la description des contextes opérationnels militaires autres que la guerre. [Baumgartner and Retschitzegger, 2006] réalise également un état de l’art des ontologies de haut niveau dédiées à la tenue de situation (situation awareness). [Inyaem et al., 2010b] s’attache à la définition d’une ontologie floue pour l’extraction automatique d’événements terroristes. Toutefois, comme dans beaucoup de travaux de ce domaine, l’ontologie développée n’est pas distribuée publiquement pour des raisons stratégiques et/ou de confidentialité. Le site web ❤tt♣✿✴✴♠✐❧✐t❛r②♦♥t♦❧♦❣②✳❝♦♠ recense un certain nombre d’ontologies pour le domaine militaire. Enfin, [Bowman et al., 2001] et [Boury-Brisset, 2003] proposent un ensemble de conseils méthodologiques pour la construction d’ontologies dédiées aux applications militaires et stratégiques. 56. Organisation du Traité de l’Atlantique Nord 57. STANdardization AGreement, ❤tt♣✿✴✴✇✇✇✳♥❛t♦✳✐♥t✴❝♣s✴❡♥✴♥❛t♦❧✐✈❡✴st❛♥❛❣✳❤t♠ 58. Intelligence Advanced Research Projects Activity, ❤tt♣✿✴✴✇✇✇✳✐❛r♣❛✳❣♦✈✴ 59. Open Source Indicators, ❤tt♣✿✴✴✇✇✇✳✐❛r♣❛✳❣♦✈✴Pr♦❣r❛♠s✴✐❛✴❖❙■✴♦s✐✳❤t♠❧ 60. Integrated Data for Events Analysis, ❤tt♣✿✴✴✈r❛♥❡t✳❝♦♠✴■❉❊❆✳❛s♣① 36 Copyright c 2013 - CASSIDIAN - All rights reserved1.4. Conclusions 1.4 Conclusions A travers ce premier état de l’art, nous avons pu nous familiariser avec les différentes problématiques de la représentation des connaissances au sens large. Nous avons, dans un premier temps, rappelé une distinction importante antre les notions de donnée, information et connaissance qui constitue l’une de bases théoriques de ce domaine. Nous avons, par la suite, présenté, dans leur ensemble, les principes et technologies du Web sémantique qui sont partie intégrante d’une majorité de travaux actuels en fouille de documents et dont l’adéquation à cette problématique n’est plus à prouver. Enfin, nous avons réalisé un focus sur la place des événements en représentation des connaissances et présenté les différentes théories et modèles de la littérature. Dans un souci d’interopérabilité avec les systèmes existants, nous avons privilégié l’utilisation de modèles communs au sein de nos travaux tout en les adaptant aux besoins spécifiques de notre application si nécessaire. Le modèle ACE, très utilisé par la communauté en EI, nous parait bien adapté à la modélisation des événements dans le cadre de nos recherches. En effet, comme nous l’avons montré dans ce chapitre, celui-ci est compatible avec les besoins des analystes du ROSO ainsi qu’avec le modèle de données de la plateforme WebLab. Nous avons par la suite réalisé un tour d’horizon des ontologies centrées sur les événements déjà développées et réutilisables : les plus communes présentent toutes des similarités de structure et un effort est réalisé dans la communauté pour lier les différentes modélisations entre elles via des alignements ontologiques. Parmi celles-ci, les ontologies DUL et LODE présentent le plus de correspondances avec nos travaux. L’ensemble de ces observations seront prises en compte lors de l’élaboration de notre modèle de connaissances présentée au chapitre 4. 37 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 1. Représentation des connaissances 38 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2 Extraction automatique d’information Sommaire 2.1 Définition et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.2 Approches d’extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.2.1 Extraction d’entités nommées et résolution de coréférence . . . . . . . . . 43 2.2.2 Extraction de relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.2.3 Extraction d’événements . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3 Plateformes et logiciels pour l’EI . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.4 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.5 Évaluation des systèmes d’EI . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.5.1 Campagnes et projets d’évaluation . . . . . . . . . . . . . . . . . . . . . 54 2.5.2 Performances, atouts et faiblesses des méthodes existantes . . . . . . . . . 56 2.6 Problèmes ouverts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 39 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information Depuis les débuts du Traitement Automatique du Langage dans les années 60-70, la compréhension automatique de textes est l’objet de nombreuses recherches. L’objectif principal est de permettre à un ordinateur de comprendre le sens global d’un document comme savent le faire les êtres humains. Les échecs récurrents des systèmes alors développés mettent rapidement en cause une vision trop générique de la compréhension automatique. En effet, de tels outils s’avèrent alors inutilisables dans un contexte opérationnel en raison du coût élevé des adaptations nécessaires (bases de connaissances et ressources lexicales spécifiques). Conscients d’être trop ambitieux au regard des possibilités technologiques, les chercheurs s’orientent alors vers des techniques plus réalistes d’extraction d’information. S’il n’est pas directement possible de comprendre automatiquement un texte, le repérage et l’extraction des principaux éléments de sens apparaît comme un objectif plus raisonnable. Cette réorientation théorique est reprise de façon détaillée par [Poibeau, 2003]. Ce chapitre présente tout d’abord les objectifs principaux de l’extraction d’information (section 2.1), puis une synthèse des méthodes les plus couramment mises en œuvre dans ce domaine (section 2.2). Pour cela, nous distinguons les travaux existants selon la nature des informations extraites : entités nommées, relations entre entités et événements. Quelques travaux en résolution de coréférence sont également présentés. La section 2.3 propose un tour d’horizon des outils et plateformes existants pour le développement de systèmes d’extraction d’information. Nous parcourons ensuite (section 2.4) quelques-unes des applications possibles dans ce domaine. Pour conclure ce chapitre, la section 2.5 aborde le problème de l’évaluation en extraction d’information à travers une revue des campagnes d’évaluation, puis une présentation des performances (atouts et faiblesses) des systèmes existants et enfin, un récapitulatif des limites restantes à l’heure actuelle. 2.1 Définition et objectifs Face à l’augmentation vertigineuse des documents textuels mis à disposition de tous, l’extraction automatique d’information voit un intérêt grandissant depuis une vingtaine d’années. En effet, noyés sous cette masse d’information non-structurée, nous rêvons d’un système automatique capable, dans nos tâches quotidiennes (professionnelles ou personnelles), de repérer et d’extraire de façon rapide et efficace les informations dont nous avons besoin. En réponse à cela, les systèmes développés visent à analyser un texte de manière automatique afin d’en extraire un ensemble d’informations jugées pertinentes [Hobbs and Riloff, 2010]. Il s’agit généralement de construire une représentation structurée (bases de données, fiches, tableaux) à partir d’un ou plusieurs documents à l’origine non-structurés. Cela en fait une approche guidée par le but de l’application dans laquelle elle s’intègre, dépendance qui reste, à l’heure actuelle, une limite majeure des systèmes d’extraction [Poibeau, 2003]. L’extraction d’information (EI) a souvent été confondue avec un autre domaine de l’intelligence artificielle (IA) qu’est la recherche d’information (RI). Bien que cet amalgame s’explique car ces deux champs de recherche partagent un objectif premier — présenter à l’utilisateur des informations qui ré- pondent à son besoin — ceux-ci diffèrent sur plusieurs autres points. Tout d’abord, les outils de RI renvoient généralement une liste de documents à l’utilisateur alors qu’en extraction d’information les résultats sont des éléments d’information extraits de ces documents. Par ailleurs, la recherche d’information s’attache à répondre à une requête exprimée par un utilisateur grâce à un système de mots-clés (ou d’autres mécanismes plus sophistiqués de recherche sémantique) [Vlahovic, 2011]. Dans le domaine de l’EI, la réponse des outils est guidée par une définition a priori des éléments d’information à repérer 40 Copyright c 2013 - CASSIDIAN - All rights reserved2.1. Définition et objectifs dans un ensemble de textes. Malgré ces distinctions et comme c’est le cas avec d’autres disciplines du TALN 61, l’EI est utile à la RI et inversement. Les systèmes d’extraction d’information bénéficient souvent de la capacité de filtrage des outils de RI en focalisant leur analyse sur un ensemble déterminé de documents. A l’inverse, la recherche d’information peut exploiter les informations extraites par les outils d’EI en tant que champs de recherche additionnels et ainsi améliorer le filtrage et l’ordonnancement des documents pour une requête donnée. Les tâches les plus communes en extraction d’information sont l’extraction d’entités nommées [Nadeau and Sekine, 2007], le repérage de relations entre ces entités [Rosario and Hearst, 2005] et la dé- tection d’événements [Naughton et al., 2006]. Celles-ci se distinguent par la nature et la complexité des informations que l’on cherche à repérer et à extraire automatiquement : entités nommées, relations ou événements. Nous détaillons ci-après les objets d’étude et les objectifs spécifiques à chaque tâche. La reconnaissance d’entités nommées (REN) vise à reconnaître et catégoriser automatiquement un ensemble d’éléments d’information qui correspondent généralement à des noms propres (noms de personnes, organisations, lieux) mais aussi aux dates, unités monétaires, pourcentages, unités de mesure, etc. Ces objets sont communément appelés "entités nommées" et s’avèrent indispensables pour saisir le sens d’un texte. Le terme "entité nommée" (EN) n’est apparu en EI que très récemment lors de la 6ème édition des campagnes d’évaluation MUC62 (voir la section 2.5) et sa définition est encore aujourd’hui l’objet de nombreuses discussions. Ce terme renvoie à la théorie de la "référence directe" évoquée dès la fin du 19ème siècle par des philosophes du langage tels que John Stuart Mill. A l’heure actuelle, une majorité de travaux se retrouvent dans la définition proposée par [Kripke, 1980] sous le nom de "désignateurs rigides" : "entités fortement référentielles désignant directement un objet du monde". Il nous faut également souligner que ces entités nommées dites "entités simples" constituent généralement un premier niveau de la chaîne d’extraction et permettent la détection de structures plus complexes que sont les relations et les événements. A cette première tâche d’extraction est couramment associé le problème de résolution de coréférence entre EN. La résolution de coréférence vise à regrouper plusieurs extractions ayant des formes de surface différentes mais référant à la même entité du monde : par exemple, "Big Apple" et "New York", ou encore "JFK" et "John Fitzgerald Kennedy". Ce problème a surtout été exploré conjointement à la détection d’entités nommées mais cette problématique est applicable à tout type d’extraction. Dans les campagnes MUC, la résolution de coréférence fait partie d’un ensemble de tâches nommé SemEval (Semantic Evaluation) ayant pour objectif une compréhension plus profonde des textes [Grishman and Sundheim, 1996]. De plus, la différentiation entre les termes "mention" et "entité" introduite lors des campagnes ACE 63 (voir la section 2.5) met en avant ce besoin de regrouper plusieurs "mentions" d’une entité provenant d’un ou plusieurs textes. Nous détaillons dans la section 2.2.1 les mé- thodes employées pour la reconnaissance de ces entités nommées et la résolution de coréférence entre ces entités. L’extraction de relations a pour objet d’étude les liens existants entre plusieurs entités : celle-ci peut-être binaire (entre deux objets) ou n-aire (plus de deux objets en relation). Il s’agit par exemple de détecter dans un corpus de documents que Barack Obama est l’actuel président des États-Unis, ce qui se traduira par une relation de type "président de" entre l’entité de type Personne "Barack Obama" et l’entité de type Lieu "États-Unis". La détection de relations n-aires correspond à ce que l’on nomme en anglais "record extraction" où il s’agit de repérer un réseau de relations entre entités et dont l’extraction 61. Traitement Automatique du Langage Naturel 62. Message Understanding Conference, ❤tt♣✿✴✴✇✇✇✲♥❧♣✐r✳♥✐st✳❣♦✈✴r❡❧❛t❡❞❴♣r♦❥❡❝ts✴♠✉❝✴ 63. Automatic Content Extraction, ❤tt♣✿✴✴✇✇✇✳✐t❧✳♥✐st✳❣♦✈✴✐❛❞✴♠✐❣✴t❡sts✴❛❝❡✴ 41 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information d’événements fait partie. Cette problématique diffère de la tâche de reconnaissance des entités nommées sur un point essentiel. Une entité nommée correspond à une portion séquentielle de texte et peut être directement représentée par une annotation délimitant le début et la fin de cette séquence. Une relation entre entités ne correspond pas directement à un ensemble consécutif de mots mais représente un lien entre deux portions de texte. Cela implique des processus et des formats d’annotation différents pour ces deux types de tâches. Dans la section 2.2.2, nous nous focaliserons sur les méthodes utilisées pour la détection de relations binaires, les relations n-aires seront abordées par le biais de l’extraction des événements. Est couramment associée à cette tâche d’EI l’extraction d’attributs ayant pour objectif d’extraire automatiquement un ensemble pré-défini de propriétés rattachées à ces entités, le type de ces propriétés dépendant directement de la nature de l’objet en question. Par exemple pour une personne, on pourra extraire son nom et son prénom, sa nationalité, son âge, etc. et pour une entreprise, son siège social, le nombre d’employés, etc. L’extraction des événements est une autre tâche de l’EI très étudiée. Celle-ci peut être conçue comme une forme particulière d’extraction de relations où une "action" est liée à d’autres entités telles qu’une date, un lieu, des participants, etc. Comme cela a été décrit dans les sections 1.3 et 1.3.1.2, cette définition peut varier selon les points de vue théoriques et les applications et donne lieu à différentes représentations et ontologies dédiées aux événements. La détection d’événements s’avère particulièrement utile dans les activités de veille en général et intéresse de plus en plus les entreprises de nombreux domaines pour ses applications en intelligence économique et stratégique [Capet et al., 2011]. Nous présentons par la suite (en section 2.2.3) un tour d’horizon des techniques utilisées pour le repérage des événements dans les textes. 2.2 Approches d’extraction En extraction d’information émergent historiquement deux principaux types d’approche : l’extraction basée sur des techniques linguistiques d’un côté et les systèmes statistiques à base d’apprentissage de l’autre. Cette distinction se retrouve largement en IA et dans les autres disciplines du TALN telles que la traduction automatique, etc. Le premier type d’approche est nommé dans la littérature "approche symbolique", "à base de connaissances", "déclarative", "à base de règles" ou encore "système-expert" et exploite les avancées en TALN. Celles-ci reposent principalement sur une définition manuelle de toutes les formes linguistiques permettant d’exprimer l’information ciblée, autrement dit l’ensemble des contextes d’apparition de telle entité ou relation. Cela se traduit généralement par l’utilisation de grammaires formelles constituées de règles et patrons linguistiques élaborés par des experts-linguistes. Ces patrons sont généralement de deux types : les patrons lexico-syntaxiques et les patrons lexico-sémantiques. Les premiers associent des caractéristiques de mot (forme fléchie, lemme, genre, casse, etc.) à des indices structurels et de dépendance (syntagmatiques, phrastiques ou textuels). Les patrons lexico-sémantiques y ajoutent des éléments sé- mantiques tels que la projection de lexiques (gazetteers), l’utilisation de réseaux sémantiques externes tels que WordNet 64 ou encore d’ontologies [Hogenboom et al., 2011]. Les méthodes symboliques ont pour principales faiblesses leur taux de rappel peu élevé et leur coût de développement manuel coûteux. 64. ❤tt♣✿✴✴❣❧♦❜❛❧✇♦r❞♥❡t✳♦r❣ 42 Copyright c 2013 - CASSIDIAN - All rights reserved2.2. Approches d’extraction Le second type d’approche utilise des techniques statistiques pour apprendre des régularités sur de larges corpus de textes où les entités-cibles ont été préalablement annotées (domaine du "machine learning"). Ces méthodes d’apprentissage sont supervisées, non-supervisées ou semi-supervisées et exploitent des caractéristiques textuelles plus ou moins linguistiques. Parmi celles-ci nous pouvons citer les "Modèles de Markov Caché" (Hidden Markov Models, HMM), les "Champs Conditionnels Aléatoires" (Conditional Random Fields, CRF), les "Machines à Vecteur de Support" (Support Vector Machines, SVM), etc. ([Ireson et al., 2005] pour un état de l’art approfondi). Les principales limites de ce second type d’approche restent qu’elles nécessitent une grande quantité de données annotées pour leur phase d’apprentissage et produisent des modèles de type "boite noire" qui restent à l’heure actuelle difficilement accessibles et interprétables. Pour répondre à ce problème, des méthodes non-supervisées telles que [Etzioni et al., 2005] proposent d’utiliser des techniques de clustering pour extraire des entités d’intérêt. Depuis quelques années, les méthodes hybrides tendent à se généraliser : les acteurs du domaine combinent plusieurs techniques face aux limites des approches symboliques et statistiques. De plus en plus de recherches portent sur l’apprentissage de ressources linguistiques ou encore sur l’utilisation d’un apprentissage dit "semi-supervisé" visant à combiner des données étiquetées et non-étiquetées ([Nadeau and Sekine, 2007], [Hobbs and Riloff, 2010]). Afin de diminuer l’effort de développement des systèmes symboliques, certains travaux s’intéressent à l’apprentissage automatique de règles d’extraction. A partir d’un corpus annoté, l’objectif est de trouver un ensemble minimal de règles permettant d’atteindre les meilleures performances, c’est-à-dire la meilleure balance entre précision et rappel (voir la section 2.5 pour une définition de ces mesures). Ces approches sont soit ascendantes ("bottom-up" en anglais) lorsqu’elles ont pour point de départ un ensemble de règles très spécifiques et opèrent des généralisations pour augmenter la couverture du système [Califf and Mooney, 2003] ; soit descendantes ("top-down" en anglais) lorsqu’elles partent d’un ensemble de règles très génériques pour arriver, par spécialisations successives, à un système plus précis [Soderland, 1999]. [Muslea, 1999] propose un tour d’horizon des grands types de règle résultant d’un apprentissage automatique. Toutes ces méthodes reposent généralement sur des pré-traitements linguistiques dits "classiques" comme la "tokenization" (découpage en mots), la lemmatisation (attribution de la forme non-fléchie associée), l’analyse morphologique (structure et propriétés d’un mot) ou syntaxique (structure d’une phrase et relations entre éléments d’une phrase). Notons ici l’importance particulière accordée à l’analyse syntaxique (en constituants ou dépendance) dans le repérage et le typage des relations et des événements. Nous détaillons par la suite quelques techniques couramment mises en œuvre selon le type d’objet à extraire : entité nommée, relation ou événement. 2.2.1 Extraction d’entités nommées et résolution de coréférence La reconnaissance automatique d’entités nommées fut consacrée comme l’une des tâches principales de l’EI lors de la 6ème campagne d’évaluation MUC. Les systèmes alors proposés s’attellent à l’extraction de trois types d’entités définis sous les noms "ENAMEX", "TIMEX" et "NUMEX" correspondant respectivement aux noms propres (personnes, lieux, organisations, etc.), entités temporelles et entités numériques. Cette classification n’est pas la seule dans la littérature, [Daille et al., 2000] aborde notamment la distinction entre les catégorisations dites "référentielles" (telles que celle de MUC) et celles dites "graphiques". Les premières classent les entités nommées selon la nature des objets du monde auxquels elles renvoient tandis que les secondes proposent une classification selon la composition graphique des 43 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information entités. A titre d’exemple, une classification inspirée de [Jonasson, 1994] distingue les entités nommées "pures simples", des EN "pures complexes" et des EN "mixtes". Quelque soit la catégorisation choisie, celle-ci est fixée a priori dans la majorité des applications. A l’inverse, les récents travaux autour de la construction d’ontologies et de bases de connaissances à partir de textes mettent en œuvre une extraction "tous types confondus" pour en déduire a posteriori une classification. L’extraction des entités nommées est généralement déroulée en deux phases : leur repérage dans le texte et leur typage selon la catégorisation pré-définie. [Nadeau and Sekine, 2007] propose un état de l’art des différentes approches explorées jusqu’à nos jours pour réaliser cette tâche : on y retrouve l’opposition "classique" (abordée dans la section précédente) entre méthodes symboliques et statistiques ainsi que l’intérêt récent pour les approches hybrides. Par ailleurs, [Friburger, 2006] présente les aspects linguistiques les plus communément exploités par les systèmes de REN. Les approches à base de règles linguistiques sont les plus anciennes et, bien que coûteuses car elles sont définies manuellement par un expert, elles s’avèrent généralement plus rapides à l’exécution et plus personnalisables. L’ensemble de règles s’apparente à une grammaire locale et vise à définir de façon la plus exhaustive possible les différents contextes d’apparition de telle entité. De nombreux formats d’expression de règles d’extraction existent (CPSL [Appelt and Onyshkevych, 1998], JAPE [Cunningham et al., 2000], DataLog [Ceri et al., 1989], etc.) et celles-ci partagent la structure générique suivante : regle : contexte → action La partie contexte est composée de plusieurs propositions décrivant un contexte textuel au moyen de diverses caractéristiques linguistiques et formelles. Le repérage des entités nommées se base géné- ralement sur la présence de majuscules puis leur catégorisation est réalisée grâce à des listes de noms propres connus ou de mots dits "catégorisants" (par exemple les prénoms). Ces caractéristiques peuvent être des attributs associés aux tokens (unités lexicales correspondant plus ou moins à un découpage en mots), à des segments plus larges tels que les syntagmes, à la phrase ou au texte dans son entier. Elles peuvent provenir de l’entité elle-même ou de son co-texte (respectivement "internal evidence" et "external evidence" [McDonald, 1996]). Lorsque le contexte est repéré dans le corpus à traiter, la partie action de la règle est exécutée. Il s’agit dans la plupart des cas d’apposer une annotation d’un certain type sur tout ou partie du contexte textuel repéré. Afin de gérer d’éventuels conflits lors de l’exécution d’un ensemble de règles, la plupart des systèmes intègrent des polices d’exécution sous forme d’heuristiques (par exemple : la règle qui produit l’annotation la plus longue est privilégiée) ou d’attribution de priorité à chaque règle. Par ailleurs, les systèmes à base de règles sont couramment implémentés en cascade, c’est-à-dire que les annotations fournies par un premier ensemble de règles peuvent être réutilisées en entrée d’un second ensemble de règles. [Wakao et al., 1996] développe le système LaSIE, une chaine de traitement symbolique fondée sur des grammaires d’unification exprimées en Prolog. Cet extracteur d’EN pour l’anglais a été évalué sur un ensemble d’articles du Wall Street Journal et atteint une F-mesure d’environ 92%. A la même période, l’ancien Stanford Research Center propose FASTUS (sponsorisé par la DARPA), un automate à états finis non-déterministe pour l’extraction d’entités nommées (sur le modèle de MUC-4) dans des textes en anglais et en japonais [Hobbs et al., 1997]. Plus récemment, [Maurel et al., 2011] présente le système open-source CasEN dédié au traitement des textes en français et développé grâce au logiciel CasSys (fourni par la plateforme Unitex) facilitant la création de cascades de transducteurs. Cet outil a 44 Copyright c 2013 - CASSIDIAN - All rights reserved2.2. Approches d’extraction notamment été testé lors de la campagne d’évaluation ESTER 2 65 (voir la section 2.5) dont l’objectif est de comparer les performances des extracteurs d’EN sur des transcriptions de la parole. Bien que les approches statistiques bénéficient d’un essor plus récent, de nombreuses techniques d’extraction ont été et sont encore explorées. Le principe sous-jacent de ces méthodes est d’apprendre, à partir de textes pré-annotés avec les entités-cibles, un modèle de langage qui, appliqué sur un nouveau corpus, permettra d’extraire de nouvelles entités du même type. La majorité de ces approches se fonde sur un corpus d’apprentissage segmenté en tokens auxquels est associé un certain nombre de caracté- ristiques représentées par des vecteurs. Ces caractéristiques peuvent être intrinsèques au token (telles que sa forme de surface, sa longueur, sa catégorie grammaticale, etc.), liées à sa graphie (sa casse, la présence de caractères spécifiques, etc.) ou encore provenir de ressources externes (bases d’entités nommées connues, liste de mots catégorisants, etc.). A partir de ces différentes informations fournies dans le corpus d’apprentissage, la reconnaissance d’entités nommées est traitée comme un problème de classi- fication. On distingue d’une part, des classifieurs dits linéaires tels que les modèles à base de régression logistique ou les machines à vecteurs de support [Isozaki and Kazawa, 2002] et, d’autre part, des classifieurs graphiques probabilistes tels que les HMMs [Zhao, 2004] ou les CRFs [Lafferty et al., 2001]. Le second type de classification est généralement plus performant car il permet de prendre en compte, lors de l’apprentissage du modèle d’annotation, les dépendances de classe entre tokens voisins. La principale limite de toutes ces approches reste le fait qu’elles construisent leur modèle au niveau token et ne permettent pas d’exploiter d’autres caractéristiques à un niveau de granularité plus élevé. Pour pallier à ce problème, il existe des techniques d’apprentissage statistique fondées sur un découpage en segments (en groupes syntaxiques, par exemple) ou sur une analyse de la structure globale des textes [Viola and Narasimhan, 2005]. Toutefois, les CRFs restent le modèle statistique le plus utilisé actuellement en REN de par leurs bonnes performances et leur capacité d’intégration de diverses caractéristiques [Tkachenko and Simanovsky, 2012]. Par ailleurs, les chercheurs en EI s’intéressent ces dernières années à combiner des techniques issues des approches symboliques et statistiques pour améliorer les performances de leurs systèmes d’extraction. [Charnois et al., 2009], par exemple, propose une approche semi-supervisée par apprentissage de patrons linguistiques pour l’extraction d’entités biomédicales (ici les noms de gènes). Ce travail met en œuvre une extraction de motifs séquentiels fréquents par fouille de textes et sous contraintes. Cette approche permet une extraction plus performante en utilisant un nouveau type de motif appelé LSR (utilisation du contexte du motif pour augmenter sa précision). Par ailleurs, [Charton et al., 2011] s’intéresse à l’extraction d’entités nommées en utilisant des motifs d’extraction extraits à partir de Wikipedia pour compléter un système d’apprentissage statistique par CRF. Les auteurs exploitent ici le contenu riche en noms propres et leurs variantes des ressources encyclopédiques telles que Wikipedia pour en extraire des patrons linguistiques. Ces résultats sont ensuite fusionnés avec ceux de l’approche statistique et une amélioration de la REN est constatée après évaluation sur le corpus de la campagne ESTER 2. L’inconvé- nient ici étant le besoin de données annotées, d’autres méthodes proposent d’interagir avec l’utilisateur : celui-ci fournit un petit ensemble d’exemples permettant d’obtenir un premier jeu de règles et celui-ci est amélioré de façon interactive et itérative [Ciravegna, 2001]. D’autres travaux tels que [Mikheev et al., 1999] choisissent de limiter la taille des gazetteers utilisés pour la REN et montrent que, tout en allégeant fortement la phase de développement de leur système (une approche hybride combinant un système à base de règles à un modèle probabiliste à Maximum d’Entropie), cela à un impact faible sur ses performances. [Fourour, 2002] propose Nemesis, un outil de REN fondé sur une approche incrémentielle se 65. Évaluation des Systèmes de Transcription Enrichie d’Émissions Radiophoniques, ❤tt♣✿✴✴✇✇✇✳❛❢❝♣✲♣❛r♦❧❡✳♦r❣✴ ❝❛♠♣❴❡✈❛❧❴s②st❡♠❡s❴tr❛♥s❝r✐♣t✐♦♥✴ 45 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information déroulant en trois phases : un premier jeu de règles est appliqué, celui-ci est suivi d’une étape d’apprentissage pour améliorer ce jeu, puis un second repérage est effectué grâce au jeu de règles amélioré. Pour finir, beaucoup de travaux se penchent sur la résolution de coréférence entre entités nommées. En effet, comme introduit dans la section 2.1, il est courant de faire référence à une entité du monde réel (une personne, un lieu, une organisation, etc.) de plusieurs manières : par son/ses nom(s) propre(s) (par exemple, "Paris" ou "Paname"), par une expression la décrivant ("la capitale de la France") ou encore par un groupe nominal ou un pronom en contexte ("cette ville", "elle"). Ainsi, lorsqu’un texte contient différentes mentions d’une même entité, il apparait intéressant de pouvoir les lier (on obtient ainsi des chaines de référence) pour indiquer qu’elles font référence à un seul et même objet réel, qu’il y a donc coréférence. Cette problématique n’est pas triviale et peut s’appliquer à un seul et même document mais aussi au sein d’un corpus (coréférence entre entités provenant de textes distincts). La résolution de coréférence peut se faire de façon endogène ou exogène (en utilisant des ressources externes), en utilisant des techniques linguistiques, statistiques ou hybrides. Cette tâche fait notamment partie de campagnes d’évaluation telles que ACE (Global Entity Detection and Recognition). [Bontcheva et al., 2002] adopte une approche à base de règles pour la résolution de coréférence entre ENs et pronominale. Ces travaux ont été implémentés sous la forme d’un transducteur à états finis au sein de la plateforme GATE et sont intégrés à la chaine de traitement ANNIE (il s’agit des modules nommés Orthomatcher et Pronominal Corerefencer). Un exemple d’approche statistique et exogène est celle présentée par [Finin et al., 2009] où la base de connaissances Wikitology (construites à partir de Wikipedia, DBPedia et FreeBase) est utilisée en entrée d’un classifeur SVM (avec une trentaine d’autres caractéristiques textuelles) pour la construction de chaines de référence. 2.2.2 Extraction de relations L’extraction de relations consiste à détecter et typer un lien exprimé textuellement entre deux entités. Cette tâche a notamment été proposée à l’évaluation lors de la campagne MUC-7, évaluation poursuivie par les campagnes ACE à partir de 2002. Les avancées dans cette problématique proviennent essentiellement des travaux d’EI menés dans les domaines de la médecine et de la biologie, notamment pour l’analyse des rapports médicaux et expérimentaux. Les premiers systèmes développés sont fondés sur un ensemble de règles d’extraction dont les plus simples définissent des patrons sous forme de triplets du type : e1 relation e2 (où e1 et e2 sont deux entités reconnues au préalable). La majorité des relations n’étant pas exprimées aussi simplement dans les textes réels, les règles d’extraction doivent être plus élaborées et intégrer d’autres caractéristiques textuelles situées soit entre les deux entités visées soit autour du triplet relationnel. Comme pour la REN, les systèmes complètent couramment des caractéristiques de mot et une analyse structurelle par des indices sémantiques. [Muller and Tannier, 2004] présente une méthode symbolique comprenant une analyse syntaxique pour la détection de relations temporelles entre entités de type "événement". Dans le domaine médical, [Fundel et al., 2007] développe RelEx, un outil visant à extraire les interactions entre protéines et gènes et dont l’évaluation (sur le corpus MEDLINE) a montré de bonnes performances (précision et rappel d’environ 80%). [Nakamura-Delloye and Villemonte De La Clergerie, 2010] propose une méthode d’extraction de relations entre entités nommées basée sur une analyse en dépendance. Leur idée est de repérer les chemins syntaxiques entre deux entités (i.e. l’ensemble des relations de dépendance qu’il faut parcourir pour relier ces deux entités) afin de construire par généralisation des groupes de patrons de relations syntaxiques spécifiques à tel type de relation sémantique. 46 Copyright c 2013 - CASSIDIAN - All rights reserved2.2. Approches d’extraction De nombreux travaux se tournent également vers l’apprentissage automatique de patrons de relation afin de faciliter ou de remplacer le travail manuel de l’expert. [Cellier et al., 2010], par exemple, s’attache au problème de la détection et du typage des interactions entre gènes par apprentissage de règles linguistiques. Leur approche réutilise une technique employée à l’origine en fouille de données : l’extraction de motifs séquentiels fréquents. Celle-ci permet d’apprendre à partir d’un corpus annoté un ensemble de régularités pour les transformer, après validation par un expert, en règles d’extraction. Il faut noter ici que le corpus d’apprentissage n’est pas annoté avec les relations-cibles mais uniquement avec des caractéristiques de plus bas niveau (entités nommées de type "gène", catégories morpho-syntaxiques, etc.). De plus, l’ajout de contraintes permet de diminuer la quantité de motifs retournés par le système et ainsi faciliter le tri manuel fait par l’expert. Du côté des approches statistiques, [Rosario and Hearst, 2004] s’intéresse à la détection de relations entre maladies et traitements (de sept types distincts dont "cures", "prevents", "is a side effect of", etc.) et compare plusieurs méthodes statistiques pour cette tâche. Une sous-partie du corpus MEDLINE 2011 est annotée manuellement par un expert du domaine afin d’entraîner et tester plusieurs modèles graphiques et un réseau de neurones. Ce dernier obtient les meilleures performances avec une précision d’environ 97%. Une autre approche statistique pour l’extraction de relations est celle de [Zhu et al., 2009] proposant de combiner un processus de "bootstrapping" et un réseau logique de Markov. Le premier permet d’initier l’apprentissage à partir d’un petit jeu de relations fournies par l’utilisateur et ainsi diminuer le besoin en données annotées. De plus, ce travail exploite les capacités d’inférence permises par les réseaux logiques de Markov afin d’augmenter les performances globales de leur système StatSnowball. La plupart des approches supervisées étant dépendantes du domaine de leur corpus d’apprentissage, [Mintz et al., 2009] s’intéresse à une supervision dite "distante" en utilisant la base de connaissances sémantique Freebase 66. Le principe de ce travail est de repérer dans un corpus de textes brut des paires d’entités étant en relation dans Freebase et d’apprendre des régularités à partir du contexte textuel de cette paire. L’apprentissage est implémenté ici sous la forme d’un classifieur à logique de régression multi-classes et prend en compte des caractéristiques lexicales (par exemple, la catégorie grammaticale des mots), syntaxiques (une analyse en dépendance) et sémantiques (un repérage des entités nommées). Pour finir, nous pouvons citer quelques travaux comme ceux de [Hasegawa et al., 2004] ou [Wang et al., 2011] proposant d’appliquer des techniques de "clustering" à l’extraction de relations. Le premier décrit une méthode non-supervisée d’extraction et de catégorisation de relations entre EN par "clustering". Celui-ci s’opère par une première étape de représentation du contexte de chaque paire d’entités proches en vecteurs de caractéristiques textuelles. Puis, on calcule une similarité cosinus entre vecteurs qui est donnée en entrée d’un "clustering" hiérarchique à lien complet. On obtient ainsi un "cluster" par type de relation, relation nommée en prenant le mot ou groupe de mot le plus fréquent entre paires d’EN au sein du "cluster". D’autre part, [Wang et al., 2011] s’intéresse à la détection de relations en domaine ouvert et de façon non-supervisée. Pour cela, leur approche est d’extraire un ensemble de relations par plusieurs phases de filtrage puis de les regrouper par type en utilisant des techniques de "clustering". La première étape est réalisée par trois filtrages successifs : les phrases contenant deux ENs et au moins un verbe entre les deux sont sélectionnées, puis les phrases non-porteuses de relation sont évacuées par des heuristiques et enfin par un apprentissage à base de CRFs. Une fois l’ensemble des relations pertinentes extraites, celles-ci sont regroupées par type sémantique en utilisant un algorithme de "clustering de Markov". Cette méthode ne nécessite pas d’annoter les relations dans un corpus d’apprentissage, ni de fixer au préalable les différents types de relation à extraire. 66. ❤tt♣✿✴✴✇✇✇✳❢r❡❡❜❛s❡✳❝♦♠✴ 47 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information 2.2.3 Extraction d’événements L’extraction d’événements, parfois considérée comme une extraction de relations n-aires, consiste à repérer dans un ou plusieurs textes des événements d’intérêt tels que définis dans la section 1.3. Cette tâche peut se résumer par le fait de répondre à la question suivante : "Who did what to whom when and where ?". Certains modèles y ajoutent les questions "how ?" et "why ?". La littérature dans ce domaine montre que l’extraction des événements regroupe généralement plusieurs sous-tâches [Ahn, 2006] : 1. détection des marqueurs d’événement ; 2. affectation des attributs ; 3. identification des arguments ; 4. estimation des rôles ; 5. résolution de coréférence. Plusieurs campagnes MUC67 s’y sont intéressé avec notamment des tâches de remplissage automatique de formulaires ("template filling"). Comme en extraction d’information de façon générale, la littérature du domaine offre à la fois des travaux basés sur des approches symboliques et des techniques purement statistiques. La première approche symbolique retenue est décrite dans [Aone and Ramos-Santacruz, 2000] : il s’agit du système REES 68 permettant l’extraction de relations et d’événements à grande échelle. Cet outil repose sur l’utilisation combinée de lexiques et de patrons syntaxiques pour la détection d’évé- nements principalement basés sur des verbes. Ces lexiques correspondent à une description syntaxique et sémantique des arguments de chaque verbe déclencheurs d’événement. Ces informations sont par la suite réutilisées au sein des patrons syntaxiques décrivant les différents contextes d’apparition d’un évé- nement. Dans la lignée, [Grishman et al., 2002b] s’intéresse à la détection d’événements épidémiques au moyen d’un transducteur à états finis. Par ailleurs, le système d’extraction IE2 (Information Extraction Engine) a été développé par la société américaine SRA International spécialisée dans le traitement de l’information [Aone et al., 1998]. Cet outil a obtenu les meilleures performances (51% de F-mesure) pour la tâche Scenario Template (ST) lors de la campagne d’évaluation MUC-7. Il s’agit d’une extracteur modulaire comprenant 6 modules dont celui nommé "EventTag" permettant le remplissage de scénarios d’événement grâce à des règles syntactico-sémantiques élaborées manuellement. Un autre outil d’EI à base de connaissances est celui proposé par [Appelt et al., 1995], il s’agit du système FASTUS ayant participé à plusieurs campagnes d’évaluation (MUC-4, MUC-5 et MUC-6). Cet extracteur est fondé sur un ensemble de règles de grammaire développé par des experts et a montré de bonnes performances dans la tâche d’extraction d’événements de MUC-6 69. FASTUS a obtenu une F-mesure de 51% contre 56% pour le meilleur des systèmes de la campagne. Cet outil est fondé sur un formalisme d’expression de règles nommé FASTSPEC visant à faciliter l’adaptation de l’outil à de nouveaux domaines. Du côté des approches statistiques, [Chieu, 2003] développe le système ALICE 70 afin d’extraire des événements par apprentissage statistique. Ceux-ci ont évalué quatre algorithmes de classification issus de la suite Weka sur les données-test de la campagne MUC-4. Le corpus d’apprentissage est constitué des documents sources (des dépêches de presse) et des fiches d’événements associés. Les caractéristiques utilisées intègrent notamment une analyse des dépendances syntaxiques par phrase du corpus ainsi que des 67. Message Understanding Conference 68. Relation and Event Extraction System 69. la tâche concernait les changements de personnel dans la direction d’une entreprise 70. Automated Learning-based Information Content Extraction 48 Copyright c 2013 - CASSIDIAN - All rights reserved2.2. Approches d’extraction chaines de coréférence entre entités nommées. Les meilleurs résultats sont obtenus avec un classifieur à Maximum d’Entropie (ALICE-ME) et celui-ci approche les performances du meilleur des participants de la campagne MUC-4. D’autre part, [Jean-Louis et al., 2012] présente un outil d’extraction d’événements sismiques exploitant des techniques d’analyse du discours et d’analyse de graphes. La reconnaissances des événements s’effectue en trois phases : un découpage des textes selon leur contenu événementiel, la construction d’un graphe des entités reconnues et le remplissage d’un formulaire d’événement par sélection des entités pertinentes dans le graphe. La première phase repose sur un apprentissage statistique par CRF tandis que la seconde est réalisée grâce à un classifieur à Maximum d’Entropie. Le corpus d’apprentissage pour ces deux premières étapes est constitué de dépêches provenant de l’AFP et de Google Actualités pour lesquelles des experts ont manuellement construits les formulaires d’événements. Les caractéristiques pour l’apprentissage (découpage en mots et phrases, détection des ENs, analyse syntaxique, etc.) ont été obtenues de l’analyseur LIMA [Besançon et al., 2010]. Enfin, le remplissage des formulaires d’événement est réalisé par combinaison de plusieurs algorithmes de sélection (PageRank, vote, etc.) afin de choisir la meilleure entité du graphe pour chaque champ du formulaire. Les méthodes d’apprentissage de patrons ou les approches semi-supervisées apparaissent intéressantes comme par exemple le système de [Xu et al., 2006]. Ceux-ci proposent un outil d’extraction de patrons linguistiques par une méthode de "bootstrapping" appliquée à la détection des événements comme des remises de prix ("prize award events"). Cette approche est itérative et faiblement supervisée car elle permet, en partant de quelques exemples d’événements provenant d’une base de données existante, d’apprendre des régularités d’occurrence de ces événements et d’en déduire des patrons d’extraction. Ceux-ci ont ensuite été implémentés sous forme de règles dans une application créée grâce à la plateforme SProUT 71 [Drozdzynski et al., 2004]. Nous pouvons égelement citer le projet TARSQI 72 (respectant la spécification TimeML) qui a donné lieu au développement du système Evita 73. [Saurí et al., 2005] présente succinctement les principes théoriques sur lesquels repose cet outil ainsi que son fonctionnement général. Les auteurs définissent les verbes, noms et adjectifs comme les trois catégories de mots déclencheurs étant les plus porteuses de sens pour la détection d’événements. Ils détaillent par la suite les différentes méthodes d’extraction associées à chaque type de déclencheur et plus particulièrement les caractéristiques textuelles et grammaticales à prendre en compte. Ainsi, pour la détection d’événements portés par un verbe, Evita opère un découpage en syntagmes verbaux et détermine pour chacun sa tête ; puis, vient une phase de tri lexical pour écarter les têtes ne dénotant pas un événement (verbes d’état, etc.) ; l’on tient ensuite compte des traits grammaticaux du verbe tels que la voix, la polarité (positif/négatif), la modalité, etc. ; et une analyse syntaxique de surface vient aider à l’identification des différents participants de l’événement. Pour finir, [Huffman, 1995] propose LIEP 74, un système de découverte de patrons d’extraction dont les résultats sont utilisés par l’extracteur d’événements symbolique ODIE 75. Dans cette approche, on propose à l’utilisateur une interface lui permettant de remplir une fiche d’événement correspondant à une phrase donnée. Ces éléments sont ensuite utilisés pour apprendre par une approche ascendante (voir section 2.2) un ensemble de patrons récurrents qui sont ensuite ajoutés en tant que nouveaux chemins dans le transducteur à états finis de l’outil ODIE. Les auteurs de ce système montrent que LIEP approche les performances d’un système purement symbolique avec une F-mesure de 85% contre 89% pour ODIE. 71. Shallow Processing with Unification and Typed feature structures 72. Temporal Awareness and Reasoning Systems for Question Interpretation 73. Events In Texts Analizer 74. Learning Information Extraction Patterns 75. On-Demand Information Extraction 49 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information 2.3 Plateformes et logiciels pour l’EI Ces années de recherche en EI ont donné lieu comme vu précédemment à de nombreux travaux et, par conséquent, au développement de nombreux outils d’extraction d’information. Afin de faciliter ces développements et leur réutilisation au sein de chaines plus complexes, est apparu un nombre important de ce qu’on pourrait appeler des boites à outils pour l’EI et le TAL plus généralement. Celles-ci partagent une même visée finale, à savoir le traitement automatique des textes, mais se différencient sur plusieurs points. Elles proviennent tout d’abord de milieux différents, soit académique, soit industriel, soit sont issues d’une collaboration entre laboratoire(s) de recherche et entreprise(s) au sein d’un projet commun. De plus, il peut s’agir soit de simples entrepôts d’outils et algorithmes, soit de véritables plateformes d’intégration de modules hétérogènes. Dans ce cas, on pourra constater des choix d’architecture distincts pour la combinaison et l’enchainement de ces différents modules. Par ailleurs, la diversité et la complexité des documents traités constitue également un facteur de variation (différents formats, langues, domaines, structures, etc.). Cette hétérogénéité des contenus se traduit naturellement par différents choix de représentation de l’information, même si le format XML tend à se généraliser. Enfin, ces boites à outils ne donnent pas la même priorité à l’interaction avec l’utilisateur et ne se dotent pas des mêmes moyens de visualisation [Enjalbert, 2008]. Nous présentons ici un rapide tour d’horizon de ces boites à outils, centré sur différentes plateformes et suites logicielles distribuées en open-source et/ou gratuitement. Précisons tout d’abord que cette liste est non-exhaustive et a été constituée, sans ordre préférentiel, au fil de notre état de l’art et de nos travaux. OpenCalais Tout d’abord, la société Thomson Reuters (qui a racheté ClearForest) propose plusieurs services autour de l’extraction d’information regroupés sous le nom OpenCalais 76. Celle-ci a mis en place OpenCalais Web Service, un outil en ligne d’extraction d’entités nommées, relations et évènements. Cet outil ainsi que les divers plugins qui l’accompagnent (Marmoset, Tagaroo, Gnosis, etc.) sont utilisables gratuitement pour usage commercial ou non. Le service d’annotation en ligne permet de traiter des textes en anglais, français et espagnol grâce à une détection automatique de la langue du texte fourni. Il extrait pour toutes ces langues un nombre conséquent de types d’entités nommées (villes, organisations, monnaies, personnes, e-mails, etc.) et attribue également un indice de pertinence/intérêt à chacune des extractions. L’analyse des textes en anglais est plus complète : extraction d’événements et de relations, désambiguïsation d’entités, détection de thème, association automatique de mots-clés ("semantic tags"), etc. Toutes ces annotations peuvent être récupérées au format RDF 77. Enfin, précisons qu’OpenCalais fournit aussi bien des modules fondés sur des techniques linguistiques que des méthodes statistiques ou hybrides. 76. ❤tt♣✿✴✴✇✇✇✳♦♣❡♥❝❛❧❛✐s✳❝♦♠✴ 77. Ressource Description Framework 50 Copyright c 2013 - CASSIDIAN - All rights reserved2.3. Plateformes et logiciels pour l’EI LingPipe LingPipe développé par Alias-i 78 constitue une autre véritable "boîte à outils" pour l’analyse automatique de textes. Divers outils y sont disponibles gratuitement pour la recherche et, parmi ceux-ci, une majorité relèvent plus ou moins directement du domaine de l’extraction d’information. D’une part, des modules de pré-traitement permettent de « préparer » le texte pour la phase d’extraction : analyse morpho-syntaxique, découpage en phrases, désambiguïsation sémantique de mots. D’autre part, LingPipe met à disposition des modules de détection d’entités nommées, de phrases d’intérêt, d’analyse d’opinion et de classification thématique. Ces traitements sont tous réalisés par approche statistique et notamment par l’utilisation de CRF et d’autres modèles d’apprentissage (spécifiques à une langue, un genre de texte ou un type de corpus). OpenNLP Également reconnu, le groupe OpenNLP 79 rassemble un nombre important de projets open-source autour du Traitement Automatique du Langage. Son objectif principal est de promouvoir ces initiatives et de favoriser la communication entre acteurs du domaine pour une meilleure interopérabilité des systèmes. En extraction d’information, nous pouvons retenir les projets NLTK 80, MALLET 81, Weka 82 ou encore FreeLing 83. Le premier correspond à plusieurs modules en Python pouvant servir de base au dé- veloppement de son propre outil d’extraction. Le second projet, MALLET, est un logiciel développé par les étudiants de l’université du Massachussetts Amherst sous la direction d’Andrew McCallum, expert du domaine [McCallum, 2005]. Ce logiciel inclut différents outils pour l’annotation de segments (entités nommées et autres), tous basés sur des techniques statistiques de type CRF, HMM et MEMM 84. Dans la même lignée, Weka est une suite de logiciels gratuits de "machine learning" développé à l’Université de Waikato (Nouvelle-Zélande) et distribués sous licence GNU GPL 85 [Hall et al., 2009]. Enfin, FreeLing [Padró and Stanilovsky, 2012] est une suite d’analyseurs de langage dont des modules de découpage en phrases, de tokenisation, lemmatisation, étiquetage grammatical, analyse syntaxique en dépendance, etc. Ce projet propose notamment une palette d’outils de traitement automatique pour la langue espagnole. GATE GATE est une plateforme open-source Java dédiée à l’ingénierie textuelle [Cunningham et al., 2002]. Créée il y a une vingtaine d’années par les chercheurs de l’université de Sheffield (Royaume-Uni), GATE est largement utilisé par les experts en TAL et dispose d’une grande communauté d’utilisateurs. Cela lui permet de disposer d’un ensemble de solutions d’aide et de support (forum, liste de diffusion, foire aux questions, wiki, tutoriels, etc.). Par ailleurs, les créateurs de GATE propose des formations ainsi que des certifications permettant de faire valoir ses compétences à l’utilisation de cette plateforme. 78. ❤tt♣✿✴✴❛❧✐❛s✲✐✳❝♦♠✴❧✐♥❣♣✐♣❡✴ 79. Open Natural Language Processing, ❤tt♣✿✴✴♦♣❡♥♥❧♣✳s♦✉r❝❡❢♦r❣❡✳♥❡t✴ 80. Natural Language ToolKit, ❤tt♣✿✴✴✇✇✇✳♥❧t❦✳♦r❣✴ 81. Machine Learning for LanguagE Toolkit, ❤tt♣✿✴✴♠❛❧❧❡t✳❝s✳✉♠❛ss✳❡❞✉✴ 82. Waikato Environment for Knowledge Analysis, ❤tt♣✿✴✴✇✇✇✳❝s✳✇❛✐❦❛t♦✳❛❝✳♥③✴♠❧✴✇❡❦❛✴ 83. ❤tt♣✿✴✴♥❧♣✳❧s✐✳✉♣❝✳❡❞✉✴❢r❡❡❧✐♥❣✴ 84. Maximum Entropy Markov Models 85. General Public License 51 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information LinguaStream Par ailleurs, le GREYC 86 développe depuis 2001 la plateforme LinguaStream 87, un environnement intégré orienté vers la pratique expérimentale du TALN. Celui-ci permet un assemblage visuel de modules de traitement hétérogènes pour des applications en EI, RI, veille, résumé automatique, enseignement, etc. Ces enchainements de modules sont représentés sous forme de graphes acycliques et l’ensemble des données traitées est sérialisé en XML. [Widlocher et al., 2006] présente une application (réalisée dans le cadre de DEFT’2006) de segmentation thématique de textes implémentée grâce à la plateforme LinguaStream. Unitex La boite à outils Unitex est principalement développée par Sébastien Paumier à l’Institut Gaspard Monge (Université de Paris-Est Marne-la-Vallée) [Paumier, 2003]. Il s’agit d’une plateforme open-source multilingue pour le traitement en temps réel de grandes quantités de textes en langage naturel. Unitex permet d’appliquer des traitements divers sur les textes tels que le repérage de patrons linguistiques sous forme d’expressions régulières ou d’automates, l’application de lexiques et de tables, etc. Cela y est implémenté par des réseaux de transition récursifs définissables graphiquement. Cet outil propose également la production de concordances ou encore un ensemble d’études statistiques en corpus. Nooj Créateur de la plateforme Intex au LADL 88 (sous la direction du Professeur Maurice Gross), le Professeur Max Silberztein continue ses travaux depuis 2002 en proposant NooJ 89, un environnement de développement dédié au traitement du langage naturel écrit [Silberztein et al., 2012]. Cette suite propose des modules de traitement pour une vingtaine de langues (anglais, français, portugais, arabe, chinois, hébreu, etc.) et gère plus d’une centaine de formats de fichier d’entrée. Comme dans beaucoup de plateformes de ce type, les données y sont manipulées au format XML et enrichies grâce aux annotations fournies par les différents composants appliqués en cascade. Une communauté, en majorité européenne, s’est formée autour de cette plateforme donnant lieu depuis 2005 à une conférence NooJ annuelle réunissant divers travaux réalisés grâce à cet outil ainsi qu’à des tutoriels et ateliers réguliers. Stanford NLP Group et Ontotext Pour finir, mentionnons également les groupes de recherche Stanford NLP Group 90 et Ontotext 91 dont les travaux sont intégrés dans GATE. L’équipe de l’université de Stanford en Californie, a créé différents outils de TAL très utiles pour l’extraction d’information : un analyseur syntaxique probabiliste pour l’anglais, un étiqueteur morpho-syntaxique ainsi qu’un système d’extraction d’entités nommées qui 86. Groupe de Recherche en Informatique, Image, Automatique et Instrumentation de Caen 87. ❤tt♣✿✴✴✇✇✇✳❧✐♥❣✉❛str❡❛♠✳♦r❣ 88. Laboratoire d’Automatique Documentaire et Linguistique - Université de Paris-Est Marne-la-Vallée 89. ❤tt♣✿✴✴✇✇✇✳♥♦♦❥✹♥❧♣✳♥❡t✴ 90. ❤tt♣✿✴✴♥❧♣✳st❛♥❢♦r❞✳❡❞✉✴ 91. ❤tt♣✿✴✴✇✇✇✳♦♥t♦t❡①t✳❝♦♠✴ 52 Copyright c 2013 - CASSIDIAN - All rights reserved2.4. Applications reconnaît les noms de personne, d’organisation et de lieu. Ontotext développe ses activités autour des technologies sémantiques et diffuse gratuitement la plateforme KIM 92 pour un usage non-commercial. Celle-ci propose de créer des liens sémantiques entre documents mais aussi d’extraire les entités nommées, relations et événements d’un texte et de les stocker automatiquement dans une base de données. 2.4 Applications Les applications possibles de l’extraction automatique d’information sont à l’heure actuelle nombreuses et ne cessent de croître avec les avancées de la recherche (en particulier dans le domaine du Web). Dans cet ensemble d’applications, un petit nombre est historique et continue de susciter l’inté- rêt depuis les débuts de l’EI : il s’agit notamment de l’analyse des "news", du domaine biomédical ou encore de la veille économique et stratégique. D’autres usages sont plus récents et coïncident avec l’apparition de nouvelles technologies et des nouveaux besoins utilisateur ou techniques qui en découlent. Nous proposons ici un aperçu (non-exhaustif et général) de quelques cas d’application et des travaux de la littérature associés. Tout d’abord, un grand nombre de travaux s’intéressent à l’utilisation des outils d’EI pour des besoins de veille : celle-ci peut être au service d’une entreprise, d’une entité gouvernementale ou encore d’un particulier souhaitant rester informé sur un sujet donné. Cette veille peut aider à la protection des populations par la prévention des épidémies ([Lejeune et al., 2010], [Grishman et al., 2002a], [Chaudet, 2004]) ou des événements sismiques [Besançon et al., 2011], par exemple. Par l’analyse automatique de différents types de sources d’information (rapports médicaux, dépêches de presse, réseaux sociaux, etc.), l’objectif est d’anticiper autant que possible ce genre de catastrophes et de suivre leur propagation pour assister les forces de secours par exemple. Les gouvernements portent aussi un grand intérêt à l’EI pour automatiser leurs processus de veille stratégique et militaire. [Zanasi, 2009], [Capet et al., 2008], [Tanev et al., 2008] ou encore [Pauna and Guillemin-Lanne, 2010] présentent leurs travaux pour une évaluation et un suivi du risque militaire et/ou civil, national et/ou international. [Hecking, 2003] se concentre sur l’analyse automatique des rapports écrits par les militaires, [Sun et al., 2005] et [Inyaem et al., 2010a] de leur côté s’intéressent à la prévention des actes de terrorisme. Enfin, [Goujon, 2002] présente une extraction automatique des événements appliquée à la crise de 2002 en Côte d’Ivoire. Dans le domaine économique, cette veille vise essentiellement à cerner des communautés de consommateurs (par exemple à partir du contenu des blogs [Chau and Xu, 2012]), à assurer un suivi des technologies et/ou produits d’un secteur donné pour les besoins d’une entreprise [Zhu and Porter, 2002] ou encore à améliorer son service-client par analyse des conversations téléphoniques [Jansche and Abney, 2002]. Pour tous les types de veille mis en œuvre, les acteurs du domaine s’intéressent également à adapter les processus d’EI pour garantir un traitement des informations en temps réel [Piskorski and Atkinson, 2011] [Liu et al., 2008]. Cette "fraicheur" des informations est particulièrement importante pour les analystes financiers et le suivi des évolutions des bourses par exemple [Borsje et al., 2010]. Par ailleurs, les chercheurs en EI se mettent au service d’autres sciences telles que la médecine et la biologie en permettant l’analyse automatique de rapports médicaux pour l’extraction d’interactions entre protéines, gènes, etc. [Rosario and Hearst, 2005] [Bundschus et al., 2008]. Dans un autre domaine d’intérêt public, la Commission Européenne a financé le projet PRONTO pour la détection d’événements dans les réseaux de transport public [Varjola and Löffler, 2010]. Les techniques d’EI sont également 92. Knowledge and Information Management 53 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information exploitées pour aider les acteurs judiciaires avec notamment l’analyse automatique des rapports de police [Chau et al., 2002]. Un autre cas d’application est le traitement automatique des publications scientifiques pour la construction de bases de citations telles que Citeseer [Lawrence et al., 1999]. De plus, comme mentionné en introduction de ce chapitre (voir la section 2.1), les résultats des outils d’extraction peuvent servir à d’autres disciplines de l’IA telles que la recherche d’information [Vlahovic, 2011], les systèmes de questions-réponses [Saurí et al., 2005], la construction des ontologies [Vargas-Vera and Celjuska, 2004] [Piskorski et al., 2007], le résumé automatique de documents [Radev et al., 2001], etc. Enfin, avec la récente démocratisation de l’IA et l’entrée dans les foyers de nouvelles technologies de l’information, beaucoup de recherches en EI concernent des applications dédiées au grand public. Les systèmes de recommandation en ligne en bénéficient [Luberg et al., 2012] [Ittoo et al., 2006], mais aussi les logiciels anti-spam [Jason et al., 2004] ou encore les sites de recherche d’emploi [Califf and Mooney, 2003] [Ciravegna, 2001]. De plus, l’important volume de données récemment accessibles par le biais des réseaux sociaux, des sites de partage, collaboratifs, etc. a ouvert la voie à de nouvelles applications orientées vers le Web et en particulier le Web Sémantique. [Popescu et al., 2011] et [Sayyadi et al., 2009] s’intéressent à l’extraction d’événements dans les flux sociaux (Twitter notamment). [Nishihara et al., 2009] propose un système de détection des expériences personnelles dans les blogs. On peut également exploiter les méta-données fournies par les utilisateurs, comme le fait [Rattenbury et al., 2007] en analysant les "tags" postés sur Flickr pour en extraire des événements et des lieux dans les photos partagées. Pour finir, citons l’encyclopédie collaborative Wikipedia qui est non seulement une ressource précieuse pour le développement des outils d’EI mais qui bénéficie aussi de ces technologies [Chasin, 2010]. 2.5 Évaluation des systèmes d’EI 2.5.1 Campagnes et projets d’évaluation En parallèle des nombreux systèmes d’EI développés ces dernières années (dont certains ont été présentés dans les sections précédentes), la communauté des chercheurs a mis en place un certain nombre de campagnes d’évaluation telles que ACE, MUC, ESTER, CONLL 93, TAC94, etc. Afin de stimuler le développement des techniques d’extraction d’information et de dégager les pistes de recherche les plus prometteuses, ces campagnes d’évaluation sont menées tant au niveau national qu’international. Celles-ci ont pour but de mettre en place un protocole d’évaluation commun permettant aux experts du domaine de mesurer les performances de leurs outils. Les campagnes définissent généralement plusieurs tâches à accomplir telles que l’extraction d’entités nommées, de relations ou encore d’événements, la résolution de coréférence, etc. Le protocole le plus courant est de fournir un corpus d’entraînement et un corpus de test où les éléments à extraire ont été pré-annotés ainsi qu’un ou plusieurs scripts d’évaluation ("scoring"). Le corpus d’entraînement permet de préparer l’outil à la tâche d’extraction pour pouvoir ensuite s’auto-évaluer sur le corpus de test et estimer son score grâce aux scripts fournis. Une fois leurs systèmes préparés à la tâche d’évaluation, les participants sont évalués et classés par les organisateurs de la campagne. Ces évaluations s’accompagnent le plus souvent de publications d’articles dans lesquels ceux-ci décrivent leur outil et les techniques mises en œuvre. Cela 93. Conference on Computational Natural Language Learning, ❤tt♣✿✴✴✐❢❛r♠✳♥❧✴s✐❣♥❧❧✴❝♦♥❧❧✴ 94. Text Analysis Conference, ❤tt♣✿✴✴✇✇✇✳♥✐st✳❣♦✈✴t❛❝✴ 54 Copyright c 2013 - CASSIDIAN - All rights reserved2.5. Évaluation des systèmes d’EI permet de mettre en avant les nouvelles approches et de faire le point sur les performances de celles déjà connues. Dans le domaine de l’extraction d’information, les campagnes MUC restent les pionnières et les plus connues au niveau international. Créées au début des années 1990 par la DARPA 95, elles constituent les premières initiatives pour encourager l’évaluation des systèmes d’extraction et ont fortement contribué à l’essor de ce domaine. À l’origine destinées au domaine militaire, les sept séries d’évaluation menées ont permis de diversifier les applications. Celles-ci se caractérisent par la tâche d’extraction consistant à remplir un formulaire à partir d’un ensemble de documents en langage naturel. Certains jeux de données de ces campagnes sont actuellement mis à disposition gratuitement. La DARPA a également initié le « Machine Reading Program » (MRP) : projet visant à construire un système universel de lecture de texte capable d’extraire automatiquement la connaissance du langage naturel pour la transformer en représentation formelle. Celui-ci est destiné à faire le lien entre le savoir humain et les systèmes de raisonnement nécessitant ce savoir. Il s’agit pour cela de combiner les avancées en TALN et en IA. Par ailleurs, nous pouvons citer le programme ACE (Automatic Content Extraction) qui, sous la direction du NIST 96, mène également des campagnes d’évaluation. Spécialisées dans l’analyse d’articles de presse, celles-ci évaluent l’extraction d’entités nommées et la résolution de co-référence (mentions d’entités nommées). Aujourd’hui, la campagne TAC (Text Analysis Conference) a pris la suite des actions menées dans le cadre du programme ACE. Toujours à l’échelle mondiale, les campagnes CoNLL (Conference on Natural Language Learning) évaluent et font la promotion des méthodes d’extraction par apprentissage. Celles-ci sont classées parmi les meilleures conférences internationales dans le domaine de l’intelligence artificielle. Ce succès est en partie du au fait que ces conférences sont dirigées par l’ACL (Association of Computational Linguistics), la plus réputée des associations de linguistique et informatique. Celle-ci est aussi à l’origine des conférences Senseval/Semeval spécialisées dans l’évaluation des outils de désambiguïsation sémantique, point crucial en extraction d’information. En Europe, l’association ELRA (European Language Ressources Association) a mis en place les conférences LREC (Language Ressources and Evaluation Conference). Lors de celles-ci les différents acteurs en ingénierie linguistique présentent de nouvelles méthodes d’évaluation ainsi que divers outils liés aux ressources linguistiques. De plus, cette association participe à l’évaluation de systèmes divers en fournissant les corpus et données nécessaires. Enfin, il nous faut citer la campagne française ESTER (Évaluation des Systèmes de Transcription Enrichie d’Émissions Radiophoniques) qui, entre autres activités, évalue le repérage d’entités nommées appliqué à des textes issus de transcription de la parole. Les mesures d’évaluation les plus communément utilisées en extraction d’information sont la précision, le rappel et la F-mesure. Ces métriques peuvent être définies ainsi : Précisioni = nombre d’entités correctement étiquetées i nombre d’entités étiquetées i 95. Defense Advanced Research Projects Agency 96. National Institute of Standards and Technology 55 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information Rappeli = nombre d’entités correctement étiquetées i nombre d’entités i F-mesurei = (1 + β 2 ) · (précisioni · rappeli ) (β 2 · précisioni + rappeli ) où β ∈ R+ β est une facteur de pondération permettant de favoriser soit la précision soit le rappel lors du calcul de la F-mesure. La plupart des travaux pondère de façon égale la précision et le rappel, il est donc plus fréquemment utilisé une F1-mesure définie comme suit : F1-mesurei = 2 · précisioni · rappeli précisioni + rappeli Précisons également que ces métriques sont souvent évaluées lors de la conception des approches afin de favoriser soit la précision soit le rappel de celles-ci en fonction de l’application visée. 2.5.2 Performances, atouts et faiblesses des méthodes existantes Bien que le système d’évaluation actuel ne soit pas parfait, les différentes campagnes d’évaluation menées depuis plus de vingt ans permettent de dresser un bilan des performances des outils développés et de comparer les atouts et faiblesses des différentes approches adoptées. Comme nous l’avons exprimé précédemment, les avancées en EI sont disparates, elles varient en fonction de nombreux paramètres tels que l’objet ciblé (sa nature et sa complexité intrinsèque), l’ancienneté de la tâche en EI, le domaine/genre des textes analysés, les techniques employées, etc. Tout cela, rend très difficile une comparaison quantitative des systèmes développés et un bilan qualitatif nous parait plus approprié. Pour ce faire, nous nous inspirons de [Hogenboom et al., 2011] qui propose une évaluation selon quatre critères : la quantité de données annotées nécessaire, le besoin de connaissances externes, la nécessité d’une expertise humaine et l’interprétabilité des résultats. Nous donnons tout de même, à titre indicatif, quelques résultats (en termes de précision, rappel et F-mesure) issus des campagnes d’évaluation présentées ci-dessus. En premier lieu, les systèmes purement linguistiques, bien que très précis, ont pour principales faiblesses leur taux de rappel moindre et leur coût de développement manuel coûteux. Ceux-ci ne nécessitent pas de corpus annoté mais impliquent un fort besoin en expertise humaine et dépendent souvent de connaissances externes (listes de mots, réseaux lexicaux, bases de connaissances, etc.). Ce dernier point se vérifie particulièrement dans le cas des systèmes à base de règles lexico-sémantiques. Un avantage non-négligeable de ces approches reste leur caractère symbolique permettant, sous réserve d’une expertise en TAL, d’appréhender plus facilement leur machinerie interne, de les adapter après analyse des résultats et d’observer dans la foulée l’impact des modifications. Ce cycle d’ingénierie est devenu plus aisé avec l’apparition des boites à outils pour l’EI (voir la section 2.3) dont certaines proposent des modules d’évaluation en temps réel de la chaine d’extraction. A titre d’exemple, le meilleur participant de la dernière campagne MUC pour l’extraction des événements (tâche Scenario Template de MUC-7) est un système symbolique et obtient les scores suivants : 65% de précision, 42% de rappel et 51% de F-mesure. Sur la tâche de REN, [Appelt, 1999] rapporte un taux d’erreur de 30% inférieur pour les approches symboliques comparées aux méthodes statistiques entièrement supervisées (respectivement environ 96% et 56 Copyright c 2013 - CASSIDIAN - All rights reserved2.6. Problèmes ouverts 93% de F-mesure). Les systèmes à base de connaissances sont également les plus performants pour la résolution de coréférence avec des résultats allant jusqu’à 63% de rappel et 72% de précision. De leur côté, les approches statistiques permettent de couvrir de nombreux contextes d’apparition (leur rappel est généralement plus élevé) mais nécessitent une grande quantité de données annotées pour l’apprentissage du modèle sous-jacent. Cela constitue une réelle contrainte car les corpus d’apprentissage sont inégalement disponibles selon la langue ciblée, le domaine/genre des textes, etc. Quelques travaux présentés plus haut s’intéressent à cette problématique en diminuant la supervision nécessaire dans le développement de tels systèmes : c’est le cas du "clustering" ou des techniques de "bootstrapping". En contrepartie, l’apprentissage statistique nécessite peu ou pas d’expertise humaine et des ressources externes limitées. Toutefois, il reste l’inconvénient que ces approches produisent des modèles de type "boite noire" qui restent à l’heure actuelle difficilement accessibles et interprétables. Enfin, les méthodes statistiques ont montré leur efficacité tout particulièrement en contexte bruité, dans le traitement des transcriptions de l’oral, par exemple. La meilleure approche statistique de la campagne CoNLL obtient une F-mesure de 91% en reconnaissance d’entités nommées. Les méthodes d’extraction par apprentissage statistique testées lors du challenge PASCAL 2005 atteignent une F-mesure de 75% pour la tâche d’extraction de relations. Pour finir, nous avons vu l’intérêt récent pour le développement d’approches hybrides afin d’exploiter les points forts des méthodes précédentes. Même si ce type d’approche n’est pas parvenu pour le moment à éviter tous les écueils pointés ci-dessus, la combinaison des techniques symboliques et statistiques présente plusieurs atouts. L’apprentissage symbolique permet, par exemple, de diminuer l’effort de développement des règles d’un système-expert classique tout en augmentant le rappel de ces approches. On peut également opter pour une construction automatique des ressources linguistiques externes dont dé- pendent beaucoup des outils développés. Après analyse des erreurs d’extraction par méthode statistique, il est aussi intéressant de compléter le système par un ensemble de règles pour gérer les cas statistiquement peu fréquents. L’outil LP2 (ayant remporté le challenge PASCAL 2005) implémente une méthode de déduction de règles d’extraction et obtient une F-mesure de près de 90% pour l’extraction de relations. Par ailleurs, dans le domaine médical, le système CRYSTAL montre une précision de 80% et un rappel de 75%. Toutes approches confondues, les meilleurs systèmes en extraction de relations obtiennent une Fmesure d’environ 75% sur des données de la campagne ACE (ce score passe à 40% lorsque l’annotation des ENs est automatisée). Pour la tâche de remplissage de formulaires, les systèmes développés montent à une F-mesure de 60% (une annotation humaine obtenant 80%). 2.6 Problèmes ouverts Pour conclure cet état de l’art sur l’extraction d’information, nous souhaitons faire le point sur les différents problèmes et challenges restant à résoudre. En effet, même si des progrès considérables ont été accomplis depuis les débuts de l’EI, un certain nombre de problèmes constituent toujours un réel frein à la commercialisation des systèmes existants [Piskorski and Yangarber, 2013]. Tout d’abord, la plupart des solutions sont développées pour un domaine ou un genre de texte particulier et voient leurs performances décroître rapidement face à des textes différents de ce point de vue. Le même problème survient lorsque les outils sont développés à partir de corpus très homogènes (sur la 57 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information forme ou le contenu) et que ceux-ci sont réutilisés sur d’autres corpus de nature plus variée. Ces limites concernent à la fois les méthodes symboliques et statistiques et nécessitent une ré-adaptation constante des techniques. Il a été montré que les performances d’un système d’extraction peuvent varier de 20% à 40% lors du passage à un nouveau domaine/genre de texte [Nadeau and Sekine, 2007]. Des travaux tels que [Chiticariu et al., 2010] ou [Daumé et al., 2010] s’attachent à faciliter la portabilité des outils d’EI d’un domaine à un autre tout en maintenant de bonnes performances. Un autre enjeu est la réduction de l’effort de développement des systèmes, qu’ils soient symboliques ou statistiques. Outre leurs performances, ce point déterminera la commercialisation à grande échelle de ces outils. Du côté des approches à base de règles, cela est abordé par les travaux en apprentissage symbolique [Cellier and Charnois, 2010] tandis que pour réduire la quantité de données annotées nécessaires aux systèmes statistiques, les chercheurs se tournent vers des techniques comme l’apprentissage dit actif ("active learning") [Culotta et al., 2006] [Thompson et al., 1999]. Plus récemment, une solution prometteuse s’offre aux développeurs de systèmes supervisés et semi-supervisés, il s’agit du crowdsourcing : cette nouvelle pratique consiste à mettre à contribution les internautes pour créer du contenu et constitue un bon moyen pour la création de corpus annotés par exemple [Lofi et al., 2012]. Par ailleurs, on s’intéresse à adapter les méthodes d’extraction actuelles à une classification plus fine des entités nommées (villes, ONG, missiles, etc.) [Sekine et al., 2002] [Fleischman and Hovy, 2002]. En effet, la REN telle qu’elle était étudiée lors des premières campagnes d’évaluation atteint aujourd’hui des performances quasi-égales à celles d’un annotateur humain et ne répond que partiellement au besoin réel des utilisateurs finaux. Au sujet de l’évaluation des technologies, nous pouvons souligner, d’une part, le peu de discussions dans la communauté de l’EI au sujet des métriques d’évaluation. En effet, ces métriques proviennent directement de l’évaluation en recherche d’information et s’avèrent, dans certains cas, peu adaptées à l’évaluation des systèmes d’extraction. [Lavelli et al., 2004] propose un résumé critique des méthodologies d’évaluation mises en œuvre depuis les débuts de l’EI. D’autre part, nous pouvons nous demander si les meilleurs résultats obtenus depuis quelques années en EI sont directement issus de l’amélioration des technologies ou s’il s’agit plutôt d’une simplification générale des tâches d’extraction. Un dernier défi provient directement du récent engouement pour le Web Sémantique : il s’agit de tisser des liens entre les communautés de l’extraction d’information et de l’ingénierie des connaissances afin de "sémantiser" les informations extraites. Suivant l’objectif premier du Web Sémantique et du Web de données — favoriser l’émergence de nouvelles connaissances en liant les informations aux connaissances déjà présentes sur la toile — certains travaux s’attèlent à la problématique de création de liens sémantiques entre la sortie des extracteurs et les bases de connaissance existantes (notamment grâce au nommage unique par URI dans les données au format RDF). [Mihalcea and Csomai, 2007] [Ratinov et al., 2011] [Milne and Witten, 2008] sont des exemples de travaux de ce type dont le but est de lier les informations extraites à des concepts Wikipedia. Nous reviendrons plus amplement sur ces approches au chapitre 3.1.2. 2.7 Conclusions La réalisation de cet état de l’art sur l’extraction d’information a révélé un domaine de recherche très étudié étant donné sa relative jeunesse : nous avons pu recenser un nombre important d’approches, 58 Copyright c 2013 - CASSIDIAN - All rights reserved2.7. Conclusions d’applications possibles, de logiciels et plateformes développés ainsi que de campagnes et projets d’évaluation menés jusqu’à nos jours. Les méthodes développées sont historiquement réparties en deux catégories : les symboliques et les statistiques. Les premières, développées manuellement par des experts de la langue, s’avèrent globalement plus précises, tandis que les secondes réalisent un apprentissage sur une grande quantité de données présentent généralement un fort taux de rappel. Parallèlement à cela, nous avons constaté une certaine complémentarité des approches existantes (voir la section 2.5.2) non seulement en termes de précision et rappel de façon générale mais également du point de vue des types d’entité ciblés, du genre textuel, du domaine d’application, etc. Il nous parait en conséquence pertinent de proposer un système d’extraction fondé sur la combinaison de plusieurs approches existantes afin de tirer partie de leurs différentes forces. Pour ce faire, les approches par apprentissage symbolique nous paraissent intéressantes car elles s’avèrent faiblement supervisées et plus flexible que d’autres approches statistiques. Enfin, ce tour d’horizon nous a permis de comparer différents outils et logiciels pour la mise en œuvre de ces approches ainsi que différents jeu de données potentiellement adaptés à l’évaluation de nos travaux. 59 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 2. Extraction automatique d’information 60 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 3 Capitalisation des connaissances Sommaire 3.1 Fusion de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.1.1 Réconciliation de données . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.1.2 Web de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.1.3 Similarité entre données . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.2 Capitalisation appliquée aux événements . . . . . . . . . . . . . . . . . . . . . 66 3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 61 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 3. Capitalisation des connaissances Lorsque la quantité de documents disponibles dépasse un certain seuil, la problématique essentielle devient d’aider les analystes à analyser cette masse de données et à identifier les informations d’inté- rêt sans avoir à parcourir et synthétiser manuellement l’ensemble des documents. Dans ce contexte, les outils d’EI abordés en chapitre 2 se trouvent limités : en effet, la plupart réalise une analyse de l’information parcellaire, mono-document, mono-genre et mono-langue. De plus, comme nous l’avons montré, ces systèmes sont encore, à l’heure actuelle, imparfaits et, même si les progrès dans ce sens ont été signi- ficatifs depuis des années, les erreurs d’analyse ne sont pas rares. Face à cela, il devient de plus en plus nécessaire d’adopter un point de vue global et de concevoir un système de capitalisation des connaissances permettant à la fois d’extraire les informations d’intérêt à partir d’une masse de documents mais également de valoriser les résultats des extracteurs en assurant leur cohérence (éliminer les redondances, contradictions, créer des liens entres les informations, etc.) [Ji, 2010]. Cette problématique, relativement nouvelle, ne bénéficie pas encore d’un intérêt comparable aux deux premiers axes (chapitres 1 et 2) mais elle est l’objet de recherches dans divers domaines tels que la fusion de données, la réconciliation et le nettoyage de données, le Linked Data, la résolution de coréférence, la détection de similarité entre données, etc. Nous présentons dans ce chapitre quelques-unes des méthodes développées explorant différents angles d’un même axe de recherche, à savoir la capitalisation globale et automatisée des connaissances. 3.1 Fusion de données La fusion de données a fait ses débuts aux États-Unis dans les années 70 et a été beaucoup étudiée jusqu’à nos jours dans des domaines divers tels que les applications militaires, de robotique, de transport ou encore en traitement d’images. L’objectif principal de cette discipline est d’optimiser l’acquisition de connaissances en combinant un ensemble d’informations (souvent imparfaites et hétérogènes) provenant de multiples sources plutôt que de les considérer chacune individuellement. Selon l’application, la fusion de données peut servir, d’une part, à reconstituer une situation le plus fidèlement possible à la réalité ou, d’autre part, à améliorer le processus de prise de décision [Desodt-Lebrun, 1996]. Parallèlement aux données à fusionner, la plupart des méthodes de fusion emploie des informations supplémentaires guidant la combinaison. Celles-ci peuvent provenir des données elles-mêmes ou de sources externes et sont par conséquent potentiellement exprimées dans des formalismes distincts. On distingue généralement plusieurs niveaux de fusion selon le type des informations traitées. Nous retiendrons la distinction principale entre la fusion dite numérique manipulant des informations de bas niveau (provenant essentiellement de capteurs) [Bloch, 2005] et la fusion dite symbolique dédiée aux informations de plus haut niveau. C’est dans le cadre de ce second type de fusion (symbolique) qu’apparaissent les travaux introduisant des techniques issues de l’intelligence artificielle et principalement ce que l’on nomme les systèmes à base de connaissance. Ceux-ci sont fondés, d’une part, sur une base de connaissances contenant l’expertise du domaine (les faits ou assertions connus) et, d’autre part, un moteur d’inférence permettant de déduire de nouvelles connaissances à partir de l’existant. Les systèmes à base de connaissance peuvent impliquer différents types de traitement sur les données : les raisonnements temporel et spatial, les déductions et inductions logiques, l’apprentissage automatique, diverses techniques de traitement automatique du langage, etc. La fusion symbolique est souvent choisie pour le traitement des données textuelles et trouve de nombreuses applications dans les systèmes automatiques nécessitant une interaction avec l’être humain. 62 Copyright c 2013 - CASSIDIAN - All rights reserved3.1. Fusion de données Alors que beaucoup de recherches ont été menées dans le cadre de la fusion de données numériques, l’extraction automatique d’information apparait comme une perspective nouvelle permettant d’appliquer ces techniques à un autre type de données et dans un contexte particulièrement incertain et bruité. Ce besoin est fondé sur une constatation principale qui s’avère particulièrement vraie dans le contexte de la veille en sources ouvertes : la même information est rapportée de nombreuses fois par des sources différentes et sous diverses formes. Cela ce traduit notamment par l’utilisation de divers vocabulaires et conventions pour exprimer les mêmes données, des informations plus ou moins à jour et complètes selon les sources, des points de vue différents sur les faits, etc. Dans les sections suivantes, nous abordons plusieurs axes de recherche traitant de cette problématique, à savoir la réconciliation des données, le Web de données et la détection de similarité entre données, puis nous nous centrerons sur l’application des méthodes de capitalisation de connaissances à la reconnaissance des événements. 3.1.1 Réconciliation de données Le réconciliation de données est abordée dans la littérature sous de multiples dénominations, provenant de différentes communautés scientifiques et mettant l’accent sur un aspect particulier de cette problématique : des travaux comme ceux de [Winkler et al., 2006] parlent de record linkage (littéralement traduit par "liaison d’enregistrements ou d’entrées"), on trouve également les termes d’appariement d’objets (object matching), réconciliation de référence [Saïs et al., 2009], duplicate record detection (détection de doublons) [Elmagarmid et al., 2007], désambiguïsation d’entités ou encore résolution de co-référence entre entités [Bhattacharya and Getoor, 2007]. Les premiers sont plutôt issus de la communauté des bases de données, tandis que ces derniers sont généralement employés par les chercheurs en intelligence artificielle (TAL, ingénierie des connaissances, Web sémantique, etc.). Le problème de la réconciliation de données a fait ses débuts dans les années 60 avec les travaux de [Newcombe et al., 1959] en génétique puis avec ceux de [Fellegi and Sunter, 1969] pour le traitement de duplicats dans des fichiers démographiques. La capacité à désambiguïser des dénominations polysé- miques ou d’inférer que deux formes de surface distinctes réfèrent à la même entité est cruciale pour la gestion des bases de données et de connaissances. La méthode la plus simple (mais aussi la moins efficace) pour réconcilier des données est de comparer uniquement leurs représentations textuelles. Les premiers travaux dans ce sens réalisent une réconciliation de référence par paires de mentions et fondée sur la représentation de leurs contextes linguistiques en vecteurs de caractéristiques. Différentes mesures de similarité (voir la section 3.1.3) sont ensuite estimées entre ces vecteurs pour les combiner de fa- çon linéaire par moyenne pondérée, par exemple [Dey et al., 1998]. Plus récemment, d’autres travaux proposent un appariement des descriptions de données plus générique mais toujours basé sur des comparaisons locales [Benjelloun et al., 2006] ou suivent une approche globale exploitant les dépendances existant entre les réconciliations [Dong et al., 2005]. Enfin, [Saïs et al., 2009] propose une approche de réconciliation de référence à base de connaissances et non-supervisée qui combine une méthode logique et une technique numérique. Ces travaux permettent d’exploiter la sémantique exprimée par les données et par leur structure par application d’un ensemble d’heuristiques. Dans le domaine du traitement de données textuelles, lorsque cette tâche est réalisée sans liaison à une base de connaissances externe, elle est souvent appelée résolution de co-référence : les mentions d’entités provenant soit d’un même document soit de plusieurs sont regroupées, chaque groupe référant 63 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 3. Capitalisation des connaissances à une seule et même entité réelle. La tâche de résolution de co-référence sur un ensemble de documents a été adressée par plusieurs chercheurs en commençant par [Bagga and Baldwin, 1999]. Ceux-ci se sont attelés au problème de la co-référence inter-documents en comparant, pour chaque paire d’entités dans deux documents distincts, les vecteurs de mots construits à partir de toutes les phrases contenant les mentions des deux entités. Pour aller plus loin, d’autres approches utilisent des modèles probabilistes [Verykios and Elmagarmid, 1999] mais ceux-ci nécessitent une grande quantité de données annotées pour leur apprentissage. [Wacholder et al., 1997] a développé Nominator l’un des premiers systèmes de REN et de co-référence entre entités fondé sur des mesures de similarité entre contextes d’occurrence. Par ailleurs, un ensemble de travaux récents proposent de représenter l’information extraite de plusieurs documents sous la forme d’un réseau [Ji et al., 2009] où les entités d’intérêt sont vues comme les feuilles d’un graphe et peuvent être liées entre elles par différents types de relations statiques. Ces différentes études visent à regrouper toutes les mentions d’une même entité au sein d’une collection de textes. Toutefois, la construction d’une chaine de co-référence entre entités ne suffit pas à la capitalisation des connaissances car il reste nécessaire de rattacher cette chaine à une entité du monde réel. Il s’agit d’une tâche complexe et il s’avère parfois difficile, même pour un lecteur humain, de dé- terminer à quel objet il est fait référence dans un texte. Dans la plupart des cas, celui-ci identifie la référence d’une entité grâce à des indices issus de son contexte textuel mais aussi et surtout en exploitant l’ensemble du savoir qu’il a déjà acquis par des expériences passées. 3.1.2 Web de données Avec l’essor du Web sémantique de nombreuses recherches proposent d’aller plus loin dans la réconciliation de données et de lier les connaissances entre elles pour créer un Web de données ou Linked Open Data (LOD). Ce liage d’entités est défini comme l’appariement d’une mention textuelle d’une entité et d’une entrée définie dans une base de connaissances. On distingue 3 défis à dépasser pour cette tâche [Dredze et al., 2010] : – Les variations de forme : une seule et même entité est souvent mentionnée sous diverses formes textuelles telles que des abréviations (JFK pour John Fitzgerald Kennedy), des expressions raccourcies (Obama pour Barack Obama), des orthographes alternatives (Osama, Ussamah ou encore Oussama pour désigner l’ancien dirigeant d’Al-Qaïda) et des alias/pseudonymes (Big Apple pour la ville de New York). – Les ambiguïtés référentielles : une seule et même forme de surface peut correspondre à plusieurs entrées dans une base de connaissances. En effet, de nombreux noms d’entités sont polysémiques (Paris est une ville en France mais aussi au Texas). – L’absence de référent : il peut arriver, particulièrement lorsque la quantité de documents traités est conséquente, que la ou les base(s) de connaissances servant de référentiel ne contiennent pas d’entrée pour une ou plusieurs des entités repérées dans les textes (par exemple, le tout nouveau nom donné par les spécialistes à une catastrophe naturelle). De par sa popularité et son exhaustivité, la base de connaissances Wikipédia a largement été utilisée comme base de référence pour le liage de données : ce cas particulier a même reçu le nom de Wikification. Etant donné une chaine de caractères identifiée dans un texte, l’objectif est de déterminer la page Wikipédia à laquelle cette chaine fait référence. Par exemple, pour la phrase suivante "Votre avion dé- collera de JFK", un système de Wification retournera l’identifiant ❤tt♣✿✴✴❢r✳✇✐❦✐♣❡❞✐❛✳♦r❣✴✇✐❦✐✴ 64 Copyright c 2013 - CASSIDIAN - All rights reserved3.1. Fusion de données ❆✪❈✸✪❆✾r♦♣♦rt❴✐♥t❡r♥❛t✐♦♥❛❧❴❏♦❤♥✲❋✳✲❑❡♥♥❡❞②, correspondant à l’aéroport de New York et non la page du 35ème président des États-Unis, par exemple. Les études existantes sur la Wikification diffèrent en fonction des types de corpus traités et des expressions qu’elles cherchent à lier. Par exemple, certains travaux se focalisent sur la Wikification des entités nommées alors que d’autres visent toutes les expressions d’intérêt en cherchant à reproduire un équivalent de la structure de liens de Wikipédia pour un ensemble de textes donné. Le système Wikifier [Milne and Witten, 2008], par exemple, est fondé sur une approche utilisant les liens entre les articles de Wikipédia en tant que données d’apprentissage. En effet, les liens entre les pages de cette base étant créés manuellement par les éditeurs, ils constituent des données d’apprentissage très sûres pour réaliser des choix de désambiguïsation. Par ailleurs, le prototype LODifier [Augenstein et al., 2012] vise à convertir des textes en langage naturel de tout domaine en données liées. Cette approche incorpore plusieurs méthodes de TAL : les entités nommées sont repérées par un outil de REN, des relations normalisées sont extraites par une analyse sémantique profonde des textes et une méthode de désambiguisation sémantique (Word Sense Disambiguation en anglais) permet de traiter les cas de polysémie. L’outil Wikifier y est utilisé pour améliorer la couverture de la REN mais également pour obtenir des liens vers le Web de données grâce aux identifiants DBPedia proposés. Le sens d’un document est finalement consolidé en un graphe RDF dont les noeuds sont connectés à des bases à large couverture du LOD telles que DBPedia et WordNet. Contrairement aux approches précédentes, les travaux de [Dredze et al., 2010] sont facilement adaptables à d’autres bases de connaissances que Wikipédia. Cette approche implémente un apprentissage supervisé fondé sur un ensemble exhaustif de caractéristiques textuelles et s’avère particulièrement efficace dans les cas d’absence de référent. Pour finir, citons l’initiative NLP2RDF 97 qui, également dans l’objectif de créer le Web de données, propose le format d’échange unifié NIF (NLP Interchange Format) afin de favoriser l’interopérabilité des méthodes et systèmes de TAL et l’exploitation de leurs résultats au sein du LOD (via le langage RDF notamment). 3.1.3 Similarité entre données Comme entrevu dans les sections précédentes, les recherches menées en réconciliation de données (au sens large) vont de paire, dans la littérature, avec les travaux conduits autour des calculs de similarité entre ces données. La multitude des calculs de similarité existants faisant que nous ne pourrons les parcourir de façon exhaustive ici, nous choisissons de les présenter par catégories et ce en faisant référence à des états de l’art existants, spécialisés sur cette problématique. Nous avons retenu deux d’entre eux très complets à savoir [Elmagarmid et al., 2007] et [Bilenko et al., 2003]. Les approches de calcul de similarité procèdent généralement en deux étapes : une phase dite de préparation des données suivie d’une phase de fusion des champs référant à une même entité. En effet, hétérogènes du point de vue de leur fond et de leur forme, les données manipulées nécessitent d’être pré-traitées dans le but de les stocker de façon la plus uniforme possible dans les bases de données. Cela consiste généralement à réduire au maximum leur diversité structurelle en les convertissant dans un format commun et normalisé. Vient, dans un second temps, l’étape de comparaison des données entre elles et d’estimation de leur similarité. Une grande quantité de méthodes ont été proposé pour ce faire : celles-ci varient sur plusieurs critères (type de données visé, niveau de comparaison, etc.) qui donnent 97. ❤tt♣✿✴✴♥❧♣✷r❞❢✳♦r❣✴❛❜♦✉t 65 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 3. Capitalisation des connaissances à des catégorisations différentes. [Elmagarmid et al., 2007] distingue les mesures de similarité au niveau caractère (distance d’édition, affine gap distance, distance de Smith-Waterman, distance de Jaro, Q-Grams) et les métriques basées sur les tokens (chaines atomiques, WHIRL, Q-Grams avec TF.IDF). [Bilenko et al., 2003] différencie les mesures statiques (distance d’édition, métrique de Jaro et ses variantes, distances basées sur les tokens et hybrides) de celles à base d’apprentissage (classifieurs SVM entrainés avec des vecteurs de caractéristiques, affine gap distance, modèles d’apprentissage avec distance de Levenstein). Pour finir, nous pouvons citer les recherches de [Moreau et al., 2008] définissant un modèle générique en vue de faciliter la combinaison de différentes mesures de similarité au sein d’un même système. 3.2 Capitalisation appliquée aux événements Selon [Quine, 1985], deux mentions d’événement co-réfèrent si elles partagent les mêmes propriétés et participants. Contrairement à la co-référence entre entités dites simples, celle entre événements s’avère plus complexe principalement car les mentions d’événements présentent des structures linguistiques plus riches et variées que les mentions d’entités simples. De plus, le premier type de tâche est réalisé au niveau du mot ou du groupe de mots alors que la résolution de co-référence entre événements doit s’effectuer à un niveau plus élevé (phrase, discours). Une partie des approches existantes pour répondre à ce problème repose sur des méthodes d’apprentissage supervisées explorant diverses caractéristiques linguistiques des textes [Humphreys et al., 1997] [Bagga and Baldwin, 1999] [Naughton et al., 2006]. [Lee et al., 2012], par exemple, propose une approche globale par apprentissage pour la résolution de co-référence, réalisée de façon conjointe entre entités et événements, au sein d’un seul ou de plusieurs documents. Celle-ci est fondée sur une méthode itérative de regroupement exploitant un modèle de régression linéaire appris sur ces données. Toutefois, la résolution de co-référence entre événements impliquant d’explorer une grande quantité de caractéristiques linguistiques, annoter un corpus d’apprentissage pour cette tâche requiert un effort de développement manuel important. De plus, étant donné que ces modèles reposent sur des décisions locales d’appariement, ils ne peuvent généralement pas capturer des relations de co-référence au niveau d’un sujet défini ou sur une collection de plusieurs documents. En réponse à cela, sont créés des systèmes comme Resolver [Yates and Etzioni, 2009] qui permet d’agréger des faits redondants extraits (par l’outil d’extraction d’information TextRunner) grâce à un modèle non-supervisé estimant la probabilité qu’une paire de mentions coréfèrent en fonction de leur contexte d’apparition (exprimé sous forme de n-tuples). Par ailleurs, [Chen and Ji, 2009] propose de représenter les co-références entre événements par un graphe pondéré non-orienté où les nœuds représentent les mentions d’événement et les poids des arêtes correspondent aux scores de co-référence entre deux des mentions. La résolution de co-référence est ensuite réalisée comme un problème de clustering spectral du graphe mais le problème le plus délicat reste l’estimation des similarités en elles-mêmes. Il nous faut noter enfin les travaux de [Khrouf and Troncy, 2012] explorant la problématique de la réconciliation des événements dans le Web de données. En effet, partant du constat que le nuage LOD contient un certain nombre de silos d’événements possédant leurs propres modèles de données, ceux-ci proposent d’aligner cet ensemble de descriptions d’événements grâce à diverses mesures de similarité et de les représenter avec un modèle commun (l’ontologie LODE présentée en section 1.3.1.2). 66 Copyright c 2013 - CASSIDIAN - All rights reservedPour finir, concernant l’évaluation de cette problématique, nous pouvons mentionner la campagne d’évaluation ACE (présentée en section 2.5.1) mettant à disposition des données d’évaluation pour la tâche Event Detection and Recognition (VDR). Toutefois, son utilisation s’avère limitée car cette ressource ne contient que des annotations de co-référence intra-documents et pour un nombre restreint de types d’événements (Life, Movement, Transaction, Business, Conflict, Contact, Personnel and Justice). 3.3 Conclusions La réalisation de cet état de l’art a mis en exergue une suite logique à nos travaux sur l’extraction automatique d’information, à savoir la problématique du passage du texte à la connaissance proprement dite. Comme nous avons pu le voir, celle-ci a donné lieu à diverses recherches au sein de plusieurs communautés de l’IA, chacune d’elles manipulant sa propre terminologie adaptée à ses propres besoins. Ses divergences de vocabulaire n’empêchent pas de voir la place importante réservée à la capitalisation des connaissances au sein des recherches actuelles que ce soit en fusion de données, extraction d’information ou Web sémantique. Certains de ces travaux nous paraissent convenir à nos objectifs tels que [Chen and Ji, 2009] avec leur représentation en graphe de l’ensemble des connaissances (bien adaptée aux travaux dans le cadre du Web sémantique et du WebLab notamment), [Khrouf and Troncy, 2012] pour leur approche globale autour de plusieurs bases de connaissances et enfin, les différentes similarités entre données qui peuvent permettre de réconcilier des extractions. Les enseignements tirés de ce tour d’horizon ont été exploités lors de l’élaboration de notre approche d’agrégation des événements (voir le chapitre 6). Ce chapitre clôture notre partie état de l’art sur les différents domaines de recherche abordés par cette thèse. 67 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 3. Capitalisation des connaissances 68 Copyright c 2013 - CASSIDIAN - All rights reservedDeuxième partie Contributions de la thèse 69 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction Cette seconde partie présente les contributions réalisées durant cette thèse en réponse à notre problé- matique de recherche et de façon adaptée aux conclusions de l’état de l’art réalisé. Nous y proposons, dans le chapitre 4 Modélisation des connaissances du domaine, notre première contribution : un modèle de représentation des connaissances conçu en accord avec les besoins de notre cadre applicatif (le ROSO et le Media mining) et avec les observations faites au chapitre 1 (sur les modèles et approches existantes). Cette première proposition comprend, d’une part, une modélisation des événements en plusieurs dimensions et, d’autre part, une implémentation de ce modèle au sein d’une ontologie de domaine, nommée WOOKIE, élaborée durant nos recherches. Dans un second chapitre (5 Extraction automatique des événements), les contributions liées à notre axe de recherche Extraction d’information seront exposées. Nous commencerons par la conception d’une approche de reconnaissance d’entités nommées pour l’anglais et le français et implémentée grâce à la plateforme GATE. Puis, le cœur du chapitre sera dédié à l’élaboration d’une approche mixte pour l’extraction automatique des événements dans les textes selon le modèle de connaissances défini auparavant. Celle-ci est fondée sur deux techniques actuelles issue de la littérature en extraction d’information : une première méthode symbolique à base de règles linguistiques contextuelles et une seconde fondée sur un apprentissage de patrons d’extraction par fouille de motifs séquentiels fréquents. L’ensemble des méthodes exposées seront accompagnées d’exemples tirés de données réelles afin de faciliter leur compréhension. Enfin, le dernier chapitre de cette partie (6 Agrégation sémantique des événements) sera centré sur un processus d’agrégation sémantique des événements destiné à assurer la création d’un ensemble de connaissances cohérent et d’intérêt pour l’utilisateur. Cela sera réalisé en différentes phases (conformément aux observations faites durant l’état de l’art) : une première étape de normalisation des différentes extractions, suivie d’une approche permettant d’estimer une similarité sémantique multi-niveaux entre événements et un processus d’agrégation sémantique fondé sur une représentation en graphe des connaissances. 71 Copyright c 2013 - CASSIDIAN - All rights reservedIntroduction 72 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 4 Modélisation des connaissances du domaine Sommaire 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.2 Notre modèle d’événement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.2.1 La dimension conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.2 La dimension temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.3 La dimension spatiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.2.4 La dimension agentive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.3 WOOKIE : une ontologie dédiée au ROSO . . . . . . . . . . . . . . . . . . . 78 4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 73 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 4. Modélisation des connaissances du domaine 4.1 Introduction Ce chapitre détaille la première contribution proposée durant nos travaux de thèse : une modélisation des événements ainsi qu’une ontologie de domaine nommée WOOKIE. Celles-ci ont été élaborées en fonction des conclusions de notre état de l’art et de façon adaptée à notre problématique, à savoir l’extraction automatique des événements dans le cadre du ROSO. Nous proposons, tout d’abord, le modèle d’événement défini pour servir de guide à l’ensemble de notre processus de capitalisation des connaissances. Un événement est représenté selon quatre dimensions (conceptuelle, temporelle, spatiale et agentive) pour chacune desquelles nous avons défini des propriétés bien spécifiques. Enfin, nous présentons l’élaboration de notre ontologie de domaine au regard de la littérature et en y intégrant notre modélisation des événements. Nous terminons ce chapitre par un bilan des forces et faiblesses de notre contribution. 4.2 Notre modèle d’événement Nous prenons pour point de départ la définition de Krieg-Planque ("un événement est une occurrence perçue comme signifiante dans un certain cadre") qui apparaît bien adaptée à nos travaux. Cette définition restant très théorique, il convient d’expliciter comment un événement est exprimé au sein des dépêches de presse (celles de l’AFP 98, par exemple). Après observation de plusieurs dépêches, celles-ci semblent généralement être centrées sur un événement principal, celui-ci étant le plus souvent résumé dans le titre et explicité tout au long de l’article (en faisant parfois référence à d’autres événements). Cette description de l’événement tout au long de la dépêche, est constituée de plusieurs sous-événements ("mentions d’événement" dans le modèle ACE) qui contribuent à la "mise en intrigue" mentionnée auparavant. Ces mentions d’événements sont généralement composées d’un terme déclencheur (dit aussi "nom d’événement" ou "ancre") associé à une ou plusieurs autres entités d’intérêt ("arguments" dans le modèle ACE) telles que des circonstants spatio-temporels (date et lieu de l’événement) et des participants (acteurs, auxiliaires, instruments, etc.). L’objectif de nos travaux est d’extraire automatiquement les mentions d’événement pertinentes pour notre application pour ensuite agréger celles qui réfèrent à un seul et même événement dans la réalité. Afin de proposer une définition formelle des événements, nous nous fondons également sur les travaux de [Saval et al., 2009] décrivant une extension sémantique pour la modélisation d’événements de type catastrophes naturelles. Les auteurs définissent un événement E comme la combinaison d’une propriété sémantique S, d’un intervalle temporel T et d’une entité spatiale SP. Nous adaptons cette modé- lisation à notre problématique en y ajoutant une quatrième dimension A pour représenter les participants impliqués dans un événement et leurs rôles respectifs. Par conséquent, un événement est représenté comme suit : Définition 1. Un événement E est modélisé comme E =< S, T, SP, A > où la propriété sémantique S est le type de l’événement (que nous appellerons dimension conceptuelle), l’intervalle temporel T est la date à laquelle l’événement est survenu, l’entité spatiale SP est le lieu d’occurrence de l’événement et A est l’ensemble des participants impliqués dans E associés avec le(s) rôle(s) qu’ils tiennent dans E. Exemple 1. L’événement exprimé par "M. Dupont a mangé au restaurant Lafayette à Paris en 1999" est représenté comme (Manger, 1999, Paris, M. Dupont). 98. Agence France Presse 74 Copyright c 2013 - CASSIDIAN - All rights reserved4.2. Notre modèle d’événement Les sections suivantes décrivent comment chaque dimension de l’événement est modélisée. Enfin, dans nos travaux, le "cadre" mentionné par Krieg-Planque est défini par l’ontologie de domaine WOOKIE 99 (voir la section 4.3) et plus précisément par la spécification de la classe événement ("Event") en différentes sous-classes et propriétés. Il détermine quels sont les entités et événements d’intérêt pour notre application. 4.2.1 La dimension conceptuelle La dimension conceptuelle S d’un événement correspond au sens véhiculé par le nom porteur de cet événement. En effet, comme le souligne [Neveu and Quéré, 1996], l’interprétation d’un événement dépend étroitement de la sémantique exprimée par les termes employés pour nommer cet événement. Cette dimension équivaut à la propriété sémantique des événements évoquée par [Saval et al., 2009] et représente le type de l’événement, c’est-à-dire sa classe conceptuelle au sein de notre ontologie de domaine. C’est la taxonomie des événements au sein de WOOKIE qui constitue le support principal de cette dimension conceptuelle. Nous avons défini pour notre application environ 20 types d’événement d’intérêt pour le renseignement militaire regroupés sous le concept de MilitaryEvent. Les différentes sous-classes d’événement sont les suivantes : – AttackEvent : tout type d’attaque, – BombingEvent : les attaques par explosifs, – ShootingEvent : les attaques par armes à feu, – CrashEvent : tous les types d’accidents, – DamageEvent : tous les types de dommages matériels, – DeathEvent : les décès humains, – FightingEvent : les combats, – InjureEvent : tout type d’événement entrainant des blessés, – KidnappingEvent : les enlèvements de personnes, – MilitaryOperation : tout type d’opération militaire, – ArrestOperation : les arrestations, – HelpOperation : les opérations d’aide et de secours, – PeaceKeepingOperation : les opérations de maintien de la paix, – SearchOperation : les opérations de recherche, – SurveillanceOperation : les opérations de surveillance, – TrainingOperation : les entrainements, – TroopMovementOperation : les mouvements de troupes, – NuclearEvent : tout type d’événement nucléaire, – TrafficEvent : tout type de trafic illégal. Cette taxonomie a été essentiellement constituée en nous inspirant des modélisations existantes dans le domaine telles que celles présentées en section 1.3.3. Mais également par observation des différents types d’événements rapportés dans des dépêches de presse sur des thèmes tels que les guerres en Afghanistan et en Irak ou encore les diverses attaques terroristes dans le monde. 99. Weblab Ontology for Open sources Knowledge and Intelligence Exploitation 75 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 4. Modélisation des connaissances du domaine 4.2.2 La dimension temporelle Pour la représentation des entités temporelles extraites nous utilisons le "Time Unit System" (TUS) proposé par [Ladkin, 1987]. Contrairement à la majorité des modèles théoriques dédiés à la logique temporelle [Fisher et al., 2005], ce formalisme s’avère plus applicable à des situations réelles de traitement des entités temporelles, notamment, par sa proximité avec les systèmes calendaires communément utilisés. Il s’agit d’une approche hiérarchique et granulaire qui représente toute expression temporelle en un groupe de granules (c’est-à-dire des unités temporelles indivisibles). Un granule (ou unité de temps) est une séquence finie d’entiers organisés selon une hiérarchie linéaire : année, mois, jour, heure, etc. De plus, ce formalisme introduit la notion de BTU (Basic Time Unit) qui correspond au niveau de granularité choisi en fonction de la précision nécessitée par une application (e.g. les jours, les secondes, etc.). Par exemple, si le BTU est fixé à heure, chaque unité temporelle sera exprimée comme une séquence d’entiers i telle que : i = [année,mois,jour,heure]. De plus, TUS définit la fonction maxj ([a1, a2, ..., aj−1]) donnant la valeur maximale possible à la position j pour qu’une séquence temporelle soit valide en tant que date. Cet opérateur est nécessaire car, selon notre actuel système calendaire, le granule jour dé- pend des granules mois et année. [Ligeza and Bouzid, 2008] définit toutes les valeurs maximales pour le granule jour de la façon suivante : – max3([g1, 2]) = 29 lorsque a1 est une année bissextile – max3([g1, 2]) = 28 lorsque a1 est une année non-bissextile – max3([g1, g2]) = 31 quelque soit g1 et lorsque g2 ∈ {1, 3, 5, 7, 8, 10, 12} – max3([g1, g2]) = 30 quelque soit g1 et lorsque g2 ∈ {4, 6, 9, 11} Une date est dite légale lorsqu’elle est valide au regard de cet opérateur et plus généralement du système calendaire courant et elle est dite illégale dans le cas contraire. Pour notre application, nous choisissons un BTU jour correspondant à la précision maximale des dates extraites. Par conséquent, toute expression temporelle i aura la forme suivante : i = [année,mois,jour]. Par exemple, [2010,09,19] représente un intervalle de temps qui débute le 18 septembre 2012 à minuit et termine un jour plus tard (ce qui équivaut à un BTU). De plus, les entités temporelles extraites peuvent s’avérer plus ou moins précises. Dans certains cas, les expressions de temps peuvent être imprécises à l’origine (e.g. "en Mai 2010") et, dans d’autres cas, l’imprécision peut être causée par une erreur d’extraction. Pour représenter ces entités floues, nous introduisons le symbole ∅ défini comme le manque d’information au sens général. Soit T = [g1, g2, g3] une expression temporelle : Définition 2. Expression temporelle complète : T est complète lorsque ∀i∈{1,2,3} , gi 6= ∅ Définition 3. Expression temporelle incomplète : T est incomplète lorsque ∃i∈{1,2,3} , gi = ∅ Nous listons ci-dessous toutes les formes possibles que peuvent revêtir les dates extraites une fois exprimées avec le formalisme TUS ainsi que des exemples : – [year, month, day], e.g. [2011, 12, 14] ; – [year, month] e.g. [2011, 12, ∅] ; – [month, day], e.g. [∅, 12, 14] ; – [year] e.g. [2011, ∅, ∅] ; – [month] e.g. [∅, 12, ∅] ; 76 Copyright c 2013 - CASSIDIAN - All rights reserved4.2. Notre modèle d’événement – [day] e.g. [∅, ∅, 14]. Enfin, le modèle TUS introduit l’opérateur convexify permettant la représentation des intervalles temporels convexes. Prenant pour paramètres deux intervalles primaires i et j, convexify(i, j) retourne le plus petit intervalle de temps contenant i et j. Par exemple, convexify([2008], [2011]) correspond à l’intervalle de 3 ans entre le premier jour de l’année 2008 et le dernier jour de 2011. Nous utilisons cet opérateur pour exprimer de façon unifiée les périodes de temps extraites des textes et permettre ainsi des calculs temporels grâce au modèle TUS. Par conséquent, une extraction telle que "from 2001 to 2005" est normalisé sous la forme convexify([2001], [2005]). 4.2.3 La dimension spatiale Pour notre application, nous choisissons de représenter les entités spatiales comme des aires géographiques et d’utiliser les relations topologiques du modèle RCC-8 pour leur agrégation. En effet, ce modèle s’avère mieux adapté à la comparaison d’entités spatiales que ceux à base de points et fondés sur les coordonnées géographiques. Comme dans le cas des entités temporelles, le raisonnement spatial nécessite d’opérer sur des objets non-ambigus et nous devons par conséquent préciser géographiquement tous les lieux extraits par notre système. Dans le cadre du WebLab, nous nous intéressons notamment à la désambiguïsation d’entités spatiales dans le but d’effectuer des traitements plus avancés comme la géolocalisation ou l’inférence spatiale [Caron et al., 2012]. Cette étape est réalisée en associant un identifiant GeoNames 100 unique (une URI) à chaque lieu extrait. Utiliser une base géographique comme GeoNames a plusieurs avantages : tout d’abord, il s’agit d’une base open-source et sémantique, par conséquent bien adaptée à une intégration au sein du WebLab ; de plus, en complément des coordonnées géographiques, cette ressource fournit des relations topologiques entre lieux, comme par exemple des relations d’inclusion. Nous utilisons, plus précisément, les trois propriétés suivantes pour l’agrégation des événements (voir la section 6.3.3) : – la propriété "children" réfère à une inclusion administrative ou physique entre deux entités géographiques ; – la propriété "nearby" relie deux entités qui sont géographiquement proches l’une de l’autre ; – la propriété "neighbour" est utilisée lorsque deux entités géographiques partagent au moins une frontière. La section 6.3.3 détaille comment nous utilisons ces relations topologiques pour l’agrégation des entités spatiales. 4.2.4 La dimension agentive Comme dit précédemment, tous les participants d’un événement et leurs rôles respectifs sont repré- sentés formellement par la dimension A. Nous définissons cette dimension de l’événement comme un ensemble A = (Pi , rj ) où chaque élément est un couple composé d’un participant pi et d’un rôle rj et où i et j ∈ N. Notre modèle ne limite pas la nature du champ "participant" (chaîne de caractères, entité nommée, nom propre/commun, etc.) pour rester le plus générique possible. Toutefois, dans notre application un participant correspond concrètement à une entité nommée de type Personne ou Organisation ayant été extraite et liée automatiquement à l’événement dans lequel elle est impliquée. Les différents 100. ❤tt♣✿✴✴✇✇✇✳❣❡♦♥❛♠❡s✳♦r❣✴ 77 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 4. Modélisation des connaissances du domaine types de rôles possibles ne sont également pas restreints ici car cela est fortement corrélé à l’application et aux capacités des extracteurs. Notre méthode d’extraction (voir la section 5.4) n’ayant pas été conçue pour déterminer le rôle joué par un participant dans un événement, cet aspect ne sera pas traité ici. 4.3 WOOKIE : une ontologie dédiée au ROSO Afin de définir précisément quelles sont les informations d’intérêt pour notre application, nous avons développé une ontologie de domaine nommée WOOKIE constituant la base de notre système de capitalisation des connaissances. Celle-ci a été créée de façon collaborative et a pour but de représenter les concepts de base nécessaires aux diverses applications du domaine. Cet aspect collaboratif (grâce notamment au logiciel WebProtégé) constitue un point important car il nous a permis de mettre en commun les visions de plusieurs membres de l’équipe IPCC afin de mieux cerner les besoins des opérationnels du renseignement. De plus, cette ontologie est implémentée au format OWL 101 selon les recommandations du W3C102 pour la représentation des connaissances au sein du Web Sémantique. Notre objectif étant de développer une ontologie à taille raisonnable mais générique pour le renseignement militaire, nous avons tout d’abord mené quelques recherches pour faire le point sur les ontologies existantes. En effet, il nous est apparu intéressant de pouvoir reprendre tout ou partie d’une modélisation déjà disponible. WOOKIE a donc été élaborée suite à un état de l’art approfondi de la littérature du domaine et des ontologies existant à l’heure actuelle (dont une partie est présentée dans le chapitre 1). Nous avons commencé par examiner les ontologies générales (dites "de haut niveau") les plus connues et utilisées telles que SUMO 103, PROTON 104, BFO 105, DOLCE 106 ou encore COSMO 107. Ces ontologies sont modélisées à divers niveaux : elles définissent des concepts de haut niveau ou "meta-concepts" (pouvant servir de base à l’organisation d’encyclopédies par exemple) mais aussi des spécialisations des concepts Lieu et Organisation qui se sont avérées particulièrement intéressantes pour le développement de notre ontologie. Puis, d’autres modélisations plus spécifiques nous ont été utiles, telles que des modélisations spécifiques au domaine militaire (voir la section 1.3.3), des ontologies spécialisées dans la description des évènements (voir la section 1.3). Ces différentes observations ont montré qu’aucune des ontologies trouvées ne correspondaient parfaitement au modèle de connaissances voulu et qu’il n’était donc pas adéquat de reprendre une de ces représentations en l’état. Toutefois, nous nous sommes inspirés de ces modélisations tout au long de la construction de WOOKIE et avons veillé à maintenir des équivalences sémantiques avec les ontologies existantes. Le développement de notre ontologie de domaine a été guidé par les méthodologies de la littérature telles que [Noy and Mcguinness, 2001] [Mizoguchi, 2003a]. Celles-ci nous ont permis d’organiser notre travail en plusieurs étapes que nous détaillons ci-après. Nous avons commencé par concevoir une taxonomie de concepts de haut niveau constituant la base de notre modélisation. Pour cela, nous avons accordé une attention particulière aux standards OTAN car ils définissent les objets d’intérêt et leurs propriétés pour le renseignement militaire. Ces standards demeurant trop techniques et détaillés, nous avons fait le choix de nous concentrer sur les catégories de 101. Ontology Web Language, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴❚❘✴♦✇❧✲❢❡❛t✉r❡s✴ 102. World Wide Web Consortium, ❤tt♣✿✴✴✇✇✇✳✇✸✳♦r❣✴ 103. Suggested Upper Merged Ontology 104. PROTo ONtology 105. Basic Formal Ontology 106. Descriptive Ontology for Linguistic and Cognitive Engineering 107. Common Semantic MOdel 78 Copyright c 2013 - CASSIDIAN - All rights reserved4.3. WOOKIE : une ontologie dédiée au ROSO l’intelligence définies par le STANAG 2433, connues sous le nom de "pentagramme du renseignement" (voir la figure 4.1). FIGURE 4.1 – Le pentagramme du renseignement Ce pentagramme reprend les éléments centraux du domaine du renseignement militaire et les définit comme ci-dessous. – Le concept Units y est défini comme tout type de rassemblement humain partageant un même objectif, pouvant être hiérarchiquement structuré et divisé en sous-groupes. Il s’agit à la fois des organisations militaires, civiles, criminelles, terroristes, religieuses, etc. – Le concept Equipment désigne toute sorte de matériel destiné à équiper une personne, une organisation ou un lieu pour remplir son rôle. Il peut s’agir d’équipement militaire ou civil, terrestre, aérien, spatial ou sous-marin. – Le concept Places regroupe les points ou espaces terrestres ou spatiaux, naturels ou construits par l’homme, pouvant être désignés par un ensemble de coordonnées géographiques. – Le concept Biographics désigne les individus et décrit un certain nombre de propriétés associées telles que des éléments d’identification, des informations sur la vie sociale et privée, un ensemble de relations avec d’autres individus ou organisations, etc. – Le concept Events décrit toute occurrence d’un élément considéré comme ayant de l’importance. Un événement peut être divisé en plusieurs sous-événements. Toutefois, les standards OTAN ne détaillent pas les sous-classes du pentagramme et les diverses propriétés de classes évoquées doivent être triées et réorganisées. Nous avons donc développé notre ontologie de haut en bas (approche descendante ou "top-down"), en partant des concepts plus généraux vers les plus spécifiques. Nous avons effectué cette spécialisation en conservant les classes intéressantes des autres ontologies observées. Pour ce faire, nous nous sommes inspirés de la méthodologie de construction d’une ontologie proposée par [Noy and Mcguinness, 2001]. La création de sous-classes a été guidée par le contexte du renseignement militaire et ses éléments d’intérêt. La taxonomie complète des classes de WOOKIE est donnée en annexe A. Pour la classe Equipment, nous nous sommes limités à décrire les différents types de véhicules et d’armes. La classe Person 79 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 4. Modélisation des connaissances du domaine est liée par équivalence au concept Person dans l’ontologie FOAF 108 mais n’a pas nécessité plus de pré- cision. En ce qui concerne le concept Unit, nous avons choisi de distinguer deux sous-classes Group et Organisation afin de différencier les groupements de personnes, point important dans le domaine visé. La classe Place a également été sous-typée en prenant en compte les besoins militaires, notamment par l’aspect stratégique des sous-classes du concept Infrastructure. Enfin, la modélisation de la classe Event s’est avérée une tâche essentielle compte tenu de l’importance de ces entités dans le renseignement et la veille militaire. Nous avons pour cela réservé plus de temps à la spécification de la classe MilitaryEvent, c’est-à-dire au choix et à l’organisation des différentes sous-classes en prenant en compte les observations préalables. La taxonomie des événements spécifiques au ROSO est présentée en annexe B. Par la suite, parallèlement aux relations hiérarchiques, nous avons liés les concepts de l’ontologie entre eux par des relations sémantiques (object properties). Il s’agit de propriétés ayant pour co-domaine un concept de l’ontologie. Celles-ci ont également été choisies en fonction des besoins du renseignement militaire et en concertation avec les membres de notre équipe. Plusieurs liens sont modélisés entre les personnes tels que des liens familiaux, de connaissance, des liens hiérarchiques, etc. (isFamilyOf, isSpouseOf, isFriendOf, isColleagueOf, etc.). Nous avons également créé des relations entre personnes et organisations (hasEmployee), entre organisations et équipements (producesEquipment, sellsEquipment) ou encore entre lieux et personnes (bornIn, diedIn), etc. Enfin, la classe Event est en relation avec tous les autres éléments du pentagramme conformément à notre modèle d’événement (voir la section 4.2). Ainsi par exemple, un événement implique des participants de type Person ou Unit (involves) ainsi qu’un instrument appartenant à la classe Equipment (hasEquipment) et se déroule dans un lieu associé à la classe Place (takesPlaceAt). Un événement peut également être relié à d’autres événements par des relations d’antécédence, succession, cause, conséquence, etc. (hasAssociatedEvent, causes, follows, etc.). Une quatrième étape a été d’attribuer à chaque classe un ensemble de propriétés permettant de les définir plus précisément en leur associant une valeur particulière. Cette valeur peut être une chaine de caractères, un nombre, une date, un booléen, etc. Comme nous l’avons déjà précisé plus haut, ces attributs sont héréditaires : ceux de la classe-mère sont automatiquement transmis aux classes-filles. Les 5 classes de plus haut niveau possèdent les attributs picture, pour leur associer une image, et alias, qui associé à la propriété rdfs :label permet d’indiquer leur(s) nom(s) alternatif(s). La classe Person possède un certain nombre d’attributs tels que la nationalité, la profession, l’âge, l’adresse postale, l’adresse électronique, les dates de naissance et de décès, etc. La classe Unit est également caractérisée par des adresses postale et électronique ainsi que des coordonnées téléphoniques. La classe Place n’a pas nécessité d’attributs. Le concept Equipment possède lui des attributs essentiellement liés à des caractéristiques techniques telles que la couleur, les dimensions, la vitesse ou encore à des informations d’identification comme la marque, le modèle, la plaque d’immatriculation, l’année de production, etc. Enfin, pour la classe Event, nous avons précisé les dates de début et fin, la durée ainsi que le nombre de victimes et de décès engendrés. La totalité des attributs de concepts est donnée en annexe D). Pour terminer, nous avons précisé les différents propriétés et attributs définis en spécifiant certaines contraintes et axiomes dans l’ontologie WOOKIE. Comme permis par la spécification OWL, des liens entre propriétés de type owl :inverseOf ont été implémentés pour indiquer que telle propriété porte un sens contraire à telle autre propriété. Par exemple, la relation isEmployeeOf (qui lie une personne à l’organisation à laquelle elle appartient) est l’inverse de hasEmployee. Par ailleurs, nous avons utilisé, le cas échéant, les restrictions symmetric/assymetric, irreflexive et transitive des modèles OWL et OWL2. La propriété hasFriend est, par exemple, symétrique et non-réflexive. La relation isSuperiorTo entre 108. Friend Of A Friend, ❤tt♣✿✴✴✇✇✇✳❢♦❛❢✲♣r♦❥❡❝t✳♦r❣✴ 80 Copyright c 2013 - CASSIDIAN - All rights reserved4.4. Conclusions deux membres d’une organisation est quant à elle transitive. Enfin, comme mentionné en section 1.3.1.2, WOOKIE intègre des liens sémantiques avec d’autres ontologies sous forme d’axiomes tels que des équivalences de classes (owl :equivalentClass) ou des relations de subsomption (rdfs :subClassOf). Ainsi, le concept Person de WOOKIE est équivalent au concept Person de l’ontologie FOAF et la classe Place de WOOKIE est un sous-type de Feature dans l’ontologie GeoNames. Par ailleurs, le concept d’événement dans notre ontologie équivaut sémantiquement au concept Event de l’ontologie LODE, par exemple. 4.4 Conclusions L’ontologie que nous venons de décrire constitue le modèle de connaissances qui servira de guide à notre approche d’extraction et de capitalisation des connaissances. Les principaux atouts de cette modélisation sont les suivants : tout d’abord, elle se fonde sur des modèles reconnus (ACE et DUL pour les événements et le modèle TUS et les relations topologiques RCC-8 pour la représentation spatiotemporelle). De plus, notre ontologie a été conçue en accord avec les besoins du ROSO (taxonomie de classes et propriétés) et intègre de nombreux liens sémantiques vers d’autres ontologies afin de maintenir une interopérabilité au sein du Web sémantique. Celle-ci présente toutefois quelques limites et nous envisageons des perspectives d’amélioration telles que l’intégration d’une cinquième dimension que nous appellerons "contextuelle" afin de représenter des éléments du contexte linguistique et extra-linguistique (indices de modalité, confiance, temporalité, propagation spatiale, etc.). Par ailleurs, nous souhaitons approfondir la représentation des rôles au sein de la dimension agentive en étudiant, par exemple, le modèle SEM (voir le chapitre 1.3.1.2). 81 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 4. Modélisation des connaissances du domaine 82 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5 Extraction automatique des événements Sommaire 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2 La plateforme GATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3 Extraction d’entités nommées . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.1 Composition de la chaine d’extraction . . . . . . . . . . . . . . . . . . . 87 5.3.2 Développement du module de règles linguistiques . . . . . . . . . . . . . 88 5.4 Extraction d’événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.4.1 Approche symbolique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.4.2 Apprentissage de patrons linguistiques . . . . . . . . . . . . . . . . . . . 97 5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 83 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements 5.1 Introduction Une fois notre modèle de connaissances établi, nous proposons de concevoir une approche permettant de reconnaitre automatiquement dans un ensemble de textes les différentes informations d’intérêt pour peupler la base de connaissances (créer des instances des différentes classes de l’ontologie WOOKIE et les liens existants entre ces instances). Ce chapitre présente notre seconde contribution : un système d’extraction automatique d’événements pour la veille en sources ouvertes. Celui-ci ayant été essentiellement élaboré grâce à la plateforme GATE, nos critères de choix ainsi qu’une présentation générale de cet outil sont exposés dans une première partie. Nous décrivons par la suite le développement d’un extracteur d’entités nommées nécessaire à la reconnaissance des événements tels que définis dans le chapitre 4.2. Nous terminons par une présentation de notre système de reconnaissance des événements fondé sur deux méthodes : une approche à base de règles linguistiques, d’une part, et une méthode par apprentissage de motifs fréquents, d’autre part. Les paramètres choisis pour notre application ainsi que les performances de notre système d’EI seront présentés en section 7.2. 5.2 La plateforme GATE GATE est une plateforme open-source implémentée en Java dédiée à l’ingénierie textuelle au sens large [Cunningham et al., 2002]. Créée il y a une vingtaine d’années par les chercheurs de l’université de Sheffield (Royaume-Uni), GATE est largement utilisée par les experts en TAL et dispose d’une grande communauté d’utilisateurs. Cela lui permet de proposer un ensemble de solutions d’aide et de support (forum, liste de diffusion, foire aux questions, wiki, tutoriels, etc.). Ce point a constitué un critère important afin de choisir notre environnement de développement parmi les différentes plateformes et outils présentés en section 2.3. Par ailleurs, GATE propose une chaine d’extraction d’entités nommées pour l’anglais nommée ANNIE composée de différents modules open source. Cette chaine ayant déjà été utilisée au sein de la plateforme WebLab, elle a constitué une première base pour l’élaboration de notre propre système d’extraction d’information. Fonctionnement général L’environnement GATE repose sur le principe de chaines de traitement composées de différents modules (dits "Processing Resources" PR) appliqués successivement sur un ou plusieurs textes (dits "Language Resources" LR). Les LR peuvent être des textes seuls, fournit dans l’interface par copiercoller ou URL, ou des corpus de textes créés manuellement ou importés d’un dossier existant. Produit d’une communauté d’utilisateurs croissante, l’ensemble des PR disponibles est conséquent : ceux-ci sont organisés au sein de plugins thématiques et permettent des traitements variés pour une quinzaine de langues au total. L’utilisateur peut ainsi sélectionner un ensemble de briques logicielles pertinentes pour sa tâche, les paramétrer et les organiser à sa convenance pour construire une chaine de traitement de texte adaptée (voir l’annexe E pour un exemple de chaine de traitement). La majorité des modules de traitement fournit une analyse des textes à traiter par un système d’annotations exprimées au format XML et selon le modèle de la plateforme. Ce système permet à chaque brique de traitement d’exploiter les annotations fournies par les modules précédents. Cela consiste géné- 84 Copyright c 2013 - CASSIDIAN - All rights reserved5.2. La plateforme GATE ralement à associer un ensemble d’attributs à une zone de texte. Ces attributs se présentent sous la forme propriété = "valeur". Voici un exemple d’annotation créée par un composant de segmentation en mots : Token { c a t e g o r y =NNP, ki n d =word , l e n g t h =5 , o r t h = u p p e r I n i t i a l , s t r i n g =Obama} Il s’agit ici d’une annotation de type Token à laquelle sont associés plusieurs attributs comme sa catégorie grammaticale (NNP), son type (word), sa longueur en nombre de caractères (5), sa casse (upperInitial) et la chaîne de caractères correspondante (Obama). Le formalisme JAPE Parallèlement aux différents modules d’analyse, la plateforme GATE propose un formalisme d’expression de grammaires contextuelles nommé JAPE (Java Annotation Patterns Engine). Ce formalisme est employé pour la définition de règles au sein des modules de type transducteurs à états finis. Ce système s’avère très utile en extraction d’information car il permet de définir les contextes d’apparition des éléments à extraire pour ensuite les repérer et les annoter dans un ensemble de textes. Le principe est de combiner différentes annotations fournies par les modules précédant le transducteur (tokens, syntagmes, relations syntaxiques, etc.) pour en créer de nouvelles plus complexes (entités nommées, relations, évè- nements, etc.) : cela revient à l’écriture de règles de production et donc à l’élaboration d’une grammaire régulière. Une grammaire dans GATE se décompose en plusieurs phases exécutées consécutivement et formant une cascade d’automates à états finis. Chaque phase correspond à un fichier .jape et peut être constituée d’une ou plusieurs règle(s) écrite(s) selon le formalisme JAPE. Classiquement, ces règles sont divisées en deux blocs : une partie gauche (Left Hand Side ou LHS) définissant un contexte d’annotations à repérer et une partie droite (Right Hand Side ou RHS) contenant les opérations à effectuer sur le corpus à traiter lorsque le contexte LHS y a été repéré. Le lien entre ces deux parties se fait en attribuant des étiquettes à tout ou partie du contexte défini en LHS afin de cibler les annotations apposées en RHS. Pour plus de clarté, prenons l’exemple d’une règle simple : 1 R ule : OrgAcronym 2 ( 3 { O r g a n i s a t i o n } 4 { Token . s t r i n g == " ( " } 5 ( { Token . o r t h == " a l l C a p s " } ) : o r g 6 { Token . s t r i n g == " ) " } 7 ) 8 −−> 9 : o r g . O r g a n i s a t i o n = { r u l e =" OrgAcronymRule " , ki n d =" Acronym "} FIGURE 5.1 – Exemple de règle d’extraction exprimée dans le formalisme JAPE L’objectif de celle-ci est d’annoter avec le type Organisation tous les acronymes entre parenthèses positionnés après une première annotation de ce même type. La première ligne de cette règle indique le nom qui lui a été donné par son auteur. Les lignes 2 à 7 définissent le motif à repérer dans le texte : les types des annotations sont encadrés par des accolades (e.g. {Organisation}), l’accès aux attributs 85 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements des annotations se fait sous la forme Annotation.attribut (Token.string, par exemple, permet d’obtenir la valeur de la propriété string associée aux annotations de type Token fournies par un module précédent), (...) :org permet d’étiqueter la partie visée du motif pour y référer en partie RHS de la règle. Puis, la flèche (ligne 8) sert de séparateur entre les parties LHS et RHS. La ligne 9 permet d’attribuer une annotation de type Organisation au segment étiqueté org en partie gauche. Remarquons également en partie droite l’ajout des propriétés rule et kind à l’annotation produite afin d’indiquer quelle règle en est à l’origine et qu’il s’agit d’un acronyme d’organisation. Ces attributs peuvent être librement définis par le développeur de grammaires. Précisons également qu’un système de macros permet de nommer une séquence d’annotations afin de la réutiliser de façon raccourcie dans les règles définies. Enfin, il est possible de gérer l’ordre d’exécution d’un ensemble de règles en choisissant un des différents modes de contrôle proposés par le formalisme JAPE (all, once, appelt, etc.). Quelques modules utilisés dans nos travaux Dans cette section, nous présentons différents modules qui nous ont été utiles pour mettre en oeuvre notre système d’extraction d’information. Tout d’abord, nous devons parler d’ANNIE (A Nearly-New Information Extraction system), une chaine complète dédiée à la reconnaissance d’entités nommées pour l’anglais. Fournie conjointement à la plateforme, cette chaine comprend différents modules d’analyse : 1. Document Reset : supprime toutes les annotations apposées précédemment sur le document, 2. English Tokenizer : découpe le texte en mots (tokens), 3. Gazetteer : repère les éléments contenus dans une liste (gazetteer) et les annote en tant que Lookup, 4. Sentence Splitter : découpe le texte en phrases, 5. POS Tagger : ajoute à l’annotation Token (mise par le tokenizer) une propriété category indiquant la catégorie morpho-syntaxique du mot en question. Il s’agit, ici, d’une version dérivée de l’étiqueteur Brill [Brill, 1992], 6. NE Transducer : un transducteur JAPE définissant un ensemble de règles afin de repérer des entités nommées (Person, Organization, Location, Date, URL, Phone, Mail, Address, etc.), 7. OrthoMatcher : annote les relations de co-référence entre les entités nommées repérées précédemment. ANNIE étant spécialisée pour le traitement de textes anglais, d’autres modules se sont avérés né- cessaires pour l’extraction d’information en français. Nous avons notamment utilisé les modules de découpage en mots et d’étiquetage morpho-syntaxique adaptés pour la langue française (French tokenizer et TreeTagger). De plus, la phase d’extraction d’événements a nécessité l’utilisation de l’analyseur syntaxique Stanford parser fournissant une analyse syntaxique en dépendance des phrases à traiter. Par ailleurs, nos travaux nécessitant un découpage des textes en groupes syntaxiques (nominaux et verbaux), les modules NP Chunker et VP Chunker ont répondu à ce besoin. Enfin, divers modules d’analyse linguistique nous ont été utiles tels qu’un analyseur morphologique ou encore un repérage lexical paramétrable (dit Flexible Gazetteer). 86 Copyright c 2013 - CASSIDIAN - All rights reserved5.3. Extraction d’entités nommées 5.3 Extraction d’entités nommées La phase d’extraction d’entités nommées consiste à mettre en place un système de détection et de typage des entités d’intérêt pour l’anglais et le français. En effet, pour reconnaitre des événements tels qu’ils sont définis dans WOOKIE, notre premier objectif est de repérer les entités de type Person, Unit, Date et Place. Pour ce faire, comme nous l’avons montré dans l’état de l’art correspondant (voir la section 2.2.1), plusieurs types de méthodes ont été explorées : des approches symboliques, statistiques ou encore hybrides. Celles-ci ayant montré des performances comparables pour le problème de la REN, notre choix a été guidé par le contexte applicatif de nos travaux. En effet, il apparait important dans le contexte du ROSO d’éviter l’extraction d’informations erronées (ce que l’on nomme plus communément le bruit). Ce critère nous a donc orienté vers le choix d’une approche à base de règles, pour laquelle la littérature a montré une plus grande précision et qui s’avère également plus facilement adaptable à un domaine d’application donné. Notre système de REN a été élaboré selon un processus ascendant et itératif : nous avons collecté un ensemble de dépêches de presse en anglais et français et repéré manuellement des exemples d’entités nommées à extraire. Partant de ces exemples, nous avons construit (par généralisations successives des contextes d’apparition de ces entités) une première version du système, que nous avons appliqué sur ce même jeu de textes pour vérifier la qualité des règles construites (en termes de précision et rappel). Le système a ensuite été modifié pour atteindre la qualité voulue, puis un nouveau corpus de textes a été constitué pour découvrir de nouvelles formes d’entités et ainsi de suite. De par la proximité des langues anglaise et française, cette méthode a été appliquée pour les deux langues et les systèmes d’extraction développés suivent donc les mêmes principes et présentent une structure commune. Nous présentons ci-dessous les différentes étapes d’extraction ainsi que leur implémentation pour l’anglais et le français grâce à la plateforme GATE. 5.3.1 Composition de la chaine d’extraction La chaine d’extraction d’entités nommées est composée de différents modules d’analyse listés et dé- crits ci-après. L’ordre d’exécution de ces modules a son importance car chaque traitement exploite les annotations créées précédemment. Pour cela, nous nous sommes inspirés de la chaine d’extraction ANNIE présentée ci-dessus tout en l’adaptant à notre problématique et à notre représentation des connaissances. La composition de modules obtenue reste la même pour l’anglais et le français bien que certains des modules soient spécifiques à la langue traitée. Notons également que les quatre premières étapes sont réalisées par des briques (reprises en l’état) proposées dans GATE tandis que les deux derniers modules ont été au centre de nos travaux et ont nécessité notre expertise. 1. Réinitialisation du document Ce premier module permet de nettoyer le document traité de toute annotation existante afin de le préparer à l’exécution d’une nouvelle chaine d’extraction. Il est indépendant de la langue. 2. Découpage en mots Ce second module découpe le texte en mots ou plus précisément en tokens. Ce traitement dépend de la langue traitée : nous avons donc utilisé les tokenizers spécifiques à l’anglais et au français fournis dans GATE. 87 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements 3. Découpage en phrases Cette étape permet d’obtenir une annotation par phrase du texte. L’anglais et le français étant des langues proches syntaxiquement, le même module a été utilisé pour ces deux langues. 4. Étiquetage grammatical Également nommée "étiquetage morpho-syntaxique" ou Part-Of-Speech (POS) tagging en anglais, cette phase donne pour chaque token repéré un ensemble d’informations grammaticales telles que la catégorie grammaticale (nom, verbe, adjectif, etc.), le genre, le nombre, etc. Ce module est dépendant de la langue considérée : l’analyseur pour l’anglais est celui présent dans la chaine ANNIE tandis que pour le français nous avons choisi l’outil TreeTagger. 5. Repérage lexical Cette étape consiste à repérer dans les textes à traiter un ensemble de mots clés préalablement définis dans des listes nommées gazetteers. Ces mots clés sont généralement des termes communs dont l’occurrence peut indiquer la présence d’une entité nommée. Les gazetteers sont de nature variée : listes de prénoms pour la reconnaissance des noms de personnes, jours de la semaine et noms des mois pour la détection des dates, etc. A chaque liste est associée une étiquette sémantique qui constituera le type de l’annotation apposée. Même s’il s’agit généralement d’une simple projection de lexique, ce module s’avère très utile pour l’extraction des entités nommées en tant que telle effectuée par le module suivant. En effet, les annotations fournies par ce module entrent dans la définition des différents contextes d’apparition des entités nommées (partie gauche des règles). Un exemple de gazetteer pour la détection des personnes en français est présentée en annexe F. 6. Règles d’extraction Ce dernier module d’annotation constitue le cœur du système de REN et contient les règles linguistiques élaborées manuellement, suivant le formalisme JAPE, pour la détection des entités de type Personne, Organisation, Lieu et Date. Nous avons fait le choix, dans le cadre de nos recherches, de ne pas conserver le module de résolution de co-référence Orthomatcher au sein de notre système d’extraction. En effet, nous avons constaté que la précision de ce module n’étant pas suffisamment bonne pour notre cas d’application et que cela détériorait la qualité de l’extraction d’événements (fortement dépendantes de l’extraction d’entités nommées). 5.3.2 Développement du module de règles linguistiques Le module d’extraction constitue le cœur de notre système. L’ensemble des règles linguistiques dé- veloppées sont contextuelles et partagent la forme suivante : regle : contexte → action Elles sont implémentées selon le formalisme JAPE décrit en section 5.2. Conformément à notre cas d’application, nous avons veillé, lors de leur développement, à privilégier la précision au rappel, c’est-à-dire l’extraction d’informations pertinentes pour mieux répondre à l’attente des opérationnels du domaine. Concrètement, cela s’est traduit par la construction de règles linguistiques dont les résultats sont plus sûrs et la mise à l’écart de règles pouvant entrainer de fausses annotations. 88 Copyright c 2013 - CASSIDIAN - All rights reserved5.3. Extraction d’entités nommées Celles-ci sont organisées en plusieurs ensembles, chacun étant spécifique au type d’entité ciblé. Ces ensembles sont implémentés sous la forme d’automates à états finis et l’exécution des règles au sein d’un même ensemble est régie par un système de priorité. Celui-ci permet de déterminer, lorsqu’il y a conflit entre plusieurs règles, quelle est celle qui doit être privilégiée pour annoter une portion de texte. Les différents ensembles de règles sont eux exécutés successivement selon un ordre fixé à l’avance au sein du système, constituant ce que l’on appelle des phases d’extraction. Pour déterminer le meilleur agencement de ces phases au sein du module de règles, nous nous sommes référés aux travaux de [Mikheev, 1999] et plus particulièrement à la gestion d’éventuelles ambiguïtés entre entités. Le principe suggéré est le suivant : afin d’éviter toute ambiguïté, il est conseillé d’exécuter en premier les règles les plus sûres (basées essentiellement sur le contexte linguistique), puis de typer les entités encore inconnues grâce aux gazetteers du module précédent et de lever les ambiguïtés restantes dans une phase finale. Nos propres observations nous ont amenés à choisir, en outre, un ordre de détection entre les 4 entités-cibles : nous typons, tout d’abord, les dates qui ne sont généralement pas confondues avec les autres entités ; puis, vient une phase de détection des organisations, suivie par les entités de type Personne et, enfin, les noms de lieux. En effet, nous avons observé que les noms d’organisations peuvent inclure des noms de personnes ou de lieux et doivent donc être repérés en priorité afin d’écarter l’ambiguïté. Par ailleurs, certains prénoms présentant une homonymie avec des noms de lieux, les entités de type Personne doivent être extraites avant celles de type Lieu. Ces premières présentent des formes moins variables et sont donc plus facilement repérables (grâce notamment aux listes de prénoms et de titres personnels). Pour l’extraction des EN en anglais, nous sommes partis de l’existant (la chaine ANNIE) en modifiant l’ordre des phases selon le principe explicité ci-dessus et sélectionnant/améliorant les règles les plus pertinentes pour notre application. Dans le cas du français, nous avons construit le système complet en s’appuyant sur la même méthodologie. Nous présentons, pour conclure cette section, quelques exemples de règles et gazetteers pour chaque type d’extraction. Extraction des dates La référence au temps peut s’exprimer de façon diverse et les expressions temporelles revêtent des formes textuelles variées : littérales ("en janvier"), numériques (10/01/2013) ou mixtes ("le 9 janvier"). La littérature distingue les expressions dites "absolues" de celles dites "relatives" : les premières permettent à elles seules de se repérer sur un axe temporel (par exemple, "le 9 janvier 2002" ou "l’année 2010") alors que les secondes ("hier matin", "le 5 mars", etc.) nécessitent pour cela des informations complémentaires provenant du co-texte ou du contexte extra-linguistique. On constate aussi des diffé- rences dans l’expression des dates d’une langue à une autre : dans notre cas, les anglophones n’expriment pas les dates comme les francophones. Toutes ces variations rendent la détection automatique des dates complexe et le développement des règles doit être réalisé en tenant compte des spécificités de l’anglais et du français. Voici pour exemple deux règles JAPE extraites de notre système : la première 5.2 permet d’extraire des dates en français, la seconde 5.3 est l’équivalent pour l’anglais (les dates en gris sont des exemples pouvant être détectés par la règle). Comme mentionné plus haut, il est fait usage de macros (termes en majuscules) pour faciliter la lecture et la maintenance du jeu de règles. De plus, un ensemble de propriétés est adjoint à l’annotation pour faciliter la normalisation des dates (voir la section 6.2). 89 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements / / l u n d i 27 a v r i l 2009 / / 27 a v r i l 2009 / / 1 e r a v r i l 2006 R ule : DateC om plete ( (NOM_JOUR) ? (NB_JOUR ) : j o u r ( { Token . s t r i n g == "−" } ) ? (NOM_MOIS ) : mois (ANNEE ) : a n n e e ) : d a t e −−> : d a t e . Date = { r u l e = " DateC om plete " , s t a r t Y e a r = : a n n e e . Token . s t r i n g , s t a r tM o n t h = : mois . Lookup . v al u e , s t a r t D a y = : j o u r . Lookup . v a l u e } FIGURE 5.2 – Règle d’extraction de dates en français / / Wed 10 J ul y , 2000 / / Sun , 21 May 2000 / / 10 t h o f J ul y , 2000 R ule : DateNameComplete P r i o r i t y : 100 ( (DAY_NAME (COMMA) ? ) ? (ORDINAL | DAY_NUM ) : day (MONTH_NAME ) : month (COMMA) ? (YEAR ) : y e a r ) : d a t e −−> : d a t e . Date = { r u l e = " DateNameComplete " , s t a r t Y e a r = : y e a r . Token . s t r i n g , s t a r tM o n t h = : month . Lookup . v al u e , s t a r t D a y = : day . Token . s t r i n g } FIGURE 5.3 – Règle d’extraction de dates en anglais Extraction des organisations Le système développé permet d’extraire des noms d’organisations divers tels que : NATO, Communist Party of India-Maoist, Ouattara Party, Nations Unies, AFP, Radio Azzatyk, armée de l’Air, etc. Nous utilisons pour cela des gazetteers de mots couramment associés à des noms d’organisations, qu’ils fassent partie de l’entité nommée ou non (la figure 5.4 est un extrait d’un de ces gazetteers pour l’anglais). La règle ci-dessous 5.5 utilise un de ces gazetteers afin de reconnaitre des noms d’organisations en anglais précédés d’un titre ou d’une fonction de personne tels que the director of the FBI ou the interim vice president of Comcast Business. Extraction des personnes Concernant la reconnaissance des noms de personne, nous avons assez classiquement utilisé des gazetteers de prénoms. Toutefois, face à l’immense variété des prénoms (même en domaine restreint) et 90 Copyright c 2013 - CASSIDIAN - All rights reserved5.3. Extraction d’entités nommées FIGURE 5.4 – Extrait du gazetteer org_key.lst R ule : O r g T i t l e P r i o r i t y : 60 ( { Lookup . maj o rT y pe == " j o b t i t l e " } { Token . s t r i n g == " o f " } ( { Token . s t r i n g == " t h e " } ) ? ( (UPPER ( POSS ) ? ) [ 1 , 4 ] ORG_KEY ) : o r g ) −−> : o r g . O r g a n i s a t i o n = { r u l e = " O r g T i t l e " } FIGURE 5.5 – Règle d’extraction d’organisations en anglais les ambiguïtés possibles, il est nécessaire d’exploiter d’autres indices contextuels tels que les titres ou fonctions personnelles. Ces derniers peuvent être placés en début ou en fin de l’entité nommée, la figure 5.6 donne quelques exemples d’indices antéposés en anglais. Enfin, la règle suivante 5.7, par exemple, exploite les annotations posées par différents gazetteers (fonctions et nationalités ici) pour l’extraction des noms de personne. 91 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements FIGURE 5.6 – Extrait du gazetteer person_pre.lst R ule : P e r s F o n c t i o n ( FONCTION ( NATIONALITE ) ? ( ( ( NP ) [ 1 , 3 ] ) : l a s t ) : p e r s o n ) −−> : p e r s o n . P e r s o n = { r u l e = " P e r s F o n c t i o n " } FIGURE 5.7 – Règle d’extraction de personnes en français Extraction des lieux L’extraction automatique des noms de lieux est, avec celle des organisations, l’une des plus complexe à mettre en œuvre de par la grande diversité formelle et référentielle de ces entités. En effet, les dépêches de presse relatant généralement des faits de façon précise, nous pouvons y trouver des noms de lieux granularité variable (noms de pays, villes, villages, régions, quartiers, rues, etc.) et exprimés parfois de façon relative ou imprécise (par exemple, eastern Iraq, Asie centrale, au nord de l’Afghanistan). De même que 92 Copyright c 2013 - CASSIDIAN - All rights reserved5.3. Extraction d’entités nommées pour la détection des organisations, de nombreuses ressources géographiques sont disponibles librement (gazetteers de toponymes, bases de données géographiques, etc.) et nous avons pu constituer quelques listes de base pour la détection des lieux communément mentionnés (liste des pays, des continents, des capitales, etc.). Il est nécessaire également de fonder nos règles d’extraction sur des indices contextuels tels que des noms communs déclencheurs d’entités géographiques (voir la figure 5.8 pour des exemples en français). FIGURE 5.8 – Extrait du gazetteer loc_key.lst Pour finir, la figure 5.9 est un exemple de règle JAPE exploitant ces indices de contexte : R ule : L o cK e y I n cl P r i o r i t y : 50 ( { Lookup . mino rType == " l o c _ k e y _ i n c l " } (DE ) ? ( ARTICLE ) ? (UPPER ) [ 1 , 3 ] ( ADJLOC ) ? ) : l o c −−> : l o c . L o c a ti o n = { r u l e = " L o cK e y I n cl " } FIGURE 5.9 – Règle d’extraction de lieux en français 93 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements 5.4 Extraction d’événements Nous détaillons, dans cette section, le cœur de notre première contribution à savoir la conception et l’implémentation d’un système d’extraction automatique d’événements tels que nous les avons défi- nis au chapitre 4. L’objectif est donc d’extraire un ensemble d’événements associés aux participants et circonstants suivants : la date de l’événement, son lieu d’occurrence et les entités de type Personne et Organisation impliquées. Celui-ci est constitué de deux extracteurs suivant deux approches distinctes : une méthode symbolique à base de règles linguistiques élaborées manuellement et une approche par apprentissage de motifs séquentiels fréquents. En effet, l’état de l’art réalisé (voir le chapitre 2.2.3) n’ayant pas révélé d’approche nettement supérieure aux autres, la combinaison de plusieurs méthodes parait être la solution la plus pertinente. Élaborer un système composite permet de tirer le meilleur parti des approches actuelles en exploitant la complémentarité des différents types d’approche (statistique, symbolique, etc.). Nous nous sommes tournés, dans le cadre de cette thèse, vers la combinaison d’un système à base de règles et d’un apprentissage symbolique pour plusieurs raisons. Tout d’abord, de par les besoins du ROSO, il est préférable de privilégier l’extraction d’informations fiables et précises et les approches symboliques répondent bien à ce besoin. Par ailleurs, afin d’améliorer les performances de ces techniques, il est apparu intéressant de les combiner avec un système d’apprentissage, dont le rappel est généralement meilleur. Nous nous sommes, dans un premier temps, orientés vers un système statistique tels que les CRFs, cependant après plusieurs recherches, nous n’avions pas à disposition un corpus d’apprentissage adapté (annoté en événements du domaine militaire/sécurité). Cela nous a donc mené vers le choix d’une méthode d’apprentissage faiblement supervisée telle que l’extraction de motifs fréquents qui ne nécessite pas de données annotées avec les entités-cibles. Nous présentons ci-dessous les principes théoriques de chaque approche choisie ainsi que la façon dont nous les avons mises en œuvre pour le traitement de dépêches de presse en langue anglaise. La méthode élaborée se veut indépendante de la langue des textes considérés et a été illustrée, dans le cadre de cette thèse, pour des textes en anglais uniquement en raison d’une plus grande disponibilité pour cette langue des outils et données nécessaires. 5.4.1 Approche symbolique La première méthode employée pour la détection d’événements est fondée sur la définition de règles linguistiques contextuelles (du même type que celles présentées en section 5.3) couplée avec une analyse syntaxique des textes. Celle-ci a été implémentée grâce à la plateforme GATE sous la forme d’une chaîne de traitement composée de différents modules d’analyse linguistique (tokenisation, découpage en phrases, repérage lexical, étiquetage grammatical, analyse syntaxique, etc.) et se déroule en plusieurs étapes détaillée ci-après. Repérage des déclencheurs d’événements La première étape consiste à repérer dans les textes à traiter les termes qui réfèrent potentiellement aux événements ciblés, que nous appellerons des "déclencheurs d’événements" (correspondant aux ancres du modèle ACE). Tout d’abord, nous considérons comme possibles déclencheurs d’événements 94 Copyright c 2013 - CASSIDIAN - All rights reserved5.4. Extraction d’événements les verbes et les noms, éléments porteurs de sens. Le repérage de ces déclencheurs se fait par l’utilisation de gazetteers contenant, d’une part, des lemmes verbaux pour les déclencheurs de type verbe et, d’autre part, des lemmes nominaux pour les déclencheurs de type nom. Nous avons chois de constituer des listes de lemmes afin d’obtenir des listes plus courtes et d’étendre le repérage des déclencheurs à toutes les formes fléchies (grâce au module GATE de type flexible gazetteer). Ces déclencheurs (139 lemmes actuellement) ont été manuellement répartis en différentes listes, chacune étant associée à un type d’événement (c’est-à-dire à une classe de notre ontologie) afin d’être repérés et annotés dans le corpus à analyser. Après une phase de découpage en mots, un analyseur morphologique attribue à chaque token son lemme. Nous comparons ensuite chaque lemme aux listes de déclencheurs et, s’ils correspondent, le mot lemmatisé est annoté comme étant un déclencheur d’événement. De plus, on lui associe la classe d’événement qu’il représente. La figure 5.4.1 présente la liste des lemmes verbaux utilisés comme déclencheurs des événements de type BombingEvent (les informations indiquées après le symbole § seront clarifiées par la suite). FIGURE 5.10 – Gazetteer bombings.lst Analyse des dépendances syntaxiques Une fois les déclencheurs d’événement repérés, il nous faut leur associer les différentes entités impliquées pour former l’événement dans son ensemble. Pour cela, nous effectuons, dans un premier temps, une extraction automatique d’entités nommées grâce au système présenté en section 5.3 ainsi qu’une analyse en constituants syntaxiques (syntagmes nominaux NP, verbaux VP, prépositionnels SP ou adjectivaux SA). Nous devons ensuite repérer les différentes relations entre le déclencheur et les entités de la phrase. Nous employons, dans ce but, un analyseur syntaxique donnant les dépendances entre les différents élé- ments phrastiques. En effet, une analyse syntaxique permet d’obtenir une meilleure précision par rapport à l’utilisation d’une analyse dite "par fenêtre de mots" associant un simple découpage en syntagmes (chunking) et des règles contextuelles. Après avoir examiné les différentes solutions proposées dans la plateforme GATE, nous avons opté pour l’utilisation du Stanford parser [De Marneffe and Manning, 2008]. Ici, nous faisons le choix de n’utiliser que les dépendances principales à savoir les relations sujet, objet, préposition et modifieur de nom. Les dépendances extraites par le Stanford parser se présentent sous la forme de liens entre les éléments centraux du syntagme-recteur et du syntagme-dépendant, plus communément appelés "têtes de syntagme" (voir la figure 5.11). 95 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements FIGURE 5.11 – Exemple d’analyse syntaxique en dépendance Voix active Voix passive Classe 1 sujet = agent, objet = patient sujet = patient, ct. prep. "by" 109 = agent Classe 2 sujet = agent, objet = instrument sujet = instrument, ct. prep. "by" = agent Classe 3 sujet = instrument, objet = patient sujet = patient, ct. prep. "by" = instrument Classe 4 sujet = agent, objet = locatif sujet = locatif, ct. prep. "by" = agent Classe 5 sujet = patient ∅ TABLE 5.1 – Classes argumentales pour l’attribution des rôles sémantiques Attribution des rôles sémantiques La dernière étape consiste à attribuer un rôle sémantique (agent, patient, instrument, etc.) aux diffé- rents participants de l’événement. Cela est rendu possible par une étude de la structure argumentale du verbe ou du nom déclencheur : à savoir déterminer sa valence (nombre d’arguments) et les rôles sémantiques de ses différents actants. Si nous prenons l’exemple des verbes anglais kill et die, nous remarquons qu’ils ont des valences différentes (2 et 1 respectivement) et que leurs sujets n’ont pas le même rôle sé- mantique : le premier sera agent et le second patient. L’attribution de ces rôles sémantiques nécessite d’étudier, en amont, la construction des lemmes présents dans nos gazetteers [François et al., 2007]. Pour cela, nous avons choisi de constituer 5 classes argumentales, chacune d’elles correspondant à un type de construction verbale ou nominale (voir le tableau 5.1). L’attribution des rôles sémantiques est réalisée par un ensemble de règles linguistiques (implémenté sous la forme d’un transducteur JAPE) exploitant les informations fournies par les phases précédentes. La figure 5.12 résume les différentes étapes de notre approche. FIGURE 5.12 – Extraction des événements : différentes étapes L’ensemble de ces traitements ont été implémentés grâce à des modules fournis dans GATE (voir la figure 5.13) et permettent d’obtenir une annotation positionnée sur l’ancre d’événement indiquant le type 96 Copyright c 2013 - CASSIDIAN - All rights reserved5.4. Extraction d’événements de l’événement (sa classe dans l’ontologie de domaine) ainsi que les différentes entités impliquées (date, lieu et participants). Un exemple d’annotation obtenu est fourni par la figure 5.14. FIGURE 5.13 – Extraction des événements : chaine de traitement GATE pour l’anglais FIGURE 5.14 – Extraction des événements : exemple d’annotation GATE 5.4.2 Apprentissage de patrons linguistiques Dans un second temps, nous nous sommes intéressés à l’extraction d’événements par une technique d’extraction de motifs séquentiels fréquents. Ce type d’approche permet d’apprendre automatiquement des patrons linguistiques compréhensibles et modifiables par un expert linguiste. Présentation de l’approche La découverte de motifs séquentiels a été introduite par [Agrawal et al., 1993] dans le domaine de la fouille de données et adaptée par [Béchet et al., 2012] à l’extraction d’information dans les textes. 97 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements Ceux-ci s’intéressent en particulier à la découverte de motifs séquentiels d’itemsets. Il s’agit de repérer, dans un ensemble de séquences de texte, des enchaînements d’items ayant une fréquence d’apparition supérieure à un seuil donné (dit support). La recherche de ces motifs s’effectue dans une base de sé- quences ordonnées d’itemsets où chaque séquence correspond à une unité de texte. Un itemset est un ensemble d’items décrivant un élément de cette séquence. Un item correspond à une caractéristique particulière de cet élément. Un certain nombre de paramètres peuvent être adaptés selon l’application visée : la nature de la séquence et des items, le nombre d’items, le support, etc. La fouille sur un ensemble de séquences d’itemsets permet l’extraction de motifs combinant plusieurs types d’items et d’obtenir ainsi des patrons génériques, spécifiques ou mixant les informations (ce qui n’est pas permis par les motifs d’items simples). Par exemple, cette technique permet d’extraire les patrons suivants : < t h r e e C h i l e a n s a r r e s t e d n e a r Buenos A i r e s > < NP a r r e s t e d n e a r L o c a ti o n > < NP VB PRP L o c a ti o n > où NP est un syntagme nominal, VB est un verbe, PRP est une préposition et Location est une entité nommée de type Lieu. La phase d’apprentissage permet d’obtenir un ensemble de motifs séquentiels fréquents qui sont ensuite sélectionnés par un expert pour en retenir les plus pertinents pour la tâche d’extraction visée. Les motifs retenus sont alors appliqués sur un le nouveau corpus à analyser, préalablement annoté pour obtenir les différents types d’items considérés. Contrairement à d’autres approches d’EI (présentées en section 2.2), la découverte de motifs séquentiels fréquents ne nécessite ni corpus annoté avec les entités-cibles, ni analyse syntaxique. Cela constitue un réel avantage car, tout d’abord, l’annotation manuelle de corpus reste un effort important et l’analyse syntaxique est encore une technologie aux performances inégales et peu disponible librement selon les langues. Toutefois, le point faible partagé par les méthodes d’apprentissage symbolique reste le nombre important de motifs extraits. Pour pallier ce problème, [Béchet et al., 2012] propose l’ajout de contraintes pour diminuer la quantité de motifs retournés et l’utilisation de l’outil Camelis [Ferré, 2007] pour ordonner et visualiser les motifs des plus généraux aux plus spécifiques puis filtrer les plus pertinents. Application à l’extraction automatique des événements Dans la lignée de ces travaux, nous avons utilisé un outil d’extraction de motifs séquentiels développé au GREYC110 (selon la méthode de [Béchet et al., 2012]). Le système repris présente plusieurs points forts qui justifient ce choix : il permet d’extraire des motifs dits "fermés" (c’est-à-dire non redondants) et génère ainsi moins de motifs que d’autres systèmes. De plus, ce logiciel s’avère robuste et permet la fouille de séquences d’itemsets, fonctionnalité qui est rarement proposée par les outils de fouille de données existants. Notre contribution a donc été d’adapter la technique de fouille de motifs séquentiels à notre domaine d’application et au traitement de dépêches de presse dans le but de générer automatiquement des patrons linguistiques pour la détection d’événements. Nous avons tout d’abord défini un ensemble de paramètres de base pour l’apprentissage : nous choisissons comme séquence la phrase et comme unité de base le 110. ❤tt♣s✿✴✴s❞♠❝✳❣r❡②❝✳❢r 98 Copyright c 2013 - CASSIDIAN - All rights reserved5.5. Conclusions token ainsi qu’un ensemble d’items de mot tels que sa forme fléchie, son lemme, sa catégorie grammaticale. Pour segmenter le corpus d’apprentissage et obtenir ces différentes informations, nous avons employé l’analyseur morpho-syntaxique TreeTagger 111 [Schmid, 1994]. A cela, nous proposons d’ajouter une reconnaissance des entités nommées (de type Personne, Organisation, Lieu et Date) ainsi qu’un repérage lexical des déclencheurs d’événements. Nous pouvons ainsi découvrir des motifs séquentiels fréquents impliquant un déclencheur d’événement et une ou plusieurs entités d’intérêt constituant les participants/circonstants de l’événement en question. Ces deux traitements sont réalisés grâce à la chaine de REN présentée en section 5.3 et aux gazetteers construits pour le premier système symbolique. Enfin, pour réduire le nombre de motifs retournés et faciliter la sélection manuelle de l’expert, nous introduisons un ensemble de contraintes spécifiques à notre application. D’une part, des contraintes linguistiques d’appartenance permettant de filtrer les motifs selon les items qu’ils contiennent. Pour notre application, la contrainte d’appartenance utilisée est de ne retourner que les motifs contenant au minimum un déclencheur d’événement et une entité nommée d’un type d’intérêt (voir plus haut). D’autre part, nous avons employé une contrainte dite de gap [Dong and Pei, 2007], permettant l’extraction de motifs ne contenant pas nécessairement des itemsets consécutifs (contrairement aux n-grammes dont les éléments sont strictement contigus). Un gap d’une valeur maximale n signifie qu’au maximum n itemsets (mots) sont présents entre chaque itemset du motif retourné dans les séquences correspondantes. Par exemple, si la séquence suivante (1) est présente dans le corpus d’apprentissage et que le gap est fixé à 2, le système pourra retourner le motif (2) : (1) [...] a suspected sectarian attack in Mehmoodabad area of Karachi [...] (2) < DT EventTrigger PRP Location PRP Location > où DT est un déterminant, EventTrigger un déclencheur d’événement, PRP une préposition et Location une entité nommée de type Lieu. La contrainte de gap permet, dans cet exemple, de retourner un motif plus générique en omettant la présence des mots "suspected" et "sectarian" si ceux-ci ne sont pas fréquents. Les contraintes de gap et de support (fréquence minimale d’un motif) sont des paramètres à ajuster lors de la phase d’apprentissage. Ce paramétrage a été réalisé pour nos expérimentations et est présenté en partie 7.2.1. Une fois le nombre de motifs extraits diminué grâce à des contraintes, ceux-ci ont été manuellement sélectionnés en fonction de leur pertinence pour la tâche d’extraction des événements. Pour cela, nous utilisons l’outil Camelis [Ferré, 2007] permettant d’ordonner et visualiser les motifs des plus généraux aux plus spécifiques puis de filtrer les plus pertinents. La figure 5.15 présente un aperçu de cet outil. Les motifs ainsi sélectionnés sont ensuite appliqués sur un nouveau corpus afin d’en extraire les événements-cibles. Dans un souci de réutilisation des systèmes déjà développés et pour faciliter cette dernière étape, nous choisissons d’exprimer les motifs obtenus grâce au formalisme JAPE et obtenons ainsi un nouveau module intégrable dans une chaine de traitement GATE. 5.5 Conclusions Notre seconde contribution détaillée dans ce chapitre est une approche mixte pour l’extraction automatique des événements fondée sur une méthode symbolique à base de grammaires contextuelles et sur 111. ❤tt♣✿✴✴✇✇✇✳✐♠s✳✉♥✐✲st✉tt❣❛rt✳❞❡✴♣r♦❥❡❦t❡✴❝♦r♣❧❡①✴❚r❡❡❚❛❣❣❡r✴ 99 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 5. Extraction automatique des événements FIGURE 5.15 – Visualisation et sélection des motifs avec l’outil Camelis une seconde technique de fouille de motifs séquentiels fréquents. Dans un premier temps, nous avons implémenté un extracteur d’entités nommées sur le modèle des approches symboliques classiques. Celui-ci permet d’annoter au préalable les différentes entités dites simples nécessaires à la reconnaissance des événements. Les résultats de ce premier extracteur ont montré des performances comparables à l’état de l’art bien qu’il pourrait être amélioré en réalisant notamment une extraction des dates dites relatives ou encore des entités d’intérêt autres que les entités nommées (comme l’extraction des équipements par exemple). Les deux méthodes pour l’extraction des événements ont montré leur efficacité lors de l’état de l’art présenté à la section 2.2.3 et nous renvoyons à la section 7.2 pour une évaluation de leurs performances sur un corpus de test de notre domaine d’application. La méthode à base de règles GATE pourra être améliorée en tenant compte d’autres informations fournies par l’analyse syntaxique telles que la voix (passive ou active) du déclencheur, la polarité de la phrase (négative ou positive), la modalité mais aussi les phénomènes de valence multiple. L’approche à base de motifs séquentiels fréquents pourrait également tirer profit de cette analyse syntaxique en intégrant les relations de dépendance produites en tant que nouveaux items ou sous forme de contraintes. Enfin, concernant les deux approches, leur limite principale (qui est aussi celle de beaucoup des approches de la littérature) est qu’ils réalisent l’extraction au niveau phrastique. Une granularité plus large tel que le paragraphe ou le discours pourrait permettre d’améliorer le rappel de ces approches. 100 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6 Agrégation sémantique des événements Sommaire 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.2 Normalisation des entités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.3 Similarité sémantique entre événements . . . . . . . . . . . . . . . . . . . . . 105 6.3.1 Similarité conceptuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.3.2 Similarité temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.3.3 Similarité spatiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.3.4 Similarité agentive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.4 Processus d’agrégation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 101 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6. Agrégation sémantique des événements 6.1 Introduction L’état de l’art réalisé ainsi que le développement de notre propre système d’extraction d’information a montré la difficulté de cette tâche mais également et surtout des pistes d’amélioration possibles. Un premier constat est que les outils d’EI existants fournissent des résultats pouvant être incomplets, redondants, flous, conflictuels, imprécis et parfois totalement erronés. Par ailleurs, comme confirmé par nos premières expérimentations (voir la section 7.2), plusieurs approches actuelles s’avèrent complé- mentaires et une combinaison adaptée de leurs résultats pourrait aboutir à une découverte de l’information plus efficace. Dans le cadre de cette thèse, l’objectif visé est d’améliorer la qualité des fiches de connaissances générées et présentées à l’utilisateur afin de faciliter son processus de découverte des informations d’intérêt. Pour ce faire, nous proposons un processus d’agrégation sémantique des résultats issus de la phase d’extraction des événements. Cette troisième contribution vise à produire un ensemble de connaissances cohérent 112 en regroupant entre elles les mentions d’événements référant à un seul et même événement du monde réel. Ce processus est fondé sur des calculs de similarité sémantique et permet d’agréger à la fois des événements provenant des deux extracteurs développés et/ou de différentes sources d’information (agrégation intra- et inter-documents). Dans ce chapitre, nous présentons tout d’abord les mécanismes mis en place pour la normalisation des entités extraites, étape préalable nécessaire au processus d’agrégation. Dans un second temps, sont exposées les différentes méthodes définies pour estimer la similarité des événements au niveau de chacune de leurs dimensions (conceptuelle, temporelle, spatiale et agentive). Enfin, nous détaillons le processus d’agrégation proposé, fondé sur ces mesures de similarité locales. 6.2 Normalisation des entités Notre processus d’agrégation sémantique des événements nécessite de manipuler non plus de simples portions de texte extraites mais des objets sémantiques, des éléments de connaissance à proprement parler. Pour cela, nous proposons une première phase de normalisation visant à désambiguïser les différentes entités impliquées dans les événements dans le but de les rattacher à un objet du monde réel (c’est-à-dire déterminer leur référence). Nous présentons, dans les sections suivantes, les différentes méthodes mises en place pour la normalisation de ces entités. Normalisation des dates La normalisation des entités temporelles est nécessaire en raison des multiples façons possibles d’exprimer le temps en langage naturel ("04/09/2012", "Mon, 09/April/12", "two days ago", etc.). Celle-ci consiste à les convertir en un format unique facilitant leur comparaison et le calcul de leur similarité (voir la section 6.3.2). Conformément à notre modélisation temporelle de l’événement (voir la section 4.2.2), nous avons choisi pour cela le format TUS, définissant une représentation numérique unifiée des dates. Nous avons effectué cette normalisation au sein-même de notre module d’extraction d’information : les règles JAPE en question récupèrent séparément les différents éléments de la date (année, mois et jour, 112. Nous entendons ici par "cohérence" une absence de contradictions et de redondances. 102 Copyright c 2013 - CASSIDIAN - All rights reserved6.2. Normalisation des entités les granules dans le modèle TUS) afin de reconstituer sa forme normalisée et d’ajouter cette information sous forme d’attribut aux annotations de type Date produites. Nous avons fait le choix de nous intéresser exclusivement aux dates absolues car la résolution des dates relatives est un sujet de recherche à part entière [Llorens Martínez, 2011] que nous ne pouvons approfondir dans le cadre de cette thèse. En effet, l’extraction de ces dernières nécessite des traitements plus complexes en vue de leur normalisation tels que la résolution d’anaphores temporelles, l’analyse automatique du contexte linguistique d’occurrence, etc. Le tableau 6.1 ci-dessous présente quelques exemples de dates extraites dans des textes en anglais ainsi que leurs formes normalisées par notre outil. Date extraite Date normalisée 1999-03-12 1999-03-12 1948 1948-01-01/12-31 April 4, 1949 1949-04-04 July 1997 1997-07-01/31 03-12-99 1999-12-03 TABLE 6.1 – Normalisation des dates Normalisation des lieux [Garbin and Mani, 2005] ont montré que 40% des toponymes présents dans un corpus de dépêches de l’AFP sont ambigus. Il existe différents types d’ambiguïté : un nom propre peut référer à des entités de types variés (Paris peut faire référence à une ville ou à une personne), deux lieux géographiques peuvent porter le même nom (London est une ville en Angleterre mais aussi au Canada), certaines entités géographiques peuvent également porter plusieurs noms ou en changer au cours du temps, etc. Notre objectif ici est d’associer à chaque entité géographique extraite un référent unique correspondant à une entité du monde réel bien définie. Nous avons pour cela utilisé un service de désambiguïsation des entités géographiques développé dans notre département. Celui-ci opère en attribuant à chaque entité géographique extraite un identifiant de la base sémantique GeoNames. Le projet GeoNames a notamment pour avantages d’être open-source, de définir de nombreux toponymes dans le monde (l’information n’est pas limitée à certaines régions géographiques) et d’intégrer des relations avec d’autres sources de données (permettant des traitements plus avancés si nécessaire). Par ailleurs, ce composant de normalisation des lieux s’inspire des travaux de [Buscaldi, 2010]. L’approche est fondée sur des calculs de cohérence sur l’ensemble des toponymes possibles pour chaque entité géographique extraite. Cette cohérence est définie à partir de trois types de critères : – les distances géographiques entre toponymes ; – les types géographiques des toponymes (continent, ville, rivière ...) ; – les distances entre les entités géographiques au sein du texte considéré. L’intérêt de cette méthode est de pouvoir dégager des groupes de toponymes cohérents entre eux. De plus, elle permet de donner plus d’importance à la notion de qualité administrative par rapport à celle de proximité géographique lorsqu’une dépêche parle, par exemple, de New York, Paris et Londres. 103 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6. Agrégation sémantique des événements Le code ci-dessous est un extrait des triplets RDF/XML produits par ce service. Les quatre premières lignes lient l’entité extraite identifiée par l’URI http ://weblab.ow2.org/wookie/instances/Place#india et son entité de référence dans la base GeoNames (ayant pour identifiant http ://sws.geonames.org/1269750/). Le reste de l’exemple donne quelques-unes des propriétés de l’entité GeoNames Republic of India : sa classe dans l’ontologie Geonames (ligne 15), ses coordonnées géographiques selon le standard WGS84 (lignes 9 et 11), son nom dans GeoNames (ligne 14), etc. 1 < r d f : D e s c r i p t i o n 2 r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / P l a c e # i n d i a " > 3 < g e o : h a s S p a t i a l T h i n g r d f : r e s o u r c e = " h t t p : / / sws . geonames . o r g / 1 2 6 9 7 5 0/ " / > 4 < / r d f : D e s c r i p t i o n > 5 6 < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / sws . geonames . o r g / 1 2 6 9 7 5 0/ " > 7 < g e o : p a r e n t F e a t u r e r d f : r e s o u r c e = " h t t p : / / sws . geonames . o r g / 6 2 9 5 6 3 0/ " / > 8 < g e o : p a r e n t F e a t u r e r d f : r e s o u r c e = " h t t p : / / sws . geonames . o r g / 6 2 5 5 1 4 7/ " / > 9 < w g s 8 4:l o n g 10 r d f : d a t a t y p e = " h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema# d o u bl e " > 7 7 . 0 < / w g s 8 4:l o n g > 11 < w g s 8 4 : l a t 12 r d f : d a t a t y p e = " h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema# d o u bl e " > 2 0 . 0 < / w g s 8 4 : l a t > 13 < r d f s : l a b e l > R e p u bli c o f I n d i a < / r d f s : l a b e l > 14 < ge o: name > R e p u bli c o f I n d i a < / ge o: name > 15 < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / www. geonames . o r g / o nt o l o g y # F e a t u r e " / > 16 < / r d f : D e s c r i p t i o n > FIGURE 6.1 – Désambiguïsation des entités spatiales : exemple de triplets RDF/XML produits Normalisation des participants La normalisation des participants est également une problématique complexe de par la diversité des noms de personnes et d’organisations rencontrés dans les dépêches de presse. Une même entité est souvent mentionnée sous de multiples formes telles que des abréviations (Boston Symphony Orchestra vs. BSO), des formes raccourcies (Osama Bin Laden vs. Bin Laden), des orthographes alternatives (Osama vs. Ussamah vs. Oussama), des alias ou pseudonymes (Osama Bin Laden vs. Sheikh Al-Mujahid). De nombreux travaux se sont intéressés à la désambiguïsation de telles entités et particulièrement depuis l’essor du mouvement Linked Data et la mise à disposition de nombreuses bases de connaissances sé- mantiques sur le Web (voir le chapitre 3). Bien que cette thèse ne nous ait pas permis d’approfondir cette problématique, nous avons retenu, à titre de perspectives, certaines approches théoriques et outils qui pourront être intégrés au sein de notre processus d’agrégation. Nous pouvons citer, parmi les outils disponibles sur le Web, DBPedia Spotlight 113 et Zemanta 114 , permettant l’attribution d’un référent unique (provenant d’une base de connaissances externe) à chaque entité d’intérêt repérée dans un texte. Le premier outil est issu d’un projet open source et se présente sous la forme d’un service Web utilisant DBPedia comme base sémantique de référence. Le système Zemanta est lui propriétaire et initialement conçu pour aider les créateurs de contenu Web (éditeurs, blogueurs, etc.) grâce à des suggestions automatiques diverses (images, liens, mots-clés, etc.). Cet outil suggère notamment des liens sémantiques vers des concepts issus de nombreuses bases de connaissances telles que Wikipédia, IMDB, MusicBrainz, etc. Du côté des travaux théoriques, nous avons retenu deux 113. ❤tt♣s✿✴✴❣✐t❤✉❜✳❝♦♠✴❞❜♣❡❞✐❛✲s♣♦t❧✐❣❤t✴❞❜♣❡❞✐❛✲s♣♦t❧✐❣❤t✴✇✐❦✐ 114. ❤tt♣✿✴✴❞❡✈❡❧♦♣❡r✳③❡♠❛♥t❛✳❝♦♠✴ 104 Copyright c 2013 - CASSIDIAN - All rights reserved6.3. Similarité sémantique entre événements approches qui nous paraissent adaptées pour réaliser cette étape de normalisation des participants d’un événement. D’une part, [Cucerzan, 2007] propose de réaliser de façon conjointe la reconnaissance des entités nommées et leur désambiguïsation. Pour cette seconde tâche, cette approche emploie une grande quantité d’informations contextuelles et catégorielles automatiquement extraites de la base Wikipédia. Il est notamment fait usage des nombreux liens existants entre les entités de cette base, des pages de désambiguïsation sémantique (redirections) ainsi que d’un modèle vectoriel créé à partir du contexte textuel des entités nommées repérées. Par ailleurs, [Mann and Yarowsky, 2003] présente un ensemble d’algorithmes visant à déterminer le bon référent pour des noms de personne en utilisant des techniques de regroupement non-supervisé et d’extraction automatique de caractéristiques. Les auteurs montrent notamment comment apprendre et utiliser automatiquement l’information biographique contenue dans les textes (date de naissance, profession, affiliation, etc.) afin d’améliorer les résultats du regroupement. Cette technique a montré de bons résultats sur une tâche de désambiguïsation de pseudonymes. 6.3 Similarité sémantique entre événements Nous proposons d’évaluer la similarité entre événements, c’est-à-dire d’estimer à quel degré deux mentions d’événement peuvent référer à un seul et même événement de la réalité. Cette estimation sera utilisée dans notre application pour aider l’utilisateur final à compléter ses connaissances et à prendre des décisions de fusion d’information. Celui-ci pourra, le cas échéant, décider de fusionner deux fiches de connaissances (une interface d’aide à la fusion de fiches a été développée au sein de la plateforme WebLab) qu’il considère référer au même événement réel. Ci-après, nous détaillons les mesures de similarité mises en œuvre pour chacune des dimensions de l’événement et les exprimons selon une échelle qualitative. En effet, une échelle qualitative s’avère plus pertinente pour élaborer un processus de capitalisation orienté utilisateur : étant donné que ces similarités seront présentées à l’analyste, une estimation symbolique sera mieux comprise qu’une similarité numérique. Nous définissons cette échelle comme composée de quatre niveaux : 1. identité (ID) : les deux dimensions réfèrent à la même entité réelle, 2. proximité (PROX) : les deux dimensions ont des caractéristiques communes et pourraient référer à la même entité du monde réel, 3. différence (DIFF) : les deux dimensions ne réfèrent pas à la même entité, 4. manque d’information (MI) : il y a un manque d’information dans l’une ou les deux dimensions (résultant du document d’origine ou du système d’extraction) qui empêche de savoir si elles ré- fèrent ou non à la même entité réelle. Définition 4. Une fonction de similarité sémantique est une fonction : R : E × E → {ID, P ROX, DIF F, MI} où E est un ensemble d’événements et ID, PROX, DIFF et MI représentent respectivement l’identité, la proximité, la différence et le manque d’information. Ces niveaux sont définis et illustrés dans les sections suivantes, à travers différentes fonctions de similarité spécifiques à chaque dimension de l’événement : Rs, Rt , Rsp et Ra. 105 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6. Agrégation sémantique des événements 6.3.1 Similarité conceptuelle Soient e = (S, T, SP, A) et e 0 = (S 0 , T0 , SP0 , A0 ) deux événements et S et S 0 leurs dimensions conceptuelles respectives. Définition 5. Rs est une fonction de similarité conceptuelle : Rs : E × E → {ID, P ROX, DIF F} tel que 1. Rs(e, e0 ) = DIF F ssi S et S 0 sont deux classes différentes de l’ontologie et ne sont pas en relation de subsomption l’une avec l’autre 2. Rs(e, e0 ) = P ROX ssi S est une sous-classe (à tout niveau) de S 0 dans l’ontologie (et inversement) 3. Rs(e, e0 ) = ID ssi S et S 0 correspondent à la même classe de l’ontologie de domaine Notons ici que le niveau Manque d’Information (MI) n’est pas défini car la dimension conceptuelle d’un événement est nécessairement fournie par notre système d’extraction. En effet, celui-ci est conçu de façon telle qu’il n’y a pas d’extraction d’événement sans déclencheur d’événement et association à une classe de l’ontologie. Prenons quelques exemples pour illustrer le calcul de cette similarité conceptuelle. Exemple 2. Soient e1, e2, e3 et e4 des événements et S1, S2, S3 et S4 leurs dimensions conceptuelles respectives tel que S1 = AttackEvent, S2 = BombingEvent, S3 = SearchOperation et S4 = AttackEvent. 1. Rs(e1, e3) = DIF F car les classes S1 et S3 ne sont pas en relation de subsomption dans notre ontologie de domaine (voir l’annexe B). 2. Rs(e1, e2) = P ROX car S2 est une sous-classe de S1 dans l’ontologie (voir l’annexe B). 3. Rs(e1, e4) = ID car e1 et e4 sont des instances de la même classe d’événement dans WOOKIE (S1 = S4 = AttackEvent). 6.3.2 Similarité temporelle Soient T = [g1, g2, g3] et T 0 = [g 0 1 , g0 2 , g0 3 ] deux entités temporelles exprimées au formalisme TUS. Définition 6. Nous définissons ⊕, un opérateur de complétion temporelle, prenant en paramètres T et T 0 où T et/ou T 0 est incomplet (voir la section 4.2.2) et retourne une expression temporelle T 00 = [g 00 1 , g00 2 , g00 3 ] où : 1. si gi = g 0 i alors g 00 i = gi = g 0 i 2. si gi = ∅ alors g 00 i = g 0 i (et inversement) Exemple 3. Si T = [∅, 3, 15] et T 0 = [2012, ∅, ∅] alors T 00 = T ⊕ T 0 = [2012, 3, 15] Exemple 4. Si T = [∅, 2, ∅] et T 0 = [2013, ∅, 29] alors T 00 = T ⊕ T 0 = [2013, 2, 29] 106 Copyright c 2013 - CASSIDIAN - All rights reserved6.3. Similarité sémantique entre événements Dans certains cas, deux événements ayant deux dates d’occurrence strictement différentes selon le format TUS (niveau DIFF défini plus bas) peuvent tout de même référer au même événement dans le monde réel. Par exemple, une attaque peut durer plusieurs heures sur deux jours et ce même événement pourra être reporté avec deux dates différentes. Afin de traiter ces situations particulières, nous définissons Dt(T, T0 ), une fonction générique retournant une distance temporelle entre deux entités et un seuil dt délimitant la différence (DIFF) et la proximité (PROX) temporelle. Cette distance peut être obtenue par des librairies dédiées à la manipulation d’entités temporelles et le seuil dt défini en fonction de l’application. Soient e = (S, T, SP, A) et e 0 = (S 0 , T0 , SP0 , A0 ) deux événements, nous définissons Rt au moyen de ces différents opérateurs et seuils. Définition 7. Rt est une fonction de similarité temporelle : Rt : E × E → {ID, P ROX, DIF F, MI} telle que 1. Rt(e, e0 ) = DIF F ssi l’une des conditions suivantes est vérifiée :  ∃i∈{1,2,3} tel que gi 6= ∅ et g 0 i 6= ∅ et gi 6= g 0 i et Dt(T, T0 ) > dt si T ou T 0 est incomplet et T ⊕ T 0 retourne une date illégale (voir la section 4.2.2) 2. Rt(e, e0 ) = P ROX ssi l’une des conditions suivantes est vérifiée :  Rt(e, e0 ) = DIF F et Dt(T, T0 ) ≤ dt T ou T 0 est incomplet et T ⊕ T 0 retourne une date légale (voir la section 4.2.2) 3. Rt(e, e0 ) = ID ssi T et T 0 sont complets (voir la section 4.2.2) et ∀i∈{1,2,3} , gi = g 0 i 4. Rt(e, e0 ) = MI ssi T et/ou T 0 est inconnu (c’est-à-dire que soit l’information n’était pas présente dans la source, soit elle n’a pas été extraite par le système d’extraction) Prenons quelques exemples pour illustrer le calcul de cette similarité temporelle. Exemple 5. Soient e1, e2, e3, e4 et e5 des événements et T1, T2, T3, T4 et T5 leurs dimensions temporelles respectives tel que T1 = [2012, 11, 05], T2 = [2013, 11, 05], T3 = ∅, T4 = [2012, 11, ∅] et T5 = [2013, 11, 05]. 1. Rt(e1, e2) = DIF F 2. Rt(e1, e4) = P ROX 3. Rt(e2, e5) = ID 4. Rt(e2, e3) = MI 6.3.3 Similarité spatiale Pour estimer la similarité entre entités géographiques, nous utilisons les relations topologiques du modèle RCC-8 (présenté en section 4.2.3) ainsi que les différentes relations spatiales existantes dans la base GeoNames. Comme mentionné précédemment, la dimension spatiale peut varier avec le point de 107 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6. Agrégation sémantique des événements vue duquel un événement est rapporté : par exemple, un événement survenu à Cestas (un petit village à côté de Bordeaux) pourra être précisément situé par une agence de presse française mais pourrait être plus généralement localisé à Bordeaux (la grande ville la plus proche) par une agence étrangère. La similarité peut également être influencée par la nature des deux entités spatiales comparées (ville, pays, quartier, continent, etc.) et par la taille de la région administrative les englobant (par exemple, la distance entre deux villes du Lichtenstein ne sera pas considérée de la même façon que celle entre deux villes de Russie). Pour résumer, l’absence d’identité topologique entre deux lieux peut être due à une différence dans le niveau d’abstraction mais ne signifie pas nécessairement une différence spatiale (niveau DIFF). Pour mieux traiter ces cas, nos introduisons Dsp(SP, SP0 ), une fonction générique retournant une distance spatiale entre deux entités géographiques et un seuil dsp délimitant la différence (DIFF) et la proximité (PROX) spatiale. Cette distance peut être obtenue par des librairies dédiées à la manipulation d’entités spatiales et le seuil dsp défini en fonction de l’application. Soient e = (S, T, SP, A) et e 0 = (S 0 , T0 , SP0 , A0 ) deux événements et r une relation RCC-8 entre deux entités spatiales SP et SP0 (voir la section 1.3.2 et la figure 1.11). Définition 8. Rsp est une fonction de similarité spatiale : Rsp : E × E → {ID, P ROX, DIF F, MI} telle que 1. Rsp(e, e0 ) = DIF F ssi r(SP, SP0 ) = DC et Dsp(SP, SP0 ) > dsp 2. Rsp(e, e0 ) = P ROX ssi l’une des conditions suivantes est vérifiée :  r(SP, SP0 ) ∈ {EC, P O, T P P, NT P P, T P P i, NT P P i} r(SP, SP0 ) = DC et Dsp(SP, SP0 ) < dsp 3. Rsp(e, e0 ) = ID ssi r(SP, SP0 ) = EQ 4. Rsp(e, e0 ) = MI ssi SP et/ou SP0 est inconnu (c’est-à-dire que soit l’information n’était pas présente dans la source, soit elle n’a pas été extraite par le système d’extraction) Ces définitions théoriques sont implémentées en utilisant les relations GeoNames comme suit : Définition 9. 1. Rsp(e, e0 ) = DIF F ssi SP et SP0 ne sont liés par aucune relation topologique dans GeoNames et Dsp(SP, SP0 ) > dsp 2. Rsp(e, e0 ) = P ROX ssi (a) SP et SP0 sont liés par une relation "nearby", "neighbour" ou "children" dans la base GeoNames (b) SP et SP0 ne sont liés par aucune relation topologique dans GeoNames et Dsp(SP, SP0 ) < dsp 3. Rsp(e, e0 ) = ID ssi SP et SP0 ont le même identifiant GeoNames (c’est à dire la même URI) 4. Rsp(e, e0 ) = MI ssi SP et/ou SP0 est inconnu (c’est-à-dire que soit l’information n’était pas présente dans la source, soit elle n’a pas été extraite par le système d’extraction) Prenons quelques exemples pour illustrer le calcul de cette similarité spatiale. 108 Copyright c 2013 - CASSIDIAN - All rights reserved6.3. Similarité sémantique entre événements Exemple 6. Soient e1, e2, e3, e4 et e5 des événements et SP1, SP2, SP3, SP4 et SP5 leurs dimensions spatiales respectives tel que SP1 = P aris, SP2 = Singapour, SP3 = ∅, SP4 = F rance et SP5 = Singapour. 1. Rsp(e1, e2) = DIF F 2. Rsp(e1, e4) = P ROX 3. Rsp(e2, e5) = ID 4. Rsp(e2, e3) = MI 6.3.4 Similarité agentive Comme mentionné précédemment, l’ensemble des participants d’un événement est composé d’entités nommées de type Personne ou Organisation et ces participants sont concrètement stockés dans une base de connaissances sous la forme de chaines de caractères. Par conséquent, l’agrégation au niveau de cette dimension implique l’utilisation de mesures de similarité dédiées aux chaines de caractères mais aussi adaptées à la comparaison des entités nommées. La distance de Jaro-Winkler [Winkler et al., 2006] convient bien à notre cadre d’application en raison de son temps d’exécution modéré et sa bonne performance dans le traitement des similarités entre noms de personne notamment. Notre approche visant à rester indépendante des mesures de similarité choisies, il conviendra d’évaluer plusieurs métriques au sein de notre système de capitalisation des connaissances pour guider notre choix final et définir le seuil de distance dstr utilisé ci-dessous. Nous définissons Dstr(P, P0 ), une fonction générique retournant une distance entre deux chaines de caractères tel que Dstr(P, P0 ) = 0 signifie que les chaines de caractères représentant les participants P et P 0 sont égales. De plus, comme nous manipulons des entités nommées et non de simples chaines de caractères, nous avons exploré d’autres techniques dédiées à la résolution de coréférence entre entités nommées telles que [Finin et al., 2009]. Dans un premier temps, nous proposons d’utiliser la base sémantique DBpedia 115 pour agréger tous les noms alternatifs référant à la même entité réelle. Nous définissons alt(P) comme une fonction retournant tous les noms alternatifs donnés dans DBpedia pour une participant P. Définition 10. P et P 0 coréfèrent, noté P ' P 0 , ssi P ∈ alt(P 0 ) (et inversement) ou Dstr(P, P0 ) = 0 Par ailleurs, comme mentionné en section 4.2.4, la dimension A est définie comme un ensemble de participants, par conséquent, l’agrégation des participants d’un événement doit permettre de traiter une similarité entre ensembles. Définition 11. A et A0 coréfèrent, noté A ∼= A0 , ssi |A| = |A0 | et ∀P ∈ A, ∃P 0 ∈ A0 tel que P ' P 0 (et inversement) Soient e = (S, T, SP, A) et e 0 = (S 0 , T0 , SP0 , A0 ) deux événements tels que A = {P1, P2, . . . , Pn} et A0 = {P 0 1 , P0 2 , . . . , P0 n}. 115. ❤tt♣✿✴✴❞❜♣❡❞✐❛✳♦r❣✴ 109 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6. Agrégation sémantique des événements Définition 12. Ra est une fonction de similarité agentive : Ra : E × E → {ID, P ROX, DIF F, MI} tel que 1. Ra(e, e0 ) = DIF F ssi ∀P ∈A et ∀P0∈A0, P 6∈ alt(P 0 ) (et inversement) et Dstr(P, P0 ) > dstr 2. Ra(e, e0 ) = P ROX ssi l’une des conditions suivantes est vérifiée :  ∀P ∈A, ∃P0∈A0 tel que P ' P 0 ∀P ∈A, ∃P0∈A0 tel que Dstr(P, P0 ) ≤ dstr 3. Ra(e, e0 ) = ID ssi A ∼= A0 4. Ra(e, e0 ) = MI ssi |A| = 0 et/ou |A0 | = 0 (c’est-à-dire que soit l’information n’était pas présente dans la source, soit elle n’a pas été extraite par le système d’extraction) Prenons quelques exemples pour illustrer le calcul de cette similarité agentive. Exemple 7. Soient e1, e2, e3, e4 et e5 des événements et A1, A2, A3, A4 et A5 leurs dimensions agentives respectives tel que A1 = {Elmer Eusebio}, A2 = {Police}, A3 = {∅}, A4 = {E. Eusebio} et A5 = {Police}. 1. Ra(e1, e2) = DIF F 2. Ra(e1, e4) = P ROX 3. Ra(e2, e5) = ID 4. Ra(e2, e3) = MI 6.4 Processus d’agrégation Nous proposons un processus d’agrégation fondé sur une représentation en graphe : l’ensemble des similarités calculées est organisé en un graphe non-orienté G = (E, edges), où E est l’ensemble des sommets et chaque sommet e ∈ E est un événement extrait, et où edges est l’ensemble des arêtes et chaque arête edge est un lien entre deux sommets e et e0 défini comme une fonction de similarité multivaluée. Définition 13. La fonction edge a pour domaine de définition : edge : E × E → R où R = Rs × Rt × Rsp × Ra correspondant aux fonctions de similarité définies précédemment. Définition 14. La fonction edge est définie telle que : edge(e, e0) = hRs(e, e0), Rt(e, e0), Rsp(e, e0), Ra(e, e0)i 110 Copyright c 2013 - CASSIDIAN - All rights reserved6.4. Processus d’agrégation Cette représentation est bien adaptée à notre cadre d’application (la plateforme WebLab et les technologies du Web sémantique au sens large), car la connaissance provenant des différents services de traitement de l’information est stockée dans des bases de connaissances sémantiques fondées sur les graphes. Le graphe G est construit selon le principe suivant : chaque événement extrait (avec l’ensemble de ses dimensions) est comparé deux à deux à chacun des autres événements pour déduire un degré de similarité au niveau de chaque dimension (Rs, Rt , Rsp et Ra) (selon les principes théoriques exposés dans les sections précédentes). Nous créons ensuite dans G l’ensemble des sommets E correspondant aux événements extraits ainsi qu’une arête multivaluée de similarité edge entre chaque paire d’événements. Les similarités obtenues pour chacune des dimensions (conceptuelle, temporelle, spatiale et agentive) constituent un ensemble d’indicateurs que nous souhaitons exploiter afin de déterminer si des événements co-réfèrent. Il est communément admis dans les applications de veille en sources ouvertes que l’information manipulée par les analystes est incertaine à plusieurs niveaux : l’information en elle-même (sa véracité, sa fiabilité, etc.), la source, les traitements opérés, etc. Partant de ce constat, nous voulons laisser à l’utilisateur le choix final de fusionner (ou non) deux événements jugés similaires, et cela dans le but d’éviter toute perte d’information pouvant survenir avec une fusion entièrement automatisée. L’objectif de nos travaux est en effet, non pas de concevoir un système de fusion de fiches à proprement parler, mais plutôt d’aider l’analyste dans sa prise de décision grâce à un processus d’agrégation sémantique des événements. Pour ce faire, nous proposons d’appliquer un regroupement automatique (clustering) sur le graphe de similarités obtenu afin de guider l’analyste au sein de cet ensemble de connaissances. Différentes combinaisons de similarités sont possibles pour réaliser ce regroupement en fonction des besoins de l’utilisateur. Nous proposons, dans un premier temps, de hiérarchiser l’ensemble de ces configurations selon leur degré de similarité global (en commençant par celle qui lie les événements les plus similaires) de la manière suivante : Configuration (C1) {isConceptuallyID, isT emporallyID, isSpatiallyID, isAgentivelyID} Configuration (C2a) {isConceptuallyID, isT emporallyID, isSpatiallyID, isAgentivelyP ROX} Configuration (C2b) {isConceptuallyID, isT emporallyID, isSpatiallyP ROX, isAgentivelyID} Configuration (C2c) {isConceptuallyID, isT emporallyP ROX, isSpatiallyID, isAgentivelyID} Configuration (C2d) {isConceptuallyP ROX, isT emporallyID, isSpatiallyID, isAgentivelyID} Configuration (C3a) {isConceptuallyID, isT emporallyID, isSpatiallyP ROX, isAgentivelyP ROX} Configuration (Cn) etc. Intuitivement, la configuration C1 parait la plus à même de regrouper entre eux les événements qui co-réfèrent. Toutefois, l’incomplétude et l’hétérogénéité des données extraites est telle que cette première configuration est peu fréquemment observée dans une application réelle. De sorte que, si l’analyste souhaite retrouver dans sa base de connaissances des événements similaires, il sera plus pertinent d’explorer d’autres configurations d’agrégation. Pour cela, nous proposons de réaliser un regroupement ascendant et hiérarchique du graphe de similarités fondé sur les différentes configurations de similarités possibles. Le processus de regroupement se déroule ainsi : 111 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6. Agrégation sémantique des événements 1. Nous appliquons une première passe de regroupement selon la première configuration de notre hiérarchie C1 afin d’obtenir un premier jeu de n agrégats d’événements Ω. Ainsi, chaque sommet e ∈ Ωi est lié à tous les autres sommets de Ωi par une arête edgeC1 satisfaisant la configuration C1. Par ailleurs, chaque agrégat Ωi ainsi formé possède la caractéristique suivante : l’ensemble des arêtes edgeCn (présentes avant le premier regroupement) reliant un sommet e ∈ Ωi à un autre sommet e0 ∈ Ωj sera de même configuration de similarités. 2. Nous pouvons donc fusionner cet ensemble d’arêtes en une nouvelle arête edgeCx où Cx correspond à cette configuration commune et relie l’agrégat Ωi au sommet e ∈ Ωj . 3. Une fois ce nouvel ensemble d’arêtes créé, nous proposons d’effectuer de nouveau un regroupement selon une nouvelle configuration Cx (la suivante dans la hiérarchie) et ainsi de suite. Ce processus de regroupements successifs n’a pas vocation à être réalisé jusqu’à épuisement des configurations possibles. En effet, afin de proposer un environnement d’aide à la décision flexible et adaptable, nous envisageons de laisser l’analyste libre du nombre de regroupements qu’il souhaite effectuer ainsi que de définir ses propres configurations de regroupement. Cela sera réalisé de la façon suivante : les différents agrégats d’événements constitués après chaque phase de regroupement seront rendus accessibles à l’utilisateur au travers de diverses interfaces de la plateforme WebLab (recherche, carte géographique, bandeau temporel et autres vues). Celui-ci pourra observer les différents agrégats proposés et décider en fonction de cela du prochain regroupement à effectuer. Par exemple, l’utilisateur pourra demander au système de lui renvoyer tous les événements jugés similaires seulement sur le plan temporel (niveau PROX) et ensuite examiner les fiches d’événements correspondantes pour en déduire de nouvelles connaissances. Ce processus d’agrégation itératif et interactif sera illustré dans la section 7.3 de nos expérimentations. 6.5 Conclusions Ce chapitre nous a permis de présenter un processus d’agrégation sémantique des événements fondé sur une échelle de similarité qualitative et sur un ensemble de mesures spécifiques à chaque type de dimension. Nous avons tout d’abord proposé des mécanismes de normalisation des entités, adaptés à leurs natures, afin d’harmoniser formellement les différentes informations extraites. Concernant ce premier aspect, nous envisageons des améliorations futures telles que la désambiguïsation des dates relatives, par exemple, ou encore l’intégration au sein de notre système d’un outil de désambiguïsation des participants (tels que ceux mentionnés en section 6.2). Nous avons ensuite proposé un une échelle de similarité qualitative orientée utilisateur et un ensemble de calculs de similarité intégrant à la fois un modèle théorique adapté à chaque dimension et une implémentation technique employant les technologies du Web sémantique (ontologies et bases de connaissances externes). Nous souhaitons poursuivre ce travail en élargissant le panel de similarités employées comme en intégrant des mesures de proximité ontologique plus sophistiquées ainsi des outils de distance temporelle et spatiale (fondés sur les coordonnées géographiques par exemple) et pour la similarité agentive, une distance dédiée aux ensembles telle que SoftJaccard [Largeron et al., 2009]. L’ensemble des similarités calculées pourraient également provenir d’une fonction d’équivalence apprise automatiquement à partir de données annotées manuellement. Enfin, un processus d’agrégation fondé sur les graphes a été proposé afin de regrouper les mentions d’événements similaires et de permettre à l’analyste de découvrir de nouvelles connaissances. Ce type d’agrégation possède l’avantage principal d’être intrinsèquement adapté aux traitement des bases de connaissances et 112 Copyright c 2013 - CASSIDIAN - All rights reserved6.5. Conclusions ainsi aisément généralisable à d’autres silos du Web de données. Cette agrégation pourrait également être réalisée par calcul d’une similarité globale qui combinerait les différentes similarités locales. Le point délicat pour cette méthode sera alors d’estimer le poids de chaque dimension dans cette combinaison. Enfin, la possibilité donnée à l’utilisateur de fusionner des fiches grâce aux suggestions d’agrégats soulèvera d’autres problématiques à explorer telles que la mise à jour et le maintien de cohérence de la base de connaissance en fonction des actions de l’analyste. 113 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 6. Agrégation sémantique des événements 114 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7 Expérimentations et résultats Sommaire 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2 Évaluation du système d’extraction . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2.1 Protocole d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.2.2 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.2.3 Bilan de l’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.3 Premières expérimentions sur l’agrégation sémantique . . . . . . . . . . . . . 122 7.3.1 Implémentation d’un prototype . . . . . . . . . . . . . . . . . . . . . . . 122 7.3.2 Jeu de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.3.3 Exemples d’observations . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.3.4 Bilan de l’expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . 128 7.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 115 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats 7.1 Introduction Ce dernier chapitre présente les expérimentations réalisées durant cette thèse afin d’évaluer l’apport scientifique et technique de nos contributions. Nous commençons par une évaluation du système d’extraction d’événements conçu et implémenté tel que décrit dans le chapitre 5. Est ensuite détaillée notre seconde expérimentation appliquée cette fois-ci à l’évaluation du processus d’agrégation sémantique des événements (voir le chapitre 6). Pour chacune des évaluations, nous décrivons, tout d’abord, le système évalué et les différents corpus et paramètres utilisés pour l’expérimentation. Puis, nous présentons une analyse qualitative et/ou quantitative (par différentes métriques) des résultats obtenus. Enfin, nous exposons les différentes limites et perspectives de ces évaluations. 7.2 Évaluation du système d’extraction La première expérimentation vise à évaluer l’approche d’extraction des événements élaborée et dé- taillée en section 5.4. Nos objectifs sont, d’une part, d’estimer de façon quantitative les performances de chacune des méthodes d’extraction d’événements conçue et implémentée (l’extracteur à base de règles et celui fondé sur un apprentissage de motifs) et, d’autre part, de montrer leur complémentarité et l’utilité de les combiner. 7.2.1 Protocole d’évaluation Pour réaliser ces objectifs nous proposons d’extraire automatiquement l’ensemble des événements d’intérêt pour notre domaine d’application au sein d’une collection de textes de type journalistique en anglais et dont le thème est d’intérêt pour le ROSO. Nous nous focalisons donc sur la vingtaine de types d’événement listée en section 4.2.1 et sur leurs dimensions : temporelle (la date de l’événement), spatiale (son lieu d’occurrence) et agentive (les personnes et organisations impliquées) conformément au modèle d’événement présenté au chapitre 4.2. Nous présentons par la suite les données et les paramètres d’apprentissage ayant servi à mettre en place l’approche à base de motifs séquentiels. Précisons que la première approche symbolique n’a pas nécessité de paramétrage particulier. Données d’apprentissage Le premier ensemble de données nécessaire est un corpus d’apprentissage afin de mettre en œuvre notre système d’extraction par motifs séquentiels fréquents. Conformément aux paramètres définis en section 5.4.2, la découverte de motifs pertinents pour notre tâche d’extraction des événements nécessite un corpus de textes présentant les caractéristiques suivantes : – découpage en phrases ; – découpage en tokens; – lemmatisation ; – étiquetage grammatical ; – annotation des entités nommées (dates, lieux, personnes et organisations) ; – repérage des déclencheurs d’événements. 116 Copyright c 2013 - CASSIDIAN - All rights reserved7.2. Évaluation du système d’extraction Nous avons constitué ce corpus de manière semi-automatique à partir de 400 dépêches de presse sur l’engagement du Canada en Afghanistan collectées sur le Web 116 et de 700 dépêches parues entre 2003 et 2009 sur le site de l’ISAF 117. Dans un second temps, nous avons traité automatiquement ce corpus pour obtenir l’ensemble des annotations nécessaires : les découpages en phrases et mots ainsi que la lemmatisation ont été réalisés par des modules fournis dans GATE, l’étiquetage grammatical par l’outil TreeTagger et enfin l’annotation en entités nommées et déclencheurs d’événements grâce à notre système d’extraction d’EN et nos gazetteers d’événements. Puis, nous avons révisé manuellement ces deux derniers types d’annotation afin de corriger les éventuelles erreurs et ainsi garantir une meilleure qualité des données d’apprentissage. Enfin, un ensemble de pré-traitements spécifiques sont réalisés pour transformer l’ensemble de ce corpus au format supporté par l’outil d’extraction de motifs (notamment la constitution des itemsets). L’annexe K présente, à titre d’exemples, plusieurs phrases extraites du corpus d’apprentissage. Données de test Le second jeu de données nécessaire est un corpus de test (ou référence) permettant de comparer notre extraction d’événements par rapport à une vérité-terrain. Pour cela, nous avons choisi d’utiliser un corpus fourni dans la campagne d’évaluation MUC-4 et constitué de 100 dépêches de presse relatant des faits terroristes en Amérique du Sud. Il est fourni avec ce corpus un ensemble de fiches de référence, une seule fiche correspondant à une seule dépêche et décrivant l’événement principal relaté par celleci ainsi qu’un ensemble de propriétés. Ces fiches d’événements ne correspondant pas exactement aux besoins de cette évaluation, nous n’avons pu les réutiliser comme référence. En effet, la granularité (une seule fiche d’événement est proposée pour la totalité d’une dépêche) et le type des événements (uniquement de type ATTACK et BOMBING) ne correspondent pas à notre modélisation et ne permettent pas d’évaluer la totalité de notre approche. Par conséquent, notre évaluation porte sur une partie de ce corpus qui a été annotée manuellement, soit environ 210 mentions d’événements et près de 240 de leurs dimensions (55 dimensions temporelles, 65 dimensions spatiales et 120 dimensions agentives). L’annotation manuelle a été facilitée notamment par l’utilisation de la plateforme Glozz 118 dédiée à l’annotation et à l’exploration de corpus. L’annexe L présente, à titre d’exemple, une dépêche du corpus de test annotée avec les événements de référence. Phase d’apprentissage Nous avons, tout d’abord, opéré un apprentissage de motifs séquentiels fréquents sur le premier corpus en considérant quatre types d’item : la forme fléchie du mot, sa catégorie grammaticale, son lemme et sa classe sémantique (LookupEvent, Date, Place, Unit ou Person). Nous avons choisi de réaliser une tâche d’apprentissage par type de d’entité impliquée en utilisant le système des contraintes d’appartenance. Nous avons donc défini et employées les quatre contraintes : – Le motif retourné doit contenir un déclencheur d’événement et au minimum une entité de type Date ; 116. ❤tt♣✿✴✴✇✇✇✳❛❢❣❤❛♥✐st❛♥✳❣❝✳❝❛✴❝❛♥❛❞❛✲❛❢❣❤❛♥✐st❛♥, consulté le 21/03/2012 117. International Security Assistance Force, ❤tt♣✿✴✴✇✇✇✳♥❛t♦✳✐♥t✴✐s❛❢✴❞♦❝✉✴♣r❡ssr❡❧❡❛s❡s, consulté le 21/03/2012 118. ❤tt♣✿✴✴✇✇✇✳❣❧♦③③✳♦r❣✴ 117 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats – Le motif retourné doit contenir un déclencheur d’événement et au minimum une entité de type Place ; – Le motif retourné doit contenir un déclencheur d’événement et au minimum une entité de type Unit ; – Le motif retourné doit contenir un déclencheur d’événement et au minimum une entité de type Person. Nous obtiendrons donc après apprentissage quatre ensembles de motifs de type LookupEvent-Date, LookupEvent-Place, LookupEvent-Person et LookupEvent-Unit. Au préalable, il est nécessaire de fixer les deux paramètres de support et de gap (voir la section 5.4.2) : le premier donnant le nombre d’occurrences minimal du motif dans l’ensemble des séquences et le second permettant de "relâcher" la composition des motifs en autorisant un nombre maximal de mots possibles entre chaque élément du motif. Ce paramétrage a été effectué de façon itérative : nous avons fixé une première de valeur de support et de gap pour chaque apprentissage, effectué une première extraction de motifs, estimé leur qualité (en observant leur nombre, leur généricité/spécificité, leur couverture/précision), puis ajusté ces paramètres en fonction de nos observations. Le tableau 7.2 présente le nombre de motifs retournés par type de motif en fonction des paramètres choisis. Au regard de ces tests, nous avons choisi de fixer un gap maximal de 3 (correspondant à 3 mots possibles entre chaque élément du motif) et un support absolu relativement bas (environ 6% des séquences) afin d’obtenir des motifs intéressants mais en nombre raisonnable pour une exploration et une validation manuelles (environ 12000 motifs au total). Une fois l’ensemble des motifs raffinés par les contraintes d’appartenance et de gap, nous avons sélectionnés manuellement et les plus pertinents grâce à l’outil Camelis. La figure 7.1 suivante présente certains des motifs retenus 119, nous en avons conservés au total une cinquantaine. 1 { P e r s o n }{ VBD }{ DT }{ NN }{ IN }{ DT }{ E v e nt } 2 { , }{ DT }{ NN }{ E v e nt }{ J J }{ IN }{ P l a c e } 3 { J J }{ E v e nt }{ NP }{ NP }{ Date } 4 { s e r v e VBG }{ IN a s }{ a }{ NN }{ IN }{ t h e }{ J J }{ NP U nit }{ E v e nt } FIGURE 7.1 – Exemples de motifs séquentiels fréquents sélectionnés Pour finir, le jeu de motifs final a été converti en un ensemble de règles JAPE, nous obtenons donc un module indépendant facilement intégrable au sein de notre chaine globale d’extraction d’événements. Évaluation réalisée Une fois cette phase d’apprentissage accomplie, nous avons constitué trois chaines d’extraction GATE distinctes : Chaine 1 Approche à base de règles linguistiques (voir la section 5.4.1) ; Chaine 2 Approche par apprentissage de motifs (voir la section 5.4.2) ; 119. Les items des motifs correspondent aux catégories grammaticales et aux annotations sémantiques telles que VBD : auxiliaire "être" au passé, DT : déterminant, NN : nom commun au singulier, IN : préposition, JJ : adjectif, NP : nom propre au singulier, VBG : auxiliaire "être" au participe présent, Person : entité nommée de type personne, Event : déclencheur d’événement équivalant à l’étiquette LookupEvent ci-dessus, Place : entité nommée de type lieu, Date : entité nommée de type date, Unit : entité nommée de type organisation. 118 Copyright c 2013 - CASSIDIAN - All rights reserved7.2. Évaluation du système d’extraction LookupEvent-Date LookupEvent-Place LookupEvent-Person LookupEvent-Unit Sup3 Gap0 - - - 1381 Sup4 Gap0 113 - 67748 - Sup4 Gap2 - - - 18278 Sup6 Gap0 - 1000 - - Sup6 Gap2 1046 - - 2039 Sup8 Gap0 30 317 - - Sup8 Gap2 699 - - 725 Sup8 Gap3 1108 - - - Sup10 Gap2 - 8693 1730 344 Sup10 Gap3 681 6596 9540 47 Sup12 Gap3 - - 4614 - FIGURE 7.2 – Nombre de motifs retournés en fonction des paramètres choisis Chaine 3 Union des deux approches : elle contient l’ensemble des pré-traitements nécessaires à chaque approche (listés en section 5.4) ainsi que les deux modules de règles développés exécutés successivement. Ces trois chaines ont été exécutées sur le corpus de test et nous avons comparé manuellement et par document la qualité des événements extraits aux événements de référence correspondants. Cela nous a permis de calculer des scores de précision, rappel et F1-mesure (voir la section 2.5.1 pour la définition de ces métriques) pour chaque chaine. Par ailleurs, nous avons souhaité évaluer l’influence de l’analyse syntaxique en dépendance et de la qualité de la REN sur nos systèmes d’extraction d’événements. Le tableau 7.1 ci-dessous résume les différentes variantes des chaines évaluées et dont les résultats sont présentés dans la section suivante. Règles manuelles Motifs séquentiels Union des résultats Avec analyse syntaxique x x Sans analyse syntaxique x x REN automatique x x x REN manuelle x x x TABLE 7.1 – Chaines d’extraction d’événements : variantes évaluées 7.2.2 Analyse des résultats Le tableau 7.2 présente les scores de précision, rappel et F1-mesure obtenus : il s’agit des résultats d’évaluation des 3 chaines présentées plus haut par type de dimension et toutes dimensions confondues. Précisons qu’il s’agit des métriques calculées avec une annotation manuelle des entités nommées pour les 3 chaines et avec analyse syntaxique en dépendance pour la chaine 1. Nous pouvons tout d’abord constater que l’approche à base de règles et l’apprentissage de motifs obtiennent tous deux une très bonne précision globale et que, comme attendu, le rappel est meilleur pour cette dernière approche. Par ailleurs, nous avons été assez surpris par la bonne précision de la méthode par 119 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats Approche à base de règles manuelles Apprentissage de motifs Union des résultats Précision Rappel F1-mesure Précision Rappel F1-mesure Précision Rappel F1-mesure Date 0,93 0,25 0,39 0,90 0,64 0,75 0,90 0,68 0,78 Lieu 0,92 0,37 0,53 0,86 0,49 0,63 0,81 0,60 0,69 Participants 0,97 0,49 0,42 0,93 0,32 0,47 0,92 0,51 0,66 Toutes dimensions 0,94 0,37 0,45 0,90 0,48 0,62 0,88 0,60 0,71 TABLE 7.2 – Extraction d’événements : précision, rappel et F-mesure apprentissage, que nous expliquons par une sélection manuelle restrictive et précise des motifs. Quant aux taux de rappel peu élevés, ce n’est pas rare pour les approches à base de règles construites manuellement et, dans le cas de l’apprentissage de motifs, cela peut être du à un "gap" maximal trop restreint qui ne permet pas d’extraire les relations distantes. Par ailleurs, une analyse des résultats par type de dimension permet d’en apprendre sur les points forts et faiblesses de chacune des approches développées. Nous pouvons, par exemple, voir que le système à base de motifs séquentiels est nettement plus performant pour la reconnaissance des dates des événements. Concernant la dimension spatiale, bien que celle-ci soit meilleure en termes de F1-mesure, l’approche symbolique s’avère plus précise. Enfin, tandis que pour ces deux premières dimensions (temporelle et spatiale) l’union des résultats apporte peu par rapport à la meilleure des deux approches, celle-ci s’avère particulièrement utile pour la dimension agentive. Enfin, nous pouvons retenir de cette expérimentation que l’union des résultats obtient une F1-mesure nettement supérieure (près de 10 points par rapport à la meilleure des deux approches), ce qui dénote une amélioration globale de la qualité d’extraction pour tout type de dimension. De plus, nous remarquons que l’apprentissage de patrons complète avec succès notre approche symbolique en augmentant sensiblement le taux global de rappel. Nous constatons tout de même une légère perte de précision de l’union par rapport aux deux approches seules : celle-ci résulte du fait que réaliser une simple union des résultats, même si elle permet d’additionner les vrais positifs des deux approches, entraine aussi une addition des faux positifs. Toutes approches confondues, les résultats obtenus sont satisfaisants comparés à l’état de l’art même s’il convient de prendre des précautions lorsque l’on compare des systèmes évalués selon différents protocoles. Apport de l’analyse syntaxique Parallèlement à ces résultats, nous nous sommes intéressés à l’apport de l’analyse syntaxique au sein de notre approche symbolique. Le tableau 7.3 présente les performances de notre système avec et sans analyse syntaxique en dépendance. Nous pouvons constater que celle-ci permet d’augmenter sensiblement la qualité des extractions pour tous les types de dimension. Bien que les outils d’analyse syntaxique soient inégalement disponibles selon les langues, cette observation confirme l’intérêt de cette technique pour l’extraction des événements. Une perspective intéressante serait d’exploiter les résultats de l’analyse syntaxique au sein de la seconde approche en tant que caractéristique supplémentaire à prendre en compte lors de l’apprentissage des motifs séquentiels fréquents. Influence de la reconnaissance automatique des entités nommées Pour compléter les résultats précédents fondés sur une annotation manuelle des entités nommées, nous avons évalué les 3 chaines avec une annotation automatique des entités (voir la section 5.3). En 120 Copyright c 2013 - CASSIDIAN - All rights reserved7.2. Évaluation du système d’extraction Sans analyse syntaxique Avec analyse syntaxique Précision Rappel F1-mesure Précision Rappel F1-mesure Date 0,32 0,45 0,38 0,93 0,25 0,39 Lieu 0,86 0,18 0,30 0,92 0,37 0,53 Participants 0,90 0,31 0,46 0,97 0,49 0,42 Toutes dimensions 0,69 0,31 0,38 0,94 0,37 0,45 TABLE 7.3 – Extraction d’événements : apport de l’analyse syntaxique effet, les entités nommées étant repérées de façon automatique dans les applications réelles, il est important d’estimer quelle sera l’influence de cette automatisation sur l’extraction des événements. Le tableau 7.4 ci-dessous compare les performances de la 3ème chaine d’extraction (c’est-à-dire l’union des deux approches) avec une REN réalisée manuellement ou automatiquement. Nous observons une baisse géné- rale de la qualité des extractions qui s’explique par le fait que notre système d’extraction des événements dépend de ces entités nommées pour la reconnaissances des différentes dimensions. Par conséquent, si une entité nommée impliquée dans un événement n’a pas été reconnue, celui-ci ne pourra la reconnaître en tant que dimension de cet événement (ce qui fait diminuer le rappel de notre approche). Par ailleurs, si une entité a bien été reconnue mais mal catégorisée ou mal délimitée cela entrainera une perte de pré- cision pour notre extracteur d’événements. Malgré cette influence négative sur les résultats globaux, les scores obtenus par notre approche restent à la hauteur de l’état de l’art. REN manuelle REN automatique Précision Rappel F1-mesure Précision Rappel F1-mesure Date 0,90 0,68 0,78 0,86 0,64 0,73 Lieu 0,81 0,60 0,69 0,94 0,46 0,62 Participants 0,92 0,51 0,66 0,94 0,39 0,55 Toutes dimensions 0,88 0,60 0,71 0,91 0,50 0,64 TABLE 7.4 – Extraction d’événements : influence de la REN 7.2.3 Bilan de l’évaluation Cette première évaluation a permis les observations suivantes : 1. les deux approches proposées pour l’extraction des événements obtiennent des résultats équivalents voire supérieurs aux systèmes existants (voir la section 2.5.2) ; 2. l’analyse syntaxique en dépendance des phrases améliore significativement la qualité des extractions réalisées par l’approche symbolique ; 3. les performances globales de notre approche sont impactées à un niveau acceptable par la détection automatique des entités nommées ; 4. les deux techniques mises en œuvre pour l’extraction des événements présentent des forces complémentaires ; 5. une union de leurs résultats (peu coûteuse à réaliser) permet d’améliorer sensiblement la qualité des événements extraits. 121 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats Nous dressons donc un bilan positif de cette première évaluation. Toutefois, celle-ci présente des limites qui donnent lieu à plusieurs perspectives d’amélioration. Tout d’abord, la conclusion 1 bien que vraie si l’on compare les scores obtenus, doit être nuancée car il s’avère toujours difficile de comparer des systèmes d’extraction ayant été évalués selon des protocoles différents. L’influence de la REN automatique révèle une problématique plus largement présente dans le contexte du Media Mining : il s’agit de l’interdépendance des modules de traitement et du suivi de qualité tout au long de la chaine de traitement. Dans notre cas de figure, il serait intéressant de mettre en place une réelle collaboration (et non plus une simple juxtaposition) entre les modules de REN et d’extraction d’événements en explorant, par exemple, les travaux sur la qualité des annotations. Par ailleurs, suite à l’observation 2, nous souhaiterions amé- liorer notre approche d’extraction de motifs séquentiels avec de nouvelles caractéristiques issues d’une analyse syntaxique. Celles-ci pourraient notamment servir en tant que contraintes supplémentaires afin de limiter la quantité de motifs retournés. Enfin, évaluer les résultats obtenus par une simple union des deux approches a mis en exergue leurs complémentarités et de nouvelles pistes d’exploration pour élaborer une combinaison plus adaptée. Dans le cadre de nos travaux, nous avons choisi de réaliser l’extraction selon les deux approches successivement et de gérer cette problématique sur le même procédé que les mentions d’événements provenant de différents documents. 7.3 Premières expérimentions sur l’agrégation sémantique Cette seconde expérimentation vise à évaluer le prototype d’agrégation sémantique des événements que nous avons développé selon l’approche présentée au chapitre 6. Nous présentons, dans un premier temps, les principales caractéristiques techniques de ce prototype puis le jeu de données employé pour cette expérimentation. Par la suite, nous présentons nos premiers résultats et concluons par un bilan de cette expérimentation ainsi que les perspectives envisagées. 7.3.1 Implémentation d’un prototype L’approche proposée au chapitre 6 a été implémentée au sein de plusieurs services (en langage Java) permettant de traiter un ensemble de documents au format WebLab issus du service d’extraction d’information développé (voir la section 5.4). Un exemple de document contenant des événements extraits par notre système et représentés en RDF/XML selon le schéma l’ontologie WOOKIE est proposé en annexe I. L’ensemble des connaissances créé et modifié par ces services est stocké et géré au sein de bases de connaissances sémantiques grâce au triplestore Jena Fuseki 120. Dans un premier temps, les événements extraits ainsi que leurs dimensions provenant du système d’extraction sont stockés dans une première base de connaissances A régie par notre ontologie de domaine (voir la section 4.3). Les différents calculs de similarité ont été implémentés au sein d’un premier service qui présente les fonctionnalités suivantes (le reste des fonctions restant comme perspectives à nos travaux) : – similarité conceptuelle : implémentation par des tests de subsomption ontologique (telle que pré- sentée en section 6.3.1) ; – similarité temporelle : implémentation telle que proposée en section 6.3.2 mais sans la fonction de distance temporelle ; 120. ❤tt♣✿✴✴❥❡♥❛✳❛♣❛❝❤❡✳♦r❣✴❞♦❝✉♠❡♥t❛t✐♦♥✴s❡r✈✐♥❣❴❞❛t❛✴ 122 Copyright c 2013 - CASSIDIAN - All rights reserved7.3. Premières expérimentions sur l’agrégation sémantique – similarité spatiale : implémentation du service de désambiguïsation spatiale par GeoNames (voir la section 6.3.3) mais sans la fonction de distance spatiale ; – similarité agentive : implémentation par distance de Jaro-Winkler comme proposé en section 6.3.4, la désambiguïsation avec DBPedia reste à mettre en place. Les calculs de similarité sont combinés grâce à la librairie Apache Jena 121 et son mécanisme de règles d’inférence (voir l’annexe J pour un exemple de règle). Le moteur d’inférence développé est appliqué à la base A qui se trouve ainsi augmentée de l’ensemble des liens de similarité. Un second service réalise le processus d’agrégation sémantique : celui-ci permet de définir une confi- guration et d’appliquer une phase de regroupement au graphe de similarité entre événements (chargé dans la base A). Une fois le regroupement réalisé, c’est-à-dire lorsque le premier graphe a été enrichi avec les agrégats d’événements similaires, celui-ci est stocké dans une seconde base de connaissances B. Cette base sera alors disponible et interrogeable par les services de la plateforme WebLab pour présenter les agrégats à l’utilisateur final par divers modes de visualisation. Cette implémentation constitue une première preuve de concept pour montrer la faisabilité de notre processus d’agrégation sémantique. Toutefois, le système que nous avons conçu n’est, à l’heure actuelle, pas apte à passer à l’échelle pour obtenir des résultats significatifs sur un corpus d’évaluation à taille réelle. Ce passage à l’échelle constitue la principale perspective à court terme de nos travaux. Nous présentons dans les sections suivantes les observations que nous avons pu réaliser sur un jeu de données réelles plus réduit. 7.3.2 Jeu de données Pour cette expérimentation, nous nous appuyons sur une base de données nommée Global Terrorism Database (GTD). Il s’agit d’une base open-source contenant plus de 104 000 événements terroristes recensés manuellement de 1970 à 2011 [LaFree and Dugan, 2007]. Cette collection est gérée par le consortium américain START 122 étudiant les faits terroristes survenus dans le monde. Celle-ci est constituée à la fois d’événements d’échelle internationale et nationale, principalement collectés à partir de sources d’actualité sur le Web mais aussi provenant de bases de données existantes, livres, journaux et documents légaux. Les événements dans la base GTD sont catégorisés selon les neuf types suivants : 1. Assassination 2. Hijacking 3. Kidnapping 4. Barricade Incident 5. Bombing/Explosion 6. Unknown 7. Armed Assault 8. Unarmed Assault 9. Facility/Infrastructure Attack 121. ❤tt♣s✿✴✴❥❡♥❛✳❛♣❛❝❤❡✳♦r❣✴ 122. Study of Terrorism and Responses to Terrorism 123 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats En fonction de son type, un événement peut présenter entre 45 et 120 propriétés/attributs tels que les suivants : – type de l’événement ; – date de l’événement (année, mois, jour) ; – lieu de l’événement (région, pays, état/province, ville, latitude/longitude) ; – auteur(s) (personne ou groupe) ; – nature de la cible ; – type de l’arme utilisée ; – dommages matériels ; – nombre de décès ; – nombre de blessés ; – résumé ; – indice de certitude ; – sources (1 à 3) : nom de la source, extrait (titre), date de l’article, URL ; – etc. L’ensemble de ces données est représenté sous forme de couples "champ-valeur" et téléchargeable au format CSV. Nous disposons d’ores et déjà d’une partie de cette base (environ 4800 fiches d’événements survenus en 2010) convertie en base de connaissance sémantique (graphe RDF). Cette base de données est bien adaptée à l’évaluation de notre processus global de capitalisation des connaissances car elle constitue une collection de fiches d’événements manuellement agrégées à partir de plusieurs sources d’information. Les sources (articles et dépêches principalement) à l’origine d’une fiche sont accessibles via l’attribut scite qui spécifie leurs URLs. Une collecte automatique de ces sources (grâce à un service WebLab) permet donc facilement de constituer un corpus d’évaluation composé de dépêches de presse et des fiches d’événements correspondantes. Il faut noter également que cette base est fondée sur une modélisation différente de celle définie dans le cadre de nos recherches (l’ontologie WOOKIE). Il nous faut donc trouver le meilleur alignement de classes et attributs afin de pouvoir évaluer les résultats de notre approche par rapport aux fiches de référence de la base GTD. Le modèle d’événement employé par cette base étant sensiblement similaire au nôtre, l’alignement des attributs d’intérêt (date, lieu et participants) n’a pas soulevé de difficultés. Concernant la taxonomie des événements, 4 classes (sur les 9 du modèle GTD) ont pu être alignées avec le modèle WOOKIE car ayant la même sémantique (voir le tableau 7.5). Nos expérimentations sont donc limitées par ce point et ne concernent que des événements de ces 4 types. Modèle GTD Ontologie WOOKIE Facility/Infrastructure Attack DamageEvent Bombing/Explosion BombingEvent Armed Assault AttackEvent Hostage Taking KidnappingEvent TABLE 7.5 – Alignement des types d’événement entre le modèle GTD et l’ontologie WOOKIE 124 Copyright c 2013 - CASSIDIAN - All rights reserved7.3. Premières expérimentions sur l’agrégation sémantique 7.3.3 Exemples d’observations Calculs de similarité Nous présentons ici un exemple d’application à ce jeu de données de la similarité sémantique entre événements : nous collectons et analysons trois dépêches de presse (que nous nommerons source1, source2 et source3) à l’origine d’une même fiche d’événement issue de la base GTD 123 et résumée par la figure 7.3. Le tableau suivant 7.6 présente quatre des événements extraits automatiquement par FIGURE 7.3 – Un exemple d’événement issu de la base GTD notre système à partir de ces sources, ainsi que leurs dimensions. Event1 Event2 Event3 Event4 rdfs :label explosions explosions bomb blasts attacked rdf :type BombingEvent BombingEvent BombingEvent AttackEvent wookie :date - [∅ ,10,31] - - wookie :takesPlaceAt Atirau city - - Kazakstan wookie :involves - KNB department Kazakh Police - source scite1 scite2 scite3 scite2 TABLE 7.6 – Événements extraits et leurs dimensions Nous constatons dans cet exemple que, sans post-traitement adapté, ces quatre événements seraient présentés à l’utilisateur final de façon distincte et sans aucun lien entre eux (quatre fiches de connaissance différentes seraient créées). Toutefois, appliquer notre modèle de similarité sémantique entre événements, permet de compléter cet ensemble de connaissances avec des relations de similarité entre ces quatre fiches de connaissance. La figure 7.4 constitue un extrait des différentes similarités obtenues représentées en RDF/XML. Tout d’abord, une proximité conceptuelle a été détectée entre les événements Event2 et Event4 (ligne 9) de par le fait que le type de l’événement Event2 est une sous-classe de celui de l’événement Event4 dans l’ontologie de domaine. De plus, le service de désambiguïsation géographique ayant assigné des identifiants GeoNames aux entités Atirau city et Kazahstan, nous pouvons appliquer 123. National Consortium for the Study of Terrorism and Responses to Terrorism (START). (2012). Global Terrorism Database [Data file]. Retrieved from ❤tt♣✿✴✴✇✇✇✳st❛rt✳✉♠❞✳❡❞✉✴❣t❞ 125 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats le calcul de similarité spatiale et déduire que les événements Event1 et Event4 sont spatialement proches (ligne 5). Enfin, la fonction de similarité agentive utilisant la distance de Jaro-Winkler a permis d’estimer que les participants des événements Event2 et Event3 ne co-réfèrent pas (ligne 10). 1 < r d f : D e s c r i p t i o n r d f : a b o u t = " # E ve nt 1 " > 2 3 4 5 6 < / r d f : D e s c r i p t i o n > 7 < r d f : D e s c r i p t i o n r d f : a b o u t = " # E ve nt 2 " > 8 9 10 11 < / r d f : D e s c r i p t i o n > 12 < r d f : D e s c r i p t i o n r d f : a b o u t = " # E ve nt 3 " > 13 14 < / r d f : D e s c r i p t i o n > FIGURE 7.4 – Similarités entre événements : extrait représenté en RDF/XML Processus d’agrégation Dans un second temps, notre processus global d’agrégation a été testé sur un sous-ensemble du corpus GTD : l’ensemble des traitements (extraction, calculs de similarité et agrégation sémantique) a été appliqué sur 60 dépêches de presse collectées du Web. Nous pouvons déjà faire quelques observations chiffrées sur ce corpus de test et les résultats obtenus : (a) 92 fiches d’événements de référence correspondent à ces 60 dépêches ; (b) la majorité des dépêches (40) est associée à une seule fiche de référence, 15 dépêches relatent chacune 2 événements de référence et les 5 restantes renvoient chacune à 3 événements ; (c) 223 mentions d’événements ont été repérées par notre approche d’extraction (tous types confondus) ; (d) 44 de ces événements extraits font partie des 4 types de l’alignement (voir le tableau 7.5 et ont pu donc être évalués ; (e) ces 44 mentions d’événements comprennent 20 AttackEvent, 14 BombingEvent, 2 DamageEvent et 8 KidnappingEvent ; (f) parmi ces 44 mentions, 3 possèdent une date, 7 présentent un lieu extrait et 5 impliquent des participants. Nous nous sommes ensuite intéressés aux différentes relations de similarité de type ID et PROX (les plus pertinentes pour rapprocher des événements similaires) créées entre les 44 événements extraits : – 20 relations de type isConceptuallyID ont été détectées ; – 17 relations de type isConceptuallyPROX ; – 4 relations de type isAgentivelyID ; – 3 relations de type isSpatiallyPROX. 126 Copyright c 2013 - CASSIDIAN - All rights reserved7.3. Premières expérimentions sur l’agrégation sémantique Nous pouvons constater que peu de relations de ce type ont été détectées. Cela est, tout d’abord, à corréler avec l’observation (f) faite plus haut, montrant que, parmi les 44 événements extraits et analysables, peu de dimensions ont été extraites. Ce manque est du notamment à une limite de notre corpus d’évaluation mise en avant par l’observation (b) : chaque événement du jeu de données est rapporté au maximum par 3 sources, ce qui ne reflète pas les conditions réelles d’un processus de veille, où de nombreuses sources et articles reportant le même événement sont quotidiennement collectés et analysés. Dans un second temps, nous avons appliqué un premier regroupement avec pour condition de regrouper entre eux les événements partageant au minimum une similarité de niveau ID et une similarité de niveau PROX. Au vu des relations de similarité ci-dessus, seules deux configurations ont permis d’obtenir des agrégats : – {isConceptuallyID, isT emporallyLI, isSpatiallyLI, isAgentivelyID} produit 3 agrégats d’événements ; – {isConceptuallyP ROX, isT emporallyLI, isSpatiallyP ROX, isAgentivelyLI} produit 1 agrégat d’événements. Appliqué sur les 3 agrégats produits par la première configuration, un second regroupement par la configuration {isConceptuallyDIF F, isT emporallyLI, isSpatiallyLI, isAgentivelyID} permet d’obtenir un agrégat contenant les trois événements présentés dans le tableau 7.7. Deux des événements proviennent d’une même source (Event2 et Event3) et le troisième (Event1) d’une source différente, celles-ci sont reportées en annexes M et N. Event1 Event2 Event3 gtd :source s3 s12 s12 rdfs :label kidnapping kidnapped bomb wookie :involves Taliban Taliban TABLE 7.7 – Exemple de 3 événements agrégés automatiquement Afin d’évaluer l’apport de cette agrégation, nous avons examiné les fiches de référence associées aux deux sources dont ces événements ont été extraits : la source s3 renvoie à un seul événement (que nous nommerons Reference1) et la source s12 renvoie à deux événements (que nous nommerons Reference2 et Reference3). Le tableau 7.8 ci-dessous présente ces trois fiches de référence ainsi que quelques propriétés d’intérêt pour cette expérimentation. Nous pouvons, à partir de cet exemple, faire les observations suivantes : – Les trois extractions d’événements réalisées correspondent bien aux fiches de référence associées à leurs sources respectives ; – Les deux regroupements successifs ont permis d’agréger 3 événements perpétrés par le même agent ("Taliban") ; – Une géolocalisation des 3 événements de référence (voir la figure 7.5) montrent que les 3 événements agrégés se sont produits dans la même zone géographique. Bien que les lieux des 3 événements n’aient pas été repérés automatiquement, l’agrégation permettrait à l’analyste de découvrir cette proximité (en remontant par exemple aux sources des trois événements) ; – Dans l’hypothèse qu’avec une plus grande quantité de sources analysées les dimensions manquantes (date et lieu) auraient pu être extraites, l’analyste aurait pu analyser la répartition spatiale et temporelle de ces 3 événements afin d’en déduire de nouvelles connaissances ou de nouvelles prédictions. 127 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats Reference1 Reference2 Reference3 eventID 201009260002 201001230002 201001230007 source s3 s12 s12 year 2010 2010 2010 month 9 1 1 day 26 23 23 country Afghanistan Afghanistan Afghanistan region South Asia South Asia South Asia province/state Konar Konar Paktika city Chawkay Shigal Unknown attackType1 Hostage Taking (Kidnapping) Hostage Taking (Kidnapping) Armed Assault attackType2 Armed Assault targetType1 NGO Police Transportation corp1 Development Alternatives Inc Sheigal Law Enforcement target1 Linda Norgrove police chief of Sheigal district and two other police officers Civilians targetType2 NGO corp2 Development Alternatives Inc target2 Three Afghan aid employees perpetrator Taliban Taliban Taliban TABLE 7.8 – Fiches d’événements de référence FIGURE 7.5 – Visualisation des 3 événements extraits sur une carte géographique 7.3.4 Bilan de l’expérimentation Cette première expérimentation a montré des résultats prometteurs à la fois pour notre approche de similarité entre événements et pour le processus d’agrégation sémantique en tenant compte de ces similarités. En effet, nous avons montré que notre approche globale peut être mise en œuvre sur des 128 Copyright c 2013 - CASSIDIAN - All rights reserveddonnées réelles sans nécessiter d’effort d’adaptation important et en maintenant le niveau de qualité escompté. Toutefois, celle-ci présente un certain nombre de limites qui constituent autant de perspectives à explorer à l’avenir. Tout d’abord, nous souhaitons améliorer notre prototype en implémentant la totalité des mesures de similarité proposées en section 6.3 (distances temporelles et spatiales ainsi que la desambiguïsation agentive grâce à la base DBPedia). De plus, nous complèterons le service de regroupement en y intégrant le procédé de regroupement hiérarchique par plusieurs passes (une seule passe est réalisée pour le moment). Enfin, des problèmes techniques empêchent, à l’heure actuelle, d’obtenir des résultats significatifs et quantitatifs sur un plus grand ensemble de données. Ce passage à l’échelle constitue notre plus proche perspective future et permettra d’évaluer notre approche de façon exhaustive et avec des métriques adaptées (issues par exemple de l’évaluation des méthodes de clustering) sur l’ensemble du jeu de données présenté en section 7.3.2 : soit environ 5000 événements de référence. Cette évaluation devra principalement permettre de répondre aux deux questions suivantes : – est-ce que les événements extraits correspondant à une seule et même fiche de référence sont bien rapprochés ? – est-ce que les événements extraits ne correspondant pas à la même fiche de référence sont bien différenciés ? 7.4 Conclusions Dans ce dernier chapitre, nous avons présenté deux expérimentations destinées à évaluer deux de nos contributions. Tout d’abord, une première évaluation a porté sur notre approche mixte d’extraction automatique des événements : celle-ci a été testée et comparée à un corpus de référence annoté manuellement pour les besoins de l’expérimentation. Pour ce faire, nous avons effectué une évaluation en termes de précision/rappel/F1-mesure et cela selon différentes configurations : chaque approche a été évaluée séparément puis comparée à l’union de leurs résultats. Nous avons également fait varier diffé- rents paramètres tels que la présence de l’analyse syntaxique ou encore l’automatisation de la REN. Une analyse détaillée des résultats a montré de bonnes performances en comparaison avec l’état de l’art et ceci pour l’ensemble des configurations d’évaluation testées. Cette première évaluation a également pointé quelques limites de notre approche telles que l’impact de l’extraction d’entités nommées sur les performances des extracteurs d’événements. De plus, celle-ci pourrait être améliorée en exploitant davantage les informations fournies par l’analyse syntaxique en dépendance. La seconde expérimentation a constitué une première analyse qualitative dans le but d’illustrer les résultats de notre processus d’agrégation sémantique sur un jeu de données réelles. Nous avons présenté, dans un premier temps, l’implémentation d’un prototype fonctionnel couvrant la chaine complète d’agré- gation des événements. Puis, la base de données Global Terrorism Database a été introduite ainsi qu’un sous-ensemble de celle-ci servant de corpus d’évaluation pour cette expérimentation. Les tests réalisés se sont avérés prometteurs à la fois pour ce qui est du calcul de similarité entre événements et du processus d’agrégation proposé. Le premier traitement a rapproché efficacement des mentions d’événements qui co-réfèrent et permettra ainsi de réduire la tâche de l’analyste du ROSO en lui proposant l’ensemble des liens de similarité en tant que critères supplémentaires de recherche. Puis, nous avons appliqué notre processus d’agrégation par regroupements successifs sur ce jeu de test et ceci pour pour 3 types de confi- guration. Malgré le peu d’agrégats formés (en raison de la taille réduite du corpus), nous avons montré 129 Copyright c 2013 - CASSIDIAN - All rights reservedChapitre 7. Expérimentations et résultats par un exemple l’utilité de cette agrégation du point de vue utilisateur. Cette seconde contribution pourra être améliorée en intégrant l’ensemble des fonctions de similarité proposées à notre prototype d’agrégation et en optimisant celui-ci pour permettre son passage à l’échelle d’un processus de veille réel. 130 Copyright c 2013 - CASSIDIAN - All rights reservedConclusion et perspectives Sommaire 1 Synthèse des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 1.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 1.2 Un modèle de connaissances pour le ROSO . . . . . . . . . . . . . . . . 133 1.3 Une approche mixte pour l’extraction automatique des événements . . . . 134 1.4 Un processus d’agrégation sémantique des événements . . . . . . . . . . 134 1.5 Évaluation du travail de recherche . . . . . . . . . . . . . . . . . . . . . . 135 2 Perspectives de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 131 Copyright c 2013 - CASSIDIAN - All rights reservedConclusion et perspectives 1 Synthèse des contributions La problématique étudiée durant cette thèse est la capitalisation des connaissances à partir de sources ouvertes. Nous nous sommes plus particulièrement intéressés à l’extraction et à l’agrégation automatique des événements dans le domaine du Renseignement d’Origine Sources Ouvertes. Ce sujet de recherche nous a amenés à explorer les principaux axes de recherche suivants : – La représentation et la modélisation des connaissances ; – L’extraction automatique d’information ; – La capitalisation des connaissances. Pour répondre à cette problématique, nous avons, dans une première phase de nos recherches, réalisé un état de l’art approfondi de ces trois axes scientifiques. 1.1 État de l’art Nous avons, tout d’abord, exploré les principes théoriques et les recherches actuelles dans les domaines de la représentation des connaissances, du Web sémantique et de la modélisation des événements. Ce premier état de l’art a rappelé la distinction fondamentale entre les concepts de donnée, information et connaissance. Il a également confirmé l’importance croissante des technologies du Web sémantique qui sont partie intégrante d’une majorité de travaux actuels en fouille de documents. Les ontologies, plus particulièrement, se positionnement comme un mode de représentation des connaissances en adéquation avec les nouvelles problématiques du traitement de l’information. Combinées aux bases de connaissances sémantiques et moteurs d’inférence, cela constitue un socle de technologies particulièrement adapté à la capitalisation des connaissances à partir de sources ouvertes. Dans un second temps, nous nous sommes focalisés sur la place des événements en représentation des connaissances et avons étudié les différentes théories, modèles et ontologies proposés jusqu’alors. L’événement apparait comme un concept complexe, dont la définition et la modélisation sont encore aujourd’hui des sujets de discussions et débats. Beaucoup de travaux s’accordent sur un objet multi-dimensionnel impliquant une situation spatio-temporelle et un ensemble d’acteurs et facteurs. Nous avons également exploré les spécifications utilisées par les acteurs du renseignement afin d’adapter notre proposition à ce cadre d’application. La seconde revue de littérature a été centrée sur l’extraction automatique d’information dans les textes. Celle-ci a révélé un domaine de recherche très étudié bien que relativement jeune : nous avons pu recenser un nombre important d’approches, d’applications possibles, de logiciels et plateformes développés ainsi que de campagnes et projets d’évaluation menés jusqu’à nos jours. Les méthodes développées sont historiquement réparties en deux catégories : les symboliques et les statistiques. Les premières, dé- veloppées manuellement par des experts de la langue, s’avèrent globalement plus précises, tandis que les secondes réalisent un apprentissage sur une grande quantité de données et présentent généralement un fort taux de rappel. Parallèlement à cela, nous avons constaté une certaine complémentarité des approches existantes, non seulement en termes de précision et de rappel mais également du point de vue des types d’entités ciblées, du genre textuel, du domaine d’application, etc. Il apparait, par conséquent, pertinent de combiner les approches existantes afin de tirer partie de leurs atouts respectifs. Pour ce faire, les approches hybrides constituent des alternatives intéressantes car elles s’avèrent faiblement supervisées et plus flexibles que d’autres approches statistiques. Enfin, ce tour d’horizon nous a permis de comparer 132 Copyright c 2013 - CASSIDIAN - All rights reserved1. Synthèse des contributions différents outils et logiciels pour la mise en œuvre de notre approche ainsi que différents jeux de données potentiellement adaptés à l’évaluation de nos travaux. Le dernier état de l’art autour de la capitalisation des connaissances a mis en avant une suite logique à nos travaux en extraction automatique d’information : la conception d’une approche globale permettant la transition du texte vers la connaissance proprement dite. Cette problématique a donné lieu à diverses recherches au sein de plusieurs communautés de l’IA, chacune d’elles manipulant sa propre terminologie adaptée à ses propres besoins. Ses divergences de vocabulaire n’empêchent pas d’observer la place importante réservée à la capitalisation des connaissances au sein des recherches actuelles, que ce soit en réconciliation de données, extraction d’information ou Web sémantique. La majorité des approches proposées en réconciliation de données trouve ses origines dans les bases de données. Il s’agit dans ce cadre d’assurer le maintien de cohérence des bases en détectant les entrées et champs dupliqués. Pour cela, beaucoup de travaux sont fondés sur des calculs de similarité : les plus simples opèrent une similarité entre chaines de caractère tandis que les plus avancés exploitent le contexte linguistique et extra-linguistique des données à comparer. Ces dernières se distinguent ensuite par le type et la méthode employée pour obtenir ces caractéristiques de contexte et sur leur mode de combinaison. Nous avons également exploré les techniques de capitalisation au sein du Web sémantique. A l’heure actuelle, cela est réalisé principalement par ce que l’on nomme la Wikification : il s’agit de désambuiguïser sémantiquement les mentions textuelles d’intérêt afin de les rattacher à une entité du monde référencée dans une base de connaissances externe (dans le LOD essentiellement). Enfin, la capitalisation des connaissances sur les événements extraits est l’objet d’un intérêt grandissant. Également nommée co-référence entre événements, cette problématique est adressée principalement par des méthodes statistiques supervisées ou non, d’une part, et des approches fondées sur les graphes et les calculs de similarité d’autre part. Suite à la réalisation de ces états de l’art, nous avons proposé trois contributions relatives aux trois domaines scientifiques explorés. Celles-ci s’articulent au sein de notre processus global de capitalisation des connaissances. Au regard des conclusions de l’état de l’art, l’objectif directeur de nos recherches est de concevoir un système global de reconnaissance et d’agrégation des événements le plus générique possible et intégrant des méthodes et outils de la littérature. 1.2 Un modèle de connaissances pour le ROSO Notre première contribution est l’élaboration d’un modèle de connaissances qui servira de guide à notre approche de capitalisation des connaissances. Nous avons, tout d’abord, défini une modélisation des événements fondée sur des modèles reconnus en ingénierie des connaissances et en extraction d’information. Un événement est représenté par quatre dimensions : une dimension conceptuelle (correspondant au type de l’événement), une dimension temporelle (la date/ période d’occurrence de l’événement), une dimension spatiale (le lieu d’occurrence de l’événement) et une dimension agentive (dédiée aux différents acteurs impliqués dans l’événement). Pour la définition de ses dimensions, nous avons privilégié la gé- néricité du modèle ainsi que sa reconnaissances par la communauté scientifique concernée (par exemple, le modèle TUS et la représentation spatiale en aires géographiques). Par ailleurs, afin de modéliser l’ensemble des informations d’intérêt pour les analystes du ROSO, une ontologie de domaine a été proposée. Celle-ci comprend en tant que classes de plus haut niveau les cinq entités principales de ce domaine : les organisations, les lieux, les personnes, les équipements et les événements. De plus, notre ontologie intègre de nombreux liens sémantiques vers d’autres modélisations existantes afin de maintenir une interopérabilité au sein du Web sémantique. Cette contribution présente quelques limites et nous envisageons 133 Copyright c 2013 - CASSIDIAN - All rights reservedConclusion et perspectives des perspectives d’amélioration telles que l’intégration d’une cinquième dimension contextuelle afin de représenter des éléments du contexte linguistique et extra-linguistique, mais également une définition des rôles au sein de la dimension agentive. 1.3 Une approche mixte pour l’extraction automatique des événements Notre seconde contribution est une approche mixte pour l’extraction automatique des événements fondée sur une méthode symbolique à base de grammaires contextuelles, d’une part, et sur une technique de fouille de motifs séquentiels fréquents, d’autre part. La méthode symbolique comporte un ensemble de règles d’extraction développées manuellement et exploite notamment la sortie d’une analyse syntaxique en dépendance combinée avec un ensemble de classes argumentales d’événement. La seconde technique permet d’obtenir de manière faiblement supervisée un ensemble de patrons d’extraction grâce à la fouille de motifs séquentiels fréquents dans un ensemble de textes. Nous avons également conçu et implémenté un système de reconnaissance d’entités nommées sur le modèle des approches symboliques classiques. Celui-ci permet d’annoter au préalable les différentes entités dites simples nécessaires à la reconnaissance des événements. Les deux méthodes pour l’extraction des événements ont montré leur efficacité lors de l’état de l’art réalisé et leurs performances ont été évaluées sur un corpus de test de notre domaine d’application (voir la section Évaluation du travail de recherche ci-dessous). La méthode à base de règles pourra être améliorée en tenant compte d’autres informations fournies par l’analyse syntaxique telles que la voix (passive ou active) du déclencheur, la polarité de la phrase (négative ou positive), la modalité mais aussi les phénomènes de valence multiple. L’approche à base de motifs séquentiels fréquents pourrait également tirer profit de cette analyse syntaxique en intégrant les relations de dépendance produites en tant que nouveaux items ou sous forme de contraintes. Enfin, concernant les deux approches, leur limite principale (qui est aussi celle d’autres approches de la littérature) est qu’elles réalisent l’extraction au niveau phrastique. Une granularité plus large tel que le paragraphe ou le discours pourrait permettre d’améliorer les performances de ces approches. 1.4 Un processus d’agrégation sémantique des événements Notre contribution suivante est un processus d’agrégation sémantique des événements fondé sur une échelle de similarité qualitative et sur un ensemble de mesures spécifiques à chaque type de dimension. Nous avons tout d’abord proposé des mécanismes de normalisation des entités, adaptés à leurs natures, afin d’harmoniser formellement les différentes informations extraites. Concernant ce premier aspect, nous envisageons des améliorations telles que la désambiguïsation des dates relatives, par exemple, ou encore l’intégration au sein de notre système d’un outil de désambiguïsation sémantique des participants. Nous avons ensuite proposé un une échelle de similarité qualitative orientée utilisateur et un ensemble de calculs de similarité intégrant à la fois un modèle théorique adapté à chaque dimension et une implémentation technique employant les technologies du Web sémantique (ontologies et bases de connaissances sémantiques). Nous souhaitons poursuivre ce travail en élargissant le panel de similarités employées : notamment, des mesures de proximité ontologique plus sophistiquées ainsi que des outils de distance temporelle et spatiale et, pour la similarité agentive, une distance dédiée aux ensembles d’entités. Les similarités entre événements pourraient également provenir d’une fonction d’équivalence apprise automatiquement à partir de données annotées manuellement. Enfin, un processus d’agrégation fondé sur les graphes a été proposé afin de regrouper les mentions d’événements similaires et de permettre à l’analyste 134 Copyright c 2013 - CASSIDIAN - All rights reserved1. Synthèse des contributions de découvrir de nouvelles connaissances. Ce type d’agrégation possède l’avantage principal d’être intrinsèquement adapté aux traitement des bases de connaissances et ainsi aisément généralisable à d’autres silos du Web de données. Cette agrégation pourrait également être réalisée par calcul d’une similarité globale qui combinerait les différentes similarités locales. Le point délicat pour cette méthode sera alors d’estimer le poids de chaque dimension dans cette combinaison. 1.5 Évaluation du travail de recherche Pour conclure ce bilan des contributions, nous avons proposé durant notre travail de recherche deux expérimentations destinées à évaluer deux de nos contributions. Tout d’abord, une première évaluation a porté sur notre approche mixte d’extraction automatique des événements : celle-ci a été testée et comparée à un corpus de référence (issu de la campagne d’évaluation MUC) annoté manuellement pour les besoins de l’expérimentation. Une analyse détaillée des résultats a montré de bonnes performances en comparaison avec l’état de l’art et ceci pour l’ensemble des configurations d’évaluation testées. Cette première évaluation a également pointé quelques limites de notre approche telles que l’impact de l’extraction d’entités nommées sur les performances des extracteurs d’événements. De plus, celle-ci pourrait être améliorée en exploitant davantage les informations fournies par l’analyse syntaxique en dépendance. La seconde expérimentation a constitué une première analyse qualitative dans le but d’illustrer les résultats de notre processus d’agrégation sémantique sur un jeu de données réelles. Nous avons présenté, dans un premier temps, l’implémentation d’un prototype fonctionnel couvrant la chaine complète d’agrégation des événements. Puis, la base de données Global Terrorism Database a été introduite ainsi qu’un sous-ensemble de celle-ci servant de corpus d’évaluation pour cette expérimentation. Les tests réalisés se sont avérés prometteurs à la fois pour ce qui est du calcul de similarité entre événements et du processus d’agrégation proposé. Le premier traitement a rapproché efficacement des mentions d’événements qui co-réfèrent et permettra ainsi de réduire la tâche de l’analyste du ROSO en lui proposant l’ensemble des liens de similarité en tant que critères supplémentaires de recherche. Puis, nous avons appliqué notre processus d’agrégation par regroupements successifs sur ce jeu de test et nous avons montré par un exemple l’utilité de cette agrégation du point de vue utilisateur. Cette seconde contribution pourra être améliorée en intégrant l’ensemble des fonctions de similarité proposées à notre prototype d’agrégation et en optimisant celui-ci pour permettre son passage à l’échelle d’un processus de veille réel. 135 Copyright c 2013 - CASSIDIAN - All rights reservedConclusion et perspectives 2 Perspectives de recherche Les travaux de recherche menés durant cette thèse ont permis de mettre en avant des perspectives d’amélioration de notre processus de capitalisation des connaissances. La première suite à donner à nos travaux sera de mettre en place une évaluation quantitative et sur un jeu de données significatif (la base GTD par exemple) de notre processus global de capitalisation de connaissances. Pour cela, nous envisageons d’optimiser l’implémentation de notre processus d’agrégation sémantique pour passer à l’échelle de notre corpus d’évaluation. L’extraction des événements pourra être améliorée par différentes méthodes exploitant la connaissance disponible dans le Web de données. L’ensemble des silos sémantiques liés entre eux par des équivalences et des relations ontologiques peut être exploité par divers moyens. Une autre piste d’amélioration est l’intégration d’un système d’estimation de la confiance ou qualité des extractions afin de guider soit les systèmes suivants soit l’utilisateur. De plus, il pourra être intéressant d’y ajouter d’autres méthodes performantes de l’EI comme par exemple une extraction par apprentissage statistique sous réserve de disposer d’un corpus annoté adéquat. Concernant notre approche à base de motifs séquentiels, nous pourrons diversifier le corpus d’apprentissage utilisé afin d’obtenir des patrons plus génériques et performants pour d’autres domaines ou genres de texte. Les récentes recherches visant à évaluer la qualité des extractions telles que [Habib and van Keulen, 2011], nous paraissent également à prendre en compte afin d’améliorer les performances de nos extracteurs mais aussi dans le but de réaliser une hybridation intelligente de ces différentes méthodes d’extraction. Par ailleurs, comme dit précédemment le travail présenté ici est centré sur la définition d’un système global de reconnaissance et d’agrégation d’événements le plus générique possible. Cela implique que les différentes mesures de similarité présentées sont facilement interchangeables avec d’autres mesures plus avancées sans remettre en cause notre approche globale. La similarité agentive pourra, par exemple, être améliorée en y intégrant des techniques de résolution de co-référence entre entités. Nous pourrons également prendre en compte certaines dépendances entre les dimensions d’événement : à titre d’exemple, la dimension sémantique peut influencer l’agrégation d’entités temporelles dans le cas d’événements duratifs comme des épidémies ou des guerres où deux mentions d’événement peuvent avoir deux dates différentes mais tout de même référer au même événement du monde réel. En effet, nous n’étudions pour le moment que les événements dits ponctuels mais il sera intéressant de poursuivre ce travail en étudiant les événements duratifs et plus particulièrement les liens temporels entre événements grâce aux relations d’Allen [Allen, 1981] et à l’opérateur convexify défini dans le modèle TUS. Une autre perspective pourra être d’étudier tous les types de dépendance entre dimensions, notamment en explorant certaines techniques de résolution collective d’entités. Concernant le processus d’agrégation proposé, nous envisageons d’étudier les travaux existants autour de la cotation de l’information et plus particulièrement de la fiabilité des sources et des informations. La qualité des connaissances capitalisées peut être grandement améliorée dès lors que le processus d’agrégation des informations tient compte de ces indices (voir par exemple les travaux de [Cholvy, 2007]). Pour finir, l’interaction avec l’utilisateur constitue également une piste de recherche intéressante. [Noël, 2008] met en avant que les technologies du Web sémantique ont souvent été critiquées pour le fait que les aspects utilisateur y ont souvent été négligés. Ceux-ci proposent donc l’application des techniques de recherche exploratoire au Web sémantique et, plus particulièrement, à l’accès aux bases 136 Copyright c 2013 - CASSIDIAN - All rights reservedde connaissances par les utilisateurs. De plus, la possibilité donnée à l’utilisateur de fusionner des fiches grâce aux suggestions d’agrégats soulèvera d’autres problématiques à explorer telles que la mise à jour et le maintien de cohérence de la base de connaissance en fonction des actions de l’analyste. 137 Copyright c 2013 - CASSIDIAN - All rights reservedConclusion et perspectives 138 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexes 139 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe A WOOKIE : taxonomie des concepts 141 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe A. WOOKIE : taxonomie des concepts 142 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe B WOOKIE : événements spécifiques au ROSO 143 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe B. WOOKIE : événements spécifiques au ROSO 144 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe C WOOKIE : relations entre concepts 145 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe C. WOOKIE : relations entre concepts 146 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe D WOOKIE : attributs des concepts 147 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe D. WOOKIE : attributs des concepts 148 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe E GATE : exemple de chaine de traitement 149 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe E. GATE : exemple de chaine de traitement 150 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe F Gazetteer pour la détection de personnes en français 151 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe F. Gazetteer pour la détection de personnes en français 152 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe G L’ontologie-type pizza.owl 153 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe G. L’ontologie-type pizza.owl 154 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe H Extrait de l’ontologie pizza.owl au format OWL < !−− / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / OWL C l a s s e s / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / −−> < !−− C l a s s : h t t p : / /www. co−ode . o r g / o n t o l o g i e s / p i z z a / p i z z a . owl# Ame rican −−> < o w l : C l a s s r d f : a b o u t = " # Ame rican " > < r d f s : l a b e l xml :l a n g= " p t " >Ame rica na < / r d f s : l a b e l > < r d f s : s u b C l a s s O f > < o w l : R e s t r i c t i o n > < o w l : o n P r o p e r t y r d f : r e s o u r c e = " # h a sT o p pi n g " / > < owl: s omeVal ue sF r om r d f : r e s o u r c e = " # TomatoTopping " / > < / o w l : R e s t r i c t i o n > < / r d f s : s u b C l a s s O f > < r d f s : s u b C l a s s O f > < o w l : R e s t r i c t i o n > < o w l : o n P r o p e r t y r d f : r e s o u r c e = " # h a sT o p pi n g " / > < owl: s omeVal ue sF r om r d f : r e s o u r c e = " # P e p e r o ni S a u s a g e T o p pi n g " / > < / o w l : R e s t r i c t i o n > < / r d f s : s u b C l a s s O f > < r d f s : s u b C l a s s O f > < o w l : R e s t r i c t i o n > < o w l : o n P r o p e r t y r d f : r e s o u r c e = " # h a sC o u nt r y O f O ri gi n " / > < o wl: h a s V al u e r d f : r e s o u r c e = " # Ame rica " / > < / o w l : R e s t r i c t i o n > < / r d f s : s u b C l a s s O f > < r d f s : s u b C l a s s O f > < o w l : R e s t r i c t i o n > < o w l : o n P r o p e r t y r d f : r e s o u r c e = " # h a sT o p pi n g " / > < owl: s omeVal ue sF r om r d f : r e s o u r c e = " # M o z z a r ell a T o p pi n g " / > < / o w l : R e s t r i c t i o n > 155 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe H. Extrait de l’ontologie pizza.owl au format OWL < / r d f s : s u b C l a s s O f > < r d f s : s u b C l a s s O f > < o w l : C l a s s r d f : a b o u t = " # NamedPizza " / > < / r d f s : s u b C l a s s O f > < r d f s : s u b C l a s s O f > < o w l : R e s t r i c t i o n > < o w l : o n P r o p e r t y r d f : r e s o u r c e = " # h a sT o p pi n g " / > < o wl: all V al u e s F r o m > < o w l : C l a s s > < o wl: u ni o n O f r d f : p a r s e T y p e = " C o l l e c t i o n " > < o w l : C l a s s r d f : a b o u t = " # M o z z a r ell a T o p pi n g " / > < o w l : C l a s s r d f : a b o u t = " # P e p e r o ni S a u s a g e T o p pi n g " / > < o w l : C l a s s r d f : a b o u t = " # TomatoTopping " / > < / o wl: u ni o n O f > < / o w l : C l a s s > < / o wl: all V al u e s F r o m > < / o w l : R e s t r i c t i o n > < / r d f s : s u b C l a s s O f > < / o w l : C l a s s > < !−− / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / OWL O bj e ct P r o p e r t i e s / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / −−> < !−− O bj e ct p r o p e r t y : h t t p : / /www. co−ode . o r g / o n t o l o g i e s / p i z z a / p i z z a . owl# h a sB a s e −−> < o w l : O b j e c t P r o p e r t y r d f : a b o u t = " # h a sB a s e " > < r d f : t y p e r d f : r e s o u r c e = "&owl ; F u n c t i o n a l P r o p e r t y " / > < r d f : t y p e r d f : r e s o u r c e = "&owl ; I n v e r s e F u n c t i o n a l P r o p e r t y " / > < o w l : i n v e r s e O f > < o w l : O b j e c t P r o p e r t y r d f : a b o u t = " # i sB a s e O f " / > < / o w l : i n v e r s e O f > < r d f s : d o m a i n > < o w l : C l a s s r d f : a b o u t = " # P i z z a " / > < / r d f s : d o m a i n > < r d f s : r a n g e > < o w l : C l a s s r d f : a b o u t = " # Pi z z aB a s e " / > < / r d f s : r a n g e > < / o w l : O b j e c t P r o p e r t y > < !−− / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / OWL I n d i v i d u a l s / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / −−> < !−− I n d i v i d u a l : h t t p : / /www. co−ode . o r g / o n t o l o g i e s / p i z z a / p i z z a . owl# Ame rica −−> < o wl: T hi n g r d f : a b o u t = " # Ame rica " > 156 Copyright c 2013 - CASSIDIAN - All rights reserved< r d f : t y p e r d f : r e s o u r c e = " # C o u nt r y " / > < / o wl: T hi n g > < !−− / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / OWL Axioms / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / −−> < o w l : C l a s s r d f : a b o u t = " # LaRei ne " > < o w l : d i s j o i n t W i t h > < o w l : C l a s s r d f : a b o u t = " #Mushroom " / > < / o w l : d i s j o i n t W i t h > < / o w l : C l a s s > < o w l : C l a s s r d f : a b o u t = " #Mushroom " > < o w l : d i s j o i n t W i t h > < o w l : C l a s s r d f : a b o u t = " # LaRei ne " / > < / o w l : d i s j o i n t W i t h > < / o w l : C l a s s > < o w l : A l l D i f f e r e n t > < o w l : d i s t i n c tM e m b e r s r d f : p a r s e T y p e = " C o l l e c t i o n " > < o wl: T hi n g r d f : a b o u t = " # Ame rica " / > < o wl: T hi n g r d f : a b o u t = " # I t a l y " / > < o wl: T hi n g r d f : a b o u t = " #Germany " / > < o wl: T hi n g r d f : a b o u t = " # F r a n c e " / > < o wl: T hi n g r d f : a b o u t = " # E n gla n d " / > < / o w l : d i s t i n c tM e m b e r s > < / o w l : A l l D i f f e r e n t > < / r d f:RDF > 157 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe H. Extrait de l’ontologie pizza.owl au format OWL 158 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe I Exemple de document WebLab contenant des événements < r e s o u r c e x s i : t y p e = " n s 3:D oc ume nt " u r i = " w e bl a b: / / S m a l l E n g l i s h T e s t / 1 " xml n s: n s 3 = " h t t p : / / we bla b . ow2 . o r g / c o r e / 1 . 2 / model # " x m l n s : x s i = " h t t p : / / www. w3 . o r g / 2 0 0 1 / XMLSchema−i n s t a n c e " > < a n n o t a t i o n u r i = " w e bl a b: / / S m a l l E n g l i s h T e s t /1#0−a2 " > < d a t a xml n s: n s 2 = " h t t p : / / we bla b . ow2 . o r g / 1 . 2 / model # " > < r d f:RDF xml n s: d c = " h t t p : / / p u r l . o r g / dc / el e m e n t s / 1 . 1 / " x m l n s : r d f = " h t t p : / / www. w3 . o r g / 1 9 9 9/ 0 2/ 2 2 − r d f−s y nt a x−n s # " > < r d f : D e s c r i p t i o n r d f : a b o u t = " w e bl a b: / / S m a l l E n g l i s h T e s t / 1 " > < d c : l a n g u a g e >en< / d c : l a n g u a g e > < / r d f : D e s c r i p t i o n > < / r d f:RDF > < / d a t a > < / a n n o t a t i o n > < m e di aU nit x s i : t y p e = " n s 3 : T e x t " u r i = " s o u r c e : / / x p _ s 7 8 " > < a n n o t a t i o n u r i = " s o u r c e : / / x p _ s 7 8 # a0 " > < d a t a > < r d f:RDF x m l n s : r d f s = " h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 1 / r d f−schema # " x m l n s : d c t = " h t t p : / / p u r l . o r g / dc / t e rm s / " x m l n s : r d f = " h t t p : / / www. w3 . o r g / 1 9 9 9/ 0 2/ 2 2 − r d f−s y nt a x−n s # " x ml n s: wl r = " h t t p : / / we bla b . ow2 . o r g / c o r e / 1 . 2 / o nt ol o g y / r e t r i e v a l # " xml n s:wl p = " h t t p : / / we bla b . ow2 . o r g / c o r e / 1 . 2 / o nt o l o g y / p r o c e s s i n g # " xml n s:w o o ki e = " h t t p : / / we bla b . ow2 . o r g / wookie # " > < r d f : D e s c r i p t i o n r d f : a b o u t = " s o u r c e : / / x p _ s 7 8 #4 " > < w l p : r e f e r s T o r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / S e a r c h O p e r a t i o n #40 d72785− 2171−4372−8e61 −5808 b41122c3 " / > < w l p : r e f e r s T o r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / S e a r c h O p e r a t i o n #832 b376 f− c7dd−4d23−a8ea −4441027 c4115 " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " s o u r c e : / / x p _ s 7 8 #5 " > < w l p : r e f e r s T o r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / C r a s hE v e nt #81 b9be1e−a f a 9− 4 a84 −9066−414 b8021468c " / > < w l p : r e f e r s T o 159 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe I. Exemple de document WebLab contenant des événements r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / C r a s hE v e nt #5 bbe4888 −5445− 4896−a d f 0 −0a 2 0 b 7 6ee d 2 7 " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " s o u r c e : / / x p _ s 7 8 # a0 " > < wl p:i s P r o d u c e dB y r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / w e b s e r v i c e s / g a t e s e r v i c e " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / C r a s hE v e nt #5 bbe4888 −5445−4896− a d f 0 −0a 2 0 b 7 6ee d 2 7 " > < w o o k i e : s o u r c e > s o u r c e : / / x p _ s 7 8 < / w o o k i e : s o u r c e > < r d f s : l a b e l > i n c i d e n t < / r d f s : l a b e l > < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie # C r a s hE v e nt " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / S e a r c h O p e r a t i o n #832 b376 f−c7dd− 4 d23−a8ea −4441027 c4115 " > < w o o k i e : i n v o l v e s r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / U nit # p o l i c e " / > < w o o k i e : s o u r c e > s o u r c e : / / x p _ s 7 8 < / w o o k i e : s o u r c e > < r d f s : l a b e l > i n v e s t i g a t i n g < / r d f s : l a b e l > < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie # S e a r c h O p e r a t i o n " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / S e a r c h O p e r a t i o n #40 d72785−2171− 4372−8e61 −5808 b41122c3 " > < w o o k i e : s o u r c e > s o u r c e : / / x p _ s 7 8 < / w o o k i e : s o u r c e > < r d f s : l a b e l > i n v e s t i g a t i n g < / r d f s : l a b e l > < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie # S e a r c h O p e r a t i o n " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / C r a s hE v e nt #81 b9be1e−a f a 9 −4a84− 9066−414 b8021468c " > < w o o k i e : i n v o l v e s r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / U nit # p o l i c e " / > < w o o k i e : s o u r c e > s o u r c e : / / x p _ s 7 8 < / w o o k i e : s o u r c e > < r d f s : l a b e l > i n c i d e n t < / r d f s : l a b e l > < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie # C r a s hE v e nt " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / P e r s o n # muhammad_khan_ sa soli " > < w l p : i s C a n d i d a t e > t r u e < / w l p : i s C a n d i d a t e > < r d f s : l a b e l >Muhammad Khan S a s o l i < / r d f s : l a b e l > < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie # P e r s o n " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / U nit # k h u z d a r _ p r e s s _ c l u b " > < w l p : i s C a n d i d a t e > t r u e < / w l p : i s C a n d i d a t e > < r d f s : l a b e l >Khuzda r P r e s s Club < / r d f s : l a b e l > < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie # U nit " / > < / r d f : D e s c r i p t i o n > 160 Copyright c 2013 - CASSIDIAN - All rights reserved< r d f : D e s c r i p t i o n r d f : a b o u t = " s o u r c e : / / x p _ s 7 8 #2 " > < w l p : r e f e r s T o r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / P e r s o n # muhammad_khan_ sa soli " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " s o u r c e : / / x p _ s 7 8 #3 " > < w l p : r e f e r s T o r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / U nit # p o l i c e " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / U nit # p o l i c e " > < w l p : i s C a n d i d a t e > t r u e < / w l p : i s C a n d i d a t e > < r d f s : l a b e l > P o l i c e < / r d f s : l a b e l > < r d f : t y p e r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie # U nit " / > < / r d f : D e s c r i p t i o n > < r d f : D e s c r i p t i o n r d f : a b o u t = " s o u r c e : / / x p _ s 7 8 #1 " > < w l p : r e f e r s T o r d f : r e s o u r c e = " h t t p : / / we bla b . ow2 . o r g / wookie / i n s t a n c e s / U nit # k h u z d a r _ p r e s s _ c l u b " / > < / r d f : D e s c r i p t i o n > < / r d f:RDF > < / d a t a > < / a n n o t a t i o n > < se gme nt x s i : t y p e = " n s 3: Li n e a r S e g m e nt " s t a r t = " 303 " end= " 321 " u r i = " s o u r c e : / / x p _ s 7 8 #1 " / > < se gme nt x s i : t y p e = " n s 3: Li n e a r S e g m e nt " s t a r t = " 386 " end= " 406 " u r i = " s o u r c e : / / x p _ s 7 8 #2 " / > < se gme nt x s i : t y p e = " n s 3: Li n e a r S e g m e nt " s t a r t = " 523 " end= " 529 " u r i = " s o u r c e : / / x p _ s 7 8 #3 " / > < se gme nt x s i : t y p e = " n s 3: Li n e a r S e g m e nt " s t a r t = " 533 " end= " 546 " u r i = " s o u r c e : / / x p _ s 7 8 #4 " / > < se gme nt x s i : t y p e = " n s 3: Li n e a r S e g m e nt " s t a r t = " 551 " end= " 559 " u r i = " s o u r c e : / / x p _ s 7 8 #5 " / > < c o n t e n t > Wednesday , December 1 5 , 2010 E−Mail t h i s a r t i c l e t o a f r i e n d P r i n t e r F r i e n d l y V e r si o n More S h a ri n g S e r v i c e s S h a r e | S h a r e on f a c e b o o k S h a r e on t w i t t e r S h a r e on l i n k e d i n S h a r e on st um bl e u p o n S h a r e on em ail S h a r e on p r i n t | J o u r n a l i s t gunned down i n Khuzda r KALAT: U n i d e n t i f i e d a rmed men gunned down Khuzda r P r e s s Club p r e s i d e n t i n Khuzda r on T ue s da y . A c c o r di n g t o t h e l o c a l p o l i c e , Muhammad Khan S a s o l i was on h i s way home when t h e u n i d e n t i f i e d men gunned him down i n La b o u r Colony . The a s s a i l a n t s f l e d f rom t h e s c e n e . P o l i c e i s i n v e s t i g a t i n g t h e i n c i d e n t . app < / c o n t e n t > < / m e di aU nit > < / r e s o u r c e > 161 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe I. Exemple de document WebLab contenant des événements 162 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe J Exemple de règle d’inférence au formalisme Jena @ p r e fi x r d f : < h t t p : / /www. w3 . o r g / 1 9 9 9/ 0 2/ 2 2 − r d f−s y nt a x−n s # >. @ p r e fi x owl : < h t t p : / /www. w3 . o r g / 2 0 0 2 / 0 7 / owl # >. @ p r e fi x r d f s : < h t t p : / /www. w3 . o r g / 2 0 0 0 / 0 1 / r d f−schema # >. @ p r e fi x x s d : < h t t p : / /www. w3 . o r g / 2 0 0 1 / XMLSchema# >. @ p r e fi x wookie : < h t t p : / / we bla b . ow2 . o r g / wookie # >. [ I n i t i a l i z a t i o n : −> p r i n t ( " / / / / / / / / / / / / / / E v e nt s s e m a n ti c s i m i l a r i t y r u l e s / / / / / / / / / / / / / / / / / / / / " ) ] / / / / / / / / / / / / / / / S em a nti c s i m i l a r i t y / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / [ SemSIM_1 : ( ? e1 wookie : s e m a nti c all y S IM ? e2 ) <− ( ? e1 r d f : t y p e ? c1 ) , ( ? e2 r d f : t y p e ? c2 ) , i s R e l e v a n t ( ? c1 ) , i s R e l e v a n t ( ? c2 ) , n oVal ue ( ? e1 wookie : s e m a nti c all y S IM ? e2 ) , n ot E q u al ( ? e1 , ? e2 ) , n ot E q u al ( ? c1 , ? c2 ) , h a s S u bCl a s s ( ? c1 , ? c2 ) ] 163 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe J. Exemple de règle d’inférence au formalisme Jena 164 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe K Extrait d’un document du corpus d’apprentissage { However howeve r RB }{ , , , }{ Canada Canada NP P l a c e }{ c o n t i n u e s c o n t i n u e VBZ }{ t o t o TO }{ make make VB }{ p r o g r e s s p r o g r e s s NN }{ on on IN }{ t h e t h e DT }{ s i x s i x CD }{ p r i o r i t i e s p r i o r i t y NNS }{ we we PP }{ ha ve ha ve VBP }{ i d e n t i f i e d i d e n t i f y VBN }{ t h a t t h a t WDT }{ w i l l w i l l MD }{ h el p h el p VB LookupEvent }{ b u i l d b u i l d VB }{ t h e t h e DT }{ f o u n d a t i o n f o u n d a t i o n NN }{ f o r f o r IN }{ a a DT }{ more more RBR }{ s t a b l e s t a b l e J J }{ A f g h a n i s t a n A f g h a n i s t a n NP P l a c e }{ . . SENT } { The t h e DT }{ f i f t h f i f t h J J }{ q u a r t e r l y q u a r t e r l y J J }{ r e p o r t r e p o r t NN }{ h i g h l i g h t s h i g h l i g h t VBZ }{ C a n a di a n C a n a di a n J J }{ a c t i v i t y a c t i v i t y NN }{ i n i n IN }{ s e v e r a l s e v e r a l J J }{ a r e a s a r e a NNS }{ : : : }{ − − : }{ Unde r u n d e r IN }{ a a DT }{ Ca na dia n−s u p p o r t e d Ca na dia n−s u p p o r t e d J J }{ p r o j e c t p r o j e c t NN }{ t o t o TO }{ c l e a r c l e a r J J }{ l a n dmi n e s l a n dmi n e NNS }{ and and CC }{ o t h e r o t h e r J J }{ e x p l o s i v e s e x p l o s i v e NNS }{ , , , }{ t r a i n i n g t r a i n i n g NN LookupEvent }{ be ga n b e gi n VBD }{ f o r f o r IN }{ 80 @card@ CD }{ l o c a l l y l o c a l l y RB }{ r e c r u i t e d r e c r u i t VBN }{ d emi n e r s d emi n e r s NNS }{ i n i n IN }{ Ka n da ha r Ka n da ha r NP P l a c e }{ , , , }{ and and CC }{ an an DT }{ a d d i t i o n a l a d d i t i o n a l J J }{ 2 7 0 , 0 0 0 @card@ CD }{ s q u a r e s q u a r e J J }{ m et r e s m et r e NNS }{ o f o f IN }{ l a n d l a n d NN }{ we re be VBD }{ c l e a r e d c l e a r VBN }{ . . SENT } { Canada Canada NP P l a c e }{ c o n t i n u e s c o n t i n u e VBZ }{ t o t o TO }{ p u r s u e p u r s u e VB }{ i t s i t s PP$ }{ e f f o r t s e f f o r t NNS }{ t o t o TO }{ p r o t e c t p r o t e c t VB LookupEvent }{ i t s i t s PP$ }{ s e c u r i t y s e c u r i t y NN }{ by by IN }{ h e l p i n g h el p VBG LookupEvent }{ t h e t h e DT }{ A fghan A fghan J J U nit }{ g o v e r nm e nt g o v e r nm e nt NN U nit }{ t o t o TO }{ p r e v e n t p r e v e n t VB }{ A f g h a n i s t a n A f g h a n i s t a n NP P l a c e }{ f rom f rom IN }{ a g a i n a g a i n RB }{ becoming become VBG }{ a a DT }{ b a s e b a s e NN }{ f o r f o r IN }{ t e r r o r i s m t e r r o r i s m NN }{ d i r e c t e d d i r e c t VBN }{ a g a i n s t a g a i n s t IN }{ Canada Canada NP P l a c e }{ o r o r CC }{ i t s i t s PP$ }{ a l l i e s a l l y NNS }{ . . SENT } 165 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe K. Extrait d’un document du corpus d’apprentissage 166 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe L Extrait d’un document du corpus de test TST4−MUC4−0001 C o n c e p ci o n < / Pl a c e > , 23 Aug 88< / Date> ( S a n t i a g o D ome stic S e r v i c e < / Uni t> ) −− [ R e p o rt ] [ Mi g uel Angel V a l d e b e n i t o < / Person> ] [ T e xt ] P o l i c e < / Uni t> s o u r c e s ha ve r e p o r t e d t h a t u n i d e n t i f i e d i n d i v i d u a l s p l a n t e d a bomb< / LookupEvent> i n f r o n t o f a < Pl a c e >Mormon Chu rch < / Pl a c e > i n T al c a h u a n o D i s t r i c t < / Pl a c e > . The bomb , which e x pl o d e d < / LookupEvent> and c a u s e d p r o p e r t y damage< / LookupEvent> w o rt h 5 0 , 0 0 0 p e s o s , was p l a c e d a t a c h a p e l o f t h e Chu rch o f J e s u s C h r i s t o f L a t t e r −Day S a i n t s < / Pl a c e > l o c a t e d a t No 3856 Gomez C a r r e n o S t r e e t < / Pl a c e > . The s h o c k wave d e s t r o y e d a w all , t h e r o o f , and t h e windows o f t h e c h u rc h , b ut di d n ot c a u s e any i n j u r i e s . C a r a b i n e r o s bomb s q u a d < / Uni t> p e r s o n n e l i m m e di at el y went < / LookupEvent> t o t h e l o c a t i o n and d i s c o v e r e d t h a t t h e bomb was made o f 50 g rams o f an−f o [ ammonium n i t r a t e −f u e l o i l b l a s t i n g a g e n t s ] and a sl ow f u s e . C a r a b i n e r o s s p e c i a l f o r c e s < / Uni t> s o o n r a i d e d < / LookupEvent> a l a r g e a r e a t o t r y t o a r r e s t < / LookupEvent> t h o s e r e s p o n s i b l e f o r t h e a t t a c k , b ut t h e y we re u n s u c c e s s f u l . The p o l i c e < / Uni t> ha ve a l r e a d y i n f o rm e d t h e a p p r o p r i a t e a u t h o r i t i e s , t h a t i s , t h e n a t i o n a l p r o s e c u t o r and t h e T al c a h u a n o c r i m i n a l c o u r t < / Uni t> , o f t h i s a t t a c k . 167 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe L. Extrait d’un document du corpus de test 168 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe M Source s12 : dépêche de presse à l’origine des événements Event1 et Event2 J a n u a r y 2 4 , 2010 Two U. S . S o l d i e r s Are Among 17 A fghan D e at h s By ROD NORDLAND and SANGAR RAHIMI KABUL, A f g h a n i s t a n − At l e a s t 17 p e o pl e di e d i n f o u r s e p a r a t e e p i s o d e s i n A f g h a n i s t a n on S at u r d a y , w hil e a p o l i c e c h i e f was ki d n a p p e d and a p r o v i n c i a l g o v e r n o r n a r r o wl y e s c a p e d a s s a s s i n a t i o n . T h r e e women and a young boy we re k i l l e d when a t a x i crammed wit h a t l e a s t e i g h t p a s s e n g e r s t r i e d t o r u n an i l l e g a l T a l i b a n c h e c k p o i n t i n P a k t i k a P r o vi n c e , i n t h e e a s t , and t h e m i l i t a n t s r i d d l e d t h e c a r wit h b u l l e t s . F o u r A fghan s o l d i e r s g u a r di n g t h e g o v e r n o r o f Wardak P r o vi n c e , j u s t w e st o f Kabul , we re k i l l e d when t h e T a l i b a n s e t o f f a hi d d e n bomb a s he t r a v e l e d t o a s c h o o l b u i l d i n g i n s p e c t i o n ; t h e g o v e r n o r was unha rmed . Two Ame rican s o l d i e r s we re k i l l e d by an i m p r o vi s e d e x p l o s i v e d e v i c e i n s o u t h e r n A f g h a ni st a n , a c c o r d i n g t o a p r e s s r e l e a s e f rom t h e i n t e r n a t i o n a l m i l i t a r y command h e r e . And s e v e n A f g ha n s we re k i l l e d i n t h e r em ot e v i l l a g e o f Qulum B al a q i n F a r y a b P r o vi n c e , i n n o r t h e r n A f g h a ni st a n , when t h e y t r i e d t o e x c a v a t e an ol d bomb d r o p p e d by an a i r c r a f t many y e a r s ago , a c c o r d i n g t o a s t a t e m e n t f rom t h e I n t e r i o r M i n i s t r y . One p e r s o n was wounded . I n a d d i t i o n , t h e p o l i c e c h i e f o f S h e i g a l d i s t r i c t i n Kuna r P r o vi n c e , J a m a t u l l a h Khan , and two o f h i s o f f i c e r s we re ki d n a p p e d w hil e p a t r o l l i n g j u s t a f t e r mi d ni g ht on S a t u r d a y c l o s e t o t h e b o r d e r wit h P a k i s t a n . Gen . K h a l i l u l l a h Zia yee , t h e p r o v i n c i a l p o l i c e c h i e f , s a i d t h e y we re a b d u ct e d " by t h e e n emi e s o f p e a c e and s t a b i l i t y i n t h e c o u nt r y , " t h e g o v e r nm e nt ’ s c at c h−a l l t e rm f o r i n s u r g e n t s . "We don ’ t ha ve any i n f o r m a t i o n a b o ut him y et , " G e n e r al Zi a y e e s ai d , s p e a ki n g o f t h e p o l i c e c h i e f . He a d de d t h a t a s e a r c h was u n d e r way . The T a l i b a n and common c r i m i n a l s o f t e n ki d n a p o f f i c i a l s f o r ransom . 169 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe M. Source s12 : dépêche de presse à l’origine des événements Event1 et Event2 The t a x i c a b s h o o t i n g o c c u r r e d a s t h e d r i v e r was t r y i n g t o t a k e h i s p a s s e n g e r s t o g e t m e di c al c a r e a t a n e a r b y m i l i t a r y b a s e r u n by i n t e r n a t i o n a l f o r c e s . I n a d d i t i o n t o t h e t h r e e women and a boy o f 5 o r 6 who we re k i l l e d , t h r e e o t h e r p a s s e n g e r s we re wounded , a c c o r d i n g t o Mukhles Afghan , a spokesman f o r t h e p r o v i n c i a l g o v e r n o r i n P a k t i k a . The a t t e m p t e d a s s a s s i n a t i o n o f t h e g o v e r n o r o f Wardak , Mohammad Halim F e di y e e , o c c u r r e d d u r i n g a t r i p t h a t had bee n announced , l e a v i n g h i s convoy v u l n e r a b l e . "We we re awa re o f t h e pl a n n e d a t t a c k and we had a l r e a d y d e f u s e d two bombs p l a n t e d on o u r way , " s a i d S h a h e d ull a h Shahed , a spokesman f o r t h e g o v e r n o r who was t r a v e l i n g wit h him . He s a i d a T a l i b a n l o c a l commander named Ahmadullah and a n o t h e r f i g h t e r had p l a n t e d a new bomb j u s t b e f o r e t h e convoy c r o s s e d a c u l v e r t , d e t o n a t i n g i t u n d e r t h e f i r s t a rm o re d v e h i c l e i n t h e convoy . The b l a s t k i l l e d f o u r s o l d i e r s i n t h e v e h i c l e . Mr . Shahed s a i d o t h e r s o l d i e r s managed t o c a p t u r e t h e two T a l i b a n members a s t h e y t r i e d t o f l e e . " T hi s t r i p was an a n n o u nce d t r i p , and e v e r y b o d y was w a i t i n g f o r t h e g o v e r n o r t o h el p them s o l v e t h e i r p r o blem s , " Mr . Shahed s a i d . " H u n d re d s o f t r i b a l e l d e r s and l o c a l p e o pl e we re w a i t i n g t o s e e t h e g o v e r n o r . " An A fghan em pl o yee o f The New York Times i n K h o st P r o vi n c e c o n t r i b u t e d r e p o r t i n g . 170 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe N Source s3 : dépêche de presse à l’origine de l’événement Event3 F o u r ki d n a p p e d i n e a s t A f g h a n i s t a n Sun Sep 2 6 , 2010 3: 7PM M i l i t a n t s ha ve ki d n a p p e d a B r i t i s h woman al o n g wit h t h r e e l o c a l s i n e a s t e r n A f g h a n i s t a n a s s e c u r i t y c o n t i n u e s t o d e t e r i o r a t e i n t h e war−r a v a g e d c o u n t r y . Those a b d u ct e d i n t h e p r o v i n c e o f Kunar a r e r e p o r t e d l y em pl o y e e s o f an Ame rican company . L o c al o f f i c i a l s ha ve blamed t h e ki d n a p pi n g on t h e T a l i b a n b ut t h e m i l i t a n t s ha ve n ot y e t cl aim e d r e s p o n s i b i l i t y . Ki d n a p pi n g s ha ve r e c e n t l y bee n on t h e r i s e i n A f g h a n i s t a n a s t h e s e c u r i t y s i t u a t i o n d e t e r i o r a t e s t o i t s w o r st l e v e l s s i n c e t h e 2001 US−l e d i n v a s i o n t h e r e . The T a l i b a n ha ve a b d u ct e d o v e r a d oze n p e o pl e a c r o s s A f g h a n i s t a n d u r i n g t h e r e c e n t p a r l i a m e n t a r y e l e c t i o n s . T hi s i s w hil e some 1 5 0 , 0 0 0 US−l e d f o r e i g n t r o o p s a r e r e s p o n s i b l e f o r s e c u r i t y i n t h e war−t o r n n a t i o n . JR /AKM/MMN 171 Copyright c 2013 - CASSIDIAN - All rights reservedAnnexe N. Source s3 : dépêche de presse à l’origine de l’événement Event3 172 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Agrawal et al., 1993] Agrawal, R., Imielinski, T., and Swami, A. (1993). Mining association rules ´ between sets of items in large databases. In Proceedings of the 1993 ACM SIGMOD international conference on Management of data, SIGMOD ’93, pages 207–216, New York. ACM. 97 [Ahn, 2006] Ahn, D. (2006). The stages of event extraction. Proceedings of the Workshop on Annotating and Reasoning about Time and Events - ARTE ’06, pages 1–8. 27, 48 [Alatrish, 2012] Alatrish, E. S. (2012). Comparison of ontology editors. eRAF Journal on Computing, 4 :23–38. 25 [Allen, 1981] Allen, J. F. (1981). An interval-based representation of temporal knowledge. In Proceedings of the 7th international joint conference on Artificial intelligence - Volume 1, pages 221–226, San Francisco, CA, USA. Morgan Kaufmann Publishers Inc. 136 [Allen, 1983] Allen, J. F. (1983). Maintaining knowledge about temporal intervals. Commun. ACM, 26(11) :832–843. 33 [Allen, 1991] Allen, J. F. (1991). Time and time again : The many ways to represent time. Journal of Intelligent Systems, 6(4) :341–355. 33 [Allen and Ferguson, 1994] Allen, J. F. and Ferguson, G. (1994). Actions and events in interval temporal logic. Journal of Logic and Computation, 4 :531–579. 29 [Aone et al., 1998] Aone, C., Halverson, L., Hampton, T., and Ramos-Santacruz, M. (1998). SRA : Description of the IE2 system used for MUC-7. In Proceedings Seventh Message Understanding Conference (MUC-7), Fairfax, VA. 48 [Aone and Ramos-Santacruz, 2000] Aone, C. and Ramos-Santacruz, M. (2000). REES : A large-scale relation and event extraction system. In ANLP, pages 76–83. 48 [Appelt, 1999] Appelt, D. E. (1999). Introduction to information extraction. AI Commun., 12(3) :161– 172. 56 [Appelt et al., 1995] Appelt, D. E., Hobbs, J. R., Bear, J., Israel, D., Kameyama, M., Martin, D., Myers, K., and Tyson, M. (1995). SRI International FASTUS system : MUC-6 test results and analysis. In Proceedings of the 6th conference on Message understanding, MUC6 ’95, pages 237–248, Stroudsburg, PA, USA. Association for Computational Linguistics. 48 [Appelt and Onyshkevych, 1998] Appelt, D. E. and Onyshkevych, B. (1998). The common pattern specification language. In Proceedings of a workshop on held at Baltimore, Maryland : October 13-15, 1998, TIPSTER ’98, pages 23–30, Stroudsburg, PA, USA. Association for Computational Linguistics. 44 173 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Augenstein et al., 2012] Augenstein, I., Padó, S., and Rudolph, S. (2012). Lodifier : generating linked data from unstructured text. In Proceedings of the 9th international conference on The Semantic Web : research and applications, ESWC’12, pages 210–224, Berlin, Heidelberg. Springer-Verlag. 65 [Bachmair and Ganzinger, 2001] Bachmair, L. and Ganzinger, H. (2001). Resolution theorem proving. In Handbook of Automated Reasoning, pages 19–99. Elsevier and MIT Press. 22 [Bagga and Baldwin, 1999] Bagga, A. and Baldwin, B. (1999). Cross-document event coreference : Annotations, experiments, and observations. In In Proc. ACL-99 Workshop on Coreference and Its Applications, pages 1–8. 64, 66 [Balmisse, 2002] Balmisse, G. (2002). Gestion des connaissances. Outils et applications du knowledge management. Vuibert. 18 [Baumgartner and Retschitzegger, 2006] Baumgartner, N. and Retschitzegger, W. (2006). A survey of upper ontologies for situation awareness. Proc. of the 4th IASTED International Conference on Knowledge Sharing and Collaborative Engineering, St. Thomas, US VI, pages 1–9+. 36 [Béchet et al., 2012] Béchet, N., Cellier, P., Charnois, T., and Crémilleux, B. (2012). Discovering linguistic patterns using sequence mining. In CICLing (1), pages 154–165. 97, 98 [Benjelloun et al., 2006] Benjelloun, O., Garcia-Molina, H., Kawai, H., Larson, T. E., Menestrina, D., Su, Q., Thavisomboon, S., and Widom, J. (2006). Generic entity resolution in the serf project. IEEE Data Eng. Bull., 29(2) :13–20. 63 [Berners-Lee et al., 2001] Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The Semantic Web. Scientific American, 284(5) :34–43. 19 [Besançon et al., 2010] Besançon, R., de Chalendar, G., Ferret, O., Gara, F., Mesnard, O., Laïb, M., and Semmar, N. (2010). LIMA : A multilingual framework for linguistic analysis and linguistic resources development and evaluation. In Chair), N. C. C., Choukri, K., Maegaard, B., Mariani, J., Odijk, J., Piperidis, S., Rosner, M., and Tapias, D., editors, Proceedings of the Seventh International Conference on Language Resources and Evaluation (LREC’10), Valletta, Malta. European Language Resources Association (ELRA). 49 [Besançon et al., 2011] Besançon, R., Ferret, O., and Jean-Louis, L. (2011). Construire et évaluer une application de veille pour l’information sur les événements sismiques. In CORIA, pages 287–294. 53 [Best and Cumming, 2007] Best, R. and Cumming, A. (2007). Open source intelligence (osint) : Issues for congress. Rl 34270, Congressional Research Service. 3 [Bhattacharya and Getoor, 2007] Bhattacharya, I. and Getoor, L. (2007). Collective entity resolution in relational data. ACM Transactions on Knowledge Discovery from Data, 1(1) :5–es. 63 [Bilenko et al., 2003] Bilenko, M., Mooney, R. J., Cohen, W. W., Ravikumar, P., and Fienberg, S. E. (2003). Adaptive name matching in information integration. IEEE Intelligent Systems, 18(5) :16–23. 65, 66 [Bloch, 2005] Bloch, I. (2005). Fusion d’informations numériques : panorama méthodologique. In Journées Nationales de la Recherche en Robotique 2005, pages 79–88, Guidel, France. 62 [Bond et al., 2003] Bond, D., Bond, J., Oh, C., Jenkins, J. C., and Taylor, C. L. (2003). Integrated Data for Events Analysis (IDEA) : An Event Typology for Automated Events Data Development. Journal of Peace Research, 40(6) :733–745. 36 [Bontcheva et al., 2002] Bontcheva, K., Dimitrov, M., Maynard, D., Tablan, V., and Cunningham, H. (2002). Shallow Methods for Named Entity Coreference Resolution. In TALN 2002. 46 174 Copyright c 2013 - CASSIDIAN - All rights reserved[Borsje et al., 2010] Borsje, J., Hogenboom, F., and Frasincar, F. (2010). Semi-automatic financial events discovery based on lexico-semantic patterns. Int. J. Web Eng. Technol., 6(2) :115–140. 53 [Boury-Brisset, 2003] Boury-Brisset, A.-C. (2003). Ontological approach to military knowledge modeling and management. In NATO RTO Information Systems Technology Symposium (RTO MP IST 040), Prague. 36 [Bowman et al., 2001] Bowman, M., Lopez, A. M., and Tecuci, G. (2001). Ontology development for military applications. In Proceedings of the Thirty-ninth Annual ACM Southeast Conference. ACM Press. 36 [Brill, 1992] Brill, E. (1992). A simple rule-based part of speech tagger. In Proceedings of the third conference on Applied natural language processing, ANLC ’92, pages 152–155, Stroudsburg, PA, USA. Association for Computational Linguistics. 86 [Bundschus et al., 2008] Bundschus, M., Dejori, M., Stetter, M., Tresp, V., and Kriegel, H.-P. (2008). Extraction of semantic biomedical relations from text using conditional random fields. BMC Bioinformatics, 9(1) :1–14. 53 [Buscaldi, 2010] Buscaldi, D. (2010). Toponym Disambiguation in Information Retrieval. PhD thesis, Universidad Politecnica de Valencia. 103 [Califf and Mooney, 2003] Califf, M. E. and Mooney, R. J. (2003). Bottom-Up Relational Learning of Pattern Matching Rules for Information Extraction. J. Mach. Learn. Res., 4 :177–210. 43, 54 [Capet et al., 2011] Capet, P., Delavallade, T., Généreux, M., Poibeau, T., Sándor, Á., and Voyatzi, S. (2011). Un système de détection de crise basé sur l’extraction automatique d’événements. In et P. Hoogstoel, M. C., editor, Sémantique et multimodalité en analyse de l’information, pages 293– 313. Lavoisier. 42 [Capet et al., 2008] Capet, P., Delavallade, T., Nakamura, T., Sandor, A., Tarsitano, C., and Voyatzi, S. (2008). A risk assessment system with automatic extraction of event types. In Shi, Z., MercierLaurent, E., and Leake, D., editors, Intelligent Information Processing IV, volume 288 of IFIP – The International Federation for Information Processing, pages 220–229. Springer US. 53 [Caron et al., 2012] Caron, C., Guillaumont, J., Saval, A., and Serrano, L. (2012). Weblab : une plateforme collaborative dédiée à la capitalisation de connaissances. In Extraction et gestion des connaissances (EGC’2012), Bordeaux, France. 77 [Casati and Varzi, 1997] Casati, R. and Varzi, A. (1997). Fifty years of events : an annotated bibliography 1947 to 1997. ❤tt♣✿✴✴✇✇✇✳♣❞❝♥❡t✳♦r❣✴♣❛❣❡s✴Pr♦❞✉❝ts✴❡❧❡❝tr♦♥✐❝✴❡✈❡♥ts❜✐❜✳❤t♠. 26 [Cellier and Charnois, 2010] Cellier, P. and Charnois, T. (2010). Fouille de données séquentielle d’itemsets pour l’apprentissage de patrons linguistiques. In Traitement Automatique des Langues Naturelles (short paper). 58 [Cellier et al., 2010] Cellier, P., Charnois, T., and Plantevit, M. (2010). Sequential patterns to discover and characterise biological relations. In Gelbukh, A., editor, Computational Linguistics and Intelligent Text Processing, volume 6008 of Lecture Notes in Computer Science, pages 537–548. Springer Berlin Heidelberg. 47 [Ceri et al., 1989] Ceri, S., Gottlob, G., and Tanca, L. (1989). What you always wanted to know about datalog (and never dared to ask). IEEE Transactions on Knowledge and Data Engineering, 1(1) :146– 166. 44 [Charlet et al., 2004] Charlet, J., Bachimont, B., and Troncy, R. (2004). Ontologies pour le Web sémantique. In Revue I3, numéro Hors Série «Web sémantique». Cépaduès. 21, 25 175 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Charlot and Lancini, 2002] Charlot, J.-M. and Lancini, A. (2002). De la connaissance aux systèmes d’information supports. In Rowe, F., editor, Faire de la recherche en systèmes d’information, pages 139–145. Vuibert FNEGE. 18 [Charnois et al., 2009] Charnois, T., Plantevit, M., Rigotti, C., and Cremilleux, B. (2009). Fouille de données séquentielles pour l’extraction d’information dans les textes. Revue Traitement Automatique des Langues (TAL), 50(3) :59–87. 45 [Charton et al., 2011] Charton, E., Gagnon, M., and Ozell, B. (2011). Génération automatique de motifs de détection d’entités nommées en utilisant des contenus encyclopédiques. In 18e Conférence sur le Traitement Automatique des Langues Naturelles (TALN 2011), Montpellier. Association pour le Traitement Automatique des Langues (ATALA). 45 [Chasin, 2010] Chasin, R. (2010). Event and temporal information extraction towards timelines of wikipedia articles. In UCCS REU 2010, pages 1–9. Massachusetts Institute of Technology. 54 [Chau and Xu, 2012] Chau, M. and Xu, J. (2012). Business intelligence in blogs : understanding consumer interactions and communities. MIS Q., 36(4) :1189–1216. 53 [Chau et al., 2002] Chau, M., Xu, J. J., and Chen, H. (2002). Extracting meaningful entities from police narrative reports. In Proceedings of the 2002 annual national conference on Digital government research, dg.o ’02, pages 1–5. Digital Government Society of North America. 54 [Chaudet, 2004] Chaudet, H. (2004). Steel : A spatio-temporal extended event language for tracking epidemic spread from outbreak reports. In In U. Hahn (Ed.), Proceedings of KR-MED 2004, First International Workshop on Formal Biomedical Knowledge Representation. 53 [Chen and Ji, 2009] Chen, Z. and Ji, H. (2009). Graph-based event coreference resolution. In Proceedings of the 2009 Workshop on Graph-based Methods for Natural Language Processing, TextGraphs- 4, pages 54–57, Stroudsburg, PA, USA. Association for Computational Linguistics. 66, 67 [Chieu, 2003] Chieu, H. L. (2003). Closing the gap : Learning-based information extraction rivaling knowledge-engineering methods. In In Proceedings of the 41st Annual Meeting of the Association for Computational Linguistics, pages 216–223. 48 [Chisholm, 1970] Chisholm, R. (1970). Events and propositions. Noûs, 4(1) :15–24. 26 [Chiticariu et al., 2010] Chiticariu, L., Krishnamurthy, R., Li, Y., Reiss, F., and Vaithyanathan, S. (2010). Domain adaptation of rule-based annotators for named-entity recognition tasks. In In EMNLP (To appear. 58 [Cholvy, 2007] Cholvy, L. (2007). Modelling information evaluation in fusion. In FUSION, pages 1–6. 136 [Ciravegna, 2001] Ciravegna, F. (2001). Adaptive information extraction from text by rule induction and generalisation. In Proceedings of the 17th international joint conference on Artificial intelligence - Volume 2, IJCAI’01, pages 1251–1256, San Francisco, CA, USA. Morgan Kaufmann Publishers Inc. 45, 54 [Crié, 2003] Crié, D. (2003). De l’extraction des connaissances au Knowledge Management. Revue française de gestion, 29(146) :59–79. 18 [Cucerzan, 2007] Cucerzan, S. (2007). Large-scale named entity disambiguation based on Wikipedia data. In Proceedings of the 2007 Joint Conference on Empirical Methods in Natural Language Processing and Computational Natural Language Learning (EMNLP-CoNLL), pages 708–716, Prague, Czech Republic. Association for Computational Linguistics. 105 176 Copyright c 2013 - CASSIDIAN - All rights reserved[Culotta et al., 2006] Culotta, A., Kristjansson, T., McCallum, A., and Viola, P. (2006). Corrective feedback and persistent learning for information extraction. Artificial Intelligence, 170(14–15) :1101 – 1122. 58 [Cunningham et al., 2002] Cunningham, H., Maynard, D., Bontcheva, K., and Tablan, V. (2002). GATE : A framework and graphical development environment for robust nlp tools and applications. In Proceedings of the 40th Annual Meeting of the Association for Computational Linguistics, Philadelphia, PA, USA. 51, 84 [Cunningham et al., 2000] Cunningham, H., Maynard, D., and Tablan, V. (2000). JAPE : a Java Annotation Patterns Engine (Second Edition). Technical Report Technical Report CS–00–10, of Sheffield, Department of Computer Science. 44 [Daille et al., 2000] Daille, B., Fourour, N., and Morin, E. (2000). Catégorisation des noms propres : une étude en corpus. In Cahiers de Grammaire - Sémantique et Corpus, volume 25, pages 115–129. Université de Toulouse-le-Mirail. 43 [Daumé et al., 2010] Daumé, III, H., Kumar, A., and Saha, A. (2010). Frustratingly easy semisupervised domain adaptation. In Proceedings of the 2010 Workshop on Domain Adaptation for Natural Language Processing, DANLP 2010, pages 53–59, Stroudsburg, PA, USA. Association for Computational Linguistics. 58 [Davidson, 1967] Davidson, D. (1967). The logical form of action sentences. In Rescher, N., editor, The Logic of Decision and Action. University of Pittsburgh Press, Pittsburgh. 26 [Davidson, 1969] Davidson, D. (1969). The individuation of events. In Rescher, N., editor, Essays in honor of Carl G. Hempel, pages 216–234. D. Reidel, Dordrecht. reprinted in Davidson, Essays on Actions and Events. 27 [De Marneffe and Manning, 2008] De Marneffe, M.-C. and Manning, C. D. (2008). Stanford typed dependencies manual. Technical report, Stanford University. 95 [Desclés, 1990] Desclés, J.-P. (1990). "State, event, process, and topology". General Linguistics, 29(3) :159–200. 26 [Desodt-Lebrun, 1996] Desodt-Lebrun, A.-M. (1996). Fusion de données. In Techniques de l’ingénieur Automatique avancée, number 12 in 96, pages 1–9. Editions Techniques de l’Ingénieur. 62 [Dey et al., 1998] Dey, D., Sarkar, S., and De, P. (1998). A probabilistic decision model for entity matching in heterogeneous databases. Management Science, 44(10) :1379–1395. 63 [Dong and Pei, 2007] Dong, G. and Pei, J. (2007). Sequence Data Mining, volume 33 of Advances in Database Systems. Kluwer. 99 [Dong et al., 2005] Dong, X., Halevy, A., and Madhavan, J. (2005). Reference reconciliation in complex information spaces. Proceedings of the 2005 ACM SIGMOD international conference on Management of data - SIGMOD ’05, page 85. 63 [Dredze et al., 2010] Dredze, M., McNamee, P., Rao, D., Gerber, A., and Finin, T. (2010). Entity disambiguation for knowledge base population. In Proceedings of the 23rd International Conference on Computational Linguistics, COLING ’10, pages 277–285, Stroudsburg, PA, USA. Association for Computational Linguistics. 64, 65 [Drozdzynski et al., 2004] Drozdzynski, W., Krieger, H.-U., Piskorski, J., Schäfer, U., and Xu, F. (2004). Shallow processing with unification and typed feature structures — foundations and applications. Künstliche Intelligenz, 1 :17–23. 49 177 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Elmagarmid et al., 2007] Elmagarmid, A. K., Ipeirotis, P. G., and Verykios, V. S. (2007). Duplicate record detection : A survey. IEEE Trans. on Knowl. and Data Eng., 19(1) :1–16. 63, 65, 66 [Enjalbert, 2008] Enjalbert, P. (2008). « Préface ». In Plate-formes pour le traitement automatique des langues, volume 49 of Revue interntaionale Traitement Automatique des Langues, chapter 2, pages 7–10. ATALA. 50 [Etzioni et al., 2005] Etzioni, O., Cafarella, M., Downey, D., Popescu, A.-M., Shaked, T., Soderland, S., Weld, D. S., and Yates, A. (2005). Unsupervised named-entity extraction from the web : An experimental study. Artif. Intell., 165(1) :91–134. 43 [Fellegi and Sunter, 1969] Fellegi, I. P. and Sunter, A. B. (1969). A theory for record linkage. Journal of the American Statistical Association, 64 :1183–1210. 63 [Fensel et al., 2001] Fensel, D., van Harmelen, F., Horrocks, I., McGuinness, D. L., and Patel-Schneider, P. F. (2001). OIL : An ontology infrastructure for the semantic web. IEEE Intelligent Systems, 16(2) :38–45. 22 [Ferré, 2007] Ferré, S. (2007). CAMELIS : Organizing and Browsing a Personal Photo Collection with a Logical Information System. In Diatta, J., Eklund, P., and Liquière, M., editors, Int. Conf. Concept Lattices and Their Applications, volume 331, pages 112–123, Montpellier, France. 98, 99 [Fialho et al., 2010] Fialho, A., Troncy, R., Hardman, L., Saathoff, C., and Scherp, A. (2010). What’s on this evening ? Designing user support for event-based annotation and exploration of media. In EVENTS 2010, 1st International Workshop on EVENTS - Recognising and tracking events on the Web and in real life, May 4, 2010, Athens, Greece, Athens, GRÈCE. 29 [Finin et al., 2009] Finin, T., Syed, Z., Mayfield, J., McNamee, P., and Piatko, C. (2009). Using Wikitology for Cross-Document Entity Coreference Resolution. In Proceedings of the AAAI Spring Symposium on Learning by Reading and Learning to Read. AAAI Press. 46, 109 [Fisher et al., 2005] Fisher, M., Gabbay, D., and Vila, L. (2005). Handbook of Temporal Reasoning in Artificial Intelligence. Foundations of Artificial Intelligence. Elsevier Science. 76 [Fleischman and Hovy, 2002] Fleischman, M. and Hovy, E. (2002). Fine grained classification of named entities. Proceedings of the 19th international conference on Computational linguistics -, 1 :1–7. 58 [Fourour, 2002] Fourour, N. (2002). Nemesis, un système de reconnaissance incrémentielle des entités nommées pour le français. Actes de la 9ème Conférence Nationale sur le Traitement Automatique des Langues Naturelles (TALN 2001), 1 :265–274. 45 [François et al., 2007] François, J., Le Pesant, D., and Leeman, D. (2007). Présentation de la classification des verbes français de jean dubois et françoise dubois-charlier. Langue Française, 153(153) :3– 32. 96 [Friburger, 2006] Friburger, N. (2006). « Linguistique et reconnaissance automatique des noms propres ». Meta : journal des traducteurs / Meta : Translators’ Journal, 51(4) :637–650. 44 [Fundel et al., 2007] Fundel, K., Küffner, R., Zimmer, R., and Miyano, S. (2007). Relex–relation extraction using dependency parse trees. Bioinformatics, 23. 46 [Garbin and Mani, 2005] Garbin, E. and Mani, I. (2005). Disambiguating toponyms in news. In Proceedings of the conference on Human Language Technology and Empirical Methods in Natural Language Processing. 103 [Genesereth, 1991] Genesereth, M. R. (1991). Knowledge interchange format. In KR, pages 599–600. 22 178 Copyright c 2013 - CASSIDIAN - All rights reserved[Giroux et al., 2008] Giroux, P., Brunessaux, S., Brunessaux, S., Doucy, J., Dupont, G., Grilheres, B., Mombrun, Y., and Saval, A. (2008). Weblab : An integration infrastructure to ease the development of multimedia processing applications. ICSSEA. 6 [Goujon, 2002] Goujon, B. (2002). Annotation d’événements dans les textes pour la veille stratégique. Event (London). 53 [Grishman et al., 2002a] Grishman, R., Huttunen, S., and Yangarber, R. (2002a). Information extraction for enhanced access to disease outbreak reports. Journal of biomedical informatics, 35(4) :236–46. 53 [Grishman et al., 2002b] Grishman, R., Huttunen, S., and Yangarber, R. (2002b). Real-time event extraction for infectious disease outbreaks. Proceedings of the second international conference on Human Language Technology Research -, pages 366–369. 48 [Grishman and Sundheim, 1996] Grishman, R. and Sundheim, B. (1996). Message understanding conference-6 : a brief history. In Proceedings of the 16th conference on Computational linguistics - Volume 1, pages 466–471, Morristown, NJ, USA. Association for Computational Linguistics. 41 [Gruber, 1993] Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowl. Acquis., 5(2) :199–220. 21 [Guarino, 1998] Guarino, N. (1998). Formal ontology and information systems. In Proceedings of Formal Ontology in Information System, pages 3–15. IOS Press. 22 [Haase et al., 2008] Haase, P., Lewen, H., Studer, R., Tran, D. T., Erdmann, M., d’Aquin, M., and Motta, E. (2008). The NeOn Ontology Engineering Toolkit. In WWW 2008 Developers Track. 25 [Habib and van Keulen, 2011] Habib, M. B. and van Keulen, M. (2011). Improving named entity disambiguation by iteratively enhancing certainty of extraction. Technical Report TR-CTIT-11-29, Centre for Telematics and Information Technology University of Twente, Enschede. 136 [Hall et al., 2009] Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P., and Witten, I. H. (2009). The WEKA data mining software : an update. SIGKDD Explor. Newsl., 11(1) :10–18. 51 [Hasegawa et al., 2004] Hasegawa, T., Sekine, S., and Grishman, R. (2004). Discovering relations among named entities from large corpora. In Proceedings of the 42nd Annual Meeting on Association for Computational Linguistics, ACL ’04, Stroudsburg, PA, USA. Association for Computational Linguistics. 47 [Hayes, 1995] Hayes, P. (1995). A catalog of temporal theories. Technical report, University of Illinois. Tech report UIUC-BI-AI-96-01. 33 [Hecking, 2003] Hecking, M. (2003). Information extraction from battlefield reports. Proceedings of the 8thInternational Command and Control Research and Technology Symposium (ICCRTS). 53 [Higginbotham et al., 2000] Higginbotham, J., Pianesi, F., and Varzi, A. (2000). Speaking of Events. Oxford University Press. 26 [Hobbs et al., 1997] Hobbs, J. R., Appelt, D. E., Bear, J., Israel, D. J., Kameyama, M., Stickel, M. E., and Tyson, M. (1997). FASTUS : A Cascaded Finite-State Transducer for Extracting Information from Natural-Language Text. CoRR, cmp-lg/9705013. 44 [Hobbs and Riloff, 2010] Hobbs, J. R. and Riloff, E. (2010). Information extraction. In Handbook of Natural Language Processing, Second Edition. CRC Press, Taylor and Francis Group, Boca Raton, FL. 40, 43 179 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Hogenboom et al., 2011] Hogenboom, F., Frasincar, F., Kaymak, U., and de Jong, F. (2011). An Overview of Event Extraction from Text. In van Erp, M., van Hage, W. R., Hollink, L., Jameson, A., and Troncy, R., editors, Workshop on Detection, Representation, and Exploitation of Events in the Semantic Web (DeRiVE 2011) at Tenth International Semantic Web Conference (ISWC 2011), volume 779 of CEUR Workshop Proceedings, pages 48–57. CEUR-WS.org. 42, 56 [Horrocks, 2002] Horrocks, I. (2002). daml+oil : a description logic for the semantic web. IEEE Data Engineering Bulletin, 25 :4–9. 22 [Huffman, 1995] Huffman, S. (1995). Learning information extraction patterns from examples. In Connectionist, Statistical, and Symbolic Approaches to Learning for Natural Language Processing, pages 246–260. Springer. 49 [Humphreys et al., 1997] Humphreys, K., Gaizauskas, R., and Azzam, S. (1997). Event coreference for information extraction. In Proceedings of the ACL-97 Workshop on Operational Factors in Practical, Robust Anaphora Resolution for Unrestricted Texts, Madrid, Spain. 66 [Inyaem et al., 2010a] Inyaem, U., Haruechaiyasak, C., Meesad, P., and Tran, D. (2010a). Terrorism event classification using fuzzy inference systems. CoRR, abs/1004.1772. 53 [Inyaem et al., 2010b] Inyaem, U., Meesad, P., Haruechaiyasak, C., and Tran, D. (2010b). Construction of fuzzy ontology-based terrorism event extraction. In WKDD, pages 391–394. IEEE Computer Society. 36 [Ireson et al., 2005] Ireson, N., Ciravegna, F., Califf, M. E., Freitag, D., Kushmerick, N., and Lavelli, A. (2005). Evaluating machine learning for information extraction. In Proceedings of the 22nd international conference on Machine learning, ICML ’05, pages 345–352, New York, NY, USA. ACM. 43 [Isozaki and Kazawa, 2002] Isozaki, H. and Kazawa, H. (2002). Efficient support vector classifiers for named entity recognition. In In Proceedings of the 19th International Conference on Computational Linguistics (COLING’02, pages 390–396. 45 [Ittoo et al., 2006] Ittoo, A., Zhang, Y., and Jiao, J. (2006). A text mining-based recommendation system for customer decision making in online product customization. In Management of Innovation and Technology, 2006 IEEE International Conference on, volume 1, pages 473–477. 54 [Jansche and Abney, 2002] Jansche, M. and Abney, S. P. (2002). Information extraction from voicemail transcripts. In In Proc. Conference on Empirical Methods in NLP. 53 [Jarrar and Meersman, 2009] Jarrar, M. and Meersman, R. (2009). Ontology engineering — the DOGMA approach. In Dillon, T. S., Chang, E., Meersman, R., and Sycara, K., editors, Advances in Web Semantics I, pages 7–34. Springer-Verlag, Berlin, Heidelberg. 22 [Jason et al., 2004] Jason, R. S., Crawford, J., Kephart, J., and Leiba, B. (2004). Spamguru : An enterprise anti-spam filtering system. In In Proceedings of the First Conference on E-mail and Anti-Spam, page 2004. 54 [Jean-Louis et al., 2012] Jean-Louis, L., Romaric, B., and Ferret, O. (2012). Une méthode d’extraction d’information fondée sur les graphes pour le remplissage de formulaires. In Actes de la 19e conférence sur le Traitement Automatique des Langues Naturelles (TALN’2012), pages 29–42, Grenoble, France. 49 [Ji, 2010] Ji, H. (2010). Challenges from information extraction to information fusion. In Proceedings of the 23rd International Conference on Computational Linguistics : Posters, COLING ’10, pages 507–515, Stroudsburg, PA, USA. Association for Computational Linguistics. 62 180 Copyright c 2013 - CASSIDIAN - All rights reserved[Ji et al., 2009] Ji, H., Grishman, R., Chen, Z., and Gupta, P. (2009). Cross-document Event Extraction and Tracking : Task, Evaluation, Techniques and Challenges. Society, pages 166–172. 64 [Jonasson, 1994] Jonasson, K. (1994). Le Nom Propre, Constructions et interprétations. Champs linguistiques. Duculot. 44 [Khrouf and Troncy, 2012] Khrouf, H. and Troncy, R. (2012). Réconcilier les événements dans le web de données. In Actes de IC2011, pages 723–738, Chambéry, France. 66, 67 [Kifer et al., 1995] Kifer, M., Lausen, G., and Wu, J. (1995). Logical foundations of object-oriented and frame-based languages. J. ACM, 42(4) :741–843. 22 [Kim, 1973] Kim, J. (1973). Causation, nomic subsumption, and the concept of event. Journal of Philosophy, 70(8) :217–236. 26 [Krieg-Planque, 2009] Krieg-Planque, A. (2009). A propos des noms propres d’événement, volume 11, pages 77–90. Les carnets du Cediscor. 27 [Kripke, 1980] Kripke, S. (1980). Naming and Necessity. Harvard University Press. 41 [Ladkin, 1987] Ladkin, P. (1987). The logic of time representation. phdphd, University of California, Berkeley. 33, 76 [Lafferty et al., 2001] Lafferty, J. D., McCallum, A., and Pereira, F. C. N. (2001). Conditional random fields : Probabilistic models for segmenting and labeling sequence data. In Proceedings of the Eighteenth International Conference on Machine Learning, ICML ’01, pages 282–289, San Francisco, CA, USA. Morgan Kaufmann Publishers Inc. 45 [LaFree and Dugan, 2007] LaFree, G. and Dugan, L. (2007). Introducing the Global Terrorism Database. Terrorism and Political Violence, 19(2) :181–204. 123 [Largeron et al., 2009] Largeron, C., Kaddour, B., and Fernandez, M. (2009). Softjaccard : une mesure de similarité entre ensembles de chaînes de caratères pour l’unification d’entités nommées. In Ganascia, J.-G. and Gançarski, P., editors, EGC, volume RNTI-E-15 of Revue des Nouvelles Technologies de l’Information, pages 443–444. Cépaduès-Éditions. 112 [Lavelli et al., 2004] Lavelli, A., Califf, M. E., Ciravegna, F., Freitag, D., Giuliano, C., Kushmerick, N., and Romano, L. (2004). IE evaluation : Criticisms and recommendations. In In AAAI-2004 Workshop on Adaptive Text Extraction and Mining. 58 [Lawrence et al., 1999] Lawrence, S., Giles, C. L., and Bollacker, K. (1999). Digital libraries and autonomous citation indexing. IEEE COMPUTER, 32(6) :67–71. 54 [LDC, 2005] LDC, L. D. C. (2005). ACE (Automatic Content Extraction) : English annotation guidelines for events, version 5.4.3 2005.07.01 edition edition. 28 [Lee et al., 2012] Lee, H., Recasens, M., Chang, A., Surdeanu, M., and Jurafsky, D. (2012). Joint entity and event coreference resolution across documents. In Proceedings of the 2012 Joint Conference on Empirical Methods in Natural Language Processing and Computational Natural Language Learning, EMNLP-CoNLL ’12, pages 489–500, Stroudsburg, PA, USA. Association for Computational Linguistics. 66 [Lejeune et al., 2010] Lejeune, G., Doucet, A., Yangarber, R., and Lucas, N. (2010). Filtering news for epidemic surveillance : towards processing more languages with fewer resources. In CLIA/COLING, pages 3–10. 53 [Ligeza and Bouzid, 2008] Ligeza, A. and Bouzid, M. (2008). Temporal specifications with xtus. a hierarchical algebraic approach. In Cotta, C., Reich, S., Schaefer, R., and Lig˛eza, A., editors, KnowledgeDriven Computing, volume 102 of Studies in Computational Intelligence, pages 133–148. Springer Berlin / Heidelberg. 76 181 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Liu et al., 2008] Liu, M., Liu, Y., Xiang, L., Chen, X., and Yang, Q. (2008). Extracting key entities and significant events from online daily news. In IDEAL, pages 201–209. 53 [Llorens Martínez, 2011] Llorens Martínez, H. (2011). A semantic approach to temporal information processing. PhD thesis, Universidad de Alicante. 103 [Lofi et al., 2012] Lofi, C., Selke, J., and Balke, W.-T. (2012). Information extraction meets crowdsourcing : A promising couple. Datenbank-Spektrum, 12(2) :109–120. 58 [Luberg et al., 2012] Luberg, A., Järv, P., and Tammet, T. (2012). Information extraction for a tourist recommender system. In Fuchs, M., Ricci, F., and Cantoni, L., editors, Information and Communication Technologies in Tourism 2012, pages 332–343. Springer Vienna. 54 [Mann and Yarowsky, 2003] Mann, G. S. and Yarowsky, D. (2003). Unsupervised personal name disambiguation. In Proceedings of the Seventh Conference on Natural Language Learning at HLT-NAACL 2003 - Volume 4, CONLL ’03, pages 33–40, Stroudsburg, PA, USA. Association for Computational Linguistics. 105 [Mannes and Golbeck, 2005] Mannes, A. and Golbeck, J. (2005). Building a terrorism ontology. In ISWC Workshop on Ontology Patterns for the Semantic Web. 36 [Maurel et al., 2011] Maurel, D., Friburger, N., Antoine, J.-Y., Eshkol, I., and Nouvel, D. (2011). Cascades de transducteurs autour de la reconnaissance des entités nommées. Traitement Automatique des Langues, 52(1) :69–96. 44 [McCallum, 2005] McCallum, A. (2005). Information extraction : Distilling structured data from unstructured text. Queue, 3(9) :48–57. 51 [McDermott, 1982] McDermott, D. (1982). A temporal logic for reasoning about processes and plans*. Cognitive Science, 6(2) :101–155. 33 [McDonald, 1996] McDonald, D. D. (1996). Internal and external evidence in the identification and semantic categorization of proper names. In Boguraev, B. and Pustejovsky, J., editors, Corpus processing for lexical acquisition, pages 21–39. MIT Press, Cambridge, MA, USA. 44 [Mihalcea and Csomai, 2007] Mihalcea, R. and Csomai, A. (2007). Wikify ! : linking documents to encyclopedic knowledge. In Proceedings of the sixteenth ACM conference on Conference on information and knowledge management, CIKM ’07, pages 233–242, New York, NY, USA. ACM. 58 [Mikheev, 1999] Mikheev, A. (1999). A knowledge-free method for capitalized word disambiguation. Proceedings of the 37th annual meeting of the Association for Computational Linguistics on Computational Linguistics -, pages 159–166. 89 [Mikheev et al., 1999] Mikheev, A., Moens, M., and Grover, C. (1999). Named entity recognition without gazetteers. In Proceedings of the ninth conference on European chapter of the Association for Computational Linguistics, EACL’99, pages 1–8, Stroudsburg, PA, USA. Association for Computational Linguistics. 45 [Milne and Witten, 2008] Milne, D. and Witten, I. H. (2008). Learning to link with wikipedia. In Proceedings of the 17th ACM conference on Information and knowledge management, CIKM ’08, pages 509–518, New York, NY, USA. ACM. 58, 65 [Minard, 2008] Minard, A.-L. (2008). Etat de l’art des ontologies d’objets géographiques. Master’s thesis, Laboratoire COGIT (IGN). 35 [Mintz et al., 2009] Mintz, M., Bills, S., Snow, R., and Jurafsky, D. (2009). Distant supervision for relation extraction without labeled data. In Proceedings of the Joint Conference of the 47th Annual 182 Copyright c 2013 - CASSIDIAN - All rights reservedMeeting of the ACL and the 4th International Joint Conference on Natural Language Processing of the AFNLP : Volume 2 - Volume 2, ACL ’09, pages 1003–1011, Stroudsburg, PA, USA. Association for Computational Linguistics. 47 [Mizoguchi, 2003a] Mizoguchi, R. (2003a). Tutorial on ontological engineering : Part 1 : Introduction to ontological engineering. New Generation Comput., 21(4) :365–384. 22, 78 [Mizoguchi, 2003b] Mizoguchi, R. (2003b). Tutorial on ontological engineering : Part 2 : Ontology development, tools and languages. New Generation Comput., 22(1) :61–96. 22 [Montague, 1969] Montague, R. (1969). On the nature of certain philosophical entities. The Monist, 53(2) :159–194. 26 [Moreau et al., 2008] Moreau, E., Yvon, F., and Cappé, O. (2008). Robust similarity measures for named entities matching. In Proceedings of the 22nd International Conference on Computational Linguistics - Volume 1, COLING ’08, pages 593–600, Stroudsburg, PA, USA. Association for Computational Linguistics. 66 [Muller and Tannier, 2004] Muller, P. and Tannier, X. (2004). Annotating and measuring temporal relations in texts. In Coling 2004 , Genève,, pages 50–56. Association for Computational Linguistics. 46 [Muslea, 1999] Muslea, I. (1999). Extraction Patterns for Information Extraction Tasks : A Survey. Proc. AAAI-99 Workshop Machine Learning for Information Extraction, pages 1–6. 43 [Nadeau and Sekine, 2007] Nadeau, D. and Sekine, S. (2007). A survey of named entity recognition and classification. Linguisticae Investigationes, 30(1) :3–26. Publisher : John Benjamins Publishing Company. 41, 43, 44, 58 [Nakamura-Delloye and Villemonte De La Clergerie, 2010] Nakamura-Delloye, Y. and Villemonte De La Clergerie, É. (2010). Exploitation de résultats d’analyse syntaxique pour extraction semisupervisée des chemins de relations. In TALN 2010, page taln2010_submission_164, Montréal, Canada. 46 [NATO, 2001] NATO (2001). The NATO Military Intelligence Data Exchange Standard AINTP-3(A). Technical report, NATO. 36 [NATO, 2007] NATO (2007). Joint c3 information exchange data model - jc3iedm. Technical report, NATO. 36 [Naughton et al., 2006] Naughton, M., Kushmerick, N., and Carthy, J. (2006). Event extraction from heterogeneous news sources. In Proc. Workshop Event Extraction and Synthesis. American Nat. Conf. Artificial Intelligence. 41, 66 [Neches et al., 1991] Neches, R., Fikes, R., Finin, T., Gruber, T., Patil, R., Senator, T., and Swartout, W. R. (1991). Enabling technology for knowledge sharing. AI Mag., 12(3) :36–56. 21 [Neveu and Quéré, 1996] Neveu, E. and Quéré, L. (1996). Le temps de l’événement I, chapter Présentation, pages 7–21. Number 75 in Réseaux. CNET. 27, 75 [Newcombe et al., 1959] Newcombe, H. B., Kennedy, J. M., Axford, S. J., and James, A. P. (1959). Automatic Linkage of Vital Records. Science, 130(3381) :954–959. 63 [Nishihara et al., 2009] Nishihara, Y., Sato, K., and Sunayama, W. (2009). Event extraction and visualization for obtaining personal experiences from blogs. In Proceedings of the Symposium on Human Interface 2009 on Human Interface and the Management of Information. Information and Interaction. Part II : Held as part of HCI International 2009, pages 315–324, Berlin, Heidelberg. Springer-Verlag. 54 183 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [NIST, 2005] NIST (2005). The ACE 2005 (ACE05) Evaluation Plan. 28 [Noël, 2008] Noël, L. (2008). From semantic web data to inform-action : a means to an end. Workshop SWUI (Semantic Web User Interaction), CHI 2008, 5-10 Avril, 2008, Florence, Italie. 136 [Noy and Mcguinness, 2001] Noy, N. F. and Mcguinness, D. L. (2001). Ontology Development 101 : A Guide to Creating Your First Ontology. Technical Report KSL-01-05, Stanford Knowledge Systems Laboratory. 22, 78, 79 [Padró and Stanilovsky, 2012] Padró, L. and Stanilovsky, E. (2012). Freeling 3.0 : Towards wider multilinguality. In Proceedings of the Language Resources and Evaluation Conference (LREC 2012), Istanbul, Turkey. ELRA. 51 [Paquet, 2008] Paquet, P. (2008). De l’information à la connaissance. In Information et communication et management dans l’entreprise : quels enjeux ?, pages 17–48. Harmattan. 18 [Paumier, 2003] Paumier, S. (2003). A Time-Efficient Token Representation for Parsers. In Proceedings of the EACL Workshop on Finite-State Methods in Natural Language Processing, pages 83–90, Budapest. 52 [Pauna and Guillemin-Lanne, 2010] Pauna, R. and Guillemin-Lanne, S. (2010). Comment le text mining peut-il aider à gérer le risque militaire et stratégique ? Text. 53 [Piskorski and Atkinson, 2011] Piskorski, J. and Atkinson, M. (2011). Frontex real-time news event extraction framework. In Proceedings of the 17th ACM SIGKDD international conference on Knowledge discovery and data mining, KDD ’11, pages 749–752, New York, NY, USA. ACM. 53 [Piskorski et al., 2007] Piskorski, J., Tanev, H., and Wennerberg, P. O. (2007). Extracting violent events from on-line news for ontology population. In Proceedings of the 10th international conference on Business information systems, BIS’07, pages 287–300, Berlin, Heidelberg. Springer-Verlag. 54 [Piskorski and Yangarber, 2013] Piskorski, J. and Yangarber, R. (2013). Information extraction : Past, present and future. In Poibeau, T., Saggion, H., Piskorski, J., and Yangarber, R., editors, Multi-source, Multilingual Information Extraction and Summarization, Theory and Applications of Natural Language Processing, pages 23–49. Springer Berlin Heidelberg. 57 [Poibeau, 2003] Poibeau, T. (2003). Extraction automatique d’information : Du texte brut au web sé- mantique. Lavoisier. 40 [Polanyi, 1966] Polanyi, M. (1966). The tacit dimension. Routledge and Keagan Paul. 18 [Popescu et al., 2011] Popescu, A.-M., Pennacchiotti, M., and Paranjpe, D. (2011). Extracting events and event descriptions from Twitter. In Proceedings of the 20th international conference companion on World wide web, WWW ’11, pages 105–106, New York, NY, USA. ACM. 54 [Pustejovsky et al., 2003] Pustejovsky, J., Castaño, J. M., Ingria, R., Sauri, R., Gaizauskas, R. J., Setzer, A., Katz, G., and R., R. D. (2003). TimeML : Robust specification of event and temporal expressions in text. In New Directions in Question Answering’03, pages 28–34. 27 [Quine, 1985] Quine, W. V. (1985). Events and reification. In Actions and Events : Perspectives on the Philosophy of Davidson, pages 162–71. Blackwell. 66 [Quine, 1960] Quine, W. V. O. (1960). Word and Object. MIT Press paperback series. Technology Press of the Massachusetts Inst. of Technology. 26 [Radev et al., 2001] Radev, D. R., Blair-Goldensohn, S., Zhang, Z., and Raghavan, R. S. (2001). Interactive, domain-independent identification and summarization of topically related news articles. In Proceedings of the 5th European Conference on Research and Advanced Technology for Digital Libraries, ECDL ’01, pages 225–238, London, UK, UK. Springer-Verlag. 54 184 Copyright c 2013 - CASSIDIAN - All rights reserved[Raimond et al., 2007] Raimond, Y., Abdallah, S. A., Sandler, M. B., and Giasson, F. (2007). The music ontology. In ISMIR, pages 417–422. 28 [Randell et al., 1992] Randell, D. A., Cui, Z., and Cohn, A. G. (1992). A spatial logic based on regions and connection. In Proceedings of the 3rd international conference on knowledge representation and reasoning. 35 [Ratinov et al., 2011] Ratinov, L., Roth, D., Downey, D., and Anderson, M. (2011). Local and global algorithms for disambiguation to wikipedia. In Proceedings of the 49th Annual Meeting of the Association for Computational Linguistics : Human Language Technologies - Volume 1, HLT ’11, pages 1375–1384, Stroudsburg, PA, USA. Association for Computational Linguistics. 58 [Rattenbury et al., 2007] Rattenbury, T., Good, N., and Naaman, M. (2007). Towards automatic extraction of event and place semantics from flickr tags. In Proceedings of the 30th annual international ACM SIGIR conference on Research and development in information retrieval, SIGIR ’07, pages 103–110, New York, NY, USA. ACM. 54 [Ricœur, 1983] Ricœur, P. (1983). Temps et récit 1. L´intrigue et le récit historique, volume 227 of Points : Essais. Ed. du Seuil, Paris. 27 [Rosario and Hearst, 2004] Rosario, B. and Hearst, M. A. (2004). Classifying semantic relations in bioscience texts. Proceedings of the 42nd Annual Meeting on Association for Computational Linguistics - ACL ’04, pages 430–es. 47 [Rosario and Hearst, 2005] Rosario, B. and Hearst, M. A. (2005). Multi-way relation classification : application to protein-protein interactions. In Proceedings of the conference on Human Language Technology and Empirical Methods in Natural Language Processing, HLT ’05, pages 732–739, Stroudsburg, PA, USA. Association for Computational Linguistics. 41, 53 [Saurí et al., 2005] Saurí, R., Knippen, R., Verhagen, M., and Pustejovsky, J. (2005). Evita : a robust event recognizer for QA systems. In Proceedings of the conference on Human Language Technology and Empirical Methods in Natural Language Processing, HLT ’05, pages 700–707, Stroudsburg, PA, USA. Association for Computational Linguistics. 49, 54 [Saval, 2011] Saval, A. (2011). Modèle temporel, spatial et sémantique pour la découverte de relations entre évènements. PhD thesis, Univeristé de Caen Basse-Normandie. 27 [Saval et al., 2009] Saval, A., Bouzid, M., and Brunessaux, S. (2009). A Semantic Extension for Event Modelisation. 2009 21st IEEE International Conference on Tools with Artificial Intelligence, pages 139–146. 74, 75 [Sayyadi et al., 2009] Sayyadi, H., Hurst, M., and Maykov, A. (2009). Event Detection and Tracking in Social Streams. In Proceedings of International Conference on Weblogs and Social Media (ICWSM). 54 [Saïs et al., 2009] Saïs, F., Pernelle, N., and Rousset, M.-C. (2009). Combining a logical and a numerical method for data reconciliation. In Spaccapietra, S., editor, Journal on Data Semantics XII, volume 5480 of Lecture Notes in Computer Science, pages 66–94. Springer Berlin Heidelberg. 63 [Schmid, 1994] Schmid, H. (1994). Probabilistic part-of-speech tagging using decision trees. In Proceedings of the International Conference on New Methods in Language Processing, Manchester, UK. 99 [Sekine et al., 2002] Sekine, S., Sudo, K., and Nobata, C. (2002). Extended named entity hierarchy. In Rodríguez, M. G. and Araujo, C. P. S., editors, Proceedings of 3 rd International Conference on Language Resources and Evaluation (LREC’02), pages 1818–1824, Canary Islands, Spain. 58 185 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Serrano et al., 2013a] Serrano, L., Bouzid, M., Charnois, T., Brunessaux, S., and Grilheres, B. (2013a). Events extraction and aggregation for open source intelligence : from text to knowledge. In IEEE International Conference on Tools with Artificial Intelligence (ICTAI 2013), Washington DC, USA. [Serrano et al., 2013b] Serrano, L., Bouzid, M., Charnois, T., Brunessaux, S., and Grilheres, B. (2013b). Extraction et agrégation automatique d’événements pour la veille en sources ouvertes : du texte à la connaissance. In Ingénierie des Connaissances 2013 (IC 2013), Lille, France. [Serrano et al., 2012a] Serrano, L., Bouzid, M., Charnois, T., and Grilheres, B. (2012a). Vers un système de capitalisation des connaissances : extraction d’événements par combinaison de plusieurs approches. In Atelier des Sources Ouvertes au Web de Données (SOS-DLWD’2012) en conjonction avec la conférence internationale francophone (EGC 2012), Bordeaux, France. [Serrano et al., 2012b] Serrano, L., Charnois, T., Brunessaux, S., Grilheres, B., and Bouzid, M. (2012b). Combinaison d’approches pour l’extraction automatique d’événements (automatic events extraction by combining multiple approaches) [in french]. In Actes de la conférence conjointe JEP-TALNRECITAL 2012, volume 2 : TALN, Grenoble, France. ATALA/AFCP. [Serrano et al., 2011] Serrano, L., Grilheres, B., Bouzid, M., and Charnois, T. (2011). Extraction de connaissances pour le renseignement en sources ouvertes. In Atelier Sources Ouvertes et Services (SOS 2011) en conjonction avec la conférence internationale francophone (EGC 2011), Brest, France. [Silberztein et al., 2012] Silberztein, M., Váradi, T., and Tadic, M. (2012). Open source multi-platform nooj for nlp. In COLING (Demos), pages 401–408. 52 [Smart et al., 2007] Smart, P., Russell, A., Shadbolt, N., Shraefel, M., and Carr, L. (2007). Aktivesa. Comput. J., 50 :703–716. 36 [Soderland, 1999] Soderland, S. (1999). Learning information extraction rules for semi-structured and free text. Mach. Learn., 34 :233–272. 43 [Sun et al., 2005] Sun, Z., Lim, E.-P., Chang, K., Ong, T.-K., and Gunaratna, R. K. (2005). Event-driven document selection for terrorism information extraction. In Proceedings of the 2005 IEEE international conference on Intelligence and Security Informatics, ISI’05, pages 37–48, Berlin, Heidelberg. Springer-Verlag. 53 [Tanev et al., 2008] Tanev, H., Piskorski, J., and Atkinson, M. (2008). Real-time news event extraction for global crisis monitoring. In Proceedings of the 13th international conference on Natural Language and Information Systems : Applications of Natural Language to Information Systems, NLDB ’08, pages 207–218, Berlin, Heidelberg. Springer-Verlag. 53 [Tarski, 1956] Tarski, A. (1956). Logic, Semantics, Metamathematics, chapter Foundations of the Geometry of Solids. Oxford, Clarendon Press. 35 [Thompson et al., 1999] Thompson, C. A., Califf, M. E., and Mooney, R. J. (1999). Active learning for natural language parsing and information extraction. In Proceedings of the Sixteenth International Conference on Machine Learning, ICML ’99, pages 406–414, San Francisco, CA, USA. Morgan Kaufmann Publishers Inc. 58 [Tkachenko and Simanovsky, 2012] Tkachenko, M. and Simanovsky, A. (2012). Named entity recognition : Exploring features. In Jancsary, J., editor, Proceedings of KONVENS 2012, pages 118–127. ÖGAI. Main track : oral presentations. 45 [Troncy et al., 2010] Troncy, R., Shaw, R., and Hardman, L. (2010). LODE : une ontologie pour repré- senter des événements dans le web de données. In IC 2010, 21st Journées Francophones d’Ingénierie des Connaissances, June 8-11, 2010, Nîmes, France, Nîmes, FRANCE. 29 186 Copyright c 2013 - CASSIDIAN - All rights reserved[Van De Velde, 2006] Van De Velde, D. (2006). Grammaire des événements. Presses Universitaires du Septentrion. 26 [van Hage et al., 2011] van Hage, W. R., Malaisé, V., Segers, R., Hollink, L., and Schreiber, G. (2011). Design and use of the Simple Event Model (SEM). Web Semantics : Science, Services and Agents on the World Wide Web, 9(2) :128–136. 30 [Vargas-Vera and Celjuska, 2004] Vargas-Vera, M. and Celjuska, D. (2004). Event recognition on news stories and semi-automatic population of an ontology. In Proceedings of the 2004 IEEE/WIC/ACM International Conference on Web Intelligence, WI ’04, pages 615–618, Washington, DC, USA. IEEE Computer Society. 54 [Varjola and Löffler, 2010] Varjola, M. and Löffler, J. (2010). PRONTO : Event Recognition for Public Transport. Proceedings of 17th ITS World Congress, Busan, Korea. 53 [Verykios and Elmagarmid, 1999] Verykios, V. S. and Elmagarmid, A. K. (1999). Automating the approximate record matching process. Information Sciences, 126 :83–98. 64 [Viola and Narasimhan, 2005] Viola, P. and Narasimhan, M. (2005). Learning to extract information from semi-structured text using a discriminative context free grammar. In Proceedings of the 28th annual international ACM SIGIR conference on Research and development in information retrieval, SIGIR ’05, pages 330–337, New York, NY, USA. ACM. 45 [Vlahovic, 2011] Vlahovic, N. (2011). Information Retrieval and Information Extraction in Web 2.0 environment. nternational Journal of Computers, 5(1). 40, 54 [Wacholder et al., 1997] Wacholder, N., Ravin, Y., and Choi, M. (1997). Disambiguation of proper names in text. In Proceedings of the fifth conference on Applied natural language processing, ANLC ’97, pages 202–208, Stroudsburg, PA, USA. Association for Computational Linguistics. 64 [Wakao et al., 1996] Wakao, T., Gaizauskas, R., and Wilks, Y. (1996). Evaluation of an algorithm for the recognition and classification of proper names. In Proceedings of the 16th conference on Computational linguistics - Volume 1, COLING ’96, pages 418–423, Stroudsburg, PA, USA. Association for Computational Linguistics. 44 [Wang et al., 2011] Wang, W., Besançon, R., Ferret, O., and Grau, B. (2011). Filtering and clustering relations for unsupervised information extraction in open domain. Proceedings of the 20th ACM international conference on Information and knowledge management - CIKM ’11, page 1405. 47 [Whitehead, 1920] Whitehead, A. (1920). The Concept of Nature. Dover science books. Dover Publications. 35 [Widlocher et al., 2006] Widlocher, A., Bilhaut, F., Hernandez, N., Rioult, F., Charnois, T., Ferrari, S., and Enjalbert, P. (2006). Une approche hybride de la segmentation thématique : collaboration du traitement automatique des langues et de la fouille de texte. In Actes de DEfi Fouille de Texte (DEFT’06), Semaine du Document Numérique (SDN’06), Fribourg, Suisse. 52 [Winkler et al., 2006] Winkler, W. E., Winkler, W. E., and P, N. (2006). Overview of record linkage and current research directions. Technical report, Bureau of the Census. 63, 109 [Xu et al., 2006] Xu, F., Uszkoriet, H., and Li, H. (2006). Automatic Event and Relation Detection with Seeds of Varying Complexity. In AAAI 2006 Workshop on Event Extraction and Synthesis. 49 [Yates and Etzioni, 2009] Yates, A. and Etzioni, O. (2009). Unsupervised methods for determining object and relation synonyms on the web. J. Artif. Intell. Res. (JAIR), 34 :255–296. 66 187 Copyright c 2013 - CASSIDIAN - All rights reservedBibliographie [Zanasi, 2009] Zanasi, A. (2009). Virtual weapons for real wars : Text mining for national security. In Corchado, E., Zunino, R., Gastaldo, P., and Herrero, A., editors, Proceedings of the International Workshop on Computational Intelligence in Security for Information Systems CISIS’08, volume 53 of Advances in Soft Computing, pages 53–60. Springer Berlin Heidelberg. 53 [Zhao, 2004] Zhao, S. (2004). Named entity recognition in biomedical texts using an hmm model. In Proceedings of the International Joint Workshop on Natural Language Processing in Biomedicine and its Applications, JNLPBA ’04, pages 84–87, Stroudsburg, PA, USA. Association for Computational Linguistics. 45 [Zhu and Porter, 2002] Zhu, D. and Porter, A. L. (2002). Automated extraction and visualization of information for technological intelligence and forecasting. Technological Forecasting and Social Change, 69(5) :495 – 506. TF Highlights from {ISF} 2001. 53 [Zhu et al., 2009] Zhu, J., Nie, Z., Liu, X., Zhang, B., and Wen, J.-R. (2009). StatSnowball : a statistical approach to extracting entity relationships. In Proceedings of the 18th international conference on World wide web, WWW ’09, pages 101–110, New York, NY, USA. ACM. 47 188 Copyright c 2013 - CASSIDIAN - All rights reserved Normalisation et Apprentissage de Transductions d’Arbres en Mots Gr´egoire Laurence To cite this version: Gr´egoire Laurence. Normalisation et Apprentissage de Transductions d’Arbres en Mots. Databases. Universit´e des Sciences et Technologie de Lille - Lille I, 2014. French. . HAL Id: tel-01053084 https://tel.archives-ouvertes.fr/tel-01053084 Submitted on 29 Jul 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Universit´e des Sciences et Technologies de Lille – Lille 1 D´epartement de formation doctorale en informatique Ecole doctorale SPI Lille ´ UFR IEEA Normalisation et Apprentissage de Transductions d’Arbres en Mots THESE ` pr´esent´ee et soutenue publiquement le 4 Juin 2014 pour l’obtention du Doctorat de l’Universit´e des Sciences et Technologies de Lille (sp´ecialit´e informatique) par Gr´egoire Laurence Composition du jury Pr´esident : Olivier Carton (Olivier.Carton@liafa.univ-paris-diderot.fr) Rapporteurs : Olivier Carton (Olivier.Carton@liafa.univ-paris-diderot.fr) Marie-Pierre B´eal (beal@univ-mlv.fr) Directeur de th`ese : Joachim Niehren (joachim.niehren@lifl.fr) Co-Encadreur de th`ese : Aur´elien Lemay (aurelien.lemay@univ-lille3.fr) Laboratoire d’Informatique Fondamentale de Lille — UMR USTL/CNRS 8022 INRIA Lille - Nord EuropeRésumé Le stockage et la gestion de données sont des questions centrales en informatique. La structuration sous forme d’arbres est devenue la norme (XML, JSON). Pour en assurer la pérennité et l’échange efficace des données, il est nécessaire d’identifier de nouveaux mécanismes de transformations automatisables. Nous nous concentrons sur l’étude de transformations d’arbres en mots représentées par des machines à états finies. Nous définissons les transducteurs séquentiels d’arbres en mots ne pouvant utiliser qu’une et unique fois chaque nœud de l’arbre d’entrée pour décider de la production. En réduisant le problème d’équivalence des transducteurs séquentiels à celui des morphismes appliqués à des grammaires algébriques (Plandowski, 95), nous prouvons qu’il est décidable en temps polynomial. Cette thèse introduit la notion de transducteur travailleur, forme normalisée de transducteurs séquentiels, cherchant à produire la sortie le «plus tôt possible» dans la transduction. A l’aide d’un algorithme de normalisation et de minimisation, nous prouvons qu’il existe un représentant canonique, unique transducteur travailleur minimal, pour chaque transduction de notre classe. La décision de l’existence d’un transducteur séquentiel représentant un échantillon, i.e. paires d’entrées et sorties d’une transformation, est prouvée NP-difficile. Nous proposons un algorithme d’apprentissage produisant à partir d’un échantillon le transducteur canonique le représentant, ou échouant, le tout en restant polynomial. Cet algorithme se base sur des techniques d’infé- rence grammaticales et sur l’adaptation du théorème de Myhill-Nerode. Titre : Normalisation et Apprentissage de Transductions d’Arbres en MotsAbstract Storage, management and sharing of data are central issues in computer science. Structuring data in trees has become a standard (XML, JSON). To ensure preservation and quick exchange of data, one must identify new mechanisms to automatize such transformations. We focus on the study of tree to words transformations represented by finite state machines. We define sequential tree to words transducers, that use each node of the input tree exactly once to produce an output. Using reduction to the equivalence problem of morphisms applied to contextfree grammars (Plandowski, 95), we prove that equivalence of sequential transducers is decidable in polynomial time. We introduce the concept of earliest transducer, sequential transducers normal form, which aim to produce output "as soon as possible" during the transduction. Using normalization and minimization algorithms, we prove the existence of a canonical transducer, unique, minimal and earliest, for each transduction of our class. Deciding the existence of a transducer representing a sample, i.e. pairs of input and output of a transformation, is proved NP-hard. Thus, we propose a learning algorithm that generate a canonical transducer from a sample, or fail, while remaining polynomial. This algorithm is based on grammatical inference techniques and the adaptation of a Myhill-Nerode theorem. Title : Normalization and Learning of Tree to Words TransductionsRemerciements Cet espace me permettant de remercier toutes les personnes m’ayant aider à effectuer, rédiger, soutenir et fêter cette thèse, je tiens tout d’abord à saluer le travail effectué par Marie-Pierre Béal et Olivier Carton, qui ont du rapporter et être jury de cette thèse. Je les remercie d’avoir eu le courage de relire l’intégralité de ce manuscrit, des retours qu’ils m’en ont fait, et de l’intérêt qu’ils ont portés à mon travail. Cette thèse n’aurait jamais eu lieu sans la présence de mes encadrants, tout particulièrement Joachim Niehren qui m’a permis d’intégrer cette équipe dès mon stage de recherche, et lancé les travaux qui mènent à ce que vous tenez maintenant entre vos mains. Merci à Joachim, Aurélien Lemay, Slawek Staworko et Marc Tommasi de m’avoir suivi pendant cette (longue) épreuve, de m’avoir guidé, soutenu, et aider à mener cette thèse pour arriver à ce résultat qui je l’espère vous fait autant plaisir qu’a moi. Tout n’a pas toujours été facile, je n’ai pas toujours été aussi investi qu’il aurait fallut, mais vous avez toujours réussi à me remettre sur la route, et permis d’arriver à cette étape. Je ne peut remercier mes encadrants sans penser à l’intégralité des membres de l’équipe Mostrare (links, magnet, et même avant) qui m’ont permis de passer ces quelques années dans un parfait environnement de travail (mais pas que). Ayant plus ou moins intégré cette équipe depuis mon stage de maitrise (grâce à Isabelle Tellier et Marc), il me serait difficile d’énumérer ici l’intégralité des membres que j’y ai croisé, et ce que chacun m’a apporté. Je m’adonne quand même à ce petit exercice pour l’ensemble des doctorants qui ont partagé cette position de thésard dans l’équipe : Jérôme, Olivier, Edouard, Benoît, Antoine, Tom, Jean, Adrien, Radu, et Guillaume (même si il n’était pas doctorant). Ces années ont également été occupées par mes différents postes dans l’enseignements à Lille 3 ou encore Lille 1 et je remercie l’ensemble des enseignants qui m’ont aidés et accompagné durant cette tâche, tout particulièrement Alain Taquet avec qui j’ai partagé mes premiers enseignements. Même si il n’ont pas à proprement contribué à ce que contient cette thèse (enfin ça dépend lesquels), malgré eux ils y sont pour beaucoup, je parle bien entendu de mes amis et ma famille. Je n’en ferait pas non plus la liste ici, n’en déplaise à certains, mais je remercie tout particulièrement mes parents, ma soeur pour m’avoir supporter et permis d’en arriver là, mon parrain et ma marraine pour leur présence et l’intérêt tout particulier qu’ils ont portés à ma thèse. Merci à toute ma famille et mes amis d’avoir été présents avant, pendant, et je l’espère encore longtemps après cette thèse, d’avoir réussi à me lafaire oubliée parfois. Une pensée toute particulière à Sébatien Lemaguer qui a eu la lourde tâche de relire l’intégralité de cette thèse (sauf ces remerciements) à la recherche de fautes (trop nombreuses). Je ne pouvait pas finir ces remerciement sans parler de mon amie, amour, Manon, a qui cette thèse appartient au moins autant qu’a moi, support inconditionnel dans l’ombre sans qui je n’aurai surement pas réussi à terminer cette thèse. Elle a vécue au moins autant que moi toute cette épreuve, jusqu’à son dernier moment, et m’a permis de malgré tout mes périodes de doutes d’aboutir à ce résultat. Merci à toi, et merci à vous tous.Table des matières Introduction 1 1 Automates 11 1.1 Mots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1.1 Mots et langages . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1.2 Grammaires . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.3 Automates . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2 Arbres d’arité bornée . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.2 Automates d’arbres . . . . . . . . . . . . . . . . . . . . . . 21 1.3 Arbres d’arité non-bornée . . . . . . . . . . . . . . . . . . . . . . . 25 1.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.3.2 Comment définir les automates ? . . . . . . . . . . . . . . 25 1.3.3 Codage binaire curryfié (ascendant) . . . . . . . . . . . . 26 1.3.4 Codage binaire frère-fils (descendant) . . . . . . . . . . . 29 1.4 Mots imbriqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.4.2 Linéarisation d’arbres d’arité non-bornée . . . . . . . . . 32 1.4.3 Automates de mots imbriqués . . . . . . . . . . . . . . . . 33 1.4.4 Automate descendant . . . . . . . . . . . . . . . . . . . . . 34 2 Transducteurs 37 2.1 Transducteurs de mots . . . . . . . . . . . . . . . . . . . . . . . . 39 2.1.1 Transducteurs rationnels . . . . . . . . . . . . . . . . . . . 39 2.1.2 Transducteurs déterministes . . . . . . . . . . . . . . . . . 50 2.1.3 Transducteurs déterministes avec anticipation . . . . . . 76 2.2 Transducteur d’arbres d’arité bornée . . . . . . . . . . . . . . . . 80 2.2.1 Transducteur descendants . . . . . . . . . . . . . . . . . . 81 2.2.2 Transducteur ascendant . . . . . . . . . . . . . . . . . . . 88 2.2.3 Transducteur avec anticipation . . . . . . . . . . . . . . . 90 2.2.4 Macro-transducteurs descendants . . . . . . . . . . . . . . 93 2.3 Transducteurs d’arbres en mots . . . . . . . . . . . . . . . . . . . 95 2.3.1 Transducteurs descendants . . . . . . . . . . . . . . . . . . 95 2.3.2 Transducteurs ascendants . . . . . . . . . . . . . . . . . . 98 2.4 Transducteurs d’arbres d’arité non bornée . . . . . . . . . . . . . 100 2.4.1 Transducteurs de mots imbriqués en mots . . . . . . . . 101 2.4.2 Transducteurs de mots imbriqués en mots imbriqués . . 1043 Transformations XML 105 3.1 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.1.1 XSLT en Pratique . . . . . . . . . . . . . . . . . . . . . . . 105 3.2 Transducteurs et xslt . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.2.1 dST2W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.2.2 Macro-Transducteurs et xpath . . . . . . . . . . . . . . . 110 4 Équivalence de transducteurs séquentiels d’arbres en mots 115 4.1 Relation avec l’équivalence de morphismes sur CFGs . . . . . . 115 4.1.1 Exécution d’un dNW2W . . . . . . . . . . . . . . . . . . 116 4.1.2 Arbre syntaxique étendu . . . . . . . . . . . . . . . . . . . 116 4.2 Relation entre dB2W et dT2W . . . . . . . . . . . . . . . . . . . 121 5 Normalisation et minimisation des transducteurs descendants d’arbres en mots 125 5.1 dST2W travailleur . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.2 Caractérisation sémantique . . . . . . . . . . . . . . . . . . . . . . 127 5.2.1 Approche naïve . . . . . . . . . . . . . . . . . . . . . . . . 127 5.2.2 Décompositions et résiduels . . . . . . . . . . . . . . . . . 129 5.2.3 Transducteur canonique . . . . . . . . . . . . . . . . . . . 133 5.3 Minimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.3.1 Minimisation des edST2Ws . . . . . . . . . . . . . . . . . 135 5.3.2 Minimisation de dST2Ws arbitraires . . . . . . . . . . . 138 5.4 Normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 5.4.1 Réduction de langages . . . . . . . . . . . . . . . . . . . . 143 5.4.2 Faire traverser un mot dans un langage . . . . . . . . . . 143 5.4.3 Déplacement de gauche à droite . . . . . . . . . . . . . . 148 5.4.4 Algorithme de normalisation . . . . . . . . . . . . . . . . 151 5.4.5 Bornes exponentielles . . . . . . . . . . . . . . . . . . . . . 158 6 Apprentissage de transducteurs descendants d’arbres en mots161 6.1 Théorème de Myhill-Nerode . . . . . . . . . . . . . . . . . . . . . 161 6.2 Consistence des dST2Ws . . . . . . . . . . . . . . . . . . . . . . . 162 6.3 Modèle d’apprentissage . . . . . . . . . . . . . . . . . . . . . . . . 165 6.4 Algorithme d’apprentissage . . . . . . . . . . . . . . . . . . . . . . 166 6.5 Décompositions, résiduels et équivalence . . . . . . . . . . . . . . 166 6.6 Echantillon caractéristique . . . . . . . . . . . . . . . . . . . . . . 170 7 Conclusion 177 7.1 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Bibliographie 183Introduction De tout temps, le stockage, la gestion et l’échange de données sont des questions centrales en informatique, plus encore de nos jours, la quantité de données devenant de plus en plus importante et partagée entre différents services. La structuration des données participe énormément à ces défis. Elle permet par exemple d’intégrer une certaine sémantique absolument nécessaire pour l’échange, d’effectuer plus efficacement des traitements comme des requêtes ou des transformations. Les arbres de données sont une telle représentation structurée des informations. Mon travail de thèse est une contribution à l’étude de ces arbres de données et particulièrement leurs transformations. Une question centrale que j’aborde consiste en la définition d’algorithmes d’apprentissage de ces programmes de transformations, que je représente sous la forme de machines à états finis : les transducteurs. Arbres de données Les arbres de données permettent d’apporter une structure à des données textuelles. Ces arbres sont composés de nœuds étiquetés par des symboles issus d’un alphabet fini. Les valeurs textuelles se retrouvent au niveau du feuillage de l’arbre ou dans ses nœuds internes sous forme d’attributs. Elles sont composés à partir d’un alphabet fini, comme par exemple celui de l’ASCII ou de l’unicode, mais ne sont pas bornées en taille. Certains modèles existants, tels que le xml (recommandation du W3C) ou JSON (JavaScript Object Notation), cherchent à homogénéiser le format des données des documents structurés sous forme d’arbre en proposant une syntaxe permettant de les représenter. Que ce soit sous forme d’arbres d’arité non bornée, ordonnés, associés à des champs textuels et des enregistrements pour le xml, ou d’arbres d’arité bornée et d’ensembles d’enregistrements non bornés ni ordonnés pour ce qui est de JSON, le but reste de spécifier une syntaxe en limitant le moins possible la sémantique que l’utilisateur souhaite associer à la structure. Certains formats de données qui en découlent limitent le choix des étiquettes de nœuds utilisables dans la structure. Ces étiquettes (les balises) doivent appartenir à un ensemble fini et fixé et portent chacune une sémantique forte. C’est le cas de fichiers html ou des méta-données contenues dans certains document issus de logiciels de traitement de texte. Les arbres de données peuvent se trouver également dans les bases de données, ou encore2 Introduction dans le «Cloud computing», où même si parfois ils partagent des syntaxes proches, peuvent être utilisés dans des domaines totalement différents avec des sémantiques qui leurs sont propres. Que ce soit pour l’échange, la mise en relation ou la sélection de données, il devient de plus en plus nécessaire, au delà des modifications automatiques de texte, comme pouvait le permettre des programmes tels que Perl, d’identifier de nouveaux mécanismes de transformation basés sur la structure. Il est surtout intéressant de voir jusqu’où les méta-données contenues dans la structure même jouent un rôle dans le choix des transformations à effectuer. Transformations Pour cela, il faut dans un premier temps se demander quel type de transformation nous intéresse. Il existe déjà plusieurs moyens de transformer des arbres de données, que ce soit pour une tâche spécifique ou comme le permet le langage xslt, une représentation des transformations dans le sens le plus large du terme. Le langage de programmation xslt (Clark, 1999), pour «eXtensible Stylesheet Language Transformations», est un langage défini au sein de la recommandation xsl du consortium W3C. Il permet de transformer des arbres de données, représentés par un ou plusieurs xml, en données de différents types, xml, textuels ou même binaires. Il est lui même repré- senté sous la forme d’un arbre de données dont certaines étiquettes de noeuds spécifient les fonctions de transformation à appliquer. Cette application passe par la sélection de noeuds à transformer à l’aide de requêtes xpath (Clark et DeRose, 1999). Ces requêtes permettent la sélection de noeuds dans un arbre de données à l’aide d’opérations primitives de déplacement dans la fi- liation de l’arbre. Une grande expressivité se faisant souvent au détriment de la complexité, xslt est un programme Turing-complet (Kepser, 2004; Onder et Bayram, 2006). Pour pouvoir étudier théoriquement et se diriger vers un possible apprentissage, Il est nécessaire d’en introduire des sous classes, moins expressives. L’intérêt d’un arbre de données étant de structurer des informations pour en simplifier la recherche et l’utilisation, il n’est pas surprenant qu’une des fonctions les plus utilisées dans le langage xslt soit la fonction «xsl ∶ value − of » retournant l’ensemble des valeurs textuelles contenues dans les feuilles des sous-arbres traités. Par exemple, comme l’illustre la figure 1, cherchons à récupérer le nom et prénom du premier contact contenu dans un carnet d’adresse sous format xml, pour un futur affichage dans un document html . Cela donne en xslt, l’appel de la balise suivante : 3 contacts contact identite nom Laurence prenom Grégoire adresse ⋯ ⋯ ⋯ ⇒ "Laurence Grégoire" Figure 1 – Exemple de transformation xslt basique Seule la structure de l’arbre importe ici pour décider du traitement à effectuer sur les feuilles. De ce fait, les valeurs textuelles pourraient être abstraites sous la forme de balises dédiées ne servant qu’à les identifier, et permettre leur réutilisation dans la sortie. Toutefois, la structure interne n’est pas toujours suffisante pour décider du traitement à effectuer. Les valeurs textuelles sont parfois des éléments centraux d’une transformation. Les opérations telles que les jointures utilisent ces valeurs textuelles comme repères pour regrouper certaines informations. Dès lors elles font partie intégrante de la sélection des noeuds à manipuler et ne peuvent plus être ignorés. Qu’en est il de la sortie ? Il n’est pas toujours intéressant de garder la structure de l’entrée. Comme l’illustre la transformation représentée dans la figure 1, il est parfois nécessaire de se concentrer sur la concaténation de champs textuels sélectionnés. Même si une structure est parfois nécessaire, il reste tout à fait possible de la représenter sous format xml, une chaîne composée de balises ouvrantes et fermantes représentant un arbre de données. Cette liberté dans la représentation de la sortie se fait au détriment du contrôle de la structure de sortie, qui n’est plus reconnue en tant qu’arbre de données, empêchant ainsi son utilisation directe en entrée d’une autre transformation. Il n’est plus possible dès lors de composer plusieurs transformations sans pré- traitements sur les données intermédiaires. Nous décidons dans cette thèse de nous concentrer sur les transformations d’arbres en mots qui permettent la concaténation dans la sortie. Cela repré- sente une simplification des transformations d’arbres de données à arbres de données. Il est dès lors plus possible d’exprimer les opérations de jointures.4 Introduction Nous perdons également les propriétés de compositions, la structure d’entrée n’étant plus présente dans la production. Cela nous permet de nous concentrer sur la possibilité de manipuler les chaînes de sortie, ce qui nous intéresse ici. Motivation générale Notre but reste l’automatisation de la tâche de transformation. Cela passe par un apprentissage de la transformation que l’on souhaite effectuer. L’apprentissage considéré ici revient à chercher à identifier une cible, appartenant à une classe de langages connue, à partir d’exemples (et de possibles contreexemples). Il nous reste donc à identifier formellement une classe de transformations d’arbres en mots, de choisir le modèle d’apprentissage que nous souhaitons appliquer, et les exemples à partir desquels apprendre. L’apprentissage que nous souhaitons utiliser se base sur l’inférence grammaticale (Gold, 1967) en cherchant à identifier à la limite un langage cohérent avec les exemples d’entrée. Le plus souvent cette technique se divise en deux étapes, une représentation des exemples dans un formalisme les regroupant, et la généralisation de ce modèle pour en déduire un langage reconnaissant souvent un langage plus large que celui représenté par les exemples, mais tout en restant cohérent avec cet échantillon. Pour ce qui est des exemples, la transformation d’arbres en mots peut être vue comme un ensemble de paires composées d’un arbre et de la chaîne de mots résultant de la transformation de cet arbre. Il est connu que, pour apprendre un langage de mots régulier, ne considérer que des exemples positifs n’est pas suffisant en inférence grammaticale (Gold, 1967). Il est nécessaire d’avoir des contre-exemples ou autres éléments permettant d’éviter une surgénéralisation. Qu’en est-il de nos transformations ? Une des propriétés permettant de contrôler cette possible sur-généralisation est le fait qu’une transformation doit rester fonctionnelle. Nous devons pour cela nous assurer qu’une entrée ne puisse être transformée qu’en au plus un résultat. Le deuxième contrôle peut être fait à l’aide du domaine d’entrée, le langage d’arbres sur lequel la transformation peut s’effectuer. Il existe pour cela de nombreuses possibilités, que ce soit à l’aide d’exemples négatifs ou encore par la connaissance directe du domaine, donné en entrée de l’apprentissage. L’apprentissage de langage d’arbres étant un problème connu et ayant déjà été résolu par inférence grammaticale (Oncina et Garcia, 1992), nous opterons pour la deuxième solution, en supposant que le domaine nous est déjà donné. Une fois le type d’exemples et d’apprentissage choisi, il nous reste à choisir quel modèle utiliser pour représenter notre transformation, vérifier que ce mo-5 dèle dispose des propriétés nécessaires pour un apprentissage, et enfin définir l’algorithme d’apprentissage à proprement parler. Nous choisissons d’utiliser les transducteurs, machines à états finis permettant d’évaluer une entrée en produisant la sortie associée. Nous souhaitons donc que toute transformation de la classe qui nous intéresse soit définissable par la classe de transducteurs choisie, ce qu’il reste à prouver. Nous voulons également que la cible d’un apprentissage soit unique, qu’a chaque transformation lui soit associé un transducteur canonique la représentant. Cela repose sur la normalisation du transducteur, pour en homogénéiser le contenu, et de sa minimisation pour assurer l’unicité. Il est donc nécessaire d’introduire une classe de transducteurs permettant de représenter les transformations d’arbres en mots, disposant d’une forme normale. La cible de l’apprentissage d’une transformation sera le transducteur canonique, unique minimal, de cette classe la représentant. Il est donc nécessaire de définir un théorème de type Myhill-Nerode (Nerode, 1958) pour ce modèle, assurant, entre autre, l’existence d’un transducteur canonique pour chaque transformation de notre classe. L’algorithme d’apprentissage en lui même se résume à la décomposition de la transformation représentée par les exemples, pour en déduire les états du transducteur cible. Cela repose sur la possibilité de tester efficacement l’équivalence de fragments de la transformation pour identifier les fragments communs. Il reste à spécifier le modèle de transducteurs à l’aide duquel nous souhaitons modéliser notre transformation. Transducteurs Que ce soit sur les mots ou les arbres, de nombreux modèles de transducteurs ont déjà été proposés et étudiés dans le domaine. Nous nous intéressons particulièrement aux modèles déterministes, ne permettant qu’une exécution possible pour une donnée d’entrée fixée, qui en plus d’assurer la fonctionnalité de la transformation représentée, simplifie la décidabilité de problèmes importants. Avant de nous concentrer sur un modèle permettant de transformer des arbres en mots, nous pouvons évoquer deux classes de transducteurs permettant respectivement de gérer les mots et les arbres. Les transducteurs sous-séquentiels, transducteurs déterministes de mots introduits par Schützenberger (1975), transforment, lettre par lettre un mot d’entrée dans sa sortie. Cette production est obtenue par concaténation de toutes les chaînes produites par le transducteur. Pour ce qui est des arbres, les transducteurs déterministes d’arbres d’arité bornée, basés sur les travaux de Rounds (1968) et Thatcher (1970), permettent, en parcourant un arbre de sa racine à ses feuilles, de produire un arbre. Chaque règle de cet arbre associe6 Introduction à un noeud de l’arbre d’entrée et ses fils, un contexte, arbre à trous. Chacun de ces sous-arbres manquants s’obtient par l’application d’une transduction à un fils de ce noeud. Aucune contrainte n’est faite sur l’ordre d’utilisation de ces fils ou encore du nombre de fois qu’ils sont utilisés. Cela revient à autoriser la copie et le réordonnancement des fils d’un noeud dans la sortie. Il n’est cependant pas possible de fusionner le contenu de plusieurs noeuds ou de supprimer des noeuds internes. Ces classes de transducteurs disposent de résultats de décidabilité sur les problèmes théorique importants. Ainsi, le problème d’équivalence est montré décidable, par Engelfriet et al. (2009) pour les transducteurs d’arbres, et par Choffrut (1979) pour les transducteurs de mots. Une forme normale, assurant à l’aide de contraintes une représentation normalisé d’un transducteur, a été introduite pour chacun d’entre eux, que ce soit par Choffrut (1979) pour les mots ou par Lemay et al. (2010) pour les arbres, afin d’assurer l’existence d’un transducteur canonique, normalisé minimal unique, pour chaque transformation exprimable par un transducteur de la classe. Des algorithmes d’apprentissages ont été proposés pour chacune de ces classes, que ce soit l’algorithme OSTIA (Oncina et al., 1993) pour les transducteurs sous-séquentiels, ou plus récemment sur les transducteurs d’arbres en arbres (Lemay et al., 2010). Pour ce qui est des transformations d’arbres en mots que nous cherchons à représenter, nous nous dirigeons sur une machine proche des transducteurs d’arbres, du moins sur le traitement de l’entrée, mais produisant cette foisci des mots. Les règles produisent maintenant, pour un noeud et ses fils, la concaténation de mots et du résultat de transduction des fils. Les problèmes théoriques, tel que l’équivalence et l’existence de représentants canoniques, sont ouverts pour cette classe de transductions. Il est également possible de pousser vers d’autres modèles de transducteurs plus expressifs tels que les macro transducteurs d’arbres (Engelfriet, 1980), plus proche des transformations de type XSLT que les modèles évoqués pré- cédemment. Mais ce modèle autorisant également des opérations telles que la concaténation, il n’est pas intéressant d’attaquer cette classe alors que des classes strictement moins expressives, et utilisant le même type d’opérateurs, n’ont toujours pas de résultats de décidabilité sur les problèmes théoriques. Maintenant que nous avons décidé du type de transformation qui nous intéresse, d’arbres en mots, ainsi que la manière de les représenter, transducteurs déterministes d’arbres en mots, nous pouvons nous concentrer sur l’apprentissage en lui-même.7 Contributions Dans cette thèse, nous définissons et étudions les transducteurs séquentiels déterministes descendants d’arbres d’arité bornée en mots. Être séquentiel signifie que chaque règle de ces transducteurs associe à un noeud une production obtenue par concaténation de mots et de l’application d’une transduction sur chacun de ces fils. Chaque fils doit être utilisé une et une seule fois, et ce dans leur ordre d’apparition dans l’entrée. Les règles d’un transducteur séquentiel sont de la forme : ⟨q, f(x1, . . . , xk)⟩ → u0 ⋅ ⟨q1, x1⟩ ⋅ . . .⟨qk, xk⟩uk qui spécifie que la transformation d’un arbre f(t1, . . . , tk) à partir d’un état q sera le résultat de la concaténation des chaînes ui et des résultats de transduction des sous arbres ti à partir des états qi respectifs. Le fait d’interdire la réutilisation et le réordonnancement des fils dans la production de la sortie est une simplification du modèle assez conséquente. Mais comme nous le verrons par la suite, cette restriction est nécessaire pour décider efficacement de problèmes théoriques cruciaux dans l’élaboration d’un apprentissage. Le problème d’équivalence de ce modèle est par exemple connu décidable pour la famille plus générale de transduction. Toute fois, il ne permet pas de disposer d’une solution efficace. Équivalence efficace En réduisant le problème d’équivalence à celui de l’équivalence de morphismes appliqués à des grammaires algébriques, prouvé décidable en temps polynomial dans la taille des morphismes et de la grammaire (Plandowski, 1995), nous prouvons que l’équivalence des transducteurs séquentiels est décidable également en temps polynomial dans la taille du transducteur considéré. Cette réduction se base sur la définition d’une grammaire représentant l’exécution parallèle de transducteurs séquentiels sur lesquels sont définis deux morphismes recomposant la sortie de transducteurs séquentiels respectifs. Toute la sortie est contenue dans les règles représentées sur cette exécution. Malgré des expressivités foncièrement différentes, les transducteurs d’arbres en mots ascendants, descendants, et les transducteurs de mots imbriqués en mots partagent des représentations d’exécutions similaires, l’ordre de l’entrée y étant toujours gardé. Cette similarité permet de mettre en relations ces principales classes de transductions d’arbres en mots en étendant le résultat de décidabilité de l’équivalence à chacune d’entre elles (Staworko et al., 2009).8 Introduction Normalisation Par la suite (Laurence et al., 2011), nous introduisons une forme normale pour les transducteurs séquentiels d’arbres en mots, cherchant à produire la sortie le plus tôt possible dans le transducteur. Cette notion de «plus tôt» pouvant être perçue de plusieurs manières nous allons l’illustrer à l’aide d’un court exemple. Exemple 1. Prenons un transducteur séquentiel M composé de deux états q0 et q1, de l’axiome initial permettant de produire de la sortie avant même de commencer la lecture d’un arbre entrée q0, n’ajoutant ici aucune sortie, et des règles suivantes. ⟨q0, f(x1, x2)⟩ → ⟨q1, x1⟩ ⋅ ac ⋅ ⟨q1, x2⟩, ⟨q1, g(x1)⟩ → ⟨q1, x1⟩ ⋅ abc, ⟨q1, a⟩ → ε. Nous pouvons représenter son exécution par l’annotation de l’arbre transformé, la sortie s’obtenant par la concaténation des mots produits en suivant le parcours en profondeur, comme l’illustre le premier arbre de la figure 2. f g g a g a ac ε ε ε abc ε ε abc ε abc ε f g g a g a ε a c bca ε ε cab ε cab ε ε Figure 2 – Exemple d’exécution d’un transducteur séquentiel et sa version normalisée Nous choisissons comme normalisation de débuter par la sortie la production le plus haut possible dans l’arbre. Par exemple, si l’arbre à pour racine f, nous savons directement que sa sortie débutera par un “a” et se terminera par un “c”. Il nous faut donc remonter ces deux lettres, respectivement à gauche et à droite, en les faisant passer à travers la transduction des sous arbres. Une fois que la sortie se trouve le plus haut possible, pour assurer un seul résultat pour la normalisation d’un arbre, nous avons décider de forcer la sortie à être9 produite le plus à gauche d’une règle, comme l’illustre le passage de droite à gauche des productions sur les noeuds étiquetés par un g. Cela donne le transducteur suivant. L’état q1 a été divisé en deux états qg et qd, le traitement du sous arbre gauche et droit étant maintenant différents. Les règles du transducteur obtenu sont les suivantes : ⟨q0, f(x1, x2)⟩ → ⟨qg, x1⟩ ⋅ ac ⋅ ⟨qd, x2⟩, ⟨qg, g(x1)⟩ → bca ⋅ ⟨qg, x1⟩, ⟨qg, a⟩ → ε, ⟨qd, g(x1)⟩ → cab ⋅ ⟨qd, x1⟩, ⟨qd, a⟩ → ε. L’exécution de ce transducteur est illustré sur le deuxième arbre de la figure 2. Nous définissons un algorithme de normalisation permettant à partir de tout transducteur séquentiel de le renvoyer sous forme normalisée. La difficulté de cette normalisation est la manipulation de la sortie, les mots devant à la fois être tirés à gauche et droite du transducteur et parfois poussés à travers la transduction de sous arbres, comme l’illustre l’exemple. Si on se limite à la sortie, cette opération revient à manipuler des mots à travers des grammaires algébriques de mots, projection du transducteur sur la sortie. La force de notre normalisation est, qu’a partir de contraintes globales devant s’appliquer les unes après les autres, nous avons réussi à en déduire des contraintes locales. En arrivant à représenter ces modifications à l’aide d’un langage d’opérations sur les mots, pouvant être directement appliquées aux états d’un transducteur, nous avons mis en place une normalisation efficace et locale d’un transducteur séquentiel d’arbres en mots. Nous identifions également les bornes sur la taille d’un transducteur sé- quentiel normalisé en fonction de la taille du transducteur de base, pouvant parfois atteindre une taille double exponentielle dans celle de la source. Apprentissage Nous aboutissons, en nous basant sur les précédents résultats, sur l’apprentissage des transducteurs séquentiels d’arbres en mots (Laurence et al., 2014). Pour cela, il faut tout d’abord identifier les transformations apprenables (i.e. représentables par des transducteurs séquentiels). Pour cela, on cherche à retrouver directement la structure des transducteurs dans une transformation. Cette restructuration passe par la décomposition de la sortie par rapport à l’entrée, l’introduction de sous transformations associées aux chemins de l’arbre d’entrée, ainsi que l’instauration de classes d’équivalence regroupant ces résiduels. À partir de cela, nous pouvons introduire des propriétés sur les transformations assurant une représentation possible sous la forme d’un transducteur séquentiel, puis prouver ces résultats par l’adaptation du théorème de Myhill-Nerode à notre classe de transduction.10 Introduction Il reste à adapter cette même approche pour l’apprentissage, non plus à partir d’une transformation complète en notre possession, mais à partir d’un échantillon d’exemples et d’un automate représentant son domaine. Nous limitant au modèle séquentiel, toute transformation et tout échantillon d’exemples n’est pas représentable par un transducteur séquentiel. Notre algorithme doit pouvoir échouer si les exemples ne peuvent être représentés par un transducteur séquentiel. En adaptant chaque étape, de la décomposition à l’identifi- cation des classes d’équivalences, l’algorithme s’assure en temps polynomial de l’existence d’un transducteur séquentiel cohérent avec l’entrée, et produit le transducteur canonique correspondant, ou le cas échéant échoue. À l’aide de la notion d’échantillon caractéristique, nous prouvons cependant que cet algorithme n’échoue pas dans les cas où l’entrée est suffisante pour aboutir à un transducteur cible représenté par cet échantillon. Plan de thèse Après avoir rappelé les différentes notions nécessaires à la compréhension de cette thèse, nous rappellerons également les différents modèles d’automates permettant de reconnaître des langages d’arbres, ces modèles étant la base des transducteurs qui nous intéressent. Nous y présenterons également les diffé- rents résultats tels que la décidabilité de l’équivalence ou encore l’apprentissage, ce qui nous permettra à travers des modèles plus simples d’illustrer les approches que nous appliquerons par la suite sur les transducteurs. Le deuxième chapitre nous permettra, à travers un survol des différentes classes de transductions existantes, de montrer les différents résultats existant dans le domaine, et où se placent les modèles que nous étudieront dans cet ensemble. Nous profiterons du troisième chapitre pour montrer une des facettes pratiques de la transformation à travers le langage xslt, qui permet de représenter et effectuer la transformation de fichiers xml sous différents formats. Les trois derniers chapitres présenteront les contributions de cette thèse. Le premier chapitre se concentre sur le problème d’équivalence, en améliorant la décidabilité pour les transducteurs d’arbres en mots. La réduction qui y est introduite permettra également d’apporter un autre regard sur les différentes classes de transductions d’arbres en mots évoquées. Les deux derniers chapitres présenteront les résultats centraux de cette thèse, à savoir la normalisation, minimisation et l’apprentissage des transducteurs séquentiels.Chapitre 1 Automates Avant de pouvoir parler de transducteurs, il est indispensable de poser les bases sur lesquelles ils se construisent. Après avoir défini formellement les différents modèles de données manipulés dans cette thèse, nous nous attarderons sur les automates, structure de base à partir desquelles les transducteurs sont définis. Pour cela, nous partirons des automates de mots, pour ensuite survoler les différents types d’automates permettant la manipulations d’arbres. 1.1 Mots 1.1.1 Mots et langages Un alphabet est un ensemble fini et non vide de symboles. La taille d’un alphabet Σ est le nombre de symboles qu’il contient, noté ∣Σ∣. Un mot est une séquence possiblement vide de symboles appartenant à un alphabet Σ. On représente par ε le mot vide. L’étoile de Kleene est la clôture réflexive et transitive d’un langage, noté Σ∗ pour l’alphabet Σ. Σ∗ est l’ensemble de tout les mots définissable à partir de l’alphabet Σ. On note u1 ⋅ u2 la concaténation de deux mots u1 et u2. La taille d’un mot u est le nombre de symboles qui le compose, noté ∣u∣. Les mots sont liés entre eux par une relation d’ordre totale . HAL Id: tel-00987630 https://tel.archives-ouvertes.fr/tel-00987630 Submitted on 6 May 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Th`ese de Doctorat Universit´e Pierre et Marie Curie – Paris 6 Sp´ecialit´e SYSTEMES ` INFORMATIQUES pr´esent´ee par Mme. Nada SBIHI pour obtenir le grade de Docteur de l’universit´e Pierre et Marie Curie – Paris 6 Gestion du trafic dans les r´eseaux orient´es contenus Jury James ROBERTS Directeur de th`ese Chercheur, INRIA et SystemX Serge FDIDA Directeur de th`ese Professeur, UPMC Sorbonne universit´es – Paris 6 Leila SAIDANE Rapporteur Professeur, ENSI–Tunisie Walid DABBOUS Rapporteur Chercheur, INRIA Sophia Antipolis Sebastien TIXEUIL Examinateur Professeur, UPMC Sorbonne universit´es – Paris 6 Diego PERINO Examinateur Chercheur, Bell Labs–Alcatel-Lucent Gwendal SIMON Examinateur Maˆıtre de conf´erence, Telecom BretagneRemerciements Je tiens tout particuli`erement `a remercier mon encadrant de th`ese M. Jim Roberts de m’avoir donn´e la chance de poursuivre mes ´etudes. Son suivi et ses pr´ecieux conseils m’ont apport´es beaucoup d’aide durant ma th`ese. Son experience est une source in´epuisable dont j’ai pu apprendre grˆace `a son encadrement et sa g´en´erosit´e. Je remercie ´egalement M.Serge Fdida d’avoir accept´e de diriger ma th`ese ainsi que Mme. Leila Saidane et Mr. Walid Dabbous mes rapporteurs, pour leurs remarques et suggestions sur la version pr´eliminaire de ce document. Je suis reconnaissante `a M.S´ebastien Tixeuil, M. Diego Perino et M. Gwendal Simon pour avoir accept´e de m’honorer de leur participation au jury de cette th`ese. Je tiens `a remercier M. Philippe Robert de m’avoir acceuilli au sein de l’´equipe R´eseaux, algorithmes et Probabilit´es(RAP) `a l’INRIA. Je suis tr`es reconnaissante `a Mme. Christine Fricker pour son aide, sa g´en´erosit´e et sa gentillesse. Ton savoir scientifique, ta p´edagogie et ta modestie m’ont donn´e beaucoup d’espoirs. Je remercie ´egalement les anciens et nouveaux membres de l’´equipe Rap et particuli`erement Virginie Collette. Un grand merci `a mes parents pour leur encouragement et Otmane, mon ´epoux pour son soutien, petit clin d’oeil particulier `a mon fils Amine. Merci `a ma famille, amies, et coll´egues. 3Resum ´ e´ Les r´eseaux orient´es contenus (CCN) ont ´et´e cr´e´es afin d’optimiser les ressources r´eseau et assurer une plus grande s´ecurit´e. Le design et l’impl´ementation de cette architecture est encore `a ces d´ebuts. Ce travail de th`ese pr´esente des propositions pour la gestion de trafic dans les r´eseaux du future. Il est n´ecessaire d’ajouter des m´ecanismes de contrˆole concernant le partage de la bande passante entre flots. Le contrˆole de trafic est n´ecessaire pour assurer un temps de latence faible pour les flux de streaming vid´eo ou audio, et pour partager ´equitablement la bande passante entre flux ´elastiques. Nous proposons un m´ecanisme d’Interest Discard pour les r´eseaux CCN afin d ?optimiser l’utilisation de la bande passante. Les CCN favorisant l’utilisation de plusieurs sources pour t´el´echarger un contenu, nous ´etudions les performances des Multipaths/ Multisources ; on remarque alors que leurs performances d´ependent des performances de caches. Dans la deuxi`eme partie de cette th`ese, nous ´evaluons les performances de caches en utilisant une approximation simple et pr´ecise pour les caches LRU. Les performances des caches d´ependent fortement de la popularit´e des objets et de la taille des catalogues. Ainsi, Nous avons ´evalu´e les performances des caches en utilisant des popularit´es et des catalogues repr´esentant les donn´ees r´eelles ´echang´ees sur Internet. Aussi, nous avons observ´e que les tailles de caches doivent ˆetre tr`es grandes pour assurer une r´eduction significative de la bande passante ; ce qui pourrait ˆetre contraignant pour l’impl´ementation des caches dans les routeurs. Nous pensons que la distribution des caches devrait r´epondre `a un compromis bande passante/m´emoire ; la distribution adopt´ee devrait r´ealiser un coˆut minimum. Pour ce faire, nous ´evaluons les diff´erences de coˆut entre architectures. 4Abstract Content Centric Network (CCN) architecture has been designed to optimize network resources and ensure greater security. The design and the implementation of this architecture are only in its beginning. This work has made some proposals in traffic management related to the internet of the future. We argue that it is necessary to supplement CCN with mechanisms enabling controlled sharing of network bandwidth by competitive flows. Traf- fic control is necessary to ensure low latency for conversational and streaming flows, and to realize satisfactory bandwidth sharing between elastic flows. These objectives can be realized using ”per-flow bandwidth sharing”. As the bandwidth sharing algorithms in the IP architecture are not completely satisfactory, we proposed the Interest Discard as a new technique for CCN. We tested some of the mechanisms using CCNx prototype software and simulations. In evaluating the performance of multi-paths we noted the role of cache performance in the choice of selected paths. In the second part, we evaluate the performance of caches using a simple approximation for LRU cache performance that proves highly accurate. As caches performance heavily depends on populations and catalogs sizes, we evaluate their performance using popularity and catalogs representing the current Internet exchanges. Considering alpha values, we observe that the cache size should be very large ; which can be restrictive for caches implementation in routers. We believe that the distribution of caches on an architecture creates an excessive bandwidth consumption. Then, it is important to determine a tradeoff bandwidth/memory to determine how we should size caches and where we should place them ; this amounts to evaluate differences, in cost, between architectures. 5Table des matieres ` Introduction g´en´erale 10 I La gestion du trafic dans les r´eseaux orient´es contenus 16 1 Introduction 17 1.1 Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.1 Contrˆole du trafic au coeur du r´eseau . . . . . . . . . . . . . . . . . 18 1.2.2 Protocole de transport . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.2.3 Multipath et multisource . . . . . . . . . . . . . . . . . . . . . . . . 19 2 Partage de bande passante 21 2.1 Identification des flots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Caches et files d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 Le principe du flow aware networking . . . . . . . . . . . . . . . . . . . . . 23 2.3.1 Partage des ressources dans les CCN . . . . . . . . . . . . . . . . . . 23 2.3.2 Contrˆole de surcharge . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3 M´ecanismes pour CCN 26 3.1 M´ecanismes pour les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.1 D´etection des rejets . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2 Protocole de transport . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2 M´ecanismes pour op´erateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.1 Motivation ´economique . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.2 Interest Discard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4 Strat´egies d’acheminement 31 4.1 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.2 Multisources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.1 Protocole de transport Multipath . . . . . . . . . . . . . . . . . . . . 32 64.2.2 Performance de MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.3 CCN et routage multipath . . . . . . . . . . . . . . . . . . . . . . . . 38 4.2.4 Performances des multipaths . . . . . . . . . . . . . . . . . . . . . . 38 5 Simulations et exp´erimentations 42 5.1 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2 Exp´erimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.1 Fair sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2.2 Interest discard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.2.3 Sc´enarios et r´esultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6 Conclusion 46 II Performances des caches 48 7 Introduction 49 7.1 Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.2 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 8 Mesure du trafic et performances des caches 51 8.1 Mesure du trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1.1 Types de contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1.2 La taille des contenus et des objets . . . . . . . . . . . . . . . . . . . 52 8.1.3 Distribution de la popularit´e . . . . . . . . . . . . . . . . . . . . . . 53 8.2 Le taux de hit d’un cache LRU . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.2.1 Independent Reference Model . . . . . . . . . . . . . . . . . . . . . . 54 8.2.2 Les mod`eles analytiques . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.2.3 La formule de Che . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.3 Autres politiques de remplacement . . . . . . . . . . . . . . . . . . . . . . . 57 8.3.1 Le cache Random . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.3.1.1 Relation entre taux de hit et temps moyen de s´ejour . . . . 57 8.3.1.2 Approximation de Fricker . . . . . . . . . . . . . . . . . . . 59 8.3.1.3 Approximation de Gallo . . . . . . . . . . . . . . . . . . . . 60 8.3.2 Le cache LFU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8.3.3 Comparaison des politiques de remplacement . . . . . . . . . . . . . 63 9 Les performances des hi´erarchies de caches 64 9.1 Caract´eristiques d’une hi´erarchie de caches . . . . . . . . . . . . . . . . . . 64 9.1.1 Politique de remplacement . . . . . . . . . . . . . . . . . . . . . . . . 64 9.1.2 Les politiques de meta-caching . . . . . . . . . . . . . . . . . . . . . 65 9.1.3 Les politiques de forwarding . . . . . . . . . . . . . . . . . . . . . . . 67 9.2 Performances des hi´erarchies de caches . . . . . . . . . . . . . . . . . . . . . 69 9.2.1 G´en´eralisation de la formule de Che . . . . . . . . . . . . . . . . . . 699.2.2 Cas d’application : hi´erarchie de caches avec mix de flux . . . . . . . 72 10 Conclusion 76 III Coˆuts d’une hi´erarchie de caches 77 11 Introduction 78 11.1 Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 11.2 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 12 Coˆut d’une hi´erarchie de caches `a deux niveaux 82 12.1 Diff´erence des coˆuts entre structures . . . . . . . . . . . . . . . . . . . . . . 83 12.2 Estimation num´erique des coˆuts . . . . . . . . . . . . . . . . . . . . . . . . . 84 12.2.1 Coˆut normalis´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 12.2.2 Solution optimale en fonction du taux de hit global . . . . . . . . . . 87 12.3 Exemple : coˆuts des torrents . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 13 Coop´eration de caches 90 13.1 Load sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 13.2 Caches coop´eratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 13.3 Routage orient´e contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 14 Hi´erarchies alternatives 99 14.1 Coˆut d’une hi´erarchie de caches `a plusieurs niveaux . . . . . . . . . . . . . . 99 14.1.1 Evaluation des coˆuts . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 14.1.2 Coop´eration de caches . . . . . . . . . . . . . . . . . . . . . . . . . . 101 14.2 Coˆuts et politiques de remplacement . . . . . . . . . . . . . . . . . . . . . . 102 14.2.1 Politique LFU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 14.2.2 Politique Random . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 15 Conclusion 107 Conclusion g´en´erale 108Introduction gen´ erale ´ Les r´eseaux orient´es contenus L’id´ee de passer d’un r´eseau `a connexion point `a point `a un r´eseau orient´e contenu date de plus d’une d´ecennie. En effet le projet TRIAD 1 proposait d´ej`a une architecture ICN. Cependant, peu de travaux ont ´et´e construits sur la base de ce projet, sans doute parce que les contenus `a cette ´epoque n’avaient pas le mˆeme poids ´enorme qu’ils prennent actuellement dans le trafic Internet. Quelques ann´ees apr`es, d’autres propositions commencent `a ´eclairer la recherche dans le domaine des r´eseaux orient´es contenu. DONA, une architecture orient´ee donn´ees a ´et´e propos´ee en 2007 par Koponen et al. [1]. Elle se base sur l’utilisation de noms autocertifi´es et incorpore des fonctionnalit´es de caching. Plus r´ecemment l’architecture CCN a attir´e l’attention de la communaut´e scienti- fique, alert´ee par la croissance ´enorme du trafic de distribution de contenus et le succ`es des CDNs proposant des services payants aux fournisseurs de contenus. Les CDNs utilisent d’une mani`ere intelligente les chemins menant aux contenus et implantent des caches partout dans le monde afin d’acc´el´erer les t´el´echargements. Akamai reste le leader mondiale dans ce domaine. Les op´erateurs ne peuvent pas rester passifs dans cet univers des contenus et sont oblig´es d’envisager une mise `a niveau de l’Internet afin de r´eduire les coˆuts engendr´es par l’augmentation rapide du trafic de contenus, notamment de vid´eos. L’architecture CCN vient au bon moment et suscite beaucoup d’int´erˆet de la communaut´e scientifique, d’autant plus que celui qui propose cette architecture n’est autre que Van Jacobson tr`es connu pour des contributions marquantes au d´eveloppement d’IP [2]. Plusieurs autres projets d’architecture orient´ee contenu ont ´et´e propos´ees dont 4WARD/SAIL [3] et PSIRP/PURSUIT [4]. Ghodsi et al. [5] ont compar´e les diff´erentes propositions de r´eseaux ICN et ont dress´e les points de divergences et les points communs entre ces architectures. Ils d´eplorent aussi le peu de remise en question de l’utilisation des ICN en comparaison avec une solution d’´evolution des CDNs. Les architectures ICN pr´esentent plusieurs points communs de design. Les ´echanges sur ces architecture sont bas´es sur le mod`ele publish/subsribe, le nom de l’objet est publi´e, un objet est demand´e par l’envoi de paquet Interest. Les caches ICN sont utilis´es pour tout 1http ://gregorio.stanford.edu/triad/ 1011 type de donn´ees et protocole. Ils sont ouverts `a tout utilisateur qui peut ainsi d´eposer ses propres contenus dans les caches. Tous les noeuds du r´eseau utilisent un cache localis´e au niveau routeur et les contenus sont s´ecuris´es ind´ependamment de leur emplacement. C’est le serveur d’origine qui signe les contenus, et les utilisateurs peuvent v´erifier les contenus grˆace `a leur signature publique. Les architectures diff`erent dans certains points. Certains designs proposent la s´ecurisation des contenus avec un m´ecanisme d’auto-certification. Dans ce cas, les contenus portent des noms qui n’ont pas de signification ´evidente pour l’homme (un code `a plusieurs caract`eres par exemple). La s´ecurit´e des contenus est assur´ee par la signature des objets. L’utilisateur peut v´erifier l’authenticit´e de l’objet en validant sa signature au moyen d’une clef publique r´ecup´er´ee grˆace aux PKI. Le routage orient´e contenus est aussi un point de divergence entre architectures, certaines architectures pr´econisent le routage orient´e contenus bas´e sur BGP alors que d’autres proposent leur propre mod`ele de routage. Dans tous les cas, ce domaine reste encore mal explor´e et pose des probl`emes s´erieux de passage `a l’´echelle. CCN Van Jacobson propose la nouvelle architecture d’Internet orient´ee contenu nomm´ee CCN (Content-centric networking) [2]. Cette architecture permettrait une recherche directe d’un contenu sans avoir `a identifier son d´etenteur, comme dans le cas des r´eseaux IP. En effet, dans les r´eseaux IP les donn´ees sont recherch´ees par leur localisation et non pas par leur nom. Un utilisateur cherchant une donn´ee doit avoir une information sur l’adresse IP de la machine contenant cette information pour pouvoir la r´ecup´erer. Ce fonctionnement pose plusieurs probl`emes de s´ecurit´e, de disponibilit´e et de complexit´e des processus de r´ecup´eration de donn´ees. L’architecture CCN a pour objectif de simplifier les processus de recherche. Un utilisateur cherche une donn´ee `a travers son nom. D´es lors que la requˆete est lanc´ee, une demande sous forme d’un paquet dit “Interest” est envoy´ee `a son routeur d’acc`es. Si la donn´ee n’est pas pr´esente dans le content store de ce routeur, la requˆete se propage au fur et `a mesure dans le r´eseau. Une fois la donn´ee trouv´ee, elle suit le chemin inverse de la requˆete de recherche jusqu’`a l’utilisateur final et sera stock´ee dans un “Content Store” dans les routeurs CCN interm´ediaires. Cette architecture offre plusieurs possibilit´es de disponibilit´e ind´ependamment de l’adresse d’une machine. La s´ecurit´e est associ´ee directement aux donn´ees et pas aux “conteneurs” ( liens, routeurs, serveurs,...) ce qui permet d’ajuster de mani`ere tr`es flexible le niveau de s´ecurit´e `a la nature du contenu en question. Plus int´eressant encore, les contenus ne sont plus associ´es `a des conteneurs pr´ecis mais peuvent ˆetre dupliqu´es `a volont´e et stock´es notamment dans des m´emoires caches au sein du r´eseau. Les contenus sont divis´es en “chunks”, chaque chunk ayant typiquement la taille d’un paquet IP. CCN respecte le d´eroulement logique d’une requˆete : un utilisateur demande une donn´ee en ´emettant des paquets de type “Interest” et re¸coit en retour des paquets de donn´ees de type “Data”. A chaque paquet Interest correspond un seul paquet Data et12 B Provider P1 S2 Interests U2 S1 of Data U1 Provider P2 A C source emitter of Figure 1 – Un segment du r´eseau CCN reliant un utilisateur U1 `a une source S1 chaque paquet Data correspond `a un Chunk. La figure 1 repr´esente un segment d’un r´eseau CCN. Pour r´ecup´erer des donn´ees du fournisseur P2, l’usager U1 envoie des paquets “Interest” pour le contenu demand´e au travers des routeurs A et B. Supposant que les Content Stores de A et B ne contiennent pas le document demand´e, les paquets Data suivent le chemin inverse de S1 vers U1 en passant par B et A. Pour g´erer l’envoi des donn´ees, trois types de m´emoires sont utilis´ees au niveau de chaque noeud : • Content Store : Dans cette base de donn´ees sont stock´es des objets physiquement. • Pending Interest Table (PIT) : Dans cette table sont stock´es les noms des donn´ees et les interfaces demandeuses correspondantes. • FIB : par analogie avec IP, le FIB dans CCN stocke les pr´efixes des noms des donn´ees ainsi que les prochaines interfaces `a emprunter pour arriver `a la donn´ee. Cette table est enrichie `a travers les d´eclarations de d´etention de donn´ees par les noeuds du r´eseau. Dans CCN il n’y a nul besoin d’acheminer les adresses source et destination `a travers le r´eseau pour r´ecup´erer la donn´ee. Le format des paquets Interests et Data est explicit´e `a la figure 2. Selector Nonce Content Name Signature Content Name Signed Info Data Interest Packet Data Packet Figure 2 – Format des paquets CCN13 A la r´eception d’un Interest par un noeud, ce dernier v´erifie si le chunk demand´e existe dans son Content Store. Si c’est le cas, le paquet Data sera envoy´e `a l’interface demandeuse. Sinon le chunk demand´e sera recherch´e dans le PIT. S’il est trouv´e, l’interface demandeuse sera rajout´ee au PIT. Si les deux bases de donn´ees ne fournissent aucune information, on cherchera dans le FIB si une entr´ee matche avec le chunk recherch´e. Alors le paquet Interest sera achemin´e vers les interfaces conduisantes `a la donn´ee. La table PIT sera mise `a jour avec une nouvelle entr´ee pour le chunk en question. A la r´eception d’un paquet Data par un noeud, une recherche est effectu´ee dans le Content Store. Si une entr´ee matche, alors le paquet re¸cu est supprim´e, car ceci implique que le chunk est d´ej`a livr´e `a toutes les interfaces demandeuses. Sinon la donn´ee sera recherch´ee dans le PIT. Si une entr´ee matche avec la donn´ee re¸cue, elle sera achemin´ee vers les interfaces demandeuses. Le chunk sera typiquement stock´e en mˆeme temps dans le Content Store. image video 1,0 1 video ...... ...... file 0 0 0 0 video fichier 3 2 1 image video 1 2 image data ...... A ....... C Interest[video] FIB(A) Content Store(C) Interest[image] Interest[video] B D FIB(B) PIT(B) Interest[image] Content Store(D) Figure 3 – La recherche des donn´ees dans CCN Dans l’exemple de la figure 3, le noeud A cherche les chunks “video” et “image”. Le FIB du noeud A indique que les paquets Interests doivent ˆetre achemin´es vers l’interface 0 et 1 pour l’image, et vers l’interface 1 pour la vid´eo. A la r´eception de l’Interest demandant la vid´eo par le noeud B, ce dernier ignore l’Interest re¸cu car le PIT contient d´ej`a une entr´ee. Cette entr´ee est mise `a jour. Cependant, quand le noeud B re¸coit l’Interest demandant l’image, il l’envoie `a l’interface 1 indiqu´ee par le FIB. Le noeud D, par la suite, achemine la donn´ee vers le noeud A. Cette donn´ee sera stock´ee dans tous les Content Stores des noeuds l’ayant re¸cu ou transit´e. Le s´equencement des paquets est ´etabli grˆace aux noms des chunks. Ces derniers sont organis´es d’une fa¸con hi´erarchique. Ainsi, pour demander un segment il faut indiquer le14 nom hi´erarchique du chunk demand´e dans le paquet Interest. Le FIB d´etermine l’interface de sortie ad´equate grˆace `a un algorithme “longest prefixe match”. La gestion du trafic La gestion du trafic consiste `a contrˆoler le partage de la bande passante des liens afin d’assurer la qualit´e de service des diverses applications. Le partage ´equitable de la bande passante entre flots r´epond aux exigences des flux sensibles `a d´ebit faible et prot`ege les flux adaptatifs des flux gourmands. La gestion du trafic dans les r´eseaux IP a fait l’objet de plusieurs travaux de recherches, mais jusqu’`a pr´esent aucune solution enti`erement satisfaisante n’a ´et´e trouv´ee. Jacobson et al. proposent un mod`ele CCN bas´e sur un ´echange Interest/Data : pour recevoir un paquet Data, l’utilisateur devrait envoyer un paquet Interest. Ils assurent que ce m´ecanisme r´ealise une bonne gestion de trafic. Ceci est insuffisant en r´ealit´e. Tous les utilisateurs n’utilisent pas un protocole de transport unique ; ce dernier peut ˆetre modifi´e par l’utilisateur final. Il est alors n´ecessaire de d´efinir des m´ecanismes pour g´erer le partage de la bande passante. La d´etection de rejets par num´eros de s´equences des paquets n’est plus applicable sur CCN ; l’utilisation des multipaths et multichemins change l’ordre des paquets, et le timeout ne suffit pas pour assurer de bonnes performances du protocole de transport. D’autre part, dans CCN, l’utilisateur ne peut plus utiliser un protocole de transport multipath car il ignore les destinations possibles de ces paquets. En plus des diff´erences entre CCN et IP en termes de mod`ele d’´echange de donn´ees, les CCN impl´ementent des caches au niveau de chaque routeur. Ainsi, l’utilisation des caches r´eduit la consommation de bande passante, et les d´elais de transmission. Contributions de la th`ese Le rapport est structur´e comme suit : • Gestion du trafic dans les r´eseaux orient´es contenus : Nous proposons des m´ecanismes pour g´erer les flots dans CCN, en identifiant les flots par le nom d’objet, et en adaptant le Fair queuing `a CCN. Nous proposons un m´ecanisme Interest Discard pour prot´eger les op´erateurs des rejets de Data, un nouveau mod`ele de tarification, une d´etection rapide des rejets pour contrˆoler les fenˆetres des protocoles de transport, et nous ´evaluons les performances des Multipaths. Nous ´evaluons les m´ecanismes propos´es par simulation et exp´erimentation. • Performance des caches : Nous ´evaluons les types des contenus, leur taille, et leur loi de popularit´e. Nous utilisons la formule de Che comme mod`ele analytique fiable pour mesurer les taux de hit des caches LRU, nous adaptons cette formule au cas Random,15 nous ´evaluons le taux de hit d’une hi´erarchie `a deux niveaux, et nous proposons une diff´erentiation de stockage de donn´ees pour am´eliorer la probabilit´e de hit. • Coˆuts des hi´erarchies de caches : Nous cherchons un optimum pour un tradeoff bande passante/m´emoire, nous effectuons une estimation des couts, nous appliquons les calculs `a un cas r´eel de donn´ees de type torrents et nous comparons les performances d’une hi´erarchie coop´erative et non-coop´erative. Le travail de th`ese a contribu´e `a la r´edaction des articles suivants : • S. Oueslati, J. Roberts, and N. Sbihi, Flow-Aware traffic control for a content-centric network, in Proc of IEEE Infocom 2012. • C. Fricker, P. Robert, J. Roberts, and N. Sbihi, Impact of traffic mix on caching performance in a content-centric network, in IEEE NOMEN 2012, Workshop on Emerging Design Choices in Name-Oriented Networking • J. Roberts, N. Sbihi, Exploring the Memory-Bandwidth Tradeoff in an InformationCentric Network, International Teletraffic Congress, ITC 25, Shanghai, 2013.Premi`ere partie La gestion du trafic dans les r´eseaux orient´es contenus 16Chapitre 1 Introduction 1.1 Probl´ematique Jacobson et al [2] remettent en cause l’architecture TCP/IP en constatant qu’il est n´ecessaire de mettre en place une nouvelle architecture Internet r´epondant mieux `a la croissance exponentielle de la demande pour des contenus de tous types. Con¸cu au d´ebut pour des ´echanges simples, l’Internet devient en effet le moyen incontournable pour consulter les sites du Web, ´echanger vid´eos et audios, et partager des fichiers. Son utilisation ayant ´evolu´e, son architecture devrait suivre. Plusieurs projets sont consacr´es `a la conception du r´eseau du futur. La proposition CCN de Jacobson et al. [2] est une des plus cr´edibles et a fait l’object de nombreuses ´etudes. Nous avons constat´e cependant que la d´efinition de cette nouvelle architecture reste incompl`ete, notamment en ce qui concerne la gestion du trafic. L’objet de la pr´esente partie du rapport est de d´ecrire nos ´etudes sur cette question. Le contrˆole de trafic est essentiel afin d’assurer aux flots audios et vid´eos des d´elais faibles mˆeme quand ils partagent la bande passante avec des flots de donn´ees `a haut d´ebit. Il importe ´egalement d’empˆecher d’´eventuels “flots gourmands” d’alt´erer la qualit´e des autres flots en s’accaparant une part excessive de la bande passante des liens qu’ils partagent. Nous pouvons diviser les axes de recherches concernant la gestion du trafic en 3 volets : • Le partage de bande passante. Dans CCN comment faut il partager la bande passante entre flots et comment identifier un flot quand les adresses IP ne sont plus utilis´ees dans les paquets ? Comment exploiter la particularit´e des r´eseaux CCN, dite de “flow balance”, o`u les paquets Data suivent exactement le chemin inverse des paquets Interest. • Le protocole de transport. La conception d’un protocole de transport sous CCN est plus compliqu´e qu’en IP. En effet, nous ne pouvons plus prendre en compte la succession des num´eros de s´equence des paquets comme garantie de non congestion, car, sous CCN mˆeme sans congestion les paquets ne se suivent pas forc´ement. Un flot ne 1718 1.2. ETAT DE L’ART se dirige pas vers une destination particuli`ere et unique. Les paquets Data peuvent venir de n’importe quelle source de donn´ees, y compris des caches, et peuvent suivre des chemins diff´erents. • Multipath et multisource. Sous CCN le t´el´echargement des objets de sources multiples devient une opportunit´e int´eressante pour augmenter les d´ebits. Cette multiplicit´e a l’avantage de pouvoir am´eliorer les d´ebits de t´el´echargment. Cependant, il y a ´egalement un inconv´enient car, les paquets empruntant plusieurs chemins diff´erents, l’opportunit´e d’exploiter les caches devient plus faible. 1.2 Etat de l’art Lorsque nous avons fait les ´etudes pr´esent´ees dans cette partie, `a partir du Chapitre 2, il n’y avait pas de publications qui abordaient les questions mentionn´ees ci-dessus. Cet ´etat de fait a chang´e depuis et dans la pr´esente section nous ´evoquons quelques articles dont les propositions peuvent mettre en cause nos choix. 1.2.1 Contrˆole du trafic au coeur du r´eseau Nous proposons, dans le chapitre 2, la mise en oeuvre dans les files d’attente des routeurs d’un ordonnancement de type Deficit Round Robin (DRR) afin d’assurer l’´equit´e du partage de bande passante. Nous associons `a cet ordonnancement un m´ecanisme “Interest discard” de rejet s´electif de paquets Interest dans la direction inverse. D’autres ont propos´e d’assurer l’´equit´e du partage en ordonnan¸cant plutˆot les flots de paquets Interest dans un m´ecanisme dit “Interest shaping”. Dans ce cas, les paquets Data sont achemin´es dans une simple file FIFO. Dans [6], Fdida et al. d´ecrivent un m´ecanisme d’Interest shaping impl´ement´e au niveau de chaque routeur CCN. La file de transmission des paquets Data est observ´ee et un seuil de remplissage est fix´e. Le d´ebit des paquets Interest est r´egul´e suivant le d´ebit des paquets Data et en tenant compte de la diff´erence entre la taille de la file d’attente et le seuil. Ainsi les paquets Interest peuvent ˆetre retard´es si le nombre de paquets Data stock´es en file d’attente d´epassent le seuil. Dans l’article [7], Gallo et al. proposent un m´ecanisme d’Interest shaping presque identique `a la nˆotre sauf que les paquets Interest subissent un retard d’envoi en cas de congestion afin de limiter leur d´ebit. Des files virtuelles accueillent les paquets Interest selon l’objet recherch´e et un compteur est attribu´e `a chaque file. Les m´ecanismes d’Interest shaping peuvent provoquer des pertes de d´ebits dans certains sc´enarios. Dans l’exemple de la figure 1.1, si on applique l’Interest shaping sur tout le trafic on va retarder les paquets Interest ind´ependamment de leur appartenance aux flots. On va alors transmettre plus de paquets Interest du flot2 que du flot1. Sachant que le flot 2 sur le lien suivant perd en bande passante puisque la capacit´e du lien est inf´erieur `a la capacit´e du lien emprunt´e par le flot 1, cette situation particuli`ere entraine une perte en capacit´e. Il nous semble que notre choix d’agir directement sur le flux de donn´ees en imposant l’´equit´e par ordonnancement DRR est plus robuste. l’Interest discard n’intervient alorsCHAPITRE 1. INTRODUCTION 19 Client ccn node Serveur1 Serveur2 3Mb 3Mb 1Mb Flow1 Flow2 Figure 1.1 – Exemple illustrant la perte en d´ebit en utilisant le shaping sans classification par flot que comme m´ecanisme de contrˆole secondaire permettant le routeur de ne pas inutilement demander des paquets Data qui ne peuvent pas ˆetre achemin´es `a cause de la congestion sur la voie descendante. Il est notable aussi que le m´ecanisme d’Interest discard s’int`egre naturellement avec l’ordonnancement DRR dans la mˆeme “line card”. 1.2.2 Protocole de transport Dans notre proposition, le protocole de transport n’est pas critique car le contrˆole d’´equit´e du partage est r´ealis´e par ordonnancement DRR. D’autres ont propos´e plutˆot de maintenir de simples files FIFO en se fiant au protocole de transport pour le contrˆole d’´equit´e. Dans IP deux moyens permettent de d´etecter un rejet de paquet : les num´eros de s´equences des paquets s’ils ne se suivent pas ou le timeout si le d´elai d’acquittement d´epasse un seuil. Dans CCN les paquets Data, mˆeme s’ils ne subissent aucun rejet, n’ont pas forc´ement le bon ordre puisque les paquets peuvent ˆetre re¸cus de plusieurs sources diff´erentes. D’autre part le timeout calcul´e sur la base du RTT change tout le temps et ceci pourrait conduire `a des timeouts inopin´es. Gallo et al. [8] d´efinissent un protocole de transport d´enomm´e ICP (Interest Control Protocol). Ils proposent la d´etection de rejet par timeout mais en mettant `a jour r´eguli`erement le seuil de temporisation selon un historique. CCN dans ses premi`eres versions proposait un timeout fixe ce qui sanctionnait lourdement les flots en n´ecessitant une attente excessive avant de d´etecter les rejets. Vu que les RTTs peuvent varier dans CCN non seulement `a cause de la congestion, mais, du fait qu’on peut r´ecup´erer les objets de plusieurs sources, cette d´etection par timeout semble difficile `a mettre en oeuvre. Dans notre approche, d´etaill´ee plus loin, nous proposons un m´ecanisme de notification explicite de congestion qui permettrait une d´etection rapide de congestion sans besoin de timeout. 1.2.3 Multipath et multisource Dans CCN, un utilisateur ne peut pas connaitre d’avance les chemins emprunt´es par les paquets, car les paquets Interest ne contiennent que le nom de l’objet et le num´ero du20 1.2. ETAT DE L’ART paquet demand´e, sans aucune pr´ecision sur la destination. La difficult´e alors de d´etecter ou de s´eparer les chemins rend l’utilisation des protocoles de type MPTCP (multipath TCP) quasiment impossible. De ce fait, on ne peut pas utiliser une fenˆetre par chemin car l’utilisateur n’a aucun moyen d’acheminer ses paquets en suivant un chemin pr´ecis. Ce sont les routeurs qui choisissent le chemin d’un paquet Interest. Gallo et al. [7] proposent un couplage entre protocole de transport multipath et un m´ecanisme de forwarding au niveau des routeurs. Ils adaptent le protocole ICP au cas multipath en collectant les RTT venant de diff´erents chemins. En effet, un paquet Interest ne peut pas “savoir” `a l’avance vers quel chemin il serait achemin´e, mais, une fois achemin´e par le r´eseau, un paquet Data “connait” surement le chemin qu’il a emprunt´e. Le r´ecepteur peut donc identifier et enregistrer les chemins emprunt´es par les paquets. Ceci permet notamment d’estimer le RTT de chaque chemin. Cette approche nous paraˆıt lourde `a mettre en oeuvre. Dans notre proposition, on envisage l’utilisation de multipaths mais l’imposition d’un ordonnancement DRR par flot rend inefficace les m´ecanismes de coop´eration `a la MPTCP. Nous envisageons donc d’autres m´ecanismes pour ´eviter les ´ecueils d’un contrˆole de congestion ind´ependant par chemin. Cependant, nous notons ´egalement que le gain de d´ebit dˆu `a l’utilisation simultan´ee de plusieurs chemins n’est r´ealisable que par des flots ne subissant pas de limitation au niveau de l’acc`es. Cette observation nous m`ene `a croire qu’un seul chemin, judicieusement choisi, peut largement suffire dans la grande majorit´e des cas. Par ailleurs, Rossini et al. [9] identifie un ph´enom`ene de “pollution” des caches caus´e par l’utilisation des multipaths. Leurs r´esultats montrent des taux de hit nettement inf´erieurs en cas d’utilisation de chemins multiples, dˆu `a l’´eparpillement des copies de paquets dans les diff´erents caches.Chapitre 2 Partage de bande passante L’utilisation des caches au sein des CCN contribue `a l’am´elioration des d´elais de t´el´echargement et r´eduit les probl`emes de congestion. Mais la demande en trafic est en augmentation permanente, et il reste n´ecessaire d’utiliser des m´ecanismes de gestion du trafic. En effet, le contrˆole de congestion est n´ecessaire pour assurer des d´elais n´egligeables pour les flots voix et vid´eos, et pour ´eviter une consommation abusive de la bande passante par des flots agressifs. Des travaux ant´erieurs sur le r´eseau IP sugg`erent que le partage de bande passante par flot impos´e par un ordonnancement dans les routeurs est une solution efficace. Il r´ealise en effet une diff´erentiation de service implicite et assure de bonnes performances. Les flots dans les CCN peuvent ˆetre identifi´es selon l’objet recherch´e et il est possible ainsi d’appliquer une politique de congestion orient´ee flot. Pour g´erer le trafic et ´eviter la congestion, nous adoptons donc une politique “flowaware” o`u les actions de gestion tiennent compte de l’appartenance des paquets `a des flots. Nous pensons que ceci est pr´ef´erable `a un contrˆole de congestion o`u la performance d´epend d’un protocole mis en oeuvre dans l’´equipement des utilisateurs, comme dans le r´eseau IP actuel. En effet, rien ne garantit l’utilisation fid`ele de ce protocole. De plus, plusieurs variantes de TCP qui voient le jour le rendant de plus en plus agressif vis `a vis des versions ant´erieures. 2.1 Identification des flots Dans IP, un flot est d´efini par les adresses IP et les num´eros de port ; cela correspond typiquement `a une requˆete pr´ecise et sp´ecifique. Dans un CCN, au niveau de l’interface r´eseau, on ne peut acheminer qu’une seule demande pour le mˆeme objet. Un CCN utilise le multicast en envoyant l’objet re¸cu `a toutes les interfaces indiqu´ees dans la PIT. Nous identifions un flot grˆace aux noms de l’objet recherch´e et le fait que les paquets sont observ´es au mˆeme point du r´eseau et sont rapproch´es dans le temps. La figure 2.1 montre le format de l’entˆete des paquets en CCN. Les paquets Data et Interest portent le mˆeme nom d’objet mais, actuellement, il n’y a pas moyen de parser 2122 2.2. CACHES ET FILES D’ATTENTE chunk name user supplied name version chunk number other fields object name Figure 2.1 – Format des paquets CCN ce nom car c’est le ‘chunk name’ qui identifie un paquet data. Le champ ‘object name’ pourrait ˆetre analys´e afin d’identifier d’une fa¸con unique les paquets correspondants `a la demande d’objet mais ceci n´ecessiterait une modification du code CCNx. 2.2 Caches et files d’attente La d´eclaration faite dans l’article de Van Jacobson que “LRU remplace FIFO” semble ˆetre inexacte. Une file d’attente ne peut jouer le rˆole d’un cache, et vice versa, puisque la file d’attente devrait ˆetre de taille faible pour permettre un acc`es rapide `a la m´emoire, alors qu’un cache devrait ˆetre de taille grande mˆeme si le temps d’acc`es est plus lent. On d´emontre ceci par des exemples. On consid`ere une politique d’ordonnancement id´eal (LFU) o`u les objets les plus populaires sont stock´es dans un cache de taille N. L’impl´ementation d’une telle politique est possible selon [10]. On consid`ere des applications g´en´erant la majorit´e du trafic Internet comme YouTube et BitTorrent. La popularit´e des objets de ces applications suit la loi Zipf de param`etre α, c’est `a dire que la popularit´e du i eme ` objet le plus populaire est proportionnelle `a i −α. Des observations rapport´ees dans les articles [11] et [12] placent ce param`etre `a 0.75 environ. On consid`ere que les objets ont tous la mˆeme taille et que le catalogue est de M objets. La probabilit´e de hit global h pour une politique LFU peut ˆetre exprim´ee par : h = PN i=1 i −α PM i=1 i−α . Si on consid`ere un catalogue et une taille de cache assez grands, on a h ≈ N M 1−α . Pour 100 millions vid´eos Youtube de taille 4MB [13] il faut 640 GB de m´emoire pour un taux de hit de 20 % ou de 25 TB de m´emoire pour un taux de hit de 50 %. Pour 400 000 torrents avec une taille moyenne de 7 GB, il faut 4 TB pour un taux de hit de 20 %, ou de 175 TB de m´emoire pour un taux de hit de 50 %. Par ailleurs, la taille d’une file d’attente est au maximum ´egale au produit de la bande passante par le d´elai RTT [14] ; pour un lien `a 10 Gb/s et un d´elai de 200 ms, la taille d’une file d’attente est donc de l’ordre de 300 MB. Il est donc clairement n´ecessaire de distinguer deux m´emoires diff´erentes : des m´emoires cache de grande taille pour le stockage des donn´ees, et une file d’attente de taille beaucoup moins importante et avec un acc`es rapide.CHAPITRE 2. PARTAGE DE BANDE PASSANTE 23 Le contrˆole du trafic s’appuie sur la gestion des files d’attente. Il est donc important ´egalement pour cette raison de bien reconnaˆıtre la distinction entre ces files et le Content Store. 2.3 Le principe du flow aware networking Afin de prot´eger les flots sensibles audio et vid´eo, des techniques pour la gestion de la QoS comme Diffserv et Intserv ont ´et´e propos´ees. Le marquage de paquets dans Diffserv est une technique qui a ´et´e impl´ement´ee pour prioriser les flots voix ou vid´eo. Cependant, c’est une technique qui reste complexe `a mettre en oeuvre et sujette `a une possibilit´e de modification illicite du marquage. Il est bien connu par ailleurs que les approches orient´ees flots d’Intserv sont trop complexes et ne passent pas `a l’´echelle. On pourrait ´eventuellement prot´eger les flots sensibles et assurer une certaine ´equit´e dans le partage des ressources en utilisant un protocole de transport comme TCP. Cependant, l’utilisateur garde dans tous les cas une possibilit´e de modifier les impl´ementations ou bien d’utiliser des versions agressives de TCP. Nous pensons que le flow aware networking, d´eja propos´e pour les r´eseaux IP peut ˆetre adapt´e aux r´eseaux CCN. Ceci consiste `a mettre en place deux fonctionnalit´es : 1. le partage ´equitable de bande passante par flot, 2. le contrˆole de surcharge. Nous d´eveloppons ces deux points ci-dessous. 2.3.1 Partage des ressources dans les CCN Le partage ´equitable de la bande passante offre plusieurs avantages tr`es connus (voir [15], [16], [17] et [18]). Nous citons `a titre d’exemple : • les flots ´emettant des paquets `a un d´ebit inf´erieur au d´ebit ´equitable ne subissent pas de rejets de paquets. • les flot sensibles (conversationnels et streaming) ayant g´en´eralement des d´ebits faibles sont prot´eg´es et b´en´eficient d’un service de diff´erentiation implicite, • les flots agressifs ne gagnent rien en ´emettant des paquets trop rapidement car leur d´ebit ne peut d´epasser le d´ebit ´equitable. Pour une utilisation ´equitable de la bande passante, et pour prot´eger les flot sensibles, nous proposons que le r´eseau CCN assure lui-mˆeme le partage ´equitable des ressources r´eseau. Les avantages de cette technique ont ´et´e largement d´evelopp´es dans les articles pr´ecit´es ; elle peut s’adapter parfaitement aux r´eseaux CCN. Pour le partage ´equitable des ressources, nous avons revu plusieurs propositions. Nous comparons par simulations certains protocoles fair drop, et un protocole fair queuing. On consid`ere un lien `a 10 Mb/s partag´e par les flux suivants :24 2.3. LE PRINCIPE DU FLOW AWARE NETWORKING • TCP1 : facteur AIMD=1/2, RTT=10ms • TCP2 : facteur AIMD=1/2, RTT=30ms • TCP3 : facteur AIMD=1/2, RTT=50ms • CBR : flux `a d´ebit constant de 3Mb/s • Poisson : Un flux poissonien de paquets repr´esentant la superposition d’un grand nombre de flux de faible d´ebit. La figure 2.2 pr´esente les r´esultats obtenus. 0 1 2 3 4 5 Tail Drop Fred Afd tcp0 tcp1 tcp2 cbr Poisson (a) Algorithmes Fair drop 0 1 2 3 4 5 Fair Queuing Throughput(Mb/s) tcp0 tcp1 tcp2 cbr Poisson (b) Fair queuing Figure 2.2 – Comparaison des protocoles fair drop et du protocole Fair queuing Il est clair que le fair queuing est l’algorithme le plus efficace. Il a ´egalement l’avantage d’ˆetre sans param`etre. Son passage `a l’´echelle a ´et´e d´emontr´e `a condition d’assurer ´egalement un contrˆole de surcharge. En effet, il a ´et´e d´emontr´e dans [19] que le nombre de flots ne d´epasse pas quelques centaines si la charge du r´eseau reste inf´erieur `a 90 %, une valeur de charge au-dessus des exigences des op´erateurs. Le d´ebit ´equitable pour un lien de capacit´e C et de charge ρ est estim´e `a C(1 − ρ) [20]. Dans un r´eseau `a charge normale (ne d´epassant pas 90 %) ce d´ebit est largement suffisant pour les flots streaming et conversationnels. Le partage ´equitable n’est pas un objectif en soi, mais un moyen d’assurer un d´ebit acceptable et de prot´eger les flots adaptatifs des flots gourmands. Ainsi, tout flot ne d´epassant pas le d´ebit ´equitable ne subit aucun rejet de paquet dont le d´elai est tr`es faible. C’est aussi un moyen automatique pour assurer un fonctionnement normal sur Internet sans se soucier des comportements de l’utilisateur final. Notons que la possibilit´e de contourner l’imposition d’un partage ´equitable par la g´en´eration de multiples flots au lieu d’un seul est tr`es limit´ee [21]. Tr`es peu d’usagers peuvent en fait ´emettre du trafic `a un d´ebit plus fort que le d´ebit ´equitable. Le d´ebit pour la plupart des usagers est limit´e par leur d´ebit d’acc`es. De plus, dans un r´eseauCHAPITRE 2. PARTAGE DE BANDE PASSANTE 25 CCN o`u les flots sont d´efinis par le nom de l’objet, la possibilit´e de d´emultiplier les flots est beaucoup plus limit´ee qu’en IP. Nous proposons l’utilisation d’un algorithme d’ordonnancement comme DRR [22] o`u les files par flot sont mod´elis´ees par des listes chain´ees utilisant une structure nomm´ee ActiveList. Il a ´et´e d´emontr´e que le nombre de flots dans ActiveList est limit´e `a quelques centaines pour une charge ne pas d´epassant 90%, ind´ependamment de la capacit´e du lien C [19]. Ces r´esultats d´emontrent le “scalabilit´e” de l’ordonnancement DRR. 2.3.2 Contrˆole de surcharge La demande en trafic est le produit du d´ebit d’arriv´ee des flots par la taille moyenne d’un flot. On dit qu’un r´eseau est en surcharge si la demande d´epasse la capacit´e du lien. Dans ce cas, le r´eseau est instable : le nombre de flots en cours croˆıt et leur d´ebit devient tr`es faible. Le partage ´equitable de la bande passante par flot n’est donc scalable que si la charge du lien (demande divis´ee par la capacit´e du lien) est normale. On consid`ere la valeur maximale d’une charge normale ´egale `a 90%. Si la charge du r´eseau d´epasse 90%, le nombre de flots devient trop grand et donc lourd `a g´erer. Pour contrˆoler la charge, on pourrait mettre en place un m´ecanisme de contrˆole d’admission. Ceci consiste `a ´eliminer tout nouveau flot d`es que la charge du r´eseau atteint une valeur maximale. Pour ceci, il faut sauvegarder une liste de flots en cours et ´ecarter tout nouveau flot arrivant. Cependant, pour un r´eseau bien dimensionn´e, le probl`eme de surcharge ne se pose qu’en certains cas rares, comme par exemple une panne sur un lien r´eseau. Pour CCN, plutˆot qu’un contrˆole d’admission complexe et peu utilis´e, nous proposons la simple suppression des paquets d’une certaine liste de flots afin de r´eduire le niveau de charge. Cette liste pourrait ˆetre d´efinie de mani`ere arbitraire (par une fonction hash sur l’identit´e du flot) ou, si possible, de mani`ere plus s´elective en n’incluant que les flots les moins prioritaires.Chapitre 3 Mecanismes pour CCN ´ 3.1 M´ecanismes pour les utilisateurs L’usager dans un CCN doit participer `a la gestion du trafic en modulant la vitesse `a laquelle il envoie les Interests pour les chunks d’un mˆeme objet. L’utilisation du protocole de transport adaptatif dans un r´eseau CCN ´equip´e de l’ordonnancement DRR n’est pas n´ecessaire pour assurer le bon fonctionnement du r´eseau. Cependant, nous recommandons l’utilisation d’un protocole adaptatif pour ´eviter les r´e´emissions multiples, dues aux rejets Interest. 3.1.1 D´etection des rejets Nous proposons pour l’utilisateur un m´ecanisme de d´etection rapide de rejet dont voici la description. Si un paquet est rejet´e au niveau de la file d’attente en raison de sa saturation ou en raison d’une politique de gestion de la file d’attente, on envoie `a l’utilisateur l’entˆete du paquet data sans le payload. L’utilisateur, en recevant un paquet data de payload nul, sait que le paquet a ´et´e rejet´e, et donc r´eajuste la vitesse d’´emission des Interests pour ´eviter l’accumulation de r´e´emissions inutiles. Mieux encore, une modification peut ˆetre apport´ee `a l’entˆete du paquet data afin de pr´eciser qu’il correspond `a un discard. Cette technique de d´etection de rejet est particuli`erement int´eressante dans les CCN, puisqu’on ne peut pas se baser sur le s´equencement des paquets. En effet, contrairement `a TCP/IP, deux paquets qui se suivent `a l’origine ne se suivent pas forc´ement `a la r´eception, car la source d’une donn´ee n’est pas forc´ement unique, et le chemin n’est pas forc´ement le mˆeme pour tous les paquets. Actuellement, dans l’impl´ementation CCNx, la d´etection est faite uniquement en se basant sur le timeout. Ceci reste tr`es impr´ecis, et peut poser des probl`emes. A titre 26CHAPITRE 3. MECANISMES POUR CCN ´ 27 d’exemple, avec un timeout fixe, comme c’est le cas de CCNx dans ses premi`eres versions, une d´etection de rejet ne correspond pas forc´ement en fait `a un rejet, mais `a un temps de propagation et de transmission d´epassant le timeout. R´eduisant la fenˆetre dans un tel cas ne fait que d´et´eriorer les d´ebits des flots malgr´e la disponibilit´e de la capacit´e dans les liens. Un protocole de transport efficace arrive `a d´etecter rapidement les rejets. Ceci devient plus difficile lorsque le protocole de transport connecte l’utilisateur `a deux sources ou plus. Dans CCN, un utilisateur ne peut savoir `a l’avance s’il est servi par deux sources, car la seule donn´ee qu’il d´etient est le nom d’objet. De plus, toute l’architecture du r´eseau et la localisation des serveurs de donn´ees sont invisibles pour lui, ce qui est le but de CCN. L’article de Carofiglio et al. [8] apporte une r´eponse `a ce probl`eme. En utilisant un historique un peu large, on collecte des informations statistiques sur le nombre de chemins utilis´es ainsi que les RTT recens´es pendant les ´echanges, et on construit, sur la base de ces informations, un protocole de transport multipath efficace. En tous les cas, nous sommes peu favorables `a l’utilisation des multipaths et multisources. Les liens r´eseaux ont des capacit´es tellement grandes que le d´ebit d’un seul flot ne peut gu`ere atteindre la capacit´e du lien. Le d´ebit des flots est limit´e en fait par le d´ebit d’acc`es au r´eseau qui est faible par rapport au d´ebit des liens au coeur de r´eseau. Donc, un seul lien non surcharg´e est largement suffisant pour q’un flot r´ealise son d´ebit maximal. Par contre, nous sommes favorables `a des m´ecanismes de load balancing en cas de surcharge de certains liens, ce qui devrait ˆetre assez exceptionnel dans un r´eseau bien dimensionn´e. Avec la d´etection rapide des rejets, le paquet Interest qui a subi le discard est transform´e en paquet data sans payload, avec ´eventuellement une modification l´eg`ere de l’entˆete afin de signaler le discard. Le paquet traverse le chemin inverse en supprimant au fur et `a mesure les entr´ees correspondantes `a la PIT. A la r´eception du paquet data, l’utilisateur ou les utilisateurs corrigeront le probl`eme d´etect´e en adaptant au mieux le d´ebit d’´emission selon le protocole de transport. 3.1.2 Protocole de transport Dans le cas d’un ordonnancement fair queuing, l’utilisateur ne gagne pas en bande passante en ´etant tr`es agressif. Les r´e´emissions multiples d’Interest sont une cons´equence directe d’un protocole de transport agressif ne prenant pas en compte le feedback r´eseau. Si le fair sharing est impos´e, comme nous l’avons sugg´er´e, le protocole de transport n’est plus vu comme un outil pour r´ealiser le partage de bande passante. Le plus simple serait d’envoyer des paquets Interest `a d´ebit constant, mais dans ce cas, le r´ecepteur devrait g´erer une large liste de paquets Interest en attente. Nous proposons plutˆot un protocole AIMD (additive increase/multiplicative-decrease) comme TCP avec d´etection rapide de perte et en utilisant une fenˆetre adaptative CWND (Congestion Window). Le nombre de paquets Interest d’un flot qui transite28 3.2. MECANISMES POUR OP ´ ERATEURS ´ dans le r´eseau ne doit pas d´epasser la taille de la fenˆetre CWND. A la d´etection d’un rejet par d´etection rapide ou timeout, la fenˆetre est r´eduite suivant un facteur ; plus ce facteur est proche de 1, plus le protocole est aggressif. En absence de perte, la fenˆetre CWND croˆıt lin´eairement selon un certain taux. Encore, plus ce taux est grand, plus le protocole est aggressif. 3.2 M´ecanismes pour op´erateurs En plus de l’ordonnancement “fair queuing”, nous envisageons un m´ecanisme pr´eventif de rejet d’Interest. L’op´erateur devrait ´egalement exploiter les sources multiples de certaines donn´ees en appliquant une strat´egie d’acheminement adapt´ee. 3.2.1 Motivation ´economique Il est important de mettre en place une motivation ´economique pour encourager l’op´erateur `a d´eployer cette nouvelle architecture. Il est ´egalement important que le fournisseur de r´eseau soit r´emun´er´e pour le trafic qu’il ´ecoule. On consid`ere que le fournisseur devrait ˆetre pay´e pour les data envoy´es ; par exemple, dans la figure 3.1, l’utilisateur U1 paye le fournisseur P1 pour les data qu’il fournit, et P1 paye P2 pour les data re¸cus. Cette approche fournit bien la motivation n´ecessaire pour d´eployer un r´eseau CCN muni de caches, car le fournisseur, en utilisant des caches, ne serait pas amen´e `a acheter le mˆeme contenu plusieurs fois. Les frais devraient couvrir les coˆuts d’infrastructure (bande passante et caches), et leur nature exacte pourrait prendre de nombreuses formes, y compris les tarifs forfaitaires et des accords de peering. 3.2.2 Interest Discard L’utilisateur ne paye le fournisseur que s’il re¸coit effectivement la donn´ee. Le fournisseur doit donc assurer un contrˆole de congestion afin d’´eviter la perte des donn´ees transmises `a ses clients. Il a int´erˆet `a rejeter les Interests en exc`es pour ´eviter de racheter des donn´ees qui ne peuvent pas ˆetre revendues `a cause d’une congestion ´eventuelle. Afin d’´eviter un tel probl`eme, nous proposons un m´ecanisme compl´ementaire pour prot´eger le fournisseur. Supposons le lien AB dans la figure 3.1 congestionn´e ; B va limiter le d´ebit des Interests envoy´es vers le fournisseur P2 pour ´eviter d’acheter des donn´ees qui ne seront pas revendues `a l’utilisateur final U1 puisqu’elles seront perdues `a cause de la congestion. Nous appelons ce m´ecanisme “Interest Discard”. On consid`ere le lien AB de la figure 3.1. A re¸coit les paquets Interest de U1 et renvoie ces paquets vers B. B re¸coit dans l’autre sens les paquets de donn´ees r´ecup´er´es du fournisseur P2 et applique le Deficit Round Robin sur les paquets Data envoy´es vers A.CHAPITRE 3. MECANISMES POUR CCN ´ 29 Ub Aout Bin Ain Bout Interests Data Interests Data Sb Ua Sa Figure 3.1 – Les cartes r´eseaux des routeurs A et B travers´ees par des paquets Interest et Data B calcule en effet un d´ebit d’´equit´e correspondant `a l’inverse du temp de cycle moyen de DRR. Le d´ebit des Interest est limit´e par des rejets forc´es en utilisant un sceau `a jetons. Le d´ebit des Interests est limit´e au d´ebit correspondant au d´ebit ´equitable r´ealis´e actuellement par le DRR (tenant compte de la taille diff´erente des paquets Interest et Data). Le sceau `a jetons est donc aliment´e au rythme de l’ordonnancement. Notons que le DRR et le sceau `a jetons seront r´ealis´es dans la mˆeme carte r´eseau facilitant ainsi leur couplage. Nous pr´esentons le pseudocode interest Discard, cet algorithme doit ˆetre utilis´e au niveau de chaque interface r´eseau. Il est ex´ecut´e `a l’arriv´ee d’un interest `a l’interface, et `a chaque cycle Round Robin incr´ementer tous les compteurs de l’interface. Nous r´esumons ci-dessous l’algorithme ex´ecut´e au niveau de l’interface r´eseau. Algorithm 1 A l’arriv´ee d’un paquet interest `a l’interface r´eseau R´ecup´erer le nom d’objet du paquet name Calculer le hash du nom d’objet hash if f ile[hash]∄ then Cr´eer la file ayant comme ID hash Attribuer un compteur count[hash] au flux Initialiser le compteur count[hash] = b end if if count(hash)==0 then rejeter l’interest i else count(hash)- - ; end if Nous adoptons le DRR comme algorithme fair queuing, il utilise un nombre fixe de files. On note M le nombre maximal de files Round Robin30 3.2. MECANISMES POUR OP ´ ERATEURS ´ Algorithm 2 A la sortie de l’interface r´eseau i = 0 while i < M do if f ile[i]∃ then Servir le premier paquet de f ile[i] end if if f ile[i] = ∅ et count[i] = b then Supprimer la file physique f ile[i] end if for i = 0 to M − 1 do count[i] = count[i] + 1 end for end whileChapitre 4 Strategies d’acheminement ´ L’architecture CCN offre de nouvelles possibilit´es d’acheminement. Il est en particulier possible d’utiliser plusieurs sources pour un mˆeme objet. Nous avons fait quelques ´etudes sur l’acheminement multi-sources. On d´emontre que les m´ecanismes de gestion du trafic fonctionnent bien dans ce contexte. Cependant, avant de poursuivre la recherche dans ce domaine, il est essentiel de comprendre les possibilit´es r´eelles qu’offrirait un r´eseau CCN en fonction de sa politique de stockage. Nos ´etudes dans cette direction sont d´ecrites dans les deux parties suivantes de ce rapport. 4.1 Multicast Sur la figure 3.1 les utilisateurs Ua et Ub demandent le mˆeme objet stock´e au niveau du fournisseur S1. Si les demandes se passent en mˆeme temps, une seule demande sera enregistr´ee au niveau du routeur B et donc le flot correspondant `a l’objet demand´e aura le mˆeme d´ebit des flots unicast dans le lien BS1. Il n’y a donc pas lieu de distinguer ces flots dans l’ordonnanceur DRR. Si les demandes sont d´ecal´ees dans le temps et que l’utilisateur Ua commence le t´el´echargement des paquets avant l’utilisateur Ub, il est possible que le d´ebit accord´e au flot soit divis´e par deux au niveau du lien BS1. Mais puisque le routeur B est dot´e d’une m´emoire cache, il est tr`es probable que l’utilisateur Ub trouve les paquets pr´ec´edemment t´el´echarg´es par Ua au niveau du cache B, et donc seuls les paquets non t´el´echarg´es par U1 seront demand´es et traverseront le lien S1B. Le d´ebit des flots multicast est donc ´egal au d´ebit des flots unicast sur toutes les branches du r´eseau. Il suffit que le temps de t´el´echargement d’un objet soit inf´erieur au temps de stockage de l’objet dans un cache. Encore, il n’y a pas lieu de distinguer ces flots dans l’ordonnanceur DRR. 3132 4.2. MULTISOURCES Il est important alors de maintenir une m´emoire sauvegardant les paquets des flots en cours, ´evitant ainsi la division du d´ebit des flot par deux ou plus au cas o`u plusieurs flots cherchant le mˆeme objet arrivent en mˆeme temps sur une interface r´eseau, et que ces flot soient non synchronis´es. 4.2 Multisources 4.2.1 Protocole de transport Multipath L’utilisation des multipaths n’a pas de sens que si les performances du r´eseau s’am´eliorent, et que cette utilisation ne r´eduit pas le d´ebit des flots et leurs performances par rapport `a une utilisation compl`etement unipath. Il est important de v´erifier que l’utilisation du routage multipath ne diminue de mani`ere sensible la r´egion de stabilit´e. Un r´eseau stable, est un r´eseau o`u les flots sont servis en un temps fini, c’est `a dire qu’aucun flot souffre de congestion `a cause de la charge sur un lien de son chemin. Dans un mod`ele enti`erement unipath, un r´eseau est stable `a condition que chaque chemin r constitu´e d’un ensemble de liens L(r) et travers´e par un ensemble de flots S v´erifie : X k∈S ρk < Cl ∀l ∈ L(r). Le fair queuing, que nous pr´econisons d’utiliser au niveau des routeurs, n’est pas seulement b´en´efique pour prot´eger les flot gourmands, et pour r´ealiser une certaine ´equit´e entre les flots, mais c’est aussi un moyen de maximiser la r´egion de stabilit´e. En effet, les auteurs de [23] ont d´emontr´e que le fair queuing offrait une r´egion de stabilit´e maximale, et donc permettrait une utilisation optimale du r´eseau. Dans un r´egime multipath, les auteurs de [24] ont d´emontr´e qu’un r´eseau est stable sous la condition : X r∈S ρr < X l∈L(s) Cl . 4.2.2 Performance de MPTCP Afin de mieux comprendre l’utilisation du routage multipath dans CCN, nous avons ´etudi´e d’abord l’impact sur la performance des diff´erentes versions de MPTCP envisag´ees actuellement pour le r´eseau IP. Les protocoles Multipaths sont class´es en deux cat´egories : les protocoles non coordonn´es et les protocoles coordonn´es. Un protocole de transport non coordonn´e permet de r´ecup´erer un maximum de d´ebit mais cette augmentation de d´ebit p´enalise le d´ebit des autres flots car le flot multipath consomme plus de capacit´e que les autres. L’exemple illustr´e dans la figure 4.1 montre que l’utilisation du TCP non coordonn´e peut r´eduire le d´ebit des flots unicast en offrant plus de d´ebit aux flots multichemins, ce qui est loin de nos objectifs. EnCHAPITRE 4. STRATEGIES D’ACHEMINEMENT ´ 33 effet, le flot f1 partage le lien `a 2 Mb/s avec le flot f2 malgr´e la disponibilit´e d’un autre lien enti`erement d´edi´e pour lui et pouvant servir tout le d´ebit requis. flux2 flux1 c=4 c=2 c=2 Figure 4.1 – Le TCP Multipath non coordonn´e n’assure pas l’´equit´e Le MPTCP coordonn´e r´epond `a la condition de stabilit´e. Sa description est pr´esent´e par l’IETF1 ; la RFC 6356 d´ecrit les fonctionnalit´es d’un protocole de transport MPTCP. Il offre beaucoup d’avantages tels que la fiabilit´e en maintenant la connexion en cas de panne, le load balancing en cas de congestion ou l’utilisation du r´eseau wifi et ADSL en mˆeme temps, par exemple, pour r´ecup´erer le mˆeme contenu. Chaque flot utilisant MPTCP est subdivis´e en plusieurs sous-flots, chacun ´eventuellement suivant un chemin diff´erent. Chaque sous-flot r d´etient sa propre fenˆetre wr [25]. On trouve deux types de protocole MPTCP coordonn´e : le MPTCP semi coupl´e et le MPTCP coupl´e. Dans le cas d’un protocole MPTCP coupl´e, `a la d´et´ection d’un rejet, la fenˆetre cwndr du sous-flot r d´ecroit `a max(cwndr − cwndtotal/2, 1). Dans le cas d’un contrˆole de congestion MPTCP semi coupl´e la fenˆetre d’un sous-flot d´ecroit selon sa propre fenˆetre de congestion uniquement. En utilisant un MPTCP enti`erement coupl´e, les fenˆetres s’annulent `a tour de rˆole rendant le fonctionnement de ce protocole instable [26]. Dans notre proposition du module de gestion du trafic pour CCN, nous avons propos´e l’utilisation du Round Robin, il s’av`ere que le Round Robin invalide le fonctionnement du MPTCP coordonn´e. Les ajustements faits par l’utilisateur ne corrigent pas ce probl`eme. Nous avons observ´e ce ph´enom`ene en simulant avec ns2 un tron¸con de r´eseau pr´esent´e dans la figure 4.2. Un flot MPTCP ´emis par le noeud A est constitu´e de deux sous-flot : TCP0, qui suit le plus long chemin vers le r´ecepteur MPTCP (noeud D) A-B-C-D, et T CP2, qui suit le plus court chemin vers le r´ecepteur MPTCP A-D. Un flot TCP g´en´er´e par le noeud E suit le plus court chemin E-B-C-F vers le r´ecepteur TCP. Nous comparons dans un premier temps les d´ebits des flots T CP0 et T CP2 partageant le lien B-C avec une politique Tail drop dans tous les noeuds du r´eseau. La figure 14.3 confirme l’efficacit´e du MPTCP coordonn´e qui r´ealise l’´equit´e en prenant en compte toute la bande passante offerte au flot, et non pas la bande passante offerte par un lien uniquement. Avec le MPTCP non coordonn´e le flot TCP0 partage 1http ://datatracker.ietf.org/wg/mptcp/charter/34 4.2. MULTISOURCES Emetteur TCP Recepteur TCP Emetteur MPTCP Recepteur MPTCP TCP0 TCP1 TCP0 TCP1 TCP0 1Mb 2Mb Figure 4.2 – un r´eseau pour illustrer les Multipaths (a) MPTCP coordonn´e (b) MPTCP non coordonn´e Figure 4.3 – MPTCP coordonn´e priorise le flot unipath ´equitablement la bande passante avec TCP2, ce qui est ´equitable localement sur le lien, mais ne l’est pas globalement dans le r´eseau, puisque l’´emetteur TCP re¸coit un d´ebit suppl´ementaire du sous-flot TCP1. Le protocole MPTCP coordonn´e corrige ce probl`eme et offre au flot unipath TCP1 plus de d´ebit que TCP0. Nous recommen¸cons le mˆeme sc´enario mais en appliquant une politique Round Robin au noeud B. Nous observons le d´ebit des flots TCP0 et TCP2. On obtient les r´esultats pr´esent´es dans la figure 4.4 : Le MPTCP coordonn´e avec Round Robin r´ealise une ´equit´e par lien. Les flots TCP0 et TCP2 partage ´equitablement la bande passante au niveau du lien B-C, contrairement aux r´esultats observ´es avec Tail Drop, ou le flot TCP2 gagnait plus de d´ebit. L’effetCHAPITRE 4. STRATEGIES D’ACHEMINEMENT ´ 35 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 0 2 4 6 8 10 12 14 16 18 20 throughput temps tcp0 reno0 Figure 4.4 – Le Round Robin annule l’efficacit´e du MPTCP des changements des fenˆetres d’une mani`ere coordonn´ee sont invalid´es par le Round Robin. L’effet du partage ´equitable local par lien du Round Robin est dominant, et le MPTCP coordonn´e perd son efficacit´e. Pour pallier `a ce probl`eme ,on propose un nouveau protocole MPRR(Multipath Round Robin) permettant de r´ealiser l’´equit´e niveau flot et de pr´eserver les performances du protocole MPTCP, le protocole MPTCP est d´ecrit par les algorithme ci dessous : Algorithm 3 A l’arriv´ee d’un paquet interest `a l’interface r´eseau I0 et sortant de l’interface I1 R´ecup´erer le nom d’objet du paquet name Calculer le hash du nom d’objet hash if f ile[hash]∄ then Cr´eer la file ayant comme ID hash Attribuer un compteur mark[hash] au flux Initialiser le compteur mark[hash] = 0 end if if interest marqu´e then mark[hash]++ ; else envoyer le paquet interest `a l’interface I1 if Une autre interface I2 r´eseau est utilis´e par le flux name then envoy´e un paquet interest marqu´e `a I2 end if end if36 4.2. MULTISOURCES Algorithm 4 A la sortie de l’interface r´eseau i = 0 while i < M do if f ile[i]∃ then if mark[i] == 0 then Servir le premier paquet de f ile[i] end if else mark[i]- - ; end if if f ile[i] = ∅ then Supprimer la file physique f ile[i] end if end while Au niveau d’un routeur, si deux interfaces I1 et I2 sont utilis´ees pour envoyer les paquets d’un flot f, `a chaque fois qu’un paquet Interest du flot f est envoy´e vers une interface, un paquet Interest dupliqu´e et marqu´e serait envoy´e `a la deuxi`eme interface. Les interfaces servant un flot multipath sont sauvegard´ees au niveau de la FIB. Au niveau du cache, `a chaque fois qu’on re¸coit un paquet Interest marqu´e, il prendrait place dans la file d’attente du flot f et le compteur Interest discard du flot f serait d´ecr´ement´e. Mais ce paquet ne serait pas achemin´e vers les autres interfaces du r´eseau, il est utilis´e uniquement pour mettre en place l’´equit´e entre flots. Chaque flot a une file unique au niveau de chaque interface. La file correspondante au flot f est trait´e une seule fois `a chaque cycle Round Robin comme tous les flots arrivants `a l’interface. Afin de v´erifier notre protocole, on utilise le simulateur Simpy pour simuler le r´eseau de la figure 4.5. 1,2 1,2 1 capacity=10Mb/s capacity=1Mb/s capacity=2Mb/s Figure 4.5 – r´eseau simul´e avec Simpy En utilisant le MPRR au niveau des interfaces on obtient les r´esultats pr´esent´es dans la figure 4.6 Le d´ebit du flot TCP0 partageant le lien avec le sous-flot MPTCP TCP1, et le d´ebit du sous flot MPTCP circulant sur le deuxi`eme lien TCP2 en utilisant les politiques Tail drop, Round Robin et MPRR sont repr´esent´es dans la figure 4.6.CHAPITRE 4. STRATEGIES D’ACHEMINEMENT ´ 37 0 200000 400000 600000 800000 1e+06 1.2e+06 1.4e+06 1.6e+06 1.8e+06 2e+06 0 50 100 150 200 250 300 350 400 450 500 Throughput(b/s) Time tcp0 tcp1 tcp2 (a) politique Tail drop 100000 200000 300000 400000 500000 600000 700000 800000 900000 1e+06 1.1e+06 1.2e+06 0 50 100 150 200 250 300 350 400 450 500 T hroughput(b/s) T ime tcp0 tcp1 tcp2 (b) politique Round Robin Figure 4.6 – D´ebits des flots avec politique Tail drop (gauche) et Round Robin (droite) Le MPTCP offre des d´ebits approximativement ´equitables tenant compte de la capacit´e global offerte au flot. Le Round Robin assure une ´equit´e au niveau de chaque lien, ce qui a pour effet de r´ealiser une in´equit´e au sens global en prenant compte de la capacit´e globale offerte. 200000 400000 600000 800000 1e+06 1.2e+06 1.4e+06 1.6e+06 1.8e+06 0 50 100 150 200 250 300 350 400 450 500 Throughput(b/s) Time tcp0 tcp1 tcp2 Figure 4.7 – D´ebits des flot avec politique Multipath Round Robin Le MPRR corrige le probl`eme provoqu´e par l’utilisation du Round Robin en r´ealisant des d´ebits presque ´equitables en prenant compte toute la capacit´e offerte aux flots, les graphes montrent une am´elioration par rapport au Tail drop traditionnel.38 4.2. MULTISOURCES 4.2.3 CCN et routage multipath Mˆeme si le MPTCP s’av`ere performant en utilisant Tail drop, ou en utilisant le MPRR, on ne peut pas faire enti`erement confiance `a tous les utilisateurs de l’Internet. L’utilisateur d´etient toujours la possibilit´e de modifier son protocole de transport, ou d’utiliser le MPTCP non coordonn´e, par exemple. Rien n’oblige l’utilisateur `a participer `a la gestion de congestion. On note aussi la difficult´e d’impl´ementer un protocole MPTCP dans CCN, du fait que l’utilisateur ne peut choisir la destination de chaque paquet. On pourrait envisager une m´ethode statistique se basant sur l’historique des chemins travers´es et leur RTTs. Si on ne peut choisir le chemin qui serait travers´e `a l’´emission, il reste possible de savoir le chemin qui a ´et´e suivi par un paquet `a la r´eception en stockant les noeud travers´es dans chaque paquet, par exemple [27]. Malheureusement cette m´ethode reste compliqu´ee et demande beaucoup de modifications au niveau de chaque paquet. De plus, la coordination des routeurs est n´ecessaire pour r´ealiser l’´equit´e globale dans le r´eseau. Nous pensons que les multipaths dans CCN ne devrait pas ˆetre g´er´es par les utilisateurs, ou du moins les utilisateurs ne sont pas responsables de la gestion du trafic dans le r´eseau. Nous ne pouvons qu’´emettre des conseils permettant `a l’utilisateur d’utiliser au mieux la bande passante et d’´eviter les rejets d’Interests successifs rendant leur protocole de transport compliqu´e `a g´erer. C’est le r´eseau qui devrait distribuer les paquets ´equitablement sur les liens disponibles. 4.2.4 Performances des multipaths Nous pensons que les flots multipaths devraient ˆetre g´er´e par le r´eseau lui-mˆeme. Pour ´evaluer les performances des multipaths, nous proposons d’´etudier deux segments de r´eseaux pr´esent´es dans la figure 4.8. N1 a) multiple single-hop sources N1 N4 N3 N2 S2 S3 S4 b) short paths and long paths Figure 4.8 – Deux r´eseaux pour illustrer les Multipaths Dans la figure 4.8a, les flot arrivants au noeud N1 peuvent r´ecup´erer les donn´ees duCHAPITRE 4. STRATEGIES D’ACHEMINEMENT ´ 39 routeur S1 localis´ee dans le noeud N1, sinon dans le cas o`u la donn´ee est introuvable, la r´ecup´erer d’une des 3 sources S4,S2 ou S3. Dans la figure 4.8b, deux routeurs sont choisi aux hasard pour r´ecup´erer les donn´ees. Nous comparons les 3 cas suivants : – un seul chemin qui correspond au chemin le plus court en nombre de sauts est utilis´e par les flots, – deux chemins sont utilis´es conjointement, – on utilise un contrˆole de charge s´electif qui consiste `a refuser l’acc`es au lien `a tout flot multipath si le lien est un chemin secondaire, et si la charge du lien d´epasse un certain seuil. On utilise des simulations Monte-Carlo pour ´evaluer le d´ebit moyen des flots en fonction de la charge, et comparer ainsi les performances des strat´egies d’acheminement. La figure repr´esente la bande passante en fonction de la charge. Pour le premier (a) a (b) b Figure 4.9 – MPTCP coordonn´e priorise les flot unipath r´eseau 4.9(a) la charge maximale `a partir de laquelle le r´eseau est instable est de 5,29 exprim´ee en unit´es du d´ebit d’un lien. Ceci peut ˆetre pr´edit par calcul. Dans ce cas, les chemins ont le mˆeme nombre de sauts. D´es qu’un chemin est surcharg´e on ne peut plus l’utiliser. L’utilisation du r´eseau est maximal avec le DRR et le contrˆole de charge. Les d´ebits du deuxi`eme r´eseau montrent que l’utilisation des chemins multiples sans aucune strat´egie m`ene `a une perte en capacit´e (la r´egion de stabilit´e est r´eduite). Dans ce cas le d´ebit offert est maximale au d´ebut. L’utilisation des chemins unicast offre une meilleur capacit´e en trafic, mais les d´ebits offerts au d´ebut sont plus faibles. Afin d’offrir des d´ebits plus importants `a faible charge, tout en offrant une meilleure capacit´e en trafic, nous proposons d’appliquer le contrˆole de charge s´electif.40 4.2. MULTISOURCES D`es qu’un seuil de d´ebit est atteint dans un lien, il faut refuser l’acc`es aux flots multipaths si le lien appartient `a un chemin secondaire. Pour distinguer les chemins secondaires et principaux pour un flot on peut marquer les paquets qui traversent un chemin secondaire. On observe effectivement que les performances obtenues avec un contrˆole de charge s´electif sont mieux que celles obtenus avec une utilisation exclusive des chemins les plus courts, et ´evidement mieux que l’utilisation al´eatoire des chemins multipath. En r´ealit´e les liens au coeur du r´eseau ont des d´ebits tr`es ´elev´es d´epassant le d´ebit d’acc`es des utilisateurs. L’utilisation des chemins multiples n’est pas forc´ement b´en´efique, les performances des caches localis´es au niveau des routeurs peuvent s´erieusement d´ecroitre. Pour illustrer ce ph´enom`ene, on consid`ere un r´eseau simple repr´esent´e dans la figure 4.10. A C B Figure 4.10 – tron¸con de r´eseau pour d´emontrer l’impact des multipath sur le hit global Des flots arrivent au noeud A selon un processus de Poisson. Si l’objet se trouve dans le noeud A alors le cache A r´epond `a la requˆete. Si l’objet demand´e se trouve dans les deux caches B et C alors un des deux caches est choisi au hasard et l’objet est r´ecup´er´e du cache choisi. Si un des caches contient l’objet et que l’autre ne le contient pas, le chemin le plus long menant au cache d´etenteur d’objet est s´electionne avec une probabilit´e P. Si aucun des caches B ou C ne contient l’objet alors il est dirig´e vers le serveur d’origine `a travers le routeur B ou C (choisi au hasard). La popularit´e des requˆetes suit une loi Zipf(0.8). On trace la probabilit´e de hit global de cette micro architecture en fonction de la probabilit´e de choix du chemin le plus long pour diff´erentes valeurs de la taille des caches. On choisit une taille de catalogue de 104 objets. Conform´ement `a la proposition CCN les caches ont la mˆeme taille. Cette exemple illustre un contre exemple des b´en´efices tir´es par les multipaths. Mˆeme si les multipaths paraissent comme une solution int´eressante pour augmenter le trafic v´ehicul´e sur Internet, son utilisation dans les r´eseaux CCN tel que pr´esent´e par Van Jacobson ne parait pas forc´ement b´en´efique. Ce constat a aussi ´et´e d´emontr´e par Rossini et al. [9]. Il est clair que le mieux pour les r´eseaux CCN est de n’utiliser les chemins les plus longs que pour les cas extrˆemes ou un flot ne peut ˆetre servi par son chemin le plus court `a cause d’une charge maximale dans un lien du chemin, et que le chemin le plus long ne contient aucun lien proche de la surcharge. Nous proposons de maintenir le choix des chemins les plus courts comme choix principal. Si un flot est rejet´e de son chemin le plus court `a cause de la surcharge d’un lien appartenant `a son chemin on peut dans ce cas seulement envisager d’emprunter un chemin secondaire, `a condition que ce chemin n’atteint pas un certain seuil deCHAPITRE 4. STRATEGIES D’ACHEMINEMENT ´ 41 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 hitg P T=0.1 T=0.3 T=0.5 Figure 4.11 – Taux de hit en fonction de la probabilit´e du choix du plus long chemin charge. A B C D chemin congestionn Dtection de congestion Figure 4.12 – Chemin plus longs choisis en cas de congestion uniquement La figure 4.12 montre un exemple de l’utilisation des multipaths dans CCN. Quand un objet se trouve dans le cache D, les Interests suivent le plus court chemin A-B-D. Mais quand le cache D re¸coit l’Interest il ne peut le servir `a travers le chemin inverse car une congestion est d´etect´e. Le flot est alors redirig´e vers le noeud d’avant B qui propose un autre chemin vers le cache D. Le chemin ´etant non congestionn´e le flot emprunte le chemin A-B-C-D. La FIB du noeud B est mise `a jour afin de v´ehiculer tous les paquets Interest du flot vers l’interface menant au noeud C et non pas au noeud D. D’autre part, un routage orient´e contenu est lourd `a mettre en place, une mise `a jour des FIB `a chaque fois qu’un objet est supprim´e d’un cache peut avoir un impact sur plusieurs tables, surtout si les tables enregistrent les paquets et non les objets.Chapitre 5 Simulations et experimentations ´ Nous avons test´e, par simulation et exp´erimentation certains des m´ecanismes que nous avons propos´es. 5.1 Simulations On consid`ere un lien `a 10 Mb/s partag´e entre un flot Poisson `a 5 Mb/s et un ensemble de flots permanents. Les flots sont ordonnanc´es en utilisant le DRR. Le flot de Poisson repr´esente de mani`ere simplifi´ee un ensemble de flots de d´ebit beaucoup plus faible que le d´ebit ´equitable. Les paquets de ce flot sont suppos´es appartenir `a des flots diff´erents. Les flots permanents simul´es sont : – AIMD (7/8) : l’utilisateur final impl´emente un contrˆole de congestion AIMD avec facteur de r´eduction de la fenˆetre CWND β = 7/8 et, pour ce flot, RTT = 10 ms. – AIMD (1/2) : l’utilisateur final impl´emente un contrˆole de congestion AIMD avec facteur de r´eduction de la fenˆetre CWND β = 1/2 et RTT = 200 ms. – CWIN (5) : L’utilisateur final maintient une fenˆetre fixe de 5 packets et RTT = 200 ms. – CWIN (100) : L’utilisateur final maintient une fenˆetre fixe de 100 packets et RTT = 200 ms. – CBR : L’utilisateur final envoie des paquets Interest `a taux fixe correspondant `a un d´ebit constant de paquets data de 4 Mb/s. 42CHAPITRE 5. SIMULATIONS ET EXPERIMENTATIONS ´ 43 Les r´esultats sont r´esum´es dans les tableaux 5.1 et 5.2. On distingue les cas d’une d´etection rapide par l’utilisateur nomm´ee “Rapid” et une d´etection par timeout fix´e `a 1s. On distingue aussi les deux cas avec “Interest discard” ou sans “Interest discard”. Table 5.1 – D´ebits en Mb/s Flow sans discard Interest discard Rapid TO (1s) Rapid TO (1s) AIMD (7/8) 1.20 1.24 1.23 1.31 AIMD (1/2) 1.19 1.10 1.12 0.84 CWIN (5) 0.19 0.19 0.19 0.19 CWIN (100) 1.20 1.24 1.23 1.32 CBR 1.20 1.24 1.23 1.32 Table 5.2 – Taux de rejets et de discard (perte/discard) Flow sans discard Interest discard Rapid TO (1s) Rapid TO (1s) AIMD (7/8) .006/0 .01/0 0/.01 0/.01 AIMD (1/2) .002/0 .003/0 0/.001 0/.003 CWIN (5) .006/0 0/0 0/.0 0/0 CWIN (100) .30/0 .18/0 0/.65 0/.22 CBR .76/0 .75/0 0/.75 0/.74 Les flot agressifs CWIN(100) et CBR ont des d´ebits `a peu pr`es ´egaux au flot TCP(7/8), mais le taux de rejets des data des flot agressifs est tr`es important (30% pour le CWIN(100) et 76% pour CBR) ; les rejets data sont convertis en rejets Interest en utilisant le m´ecanisme Interest Discard. A partir de ces r´esultats, nous recommandons que les utilisateurs choisissent un protocole de transport AIMD agressif avec donc un facteur de r´eduction proche de 1. 5.2 Exp´erimentations 5.2.1 Fair sharing Nous avons utilis´e comme algorithme d’ordonnancement le DDR [22]. Cet algorithme utilise des files virtuelles, chacune correspondant `a un identifiant de flot. A la r´eception d’un paquet, un hash est calcul´e `a partir du nom d’objet, et le paquet est plac´e dans la file correspondante `a cet identifiant. Les files sont impl´ement´ees comme une simple liste chain´ee appel´e ActiveList. Lorsque la file globale atteint une taille maximale, le dernier paquet de la file de flot la plus longue est supprim´e.44 5.2. EXPERIMENTATIONS ´ client serveur ./ccnd video1 @ipB video2 @ipB FIB ./ccnd Content Store video2 video1 Discard de l’interest ou nom? Identifier nom objet et calculer son hash Alimenter les conteurs chaque cycle Round Robin Figure 5.1 – Testbed et interest Discard 5.2.2 Interest discard On impl´emente un compteur pour chaque flot dans l’ActiveList du DRR. Tous les compteurs seront incr´ement´es d’un quantum `a chaque fois que l’ordonnanceur DRR compl`ete un cycle (parcours toutes les files) jusqu’`a une valeur maximale b. A chaque fois qu’un Interest correspondant `a un flot arrive sur la carte r´eseau, le compteur du flot est d´ecr´ement´e d’un quantum. Si un Interest arrive et que le compteur du flot correspondant `a l’Interest est `a z´ero, il faut supprimer l’Interest. 5.2.3 Sc´enarios et r´esultats Nous avons impl´ement´e un ordonnancement DRR [22] ainsi que l’Interest discard dans un r´eseau basique de deux noeuds. Un lien full duplex interconnecte deux machines Linux. Une machine joue le rˆole du serveur et stocke des fichiers de donn´ees, l’autre machine est client, cherchant ces donn´ees. L’ordonnancement est impl´ement´e dans l’espace noyau en utilisant une version modifi´ee du module sch sfq d´evelopp´e par L.Muscariello et P.Viotti [28]. Cette nouvelle impl´ementation permet l’identification des flots par les noms d’objets. L’Interest discard est impl´ement´e dans le noyau, les modifications suivantes ont ´et´e apport´ees : – Cr´eation d’un compteur par flot. – Incr´ementation de tous les compteurs `a chaque cycle DRR. – D´ecr´ementation d’un compteur `a chaque fois qu’un Interest est envoy´e. – Rejet d’un Interest si le compteur est nulle. Au niveau du serveur, nous appliquons un shaping `a 10 Mb/s, lan¸cons le d´emon ccnd, et chargeons des fichiers dans le r´ef´erentiel. Au niveau de la machine cliente, nous lan¸cons le d´emon ccnd, et r´ecup´erons les objets stock´es dans le serveur en utilisantCHAPITRE 5. SIMULATIONS ET EXPERIMENTATIONS ´ 45 deux applications : l’application ccncatchunks2 impl´ement´ee par PARC, et l’application cbr que nous avons d´evelopp´ee pour envoyer les paquets Interest `a un d´ebit constant. La figure 5.2 repr´esente les d´ebits instantan´es dans le cas d’un ordonnancement FIFO, et dans le cas d’un ordonnancement DRR. 0 5 10 0 20 40 60 80 100 rate (Mb/s) FIFO 0 5 10 0 20 40 60 80 100 rate (Mb/s) DRR Figure 5.2 – D´ebits des flot : cbr et ccncatchunks2 Le flot ccncatchunks2 arrive `a avoir son d´ebit maximal en utilisant le Deficit Round Robin, contrairement `a l’ordonnancement par d´efaut tail drop. Les r´esultats des exp´erimentations confirment les simulations. L’Interest Discard permet de convertir les rejets data en rejets Interest, ce qui aide `a conserver la bande passante et `a prot´eger l’op´erateur. sans filtre b = 10 b = 100 perte .42 .002 .005 discard 0 .45 .46 Le tableau ci-dessus montre que l’Interest discard est un m´ecanisme efficace pour ´eviter les rejets data et donc ´eviter un gaspillage de la bande passante.Chapitre 6 Conclusion Dans cette partie, nous avons propos´e un ensemble de m´ecanismes de gestion du trafic pour la proposition CCN. Cet ensemble comprend quatre volets essentiels : – La gestion du partage de bande passante. Grˆace `a l’identification des flots par les noms d’objets, il est d´esormais possible de d´efinir un flot sous CCN. Nous soulignions la n´ecessit´e de s´eparer files d’attente et caches parce qu’ils n’ont pas les mˆemes exigences en termes de taille et de temps de r´eponse. La file d’attente devrait ˆetre de taille petite avec un temps de r´eponse rapide. Par contre les caches sont plus grands mais exigent un temps de r´eponse moins rapide et utilisent typiquement une politique LRU (remplacement de l’objet le moins r´ecemment demand´e). Le partage de bande passante est assur´e au moyen de l’ordonnancement fair queuing (DRR de pr´ef´erence) au niveau flot. – Des m´ecanismes pour utilisateurs. Nous conseillons l’utilisation d’un protocole AIMD adaptatif, pas pour assurer l’´equit´e, qui est r´ealis´ee directement par DRR, mais afin de limiter les pertes et le d´eclenchement de r´e´emissions multiples lourdes `a g´erer. L’utilisateur ne gagne rien en ´etant agressif car le r´eseau partage ´equitablement la bande passante. La d´etection rapide des rejets assure l’efficacit´e du protocole de transport. Nous proposons donc une d´etection rapide de rejets au niveau des routeurs. Si un paquet Interest ne peut ˆetre servi ou si un paquet Data devrait ˆetre rejet´e, un paquet data sans payload est envoy´e vers l’usager. Nous utilisons cette m´ethode car, dans CCN, l’existence de chemins multiples entraine des probl`emes de s´equencement des paquets Data rendant impossible la d´etection rapide de perte en contrˆolant les num´eros de s´equence. L’utilisation de sources multiples engendre en plus des variations importantes du RTT rendant difficile le r´eglage du seuil de Timeout. – Des m´ecanismes pour op´erateurs. Nous proposons un nouveau mod`ele de facturation o`u un usager ou un op´erateur “ach`ete” des paquets de Data en ´emettant 46CHAPITRE 6. CONCLUSION 47 les paquets Interest correspondants. Ce m´ecanisme incite les op´erateurs `a investir dans des ressources r´eseaux afin de pouvoir “vendre” davantage de trafic. Les op´erateurs sont ´egalement motiv´es `a utiliser les caches afin d’´eviter le rachat multiple fois d’un objet populaire. Nous proposons aussi un m´ecanisme d’Interest discard qui limite les rejets Data et permet `a l’op´erateur d’´eviter de demander des paquets Data qui ne peuvent pas ˆetre revendus en aval. – Des strat´egies d’acheminement. Le multicast sous CCN est compatible avec le fair queuing que nous sugg´erons d’utiliser au niveau des routeurs. CCN utilise le multicast comme une partie de la proposition de sorte que deux flux synchronis´es demandant le mˆeme objet ne peuvent le t´el´echarger parall`element sur un lien. Une seule demande est envoy´ee pour les deux flux, ce qui ´evite la division du d´ebit des flux due au fair queuing. Si les demandes ne sont pas synchronis´ees l’utilisation des caches permet de maintenir le d´ebit de t´el´echargement grˆace au stockage temporaire des paquets en cours de t´el´echargement. Par contre l’utilisation du fair queuing peut poser un s´erieux probl`eme en ce qui concerne les multipaths. Le fair queuing annule le comportement du flux multipath coordonn´e et le transforme en un flux multipath non coordonn´e. Une ´equit´e locale par lien est r´ealis´ee mais l’´equit´e globale ne l’est pas car le flux multipath re¸coit plus de d´ebit qu’un flux unipath. Nous corrigeons ce probl`eme par la conception d’un protocole MPRR (multipath Round Robin). Un protocole de type MPTCP est difficile `a r´ealiser sous CCN puisque l’utilisateur n’a aucune visibilit´e sur les chemins utilis´es. Nous proposons donc une gestion par flot plutˆot qu’une gestion par paquet. Il suffit d’observer la charge des liens et de n’accepter aucun nouveau flot sur un chemin long que si la charge des liens est assez faible. Nous avons ´egalement observ´e que l’utilisation de multipaths nuit `a l’efficacit´e des caches dans certains cas. Suite `a nos observations li´es `a la d´egradation du taux de hit global due `a l’utilisation des multipaths, une ´etude des performances des caches est n´ecessaire, car la gestion du trafic en d´epend. Cette ´etude est l’objet de la prochaine partie.Deuxi`eme partie Performances des caches 48Chapitre 7 Introduction 7.1 Probl´ematique Dans ce chapitre, nous traitons le probl`eme de la performance des caches dans les r´eseaux orient´es contenus. Compte tenu des modifications majeures `a apporter aux r´eseaux dans le cas o`u une mise en oeuvre de CCN est envisag´ee (mise `a jour des caches, protocoles, m´emoires distribu´ees), il est important de mesurer le gain apport´e par cette architecture. Il est primordial de mesurer la quantit´e et la mani`ere dont arrivent les objets. Les conclusions que nous pouvons tirer d’une ´etude de performances d´epend de la popularit´e des objets arrivant aux caches, et de la taille des catalogues. Nous souhaitons apporter des conclusions pratiques en utilisant des donn´ees r´eelles. On note que la diffusion de contenus repr´esente 96% du trafic Internet. Ce contenu est constitu´e d’un mix de donn´ees. Nous avons alors mis en place une ´evaluation d’une hi´erarchie de caches `a deux niveaux en utilisant un mix de flux refl´etant un ´echange r´eel de donn´ees sur Internet. 7.2 Etat de l’art 7.3 Contributions Dans cette partie, on ´evalue le taux de hit, pour une hi´erarchie de caches `a deux niveaux, avec un mix de flux r´eel. Ceci en utilisant un mod`ele simple permettant d’effectuer des calculs rapides pour des tailles importantes de cache. Ce mod`ele, pr´ec´edemment propos´e dans la litt´erature, a ´et´e test´e, v´erifi´e, et d´emontr´e math´ematiquement. Des simulations ont ´et´e effectu´ees pour confirmer son exactitude. Nous avons effectu´e 4950 7.3. CONTRIBUTIONS les calculs en utilisant un mix de flux refl´etant le partage actuel du trafic sur Internet. Nous proposons un stockage des contenus VoD au niveau des routeurs d’acc`es, vu leur volume faible par rapport aux autres types de donn´ees. Les autres types devraient ˆetre stock´es dans un cache tr`es volumineux, probablement constituant un deuxi`eme niveau de caches.Chapitre 8 Mesure du trafic et performances des caches Pour estimer les taux de hit d’une architecture `a deux niveaux, il est primordial de mesurer les caract´eristiques du trafic, car les taux de hit d´ependent fortement de la nature du trafic et de son volume. 8.1 Mesure du trafic Nous pr´esentons les caract´eristiques du trafic Internet, et nous discutons des param`etres les plus importants pour nos ´evaluations. 8.1.1 Types de contenu Le “Cisco Visual Networking Index” publi´e en 2011 [29] classifie le trafic Internet et la demande globale pr´evue pour la p´eriode 2010-2015. 96% du trafic repr´esente le transfert de contenus susceptibles d’ˆetre stock´es dans les m´emoires cache. On peut les classifier en quatre cat´egories : – Donn´ees web : Ce sont les pages web visit´ees par les internautes. – Fichiers partag´es : G´en´eralement g´er´es par des protocoles pair `a pair, cr´eant une communaut´e d’entraide : Un utilisateur (leecher) peut t´el´echarger un fichier stock´e dans une des machines des autres utilisateurs (seeders). D`es que son t´el´echargement est termin´e, le leecher devient `a son tour seeder. Les r´eseaux pair `a pair rencontrent de plus en plus de probl`emes `a cause de la violation des droits 5152 8.1. MESURE DU TRAFIC d’auteur par leurs utilisateurs. Ces derniers peuvent mettre en t´el´echargement du contenu ill´egal. R´ecemment, `a titre d’exemple, le site Demonoid n’est plus disponible, probablement `a cause de la violation des droits d’auteur. – Contenu g´en´er´e par les utilisateurs (UGC) : C’est un ensemble de contenus g´en´er´es par les utilisateurs, ou directement mis `a disposition par ces derniers. La communaut´e utilisant ce partage utilise des logiciels libres, des contenus avec des licences de droit d’auteur flexibles, permettant des ´echanges simples entre des utilisateurs, mˆeme ´eloign´es g´eographiquement. A la diff´erence des r´eseaux pair `a pair, les donn´ees sont sauvegard´ees sur les serveurs priv´ees du fournisseur de contenu. Il d´etient alors la possibilit´e de v´erifier les contenus charg´es par les utilisateurs avant leur publication. – Vid´eo `a la demande (VoD) : C’est une technique de diffusion de donn´ees permettant `a des utilisateurs de commander des films ou ´emissions. La t´el´evision sur IP est le support le plus utilis´e. Le service VoD est propos´e g´en´eralement par des fournisseurs d’acc`es Internet, et il est dans la plupart des cas payant. Le contenu propos´e est lou´e pour une p´eriode donn´ee, assurant ainsi le respect des droits num´eriques. Les proportions du trafic sont indiqu´es dans le tableau 8.1. Fraction du trafic (pi) taille de la taille moyenne 2011 2015 population(Ni) des objets (θi) Web .18 .16 1011 10 KB File sharing .36 .24 105 10 GB UGC .23 .23 108 10 MB VoD .23 .37 104 100 MB Table 8.1 – Les caract´eristiques des contenus du trafic Internet 8.1.2 La taille des contenus et des objets – Web : La soci´et´e Netcraft 1 publie chaque mois le nombre de sites, estim´e grˆace `a un sondage fait aupr`es de soci´et´es d’h´ebergement et d’enregistrement des noms de domaine. Elle estime le nombre de sites actifs `a 861 379 152, en consid´erant la moyenne de nombre de pages par site `a 273 2 nous comptons plus de 2 ∗ 1011 pages web. Pour notre ´etude, on suppose que le nombre de pages web est de 1011 et leur taille moyenne est de 10KB [30]. – Fichiers partag´es : On estime le nombre de fichiers partag´es grˆace aux statistiques relev´ees sur le site Demonoid3 `a 400 000 fichiers de taille moyenne de 7.4 GB. Nous arrondissons ces chiffres dans le tableau 8.1. 1http ://news.netcraft.com/archives/category/web-server-survey/ 2http ://www.boutell.com/newfaq/misc/sizeofweb.html 3www.demonoid.me/CHAPITRE 8. MESURE DU TRAFIC ET PERFORMANCES DES CACHES 53 – UGC : Les contenus UGC sont domin´es par Youtube. Une ´etude r´ecente, faite par Zhou et al. [31], estime le nombre de vid´eos Youtube `a 5 × 108 de taille moyenne de 10 MB. Actuellement avec une simple recherche du mot clef ”a” sur Youtube nous comptons plus de 109 vid´eos. – VoD : Les vid´eos `a la demande sont estim´ees `a quelques milliers et sont de taille moyenne de 100 MB. Ce sont sans doute des sous-estimations avec l’essore r´ecente de certaines applications VoD mais elles sont suffisamment pr´ecises pour les ´evaluations pr´esent´ees dans la suite. 8.1.3 Distribution de la popularit´e La distribution de la popularit´e est un des ´el´ements essentiels du calcul des performances d’un cache. – Web : La popularit´e des pages web suit g´en´eralement la loi de Zipf : le taux de demandes q(n) pour le ni´eme objet le plus populaire est proportionnel `a 1/nα. Selon [32] et [30] le param`etre α varie entre 0.64 and 0.83. – Fichiers partag´es : Il est possible de calculer la popularit´e des torrents en utilisant les statistiques extraites du site Demonoid. En entrant un mot clef, on peut classer les torrents d’une mani`ere d´ecroissante suivant le nombre de t´el´echargements en cours (mais le site ne permet l’affichage que des 10 000 premiers et les 10 000 derniers torrents). La loi de popularit´e correspond `a peu pr`es `a une loi de Zipf de param`etre α ´egal 0.82. On estime que la popularit´e du site PirateBay suit une loi de Zipf de param`etre 0.75. On trace la popularit´e des vid´eos partag´es pour deux sites ”PirateBay” et ”torrentreactor” 4 . Apr`es une recherche par mot clef, les sites affichent les vid´eos et le nombre de leechers correspondants. En choisissant comme mot clef la seule lettre ”a”, et apr`es un tri d´ecroissant du nombre de leechers, nous tra¸cons les popularit´es pr´esent´ees dans 8.1(a) et 8.1(b). Pour le site torrentreactor, la popularit´e suit la loi Zipf(0.75) pour les premiers rangs, puis la courbe s’incline et suit une loi Zipf(1.2) pour la queue de la loi. La mˆeme observation concerne le site PirateBay. – UGC : Les flux UGC suivent une loi de Zipf avec α estim´e `a 0.56 [11] ou `a 0.8 [13]. Des travaux r´ecents de Carlinet et al. [33] sugg`erent plutˆot une loi Zipf(0.88). – VoD : L’´etude de Carlinet et al. ´evalue ´egalement les VoD. La loi de popularit´e n’est pas de Zipf, mais une combinaison de deux lois de Zipf. La premi`ere est de param`etre 0.5 pour les 100 objets les plus populaires, la deuxi`eme est de param`etre 1.2 pour les objets suivants. Des statistiques ´etudi´ees par Yu et al. [34] pour un service VoD en Chine sugg`erent une loi de Zipf avec α variant ente 0.65 et 1. 4http ://www.torrentreactor.net54 8.2. LE TAUX DE HIT D’UN CACHE LRU 1 10 100 1000 10000 100000 1 10 100 1000 10000 nombre de leechers Zipf(0.75) (a) torrentreactor 1 10 100 1000 10000 1 10 100 1000 rang nombre de leechers Pirate Bay Zipf(0.7) (b) Pirate Bay Figure 8.1 – La popularit´e des vid´eos partag´ees sur torrentreactor et Pirate Bay 8.2 Le taux de hit d’un cache LRU 8.2.1 Independent Reference Model Afin d’utiliser les mod`eles math´ematiques, on consid`ere g´en´eralement un ensemble d’objets ayant des popularit´es fixes, ainsi qu’un catalogue d’objets fixe. C’est le mod`ele dit “independance reference model” ou IRM. En r´ealit´e, les objets changent de popularit´e et les catalogues ne cessent d’augmenter. Une prise en compte d’une telle complexit´e ne peut ˆetre r´esolue par mod`ele math´ematique, et est tr`es complexe `a simuler. Cependant, la variance des popularit´es est n´egligeable par rapport au temps de remplissage d’un cache. On peut consid´erer que les mod`eles sont applicables sur un intervalle de temps o`u les popularit´es et les catalogues seront approximativement fixes. Afin d’appliquer ce mod`ele math´ematique, il faut aussi que les requˆetes soient ind´ependantes. Ceci est vrai si des demandes arrivent d’un grand nombre d’utilisateurs agissant de fa¸con ind´ependante. Ces conditions s’appliquent pour un premier niveau de cache. Mais pour les niveaux sup´erieurs, la corr´elation des demandes invalide le mod`ele IRM. Cependant, selon Jenekovic et Kang [35], la corr´elation des demandes qui d´ebordent du premier niveau d’un simple r´eseau de caches `a deux niveaux, a un faible effet sur la probabilit´e de hit observ´ee. Nous avons d’ailleurs v´erifi´e par simulation l’effet de la corr´elation des demandes pour un r´eseau de caches en arbre. Pour conclure, les mod`eles math´ematiques bas´es sur l’IRM peuvent ˆetre appliqu´es pour les r´eseaux CCN, car la popularit´e des objets varient d’une mani`ere faible par rapport `a la vitesse de remplissage des caches et l’ind´ependance est respect´ee.CHAPITRE 8. MESURE DU TRAFIC ET PERFORMANCES DES CACHES 55 8.2.2 Les mod`eles analytiques Une politique de remplacement LFU (least frequently used) reste la politique id´eale ; mais, il est impossible de mettre en place cet id´eal car la popularit´e des objets est en g´en´eral inconnue. Van Jacobson propose un ordonnancement LRU (least recently used) dans tous les caches mˆeme si plusieurs travaux remettent en question les performances r´eseau avec une utilisation exclusive de LRU. Les ´etudes de performance des r´eseaux CCN n´ecessitent l’utilisation de mod`eles math´ematiques afin de confirmer et de g´en´eraliser les observations tir´ees des simulations et exp´erimentations. Notre objectif, qui est d’´evaluer la performance pour les tr`es grandes populations (jusqu’`a 1011 pages web, par exemple) et leur m´elange, n’est pas envisageable par simulation. Les mod`eles exacts sont tr`es complexes, mˆeme dans le cas basique d’un seul cache. La complexit´e de ces mod`eles croit d’une fa¸con exponentielle avec la taille des caches et le nombre d’objets. Il est donc plus int´eressant de cr´eer des mod`eles simplifi´es bas´es sur des approximations. La majorit´e des mod`eles ont ´et´e con¸cus pour une politique de remplacement LRU avec le mod`ele dit IRM (Independent Reference Model). Quelques travaux r´ecents ont trait´e cette probl´ematique. En effet, G. Carofiglio et al. [36] proposent un mod`ele g´en´eralis´e dans le cas d’un r´eseau de caches (architecture en arbre) ; ce mod`ele se limite aux cas d’arriv´ees suivant un processus de Poisson et une loi de popularit´e de type Zipf avec α > 1. Ce mod`ele s’applique `a la mise en cache par paquet (comme CCN) et prend en compte la d´ependance entre les paquets data d’un mˆeme objet. Un autre mod`ele pour les r´eseaux de caches a ´et´e propos´e par E.Rosensweig et al. [37] ; c’est un mod`ele adapt´e `a toute architecture. Cependant, la complexit´e du calcul du taux de hit, dˆu `a Dan et Towsley [38], limite cette approche `a des r´eseaux et des populations de taille relativement faible. 8.2.3 La formule de Che Nous pensons qu’une mise en cache par objet est plus simple `a d´eployer et `a utiliser qu’une mise en cache par paquet. La proposition de Che et al. [39] est particuli`erement int´eressante. Hormis sa facilit´e d’utilisation par rapport aux autres mod`eles, sa grande pr´ecision a ´et´e d´emontr´ee dans plusieurs cas. On consid`ere un cache de taille C, des objets appartenant `a un catalogue de taille M arrivent au cache suivant une loi de popularit´e pop(n) proportionnelle `a q(n). Sous un syst`eme conforme au mod`ele IRM, la probabilit´e de hit h(n) d’un objet n selon l’approximation de Che est estim´ee `a : h(n) = 1 − e −q(n)tc , (8.1) o`u tc est la solution de l’´equation : C = X n (1 − e −q(n)tc ). (8.2)56 8.2. LE TAUX DE HIT D’UN CACHE LRU Cette approximation est centrale pour le reste du travail. Voici quelques ´el´ements expliquant sa pr´ecision et sa validit´e comme mod`ele math´ematique. On note Tc(n) le temps o`u exactement C objets diff´erents de n ont ´et´e demand´es. On suppose une premi`ere demande de l’objet n faite `a l’instant 0, la prochaine requˆete pour l’objet n a lieu `a τn, cette demande est un hit si τn < Tc(n). La probabilit´e de hit de l’objet n peut ˆetre exprim´ee par : h(n) = P(τn < Tc(n)). (8.3) Che et al. ont mesur´e par simulation Tc(n) et ont observ´e qu’il est presque d´eterministe et montre une tr`es faible variation en fonction du rang mˆeme pour des catalogues petits (catalogue de 10 000 objets). Cette variable est presque ind´ependante de l’objet n et est caract´eristique au catalogue On pose alors E(Tc(n)) = tc que Che et al consid`erent comme le “temps caract´eristique” du cache. Puisque les arriv´ees de requˆetes suivent un processus de Poisson, le temps inter-arriv´ee τn suit une loi exponentielle de param`etre q(n). On a donc la probabilit´e de hit h(n) de l’objet n, en r´e´ecrivant (8.3 : h(n) = P(τn < tc) = 1 − exp(−q(n)tc) . Dans l’intervalle [0,tc], nous avons exactement C arriv´ees sans compter l’objet n. Donc, `a cet instant pr´ecis, parmi les M objets du catalogue, C objets exactement sont arriv´es au cache `a l’instant tc, sans compter l’objet n. Ceci peut ˆetre exprim´e par : X M i=1,i6=n P(τi < tc) = C o`u τi est le temps s´eparant le d´ebut de l’observation t = 0 du temps d’arriv´ee de la demande de l’objet i au cache donc exponentielle de paramˆetre q(i). Cette ´equation permet de calculer le temps caract´eristique des caches tc. Mais pour plus de facilit´e, l’´equation devient : PM i=1 P(τi < tc) = C. Ceci est valable si la popularit´e individuelle de l’objet est relativement petite par rapport `a la somme des popularit´es. En utilisant le fait que τi est de loi exponentielle de param`etre q(i), l’´equation devient l’´equation (8.2), C = PM i=1(1 − e −q(i)tc ). L’approximation n’est pas seulement pr´ecise dans le cas, envisag´e par Che et al, d’un grand cache et d’une population importante, mais ´egalement pour des syst`emes tr`es petits. Nous avons v´erifi´e la validit´e de l’approximation par simulation, pour un seul cache de taille 104 et une loi Zipf(0.8) ou un cache de taille 16 et une loi g´eom´etrique Geo(0.5). La figure 8.2 montre la pr´ecision de l’approximation et sa validit´e mˆeme dans le cas d’un petit cache. Pour calculer le h(n), il faut d’abord trouver le tc qui est le z´ero de l’´equation (8.2). Pour trouver le z´ero de cette ´equation on utilise la m´ethode de Newton : On peut trouver une valeur proche du z´ero d’une fonction f(x) en calculant successivementCHAPITRE 8. MESURE DU TRAFIC ET PERFORMANCES DES CACHES 57 0 0.2 0.4 0.6 0.8 1 1 100 10000 hit rate cache size (objects) 0 0.2 0.4 0.6 0.8 1 1 4 16 cache size (objects) Figure 8.2 – Taux de Hit en fonction de la taille du cache en utilisant l’approximation de Che : `a gauche, N = 104 , popularit´e de Zipf(.8) , rangs 1, 10, 100, 1000 ; `a droite, N = 16, popularit´e geo(.5), rangs 1, 2, 4, 8. une suite de valeurs xi jusqu’`a l’obtention d’une approximation satisfaisante. xi+1 est calcul´e `a partir de la valeur de xi : xi+1 = xi − f(xi) f ′(xi) . (8.4) Le x0 est choisi arbitrairement et on calcule x1 en utilisant la formule 8.4. On recalcule f(x1) et si f(x1) est suffisamment proche de z´ero, x1 est alors le z´ero de f(x). Sinon on calcule x2,... Nous constatons que la convergence est extrˆemement rapide. 8.3 Autres politiques de remplacement 8.3.1 Le cache Random 8.3.1.1 Relation entre taux de hit et temps moyen de s´ejour On consid`ere un cache de taille C utilisant une politique de remplacement Random. Dans cette politique, lorsqu’il faut lib´erer de la place pour cacher un nouveau contenu, le contenu `a ´eliminer est choisi au hasard. La taille du catalogue est M. On note Ts(n) le temps de s´ejour de l’objet n. On commence nos observations sur des simulations pour un catalogue de taille petite (100 objets), et un cache de 50 objets. Nous ´etudions le cas des objets arrivant suivant une loi Zipf(0.6) et Zipf(1.2). Les requˆetes arrivent avec un taux de 100 requˆetes/s. On lance la simulation pour 1 000, 10 000 et 100 000 it´erations. On trace dans ces trois cas la moyenne du temps de s´ejour Ts(n) en fonction de n (voir figure 8.3). On remarque que, plus le nombre d’it´erations augmente, plus la moyenne du temps de s´ejour tend vers une valeur pr´ecise. Cette valeur est la mˆeme quelque soit le rang. En se basant sur cette observation, on consid`ere que la valeur du temps de s´ejour est ind´ependante de n (adoptant la mˆeme approximation que Che). Le Ts est fixe quand58 8.3. AUTRES POLITIQUES DE REMPLACEMENT 0 1000 2000 3000 4000 5000 6000 0 10 20 30 40 50 60 70 80 90 100 Ts rang 1000 iteration 10000 iterations 100000 iterations (a) Zipf(0.6) 0 2000 4000 6000 8000 10000 12000 0 10 20 30 40 50 60 70 80 90 100 Ts rang 1000 iteration 10000 iterations 100000 iterations (b) Zipf(1.2) Figure 8.3 – Temps de s´ejour en fonction du rang pour un cache Random le temps de simulation devient grand, car tout objet du cache a la mˆeme probabilit´e que les autres objets d’ˆetre ´elimin´e. Son ´elimination d´epend surtout du taux de miss du cache qui devient fixe et stable apr`es un certain temps de simulation. Nous appliquons la formule de Little. La probabilit´e de hit d’un objet i est exprim´ee par : h(n) = λ(n)Ts(n) o`u Ts(n) est la moyenne du temps de s´ejour de l’objet n. Ts(n) ´etant fixe et ind´ependant de n on pose Ts(j) = Ts ∀j. Le taux d’entr´ee dans le cache est λ(n) = (1 − h(n))pop(n) o`u pop(n) est la popularit´e normalis´ee de l’objet n. On obtient alors : h(n) = (1 − h(n))pop(n)Ts Finalement h(n) peut ˆetre exprim´e par : h(n) = pop(n)Ts 1 + pop(n)Ts . (8.5) La moyenne du temps de s´ejour peut ˆetre calcul´ee en utilisant l’´equation suivante (comme dans le cas d’un cache LRU) : X M i=1 h(i) = X M i=1 pop(i)Ts 1 + pop(i)Ts = C. (8.6) L’´equation (8.6) peut ˆetre r´esolue avec la m´ethode de Newton. Nous utilisons la valeur Ts retrouv´ee dans l’´equation (8.5) pour d´eterminer les h(n). Les valeurs h(n) trouv´e par calcul et h(n) trouv´e par simulation sont compar´ees dans la Figure 8.4 pour diff´erentes valeurs de taille de cache et pour les deux lois, Zipf(0.6) et Zipf(1.2) et pour diff´erentes tailles de cache : c = C/M = 0.3, 0.5, 0.7.CHAPITRE 8. MESURE DU TRAFIC ET PERFORMANCES DES CACHES 59 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 10 20 30 40 50 60 70 80 90 100 hit rang simulation c=0.5 simulation c=0.3 simulation c=0.7 calcul c=0.5 calcul c=0.3 calcul c=0.7 (a) Zipf(0.6) 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 10 20 30 40 50 60 70 80 90 100 hit rang simulation c=0.5 simulation c=0.3 simulation c=0.7 calcul c=0.5 calcul c=0.3 calcul c=0.7 (b) Zipf(1.2) Figure 8.4 – Taux de hit en fonction du rang pour un cache Random 8.3.1.2 Approximation de Fricker Dans Fricker, Robert and Roberts [40], l’approximation suivante est donn´ee : Ts ≃ P τC j6=n q(j) , (8.7) o`u τC est une constante. On va discuter de la validit´e de cette approximation. Le temps de s´ejour d’un objet n peut ˆetre exprim´e, comme repr´esent´e dans la figure 8.5, par une somme de temps tj o`u tj est la dur´ee entre deux requˆetes successives. Arrivee de l’objet n Temps de sejour de l’objet n t1 t3 ti t2 Arrivee de l’objet n sortie de l’objet n Figure 8.5 – Repr´esentation du temps de s´ejour A chaque arriv´ee au cache, l’objet n peut ˆetre retir´e du cache avec une probabilit´e de 1/C si l’objet arriv´e n’appartient pas d´ej`a au cache. On suppose que toute nouvelle arriv´ee au cache implique une mise `a jour mˆeme si cette arriv´ee est un hit. Soit n fix´e. Calculons le temps de s´ejour Ts(n). Tout objet i arrive au cache suivant un processus de Poisson de taux q(i). Les temps inter-arriv´ees Zi sont des variables al´eatoires ind´ependantes de loi exponentielle de param`etre q(i). La prochaine requˆete susceptible de retirer l’objet n du cache se passe `a un temps Xn1 Xn1 = inf i6=n (Zi). (8.8)60 8.3. AUTRES POLITIQUES DE REMPLACEMENT Donc Xn1 suit une loi exponentielle de param`etre P i6=n q(i). Comme la politique de remplacement est Random, on en d´eduit facilement que Ts(n) = X Y j=1 Xnj (8.9) o`u Xnj est de loi exponentielle de param`etre P i6=n q(i), et Y est de loi g´eom´etrique de param`etre 1 − 1/C sur N∗ , ind´ependant de (Xnj )j≥1. D’o`u, en passant `a l’esp´erance dans l’´equation (8.9), Ts(n) = X +∞ i=1 P(Y = i) X i k=1 E(Xnk). (8.10) Or, E(Xnk) = 1/ X j6=n q(j), et comme Y suit une loi g´eom´etrique de param`etre 1 − 1/C sur N∗ , il vient que E(Y ) = C. En effet, une v.a. de loi g´eom´etrique de param`etre a sur N∗ est de moyenne 1/(1−a). En reportant dans l’´equation (8.10 le temps de s´ejour moyen peut donc ˆetre exprim´e par : Ts(n) = E(Y ) P j6=n q(j) = C P j6=n q(j) . Revenons `a l’approximation (8.7). L’id´ee sous-jacente dans [40] est qu’on peut approximer le temps de s´ejour de n en supposant que toute arriv´ee mˆeme un hit implique une mise `a jour. Cela revient `a supposer que tous les objets autres que n sont hors du cache. Intuitivement, cela est justifi´e si 1) le cache est petit devant la taille du catalogue, 2) les objets les plus populaires sont hors du cache car ce sont eux qui contribuent le plus `a P j6=n q(j). Cette deuxi`eme condition n’est pas du tout naturelle. On va voir, en tra¸cant les diff´erentes approximations du taux de hit, que cela est vrai pour une loi de popularit´e de Zipf de param`etre α < 1 o`u les objets ont des popularit´es plus voisines que pour α > 1 o`u les objets les plus populaires sont dans le cache avec forte probabilit´e. 8.3.1.3 Approximation de Gallo Gallo et al [41] ont propos´e une approximation pour le taux de hit pour une valeur de α > 1. La probabilit´e de miss d’un objet i est approxim´ee quand C est grand par :CHAPITRE 8. MESURE DU TRAFIC ET PERFORMANCES DES CACHES 61 M iss(i) = ραi α Cα + ραi α o`u ρα =  π α sin( π α ) α . Cela revient `a hitg(i) = 1 − M iss(i) ≈ 1 ρα(i/C) α + 1 . Donc tout calcul fait, le temps de s´ejour devrait ˆetre proportionnel `a  C ∗ sin( π α ) π α α pour α > 1. On compare l’approximation du taux de hit avec l’approximation de Gallo et al [41] hitg pour des valeurs de α > 1 pour un catalogue de M = 20 000. Voir Figure 8.6. On remarque que les deux approximations sont proches pour des valeurs de caches mˆemes petites (C ≥ 20). 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1 10 100 1000 10000 100000 hit rang hitG hitF α = 1.2 α = 1.5 α = 1.7 (a) C=20 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1 10 100 1000 10000 100000 hit rang hitG hitF α = 1.2 α = 1.5 α = 1.7 (b) C=100 Figure 8.6 – Comparaison des taux de hit avec l’approximation de Fricker et Gallo 8.3.2 Le cache LFU Le cache LFU ne stocke que les objets les plus populaires. Donc, la probabilit´e de hit LFU peut ˆetre calcul´ee, pour un catalogue de taille M et pour un cache LFU de taille  C objets : hit(i) = 1; 0 ≤ i ≤ C, hit(i) = 0;i > C.62 8.3. AUTRES POLITIQUES DE REMPLACEMENT La probabilit´e de hit globale d’un cache LFU peut donc ˆetre exprim´ee par : hitg = X C i=1 pop(i) o`u pop(i) est la popularit´e normalis´ee de l’objet i. Pour une loi de Zipf, la popularit´e normalis´ee de l’objet i peut ˆetre exprim´ee par : pop(i) = 1/iα PM k=1 1/kα Donc la probabilit´e globale de hit pour un cache LFU peut ˆetre exprim´ee par : hitg = PC i=1 1/iα PM i=1 1/iα . Soit i un entier et t un r´eel tel que i ≤ t ≤ i + 1. Pour α > 0, on a : 1 (i + 1)α < 1 t α < 1 i α. Donc, 1 (i + 1)α < Z i+1 i 1 t α dt < 1 i α , d’o`u (M + 1)1−α − 1 1 − α < X M i=1 1 i α < M1−α 1 − α et (C + 1)1−α − 1 1 − α < X C i=1 1 i α < C 1−α 1 − α . Puisque le nombre d’objets est grand, nous consid´erons M + 1 ≈ M. Nous utilisons des caches d’au moins quelques centaines d’objets donc, C + 1 ≈ C nous concluons que : X M i=1 1 i α ≈ M1−α 1 − α et X C i=1 1 i α ≈ C 1−α 1 − α . (8.11) La probabilit´e de hit global pour un cache LFU peut ˆetre exprim´ee par : hitg =  C M 1−α ,CHAPITRE 8. MESURE DU TRAFIC ET PERFORMANCES DES CACHES 63 8.3.3 Comparaison des politiques de remplacement On compare les deux politiques de remplacement LRU et Random en fonction du rang, pour des valeurs de α = 0.6 et α = 1.2, et pour un cache de 50% la taille du catalogue. On fixe le catalogue M = 106 objets. Il est clair que la politique LRU est plus performante que Random. On remarque aussi que l’´ecart entre LRU et Random est r´eduit pour un α = 1.2, ce qui est confirm´e par l’´etude de Gallo et al. [41]. Cet ´ecart se r´eduit de plus en plus quand α grandit. Mais pour une comparaison effective, il est imp´eratif de comparer le taux de hit global des caches Random, LRU et LFU. 0 0.2 0.4 0.6 0.8 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 hitg c LRU LFU Random (a) Zipf(0.6) 0 0.2 0.4 0.6 0.8 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 hitg c LRU LFU Random (b) Zipf(1.2) Figure 8.7 – Taux de hit global en fonctions des tailles de cache normalis´e On remarque que la diff´erence des performances des caches est plus grande et visible dans le cas d’un Zipf(0.6). Cette diff´erence diminue pour un α = 1.2, non seulement entre LRU et Random, mais aussi LFU. Les caches deviennent aussi plus efficaces. Or, selon notre ´etude bibliographique et les statistiques tir´ees de certains sites fournisseurs de donn´ees, on sait que le α est g´en´eralement < 1. La politique LFU dans ce cas s’´eloigne largement de LRU et Random. Mais un petit ´ecart est `a noter entre les deux politiques de remplacement LRU et Random.Chapitre 9 Les performances des hierarchies de caches ´ 9.1 Caract´eristiques d’une hi´erarchie de caches Pour ´evaluer les performances des hi´erarchies de caches, il est important de pr´eciser ses caract´eristiques. Une hi´erarchie de caches est diff´erente d’une autre si un ou plusieurs de ces caract´eristiques sont diff´erentes. 9.1.1 Politique de remplacement La fonction d’un algorithme de remplacement est de choisir un contenu `a remplacer dans un cache quand le cache est plein, et qu’un nouveau contenu doit ˆetre enregistr´e. Un algorithme optimal ´elimine le contenu qui serait le moins utilis´e. Pour ceci, l’´evolution des popularit´es des objets devrait ˆetre connue. Puisque la variation des popularit´es des objets se produit sur un temps beaucoup plus grand que le temps n´ecessaire pour remplir un cache, les pr´edictions futures peuvent se baser sur le comportement pass´e ; ce qu’on appelle principe de localit´e. On trouve diff´erentes politiques de remplacement – LRU (Least Recently Used) : cet algorithme remplace le contenu utilis´e le moins r´ecemment. Il se base sur le principe de localit´e temporelle. Un objet tr`es populaire sera demand´e plus rapidement qu’un objet moins populaire. L’impl´ementation de cette politique est simple. Il suffit d’attribuer `a chaque objet du catalogue un hash, le hash correspond `a une case permettant de renseigner l’adresse de l’objet recherch´e (si l’objet n’existe pas, l’adresse correspond `a NULL). Des pointeurs permettent de relier les objets et de sauvegarder l’ordre des objets. 64CHAPITRE 9. LES PERFORMANCES DES HIERARCHIES DE CACHES ´ 65 – LFU (Least Frequently Used) : cet algorithme remplace le contenu le moins fr´equemment utilis´e. Il est optimal pour des popularit´es fixes, mais les variations des popularit´es des objets le rend moins efficace. Si les variations des popularit´es sont lentes, LFU est un bon algorithme de remplacement. De plus, il est facile `a impl´ementer, il suffit d’attribuer `a chaque contenu le nombre de fois o`u il a ´et´e demand´e. Par contre, son impl´ementation mat´erielle serait coˆteuse, car un compteur devrait ˆetre attribu´e `a chaque contenu. – Random : Cet algorithme remplace un contenu au hasard, il ne demande aucun enregistrement d’information, mais il est moins performant que LRU. – MRU (Most recently used) : Cette politique ´elimine le contenu correspondant `a la donn´ee la plus r´ecemment demand´ee. Cette politique s’av`ere efficace comme politique de deuxi`eme niveau dans le cas d’une hi´erarchie de caches. Gallo et al [41] ont d´emontr´e, par simulation et par calcul, que la diff´erence entre les performances observ´ees entre un cache LRU et Random ne sont pas importantes, et surtout pour des popularit´es d’objets suivant une loi de Zipf avec α > 1 (α = 1.7). Nous avons simul´e des caches LRU et Random avec une loi Zipf (0.6), le constat reste le mˆeme. La diff´erence constat´ee entre probabilit´e de hit obtenue avec LRU et celle obtenue avec Random est faible. Mais cette diff´erence atteint 16% dans certains cas. Cette diff´erence, mˆeme n´egligeable, peut r´eduire l’utilisation de la bande passante d’une mani`ere importante. 9.1.2 Les politiques de meta-caching – LCE(Leave Copy Everywhere ) : Les objets sont copi´es `a chaque cache travers´e. – Fix [42] : Cette politique consiste `a mettre dans le cache un objet selon une probabilit´e fixe. – LCD(Leave Copy Down) [42] : Copier uniquement dans le cache suivant. Selon Laoutaris, cet algorithme offre les meilleurs r´esultats dans tous les cas ´etudi´es, et donc parait le plus prometteur de tous. – ProbCache [43] : Un objet est copi´e dans un cache suivant une probabilit´e calcul´ee en se basant sur le nombre de sauts travers´es. Psaras et al. pr´esentent des r´esultats remettant en cause LCD comme meilleur algorithme de metacaching, mais la diff´erence des performances reste petite entre les deux algorithmes. D’autre part, Rossini el al. [44] constatent que, inversement, LCD offre de meilleurs r´esultats. – WAVE [45] : c’est un algorithme de meta-caching orient´e chunk. Il est similaire `a LCD, sauf que des variables sont utilis´ees pour contrˆoler le stockage des donn´ees selon leur popularit´e. Les objets peu populaires ont peu de chance de traverser tous les caches menant au demandeur. Cet algorithme semble plus complexe que LCD, par opposition `a LCD qui stocke naturellement les objets les plus populaires tout pr`es des utilisateurs.66 9.1. CARACTERISTIQUES D’UNE HI ´ ERARCHIE DE CACHES ´ – Btw [46] : Cet algorithme se base sur le stockage des donn´ees uniquement dans les noeuds pertinents du r´eseau, c’est-`a-dire ayant la probabilit´e la plus ´elev´ee d’aboutir `a un hit pour les objets demand´es. Plusieurs ´etudes mettent en valeur la politique LCD `a cause de son efficacit´e constat´ee par les ´etudes comparatives, mais aussi par sa simplicit´e par rapport aux autres politiques. L’´etude r´ecente de Rossini et al. [44] confirme l’efficacit´e de LCD par rapport aux autres politiques propos´ees. Dans cette perspective, Laoutaris et al. ont pr´esent´e une ´etude portant sur une hi´erarchie LCD [47] ; cette ´etude commence par une comparaison entre plusieurs politiques de meta-caching. La politique LCD semble ˆetre la meilleure avec MCD (Move copy down). Cette ´etude pr´esente aussi un mod`ele analytique pour calculer num´eriquement le taux de hit pour une hi´erarchie LCD `a deux niveaux. La probabilit´e de hit au premier niveau d’un objet pour une hi´erarchie de caches LCD est estim´ee `a : h1(i) = exp(λi ∗ τ1 − 1)/exp(λiτ1) + exp(λi ∗ τ2) exp(λi ∗ τ2) − 1 o`u τ1 et τ2 repr´esentent les temps caract´eristiques des caches au premier et au deuxi`eme niveau ; la probabilit´e de hit au premier niveau d´epend de la taille du cache au deuxi`eme niveau. La probabilit´e de hit au deuxi`eme niveau vient directement de la formule de Che pour LCE, en supposant les arriv´ees au deuxi`eme niveau ind´ependantes. h2(i) = 1 − exp(−λi ∗ M iss1(i) ∗ τ2) o`u M iss1(i) est le taux de miss de l’objet i au premier niveau de caches. Les temps caract´eristiques sont calcul´es en uti P lisant la formule : i h(i) = C o`u C est la taille du cache. Cette ´equation peut ˆetre utilis´ee au premier niveau comme au deuxi`eme niveau de cache. Nous obtenons alors deux ´equations `a deux inconnues, τ1 et τ2. On r´esout ces ´equations en utilisant la m´ethode de Newton appliqu´ee aux ´equations `a deux inconnues. Pour ce faire, on est amen´e `a calculer l’inverse de la matrice jacobienne pour trouver la solution des ´equations. Nous comparons le mod`ele math´ematique avec les simulations ; nous observons les r´esultats dans le graphique 9.1 : Nous avons effectu´e des simulations comparant la politique LCE et LCD jug´ee la meilleure de toutes les politiques de m´etaching. Nous pr´esentons dans les graphes 9.2 les r´esultats des simulations pour une hi´erarchie de caches `a deux niveaux, avec 10 serveurs au premier niveau, attach´es `a un serveur au deuxi`eme niveau. Les r´esultats montrent un avantage de LCD par rapport `a LCE. Cet avantage diminue au fur et `a mesure que la taille des caches augmente, r´eduisant ainsi l’utilit´e de LCD. LCD permet de r´eduire le nombre de copies inutiles dans une hi´erarchie. La politique MCD, en plus de copier les objets dans le cache inf´erieur, efface les objets dans les caches sup´erieurs, mais l’efficacit´e de cet algorithme reste presque identique `a LCD, surtout dans le cas d’une hi´erarchie `a deux niveaux. Ainsi, LCD paraˆıt la politique la plus simple et la plus rentable. Nous comparons aussi la probabilit´e de hit globale des hi´erarchies afin d’´evaluer l’efficacit´e globale des algorithmes :CHAPITRE 9. LES PERFORMANCES DES HIERARCHIES DE CACHES ´ 67 0 0.2 0.4 0.6 0.8 1 0 10 20 30 40 50 60 70 80 90 100 hit1 : taux de hit au premier niveau rang c1 = c2 = 0.1 c1 = c2 = 0.3 simulation calcul (a) Zipf(0.6) 0 0.2 0.4 0.6 0.8 1 0 10 20 30 40 50 60 70 80 90 100 hit1 : taux de hit au premier niveau rang c1 = c2 = 0.1 c1 = c2 = 0.3 simulation calcul (b) Zipf(0.9) Figure 9.1 – Taux de hit calcul´e par simulation et mod`ele analytique de Che 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 hit1 C2 c1 = 0.1 c1 = 0.3 c1 = 0.5 LCE LCD (a) Zipf(0.6) 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 hit1 C2 c1 = 0.1 c1 = 0.3 c1 = 0.5 LCE LCD (b) Zipf(0.9) Figure 9.2 – Taux de hit au premier niveau pour une hi´erarchie LCE et LCD 9.1.3 Les politiques de forwarding – SPR (Shortest Path Routing) : Cette politique consiste `a chercher l’objet en suivant le chemin le plus court vers le serveur d’origine. – Flooding [48] : Envoyer la demande `a tous les noeuds et suivre le chemin trouv´e. Cette technique est lourde `a mettre en place et est tr`es coˆuteuse. – INFORM [49] : Chaque noeud sauvegarde les valeurs correspondant au temps de latence n´ecessaire pour arriver `a une destination en passant par chaque noeud voisin. Le noeud voisin, menant `a destination et offrant le moins de temps pour y arriver, est s´electionn´e pour r´ecup´erer ou envoyer les prochains paquets. – CATT [50] : Le choix du prochain noeud `a suivre pour arriver `a la donn´ee est effectu´e suivant le calcul du param`etre nomm´e potential value. Ce param`etre68 9.1. CARACTERISTIQUES D’UNE HI ´ ERARCHIE DE CACHES ´ 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 hitg C2 LCE LCD (a) Zipf(0.6) 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 hitg C2 LCE LCD (b) Zipf(0.9) Figure 9.3 – Taux de hit global pour une hi´erarchie LCE et LCD `a deux niveaux pour les cas de bas en haut c1 = 0.1, c1 = 0.3 et c1 = 0.5 peut ˆetre ´evalu´e selon le nombre de sauts, la situation g´eographique, ou la qualit´e de la bande passante s´eparant le noeud voisin des noeuds contenant les donn´ees. – NDN [51] : Cette strat´egie est propos´ee actuellement pour les r´eseaux orient´es contenus. Elle utilise des tables FIB, PIT et CS ; mais les FIB doivent ˆetre remplies suivant une autre m´ethode. Cet algorithme suppose des tables FIB compl`etes. – NRR(Nearest Routing Replica) : C’est une strat´egie id´ealiste qui consiste `a trouver la copie la plus proche du cache. Cette politique est lourde `a mettre en place car il faut maintenir des tables de routage orient´ees contenu tr`es dynamiques. La majorit´e des algorithmes propos´es r´ecemment se basent sur le calcul de param`etres de performances menant au cache contenant la donn´ee. Tout ceci n´ecessite des m´ecanismes de signalisation et d’´echange de messages de contrˆole afin d’identifier p´eriodiquement les chemins menant `a tous les objets. Cette op´eration est non seulement coˆuteuse, mais aussi pose des probl`emes de passage `a l’´echelle. SPR reste jusqu’`a pr´esent l’algorithme le plus utilis´e, et le plus simple ne pr´esentant aucun probl`eme de passage `a l’´echelle. Si la donn´ee est pertinente et populaire, elle devrait se trouver dans l’un des caches du plus court chemin menant au serveur d’origine. Ce dernier, est statique et invariable, sauf en cas de panne. L’utilisation des chemins secondaires est conditionn´ee par des probl`emes de congestion dans le r´eseau. La politique NRR semble ˆetre la politique la plus efficace offrant les meilleurs taux de hit. Nous comparons la politique SPF avec NRR afin d’´evaluer la diff´erence entre la politique la plus performante, et la politique la plus utilis´ee pour le routage. Les r´esultats sont pr´esent´es dans le graphique 9.4 :CHAPITRE 9. LES PERFORMANCES DES HIERARCHIES DE CACHES ´ 69 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 hit1 c1 SPF NRR (a) Zipf(0.6) 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 hit1 c1 SPF NRR (b) Zipf(0.9) Figure 9.4 – Taux de hit au premier niveau pour les politiques de forwarding NRR et SPF 9.2 Performances des hi´erarchies de caches Dans cette partie, nous ´etudions le cas d’une hi´erarchie LRU, avec une politique de forwarding se basant sur la recherche dans le serveur d’origine le plus proche. Nous nous limitons au cas de deux niveaux de cache ; Sem Borst [52] affirme qu’il n’y a aucune utilit´e `a utiliser un cache coop´eratif de plus de deux niveaux. 9.2.1 G´en´eralisation de la formule de Che Il a ´et´e mentionn´e dans la section pr´ec´edente que la corr´elation des demandes `a un deuxi`eme niveau de cache n’a qu’une petite influence sur les probabilit´es de hit. Nous d´emontrons, par simulation, que la formule de Che reste valide pour un deuxi`eme niveau de cache `a condition d’avoir suffisamment de caches au premier niveau att´enuant ainsi la corr´elation entre les caches. On consid`ere un catalogue de M objets ; les demandes arrivent au premier niveau suivant les lois de popularit´e Zipf(α). On mesure la probabilit´e de hit global de l’architecture `a deux niveaux, constitu´ee de n caches au premier niveau et d’un seul cache au deuxi`eme niveau. Les caches au premier niveau ont la mˆeme taille C1. On pose c1 = C1/M, la taille normalis´ee des caches au premier niveau. T2 est la taille du cache au deuxi`eme niveau et c2 = C2/M sa taille normalis´ee. On utilise la formule de Che au deuxi`eme niveau de caches, en consid´erant la popularit´e pop2(i) de l’objet i `a l’entr´ee du cache au deuxi`eme niveau : pop2(i) = pmiss1(i) ∗ pop1(i) o`u pmiss1(i) est la probabilit´e de miss de l’objet i au premier niveau.70 9.2. PERFORMANCES DES HIERARCHIES DE CACHES ´ La formule de Che au premier niveau s’applique normalement : pmiss1(i) = exp(−pop1(i) ∗ tc1 ) o`u tc1 est la solution de l’´equation C1 = X n (1 − e −pop1(i)tc1 ). La forumule de Che appliqu´ee au deuxi`eme niveau donne : pmiss2(i) = exp(−pop2(i) ∗ tc2 ) o`u tc2 est la solution de l’´equation C2 = X n (1 − e −pop2(i)tc2 ). La probabilit´e de hit globale hitg(i) de l’objet i est calcul´ee de : hitg(i) = hit1(i) + hit2(i) − hit1(i) ∗ hit2(i) et la probabilit´e de hit globale de toute l’architecture est : hitg = Xpop1(i) ∗ hitg(i). Comme on peut le remarquer, le n n’intervient pas dans le calcul du hitg, Che propose une formule plus complexe que l’´equation initiale incluant le n. La formule ´etant dif- ficile `a exploiter et nos calculs ne semblant pas donner des r´esultats plus satisfaisants, nous souhaitons savoir si la forumule de Che pour un cache est valable aussi pour plusieurs niveaux de cache. On compare les r´esultats des calculs avec les r´esultats des simulations dans les cas suivants : On remarque que les r´esultats des simulations sont proches des r´esultats de calcul pour n = 5, l’approximation de Che devient de plus en plus exacte que n augmente. Nous avons v´erifi´e que l’approximation est tr`es pr´ecise pour n ≥ 10. On compare les taux de hit globaux `a chaque niveau de cache pour une hi´erarchie de caches `a 5 niveaux obtenus par simulation hitgs et par calcul hitgc , les tableaux ci dessous repr´esente le taux d’erreur Te pour des valeurs de n de 2 et 5 (chaque noeud `a n fils). Le taux d’erreur est calcul´e ainsi : Te = hitgs − hitgc hitgs On effectue le calcul et la simulation dans le cas de caches de mˆeme taille normalis´ee c(cas CCN),on pose Tg la taille globale Tg = 5∗c ; les conclusions tir´ees sont identiques, mˆeme si les tailles de cache sont diff´erentes d’un niveau `a un autre. Il est clair queCHAPITRE 9. LES PERFORMANCES DES HIERARCHIES DE CACHES ´ 71 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.2 0.4 0.6 0.8 1 hicg c2 c1 = 0.1 c1 = 0.3 c1 = 0.5 c1 = 0.7 c1 = 0.9 Simulation Calcul (a) n=2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.2 0.4 0.6 0.8 1 hicg c2 c1 = 0.1 c1 = 0.3 c1 = 0.5 c1 = 0.7 c1 = 0.9 Simulation Calcul (b) n=5 Figure 9.5 – Probabilit´es de hit global pour α = 0.6 pour un nombre de caches au premier niveau ´egal `a 2 (gauche) et 5 (droite) 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.2 0.4 0.6 0.8 1 hicg c2 c1 = 0.1 c1 = 0.3 c1 = 0.5 c1 = 0.7 c1 = 0.9 Simulation Calcul (a) n=2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.2 0.4 0.6 0.8 1 hicg c2 c1 = 0.1 c1 = 0.3 c1 = 0.5 c1 = 0.7 c1 = 0.9 Simulation Calcul (b) n=5 Figure 9.6 – Probabilit´es de hit global pour α = 0.8 la formule de Che reste une excellente approximation, mˆeme pour une hi´erarchie de caches, et `a tous les niveaux de caches. Chaque objet dans CCN est constitu´e d’un certain nombre de chunks, On peut appliquer l’approximation de Che au niveau des chunks. On consid`ere que la d´ependance entre chunks est n´egligeable. On consid`ere un catalogue de taille M objets, un cache de taille C ; chaque objet k est de taille Tk et constitu´e de Tk/s chunks, o`u s est la taille d’un chunk. La probabilit´e de hit du chunk oik de l’objet k est : h(oik) = 1 − exp(−pop(oik) ∗ tc)72 9.2. PERFORMANCES DES HIERARCHIES DE CACHES ´ level M = 104 M = 105 Tg = 20% level2 13% 17% level3 23% 25% level4 28% 29% level5 30% 32% Tg = 80% level2 14% 17% level3 23% 20% level4 25% 30% level5 28% 21% Table 9.1 – Taux d’erreur pour la formule de Che pour n = 2 level M = 103 M = 104 Tg = 20% level2 10% 6% level3 11% 13% level4 11% 9% level5 12% 10% Tg = 80% level2 1.3% 4% level3 3.5% 6.8% level4 5.8% 7.3% level5 6% 6.9% Table 9.2 – Taux d’erreur pour la formule de Che pour n = 5 o`u tc est la solution de l’´equation : C = X M k=1 T Xk/s i=1 (1 − exp(−pop(oik) ∗ tc). Les chunks appartenant au mˆeme objet ont la mˆeme popularit´e que l’objet : pop(oik) = pop(k). Donc tc est calcul´e avec l’´equation : C = X M k=1 (Tk/s) ∗ (1 − exp(−pop(k) ∗ tc). 9.2.2 Cas d’application : hi´erarchie de caches avec mix de flux Comme soulign´e pr´ec´edemment, les donn´ees Internet sont non homog`enes. Plusieurs cat´egories de donn´ees avec des lois de popularit´e et des tailles diff´erentes partagent les ressources r´eseaux. Nous nous limitons `a une hi´erarchie `a deux niveaux. On consid`ere un r´eseau constitu´e d’un premier niveau de caches (situ´es dans les routeurs d’acc`es)CHAPITRE 9. LES PERFORMANCES DES HIERARCHIES DE CACHES ´ 73 reli´es `a un grand cache de deuxi`eme niveau situ´e au coeur du r´eseau (voir la figure 9.7). Notons que le deuxi`eme niveau serait r´ealis´e en pratique par un r´eseau de caches dont les contenus seraient typiquement coordonn´es. L’´etude d’un tel r´eseau est l’objectif de nos travaux suivants. sources . . . . . layer 2 layer 1 users . Figure 9.7 – Hi´erarchie de caches `a deux niveaux On consid`ere que le nombre de routeurs d’acc`es au premier niveau de caches est large ; donc, les requˆetes arrivant au deuxi`eme niveau de cache peuvent ˆetre consid´er´ees comme ind´ependantes (i.e., l’IRM s’applique pour le deuxi`eme niveau). La popularit´e au deuxi`eme niveau de cache est ´egale `a q ′ (n) = q(n)(1 − h(n)) ; il suffit d’appliquer la formule de Che, en utilisant la nouvelle valeur de popularit´e, pour trouver la popularit´e de hit au deuxi`eme niveau h ′ (n). La figure 9.8 repr´esente la probabilit´e globale de hit, P n q(n)(h(n) + (1 − h(n)h ′ (n))/ P n q(n), en fonction des tailles de cache au premier et au deuxi`eme niveau. La loi de popularit´e est de Zipf et la figure montre l’impact de son param´etre α. 102 104 C1 102 104 C2 20% 40% 60% 80% 102 104 C1 102 104 20% 40% 60% 80% Figure 9.8 – Taux de hit(%) en fonction de la taille des caches dans les niveaux 1 et 2 : `a gauche, α = .8, N = 104 ; `a droite, α = 1.2. La mˆeme approche a ´et´e appliqu´ee dans le cas d’un mix de trafic, permettant ainsi de quantifier les tailles de cache aux deux niveaux pour une probabilit´e de hit cible.74 9.2. PERFORMANCES DES HIERARCHIES DE CACHES ´ 108 1012 1016 C1 108 1012 1016 C2 20% 40% 60% 80% 108 1012 1016 108 1012 1016 C2 20% 40% 60% 80% Figure 9.9 – Taux de hit(%) en fonction de la taille des caches dans les niveaux 1 et 2 : `a gauche trafic UGC, α = .8 ; `a droite, VoD α = 1.2, N = 104 . Les caches au premier niveau sont efficaces pour le trafic VoD voir figure 9.9. En effet, avec un cache `a 1012, la probabilit´e de hit du trafic VoD est de 80%. Avec un cache de mˆeme taille, on ne peut d´epasser 20% de probabilit´e de hit pour les autres types de trafic : UGC, fichiers partag´es et web. Il serait donc n´ecessaire de choisir des tailles de caches assez grandes. Les tailles de cache au premier niveau sont petites permettant ainsi leur insertion `a un routeur d’acc`es. Les VoD peuvent ainsi ˆetre stock´ees au premier niveau, contrairement aux autres types de donn´ees. Dans la table ci-dessous, nous ´evaluons la bande passante conserv´ee par une succession de deux caches ; le premier situ´e au premier niveau est de taille 1 TB , et le deuxi`eme situ´e au deuxi`eme niveau est de taille 100 TB. L’´evaluation est effectu´ee dans le cas d’un partage normal entre contenus, et dans le cas d’un premier niveau r´eserv´e au VoD. Les r´esultats pr´esent´es correspondent au trafic Mix de 2011 et 2015. On remarque qu’un stockage exclusif du VoD au premier niveau am´eliore la proZipf VoD(α) niveau1 R´eduction bande passante au niveau1 R´eduction bande passante au niveau1 et 2 2011 0.8 partag´e 17% 50% VoD 23% 58% 1.2 partag´e 24% 50% VoD 23% 58% 2015 0.8 partag´e 27% 59 % VoD 37% 61% 1.2 partag´e 36% 59% VoD 37% 61% Table 9.3 – R´eduction en bande passante pour C1=1TB et C2=100TB babilit´e du hit au premier niveau de cache ; ceci est plus significative pour une loi Zipf(0.8). Dans tous les cas, un stockage discriminatoire des VoD au premier niveauCHAPITRE 9. LES PERFORMANCES DES HIERARCHIES DE CACHES ´ 75 am´eliore le taux de hit global r´esultant des deux caches, que ce soit pour une loi Zipf(0.8) ou Zipf(1.2) ; la diff´erence devient moins importante pour le trafic futur en 2015.Chapitre 10 Conclusion Dans ce chapitre, nous avons ´evalu´e la nature, la quantit´e et la popularit´e des objets ´echang´es sur Internet, le trafic ´etant presque majoritairement du contenu distribu´e. Nous avons par la suite ´evalu´e les performances d’un cache LRU ; pour ce faire nous avons test´e la formule de Che. Cette derni`ere est facile `a utiliser num´eriquement, valable pour toute valeur de α de la loi de Zipf et pour plusieurs autres lois de popularit´e. Nous avons expliqu´e les raisons de son exactitude, en se basant sur la d´emonstration pr´esent´ee par Fricker et al. [40]. Nous avons aussi explor´e le cas d’un cache Random, et compar´e ses performances `a celles d’un cache LRU. Nous avons d´ecrit les caract´eristiques d’une hi´erarchie de caches, et compar´e les perfomances des politiques de m´etacaching et forwarding optimales avec des politiques d’usage. Nous avons constat´e `a travers un exemple en se basant sur des donn´ees repr´esentant l’´echange actuel sur Internet que pour des lois de popularit´e Zipf avec un param`etre α ¡1 il faut choisir des taille de cache tr`es grands pour r´eduire d’une mani`ere significative l’utilisation de la bande passante, ce qui est techniquement difficile `a mettre en place au niveau d’un routeur, ce qui nous m`ene `a penser qu’un d´eployment au niveau applicatif est plutot convenable. Dans la partie suivante nous comparons les couts des hierarchies distribu´es `a la CCN et des hierarchie centralis´ees `a la CDN qui nous paraissent techniquement plus convenables. 76Troisi`eme partie Coˆuts d’une hi´erarchie de caches 77Chapitre 11 Introduction 11.1 Probl´ematique Dans la partie pr´ec´edente, nous avons propos´e un stockage diff´erenci´e pour am´eliorer la probabilit´e de hit de la hi´erarchie. Or, en stockant la majorit´e des contenus au deuxi`eme niveau, la consommation de la bande passante est plus ´elev´ee. Pour les op´erateurs, deux crit`eres importants leur permettent de prendre des d´ecisions pour le stockage de donn´ees : les coˆuts et la difficult´e de mise en oeuvre. Puisque les r´eseaux de caches comme CCN sont distribu´es, il faut prendre en compte, en plus du coˆut de la m´emoire, le coˆut de la bande passante. Plus l’op´erateur investit en m´emoire, moins il investit en bande passante et vice versa. L’op´erateur est amen´e `a d´eterminer un tradeoff optimal entre bande passante et caches. D´eploy´es depuis des ann´ees, les CDN deviennent un acteur principal g´erant le contenu des sites les plus connus et utilis´es `a travers le monde. Les CDN, contrairement aux CCN, sont des hi´erarchies centralis´ees et non distribu´ees. Entre une technologie d´ej`a exp´eriment´ee et une technologie en cours de recherche, le choix de l’op´erateur est vite fait ; les CDN sont d´ej`a d´eploy´es et utilis´es, ne n´ecessitant aucune mise `a jour au niveau des routeurs ou des protocoles r´eseau. Le seul enjeu pouvant encourager les op´erateurs `a opter pour une architecture distribu´ee est le coˆut. Le travail de Ghodsi et al. [5] n’apporte pas cet espoir pour l’avenir des r´eseaux CCN ; cet article vient, en plein milieu de notre travail de recherche, remettre en cause l’utilisation des CCN `a l’avenir. Les arguments avanc´es par Ghodsi et al. sont : – La difficult´e de changer tout le mod`ele Internet de l’orient´e IP vers l’orient´e contenu. La convergence vers un r´eseau orient´e contenu n´ecessite un changement au niveau des routeurs et des protocoles. Ceci n´ecessiterait beaucoup de temps, compte tenu du temps d’attente avant la mise en place d’une mise `a 78CHAPITRE 11. INTRODUCTION 79 jour mineure telle que l’adressage IPv6. Sans compter le temps n´ecessaire pour l’impl´ementation de PKI assurant la s´ecurit´e des donn´ees. – Pour des caches de grande taille, il a ´et´e prouv´e que la coop´eration n’apporte que tr`es peu de gain ; donc l’utilit´e de distribuer la m´emoire sur tous les routeurs n’est pas forc´ement b´en´efique. En plus de ces arguments, notre travail pr´esent´e dans [40] montre qu’une r´eduction significative de bande passante n´ecessite l’utilisation de caches de tr`es grande taille, d´epassant largement la taille de la m´emoire pouvant ˆetre ajout´ee `a un routeur [53]. Notre probl`eme revient `a ´evaluer les coˆuts d’une architecture de cache distribu´ee : qu’est ce qui coˆuterait plus cher, mettre des petits caches partout ou de grands caches au premier niveau ? Ou plus exactement dans une architecture en arbre, comment faut-il choisir la taille de cache dans les diff´erents niveaux pour avoir un taux de hit cible avec le moindre coˆut ? 11.2 Etat de l’art Certaines ´etudes abordent le probl`eme de l’optimisation en fixant un ou plusieurs param`etres. Par exemple, Dario Rossi et Giuseppe Rossini [54] se sont d´ej`a pench´es sur ce probl`eme. Ils ont conclu que l’utilisation de caches de tailles diff´erentes ne fait augmenter le gain que de 2,5% dans le meilleur des cas, et qu’il vaut mieux utiliser la mˆeme taille de cache, vu le gain faible et la d´et´erioration de la rapidit´e d’un cache quand sa taille augmente. Dans cette ´etude, la taille globale de caches a ´et´e fix´ee. Le coˆut de caching est donc fix´e et le facteur de performance est le taux de hit. Le coˆut de bande passante n’a pas ´et´e pris en compte. Une configuration est pr´ef´erable `a une autre si sa probabilit´e de hit est meilleure. On voit que ceci n’est pas suffisant. Par ailleurs, le param`etre α de la loi Zipf de popularit´e est suppos´e sup´erieur `a 1, ce qui n’est pas conforme aux mesures. Sem Borst et al. [52] calculent les coˆuts de bande passante et proposent un algorithme de coop´eration pour le placement des donn´ees dans une hi´erarchie de caches afin de minimiser ce coˆut. Le coˆut de la m´emoire n’est pas pris en consid´eration, donc le tradeoff m´emoire/bande passante n’est pas ´etudi´e. Kangasharju [55] suppose que la localisation des caches et la capacit´e sont fixes, et dans [47] est explor´e le probl`eme d’optimisation avec une taille fixe de cache global comme contrainte. Notre vision des choses est diff´erente, nous pensons que le coˆut global inclut le coˆut de la bande passante et le coˆut de la m´emoire. C’est un crit`ere de comparaison fiable entre architectures. D’autres ´etudes cherchent le tradeoff m´emoire/bande passante, comme par exemple Nussbaumer et al. [56]. Ils adoptent une ´evaluation de coˆut similaire `a la nˆotre, en prenant en compte les coˆuts de la bande passante et de la m´emoire pour une hi´erarchie80 11.2. ETAT DE L’ART de caches en arbre. Cependant, leurs r´esultats ne sont pas applicables pour nous. Nous rencontrons le mˆeme probl`eme avec l’article [57] qui n’offre aucun r´esultat num´erique exploitable. Il est clair que la taille des caches d´etermine le coˆut de la m´emoire qui est croissant en fonction de la taille. Par contre le coˆut de la bande passante devient plus petit car le taux de hit augmente avec la taille. Notre objectif est de d´eterminer la hi´erarchie de cache optimale, que ce soit une architecture avec, ou sans coop´eration de caches. On fixe la probabilit´e de hit global de l’architecture `a une probabilit´e de hit cible. Avec une hi´erarchie de caches, il est toujours possible d’am´eliorer les gains en utilisant la coop´eration, comme c’´etait le cas pour les proxies, et donc rendre la distribution de caches rentable par rapport `a une hi´erarchie centralis´ee. Pourtant, Wolman et al. [58] ont d´emontr´e, par simulation sur une large population de 107 ou 108 objets que la coop´eration n’apporte que tr`es peu de gain ; ce qui remet en question l’utilit´e de mettre en place un lourd m´ecanisme de coop´eration et d’´echange de messages entre serveurs. Pour une population r´eduite, utiliser un seul proxy revient moins cher et est aussi efficace que plusieurs caches coop´eratifs. Plus r´ecemment, Fayazbakhsh et al. [59] ont constat´e que le stockage `a l’edge offre des performances plutˆot bonnes en termes de temps de latence, de congestion, et de charge du serveur d’origine. De plus, il offre un ´ecart de 17% par rapport `a une architecture CCN presque optimale, ce que les auteurs consid`erent comme minime, et compensable en pla¸cant plus de m´emoire `a l’edge. L’article [44] a remis en question cette ´etude par une contre-´etude, en montrant que le fait de coupler une strat´egie de forwarding optimale (chercher l’objet dans le cache le plus proche contenant l’objet recherch´e) avec une politique de m´eta-caching optimale (LCD pour Leave a Copy Down) augmente consid´erablement la marge entre un caching `a l’edge et un caching distribu´e `a la CCN, ceci en consid´erant une popularit´e Zipf avec α = 1. Wang et al. [60] traitent le probl`eme d’allocation de la m´emoire et cherchent `a trouver l’optimum. Le raisonnement va dans le mˆeme sens : l’optimum est obtenu `a travers une distribution non ´equitable des tailles de caches dans une hi´erarchie ; cette distribution d´epend de la popularit´e des objets, et de la taille du catalogue. En somme, un caching exclusif `a l’edge est une solution contest´ee du fait qu’elle n’a pas ´et´e compar´ee `a une solution ICN optimale avec une strat´egie de forwarding, et de meta-caching optimales. Dans tous les cas, le probl`eme que nous ´etudions est diff´erent du probl`eme trait´e dans les articles pr´ec´edemment cit´es. En g´en´eral, les chercheurs fixent une taille de cache global, ou par cache individuel, et cherchent un optimum pour la probabilit´e de hit globale, ou un optimum selon le nombre moyen de sauts travers´es par les requˆetes pour trouver l’objet recherch´e, ce qui mesure implicitement la consommation de la bande passante. Le fait de fixer la taille de cache ´elimine desCHAPITRE 11. INTRODUCTION 81 solutions possibles pour les optima, sachant que l’optimum absolu pour les utilisateurs est un stockage entier du catalogue `a l’edge ´evitant ainsi tout d´eplacement vers les serveurs d’origine. Entre la taille n´ecessaire pour assurer le stockage et la consommation de bande passante, le choix des op´erateurs devrait se baser sur les coˆuts, sachant que les coˆuts de la m´emoire d´ecroissent tr`es vite. Un stockage `a l’edge ´eliminerait tous les probl`emes li´es au routage orient´e contenu qui nous paraissent lourdes et posent des probl`emes de passage `a l’´echelle. L’utilisateur demande un objet de son edge. Si le routeur d’acc`es ne d´etient pas l’objet, alors la requˆete est redirig´ee vers le serveur d’origine. Le tableau 11.1 r´esume quelques ´etudes ayant trait´e la probl´ematique de l’optimum. R´ef´erence Contraintes Optimums Fayazbakhsh et al. [59] Les caches ont la mˆeme taille Peu d’avantages `a cacher partout dans le r´eseau, un caching `a l’edge est b´en´efique Rossini et al. [44] Les caches ont la mˆeme taille Avec une politique de meta caching LCD (Leave a copy down) et une strat´egie de forwarding menant au cache le plus proche(NRR) contenant l’objet, nous obtenons un ´ecart de 4% en nombre de sauts par rapport `a un couplage LCD et une politique de forwarding SPF menant au serveur d’origine le plus proche. Borst et al. [52] Taille de caches fixes, recherche de l’optimum en terme de bande passante L’optimum inter-niveau correspond `a un stockage des objets les plus populaires dans toutes les feuilles de l’arbre, et les moins populaires dans le cache sup´erieur. Table 11.1 – Comparaison des quelques ´etudes des coˆuts des hi´erarchies de cachesChapitre 12 Cout d’une hi ˆ erarchie de ´ caches a deux niveaux ` Dans ce chapitre, nous nous int´eressons aux coˆuts d’une hi´erarchie de caches. Nous souhaitons r´epondre `a la question : est-ce b´en´efique d’utiliser des caches distribu´es plutˆot que des caches centralis´es ? Nous pensons que c’est la diff´erence de base entre les r´eseaux CCN et les CDN. Afin de voir clairement la diff´erence des deux solutions, nous commen¸cons par une hi´erarchie `a deux niveaux uniquement. Notre hi´erarchie est repr´esent´ee `a la figure 12 : Le trafic g´en´er´e par les demandes des utilisateurs est de A en bit/s, le requˆetes ..... Figure 12.1 – architecture `a deux niveaux proviennent de n noeuds d’acc`es au premier niveau. Tous les caches au premier niveau ont la mˆeme taille T1. Le cache de deuxi`eme niveau est de taille T2. On cherche la structure optimale avec le minimum de coˆut. Les tailles T1 et T2 varient afin d’obtenir `a chaque fois une structure diff´erente, mais chaque structure devrait r´ealiser un taux de hit fix´e `a une valeur cible (afin de pouvoir comparer les coˆuts 82CHAPITRE 12. COUT D’UNE HI ˆ ERARCHIE DE CACHES ´ A DEUX NIVEAUX ` 83 des architectures). Donc pour chaque valeur de T1, il existe une seule valeur de T2 v´erifiant un taux de hit global fixe. 12.1 Diff´erence des coˆuts entre structures Le coˆut d’une architecture est ´egal `a la somme des coˆuts de la bande passante, le coˆut de la m´emoire, et le coˆut de gestion au niveau des caches. – Le coˆut de la bande passante Cb est proportionnel (on introduira une constante kb) au trafic global g´en´er´e entre le premier et le deuxi`eme niveau. Le coˆut d’acc`es est le mˆeme pour toutes les architectures, et donc il s’annule en diff´erence Cb = kb × T raf ic . – Le coˆut de la m´emoire Cm est proportionnel `a la taille des caches Cm = km × Taille de la m´emoire . – Le coˆut de gestion au niveau des caches Cg est proportionnel au trafic, soit Cg = ks × T raf ic. La diff´erence de coˆut entre deux architectures ayant le mˆeme taux de hit global est : δcout(T1, T′ 1 ) = (pmiss1 − p ′ miss1 )(kb + ks)A + (n(T1 − T ′ 1 ) + (T2 − T ′ 2 ))km o`u – pmiss1 est le taux de miss de la premi`ere architecture, – pmiss′ 1 est le taux de miss de la deuxi`eme architecture, – T1 (T2) est la taille des caches au premier (deuxi`eme) niveau de la premi`ere architecture – et T ′ 1 (T ′ 2 ) est la taille des caches au premier (deuxi`eme) niveau de la deuxi`eme architecture. Les deux architectures ont le mˆeme taux de hit global et le mˆeme nombre de caches au premier niveau.84 12.2. ESTIMATION NUMERIQUE DES CO ´ UTS ˆ 12.2 Estimation num´erique des coˆuts Nous avons besoin de quelques estimations des coˆuts unitaires kb, km et ks. – kb : On estime kb `a 15 $ par Mbps ; c’est une valeur non publi´ee mais estim´ee par quelques sources sur le web, et par des ´echanges priv´es avec un op´erateur. Ce coˆut unitaire couvre le coˆut du transport et des routeurs. – km : On estime le coˆut unitaire de la m´emoire `a km=0.15 $ par Gigabyte. Cette estimation est d´eriv´ee des fournisseurs de cloud comme Amazon. – ks : Le coˆut unitaire de gestion ks est estim´e `a 10 c par Mbps. Cette observation est tir´ee des charges de t´el´echargement des offres Cloud. La valeur de ks est donc n´egligeable par rapport `a la valeur de kb de sorte que la diff´erence des coˆuts entre architectures devient : ∆cout(T1, T′ 1 ) = (pmiss1 − p ′ miss1 )kbA + (n(T1 − T ′ 1 ) + (T2 − T ′ 2 ))km. Etudier la diff´erence de coˆuts revient `a ´etudier la fonction δ d´efinie par : ∆(T1) = pmiss(T1)kbA + (nT1 + T2(T1))km. Notre objectif est de d´eterminer les tailles T1 (et donc T2 puisque le taux de hit global est fix´e) correspondant au minimum de la fonction ∆. Le trafic `a l’acc`es est de l’ordre de A = 1 Tbp, la taille moyenne de chaque objet est de 1 GB et la taille du catalogue est estim´ee `a M = 2 × 106 objets. De plus, notons que la probabilit´e de hit d´epend du rapport entre la taille du cache et le catalogue. Pour v´erifier ceci, on consid`ere un cache de taille T et un catalogue de taille M. On trace sur la figure 12.2 la probabilit´e de hit en fonction de T /M pour diff´erentes valeurs de M et deux lois de popularit´e, Zipf(0.6) et Zipf(0.8). On observe que la probabilit´e de hit pour une popularit´e Zipf(0.6) est presque la mˆeme pour des tailles de catalogue diff´erentes. Pour le cas Zipf(0.8), la probabilit´e de hit est l´eg`erement plus faible pour un catalogue de taille 2 × 104 mais les probabilit´es de hit se rapprochent pour les grandes tailles de catalogue. Dans tous les cas, `a partir d’une taille de cache normalis´ee de 10%, les valeurs sont tr`es rapproch´ees. Puisque les tailles de catalogues sont grandes en r´ealit´e, il est clair que la probabilit´e de hit ne d´epend en pratique que du rapport entre la taille du cache et du catalogue. On note c la taille normalis´ee du cache c = T /M, ¯c la taille normalis´ee du cache au deuxi`eme niveau et h(c) la probabilit´e de hit au premier niveau de cache. La diff´erence de coˆut devient : δ(c) = (1 − h(c))kbA + M(nc + ¯c)km.CHAPITRE 12. COUT D’UNE HI ˆ ERARCHIE DE CACHES ´ A DEUX NIVEAUX ` 85 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1e-05 0.0001 0.001 0.01 0.1 1 M = 2 ∗ 104 M = 2 ∗ 105 M = 2 ∗ 106 M = 2 ∗ 107 (a) Popularit´e Zipf α=0.6 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1e-05 0.0001 0.001 0.01 0.1 1 M = 2 ∗ 104 M = 2 ∗ 105 M = 2 ∗ 106 M = 2 ∗ 107 (b) Popularit´e Zipf α=0.8 Figure 12.2 – Taux de hit en fonction des tailles de caches normalis´ees T /M 12.2.1 Coˆut normalis´e Dans un premier temps, on consid`ere que l’op´erateur souhaite ´eviter de chercher les donn´ees en dehors de son r´eseau, et donc la probabilit´e de hit cible est ´egale `a 1. Dans ce cas ¯c = 0 ( est une diff´erence de tailles de caches au deuxi`eme niveau qui s’annule dans ce cas). On pose Γ = Akb Mnkm , le rapport entre le coˆut maximal de bande passante Akb et le coˆut maximal de m´emoire Mnkm. Le tradeoff entre m´emoire et bande passante est visible sur l’´equation. On note Γnominal la valeur de Γ correspondante aux valeurs cit´ees dans le paragraphe pr´ec´edent, Γnominal = 1012 × 15 × 10−6 0.15 × 10−9 × 100 × 2 × 106 × 109 = 0.5. Avec ce choix taux de hit cible, la diff´erence de coˆut normalis´e peut s’exprimer : δ(c) = Γ(1 − h(c)) + c. Cette fonction est pr´esent´e `a la figure 12.3. On observe que, pour Γ=0.5 (c’est-`a-dire la valeur nominale), la valeur optimale du coˆut correspond `a une taille de cache au premier niveau plutˆot petite (inf´erieure `a 10% du catalogue) ; plus Γ devient petit, plus on a int´erˆet `a tout cacher au deuxi`eme niveau. Plus la valeur Γ augmente, plus la solution optimale correspondrait `a un grand cache au premier niveau. Ces observations sont valables pour les deux valeurs de α comme le montre la figure 12.4. On remarque que le choix d’une taille de cache au premier niveau ´egale `a la taille du catalogue offre une solution optimale pour une valeur de Γ > 2 pour α = 0.6, et de Γ > 3.8 pour α = 0.8. Plus le cache est efficace (param`etre α plus grand ou politique86 12.2. ESTIMATION NUMERIQUE DES CO ´ UTS ˆ 0.1 1 10 0 0.2 0.4 0.6 0.8 1 Γ = 10 Γ = 5.0 Γ = 1.0 Γ = 0.5 Γ = 0.1 (a) Popularit´e Zipf α=0.6 0.1 1 10 0 0.2 0.4 0.6 0.8 1 Γ = 10 Γ = 5.0 Γ = 1.0 Γ = 0.5 Γ = 0.1 (b) Popularit´e Zipf α=0.8 Figure 12.3 – Coˆuts normalis´es en fonction des tailles de caches normalis´es au premier niveau 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 coptimal Γ α = 0.6 α = 0.8 (a) Popularit´es diff´erentes 0 0.2 0.4 0.6 0.8 1 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 coptimal Γ LRU(α = 0.6) LF U(α = 0.6) LRU(α = 0.8) LF U(α = 0.8) (b) Politiques de remplacement diff´erentes Figure 12.4 – Taille de cache normalis´ee optimale en fonction de Γ de remplacement plus efficace), moins il est utile de stocker des donn´ees au premier niveau de cache. Mais, mˆeme pour un cache LFU et un α = 0.8, la solution optimale correspond `a un stockage complet du catalogue `a partir de Γ = 5. La solution optimale actuelle pour le Γ nominal correspond `a une valeur de moins de 10 % du catalogue ; mais les valeurs des coˆuts sont si rapproch´ees pour Γ = 1 que le choix d’un c a une valeur ´egale au catalogue semble meilleur car l’utilisateur peut profiter d’une latence plus faible. La valeur de kc diminue de 40% chaque ann´ee1 , kb diminue de 20% chaque ann´ee, le 1http ://www.jcmit.com/memoryprice.htmCHAPITRE 12. COUT D’UNE HI ˆ ERARCHIE DE CACHES ´ A DEUX NIVEAUX ` 87 trafic T augmente de 40% chaque ann´ee2 et le catalogue augmente d’`a peu pr`es 50%. Le Γ tend alors `a augmenter au fil du temps, et peut devenir cinq fois plus grand que le Γ nominal dans 6 ans. Cependant, les valeurs des coˆuts varient selon la r´egion g´eographique 3 et des ´el´ements inattendus peuvent augmenter le prix des m´emoires. Le tradeoff reste quand mˆeme compliqu´e `a d´eterminer car il d´epend de l’emplacement g´eographique, et des lois de popularit´e. 12.2.2 Solution optimale en fonction du taux de hit global Nous avons consid´er´e la probabilit´e de hit global ´egale `a 1. Or, pour diff´erentes raisons, le fournisseur de contenu peut manquer de moyens pour payer le prix optimal. La solution consiste `a g´erer une partie du catalogue (ce qui correspond `a la partie la plus populaire) et de confier le stockage des autres contenus `a un serveur distant. Le nombre de caches au premier niveau ne change rien `a la probabilit´e de hit global, on peut utiliser la formule de Che `a deux niveaux de caches. Donc δ(c) = Γ(1 − h(c)) + c + ¯c/n). On obtient les r´esultats pr´esent´es dans la figure 12.5 avec des probabilit´es de hit global de 0.5 et 0.9. 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 cout c Γ = 0.05 Γ = 0.5 Γ = 2 hitg=0.9 hitg=0.5 (a) Loi Zipf(0.6) 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 cout c Γ = 0.05 Γ = 0.5 Γ = 2 hitg=0.9 hitg=0.5 (b) Loi Zipf(0.8) Figure 12.5 – Coˆuts pour diff´erentes valeurs de Γ et de probabilit´es de hit On remarque que la courbe des diff´erences de coˆuts pour une probabilit´e de hit de 50% co¨ıncide avec la courbe des coˆuts pour une probabilit´e de hit de 90%. Ceci s’explique 2http ://www.networkworld.com/news/tech/2012/041012-ethernet-alliance-258118.html ?page=1 3http ://www.zdnet.fr/actualites/le-prix-du-transit-ip-baisse-encore-partout-dans-le-monde- 39775196.htm88 12.3. EXEMPLE : COUTS DES TORRENTS ˆ peut-ˆetre par la valeur de n (n=100) qui implique que la valeur de ¯c/n reste petite et n’influence pas la valeur des coˆuts. Ceci peut mener `a nous demander `a quel niveau il faut placer les caches dans un r´eseau. 12.3 Exemple : coˆuts des torrents Un moteur de recherche comme mininova.org offre un ensemble de torrents. Dan et al. [61] ont analys´e des donn´ees torrents de cette source et partag´e leurs donn´ees avec nous. Un premier fichier de donn´ees contient 2.9 × 106 torrents actifs et donne le nombre de leechers au moment de la capture. Nous avons conserv´e 1.6 × 106 torrents correspondant `a au moins un leecher actif au moment de la capture. On consid`ere un torrent de taille s et un nombre de leechers instantan´e de l. En utilisant la loi de Little, et en consid´erant la dur´ee de t´el´echargement proportionnelle `a la taille s, la fr´equence d’arriv´ee du torrent est : λ = nombre moyen de torrents temps de t´el´echargement . La fr´equence d’arriv´ee des torrents est donc proportionnelle `a l/s. Un deuxi`eme fichier correspondant aux tailles des torrents nous a ´et´e fourni. La popularit´e de chaque chunk est ´egale `a la popularit´e de son torrent. La formule de Che est plus facile `a utiliser au niveau chunk qu’au niveau torrent car les torrents ont des tailles diff´erentes, alors que les chunks ont la mˆeme taille. La popularit´e des chunks des torrents d´eduite des traces est repr´esent´ee `a la figure 12.6. 1e-05 0.001 0.1 10 1000 100000 1 100 10000 1e+06 1e+08 popularity rank head (Zipf(.6)) body (Zipf(.8)) tail Figure 12.6 – Popularit´e des chunks pour les torrentsCHAPITRE 12. COUT D’UNE HI ˆ ERARCHIE DE CACHES ´ A DEUX NIVEAUX ` 89 0.01 0.1 1 10 100 0 0.2 0.4 0.6 0.8 1 .3 .5 .7 .8 .9 .95 .99 (a) coˆuts normalis´es pour un coˆut de bande passante lin´eaire 0.01 0.1 1 10 100 0 0.2 0.4 0.6 0.8 1 .3 .5 .7 .8 .9 .95 .99 (b) coˆut normalis´es pour un coˆut de bande passante non lin´eaire Figure 12.7 – Coˆuts normalis´es pour diff´erentes valeur de Γ Les courbes pr´esent´ees dans la figure 12.7 repr´esentent les coˆuts normalis´es dans le cas d’une probabilit´e de hit globale de 1 pour les torrents. La figure 12.7(b) repr´esente le cas d’un coˆut de bande passante non lin´eaire T .75kb, ce qui permet d’´evaluer l’impact d’´economie d’´echelle. On remarque que les observations sont les mˆemes : pour un Γ = 10, la solution optimale correspond `a un stockage complet au premier niveau ; de mˆeme pour Γ = 1 la courbe est presque plate, impliquant qu’un stockage au premier niveau semble plutˆot b´en´efique.Chapitre 13 Cooperation de caches ´ Un grand nombre de publications met en avant l’avantage qu’on peut tirer de la distribution de caches et de leur coop´eration. Mais ces publications ne prennent pas en compte le coˆut des ´echanges entre les caches et donc le coˆut de la bande passante qui est typiquement plus important que le coˆut de la m´emoire. Dans cette section, nous nous int´eressons `a l’´evaluation du tradeoff bande passante/ m´emoire, dans le cas de coop´eration de caches. 13.1 Load sharing Li et Simon [62] proposent la division du catalogue en P partitions. Chaque cache peut stocker les ´el´ements d’une partition de taille ´egale `a M/P o`u M est la taille du catalogue. Figure 13.1 – R´eseau de caches P=3 et S=12 Pour ´evaluer les coˆuts de cette architecture, on introduit un nouveau facteur k ′ b repr´esentant le coˆut unitaire des liens entre caches du premier niveau. Une proportion 90CHAPITRE 13. COOPERATION DE CACHES ´ 91 1/P des requˆetes arrivant `a chaque cache correspondent au sous-catalogue attribu´e au cache, les (P − 1)/P requˆetes restantes ´etant redirig´ees vers les autres caches. La consommation de bande passante au premier niveau est donc estim´ee `a : nk′ b P − 1 P . Le coˆut de la bande passante r´esultante du taux de miss au premier niveau est estim´ee `a : nkbmiss(C) o`u miss(C) est la probabilit´e de miss au premier niveau pour cette architecture. Elle correspond au taux de miss d’un cache LRU de taille C pour un catalogue de taille M/P. On pose c = CP/M la taille normalis´ee des caches pour cette architecture. On ´ecrit miss(c) = miss(CP/M) o`u miss(c) correspond `a la probabilit´e de miss d’un cache LRU de taille P C et un catalogue de taille M. Tout calcul fait : δLS(c) = δ(c) + (1 − 1 P )(Γk ′ b kb − c). Le partitionnement du catalogue est b´en´efique dans le cas o`u Γk ′ b kb < c. Si, par exemple, Γ = 4 il faut que k ′ b kb < c/4 ≤ 1/4. Or, il serait surprenant que le coˆut d’un lien entre caches de premier niveau soit 4 fois inf´erieur au coˆut d’un lien entre le premier et le deuxi`eme niveau de caches, ce qui sugg`ere que ce type de partage de charge n’est gu`ere utile. 13.2 Caches coop´eratifs Ni et Tsang [63] proposent un algorithme de caches coop´eratifs bas´e sur le load sharing. Chaque cache est responsable d’une partition du catalogue. Toute requˆete destin´ee `a un cache sera d’abord recherch´ee dans le cache d’accueil, avant de s’adresser au cache responsable le plus proche. On d´esigne q(i) la popularit´e normalis´ee de l’objet i. Pour un cache du premier niveau, la popularit´e de chaque chunk appartenant `a la partition dont il est responsable est q ′ (n) = q(n)(1 + (P − 1)e −q ′ (n)tc ). En adaptant la formule de Che, on trouve tc en utilisant la formule (13.1) : X N n=1 1 P (1 − e −q ′ (n)tc ) + (1 − 1 P )(1 − e −q(n)tc ) = C (13.1) On consid`ere un cache k au premier niveau. On note R la fonction d´eterminant l’identit´e de la partition du catalogue dont il est responsable : R(k) = l veut dire que le cache k est responsable de la partition Ml . On note Ak l’ensemble de caches au premier niveau sauf le cache k. On observe les ´echanges entre caches illustr´es par la figure 13.2.92 13.2. CACHES COOPERATIFS ´ cache niveau 2 objet i, i /∈ Ml,miss(i) objet i, i ∈ Ml,miss(i) cache k Autres caches Ak objet i objet i, i ∈ Ml,miss(i) Figure 13.2 – illustration des diff´erents ´echanges pour une hi´erarchie coop´erative En utilisant l’´equation (13.1) pour trouver tc, nous pouvons calculer la probabilit´e de miss au niveau du cache k pour tout objet i missk(i) =  exp(−q(i)tc) ;i /∈ Ml exp(−q ′ (i)tc) ;i ∈ Ml . Les caches g`erent le trafic arrivant des noeuds d’acc`es. On note par θ ′ la probabilit´e de hit global de ce trafic : θ ′ = X N n=1 q(n)  1 P (1 − e −q ′ (n)tc ) + (1 − 1 P )(1 − e −q(n)tc )  / X N n=1 q(n) En cas de miss local, les requˆetes seront transmises aux caches responsables de la partition dont l’objet en question fait partie. Le cache k r´ealise un taux de hit suppl´ementaire pour ces requˆetes. La popularit´e des objets appartenant `a ces requˆetes `a l’entr´ee du cache k est q ′ (n) et la probabilit´e de hit de chaque objet est 1−e −q ′ (i)tc . Ces objets arrivent avec un taux q(i)e −q(i)tc et ils arrivent de P − 1 caches. Chaque cache autre que k envoie uniquement une fraction 1/P des objets ayant subi un miss au cache k, c’est-`a-dire les objets appartenant au sous-catalogue Ml . La probabilit´e de hit global du trafic d´ebordant des caches apr`es un premier essai (cache local) est exprim´ee par : θ ′′ = X N n=1 q(n)(1 − 1 P )e −q(n)tc (1 − e −q ′ (n)tc )/ X N n=1 q(n). On compare `a la figure 13.3 les r´esultats obtenus par simulation et par calcul pour les probabilit´es de hit locales θ ′ et les probabilit´es de hit suppl´ementaires dˆu `a laCHAPITRE 13. COOPERATION DE CACHES ´ 93 coop´eration θ ′′, pour un catalogue de 105 objets, pour P ´egale `a 2, 5 et 10 et pour les deux lois Zipf(0.6) et Zipf(1.2). 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 hit local c calcul simulation (a) α = 0.6 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 hit local c calcul simulation (b) α = 1.2 0 0.1 0.2 0.3 0.4 0.5 0.6 0 0.2 0.4 0.6 0.8 1 hit de coop’eration c P = 2 P = 5 P = 10 simulation calcul (c) α = 0.6 0 0.1 0.2 0.3 0.4 0.5 0.6 0 0.2 0.4 0.6 0.8 1 hit de coop’eration c P = 2 P = 5 P = 10 simulation calcul (d) α = 1.2 Figure 13.3 – Les probabilit´es de hit locales et de coop´eration en fonction de la taille de cache normalis´ee On remarque que la probabilit´e de hit locale obtenue par calcul co¨ıncide avec celle obtenue par simulation, et que cette probabilit´e est ind´ependante de P. Pour les probabilit´es de hit de coop´eration, une l´eg`ere diff´erence entre simulation et calcul est `a noter pour P = 2. Cette diff´erence diminue au fur et `a mesure que P augmente. Pour P = 10, les valeurs de simulation et de calcul sont identiques. Ces r´esultats s’expliquent par la pr´ecision de l’approximation de Che. Appliqu´ee `a un deuxi`eme niveau de caches, on s’attend `a ce que l’erreur due `a l’hypoth`ese d’ind´ependance soit faible si le nombre de caches de premier niveau est assez grand (n > 5). On note θ la probabilit´e de hit global au premier niveau : θ = θ ′ + θ ′′. Pour un cache94 13.2. CACHES COOPERATIFS ´ de taille C, le coˆut global de la structure est : cout(C) = Ak′ b P − 1 P (1 − θ ′ ) + Akb(1 − θ) + nkmC. Cet algorithme est inspir´e du load-sharing et chaque cache ne peut d´epasser la taille de M/P. La taille normalis´ee du cache peut donc s’´ecrire c = CP/M. On trace la probabilit´e θ(c/P) en fonction de c pour diff´erentes valeurs de P pour la loi Zipf(0.6). Les r´esultats sont pr´esent´es `a la figure 13.2. 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 θ(c/P) c P = 1 P = 2 P = 5 P = 10 Figure 13.4 – Probabilit´e de hit global θ(c/P) On remarque que θ(c) > θP (c/P) pour P ≥ 2 o`u θ(c) correspond `a la probabilit´e de hit au premier niveau sans coop´eration (P = 1). On note ˜θ la probabilit´e de hit locale des objets qui ne font pas partie de la partition du cache. On a ˜θ(c) < θ′ (c) et θp(c) < θ(cp). Divisant par nkmM, le coˆut normalis´e peut s’exprimer : δcc(c) = Γ(1 − θP (c)) + Γk ′ b kb (1 − 1 P )(1 − ˜θ(c)) + c/P. Tout calcul fait : δcc(c) > δ(c) + (1 − 1 P )(Γk ′ b kb (1 − θ ′ (c)) − c). Pour savoir quelle architecture est la plus rentable, il faut donc ´evaluer la quantit´e Γ k ′ b kb (1 − θ ′ (c)) − c. On pose f(c) = Γk ′ b kb (1 − θ ′ (c)) − c. La fonction f(c) est minimale si θ ′ (c) et c sont maximales, ce qui correspond `a un stockage complet au premier niveau, quel que soitCHAPITRE 13. COOPERATION DE CACHES ´ 95 la valeur de k ′ b /kb et de Γ. La coop´eration est moins rentable qu’une hi´erarchie simple si la taille des caches de premier niveau est grande. La conclusion d´epend encore des coˆuts relatifs k ′ b et kb. Notons que, plus le coˆut de bande passante augmente relatif au coˆut des caches, plus il s’av`ere inutile de faire coop´erer les caches. 13.3 Routage orient´e contenu Notre ´etude est favorable `a un stockage complet `a l’Edge puisque le tradeoff entre bande passante et m´emoire est optimal dans le cas d’un stockage entier au premier niveau. Nos r´esultats sont soutenus par d’autres ´etudes telles que [59] et [5]. Cependant, une autre ´etude remet en question ces r´esultats, les jugeant insuffisants car ils comparent un r´eseau de caches non optimal avec un caching `a l’Edge ce qui est pour les auteurs simpliste. Effectivement, [44] met en doute les r´esultats constat´es du fait que la comparaison n’a pas ´et´e faite avec une hi´erarchie de caches optimale. Avec un couplage meta-caching/strat´egie de forwarding, l’´ecart entre une hi´erarchie de caches optimale et un stockage `a l’edge peut s’av´erer beaucoup plus important. Nous nous int´eressons `a l’influence que peut avoir l’utilisation d’une hi´erarchie de caches plus efficace que la hi´erarchie LRU utilisant SPF (shortest path first) comme politique de forwarding. Nous souhaitons utiliser les caches pour obtenir des taux de hit assez grands (plus de 90%). Dans ce cas, l’efficacit´e de la politique de m´eta-caching LCD tend vers celle d’une politique LCE. La seule question restant `a traiter est l’influence de la politique de forwarding sur les coˆuts. On consid`ere une hi´erarchie de caches LRU `a deux niveaux. On note n le nombre de caches au premier niveau. Les caches au premier niveau ont la mˆeme taille C et on consid`ere une demande sym´etrique de donn´ees. Ces caches sont reli´es `a un cache de niveau 2 stockant la totalit´e du catalogue. Nous ´etudions donc l’optimum dans le cas d’un taux de hit de 100%. Chaque cache au premier niveau est reli´e `a tous les autres caches par des liens et le coˆut de bande passante de chaque lien est kb. Le coˆut de bande passante des liens reliant le cache du premier niveau au cache du deuxi`eme niveau est k ′ b . On note θ ′ le taux de hit local dˆu au hit des objets demand´es par les utilisateurs et on note θ ′′ le taux de hit dˆu `a la coop´eration. Le taux de hit global au premier niveau est θ = θ ′ + θ ′′. En utilisant les simulations, on trace θ ′ et on le compare `a hit(c) le taux de hit au premier niveau d’une hi´erarchie SPF pour un catalogue de M = 104 objets. On remarque que θ ′ est ´egal au taux de hit d’un cache LRU simple, la valeur de n ne changant rien `a ce constat. Le coˆut de cette hi´erarchie peut donc ˆetre exprim´e par : cost = Akb(1 − θ(c)) + Ak′ b θ ′′ + nkmC. On normalise cette formule et on trouve : costN (c) = δ(c) + Aθ′′(k ′ b − kb).96 13.3. ROUTAGE ORIENTE CONTENU ´ 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 θ ′ c hit1(c) θ ′ (a) Zipf(0.6) 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 T auxdehit c hit1(c) θ ′ (b) Zipf(1.2) Figure 13.5 – Probabilit´e de hit locale θ ′ et hit(c) compar´es par simulation Puisque k ′ b < kb, costN (c) < δ(c). Donc en utilisant une politique de forwarding NRR, on r´ealise un coˆut inf´erieur. Nous allons ´evaluer les optima dans ce cas. La popularit´e de l’objet i `a l’entr´e de chaque cache au premier niveau peut ˆetre exprim´e par : q ′ (i) = q(i)+Pn−1 k=1(mn−l (1− m) l )/l tel que m est la probabilit´e de miss de i de popularit´e q(i) pour un cache LRU. La probabilit´e de hit locale d’un objet peut ˆetre exprim´ee par : hit(n) = 1 − exp(−q ′ (n) ∗ tc) Le tc est calcul´e en utilisant l’´equation modifi´ee de Che : PM i=1(1 − exp(−q ′ (i) ∗ tc) = C La probabilit´e de hit locale est exprim´ee par : θ ′ = PM i=1 q(i) ∗ (1 − exp(−q ′ (i) ∗ tc)) La probabilit´e de hit de coop´eration est exprim´ee par :θ ′′ = PM i=1 q(i) ∗ exp(−q ′ (i) ∗ tc) ∗ (1 − exp(−(n − 1) ∗ tc ∗ q ′ (i))) On compare les r´esultats de calcul avec les r´esultats de simulation pour un catalogue de 104 objets, n prenant les valeurs de 10,20,40 et 100. Les calculs sont effectu´ees pour une loi Zipf(0.6) mais les conclusions sont vrai pour tout α. Les r´esultats du hit local et du hit de coop´eration sont repr´esent´es dans les graphs 13.6(a) et 13.6(b) On remarque que les hit locaux calcul´es par la m´ethode de Che modifi´ee co¨ıncident exactement avec les probabilit´es de hit r´ecup´er´es des simulations, et ces taux de hit sont ind´ependants de la valeur de n. D’autre part, on note une diff´erence entre le taux de hit de coop´eration r´ecup´er´e des calculs, et le taux de hit obtenu par simulation pour n = 5 et n = 10, mais cette diff´erence disparait pour des tailles de caches grands. Pour n = 100 aucune diff´erence est `a noter entre les deux m´ethodes calcul et simulation. Le cout d’une hi´erarchie NRR est estim´ee `a : cost = n∗km ∗C +A∗kb ∗(1−θ)+A∗k ′ b ∗θ ′′CHAPITRE 13. COOPERATION DE CACHES ´ 97 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 hit local c simulation calcul (a) hit local 0 0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 hit de coope ′ration c simulation calcul n = 5 n = 10 n = 50 n = 100 (b) hit coop´eration Figure 13.6 – Probabilit´e de hit compar´es par simulation et calcul le cout normalis´e est estim´e `a : costn = c + Γ(1 − θ) + Γ ∗ ( k ′ b kb ) ∗ θ ′′ On trace la taille de cache optimale en fonction de Γ et k ′ b /kb On remarque que pour les valeurs futures 0 1 2 3 4 5 Γ 0 0.2 0.4 0.6 0.8 1 k ′ b kb 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Figure 13.7 – Taille de cache normalis´ee optimale en fonction de Γ et k ′ b /kb du Γ nominal, et pour un k ′ b /kb=0.8 la solution optimale consiste `a tout stocker au98 13.3. ROUTAGE ORIENTE CONTENU ´ premier niveau de caches.Chapitre 14 Hierarchies alternatives ´ 14.1 Coˆut d’une hi´erarchie de caches `a plusieurs niveaux 14.1.1 Evaluation des coˆuts Sem Borst et al. [52] affirment qu’il n’y a aucun int´erˆet `a distribuer des caches sur plus de deux niveaux. Cette affirmation a attir´e notre curiosit´e. Pour v´erifier ceci, on consid`ere une hi´erarchie de caches `a 5 niveaux. L’approximation de Che ´etant bonne pour tous les niveaux de caches, on l’utilise pour calculer la probabilit´e de hit globale de la structure ainsi que la probabilit´e de hit `a chaque niveau. Pour simplifier notre analyse, on consid`ere le cas d’une hi´erarchie homog`ene et sym´etrique en arbre `a nblevel niveaux. On se restreint dans cette ´etude `a 5 niveaux de caches (nblevel = 5). Le cache de niveau 5 est la racine de l’arbre et n’a pas de parent. Chaque noeud a le mˆeme nombre nbf de fils. A chaque niveau i de l’arbre, les caches ont la mˆeme taille Ti . On fixe nbf = 5. On consid`ere 3 cas : – une r´epartition ´equitable de m´emoire `a tous les niveaux, Ti = Ti+1 pour tout i, – une r´epartition favorisant les caches aux premiers niveaux Ti+1 = Ti/2, – une r´epartition favorisant les caches sup´erieurs Ti+1/2 = Ti . Le catalogue a une taille M. Notre objectif est de comparer les diff´erents cas en terme de coˆuts de m´emoire et de bande passante tout en pr´eservant la mˆeme valeur de probabilit´e de hit global. 99100 14.1. COUT D’UNE HI ˆ ERARCHIE DE CACHES ´ A PLUSIEURS NIVEAUX ` 1 2 3 nb_f Figure 14.1 – Hi´erarchie de caches `a 5 niveaux On note pmissi la probabilit´e de miss au niveau i. Le coˆut de la structure est : cout = Akb nblevel X−1 k=1 Y k i=1 pmissi + km nblevel X i=1 Ti(nbf ) nblevel−i . On note coutn le coˆut normalis´e en divisant le coˆut par kmMn, n ´etant le nombre total de caches. On pose Γ = Akb kmMn . Alors coutn = Γ( nblevel X−1 k=1 Y k i=1 pmissi ) + nblevel X i=1 tinbnblevel−i f /n. La figure 14.1.1 repr´esente les r´esultats obtenus pour diff´erentes valeurs de Γ. La valeur nominale de Γ est de 0.12. Le stockage favorisant les premiers niveaux est optimal juqu’`a la valeur d’un taux de hit global de 93%. Le stockage favorisant les premiers niveaux est toujours optimal si Γ ≥ 0.16. Il est probable que cette valeur soit bientˆot atteinte puisque Γ est en augmentation permanente du fait de l’augmentation rapide de la demande entrainant une augmentation de la valeur de d´ebit. Actuellement les coˆuts de la m´emoire baissent plus vite que les coˆuts de la bande passante et Γ augmente de plus en plus d´epassant actuellemnt la valeur de 0.12. Il est vrai que la popularit´e ne suit pas une loi Zipf(0.6) mais plutˆot une loi compos´ee de Zipf(0.6) et Zipf(0.8), mais dans tous les cas, la tendance future est le stockage entier au premier niveau en ´evitant la maintenance excessive de la bande passante entre routeurs. La r´epartition des caches n’est pas forc´ement gagnante pour un op´erateur ou un fournisseur de contenu puisqu’il faut prendre en compte les coˆuts ´elev´es de la bande passante par rapport aux coˆuts de la m´emoire.CHAPITRE 14. HIERARCHIES ALTERNATIVES ´ 101 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0 0.2 0.4 0.6 0.8 1 coutn hitg same size lower levels favored higher level favored (a) Γ = 0.01 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0 0.2 0.4 0.6 0.8 1 coutn hitg same size lower levels favored higher level favored (b) Γ = 0.08 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0 0.2 0.4 0.6 0.8 1 coutn hitg same size lower levels favored higher level favored (c) Γ = 0.12 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0 0.2 0.4 0.6 0.8 1 coutn hitg same size lower levels favored higher level favored (d) Γ = 0.15 Figure 14.2 – Coˆuts normalis´es pour diff´erentes valeur de Γ 14.1.2 Coop´eration de caches On restreint notre ´etude dans cette section au cas d’une r´epartition ´equitable de m´emoire comme c’est le cas pour CCN. Notre objectif est de d´eterminer le gain en m´emoire et en bande passante en comparant le cas d’une coop´eration des caches et le cas d’une non-coop´eration des caches. Il est clair que le gain en m´emoire qu’on peut avoir avec une coop´eration est tr`es int´eressant mais par ailleurs le gain en bande passante d´ecroit. On choisit la coop´eration par r´epartition du catalogue, c’est-`a-dire que chaque niveau de cache est destin´e `a stocker 1/5 du catalogue. Ainsi, on stocke le chunk num´ero i dans le niveau i (mod 5). Puisque les niveaux de caches traitent des catalogues disjoints et que les chunks suivent la mˆeme loi de popularit´e que les objets, il est simple de trouver la probabilit´e de hit des caches `a chaque niveau.102 14.2. COUTS ET POLITIQUES DE REMPLACEMENT ˆ La quantit´e de m´emoire utilis´ee est : Pnblevel i=1 C1(nbf ) nblevel−i . On note hiti(c1) la probabilit´e de hit d’un cache de taille normalis´ee c1 pour le niveau de cache i pour une hi´erarchie de caches p`ere-fils et un catalogue de taille M. La bande passante utilis´ee pour la hi´erarchie sans coop´eration est : nblevel X−1 i=1 (nbf ) nblevel−i (1 − hiti(c1)). 0 0.5 1 1.5 2 2.5 3 3.5 4 0 0.2 0.4 0.6 0.8 1 bande passante/A hitg caches non cooperatives caches cooperatives (a) Bande passante 0 5e+07 1e+08 1.5e+08 2e+08 2.5e+08 3e+08 3.5e+08 4e+08 0 0.2 0.4 0.6 0.8 1 Memory hitg caches non cooperatives caches cooperatives (b) M´emoire Figure 14.3 – Comparaison entre caches coop´eratifs et non coop´eratifs On remarque que les caches coop´eratifs utilisent moins de m´emoire pour obtenir la mˆeme probabilit´e de hit global. Cependant, la quantit´e de bande passante consomm´ee par les caches coop´eratifs est plus importante que la quantit´e de bande passante consomm´ee par les caches non coop´eratifs. 14.2 Coˆuts et politiques de remplacement 14.2.1 Politique LFU On consid`ere une hi´erarchie en arbre de caches LFU avec les objets stock´es du niveau bas au niveau sup´erieur suivant l’ordre d´ecroissant de leur popularit´e. La politique de forwarding est une politique de recherche p`ere/fils puisque le fils cherche l’objet en suivant le chemin le plus court menant au serveur d’origine qui est plac´e au niveau sup´erieur de la hi´erarchie. On consid`ere alors un catalogue de M objets class´es selon un ordre d´ecroissant de popularit´e : o1, o2, o3, ..., oM. La taille des caches au niveau i est ci . La figure 14.4 repr´esente notre hi´erarchie `a ´etudier et le tableau 14.2.1 pr´esente les param`etres.CHAPITRE 14. HIERARCHIES ALTERNATIVES ´ 103 niveau n niveau n−1 C1 niveau 1 Cn−1 Cn Figure 14.4 – R´eseau de caches avec une politique LFU M taille du catalogue Ci taille du cache au niveau i ci taille du cache au niveau i normalis´ee ci = Ci/M Pmi probabilit´e de miss de la hierarchie jusqu’au niveau i kb coˆut unitaire de la bande passante km coˆut unitaire de la m´emoire A d´ebit d’entr´ee `a la hierarchie nbi nombre de caches au niveau i Pmcible la probabilit´e de miss global cibl´ee La probabilit´e de miss au premier niveau Pm1 peut ˆetre exprim´e pour LFU par : Pm1 = M1−α − C 1−α 1 M1−α (14.1) ou Pm1 = 1 − c 1−α 1 . D’une mani`ere g´en´erale, la probabilit´e de miss de la hi´erarchie de caches constitu´ee des niveaux 1 `a i est exprim´ee par : Pmi = 1 − ( X i k=1 ck) 1−α . (14.2) On suppose la probabilit´e de hit globale de la hi´erarchie est fix´ee `a une valeur cible : Pmg = 1 − ( Xn k=1 ck) 1−α d’o`u cn = (1 − Pmg ) 1/(1−α) − nX−1 k=1 ck. (14.3) La fonction de coˆut peut ˆetre exprim´ee par :104 14.2. COUTS ET POLITIQUES DE REMPLACEMENT ˆ cout = Akb( nX−1 k=1 pmk ) + nX−1 k=1 (nbk − nbn)Ckkm On pose Γ′ = Akb M km . On divise la fonction de coˆut par une constante kmM et on obtient : coutN = nX−1 k=1 Γ ′ (1 − ( X k i=1 ci) 1−α ) + nX−1 i=1 (nbi − nbn)ci . L’optimum v´erifie ∂coutN ∂c1 = 0 et ∂coutN ∂c2 = 0, pour une probabilit´e de hit global de 1 : c1 = M in(  Γ ′ (1 − α) (nb1 − nb2) 1/α , 1). En posant Γ = Γ ′ nb1 − nb2 , on obtient : c1 = M in(1,(Γ(1 − α))1/α). (14.4) A la figure 14.5, on trace la valeur de l’optimum en fonction de α. 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Γ = 1 Γ = 2 Γ = 3 Γ = 5 Figure 14.5 – La taille de cache optimale en fonction de α. On remarque que plus Γ augmente, plus l’optimum correspond `a un stockage au premier niveau de cache. Pour α = 0.8, `a partir de Γ = 5 l’optimum correspond `a un stockage entier `a l’edge. Nous nous int´eressons de plus `a la diff´erence de coˆuts entre LRU et LFU, les r´esultats sont repr´esent´es sur la figure 14.6. On remarque que la diff´erence de coˆuts entre politiques LRU et LFU diminue quand la taille des caches augmente. Donc il n’est pas utile d’impl´ementer une politique mat´eriellement coˆuteuse comme LFU car LRU suffit.CHAPITRE 14. HIERARCHIES ALTERNATIVES ´ 105 0 1 2 3 4 5 6 Γ 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 taille de caches normalis´e 0 5 10 15 20 25 30 (a) α = 0.6 0 1 2 3 4 5 6 Γ 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 taille de caches normalis´e 0 5 10 15 20 25 30 35 40 (b) α = 1.2 Figure 14.6 – Diff´erence entre coˆuts LRU et LFU en % 14.2.2 Politique Random La politique Random est une concurrente forte de LRU, son impl´ementation mat´erielle est simple et ses performances ne s’´eloignent pas de celles de LRU. Dans cette section nous ´etudions le tradeoff de cette politique. En utilisant la mˆeme ´equation des coˆuts pour la hi´erarchie LRU, le coˆut d’une hi´erarchie de caches Random est exprim´e par : costN = Γ(1 − h) + c o`u h est la probabilit´e de hit globale de la hi´erarchie, et c est la taille de cache normalis´ee au premier niveau. Avec la politique Random, nous tra¸cons `a la figure 14.7 la valeur de l’optimum en fonction du Γ pour diff´erentes valeurs de α. Nous distinguons les cas α < 1 et α > 1. On remarque que l’optimum correspond `a un 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.5 1 1.5 2 2.5 3 3.5 Cache Optimale Γ α = 0.6 α = 0.7 α = 0.8 α = 0.9 (a) α < 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0 1 2 3 4 5 6 Cache Optimale Γ α = 1.1 α = 1.2 α = 1.3 α = 1.4 (b) α > 1 Figure 14.7 – Tailles de caches optimales en fonction de Γ106 14.2. COUTS ET POLITIQUES DE REMPLACEMENT ˆ stockage complet `a l’Edge pour des arriv´ees suivant la loi Zipf(0.6) `a partir d’une valeur de Γ = 1.5. On conclut que mˆeme pour une politique Random, et compte tenu des valeurs de Γ selon nos estimations, un stockage complet `a l’edge correspond `a la solution optimale. Par ailleurs, quand la taille des caches est proche de la taille du catalogue, les probabilit´es de hit LRU et Random sont tr`es proches. L’utilisation de la politique Random devient int´eressante alors, car cette derni`ere est moins coˆuteuse mat´eriellement que LRU.Chapitre 15 Conclusion Dans cette partie, nous ´evaluons le coˆut d’une hi´erarchie de caches en prenant en compte le coˆut de la m´emoire et le coˆut de la bande passante. Nous utilisons la formule de Che pour ´evaluer num´eriquement ce tradeoff. Le coˆut optimal d´epend de la valeur du rapport Γ = kcA/(M kmn) ainsi que de la loi de popularit´e des objets. Nos r´esultats sugg`erent que dans un futur proche, l’optimum correspondra `a un stockage complet `a l’edge. Mais cette ´etude ´etant r´ealis´ee avec une fonction de coˆut lin´eaire, et avec des estimations non exacts des facteurs impactant les coˆuts, on ne peut la consid´erer que comme une premi`ere ´evaluation. Les op´erateurs poss´edant plus de d´etails et pr´ecisions pourraient adapter cette ´etude en int´egrant des fonctions de coˆuts r´eels. N´eanmoins, g´erer un grand cache est plus compliqu´e que la gestion d’un petit cache, et les performances et la rapidit´e de r´eponse d’un cache d´ependent de sa taille. Dans ce cas, chaque cache `a l’edge peut ˆetre lui-mˆeme distribu´e localement en un ensemble de caches. L’op´erateur pourrait d´edier `a titre d’exemple un ou plusieurs caches de taille maximale `a chaque fournisseur de contenu. Nous pensons que les fonctions de stockage et de gestion de contenu sont ind´ependantes. L’op´erateur ne peut en plus des fonctions de routage, fournir des r´eponses aux requˆetes d’utilisateurs, v´erifier les donn´ees en supprimant les donn´ees ill´egales par exemple, en mettant `a jour une donn´ee, etc. Le fait de centraliser les donn´ees permet de r´ealiser rapidement des op´erations de mise `a jour sur les donn´ees. 107Conclusion gen´ erale ´ L’Internet devient centr´e sur les contenus, 90% des ´echanges sur internet ´etant des consultations de sites Web, des t´el´echargements de fichier, ou des streamings audio ou vid´eo. La proposition CCN de Jacobson et al. vient donc au bon moment et suscite un grand int´erˆet. L’objectif de cette th`ese ´etait de rajouter `a la proposition CCN des fonctionnalit´es de gestion du trafic. En effet le protocole de transport propos´e au d´ebut n’offrait pas un bon d´ebit, puisque la d´etection de rejet se basait uniquement sur le timeout. D’autre part les paquets Data suivant le sens inverse des paquets Interest ne suffit pas pour assurer un partage ´equitable de bande passante et la protection des flux sensibles. Nous avons propos´e une solution dite “flow aware networking”, inspir´ee de travaux ant´erieurs sur IP o`u cette mani`ere de g´erer le traffic par flot a prouv´e son efficacit´e. Nous proposons ´egalement l’utilisation de la d´etection rapide de congestion pour rendre plus efficaces les protocoles de transport. L’interest Discard est un nouveau m´ecanisme con¸cu sp´ecialement pour les r´eseaux CCN permettant de limiter les rejets de paquets Data en supprimant s´electivement des paquets Interest en cas de congestion. Avec les r´eseaux orient´es contenus, on cherche les donn´ees dans n’importe quelle destination poss´edant le contenu. Dans ce contexte, les protocoles multipaths semblent prometteurs. Nous avons observ´e cependant que le t´el´echargement des donn´ees de sources multiples “pollue” les caches et d´et´eriore ainsi la probabilit´e de hit globale de l’architecture. Utiliser les chemins les plus courts pour tous les flux tant que la charge des liens ne d´epasse pas un seuil maximal s’av`ere suffisant. Les chemins longs ne doivent ˆetre utilis´es que lorsque leur charge est faible, sauf bien entendu en cas d’une panne au niveau du chemin le plus court. Les caches sont des acteurs majeurs dans la gestion du trafic et l’´etude de leur performance est essentielle. Il est n´ecessaire notamment d’´evaluer la mani`ere dont devrait ˆetre r´eparti les contenus dans une hi´erarchie de caches. La simulation ´etant coˆuteuse, puisque toute simulation de catalogue tr`es volumineux consomme beaucoup de temps, nous avons utilis´e des calculs approch´es `a l’aide de la formule de Che. Cette formule 108CHAPITRE 15. CONCLUSION 109 donne le taux de hit d’un cache de taille donn´ee sous l’hypoth`ese d’ind´ependance antre les arriv´ees de requˆetes. Elle s’av`ere tr`es pr´ecise et facile `a utiliser ´etant valable pour tout loi de popularit´e et toute taille de cache. L’utilisation de cette formule peut s’´etendre `a deux ou plusieurs niveaux de caches, `a condition que le nombre de cache au niveau inf´erieur soit grand (sup´erieur ou ´egale `a 5, d’apr`es nos ´etudes) afin de garantir l’ind´ependance des requˆetes. En utilisant ce mod`ele math´ematique, et avec des popularit´es et tailles de catalogues s’approchant de la r´ealit´e, nous avons pu ´etudier les perfomances d’une hierarchie de caches LRU. Dans un article r´ecent [59], Fayazbakhsh et al. se demandent s’il est vraiment n´ecessaire de distribuer les caches dans une hierarchie. D’autre part les CDNs rencontrent un succ`es ´enorme et sont op´erationnelles depuis des ann´ees. Pour un op´erateur, l’enjeu principale dans le choix d’une architecture orient´e contenu est le coˆut et la difficult´e de mise en place. Au niveau de la difficult´e de mise en place les CDN sont sans contestation mieux puisqu’ils sont d´eja op´erationnels. Le savoir faire dans ce domaine est fleurissant contrairement aux ICN qui manquent toujours d’une solution claire pour le routage, pour l’identification des objets dans le r´eseau ainsi que le changement des fonctionnalit´es des routeurs pour effectuer le stockage. Au niveau des coˆuts, nous ne pouvons estimer pr´ecis´ement laquelle des architectures est la moins coˆuteuse. Il est ´egalement difficile d’estimer tous les coˆuts possibles et d’avoir un mod`ele de coˆut fiable s’approchant des mod`eles utilis´es par les op´erateurs. Ne pouvant affranchir le pas de la confidentialit´e des donn´ees des op´erateurs, nous nous contentons d’estimer les coˆuts en prenant en compte les coˆuts de la m´emoire et de la bande passante. Nous adoptons un simple mod`ele de coˆut lin´eaire permettant une comparaison chiffr´ee quoique grossi`ere des diff´erentes options. Nous consid´erons qu’une hi´erarchie est mieux qu’une autre si le coˆut global incluant le coˆut des caches et le coˆut de la bande passante est plus faible. Notre objectif revient `a trouver un tradeoff optimal, puisque une hierarchie distribu´e est coˆuteuse en m`emoire mais ne coˆute rien en bande passante, alors qu’une hi´erarchie centralis´ee coˆute moins cher en m´emoire mais est plus coˆuteuse en bande passante. Suite aux r´esultats de nos ´etudes, nous recommandons un stockage presque complet `a l’edge. Cette solution paraˆıt optimale sutout dans un avenir proche car le coˆut des m´emoires baisse beaucoup plus vite que celui de la bande passante. D’autres ´etudes remettent en question cette conclusion, la jugeant rapide puisque certaines politiques de meta caching et forwarding am´eliorent la probabilit´e de hit des caches au premier niveau et r´eduisent donc le coˆut de la bande passante. Nous avons approfoni l’´etude de certains cas, dont celui de caches coop´eratives avec une politique de forwarding NRR (Nearest Replica Routing). Dans ce cas pour une hierarchie `a deux niveaux l’optimum correspond bien `a un stockage `a l’edge. Alors que Borst et al. [52] assurent qu’il n’ y a aucun avantage `a distribuer les contenus sur plusieurs niveaux de caches, cette affirmation n’´est pas accompagn´e de preuve. Nous avons donc estim´e les coˆuts pour une hierarchie `a plusieurs niveaux avec politique LRU. Les constats restent les mˆemes, il est plus rentable `a moyen terme d’utiliser de110 grands caches `a l’edge. On devrait poursuivre cette ´evaluation avec, par exemple, une politique de remplacement LCD et un routage NRR mais nos r´esultats pr´eliminaires mettent s´erieusement en question la notion CCN de mettre des caches dans tous les routeurs. Nos r´esultats s’accordent avec ceux de Fayazbakhsh et al. [59], mˆeme si les mod`eles utilis´es sont tr`es diff´erents. Un autre probl`eme pos´e par CCN est la difficult´e de gestion de donn´ees dans les caches. Si un fournisseur de donn´ees souhaite supprimer un objet, il est difficile de parcourir toute la hierarchie pour supprimer l’objet ou le mettre `a jour. Une hi´erarchie avec peu de niveaux est plus facile `a g´erer. Compte tenu des doutes concernant le coˆut ´elev´e de CCN, de la difficult´e de mise en oeuvre n´ecessitant des modifications majeures, de la n´ecessit´e de mettre en place une strat´egie de gestion de noms d’objets et leur authentifications, et de la difficult´e `a g´erer les donn´ees sur des serveurs distribu´es, il nous parait pr´ef´erable de stocker tous les objets `a l’edge tout proche des usagers. De grands caches `a ce niveau pourraient ˆetre sp´ecialis´e par fournisseur de contenus pour faciliter la gestion. Chaque objet s’identifierait d’abord par son fournisseur, qui a la responsabilit´e d’assurer l’unicit´e de l’objet et son authentification, ainsi que la s´ecurit´e de ses objets. L’op´erateur peut prendre en charge la fonctionnalit´e du caching `a l’edge en accord avec les fournisseur de contenus et attribuer `a chaque fournisseur un ou plusieurs caches. L’op´erateur peut devenir lui aussi fournisseur de contenus. Ceci bien sur peut ˆetre conclu `a travers des accords commerciaux entre les diff´erents acteurs. La fonctionnalit´e de l’internet serait alors surtout localis´ee `a l’edge du r´eseau de l’op´erateur. Certaines fonctionnalit´es propos´es dans CCN peuvent bien entendu ˆetre utiles dans cette architecture comme, par exemple, l’utilisation des noms d’objets au lieu des adresses IP. Toute utilisateur demanderait un objet avec le nom du fournisseur suivi du nom d’objet et c’est le routeur d’acc`es qui va, soit envoyer la donn´e demand´e `a travers ces caches `a l’edge, soit rediriger la demande vers le fournisseur de contenus. Pour les travaux futurs, nous souhaitons approfondir l’´etude du tradeoff m´emoire/bande passante en utilisant des mod`eles de coˆuts plus r´ealistes, et pour des hi´erarchies optimales NRR/LCD, ou des caches coop´eratives pour plusieurs niveaux de caches. Nous souhaitons aussi compl´eter notre ´etude sur les multipaths et leurs performances, d’analyser l’impact des caches et la mani`ere de les g´erer sur les performances des multipaths. Nous souhaitons aussi adapter la formule de Che `a plusieurs cas, notament pour le cas d’une hierarchie LCD `a plusieurs niveau de caches. Il est aussi important d’´evaluer l’´evolution des popularit´es des objets et leurs tailles.Ref´ erences ´ [1] T. Koponen, M. Chawla, G.-B. Chun, A. Ermolinskiy, H. Kim, S. Shenker, and I. Stoica, “A data-oriented (and beyond) network architecture,” ACM SIGCOMM Computer Communication Review, vol. 37, no. 4, pp. 181–192, 2007. [2] V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs, and R. Braynard, “Networking named content,” in CoNext 2009, 2009. [3] B. Ahlgren, M. D’Ambrosio, M. Marchisio, I. Marsh, C. Dannewitz, B. Ohlman, K. Pentikousis, O. Strandberg, R. Rembarz, and V. Vercellone, “Design considerations for a network of information,” Proceedings of the 2008 ACM CoNEXT Conference, 2008. [4] “Publish-subscribe internet routing paradigm.” http://psirp.hiit.fi/. [5] A. Ghodsi, S. Shenker, T. Koponen, A. Singla, B. Raghavan, and J. Wilcox, “Information-centric networking : seeing the forest for the trees,” in Proceedings of HotNets-X, pp. 1 :1–1 :6, 2011. [6] S. Fdida and N. Rozhnova, “An effective hop-by-hop interest shaping mechanism for ccn communications,” in in IEEE NOMEN Workshop, co-located with INFOCOM, 2012. [7] G. Carofiglio, M. Gallo, and L. Muscariello, “Joint hop-by-hop and receiverdriven interest control protocol for content-centric networks,” ACM SIGCOMM Workshop on Information Centric Networking (ICN’12), 2012. [8] G. Carofiglio, M. Gallo, and L. Muscariello, “Icp : Design and evaluation of an interest control protocol for content-centric networking,” IEEE NOMEN Workshop, co-located with INFOCOM, 2012. [9] D. Rossi and G. Rossini, “Caching performance of content centric networks under multi-path routing (and more).” Technical report, Telecom ParisTech, 2011. [10] P. R. Jelenkovic, “Approximation of the move-to-front search cost distribution and least-recently-used caching fault probabilities,” Annals of Applied Probability, vol. 9, no. 2, pp. 430–464, 1999. 111112 REF´ ERENCES ´ [11] P. Gill, M. Arlitt, Z. Li, and A. Mahanti, “Youtube traffic characterization : a view from the edge,” in Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, IMC ’07, (New York, NY, USA), pp. 15–28, ACM, 2007. [12] K.Gummadi, R. S.saroiu, S.Gribble, A.Levy, and J.Zahorjan., “Measurement, modeling and analysis of a peer-to-peer file shraing workload.,” in SOSP’03, 2003. [13] M. Cha, H. Kwak, P. Rodriguez, Y.-Y. Ahn, and S. Moon, “I tube, you tube, everybody tubes : analyzing the world’s largest user generated content video system,” in Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, IMC ’07, (New York, NY, USA), pp. 1–14, ACM, 2007. [14] G. Appenzeller, I. Kesslassy, and N. McKeown, “Sizing router buffers,” in SIGCOMM 2004, 2004. [15] J.Nagle, “On packet switches with infinite storage,” in RFC 970, 1985. [16] S. Oueslati and J. Roberts, “A new direction for quality of service : Flow aware networking,” in NGI 2005, 2005. [17] R. Pan, L. Breslau, B. Prabhakar, and S. Shenker, “Approximate fair dropping for variable length packets,” ACM Computer Communications Review, vol. 33, no. 2, pp. 23–39, 2003. [18] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury, “Buffer management schemes for supporting TCP in gigabit routers with per-flow queueing,” IEEE JSAC, vol. 17, no. 6, pp. 1159–1169, 1999. [19] A. Kortebi, L. Muscariello, S. Oueslati, and J. Roberts, “Evaluating the number of active flows in a scheduler realizing fair statistical bandwidth sharing,” in ACM Sigmetrics, 2005. [20] S. Ben Fredj, T. Bonald, A. Proutiere, G. R´egni´e, and J. W. Roberts, “Statistical bandwidth sharing : a study of congestion at flow level,” SIGCOMM Comput. Commun. Rev., vol. 31, no. 4, 2001. [21] B. Briscoe, “Flow rate fairness : Dismantling a religion,” SIGCOMM Comput. Commun. Rev., vol. 37, no. 2, pp. 63–74, 2007. [22] M. Shreedhar and G. Varghese, “Efficient fair queueing using deficit round robin,” SIGCOMM Comput. Commun. Rev., vol. 25, pp. 231–242, October 1995. [23] T. Bonald, M. Feuillet, and A. Prouti´ere, “Is the ”law of the jungle” sustainable for the internet ?,” in INFOCOM, 2009. [24] P. Key and L. Massouli´e, “Fluid models of integrated traffic and multipath routing,” Queueing Syst. Theory Appl., vol. 53, pp. 85–98, June 2006. [25] D. Wischik, C. Raiciu, A. Greenhalgh, and M. Handley, “Design, implementation and evaluation of congestion control for multipath tcp,” in NSDI’11 Proceedings of the 8th USENIX conference on Networked systems design and implementation, 2011.REF´ ERENCES ´ 113 [26] C. Raiciu, D. Wischik, and M. Handley, “Practical congestion control for multipath transport protocols,” in UCL Technical Report, 2010. [27] G. Carofiglio, M. Gallo, L. Muscariello, and M. Papalini, “Multipath congestion control in content-centric networks,” IEEE INFOCOM Workshop on emerging design choices in name oriented networking, 2013. [28] P. Viotti, “Caching and transport protocols performance in content-centric networks.” Eurocom Master Thesis, 2010. [29] Cisco, “Cisco visual networking index : Forecast and methodology, 2010-2015.” White paper, 2011. [30] A. Mahanti, C. Williamson, and D. Eager, “Traffic analysis of a web proxy caching hierarchy,” IEEE Network, pp. 16–23, May/June 2000. [31] J.Zhou, Y. Li, K. Adhikari, and Z.-L. Zhang, “Counting youtube videos via random prefix sampling,” in Proceedings of IMC’07, 2011. [32] L. Breslau, P. Cao, L. Fan, G. Phillips, and S. Shenke, “Web caching and zipflike distributions : evidence and implications,” INFOCOM ’99. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, 1999. [33] Y. Carlinet, B. Kauffmann, P. Olivier, and A. Simonian, “Trace-based analysis for caching multimedia services.” Orange labs technical report, 2011. [34] H. Yu, D. Zheng, B. Y. Zhao, and W. Zheng, “Understanding user behavior in large-scale video-on-demand systems,” SIGOPS Oper. Syst. Rev., vol. 40, pp. 333–344, April 2006. [35] P. Jelenkovic, X. Kang, and A. Radovanovic, “Near optimality of the discrete persistent caching algorithm,” Discrete Mathematics and Theoretical Computer Science, pp. 201–222, 2005. [36] G. Carofiglio, M. Gallo, and L. Muscariello, “Bandwidth and storage sharing performance in information centric networking,” in ACM Sigcomm workshop on ICN, 2011. [37] E.Rosensweig, J. Kurose, and D.Towsley, “Approximate models for general cache networks,” in Infocom, 2010. [38] A. Dan and D.Towsley, “An approximate analysis of the lru and fifo buffer replacement schemes,” in SIGMETRICS, 1990. [39] H. Che, Y. Tung, and Z. Wang, “Hierarchical web caching systems : modeling, design and experimental results,” IEEE JSAC, vol. 20, no. 7, pp. 1305–1314, 2002. [40] C. Fricker, P. Robert, and J. Roberts, “A versatile and accurate approximation for lru cache performance,” in Proceedings of ITC 24, 2012. [41] M. Gallo, B. Kauffmann, L. Muscariello, A. Simonian, and C. Tanguy, “Performance evaluation of the random replacement policy for networks of caches,” ASIGMETRICS ’12, 2012.114 REF´ ERENCES ´ [42] N. Laoutaris, S. Syntila, and I. Stavrakakis, “Meta algorithms for hierarchical web caches,” in IEEE ICPCC, 2004. [43] I. Psaras, W. K. Chai, and G. Pavlou, “Probabilistic in-network caching for information-centric networks,” in Proceedings ICN ’12, (New York, NY, USA), pp. 55–60, ACM, 2012. [44] G. Rossini and D. Rossi, “Coupling caching and forwarding : Benefits, analysis, and implementation,” tech. rep., telecom-paristech. [45] K. Cho, M. Lee, K. Park, T. Kwonand, Y. Choi, and S. Pack, “Wave : Popularitybased and collaborative in-network caching for content- oriented networks,,” in IEEE INFOCOM, NOMEN, 2012. [46] W. Chai, D. He, I. Psaras, and G. Pavlou, “Cache less for more in informationcentric networks,” in IFIP NETWORKING, 2012. [47] N. Laoutaris, H. Che, and I. Stavrakakis, “The lcd interconnection of lru caches and its analysis,” Perform. Eval., vol. 63, pp. 609–634, July 2006. [48] R. Chiocchetti, D. Rossi, G. Rossini, G. Carofiglio, and D. Perino, “Exploit the known or explore the unknown ? : hamlet-like doubts in icn,” in ACM SIGCOMM,ICN, 2012. [49] R. Chiocchetti, D. Perino, G. Carofiglio, D. Rossi, and G. Rossini, “Inform : a dynamic interest forwarding mechanism for information centric networking,” in ACM SIGCOMM, ICN, 2013. [50] S. Eum, K. Nakauchi, M. Murata, Y. Shoji, and N. Nishinaga, “Catt :potential based routing with content caching for icn,” in ACM SIGCOMM, ICN, 2012. [51] C. Yi, A. Afanasyev, I. Moiseenko, L. Wang, B. Zhang, and L. Zhang, “A case for stateful forwarding plane,” Computer Communications, vol. 36, no. 7, 2013. [52] S. Borst, V. Gupta, and A. Walid, “Distributed caching algorithms for content distribution networks,” IEEE INFOCOM, 2010. [53] D. Perino and M. Varvello, “A reality check for content centric networking,” in Proceedings of the ACM SIGCOMM workshop on Information-centric networking, ICN ’11, (New York, NY, USA), pp. 44–49, ACM, 2011. [54] D. Rossi and G.Rossini, “On sizing ccn content stores by exploiting topogical information,” IEEE INFOCOM, NOMEN Worshop, 2012. [55] J. Kangasharju, J. Roberts, and K. W. Ross, “Object replication strategies in content distribution networks,” Computer Communications, pp. 367–383, 2001. [56] J. P. Nussbaumer, B. V. Patel, F. Schaffa, and J. P. G. Sterbenz, “Networking requirements for interactive video on demand,” IEEE Journal on Selected Areas in Communications, vol. 13, pp. 779–787, 1995. [57] I. Cidon, S. Kutten, and R. Soffer, “Optimal allocation of electronic content,” Computer Networks, vol. 40, no. 2, pp. 205 – 218, 2002.REF´ ERENCES ´ 115 [58] A. Wolman, G. M. Voelker, N. Sharma, N. Cardwell, A. Karlin, and H. M. Levy, “On the scale and performance of cooperative web proxy caching,” in ACM Symposium on Operating Systems Principles, pp. 16–31, ACM New York, 1999. [59] S. K. Fayazbakhsh, Y. Lin, A. Tootoonchian, A. Ghodsi, T. Koponen, B. Maggs, K. C. Ng, V. Sekar, and S. Shenker, “Less pain, most of the gain : incrementally deployable icn,” SIGCOMM ’13 Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, 2013. [60] Y. Wang, Z. Li, G. Tyson, S. Uhlig, and G. Xie, “Optimal cache allocation for content-centric networking,” ICNP, IEEE, 2013. [61] N.Carlson, G.Dan, A.Mahanti, and M. Arlitt., “A longitudinal a characterization of local and global bittorrent workload dynamics,” In Proceedings of PAM12, 2012. [62] Z. Li and G. Simon, “Time-shifted tv in content centric networks : The case for cooperative in-network caching,” In Communications (ICC), 2011. [63] J. Ni and D. Tsang, “Large-scale cooperative caching and application-level multicast in multimedia content delivery networks,” Communications Magazine, IEEE, 2005. Trigraphes de Berge apprivoises Th´eophile Trunck To cite this version: Th´eophile Trunck. Trigraphes de Berge apprivoises. Discrete Mathematics. Institut d’Optique Graduate School, 2014. French. . HAL Id: tel-01077934 https://tel.archives-ouvertes.fr/tel-01077934 Submitted on 27 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.École Normale Supérieure de Lyon THÈSE pour obtenir le grade de Docteur de l’Université de Lyon, délivré par l’École Normale Supérieure de Lyon Spécialité : Informatique préparée au Laboratoire de l’Informatique du Parallélisme dans le cadre de l’École Doctorale Info-Math présentée et soutenue publiquement par Théophile Trunck le 17 septembre 2014 Titre : Trigraphes de Berge apprivoisés Directeur de thèse : Nicolas Trotignon Jury Celina De Figueiredo, Rapporteur Frédéric Maffray, Rapporteur Stéphan Thomassé, Examinateur Nicolas Trotignon, Directeur Annegret Wagler, ExaminateurRésumé L’objectif de cette thèse est de réussir à utiliser des décompositions de graphes afin de résoudre des problèmes algorithmiques sur les graphes. Notre objet d’étude principal est la classe des graphes de Berge apprivoisés. Les graphes de Berge sont les graphes ne possédant ni cycle de longueur impaire supérieur à 4 ni complémentaire de cycle de longueur impaire supérieure à 4. Dans les années 60, Claude Berge a conjecturé que les graphes de Berge étaient des graphes parfaits, c’est-à-dire que la taille de la plus grande clique est exactement le nombre minimum de couleurs nécessaires à une coloration propre et ce pour tout sous-graphe. En 2002, Chudnovsky, Robertson, Seymour et Thomas ont démontré cette conjecture en utilisant un théorème de structure : les graphes de Berge sont basiques ou admettent une décomposition. Ce résultat est très utile pour faire des preuves par induction. Cependant, une des décompositions du théorème, la skew-partition équilibrée, est très difficile à utiliser algorithmiquement. Nous nous focalisons donc sur les graphes de Berge apprivoisés, c’est-à-dire les graphes de Berge sans skew-partition équilibrée. Pour pouvoir faire des inductions, nous devons adapter le théorème de structure de Chudnovsky et al. à notre classe. Nous prouvons un résultat plus fort : les graphes de Berge apprivoisés sont basiques ou admettent une décomposition telle qu’un côté de la décomposition soit toujours basique. Nous avons de plus un algorithme calculant cette décomposition. Nous utilisons ensuite notre théorème pour montrer que les graphes de Berge apprivoisés admettent la propriété du grand biparti, de la clique-stable séparation et qu’il existe un algorithme polynomial permettant de calculer le stable maximum. Abstract The goal of this thesis is to use graph’s decompositions to solve algorithmic problems on graphs. We will study the class of tamed Berge graphs. A Berge graph is a graph without cycle of odd length at least 4 nor complement of cycle of odd length at least 4. In the 60’s, Claude Berge conjectured that Berge graphs are perfect graphs. The size of the biggest clique is exactly the number of colors required to color the graph. In 2002, Chudnovsky, Robertson, Seymour et Thomas proved this conjecture using a theorem of decomposition: Berge graphs are either basic or have a decomposition. This is a useful result to do proof by induction. Unfortunately, one of the decomposition, the skewpartition, is really hard to use. We are focusing here on tamed Berge graphs, i.e Berge graph without balanced skew- partition. To be able to do induction, we must first adapt the Chudnovsky et al’s theorem of structure to our class. We prove a stronger result: tamed Berge graphs are basic or have a decomposition such that one side is always basic. We also have an algorithm to compute this decomposition. We then use our theorem to prove that tamed Berge graphs have the big-bipartite property, the clique-stable set separation property and there exists a polytime algorithm to compute the maximum stable set. iiRemerciements Je tiens tout d’abord à remercier mon directeur de thèse Nicolas Trotignon, pour sa disponibilité, l’aide qu’il m’a accordée pendant cette thèse et toutes les choses qu’il a pu m’apprendre tant au niveau de la recherche que de comment bien rédiger ou de choses plus anecdotiques comme la liste des monarques danois à partir de XVe siècle 1 . Je souhaite à tous les thésards de pouvoir bénéficier d’un encadrement comme le tien. Si je peux présenter cette thèse, c’est aussi grâce à mes relecteurs. Je remercie Celina de Figueiredo pour toutes ses remarques sur le manuscrit et aussi pour avoir accepté de faire le déplacement à Lyon pour faire partie de mon jury. Je remercie également Frédéric Maffray, pour sa relecture scrupuleuse qui m’a permis de rendre plus claires certaines preuves. Merci également à Annegret Wagler d’avoir bien voulu faire partie de mon jury. Stéphan, merci pour tous les problèmes souvent suivis de solutions très élégantes que tu as pu nous poser durant ces années à Lyon, merci aussi d’avoir accepté de participer à ce jury. Durant ce temps passé en thèse, mais aussi durant mon stage de master où j’ai pu commencer à travailler sur les problèmes présentés ici, j’ai eu la chance de rencontrer de nombreuses personnes. Je pense tout d’abord à mes cobureaux, par ordre d’apparition : Pierre, lorsque j’étais encore en stage de master au Liafa à Paris et qui nous a ensuite fait l’honneur de ses visites à Lyon. Bruno pour ton accueil au sein du LIP, tes explications sur le fonctionnement du DI et qui par ta maîtrise de Sage m’a donné goût à la science expérimentale. Sébastien tes discussions ont contribué à enrichir mes connaissances en physique, merci surtout pour ton enthousiasme à vouloir travailler sur n’importe quel problème, qu’il soit ou non lié à ton domaine de recherche. Aurélie sans qui les grapheux de MC2 n’auraient pas pu aller à toutes ces conférences, merci pour ton soutien. Emilie, je ne sais pas si nous avons officiellement été cobureaux mais merci pour toutes ces discussions (scientifiques ou pas) et bien sûr pour ces quiz musicaux. Jean-Florent, pendant ce semestre à Varsovie j’ai été très content d’avoir un cobureau lui aussi conditionné à manger à heures fixes, merci de m’avoir aidé à comprendre les wqo. Comme le temps passé au labo ne se limite pas à mon bureau merci à toute l’équipe MC2 : Nathalie, Pascal, Irena, Natacha, Michaël, Éric, Éric, Zhentao, Kévin, Maxime, Petru, Sebastián, Matthieu. Je souhaite à tout le monde de pouvoir travailler dans une telle équipe. La recherche ne se limite pas à Lyon. Merci à Maria et Kristina de m’avoir appris autant de choses sur les graphes parfaits lors de votre séjour à Paris au début de mon stage. Marcin dziękuję za zaproszenie do Warszawy. Merci aussi à Marko et Jarek avec qui j’ai eu l’occasion de travailler respectivement à Belgrade et à Varsovie. Merci enfin à ceux qui m’ont les premiers fait découvrir la théorie des graphes lors de mon stage de M1. Daniël pour avoir proposé un sujet de stage intéressant et accessible, Matthew et Viresh pour vos discussions, Pim pour tes parties de billard. La thèse c’est aussi l’enseignement, à ce titre merci à tous ceux avec qui j’ai eu l’occasion d’enseigner : Christophe, Xavier, Éric, Vincent et Arnaud. Merci aussi à tous mes élèves, particulièrement à ceux que j’ai eu l’occasion de coacher pour le SWERC. 1. C’est une alternance de Christian et de Frédéric iiiMême s’ils ne m’ont pas fait gagner de gourde j’ai été très content de les accompagner à Valence. Un immense merci à Marie et Chiraz pour les réponses aux innombrables questions que j’ai pu leur poser et pour l’organisation de mes missions. Chiraz encore merci pour t’être occupée de l’organisation de ma soutenance. Merci à Damien pour ton aide lors des procédures d’inscription, de réinscription et de soutenance de thèse. Merci aussi à Catherine, Évelyne, Laetitia, Sèverine et Sylvie d’avoir toutes, à un moment donné, su répondre à mes demandes. Comme une thèse ce n’est pas seulement ce qui se passe au labo, je voudrais remercier tous ceux qui m’ont accompagné durant ces trois ans. Au risque d’en oublier, merci à : Coco, Dédé, Pedro, Jo, So, Nico, Julie, Rom, Jess, Marion, Mika, Pauline, Pippo, Audrey, Camille... Merci aussi à toute ma famille, à mes parents qui ont pu être présents pour ma soutenance, à ma sœur qui est régulièrement passée à Lyon pendant ma thèse, mais surtout à Léopold sans qui l’organisation du pot m’aurait bien plus stressé. Enfin Marie, merci pour ton soutien pendant ces trois dernières années, mais merci surtout de m’avoir suivi à Lyon. Et toi lecteur, si tu n’as pas encore trouvé ton nom, je ne t’ai pas oublié. J’espère juste que /dev/random te permettra de le trouver parmi tous les autres dans la grille suivante. O K R A M S H T E R G E N N A Z O G U X U E L L I M A C H I R A Z J E S S I C A V E A H C A T A N E M A T T H E W Z V M S O P E E I L E R U A Y H T A C R W S A O A Q N H K T T H E N I R E H T A C U R L T M P I P D X N W P L E O P O L D E I E N S I U C O C X E M O S E V E R I N E N E F T K D O T R A R A L L P E O L D H N H E F E A E L S O V O R E Y G E E B E O Z I G T L S N A I L I L C N D W A A Y I A L E V N L A I S R A E F I E W H W E R I A R N U E A L L V H N R N N P C A I A R H A Y E S C J S U K C D I A C I L V M A T R M O I N N E I A R K Q I E M S L Z M A D O I S T I I M N P I R F X J O Y N H N T C H G Q S A V I A E S U D F R S C F R E D E R I C A M J X T F T R I A Y L A E T I T I A L J B O R A S T I T J O E I L I M E V E L Y N E R X M R V N E M M N A H T A N O J R M V S C E L I N A P ivTable des matières Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v 1 Introduction 1 2 Trigraphes de Berge apprivoisés 9 2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Trigraphes basiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Décompositions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Structure des trigraphes de Berge apprivoisés . . . . . . . . . . . . . 21 2.5 Blocs de décomposition . . . . . . . . . . . . . . . . . . . . . . . . . 28 3 Propriété du grand biparti 35 3.1 Grand biparti dans les trigraphes de Berge apprivoisés . . . . . . . 37 3.2 Clôture par k-joints généralisés . . . . . . . . . . . . . . . . . . . . 44 3.3 Grand biparti dans les classes closes par k-joints . . . . . . . . . . . 45 4 Clique-Stable séparateur 49 4.1 Clique-stable séparateur dans les trigraphes de Berge apprivoisés . . 51 4.2 Clique-stable séparateur dans les classes closes par k-joints . . . . . 55 5 Calcul du stable maximum 59 5.1 Le cas des trigraphes basiques . . . . . . . . . . . . . . . . . . . . . 60 5.2 Stocker α dans les blocs . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3 Calculer α . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6 Décompositions extrêmes 79 6.1 Décompositions extrêmes . . . . . . . . . . . . . . . . . . . . . . . . 79 6.2 Calculer une fin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7 Conclusion 95 Bibliographie 97 vTABLE DES MATIÈRES viChapitre 1 Introduction Les graphes permettent de modéliser de nombreux problèmes. Par exemple, affecter un nombre minimal de salles permettant de faire cours sans que deux cours n’aient lieu dans la même salle au même moment est un problème de coloration du graphe d’intervalles représentant les cours. Certains de ces problèmes sont “faciles”, c’est-à-dire qu’il existe un algorithme en temps d’exécution polynomial pour les résoudre, d’autres sont difficiles (NPcomplet) c’est-à-dire que si l’on trouve un algorithme efficace pour les résoudre, on résout par la même occasion tous les problèmes NP (ceux pour lesquels si l’on nous donne une solution il est facile de la vérifier, en particulier tous les problèmes de chiffrement). Cependant même si un problème est difficile sur les graphes généraux, il est possible que sur certaines classes de graphes il soit facile. Le problème du stable maximum est en général difficile, mais dans le cas des graphes bipartis (les graphes sans cycle de longueur impaire ou de manière équivalente, les graphes pouvant se partitionner en deux ensembles de sommets V1 et V2, tels que les seules arêtes soient entre V1 et V2, c’est-à-dire qu’il n’y ait aucune arête dans V1 ni dans V2) il devient facile. Notons bien que l’adjectif facile veut seulement dire ici qu’il existe un algorithme polynomial (donc dans un certain sens efficace) pour le résoudre et pas que cet algorithme est “facile” à trouver. Par exemple, pour résoudre le problème du stable maximum dans les graphes bipartis, il faut utiliser le théorème de Kőnig assurant l’égalité entre deux paramètres de graphe et un algorithme de couplage qui est maintenant classique. Il est donc intéressant d’étudier des classes de graphes. D’un point de vue théorique afin de comprendre ce qui fait la difficulté d’un problème, mais également d’un point de vue pratique. En effet en modélisant un problème il est tout à fait possible que le graphe obtenu ait des propriétés spécifiques et qu’il soit alors 1CHAPITRE 1. INTRODUCTION 1 1 1 1 2 2 2 3 3 3 Figure 1.1 – Exemple de coloration possible d’avoir des algorithmes efficaces. De nombreuses restrictions peuvent être obtenues, par exemple un graphe peut être obtenu à partir d’une carte routière et donc être représenté sans que ses arêtes ne se croisent (il est alors planaire). Il peut être obtenu à partir d’intersections d’intervalles de R (c’est alors un graphe d’intervalles) ou de contraintes entre deux types d’objets. Nous nous intéressons particulièrement aux classes de graphes définies par sous-graphes induits interdits, c’est-à-dire qu’en supprimant des sommets, on est assuré de ne pas pouvoir obtenir certains sous-graphes. De manière équivalente cela veut dire que quel que soit le sommet que l’on supprime, le graphe reste dans notre classe, ce qui permet par exemple de faire des inductions. Les graphes bipartis sont un exemple de classe de graphe définie par sous-graphes induits interdits (les cycles de longueur impaire). La question générale est celle de l’influence des propriétés locales (on interdit localement une configuration) sur les propriétés globales : comment peut-on trouver un ensemble de taille maximum de sommets tous deux à deux non-adjacents, comment peut-on colorier le graphe avec seulement k couleurs ? Le problème de coloration est le suivant : étant donné un graphe G, nous voulons donner à chacun de ses sommets une couleur (classiquement on identifie les couleurs à des entiers), telle que deux sommets adjacents n’aient pas la même couleur. Une solution triviale est de donner à chaque sommet une couleur diffé- rente, mais nous cherchons à minimiser le nombre de couleurs différentes utilisées. Pour un graphe G on appelle nombre chromatique que l’on note χ(G) le nombre minimum de couleurs nécessaire pour colorier G. Une question naturelle à propos du problème de coloration, et c’est celle qui 2va motiver l’introduction de notre classe de graphes, est la suivante : pourquoi un graphe G peut-il être colorié avec c couleurs mais pas avec c − 1 ? Il est facile de trouver des conditions nécessaires. Par exemple, si un graphe contient une arête, c’est-à-dire deux sommets adjacents, il ne peut pas être colorié avec moins de 2 couleurs. Plus généralement s’il contient une clique de taille k (un ensemble de sommets tous deux à deux adjacents) alors il ne pourra pas être colorié avec strictement moins de k couleurs. Pour un graphe G on note ω(G) la taille de sa plus grande clique. Ce que nous venons de voir peut se traduire avec nos notations : Pour tout graphe G, χ(G) ≥ ω(G). Cependant la présence de clique n’est pas la seule obstruction. Par exemple, il n’y a pas de clique de taille strictement supé- rieure à deux dans un cycle sans corde sur 5 sommets, pourtant il est impossible de le colorier avec strictement moins de 3 couleurs. Plus généralement, il existe de nombreuses constructions qui pour tout entier k fournissent un graphe Gk n’ayant pas de triangle (de clique de taille plus que 3), mais qui n’est pas coloriable avec moins de k couleurs. Dans ce contexte, il est intéressant de regarder comment sont construits les graphes pour lesquels avoir une clique de taille k est la seule raison de ne pas être k coloriable. Il y a une petite subtilité technique, avec seulement cette propriété n’importe quel graphe est, si on lui ajoute une clique suffisamment grande, dans la classe. Pour éviter ce problème et comprendre vraiment les structures de nos graphes, Claude Berge a proposé dans les années 1960 de demander que tous les sous-graphes induits soient également dans la classe. C’est ainsi que sont définis les graphes parfaits : un graphe G est parfait si et seulement si pour tout sous-graphe induit H de G, alors la taille de la plus grande clique de H est égale au nombre de couleurs minimum permettant de colorier le graphe H. Soit avec nos notations un graphe G est parfait si et seulement si pour tout sous-graphe induit H de G, χ(H) = ω(H). Une autre notion importante est celle du stable. Un stable dans un graphe est un ensemble de sommets sans aucune arête entre eux. Pour tout graphe G on note α(G) la taille d’un stable maximum de G. Une opération classique sur un graphe G est de prendre son complémentaire G définit comme suit : les sommets de G sont les même que ceux de G et deux sommets de G sont adjacents si et seulement s’ils ne sont pas adjacents dans G. On peut alors voir qu’un stable dans G devient une clique dans G et inversement. On a alors avec nos notations α(G) = ω(G). D’un point de vue algorithmique, il est intéressant de noter que trouver un algorithme de coloration dans les graphes parfaits se ramène à un algorithme de calcul de stable et de clique maximum pondérés (on met des poids sur les sommets et on cherche un stable ou une clique de poids maximum). C’est pourquoi cette 3CHAPITRE 1. INTRODUCTION thèse contient un chapitre sur le calcul du stable mais pas sur un algorithme de coloration. Ce résultat classique est difficile à extraire des travaux originaux de Gröstchel, Lovász, Schrijver mais est exposé plus clairement dans plusieurs travaux ultérieurs [33, 36]. Afin que le problème de coloration soit également traité dans cette thèse, le voici avec sa démonstration. Théorème 1.1 (Gröstchel, Lovász, Schrijver, 1988). Pour toute classe C autocomplémentaire de graphes parfaits, s’il existe un algorithme de complexité O(n k ) pour calculer un stable maximum pondéré d’un graphe de C, alors il existe un algorithme de complexité O(n k+2) pour colorier les graphes de C. Démonstration. Commençons par donner un algorithme qui étant donné un graphe G de C et une liste de cliques maximums de G K1, . . . , Kt avec t < |V (G)| calcule en temps O(n k ) un stable de G intersectant toutes ces cliques. Donnons à chaque sommets le poids yv = |{i; v ∈ Ki}|. Ce poids peut être nul. Calculons alors avec notre algorithme un stable pondéré maximum S. Nous alons montrer que S intersecte bien toutes les cliques Ki . Considérons alors le graphe G0 obtenu à partir de G en réplicant yv fois chaque sommet v. Observons que G0 peut ne pas être dans C mais est un graphe parfait. En réplicant yv fois chaque sommet v de S nous obtenons S 0 un stable maximum de G0 . Par construction, G0 peut être partitionné en t cliques de taille ω(G) qui forment un coloriage optimale de G0 car α(G0 ) = ω(G0 ) = ω(G). Puisque que le complémentaire d’un graphe parfait est parfait, G0 est parfait, et donc |S 0 | = t. Donc dans G, S intersecte toutes les cliques Ki . Nous allons maintenant montrer comment trouver un stable S intersectant toutes les cliques maximum de G. Ce stable formera une couleur et nous appliquerons ensuite cette méthode inductivement sur G \ S qui est bien χ(G) − 1 coloriable. Notons que la classe C n’a pas besoin d’être héréditaire, puisqu’on peut émuler G\S en donnant un poids nul aux sommets de S. Commençons avec t = 0. À chaque étape nous avons une liste de cliques maximums K1, . . . , Kt et nous calculons un stable S les intersectant toutes avec la méthode décrite précédament. Si ω(G \ S) < ω(G), alors notre stable intersecte toute les cliques maximums de G. Dans le cas contraire, calculons une clique maximum Kt+1 de G\S. Ce qui revient à calculer un stable maximum dans G \ S et qui est possible car notre classe est autocomplémentaire et en donnant un poids nul aux sommets de S. Pour prouver notre résultat nous n’avons plus qu’à montrer que t la taille de notre liste de clique maximum est bornée par |V (G)|. 41 1 2 2 3 1 1 1 2 2 2 3 1 1 2 2 3 3 4 Figure 1.2 – Trous et complémentaire de trous (C5 = C5, C7 et C7) Soit Mt la matrice d’incidence des cliques K1, . . . Kt . C’est-à-dire que les colonnes de Mt correspondent aux sommets de G et que chaque ligne est une clique. Montrons par induction que les lignes de Mt sont indépendantes. Le cas de base est trivial. Supposons que les lignes de Mt sont indépendantes et montrons que celles de Mt+1 le sont. Soit x le vecteur d’incidence x de S. On a Mtx = 1 mais pas de Mt+1x = 1. Supposons que les lignes de Mt+1 ne soient pas indépendantes. Nous avons, Kt+1 = λ1K1 + · · · + λtKt . En multipliant par x nous avons Kt+1x = λ1 + · · · + λt 6= 1. En multipliant par le vecteur colonne 1 nous avons alors ω(G) = Kt+11 = λ1ω(G) + · · · + λtω. Donc λ1 + · · · + λt = 1, une contradiction. Par conséquent, les matrices M1, M2, . . . ne peuvent avoir plus de |V (G)| lignes, et notre nombre d’itérations est bien borné par |V (G)|. Comme nous l’avons vu, contenir un cycle sans corde de longueur impaire nous assure de ne pas être parfait. Il est facile de voir que contenir le complémentaire d’un cycle sans corde de longueur impaire (tous les sommets non-adjacents deviennent adjacents et ceux adjacents deviennent non-adjacents, pour tout graphe G on note G son complémentaire) empêche également un graphe d’être parfait. On appelle trou un cycle sans corde, et on note Cn le trou de longueur n. On dit qu’un graphe sans trou, ni complémentaire de trou de longueur impaire supérieure à 4 est un graphe de Berge. La propriété d’être parfait pour un graphe est une propriété globale et elle implique la propriété locale d’être de Berge. Un exemple trivial d’influence de propriété locale ou d’interdiction de structures locales sur la coloration est celui d’interdire les arêtes. Dans ce cas il est immédiat que le graphe est coloriable avec une seule couleur. Voyons un exemple plus intéressant. On note P4 le chemin de 4 sommets, ce graphe a 3 arêtes. Un 5CHAPITRE 1. INTRODUCTION graphe G est sans P4 s’il ne contient pas P4 en tant que sous graphe induit. Théorème 1.2. Les graphes sans P4 sont coloriables optimalement avec l’algorithme suivant : Commençons par attribuer à chaque couleur un entier. Puis tant qu’il existe un sommet non colorié le colorier avec la plus petite couleur non utilisée par un de ses voisins. Démonstration. Notons k le nombre de couleurs utilisées par l’algorithme. Soit i le plus petit entier, tel qu’il existe une clique composée de k − i + 1 sommets coloriés de i à k. Si le graphe ne contient pas d’arête, il est clair que l’algorithme est valide, sinon cette clique contient au moins 2 sommets. Nous allons montrer que i = 1. Supposons que ce n’est pas le cas. Par définition de l’algorithme, tout sommet de la clique a un voisin colorié par i − 1, notons S cet ensemble de sommets. Par minimalité de i, S ne peut être réduit à un unique sommet. De plus, les sommets de S ayant la même couleur, ils forment donc un stable (ils sont tous deux à deux non-adjacents). Il existe deux sommets u et v de S, tels que u a un voisin x dans la clique qui n’est pas un voisin de v et v a un voisin dans la clique qui n’est pas un voisin de u. Les sommets u − x − y − v forment un P4, c’est une contradiction. Il existe donc une clique de taille k. Comme nous l’avons vu précédemment il est donc impossible de colorier le graphe avec strictement moins de k couleurs. Notre algorithme est donc optimal. Cette démonstration classique montre en fait que les graphes sans P4 sont des graphes parfaits. Dans les années 1960, Claude Berge a conjecturé qu’un graphe était parfait si et seulement si il était de Berge. Comme on vient de le voir, le passage du global (être coloriable avec exactement le même nombre de couleurs que la taille de la plus grande clique) au local (ne pas contenir de trou ni de complémentaire de trou de longueur impaire plus grande que 4) est clair. D’après les définitions : les graphes parfaits sont des graphes de Berge. C’est la réciproque, le passage du local au global qui est complexe. Cette conjecture a motivé de nombreuses recherches, utilisant des outils très différents (polyèdre, combinatoire). Finalement c’est grâce à un théorème de structure qu’en 2002 Chudnovsky, Robertson, Seymour et Thomas ont pu démontrer cette conjecture. Théorème 1.3 (Chudnovsky, Robertson, Seymour, Thomas (2002)). Les graphes de Berge sont parfaits. 6Un théorème de structure est un théorème disant que les graphes d’une classe sont : ou bien basiques ou bien admettent une décomposition. Par basique, on entend qu’ils sont dans une sous-classe de graphe suffisamment simple ou étudiée pour qu’il soit possible de résoudre notre problème sur cette sous-classe. Par décomposition, on entend que le graphe est obtenu en recollant de manière bien définie deux graphes plus petits de la classe. Le sommet d’articulation (un sommet dont la suppression déconnecte le graphe) est un exemple de décomposition. Si l’on a deux graphes G1 et G2 on peut en former un troisième G3 plus gros en identifiant un sommet de G1 avec un sommet de G2, ce sommet devient alors un sommet d’articulation de G3. Il existe également une version plus forte des théorèmes de structure : les théorèmes de structure extrême, qui énoncent qu’un graphe est ou bien basique, ou bien admet une décomposition telle qu’un côté de la décomposition est basique. Si l’on regarde l’arbre de décomposition d’un théorème de structure extrême, c’est un peigne (chaque nœud interne de l’arbre a comme fils une feuille et un nœud). Les théorèmes de structure sont généralement très utiles pour faire des démonstrations ou obtenir des algorithmes. Ils permettent de faire des inductions. Si une propriété est vraie pour les graphes basiques et qu’il est possible en utilisant la forme de la décomposition d’avoir cette propriété sur la composition de graphes, alors la propriété est vraie pour la classe de graphes. Certaines décompositions sont faciles à utiliser, par exemple le sommet d’articulation ou plus généralement la clique d’articulation (une clique dont la suppression déconnecte le graphe) qui peuvent, par exemple, être utilisées pour la coloration. D’autres sont très difficiles à utiliser, par exemple le star-cutset (un sommet dont la suppression et la suppression de certains de ses voisins déconnectent le graphe) et ses généralisations. En effet, il est possible que le star-cutset soit constitué de la majeure partie du graphe, dans ce cas toute tentative d’induction nécessitant de conserver le starcutset dans chaque partie de la décomposition (c’est ce qui est le cas classique) conduira nécessairement à un algorithme exponentiel. Dans cette thèse, nous allons utiliser le théorème de structure des graphes de Berge afin de démontrer un certain nombre de propriétés et d’algorithmes. Le théorème de Chudnovsky et al. et dont nous avons déjà parlé est le suivant. Théorème 1.4 (Chudnovsky, Robertson, Seymour, Thomas (2002)). Les graphes de Berge sont basiques ou décomposables par skew-partitions équilibrées, 2-joints ou complémentaire de 2-joints. Toutes les définitions seront données dans le chapitre 2. Nous ne savons pas 7CHAPITRE 1. INTRODUCTION utiliser les skew-partitions (une décomposition généralisant les star-cutset) dans les algorithmes, nous nous focalisons donc sur les graphes de Berge sans skewpartition. Vu que notre classe et que nos problèmes sont auto-complémentaires notre principale décomposition est donc le 2-joint. Nous essayerons tant que possible de généraliser nos résultats à d’autres classes décomposables par k-joints. Dans le chapitre 2, nous donnons toutes les définitions. Nous avons en fait besoin de généraliser la définition d’arête d’un graphe. Nous aurons alors des arêtes fortes, des non-arêtes fortes et un nouveau type d’adjacence : les arêtes optionnelles qui encodent une adjacence floue. Ces graphes généralisés sont appelés trigraphes et on été introduit par Chudnovsky et al. lors de la preuve du théorème fort des graphes parfaits. Nous avons donc besoin de redéfinir toutes les notions usuelles de graphe, ainsi que le théorème de structure des graphes de Berge. Dans le chapitre 3, nous nous intéressons aux classes pour lesquelles il existe pour tout graphe de la classe deux ensembles de sommets complets dans le graphe ou dans son complément de taille linéaire. Il y a des contre-exemples de classes de graphes de Berge sans ces ensembles, mais lorsqu’on exclut les skew-partition ces ensembles existent toujours. Il est possible de généraliser cette propriété aux classes construites par k-joints. Dans le chapitre 4, nous nous intéressons à la propriété de la clique-stable séparation, c’est-à-dire à l’existence d’un nombre polynomial de partitions du graphe en 2 ensembles tels que pour toute clique et tout stable sans intersection, il existe une partition contenant la clique d’un côté et le stable de l’autre. Ce problème est ouvert en général sur les graphes de Berge, mais nous pouvons le démontrer dans le cas où on exclut les skew-partition. Ici encore cette propriété peut-être étendue aux classes construites par k-joints. Dans le chapitre 5, nous nous intéressons au calcul en temps polynomial du stable maximum. Notre algorithme est constructif et donne directement les sommets du stable. Dans le cas général des classes héréditaires on peut reconstruire avec un surcoût linéaire un stable maximum en sachant calculer sa valeur, cependant notre classe n’est pas héréditaire. Cet algorithme ne se généralise pas aux classes construites par k-joints, il existe de telles classes où le calcul du stable maximum est NP-complet. À partir de l’algorithme de calcul du stable on peut déduire un algorithme qui calcule une coloration optimale avec un surcoût de O(n 2 ). Dans le chapitre 6, nous montrons qu’en étendant notre ensemble de décompositions nous pouvons obtenir une version extrême du théorème de structure. Nous donnons également des algorithmes permettant de calculer une telle décomposition. 8Chapitre 2 Trigraphes de Berge apprivoisés Les résultats de ce chapitre ont été obtenus avec Maria Chudnovsky, Nicolas Trotignon et Kristina Vušković, ils font l’objet d’un article [15] soumis à Journal of Combinatorial Theory, Series B. Nous introduisons dans ce chapitre une généralisation des graphes, les trigraphes. Il semble que cette notion de trigraphe, inventée par Chudnovsky, soit en train de devenir un outil très utile en théorie structurelle des graphes. Les trigraphes ont entre autre été utilisés pour éliminer la paire homogène (deux ensembles A et B de sommets se comportant comme deux sommets vis à vis du reste du graphe i.e tels que le reste du graphe se décompose en quatre ensembles : les sommets complétement adjacents aux sommets de A et de B, ceux complétement adjacents aux sommets de A et complétement non-adjacents aux sommets de B, ceux complétement non-adjacents aux sommets de A et complétement adjacents aux sommets de B et ceux complétement non-adjacents aux sommets de A et de B) de la liste des décompositions utilisées pour décomposer les graphes de Berge [9]. Ils apparaissent également dans l’étude des graphes sans griffe [14] ou dans celle des graphes sans taureau [11, 10]. La notion de trigraphe apparait également lors de l’étude d’homomorphismes [18, 19]. Cependant il faut bien noter que dans ce dernier cas, même si le nom et les idées générales sont identiques, les définitions diffèrent légèrement. Avant de tout définir, essayons d’expliquer informellement l’intérêt des trigraphes. Le premier exemple de leurs utilisation est dans la démonstration de l’amélioration du théorème de décomposition des graphes de Berge. En effet, lors 9CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS A B Figure 2.1 – Paire Homogène (Une double arête entre deux ensembles indique qu’ils sont complet, une arête simple indique qu’on ne sait rien sur leur adjacence, l’absence d’arête indique qu’il n’y a aucune arête entre les deux ensembles) de la preuve du théorème des graphes parfaits Chudnovsky, Robertson, Seymour et Thomas [13] parviennent à décomposer les graphes de Berge en utilisant trois types de décompositions. Chudnovsky [9] montre alors qu’une de ces décompositions, la paire homogène est en fait inutile. Voyons l’intérêt des trigraphes dans la démonstration de ce résultat. L’idée de sa preuve est de prendre le plus petit graphe G dont la seule décomposition possible est une paire homogène et de chercher une contradiction. L’idée naturelle est alors de contracter cette paire homogène afin d’obtenir un graphe plus petit G0 , qui par hypothèse de minimalité, admet alors une décomposition autre que la paire homogène. On peut alors déduire de cette décomposition une décomposition dans G. Ce qui est contradictoire puisque par hypothèse, G n’est décomposable que par paire homogène. Cette idée est en fait une méthode classique de démonstration en théorie structurelle de graphes. Le principal problème (et c’est pour répondre à ce problème que les trigraphes ont été introduit) est de savoir comment contracter la paire homogène. Une paire homogène étant deux ensembles A et B de sommets se comportant comme deux sommets vis à vis du reste du graphe, on peut vouloir les réduire à deux sommets a et b tout en préservant leurs adjacences par rapport au reste du graphe. La question est de savoir s’il faut ou non mettre une arête entre ces deux sommets contractés. Sans donner les définitions précises, si on décide de ne pas mettre d’arête entre a et b, dans un certain sens, a va pouvoir être séparé de b, alors que dans le graphe de départ, séparer A de B n’a pas de sens. Nous avons le même problème dans le complémentaire du graphe si l’on décide de mettre une arête entre a et b. En 10fait aucun de ces choix n’est le bon, en effet a priori chacun de ces choix pourrait créer une décomposition. Ce n’est finalement pas le cas puisque le résultat est vrai mais toute démonstration se heurte à ce problème. L’idée est alors de mettre une arête optionnelle. Les trigraphes sont alors définis comme des graphes mais avec trois types d’adjacence, les arêtes, les arêtes optionnelles et les non-arêtes. Une réalisation d’un trigraphe est alors une affectation des arêtes optionnelles en arêtes et non-arêtes. Tout le vocabulaire et les propriétés sur les graphes se traduisent alors sur les trigraphes de la manière suivante : Une propriété P est vraie sur le trigraphe T si et seulement si elle est vraie sur toutes les réalisations G de T. On ne crée alors plus de décomposition car on peut alors montrer que si toutes les réalisations contiennent cette décomposition, alors cette décomposition était présente à l’origine, ce qui mène à une contradiction. Bien entendu pour pouvoir faire l’induction tous les résultats doivent être vrais sur les trigraphes. Comme c’est souvent le cas lors des preuves par induction afin d’obtenir le résultat voulu nous devons en montrer un plus fort. Les trigraphes permettent donc de travailler naturellement sur des hypothèses d’induction plus fortes ; pour toute réalisation la propriété doit être vraie ; ce qui nous permet alors de contracter des ensembles de sommets tout en préservant l’information d’adjacence entre ces sommets. Certains étaient adjacents, d’autre non, et suivant la réalisation choisie on a ou pas cet état. Ceci nous permet, si une décomposition existe (dans toutes les réalisations), de la trouver dans le graphe de départ. Ceci n’étant que de brèves explications, voyons maintenant les définitions pré- cises. Dans ce chapitre nous allons commencer par formaliser le vocabulaire usuel des graphes sur les trigraphes. Nous définissons ensuite plusieurs classes de trigraphes basiques (il s’agit des classes de base du thérorème fort des graphes parfaits, à savoir les trigraphes bipartis, les line trigraphes et les trigraphes doublés) et les décompositions que nous allons utiliser, là encore il s’agit des décompositions utilisées pour la démonstration du théorème fort des graphes parfaits à savoir les 2-joints et les skew-partitions équilibrées. Comme mentionné précédemment les paires homogènes ne sont pas utiles et nous les définirons plus tard lorsque nous voudrons une version “extrême” du théorème de structure, c’est à dire un théorème de structure dans lequel à chaque étape de décomposition, un côté au moins de la décomposition est un trigraphe basique. Nous définissons ensuite la classe des trigraphes que nous allons étudier, les trigraphes de Berge bigames, il s’agit d’une généralisation des trigraphes monogames utilisés dans [8]. Dans les trigraphes monogames les arêtes optionnelles forment un couplage alors que dans 11CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS les trigraphes bigames on autorise sous certaines conditions des composantes de deux arêtes optionnelles. Nous devons alors étendre le théorème de décomposition des trigraphes de Berge monogames aux trigraphes de Berge bigames. Enfin, nous pourrons définir la sous-classe qui nous intéresse, à savoir les trigraphes de Berge apprivoisés et montrer qu’ils se comportent bien vis à vis des décompositions du théorème. En effet il est possible de les décomposer tout en gardant l’information utile de l’autre partie de la décomposition et en restant dans la sous-classe. 2.1 Définitions Pour tout ensemble X, on note  X 2  l’ensemble de tous les sous-ensembles de X de taille 2. Pour alléger les notations, un élément {u, v} de  X 2  sera également noté uv ou vu. Un trigraphe T est composé d’un ensemble fini V (T), appelé l’ensemble de sommet de T et d’une application θ :  V (T) 2  −→ {−1, 0, 1}, appelée fonction d’adjacence. Deux sommets distincts de T sont dit fortement adjacents si θ(uv) = 1, fortement antiadjacents si θ(uv) = −1 et semiadjacents si θ(uv) = 0. On dit que u et v sont adjacents s’ils sont fortement adjacents ou semiadjacents ; et qu’ils sont antiadjacents, s’ils sont fortement antiadjacents ou semiadjacents. Une arête (antiarête) est une paire de sommets adjacents (antiadjacents). Si u et v sont adjacents (antiadjacents), on dit également que u est adjacent (antiadjacent) à v, ou que u est un voisin (antivoisin) de v. De la même manière, si u et v sont fortement adjacents (fortement antiadjacents), alors u est un voisin fort (antivoisin fort) de v. On note E(T), l’ensemble de toutes les paires fortement adjacentes de T, E(T) l’ensemble de toutes les paires fortement antiadjacentes de T et E ∗ (T) l’ensemble de toutes les paires semiadjacentes de T. Un trigraphe T peut être considèré comme un graphe si et seulement si E ∗ (T) est vide. Une paire {u, v} ⊆ V (T) de sommets distincts est une arête optionnelle si θ(uv) = 0, une arête forte si θ(uv) = 1 et une antiarête forte si θ(uv) = −1. Une arête uv (antiarête, arête forte, antiarête forte, arête optionnelle) est entre deux ensembles A ⊆ V (T) et B ⊆ V (T) si u ∈ A et v ∈ B ou si u ∈ B et v ∈ A. Soit T un trigraphe. Le complément de T est le trigraphe T avec le même ensemble de sommet V (T) que T, et avec la fonction d’adjacence θ = −θ. Pour v ∈ V (T), on note N(v) l’ensemble de tous les sommets de V (T) \ {v} qui sont adjacents à v. Soit A ⊂ V (T) et b ∈ V (T) \ A. On dit que b est fortement complet à A si b est fortement adjacent à tous les sommets de A ; b est fortement 122.1. DÉFINITIONS anticomplet à A si b est fortement antiadjacent à tous les sommets de A ; b est complet à A si b est adjacent à tous les sommets de A ; et b est anticomplet à A si b est anticomplet à tous les sommets de A. Pour deux ensembles disjoints A, B de V (T), B est fortement complet (fortement anticomplet, complet, anticomplet) à A si tous les sommets de B sont fortement complets (fortement anticomplets, complets, anticomplets) à A. Un ensemble de sommets X ⊆ V (T) domine (domine fortement) T, si pour tout sommet v ∈ V (T) \ X il existe u ∈ X, tel que v est adjacent (fortement adjacent) à u. Une clique de T est un ensemble de sommets deux à deux adjacents. Une clique forte est un ensemble de sommets deux à deux fortement adjacents. Un stable est un ensemble de sommets deux à deux antiadjacents. Un stable fort est un ensemble de sommets deux à deux fortement antiadjacents. Remarquons qu’avec ces définitions une clique et un stable peuvent s’intersecter sur plusieurs sommets, dans ce cas l’intersection est composée uniquement d’arêtes optionnelles. Pour X ⊆ V (T), le trigraphe induit par T sur X (noté T|X) a X comme ensemble de sommets et θ restreinte sur  X 2  comme fonction d’adjacence. L’isomorphisme entre deux trigraphes est défini de manière naturelle et pour deux trigraphes T et H, on dit que H est un trigraphe induit de T ou que T contient H en tant que sous-trigraphe induit, s’il existe X ⊆ V (T), tel que H est isomorphe à T|X. Comme la relation de sous-graphe induit est la principale relation étudiée dans cette thèse, on dit également que T contient H si T contient H comme sous-trigraphe induit. On note T \ X le trigraphe T|(V (T) \ X). Soit T un trigraphe. Un chemin P de T est une suite de sommets distincts p1, . . . , pk telle que ou bien k = 1, ou bien pour i, j ∈ {1, . . . , k}, pi est adjacent à pj , si |i − j| = 1 et pi est antiadjacent à pj si |i − j| > 1. Dans ce cas, V (P) = {p1, . . . , pk} et on dit que P est un chemin de p1 à pk, son intérieur est l’ensemble P ∗ = V (P) \ {p1, pk}, et la taille de P est k − 1. Parfois on note P par p1- · · · -pk. Notons que puisqu’un graphe est également un trigraphe, un chemin dans un graphe avec notre définition est plus généralement appelé dans la littérature un chemin sans corde. Un trou dans un trigraphe T est un sous-trigraphe induit H de T sur un ensemble de sommets h1, . . . , hk avec k ≥ 4, et pour i, j ∈ {1, . . . , k}, hi est adjacent à hj si |i − j| = 1 ou si |i − j| = k − 1 ; et hi est antiadjacent à hj si 1 < |i − j| < k − 1. La taille d’un trou est égale au nombre de sommets qu’il contient. Parfois on note H par h1- · · · -hk-h1. Un antichemin (resp. antitrou) dans T est un sous-trigraphe induit de T dont le complément est un chemin (resp. trou) dans T. 13CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS Une semiréalisation d’un trigraphe T est n’importe quel trigraphe T 0 sur l’ensemble de sommet V (T) qui vérifie les propriétés suivantes : pour tout uv ∈  V (T) 2  , si uv ∈ E(T) alors uv ∈ E(T 0 ), et si uv ∈ E(T) alors uv ∈ E(T 0 ). On peut voir une semiréalisation de T comme une affectation des arêtes optionnelles de T avec trois valeurs possibles : “arête forte”, “antiarête forte” ou “arête optionnelle”. Une réalisation de T est n’importe quel graphe qui est une semiréalisation de T (c’est à dire que toutes les arêtes optionnelles sont assignées aux valeurs “arête forte” ou “antiarête forte”). Pour S ⊆ E ∗ (T), on note par GT S la réalisation de T avec E(T)∪S comme ensemble d’arêtes, c’est à dire que dans GT S les arêtes optionnelles de S sont assignées à la valeur “arête” et que celles de E ∗ (T) \ S sont assignées à la valeur “antiarête”. La réalisation GT E ∗(T) est appelée réalisation complète de T. Soit T un trigraphe. Pour X ⊆ V (T), on dit que X et T|X sont connexes (resp. anticonnexes) si le graphe G T|X E ∗(T|X) (G T|X ∅ ) est connexe, c’est à dire qu’en remplaçant toute les arêtes optionnelles par des arêtes fortes (resp. antiarêtes fortes) le graphe obtenu est connexe (resp. le complémentaire du graphe obtenu est connexe). Une composante connexe (ou simplement une composante) de X est un sous-ensemble connexe maximal de X, et une anticomposante connexe (ou simplement une anticomposante) de X est un ensemble maximal anticonnexe de X. L’idée des ces définitions est la suivante : — une propriété est vraie sur un trigraphe T s’il existe un graphe G réalisation de T sur laquelle elle est vraie. — une propriété forte est vraie sur un trigraphe T si pour tout graphe G réalisation de T elle est vraie. — une antipropriété est vraie sur un trigraphe T si elle est vraie sur le complémentaire de T (les arêtes fortes deviennent des antiarêtes fortes et inversement). Attention dans les sections suivantes, les trigraphes basiques et les décompositions sont implicitement fortes. En effet si on a besoin de pouvoir parler de trigraphe connexe (au sens faible), nous n’aurons jamais besoin de parler de trigraphe faiblement de Berge ou admettant un 2-joint faible. En effet comme mentionné dans lors des motivations des trigraphes, nous voulons qu’un trigraphe soit basique ou admette une décomposition si et seulement si c’est le cas pour toutes ses réalisations. De cette manière nous pourront transformer une obstruction dans le trigraphe contracté en une obstruction dans le trigraphe de départ. 142.2. TRIGRAPHES BASIQUES 2.2 Trigraphes basiques Un trigraphe T est de Berge, s’il ne contient pas de trou impair ni d’antitrou impair. Par conséquent, un trigraphe est de Berge si et seulement si son complé- ment l’est. Notons également que T est de Berge si et seulement si, toutes ses semiréalisations (réalisations) sont de Berge. Remarquons qu’un trigraphe sans arêtes optionnelles et en particulier toutes réalisations d’un trigraphe peuvent être vues comme un graphe, il est alors important de voir qu’être un trigraphe de Berge pour un trigraphe sans arêtes optionnelles est exactement être un graphe de Berge. Notre définition dans les trigraphes est bien une généralisation aux trigraphes de la définition usuelle dans les graphes. Un trigraphe T est biparti si on peut partitionner son ensemble de sommets en deux stables forts. Toute réalisation d’un trigraphe biparti est un graphe biparti, et donc tout trigraphe biparti est de Berge. De la même manière, les compléments de trigraphes bipartis sont également de Berge. De même cette définition est bien une généralisation de la définition de biparti dans les graphes. Un trigraphe T est un line trigraphe, si la réalisation complète de T est le line graphe d’un graphe biparti et que toute clique de taille au moins 3 dans T est une clique forte. L’énoncé suivant est un résultat simple sur les lines trigraphes. Ici encore un line trigraphe sans arêtes optionnelles est un line graphe de graphe biparti. Lemme 2.1. Si T est un line trigraphe, alors toute réalisation de T est le line graphe d’un graphe biparti. Et plus, toute semiréalisation de T est un line trigraphe. Démonstration. Par définition, la réalisation complète G de T est le line graphe d’un graphe biparti R. Soit S ⊆ E ∗ (T). Définissons RS comme suit. Pour tout xy ∈ E ∗ (T) \ S, soit vxy l’extrémité commune de x et y dans R. Alors vxy est de degré 2 dans R car toute clique de taille au moins 3 dans T est une clique forte. Soit axy et bxy ses voisins. Supprimons vxy de R et remplaçons le par deux nouveaux sommets, uxy, wxy tels que uxy est seulement adjacent à axy, et wxy est seulement adjacent à bxy. Maintenant RS est biparti et GT S est le line graphe de RS. On a alors la première partie du résultat, la seconde suit car la réalisation complète d’une semiréalisation est une réalisation. Remarquons que cela implique que les line trigraphes ainsi que leurs complé- ments sont de Berge. Définissons maintenant les trigraphes semblables aux double 15CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS split graphes (défini pour la première fois dans [13]), c’est à dire les trigraphes doublés. Une bonne partition d’un trigraphe T est une partition (X, Y ) de V (T) (les cas X = ∅ ou Y = ∅ ne sont pas exclus) telle que : — Chaque composante de T|X a au plus deux sommets, et chaque anticomposante de T|Y a au plus deux sommets. — Il n’y a pas d’arête optionnelle de T qui intersecte à la fois X et Y — Pour toute composante Cx de T|X, toute anticomposante CY de T|Y et tout sommet v dans CX ∪ CY , il existe au plus une arête forte et une antiarête forte entre CX et CY qui est incidente à v. Un trigraphe est doublé si et seulement s’il a une bonne partition. Les trigraphes doublés peuvent aussi être définis comme les sous-trigraphes induits des double split trigraphes (voir [9] pour une définition des double split trigraphes que nous n’utiliserons pas ici). Remarquons que les trigraphes doublés sont clos par sous-trigraphes induit et par complémentation (en effet (X, Y ) est une bonne partition d’un trigraphe T si et seulement si (Y, X) est une bonne partition de T). Un graphe doublé est n’importe quelle réalisation d’un trigraphe doublé. Nous montrons maintenant le résultat suivant : Lemme 2.2. Si T est un trigraphe doublé, alors toute réalisation de T est un graphe doublé. De plus, toute semiréalisation de T est aussi un graphe doublé. Démonstration. L’énoncé sur les réalisations est clair par définition. Soit T un trigraphe doublé, et (X, Y ) une bonne partition de T. Soit T 0 une semiréalisation de T. Il est facile de voir que (X, Y ) est aussi une bonne partition de T 0 (par exemple, si une arête optionnelle ab de T|X est assignée à la valeur “antiarête”, alors {a} et {b} deviennent des composantes de T 0 |X, mais ils vérifient toujours la définition d’une bonne partition). Ceci prouve le résultat sur les semiréalisations. Remarquons que ceci implique que tout trigraphe doublé est de Berge, car tout graphe doublé est de Berge. Un trigraphe est basique si c’est, ou bien un trigraphe biparti, ou bien le complément d’un trigraphe biparti, ou bien un line trigraphe, ou bien le complément d’un line trigraphe ou bien un trigraphe doublé. Le résultat suivant résume les ré- sultats de cette section et montre bien que nos classes basiques sont implicitement fortement basiques. Lemme 2.3. Les trigraphes basiques sont de Berge et sont clos par soustrigraphe induit, semiréalisation, réalisation et complémentation. 162.3. DÉCOMPOSITIONS A1 C1 B1 A2 C2 B2 X1 X2 Figure 2.2 – 2-joint (Une double arête entre deux ensembles indique qu’ils sont complet, une arête simple indique qu’on ne sait rien sur leur adjacence, l’absence d’arête indique qu’il n’y a aucune arête entre les deux ensembles) 2.3 Décompositions Nous pouvons maintenant décrire les décompositions dont nous aurons besoin afin d’énoncer notre théorème de décomposition. Pour commencer, un 2-joint dans un trigraphe T est une partition (X1, X2) de V (T) telle qu’il existe des ensembles disjoints A1, B1, C1, A2, B2, C2 ⊆ V (T) vérifiant : — X1 = A1 ∪ B1 ∪ C1 et X2 = A2 ∪ B2 ∪ C2 ; — A1, A2, B1 et B2 sont non-vides ; — il n’y a pas d’arête optionnelle qui intersecte à la fois X1 et X2 ; — tout sommet de A1 est fortement adjacent à tous les sommets de A2, et tout sommet de B1 est fortement adjacent à tous les sommets de B2 ; — il n’y a pas d’autre arête forte entre X1 et X2 ; — pour i = 1, 2 |Xi | ≥ 3 ; et — pour i = 1, 2, si |Ai | = |Bi | = 1, alors la réalisation complète de T|Xi n’est pas un chemin de taille deux reliant les membres de Ai et ceux de Bi . 17CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS Remarquons bien qu’aucune arête importante (celles entre X1 et X2) pour la définition du 2-joint ne peut être une arête optionnelle. Ici aussi et sauf cas pathologique (Xi est un triangle d’arêtes optionelles ayant un sommet dans chaque ensemble Ai , Bi et Ci), le 2-joint est implicitement fort, dans tout graphe G réalisation de T, (X1, X2) est un 2-joint. Notons bien que dans les trigraphes de Berge ce cas pathologique ne peut pas apparaitre car il contredit le lemme 2.4 énoncé juste après. Nous aurions pu éviter ce problème en choisissant une définition plus forte du 2-joint, par exemple un 2-joint vérifiant par définition tous les points du théorème 2.9. Ce théorème prouve que dans le cas des trigraphes de Berge apprivoisés les 2-joints possèdent certaines conditions techniques supplémentaires que n’a pas ce cas pathologique. Cependant l’utilisation du théorème 2.5 qui est exactement le théorème 3.1 de [9] ne nous autorise pas à utiliser une définition adaptée aux trigraphes de Berge apprivoisés. Dans ces conditions, on dit que (A1, B1, C1, A2, B2, C2) est une affectation de (X1, X2). Le 2-joint est propre si pour i = 1, 2, toute composante de T|Xi intersecte à la fois Ai et Bi . Remarquons que le fait que le 2-joint soit propre ne dépend pas du choix de l’affectation. Un complément de 2-joint d’un trigraphe T est un 2-joint de T. Plus précisé- ment, un complément de 2-joint d’un trigraphe T est une partition (X1, X2) de V (T) telle que (X1, X2) est un 2-joint de T ; et (A1, B1, C1, A2, B2, C2) est une affectation de ce complément de 2-joint, si c’est une affectation du 2-joint correspondant dans le complément, i.e. A1 est fortement complet à B2 ∪ C2 et fortement anticomplet à A2, C1 est fortement complet à X2, et B1 est fortement complet à A2 ∪ C2 et fortement anticomplet à B2. Lemme 2.4. Soit T un trigraphe de Berge et (A1, B1, C1, A2, B2, C2) une affectation d’un 2-joint propre de T. Alors tous les chemins dont une extrémité est dans Ai, l’autre étant dans Bi et dont l’intérieur est dans Ci, pour i = 1, 2 ont des longueurs de même parité. Démonstration. Dans le cas contraire, pour i = 1, 2, soit Pi des chemins dont une extrémité est dans Ai , l’autre extrémité étant dans Bi et dont l’intérieur est dans Ci , tels que P1 et P2 ont des parités différentes. Ils forment un trou impair, c’est une contradiction. Notre deuxième décomposition est la skew-partition équilibrée. Soit A, B deux ensembles disjoints de V (T). On dit que la paire (A, B) est équilibrée s’il n’y a pas de chemin impair de longueur strictement supérieure à 1 dont les extrémités 182.3. DÉCOMPOSITIONS A1 C1 B1 A2 C2 B2 X1 X2 Figure 2.3 – Complèment de 2-joint (Une double arête entre deux ensembles indique qu’ils sont complet, une arête simple indique qu’on ne sait rien sur leur adjacence, l’absence d’arête indique qu’il n’y a aucune arête entre les deux ensembles) A B C D Figure 2.4 – Skew-partition (Une double arête entre deux ensembles indique qu’ils sont complet, l’absence d’arête indique qu’il n’y a aucune arête entre les deux ensembles) 19CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS sont dans B et dont l’intérieur est dans A et qu’il n’y a pas non plus d’antichemin de longueur strictement supérieure à 1 dont les extrémités sont dans A et dont l’intérieur est dans B. Une skew-partition est une partition (A, B) de V (T) telle que A n’est pas connexe et B n’est pas anticonnexe. Une skew-partition (A, B) est équilibrée si la paire (A, B) l’est. Étant donné une skew-partition équilibrée (A, B), (A1, A2, B1, B2) est une affectation de (A, B) si A1, A2, B1 et B2 sont des ensembles disjoints et non-vide, A1 ∪ A2 = A, B1 ∪ B2 = B, A1 est fortement anticomplet à A2, et B1 est fortement complet à B2. Remarquons que pour toute skew-partition équilibrée, il existe au moins une affectation. Attention, l’adjectif “équilibrée” pourrait laisser penser que les tailles des deux parties sont comparables, ce n’est absolument pas le cas. Il est tout à fait possible qu’un des ensembles de l’affectation concentre presque tout le trigraphe, le reste ne comportant qu’un nombre fixe négligeable de sommets. C’est le problème majeur à l’élaboration d’algorithmes utilisant les skew-partitions équilibrées. Si nous étions assurés que chaque ensemble de l’affectation fût composé d’au moins une fraction du trigraphe, nos algorithmes pourraient alors s’étendre sur tous les graphes parfaits. Ces deux décompositions généralisent les décompositions utilisées dans [13]. De plus toutes les arêtes et non-arêtes “importantes” dans ces décompositions doivent respectivement être des arêtes fortes et des antiarêtes fortes du trigraphe. Nos décompositions sont donc bien implicitement fortes. Nous pouvons maintenant énoncer plusieurs lemmes techniques. Un trigraphe est dit monogame si tous ses sommets appartiennent à au plus une arête optionnelle. Nous pouvons maintenant énoncer le théorème de décomposition pour les trigraphes monogames de Berge. C’est le théorème 3.1 de [9]. Théorème 2.5. Soit T un trigraphe monogame de Berge. Alors un des points suivants est vrai : — T est basique ; — T ou T admet un 2-joint propre ; ou — T admet une skew-partition équilibrée. Si (A, B) est une skew-partition d’un trigraphe T, on dit que B est un star cutset de T si au moins une anticomposante de B a taille 1. L’énoncé suivant est le Théorème 5.9 de [8]. 202.4. STRUCTURE DES TRIGRAPHES DE BERGE APPRIVOISÉS Lemme 2.6. Si un trigraphe de Berge admet un star cutset, alors il admet une skew-partition équilibrée. On dit que X est un ensemble homogène d’un trigraphe T si 1 < |X| < |V (T)|, et que tout sommet de V (T) \ X est ou bien fortement complet ou bien fortement anticomplet à X. Lemme 2.7. Soit T un trigraphe et X un ensemble homogène de T, tel qu’il existe un sommet de V (T)\X fortement complet à X, et un sommet de V (T)\ X fortement anticomplet à X. Alors T admet une skew-partition équilibrée. Démonstration. Soit A l’ensemble des sommets de V (T) \ X qui sont fortement anticomplets à X, et C l’ensemble des sommets de V (T) \ X qui sont fortement complets à X. Soit x ∈ X. Alors C ∪ {x} est un star cutset de T (puisque A est X \ {x} sont non-vides et fortement anticomplets entre eux), et donc T admet une skew-partition équilibrée d’après le lemme 2.6. Nous aurons également besoin du résultat suivant (qui est un corollaire immé- diat du théorème 5.13 de [8]) : Lemme 2.8. Soit T un trigraphe de Berge. Supposons qu’il y ait une partition de V (T) en quatre ensembles non-vides X, Y, L, R, tels que L est fortement anticomplet à R, et X est fortement complet à Y . Si (L, Y ) est équilibrée alors T admet une skew-partition équilibrée. 2.4 Structure des trigraphes de Berge apprivoisés Pour les besoins de nos inductions nous aurons besoin d’utiliser des trigraphes plus généraux que les trigraphes monogame. Nous allons donc définir les trigraphes bigame et montrer que le théorème de décomposition des trigraphes monogames de Berge s’étend sur les trigraphes bigames de Berge. Pour se familiariser avec notre objet d’étude principal, les trigraphes de Berge apprivoisés (définis dans la suite de ce paragraphe), nous allons commencer par montrer que dans ces trigraphes les 2-joints vérifient plusieurs conditions techniques supplémentaires. Soit T un trigraphe, notons par Σ(T) le graphe ayant V (T) comme ensemble de sommets et E ∗ (T) (les arêtes optionnelles de T) comme ensemble d’arêtes. Les 21CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS Figure 2.5 – Configuration possible des arêtes optionnelles dans les trigraphes bigame (les arêtes sont représentées par des traits pleins et les arêtes optionnelles par des pointillés) composantes connexes de Σ(T) sont appelées les composantes optionnelles de T. On dit qu’un trigraphe de Berge est bigame si les propriétés suivantes sont vérifiées : — Chaque composante optionnelle de T a au plus deux arêtes (et donc aucun sommet n’a plus de deux voisins dans Σ(T)). — Soit v ∈ V (T) de degré deux dans Σ(T), notons x et y ses voisins. Alors, ou bien v est fortement complet à V (T) \ {v, x, y} dans T, et x est fortement adjacent à y dans T (dans ce cas on dit que v et la composante optionnelle qui contient v sont lourds) ou bien v est fortement anticomplet à V (T) \ {v, x, y} dans T, et x est fortement antiadjacent à y dans T (dans ce cas on dit que v et la composante optionnelle qui contient v sont légers). Remarquons qu’un trigraphe T est bigame si et seulement si T l’est aussi ; de plus v est léger dans T si et seulement si v est lourd dans T. On dit qu’un trigraphe de Berge est apprivoisé s’il est bigame et qu’il ne contient pas de skew-partition équilibrée. On dit qu’un graphe de Berge est apprivoisé s’il ne contient pas de skewpartition équilibrée. Théorème 2.9. Soit T un trigraphe de Berge apprivoisé et soit (A1, B1, C1, A2, B2, C2) une affectation d’un 2-joint (X1, X2) dans T. Alors les propriétés suivantes sont vérifiées : (i) (X1, X2) est un 2-joint propre ; (ii) chaque sommet de Xi a un voisin dans Xi, i = 1, 2 ; (iii) chaque sommet de Ai a un antivoisin dans Bi , i = 1, 2 ; (iv) chaque sommet de Bi a un antivoisin dans Ai, i = 1, 2 ; 222.4. STRUCTURE DES TRIGRAPHES DE BERGE APPRIVOISÉS (v) chaque sommet de Ai a un voisin dans Ci ∪ Bi, i = 1, 2 ; (vi) chaque sommet de Bi a un voisin dans Ci ∪ Ai, i = 1, 2 ; (vii) si Ci = ∅, alors |Ai | ≥ 2 et |Bi | ≥ 2, i = 1, 2 ; (viii) |Xi | ≥ 4, i = 1, 2. Démonstration. Remarquons que d’après le lemme 2.6, ni T ni T ne peuvent contenir de star cutset. Pour démontrer (i), nous devons simplement démontrer que toute composante de T|Xi intersecte à la fois Ai et Bi , i = 1, 2. Supposons par contradiction qu’il y ait une composante connexe C de T|X1 qui n’intersecte pas B1 (les autres cas sont symétriques). S’il y a un sommet c ∈ C \ A1 alors pour tout sommet u ∈ A2, {u} ∪ A1 est un star cutset qui sépare c de B1, c’est une contradiction. Donc C ⊆ A1. Si |A1| ≥ 2 alors nous pouvons choisir deux sommets c ∈ C et c 0 6= c dans A1. Dans ce cas {c 0} ∪ A2 est un star cutset qui sépare c de B1. On a alors C = A1 = {c}. Il existe donc une composante de T|X1 qui n’intersecte pas A1 et par le même argument on peut déduire que B1 = 1 et que l’unique sommet de B1 n’a pas de voisin dans X1. Puisque |X1| ≥ 3, il existe un sommet u dans C1. Maintenant, {c, a2} avec a2 ∈ A2 est un star cutset qui sépare u de B1, c’est une contradiction. Pour démontrer (ii), nous avons simplement à remarquer que si un sommet de Xi n’a pas de voisin dans Xi , alors il forme une composante de T|Xi qui n’intersecte pas à la fois Ai et Bi . Ceci contredit (i). Pour démontrer (iii) et (iv), considérons un sommet a ∈ A1 fortement complet à B1 (les autres cas sont symétriques). Si A1 ∪ C1 6= {a} alors B1 ∪ A2 ∪ {a} est un star cutset qui sépare (A1 ∪ C1) \ {a} de B2. Donc A1 ∪ C1 = {a} et |B1| ≥ 2 car |X1| ≥ 3. Mais alors B1 est un ensemble homogène, fortement complet à A1 et fortement anticomplet à A2 et donc T admet une skew-partition équilibrée d’après le lemme 2.7, c’est une contradiction. Pour démontrer (v) et (vi), considérons un sommet a ∈ A1 fortement anticomplet à C1 ∪ B1 (les autres cas sont symétriques). D’après (ii), le sommet a a un voisin dans A1, et donc A1 6= {a}. Dans ce cas {a} ∪ B1 ∪ C1 ∪ B2 ∪ C2 est un star cutset dans T. C’est une contradiction. Pour démontrer (vii), supposons que C1 = ∅ et que |A1| = 1 (les autres cas sont symétriques). D’après (iv) et (vi), et comme C1 = ∅, A1 est à la fois complet et anticomplet à B1. Ceci implique que l’unique sommet de A1 soit semiadjacent à tous les sommets de B1 et donc puisque T est apprivoisé, |B1| ≤ 2. Puisque |X1| ≥ 3, |B1| = 2 et comme T est apprivoisé, l’unique sommet de A1 est ou bien 23CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS fortement complet ou bien fortement anticomplet à V (T) \ (A1 ∪ B1), c’est une contradiction car A1 est fortement complet à A2 et fortement anticomplet à B2. Pour démontrer (viii), nous pouvons supposer d’après (vii) que C1 6= ∅. Supposons donc par contradiction que |A1| = |C1| = |B1| = 1. Soit a, b, c les sommets de respectivement A1, B1, C1. D’après (iii), ab est une antiarête. De plus, c est adjacent au sommet a sinon il y aurait un star cutset centré en b qui séparerait a de c. Pour la même raison c est adjacent à b. Puisque la réalisation complète de T|X1 n’est pas un chemin de longueur 2 allant de a à b, nous savons que ab est une arête optionnelle. Ceci contredit le lemme 2.4. Soit b un sommet de degré deux dans Σ(T) et soit a, c les voisins de b dans Σ(T). Supposons également que b soit léger. Nous appelons un sommet w ∈ V (T)\ {a, b, c} un a-appendice de b s’il existe u, v ∈ V (T) \ {a, b, c} tel que : — a-u-v-w est un chemin ; — u est fortement anticomplet à V (T) \ {a, v} ; — v est fortement anticomplet à V (T) \ {u, w} ; et — w n’a pas de voisin dans Σ(T) à la possible exception de v (i.e. il n’y a pas d’arête optionnelle contenant w dans T à la possible exception de vw). Un c-appendice est défini de la même manière. Si b est un sommet lourd de T, alors w est un a-appendice de b dans T si et seulement si w est un a-appendice de b dans T. Le résultat suivant est analogue au théorème 2.5 pour les trigraphes de Berge bigame. Théorème 2.10. Tout trigraphe de Berge bigame est ou bien basique, ou bien admet une skew-partition équilibrée, un 2-joint propre, ou un 2-joint propre dans son complément. Démonstration. Pour T un trigraphe de Berge bigame, notons τ (T) le nombre de sommets de degré deux dans Σ(T). La démonstration est une induction sur τ (T). Si τ (T) = 0, le résultat est direct à partir du théorème 2.5. Maintenant prenons T un trigraphe de Berge bigame et soit b un sommet de degré deux dans Σ(T). Soient a, c les deux voisins de b dans Σ(T). Quitte à passer au complément, on peut supposer que b est léger. Soit T 0 le trigraphe obtenu à partir de T en rendant a fortement adjacent à b. Si b n’a pas de a-appendice, alors nous n’avons pas besoin d’effectuer plus de modifications ; prenons W = ∅. Dans le cas contraire, choisissons un a-appendice w 242.4. STRUCTURE DES TRIGRAPHES DE BERGE APPRIVOISÉS de b, et prenons u, v comme dans la définition des a-appendices ; prenons V (T 0 ) = V (T) \ {u, v}, W = {w} et rendons a semiadjacent à w dans T 0 . Si W = ∅ alors clairement T 0 est un trigraphe de Berge bigame et τ (T) > τ (T 0 ). Supposons que W 6= ∅. Si t ∈ V (T 0 ) est adjacent à a et à w, alors a-u-v-w-t est un trou impair dans T. Par conséquent aucun sommet de T 0 n’est adjacent à la fois à a et à w. En particulier, il n’y a pas d’antitrou impair de taille au moins 7 dans T 0 qui passe par a et par w. Comme il n’y a pas de trou impair qui passe par a et par w, T 0 est un trigraphe de Berge bigame. De plus τ (T) > τ (T 0 ) (nous rappelons que dans Σ(T), v est l’unique voisin potentiel de w et b est l’unique voisin potentiel de a). Par induction, une des conséquences du théorème 2.10 est vraie pour T 0 . Nous considérons les cas suivants et montrons que pour chacun d’entre eux, une des conséquences du théorème 2.10 est vraie pour T. Cas 1 : T 0 est basique. Supposons d’abord que T 0 est biparti. Nous affirmons que T est biparti. Soit V (T 0 ) = X ∪Y où X et Y sont des stables forts disjoints. L’affirmation est claire si b n’a pas de a-appendice, on peut donc supposer que W = {w}. On peut supposer que a ∈ X ; alors w ∈ Y . Dans ce cas X ∪ {v} et Y ∪ {u} sont des stables forts de T d’union V (T) et donc T est biparti. Supposons que T 0 est un line trigraphe. Observons pour commencer qu’aucune clique de taille au moins trois dans T ne contient u, v ou b. Donc si W = ∅, il est clair que T est un line trigraphe. Nous pouvons donc supposer que W 6= ∅. Remarquons que la réalisation complète de T est obtenue à partir de la réalisation complète de T 0 en subdivisant deux fois l’arête aw. Puisque aucun sommet de T 0 n’est adjacent à la fois à a et à w, T est un line trigraphe (car les line graphes sont clos par subdivision d’arêtes n’ayant pas d’extrémité commune, et que les line graphes de graphes bipartis sont clos par double subdivision de telles arêtes). Supposons que T 0 soit biparti et prenons X, Y une partition de V (T) en deux cliques fortes de T 0 . On peut supposer que a ∈ X. Supposons pour commencer que b ∈ Y . Puisque a est l’unique voisin fort de b dans T 0 , Y = {b} et donc X contient a et c, c’est une contradiction. Par conséquent on peut supposer que b ∈ X. Puisque a est l’unique voisin fort de b dans T 0 , X = {a, b} et b est fortement anticomplet à Y \ {c}. Soit N l’ensemble des voisins forts de a dans Y \ {c} et M l’ensemble des antivoisins forts de a dans Y \ {c}. Puisque T est un trigraphe de Berge bigame, Y = N ∪ M ∪ W ∪ {c}. Si |N| > 1 ou |M| > 1, alors d’après le lemme 2.7 T admet une skew-partition équilibrée. On peut donc supposer que |N| ≤ 1 et que |M| ≤ 1. Puisqu’aucun sommet de T 0 n’est adjacent à la fois à a et 25CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS à w, |N ∪ W| ≤ 1. Maintenant si M = ∅ ou que N ∪ W = ∅, alors T 0 est biparti et nous pouvons procéder comme ci-dessus. Sinon N ∪ W ∪ {c} est un clique cutset de T 0 de taille 2 qui est un star cutset de T et donc d’après le lemme 2.6 T admet une skew-partition équilibrée. Supposons maintenant que T 0 est un line trigraphe. Puisque bc est une arête optionnelle dans T 0 et que b est fortement anticomplet à V (T 0 ) \ {a, b, c}, c est fortement complet à V (T 0 ) \ {a, b, c} sinon il y aurait dans T 0 une clique de taille 3 avec une arête optionnelle. Puisque T 0 est un line trigraphe, pour tout triangle S de T 0 et tout sommet v ∈ V (T 0 ) \ S, v a au moins un voisin fort dans S. Si x, y ∈ V (T 0 ) \ {a, b, c} sont adjacents, alors {x, y, c} est un triangle et b n’a pas de voisin fort à l’intérieur. Par conséquent, V (T 0 ) \ {a, b, c} est un stable fort. Maintenant V (T 0 ) \ {a, c}, {a, c} forme une partition de V (T 0 ) en deux stables forts de T 0 . T 0 est donc biparti et nous pouvons procéder comme ci-dessus. Finalement, supposons que T 0 est un trigraphe doublé et prenons (X, Y ) une bonne partition de T 0 . Si T 0 |Y est vide ou n’a qu’une unique anticomposante, alors T 0 est biparti. Nous pouvons donc supposer que Y contient deux sommets fortement adjacents x et x 0 . S’il existe y 6= x et y 0 6= x 0 , tels que {x, y} et {x 0 , y0} soient des anticomposantes de T 0 |Y , alors tout sommet de T 0 a au moins deux voisins forts, c’est une contradiction à cause de b. Ceci implique que par exemple {x} est une anticomposante de T 0 |Y . Si T 0 |X est connexe ou vide, alors T 0 est le complément d’un trigraphe biparti. On peut donc supposer que T 0 |X a au moins deux composantes. Dans ce cas, Y est un star cutset de T 0 centré en x. Ce cas est le prochain cas traité. Cas 2 : T 0 admets une skew-partition équilibrée. Soit (A, B) une skew-partition équilibrée de T 0 . Si W 6= ∅, prenons A0 = A ∪ {u, v} ; et si W = ∅ prenons A0 = A. Dans tous les cas, T|A0 n’est pas connecté. Nous allons montrer que si une anticomposante Y de B n’intersecte pas {a, b}, alors T admet une skew-partition équilibrée. Puisque a est complet à W dans T 0 , il existe une composante L de A qui n’intersecte pas {a, b} et donc L est aussi une composante de A0 . Sans perte de généralité, on peut supposer que Y est disjoint de W (c’est clair dans le cas où B ∩ {a, b} 6= ∅ et si B ∩ {a, b} = ∅ on peut sans perte de généralité supposer que Y ∩ W = ∅). Maintenant, dans T, Y est fortement complet à B \ Y , L est fortement anticomplet à A0 \L et donc A0 , B0 est une skew-partition de T et (L ∪ Y ) ∩ ({a, b} ∪ W ∪ (A0 \ A)) ⊆ {b}. Puisque A, B est une skew-partition équilibrée de T 0 , la paire (L, Y ) est équilibrée dans T. Par conséquent le lemme 2.8 implique que T admet une skew-partition équilibrée. Nous pouvons donc supposer qu’il n’y a pas de tel ensemble Y et donc T 0 |B a 262.4. STRUCTURE DES TRIGRAPHES DE BERGE APPRIVOISÉS exactement deux anticomposantes, B1 et B2, de plus a ∈ B1 et b ∈ B2. Puisque a est l’unique voisin fort de b dans T 0 , B1 = {a}. Puisque a est anticomplet à W ∪ {c}, nous pouvons en déduire que W ∪ {c} ⊆ A0 . Soit A1 la composante de T|A0 contenant c et A1 = A0 \ A1. Supposons que a n’ait pas de voisin fort dans T. Dans ce cas B2 = {b} et puisque T est un trigraphe de Berge bigame, a est fortement anticomplet à A0 . Nous pouvons supposer que T n’est pas biparti, car sinon nous aurions déjà le résultat. T contient donc un trou impair C, qui doit être dans A1 ou dans A2 (en effet {a, b} est fortement complet à A0 ). Puisque T est un trigraphe de Berge bigame, C contient au moins une arête forte xy. Dans ce cas {x, y} est un star cutset dans T qui sépare {a, b} d’un sommet de A2. D’après le lemme 2.6, T a une skew-partition équilibrée. Nous pouvons donc supposer que le sommet a a au moins un voisin fort dans T. Soit x ∈ A2. Notons N l’ensemble des voisins forts de a dans T. Alors (N ∪ {a}) \ {x} est un star cutset dans T séparant b de x à moins que x soit l’unique voisin fort de a. Dans ce cas {a, x} est un star cutset séparant A1 de A2 \ {x}, à moins que A2 = {x}. Supposons alors que c ait un voisin y (dans ce cas c’est un voisin fort car T est un trigraphe de Berge bigame). Alors {c, y} est un star cutset séparant A1 \ {c, y} de x, à moins que A1 = {c, y} mais dans ce cas T est biparti. Supposons donc que c n’ait pas de voisin dans A1. Si T n’est pas biparti, il contient un trou impair, dans ce cas ce trou est dans A1 et n’importe quelle arête forte (qui existe puisque T est un trigraphe de Berge bigame) forme un star cutset séparant c du reste du trou. D’après le lemme 2.6, T a une skew-partition équilibrée. Cas 3 : T 0 admet un 2-joint propre. Soit (A1, B1, C1, A2, B2, C2) une affectation d’un 2-joint propre de T 0 . Supposons que a ∈ A1 ∪ B1 ∪ C1. Alors W ⊆ A1 ∪ B1 ∪ C1. Si W 6= ∅ prenons C 0 1 = C1 ∪ {u, v}, et sinon prenons C 0 1 = C1. On peut supposer que (A1, B1, C0 1 , A2, B2, C2) n’est pas un 2-joint propre de T et donc sans perte de généralité a ∈ A1 et b ∈ A2. Alors c ∈ B2 ∪ C2. Puisque a est l’unique voisin fort de b dans T 0 , A1 = {a}. D’après le cas 2, on peut supposer que T 0 n’admet pas de skew-partition équilibré et donc le lemme 2.9 implique que a est anticomplet à B1. Remarquons que puisque T est un trigraphe de Berge bigame, ab est la seule arête optionnelle dans T contenant le sommet a. Soit N l’ensemble des voisins forts de a dans C 0 1 dans T. D’après les définitions du 2-joint propre, N 6= ∅. On peut supposer que T n’admet pas de skew-partition équilibrée et donc d’après le lemme 2.9, tout 2-joint de T est propre. Dans ce cas, ou bien (N, B1, C0 1 \ N, {a}, B2, C2 ∪ A2) est une affectation d’un 2-joint propre de T, ou bien |N| = |B1| = 1 et la réalisation complète de T|(C 0 1 ∪ B1) est un chemin de longueur deux entres N et B1. Notons 27CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS n-n 0 -b1 ce chemin avec n ∈ N et b1 ∈ B1. Puisque b1 n’a pas de voisin dans Σ(T) à l’exception possible de n 0 , b1 est un a-appendice de b. En particulier, W 6= ∅. Puisque W ⊆ B1 ∪ C1, w = b1, u = n et v = n 0 . Dans ce cas |A1 ∪ B1 ∪ C1| = 2, ce qui contredit le fait que (A1, B1, C1, A2, B2, C2) soit l’affectation d’un 2-joint propre de T 0 . Cas 4 : (T 0 ) admet un 2-joint propre. Soit (A1, B1, C1, A2, B2, C2), une affectation d’un 2-joint dans T 0 . Commençons par supposer que W 6= ∅. Alors on peut supposer que a, w ∈ A1 ∪ B1 ∪ C1. Puisqu’aucun sommet de T 0 est adjacent à la fois à a et à w, on peut supposer sans perte de généralité que a ∈ A1, w ∈ B1 et C2 = ∅. Puisque a est l’unique voisin fort de b dans T 0 , b ∈ B2 et C1 = ∅. Dans ce cas (A1, B1, ∅, B2, A2, ∅) est une affectation d’un 2-joint de T 0 . D’après le deuxième cas, on peut supposer que T 0 n’admet pas de skew-partition équilibrée et donc ce 2-joint est propre d’après le lemme 2.9. Nous pouvons alors procéder comme dans le cas précédent. Supposons donc que W = ∅. On peut supposer que (A1, B1, C1, A2, B2, C2) n’est pas une affectation d’un 2-joint propre de T, par conséquent et sans perte de généralité, a ∈ A1 ∪ B1 ∪ C1, et b ∈ A2 ∪ B2 ∪ C2. Puisque a est l’unique voisin fort de b dans T 0 et puisque A1, B1 sont tous les deux non-vides, b 6∈ C2, et on peut alors supposer que b ∈ B2. Puisque A1 6= ∅, C1 = ∅ et A1 = {a}. Puisque |A1 ∪ B1 ∪ C1| ≥ 3, |B1| ≥ 2. De plus c est fortement antiadjacent à a et semiadjacent à b dans T, on peut donc en déduire que c ∈ A2. Maintenant, si le sommet a a un voisin x dans B1 dans le trigraphe T (c’est alors un voisin fort), alors {x, a} ∪ A2 ∪ C2 est un star cutset dans T, et si a est fortement anticomplet à B1 dans T, d’après la définition du 2-joint propre, B1 est un ensemble homogène dans T. Dans tous les cas, d’après le lemme 2.6 ou le lemme 2.7, T admet une skew-partition équilibrée. 2.5 Blocs de décomposition La manière d’utiliser les décompositions dans les chapitres suivantes nous demande de construire des blocs de décompositions et de récursivement poser plusieurs questions sur ces blocs. Pour pouvoir faire cela, nous devons nous assurer que les blocs de décompositions sont toujours dans notre classe de graphes. Un ensemble X ⊆ V (T) est un fragment d’un trigraphe T si une des conditions suivantes est vérifiée : 1. (X, V (T) \ X) est un 2-joint propre de T ; 282.5. BLOCS DE DÉCOMPOSITION A2 C2 B2 X2 A2 C2 B2 X2 Figure 2.6 – Blocs de décomposition : 2-joint 2. (X, V (T) \ X) est un complément de 2-joint propre de T. Remarquons qu’un fragment de T est un fragment de T. Nous pouvons maintenant définir le bloc de décomposition TX associé à un fragment X. Un 2-joint est pair ou impair suivant la parité des longueurs des chemins décrits par le lemme 2.4. Si (X1, X2) est un 2-joint propre impair et si X = X1, alors prenons (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Nous construisons alors le bloc de décomposition TX1 = TX comme suit. Nous partons de T|(A1 ∪ B1 ∪ C1). Nous ajoutons ensuite deux sommets marqués a et b, tels que a est fortement complet à A1, b est fortement complet à B1, ab est une arête optionnelle et il n’y a aucune autre arête entre {a, b} et X1. Remarquons que {a, b} est une composante optionnelle de TX. Nous l’appelons la composante marquée de TX. Si (X1, X2) est un 2-joint propre pair et si X = X1, alors prenons (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Nous construisons alors le bloc de décomposition TX1 = TX comme suit. Nous partons de T|(A1 ∪ B1 ∪ C1). Nous ajoutons ensuite trois sommets marqués a, b et c, tels que a est fortement complet à A1, b est fortement complet à B1, ac et cb sont deux arêtes optionnelles et il n’y a aucune autre arête entre {a, b, c} et X1. À nouveau nous appelons {a, b, c} la composante marquée de TX. Si (X1, X2) est le complément d’un 2-joint propre impair et si X = X1, alors prenons (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Nous construi- 29CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS A2 C2 B2 X2 A2 C2 B2 X2 Figure 2.7 – Blocs de décomposition : Complément de 2-joint sons alors le bloc de décomposition TX1 = TX comme suit. Nous partons de T|(A1 ∪ B1 ∪ C1). Nous ajoutons ensuite deux sommets marqués a et b, tels que a est fortement complet à B1 ∪ C1, b est fortement complet à A1 ∪ C1, ab est une arête optionnelle et il n’y a aucune autre arête entre {a, b} et X1. À nouveau nous appelons {a, b} la composante marquée de TX. Si (X1, X2) est le complément d’un 2-joint propre pair et si X = X1, alors prenons (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Nous construisons alors le bloc de décomposition TX1 = TX comme suit. Nous partons de T|(A1∪B1∪C1). Nous ajoutons ensuite trois sommets marqués a, b et c, tels que a est fortement complet à B1 ∪ C1, b est fortement complet à A1 ∪ C1, ac et cb sont deux arêtes optionnelles, ab est une arête forte et il n’y a aucune autre arête entre {a, b, c} et X1. À nouveau nous appelons {a, b, c} la composante marquée de TX. Lemme 2.11. Si X est un fragment d’un trigraphe T de Berge bigame, alors TX est un trigraphe de Berge bigame. Démonstration. Par définition de TX, il est clair que tout sommet de TX est ou bien dans au plus une arête optionnelle, ou bien est lourd, ou bien est léger, TX est donc bien un trigraphe bigame. Il reste juste à démontrer que TX est de Berge. Soit X = X1 et (X1, X2) un 2-joint propre de T. Soit (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). 302.5. BLOCS DE DÉCOMPOSITION Commençons par supposer que TX1 a un trou impair H = h1- · · · -hk-h1. Notons ZX1 l’ensemble des sommets marqués de TX1 . Supposons que les sommets de ZX1 soient consécutifs dans H, alors H \ ZX1 est un chemin P dont une extrémité est dans A1, l’autre dans B1 et dont l’intérieur est dans C1. Un trou de T est obtenu en ajoutant à P un chemin dont une extrémité est dans A2, dont l’autre extrémité est dans B2 et dont l’intérieur est dans C2. D’après le lemme 2.4 ce trou est impair, c’est une contradiction. Dans ce cas les sommets marqués ne sont pas consécutifs dans H, et puisque c n’a pas de voisin dans V (T) \ {a, b, c}, on peut en déduire que c 6∈ V (H). Maintenant, un trou de même longueur que H peut être obtenu dans T en remplaçant si besoin a et/ou b par des sommets a2 ∈ A2 et b2 ∈ B2, choisi pour être antiadjacent (ce qui est possible d’après le lemme 2.9). Supposons alors que TX1 ait un antitrou impair H = h1- · · · -hk-h1. Puisqu’un antitrou de longueur 5 est également un trou, on peut supposer que H est de longueur au moins 7. Donc dans H, toute paire de sommets à un voisin commun. Il y a donc au plus un sommet parmi a, b, c qui est dans H, et à cause de son degré, c ne peut pas être dans H. Un antitrou de même longueur que H peut être obtenu dans T en remplaçant si besoin a ou b par un sommet a2 ∈ A2 ou b2 ∈ B2, encore une fois c’est une contradiction. Remarquons que les cas où T a un complément de 2-joint sont traités par complémentation. Lemme 2.12. Si X est un fragment d’un trigraphe T de Berge apprivoisé, alors le bloc de décomposition TX n’a pas de skew-partition équilibrée. Démonstration. Pour démontrer ce résultat commençons par supposer que TX ait une skew-partition équilibrée (A0 , B0 ) et notons (A0 1 , A0 2 , B0 1 , B0 2 ) une affectation de cette skew-partition. Cherchons maintenant une skew-partition dans T. Nous utiliserons le lemme 2.8 pour démontrer qu’il existe alors une skew-partition équilibrée dans T. Le résultat sera alors vrai par contradiction. Soit X = X1 et (X1, X2) un 2-joint propre de T. Soit (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Puisque les sommets marqués dans TX, a et b n’ont pas de voisin fort commun et que c n’a pas de voisin fort, il y a, à symétrie près, deux cas : a ∈ A0 1 et b ∈ A0 1 , ou a ∈ A0 1 et b ∈ B0 1 . Remarquons que lorsque (X1, X2) est pair, le sommet marqué c doit être dans A0 1 car il est adjacent au sommet a et n’a pas de voisin fort. Commençons par supposer que les sommets a et b sont tous les deux dans A0 1 . Dans ce cas (X2 ∪ A0 1 \ {a, b, c}, A0 2 , B0 1 , B0 2 ) est une affectation d’une skew- 31CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS partition (A, B) dans T. La paire (A0 2 , B0 1 ) est équilibrée dans T car elle l’est dans TX. Donc d’après le lemme 2.8, T admets une skew-partition équilibrée, c’est une contradiction. Les sommets a et b ne sont donc pas tous les deux dans A0 1 et donc a ∈ A0 1 et b ∈ B0 1 . Dans ce cas, (A2 ∪C2 ∪A0 1 \ {a, c}, A0 2 , B2 ∪B0 1 \ {b}, B0 2 ) est une affectation d’une skew-partition (A, B) dans T. La paire (A0 2 , B0 2 ) est équilibrée dans T car elle l’est dans TX. Donc d’après le lemme 2.8, T admet une skew-partition équilibrée, c’est une contradiction. Le cas où T admet un complément de 2-joint se prouve par complémentation. Nous avons dans ce chapitre introduit toutes les notions de base qui vont nous être utiles dans les chapitres suivants. Les résultats les plus importants sont le théorème 2.10 et les lemmes 2.11 et 2.12 qui nous permettent de dire que les trigraphes de Berge apprivoisés se décomposent par 2-joint et complémentaire de 2- joint et que les blocs construits restent dans la classe. Ces résultats sont la base des trois chapitres suivants dans lesquels nous allons pouvoir prouver divers résultats sur la classe en décomposant nos graphes puis en appliquant une induction. Enfin, notons que les graphes de Berge sans skew-partition forment une sousclasse stricte des graphes de Berge. La figure 2.8 montre un graphe qui, si l’on se restreint à notre ensemble de décomposition, n’est décomposable que par skewpartition. Dans ce graphe, les arêtes de couleurs vont vers tous les sommets de possédant la même couleur. Un résultat important serait d’arriver, en étendant l’ensemble des décompositions autorisées, à se débarrasser des skew-partitions. 322.5. BLOCS DE DÉCOMPOSITION Figure 2.8 – Un graphe de Berge décomposable uniquement par skew-partition 33CHAPITRE 2. TRIGRAPHES DE BERGE APPRIVOISÉS 34Chapitre 3 Propriété du grand biparti Les résultats de ce chapitre ont été obtenus avec Aurélie Lagoutte, ils font l’objet d’un article [26] soumis à Discrete Mathematics. Une des propriétés les plus simples à obtenir à l’aide d’une décomposition par 2-joints est celle du grand biparti. On dit qu’un graphe G d’ordre n a la c-propriété du grand biparti, s’il existe deux ensembles de sommets V1 ⊆ V et V2 ⊆ V , tels que |V1| ≥ cn˙ , |V2| ≥ cn˙ et que V1 soit ou bien complet, ou bien anticomplet à V2. On dit qu’une classe de graphes C a la propriété du grand biparti s’il existe une constante c, telle que tout graphe G ∈ C d’ordre n a la c-propriété du grand biparti. Cette propriété est appelée propriété d’Erdős Hajnal forte dans [22]. Par exemple, pour tout entier k, les graphes sans Pk, ni Pk induit ont la propriété du grand biparti [5]. Cette propriété est intéressante car dans le cas des classes de graphes définies par un unique sous-graphe induit H interdit, elle implique la propriété d’Erdős-Hajnal [3, 22]. C’est à dire qu’il existe une constante δH qui dépend de H, telle que tout graphe G de la classe contient une clique ou un stable de taille |V (G) δH |. Nous allons montrer le résultat suivant : Théorème 3.1. Tout graphe de Berge sans skew-partition équilibrée a la propriété du (1/148)-grand biparti. Ce résultat n’implique pas la propriété d’Erdős-Hajnal, puisque la classe des graphes de Berge apprivoisés n’est pas close par sous-graphe induit, en effet la suppression de sommets peut créer des skew-partitions équilibrées. Cependant, il est facile de voir que la propriété d’Erdős-Hajnal est une conséquence directe 35CHAPITRE 3. PROPRIÉTÉ DU GRAND BIPARTI du théorème fort des graphes parfaits. En effet, pour tout graphe G, |V (G)| ≤ χ(G)α(G) et par perfection des graphes de Berge χ(G) = ω(G), on sait donc que pour tout graphe de Berge G |V (G)| ≤ ω(G)α(G) donc pour tout graphe de Berge, ou bien ω(G) ≥ q |V (G)| ou bien α(G) ≥ q |V (G)|. En fait nous n’avons même pas besoin du théorème fort des graphes parfaits, il suffit d’avoir l’inégalité |V (G)| ≤ ω(G)α(G), prouvée dès 1972 par Lovász [28]. Le théorème 3.1 est dans un certain sens un résultat négatif, en effet les graphes de Berge n’ont en général pas la propriété du grand biparti. Interdire les skewpartitions donne donc une classe sensiblement plus petite. Comme l’a observé Seymour [34], les graphes de comparabilité non triviaux (ici qui ne sont ni des cliques, ni des graphes bipartis) ont tous une skew-partition. En fait Chvátal à démontré [16] que les graphes parfaitement ordonables, c’est à dire une super classe des graphes de comparabilité sont, ou bien biparti, ou bien admettent un starcutset dans leur complémentaire. Les graphes de comparabilité étant des graphes de Berge, c’est une des classes les plus intéressantes à regarder pour comprendre les restrictions posées par l’interdiction des skew-partitions équilibrées. Le résultat suivant est le théorème 2 de [21]. Théorème 3.2. Soit ε ∈ (0, 1). Pour tout entier n suffisamment grand, il existe un ordre partiel P sur n éléments tel qu’aucun élément de P n’est comparable à n ε autres éléments de P et pour tout A, B ⊂ P tels que |A| = |B| > 14n ε log2 n , il y a un élément de A comparable à un élément de B. En prenant les graphes de comparabilité des ordres partiels fournis par ce théorème, nous avons une classe de graphes parfaits qui n’a pas la propriété du grand biparti. À partir d’un ordre partiel, on construit son graphe de comparabilité de la manière suivante, les sommets sont les éléments de l’ordre et il y un arête entre deux sommets si et seulement si les éléments qu’ils représentent sont comparables dans l’ordre partiel. Le but de ce chapitre est de montrer que les graphes de Berge apprivoisés ont la propriété du grand biparti. Pour cela nous allons généraliser le problème aux trigraphes de Berge apprivoisés. Commençons par étendre la définition. Nous verrons ensuite comment généraliser ce résultat aux classes construites par k-joints généralisés. 363.1. GRAND BIPARTI DANS LES TRIGRAPHES DE BERGE APPRIVOISÉS 3.1 Grand biparti dans les trigraphes de Berge apprivoisés Soit une constante 0 < c < 1, un trigraphe T sur n sommet a la c-propriété du grand biparti s’il existe V1, V2 ⊆ V (T) tels que |V1|, |V2| ≥ cn˙ et que V1 est fortement complet ou anticomplet à V2. Il est immédiat de voir que pour les trigraphes sans arêtes optionnelles, la définition coïncide avec celle sur les graphes. Une autre remarque importante est que la propriété du grand biparti est une propriété autocomplémentaire : un trigraphe T a la propriété du grand biparti si et seulement si son complémentaire T a aussi la propriété du grand biparti. Nous rappelons qu’être un trigraphe de Berge apprivoisé est aussi une propriété auto-complémentaire. Lors de nos inductions nous pouvons donc ramener le cas des complémentaires de 2- joints au cas des 2-joints. Nous allons démontrer le résultat suivant : Théorème 3.3. Soit T un trigraphe de Berge apprivoisé, tel que n = |V (T)| ≥ 3. Alors T a la (1/148)-propriété du grand biparti. Pour les besoins de l’induction nous devons encore étendre notre problème aux trigraphes de Berge apprivoisés pondérés. Dans la suite, on associe à tout trigraphe T une fonction de poids w : V (T) ∪ E ∗ (T) → N, telle que w(v) > 0 pour v ∈ V (T) et que toute arête optionnelle de poids non nul soit étiquetée avec “2-joint” ou “complément 2-joint”. Pour tout sous-ensemble V 0 ⊆ V (T), on note w(V 0 ) = P v∈V 0 w(v) + P u,v∈V 0 w(uv). Avec ces notations, le poids W d’un trigraphe T est la somme w(V (T)) de ses poids, et étant donné une constante c < 1, on dit que T a la c-propriété du grand biparti, s’il existe V1, V2 ⊆ V (T), tels que w(V1), w(V2) ≥ cW˙ et V1 est fortement complet ou fortement anticomplet à V2. Remarquons que si w est une fonction de poids telle que w(v) = 1 pour tout sommet v ∈ V (T) et que w(uv) = 0 pour toute arête optionnelle uv ∈ E ∗ (T), nous obtenons la notion précédente. Remarquons également que la propriété du grand biparti est stable par réalisation comme le montre le lemme suivant. Lemme 3.4. Soit CT une classe de trigraphes ayant la c-propriété du grand biparti, alors la classe des graphes C = {G, G est une réalisation de T ∈ CT } a la c-propriété du grand biparti. Démonstration. Si un trigraphe T a la propriété du grand biparti, il existe une paire d’ensembles de sommets V1, V2 ⊆ V (T) témoins de la propriété. Dans toute 37CHAPITRE 3. PROPRIÉTÉ DU GRAND BIPARTI réalisation de T, V1, V2 reste une paire de témoins de la propriété du grand biparti. L’idée de la démonstration du théorème 3.1 est de contracter les sommets de T, tout en préservant les poids jusqu’à obtenir un trigraphe basique. Soit T un trigraphe avec une fonction de poids w, (X1, X2) un 2-joint propre dans T ou dans son complément T, tel que w(X1) ≥ w(X2), et (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Définissons le trigraphe T 0 avec la fonction de poids w 0 comme la contraction de T, noté (T, w) ❀ (T 0 , w0 ). T 0 est le bloc de décomposition TX1 et sa fonction de poids w 0 est définie comme suit : — Sur les sommets de X1, on définit w 0 = w. — Sur les sommets marqués a, b, on définit w 0 (a) = w(A2) et w 0 (b) = w(B2) — Si le sommet marqué c existe, on définit w 0 (c) = w(C2). Sinon, on définit w 0 (ab) = w(C2) et on étiquette ab en fonction du type de (X1, X2). On définit a (resp. b, v ∈ X1) comme étant le représentant de A2 (resp. B2, v) et pour tout sommet v ∈ A2 (resp. B2, X1) on note v → a (resp. v → b, v → v). Suivant l’existence de c, c ou ab est le représentant de C2 et pour tout sommet v ∈ C2 on note v → c ou v → ab. Si (T, w) ❀ (T 0 , w0 ) et V 0 ⊆ V (T 0 ), on note également V → V 0 si V = {v ∈ V (T)|∃v 0 ∈ V 0 v → v 0∨ ∃u 0 v 0 ∈ V 02 v → u 0 v 0}. On note par →∗ (resp. ❀∗ ) la clôture transitive de → (resp. ❀). Lemme 3.5. Si T est un trigraphe avec une fonction de poids w et (T, w) ❀∗ (T 0 , w0 ) alors : — w 0 (V (T 0 )) = w(V (T)) — Si T 0 a la c-propriété du grand biparti, alors T aussi. Démonstration. La première partie du résultat est claire. Supposons que T 0 ait la c-propriété du grand biparti. Alors il existe W1, W2 ⊆ V (T), tels que W1 →∗ V1 et W2 →∗ V2. Puisque la contraction ne crée ni adjacence forte, ni antiadjacent forte qui n’existaient pas auparavant, si V1, V2 sont fortement complets (resp. anticomplets), W1, W2 sont également fortement complets (resp. anticomplets). De plus w(W1) = w 0 (V1) et w(W2) = w 0 (V2). Donc la paire (W1, W2) prouve que T 0 a la c-propriété du grand biparti. 383.1. GRAND BIPARTI DANS LES TRIGRAPHES DE BERGE APPRIVOISÉS Lemme 3.6. Soit 0 < c < 1/6. Soit T un trigraphe de Berge apprivoisé, et w sa fonction de poids telle que w(x) < cn˙ pour tout x ∈ V (T) ∪ E ∗ (T). Ou bien T a la c-propriété du grand biparti, ou bien il existe un trigraphe basique T 0 avec sa fonction de poids associée w 0 tel que (T, w) ❀∗ (T 0 , w0 ) et pour tout x ∈ V (T 0 ) ∪ E ∗ (T 0 ), w(x) < cn˙ . Démonstration. On prouve le résultat par induction sur T, en utilisant le résultat de décomposition sur les trigraphes de Berge bigames (Théorème 2.10). Si T n’est pas basique, alors il admet un 2-joint propre ou le complément d’un 2-joint propre. Le problème étant auto-complémentaire, nous traitons uniquement le cas d’un 2- joint (X1, X2) de T. Par symétrie, supposons que w(X1) ≥ w(X2) et donc w(X1) ≥ n/2. Soit (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Par définition de X1, max(w(A1), w(B1), w(C1)) ≥ n/6 ≥ cn˙ . Donc si max(w(A2), w(B2), w(C2)) ≥ cn˙ , on a la c-propriété du grand biparti. Sinon, (T, w) ❀ (T 0 , w0 ) avec w 0 (x) < cn˙ pour tout x ∈ V (T 0 ) ∪ E ∗ (T 0 ) et T 0 est un trigraphe de Berge apprivoisé d’après 2.11. On peut donc appliquer l’hypothèse d’induction et ; ou bien trouver un trigraphe basique T 00, tel que (T, w) ❀ (T 0 , w0 ) ❀∗ (T 00, w00) et w 00(x) < cn˙ pour tout x ∈ V (T 00) ∪ E ∗ (T 00); ou bien T 0 a la c-propriété du grand biparti, et donc T aussi d’après le lemme 3.5. Si T est un trigraphe basique avec une fonction de poids w, on veut transformer T en un trigraphe ayant des poids uniquement sur ses sommets en transférant les poids des arêtes optionnelles sur de nouveaux sommets. On définit l’extension T 0 de T comme le trigraphe avec la fonction de poids w 0 : V (T 0 ) → N\{0} définie comme suit : V (T 0 ) = V (T) ∪ {vab|ab ∈ E ∗ (T), w(ab) > 0}, w 0 (v) = w(v) pour v ∈ V (T), l’étiquette de ab est donnée par vab, w 0 (vab) = w(ab), θ(avab) = θ(bvab) = 0, et si u ∈ V \ {a, b}, alors θ(uvab) = −1 si l’étiquette de ab est “2-joint” et θ(uvab) = 1 si l’étiquette est “complément 2-joint”. Remarquons que ab était le représentant de C2 de l’affectation (A1, B1, C1, A2, B2, C2) du 2-joint, et que vab prend sa place en tant que contraction de C2, puisque qu’il a le même poids et les même adjacences et antiadjacences fortes vis à vis du reste du trigraphe. Il n’était pas possible de garder la contraction de C2 à chaque étape et en même temps de rester apprivoisé, ce qui est la clé du lemme 3.6. Remarquons finalement que les nouveaux sommets ajoutés étiquetés “2-joint” forment un stable et que ceux étiquetés “complément de 2-joint” forment une clique. 39CHAPITRE 3. PROPRIÉTÉ DU GRAND BIPARTI Lemme 3.7. Soit T un trigraphe de Berge apprivoisé et w sa fonction de poids associée, tel que w(uv) = 0 pour tout uv ∈ E ∗ (T). Supposons que (T, w) ❀∗ (T 0 , w0 ) et soit T 00 avec sa fonction de poids w 00 l’extension de T 0 . Si T 00 a la c-propriété du grand biparti, alors T aussi. Démonstration. Soit (V1, V2) deux sous-ensembles de T 00 prouvant que T 00 a la c propriété du grand biparti. Soit X1 ⊆ V1 un sous-ensemble de sommets de V1 étiquetés. Alors V1\X1 ⊆ V (T 0 ) et il existe W1 ⊆ V (T), tel que W1 →∗ V1\X1. Soit Y1 = {v ∈ V (T)|∃vab ∈ X1, v → ab}. Alors w(W1 ∪ Y1) = w 00(V1) ≥ cn˙ . On définit de la même manière X2, W2 et Y2 et nous avons les même inégalités w(W2 ∪Y2) = w 00(V2) ≥ cn˙ . De plus, W1∪Y1 est fortement complet (resp. anticomplet) à W2∪Y2 si V1 est fortement complet (resp. anticomplet) à V2. Donc T a la c-propriété du grand biparti. Lemme 3.8. Si T 0 est l’extension d’un trigraphe basique T de Berge apprivoisé et que sa fonction de poids associée w0 vérifie w0(x) < cn˙ pour tout x ∈ V (T) ∪ E ∗ (T) et si c ≤ 1/148, alors T 0 a la c-propriété du grand biparti. Avant de pouvoir démontrer ce résultat nous avons besoin d’un lemme technique. Un graphe G a m arêtes-multiples si son ensemble d’arêtes E est un multiensemble de V 2 \ {xx|x ∈ V (G)} de taille m : il peut y avoir plusieurs arêtes entre deux sommets distincts mais pas de boucle. Une arête uv a deux extrémités u et v. Le degré de v ∈ V (G) est d(v) = |{e ∈ E|v est une extrémité de e}|. Lemme 3.9. Soit G un graphe biparti (A, B) avec m arêtes multiples et de degré maximum cm˙ avec c < 1/3. Alors il existe des sous-ensembles d’arêtes E1, E2 de G, tels que |E1|, |E2| ≥ m/48 et si e1 ∈ E1, e2 ∈ E2 alors e1 et e2 n’ont pas d’extrémité commune. Démonstration. Si m ≤ 48, il suffit de trouver deux arêtes sans extrémité commune. De telles arêtes existent toujours puisque le degré maximum est borné par cm˙ , donc aucun sommet ne peut être une extrémité commune à toutes les arêtes. Sinon si m > 48, considérons une partition aléatoire uniforme (U, U0 ) des sommets. Pour toute paires d’arêtes distinctes e1, e2, considérons la variable aléatoire Xe1,e2 = 1 si (e1, e2) ∈ (U 2 × U 02 ) ∪ (U 02 × U 2 ), et 0 sinon. Si e1 et e2 ont au moins une extrémité commune, alors Pr(Xe1,e2 = 1) = 0, sinon Pr(Xe1,e2 = 1) = 1/8. 403.1. GRAND BIPARTI DANS LES TRIGRAPHES DE BERGE APPRIVOISÉS Nous définissons alors : p = |{(e1, e2) ∈ E 2 |e1 et e2 n’ont pas d’extrémité commune}| pA = |{(e1, e2) ∈ E 2 |e1 et e2 n’ont pas d’extrémité commune dans A}| qA = |{(e1, e2) ∈ E 2 |e1 6= e2 et e1 et e2 n’ont pas d’extrémité commune dans A}| Nous définissons de la même manière pB et qB. Supposons que p ≥ 1 3  m 2  . Alors : E( X e1,e2∈E e16=e2 Xe1,e2 ) = X e1,e2∈E e16=e2 Pr(Xe1,e2 = 1) = p 8 ≥ 1 24 m 2 ! . Donc il existe une partition (U, U0 ) telle que : X e1,e2∈E e16=e2 Xe1,e2 ≥ 1 24 m 2 ! . Soit E1 = E ∩ U 2 et E2 = E ∩ U 02 . Alors |E1|, |E2| ≥ m/48, sinon : X e1,e2∈E e16=e2 Xe1,e2 = |E1| · |E2| < m 48 ·  1 − 1 48 m ≤ 1 24 m 2 ! , c’est une contradiction. Donc E1 et E2 vérifient les hypothèses du lemme. Il nous reste donc à démontrer que p ≥ 1 3  m 2  . Le résultat intermédiaire clé est que pA ≥ 2qA. Numérotons les sommets de A de 1 à |A| et rappelons que d(i) est le degré de i. Alors P|A| i=1 d(i) = m et : pA = 1/2   X |A| i=1 d(i)(m − d(i))   = 1/2     X |A| i=1 d(i)   2 − X |A| i=1 (d(i))2   = 1/2   X |A| i,j=1 i6=j d(i)d(j)   qA = 1/2   X |A| i=1 d(i)(d(i) − 1)   = 1/2   X |A| i=1 (d(i))2 − m   41CHAPITRE 3. PROPRIÉTÉ DU GRAND BIPARTI Par conséquent : 2pA − (4qA + 2m) = X |A| i=1 d(i)   X |A| j=1 j6=i d(j) − 2d(i)   = X |A| i=1 d(i)   X |A| j=1 d(j) − 3d(i)   = X |A| i=1 d(i) (m − 3d(i)) Mais pour tout i, d(i) ≤ cm˙ ≤ m/3 donc m − 3d(i) ≥ 0. Par conséquent, 2pA − (4qA + 2m) ≥ 0 et donc pA ≥ 2qA. Mais pA + qA =  m 2  donc qA ≤ 1 3  m 2  . De la même manière, pB ≥ 2qB et qB ≤ 1 3  m 2  . Finalement : p ≥ m 2 ! − qA − qB ≥ m 2 ! − 2 3 m 2 ! ≥ 1 3 m 2 ! . Démonstration du lemme 3.8. Soit w la fonction de poids associée à T 0 . Puisque le problème est auto-complémentaire, il suffit de démontrer le résultat si T est un trigraphe biparti, un trigraphe doublé ou un line trigraphe. Si T est un trigraphe doublé, alors T a une bonne partition (X, Y ). En fait, X est l’union de deux stables X1, X2 et Y est l’union de deux cliques Y1 et Y2. Donc T 0 est l’union de trois stables X1, X2, X3 (X3 est l’ensemble des sommets étiquetés “2-joint”) et de trois cliques Y1, Y2, Y3 (Y3 est l’ensemble des sommets étiquetés “complément de 2-joint”). Il existe un ensemble Z parmi ces six ensembles de taille au moins n/6. Puisque chaque sommet de Z a poids au plus cn˙ , on peut partitionner Z en (Z1, Z2) avec w(Z1), w(Z2) ≥ n/12 − cn˙ ≥ cn˙ et Z1 est ou bien fortement complet à Z2 (c’est le cas si Z est une clique forte) ou bien fortement anticomplet à Z2 (c’est le cas si Z est un stable fort). Le même argument s’applique si T est un trigraphe biparti, puisque c’est alors l’union de deux stables forts. La démonstration est plus compliquée si T est un line trigraphe. Soit X le stable fort des sommets étiquetés “2-joint” dans T, Y la clique forte des sommets étiquetés “complément de 2-joint”, et Z = V (T 0 ) \ (X ∪ Y ). Par définition du line trigraphe, la réalisation complète de T 0 |Z est le line graphe d’un graphe biparti G, et toute clique de T 0 |Z de taille au moins trois est une clique forte. Si vab ∈ X, 423.1. GRAND BIPARTI DANS LES TRIGRAPHES DE BERGE APPRIVOISÉS alors la réalisation complète de T 0 |(Z ∪ {vab}) est aussi le line graphe d’un graphe biparti : en effet, vab est semiadjacent à exactement a et b, et antiadjacent au reste des sommets. Par hypothèse sur les cliques de taille trois de T, il ne peut y avoir de sommet d ∈ Z adjacent à la fois à a et à b. Cela veut dire que l’extrémité commune x de a et b dans G a degré exactement deux. Ajoutons l’arête vab entre x et un nouveau sommet, alors la réalisation complète de T 0 |(Z ∪ {vab}) est le line graphe d’un graphe biparti. En itérant ce procédé, la réalisation complète T 0 |(Z ∪ X) est également le line graphe d’un graphe biparti. Distinguons alors deux cas : s’il existe une clique K de poids w(K) ≥ 4cn˙ dans T 0 , alors nous pouvons partitionner K en (K1, K2) avec w(K1), w(K2) ≥ 4cn/˙ 2 − cn˙ ≥ cn˙ et K1 est fortement complet à K2. Sinon, remarquons que dans Z∪X, toute composante optionnelle a au plus trois sommets. Pour chaque composante prenons le sommets de poids maximal pour obtenir un ensemble de sommets V 0 ⊆ Z ∪ X sans arête optionnelle entre eux, c’est à dire T 0 |V 0 est un graphe. De plus T 0 |V 0 est un sous-graphe de la réalisation complète de T 0 |(Z ∪ X) et donc est le line graphe d’un graphe biparti G. Au lieu de garder les poids strictement positifs sur les arêtes de G, nous transformons chaque arête xy de poids m en m arêtes xy. L’inégalité w(K) ≤ 4cn˙ pour toute clique K implique que d’une part le degré maximum d’un sommet de G est 4cn˙ , d’autre part, n 0 = w(V 0 ) ≥ (n − w(Y ))/3 ≥ n(1 − 4c)/3, puisque Y est une clique. Le lemme 3.9 prouve l’existence de deux sous-ensembles d’arêtes E1, E2 de G tels que |E1|, |E2| ≥ n 0/48 et si e1 ∈ E1, e2 ∈ E2 alors e1 et e2 n’ont pas d’extrémité commune. Cela correspond dans T 0 un témoin anticomplet de la propriété du grand biparti. Démonstration du Théorème 3.3. Soit c = 1/148. Si n < 1/c, il existe toujours une arête forte ou une antiarête forte uv par définition des trigraphes bigames, et nous définissons V1 = {u} et V2 = {v}. Sinon, donnons à T la fonction de poids w, telle que w(v) = 1 pour tout v ∈ V (T) (en particulier, w(V (T)) = n). Appliquons le lemme 3.6 à T pour obtenir ou bien la c propriété du grand biparti, ou bien pour contracter T : il existe un trigraphe basique T 0 tel que (T, w) ❀∗ (T 0 , w0 ). Appliquons alors le lemme 3.8 pour avoir la c-propriété du grand biparti dans l’extension de T 0 . Grâce au lemme 3.7 nous avons bien la c-propriété du grand biparti. 43CHAPITRE 3. PROPRIÉTÉ DU GRAND BIPARTI 3.2 Clôture par k-joints généralisés Dans cette section nous allons voir comment nous pouvons utiliser une géné- ralisation des 2-joints afin d’obtenir un résultat analogue. Les résulats 2.10, 2.11 et 2.12 montrent qu’en fait les trigraphes de Berge apprivoisés sont la clôture par 2-joints et complément de 2-joints des classes basiques (trigraphes biparti, line trigraphes, trigraphes doublés et leurs complémentaires). Ces classes basiques ont la propriété du grand biparti et le théorème 3.3 montre que prendre la clôture de cette classe préserve la propriété du grand biparti. Dans cette section nous allons voir comment à partir d’une classe de graphes héréditaire nous pouvons obtenir une classe de trigraphes, puis comment clore cette classe de trigraphes par des opérations similaires aux 2-joints et aux complémentaires de 2-joints. La clôture sera une classe de trigraphe. D’après le lemme 3.4 si la clôture a la propriété du grand biparti alors la classe de graphes des réalisations des trigraphes de la clôture aussi. En fait dans ce qui suit un k-joint avec k = 2 sera analogue à la fois à l’opération de 2-joint et à celle du complémentaire de 2-joint. Dans la section suivante nous verrons que si la classe de graphes basiques a la propriété du grand biparti, cette propriété est conservée dans la clôture par kjoints. Il est important de remarquer que prendre la clôture des graphes basiques du théorème de décomposition des graphes de Berge par k-joints avec k = 2 ne donne pas exactement la classe des trigraphes de Berge apprivoisés (en particulier les trigraphes de la clôture ne sont pas tous de Berge). De plus les constantes obtenues pour les k-joints sont moins bonnes que celles obtenue pour les trigraphes de Berge apprivoisés. Soit C une classe de graphes qui doit être vue comme une classe “basique” de graphes. Pour tout entier k ≥ 1, on construit la classe de trigraphes C ≤k de la manière suivante : un trigraphe T appartient à C ≤k si et seulement s’il existe une partition X1, . . . , Xr de V (T) telle que : — pour tout 1 ≤ i ≤ r, 1 ≤ |Xi | ≤ k. — pour tout 1 ≤ i ≤ r,  Xi 2  ⊆ E ∗ (T). — pour tout 1 ≤ i 6= j ≤ r, Xi × Xj ∩ E ∗ (T) = ∅. — il existe un graphe G dans C tel que G est une réalisation de T. En d’autre termes, on part du graphe G de C, on partitionne ses sommets en petites parties (de taille au plus k), et on change toutes les adjacences à l’intérieur de ces parties en arêtes optionnelles. On définit alors le k-joint généralisé entre deux trigraphes T1 et T2, qui géné- 443.3. GRAND BIPARTI DANS LES CLASSES CLOSES PAR K-JOINTS ralise le 2-joint et qui est similaire au H-joint [6]. Soit T1 et T2 deux trigraphes vérifiant les propriétés suivantes avec 1 ≤ r, s ≤ k : — V (T1) est partitionné en (A1, . . . , Ar, B = {b1, . . . , bs}) et Aj 6= ∅ pour tout 1 ≤ j ≤ r. — V (T2) est partitionné en (B1, . . . , Bs, A = {a1, . . . , ar}) et Bi 6= ∅ pour tout 1 ≤ i ≤ s. —  B 2  ⊆ E ∗ (T1) et  A 2  ⊆ E ∗ (T2), ce qui veut dire que A et B contiennent uniquement des arêtes optionnelles. — Pour tout 1 ≤ i ≤ s, 1 ≤ j ≤ r, bi et aj sont ou bien fortement complets, ou bien fortement anticomplets à respectivement Aj et Bi . En d’autre terme, il existe un graphe biparti qui décrit les adjacences entre B et (A1, . . . , Ar), et le même graphe biparti décrit les adjacences entre (B1, . . . , Bs) et A. Alors le k-joint généralisé de T1 et T2 est le trigraphe T ou V (T) = A1 ∪ . . . ∪ Ar ∪ B1 ∪ . . . ∪ Bs. Soit θ1 et θ2 les fonctions d’adjacences de respectivement T1 et T2. Autant que possible la fonction d’adjacence θ de T étend θ1 et θ2 (c’est à dire θ(uv) = θ1(uv) pour uv ∈  V (T1)∩V (T) 2  et θ(uv) = θ2(uv) pour uv ∈  V (T2)∩V (T) 2  ), et pour a ∈ Aj , b ∈ Bi , θ(ab) = 1 si bi et Aj sont fortement complets dans T1 (ou de manière équivalente, si aj et Bi) sont fortement complets dans T2), et −1 sinon. On définit finalement C ≤k comme la plus petite classe contenant C ≤k et close par k-joints généralisés. 3.3 Grand biparti dans les classes closes par kjoints En fait la méthode de contraction des 2-joints utilisée dans la section précédente peut être généralisée aux k-joints. Nous avons seulement besoin que la classe C des graphes basiques soit close par sous-graphes induits pour avoir le résultat sur C ≤k . Nous obtenons le résultat suivant : Théorème 3.10. Soit k ∈ N\{0}, 0 < c < 1/2 et C une classe de graphes telle que pour tout G ∈ C et pour toute fonction de poids w : V (G) → N \ {0} telle que w(v) < cn˙ pour tout v ∈ V (G), G a la c-propriété du grand biparti. Alors tout trigraphe T de C ≤k , avec au moins k/c sommets, a la (c/k)-propriété du grand biparti. Pour démontrer ce théorème, nous définissons la contraction d’un k-joint géné- ralisé. Paradoxalement cette contraction est plus simple que dans le cas du 2-joint 45CHAPITRE 3. PROPRIÉTÉ DU GRAND BIPARTI car il n’y a ni poids ni étiquette sur les arêtes optionnelles : soit T un trigraphe avec une fonction de poids w : V (T) → N\{0} et supposons que T est le k-joint généralisé de T1 et de T2. Nous suivons les notations introduites dans la définition des kjoints généralisés. En particulier, V (T) est partitionné en (A1, . . . , Ar, B1, . . . , Bs). Quitte à échanger T1 et T2, supposons que w(∪ r j=1Aj ) ≥ w(∪ s i=1Bi). Alors la contraction de T est le trigraphe T 0 = T1 avec les poids w 0 définis par w 0 (v) = w(v) si v ∈ ∪r j=1Aj , et w 0 (bi) = w(Bi) pour 1 ≤ i ≤ s. On note cette opération de contraction par (T, w) ❀ (T 0 , w0 ). Remarquons que le lemme 3.5 est toujours vrai dans ce contexte, et nous obtenons le lemme suivant : Lemme 3.11. Soit 0 < c < 1/(2k). Soit (T, w) un trigraphe pondéré de C ≤k tel que w(v) < cn˙ pour tout v ∈ V (T). Ou bien T a la c-propriété du grand biparti, ou bien il existe un trigraphe T 0 ∈ C≤k de poids w 0 tel que (T, w) ❀∗ (T 0 , w0 ) et pour tout v ∈ V (T 0 ), w(v) < cn˙ . Démonstration. La démonstration est similaire au lemme 3.6. On prouve le résultat par induction sur T. Avec les notations précédentes, T se partitionne en V (T) = A1 ∪ . . . ∪ Ar ∪ B1 ∪ . . . ∪ Bs Par symétrie, supposons que w(∪Aj ) ≥ w(∪Bi) et donc w(∪Aj ) ≥ n/2. Par définition de X1, max(w(Aj )) ≥ n/(2k) ≥ cn˙ . Donc si max(w(Bj )) ≥ cn˙ , on a la c-propriété du grand biparti. Sinon, (T, w) ❀ (T 0 , w0 ) avec w 0 (x) < cn˙ pour tout x ∈ V (T 0 )∪ E ∗ (T 0 ) et T 0 ∈ C ≤k par construction de la classe. On peut donc appliquer l’hypothèse d’induction et ; ou bien trouver un trigraphe basique T 00, tel que (T, w) ❀ (T 0 , w0 ) ❀∗ (T 00, w00) et w 00(x) < cn˙ pour tout x ∈ V (T 00) ∪ E ∗ (T 00); ou bien T 0 a la c-propriété du grand biparti, et donc T aussi d’après le lemme 3.5. Démonstration du Théorème 3.10. Soit T un trigraphe de C ≤k . On définit les poids w(v) = 1 pour tout v ∈ V (T). En appliquant le lemme 3.11 on a, ou bien la (c/k) propriété du grand biparti, ou bien il existe un trigraphe T 0 ∈ C≤k tel que (T, w) ❀∗ (T 0 , w0 ) et w 0 (v) < (c/k).n pour tout v ∈ V (T 0 ). Pour chaque composante optionnelle de T 0 , on choisit le sommet de plus grand poids et on supprime les autres. On obtient un graphe G ∈ C et on définit w 00(v) = w 0 (v) sur ses sommets. Remarquons que w 00(V (G)) ≥ w 0 (V (T 0 ))/k puisque toute composante optionnelle a taille au moins k, et pour tout v ∈ V (G), w 00(v) < (c/k).w0 (V (T 0 )) ≤ cw˙ 00(V (G)). Alors il existe V1, V2 ⊆ V (G) tels que w 00(V1), w00(V2) ≥ cw˙ 00(V (G)) et V1 est ou bien fortement complet ou bien fortement anticomplet à V2. Alors w 0 (V1), w0 (V2) ≥ (c/k).w0 (V (T 0 )) et V1 est ou bien fortement complet ou bien fortement anticomplet 463.3. GRAND BIPARTI DANS LES CLASSES CLOSES PAR K-JOINTS à V2 dans T 0 . Donc T 0 a la (c/k)-propriété du grand biparti. On conclut alors à l’existence d’une paire d’ensembles témoins de la propriété du grand biparti dans T avec le lemme 3.5. Les résultats de ce chapitre ne sont pas spécifiques aux trigraphes de Berge apprivoisés. En effet la partie la plus technique est la démonstration du cas basique (lemme 3.8). La partie induction, c’est à dire, la construction par joint est finalement assez simple. En fait, si le joint est équilibré, il est normal que l’on ait la propriété du grand biparti entre les deux côtés du joint. Cependant comme les graphes de Berge n’ont pas tous cette propriété, c’est une autre manière de voir que notre classe est une sous-classe stricte des graphes de Berge. 47CHAPITRE 3. PROPRIÉTÉ DU GRAND BIPARTI 48Chapitre 4 Clique-Stable séparateur Les résultats de ce chapitre ont été obtenus avec Aurélie Lagoutte, ils font l’objet d’un article [26] soumis à Discrete Mathematics. Une propriété très proche de la propriété du grand biparti est celle de la cliquestable séparation. Commençons par définir ce qu’est un clique-stable séparateur. Soit G un graphe, on dit qu’une partition en deux ensembles C = (U, V ) du graphe G est une coupe. Un ensemble de coupes est un clique-stable séparateur de G si pour toute clique K et tout stable S de G tels que K ∩ S = ∅ il existe une coupe C = (U, V ) du graphe G telle que K ⊆ U et S ⊆ V . Bien entendu, pour tout graphe G il existe toujours un clique-stable séparateur. La question intéressante est de savoir s’il existe un clique-stable séparateur contenant un nombre polynomial de coupes. On dit donc qu’une classe C graphes a la propriété de la clique-stable séparation s’il existe un polynôme P tel que pour tout graphe G ∈ C d’ordre n, G admette un clique-stable séparateur de taille P(n). Dans ce chapitre nous allons montrer que les graphes de Berge apprivoisés admettent un clique-stable séparateur de taille O(n 2 ). Nous généraliserons ce résultat aux classes de trigraphes construites par k-joints généralisés comme défini dans le chapitre 3. La propriété de la clique-stable séparation a été introduite par Yannakakis [38] dans les années 90 lorsqu’il étudiait le problème de l’existence d’une formulation étendue pour le polytope des stables (l’enveloppe convexe des fonctions caracté- ristiques de ses stables). C’est à dire un polytope plus simple en dimension plus grande mais tel que sa projection soit le polytope des stables. Il s’est intéressé à 49CHAPITRE 4. CLIQUE-STABLE SÉPARATEUR ce problème sur les graphes parfaits car ces graphes ont des propriétés permettant de définir plus simplement ce polytope. Cela l’a amené à définir un problème de communication qui est équivalent à celui de la clique-stable séparation. De fait l’existence d’un clique-stable séparateur de taille polynomial est une condition né- cessaire à l’existence d’une formulation étendue. Il a pu démontrer l’existence à la fois d’un clique-stable séparateur de taille polynomiale et d’une formulation étendue pour de nombreuses sous-classes de graphes parfaits comme par exemple, les graphes de comparabilité, les graphes triangulés (chordal graph c’est-à-dire les graphes sans C4 induit), et les compléments de ces classes. Lovász à également démontré ces propriétés pour les graphes t-parfaits [30]. Cependant ces deux problèmes restent ouverts pour les graphes parfaits en général. L’existence d’une formulation étendue n’étant pas toujours vraie pour les graphes [20], il est donc d’autant plus intéressant de voir si ces propriétés sont vérifiées pour les graphes parfaits. Remarquons bien que contrairement à la propriété du grand biparti qui n’est pas vérifiée pour les graphes de comparabilité, la propriété de la clique-stable séparation est vraie sur cette classe. Les graphes de comparabilité sont une classe de graphes parfaits assez bien comprise dans laquelle presque tous les graphes ont de nombreuses skew-partitions équilibrées, de ce point de vue c’est une classe bien étudiée de graphes de Berge non apprivoisés. Peut-être est-il donc possible d’utiliser la décomposition du théorème fort des graphes parfaits pour démontrer l’existence de clique-stable séparateur de taille polynomiale pour les graphes parfaits. Commençons par voir comment la propriété de la clique-stable séparation et la propriété du grand biparti sont liées. Dans le cas des classes de graphes héréditaires, la propriété du grand biparti implique celle de la clique-stable séparation. Comme le montre le théorème suivant (la démonstration est la même que celle de Bousquet, Lagoutte et Thomassé dans [4] qui à partir de la propriété du grand biparti prouvé dans [5] montre que les graphes sans chemin induit ni complémentaire de chemin induit de taille k ont la propriété de la clique-stable séparation) Lemme 4.1. Soit C une classe de graphes héréditaire ayant la c-propriété du grand biparti, alors C a la propriété de la clique-stable séparation. Démonstration. Le but est de démontrer que tout graphe G dans C admet un clique-stable séparateur de taille n cs avec cs = −1 log2(1−c) (pour rappel, c-est la constante de la propriété du grand biparti). Raisonnons par l’absurde et prenons G un contre-exemple minimal. Notons n = |V (G)|, comme G a la c-propriété du grand biparti, il existe deux sous-ensembles de sommets disjoints V1, V2 vérifiant, |V1| ≥ cn˙ , |V2| ≥ cn˙ et V1 est ou bien complet à V2 ou bien anticomplet à V2. 504.1. CLIQUE-STABLE SÉPARATEUR DANS LES TRIGRAPHES DE BERGE APPRIVOISÉS Notons V3 = V (G) \ (V1 ∪ V2). Par minimalité de G, G|(V1 ∪ V3) admet un cliquestable séparateur F1 de taille (|V1| + |V3|) cs et G|(V2 ∪ V3) admet un clique-stable séparateur F2 de taille (|V2| + |V3|) cs. Construisons F un clique stable séparateur de G. Nous devons distinguer deux cas suivant les adjacences entre V1 et V2. L’idée est de prendre chaque coupe de F1 et F2 et de la transformer en une coupe de G en ajoutant les sommets de V2 ou V1 du “bon” côté de la coupe suivant les adjacences entre V1 et V2. Formellement si V1 est complet à V2, F = {(U ∪ V2, W); (U, W) ∈ F1} ∪ {(U ∪ V1, W); (U, W) ∈ F2}. Si au contraire, V1 est anticomplet à V2, F = {(U, W ∪ V2); (U, W) ∈ F1} ∪ {(U, W ∪ V1); (U, W) ∈ F2}. Il est facile de voir que F est un clique-stable séparateur de G. En effet suivant les adjacences entre V1 et V2 une clique ou un stable de G ne peut pas intersecter à la fois V1 et V2. Pour toute clique K et stable S ne s’intersectant pas, il existe donc une coupe dans F qui les sépare. Enfin F a taille au plus 2((1 − c)n) cs ≤ n cn . Ce résultat ne règle pas vraiment le problème pour les graphes de Berge apprivoisés. En effet la classe des graphes de Berge apprivoisés n’est pas héréditaire (la suppression de sommet peut créer des skew-partitions). D’autre part, avec la constante obtenue dans le théorème 3.3 on obtiendrait un clique-stable séparateur de taille O(n 101) ce qui, étant donné que nous pouvons montrer qu’il existe un clique-stable séparateur de taille quadratique, est assez mauvais. 4.1 Clique-stable séparateur dans les trigraphes de Berge apprivoisés Comme dans le chapitre précédent, nous allons utiliser le théorème de décomposition et les blocs du chapitre 2. Nous devons donc étendre notre problème aux trigraphes. Le résultat principal sera le théorème 4.5 prouvant l’existence de cliquestable séparateur de taille quadratique pour les trigraphes de Berge apprivoisés. Commençons par définir les notions de clique-stable séparation dans les trigraphes. Soit T un trigraphe. Une coupe de T est une paire (U, W) ⊆ V (T) 2 , telle que U ∪W = V (T) et U ∩W = ∅. Elle sépare une clique K d’un stable S, si H ⊆ U et S ⊆ W. Parfois on dit que U est la partie clique de la coupe et W la partie stable de la coupe. Remarquons qu’une clique et un stable ne peuvent être séparés que s’ils ne s’intersectent pas. Remarquons également qu’ils ne peuvent s’intersecter que sur une composante optionnelle V (pour rappel pour tout u, v ∈ V , u = v ou uv ∈ E ∗ (T)). En particulier, si T est un trigraphe bigame, une clique et un 51CHAPITRE 4. CLIQUE-STABLE SÉPARATEUR stable s’intersectent sur au plus un sommet ou une arête optionnelle. On dit que la famille F de coupes est un clique-stable séparateur, si pour toute clique K et tout stable S qui ne s’intersectent pas, il existe une coupe dans F qui sépare K et S. Étant donnée une classe C de trigraphes, nous nous intéressons à la question suivante : existe-t-il une constante c, telle que pour tout trigraphe T de C, T admet un clique-stable séparateur de taille O(n c ) ? Supposons qu’il existe un clique-stable séparateur de taille m de T, alors on construit un clique-stable séparateur de taille m de T en construisant pour chaque coupe (U, W) la coupe (W, U). Le problème est donc bien auto-complémentaire. Montrons également qu’il est suffisant de considérer uniquement les cliques et les stables maximaux. Lemme 4.2. Si un trigraphe T bigame admet une famille F de coupes qui sépare toutes les cliques maximales (pour l’inclusion) de tous les stables maximaux, alors T admet un clique-stable séparateur de taille au plus |F| + O(n 2 ). Démonstration. Pour tout x ∈ V , prenons Cut1,x la coupe N[x], V \N[x] et Cut2,x la coupe (N(x), V \ N(x)). Pour toute arête optionnelle xy, prenons Cut1,xy (resp. Cut2,xy, Cut3,xy, Cut4,xy) la coupe (U = N[x] ∪ N[y], V \ U) (resp. (U = N[x] ∪ N(y), V \ U), (U = N(x) ∪ N[y], V \ U), (U = N(x) ∪ N(y), V \ U)). Soit F 0 l’union de F avec toutes les coupes que nous venons de définir pour tout x ∈ V , et xy ∈ E ∗ (T). Nous allons démontrer que F 0 est un clique-stable séparateur. Soit (K, S) une paire d’une clique et d’un stable qui ne s’intersectent pas. Étendons K et S en ajoutant des sommets jusqu’à avoir une clique maximale K0 et un stable maximal S 0 . Nous devons traiter trois cas. Ou bien K0 et S 0 ne s’intersectent pas, dans ce cas il y a une coupe de F qui sépare K0 de S 0 (et donc K et S). Ou bien K0 et S 0 s’intersectent sur un sommet x, dans ce cas si x ∈ K, alors Cut1,x sépare K de S, sinon Cut2,x les sépare. Ou bien K0 et S 0 s’intersectent sur une arête optionnelle xy (en effet une clique et un stable ne peuvent s’intersecter que sur au plus un sommet ou une arête optionnelle). Dans ce cas, par le même argument que pour le cas précédent, suivant l’intersection entre {x, y} et K0 une des coupes Cut1,xy,. . ., Cut4,xy sépare la clique K du stable S. En particulier, si T a au plus O(n c ) cliques maximales (ou stables maximaux) pour une constante c ≥ 2, alors il existe un clique-stable séparateur de taille O(n c ). (Il suffit de séparer toutes les cliques maximales puis d’appliquer le lemme précédent). 524.1. CLIQUE-STABLE SÉPARATEUR DANS LES TRIGRAPHES DE BERGE APPRIVOISÉS Nous prouvons maintenant que les trigraphes de Berge apprivoisés admettent un clique-stable séparateur de taille quadratique. Commençons par traiter le cas des trigraphes basiques. Lemme 4.3. Il existe une constante c, telle que tout trigraphe basique admet un clique-stable séparateur de taille cn˙ 2 . Démonstration. Puisque le problème est auto-complémentaire, nous traitons uniquement le cas des trigraphes bipartis, des line trigraphes et des trigraphes doublés. Une clique dans un trigraphe biparti est une arête forte, une arête optionnelle ou un sommet, il y a donc un nombre quadratique de cliques. Si T est un line trigraphe, alors sa réalisation complète est le line graphe d’un graphe biparti G et donc T a au plus un nombre linéaire de cliques car chaque clique correspond à un sommet de G. Grâce au lemme 4.2, les line trigraphes admettent un clique-stable séparateur de taille quadratique. Si T est un trigraphe doublé, alors soit (X, Y ) une bonne partition de T. Ajoutons à la coupe (Y, X) les coupes suivantes : pour tout Z = {x} avec x ∈ X ou Z = ∅, et pour tout Z 0 = {y} avec y ∈ Y ou Z 0 = ∅, prenons la coupe (Y ∪ Z \ Z 0 , X ∪ Z 0 \ Z) et pour toute paire x, y ∈ V , prenons la coupe ({x, y}, V \ {x, y}), et (V \ {x, y}, {x, y}). Ces coupes forment un clique-stable séparateur : soit K une clique et S un stable de T qui ne s’intersectent pas, alors |K ∩ X| ≤ 2 et |S ∩ Y | ≤ 2. Si |K ∩ X| = 2 (resp. |S ∩ Y |=2) alors K (resp. S) est seulement une arête (resp. une antiarête), car par définition, les sommets de K ∩ X n’ont pas de voisin commun avec Y . Donc la coupe (K, V \ K) (resp. V \ S, S) sépare K et S. Sinon, |K∩X| ≤ 1 et |S∩Y | ≤ 1 et alors (Y ∪(K∩X)\(S∩Y ), X∪(S∩Y )\(K∩X)) sépare K et S. Nous pouvons maintenant traiter le cas des 2-joints dans les trigraphes et montrer comment reconstruire un clique-stable séparateur à partir des clique-stable séparateurs des blocs de décompositions. Lemme 4.4. Soit T un trigraphe qui admet un 2-joint propre (X1, X2). Si les blocs de décomposition TX1 et TX2 admettent des clique-stable séparateurs de taille respectivement k1 et k2, alors T admet un clique-stable séparateur de taille k1 + k2. Démonstration. Soit (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2), TXi (i = 1, 2) les blocs de décomposition avec les sommets marqués ai , bi et potentiellement 53CHAPITRE 4. CLIQUE-STABLE SÉPARATEUR ci suivant la parité du 2-joint. Remarquons que nous n’avons pas besoin de distinguer le cas du 2-joint pair de celui du 2-joint impair car ci ne joue aucun rôle. Soit F1 un clique-stable séparateur de TX1 de taille k1 et F2 un clique-stable séparateur de TX2 de taille k2. Construisons F un clique-stable séparateur de T. Pour chaque coupe (U, W) ∈ F1, construisons la coupe ((U ∩ X1) ∪ U 0 ,(W ∩ X1) ∪ W0 ∪ C2) avec U 0 ∪ W0 = A2 ∪ B2 et A2 ⊆ U 0 (resp. B2 ⊆ U 0 ) si a2 ∈ U (resp. b2 ∈ U), et A2 ⊆ W0 (resp. B2 ⊆ W0 ) sinon. En d’autres termes, A2 va du même côté de la coupe que a2, B2 va du même côté que b2 et C2 va toujours du côté du stable. Pour chaque coupe dans F2, nous faisons la même construction : A1 va du côté de a1, B1 va du côté de b1 et C1 va du côté du stable. Montrons maintenant que F est bien un clique-stable séparateur : soit K une clique et S un stable tels que K et S ne s’intersectent pas. Commençons par supposer que K ⊆ X1. Soit S 0 = (S ∩ X1) ∪ Sa2,b2 avec Sa1,b2 ⊆ {a2, b2} contient a2 (resp. b2) si et seulement si S intersecte A2 (resp. B2). S 0 est un stable de TX1 , donc il y a une coupe de F1 qui sépare K de S 0 . La coupe correspondante dans F sépare (K, S). Le cas K ⊆ X2 se traite de la même manière. Supposons alors que K intersecte à la fois X1 et X2. Alors K ∩ C1 = ∅ et K ⊆ A1 ∪ A2 ou K ⊆ B1 ∪ B2. Supposons sans perte de généralité que K ⊆ A1∪A2. Remarquons que S ne peut intersecter à la fois A1 et A2 qui sont fortement adjacent. Supposons donc que S n’intersecte pas A2. Soit K0 = (K ∩ A1) ∪ {a2} et S 0 = (S ∩ X1) ∪ Sb2 avec Sb2 = {b2}, si S intersecte B2, et Sb2 = ∅ sinon. K0 est une clique et S 0 est un stable de TX1 , donc il existe une coupe dans F1 qui les sépare. La coupe correspondante dans F sépare bien K de S, et donc F est bien un clique-stable séparateur. Nous pouvons maintenant démontrer le théorème principal de cette section : Théorème 4.5. Tout trigraphe de Berge apprivoisé admet un clique-stable séparateur de taille O(n 2 ). Démonstration. Soit c 0 la constante du lemme 4.3 et c = max(c 0 , 2 24). Nous allons démontrer par induction que tout trigraphe de T admet un clique-stable séparateur de taille cn˙ 2 . Nous avons deux cas de base, celui des trigraphes basiques, traités par le lemme 4.3 qui donne un clique-stable séparateur de taille c 0n 2 , et celui des petits trigraphes, c’est à dire celui des trigraphes d’ordre inférieur à 24. Pour ces trigraphes on peut simplement prendre tous les sous-ensembles de sommet U et prendre les coupes (U, V \ U) qui forment trivialement un clique-stable séparateur de taille au plus 2 24n 2 . 544.2. CLIQUE-STABLE SÉPARATEUR DANS LES CLASSES CLOSES PAR K-JOINTS Par conséquent, nous pouvons maintenant supposer que le trigraphe T n’est pas basique et a au moins 25 sommets. D’après le théorème 2.10, T admet un 2-joint propre (X1, X2) (ou le complément d’un 2-joint propre, mais dans ce cas comme le problème est auto-complémentaire, donc pouvons le résoudre sur T). Soit n1 = |X1|, d’après le lemme 2.9 nous pouvons supposer que 4 ≤ n1 ≤ n − 4. D’après le théorème 2.11, nous pouvons appliquer l’hypothèse d’induction sur les blocs de décomposition TX1 et TX2 afin d’obtenir un clique-stable séparateur de taille respectivement au plus k1 = c(n1 + 3)2 et k2 = c(n − n1 + 3)2 . D’après le lemme 4.4, T admet un clique-stable séparateur de taille k1 + k2. Prouvons maintenant que k1 + k2 ≤ cn˙ 2 . Soit P(n1) = c(n1 + 3)2 + c(n − n1 + 3)2 − cn˙ 2 . P est un polynôme de degré 2 de coefficient dominant 2c > 0. De plus P(4) = P(n − 4) = −2c(n − 25) ≤ 0 donc par convexité de P, P(n1) ≤ 0 pour tout 4 ≤ n1 ≤ n − 4, ce qui termine la démonstration. 4.2 Clique-stable séparateur dans les classes closes par k-joints Comme dans le chapitre 3 voyons maintenant comment étendre le résultat sur l’existence de clique-stable séparateurs de taille polynomial dans les classes de trigraphes closes par k-joints généralisés. Nous rappelons que nous partons d’une classe de graphes C héréditaire ayant la propriété de la clique stable séparation. Nous allons alors construire une classe de trigraphes C ≤k à partir de ces graphes, puis nous prenons la clôture C ≤k de cette classe par k-joints généralisés. Nous rappelons que toutes les définitions sont dans la section 3.2 du chapitre 3. Les remarques du chapitre précédent restent vraies : même si le théorème 2.10 montre que dans un certain sens les trigraphes de Berge apprivoisés sont la clô- ture par 2-joints et complémentaire de 2-joints des trigraphes basiques, prendre la clôture par k-joints généralisés des trigraphes basiques avec k = 2 ne donne pas la classe des trigraphes de Berge apprivoisés. En effet certains graphes de cette clôture ont des skew-partitions équilibrées. De plus les constantes obtenues dans le cas des k-joints généralisés sont moins bonnes que celles obtenues directement sur les trigraphes de Berge apprivoisés. Dans un premier temps montrons que la transformation des graphes en trigraphes (de la classe C à la classe C ≤k ), préserve la propriété de la clique-stable séparation. L’explosion de la taille du clique-stable séparateur est due au fait que 55CHAPITRE 4. CLIQUE-STABLE SÉPARATEUR dans un trigraphe T, une clique (et de même pour un stable) contenant k arêtes optionnelles devient une union d’au plus k cliques dans les réalisations de T. Lemme 4.6. Si chaque graphe G de C admet un clique-stable séparateur de taille m, alors chaque trigraphe T de C ≤k admet un clique-stable séparateur de taille mk 2 . Démonstration. Commençons par démontrer que s’il existe un clique-stable séparateur F de taille m alors F 0 = {(∩ k i=1Ui , ∪ k i=1Wi)|(U1, W1). . .(Uk, Wk) ∈ F} est une famille de coupes de taille mk qui sépare chaque clique de chaque union d’au plus k stables. En effet, si K est une clique et S1 . . . Sk sont k stables, tels qu’ils n’intersectent pas K, alors il existe dans F k partitions (U1, W1). . .(Uk, Wk) telles que (Ui , Wi) sépare K et Si . Maintenant (∩ k i=1Ui , ∪ k i=1Wi) est une partition qui sépare K de ∪ k i=1Si . Avec le même argument, on peut construire une famille F 00 de coupes de taille mk 2 qui sépare chaque union d’au plus k cliques d’union d’au plus k stables. Maintenant soit T un trigraphe de C ≤k et soit G ∈ C, tel que G est une réalisation de T. Remarquons qu’une clique K (resp. un stable S) dans T est une union d’au plus k cliques (resp. stables) dans G. Par exemple on peut voir que Σ(T) ∩ K (resp. Σ(T) ∩ S) est k-coloriable et chaque classe de couleur correspond à une clique (resp. un stable) dans G. Alors il existe un clique-stable séparateur de T de taille mk 2 . Nous pouvons maintenant montrer que le k-joint généralisé de deux trigraphes préserve la propriété de clique-stable séparation. En fait vu la structure assez forte du k-joint généralisé, les cliques traversantes (qui ont des sommets des deux côtés du k-joint généralisé) sont très contraintes. On peut donc presque prendre l’union des clique-stable séparateurs des deux trigraphes dont on est en train de prendre le k-joint généralisé. Lemme 4.7. Si T1 et T2 ∈ C ≤k admettent des clique-stable séparateurs de taille respectivement m1 et m2, alors le k-joint généralisé T de T1 et T2 admet un clique-stable séparateur de taille m1 + m2. Démonstration. La preuve est similaire à celle faite pour le lemme 4.4. On suit les notations introduites dans les définitions du k-joint généralisé. Soit F1 (resp, F2) un clique-stable séparateur de taille m1 (resp. m2) sur T1 (resp. T2). Construisons F un clique-stable séparateur de T. Pour chaque coupe (U, W) dans F1, construisons la coupe (U 0 , W0 ) suivant ces deux règles : pour tout a ∈ ∪r j=0Aj (resp. b ∈ Bi), 564.2. CLIQUE-STABLE SÉPARATEUR DANS LES CLASSES CLOSES PAR K-JOINTS a ∈ U 0 (resp. b ∈ U 0 ) si et seulement si a ∈ U (resp. bi ∈ U). En d’autres termes, on prend une coupe similaire à (U, W) en mettant Bi du même côté que bi . On fait l’opération symétrique pour chaque coupe (U, W) dans F2 en mettant Aj du même côté que aj . F est bien un clique-stable séparateur : soit K une clique et S un stable qui ne s’intersectent pas. Supposons pour commencer qu’un côté de la partition (A1, . . . , Ar, B1, . . . , Bs) intersecte à la fois K et S. Quitte à échanger T1 et T2 et à renuméroter les Aj , on peut supposer que A1 ∩ K 6= ∅ et A1 ∩ S 6= ∅. Puisque pour tout i, A1 est ou bien fortement complet ou bien fortement anticomplet à Bi , Bi ne peut intersecter à la fois K et S. Considérons dans T1 la paire (K0 = (K ∩ V (T)) ∪ Kb, S0 = (S ∩ V (T)) ∪ Sb) avec Kb = {bi |K ∩ Bi 6= ∅} et Sb = {bi |S ∩ Bi 6= ∅}. K0 est une clique dans T1, S 0 est un stable dans T1. Comme ils ne s’intersectent pas, il y a une coupe les séparant dans F1. La coupe correspondante dans F sépare K et S. L’autre cas est celui ou aucune partie de la partition n’intersecte à la fois K et S. Alors pour tout i, Bi n’intersectent pas non plus à la fois la clique K et le stable S : le même argument que ci-dessus s’applique encore. Nous pouvons maintenant démontrer le théorème principal de cette section. Théorème 4.8. Si tout graphe de C admet un clique-stable séparateur de taille O(n c ), alors tout trigraphe de C ≤k admet un clique-stable séparateur de taille O(n k 2 c ). En particulier, toute réalisation d’un trigraphe de C ≤k admet un clique-stable séparateur de taille O(n k 2 c ). Démonstration. On prouve par induction qu’il existe un clique-stable séparateur de taille pnk 2 c avec p = max(p 0 , 2 p0 ) où p 0 est la constante du O de la taille du clique-stable séparateur des graphes de C et p0 est une constante définie dans la suite. Le cas de base comporte deux cas : les trigraphes de C ≤k , pour lesquels la propriété est vérifiée d’après le lemme 4.6 et les trigraphes d’ordre au plus p0. Pour ces derniers, on peut considérer tous les sous-ensembles U de sommets et prendre les coupes (U, V \ U) qui forment un clique-stable séparateur trivial de taille au plus 2 p0 n k 2 c . Par conséquent, on peut supposer que T est le k-joint généralisé de T1 et T2 et qu’il a au moins p0 sommets. Soit n1 = |T1| et n2 = |T2| avec n1 + n2 = n + r + s et r + s + 1 ≤ n1, n2, ≤ n − 1. Par induction, il existe un clique-stable séparateur de taille pnk 2 c 1 sur T1 et un de taille pnk 2 c 2 sur T2. D’après le lemme 4.7, il existe 57CHAPITRE 4. CLIQUE-STABLE SÉPARATEUR un clique-stable séparateur sur T de taille pnk 2 c 1 + pnk 2 c 2 . On veut démontrer que pnk 2 c 1 + pnk 2 c 2 ≤ pnk 2 c . Remarquons que n1+n2 = n−1+r+s+1 donc par convexité de x 7→ x c sur R +, n k 2 c 1 +n k 2 c 2 ≤ (n−1)k 2 c+ (r+s+1)k 2 c . De plus, r+s+1 ≤ 2k+1. Définissons alors p0 suffisamment grand pour que pour tout n ≥ p0, n k 2 c − (n − 1)k 2 c ≥ (2k + 1)k 2 c . Alors n k 2 c 1 + n k 2 c 2 ≤ n k 2 c , ce qui conclut la démonstration. Dans ce chapitre également les résultats sortent du cadre des graphes de Berge apprivoisés pour s’étendre aux graphes clos par k-joint. Le point clé est de remarquer que les cliques ne peuvent pas vraiment traverser un k-joint. Le seul cas possible de traversée est entre deux ensembles complets du k-joint, mais dans ce cas comme les ensembles sont complets, le stable ne peut pas lui aussi intersecter ces deux ensembles. 58Chapitre 5 Calcul du stable maximum Les résultats de ce chapitre ont été obtenus avec Maria Chudnovsky, Nicolas Trotignon et Kristina Vušković, ils font l’objet d’un article [15] soumis à Journal of Combinatorial Theory, Series B. Nous allons dans ce chapitre montrer comment calculer en temps polynomial la taille du stable maximum dans les graphes de Berge apprivoisés. En toute rigueur ce problème est déjà résolu dans les graphes parfaits et donc a fortiori dans les graphes de Berge apprivoisés. Cependant la démonstration, due à Grötschel, Lovász et Schrijver [33] n’utilise pas du tout la structure (au sens du théorème de décomposition) des graphes parfaits (qui lui est postérieur) mais utilise principalement l’égalité entre les nombre chromatique χ et la taille d’une clique maximumω. En effet Lovász [29] introduit une quantité ϑ, résultat d’un problème d’optimisation convexe. Dans les graphes cette quantité vérifie l’inégalité α ≤ ϑ ≤ χ (χ est la taille d’une couverture par clique minimale). Dans les graphes parfaits, ϑ est donc égal à α la taille maximum d’un stable. Grâce à la méthode de l’ellipsoïde inventée par Grötschel, Lovász et Schrijver [23], il est alors possible de calculer α en temps polynomial. L’intérêt de notre résultat est qu’il est complétement combinatoire. À partir de ce résultat il est possible de colorier les graphes de Berge apprivoisés avec un surcout de O(n 2 ) en utilisant la démonstration classique de Grötschel, Lovász et Schrijver [33]. Comme dans les chapitres précédents nous allons décomposer le graphe grâce au théorème 2.10, et faire une induction. Malheureusement contrairement aux chapitres précédents notre méthode n’est pas générale vis à vis des 2-joints et donc ne se généralise pas aux classes closes par k-joints généralisées. 59CHAPITRE 5. CALCUL DU STABLE MAXIMUM En effet la structure des stables dépend de la parité du 2-joint (voir surtout le lemme 5.3 et le lemme 5.4). Afin de pouvoir faire l’induction nous avons besoin de travailler avec des trigraphes pondérés. Donc dans la suite de ce chapitre, le terme “trigraphe” signifie un trigraphe avec des poids sur ses sommets. Les poids sont des nombres de K avec K ou bien l’ensemble R+ des réels strictement positifs ou bien N+ l’ensemble des entiers strictement positifs. Les théorèmes sont vrais pour K = R+ mais les algorithmes sont implémentés avec K = N+. On voit un trigraphe sans poids sur ses sommets comme un trigraphe pondéré avec tous ses poids égaux à 1. Remarquons qu’un ensemble de sommets dans un trigraphe T est un stable fort, si et seulement si c’est un stable dans la réalisation complète de T. 5.1 Le cas des trigraphes basiques Commençons par montrer que nous pouvons reconnaître les classes basiques et calculer un stable pondéré maximum dans ces classes. Théorème 5.1. Il existe un algorithme en temps O(n 4 ) dont l’entrée est un trigraphe et dont la sortie est ou bien “T n’est pas basique”, ou bien le nom de la classe de base de T et le poids maximum d’un stable fort de T. Démonstration. Pour toute classe de trigraphe basique, nous fournissons un algorithme en temps O(n 4 ) qui décide si le trigraphe appartient à la classe et si c’est le cas, calcule le poids maximum d’un stable fort. Pour les trigraphes bipartis, on construit la réalisation complète G de T. Il est immédiat de voir que T est biparti si et seulement si G l’est. On peut donc reconnaitre un trigraphe biparti en temps linéaire en utilisant un parcours. Si T est biparti, un stable maximum de G est exactement un stable fort maximum de T, et on peut le calculer en temps O(n 3 ) voir [33]. Pour les compléments de trigraphes bipartis, nous procédons de manière analogue : nous commençons par prendre le complément T de notre trigraphe T, et nous reconnaissons si la réalisation complète de T est un graphe biparti. Nous calculons ensuite le poids maximum d’une clique de GT ∅ . Toutes ces opérations peuvent clairement se faire en temps O(n 2 ). Pour les line trigraphes, nous calculons la réalisation complète G et testons si G est un line graphe d’un graphe biparti par un algorithme classique comme [27] ou [32]. Notons que ces algorithmes fournissent également le graphe R tel que 605.1. LE CAS DES TRIGRAPHES BASIQUES G = L(R). En temps O(n 3 ) nous pouvons vérifier que les cliques de taille au moins 3 dans T sont bien des cliques fortes. On peut donc reconnaitre si T est un line trigraphe en temps O(n 3 ). Si c’est le cas, un stable maximum dans G peut être calculer en temps O(n 3 ) en calculant un couplage de poids maximum (voir [33]) dans le graphe biparti R tel que G = L(R). Pour les compléments de line trigraphes, nous procédons de manière similaire pour la reconnaissance en prenant la réalisation complète de T. Et le calcul du poids maximum d’un stable fort est simple : nous calculons la réalisation complète G de T, nous calculons ensuite le graphe biparti R tel que G = L(R) (il existe car d’après le lemme 2.1, les line trigraphes sont clos par réalisation) et nous calculons un stable de poids maximum de G (un tel stable est un ensemble maximal d’arête de R toutes deux à deux adjacentes, et il y a un nombre linéaire de tels ensembles). C’est alors un stable fort de poids maximum dans T. Pour les trigraphes doublés, nous ne pouvons pas utiliser de résultats classiques. Pour la reconnaissance, nous pourrions utiliser la liste des graphes non doublés minimaux décrite dans [2]. Cette liste de 44 graphes sur au plus 9 sommets donne un algorithme de reconnaissance en temps O(n 9 ). Plus récemment Maffray à donné un algorithme linéaire [31] pour la reconnaissance des graphes doublés. Malheureusement ce résultat ne semble pas se généraliser directement aux trigraphes. Nous proposons ici un algorithme en O(n 4 ) qui fonctionne également sur des trigraphes. Si une partition (X, Y ) des sommets d’un trigraphe est donné, on peut décider si c’est une bonne partition, par une génération exhaustive qui vérifie tous les points de la définition en temps O(n 2 ). Et si une arête ab de T|X est donnée, il est facile de reconstruire la bonne partition : tous les sommets fortement antiadjacents aux sommets a et b sont dans X et tous les sommets fortement adjacents à au moins a ou b sont dans Y . Donc en testant toutes les arêtes uv, on peut prédire laquelle est dans T|X, puis reconstruire (X, Y ) et donc décider en temps O(n 4 ) si le trigraphe T a une bonne partition (X, Y ), telle que X contient au moins une arête. De la même manière on peut tester si le trigraphe T a une bonne partition (X, Y ), telle que Y contient au moins une antiarête. Reste le cas de la reconnaissance des trigraphes doublés, tels que toute bonne partition est composée d’une clique forte et d’un stable fort. Dans ce cas le trigraphe est en fait un graphe, et ce type de graphe est connu comme un split graphe. Ils peuvent être reconnus en temps linéaire, voir [25] où il est prouvé qu’en regardant les degrés on peut facilement trouver une partition en clique et stable si une telle partition existe. Maintenant que nous savons reconnaitre si le trigraphe T est un trigraphe doublé, regardons comment calculer le poids maximum d’un stable fort de T. 61CHAPITRE 5. CALCUL DU STABLE MAXIMUM Calculons la réalisation complète G de T. D’après 2.2, G est un graphe doublé, et en fait (X, Y ) est une bonne partition pour G. Nous calculons alors un stable pondéré maximum dans G|X (qui est biparti), dans G|Y (dont le complément est biparti), et tous les stables formés d’un sommet de Y et de ses non-voisins dans X. Un de ces stables est de poids maximum dans G et donc est un stable fort de poids maximum dans T. 5.2 Stocker α dans les blocs Dans cette section, nous définissons plusieurs blocs de décomposition qui vont nous permettre de calculer le stable de poids maximum. Nous notons α(T) le poids maximum d’un stable fort de T. Dans la suite, T est un trigraphe de Berge apprivoisé, X est un fragment de T et Y = V (T) \ X (donc Y est aussi un fragment de T). Pour calculer α(T), il n’est pas suffisant de considérer les blocs TX et TY (comme défini dans le chapitre 2) séparément. Nous devons élargir les blocs afin d’encoder l’information de l’autre bloc. Dans cette section nous définissons quatre gadgets différents, TY,1, . . ., TY,4 et pour i = 1, . . . , 4, nous prouvons que α(T) peut être calculé à partir de α(TYi ). Nous définissons parfois plusieurs gadgets pour la même situation. En effet, dans la section 5.3 (notamment pour démontrer le lemme 5.9), nous avons besoin que nos gadgets préservent les classes de base, et suivant ces classes de base nous utilisons différents gadgets. Les gadgets que nous allons définir ne préservent pas la classe (certains introduisent des skew-partitions équilibrées). Ce n’est pas un problème dans cette section, mais il faudra y prendre garde dans la section suivante. Dans [37], un résultat de NP-complétude est prouvé, qui suggère que les 2- joints ne sont sans doute pas un outil utile pour calculer des stables maximum. En effet Trotignon et Vušković exhibent une classe de graphes C avec une théorème de décomposition du type : tout graphe de C est ou bien un line graphe, ou bien un graphe biparti ou bien admet un 2-joint. Cependant le calcul du stable maximum dans la classe C est NP=complet. Il semble donc que pour pouvoir utiliser les 2- joints, nous devons vraiment utiliser le fait que nos trigraphes sont de Berge. Ceci est fait en prouvant plusieurs inégalités. Si (X, Y ) est un 2-joint de T alors soit X1 = X, X2 = Y et soit (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Nous définissons αAC = α(T|(A1 ∪ C1)), αBC = α(T|(B1 ∪ C1)), αC = α(T|C1) et αX = α(T|X1). Soit w la fonction de poids sur V (T), w(H) est la somme des poids sur les sommets de H. 625.2. STOCKER α DANS LES BLOCS Lemme 5.2. Soit S un stable fort de poids maximum de T. Alors exactement un des points suivants est vérifié : 1. S∩A1 6= ∅, S∩B1 = ∅, S∩X1 est un stable fort maximum de T|(A1∪C1) et w(S ∩ X1) = αAC ; 2. S∩A1 = ∅, S∩B1 6= ∅, S∩X1 est un stable fort maximum de T|(B1∪C1) et w(S ∩ X1) = αBC ; 3. S ∩ A1 = ∅, S ∩ B1 = ∅, S ∩ X1 est un stable fort maximum de T|C1 et w(S ∩ X1) = αC ; 4. S ∩ A1 6= ∅, S ∩ B1 6= ∅, S ∩ X1 est un stable fort maximum de T|X1 et w(S ∩ X1) = αX. Démonstration. Directe depuis la définition d’un 2-joint. Nous avons besoin de plusieurs inégalités à propos des intersections entre les stables forts et les 2-joints. Ces lemmes sont prouvés dans [37] pour les graphes. Les démonstrations sont similaires pour les trigraphes mais comme ce sont ces inégalités qui nous permettent d’utiliser le fait que les trigraphes sont de Berge nous les incluons ici. Lemme 5.3. 0 ≤ αC ≤ αAC, αBC ≤ αX ≤ αAC + αBC. Démonstration. Les inégalités 0 ≤ αC ≤ αAC, αBC ≤ αX sont trivialement vraies. Soit D un stable fort pondéré de poids maximum de T|X1. Nous avons : αX = w(D) = w(D ∩ A1) + w(D ∩ (C1 ∪ B1)) ≤ αAC + αBC. Lemme 5.4. Si (X1, X2) est un 2-joint impair de T, alors αC + αX ≤ αAC + αBC. Démonstration. Soit D un stable fort de T|X1 de poids αX et C un stable fort de T|C1 de poids αC. Dans le trigraphe biparti T|(C ∪ D), on note par YA (resp. YB) l’ensemble des sommets de C ∪ D pour lesquels il existe un chemin dans T|(C ∪ D) les reliant à des sommets de D ∩ A1 (resp. D ∩ B1). Remarquons que par définition, D ∩ A1 ⊆ YA, D ∩ B1 ⊆ YB et il n’y a pas d’arêtes entre YA ∪ YB et (C ∪ D) \ (YA ∪YB). Montrons que YA ∩YB = ∅, et YA est fortement complet à YB. 63CHAPITRE 5. CALCUL DU STABLE MAXIMUM Supposons le contraire, alors il existe un chemin P dans T|(C ∪ D) d’un sommet de D ∩ A1 à un sommet de D ∩ B1. On peut supposer que P est minimal vis à vis de cette propriété, et donc que l’intérieur de P est dans C1 ; Par conséquent, P est de longueur paire car T|(C ∪ D) est biparti. Ceci contredit l’hypothèse sur le fait que (X1, X2) était impair. Nous définissons alors : — ZA = (D ∩ YA) ∪ (C ∩ YB) ∪ (C \ (YA ∪ YB)); — ZB = (D ∩ YB) ∪ (C ∩ YA) ∪ (D \ (YA ∪ YB). Des définitions et des propriétés ci-dessus, ZA et ZB sont des stables forts et ZA ⊆ A1∪C1 et ZB ⊆ B1∪C1. Donc, αC +αX = w(ZA)+w(ZB) ≤ αAC +αBC. Lemme 5.5. Si (X1, X2) est un 2-joint pair de T, alors αAC +αBC ≤ αC +αX. Démonstration. Soit A un stable fort de T|(A1 ∪ C1) de poids αAC et B un stable fort de T|(B1 ∪ C1) de poids αBC. Dans le trigraphe biparti T|(A ∪ B), on note YA (resp. YB) l’ensemble des sommets de A ∪ B pour lesquels il existe un chemin P dans T|(A ∪ B) les reliant à un sommet de A ∩ A1 (resp. B ∩ B1). Remarquons que d’après les définitions, A ∩ A1 ⊆ YA, B ∩ B1 ⊆ YB, et YA ∪ YB est fortement anticomplet à (A ∪ B) \ (YA ∪ YB). Nous allons montrer que YA ∩ YB = ∅ et Y est fortement anticomplet à YB. Supposons que ce ne soit pas le cas, alors il existe un chemin P dans T|(A ∪ B) d’un sommet de A ∩ A1 à un sommet de B ∩ B1. On peut supposer que P est minimal vis à vis de cette propriété, et donc que son intérieur est dans C1 ; par conséquent, il est de longueur impaire car T|(A ∪ B) est biparti. Ceci contredit l’hypothèse sur le fait que (X1, X2) était pair. Nous définissons alors : — ZD = (A ∩ YA) ∪ (B ∩ YB) ∪ (A \ (YA ∪ YB)); — ZC = (A ∩ YB) ∪ (B ∩ YA) ∪ (B \ (YA ∪ YB)). À partir des définitions et des propriétés ci-dessus, ZD et ZC sont des stables forts et ZD ⊆ X1 et ZC ⊆ C1. Donc, αAC +αBC = w(ZC)+w(ZD) ≤ αC +αX. Nous pouvons maintenant construire nos gadgets. Si (X, Y ) est un complément de 2-joint propre de T, alors soit X1 = X, X2 = Y et (A1, B1, C1, A2, B2, C2) une affectation de(X1, X2). Nous construisons le gadget TY,1 comme suit. Nous partons de T|Y et nous ajoutons deux nouveaux sommets marqués a, b, tels que a est fortement complet à B2 ∪ C2, b est fortement complet à A2 ∪ C2 et ab est une arête forte. Nous donnons les poids αA = α(T|A1) et αB = α(T|B1) respectivement aux sommets a et b. Nous notons αX = α(T|X). 645.2. STOCKER α DANS LES BLOCS Lemme 5.6. Si (X, Y ) est un complément de 2-joint propre de T, alors TY,1 est de Berge et α(T) = max(α(TY,1), αX). Démonstration. Puisque TY,1 est une semiréalisation d’un sous-trigraphe induit du bloc TY , comme défini dans le chapitre 2, il est clairement de Berge d’après 2.11. Soit Z un stable fort pondéré de poids maximum dans T. Si Z ∩ X1 = ∅, alors Z est aussi un stable fort dans TY,1, donc α(T) ≤ α(TY,1) ≤ max(α(TY,1), αX). Si Z ∩ A1 6= ∅ et Z ∩ (B1 ∪ C1) = ∅, alors {a1} ∪ (Z ∩ X2) est un stable fort dans TY,1 de poids α(T), donc α(T) ≤ α(TY,1) ≤ max(α(TY,1), αX). Si Z ∩ B1 6= ∅ et Z ∩(A1 ∪ C1) = ∅, alors {b1} ∪(Z ∩ X2) est un stable fort dans TY,1 de poids α(T), donc α(T) ≤ α(TY,1) ≤ max(α(TY,1), αX). Si Z∩(A1∪C1) 6= ∅ et Z∩(B1∪C1) 6= ∅, alors α(T) = αX, donc α(T) ≤ max(α(TY,1), αX). Dans tous les cas nous avons prouvé que α(T) ≤ max(α(TY,1), αX). Réciproquement, soit α = max(α(TY,1), αX). Si α = αX, alors en considérant n’importe quel stable fort de T|X1, nous voyons que α = αX ≤ α(T). Nous pouvons donc supposer que α = α(TY,1) et soit Z un stable fort pondéré de poids maximum dans TY,1. Si a /∈ Z et b /∈ Z, alors Z est aussi un stable fort dans T, donc α ≤ α(T). Si a ∈ Z et b /∈ Z, alors Z 0 ∪ Z \ {a}, où Z 0 est un stable fort pondéré de poids maximum dans T|A1, est aussi un stable fort dans T de même poids que Z, donc α ≤ α(T). Si a /∈ Z et b ∈ Z, alors Z 0 ∪Z \ {b} quand Z 0 est un stable de poids maximum dans T|B1 est aussi un stable fort dans T de même poids que Z, donc α ≤ α(T). Dans tous les cas, nous avons prouvé que α ≤ α(T). Si (X1, X2) est un 2-joint propre impair de T, alors nous construisons le gadget TY,2 comme suit. Nous commençons avec T|Y . Nous ajoutons ensuite quatre nouveaux sommets marqués a, a 0 , b, b 0 , tels que a et a 0 soient fortement complets à A2, b et b 0 soient fortement complets à B2, et ab est une arête forte. Nous donnons les poids αAC + αBC − αC − αX, αX − αBC, αAC + αBC − αC − αX et αX − αAC à respectivement a, a 0 , b et b 0 . Remarquons que d’après 5.3 et 5.4, tous les poids sont positifs. Nous définissons un autre gadget de décomposition TY,3 pour la même situation, de la manière suivante. Nous commençons avec T|Y . Nous ajoutons ensuite trois nouveaux sommets marqués a, a 0 , b, tels que a et a 0 sont fortement complets à A2, b est fortement complets à B2, et a 0a et ab sont des arêtes fortes. Nous donnons les poids αAC − αC, αX − αBC et αBC − αC à respectivement a, a 0 et b. Remarquons que d’après 5.3, tous les poids sont positifs. 65CHAPITRE 5. CALCUL DU STABLE MAXIMUM Lemme 5.7. Si (X, Y ) est un 2-joint propre de T, alors TY,2 et TY,3 sont de Berge, et α(T) = α(TY,2) + αC = α(TY,3) + αC. Démonstration. Supposons que TY,2 contienne un trou impair H. Puisqu’un trou impair n’a pas de sommet fortement dominant, il contient au plus un sommet parmi a, a0 et au plus un sommet parmi b, b0 . Donc H est un trou impair d’une semiréalisation du bloc TY (comme défini dans le chapitre 2). Ceci contredit 2.11. De la même manière, TY,2 ne contient pas d’antitrou impair, et est donc de Berge. La démonstration que TY,3 est de Berge est similaire. Soit Z un stable fort dans T de poids α(T). Nous construisons un stable fort dans TY,2 en ajoutant à Z ∩ X2 un des ensembles suivants (en fonction de la conclusion du lemme 5.2) : {a, a0}, {b, b0}, ∅, ou {a, a0 , b0}. Dans chaque cas, nous obtenons un stable fort de TY,2 de poids α(T) − αC. Ce qui prouve que α(T) ≤ α(TY,2) + αC. Réciproquement, soit Z un stable dans TY,2 de poids α(TY,2). On peut supposer que Z ∩ {a, a0 , b, b0} est un des ensembles {a, a0}, {b, b0}, ∅, ou {a, a0 , b0}, et suivant chacun de ces cas, on construit un stable fort de T en ajoutant à Z ∩ X2 un stable fort pondéré de poids maximum d’un des trigraphes suivants : T|(A1∪C1), T|(B1∪ C1), T|C1, ou T|X1. Nous obtenons un stable fort dans T de poids α(TY,2) + αC, prouvant que α(TY,2) + αC ≤ α(T). Ceci complète la démonstration pour TY,2. Prouvons maintenant l’égalité pour TY,3. Soit Z un stable fort dans T de poids α(T). Nous construisons un stable fort dans TY,3 en ajoutant à Z ∩ X2 un des ensembles suivants (en fonction de la conclusion du lemme 5.2) : {a}, {b}, ∅, or {a 0 , b}. Dans chaque cas, nous obtenons un stable fort de TY,3 de poids α(T) − αC. Ceci prouve que α(T) ≤ α(TY,3) + αC. Réciproquement, soit Z un stable de TY,3 de poids α(TY,3). D’après 5.4, αAC − αC ≥ αX − αBC, on peut donc supposer que Z ∩ {a, a0 , b} est un des ensembles {a}, {b}, ∅, ou {a 0 , b}, et suivant chacun, nous construisons un stable fort de T en ajoutant à Z ∩ X2 un stable fort pondéré de poids maximum d’un des trigraphes suivants : T|(A1 ∪ C1), T|(B1 ∪ C1), T|C1, ou T|X1. Nous obtenons alors un stable fort dans T de poids α(TY,3) + αC, ce qui prouve que α(TY,3) + αC ≤ α(T). Ceci termine la démonstration pour TY,3. Si (X1, X2) est un 2-joint propre pair de T et X = X1, Y = X2, alors soit (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Nous construisons le gadget TY,4 comme suit. Nous partons que T|Y . Nous ajoutons ensuite trois nouveaux sommets marqués a, b, c, tels que a est fortement complet à A2, b est fortement 665.3. CALCULER α complet à B2, et c est fortement adjacent aux sommets a et b et n’a aucun autre voisin. Nous donnons les poids αX − αBC, αX − αAC, et αX + αC − αAC − αBC à respectivement a, b et c. Remarquons que d’après 5.3 et 5.5, ces poids sont positifs. Lemme 5.8. Si (X, Y ) est un 2-joint propre pair de T, alors TY,4 est de Berge et α(T) = α(TY,4) + αAC + αBC − αX. Démonstration. Clairement, TY,4 est de Berge, car c’est la semiréalisation du bloc TY comme défini dans le chapitre 2, qui est de Berge d’après 2.11. Soit Z un stable fort dans T de poids α(T). Nous construisons un stable fort dans TY,4 en ajoutant à Z ∩ X2 un des ensembles suivant (suivant la conclusion de 5.2) : {a}, {b}, {c}, ou {a, b}. Dans chaque cas, nous obtenons un stable fort de TY,4 de poids α(T) − (αAC + αBC − αX). ce qui prouve que α(T) ≤ α(TY,4) + αAC + αBC − αX. Réciproquement, soit Z un stable fort dans TY,4 de poids α(TY,4). On peut supposer que Z ∩ {a, b, c} est un des ensembles {a}, {b}, {c}, ou {a, b}, et suivant ces cas, nous construisons un stable fort de T en ajoutant à Z ∩ X2 un stable fort pondéré de poids maximum d’un des trigraphes suivant : T|(A1∪C1), T|(B1∪C1), T|C1, ou T|X1. Nous obtenons un stable fort de T de poids α(TY,4) +αAC +αBC − αX, ce qui prouve que α(TY,4) + αAC + αBC − αX ≤ α(T). 5.3 Calculer α Nous sommes maintenant prêt à décrire notre algorithme de calcul d’un stable fort pondéré de poids maximal. La difficulté principale est que les blocs de décomposition définis dans le chapitre 2 doivent être utilisés pour rester dans la classe, alors que les gadgets définis dans la section 5.2 doivent être utilisés pour calculer α. Notre idée est de commencer par utiliser les blocs de décomposition dans un premier temps, puis de les remplacer par les gadgets lors d’une deuxième étape. Pour transformer un bloc en un gadget (ce que nous appelons réaliser une expansion), nous devons effacer une composante optionnelle, et la remplacer par un groupe de sommets de poids bien choisi. Pour cela nous avons besoin de deux informations ; la première est le type de décomposition utilisé originellement pour créer cette composante optionnelle, ainsi que les poids associés ; ces informations sont encodées dans ce que nous appelons un pré-label. La seconde information nécessaire est le type de la classe basique dans laquelle cette composante optionnelle va finir (car tous les gadgets ne préservent pas toutes les classes basiques) ; cette information 67CHAPITRE 5. CALCUL DU STABLE MAXIMUM est encodée dans ce que nous appelons un label. Remarquons que le pré-label est connu juste après la décomposition du trigraphe, alors que le label n’est connu qu’après, lorsque le trigraphe est complétement décomposé. Formalisons cela. Soit S une composante optionnelle d’un trigraphe bigame T. Un pré-label de S est défini par : — (“Complément de 2-joint impair”, αA, αB, αX) avec αA, αB et αX des entiers, si S est une arête optionnelle. — (“2-joint impair”, αAC, αBC, αC, αX) avec αAC, αBC, αC et αX des entiers, si S est une arête optionnelle et qu’aucun sommet de T n’est complet à S. — (“Complément de 2-joint pair”, αA, αB, αX) avec αA, αB et αX des entiers, si S est un composante lourde. — (“2-joint pair”, αAC, αBC, αC, αX) avec αAC, αBC, αC et αX des entiers, si S est une composante légère. Remarquons que certains types de composantes optionnelles sont “éligibles” à la fois au premier et au deuxième pré-label. Un pré-label doit être vu comme “la décomposition à partir de laquelle la composante optionnelle est construite”. Quand T est un trigraphe et S est un ensemble des composantes optionnelles de T, une fonction de pré-label pour (T, S) est une fonction qui associe à chaque S ∈ S un pré-label. Il est important de remarquer que S est seulement un ensemble de composantes optionnelles, donc certaines composantes optionnelles peuvent ne pas avoir de pré-label. Notons que la définition suivante des labels est un peu ambigüe. En effet, lorsqu’on parle de “la classe basique contenant le trigraphe” il est possible que certains trigraphes soient contenus dans plusieurs classes basiques. C’est typiquement le cas des petits trigraphes et des trigraphes complets par exemple. Il est important de voir que cela n’est pas un problème ; si un trigraphe appartient à plusieurs classes de base, notre algorithme choisi arbitrairement une de ces classes, et produit un résultat correct. Pour ne pas compliquer les notations c’est pas n’est pas complétement formalisé dans notre algorithme. Pour les trigraphes doublés, il y a une autre ambiguïté. Si T est un trigraphe doublé et (X, Y ) est une bonne partition de T, une arête optionnelle uv de T est une arête de couplage si u, v ∈ X et une antiarête de couplage si u, v ∈ Y . Dans certains cas dégénérés, une arête optionnelle d’un trigraphe doublé peut être à la fois une arête de couplage et une antiarête de couplage suivant la bonne partition choisie, cependant une fois la bonne partition choisie il n’y a plus d’ambiguïté. Là encore ce n’est pas un problème : lorsqu’une arête optionnelle est ambigüe, notre algorithme choisi arbitrairement une bonne partition. 685.3. CALCULER α Soit S une arête optionnelle d’un trigraphe bigame. Un label pour S est une paire L 0 = (L, N), tel que L est un pré-label et N est une des étiquettes suivantes : “biparti”, “complément de bipartite”, “line”, “complément de line”, “couplage doublé”, “anticouplage doublé”. On dit que L 0 étend L. l’étiquette ajoutée au pré-label d’une composante optionnelle S doit être pensée comme “la classe basique dans laquelle la composante S finit une fois que le trigraphe est complétement décomposé”. Quand T est un trigraphe et S est un ensemble de composantes optionnelles de T, une fonction de label pour (T, S) est une fonction qui associe à chaque S ∈ S un label. Dans ces conditions, on dit que T est étiqueté. Comme pour les pré-labels, les composantes optionnelles qui ne sont pas dans S ne reçoivent pas de label. Soit T un trigraphe étiqueté, S un ensemble de composantes optionnelles de T et L une fonction de label pour (T, S). L’expansion de (T, S,L), est le trigraphe obtenu à partir de T après avoir effectué pour chaque S ∈ S de label L l’opération suivante : 1. Si L = ((“Complément de 2-joint impair”, αA, αB, αX), N) pour une étiquette N (donc S est une arête optionnelle ab) : transformer ab en arête forte, donner le poids αA au sommet a et le poids αB au sommet b. 2. Si L = ((“2-joint impair”, αAC, αBC, αC, αX), N) pour une étiquette N (donc S est une arête optionnelle ab) : transformer ab en arête forte et : — Si N est une des étiquettes suivantes : “biparti”, “complément de line”, ou “couplage doublé”, alors ajouter un sommet a 0 , un sommet b 0 , rendre a 0 fortement complet à N(a) \ {b}, rendre b fortement complet à N(b) \ {a}, et donner les poids αAC +αBC −αC −αX, αX −αBC, αAC +αBC −αC −αX et αX − αAC à respectivement a, a 0 , b et b 0 — Si N est une des étiquettes suivantes : “complément de biparti”, “line” ou “anticouplage doublé”, alors ajouter un sommet a 0 , rendre a 0 fortement complet à {a} ∪ N(a) \ {b} et donner les poids αAC − αC, αX − αBC et αBC − αC à respectivement a, a 0 et b 3. Si L = ((“Complément de 2-joint pair”, αA, αB, αX), N) pour une étiquette N (donc S est composée de deux arêtes optionnelles ac et cb et c est lourd) : supprimer le sommet c, et donner les poids αA au sommet a et αB au sommet b. 4. Si L = ((“2-joint pair”, αAC, αBC, αC, αX), N) pour une étiquette N (donc S est composée de deux arêtes optionnelles ac et cb, et c est léger) : transformer ac et cb en arête forte, donner les poids αX − αBC, αX − αAC, et αX + αC − αAC − αBC à respectivement a, b et c. 69CHAPITRE 5. CALCUL DU STABLE MAXIMUM L’expansion doit être vue comme “ce qui est obtenu si on utilise les gadgets comme défini dans la section 5.2 au lieu des blocs de décomposition comme défini dans le chapitre 2”. Théorème 5.9. Supposons que T est un trigraphe qui est dans une classe basique d’étiquette N, S est l’ensemble des composantes optionnelles de T et L est une fonction de label pour T, tels que pour tout S ∈ S de label L, un des points suivants est vérifié : — L = (. . . , N) avec N une des étiquettes suivantes : “biparti”, “complé- ment de biparti”, “line” ou “complément de line” ; ou — N = “doublé”, S est une arête de couplage de T et L = (. . . , “couplage doublé”); ou — N = “doublé”, S est une antiarête de couplage de T et L = (. . . , “anticouplage doublé”). Alors l’expansion de (T, S,L) est un trigraphe basique. Démonstration. À partir de nos hypothèses, T est basique. Donc il suffit de dé- montrer que l’expansion d’une composante optionnelle S préserve le fait d’être basique, et le résultat suivra par induction sur S. Soit T 0 l’expansion. Dans plusieurs cas (c’est à dire dans les cas 1, 3 et 4) l’expansion consiste simplement à transformer des arêtes optionnelles en arêtes fortes et potentiellement supprimer des sommets. D’après 2.3, ces opérations préservent le fait d’être basique. Nous avons donc simplement à étudier le cas 2 de la définition des expansions. Nous pouvons donc supposer que S est une arête optionnelle ab. Il est facile de voir que l’expansion comme définie dans le cas 2 préserve les trigraphes bipartis et les compléments de trigraphes bipartis ; donc si N ∈ {“biparti”, “complément de biparti”} le résultat est prouvé. Supposons que N =“line”, et donc T est un line trigraphe. Soit G la réalisation complète de T, et R le graphe biparti, tel que G = L(R). Donc a est une arête xaya dans R, et b est un arête yaxb. Puisque T est un line trigraphe, toute clique de taille au moins 3 dans T est une clique forte, et donc a et b n’ont pas de voisin commun dans T. Donc tous les voisins de a, à l’exception de b, sont des arêtes incidentes à xa et pas à ya. Soit R0 le graphe obtenu à partir de R en ajoutant une arête pendante e à xa. Remarquons que L(R0 ) est isomorphe à la réalisation complète de T 0 (l’arête e correspond au nouveau sommet a 0 ), et donc T 0 est un line trigraphe. Supposons maintenant que N =“complément de line”, donc T est le complé- ment d’un line trigraphe. Puisque toute clique de taille au moins 3 dans T est une 705.3. CALCULER α clique forte, V (T) = N(a) ∪ N(b). Supposons qu’il existe u, v ∈ N(a) \ N(b), tels que u est adjacent à v. Puisque T est un line trigraphe, et que uv est une semiarête, alors {u, v, b} est une clique de taille 3 dans T. Soit R le graphe biparti, tel que la réalisation complète de T soit L(R). Alors dans R aucune arête de u, v, a ne partage d’extrémité, cependant b partage une extrémité avec ces trois arêtes, c’est une contradiction. Ceci prouve que N(a) \ N(b) (et par symétrie que N(b) \ N(a)) est un stable fort dans T. Comme N(a) ∩ N(b) = ∅, alors T est biparti, et donc comme précédemment, T 0 est basique. On peut donc supposer que T est un trigraphe doublé avec (X, Y ) une bonne partition. Si S = ab est une arête de couplage de T, alors ajouter les sommets a 0 , b0 à X produit une bonne partition de T 0 . Si S = ab est une antiarête de couplage de T, alors ajouter le sommet a 0 à Y produit une bonne partition de T 0 . Dans tous les cas T 0 est basique et le résultat est prouvé. Soit T un trigraphe, S un ensemble de composantes optionnelles de T, L une fonction de label de (T, S) et T 0 l’expansion de (T, S,L). Soit X ⊆ V (T). On définit l’expansion de X ⊆ V (T) en X0 comme suit. On part avec X0 = X et on effectue les opérations suivantes pour tout S ∈ S. 1. Si L = ((“Complément de 2-joint impair”, αA, αB, αX), N) pour une étiquette N (donc S est une arête optionnelle ab), ne pas modifier X0 . 2. Si L = ((“2-joint impair”, αAC, αBC, αC, αX), N) pour une étiquette N(donc S est une arête optionnelle ab) : — Si N est une des étiquettes suivantes : “biparti”, “complément de line”, ou “couplage doublé”, faire : si a ∈ X alors ajouter a 0 à X0 , et si b ∈ X alors ajouter b 0 à X0 . — Si N est une des étiquettes suivantes : “complément de biparti”, “line” ou “anticouplage doublé”, faire : si a ∈ X alors ajouter a 0 à X0 . 3. Si L = ((“Complément de 2-joint pair”, αA, αB, αX), N) pour une étiquette N (donc S est composée de deux arêtes optionnelles ac et cb et c est lourd), faire : si c ∈ X, alors supprimer c de X0 . 4. Si L = ((“2-joint pair”, αAC, αBC, αC, αX), N) pour une étiquette N (donc S est composée de deux arêtes optionnelles ac et cb et c est léger) ne pas modifier X0 . 71CHAPITRE 5. CALCUL DU STABLE MAXIMUM Théorème 5.10. Avec les notations ci-dessus, si (X1, X2) est un 2- joint propre (resp. le complément d’un 2-joint propre) de T avec (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2), alors (X0 1 , X0 2 ) est un 725.3. CALCULER α 2-joint propre (resp. le complément d’un 2-joint propre) de T 0 avec (A0 1 , B0 1 , C0 1 , A0 2 , B0 2 , C0 2 ) une affectation de (X0 1 , X0 2 ), de même parité que (X1, X2). (Remarquons que la notion de parité fait sens pour T 0 , puisque T 0 est de Berge d’après 5.6, 5.7 et 5.8). Démonstration. Directe à partir des définitions. Théorème 5.11. Il existe un algorithme avec les spécifications suivantes : Entrée : Un triplet (T, S,L), tels que T est un trigraphe de Berge apprivoisé, S est un ensemble de composantes optionnelles de T et L est une fonction de pré-label pour (T, S). Sortie : Une fonction de label L 0 pour (T, S) qui étend L, et un stable fort pondéré de poids maximum de l’expansion de (T, S,L 0 ). Complexité en temps : O(n 5 ) Démonstration. Nous décrivons un algorithme récursif. La première étape de l’algorithme utilise 5.1 pour vérifier que T est basique. Remarquons que si T est un trigraphe doublé, l’algorithme de 5.1 calcule également quelles arêtes optionnelles sont des arêtes de couplage, et quelles arêtes optionnelles sont des antiarêtes de couplage. Commençons par supposer que T est dans une classe basique de nom N (c’est en particulier le cas lorsque |V (T)| = 1). Nous étendons la fonction de pré-label L en une fonction de label L 0 comme suit : si N 6=“doublé”, alors on ajoute N à tous les pré-labels et sinon, pour tout S ∈ S de label L, on ajoute “couplage doublé” (resp. “anticouplage doublé”) à L si S est une arête de couplage (resp. antiarête de couplage). La fonction de label obtenue vérifie les hypothèses de 5.9, donc l’expansion T 0 de (T, S,L 0 ) est basique, et en exécutant l’algorithme de 5.1 sur T 0 , nous obtenons un stable fort pondéré de poids maximum de T 0 en temps O(n 4 ). Donc, nous pouvons bien calculer une fonction de label L 0 pour T, S qui étend L, et un stable fort pondéré de poids maximum de l’expansion de (T, S,L 0 ). Supposons maintenant que T n’est pas basique. Puisque T est un trigraphe de Berge apprivoisé, d’après 2.10, nous savons que T se décompose par un 2-joint ou le complément d’un 2-joint. Dans [7], un algorithme fonctionnant en temps O(n 4 ) est donné pour calculer un 2-joint dans un graphe quelconque. En fait les 2-joints comme décrit dans [7] ne sont pas exactement ceux que nous utilisons : Le dernier point de notre définition n’a pas besoin d’être vérifié (celui qui assure 73CHAPITRE 5. CALCUL DU STABLE MAXIMUM qu’aucun côté du 2-joint n’est réduit à un chemin de longueur exactement 2). Cependant la méthode du Théorème 4.1 de [7] montre comment ajouter ce type de contraintes sans perte de temps. Il est facile d’adapter cette méthode pour la dé- tection de 2-joint dans un trigraphe (nous présentons d’ailleurs dans le chapitre 6 un algorithme similaire). Nous pouvons donc calculer la décomposition nécessaire en temps O(n 4 ). Nous calculons alors les blocs TX et TY comme défini dans le chapitre 2. Remarquons que tout membre de S est une arête optionnelle de seulement un des blocs TX ou TY . Nous appelons SX (resp. SY ) l’ensemble des éléments de S qui sont dans TX (resp. TY ). Soit S la composante optionnelle marquée utilisée pour créer le bloc TY . Observons que pour tout u ∈ S, il existe un sommet v ∈ X tel que NT (v)∩Y = NTY (u)∩Y . De même pour TX. Donc, la fonction de pré-label L pour (T, S) induit naturellement une fonction de pré-label LX pour (TX, SX) et une fonction de pré-label LY pour (TY , SY ) (chaque S ∈ SX reçoit le même pré-label que celui dans L, et de même pour SY . Dans la suite, la décomposition réfère à la décomposition qui a été utilisée pour construire TX et TY , (c’est une des étiquettes “complément de 2-joint pair”, “complément de 2-joint impair”, “2- joint pair” ou “2-joint impair”) et nous utilisons nos notations habituelles pour l’affectation de cette décomposition. Sans perte de généralité, on peut supposer que |V (TX)| ≤ |V (TY )|. D’après 2.11, TX, TY sont des trigraphes de Berge bigames, et d’après 2.12, ils sont apprivoisés. Soit S la composante optionnelle marquée qui est utilisée pour créer le bloc TY . On définit S 0 Y = SY ∪ {S}. On peut maintenant construire une fonction de pré-label LY pour S 0 Y comme suit. Toutes les composantes optionnelles dans SY conservent le pré-label qu’elles ont dans S. La composante marquée S reçoit le pré-label suivant : — Si la décomposition est un complément de 2-joint impair, alors calculer récursivement αA = α(TX|A1), αB = α(TX|B1) et αX = α(TX|X), et définir le pré-label de S comme (“Complément de 2-joint impair”, αA, αB, αX). Remarquons que dans ce cas |S| = 2. — Si la décomposition est un 2-joint impair, alors calculer récursivement αAC = α(TX|(A1 ∪ C1)), αBC = α(TX|(B1 ∪ C1)), αC = α(TX|C1) et αX = α(TX|X) et définir le pré-label de S comme (“2-joint impair”, αAC, αBC, αC, αX). Remarquons que dans ce cas |S| = 2 et aucun sommet de T 0 Y \ S n’est fortement complet à S. — Si la décomposition est un complément de 2-joint pair, alors calculer récursivement αA = α(TX|A1), αB = α(TX|B1) et αX = α(TX|X), et définir le 745.3. CALCULER α pré-label de S comme (“Complément de 2-joint pair”, αA, αB, αX). Remarquons que dans ce cas, |S| = 3 et S est léger. — Si la décomposition est un 2-joint pair, alors calculer récursivement αAC = α(TX|(A1 ∪ C1)), αBC = α(TX|(B1∪C1)), αC = α(TX|C1) et αX = α(TX|X) et définir le pré-label de S comme (“2-joint pair”, αAC, αBC, αC, αX). Remarquons que dans ce cas, |S| = 3 et S est lourd. Maintenant TY , S 0 Y a une fonction de pré-label LY . Nous exécutons récursivement notre algorithme pour (TY , S 0 Y ,LY ). Nous obtenons une extension L 0 Y de LY et un stable fort pondéré de poids maximum de l’expansion T 0 Y de (TY , S 0 Y ,L 0 Y ). Nous utilisons L 0 Y pour terminer la construction de L 0 , en utilisant pour tout S ∈ SY la même extension que nous avions dans L 0 Y pour étendre LY . Nous avons donc maintenant, une extension L 0 de L. Soit T 0 l’extension de (T, S,L 0 ). Remarquons maintenant que d’après 5.10, T 0 Y est exactement le gadget pour T 0 , comme défini dans la section 5.2. Donc, α(T 0 ) peut être calculé à partir de α(T 0 Y ), comme expliqué dans 5.6, 5.7, ou 5.8. Donc, l’algorithme fonctionne correctement lorsqu’il renvoie L 0 et le stable fort pondéré de poids maximum que nous venons de calculer. Analyse de complexité : Avec notre manière de construire nos blocs de dé- composition, nous avons |V (TX)| − 3 + |V (TY )| − 3 ≤ n et d’après 2.9(viii) nous avons 6 ≤ |V (TX)|, |V (TY )| ≤ n − 1. Rappelons que nous avons supposé que |V (TX)| ≤ |V (TY )|. Soit T(n) la complexité de notre algorithme. Pour chaque type de décomposition, nous effectuons au plus quatre appels récursifs sur le petit bloc, c’est à dire TX, et un appel récursif sur le grand bloc TY . Nous avons donc T(n) ≤ dn4 lorsque le trigraphe est basique et sinon T(n) ≤ 4T(|V (TX)|) + T(|V (TY )|) + dn4 , avec d la constante venant de la complexité de trouver un 2-joint ou un complément de 2-joint et de trouver α dans les trigraphes basiques. Nous pouvons maintenant démontrer qu’il existe une constante c, telle que T(n) ≤ c.n5 . Notre démonstration est par induction sur n. Nous montrons qu’il existe une constante N, telle que l’étape d’induction passe pour tout n ≥ N (cet argument et en particulier N ne dépend pas de c). Le cas de base de notre induction est alors sur les trigraphes basiques ou sur les trigraphes qui ont au plus N sommets. Pour ces trigraphes, il est clair que la constante c existe. Nous faisons la démonstration de l’induction uniquement dans le cas du 2- joint pair (potentiellement dans le complément). La démonstration pour le 2-joint impair est similaire. Nous définissons n1 = |V (TX)|. Nous avons T(n) ≤ 4T(n1) + 75CHAPITRE 5. CALCUL DU STABLE MAXIMUM T(n + 6 − n1) + dn4 pour tout n1 et n vérifiant b n 2 c + 3 ≥ n1 ≥ 7. Définissons f(n1) = n 5−4n 5 1−(n+6−n1) 5−dn4 . Nous montrons qu’il existe une constante N, telle que pour tout n ≥ N et pour tout n1 tel que 7 ≤ n1 ≤ bn 2 c + 3, f(n1) ≥ 0. Par hypothèse d’induction, ceci prouve notre résultat. Un simple calcul montre que : f 0 (n1) = −20n 4 1 + 5(n + 6 − n1) 4 f 00(n1) = −80n 3 1 − 20(n + 6 − n1) 3 Puisque n + 6 − n1 est positif, nous avons f 00 ≤ 0. Donc, f 0 est décroissante, et il est facile de voir que si n est suffisamment large, f 0 (n1) est positif pour n1 = 7 et négatif pour n1 = b n 2 c + 3. Maintenant f est minimum pour n1 = 7 ou n1 = b n 2 c + 3. Puisque f(7) = n 5 − (n − 1)5 − P(n) avec P un polynôme, tel que deg(P) ≤ 4, si n est suffisamment large, alors f(7) est positif. De même f(b n 2 c + 3) ≤ n 5 − 5(d n 2 e + 3)5 . Là encore, si n est suffisamment large, f(b n 2 c + 3) est positif. Donc, il existe une constante N, telle que pour tout n ≥ N, f(n1) ≥ 0. Cela montre que notre algorithme s’exécute en temps O(n 5 ). Théorème 5.12. On peut calculer un stable fort pondéré de poids maximum d’un trigraphe T de Berge apprivoisé en temps O(n 5 ). Démonstration. Exécuter l’algorithme de 5.11 pour (T, ∅, ∅). Théorème 5.13. On peut calculer un stable pondéré de poids maximum d’un graphe G de Berge apprivoisé en temps O(n 5 ). Démonstration. D’après 5.12 et le fait que les graphes de Berge peuvent être vu comme des trigraphes de Berge. Contrairement aux deux chapitres précédents, les résultats de ce chapitre ne peuvent s’étendre aux classes closes par k-joint. La raison principale est que les lemmes 5.3 et 5.4 qui sont nécessaires pour assurer que les poids dans les blocs sont tous positifs ou nuls ne sont vrais que dans le cas des graphes de Berge. Plus précisément nous avons besoin que tous les chemins entre les deux ensembles frontières du 2-joint (avec nos notations : Ai et Bi) soient de mêmes parités (ce qui est prouvé par le lemme 2.4 pour les graphes de Berge). 765.3. CALCULER α On peut voir notre preuve comme étant en deux temps. Nous commençons par construire l’arbre de décomposition. Lors de cette étape, nous devons n’utiliser que les blocs qui préservent la classe pour pouvoir continuer à décomposer. Puis une fois le trigraphe complètement décomposé nous modifions les blocs afin de pouvoir faire remonter l’information des blocs basiques au trigraphe complet. Un point important lors de la reconstruction est de bien choisir sur quel bloc poser le plus de questions, en effet si l’on ne fait pas attention l’algorithme devient exponentiel. Dans les algorithmes présentés nous nous sommes focalisé sur le calcul de la valeur du stable maximum. Il est facile et classique de convertir un tel algorithme en un algorithme qui explicite un stable maximum pour un surcout linéaire. Cependant comme il est possible pour les classes de base d’expliciter à chaque fois un stable maximum, il est possible en utilisant de bonnes structures de données de suivre les sommets du stable maximum à chaque étape de l’induction et ainsi d’expliciter un stable maximum sans surcout. Enfin il faut noter qu’en utilisant le théorème 1.1 nous obtenons un algorithme de coloration en temps O(n 7 ). 77CHAPITRE 5. CALCUL DU STABLE MAXIMUM 78Chapitre 6 Décompositions extrêmes Les résultats de ce chapitre ont été obtenus avec Maria Chudnovsky, Nicolas Trotignon et Kristina Vušković, ils font l’objet d’un article [15] soumis à Journal of Combinatorial Theory, Series B. 6.1 Décompositions extrêmes Dans cette section nous allons démontrer que les trigraphes de Berge apprivoisés qui ne sont pas basiques, admettent des décompositions extrêmes. C’est à dire des décompositions telles qu’un des blocs de décomposition est basique. Ce résultat n’est pas trivial, puisque qu’il existe dans [37] un exemple montrant que les graphes de Berge généraux n’admettent pas toujours de 2-joint extrême. Les décompositions extrêmes sont parfois très utiles pour faire des preuves par induction. En fait nous ne sommes pas capable de démontrer que tous les trigraphes de Berge apprivoisés admettent un 2-joint ou un complément de 2-joint extrême. Pour démontrer l’existence de décompositions extrêmes nous devons inclure un nouveau type de décomposition, la paire homogène à notre ensemble de décomposition. Il est intéressant de remarquer que cette nouvelle décomposition est déjà utilisée dans de nombreuses variantes du théorème 2.5. Il est intéressant de voir que nous avons besoin d’étendre notre ensemble de décompositions afin d’obtenir un théorème de structure extrême. Il est donc possible que les star-cutsets ou plus généralement les skew-partitions ne soient pas des décompositions assez générales mais qu’en 79CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES Figure 6.1 – Un exemple de graphe d’admettant pas de 2-joint extrême les étendant il soit possible d’obtenir un théorème de décomposition extrême. Par exemple dans [1], nous avons pu avec Aboulker, Radovanović Trotignon et Vuš- ković, en étendant la définition du star-cutset avoir une décomposition extrême d’une classe de graphes particulière. Grâce à cette décomposition extrême nous avons alors pu démontrer notre hypothèse d’induction. Une paire homogène propre d’un trigraphe T est une paire de sous-ensembles disjoints (A, B) de V (T), telle que si A1, A2 sont respectivement les ensembles de tous les sommets fortement complets à A et fortement anticomplets à A et que B1, B2 sont définis de manière similaire, alors : — |A| > 1 et |B| > 1 ; — A1 ∪ A2 = B1 ∪ B2 = V (T) \ (A ∪ B) (et en particulier tout sommet de A a un voisin et un antivoisin dans B et vice versa) ; et — les quatre ensembles A1∩B1, A1∩B2, A2∩B1, A2∩B2 sont tous non-vides. Dans ces circonstances, on dit que (A, B, A1 ∩ B2, A2 ∩ B1, A1 ∩ B1, A2 ∩ B2) est une affectation de la paire homogène. Une manière de démontrer l’existence d’une décomposition extrême est de considérer un “côté” de la décomposition et de le minimiser, pour obtenir ce que nous appelons une fin. Cependant pour les paires homogènes, les deux côtés (qui sont A ∪ B et V (T) \ (A ∪ B) avec nos notations habituelles) ne sont pas symé- triques comme le sont les deux côtés d’un 2-joint. Nous devons donc décider quel côté minimiser. Nous choisissons de minimiser le côté A ∪ B. Formellement nous devons faire la distinction entre un fragment, qui est n’importe quel côté d’une décomposition et un fragment propre qui est le côté qui va être minimisé et qui ne peut donc pas être le côté V (T) \ (A ∪ B) d’une paire homogène. Toutes les définitions sont données formellement ci-dessous. 806.1. DÉCOMPOSITIONS EXTRÊMES A B Figure 6.2 – Paire Homogène Nous commençons par modifier la définition des fragments pour inclure les paires homogènes. À partir de maintenant, un ensemble X ⊆ V (T) est un fragment d’un trigraphe T si une des propriétés suivantes est vérifiée : 1. (X, V (T) \ X) est un 2-joint propre de T ; 2. (X, V (T) \ X) est un complément de 2-joint propre de T ; 3. il existe une paire homogène propre (A, B) de T telle que X = A ∪ B ou X = V (T) \ (A ∪ B). Un ensemble X ⊆ V (T) est un fragment propre d’un trigraphe T si une des propriétés suivantes est vérifiée : 1. (X, V (T) \ X) est un 2-joint propre de T ; 2. (X, V (T) \ X) est un complément de 2-joint propre de T ; 3. il existe une paire homogène propre (A, B) de T telle que X = A ∪ B. Une fin de T est un fragment propre X de T tel qu’aucun sous-trigraphe induit propre de X est un fragment propre de T. Remarquons qu’un fragment propre de T est un fragment propre de T, et une fin de T est une fin de T. De plus un fragment dans T est encore un fragment dans T. Nous avons déjà défini les blocs de décomposition d’un 2-joint et d’un complément de 2-joint. Nous définissons maintenant les blocs de décomposition d’une paire homogène. Si X = A ∪ B avec (A, B, C, D, E, F) une affectation d’une paire homogène propre (A, B) de T, alors nous construisons le bloc de décomposition TX en rapport avec X de la manière suivante. Nous partons de T|(A ∪ B). Nous ajoutons ensuite 81CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES deux nouveaux sommets marqués c et d tels que c est fortement complet à A, d est fortement complet à B, cd est une arête optionnelle et il n’y a aucune autre arête entre {c, d} et A ∪ B. Ici encore, {c, d} est appelé la composante marquée de TX. Si X = C ∪ D ∪ E ∪ F avec (A, B, C, D, E, F) une affectation d’une paire homogène propre (A, B) de T, alors nous construisons le bloc de décomposition TX en rapport avec X de la manière suivante. Nous partons de T|X. Nous ajoutons alors deux nouveaux sommets marqués a et b tels que a est fortement complet à C ∪ E, b est fortement complet à D ∪ E, ab est une arête optionnelle et il n’y a aucune autre arête entre {a, b} et C ∪ D ∪ E ∪ F. Ici encore, {a, b} est appelé la composante marquée de TX. Théorème 6.1. Si X est un fragment d’un trigraphe T de Berge bigame, alors TX est un trigraphe de Berge bigame. Démonstration. D’après la définition de TX, il est clair que tous ses sommets sont dans au plus une arête optionnelle ou sont lourds ou sont légers. Il ne nous reste donc plus qu’à démontrer que TX est de Berge. Si le fragment vient d’un 2-joint ou d’un complément de 2-joint, alors nous avons le résultat d’après le lemme 2.11. Si X = A ∪ B et (A, B) est une paire homogène propre de T, alors soit H un trou ou un antitrou de TX. En passant si besoin au complémentaire, on peut supposer que H est un trou. S’il contient les deux sommets marqués c, d, alors c’est un trou sur quatre sommets ou il doit contenir deux voisins forts de d dans B, donc H a longueur 6. Par conséquent, on peut supposer que H contient au plus un sommet parmi c, d et donc un trou de longueur strictement identique peut être obtenu dans T en remplaçant c ou d par un sommet de C ou de D. Par conséquent, H a longueur paire. S’il existe une paire homogène propre (A, B) de T telle que X = V (T)\(A∪B), alors puisque pour tout sommet de A a un voisin et un antivoisin dans B, nous pouvons remarquer que toute réalisation de TX est un sous-trigraphe induit d’une réalisation de T. Il suit que TX reste de Berge. Théorème 6.2. Si X est un fragment d’un trigraphe T de Berge apprivoisé, alors le bloc de décomposition TX n’a pas de skew-partition équilibrée. Démonstration. Pour démontrer ce résultat, supposons que TX ait une skewpartition équilibrée (A0 , B0 ) avec une affectation (A0 1 , A0 2 , B0 1 , B0 2 ). À partir de cette 826.1. DÉCOMPOSITIONS EXTRÊMES skew-partition équilibrée, nous allons trouver une skew-partition dans T. Nous allons alors utiliser le lemme 2.8 afin de démontrer l’existence d’une skew-partition équilibrée dans T. Ceci nous fournira une contradiction, et démontrera le résultat. Si le fragment vient d’un 2-joint ou d’un complément de 2-joint, nous avons le résultat d’après le lemme 2.12. Si X = A ∪ B et (A, B) est une paire homogène de T, alors soit (A, B, C, D, E, F) une affectation de (A, B). Puisque cd est une arête optionnelle, les sommets marqués c et d n’ont pas de voisin commun et cd domine TX. Sans perte de généralité il n’y a qu’un cas à traiter : c ∈ A0 1 et d ∈ B0 1 . Puisque B0 2 est complet à d et A0 2 est anticomplet à c, il suit que A0 2 , B0 2 ⊆ B. Maintenant (A0 1 \ {c}∪C ∪F, A0 2 , B0 1 \ {d}∪D∪E, B0 2 ) est une affectation d’une skew-partition dans T. La paire (A0 2 , B0 2 ) est équilibrée dans T car elle l’est dans TX. Par conséquent, d’après le lemme 2.8, T admet une skew-partition équilibrée, c’est une contradiction. Si X = V (T)\(A∪B) et (A, B) est une paire homogène propre de T, alors soit (A, B, C, D, E, F) une affectation de (A, B). Puisque ab est une arête optionnelle, on peut à symétrie et complémentation près supposer que a ∈ A0 1 et b ∈ A0 1 ∪ B0 1 . Si b ∈ A0 1 alors (A ∪ B ∪ A0 1 \ {a, b}, A0 2 , B0 1 , B0 2 ) est une affectation d’une skewpartition dans T. Dans tous les cas, la paire (A0 2 , B0 2 ) est équilibrée dans T car elle l’est dans TX. Par conséquent, d’après le lemme 2.8, T admet une skew-partition équilibrée, c’est une contradiction. Théorème 6.3. Si X est une fin d’un trigraphe T de Berge apprivoisé, alors le bloc de décomposition TX est basique. Démonstration. Soit T un trigraphe de Berge apprivoisé et X une fin de T. D’après le lemme 6.1, TX est un trigraphe bigame de Berge et d’après le lemme 6.2, TX n’a pas de skew-partition équilibrée. D’après le théorème 2.10, il suffit de montrer que TX n’a ni 2-joint propre, ni complément de 2-joint propre. En passant au complémentaire de T si nécessaire, on peut supposer qu’une des propriétés suivantes est vraie : — X = A ∪ B et (A, B) est une paire homogène propre de T ; — (X, V (T) \ X) est un 2-joint pair propre de T ; ou — (X, V (T) \ X) est un 2-joint impair propre de T. Cas 1 : X = A ∪ B avec (A, B) une paire homogène propre de T. Soit (A, B, C, D, E, F) une affectation de (A, B). 83CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES Supposons que TX admette un 2-joint propre (X1, X2). Soit (A1, B1, C1, A2, B2, C2) une affectation de (X1, X2). Puisque cd est une arête optionnelle, nous pouvons supposer que les deux sommets c, d sont tous les deux dans X2. Comme {c, d} domine fortement TX, on peut supposer que c ∈ A2 et d ∈ B2, et donc C1 = ∅. Puisque c est fortement complet à A, A1 ⊆ A et de manière similaire, B1 ⊆ B. D’après le lemme 6.2 et le lemme 2.9, |A1| ≥ 2 et |B1| ≥ 2 et comme C1 = ∅, tous les sommets de A1 ont un voisin et un antivoisin dans B1 et vice versa. Maintenant (A1, B1, C ∪ A2 \ {c}, D ∪ B2 \ {d}, E, F ∪ C2) est une affectation d’une paire homogène propre de T. Comme |X2| ≥ 3, A1 ∪ B1 est strictement inclus dans A ∪ B, c’est une contradiction. Comme A∪B est aussi une paire homogène de T, en utilisant le même argument que ci-dessus, TX n’admet pas de complément de 2-joint propre. Cas 2 : (X, V (T) \ X) est un 2-joint pair propre (X1, X2) de T, avec X = X1. Soit (A1, B1, C1, A2, B2, C2) une affectation de (X, V (T) \ X). Supposons que TX admette un 2-joint propre (X0 1 , X0 2 ). Soit (A0 1 , B0 1 , C0 1 , A0 2 , B0 2 , C0 2 ) une affectation de (X0 1 , X0 2 ). Puisque ac et bc sont des arêtes optionnelles, on peut supposer que a, b, c ∈ X0 2 . Nous affirmons maintenant que (X0 1 , V (T) \ X0 1 ) est un 2-joint propre de T et que X0 1 est strictement inclus dans X, ce qui est une contradiction. Remarquons que d’après la définition d’un 2-joint et le fait que c n’ait pas de voisin fort, X0 2 ne peut pas être réduit à {a, b, c} et par conséquent, X0 1 est strictement inclus dans X. Puisque c n’a pas de voisin fort, c ∈ C 0 2 . Puisque a et b n’ont pas de voisin fort commun dans TX1 , il n’y a à symétrie près que trois cas : ou bien a ∈ A0 2 , b ∈ B0 2 , ou bien a ∈ A0 2 , b ∈ C 0 2 , ou bien a, b ∈ C 0 2 . Si a ∈ A0 2 et b ∈ B0 2 , alors (A0 1 , B0 1 , C0 1 , A2 ∪A0 2 \ {a}, B2 ∪B0 2 \ {b}, C2 ∪C 0 2 \ {c}) est une affectation d’un 2-joint de T. Si a ∈ A0 2 et b ∈ C 0 2 , alors (A0 1 , B0 1 , C0 1 , A2 ∪ A0 2 \ {a}, B0 2 , B2 ∪ C2 ∪ C 0 2 \ {b, c}) est une affectation d’un 2-joint de T. Si a ∈ C 0 2 et b ∈ C 0 2 , alors (A0 1 , B0 1 , C0 1 , A0 2 , B0 2 , X2 ∪ C 0 2 \ {a, b, c}) est une affectation d’un 2-joint de T. D’après le lemme 6.2 et le lemme 2.9 tous ces 2-joints sont propres, et nous avons donc une contradiction. Supposons que TX admette un complément de 2-joint propre (X0 1 , X0 2 ). Puisque c n’a pas de voisin fort nous avons une contradiction. Case 3 : (X, V (T) \ X) est un 2-joint propre (X1, X2) de T, avec X = X1. Soit (A1, B1, C1, A2, B2, C2) une affectation de (X, V (T) \ X). Supposons que TX admette un 2-joint propre (X0 1 , X0 2 ). Soit 846.2. CALCULER UNE FIN (A0 1 , B0 1 , C0 1 , A0 2 , B0 2 , C0 2 ) une affectation de (X0 1 , X0 2 ). Puisque ab est une arête optionnelle, on peut supposer que a, b ∈ X0 2 . Maintenant nous affirmons que (X0 1 , V (T) \ X0 1 ) est un 2-joint propre de T, ce qui est une contradiction, car X0 2 ne peut pas être réduit à seulement {a, b} (d’après la définition d’un 2-joint), donc X0 1 est strictement inclus dans X. Comme a et b n’ont pas de voisin fort commun dans TX1 , il y a à symétrie près seulement trois cas : ou bien a ∈ A0 2 , b ∈ B0 2 , ou bien a ∈ A0 2 , b ∈ C 0 2 , ou bien a, b ∈ C 0 2 . Si a ∈ A0 2 et b ∈ B0 2 , alors (A0 1 , B0 1 , C0 1 , A2 ∪ A0 2 \ {a}, B2 ∪ B0 2 \ {b}, C2 ∪ C 0 2 ) est une affectation d’un 2-joint de T. Si a ∈ A0 2 et b ∈ C 0 2 , alors (A0 1 , B0 1 , C0 1 , A2 ∪ A0 2 \ {a}, B0 2 , B2 ∪ C2 ∪ C 0 2 \ {b}) est une affectation d’un 2-joint de T. Si a ∈ C 0 2 et b ∈ C 0 2 , alors (A0 1 , B0 1 , C0 1 , A0 2 , B0 2 , X2∪C 0 2 \{a, b}) est une affectation d’un 2-joint de T. D’après le lemme 6.2 et le lemme 2.9 tous ces 2-joints sont propres, et nous avons donc une contradiction. Supposons que TX admette un complément de 2-joint propre (X0 1 , X0 2 ). Soit (A0 1 , B0 1 , C0 1 , A0 2 , B0 2 , C0 2 ) une affectation de (X0 1 , X0 2 ). Puisque ab est une arête optionnelle, on peut supposer que a, b ∈ X0 2 . Puisque a et b n’ont pas de voisin fort commun, on peut supposer que a ∈ A0 2 , b ∈ B0 2 et C 0 1 = ∅. Si C2 et C 0 2 sont nonvides, alors (A0 1 , B0 1 , B2 ∪ B0 2 \ {b}, A2 ∪ A0 2 \ {a}, C0 2 , C2) est une affectation d’une paire homogène propre de T et A0 1 ∪ B0 1 est strictement inclus dans X, c’est une contradiction (remarquons que d’après le lemme 6.2 et le lemme 2.9, |A0 1 | ≥ 2, |B0 1 | ≥ 2, et tout sommet de A0 1 a un voisin et un antivoisin dans B0 1 et vice versa). Si C2 est non-vide et que C 0 2 est vide, alors (A0 1 , B0 1 , ∅, B2∪B0 2\{b}, A2∪A0 2\{a}, C2) est une affectation d’un 2-joint propre de T (il est propre d’après le lemme 6.2 et le lemme 2.9). Si C2 est vide, alors (A0 1 , B0 1 , ∅, A2 ∪ A0 2 \ {a}, B2 ∪ B0 2 \ {b}, C0 2 ) est une affectation d’un complément de 2-join de T (ici encore il est propre d’après le lemme 6.2 et le lemme 2.9). 6.2 Calculer une fin Le but de cette section est de donner un algorithme polynomial qui étant donné un trigraphe, calcule une fin s’il en existe une. Pour résoudre ce problème nous pourrions utiliser les algorithmes existants de détection de 2-joint et de paire homogène. Le plus rapide est dans [7] pour les 2-joints et dans [24] pour les paires homogènes. Cependant cette approche pose plusieurs problèmes. Premièrement ces algorithmes fonctionnent pour les graphes et non pour les trigraphes. Il est 85CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES cependant possible de les adapter pour les faire fonctionner sur les trigraphes. Cependant il est difficile de démontrer que cette conversion des graphes aux trigraphes est correcte sans rentrer dans les détails des algorithmes. Le problème plus grave est que ces algorithmes calculent un fragment et non une fin. En fait pour les 2-joints l’algorithme de [7] calcule un ensemble X minimal pour l’inclusion tel que (X, V (G)\X) est un 2-joint, mais il peut toujours y avoir une paire homogène dans X. Pour régler ces deux problèmes nous donnons ici notre propre algorithme même si la plupart des idées de cet algorithme existaient déjà dans des travaux précédents. Notre algorithme cherche un fragment propre X. À cause de tous les points techniques des définitions des 2-joints et des paires homogènes, nous introduisons une nouvelle notion. Un fragment faible d’un trigraphe T est un ensemble X ⊆ V (T) tel qu’il existe des ensembles disjoints A1, B1, C1, D1, A2, B2, C2, D2 vérifiant : — X = A1 ∪ B1 ∪ C1 ∪ D1 ; — V (T) \ X = A2 ∪ B2 ∪ C2 ∪ D2 ; — A1 est fortement complet à A2 ∪ D2 et fortement anticomplet à B2 ∪ C2 ; — B1 est fortement complet à B2 ∪ D2 et fortement anticomplet à A2 ∪ C2 ; — C1 est fortement anticomplet à A2 ∪ B2 ∪ C2 ; — D1 est fortement anticomplet à A2 ∪ B2 ∪ D2 ; — |X| ≥ 4 et |V (T) \ X| ≥ 4 ; — |Ai | ≥ 1 et |Bi | ≥ 1, i = 1, 2 ; — et au moins une des propriétés suivantes est vérifiée : — C1 = D1 = ∅, C2 6= ∅, et D2 6= ∅, ou — D1 = D2 = ∅, ou — C1 = C2 = ∅. Dans ces circonstances, on dit que (A1, B1, C1, D1, A2, B2, C2, D2) est une affectation de X. Étant donné un fragment faible, on dit qu’il est de type paire homogène si C1 = D1 = ∅, C2 6= ∅, et D2 6= ∅, de type 2-joint si D1 = D2 = ∅ et de type complément de 2-joint si C1 = C2 = ∅. Remarquons qu’un fragment peut être à la fois de type 2-joint et de type complément de 2-joint (lorsque C1 = D1 = C2 = D2 = ∅). Théorème 6.4. Si T est un trigraphe de Berge apprivoisé, alors X est un fragment faible de T si et seulement si X est un fragment propre de T. Démonstration. Si X est un fragment propre, alors c’est clairement un fragment faible (les conditions |X| ≥ 4 et |V (T) \ X| ≥ 4 sont satisfaites lorsque X est un côté d’un 2-joint d’après le lemme 2.9). Prouvons l’autre sens de l’équivalence. Soit 866.2. CALCULER UNE FIN X un fragment faible et soit (A1, B1, C1, D1, A2, B2, C2, D2) une affectation de X. Si X est de type 2-joint ou complément de 2-joint, alors il est propre d’après le lemme 2.9. Par conséquent nous n’avons à traiter que le cas du fragment faible de type paire homogène et donc C1 = D1 = ∅, C2 6= ∅, et D2 6= ∅. Puisque les quatre ensembles A1, A2, B1, B2 sont tous non-vides, il suffit de vérifier que les conditions suivantes sont vérifiées : (i) Tout sommet de A1(B1) a un voisin et un antivoisin dans B1(A1). (ii) |A1| > 1 et |B1| > 1. Supposons que la condition (i) n’est pas vérifiée. En prenant le complémentaire de T si nécessaire, on peut supposer qu’il existe un sommet v ∈ A1 fortement complet à B1. Puisque {v} ∪ B1 ∪ A2 ∪ D2 n’est pas un star cutset dans T d’après le lemme 2.6, on a que A1 = {v}. Maintenant tout sommet de B1 est fortement complet à A1, et donc par le même argument, |B1| = 1. Ceci contredit l’hypothèse que |X| ≥ 4. Par conséquent la propriété (i) est vérifiée. Pour démontrer (ii) supposons que |A1| = 1. Puisque |X| ≥ 4, on a que |B1| ≥ 3. D’après (i), tout sommet de B1 est semi-adjacent à un unique sommet de A1, ce qui est impossible puisque |B1| ≥ 3 et que T est un trigraphe bigame. Par conséquent la propriété (ii) est vérifiée. Un quadruplet (a1, b1, a2, b2) de sommets d’un trigraphe T est propre s’il vérifie les propriétés suivantes : — a1, b1, a2, b2 sont deux à deux distincts ; — a1a2, b1b2 ∈ E(T); — a1b2, b1a2 ∈ E(T). Un quadruplet propre (a1, b1, a2, b2) est compatible avec un fragment faible X s’il existe une affectation (A1, B1, C1, D1, A2, B2, C2, D2) de X telle que a1 ∈ A1, b1 ∈ B1, a2 ∈ A2 et b2 ∈ B2. Nous utilisons les notations suivantes. Si x est un sommet d’un trigraphe T, N(x) désigne l’ensemble des voisins de x, N(x) l’ensemble des antivoisins de x, E(x) l’ensemble des voisins forts de x, et E ∗ (x) l’ensemble des sommets v tels que xv ∈ E ∗ (T). 87CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES Théorème 6.5. Soit T un trigraphe et Z = (a1, b1, a2, b2) un quadruplet propre de T. Il y a un algorithme en temps O(n 2 ) qui étant donné un ensemble R0 ⊆ V (T) de taille au moins 4 tel que Z ∩ R0 = {a1, b1}, trouve un fragment faible X compatible avec Z et tel que R0 ⊆ X, ou renvoie la propriété vraie suivante : “Il n’existe pas de fragment faible X compatible avec Z et tel que R0 ⊆ X” De plus le fragment trouvé X est minimal vis à vis de ces propriétés. C’est 886.2. CALCULER UNE FIN à dire que X ⊂ X0 pour tout fragment faible X0 vérifiant ces propriétés. Démonstration. Nous utilisons la procédure décrite dans la table 6.1. Elle essaie de construire un fragment faible R, en commençant avec R = R0 et S = V (T) \ R0, Ensuite plusieurs règles de forçage sont implémentées, disant que certains ensembles de sommets doivent être déplacés de S vers R. La variable “State” contient le type du fragment faible en train d’être considéré. Au début de la procédure le type n’est pas connu et la variable “State” contient “Unknown”. Il est facile de vérifier que les propriétés suivantes sont des invariants d’exécution (c’est à dire qu’elles sont vérifiées après chaque appel à Explore) : — R et S forment une partition de V (T), R0 ⊆ R et a2, b2 ∈ S. — Pour tout sommet v ∈ R non-marqué et tout sommet u ∈ S, uv n’est pas une arête optionnelle. — Tous les sommets non-marqués appartenant à R ∩ (E(a2) \ E(b2)) ont le même voisinage dans S, c’est à dire A (et A est un voisinage fort). — Tous les sommets non-marqués appartenant à R ∩ (E(b2) \ E(a2)) ont le même voisinage dans S, c’est à dire B (et B est un voisinage fort). — Tous les sommets non-marqués appartenant à R ∩ (E(b2) ∩ E(a2)) ont le même voisinage dans S, c’est à dire A ∪ B. — Tous les sommets non-marqués appartenant à R et non-adjacent ni à a2 ni à b2 sont fortement anticomplet à S. — Pour tout fragment faible X tel que R0 ⊆ X et a2, b2 ∈ V (T) \ X, on a que R ⊆ X et V (T) \ X ⊆ S. D’après le dernier point, tous les déplacements de sommets de S vers R sont nécessaires. Donc si un sommet de R est fortement adjacent à a2 et à b2, n’importe quel fragment faible compatible avec Z qui contient R doit être un fragment faible de type complément de 2-joint. C’est pourquoi la variable “State” est alors assignée avec la valeur 2-joint et que tous les sommets de S \ (A ∪ B) sont déplacés vers R. De la même manière, si un sommet de R est fortement antiadjacent à a2 et à b2, n’importe quel fragment faible compatible avec Z qui contient R doit être un fragment faible de type 2-joint. C’est pourquoi la variable “State” est alors assignée à la valeur 2-joint et que tous les sommets de A ∩ B sont déplacés vers R. Lorsque State = “2-joint” et qu’un sommet de R est à la fois fortement adjacent à a2 et à b2, il y a une contradiction avec la définition du complément de 2-joint, donc l’algorithme doit s’arrêter. Lorsque State = 2-joint et qu’un sommet de R est à la fois fortement adjacent à a2 et à b2, il y a une contradiction avec la définition du 2-joint donc l’algorithme doit s’arrêter. Lorsque la fonction Move essaie de déplacer a2 ou b2 dans R (ceci peut arriver si un sommet dans R est semiadjacent 89CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES Entrée : R0 un ensemble de sommets d’un trigraphe T et un quadruplet propre Z = (a1, b1, a2, b2) tel que a1, b1 ∈ R0 and a2, b2 ∈/ R0. Initialisation : R ← R0 ; S ← V (T) \ R0 ; A ← E(a1) ∩ S ; B ← E(b1) ∩ S ; State ← Unknown ; Les sommets a1, b1, a2, b2 sont laissés non-marqués. Pour les autres sommets de T : Mark(x) ← αβ pour tout sommet x ∈ E(a2) ∩ E(b2); Mark(x) ← α pour tout sommet x ∈ E(a2) \ E(b2); Mark(x) ← β pour tout sommet x ∈ E(b2) \ E(a2); tous les autres sommets de T sont marqués par ε ; Move(E ∗ (a1) ∩ S); Move(E ∗ (b1) ∩ S); Boucle principale : Tant que il existe un sommet x ∈ R marqué Faire Explore(x); Unmark(x); Fonction Explore(x) : Si Mark(x) = αβ et State = Unknown alors State ← 2-joint, Move(S \ (A ∪ B)); Si Mark(x) = αβ et State = 2-joint alors Move(N(x) ∩ S); Si Mark(x) = αβ et State = 2-joint alors Sortie Pas de fragment faible trouvé, Stop ; Si Mark(x) = α alors Move(A∆(E(x) ∩ S)), Move(E ∗ (x) ∩ S); Si Mark(x) = β alors Move(B∆(E(x) ∩ S)), Move(E ∗ (x) ∩ S); Si Mark(x) = ε et State = Unknown alors State ← 2-joint, Move(A ∩ B); Si Mark(x) = ε et State = 2-joint alors Move(N(x) ∩ S); Si Mark(x) = ε et State = 2-joint alors Sortie Pas de fragment faible trouvé, Stop ; Fonction Move(Y) : Cette fonction déplace simplement un sous-ensemble Y ⊂ S de S vers R. Si Y ∩ {a2, b2} 6= ∅ alors Sortie Pas de fragment faible trouvé, Stop ; R ← R ∪ Y ; A ← A \ Y ; B ← B \ Y ; S ← S \ Y ; Table 6.1 – La procédure utilisée dans le théorème 6.5 906.2. CALCULER UNE FIN à a2 et à b2), alors R ne peut pas être contenu dans un fragment compatible avec Z. Si le processus ne s’arrête pas pour une des raisons ci-dessus, alors tous les sommets de R ont été explorés et donc sont non-marqués. Donc, si |S| ≥ 4 à la fin, R est un fragment faible compatible avec Z. Plus spécifiquement, (R∩(E(a2)\ E(b2)), R ∩(E(b2) \ E(a2)), R \ (E(a2)∪ E(b2)), R ∩(E(a2)∩ E(b2)), A \ B, B \ A, S \ (A ∪ B), A ∩ B) est une affectation du fragment faible R. Puisque tous les déplacements de S vers R sont nécessaires, le fragment est minimal comme affirmé. Cela implique également que si |S| ≤ 3, alors il n’existe pas de fragment faible vérifiant les propriétés, dans ce cas l’algorithme renvoie qu’il n’existe pas de fragment vérifiant les propriétés requises. Complexité : Le voisinage et l’antivoisinage d’un sommet de R n’est considéré qu’au plus une fois. Donc, globalement l’algorithme utilise un temps O(n 2 ). Théorème 6.6. Il existe un algorithme fonctionnant en temps O(n 5 ), qui prend en entré un trigraphe T de Berge apprivoisé, et qui renvoie une fin X de T (si une fin existe) et le bloc de décomposition TX. Démonstration. Rappelons que d’après le lemme 6.4, les fragments faibles de T sont des fragments propres. Nous commençons par décrire un algorithme de complexité O(n 8 ), nous expliquerons ensuite comment l’accélérer. Nous supposons que |V (T)| ≥ 8 car sinon il n’existe pas de fragment propre. Pour tout quadruplet propre Z = (a1, a2, b1, b2) et pour toute paire de sommets u, v de V (T) \ {a1, a2, b1, b2}, nous appliquons le lemme 6.5 à R0 = {a1, b1, u, v}. Cette méthode détecte pour tout Z et tout u, v un fragment propre (s’il en existe) compatible avec Z, contenant u, v et minimal vis à vis de ces propriétés. Parmi tous ces fragments, nous choisissons celui de cardinalité minimum, c’est une fin. Une fois que la fin est donnée, il est facile de connaitre le type de décomposition utilisé et de construire le bloc correspondant (en utilisant en particulier, le lemme 2.4, on peut simplement tester avec un chemin si le 2-joint est pair ou impair). Voyons maintenant comment accélérer cet algorithme. Nous traitons séparément le cas du 2-joint et de la paire homogène. Nous allons décrire un algorithme en temps O(n 5 ) qui renvoie un fragment faible de type 2-joint, un algorithme en temps O(n 5 ) qui renvoie un fragment faible de type complément de 2-joint et un algorithme en temps O(n 5 ) qui renvoie un fragment faible 91CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES de type paire homogène. Chacun de ces fragments sera de cardinalité minimum parmi tous les fragments faibles du même type. Par conséquent, le fragment de cardinalité minimum parmi ces trois fragments sera une fin. Commençons par traiter le cas des 2-joints. Un ensemble Z de quadruplets propres est universel, si pour tout 2-joint propre d’affectation (A1, B1, C1, A2, B2, C2), il existe (a1, a2, b1, b2) ∈ Z tel que a1 ∈ A1, a2 ∈ A2, b1 ∈ B1, b2 ∈ B2. Au lieu de tester tous les quadruplets comme dans la version en O(n 8 ) de notre algorithme, il est clairement suffisant de restreindre notre recherche à un ensemble universel de quadruplet. Comme prouvé dans [7], il existe un algorithme qui génère en temps O(n 2 ) un ensemble universel de quadruplet de taille au plus O(n 2 ) pour n’importe quel graphe. Il est facile d’obtenir un algorithme similaire pour les trigraphes. L’idée suivante pour les 2-joints est d’appliquer la méthode de la Table 6.1 à R0 = {a1, b1, u} pour tout sommet u au lieu de l’appliquer pour R0 = {a1, b1, u, v} pour tout couple de sommets u, v. Comme nous allons le voir ceci trouve un 2- joint compatible avec Z = (a1, a2, b1, b2) s’il en existe un. Supposons que (X1, X2) soit un tel 2-joint. Si X1 contient un sommet u dont le voisinage (dans T) est différent de N(a1)∪N(b1), alors d’après le lemme 2.9, u a au moins un voisin dans X1 \{a1, b1}. Donc quand la boucle considère u, la méthode de la Table 6.1 déplace de nouveaux sommets dans R. Donc, à la fin, |R| ≥ 4 et le 2-joint est détecté. Par conséquent, l’algorithme échoue à détecter un 2-joint uniquement dans le cas où u a degré 2 et a1-v-b1 est un chemin alors qu’il existe un 2-joint compatible avec Z avec u du même côté que a1 et b1. En fait, puisque tous les sommets sont essayés, ce n’est un problème que s’il apparait pour tout choix possible de u. C’est à dire si le 2-joint cherché a un côté fait de a1, b1, et d’un ensemble de sommets u1, . . . , uk de degré 2 tous adjacents à la fois à a1 et à b1. Mais dans ce cas, ou bien un des ui est fortement complet à {a1, b1} et c’est le centre d’un star cutset, ou bien tous les ui sont adjacents à un des sommets a1 ou b1 par une arête optionnelle. Dans ce cas tous les ui sont déplacés vers R lorsque nous appliquons les règles décrites par la Table 6.1, et donc le 2-joint est en fait bien détecté. Les compléments de 2-joints sont traités de la même manière dans le complé- ment. Considérons maintenant les paires homogènes. Il est utile de définir une paire homogène faible exactement comme les paires homogènes propres, à l’exception que nous demandons que “|A| ≥ 1, |B| ≥ 1 et |A ∪ B| ≥ 3” au lieu de “|A| > 1 et |B| > 1”. Un lemme similaire au lemme 6.5 existe pour lequel l’entrée de l’algorithme est un graphe G, un triplet (a1, b1, a2) ∈ V (G) 3 et un ensemble R0 ⊆ 926.2. CALCULER UNE FIN V (G) qui contient a1, b1 mais pas a2, et dont la sortie est une paire homogène faible (A, B) telle que R0 ⊆ A ∪ B, a1 ∈ A, b1 ∈ B et a2 ∈/ A ∪ B, et telle que a2 est complet à A et anticomplet à B, si une telle paire homogène faible existe. Comme dans le lemme 6.5, le temps d’exécution est O(n 2 ) et la paire homogène faible est minimale parmi toutes les paires homogènes faibles possibles. Ce résultat est prouvé dans [17]. Comme pour les 2-joints, nous définissons la notion d’ensemble universel de triplets (a1, b1, a2). Comme prouvé dans [24], il existe un algorithme qui génère en temps O(n 2 ) un ensemble universel de triplet de taille au plus O(n 2 ) pour n’importe quel graphe. Ici encore il est facile d’adapter cet algorithme pour les trigraphes. Comme dans le cas du 2-joint, nous appliquons un lemme analogue au lemme 6.5 à tous les sommets u au lieu de tous les couples de sommets u, v. Le seul problème est qu’après l’appel au lemme similaire au lemme 6.5, nous avons une paire homogène faible et pas propre (donc |A ∪ B| = 3). Mais dans ce cas on peut vérifier qu’alors le trigraphe contient un star cutset ou un star cutset dans son complément. Nous avons vu dans ce chapitre comment étendre notre ensemble de décompositions afin d’assurer l’existence d’une décomposition extrême. Nous avons également donné un algorithme polynomial permettant d’exhiber une telle décomposition. Nous n’avons pas eu besoin de ce type de décomposition pour prouver le reste des résultats de cette thèse, mais savoir qu’elle existe donne une preuve conceptuellement plus simple des résultats concernant le calcul du stable maximum. En effet, si l’on sait qu’à chaque étape de décomposition un des côtés est basique on peut facilement calculer les valeurs qui nous intéressent dans ce coté sans craindre d’explosion combinatoire, de fait la récursion devient presque immé- diatement récursive terminale. Malheureusement, la preuve est techniquement plus compliquée puisqu’il faut également traiter les cas des paires homogènes. Il n’est pas possible de transformer automatique un théorème de décomposition en son équivalent extrême (cf la figure 6.1). Il serait intéressant de savoir s’il est toujours possible d’ajouter des décompositions (et comment les calculer) pour obtenir une décomposition extrême. 93CHAPITRE 6. DÉCOMPOSITIONS EXTRÊMES 94Chapitre 7 Conclusion Dans cette thèse, nous avons démontré un certain nombre de résultats sur les trigraphes de Berge apprivoisés et par conséquent sur les graphes de Berge sans skew-partition. En fait, le point important dans tous ces résultats est de pouvoir décomposer le graphe par 2-joint ou complémentaire de 2-joint. L’interdiction des skew-partitions permet simplement d’assurer que le graphe ou son complémentaire admet bien un 2-joint et que les blocs vont eux aussi être inductivement décomposables. La classe la plus générale pour laquelle ces résultats s’appliquent est donc celle des graphes de Berge décomposables par 2-joint ou complémentaire de 2-joint. Malheureusement cette classe est une sous-classe stricte des graphes de Berge, le graphe en figure 2.8 est un graphe de Berge qui (en utilisant les décompositions mentionnées dans cette thèse) n’est décomposable que par skew-partition. La reconnaissance des graphes de Berge apprivoisés est possible en temps polynomial, mais est compliquée. En toute généralité la détection de skew-partition équilibrée est un problème NP-complet heureusement ce problème devient polynomial sur les graphes de Berge [35]. On peut donc utiliser l’algorithme de Chudnovsky, Cornuéjols, Liu, Seymour et Vušković [12] pour s’assurer que le graphe est bien de Berge puis on peut utiliser les résultats de Trotignon [35] pour s’assurer que le graphe ne possède pas de skew-partition équilibrée. Avec ces résultats il est alors possible, étant donné un graphe quelconque de le colorier en temps polynomial ou d’assurer que ce n’est pas un graphe de Berge sans skew-partition. La reconnaissance de la classe plus large des graphes de Berge totalement décomposable par 2-joint et complémentaire de 2-joint est plus difficile. On peut chercher décomposer jusqu’à arriver sur des blocs basiques, mais en cas d’échec, a priori rien ne garantit qu’en ayant choisi un autre 2-joint nous n’aurions pas pu le décomposer totalement. 95CHAPITRE 7. CONCLUSION Notre classe est auto-complémentaire mais pas héréditaire, ce qui peut paraître surprenant pour les personnes familières avec les graphes de Berge. Il est assez difficile de trouver une classe proche qui soit héréditaire. De manière artifi- cielle, ce serait la classe des graphes de Berge sans sous-graphe induit uniquement décomposable par skew-partition (en utilisant comme ensemble de décompositions celles présentées dans cette thèse), en particulier il faut interdire le graphe de la figure 2.8. Il faudrait alors vérifier que les blocs de décompositions restent dans la classe. Dans ce cas cette classe serait alors totalement décomposable par 2-joint et par complémentaire de 2-joint et tous les résultats de cette thèse s’appliqueraient. Une manière d’étendre ces résultats serait de réussir pour un graphe de Berge donné à lui ajouter des sommets pour le rendre sans skew-partition. Dans ce cas en affectant des poids nuls à ces sommets ajoutés il est possible d’utiliser l’algorithme de stable maximum pondéré présenté ici pour calculer un stable maximum du graphe de départ. Pour que cet algorithme reste un algorithme en temps polynomial il faut que le nombre de sommets à ajouter soit polynomial en la taille du graphe de départ. Le risque d’une telle méthode est bien sûr que les sommets ajoutés créent de nouvelles skew-partition. Si ces résultats ne permettent pas de résoudre le problème pour les graphe de Berge en général, ils peuvent néanmoins fournir des outils utiles. En effet pour ces problèmes, on peut désormais voir notre classe comme une classe basique. De futurs algorithmes pourraient donc traiter les graphe de Berge tant qu’ils admettent des skew-partition puis utiliser nos algorithmes. Enfin le problème ouvert qui est sans doute le plus intéressant est celui de la reconnaissance des trigraphes de Berge. Ce problème est résolu pour les graphes [12] mais est toujours ouvert pour les trigraphes. Étant donné l’intérêt de l’utilisation des trigraphes pour l’étude des graphes de Berge, il serait très intéressant de savoir reconnaître les trigraphes de Berge. De manière plus générale, si l’on définit une classe de trigraphe C ∗ à partir de la classe de graphe C de la manière suivante : Un trigraphe T est dans la classe C ∗ si et seulement si toutes ses réalisations sont dans la classe C, quel est le lien entre la reconnaissance de la classe C et celle de la la classe C ∗ . 96Bibliographie [1] Pierre Aboulker, Marko Radovanović, Nicolas Trotignon, Théophile Trunck et Kristina Vušković : Linear balanceable and subcubic balanceable graphs. Journal of Graph Theory, 75(2):150–166, 2014. [2] Boris Alexeev, Alexandra Fradkin et Ilhee Kim : Forbidden induced subgraphs of double-split graphs. SIAM Journal on Discrete Mathematics, 26(1):1–14, 2012. [3] Noga Alon, János Pach, Rom Pinchasi, Radoš Radoičić et Micha Sharir : Crossing patterns of semi-algebraic sets. Journal of Combinatorial Theory, Series A, 111(2):310–326, 2005. [4] Nicolas Bousquet, Aurélie Lagoutte et Stéphan Thomassé : Clique versus independent set. arXiv preprint arXiv :1301.2474, 2013. [5] Nicolas Bousquet, Aurélie Lagoutte et Stéphan Thomassé : The ErdősHajnal conjecture for paths and antipaths. arXiv preprint arXiv :1303.5205, 2013. [6] Binh-Minh Bui-Xuan, Jan Arne Telle et Martin Vatshelle : H-join decomposable graphs and algorithms with runtime single exponential in rankwidth. Discrete Applied Mathematics, 158(7):809–819, 2010. [7] Pierre Charbit, Michel Habib, Nicolas Trotignon et Kristina Vušković : Detecting 2-joins faster. Journal of discrete algorithms, 17:60–66, 2012. [8] Maria Chudnovsky : Berge trigraphs and their applications. Thèse de doctorat, Princeton University, 2003. [9] Maria Chudnovsky : Berge trigraphs. Journal of Graph Theory, 53(1):1–55, 2006. [10] Maria Chudnovsky : The structure of bull-free graphs II and III—A summary. Journal of Combinatorial Theory, Series B, 102(1):252–282, 2012. 97BIBLIOGRAPHIE [11] Maria Chudnovsky : The structure of bull-free graphs I—Three-edge-paths with centers and anticenters. Journal of Combinatorial Theory, Series B, 102(1):233–251, 2012. [12] Maria Chudnovsky, Gérard Cornuéjols, Xinming Liu, Paul Seymour et Kristina Vušković : Recognizing berge graphs. Combinatorica, 25(2):143– 186, 2005. [13] Maria Chudnovsky, Neil Robertson, Paul Seymour et Robin Thomas : The strong perfect graph theorem. Annals of Mathematics, pages 51–229, 2006. [14] Maria Chudnovsky et Paul D Seymour : The structure of claw-free graphs. Surveys in combinatorics, 327:153–171, 2005. [15] Maria Chudnovsky, Nicolas Trotignon, Théophile Trunck et Kristina Vuskovic : Coloring perfect graphs with no balanced skew-partitions. arXiv preprint arXiv :1308.6444, 2013. [16] Vasek Chvátal : Star-cutsets and perfect graphs. Journal of Combinatorial Theory, Series B, 39(3):189–199, 1985. [17] Hazel Everett, Sulamita Klein et Bruce Reed : An algorithm for finding homogeneous pairs. Discrete Applied Mathematics, 72(3):209–218, 1997. [18] Tomás Feder, Pavol Hell, David G Schell et Juraj Stacho : Dichotomy for tree-structured trigraph list homomorphism problems. Discrete Applied Mathematics, 159(12):1217–1224, 2011. [19] Tomás Feder, Pavol Hell et Kim Tucker-Nally : Digraph matrix partitions and trigraph homomorphisms. Discrete Applied Mathematics, 154(17):2458–2469, 2006. [20] Samuel Fiorini, Serge Massar, Sebastian Pokutta, Hans Raj Tiwary et Ronald de Wolf : Linear vs. semidefinite extended formulations : exponential separation and strong lower bounds. In Proceedings of the 44th symposium on Theory of Computing, pages 95–106. ACM, 2012. [21] Jacob Fox : A bipartite analogue of Dilworth’s theorem. Order, 23(2-3):197– 209, 2006. [22] Jacob Fox et János Pach : Erdős-Hajnal-type results on intersection patterns of geometric objects. In Horizons of combinatorics, pages 79–103. Springer, 2008. [23] Martin Grötschel, László Lovász et Alexander Schrijver : Geometric algorithms and combinatorial optimization. 1988. 98BIBLIOGRAPHIE [24] Michel Habib, Antoine Mamcarz et Fabien de Montgolfier : Algorithms for some H-join decompositions. In LATIN 2012 : Theoretical Informatics, pages 446–457. Springer, 2012. [25] Peter L Hammer et Bruno Simeone : The splittance of a graph. Combinatorica, 1(3):275–284, 1981. [26] Aurélie Lagoutte et Théophile Trunck : Clique-stable set separation in perfect graphs with no balanced skew-partitions. arXiv preprint arXiv :1312.2730, 2013. [27] Philippe GH Lehot : An optimal algorithm to detect a line graph and output its root graph. Journal of the ACM (JACM), 21(4):569–575, 1974. [28] Lásló Lovász : A characterization of perfect graphs. Journal of Combinatorial Theory, Series B, 13(2):95–98, 1972. [29] László Lovász : On the shannon capacity of a graph. Information Theory, IEEE Transactions on, 25(1):1–7, 1979. [30] László Lovász : Stable sets and polynomials. Discrete mathematics, 124(1): 137–153, 1994. [31] Frédéric Maffray : Fast recognition of doubled graphs. Theoretical Computer Science, 516:96–100, 2014. [32] Nicholas D Roussopoulos : A max(n, m) algorithm for determining the graph H from its line graph G. Information Processing Letters, 2(4):108–112, 1973. [33] Alexander Schrijver : Combinatorial optimization : polyhedra and effi- ciency, volume 24. Springer, 2003. [34] Paul Seymour : How the proof of the strong perfect graph conjecture was found. Gazette des Mathematiciens, 109:69–83, 2006. [35] Nicolas Trotignon : Decomposing berge graphs and detecting balanced skew partitions. Journal of Combinatorial Theory, Series B, 98(1):173–225, 2008. [36] Nicolas Trotignon : Perfect graphs : a survey. arXiv preprint arXiv :1301.5149, 2013. [37] Nicolas Trotignon et Kristina Vušković : Combinatorial optimization with 2-joins. Journal of Combinatorial Theory, Series B, 102(1):153–185, 2012. 99BIBLIOGRAPHIE [38] Mihalis Yannakakis : Expressing combinatorial optimization problems by linear programs. In Proceedings of the twentieth annual ACM symposium on Theory of computing, pages 223–228. ACM, 1988. 100 Reconnaissance de comportements complexes par traitement en ligne de flux d’ev`enements Ariane Piel To cite this version: Ariane Piel. Reconnaissance de comportements complexes par traitement en ligne de flux d’ev`enements. Computer Science. Universit´e Paris Nord - Paris 13, 2014. French. HAL Id: tel-01093015 https://hal.archives-ouvertes.fr/tel-01093015 Submitted on 9 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Université Paris 13 Thèse pour obtenir le grade de Docteur de l’Université Paris 13 Discipline : Informatique présentée et soutenue publiquement par Ariane PIEL le 27 octobre 2014 à l’Office National d’Études et de Recherches Aérospatiales Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements (Online Event Flow Processing for Complex Behaviour Recognition) Jury Présidente : Laure Petrucci Professeur, Université Paris 13 Rapporteurs : Serge Haddad Professeur, École Normale Supérieure de Cachan Audine Subias Maître de conférences, HDR, Institut National des Sciences Appliquées de Toulouse Examinateurs : Philippe Bidaud Professeur, Université Paris 6 – Pierre et Marie Curie Christine Choppy Professeur, Université Paris 13 Romain Kervarc Docteur ingénieur, Onera Invités : Jean Bourrely Docteur ingénieur, Onera Patrice Carle Docteur ingénieur, Onera Directrice de thèse : Christine Choppy Encadrants Onera : Romain Kervarc, avec Jean Bourrely et Patrice Carle Laboratoires : Office National d’Études et de Recherches Aérospatiales Laboratoire d’Informatique de Paris Nord N◦ d’ordre :Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements 2Remerciements Nombreux sont ceux qui ont contribué à l’aboutissement de cette thèse, et je souhaite à présent les remercier très sincèrement. Cette thèse s’est déroulée à l’Onera au sein du Département de Conception et évaluation des Performances des Systèmes (DCPS). Je tiens à remercier Thérèse Donath, directrice du département, de m’avoir accueillie et de m’avoir permis de réaliser ces travaux dans un environnement stimulant au sein de l’Onera. Je souhaite vivement remercier l’Unité de Techniques pour la Conception et la Simulation de systèmes (TCS) dans laquelle j’ai été chaleureusement intégrée. Je remercie Christine Choppy, Professeur à l’Université Paris 13, d’avoir dirigé ma thèse durant ces trois années avec tant d’implication et de disponibilité. Son sens de l’organisation et sa ténacité nous a permis d’entreprendre de nombreux projets. Je garde un excellent souvenir d’un workshop organisé à Singapour où nous avons pu allier les plaisirs de la recherche et ceux des voyages. Je suis très reconnaissante envers Romain Kervarc, ingénieur-chercheur à l’Onera, d’avoir coencadré cette thèse et de m’avoir toujours soutenue tant sur les idées que sur la forme où nous nous retrouvions entre logiciens. Je remercie aussi Romain de m’avoir offert de nombreuses opportunités pour rencontrer des chercheurs à travers le monde, et de m’avoir accordé sa confiance, laissant ainsi libre cours à la poursuite de mes idées. J’exprime toute ma gratitude à Patrice Carle, chef de l’unité TCS, pour m’avoir aidée sur tous les aspects de ce travail, avec des remarques toujours pertinentes. L’expérience et le recul sur le sujet qu’a apportés Patrice allaient de pair avec un enthousiasme débordant, ce qui a su avoir raison de mes doutes et de mon regard parfois trop critique. Sa certitude dans la qualité et l’intérêt de notre projet a été d’un grand soutien. Je tiens à remercier tout particulièrement Jean Bourrely, ancien directeur adjoint du DCPS, pour sa clairvoyance et son sens pratique dans tous les moments de questionnement, et pour son aide incommensurable dans l’implémentation de CRL. Les nombreuses heures de travail en commun m’ont donné l’énergie et la stimulation nécessaires à l’aboutissement de cette thèse et comptent dans les instants qui resteront parmi les meilleurs de ces trois ans. J’exprime toute ma gratitude à Serge Haddad, Professeur à l’École Normale Supérieure de Cachan, et à Audine Subias, Maître de Conférences habilité à l’Institut National des Sciences Appliquées de Toulouse, pour m’avoir honorée d’être les rapporteurs de cette thèse. Leurs remarques ont été précieuses pour l’amélioration de ce travail et ont ouvert quantité de nouvelles perspectives. 3Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Je souhaite étendre cette gratitude à Laure Petrucci, Professeur à l’Université Paris 13, et à Philippe Bidaud, Professeur à l’Université Paris 6, pour m’avoir suivie durant ces trois années puis avoir accepté de participer au jury de cette thèse. Mes remerciements vont également à Thibault Lang qui m’a généreusement aidée dans le développement des cas d’application traités dans cette thèse, et à Nicolas Huynh pour sa contribution à leur mise en place. J’adresse aussi mes profonds remerciements à Stéphanie Prudhomme pour l’atmosphère chaleureuse qu’elle sait entretenir au sein de l’unité TCS, et pour ses conseils avisés. Je dois beaucoup à mes collègues et à la bonne ambiance qu’ils font régner au sein du département. J’ai eu la chance d’être particulièrement bien entourée ce qui est inestimable dans le travail de longue haleine que représente un doctorat, travail qui peut être emprunt de frustrations et de solitude. Je remercie tous ceux qui passaient de temps en temps dans mon bureau et j’adresse une pensée particulière à Mathieu et son Apple-attitude, Pierre avec son tweed et son bronzage uniques, Rata et sa bonne humeur, Damien et sa décontraction sudiste, Arthur lorsqu’il n’est pas en vacances, Evrard lorsqu’il est réveillé, Sarah avec sa force surhumaine et ses conseils esthé- tiques, Pawit et ses bons plats thaïs, Yohan avec son gâteau au chocolat et son fromage blanc à Saulx-les-Chartreux, Joseph avec le petit compartiment de sa machine à pain et son thé, Dalal et son rire, et tous les autres (même ceux du DTIM). Je souhaite remercier plus particulièrement Antoine notamment pour nos tours de ring et nos échanges autour de bons thés (exempts ou non de grand-mères) qui m’ont permis de surmonter l’étape douloureuse que peut être la rédaction ; Christelle, pour son amitié et son soutien, avec nos nombreuses et longues discussions qui m’ont portée au travers des moments les plus difficiles, aussi bien professionnels que personnels ; et Loïc, qui dès son arrivée en thèse, a su m’offrir une oreille attentive et des conseils éclairés tout en entretenant ma motivation dès qu’elle était trop fragile. Je ne pourrais oublier de remercier également mes amis Lucille, Ambre, Mathieu, Lise, Estelle, Laetitia, Julie, Anaïs, Charlotte, Yelena, Alice et les Glénanais qui m’ont encouragée jusqu’au jour de ma soutenance. Enfin, mais non des moindres, je remercie mes frères, David et Thomas, ainsi que ma mère, Sandra et Coline pour avoir toujours cru en moi et avoir fait preuve d’un encouragement sans faille. 4Table des matières Introduction 9 1 Systèmes de traitement formel d’évènements complexes 13 1.1 Principaux enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2 Event Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3 Le langage ETALIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.4 Le langage des chroniques de Dousson et al. . . . . . . . . . . . . . . . . . . . . . . 23 1.5 Le langage des chroniques Onera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.5.1 Une première implémentation : CRS/Onera . . . . . . . . . . . . . . . . . . . 29 1.5.2 Définition d’une sémantique du langage des chroniques . . . . . . . . . . . . 30 1.5.3 Détail de la sémantique ensembliste du langage des chroniques de CRS/Onera 31 1.6 D’autres modes de représentation et de reconnaissance de comportements . . . . . 34 2 Construction d’un cadre théorique pour la reconnaissance de comportements : le langage des chroniques 41 2.1 Définitions générales préalables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.1.1 Évènements et leurs attributs . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.1.2 Opérations sur les attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.2 Définition d’une syntaxe étendue du langage des chroniques : ajout de contraintes sur des attributs d’évènement et de constructions temporelles . . . . . . . . . . . . 46 2.3 Définition de la sémantique du langage à travers la notion de reconnaissance de chronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.1 Passage à une représentation arborescente des reconnaissances . . . . . . . 53 2.3.2 Formalisation de la notion de reconnaissance de chronique . . . . . . . . . . 55 2.4 Propriétés du langage des chroniques . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.4.1 Définition d’une relation d’équivalence sur les chroniques . . . . . . . . . . 60 2.4.2 Relations entre ensembles de reconnaissances . . . . . . . . . . . . . . . . . 60 2.4.3 Associativité, commutativité, distributivité . . . . . . . . . . . . . . . . . . 62 2.5 Gestion du temps continu à l’aide d’une fonction Look-ahead . . . . . . . . . . . . 64 2.6 Tableau récapitulatif informel des propriétés du langage des chroniques . . . . . . . 66 2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements 3 Un modèle de reconnaissance en réseaux de Petri colorés dit « à un seul jeton » 69 3.1 Définition du formalisme des réseaux de Petri colorés . . . . . . . . . . . . . . . . . 70 3.1.1 Types et expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.1.2 Réseaux de Petri colorés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.1.3 La fusion de places . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.1.4 Arcs inhibiteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.2 Construction formelle des réseaux dits « à un seul jeton » . . . . . . . . . . . . . . 77 3.2.1 Types et expressions utilisés dans le modèle . . . . . . . . . . . . . . . . . . 77 3.2.2 Structure générale des réseaux « à un seul jeton » . . . . . . . . . . . . . . 79 3.2.3 Briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.2.4 Construction par induction . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.3 Formalisation et description de l’exécution des réseaux . . . . . . . . . . . . . . . . 89 3.3.1 Reconnaissance d’un évènement simple . . . . . . . . . . . . . . . . . . . . . 89 3.3.2 Reconnaissance d’une séquence . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.3.3 Reconnaissance d’une disjonction . . . . . . . . . . . . . . . . . . . . . . . . 94 3.3.4 Reconnaissance d’une conjonction . . . . . . . . . . . . . . . . . . . . . . . 95 3.3.5 Reconnaissance d’une absence . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.3.6 Définition formelle de la stratégie de tirage . . . . . . . . . . . . . . . . . . 106 3.4 Démonstration de la correction du modèle « à un seul jeton » . . . . . . . . . . . . 107 3.5 Étude de la taille des réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4 Un modèle de reconnaissance contrôlé en réseaux de Petri colorés 117 4.1 Construction et fonctionnement des réseaux dits « multi-jetons » . . . . . . . . . . 118 4.1.1 Types et expressions utilisés dans les réseaux multi-jetons . . . . . . . . . . 119 4.1.2 Structure globale des réseaux multi-jetons . . . . . . . . . . . . . . . . . . . 119 4.1.3 Briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.1.4 Construction par induction . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.1.5 Bilan sur le degré de contrôle acquis et stratégie de tirage . . . . . . . . . . 133 4.2 Construction et fonctionnement des réseaux « contrôlés » . . . . . . . . . . . . . . 134 4.2.1 Types et expressions utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 4.2.2 Structure globale des réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . 137 4.2.3 Briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 4.2.4 Un séparateur de jetons générique . . . . . . . . . . . . . . . . . . . . . . . 144 4.2.5 Construction par induction des réseaux contrôlés . . . . . . . . . . . . . . . 146 4.2.6 Graphes d’espace d’états des réseaux contrôlés . . . . . . . . . . . . . . . . 159 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 5 Bibliothèque C++ de reconnaissance de comportements et applications à la surveillance de la sécurité d’avions sans pilote 165 5.1 Développement d’une bibliothèque C++ implémentant la reconnaissance de chroniques : Chronicle Recognition Library (CRL) . . . . . . . . . . . . . . . . . . . . . 166 6TABLE DES MATIÈRES 5.2 Surveillance de cohérence au sein d’un UAS en cas de pannes . . . . . . . . . . . . 171 5.2.1 Description de l’architecture du système d’avion sans pilote étudié . . . . . 172 5.2.2 Modélisation du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 5.2.3 Objectifs de la reconnaissance de comportements dans ce cas d’étude . . . . 180 5.2.4 Écriture et formalisation des situations incohérentes à détecter . . . . . . . 181 5.2.5 Utilisation de CRL pour reconnaître les situations incohérentes . . . . . . . 182 5.3 Surveillance du bon respect de procédures de sécurité à suivre par un drone . . . . 185 5.3.1 Cadre du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 5.3.2 Mise en place du système de surveillance : écriture des chroniques critiques à reconnaître . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 5.3.3 Application à des scénarios de simulation avec CRL . . . . . . . . . . . . . . 189 5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Conclusion et perspectives 193 Bibliographie 197 A Démonstrations de propriétés du langage des chroniques 207 A.0.1 Associativité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 A.0.2 Commutativité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 A.0.3 Distributivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Table des figures et des tableaux 211 Table des symboles 213 Table des acronymes 215 7Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements 8Introduction Dans de nombreux domaines, notamment l’aérospatial, le médical, la finance ou le nucléaire, des quantités très importantes de données sont produites par des systèmes pouvant être réels ou simulés. Pour la manipulation de ces masses énormes de données, des outils d’aide à l’analyse sont nécessaires. Par exemple, l’industrie aérospatiale a recours de façon systématique à la simulation afin de pouvoir étudier l’ensemble des caractéristiques de systèmes de grande envergure ; et il est nécessaire de pouvoir exploiter les données produites. Par ailleurs, au vu de l’automatisation croissante des tâches, les systèmes mis en cause sont de plus en plus critiques et de plus en plus complexes. Ils mettent en interaction hommes, machines et environnements, rendant ainsi les risques humains et matériels de très grande envergure. Ceci rend nécessaire l’emploi de méthodes formelles pour s’assurer de la correction des outils d’aide à l’analyse utilisés. C’est dans ce contexte que s’inscrit la problématique de la reconnaissance formelle de comportements dans le cadre de problèmes complexes, domaine du Complex Event Processing (CEP). Il s’agit de développer des outils fiables d’aide à l’analyse de flux d’évènements permettant de reconnaître des activités pouvant être aussi bien normales qu’anormales dans des flux complexes d’évènements. Parmi les formalisations de description et de reconnaissance de comportements, on peut citer les suivantes : — L’Event Calculus (EC), dont les travaux récents sont menés principalement par A. Artikis, est fondé sur la programmation logique. Des séries de prédicats, qui peuvent être dérivés par apprentissage [ASPP12], définissent les comportements à reconnaître. Initialement, leur reconnaissance ne pouvait se faire en ligne, mais une solution est proposée dans [ASP12]. De plus, un raisonnement probabiliste peut être introduit dans l’EC [SPVA11]. — Les chroniques de Dousson et al. [DLM07] sont des ensembles de formules décrivant des associations d’évènements observables et sont représentées par des graphes de contraintes. — Les chroniques de [Ber09, CCK11] développées à l’Onera sont un langage temporel bien distinct des chroniques de Dousson et permettant la description formelle de comportements puis leur reconnaissance en ligne, et ce avec historisation des évènements (c’est-à-dire avec la possibilité de remonter précisément à la source des reconnaissances). Elles sont définies par induction à partir d’opérateurs exprimant la séquence, la conjonction, la disjonction et l’absence. Un modèle de reconnaissance est proposé en réseaux de Petri colorés, où un 9Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements réseau calculant les ensembles de reconnaissances peut être construit pour chaque chronique que l’on souhaite reconnaître. Les applications de ces travaux sont très variées et touchent notamment à la médecine (monitoring cardiaque par exemple), la gestion d’alarmes, la sécurité informatique, l’évaluation de la satisfaction de passagers dans des transports publics, la surveillance vidéo, etc. Cette thèse consiste à formaliser et étendre un langage de description de comportements, le langage des chroniques de [CCK11], tout en développant des modèles d’implémentation du processus de reconnaissance pour ensuite traiter des applications variées. La démarche consiste dans un premier temps à formaliser et étendre le langage des chroniques défini dans [CCK11] afin de répondre à un besoin d’expressivité plus important. On commence par définir inductivement la syntaxe du langage, puis, afin de lui donner un sens, on explicite la notion de reconnaissance de chronique par une fonction. Cette dernière est définie par induction pour chaque chronique : à un flux d’évènements, elle associe l’ensemble des reconnaissances de la chronique dans ce flux. Dans [CCK11], le formalisme de représentation des reconnaissances de chroniques est ensembliste (chaque reconnaissance est représentée par un ensemble d’évènements), mais cela ne permet pas de distinguer certaines reconnaissances car il n’est pas possible de savoir à partir de ces ensembles à quelle partie de la reconnaissance de la chronique correspond chaque évènement de l’ensemble de reconnaissance. Pour cela, on modifie ce formalisme en remplaçant la représentation ensembliste par une représentation arborescente des reconnaissances qui permet de conserver plus d’informations et de distinguer toutes les reconnaissances possibles. Après cette formalisation, on peut étendre l’expressivité du langage avec de nouvelles constructions temporelles et introduire la manipulation d’attributs d’évènements. Davantage de comportements peuvent ainsi être exprimés et une plus grande variété d’applications peut être traitée. Les constructions temporelles choisies sont de deux types : d’une part les constructions contraignant temporellement une chronique par rapport à une autre, et d’autre part celles contraignant une chronique par rapport à un délai. Ces constructions découlent classiquement des relations d’Allen [All81, All83] qui décrivent tous les agencements possibles d’intervalles et sont compatibles avec un modèle de temps continu adapté à des applications réelles. Parallèlement, la notion d’attribut d’évènement est formalisée de manière à pouvoir manipuler des données liées aux évènements du flux, puis, plus généralement, des données liées aux chroniques elles-mêmes. Ceci permet d’introduire plusieurs niveaux de complexité et de considérer des chroniques comme des évènements intermédiaires. La nécessité de pouvoir manipuler de telles données apparaît dès lors que l’on essaie de traiter des exemples d’application d’une légère complexité. En effet, il est primordial de pouvoir alors exprimer des corrélations entre des évènements différents, par exemple, de pouvoir spécifier qu’ils proviennent d’une même source. Pour cela, des chroniques exprimant des contraintes sur les attributs sont définies. De plus, afin de pouvoir considérer plusieurs niveaux d’évènements-chroniques, une fonction permettant de construire des attributs de chroniques est définie. L’ensemble de ces travaux est présenté dans le Chapitre 2. On obtient alors un langage des chroniques expressif formalisé. Afin de pouvoir utiliser ce formalisme pour effectuer la reconnaissance de comportements, il faut définir des modèles de ce processus qui permettent l’utilisation du langage dans des applications quelconques. On doit pouvoir montrer que l’exécution de ces modèles respecte la sémantique des chroniques. Pour ce faire, on choisit de 10Introduction développer deux modèles d’implémentations différentes. Un premier modèle, dans la continuité de celui présenté dans [CCK11], permet de reconnaître les chroniques initiales de [CCK11] à l’aide de réseaux de Petri colorés, un langage de spécification formelle adapté à la reconnaissance de comportements. Pour compléter la construction formelle du modèle de [CCK11], on définit par induction cinq places centrales formant une structure clé de chaque réseau, permettant ensuite de composer ensemble les réseaux et donc de définir une construction formelle par induction des réseaux de reconnaissance. Le marquage des réseaux de Petri colorés construits pour chaque chronique évolue au fur et à mesure du flux d’évènements. Pour répondre au problème de la vérification de la correction du système vis-à-vis de la sémantique, on démontre que ce marquage correspond exactement à la définition formelle de [PBC+]. Cette formalisation et cette preuve sont présentées dans [CCKP12a] et développés dans le Chapitre 3. Cependant, l’intégralité des transitions des réseaux de Petri de ce modèle sont toujours tirables. Le modèle de reconnaissance est ainsi non déterministe dans le sens où il est nécessaire de tirer à la main les transitions dans un certain ordre, en suivant une stratégie de tirage bien définie, pour obtenir le résultat souhaité, c’est-à-dire l’ensemble de reconnaissance défini par la sémantique. On souhaite donc modifier ce modèle pour obtenir un marquage final unique, tout en conservant la double contrainte d’avoir d’une part une construction modulaire des réseaux calquée sur le langage, et d’autre part de conserver de la concurrence dans l’exécution des réseaux. On procède en deux temps. Tout d’abord, contrairement au premier modèle proposé dont les jetons contiennent des listes d’instances de reconnaissance, on passe à un modèle de réseau multi-jetons : un jeton pour chaque instance de reconnaissance afin d’initier l’implémentation d’un contrôle du réseau via des gardes sur les transitions. Dans un second temps, une structure de contrôle du flux d’évènements est implémentée pour achever la déterminisation du modèle tout en préservant la structure modulaire. La concurrence présente dans l’exécution des réseaux et l’unicité du marquage final après le traitement de chaque évènement du flux sont ensuite mis en avant en développant le graphe des marquages accessibles à l’aide du logiciel CPN Tools. Ces travaux sont exposés dans [CCKP13a] et développés dans le Chapitre 4. Ce premier modèle de reconnaissance de chronique est cependant limité aux chroniques initiales de [CCK11] et ne permet donc pas de reconnaître des constructions temporelles ni de manipuler des attributs. Un second modèle de reconnaissance sur l’ensemble du langage étendu des chroniques est donc développé en C++ permettant ainsi une application directe. Ses algorithmes sont fidèlement calqués sur la sémantique du langage, justifiant ainsi le fonctionnement du modèle, CRL, qui est déposé sous la licence GNU LGPL. La bibliothèque CRL est utilisée dans des applications du domaine des drones. On considère d’abord un système de drone (pilote, drone, Air Traffic Control (ATC)). On souhaite évaluer les procédures d’urgence liées à des pannes de liaisons entre les différents acteurs du systèmes. Ces procédures sont en cours de développement et l’on souhaite mettre en avant les éventuelles failles corrigibles, et proposer un système d’alarmes pour les failles humaines dont il est impossible de s’affranchir. On modélise le système et ses procédures par un diagramme UML implémenté en C++ puis on le soumet à des pannes de liaisons éventuellement multiples pour reconnaître les situations incohérentes pouvant donner lieu à un danger. crl et cette application sont présentées dans [CCKP12b] et [CCKP13b], et développés dans le Chapitre 5. 11Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements On réalise également une seconde application dans le domaine des drones. On considère un drone partant de l’aéroport d’Ajaccio pour une mission d’observation d’un feu en dehors de l’espace aérien contrôlé. Il doit passer successivement dans des zones de l’espace aérien contrôlé puis en sortir, et à chacune de ces actions sont associées des procédures de sécurité (points de passage, clearances, . . . ). L’objectif est de proposer un moyen de surveillance du drone assurant le respect des procédures. Pour ce faire, on écrit plusieurs niveaux de chroniques, où interviennent des constructions temporelles et des contraintes sur des attributs d’évènements complexes. On utilise crl pour reconnaître ces chroniques dans des flux d’évènements tests comprenant un fi- chier de positions du drone produit par le battlelab blade de l’Onera [CBP10] ainsi qu’un fichier d’évènements élémentaires (clearances, changement de fréquence radio, . . . ). 12Chapitre 1 Systèmes de traitement formel d’évènements complexes Sommaire 2.1 Définitions générales préalables . . . . . . . . . . . . . . . . . . . . . . 43 2.1.1 Évènements et leurs attributs . . . . . . . . . . . . . . . . . . . . . . . . 44 2.1.2 Opérations sur les attributs . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.2 Définition d’une syntaxe étendue du langage des chroniques : ajout de contraintes sur des attributs d’évènement et de constructions temporelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3 Définition de la sémantique du langage à travers la notion de reconnaissance de chronique . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.1 Passage à une représentation arborescente des reconnaissances . . . . . 53 2.3.2 Formalisation de la notion de reconnaissance de chronique . . . . . . . . 55 2.4 Propriétés du langage des chroniques . . . . . . . . . . . . . . . . . . 60 2.4.1 Définition d’une relation d’équivalence sur les chroniques . . . . . . . . 60 2.4.2 Relations entre ensembles de reconnaissances . . . . . . . . . . . . . . . 60 2.4.3 Associativité, commutativité, distributivité . . . . . . . . . . . . . . . . 62 2.5 Gestion du temps continu à l’aide d’une fonction Look-ahead . . . . 64 2.6 Tableau récapitulatif informel des propriétés du langage des chroniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 On va s’intéresser dans ce chapitre à exposer les principales méthodes de traitement formel d’évènements complexes – Complex Event Processing (CEP) et plus généralement de l’Information Flow Processing (IFP) 1 . Ces systèmes se présentent en deux parties principales : il y a 1. La distinction entre CEP et IFP est réalisée dans [CM12], le CEP est présenté comme étant une partie de l’IFP qui contient également d’autres domaines comme celui des bases de données actives. 13Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements d’une part le moyen employé pour la description formelle des comportements à reconnaître, et d’autre part le processus de reconnaissance de ces comportements dans un flux d’évènements. Pour une introduction globale au domaine du traitement d’évènements complexes, nous renvoyons aux livres [Luc02, EN10]. D’autre part, [LSA+11] présente un glossaire des termes employés dans le domaine. Nous allons commencer par dégager dans la Section 1.1 les principales problématiques de l’IFP. Dans les sections suivantes, nous présentons ensuite successivement quatre méthodes de reconnaissance d’évènements complexes qui sont représentatives de notre problématique : l’Event Calculus (EC) dans la Section 1.2, le langage ETALIS dans la Section 1.3, le langage des chroniques de Dousson et al. dans la Section 1.4, et le langage des chroniques Onera dans la Section 1.5. Dans une dernière section (1.6), nous présentons succinctement une sélection d’autres méthodes autour de l’IFP et donnons un aperçu des domaines d’application. 1.1 Principaux enjeux On s’attache dans cette section à mettre en avant les principaux enjeux permettant de distinguer les différentes approches formelles de l’IFP. Expressivité Il est nécessaire que le langage utilisé pour la description des comportements à reconnaître soit suffisamment expressif pour exprimer toutes les nuances désirées selon l’application envisagée. Cependant, il est clair qu’une grande expressivité ira inévitablement de pair avec une plus grande complexité du processus de reconnaissance. Il s’agit donc de trouver l’équilibre adéquat. La section 3.8 de [CM12] présente les principaux opérateurs et constructions que l’on rencontre dans la littérature. On retrouve notamment la conjonction, la disjonction, la séquence, la négation ou l’absence, l’itération, l’expression de contraintes temporelles, la manipulation de paramètres. . . La notion de négation ou d’absence est particulièrement épineuse : il est nécessaire de délimiter l’intervalle de temps précis sur lequel porte une négation ou une absence pour pouvoir déterminer si une telle construction est reconnue. Par ailleurs, la question d’avoir une syntaxe ouverte ou fermée se pose. Il s’agit d’autoriser, ou non, la possibilité d’écrire des formules n’ayant pas de sens. Praticité d’écriture & lisibilité Dans le contexte du dialogue avec des experts pour la réalisation d’une application, la praticité d’écriture du langage est importante. On s’intéresse à la concision et à la lisibilité du langage qui faciliteront la discussion avec les spécialistes du domaine et leur utilisation du système de reconnaissance. Il s’agit là encore de trouver un équilibre entre lisibilité et expressivité : une lisibilité excessive peut conduire à une simplifi- cation extrême du langage et donc à une expressivité réduite. Efficacité L’efficacité du processus de reconnaissance est cruciale. En effet, l’analyse des données se veut souvent être réalisée en ligne. Ceci implique la nécessité d’un temps de calcul réduit permettant de traiter les évènements du flux suffisamment rapidement par rapport à leur fréquence d’arrivée. Naturellement, la rapidité du processus est directement liée à la promptitude de la réponse au problème étudié qui peut être capitale par exemple s’il s’agit de produire une alarme lorsqu’une situation critique se produit. 14CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Multiplicité On peut s’intéresser à établir toutes les reconnaissances d’un comportement donné, et non uniquement l’information que le comportement a eu lieu au moins une fois. La multiplicité des reconnaissances est nécessaire dans la perspective de recherche de comportements dangereux où il peut être essentiel de savoir qu’un comportement s’est produit plusieurs fois. Par exemple, dans certains domaines d’application comme la supervision de réseaux de télécommunications [Dou02], certaines pannes ne sont identifiables qu’à travers la multiplicité d’un comportement donné qui n’est en revanche pas significatif individuellement. En revanche, la multiplicité peut aller à l’encontre de l’efficacité du processus qui doit reconnaître toutes les occurrences et n’a donc pas le droit à l’oubli de reconnaissances intermédiaires. Pour pouvoir s’adapter à toutes les situations, on peut définir différents degrés d’exhaustivité des reconnaissances. Par exemple, [CM12] pose les contextes suivants qui établissent différentes gestions de la multiplicité des reconnaissances : — dans le contexte « récent », seule l’occurrence la plus récente d’un événement qui débute une reconnaissance est considéré (ainsi, pour il y a toujours un évènement initiateur unique) ; — dans le contexte « chronique », les plus anciennes occurrences sont utilisées en premier, et sont supprimées dès leur utilisation (ainsi, les évènements initiateur et terminal sont uniques) ; — dans le contexte « continu », chaque évènement initiateur est considéré ; — dans le contexte « cumulatif », les occurrences d’évènements sont accumulées, puis supprimées à chaque reconnaissance (ainsi, un évènement ne peut pas participer à plusieurs reconnaissances). Historisation Il s’agit de pouvoir spécifier, pour chaque reconnaissance d’un comportement, quels sont les évènements du flux qui ont mené à cette reconnaissance. L’historisation permet alors de distinguer les différentes reconnaissances et donc d’y réagir plus finement. Il s’agit d’une forme de traçabilité qui apporte également la possibilité d’un retour d’expérience sur les causes du comportement détecté. Traitement des évènements Plusieurs caractéristiques peuvent être requises par le système sur le flux d’évènements à traiter. Un flux unique totalement et strictement ordonné et dont les évènements arrivent dans l’ordre sans retard constitue un flux idéal, et l’algorithme de reconnaissance associé en sera a priori simplifié. Cependant les domaines d’applications peuvent exiger d’avoir la possibilité de considérer notamment : — un ordre uniquement partiel entre les évènements à analyser ; — des sources distribuées d’évènements – il faut alors définir correctement l’ordre entre les évènements provenant de deux flux différents ; — un ordre non strict entre les évènements pour prendre en compte l’arrivée simultanée d’évènements ; — des évènements arrivant en retard ou étant corrigés a posteriori – il s’agit alors de pouvoir malgré tout les traiter correctement. La gestion d’événements révisés est utile par exemple dans les cas d’application où un événement a été envoyé puis reçu, mais ensuite révisé suite à l’échec d’une transaction. 15Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Centralisation ou distribution Le flux d’évènements à analyser peut provenir d’une source centralisée ou distribuée. Dans le cas d’un système distribué se pose la question de l’ordonnancement des évènements provenant des différentes parties du système. Par exemple, l’hypothèse d’une horloge synchronisée peut être prise. Modèle de temps Le modèle de temps adopté est en général linéaire. Il peut être discret, avec une granularité adaptable, ou bien continu. Dans certains systèmes comme les Systèmes de Gestion de Flux de Données – Data Stream Management Systems (DSMSs), aucun modèle de temps particulier n’est utilisé et seul l’ordre entre les évènements est considéré mais cela a alors une incidence sur l’expressivité du langage de description de comportements utilisé. Actions Il peut être possible de déclencher des actions à différents instants dans le processus de reconnaissance. Parmi les actions, on peut considérer entre autres la production d’un évènement associé à la reconnaissance d’un comportement et son intégration au flux. Se pose alors la question de l’ordre de traitement de ces nouveaux évènements par rapport aux autres évènements du flux. On peut également imaginer des actions d’une complexité plus importante : par exemple, ajouter dynamiquement un nouveau comportement à reconnaître. Méthodes d’écriture L’écriture, dans le langage formel utilisé, des comportements à reconnaître présente une double difficulté qui dépend de l’expressivité et de la lisibilité du langage. D’une part, il faut exactement identifier toutes les situations à reconnaître pour répondre au problème étudié. D’autre part, il faut correctement transcrire ces comportements dans le langage utilisé. Des méthodes plus ou moins automatisées et principalement fondées sur des statistiques peuvent être proposées aux experts chargés d’écrire les comportements à reconnaître. Gestion d’incertitudes Lors de l’analyse d’activités réelles, de nombreuses indéterminations apparaissent naturellement : incertitudes sur les comportements à reconnaître, incertitudes sur la date d’occurrence ou même sur l’occurrence elle-même d’évènements. . . Des mécanismes de gestion d’incertitudes peuvent donc être établis au niveau du langage de description et/ou au niveau de l’algorithme de reconnaissance, selon les indéterminations considérées. 1.2 Event Calculus Le calcul d’évènements, ou EC, est une formalisation permettant la représentation et le raisonnement sur des évènements et des actions et pouvant s’exécuter sous la forme d’un programme logique. Il s’intéresse à établir la valeur de propositions logiques dans le temps. L’EC est introduit par Kowalski et Sergot dans [KS86] et tire son nom du calcul de situation (Situation Calculus) dont il se distingue par le fait qu’il traite d’évènements locaux plutôt que d’états globaux. Le but est de s’affranchir du problème du cadre dans un souci d’efficacité. L’EC se veut constituer une analyse formelle des concepts mis en jeu, à savoir les évènements et les actions. Il peut être exprimé à partir de clauses de Horn 2 auxquelles est ajoutée la négation par l’échec 3 , 2. On rappelle qu’une clause de Horn est une formule du calcul propositionnel de la forme (p1 ∧ . . . ∧ pn) ⇒ q où n ∈ N, p1, . . . , pn sont des littéraux positifs et q est un littéral quelconque. 3. La négation par l’échec se fonde sur le principe que la base de connaissances est complète et que donc, si tous 16CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES se plaçant ainsi dans le cadre de la programmation logique. Les principes initiaux majeurs de l’EC sont les suivants : — les évènements peuvent être traités dans un ordre quelconque non nécessairement lié à leur ordre d’occurrence ce qui fait que le passé et le futur sont considérés symétriquement ; — en particulier, des évènements peuvent être concurrents et ne sont pas forcément considérés comme ponctuels ; — les mises à jour sont toujours additives dans le sens où elles ne peuvent pas retirer d’informations passées ; — ce n’est pas tant la date des évènements qui est importante que leur ordre relatif. Il existe de nombreux dialectes de l’EC fondés sur des axiomatiques proches et permettant de traiter diverses spécificités telles que la gestion d’actions différées ou de changements continus entre états. De telles axiomatiques sont recensées dans [MS99] et on peut également citer [PKB07, PB08]. Nous nous intéressons plus particulièrement à l’EC élaboré par Artikis et al. pour la reconnaissance de comportements. Ce dialecte, implémenté en programmation logique, est dédié à la reconnaissance de comportements complexes de haut niveau à partir d’évènements de bas niveau. Les comportements composites à reconnaître sont définis à l’aide de prédicats présentés Tableau 1.1 et permettant l’expression de contraintes temporelles sur un modèle de temps linéaire. Ces prédicats sont définis par des axiomes dont certains pouvant être indépendants du domaine d’application. Ce formalisme est expressif. Il permet d’exprimer des contraintes complexes aussi bien temporelles qu’atemporelles et de décrire des situations dans lesquelles un certain comportement ne doit pas avoir lieu dans un certain laps de temps [AP09]. Cette dernière caractéristique est liée au mécanisme de l’absence dans le formalisme des chroniques. Selon les demandes de l’utilisateur, un comportement de haut niveau à reconnaître peut être défini comme un évènement ponctuel simple ou complexe à l’aide du prédicat happensAt ou comme un fluent – i.e. une propriété non ponctuelle pouvant prendre différentes valeurs dans le temps – à l’aide de initially, initiatedAt, holdsFor. . . Pour les activités non ponctuelles, il s’agit de calculer les intervalles maximaux durant lesquels un fluent possède une certaine valeur. Pour ce faire, tous les instants de début d’intervalle puis chaque instant de fin correspondant sont évalués. En effet, intuitivement, un principe d’inertie (exprimant qu’une valeur n’a pas changé tant qu’elle n’a pas été modifiée) est respecté dans le sens où l’on considère qu’un fluent vérifie une certaine valeur si celle-ci a été fixée par un évènement et que, depuis, aucun autre évènement ne l’a modifiée. La question de l’écriture des comportements à reconnaître est étudiée dans [ASP10b, AEFF12]. En effet, l’écriture par des experts des activités à reconnaître est fastidieuse et fortement susceptible de donner lieu à des erreurs, donc il est intéressant de développer un procédé automatique pour engendrer des définitions à partir de données temporelles. Une telle méthode d’apprentissage fondée sur une combinaison d’abductions et d’inductions est utilisée dans [ASP10b, AEFF12] pour inférer les comportements à reconnaître. Une problématique majeure de la reconnaissance de comportements est la possibilité ou non d’exécuter le processus de reconnaissance en temps réel. L’algorithme de base de ce dialecte d’EC fonctionne avec une méthode d’interrogation du système : le raisonnement ne se fait pas au fur les moyens pour montrer une propriété échouent, c’est que sa négation est vérifiée (hypothèse du monde clos). 17Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Tableau 1.1 – Principaux prédicats de l’EC Prédicat Correspondance intuitive happensAt(E, T) Occurrence de l’évènement E à l’instant T. initially(F = V ) Le fluent F vaut V à l’instant 0. holdsAt(F = V, T) Le fluent F vaut V à l’instant T. holdsFor(F = V, I) I est la liste des intervalles maximaux où F vaut V . initiatedAt(F = V, T) À l’instant T, un intervalle de temps où F vaut V débute. terminatedAt(F = V, T) À l’instant T, un intervalle de temps où F vaut V s’achève. union_all(L, I) I est la liste des intervalles maximaux correspondant à l’union des ensembles d’intervalles de la liste L. intersect_all(L, I) I est la liste des intervalles maximaux correspondant à l’intersection mutuelle des ensembles d’intervalles de la liste L. relative_complement _all(I 0 , L, I) I est la liste des intervalles maximaux correspondant à la différence ensembliste entre la liste d’intervalles I 0 et chaque ensemble d’intervalles de la liste L. et à mesure mais à la demande de reconnaissance d’une activité de haut niveau [APPS10]. Pour réaliser une analyse en ligne, il est nécessaire de constamment interroger le programme ; et sans système de mémoire-cache, il faut à chaque fois recommencer les calculs à zéro. De plus, l’un des principes de base de l’EC, à savoir le fait que la reconnaissance de comportements ne doit pas être affectée par l’ordre dans lequel arrivent les évènements à analyser, ne contribue pas à diminuer la complexité de calcul. Dans [CM96], Chittaro et al. présentent une version de l’EC dénommée Cached Event Calculus (CEC) et dont l’implémentation inclut la gestion de mémoire-cache, réduisant ainsi significativement la complexité du processus. Cependant, comme le CEC n’a pas de système d’oubli ni de péremption et qu’il accepte des évènements datés plus tôt que d’autres évènements ayant déjà été traités, les temps de reconnaissance augmentent au fur et à mesure de l’arrivée des évènements de bas niveau à traiter et, après un certain temps, peuvent finir par ne plus respecter les temps de 18CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES calcul minimaux nécessaires pour une reconnaissance en ligne correcte. Pour résoudre ces problèmes, Artikis et al. proposent dans [ASP12] une implémentation efficace de leur processus de reconnaissance, nommée Event Calculus for Run-Time reasoning (RTEC) 4 et réalisée sous YAProlog 5 . Le programme fonctionne toujours par interrogations successives du système, et comme pour le CEC, un dispositif de mémoire-cache est mis en place pour stocker les intervalles maximaux calculés par les prédicats holdsFor pour chaque fluent F. Ceci permet de n’avoir pas à recalculer ces intervalles à chaque itération. La problématique du calcul vient ensuite du fait que des évènements peuvent ou bien arriver en retard, ou bien être corrigés a posteriori. L’algorithme est élaboré de façon à pouvoir traiter correctement ce genre de situation. Deux paramètres du programme sont à fixer : — d’une part, le pas Qi+1 − Qi entre deux interrogations Qi et Qi+1 du système ; — d’autre part, la taille WM (Working Memory) de la fenêtre des évènements à considérer. À chaque itération Qi les évènements datés dans l’intervalle ]Qi − WM, Qi ] sont analysés. Ainsi, dans le choix des paramètres, le signe de la différence WM − (Qi+1 − Qi) est significatif : — si WM < Qi+1 − Qi , alors les évènements de la fenêtre ]Qi , Qi+1 − WM] ne seront jamais analysés, et si un évènement arrive en retard ou est corrigé, il ne sera pas considéré ; — si WM = Qi+1 − Qi , alors exactement tous les évènements arrivés à temps seront analysés ; — si WM > Qi+1 − Qi , alors le système peut traiter des évènements arrivant ou bien avec un certain délai ou bien corrigés dans un certain délai. L’algorithme fonctionne alors comme suit. Les parties des intervalles maximaux calculés auparavant et s’intersectant avec la fenêtre ]Qi−WM, Qi ] sont tronqués. Ensuite, les évènements de la fenêtre ]Qi−WM, Qi ] sont analysés pour recalculer des intervalles maximaux sur cette fenêtre, éventuellement certains identiques à ceux ayant été tronqués. Enfin, les morceaux sont « recollés » afin de recréer des intervalles maximaux globaux. L’algorithme plus détaillé de RTEC est présenté dans [ASP12], avec une analyse des performances du système sur des données réelles et sur des données synthétisées. Dans [AMPP12, PAMP12], une architecture de système pour la reconnaissance de comportements, Event Processing for Intelligent Ressource Management (EP-IRM), est proposée. Elle peut être dotée de nombreux composants pouvant facilement être ajoutés ou supprimés. Certaines applications sont indépendantes du domaine et peuvent être utilisées quelle que soit l’étude, comme par exemple l’affichage de cartes MAP. Le système est également composé d’un moteur détectant les évènements de bas niveau qui sont ensuite envoyés au moteur de reconnaissance de comportements complexes. Par ailleurs, plusieurs approches probabilistes de l’EC sont développées. Tout d’abord, Artikis et al. étendent dans [SPVA11] le formalisme de l’EC au raisonnement probabiliste à l’aide de Réseaux Logiques de Markov [DL09] qui combinent l’expressivité de la logique du premier ordre avec la sémantique formelle probabiliste des réseaux de Markov. D’autre part, dans [SAFP14], Artikis et al. proposent une adaptation de l’EC au cadre de la programmation logique probabiliste en utilisant ProbLog [KDDR+11]. Ceci permet de répondre au problème de détections incorrectes des 4. RTEC est disponible en open-source sur le web : http://users.iit.demokritos.gr/~a.artikis/ RTEC-3examples.zip. 5. http://www.dcc.fc.up.pt/~vsc/Yap/ 19Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements évènements de bas niveau en travaillant sur un flux d’évènements où chaque évènement est doté d’un indice de confiance. En revanche, la reconnaissance en ligne n’est pas encore réalisable avec ce formalisme, et il ne permet pas de traiter le cas des définitions imprécises des comportements à reconnaitre. Une autre approche pour la gestion d’incertitude est présentée dans [AWG+13]. Elle est orthogonale à celle de [SAFP14] dans le sens où elles peuvent être combinées. Le principe consiste à utiliser la variété des sources d’évènements pour déterminer leur véracité. Un système d’« auto-adaptation » est implémenté en utilisant le processus de reconnaissance de comportements lui-même. En effet, des définitions de comportements complexes sont écrites pour identifier les domaines d’incertitude et y réagir : lorsque l’incertitude est significative, le système peut ignorer les évènements d’un certain laps de temps ou bien, momentanément, ne pas considérer certaines sources d’évènements. [AWS+14] répond à la même problématique en ayant en plus recours à du crowdsourcing pour trancher lorsque les désaccords entre les sources sont significatifs. 1.3 Le langage ETALIS Le langage de description de comportements Event-driven Transaction Logic Inference System (ETALIS) 6 [ARFS12, Ani11] est un langage de CEP muni d’une syntaxe et d’une sémantique formelles permettant simultanément de raisonner sur des connaissances temporelles (concernant des évènements) et sur des connaissances stables ou en évolution (règles, faits, ontologies, données encyclopédiques. . . ), et ce à l’aide d’un système réalisant l’analyse de comportements en ligne. ETALIS est un langage de programmation logique. Sa syntaxe est définie par des règles dont les principales constructions sont présentées dans le Tableau 1.2. Le modèle de temps adopté est linéaire et dense mais dénombrable (l’ensemble des rationnels Q) ; les évènements de base du flux à analyser peuvent être aussi bien des évènements instantanés que des évènements ayant une durée, ils sont datés par des intervalles de temps [T1, T2] où éventuellement T1 = T2. Le langage présente une expressivité forte : — l’ensemble des 13 relations d’Allen peut être décrit, — des contraintes peuvent être exprimées sur des propriétés d’évènements, — une notion d’absence est développée, mais limitée au cadre de la séquence, — une distinction précise est faite entre la conjonction en série et celle en parallèle, — il est possible de réaliser des définitions récursives de comportements ce qui permet, par exemple, d’accumuler à l’aide d’une fonction une valeur sur une suite d’évènements. Une première sémantique déclarative formelle est fournie [AFR+10, ARFS12] ; les interprétations de motifs (patterns) d’évènements (i.e. des comportements à reconnaître) est définie par induction à la manière de la théorie des modèles. Il s’agit d’ensembles de reconnaissances où une reconnaissance est représentée par un couple hq1, q2i, avec q1, q2 ∈ Q, délimitant l’intervalle de temps nécessaire et suffisant à la reconnaissance. Les informations relatives aux évènements ayant donné lieu à la reconnaissance ne sont pas conservées, il n’y a donc pas de possibilité d’historisation. Le système de reconnaissance ETALIS est implémenté en Prolog. Pour ce faire, une seconde sémantique, opérationnelle, est définie à l’aide de règles de programmation logique. Les compor- 6. ETALIS est disponible en open-source sur le web : http://code.google.com/p/etalis/. 20CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Tableau 1.2 – Principales constructions du langage ETALIS [AFR+10] Constructions Correspondance intuitive p where t Le comportement p est reconnu et le terme t prend la valeur vraie. q Pour tout q ∈ Q, correspond à l’instant absolu q. (p).q Le comportement p est reconnu et dure exactement q, avec q ∈ Q. p1 seq p2 Le comportement p1 est suivi, strictement (dans le temps), du comportement p2. p1 and p2 Les comportement p1 et p2 sont reconnus, sans aucune contrainte temporelle. p1 par p2 Les comportement p1 et p2 sont reconnus en parallèle, i.e. ils se chevauchent dans le temps. p1 or p2 L’un des deux comportements est reconnu. p1 equals p2 Les deux comportements sont reconnus sur exactement le même intervalle de temps. p1 meets p2 Le dernier instant de reconnaissance de p1 est exactement le premier instant de reconnaissance de p2. p1 during p2 Le comportement p1 est reconnu pendant le comportement p2. p1 starts p2 L’intervalle de reconnaissance de p1 est un segment initial de l’intervalle de reconnaissance de p2. p1 finishes p2 L’intervalle de reconnaissance de p1 est un segment final de l’intervalle de reconnaissance de p2. not(p1).[p2, p3] Les comportements p2 et p3 sont reconnus dans cet ordre, sans occurrence de p1 strictement entre les deux dans le temps. 21Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements tements complexes recherchés sont décomposés en des évènements intermédiaires appelés buts (goals). ETALIS compile les comportements complexes pour fournir un ensemble de règles permettant l’Event-Driven Backward Chaining (EDBC) – chaînage arrière piloté par les données. C’est le chaînage arrière piloté par les données qui rend possible un processus de reconnaissance en ligne. Deux types de règles résultent de la compilation [AFSS09] : — D’une part, des règles créant les buts à reconnaître pour avancer dans la reconnaissance du comportement complexe. Les buts créés représentent l’occurrence d’un évènement et l’attente d’un autre évènement pour reconnaître un évènement (complexe). Elles sont de la forme goal(b [−,−] , a[T1,T2] , ie[−,−] 1 ) qui exprime qu’à la reconnaissance d’un évènement (éventuellement complexe) a sur l’intervalle [T1, T2], le système est en attente d’un évènement b pour reconnaître l’évènement ie1. — D’autre part, des règles créant des évènements intermédiaires ou des patterns d’évènements. Celles-ci vérifient dans la base de données si un certain but existe déjà, et, s’il existe effectivement, déclenchent l’évènement qui a été reconnu par le but. Par exemple, si le but goal(b [T3,T4] , a[T1,T2] , ie[−,−] 1 ) figure dans la base de données, alors l’évènement ie[T1,T4] 1 est déclenché et ensuite propagé s’il s’agit d’un évènement intermédiaire ou utilisé pour déclencher une action s’il s’agit de l’un des comportements complexes recherchés. Les règles de ce type permettent également de supprimer de la base de données les buts qui ne sont plus nécessaires car obsolètes. En d’autres termes, chaque but correspond à un sous-comportement restreint à deux évènements (dans les exemples précédents il s’agit de a et b), et les buts sont chaînés pour aboutir à la reconnaissance du comportement complexe recherché. La structure de la décomposition d’un comportement complexe en buts correspond donc essentiellement à celle d’un arbre binaire. Il n’y a pas de démonstration d’équivalence entre les deux sémantiques. Les auteurs s’assurent en revanche que la sémantique opérationnelle est belle et bien déclarative [ARFS12], et que donc le comportement du système est à la fois prédictible et reproductible. En ce qui concerne la multiplicité des reconnaissances, ETALIS permet l’implémentation des politiques de consommation d’évènements suivantes (introduites dans la Section 1.1) : contexte récent, contexte chronique et contexte libre (i.e. sans restriction, multiplicité totale). Mais il faut noter que l’on perd l’aspect déclaratif si l’on utilise une autre politique que celle dite libre, et l’ordre d’évaluation des règles devient alors significatif. Une analyse des performances d’ETALIS est présentée dans [AFR+10] sur un cas d’étude analysant l’efficacité d’un système de livraison de fleurs (Fast Flower Delivery Use Case [EN10]). Par ailleurs, la nature logique de l’approche rend possible un raisonnement déductif en temps réel sur une base de connaissances fixe de données structurées de l’environnement. Celle-ci permet de définir une sémantique de l’information utilisable par un système. ETALIS permet la gestion d’évènements arrivant en retard dans un flux ordonné par rapport au temps [FAR11] grâce à l’ajout de deux types de règles : — Des règles de type goal_out(a [−,−] , b[T3,T4] , ie[−,−] 1 ) exprimant que l’évènement b a été reçu et que a est en attente, mais avant b, pour réaliser la reconnaissance de ie1. — Des règles de la forme if goal_out(. . . ) and T2 < T3, alors si un évènement a arrive avec effectivement T2 < T3, l’événement ie[T1,T4] 1 est déclenché. 22CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Un tel algorithme a la particularité de ne pas gérer les évènements en retard au détriment de l’ef- ficacité du processus de reconnaissance pour les évènements arrivant à temps : la reconnaissance est toujours quasi-immédiate si tous les évènements composant un comportement complexe sont arrivés à temps. En revanche, le système nécessite la mise en place d’une procédure de libération de mémoire assurant la suppression des règles de type goal_out après un certain laps de temps. [FAR11] précise que, pour « des raisons pratiques » (sûrement une question d’efficacité de reconnaissance par surcharge de règles), cette fonctionnalité n’a pas été implémentée pour la politique de consommation d’évènements dite libre ; on perd donc la multiplicité des reconnaissances. Pour mener les cas de retard d’un évènements interdit dans une absence, la gestion d’arrivée d’évènements en retard doit être couplée avec la gestion d’évènements révisés, présentée brièvement ci-dessous. En effet, si l’on considère une négation not(c).[a, b] et qu’une reconnaissance est invalidée par l’arrivée d’un c en retard, il faut alors réviser la reconnaissance erronée. ETALIS permet également la gestion d’évènements révisés [ARFS11]. Comme évoqué en 1.1, ceci peut s’avérer utile dans le cas d’un échec d’une procédure amenant ainsi la correction d’un évènement déjà envoyé. Des sortes de marqueurs sont ajoutés, permettant d’indiquer quels évè- nements (éventuellement intermédiaires) ont donné lieu à quels buts. Ceci permet d’identifier les instances d’évènements à réviser et de propager correctement la révision dans tout le système. Des règles rev sont ajoutées pour supprimer les buts (goal(. . . )) insérés mais révisés. 1.4 Le langage des chroniques de Dousson et al. Le langage des chroniques a été développé pour décrire formellement une signature évènementielle et offre un cadre pour le traitement d’évènements complexes – CEP. Le terme de « chronique » est un terme générique englobant plusieurs systèmes formels voués à la description et à la reconnaissance de comportements. On décrit, dans cette sous-section, un premier formalisme de la notion de chronique. Un langage des chroniques a été introduit notamment dans [Gha96] et développé principalement par Dousson et al. [DGG93, Dou02, DLM07]. Il permet de décrire formellement des agencements d’évènements. Une chronique est en quelque sorte un ordre partiel d’évènements observables dans un certain contexte. Le langage est doté d’un processus de reconnaissance en ligne efficace permettant d’analyser un flux d’évènements datés mais dont les évènements n’arrivent pas nécessairement dans leur ordre d’occurrence pour y reconnaître des situations et éventuellement déclencher des actions ou produire un évènement à une date définie relativement aux dates des évènements ayant donné lieu à la reconnaissance. On manipule des prédicats exprimant le fait qu’un attribut fixé ait une certaine valeur sur un intervalle de temps donné. Un motif d’évènement correspond à un changement de valeur d’un attribut, et un évènement est alors une instance datée ponctuelle de motif d’évènement [DGG93]. Le modèle de temps adopté est linéaire et discret, la résolution adoptée étant supposée suffisante pour le contexte étudié. Une distinction est opérée entre la date d’occurrence et la date de réception des évènements observés. Une borne sur le délai de réception d’un évènement est fournie par l’utilisateur pour chaque motif d’évènement. Ceci permet, comme dans l’Event Calculus, de considérer des 23Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements évènements arrivant avec un retard borné. Par ailleurs, de même que pour l’Event Calculus, on suppose la complétude du flux d’évènement, c’est-à-dire qu’entre deux activations d’une propriété il y a nécessairement un évènement de désactivation de cette propriété (par rapport aux dates d’occurrences). Un modèle de chronique à reconnaître [DGG93] est composé : — d’un ensemble de motifs d’évènements exprimés par les prédicats du Tableau 1.3, — de contraintes temporelles sur ces motifs d’évènements reliées par une conjonction implicite (pour des raisons de complexité, il n’est pas possible d’exprimer de disjonction), — d’un contexte général permettant d’exprimer des contraintes contextuelles, — d’éventuelles actions à réaliser à la reconnaissance (notamment la production d’évènements). Dans [Dou02], le prédicat occurs présenté dans le Tableau 1.3 est ajouté pour répondre à la question du comptage d’évènements qui est un problème typique du domaine de la gestion d’alarmes où certaines pannes ne sont identifiables que par comptage. occurs permet de faciliter l’écriture de ce genre de chroniques et d’optimiser le processus de reconnaissance associé. En effet, sinon, il faut écrire beaucoup de chroniques pour exprimer la même situation, or la complexité du processus de reconnaissance dépend du nombre de chroniques à étudier. Tableau 1.3 – Principaux prédicats et notations des chroniques [Dou96, Dou02] Prédicat Correspondance intuitive hold(P : v,(t1, t2)) Le nom d’attribut P a la valeur v sur l’intervalle [t1, t2], sans implication sur l’instant où il a pris cette valeur. event(P : (v1, v2), t) L’attribut P passe de la valeur v1 à la valeur v2 à l’instant t. noevent(P,(t, t0 )) P ne change pas de valeur sur l’intervalle [t, t0 [. occurs(n1, n2, a,(t1, t2)) L’évènement a a lieu exactement N fois, avec n1 ≤ N ≤ n2, dans l’intervalle de temps [t1, t2[. (permet l’unification du langage) Notation ? « ? » permet d’indiquer une valeur quelconque. Le processus de reconnaissance de chroniques est illustré par la Figure 1.4. Dans un premier temps, il s’agit de compiler hors ligne les modèles de chroniques fournis par l’utilisateur afin de transcrire les contraintes temporelles de chaque modèle en un graphe de contraintes minimal (la relation d’ordre pour laquelle ce graphe est minimal est définie dans [DD99]). Ce pré-traitement permet notamment de mettre en avant les incohérences éventuelles des modèles de chroniques (l’algorithme employé pour la compilation étant incrémental, il désigne même un sous-ensemble de contraintes incohérentes). L’algorithme de reconnaissance est fondé sur ces graphes. Le système doit ensuite être initialisé avec les états initiaux du monde considéré, datés à −∞, puis la reconnaissance de chroniques peut être lancée. Des instances partielles, i.e. des reconnaissances encore non complètes, sont manipulées. Elles sont chacune en attente d’évènements manquants pour compléter la reconnaissance. Ces évènements manquants doivent arriver dans un certain intervalle de temps, la fenêtre d’admissibilité, calculée grâce au graphe de contraintes et 24CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Figure 1.4 – Le système de reconnaissance de chroniques [Dou94] ce afin de vérifier les contraintes temporelles spécifiées dans la chronique correspondante. Si un évènement attendu n’arrive pas avant la fin de sa fenêtre d’admissibilité ou si l’une des conditions générales de la chronique n’est plus vérifiée, l’instance partielle est alors abandonnée et supprimée. Au contraire, lorsqu’une instance partielle s’apprête à être complétée par un évènement, elle est d’abord dupliquée afin de garantir la reconnaissance de toutes les situations : l’instance partielle complétée peut ainsi être de nouveau complétée par une autre occurrence d’un évènement similaire. La duplication d’instances est la principale source de complexité du processus de reconnaissance. Afin d’optimiser la manipulation des instances (partielles) de reconnaissance, celles-ci sont stockées dans un arbre. Au fur et à mesure de l’arrivée des évènements pertinents les contraintes temporelles exprimées par les fenêtres d’admissibilité du graphe de contraintes sont mises à jour et les modifications sont propagées dans le reste du graphe. Ceci permet de traiter directement l’arrivée de tout évènement. Une propagation des modifications est également effectuée lorsque le temps avance : le système calcule le prochain instant critique et une mise à jour est effectuée lorsque le temps courant atteint cet instant [DGG93]. Le processus de reconnaissance est donc exhaustif, et le plus efficace pour diminuer sa complexité est de limiter la durée de validité d’une instance de chronique [AD01]. Le système peut également prendre en entrée, en plus des évènements datés, l’assertion AssertNoMore(e, I) où e est un évènement et I est un intervalle étendu (i.e. une union disjointe d’intervalles) [DLM07]. Cette assertion indique qu’aucun évènement e n’aura lieu dans I. À la réception d’un tel message, les fenêtres d’admissibilité sont mises à jour en leur appliquant la différence ensembliste avec I et les modifications sont propagées dans le graphe. Cette assertion est introduite dans le but d’être utilisée à des fins d’optimisation, ce qui sera détaillé par la suite. 25Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Pour le prédicat occurs(n1, n2, a,(t1, t2)), un compteur est associé au prédicat et tant que l’instant t2 n’est pas atteint, il n’est pas possible de déterminer si le prédicat est vérifié. À l’arrivée d’un évènement a à la date d, les instants t1 et t2 n’ont pas encore nécessairement de valeur mais sont contraints à des intervalles [I − t1 , I+ t1 ] et [I − t2 , I+ t2 ]. On étudie alors tous les cas d’ordonnancement de d, I − t1 , I + t1 , I − t2 , et I + t2 . Ce système de reconnaissance, appelé Chronicle Recognition System (CRS), est construit autour du gestionnaire de graphes temporels IxTeT [GL94]. Il permet ainsi de reconnaître en ligne et efficacement toutes les occurrences des chroniques spécifiées. De plus, ce système est prédictif. En effet, l’utilisateur peut savoir à tout moment quand une reconnaissance est attendue et quels évènements sont requis pour compléter chaque instance partielle. Une définition plus formelle de la notion de chronique et du système de reconnaissance associé est présentée dans [DG94]. Figure 1.5 – Architecture du système de reconnaissance avec focalisation temporelle [DLM07] Dans [DLM07], Dousson et al. proposent une technique d’optimisation de CRS. Il s’agit tout d’abord d’appliquer une méthode de focalisation temporelle qui permet d’optimiser les situations où certains évènements sont beaucoup plus fréquents que d’autres. Afin de limiter le nombre d’instances partielles créées suite à un évènement fréquent en attente d’un évènement rare, on définit un niveau pour chaque type d’évènement. Ceci permet d’établir un critère d’intégration au système de reconnaissance : un évènement de niveau n + 1 n’est pas intégré à une instance donnée 26CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES tant que tous les évènements des niveaux 1 à n n’ont pas été intégrés. Lorsqu’un évènement est intégré à une instance, il est envoyé à toutes les autres instances même si la règle n’est pas vérifiée. Ceci permet de s’assurer que tout évènement est traité exactement une fois. La structure du système est présentée Figure 1.5. Un composant de gestion des évènements est introduit. Les évènements qui ne sont pas immédiatement intégrés sont envoyés au collectionneur qui les stocke dans des flux tampons (il y a un buffer par type d’évènement). Chaque flux tampon manipule trois fenêtres temporelles : la fenêtre assert no more où plus aucun évènement ne sera reçu, la fenêtre de filtrage qui contient les occurrences d’évènements ne convenant à aucune instance, et la fenêtre de focalisation qui contient les dates d’occurrence auxquelles un évènement est attendu et devrait donc être immédiatement envoyé à CRS. Ce mécanisme fournit exactement les mêmes reconnaissances qu’avec la version initiale de CRS et a uniquement un effet sur les performances. Celles-ci ne sont pas améliorées systématiquement ; cela dépend de la fréquence des évènements et de leur position dans le graphe de contraintes. La seconde partie de la méthode est d’introduire un principe de chroniques hiérarchiques qui permet de définir séparément des sous-chroniques et de les intégrer dans une chronique plus complexe. La méthode de focalisation temporelle peut ensuite être appliquée aux sous-chroniques elles-mêmes. Dans le formalisme des chroniques, le processus d’écriture des situations à reconnaître reste une difficulté centrale. Plusieurs réponses y sont apportées. Un système, Frequency Analyser for Chronicle Extraction (FACE) [DD99], permettant à un expert d’analyser des fichiers de logs d’alarmes pour identifier les phénomènes récurrents et ainsi définir des chroniques est développé. A partir d’une grandeur fqmin fournie par l’utilisateur, on définit une notion de chronique fréquente. On construit ensuite par induction sur la taille des chroniques les chroniques fréquentes dans le flux d’évènements étudié, puis les contraintes temporelles associées à l’aide d’un algorithme favorisant certaines contraintes. Partir d’une base de chroniques déjà posée par des experts permet de diminuer considérablement le temps de calcul. Il s’agit ensuite de filtrer l’ensemble des chroniques fréquentes obtenues : pour déterminer s’il est intéressant de chercher à reconnaître à la fois une chronique et l’une de ses sous-chroniques, une notion de dépendance est définie. [FCD04] propose une méthode de pré-traitement des fichiers pour en extraire des sous-fichiers appropriés et ainsi alléger la saturation de mémoire provoquée par FACE. Une seconde méthode d’aide à l’écriture de chroniques est fondée sur une simulation du système qui permet de faire apparaître des configurations caractéristiques d’évènements. Ceci permet de ré- colter les séquences d’évènements datés associés et ainsi de former, pour chaque configuration, une liste de séquences positives (i.e. liées à la configuration) et une liste de séquences négatives. Une mé- thode de programmation logique inductive (ILP) [MDR94] peut ensuite être appliquée sur ces deux listes pour en dériver des chroniques [CD00]. Les techniques d’Inductive Logic Programming (ILP) peuvent être également utilisées directement sur des flux d’évènements, combinées avec l’Inductive Constraint Logic (ICL) [DRVL95] qui permet l’expression de contraintes sur le type de chroniques à apprendre, assurant ainsi une caractérisation précise des situations à reconnaître [QCCW01]. Dans [DG94], Dousson et al. commencent à introduire une notion d’incertitude autour de la datation des évènements du flux en utilisant des ensemble flous pour exprimer les ensembles de dates possibles pour un évènement. 27Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Subias et al. partent du formalisme des chroniques de Dousson et al. et l’adaptent aux systèmes distribués. En effet, il est difficile de développer des mécanismes capables de dater des évènements dans un système distribué, et, de plus, des délais de transmission sont à prendre en compte. Il est donc intéressant de subdiviser l’architecture de contrôle en sous-sites de contrôle pouvant se chevaucher par endroits pour faciliter le diagnostic. Pour ce faire, Subias et al. définissent dans [BSC02] une notion de sous-chronique comme extension de la notion de chronique. Une sous-chronique est composée d’un ensemble d’évènements E et d’un ensemble de contraintes sur les évènements de E mais aussi sur des évènements extérieurs. Une chronique peut alors se décomposer en souschroniques, avec une sous-chronique correspondant à chaque sous-site de contrôle et telles que l’ensemble des évènements E de chaque sous-chronique doit être inclus dans l’ensemble des évènements observables par le sous-site de contrôle concerné. Alors, une chronique est reconnue lorsque toutes les sous-chroniques sont reconnues. Une sous-chronique possède deux types de contraintes : les contraintes locales portant uniquement sur les évènements de E, et les contraintes globales faisant intervenir des évènements extérieurs. Le cadre des réseaux de Petri p- et t-temporels (réseaux de Petri classiques auxquels deux types de mécanismes, détaillés ci-dessous, ont été ajoutés [Kha97, BD91]) est choisi pour modéliser le processus de reconnaissance distribué car, d’après [BSC05] : — il offre une visualisation claire de l’état courant de la reconnaissance de la chronique/souschronique ; — il est approprié pour simuler l’évolution d’une chronique à l’aide d’outils, ou pour revenir en arrière ; — les occurrences multiples sont facilement représentables ; — ils pourraient permettre de démontrer la correction du modèle de contraintes temporelles. Les mécanismes t-temporels (contraintes temporelles de type intervalle sur les transitions) sont utilisés pour exprimer les contraintes de fenêtres d’admissibilité de la chronique (contraintes de type 1 ≤ minp(d(e1) − d(ep)) ≤ 3). Les mécanismes p-temporels (contraintes temporelles sur la durée de séjour admissible d’un jeton dans une place) permettent quant à eux l’expression des contraintes de type intervalle (i.e. du type 1 ≤ d(e1) − d(e2) ≤ 3). Chaque type de contrainte est transposé en une brique de réseau de Petri temporel. Un réseau correspondant à une chronique est réalisé en fusionnant les briques de réseau correspondant à chaque contrainte de la chronique. Dans le réseau obtenu, il n’y a pas de situation de conflit structurel (i.e. il n’y a pas de place précédant plusieurs transitions) car les vérifications de contraintes doivent être réalisées de manière indépendantes. Chaque jeton du réseau obtenu correspond à une instance (partielle ou non) de la chronique. Les occurrences d’évènements sont représentées par des transitions, et les jetons (instances partielles) sont dupliqués et complétés au tirage de ces transitions pour obtenir in fine toutes les reconnaissances complètes [BSC02]. Dans le cas des sous-chroniques, la problématique principale est la vérification des contraintes globales. Pour vérifier celles-ci, la sous-chronique doit recevoir les informations adaptées de l’extérieur. Les transitions et places correspondantes sont donc également ajoutées au réseau. La problématique du délai de transmission entre les sous-sites de contrôle est étudiée dans [BSC04]. Le centre de la question est que ce délai induit une incertitude sur la vérification des contraintes. La méthode employée est la suivante. Le délai ∆ de transmission est supposé borné. Les contraintes glo- 28CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES bales du système sont réécrites sous forme d’expressions dépendant de mesures locales (comme les contraintes locales) et des bornes du délai ∆. La possibilité, entre 0 et 1, de vérifier la contrainte est ensuite quantifiée : on obtient des ensembles flous de valeurs permettant de vérifier les contraintes. Dans les cas où la valeur n’est ni 0 ni 1 mais dans ]0,1[, [BSC04] propose un système de coopération qui peut être lancé pour que la contrainte soit vérifiée par un autre sous-site de contrôle. Pour mieux manipuler ces délais temporels, [BSC05] passe aux réseaux de Petri p- et t-temporels flous. 1.5 Le langage des chroniques Onera 1.5.1 Une première implémentation : CRS/Onera Ornato et Carle présentent une première notion de chronique dans [OC94a, OC94b]. Il s’agit de répondre à la problématique de l’automatisation de la reconnaissance des intentions d’un agent considéré comme une boîte noire. Contrairement au domaine de la reconnaissance de plans, les auteurs ne font pas d’hypothèse forte sur le sujet observé : il n’est pas nécessaire d’avoir une base de connaissance exhaustive décrivant les différents plans pouvant être suivis par le sujet, et, en particulier, le sujet n’est pas supposé effectuer les plans sans erreur ni n’en suivre qu’un seul à la fois. De plus, les auteurs souhaitent pouvoir exprimer des notions telles que la suspension ou l’abandon d’un but. Dans cette optique, un système de reconnaissance de comportements, Chronicle Recognition System/Onera (CRS/Onera) est implémenté. Il est fondé sur un langage temporel, le langage des chroniques, qui permet la description de comportements complexes à l’aide d’évènements typés pouvant être dotés de propriétés et des opérateurs suivants : — la séquence, le non-ordre (conjonction) et la disjonction, — la non-occurrence d’une chronique sur un intervalle de temps délimité par une seconde chronique (notons qu’il n’y a pas de garantie d’ordre de traitement entre les deux chroniques à l’arrivée d’un évènement et qu’il y a donc des formes indéterminées), — une notion de délai, — un opérateur de coupure, le cut, permettant de réduire la combinatoire due à l’exhaustivité recherchée dans le processus de reconnaissance : le cut désigne uniquement la première reconnaissance dans le flux, — opérateur d’indexation d’évènements permettant d’identifier à une unique occurrence plusieurs évènements de même nom dans une chronique (les opérateurs de non occurrence et de disjonction sont cependant opaques pour l’indexation). Le système de reconnaissance CRS/Onera se voit imposer trois contraintes principales : 1. les reconnaissances doivent être exhaustives (i.e. toutes les reconnaissances possibles doivent être détectées) ; 2. il doit y avoir une historisation des évènements (i.e. il faut être capable de dire quels évènements sont à l’origine de chaque reconnaissance) ; 3. le processus de reconnaissance doit être suffisamment efficace pour être réalisé en ligne. Pour répondre à ces contraintes, l’algorithme de CRS/Onera a été conçu sur la base d’automates dupliqués représentant les instances éventuellement partielles des chroniques à reconnaître. Chaque 29Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements reconnaissance partielle de chronique est dupliquée et mise en attente des évènements attendus pour la complétion de la reconnaissance. Cette duplication permet à la fois d’assurer l’exhaustivité du processus et également de gérer les constructions de non-occurrence. CRS/Onera propose également la gestion d’actions et de tests à la reconnaissance. Il est possible d’exprimer des conditions à vérifier sur la reconnaissance : si l’expression précisée est fausse, alors l’instance de chronique est éliminée. D’autre part, un évènement peut être envoyé dans le flux à la suite d’une reconnaissance. Celui-ci peut ensuite être utilisé dans une autre chronique et ainsi définir des chroniques de niveau supérieur. Il y a également la possibilité d’exécuter du code C++ avant que le système n’engendre d’évènement, ou après. CRS/Onera se compose d’un compilateur engendrant du code C++. L’utilisateur décrit des fichiers de systèmes de chroniques et le compilateur CRS/Onera engendre le code C++ correspondant avec un facteur d’expansion d’environ 50. Celui-ci est ensuite compilé. Chaque chronique est alors une classe dont les méthodes gèrent les évolutions et les duplications d’instances. 1.5.2 Définition d’une sémantique du langage des chroniques Dans la lignée de CRS/Onera s’inscrivent les travaux de Bertrand et al. [Ber09] dont l’objectif est d’établir une sémantique du langage des chroniques de CRS/Onera. Une sémantique ensembliste est donnée dans [Ber09] puis aboutie dans [CCK11] pour quatre opérateurs de base (la séquence, la conjonction, la disjonction et l’absence). Un ensemble de reconnaissances est défini pour chaque chronique, explicitant formellement ce que cela signifie de reconnaître dans un flux d’évènements donné le comportement décrit par une chronique. Cette sémantique est détaillée dans la sous-section suivante (1.5.3). Une seconde sémantique opérationnelle est également développée. Une comparaison de différentes modélisations possibles du processus de reconnaissance de chroniques est réalisée dans [BCC07]. Les auteurs se concentrent sur deux principales difficultés : la multiplicité des reconnaissances et l’historisation des évènements donnant lieu aux reconnaissances. Les automates standards à états finis permettent la reconnaissance d’expressions régulières, mais une chronique, de par la multiplicité de la notion de reconnaissance, n’est pas une expression régulière. Un automate standard ne peut donc reconnaître qu’une seule fois une chronique ce qui ne répond pas à la problématique initiale. Si l’on introduit des automates à compteurs, les occurrences multiples d’une chronique peuvent alors être comptabilisées mais il n’est alors pas possible de distinguer les différentes reconnaissances comme il n’y a pas d’historisation des évènements. En revanche, les automates dupliqués, en créant une instance d’automate pour chaque reconnaissance partielle d’une chronique, permettent de reconnaître toutes les occurrences d’une chronique tout en préservant l’information de quels évènements ont donné lieu à chaque reconnaissance. Cependant, cette méthode ne permet pas d’avoir une approche modulaire dans le processus d’écriture de chroniques. Dans cette optique, les réseaux de Petri colorés qui permettent multiplicité et historisation, sont choisis car non seulement ils sont dotés de moyens de construction modulaire, mais encore des outils d’édition, de simulation et d’analyse sont disponibles pour mettre en avant les propriétés des réseaux. Une sémantique en réseaux de Petri colorés est donc établie [BCC08, BCC09, Ber09, CCK11]. 30CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Un réseau est construit pour chaque chronique. Les transition du réseau sont tirées en fonction du flot d’évènement et les reconnaissances (éventuellement partielles) sont produites et/ou complétées en conséquence. La construction de ces réseaux se fait par induction sur la structure du langage à partir de briques de base, mais celle-ci n’est pas formalisée entièrement. 1.5.3 Détail de la sémantique ensembliste du langage des chroniques de CRS/Onera Dans cette sous-section, nous détaillons précisément la sémantique du langage des chroniques telle que présentée dans [CCK11]. Nous présentons le langage des chroniques puis formalisons le concept d’évènement pour pouvoir ensuite définir la notion de reconnaissance d’une chronique. Une chronique décrit un certain agencement d’évènements. Le langage est construit à partir d’évènements simples et des opérateurs suivants, où C1 et C2 sont des chroniques : — la disjonction C1 | | C2 qui correspond à l’occurrence d’au moins l’une des deux chroniques C1 et C2. — la conjonction C1&C2 qui correspond à l’occurrence des deux chroniques C1 et C2, dans un ordre quelconque, éventuellement entrelacées. C1 C2 — la séquence C1 C2 qui correspond à l’occurrence de la chronique C1 suivie de l’occurrence de la chronique C2. C1 C2 — l’absence (C1) − [C2] qui correspond à l’occurrence de la chronique C1 sans occurrence de la chronique C2 pendant l’occurrence de C1. Formellement, on définit le langage des chroniques à partir d’un ensemble donné de noms d’évènement comme suit : Définition 1 (langage des chroniques). Soit N un ensemble dénombrable dont les éléments sont des noms d’évènement simple. On définit l’ensemble des chroniques sur N, noté X(N), par le schéma inductif suivant : A ∈ N A ∈ X(N) (nom) C1 ∈ X(N) C2 ∈ X(N) C1 | | C2 ∈ X(N) (disjonction) C1 ∈ X(N) C2 ∈ X(N) C1&C2 ∈ X(N) (conjonction) C1 ∈ X(N) C2 ∈ X(N) C1 C2 ∈ X(N) (séquence) C1 ∈ X(N) C2 ∈ X(N) (C1) − [C2] ∈ X(N) (absence) Considérons deux exemples illustrant informellement l’expressivité du langage. Exemple 1. Soit A, B et D des noms d’évènement simple de N. La chronique (A&B) | | D correspond à deux évènements de noms respectifs A et B dans un ordre quelconque ou à un évènement de nom D. 31Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Exemple 2. Soit A, B, D et E des noms d’évènement simple de N. La chronique (A B)−[D | | E] correspond à un évènement de nom A suivi d’un évènement de nom B, sans occurrence ni d’un évènement de nom D ni d’un évènement de nom E entre les occurrences de A et B. Évènements Nous souhaitons définir la notion de reconnaissance de chronique afin de munir le langage d’une sémantique. Pour ce faire, il est nécessaire de formaliser au préalable le concept d’évènement et les notions qui lui sont associées. Définition 2 (évènements). Soit N un ensemble dénombrable de noms d’évènement. Soit E un ensemble dénombrable dont les éléments sont des évènements. Une fonction de nommage est une fonction totale ν : E 7→ N. Elle associe un nom à chaque évènement. Le triplet (E, N, ν) est alors appelé espace nommé d’évènements. Remarque 1. On distingue ainsi les noms des évènements (qui servent à construire les chroniques) que l’on notera par convention en majuscules (A, B, C, D, . . .) et les évènements (qui constituent les données observées à analyser) que l’on notera en minuscule (a, b, c, d, . . .). Pour faciliter la compréhension, on posera en général ν(a) = A, ν(b) = B, . . . Définition 3 (flux d’évènements). Soit (E, N, ν) un espace nommé d’évènements et soit I ⊆ N. Un flux d’évènements est une suite ϕ = (ui)i∈I d’éléments de E. On notera son domaine ◦ ϕ. On a ainsi I = ◦ ϕ. Il s’agit de l’ensemble des indices d’occurrence des évènements. Par convention, si rien n’est spécifié, on commencera la numérotation à 1 (car cela correspondra à celle engendrée par le modèle de reconnaissance en réseaux de Petri colorés qui sera présenté Chap. 3 et 4). Si ϕ = (ui)i∈I est un flux d’évènements et si J ⊆ I, on définit la restriction de ϕ à J, notée ϕ|J , par ϕ|J = (ui)i∈J . Pour un flux ϕ = (ui)i∈I , on définit les fonctions Eϕ(i) = ui et Nϕ(i) = ν(Eϕ(i)) = ν(ui). Eϕ(i) correspond au i e évènement du flux ϕ. Nϕ(i) correspond au nom du i e évènement du flux ϕ. Reconnaissance d’une chronique Il s’agit maintenant de s’appuyer sur les définitions précédentes pour doter le langage d’une sémantique ensembliste définissant la notion de reconnaissance de comportements. Une reconnaissance d’une chronique est représentée par l’ensemble exact des indices des évènements ayant donné lieu à la reconnaissance. Il est donc nécessaire de commencer par définir les notions suivantes liées aux indices. Définition 4 (instances). Soit (E, N, ν) un espace nommé d’évènements sur lequel est défini un flux d’évènements ϕ = (ui)i∈I . 32CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Une instance de ϕ est un sous-ensemble fini de I. Un support de ϕ est un sous-intervalle fini de I. (Ainsi, tout support de ϕ est une instance de ϕ.) Le support d’une instance r de ϕ est l’ensemble [r] = {i ∈ I : min r ≤ i ≤ max r}. On notera ]r] = [r] \ {min r} et [r[= [r] \ {max r}. On dit que deux instances r et r 0 de ϕ sont compatibles, noté r ./ r0 , si max r < min r 0 (c’est- à-dire si r « précède » r 0 ). On définit la relation ternaire « r est la réunion compatible de r1 et r2 » par r = r1 ./ ∪ r2 si, et seulement si, r1 ./ r2 ∧ r = r1 ∪ r2. Remarque 2. ./ est une relation d’ordre strict sur les instances de I. Pour chaque chronique, en fonction du flux ϕ étudié, on définit par induction l’ensemble des reconnaissances associées. Définition 5 (ensembles de reconnaissances). Soit (E, N, ν) un espace nommé d’évènements sur lequel est défini un flux d’évènements ϕ = (ui)i∈I . Soit C ∈ X(N). On définit par induction l’ensemble des reconnaissances de C sur le flux ϕ, noté RC (ϕ) : — si C = A ∈ N, alors RA(ϕ) = {{i} : i ∈ ◦ ϕ ∧ Nϕ(i) = A}. La chronique A est reconnue lorsqu’un évènement de nom A a lieu. — si C = C1 | | C2, alors RC (ϕ) = RC1 (ϕ) ∪ RC2 (ϕ). La chronique C1 | | C2 est reconnue si la chronique C1 est reconnue ou si la chronique C2 est reconnue. — si C = C1&C2, alors RC (ϕ) = {r1 ∪ r2 : r1 ∈ RC1 (ϕ) ∧ r2 ∈ RC2 (ϕ)}. La chronique C1&C2 est reconnue si la chronique C1 est reconnue et si la chronique C2 est également reconnue, sans autre contrainte. C1 C2 — si C = C1 C2, alors RC (ϕ) = {r1 ∪r2 : r1 ∈ RC1 (ϕ)∧r2 ∈ RC2 (ϕ)∧r1 ./ r2}. La chronique C1 C2 est reconnue si la chronique C1 est reconnue, si la chronique C2 est reconnue et si la reconnaissance de C1 précède le début de la reconnaissance de C2. C1 C2 — si C = (C1)−[C2], alors RC (ϕ) = {r1 : r1 ∈ RC1 (ϕ)∧(Pf([r1[)∩RC2 (ϕ) = ∅)} où, pour tout ensemble s, Pf(s) est l’ensemble des parties finies de s. La chronique C = (C1) − [C2] est reconnue si la chronique C1 est reconnue et s’il n’y a pas eu de reconnaissance de la chronique C2 pendant la reconnaissance de la chronique C1. Ainsi, pour une chronique C et un flux ϕ, chaque reconnaissance de C dans ϕ correspond à un ensemble d’indices (les indices des évènements donnant lieu à la reconnaissance), et RC (ϕ) est l’ensemble de tous ces ensembles. Exemple 3. Soit a, b, d et e des évènements de E tels que ν(a) = A, ν(b) = B, ν(d) = D et ν(e) = E. 33Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Considérons la chronique C = (A&B) | | D et le flux ϕ = (a, e, b, d, a, b) avec ◦ ϕ = J1, 6K. On a alors RC (ϕ) = {{4}, {1, 3}, {1, 6}, {3, 5}, {5, 6}}. aebdab 1 23 456 Exemple 4. Soit a, b, d, e, f et g des évènements de E tels que ν(a) = A, ν(b) = B, ν(d) = D, ν(e) = E, ν(f) = F et ν(g) = G. Considérons la chronique C = (A B) − [F] et le flux ϕ = (d, a, e, a, b, g, a, f, b) avec ◦ ϕ = J1, 9K. On a alors RC (ϕ) = {{2, 5}, {4, 5}}. Notons que {2, 9}, {4, 9} et {7, 9}, bien qu’étant des reconnaissances de A B, ne sont pas des reconnaissances de C car Nϕ(8) = F. Exemple 5. Soit a, b, d et e des évènements de E tels que ν(a) = A, ν(b) = B, ν(d) = D et ν(e) = E. Considérons la chronique C = (A B) − [D E] et le flux ϕ = (a, d, a, e, b) avec ◦ ϕ = J1, 5K. On a alors RC (ϕ) = {{3, 5}}. {1, 5} n’est pas une reconnaissance de C car {2, 4} ∈ RD E(ϕ) et {2, 4} ⊂ J1, 5K. Exemple 6. Soit a, b, d, e, f et g des évènements de E tels que ν(a) = A, ν(b) = B, ν(d) = D, ν(e) = E, ν(f) = F et ν(g) = G. Considérons la chronique C = (A B) − [(D E) − [F G]] et le flux ϕ = (a, d, f, g, e, b) avec ◦ ϕ = J1, 6K. On a alors RC (ϕ) = {{1, 6}} car R(D E)−[F G](ϕ) = {}. Remarque 3. On peut montrer par induction directe sur les chroniques que, pour tout C ∈ X(N), RC ({}) = {}. 1.6 D’autres modes de représentation et de reconnaissance de comportements Dans les quatre sections précédentes, nous avons détaillé différentes approches du traitement d’évènements complexes. Dans cette section, nous présentons plus succinctement une dernière sélection de systèmes de reconnaissance de comportements moins proches de notre problématique. Nous renvoyons à [CM12] pour une collection plus complète de systèmes d’IFP. Dans [CM12], les problématiques et différentes options envisageables pour l’IFP sont détaillées, puis un grand nombre de systèmes sont présentés, répartis en quatre groupes : — le domaine des bases de données actives ; — les systèmes de gestion de flux de données ; — les systèmes de CEP ; — les systèmes disponibles dans le commerce. 34CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Nous renvoyons également à d’autres surveys pour une vision plus complète [dCRN13, FTR+10, ASPP12]. [FTR+10] présente le CEP conjointement avec le domaine de l’analyse prédictive à travers une selection d’articles, d’outils commerciaux puis d’outils académiques ou en libre accès. [ASPP12] compare les chroniques de Dousson (Section 1.4), l’EC (Section 1.2) et la logique de Markov qui permet la prise en compte d’incertitudes dans le domaine du CEP [BTF07, dSBAR08, HN03, TD08, KDRR06]. Les trois approches sont comparées sur trois axes : la description des comportements à reconnaître, le raisonnement à réaliser pour effectuer la reconnaissance, et les méthodes d’apprentissage existant pour mettre en œuvre l’écriture des comportements. MUSE [KM87] Kumar et Mukerjee établissent un système de reconnaissance incrémental appelé MUSE. Le modèle de temps adopté est linéaire et discret, avec une résolution suffisamment fine. Un évènement est un couple (ϕ, τ ) où ϕ correspond à un nom d’évènement et τ est un ensemble d’instants consécutifs, décrivant ainsi un certain intervalle de temps. Des assertions temporelles peuvent être utilisées : les 13 assertions de Allen ainsi que quatre autres relations permettant d’exprimer des relations entre des évènements encore « incomplets » (i.e. dont l’ensemble d’instants consécutifs où l’évènement est vérifié n’est pas encore complet). Ceci permet d’assurer que, pour chaque couple d’évènements donné, une unique des ces dix-sept assertions est toujours vérifiée. Le processus de reconnaissance peut ainsi être effectué au fur et à mesure, à l’aide d’automates à états finis qui résument les différentes règles. Des conjonctions et disjonctions d’assertions peuvent ensuite être spécifiées. Pour finir, une sémantique temporelle sur les évènements permet de définir l’ensemble d’instants α d’une reconnaissance et ainsi de s’adapter à différents cas : on peut avoir tout simplement α = τ , mais on peut aussi définir α = min(τ ) (sémantique instantanée) ou d’autres sémantiques plus complexes. SAMOS [GD94b, GD94a] Swiss Active Mechanism based Object-oriented database Systems (SAMOS) est un système de gestion de base de données actives qui offre notamment un langage de description de comportements qui permet de spécifier des évènements complexes à intégrer aux règles de gestion. Les évènements considérés sont ponctuels (pour les évè- nements complexes, une algèbre d’évènements permet de définir leur instant d’occurrence) et dotés de paramètres. Des opérateurs – disjonction, conjonction, séquence, n occurrences dans un intervalle donné, absence d’occurrence dans un intervalle donné, première occurrence uniquement sur un intervalle donné – permettent de composer les évènements. Le mot clé same peut être apposé à un évènement complexe pour préciser des contraintes d’égalité sur les paramètres des évènements mis en jeu. Le système est également doté d’un intervalle de suivi des évènements indiquant une fenêtre dans laquelle reconnaître un comportement donné (reconnaître E dans I). Cet intervalle peut aussi bien être délimité explicitement avec des instants absolus qu’implicitement, et il peut être défini pour réapparaître périodiquement. Pour certaines constructions comme l’absence d’un comportement, il est obligatoire de préciser un tel intervalle. [GD94a] propose un modèle de reconnaissance des évènements complexes ainsi définis à l’aide d’un formalisme proche des réseaux de Petri colorés, car celui-ci permet de faire circuler dans le réseau les informations relatives aux paramètres des évènements complexes ou non. La notion de SAMOS Petri nets (S-PN) est introduite. Il s’agit de réseaux de Petri colorés possédant trois types de places, les places en entrée correspon- 35Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements dant aux évènements composant un évènement complexe, les places en sortie correspondant aux évènements complexes, et des places auxiliaires. Les opérateurs sont représentés par des transitions, et le mot clé same par une garde éventuelle sur les transitions. Une contrainte « d’absence de conflit » est imposée, c’est-à-dire qu’un jeton ne peut pas activer deux places simultanément. Seules les constructions relatives à la conjonction et à la reconnaissance de n occurrences sur un intervalle sont présentées. Lorsqu’un évènement complexe fait partie de la composition d’un autre évènement complexe, les réseaux correspondants sont combinés. Inversement, lorsqu’un évènement simple participe à plus d’un événement complexe, le jeton correspondant à l’évènement simple est dupliqué ; ainsi, à l’occurrence d’un évènement, seule une place doit être marquée. Ce modèle de reconnaissance est implémenté au sein de SAMOS. GEM [MSS97, MSS96] Le langage Generalised Event Monitoring (GEM) est un langage déclaratif fondé sur un système de règles et s’attachant à la reconnaissance de comportements dans le cadre de systèmes distribués. La seule hypothèse réalisée est l’existence d’une horloge globale bien synchronisée. Les évènements considérés sont dotés d’attributs, dont par défaut, la classe d’évènement auquel l’évènement appartient, le composant du système dont il est issu et son instant d’occurrence. Des évènements complexes peuvent être construits à l’aide d’opérateurs de conjonction, de délai suivant une reconnaissance, d’absence d’un évènement complexe entre deux autres évènements, de disjonction, et de séquence. Une garde optionnelle peut exprimer des contraintes sur les attributs et sur les instants de début et de fin des reconnaissances, ce qui permet notamment de décrire l’ensemble des relations d’Allen, et un opérateur d’identification permet de se référer à une instance précise d’un évènement dans une règle. Les règles sont construites en quatre parties : — un identifiant unique de la règle ; — une fenêtre de détection déterminant la durée pendant laquelle doit être conservé l’historique des évènements liés à la règle ; — la description de l’évènement complexe à reconnaître ; — les actions à effectuer si l’évènement complexe est détecté (actions de notification explicite de l’évènement – interne ou externe à la règle –, transfert de certains évènements ayant donné lieu à la reconnaissance – dans une visée de filtrage par exemple –, activation ou désactivation de règles. Des commandes de contrôle globales similaires aux actions ci-dessus sont également disponibles. Le processus de détection des comportements est fondé sur une structure arborescente associée à chaque comportement à reconnaître et suivant la structure de l’expression du comportement. Chaque nœud possède un type identifiant l’opérateur dont il s’agit, la garde associée, et l’historique des évènements correspondants. À l’arrivée d’un évènement, celui-ci est inséré à sa place dans l’arbre, sans considération temporelle autre, ce qui permet d’autoriser un retard dans l’arrivée des évènements, dans la limite de la fenêtre temporelle de détection définie. La gestion du retard des évènements se fait donc au sein même de l’étape de détection. Au niveau de chaque nœud, l’historique des évènements concernés est conservé, dans le cadre de la fenêtre de détection, ce qui permet de diminuer les évènements à ordonner. Des pointeurs sont également utilisés pour éviter la duplication d’historiques. [MSS96] décrit l’intégration et l’implémentation de GEM en C++. 36CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Rete [For82, Ber02, WBG08, WGB08] Rete [For82] est un algorithme permettant de comparer une grande quantité de motifs (patterns) à une grande quantité d’objets. Il s’agit de déterminer l’intégralité des correspondances correctes et l’accent est porté en particulier sur l’efficacité du système. La version originale de Rete ne permet pas de considérations temporelles, et il existe de nombreuses extensions de ce système. [Ber02] introduit dans Rete une sémantique temporelle où tout évènement simple ou complexe est considéré comme ponctuel. Les règles définissant les comportements à reconnaître sont compilées pour obtenir des graphes composés de trois types de nœuds : les nœuds de classe qui filtrent les faits selon les classes, les nœuds de jonction qui combinent les faits, et les nœuds de discrimination qui filtrent les faits selon leurs attributs. Les faits sont alors stockés au niveau de chaque nœud et sont propagés en fonction des règles transcrites. Pour la gestion des contraintes temporelles, une horloge interne discrète est introduite conjointement avec une notion d’évènement qui s’oppose à la notion de fait. Les évènements sont datés et des contraintes temporelles peuvent être spécifiées sur les dates d’occurrence (on rappelle que chaque évènement même complexe est considéré comme ponctuel) avec les prédicats before et after bornant à un intervalle la différence entre les deux dates d’occurrence des évènements. Les contraintes peuvent être combinées avec des opérateurs de disjonction, de conjonction et de négation. L’accent est mis sur l’importance de la notion de changement d’état qui peut être exprimée à l’aide des évènements introduits. L’introduction de contraintes temporelles permet une gestion de la mémoire à l’intérieur même du système : les évènements rendus obsolètes sont oubliés. Une autre extension de Rete est développée dans [WBG08]. Elle s’oppose à [Ber02] dans la considération des évènements qui ne sont plus ponctuels mais dotés d’un instant de début et d’un instant de fin, ce qui est fondamental pour éviter des erreurs de reconnaissance dans le cas de séquences (problématique mise en avant dans [GA02]). Rete est donc étendu avec une sémantique temporelle d’intervalle qui permet l’expression des treize relations d’Allen étendues de deux manières : — possibilité de définir la valeur exacte ou une plage de valeurs sur la durée séparant l’instant de début et l’instant de fin de deux intervalles de temps dans le cas des opérateurs non restrictifs (during, finishes, starts, overlaps, before) ; — définition possible de limites de tolérance au niveau des opérateurs restrictifs (par exemple pour equals). Il faut noter que ces extensions suppriment le caractère exclusif des opérateurs d’Allen mais permettent de s’adapter aux situations réelles que l’on peut souhaiter exprimer. Un système de calcul de la durée de vie des évènements est implémenté, découlant des contraintes temporelles spécifiées. [WGB08] présente une extension de Rete complémentaire à [WBG08] pour la gestion de fenêtres temporelles de validité autour des évènements. Ces fenêtres temporelles rendent obsolètes les évènements dont l’instant de fin sort de la fenêtre – notons qu’un évènement peut donc commencer avant la fenêtre dans laquelle il est considéré. Snoop [CM94, CKAK94], SnoopIB [AC06] Le domaine des bases de données actives se consacre notamment à surveiller la séquence d’évènements affectant la base de donnée depuis l’extérieur. Le système reconnaît des comportements et peut y réagir suivant des règles EventCondition-Action (ECA) spécifiant les comportements à reconnaître et les actions à effectuer 37Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements lors de la détection. Snoop [CM94] est un tel système. Il est construit sur un modèle de temps linéaire discret et permet l’analyse d’évènements primitifs ne pouvant avoir d’occurrences simultanées et composés à la fois : — d’évènements explicites externes fournis au système avec leurs paramètres contenant au moins le type de l’évènement ainsi que sa date ; — d’évènements temporels pouvant être absolus (c’est-à-dire datés) ou relatifs (i.e. placés temporellement par rapport à un autre évènement de Snoop) ; — d’évènements de la base de donnée correspondant aux opérations de manipulation des données. Les évènements composites à reconnaître sont définis à partir de ces évènements primitifs et des opérateurs de disjonction, de séquence, de conjonction, n occurrences parmi . . . , l’opérateur apériodique A(E1, E2, E3) (E2 a lieu entre E1 et E3) et l’opérateur périodique P(E1, [t], E3) (E1 puis E3 dure exactement [t]. Notons qu’il n’y a pas alors d’expression de négation ou d’absence (la difficulté est évoquée dans la Section 5.4 de [CM94]). Les évènements sont tous considérés comme ponctuels et la notion de modificateur d’évènement est introduite pour définir l’instant d’occurrence d’un évènement initialement non ponctuel. Par défaut, il existe deux modificateurs d’évènements, à savoir begin_of et end_of. Le choix de multiplicité des reconnaissances dans le processus de reconnaissance de ces comportements complexes varie selon le contexte adopté parmi le contexte récent, le contexte chronique, le contexte continu et le contexte cumulatif présentés dans la Section 1.1. Le processus de reconnaissance est fondé sur des graphes associés à chaque évènement complexe à reconnaître et obtenus après compilation des expressions de ces évènements. Les arbres suivent la structure des expressions concernées, et, dans le cas de sous-expressions identiques, les parties associées de l’arbre sont amalgamées. Dans [CM94], un algorithme est détaillé pour le contexte récent qui permet l’utilisation d’un buffer de taille fixe au niveau de chaque nœud des arbres (contrairement aux contextes continu et cumulatif qui demandent beaucoup d’espace mémoire). Une notion d’équivalence d’expressions est définie et peut permettre de réécrire une description de comportement sous une autre forme pour optimiser le processus de reconnaissance par exemple en dévoilant des nouvelles sous-expressions communes. [CKAK94] présente la sémantique de Snoop à l’aide de formules logiques du premier ordre. Cependant, comme pour Rete, la considération d’évènements uniquement ponctuels pose problème dans le cas de composition avec une séquence par exemple car il faut pouvoir également comparer les instants d’initiation (et pas uniquement ceux de terminaison) des reconnaissances (problématique mise en avant dans [GA02]). Pour répondre à ce problème, [AC06] propose SnoopIB, une nouvelle sémantique fondée sur des intervalles et dont la définition formelle est en partie présentée dans [GA02]. Deux nouveaux opérateurs sont introduits, à savoir l’opérateur de non occurrence d’un évènement entre l’instant de terminaison d’un évènement et l’instant d’initiation d’un autre évènement, et l’opérateur plus exprimant l’occurrence d’un évènement suivi d’une durée. 38CHAPITRE 1. SYSTÈMES DE TRAITEMENT FORMEL D’ÉVÈNEMENTS COMPLEXES Domaines d’application Au travers de cette sélection de systèmes d’analyse d’évènements complexes, nous avons un aperçu général des différentes approches possibles, dans des domaines variés. La multiplicité de ces systèmes est due au large éventail d’applications possibles de la reconnaissance de comportements. Nous donnons ici un échantillon des différents domaines dans lesquels l’IFP s’est montrée utile : — supervision et l’analyse de situations dangereuses à l’aide d’un drone pour aider les services de police [Hei01, DKH09a, DKH09b, DGK+00], avec des chroniques ; — de nombreux domaines d’application en médecine comme le monitoring cardiaque où des méthodes d’apprentissage sont appliquées[CD00, CCQW03, QCC+10, Doj96, Por05, CD97], avec des chroniques ; — gestion d’alarmes pour la détection d’intrusions informatique [MD03], avec CRS et les chroniques de Dousson et al. ; — diagnostic de web-services [PS09, CGR+07, LGCR+08], avec des chroniques ; — évaluation de la qualité de transports publics (projet PRONTO) [KVNA11, VL10], avec l’EC ; — surveillance vidéo (projet CAVIAR) [SA11, ASP10b, ASP10a, AP09], avec l’EC ; — analyse des médias sociaux [SA11] ; — aide à la prise de décision dans le cadre de combats aériens [CV98], avec des chroniques ; — supervision et gestion de réseaux [SEC+10], avec des chroniques ; — dans l’industrie, supervision d’une turbine à gaz dans une usine pétrochimique [MNG+94] et supervision d’une usine de lait [MCCDB10], avec des chroniques ; — caractérisation d’activité humaine [CMM12], avec des chroniques. Après cette introduction et ce survol des systèmes existants, nous allons développer le système de reconnaissance de comportements des Chroniques/Onera afin de se rapprocher d’un système répondant aux enjeux évoqués dans la Section 1.1. 39Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements 40Chapitre 2 Construction d’un cadre théorique pour la reconnaissance de comportements : le langage des chroniques Sommaire 3.1 Définition du formalisme des réseaux de Petri colorés . . . . . . . . 70 3.1.1 Types et expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.1.2 Réseaux de Petri colorés . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.1.3 La fusion de places . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.1.4 Arcs inhibiteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.2 Construction formelle des réseaux dits « à un seul jeton » . . . . . 77 3.2.1 Types et expressions utilisés dans le modèle . . . . . . . . . . . . . . . . 77 3.2.2 Structure générale des réseaux « à un seul jeton » . . . . . . . . . . . . 79 3.2.3 Briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.2.4 Construction par induction . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.3 Formalisation et description de l’exécution des réseaux . . . . . . . 89 3.3.1 Reconnaissance d’un évènement simple . . . . . . . . . . . . . . . . . . . 89 3.3.2 Reconnaissance d’une séquence . . . . . . . . . . . . . . . . . . . . . . . 91 3.3.3 Reconnaissance d’une disjonction . . . . . . . . . . . . . . . . . . . . . . 94 3.3.4 Reconnaissance d’une conjonction . . . . . . . . . . . . . . . . . . . . . 95 3.3.5 Reconnaissance d’une absence . . . . . . . . . . . . . . . . . . . . . . . . 99 3.3.6 Définition formelle de la stratégie de tirage . . . . . . . . . . . . . . . . 106 3.4 Démonstration de la correction du modèle « à un seul jeton » . . . 107 41Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements 3.5 Étude de la taille des réseaux . . . . . . . . . . . . . . . . . . . . . . . 115 3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 De nombreuses applications concrètes de la reconnaissance de comportements nécessitent notamment des moyens à la fois de validation et de traçabilité, comme il sera illustré dans le Chapitre 5. Pour cela, il s’agit de fournir un cadre théorique solide pour la reconnaissance de comportements en adoptant une approche purement formelle qui assure une possibilité de vérification et d’analyse du processus de reconnaissance. Dans ce chapitre, nous posons ce cadre théorique en développant un langage de description de comportements, le langage des chroniques introduit dans la Section 1.5 1 , et en formalisant le processus de reconnaissance associé à l’aide d’une sémantique [PBC+] : — nous développons un formalisme autour de la notion d’évènement et de leurs attributs ; — nous étendons largement la syntaxe du langage des chroniques de [CCK11] avec des constructions permettant non seulement l’expression de contraintes temporelles variées mais aussi la spécification de contraintes complexes sur des attributs d’évènement ; — nous introduisons une nouvelle représentation de la notion de reconnaissance de chronique, en passant d’ensembles d’ensembles à des ensembles d’arbres ce qui donne une structure des reconnaissances plus précise et permet ainsi des opérations plus fines sur les reconnaissances ; — nous formalisons le processus de reconnaissance à travers une sémantique du langage que nous avons étendu ; — nous rendons possible l’implémentation du processus de reconnaissance avec un modèle de temps continu grâce à une fonction « Look-ahead » qui fournit le prochain instant où interroger le programme. Dans une première section (2.1), nous posons les définitions générales formalisant le contexte de notre travail d’analyse de comportements complexes, à savoir les notions d’évènement et d’attributs d’évènement. Nous définissons ensuite dans la Section 2.2 la syntaxe étendue du langage des chroniques, permettant notamment la spécification à la fois de contraintes sur des attributs d’évènement et de contraintes temporelles exprimant des exigences sur les délais. La Section 2.3 définit ensuite la sémantique du langage des chroniques, spécifiant ainsi la notion de reconnaissance, et ce après avoir défini une nouvelle représentation arborescente des reconnaissances. Pour nous familiariser avec le langage des chroniques et pour simplifier les démonstrations à venir, nous étudions dans la Section 2.4 les principales propriétés du langage. Dans la visée d’une implémentation du processus de reconnaissance et pour assurer la gestion d’un modèle de temps continu, nous définissons dans la Section 2.5 une fonction dite de « Look-ahead » qui permet par la suite le pilotage des appels au processus de reconnaissance. Le chapitre s’achève avec un tableau récapitulatif informel des propriétés du langage construit dans la Section 2.6. 1. Rappelons que les chroniques étudiées ici se réfèrent à celles introduites par P. Carle dans [CBDO98] qui diffèrent de celles introduites par C. Dousson dans [DGG93]. 42CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES 2.1 Définitions générales préalables L’objectif de cette section est de formaliser la notion d’évènement qui sera manipulée tout au long du chapitre. Nous reprenons le cadre formel posé dans la Section 1.5 [CCK11] en introduisant la notion d’attribut dans la formalisation du concept d’évènement. En effet, nous souhaitons maintenant considérer des évènements munis d’informations (par exemple un identifiant, une qualité, des coordonnées, une vitesse, . . .) sur lesquelles il sera ensuite possible de raisonner en effectuant des comparaisons ou des calculs, et de poser des contraintes. Cette extension primordiale est motivée par de nombreuses applications qui nécessitent de pouvoir raisonner sur des données liées aux évènements du flux que l’on souhaite analyser. Par exemple, supposons que nous surveillons un avion en vol dans le but de s’assurer que la fréquence radio sur laquelle il est réglé correspond bien à celle associée à sa zone de vol. Il faut identifier les évènements relatifs à l’avion au milieu de tous les autres évènements, puis accéder aux données relatives à la fréquence radio et à la position de l’appareil afin d’effectuer des comparaisons entre elles. Dans une autre situation, on peut également être amené à effectuer des calculs, pour évaluer la distance entre deux avions et garantir une distance minimale. Nous allons donc introduire la notion d’attribut d’évènement. Les évènements observés pourront être dotés d’une ou plusieurs caractéristiques, que nous appellerons attributs ou propriétés. Nous cherchons à reconnaître des agencements complexes de tels évènements, agencements décrits par des formules de chroniques que nous définirons par la suite. Dans ces chroniques, nous souhaitons exprimer des contraintes sur ces attributs d’évènement. Pour manipuler librement ces propriétés, nous construisons, à partir des attributs d’évènement, des attributs de reconnaissance de chronique qui auront un rôle similaire, à savoir représenter des informations liées au comportement plus global décrit par la chronique. Ainsi, si l’on souhaite écrire des chroniques pour réaliser de l’évitement de collision à partir de mesures radar, il peut être intéressant d’écrire une première chronique calculant la distance entre deux aéronefs à partir des données brutes du radar. Cette chronique correspond alors à la reconnaissance d’une distance avec comme propriétés les identifiants des deux appareils ainsi que la donnée numérique de la distance calculée. La chronique peut ensuite être utilisée au sein d’autres chroniques pour engendrer des alertes par exemple. La chronique, munie de ses nouveaux attributs, peut alors être considérée comme un évènement complexe de plus haut niveau, souvent non ponctuel, et formant une abstraction des évènements du flux. La chronique obtenue peut alors être utilisée pour former une autre chronique, au même titre qu’un simple évènement, et l’on peut disposer de ses attributs. Pour définir ces notions d’évènement et d’attribut, on considère les trois ensembles suivants : — N un ensemble dénombrable de noms d’évènement, contenant un élément τ utilisé pour nommer les instants temporels purs ; — P un ensemble dénombrable de noms de propriété ou aussi de noms d’attribut contenant un élément particulier ♦ dénommant les propriétés anonymes qui désignent les propriétés qui n’ont pas encore été nommées par l’utilisateur ; — V un ensemble de valeurs de propriété. 43Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements 2.1.1 Évènements et leurs attributs Commençons par définir la notion d’évènement. Contrairement à [CCK11], on souhaite considérer un modèle de temps continu. Les évènements sont donc datés par des réels et nous les identifions maintenant par un couple (nom, date) et non plus par leur indice d’occurrence dans le flux d’évènements étudié. Définition 6 (évènements). Un évènement est une paire (e, t) ∈ N × R composée d’un nom d’évènement et d’une date représentée par un réel. Le nom d’évènement τ ∈ N est réservé pour identifier les évènements temporels purs. Sur l’ensemble des évènements E ⊆ N × R, la projection sur la date est la fonction de datation, notée θ : E → R. Les informations spécifiques associées aux évènements sous la forme d’attributs sont regroupées dans un ensemble d’attributs comme suit : Définition 7 (attributs, ensembles d’attributs). Un attribut, aussi appelé une propriété, est une paire a = (p, v) ∈ P × V composée d’un nom de propriété et d’une valeur. Sur l’ensemble des attributs, la projection sur le nom de propriété est appelée la fonction de référence, notée ρ. Un ensemble d’attributs d’évènement est un ensemble X ⊆ P×V vérifiant la propriété fonctionnelle suivante, qui exprime que X est le graphe d’une fonction, c’est-à-dire que chaque propriété n’a qu’une seule valeur : ∀p∀v((p, v) ∈ X ⇒ ∀w((p, w) ∈ X ⇒ w = v)) (2.1) Par la suite on considère un ensemble Ae(P, V) d’ensembles d’attributs d’évènement sur P × V stable par union d’ensembles d’attributs d’évènement ayant des noms disjoints, c’est-à- dire vérifiant la contrainte suivante : ∀X1 ∈ Ae(P, V) ∀X2 ∈ Ae(P, V) {p ∈ P : ∃v ∈ V(p, v) ∈ X1} ∩ {p ∈ P : ∃v ∈ V(p, v) ∈ X2} = ∅ ⇒ X1 ∪ X2 ∈ Ae(P, V) Cette contrainte de stabilité est nécessaire pour la bonne définition des ensembles de reconnaissance donnée dans la Définition 16 (en effet, Ae(P, V) est le domaine de définition de la fonction D de la Définition 11). Ces évènements, dotés éventuellement de leurs attributs, sont regroupés sous la forme de flux d’évènements que l’on souhaite étudier et analyser avec notre système de reconnaissance de comportements. Définition 8 (flux d’évènements). Un flux d’évènements est défini comme une suite d’évènements ϕ = (ui)i∈N ∈ E N ordonnée par rapport au temps : ∀i∀j(i < j ⇒ θ(ui) < θ(uj )) et dotée d’une fonction d’extraction d’attributs α : {ϕ(i) : i ∈ N} → Ae(P, V) qui fournit l’ensemble d’attributs associé à chaque évènement permettant ainsi l’accès aux valeurs des attributs d’évènement simple dans le flux d’évènements. 44CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES 2.1.2 Opérations sur les attributs Lors du processus de reconnaissance qui analyse le flux d’évènements pour reconnaître les comportements décrits par des chroniques, des évènements sont rassemblés pour former des reconnaissances, comme ce sera formalisé dans la Section 2.3. Durant ce processus de reconnaissance, des attributs doivent être manipulés et peuvent être modifiés. Il peut être nécessaire de réaliser des opérations sur divers attributs de différents évènements. Si ces opérations sont imbriquées dans un comportement plus complexe à reconnaître, les résultats de ces opérations doivent être stockés sous forme d’attributs associés cette fois-ci aux reconnaissances et non plus aux évènements, afin de pouvoir être utilisés a posteriori. Comme évoqué précédemment, les reconnaissances de comportements sont donc elles aussi dotées d’attributs. Définition 9 (attribut de reconnaissance). Un ensemble d’attributs de reconnaissance de comportements est un ensemble X ⊆ P×Ae(P, V) vérifiant la propriété fonctionnelle (2.1). L’ensemble des ensembles d’attributs de reconnaissance est noté Ar(P, V). Comme défini au début de cette section, l’ensemble des noms de propriété contient un nom spécifique, ♦, utilisé comme nom anonyme. Lors de la progression du processus de reconnaissance, des attributs peuvent être calculés et enregistrés sous ce nom, en tant que nouveaux attributs temporaires, avant d’être éventuellement nommés pour être utilisés par la suite, comme il sera détaillé 2.3.2. Les fonctions suivantes permettent l’expression de telles opérations sur les attributs. Définition 10 (transformations d’attributs). Une transformation d’attributs est une fonction définie sur l’ensemble des ensembles d’attributs de reconnaissance Ar(P, V) dans l’ensemble des ensembles d’attributs d’évènement Ae(P, V) qui permet d’engendrer de nouvelles propriétés qui seront anonymes jusqu’à ce qu’elles soient oubliées ou nommées. Une fonction de transformation d’attributs f doit vérifier la contrainte suivante : ∀Xr ∈ Ar(P, V) {p ∈ P : ∃v ∈ V(p, v) ∈ f(Xr)} ∩ {p ∈ P : ∃Xe ∈ Ae(P, V) ∃pr ∈ P((pr, Xe) ∈ Xr ∧ ∃v ∈ V(p, v) ∈ Xe)} = ∅ qui exprime que les nouveaux attributs d’évènement créés par la fonction f ont des noms strictement différents de ceux déjà employés dans l’ensemble d’attributs de reconnaissance qui est en argument de f. Cette obligation participe à assurer l’unicité d’utilisation des noms de propriété dans une chronique. L’ensemble des fonctions de transformation d’attributs sur (P, V) est noté T(P, V). Les transformations d’attributs produisent ainsi de nouvelles données attachées aux reconnaissances. Pour pouvoir les employer par la suite dans des comparaisons ou des calculs, il est nécessaire de les identifier en les nommant. Les nouvelles propriétés qui sont soit issues d’une transformation d’attributs soit directement issues du flux d’évènements (i.e. des attributs d’évènement) ont d’abord un nom anonyme ♦ qui leur est donné par la fonction suivante : Définition 11 (fonction de dénomination anonyme). Une fonction de dénomination anonyme est définie sur l’ensemble des ensembles d’attributs d’évènement. Elle crée un ensemble d’attributs de reconnaissance, réduit à un singleton, en nommant ♦ l’ensemble d’attributs d’évènement 45Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements initial comme défini ci-dessous : D : Ae(P, V) → Ar(P, V) X 7→  {(♦, X)} si X 6= ∅ ∅ si X = ∅ Les propriétés anonymes ♦ peuvent ensuite être nommées par la fonction suivante : Définition 12 (fonction de renommage d’attributs). La fonction de renommage d’attributs est définie sur l’ensemble des ensembles d’attributs de reconnaissance et sur l’ensemble des noms de propriété. Elle nomme l’attribut anonyme ♦ de l’ensemble d’attributs comme défini ci-dessous 2 : R : Ar(P, V) × P → Ar(P, V) (X, p0 ) 7→ {(p 0 , v) : (♦, v) ∈ X} ∪ {(p, v) ∈ X : p 6= ♦} Ces fonctions permettent d’effectuer toutes les opérations nécessaires à la manipulation d’attributs et sont utilisées dans la Section 2.3.2 pour définir le processus de reconnaissance où l’on manipule des attributs qui doivent être nommés et parfois modifiés. 2.2 Définition d’une syntaxe étendue du langage des chroniques : ajout de contraintes sur des attributs d’évènement et de constructions temporelles Nous pouvons maintenant définir une syntaxe du langage des chroniques étendant largement celle de [CCK11]. De même que dans la Section 1.5, le langage des chroniques est construit par induction à partir d’évènements simples et de divers opérateurs permettant de spécifier des contraintes, temporelles ou non, sur les évènements étudiés. Commençons par détailler les diffé- rentes extensions et modifications envisagées. Expression de contraintes sur des attributs d’évènement Le langage des chroniques peut maintenant être étendu pour permettre de prendre en compte et de raisonner sur les attributs définis dans la Section 2.1.1 à l’aide des fonctions définies dans la Section 2.1.2. Toute chronique est dotée d’un prédicat P qui exprime les contraintes souhaitées sur les propriétés manipulées. Avant de pouvoir valider une reconnaissance, il faut que le prédicat P, évalué sur les valeurs des attributs de la reconnaissance, soit vérifié. Pour la manipulation des attributs, une chronique est également dotée d’une fonction de transformation d’attributs (Définition 10) introduisant de nouveaux attributs. 2. Il est immédiat de montrer que les images de la fonction R sont bien des éléments de Ar(P, V). 46CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES Une construction de nommage Nous ajoutons également une construction de nommage afin de pouvoir spécifier un nom pour nommer les nouvelles propriétés anonymes ♦, comme introduit précédemment dans 2.1. Une telle construction est nécessaire. En effet, un nom unique doit être donné aux nouveaux attributs, ils ne peuvent donc pas être nommés d’après le nom de l’évènement ou de la sous-chronique auquel ils correspondent car plusieurs évènements de même nom ou même plusieurs sous-chroniques peuvent prendre part à une description de comportement, mais il est nécessaire de pouvoir les distinguer. Donc, comme plusieurs évènements d’un même nom peuvent prendre part à la construction d’une chronique, il est nécessaire de pouvoir se référer précisément à l’un d’entre eux afin de savoir de quel évènement il faut récupérer dans le flux les valeurs des attributs pour évaluer le prédicat. Le nom spécifié par la construction de nommage remplit ce rôle mais pour cela il faut assurer qu’un nom donné n’est employé qu’une unique fois. Notion de contexte Pour assurer que les noms de propriété ne sont effectivement utilisés qu’une seule fois dans une chronique, il est nécessaire de faire apparaître des contraintes sur ces noms au niveau de la construction du langage. Pour ce faire, nous définissons la notion de contexte d’une chronique : il s’agit de l’ensemble des noms de propriété mis en jeu dans la chronique. Le contexte d’une chronique donnée, construit par induction en parallèle du langage, est intuitivement généralement l’union des contextes des sous-chroniques directes formant la chronique étudiée (c’est-à-dire l’union des noms de propriété des sous-chroniques). Cette gestion du contexte doit être particularisée pour quelques constructions, et nous détaillons les raisons de ces particularités après la définition suivante. Le contexte est également utilisé pour déterminer quels attributs sont disponibles pour l’évaluation du prédicat P et de la fonction de transformation f associés à la chronique. On devra ainsi distinguer deux types de contextes : un contexte d’évaluation pour le prédicat P et la fonction f, et un contexte résultant à transmettre dans l’induction pour la construction des contextes de chroniques plus complexes. Le contexte évolue donc en deux temps : une première fois avant la reconnaissance de la chronique et l’évaluation du prédicat, et une seconde fois après. Nous appelons contexte d’évaluation le contexte correspondant au domaine possible du prédicat et de la fonction, et contexte résultant, le contexte d’évaluation éventuellement modifié, après l’évaluation du pré- dicat, et qui sert à définir le prochain contexte d’évaluation dans l’induction. Des contraintes qui apparaissent dans la construction du langage pour assurer qu’un nom ne peut être utilisé qu’une seule fois portent sur le contexte d’évaluation. Les raisons précises derrière l’existence de ces deux notions de contexte seront développées après la Définition 13. Des opérateurs de contraintes sur les délais Afin de modéliser des contraintes temporelles, dix constructions sont ajoutées par rapport à [CCK11]. Ces constructions découlent de la logique d’intervalles d’Allen [All83] évoquée dans le Chapitre 1. Il s’agit de spécifier des contraintes sur des intervalles de reconnaissance de chroniques, c’est-à-dire, pour une reconnaissance donnée, sur l’intervalle de temps nécessaire et suffisant pour établir cette reconnaissance. Une première partie des opérateurs de contraintes temporelles permet d’exprimer toutes les relations temporelles entre deux intervalles de reconnaissance de deux chroniques (opérateurs equals, starts, finishes, meets, 47Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements overlaps, et during) à l’instar des treize relations d’Allen 3 . D’autres constructions décrivent trois différentes contraintes sur la durée de reconnaissance d’une chronique (opérateurs lasts δ, at least δ, at most δ) exprimant que le temps de reconnaissance de la chronique doit être respectivement exactement, au moins ou au plus une certaine durée δ. Elles correspondent à une transcription des opérateurs d’Allen equals, during et le symétrique de during. Seules ces trois constructions sont retenues car ce sont les seules ayant un sens dans notre contexte. En effet, si l’on considère par exemple la transposition de la relation starts, la contrainte qu’une certaine durée δ « débute » une reconnaissance n’apporte aucune spécification supplémentaire que celle qui impose que la reconnaissance dure au moins δ. La relation overlaps, quant à elle, lorsqu’elle est transcrite entre une reconnaissance et une durée, serait vérifiée dans tous les cas ; de même que la relation before. Il n’y a donc pas de sens à les introduire. La dernière construction spécifie l’écoulement d’un laps de temps directement après la reconnaissance d’une chronique (opérateur then δ) et correspond à une transposition de l’opérateur d’Allen meets. Les bornes de l’absence La notion d’absence est une notion cruciale dans le domaine de la reconnaissance de comportements, comme évoqué dans la Section 1.1. Dans la description d’une absence, il est nécessaire, pour pouvoir statuer d’une reconnaissance, de spécifier l’intervalle de temps pendant lequel le comportement non désiré ne doit pas se produire. Dans [CCK11], le langage des chroniques permet la description de l’absence d’un comportement pendant un autre comportement. C’est ce second comportement qui spécifie l’intervalle de temps à observer et pendant lequel le comportement interdit ne doit pas avoir lieu. Se pose alors la question de l’inclusion ou non des bornes dans l’intervalle considéré : le comportement interdit peut-il commencer en même temps ou se terminer au même instant que le comportement recherché ? Dans [CCK11], un seul cas de figure est formulable : le comportement interdit peut commencer en même temps mais doit terminer strictement avant la fin de la reconnaissance recherchée pour l’invalider. Nous introduisons dans la définition suivante (cf. [absence]) trois nouvelles notations qui permettent l’expression des trois possibilités. Notons que l’ancienne notation est utilisée parmi les trois, mais, afin de rendre la lecture du langage plus intuitive, elle ne désigne plus les même bornes que dans [CCK11] (cf. Définition 16). Le « cut » Nous ajoutons également plusieurs nouveaux opérateurs. Les deux premiers ajouts correspondent à des séquences dont nous souhaitons limiter la multiplicité des reconnaissances. Nous commençons par ajouter un opérateur que l’on appelle « cut », noté « ! ». Il exprime la reconnaissance consécutive de deux comportements A et B, comme dans le cadre d’un séquence, mais nous la restreignons à la première occurrence du comportement B après chaque comportement A. Nous limitons donc le nombre de reconnaissances par rapport à une séquence classique. 3. L’opérateur d’Allen before correspond à une version stricte de la séquence (la séquence est en fait une disjonction de meets et before) qui fait déjà partie du langage de [CCK11] et n’est donc pas ajouté. Notons également que l’opérateur de conjonction peut alors être exprimé comme une disjonction de tous les opérateurs d’Allen. 48CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES Le changement d’état ou « double cut » Nous ajoutons une seconde construction, correspondant à une séquence dont nous limitons la multiplicité des reconnaissances, avec une chronique exprimant le « changement d’état ». Il s’agit de décrire le passage d’un comportement caractérisant un état à un autre comportement caractérisant un autre état. Cette construction est représentée par l’opérateur noté « !! » et correspond, comme nous le verrons plus clairement par la suite, à un cut « dans les deux sens », donc nous l’appelons également « double cut ». Elle répond à une problématique fréquente lors du traitement de cas concrets. Considérons par exemple un drone à terre dont le décollage doit être détecté. Ses coordonnées de position permettent aisément d’identifier si le drone se trouve à terre (on_ground) ou bien s’il vole (above_ground). Le changement d’état de l’un à l’autre caractérise le décollage de l’appareil. Identifier ce changement d’état correspond à détecter « le dernier on_ground avant le premier above_ground », ce qui correspond à la sémantique de l’opérateur « !! ». Notons que ce changement d’état peut être exprimé à l’aide des autres opérateurs, mais lorsque l’on traite des applications réelles, il apparaît que l’opérateur de changement d’état est souvent nécessaire. Cette construction est donc ajoutée au langage afin de s’affranchir de définitions fastidieuses de chroniques. Une construction d’évènement de reconnaissance Lors de l’écriture des descriptions des comportements à reconnaître, il peut être intéressant de décomposer les comportements complexes pour les décrire en plusieurs étapes. Il y a alors deux possibilités pour imbriquer une chronique dans une autre. Soit la chronique est considérée comme un évènement ayant un instant de fin et un instant de début a priori disjoints, soit la chronique est réduite à son instant de reconnaissance. La construction par induction du langage des chroniques implique l’intégration naturelle du premier cas dans la syntaxe. En revanche, si l’on souhaite pouvoir exprimer le second cas, il faut rajouter une construction à apposer à une chronique pour se référer uniquement à son instant de reconnaissance. Pour ce faire, nous introduisons un opérateur, appelé « at » et noté « @ », qui correspond à la détection d’un évènement « abstrait d’une chronique », c’est-à-dire réduit à son instant de reconnaissance et donc nécessairement ponctuel. Donnons maintenant la syntaxe du langage muni des extensions décrites ci-dessus. Notons que la sémantique du langage est présentée Définition 16. Définition 13 (chroniques). Soit N, P, et V les ensembles introduits au début de la Section 2.1, p. 43. Soit S un ensemble de symboles de prédicats. L’ensemble des chroniques sur (N, P, V, S), noté X, est un ensemble de triplets (C, P, f), où : — C est une formule de chronique, comme définie dans la définition inductive de X qui suit ; — P ∈ S est un symbole de prédicat ; — f ∈ T(P, V) est une transformation d’attributs. X est défini inductivement avec deux notions de contextes, qui sont des fonctions de X dans P : — un contexte d’évaluation, noté Ce(·); — un contexte résultant, noté Cr(·). Pour tous C1 ∈ X et C2 ∈ X, on a : 49Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements [évènement simple] Si A ∈ N, alors (A, P, f) ∈ X, Ce(A, P, f) = {♦}, et Cr(A, P, f) = Ce(A, P, f); [séquence] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1 C2, P, f) ∈ X, Ce(C1 C2, P, f) = Cr(C1)∪Cr(C2), et Cr(C1 C2, P, f) = Ce(C1 C2, P, f); [conjonction] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1&C2, P, f) ∈ X, Ce(C1&C2, P, f) = Cr(C1) ∪ Cr(C2), Cr(C1&C2, P, f) = Ce(C1&C2, P, f); [disjonction] (C1 || C2, P, f) ∈ X, Ce(C1 || C2, P, f) = Cr(C1) ∩ Cr(C2), et Cr(C1 || C2, P, f) = Ce(C1 || C2, P, f); [absence] Si Ce(C1) ∩ Ce(C2) = {♦}, alors ((C1) − [C2], P, f) ∈ X, Ce((C1) − [C2], P, f) = Cr(C1)∪Cr(C2), et Cr((C1) − [C2], P, f) = Cr(C1); De même pour (C1)−]C2], (C1) − [C2[ 4 et (C1)−]C2[ ; [meets] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1 meets C2, P, f) ∈ X, Ce(C1 meets C2, P, f) = Cr(C1) ∪ Cr(C2), et Cr(C1 meets C2, P, f) = Ce(C1 meets C2, P, f); [overlaps] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1 overlaps C2, P, f) ∈ X, Ce(C1 overlaps C2, P, f) = Cr(C1)∪Cr(C2), et Cr(C1 overlaps C2, P, f) = Ce(C1 overlaps C2, P, f); [starts] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1 starts C2, P, f) ∈ X, Ce(C1 starts C2, P, f) = Cr(C1) ∪ Cr(C2), et Cr(C1 starts C2, P, f) = Ce(C1 starts C2, P, f); [during] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1 during C2, P, f) ∈ X, Ce(C1 during C2, P, f) = Cr(C1)∪Cr(C2), et Cr(C1 during C2, P, f = Ce(C1 during C2, P, f); [finishes] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1 finishes C2, P, f) ∈ X, Ce(C1 finishes C2, P, f) = Cr(C1)∪Cr(C2), et Cr(C1 finishes C2, P, f) = Ce(C1 finishes C2, P, f); [equals] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1 equals C2, P, f) ∈ X, Ce(C1 equals C2, P, f) = Cr(C1)∪Cr(C2), et Cr(C1 equals C2, P, f) = Ce(C1 equals C2, P, f); [lasts δ] Si δ ∈ R + ∗ , alors (C1 lasts δ, P, f) ∈ X, Ce(C1 lasts δ, P, f) = Cr(C1), et Cr(C1 lasts δ, P, f) = Ce(C1 lasts δ, P, f); [at least δ] Si δ ∈ R + ∗ , alors (C1 at least δ, P, f) ∈ X, Ce(C1 at least δ, P, f) = Cr(C1), et Cr(C1 at least δ, P, f) = Ce(C1 at least δ, P, f); [at most δ] Si δ ∈ R + ∗ , alors (C1 at most δ, P, f) ∈ X, Ce(C1 at most δ, P, f) = Cr(C1), et Cr(C1 at most δ, P, f) = Ce(C1 at most δ, P, f); [then δ] Si δ ∈ R + ∗ , alors (C1 then δ, P, f) ∈ X, Ce(C1 then δ, P, f) = Cr(C1), et Cr(C1 then δ, P, f) = Ce(C1 then δ, P, f); [nommage de propriété] Si x ∈ P \ {♦}, alors (C1→x, P, f) ∈ X, Ce(C1→x, P, f) = Cr(C1), Cr(C1→x, P, f) = {x, ♦} ; [cut] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1!C2, P, f) ∈ X, Ce(C1!C2, P, f) = Cr(C1) ∪ Cr(C2), et Cr(C1!C2, P, f) = Ce(C1!C2, P, f); 4. C’est cette construction qui correspond à celle de l’absence dans [CCK11] présentée dans la Section 1.5.3 et notée (C1) − [C2]. 50CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES [changement d’état] Si Ce(C1) ∩ Ce(C2) = {♦}, alors (C1!!C2, P, f) ∈ X, Ce(C1!!C2, P, f) = Cr(C1) ∪ Cr(C2), et Cr(C1!!C2, P, f) = Ce(C1!!C2, P, f); [évènement de reconnaissance] (@C1, P, f) ∈ X, Ce(@C1, P, f) = Cr(C1), et Cr(@C1, P, f) = Cr(C1). Remarque 4. La grammaire du langage des chroniques, sans considération de contexte, s’exprime comme suit sous la forme de Backus-Naur, avec A ∈ N, δ ∈ R + ∗ et x ∈ P \ {♦} : C ::= A | C C | C&C | C || C | (C) − [C] | C meets C | C overlaps C | C starts C | C during C | C finishes C | C equals C | C lasts δ | C at least δ | C at most δ | C then δ | C→x | C!C | C!!C | @C Éclaircissements sur la double notion de contexte La contrainte récurrente Ce(C1) ∩ Ce(C2) = {♦} assure que tout nom de propriété ne peut être utilisé qu’une seule fois dans une chronique, ce qui est nécessaire pour pouvoir identifier correctement les propriétés. En effet, comme évoqué précédemment, un nom d’attribut se réfère à un évènement ou une chronique spécifique, et un même nom de propriété ne peut donc pas être donné à plusieurs structures au sein d’une même chronique. Quant à la construction des contextes, la définition générique intuitive évoquée précédemment est celle de la séquence et elle est partagée par la plupart des opérateurs. Le contexte d’évaluation est simplement l’union des contextes résultant des deux sous-chroniques, regroupant ainsi tous les noms de propriété mis en jeu dans l’ensemble de la chronique. Le contexte résultant est identique au contexte d’évaluation. Cependant, ceci ne peut pas être appliqué à l’ensemble des opérateurs, et c’est là qu’apparaît la nécessité de définir deux contextes. Présentons les trois exceptions. Le cas de la disjonction Tout d’abord, notons que la disjonction est la seule chronique construite à partir de deux sous-chroniques mais à laquelle n’est pas imposée la contrainte générique d’avoir l’intersection des contextes d’évaluation réduite au singleton {♦}. Au contraire, nous allons nous intéresser aux noms de propriété qui sont employés dans les deux branches de la disjonction. Cette particularité provient du fait que, dans une disjonction, seule l’une des deux sous-chroniques peut être reconnue. Pour qu’un nom d’attribut puisse avoir un sens dans une disjonction, c’est- à-dire pour qu’il soit toujours possible de lui attribuer une valeur en tout cas de figure, un nom d’attribut dans une disjonction doit se référer à un évènement dans chacune des deux branches. En effet, sinon, on ne peut pas assurer que, quelle que soit la branche reconnue, tout nom d’attribut se réfère effectivement à un évènement du flux ce qui est nécessaire pour évaluer le prédicat et la fonction de transformation. Considérons par exemple la chronique (A→x B→y) || (D→z A→x) qui est une disjonction reconnaissant soit la séquence de deux évènements A suivi de B soit la séquence de D suivi de A. Toute reconnaissance de cette chronique mettra en jeu un évènement de nom de propriété x, mais selon la branche de la disjonction reconnue, elle mettra en jeu un évènement de nom de propriété soit y soit z. Au niveau de la disjonction, on peut donc se référer à x pour lequel des valeurs seront toujours disponibles, mais on ne peut pas se référer à y ou z 51Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements comme cela dépend de la branche reconnue. Pour cette raison, le contexte d’évaluation associé à une disjonction est l’intersection des contextes de ses sous-chroniques. Le cas de l’absence Le cas de l’absence est similaire à celui de la disjonction. Nous souhaitons permettre l’expression de la contrainte suivante, sur les attributs des deux sous-chroniques d’une absence : « (C1)−[C2] vérifiant le prédicat P » correspond au comportement décrit par « C1 reconnue sans qu’il n’y ait aucune occurrence de C2 vérifiant le prédicat P durant la reconnaissance de C1, où P peut porter sur les attributs à la fois de C1 et de C2 ». Par exemple, le comportement suivant peut alors être décrit : « Un avion d’ID n a modifié sa fréquence radio à f 6= 118.075 (qui est en fait la fréquence recherchée) à l’instant t au plus 5 min après le décollage, et, après t mais avant cette échéance de 5 min, la fréquence radio n’a pas été corrigée par l’avion n ». Pour reconnaître ce comportement, les attributs des deux sous-chroniques C1 et C2 doivent être comparés pour identifier le même avion n et pour avoir accès à l’instant t. Notons que cet exemple sera développé dans l’application présentée dans la Section 5.3. Pour permettre au prédicat d’avoir accès aux attributs des deux sous-chroniques, le contexte d’évaluation de la chronique doit être l’union des deux contextes résultants des deux sous-chroniques, comme c’est le cas généralement. Cependant, la chronique (C1) − [C2] est reconnue s’il n’y a aucune reconnaissance de C2 pendant la reconnaissance de C1, donc les deux contextes ne doivent pas être passés dans l’induction à une chronique de plus haut niveau. En effet, comme dans le cas de la disjonction, il n’y a pas nécessairement de valeurs pour les attributs de C2 car il n’y a pas nécessairement de reconnaissance de C2. C’est pour cela que l’on introduit la notion de contexte résultant, qui permet de conserver dans le contexte d’évaluation l’union des deux contextes des sous-chroniques, mais de ne passer dans l’induction uniquement le contexte de C1 en réduisant le contexte résultant à celui-ci. Le cas du nommage de propriété La dernière exception à la définition générique des contextes est le cas du nommage de propriété. Le rôle de cette construction de nommer les attributs de la chronique. Afin que ce nom puisse être utilisé par la suite, ce nom doit donc être ajouté au contexte résultant de la chronique. Par ailleurs, il a été décidé que, lorsque les propriétés d’une chronique sont ainsi nommées, on ne conserve que les propriétés créées par la fonction de transformation f (qui sont stockées sous le nom anonyme ♦ avant d’être éventuellement nommées) et les anciennes propriétés sont « oubliées ». Ceci se traduit par le fait que le contexte résultant est donc réduit à l’ensemble {♦, x} où x est le nom de propriété choisi. Notons que si l’on souhaite conserver l’ensemble des propriétés présentes à l’intérieur de la chronique nommée, cela est possible à travers de la fonction f. Le choix d’oublier par défaut ces propriétés a été fait car cela permet d’abstraire la sous-chronique en une sorte d’évènement de plus haut niveau muni d’attributs plus complexes tout en se défaisant d’informations superflues. 52CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES 2.3 Définition de la sémantique du langage à travers la notion de reconnaissance de chronique Dans la section précédente, nous avons établi la syntaxe de notre langage des chroniques, en introduisant de nombreuses nouvelles constructions. Dans cette section, nous allons maintenant définir la sémantique de ce langage en définissant la notion de reconnaissance d’une chronique. Dans un premier temps (Section 2.3.1) nous étudierons le modèle de représentation des reconnaissances dans le formalisme. Dans [CCK11], une reconnaissance est représentée par un ensemble. Nous montrerons qu’une représentation arborescente est plus appropriée. Nous définirons dans un second temps (Section 2.3.2) la sémantique du langage des chroniques fondée sur ce formalisme de reconnaissance arborescente. 2.3.1 Passage à une représentation arborescente des reconnaissances Il s’agit d’étudier ici le formalisme employé pour représenter une reconnaissance de chronique. Rappelons que dans [CCK11], une reconnaissance d’une chronique est un ensemble contenant les indices d’occurrence des évènements ayant donné lieu à la reconnaissance (cf. Définition 1.5.3). Nous souhaitons mettre en avant un problème de multiplicité des reconnaissances lié à la structure ensembliste utilisée. Commençons par étudier l’exemple suivant qui illustre ce problème. Considérons la chronique C = (A B)&A sur le flux ϕ = ((a, 1),(a, 2),(b, 3)). Avec le formalisme de [CCK11] dans lequel une reconnaissance est un ensemble d’évènements, nous obtenons trois reconnaissances de la chronique C sur le flux ϕ : RC (ϕ) = {{1, 2, 3}, {1, 3}, {2, 3}} Remarquons que, dans la reconnaissance {1, 2, 3}, on ne peut pas identifier quel évènement a participe à la reconnaissance de la séquence A B et quel évènement a correspond à l’évènement simple A. Ceci est dû à l’impossibilité de distinguer les ensembles {1, 3, 2} et {2, 3, 1}, et donc à distinguer les deux a. Or, comme introduit dans la Section 1.1, l’historisation des évènements, à savoir l’identification exacte de quel évènement a participé à quel morceau de la reconnaissance, est une problématique omniprésente. D’autre part, l’introduction d’attributs rend primordial l’appariement exact des évènements à la chronique pour que les valeurs correctes des propriétés soient considérées. Nous voudrions donc pouvoir différencier les ensembles {1, 3, 2} et {2, 3, 1}, ce qui donnerait donc quatre reconnaissances pour la chronique C sur le flux ϕ. Ce problème a donc également une incidence sur la combinatoire du système. Pour résoudre cette question, nous proposons de manipuler des reconnaissances sous forme d’arbres binaires plutôt que sous forme de simples ensembles. Davantage d’informations peuvent ainsi être conservées : l’arbre d’une reconnaissance est calqué sur la structure arborescente de la chronique associée et l’on a donc la possibilité de connaître la correspondance exacte entre les noms d’évènements simples de la chronique et les évènements du flux prenant part à la reconnaissance. Pour l’exemple précédent, cela permet de différencier les appariements des a du flux et ainsi 53Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements obtenir quatre reconnaissances. Avec la représentation d’arbre binaire définie par la suite (Définition 14), l’ensemble de reconnaissances est alors : RC (ϕ) = {hh1, 3i, 2i,hh2, 3i, 1i,hh1, 3i, 1i,hh2, 3i, 2i} Par ailleurs, pour favoriser la lecture, nous adoptons un autre système de représentation des évènements, en indiquant les évènements et leur date d’occurrence en lieu et place de leur indice d’occurrence dans le flux, comme annoncé au début de la Section 2.1.1. Nous serons également amenés à ajouter un paramètre d à l’ensemble de reconnaissance, indiquant l’instant jusqu’auquel les évènements du flux ont été pris en compte. Ce paramètre est nécessaire pour l’écriture des ensemble de reconnaissances de certains opérateurs exprimant des contraintes temporelles. Avec ces nouvelles notations, l’ensemble de reconnaissances de l’exemple précédent sera noté : RC (ϕ, 3) = {hh(a, 1),(b, 3)i,(a, 2)i,hh(a, 2),(b, 3)i,(a, 1)i, hh(a, 1),(b, 3)i,(a, 1)i,hh(a, 2),(b, 3)i,(a, 2)i} Définissons maintenant formellement la représentation arborescente utilisée. Une reconnaissance r est l’arbre binaire des évènements (e, t) ayant donné lieu à la reconnaissance. La structure de l’arbre de reconnaissance reflète celle de la chronique associée, les feuilles de celui-ci correspondant aux évènements donnant lieu à la reconnaissance. Les informations qui sont pertinentes sont la structure de l’arbre ainsi que les étiquettes des feuilles 5 . Pour identifier sans ambiguïté les appariements d’évènements avec les sous-chroniques de la chronique étudiée, il n’est pas nécessaire de nommer d’autres nœuds que les feuilles. Nous utilisons donc le formalisme suivant. Définition 14 (arbres de reconnaissance). L’ensemble A(E) des arbres de reconnaissance sur l’ensemble d’évènements E se définit par induction comme suit, où X est un ensemble d’attributs : — si (e, t) ∈ E, alors ((e, t), X) ∈ A(E); — si r1 ∈ A(E) et r2 ∈ A(E), alors (hr1, r2i, X) ∈ A(E); — si r ∈ A(E), alors (hri, X) ∈ A(E), (hr, ⊥i, X) ∈ A(E) et (h⊥, ri, X) ∈ A(E). Nous définissons aussi l’ensemble F(r) des feuilles d’un arbre de reconnaissance r par induction : — si r = ((e, t), X) avec (e, t) ∈ E, alors F(r) = {(e, t)} ; — si r = (hr1, r2i, X) avec r1 ∈ A(E) et r2 ∈ A(E), alors F(r) = F(r1) ∪ F(r2); — si r ∈ {(hr1, ⊥i, X),(h⊥, r1i, X),(hr1i, X)} avec r1 ∈ A(E), alors F(r) = F(r1). Notons que, dans la définition précédente, nous avons introduit une notation pour distinguer deux types de paires : les feuilles qui sont des paires composées d’un nom d’évènement et d’une date, notées entre parenthèses (), et les ramifications des arbres, notées entre chevrons hi. Avant de définir la sémantique de notre langage à travers la notion de reconnaissance, nous définissons au préalable deux fonctions Tmin et Tmax retournant respectivement, en fonction d’une reconnaissance r, le premier et le dernier instants auxquels a lieu un évènement participant à r : 5. L’ensemble des feuilles d’un arbre de reconnaissance correspond à la reconnaissance dans le formalisme de [CCK11]. 54CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES Définition 15 (temps min et max). Tmin : A(E) → R, r 7→ min{t : (e, t) ∈ F(r)} Tmax : A(E) → R, r 7→ max{t : (e, t) ∈ F(r)} Ainsi, pour toute reconnaissance r, l’intervalle [Tmin(r), Tmax(r)] correspond à l’intervalle de temps nécessaire et suffisant pour établir la reconnaissance r. Ces deux fonctions permettront de poser des contraintes temporelles entre les intervalles d’occurrence de chroniques. 2.3.2 Formalisation de la notion de reconnaissance de chronique Nous pouvons maintenant poser la sémantique de notre langage des chroniques en définissant la notion de reconnaissance d’une chronique tout en intégrant la nouvelle représentation arborescente des reconnaissances. La définition de la sémantique est délicate pour deux raisons principales : — d’une part, le processus de reconnaissance doit permettre d’évaluer des prédicats sur des attributs d’évènement provenant de différentes parties de la chronique ; — d’autre part, les chroniques doivent être reconnues en ligne. Avec ces deux contraintes à l’esprit, nous définissons pour chaque chronique un ensemble de reconnaissances qui correspond à toutes les reconnaissances de la chronique représentées sous forme d’arbres et munies de leurs attributs de reconnaissance associés. Comme l’on souhaite que le processus de reconnaissance puisse être effectué au fur et à mesure tout en étant exhaustif, la construction des ensembles de reconnaissances est progressive, ce qui s’exprime par une définition inductive dépendant de l’instant d jusqu’auquel les évènements du flux sont considérés. La constitution de ces ensembles ne nécessite donc pas de connaître par avance l’intégralité du flux d’évènements. Nous définissons donc, par induction pour chaque chronique, l’ensemble de ses reconnaissances sur un flux d’évènements et jusqu’à une date donnés. Les évènements de cet ensemble sont des couples (r, X) où r est un arbre de reconnaissance et X est l’ensemble d’attributs de reconnaissance associé. Chaque définition peut se décomposer en trois parties : — l’expression des contraintes temporelles liées à l’opérateur; — la vérification du prédicat; — la définition de l’ensemble d’attributs de reconnaissance. Définition 16 (ensembles de reconnaissances). Soit C ∈ X une chronique. Considérons, pour tout prédicat P, un (P × V)-modèle M dans lequel il existe une interprétation Pˆ de P. L’ensemble des reconnaissances de C sur le flux d’évènements ϕ jusqu’à la date d est noté RC (ϕ, d) et est un sous-ensemble de A(E). L’ensemble d’attributs associé à une reconnaissance r est noté Xr. Nous utilisons les notations suivantes : X♦ r = {(♦, v) ∈ Xr : v ∈ Ae(P, V)}, qui est un singleton, et X∗ r = Xr \ X♦ r . Les ensembles de reconnaissances et les ensembles d’attributs associés aux reconnaissances sont définis par induction comme suit : — Un évènement simple A vérifiant le prédicat P est reconnu si un évènement de nom A a lieu dans le flux avant l’instant d et si ses attributs vérifient le prédicat P. Les attributs de reconnaissance sont réduits à une unique propriété anonyme contenant les éventuels attributs créés par la fonction f et les attributs de l’évènement du flux. 55Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Si A∈N, alors : R(A,P,f)(ϕ, d) = {((e, t), X(e,t)) : e = A ∧ ∃i ϕ(i) = (e, t) ∧ t ≤ d ∧ Pˆ[D◦α((e, t))] ∧ X(e,t)={ (♦, X) : ∃Xe ∈ Ae(P, V) ( X = Xe∪α((e, t)) ∧ f◦D◦α((e, t)) = {(♦, Xe)} ) } } En d’autres termes, les reconnaissances d’un évènement simple suivent les règles suivantes : — le nom de l’évènement est correct ; — la date de l’évènement est inférieure à l’horizon (t ≤ d) ; — le prédicat, s’il existe, est vérifié sur les attributs de l’évènement (Pˆ[D◦α((e, t))]). Et en supplément, l’ensemble d’attributs associé à la reconnaissance est constitué de la manière suivante. Il contient : — les attributs de l’évènement dans le flux (α((e, t))) ; — les attributs créés par la fonction f (f◦D◦α((e, t))). — Une disjonction C1 || C2 vérifiant un prédicat P est reconnue lorsque l’une des deux souschroniques est reconnue et vérifie P. La structure de l’arbre indique quelle branche de la chronique a été reconnue. Les attributs de reconnaissance sont réduits aux attributs dont les noms sont utilisés à la fois dans C1 et C2, comme détaillé dans la Section 2.2 (p.51), avec les attributs anonymes créés par la fonction f. On rappelle que la fonction ρ permet d’accéder au nom d’une propriété. R(C1||C2,P,f)(ϕ, d) = {(hr, ⊥i, Xhr,⊥i) : r ∈ RC1 (ϕ, d) ∧ Pˆ[X∗ r ] ∧ Xhr,⊥i = {x ∈ X∗ r : ρ(x) ∈ Ce(C1||C2)} ∪ D◦f[X∗ r ]} ∪ {(h⊥, ri, Xh⊥,ri) : r ∈ RC2 (ϕ, d) ∧ Pˆ[X∗ r ] ∧Xh⊥,ri={x ∈ X∗ r : ρ(x) ∈ Ce(C1 || C2)} ∪ D◦f[X∗ r ]} — Une séquence C1C2 vérifiant P est reconnue lorsque C2 est reconnue après avoir reconnu C1 et que les deux reconnaissances vérifient P. Les attributs de reconnaissance sont ceux des reconnaissances de C1 et de C2 avec les attributs anonymes créés par la fonction f. C1 C2 R(C1 C2,P,f)(ϕ, d) = {(hr1, r2i, Xhr1,r2i) : r1 ∈ RC1 (ϕ, d) ∧ r2 ∈ RC2 (ϕ, d) ∧Tmax(r1) < Tmin(r2) ∧ Pˆ[X∗ r1 ∪ X∗ r2 ] ∧ Xhr1,r2i = X∗ r1 ∪ X∗ r2 ∪ D◦f[X∗ r1 ∪ X∗ r2 ]} — Une conjonction C1&C2 vérifiant P est reconnue lorsque à la fois C1 et C2 sont reconnues et vérifient P. Les attributs de reconnaissance sont construits comme pour la séquence. R(C1&C2,P,f)(ϕ, d)={(hr1, r2i, Xhr1,r2i) : r1∈RC1 (ϕ, d) ∧ r2 ∈ RC2 (ϕ, d) ∧ Pˆ[X∗ r1 ∪ X∗ r2 ] ∧ Xhr1,r2i = X∗ r1 ∪ X∗ r2 ∪ D◦f[X∗ r1 ∪ X∗ r2 ]} — Une absence (C1) − [C2] vérifiant un prédicat P est reconnue lorsque C1 est reconnue sans aucune occurrence de C2 vérifiant P durant la reconnaissance de C1. Attention, dans le cas d’une absence, la signification du prédicat est donc particulière. Les attributs de reconnaissance sont alors réduits à ceux de la reconnaissance de C1, comme détaillé dans 2.2, complétés des éventuels attributs anonymes créés par la fonction f. 56CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES C1 C2 R((C1)−[C2],P,f)(ϕ, d) = {(hr1i, Xhr1i) : r1∈RC1 (ϕ, d) ∧∀r2∈RC2 (ϕ, d) ( Tmin(r1)>Tmin(r2) ∨Tmax(r1)Tmin(r2) ∨ Tmax(r1)≤Tmax(r2); — pour (C1)−]C2], elle devient Tmin(r1)≥Tmin(r2) ∨ Tmax(r1)Tmin(r2)∧Tmax(r1)Tmin(r2)∧Tmax(r1)=Tmax(r2). — Une chronique C1 equals C2 est reconnue lorsque à la fois C1 et C2 sont reconnues sur exactement le même intervalle de temps, et P est vérifié. C1 C2 R(C1 equals C2,P,f)(ϕ, d) est défini comme la séquence mais avec la contrainte temporelle Tmin(r1)=Tmin(r2)∧Tmax(r1)=Tmax(r2). 6. C’est cette construction qui correspond à celle de l’absence dans [CCK11] présentée dans la Section 1.5.3 et notée (C1) − [C2]. 57Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements — Une chronique C1 lasts δ est reconnue lorsque C1 est reconnue, P est vérifié, et la taille de l’intervalle de reconnaissance est exactement δ. C1 δ R(C1 lasts δ,P,f)(ϕ, d) = {(hri, Xhri) : r ∈ RC1 (ϕ, d) ∧Tmax(r) − Tmin(r) = δ ∧ Pˆ[X∗ r ] ∧ Xhri = X∗ r ∪ D◦f[X∗ r ]} — Une chronique C1 at most δ est reconnue lorsque C1 est reconnue, P est vérifié, et la taille de l’intervalle de reconnaissance est au plus δ. C1 δ R(C1 at most δ,P,f)(ϕ, d) est défini comme la chronique « lasts » mais avec la contrainte temporelle Tmax(r) − Tmin(r) < δ. — Une chronique C1 at least δ est reconnue lorsque C1 est reconnue, P est vérifié, et la taille de l’intervalle de reconnaissance est au moins δ. C1 δ R(C1 at least δ,P,f)(ϕ, d) est défini comme la chronique « lasts » mais avec la contrainte temporelle Tmax(r) − Tmin(r) > δ. — Une chronique C1 then δ est reconnue lorsque exactement δ unités de temps s’écoulent après une reconnaissance de C1. L’arbre de reconnaissance conserve l’évènement d’instant temporel pur (τ, t) correspondant à l’instant de la reconnaissance. Ceci permet, entre autre, d’avoir une définition correcte de Tmax. C1 δ R(C1 then δ,P,f)(ϕ, d)={(hr,(τ, t)i, Xhr,(τ,t)i) : t ≤ d ∧ r ∈ RC1 (ϕ, t) ∧t = Tmax(r)+δ ∧ Pˆ[X∗ r ] ∧ Xhr,(τ,t)i = X∗ r ∪ D◦f[X∗ r ]} — Une chronique de nommage de propriété C1→x est reconnue lorsque C1 est reconnue. Les attributs de reconnaissance sont les attributs anonymes de la reconnaissance de C1 mais renommés x, avec les nouveaux attributs anonymes créés par la fonction f. R(C1→x,P,f)(ϕ, d) = {(hri, Xhri) : r∈RC1 (ϕ, d) ∧ Pˆ[X∗ r ] ∧ Xhri = R(X♦ r , x) ∪ D◦f[X∗ r ]} — Une chronique de cut C1!C2 est reconnue lorsque C1 et C2 sont reconnues successivement et lorsque la reconnaissance de C2 est la première après celle de C1 En d’autres termes, il n’y a pas d’autre reconnaissance de C2 entre les deux reconnaissances sélectionnées. R(C1!C2,P,f)(ϕ, d)={(hr1, r2i, Xhr1,r2i) : r1∈RC1 (ϕ, d) ∧ r2∈RC2 (ϕ, d) ∧ Tmax(r1) Tmin(r2) ∨ Tmax(r1) ≤ Tmax(r2) )}. Soit r1 ∈ RC (ϕ|I , d). Alors r1 ∈ RC1 (ϕ|I , d) et ∀r2 ∈ RC2 (ϕ|I , d) ( Tmin(r1) > Tmin(r2) ∨ Tmax(r1) ≤ Tmax(r2) ). Par hypothèse d’induction, RC1 (ϕ|I , d) ⊆ RC1 (ϕ|J , d), et donc r1 ∈ RC1 (ϕ|J , d). Montrons de plus par l’absurde que ∀r2 ∈ RC2 (ϕ|J , d) ( Tmin(r1) > Tmin(r2) ∨ Tmax(r1) ≤ Tmax(r2) ). Soit r2 ∈ RC2 (ϕ|J , d) tel que Tmin(r1) ≤ Tmin(r2) ∧ Tmax(r1) > Tmax(r2). En particulier, Tmax(r2) < Tmax(r1) ≤ max I et r2 ∈ RC2 (ϕ|J , d), donc, comme I est un segment initial de J, r2 ∈ RC2 (ϕ|I , d), donc ∃r2 ∈ RC2 (ϕ|I , d) ( Tmin(r1) ≤ Tmin(r2) ∧ Tmax(r1) > Tmax(r2) ). Absurde. Donc r1 ∈ RC (ϕ|J , d), et on a donc bien RC (ϕ|I , d) ⊆ RC (ϕ|J , d). — La démonstration pour les autres opérateurs est analogue à celle de la séquence. Remarque 10. En particulier, pour tout k ∈ N et tout d ∈ R, RC ((ui)i∈J1,kJ , d) ⊆ RC ((ui)i∈J1,k+1J , d) Remarque 11. En revanche, la propriété « pour tout I inclus dans le domaine de ϕ, RC (ϕ|I , d) ⊆ RC (ϕ, d) » n’est pas vérifiée pour toute chronique dans laquelle est utilisée l’opérateur d’absence. Le problème se pose si I n’est pas un segment initial du domaine de ϕ. Par exemple, prenons C = (A D)−[B[ et posons ϕ = ((a, 1),(b, 2),(d, 3)) avec I = {1, 3}. Alors, RC (ϕ|I , d) = {h(a, 1),(d, 3)i} mais RC (ϕ, d) = { }, donc RC (ϕ|I , d) * RC (ϕ, d). Il en est de même pour la propriété plus générale « pour tout I ⊆ J, RC (ϕ|I , d) ⊆ RC (ϕ|J , d) » s’il n’y a pas de condition supplémentaire sur I et J. 2.4.3 Associativité, commutativité, distributivité Les démonstrations des propriétés suivantes se trouvent dans l’Annexe A. Propriété 3 (associativité). La disjonction, la conjonction, la séquence, meets et equals sont associatifs. Remarque 12. 1. « overlaps » n’est pas associatif. En effet, considérons le flux ϕ = ((a, 1),(f, 2),(d, 3),(b, 4),(e, 5),(g, 6)), et les chroniques C1 = A B, C2 = D E et C3 = F G. On a alors FC1 overlaps C2 (ϕ, 6) = {{1, 3, 4, 5}} et FC2 overlaps C3 (ϕ, 6) = { }, Donc F(C1 overlaps C2) overlaps C3 (ϕ, 6) = {{1, 2, 3, 4, 5, 6}}, mais FC1 overlaps (C2 overlaps C3)(ϕ, 6) = { }. 2. « starts » n’est pas associatif. En effet, considérons le flux ϕ = ((a, 1),(b, 2),(d, 3),(e, 4)), et les chroniques C1 = A D, C2 = A B et C3 = A E. 62CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES On a alors FC1 starts C2 (ϕ, 4) = { } donc F(C1 starts C2) starts C3 (ϕ, 4) = { }, Mais FC2 starts C3 (ϕ, 4) = {{1, 2, 4}}, donc FC1 starts (C2 starts C3)(ϕ, 4) = {{1, 2, 3, 4}}. 3. « during » n’est pas associatif. En effet, considérons le flux ϕ = ((a, 1),(b, 2),(d, 3),(e, 4),(f, 5),(g, 6)), et les chroniques C1 = B E, C2 = D F et C3 = A G. On a alors FC1 during C2 (ϕ, 6) = { } donc FC1 during (C2 during C3)(ϕ, 6) = { }, Mais FC2 during C3 (ϕ, 6) = {{1, 3, 5, 6}}, donc FC1 during (C2 during C3)(ϕ, 6) = {{1, 2, 3, 4, 5, 6}}. 4. « finishes » n’est pas associatif. En effet, considérons le flux ϕ = ((a, 1),(b, 2),(d, 3),(e, 4)), et les chroniques C1 = B E, C2 = D E et C3 = A E. On a alors FC1 finishes C2 (ϕ, 4) = { } donc F(C1 finishes C2) finishes C3 (ϕ, 4) = { }, Mais FC2 finishes C3 (ϕ, 4) = {{1, 3, 4}}, donc FC1 finishes (C2 finishes C3)(ϕ, 4) = {{1, 2, 3, 4}}. 5. Le changement d’état n’est pas associatif. En effet, considérons le flux ϕ = ((a, 1),(b, 2),(b, 3),(d, 4)), et les chroniques C1 = A!!(B!!D) et C2 = (A!!B)!!D. On a alors FC1 (ϕ, 4) = {{1, 3, 4}} mais FC2 (ϕ, 4) = {{1, 2, 4}}. 6. Le cut n’est pas associatif, puisque le changement d’état est un cut particulier. Propriété 4 (commutativité). La disjonction, la conjonction et equals sont commutatifs. Remarque 13. 1. La séquence n’est pas commutative. En effet, considérons le flux ϕ = ((a, 1),(b, 2)), et les chroniques A B et B A. On a alors FA B(ϕ, 2) = {{1, 2}} mais FB A(ϕ, 2) = { }. 2. meets, overlaps, starts, during, finishes, le cut et le changement d’état ne sont pas commutatifs. En effet, comme pour la séquence, les propriétés temporelles qui caractérisent ces opérateurs sont exprimées par des inégalités et ne sont donc pas commutatives. Propriété 5 (distributivité). Tous les opérateurs sont distributifs sur la disjonction. Remarque 14. La distributivité de tout opérateur sur un opérateur autre que la disjonction n’est pas vérifiée. En effet, considérons deux opérateurs ~ et }. Si ~ est distributif sur }, alors, en particulier, l’égalité suivante est vérifiée, où A, B et D sont des évènements simples : A ~ (B } D) ≡ (A ~ B)}(A~D). Une reconnaissance de la chronique du membre de gauche ne peut correspondre qu’à un unique évènement a. En revanche, si } n’est pas une disjonction, deux évènements a distincts peuvent participer à une même reconnaissance de la chronique du membre de droite. L’équivalence n’est donc pas vérifiée si } n’est pas une disjonction, tout opérateur n’est ainsi pas distributif sur un opérateur autre que la disjonction. Considérons par exemple le cas de la distributivité de la séquence sur la conjonction, avec le flux ϕ = ((a, 1),(b, 2),(a, 3),(d, 4)), et les chroniques A (B&D) et (A B)&(A D). On a alors {1, 2, 3, 4} ∈ F(A B)&(A D)(ϕ, 4) mais {1, 2, 3, 4} ∈/ FA (B&D)(ϕ, 4). 63Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Pour les opérateurs liés aux durées, et qui n’ont donc pas de sens sur des évènements simples, le même raisonnement s’applique sur les évènements simples qui constituent chaque sous-chronique. Par exemple, pour le cas de la distributivité de la séquence sur starts, considérons le flux ϕ = ((a, 1),(b, 2),(d, 3),(e, 4),(b, 5),(f, 6),(g, 7)), et les chroniques (A B) ((D E) starts (F G)) et (A B D E) starts (A B F G). Alors : {1, 2, 3, 4, 5, 6, 7} ∈ F(A B D E) starts (A B F G)(ϕ, 7) mais : {1, 2, 3, 4, 5, 6, 7} ∈/ F(A B) ((D E) starts (F G))(ϕ, 7) 2.5 Gestion du temps continu à l’aide d’une fonction Lookahead Cette section s’attache à la gestion du temps dans la mise en œuvre du processus de reconnaissance. Des opérations de contraintes temporelles ont été ajoutées au langage et la syntaxe comme la sémantique ont été adaptées pour considérer un modèle de temps continu. Dans une optique d’implémentation, la considération d’un temps continu soulève des problèmes et rend nécessaire la définition d’une fonction « Look-ahead » indiquant un prochain instant TC (ϕ, d) jusqu’auquel le système n’a pas besoin d’être réexaminé car on a l’assurance qu’aucune reconnaissance ne va se produire jusqu’à cet instant. En effet, les systèmes considérés sont asynchrones, et cette fonction fournit le prochain instant où les chroniques peuvent évoluer. En indiquant le moment où observer le système, cette fonction permet de ne pas avoir à le surveiller constamment pour une reconnaissance éventuelle, ce qui serait impossible du fait du modèle de temps continu (et ce qui serait de toute façon trop exigeant même si le modèle de temps pouvait être discrétisé). La fonction « Look-ahead » est inférée de la sémantique du langage présentée dans la Définition 16 et est définie comme suit : Définition 19 (fonction « Look-ahead »). Soit d ∈ R, C ∈ X et ϕ un flux d’évènements. Nous définissons TC (ϕ, d) par induction sur la chronique C : — si A ∈ N et C = (A, P, f), alors TC (ϕ, d) = min{t : ∃i ∈ N ∃e ∈ N ϕ(i) = (e, t) ∧ t > d} ; — pour tout ~ ∈ {||, &, “ ”,( ) − [ ],( ) − [ [,( )−] ],( )−] [, meets, overlaps, starts, during, finishes, equals, !, !!}, si C = (C1 ~ C2, P, f) avec C1 ∈ X et C2 ∈ X, alors TC (ϕ, d) = min{TC1 (ϕ, d), TC2 (ϕ, d)} ; — si C = (C1 lasts δ, P, f), alors TC (ϕ, d) = TC1 (ϕ, d); — si C = (C1 at most δ, P, f), alors TC (ϕ, d) = TC1 (ϕ, d); — si C = (C1 at least δ, P, f), alors TC (ϕ, d) = TC1 (ϕ, d); — si C = (C1 then δ, P, f), alors nous définissons tout d’abord l’instant τC1,δ(ϕ, d) correspondant au plus petit instant t + δ tel qu’il y a eu une nouvelle reconnaissance de C1 dans le flux ϕ à l’instant t et tel que t ≤ d < t + δ, comme suit : τC1,δ(ϕ, d) = min{Tmax(r1) + δ : r1 ∈ RC1 (ϕ, d) ∧ Tmax(r1) + δ > d} Alors TC (ϕ, d) = min{τC1,δ(ϕ, d), TC1 (ϕ, d)} ; 64CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES — si C = (C1→x, P, f), alors TC (ϕ, d) = TC1 (ϕ, d); — si C = (@C1, P, f), alors TC (ϕ, d) = TC1 (ϕ, d). Remarque 15. Notons que l’opérateur « then » se distingue des autres opérateurs du fait que la reconnaissance de la chronique découle du temps qui passe et non de l’occurrence d’un évènement dans le flux. C’est cette chronique qui rend nécessaire la définition de la fonction Look-ahead. Nous pouvons alors démontrer la propriété suivante, qui caractérise le comportement recherché de la fonction. Propriété 6 (Look-ahead). Après l’instant d, l’ensemble des reconnaissances de la chronique C n’évoluera pas avant au moins l’instant TC (ϕ, d). Plus formellement, pour toute chronique C ∈ X et pour tout instant d ∈ R : ∀t1 ∈ [d, TC (ϕ, d)[ RC (ϕ, d) = RC (ϕ, t1) Démonstration. Soit d ∈ R. Nous montrons cette propriété par induction sur la chronique C. Pour simplifier les notations, on s’affranchit ici des attributs, du prédicat P et de la fonction f. La démonstration complète est analogue. Soit t1 ∈ [d, TC (ϕ, d)[. Par la Propriété 1, il ne reste à montrer que l’inclusion RC (ϕ, d) ⊇ RC (ϕ, t1). — Si C = A ∈ N. Par définition, on a RA(ϕ, t1) = {(e, t) : ∃i ϕ(i) = (e, t) ∧ e = a ∧ t ≤ t1}, et RA(ϕ, d) = {(e, t) : ∃i ϕ(i) = (e, t) ∧ e = a ∧ t ≤ d}. Par l’absurde, soit (e0, t0) ∈ RA(ϕ, t1) \ RA(ϕ, d). On a donc t0 < t1 < TA(ϕ, d), i.e. t0 < min{t : ∃i ∈ N ∃e ∈ N ϕ(i) = (e, t) ∧ t > d}. Or t0 > d car (e0, t0) ∈/ RA(ϕ, d), donc t0 ∈ {t : ∃i ∈ N ∃e ∈ N ϕ(i) = (e, t) ∧ t > d} et, en particulier, t0 < t0. Absurde. D’où RA(ϕ, t1) \ RA(ϕ, d) = ∅, et donc RA(ϕ, d) ⊇ RA(ϕ, t1). — Si C = C1 | | C2. On note que t1 < TC (ϕ, d) = min{TC1 (ϕ, d), TC2 (ϕ, d)} et donc t1 < TC1 (ϕ, d) et t1 < TC2 (ϕ, d). RC (ϕ, t1) = {hr, ⊥i : r ∈ RC1 (ϕ, t1)} ∪ {h⊥, ri : r ∈ RC2 (ϕ, t1)} = {hr, ⊥i : r ∈ RC1 (ϕ, d)} ∪ {h⊥, ri : r ∈ RC2 (ϕ, d)} par hypothèse d’induction = RC (ϕ, d) — La démonstration relative aux opérateurs de conjonction, de séquence, d’absence, meets, overlaps, starts, during, finishes, equals, lasts δ, at most δ, at least δ, cut, et changement d’état est identique à celle du cas précédent (car la définition de TC (ϕ, d) est identique pour ces opérateurs). — Si C = C1 then δ. On a RC (ϕ, d) = {hr1,(τ, i)i : i ≤ d ∧ r1 ∈ RC1 (ϕ, i) ∧ i = Tmax(r1) + δ}, Et : RC (ϕ, t1) = {hr1,(τ, j)i : j ≤ t1 ∧ r1 ∈ RC1 (ϕ, j) ∧ j = Tmax(r1) + δ}. = RC (ϕ, d) ∪ {r1 : ∃j d < j ≤ t1 ⇒ (r1 ∈ RC1 (ϕ, j) ∧ j = Tmax(r1) + δ)} On souhaite montrer que {hr1,(τ, j)i : d < j ≤ t1 ∧ r1 ∈ RC1 (ϕ, j) ∧ j = Tmax(r1) + δ} est 65Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements vide. Par l’absurde supposons hr1,(τ, j)i un élément de cet ensemble. Alors d < j ≤ t1 et r1 ∈ RC1 (ϕ, j) ∧ j = Tmax(r1) + δ. Comme t1 < TC (ϕ, d) ≤ TC1 (ϕ, d), j ∈]d, t1] implique que j ∈ [d, TC1 (ϕ, d)[. On peut donc appliquer l’hypothèse d’induction qui nous donne que RC1 (ϕ, d) = RC1 (ϕ, j). On a donc que r1 ∈ RC1 (ϕ, d). De plus, on a bien que j = Tmax(r1) + δ > d, Donc j = Tmax(r1) + δ ∈ {Tmax(r1) + δ : r1 ∈ RC1 (ϕ, d) ∧ Tmax(r1) + δ > d}. Or j ≤ t1 < TC1 (ϕ, d) ≤ τC1,δ(ϕ, d) = min{Tmax(r1)+δ : r1 ∈ RC1 (ϕ, d)∧Tmax(r1)+δ > d}. Absurde. Donc RC (ϕ, t1) = RC (ϕ, d). — Si C = C1→x ou si C = @C1, la démonstration est immédiate car TC (ϕ, d) = TC1 (ϕ, d). 2.6 Tableau récapitulatif informel des propriétés du langage des chroniques Le Tableau 2.1 présente un récapitulatif informel de l’ensemble des constructions et propriétés du langage des chroniques qui ont été présentées dans ce chapitre. 66CHAPITRE 2. CONSTRUCTION D’UN CADRE THÉORIQUE POUR LA RECONNAISSANCE DE COMPORTEMENTS : LE LANGAGE DES CHRONIQUES Tableau 2.1 – Récapitulatif informel des constructions et propriétés du langage des chroniques Nom Chronique Pré-requis Ce(C1)∩Ce(C2) ={♦} Ce Cr Forme de l’arbre Condition temporelle Commut. Assoc. Look-ahead évènement simple A {♦} Ce (e, t) min{t:ϕ(i)=(e, t) ∧t > d} séquence C1 C2 • ∪ Ce hr1, r2i Tmax(r1) < Tmin(r2) • min{TC1 , TC2 } conjonction C1& C2 • ∪ Ce hr1, r2i • • min{TC1 , TC2 } disjonction C1 || C2 ∩ Ce hr1, ⊥i, h⊥, r2i • • min{TC1 , TC2 } absence (C1) − [C2[ • ∪ Cr(C1) hr1i ∀r2 ( Tmin(r1)>Tmin(r2) ∨ Tmax(r1) Tmin(r2) ∧ Tmax(r1) Tmin(r2) ∧ Tmax(r1)= Tmax(r2) min{TC1 , TC2 } equals C1 equals C2 • ∪ Ce hr1, r2i Tmin(r1) = Tmin(r2) ∧ Tmax(r1)= Tmax(r2) • • min{TC1 , TC2 } lasts C lasts δ Cr Ce hri Tmax(r)− Tmin(r)=δ TC at least C at least δ Cr Ce hri Tmax(r)− Tmin(r)>δ TC at most C at most δ Cr Ce hri Tmax(r)− Tmin(r)<δ TC then C then δ Cr Ce hr, (τ, i)i i = Tmax(r)+δ min{τC1,δ(ϕ, d), TC1 (ϕ, d)} nommage C →x Cr {x, ♦} hri TC cut C1!C2 • ∪ Ce hr1, r2i Tmax(r1) < Tmin(r2) . . . min{TC1 , TC2 } changement d’état C1!!C2 • ∪ Ce hr1, r2i Tmax(r1) < Tmin(r2) . . . min{TC1 , TC2 } évènement de reco. @ C Cr Ce (e, t) TC 67Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements 2.7 Conclusion Dans ce chapitre, nous avons largement étendu le langage des chroniques présenté dans [CCK11]. Nous avons ajouté de nombreux opérateurs, augmentant ainsi l’expressivité de notre langage. Notamment, nous avons ajouté dix constructions exprimant toutes les contraintes temporelles possibles en transposant dans notre formalisme la logique d’intervalles d’Allen. Nous avons également formalisé la notion de propriété liée à un évènement du flux à analyser. Ceci nous a ensuite permis de doter le langage des chroniques de la possibilité d’exprimer des contraintes sur ces attributs d’évènement. Pour l’ensemble de ces constructions, nous avons formellement défini la syntaxe et la sémantique associées. Pour ce faire, nous avons été amenés à raffiner la représentation des reconnaissances en passant d’un formalisme ensembliste à un formalisme arborescent conservant davantage d’informations sur la reconnaissance. Nous avons étudié les principales propriétés du langage étendu des chroniques. Nous avons également défini une fonction de Look-ahead qui permet de formaliser la gestion du temps continu dans le cadre d’une implémentation éventuelle du processus de reconnaissance, en indiquant à quels instants interroger le système. Nous possédons donc maintenant un cadre théorique formel complet pour effectuer de la reconnaissance de comportements. Il s’agit donc maintenant d’implémenter un processus de reconnaissance de chroniques fondé sur cette base théorique. Nous allons construire deux tels modèles : — dans les Chapitres 3 et 4, nous allons définir un modèle à l’aide de réseaux de Petri colorés permettant de valider les principes de reconnaissance en faisant notamment ressortir les problèmes de concurrence ; — dans le Chapitre 5, nous implémentons un modèle de reconnaissance sous la forme d’une bibliothèque C++ appelée Chronicle Recognition Library (CRL). 68Chapitre 3 Un modèle de reconnaissance en réseaux de Petri colorés dit « à un seul jeton » Sommaire 4.1 Construction et fonctionnement des réseaux dits « multi-jetons » . 118 4.1.1 Types et expressions utilisés dans les réseaux multi-jetons . . . . . . . . 119 4.1.2 Structure globale des réseaux multi-jetons . . . . . . . . . . . . . . . . . 119 4.1.3 Briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.1.4 Construction par induction . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.1.5 Bilan sur le degré de contrôle acquis et stratégie de tirage . . . . . . . . 133 4.2 Construction et fonctionnement des réseaux « contrôlés » . . . . . . 134 4.2.1 Types et expressions utilisés . . . . . . . . . . . . . . . . . . . . . . . . . 135 4.2.2 Structure globale des réseaux . . . . . . . . . . . . . . . . . . . . . . . . 137 4.2.3 Briques de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 4.2.4 Un séparateur de jetons générique . . . . . . . . . . . . . . . . . . . . . 144 4.2.5 Construction par induction des réseaux contrôlés . . . . . . . . . . . . . 146 4.2.6 Graphes d’espace d’états des réseaux contrôlés . . . . . . . . . . . . . . 159 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Dans le Chapitre 2, nous avons formalisé un langage de description de comportements, le langage des chroniques, et sa sémantique associée, définissant ainsi la notion de reconnaissance d’une chronique dans un flux d’évènements. Il s’agit maintenant de proposer une implémentation du processus de reconnaissance dont il est possible de montrer que l’exécution respecte la sémantique préalablement définie dans la Section 2.3.2. En effet, dans l’optique de traiter des applications critiques (par exemple s’assurer qu’un avion sans pilote respecte bien des procédures de sécurité 69Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements données, comme dans la Section 5.3), il faut que le processus de reconnaissance soit fiable et robuste car il n’y a pas de droit à l’erreur. Nous allons développer deux implémentations du système de reconnaissance de comportements permettant cette vérification. Dans ce chapitre et le suivant, nous commençons par définir, à l’aide de réseaux de Petri colorés, un premier modèle de reconnaissance d’un sous-langage des chroniques restreint aux opérateurs de séquence, de conjonction, de disjonction et d’absence, et qui ne permet donc pas l’expression de contraintes temporelles ni de contraintes sur des attributs d’évènement. Pour chaque chronique, un réseau, construit par induction, calcule l’ensemble des reconnaissances de la chronique sur un flux d’évènements donné. Une version initiale de ce modèle est présentée dans [CCK11], mais il n’est pas totalement formalisé car il faut réaliser la démonstration de son adéquation avec la sémantique des chroniques. Ce modèle, contrairement à ceux présentés dans le Chapitre 4, ne possède qu’un jeton par place. C’est pourquoi nous nous y référons comme le modèle « à un seul jeton ». Dans ce chapitre, nous complétons la formalisation des réseaux de Petri colorés présentés dans [CCK11] et nous nous attaquons à la vérification de son adéquation [CCKP12a] : — nous posons une nouvelle définition théorique de la notion de fusion de réseaux de Petri colorés ; — nous corrigeons les modèles de la conjonction et de l’absence pour qu’ils fonctionnent dans tous les cas de composition ; — nous proposons une formalisation de la construction des réseaux en faisant ressortir une structure commune à tous les réseaux afin de pouvoir les définir par induction ; — nous formalisons également les règles d’exécution des réseaux pour bien obtenir les ensembles de reconnaissances des chroniques concernées ; — nous démontrons la correction des réseaux vis-à-vis de la sémantique ensembliste de la Section 2.3.2 pour les chroniques incluant, au plus, une absence au plus haut niveau. Dans une première Section (3.1), nous commençons par rappeler la définition des réseaux de Petri colorés en introduisant la notion d’arcs inhibiteurs ainsi qu’une nouvelle définition de fusion. Nous construisons ensuite formellement dans la Section 3.2 les réseaux de Petri colorés modélisant la reconnaissance de chroniques ; puis, dans la Section 3.3, nous décrivons le comportement des réseaux lorsqu’ils suivent une certaine règle d’exécution définie en 3.3.6. Le modèle est alors complètement formalisé. Ceci nous permet de montrer dans la Section 3.4 que, pour des constructions faisant intervenir au plus une absence au plus haut niveau, les reconnaissances produites par les réseaux correspondent exactement à celles définies par la sémantique du langage. Nous achevons ce chapitre en étudiant dans la Section 3.5 la complexité des réseaux construits. 3.1 Définition du formalisme des réseaux de Petri colorés Commençons par définir le formalisme des réseaux de Petri colorés employé par la suite pour modéliser le processus de reconnaissance. Dans la Section 3.1.1, nous introduisons les notions de type et d’expression. Nous donnons ensuite dans la Section 3.1.2 une définition des réseaux de Petri colorés. Cette définition est complétée dans la Section 3.1.3 par une nouvelle notion de fusion de réseaux, et dans la Section 3.1.4 par des arcs inhibiteurs. 70CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » 3.1.1 Types et expressions Il s’agit ici de fournir un cadre formel pour la description des types de données et des fonctions utilisés dans les réseaux (voir la Section 3.2.1 pour la description concrète des types et expressions de nos réseaux). À partir d’un ensemble de types de base, nous construisons l’ensemble des types de fonction possibles : Définition 20 (signature d’expression typée). Soit un ensemble B dont les éléments seront des types de base. On définit inductivement l’ensemble des types fonctionnels de B, noté TB, par : b ∈ B b ∈ TB (type de base) τ1, . . . , τn, τ ∈ TB τ1 × · · · × τn → τ ∈ TB (type fonctionnel) On définit l’arité d’un type χ ∈ TB, notée ari(χ), par : — si χ ∈ B, alors ari(χ) = 0 — si χ = τ1 × · · · × τn → τ , alors ari(χ) = n Si B est un ensemble de types de base, F, un ensemble de fonctions, et σ : F −→ TB une fonction de typage, on appelle Σ = (B, F, σ) une signature d’expression typée. À partir de cette signature, on peut définir l’ensemble des expressions qui sont employées dans les gardes et les étiquettes des arcs : Définition 21 (ensemble des expressions). Soit Σ = (B, F, σ) une signature d’expression typée. Un ensemble de variables B-typées est un couple (V, σ) où V est un ensemble de variables et σ : V → B est une fonction de typage. On définit par induction l’ensemble des V -expressions de Σ, noté ExprΣ(V ) , et on prolonge canoniquement la fonction σ à ExprΣ(V ) par : x ∈ V x ∈ ExprΣ(V ) (variable) c ∈ F ari(σ(c)) = 0 c ∈ ExprΣ(V ) (constante) f ∈ F e1, . . . , en ∈ ExprΣ(V ) σ(f) = σ(e1) × · · · × σ(en) → τ f(e1, . . . , en) ∈ ExprΣ(V ) σ(f(e1, . . . , en)) = τ (fonction) 3.1.2 Réseaux de Petri colorés Un réseau de Petri coloré est un graphe biparti composé de deux types de nœuds : des places représentées par des ellipses, et des transitions représentées par des rectangles. Des arcs orientés lient des places à des transitions. Ils sont étiquetés par des expressions. On les appelle arcs en entrée et, dans les réseaux que nous utilisons, ils sont étiquetés par des noms de variables. D’autres arcs orientés lient des transitions à des places. On les appelle arcs en sortie et ils sont étiquetés par des expressions de fonctions dans lesquelles des variables des arcs d’entrée de la transition, appelées variables d’entrée, peuvent apparaître. 71Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Les places sont typées et stockent un ou plusieurs éléments de leur type, appelés jetons, qui constituent le marquage de la place. Dans les réseaux de Petri de ce chapitre, chaque place ne contiendra qu’un seul jeton. En revanche, dans le Chapitre 4, nous construisons un modèle tirant parti de la possibilité d’avoir plusieurs jetons par place. Les transitions peuvent être munies de gardes, c’est-à-dire de conditions booléennes, dans lesquelles peuvent apparaître les variables d’entrée de la transition. Une transition peut être tirée lorsque les deux conditions suivantes sont réunies : (i) si elle possède une garde, celle-ci est vérifiée ; (ii) toutes les places liées par un arc d’entrée à la transition possèdent un jeton (c’est-à-dire qu’une valeur peut être attribuée à chaque variable d’entrée de la transition). Tirer une transition revient à consommer les jetons indiqués sur les arcs d’entrée de la transition et à appliquer les fonctions étiquetant les arcs de sortie de la transition, c’est-à-dire à ajouter la valeur de ces fonctions au contenu des places liées par des arcs de sortie à la transition. Ainsi, au fur et à mesure que les transitions sont tirées, le marquage des places évolue. Remarque 16 (multiples tirages successifs possibles de transitions). On remarque donc que, pour un marquage donné d’un réseau, il peut y avoir plusieurs séquences possibles de transitions tirables. Ce comportement non déterministe – dans le sens où il ne mène pas nécessairement toujours au même marquage – peut être souhaité pour exprimer différentes possibilités d’évolution d’un système. Cependant, notre travail sur les réseaux de Petri nécessite d’obtenir systématiquement le même marquage à l’issue du traitement occasionné par un évènement du flux. En effet, on doit pouvoir lire dans celui-ci l’ensemble des reconnaissances de la chronique. Notons que cela n’implique pas qu’il n’existe qu’une seule stratégie de tirage de transitions adaptée, comme on le verra dans la Section 4.2. Il nous faudra donc soit accompagner chaque réseau d’une stratégie de tirage, soit montrer que toute séquence possible de transitions donne le même marquage final du réseau. Définissons maintenant plus formellement un réseau de Petri coloré, d’après la définition de [JK09]. Définition 22 (réseau de Petri coloré). Un réseau de Petri coloré N est un 9-uplet (P, T, A, B, V, C, G, EX, I) où : 1. P est un ensemble fini de places ; 2. T est un ensemble fini de transitions disjoint de P ; 3. A ⊆ P × T ] T × P est un ensemble d’arcs orientés ; 4. B est un ensemble fini de types ; 5. V est un ensemble fini de variables typées par une fonction σ telle que ∀v∈V σ(v)∈B ; 6. C : P → B est une fonction de coloriage qui à chaque place associe un type ; 7. G : T → ExprΣ(V ) est une fonction de garde qui à chaque transition associe une garde de type booléenne et dont les variables sont des éléments de V ; 72CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » 8. EX : A → ExprΣ(V ) est une fonction d’expression d’arcs qui à chaque arc associe une expression telle que, pour tout arc a ∈ A, EX(a) est du même type que la place à laquelle est relié l’arc a ; 9. I : P → ExprΣ(V ) est une fonction d’initialisation qui à chaque place associe un marquage initial tel que, pour toute place p ∈ P, σ(I(p)) = C(p). Pour modéliser et exécuter les réseaux de Petri colorés, nous utilisons le logiciel CPN Tools 1 [RWL+03]. La Figure 3.1 présente l’apparence d’un réseau dans l’interface de CPN Tools. Pour simplifier la lecture et la conception de réseaux, CPN Tools dispose d’un système d’annotation de fusion (« fusion tags ») : deux places possédant la même annotation de fusion 2 doivent être assimilées à une unique place, et possèdent par conséquent le même marquage. Ce système sert notamment à la composition de réseaux, ce que nous exploitons pour la construction inductive de nos réseaux. Il offre également la possibilité d’effectuer des simulations et des analyses d’espace d’états. INT transition [garde cpt] cpt+1 0 place cpt 3 1`3++ 2`4 marquage initial marquage courant: 1 jeton de valeur 3 et 2 jetons de valeur 4 type nombre total de jetons annotation de fusion annotation de fusion Figure 3.1 – Un réseau sur CPN Tools 3.1.3 La fusion de places Nous modélisons le processus de reconnaissance de chroniques en élaborant des réseaux de Petri colorés associés aux chroniques, et ce de façon modulaire : cette construction se fait par induction sur la structure de la chronique, à l’aide de fusion de places. Il s’agit maintenant de définir formellement ce mécanisme de fusion. Il existe deux types de fusion pour les réseaux de Petri colorés : la fusion de places, et la fusion de transitions. Cette dernière consiste en l’unification de plusieurs transitions en une unique transition regroupant les arcs d’entrée et de sortie de ces transitions, et dont la garde est la conjonction de l’ensemble des gardes des transitions fusionnées. La transition résultante n’est donc tirable que lorsque l’ensemble des transitions fusionnées le sont. Cette caractéristique n’est pas désirable pour notre modèle et nous n’utilisons donc pas cette fonctionnalité. La fusion de places se comprend premièrement intuitivement comme une facilité d’écriture : les places fusionnées partagent systématiquement le même marquage initial, le même type, et le même 1. http://cpntools.org/ 2. Selon le formalisme défini par la suite en 3.1.3, ces deux places appartiennent donc à un même ensemble de fusion de places. 73Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements marquage courant, et il s’agit donc du dédoublement d’une unique place facilitant la représentation des arcs d’entrée et de sortie, évitant ainsi l’éventuel « plat de spaghetti ». Cependant, nous verrons que la fusion de places peut également poser des problèmes de sémantique. Une définition formelle de la fusion est proposée dans [CP92] (Definition 4.3) où sont définis des réseaux de Petri modulaires – Modular Coloured Petri Nets (MCPNs). Ce sont des triplets (S, P F, T F) où : (i) S est un ensemble fini de modules qui sont des réseaux de Petri disjoints ; (ii) P F est un ensemble fini d’ensembles de fusion de places vérifiant certaines conditions ; (iii) T F est un ensemble fini d’ensembles de fusion de transitions. Nous nous inspirons largement de cette définition, mais nous avons besoin d’y apporter quelques modifications. D’une part, dans cette définition, un réseau de Petri modulaire est construit à partir d’un ensemble de réseaux de Petri non modulaires S dont on souhaite fusionner certaines places et certaines transitions. Cette définition ne convient pas directement à notre construction. En effet, elle est définie par induction, et des fusions successives sont donc effectuées. La fusion doit donc se faire à partir d’un ensemble de réseaux de Petri eux-même modulaires. Dans [CP92] il est ensuite montré (Théorème 4.9) que, pour tout MCPN, on peut aisément construire un réseau de Petri coloré non modulaire équivalent, ce qui résout notre problème. Cependant, afin de nous affranchir de conversions incessantes, nous établissons dans cette section une définition directe de la fusion de places à partir de MCPN plutôt qu’à partir de réseaux de Petri colorés simples. D’autre part, un pré-requis sur l’ensemble P F est que toutes les places d’un de ses ensembles de fusions de places pf (c’est-à-dire toutes les places à fusionner ensemble) doivent avoir le même type et le même marquage initial. C’est une condition que l’on retrouve également dans un article de K. Jensen [HJS91]. Cependant, dans le logiciel que nous utilisons, CPN Tools, il est possible de fusionner deux places ayant des types et marquages initiaux différents : c’est la première place sélectionnée qui définit les caractéristiques de la seconde. Nous n’autoriserons pas la fusion de places de types différents car cela pourrait entraîner la construction d’un réseau mal formé, même si les réseaux de départ son bien formés. En revanche, la fusion de places de marquages initiaux différents offre des possibilités intéressantes en permettant d’adapter le marquage initial d’une place selon qu’elle soit fusionnée ou non. Nous aurons besoin d’exploiter cette possibilité, donc nous l’intégrons dans notre définition de la fusion. Enfin, comme nous ne mettons pas en œuvre de fusion de transitions, nous ne faisons pas apparaître l’ensemble T F. On obtient ainsi les définitions suivantes, en commençant par poser la notion de MCPN puis en formalisant la fusion. Définition 23 (réseau de Petri coloré modulaire). Un réseau de Petri coloré modulaire (MCPN) est un couple (S, P F) vérifiant les propriétés suivantes : (i) S est un ensemble fini de modules tel que : — Chaque module s ∈ S est un réseau de Petri coloré (Ps, Ts, As, Bs, Vs, Cs, Gs, EXs, Is). 74CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » — Les ensembles des éléments des réseaux sont deux-à-deux disjoints : ∀s1 ∈ S ∀s2 ∈ S [s1 6= s2 ⇒ (Ps1 ∪Ts1 ) ∩ (Ps2 ∪Ts2 ) = ∅] Notons que l’on peut renommer les places et les transitions de manière unique en les préfixant par un identifiant de réseau. On pourra donc supposer que les réseaux ont des places et des transitions distinctes sans mettre en œuvre cette préfixation qui conduit à des notations excessivement lourdes. (ii) P F ⊆ P × P(P) est un ensemble fini de couples de fusion de places, dont on appellera place d’initialisation de la fusion le premier membre, ainsi qu’ensemble de fusion de places le second, où P = S s∈S Ps et P(P) désigne l’ensemble des parties de P, et tel que : — Toute place d’initialisation appartient à l’ensemble de fusion de places associé. ∀(p0, E) ∈ P F p0 ∈ E — Toutes les places d’un ensemble de fusion de places ont même type. ∀(p0, E) ∈ P F ∀p1 ∈ E ∀p2 ∈ E C(p1) = C(p2) — L’ensemble des ensembles de fusion de places forme une partition de P 3 . [ ∀p ∈ P ∃p0 ∈ P ∃E ∈ P(P) ((p0, E) ∈ P F ∧ p ∈ E) ] ∧ [ ∀p01 ∈ P ∀p02 ∈ P ∀E1 ⊆ P ∀E2 ⊆ P ( (p01 , E1)∈P F ∧(p02 , E2)∈P F ∧E16=E2 ) ⇒ E1∩E2 = ∅ ] Remarque 17. Notons qu’à tout réseau de Petri coloré N correspond trivialement un MCPN équivalent : il suffit de poser M = {S, P F} où S = {N} et P F = {(p, {p}) : p ∈ PN }. On définit maintenant une fonction de fusion entre réseaux de Petri modulaires. C’est celle-ci que nous appliquons lors de l’induction pour construire nos réseaux de Petri associés aux chroniques. Définition 24 (fusion de places). Soit M = {(S1, P F1), . . . ,(Sn, P Fn)} un ensemble fini de MCPN et soit P F0 un ensemble fini de couples de fusion de places tels que : — Les places d’initialisation de fusion des couples de P F0 sont des places d’initialisation de couples des P F1, . . . , P Fn : ∀p0∈P ∀E0⊆P [ (p0, E0)∈P F0 ⇒ ( ∃i∈J1, nK ∃Ei⊆P (p0, Ei)∈P Fi ) ] — Les ensembles de fusion de places des couples de P F0 sont formés de places des MCPN de M : ∀p0∈P ∀E0⊆P [ (p0, E0)∈P F0 ⇒ ( ∀p∈E0 ∃i∈J1, nK ∃Ei⊆P ((p0, Ei)∈P Fi ∧ p ∈ Ei) ) ] Alors on peut définir la fusion de ces MCPN relativement à l’ensemble P F0 : F usion(M, P F0) = (S, P F) où : — S = S 1≤i≤n Si — P F = {(p0, S p∈E E(p)) : (p0, E) ∈ P F0} où E(p) est l’unique Ei tel que (p, Ei) ∈ P Fi . 3. Notons que la contrainte que les ensembles de fusion de places soient deux à deux disjoints n’était pas requise dans [CP92] mais découle de notre construction qui autorise la fusion de places à marquages initiaux différents. En effet, si une place appartenait à deux ensembles de fusion de places distincts, deux marquages initiaux différents pourraient lui être associés, ce qui est absurde. 75Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements On peut montrer, à l’aide d’une démonstration analogue à celle exposée dans [CP92], que le réseau de Petri suivant ainsi que le MCPN à partir duquel il est construit sont équivalents du point de vue de leur comportement (évolution du marquage, transitions tirables, places atteignables. . . ). Définition 25 (réseau de Petri coloré équivalent). Pour toute place d’initialisation p0, E(p0) désigne l’ensemble de fusion de places associé, et pour toute place p et toute transition t, s(p) et s(t) désignent respectivement le réseau de Petri de S tel que p ∈ Ps(p) et celui tel que t ∈ Ts(t) . Soit M = (S, P F) un réseau de Petri coloré modulaire. On définit le réseau de Petri coloré équivalent par M∗ = (P ∗ , T ∗ , A∗ , B ∗ , V ∗ , C∗ , G∗ , EX∗ , I∗ ) où : (i) P ∗ = {p0 ∈ P : ∃E0 ∈ P(P) (p0, E0) ∈ P F} (on rappelle que P = S s∈S Ps) (ii) T ∗ = S s∈S Ts (iii) A∗ = {(p0, t) ∈ P ∗ × T ∗ : ∃p ∈ E(p0) (p, t) ∈ As(p)} ∪ {(t, p0) ∈ T ∗ × P ∗ : ∃p ∈ E(p0) (t, p) ∈ As(p)} (iv) B ∗ = S s∈S Bs (v) V ∗ = S s∈S Vs (vi) C ∗ : P ∗ → B∗ , p0 7→ Cs(p0)(p0) (vii) G∗ : T ∗ → ExprΣ(V ∗) , t 7→ Gs(t)(t) (viii) EX∗ : A∗ → ExprΣ(V ∗) est défini par : — pour tous (p0, t) tels que ∃p ∈ E(p0) (p, t) ∈ As(p) , (p0, t) 7→ EXs(p)((p, t)), — pour tous (t, p0) tels que ∃p ∈ E(p0) (t, p) ∈ As(p) , (t, p0) 7→ EXs(p)((t, p)). (ix) I ∗ : P ∗ → ExprΣ(V ∗) , p0 7→ Is(p0)(p0) 3.1.4 Arcs inhibiteurs Dans le Chapitre 4, nous construisons des réseaux de Petri plus complexes où il faut pouvoir spécifier qu’une transition n’est tirable que si une place donnée est vide. Cette contrainte ne peut pas s’exprimer par une simple garde sur la transition. On introduit un nouveau type d’arc, l’arc inhibiteur, qui permet l’implémentation d’algorithmes fondés sur l’absence ou non de jetons dans une place. Des réseaux équivalents peuvent être construits sans arcs inhibiteurs à l’aide de listes mais cela conduit à des réseaux trop complexes. On complète donc la Définition 22 des réseaux de Petri colorés comme suit : Définition 26 (arcs inhibiteurs). Un réseau de Petri coloré muni d’arcs inhibiteurs est un 10-uplet (P, T, A, B, V, C, G, EX, I, B) où (P, T, A, B, V, C, G, EX, I) est un réseau de Petri coloré et : 10. B ⊆ P × T est un ensemble d’arcs inhibiteurs orientés. Un arc inhibiteur n’a d’incidence que sur le tirage des transitions. Notons Inh(t) = {p ∈ P : (p, t) ∈ B} l’ensemble des places reliées par un arc inhibiteur à une transition t ∈ T. La contrainte suivante s’ajoute pour qu’une transition t ∈ T soit tirable : 76CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » (iii) aucune place inhibitrice p ∈ Inh(t) ne contient de jeton. Dans le logiciel CPN Tools, les arcs inhibiteurs sont représentés comme sur la Figure 3.2. Lorsque la place est vide, la transition est tirable, ce qui est indiqué par le liseré vert. place 0 INT transition 1 1`3 arc inhibiteur place 0 INT transition Figure 3.2 – Arcs inhibiteurs sur CPN Tools 3.2 Construction formelle des réseaux dits « à un seul jeton » À l’aide du formalisme des réseaux de Petri colorés munis du mécanisme de fusion décrit dans 3.1, nous construisons par induction un modèle du processus de reconnaissance. Pour chaque chronique C, nous définissons un réseau de Petri coloré associé dont le marquage évolue en fonction du flux d’évènements. Une place du réseau contient l’ensemble des reconnaissances correspondant à la chronique étudiée. Nous commençons par établir dans la Section 3.2.1 les types des données et fonctions utilisés. Nous donnons ensuite un aperçu de la structure générale des réseaux que nous allons construire (Section 3.2.2). Nous posons dans la Section 3.2.3 un ensemble élémentaire de réseaux de Petri colorés, les briques de base, que nous utilisons pour construire nos réseaux lors d’une induction sur la structure de la chronique dans la Section 3.2.4. 3.2.1 Types et expressions utilisés dans le modèle Posons maintenant les types et fonctions que nous utilisons dans nos réseaux de Petri en défi- nissant Σ = (B, F, σ) (Définition 20). Posons B = {INT, Event, NCList}, et définissons le type NEvent = Event × INT. Le type INT correspond à un entier, Event, à un évènement, et NCList, à une liste de listes de couples NEvent. Un jeton de type NCList correspond à un ensemble de reconnaissances. Chaque élément de la liste NCList est une liste de NEvent, c’est-à-dire une liste d’évènements datés qui représente une reconnaissance. Posons F = {+, max, ANR, CPR, rem_obs, mixAnd, last_ini_recog} qui correspond à l’ensemble des fonctions employées dans nos réseaux. 77Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Le Tableau 3.3 décrit brièvement le fonctionnement général de ces fonctions. Une explication axée sur notre utilisation de ces fonctions sera donnée lors de la description de l’exécution des réseaux dans la Section 3.3. À partir des fonctions de F, nous pouvons alors définir une dernière fonction qui permet de compléter des reconnaissances dans une liste avec une instance d’un évènement : complete : ((E(a), cpt), curr, inst) 7→ ANR(inst, CPR([[(E(a), cpt + 1)]], curr) Tableau 3.3 – Fonctions utilisées dans nos réseaux Fonction Type (image de la fonction σ) Description + INT × INT → INT Addition usuelle. max INT × INT → INT Entier maximum entre deux entiers. ANR NCList × NCList → NCList (Add New Recognition) Ajoute le contenu de la seconde liste à la première liste, s’il n’y est pas encore. CPR NEvent × NCList → NCList (Complete Partial Recognition) Renvoie la liste de listes de couples dont chaque liste de couples a été complétée par le couple supplé- mentaire (E(a), cpt + 1). rem_obs INT × NCList → NCList Renvoie la liste de laquelle on a d’abord supprimé toutes les listes de couples dont un des couples (E(a), cpt) a un indice cpt inférieur à l’entier n qui est en argument. mergeAndNew NCList × NCList × NCList × NCList → NCList Renvoie la dernière liste à laquelle a été ajoutée une combinaison explicitée par la suite des trois premières listes. startsub NCList → NCList Renvoie [ [ ] ] si l’argument est une liste non vide, [ ] sinon. chg_win INT × NCList → INT Renvoie le maximum entre l’entier en argument et le plus grand instant de reconnaissance des reconnaissances de la liste. concatabs NCList × NCList × NCList × INT → NCList Effectue les combinaisons séquentielles possibles entre les deux premières listes, puis les ajoute à la troisième liste si elles sont nouvelles (le critère de nouveauté étant déterminé par une comparaison avec l’entier). 78CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » 3.2.2 Structure générale des réseaux « à un seul jeton » Nous construisons donc inductivement sur la structure du langage un réseau de Petri coloré pour chaque chronique. Il permet de calculer, en fonction d’un flux d’évènements, l’ensemble de reconnaissances associé. Pour pouvoir réaliser cette construction inductive, il faut que les réseaux soient modulaires. Cette caractéristique se traduit par le fait que tous les réseaux associés aux chroniques ont une structure générale identique permettant ainsi de les combiner. Cette structure est présentée dans la Figure 3.4. Figure 3.4 – Structure des réseaux Chaque réseau possède un compteur d’évènements (place Present et transition End) ainsi que quatre places principales : — la place Present, de type INT, est fusionnée avec le compteur d’évènements et contient un entier correspondant au nombre d’évènements déjà traités ; — la place Start est de type NCList, elle contient une liste de reconnaissances qui seront complétées par le réseau ; — la place Success est également de type NCList, elle contient les reconnaissances de la place Start complétées par le réseau ; — la place Wini, de type INT, contient un entier qui sert de repère dans le cas d’une absence, permettant de déterminer les reconnaissances qu’il faut alors supprimer de la place Start. Chaque place contient exactement un seul jeton d’où le nom de modèle « à un seul jeton ». Les places Start et Success sont marquées d’un jeton contenant une liste des reconnaissances. Les reconnaissances vont circuler dans les réseaux au fur et à mesure de l’évolution du flux d’évènements. Pour une chronique complexe, une reconnaissance est d’abord vide [ ] dans la place Start 79Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements du réseau général, puis elle va petit à petit être complétée par les évènements pertinents du flux. Au fur et à mesure qu’elle est complétée, elle va transiter de la place Start à la place Success des sous-réseaux, passant de sous-réseau en sous réseau pour arriver, lorsque la reconnaissance est complète, à la place Success du réseau général. Les réseaux « à un seul jeton » se lisent de gauche à droite, ce qui correspond au circuit des reconnaissances. Ce sont ces quatre places principales que l’on fusionne tour à tour entre plusieurs réseaux et avec les briques élémentaires que nous allons définir dans la Section 3.2.3. Pour la gestion correcte d’absences dans une séquence (ce qui est détaillé dans la Section 3.3.5), les places Wini sont en fait divisées en deux catégories : les places WiniIn et les places WiniOut qui permettent de fusionner correctement les places pour construire nos réseaux. Lors de la construction des réseaux, nous définissons donc cinq fonctions qui à chaque chronique C associent les cinq types de place principaux Present(C), Start(C), Success(C), WiniIn(C) et WiniOut(C) du réseau correspondant à la chronique C. 3.2.3 Briques de base Définissons maintenant les quelques réseaux élémentaires que nous utilisons comme briques de base dans la construction inductive de notre modèle de reconnaissance. cpt+1 cpt End Present 0 INT Figure 3.5 – Compteur d’évènements Compteur Ce réseau élémentaire, noté CPT et présenté dans la Figure 3.5, fait office de compteur d’évènements. Il est composé d’une place Present dans laquelle est stockée la valeur de ce compteur, et d’une transition End qui incrémente le compteur à chaque fois qu’elle est tirée. Opérateur AND Ce réseau élémentaire, noté OPAND et présenté dans la Figure 3.6, calcule l’ensemble des reconnaissances de la conjonction de deux chroniques C1 et C2. On donne ici une description très succincte du fonctionnement de cet opérateur. La Section 3.3.4 détaille davantage le déroulement d’une reconnaissance de conjonction. Le réseau est composé de six places. Dans deux places, Operand1 et Operand2, sont stockées les reconnaissances respectives de C1 et de C2. Lorsque la transition AND est tirée, les reconnaissances de C1 et celles de C2 sont combinées de façon à récupérer dans la place Success les reconnaissances de C1&C2. Si la conjonction forme la seconde partie d’une séquence, c’est-à-dire si la chronique étudiée est de la forme · · ·(C3 C1&C2)· · · , nous ne souhaitons pas que le réseau commence à reconnaitre C1 et C2 tant que la première partie de la séquence (à savoir C3) n’a pas été reconnue. La transition Sub 80CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » rem_obs init inst2 inst2 mergeAndNew curr inst1 inst2 inst Forget AND [] NCList Operand2 [] NCList ~1 INT Success [] NCList [] [] Wini inst Sub startSub curr NCList curr rem_obs init curr inst2 inst1 rem_obs init inst1 Operand1 inst1 Start NCList startsub curr curr2 curr init Figure 3.6 – Opérateur AND sert à initialiser les places Start de C1 et de C2 afin de contrôler la mise en route du mécanisme de reconnaissance de C1 et de C2. La transition Forget sert dans le cas de l’absence. La place Success de ce réseau joue un rôle central car elle stocke les reconnaissances de C1&C2. Nous aurons donc besoin de nous y référer pour effectuer des fusions. Pour cela, nous utiliserons Success(AND) pour Success, de même que Start(AND) pour Start et Wini(AND) pour Wini. bck init inst Update Down ~1 INT WiniBe ~1 INT [] NCList [] NCList [] [[]] INT init Sub WiniAf Abs Forget Start rem_obs init curr StartSub curr Oper Present Success concatabs inst curr inst2 cpt inst2 curr2 0 curr cpt max bck init init chg_win init inst [] inst [] NCList startsub inst NCList NCList Figure 3.7 – Opérateur ABS Opérateur ABS Ce réseau élémentaire, noté OPABS et présenté dans la Figure 3.7, sert à composer deux réseaux de Petri correspondant aux chroniques C1 et C2 pour obtenir les reconnaissances de (C1) − [C2[. Le rôle de ce réseau est double : — La partie de gauche du réseau est chargée d’assurer la gestion de l’entier repère stocké dans les places Wini du reste du réseau. Rappelons que cet entier permet d’établir si certaines 81Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements reconnaissances doivent être supprimées car invalidées par une absence. La place WiniBe stocke l’indice suivant celui de la dernière reconnaissance de C2 et est mise à jour par le tirage de la transition Update. Cet indice sert à supprimer les reconnaissances partielles de C1 qui ne doivent pas être complétées car C2 a été reconnue. La place WiniAf sert dans le cas où (C1) − [C2[ est elle-même imbriquée dans une autre absence : elle propage grâce à la transition Down la valeur du Wini de la seconde absence, mais la valeur de Wini de la première absence (celle dans WiniBe) n’est en revanche pas propagée à l’extérieur de celle-ci. — La partie de droite doit son origine au caractère modulaire de nos réseaux. Elle est chargée de recombiner les reconnaissances de l’absence (qui sont stockées dans la place Oper) avec les reconnaissances pouvant les précéder (qui sont dans la place Start). Ce genre de combinaison est nécessaire lorsque la chronique étudiée contient une absence mais à un niveau de profondeur non nul, par exemple lorsqu’une absence est composée avec une sé- quence (comme D ((A B) − [C[)). Il s’agit d’une combinaison analogue à celle effectuée par la fonction mergeAndNew pour l’opérateur OPAND mais avec une contrainte temporelle supplémentaire : la combinaison doit être séquentielle. Il n’est pas possible de faire transiter les reconnaissances précédant l’absence à travers le réseau d’absence car la portée de l’absence doit être délimitée. La brique ABS permet donc de marquer les bornes de l’absence et d’isoler les reconnaissances jusqu’à ce qu’elles soient prêtes à être combinées. Comme dans l’opérateur AND, la place StartSub sert à activer le réseau de l’absence. En effet, lorsque l’on cherche à reconnaître D ((A B) − [C[) par exemple, on ne souhaite pas commencer à reconnaître (A B) − [C[ tant qu’il n’y a pas de reconnaissance de D à compléter. La transition Sub permet donc à la fois de mettre à jour la liste des reconnaissances globales de la place Success, et d’activer le réseau de l’absence si nécessaire. Une description plus élaborée du mécanisme de l’absence et des nombreuses problématiques qui lui sont associées est donnée dans la Section 3.3.5. 3.2.4 Construction par induction Avec les types et expressions définis dans la Section 3.2.1 et les réseaux élémentaires de la Section 3.2.3, nous pouvons maintenant construire notre modèle en réseau de Petri colorés du processus de reconnaissance. Pour chaque chronique C, nous définissons par induction un réseau de Petri coloré N(C) qui calcule les reconnaissances de C. Chaque réseau résulte de la fusion d’un compteur d’évènements et de sous-réseaux. La construction par induction se fait donc en deux étapes. Pour une chronique C, nous définissons d’abord une réseau N0 (C) qui correspond au mécanisme global de reconnaissance sans le compteur, puis nous réalisons une fusion de N0 (C) avec le compteur pour définir N(C). Ce sont les réseaux N0 (C) qui sont utilisés comme sous-réseaux dans l’induction comme nous le verrons par la suite. Comme évoqué dans la Section 3.2.2, dans la construction par induction, certaines des places Present, Start, Success et Wini jouent un rôle dans la composition des réseaux. En effet, quelle que soit la chronique C, chaque réseau N(C) a la même structure globale que nous avons présentée dans la Figure 3.4. Formellement, nous définissons en parallèle de N(C) les places Present(C), Start(C), Success(C), WiniIn(C) et WiniOut(C) qui délimitent cette structure et qui sont donc 82CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » utilisées si l’on compose le réseau avec un autre réseau. Dans cette section, nous présentons la construction formelle de nos réseaux de reconnaissance de chroniques en expliquant les fusions effectuées et le mécanisme global de chaque réseau. Dans les Sections 3.3.1 à 3.3.5, nous donnons ensuite une explication plus détaillée du mécanisme de chaque réseau. Si C = A ∈ N Dans le cas d’un évènement simple, ce réseau élémentaire utilisé pour sa reconnaissance correspond exactement à N0 (C). cpt End Forget A Present 1_Num 0 INT Wini ~1 Success [] NCList Present 1_Num INT Start 1_Num curr NCList rem_obs init curr curr [[]] init INT complete (E(a),cpt) curr inst 0 1_Num cpt+1 cpt inst Figure 3.8 – Réseau correspondant à la chronique A La Figure 3.8 représente le réseau N(A) relatif à l’évènement simple A. Comme évoqué dans la description de la structure générale des réseaux (Section 3.2.2), la place Start contient les reconnaissances devant être complétées par le réseau. Dans l’exemple présenté ici, il s’agit uniquement de reconnaître A. Le marquage de la place Start est donc [ [ ] ] : la reconnaissance à compléter est la reconnaissance vide [ ] qui pourra évoluer en une reconnaissance de A en transitant dans le réseau. La place Wini et la transition Forget sont utilisées si le réseau est fusionné pour construire une chronique plus complexe incluant une absence. On définit la structure du réseau : Present(C) = Present Start(C) = Start Success(C) = Success WiniOut(C) = Wini WiniIn(C) = ∅ 4 83Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Puis on pose 5 : N(C) = Fusion({N 0 (C), CPT}, {(Present(C), {Present(C), Present(CPT)})}) (3.1) Si C = C1 C2 rem_obs init curr init End A Forget B Forget Present Fusion 84 Present Fusion 84 INT Success Fusion 85 Start Wini Present Fusion 84 Success Start Fusion 85 Wini Fusion 85 Fusion 84 INT cpt cpt+1 0 Fusion 84 0 cpt complete (E(a),cpt) curr inst inst NCList[] curr curr NCList [[]] rem_obs init curr init INT Fusion 84 INT 0 complete (E(b),cpt) curr inst NCList [] inst cpt curr curr [] NCList INT ~1 ~1 Figure 3.9 – Réseau correspondant à la chronique A B Afin de modéliser une séquence C1 C2 (comme la séquence A B dont le réseau est représenté Figure 3.9), nous fusionnons la place Success du réseau N(C1) avec la place Start du réseau N(C2). Le marquage initial de la place Start(C2) change donc : il prend le marquage initial de la place Success(C1), c’est-à-dire [ ]. Ainsi, le réseau ne commence pas à reconnaître C2 tant que ce n’est pas pour compléter une reconnaissance de C1. Remarque 18 (marquages initiaux des places Start). Dans nos réseaux, il y a deux marquages initiaux possibles pour une place Start : — la liste qui contient la liste vide, [ [ ] ], indique que le réseau peut activer son mécanisme et compléter la reconnaissance partielle vide [ ] – on dit alors que le réseau est activé ; — la liste vide [ ] indique qu’il n’y a encore aucune reconnaissance partielle à compléter, et tant que le marquage n’est pas modifié, le mécanisme du réseau ne peut pas opérer et on dit qu’il n’est pas activé. Les marquages initiaux des places Start permettent donc de contrôler précisément l’activation des différentes parties d’un réseau, pour ne pas activer la reconnaissance d’un évènement tant que 4. Ceci signifie qu’il n’y a pas de place WiniIn dans les réseaux d’évènement simple. 5. Par la suite, nous effectuons des fusions de réseaux de Petri colorés et de MCPN. Du fait de la Remarque 17, nous ne prenons pas la peine de redéfinir un MCPN équivalent pour les quelques réseaux de Petri non modulaires mis en jeu. 84CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » ce n’est pas nécessaire. Par exemple, dans le cas de la séquence C1 C2, nous avons vu qu’il n’est pas nécessaire de commencer à reconnaître les évènements relatifs à C2 tant qu’une reconnaissance complète de C1 n’est pas disponible pour être complétée. Les différents marquages initiaux sont rendus possibles par la fonctionnalité de fusion évoquée dans la Section 3.1.3 qui détermine le marquage initial des places fusionnées. On pose : N0 (C) = Fusion({N0 (C1), N0 (C2)}, { (Present(C1), {Present(C1), Present(C2)}), (Success(C1), {Success(C1), Start(C2)}), (WiniIn(C1), {WiniIn(C1), WiniIn(C2), WiniOut(C2)}) }) On définit la structure du réseau : Present(C) = Present(C1) Start(C) = Start(C1) Success(C) = Success(C2) WiniOut(C) = WiniOut(C1) WiniIn(C) = WiniOut(C2) Puis nous fusionnons avec le compteur d’évènements comme dans l’équation (3.1). Sur la Figure 3.9, on remarque que les places Present(A), Present(B), et Present(CPT) ont la même annotation de fusion, à savoir Fusion_84. De même pour Success(A) et Start(B) qui appartiennent à un même ensemble de fusion annoté Fusion_85. Si C = C1 || C2 Afin de modéliser la disjonction (comme A || B dont le réseau est représenté Figure 3.10), les deux réseaux N0 (C1) et N0 (C2) fonctionnent en parallèle. Nous fusionnons donc les places Start des deux réseaux et les places Success des deux réseaux. On pose : N0 (C) = Fusion({N0 (C1), N0 (C2)}, { (Start(C1), {Start(C1), Start(C2)}), (Present(C1), {Present(C1), Present(C2)}), (Success(C1), {Success(C1), Success(C2)}), (WiniOut(C1), {WiniOut(C1), WiniOut(C2)}), (WiniIn(C1), {WiniIn(C1), WiniIn(C2)}) }) 85Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements inst init cpt init A Forget B Forget End Success Fusion 89 Present Fusion 87 Start Fusion 88 Wini Fusion 90 Present Fusion 87 Success Fusion 89 Start Fusion 88 Wini Fusion 90 Present Fusion 87 Fusion 89 Fusion 87 Fusion 87 Fusion 89 complete (E(a),cpt) curr inst INT0 cpt NCList curr [] curr Fusion 88 NCList [[]] rem_obs init curr INT Fusion 90 ~1 INT 0 Fusion 87 cpt+1 cpt INT0 complete (E(b),cpt) curr inst [] NCList inst curr curr NCList[[]] Fusion 88 rem_obs init curr Fusion 90 INT ~1 Figure 3.10 – Réseau correspondant à la chronique A || B On définit la structure du réseau : Present(C) = Present(C1) Start(C) = Start(C1) Success(C) = Success(C1) WiniOut(C) = WiniOut(C1) WiniIn(C) =  WiniIn(C1) si WiniIn(C1) 6= ∅ WiniIn(C2) sinon Puis nous fusionnons avec le compteur d’évènements comme dans l’équation (3.1). 86CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » rem_obs init curr init inst2 curr startsub curr curr2 cpt rem_obs init curr init cpt cpt+1 cpt Forget AND Sub Forget A Forget B End Operand1 4_SuccessA NCList Operand2 4_SuccessB NCList Wini 4 Init INT Success [] NCList Start [] NCList startSub 4 Start [[]] Success 4_SuccessA NCList Wini 4 Init Present 4_Num Start 4 Start NCList Wini ~1 4 Init Start 4 Start NCList Success 4_SuccessB NCList Present 4_Num 0 Present 4_Num 4_SuccessA 4_SuccessB INT 4_Num 0 0 4_Num INT complete (E(a),cpt) curr inst 4_SuccessA [] inst curr curr init 4 Init ~1 INT rem_obs init curr 4 Start [[]] INT 4_Num complete (E(b),cpt) curr inst [] 4_SuccessB inst curr [[]] curr 4 Start INT 4 Init inst1 mergeAndNew curr inst1 inst2 inst inst curr NCList ~1 4 Init 4 Start rem_obs init inst1 rem_obs init inst2 inst2 curr inst1 [] [] Figure 3.11 – Réseau correspondant à la chronique A&B Si C = C1&C2 Pour modéliser une conjonction C1&C2 (comme A&B dont le réseau est représenté Figure 3.11), les réseaux N0 (C1) et N0 (C2) fonctionnent aussi en parallèle, donc nous fusionnons les places Start des deux réseaux. Nous fusionnons les places Success des deux réseaux avec des places de l’opérateur OPAND afin de construire les reconnaissances de C1&C2. On pose : N0 (C) = Fusion({N0 (C1), N0 (C2), OPAND}, { (Start(C1), {Start(C1), Start(C2)}), (Present(C1), {Present(C1), Present(C2)}), (Success(C1), {Success(C1), Operand1}), (Operand2, {Operand2, Success(C2)}), (WiniOut(C1), {WiniOut(C1), WiniOut(C2), Wini(AND)}, (WiniIn(C1), {WiniIn(C1), WiniIn(C2)}) }) 87Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements On définit la structure du réseau : Present(C) = Present(C1) Start(C) = Start(C1) Success(C) = Success(AND) WiniOut(C) = WiniOut(C1) WiniIn(C) =  WiniIn(C1) si WiniIn(C1) 6= ∅ WiniIn(C2) sinon Puis nous fusionnons avec le compteur d’évènements comme dans l’équation (3.1). Si C = (C1) − [C2[ rem_obs init curr init init chg_win init inst init curr inst2 concatabs inst curr inst2 cpt cpt rem_obs init curr init curr complete (E(c),cpt) curr inst cpt curr curr init cpt init curr cpt cpt+1 cpt Forget Update Down Sub Forget C Forget B Forget A End WiniAf INT Abs Fusion 92 [] NCList WiniBe Fusion 95 ~1 INT StartSub Fusion 94 [] NCList Oper Fusion 98 [] NCList Success NCList Start [[]] NCList Present Fusion 91 0 INT Wini ~1 INT Start Fusion 94 [] NCList Success Fusion 92 [] NCList Present Fusion 91 0 INT Start Fusion 93 [] NCList Success Fusion 98 [] NCList Wini Fusion 95 ~1 INT Present Fusion 91 0 INT Success Fusion 93 [] NCList Wini ~1 INT Start Fusion 94 [] NCList Present Fusion 91 0 INT Present 0 Fusion 91 INT Fusion 91 Fusion 94 Fusion 93 Fusion 91 Fusion 95 Fusion 98 Fusion 93 Fusion 91 Fusion 92 Fusion 94 Fusion 95 Fusion 94 complete (E(a),cpt) curr inst inst complete (E(b),cpt) curr inst inst rem_obs init curr curr rem_obs init curr inst curr max bck init bck ~1 Fusion 98 Fusion 91 startsub inst [] curr2 curr inst Fusion 92 [] inst Figure 3.12 – Réseau correspondant à la chronique (A B) − [C[ Afin de modéliser l’absence (C1) − [C2[ (comme (A B) − [C[ dont le réseau est représenté Figure 3.12), nous fusionnons les places Wini du réseau N(C1) et Success du réseau N(C2) avec des places de l’opérateur OPABS afin de rendre la chronique C2 « interdite ». On pose : 88CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » N0 (C) = Fusion({N0 (C1), N0 (C2), OPABS}, { (Start(C1), {Start(C1), Start(C2), StartSub}), (Present(C1), {Present(C1), Present(C2), Present(ABS)}), (Success(C1), {Success(C1), Oper}), (Success(C2), {Success(C2), Abs}), (WiniIn(C1), {WiniIn(C1), WiniBe}) }) On définit la structure du réseau : Present(C) = Present(C1) Start(C) = Start(ABS) Success(C) = Success(ABS) WiniOut(C) = WiniAf WiniIn(C) = ∅ Puis nous fusionnons avec le compteur d’évènements comme dans l’équation (3.1), ce qui complète la formalisation de la construction de nos réseaux. 3.3 Formalisation et description de l’exécution des réseaux Dans cette section, nous présentons le fonctionnement des réseaux que nous venons de définir en prenant appui sur des exemples d’exécution. Nous définissons ensuite une stratégie formelle pour le tirage des transitions car toutes les transitions de nos réseaux sont en permanence tirables mais toute séquence de transitions tirée ne mène pas au marquage recherché, à savoir celui où l’on peu correctement lire les ensembles de reconnaissance. Décrivons maintenant le fonctionnement de ces réseaux. Pour chacune des constructions précé- dentes, nous présentons l’ensemble de ses places, puis les effets de ses transitions. Nous expliquons ensuite la stratégie de tirage à adopter pour obtenir les ensembles de reconnaissance corrects. Cette stratégie de tirage est formalisée dans la Section 3.3.6. 3.3.1 Reconnaissance d’un évènement simple Étudions le comportement d’un réseau reconnaissant un évènement simple sur l’exemple de la Figure 3.13 qui correspond à la chronique A ∈ N. Il est composé de deux sous-réseaux : le réseau de compteur d’évènements de la Figure 3.5, et le réseau relatif à la transition A. Notons que l’annotation de fusion 1_Num indique que les deux places Present sont fusionnées. Places Les places Present des deux sous-réseaux sont fusionnées, et ont donc le même marquage. Elles sont de type INT et contiennent un entier qui correspond à la valeur du compteur d’évènement. 89Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements Figure 3.13 – Réseau correspondant à la chronique A Les places Start et Success sont de type NCList, c’est-à-dire qu’elles contiennent une liste d’instances de chroniques. La place Start a un rôle dans la composition des réseaux pour des chroniques complexes. Ici, son marquage est constant, égal à son marquage initial [ [ ] ]. La place Success contient la liste des reconnaissances de la chronique A. La partie du réseau composée de la place Wini et de la transition Forget est utilisée dans le cas de l’absence. Son fonctionnement est donc explicité dans la section de la reconnaissance de l’absence (3.3.5). Transitions Lorsque la transition End est tirée, l’entier de la place Present est incrémenté de 1. La valeur du compteur est apposée aux évènements pour les distinguer entre eux, comme il est détaillé par la suite. Il faut donc augmenter le compteur à chaque évènement du flux. Au tirage de la transition End, le marquage du réseau évolue comme suit : Start Success Present   curr inst cpt   End −→   curr inst cpt + 1   Lorsque la transition A est tirée, le contenu de la place Success est modifié : la liste des reconnaissances déjà présente dans la place Success est complétée par une nouvelle reconnaissance, notée (E(a), cpt+ 1) (que l’on notera aussi Ecpt+1 a ) où cpt est la valeur du compteur d’évènements. Ci-dessous, nous avons simplifié la définition de la fonction complete en intégrant le fait que, ici, curr = [ [ ] ]. La fonction ANR (Add New Recognition) ajoute la nouvelle reconnaissance [Ecpt+1 a ] à la liste inst. 90CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » Start Success Present   curr inst cpt   A −→   curr ANR(inst, [ [Ecpt+1 a ] ]) cpt   Stratégie de tirage Considérons un flux ϕ. Ce sont les évènements du flux ϕ qui déterminent la suite de transitions à tirer. Si un évènement de nom différent de A a lieu, seule la transition End est tirée : seul le compteur d’évènement est incrémenté. Si un évènement de nom A a lieu, la transition A est tirée, de façon à ajouter l’évènement à la liste des reconnaissances, puis la transition End est tirée pour incrémenter le compteur. Exemple 8. Soit ϕ = ((b, 1),(a, 2),(d, 3),(a, 4)) avec a, b, d ∈ N où nous souhaitons reconnaître la chronique A. La liste des transitions à tirer correspondant au flux ϕ est [End, A, End, End, A, End]. Le marquage des places du réseau évolue comme suit : Start Success Present   [ [ ] ] [ ] 0   End −→   [ [ ] ] [ ] 1   A −→   [ [ ] ] [ [E2 a ] ] 1   End −→   [ [ ] ] [ [E2 a ] ] 2   End −→   [ [ ] ] [ [E2 a ] ] 3   A −→   [ [ ] ] [ [E2 a ], [E4 a ] ] 3   End −→   [ [ ] ] [ [E2 a ], [E4 a ] ] 4   On obtient bien deux reconnaissances, [E2 a ] et [E4 a ] dues à (a, 2) et (a, 4). 3.3.2 Reconnaissance d’une séquence Nous allons étudier le réseau de Petri de la Figure 3.14 qui correspond à la chronique A B où A, B ∈ N pour examiner le déroulement d’une séquence. Il est composé de trois sous-réseaux : le réseau de compteur d’évènements, le réseau relatif à la transition A et le réseau relatif à la transition B. Places Comme précédemment, les places Present des trois sous-réseaux sont fusionnées, de type INT, et contiennent un entier correspondant au compteur d’évènements. La place Start du réseau A a un marquage constant, égal à son marquage initial [ [ ] ]. La place Success du réseau A est fusionnée avec la place Start du réseau B. Les deux sousréseaux A et B fonctionnent donc en série. La place Start du réseau B n’a donc plus un marquage constant [ [ ] ]. Son marquage initial est la liste vide [ ] qui est le marquage initial de Success(A). Comme évoqué dans la Remarque 18, ceci implique que le mécanisme du réseau relatif à B ne peut pas être effectif tant que le marquage initial n’a pas été modifié car il n’y a pas de reconnaissance partielle à compléter. Au fur et à mesure de l’exécution du réseau, Start(B) pourra contenir une liste contenant une liste non vide : il s’agira des reconnaissances partielles de A B, c’est-à-dire des reconnaissances de A, qu’il faut compléter par des reconnaissances de B. 91Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements rem_obs init curr init End A Forget B Forget Present Fusion 84 Present Fusion 84 INT Success Fusion 85 Start Wini Present Fusion 84 Success Start Fusion 85 Wini Fusion 85 Fusion 84 INT cpt cpt+1 0 Fusion 84 0 cpt complete (E(a),cpt) curr inst inst NCList[] curr curr NCList [[]] rem_obs init curr init INT Fusion 84 INT 0 complete (E(b),cpt) curr inst NCList [] inst cpt curr curr [] NCList INT ~1 ~1 1 1`0 1 1`0 1 1`[] 1 1`[[]] 1 1`(~1) 1 1`0 1 1`[] 1 1`[] 1 1`(~1) Figure 3.14 – Réseau correspondant à la chronique A B La place Success du réseau B contient les reconnaissances de la chronique A B. Comme précédemment, on ignore pour le moment les parties des réseaux A et B composées de la place Wini et de la transition Forget et relatives à l’absence. Transitions Lorsque la transition End est tirée, le compteur d’évènements est incrémenté de 1. Lorsque la transition A est tirée, une nouvelle reconnaissance de A est ajoutée à la liste contenue dans la place Success, comme dans le réseau précédent. Lorsque la transition B est tirée, la reconnaissance de B complète les reconnaissances de A qui se trouvent dans la place Start(B) (à l’aide de la fonction CPR - Complete Partial Recognition) pour former des reconnaissances de A B qui sont ajoutées à la liste de la place Success(B). En effet, la fonction complete prend en argument la variable currB qui correspond au contenu de la place Start et complète les reconnaissances partielles qui s’y trouvent. C’est pour cela que le marquage initial de Success(A) et Start(B) est [ [ ] ] et non [ ] : la fonction complete va compléter la liste vide, il n’y a pas encore de reconnaissance de A. Start(A) Start(B) Success(B) Present     currA currB instB cpt     B −→     currA currB ANR(instB, CPR([ [E cpt+1 b ] ], currB)) cpt     Stratégie de tirage Si un évènement de nom différent de A et de B a lieu, seule la transition End est tirée, et donc seul le compteur d’évènements est incrémenté. Si un évènement de nom A a lieu, la transition A est tirée de façon à ajouter l’évènement à la liste des reconnaissances partielles, puis la transition End est tirée. De même, si un évènement de nom B a lieu, la transition B est tirée 92CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » de façon à compléter les reconnaissances partielles et obtenir des reconnaissances de A B, puis la transition End est tirée. Exemple 9. Soit ϕ = ((b, 1),(a, 2),(d, 3),(a, 4),(b, 5)) avec a, b, d ∈ N où l’on souhaite reconnaître la chronique A B. La liste des transitions à tirer correspondant au flux ϕ est [B, End, A, End, End, A, End, B, End]. Le marquage des places du réseau évolue comme suit (on rappelle que les places Success(A) et Start(B) sont fusionnées et ont donc le même marquage) : Start(A) Success(A) Success(B) Present     [ [ ] ] [ ] [ ] 0     B −→     [ [ ] ] [ ] [ ] 0     End −→     [ [ ] ] [ ] [ ] 1     A −→     [ [ ] ] [ [E2 a ] ] [ ] 1     End −→     [ [ ] ] [ [E2 a ] ] [ ] 2     End −→     [ [ ] ] [ [E2 a ] ] [ ] 3     A −→     [ [ ] ] [ [E2 a ], [E4 a ] ] [ ] 3     End −→     [ [ ] ] [ [E2 a ], [E4 a ] ] [ ] 4     B −→     [ [ ] ] [ [E2 a ], [E4 a ] ] [ [E2 a , E5 b ], [E4 a , E5 b ] ] 4     End −→     [ [ ] ] [ [E2 a ], [E4 a ] ] [ [E2 a , E5 b ], [E4 a , E5 b ] ] 5     Remarquons que le premier tirage de la transition B ne modifie pas le marquage du réseau. Ceci est dû au fait que le marquage de la place Start(B) est [ ] et qu’il n’y a donc aucune liste, même vide, à compléter. Comme il s’agit d’une séquence, on ne commence pas à reconnaître B tant que l’on n’a pas reconnu A. Le cas particulier A A Il est important de vérifier que le cas particulier A A ne pose pas de problème dans la gestion des différentes combinaisons pour les reconnaissances et qu’il faut bien deux occurrences distinctes de A pour reconnaître la séquence. Ceci est garanti par la fonction complete qui ne complète que les reconnaissances datant d’un instant inférieur ou égal à l’instant courant cpt du compteur d’évènements. Étudions le mécanisme sur le flux ((a, 1),(a, 2)). On dénomme A1 et A2 les deux réseaux fusionnés pour former N(A A). À la suite du tirage de la transition A1 pour le traitement de l’évènement (a, 1), le marquage de Success(A1) (qui est aussi celui de Start(A2)) est [[E1 a ]]. Lorsque l’on tire A2, la fonction complete examine l’instant de chacune des reconnaissances à compléter. Il n’y a pour le moment que [E1 a ] à compléter et son instant de reconnaissance est 1. La compteur d’évènements est encore à 0 donc la contrainte n’est pas vérifiée (¬ 0 ≥ 1) et [E1 a ] ne peut être complétée par (a, 1). On tire alors la transition End et le compteur passe à 1. [E1 a ] peut donc maintenant être complétée. Pour traiter (a, 2), on tire A1 ce qui modifie le marquage de Success(A1) à [[E1 a ], [E2 a ]] et on tire A2 ce qui ne peut compléter que [E1 a ]. On obtient alors [[E1 a , E2 a ]] 93Reconnaissance de comportements complexes par traitement en ligne de flux d’évènements comme marquage de Success(A2); on a bien une unique reconnaissance et le cas particulier A A est correctement traité. 3.3.3 Reconnaissance d’une disjonction cpt+1 cpt init remove_obsolete init curr curr inst complete (E(b),cpt) curr inst inst complete (E(a),cpt) curr inst init remove_obsolete init curr End Forget B A Forget Present 3_Num 0 INT Wini 3 Init ~1 INT Success 3_Success [] NCList Present 3_Num 0 INT Present 3_Num 0 INT Success 3_Success [] NCList Start 3_Start [[]] NCList Wini 3 Init ~1 INT Start 3_Start [[]] NCList 3_Start 3_Success 3_Num 3_Num 3_Success 3_Num 3 Init 3 Init cpt cpt curr curr curr 1 1`0 1 1`(~1) 1 1`[] 1`0 1 1`0 1 1 1`[] 1 1`[[]] 1 1`(~1) 1 1`[[]] Figure 3.15 – Réseau correspondant à la chronique A || B Étudions le comportement d’une disjonction à travers le réseau de Petri de la Figure 3.15 qui correspond à la chronique A || B où A, B ∈ N. Il est composé de trois sous-réseaux : le réseau de compteur d’évènements, le réseau relatif à la transition A et le réseau relatif à la transition B. Places Comme précédemment, les places Present des trois sous-réseaux sont fusionnées, de type INT, et contiennent un entier correspondant au compteur d’évènements. 94CHAPITRE 3. UN MODÈLE DE RECONNAISSANCE EN RÉSEAUX DE PETRI COLORÉS DIT « À UN SEUL JETON » Les places Start des réseaux A et B sont fusionnées et ont ici un marquage constant, égal à [ [ ] ]. Les deux sous-réseaux fonctionnent donc en parallèle. Les places Success des réseaux A et B sont aussi fusionnées. Elles contiennent la liste des reconnaissances de A || B. Comme précédemment, on ignore pour le moment les parties des réseaux A et B composées de la place Wini et de la transition Forget. Transitions Lorsque la transition End est tirée, le compteur d’évènements est incrémenté de 1. Lorsque la transition A est tirée, une nouvelle reconnaissance de A est ajoutée à la liste contenue dans la place Success. Une reconnaissance de A est une reconnaissance de A || B. De même, lorsque la transition B est tirée, une nouvelle reconnaissance de B est ajoutée à la liste contenue dans la place Success. Ainsi, la place Success contient toutes les reconnaissances de A et toutes celles de B, ce qui correspond à toutes les reconnaissances de A || B. Stratégie de tirage Si un évènement de nom différent de A et de B a lieu, seule la transition End est tirée, et donc seul le compteur d’évènements est incrémenté. Si un évènement de nom A (respectivement B) a lieu, la transition A (respectivement B) est tirée de façon à ajouter l’évènement à la liste des reconnaissances de la place Success, puis la transition End est tirée. Exemple 10. Soit ϕ = ((b, 1),(a, 2),(d, 3),(a, 4)) avec a, b, d ∈ N où nous souhaitons reconnaître A || B. La liste des transitions à tirer correspondant au flux ϕ est [B, End, A, End, End, A, End]. Le marquage des places du réseau évolue comme suit : Start Success