De nouveaux outils pour calculer avec des inductifs en Coq - Thèse Informatique

De nouveaux outils pour calculer avec des inductifs en Coq - Thèse Informatique - Revenir à l'accueil

FICHIERS


 

 

 

Source : 

https://hal.archives-ouvertes.fr/tel-01054723

 

De nouveaux outils pour calculer avec des inductifs en Coq
Pierre Boutillier 1, 2 
 
Résumé : En ajoutant au lambda-calcul des structures de données algébriques, des types dépendants et un système de modules, on obtient un langage de programmation avec peu de primitives mais une très grande expressivité. L'assistant de preuve Coq s'appuie sur un tel langage (le CIC) à la sémantique particulièrement claire. L'utilisateur n'écrit pas directement de programme en CIC car cela est ardu et fastidieux. Coq propose un environnement de programmation qui facilite la tâche en permettant d'écrire des programmes incrémentalement grâce à des constructions de haut niveau plus concises. Typiquement, les types dépendants imposent des contraintes fortes sur les données. Une analyse de cas peut n'avoir à traiter qu'un sous-ensemble des constructeurs d'un type algébrique, les autres étant impossibles par typage. Le type attendu dans chacun des cas varie en fonction du constructeur considéré. L'impossibilité de cas et les transformations de type doivent être explicitement écrites dans les termes de Coq. Pourtant, ce traitement est mécanisable et cette thèse décrit un algorithme pour réaliser cette automatisation. Par ailleurs, il est nécessaire à l'interaction avec l'utilisateur de calculer des programmes du CIC sans faire exploser la taille syntaxique de la forme réduite. Cette thèse présente une machine abstraite conçu dans ce but. Enfin, les points fixes permettent une manipulation aisée des structure de données récursives. En contrepartie, il faut s'assurer que leur exécution termine systématiquement. Cette question sensible fait l'objet du dernier chapitre de cette thèse.
Type de document : 
Thèse
Programming Languages. Université Paris-Diderot - Paris VII, 2014. French
Domaine :
Informatique / Langage de programmation

 

Autres thèses en informatique :

[TXT]

 Etude-theorique-cryp..> 06-Jan-2015 13:08  3.0M  

[TXT]

 Modelisation-qualita..> 06-Jan-2015 13:08  2.6M  

[TXT]

 Etude-de-representat..> 06-Jan-2015 13:07  3.0M  

[TXT]

 Exploration-et-struc..> 06-Jan-2015 13:07  3.4M  

[TXT]

 Analyse-de-dependanc..> 06-Jan-2015 13:06  4.5M  

[TXT]

 Scenarisation-d-envi..> 06-Jan-2015 13:06  4.1M  

[TXT]

 De-l-auto-evaluation..> 06-Jan-2015 06:51  6.2M

[TXT]

 APISENSE-a-distribut..> 05-Jan-2015 08:09  5.7M  

[TXT]

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

[TXT]

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

[TXT]

 Algorithmique-distri..> 05-Jan-2015 23:00  4.2M  

[TXT]

 Approche-algorithmiq..> 05-Jan-2015 22:53  3.5M  

[TXT]

 Architecture-de-comm..> 05-Jan-2015 08:04  4.4M  

[TXT]

 Bornes-inferieures-e..> 05-Jan-2015 15:39  1.6M  

[TXT]

 CONTRIBUTION-A-LA-ST..> 05-Jan-2015 22:56  5.5M  

[TXT]

 Caracterisation-auto..> 05-Jan-2015 16:34  5.1M  

[TXT]

 Caracterisation-et-d..> 05-Jan-2015 22:51  4.5M  

[TXT]

 Catalogage-de-petits..> 05-Jan-2015 08:06  3.8M  

[TXT]

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

[TXT]

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

[TXT]

 Completion-combinato..> 05-Jan-2015 15:41  2.6M  

[TXT]

 Contribution-a-l-etu..> 05-Jan-2015 22:54  3.2M  

[TXT]

 Contribution-a-la-co..> 05-Jan-2015 16:10  3.5M  

[TXT]

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

[TXT]

 Controle-de-la-puiss..> 05-Jan-2015 22:52  3.6M  

[TXT]

 Coordination-Modulai..> 05-Jan-2015 15:58  2.2M  

[TXT]

 Couplage-de-modeles-..> 05-Jan-2015 22:46  5.3M  

[TXT]

 Cryptographie-sur-le..> 05-Jan-2015 08:01  3.4M  

[TXT]

 De-l-auto-evaluation..> 05-Jan-2015 22:44  6.2M  

[TXT]

 Detection-de-rails-m..> 05-Jan-2015 08:04  5.1M  

[TXT]

 Dispositifs-spatiaux..> 05-Jan-2015 22:59  5.2M  

[TXT]

 Dynamique-des-graphe..> 05-Jan-2015 22:56  5.5M  

[TXT]

 Environnements-urbai..> 05-Jan-2015 08:03  6.3M  

[TXT]

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

[TXT]

 Etude-de-la-synchron..> 05-Jan-2015 15:58  2.4M  

[TXT]

 Etude-des-facteurs-d..> 05-Jan-2015 15:38  1.8M  

[TXT]

 Evaluation-analytiqu..> 05-Jan-2015 08:07  3.5M  

[TXT]

 Evaluation-de-la-sur..> 05-Jan-2015 15:39  1.4M  

[TXT]

 Execution-efficace-d..> 05-Jan-2015 15:39  1.4M  

[TXT]

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

[TXT]

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

[TXT]

 Formes-et-fonctions-..> 05-Jan-2015 22:49  4.5M  

[TXT]

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

[TXT]

 Generation-de-modele..> 05-Jan-2015 15:41  3.2M  

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

 Influence-du-mapping..> 05-Jan-2015 22:49  4.6M  

[TXT]

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

[TXT]

 Integration-et-explo..> 05-Jan-2015 16:35  4.8M  

[TXT]

 Intelligence-en-essa..> 05-Jan-2015 08:03  5.6M  

[TXT]

 Interaction-entre-al..> 05-Jan-2015 22:51  4.1M  

[TXT]

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

[TXT]

 L-architecture-du-di..> 05-Jan-2015 15:40  1.2M  

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

 Methode-de-game-desi..> 05-Jan-2015 08:10  4.2M  

[TXT]

 Methodes-de-reconstr..> 05-Jan-2015 23:05  6.1M  

[TXT]

 Methodes-et-structur..> 05-Jan-2015 22:46  5.6M  

[TXT]

 Methodes-numeriques-..> 05-Jan-2015 22:52  3.9M  

[TXT]

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

[TXT]

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

[TXT]

 Mise-en-oeuvre-de-cr..> 05-Jan-2015 23:03  6.3M  

[TXT]

 Modele-de-comporteme..> 05-Jan-2015 16:10  3.2M  

[TXT]

 Modele-et-experience..> 05-Jan-2015 08:01  3.8M  

[TXT]

 Modelisation-d-un-re..> 05-Jan-2015 23:03  7.2M  

[TXT]

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

[TXT]

 Modelisation-de-la-p..> 05-Jan-2015 15:59  1.9M  

[TXT]

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

[TXT]

 Modelisation-et-scor..> 05-Jan-2015 16:09  4.4M  

[TXT]

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

[TXT]

 Nouvelles-approches-..> 05-Jan-2015 08:09  2.3M  

[TXT]

 Periodes-d-integrale..> 05-Jan-2015 22:54  3.0M  

[TXT]

 Planification-d-une-..> 05-Jan-2015 08:06  4.1M  

[TXT]

 Positionnement-robus..> 05-Jan-2015 15:39  1.5M  

[TXT]

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

[TXT]

 Proposition-d-approc..> 05-Jan-2015 22:58  5.2M  

[TXT]

 Proposition-d-une-ar..> 05-Jan-2015 22:48  5.0M  

[TXT]

 Protection-obligatoi..> 05-Jan-2015 22:44  6.0M  

[TXT]

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

[TXT]

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

[TXT]

 Reseaux-urbains-de-c..> 05-Jan-2015 16:34  5.6M  

[TXT]

 Samsung-Telephone-Mo..> 05-Jan-2015 15:41  2.4M  

[TXT]

 Segmentation-par-cou..> 05-Jan-2015 23:01  3.9M  

[TXT]

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

[TXT]

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

[TXT]

 Simulation-credible-..> 05-Jan-2015 22:58  5.2M  

[TXT]

 Simulations-numeriqu..> 05-Jan-2015 22:48  4.8M  

[TXT]

 Systeme-de-mesure-d-..> 05-Jan-2015 15:40  1.3M  

[TXT]

 Techniques-de-codage..> 05-Jan-2015 22:53  3.5M  

[TXT]

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

[TXT]

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

[TXT]

 Thermoformage-du-ver..> 05-Jan-2015 22:59  4.4M  

[TXT]

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

[TXT]

 Typologies-textuelle..> 05-Jan-2015 23:05  6.1M  

[TXT]

 Un-ilot-formel-pour-..> 05-Jan-2015 08:07  3.1M  

[TXT]

 Une-approche-agile-f..> 05-Jan-2015 16:09  4.0M  

[TXT]

 Une-approche-d-align..> 05-Jan-2015 15:40  2.9M  

[TXT]

 Vers-une-capitalisat..> 03-Jan-2015 22:00  4.6M
Cours d'informatique :

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

 Vers-une-signalisati..> 03-Jan-2015 17:25  3.8M 
De nouveaux outils pour calculer avec des inductifs en Coq Pierre Boutillier To cite this version: Pierre Boutillier. De nouveaux outils pour calculer avec des inductifs en Coq. Programming Languages. Universit´e Paris-Diderot - Paris VII, 2014. French. HAL Id: tel-01054723 https://tel.archives-ouvertes.fr/tel-01054723 Submitted on 8 Aug 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 Diderot (Sorbonne Paris Cité) Laboratoire PPS – Éqipe πr 2 École Doctorale Sciences Mathématique de Paris Centre Thèse de doctorat spécialité Informatiqe De nouveaux outils pour Calculer avec des inductifs en Coq présentée et soutenue publiquement par Pierre Boutillier le 18 février 2014 devant le jury composé de M. Yves Bertot rapporteur M. Roberto Di Cosmo président M. Hugo Herbelin directeur M. Daniel Hirschkoff examinateur M. Conor McBride examinateur Mme. Christine Paulin-Mohring examinatrice M. Carsten Schuermann rapporteurÀ Madou et tonton Jean-Pierre,Mercis Le grade de docteur ne s’obtient jamais seul. J’ai le privilège d’avoir été merveilleusement entouré. Antichronologiquement, comme le veut la coutume, Yves Bertot et Carsten Schuermann ont dû endurer mon style et m’ont malgré tout autorisé à soutenir. Je leur suis énormément reconnaissant de l’eort d’une part et de la pertinence de leurs remarques d’autre part. D’autant que Carsten l’a fait dans une langue étrangère et Yves avec bienveillance. Les discussions avec Hugo m’ont toujours énormément éclairé sur comment aborder une question en conservant ma manière de penser ; vision, il me semble, que nous partageons. Ce manuscrit n’est « pas si pire » grâce à Pierre Letouzey qui m’a oert un peu de la rigueur qui fait tenir Coq debout pour relire exhaustivement ma thèse. Le reste de l’équipe πr 2 Yann, Matthieu, Alexis, Pierre-Louis, Pierre-Marie, Lourdes, Guillaume, Matthias, Sté- phane, Vincent ont tous joué un rôle dans l’écriture et/ou la conception de cette thèse et de sa soutenance. Christine, Frédérique et Thomas ont aussi beaucoup aidé à la genèse de ce document. Fernand Deligny (pédagogue) disait « Soit surtout présent lorsque tu n’es pas là. » C’est le tour de force que réussit Christine Paulin-Mohring avec l’équipe de développement de Coq ! Bien que nos échanges directs soient récents, son inuence ne l’est pas et je la remercie chaleureusement d’évaluer mon travail. Mon cerveau a été scientiquement façonné par Conor McBride. Mes quelques idées originales trouvent leur source dans sa folie. Avant lui, Daniel Hirschko (avec l’ensemble de l’équipe PLUME) m’avait dénitivement fait tomber dans les bras de la programmation comme support du raisonnement. Daniel fut aussi ma boussole aux moments clés de mon cheminement scientique. Daniel et Roberto Di Cosmo, qui m’honore de la présidence de mon jury, furent, de mes enseignants d’informatique, ceux qui m’ont le plus marqué. J’estime que l’enseignement fut une part importante de mon travail de thèse et je pense que si elle fut si plaisante, c’est grâce à leur modèle auxquel j’ai pu me raccrocher. Mes études supérieures doivent énormément au cadre dans lequel elles ont eu lieu. Il me faut donc remercier l’ENS Lyon et le Lycée Fenelon (et donc ceux qui les font ainsi) pour m’avoir d’abord séduit au premier regard, puis pour m’être fait me dire que même rentré par la fenêtre, l’année d’après j’y serai et enn pour ne m’avoir, mais alors pas du tout, déçu ensuite ! A tous les niveaux, les établissements que j’ai fréquentés tenaient debout grâce à leur responsable administratif. Merci pour tout ce travail de l’ombre ! Ma famille m’a donné la possibilité d’un épanouissement personnel rare. Mes parents ont réussi le tour de force de toujours m’encourager à être moi-même sans jamais abandonner l’idée d’améliorer mes torts. Je me suis construit grâce à leur persévérance. Toute la famille 5m’a énormément soutenu et me dire « nis ta thèse pour qu’ils puissent un peu se dire que tu n’as pas gâché toute la liberté qu’ils t’ont ménagée » a été l’un des moteurs irrationnels forts pour mener l’aventure au bout. Sneusneur est aussi à un tournant qu’elle devrait surmonter très fort, nous avons toujours fonctionné en symbiose. Ma thèse et beaucoup plus doivent quotidiennement énormément à Maud. 6Table des matières Introduction 9 Logiques constructives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Quantication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 La généralisation : les inductifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Correspondance preuves/programmes . . . . . . . . . . . . . . . . . . . . . . . . . 11 Machines universelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Programmation fonctionnelle avec types algébriques . . . . . . . . . . . . . . . . . 12 Types riches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Utilisation des données inductives . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Réduction des points xes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1 Un langage fonctionnel avec types riches 17 1.1 Conventions d’écriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Le cœur fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.2.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3 Déclarations globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.4 Types de données algébriques strictement positifs . . . . . . . . . . . . . . . 21 1.4.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.4.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5 Des structures de données d’exemple . . . . . . . . . . . . . . . . . . . . . . 24 1.6 Digression sur la représentation des constructeurs et des branches . . . . . . 26 1.7 Expressivité de l’analyse de cas . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2 Le filtrage en programmation fonctionnelle 29 2.1 Principe du ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.2 Reconnaitre un motif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 Construire un arbre de décision . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.1 Arbre de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.2 Mécanique d’atomisation . . . . . . . . . . . . . . . . . . . . . . . . 34 7Table des matières 3 Encodage du filtrage dans l’analyse de cas 37 3.1 Le ltrage dépendant primitif . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.2 Encodage du ltrage par des analyses de cas . . . . . . . . . . . . . . . . . . 38 3.2.1 Des types riches exprimant les problèmes d’unication . . . . . . . . 39 3.2.2 Manipulation des égalités d’index . . . . . . . . . . . . . . . . . . . . 40 3.3 Utilisabilité de l’encodage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.4 Constructions génériques autour d’une analyse de cas dépendante . . . . . . 42 3.4.1 Coupures entrelacées . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.2 Elimination des branches impossibles . . . . . . . . . . . . . . . . . . 43 4 Du filtrage à l’analyse de cas structurellement 45 4.1 Squelette d’index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2 Quand les égalités sont inutiles . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3 Diagonalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.4 Quand le diagonaliseur en dit trop . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5 Des clauses de retour pour éliminer tous les termes . . . . . . . . . . . . . . 53 4.5.1 Les index du type ne contiennent que des variables et des constructeurs 53 4.5.2 Hors du cadre pseudo-motif . . . . . . . . . . . . . . . . . . . . . . . 54 4.6 Digression sur les cas impossibles dans des points xes . . . . . . . . . . . . 55 4.7 Mécaniser la diagonalisation et compiler le ltrage . . . . . . . . . . . . . . . 56 4.7.1 Construire une analyse de cas à partir de sa clause de retour . . . . . 56 4.7.2 D’un arbre de décision à des analyses de cas . . . . . . . . . . . . . . 57 4.7.3 Extraire un diagonaliseur . . . . . . . . . . . . . . . . . . . . . . . . 59 4.8 Eléments de correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5 Simplifier un terme 63 5.1 Normalisation en appel par nom . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2 Trace des constantes dépliées . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3 Refolding Algebraic Krivine Abstract Machine . . . . . . . . . . . . . . . . . 69 5.4 Congurabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6 Etablir qu’un point fixe ne produit pas de calcul infini 75 6.1 Décroissance structurelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.2 Ranement lié à l’induction . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3 Ranement lié aux coupures entrelacées . . . . . . . . . . . . . . . . . . . . 81 6.4 Ranement lié à la réduction . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.4.1 Garder la forme βιδ normale . . . . . . . . . . . . . . . . . . . . . . . 82 6.4.2 Retrouver la réduction forte . . . . . . . . . . . . . . . . . . . . . . . 84 6.4.3 Questions d’ecacité . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.5 La règle ϕ de réduction impose une garde structurelle . . . . . . . . . . . . . 86 Conclusion et perspectives 89 8Introduction Aucune tâche n’est atomique. Toute action se décompose en opérations plus élémentaires. Agir demande en permanence de concevoir des algorithmes an de réaliser des activités complexes. Le concept de programme et son exécution ou calcul est bien antérieur à l’apparition des ordinateurs. L’informatique, la science qui les étudie, n’a donc pas attendu des machines aussi complexes pour susciter l’intérêt. La mécanisation n’a fait que démultiplier le besoin d’y rééchir formellement. L’humain a le souci de l’optimisation. Dès qu’il trouve un algorithme, il se demande comment faire la même chose en moins d’étapes ou par d’autres moyens. Pourtant, après modications, l’algorithme réalise-t-il eectivement toujours « la même chose » ? Nos cousins shadocks arment que « Plus un ordinateur va vite, plus il donne de bons résultats. . . ». Laissons-leur l’ambiguïté sur la notion de bon résultat et le pied de nez que j’y vois à mon ministère de tutelle. Cette introduction établit un cadre mathématique qui aborde formellement la question de la correction (le fait d’être correct) d’un résultat. Ce manuscrit n’y répond pas ; il aborde des problématiques pour faciliter l’utilisation de systèmes qui permettent d’y répondre. Nous allons d’abord énumérer des systèmes logiques dans lesquels prouver revient de plus en plus à manipuler des données et des fonctions. Il est légitime de parler de logique pour aborder la programmation et d’utiliser des structures de données pour appuyer un raisonnement logique. Nous basculerons en eet dans l’informatique en décrivant les découvertes qui ont identié les deux problématiques en donnant, suivant le point de vue, aux preuves un corps ou aux programmes une description de leur comportement. Ainsi, nous aboutirons à un langage de programmation pratique qui apporte des garanties fortes sur la bonne formation des programmes qu’il permet d’écrire. Nous aurons alors le socle nécessaire pour discuter nos problématiques. Logiques constructives Formaliser la logique est apparu comme un champ des mathématiques au cours du 19e siècle. Des primitives autour desquelles s’articule le raisonnement ont émergé. Parmi ces connecteurs : l’implication exprime la possibilité d’obtenir une propriété B à partir d’une propriété A et s’écrit A → B. Elle vient avec l’axiome que pour toute propriété A, A → A. la conjonction fait de deux propriétés une propriété. la disjonction introduit la notion de choix. Elle se construit en donnant l’une des deux possibilités. Elle demande de savoir agir dans les deux cas pour être détruite. 9Introduction faux n’a pas de règle d’obtention. Elle permet de nier toute proposition. Par ailleurs, les premiers systèmes formels venaient avec la supposition toujours faite jusque là que l’on peut toujours considérer qu’une propriété est soit vraie soit fausse (principe du tiers exclu). On parle aujourd’hui de logique classique. Dans les logiques classiques, prouver l’impossibilité qu’il n’existe pas revient à prouver qu’il existe. L’objet dont la non existence a été niée n’est pas pour autant construit. Un mouvement s’est constitué pour établir des logiques dans lesquelles prouver qu’il existe impose d’exhiber un témoin d’existence. Ce schéma de pensée appelé constructivisme a un intérêt particulier pour voir les preuves d’existence comme des algorithmes de construction. Quelles que soient les structures de données utilisées et les règles de raisonnement autorisées, il existe plusieurs manières de structurer un raisonnement. Parmi elles, la déduction naturelle dénit les connecteurs par deux types de règles : des règles pour les construire ou introduire et des règles pour les détruire ou utiliser. Cette manière de faire est assez intuitive lors de la construction de preuves par l’esprit humain. Le calcul des séquents est lui ecace lors du traitement mécanique des preuves. Pour chaque connecteur, il s’articule autour de règles dites gauches si on suppose avoir la donnée et de règles dites droites si on veut l’obtenir. antification Le type des entiers naturels, déni par l’arithmétique de Peano, représente une classe d’objet contenant une innité d’habitants distincts directement manipulables dans la logique. Les nombres sont construits à l’aide de deux primitives : une constante nommée zéro et une fonction injective successeur qui à tout entier associe l’entier suivant. Surtout, un nouveau concept arrive pour utiliser les nombres entiers : le raisonnement par récurrence. Il permet de prouver des propriétés qui dépendent d’un entier par un raisonnement potentiellement inni. Ce raisonnement est en réalité ni pour tout entier ni car il donne un comportement à adopter ni pour l’entier zéro et un comportement ni pour passer de la propriété pour un entier à cette propriété pour son successeur. L’arithmétique permet d’énoncer des propriétés qui parlent d’entiers naturels. Elle dispose en plus de l’implication d’une notion de quantication : une propriété peut parler des valeurs des objets qu’elle suppose. On peut écrire, pour tout entier naturel n, la propriété P dans laquelle n apparaît. La quantication est aussi utilisable pour permettre à une propriété de dépendre d’une autre propriété. Par ce biais, une propriété peut parler de toutes les propriétés (y compris ellemême). Un tel système est dit imprédicatif. Le système F de Girard est obtenu en ajoutant la quantication sur les propriétés à la logique minimale. Il forme ainsi le système d’expressivité minimale où les raisonnements imprédicatifs sont permis. L’imprédicativité est extrêmement expressive. En système F, les structures de données n’ont pas besoin d’être dénies. Elles sont toutes encodables au moyen de quantications et d’implications (voir les travaux de Böhm etBerarducci [9]). La puissance de l’imprédicativité cause des suspicions chez certains constructivistes quant à son admissibilité. Par contre, l’idée de ne pas se cantonner à un nombre ni de structures 10La généralisation : les inductifs de données a été réexploitée. De même, exprimer des propriétés qui varient selon la valeur des données dont elles dé- pendent s’est révélée une brique élémentaire des systèmes logiques constructifs. Le logical framework (LF) [48] ou λπ [20] est le langage générique pour raisonner sur ces systèmes. La généralisation : les inductifs Martin-Löf a proposé un système logique prédicatif disposant des structures de données de la logique intuitionniste et de quantications sur les valeurs. Pourtant, toutes les structures de données vues jusqu’ici ont toutes un canevas similaire. Elles sont engendrées par un nombre ni de constructeurs et les utiliser revient à énumérer le comportement à adopter dans le cas de chacun des constructeurs. De plus, prouver une propriété dans les cas récursifs peut se faire grâce à cette même propriété sur les sous-parties récursives. De cette constatation, Dybjer [22] a proposé une généralisation de la théorie des types de Martin-Löf avec un monde ouvert. Toute structure de données qui respecte un canevas assurant sa bonne formation est dénissable puis utilisable directement. Les systèmes logiques sont d’une importance fondamentale pour l’informatique. Ces recherches sont en réalité développées non pas seules mais en interaction avec l’informatique grâce à deux découvertes fondamentales du vingtième siècle. Pour poursuivre continûment le déroulé de cette introduction, elles sont présentées ici dans l’ordre antichronologique. Correspondance preuves/programmes Pour tenter d’assurer la correction des programmes, on a cherché à les classier. Pour cela, on leur a associé un type, une spécication construite par des règles d’inférence à partir de la syntaxe du programme qui spécie son comportement. Si l’on sait qu’un morceau de programme est une fonction qui prend un entier et renvoie une liste de vrai ou faux, nous savons qu’il est impossible de l’élever au carré ou de lui donner en entrée un tableau de nombres à virgule. L’intérêt premier des types est de signaler tôt et systématiquement au programmeur toute une classe d’erreurs qu’il a pu commettre, sans attendre que ce programme plante lors de son exécution. Mais avec leur introduction intervient une révolution. Les types ont donné corps au travail des logiciens constructivistes. Prouver que la propriété que A et B implique A ou B est identique à écrire une fonction qui prend la paire d’un élément de type A et d’un élément de B et qui renvoie un élément soit de type A soit de type B. C’est la correspondance de Curry-DeBruijn-Howard ; la logique nourrit l’informatique. Prouver des théorèmes est isomorphe à écrire des programmes si l’on est capable de donner un contenu calculatoire aux axiomes et aux constructeurs de notre logique. Le coeur de ce dispositif est la correspondance entre la fonction et l’implication logique. Autrement dit la logique minimale a pour langage correspondant le λ-calcul simplement typé. 11Introduction Le bloc de données et la conjonction de propriétés sont les deux facettes du même objet. Le choix et disjonction aussi. Derrière la récurrence, il y a un programme clair : les fonctions récursives, c’est-à-dire celles qui se rappellent elles-même. L’arithmétique de Péano a donc un langage de programmation correspondant dont le comportement calculatoire est basé sur le système T de Gödel. Burstall propose avec Hope [15] un langage de programmation ayant un mécanisme de ltrage pour raisonner par cas et la possibilité de dénir des types algébriques. Cette idée a mené à la dénition de la famille de langages fonctionnels ML ainsi qu’à Haskell [31] et a donné le support nécessaire à la dénition de la théorie des types de Martin-Löf. Machines universelles Avant la découverte de cette correspondance entre calculs qui terminent et preuves de théorème, les diérentes manières de calculer avait été prouvées équivalentes. Alan Turing cherchant à modéliser le comportement mécanique du mathématicien en le représentant comme une machine munie d’états d’esprits, d’un alphabet, d’un crayon, d’une gomme, de règles pour changer d’état d’esprit et agir localement sur le papier à partir de son état d’esprit et de ce qu’il lit et d’inniment de feuilles de papiers ; John von Neumann réalisant concrètement une machine capable de réaliser quelques opé- rations de lecture et d’écriture dans un dispositif de stockage d’informations qu’il nomme mémoire. Cette machine lisant quelles opérations elle doit faire à partir de sa mémoire ; Alonzo Church construisant le λ-calcul, un langage élémentaire pour parler des preuves mathématiques ; peuvent tous trois calculer les mêmes résultats ! Les preuves qu’un mathématicien peut écrire, il peut les manipuler mécaniquement. Ce qu’il peut faire mécaniquement en concevant un programme, une machine peut le faire. Voici la révolution qui créa l’informatique théorique : raisonner, c’est eectivement programmer, l’informatique peut nourrir la logique. Avec ces formalismes, il est facile de montrer que ces machines ne peuvent pas tout. Elles ne peuvent par exemple pas prédire dans tous les cas si un algorithme donné s’arrête après un nombre ni d’étapes de calcul. Cette question est plus élémentaire que savoir si deux algorithmes ont les même sorties pour les même entrées. Il n’y a aucune chance de répondre en toute généralité au problème de l’équivalence de programmes. Programmation fonctionnelle avec types algébriques La théorie des types de Martin-Löf généralisée propose sur le versant informatique un langage avec un monde ouvert où l’utilisateur peut introduire de nouvelles structures de données à la condition qu’elles soient correctement formées. Ces données sont ensuite utilisables grâce à des fonctions récursives ou du raisonnement par induction. On parle naturellement de structure de données inductives. 12Types riches Pour l’utilisateur, travailler avec des structures de données qu’il a dénies exactement pour son besoin lui permet d’écrire des programmes suivant son intuition sans se soucier d’encodage. L’étude mathématique justie la correction des programmes typés dans ce formalisme. Ce paradigme de programmation permet d’utiliser de manière sûre et simple les primitives des processeurs. Réaliser un choix est une des opérations élémentaires mises à la disposition du programmeur. Cette action consiste à exécuter une partie ou une autre d’un programme suivant la valeur d’une entrée. De manière primitive dans un processeur, l’opération de branchement conditionnel saute à une instruction plus lointaine en fonction du résultat d’une comparaison d’entiers. Historiquement, les langages impératifs (C, Java, . . .) proposent un opérateur de sélection de cas à partir de cette primitive. La commande switch n inspecte la valeur de l’entier n puis exécute le code situé entre case k: et break; si n = k. Un comportement par défaut, pour les k n’apparaissant pas, est spécié grâce à default:. Si un ordinateur ne manipule que des séquence de bits, ce n’est pas le cas de l’intuition humaine. Il est donc communément possible d’associer un nom à un nombre par #define FLEUR 12 an de clarier les programmes en écrivant switch (plante) { case FLEUR: cueillir; break; default: arroser}. Par contre, il n’existe aucune garantie sur l’exhaustivité ou la cohérence des choix donnés. Le programme switch (animal) { case FLEUR: promener; break; default: carresser} se révélera aberrant à l’exécution mais il est accepté par le logiciel chargé d’en permettre l’exécution : l’interpréteur ou le compilateur. De même, réserver un bloc de mémoire est primitif. L’accès aux champs d’un bloc dans les langages impératifs n’a par contre aucune garantie. Rien n’empèche donc de lire une mauvaise zone de mémoire. Ces problèmes sont pris en charge par les disciplines de typage. Types riches Les systèmes de type qui permettent le plus de contrôle sur les programmes autorisent les types à dépendre de valeurs. Ce gain entraîne deux complications : l’apparition d’annotation de type dans les termes et l’apparition de calculs dans les types (l’impossibilité de ne considérer que l’égalité syntaxique de types). Le modèle où l’utilisateur donne tout d’abord intégralement un programme ou une preuve, puis la machine le/la vérie dans un second temps n’est plus satisfaisant. Des annotations sont fastidieuses à écrire alors qu’il est possible d’écrire une fois pour toutes un programme permettant à l’ordinateur de les deviner. De longs calculs que l’utilisateur ne veut pas faire de tête sont parfois nécessaire pour connaître le type que doit avoir un terme. La machine et son utilisateur doivent interagir an de construire et vérier incrémentalement les termes. Les assistants de preuve sont des logiciels permettant de construire interactivement preuves ou programmes. Ce domaine de recherche prolique a généré de nombreuses tentatives aux objectifs multiples. Prouver des théorèmes avec des programmes simplement typés est par exemple permis par Isabelle [54], HOL-light [27] ou ACL2 [32]. On retrouve également des systèmes où la programmation peut être aussi dépendante que la preuve, par exemple Lego [51], Matita [1] 13Introduction ou Coq. Cayenne [3] puis Epigram [39] et Agda [14] orent par exemple des systèmes tournés en premier lieu vers la programmation. Twelf [49] (ou Dedukti [13]) tentent d’extraire l’universalité des systèmes logiques an de générer d’autres systèmes. Ces systèmes orent à l’utilisateur un langage de surface qui lui évite d’écrire exhaustivement les termes. L’interactivité minimale est une présentation par la machine du type du terme attendu en un point donné. Le choix de la forme à présenter est cruciale pour la compréhension humaine. Utilisation des données inductives Dans la diérentiation du langage de surface et de celui sur laquelle s’appuie la logique, ce manuscrit distingue des concepts qui sont confondus dans la littérature. Nous employerons des mots synonymes dans des sens distincts car notre propos est précisément de montrer les distinctions et les passerelles des uns aux autres. Intuitivement et en anticipant légèrement sur la suite qui dénit plus formellement chacun des termes, nous distinguons : — l’analyse de cas élémentaire, cette réécriture du principe d’élimination d’un inductif qui donne le comportement pour chacun des constructeurs et que l’on peut qualier de ltrage atomique. — le typage de l’analyse de cas, justement par étude de cas, qui assure que pour chacun des constructeurs, une réponse bien typée est apportée. Cette primitive est identique pour tous les éléments d’un type inductif. — le ltrage complexe, qui correspond au ltrage généralisé, celui que l’on retrouve dans les langages fonctionnels. Son exécution nécessite alors une phase de compilation vers une forme plus élémentaire. — et le typage par analyse de couverture, celui qui travaille sur une instance du type inductif spéciquement et permet de typer un ltrage (généralisé) directement. Dans le λ-calcul simplement typé ou paramétrique, les deux typages sont équivalents car tous les constructeurs ont le même type. Il n’y a donc pas réellement besoin de s’attarder sur la version élémentaire de l’opération qui n’est qu’un point de passage au cours de la compilation. Avec des types dépendants, la confusion a perduré alors que le ltrage (l’opération non atomique) n’est pas typable directement dans un système comme le notre qui n’a à disposition qu’un principe d’élimination générique. Qui plus est, l’opération complexe considérée primitive apporte avec elle un axiome supplémentaire (voir 1.7). Ce manuscrit parlera donc d’analyse de cas (élémentaire) et de ltrage (généralisé) en omettant les qualicatifs. Sa première contribution originale est de proposer une nouvelle compilation du second dans le premier. Cette première partie du manuscrit est décomposée en trois chapitres. Dans un premier temps, l’algorithme pour atomiser un ltrage complexe sans considération de typage est rappelé. Dans un deuxième temps, le système de typage direct du ltrage complexe tel qu’imaginé par Coquand est décrit. Nous présenterons le plongement que McBride a proposé dans les CCI en utilisant un axiome supplémentaire. Le chapitre 4 de ce manuscrit décrit une com- 14Réduction des points xes pilation d’un sous-ensemble signicatif des ltrages dans le CCI pur. C’est la continuité du travail réalisé par Herbelin et Cornes [18]. Réduction des points fixes Au lieu de dénir les récurseurs des types inductifs primitivement, un mécanisme géné- rique de point xe est proposé. Bien sûr, il faut s’assurer que les points xes ne peuvent pas produire de calculs innis. Avec un véricateur de terminaison, cette formulation est équivalente aux principes de récurrence [23]. Ces points xes sont dénissables par le biais de constantes globales autorisées à s’appeler elles-mêmes ou par des constructions locales aux systèmes. La seconde contribution originale de ce manuscrit est de simuler au niveau de l’utilisateur le premier système dans le second. La description de se mécanisme constitue le chapitre 5. Le véricateur de terminaison doit pouvoir interagir au mieux avec la volonté de l’utilisateur. Par exemple, il doit permettre la réutilisation de code. Il doit aussi ne pas être perturbé par les constructions dont le système a besoin pour assurer le typage du terme. La troisième contribution originale de ce manuscrit est un algorithme présenté chapitre 6 qui va dans ce sens. Il se base sur un critère syntaxique de décroissance structurelle. 151 Un langage fonctionnel avec types riches Le langage formel utilisé dans ce manuscrit est un λ-calcul à la Church avec des types algébriques et des constantes globales écrit en déduction naturelle. Il va être décrit progressivement dans ce chapitre. 1.1 Conventions d’écriture Des listes sont utilisées tout au long de ce manuscrit. L’écriture adoptée pour représenter la liste de n "x" est x1 · · · xn. Par convention, l’indice s dans x1 · · · xs est utilisé quand le nombre d’éléments n’importe pas. Les déclarations sont notées (x : T) où T est le type de la variable x. Les listes de déclarations (x : X) (y : Y) (z : Z) . . . dans lesquels x apparaît dans Y, x et y apparaissent dans Z, . . . seront intensivement utilisées. Elles sont appelées des télescopes et disposent d’une notation spécique : −−−−−−→ (ai : Ai ) désigne (a1 : A1) · · · (ai : Ai ). Remarque Dans l’assistant de preuve Coq, des dénitions (let z : Z := t in u) peuvent entrecroiser des déclarations au sein des télescopes pour obtenir (x : X) (y : Y) (z : Z := t) . . .. Il est néanmoins toujours possible de remplacer les variables dénies par leur dénition et de traiter des listes de déclarations uniquement. Ceci simplie la présentation. Le langage déni ici se traduit symbole pour symbole en une structure de données utilisables en pratique pour une implantation 1 , mis à part la représentation des variables. Une machine utilise des indices de Bruijn pour avoir une représentation canonique des variables, ce qui évite les problèmes de capture. Ce manuscrit utilise par souci de lisibilité des variables nommées en respectant les conventions usuelles. La convention de Barendregt évite les problèmes de capture en imposant des noms de variable tous distincts et l’α-équivalence identie les termes égaux à renommage des variables liées près. La syntaxe utilisée est une réminiscence de celle des versions 8 de Coq. Lors de dénitions abstraites, les couleurs et les noms tenteront de faciliter la lecture. Il sera par exemple question de termes t, de types T, de constantes globales c et de variables x. 1. Elle est exactement déduite de la structure Constr.t du code de Coq v8.5. 171 Un langage fonctionnel avec types riches 1.2 Le cœur fonctionnel 1.2.1 Syntaxe Le λ-calcul est un modèle de calcul qui permet de manipuler aisément des lieurs. Tous les programmes dans ce modèle sont construits à partir de fonctions. Le mot terme est communément employé pour désigner un de ces programmes. Il existe plusieurs formulations du λ-calcul. Ce manuscrit utilise une variante typée : le λ- calcul à la Church. Le but du typage est ici d’interdire les calculs innis. Certaines annotations de type sont explicites an que le typage reste décidable malgré des types très expressifs. Stefano Berardi et Jan Terlouw ont proposé un cadre très générique pour étudier les systèmes de type : les systèmes de types purs. Ce cadre est une généralisation du λ-cube de Barendregt ([4]) où chaque dimension représente une possibilité de dépendance en plus et chaque sommet un système de type connu. Le système de type utilisé ici est le sommet du λ-cube. Termes et types partagent la même syntaxe an de dépendre les uns des autres. Il a été introduit par Thierry Coquand [16] sous le nom de calcul des constructions. Sa syntaxe est donnée gure 1.1 u, t, S, T : := x | λ(x : T) ⇒ t | t u | ∀(x : S), T | Set | Type Figure 1.1 – Grammaire du cœur fonctionnel (CoC) L’abstraction de la variable x de type T dans le terme t s’écrit λ(x : T) ⇒ t. Par souci de concision, λ(x : X) ⇒ λ(y : Y) ⇒ t est noté λ(x : X) (y : Y) ⇒ t et λ(x : X) (y : X) ⇒ t est noté λ(x y : X) ⇒ t. L’application du terme u au terme t est noté t u sans symbole explicite. Elle est conventionnellement associative à gauche. Au niveau des types, le produit jouit des même facilités d’écriture que l’abstraction. Le terme ∀(x y : S) (z : T), s désigne ∀(x : S), ∀(y : S), ∀(z : T), s. Deux constantes, les sortes Set et Type sont aussi données. Le caractère _ est utilisé pour désigner une variable liée qui n’apparaît pas dans le corps du lieur. Ainsi dans le cas d’une abstraction sur une variable non utilisée, on écrit λ(_ : T) ⇒ t. Dans le cas du produit, A → B est une notation pour ∀(_ : A), B. 1.2.2 Evaluation Le calcul intervient lorsqu’un argument est appliqué à une abstraction. Une telle situation est appelée un rédex. Le terme se réduit alors vers le corps de la fonction dans lequel l’argument remplace la variable de l’abstraction. Cette opération s’appelle une β-contraction et se note formellement (λ(x : T) ⇒ t) u 7→β t[u/x] La notation t[u/x] désigne la substitution de la variable x par le terme u dans le terme t. 181.3 Déclarations globales La clôture par congruence 2 , réexivité et transitivité de cette réécriture est appelée réduction. Dans la suite, 7→β ferra référence à la réduction. Deux termes t et t’ sont convertibles (noté t ≡ t’) s’ils se réduisent sur un même terme : t 7→β v et t’ 7→β v. L’ordre dans lequel sont réalisées les réécritures n’a pas d’incidence sur la convertibilité. La réduction est conuante : quelle que soit la manière dont les réécritures sont réalisées à partir d’un terme, les termes obtenus restent toujours convertibles. En dénissant une réduction parallèle qui réalise la réécriture sur toutes les partie du terme en une seule étape, on obtient une réduction que l’on peut simuler à l’aide des règles dénies au-dessus. Cette réduction parallèle réduit les deux termes issus d’une paire critique sur le même terme en une étape (propriété du diamant). Les stratégies de réduction (discutées chapitre 5) n’auront donc pas d’eet sur l’expressivité. L’autre point important de la réduction est sa terminaison. Une valeur ou forme normale est un terme sur lequel aucune réécriture β n’est applicable sur aucune partie. Il est indispensable que tous les termes du langage se réduisent sur une valeur (unique par conséquence de la conuence). Le typage l’impose. La preuve passe par la construction d’un modèle et a fait en particulier l’objet de travaux par Coquand [16], Werner - Miquel [42], Lee [35], Barras [5], . . . 1.2.3 Typage Le système de type du calcul des constructions est présenté gure 1.2. La sorte s désigne indiéremment Set ou Type. Il est décrit sous la forme de jugements qui donne le type d’un terme à partir du type des variables apparaissant dans ce terme. Le type des variables est stocké dans un environnement (conventionnement nommé Γ) qui est soit vide (∅) soit composé de la déclaration de la variable x de type T suivi du sous contexte Γ (Γ, (x : T)). 1.3 Déclarations globales 1.3.1 Syntaxe L’utilisateur n’écrit pas un terme monolithique mais une succession de dénitions globales notées (c : T := t) qui forment un environnement ∆. Par réminiscence de la syntaxe de Coq, la syntaxe pour dénir la constante c dans les exemples de ce manuscrit est Definition c : T := t. Il est aussi possible de déclarer des axiomes. Ce sont des constantes sans valeur notée (x : T). Pour éviter les répétitions, Definition c : ∀(x : S), T := λ(x : S) ⇒ t. peut être écrit Definition c (x : S) : T := t. 2. Par congruence, nous entendons les règles de la forme t 7→β t’ et T 7→β T’ implique λ(x : T) ⇒ t 7→β λ(x : T’) ⇒ t’. 191 Un langage fonctionnel avec types riches Γ ⊢ t ∈ T Γ, (x : T) ⊢ x ∈ T Γ ⊢ S ∈ s Γ ⊢ y ∈ T Γ, (x : S) ⊢ y ∈ T Γ, (x : S) ⊢ t ∈ T Γ ⊢ ∀(x : S), T ∈ s Γ ⊢ λ(x : S) ⇒ t ∈ ∀(x : S), T Γ ⊢ Set ∈ Type Γ ⊢ t ∈ ∀(x : S),T Γ ⊢ u ∈ S T[u/x] ≡ T’ Γ ⊢ T’ ∈ s Γ ⊢ t u ∈ T’ Γ ⊢ S ∈ Set Γ, (x : S) ⊢ T ∈ Set Γ ⊢ ∀(x : S), T ∈ Set Γ ⊢ S ∈ s Γ, (x : S) ⊢ T ∈ Type Γ ⊢ ∀(x : S), T ∈ Type Figure 1.2 – Typage du calcul des constructions Les termes peuvent faire référence à des constantes globales précédemment dénies. Une constante est un constructeur de terme (gure 1.3). u, t, S, T : := x | λ(x : T) ⇒ t | t u | ∀(x : S), T | Set | Type | c Figure 1.3 – Grammaire de CoC avec dénition 1.3.2 Evaluation Au cours d’un calcul, une constante est remplacée par le corps de sa dénition donnée par l’environnement global (communément appelé ∆). Cette opération est appelée δ-expansion et se note : ∆, (c : T := t), ∆’ ⊢ c 7→δ t La réduction intègre maintenant cette règle de réécriture et est notée ∆ ⊢ 7→βδ . La conuence reste valable. La réduction parallèle conserve la propriété du diamant. Le dépliage de constante n’a pas d’incidence sur la terminaison. 1.3.3 Typage Le jugement de typage est maintenant paramétré par l’environnement des constantes dé- nies. Le type d’une constante est donné par cet environnement. ∆, (c : T := t), ∆’ ;Γ ⊢ c ∈ T ∆, (c : T), ∆’ ;Γ ⊢ c ∈ T 201.4 Types de données algébriques strictement positifs . L’environnement global doit être bien formé, c’est-à-dire vide ou obtenu par ajout de constantes aux noms frais et bien typées. ∆ ⊣ ∅ ⊣ ∆ ⊣ ∆ ;∅ ⊢ T ∈ s ∆ ;∅ ⊢ t ∈ T c < ∆ ∆, (c : T := t) ⊣ ∆ ⊣ ∆ ;∅ ⊢ T ∈ s c < ∆ ∆, (c : T) ⊣ Figure 1.4 – Environnements bien formés 1.4 Types de données algébriques strictement positifs 1.4.1 Syntaxe Le langage considéré jusqu’à maintenant permet de dénir des structures de données par codage imprédicatif. Néanmoins, comme suggéré dans l’introduction, manipuler des données de manière primitive est plus naturel. Les constructions utilisées pour rendre cela possible sont les structures inductives. L’ajout des types inductifs primitifs décrit ci dessous donne le Calcul des Constructions Inductives dû à Christine Paulin et Thierry Coquand [17]. Les structures de données sont dénies uniquement au sein de l’environnement global. La syntaxe des contextes globaux est enrichie de l’entrée     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     . Les exemples du manuscrit ainsi que la syntaxe de Coq v8 utilisent une syntaxe diérente plus lisible où le bloc ci-dessus est écrit Inductive I −−−−−−−−→ (am : Am): T := |(C1 : T1) · · · |(Ci : Ti ). La gure 1.5 montre une déclarations d’inductifs écrite en forme normale an d’introduire la terminologie employée pour les manipuler. Inductive I −−−−−−−−→ (am : Am) : ∀ −−−−−−−→ (bn : Bn), Set := | C1 : ∀ −−−−−−−−→ (x1s : T1s ), I a1 · · · am t11 · · · t1n · · · | Ci : ∀ −−−−−−−→ (xis : Tis ), I a1 · · · am ti1 · · · tin. Figure 1.5 – Squelette d’un inductif du CCI C1 · · · Cs sont les constructeurs du type inductif I. 211 Un langage fonctionnel avec types riches a1 · · · am sont les paramètres de l’inductif. b1 · · · bn forment la signature d’index de l’inductif. x1 · · · xs sont les arguments du constructeur C. t1 · · · tn sont les index du constructeur C. Par construction, — Le type des constructeurs doit être en forme constructeur par rapport à I. La syntaxe des forme constructeur par rapport à X est Co : := X t1 · · · ts | ∀(x : T), Co avec T = X u1 · · · us ou X n’apparaît dans T et X n’apparaît pas dans les termes t et u1 · · · us . L’occurrence nale de X est la conclusion du type du constructeur. — Les paramètres sont des constantes d’une dénition. Il doivent rester identiques dans la conclusion du type des constructeurs et dans la dénition de l’inductif. Un exemple d’inductif est la dénition de l’égalité donnée gure 1.6. Inductive eq (A : Set) (a : A) : A → Set := | eq_re :eq A a a. Lorsque l’on écrit eq T t u, la valeur du type T est imposée par les termes t et u. Par consé- quent, lorsque le type T n’est pas le point clé de l’explication, eq T t u est noté par la suite t = u. Figure 1.6 – Dénition de l’égalité Une fois dénis, inductifs et constructeurs sont utilisables dans les termes comme des constantes. Les constructeurs ont un statut particulier. Deux constructeurs sont prouvablement distincts et l’ensemble des habitants d’un type inductif est statiquement connu par l’environnement global. Grâce à cela, Christine Paulin a déni une règle d’élimination des données par analyse de cas. La syntaxe employée est donnée gure 1.7. case t predicate P of | br1 · · · | bri end Figure 1.7 – Analyse par cas sur t de type I u1 · · · um v1 · · · vn Le terme t inspecté par l’analyse de cas est appelé terme inspecté. L’annotation de typage P est appelée clause de retour ou prédicat de retour. Le terme brj appelé branche du constructeur Cj correspond au comportement du programme si le terme inspecté débute par le j-ième constructeur. An de fournir des noms pour représenter les arguments du constructeurs, une branche débute par autant d’abstractions que le constructeur lui correspondant a d’arguments. Le langage Gallina fournit une primitive plus haut niveau qui sera l’objet d’étude des chapitres suivants. Néanmoins, l’analyse de cas écrite en forme dite η-longue (où il y a un λ pour toutes les abstractions) s’injecte dans la syntaxe de Gallina en écrivant Terme de Constr.t case t predicate λ −−−−−−−→ (bn : B’n) (x : I u1 · · · um b1 · · · bn) ⇒ T of |λ −−−−−−−−−→ (x1s : T’1s ) ⇒ br1 · · · |λ −−−−−−−−→ (xis : T’is ) ⇒ bri end où T’jk := Tjk [u1 · · · um/a1 · · · am] et B’k := Bk [u1 · · · um/a1 · · · am] 221.4 Types de données algébriques strictement positifs Terme de Gallina match t as x in I b1 · · · bn return T with | C1 x11 · · · x1s => br1 · · · | Ci xi1 · · · xis => bri end L’analyse de cas n’est pas susante pour dénir des fonctions par analyse de cas récursives. Une notion de point xe est nécessaire. La syntaxe employée est fixi (f : T := t) où f est une variable libre dans t. L’indice i est appelé l’argument récursif du point xe. Il désigne le numéro de l’argument à inspecter pour savoir s’il faut déplier le point xe (comme expliqué section suivante). Fixpoint f (x_1 : S_1) · · · (x_i : S_i) : T := t. est un alias plus concis pour Definition f : ∀(x_1 : S_1) · · · (x_i : S_i), T := fixi (f : ∀(x_1 : S_1) · · · (x_i : S_i), T := λ(x_1 : S_1) · · · (x_i : S_i) ⇒t). En résumé, la grammaire exhaustive des termes est écrite gure 1.8. Elle est nommée minicalcul des constructions inductives car le calcul des constructions inductives à proprement parler inclus par exemple une hiérarchie innie de sortes avec sous-typage ou des structures de données coinductives qui sont hors du champ de l’étude réalisée dans ce manuscrit. u, t, S, T : := x | c | ∀(x : S), T | s | λ(x : T) ⇒ t | t u | C | I | case t predicate P of t1 · · · ts end | fixi (f : T := t) Figure 1.8 – Grammaire des termes utilisés (mini-CCI) 1.4.2 Evaluation Une analyse de cas dont le terme inspecté est le constructeur Cj appliqué à des arguments u1 · · · us se réduit vers la branche de Cj appliquée aux termes u1 · · · us . C’est la ι-contraction. ∆ ⊢ case Ci u1 · · · un predicate T of |t1 · · · |tm end 7→ι ti u1 · · · un La dernière règle est la ϕ-expansion. Un point xe se déplie si son argument récursif commence par un constructeur. Ce conditionnement du dépliage à la forme de l’un des arguments est indispensable. Remplacer systématique la variable représentant le point xe par le corps du point xe amène des dépliages innis lorsque la règle est appliquée sur des sous-termes ayant des variables libres. ∆ ⊢ (fixi (f : T := t)) u1 · · · ui-1 (C v1 · · · vn) 7→ϕ t[fixi (f : T := t)/f] u1 · · · ui-1 (C v1 · · · vn) La réduction enrichie de ces deux règles est notée ∆ ⊢ 7→βιϕδ . Sa conuence est toujours prouvable grâce à une réduction parallèle vériant la propriété du diamant. La terminaison demande la construction de nouveaux modèles qui furent par exemple l’objet du travail de Coquand - Paulin [46], Luo [37], Barras [6], . . . 231 Un langage fonctionnel avec types riches 1.4.3 Typage Un type algébrique I est un inductif si les occurrences de I dans les télescopes des arguments des constructeurs sont en positions strictement positives. Elles ne doivent jamais apparaître à gauche d’un produit dans un type. Pour le reste, on étend la règle de bonne formation des environnements globaux (gure 1.4) par la déclaration d’un type inductif : ∆ ⊣ ∆ ;∅ ⊢ ∀ −−−−−−−−→ (am : Am), T ∈ Type ∆ ;(I : ∀ −−−−−−−−→ (am : Am), T), ∅ ⊢ ∀ −−−−−−−−→ (am : Am), T1 ∈ Set · · · ∆ ;(I : ∀ −−−−−−−−→ (am : Am), T), ∅ ⊢ ∀ −−−−−−−−→ (am : Am), Ti ∈ Set ∆,     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     ⊣ Dans notre restriction mini-CCI, le type de l’inductif (Type) et de ses constructeurs (Set) sont xes alors qu’en Coq ils pourraient varier. L’extension du typage des termes est donné gure 1.9. Une fois un inductif déclaré dans l’environnement global, son type et le type de ses constructeurs sont directement donnés par cet environnement. Une analyse de cas est une écriture particulière du schéma d’élimination d’un inductif. ( Ce schéma correspond à l’encodage imprédicatif d’un inductif [47]). Lors d’une élimination dépendante, chaque branche attend un type diérent. Puisque les types dépendent des termes, le type d’une branche dépend du constructeur auquel il correspond. Le type global de la réponse renvoyée par l’analyse de cas est lui fonction du terme inspecté. Le typage d’un point xe n’est pas surprenant. L’originalité de la règle présentée est la condition Decr(∆,t,f,i). Il correspond à une condition de bonne formation appelée condition de garde qui interdit les points xes divergents. Son étude précise est l’objet du chapitre 6. Son principe général est de garantir que "le nombre de constructeurs en tête de l’argument récursif" est une grandeur strictement décroissante. Cette propriété garantit que seul un nombre ni d’appels récursifs peut avoir lieu si l’argument est un terme clos. 1.5 Des structures de données d’exemple Ce manuscrit réalise pour chaque partie une présentation incrémentale informelle des problématiques avant d’exposer la réponse formelle apportée. En plus des structures de données ayant des rôles très particuliers en théorie des types comme l’égalité déjà présentée gure 1.6, ces descriptions pédagogiques s’appuient sur des structures de données courantes. En premier lieu vient la représentation unaire des entiers naturels (gure 1.10) qui fournit une structure de donnée récursive élémentaire. 241.5 Des structures de données d’exemple ∆ ;Γ ⊢ t ∈ T ∆,     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     , ∆ ′ ;Γ ⊢ I ∈ ∀ −−−−−−−−→ (am : Am), T ∆,     (C1 : T1) · · · (Ci : Ti ) @ −−−−−−−−→ (am : Am) → I : T     , ∆ ′ ;Γ ⊢ Cj ∈ ∀ −−−−−−−−→ (am : Am), Tj ∆ ;Γ ⊢ z ∈ I u1 · · · um v1 · · · vn ∆ := ∆ ′ ,     (C1 : ∀ −−−−−−−→ (x1 : T1), I a1 · · · am t11 · · · t1n ) · · · (Ci : ∀ −−−−−−→ (xi : Ti ), I a1 · · · am ti1 · · · tin) @ −−−−−−−−→ (am : Am) → I : ∀ −−−−−−−→ (bn : Bn), Set     , ∆ ′′ B ′ k := Bk [u1 · · · um/a1 · · · am] T ′ jk := Tjk [u1 · · · um/a1 · · · am] ∆ ;Γ ⊢ P ∈ ∀ −−−−−−−→ (bn : B ′ n) (x : I u1 · · · um b1 · · · bn), s ∆ ;Γ ⊢ brk ∈ ∀ −−−−−−−→ (xk : T ′ k ), P tk 1 · · · tkn (Ck u1 · · · um xk1 · · · xks ) ∆ ;Γ ⊢ case z predicate P of | br1 · · · | bri end ∈ P v1 · · · vn z ∆ ;Γ ⊢ T ∈ s ∆ ;Γ, (f : T) ⊢ t ∈ T Decr(∆,t,f,i) ∆ ;Γ ⊢ fixi (f : T := t) ∈ T Figure 1.9 – Typage des inductifs du mini-calcul des constructions inductives 251 Un langage fonctionnel avec types riches Inductive nat : Set := | O :nat | S :nat → nat. Figure 1.10 – Les entiers naturels unaires (zéro ou le successeur d’un entier) Les listes simplement chaînées (gure 1.11) prennent un paramètre de type qui indique la nature des éléments qu’elles contiennent. Néanmoins, tous les constructeurs ont le même type. Si t est une liste d’entier, t peut aussi bien être nil que cons a b. Les deux constructeurs créent des listes d’entiers. Nous insistons ici car cette propriété n’est pas vrai pour les familles inductive ayant un index. Inductive list (A : Set) : Set := | nil :list A | cons :∀(t : A) (q : list A), list A. Figure 1.11 – Type avec paramètre : Les listes simplement chaînées Le prédicat de parité d’un entier naturel (gure 1.12) fournit une structure de données avec un index donc réellement dépendant. Il sera l’exemple canonique pour faire apparaître des branches impossibles. Inductive even : nat → Set := | even_O :even O | even_SS :∀(n : nat) (_ : even n), even (S (S n)). Figure 1.12 – Prédicat de parité sur les entiers Des structures plus compliquées ou ad hoc serviront ponctuellement par la suite. 1.6 Digression sur la représentation des constructeurs et des branches Des abstractions sont utilisées pour représenter les arguments du constructeur dans les branches d’une analyse de cas. Les constructeurs sont vus comme des constantes dont le type est fonctionnel. Ceci n’est pas conventionnel en programmation. Les langages qui ont le soucis de s’exécuter vite voient un constructeur comme un bloc et ces arguments comme des champs de ce bloc. L’analyse de cas n’introduit qu’une variable : celle qui représente le terme inspecté. Par contre, les branches disposent d’une primitive supplémentaire field i t qui donne le ième champs de t (à supposer qu’il s’agisse bien d’un bloc). La première solution simplie l’étude théorique et en particulier l’écriture de la règle de typage, tandis que l’intérêt intrinsèque de la seconde solution est le partage de code. Par exemple, si un utilisateur dénit la structure de donnée Inductive I : Set := | A :I → I | B :I | C :nat → I. puis écrit (en anticipant très légèrement la syntaxe présentée chapitre 2) 261.7 Expressivité de l’analyse de cas Definition destA (x : I) : I := match x with | A y => y | _ => x end. Les branches de B et de C devraient être identiques et donc pouvoir pointer vers le même code. En se souvenant que la machine utilise des indices de de Bruijn pour représenter les variables, c’est eectivement le cas avec λI . case 1 predicate λI . I of | field 1 1 | 1 | 1 end mais pas dans le formalisme du calcul des constructions inductives qui donne λI . case 1 predicate λI . I of | λI . 1 | 1 | λnat. 2 end Il est par ailleurs notable qu’une primitive de projection allégerait aussi les termes issus de l’utilisation d’inductifs à un seul constructeur. Il est bien sûr possible de dénir les projections de tels objets (par exemple proj1 nat even x). Néanmoins, la projection dénie comme une constante prend en argument les arguments de l’inductif (dans l’exemple nat et even alors qu’une projection primitive (ici field 1 x) n’en a pas besoin. Elle peut être typée directement au moyen de la dénition de l’inductif au sein de l’environnement global. 1.7 Expressivité de l’analyse de cas La clause de retour est explicite, elle peut donc être arbitrairement complexe. Elle est la clé de la grande expressivité de l’élimination dépendante. Une clause de retour débute par des abstractions représentant des généralisations des index du terme éliminé ainsi que le terme éliminé. Par exemple, supposons avoir un inductif K qui a un argument et au moins un constructeur H de type ∀(z : S), K z, la clause de retour pour un terme inspecté u de type K t a la forme λ(x : S) (y : K x) ⇒ T. Rien n’oblige le type attendu en retour à utiliser ces abstractions. Dans l’exemple, cela donnerait λ(x : S) (y : K x) ⇒ P avec t et u apparaissant dans P mais ni x ni y. Néanmoins, le type demandé dans chacune des branches est alors constant (exactement P) et décorrelé des index du constructeur de la branche (z dans le cas de H). On ne peut plus raner le type grâce aux informations fournies par le constructeur. De plus, les arguments du constructeur sont le plus souvent inutilisables car de types incompatibles. Dans le cas de la branche de H, le type attendu est ∀(z : S), (λ(x : S) (y : K x) ⇒ P) z (H z). Puisque x et y ne sont pas libres dans P, ce type ce réduit à ∀(z : S), P où z n’est pas libre dans P. Il est donc peu crédible de pouvoir utiliser z pour fournir du P. Pour rendre l’élimination utile, la clause de retour doit utiliser au maximum ces généralisations. Des contraintes de typage que nous allons expliciter limitent cette possibilité. Le type des abstractions découle uniquement de la dénition de l’inductif et non pas du type, plus précis, du terme éliminé. Or, généraliser les termes signie nécessairement géné- raliser parallèlement les types. Il existe alors des situations où il est impossible d’écrire un terme de type T k par analyse sur (k : K v) car il n’est pas possible de trouver (P : ∀(a : A) (b : K a), Set) tel que P v k ≡ T k. Au lieu d’une quantication universelle sur A, il serait souhaitable de pouvoir exprimer une propriété existentielle disant a doit être v. Comme si une analyse de cas dépendante demandait de pouvoir écrire en ce qui concerne des types des motifs où des égalités de variables sont exprimables. La section 3.2 revient sur cette considération. 271 Un langage fonctionnel avec types riches Une perte d’expressivité découle de cette contrainte. L’égalité de deux termes peut être exprimée comme un type de donnée du langage au moyen de la dénition gure 1.6. Elle est ainsi manipulable directement au sein du langage. Il est cependant impossible de dénir un terme ayant le type de la gure 1.13 par analyse sur e. La clause de retour qu’il faudrait : ∀(b : A) (e’ : eq A a b), eq (eq A a b) e’ (eq_re A a) est mal typée car eq_re A a a le type eq A a a et non pas eq A a b (le type de e’). Axiom UIP_re : ∀(A : Set) (a : A) (e : eq A a a), eq (eq A a a) e eq_re. Figure 1.13 – Unicité des preuves d’égalité Cet exemple n’est pas articiel et limite la programmation dépendante. Dans [28], Thomas Streicher et Martin Hofmann ont nommé K une formulation équivalente (gure 1.14) de cet axiome. Ils ont montré que K est indépendant du CCI. Il est en eet admissible mais il existe des modèles qui ne le réalisent pas. Axiom StreitherK (U : Set) : ∀(x : U) (P : x = x → Prop), P (eq_re x) → ∀(p : x = x), P p. Figure 1.14 – Axiome K Puisqu’il est compatible avec le calcul des constructions inductives, K peut être supposé. Un axiome étant une hypothèse globale qui n’a pas de dénition, il n’a jamais la possibilité de se réduire. Calculatoirement, un tel axiome est donc extrêmement préjudiciable à moins d’amener avec lui une forme faible d’irrelevance des preuves. En eet, la réduction peut être modiée pour ignorer la preuve d’égalité t = u qui bloque une réécriture. Si u et tsont convertibles, la réécriture est eacée. De plus, la section 3.2 montre que K est supposé lorsque l’élimination des inductifs est vu comme une couverture de tous les cas possibles. Il a longtemps été considéré comme regrettable qu’introduire K de manière externe au CCI bloque toutes les réductions de termes. Une règle d’élimination par cas des inductifs vériant K a donc été proposée dans [7]. L’apparition de la théorie homotopique des types [52] dans lesquels K n’est pas valable mais qui présente d’autres intérêts tempère ce point de vue et justie le travail présenté chapitre 4. 282 Le filtrage en programmation fonctionnelle Dans ce manuscrit, nous cherchons à exhiber que la présence de types dépendant rend profondément diérents l’analyse de cas élémentaire telle qu’elle est dénie dans le CCI et le ltrage généralisé tel qu’il apparaît dans les langages fonctionnels depuis HOPE (le premier langage avec des types algébriques). L’amalgame entre les deux notions est entretenu car Coq ore à l’utilisateur une primitive de ltrage généralisé. En réalité, ce ltrage est compilé par le système et cette première partie explique ce procédé de compilation. Dans les langages avec types algébriques paramétriques (comme par exemple Haskell, OCaml ou SML), il n’y pas besoin d’isoler l’analyse de cas élémentaire du point de vue du typage. Il est néanmoins nécessaire dans le processus de compilation vers un langage machine d’atomiser les tests. Ce travail a été décrit une première fois par Augustsson [2] puis étudié et optimisé de diérentes manières, par exemple, par Le Fessant, Maranget[34], Wadler[30, Chapitre 5]. Ce chapitre décrit ces travaux, vu que la structure intermédiaire qu’ils introduisent pour leur compilation est la structure intermédiaire que nous utilisons pour la nôtre. La compilation proposée par la littérature est optimisante. Des heuristiques permettent de réduire le nombre d’analyse des cas à réaliser pour simuler un ltrage. Ce manuscrit ne discute pas d’optimisation et se contente de décrire la compilation naïve. Néanmoins, il dénit la construction optimisante de la structure intermédiaire car il peut ainsi proter gratuitement du travail sur les optimisations fait dans la littérature. ltrage arbre de décision sauts conditionnels analyses de cas + encodage par égalités Chap 3 analyses de cas + encodage structurel Chap 4 Chap 2 Figure 2.1 – Plan de la première partie du manuscrit Les chapitres suivants expliquent les constructions nécessaire pour aller de la structure intermédiaire qui décrit les choix élémentaires à des analyses de cas du CCI bien typées. 292 Le ltrage en programmation fonctionnelle Ces chapitres sont successivement la description de la littérature et l’algorithme original que propose ce manuscrit. Ces chapitres s’occupent seulement de problèmes de types, mais ne reviendront plus sur l’atomisation qui est l’objet de l’étude qui suit. 2.1 Principe du filtrage Le ltrage (généralisé) n’analyse pas un seul terme mais une liste de termes en parallèle. Pour choisir le comportement à adopter, il peut inspecter les arguments d’un constructeur puis les arguments d’un constructeur argument d’un constructeur et ainsi de suite. Il n’est pas limité à discriminer selon le premier constructeur en tête du terme. Le ltrage permet de factoriser le comportement à adopter quand il est identique dans plusieurs cas, il permet par exemple d’écrire un cas par défaut. Enn, le ltrage permet de nommer des morceaux des termes inspectés an de s’en resservir pour décrire le comportement que la suite du calcul doit avoir. Fixpoint beq_half (m n : nat) : bool := match m, n with | O, O => true | S (S i), S j => beq_half i j | _ , _ => false end. Figure 2.2 – Exemple d’inspection en parallèle et en profondeur : n est il la moitié de m ? Un ltrage est constitué de la liste des termes à inspecter que nous appellerons les termes ltrés et d’une énumération de possibilités qui sont communément appelées les branches. Une branche de ltrage n’est pas composée que d’un terme comme l’est une branche d’analyse de cas. Une branche de ltrage est une paire d’un membre gauche composé d’une liste de motifs et d’un membre droit qui est un terme. Chaque branche a autant de motifs que le ltrage a de termes ltrés. La syntaxe des motifs (gure 2.3) permet d’établir une empreinte pour la tête d’un terme. Si un terme respecte la forme de cette empreinte, il coïncide avec le motif. La sémantique du ltrage est d’exécuter le membre droit de la première branche pour laquelle les membres gauches coïncident avec les termes inspectés en ayant eectué les substitutions nécessaires. Formellement, la sémantique est déni grâce à — Une opération ◦ de composition de « peut être substitution ». L’absence de substitution (⊥) est un élément absorbant. — une opération de substitution généralisée [p ← t] décrite gure 2.4 qui prend en argument un motif p et un terme t et renvoie peut être une substitution ; celle à appliquer si le terme coïncide avec le motif. — une opération ⊕ qui sélectionne le premier succès d’une liste de « peut être ». Elle s’écrit alors match t1 · · · tn with |p11 · · · p1n → u1 · · · |ps1 · · · psn → us end 7→ ⊕i (◦j[pij ← tj])ui . 302.1 Principe du ltrage Exemple Le terme cons O (cons (S (S O)) nil) coïncide avec le motif cons _ (cons (S _)) _ mais pas cons (S (S O)) nil ou cons (S O) (cons O nil) p : := C p1 · · · ps | _ | ( p1 | p2 ) | ( p as x ) Figure 2.3 – Syntaxe des motifs Le motif "_" est appelé joker, n’importe quel terme coïncide avec lui. Un terme coïncide avec le motif C p1 · · · ps si, une fois réduit, il est le constructeur C appliqué à des arguments coïncidant avec les motifs p1 · · · ps . Un terme coïncide avec ( p1 | p2 ) s’il coïncide avec p1 ou avec p2. Enn, un alias ( p as x ) est un lieur. Il associe le nom x au sous-terme coïncidant avec le motif p. Le motif ( _ as x ) est noté par simplicité x. [p ← t] [( p as x ) ← t] def = [t/x] ◦ [p ← t] [_ ← t] def = ∅ [( p | q ) ← t] def = [p ← t] ⊕ [q ← t] [Ci p1 · · · ps ← Ci t1 · · · ts] def = ◦k [pk ← tk ] [Ci p1 · · · ps ← Cj t1 · · · ts] def = ⊥ Figure 2.4 – Substitution généralisée pour un motif Il est notable que les motifs ne peuvent parler que de constructeurs et non pas de n’importe quelle déclaration de l’environnement global. L’avantage de ne traiter que des données à la structure statiquement dénie est de connaître l’espace inspecté. Il est par conséquent possible de vérier la bonne formation des ltrages en contrôlant l’exhaustivité et la non redondance des motifs. Il existe une autre forme de ltrage, non déterministe cette fois, en programmation logique. La problématique est alors diérente et les motifs sont moins contraints. Une branche de ltrage en programmation logique utilise des variables existentielles : "S’ il existe x tel que p(x) = t, exécute u" alors que les variables des motifs de la programmation fonctionnelle sont universelles : "pour tout x tel que p(x) = t, exécute u". Les motifs en programmation logique peuvent être non linéaires : une variable peut apparaître plusieurs fois, signiant que plusieurs parties d’un terme inspecté doivent être identiques. Il n’est alors plus question de savoir si un terme coïncide avec un motif mais de dé- terminer les classes d’équivalence auxquelles appartiennent les variables des motifs au sein des termes. Ce calcul est coûteux. Il repose sur un algorithme d’unication. Ce besoin de propriété existentielle au sein du typage de l’élimination dépendante des données a été exhibée section 1.7. C’est pourquoi cette autre forme de ltrage va apparaître section 3.2. Elle est donc mentionnée ici an de bien la diérencier de notre objet d’étude. 312 Le ltrage en programmation fonctionnelle 2.2 Reconnaitre un motif Au niveau du processeur, l’unique primitive qui permet le branchement est le saut conditionnel. Reconnaître un constructeur modélisé par un entier ne demande qu’une instruction de comparaison. L’analyse de cas se traduit aisément en sauts conditionnels. Reconnaître un motif n’est pas aussi immédiat. Pour exécuter un ltrage, la coïncidence avec un motif doit être décomposée en la vérication d’une succession de contraintes élé- mentaires. Un protocole doit donc être établi an de compiler le ltrage. Cette étape de compilation n’est pas nécessaire uniquement à l’exécution mais sert aussi aux contrôles de bonne formation du ltrage. Avec des types de données paramétriques, tous les motifs et toutes les branches ont le même type. Cette partie du typage est réalisable avant compilation. Par contre, contrôler la bonne formation des motifs consiste aussi à s’assurer que tous les cas possibles ont été traité et qu’il n’y a pas de redondance et donc de branches jamais exécutée. Cela revient à exhiber la complétude et la non surcharge de l’arbre des choix à réaliser pour déterminer la branche à suivre, c’est-à-dire travailler exactement sur la structure intermédiaire de la compilation du ltrage. La littérature propose deux langages intermédiaires pour la compilation : les automates bracktrackant [2, 34] et les arbres de décision [38]. Tous deux utilisent l’analyse de cas comme primitive mais le premier langage maximise la concision du code produit en reposant sur l’usage d’un cas par défaut et d’exceptions alors que le second minimise le nombre de comparaison et s’exprime uniquement par une succession d’analyses de cas telle que présentée section 1.4. A titre d’exemple, le résultat de la compilation de beq_half (gure 2.2) vers un automate backtrackant est donné gure 2.5.1 et vers un arbre de décision gure 2.5.2. Précisément, la syntaxe utilisée est celle du langage intermédiaire de la compilation d’OCaml dlambda. catch (case m of |O: case n of |O: true |_: exit 1 end |S: let k := (eld 1 m) in (case k of |S: case n of |S: beq_half (eld 1 k) (eld 1 n) |_: exit 1 end |_: exit 1 end) end with 1: false) (1) par backtraking automata case m of |O: case n of |O: true |S: false end |S: let k := (eld 1 m) in (case k of |O: false |S: case n of |O: false |S: beq_half (eld 1 k) (eld 1 n) end end) end (2) par arbre de décision Figure 2.5 – Compilation de beq_half Comme elle ne requiert pas d’autres primitives que des analyses de cas, la transformation d’un ltrage vers une succession d’analyses de cas au moyen d’un arbre de décision ouvre la porte au ltrage en calcul des constructions inductives. 322.3 Construire un arbre de décision Avec des types dépendants, chaque branche a un type diérent dépendant du cas considéré. Deux approches existent pour le typage du ltrage. — La première est un typage avant compilation grâce à une nouvelle théorie logique. Cette approche est décrite dans la section 3.1. — La seconde est de s’appuyer sur le typage de l’analyse de cas en CCI après compilation du ltrage vers ces derniers. Il faut alors non seulement trouver un arbre de décision mais aussi ajouter les annotations et les constructions nécessaires an de typer les analyses de cas générées. Ceci revient à trouver un algorithme pour créer des clauses de retour et des termes en tête de branche qui applique les coercions de type nécessaires. Le chapitre 3 décrit un algorithme pour encoder le typage primitif du ltrage que propose la section 3.1. Le chapitre 4 montre une manière alternative et inédite de concevoir des annotations qui ne demandent pas d’étendre la théorie. Ces deux chapitres considéreront qu’un arbre de décision non typé a déjà été construit à partir du ltrage à encoder. La n de ce chapitre se concentre justement sur cette étape ne parlant pas de types et donc pas de dépendance : comment transformer un ltrage en un arbre de décision. 2.3 Construire un arbre de décision 2.3.1 Arbre de décision Formellement, un arbre de décision est un terme dans la grammaire donnée en gure 2.6 agissant sur une pile de termes ltrés. p : := Tail (t) | Leafx : : p | Nodex(p1 · · · ps ) | Swapi j1 ··· j s : : p Figure 2.6 – Grammaire des arbres de décisions Tail (t) représente la n d’un arbre de décision. A condition que la pile des termes à ltrer soit bien vide, t est la réponse apportée. Leafx : : p est une feuille, c’est-à-dire que le terme en tête de pile n’est pas inspecté plus profondément et p indique comment se comporter pour la queue de la pile. La variable x est l’alias du terme ltré dépilé. Nodex(p1 · · · ps ) signie que le terme en tête de pile est inspecté et que le ieme p donne le comportement à suivre s’il s’agit du i e constructeur. Des variables correspondant aux arguments du constructeur sont empilées sur les termes à ltrer dans toutes les branches. Le terme ltré inspecté a pour alias x. Swapi j1 ··· js : : p est une opération d’optimisation. Elle extrude en tête le ième élément de la pile an de lui appliquer le traitement dicté par p. Cette opération n’est pas rigoureusement identique en présence de types dépendants ou non. D’une liste de termes ltrés réordonnable à souhait, nous passons à la manipulation de télescopes de termes, c’est- à-dire de liste ordonnée du point de vue du typage (les premiers termes apparaissent 332 Le ltrage en programmation fonctionnelle dans les types des suivants). Donner la priorité à un terme n’est donc pas uniquement retarder le traitement des autres, c’est aussi annuler le traitement des dépendances du terme choisi. La liste j1 · · · js donne les numéros des éléments de la liste à jeter car ils sont déterminés par l’analyse du terme sélectionné. hσ(Tail (t)) | i = σ(t) σ(Leafx : : p) | t, q = {x := t, σ }(p) | q D σ(Nodex(p1 · · · ps )) | Ci t1 · · · tn, qE = {x := Ci t1 · · · tn, σ }(pi ) | t1 · · · tn, q  σ(Swapi j1 ··· js : : p) | t1 · · · ti , q = σ(p) | ti , tk1 · · · tki’, q avec  tk1 · · · tki’ = {t1 · · · ti } - ( tj1 · · · tj s ) Figure 2.7 – Sémantique des arbres de décisions (σ est une substitution qui donne le terme correspondant à chaque alias) 2.3.2 Mécanique d’atomisation La liste des branches (appelée matrice des clauses) est transformée en un arbre de décision à l’aide d’une fonction qui travaille sur les colonnes de la matrice. motifs branches corps Figure 2.8 – Structure d’une matrice de clauses Les colonnes de la matrice peuvent être considérées comme une pile. Le travail est systé- matiquement eectué sur la première. L’algorithme présenté ici traite ce cas minimal. Optimiser la compilation du ltrage, c’est échanger l’ordre des colonnes an de réduire le nombre d’analyse de cas nécessaires en traitant les colonnes clés d’abord. Cela revient à introduire des constructeurs Swapi j1 ··· js : : p dans l’arbre de décision. L’algorithme minimal est le suivant : Quand la matrice n’a plus de colonne de motifs, il doit y avoir exactement une ligne. Moins révèle un ltrage non exhaustif, plus des motifs redondants. La réponse est alors Tail (t) avec t le terme de cette branche restante. Dans les autres cas, les alias de la première colonne sont uniés par α-renommage, soit x le nom de l’alias commun. ( p0 as x0 ) ( p1 as x1 ) ( p2 as x2 ) p0 p1 p2 [x/x0] [x/x1] [x/x2] 342.3 Construire un arbre de décision Ensuite, les disjonctions de la première colonne sont supprimées en dupliquant la ligne avec pour premier motif les deux cas de la disjonction. ( q1 | q2 ) p1 · · · ps t q1 p1 · · · ps q2 p1 · · · ps t t Enn, si tous les éléments de la première colonne sont des jokers, la réponse est Leafx : : p où p est l’arbre de décision correspondant à la matrice privée de sa première colonne. Sinon, il est temps d’analyser réellement le premier terme ltré. L’arbre de décision débute par Nodex(p1 · · · ps ). Pour obtenir la réponse pi au sous problème associé au constructeur Ci , on utilise une opération S qui renvoie la nouvelle matrice regroupant les motifs à traiter si le premier terme ltré commence par Ci . La fonction S Ci va transformer la première colonne de motifs en k nouvelles colonnes, avec k le nombre d’arguments de Ci . Pour cela, elle parcourt les lignes en regardant le motif de tête. — S’il s’agit du même Ci appliqué aux sous motifs m1 · · · mk , elle ajoute à la réponse une ligne constitué des m1 · · · mk concaténés au reste de la ligne. (Ci m1 · · · mk ) m1 · · · mk — Si le premier motif commence par un autre constructeur Cj , la ligne disparaît. (Cj m’1 · · · m’k’) ∅ — Un joker est transformé en k jokers tout en gardant le reste de la ligne. _ _1 · · · _k Cette procédure est décrite par Luc Maranget dans [38]. L’objet de son article est de réduire la taille de l’arbre de décision en permutant des colonnes. Il décrit des heuristiques de choix de la colonne à casser en priorité qui permettent d’égaler les performances de la compilation par automates backtrackant en utilisant des arbres de décisions. Dans un cadre avec types dépendant, l’étude de la correction et de la pertinence des heuristiques reste à traiter, ainsi que la proposition de nouvelles heuristiques spécialisées. 353 Encodage du filtrage dans l’analyse de cas 3.1 Le filtrage dépendant primitif Il existe des systèmes logiques dans lesquels le ltrage est l’élimination primitive des inductifs. Les langages Agda [45] et Beluga [50] sont basés sur un tel ltrage primitif dont le typage est assuré par analyse de couverture suivant les idées de Thierry Coquand dans [44]. Le principe est de garantir que l’ensemble des motifs membres gauche des branches couvrent l’ensemble des valeurs que peuvent prendre les termes ltrés. Le typage du ltrage par analyse de couverture présuppose trois classes de propriétés sur les constructeurs d’inductifs. discrimination Deux constructeurs syntaxiquement distincts sont nécessairement dié- rents. Par exemple, pour les entiers : ∀(P : Set) (n : nat), S n = O → P inversibilité Deux instances d’un constructeur sont identiques si et seulement si leurs arguments sont identiques. Pour les entiers : ∀(m n : nat), S m = S n → m = n acyclicité L’argument d’un constructeur d’inductif ne peut pas être égal au terme entier. Par exemple, pour les entiers naturels, ∀(P : Set) (n : nat), S n = n → P, ce qui est vrai également pour tous les S (S . . . (S n)) = n. Lors du typage d’une branche, la correspondance entre les index des termes ltrés et ceux du motif considéré ainsi qu’entre les termes ltrés et le cas considéré se ramène à un problème d’unication ayant pour règles les énoncés ci-dessus. Si t de type even u est éliminé, dans la branche de even_SS x y de type even (S (S x)), les problèmes d’unication sont u ? = (S (S x)) au niveau des index et t ? = (even_SS x y) pour le terme ltré. L’algorithme cherche une substitution des variables apparaissant dans les contraintes telle que les contraintes soient satisfaites. Les variables des motifs peuvent donc être métamorphosées au besoin en des variables existentielles qu’il faut substituer par un terme pour satisfaire les contraintes de type. — S’il existe une telle substitution, elle est appliquée aux types des variables libres et au type attendu en retour. Elle est aussi appliquée aux variables du motif qui ont été transformées ainsi qu’aux types des variables du motif. Dans l’exemple, le type de y contient x qui pourrait être part de la substitution. — S’il n’existe aucune substitution satisfaisant le problème, la branche est déclarée impossible et est eacée. Les variables du contexte sont ici vues comme des variables existentielles et non universelles. Le type UIP_re, l’axiome indépendant du CIC et équivalent à K déni gure 1.13, est 373 Encodage du ltrage dans l’analyse de cas de ce fait habité par le terme Agda 1 UIP_re : ∀ (A : Set) (a : A) (e : eq A a a) 7→ eq (eq A a a) e (eq_re A a) UIP_re .B .b (eq_re B b) = eq_re (eq B b b) (eq_re B b) Il est valide car il existe la substitution A := B, a := b telle que la branche eq_re soit bien typée. Toutes les éliminations ne peuvent pas être réalisées. Le comportement problématique apparaît quand les arguments du terme ltré sont autre chose que des variables et des constructeurs. Un terme ayant pour type (plus x y) = O ne peut pas être éliminé directement, l’algorithme d’unication ne sait ni inférer une substitution la plus générale telle que x + y ≡ 0 ni décréter qu’il n’y en a aucune et que ce cas est impossible. En eet, l’unication d’ordre supérieur en λ-calcul est indécidable (voir [29]). Cette restriction est nuancée en Agda en travaillant après réduction et en autorisant des termes quelconques mais syntaxiquement égaux après application de la substitution trouvée par ailleurs. Il est par exemple possible d’éliminer un terme de type (even (S (S O))) = (even (plus (S O) (S O))). 3.2 Encodage du filtrage par des analyses de cas Le ltrage est une manière concise et facile à relire de présenter des programmes. Cette concision est encore plus vraie avec des types dépendants quand les branches impossibles peuvent être omises. L’exemple systématique pour illustrer ce fait est de pouvoir écrire even_map2 : ∀ (n : nat) 7→ even n 7→ even n 7→ _ even_map2 .O even_O even_O = ? even_map2 .(S (S m)) (even_SS .m e1) (even_SS m e2) = ? sans rien dire des cas mixtes even_O/even_SS impossibles par typage. Il est donc souhaitable d’orir à l’utilisateur cette syntaxe de surface même si la logique sous-jacente ne traite que d’analyse de cas élémentaire. Conor McBride et James McKinna ont démontré dans [24] que l’expressivité de l’analyse par cas était celle du ltrage par analyse de couverture si l’on suppose l’axiome UIP de la - gure 1.13. La démonstration revient à construire une clause de retour et un entête de branche après avoir obtenu l’arbre de décision pour tous les ltrages typables par analyse de couverture [40]. Cristina Cornes [19] puis Matthieu Sozeau [53] ont mécanisé pour Coq la génération de telles clauses de retour et preuves en tête de branche. L’utilisateur dispose de la commande "Program" pour écrire des termes et des tactiques case_eq, inversion et dependent_destruction par échelle croissante d’automatisation dans les preuves. Sur des exemples fortement dépendants, ces techniques sont puissantes mais sourent des limitations de l’axiome K décrites section 1.7. 1. En Agda, .t signie justement que les contraintes de typage imposent de substituer cette variable de motif par le terme t. 383.2 Encodage du ltrage par des analyses de cas 3.2.1 Des types riches exprimant les problèmes d’unification L’encodage repose sur l’obtention et la manipulation explicite d’égalités dans le langage. Ces égalités correspondent aux problèmes d’unication entre les index des termes ltrés et ceux des constructeurs. Les propriétés précédentes des constructeurs (discrimination, inversibilité et acyclicité) doivent être ensuite bâties explicitement. Pour obtenir l’information, la solution est d’utiliser le prédicat de retour de l’analyse de cas. Lors de l’élimination d’un entier n pour produire un terme de type T, on rajoute arti- ciellement une égalité ce qui donne le prédicat de retour λ(m : nat) ⇒ m = n → T. L’analyse de cas dans son ensemble a maintenant le type n = n → T, ce qui peut bien redonner T quand on lui applique eq_re nat n. L’avantage est que la branche O attend maintenant un terme de type O = n → T, ce qui fournit l’égalité recherchée. De telles constructions avec la clause de retour jouent un rôle fondamental pour le typage de l’analyse de cas qui sera discuté plus amplement section 3.4.1. Dans l’exemple précédent, l’égalité ajoutée relie des objets de type xe (nat). L’encodage complet du ltrage exposé section précédente nécessite de poser des égalités sur des objets dont les types sont eux-même concernés par d’autres égalités. L’égalité simple dénie gure 1.6 ne sut plus, on a alors besoin de dénir une égalité hétérogène (gure 3.1). Inductive JMeq (A : Set) (a : A) : ∀(B : Set) (b : B), Set := | JMeq_re :JMeq A a A a. Figure 3.1 – Dénition de l’égalité hétérogène Par exemple, la gure 3.2 qui décrit l’inversion d’un double successeur d’un entier a besoin d’égalité hétérogène. En eet, E a le type even 2 alors que H a le type even m. L’hypothèse 2 = m ne sut pas à rendre ces deux types convertibles, ce qui empêche de typer E = H. Definition even_inv (E : even 2) : eq (even 2) E (even_SS O even_O) := case E predicate λ(m : nat) (H : even m) ⇒ 2 = m → JMeq (even 2) E (even m) H → eq (even 2) E (even_SS O even_O) of |even_O:λ(e1 : 2 = O) (e2 : JMeq (even 2) E (even O) even_O) ⇒ . . . |even_SS:λ(n : nat) (E’ : even n) ⇒ λ(e1 : 2 = (S (S n))) (e2 : JMeq (even 2) E (even (S (S n))) (even_SS n E’)) ⇒ . . . end (eq_re 2) (JMeq_re (even 2) E). 2 représente (S (S O)) Figure 3.2 – Exemple d’inversion avec égalité Même une fois exploitée l’égalité de 2 et m, il est impossible d’exploiter l’égalité hétérogène. Le problème de généralisation mal typée mais indispensable pour écrire une clause de retour apparaît pour réaliser le type de la gure 3.3 (il faudrait pouvoir dissocier les 2 instances de p dans les arguments de la constante rew (formellement dénie gure 3.7) pour pouvoir éliminer l’égalité h) exactement comme celui de la gure 1.13. Tous deux sont d’ailleurs logiquement équivalents à K. Une fois muni de cet axiome, l’encodage est mécaniquement réalisable. 393 Encodage du ltrage dans l’analyse de cas Axiom eq_rect_eq : ∀(U : Set) (p : U) (Q : U → Set) (x : Q p) (h : p = p), x = rew U Q p p x h. Figure 3.3 – Egalité modulo réécriture de type 3.2.2 Manipulation des égalités d’index Les règles utilisées par l’unication durant le typage du ltrage par analyse de couverture deviennent des lemmes utilisés pour réaliser des réécritures en tête de branches. Nous allons détailler comment ces lemmes sont construits et utilisés. An d’exprimer une propriété triviale mais qui n’apporte aucune information, on dénit la propriété True (gure 3.4). Pour exprimer une impossibilité dont tout se déduit, on utilise la propriété False (gure 3.5). Inductive True : Set := | I :True. Figure 3.4 – La propriété vraie Inductive False : Set :=. Figure 3.5 – La propriété fausse Puisque False n’a pas de constructeurs, son schéma d’élimination (gure 3.6) qui sera réutilisé section 4.6 permet toutes les folies. La gure 3.7 donne le schéma d’élimination de l’égalité. La possibilité qu’il ore d’avoir une propriété pour le terme de droite si on peut la prouver pour celui de gauche est non seulement le moyen de réaliser les réécritures mais aussi une pierre angulaire de l’élaboration des lemmes d’injectivité eux-mêmes. On peut remarquer qu’il est équivalent d’écrire m = O et case m predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(_ : nat) ⇒ False end. En eet, si m est eectivement O nous n’avons aucune information supplémentaire. En revanche, si m n’est pas O, on obtient une preuve de faux qui nous donne la possibilité de fournir une preuve de T pour tout T en utilisant false_rect. L’analyse par cas constitue une forme d’égalité pour les termes dans lesquels seuls des variables et des constructeurs apparaissent, ceux visibles comme des motifs. Cette remarque et rew sont des outils susants pour discriminer les constructeurs. Pour deux constructeurs distincts Ci et Cj alors le terme de la gure 3.8 a le type C_j = C_i → False 2 . Ce terme permet de conclure dans les cas absurdes. De manière moins intuitive mais tout aussi systématique, le type ∀(n : nat), m = S n → T n peut se reformuler case m predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(n : nat) ⇒ 2. ceci est couramment noté Ci , Cj 403.3 Utilisabilité de l’encodage Definition false_rect (P : Set) (x : False) : P := case x predicate λ(_ : False) ⇒ P of end. Figure 3.6 – ex falso quolibet Definition rew (A : Set) (P : A → Set) (a b : A) (p : P a) (e : eq A a b) : P b := case e predicate λ(c : A) (e’ : eq A a c) ⇒ P c of |eq_re:p end. Figure 3.7 – Brique élémentaire de la réécriture (équivalente au eq_rect de Coq) T n end. La correspondance entre m et S n est assurée. Si m s’avère être autre chose qu’un S dans une branche, la branche est une branche impossible. Il sut de fournir I comme preuve triviale (et inutile pour toute exécution). La preuve d’inversibilité écrite gure 3.9 utilise cette méthodologie. Pour les preuves d’acyclicité, on utilise des inductions sur la variable apparaissant des 2 cotés. Tous les cas sauf celui du constructeur qui apparaît en tête dans l’égalité cyclique utilisent une discrimination. Ce dernier cas est exactement l’appel récursif après usage d’un lemme d’inversibilité. 3.3 Utilisabilité de l’encodage Sur la face logique de la correspondance de Curry-deBruijn-Howard, un lemme de mathématique est rarement démontré pour être évalué. Les termes engendrés par une preuve non triviale sont volumineux. Coq propose pour des questions d’ecacité et de modularité de les masquer une fois qu’ils ont été vériés. L’utilisateur utilise de fait ses lemmes comme des constantes opaques la majorité du temps. Ceci rend anodin d’utiliser l’axiome K. De plus, les égalités explicitement introduites autorisent un raisonnement équationnel arbitrairement complexe et plus expressif que n’importe quelle théorie décidable. Par exemple, il peut s’agir d’exploiter l’arithmétique de Peano sur des égalités d’entiers impliquant addition et multiplication. De plus, si aucune égalité hétérogène n’est utilisée et que l’utilisation des égalités fournies dans les branches se limite à instancier des lemmes de discrimination et d’inversibilité similaires à ceux de la section précédente, le comportement calculatoire du ltrage n’est pas altéré. L’élimination d’un inductif au moyen de cette méthodologie est utile et utilisée. Un algorithme alternatif partiel mais ne nécessitant pas K sera néanmoins proposé dans le chapitre suivant. En eet, d’une part ce manuscrit met l’accent sur l’écriture de programmes et ses problématiques, d’autre part, un tel algorithme représente un support de réexion sur l’expressivité d’une analyse de cas sans K. 413 Encodage du ltrage dans l’analyse de cas Definition C_i_C_j_discr : C_i = C_j → False := λ(e : eq . . . C_j C_i) ⇒ rew . . . (λ(x : . . .) ⇒ case x predicate λ −−−−→ (_ : _) ⇒ Set of |C_j:True |C_s:False end) C_i C_j I e. Figure 3.8 – Discrimination en action Definition C_i_inj (a b : . . .) : C_i a = C_i b → a = b := λ(e : eq . . . (C_i a) (C_i b)) ⇒ rew . . . (λ(x : . . .) ⇒ case x predicate λ −−−−→ (_ : _) ⇒ Set of |C_i:λ(y : . . .) ⇒ eq . . . a y |_:λ −−−−→ (_ : _) ⇒ True end) (C_i a) (C_i b) (eq_re _ a) e. Figure 3.9 – Injection en action 3.4 Constructions génériques autour d’une analyse de cas dépendante 3.4.1 Coupures entrelacées Concevoir intelligemment des clauses de retour implique d’entrelacer l’élimination d’un inductif avec des redex de fonction. Sans considération de typage, il est plus naturel d’écrire le terme (1) que (2) de la gure 3.10. Les deux termes sont néanmoins équivalents et on parle de coupure commutative car il serait possible de réduire (2) vers (1). Fixpoint plus (m n : nat) : nat := case n predicate λ(_ : nat) ⇒ nat of |O:m |S:λ(n’ : nat) ⇒ S (plus m n’) end. Fixpoint plus (m n : nat) : nat := case n predicate λ(_ : nat) ⇒ nat → nat of |O:λ(m’ : nat) ⇒ m’ |S:λ(n’ m’ : nat) ⇒ S (plus m’ n’) end m. (1) (2) Figure 3.10 – Exemple de coupure commutative Pour raisonner sur des prédicats de parité d’entier dénis gure 1.12, les expressions (1) et (2) de la gure 3.11 sont radicalement diérentes. Dans (1), la correspondance de type entre les deux variables est perdue alors que dans (2), le type de e1’ est modié simultanément à e2 dans chaque branche. En eet, l’analyse par cas ne modie pas les types des variables libres (comme e1 qui est de type even n). Les types dans le contexte et les types des constructeurs sont désynchronisés 423.4 Constructions génériques autour d’une analyse de cas dépendante Definition even_inv (n : nat) (e1 e2 : even n) : . . . := case e2 predicate λ(m : nat) (_ : even m) ⇒ . . . of |even_0:. . . |even_SS:λ(m’ : nat) (e : even (S (S m’))) ⇒ . . . end. Definition even_inv (n : nat) (e1 e2 : even n) : . . . := case e2 predicate λ(m : nat) (_ : even m) ⇒ even m → . . . of |even_0:λ(e1’ : even O) ⇒ . . . |even_SS:λ(m’ : nat) (e e1’ : even (S (S m’))) ⇒ . . . end e1. (1) (2) Figure 3.11 – Coupure entrelacée sur les prédicats de parité dans les branches (La première branche indique que e2 est even_0 de type even O mais e1 n’a pas changé de type pour autant). Par contre, en abstrayant une variable, elle passe du contexte à la conclusion. Son type est réécrit dans la clause de retour (e1’ est cette copie de e1 au type plus précis). L’utilisation des abstractions permet la conservation des correspondances dans l’analyse par cas. Sur l’exemple, en inversant l’ordre d’introduction de e1 et e2, la coupure commutative aurait été inutile. L’introduction partielle de e2 uniquement pour laisser e1 dans la conclusion aurait su parce qu’alors on peut faire une η-réduction. Cette possibilité n’est pas systématique comme nous le verrons dans la section 4.3. Introduire une coupure pour obtenir une copie d’un terme dans un type en adéquation avec le type du constructeur de la branche considérée n’est pas utile uniquement pour les variables libres. La mémorisation de la valeur des index du type éliminé se fait de la même manière. Cette technique est par exemple décrite par Bertot et Castéran dans [11] avec des preuves d’égalité. Pour éliminer (p : even(plus (S x) O)) ecacement, mieux vaut savoir que plus (S x) O = O dans le premier cas (an d’éliminer ce cas) et plus (S x) O = S (S m’) dans le second. Nous plaçons pour cela le terme eq_re (plus (S x) O) comme argument du ltrage et réécrivons son type grâce à la clause de retour λ(m : nat) (e : even m) ⇒ eq nat (plus (S x) O) m → . . . an d’obtenir exactement les égalités recherchées. Elles peuvent ainsi servir à montrer que la branche est impossible ou à obtenir des correspondances entre les types des arguments du constructeur et ceux du contexte et de la conclusion. 3.4.2 Elimination des branches impossibles Si un inductif n’a pas d’index, la clause de retour de l’élimination d’un terme de ce type n’a qu’une unique variable, celle qui généralise le terme ltré. Le type attendu dans les branches est le type demandé en retour du ltrage dans lequel le terme éliminé est remplacé par le constructeur de la branche. Sur le cas des listes, la gure 3.12 montre que les termes PN et 433 Encodage du ltrage dans l’analyse de cas PC ont des types ranés. Definition case_list (A : Set) (P : list A → Set) (PN : P nil) (PC : ∀ (t : A) (q : list A) , P (cons t q)) (l : list A): P l := case l predicate λ(l’ : list A) ⇒ P l’ of |nil:PN |cons:λ(t : A) (q : list A) ⇒ PC t q end. Figure 3.12 – Principe d’élimination d’une liste La valeur de l’objet ltré est ranée dans les branches mais son type n’est pas modié. Le typage de la clause de retour ne pose pas de diculté. Un inductif ayant un ou des arguments comme Inductive I : ∀(a : A),Set := . . .. est fondamentalement diérent d’un inductif tel que Inductive J (a : A) : Set := . . .. n’ayant que des paramètres. Tous les constructeurs de J ont en eet le type J a alors que les constructeurs de I ont un type I t avec t quelconque et dépendant du constructeur. Alors que l’élimination de (j : J u) ne peut produire que des constructeurs de type J u, l’élimination de (k : I v) peut produire des constructeurs de type I t (où t dépend du constructeur). Une clause de retour sur J n’a donc pas besoin de dépendre de a. C’est pourquoi il n’y a pas de lieur pour les paramètres. Dans la syntaxe de Gallina, ils doivent apparaître comme des _. Une clause de retour sur I doit par contre avoir un type de la forme ∀(a : A) (b : I a), Set an que P v k et P t (C x y) soient simultanément typables. Le type des branches dépend des index du constructeur en même temps que du constructeur. Le type varie d’un constructeur à l’autre. L’élimination de k doit avoir une branche pour tous les constructeurs C de l’inductif I. Il est donc nécessaire de fournir un terme de type P t (C x y) même si t est incompatible avec v et qu’il est impossible que k soit le constructeur C. L’abstraction sur l’argument de l’inductif donne un moyen de parler de v dans la clause de retour. Par conséquent, l’incompatibilité de t et v est exprimable dans la clause de retour an que n’importe quel terme soit admis dans la branche C. C’est alors une branche impossible. Si un index débute par un constructeur CC, la clause de retour va faire une analyse de cas sur cet index qui revoit le type demandé dans le cas de CC et le type choisi pour peupler les branches impossibles dans les autres cas. Nous verrons avec précision à la section 4.3 comment écrire une clause de retour exhibant les incompatibilités. Dans le cadre présenté ici toutes les branches impossibles contiennent une preuve de discrimination. 444 Du filtrage à l’analyse de cas structurellement L’originalité de ce chapitre est de proposer une traduction des arbres de décision vers des analyses de cas sans utiliser la structure de données eq (et JMeq). Cette construction réduit le préjudice induit par l’absence de l’axiome K en éliminant des situations où l’encodage de la section 3.2 introduit inutilement des égalités hétérogènes. Elle ne tire pas avantage de l’acyclicyté des types de données. Néanmoins, sans axiome ni preuve par récurrence en tête de branche, le comportement calculatoire n’est jamais entravé. La taille syntaxique des termes est aussi potentiellement moindre et leur typage s’avère plus rapide. 4.1 Squelee d’index Les constructeurs en tête des index du type des termes inspectés jouent un rôle particulier. Ils sont distingués des autres termes en introduisant la notion de squelette d’index. Tout d’abord, nous notons p(t1 · · · ts ) le motif p vu comme un terme dans lequel le ième joker est remplacé par le terme ti . Le squelette du terme u est alors la paire d’un motif p et de termes t1 · · · ts ne débutant pas par un constructeur tels que u = p(t1 · · · ts ). Le motif p exprime alors ce sur quoi on peut ltrer. Les termes t1 · · · ts sont dénommés les feuilles du squelette. Les motifs de squelette utilisent une restriction de la syntaxe présentée gure 2.3 puisqu’ils ne contiennent ni alias ni choix. Par exemple, le squelette du terme even_SS (S (S n)) (even_SS n t) est (even_SS (S (S _)) (even_SS _ _), [n ;n ;t]). Deux squelettes sont compatibles si il existe une substitution des jokers de la partie motif de l’un qui permet d’obtenir la partie motif de l’autre. Pour tout terme u dans une famille inductive, le squelette d’index du type de u est la liste des squelettes des index de son type. 4.2 and les égalités sont inutiles Considérons l’élimination d’un terme x de type I a1 · · · as an d’obtenir un terme de type P. Dans le cas le plus simple, les a1 · · · as sont des variables deux à deux distinctes et de types identiques à ceux des index de I lors de sa dénition. Le terme x a dans ce cas un type aussi général que la signature de I. Il est alors inutile de recourir à des égalités pour éliminer x. La 454 Du ltrage à l’analyse de cas structurellement clause de retour s’écrit directement λ −−−−−→ (a’ : A) (x’ : I a’1 · · · a’s ) ⇒ P’ où P’ est P dans lequel sont réalisés les α-renommages ai -> a’i et x -> x’. Remarque Le terme P’ est une généralisation de P, les termes a1 · · · as , x (qui se trouvent être des variables) sont des objets immuables alors que les variables a’1 · · · a’s , x’ sont des abstractions pour diérents termes suivant les cas. Ce sont les outils du ranement des types dans les branches. Par rapport au typage direct du ltrage généralisé (chapitre 3), le sens dans lequel la correspondance entre les type est faite dans les branches est en quelque sorte inversé. Alors que l’unication ou les réécritures qui la simulent plongent les types des arguments du constructeur dans les types du contexte, c’est maintenant le type de retour qui est réécrit en correspondance avec le type du constructeur. En conséquence, si le type du constructeur est trop général, le type attendu est trop général (voir section 4.4). Si maintenant les index a1 · · · as de x ne sont plus nécessairement des variables, un deuxième cas favorable peut se produire. Les feuilles du squelette d’index du type de x peuvent être des variables deux à deux distinctes et de types découlant de la dénition de I. Les constatations pour écrire des lemmes d’injection (gure 3.9) sont alors réemployables. Une clause de retour avec égalité (section 3.2.2) x = C a b → P a b peut s’écrire case x predicate Set of |λ. . . ⇒ Q . . . |λ(a’ : _) (b’ : _) ⇒ P a’ b’ . . . |λ. . . ⇒ Q end. Les branches correspondant à des constructeurs dont l’index ne commence pas par C sont des branches impossibles. Comme expliqué section 3.4.2, le type Q peut donc a priori être choisi arbitrairement mais il est judicieux qu’il soit un type trivialement habité an d’avoir un terme de type Q canonique. Tous les cas d’une élimination d’un inductif doivent en eet être donnés, y compris ceux qui sont impossibles pour toute exécution car de type incompatible. Nous utiliserons dans un premier temps True (et I) (dénis gure 3.4) avant de raner ce choix section 4.6 pour une raison d’inférence de la terminaison des points xes, problème indépendant de celui considéré ici. Une clause de retour du ltrage d’un terme dont le type est un motif est donc caractérisé par une formulation comme match t as x’ in I p1 · · · pn return P with ... end avec les p1 · · · pn des motifs. Coq autorise d’ailleurs directement cette syntaxe. La structure pour donner le prédicat de retour in I p1 · · · pn return P est transformée en interne en λy1 · · · yn ⇒ « match y1 · · · yn with | p1 · · · pn => P | _ => True end » Le ltrage est entre guillemets car il s’agit d’un ltrage généralisé à compiler à son tour. Intuitivement, les termes qui composent ces clauses de retour sont un ltrage à un seul cas intéressant, celui qui isole le squelette d’index du terme ltré. Jean Francois Monin et Xiaomu Shi ont introduit le terme diagonaliseur pour parler d’eux dans [43]. La diérence d’expressivité entre le ltrage par couverture et le ltrage par analyse de cas est assez explicite avec les clauses de retour mises sous cette forme. Le motif utilisé ici est un motif de la programmation fonctionnelle, il doit être linéaire. Le motif de l’analyse de couverture est un motif de la programmation logique qui n’a pas cette contrainte. L’identication de deux types est exactement ce qui nécessite K. 464.3 Diagonalisation 4.3 Diagonalisation Pour pouvoir construire une clause de retour, il faut savoir : — extraire le squelette d’index, mais aussi, — abstraire les variables libres dont le type interfère avec l’objet ltré ou ses index. Conserver les liens avec les types des variables libres introduit les coupures entrelacées. Spécialiser la clause de retour suivant le squelette d’index élimine les branches impossibles. Cela demande du ltrage dans le diagonaliseur. Il y a donc du ltrage dans la clause de retour du ltrage. Cependant le ltrage dans la clause de retour a lieu sur le type d’un index du terme ltré. Il a donc lieu sur un inductif déni strictement plus tôt dans le contexte global. La terminaison est assurée, la lisibilité du résultat par contre ne l’est pas. Nos exemples explicatifs sont incrémentaux pour ne pas noyer le lecteur. Commençons par illustrer l’utilisation d’un squelette d’index et la reconnaissance de branches impossibles. Fournir un habitant du type False est et doit rester impossible. Il est pourtant possible d’écrire une preuve de ∀(H : even 1), False (pour even déni gure 1.12) par ltrage sur H. La clause de retour de l’élimination d’un terme de type even u a la forme λ(n : nat) (e : even n) ⇒ P n e. Les constructeurs S et O sont des constantes injectives. Le diagonaliseur de la gure 4.1 permet en ltrant sur n de montrer que P 1 _ renvoie False comme attendu mais que P (S (S m)) (even_SS m) et P O even_O demandent des termes de type True faciles à construire. Definition diag_even1 (n : nat) (e : even n) : Set := case n predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(m : nat) ⇒ case m predicate λ(_ : nat) ⇒ Set of |O:False |S:λ(_ : nat) ⇒ True end end. Definition even1 (H : even (S O)) : False := case H predicate λ(n : nat) (e : even n) ⇒ diag_even1 n e of |even_O:I |even_SS:λ(m : nat) ⇒ I end. Figure 4.1 – Diagonaliseur pour even 1 La section précédente a illustré deux techniques : généraliser le type attendu en retour de l’analyse de cas et incorporer aux clauses de retour la séparation des constructeurs. Mettons maintenant en œuvre pleinement ces constructions. Dans l’exemple précédent (x = C a b → P a b) les variables a b sont devenues a’ b’ à l’intérieur du case. Plus généralement, les variables qui apparaissent en feuilles du squelette d’index sont substituées autant que possible par les variables issues de l’analyse de cas. Une telle substitution n’est pas une opération sûre : si la 474 Du ltrage à l’analyse de cas structurellement variable substituée apparaît dans les paramètres de l’inductif ou apparaît à plusieurs feuilles, le terme construit est mal typé. La n de ce chapitre détaille notre heuristique (section 4.5). Ecrire un terme de type ∀(n : nat) (e : even (S (S n))), even n par analyse de cas sur e met en application ce principe. Le cas even_O est une branche impossible car O , S(S _) . L’argument m de even_SS est utilisé lui dans le type attendu. Le prédicat de diagonalisation est Definition diag_SS (n : nat) (e : even (S (S n))) : Set := case n predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(x : nat) ⇒ case x predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(m : nat) ⇒ even m end end. Figure 4.2 – Diagonaliseur pour inverser evenSS Nous n’utilisons ici que la feuille du squelette d’index dont le type n’est pas dépendant. Dès qu’est utilisée une variable dont le type évolue au cours du ranement du squelette d’index, une coupure entrelacée est nécessaire. En particulier, le type de la variable représentant la généralisation du terme ltré doit se raner au fur et à mesure que les index du terme ltré sont ranés. An d’illustrer cette armation, nous introduisons une nouvelle structure de données dépendante. La gure 4.3 déni la famille des ensembles nis. Le type Fin n représente l’ensemble [|1 .. n|]. Le constructeur F1 m représente le premier élément d’un ensemble à S m éléments alors que FS m f représente le (k + 1)-ième élément d’un ensemble à S m éléments si f représente le k-ième élément d’un ensemble à m éléments. Par exemple, Fin O est vide, Fin (S (S O)) contient F1 (S O) et FS (S O) (F1 O), etc. Inductive Fin : nat → Set := | F1 :∀(n : nat), Fin (S n) | FS :∀(n : nat), Fin n → Fin (S n). Figure 4.3 – Famille inductive des ensembles de taille xée Avec cette dénition, comment raisonner par cas sur un élément quelconque d’un ensemble non vide ? Supposons par exemple que t a le type Fin (S n) pour n xé et que l’on souhaite raisonner par cas dessus. Le but est alors d’écrire un terme de type ∀(n : nat) (f : Fin (S n)), P n f. Son diagonaliseur va nécessairement débuter par les abstractions issues de la dénition de la famille inductive : λ(k : nat) (f’ : Fin k) ⇒ . . .. il faut ensuite ltrer sur k pour retrouver qu’il est non nul sans perdre le fait que f’ a k éléments. La variable f’ est dans le contexte, une coupure entrelacée la remet dans la conclusion. La gure 4.4 montre le résultat. Les diagonaliseurs réalisent pour l’instant des ltrages sur nat, un inductif non dépendant. Les diagonaliseurs des analyses de cas du diagonaliseur étaient implicites car simples. Dans le cas général, il faut de nouveau prendre en considération dans le diagonaliseur les branches 484.3 Diagonalisation Definition diag_nS (k : nat) (f’ : Fin k) : Set := case k predicate λ(k’ : nat) ⇒ Fin k’ → Set of |O:λ(fo : Fin O) ⇒ True |S:λ(k’ : nat) (fs : Fin (S k’)) ⇒ P k’ fs end f’. λ(n : nat) (f : Fin n) ⇒ case f predicate diag_nS of |F1:λ(m : nat) ⇒ . . . : P m (F1 m) |FS:λ(m : nat) (f’ : Fin m) ⇒ . . . : P m (FS m f’) end Figure 4.4 – Diagonaliseur pour ensemble non vide impossibles, généraliser suivant les index et le terme éliminé mais aussi prévenir les désynchronisations des types des variables du contexte avec ceux des arguments du constructeur dans la branches. Bref, bâtir récursivement nos diagonaliseurs. Considérons par exemple l’élimination d’un prédicat (H : FLast (S n) (FS n f)) où FLast exprime la propriété d’être le dernier élément d’un ensemble non élémentaire (gure 4.5) pour conclure P n f H . Il faudra construire successivement trois diagonaliseurs. Inductive FLast : ∀(n : nat) (f : Fin n), Set := | FL1 :FLast (S O) (F1 O) | FLS :∀(n : nat) (f : Fin n), FLast n f → FLast (S n) (FS n f). Figure 4.5 – Dernier élément d’un ensemble Le prédicat de diagonalisation gure 4.7 débute par un ltrage sur l’entier. L’ensemble et le prédicat ne doivent pas être introduits an de conserver les dépendances de type. Le prédicat (diag_Fin : ∀(k : nat) (f : Fin (S k)) (H : Flast (S k) f), Set) doit ensuite par ltrage sur f être égal à P appliqué aux variables du dernier ltrage dans le cas FS et à True sinon. Pour conserver les correspondances de type alors qu’un constructeur apparaît dans le type de f, l’élimination a pour clause de retour le diagonaliseur diag_nat. Ici il existe un diagonaliseur bien plus simple donné gure 4.8 qui économise l’analyse de cas sur les entiers vu qu’ils sont arguments de l’ensemble. Néanmoins, la présence de diagonaliseurs dans les diagonaliseurs est générique et absolument nécessaire en général. Pour preuve, voici notre dernier exemple : l’inversion du prédicat d’égalité sur deux ensembles de même taille déni gure 4.6. Il met en oeuvre tous les mécanismes expliqués. Cette fois, tous sont nécessaires. Le résultat est indigeste, il est heureux que la section 4.7 donne l’algorithme formel pour le générer an que plus jamais il ne soit écrit manuellement. Inductive FinEq : ∀(n : nat), Fin n → Fin n → Set := | F1Eq :∀(n : nat), FinEq (S n) (F1 n) (F1 n) | FSEq :∀(n : nat) (f1 f2 : Fin n), FinEq n f1 f2 → FinEq (S n) (FS n f1) (FS n f2). Figure 4.6 – Prédicat d’égalité sur les éléments dans des ensembles de même taille 494 Du ltrage à l’analyse de cas structurellement Definition diag_FLS (m : nat) : ∀(f : Fin m) (H : FLast m f), Set := case m predicate λ(m’ : nat) ⇒ ∀(f : Fin m’) (H : FLast m’ f), Set of |O:λ(f’ : Fin O) (_ : FLast O f’) ⇒ True |S:λ(k : nat) ⇒ diag_Fin k end. where Definition diag_Fin (k : nat) (f : Fin (S k)) : ∀(H : FLast (S k) f), Set := case f predicate diag_nat of |FS:λ(j : nat) (f0 : Fin j) ⇒ λ(H : FLast (S j) (FS j f0)) ⇒ P j f0 H |F1:λ(j : nat) ⇒ λ(_ : FLast (S j) (F1 j)) ⇒ True end. and Definition diag_nat (i : nat) : ∀(f : Fin i), Set := case i predicate λ(i’ : nat) ⇒ ∀(f : Fin i’), Set of |O:λ(_ : Fin O) ⇒ True |S:λ(j : nat) ⇒ λ(f’ : Fin (S j)) ⇒ ∀(H : FLast (S j) f’), Set end. Figure 4.7 – Diagonaliseur pour ∀(H : FLast (S n) (FS n f)), P n f H λ(m : nat) (f : Fin m) ⇒ case f predicate λ(i : nat) (f’ : Fin i) ⇒ FLast i f’ → Set of |F1:λ(i : nat) (H : FLast (S i) (F1 i)) ⇒ True |FS:λ(i : nat) (f0 : Fin i) (H : FLast (S i) (FS i f0)) ⇒ P i f0 end Figure 4.8 – Diagonaliseur optimisé pour ∀(H : FLast (S n) (FS n f)), P n f H 504.3 Diagonalisation Definition diag_x1 (x1 : nat) : Fin x1 → Set := case x1 predicate λ(n2 : nat) ⇒ Fin n2 → Set of |O:λ(_ : Fin O) ⇒ True |S:λ(x0 : nat) ⇒ λ(f1’ : Fin (S x0)) ⇒ ∀(f2 : Fin (S x0)), FinEq (S x0) f1’ f2 → Set end. Definition diag_x2 (x2 : nat) : Fin x2 → Set := case x2 predicate λ(n3 : nat) ⇒ Fin n3 → Set of |O:λ(_ : Fin O) ⇒ True |S:λ(x0 : nat) ⇒ λ(f2’ : Fin (S x0)) ⇒ ∀(f1’’ : Fin x0), FinEq (S x0) (FS x0 f1’’) f2’ → Set end. Definition diag_H (n0 : nat) : ∀(f1 f2 : Fin n), FinEq n f1 f2 → Set := case n0 predicate λ(n1 : nat) ⇒ ∀(f4 f5 : Fin n1), FinEq n1 f4 f5 → Set of |O:λ(f4 f5 : Fin O) (_ : FinEq O f4 f5) ⇒ True |S:λ(x : nat) ⇒ λ(f4 : Fin (S x)) ⇒ case f4 predicate diag_x1 of |F1:λ(n1 : nat) ⇒ λ(f5 : Fin (S n1)) (_ : FinEq (S n1) (F1 n1) f5) ⇒ True |FS:λ(n1 : nat) (f5 : Fin (S n1)) ⇒ λ(f6 : Fin (S n1)) ⇒ (case f6 predicate diag_x2 of |F1:λ(n2 : nat) ⇒ λ(f7 : Fin n2) (_ : FinEq (S n2) (FS n2 f7) (F1 n2)) ⇒ True |FS:λ(n2 : nat) (f7 : Fin n2) ⇒ λ(f8 : Fin n2) (_ : FinEq (S n2) (FS n2 f8) (FS n2 f7)) ⇒ FinEq n2 f8 f7 end f5) end end. Definition invert_H (n : nat) (f1 f2 : Fin n) (H : FinEq (S n) (FS n f1) (FS n f2)) : FinEq n f1 f2 := case H predicate λ(n0 : nat) (f f0 : Fin n0) (H’ : FinEq n0 f f0) ⇒ diag_n f f0 H’ of |F1Eq:λ(_ : nat) ⇒ I |FSEq:λ(m : nat) (f’ f’’ : Fin m) (H0 : FinEq m f’ f’’) ⇒ H0 end. Figure 4.9 – Inversion du prédicat d’égalité sur deux ensembles non élémentaires 514 Du ltrage à l’analyse de cas structurellement 4.4 and le diagonaliseur en dit trop La construction du diagonaliseur est réalisée suivant l’intégralité du squelette d’index de l’objet ltré. Maintenant, il faut aussi se préoccuper des constructeurs de l’inductif correspondant et de leurs squelettes d’index. Jusqu’à maintenant, ces squelettes étaient soit égaux soit incompatibles avec le squelette de l’objet ltré. En réalité, ils peuvent être plus généraux. La forme normale du type attendu dans la branche est alors une analyse de cas sur l’un des arguments du constructeur. Pour habiter le type voulu, la branche commence par l’élimination de cet argument. Pour caricaturer, dénissons un inductif ayant un prédicat comme paramètre et un entier comme index et dont l’unique constructeur n’a pour but que d’empaqueter un habitant du prédicat pour un entier donné (gure 4.10). Supposons ensuite que l’on souhaite détruire un terme de type boite P (S n) pour P et n donnés. L’élimination a la structure indiquée en gure 4.11. Il a fallu raisonner par cas sur l’argument de contenu an de peupler le type demandé dans la branche puisque lui aussi est un raisonnement par cas sur cet argument. Inductive boite (D : nat → Set) : nat → Set := | contenu :∀(n : nat), D n → boite D n. Figure 4.10 – Une boite à D Definition ouvre_boite (D : nat → Set) (n : nat) (B : boite D (S n)) : T := let diag_boite := λ(m : nat) ⇒ case m predicate λ(m’ : nat) ⇒ Set of |O:True |S:λ(k : nat) ⇒ T end in case B predicate λ(m : nat) (_ : boite D m) ⇒ diag_boite m of |contenu:λ(n : nat) (x : P n) ⇒ case n predicate λ(n’ : nat) ⇒ diag_boite n’ of |O:True |S:λ(k : nat) ⇒ t end end. Figure 4.11 – Éliminer une grosse boite Voilà tout le nécessaire pour construire des clauses de retours et peupler les parties impossibles des branches si les index des termes ltrés peuvent être écrits sous la forme d’une liste de motifs du ltrage à la ML. Des situations hors de ce cadre peuvent néanmoins apparaître à tout moment, y compris dans les index des index soit dans des appels récursifs. Trouver un comportement le plus conservatif possible quand les termes sont trop généraux est indispensable pour écrire un algorithme générique utilisable en pratique. 524.5 Des clauses de retour pour éliminer tous les termes 4.5 Des clauses de retour pour éliminer tous les termes Nous venons de voir sur des exemples les méthodes que la compilation structurelle du ltrage utilise. Au-delà de ces exemples, quels sont les ltrages pour lesquels ces méthodes s’appliquent convenablement et sont susantes ? La diculté de construire une analyse de cas dépend du type de l’objet ltré. 4.5.1 Les index du type ne contiennent que des variables et des constructeurs Pour éliminer une structure de données n’ayant pas d’index, la section 1.7 a déjà remarqué qu’aucun type n’était variable dans la clause de retour et que le problème ne posait pas de diculté. En présence d’index mais pas de paramètres, la question est de savoir si ces index peuvent être vus comme des motifs. Construire une clause de retour structurellement se fait en eet au moyen d’un diagonaliseur et un diagonaliseur est construit par analyse de cas sur les index. Dans un motif de la programmation fonctionnelle, les variables sont des lieurs tous distincts. En renommant toutes les occurrences de ces variables dans le type attendu en retour de l’analyse de cas, on conserve un terme correctement typé. Construire des clauses de retour ne comporte alors pas de diculté. En présence de paramètre et d’index simultanément, les variables apparaissant à la fois dans les index et les paramètres sont problématiques. L’occurrence dans les index prend part au diagonaliseur et va donc être α-renommé dans la clause de retour alors que celle dans les paramètres n’y prend pas part et reste constante. Comment savoir alors quelles occurrences de la variable dans le type attendu en retour de l’analyse de cas renommer et ne pas renommer pour écrire la clause de retour ? Que se soit suite au problème d’occurrence simultané dans un paramètre d’une variable apparaissant dans un index ou de l’occurrence multiple dans les index, supposons que la condition de linéarité d’occurrence des variables ne soit pas satisfaite pour la variable o. Il faut alors réintroduire des degrés de liberté pour écrire un prédicat de retour. Nous voulons dissocier les occurrences de o dans Q (le type attendu en retour) en fonction de l’occurrence de o dans t’1 · · · t’s ou w’1 · · · w’s dont elles proviennent. Le problème se ramène concrè- tement à dénir (Q0 : ∀. . . (o1 : _) . . . (o2 : _) . . ., Set) dont le type suit la signature de l’inductif et tel que Q0 . . . o . . . o . . . = Q. Notre heuristique fait le choix d’utiliser autant que le typage le permet o2 puis autant que le typage le permet o1 puis o en dernier recourt. Elle est choisie pour maximiser la « typabilité » des termes générés. Quand ni o1 ni o2 ne peuvent être choisis mais qu’un o’ imaginaire uniable à la fois à o1, o2 et o le pourrait, nous avons aaire à un ltrage qui implique l’axiome K sur le type de o. o1 et o2 ne sont pas dissociables. Notre algorithme n’utilise lui que o. Il fournit ainsi un type qui ne varie pas suivant les branches et rend inexploitable l’élimination. L’information que o1 = o2 = o est perdue. Avant d’atteindre les feuilles du squelette d’index et les problèmes de généralisation, il a fallu extraire le motif du diagonaliseur. Pour cela : 534 Du ltrage à l’analyse de cas structurellement 1. Nous commençons par une phase conservative : — Quand une feuille du squelette d’index est une variable qui n’apparaît ni dans le type attendu en retour ni dans les types des feuilles suivantes, il est remplaçable par un _ (le joker des motifs). Par exemple, pour détruire (f : even m) an d’obtenir un entier, puisque m n’apparaît pas dans nat, il est parfaitement admissible d’écrire case f predicate λ(_ : nat) (_ : even _) ⇒ nat of . . . end — Dans la dénition d’un inductif, un index peut en déterminer un autre. Par exemple, dans FLast, l’entier est déterminé par l’ensemble car il en est la taille. Plus géné- ralement, à chaque fois que le type de l’inductif est de la forme ∀. . . (x : . . .) . . . (y : I t1 · · · ts ), Set et que x est l’une des feuilles du squelette d’index d’un des t1 · · · ts , y détermine x. Un index déterminé par ailleurs grâce à la dénition de l’inductif est remplaçable par un joker si, dans le type de l’objet ltré, il s’agit d’une variable ou que l’un des index le déterminant commence par un constructeur. — Un index déterminé par ailleurs ne l’est pas nécessairement qu’une seule fois. Dans la dénition de FinEq le premier index est déterminé par le second et/ou le troisième car les deux ensembles sont de même taille : l’entier donné. Lorsque deux index déterminant un même troisième commencent tous deux par un constructeur, le terme t correspondant à l’index déterminé apparaît comme argument des deux constructeurs. Une occurrence déterminant l’autre, t est remplaçable par un joker dans l’un des deux index déterminant en plus de remplacer l’index dé- terminé par _. 2. Si après cette phase, nous n’avons plus que des constructeurs, des jokers et des variables apparaissant linéairement, et hors des paramètres du type de l’objet ltré, nous voilà dans la situation optimale. Voici un motif caractérisant le problème qui va permettre la construction d’un diagonaliseur. 4.5.2 Hors du cadre pseudo-motif Nous allons maintenant nous attarder sur des ltrages qui ne sont pas couverts par le typage primitif. Comment éliminer une donnée dont les index du type sont des termes quelconques (des sortes, des produits des analyses de cas, . . .) ? Deux altermatives existent : perdre de l’information ou réintroduire les égalités explicites que nous souhaitions éviter. — On ramène le problème de générer une annotation de type pour une analyse de cas à un problème d’unication d’ordre supérieur Si l’un des t’ n’est pas une variable. L’algorithme tente d’abstraire t’ par une variable fraîche du type de l’argument correspondant dans la dénition de l’inductif. Les chances de résultat concluant sont minces et la correspondance de cet argument avec t’ est perdue. Quasi systématiquement, aucune occurrence substituable n’est trouvée et le type de retour demandé est constant suivant les branches. L’information est perdue par désynchronisation entre les types comme nous l’avons expliqué lorsque nous avons étudier les conséquence de ne pas utiliser les abstractions de la clause de retour section 3.4.2. 544.6 Digression sur les cas impossibles dans des points xes Si ces index n’apparaissent ni dans le type d’autres index non jokerisés ni dans le type attendu en retour de l’analyse de cas, il n’y aura pas de problème de typage mais il peut néanmoins appaitre des branches impossibles non reconnues comme telles. Prenons l’exemple de (x : nat) et (f : even (plus x (S O))). En détruisant f pour obtenir un nouvel entier (nat), il est tout-à-fait possible d’écrire la clause de retour λ(_ : nat) ⇒ nat. Nous n’avons pas l’information que la branche d’even_O est impossible même si eectivement x + 1 , 0. Les désagréments ont tendance à s’accumuler. Si une variable x apparaissant pourtant linéairement dans les index a un type contenant un autre index t’, x ne sera pas convenablement systématiquement renommée. Dans ∀(m n : nat) (f1 : Fin m) (f2 : Fin n) (f3 : Fin (plus n m)) (H : FLast (plus m n) f3), eq (Fin (plus m n)) (append m f1 n f2) f3, il est impossible d’éliminer H car la clause de retour est mauvaise que l’on écrive λ(x : nat) (y : Fin x) ⇒ x = plus m n → eq (Fin x) (append m f1 n f2) y ou eq (Fin (plus m n)) (append m f1 n f2) y — L’alternative est de réappliquer la stratégie des égalités explicites du chapitre précédent. Au lieu d’eacer ces termes u1 · · · us , on réalise une coupure entrelacée sur l’égalité en appliquant l’analyse de cas à eq_re ... y1 · · · eq_re ... ys an de se souvenir dans les branches à quoi sont égales les feuilles du squelette d’index. Il n’y a pas moyen de tirer avantage automatiquement des ces égalités car elles n’ont pas de constructeur en tête. Lorsque le terme de preuve est construit interactivement par tactique, l’utilisateur peut réagir manuellement aux informations retournées pour construire les branches après une élimination d’une inductif. La stratégie adoptable est diérente. Mieux vaut conserver toutes les informations de correspondance quitte à utiliser pour se faire des égalités (potentiellement hétérogènes) explicitement. 4.6 Digression sur les cas impossibles dans des points fixes Il doit être fait une remarque maintenant qui ne prend du sens qu’une fois les questions du contrôle de la bonne formation des points xes abordée (Chapitre 6) Une analyse de cas est considérée comme un argument admissible d’un appel récursif si toutes ses branches le sont. En particulier, si un inductif n’a, comme False, aucun constructeur, toutes les zéros branches d’un ltrage d’un terme de ce type sont des appels récursifs admissibles. An que les branches impossibles soient le plus invisibles possible, il faut les peupler par des termes qui sont des appels récursifs admissibles. C’est pourquoi, plutôt que I : True, Coq utilise dans les cas impossibles λ(x : False) ⇒ case x predicate λ(_ : False) ⇒ True of end : False → True. Ainsi, si v est un sous terme d’un argument récursif dans la dénition du point xe f, le terme f (Vhd v) est un appel récursif admissible pour la dénition Definition Vhd (A : Set) (n : nat) (v : vector A (S n)) : A := let diag := λ(n : nat) ⇒ case n predicate λ(n’ : nat) ⇒ vector A n’ → Set of |O:λ(_ : vector O) ⇒ False → True |S:λ(m : nat) ⇒ λ(_ : vector (S m)) ⇒ A 554 Du ltrage à l’analyse de cas structurellement end in case v predicate diag of |Vnil:λ(x : False) ⇒ case x predicate λ(_ : False) ⇒ True of end |Vcons:λ(n : nat) (h : A) (t : vector A n) ⇒ h end. mais pas pour la dénition Definition Vhd (A : Set) (n : nat) (v : vector A (S n)) : A := let diag := λ(n : nat) ⇒ case n predicate λ(n’ : nat) ⇒ vector A n’ → Set of |O:λ(_ : vector O) ⇒ True |S:λ(m : nat) ⇒ λ(_ : vector (S m)) ⇒ A end in case v predicate diag of |Vnil:I |Vcons:λ(n : nat) (h : A) (t : vector A n) ⇒ h end. car I n’est pas un sous terme ! 4.7 Mécaniser la diagonalisation et compiler le filtrage Le chapitre 2 indique comment obtenir un arbre de décision et une pile d’objet à ltrer à partir d’un ltrage. Cette partie va indiquer comment aller mécaniquement d’un arbre de décision à une succession d’analyse de cas. Toute la diculté est de gérer les types. Les opérations élémentaires sont toutes mutuellement récursives, c’est pourquoi l’exposé est nécessairement incrémental et non parallèle. Les fonctions impliquées sont — env ⊢ decl_branchenuméro_branche continuation_corps_branche type_branche = résultat pour construire une branche, — env ⊢ construire_case terme_éliminé clause_de_retour continuation_corps_branche = résultat pour construire une analyse de cas, — env ⊢ (type_terme_éliminé 7→ type_attendu_retour) ց résultat, variables_à_généraliser pour aller du type de l’objet analysé à un diagonaliseur, — env ⊢ || (terme_éliminé : index_type_terme_eliminé) 7→ [substitution]type_attendu_retour || = arbre_decision, variables_à_généraliser pour construire l’arbre de décision associé au type d’un terme éliminé, — et env ⊢ arbre_décision : type_attendu_retour ց résultat pour aller d’un arbre de décision à un terme du CCI. 4.7.1 Construire une analyse de cas à partir de sa clause de retour La première opération nécessaire est la construction d’une branche dirigée par son type. Il s’agit de la fonction decl_branche déclarée gure 4.12. On part du type que doit avoir la branche et d’une fonction de continuation pour construire la branche. Le système regarde le type : 564.7 Mécaniser la diagonalisation et compiler le ltrage — S’il reconnaît une branche impossible, il peuple la branche automatiquement et n’utilise pas la continuation. — Si le type est une analyse de cas sur l’un des arguments du constructeur, nous sommes dans la situation de la section 4.4. Le système fait une analyse de cas sur cette variable pour n’appeler la fonction de l’utilisateur que lorsque toutes les informations de typage auront été récupérées. — Dans les autres cas, c’est à la continuation d’agir. Γ ⊢ decl_branchei k T = t Γ ⊢ decl_branchei k (∀ −−−−→ (x : S), False → T) = (λ −−−−→ (x : S) (b : False) ⇒ ex_falso T b) Γ, −−−−→ (z : S) ⊢ (x 7→ * . , case x predicate P of |b1 · · · |bs end u1 · · · uj + / - ) ց diag, y1 · · · yn Γ, −−−−→ (z : S) ⊢ construire_case x diag k_branche = t Γ ⊢ decl_branchei k * . . . . , λ −−−−→ (z : S) ⇒ case x predicate P of |b1 · · · |bs end u1 · · · uj + / / / / - = λ −−−−→ (z : S) ⇒ t y1 · · · yn k_branche(Γ, T, i) = t ssi Γ ⊢ decl_branchei k T = t Γ ⊢ decl_branchei k T = k Γ T i Figure 4.12 – Dénition de la ième branche dirigée par son type T puis la continuation k La fonction decl_branche peuple les parties non informatives de la branche, celles qui sont issues d’un type de branche fourni par un diagonaliseur pour ne demander à l’utilisateur que les branches utiles lors de réductions. Grâce à elle, nous dénissons construire_case, la fonction décrite gure 4.13 qui construit une analyse de cas à partir d’un diagonaliseur et d’une continuation fournissant les habitants des branches utiles. 4.7.2 D’un arbre de décision à des analyses de cas Nous n’avons pas encore dit comment écrire une clause de retour mais nous savons ré- pondre aux artefacs qu’elle induit dans les termes. Il est alors possible de décrire gure 4.14 comment aller d’un arbre de décision à un terme. Cette procédure a besoin du type T du 574 Du ltrage à l’analyse de cas structurellement Γ ⊢ construire_case t diag k = o Γ ⊢ C1 ∈ ∀ −−−−−−−−−→ (z1n : S1n), I u11 · · · u1j · · · Γ ⊢ Cs ∈ ∀ −−−−−−−−→ (zsn : Ssn), I us1 · · · usj Γ ⊢ decl_branchei k (∀ −−−−−−−−−→ (z1n : S1n), T u11 · · · u1j (C1 z11 · · · z1n)) = b1 · · · Γ ⊢ decl_branchei k (∀ −−−−−−−−→ (zsn : Ssn), T us1 · · · usj (Cs zs1 · · · zsn)) = bs Γ ⊢ construire_case t T k = case t predicate T of |b1 · · · |bs end Figure 4.13 – Dénition de l’élimination de t à partir du prédicat de retour diag suivant la continuation k terme à construire et de l’environnement de typage Γ. Les alias présents dans les noeuds de l’arbre de décision doivent être des variables deux à deux distinctes et diérentes des variables de l’environnement. Cet invariant est garanti par les fonctions qui construisent un arbre de décision au moment où elles prennent en compte les alias donnés par l’utilisateur. Γ ⊢ st : T ց t Γ ⊢ Tail (t) : T ց t Γ, (x : S) ⊢ p : T ց t Γ ⊢ Leafx : : p : ∀ (x : S), T ց λ (x : S) ⇒ t Γ, (x : S) ⊢ (x 7→ T) ց diag, y1 · · · ys Γ, (x : S) ⊢ construire_case x diag k_case = t Γ ⊢ Nodex(st1 · · · stn) : ∀ (x : S), T ց λ (x : S) ⇒ t y1 · · · ys k_case(Γ, T, i) = t ssi Γ ⊢ sti : T ց t Figure 4.14 – D’un arbre de décision à un terme La générations des analyses de cas suit exactement la structure de l’arbre de décision : — A la n la substitution des alias par des variables est appliquée au membre droit de la branche — Une feuille est une abstraction. La substitution est enrichie du nouveau nom pour l’alias. — Si l’on sait obtenir les variables du contexte qu’il faut généraliser et le diagonaliseur qui correspondent à une élimination, nous savons construire l’analyse de cas qui correspond à un noeud. — Un échange introduit par des abstractions les éléments de la pile jusqu’à l’élément recherché, retire des éléments introduits ceux à oublier car ils sont imposés par le typage de l’élément recherché puis réapplique l’élément recherché suivi des éléments restants. L’échange introduit comme le noeud des coupures entrelacées mais avec des termes à ltrer plus tard et non des variables libres. 584.7 Mécaniser la diagonalisation et compiler le ltrage 4.7.3 Extraire un diagonaliseur Il reste à construire le diagonaliseur (gure 4.16), c’est-à-dire à extraire le squelette d’index d’un terme ltré, la généralisation des variables libres dont le type dépend des feuilles de ce squelette et à tenter la meilleurs abstraction possible du type attendu en retour en fonction de ces feuilles. Γ ⊢ || (t : u1 · · · us ) 7→ [σ]c || = p, x1 · · · xs Γ ⊢ || (t : u1 · · · us , q) 7→ [σ]T || = pi , −−−−−−−−→ (ym : Sm) ∀j , i,pj = Leafnj +m _ : : Tail (False → True) Γ ⊢ || (t : Ci u1 · · · us , q) 7→ [σ]T || = Nodex(p1 · · · pn ), −−−−−−−−→ (ym : Sm) {(a : A) ∈ Γ | u occurs_in A} = −−−−−→ (z : S’) x variable fraiche Γ ⊢ || (t : q, z1 · · · zs ) 7→ [σ, u 7→ x]T || = p, −−−−→ (y : S) Γ ⊢ || (t : u, q) 7→ [σ]T || = Leafx : : p, −−−−→ (y : S), −−−−−→ (z : S’) {(a : A) ∈ Γ | t occurs_in A} = −−−−→ (z : S) x et y1 · · · ys variables fraiches abstract_all_when_possible (σ, t 7→ x, z1 7→ y1 · · · zs 7→ ys ) T = v Γ ⊢ || (t : ∅) 7→ [σ]T || = Leafx, y1 · · · ys : : Tail (v), −−−−→ (y : S) Figure 4.15 – Construction du diagonaliseur La méthode pour trouver la meilleure abstraction d’un terme suivant des termes donnés est due à Chung-Kil Hur. Le problème est le suivant : Pour u1 · · · um une liste de termes de types respectifs S1 · · · Sm et un terme t de type T, trouver t’ tel que t’ u1 · · · um = t. Le terme t’ doit être bien typé. 1 Les termes u1 · · · um doivent en outre apparaître le moins possible dans t’. Nous ne chercherons pas à qualier formellement « le moins possible ». Celui-ci dissimule en eet la caractérisation de l’expressivité du ltrage sans l’axiome K, problème fondamental que ce manuscrit ne résout pas. A l’origine de l’algorithme réside un judicieux détournement. Coq ore à l’utilisateur un mécanisme d’arguments implicites. Si une constante attend par exemple comme argument un entier n puis un Fin n, quand l’utilisateur donne l’ensemble, il donne sa taille. Le premier argument étant nécessairement cette taille, l’utilisateur n’a pas besoin de la donner explicitement, le système peut l’inférer. Le premier argument est dénissable comme implicite donc non donné par l’utilisateur et le système remplace ce "trou" par le terme adéquat. Si u de type S apparaît dans t, remplaçons toutes les occurrences de u dans t par des "trous" qui se nomment en réalité des variables existentielles. Demandons au système de résoudre ses variables existentielles. Là où u est indispensable par typage, le système va le remettre. 1. D’ailleurs, obtenir son type demande déjà du travail. 594 Du ltrage à l’analyse de cas structurellement Ailleurs, remplaçons les variables restantes par une variable y fraîche pour obtenir t’. Le terme λ(y : S) ⇒ t’ est bien typé et convertible à t quand il est appliqué à u. Nous avons obtenu une solution d’abstraction sur un terme. Pour une liste de termes la solution est similaire mais compliquée par les dépendances de type entres les termes à abstraire. Il faut en eet commencer par le dernier élément du futur télescope an qu’ensuite son type soit lui aussi généralisé selon les termes dont il dépend. La fonction abstract_all_when_possible doit donner une réponse bien typée et telles que si σ ◦ σ ′ = id (σ’ est une substitution standard des variables vers les termes) alors σ’(abstract_all_when_possible σ T) = T. Γ ⊢ (t 7→ c) ց out, x1 · · · xs Γ ⊢ t ∈ I a1 · · · am u1 · · · us Γ ⊢ I a1 · · · am ∈ ∀ −−−−→ (x : S), Set Γ ⊢ || (t : u1 · · · us ) 7→ [ε]c || = st, −−−−−−−→ (yn : Tn) Γ ⊢ st : ∀ −−−−→ (x : S) (z : I a1 · · · am x1 · · · xs ) −−−−−−−→ (yn : Tn), Set ց o Γ ⊢ (t 7→ c) ց o, y1 · · · yn Figure 4.16 – Prédicat de retour out de l’élimination de t pour obtenir c 4.8 Eléments de correction Notre algorithme génère-t-il des termes bien typés ? Nous ne pouvons pas réellement exprimer cette propriété. Nous ne sommes pas capable de donner une règle de typage primitive pour le ltrage généralisé n’impliquant pas l’axiome K. La recherche sur ce sujet est très active au moment de l’écriture de ce manuscrit mais elle n’a pas encore abouti à une caractérisation. Nous ne pouvons donc pas énoncer de propriété telle que « si le ltrage est bien typé, le terme du CCI généré par l’algorithme ci-dessus est bien typé ». Or, si l’utilisateur écrit un ltrage qui n’a pas de sens, le résultat de sa compilation sera mal-typé. Par ailleurs, notre algorithme nissant par une phase heuristique, il y a peu d’espoir de pouvoir obtenir un résultat général. Cette question n’est néanmoins pas critique. DeBruijn a introduit un principe essentiel en informatique théorique : plutôt que certier la génération de témoins de manière complexe, assurons de manière simple a posteriori la correction du témoin exhibé. Nous adoptons exactement cette démarche car le noyau de Coq (un véricateur de type du CCI) vérie le bon typage de chacun des termes que nous générons. Il n’y a pas besoin de faire conance à notre algorithme du point de vu du typage. Le contrôle du terme généré par le véricateur de type n’exonère pas de toute vérication. L’utilisateur souhaite que le comportement calculatoire de la chaîne d’analyse de cas soit celui du ltrage généralisé dont elle découle. Cette adéquation entre le terme généré et son origine est correcte si la règle de réduction donné section 2.1 est simulable sur le terme compilé au moyen de βι-réductions du CCI. Cette preuve est réalisée en deux étapes : 604.8 Eléments de correction — La simulation du ltrage par des réductions d’arbres de décision (gure 2.7). Cette preuve est identique au cas de ML traité par [38]. — La simulation des réduction d’arbres de décisions par les analyses de cas construites. Le lemme cruciale est le suivant : lorsqu’une analyse de cas supplémentaire sur l’un des arguments a été générée dans une branche pour raner son type (la situation expliquée section 4.4), cette analyse de cas va être systématiquement réduite lorsqu’elle arrive en tête. Ce lemme se prouve en raisonnant sur la forme de l’argument : l’argument a nécessairement une forme qui va réduire l’analyse de cas pour que le terme éliminé ait le bon type. Pour les autres situations, nos manipulations n’ont concerné que les annotations de types et la preuve est immédiate. Jean-François Monin avait montré l’apport d’une telle manière d’écrire des termes en Coq. Nous apportons la possibilité de les écrire automatiquement. En ce sens, cette partie constitue un pas en avant sur le chemin de la programmation certiée. 615 Simplifier un terme Écrire sans assistance un terme complexe dans un langage à types riches est une chose ardue. Des systèmes pour guider l’écriture de programmes ont donc été réalisés. Que ce soit au moyen de tactiques [21] ou d’un mode d’édition interactif [41], une fonctionnalité clé est de pouvoir écrire des termes « à trous » puis de demander au système quel doit être le type des termes à mettre dans ces trous. L’utilisateur n’a pas à fournir un terme de type syntaxiquement égal à celui attendu mais un type qui lui est convertible. Pour faciliter la compréhension, il est même souhaitable que le système n’ache pas le type qu’il a inféré pour le trou mais plutôt une forme réduite. Ce chapitre propose un algorithme pour obtenir une forme réduite d’un terme. Nous parlons de forme réduite et non de forme normale car la forme normale n’est pas le représentant le plus lisible d’une classe d’équivalence pour la conversion. En eet, pour un humain, une constante (au nom bien choisie) est plus explicite que sa dénition. Une δ-expansion ne doit avoir lieu que si elle induit d’autres réductions. Definition plus : nat → nat → nat := fix2 (pl : nat → nat → nat := λ(m n : nat) ⇒ case n predicate λ(_ : nat) ⇒ nat of |O:m |S:λ(n’ : nat) ⇒ S (pl m n’) end). Definition succ : nat → nat := plus (S O). Figure 5.1 – L’addition et le successeur De plus, dans le CCI tel qu’il est déni actuellement, lors de normalisations impliquant des points xes, déplier puis replier une constante est nécessaire. Considérons par exemple la dénition de plus donnée gure 5.1. La forme normale de plus (S (S x)) y n’est pas S (S (plus x y)) mais : S (S (fix1 (pl : nat → nat → nat := λ(m n : nat) ⇒ case m predicate λ(_ : nat) ⇒ nat of |O:n |S:λ(m’ : nat) ⇒ S (pl m’ n) end) x y)) Après une présentation de la méthode de normalisation utilisée, nous détaillerons un moyen d’obtenir la forme escomptée. 5.1 Normalisation en appel par nom Suivant les schéma de compilation usuels (voir par exemple [26, 36]), la réduction d’un terme est réalisée en le traduisant vers un langage particulier (l’évaluation), en calculant 635 Simplier un terme dans ce langage (le calcul) puis en retraduisant le résultat vers un terme (la réication). Notre langage cible est un état de machine abstraite. Un état de machine abstraite est la paire d’un terme et d’une pile où sont stockés les destructeurs de type à appliquer au terme. La syntaxe des piles est donnée par sk : := ∅ | ◦ t, sk | ZcaseT(u1 · · · us ), sk | Zx (i, (f : T := t) : : u1 · · · us ), sk ◦ t représente un argument attendant d’obtenir la fonction à laquelle il est appliqué. ZcaseT(u1 · · · us) stocke les branches d’une analyse de cas en attendant de connaître le constructeur par lequel débute le terme ltré. Zfix (i, (f : T := t) : : u1 · · · us) est un point xe attendant de savoir si son argument récursif s’évalue sur un constructeur appliqué pour se déplier. L’évaluation débute en plaçant le terme à réduire en face de la pile vide (∅). Les destructeurs de termes sont empilés. Lorsqu’un constructeur de type est atteint, la tête de la pile est inspectée pour déclencher si possible un calcul. Les règles de calcul pour la β-réduction de λ(x : T) ⇒ t sont : ◦ u, sk –[t] → (x : T) k k t[u/x] sk ∅ –[t] → (x : T) k hλ(x : T) ⇒ t | ∅i La continuation k du calcul sera la fonction d’évaluation. Pour les règles ι et ϕ, il faut extraire de la tête de pile les arguments du constructeur (les nœuds ◦ t). Nous notons t1 · · · tn⊕sk une pile constituée des nœuds applications ◦ t1 · · · ◦ tn puis de sk (ne débutant pas par une application). Les règles de calcul pour le ie constructeur Cisont t1 · · · ts ⊕ ZcaseT(u1 · · · un), sk i →k k ui (◦ t1 · · · ◦ ts , sk) t1 · · · ts⊕ i →k k v[fixj (f : T := v)/f] Zx (j, (f : T := v) : : u1 · · · uj-1), sk (◦ u1 · · · ◦ uj-1, ◦ (Ci t1 · · · ts ), sk) t1 · · · ts ⊕ ∅ i →k hCi | ◦ t1 · · · ◦ ts , ∅i Le calcul prend encore une fois sa continuation k en argument an que tous les appels de fonction dans la machine abstraite soient récursifs terminaux. L’évaluation suit les règles de réécriture de la gure 5.2. La continuation k attendue par les opérations de calculs est la vision fonctionnelle des règles d’évaluations. Formellement, k t sk = hv | sk’i si et seulement si ∆ ⊢ ht | ski ↓CBN hv | sk’i. Une fois qu’il n’y a plus de coupure en tête du terme, l’état de machine abstraite est réié pour retrouver un terme en replaçant autour de la valeur obtenue les destructeurs de termes restant. Le processus est décrit gure 5.3 Ce procédé permet d’obtenir la forme normale de tête faible d’un terme par un calcul en appel par nom. Pour obtenir la forme normale forte, il faut traverser les fonctions et les 645.1 Normalisation en appel par nom ∆ ⊢ htmi | ski i ↓CBN htmo | skoi ∆ ⊢ ht | ◦ u, ski ↓CBN hv | sk’i ∆ ⊢ ht u | ski ↓CBN hv | sk’i sk –[t] → (x : T) k hv | sk’i ∆ ⊢ hλ(x : T) ⇒ t | ski ↓CBN hv | sk’i ∆ ⊢ ht | ZcaseP(u1 · · · us ), ski ↓CBN hv | sk’i ∆ ⊢ hcase t predicate P of u1 · · · us end | ski ↓CBN hv | sk’i ∆ ⊢ hui | Zx (i, (f : T := t) : : u1 · · · ui-1), ski ↓CBN hv | sk’i ∆ ⊢ hfixi (f : T := t) | ◦ u1 · · · ◦ ui , ski ↓CBN hv | sk’i ∆ ⊢ fixi (f : T := t) | u1 · · · ui-k⊕∅ ↓CBN fixi (f : T := t) | u1 · · · ui-k⊕∅ k ≤ i ∆ ⊢ hx | ski ↓CBN hx | ski ∆ ⊢ hI | ◦ t1 · · · ◦ ts , ∅i ↓CBN hI | ◦ t1 · · · ◦ ts , ∅i ∆, (c : T := t), ∆’ ⊢ ht | ski ↓CBN hv | sk’i ∆, (c : T := t), ∆’ ⊢ hc | ski ↓CBN hv | sk’i ∆ ⊢ hS | ∅i ↓CBN hS | ∅i ∆ ⊢ h∀(x : S), T | ∅i ↓CBN h∀(x : S), T | ∅i sk i →k hv | sk’i ∆ ⊢ hCi | ski ↓CBN hv | sk’i Figure 5.2 – Call By Name abstract machine hu | ski ↑ v ht | ∅i ↑ t hcase t predicate T of u1 · · · us end | ski ↑ v ht | ZcaseT(u1 · · · us ), ski ↑ v ht u | ski ↑ v ht | ◦ u, ski ↑ v hfixi (f : T := u) t1 · · · ti-1 t | ski ↑ v ht | Zx (i, (f : T := u) : : t1 · · · ti-1), ski ↑ v Figure 5.3 – Réinterprétation d’un état comme une valeur 655 Simplier un terme produits an de normaliser leur corps puis appliquer récursivement le même processus aux termes qui apparaissent dans les éléments de la pile avant de réaliser la réication. Notre machine est inecace car elle réalise les substitutions une par une au lieu d’utiliser un environnement. Cette machine avec des environnements est une machine de Krivine [33] ou plutôt une machine de Krivine avec types algébriques [6] puisqu’elle manipule des inductifs. Nous la présenterons section 5.3. Avant cela, traitons le cœur de notre contribution, les repliages de constante. 5.2 Trace des constantes dépliées Nous ajoutons aux états de machine de la section précédente une liste des constantes dé- pliées convertibles au terme de l’état. Cette liste va permettre de savoir quelle constante replier. Nous utilisons une liste car nous souhaitons traiter ce que nous nommons une cascade de constantes. Il s’agit d’une situation où une constante est dénie grâce à une autre constante. Par exemple, nombre de fonctions (telles que incr_ids gure 5.1) sur les listes (celle du langage dénie gure 1.11) sont dénies grâce aux itérateurs sur les listes (comme list_map) qui eux sont dénis par point xe et analyse de cas . Definition list_map (A B : Set) (f : A → B) : list A → list B := fix1 (map : list A → list B := λ(l : list A) ⇒ case l predicate λ(_ : list A) ⇒ list B of |nil:nil B |cons:λ(h : A) (t : list A) ⇒ cons (f h) (map t) end). Definition incr_ids : list nat → list nat := list_map nat nat succ. Figure 5.4 – Exemple d’itérateur et d’une de ses instances Formellement, un dépliage est un triplet constitué d’un nom de constante et de deux listes de termes appelées les paramètres et les arguments. Une liste de dépliage p est un repliage du terme t noté t p si pour tous ses éléments la constante appliquée aux paramètres est convertible à t appliqué aux arguments. Le point xe pl a pour dépliage (plus,[],[]) qui n’a ni argument ni paramètre mais on comprend le sens des paramètres pour donner un dépliage du point xe map : (list_map,[S, T, t],[]) (avec S, T et t les valeurs de A, B et f dans le cas considéré). L’intérêt des arguments est illustré par : pl a pour dépliage alternatif (succ,[],[S O]) Les primitives dont nous avons besoin sur les listes de dépliages sont dénies telles que — Si t u p alors t add_arg u p. — Pour u donné, si λ(x : T) ⇒ t p et pour tout (c,params,args) ∈ p, on a soit (args = u, _) soit (args = ∅), alors t[u/x] add_param u p. — Si c p et ∆(c) = t alors t add_cst c p. 665.2 Trace des constantes dépliées par (** val add_arg : term → cst_stk → cst_stk *) let add_arg arg = List.map (fun (a,b,c) → (a,b,c @ [arg])) (** val add_param : term → cst_stk → cst_stk *) let add_param param p = List.map (fun (a,b,c) → match c with |[] → (a,b @ [param],c) |_ : :q → (a,b,q)) p (** val add_cst : cst → cst_stk → cst_stk *) let add_cst cst p = (c,[],[]) : : p Les noeuds de la pile qui détruisent un inductif sont modiés. Une liste de dépliage est ajoutée. Elle représente un repliage de la réication du terme et de la pile jusqu’à ce noeud inclus. Il existe une fonction eacement triviale qui permet de retrouver une pile de machine appel par nom à partir d’une pile avec les traces en supprimant ces annotations. sk : := ∅ | ◦ t, sk | ZcaseT(u1 · · · us/p), sk | Zx (i, (f : T := t)/p : : u1 · · · us ), sk Les étapes de calcul et d’évaluation (gure 5.5) sont modiées de telle sorte à maintenir un repliage du terme de l’état de la machine. Nous nommons RN cette nouvelle machine. L’évaluation enregistre aussi les repliages des destructeurs d’inductif lorsqu’elle les empile. ◦ u, sk p –[t] → (x : T) k k (add_param u p) (t[u/x]) sk ∅ p –[t] → (x : T) k hλ(x : T) ⇒ t | ∅i Maintenant que la machinerie est en place, le calcul sur les inductifs et la réication peuvent en tirer avantage. Pour cela, nous dénissons la notion de meilleur repliage. Lors du calcul de succ (S m), le repliage du point xe à l’intérieur de sa dénition est [(plus,[],[]) ;(succ,[],[S O])]. La constante dépliée en premier, le premier élément de la cascade, est en fond de repliage. Nous voulons l’utiliser autant que possible pour remplacer le terme déplié. C’est possible si le terme à replier est appliqué aux arguments du dépliage (c’est bon pour succ si le premier argument de pl est S O). Si ce n’est pas le cas, nous essayons avec le dépliage suivant (plus dans notre exemple). Les fonctions qui choisissent le meilleur repliage sont refold_term et refold_state. La fonction refold_term travaille comme une substitution qui regarde les arguments de la variable à substituer pour choisir par quoi substituer. La fonction refold_state travaille elle sur un état de machine abstraite. Elle inspecte les termes en tête de pile pour choisir par quoi elle va remplacer le terme. Par construction, le nombre d’arguments des dépliages dans un repliage est une fonction croissante. Un dépliage n’ayant pas d’argument peut toujours être utilisé car il n’y a alors aucune condition sur le contexte. Nous ne conservons donc en pratique qu’un seul dépliage sans argument en tête du dépliage. Lors du calcul de incr_ids (cons x y), le repliage du point xe est [(map_list, [nat;nat;succ], []) ;(incr_ids,[],[])] mais nous ne gardons que [(incr_ids,[],[])] qui est toujours utilisable. Lors du dépliage d’un point xe, le meilleur repliage du point xe est utilisé dans la substitution plutôt que la dénition du point xe. 675 Simplier un terme ∆ ⊢p htmi | ski i ↓RN htmo | skoi s p –[t] → (x : T) k hv | s’i ∆ ⊢p hλ(x : T) ⇒ t | si ↓RN hv | s’i ∆ ⊢add_arg u p ht | ◦ u, si ↓RN hv | s’i ∆ ⊢p ht u | si ↓RN hv | s’i ∆ ⊢p h∀(x : S), T | ∅i ↓RN h∀(x : S), T | ∅i sk i →k hv | sk’i ∆ ⊢p hCi | ski ↓RN hv | sk’i ∆ ⊢∅ t | ZcaseT(u1 · · · us/p), sk ↓RN hv | sk’i ∆ ⊢p hcase t predicate T of u1 · · · us end | ski ↓RN hv | sk’i ∆ ⊢∅ ui | Zx (i, (f : T := t)/p : : u1 · · · ui-1), sk ↓RN hv | sk’i ∆ ⊢p hfixi (f : T := t) | ◦ u1 · · · ◦ ui , ski ↓RN hv | sk’i ∆ ⊢p fixi (f : T := t) | u1 · · · ui-k⊕∅ ↓RN fixi (f : T := t) | u1 · · · ui-k⊕∅ ∆ ⊢p hx | ski ↓RN hx | ski ∆ ⊢p hI | ◦ t1 · · · ◦ ts , ∅i ↓RN hI | ◦ t1 · · · ◦ ts , ∅i ∆, (c : T := t), ∆’ ⊢add_cst c p ht | ski ↓RN hv | sk’i ∆, (c : T := t), ∆’ ⊢p hc | ski ↓RN hv | sk’i ∆ ⊢p hs | ∅i ↓RN hs | ∅i Figure 5.5 – Refoldant Call By Name abstract machine 685.3 Refolding Algebraic Krivine Abstract Machine t1 · · · ts ⊕ ZcaseT(u1 · · · us/p), sk i →k k ∅ ui (◦ t1 · · · ◦ ts , sk) t1 · · · ts⊕ i →k k ∅ v[refold_term p/f] Zx (j, (f : T := v)/p : : u1 · · · uj-1), sk (◦ u1 · · · ◦ uj-1, ◦ (Ci t1 · · · ts ), sk) t1 · · · ts ⊕ ∅ i →k hCi | ◦ t1 · · · ◦ ts , ∅i Lorsqu’un éliminateur d’inductif est replié, le meilleur repliage est utilisé plutôt que la construction elle-même (gure 5.6). hu | ski ↑ v ht | ∅i ↑ t refold_state p (case t predicate T of u1 · · · us end) | sk ↑ v t | ZcaseT(u1 · · · us/p), sk ↑ v ht u | ski ↑ v ht | ◦ u, ski ↑ v refold_state p (fixi (f : T := u) t1 · · · ti-1 t) | sk ↑ v t | Zx (i, (f : T := u)/p : : t1 · · · ti-1), sk ↑ v Figure 5.6 – Réication du repliage d’une valeur La correction de notre machine est garantie par le théorème : Pour tout terme t et toute pile de machine sk, si ∆ ⊢p ht | ski ↓RN hv | si, t p et ∆ ⊢ ht | eacement(sk)i ↓CBN hv’ | s’i alors ∆ ⊢ v 7→βδ v’ et les termes apparaissant dans l’eacement de s se réduisent modulo βδ vers le terme à la même place dans s’. Toutes les réductions ι et ϕ possibles ont été réalisées. 5.3 Refolding Algebraic Krivine Abstract Machine La machine présentée jusqu’ici fonctionne mais elle est inecace. Elle est calculatoirement inecace comme nous l’avons déjà remarqué section 5.1. Pire, sa capacité à réaliser les repliages est limitée. Ces deux sous-optimalitées se corrigent en améliorant les substitutions. Pour comprendre le problème avec les repliages, revenons sur l’exemple succ (S m). Le système répond S (plus (S O) n) et non S (succ n) car le dépliage du point xe a lieu avant la substitution de m par S O dans le corps du point xe. L’argument de l’appel récursif au moment de la substitution ne correspond pas à l’argument demandé pour replier par succ, ce choix est donc éliminé. D’autre part, en repliant par la meilleure constante à chaque fois, les δ-réductions ont lieu à chaque fois. Lors de la réduction de plus m (S (S n)), la constante plus est dépliée deux fois. En retardant la substitution, les alternatives peuvent toutes deux être conservées an que dans un calcul, le point xe soit utilisé et que durant la réication, la constante donne un terme concis. Nous modions notre machine pour qu’elle manipule non plus des termes mais des clô- tures, c’est-à- dire des paires (terme, substitution). La grammaire des substitutions est constituée de trois types de noeuds, le premier pour les termes non évalués, le deuxième pour les constructeurs déjà calculés (car ils sont l’argument 695 Simplier un terme récursif d’un point xe) et le troisième pour les points xes dépliés qui stockent la cascade de constantes dont ils sont issus. σ : := ∅ |  x := Sapp σ’(t), σ | ( x := Scstrj σ1(t1) · · · σs (ts ), σ ) | {x := Sxi σ’(f : T := t)/cst, σ } La pile est modiée car tous les termes deviennent des clôtures. Comme dans les substitutions, un noeud particulier est ajouté pour des valeurs déjà calculées. Une fois réduit sur un constructeur, l’argument récursif d’un point xe doit en eet être réempilé an de procéder au dépliage du point xe. La fonction l⊕sk doit maintenant aussi extraire ces noeuds spéciaux. Remarque Avec des valeurs qui sont des clôtures et non plus des termes, un comportement remarquable de la machine apparaît. Le calcul de l’argument récursif pour autoriser le dé- pliage d’un point xe introduit de l’appel par valeur au sein de notre machine en appel par nom. Avant d’avoir des substitutions, nous réions implicitement cette valeur avant de la remettre dans la pile. sk : := ∅ | ◦ σ(t), sk | ZcaseT(σ(u1 · · · us )/cst), sk | Zx (i, σ(f : T := t)/cst : : σ1(u1) · · · σi-1(ui-1)), sk | Zcstri σ1(t1) · · · σs (ts ), sk Les repliages ne sont pas profondément diérents hormis qu’ils manipulent des clôtures. (** val add_arg : term → subst → cst_stk → cst_stk *) let add_arg arg sigma p = List.map (fun (a,b,c) → (a,b,c @ [arg, sigma])) p (** val add_param : term → subst → cst_stk → cst_stk *) let add_param param sigma p = List.map (fun (a,b,c) → match c with |[] → (a,b @ [param, sigma],c) |_ : :q → (a,b,q)) p (** val add_cst : cst → cst_stk → cst_stk *) let add_cst cst p = (c,[],[]) : : p Le calcul ne fait plus de substitution, il enrichit la substitution de la clôture. Les règles de réécriture sont moins claires du fait des clôtures mais seul change réellement le fait d’interroger la substitution quand une variable est atteinte. A la n de l’évaluation, il faut retourner d’une clôture à un terme en appliquant eectivement la substitution avant de réier l’état de la machine. La propagation d’une substitution σ dans un terme t pour obtenir u est notée u ⋉ σ. Cette nouvelle machine est meilleure que la précédente si elle réalise plus de repliage tout en calculant toujours toutes les ϕ expansions et les ι réductions possibles. Le théorème le garantissant serait qu’en appliquant les substitutions à la sortie de la machine, on ait un terme qui se βδ réduise sur la sortie de la machine appel par nom avec repliage. 5.4 Configurabilité Trouver la manière optimale de réduire une constante n’est pas du ressort d’un ordinateur car la notion elle-même n’est pas dénie. Certaines constantes masquent des preuves sans 705.4 Congurabilité ◦ σ(u), sk p –[t] σ’ → (x : T) k k (add_param u σ p) t (  x := Sapp σ(u), σ’ ) sk Zcstri σ1(t1) · · · σs (ts ), sk ∅ –[t] σ→ (x : T) k k ∅ t ({x := Scstri σ1(t1) · · · σs (ts ), σ }) sk ∅ p –[t] σ→ (x : T) k hσ(λ(x : T) ⇒ t) | ∅i σ1(t1) · · · σs (ts ) ⊕ ZcaseT(σ(u1 · · · us )/p), sk i →k k ∅ ui σ (◦ σ1(t1) · · · ◦ σs (ts ), sk) σ1(t1) · · · σs (ts )⊕ i →k k ∅ v ( ( f := Sxj σ(f : T := v)/p, σ ) ) Zx (j, σ(f : T := v)/p : : σ’1(u1) · · · σ’j-1(uj-1)), (σ’1(u1) · · · σ’j-1(uj-1), sk Zcstri σ1(t1) · · · σs (ts ), sk) σ1(t1) · · · σs (ts ) ⊕ ∅ i →k hCi | σ1(t1) · · · σs (ts ), ∅i contenu calculatoire et qu’en général on ne souhaite pas déplier. Certaines constantes sont des applications partielles d’autres constantes que l’on ne souhaite déplier que si elles ont elles-même un nombre susant d’arguments pour poursuivre des calculs. Enn les constantes représentant des point xes construits non pas à partir d’une analyse de cas élémentaire sur leur argument récursif mais à l’aide d’un ltrage complexe ne doivent se déplier que si les arguments permettent d’atteindre une feuille de l’arbre de décision du ltrage et non pas uniquement si l’argument récursif commence par un constructeur. D’autres situations sont imaginables. Bref, il faut orir à l’utilisateur de congurer pour chaque constante globale son comportement vis à vis du dépliage. Notre machine peut en tout cas comprendre ces directives : — Ne jamais se déplier, c’est ne pas se déplier ! — Ne pas se replier, c’est ne pas être mis dans la trace des constantes dépliées. — Contrôler le nombre d’arguments, c’est compter le nombre de noeuds ◦ t en tête de pile. — Nous savons déjà geler le dépliage d’un point xe en attendant de savoir si son argument récursif se réduit sur un constructeur. Nous pouvons similairement ajouter le nécessaire pour réduire les arguments d’une constante an de contrôler s’ils permettent d’atteindre une feuille d’un arbre de décision donné. En pratique, une table stockant les arbres de décision sous-jacents pour toutes les constantes est dénie. Elle est interrogée lorsque le terme de l’état de la machine est une constante. Le premier argument sur lequel travaille l’arbre de décision est placé en tête de machine et on empile un noeud Zconst (cst, arg1 · · · args , split_tree) qui stocke la constante, les arguments déjà traités et l’arbre de décision qui reste à parcourir. Le calcul dans le cas des constructeurs est enn étendu pour gérer ces noeuds Zconst (cst, arg1 · · · args , st). Si l’arbre de décision restant à considérer (st) est vide, la constante cst’ est eectivement dépliée. Sinon, le prochain argument argsk qu’il faut évaluer est mis en tête. 715 Simplier un terme ∆ ⊢p hσ(tmi ) | ski i ↓RK hσ’(tmo) | skoi ∆ ⊢add_arg u σ p hσ(t) | ◦ σ(u), ski ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(t u) | ski ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(s) | ∅i ↓RK hσ(s) | ∅i ∆ ⊢p hσ(∀(x : S), T) | ∅i ↓RK hσ(∀(x : S), T) | ∅i ∆ ⊢∅ σ(t) | ZcaseT(σ(u1 · · · us )/p), sk ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(case t predicate T of u1 · · · us end) | ski ↓RK hσ’(v) | sk’i sk i →k hσ’(v) | sk’i ∆ ⊢p hσ(Ci ) | ski ↓RK hσ’(v) | sk’i skp –[t] σ→ (x : T) k hσ’(v) | sk’i ∆ ⊢p hσ(λ(x : T) ⇒ t) | ski ↓RK hσ’(v) | sk’i ∆ ⊢∅ σi (ui ) | Zx (i, σ(f : T := t)/p : : σ1(u1) · · · σi-1(ui-1)), sk ↓RK hσ’(v) | sk’i ∆ ⊢p hσ(fixi (f : T := t)) | ◦ σ1(u1) · · · ◦ σi (ui ), ski ↓RK hσ’(v) | sk’i sk = ◦ σ1(u1) · · · ◦ σi-k(ui-k), ∅ ∆ ⊢p hσ(fixi (f : T := t)) | ski ↓RK hσ(fixi (f : T := t)) | ski ∆ ⊢p hσ(t) | ski ↓RK hσ’(v) | sk’i ∆ ⊢p (σ”,  x := Sapp σ(t), σ”’ )(x) | sk ↓RK hσ’(v) | sk’i (◦ σ1(u)1 · · · ◦ σs (u) s , sk) i →k hσ’(v) | sk’i ∆ ⊢p’ h(σ”, {x := Scstri σ1(u1) · · · σs (us ), σ”’})(x) | ski ↓RK hσ’(v) | sk’i ∆ ⊢p D σ(fixj (f : T := t)) | skE ↓RK hσ’(v) | sk’i ∆ ⊢p D (σ”, ( x := Sxj σ(f : T := t)/p’, σ”’) )(x) | skE ↓RK hσ’(v) | sk’i ∆ ⊢p σ(I) | ◦ σ1(t)1 · · · ◦ σs (t) s , ∅ ↓RK σ(I) | ◦ σ1(t)1 · · · ◦ σs (t) s , ∅ ∆, (c : T := t), ∆’ ⊢add_cst c p h∅(t) | ski ↓RK hσ’(v) | sk’i ∆, (c : T := t), ∆’ ⊢p hσ(c) | ski ↓RK hσ’(v) | sk’i Figure 5.7 – Refoldant Krivine Abstract Machine 725.5 Discussion 5.5 Discussion La congurabilité ne sut pas à orir toutes les possibilités. Dans notre implantation, certains choix sont codés en dur, d’autres sont impossibles. Nous les discutons ici. Cascade de constante Il existe des systèmes logiques comme Agda [14] ou Matita [1] dont les points xes sont « génératifs ». Les points xes n’y sont pas des objets locaux mais des constantes globales capables de s’appeler elles-mêmes. Le problème des repliages est alors bien moins critique. Par contre, dans le cas d’une constante dénie comme list_map appliquée à une fonction particulière, exprimer les appels récursifs en fonction de cette constante plutôt que de l’itérateur est un gain. Notre système est donc plus qu’une simulation du cas génératif en présence de cascade de constantes. Pour autant, la réponse apportée n’est pas idéale. Elle est extrêmement sensible à la syntaxe et suppose une expertise de l’utilisateur an d’être exploitable. Un simple échange d’argument et le système est perdu. Par exemple, en dénissant plus par récurrence sur son premier argument puis succ m par plus m (S O), l’information conservée au cours de la réduction de succ (S n) est que pl (S n) (S O) est repliable en succ (S n), ce qui est vrai mais inutile. Le résultat obtenu est alors seulement S (plus n (S O)). Points fixes mutuels Nous n’en avons pas parlé car ils ne changeaient jusqu’ici rien à notre étude mais Coq ore la possibilité de dénir des types de donnée et des points xes mutuellement récursifs. La machine abstraite ne conserve que les noms des constantes qu’elle a dépliées au cours de la réduction. Il n’y a donc aucun moyen direct de connaître le nom de la constante globale qui correspond à un appel récursif à un autre point xe du paquet ! Replier ou réduire Les constantes dénies à partir de list_map sont toujours convenablement repliables car la fonction est un paramètre de la dénition. Dans le cas de list_fold, par contre, l’accumulateur évolue et les appels récursifs ne s’expriment pas forcément en fonction de la première constante. Nous choisissons de privilégier la réduction (et donc le repliage utilisant list_fold) sur la conservation de la constante haut niveau. L’autre choix peut avoir des usages. Contrôler le nombre de dépliages Supposons qu’un utilisateur ait un type impliquant plus n (S (S O)) qu’il souhaite exprimer en fonction de plus n (S O) et non n. Il ne peut ni dire de ne pas déplier plus ni se contenter d’en autoriser le dépliage. Il lui faut un moyen d’autoriser un unique dépliage. L’implantation eective permet ce comportement en ranant le moment où elle autorise certaines réductions. 736 Etablir qu’un point fixe ne produit pas de calcul infini Prenons le point xe fix1 (f : ∀(n : nat), False := λ(n : nat) ⇒ f O). D’après les règles de la gure 1.9 section 1.4, si on oublie la condition Decr, ce terme du CCI est bien typé. Pourtant, f (S O), par exemple, est une preuve close de False. Ainsi, pour toute proposition logique P, il existe une preuve de P (cf gure 3.6). Cette preuve est case (fix1 (f : ∀(n : nat), False := f O)) (S O) predicate λ(_ : False) ⇒ P of end. Le programmeur n’est pas plus satisfait que le mathématicien. Ce point xe n’est pas autre chose qu’une boucle innie qui ne répondra jamais de valeur. Toutes les garanties que nous souhaitons apporter sur les preuves/programmes s’écroulent donc si nous ne nous assurons pas que la réduction des point xes termine. C’est justement le rôle du jugement qui demande, dans l’exemple, Decr(∆,λ(n : nat) ⇒ f O,f,1) (La syntaxe qui nous allons introduire est ∆ ;{f := STRICT, ∅} # 1 f hλ(n : nat) ⇒ f O | ARGi). Son objectif est d’imposer la terminaison par décroissance structurelle de f suivant son 1 er argument. Un point xe dont le corps vérie cette propriété est dit gardé. Ce chapitre décrit comment le jugement de garde est déni. Partant du principe de base de décroissance structurelle, nous introduirons une à une quelques subtilités permettant de traiter un nombre toujours plus grand de cas de décroissance structurelle. Les premiers ra- nements, qui concernent les branches impossibles ou les points-xes imbriqués, existent dans Coq depuis le travail de Gimenez [23]. Nous introduirons et justierons ensuite les nouveaux ranements suivants : propagation des conditions de décroissance à travers les coupures entrelacées, propagation des conditions de décroissance à travers les βιϕ-rédex garantissant la réduction forte, prise en compte de questions d’ecacité. 6.1 Décroissance structurelle Les points xes ont été introduits en CCI an de manipuler les structures de données ré- cursives. Ils ne permettent que cela. La construction d’un point xe est structurée autour d’un argument de type inductif explicitement nommé. Il est appelé argument récursif. L’argument i dans fixi (f : T := t) est le numéro de l’argument récursif. Le principe de la garantie de terminaison des points xes est : A chaque dépliage d’un point xe, au moins un des constructeurs de tête de l’argument récursif est consommé . 756 Etablir qu’un point xe ne produit pas de calcul inni Par exemple, un point xe f appliqué à S (S O) ne peut faire des appels récursifs qu’à f (S O) ou f O. Il consomme un ou deux constructeurs. La description de l’algorithme qui assure que l’argument récursif d’un point xe décroît structurellement repose sur les concepts énumérés ici. La vérication de la propriété se base sur une classication des variables libres apparaissant dans la dénition du corps du point xe. NO signie que la variable n’est pas sous-terme de l’argument récursif. STRICT signie qu’elle est sous terme de l’argument récursif. ARG qu’elle est l’argument récursif lui-même. La catégorie à laquelle appartient chaque variable libre est stockée au sein d’un environnement que nous noterons Ψ. L’environnement ∆ contient lui les dénitions des constantes globales. Deux phases distinctes se succèdent. D’abord ∆ ;Ψ # i f ht | πi , le jugement principal, parcourt un terme t (le corps du point xe) à la recherche des appels récursifs à f pour les vérier. Cette tâche comporte deux aspects : — Quand un lieur est traversé, le statut de sous-terme de la nouvelle variable libre introduite est déterminé et mémorisé dans l’environnement. — Quand un appel récursif à f est atteint, son i-ième argument est contrôlé. Le second jugement vérie que ce terme est sous-terme. Il utilise pour cela les valeurs de sousterme des variables libres collectées dans l’environnement au fur et à mesure du parcours du corps du point xe. ∆ ;Ψ ⋄ ht | πi = spec donne la spécication de sous-terme spec d’un terme t (l’argument en position récursive d’un appel récursif) grâce aux spécications de sous-terme de ses variables libres. Ce jugement est appelé par le premier à chaque fois qu’il atteint un appel récursif. Calculer une valeur de sous-terme Le dernier argument (π) des jugements est une pile. Comme une pile de machine abstraite, elle donne la valeur des variables correspondant aux lieurs en tête du terme à inspecter. La diérence est que c’est ici une valeur de sous-terme et non un terme qui est associé à une variable. En réalité, le deuxième jugement décrit gure 6.1 est eectivement une machine abstraite pour la β-réduction en appel par valeur. Il s’agit d’une machine qui calcule des spécications de sous-terme. Le premier jugement embarque cette machine abstraite an de lancer des calculs avec un environnement correct. Ces machines ont une règle particulière : ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ t1 | renforce1(c)1 · · · renforce1(c)s = o1 · · · ∆ ;Ψ ⋄ tn | renforcen(c)1 · · · renforcen(c)s = on Yn k = 1ok = o ∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o 766.1 Décroissance structurelle ∆ ;Ψ ⋄ ht | πi = out ∆ ;Ψ ⋄ hx | πi = Ψ(x) ∆ ;Ψ ⋄ h∆(c) | πi = o ∆ ;Ψ ⋄ hc | πi = o ∆ ;Ψ ⋄ hs | ∅i = NO ∆ ;{x := s, Ψ} ⋄ ht | πi = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | s, πi = out ∆ ;{x := NO, Ψ} ⋄ ht | ∅i = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | ∅i = out ∆ ;Ψ ⋄ hu | ∅i = s ∆ ;Ψ ⋄ ht | s, πi = out ∆ ;Ψ ⋄ ht u | πi = out ∆ ;Ψ ⋄ h∀(x : S), T | ∅i = NO ∆ ;Ψ ⋄ hC | πi = NO ∆ ;Ψ ⋄ hI | πi = NO ∆ ;  g := NO, Ψ ⋄ t | NO1 · · · NOk = o ∆ ;Ψ ⋄ D fixj (g : T := t) | s1 · · · sk E = o ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ t1 | renforce1(c)1 · · · renforce1(c)s = o1 · · · ∆ ;Ψ ⋄ tn | renforcen(c)1 · · · renforcen(c)s = on Yn k = 1ok = o ∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o Figure 6.1 – Calcul de la spécication de sous terme d’un terme 776 Etablir qu’un point xe ne produit pas de calcul inni Cette règle est la clé de voûte de la garantie de la terminaison. Elle utilise deux fonctions sur les valeurs de sous-terme à expliquer. — Nous souhaitons que n soit un sous-terme si t de type nat est l’argument récursif ou déjà un sous-terme dans case t predicate λ(m : nat) ⇒ T of |O:a |S:λ(n : nat) ⇒ b end. Plus génériquement, la spécication STRICT est assignée aux variables représentant les arguments des constructeurs dans les branche lorsque le terme ltré a la spécication ARG. Pas à toutes les variables, si le terme ltré a le type I t1 · · · ts , uniquement aux variables de type ∀ −−−−→ (x : S), I u1 · · · us . Les autres ont la spécication NO. En eet, le CCI autorise la dénition de constructeurs dont le type est polymorphe comme par exemple Inductive I : Set := | C :(∀(P : Set), P → P) → I. La condition sur les types des arguments du constructeur est donc indispensable an que ne puisse pas être admise la dénition non terminante : Definition Paradox : False := (fix1 (ni : I → False := λ(i : I) ⇒ case i predicate λ(_ : I) ⇒ False of |C:λ(f : ∀ (P : Set) , P → P) ⇒ ni (f _ i) end)) (C (λ(P : Set) (x : P) ⇒ x)). Formellement, la description de la machine utilise une fonction qui donne la caractéristique de sous-terme des arguments d’un constructeur "du bon type" dans une branche en fonction de la caractéristique de sous-terme de l’objet ltré. Sa spécication est bien plus complexe que sa dénition car il s’agit de dire renforcei (NO) = NO1 · · · NOs et renforcei (ARG) = STRICT1 · · · STRICTs pour les arguments de Ci non polymorphes (NO1 · · · NOs sinon). renforcei (STRICT) = STRICT1 · · · STRICTs — L’autre problématique est de fusionner les valeurs de sous-terme de chacune des branches an de répondre la valeur de sous-terme de l’ensemble d’une analyse de cas. C’est objet de l’opération × dénie gure 6.2. Cette opération se doit d’être associative commutative an de ne pas être inuencée par l’ordre des branches. L’assistant de preuve de votre choix le garantit très facilement. Il faut de plus une caractéristique pour l’analyse de cas à zéro cas. Un inductif à zéro cas ne pouvant jamais être construit dans un contexte cohérent, son élimination ne peut avoir lieu que dans des cas d’absurdité, c’est-à-dire dans du code mort. Nous introduisons donc une spécication de sous-terme DEAD qui caractérise du code mort et qui est l’élément absorbant de l’opération ×. Une analyse de cas qui analyse du code mort est nécessairement du code mort. Il est donc admissible de faire un appel récursif sur un terme de spécication DEAD. Il n’arrivera en eet pas ! De même, renforcei (DEAD) = DEAD1 · · · DEADs , une analyse de cas de code mort a des branches qui sont du code mort donc jamais les arguments des constructeurs ne seront habités. Il ne reste alors plus qu’à donner le premier jugement, celui qui fait le contrôle des appels récursifs, dans la gure 6.3. La garantie de la terminaison de l’évaluation de fixi (f : T := t) est 786.2 Ranement lié à l’induction × STRICT ARG DEAD NO NO NO NO NO NO DEAD STRICT ARG DEAD ARG ARG ARG STRICT STRICT Figure 6.2 – Fusion de la valeur de sous termes de deux branches le jugement ∆ ;{f := NO, ∅} # i f ht | ∅i. La correction de cette condition de garde a été démontrée par Eduardo Gimenez [23] grâce à un algorithme qui, pour tout point xe dénissable dans ce système, dénit un inductif dont le principe de récurrence simule le point xe. Retour sur les branches impossibles d’une analyse de cas Nous sommes à présent en pleine mesure de comprendre la section 4.6. Si v est l’argument récursif, quelle est la valeur de sous-terme de Vhd v ? L’astuce est que, grâce aux constructions que nous venons de faire, False_rect a la spéci- cation de sous-terme DEAD. La branche impossible de nil n’est donc pas un handicap au fait que la spécication du code suivant soit bien STRICT : case v predicate diag of |nil:False_rect True |cons:λ(n : nat) (h : A) (t : vect A n) ⇒ h end 6.2 Rainement lié à l’induction Dans le corps t d’un point xe f peut apparaître la dénition d’un autre point xe g. On parle alors de points xes imbriqués. La garde des point xes imbriqués n’est pas contrôlée simultanément. D’abord, t est typé. Comme la dénition de g est dans t, le fait que g est gardé est contrôlé durant cette phase. Ensuite, on vérie la terminaison de f et seulement de f. Par contre, durant la vérication de f, g apparaît bel et bien. Il faut alors attribuer une valeur de sous-terme à g. Il faut de même attribuer une valeur de sous-terme à f. La prudence dicte que la spécication de sous-terme de f et g soit NO. De même, ce n’est pas parce que le ie argument de g est un STRICT quand f appelle g que le ie argument de g lors d’un appel récursif dans la dénition de g restera un argument de spécication STRICT. Il est donc indispensable que tous les arguments de g aient la spécication NO. Voilà justiée la règle ∆ ;Ψ # i f hT | ∅i ∆ ;  g := NO, Ψ # i f t | NO1 · · · NOk ∆ ;Ψ # i f D fixj (g : T := t) | s1 · · · sk E et l’appel initial ∆ ;{f := NO, ∅} # i f ht | ∅i. 796 Etablir qu’un point xe ne produit pas de calcul inni ∆ ;Ψ # i f ht | πi ∆ ;Ψ # i f hx | πi ∆ ;Ψ # i f hI | πi ∆ ;Ψ # i f hS | ∅i ∆ ;{x := s, Ψ} # i f ht | πi ∆ ;Ψ # i f hλ(x : S) ⇒ t | s, πi ∆ ;Ψ # i f hs | ∅i ∆ ;Ψ # i f hC | πi ∆ ;Ψ # i f hS | ∅i ∆ ;{x := NO, Ψ} # i f ht | ∅i ∆ ;Ψ # i f hλ(x : S) ⇒ t | ∅i ∆ ;Ψ # i f hu | ∅i ∆ ;Ψ ⋄ hu | ∅i = s ∆ ;Ψ # i f ht | s, πi ∆ ;Ψ # i f ht u | πi ∆ ;Ψ # i f hc | πi si = STRICT ∨ si = DEAD ∆ ;Ψ # i f f | s1 · · · sk ∆ ;Ψ # i f hS | ∅i ∆ ;{x := NO, Ψ} # i f hT | ∅i ∆ ;Ψ # i f h∀(x : S), T | ∅i ∆ ;Ψ # i f hT | ∅i ∆ ;  g := NO, Ψ # i f t | NO1 · · · NOk ∆ ;Ψ # i f D fixj (g : T := t) | s1 · · · sk E ∆ ;Ψ # i f hu | ∅i ∆ ;Ψ # i f hT | ∅i ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ # i f ht1 | renforce1(c)i · · · ∆ ;Ψ # i f htn | renforcen(c)i ∆ ;Ψ # i f hcase u predicate T of t1 · · · tn end | πi Figure 6.3 – Contrôle de la décroissance structurelle de f selon son i-ème argument. 806.3 Ranement lié aux coupures entrelacées Pourtant, deux considérations peuvent améliorer l’expressivité : 1. Même si les arguments de g en général peuvent devenir complètement quelconques au fur et à mesure des appels récursifs, l’argument récursif a lui l’obligation de décroître. Ainsi, si g est appelé avec un argument STRICT en position récursive, cet argument ne peut que rapetisser lors d’appels récursifs et rester donc forcément STRICT. La pile des arguments peut ne pas être complètement réinitialisée ; l’argument récursif a le droit de garder sa valeur. 2. Les variables représentant les points xes peuvent avoir la spécication STRICT. Il y a alors une forme de raisonnement par récurrence : Pour calculer si l’ensemble de la dénition d’un point xe est sous-terme, supposons que les appels récursifs qui apparaissent dans cette dénition sont sous-terme. La règle implémentée est donc ∆ ;Ψ # i f hT | ∅i ∆ ;  g := STRICT, Ψ # i f D t | NO1 · · · NOj-1, sj , NO1 · · · NOk-jE ∆ ;Ψ # i f D fixj (g : T := t) | s1 · · · sk E et l’appel initial ∆ ;{f := STRICT, ∅} # i f ht | ∅i. Cette optimisation est présente dans les versions précédant la version 8.4 de Coq. La condition de garde jusque la version 8.3 de Coq est strictement composée des règles présentées jusqu’ici appliquées à la forme normale du corps du point xe. Nous abordons maintenant les ranements postérieurs qui constituent la contribution originale de ce manuscrit. 6.3 Rainement lié aux coupures entrelacées Le chapitre 4 a montré que les coupures entrelacées étaient essentielles à l’écriture d’analyse de cas dépendant. La contre-partie regrettable est que sont perdues en chemin les valeurs de sous-terme des arguments de l’analyse de cas. Avec les jugements des gures 6.3 et 6.1 fix1 (f : . . . := λ(x : nat) ⇒ . . . case . . . predicate . . . of . . . |λ(. . . : . . .) (x’ : nat) ⇒ f (pred x’) . . . end x . . .) est refusé car x’ n’est pas vu comme ARG. Une solution de contournement est simple. La pile des arguments construite avant d’atteindre une analyse de cas est transmise à chacune des branches de cette analyse de cas. Néanmoins, cette manoeuvre est mal typée. Les branches impossibles peuvent donc ne pas être en adéquation avec leur pile. Un invariant ne tient plus. La pile en regard d’un produit ou d’une sorte n’est plus forcément vide. La règle qui assure la terminaison d’une analyse de cas devient ∆ ;Ψ # i f hu | ∅i ∆ ;Ψ # i f hT | ∅i ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ # i f ht1 | renforce1(c), πi · · · ∆ ;Ψ # i f htn | renforcen(c), πi ∆ ;Ψ # i f hcase u predicate T of t1 · · · tn end | πi 816 Etablir qu’un point xe ne produit pas de calcul inni An de gérer la terminaison des branches impossibles (et donc d’un type incompatible avec la pile qui leur est présentée), nous modions les règles à propos des constructeurs de type (sorte et produit) pour qu’elles acceptent une pile : ∆ ;Ψ # i f hs | πi 6.4 Rainement lié à la réduction 6.4.1 Garder la forme βιδ normale Pour partager du code en utilisant par exemple des constantes globales, il arrive d’écrire des points xes dont le corps contient des coupures. Or, la présence de coupure perturbe la vérication de la terminaison. Un exemple extrême est de dénir la constante app qui applique une fonction à son argument. Si f est le point xe que l’on contrôle, app f x n’est pas gardé car f n’est appliqué directement à aucun argument donc pas à un sous-terme alors que f x peut être gardé si x est STRICT. Nous devons donc vérier non pas le corps du point xe mais la forme normale du corps du point xe. Pour le faire, nous simulons les β, lesι et les ϕ réductions au sein de nos jugements. Pour réaliser les ι réductions, le plus simple est d’ajouter une spécication de sous-terme qui signie : être le ie constructeur dont les arguments ont les spécications de sous-terme s1 · · · sn. Pour cela la règle qui donne la spécication d’un constructeur est modiée pour devenir ∆ ;Ψ ⋄ D Cj | c1 · · · cs E = CONSTRj (c1 · · · cs ) Parallèlement, la fonction renforce est enrichie d’une règle qui simule la ι-reduction en rendant leur spécication aux arguments du constructeur et rendant les autres branches code mort : renforcei (CONSTRj (o1 · · · os )) = o1 · · · os si i = j et DEAD1 · · · DEADs sinon. Pour réaliser les β-réductions, nous allons retrouver une pile et un environnement de machine abstraite standard où des termes sont stockés. Les nœuds qui stockent un terme sont notées WEAK(Ψ,t). Ils seront aussi notés STRONG(Ψ,t) dans certains cas. Cette deuxième construction est la conséquence d’une optimisation qui va être détaillée à la n de cette section. Le calcul des valeurs de sous-terme est identique dans les 2 cas. La vérication des appels récursifs pourrait être réalisée en n’utilisant que WEAK(Ψ,t). Des nœuds "variables libres dont la spécication de sous-terme est s" restent nécessaires. Nous les notons ⊤s. La fonction renforcei (s) est elle aussi modiée suite au changement de type des éléments de la pile. Si elle renvoyait o1 · · · os , elle renvoie maintenant ⊤o1 · · · ⊤os . Puisque l’environnement stocke parfois des termes et non des valeurs de sous-terme directement, la fonction ∆ ⇓ hs | πi = o présentée gure 6.4 permet de recalculer cette spécication de sous-terme. La description exhaustive de la machine qui normalise un terme et en calcule sa spécication de sous-terme en appel par nom est donnée gure 6.5. 826.4 Ranement lié à la réduction ∆ ⇓ hs | πi = o ∆ ⇓ h⊤s | πi = s ∆ ;Ψ ⋄ ht | πi = o ∆ ⇓ hSTRONG(Ψ,t) | πi = o ∆ ;Ψ ⋄ ht | πi = o ∆ ⇓ hWEAK(Ψ,t) | πi = o Figure 6.4 – Forcer le calcul d’une valeur de sous terme ∆ ;Ψ ⋄ ht | πi = out ∆ ⇓ hΨ(x) | πi = out ∆ ;Ψ ⋄ hx | πi = out ∆ ;{x := s, Ψ} ⋄ ht | πi = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | s, πi = out ∆ ;{x := ⊤NO, Ψ} ⋄ ht | ∅i = out ∆ ;Ψ ⋄ hλ(x : S) ⇒ t | ∅i = out ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ ht | ⊤c, πi = out ∆ ;Ψ ⋄ ht u | πi = out ∆ ;Ψ ⋄ hs | πi = NO ∆ ;Ψ ⋄ h∀(x : S), T | πi = NO ∆ ⇓ hc1 | ∅i = o1 · · · ∆ ⇓ hcs | ∅i = os ∆ ;Ψ ⋄ D Cj | c1 · · · cs E = CONSTRj (o1 · · · os ) ∆ ;Ψ ⋄ hI | πi = NO ∆ ⇓ D sj | ∅E = CONSTRk (c1 · · · cs ) ∆ ; ( g := WEAK(Ψ,fixj (g : T := t)), Ψ ) ⋄ t | s1 · · · sk = o ∆ ;Ψ ⋄ D fixj (g : T := t) | s1 · · · sk E = o ∆ ;Ψ ⋄ h∆(c) | πi = o ∆ ;Ψ ⋄ hc | πi = o ∆ ⇓ D sj | ∅E = o’ ∆ ;  g := ⊤STRICT, Ψ ⋄ D t | ⊤NO1 · · · ⊤NOj-1, ⊤o’, ⊤NO1 · · · ⊤NOk-jE = o ∆ ;Ψ ⋄ D fixj (g : T := t) | s1 · · · sk E = o ∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ ht1 | renforce1(c), πi = o1 · · · ∆ ;Ψ ⋄ htn | renforcen(c), πi = on Yn k = 1ok = o ∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o Figure 6.5 – Calcul de la spécication de sous terme d’un terme 836 Etablir qu’un point xe ne produit pas de calcul inni Cette description donne une seconde règle pour le point xe an de réaliser la ϕ réduction en protant de la même machinerie. 6.4.2 Retrouver la réduction forte Vérier que la forme normale du corps d’un point xe vérie la condition de garde est insusant à assurer la normalisation forte. Prenons l’exemple Fixpoint aie (n : nat) : nat := (λ(x : nat) ⇒ O) (aie O)., la forme normale du corps : λ(n : nat) ⇒ O est bien évidemment gardée. Son évaluation en appel par valeur, par contre, rentre dans une boucle innie ! Il faut donc vérier quand même les arguments des applications avant de les mettre dans la pile. La vérication à faire est un peu plus faible. Les arguments sont systématiquement évalués dans un contexte vide lors d’un calcul en appel par valeur. De ce fait, des variables libres en position d’argument récursif ne peuvent jamais déclencher de ϕ-réductions. La règle qui vérie une application est donc ∆ ;Ψ i f hu | ∅i ∆ ;Ψ # i f ht | WEAK(Ψ,u), πi ∆ ;Ψ # i f ht u | πi Une nouvelle valeur de sous terme NEUTRAL est ajoutée qui stipule qu’une variable est une variable libre. Les fonctions sur les valeurs de sous-terme sont enrichies par renforcei (NEUTRAL) = NEUTRAL1 · · · NEUTRALs et la table du produit des valeurs de sous-terme est complétée par rapport à la gure 6.2 par × CONSTRi (c1 · · · cs ) NEUTRAL NO NO NO DEAD CONSTRi (c1 · · · cs ) NEUTRAL ARG NO* ARG but WEAK STRICT NO* NEUTRAL NEUTRAL CONSTRi (c1 · · · cs ) but WEAK NEUTRAL CONSTRj (c’1 · · · c’s ) CONSTRi (c1 × c’1 · · · cs × c’s ) Nous appelons garde faible le jugement ∆ ;Ψ i f hu | πi. Il assure que t en position d’argument est gardé. Il est déni par les règles : Vérier faiblement les arguments des valeurs (constructeurs, inductifs, variables libres) n’est pas susant. Les jugements correspondants doivent contrôler "normalement" les corps des arguments qui ont été mis dans la pile. 6.4.3 estions d’eicacité Les règles de déduction du jugement de vérication de la garde présenté gure 6.6 ne sont pas dirigées par la syntaxe puisque les constantes globales et les applications apparaissent toutes deux dans deux jugements diérents. L’introduction des éléments de pile 84 Ing´enierie des applications Web : r´eduire la complexit´e sans diminuer le contrˆole Julien Richard-Foy To cite this version: Julien Richard-Foy. Ing´enierie des applications Web : r´eduire la complexit´e sans diminuer le contrˆole. Software Engineering. Universit´e de Rennes 1, France, 2014. French. HAL Id: tel-01087372 https://hal.inria.fr/tel-01087372 Submitted on 5 Jan 2015 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 : Informatique École doctorale Matisse présentée par Julien RICHARD-FOY préparée à l’unité de recherche IRISA – UMR6074 Institut de Recherche en Informatique et Système Aléatoires ISTIC Ingénierie des applications Web : ré- duire la complexité sans diminuer le contrôle Thèse soutenue à Rennes le 9 décembre 2014 devant le jury composé de : Lionel SEINTURIER Professeur à l’université de Lille 1 / Rapporteur Manuel SERRANO Directeur de recherche à Sophia Antipolis / Rapporteur Erwan LOISANT Consultant à Zengularity / Examinateur François BODIN Professeur à l’IRISA / Examinateur Jean-Marc JÉZÉQUEL Directeur de l’IRISA / Directeur de thèse Olivier BARAIS Maître de conférence à l’IRISA / Co-directeur de thèse■❧ s❡♠❜❧❡ q✉❡ ❧❛ ♣❡r❢❡❝t✐♦♥ s♦✐t ❛tt❡✐♥t❡✱ ♥♦♥ q✉❛♥❞ ✐❧ ♥✬② ❛ ♣❧✉s r✐❡♥ à ❛❥♦✉t❡r ♠❛✐s q✉❛♥❞ ✐❧ ♥✬② ❛ ♣❧✉s r✐❡♥ à r❡tr❛♥❝❤❡r par Antoine de Saint-Exupéry ❊❛❝❤ s✐❣♥✐✜❝❛♥t ♣✐❡❝❡ ♦❢ ❢✉♥❝t✐♦♥❛❧✐t② ✐♥ ❛ ♣r♦❣r❛♠ s❤♦✉❧❞ ❜❡ ✐♠♣❧❡♠❡♥t❡❞ ✐♥ ❥✉st ♦♥❡ ♣❧❛❝❡ ✐♥ t❤❡ s♦✉r❝❡ ❝♦❞❡✳ ❲❤❡r❡ s✐♠✐❧❛r ❢✉♥❝t✐♦♥s ❛r❡ ❝❛rr✐❡❞ ♦✉t ❜② ❞✐st✐♥❝t ♣✐❡❝❡s ♦❢ ❝♦❞❡✱ ✐t ✐s ❣❡♥❡r❛❧❧② ❜❡♥❡✜❝✐❛❧ t♦ ❝♦♠❜✐♥❡ t❤❡♠ ✐♥t♦ ♦♥❡ ❜② ❛❜str❛❝t✐♥❣ ♦✉t t❤❡ ✈❛r②✐♥❣ ♣❛rts✳ par Benjamin PierceRemerciements Je remercie Lionel ❙❡✐♥t✉r✐❡r, Professeur à l’université de Lille 1, et Manuel ❙❡r✲ r❛♥♦, Directeur de recherche à Sophia Antipolis, d’avoir bien voulu accepter la charge de rapporteur. Je remercie Erwan ▲♦✐s❛♥t, Consultant à Zengularity, et François ❇♦❞✐♥, Professeur à l’IRISA, d’avoir bien voulu juger ce travail. Je remercie enfin Olivier ❇❛r❛✐s et Jean-Marc ❏é③éq✉❡❧, qui ont dirigé ma thèse.Table des matières ❚❛❜❧❡ ❞❡s ♠❛t✐èr❡s ✶ ■♥tr♦❞✉❝t✐♦♥ ✺ ■ ❈♦♥t❡①t❡ ❡t ét❛t ❞❡ ❧✬❛rt ✾ ✶ ❈♦♥t❡①t❡ ❡t ♣♦rté❡ ❞❡ ❧❛ t❤ès❡ ✶✶ 1.1 Architecture des applications Web . . . . . . . . . . . . . . . . . . . . . 11 1.2 Partage de code entre les parties client et serveur d’une application Web 13 1.3 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4 Portée de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ✷ ➱t❛t ❞❡ ❧✬❛rt ✶✾ 2.1 Styles d’architecture pour les applications Web résilientes . . . . . . . . 19 2.1.1 Architecture des applications Web interactives . . . . . . . . . . 20 2.1.2 Prise en charge du mode déconnecté . . . . . . . . . . . . . . . . 23 2.1.3 Travail coopératif assisté par ordinateur . . . . . . . . . . . . . . 24 2.1.4 ❊✈❡♥t s♦✉r❝✐♥❣ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2 Partage de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.1 Langages dédiés implémentés comme une bibliothèque . . . . . 27 2.2.2 Langages lourds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.3 Ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . . 30 2.2.4 Pouvoir d’expression des langages dédiés externes . . . . . . . . 31 2.2.5 Langages dédiés compilés et implémentés comme une bibliothèque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.6 Méta-programmation et évaluation partielle . . . . . . . . . . . . 35 2.2.7 ▲✐❣❤t✇❡✐❣❤t ▼♦❞✉❧❛r ❙t❛❣✐♥❣ et ❥s✲s❝❛❧❛ . . . . . . . . . . . . . . . 35 2.3 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 ■■ ❈♦♥tr✐❜✉t✐♦♥s ✹✶ ✸ P❛rt❛❣❡ ❞❡ ❝♦❞❡ ✹✸ 12 Table des matières 3.1 API des sélécteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2 Manipulation de valeurs optionnelles . . . . . . . . . . . . . . . . . . . . 46 3.3 Définition de fragments de HTML . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1 Représentation statiquement typée de chaînes de caractères contenant des expressions JavaScript . . . . . . . . . . . . . . . . . . . 50 3.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.2 Expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 ✹ ❙ûr❡té ❞✉ t②♣❛❣❡ ✻✶ 4.1 Inventaire des fonctions problématiques . . . . . . . . . . . . . . . . . . 61 4.1.1 createElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1.2 getElementsByTagName . . . . . . . . . . . . . . . . . . . . . . . 62 4.1.3 addEventListener . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2 Solutions bien typés et conservant le même pouvoir d’expression . . . . 65 4.2.1 Généralisation des solutions existantes . . . . . . . . . . . . . . . 65 4.2.2 Utilisation des types paramétrés . . . . . . . . . . . . . . . . . . 66 4.2.3 Utilisation des types dépendants . . . . . . . . . . . . . . . . . . 67 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 ✺ ❯♥ st②❧❡ ❞✬❛r❝❤✐t❡❝t✉r❡ ♣♦✉r ❧❡s ❛♣♣❧✐❝❛t✐♦♥s ❲❡❜ rés✐❧✐❡♥t❡s ✼✸ 5.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Fonctionnement du système de synchronisation . . . . . . . . . . . . . . 74 5.2.1 Scénario mono-utilisateur . . . . . . . . . . . . . . . . . . . . . . 75 5.2.2 Scénario multi-utilisateur . . . . . . . . . . . . . . . . . . . . . . 76 5.3 Généralisation du composant de synchronisation . . . . . . . . . . . . . 77 5.4 Évolution : fonctionnement complètement hors-ligne . . . . . . . . . . . 77 5.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.2 Expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 ■■■ ❈♦♥❝❧✉s✐♦♥ ❡t ♣❡rs♣❡❝t✐✈❡s ✽✸ ✻ ❈♦♥❝❧✉s✐♦♥ ❡t ♣❡rs♣❡❝t✐✈❡s ✽✺ 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table des matières 3 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 ❇✐❜❧✐♦❣r❛♣❤✐❡ ✾✹ ❚❛❜❧❡ ❞❡s ✜❣✉r❡s ✾✺4 Table des matièresIntroduction En automatisant certaines tâches et traitements d’informations, les technologies de l’information et de la communication (TIC) permettent de réaliser des économies considérables sur nos activités. Elles sont une importante source d’activités économiques, parfois qualifiée de « troisième révolution industrielle »[Rif08]. Illustrons ce propos par un exemple concret : le co-voiturage. Ce système vise à diminuer le nombre de véhicules sur les routes, et, par voie de conséquence, leurs émissions de gaz à effet de serre, en maximisant leur taux d’occupation par la mutualisation des voyages de différentes personnes. Le co-voiturage nécessite la collecte d’informations sur les trajets proposés par les conducteurs et les passagers, leur mise en relation ainsi qu’un processus de paiement. Les outils numériques, en automatisant ces tâches et traitements d’informations, facilitent considérablement la pratique du co-voiturage. En effet, utiliser, par exemple, des petites annonces dans la presse pour informer les passagers potentiels des trajets proposés par un conducteur, puis utiliser des courriers postaux pour organiser le voyage entre les personnes intéressées serait beaucoup plus contraignant (par exemple, chercher un trajet nécessiterait de parcourir manuellement l’intégralité des annonces, et les délais de mise en relation entre les personnes leur imposeraient de s’organiser très en avance). L’essor des TIC a permis au leader français du co-voiturage, BlaBlaCar, de rendre service à plus de 6 millions d’usagers. Ces outils numériques sont utilisés depuis des machines telles qu’un ordinateur, un téléphone ou une tablette. Les échanges d’information entre ces machines nécessitent qu’elles soient reliées en réseau. Dans ce contexte, le Web offre un environnement propice à la mise en place d’outils numériques : ceux-ci sont hébergés par des s❡r✈❡✉rs, qui centralisent les informations et coordonnent les utilisateurs. Ces derniers accèdent aux outils depuis leurs terminaux ❝❧✐❡♥ts, quels qu’ils soient (ordinateur, té- léphone ou tablette), en utilisant un navigateur Web, sans aucune étape d’installation. Lorsqu’un utilisateur interagit avec un tel outil, les actions qu’il effectue depuis sa machine sont éventuellement transmises au serveur. Par exemple, lorsqu’un passager décrit, depuis son ordinateur personnel, le voyage qu’il souhaite effectuer, cette information est transmise au serveur hébergeant l’application de co-voiturage qui lui indique, en retour, quels conducteurs prévoient de faire un voyage similaire. Toutefois, la réalisation de ces applications Web présente des difficultés pour les développeurs. La principale difficulté vient de la ❞✐st❛♥❝❡ entre les postes client et serveur. 56 Introduction D’une part, la distance physique (ou distance ♠❛tér✐❡❧❧❡) entre les machines nécessite qu’une connexion réseau soit toujours établie entre elles pour que l’application fonctionne correctement. Cela pose plusieurs problèmes : comment gérer les effets de latence lors des échanges d’information entre machines ? Comment assurer une qualité de service même lorsque la connexion réseau est interrompue ? Comment choisir quelle part de l’application s’exécute sur le client et quelle part s’exécute sur le serveur ? Des travaux ont proposé de prendre en charge le mode déconnecté en s’appuyant sur un système de persistence des données, côté client, capable de se synchroniser automatiquement lorsque la connexion réseau le permet [KLYY12, MGPW13]. Cependant, cette approche n’offre aucun moyen de régler les conflits dus à des modi- fications concurrentes des données. La gestion de ces conflits, quant à elle, a fait l’objet de nombreuses recherches, et un algorithme adapté aux spécificités du Web a été proposé en 2011 [SLLG11]. Bien que ces technologies apportent isolément des éléments de solutions, elles ne fournissent pas aux développeurs un cadre architectural pour que leurs applications soient, par construction, résilientes aux pannes de réseau. D’autre part, l’environnement d’exécution est différent entre les clients et serveurs, produisant une distance ❧♦❣✐❝✐❡❧❧❡. En effet, côté client c’est un navigateur Web qui exécute le code du programme, lequel est généralement écrit en JavaScript. De l’autre côté, c’est un serveur Web, éventuellement implémenté avec un autre langage que JavaScript, qui traite les requêtes des clients. Certains aspects d’une application Web peuvent être communs aux parties client et serveur, par exemple la construction de morceaux de pages Web, la validation des données saisies dans un formulaire ou certains calculs métier. En effet, construire les pages Web depuis le serveur facilite le référencement de leur contenu par les moteurs de recherche, mais les construire depuis le client produit une meilleure expérience utilisateur. De même, effectuer la validation des données des formulaires depuis le client offre une meilleure expérience utilisateur mais cette validation doit être effectuée de nouveau sur le serveur pour des raisons de sécurité. Cependant les langages de programmation et, surtout, les interfaces de programmation (API) étant différentes entre les deux parties, cela entrave les possibilités de réutilisation de code entre elles. Par conséquent, les développeurs dupliquent des concepts entre les parties client et serveur, bien que cela soit plus coû- teux à maintenir. Certaines technologies permettent le partage de code entre clients et serveurs [JW07, Can08], mais ce code partagé n’est pas capable de tirer parti des spécificités des environnements client et serveur, il nécessite une couche d’adaptation coûteuse en performance. En intégrant directement dans le langage les aspects communs aux parties client et serveur [RT10], le compilateur peut produire du code exécutable tirant parti des spécifités des plateformes cibles, mais cette approche demande un effort d’implémentation beaucoup plus important. Pour faciliter le processus d’ingénierie des applications Web, un challenge consiste à raccourcir cette distance, tant matérielle que logicielle. Cela signifie offrir un modèle de développement permettant aux développeurs de ne pas avoir à gérer ces difficultés sans pour autant masquer l’aspect distribué des architectures Web ni les spécificités de chaque environnement d’exécution. En effet, masquer complètement l’aspect distribué d’un système diminuerait la capacité à bénéficier des avantages de cette ar-Introduction 7 chitecture [GF99] (e.g. ubiquité des données). De même, masquer les spécificités des environnements client et serveur diminuerait les performances d’exécution [RFBJ13a]. Les travaux de cette thèse cherchent à raccourcir cette distance entre les parties client et serveur des applications Web, tout en préservant la capacité à tirer parti de cette distance, c’est-à-dire en donnant autant de contrôle aux développeurs. Le premier axe de travail est la réduction de la distance matérielle : comment concevoir une application Web de telle sorte qu’elle fonctionne aussi bien, quelle que soit la latence due à la distance entre les machines reliées en réseau, voire quand la connexion est rompue ? Nous répondons à cette question en proposant un modèle d’architecture découpant le code de l’application de façon à isoler la préoccupation de communication client-serveur et la logique métier. Grâce à ce modèle d’architecture nous avons été capables de capitaliser la logique de synchronisation entre clients et serveurs sous forme d’une bibliothèque réutilisable. Le deuxième axe de travail complète le premier. En effet, notre modèle d’architecture conduit à partager certains concepts côtés client et serveur. En particulier, les types de données décrivant les actions du système existent des deux côtés. Le besoin de partager des concepts entre clients et serveurs n’est, cependant, pas caractéristique de notre modèle d’architecture, et l’on observe plusieurs initiatives visant à faciliter la réutilisation de code entre clients et serveurs. Notre solution réutilise la bibliothèque js-scala, qui fournit un mécanisme d’évaluation retardée permettant à un même programme d’être évalué dans un navigateur Web ou dans l’environnement d’exécution du serveur (une JVM) [KARO12]. Notre contribution consiste en un ensemble de bibliothèques bâties sur js-scala, fournissant des API de haut niveau pour traiter certains aspects des applications Web, et produisant du code tirant parti des spécificités des environnements client et serveur. En particulier, ❉♦♠❖♣s pour la manipulation du DOM d’une page Web et ❢♦r❡st pour la définition de fragments de pages Web. En pratique, nous avons observé que la taille du code écrit avec nos outils est du même ordre de grandeur que celle d’un code utilisant des bibliothèques haut-niveau existantes et 35% à 50% plus petite que celle d’un code bas-niveau, mais que les performances d’exécution du programme obtenu sont du même ordre de grandeur que celles d’un code bas-niveau et 39% à 972% meilleures qu’un code haut-niveau. Nos travaux sont basés sur le langage Scala, qui est statiquement typé. Bien que le typage dynamique apporte aussi des avantages, des travaux ont rapporté que le typage statique peut jouer un rôle important pour faciliter la gestion de la complexité d’un programme [KHR+12, MHR+ ]. Cependant, l’utilisation d’un langage statiquement typé pour écrire du code s’exécutant sur les navigateurs Web a soulevé un nouveau problème : ce code fait appel aux API du navigateur, dont les fonctions sont destinées à être utilisées depuis le langage dynamiquement typé JavaScript, et auxquelles il peut être difficile de faire correspondre une signature typée sans perte d’information. En effet, certaines fonctions fondamentales de l’API du navigateur exposent des types de données trop généraux, contraignant le développeur à écrire des conversions descendantes de type (❞♦✇♥❝❛st✐♥❣), contournant ainsi le système de vérification de types, donc le conduisant éventuellement à écrire du code incorrect. En nous appuyant sur les mécanismes de paramètres de type ou de types membres des langages de pro-8 Introduction grammation, notre troisième contribution est une façon d’exposer des signatures de type pour ces fonctions, de telle sorte qu’elles fournissent suffisamment d’information pour éviter aux développeurs de réaliser des conversions de types, tout en conservant le même pouvoir d’expression. Comparée aux autres approches utilisées pour exposer l’API du navigateur dans un langage statiquement typé, notre approche permet de réduire le nombre de fonctions tout en préservant le même pouvoir d’expression. Ainsi, nos trois contributions permettent de diminuer la complexité du développement d’applications Web tout en donnant autant de contrôle aux développeurs.Première partie Contexte et état de l’art 9Chapitre 1 Contexte et portée de la thèse Ce chapitre détaille les problèmes d’ingénierie des applications Web dus aux distances matérielle et logicielle entre les postes client et serveur. Nous présentons d’abord les enjeux architecturaux découlant de la distance maté- rielle entre clients et serveurs, puis les obstacles au partage de code entre les environnements client et serveur à cause de leur distance logicielle. Ensuite, nous soulignons les difficultés à exposer l’interface de programmation des navigateurs Web dans un langage de programmation statiquement typé. Enfin, nous terminons ce chapitre en exposant les questions de recherche adressées par nos travaux. 1.1 Architecture des applications Web L’architecture d’un système peut supprimer certains problèmes techniques ou isoler certaines préoccupations, rendant le système moins complexe, donc plus facile à comprendre et faire évoluer. Dans le cas des applications Web, nous distinguons deux niveaux d’architecture : matériel et logiciel. L’architecture matérielle correspond à la disposition matérielle des machines reliées entre elles. Dans le cas des applications Web, il s’agit d’une architecture centralisée : plusieurs clients se connecte à un même serveur pour accéder à ses services. L’architecture logicielle correspond à l’organisation du code d’une application donnée, elle décrit la façon dont les différentes parties du code s’assemblent et leur responsabilités respectives. L’architecture matérielle du Web a pour avantage de permettre un accès ubiquitaire aux données : celles-ci étant stockées sur un serveur distant, l’utilisateur peut les consulter depuis plusieurs postes clients (par exemple depuis son ordinateur de bureau et son téléphone). En outre, si plusieurs utilisateurs accèdent à un même document, ils peuvent collaborer bien plus facilement que s’ils devaient s’envoyer, à tour de rôle, une copie modifiée d’un même document. Enfin, un dernier avantage est que le stockage des données est mutualisé : les postes clients n’ont pas besoin de disposer d’une grande quantité de mémoire pour utiliser une application. Toutefois, les architectures Web ont également certains désavantages. Par exemple, 1112 Contexte et portée de la thèse les utilisateurs peuvent percevoir de la latence due aux échanges d’information entre les postes clients et serveurs. De plus, la nature centralisée des architectures Web peut poser des problèmes de gestion de montée en charge pour les serveurs, si le trafic est irrégulier et intense. Enfin, une application Web ne peut être utilisée que si une connexion réseau est établie entre les postes client et serveur, or certains appareils (par exemple les téléphones mobiles) ne disposent que d’une connexion intermittente. L’objectif de cette thèse est de proposer des moyens logiciels pour construire des applications Web bénéficiant des avantages présentés précédemment sans souffrir des inconvénients dus à la distance matérielle entre clients et serveurs. En particulier, un aspect qui nous préoccupe est la rés✐❧✐❡♥❝❡ aux aléas du réseau : comment faire pour que la qualité de l’expérience utilisateur soit le moins possible affectée par une coupure de la connexion réseau ? Une telle coupure rend impossibles les échanges d’information entre le client et le serveur. Par conséquent, la préservation de l’expérience utilisateur n’est possible que si le client a déjà téléchargé suffisamment d’information pour pourvoir les fonctionnalités utilisées. Illustrons cela par un cas pratique. Imaginons une application permettant de gérer une liste de tâches à effectuer : les utilisateurs peuvent ajouter des tâches et indiquer quand elles sont réalisées. Le fonctionnement traditionnel des applications Web est le suivant : lorsqu’un utilisateur crée une nouvelle tâche ou indique qu’une tâche est réalisée, cette demande est transmise au serveur, celui-ci met à jour l’état du système en lui ajoutant la tâche créée, puis il envoie au client les informations lui permettant de mettre à jour l’interface utilisateur de façon à montrer à l’utilisateur qu’une tâche a été ajoutée. Maintenir les fonctionnalités de cette application lorsque le client est dé- connecté du serveur nécessite de faire évoluer et afficher l’état du système localement, sur le poste client, sans solliciter le serveur. Cependant, le fait de permettre à l’utilisateur d’utiliser le système en étant déconnecté induit un nouveau problème : l’état du système sur son poste client diverge de l’état du système sur le serveur, il devient alors nécessaire de synchroniser l’état du système du client vers le serveur, lorsque la connexion est de nouveau établie. Dans le cas d’un système permettant le travail collaboratif, la synchronisation doit prendre en compte le fait que deux utilisateurs peuvent effectuer des modifications concurrentes et parfois conflictuelles sur une même ressource. Reprenons notre exemple d’application de gestion de tâches. Lorsque la connexion est de nouveau établie, le client doit transmettre au serveur le nouvel état du système, tel qu’il a évolué suite à son utilisation. Cependant, si deux utilisateurs, Alice et Bob, utilisent le système en étant déconnecté, ils partent du même état et le font chacun évoluer différemment. Par exemple, Alice peut créer une nouvelle tâche, et Bob indiquer qu’une autre tâche a été réalisée. Quand ils se reconnectent, le processus de synchronisation doit faire converger les trois états (celui du serveur et ceux des clients d’Alice et Bob). En outre, si, en mode déconnecté, Alice supprime une tâche et Bob indique que cette même tâche a été réalisée, puis qu’Alice se reconnecte et se synchronise avec le serveur avant Bob, quand Bob se synchronise avec le serveur, celui-ci doit gérer le fait que la tâche que Bob a indiqué être réalisée a entretemps été supprimée par Alice.Partage de code entre les parties client et serveur d’une application Web 13 Plusieurs approches sont possibles dans ce cas. La plus simple pour les développeurs est aussi la moins satisfaisante pour les utilisateurs, elle consiste à ne rien faire de particulier sur le serveur en cas de modifications conflictuelles. Dans notre cas, cela peut se traduire par la levée d’une erreur lors de la synchronisation de Bob, car il demande au serveur de modifier une tâche qui n’existe pas. Cette approche conduit, dans le meilleur des cas, à l’affichage d’erreurs chez les clients, mais elle peut également ne pas détecter les conflits et faire converger le système vers un état qui ne reflète pas l’intention initiale des utilisateurs. Par exemple, si, en mode déconnecté, Alice demande de supprimer toutes les tâches réalisées pendant que Bob indique qu’une nouvelle tâche a été réalisée. Si Bob se synchronise avant Alice, la synchronisation de cette dernière peut conduire à ne pas supprimer la tâche nouvellement indiquée comme étant réalisée, alors qu’Alice avait initialement l’intention de supprimer toutes les tâches réalisées. Nous ne souhaitons par remettre en cause l’architecture matérielle des applications Web, car elle fournit de nombreux avantages. Notre objectif est de trouver une solution au niveau logiciel. Un style d’architecture pour construire des applications Web résilientes est un style d’architecture qui isole la préoccupation de résilience ou réduit le travail à effectuer par les développeurs pour parvenir à construire des applications résilientes. Une conséquence du fait que les côtés client et serveur soient tous les deux amenés à exécuter les traitements métiers (côté client, pour obtenir la propriété de résilience, côté serveur pour maintenir l’état de référence du système) est que la logique métier risque de se trouver dupliquée dans le code des programmes client et serveur. Cette duplication n’est pas souhaitable par l’ingénieur logiciel qui doit alors maintenir deux bases de code cohérentes entre elles. Un moyen d’éviter la duplication consiste à partager le même code. Cette idée est détaillée dans la section suivante. 1.2 Partage de code entre les parties client et serveur d’une application Web En fait, plusieurs aspects d’une application Web gagnent à être partagés entre clients et serveurs. Par exemple, vérifier, côté client, que les données saisies dans un formulaire sont valides contribue à améliorer l’expérience utilisateur car celui-ci n’a pas besoin d’attendre de soumettre l’intégralité d’un formulaire pour voir apparaître les erreurs. Cependant, ces règles de validation doivent également être appliquées côté serveur, au cas où un utilisateur mal intentionné contournerait la validation côté client. De même, la construction des pages HTML a intérêt à être réalisée côté serveur, pour obtenir un meilleur référencement du contenu par les moteurs de recherche, mais elle a aussi intérêt à être réalisée côté client, là encore, pour améliorer l’expé- rience utilisateur, en n’actualisant qu’une partie du document plutôt qu’en rechargeant la page entière. En outre, il est intéressant de gérer la navigation (la relation entre une URL et le contenu de la page correspondante) côté serveur, toujours pour des raisons de référencement par les moteurs de recherche, mais également côté client,14 Contexte et portée de la thèse encore pour des raisons d’exérience utilisateur. Enfin, certains calculs effectués sur le domaine métier d’un système peuvent également être exécutés côtés client et serveur. Tous ces exemples illustrent un besoin général, dans les applications Web, d’être capable de partager des concepts entre clients et serveurs. Cependant, ce besoin est difficile à satisfaire car les environnements d’exécution des programmes client et serveur ne sont pas les mêmes. Premièrement, les langages de programmation peuvent être différents : côté client le langage supporté par tous les navigateurs est JavaScript, tandis que côté serveur le choix du langage peut être déterminé par des raisons techniques (inter-opérabilité avec l’existant, compétences des collaborateurs, etc.). Mais surtout, le contexte d’exécution n’est pas le même. Côté client, le programme s’exé- cute dans un navigateur et est associé à un contexte local au client (document HTML, stockage local, etc.). Côté serveur, le programme s’exécute derrière un serveur HTTP et est associé à l’état global du système. Illustrons ces différences par un exemple concret : la construction de fragments HTML. Côté client, celle-ci aboutit à la construction d’un fragment de DOM, c’est-à- dire un arbre d’éléments HTML sur lequel il est possible d’effectuer des manipulations (e.g. ajout, suppression, déplacement de nœuds) ou de réagir à des événements produits par l’utilisateur sur certains nœuds (e.g. clic de souris). Côté serveur, elle aboutit à un un texte représentant la structure des éléments HTML. Ces différences sont illustrés figure 1.1. Le listing 1.1 donne le code JavaScript qui permet de construire cet arbre, côté client, et le listing 1.2 donne le code Scala qui permet de construire le fragment de HTML, côté serveur. Ces deux exemples illustrent le fait que construire un même fragment de HTML, côté client ou côté serveur, ne se fait pas de la même façon. 1.3 Sûreté du typage Nous avons réalisé nos travaux en nous appuyant sur le langage Scala, qui a la particularité d’être statiquement typé. Bien que le typage dynamique ait également ses avantages, nous observons que l’utilisation d’un langage à typage statique pour écrire la partie client d’une application Web n’est pas marginale : GWT [JW07], Dart [WL12], TypeScript [Fen12] 1 , Kotlin [Kot], Opa [RT10], SharpKit [Sha], HaXe [Can08], Ocsigen [Bal06], Elm [Cza12], Idris [Bra13] ou PureScript [Pur] sont autant d’exemples de langages à typage statique utilisés pour écrire la partie client d’applications Web. La partie client d’une application Web a pour rôle de réagir aux actions de l’utilisateur et de mettre à jour le document affiché. Cela s’effectue en utilisant des fonctions fournies par l’interface de programmation (API) du navigateur Web. Or, cette API a été conçue pour être utilisée depuis le langage JavaScript, qui est dynamiquement typé, et il est parfois difficile de définir une signature de type correcte pour certaines fonctions. 1. Soulignons toutefois que, dans le cas de Dart et TypeScript, le système de types n’est pas aussi contraignant que les systèmes de types statiques habituels. En effet, les erreurs de typage produisent seulement des avertissements plutôt que des erreurs de compilation. Ce comportement est voulu et a vocation à faciliter une migration d’une base de code non typée vers du code typé [BAT14, EMSS].Sûreté du typage 15 Figure 1.1 – Un formulaire tel qu’il est perçu par l’utilisateur (en haut), est représenté par un arbre d’éléments HTML côté client, et par un texte côté serveur. var ui = function (emailValue) { var email = document.createElement(’input’); email.name = ’email’; email.placeholder = ’Email’; email.value = emailValue; var pwd = document.createElement(’input’); pwd.name = ’pwd’; pwd.placeholder = ’Password ’; var button = document.createElement(’button ’); button.appendChild(document.createTextNode(’Sign in’)); var form = document.createElement(’form’); form.action = ’/authenticate ’; form.method = ’POST’; form.appendChild(email); form.appendChild(pwd); form.appendChild(button ); return form } Listing 1.1 – Définition du fragment de HTML représentant le formulaire montré dans la figure 1.1, côté client, en JavaScript : un arbre est construit progressivement, par ajout successif de nœuds.16 Contexte et portée de la thèse def ui(email: String ): Html = html"""
""" Listing 1.2 – Définition du fragment de HTML représentant le formulaire montré dans la figure 1.1, côté serveur, en Scala : une chaîne de caractères utilise une représentation textuelle du fragment de HTML. Le préfixe html permet une interpolation sûre de la valeur email var img = createElement("img"); img.src = "/icon.png"; var input = createElement("input"); input.value = "foo"; Listing 1.3 – Utilisation de la fonction createElement en JavaScript Par exemple, la fonction createElement a la signature de type suivante, d’après sa spécification standard [HTM] : Element createElement(String name); Notons que le type de retour indiqué est Element. Néanmoins, l’appel createElement(’input’) retourne plus précisément un nœud de type InputElement représentant un champ de formulaire. De même, l’appel createElement(’img’) retourne plus précisément un nœud de type ImageElement représentant une image. Ces deux types, InputElement et ImageElement, n’ont pas les mêmes propriétés. Par exemple, le type InputElement possède une propriété value contenant la valeur du champ du formulaire. De même, le type ImageElement possède une propriété src contenant l’URL de l’image. Ce détail n’a aucune importance pour les développeurs utilisant le langage JavaScript mais est problématique dans un langage statiquement typé. En effet, considérons le listing 1.3, écrit en JavaScript et créant une image et un champ de formulaire. Dans cet exemple, nous accédons à la propriété src de l’image et à la propriété value du champ de formulaire. Dans un monde statiquement typé, ce listing, bien que correct, produirait une erreur de typage car les propriétés src et value ne sont pas définies pour le type général Element. Ainsi, la signature de type standard de la fonction createElement ne convient pas, telle quelle, aux langages statiquement typés. Notons enfin, que le langage JavaScript permet d’écrire le listing 1.3 mais il permet également d’écrire des programmes incorrects. Par exemple, il est possible, en JavaScript, d’écrire un programme accédant à une propriété src d’un objet de typePortée de la thèse 17 InputElement bien que ce type ne possède pas de telle propriété. Idéalement, on aimerait avoir une signature de type telle que le listing suivant, en Scala, compile sans problème, sauf la dernière ligne : val img = createElement("img") img.src = "/icon.png" // Ok img.value = "foo" // Erreur: propriete ’value’ non definie De même, le listing suivant doit compiler, sauf la dernière ligne : val input = createElement("input") input.value = "foo" // Ok input.src = "/icon.png" // Erreur: propriete ’src’ non definie Autrement dit, après avoir créé un élément, il doit être possible d’utiliser toutes ses propriétés. Par contre, l’utilisation d’une propriété non définie pour ce type d’élément doit provoquer une erreur de typage. Dès lors, quelle signature de type définir pour la fonction createElement ? Plus généralement, y a-t-il d’autres fonctions qui souffrent d’un problème similaire, et comment le résoudre ? 1.4 Portée de la thèse Les sections précédentes ont soulevé plusieurs problèmes. Nos travaux s’intéressent en particulier aux questions de recherche suivantes : RQ1 Quel style d’architecture logicielle adopter pour isoler les problèmes dus à la distance matérielle entre clients et serveurs (latence, indisponibilité de l’application en mode déconnecté) ? RQ2 Comment partager du code entre les parties client et serveur malgré leurs différences ? RQ3 Comment interfacer le monde dynamiquement typé des navigateurs avec un langage statiquement typé en préservant la sûreté du typage et sans perdre de pouvoir d’expression ? Le reste de ce document est organisé comme suit. Le prochain chapitre détaille l’état de l’art relatif aux trois questions de recherches formulées. Le chapitre 3 montre comment nous avons défini des abstractions qui, bien qu’elles soient utilisables côtés client et serveur, ne souffrent pas de problèmes de performance (RQ2). Dans le chapitre 4 nous montrons qu’il est possible de définir, pour certaines fonctions de l’API du navigateur, des signatures de type garantissant une sûreté du typage et préservant le même pouvoir d’expression que l’API native (RQ3). Le chapitre 5 présente un sytle d’architecture ainsi que l’implémentation d’un composant logiciel réutilisable pour construire des applications Web résilientes (RQ1). Enfin, le chapitre 6 présente une synthèse des contributions ainsi que des perspectives de recherche.18 Contexte et portée de la thèseChapitre 2 État de l’art Ce chapitre présente les réponses que des travaux antérieurs apportent aux questions de recherche traitées par cette thèse. La préoccupation de résilience étant une préoccupation technique transverse, la section 2.1 s’intéresse aux styles d’architecture logicielle permettant d’isoler cette pré- occupation. La section 2.2 compare les méthodes existantes pour partager du code entre les parties client et serveur. Enfin, la section 2.3 recense les travaux visant à interfacer les langages statiquement typés et dynamiquement typés. 2.1 Styles d’architecture pour les applications Web résilientes L’ingénierie des applications Web a fait l’objet de nombreuses recherches. En 2002, Roy T. Fielding ❡t✳ ❛❧✳ ont proposé le style d’architecture ❘❊♣r❡s❡♥t❛t✐♦♥❛❧ ❙t❛t❡ ❚r❛♥s✲ ❢❡r (REST) [FT02]. Ce style d’architecture définit un ensemble de contraintes sur le fonctionnement et l’interaction des services Web, de façon à minimiser les problèmes de latence tout en minimisant le couplage des services Web. Cependant, REST se limite au côté serveur des applications Web : il ne donne aucune préconisation sur la façon d’intégrer les parties client et serveur des applications Web. En effet, les applications Web ont, entretemps, évolué. Notamment, la partie client est devenue beaucoup plus riche : elle ne se contente plus simplement d’afficher le contenu des pages et de naviguer entre les liens hypertextes, mais elle permet des interactions riches (déroulement de menus, etc.) et, surtout, une navigation asynchrone (quand l’utilisateur clique sur un lien hypertexte, le client ne remplace pas la page actuelle par la nouvelle, mais met à jour une partie du document actuel). Cette évolution se traduit par une plus grande quantité de code et de nouvelles responsabilités pour la partie client d’une application Web [Mar09]. Ainsi, une application Web comporte désormais deux applications : une application côté serveur, chargée de traiter les actions des clients et d’exposer les données du système, et une application côté client, chargée de répondre aux interactions de l’uti- 1920 État de l’art Figure 2.1 – Les modèles MVC (à gauche) et PAC (à droite) lisateur, éventuellement en transmettant ses actions à l’application côté serveur, et en actualisant l’affichage en fonction de l’évolution de l’état du système. L’utilisateur final utilise l’application côté client, qui elle-même utilise l’application côté serveur. 2.1.1 Architecture des applications Web interactives Cette section présente les styles d’architectures utilisés dans les applications interactives et leurs évolutions conduisant aux applications Web interactives. 2.1.1.1 Architecture des applications interactives Les deux principaux styles d’architcture pour les applications interactives sont ▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r [KP88] et Pr❡s❡♥t❛t✐♦♥✲❆❜str❛❝t✐♦♥✲❈♦♥tr♦❧ [Cou87]. Dans les deux cas, les préoccupations identifiées sont la logique métier (▼♦❞❡❧ ou ❆❜str❛❝t✐♦♥), l’interface utilisateur (❱✐❡✇ ou Pr❡s❡♥t❛t✐♦♥) et le lien entre les deux (❈♦♥tr♦❧❧❡r ou ❈♦♥tr♦❧). La principale différence entre les deux modèle, illustrée figure 2.1, est que, dans le cas du modèle PAC, la responsabilité de l’❆❜str❛❝t✐♦♥ s’arrête à la logique métier : elle ne communique pas avec l’interface utilisateur, contrairement au modèle MVC, et elle ne fait même pas l’hypothèse qu’une interface utilisateur existe. Notons également que la littérature mentionne aussi l’architecture ▼♦❞❡❧✲❱✐❡✇✲Pr❡s❡♥t❡r (MVP), qui est en réalité complètement équivalente au modèle PAC. Ainsi, le modèle PAC isole mieux les différents aspects des applications interactives : la partie ❆❜str❛❝t✐♦♥ contient la logique métier et est réutilisable dans une application non interactive. La partie Pr❡s❡♥t❛t✐♦♥ contient tout ce qui est spécifique à la technologie d’affichage choisie. Elle n’est pas liée à une application en particulier. Enfin, la partie ❈♦♥tr♦❧ rend l’❆❜str❛❝t✐♦♥ interactive en l’affichant à l’aide d’une Pr❡✲ s❡♥t❛t✐♦♥ et en interprétant les actions de l’utilisateur en termes d’actions métier. 2.1.1.2 Architecture des applications collaboratives interactives Les modèles PAC et MVC sont adaptés aux applications mono-utilisateur. Dans le cas où plusieurs utilisateurs manipulent en même temps une même ressource, de nouveaux problèmes se posent, notamment de gestion de la cohérence de l’information entre les différents utilisateurs. Duval ❡t✳ ❛❧✳ ont montré comment adapter le modèle PAC aux applications collaboratives. Ils proposent de dupliquer des instances de modèle PAC sur chaque clientStyles d’architecture pour les applications Web résilientes 21 Figure 2.2 – Le modèle PAC-C3D et de les faire communiquer entre elles au niveau des composants ❈♦♥tr♦❧. Ces composants se voient infliger une nouvelle responsabilité : gérer la cohérence des données entre les différents clients. Cette responsabilité est coordonnée par un serveur, maintenant l’état de référence du système. La figure 2.2 illustre le modèle PAC-C3D dans le cas d’un serveur et un client. Le serveur n’a pas de composant de Pr❡s❡♥t❛t✐♦♥ puisque son rôle se limite à de la synchronisation d’information : il reçoit les modifications effectuées par un client et les transmet aux autres clients. Le modèle PAC-C3D a l’avantage d’être simple et bien découpé : chaque composant n’a que peu de responsabilités. Cependant, il fait l’hypothèse d’une connexion réseau fiable et ne gère pas les conflits dues à des modifications concurrentes par des utilisateurs distants. 2.1.1.3 Architecture des applications Web interactives En 2007, Morales-Chaparro ❡t✳❛❧✳ ont proposé un ensemble de modèles d’architecture pour les applications Web. Ces modèles sont tous des variations du modèle ▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r (MVC), couramment utilisé pour la conception d’applications interactives. Les variantes proposées par ces auteurs s’adaptent à l’importance de l’application côté client. Dans une première variante, ils suggèrent d’utiliser MVC côté serveur seulement. C’est-à-dire que c’est le serveur qui est responsable de la construction de la page HTML affichée par le serveur (partie ❱✐❡✇), d’interpréter les requêtes HTTP en termes d’actions métier (partie ❈♦♥tr♦❧❧❡r ) et de mettre à jour l’état du système en fonction des actions métier (partie ▼♦❞❡❧). Dans cette variante, il n’y a pas d’application côté client, cela correspond donc au cas des applications Web d’antan. Une autre variante consiste à utiliser MVC côté client seulement. C’est-à-dire que c’est le client qui est responsable de la construction de la page HTML qu’il affiche (partie ❱✐❡✇), d’interpréter les interactions de l’utilisateur (e.g. clics sur des boutons) en termes d’actions métier (partie ❈♦♥tr♦❧❧❡r ), et de mettre à jour l’état du système en fonction des actions métier (partie ▼♦❞❡❧). Dans leur modèle, cette dernière partie est également responsable de transmettre l’évolution de l’état du système à un ▼♦❞❡❧ analogue, côté serveur. Dans cette variante, l’application est plus maigre sur le serveur que sur le client. Néanmoins, la partie ▼♦❞❡❧ existe des deux côtés, client et serveur. Enfin, les auteurs ont également proposé des modèles hybrides, où les trois parties22 État de l’art a) b) c) Figure 2.3 – Trois variantes d’architectures dérivées du modèle Model-View-Controller. a) MVC côté serveur ; b) MVC côté client ; et c) MVC hybride côtés client et serveur. (▼♦❞❡❧, ❱✐❡✇ et ❈♦♥tr♦❧❧❡r ) existent côtés client ❡t serveur. La figure 2.3 illustre ces variantes. Notons que dans tous les cas les applications client et serveur sont reliées entre elles par leur composant ▼♦❞❡❧, contrairement au modèle PAC-C3D présenté dans la section précédente, où les applications client et serveur sont reliées par leur composant ❈♦♥tr♦❧. Ces modèles d’architecture permettent de découper le code d’une application complète en parties correspondant à différents aspects (l’interface utilisateur, la logique métier et le lien entre les deux). Ce découpage a des avantages pour le développeur, qui peut plus facilement raisonner sur chaque aspect indépendamment des autres, mais il a également des avantages structurels : par exemple, la logique métier peut être utilisée indépendamment de l’interface utilisateur, elle est donc plus facilement testable. Par ailleurs, ces modèles d’architecture ont chacun des caractéristiques techniques qui les rendent plus ou moins appropriés selon les usages attendus de l’application. Le premier modèle est le plus simple à mettre en œuvre car il comporte peu de composants. Il comporte également un aspect technique intéressant : les pages étant construites sur le serveur, leur contenu est mieux référencé par les moteurs de recherche. Son inconvénient est qu’une application bâtie sur ce modèle n’offre pas une expérience utilisateur agréable (navigation synchrone). Le modèle où l’essentiel du code de l’application est côté client permet d’offrir une meilleur expérience utilisateur, mais il nécessite de dupliquer la partie ▼♦❞❡❧ côtés client et serveur. Ce modèle, contrairement au précédent, ne permet pas au contenu des pages d’être bien référencé par les moteurs de recherche. Les modèles hybrides permettent d’avoir à la fois une bonne expérience utilisateur et un bon référencement du contenu par les moteurs de recherche, au prix d’une duplication des parties ▼♦❞❡❧ et ❱✐❡✇ côtés client et serveur.Styles d’architecture pour les applications Web résilientes 23 Ce panel de modèles d’architecture témoigne surtout d’un aspect caractéristique des applications Web : le code de l’application doit être réparti entre le client et le serveur. Selon le type d’application on peut choisir de mettre plus de code sur le serveur que sur le client, ou inversement. Roberto Rodríguez-Echeverría a d’ailleurs identi- fié que cet aspect est, avec le processus de synchronisation client-serveur, une source majeure de complexité dans l’ingénierie des applications Web [RE09]. Il a également souligné que les méthodes d’ingénierie des applications Web devraient prendre en compte le fait que la connexion réseau peut être intermittente. À ce jour, personne n’a encore proposé de style d’architecture permettant le travail en mode déconnecté et automatisant la synchronisation au retour de la connexion. Intégrer la préoccupation de résilience nécessite de surveiller les échanges d’information entre clients et serveurs afin de choisir une stratégie de secours au cas où une requête échouerait. Les modèles d’architecture présentés précédemment font tous l’hypothèse d’une connexion réseau fiable. Si une interruption survient, l’effet d’une action de l’utilisateur sur l’état du système ne peut plus être transmis au serveur. Il est alors nécessaire de détecter le problème, d’en avertir l’utilisateur par une notification et, si possible, d’essayer d’envoyer à nouveau, un peu plus tard, la requête ayant échoué. De telles modifications impacteraient tant la partie interface utilisateur que la partie métier. En particulier, l’ensemble de la couche métier serait affectée car toutes les modifications des données doivent être transmises au serveur. Nous voyons ainsi que la préoccupation de résilience est une préoccupation transverse. 2.1.2 Prise en charge du mode déconnecté Dès 2000, Yun Yang a formulé l’essentiels des besoins auxquels doivent répondre les applications Web pour permettre le travail collaboratif en mode déconnecté : notamment le fait que la partie client doit contenir suffisamment d’information pour pourvoir les fonctionnalités de l’application, et la nécessité de synchroniser l’état du système avec le serveur au retour de la connexion [Yan00]. Plus récemment, Marco ❡t✳ ❛❧✳ ont proposé un modèle de description de site Web prenant en charge le mode déconnecté [MGPW13]. Leur modèle permet de définir comment l’utilisateur peut naviguer à travers les pages d’un site contenant de l’information et leur système génère un site Web utilisable en mode déconnecté. Cependant leur modèle se limite aux systèmes dont l’état n’évolue pas, il n’est donc pas approprié pour représenter une application dont l’état évolue suite aux actions de l’utilisateur. Kao ❡t✳ ❛❧✳ [KLYY12] ont implémenté une plateforme d’exécution d’applications Web prenant en charge le mode déconnecté et capable d’adapter le contenu des pages aux appareils mobiles (✐✳❡✳ téléphones). Leur plateforme fournit des bibliothèques pour stocker des données sur les postes clients et les synchroniser avec le serveur. Cependant, leur contribution se limite à une infrastructure logicielle : ils n’indiquent pas comment concevoir une application bénéficiant de cette infrastructure. Cet effort de conception reste donc à faire par les développeurs. En outre, leur solution de synchronisation ne gère pas les conflits.24 État de l’art 2.1.3 Travail coopératif assisté par ordinateur Indépendamment des recherches sur les architectures des applications Web, dans le domaine du travail coopératif assisté par ordinateur des travaux se sont intéressés spécifiquement aux méthodes de synchronisation de l’état d’un système distribué. Une méthode de synchronisation a pour but de faire converger les multiples répliques du système qui existent sur chaque client, après qu’elles ont évolué indépendamment les unes des autres. 2.1.3.1 Synchronisation basée sur les données Une première approche consiste à observer la façon dont les données évoluent sur les différentes répliques et à transmettre les changements aux autres répliques. Ainsi, Brett Cannon ❡t✳ ❛❧✳ ont rendu résilient un système de persistence en le dotant d’un mécanisme de synchronisation qui observe les modifications et les synchronise dès que possible avec le serveur [CW10]. L’intégration d’une telle technologie de persistence avec les modèles d’architectures présentés précédemment devrait permettre de traiter la préoccupation de résilience de façon transparente et isolée : la couche métier s’appuierait sur cette technologie de persistence résiliente, les autres parties du code n’auraient pas besoin d’être modifiées. Les ❈♦♥✢✐❝t✲❢r❡❡ ❘❡♣❧✐❝❛t❡❞ ❉❛t❛ ❚②♣❡s (CRDT) sont une approche similaire [SPBZ11]. L’idée est de modéliser le domaine du système à l’aide de types de données dont les opérations sont toutes commutatives, par construction. Ainsi, les effets de deux opé- rations concurrentes convergent toujours, sans générer de conflit. L’inconvénient de cette approche c’est que l’utilisation d’un tel type de données est contraignant, pour les développeurs, pour modéliser le domaine du système. L’inconvénient des approches basées sur les données est leur mauvaise gestion de la résolution des conflits. Illustrons cela à l’aide de l’exemple d’application de gestion de tâches donné en section 1.1. Prenons une situation où Alice supprime une tâche donnée, et Bob, de façon concurrente, fait passer l’état de cette même tâche de l’état réalisée à non réalisée. Un système de synchronisation placé sur le serveur et basé sur les données recevrait les modifications du système dues aux clients l’une après l’autre. S’il reçoit d’abord la modification de Bob, puis la suppression d’Alice, il applique les mêmes modifications sur son système, dans cet ordre, et termine dans un état où la tâche est supprimée. S’il reçoit d’abord la suppression d’Alice, puis la modification de Bob, il se retrouve dans une situation où il doit appliquer une modification sur une donnée qui a été supprimée. Dans ce cas, une solution simple consiste à ignorer la modification, et l’état d’arrivée est le même que précédemment : la tâche est supprimée. Prenons maintenant une situation où Alice supprime toutes les tâche réalisées et Bob fait passer une tâche de l’état réalisée à non réalisée. Si l’algorithme de synchronisation reçoit d’abord la modification de Bob puis la suppression d’Alice, il modifie la tâche puis la supprime car elle faisait partie des tâches réalisées dans la réplique d’Alice. En revanche, s’il reçoit d’abord la suppression d’Alice puis la modificationStyles d’architecture pour les applications Web résilientes 25 de Bob, il se retrouve dans une situation similaire à celle du pragraphe précédent : il doit appliquer une modification sur une tâche qui a été supprimée. S’il applique la stratégie décrite au paragraphe précédent, qui consiste à ignorer la modification sur la tâche supprimée, celle-ci est supprimée. Dans les deux cas il n’est pas certain que l’état du système corresponde vraiment à ce qu’attendent Alice et Bob. En effet, au final l’action d’Alice supprime une tâche dans l’état non réalisée alors que son action initiale consistait justement à supprimer les tâches réalisées. Le problème vient du fait que généralement il n’est pas possible de déduire l’intention initiale d’un utilisateur en fonction de l’évolution des données de sa réplique du système. En effet, différentes actions, correspondant à différentes intentions, peuvent conduire à des modifications de données similaires. Dans notre exemple, une tâche peut être supprimée parce qu’un utilisateur veut supprimer cette tâche en particulier, ou parce qu’elle fait partie des tâches réalisées et que son intention est de supprimer toutes les tâches réalisées. 2.1.3.2 Synchronisation basée sur les actions En fait, dès 1992 Ernst Lippe ❡t✳ ❛❧✳ distinguaient l’approche précédente, basée sur les données, d’une approche basée sur les actions [LV92]. La seconde approche consiste à comparer les suites d’actions qui ont été effectuées par les différents clients. Les auteurs notent que cette approche donne plus d’opportunités pour résoudre les éventuels conflits car elle permet de préserver l’intention de l’utilisateur. Dans le domaine des systèmes distribués, des algorithmes de convergence basés sur les actions existent depuis plus de 25 ans [EG89, SE98]. Ceux-ci sont en général conçus pour des architectures décentralisées et ont un coût important en espace, né- cessitant généralement des horloges vectorielles (ou quelque chose d’équivalent), ne permettant pas de passage à l’échelle. Un algorithme centralisé, Jupiter OT, a été proposé en 1995 par David Nichols [NCDL95]. Cet algorithme tire parti des spécificités des architectures client-serveur pour réduire sa complexité en espace : il n’est plus nécessaire, pour un client, de connaître les horloges de tous les autres clients, l’horloge du serveur suffit. Un autre avantage de cet algorithme est qu’il permet d’exécuter l’application d’opérations concurrentes de fa- çon optimiste : il n’est pas nécessaire d’attendre une réponse du serveur pour exécuter une opération sur un client. En effet, celui-ci peut exécuter l’opération directement sur sa machine, modifiant ainsi sa réplique de l’état du système. Si d’autres clients effectuent une modification de façon concurrente, l’algorithme crée une nouvelle opé- ration permettant de compenser les changements de façon à ce que les états de toutes les répliques convergent. Cependant l’algorithme de résolution de conflits n’est pas dé- terministe : l’état final du système obtenu côté serveur dépend de l’ordre dans lequel il reçoit les mises à jour des clients. Autrement dit, les actions concurrentes effectuées par plusieurs utilisateurs ne conduisent pas toujours à une convergence de l’état du système entre clients et serveurs. En outre, l’algorithme fait l’hypothèse d’un canal de communication fiable et ordonné, ce qui n’est pas le cas du protocole HTTP. Cette limitation a été résolue par Bin Shao ❡t✳ ❛❧✳ avec TIPS, un autre algorithme26 État de l’art de synchronisation basée sur une architecture centralisée [SLLG11]. Les auteurs introduisent une notion de relation d’effets rendant déterministe l’évolution de l’état du système, quel que soit l’ordre dans lequel les opérations sont reçues par le serveur. En outre, leur algorithme est conçu pour être particulièrement adapté aux architectures Web : de nouveaux clients peuvent joindre ou quitter la session de travail collaboratif à n’importe quel moment, les clients peuvent décider indépendamment les uns des autres quand se synchroniser auprès du serveur et le serveur peut décider quand traiter les opérations transmises par les clients. Un point commun à tous les algorithmes de synchronisation optimistes basés sur les actions est qu’ils s’appuient sur une fonction de transformation des actions, propre à chaque application. Dans le cas de Jupiter OT cette fonction a la forme suivante : f(c, s) = (c’, s’) Son implémentation doit satisfaire la propriété suivante : si c est une commande issue d’un client et s une commande issue du serveur, alors l’application des commandes s puis c’ par le serveur et c puis s’ par le client doivent produire le même effet. C’est cette fonction, spécifique à chaque application, qui permet de compenser les effets relatifs des commandes appliquées de façon concurrente. C’est cette fonction de transformation des actions qui permet de propager l’intention initiale des utilisateurs. Ainsi, dans le cas de notre exemple d’application de gestion de tâches, l’implémentation de cette fonction peut être différente pour traiter la suppression d’une tâche en particulier ou la suppression de toutes les tâches réalisées. Par conséquent, dans les situations données dans la section précédente, le système conserverait effectivement la suppression d’Alice dans le premier cas mais pas dans le second, correspondant à une intention de suppression de toutes les tâches réalisées. 2.1.4 Event sourcing Enfin, terminons cette section de l’état de l’art en reliant les approches de synchronisation basées sur les actions et l’❡✈❡♥t s♦✉r❝✐♥❣. L’❡✈❡♥t s♦✉r❝✐♥❣ décrit un style d’architecture dans lequel l’état d’un système est représenté par une succession d’évé- nements plutôt qu’à l’aide de types de données [Fow05]. Ainsi, dans notre exemple de logiciel de gestion de tâches, les événements permettant de représenter le système pourraient être : Created(id, content, isCompleted) « une tâche a été créée, elle a pour identi- fiant id, pour contenu content et comme état de complétion isCompleted » ; Removed(id) « la tâche identifiée par id a été supprimée » ; Edited(id, content, isCompleted) « la tâche identifiée par id a été modifiée ». Un système contenant une tâche dont l’état a été modifié une fois pourrait être représenté par la séquence d’événements suivante : Created(42, "Rédiger une thèse", false), Edited(42, "Rédiger une thèse", true).Partage de code 27 def ui(email: String ): Html = form(action := "/authenticate", method := "POST", input(name := "email", placeholder := "Email", value := email), input(name := "pwd", placeholder := "Password"), button("Sign in") ) Listing 2.1 – Définition de fragments de HTML à l’aide d’un langage dédié interne, en Scala. L’❡✈❡♥t s♦✉r❝✐♥❣ est surtout utilisé pour améliorer la montée en charge d’applications comportant beaucoup d’utilisateurs en consultation mais peu d’utilisateurs effectuant des modifications [BDM+13]. Notons que les algorithmes de synchronisation basés sur les actions correspondent à une approche ❡✈❡♥t s♦✉r❝❡❞ : une action est l’équivalent d’un événement. L’algorithme de synchronisation calcule l’état du système en fonction de l’application des actions effectuées par les divers utilisateurs. 2.2 Partage de code Cette section compare les différentes approches permettant de partager du code entre les parties client et serveur d’une application Web. 2.2.1 Langages dédiés implémentés comme une bibliothèque Une première approche consiste à utiliser un langage généraliste (p. ex. Scala), et à le rendre exécutable côté client en implémentant un ❜❛❝❦❡♥❞ du compilateur générant du JavaScript. Il devient alors possible d’écrire du code partagé entre les côtés client et serveur. Par exemple, il devient envisageable de définir une abstraction pour représenter les fragments de HTML. L’utilisation d’une telle bibliothèque, pour définir un fragment de HTML correspondant à la figure 1.1, pourrait ressembler à ce qui est donné dans le listing 2.1. L’ensemble des fonctions de l’API de cette bibliothèque forme un vocabulaire dédié à la construction de fragments de HTML. Comme le langage hôte sur lequel il s’appuie (ici, Scala), est utilisable côtés client et serveur, ce langage dédié est également utilisable côtés client et serveur. Cette approche a été décrite par Paul Hudak [Hud96]. Son principal intérêt réside dans son faible coût d’implémentation : une fois que le langage hôte peut être exécuté côtés client et serveur, l’introduction de nouveaux éléments de langages dédiés à un aspect particulier ne nécessite que l’implémentation d’une bibliothèque. GWT est un projet populaire suivant cette approche : il compile du code Java vers du JavaScript. Ainsi, il est possible d’écrire les parties client et serveur d’une application Web en Java, et de partager du code commun aux deux parties. HaXe, Kotlin, SharpKit, Ocsigen et ScalaJs [Doe13] sont d’autres projets similaires.28 État de l’art Figure 2.4 – Exécution du programme indiqué dans le listing 2.1. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation abstraite d’un fragment HTML. Celle-ci est ensuite convertie vers une représentation spécifique à chaque plateforme. En général, les outils suivant cette approche fournissent un mécanisme permettant d’interfacer les API du langage hôte (✐✳❡✳ Java, dans dans le cas de GWT) avec l’environnement du navigateur Web. Un tel mécanisme, appelé ❢♦r❡✐❣♥ ❢✉♥❝t✐♦♥ ✐♥t❡r✲ ❢❛❝❡ (FFI), permet d’utiliser les bibliothèques JavaScript existantes ou l’API native du navigateur directement depuis le langage hôte. Cependant, toutes les API utilisant ce mécanisme ne sont plus utilisables côté serveur. Par conséquent, il n’est pas possible de définir une bibliothèque partagée par les côtés client et serveur, pour, par exemple, construire des fragments de HTML, tout en exploitant directement les API natives des deux côtés, client et serveur. Plus généralement, le système de génération de code du compilateur n’a aucun moyen de produire du code tirant parti des spécificités de chaque plateforme (client ou serveur) pour une bibliothèque donnée. En effet, le compilateur n’a connaissance que des concepts du langage hôte, dans lequel sont implémentées les bibliothèques. En pratique, cela signifie qu’il n’est pas possible de faire en sorte que le listing 2.1 produise le code du listing 1.1 côté client et du listing 1.2 côté serveur. En effet, tout ce que la fonction form, par exemple, peut retourner, c’est une description abstraite d’un élément HTML
. Pour relier ce type de données abstrait à la représentation spécifique lui correspondant, côtés client et serveur, il est nécessaire d’introduire une couche d’interprétation, à l’exécution, comme indiqué en figure 2.4. Cette couche d’exécution peut diminuer les performances du programme.Partage de code 29 Figure 2.5 – Langages lourds. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation efficace du fragment HTML, en tirant parti des spécificités de chaque plateforme. 2.2.2 Langages lourds Pour produire du code plus spécifique à chaque plateforme pour une abstraction donnée, le compilateur doit avoir connaissance de cette abstraction. Un moyen d’y parvenir consiste à intégrer les concepts spécifiques au Web dans le langage lui-même, plutôt que de les définir sous forme de bibliothèques. Ainsi, si nous poursuivons l’exemple des fragments de HTML, un tel langage incluerait le concept de fragment de HTML, permettant aux développeurs de définir des fragments de HTML directement depuis le langage, avec une syntaxe dédiée et bien intégrée au reste du langage. Le compilateur du langage traduirait, dès la compilation, cette fois, les définitions de fragments de HTML en code natif correspondant, côtés client et serveur. Ce processus est illustré par la figure 2.5. Le fait que le concept de fragment de HTML fasse partie du langage permet au compilateur de le traiter de façon particulière, et de générer du code spécifique pour chaque plateforme, tirant parti des API natives. Opa et Links [CLWY07] sont des exemples de tels langages. Ils visent à couvrir, dans un unique langage, l’ensemble des aspects des applications Web. Par exemple, en Opa, les fragments de HTML peuvent être définis en utilisant la syntaxe textuelle de HTML, littéralement, comme le montre le listing 2.2. Cette approche a deux intérêts par rapport à la précédente : — La syntaxe du langage peut être adaptée aux aspects à intégrer (cf l’utilisation de littéraux HTML), offrant une meilleur expérience pour le développeur ; — Les aspects supportés par le langages peuvent être compilés de façon à tirer parti des environnements des plateformes cibles.30 État de l’art function ui(email) {
} Listing 2.2 – Définition d’un fragment de HTML avec Opa. La syntaxe du langage permet d’intégrer directement des littéraux HTML. Malgré ces avantages, les outils suivant cette approche n’ont pas connu de grand succès. Cela vient probablement du fait que, d’une part, le développement de la chaîne de compilation d’un langage et de l’outillage à destination des développeurs demande un important effort, par conséquent peu de projets ont atteint un niveau de maturité suffisant et sont capables de s’adapter aussi vite que les besoins et infrastructures évoluent. Et, d’autre part, apprendre un nouveau langage demande également un effort pour les développeurs, par conséquent il est souvent plus rentable de valoriser les compétences d’un développeur sur plusieurs projets plutôt que de le former à un nouvel outil à chaque nouveau projet. 2.2.3 Ingénierie dirigée par les modèles Une solution, pour limiter les deux inconvénients de l’approche précédente, consiste à utiliser plusieurs langages, chacun dédié à un aspect du développement d’applications Web. Ainsi, chaque développeur peut réutiliser ses compétences d’un projet à un autre, tant que certains aspects se recouvrent, et l’outillage propre à chaque langage peut également être réutilisé. La figure 2.6 illustre le fonctionnement de cette approche. Une fois que le mécanisme de combinaison des langages et le système de géné- ration de code sont définis, pour un ensemble de langages donnés, cette approche permet de produire les applications côtés client et serveur à partir de leurs aspects décrits dans différents langages dédiés. Les langages dédiés fournissent un vocabulaire permettant de décrire le système à un niveau de détail très abstrait. Cela rend le code du système plus facile à lire et faire évoluer, car il ne contient pas d’information purement technique ou bas niveau. WebDSL est un exemple de langage de programmation dédié au développement d’applications Web, construit selon une approche dirigée par les modèles[Vis08]. Le principal inconvénient de cette approche est qu’il est difficile de coordonner les différents aspects du programme. En effet, le processus de compilation nécessite, au préalable, de combiner les différents aspects ensemble, tant au niveau syntaxique que sémantique. Or, les technologies basées sur les modèles ne sont pas capables, aujourd’hui, d’automatiser cette phase de composition de langages bien que cela fasse l’objet de nombreuses recherches [VV10, VP12, JCB+13]. Autrement dit, cette approche re-Partage de code 31 Figure 2.6 – Ingénierie dirigée par les modèles. Chaque aspect du programme est dé- crit dans un langage dédié. La combinaison de ces aspects constitue le programme global, qui est transformé en une application côté client et une application côté serveur. quiert un effort d’implémentation important. De même, en réalité les possibilités de réutilisation de l’outillage spécifique à une unité de langage sont minces quand il s’agit de composer ces langages entre eux : seule la partie chargée de l’analyse syntaxique peut éventuellement être réutilisée. La plupart des fonctionnalités des outils, telles que la gestion des références interlangages, doivent être adaptées à chaque combinaison de langages. Enfin, un autre inconvénient de cette approche est qu’il est difficile de définir pré- cisément les bornes de chaque langage. L’argument principal de l’approche dirigée par les modèles est qu’on peut associer à chaque aspect du programme un langage simple à maîtriser. En réalité, un langage simple peut très vite devenir limitant en termes de pouvoir d’expression. Ce problème n’est pas spécifique à l’ingénierie dirigée par les modèles, il survient plus généralement lorsque l’on utilise des langages dédiés dits « externes » [Gho10]. 2.2.4 Pouvoir d’expression des langages dédiés externes Prenons un exemple pour illustrer ce problème. Le langage CSS [CSS] permet de décrire l’aspect visuel des éléments d’une page HTML : la couleur de l’arrière-plan de la page, la couleur du texte, la taille et l’espacement des éléments, etc. Le principal intérêt de CSS est qu’il permet de séparer l’aspect visuel du contenu HTML : le contenu peut être modifié indépendamment de son aspect visuel et réciproquement. CSS est un langage facile à apprendre car il contient peu de concepts : un document CSS est constitué d’un ensemble de règles définissant les valeurs de certaines proprié- tés visuelles (couleur, espacement, etc.) d’un ensemble d’éléments. D’un autre côté, cette simplicité est pénalisante pour le développeur. Par exemple, il n’est pas pos-32 État de l’art sible de définir la couleur d’un élément en fonction de la couleur d’un autre élément. Il n’est pas non plus possible de définir une règle en réutilisant une règle existante. En d’autres termes, il est difficile d’écrire du code modulaire et réutilisable. Ces problèmes pourraient être résolus si le langage supportait des mécanismes de nommage, de composition et d’abstraction. Il deviendrait alors possible, par exemple, de définir un style abstrait, réutilisable et spécialisable. Cette limitation n’est pas propre au langage CSS, on la retrouve souvent dans les langages dédiés externes (p. ex. HTML ou SQL). En 1966, Peter J. Landin a idientifé qu’un langage de programmation comportait en général deux facettes : un système linguistique général et un ensemble de concepts dédiés à un problème donné [Lan66]. Les concepts dédiés sont, comme leur nom l’indique, dédiés à un problème ou un aspect donné, et le système linguistique permet de construire des programmes en combinant les éléments de programmes entre eux (en s’appuyant sur des concepts généraux tels que le nommage, la composition et l’abstraction). Les langages de programmation généralistes se focalisent surtout sur la première facette : ils fournissent des mécanismes généraux permettant de construire des programmes. Tandis que les langages dédiés externes se focalisent surtout sur la seconde facette : ils fournissent des concepts dédiés à un problème donné. Or, les deux facettes sont utiles pour construire des programmes. Notons que l’on pourrait être tenté d’enrichir un langage externe trop pauvre avec des concepts supplémentaires fournissant des moyens de généralisation ou de composition. Mais, d’une part, cela rendrait le langage plus complexe, ce qui irait à l’encontre du but initial, et, d’autre part, cela conduirait à ré-inventer les mêmes choses dans chaque nouveau langage car les systèmes actuels d’ingénierie des langages ne savent pas produire des langages à partir d’unités de langages réutilisables. 2.2.5 Langages dédiés compilés et implémentés comme une bibliothèque Ainsi, toutes les solutions aux limitations des langages dédiés implémentés sous forme de bibliothèques présentent de nouvelles limitations diminuant leur applicabilité. En fait, le principal inconvénient des bibliothèques – l’impossibilité de spécialiser le code à exécuter pour une abstraction et une plateforme données – est exacerbé dans notre situation (le développement d’applications Web) mais n’en est pas l’apanage. En effet, ce problème peut être généralisé à la plupart des abstractions logicielles. La plupart des composants logiciels sont écrits pour être paramétrables ou confi- gurables. Ainsi, un même composant peut être utilisé différement selon qu’il est intégré dans un environnement de test ou de production. Un exemple typique est la connexion à une base de données : des URL différentes sont utilisées selon l’environnement (test ou production). Cela signifie que le code du programme qui se connecte à la base de données est paramétré par la connexion effective à la base de données. Pourtant, une fois lancé, le programme se connecte toujours à la même base de données.Partage de code 33 On observe donc une situation similaire à celle rencontrée dans l’exemple du langage dédié à la définition de fragments de HTML : un composant logiciel est souvent plus général que l’utilisation qui en est faite à l’exécution, et cela se paie à l’exécution par un niveau d’indirection supplémentaire. L’idéal serait que le code finalement exécuté ne souffre pas de ce niveau d’indirection : une fois la connexion à la base de données connue, on aimerait pouvoir construire un programme directement relié à celle-ci. Les systèmes de compilation à la volée (❏■❚) sont capables de faire certaines de ces optimisations, au prix d’une analyse du comportement du programme à l’exécution. Cependant des travaux ont montré que les JITs ne détectent pas autant d’opportunités d’optimisations qu’ils pourraient [RSB+14]. En fait, un autre système effectuant ce genre d’optimisations existe déjà et est utilisé par de nombreuses personnes sans le savoir. En effet, les outils de construction de projets remplissent exactement ce rôle. Ces outils permettent de compiler le code d’un projet et de gérer son cycle de vie (exécution des tests, déploiement, etc.). La plupart des ces outils de construction de projets sont capables de générer une partie du code source à compiler. Par exemple, dans maven, cela correspond à la phase ❣❡♥❡r❛t❡✲ s♦✉r❝❡s. Dans sbt, cela correspond à la tâche s♦✉r❝❡●❡♥❡r❛t♦rs. Dans les deux cas, les outils génèrent une partie du code source du programme à construire. Le code source du programme final est donc le produit de l’exécution d’un premier programme. Ce programme est un générateur de programmes. Ainsi, on observe qu’il est très fréquent qu’un programme soit généré par un autre programme. Dans le cas des outils de construction de projet, la distinction est claire car il y a effectivement deux phases d’exécution : une première pour générer du code, et une seconde pour exécuter ce code. Dans le cas des composants logiciels généraux, bien qu’il n’y ait qu’un seul code source et qu’une seule phase d’exécution, on est dans une situation où un programme est obtenu à partir d’un autre programme : en effet, une partie de l’exécution du programme correspond à l’interprétation des paramètres et la seconde partie à l’exécution effective du programme. Notons que cette observation a déjà été à l’origine de travaux en 1986 [JS86] : les auteurs introduisent le concept de st❛❣✐♥❣ visant à évaluer certaines parties d’un programme avant les autres selon leur fréquence d’exécution ou la disponibilité des données utilisées. Les deux approches (outils de construction de programmes et composants géné- raux) ont leurs avantages et inconvénients. Les outils de construction de programme, grâce à leur première phase d’exécution sont capables de générer du code plus spécialisé, et donc bénéficient de meilleures performances lors de la seconde phase d’exécution. Les composants généraux sont des citoyens de première classe dans tout le reste du programme : ils peuvent être passés en paramètre d’une fonction ou retournés comme résultat, ou être combinés entre eux, ce qui donne une plus grande flexibilité pour le programmeur, au détriment d’une perte de performances à l’exécution. Les langages dédiés compilés et implémentés sous forme de bibliothèque visent à bénéficier des avantages des deux approches en minimisant leurs inconvénients. L’idée essentielle est la suivante : les unités de langage sont fournies sous forme de bi-34 État de l’art Figure 2.7 – Langages dédiés compilés et implémentés par des bibliothèques. Un langage dédié est fourni par une bibliothèque dont l’implémentation produit une repré- sentation abstraite du programme à générer. Un générateur de code peut dériver, à partir de cette représentation abstraite, les programmes correspondant, côtés client et serveur. bliothèques dont l’implémentation retourne le code source d’un programme optimisé. Des travaux ont introduit cette idée en 1996 [K+96, Hud96]. Une amélioration consiste à utiliser une représentation abstraite du programme à générer plutôt que directement son code source [EFDM00]. Cela permet de réaliser de nombreuses réécritures de code ou optimisations telles que l’élimination de sous-expressions communes ou du code mort. La figure 2.7 illustre cette approche sur l’exemple des définitions de fragments de HTML. Avec cette approche, le développeur bénéficie du système linguistique du langage hôte pour définir et combiner entre elles des représentations abstraites de programmes obtenues avec le langage dédié à son problème. La figure 2.8 illustre les différences entre les langages dédiés implémentés par des bibliothèques, intérprétés ou compilés. Dans le premier cas, les concepts dédiés à un problème sont implémentés par des bibliothèques qui sont traduites, par le compilateur du langage hôte, vers du code pour les environnements client et serveur. Ce code, trop général, est adapté à l’exécution vers les spécificités des environnements client et serveur. Dans le second cas, les concepts dédiés à un problème sont également implé- mentés par des bibliothèques, mais cette fois-ci c’est leur exécution qui produit le code pour les environnements client et serveur. Ce code, produit par les bibliothèques plutôt que par le compilateur du langage, traduit chaque concept vers une représentation spécifique dans chaque environnement cible.Partage de code 35 Figure 2.8 – Différence entre les langages dédiés implémentés par des bibliothèques, interprétés (à gauche) ou compilés (à droite). 2.2.6 Méta-programmation et évaluation partielle Par ailleurs, il est notable que le programme écrit par le développeur est en réalité un générateur de programmes car c’est son exécution qui produit le programme final. Le fait que le programme bénéficie au total de deux phases d’exécution relie cette approche aux systèmes d’évaluation partielle [JGS93] : la première exécution peut déjà évaluer certaines parties du programme qui deviendront alors des constantes dans le programme final. Autrement dit, l’évaluation du programme final est ❞é❧❛②é❡ par rapport au programe initial. Une idée similaire a déjà été explorée par Manuel Serrano, dans le cas des applications Web, avec le langage Hop [SGL06]. Un programme écrit avec Hop contient en fait deux programmes : celui évalué côté serveur et celui évalué côté client. Le programme évalué côté client peut être construit à partir du résultat d’une évaluation côté serveur, de façon similaire à de l’évaluation partielle. Notons que, dans le cas de Hop, seul le programme côté client bénéficie du mécanisme d’évaluation partielle. Enfin, une autre manière d’effectuer de l’évaluation partielle est l’utilisation de macros. Les macros permettent d’évaluer des parties du code source au moment de la compilation. Cependant, les macros ne sont pas des entités de première classe au sein d’un langage : leur expansion ne peut avoir lieu qu’au moment de la compilation, elles ne peuvent donc pas être retournées comme résultat d’une fonction ou passées en paramètre. Cette caractéristique limite leurs possibilités d’utilisation. Par exemple, il n’est pas facile d’implémenter une macro extensible ou paramétrable. 2.2.7 Lightweight Modular Staging et js-scala Récemment, Tiark Rompf a implémenté ❧✐❣❤t✇❡✐❣❤t ♠♦❞✉❧❛r st❛❣✐♥❣ (LMS), une infrastructure logicielle, en Scala, pour définir des langages dédiés compilés et implé- mentés sous forme de bibliothèques [Rom12]. S’appuyant sur LMS, Kossakowski ❡t✳ ❛❧✳ ont implémenté ❥s✲s❝❛❧❛, un générateur de code JavaScript [KARO12]. Leurs travaux36 État de l’art ont montré le gain en confort obtenu par les développeurs utilisant le langage Scala plutôt que JavaScript pour écrire la partie client des applications Web, notamment grâce au typage statique. Ils ont également montré comment utiliser les bibliothèques JavaScript existantes depuis le langage Scala, à moindre effort, avec un système de typage graduel. Cependant, leur travail ne permet pas de produire, pour une abstraction donnée, du code tirant parti des spécificités des plateformes client et serveur. Nos travaux se sont basés sur js-scala : nous avons défini des unités de langage produisant du code optimisé, spécifique aux plateformes client et serveur. La suite de cette section détaille le fonctionnement de LMS. 2.2.7.1 Unités de langages composables Un programme LMS construit une représentation abstraite du programme à géné- rer. De la même façon qu’un programme complexe s’obtient en combinant plusieurs morceaux de programmes plus simples, une représentation abstraite d’un programme complexe s’obtient en combinant entre elles des représentations abstraites de programmes simples. Un exemple de programme simple est le programme constant : il retourne une valeur, toujours la même. On peut représenter un tel programme, avec LMS, à l’aide de la fonction const : val un = const (1) Le terme un a pour type Rep[Int] et a pour valeur une représentation abstraite d’un programme retournant le nombre 1. Pour l’utilisateur, il n’est pas nécessaire de connaître les détails de cette représentation abstraite. On peut ensuite représenter un programme plus complexe en combinant plusieurs programmes simples. Par exemple, la fonction plus combine deux programmes retournant un nombre et produit un nouveau programme retournant un nombre : val un = const (1) val deux = const (2) val trois = plus(un, deux) La fonction plus ne calcule pas une somme mais retourne une représentation abstraite d’un programme calculant la somme des résultats des programmes un et deux. Soulignons que les fonctions const et plus ne sont pas des mots-clé du langage Scala, mais bien des noms de fonctions implémentées dans une bibliothèque. Ces fonctions constituent le vocabulaire d’une ✉♥✐té ❞❡ ❧❛♥❣❛❣❡, NumericOps, permettant de représenter des programmes effectuant des sommes d’entiers. Les unités de langage forment des modules que l’utilisateur combine pour enrichir son vocabulaire. Des exemples d’unités de langage sont ArrayOps, pour manipuler des tableaux, et FunctionOps, pour définir des fonctions. Enfin, le développeur peut étendre ce vocabulaire en implémentant ses propres bibliothèques.Partage de code 37 Figure 2.9 – Diagramme d’objets correspondant au terme trois. 2.2.7.2 Représentation abstraite des programmes Du point de vue de l’utilisateur, les trois programmes, un, deux et trois ont tous le même type : Rep[Int]. Cela, bien que le programme trois soit un programme composite, contrairement aux programmes un et deux, qui sont des programmes constants. Pour l’utilisateur, ce qui compte c’est seulement de savoir qu’il manipule un programme retournant un entier, et c’est tout ce que le type Rep[Int] indique. En pratique, la représentation abstraite des programmes est implémentée à l’aide d’un graphe dont chaque nœud représente une instruction. Dans le cas du programme un, ce graphe ne comporte qu’un seul nœud, représentant la valeur constante 1. Ainsi, la fonction const retourne un nœud de type Const, et la fonction plus retourne un nœud de type Plus. La figure 2.9 montre le diagramme d’objets correspondant au terme trois. Le code suivant montre l’implémentation de la fonction plus : def plus(lhs: Rep[Int], rhs: Rep[Int]): Rep[Int] = Plus(lhs , rhs) 2.2.7.3 Génération de code L’objectif final est d’exécuter les programmes ainsi construits. On utilise pour cela des générateurs de code qui prennent en paramètre une représentation abstraite de programme et produisent un fichier texte contenant le code du programme. Le niveau de granularité de la génération de code est définie par les nœuds du graphe représentant le programme. Les nœuds du graphe sont parcourus et le générateur de code écrit le code correspondant à chacun. Par exemple le générateur de code JavaScript pour le nœud Plus est défini comme suit : case Plus(lhs , rhs) => gen"var $sym = $lhs + $rhs;" Le code produit une variable contenant le résultat de la somme des deux opé- randes. Au final, la sortie du générateur de code JavaScript appliqué au programme trois est la suivante : var x0 = 1 + 2;38 État de l’art 2.2.7.4 Optimisations En fait, comme les termes un et deux représentent des programmes constants, leur valeur est connue dès l’exécution du générateur de programmes, et cela constitue une opportunité d’optimisation : la somme des deux constantes pourrait être déjà évaluée dans le générateur de programmes et produire la constante 3 dans le programme final. Ainsi, une implémentation plus optimisée de la fonction plus est la suivante : def plus(lhs: Rep[Int], rhs: Rep[Int]): Rep[Int] = (lhs , rhs) match { case (Const(lhs), Const(rhs)) => const(lhs + rhs) case (lhs , Const (0)) => lhs case (Const(0), rhs) => rhs case _ => Plus(lhs , rhs) } Cette implémentation teste si les valeurs à additionner sont des représentations de programmes constants ou non. La somme de deux programmes constants est évaluée directement et produit un nouveau programme constant. Les cas particuliers d’addition d’un programme non constant avec la constante zéro sont également traités en éliminant l’addition. Enfin, le cas plus général, correspondant à deux programmes non constants, produit un nœud de type Plus. 2.2.7.5 Flexibilité syntaxique Voici un exemple plus complexe de code décrivant un programme manipulant un intervalle de nombres : val ns = range(1, 4) val inc = fun { (n: Rep[Int]) => plus(n, const (1)) } val prog = range_map(ns, inc) Le terme prog représente un programme qui applique une fonction à tous les élé- ments d’un intervalle de nombres. La fonction appliquée, représentée par le terme inc, retourne la valeur n, qui lui est passée en paramètre, majorée de 1. L’intervalle de nombres, représenté par le terme inc, contient les nombres de 1 à 4. À titre de comparaison, un programme équivalent en Scala pur 1 s’écrirait comme suit : for (n <- 1 to 4) yield n + 1 La comparaison des deux listings peut conduire le lecteur à estimer que la version écrite avec LMS est nettement plus verbeuse, donc plus difficile à lire. Par exemple, le corps de la fonction effectuant l’incrémentation s’écrit plus(n, const(1)) dans la version LMS, tandis qu’il s’écrit simplement n + 1 en Scala pur. Heureusement, le 1. Dans ce document, nous considérons les unités de langages définies au-dessus de LMS comme un langage différent de Scala bien que ce ne soit pas le cas puisque LMS est simplement une bibliothèque Scala.Sûreté du typage 39 langage Scala fournit un mécanisme de conversion implicite permettant à LMS de définir une conversion implicite de toute constante en un programme constant. Cela permet à l’utilisateur d’omettre le terme const : il peut simplement écrire plus(n, 1). De plus, le langage Scala fournit également un mécanisme permettant de définir ❛ ♣♦st❡r✐♦r✐ des opérateurs pour des types de données. LMS utilise ce mécanisme pour définir un opérateur + ayant pour opérandes des valeurs de type Rep[Int]. Cela permet à l’utilisateur d’écrire simplement n + 1, comme en Scala pur. Au final, grâce à ces facilités syntaxiques, l’utilisateur peut écrire son programme comme suit : val prog: Rep[List[Int]] = for (n <- 1 to 4) yield n + 1 C’est-à-dire, exactement comme il l’aurait écrit en Scala pur ! L’idée essentielle est que LMS ne nécessite pas le recours à une syntaxe particulière pour distinguer les termes représentant des valeurs des termes représentant des programmes. La distinction se fait uniquement par les types : le type Int représente un nombre entier, tandis que le type Rep[Int] représente un programme retournant un nombre entier. 2.2.7.6 Synthèse En résumé, définir une unité de langage avec LMS, consiste à : — définir une API fournissant le vocabulaire du langage (section 2.2.7.1) ; — écrire une implémentation de cette API produisant une représentation abstraite de chaque concept du langage (section 2.2.7.2) ; — définir un générateur de code (ou plusieurs, si différentes plateformes d’exécution sont ciblées) produisant le code correspondant à chaque nœud représentant un concept du langage (section 2.2.7.3). 2.3 Sûreté du typage Dans la section 2.2.7 nous avons mentionné le fait que js-scala permet d’utiliser les bibliothèques JavaScript existantes en utilisant un système de typage graduel. Ainsi, il n’est pas nécessaire de donner une signature de type aux fonctions de l’API JavaScript utilisée, mais, en contrepartie, aucune vérification du typage n’est effectuée. Cela peut donc conduire l’utilisateur à écrire des programmes incorrects sans que le compilateur ne l’en avertisse. Des travaux ont été réalisés pour vérifier que des appels de fonctions depuis un langage vers un autre, utilisant des systèmes de type différents, soient bien typés [FF05]. Cependant, notre problème est un peu différent : la difficulté réside dans le fait qu’à l’utilisation les signatures de type des fonctions standard du navigateur ne se révèlent pas « pratiques » pour le développeur. En effet, elles l’obligent ensuite à effectuer une opération de transtypage. L’enjeu consiste à trouver une autre signature de type contenant plus d’informations afin d’éviter à l’utilisateur d’effectuer des opérations de transtypage.40 État de l’art var createTwoElements = function (fst , snd) { return [ createElement(fst), createElement(snd) ] }; Listing 2.3 – Fonction faisant appel à createElement Le langage TypeScript permet de surcharger des opérations selon la valeur de certains paramètres. Ainsi, le compilateur attribue à l’expression createElement("div") le type DivElement car la valeur du paramètre passé à la fonction, "div", est connue en temps de compilation (c’est une constante). Cette solution donne autant de pouvoir d’expression aux utilisateurs et est bien typée à condition qu’elle soit utilisée avec des valeurs connues en temps de compilation. Cette contrainte limite son applicabilité car une fonction prenant en paramètre un nom d’élément name et créant un élément en appelant createElement(name) ne peut pas bénéficier du bon typage : le type de retour inféré de l’appel à createElement n’est pas plus précis que Element. Cette limitation est illustrée par le listing 2.3. Dans ce programme, la fonction createTwoElements prend en paramètre deux noms d’éléments et retourne un tuple contenant les deux éléments créés correspondant. Tout ce que le système de type du langage TypeScript peut infé- rer comme type de retour pour cette fonction est un tuple d’Elements. Une autre solution consiste à définir plusieurs fonctions spécialisées plutôt qu’une seule fonction générale. Ainsi, GWT propose une fonction createInputElement() ayant pour type de retour InputElement, une fonction createImageElement() ayant pour type de retour ImageElement, etc. Le développeur, en appelant createInputElement() plutôt que createElement("input") obtient alors une valeur du type le plus précis possible (InputElement plutôt que Element). L’inconvénient de cette solution, outre le fait qu’elle augmente significativement le nombre de fonctions de l’API, est qu’elle diminue le pouvoir d’expression de l’utilisateur. En effet, comme le paramètre repré- sentant le nom de l’élément à créer n’existe plus, il n’est plus possible d’écrire du code lui-même paramétré par un nom d’élément et faisant appel à createElement. Autrement dit, avec cette approche il n’est pas possible d’implémenter la fonction createTwoElements du listing 2.3. Une approche complètement différente a été suivie par Chugh ❡t✳ ❛❧✳ [CHJ12]. Ils ont montré comment typer du code JavaScript à l’aide d’un système de typage à types dépendants. Leurs travaux visent à bien typer un sous-ensemble du langage JavaScript. Cependant, la complexité des annotations de type nécessaires rend leur approche difficile à maîtriser par les utilisateurs.Deuxième partie Contributions 41Chapitre 3 Partage de code Ce chapitre présente un moyen de partager de code entre les environnements client et serveur. En nous appyant sur LMS et js-scala, nous avons pu définir des unités de langage fournissant des APIs de haut niveau, parfois utilisables des deux côtés, client et serveur, et générant du code efficace. Ce chapitre présente ces abstractions et leurs détails d’implémentation. Le contenu de ce chapitre a fait l’objet d’une publication [RFBJ13b]. 3.1 API des sélécteurs L’API des sélécteurs est une API du navigateur permettant de rechercher des élé- ments HTML dans une page. Elle contient plusieurs fonctions, résumées dans la fi- gure 3.1. Les fonctions querySelector et querySelectorAll sont les plus générales : les autres correspondent seulement à des cas particuliers de ces fonctions. Par exemple, la fonction getElementById peut être implémentée comme ceci : var getElementById = function (id) { return querySelector(’#’ + id) }; De façon similaire, les fonctions getElementsByClassName et getElementsByTagName peuvent être implémentée avec querySelectorAll. Fonction Élément(s) recherché(s) querySelector(s) Premier élément correspondant au sélecteur CSS s getElementById(i) Élément dont l’attribut id vaut i querySelectorAll(s) Tous les éléments correspondant au sélecteur CSS s getElementsByTagName(n) Tous les éléments ayant pour nom n getElementsByClassName(c) Tous les éléments dont l’attribut class contient c Figure 3.1 – L’API standard des sélecteurs. 4344 Partage de code function getWords () { var form = document.getElementById(’add -user’); var sections = form.getElementsByTagName(’fieldset ’); var results = []; for (var i = 0 ; i < sections.length ; i++) { var words = sections[i] .getElementsByClassName(’word’); results[i] = words; } return results } Listing 3.1 – Utilisation de l’API native pour rechercher des éléments dans une page HTML function getWords () { var form = $(’#add -user’); var sections = $(’fieldset ’, form); return sections.map(function () { return $(’.word’, this) }) } Listing 3.2 – Utilisation de jQuery pour rechercher des éléments dans une page HTML Ces fonctions plus spécifiques ont l’avantage d’avoir une implémentation plus performante par le navigateur, comparées aux fonctions générales querySelector et querySelectorAll. D’un autre côté, elles ajoutent de la complexité au code en augmentant le nombre de fonctions à connaître pour manipuler l’API et en poussant l’utilisateur à penser à un bas niveau d’abstraction. Le listing 3.1 illustre l’utilisation de cette API pour récupérer une liste de champs de formulaires. La fonction getWords commence par rechercher l’élément ayant pour id add-user, puis collecte tous les sous-éléments de type fieldset, et, pour chacun, retourne la liste de ses sous-éléments dont l’attribut class contient word. Notons que le code utilise uniquement les trois fonctions bas niveau de l’API du navigateur. À titre de comparaison, la bibliothèque jQuery [BK08], largement utilisée par les sites Web [jQu], ne propose qu’une seule fonction pour rechercher des éléments dans une page HTML. Une version du programme getWords avec jQuery est donnée dans le listing 3.2. Le code est à la fois plus court et plus simple, notamment grâce au fait que jQuery propose une API plus haut niveau que l’API du navigateur. Cependant, ce confort d’utilisation se paie par des performances d’exécution moindres (les benchmarks pré- sentés en section 3.4 montrent des temps d’exécution de l’ordre de 10 à 30 fois plus longs avec jQuery).API des sélécteurs 45 def getWords () = { val form = document.find("#add -user") val sections = form.findAll("fieldset") sections map (_.findAll(".word")) } Listing 3.3 – Utilisation de DomOps pour rechercher des éléments dans une page HTML def find(selector: Rep[String ]) = selector match { case ConstIdCss(id) if receiver == document => DocumentGetElementById(Const(id)) case _ => SelectorFind(receiver , selector) } Listing 3.4 – Optimisation de find En nous appuyant sur le mécanisme d’évaluation partielle de LMS, notre idée consiste à définir une API de haut niveau, fournissant un confort d’utilisation similaire à jQuery, mais dont l’évaluation produit un programme utilisant les APIs bas niveau du navigateur, bénéficiant des bonnes performances d’exécution. Ainsi, nous proposons une API de haut niveau, ❉♦♠❖♣s, comprenant deux fonctions : find et findAll, permettant de chercher un élément ou plusieurs éléments, respectivement. Ces fonctions sont directement équivalentes aux fonctions querySelector et querySelectorAll de l’API native. Elles prennent en paramètre un sélecteur CSS et retournent le premier élément ou tous les éléments correspondant. Le listing 3.3 montre code de la fonction getWords avec notre API. Ce code est, lui aussi, simple et concis, comparé au listing 3.1 utilisant l’API native du navigateur. L’implémentation des fonctions find et findAll analyse les sélecteurs qui leur sont passés en paramètre pour détecter une opportunité d’utilisation d’une fonction spé- cialisée plutôt que de toujours utiliser querySelector et querySelectorAll, respectivement. L’analyse consiste à détecter un motif particulier dans la chaîne de caractères représentant le sélecteur. Ainsi, l’implémentation de find vérifie si le sélecteur correspond à un sélecteur d’id et si l’objet sur lequel est appelée la méthode est document, et, le cas échéant, retourne un nœud de type DocumentGetElementById. Sinon, elle retourne un nœud de type SelectorFind. Ces nœud sont traduits, par le générateur de code JavaScript, en code utilisant getElementById et querySelector, respectivement. Le listing 3.4 montre l’implémentation de la fonction find. Du point de vue de l’utilisateur, la fonction s’utilise toujours de la même façon mais elle produit un code différent en fonction de la valeur des paramètres qui lui sont passés. Par exemple, l’évaluation de l’expression document.find("#add-user button") retourne un nœud de type SelectorFind, car le sélecteur ne correspond pas à un sélec-46 Partage de code Figure 3.2 – Représentations abstraites de code retournées par l’évaluation des expressions (a) document.find("#add-user button") et (b) document.find("#add-user") def findAll(selector: Rep[String ]) = selector match { case ConstClassName(name) => GetElementsByClassName(receiver , name) case ConstTagName(name) => GetElementsByTagName(receiver , name) case _ => SelectorFindAll(receiver , selector) } Listing 3.5 – Optimisation de findAll teur d’id (c’est un sélecteur composite sélectionnant les éléments de type button à l’intérieur de l’élément ayant pour id add-user). D’un autre côté, l’expression document.find("#add-user") retourne un nœud de type DocumentGetElementById. La figure 3.2 L’implémentation de la fonction findAll, donnée dans le listing 3.5, est similaire : le sélecteur passé en paramètre est analysé pour détecter s’il s’agit d’un sélecteur de classe ou de nom d’élément, et, le cas échéant, retourne un nœud de type GetElementsByClassName ou GetElementsByTagName, respectivement. Sinon, elle retourne un nœud de type SelectorFindAll. Notre solution offre donc à l’utilisateur une API de haut niveau dont le surcoût n’existe que lors de la première évaluation du programme : le programme final généré s’appuie, lorsque cela est possible, directement sur les APIs bas niveau performantes. En fait, le listing 3.3 produit exactement le code bas niveau du listing 3.1. 3.2 Manipulation de valeurs optionnelles Certaines fonctions du navigateur peuvent, dans certains cas, ne pas retourner de résultat : typiquement, les fonctions de recherche d’éléments HTML peuvent échouer (dans le cas où l’élément recherché n’est pas trouvé dans la page) et, dans ce cas, la valeur retournée doit représenter l’absence de résultat. La majorité des API JavaScript utilisent l’objet null pour représenter l’absence de valeur. Cependant, cette solution est connue pour être une importante source de fragilité dans le code des programmes [NS09, Hoa09]. Pour s’en protéger, les programmeurs peuvent faire de la programmation dite « défensive », en vérifiant toujours qu’une valeur ne vaut pas null avant de l’utiliser. À titre d’exemple, le listing 3.6 montre unManipulation de valeurs optionnelles 47 var loginWidget = document.querySelector("div.login"); var loginButton = loginWidget.querySelector("button.submit"); loginButton.addEventListener("click", handler ); Listing 3.6 – Code non sûr manipulant des valeurs optionnelles var loginWidget = document.querySelector("div.login"); if (loginWidget !== null) { var loginButton = loginWidget.querySelector("button.submit"); if (loginButton !== null) { loginButton.addEventListener("click", handler ); } } Listing 3.7 – Style défensif pour se protéger du déréférencement de valeurs null programme JavaScript recherchant un composant dans la page, puis recherchant un bouton à l’intérieur de ce composant. Le code de ce listing n’est pas sûr car les termes loginWidget et loginButton sont utilisés sans vérifier qu’ils ne valent pas null. Par conséquent, l’exécution de ce programme sur une page ne contenant pas les éléments recherchés lèvera une exception au moment où le terme loginWidget sera déréférencé. Une version sûre du même programme est donnée dans le listing 3.7. Ce style de code, très verbeux, n’est pas pratique à l’utilisation, et, surtout, nécessite une grande rigueur de la part de l’utilisateur car rien ne le force à effectuer ces tests pour diffé- rencier l’absence de valeur des cas où une valeur est bien présente. Une amélioration possible consiste à utiliser un type de données spécifique pour représenter l’absence éventuelle de valeur. Cela permet à l’utilisateur de distinguer les cas où il doit se protéger de l’absence de valeur des cas où il peut faire l’hypothèse que la valeur est présente. Cela réduit l’effort intellectuel à fournir par l’utilisateur mais pas la verbosité du code car les tests vérifiant que la valeur est présente sont toujours nécessaires. Une seconde amélioration consiste donc à bénéficier d’une syntaxe allégée pour déréférencer les valeurs optionnelles, de façon à diminuer la verbosité du code. En Scala, la notation for permet de séquencer l’évaluation d’expressions de façon concise. En nous appuyant sur ces améliorations, notre solution, ❖♣t✐♦♥❖♣s, fournit une syntaxe concise pour manipuler les valeurs optionnelles de façon sûre. Le listing 3.8 for { loginWidget <- document.find("div.login") loginButton <- loginWidget.find("submit.button") } loginButton.on(Click)( handler) Listing 3.8 – Manipulation de valeurs optionnelles avec OptionOps48 Partage de code montre l’implémentation du programme précédent avec OptionOps. La fonction find retourne maintenant une valeur de type Rep[Option[Element]] au lieu de Rep[Element] et l’implémentation du séquencement, dans les expressions for vérifie que la valeur est bien présente. Encore une fois, cette abstraction a un coût : l’utilisation d’un type de données spé- cifique pour représenter l’absence éventuelle de valeur nécessite une allocation d’objet supplémentaire, et les fonctions d’ordre supérieur utilisées pour le séquencement, par la notation for, sont moins efficaces que des instructions if. Heureusement, comme précédemment, notre abstraction et ses surcoûts n’existent que dans le programme initial. En effet, le séquencement d’expressions représentant des programmes contenant des valeurs optionnelles retourne une représentation de programme effectuant ce séquencement. Finalement, le générateur traduit cette représentation abstraite de séquencement en véritable séquencement en générant du code vérifiant qu’une valeur n’est pas absente en la comparant avec null. Le listing 3.9 montre l’implémentation de la génération de code pour le séquencement. case OptionForeach(option , block) => gen"""if ($option !== null) { $block }""" Listing 3.9 – Générateur de code JavaScript pour le langage de manipulation de valeurs optionnelles Le programme haut niveau du listing 3.8 produit un programme JavaScript identique au listing bas niveau 3.7. Enfin, comme l’implémentation de l’unité de langage retourne une représentation abstraite des opérations, celle-ci est indépendante de la plateforme d’exécution, et il est facile d’implémenter, en plus du générateur de code JavaScript, un générateur de code Scala. Ainsi, la même abstraction – l’unité de langage pour manipuler des valeurs optionnelles – est utilisable côtés client et serveur, et le code généré est efficace des deux côtés (il n’utilise pas d’objet supplémentaire pour représenter l’éventuelle absence de valeur). 3.3 Définition de fragments de HTML Nous avons montré en introduction à quel point les plateformes client et serveur représentent différemment l’interface utilisateur (listings 1.1 et 1.2, page 15). Côté client, l’interface utilisateur de l’application est représenté par un arbre organisant de façon hiérarchique les composants, le ❉♦❝✉♠❡♥t ❖❜❥❡❝t ▼♦❞❡❧ (DOM). L’utilisation d’un arbre permet facilement de remplacer un nœud par un autre, d’introduire un nouveau nœud ou de retirer un nœud, dynamiquement, pour mettre à jour l’interface utilisateur.Définition de fragments de HTML 49 def ui(email: Rep[String ]): Rep[Element] = el(’form , ’action -> "/authenticate", ’method -> "POST ")( el(’input , ’name -> "email", ’placeholder -> "Email", ’value -> email)(), el(’input , ’name -> "pwd", ’placeholder -> "Password")(), el(’button )(" Sign in") ) Listing 3.10 – Définition d’un fragment de DOM avec Forest Côté serveur, l’interface utilisateur est généralement représentée par du texte contenant du code HTML. Cette représentation permet au contenu d’une page Web d’être facilement transmis dans le corps d’une réponse HTTP. Construire le contenu HTML depuis les côtés client et serveur ont tous les deux des avantages. Côté client, cela permet de faire évoluer l’interface utilisateur dynamiquement, sans rechargement complet de la page, ce qui procure une meilleur expé- rience utilisateur. Côté serveur, cela permet au contenu d’être mieux référencé par les moteurs de recherche (le référencement du contenu produit côté client ajoute beaucoup de complexité aux systèmes de référencement) et permet de gagner du temps sur l’affichage initial du contenu. Ces préoccupations techniques conduisent les développeurs à dupliquer, côtés client et serveur, le code définissant le contenu HTML de leurs applications. En plus de ces considérations techniques, notons que l’API du navigateur pour la construction de fragments de DOM est particulièrement verbeuse : en effet, le listing JavaScript 1.1 est plus de deux fois plus long que son équivalent Scala, le listing 1.2. En outre, le style impératif de l’API du navigateur ne permet pas facilement de visualiser la structure hiérarchique des différents éléments d’un fragment de DOM, contrairement à la notation HTML. En résumé, pour atteindre notre objectif de réduction de la complexité de la défi- nition de contenus Web, nous devons proposer un seul langage, concis, permettant de générer les contenus côtés client et serveur. Malgré les différences de représentation côtés client et serveur, les contenus Web sont, dans les deux cas, constitués d’éléments HTML et de texte. Ainsi, nous proposons un langage, appelé ❋♦r❡st, centré sur des deux concepts. L’implémentation de notre langage produit une représentation abstraite de contenu Web. Nos générateurs de code parcourent cette représentation abstraite et génèrent, pour chaque plateforme, du code bas niveau utilisant les API natives. Le listing 3.10 montre comment construire le contenu Web présenté en figure 1.1. La fonction el construit un élément HTML, lequel peut contenir des attributs et des sous-éléments. Ceux-ci peuvent être des éléments HTML ou du texte, comme dans le cas du bouton. Le type de retour de la fonction ui, Rep[Element], désigne une repré- sentation abstraite de programme produisant un élément HTML. Il est notable que notre unité de langage, bien que minimaliste (elle ne comporte qu’une fonction, el), n’a pas un pouvoir d’expression limité. En effet, comme elle est50 Partage de code def usersUi(users: Rep[Seq[User ]]) = el(’ul)( for (user <- users) yield el(’li)( userUi(user)) ) Listing 3.11 – Utilisation de boucles et composition de fragments Web avec Forest définie sous forme de bibliothèque, elle s’intègre directement dans le langage Scala dont elle peut bénéficier de tous les concepts : fonction, boucles, tests, etc. Les représentations abstraites de programmes produisant du contenu Web (les valeurs de type Rep[Element]) sont des entités de première classes, elles peuvent être passées en paramètre à des fonctions, utilisées dans des boucles, etc. de telle sorte qu’au final, l’utilisateur bénéficie d’un système puissant de génération de contenus Web, similaire aux moteurs de gabarits (t❡♠♣❧❛t❡ ❡♥❣✐♥❡s, en anglais) généralement fournis par les solutions de construction d’applications Web. Le listing 3.11 montre, ainsi, comment construire un contenu Web affichant une liste d’utilisateurs. La fonction usersUi crée un élément HTML ul, dont les sous- éléments sont obtenus en transformant une collections d’utilisateurs en une collection de fragments Web. Cette transformation utilise une unité de langage de manipulation de collections. Enfin, le fragment Web décrivant chaque utilisateur est obtenu en appelant la fonction userUi, dont le code n’est pas montré dans le listing. Le point important du listing étant de montrer qu’il est possible de découper la définition de contenus Web en fragments réutilisables. Les listings 3.12 et 3.13 montrent les implémentations des générateurs de code JavaScript et Scala pour le langage Forest. Dans les deux cas, le fonctionnement est similaire. Il y a deux types de nœuds à traiter, les éléments HTML (Tag) et le texte (Text). La version JavaScript construit un arbre en utilisant l’API native du DOM. La version Scala génère du texte (le code du générateur est difficile à lire du fait que le code généré, représenté par des chaînes de caractères, contient lui-même des chaînes de caractères). Les deux générateurs de code gèrent le fait que les sous-éléments d’un élément Web peuvent être connus au moment de l’évaluation du programme initial et, le cas échéant, déroulent la boucle insérant chaque sous-élément dans son élément parent. Dans le cas contraire, ils génèrent une boucle dans le langage cible. Au final, l’exécution du listing 3.10 produit le code bas niveau du listing 1.1 côté client et du listing 1.2 côté serveur. 3.3.1 Représentation statiquement typée de chaînes de caractères contenant des expressions JavaScript Il est possible de définir, dans un document HTML, le code JavaScript à exécuter lorsqu’un événement se produit sur un élément HTML donné. Ainsi, le listing HTML 3.14 définit un élément exécutant le code JavaScript alert(’clicked’) lorsque l’utilisateur clique dessus.Définition de fragments de HTML 51 case Tag(name , children , attrs) => emitValDef(sym , src"document.createElement(’$name ’)") for ((n, v) <- attrs) { gen"$sym.setAttribute(’$n’, $v);" } children match { case Left(children) => for (child <- children) { gen"$sym.appendChild($child );" } case Right(children) => val x = fresh[Int] gen"""for (var $x = 0; $x < $children.length; $x++) { $sym.appendChild($children[$x]); }""" } case Text(content) => emitValDef(sym , src"document.createTextNode($content)") Listing 3.12 – Générateur de code JavaScript pour l’unité de langage de définition de contenus Web case Tag(name , children , attrs) => val attrsFormatted = (for ((name , value) <- attrs) yield src" $name=$${$value}"). mkString children match { case Left(children) => if (children.isEmpty) { emitValDef(sym , src"html \"\"\" < $name$attrsFormatted / >\"\"\"") } else { val qc = children.map(quote) emitValDef(sym , src"html \"\"\" < $name$attrsFormatted >$${$qc}\"\"\"" ) } case Right(children) => emitValDef(sym , src"html \"\"\" < $name$attrsFormatted >$${$children}\"\"\"" ) } case Text(content) => emitValDef(sym , src"html \"\"\" $${$content }\"\"\"") Listing 3.13 – Générateur de code Scala pour l’unité de langage de définition de contenus Web52 Partage de code
click me
Listing 3.14 – Code JavaScript inclus dans une chaîne de caractères el(’div , ’onclick -> "println (\" clicked \")")("click me") Listing 3.15 – Code Scala inclus dans une chaîne de caractères Il n’est pas possible de représenter de telles constructions avec Forest car nous n’avons pas de moyen d’obtenir, à l’intérieur d’un programme js-scala, la représentation textuelle d’un programme JavaScript à partir de sa représentation abstraite. Si nous écrivions du code Scala directement dans une chaîne de caractères, cela serait fragile car notre code Scala ne bénéficierait pas des vérifications de type apportées par le compilateur Scala, mais cela serait surtout incorrect car les navigateurs Web ne sauraient pas interpréter le code Scala. Le listing 3.15 illustre ce non-sens. Ce que nous voulons, c’est désigner une expression Scala et obtenir la représentation textuelle du code JavaScript correspondant. Nous pouvons résoudre ce problème en introduisant un nouveau mécanisme : une fonction quote qui prendrait en paramètre, sans l’évaluer, une expression Scala représentant un programme JavaScript, et retournerait une représentation textuelle de cette expression. La signature de cette fonction est donnée dans le listing 3.16. Le listing 3.17 montre comment s’appuyer sur cette fonction pour implémenter l’équivalent du listing 3.14 avec Forest, de façon statiquement typée. La fonction quote crée d’abord une fonction sans paramètre qui se contente d’évaluer l’expression donnée, puis retourne un nœud pour lequel le générateur de code JavaScript produit une chaîne de caractères contenant l’appel de la fonction produite à la première étape. Le code JavaScript généré par le listing 3.17 est donné dans le listing 3.18. 3.4 Validation 3.4.1 Objectifs Les objectifs des travaux rapportés dans ce chapitre sont, d’une part, de proposer des abstractions de haut niveau, éventuellement utilisables côtés client et serveur, produisant du code efficace. Et, d’autre part, de proposer une méthode générale pour construire, à moindre effort, de telles abstractions efficaces et dédiées au développement d’applications Web. def quote[A](a: => Rep[A]): Rep[String] Listing 3.16 – Signature de la fonction quoteValidation 53 el(’div , ’onclick -> quote { println("clicked") })("click me") Listing 3.17 – Génération d’une chaîne de caractères contenant du code JavaScript var x1 = function () { alert(’clicked ’); }; var x0 = document.createElement(’div’); x0.setAttribute(’onclick ’, ’x1()’); x0.textContent = ’click me’; Listing 3.18 – Code généré par le listing 3.17 3.4.2 Expérience Pour évaluer si notre premier objectif est atteint, nous nous appuyons sur une validation empirique. Mesures Nous utilisons, comme approximation inverse du niveau d’abstraction, le nombre de lignes de code que l’utilisateur doit écrire (plus un code est concis, plus il est haut niveau). Nous mesurons l’efficacité d’un programme par sa vitesse d’exécution (plus un programme s’exécute vite, plus il est efficace). Nous évaluons le niveau d’abstraction et l’efficacité de notre solution, que nous comparons aux autres approches actuelles permettant de partager du code entre les côtés client et serveur. Hypothèses Les hypothèses testées sont les suivantes : H1 l’utilisation de nos unités de langage montre de meilleures performances par rapport au nombre de lignes de code que les approches alternatives ; H2 nos unités de langage sont utilisables côtés client et serveur. Méthode Nous avons écrit plusieurs tests de performance sur des programmes ciblant l’utilisation d’unités de langages en particulier, et sur une application réelle. À chaque fois, nous avons écrit différentes implémentations du programme, en JavaScript, Java/GWT, HaXe et js-scala (avec nos unités de langages). Nous avons fait un effort pour respecter le style de programmation de chaque langage. Les tests de performance ont été effectués sur un ordinateur portable DELL Latitude E6430 avec 8 Go de mémoire RAM, dans le navigateur Google Chrome version 27. Les graphiques reflètent les types de mesures qui ont été effectuées : le premier groupe de mesures est la vitesse d’exécution du code JavaScript (plus l’indice est élevé, mieux c’est), le deuxième groupe mesure le nombre de lignes de code (plus l’indice est54 Partage de code Figure 3.3 – Tests de performance sur un programme utilisant l’API des sélecteurs bas, mieux c’est), et le troisième groupe montre le rapport entre la vitesse d’exécution et le nombre de lignes de code (plus l’indice est haut, mieux c’est). Les valeurs ont été normalisées de façon à ce que les graphiques puissent être affichés côte à côte sans problème d’échelle verticale. 3.4.2.1 Programmes ciblant des unités de langages Nous avons écrit des petits programmes utilisant spécifiquement l’API des sélécteurs et de manipulation de valeurs optionnelles 1 . Sélécteurs Cette abstraction ne pouvant pas être implémentée avec GWT ou HaXe puisque ces langages ne fournissent pas de mécanisme d’évaluation partielle, nous avons comparé les temps d’exécution du code JavaScript généré par le listing 3.3 avec le temps d’exécution d’un programme similaire au listing 3.1, mais utilisant seulement les fonctions haut niveau querySelector et querySelectorAll. Le programme a été exécuté dans une page Web contenant les éléments suivants : quatre éléments fieldset, chacun contenant jusqu’à deux éléments ayant pour classe word. La figure 3.3 montre les résultats du test de performance. La version JavaScriptopt correspond au listing 3.1 (qui utilise les fonctions bas niveau getElementById, getElementsByTagName et getElementsByClassName), la version JavaScript correspond au programme équivalent utilisant seulement l’API native haut niveau (c’est-à-dire 1. Le code des programmes utilisés pour réaliser les tests de performance est disponible à l’adresse suivante : https://github.com/js-scala/js-scala/tree/master/papers/gpce2013/benchmarks.Validation 55 val maybe = fun { (x: Rep[Int]) => some(x + 1) } def benchmark = for { a <- maybe (0) b <- maybe(a) c <- maybe(b) d <- maybe(c) } yield d Listing 3.19 – Programme manipulant des valeurs optionnelles les fonctions querySelector et querySelectorAll) et la version jQuery correspond au listing 3.2. La version js-scala est légèrement plus lente que la version JavaScript-opt (d’environ 14%), mais est 2.88 fois plus rapide que la version JavaScript, et 28.6 fois plus rapide que la version jQuery. Enfin, la version js-scala a un rapport performance sur nombre de lignes de code plus de 1.72 fois meilleur que les autres versions. Valeurs optionnelles Nous avons implémenté l’abstraction de manipulation de valeurs optionnelles en JavaScript pur, Java et HaXe, et avons écrit un programme manipulant des valeurs optionnelles. Le listing 3.19 montre la version js-scala du programme. La fonction maybe est une fonction partiellement définie sur les valeurs de type Int. La figure 3.4 montre les résultats du test de performance. La version js-scala est 3 à 10 fois plus rapide que les autres versions. Cette version est également la plus concise (cela provient essentiellement de la syntaxe for, qui n’a pas d’équivalent dans les autres langages). Finalement, la version js-scala a un rapport performance sur lignes de code plus de 4 fois supérieur aux autres versions. 3.4.2.2 Application réelle Chooze 2 est une application complète pour effectuer des sondages en ligne. L’application permet aux utilisateurs de créer des sondages, de définir les différents choix possibles pour une question, de partager un sondage avec d’autres personnes, de voter et de consulter les résultats. L’application contient du code JavaScript pour gérer le comportement dynamique de l’application : interdiction d’une double soumission d’un vote, mise à jour du formulaire de création de sondage, interactions avec l’interface utilisateur, etc. La taille totale de l’application (incluant les côtés client et serveur) est de l’ordre du millier de lignes de code. 2. Le code source est disponible à l’adresse http://github.com/julienrf/chooze, dans les branches vanilla, jquery, gwt, haxe and js-scala.56 Partage de code Figure 3.4 – Tests de performance sur un programme manipulant des valeurs optionnelles L’application a été initialement écrite avec jQuery. Nous l’avons réécrite en JavaScript pur (version « vanilla », bas niveau et optimisé, sans utilisation de bibliothèque tierce), js-scala, GWT et HaXe. Tests de performance Le test de performance a mesuré le temps d’exécution d’un scénario d’utilisation : 2000 clics sur un bouton ajoutant un champ de formulaire. Le code impliqué utilise les API de manipulation de valeurs optionnelles, de sélécteurs et de définition de contenus Web. La figure 3.5 montre les résultats du test. Les performances d’exécution des versions vanilla, HaXe et js-scala sont similaires (bien que la version js-scala soit légèrement moins rapide, de 6%). Il est notable que les versions vanilla et HaXe utilisent toutes les deux du code bas niveau comparé à la version js-scala, comme le souligne la partie au milieu de la figure : la version js-scala tient en 74 lignes de code, tandis que la version vanilla tient en 116 lignes de code (57% plus longue) et la version HaXe tient en 148 lignes de code (100% plus longue). La version jQuery, dont le code est haut niveau (54 lignes de code, 27% plus concise que la version js-scala) est 10 fois plus lente que la version js-scala. La dernière partie de la figure montre que la version js-scala dispose du meilleur rapport performances sur nombre de lignes de code. Ce rapport est 1.48 fois meilleur que pour la version vanilla, 1.88 fois meilleur que pour la version HaXe, 3.45 fois meilleur que pour la version GWT et 7.82 fois meilleur que pour la version jQuery.Validation 57 Figure 3.5 – Tests de performance sur une application réelle Réutilisation de code La version js-scala du programme nous a permis de réutiliser quelques définitions de contenus Web entre les côtés client et serveur. Avec GWT nous n’avons pas le choix : le contenu des pages est forcément construit côté client. Dans les autres versions, le code définissant le contenu des pages est dupliqué entre les côtés client et serveur. Cela représente 20 lignes de code JavaScript (17% du total) et 15 lignes de HTML (5% du total) dans la version vanilla, 19 lignes de HaXe (13% du total) et 15 lignes de HTML (5% du total) dans la version HaXe. Dans la version js-scala, les définitions de fragments Web partagées entre les côtés client et serveur représentent 22 lignes de Scala (30% du total) et ont permis d’économiser 15 lignes de HTML (5% du total). 3.4.3 Discussion 3.4.3.1 Analyse des résultats Nos résultats montrent que le code haut niveau écrit avec js-scala génère du code JavaScript bas niveau dont les performances d’exécution sont du même ordre de grandeur que du code JavaScript optimisé à la main. Les tests ciblant l’utilisation d’une abstraction en particulier montrent de bons résultats, comme attendu. Les gains sur le rapport entre les performances d’exécution et le nombre de lignes de code varient d’un facteur 1.72 à 30 selon les technologies comparées. Le test sur une application réelle permet de tenir compte de la place relative, dans une application complète, des gains individuels décrits au paragraphe précédent. Ce58 Partage de code test affiche tout de même un gain sur le rapport entre les performances d’exécution et le nombre de lignes de code variant d’un facteur 1.48 à 7.82. Ces résultats valident l’hypothèse H1 : le rapport entre les performances et le nombre de lignes de code est meilleur avec nos unités de langage qu’avec les approches alternatives. Nos tests montrent également qu’une partie du code d’une application réelle peut être partagée entre les parties client et serveur, ce qui valide l’hypothèse H2. 3.4.3.2 Limites de notre validation Mesure du niveau d’abstraction Notre objectif est de mettre en perspective les performances d’exécution par rapport au niveau d’abstraction. Nous avons choisi le nombre de lignes de code comme indicateur de l’inverse du niveau d’abstraction. Or, ce choix n’est pas sientifiquement établi. Cependant, aucune autre métrique n’a été proposée par la communauté scientifique pour mesurer le niveau d’abstraction. Différences de concision propres aux langages Nous comparons la concision du code dans plusieurs langages. Or, la syntaxe propre à chaque langage peut introduire des différences inter-langages indépendantes du niveau d’abstraction. Par exemple, la taille du programme Java utilisant le langage de manipulation de valeurs optionnelles pourrait être quasiment divisée par deux en utilisant les ❧❛♠❜❞❛ ❡①♣r❡ss✐♦♥s [Jav]. Cependant, il n’existe aucun travail scientifique fournissant un facteur de correction pour gommer ces différences. Représentativité des tests effectués Il n’est pas correct d’extrapoler les résultats des tests de performance, obtenus sur l’application réelle, à toutes les applications Web. Cependant, l’application que nous avons utilisée était de taille modeste et contenait peu de code côté client. Nous pensons donc que sur des applications de taille plus grosses et implémentant plus de fonctionnalités côté client, les tests pencheraient encore plus en faveur de js-scala. Respect du style idiomatique des technologies comparées Pour gérer l’interface utilisateur, la version GWT n’utilise pas la bibliothèque de composants fournie par GWT. Au lieu de cela, nous interceptons les événements directement au niveau du DOM, comme nous le ferions en JavaScript pur. Cependant, cette façon d’utiliser GWT n’a pas d’impact sur les performances et a seulement un impact marginal sur la concision du code. 3.5 Conclusion Les abstractions de haut niveau permettent à la fois de réduire la complexité du code et, dans le cas des applications Web, de masquer les différences entre les environnements client et serveur. Cependant, outre le coût en performance des abstractions,Conclusion 59 en masquant les différences d’environnements client et serveur l’utilisateur perd l’opportunité d’exploiter leurs spécificités. En implémentant nos abstractions sous forme de bibliothèques générant du code, nous conservons les avantages apportés par les abstractions concernant le confort d’ingénierie. Mais nous avons également la possibilité de générer du code efficace, capable de tirer parti des spécificités des environnements client et serveur. Bien que le coût initial de cette approche soit non négligeable (il faut implémenter des générateurs de code pour un langage généraliste), l’ajout d’abstractions dédiés à un problème donné nécessite peu d’efforts pour l’utilisateur : la définition d’une API, une implémentation retournant une représentation abstraite de programme, et un générateur de code pour cette représentation abstraite, pour chaque plateforme ciblée. Tous ces composants peuvent être définis de façon indépendante, sans qu’il ne soit nécessaire de modifier le code d’un compilateur existant. Ainsi, nous avons implémenté des unités de langage pour rechercher des éléments dans une page Web, manipuler des valeurs optionnelles, et représenter des contenus Web. Le code écrit avec les deux dernières unités de langage peut être partagé côtés client et serveur. Ces abstractions produisent du code exploitant les spécificités des environnements client et serveur. Enfin, les performances d’exécution sont du même ordre de grandeur que du code bas niveau optimisé à la main.60 Partage de codeChapitre 4 Sûreté du typage Ce chapitre présente une solution au problème de l’exposition des interfaces de programmation du navigateur Web dans un langage statiquement typé. Nous commençons par détailler les limites des solutions actuelles puis nous présentons deux solutions préservant un maximum d’informations dans les types tout en donnant autant de pouvoir d’expression aux utilisateurs. La seconde solution est plus pratique pour l’utilisateur mais s’appuie sur le concept de t②♣❡s ❞é♣❡♥❞❛♥ts, peu répandu dans les systèmes de type des langages généralistes. Le contenu de ce chapitre a fait l’objet d’une publication [RFBJ14]. 4.1 Inventaire des fonctions problématiques Illustrons les difficultés à définir des signatures de type pour des APIs dynamiquement typées en prenant comme exemples quelques-unes des principales 1 fonctions de l’API du navigateur : createElement, getElementsByTagName et addEventListener 2 . 4.1.1 createElement Cette fonction, ainsi que les difficultés pour lui donner une signature de type dans un langage statiquement typé, ont été présentées dans les chapitres 1 et 2. La suite de cette section détaille les différentes signatures de type proposées pour cette fonction par les langages de programmation statiquement typés courants. 4.1.1.1 Signatures de type proposées par les langages actuels API trop générale La première solution consiste simplement à conserver la même signature de type et à imposer au programmeur d’effectuer une opération de trans- 1. D’après le Mozilla Developer Network (https://developer.mozilla.org/en-US/docs/DOM/DOM Reference/Introduction). 2. Nous présentons seulement les fonctions pour lesquelles il est difficile de définir une signature de type. 6162 Sûreté du typage typage (t②♣❡ ❝❛st) pour obtenir une valeur d’un type plus précis. Une telle solution ressemblerait, à l’utilisation, en Scala, au listing suivant : val img = createElement("img"). asInstanceOf[ImageElement] img.src = "/icon.png" // Ok img.value = "foo" // Erreur: propriete ’value’ non definie Évidemment, l’utilisation d’opérations de transtypage introduit une fragilité allant à l’encontre de l’utilisation même d’un langage statiquement typé. API trop spécifique Une autre solution consiste à définir des fonctions distinctes, retournant chacune un type d’élément spécifique, plutôt qu’une seule fonction avec pour type de retour Element. Ainsi, au lieu d’avoir une seule fonction, createElement, il s’agit d’exposer autant de fonctions qu’il y a de types d’éléments possibles, par exemple createImgElement, createInputElement, etc : def createImgElement (): ImageElement def createInputElement (): InputElement etc. L’utilisation d’une telle solution est illustrée par le listing suivant : val img = createImgElement () img.src = "/icon.png" // Ok img.value = "foo" // Erreur: propriete ’value’ non definie L’inconvénient de cette solution, évoqué dans la section 2.3 est qu’elle réduit le pouvoir d’expression de l’API. En effet, cette solution utilise des fonctions plus spé- cifiques que la fonction initiale ce qui rend impossible l’implémentation de certains programmes, qu’il est pourtant possible d’implémenter avec la fonction initiale, plus générale. 4.1.2 getElementsByTagName 4.1.2.1 Description La fonction getElementsByTagName prend en paramètre un nom d’élément HTML et retourne l’ensemble des éléments de ce type dans le document. Sa signature est la suivante : HTMLCollection getElementsByTagName(String name); Le type HTMLCollection représente un tableau d’Elements HTML. Le problème rencontré avec cette fonction est similaire à celui posé par la fonction createElement : les éléments retournés ont un type trop général. En effet, l’expression getElementsByTagName(’input’) retourne un tableau de InputElement mais la signature de type n’expose que le type général Element.Inventaire des fonctions problématiques 63 4.1.2.2 Signatures de type proposées par les langages actuels Les langages statiquement typés conservent la signature de type standard pour cette fonction. Ils exposent donc un type de retour trop général, obligeant les utilisateurs à effectuer des opérations de transtypage sur le résultat. 4.1.3 addEventListener 4.1.3.1 Description La fonction addEventListener permet de réagir aux événements produits par l’utilisateur d’une application Web. Elle prend en paramètre un type d’événement et une fonction à appeler lorsqu’un tel événement se produit : void addEventListener(String type, Function callback ); Le type Function est peu précis, il représente une fonction prenant un nombre arbitraire de paramètres dont les types sont également arbitraires. Le listing suivant montre comment l’utiliser, en JavaScript, pour réagir aux clics et appuis de touches de l’utilisateur : document.addEventListener(’click’, function (event) { console.log(event.button ); }); document.addEventListener(’keydown ’, function (event) { console.log(event.key); }) Ce listing affiche les valeurs de la propriété button de l’événement représentant chaque clic et de la propriété key de l’événement représentant chaque appui de touche. Ici encore, dans un monde statiquement typé, le code ci-dessus produirait une erreur de typage car le type de l’objet event est indéfini, donc il ne possède pas de propriétés button ou key. Notons que la propriété button est définie par le type MouseEvent et la propriété key est définie par le type KeyboardEvent. Ainsi, on aimerait, idéalement, trouver une signature de type pour la fonction addEventListener telle que le listing suivant, en Scala, compile sans erreur, sauf l’avant-dernière ligne : document.addEventListener("click", event => { println(event.button) println(event.key) // Erreur: propriete ’key’ non definie }) De même, le listing suivant doit compiler, sauf l’avant-dernière ligne : document.addEventListener("keydown", event => { println(event.key) println(event.button) // Erreur: propriete ’button ’ non definie })64 Sûreté du typage Autrement dit, le type de l’objet event doit être MouseEvent lorsque l’utilisateur ré- agit à l’événement "click", et KeyboardEvent lorsque l’utilisateur réagit à l’événement "keydown". 4.1.3.2 Signatures de type proposées par les langages actuels API trop générale Comme précédemment, la première solution consiste à conserver une signature de type trop générale et donc à imposer à l’utilisateur d’effectuer une opération de transtypage pour obtenir une valeur d’un type plus précis. Une telle signature de type serait la suivante, en Scala : def addEventListener(event: String , callback: Event => Unit): Unit Cette solution souffre des même inconvénients que ceux décrits précédemment. API trop spécifique Une autre solution consiste à définir des fonctions distinctes pour réagir aux différents types d’événements plutôt qu’une seule fonction trop géné- rale : def addClickEventListener(callback: MouseEvent => Unit): Unit def addKeyDownEventListener(callback: KeyboardEvent => Unit): Unit etc. L’inconvénient de cette solution est qu’elle réduit le pouvoir d’expression de l’API. En effet, cette solution utilise des fonctions plus spécifiques que la fonction initiale, rendant impossible l’implémentation de certains programmes, qu’il est pourtant possible d’implémenter avec la fonction initiale, plus générale. Par exemple, le programme JavaScript suivant ne peut pas être implémenté : var observe = function (type) { return function (callback) { document.addEventListener(type, callback ); } }; Ce programme définit une fonction observe réalisant une application partielle des paramètres de la fonction addEventListener 3 . Une variante rencontrée consiste à définir un type abstrait EventListener, ne comportant aucune opération, et autant de sous-types qu’il y a de genres d’événements possibles, chacun comportant une seule opération abstraite correspondant au callback. Il est ensuite possible de définir une seule opération, addEventListener, prenant en paramètre un EventListener : sealed trait EventListener abstract class ClickListener(callback: MouseEvent => Unit) extends EventListener abstract class KeyDownListener(callback: KeyboardEvent => Unit) extends EventListener etc. 3. Le code de cette fonction est inspiré des bibliothèques JavaScript existantes de programmation fonctionnelle réactive : Rx.js [LB11] et Bacon.js [Bac]Solutions bien typés et conservant le même pouvoir d’expression 65 def addEventListener(listener: EventListener ): Unit Cette solution souffre du même problème de réduction du pouvoir d’expression de l’API initiale du navigateur. 4.1.4 Discussion Les solutions actuellement implémentées par les langages de programmation statiquement typés produisant du JavaScript soit réduisent le pouvoir d’expression soit ne sont pas bien typées. 4.2 Solutions bien typés et conservant le même pouvoir d’expression 4.2.1 Généralisation des solutions existantes Les solutions bien typées existantes réduisent toutes le pouvoir d’expression de l’utilisateur. Elles ont toutes un point commun : elles réduisent le nombre de paramètres passés par l’utilisateur. Par exemple, au lieu d’écrire : addEventListener("click", callback) l’utisateur écrit : addEventListener(new ClickListener(callback )) ou : addClickEventListener(callback) Dans les deux cas, le paramètre correspondant au nom de l’événement, "click", disparaît. De même, au lieu d’écrire : createElement("img") l’utilisateur écrit : createImgElement () Le paramètre correspondant au nom de l’élément n’est plus présent. Cette solution permet de distinguer entre les différents noms d’événements ou d’éléments HTML en utilisant des noms de fonction différents. Chaque nom correspond à une fonction dont la signature expose des types plus précis que la fonction, plus générale, de l’API native du navigateur. Plus précisément, cette solution remplace un paramètre, dont la signature de type de la fonction dépend, par un nom constant. C’est parce que cette solution élimine un paramètre de la fonction initiale qu’elle est moins expressive. Notons que cette solution ne fonctionne que parce que la plage de valeurs possibles pour ces paramètres est connue à l’avance et fixée : la fonction createElement ne prend en paramètre que des noms d’éléments HTML. De même, la fonction addEventListener ne prend en paramètre que des noms d’événements.66 Sûreté du typage 4.2.2 Utilisation des types paramétrés Notre but est de trouver, pour les fonctions présentées précédemment, une signature de type qui ne réduise pas le pouvoir d’expression et qui soit bien typée (ou qui ne contraigne pas l’utilisateur à écrire du code mal typé). Il est possible de représenter la relation de dépendence entre un type T et un paramètre p impliqués dans une fonction en procédant comme suit : — définir un type paramétré P[U], — affecter le type P[U] au paramètre p, — remplacer les occurrences de T par U, — définir autant de valeurs de type P[U] qu’il y a de valeurs possibles pour p, chacune fixant le paramètre de type U à un type plus précis. L’application de cette solution aux fonctions createElement et getElementsByTagName est illustrée par le code suivant : class ElementName[E] def createElement[E](name: ElementName[E]): E def getElementsByTagName[E](name: ElementName[E]): Array[E] val Img = new ElementName[ImageElement] val Input = new ElementName[InputElement] // etc. pour chaque nom d’element possible Les deux fonctions, createElement et getElementsByTagName, ont leur type de retour (Element ou Array[Element] dans l’API initiale) qui dépend de la valeur d’un paramètre name. Nous introduisons un type ElementName[E], et attribuons ce type, plutôt que String, au paramètre name. Nous attribuons également le type E plutôt qu’Element au type de retour de la fonction (ou Array[E] plutôt que Array[Element], dans le cas de getElementsByTagName). Enfin, nous définissons autant de valeurs, Img, Input, etc. qu’il y a de types d’éléments HTML possibles. L’idée essentielle de notre solution consiste à utiliser des types différents pour représenter les différents noms d’éléments HTML (✐✳❡✳ le type ElementName[ImageElement] pour l’élément img, le type ElementName[InputElement] pour l’élément input, etc.), et à s’appuyer sur un mécanisme (les types paramétrés) permettant de retrouver le type d’un élément à partir du type du nom de l’élément : le type ElementName[E] définit la relation entre un nom d’élément HTML et son type. Le paramètre de type E est parfois appelé t②♣❡ ❢❛♥tô♠❡ car les valeurs de type ElementName[E] ne contiennent jamais de valeur de type E [LM99]. Le listing suivant montre l’utilisation de notre solution : val img = createElement(Img) img.src = "/icon.png" // Ok img.value = "foo" // Erreur L’utilisation de la valeur Img fixe le type du paramètre name à ElementName[ImageElement], et, par conséquent, fixe le type de retour de l’appel à la fonction createElement à ImageElement.Solutions bien typés et conservant le même pouvoir d’expression 67 Ainsi, notre solution est bien typée. En outre, notre solution ne réduit pas le pouvoir d’expression de l’utilisateur car elle ne réduit pas le nombre de paramètres de la fonction. Il est donc possible d’implémenter la fonction createTwoElements comme suit : createTwoElements[A, B](fst: ElementName[A], snd: ElementName[B]): (A, B) = (createElement(fst), createElement(snd)) La même solution est applicable à la fonction addEventListener : class EventName[E] def addEventListener[E](name: EventName[E])( callback: E => Unit): Unit val Click = new EventName[MouseEvent] val KeyDown = new EventName[KeyboardEvent] // etc. pour chaque nom d’evenement possible L’utilisation est la suivante : addEventListener(Click) { event => println(event.button) } Comme précédemment, notre solution est bien typée et donne autant de pouvoir d’expression à l’utilisateur. Nous sommes ainsi capable d’implémenter la fonction observe : def observe(name: EventName[A]): (A => Unit) => Unit = callback => addEventListener(name)( callback) Notre solution comporte cependant un inconvénient à l’utilisation : toute fonction prenant en paramètre un nom d’élément HTML ou un nom d’événement doit également prendre un paramètre de type (un type fantôme), correspondant au type de l’élément HTML ou de l’événement désigné. En effet, la fonction createTwoElements prend deux paramètres de type, A et B, et la fonction observe prend un paramètre de type, A. 4.2.3 Utilisation des types dépendants Cette section montre comment nous pouvons nous débarrasser des type fantômes introduits dans la section précédente en utilisant des types ❝❤❡♠✐♥✲❞é♣❡♥❞❛♥ts [OCRZ03]. Plus précisément nous représentons les paramètres de type en utilisant des types ♠❡♠❜r❡s, comme cela a été décrit dans [OZ05]. 4.2.3.1 Types membres Les types membres étant peu présents dans les langages de programmation géné- ralistes, commençons par rappeler ce concept. Les langages de programmation gèrent en général deux mécanismes généraux d’abstraction : les paramètres et les membres abstraits. Par exemple, le langage Java gère68 Sûreté du typage la paramétrisation des valeurs (paramètres de méthodes) et des types (❣❡♥❡r✐❝s) et les membres abstraits pour les valeurs (méthodes abstraites). Illustrons la différence entre les paramètres et les membres par un exemple. Supposons que l’on veuille écrire une classe réalisant une addition entre deux nombres. Nous souhaitons que notre classe soit capable d’additionner deux nombres quels qu’ils soient. Autrement dit, nous souhaitons que les nombres à additionner soit abstraits pour la classe. Nous pouvons réaliser cela en écrivant une méthode paramétrée par les nombres à additionner, comme suit : class Plus { public int apply(int a, int b) { return a + b; } } Une autre façon de faire, tout à fait équivalente, consiste à utiliser des membres abstraits pour représenter les nombres à additionner : abstract class Plus { abstract int a(); abstract int b(); public int apply() { return a() + b(); } } Ainsi, les paramètres et les membres sont deux moyens de généralisation équivalents. Dans le cas de Java, le langage gère à la fois les paramètres et les membres pour généraliser au niveau valeur, mais il ne gère que les paramètres pour généraliser au niveau type (les ❣❡♥❡r✐❝s). Le langage Scala, quant à lui, gère à la fois les paramètres et les membres pour gé- néraliser au niveau type [CGLO06, OCRZ03]. Illustrons ce concept avec, par exemple, un type représentant une collection d’objets, générique, contenant des objets ayant tous le même type. Nous pouvons représenter une telle collection avec le type suivant : trait Collection[A] { def get(i: Int): A } Le paramètre de type A représente le type des éléments contenus dans une collection donnée. Par exemple, le type Collection[Int] représente une collection spéci- fique, contenant uniquement des nombres entiers. Nous pouvons représenter la même collection générique en utilisant un type membre à la place du paramètre de type A : trait Collection { type A def get(i: Int): A }Solutions bien typés et conservant le même pouvoir d’expression 69 Nous pouvons spécialiser le type Collection pour ne contenir que des nombres entiers en instanciant le type membre A comme suit : trait IntCollection extends Collection { type A = Int } L’instanciation d’un type membre est l’équivalent au niveau type de l’implémentation d’une méthode abstraite au niveau valeur. Enfin, il est possible de faire référence au type membre A depuis l’extérieur du trait Collection comme suit : def head(collection: Collection ): collection.A = collection.get(0) La méthode head récupère le premier élément d’une collection donnée. Son type de retour, collection.A, correspond à l’instance du type membre A de la collection passée en paramètre. Plus généralement, un type membre abstrait d’une classe est un type interne qui peut être utilisé pour qualifier des valeurs et qui peut être instancié par des sousclasses. Depuis l’extérieur de la classe, on peut désigner un type membre en effectuant une sélection de type sur une instance de la classe : l’expression p.C désigne le type membre C d’une valeur p, et correspond à l’instance de C du type singleton de la valeur p. 4.2.3.2 Utilisation des types membres Le type ElementName[E] peut être réécrit à l’aide d’un type membre comme suit : abstract class ElementName { type Element } val Img = new ElementName { type Element = ImageElement } val Input = new ElementName { type Element = InputElement } // etc. def createElement(name: ElementName ): name.Element Nous avons remplacé le paramètre de type E par un type membre Element. Les valeurs Img, Input, etc. instancient ce membre en lui donnant le type d’élément HTML correspondant. Enfin, la fonction createElement retourne une valeur de type name.Element, correspondant à l’instance du membre Element pour leur paramètre name. Utilisation : val img = createElement(Img) img.src = "/icon.png" // Ok img.value = "foo" // Erreur70 Sûreté du typage Cette représentation conserve autant de pouvoir d’expression que la précédente, comme en atteste l’implémentation suivante de la fonction createTwoElements : def createTwoElements(fst: ElementName , snd: ElementName ): (fst.Element , snd.Element) = (createElement(fst), createElement(snd)) Enfin, le même procédé s’applique au type EventName : trait EventName { type Event } object Click extends EventName { type Event = MouseEvent } // etc. pour chaque nom d’evenement possible def addEventListener(name: EventName) (callback: name.Event = > Unit): Unit def observe(name: EventName ): (name.Event => Unit) => Unit = callback => document.addEventListener(name)( callback) Notons que les fonctions createTwoElements et observe ne comportent plus de types fantômes. 4.3 Discussion 4.3.1 Analyse Implémentation dans js-scala Nous avons implémenté, au sein du projet js-scala, une API basée sur la solution utilisant les types chemin-dépendants. Nous avons également implémenté plusieurs applications utilisant cette API, notamment une application de discussion instantanée et une application de sondages. La taille de ces applications est de l’ordre de plusieurs centaines de lignes de code. Du fait que notre API est bien typée, le code est exempt d’opérations de transtypage. Clarté de l’API Notre solution offre une correspondance un pour un avec l’API native du navigateur. À titre de comparaison, les solutions existantes bien typées font souvent correspondre une seule fonction de l’API native à plus de 30 fonctions. Ainsi, GWT fait correspondre 31 fonctions spécialisées pour la fonction createElement, et Dart en fait correspondre 62. De même, GWT fait correspondre 32 fonctions spécialisées pour la fonction addEventListener, et Dart en fait correspondre 49. Notre solution a l’avantage d’être bien typée sans multiplier le nombre de fonctions ayant un rôle similaire. Commodité syntaxique Les annotations de type des langages à typage statique peuvent être perçues par le développeur comme une complexité indésirable. Dans notre cas,Conclusion 71 la solution s’appuyant sur des types paramétrés est utilisable avec de nombreux langages généralistes tels que Java, Dart, TypeScript, Kotlin, HaXe, Opa, Idris ou Elm. Cependant cette solution nécessite d’inclure des types fantômes, indésirables, dans les signatures des fonctions prenant en paramètre des noms d’événements ou d’éléments HTML. La seconde solution, en revanche, conduit à des signatures de fonctions d’une verbosité équivalente à celle de la spécification standard des API HTML et DOM. Nous estimons qu’il n’y a, dans ce cas, pas de prix syntaxique à payer. Cependant, cette solution n’est utilisable qu’avec des langages supportant les types dépendants, tels que Scala, Idris ou Agda. 4.3.2 Limitations Nos solutions remplacent un paramètre de type String par un paramètre d’un type plus précis permettant de déduire le type de l’élément ou événement correspondant. Ce faisant, nos solutions diminuent légèrement le pouvoir d’expression par rapport à l’API native : il n’est plus possible, par exemple, de passer en paramètre une valeur résultant de la concaténation de deux chaînes de caractères ou d’une quelconque autre opération de manipulation de chaîne de caractères. Nos solutions s’appliquent seulement aux fonctions dont la signature comporte des types qui dépendent de la valeur d’un des paramètres. Si ce genre de fonctions est commun dans les API JavaScript, ce n’est pas le cas de toutes les fonctions. Par exemple, la fonction getElementById ne peut pas bénéficier de notre solution. Cette fonction récupère un élément du document à partir de la valeur de son attribut id, or le type de l’élément ne peut pas être déduit depuis la valeur de cet attribut. 4.4 Conclusion S’appuyer sur un langage statiquement typé produisant du JavaScript n’est pas suffisant pour profiter du typage statique pour le développement de la partie client d’une application Web. En effet, l’API du navigateur Web doit également être exposée dans ce langage et son système de type. Or, cela n’est pas facile à réaliser pour certaines fonctions et conduit généralement soit à perdre en sûreté de typage, soit à perdre en pouvoir d’expression. Dans ce chapitre, nous avons présenté deux méthodes pour exposer les fonctions problématiques de cette API. La première méthode s’appuie sur les types paramétrés et est utilisable avec la plupart des langages de programmation courants (❡✳❣✳ Java ou C#). La seconde méthode apporte un confort syntaxique supplémentaire et nécessite que le langage gère les types dépendants (❡✳❣✳ Scala). Nos deux méthodes évitent aux développeurs d’avoir recours à des opérations de transtypage non sûres et conservent le même pouvoir d’expression que les fonctions natives. Nos résultats suggèrent que la prise en charge des types dépendants peut être un atout pour les langages à typage statique ciblant la programmation Web.72 Sûreté du typageChapitre 5 Un style d’architecture pour les applications Web résilientes Ce chapitre présente une approche pour développer des applications Web résilientes par construction. Nous nous appuyons, pour cela, sur un style d’architecture découpant le code de l’application de telle sorte qu’il soit à la fois facile pour les dé- veloppeurs de raisonner dessus, et facile techniquement d’implémenter les différents aspects de façon réutilisable et indépendamment les uns des autres. La suite de ce chapitre donne une vision générale du style d’architecture puis montre progressivement, en détaillant certaines parties, comment il répond à nos objectifs. 5.1 Présentation générale La figure 5.1 donne une vue d’ensemble des différents composants impliqués dans notre style d’architecture. Nous nous appuyons sur plusieurs concepts présentés dans l’état de l’art. Les client et serveur contiennent tous les deux des composants simiFigure 5.1 – Vue d’ensemble de notre style d’architecture pour applications Web résilientes 7374 Un style d’architecture pour les applications Web résilientes laires : Model Données représentant l’état du système ; View Affichage d’informations destiné aux utilisateurs ; Control Interprétation des actions de l’utilisateur en termes d’actions métier (p. ex. un clic de l’utilisateur est traduit en une action de suppression de tâche), actualisation du ▼♦❞❡❧ et de la ❱✐❡✇ ; Sync Synchronisation de l’état du système entre clients et serveurs. Les spécificités de cette architecture sont les suivantes : — La communication client-serveur se situe au niveau ❈♦♥tr♦❧ (tout comme dans le modèle PAC-C3D) plutôt que ▼♦❞❡❧ (comme c’est le cas dans les modèles dérivées de MVC présentés dans l’état de l’art) ; — Le composant de synchronisation côté client est intercalé entre les composants de contrôle client et serveur. Il joue un rôle de tampon en stockant localement toutes les actions réalisées par l’utlisateur avant de les synchroniser quand le contexte le permet (✐✳❡✳ quand la connexion est établie) ; — L’état du système est représenté par la succession des actions effectuées par les utilisateurs, selon le principe d’❡✈❡♥t s♦✉r❝✐♥❣ ; — La synchronisation est basée sur les actions, afin de profiter des algorithmes sophistiqués de résolution de conflits tels que TIPS ; — Différentes stratégies de synchronisation basées sur les actions peuvent être employées (p. ex. Jupiter OT, TIPS, etc.) ; — Chaque utilisateur fait évoluer sa propre réplique du système de façon optimiste (c’est-à-dire sans attendre l’aval du serveur après chaque action), et toutes les répliques convergent éventuellement ; — Les composants ▼♦❞❡❧ et ❱✐❡✇ sont optionnels côté serveur. En effet, comme l’état du système peut être représenté par une suite d’actions effectuées par les utilisateurs, un journal suffit pour le stocker. La partie ▼♦❞❡❧ permet, en plus, de maintenir une représentation en mémoire de l’état du système, utilisable pour transmettre aux clients un s♥❛♣s❤♦t représentant le système. Cela permet de réduire le temps de reconstruction de la réplique de chaque client. La partie ❱✐❡✇, sur le serveur, permet d’exposer le contenu du système aux moteurs de recherche. 5.2 Fonctionnement du système de synchronisation L’objectif du système de synchronisation est de permettre à l’utilisateur de continuer à utiliser l’application même lorsque la connexion réseau est interrompue, et de synchroniser automatiquement ses modifications lorsque la connexion est de nouveau établie. Cette section décrit son fonctionnement en allant du scénario le plus simple au plus complexe.Fonctionnement du système de synchronisation 75 Figure 5.2 – Diagramme des classes impliquées dans la synchronisation 5.2.1 Scénario mono-utilisateur La figure 5.2 montre le découpage, sous forme de diagramme de classes, d’une application basée sur notre architecture. Le diagramme montre seulement les classes impliquées dans le processus de synchronisation. La classe abstraite Event représente une action métier. Elle est spécialisée en autant de sous-classes que l’application gère d’actions métier (ici, Event1 et Event2). Ces actions métier sont partagées par les côtés client et serveur. Côté serveur, un journal stocke les actions transmises par les diffé- rents utilisateurs. Dans le cas d’une application de gestion de tâches, les Events possibles pourraient être les suivants : Added (une tâche est ajoutée), Removed (une tâche est supprimée) et Toggled (l’état d’une tâche passe de « non réalisée » à « réalisée », ou inversement). Les Models seraient Task(content, isCompleted) et TaskList(tasks). Côté client, à chaque Model serait associé un Control, utilisant des Views pour l’affichage. La figure 5.3 décrit le fonctionnement dynamique de l’application, dans un scé- nario mono-utilisateur, lorsque celui-ci effectue une action. Les interactions entre les différents composants sont les suivantes : 1. L’utilisateur interagit avec l’interface utilisateur (p. ex. il clique sur un bouton) ; 2. Le composant de contrôle traduit cet événement en action métier (ici, Event1) ; 3. Cette action métier est transmise au composant de synchronisation ; 4. Le composant de synchronisation, d’une part, execute la logique métier correspondant à cette action ; 5. La logique métier impacte le ▼♦❞❡❧ et la ❱✐❡✇ est mise à jour ; 6. Le composant de synchronisation, d’autre part, transmet l’action au serveur, si la connexion réseau le permet. Autrement, l’action est stockée dans une file d’attente jusqu’à ce que la connexion réseau permette de la transmettre au serveur ; 7. Le serveur ajoute l’action à son journal ; 8. Le serveur indique au client que son action a bien été enregistrée. Le client supprime alors l’action de sa file d’attente.76 Un style d’architecture pour les applications Web résilientes Figure 5.3 – Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario mono-utilisateur Cette architecture permet à l’utilisateur de modifier l’état du système sans avoir à attendre l’aval du serveur à chaque action : toutes ses actions sont enregistrées et transmises au serveur si la connexion réseau le permet. 5.2.2 Scénario multi-utilisateur La prise en compte de plusieurs utilisateurs simultanés nécessite d’effectuer deux modifications : i) les clients doivent être notifiés lorsqu’un autre utilisateur a effectué une action, et ii) le système de synchronisation doit résoudre les éventuels conflits de modifications concurrentes. La figure 5.4 illustre ces modifications. Jusqu’à l’étape 6 les interactions sont les mêmes que précédemment. Puis, lorsque le serveur reçoit l’action e d’un utilisateur, il la transforme éventuellement en une action e’ (étape 7), selon l’algorithme de convergence utilisé. De même, il notifie les clients (étape 8) en transformant éventuellement l’action en une action e’’, spécifique à chaque client, afin que l’état de tous les clients converge. Notons que pour certains algorithmes, la transformation de l’action a lieu côté serveur (p. ex. TIPS), et, dans d’autres cas, côté client (p. ex. Jupiter OT). La logique métier correspondant à l’action est ensuite exécutée sur les clients notifiés (étapes 9 et 10).Généralisation du composant de synchronisation 77 Figure 5.4 – Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario multi-utilisateur 5.3 Généralisation du composant de synchronisation La dernière étape de notre contribution consiste à généraliser le système de synchronisation de façon à isoler la stratégie de synchronisation du reste de l’application (afin de réutiliser une stratégie dans différentes applications). La figure 5.5 montre cette évolution. Les classes en gris sont spécifiques à une application donnée, les classes en blanc sont plus générales, donc réutilisables. Le composant de synchronisation implémente une stratégie de synchronisation en particulier. Sa méthode abstraite interprete est implémentée par chaque application. Cette méthode définit la logique métier correspondant à la réalisation d’une action donnée. Ainsi, lorsqu’une action est traitée par un composant de contrôle, celui-ci la transmet au composant de synchronisation ✈✐❛ la méthode apply, lequel appelle ensuite sa méthode interprete pour invoquer la logique métier associée (il s’agit du patron de conception ❚❡♠♣❧❛t❡ ▼❡t❤♦❞). Les classes en pointillés représentent des composants qui ne sont pas couplés au composant de synchronisation. 5.4 Évolution : fonctionnement complètement hors-ligne L’architecture décrite précédemment gère les interruptions de réseau mais elle ne stocke pas les données du système de façon persistante. La connexion est donc nécessaire pour le chargement initial de l’application. Une fois l’application chargée dans le navigateur, si l’utilisateur actualise la page il a besoin de la connexion réseau. Autrement dit, le support du mode hors-ligne, tel que décrit précédemment, n’est effectif que si l’utilisateur a déjà chargé l’application dans son navigateur et qu’il ne ferme78 Un style d’architecture pour les applications Web résilientes Figure 5.5 – Généralisation de la synchronisation pas son onglet. Il est techniquement possible de pallier ce problème en stockant de façon persistante le journal d’actions pour pouvoir reconstruire l’état de l’application et en utilisant le cache du navigateur pour que la connexion réseau ne soit pas nécessaire pour le chargement de l’application. Le journal des actions est déjà stocké de façon persistante sur le serveur. Des solutions récentes de stockage persistant côté client telles que IndexedDB [Ind] permettent de stocker le journal côté client également. L’❆♣♣❧✐❝❛t✐♦♥ ❈❛❝❤❡ [App] permet de stocker le code client de l’application dans le cache du navigateur, et donc permet de lancer l’application sans connexion réseau. En utilisant ces deux systèmes de stockage, il est possible de gérer le fonctionnement complètement hors-ligne (une connexion réseau reste toutefois nécessaire pour télécharger l’application la toute première fois). 5.5 Validation 5.5.1 Objectifs Le premier objectif de ce chapitre est de proposer un style d’architecture pour contsruire des applications Web résilientes. C’est-à-dire un style d’architecture qui encourage la séparation des différentes préoccupations impliquées dans ce type d’applications : l’interaction avec l’utilisateur, la synchronisation avec le serveur et les traitements métier. Cette séparation des préoccupation a elle-même un double objectif : permettre au développeur de se focaliser sur une seule préoccupation à la fois et rendre l’architecture plus modulaire (il doit être possible de modifier un aspectValidation 79 indépendamment des autres). 5.5.2 Expérience Hypothèses Les hypothèses que nous cherchons à valider sont les suivantes : H1 la logique métier est effectivement isolée ; H2 la préoccupation de résilience est effectivement isolée. Méthode Nous avons écrit plusieurs applications suivant le style d’architecture dé- crit précédemment, notamment une application de gestion de tâches et un éditeur de texte. Ces deux applications fonctionnent en mode complètement hors-ligne et se synchronisent avec le serveur lorsque la connexion réseau est active. L’application d’édition de texte est l’exemple type d’applications illustrant le travail collaboratif assisté par ordinateur. Au total (côtés client et serveur, sans les commentaires), le code de l’application fait 566 lignes. L’application de gestion de tâches est une implémentation du projet TodoMVC [Tod]. Ce projet vise à comparer les différents outils de construction d’applications Web interactives. Au total, le code de l’application fait 1344 lignes. Le code prenant en charge la préoccupation de résilience et la stratégie de synchronisation est partagé entre les deux applications. Il est implémenté sous forme de deux bibliothèques réutilisables (une pour le côté client et une pour le côté serveur), et s’appuie sur les WebSockets pour la communication client-serveur. Le code de la bibliothèque côté client fait 334 lignes de JavaScript, CoffeeScript et Less. Le code de la bibliothèque côté serveur fait 178 lignes de Scala. La logique métier est implémentée uniquement dans la partie ▼♦❞❡❧ : l’ajout ou la modification d’une fonctionnalité n’impacte que cette couche. Cependant, pour rendre la fonctionnalité accessible à l’utilisateur, il est nécessaire d’effectuer des modifications dans plusieurs parties du code. Il faut : — réifier la fonctionalité en une action métier (c’est-à-dire ajouter un cas particulier d’❊✈❡♥t) ; — définir l’implémentation de cette action au niveau de la couche ❈♦♥tr♦❧, laquelle s’appuie sur la couche ▼♦❞❡❧ ; — définir les éléments d’interface utilisateur permettant d’utiliser la fonctionnalité, au niveau ❱✐❡✇. 5.5.3 Discussion 5.5.3.1 Analyse des résultats Le découpage du code induit par notre style d’architecture conduit à séparer les préoccupations de la façon suivante :80 Un style d’architecture pour les applications Web résilientes Figure 5.6 – Préoccupations des applications Web resilientes et responsabilités des différents composants de notre architecture — La partie ▼♦❞❡❧ contient les données et fonctionnalités métier. Elle est complètement ignorante des préoccupations d’interaction ou de résilience, ce qui valide l’hypothèse H1 ; — La partie ❈♦♥tr♦❧ rend le ▼♦❞❡❧ interactif. Cette partie est ignorante de la pré- occupation de résilience ; — La partie ❙②♥❝ rend l’application résiliente. Elle est ignorante de la logique métier ; — La partie ❱✐❡✇ affiche de l’information à l’utilisateur. Elle est ignorante de la logique métier et de la préoccupation de résilience. Autrement dit, notre architecture permet de développer l’application sans se soucier de la préoccupation de résilience, laquelle est prise en charge par une bibliothèque réutilisable, ce qui valide l’hypothèse H2. La figure 5.6 illustre les différentes préoccupations et les responsabilités des composants. Notons que le fait que l’ajout d’une fonctionnalité ait un impact à plusieurs endroits dans le code n’est pas en contradiction avec nos objectif. Cela est simplement une conséquence normale du fait qu’une fonctionnalité a plusieurs facettes : logique métier, affichage et interaction avec l’utilisateur. 5.5.3.2 Limites de notre validation Notre architecture n’est appropriée que dans les situations où la logique d’une action peut être entièrement pourvue par le client. Or, dans certains cas (p. ex. la recherche d’information) la logique métier nécessite d’utiliser des informations qui ne sont disponibles que sur le serveur (les transférer côté client coûterait trop cher). Néanmoins, dans tous les cas où l’application sert à manipuler un document ou deDiscussion 81 l’information (p. ex. un agenda, une liste de tâche, un éditeur de texte, de présentation, etc.), notre architecture est appropriée. Comme indiqué en section 5.1, la construction de l’état de l’application en « rejouant » son histoire, c’est-à-dire en exécutant toutes les actions qui ont été enregistrées, peut être coûteuse et conduire à l’utilisation de s♥❛♣s❤♦ts pour accélérer le processus. En effet, les clients ont besoin de construire une représentation en mémoire de l’état de l’application (ou d’un partie de l’application), et avec le temps l’historique d’une application peut être particulièrement important. La solution consiste à envoyer aux clients un s♥❛♣s❤♦t représentant l’état actuel du système. Ainsi, les clients peuvent directement partir de ce snapshot plutôt que de tout recalculer. Cependant, il n’existe pas, à ce jour, de système automatisant la sérialisation d’un tel s♥❛♣s❤♦t de façon à ce que le système puisse être reconstruit côté client. Notons également que, pour construire ces s♥❛♣s❤♦ts, la totalité du modèle de données doit tenir en mémoire côté serveur. Il est cependant possible de sectoriser le modèle de données de façon à ne traiter qu’une partie des données à la fois. 5.6 Discussion Les applications Web s’appuient sur une connexion réseau pour fonctionner. Lorsque la connexion est intermittente, ou lente, comme cela peut notamment être le cas sur les appareils mobiles, la qualité de l’expérience utilisateur s’amoindrit, à moins de rendre l’application résiliente aux aléas du réseau. La préoccupation de résilience étant transversale, sa prise en charge pourrait augmenter la complexité du code des applications Web. Nous avons défini un style d’architecture isolant cette préoccupation et permettant donc de construire des applications Web collaboratives résilientes. Les applications adhérant à cette architecture peuvent être utilisées en mode hors-ligne et leur expérience utilisateur n’est pas affectée par la latence du réseau. L’architecture que nous proposons réduit la complexité de développement en défi- nissant clairement les limites des responsabilités de chaque composant. La couche mé- tier est ainsi ignorante des préoccupations d’interactivité ou de résilience. La couche gérant l’interactivité est ignorante de la préoccupation de résilience. Cette dernière est ignorante de la logique métier. Ce faible couplage entre les différents composants de notre architecture nous a permis d’implémenter la gestion de la résilience sous forme d’une bibliothèque géné- rique. En réutilisant cette bibliothèque, qui s’intègre facilement dans notre architecture, le développement d’une application Web résiliente demande peu d’efforts. Enfin, notons que notre style d’architecture conduit à partager certains concepts entre les applications client et serveur : les actions métier et, dans le cas où le serveur maintient l’état du système en mémoire, la partie ▼♦❞❡❧. Le chapitre 3 a présenté un moyen de partager du code entre clients et serveurs, pouvons-nous utiliser cet outil pour mutualiser les concepts partagés ? Dans le cas des actions métier, c’est effectivement possible, bien que le gain soit82 Un style d’architecture pour les applications Web résilientes assez faible car les actions métier ne sont définies que par des données sans opération. Le code partagé n’est alors constitué que des constructeurs de types de données. Dans le cas de la partie ▼♦❞❡❧, le modèle de données et l’implémentation des transitions de l’état du système en fonction des actions métier sont partagés. Cependant, nous avons observé que, en pratique, nos implémentations utilisent des idiomes différents côtés client et serveur. Côté serveur, l’état du système est implémenté à l’aide de types de données immuables, ce qui permet d’implémenter les transitions de façon atomique (cela est nécessaire sur le serveur qui peut être accédé par plusieurs clients de façon concurrente). Côté client, le style est impératif car cela est plus idiomatique dans le langage JavaScript et que nous n’avons pas les mêmes contraintes de concurrence que sur le serveur. Nous aurions pu, cependant, définir un langage commun pour décrire notre modèle de données et les transitions d’état, et définir comment générer le code correspondant côtés client et serveur, afin de mutualiser cet aspect de notre application. Cela aurait eu l’avantage de maintenir les applications client et serveur cohérentes entre elles, mais aurait demandé un effort d’implémentation relativement important pour un résultat non réutilisable (puisque propre au domaine d’une application donnée). Un bon compromis aurait pu être de définir un langage commun plus général de dé- finition et manipulation de types de données. Un tel langage aurait pu être réutilisé pour modéliser le domaine métier et les transitions d’état de chaque application. Nous avons exploré cette voie sans toutefois atteindre un niveau de maturité suffisant. Cependant, même en terminant ce travail le problème n’aurait été que partiellement résolu, une autre facette du problème est l’intégration du code généré dans le programme final. Le système de génération de code sur lequel nous nous sommes appuyé est conçu pour produire des programmes avec un seul point d’entrée, c’est-à-dire des fonctions. Or dans certains cas, il est plus commode d’intégrer des modules exposant plusieurs fonctions et comportant des dépendances vers d’autres composants. La différence n’est pas grande, et il est possible d’émuler les modules avec les fonctions ou de rendre le système de génération de code paramétrable. Néanmoins l’intégration, dans chaque variante de l’application, du code généré à partir du code mutualisé comporte une part de friction diminuant l’intérêt du processus de génération de code. Finalement, nous pensons que, à part pour certains aspects comme la navigation et le contenu HTML, il n’est pas certain que les avantages de la mutualisation du code contrebalancent toujours les inconvénients de l’intégration du code généré.Troisième partie Conclusion et perspectives 83Chapitre 6 Conclusion et perspectives Ce chapitre présente une synthèse des contributions de cette thèse et discute les perspectives qu’elles ouvrent. 6.1 Conclusion La distance, tant matérielle que logicielle, entre les postes ou environnements client et serveur est une source de complexité pour le développement d’applications Web. La distance matérielle crée une préoccupation technique transverse : la résilience aux aléas du réseau. D’un côté, pour simplifier le processus d’ingénierie des applications Web, on souhaite que cette préoccupation soit gérée automatiquement, sans intervention du développeur. D’un autre côté, il n’est pas souhaitable de masquer l’aspect distribué des architectures Web : le développeur doit pouvoir préciser les modalités de synchronisation ou décider au cas par cas de la stratégie à suivre lorsque la connexion réseau est rompue. La distance logicielle empêche le développeur de réutiliser du code entre les client et serveur et l’oblige à décider très tôt où exécuter le code de l’application. Ici encore, d’un côté, pour simplifier le processus d’ingénierie des applications Web, on souhaite que les développeurs puissent écrire le code de l’application et décider ❛ ♣♦st❡r✐♦r✐ d’exécuter ce code côté client ou serveur, voire partager ce code des deux côtés. D’un autre côté, il n’est pas souhaitable de masquer les spécificités des environnements client et serveur : le développeur doit pouvoir tirer parti des environnements natifs (notamment pour des raisons de performances). Les travaux de cette thèse proposent des solutions pour réduire la complexité de développement des applications Web, sans pour autant diminuer le contrôle donné aux développeurs. Concernant la distance logicielle, nous proposons un ensemble de bibliothèques Scala fournissant des abstractions dédiées à la programmation Web et produisant des programmes optimisés pour les environnements client et serveur. Cela permet aux développeurs de réutiliser du code entre les côtés client et serveur tout en tirant parti 8586 Conclusion et perspectives des spécificités de ces environnements. Notre deuxième contribution permet d’utiliser l’interface de programmation du navigateur depuis les langages de programmation statiquement typés sans diminution du pouvoir d’expression et de manière plus sûre que les autres approches. Enfin, concernant la distance matérielle, nous proposons un modèle d’architecture isolant la préoccupation de résilience. Cela permet aux développeurs d’écrire les traitements métier de leur application sans avoir à gérer les aléas du réseau, ainsi que de réutiliser des implémentations de stratégies de synchronisation. Mentionnons également que, en parallèle de ses travaux académiques, l’auteur de cette thèse a publié un livre sur l’ingénierie des applications Web avec le framework Play [RF14]. 6.2 Perspectives Nos trois contributions réduisent la complexité de développement des applications Web sans pour autant diminuer le contrôle donné aux développeurs. Nous pensons qu’il est possible, et souhaitable, de prolonger notre effort afin de réduire encore d’autres sources de complexité. La suite de cette section présente les sources de complexité que nous avons identifiées et qui pourraient faire l’objet de travaux ultérieurs. Navigations synchrone et asynchrone Nous avons mentionné le fait que les navigations synchrone et asynchrone ont toutes les deux des avantages. La navigation synchrone (le fait de recharger complètement la page en suivant un lien hypertexte) permet un meilleur référencement du contenu par les moteurs de recherche et diminue le temps d’affichage initial des pages. La navigation asynchrone (le fait de ne mettre à jour qu’une partie de la page en suivant un lien hypertexte) diminue le temps de transition d’une page à une autre. Cependant, la gestion des deux types de navigation pose plusieurs problèmes. D’une part, les deux navigations doivent être cohérentes entre elles (elles doivent gé- rer les mêmes URLs désignant les mêmes ressources). Ce problème devrait toutefois être facilement être résolu avec un outil comme LMS. D’autre part, le code côté client ou le modèle de données peuvent varier selon les pages. Par exemple, une page affichant une liste d’articles dans une boutique en ligne peut nécessiter du code pour gérer la pagination, et peut s’appuyer sur un modèle de données définissant une liste d’articles. Tandis qu’une page affichant un article seul n’a pas besoin du code gérant la pagination, et le modèle de données peut se limiter à la définition d’un seul article. Avec une navigation synchrone, chaque page contient le code nécessaire à son affichage. Mais avec une navigation asynchrone, le code et le modèle de données doivent pouvoir être mis à jour selon les besoins : le passage de l’affichage d’un article à une liste d’articles doit télécharger le morceau de code manquant et enrichir le modèle de données.Perspectives 87 Éditeurs de données Malgré les bénéfices apportés par nos travaux, le développement de certaines classes d’applications Web reste très laborieux. C’est le cas des applications de gestion de données. Développer une interface Web pour gérer la saisie et l’affichage de données nécessite beaucoup d’étapes : l’affichage d’une interface utilisateur, la sérialisation des données pour leur transfert entre clients et serveurs et le retour d’informations à l’utilisateur. Automatiser ces étapes est difficile car chacune requiert des informations qui lui sont spécifiques (bien que toutes soient dédiées au même type de données) : libellés d’affichage, règles de validation, protocole de sérialisation, etc. Toujours en respectant notre philosophie visant à automatiser sans diminuer le contrôle, il faudrait pouvoir générer un éditeur de données à partir d’un simple modèle de données, tout en conservant la possibilité d’affiner chaque aspect de l’éditeur (libellés, règles de validation, etc.) et de faire évoluer le modèle de données. Des travaux préliminaires ont déjà été réalisés dans cette direction [edi]. Générer des variantes d’applications natives pour téléphones Enfin, si le Web permet de définir du contenu visualisable sur des plateformes très variées, allant de l’ordinateur de bureau au téléphone, il comporte également quelques inconvénients. En effet, les applications Web manifestent généralement un surcoût en performances d’exécution par rapport aux applications natives. En outre, l’environnement du Web ne permet pas toujours d’accéder à toutes les fonctionnalités des terminaux clients. Pour ces raisons, ceux-là même qui naguère vantaient le Web (❡✳❣✳ Google, Facebook) s’en détournent aujourd’hui, au moins dans le cas des téléphones mobiles, et investissent leurs efforts de développement dans des applications natives. Or, le développement d’applications natives pour les téléphones mobiles conduit à une importante duplication d’efforts, car les environnements de ces terminaux peuvent être très différents (p. ex. il existe trois systèmes d’exploitation majeurs — iOS, Android et Windows Phone – qui ne gèrent pas tous les mêmes langages de programmation – Swift, Java et C#). Des outils tels que Xamarin [Xam] permettent déjà de générer des applications natives pour les différentes plateformes mobiles du marché. Cependant, ces outils s’appuient sur les mêmes solutions techniques que GWT, et souffrent donc des mêmes limitations (en particulier l’impossibilité de définir des abstractions tirant parti des spécificités de l’environnement cible sans surcoût à l’exécution). De façon analogue à notre travail permettant de mutualiser le code des applications client et serveur, nous pourrions définir un langage pour le développement d’applications sur téléphones mobiles, et générer des applications natives performantes, pour chaque plateforme.88 Conclusion et perspectivesBibliographie [App] Application cache. http://web.archive.org/web/20140816085956/ http://www.whatwg.org/specs/web-apps/current-work/multipage/ /browsers.html. Accédé le 11 septembre 2014. [Bac] Bacon.js. http://web.archive.org/web/20140802222641/http:// baconjs.github.io/. Accédé le 18 août 2014. [Bal06] Vincent Balat. Ocsigen : typing web interaction with objective caml. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✷✵✵✻ ✇♦r❦s❤♦♣ ♦♥ ▼▲, pages 84–94. ACM, 2006. [BAT14] Gavin Bierman, Martín Abadi, and Mads Torgersen. Understanding typescript. In ❊❈❖❖P ✷✵✶✹✕❖❜❥❡❝t✲❖r✐❡♥t❡❞ Pr♦❣r❛♠♠✐♥❣, pages 257–281. Springer, 2014. [BDM+13] Dominic Betts, Julian Dominguez, Grigori Melnik, Fernando Simonazzi, and Mani Subramanian. ❊①♣❧♦r✐♥❣ ❈◗❘❙ ❛♥❞ ❊✈❡♥t ❙♦✉r❝✐♥❣ ✿ ❆ ❏♦✉r✲ ♥❡② ✐♥t♦ ❍✐❣❤ ❙❝❛❧❛❜✐❧✐t②✱ ❆✈❛✐❧❛❜✐❧✐t②✱ ❛♥❞ ▼❛✐♥t❛✐♥❛❜✐❧✐t② ✇✐t❤ ❲✐♥❞♦✇s ❆③✉r❡. Microsoft patterns & ; practices, 1st edition, 2013. [BK08] B. Bibeault and Y. Kats. ❥◗✉❡r② ✐♥ ❆❝t✐♦♥. Dreamtech Press, 2008. [Bra13] Edwin Brady. Idris, a general-purpose dependently typed programming language : Design and implementation. ❏♦✉r♥❛❧ ♦❢ ❋✉♥❝t✐♦♥❛❧ Pr♦❣r❛♠✲ ♠✐♥❣, 23(05) :552–593, 2013. [Can08] Nicolas Cannasse. Using haxe. In ❚❤❡ ❊ss❡♥t✐❛❧ ●✉✐❞❡ t♦ ❖♣❡♥ ❙♦✉r❝❡ ❋❧❛s❤ ❉❡✈❡❧♦♣♠❡♥t, pages 227–244. Springer, 2008. [CGLO06] Vincent Cremet, François Garillot, Sergueï Lenglet, and Martin Odersky. A core calculus for scala type checking. In ▼❛t❤❡♠❛t✐❝❛❧ ❋♦✉♥❞❛t✐♦♥s ♦❢ ❈♦♠♣✉t❡r ❙❝✐❡♥❝❡ ✷✵✵✻, pages 1–23. Springer, 2006. [CHJ12] Ravi Chugh, David Herman, and Ranjit Jhala. Dependent types for javascript. ❙■●P▲❆◆ ◆♦t✳, 47(10) :587–606, October 2012. [CLWY07] Ezra Cooper, Sam Lindley, Philip Wadler, and Jeremy Yallop. Links : Web programming without tiers. In ❋♦r♠❛❧ ▼❡t❤♦❞s ❢♦r ❈♦♠♣♦♥❡♥ts ❛♥❞ ❖❜✲ ❥❡❝ts, pages 266–296. Springer, 2007. [Cou87] Joëlle Coutaz. Pac : An object oriented model for implementing user interfaces. ❆❈▼ ❙■●❈❍■ ❇✉❧❧❡t✐♥, 19(2) :37–41, 1987. 8990 Bibliographie [CSS] Css. http://web.archive.org/web/20140823082659/http://www.w3. org/Style/CSS/. Accédé le 27 août 2014. [CW10] Brett Cannon and Eric Wohlstadter. Automated Object Persistence for JavaScript. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✶✾t❤ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❲♦r❧❞ ❲✐❞❡ ❲❡❜, WWW ’10, pages 191–200, New York, NY, USA, 2010. ACM. [Cza12] Evan Czaplicki. Elm : Concurrent frp for functional guis, 2012. [Doe13] Sébastien Doeraene. Scala. js : Type-directed interoperability with dynamically typed languages. Technical report, 2013. [edi] editors. https://github.com/julienrf/editors. Accédé le 30 septembre 2014. [EFDM00] Conal Elliott, Sigbjørn Finne, and Oege De Moor. Compiling embedded languages. In ❙❡♠❛♥t✐❝s✱ ❆♣♣❧✐❝❛t✐♦♥s✱ ❛♥❞ ■♠♣❧❡♠❡♥t❛t✐♦♥ ♦❢ Pr♦❣r❛♠ ●❡♥❡r❛t✐♦♥, pages 9–26. Springer, 2000. [EG89] C. A. Ellis and S. J. Gibbs. Concurrency Control in Groupware Systems. ❙■●▼❖❉ ❘❡❝✳, 18(2) :399–407, June 1989. [EMSS] Erik Ernst, Anders Møller, Mathias Schwarz, and Fabio Strocco. Managing gradual typing with message-safety in dart. [Fen12] Steve Fenton. Typescript for javascript programmers. 2012. [FF05] Michael Furr and Jeffrey S. Foster. Checking type safety of foreign function calls. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✷✵✵✺ ❆❈▼ ❙■●P▲❆◆ ❈♦♥❢❡r❡♥❝❡ ♦♥ Pr♦✲ ❣r❛♠♠✐♥❣ ▲❛♥❣✉❛❣❡ ❉❡s✐❣♥ ❛♥❞ ■♠♣❧❡♠❡♥t❛t✐♦♥, PLDI ’05, pages 62–72, New York, NY, USA, 2005. ACM. [Fow05] Martin Fowler. Event sourcing. ❖♥❧✐♥❡✱ ❉❡❝, 2005. [FT02] Roy T. Fielding and Richard N. Taylor. Principled design of the modern Web architecture. ❆❈▼ ❚r❛♥s✳ ■♥t❡r♥❡t ❚❡❝❤♥♦❧✳, 2 :115–150, May 2002. [GF99] Rachid Guerraoui and Mohamed E Fayad. Oo distributed programming is not distributed oo programming. ❈♦♠♠✉♥✐❝❛t✐♦♥s ♦❢ t❤❡ ❆❈▼, 42(4) :101–104, 1999. [Gho10] Debasish Ghosh. ❉❙▲s ✐♥ ❆❝t✐♦♥. Manning Publications Co., Greenwich, CT, USA, 1st edition, 2010. [Hoa09] T. Hoare. Null references : The billion dollar mistake. Pr❡s❡♥t❛t✐♦♥ ❛t ◗❈♦♥ ▲♦♥❞♦♥, 2009. [HTM] Html. http://web.archive.org/web/20140702124213/http://www. w3.org/TR/domcore/. Accédé le 31 juillet 2014. [Hud96] Paul Hudak. Building domain-specific embedded languages. ❆❈▼ ❈♦♠✲ ♣✉t✳ ❙✉r✈✳, 28(4es), December 1996. [Ind] Indexed database api. http://web.archive.org/web/20140906110326/ http://www.w3.org/TR/IndexedDB/. Accédé le 11 septembre 2014.Bibliographie 91 [Jav] Lambda expressions. http://web.archive.org/web/20140625121030/ http://docs.oracle.com/javase/tutorial/java/javaOO/ lambdaexpressions.html. Accédé le 4 septembre 2014. [JCB+13] Jean-Marc Jézéquel, Benoit Combemale, Olivier Barais, Martin Monperrus, and François Fouquet. Mashup of metalanguages and its implementation in the kermeta language workbench. ❙♦❢t✇❛r❡ ✫ ❙②st❡♠s ▼♦❞❡❧✐♥❣, pages 1–16, 2013. [JGS93] Neil D Jones, Carsten K Gomard, and Peter Sestoft. P❛rt✐❛❧ ❡✈❛❧✉❛t✐♦♥ ❛♥❞ ❛✉t♦♠❛t✐❝ ♣r♦❣r❛♠ ❣❡♥❡r❛t✐♦♥. Peter Sestoft, 1993. [jQu] Utilisation de jquery. http://web.archive.org/web/20140704091353/ https://trends.builtwith.com/javascript. Accédé le 2 septembre 2014. [JS86] Ulrik Jørring and William L. Scherlis. Compilers and staging transformations. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✶✸t❤ ❆❈▼ ❙■●❆❈❚✲❙■●P▲❆◆ ❙②♠♣♦s✐✉♠ ♦♥ Pr✐♥❝✐♣❧❡s ♦❢ Pr♦❣r❛♠♠✐♥❣ ▲❛♥❣✉❛❣❡s, POPL ’86, pages 86–96, New York, NY, USA, 1986. ACM. [JW07] Bruce Johnson and Joel Webber. ●♦♦❣❧❡ ✇❡❜ t♦♦❧❦✐t. Addison-Wesley, 2007. [K+96] Samuel Kamin et al. Standard ml as a meta-programming language. Technical report, 1996. [KARO12] Grzegorz Kossakowski, Nada Amin, Tiark Rompf, and Martin Odersky. Javascript as an embedded dsl. In ❊❈❖❖P ✷✵✶✷✕❖❜❥❡❝t✲❖r✐❡♥t❡❞ Pr♦✲ ❣r❛♠♠✐♥❣, pages 409–434. Springer, 2012. [KHR+12] Sebastian Kleinschmager, Stefan Hanenberg, Romain Robbes, É Tanter, and Andreas Stefik. Do static type systems improve the maintainability of software systems ? an empirical study. In Pr♦❣r❛♠ ❈♦♠♣r❡❤❡♥s✐♦♥ ✭■❈P❈✮✱ ✷✵✶✷ ■❊❊❊ ✷✵t❤ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, pages 153–162. IEEE, 2012. [KLYY12] Yung-Wei Kao, ChiaFeng Lin, Kuei-An Yang, and Shyan-Ming Yuan. A Web-based, Offline-able, and Personalized Runtime Environment for executing applications on mobile devices. ❈♦♠♣✉t❡r ❙t❛♥❞❛r❞s ✫ ■♥t❡r❢❛❝❡s, 34(1) :212–224, 2012. [Kot] Kotlin. http://web.archive.org/web/20140712061248/http: //kotlin.jetbrains.org/. Accédé le 18 juillet 2014. [KP88] G Krasner and S Pope. A cookbook for using the model-view controller user interface paradigm in smalltalk-80 j. object oriented program., 1, 26- 49, 1988. [Lan66] Peter J Landin. The next 700 programming languages. ❈♦♠♠✉♥✐❝❛t✐♦♥s ♦❢ t❤❡ ❆❈▼, 9(3) :157–166, 1966. [LB11] Jesse Liberty and Paul Betts. Reactive extensions for javascript. In Pr♦✲ ❣r❛♠♠✐♥❣ ❘❡❛❝t✐✈❡ ❊①t❡♥s✐♦♥s ❛♥❞ ▲■◆◗, pages 111–124. Springer, 2011.92 Bibliographie [LM99] Daan Leijen and Erik Meijer. Domain specific embedded compilers. In ❆❈▼ ❙✐❣♣❧❛♥ ◆♦t✐❝❡s, volume 35, pages 109–122. ACM, 1999. [LV92] Ernst Lippe and Norbert Van Oosterom. Operation-based merging. In ❆❈▼ ❙■●❙❖❋❚ ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡r✐♥❣ ◆♦t❡s, volume 17, pages 78–87. ACM, 1992. [Mar09] Nora Koch Marianne Busch. Rich Internet Applications. State-of-the-Art. Technical Report 0902, Ludwig-Maximilians-Universität München, 2009. [MGPW13] Félix Albertos Marco, José A. Gallud, Victor M. Ruiz Penichet, and Marco Winckler. A model-based approach for supporting offline interaction with web sites resilient to interruptions. In ■❈❲❊ ❲♦r❦s❤♦♣s, pages 156– 171, 2013. [MHR+ ] Clemens Mayer, Stefan Hanenberg, Romain Robbes, Éric Tanter, and Andreas Stefik. Static type systems (sometimes) have a positive impact on the usability of undocumented software : An empirical evaluation. s❡❧❢, 18 :5. [NCDL95] David A. Nichols, Pavel Curtis, Michael Dixon, and John Lamping. Highlatency, Low-bandwidth Windowing in the Jupiter Collaboration System. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✽t❤ ❆♥♥✉❛❧ ❆❈▼ ❙②♠♣♦s✐✉♠ ♦♥ ❯s❡r ■♥t❡r❢❛❝❡ ❛♥❞ ❙♦❢t✇❛r❡ ❚❡❝❤♥♦❧♦❣②, UIST ’95, pages 111–120, New York, NY, USA, 1995. ACM. [NS09] M.G. Nanda and S. Sinha. Accurate interprocedural null-dereference analysis for java. In ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡r✐♥❣✱ ✷✵✵✾✳ ■❈❙❊ ✷✵✵✾✳ ■❊❊❊ ✸✶st ■♥✲ t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, pages 133–143. IEEE, 2009. [OCRZ03] Martin Odersky, Vincent Cremet, Christine Röckl, and Matthias Zenger. A nominal theory of objects with dependent types. In ❊❈❖❖P ✷✵✵✸✕ ❖❜❥❡❝t✲❖r✐❡♥t❡❞ Pr♦❣r❛♠♠✐♥❣, pages 201–224. Springer, 2003. [OZ05] Martin Odersky and Matthias Zenger. Scalable component abstractions. ❆❈▼ ❙✐❣♣❧❛♥ ◆♦t✐❝❡s, 40(10) :41–57, 2005. [Pur] Purescript. http://web.archive.org/web/20140731132649/http:// www.purescript.org/. Accédé le 31 juillet 2014. [RE09] Roberto Rodríguez-Echeverría. RIA : more than a Nice Face. In Pr♦❝❡❡✲ ❞✐♥❣s ♦❢ t❤❡ ❉♦❝t♦❧r❛❧ ❈♦♥s♦rt✐✉♠ ♦❢ t❤❡ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❲❡❜ ❊♥❣✐♥❡❡r✐♥❣, volume 484. CEUR-WS.org, 2009. [RF14] Julien Richard-Foy. P❧❛② ❋r❛♠❡✇♦r❦ ❊ss❡♥t✐❛❧s. Packt Publishing Limited, Birmingham, UK, 1st edition, 2014. [RFBJ13a] Julien Richard-Foy, Olivier Barais, and Jean-Marc Jézéquel. Efficient highlevel abstractions for web programming. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ✶✷t❤ ✐♥t❡r✲ ♥❛t✐♦♥❛❧ ❝♦♥❢❡r❡♥❝❡ ♦♥ ●❡♥❡r❛t✐✈❡ ♣r♦❣r❛♠♠✐♥❣ ✿ ❝♦♥❝❡♣ts ✫ ❡①♣❡r✐❡♥❝❡s, pages 53–60. ACM, 2013. [RFBJ13b] Julien Richard-Foy, Olivier Barais, and Jean-Marc Jézéquel. Efficient highlevel abstractions for web programming. In Jaakko Jarvi and ChristianBibliographie 93 Kastner, editors, ●❡♥❡r❛t✐✈❡ Pr♦❣r❛♠♠✐♥❣ ✿ ❈♦♥❝❡♣ts ❛♥❞ ❊①♣❡r✐❡♥❝❡s✱ ●P❈❊✬✶✸, pages 53–60, Indianapolis, États-Unis, 2013. ACM. [RFBJ14] Julien Richard-Foy, Olivier Barais, and Jean-Marc Jézéquel. Using PathDependent Types to Build Type Safe JavaScript Foreign Function Interfaces. In ■❈❲❊ ✲ ✶✹t❤ ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❲❡❜ ❊♥❣✐♥❡❡r✐♥❣, Toulouse, France, July 2014. [Rif08] Jeremy Rifkin. The third industrial revolution. ❊♥❣✐♥❡❡r✐♥❣ ✫ ❚❡❝❤♥♦❧♦❣②, 3(7) :26–27, 2008. [Rom12] Tiark Rompf. ▲✐❣❤t✇❡✐❣❤t ▼♦❞✉❧❛r ❙t❛❣✐♥❣ ❛♥❞ ❊♠❜❡❞❞❡❞ ❈♦♠♣✐❧❡rs ✿ ❆❜str❛❝t✐♦♥ ✇✐t❤♦✉t ❘❡❣r❡t ❢♦r ❍✐❣❤✲▲❡✈❡❧ ❍✐❣❤✲P❡r❢♦r♠❛♥❝❡ Pr♦❣r❛♠♠✐♥❣. PhD thesis, 2012. [RSB+14] Tiark Rompf, Arvind K Sujeeth, Kevin J Brown, HyoukJoong Lee, Hassan Chafi, and Kunle Olukotun. Surgical precision jit compilers. In Pr♦❝❡❡✲ ❞✐♥❣s ♦❢ t❤❡ ✸✺t❤ ❆❈▼ ❙■●P▲❆◆ ❈♦♥❢❡r❡♥❝❡ ♦♥ Pr♦❣r❛♠♠✐♥❣ ▲❛♥❣✉❛❣❡ ❉❡s✐❣♥ ❛♥❞ ■♠♣❧❡♠❡♥t❛t✐♦♥, page 8. ACM, 2014. [RT10] David Rajchenbach-Teller. Opa : Language support for a sane, safe and secure web. Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❖❲❆❙P ❆♣♣❙❡❝ ❘❡s❡❛r❝❤ ✷✵✶✵, 2010. [SE98] Chengzheng Sun and Clarence Ellis. Operational Transformation in Realtime Group Editors : Issues, Algorithms, and Achievements. In Pr♦❝❡❡✲ ❞✐♥❣s ♦❢ t❤❡ ✶✾✾✽ ❆❈▼ ❈♦♥❢❡r❡♥❝❡ ♦♥ ❈♦♠♣✉t❡r ❙✉♣♣♦rt❡❞ ❈♦♦♣❡r❛t✐✈❡ ❲♦r❦, CSCW ’98, pages 59–68, New York, NY, USA, 1998. ACM. [SGL06] Manuel Serrano, Erick Gallesio, and Florian Loitsch. Hop : a language for programming the web 2. 0. In ❖❖P❙▲❆ ❈♦♠♣❛♥✐♦♥, pages 975–985, 2006. [Sha] Sharpkit. http://web.archive.org/web/20140716013416/http:// sharpkit.net/. Accédé le 18 juillet 2014. [SLLG11] Bin Shao, Du Li, Tun Lu, and Ning Gu. An operational transformation based synchronization protocol for web 2.0 applications. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❆❈▼ ✷✵✶✶ ❝♦♥❢❡r❡♥❝❡ ♦♥ ❈♦♠♣✉t❡r s✉♣♣♦rt❡❞ ❝♦♦♣❡r❛t✐✈❡ ✇♦r❦, pages 563–572. ACM, 2011. [SPBZ11] Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. Conflict-free replicated data types. In ❙t❛❜✐❧✐③❛t✐♦♥✱ ❙❛❢❡t②✱ ❛♥❞ ❙❡❝✉r✐t② ♦❢ ❉✐str✐❜✉t❡❞ ❙②st❡♠s, pages 386–400. Springer, 2011. [Tod] Todomvc. http://web.archive.org/web/20140903120512/http:// todomvc.com/. Accédé le 11 septembre 2014. [Vis08] Eelco Visser. Webdsl : A case study in domain-specific language engineering. In ●❡♥❡r❛t✐✈❡ ❛♥❞ ❚r❛♥s❢♦r♠❛t✐♦♥❛❧ ❚❡❝❤♥✐q✉❡s ✐♥ ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡✲ r✐♥❣ ■■, pages 291–373. Springer, 2008. [VP12] Markus Voelter and Vaclav Pech. Language modularity with the mps language workbench. In ❙♦❢t✇❛r❡ ❊♥❣✐♥❡❡r✐♥❣ ✭■❈❙❊✮✱ ✷✵✶✷ ✸✹t❤ ■♥t❡r♥❛t✐♦✲ ♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, pages 1449–1450. IEEE, 2012.94 Bibliographie [VV10] Markus Völter and Eelco Visser. Language extension and composition with language workbenches. In Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❆❈▼ ✐♥t❡r♥❛t✐♦♥❛❧ ❝♦♥❢❡r❡♥❝❡ ❝♦♠♣❛♥✐♦♥ ♦♥ ❖❜❥❡❝t ♦r✐❡♥t❡❞ ♣r♦❣r❛♠♠✐♥❣ s②st❡♠s ❧❛♥❣✉❛❣❡s ❛♥❞ ❛♣♣❧✐❝❛t✐♦♥s ❝♦♠♣❛♥✐♦♥, pages 301–304. ACM, 2010. [WL12] Kathy Walrath and Seth Ladd. ❲❤❛t ✐s ❉❛rt ❄ " O’Reilly Media, Inc.", 2012. [Xam] Xamarin. http://web.archive.org/web/20140912234132/http:// xamarin.com/. Accédé le 30 septembre 2014. [Yan00] Yun Yang. Supporting online Web-based teamwork in offline mobile mode too. In ❲❡❜ ■♥❢♦r♠❛t✐♦♥ ❙②st❡♠s ❊♥❣✐♥❡❡r✐♥❣✱ ✷✵✵✵✳ Pr♦❝❡❡❞✐♥❣s ♦❢ t❤❡ ❋✐rst ■♥t❡r♥❛t✐♦♥❛❧ ❈♦♥❢❡r❡♥❝❡ ♦♥, volume 1, pages 486–490. IEEE, 2000.Table des figures 1.1 Un formulaire tel qu’il est perçu par l’utilisateur (en haut), est repré- senté par un arbre d’éléments HTML côté client, et par un texte côté serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Les modèles MVC (à gauche) et PAC (à droite) . . . . . . . . . . . . . . . 20 2.2 Le modèle PAC-C3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3 Trois variantes d’architectures dérivées du modèle ▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r. a) MVC côté serveur ; b) MVC côté client ; et c) MVC hybride côtés client et serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4 Exécution du programme indiqué dans le listing 2.1. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation abstraite d’un fragment HTML. Celle-ci est ensuite convertie vers une représentation spécifique à chaque plateforme. . . . . . . . . . . . . . . . . . . . . . . . 28 2.5 Langages lourds. Le programme est compilé vers les environnements client et serveur. Dans chaque environnement, son exécution produit une représentation efficace du fragment HTML, en tirant parti des spé- cificités de chaque plateforme. . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6 Ingénierie dirigée par les modèles. Chaque aspect du programme est décrit dans un langage dédié. La combinaison de ces aspects constitue le programme global, qui est transformé en une application côté client et une application côté serveur. . . . . . . . . . . . . . . . . . . . . . . . 31 2.7 Langages dédiés compilés et implémentés par des bibliothèques. Un langage dédié est fourni par une bibliothèque dont l’implémentation produit une représentation abstraite du programme à générer. Un gé- nérateur de code peut dériver, à partir de cette représentation abstraite, les programmes correspondant, côtés client et serveur. . . . . . . . . . . 34 2.8 Différence entre les langages dédiés implémentés par des bibliothèques, interprétés (à gauche) ou compilés (à droite). . . . . . . . . . . . . . . . 35 2.9 Diagramme d’objets correspondant au terme trois. . . . . . . . . . . . . 37 3.1 L’API standard des sélecteurs. . . . . . . . . . . . . . . . . . . . . . . . . 43 9596 Table des figures 3.2 Représentations abstraites de code retournées par l’évaluation des expressions (a) document.find("#add-user button") et (b) document.find("#add-user") 46 3.3 Tests de performance sur un programme utilisant l’API des sélecteurs . 54 3.4 Tests de performance sur un programme manipulant des valeurs optionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5 Tests de performance sur une application réelle . . . . . . . . . . . . . . 57 5.1 Vue d’ensemble de notre style d’architecture pour applications Web ré- silientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Diagramme des classes impliquées dans la synchronisation . . . . . . . 75 5.3 Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario mono-utilisateur . . . . . . . . . . . . . . . . 76 5.4 Interactions entre les différents composants impliqués dans la synchronisation, dans un scénario multi-utilisateur . . . . . . . . . . . . . . . . 77 5.5 Généralisation de la synchronisation . . . . . . . . . . . . . . . . . . . . 78 5.6 Préoccupations des applications Web resilientes et responsabilités des différents composants de notre architecture . . . . . . . . . . . . . . . . 80Résumé L’automatisation de certaines tâches et traitements d’information grâce aux outils numériques permet de réaliser des économies considérables sur nos activités. Le Web est une plateforme propice à la mise en place de tels outils : ceux-ci sont hébergés par des serveurs, qui centralisent les informations et coordonnent les utilisateurs, et ces derniers accèdent aux outils depuis leurs terminaux clients (ordinateur, téléphone, tablette, etc.) en utilisant un navigateur Web, sans étape d’installation. La réalisation de ces applications Web présente des difficultés pour les développeurs. La principale difficulté vient de la ❞✐st❛♥❝❡ entre les postes client et serveur. D’une part, la distance physique (ou distance ♠❛tér✐❡❧❧❡) entre les machines né- cessite qu’une connexion réseau soit toujours établie entre elles pour que l’application fonctionne correctement. Cela pose plusieurs problèmes : comment gérer les problèmes de latence lors des échanges d’information ? Comment assurer une qualité de service même lorsque la connexion réseau est interrompue ? Comment choisir quelle part de l’application s’exécute sur le client et quelle part s’exécute sur le serveur ? Comment éviter aux développeurs d’avoir à résoudre ces problèmes sans pour autant masquer la nature distribuée des applications Web et au risque de perdre les avantages de ces architectures ? D’autre part, l’environnement d’exécution est différent entre les clients et serveurs, produisant une distance ❧♦❣✐❝✐❡❧❧❡. En effet, côté client, le programme s’exécute dans un navigateur Web dont l’interface de programmation (API) permet de réagir aux actions de l’utilisateur et de mettre à jour le document affiché. De l’autre côté, c’est un serveur Web qui traite les requêtes des clients selon le protocole HTTP. Certains aspects d’une application Web peuvent être communs aux parties client et serveur, par exemple la construction de morceaux de pages Web, la validation de données saisies dans les formulaires, la navigation ou même certains calculs métier. Cependant, comme les API des environnements client et serveur sont différentes, comment mutualiser ces aspects tout en bénéficiant des mêmes performances d’exécution qu’en utilisant les API natives ? De même, comment conserver la possibilité de tirer parti des spécificités de chaque environnement ? Les travaux de cette thèse ont pour but de raccourcir cette distance, tant logicielle que matérielle, tout en préservant la capacité à tirer parti de cette distance, c’est-à-dire en donnant autant de contrôle aux développeurs. La première contribution concerne la distance matérielle. Nous proposons un modèle d’architecture pour les applications interactives et collaboratives fonctionnant en mode connecté et déconnecté. Notre modèle isole la préoccupation de synchronisation client-serveur, offrant ainsi un modèle de développement plus simple pour les développeurs. La seconde contribution concerne la distance logicielle. Nous nous appuyons sur un mécanisme d’évaluation retardée, permettant à un même programme d’être exé- cuté côté client ou serveur, pour bâtir des abstractions, offrant un modèle de programmation homogène et haut-niveau, produisant du code tirant parti des spécificités des environnements client et serveur. Nous avons observé que la taille du codeécrit avec nos outils est du même ordre de grandeur que celle d’un code utilisant des bibliothèques haut-niveau existantes et 35% à 50% plus petite que celle d’un code bas-niveau, mais les performances d’exécution sont du même ordre de grandeur que celles d’un code bas-niveau et 39% à 972% meilleurs qu’un code haut-niveau. Une troisième contribution s’adresse aux adeptes du typage statique. En effet l’API du navigateur est conçue pour un langage dynamiquement typé, JavaScript, et certaines de ses fonctions peuvent être difficiles à exposer dans un langage statiquement typé. En effet, les solutions actuelles perdent en général de l’information, contraignant les développeurs à effectuer des conversions de type contournant le système de typage, ou proposent des fonctions avec un pouvoir d’expression réduit. Nous proposons deux façons d’exposer ces fonctions dans des langages statiquement typés, en nous appuyant respectivement sur les types paramétrés ou les types dépendants. Notre approche, tout en étant bien typée, permet de réduire le nombre de fonctions exposées aux développeurs tout en conservant le même pouvoir d’expression que l’API native. Abstract Thanks to information technologies, some tasks or information process can be automated, thus saving a significant amount of money. The web platform brings numerous of such digital tools. These are hosted on web servers that centralize information and coordinate users, which can use the tools from several kinds of devices (desktop computer, laptop, smartphone, etc.), by using a web browser, without installing anything. Nevertheless, developing such web applications is challenging. The difficulty mainly comes from the ❞✐st❛♥❝❡ between client and server devices. First, the physical distance between these machines requires them to be networked. This raises several issues. How to manage latency ? How to provide a good quality of service even when the network is down ? How to choose on which side (client or server) to execute a computation ? How to free developers from addressing these problems without yet hiding the distributed nature of web application so that they can still benefit from their advantages ? Second, the execution environment is different between clients and servers. Indeed, on client-side the program is executed within a web browser whose API provides means of reacting to user actions and of updating the page. On server-side, the program is executed on a web server that processes HTTP requests. Some aspects of web applications can be shared between client and server sides (❡✳❣✳ content display, form validation, navigation, or even some business computations). However, the APIs and environments are different between clients and servers, so how to share the same code while keeping the same execution performance as with native APIs ? How to keep the opportunity to leverage the specificities of a given platform ? This work aims at shortening this distance while keeping the opportunity to leverage it, that is while giving developers as much expressive power. Our first contribution consists of an architecture pattern to build interactive andcollaborative web applications handling on-line and off-line modes. Our pattern captures the client-server synchronization concern, thus giving developers a simpler programming model. Our second contribution shows how to use a delayed evaluation mechanism to build high-level abstractions that can be shared between client and server sides and that generate efficient code leveraging the specificities of each platform. We observed that the size of the code written using our abstractions is similar to code that uses high-level libraries, and 35% to 50% smaller than low-level code, while execution performance are similar to low-level code and 39% to 972% faster than high-level code. Our third contribution makes it easier to use the web browser’s API from a statically typed language. Indeed, this API is designed to be used with the dynamically typed language JavaScript, and some functions are hard to encode in a static type system. Current solutions either loose type information, requiring users to perform unsafe typecasts or reduce the expressive power. We show two ways to encode challenging web browser’s functions in a static type system by leveraging parameterized types and dependent types. Our approach is typesafe and keeps the same expressive power as the native API. Analyse de vuln´erabilit´es de syst`emes avioniques embarqu´es : classification et exp´erimentation Anthony Dessiatnikoff To cite this version: Anthony Dessiatnikoff. Analyse de vuln´erabilit´es de syst`emes avioniques embarqu´es : classi- fication et exp´erimentation. Embedded Systems. Institut d’Optique Graduate School, 2014. French. . HAL Id: tel-01077930 https://tel.archives-ouvertes.fr/tel-01077930 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.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 17/07/2014 par : Anthony DESSIATNIKOFF Analyse de vulnérabilités de systèmes avioniques embarqués : classification et expérimentation JURY Jean-Louis LANET Université de Limoges Rapporteur Olivier FESTOR Télécom Nancy Rapporteur Bertrand LECONTE Ingénieur Airbus Examinateur Colas LE GUERNIC Ingénieur DGA Examinateur Vincent NICOMETTE INSA de Toulouse Examinateur Eric ALATA INSA de Toulouse Directeur de thèse É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 de Thèse : Eric ALATA Rapporteurs : Jean-Louis LANET et Olivier FESTORiiRemerciements Les travaux présentés dans ce mémoire ont été effectués au Laboratoire d’Analyse et d’Architecture des Systèmes (LAAS) du Centre National de la Recherche Scientifique (CNRS). Je remercie Raja Chatila, Jean-Louis Sanchez et Jean Arlat qui ont assuré la direction du LAAS depuis mon entrée. Je remercie également Karama Kanoun et Mohamed Kaâniche, responsables successifs de l’équipe de recherche Tolérance aux fautes et Sûreté de Fonctionnement informatique (TSF), pour m’avoir permis de réaliser mes travaux au sein du groupe. Je remercie la Direction Générale de l’Armement (DGA) et le CNRS pour m’avoir financé pendant 3 années puis l’Agence Nationale de la Recherche avec le projet SOBAS pendant les derniers mois. Je tiens à exprimer ma profonde reconnaissance et un grand respect à Yves Deswarte, Directeur de Recherche au CNRS, pour m’avoir accueilli en stage au LAAS en 2009 et m’avoir fait confiance pour la réalisation de ces travaux de thèse en 2010 et pour avoir été mon directeur de thèse pendant 3 années. Sa disparition le 27 janvier 2014 a été une profonde douleur. J’exprime ma gratitude et remercie Éric Alata et Vincent Nicomette pour m’avoir encadré avec Yves Deswarte pendant ma thèse. Ils étaient toujours disponibles pour discuter et corriger mes erreurs, malgré leurs emplois du temps très chargés. J’adresse également mes sincères remerciements aux membres du jury qui ont accepté de juger mon travail. Je leur suis très reconnaissant pour l’intérêt qu’ils ont porté à mes travaux : – Jean-Louis Lanet, Professeur des Universités, laboratoire XLIM de Limoges – Olivier Festor, Professeur des Universités, Télécom Nancy – Vincent Nicomette, Professeur des Universités, INSA de Toulouse – Bertrand Leconte, Ingénieur de recherche, Airbus, Toulouse – Colas Le Guernic, Ingénieur de recherche, DGA, Rennes Je remercie particulièrement Messieurs Jean-Louis Lanet et Olivier Festor qui ont accepté la charge d’être rapporteurs. Je remercie les nombreuses personnes ayant participé, depuis le début ou en partie, au projet SOBAS de l’ANR : Bertrand Leconte (Airbus), Benoît Triquet (Airbus), Alain Combes (Airbus), Cristina Simache (Altran), Julien Iguchi-Cartigny (XLIM), Jean-Paul Blanquart (ASTRIUM), Stéphane Duverger (EADS), les membres de l’ANSSI ainsi que les autres personnes que j’ai pû oublier. iiiUne mention particulière est donnée à Benoît Triquet (Airbus) et Fabrice Thorignac (Atos Origin) pour m’avoir accueilli dans les locaux d’Airbus plusieurs jours pendant ces 3 années et qui m’ont énormément aidé pour la compréhension du code noyau, des applications avioniques et du P4080. Je remercie également Stéphane Duverger pour son enthousiasme permanent et sa grande expertise sur les systèmes d’exploitation. De plus, je remercie Cristina Simache ainsi que les autres personnes qui ont relu et corrigé le manuscrit. Je remercie également tous les doctorants, docteurs, post-doctorants et stagiaires de l’équipe TSF que j’ai pû rencontrer, je ne peux pas tous les citer mais je vais essayer : Miruna, Carla, Fernand, Miguel, Camille, Jesus, Pierre, Thibaut, Amira, Quynh Anh, Moussa, Hélène, Ludovic, Olivier, Benoît, Ivan, Yann, Joris, Roberto, Mathilde, Kalou, Julien, Guthemberg, Fanny, Robert, Hongli, Roxana, Irina, Kossi, Jimmy, Amina, Rim, Damien, Éric, Géraldine, etc. dont je me suis lié d’amitié avec une grande partie. Je remercie tous les permanents TSF car ils contribuent pour beaucoup à la bonne entente générale dans l’équipe TSF. J’ai eu la chance de rencontrer au LAAS beaucoup de monde très intéressant, j’ai une pensée pour Jean-Claude Laprie (qui était un grand monsieur, dans tous les sens du terme). De plus, je remercie Sonia De Sousa pour sa gestion parfaite du secrétariat du thème Informatique Critique du laboratoire, elle a toujours été disponible et très efficace pour m’aider dans les différentes tâches administratives. Je pense également à mes autres amis que je vois trop peu à cause de la distance et qui m’ont soutenu : Richard, Antoine et Mellie, Damien et Caroline, Steven et Lucie, et les autres. Je tiens à remercier particulièrement ma famille qui m’a toujours soutenu depuis le début, même s’ils n’ont pas toujours compris ce que je faisais exactement, ils ont le mérite de m’avoir encouragé dans les moments difficiles. iv« La vraie faute est celle qu’on ne corrige pas. » Confucius (551 – 479 avant J.C.) vviSommaire Table des figures xi Introduction générale 1 Chapitre 1 État de l’art de la sécurité des systèmes avioniques 5 1.1 Systèmes avioniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.1 Architecture fédérée . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.2 Architecture IMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Sûreté de fonctionnement et le développement logiciel . . . . . . . . . . . 12 1.2.1 Quelques définitions de la sûreté de fonctionnement . . . . . . . . 12 1.2.2 Tolérance aux fautes dans le domaine avionique . . . . . . . . . . . 15 1.2.3 Développement de logiciels critiques sûrs . . . . . . . . . . . . . . . 16 1.2.4 Sécurité-immunité dans les standards avioniques . . . . . . . . . . 20 1.3 Problématique de la sécurité-immunité dans les systèmes avioniques . . . 23 1.3.1 Connectivité accrue entre les applications . . . . . . . . . . . . . . 24 1.3.2 Partage de ressource entre applications . . . . . . . . . . . . . . . . 25 1.3.3 Utilisation de composants COTS . . . . . . . . . . . . . . . . . . . 26 1.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.4 Différentes approches pour améliorer la sécurité-immunité . . . . . . . . . 26 1.4.1 Intégration de mécanismes de sécurité adaptés . . . . . . . . . . . 27 1.4.2 Utilisation de méthodes formelles . . . . . . . . . . . . . . . . . . . 27 1.4.3 Analyse de vulnérabilités dans le processus de développement . . . 29 1.5 Analyse de vulnérabilités dans les systèmes critiques embarqués . . . . . . 29 1.5.1 Approche par boîte blanche . . . . . . . . . . . . . . . . . . . . . . 30 1.5.2 Approche par boîte noire . . . . . . . . . . . . . . . . . . . . . . . 31 1.6 Contribution de cette thèse . . . . . . . . . . . . . . . . . . . . . . . . . . 32 viiChapitre 2 Caractérisation des attaques des systèmes embarqués 35 2.1 Attaques visant les fonctionnalités de base . . . . . . . . . . . . . . . . . . 36 2.1.1 Attaques ciblant le processeur . . . . . . . . . . . . . . . . . . . . . 36 2.1.2 Attaques ciblant la gestion de la mémoire . . . . . . . . . . . . . . 38 2.1.3 Attaques ciblant les communications . . . . . . . . . . . . . . . . . 41 2.1.4 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . 43 2.1.5 Attaques ciblant la gestion des processus . . . . . . . . . . . . . . 44 2.1.6 Attaques ciblant l’ordonnancement . . . . . . . . . . . . . . . . . . 45 2.1.7 Attaques ciblant les mécanismes cryptographiques . . . . . . . . . 45 2.1.8 Attaques ciblant les fonctions ancillaires . . . . . . . . . . . . . . . 46 2.1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.2 Les attaques ciblant les mécanismes de tolérance aux fautes . . . . . . . . 46 2.2.1 Détection d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.2.2 Recouvrement d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . 50 2.2.3 Traitement de fautes . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.3 Contexte et hypothèses d’attaques . . . . . . . . . . . . . . . . . . . . . . 52 2.3.1 Attaquants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.3.2 Hypothèse d’attaque : une application non critique malveillante . . 54 Chapitre 3 Mise en œuvre de la méthodologie 57 3.1 Système expérimental d’Airbus : noyau et partitions . . . . . . . . . . . . 57 3.1.1 Hypothèses concernant la partition malveillante . . . . . . . . . . . 59 3.1.2 Phases d’exécution d’une partition . . . . . . . . . . . . . . . . . . 60 3.2 Architecture du P4080 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.2.1 Structure des cœurs e500mc . . . . . . . . . . . . . . . . . . . . . . 63 3.2.2 Contrôleur d’interruption . . . . . . . . . . . . . . . . . . . . . . . 63 3.2.3 DataPath Acceleration Architecture (DPAA) . . . . . . . . . . . . . 64 3.2.4 Démarrage sécurisé . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.3 Présentation de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.3.1 Observation du noyau et des applications . . . . . . . . . . . . . . 66 3.3.2 Configuration de la plateforme d’expérimentation . . . . . . . . . . 67 3.4 Attaques ciblant la gestion de la mémoire . . . . . . . . . . . . . . . . . . 70 3.4.1 Attaques ciblant le Security Engine . . . . . . . . . . . . . . . . . . 70 3.4.2 Attaques ciblant le Run Control/Power Management . . . . . . . . 72 viii3.5 Attaques ciblant les communications . . . . . . . . . . . . . . . . . . . . . 72 3.5.1 Attaques ciblant les communications AFDX . . . . . . . . . . . . . 72 3.5.2 Attaques ciblant les IPC . . . . . . . . . . . . . . . . . . . . . . . . 75 3.6 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . . . . . 78 3.6.1 Première attaque : utilisation des interruptions . . . . . . . . . . . 78 3.6.2 Seconde attaque : modification de la configuration d’une partition 81 3.6.3 Utilisation conjointe des deux attaques . . . . . . . . . . . . . . . . 82 3.7 Attaques ciblant les mécanismes de tolérance aux fautes . . . . . . . . . . 82 3.7.1 Réalisation du programme Crashme . . . . . . . . . . . . . . . . . 82 3.7.2 Instrumentation du noyau . . . . . . . . . . . . . . . . . . . . . . . 83 3.7.3 Résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Chapitre 4 Protections des systèmes avioniques contre les malveillances 87 4.1 Contre-mesures spécifiques à notre plateforme d’expérimentation . . . . . 88 4.1.1 Attaques ciblant la gestion de la mémoire . . . . . . . . . . . . . . 88 4.1.2 Attaques ciblant les communications . . . . . . . . . . . . . . . . . 89 4.1.3 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . 91 4.1.4 Attaques ciblant les mécanismes de tolérance aux fautes . . . . . . 92 4.2 Contre-mesures génériques . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.2.1 Attaques ciblant le processeur . . . . . . . . . . . . . . . . . . . . . 94 4.2.2 Attaques ciblant la mémoire . . . . . . . . . . . . . . . . . . . . . . 96 4.2.3 Attaques ciblant les communications . . . . . . . . . . . . . . . . . 97 4.2.4 Attaques ciblant la gestion du temps . . . . . . . . . . . . . . . . . 98 4.2.5 Attaques ciblant la cryptographie . . . . . . . . . . . . . . . . . . . 98 4.2.6 Attaques ciblant les fonctions ancillaires . . . . . . . . . . . . . . . 98 4.2.7 Attaques ciblant les mécanismes de tolérance aux fautes . . . . . . 99 4.2.8 Recommandation aux développeurs . . . . . . . . . . . . . . . . . . 100 4.2.9 Analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.2.10 Analyse dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.3 Architecture sécurisée pour la gestion d’un périphérique partagé . . . . . 102 4.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.3.2 Virtualisation matérielle d’un périphérique . . . . . . . . . . . . . 103 4.3.3 Utilisation de SR-IOV dans un contexte avionique embarqué . . . 105 ixConclusion générale 107 Bibliographie 111 xTable des figures 1.1 Architecture fédérée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Architecture IMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Exemple de Module IMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.4 L’arbre de la sûreté de fonctionnement . . . . . . . . . . . . . . . . . . . . 12 1.5 Guide de conception et techniques de certification (ARP 4754A, [arp10]) . 18 1.6 Les domaines de réseaux dans un avion (ARINC 811). . . . . . . . . . . . 22 1.7 Les domaines de réseaux dans un avion (extrait de [ari05]). . . . . . . . . 24 1.8 Partage simple entre 2 applications d’un module. . . . . . . . . . . . . . . 25 1.9 Visualisation des hypothèses de bas niveau. . . . . . . . . . . . . . . . . . 28 2.1 Hiérarchie des caches (architecture Harvard). . . . . . . . . . . . . . . . . 37 2.2 Les différents types de communications. . . . . . . . . . . . . . . . . . . . 42 2.3 Exemple d’une partition de 300 microsecondes. . . . . . . . . . . . . . . . 44 2.4 Schéma des différents traitements de la tolérance aux fautes. . . . . . . . . 47 3.1 Exemple d’ordonnancement avec 5 partitions. . . . . . . . . . . . . . . . . 58 3.2 Exemple d’entrées dans la TLB avec deux partitions et un noyau. . . . . . 60 3.3 Les deux phases de trois partitions. . . . . . . . . . . . . . . . . . . . . . . 60 3.4 Fonctionnement d’un Global Timer. . . . . . . . . . . . . . . . . . . . . . 61 3.5 Architecture du P4080 (extrait de [Fre11]). . . . . . . . . . . . . . . . . . 62 3.6 QorIQ DataPath Acceleration Architecture. . . . . . . . . . . . . . . . . . 64 3.7 La plateforme d’expérimentation. . . . . . . . . . . . . . . . . . . . . . . . 66 3.8 Sonde JTAG de Freescale. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.9 Capture d’écran du logiciel IDE Codewarrior de Freescale. . . . . . . . . . 68 3.10 Diagramme des états du SEC [Fre11]. . . . . . . . . . . . . . . . . . . . . 71 3.11 Chaîne de compilation pour une partition utilisant AFDX. . . . . . . . . . 73 3.12 Exemple de communication IPC . . . . . . . . . . . . . . . . . . . . . . . 75 3.13 Appel-système depuis l’Application 0 . . . . . . . . . . . . . . . . . . . . . 76 3.14 Boucle infinie l’Application 0 . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.15 Mesures des temps sur un cycle (5 ms). . . . . . . . . . . . . . . . . . . . 79 3.16 Comportement normal des deux partitions. . . . . . . . . . . . . . . . . . 80 3.17 Dépassement de P6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.18 Dépassement de la phase de préparation de P7. . . . . . . . . . . . . . . . 81 xi3.19 Dépassement de la phase de préparation et de la phase opérationnelle de P7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.1 Exemple d’accès entre 2 partitions et une partition I/O. . . . . . . . . . . 89 4.2 Proposition de contre-mesure sur le mécanisme IPC. . . . . . . . . . . . . 91 4.3 Proposition de contre-mesure prenant en compte les durées d’exécution d’interruption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.4 Architecture de virtualisation Single Root I/O [sri]. . . . . . . . . . . . . . 104 xiiIntroduction générale Contexte et problématique La sécurité des systèmes embarqués avioniques, au sens safety (ou sécurité-innocuité) est depuis toujours une préoccupation majeure des concepteurs et des exploitants de ces systèmes et plus largement du grand public. Historiquement, les sources de défaillance de ces systèmes étaient essentiellement liées à l’occurrence de fautes accidentelles, affectant les composants matériels ou logiciels, ou bien à des interactions humaines inappropriées. Cependant, le rôle de plus en plus prépondérant joué par les systèmes informatiques au sein des systèmes avioniques et également l’impact de leurs communications avec d’autres systèmes de l’environnement avionique posent de nouvelles problématiques relatives à la sécurité (au sens security ou sécurité-immunité) et aux risques d’attaques informatiques qui viennent s’ajouter aux contraintes de safety (ou sécurité-innocuité). Cette importance de la notion de sécurité-immunité est liée à l’évolution des systèmes d’information qui vise à réduire les coûts de production et d’opération. Cette évolution repose principalement sur trois approches. Tout d’abord, l’industrie aéronautique propose des systèmes d’information de plus en plus ouverts aux passagers et aux compagnies aériennes. Cette approche entraîne un élargissement de la surface d’attaque. Ensuite, l’industrie aéronautique utilise de plus en plus de composants sur étagère (ou COTS pour Commercial Off-The-Shelf) pour des applications plus ou moins critiques. Ces composants, étant conçus pour être génériques, sont souvent d’une plus grande complexité que ceux destinés à un système particulier. Cette complexité les fragilise vis-à-vis de la sécurité. En effet, il est pratiquement impossible de les vérifier parfaitement, c’est-à- dire de garantir, d’une part, l’absence de bogues, et, d’autre part, l’absence de fonctions cachées. Pour finir, le partage des ressources est de plus en plus employé pour héberger, au sein d’un même système, différentes applications ayant potentiellement différentes exigences de sécurité. Pour améliorer le niveau de sécurité des systèmes embarqués avioniques critiques, des techniques rigoureuses de développement, s’appuyant de plus en plus sur des méthodes formelles, sont utilisées pour accompagner les phases de spécification, de conception, de vérification et de certification, dans le but de contrôler si les propriétés de sécurité sont assurées. Cependant ces méthodes ne peuvent pas prendre en compte toutes les malveillances, notamment celles qui visent à exploiter certaines vulnérabilités invisibles par les méthodes formelles. Ces vulnérabilités exploitables se trouvent à l’interface entre 1logiciel et matériel, en particulier dans l’implémentation par le matériel de fonctions exploitées par le logiciel (gestion de l’adressage, gestion des interruptions, mécanismes de tolérance aux fautes, etc.) mais aussi sur des fonctions annexes de gestion du matériel (contrôle de fréquence d’horloge, de la consommation, de la température, de l’alimentation, etc.). Ces aspects ne sont généralement pas considérés par des modèles formels. En effet, il est difficile pour ce type de modèles de prendre en compte à la fois des propriétés de sécurité de haut niveau (par exemple l’intégrité des données critiques) et une représentation fine d’une implémentation matérielle. L’approche formelle doit donc être complétée par des analyses de vulnérabilités. Traditionnellement, ces analyses ne sont réalisées que lorsque le système est complètement intégré, donc très tard dans le cycle de développement, ce qui ne permet que de corriger ponctuellement des fautes de conception ou d’implémentation. L’approche développée dans cette thèse vise donc à compléter les méthodes formelles de conception et de développement par une analyse de vulnérabilités de façon à identifier au plus tôt des classes génériques de vulnérabilités, soit pour modifier la conception, soit pour développer des contre-mesures génériques, capables d’empêcher l’exploitation des vulnérabilités identifiées, mais aussi d’autres vulnérabilités similaires non encore connues. Ces travaux ont été effectuées dans le cadre du projet ANR SOBAS (Securing OnBoard Aerospace Systems). Présentation de nos travaux Nous débutons ce manuscrit par un chapitre dédié à la présentation des architectures des systèmes avioniques ainsi que leur évolution, étroitement liée aux avancées signifi- catives du domaine du logiciel. Ensuite, nous présentons les approches employées pour améliorer la sécurité-immunité dans ces systèmes et nous nous focalisons sur l’analyse de vulnérabilités, qui est l’objet de ce manuscrit. Nous concluons ce chapitre par la proposition d’une démarche en trois étapes pour l’application de l’analyse de vulnérabilités. Chacune de ces étapes fait ensuite l’objet d’un chapitre. La première étape, présentée dans le second chapitre, est dédiée à la caractérisation des attaques des systèmes embarqués. Les systèmes étant composés de différents composants matériels et logiciels, ces composants sont passés en revue pour identifier les attaques qui peuvent les concerner. Les composants passés en revue sont les composants matériels, les composants logiciels du système d’exploitation et les mécanismes de tolé- rance aux fautes. L’objectif de ce chapitre est de proposer une approche pour recenser l’ensemble des risques possibles, qui doivent faire l’objet d’une étude plus approfondie. La seconde étape se focalise sur la mise en œuvre des attaques sur une plateforme d’expérimentation. Ce travail est présenté dans le troisième chapitre. Tout d’abord, nous détaillons les différents éléments constituant notre plateforme d’expérimentation. Ensuite, quatre classes d’attaques correspondant aux attaques les plus importantes sont présentées, et les résultats sont discutés. Le quatrième chapitre présente la dernière étape de notre approche. Cette étape passe à nouveau en revue les classes d’attaques identifiées lors de la caractérisation, et identifie, 2pour chacune de ces classes d’attaques, un ensemble de contre-mesures adaptées. Ce chapitre est structuré en trois parties. Les contre-mesures spécifiques aux vulnérabilités identifiées dans le troisième chapitre sont dans un premier temps discutées. Ensuite, ces contre-mesures sont généralisées pour être adaptées à tout système embarqué. Pour finir, une architecture matérielle et logicielle, permettant le partage d’un périphérique entre plusieurs applications, est présentée et illustrée avec une carte réseau. Nous concluons ce manuscrit par une synthèse de nos contributions et présentons quelques perspectives de notre travail. 34Chapitre 1 État de l’art de la sécurité des systèmes avioniques Introduction Selon le US-CERT1 , le nombre d’attaques informatiques est en forte augmentation depuis 2006 [usc12]. Cette augmentation peut s’expliquer par deux raisons : la première est la complexité des systèmes actuels qui est de plus en plus élevée et donc plus difficile à gérer [Lab12] ; la deuxième raison est la simplicité d’utilisation d’outils automatiques d’attaque, maintenant accessibles aux débutants. Ces outils peuvent par exemple être utilisés pour réaliser des attaques de type Distributed-Denial-of-Service2 . A titre d’exemple, le groupe de pirates Anonymous a lancé une série d’attaques en janvier 2012 après la fermeture du site de partage Megaupload, ce qui a rendu indisponible de nombreux sites Internet [Can12]. Un autre exemple d’attaque de plus grande envergure est celle d’août 2013 qui a touché la Chine en bloquant les accès à une grande partie des sites Internet Chinois [01N13]. Avec la même facilité, les attaques contre des applications Web sont aussi possibles avec des outils tels que WebScarab [OWA13]. Ces outils en libre circulation sont performants et permettent de lancer des attaques contre n’importe quel système distant. Il s’agit de programmes malveillants qui peuvent endommager de façon catastrophique les systèmes ciblés : accès, modification de données confidentielles ; espionnage du système (keylogger) ; interruption de services (Denial-of-Service) ; exécution de virus ou rootkit ; attaque par force brute pour obtenir des mots de passe ; etc. Les systèmes embarqués avioniques peuvent également être ciblés par ces attaques. Il est donc important de les protéger efficacement contre ces malveillances. Une attaque informatique visant un système avionique peut avoir de graves conséquences comme des pertes matérielles voire des pertes humaines. Afin d’éviter l’occurrence de défaillances dans les systèmes avioniques, des mécanismes de tolérance aux fautes sont utilisés (redondance, votes majoritaires, etc.). Cependant, ces mécanismes sont efficaces pour des défaillances d’origine accidentelle mais ils ne sont pas forcément efficaces face à des at- 1United States Computer Emergency Readiness Team. 2Technique distribuée pour rendre hors service un serveur par inondation de requêtes. 5taques (autrement dit, face à des fautes d’origine intentionnelle). Il est donc nécessaire de considérer aussi d’autres moyens de protection, spécifiquement développés pour faire face aux fautes intentionnelles que sont les attaques informatiques. Et même si de tels moyens sont déjà utilisés dans les avions aujourd’hui, ils ne sont pas dans la même état de maturité que les mécanismes de tolérance aux fautes accidentelles. De plus, les architectures des systèmes embarqués avioniques évoluant, les menaces considérées évoluant également, il est donc fondamental d’améliorer ces mécanismes et de les adapter aux nouvelles architectures. Dans ce chapitre, nous décrivons une architecture utilisée pour la conception de système avionique. Ensuite, nous présentons les normes avioniques qui permettent de s’assurer que le code utilisé est conforme à sa spécification et ne contient pas de faute. Ensuite, nous détaillons comment ces systèmes sont protégés vis-à-vis des fautes accidentelles (sécurité-innocuité ou safety) et vis-à-vis des malveillances (sécurité-immunité ou security). Nous concluons ce chapitre en présentant une méthodologie d’analyse de vulnérabilités permettant d’identifier les vulnérabilités lors du développement afin d’intégrer au système les mécanismes de protection les plus adaptés, avant la finalisation du développement du système. 1.1 Systèmes avioniques Le terme architecture avionique représente l’ensemble des matériels et logiciels embarqués à bord de l’avion, qui assurent diverses fonctions telles que le traitement des informations provenant des capteurs, le pilotage automatique, la gestion du niveau de carburant, les échanges de messages avec l’opérateur au sol, pendant le vol, etc. Les architectures avioniques occupent une place non négligeable dans le coût des avions modernes (de l’ordre de 33% du coût total [pip09]). 1.1.1 Architecture fédérée Historiquement, dans les systèmes avioniques, chaque fonction de contrôle disposait de ses propres ressources matérielles (représentées par une machine ou un calculateur) pour son exécution, comme le montre la figure 1.1. Ces dispositifs dédiés sont très souvent répliqués pour la tolérance aux fautes et peuvent varier d’une fonction à l’autre. Il en résulte ainsi une architecture hétérogène et faiblement couplée, où chaque fonction peut opérer de manière quasi indépendante vis-à-vis des autres fonctions. Une telle architecture est qualifiée de fédérée. Par exemple, la construction des Airbus A330 et A340 repose sur ce type d’architecture. Les équipements numériques mettant en œuvre certaines des fonctions à bord sont reliés par des bus mono-émetteur. Un avantage majeur des architectures fédérées, en plus de leur simplicité, est la minimisation des risques de propagation d’erreurs qui peuvent survenir lors de l’exécution d’une fonction au sein du système. Cela assure une meilleure disponibilité du système global dans la mesure où une fonction défaillante peut éventuellement être isolée sans avoir recours à un arrêt complet du système. Cette caractéristique inhérente aux ar- 6Fig. 1.1 – Architecture fédérée chitectures fédérées est primordiale dans des systèmes critiques comme ceux qui sont embarqués dans les avions. Un autre avantage des architectures fédérées est leur hétérogénéité. En effet, les types de machines utilisées peuvent varier d’une fonction à l’autre au sein du même système. Cela permet l’utilisation de machines ayant des puissances variables. Cependant, cette vision classique de systèmes fédérés présente des inconvénients liés à une forte dépendance entre le logiciel et le matériel que nous résumons dans les points suivants : • La communication entre systèmes dépend des applications et également du maté- riel d’exécution. Toute mise à jour d’une entité logicielle implique une modification importante dans le mécanisme de communication, entraînant souvent la modification des autres entités logicielles pour maintenir une bonne interopérabilité. • Le matériel utilisé dans les applications avioniques est très hétérogène. En effet, chaque application possède ses propres contraintes fonctionnelles, et est exécutée sur un matériel qui lui est dédié. Assurer la maintenance matérielle dans ces conditions est une tâche fort coûteuse, d’un point de vue économique. • La durée de vie d’un avion est de l’ordre de plusieurs dizaines d’années (25-30 ans, voire plus). Cette durée de vie est longue relativement à la durée de vie d’un maté- riel. En effet, vu les avancées technologiques actuelles, un matériel devient obsolète au bout de quelques années seulement. Dans de nombreux cas, le matériel planifié durant la conception peut même devenir obsolète au moment de la construction de l’appareil. De plus, même si ce matériel est mis à jour, il faut bien s’assurer de la portabilité du logiciel qui n’a pas été originellement développé pour ce nouveau matériel. Cette tâche s’avère particulièrement coûteuse en raison du lien étroit qui existe entre le logiciel et le matériel dans un système fédéré. 71.1.2 Architecture IMA Dans les années 1990, sous l’impulsion de la commission européenne, des projets européens de recherche tel que PAMELA, NEVADA et VICTORIA [PAM01, NEV01, VIC01], ont permis l’émergence d’une autre vision dans la conception des systèmes avioniques ; celle-ci a pour but de pallier les insuffisances des architectures fédérées en proposant de dissocier les composants logiciels des composants matériels (dans les systèmes fédérés). Ce type d’architecture est qualifié de modulaire intégré, plus communément appelé IMA (Integrated Modular Avionics) [ARI08]. Le principe de l’architecture IMA [Mor91] est de répartir dans tout le volume de l’appareil un ensemble de ressources (calcul, mémoire, communication), qui pourront être partagées par plusieurs applications, qui accompliront les différentes fonctions du système avionique. Des exemples d’avions adoptant la solution intégrée sont l’Airbus A380 ou le Boeing B777. L’approche IMA présente trois principaux avantages : • Réduction du poids grâce à un plus petit nombre de composants matériels et un câblage réduit, ce qui augmente l’efficacité énergétique ; • Coût de maintenance réduit par l’utilisation de modules génériques ; • Réduction des coûts de développement par l’utilisation de systèmes standardisés et de COTS (Commercial-Off-The-Shelf). Cette organisation du système présente une plateforme unique (cf. Figure 1.2) pour plusieurs applications logicielles avioniques qui permet d’économiser les ressources, contrairement aux architectures fédérées. Par la même occasion, le coût de réalisation peut être limité de façon raisonnable. La plateforme consiste en un réseau temps-réel distribué, permettant à différentes applications de s’exécuter en parallèle. Cependant, elle introduit un risque de propagation d’erreur. Par exemple, une fonction en dysfonctionnement peut monopoliser le système de communication ou envoyer des commandes inappropriées, et pour chacune des fonctions il est difficile de se mettre à l’abri d’un tel comportement. Il est donc indispensable qu’une telle architecture assure un partage de ressource sûr entre les applications : le mécanisme dit de partitionnement [ARI08]. Par ce moyen, une ou plusieurs applications regroupées au sein d’un même module peuvent s’exécuter de manière sûre en parallèle (deux fonctions quelconques prévues pour s’exécuter dans un même module ne peuvent en aucun cas interagir l’une avec l’autre). De manière pratique, l’architecture physique est décrite par la norme ARINC 651. Les ressources sont regroupées dans des modules génériques appelés LRM (Line Replaceable Module), qui sont à leur tour regroupés dans des étagères, la communication au sein de ces étagères étant réalisée avec des bus spéciaux, généralement de type ARINC 659. Les modules peuvent être de trois types : • des modules cœurs qui sont ceux qui se chargent de l’exécution des applications ; • des modules d’entrée/sortie permettant la communication avec des éléments ne respectant pas l’architecture IMA ; • des modules passerelles servant à la communication entre étagères (l’architecture 8IMA n’impose pas de moyen de communication spécifique entre ses différents composants). Fig. 1.2 – Architecture IMA Ce partitionnement est classé en partitionnement spatial (par exemple, la gestion de la mémoire) et temporel (la gestion des ressources temporelles par le CPU) [Rus99]. Le partitionnement spatial des applications repose sur l’utilisation de composants matériels chargés de gérer la mémoire pour empêcher toute corruption de zones mémoires adjacentes à une zone en cours de modification. Le partitionnement temporel dépend des fonctionnalités attendues de l’ensemble (par exemple, on aura besoin d’exécuter plus souvent des fonctions qui s’occupent du rafraî- chissement de paramètres critiques). Avec ce partitionnement, des tranches de temps pour l’exécution des applications et l’exécution du noyau du système sont allouées statiquement. Afin de déterminer la durée des tranches de temps, des études d’estimation du pire cas du temps d’exécution (WCET3 ) sont réalisées de façon dynamique (sur le maté- riel ou sur simulateur) ou de façon statique (sans exécution) [Pua11]. Les méthodes d’estimation du WCET ne sont définies dans aucune norme avionique, il faut donc choisir la méthode appropriée en fonction de ses besoins. Il faut également prendre en compte l’utilisation de plusieurs cœurs dans les processeurs aujourd’hui car les multi-cœurs tendent à remplacer les mono-cœurs [Gen13, ZY09] ce qui change considérablement les calculs des durées d’exécution. La méthode dynamique d’évaluation du WCET s’appuie sur l’exécution de l’application sur le matériel ou sur simulateur et la mesure du temps d’exécution entre le début et la fin d’exécution. Le comportement de l’application peut dépendre des entrées/sorties. Il est donc nécessaire de générer ces informations. Une couverture 3Worst Case Execution Time. 9exhaustive du domaine des entrées serait bien sûr souhaitable mais le risque d’explosion combinatoire est élevé. En général, il s’agit donc de trouver un compromis entre la couverture des entrées générées et la précision du WCET que l’on souhaite obtenir. Un outil peut être utilisé pour mesurer le WCET automatiquement. Par exemple, RapiTime4 permet de créer des traces d’exécution et supporte la norme DO-178B (norme avionique sur laquelle nous reviendrons dans la suite de ce chapitre). La méthode statique d’évaluation du WCET calcule la durée d’exécution en analysant la structure du programme. Différentes techniques d’analyse existent : analyse des flux (Flow analysis), calcul avec arbre (Tree-based computation), énumeration des chemins, (IPET, Implicit Path Enumeration Technique), analyse de bas niveau (Low-level analysis). Mais en pratique, ces durées d’exécution seront forcément dépendantes du matériel et des exécutions passées. Elles doivent être calculées dans toute la chaîne d’exécution, c’est-à-dire qu’il faut être capable de connaître le chemin d’exécution exact ainsi que chaque type de données à traiter (entier, chaînes de caractères, etc.). De plus, les durées doivent être calculées pour tous les chemins d’exécution. Des outils sont également disponibles pour une méthode d’estimation statique, nous pouvons citer Bound-T5 , AbsInT6 (notamment utilisé pour l’A380). De manière générale, le partitionnement spatial et temporel désigne un mécanisme mis en place pour assurer une gestion des ressources qui ne met pas en péril le fonctionnement des applications qui l’utilise. Une architecture IMA peut donc être perçue comme un gestionnaire de ressources matérielles pour des applications avioniques embarquées. Ces applications sont implantées dans des modules pouvant avoir des niveaux de criticité différents. L’architecture IMA se doit d’être sûre afin de permettre un tel partitionnement entre applications à criticités multiples. Dans [ARI08], le partitionnement est défini comme devant assurer une isolation totale. L’isolation est réalisée en introduisant des partitions qui sont des espaces d’exécution logiques attribués à chaque fonction avionique. L’accès aux ressources (CPU, mémoire, etc) est ensuite contrôlé pour qu’il n’y ait aucune altération du fonctionnement des entités les plus critiques (des entités du niveau DAL-A ou DAL-B, par exemple). Une telle architecture est similaire à l’architecture d’un système d’exploitation classique. En effet, un système d’exploitation offre aux différentes applications qui y sont installées de s’exécuter en parallèle, indépendamment de la couche matérielle. Une architecture IMA (Figure 1.2), tout comme un système d’exploitation, offre des services (par exemple service de communication) aux applications qui y sont installées. Ces services sont accessibles via une interface de programmation des applications (Application Programming Interface : API) unique pour toutes les fonctions avioniques. Ainsi, une plateforme IMA est constituée d’un certain nombre de modules distribués dans l’avion. Ces modules sont connectés entre eux et également avec des périphériques de l’avion (typiquement des périphériques d’entrée/sortie comme des capteurs ou des interfaces homme machine). La Figure 1.3 présente l’aspect en couche d’un module IMA. Le module est constitué 4 http://www.rapitasystems.com/products/rapitime 5 http://www.bound-t.com/ 6 http://www.absint.com/ait/ 10Matériel Système d'exploitation API Application 1 Application 2 Application 3 Fig. 1.3 – Exemple de Module IMA d’un système d’exploitation en charge d’exécuter plusieurs partitions. La communication entre les partitions et le système d’exploitation du module se fait via l’API. Cette interface de programmation est la seule couche visible pour une application dans une partition donnée. Cette abstraction présente les avantages suivants : • Du fait de la transparence du matériel vis-à-vis des fonctions avioniques, il est possible d’utiliser du matériel distinct afin d’assurer une diversification matérielle (cf. 1.2.2), sans conséquence pour le fonctionnement de l’application. • La robustesse du partitionnement fait qu’une application peut être développée et testée d’une façon incrémentale, sans que cela n’altère le fonctionnement des autres partitions. • Grâce à l’interopérabilité des modules, en cas de défaillance d’un module, il est possible de reconfigurer une application logicielle pour qu’elle s’exécute sur un second module, ce qui présente une propriété fort intéressante en terme de disponibilité de l’application. Les architectures IMA sont déjà utilisées pour des fonctionnalités spécifiques sur certains appareils. Par exemple, le système d’exploitation PikeOS [KW07] est utilisé pour son niveau de certification afin de construire une architecture facile à certifier. Les équipements ainsi produits pourront être déployés sur le prochain A350 XWB. Cependant, la certification des systèmes avioniques utilise toujours la vision des systèmes fédérés. Des projets de recherche tel que SCARLETT [SCA11] définissent les évolutions de l’architecture IMA afin d’améliorer entre autre, le processus de certification. Comme nous avons pu le constater, la sécurité, au sens innocuité, est l’une des premières exigences qui a guidé le développement des fonctions avioniques (aussi bien au niveau matériel que logiciel). Cependant, la composante sécurité-immunité est devenue 11de plus en plus présente dans le monde avionique. Ces deux propriétés sont plus précisément définies dans le cadre de la sûreté de fonctionnement. 1.2 Sûreté de fonctionnement et le développement logiciel Dans cette section, nous donnons des définitions de la sûreté de fonctionnement et de ses composantes pour comprendre quelle utilité elle peut avoir dans un contexte avionique. Nous détaillons également comment s’effectue le développement de logiciels critiques en utilisant des normes et techniques de la sûreté de fonctionnement. Les défi- nitions de cette section proviennent de [L+96, ALRL04, A+06]. 1.2.1 Quelques définitions de la sûreté de fonctionnement La sûreté de fonctionnement d’un système informatique est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il leur délivre. Le service délivré par un système est son comportement tel qu’il est perçu par son, ou ses utilisateurs, l’utilisateur étant un autre système, humain ou physique qui interagit avec le système considéré. La sûreté de fonctionnement peut être représentée par l’arbre suivant : Sûreté de fonctionnement Attributs Entraves Moyens Disponibilité Fiabilité Sécurité-innocuité Confidentialité Intégrité Maintenabilité Fautes Erreurs Défaillances Prévention des fautes Tolérance aux fautes Elimination des fautes Prévision des fautes Sécurité-immunité Fig. 1.4 – L’arbre de la sûreté de fonctionnement Cet arbre permet de définir les termes importants de la sûreté de fonctionnement : les attributs, les entraves et les moyens. 121.2.1.1 Attributs La sûreté de fonctionnement peut être perçue selon différentes propriétés appelées attributs : • la disponibilité est l’aptitude du système à être prêt à l’utilisation ; • la fiabilité est la continuité de service ; • la sécurité-innocuité est l’absence de conséquences catastrophiques pour l’environnement ; • la confidentialité est l’absence de divulgations non autorisées de l’information ; • l’intégrité est l’absence d’altérations inappropriées de l’information ; • la maintenabilité est l’aptitude aux réparations et aux évolutions. Ces attributs sont à considérer suivant le système que l’on souhaite étudier. Cela permet également de différencier sans ambiguïté les termes de safety et security. Le terme safety correspond à la sécurité-innocuité, qui définit les propriétés selon lesquelles un système est dit “sûr” (sans défaillance catastrophique pouvant conduire à des pertes de vies humaines ou des conséquences économiques importantes). Le terme security correspond à la sécurité-immunité7 , qui définit les propriétés selon lesquelles un système est dit “sécurisé”. Cet attribut est une combinaison de trois autres attributs : la confidentialité, l’intégrité et la disponibilité. La sécurité-immunité permet de prendre en compte les menaces informatiques tels que les virus, vers, bombes logiques, etc. 1.2.1.2 Entraves Les entraves sont les circonstances indésirables mais non inattendues, causes ou ré- sultats de la non sûreté de fonctionnement, car la confiance n’est plus assurée dans le système. Les entraves à la sûreté de fonctionnement sont les suivantes : fautes, erreurs et défaillances. La relation entre les entraves de la sûreté de fonctionnement peut être exprimée ainsi : ... → Défaillance → Faute → Erreur → Défaillance → Faute → ... Une faute est active (après avoir été dormante) lorsqu’elle produit une erreur. L’ensemble des fautes peuvent être réparties en huit catégories, selon : la phase de création (fautes de développement ou fautes opérationnelles), les frontières du système (internes ou externes), les causes phénoménologiques (naturelles ou humaines), les objectifs (fautes malicieuses ou non), la dimension (fautes matérielles ou fautes logicielles), les intentions (fautes délibérées ou non), la capacité (fautes accidentelles ou non) ou la persistance (fautes permanentes ou éphémères). Ces fautes peuvent être combinées pour former trois grandes classes de fautes : les fautes de développement, les fautes physiques et les fautes d’interaction. Les fautes de développement constituent toutes les fautes qui surviennent pendant le développement du logiciel. Les fautes physiques incluent les fautes qui affectent le matériel. Les fautes d’interaction incluent les fautes externes. Une erreur est définie comme susceptible de provoquer une défaillance. Elle peut être latente ou détectée. Une erreur est latente tant qu’elle n’a pas été reconnue en tant 7Aussi appelée sécurité-confidentialité dans [L+96]. 13que telle ; elle est détectée par un algorithme ou un mécanisme de détection qui permet de la reconnaître comme telle. Une erreur peut disparaître avant d’être détectée. Par propagation, une erreur crée de nouvelles erreurs. Une défaillance survient lorsque, par propagation, elle affecte le service délivré par le système, donc lorsqu’elle est perçue par le ou les utilisateurs. Une défaillance est définie comme un événement qui survient quand le service délivré dévie du service correct. Les défaillances ne se manifestent pas toujours de la même manière, ce qui signifie que l’on peut parler de modes de défaillances. On peut distinguer différentes dimensions pour caractériser les défaillances : le domaine de défaillance, la détectabilité de défaillances, la cohérence des défaillances, et les conséquences des défaillances. Le domaine des défaillances permet de distinguer les défaillances en valeur (la valeur du service délivré dévie de l’accomplissement de la fonction du système) et les défaillances temporelles (la temporisation du service dévie de l’accomplissement de la fonction du système). La détectabilité des défaillances permet de distinguer les défaillances signalées (le service délivré est détecté comme incorrect) et non signalées (la délivrance d’un service incorrect n’est pas détectée). La cohérence des défaillances permet de distinguer les défaillances cohérentes et les défaillances incohérentes ou byzantines (le service incorrect peut être perçu différemment suivant les cas). Les conséquences des défaillances permettent de distinguer les défaillances bénignes (les conséquences sont du même ordre de grandeur que le bénéfice procuré par le service délivré en l’absence de défaillance) des défaillances catastrophiques (les conséquences sont incommensurablement différentes du bénéfice procuré par le service délivré en l’absence de défaillance). 1.2.1.3 Moyens Quatre grandes catégories sont utilisées comme moyens pour satisfaire les attributs de la sûreté de fonctionnement : • La prévention des fautes permet d’empêcher l’occurrence ou de l’introduction d’une faute. • La tolérance aux fautes permet de fournir un service qui remplit la fonction du système en dépit de fautes. • L’élimination des fautes permet de réduire le nombre et la sévérité des fautes. • La prévision des fautes permet d’estimer la présence, la création et les consé- quences des fautes. La volonté d’empêcher l’occurrence de fautes paraît évidente pour des développeurs et notamment pour le développement de logiciels et la conception de matériels sûrs. Plusieurs techniques peuvent être utilisées : méthodes formelles, utilisation de langages fortement typés, règles de conception rigoureuses, etc. Un système tolérant aux fautes doit pouvoir remplir ses fonctions en dépit de fautes pouvant affecter ses composants, sa conception ou ses interactions avec des hommes ou d’autres systèmes. Pour mettre en œuvre la tolérance aux fautes, des techniques de traitement d’erreurs et de traitement de fautes sont utilisées. Parmi les différentes techniques de traitement d’erreurs, on peut citer la compensation, la reprise (rollback) ou la poursuite d’erreurs (rollforward). Parmi les différentes techniques de traitement de 14fautes, on peut citer le diagnostic, l’isolation, la reconfiguration ou la réinitialisation. L’élimination des fautes peut être faite pendant la phase de développement ou pendant la phase d’exécution. Pendant la phase de développement, l’élimination des fautes est réalisée en trois étapes : la vérification, le diagnostic et la correction. La vérifi- cation permet de vérifier que le système est exempt de fautes. Si une faute est détectée, le système de diagnostic a pour objectif d’en connaître la raison puis le système de correction permet de corriger cette faute. Pendant l’exécution, l’élimination des fautes consiste en de la maintenance corrective (après avoir détecté une faute) ou préventive (avant d’avoir détecté une faute). La prévision des fautes est conduite en réalisant une évaluation du comportement du système en prenant en compte les occurrences et les activations de fautes. L’évaluation peut être qualitative (pour identifier, classifier et ranger les modes de défaillances) ou quantitative (pour évaluer en terme de probabilités l’étendue pour laquelle des attributs sont satisfaits). 1.2.2 Tolérance aux fautes dans le domaine avionique Les systèmes avioniques tels que décrits dans la section 1.1 sont dotés de mécanismes de tolérance aux fautes pour réduire au minimum les risques de défaillances qui pourraient causer de nombreux dégâts pouvant aller jusqu’à des pertes humaines. Nous détaillerons ici deux mécanismes importants (mais d’autres existent) de tolérance aux fautes utilisés dans des avions : la redondance et la diversification fonctionnelle (les deux mécanismes utilisent le vote majoritaire pour prendre des décisions). 1.2.2.1 Utilisation de la redondance La redondance est souvent utilisée comme mécanisme principal de la tolérance aux fautes pour améliorer la fiabilité en utilisant des ressources alternatives. La redondance peut être logicielle, matérielle ou temporelle. Nous allons détailler trois types de redondance : statique, dynamique et hybride. La redondance statique utilise le masquage de fautes en réalisant un vote majoritaire entre les différentes répliques. Ainsi, si la majorité des répliques fonctionne correctement, une faute dans une minorité des répliques n’affectera pas le fonctionnement du système global. Cela suppose que les défaillances sont statistiquement indépendantes. La redondance dynamique utilise la reconfiguration du système (action de modifier la structure d’un système qui a défailli, de telle sorte que les composants nondéfaillants permettent de délivrer un service acceptable, bien que dégradé [L+96]). C’est la majorité des répliques qui décident de désactiver ou non une réplique défaillante. Mais avant, le système doit déterminer si la défaillance est permanente ou temporaire. Ensuite, il établit quelles fonctions sont nécessaires pour poursuivre l’exécution du programme, il détermine si une évaluation des dommages est nécessaire et si une isolation de fautes ou une reconfiguration sont nécessaires. La redondance hybride est la combinaison de la redondance statique et la redondance dynamique. C’est-à-dire que le masquage de fautes est appliqué en plus d’une 15reconfiguration du système. 1.2.2.2 Diversification fonctionnelle La diversification fonctionnelle est une technique qui utilise des variantes (les variantes correspondent à des répliques) et un décideur. C’est le décideur qui va commander l’ordre de désactiver ou non une variante. Cette technique est destinée à tolérer des fautes de conception logicielles. Il existe trois approches pour la diversification fonctionnelle : les blocs de recouvrement, la programmation en N-versions et la programmation N-autotestable [L+96]. Avec les blocs de recouvrement [Ran75], le décideur teste les variantes de façon séquentielle. La variante primaire est exécutée en premier lieu. Si une défaillance est constatée, une autre variante (secondaire) est exécutée à la place de la primaire. Il est alors nécessaire de restaurer l’état de la première exécution pour l’exécution de la variante secondaire. Une défaillance peut être provoquée par une faute logicielle telle que : division par zéro, excès de limite de temps, buffer overflow, etc. Avec la programmation en N-versions [Avi85], les variantes (ici appelées versions) et le décideur effectuent un vote majoritaire sur les résultats de toutes les versions. Par exemple, ce type de diversification fonctionnelle a été implémenté par Boeing pour le 777 en utilisant trois versions conçues par trois constructeurs différents (Intel, Motorola et AMD) ou en 4 versions pour les A330/A340 de Airbus. Pour Airbus, cette technique est utilisée depuis les premiers A300 (années 1970) avec des exécutions parallèles de deux variantes qui s’arrêtent quand une comparaison des résultats indique une différence [LABK90]. La programmation N-autotestable [LABK90] utilise des variantes en parallèle avec des mécanismes de détection d’erreurs. Un composant autotestable est un composant qui contient un mécanisme capable de contrôler si les propriétés entre ses entrées et ses sorties sont vérifiées. Si cela n’est pas le cas, un signal d’erreur est alors délivré au composant pour qu’il soit capable de se suspendre de lui-même et pour qu’une autre variante puisse continuer l’exécution. Après avoir présenté les différents mécanismes de tolérance aux fautes, nous donnons dans la suite de ce chapitre, un aperçu les différentes normes utilisées dans les logiciels et matériels critiques. 1.2.3 Développement de logiciels critiques sûrs Le développement logiciel des applications avioniques est réalisé en respectant un ensemble de normes et recommandations qui permettent de développer des systèmes critiques (logiciels et matériels) et de fournir des moyens de certifications. Le processus d’évaluation de la sécurité d’un système avionique a pour but de vérifier la conformité de la conception avec les exigences de navigabilité spécifiées par les autorités. Ces autorités sont l’EASA (European Aviation Safety Agency) pour l’Europe et la FAA (Federal Aviation Administration) pour les Etats-Unis. Les organismes suivants sont responsables de la rédaction des recommandations et normes : SAE (Society of Automotive Engineers), 16RTCA (Radio Technical Commission for Aeronautics) pour les Etats-Unis et EUROCAE (European Organisation for Civil Aviation Equipment) pour l’Europe. La SAE8 fournit les documents de type ARP (Aerospace Recommended Practice) ; la RTCA Inc.9 fournit les documents de type DO et l’EUROCAE10 fournit les documents de type ED. Nous pouvons également citer l’ARINC11 (Aeronautical Radio INCorporated qui est une entreprise créée en 1929 par plusieurs compagnies aériennes et constructeurs aéronautiques américains et rachetée en août 2013 par Rockwell Collins. Elle définit de nombreuses recommandations pour huit types d’industries : l’aviation, les aéroports, la défense, le gouvernement, les services de santé, les réseaux, la sécurité ainsi que les transports. L’ARINC a notamment conçu dès 1978, le système ACARS (Aircraft Communications Addressing and Reporting System) qui permet d’effectuer encore aujourd’hui des communications entre les stations au sol et les avions en utilisant la radio (communication VHF12 ou HF13) ou le satellite. Les organismes européens et américains travaillent en collaboration pour réaliser des documents équivalents, c’est pour cette raison que les noms des recommandations contiennent deux références différentes (DO et ED). Ces recommandations ARP, DO et ED sont devenues des normes avioniques au fil des années. Quatre principales normes sont utilisées pour le développement logiciel critique. L’ARP 4754A/ED-79 (Guidelines for Development of Civil Aircraft and Systems) décrit un processus de développement des systèmes avioniques et inclut des études pour permettre leur certification. L’ARP 4761/ED-135 (Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment), quant à elle, décrit un ensemble de méthodes d’analyse et d’évaluation de la sécurité-innocuité des systèmes avioniques à des fins de certification. Ces deux normes sont en général utilisée conjointement. Le DO-178B/ED-12C (Software Considerations in Airborne Systems and Equipment Certification) définit les contraintes de développement liées à l’obtention de la certification de logiciel avionique et le DO-254/ED-80 (Design Assurance Guidance for Airborne Electronic Hardware) est son pendant pour le développement d’équipement matériel électronique. La figure 1.5 présente les liens entre ces différentes normes et recommandations. 1.2.3.1 Guide de développement pour l’aviation civile – ARP 4754A La recommandation ARP 4754A (datant de décembre 2010) définit les processus de développement des avions civils et des systèmes critiques. Elle intègre notamment : la détermination et validation des exigences, le processus de certification, la gestion de la configuration, et la vérification de l’implémentation. Elle est utilisée conjointement avec l’ARP 4761 “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment” qui définit les méthodes d’évaluation de la 8 http://www.sae.org 9 http://www.rtca.org 10http://www.eurocae.org 11http://www.arinc.com 12Very High Frequency. 13High Frequency. 17Cycle de vie du développement matériel (DO-254 / ED-80) Cycle de vie du développement logiciel (DO-178B / ED-12B) Conception du système Fonctions & exigences Implémentation Processus de développement du système Processus du cycle de vie matériel Processus du cycle de vie logiciel Fonction avionique prévue Fonction, défaillance & information de sûreté Fig. 1.5 – Guide de conception et techniques de certification (ARP 4754A, [arp10]) sécurité-innocuité des systèmes critiques et permet d’assigner les niveaux d’assurance de conception. La recommandation ARP 4754A permet de valider que les exigences sont correctes et complètes avec des méthodes de haut niveau sans faire de différences entre le logiciel et le matériel (qui est faite par ailleurs dans les recommandations DO-178C pour le logiciel et DO-254 pour le matériel). 1.2.3.2 Méthodes d’évaluation de la sûreté pour l’aviation civile – ARP 4761 Cette recommandation ARP 4761 définit plusieurs méthodes et techniques d’analyse de sûreté de fonctionnement sur le système, dont : Functional Hazard Analysis (FHA), Preliminary System Safety Analysis (PSSA), System Safety Analysis (SSA), Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA). Les systèmes avioniques peuvent avoir des niveaux de criticité différents suivant leurs applications et donc leurs 18développements imposent plus ou moins de vérifications/recommandations. L’analyse de risques fonctionnels (FHA) permet d’identifier les défaillances potentielles du système et les conséquences de ces défaillances en attribuant un niveau de DAL (Design Assurance Level) auquel est associé une probabilité par heure qu’une défaillance ne survienne. Les cinq niveaux de DAL sont les suivants : • Niveau A : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème catastrophique, la sécurité du vol ou de l’atterrissage est compromis et le crash de l’avion possible. • Niveau B : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème majeur entraînant des dégâts sérieux voire la mort de quelques occupants. • Niveau C : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème sérieux entraînant par exemple une réduction significative des marges de sécurité ou des capacités fonctionnelles de l’avion. • Niveau D : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème ayant des conséquences mineures sur la sécurité du vol. • Niveau E : Un dysfonctionnement du système ou sous-système étudié peut provoquer un problème sans effet sur la sécurité du vol. Pour le niveau DAL A (niveau catastrophique), il est considéré comme atteint si la probabilité d’activation est inférieur à 1× 10−9 par heure, alors que pour le niveau DAL D (niveau mineur), le seuil maximum est de 1 × 10−3 par heure, et pour le niveau E, aucun seuil n’est imposé. L’analyse PSSA quant à elle, examine les conditions de défaillance de la FHA et décrit comment la conception du système devra respecter les engagements définis. Plusieurs techniques peuvent être utilisées pour le PSSA comme des arbres des fautes (FTA), des chaînes de Markov, etc. 1.2.3.3 Conception et certification de logiciels – RTCA DO-178C La norme DO-178C qui est disponible depuis janvier 2012 est une mise à jour du DO-178B (qui datait de 1992). Elle décrit les objectifs pour les processus de cycle de vie des logiciels, les activités et les études de conception pour accomplir les objectifs et prouver que les objectifs ont été satisfaits. C’est en fait un modèle pour développer des logiciels de haute fiabilité. Il est donc important d’utiliser ces méthodes pour obtenir du code de confiance. Le nombre d’objectifs à atteindre dépend du DAL (voir 1.2.3.2) défini pour le logiciel analysé. Parmi les modifications apportées dans la version C, il y a notamment la volonté d’implémenter des approches qui peuvent changer avec la technologie, ce qui permet d’être compatible avec la modularité de l’architecture IMA. De même, quatre suppléments à ce standard ont été ajoutés : le DO-330 intitulé “Software Tool Qualification Considerations” pour la qualification d’outils avioniques, le DO-331 intitulé “Model-Based Development and Verification Supplement to DO-178C and DO- 278” pour utiliser le développement basé sur les modèles [SPHP02], le DO-332 intitulé “Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO- 19278A” pour les conseils sur les technologies orientées objets, le DO-333 intitulé “Formal Methods Supplement to DO-178C and DO-278A” pour utiliser les méthodes formelles si nécessaire. 1.2.3.4 Conception et développement matériel – RTCA DO-254 Ce standard, qui date d’avril 2000, permet de concevoir et développer des équipements matériels complexes fiables pour des systèmes avioniques. Il est composé de plusieurs sections : cycle de vie de la conception matérielle, processus de planification, validation et vérification, gestion de la configuration, certification, etc. Les objectifs de ce standard sont identiques à ceux vus précédemment dans DO-178C, la seule différence étant qu’ici, il cible le matériel et non le logiciel. 1.2.4 Sécurité-immunité dans les standards avioniques Les standards précédents décrivent les développements de systèmes critiques sûrs, pour empêcher que des fautes physiques et non des fautes d’interaction (voir sous-section 1.2.1.2) causent de graves conséquences. Ces standards sont donc plutôt orientés sécurité- innocuité. Cependant, il est intéressant de se pencher également sur la sécurité-immunité pour contrer d’éventuelles attaques informatiques car comme nous l’avons montré en dé- but de ce chapitre, le nombre d’attaques informatiques augmente. Les pirates informatiques ont notamment aujourd’hui une plus grande surface d’attaques avec les systèmes avioniques plus récents car ils offrent plus de connectivité (plus d’interactions entre les systèmes et ressources) et ils utilisent moins d’équipements spécifiques et davantage de COTS (donc potentiellement moins protégés). Dans cette sous-section, nous nous inté- ressons à la sécurité-immunité et aux standards qui abordent ce sujet. Des recommandations ont été rédigées par la FAA (§129.25 Airplane Security, §128.28 Flight Deck Security et §25.795 Security Considerations) mais elles n’adressent spécifi- quement ni la sécurité des réseaux ni la sécurité des données. Nous détaillons ici trois standards, dont deux concernent plus particulièrement le domaine avionique (ARINC 811 et RTCA DO-326), qui abordent la sécurité au sens de sécurité-immunité (pour faire face aux malveillances). On peut noter qu’il existe également des travaux qui s’intéressent aux interactions entre sécurité-innocuité et sécurité-immunité en proposant par exemple des approches développées harmonisées. On peut citer par exemple [DKCG99, B+12a, B+12b]. 1.2.4.1 Common Criteria for Information Technology Security Evaluation – ISO/IEC 15408 Les critères communs correspondent à une norme internationale ISO/IEC 15408 qui permet de certifier des systèmes de sécurité. Cette norme n’est pas spécifique aux systèmes avioniques mais elle peut être appliquée à certains systèmes avioniques si besoin. Elle permet notamment d’assigner un niveau de certification Evaluation Assurance Level (EAL) entre 1 et 7 (du moins exigeant au plus exigeant en terme de conception, tests et 20vérifications). Les produits certifiés ne garantissent pas l’absence de vulnérabilités mais seulement que des objectifs de tests et de vérifications ont été atteints. Par exemple, les produits tels que Microsoft Windows Server 2003 et Windows XP ont été certifiés en 2005 et sont évalués EAL4+, alors que nombreuses vulnérabilités ont été détectées depuis cette date : 629 vulnérabilités pour Windows XP et 532 vulnérabilités pour Windows Server 2003 [You]. 1.2.4.2 Sécurité des systèmes d’information des systèmes commerciaux – ARINC 811 Le document ARINC 811 a été publié en 2005 par l’ARINC pour faciliter la compréhension de la sécurité de l’information et pour développer des concepts de sécurité opérationnelle des avions [ari05]. Même s’il a pour but de protéger les informations sensibles, ce document n’est pas directement utile pour se protéger contre une attaque informatique, ou pour éviter l’exploitation de vulnérabilités présentes dans des applications (critiques ou non). Il définit le cycle de vie de la configuration de l’avion, les modes des systèmes (opérationnel normal, opérationnel non-normal et maintenance), les rôles de sécurité (Ground Security Administrator, Ground User, Onboard Cockpit User, Maintenance User, etc.) qui permettent de définir des groupes de personnes auprès des compagnies aériennes, les objectifs de sécurité de l’information, etc. La figure 1.6 présente les différents domaines de réseaux dans un avion. • Le domaine de commande de l’appareil (Aircraft Control Domain) est le domaine le plus critique dans le monde avionique. Il contient les applications de contrôle et de commande de l’appareil. Ces applications sont généralement installées sur des calculateurs qui récupèrent les commandes du pilote, les transforment (en fonction des lois de pilotage et des données environnementales, par exemple) en données numériques, et les communiquent (via un réseau dédié) aux différents actionneurs de l’appareil. • Le domaine de services d’information de la compagnie (Airline Information Services Domain) contient les différents supports relatifs au vol, la cabine, la maintenance). Ce domaine est moins critique que le précédent, mais il reste tout de même d’un niveau de criticité élevé. En effet, les informations contenues dans ce domaine sont critiques pour l’exploitation de l’appareil (surtout par rapport à la maintenance) par les compagnies aériennes. • Le domaine de services d’information et de divertissement des passagers (Passenger Information and Entertainment Services Domain) est en charge de la communication avec les passagers. Il comprend la gestion des écrans de divertissement (In Flight Entertainment : IFE) ainsi que l’interface de connexion des périphériques du passager. Ce domaine est fortement lié à l’image de marque de la compagnie aérienne auprès des passagers. Aussi, les compagnies accordent une grande importance aux équipements de divertissement des passagers, certaines allant même jusqu’à refuser l’autorisation de décollage d’un appareil si un terminal de divertissement (IFE) est défaillant. • Le domaine des équipements des passagers (Passenger-owned Devices) est réservé 21à tous les équipements électroniques des passagers (ordinateurs portables, smartphone, consoles de jeu). Dans certains avions récents, ces équipements sont connectables, via des interfaces spécifiques (présentes dans le domaine précédent), à un réseau que la compagnie aérienne peut configurer en fonction de sa stratégie commerciale (par exemple proposer une connexion Internet aux passagers). Fig. 1.6 – Les domaines de réseaux dans un avion (ARINC 811). 221.2.4.3 Processus de sécurité de la navigabilité – RTCA DO-326 La recommandation RTCA DO-326 intitulée “Airworthiness Security Process Speci- fication” publiée en décembre 2010 [do310] permet d’améliorer la sécurité (au sens de sécurité-immunité) à bord. Ce standard a pour objectif de sécuriser les quatre éléments suivants : • les connexions externes aux fournisseurs de services non-gouvernementaux (services de l’équipage de vol, services de maintenance) ; • les nouveaux services de divertissement (isolation entre les systèmes de contrôle de l’avion, partage de ressources) ; • les interfaces pour les média portables (incluant les ordinateurs portables) ; • l’insertion des équipements externes. Deux autres documents sont en cours de préparation pour compléter cette recommandation DO-326 : DO-YY3/ED-203 (Security Methods and Considerations) et DOYY4/ED-204 (Security Guidance for continuing airworthiness). Le document ED-203 permet d’assurer par des méthodes et des recommandations, que les évaluations de risques de sécurité sont rigoureux, équilibrés et justes. Il permettra également de s’assurer par des pratiques d’assurance de développement que les contre-mesures sur l’avion sont implémentées correctement. Le document ED-204 permet de s’assurer que les contremesures sont fonctionnelles et qu’elles sont maintenues correctement. Une mise à jour de cette recommandation sera publiée courant 2014 (sous le nom de DO-326A) pour améliorer celle existante. La DO-326 était à l’origine conçue pour être un supplément de l’ARP 4754 orienté sécurité, mais la publication de ARP 4754A en 2010 impliquait trop de changements pour être seulement un supplément, donc un nouveau document est nécessaire. Ce standard DO-326 est actuellement en cours de révision pour être plus en phase avec les évolutions actuelles. Malgré une volonté évidente de sécuriser les infrastructures avioniques, il est possible que des vulnérabilités subsistent et puissent être exploitées si des mécanismes de sécurité supplémentaires ne sont pas utilisés. Nous évoquons ce point dans la section suivante. 1.3 Problématique de la sécurité-immunité dans les systèmes avioniques Comme nous l’avons vu précédemment (voir sous-section 1.1.2), les systèmes IMA permettent d’offrir une connectivité accrue, un partage des ressources entre les applications (potentiellement de criticité différente) d’un même calculateur, et favorisent l’utilisation de COTS. Ces évolutions sont des atouts (réduction des coûts de développement, des coûts de maintenance, du poids) mais du point de vue de la sécurité, la surface d’attaque pour un programme malveillant en est décuplée. En effet, si par exemple, le partage de ressources n’est pas suffisamment protégé, une partition malveillante peut lire des données d’une autre partition voire même les modifier et ainsi potentiellement provoquer de graves conséquences. Nous présentons dans les sous-sections suivantes les problèmes de sécurité liées à chacune de ces évolutions. 231.3.1 Connectivité accrue entre les applications La connectivité à bord d’un avion peut prendre diverses formes. Elle concerne à la fois les communications entre différentes applications distantes, à travers un support de communication, qu’il soit filaire (ARINC 429, AFDX) ou non (VHF, satellite et Wifi). Elle concerne également les communications entre applications d’un même calculateur (partitions sur un même module). Par exemple, l’utilisation d’iPADs a été autorisée par la FAA depuis 2011 [DO11]. Ces iPADs peuvent être utilisés comme des EFB (Electronic Flight Bag) portables. A terme, la documentation avion papier anciennement nécessaire (représentant une masse de 15 kg environ) pourra donc être supprimée. Un autre exemple est l’utilisation d’appareils électroniques en fonctionnement pendant le décollage et l’atterrissage des avions, qui est possible depuis 2014 [lem13]. Cette évolution peut comporter des risques si la sécurité n’est pas maîtrisée. La figure 1.7 représente les domaines de réseaux présents dans un avion décrits dans le standard ARINC 811. Fig. 1.7 – Les domaines de réseaux dans un avion (extrait de [ari05]). Cette norme propose de décomposer les communications et équipements en trois catégories : publique, privée et fermée. La catégorie publique correspond aux appareils des passagers, comme les téléphones, ordinateurs portables, tablettes, etc. La catégorie privée correspond aux équipements de la compagnie aérienne comme les calculateurs fournissant l’accès à Internet, au Wifi, les systèmes de divertissement (IFE14). La caté- 14In-Flight Entertainment. 24gorie fermée correspond au domaine où les informations sensibles circulent et ne doivent pas être accessibles par un tiers. Cela concerne notamment la communication par satellite (SATCOM) et par radio (VHF). Des règles précises de filtrage des communications entre chaque catégorie doivent être définies. Les équipements des passagers étant totalement imprévisibles, il faut être capable de limiter leurs accès pour éviter les risques de perturbations. A l’heure actuelle, nous savons déjà qu’il est possible de perturber avec des ondes électromagnétiques de l’avion [Bro13]. Une étude de la IATA (International Air Transport Association) réalisée entre 2003 et 2009 sur 125 opérateurs a révélé que 75 cas de perturbations ont été détectés dont : des problèmes de communication, problèmes dans les contrôles de vol, des affichages défaillants, etc. La maîtrise des communications entre différentes applications sur un système avionique est donc fondamentale du point de vue de la sécurité. 1.3.2 Partage de ressource entre applications de différents niveaux de criticité Un autre avantage de l’architecture IMA est le partage facilité de ressources entre applications avec différents niveaux de criticité. Ce principe réduit les coûts de matériels mais la proximité physique des informations entre les applications entraîne un risque de compromission élevé. Pour cette raison, le partitionnement est utilisé. Il permet de restreindre les accès mémoire puisque chaque partition utilise une zone de la mémoire définie statiquement pendant la configuration. La figure 1.8 illustre un exemple simple de partage d’informations entre applications. Application 1 Application 2 Noyau temps-réel Fig. 1.8 – Partage simple entre 2 applications d’un module. Dans la figure 1.8, nous avons deux applications sur le même module qui communiquent entre elles, le partitionnement permettant de contrôler les accès aux informations. Ce partage sur un système temps-réel doit être opéré de façon à ce que les données soient accédées de façon périodique ou apériodique mais elles ne doivent jamais être accessibles à deux applications en même temps pour éviter des accès concurrents à la même ressource. Il est donc nécessaire de s’assurer que ce mécanisme de partitionnement soit effi- cace de manière à empêcher une application disposant d’un niveau de criticité faible de perturber le comportement d’une application de niveau de criticité élevé. 251.3.3 Utilisation de composants COTS Aujourd’hui, l’utilisation de composants COTS (Commercial-Off-The-Shelf) repré- sente plus de 95% de tous les composants de l’avion [Ska13] et ces composants n’ont pas forcément les mêmes exigences de conception et de développement que les composants avioniques spécifiques. Les fournisseurs de logiciels et matériels COTS sont susceptibles à tout moment de faire des modifications dans leurs logiciels et composants sans pour autant qu’elles soient validées à nouveau pour être embarquées dans l’avion. L’adoption d’une mise à jour d’un COTS pour utilisation dans un avion nécessite donc systématiquement un processus de validation complet. Les composants COTS sont cependant acceptés à bord car d’une part, ils sont conçus par des fournisseurs choisis et approuvés par les constructeurs d’avions, et d’autre part, parce que ces composants ont été évalués et acceptés vis-à-vis d’un cahier des charges précis. Ces démarches réduisent considérablement a priori le risque que ces composants soient intentionnellement corrompus. Cependant, les composants de faible criticité sont évalués à un niveau inférieur à celui des composants de forte criticité ; il est donc toujours possible que des vulnérabilités subsistent. 1.3.4 Conclusion Les évolutions de l’architecture des systèmes avioniques que nous venons de présenter (connectivité, partage des ressources et utilisation des COTS), augmentent la surface d’attaques possible et par conséquent, le risque potentiel de malveillance. Améliorer la sécurité des systèmes embarqués dans les avions est donc un problème important pour l’industrie aéronautique et il est fondamental aujourd’hui d’adapter les mécanismes de protection à l’évolution des architectures de leurs systèmes d’information. Des cyber-attaques contre ces systèmes ont déjà été réalisées. En octobre 2011, des virus ont été détectés dans une flotte de drones américains Predator et Reaper [Mun11]. En avril 2013, des compagnies aériennes et constructeurs d’avion se sont intéressés de près à Hugo Teso, après des révélations sur la faible sécurité des communications dans les protocoles avioniques ADS-B15 à ACARS16. Lors d’une démonstration sur un logiciel d’entraînement non avionable, il a voulu montrer qu’il était possible d’obtenir un accès au Flight Management System (FMS) [Tes13]. Même si sa démonstration n’était pas concluante, le fait qu’il l’ait présenté publiquement a été pris très au sérieux par l’ensemble de la communauté aéronautique, autorités et constructeurs. Nous allons maintenant décrire dans la prochaine section les différentes approches existantes pour protéger les systèmes avioniques efficacement face à des malveillances. 1.4 Différentes approches pour améliorer la sécurité-immunité Pour assurer la sécurité-immunité des systèmes avioniques, il est nécessaire d’appliquer ou d’adapter des méthodes et techniques qui ont prouvé leur efficacité pour la 15Automatic Dependent Surveillance-Broadcast. 16Aircraft Communication Addressing and Reporting System. 26protection de systèmes informatiques “classiques” : • les outils et mécanismes de sécurité (pare-feux, contrôle d’accès, système de détection d’intrusion, etc.) ; • les méthodes formelles pour la spécification, le développement, la vérification et la certification ; • l’analyse de vulnérabilités avec les contre-mesures associées, appliquées au plus tôt dans le cycle de développement. Nous allons présenter maintenant ces trois approches dans les prochaines sous-sections. 1.4.1 Intégration de mécanismes de sécurité adaptés Assurer la sécurité-immunité des systèmes peut en partie être réalisé en utilisant des outils et mécanismes de sécurité classiques. Plusieurs types d’outils existent : les firewalls, le contrôle d’accès, les systèmes de détection d’intrusion (Intrusion Detection System ou IDS), l’authentification, le chiffrement, etc. Ces outils ont montré leur efficacité pour la protection face aux attaquants sur les systèmes classiques. En revanche, ils doivent être adaptés pour satisfaire les contraintes des systèmes avioniques. Les deux contraintes principales sont le respect des délais d’exécution et le partitionnement spatial et temporel des partitions. A titre d’exemple, dans un système classique, un IDS peut être déployé sur une machine de manière à observer à la fois les communications concernant les applications de la machine et les communications entre deux autres machines. Un IDS peut ainsi se baser sur ces observations pour remonter des alertes correspondant à l’identification d’une tentative d’attaque. Il doit donc pouvoir avoir accès à l’ensemble des communications. Par contre, sur un système avionique, une application peut observer uniquement les communications la concernant. Ce dispositif serait donc dans l’incapacité de détecter des tentatives d’intrusion concernant les autres applications. Donc, les IDS employés dans les réseaux d’entreprises ne peuvent pas être déployés en l’état sur les systèmes embarqués. Il est relativement simple de mettre en place les mécanismes de chiffrement dans les systèmes avioniques. Par contre, un inconvénient majeur pour ces mécanismes concerne le temps de chiffrement qui peut être relativement long (surtout pour des calculs concernant certains chiffres assymétriques tels que le RSA). De la même manière, pour les mécanismes de contrôles d’accès et d’authentification, des vérifications doivent être réalisées à chaque accès aux ressources, ce qui peut s’avérer également particulièrement coûteux. 1.4.2 Utilisation de méthodes formelles Les méthodes formelles sont utilisées par les avionneurs pour vérifier le fonctionnement des applications et des systèmes [S+09b]. Par exemple, Airbus utilise ces méthodes depuis 2001 pour l’A380. La norme RTCA DO 178C propose notamment une annexe concernant l’utilisation de ces méthodes. 27Les méthodes formelles fournissent une structure mathématique avec laquelle il est possible de s’assurer que le modèle d’un système satisfait bien un cahier des charges formel. Mais les méthodes formelles ont aussi des limitations [LA95], les spécifications formelles peuvent ne pas être efficaces car il n’y a pas de principe général sur la façon d’acquérir les exigences de l’utilisateur et comment les enregistrer en utilisant un langage formel de spécification. Le raffinement qui consiste à passer de l’abstraction d’une spécification à l’implémentation est une opération sensible qui peut engendrer de nouveaux problèmes si cette opération est mal réalisée. Les preuves formelles sont elles aussi sujettes à des problèmes suivant le raffinement qui est réalisé. De la même façon, la spéci- fication peut ne pas être suffisamment détaillée pour le développeur ou alors les exigences de l’utilisateur peuvent être mal comprises par le concepteur/développeur. D’autres problèmes potentiels plus spécifiques aux systèmes sécurisés sont cités dans [JH08] : spé- cifications invalides ou partielles, définitions de propriétés trop vagues, implémentation trop “libre” pour le développeur qui amène à des interprétations personnelles. Nous pouvons ajouter à cela que les méthodes formelles doivent se baser sur des hypothèses sur l’environnement d’exécution, soit parce que l’environnement d’exécution n’est pas encore disponible, soit parce que sa complexité nécessite de le modéliser de manière plus simple. La figure 1.9 illustre ce problème. Fig. 1.9 – Visualisation des hypothèses de bas niveau. La partie gauche de la figure représente les étapes nécessaires pour une conception ascendante et une vérification de l’application (“Conception top-down”) et la partie droite représente l’exécution de ce même système. Pendant la vérification de la conception, 28certaines hypothèses doivent être faites sur l’environnement dans lequel il sera exécuté. C’est à ce niveau que des problèmes peuvent subsister car ces hypothèses peuvent ne pas correspondre ou être légèrement différentes de la réalité dû à des changements nonprévus après la conception, des reconfigurations, etc. Ceci est en particulier vrai pour le matériel dont il est très difficile à priori de connaître parfaitement le fonctionnement. Si certaines hypothèses de bas niveau sont effectivement vérifiées, il est possible que d’autres ne le soient pas, ce qui peut conduire à la présence de vulnérabilités. 1.4.3 Analyse de vulnérabilités dans le processus de développement La troisième approche consiste à analyser un composant (matériel, noyau temps-réel et applications) en vue de détecter la présence de vulnérabilités. Une vulnérabilité est une faute qui peut être exploitée pour corrompre une partie ou la totalité du système. Il est donc important de détecter ces vulnérabilités pour éviter des conséquences graves sur la sécurité du système. Les analyses de vulnérabilités permettent de détecter les vulnérabilités mais elles sont généralement réalisées lorsque les systèmes sont en production pour étudier s’ils sont vulnérables à des attaques informatiques. L’inconvénient de cette démarche est que, lors de l’identification d’une vulnérabilité, la contre-mesure se limitera à une “rustine” locale appliquée au système. Cette contre-mesure ne pourra donc pas être intégrée directement dans l’architecture de ce système. Or, il est également possible et intéressant de réaliser une analyse de vulnérabilités au plus tôt dans le développement du noyau et des applications pour les détecter avant que le système soit en production. Ces analyses de vulnérabilités peuvent également être intéressantes pour identifier l’architecture logicielle la plus adaptée pour éviter l’introduction des vulnérabilités. Nous avons décidé de développer cette approche pour la suite car c’est une approche innovante pour les systèmes critiques et elle peut donner de bons résultats. L’analyse de vulnérabilités réalisée tôt dans le processus de développement permettra de corriger ces vulnérabilités pour améliorer la protection globale du système embarqué. Dans la prochaine section, nous détaillons l’analyse de vulnérabilités dans les systèmes critiques embarqués. 1.5 Analyse de vulnérabilités dans les systèmes critiques embarqués Nous nous intéressons dans cette section à l’analyse de vulnérabilités sur des systèmes classiques, pouvant être adaptée à des systèmes temps-réel. Pour les systèmes non tempsréel, les analyses de vulnérabilités sont souvent utilisées pour détecter si des maliciels sont présents, si des données peuvent être volées ou si le système peut être corrompu. Une fois détectée, il est nécessaire de trouver des moyens pour se protéger efficacement et ainsi éviter que cette vulnérabilité ne soit exploitée. Les analyses de vulnérabilités peuvent être réalisées de manière automatique ou de manière manuelle. Elles peuvent être également réalisées par des approches boîte noire ou par des approches boîte blanche. 29Une analyse de vulnérabilités manuelle a l’avantage d’être plus approfondie mais cette analyse requiert en général des compétences très spécifiques que seul un expert humain est capable de mettre en pratique. De plus, le temps nécessaire pour faire cette analyse est long car il est très difficile de prendre en compte toutes les subtilités d’un système, étant donné sa complexité. Une analyse automatique permet en revanche une analyse plus rapide mais plus superficielle car les outils ne font pas de recherche approfondie contrairement à l’analyse manuelle. En effet, il est très difficile de développer des outils d’analyse automatique en leur permettant de traiter un large éventail de vulnérabilités. Cette difficulté est en partie due à la complexité des cibles des analyses. De nombreux travaux ont été réalisés pour évaluer la présence de vulnérabilités dans des systèmes, par différents moyens [IW08]. Les approches boîte blanche et les approches boîte noire se distinguent par les conditions dans lesquelles ces analyses sont réalisées. L’approche par boîte blanche consiste à avoir accès à toutes les informations du système allant du code source à la documentation et permet ainsi de comprendre exactement comment il fonctionne. L’approche par boîte noire consiste à ne pas avoir ces informations et donc à travailler sans aucune connaissance particulière sur le système. Nous allons décrire ces deux types d’analyses dans les prochaines sous-sections 1.5.1 et 1.5.2 pour en comprendre le fonctionnement. L’approche que nous proposons sera ensuite décrite dans la sous-section 1.6. 1.5.1 Approche par boîte blanche L’approche par boîte blanche consiste à avoir accès à des informations du système (code source, binaire et documentation éventuelle) pour réaliser l’analyse de vulnérabilités. Deux techniques différentes sont possibles pour réaliser cette analyse. L’une “statique” consiste à analyser le code source ou le fichier binaire mais sans exécuter le programme ciblé. L’autre technique est dite “dynamique”, elle consiste à faire l’analyse pendant l’exécution du programme ciblé en observant les flux de données (entrées et sorties) soit en instrumentant le code (i.e. modifier le code avec des informations de debug) soit en le laissant tel quel. Cependant, si le programme a été modifié pour réaliser l’instrumentation, il se peut que son comportement soit différent du comportement dans l’environnement réel d’exécution. En général, des outils d’analyse de code sont utilisés pour détecter les vulnérabilités, ils analysent le code source pour détecter les erreurs courantes de débordement de buffers (buffer overflows), débordement d’entiers (integer overflows) ou encore de divisions par zéro. Plusieurs outils d’analyse statique sont utilisés dans l’industrie, nous en présentons 4 : • Caveat [B+02] est un outil de vérification formelle qu’utilise Airbus depuis 2002. Il permet d’analyser des programmes en C et propose deux fonctionnalités : les analyses de flux de contrôle et de données (automatique pour l’outil) et la preuve des propriétés spécifiées par l’utilisateur. 30• Frama-C17 permet d’analyser des programmes C et de s’assurer que le code source est conforme à une spécification formelle définie. Il est possible d’ajouter des plugins pour y ajouter des fonctionnalités. Ces plug-ins peuvent ensuite communiquer entre eux grâce à un langage de spécification commun appelé ACSL. • Astrée18, également utilisé par Airbus, permet de prouver l’absence de Run-Time Error (RTE) [C+07] en utilisant la théorie de l’interprétation abstraite [CC77]. • Ait19 analyse un programme dans sa forme binaire pour calculer une borne supé- rieure du WCET des tâches du programme. Il permet de vérifier que les WCET calculés correspondent à ceux mesurés. Ces outils sont utiles pour vérifier que le code (ou le fichier binaire) fait ce qu’il doit faire sans faute de développement mais des vulnérabilités peuvent encore subsister. Les analyses menées par ces outils peuvent donc être complétées par des analyses dites “approches par boîte noire”. 1.5.2 Approche par boîte noire L’approche par boîte noire consiste à réaliser l’analyse de vulnérabilités sans avoir une connaissance particulière du système. Elle repose généralement sur l’observation des interactions du composant analysé avec son environnement. Les techniques statiques et dynamiques pourraient être appliquées dans ces approches. Cependant, les techniques statiques ne sont pas pertinentes car elles imposent d’avoir accès soit au code source soit au binaire, avant l’exécution et elles ne permettent donc pas d’être dans un contexte d’approche par boîte noire. En revanche, les techniques dynamiques sont pertinentes car, pendant l’exécution, l’analyse de vulnérabilités peut être réalisée en analysant les flux d’entrées et de sorties (par exemple, vérification des limites d’un tableau en mémoire, etc.) sans avoir d’informations particulières sur le programme exécuté. Les différentes étapes nécessaires sont les suivantes : • identifier les composants de l’environnement ; • sélectionner des attaques susceptibles de fonctionner ; • tester les attaques sélectionnées ; • observer le comportement du système. L’identification des composants de l’environnement permet de connaître l’ensemble des composants avec lesquels le composant à analyser peut interagir. Ces interactions sont réalisées par des entrées et des sorties. Souvent, les outils d’analyse dynamique adoptant une approche boîte noire se basent sur ces entrées et sorties pour tester les composants. La seconde étape correspond à un croisement entre les informations collectées dans la première étape avec une base de connaissance sur des classes d’attaques. En général, la connaissance de l’environnement est nécessaire pour tester des situations extrêmes. Ces classes d’attaques sont utilisées pour atteindre ces situations extrêmes. Pour 17http://frama-c.cea.fr/ 18http://www.astree.ens.fr/ 19http://www.absint.com/ait/ 31pouvoir être testées, ces classes d’attaques doivent être instanciées. Une classe d’attaque souvent employée est la génération de données aléatoires (fuzzing). Les attaques obtenues sont ensuite testées sur le composant, dans la troisième étape. Pour finir, le comportement du composant est analysé dans la dernière étape. Si, lors de l’exécution de l’attaque, une défaillance est identifiée (par exemple, le composant ne délivre plus de service), alors l’attaque est considérée comme réussie. Il faut aussi prendre en compte l’impact des mécanismes de tolérance aux fautes du composant sur le déroulement du processus de tests (par exemple un redémarrage du système conduira à l’arrêt du test). Les méthodes d’analyse dynamique ont deux défauts principaux [C+07] : • elles peuvent prouver la présence d’erreurs mais pas leurs absences ; • elles ne peuvent pas vérifier toutes les propriétés d’un programme (présence de code mort ou non terminaison). 1.6 Contribution de cette thèse : une méthodologie d’analyse de vulnérabilités pour des systèmes embarqués avioniques Les sections précédentes décrivent les systèmes avioniques et les techniques de sûreté de fonctionnement utilisées dans ces systèmes pour éviter des conséquences graves sur les systèmes avioniques. Les normes et techniques permettant d’améliorer la sécurité- innocuité et la sécurité-immunité à bord de l’avion sont également présentées dans ces sections. Un focus particulier est réalisé sur l’analyse de vulnérabilités, qui constitue une de ces techniques. Habituellement, les analyses de vulnérabilités sont réalisées à la fin du développement et en phase d’exploitation et, en cas d’identification de vulnérabilités, ce sont des “rustines” qui sont appliquées localement, la plupart du temps sans essayer de repenser l’architecture globale de l’application. Effectivement, le temps restant pour produire le système ne permet pas de revenir sur les phases de conception et de modélisation du système. Réaliser les tests et découvrir des vulnérabilités pendant le développement à partir du moment où l’on dispose d’un premier prototype du système permet une toute autre approche. La découverte de certaines vulnérabilités, jugées critiques, peut amener à une modification de l’architecture globale de l’application, parce qu’il est encore temps de le faire sans que ce soit trop coûteux. On peut ainsi obtenir une architecture construite pour “intrinsèquement” éviter l’introduction des vulnérabilités identifiées, dès les premières phases de son développement. Cette analyse de vulnérabilités et la proposition de contre-mesures adaptées au plus tôt dans le cycle de développement logiciel est au cœur de la contribution de cette thèse. Nous allons pour cela proposer une méthodologie d’analyse de vulnérabilités, basée sur trois grandes étapes : • Dans un premier temps, il est fondamental de classifier l’ensemble des menaces qui peuvent peser sur les systèmes embarqués avioniques. C’est la contribution proposée par le chapitre 2. Dans ce chapitre, nous proposons de définir une classification la plus exhaustive possible des différentes attaques qui peuvent cibler les systèmes 32embarqués avioniques. Bien sûr, certaines attaques sont similaires à des attaques que l’on peut rencontrer sur des systèmes informatiques usuels “du bureau”, mais certaines sont spécifiques aux systèmes avioniques car elles peuvent tirer partie de certaines caractéristiques spécifiques de ces systèmes pour arriver à leur fin. Nous détaillons donc ces deux familles d’attaques dans notre classification. • Une fois cette classification établie, une phase d’expérimentation sur le système cible doit avoir lieu. Ces expérimentations doivent faire en sorte de tester aussi exhaustivement que possible les attaques décrites dans la classification précédente. Bien évidemment, elles doivent être précédées d’une analyse précise du système cible et de son fonctionnement interne de façon à pouvoir parfaitement mener des attaques adaptées à ce système. Cela signifie que l’analyse doit tenir compte à la fois du logiciel mais aussi du matériel sur lequel le système s’exécute. C’est la raison pour laquelle il est fondamental que les expérimentations se déroulent sur une plateforme matérielle identique à la plateforme sur laquelle le système avionique doit réellement s’exécuter en opération. Le chapitre 3 présente un exemple de mise en œuvre de telles expérimentations sur un système avionique expérimental fourni par Airbus France. Ce chapitre commence donc par présenter en détail l’implé- mentation de ce système, ainsi que la plateforme sur laquelle il s’exécute. Ensuite, il présente l’ensemble des attaques qui ont été envisagées sur cette plateforme et décrit en détail celles qui ont été les plus pertinentes en terme de découvertes de vulnérabilités. • Enfin, la dernière phase de notre méthodologie consiste à concevoir et implémenter des contre-mesures efficaces face aux vulnérabilités découvertes. C’est l’objet du chapitre 4. Les contre-mesures proposées dans ce chapitre sont de deux types. Nous y décrivons dans un premier temps les contre-mesures spécifiques aux vulnérabilités découvertes sur le système présenté dans le chapitre 3. Ensuite, nous essayons de généraliser ces contre-mesures, de façon à proposer des recommandations, aussi gé- nériques que possible, à appliquer durant le développement de systèmes embarqués avioniques. 3334Chapitre 2 Caractérisation des attaques des systèmes embarqués Introduction Dans le chapitre précédent, nous avons justifié la nécessité d’améliorer et de réaliser systématiquement des analyses de vulnérabilités dans le processus de développement des systèmes embarqués avioniques de future génération. En effet, l’évolution des systèmes (ouverture, partage, utilisation de COTS) facilitent l’introduction de vulnérabilités et il est donc fondamental d’accompagner leur développement d’une analyse de vulnérabilités approfondie, au plus tôt, pour renforcer leur sécurité. Il est nécessaire d’adopter une démarche rigoureuse pour mener cette analyse de vulnérabilités. Pour cela, une connaissance précise des attaques qui peuvent menacer ces systèmes est requise. C’est la raison pour laquelle ce chapitre propose une classification des différentes attaques qui peuvent cibler des systèmes embarqués critiques avioniques. Cette classification a fait l’objet d’une publication dans [DADN12]. Nous avons établi cette classification en faisant le raisonnement suivant. Un système embarqué critique a de multiples points communs avec un système informatique “classique” utilisé dans le cadre professionnel ou privé. Nous allons donc établir une première classification d’attaques inspirée des classifications connues des attaques sur les fonctionnalités de base des systèmes informatiques classiques, en les adaptant toutefois aux spécificités et aux contraintes du monde avionique. Nous appellerons cette catégorie attaques ciblant les fonctionnalités de base. Cependant, un système avionique embarqué possède des caractéristiques spécifiques très particulières pour des raisons de sûreté de fonctionnement (safety). Il inclut en particulier un ensemble de mécanismes de tolérance aux fautes. Or, ces mécanismes eux-mêmes peuvent être potentiellement la cible d’attaques et leur corruption peut s’avérer particulièrement intéressante pour un attaquant. Nous le montrerons dans la suite de ce chapitre. Nous avons donc défini une seconde catégorie d’attaques appelée attaques ciblant les mécanismes de tolérance aux fautes. Ce chapitre est principalement consacré à la présentation de ces deux catégories d’attaques. A la fin de ce chapitre, nous présentons également le contexte et les hypothèses 35d’attaques que nous avons considérés pour notre étude. 2.1 Attaques visant les fonctionnalités de base Un système avionique embarqué, comme tout système informatique, utilise un processeur, de la mémoire, des périphériques, un système d’exploitation et des applications, et les mécanismes de gestion qui leurs sont associés. Nous avons ainsi classifié les attaques visant les fonctionnalités de base en huit catégories. • le processeur ; • la gestion de la mémoire ; • les communications ; • la gestion du temps ; • la gestion des processus ; • l’ordonnancement ; • la cryptographie ; • les fonctions ancillaires. Les sous-sections suivantes présentent ces différentes catégories. Pour chaque catégorie, nous décrivons rapidement le fonctionnement du composant ciblé ou de la fonctionnalité ciblée et nous donnons le principe général des attaques que nous estimons possibles sur ce composant ou cette fonctionnalité. Nous nous inspirons des attaques connues dans le monde des PCs de bureau et de l’architecture x86, qui sont des architectures bien plus éprouvées par les attaquants que les architectures avioniques, du point de vue de la sé- curité. Nous pouvons ainsi proposer un riche panorama d’attaques possibles, même si aujourd’hui, de telles attaques n’ont encore pas toutes vu le jour sur des architectures de type avionique. L’important, est d’être aussi exhaustif que possible afin de pouvoir anticiper au mieux l’occurrence de nouvelles attaques. 2.1.1 Attaques ciblant le processeur Le processeur est le composant matériel principal d’un calculateur. Il exécute les différentes instructions. De nombreuses caractéristiques et améliorations sont incluses dans les processeurs modernes : multiples cœurs, multiples niveaux de mémoires caches, unité de gestion de la mémoire, unité de prédiction de branchement, interruptions, etc. En particulier, les caches des processeurs sont utilisés pour réduire le temps moyen d’accès mémoire (car la mémoire SRAM (Static Random Access Memory) utilisée est beaucoup plus rapide que la DRAM (Dynamic Random Access Memory). En revanche, la SRAM ne peut contenir que très peu de données. Les systèmes actuels ont généralement trois niveaux de caches (L1, L2 et L3) placés de façon à optimiser les accès mémoire. Le premier niveau de cache (par exemple de 64 Ko) est au plus proche des cœurs du processeur. Il peut être partagé en deux caches, un pour les instructions et un autre pour les données (architecture Harvard) ou non (architecture von Neumann). Le second niveau de cache (par exemple de 128 Ko) est partagé entre les cœurs et est en général unifié (aucune séparation entre instructions et données). Le troisième niveau de cache se 36situe après le cache L2. Il est donc plus lent mais contient plus de données (par exemple 8 Mo). Lorsque ces caches sont utilisés, les données de la mémoire y sont copiées pour être réutilisées plus tard. Des mécanismes de cohérence des caches sont mis en œuvre pour que les caches contiennent les valeurs correctes aux mêmes moments. Des problèmes de sécurité liés à la gestion des caches dans les systèmes temps-réel ont déjà été mis en évidence [ZBR07] et des protections ont été proposées notamment en authentifiant et chiffrant les données [LAEJ11]. Des faiblesses concernant la confidentialité ont aussi été découvertes. Par exemple, des études montrent qu’il est possible de retrouver des clés secrètes cryptographiques en utilisant les caches [Aci07a, OST06, Aci06, Bon06, Aci07b, Per05, Ber05] ou le mécanisme de prédiction de branches BTB [ASK07]. La figure 2.1 illustre la hiérarchie des caches présents dans un système utilisant 4 cœurs. Cœur 1 Cœur 2 Cœur 3 Cœur 4 Cache Instruct. Cache Données Cache Instruct. Cache Données Cache Instruct. Cache Données Cache Instruct. Cache Données Cache unifié Cache Cache DRAM DRAM L1 L2 L3 Fig. 2.1 – Hiérarchie des caches (architecture Harvard). Des attaques peuvent aussi essayer de provoquer un arrêt inopiné du processeur, en le faisant exécuter des instructions non-définies ou non-documentées. Si un code malveillant est capable d’envoyer des instructions non-documentées au processeur, le comportement de ce dernier devient imprévisible. Cela peut provoquer, par exemple, le basculement du processeur dans un mode spécial (tel que un mode de maintenance) dont bénéficie automatiquement le code malveillant qui s’exécute. Il peut ainsi acquérir de nouveaux privilèges associés à ce mode. Une telle attaque peut provoquer un Déni-de-Service20 (DoS). Par exemple, comme décrit dans [SPL95], les processeurs x86 peuvent avoir des comportements imprévisibles : les auteurs ont identifié 102 vulnérabilités potentielles affectant des versions différentes des processeurs 80x86. Il a d’ailleurs été montré que certains processeurs de la famille x86 disposaient d’instructions non documentés, c’est- 20Denial-Of-Service. 37à-dire pour lesquels on ne connaît pas le comportement du processeur [Duf07]. Tenter d’exécuter ces instructions peut donc provoquer des comportements totalement imprévus et peut mener à la défaillance du système reposant sur ce processeur. Ainsi, des programmes tels que Crashme21 générant un flot d’instructions aléatoires, ont déjà montré leur efficacité sur différents types d’architecture. 2.1.2 Attaques ciblant la gestion de la mémoire Les attaques ciblant la mémoire correspondent à des attaques qui visent à modifier certaines régions de mémoire du calculateur. Le terme “mémoire” est à considérer au sens large : il inclut la mémoire centrale (RAM), mais aussi l’environnement d’exécution du processeur (tels que les registres par exemple) et les régions de mémoires incluses dans les contrôleurs d’entrées/sorties. Ces attaques peuvent être perpétrées depuis un programme s’exécutant sur le processeur en exploitant une vulnérabilité logicielle, mais aussi depuis un périphérique malveillant, abusant les mécanismes d’entrées/sorties tels que les accès directs à la mémoire (DMA ou Direct Memory Access). 2.1.2.1 Accès à la mémoire depuis le processeur La façon la plus directe d’accéder à la mémoire consiste à utiliser le processeur. Normalement, ces accès sont limités à la mémoire attribuée au processus en cours d’exé- cution. Ces privilèges peuvent être étendus grâce à certaines fonctionnalités des systèmes d’exploitation. Par exemple, sous Linux, il est possible d’accéder à la mémoire du système d’exploitation au travers de l’utilisation des fichiers /dev/mem ou /dev/kmem ou au travers de certaines fonctionnalités matérielles. Ainsi Joanna Rutkowska, dans [RW09], a montré que le mode SMM (System Management Mode) des processeurs Intel peut être détourné pour obtenir un accès direct à toute la mémoire. L’accès à la mémoire depuis le processeur peut être également réalisé en exploitant des vulnérabilités (telles que les débordements de tampons, les chaînes de formats, etc.), qui peuvent affecter tout type de composant logiciel (applications, système d’exploitation, gestionnaire de machines virtuelles). Des exemples de telles vulnérabilités ont déjà été recensés sur des systèmes tels que Windows [CC13], Mac [Art14] et Linux [Aed12], en particulier pour les plateformes x86. Ces vulnérabilités sont dûes à un manque de rigueur dans le codage des applications, en particulier l’absence de tests aux valeurs limites et l’absence de vérification lors d’allocation ou libération de mémoire. Les conséquences de l’exploitation de ces vulnérabilités peuvent être sérieuses puisqu’elles peuvent permettre à l’attaquant d’exécuter du code sur la machine cible, avec différents niveaux de privilège, en fonction du logiciel vulnérable exploité. En particulier, si une vulnérabilité de ce genre est présente non seulement dans les couches applicatives mais au sein du noyau du système lui-même (ce qui reste possible malgré le niveau de criticité du noyau), son exploitation permet alors à un attaquant d’exécuter du logiciel malveillant avec les privilèges du noyau, ce qui rend ces attaques particulièrement graves. 21http://people.delphiforums.com/gjc/crashme.html 382.1.2.2 Accès à la mémoire par les entrées/sorties L’accès à la mémoire peut être réalisé par le mécanisme d’accès direct à la mémoire (DMA) piloté par des contrôleurs d’entrées/sorties. Ceux-ci permettent d’accéder à la mémoire centrale en lecture et en écriture mais aussi aux mémoires internes et registres d’autres contrôleurs (ces attaques sont appelées attaques peer-to-peer). Ces dernières attaques sont particulièrement difficiles à détecter dans la mesure où elles ne nécessitent aucun transfert de données dans la mémoire principale. Cependant, ce type d’attaque n’est pas réalisable sur tous les chipsets22 actuels [LSLND10]. Les accès DMA peuvent être divisés en deux catégories, selon que le processeur intervient ou pas dans la réalisation de l’accès. Si l’accès est initié par le périphérique lui-même, on parle de périphérique disposant d’un accès bus master. Ces périphériques, par exemple les périphériques FireWire, peuvent alors prendre le contrôle du bus et réaliser des transferts de données sans aucune intervention du processeur. Ces attaques sont donc particulièrement difficiles à détecter. A l’opposé, si l’accès à la mémoire est contrôlé par le processeur, le logiciel malveillant qui réalise cet accès doit nécessairement s’exécuter sur le processeur, ou au moins doit posséder un programme complice s’exécutant sur le processeur. Les attaques DMA ont montré leur efficacité pour contourner les mécanismes de protection mémoire implémentés par un système d’exploitation. Loïc Duflot a montré par exemple qu’un code malveillant avec des privilèges réduits peut initier des transferts DMA dans les contrôleurs USB UCI [Duf07] de façon à obtenir les mêmes privilèges que ceux du noyau. M. Dornseif [Dor04] a ainsi montré comment un périphérique FireWire peut accéder à la totalité de la mémoire par l’intermédiaire du contrôleur FireWire connecté sur une machine Linux, Mac ou BSD. A. Boileau [Boi06] a poursuivi ces travaux sur les systèmes Windows et a montré qu’il pouvait contourner le mécanisme d’identification de connexion grâce à un tranfert DMA depuis un périphérique FireWire simplement connecté à la machine. D’après D. Maynor [May05], les contrôleurs USB On-The-Go présenteraient les mêmes caractéristiques et pourraient être abusés par des périphériques malveillants tentant d’exécuter ce même type de transfert DMA. Enfin, L. Duflot [DLM09] a montré qu’en exploitant à distance une vulnérabilité dans le firmware d’un contrôleur réseau, il est possible de lui faire réaliser des accès DMA de façon à obtenir un accès administrateur à distance. Les attaques visant la mémoire, qu’elles soient menées depuis le processeur ou depuis des contrôleurs d’entrées/sorties malveillants, peuvent être classifiées, selon leur cible : les composants logiciels (applications, système d’exploitation, hyperviseur), le processeur lui-même et son environnement d’exécution (par exemple ses registres) ou même les mémoires ou registres internes des contrôleurs d’entrées/sorties. Nous présentons briè- vement chacune de ces classes dans les sous-sections suivantes. 22Le chipset est un ensemble de puces électroniques chargé d’interconnecter les processeurs à d’autres composants matériels tels que les mémoires, les cartes graphiques, les cartes réseau, les contrôleurs de disque, etc. 392.1.2.3 Attaques ciblant les applications Un attaquant peut corrompre la mémoire d’une application particulière s’exécutant sur la machine cible. Cibler la mémoire d’une seule application peut avoir l’avantage d’être relativement difficile à détecter et éradiquer. De telles attaques sont en général le résultat d’un débordement de tampon. Dans le contexte avionique, on peut par exemple penser à une tâche de faible criticité qui veut provoquer la défaillance d’une application critique s’exécutant sur la même plateforme, à l’aide de ce type de corruption mémoire. Elle peut aussi modifier le comportement de l’application critique, pour la faire entrer dans une boucle infinie par exemple. De telles attaques peuvent permettre aussi de contourner des mécanismes de protection comme des systèmes d’authentification : l’application non critique peut essayer de désactiver les contrôles réalisés par l’application critique en modifiant son espace mémoire. 2.1.2.4 Attaques ciblant le système d’exploitation Les attaques en mémoire peuvent cibler l’espace mémoire du noyau du système d’exploitation. Corrompre un noyau de système d’exploitation est bien sûr particulièrement intéressant pour un attaquant puisque cela signifie potentiellement corrompre toutes les applications s’exécutant sur ce noyau. Certains maliciels se spécialisent dans ce type de corruption. Ce sont les rootkits noyau. Ils tentent d’exploiter des vulnérabilités dans le code des noyaux de systèmes d’exploitation de façon à pouvoir y injecter du code malveillant. La corruption d’un noyau ayant de très graves conséquences, il est très important de le protéger efficacement. Cependant, la complexité des noyaux de système d’aujourd’hui fait que cette tâche est particulièrement ardue. De plus, les mécanismes de protection du noyau sont en général implémentés dans le noyau lui-même (qui correspond souvent au mode le plus privilégié du processeur), et peuvent donc être rapidement desactivés par un attaquant ayant réussi à injecter du code dans le noyau. Les attaques visant les noyaux de système sont donc particulièrement redoutables, quels que soient le contexte et le domaine d’application. 2.1.2.5 Attaques ciblant l’hyperviseur Les machines virtuelles sont de plus en plus utilisées aujourd’hui, en particulier depuis l’émergence du Cloud Computing. Les machines virtuelles sont gérées par un gestionnaire de machines virtuelles (ou hyperviseur). Si la virtualisation a des atouts certains, elle peut aussi être la source potentielle de nouveaux problèmes de sécurité. Différents types d’attaques ont déjà été recensées [xen14, vir14, vmw14]. En effet, les machines virtuelles partagent la même architecture physique, puisqu’elles s’exécutent sur la même machine, et l’allocation des ressources qu’elles utilisent est gérée et contrôlée par l’hyperviseur. Une machine virtuelle peut donc profiter de ce partage pour essayer d’accéder ou modifier des données d’une machine virtuelle s’exécutant sur la même machine physique. Plus grave, encore, une machine virtuelle peut tenter de corrompre l’hyperviseur lui-même. La corruption de l’hyperviseur peut entraîner des conséquences graves puisque c’est lui qui 40assure l’isolation spatiale et temporelle des machines virtuelles. On peut donc imaginer des attaques qui pourraient essayer de rompre cette isolation ou qui pourraient corrompre l’hyperviseur de façon à modifier directement la mémoire de certaines machines virtuelles. Des vulnérabilités de ce type ont déjà été identifiées dans certains hyperviseurs [Cou13]. 2.1.2.6 Attaques ciblant l’environnement du processeur L’environnement du processeur peut également être la cible d’attaques. En particulier, il peut être intéressant de modifier les registres d’un processeur et même son micro-code. Certains registres sont très importants, par exemple le registre idtr sur l’architecture x86, qui contient l’adresse de la table des interruptions. Les registres cr0, cr3, cr4 ont aussi des rôles très importants et la corruption de certains bits de ces registres peut totalement changer le fonctionnement de la machine. Loïc Duflot a par exemple montré [DLM09] qu’il est possible d’exécuter du code malveillant dans les gestionnaires des interruptions SMI23 (gestionnaires d’interruptions qui sont exécutés dans le mode SMM24 du processeur). Cette corruption repose sur la modification d’un registre interne particulier du processeur. L’architecture PowerPC de type RISC contient un nombre élevé de registres. Parmi ces registres, le MSR (Machine Status Register) permet de définir le mode de privilège du processeur : utilisateur (non-privilégié) ou superviseur (privilégié). Il convient donc de ne pas le laisser accessible à n’importe quel processus. D’autres registres peuvent aussi être intéressants pour un attaquant : IVOR0-4125 (registres contenant les vecteurs d’interruption), L2CSR0-126 (registres contenant la confi- guration du cache de niveau L2) ou encore MAS0-727 (registres contenant la configuration de la MMU). Toutes les attaques en mémoire sont bien sûr envisageables sur tout type d’architecture, qu’elles soient grand public ou avionique et il faut donc les considérer avec attention. 2.1.3 Attaques ciblant les communications Les communications concernent tous les échanges de données entre deux ou plusieurs entités. Elles peuvent concerner des échanges d’informations entre plusieurs tâches, à l’aide de mécanismes tels que les IPC (Inter Process Communication) par exemple. Elles peuvent aussi représenter les échanges entre différentes machines (ou modules dans le contexte avionique) reliées par un bus de communication (tel que le classique réseau Ethernet dans le cas des PCs grand public ou un bus spécifique tel que le réseau AFDX [ari09] dans le cas des systèmes avioniques). Nous envisageons dans cette section les attaques liées à ces différentes communications. De façon générale, les attaques ciblant les communications peuvent permettre à une tâche de faible criticité de modifier les données 23System Management Interrupt. 24System Management Mode. 25Interrupt Vector Offset Register 0 à 41. 26L2 Configuration Status Register 0 et 1. 27MMU Assist Register 0 à 7. 41d’une tâche plus critique via ces mécanismes de communications. Les attaques peuvent aussi être du type man-in-the-middle. Elles consistent alors à capturer ou modifier des données transmises entre deux entités et elles supposent que l’attaquant ait un accès physique au medium de communication. Si l’on considère plus spécifiquement le cas d’un système embarqué avionique, trois types de communications sont en général utilisés : les communications inter-modules, les communications intra-partition et les communications inter-partitions. La figure 2.2 représente ces communications. Deux partitions sont représentées (P0 et P1), chacun contenant quatre tâches (T0 à T3). inter-partitions T0 T1 T2 T3 P0 T0 T1 T2 T3 P1 Noyau intra-partition inter-modules Fig. 2.2 – Les différents types de communications. Dans l’architecture avionique de type IMA, la communication inter-modules est le plus souvent réalisée aujourd’hui en utilisant le réseau AFDX. Ce réseau est déterministe et garantit l’absence de perte de paquets. Tous les événements d’émission et réception de paquets AFDX sont préparés et configurés statiquement avant la compilation. Il n’est donc a priori pas possible de les modifier après avoir démarré les applications. En revanche, chaque partition qui émet des données, construit pendant l’exécution la payload correspondant à chaque émission. Une application malveillante peut donc tenter de fabriquer une payload d’une taille bien supérieure à la taille qu’elle indique au driver AFDX, de façon à provoquer un débordement de buffer dans la zone où cette payload est recopiée, par exemple. Par ailleurs, une partition malveillante peut aussi tenter de se faire passer pour une autre lors d’émission de paquets. Si les méta-données associées à une communication AFDX sont accessibles en écriture à chaque application, une application malveillante peut intentionnellement modifier l’identité de l’émetteur pour se faire passer pour une autre partition. Enfin, un attaquant peut également essayer d’intercepter les communications (attaque de type man-in-the-middle) afin de capturer ou modifier les données. Cette attaque est très difficile à réaliser car elle suppose que l’attaquant ait un accès physique au bus AFDX ou qu’il puisse modifier la configuration des switchs AFDX, ce qui est très peu probable et qui ne constitue donc pas une hypothèse que nous considérons dans le cadre de notre étude. 42La communication inter-partitions est réalisée, toujours selon l’ARINC 653, en utilisant des messages entre partitions. Un message est un bloc de données avec une longueur finie et il est envoyé de façon périodique ou apériodique. Une partition malveillante peut tenter d’envoyer des valeurs erronées dans un message bien formé dans le but de modi- fier le comportement de la partition qui va recevoir ces valeurs. Cette attaque est plus intéressante si la partition qui reçoit ces messages est une partition critique. Elle peut également tenter d’envoyer des données malformées, par exemple en positionnant une fausse taille de message et en espérant provoquer un débordement de tampon dans la partition qui reçoit ce message. Enfin, la communication intra-partition est utilisée par les processus pour qu’ils communiquent entre eux, au sein d’une même partition. Un processus est une tâche exécutée dans une partition. Deux mécanismes sont décrits dans l’API ARINC 653 pour ces communications intra-partition : les buffers et les blackboards. Un buffer permet de créer une file de messages en ordre FIFO (First In First Out). Une tâche malveillante pourrait abuser de ce mécanisme en envoyant un grand nombre de messages pour saturer la mé- moire avec une file de messages trop grande ou alors en envoyant des messages de taille très importante, et ainsi perturber le fonctionnement correct des autres processus de la partition. Le blackboard est lui utilisé pour garder les messages jusqu’à ce qu’ils soient supprimés ou réécrits par d’autres messages. Une tâche malveillante peut facilement modifier ou supprimer les messages qui n’ont pas été écrits par elle car la zone de mémoire allouée doit être accessible à toutes les tâches de la partition qui communiquent par ce moyen. Ce mécanisme ne fonctionne que si toutes les tâches se font confiance. Ce type de corruption est cependant très limité pour un attaquant car il ne peut provoquer la défaillance que de la partition dans laquelle il a inséré une tâche malveillante. L’intérêt de l’attaquant est bien sûr plutôt de corrompre une tâche d’une autre partition ou le noyau du système lui-même. 2.1.4 Attaques ciblant la gestion du temps Pour cadencer les différentes opérations exécutées sur un calculateur, plusieurs horloges sont disponibles. On peut citer notamment dans les architectures récentes : la Real Time Clock (RTC), les Programmable Interval Timers (PIT), les Time Stamp Counters (TSC), les High Precision Event Timer (HPET). Pour satisfaire la demande des développeurs de logiciels en ce qui concerne la précision dans la mesure du temps, ces horloges sont de plus en plus performantes. Par exemple, la puce PIT défini en 1981, manipule un compteur 16 bits à une fréquence de 1.2 MHz tandis que les nouvelles versions des puces HPET manipulent un compteur de 64 bits à une fréquence de 10 MHz. Ces puces peuvent être configurées en deux modes différents : le mode one-shot ou le mode périodique. Dans le mode one-shot, la puce exécute une interruption une seule fois quand son compteur principal atteint une valeur spécifique stockée dans un registre. Dans le mode périodique, la puce exécute une interruption à des intervalles spécifiés. Un attaquant peut donc tenter de corrompre ces horloges en modifiant les valeurs de registres de configuration associés. La corruption de ces horloges peut avoir un impact direct sur l’exécution de tâches critiques qui alors ne sont plus en mesure de respecter 43leurs contraintes temps-réels, ce qui peut avoir de graves conséquences. La configuration des horloges et des interruptions est généralement modifiable uniquement par une entité avec des privilèges élevés (comme le noyau) donc seule une élévation de privilèges depuis une partition utilisateur quelconque peut donner la possibilité de corrompre les registres des horloges. Cependant, un autre facteur peut venir perturber les échéances temps réel d’une application. Il s’agit de la génération d’interruption. Lorsqu’une interruption est générée pendant l’exécution d’une application, le noyau prend la main et exécute la routine de traitement associée à cette interruption. Par exemple, la figure 2.3 représente la conséquence d’une interruption sur une partition. Noyau Partition Compteur horloge interruption noyau générée par une instruction t t t t1 t2 compteur = 300µs partie de la partition non-exécutée Fig. 2.3 – Exemple d’une partition de 300 microsecondes. Dans cette figure, une partition doit s’exécuter en 300 microsecondes. Une interruption survient avant la fin et le noyau prend le relais pour la traiter. A la fin du traitement de l’interruption, la main est redonnée à la partition. Si le noyau met trop de temps à traiter l’interruption, alors la partition n’aura pas le temps de s’exécuter entièrement. Le compteur de l’horloge décrémentera jusqu’à atteindre zéro pour changer de partition, même si la partition courante n’a pas terminé son exécution. La conséquence est la suivante : une partie de la partition n’est pas exécutée (représentée par la partie foncée sur le schéma). Il est donc important d’inclure parmi les attaques qui ciblent la gestion du temps, celles qui peuvent tirer profit de la gestion des interruptions. Nous y reviendrons plus en détails dans le prochain chapitre. 2.1.5 Attaques ciblant la gestion des processus Nous appelons “gestion des processus” la création, la modification et la suppression des processus et des threads. Pour créer un processus, des privilèges sont requis puisque des appels-systèmes sont nécessaires. Si un programme malveillant a la possibilité de créer des processus, il peut consommer des ressources CPU non-nécessaires menant à un déni-de-service (DoS). Une telle attaque peut être réalisée en inondant le système 44d’exploitation avec des requêtes pour ralentir, voire stopper le système (en créant un nombre important de processus à l’aide d’une fork bomb 28 par exemple). Générer un deadlock est aussi un bon moyen pour un attaquant de causer un DoS. Un programme malveillant peut abuser les mécanismes de synchronisation des processus pour provoquer un blocage (deadlock) en monopolisant une ressource (typiquement, gardée par un sémaphore) requise par un processus légitime. 2.1.6 Attaques ciblant l’ordonnancement Les systèmes d’exploitation modernes ont la capacité d’exécuter des processus multiples en même temps sur le même processeur. Ces systèmes d’exploitation sont appelés “systèmes d’exploitation multi-tâches”. L’ordonnanceur qui organise l’exécution des processus en fonctionnement décide quand le processeur doit exécuter le processus et pour combien de temps. Quand le slot de temps dédié à l’exécution d’un processus expire, l’ordonnanceur donne automatiquement la main au prochain processus. Typiquement, pendant le démarrage du système, le noyau met en place une horloge pour activer pé- riodiquement l’ordonnanceur. La gestion efficace des ressources par l’ordonnanceur est cruciale dans ce contexte. Si un processus est interrompu alors qu’il utilise une ressource, l’ordonnanceur ne doit pas donner la main à un autre processus qui pourrait utiliser la même ressource. Cette situation doit être évitée pour empêcher les deadlocks. Dans ce cadre, un attaquant peut tenter de corrompre l’ordonnancement en modifiant la configuration de l’horloge dans la zone de mémoire correspondante. Le résultat d’une telle attaque serait catastrophique car les contraintes temps-réel ne seraient alors pas respectées. 2.1.7 Attaques ciblant les mécanismes cryptographiques Les mécanismes cryptographiques peuvent aussi être vulnérables à des attaques. Des algorithmes peuvent ainsi contenir des défauts découverts plusieurs années après leur développement, qui peuvent être exploités grâce à l’amélioration de la puissance de calcul disponible (par exemple, les collisions MD5 ont été découvertes en 2004 [WFLH04] alors que l’algorithme existe depuis 1991) et même si les algorithmes cryptographiques sont prouvés pour être corrects, leurs implémentations peuvent contenir des bugs ou des contournements qui pourraient être exploités par des attaquants. L’analyse par canauxcachés est un exemple d’une telle exploitation [KJJ99]. La consommation de courant, les analyses des temps [Koc96] ou même l’écoute des composants [GST13] peuvent permettre de retrouver des clés secrètes RSA ou AES. Cependant, ces attaques ne sont réalisables qu’avec un accès physique au système et avec un matériel important pour réaliser toutes les mesures nécessaires. Par exemple, une clé RSA peut être reconstruite en utilisant seulement 27% de ces bits en mémoire [HS09]. Les attaques sur les mécanismes de cryptographie dépendent grandement de la gestion de la mémoire (voir sous-section 2.1.2) car si une “fuite” de mémoire est présente, des informations sur la clé secrète peuvent être divulguées, et ainsi compromettre la sécurité du système complet. 28Processus créés dans une boucle infinie, menant à l’épuisement des ressources du système. 452.1.8 Attaques ciblant les fonctions ancillaires Les fonctions ancillaires correspondent à la gestion de l’alimentation, de l’overclocking, du contrôle de température, etc. Dans les processeurs x86, ces fonctions sont supportées par le SMM (System Management Mode). Ces dernières années, des vulnérabilités ont été découvertes dans ce mode. Un attaquant peut exploiter ces vulnérabilités pour exécuter du code arbitraire dans un mode privilégié [ESZ08, DLM09]. Le mode SMM est un mode 16 bits utilisé pour le contrôle de la carte mère et la gestion de l’alimentation. Seule une SMI (System Management Interrupt) peut faire entrer le processeur dans le mode SMM, ces SMIs sont générés par le chipset. Mais n’importe quel contrôleur avec les privilèges d’entrées/sorties peut générer ces SMIs. A partir de cette zone SMM, il est possible d’obtenir des privilèges élevés, d’utiliser un rootkit ou encore de contourner des restrictions de démarrage sûrs (late launch restrictions) [DLM09]. 2.1.9 Conclusion Nous avons, dans cette section, essayé de lister exhaustivement les attaques pouvant cibler les fonctionnalités de base d’un calculateur avionique. Comme nous l’avons explicité au début de ce chapitre, cette classification concernant les fonctionnalités de base est tirée en grande partie des attaques que l’on peut rencontrer sur les systèmes informatiques “grand public”. La section suivante concerne des attaques ciblant des mécanismes spécifiques qui sont présents dans la plupart des calculateurs embarqués exécutant des systèmes critiques, pour des raisons de sûreté de fonctionnement : les mécanismes de tolérance aux fautes. 2.2 Les attaques ciblant les mécanismes de tolérance aux fautes Les systèmes avioniques, comme bon nombre de systèmes embarqués critiques, intègrent des mécanismes de tolérance aux fautes pour être capables de continuer à fonctionner correctement même si des défaillances surviennent. La figure 2.4 représente ces différents mécanismes de tolérance aux fautes. Ces principes font références aux concepts de bases présentés dans [ALRL04]. La chaîne fondamentale des entraves à la sûreté de fonctionnement est la suivante : ... ⇒ Faute ⇒ Erreur ⇒ Défaillance ⇒ ... La tolérance aux fautes vise à éviter l’occurence de défaillances. Elle est mise en œuvre par la détection des erreurs et le rétablissement du système. Le rétablissement du système est lui-même mis en œuvre par le traitement d’erreurs et le traitement de fautes. Le traitement d’erreurs a pour but l’élimination des erreurs de l’état du système avant l’occurrence de défaillance. Le traitement de fautes a pour but d’empêcher une 46Traitement d'erreurs Traitement de fautes Détection d'erreurs Diagnostic Recouvrement Isolation Reconfiguration Reprise Poursuite Compensation Mécanismes de tolérance aux fautes Diagnostic Réinitialisation Fig. 2.4 – Schéma des différents traitements de la tolérance aux fautes. nouvelle activation de faute dans le système. Le traitement d’erreurs est en général la première étape du rétablissement du système, le traitement des fautes en est la seconde. Le traitement d’erreurs peut être mis en œuvre par : • la détection d’erreur, qui permet à un état erroné d’être identifié comme tel ; • le diagnostic d’erreur, qui permet l’évaluation des dommages par une erreur dé- tectée ou par des erreurs propagées avant la détection ; • le recouvrement d’erreur, où un état sans erreur est substitué à un état erroné. Les techniques de détections d’erreur peuvent être classifiées en détections concomitantes, si elles sont réalisées pendant l’exécution du service normal, et en détections préemptives, si elles sont effectuées lors de la suspension du service (par exemple, en phase d’initialisation). La détection préemptive vise à révéler l’éventuelle présence d’erreurs latentes ou des fautes dormantes. Concernant le recouvrement d’erreurs, trois techniques sont classiquement utilisées : • la reprise, où la transformation de l’état erroné consiste à ramener le système à un état antérieur sain avant l’occurrence d’erreur ; ceci implique la sauvegarde de points de reprise, qui sont des sauvegardes régulières dans le temps, de l’état du système, dans lequel le système peut ensuite être restauré ; • la poursuite, où la transformation de l’état erroné consiste à trouver un nouvel état dans lequel le système peut continuer à opérer (éventuellement en mode dégradé) ; • la compensation, où l’état erroné contient suffisamment de redondances pour permettre sa transformation en un état sans erreur. La reprise est en général inapplicable à un système avionique puisqu’il est impossible de ramener le système complet (incluant notamment certaines données réelles comme la position ou la vitesse de l’appareil, le niveau de carburant disponible, etc.) dans un 47état sain précédent. En revanche, les systèmes avioniques appliquent en général une combinaison de techniques de poursuite et de compensation. La seconde étape de rétablissement de système est le traitement de fautes. Il vise à empêcher de nouvelles activations de fautes. Le traitement de fautes comprend plusieurs étapes : le diagnostic, l’isolation, la reconfiguration et la réinitialisation. Le diagnostic identifie et enregistre les causes des erreurs de façon à en préciser le type et la localisation précise. L’isolation consiste à exclure de façon logicielle ou matérielle, les composants fautifs de la délivrance du service (en cela, cette étape rend les fautes dormantes). La reconfiguration peut soit provoquer l’exécution du service sur un composant supplé- mentaire à disposition, soit répartir les tâches sur l’ensemble des composants disponibles non fautifs. La réinitialisation vérifie et met à jour la nouvelle configuration, et enregistre cette nouvelle configuration dans des tables du système. Tous ces mécanismes de tolérance aux fautes peuvent être des cibles pour un attaquant. Par exemple, si l’attaquant est capable d’empêcher la détection d’erreurs, il peut en conséquence empêcher le recouvrement du système en cas d’erreur et ainsi mener le système à défaillance. S’il peut corrompre le diagnostic d’erreur, il peut également empêcher la reconfiguration du système. La corruption d’un recouvrement d’erreur peut provoquer la substitution d’un état d’erreur bien choisi à l’état courant. De la même façon, le diagnostic de fautes peut être compromis pour identifier un composant correct comme défaillant ou un composant fautif comme correct. Une passivation de fautes corrompue peut désactiver un composant correct à la place du composant défaillant, et une reconfiguration défaillante peut modifier la structure du système afin que les tâches critiques ne soient plus exécutées. Dans les sections suivantes, nous envisageons plus en détail les attaques pouvant cibler le traitement des erreurs (en particulier, les étapes de détection des erreurs et recouvrement des erreurs) et le traitement des fautes. 2.2.1 Détection d’erreurs Du point de vue d’un attaquant, les mécanismes de détection d’erreur peuvent être une cible intéressante. En effet, si un attaquant est capable d’empêcher la détection d’erreur, alors aucun recouvrement ne peut être effectué, ce qui peut causer une dé- faillance du système. Inversement, si un attaquant provoque la détection d’erreur trop fréquemment, il peut déclencher une procédure de recouvrement incorrecte, ce qui peut provoquer l’épuisement des unités de rechange et ainsi rendre inefficace les mécanismes de tolérance aux fautes. Les moyens utilisés pour la détection d’erreurs peuvent varier en fonction du niveau où la vérification est effectuée et le compromis coût/efficacité sélectionné. Les formes les plus populaires sont les suivantes : • Les codes détecteur d’erreur ; • La duplication et comparaison ; • Les contrôles temporels et d’exécution ; • Les contrôles de vraisemblance ; • Les contrôles de données structurées. 48Nous décrivons dans la suite trois d’entre elles : les contrôles de vraisemblance, la duplication et comparaison et les contrôles temporels et d’exécution car ils sont largement utilisés dans l’industrie. 2.2.1.1 Contrôle de vraisemblance L’implémentation de mécanismes de contrôle de vraisemblance nécessite peu de coûts additionnels, en comparaison au coût des éléments fonctionnels du système. Beaucoup de contrôles peuvent être implémentés pour détecter si les erreurs surviennent depuis une large sélection de fautes, mais leur couverture est généralement limitée. Ce mécanisme peut être utilisé par exemple pour détecter les erreurs de valeurs, les violations des mé- canismes de protection de la mémoire ou pour vérifier la conformité des entrées/sorties. Ces contrôles sont relativement faciles à faire échouer sous réserve de connaître la façon dont le système se comporte avec des données non conformes. Envoyer des données aléatoires (technique de fuzzing) permet de tester si les contrôles de vraisemblance peuvent résister à tout type de données d’entrée. Si des erreurs ne sont pas détectées alors le système peut continuer son exécution en engendrant de possibles défaillances. 2.2.1.2 Duplication et comparaison La duplication et comparaison est un mécanisme de détection d’erreurs largement utilisé, malgré un coût matériel important, car il est simple à mettre en place. La mise en œuvre repose sur l’utilisation d’au moins deux unités redondantes qui sont indépendantes du point de vue de la création et de l’activation des fautes : il est nécessaire de s’assurer que soit les fautes sont crées ou activées indépendamment dans les unités redondantes, soit que, si une même faute provoque des erreurs dans chaque unité, ces erreurs sont différentes. Si on considère les fautes physiques internes, les unités peuvent être identiques dans la mesure où l’on peut supposer que les compsants matériels défaillent de manière différente dans chaque unité. Dans le cas de fautes physiques externes, il faut éviter des fautes de mode commun en isolant physiquement les deux unités ou décalant dans le temps le traitement sur les deux unités. Face à la duplication et comparaison, un attaquant peut tenter de corrompre chaque unité de façon à ce que la détection soit inefficace. L’éloigement géographiquement des unités peut résoudre en partie le problème lorsqu’il s’agit d’attaques physiques mais si l’on considère les attaques logicielles (et donc les fautes de conception du logiciel), il est nécessaire d’avoir recours à la diversification des logiciels et de matériels. En effet, des logiciels et matériels de conception et de mise en œuvre différentes ne sont pas vulnérables aux mêmes attaques par construction. 2.2.1.3 Contrôles temporels et d’exécution Dû à ses coûts très limités, les contrôles temporels par des “chiens de garde” (watchdog timers) sont les plus largement utilisés pour la détection d’erreurs durant l’exécution. Un watchdog peut être utilisé dans différentes situations telles que la détection de la 49défaillance d’un périphérique en contrôlant son temps de réponse (suite à l’envoi d’un signal) qui ne doit pas dépasser une valeur maximale ou la surveillance de l’activité des processeurs. Dans ce dernier cas, le watchdog doit être périodiquement rafraîchi par le processeur. Ainsi, si le comportement du processeur est altéré de sorte que le watchdog n’est plus rafraîchi avant qu’il n’expire, une exception sera levée. Une telle approche peut être utilisée, pour sortir d’une situation de blocage ou d’une boucle infinie, ou pour détecter l’arrêt d’un processeur distant. Une attaque simple sur cet élément consiste à empêcher le signal de revenir à l’émetteur et donc de faire passer un programme ou un périphérique comme défaillant alors qu’il ne l’est pas. Cette technique peut être mise en œuvre par un déni-de-service du programme visé (par exemple, par saturation de requêtes d’appels-systèmes) ce qui engendrera une augmentation du temps processeur ralentissant ainsi fortement le traitement des requêtes et donc le temps de réponse associé. 2.2.2 Recouvrement d’erreurs En concordance avec la détection d’erreurs, le recouvrement d’erreurs est utilisé pour continuer à délivrer le service du système. Trois types de recouvrements peuvent être effectués : la reprise, la poursuite et la compensation. La reprise est le moyen le plus utilisé ; il consiste en la sauvegarde régulière de l’état du système pour permettre de le restaurer si une erreur est détectée. Le système est sauvegardé avec des points de restauration, lesquels peuvent être possiblement corrompus par un attaquant. La corruption de tout ou partie d’un seul point de restauration suffit à mettre en danger le système. Il est donc important de vérifier les privilèges nécessaires à la création et la modification des régions de mémoire dans lesquelles ces points de restauration sont créés. La poursuite constitue une alternative ou une approche complémentaire à la reprise. La poursuite consiste à chercher un nouvel état acceptable pour le système, à partir duquel il sera possible de poursuivre l’exécution du système (éventuellement dans un mode dégradé). Dans le cas où la poursuite est la technique de tolérance aux fautes adoptée par le système, l’attaquant peut faire en sorte de forcer l’utilisation du mode dégradé, en provoquant le plus souvent possible des erreurs. La compensation d’erreur nécessite que l’état du système comporte suffisamment de redondance pour permettre en dépit des erreurs pouvant l’affecter, sa transformation en un état exempt d’erreur. Un exemple typique est celui des architectures à base de vote majoritaire où la présence d’erreurs n’aura aucune conséquence pour le système. Un exemple typique de la détection et compensation d’erreur est l’utilisation des composants autotestables exécutant en redondance active le même traitement ; en cas de défaillance de l’un d’entre eux, il est déconnecté et le traitement se poursuit sans interruption sur les autres. La compensation, dans ce cas, se limite à une commutation éventuelle de composants. C’est sur ce principe que fonctionne le système de gestion de commandes de vol des Airbus 320/330/340. Lorque la compensation d’erreurs est utilisée, et donc de la redondance, un attaquant peut faire en sorte de provoquer des erreurs dans chacune des unités redondantes, de façon à faire en sorte que la compensation ne soit plus possible 50puisqu’il ne subsiste plus d’unité considérée correcte dans le système. 2.2.3 Traitement de fautes Le traitement de fautes a pour but d’empêcher les fautes d’être activées une nouvelle fois. Le traitement de fautes consiste en : diagnostic, isolation, reconfiguration et réinitialisation. Toutes ces techniques peuvent être la cible d’attaques. Par exemple, des attaques peuvent faire en sorte de faire échouer le diagnostic de façon à diagnostiquer à tort un composant non-défectueux comme défectueux. Un attaquant peut de même tenter de provoquer l’isolation d’un composant non-défectueux ou provoquer la poursuite du système avec un composant défectueux. Il peut également provoquer à tort la mise à jour d’une nouvelle configuration du système. Toutes ces attaques peuvent amener le système à défaillance. En effet, le diagnostic à tort d’un composant non-défectueux comme défectueux permet d’éliminer des composants valides du système et donc à terme de forcer le système à passer dans un mode dégradé. De même, si l’attaquant parvient à provoquer l’isolation de tous les composants non défectueux, alors il peut provoquer une exécution totalement erronée du système. Enfin, l’attaquant peut également cibler le mécanisme de mise à jour de la configuration. S’il parvient à mettre à jour la configuration de façon à activer une nouvelle configuration erronée, il peut amener le système à défaillir. 2.2.3.1 Isolation de fautes Pour isoler une faute, le composant concerné est supprimé mais dans un scénario malveillant, l’attaquant peut essayer de provoquer volontairement une faute pour isoler un composant sain. Il peut ainsi provoquer la passivation de toutes les unités du système et provoquer son arrêt. L’attaquant peut aussi directement cibler le mécanisme d’isolation de fautes de façon à ne pas isoler un composant lorsqu’il est défectueux. Ces attaques peuvent mener le système à se comporter d’une façon totalement arbitraire et ainsi provoquer sa défaillance. Une autre attaque possible consiste à modifier le mécanisme d’isolation de fautes pour faire en sorte que le mécanisme détecte tous les composants comme défectueux (ce qui aura comme conséquence de forcer l’isolation pour tous les composants) ou de faire en sorte que ce mécanisme ne détecte aucun composant défectueux (ce qui aura pour conséquence de laisser les défaillances se produire suite à un état incohérent du système). 2.2.3.2 Reconfiguration La reconfiguration consiste à modifier la configuration du système (éventuellement dans un mode dégradé) pour le réactiver dans un état sans faute. Un attaquant peut tirer avantage de cette reconfiguration en modifiant le processus qui effectue la reconfiguration pour établir sa propre reconfiguration. Une reconfiguration peut impliquer l’abandon de certaines tâches ou la ré-allocation de certaines tâches aux composants restants pour délivrer un service acceptable. Cependant, le service délivré après reconfiguration peut 51être en mode dégradé, si la reconfiguration est compromise. La configuration peut être modifiée si par exemple, les accès en écriture à la mémoire où est stockée cette configuration sont trop permissifs. L’attaquant peut alors provoquer l’arrêt de toutes les tâches ou empêcher la ré-allocation de certaines tâches. 2.3 Contexte et hypothèses d’attaques Dans la section précédente, nous avons classifié les différentes attaques possibles en deux catégories : mécanismes de base et mécanismes de tolérance aux fautes. Dans cette section, nous proposons d’exposer l’ensemble des hypothèses et contraintes qui caractérisent l’environnement dans lequel nous effectuons nos expérimentations d’attaques. En particulier, nous allons exposer les hypothèses d’attaques mais aussi les conditions particulières dans lesquelles nous allons étudier la faisabilité de ces attaques. Un système critique avionique répond à un certain nombre de contraintes particulières et nous devons en tenir compte pour établir les hypothèses. Dans la première sous-section, nous détaillons les types d’attaquants et les hypothèses d’attaques que nous considérons dans cette étude. Dans la sous-section suivante, nous détaillons le type d’application malveillante que nous avons utilisé pour cette étude, sa configuration et la façon dont nous l’avons modifiée. 2.3.1 Attaquants Notre étude se focalise sur les attaques logicielles. En effet, nous considérons que des personnes malveillantes n’ont pas d’accès physique au système. Si un tel accès physique est donné, il est plus simple, pour provoquer des défaillances, de débrancher des cartes ou des câbles plutôt qu’avoir recours à des applications malveillantes. Par exemple, le débranchement des câbles AFDX interrompt les communications entre modules, ce qui provoque des erreurs à répétition pour finalement probablement mettre en fonctionnement les unités redondantes si elles existent ou simplement arrêter les modules qui ne peuvent plus communiquer. Nous considérons donc les trois hypothèses suivantes : • L’attaquant n’a pas d’accès physique au système en exécution ; • Les pilotes et l’équipage sont considérés comme des personnes de confiance, ainsi que tout le personnel de maintenance ; • Les passagers, les utilisateurs de réseaux publics et les développeurs COTS sont considérés comme des personnes potentiellement malveillantes ; Nous donnons dans la suite quelques informations sur cette classification des personnes potentiellement malveillantes ou non ainsi que sur leur liberté d’actions s’ils sont malveillants. Précisons que ces hypothèses d’attaques peuvent sembler peu probables, mais, dans le cas des analyses de sécurité et en accord avec Airbus, nous avons volontairement opté pour des hypothèses relativement pessimistes. Les passagers sont considérés comme potentiellement malveillants. En effet, les passagers ont la possibilité d’embarquer à bord de l’avion leur ordinateur portable, leur 52tablette, leur smartphone, etc. Ils peuvent ainsi, à l’aide de ces matériels connectés, tenter de se connecter au réseau de l’avion et tenter ensuite de progresser dans ce réseau de façon à accroître leurs privilèges et ainsi essayer d’atteindre des calculateurs connectés de façon plus ou moins directe au système de vol. Par ailleurs, les passagers, même bienveillants, peuvent posséder des logiciels infectés sur leur machine personnelle, qui peuvent réaliser ce type d’attaque à leur insu. Il est même possible que cette injection survienne directement lorsque le passager est dans l’avion. En effet, juste avant la phase de décollage, lorsque l’accès au réseau Internet est encore autorisé pour les passagers, on peut imaginer qu’un internaute malveillant puisse exploiter une vulnérabilité d’un PC portable ou d’une tablette d’un passager, qu’il puisse installer à cet instant précis un logiciel malveillant grâce à cette vulnérabilité et qu’il puisse tenter ensuite de mener une attaque à partir de cet équipement corrompu. Enfin, on peut même imaginer ce type d’attaque pendant le vol, puisque certaines compagnies autorisent d’ores et déjà l’utilisation du réseau Internet en vol. Certaines personnes ont des accès privilégiés à l’avion en dehors des périodes de vol pour la maintenance de l’avion par exemple, le ravitaillement, mais aussi pour l’installation d’équipements dans l’appareil, notamment dans la cabine. Ces opérateurs sont considérés comme des personnes de confiance et ne sont donc pas susceptibles d’installer volontairement des applications malveillantes lors de leur accès privilégié à l’avion. Cependant, il est envisagé dans un futur proche d’équiper les opérateurs de maintenance de PC portables personnels qui seront utilisés pour effectuer cette maintenance (qui aujourd’hui est réalisée avec du matériel spécifique). Si ce PC portable peut être par ailleurs utilisé en dehors des phases de maintenance de l’avion, pour un usage personnel (connexion au réseau Internet par exemple), il est alors tout à fait possible qu’il puisse être infecté par un logiciel malveillant. Lorsque ce PC est ensuite connecté au réseau de l’avion lors de la phase de maintenance, le logiciel malveillant peut tenter d’exploiter une vulnérabilité, pour ensuite tenter de se propager sur ce réseau. Même si aujourd’hui, ce type de menace n’est pas envisageable, il peut le devenir dans un futur proche (Airbus a d’ailleurs d’ores et déjà lancé des études sur le sujet pour y faire face [Laa09]). Comme nous l’avons indiqué dans le premier chapitre, l’introduction de logiciels COTS dans les systèmes critiques est de plus en plus envisagé. Sans envisager la malveillance des développeurs de COTS, on peut cependant supposer que ces derniers dé- veloppent leurs applications en ne respectant pas de strictes règles de codage et que par conséquent, leurs logiciels sont susceptibles de contenir des vulnérabilités, qui peuvent être exploitées pour exécuter des attaques. Dans le cas le plus favorable, ces COTS sont utilisés uniquement pour l’implémentation de partitions non critiques (c’est le cas que nous supposons dans cette thèse) mais on peut également imaginer que des COTS puissent être également utilisés dans le développement de logiciels critiques. Par ailleurs, les logiciels COTS ne sont en général pas développés pour le monde embarqué (par exemple vlc29 pour le streaming) et sont donc susceptibles de ne pas correspondre entiè- rement aux besoins des systèmes avioniques. Ces logiciels sont bien sûr testés et évalués du point de vue de la sécurité avant d’être insérés dans l’avion mais il est possible que 29http://www.videolan.org/vlc/ 53malgré tout, étant donné leur complexité, un certain nombre de vulnérabilités subsistent, en particulier dans les couches les plus proches du matériel, et que ces vulnérabilités puissent être exploitées. On peut aussi envisager l’hypothèse qu’un logiciel ou matériel COTS puisse contenir intentionnellement des fonctions malveillantes (une porte dérobée par exemple). 2.3.2 Hypothèse d’attaque : une application non critique malveillante Dans le cadre des expérimentations d’attaques que nous avons menées dans cette thèse et qui font l’objet du chapitre suivant, nous avons fait le choix d’utiliser une application malveillante compatible ARINC 653 déjà installée parmi les autres applications sur un calculateur qui exécute un noyau temps-réel critique. Cette application est non critique et l’objectif est de vérifier si elle peut avoir un impact sur la sécurité d’une application critique ou du noyau système lui-même. La façon dont a pu être installé cette application malveillante n’est pas l’objet de cette thèse mais elle peut faire intervenir les personnes potentiellement malveillantes que nous avons présentées dans la section précédente. L’installation de ce type d’application malveillante, même non critique, est bien sûr très improbable aujourd’hui, compte tenu des mécanismes de protection (physiques et logiques) déjà mis en place dans les avions. Cependant, dans le cadre de cette étude, nous nous plaçons volontairement dans un cadre très pessimiste, où nous supposons qu’elle a pu être installée, et nous nous focalisons sur l’étude des effets potentiels de cette application, afin de mieux s’en protéger. Dans le cadre de nos expérimentations, nous disposons d’un exécutif temps réel expé- rimental, en cours de développement, fourni par Airbus. La configuration du noyau et des applications est réalisée avant la compilation grâce à des fichiers textes qui permettent de générer le code approprié pour le noyau. Cette configuration comprend majoritairement les accès à la mémoire pour chaque partition et le noyau mais également les durées de chaque partition et la durée totale d’un cycle (l’exécution séquentielle de toutes les partitions), les communications inter-partitions si elles existent, le comportement du Health Monitor (HM) pour chaque partition, les appels-système, etc. Pour créer notre application malveillante, nous avons copié le code source en langage C d’une application avionique basique. Nous avons ensuite modifié l’application en langage assembleur pour ne pas dépendre des limitations du langage C par rapport à un langage de bas niveau. Effectivement, un langage de bas niveau peut directement avoir accès à la mémoire et à tous les registres (du mode utilisateur). En ce qui concerne le fonctionnement de l’application malveillante, elle peut réaliser toutes les actions disponibles depuis un mode utilisateur, qui peuvent éventuellement provoquer des erreurs, notamment : • exécuter des instructions privilégiées ; • accéder à des registres spéciaux ; • accéder à des données dans une zone mémoire interdite ; • exécuter des instructions dans une zone mémoire interdite. Le but est d’observer le comportement du noyau lorsque ces tests sont effectués. Si le mécanisme de gestion des erreurs est correctement réalisé alors aucune conséquence ne 54sera constatée. Comme nous le verrons dans le prochain chapitre, nous avons dû instrumenter le noyau pour observer son comportement et celui des applications, notamment pour mesurer les durées d’exécution ainsi que pour contrôler les erreurs provoquées. Conclusion Nous avons détaillé dans ce chapitre une classification de différentes attaques possibles sur les systèmes embarqués, qu’elles ciblent les mécanismes de base (processeur, gestion de la mémoire, communications, gestion du temps, gestion des processus, ordonnancement, cryptographie, fonctions ancillaires) ou qu’elles ciblent les mécanismes de la tolérance aux fautes (mécanismes de traitement d’erreur et mécanismes de traitement de fautes). Nous avons également précisé le contexte de nos expérimentations en listant les hypothèses d’attaques ainsi que le contexte d’exécution de ces attaques. Nous avons ainsi indiqué comment l’application malveillante, que nous utilisons pour lancer des attaques, a été configurée et installée parmi les autres applications. Dans le chapitre suivant, nous décrivons la plateforme d’expérimentation utilisée pour la réalisation de nos attaques, le noyau expérimental, les partitions ainsi que l’environnement de développement. Nous développerons également différentes attaques que nous avons pu mettre en œuvre. 5556Chapitre 3 Mise en œuvre de la méthodologie sur une plateforme IMA expérimentale Introduction Ce chapitre décrit 1) la méthodologie employée pour mettre en œuvre notre plateforme IMA d’expérimentations ainsi que 2) nos expérimentations et leurs résultats. Cette plateforme est composée d’un calculateur, d’une sonde JTAG, de l’IDE Codewarrior et d’un noyau temps-réel expérimental conçu par Airbus. Le noyau est développé selon le standard avionique ARINC-653 ("Avionics Application Software Standard Interface"). Ce standard est une interface pour le partitionnement temporel et spatial des ressources des systèmes embarqués. Les éléments constituant cette plateforme sont détaillés dans la suite de ce chapitre. Dans la section 3.1, nous décrivons le noyau temps-réel expérimental d’Airbus, son fonctionnement et sa configuration. Ensuite, nous détaillons l’architecture de la plateforme matérielle que nous avons utilisée, le P4080, et les fonctionnalités utilisées par le noyau (section 3.2). Dans la section 3.3, nous présentons les composants de la plateforme IMA utilisés. Puis, nous présentons les attaques (ainsi que leurs résultats) ciblant les mécanismes de base, notamment en ce qui concerne la gestion de la mémoire (section 3.4), les communications (section 3.5) et la gestion du temps (section 3.6). Enfin, nous décrivons les attaques (ainsi que leurs résultats) ciblant les mécanismes de tolérance aux fautes (section 3.7). Ces différents travaux ont fait l’objet de publications dans [DADN13] et [DDAN13]. 3.1 Système expérimental d’Airbus : noyau et partitions Le noyau temps-réel expérimental d’Airbus permet d’exécuter des applications en respectant le principe de partitionnement (ARINC 653). Le partitionnement spatial est 57opéré par la MMU et le partitionnement temporel par le MPIC. Les partitions sont exécutées dans l’ordre prévu par la configuration des fichiers comme vu précédemment. Le noyau s’initialise en réalisant les opérations suivantes : • l’activation des permissions de la zone de mémoire (MMU) ; • l’activation du compteur de temps (Time Base) ; • l’initialisation des interruptions (MPIC) ; • l’initialisation des caches. Lorsque l’initialisation du noyau et des partitions est terminée, la première partition est exécutée suivant l’ordre défini précédemment. Cette partition exécute son code pendant quelques microsecondes. Puis, à la fin de sa tranche de temps, la partition suivante prend le relais et ainsi de suite jusqu’à l’arrêt du système. Nous pouvons représenter de façon très simple l’ordonnancement des partitions comme suit : Initialisation du noyau et des partitions Partition 0 Partition 1 Partition 2 Partition 3 Partition 4 Fig. 3.1 – Exemple d’ordonnancement avec 5 partitions. Ensuite, la première partition s’exécute et lorsque sa tranche de temps (time slot) est terminée, le noyau opère un changement de partition qui consiste à sauvegarder le contexte de la partition courante. Pour cela, un changement de contexte (context switching) est réalisé. Nous décrivons cette opération dans la sous-section 3.1.2. Le contexte d’une partition correspond au contenu de plusieurs registres : • GPR (General Purpose Register) : les 32 registres généraux (de 32 bits chacun) ; • FPR (Floating-Point Register) : les 32 registres à virgule flottante (de 64 bits chacun) ; • PC (Program Counter) : l’adresse de la prochaine instruction (32 bits) ; • MSR (Machine State Register) : l’état du processeur (dont les privilèges) (32 bits) ; • LR (Link Register) : l’adresse de destination d’une branche30 (32 bits) ; 30Á noter qu’en langage PowerPC, une “branche” ou un “branchement” correspond à un saut d’une instruction à une autre. 58• CTR (Count Register) : ce compteur est décrémenté et testé pendant l’exécution des instructions de branchement (32 bits) ; • XER (Integer Exception Register) : ce registre permet de connaître des informations sur les opérations d’entiers (retenu, débordement) ainsi que le nombre d’octets transmits par une instruction sur les chaînes de caractères (32 bits) ; • CR (Condition Register) : ce registre contient 8 registres de 4 bits permettant d’utiliser jusqu’à 8 comparaisons d’entiers simultanées (32 bits) ; • FPSCR (Floating-Point Status and Control Register) : ce registre contient des informations d’erreurs sur les nombres à virgules flottantes (64 bits). Un contexte de partition contient donc 416 octets qui sont sauvegardés dans la mé- moire utilisateur de la partition (accessible en lecture/écriture) à chaque fin d’exécution de la tranche de temps de la partition puis restaurés à chaque début de tranche de temps. Á noter que le registre MSR qui permet, en autre, de passer du mode superviseur au mode utilisateur n’est pas restauré depuis la mémoire comme les autres mais défini statiquement (afin d’interdire à la partition ayant un accès sur cette zone de modifier ses privilèges lors de la prochaine restauration de contexte). 3.1.1 Hypothèses concernant la partition malveillante Comme pour les autres applications, les règles de partitionnement spatial et temporel sont appliquées. La partition non critique depuis laquelle nous allons mener nos attaques s’exécute donc périodiquement comme toutes les autres applications, pendant 1.5 millisecondes sur les 5 millisecondes disponibles (durée correspondant à un cycle d’exécution de toutes les partitions). Elle est exécutée en dernière position (7ème position). Pour le partitionnement spatial, nous avons configuré la partition pour utiliser une zone de 1Mo de données en lecture/écriture et 1Mo d’instructions en lecture/exécution et aucun autre accès à la mémoire. Ces zones ne sont pas en conflit avec d’autres zones (les zones ne se chevauchent pas) pour éviter de donner des accès à d’autres applications. Pour notre application non critique malveillante, nous utilisons les mêmes privilèges que les autres applications, à savoir un mode utilisateur qui est restreint sur certaines instructions privilégiées (contrairement au mode superviseur). En ce qui concerne la protection mémoire, elle est assurée par la MMU (Memory Management Unit). Ce composant est situé dans le processeur pour contrôler les accès à la mémoire. Une entrée dans la MMU correspond à une entrée dans une TLB (Translation Lookaside Buffer) qui est une table contenant tous les accès aux zones mémoires configurées. Deux entrées sont créées au minimum, une pour les données et une autre pour les instructions. D’autres entrées sont également utilisées pour les accès du noyau. Comme pour les autres applications, l’application malveillante ne peut accéder ni aux périphé- riques ni au noyau en dehors des mécanismes prévus tel que les appels système. La figure 3.2 représente un exemple d’entrées dans la TLB lorsque les partitions 5 et 6 sont exécutées. Dans cet exemple, la partition 6 a un accès de l’adresse 0x0070_0000 à 0x0080_0000 en lecture et écriture pour la modification des données et un autre accès de 0x0080_0000 à 0x0090_0000 en lecture et exécution pour exécuter les instructions. La partition 5 a un 59Memory Management Unit (TLB) Partition5 de 0x0050_0000 à 0x0060_0000 en rw Partition5 de 0x0060_0000 à 0x0070_0000 en rx Partition6 de 0x0070_0000 à 0x0080_0000 en rw Partition6 de 0x0080_0000 à 0x0090_0000 en rx Noyau de 0x0000_0000 à 0x0030_0000 en rx Noyau de 0x0030_0000 à 0x0050_0000 en rw Fig. 3.2 – Exemple d’entrées dans la TLB avec deux partitions et un noyau. accès de 0x0050_0000 à 0x0060_0000 en lecture et écriture pour les données et un autre accès de 0x0060_0000 à 0x0070_0000 en lecture et exécution pour les instructions. Le noyau a lui aussi un accès pour ses données de 0x0030_0000 à 0x0050_0000 en lecture et écriture et de 0x0000_0000 à 0x0030_0000 en lecture et exécution pour ses instructions. Les accès entre le noyau et les applications peuvent paraître similaires dans la TLB mais le noyau s’exécute lui en mode superviseur alors que les applications s’exécutent en mode utilisateur. Si un accès non autorisé est effectué tel qu’un accès en dehors des limites prévues par ces entrées dans la TLB alors une réaction adaptée doit être mise en œuvre, comme par exemple l’arrêt ou le redémarrage de la partition. 3.1.2 Phases d’exécution d’une partition Une partition comprend deux phases lors de son exécution, la première phase est appelée “phase de préparation”, la seconde est la “phase opérationnelle”. La figure 3.3 représente ces deux phases pour trois partitions P0, P1 et P2. PREPARATION P1 OPERATION P1 90µs (t-90)µs P1 (partition en cours d’exécution) PREPARATION P2 P0 P2 OPERATION P0 OPERATION P2 90µs (t-90)µs PREPARATION P1 90µs (t-90)µs Fig. 3.3 – Les deux phases de trois partitions. La phase de préparation dure 90 microsecondes pour chaque partition et est utilisée par le noyau pour exécuter certaines opérations afin que la prochaine partition fonctionne correctement : 1) sauvegarde du contexte de la partition précédente (celle qui a été exécutée avant P1, il s’agit de P0) ; 2) configuration de la MMU en ajoutant de 60nouvelles entrées dans la TLB pour la prochaine partition (P1) et en supprimant les anciennes ; 3) configuration du prochain Global Timer à la durée de la phase opérationnelle (90 - durée totale d’exécution de la partition) microsecondes (ici, il s’agit de la phase opérationnelle de P1). Cette phase se termine par une mise en attente31. Cette attente permet de s’assurer que la durée d’exécution de la phase de préparation est bien 90µs. Lorsque cette phase est terminée, la seconde phase (la phase opérationnelle) débute par la configuration du Global Timer pour la prochaine tranche de temps (ici, celle de la phase de préparation de P2) puis la restauration du contexte de la nouvelle partition courante (ici, P1). Enfin, la première instruction exécutée de la partition est à l’adresse du registre PC (Program Counter) qui vient d’être restauré. Pour mieux comprendre comment l’interruption est émise lors des changements de partition, la suite de cette sous-section traite des interruptions GT (Global Timer). Lorsqu’une interruption de type Global Timer survient, une fonction du noyau est exécutée pour traiter l’interruption. CCR=BCR non CCR == 0 ? CCR-- Générer interruption GT oui Fig. 3.4 – Fonctionnement d’un Global Timer. Sur le schéma 3.4, deux registres sont utilisés pour les interruptions de type Global Timer : CCR pour le Current Counter Register et BCR pour le Base Counter Register. Le premier contient la valeur actuelle du compteur et le second contient la valeur maximale depuis laquelle le compteur sera décrémenté. Un troisième registre est utilisé, le VPR (Vector/ Priority Register) qui permet de définir la fonction qui sera invoquée lorsque 31Cette mise en attente est, en fait, une boucle infinie en mode utilisateur. 61l’interruption surviendra. L’interruption est donc générée une fois que le compteur atteint la valeur zéro, ce qui conduit à exécuter une fonction du noyau (nk_int_vector()). Cette fonction invoque ensuite une autre fonction pour aller configurer le Global Timer pour les partitions suivantes. 3.2 Architecture du P4080 Le P4080 est un calculateur conçu pour être intégré dans des équipements de télé- communications. Il permet d’accélérer le traitement et le filtrage des paquets. Le P4080 respecte l’architecture QorIQ de Freescale. Il contient un processeur PowerPC de type RISC avec 8 cœurs e500mc pouvant atteindre une fréquence de 1.5GHz indépendamment les uns des autres, avec 3 niveaux de caches. Ils peuvent être exécutés de façon symétrique ou asymétrique. Le processeur peut fonctionner dans trois modes de privilèges différents : utilisateur, invité privilégié et hyperviseur. Le mode “utilisateur” (user) est le mode le plus restreint. Il est utilisé pour les applications qui ne doivent pas avoir d’accès privilégiés. Le mode “invité privilégié” (supervisor) est utilisé lorsqu’un moniteur de machines virtuelles est présent. Le mode “hyperviseur” (hypervisor) est le niveau le plus privilégié des trois et permet de gérer l’ensemble du matériel du calculateur grâce à des accès et des instructions non-restreints. La figure 3.5 représente l’architecture du P4080. Fig. 3.5 – Architecture du P4080 (extrait de [Fre11]). 62Sur le haut de la figure 3.5 sont représentés les 8 cœurs avec les 3 niveaux de caches. Ceux-ci sont connectés au bus CoreNet qui permet de relier simplement les périphé- riques avec la mémoire, le processeur et les différentes autres fonctions du P4080. Sur la gauche de la figure sont représentés les périphériques d’entrées/sorties : Security Monitor, SD/MMC, SPI, DUART, I2C, USB, etc. Le P4080 intègre également des PAMUs (Peripheral Access Management Unit) assimilables à des I/OMMUs (pour architecture Intel) pour se protéger contre des accès malveillants depuis un périphérique. La plateforme offre la possibilité d’utiliser un démarrage sécurisé (secure boot). Il est possible de signer numériquement le code qui est exécuté par le processeur pour s’assurer que celui-ci n’a pas été altéré. Un autre composant important est le DPAA (DataPath Acceleration Architecture), qui permet d’accélérer le traitement des paquets Ethernet. D’autres contrôleurs tels que le PCI Express ou le RapidIO sont également utilisables. 3.2.1 Structure des cœurs e500mc Un cœur e500mc exécute des instructions 32 bits et implémente 32 registres généraux ainsi que 32 registres en virgules flottantes 64 bits. Le jeu d’instructions du e500mc est Power ISA version 2.0632 (Performance Optimization With Enhanced RISC Instruction Set Architecture). Le cœur contient un cache L1 de 32 Ko pour les données et 32 Ko pour les instructions. Le cache L2 a une capacité de 128 Ko, il peut contenir à la fois des données et des instructions. Les deux caches sont protégés avec des codes correcteurs d’erreurs. Le e500mc contient une MMU dont l’objectif est de définir des droits d’accès à certaines portions de mémoire. Le e500mc permet également de surveiller et compter des événements tels que les périodes des horloges de processeur, les omissions du cache d’instructions ou du cache de données ou encore les branches mal prédites (mispredicted branches). Les registres de surveillance de performance (Performance Monitor Registers) sont utilisés pour configurer et traquer les opérations de surveillance de performance. La gestion de l’alimentation permet de réduire la consommation d’énergie grâce à trois modes différents d’arrêts pour le cœur, sommeil léger, sommeil profond ou arrêt. 3.2.2 Contrôleur d’interruption Le MPIC (Multicore Programmable Interrupt Controller) est l’unité permettant de contrôler les interruptions sur des architectures multi-cœurs. Elle est également responsable de recevoir les interruptions générées par le matériel depuis différentes sources internes et externes, les classer par priorité et livrer les signaux à la destination appropriée. Le MPIC peut recevoir des interruptions de plusieurs sources : • les signaux externes IRQ ; • les sources d’interruptions internes (jusqu’à 112) ; • les messages partagés entre programmes ; 32https://www.power.org/wp-content/uploads/2012/07/PowerISA_V2.06B_V2_PUBLIC.pdf 63• interruptions générées dans le MPIC (Global Timer, InterProcessor Interrupt). Les interruptions peuvent être routées vers n’importe lequel des 8 cœurs. Il est également possible de faire du multicast pour une diffusion simultanée sur plusieurs cœurs. Le MPIC gère également des compteurs : les Global Timers. Ces compteurs permettent de générer une interruption lorsqu’un compteur décrémental (horloge) atteint la valeur zéro. Il suffit pour cela de lui donner une valeur correspondant à la durée souhaitée à attendre (registre GTBCRB0) puis de préciser quelle fonction appeler (registre GTVPRB0) lorsque la valeur atteint zéro. 3.2.3 DataPath Acceleration Architecture (DPAA) Le DPAA permet de réduire les surcharges logicielles et d’accélérer le traitement des paquets Ethernet. Il est composé de cinq éléments : le Security and Encryption Engine (SEC), Queue Manager (QMan), Pattern-Matching Engine (PME), Buffer Manager (BMan) et le Frame Manager (FMan). Ces éléments sont représentés dans la figure 3.6. Frame Manager Fig. 3.6 – QorIQ DataPath Acceleration Architecture. Le QMan est le composant qui permet le partage simplifié des interfaces réseau et des accélérateurs matériel par les cœurs. Il fournit aussi les moyens de partager des données entre cœurs pour être capable de paralléliser certaines tâches. La première fonction du BMan est de réduire la surcharge de traitement par le logiciel grâce à l’utilisation de groupes de tampons (pools of buffers). Ces groupes de tampons sont mis à disposition des autres composants matériels et sont alloués et libérés par le BMan. Le FMan permet de réaliser des analyses et classification configurables de trames entrantes avec pour but de sélectionner la file de trames d’entrée appropriée pour expédier le traitement vers un CPU ou un groupe de CPU. 64Le SEC est un moteur d’accélération cryptographique. Il implémente les algorithmes de chiffrement par bloc, par flux, de hachage, asymétriques, générateur de nombres aléatoires et vérificateur d’intégrité d’exécution. Le PME est une fonctionnalité de correspondance de modèles (pattern-matching) haute-performance permettant de rechercher des modèles dans des paquets réseau. 3.2.4 Démarrage sécurisé Le P4080 intègre plusieurs mécanismes de sécurité : le bit de non-exécution (X bit de la MMU), l’hyperviseur, les PAMUs, le Security Engine, le contrôleur de débogage sécurisé, la détection d’un appareil de sécurité défaillant, le Pre Boot Loader (PBL), le fusible de sécurité (FSP), le moniteur de sécurité. Le démarrage sécurisé utilise une clé publique RSA pour déchiffrer une empreinte SHA-256 signée et la comparer à une empreinte calculée sur la même portion de code. Ce code est en fait une image qui contient des instructions exécutables, des informations de configuration et une entête du fichier de séquence de commande. Il peut être en clair ou chiffré dans la mémoire. C’est le développeur qui décide du chiffrement ou non et du lieu où la clé privée RSA est stockée en mémoire. Elle ne doit en aucun cas être disponible à un tiers pour éviter la possibilité de générer une image alternative, ce qui rendrait inutile le démarrage sécurisé. 3.3 Présentation de la plateforme Notre plateforme expérimentale comprend des éléments logiciels (le noyau temps-réel et l’IDE Codewarrior) et matériels (le P4080 et la sonde JTAG). Le calculateur QorIQ P4080 de Freescale a été choisi par Airbus car son processeur de type PowerPC et ses performances élevées permettent d’assurer une forte compatibilité avec les autres logiciels développés dans l’entreprise. Il permet également de proposer de nouvelles technologies (démarrage sécurisé, utilisation de plusieurs cœurs, etc.). Le noyau temps-réel est confi- guré statiquement (allocation de la mémoire pendant la compilation) ce qui permet de satisfaire la contrainte du déterminisme, et il n’y a aucune allocation de la mémoire pendant l’exécution du noyau. Cette configuration est réalisée via des fichiers dédiés. Un outil de génération automatique de code est utilisé pour générer le code du noyau et des interfaces entre le noyau et les applications à partir de la configuration. Cette section est consacrée à la présentation détaillée de cette plateforme, en particulier, des mécanismes que nous avons utilisés pour pouvoir observer le comportement du noyau et des applications ainsi que la configuration de ces mécanismes. Cette observation est principalement basée sur l’utilisation d’une sonde JTAG et d’un logiciel approprié. La figure 3.7 propose une vue globale de notre plateforme d’expérimentation. 65Freescale QorIQ P4080 Sonde JTAG USB Codewarrior Ordinateur de pilotage d'expérimentations Fig. 3.7 – La plateforme d’expérimentation. 3.3.1 Observation du noyau et des applications Pour notre étude, nous avons utilisé une version datant de 2010 du noyau expérimental d’Airbus. Cette version est actuellement en cours de développement mais elle permet néanmoins d’utiliser des fonctions du P4080 (notamment le MPIC et la MMU) avec le noyau et les partitions (séparation de la mémoire et décomposition en slots de temps). Pour être capable de tester efficacement le noyau et les applications, nous avons utilisé le logiciel Codewarrior (version 10.1.1). Il permet en effet de charger des applications sur une cible, de configurer du matériel, de contrôler et d’observer cette cible grâce à une sonde JTAG. La sonde JTAG (voir figure 3.8) est l’interface entre le P4080 et le PC exécutant Codewarrior, elle permet de convertir les signaux de la carte en information compré- hensible par le logiciel. Elle peut être connectée par le développeur à un ordinateur sur un port USB 2.0 ou un port Gigabit (disponibles par Freescale). Le second est bien sûr beaucoup plus rapide (de 100Mbits/s à 1Gbits/s) que le premier (quelques dizaines de Mbits/s) mais requiert une connexion au réseau local ce qui peut être une contrainte car cela signifie que la sonde est directement accessible à n’importe quel personne (honnête ou non) qui connaît l’adresse IP de la sonde33. Pour nos expérimentations, nous avons utilisé la sonde JTAG avec un port USB. Le port JTAG se situe sur la carte mère du P4080. La sonde JTAG est connectée à ce port et à un ordinateur disposant de Codewarrior à l’autre extrémité. Comme pour tout programme de débogage, l’exécution peut se faire en mode pas-à-pas ou en mode continu jusqu’à ce que le programme rencontre un point d’arrêt. Cette sonde permet par exemple de débugger le code en cache, ROM, RAM et dans la mémoire flash, d’afficher et de modifier la mémoire sur la cible ou encore d’examiner 33Cette méthode est donc plutôt utilisée pour un ensemble de développeur ayant accès à la même plateforme. 66Fig. 3.8 – Sonde JTAG de Freescale. et de modifier n’importe quel registre du processeur. Il supporte également toutes les vitesses des cœurs du processeur. L’avantage avec le port USB est qu’il ne nécessite aucune configuration de la sonde contrairement à l’interface réseau Gigabit qui nécessite forcément l’attribution d’une adresse IP pour être accessible sur le réseau. Codewarrior détecte automatiquement le branchement de la sonde USB. Il est aussi possible de brancher plusieurs sondes USB sur le même ordinateur et d’en spécifier une seule à utiliser dans Codewarrior (grâce à son numéro de série). 3.3.2 Configuration de la plateforme d’expérimentation La configuration de la plateforme d’expérimentation est basée sur le paramétrage du P4080 lui-même, sur l’installation et la paramétrage des composants logiciels du système avionique (le noyau et les applications), ainsi que sur le paramétrage des outils de contrôle et d’observation (la sonde JTAG et l’application Codewarrior). Nous présentons ces différentes configurations dans les sous-sections suivantes. 3.3.2.1 Configuration de Codewarrior et de la sonde JTAG USB L’interface graphique de Codewarrior offre plusieurs vues : le code source (C ou assembleur), la mémoire désassemblée, les breakpoints et les commandes de debug (pour continuer l’exécution jusqu’au prochain point d’arrêt ou faire une pause). La figure suivante 3.9 est une capture d’écran de Codewarrior version 10.1.1. De nombreuses fonctionnalités sont offertes par ce logiciel. La plus intéressante est probablement le debugger shell qui nous permet de lire des registres et de la mémoire, de gérer les points d’arrêts et de créer des scripts. Codewarrior offre la possibilité de configurer un ou plusieurs cœurs du processeur. 67Fig. 3.9 – Capture d’écran du logiciel IDE Codewarrior de Freescale. Nous n’utilisons qu’un seul cœur pour exécuter notre code pour nous placer dans les mêmes conditions que celles d’Airbus. Ensuite, la configuration du cœur lui-même s’effectue au démarrage du noyau. Cette initialisation est réalisée via un fichier de configuration. Ce fichier contient la configuration de plusieurs éléments importants du P4080 : les fenêtres d’accès local (Local Access Window ou LAW), la DDR et ajoute une entrée dans la MMU. Un ensemble de 32 LAWs34 peut être configuré. Un LAW permet d’assigner une zone d’adresses à un périphérique. Pour notre plateforme, cinq de ces LAWs sont configurés pour Codewarrior : pour l’utilisation de la DDR1 et DDR2, PCI Express 3, et deux eLBC (ex : SRAM, ZBT RAM ou EEPROM). La taille de ces zones, l’adresse de base, la cible de la transaction sont précisées dans ce fichier de configuration. La sonde JTAG USB ne nécessite aucune configuration particulière. Il suffit de la brancher à l’ordinateur pour qu’elle soit directement reconnue. 3.3.2.2 Configuration du P4080 Avant d’utiliser la plateforme, une configuration logicielle et matérielle s’impose. La configuration matérielle est réalisée grâce à des cavaliers (les SW35) présents sur la carte mère du P4080. Ils sont au nombre de 80. Nous pouvons modifier les paramètres sui- 34Une zone peut être définie sur 4Ko au minimum ou 64Go au maximum. 35SWitches. 68vants : la vitesse de l’horloge interne (de 66.666 MHz à 133.333 MHz), le voltage des cœurs et de la plateforme ou encore les protections en écriture des configurations RCW. La configuration logicielle du P4080 s’effectue en deux temps. Tout d’abord, un fichier (le PBL36) est chargé depuis la mémoire flash pendant le démarrage notamment pour configurer la fréquence du processeur. Ensuite, le noyau configure plusieurs éléments : • les permissions de la zone de mémoire (MMU) ; • le compteur de temps (Time Base) ; • les interruptions, qui sont initialisées (MPIC) ; • les caches, qui sont initialisés. Dans les premières instructions de l’exécution du code noyau, quatre nouvelles zones de mémoire sont ajoutées dans la MMU : le CCSR37 sur 16 Mo (nous y reviendrons en détail plus tard), le code noyau sur 1 Mo, les données du noyau sur 1 Mo puis les données d’instrumentation du noyau sur 1 Mo. Le compteur de temps est aussi activé (car il est désactivé par défaut) dans les premières instructions pour être capable de mesurer les durées des exécutions ce qui nous est nécessaire pour nos expérimentations. Les interruptions sont également utilisées pour permettre de gérer efficacement les évé- nements et les erreurs sur la plateforme. Les IVORs (Interrupt Vector Offset Registers) permettent par exemple de définir les actions à entreprendre (adresse des instructions à exécuter) lorsqu’un événement survient (erreur de données, erreur d’alignement, erreur de données TLB, appel-système, etc.). Les caches sont utilisés pour accélérer la vitesse de transmission des données et des instructions entre le processeur et la mémoire principale. 3.3.2.3 Configuration du noyau La configuration du noyau est réalisée par l’intermédiaire de plusieurs fichiers textes. Ces fichiers sont utilisés lors de la génération du noyau. Dans ces fichiers de configuration, nous retrouvons notamment la durée d’un cycle d’exécution, le nombre d’applications qui sont exécutées par le noyau, la durée maximale d’un appel d’une fonction distante (IPC) ou encore les actions à entreprendre (arrêt, redémarrage ou arrêt après trois redémarrages) lorsqu’une erreur survient. 3.3.2.4 Configuration des applications La configuration des applications se fait également par des fichiers modifiables avant la compilation. Une application est composée d’une ou plusieurs partitions (voir le chapitre 1 sur les systèmes avioniques pour plus de détails). Chaque partition a donc une tranche de temps qui lui est réservée ainsi qu’un espace mémoire limité. Ces paramètres sont différents de ceux du noyau car celui-ci n’a pas de tranches de temps allouées. Il y a nécessairement la durée d’exécution de la partition ainsi que les zones de mémoire accessibles depuis la partition. Il est aussi nécessaire de préciser à quel moment (décalage en microsecondes) la partition doit commencer. 36Pre-Boot Loader 37Configuration, Control and Status Registers. 69Après la présentation des différents composants de notre plateforme d’expérimentation, la section suivante est consacrée à la présentation détaillée de plusieurs attaques que nous avons pu réaliser sur notre plate-forme, cela concerne les attaques : • ciblant la gestion de la mémoire, • ciblant les communications, • ciblant la gestion du temps, • ciblant les mécanismes de tolérance aux fautes. 3.4 Attaques ciblant la gestion de la mémoire Une corruption de la gestion de la mémoire peut permettre à une partition malveillante d’accéder à des données sensibles utilisées par le noyau ou par d’autres partitions. Nous décrivons dans l’exemple suivant comment provoquer une attaque par dénide-service en abusant la gestion de la mémoire. Comme nous l’avons déjà indiqué, la plateforme P4080 est configurée en partie grâce à la zone Configuration, Control, and Status Registers (CCSR). Cette zone de 16 Mo contient la configuration de tous les composants matériels (MPIC, périphériques, contrôleurs réseau, alimentation, etc.). Or, nous avons découvert, en analysant le code source, que dans la version actuelle du système en notre possession, les accès en lecture et écriture à cette zone sont positionnés pour le noyau mais également pour les partitions. Cette configuration a été choisie délibérément pour que les différentes partitions puissent utiliser le contrôleur réseau AFDX sans utiliser de pilote partagé. Cette configuration est particulièrement risquée car cela implique que les partitions peuvent modifier la configuration de tous les composants matériels de la plateforme. Par exemple, avec cette configuration, une partition malveillante est parfaitement capable de remplir les registres de la zone CCSR avec des données aléatoires. Pour nos expé- rimentations, nous avons choisi d’injecter, depuis la partition malveillante, des valeurs particulières dans cette zone afin de provoquer un déni-de-service. A titre d’illustration, un exemple de déni-de-service est présenté dans la prochaine sous-section, en utilisant des registres du CCSR et visant plus spécialement le Security Engine (SEC du DPAA) du P4080. 3.4.1 Attaques ciblant le Security Engine Comme nous l’avons déjà vu précédemment, le SEC permet d’utiliser des mécanismes de chiffrement tels que AES, DES, RSA, etc., au sein du P4080, que ce soit pour le traitement des paquets Ethernet ou pour un autre usage. Il est géré par le Security Monitor qui est en charge de vérifier les erreurs du système et contrôler les clés cryptographiques utilisées pour le démarrage sécurisé. Par défaut, le gestionnaire de sécurité (security monitor) est dans un état non-secure, c’est-à-dire que les clés cryptographiques ne sont pas initialisées. La figure 3.10 montre les différents états possibles du gestionnaire de sécurité et les relations entre eux. 70Fig. 3.10 – Diagramme des états du SEC [Fre11]. Le choix du démarrage sécurisé ou non se fait grâce au bit ITS (Intent To Secure) du registre SFP_OSPR (OEM Security Policy Register) des registres Security Fuse Processor (SFP). Pendant le démarrage du système, l’état du gestionnaire de sécurité passe successivement de init à check puis à non-secure si le bit ITS n’est pas positionné, ou secure si ce bit est positionné. Si une erreur logicielle est détectée lors du démarrage du système, le gestionnaire de sécurité entre dans un état “failed” ce qui bloque l’utilisation des clés cryptographiques et les positionne à zéro. Ce type d’erreur se manifeste par le positionnement à 1 du bit SW_FSV du registre SM_HP (adresse 0xFE314004). Si, à partir de cet état, une erreur matérielle est détectée, le système redémarre. Cette erreur se ma- 71nifeste par le positionnement à 1 du bit HAC_EN du même registre SM_HP (tel qu’indiqué dans la spécification du P4080 [Fre11]). Ce registre est positionné dans le CCSR, zone mémoire dont les accès en lecture et écriture sont autorisés pour toutes les partitions, comme nous l’avons vu précédemment. En conséquence, si une partition malveillante modifie intentionnellement ces deux bits et les positionne à 1, la plateforme redémarre. Nous avons ainsi provoqué ce déni de service en modifiant ces 2 bits. Un exemple similaire peut être réalisé en utilisant le Run Control/Power Management (RCPM). Nous le présentons dans la sous-section suivante. 3.4.2 Attaques ciblant le Run Control/Power Management Le RCPM (Run Control/Power Management) est une autre zone du CCSR. Le RCPM gère l’alimentation des cœurs et des périphériques. Deux modes de faible alimentation sont possibles pour un cœur. Il s’agit des modes : assoupi (dozing) et endormi (napping). Le mode assoupi permet de suspendre l’exécution d’instructions, sans arrê- ter le fonctionnement des caches L1 et L2. Dans le mode endormi, toutes les horloges internes sont arrêtées et les caches L1/L2 ne sont plus fonctionnels. Deux registres sont utilisés pour passer dans ces modes. Le registre RCPM_CDOZCR (Core Doze Control Register) permet de passer en mode core dozing et le registre RCPM_CNAPCR (Core Nap Control Register) permet de passer en mode core napping. Dans la mesure où l’accès en écriture est autorisé pour toutes les partitions dans le CCSR (et donc dans la zone RCPM), il est donc possible pour une partition malveillante de modifier ces registres et donc de configurer les modes d’alimentation des cœurs, et ainsi de provoquer un déni-de-service en les positionnant en mode assoupi ou endormi. 3.5 Attaques ciblant les communications Le noyau expérimental fourni par Airbus autorise plusieurs types de communications : une communication entre modules via le réseau AFDX (Avionics Full DupleX) et une communication entre partitions d’un même module via les IPC. 3.5.1 Attaques ciblant les communications AFDX Pour communiquer entre les modules et échanger des informations, les systèmes avioniques utilisent principalement le réseau AFDX. Celui-ci est déterministe et basé sur Ethernet. Ses principaux avantages sont sa rapidité et sa simplicité (pour l’accès au ré- seau et l’évolution de l’architecture). Pour cela, le réseau utilise des liens virtuels (Virtual Links). Un Virtual Link (VL) caractérise un flot de données entre un émetteur et un ou plusieurs destinataires ; ce flot de données doit respecter une bande passante défi- nie par configuration. L’identifiant du VL est contenu dans l’adresse MAC destination. D’autres informations comme le numéro de partition, le numéro de l’hôte et du réseau sont eux contenus dans l’adresse IP source, qui, même si elle est codée sur la même taille qu’une adresse IP usuelle, contient des informations légèrement différentes (le numéro de partition). Deux types de ports AFDX sont utilisés : 72• Service Access Points (SAP) : les ports SAP ont été créés pour répondre à un besoin Ethernet “classique” pour les applications du monde ouvert (TFTP notamment). • AFDX communication : chaque port implémente un service d’envoi de données et deux services de réception (en mode sampling et queuing) • mode Sampling : seule la dernière valeur est présentée à l’application par le driver. • mode Queuing : toutes les valeurs sont présentées à l’application par le driver. La configuration de AFDX se fait avant la compilation des partitions car elle est statique et tous les paramètres doivent être définis avant exécution. Nous allons détailler comment réaliser cette configuration AFDX. 3.5.1.1 Configuration des tables AFDX La configuration des tables AFDX se fait grâce à deux fichiers contenant deux tableaux avec tous les paramètres nécessaires : VL, BAG38 , Max frame size, redondance, numéro de réseau, etc. Un outil codé en Perl appelé Matrix (produit et mis à notre disposition par Airbus) utilise ces fichiers pour générer du code C qui est ensuite compilé pour obtenir le fichier ELF exécutable correspondant au pilote AFDX pour la partition. La figure 3.11 représente la chaîne de compilation pour une partition utilisant l’AFDX. Il est nécessaire d’utiliser l’outil Matrix pour générer des fichiers C, ensuite, nous utilisons le compilateur GCC pour les compiler avec le programme principal. Matrix Fichiers ".c" générés qui contiennent la configuration du driver Compilation du driver (application 0) fichiers ".c" *_extrait_isdb.csv *_ports_partition.csv *_conf_tc.c *_ports_emission.c *_ports_reception.c *_partition_0_ports_reception.c *_partition_0_ports_emission.c *_partition_1_ports_reception.c *_partition_1_ports_emission.c *_partition_2_ports_reception.c *_partition_2_ports_emission.c *_vl_reception.c GCC Exécution de Matrix Configuration des tables test0_0.elf partition0.c end_system_controller.c ... Fig. 3.11 – Chaîne de compilation pour une partition utilisant AFDX. Pour réaliser nos tests AFDX, nous avons utilisé une carte AFDX d’Airbus, connectée en PCI avec un pont PCI vers PCI Express. Cette carte est par défaut “ouverte” car elle est destinée à réaliser des tests. C’est la raison pour laquelle nous avons détecté certains problèmes évidents de sécurité comme la gestion des accès DMA par exemple. Cependant nous avons également identifié d’autres vulnérabilités qui ne sont pas uniquement liées à 38Le Bandwidth Allocation Gap (BAG) représente le délai minimum entre 2 trames consécutives d’un VL (de 1ms à 128ms par valeurs multiples de 2). 73cette configuration en mode test. Nous présentons l’ensemble de ces vulnérabilités dans la suite. 3.5.1.2 Vulnérabilités détectées La première vulnérabilité découverte est liée à la configuration des accès DMA, puisqu’ils sont autorisés en lecture et écriture de façon illimitée à toute la mémoire (l’envoi et la réception de données nécessite en effet de réaliser des accès DMA, comme il est coutume avec une carte Ethernet classique). Cette configuration est réalisée dans le CCSR, et comme nous l’avons vu précédemment, la gestion des droits d’accès au CCSR fait que toute partition peut modifier tous les registres présents dans cette zone. Une partition malveillante peut donc tout à fait modifier la gestion des accès DMA en accédant en écriture au CCSR. Il lui est donc tout à fait possible d’envoyer des commandes à la carte AFDX sans aucun contrôle préalable, et de faire n’importe quelle lecture ou écriture sur toute la mémoire du système. Une seconde vulnérabilité concerne l’accès à certaines variables globales utilisées pour les communications AFDX. Ces variables sont créées dans une zone de mémoire partagée entre les applications qui effectuent des communications AFDX, et donc modifiables par n’importe laquelle de ces partitions. En conséquence, une partition malveillante qui utilise le réseau AFDX a donc accès à cette zone de mémoire et peut donc modifier ces variables. Nous avons ainsi pu montrer qu’il est possible de bloquer depuis une partition malveillante les envois AFDX d’autres partitions. La troisième vulnérabilité concerne une variable appelée AFDX_PARTITION_ID qui permet d’identifier une partition lors de l’envoi et la réception de paquets. Cette variable est locale à chaque partition et est stockée dans son espace mémoire dédié. Mais on peut imaginer qu’une partition malveillante modifie cette variable dans le but de recevoir des données qui ne lui sont pas destinées ou de se faire passer pour une autre partition lorsqu’elle envoie des données. Si une partition malveillante modifie cette variable en lui affectant un numéro de partition invalide, cela provoque une erreur. Si elle utilise un numéro valide d’une autre partition, alors le paquet émis par la partition malveillante sera considéré émis par cette autre partition. Lors de la réception de paquet, il est également possible à une application malveillante de modifier cette variable pour tenter de recevoir des paquets destinées à une autre partition mais la propriété de déterminisme du réseau AFDX fait qu’en pratique, il est impossible que des données soient reçues à un instant t pour une partition i alors que c’est la partition j qui est en cours d’exécution. Nous considérons donc que cette vulnérabilité est beaucoup plus difficile à exploiter en réception. Dans le cadre de nos expérimentations, nous avons effectivement réussi à modifier cette variable au moment de l’envoi et donc à créer une partition qui émet des paquets en se faisant passer pour une autre partition. La quatrième vulnérabilité concerne les partitions Data Loader et Flash Manager qui permettent de télécharger et de recopier des données (en particulier de mises à jour). Dans la version actuelle de ces partitions, la Data Loader ne fait aucune vérification sur les données envoyées au Flash Manager. Si par conséquent, ces données contiennent des informations erronées concernant des données de configuration des partitions ou 74des coeurs du processeur par exemple, celles-ci seront mises à jour et pourront considérablement modifier le comportement global du système jusqu’à le rendre totalement inopérant. Cette dernière vulnérabilité a été découverte grâce à l’analyse de code source des applications mais elle n’a pas donné lieu à des expérimentations. 3.5.2 Attaques ciblant les IPC Notre noyau temps-réel expérimental implémente les IPC (Inter-Process Communications) qui permettent à une partition (dite locale dans la terminologie IPC) d’appeler une fonction fournie par une autre partition (dite distante). Pour cela, (1) la partition locale exécute un appel-système pour que le noyau exécute une commutation de contexte ; (2) le noyau change le contexte de la partition locale pour le contexte de la partition distante ; (3) la fonction distante est exécutée pendant 27 microsecondes puis exécute un appel-système pour que le noyau exécute une commutation de contexte ; (4) le noyau recharge le contexte de la partition locale et (5) la partition locale continue à être exécutée. La figure 3.12 représente un exemple de communication IPC. Application0 (code user) 1) image_app6_part0_u_call_EP() { r10 = 0 r9 = 7 syscall() } 9) image_app0_part0_u_enter_part_ipc { ENTRYPOINT() r9 = 7 syscall() } 13) image_app6_part0_return_from_ipc() { rfi } 5) image_app0_enter_ipc() { if (r10 != 0): goto bad_ipc } 6) image_app0_enter_ipc_part_part0() 7) image_app0_part0_enter_part_ipc() 8) image_app0_part0_perform_enter_ipc() { address_ipc_return <- 0xB4740 rfi } 10) nk_sc_vector() 11) image_app0_part0_syscall() 12) image_app0_part0_syscall_ipc_return() { goto address_ipc_return } Kernel (code noyau) 2) nk_sc_vector() 3) image_app6_part0_syscall() 4) image_app6_part0_syscall_ipc_enter_aapp0() Application6 (code user) Fig. 3.12 – Exemple de communication IPC 75Deux appels système sont créés pour la gestion des IPC : un appel-système est créé dans la partition locale pour appeler la fonction distante et un autre dans la partition distante pour revenir dans la partition locale. Ces appels système permettent de donner la main au noyau car c’est lui seul qui a les privilèges suffisants pour passer d’une partition à une autre (modification de contexte). Deux registres généraux (GPR9 et GPR10) sont initialisés avant l’appel-système pour appeler la fonction distante. GPR9 permet de préciser le numéro de l’appel-système et GPR10 est utilisé par le noyau pour une action non-définie car toujours en cours de développement. L’application 6 correspond à la partition locale et l’application 0 correspond à la partition distante. Nous allons détailler maintenant trois problèmes d’implémentations du noyau qui peuvent conduire à des vulnérabilités (en particulier des dénis-de-service) si la partition locale ou distante n’agit pas exactement comme elle est supposée le faire. 3.5.2.1 Modification de l’ordre des appels-système Une première tentative d’attaque consiste pour la partition distance à exécuter l’appel-système lui permettant de revenir dans la partition locale alors que la partition locale n’a pas encore effectué d’IPC en invoquant elle-même son propre appel système. La figure 3.13 représente cet exemple. Application0 (code user) 1) image_app0_part0_u_enter_part_ipc { ENTRYPOINT() r9 = 7 syscall() } x) image_app6_part0_return_from_ipc() { rfi } 2) nk_sc_vector() 3) image_app0_part0_syscall() 4) image_app0_part0_syscall_ipc_return() { blr address_ipc_return (0x00000000) } Kernel (code noyau) Application6 (code user) Fig. 3.13 – Appel-système depuis l’Application 0 Dans ce cas, le code noyau qui vérifie la source de l’appel-système va provoquer une erreur de type ITLB (Instruction Translation Lookaside Buffer) en exécutant l’instruction à l’adresse 0x00000000 qui se situe dans un espace mémoire privilégié (et qui provoque un déni-de-service). Là encore, c’est l’implémentation qui n’est pas complète et qui ne devrait pas pointer vers cette adresse. 763.5.2.2 Interruption dans la fonction distante Dans cette seconde attaque, nous avons voulu observer le comportement du noyau lorsque la durée accordée à l’exécution de l’IPC (27 microsecondes) se termine avant que toute la fonction n’ait été exécutée. Pour cela, nous avons défini une boucle infinie dans la fonction distante pour qu’une interruption de type Global Timer puisse provoquer le retour dans le noyau au lieu de l’appel-système. Dans ce cas, l’exécution continue dans une boucle infinie (figure 3.14), l’implémentation actuelle ne l’a pas pris en compte. Application0 (code user) 1) image_app6_part0_u_call_EP() { r10 = 0 r9 = 7 syscall() } 9) image_app0_part0_u_enter_part_ipc { ENTRYPOINT() { while(1) {} } r9 = 7 syscall() } 5) image_app0_enter_ipc() { if (r10 != 0): goto bad_ipc } 6) image_app0_enter_ipc_part_part0() 7) image_app0_part0_enter_part_ipc() 8) image_app0_part0_perform_enter_ipc() { address_ipc_return <- 0xB4740 rfi } Kernel (code noyau) 2) nk_sc_vector() 3) image_app6_part0_syscall() 4) image_app6_part0_syscall_ipc_enter_aapp0() Application6 (code user) 10) nk_int_vector() 11) nk_slice_end() 12) image_app0_part0_leave() { if address_ipc_return != 0: image_app0_part0_spurious() } 13) image_app0_part0_spurious() { b . } Fig. 3.14 – Boucle infinie l’Application 0 3.5.2.3 Modification du registre GPR10 Cette dernière attaque concerne la modification intentionnelle du registre GPR10 dans le but de rendre le système indisponible. En effet, ce registre GPR10 est initialisé à la valeur 0 dans le code de la partition (et donc en mode utilisateur) avant de réaliser l’appel-système pour appeler la fonction distante. Il est ensuite comparé à 0 dans le code 77noyau. Si une valeur différente est présente, alors une boucle infinie est exécutée sinon le code poursuit son exécution. Si la partition locale est malveillante alors elle peut positionner ce registre GPR10 à une valeur différente de 0 pour que le noyau rentre dans la boucle infinie. Dès qu’une boucle infinie dans le noyau est exécutée, il n’est plus possible de sortir de cette boucle par un autre moyen que le redémarrage ou une interruption NMI car le noyau ne peut pas être interrompu par une interruption “classique”. La présence de cette boucle à cet endroit ne devrait pas être possible, il s’agissait en fait d’une implémentation incomplète car le noyau est en cours de développement. Même si globalement ces résultats d’expérimentations sont principalement dues au fait que le noyau est en cours de développement, elles ont permis de mettre en évidence des comportements qui n’avaient pas été considérés comme possibles tant que l’on envisage pas des actes malveillants. Modifier volontairement le séquencement d’un IPC ou inclure une boucle infinie dans son propre code sont des comportements malveillants qu’il est donc important de prendre en compte lors du développement, sous réserve de provoquer des dénis-de-service du système. 3.6 Attaques ciblant la gestion du temps Cette section est consacrée à la présentation des expérimentations que nous avons menées pour perturber la durée d’exécution d’une partition, tout d’abord en utilisant les interruptions, ensuite en modifiant la configuration d’une partition. 3.6.1 Première attaque : utilisation des interruptions La durée d’exécution des tranches de temps pour chaque partition est basée sur le calcul du WCET (Worst Case Execution Time) qui est stocké dans les fichiers de confi- guration de chaque partition. Le MPIC fournit la gestion des interruptions multiprocesseurs et est responsable d’envoyer des interruptions générées par le matériel (internes et externes), leur associer des priorités, et les envoyer aux cœurs appropriés. Le principe de l’attaque à laquelle nous avons pensé consiste à essayer de faire en sorte que l’exécution d’une partition malveillante déborde de sa tranche de temps allouée, de façon à réduire le temps d’exécution de la partition suivante. Si cette partition est une partition critique, cela peut donc avoir un impact sérieux. Cette attaque nécessite l’utilisation d’une interruption, ainsi que nous le présentons dans la sous-section suivante. 3.6.1.1 Réalisation du programme Pour réaliser le programme de notre propre partition malveillante, nous avons créé une boucle et ajusté une valeur de sortie de boucle pour provoquer une interruption au plus proche de la fin de la durée d’exécution. Cette interruption est une instruction 78illégale (instruction rfi39 dans notre cas) qui provoque un retour dans le noyau pour être traité. Notre objectif est ainsi de pouvoir consommer du temps CPU dans le noyau (qui est non interruptible) grâce à cette interruption déclenchée au dernier moment dans notre partition malveillante, et ainsi voler du temps CPU à la partition suivante. 3.6.1.2 Instrumentation du noyau Nous avons modifié le noyau pour être capable de sauvegarder en mémoire les durées d’exécution des partitions P6 et P7 (phase de préparation de P7 et phases opérationnelles de P6 et P7) : les temps T0, T1, T2 et T3. La figure 3.15 représente ces durées pour chaque partition (la phase de préparation est notée W et la phase opérationnelle est notée P suivi du numéro de la partition) : P3 P4 P1 P5 P2 P0 P6 P7 T0 T1 T2 T3 Fig. 3.15 – Mesures des temps sur un cycle (5 ms). Nous sauvegardons ces 4 temps40 pendant 1024 cycles puis nous analysons les résultats. A noter que ces temps correspondent aux réelles durées d’exécution des différentes phases et non au compteur du Global Timer qui déclenchent les interruptions une fois qu’il vaut zéro. Pour cela, nous avons réalisé un programme en Python qui, à partir de ce tableau de 1024 cycles, permet de calculer toutes les durées d’exécution de la partition P6 et P7 ainsi que celle de la phase de préparation de la partition P7. 3.6.1.3 Résultats obtenus Nous prenons comme exemple deux partitions P6 (malicieuse) et P7 (non-malicieuse) avec leurs phases de préparation associées W6 et W7. Les durées des phases de préparation sont fixées à 90 microsecondes pour toutes les partitions et les durées des phases opérationnelles sont fixées à 1410 microsecondes (soit un total de 1500 microsecondes pour chacune des deux partitions). La figure 3.16 représente les durées d’exécutions des différentes phases de ces deux partitions ainsi que les compteurs CCR (Current Count Register) du MPIC dont la valeur décrémente jusqu’à la valeur 0. 39L’instruction return from interrupt (rfi) permet de retourner en mode utilisateur lorsque l’on est dans le noyau et doit donc être seulement utilisé dans le noyau. 40Utilisation des registres TB (Time Base) et TBL (Time Base Lower). 79P6 P7 T0 T1 T2 T3 90 1410 1410 90 Durée d'exécution Compteur (CCR) Fig. 3.16 – Comportement normal des deux partitions. Une attaque sur la gestion du temps consiste pour une partition non-critique malveillante, à être capable de réduire la durée d’exécution d’une partition critique. Comme nous l’avons expliqué auparavant, le principe consiste donc, pour une partition malveillante, à augmenter sa tranche de temps grâce au déclenchement volontaire, à la fin de sa tranche de temps, d’interruptions qui sont gérées par le noyau (qui ne peut être interrompu) (voir figure 3.17). P6 P7 T0 T1 T2 T3 W7 90 1410 1410 90 Durée d'exécution Compteur (CCR) Fig. 3.17 – Dépassement de P6. Lorsque la partition P6 enclenche une exception à la fin de sa tranche de temps, nous avons été capable d’augmenter sa durée de 6 microsecondes et donc de réduire la durée de la partition P7 de 6 microsecondes. Pour cette expérience, les conséquences n’ont pas été significatives car la marge de sécurité prise par le noyau est suffisante mais dans d’autres contextes, il est tout à fait possible d’imaginer que cette réduction puisse conduire à défaillance. 803.6.2 Seconde attaque : modification de la configuration d’une partition Un autre type d’attaque a été envisagé, même s’il est beaucoup plus difficile à réaliser en pratique. Il consiste à essayer de faire en sorte que la partition P7 nécessite un temps de préparation supérieur à la durée de 90µs prévu statiquement. Pour cela, nous avons considéré une partition P7 qui utilise énormément de mémoire et donc d’entrées dans la MMU. Dans ce cas, la phase de préparation, durant laquelle notamment ces entrées MMU sont préparées, peut durer plus de 90µs. Nous avons ainsi ajouté volontairement plusieurs dizaines d’entrées dans la MMU de P7, ce qui allonge donc la durée de la phase de préparation, car il s’agit de code en mode noyau non interruptible. A titre d’illustration, nous avons réalisé l’expérimentation de la figure 3.18. Nous avons augmenté la durée d’exécution de la phase de préparation de la partition P7 en ajoutant 452 entrées dans la MMU ce qui a prolongé de 15 microsecondes la durée de cette phase (105 microsecondes au lieu des 90 requises). P6 P7 T0 T1 T2 T3 90 1410 1410 90 Durée d'exécution Compteur (CCR) Fig. 3.18 – Dépassement de la phase de préparation de P7. Cette expérimentation a juste pour but de montrer que l’on peut déborder de ces 90µs mais elle ne peut directement être exploitée par une partition malveillante. Si une partition malveillante utilise volontairement énormément d’entrées dans la MMU, elle va simplement se pénaliser elle-même puisque son cycle de préparation va dépasser 90µs, et par conséquent, son temps d’exécution va en être réduit d’autant. En revanche, si on imagine qu’une partition malveillante ait la possibilité de modifier la configuration d’une partition critique de façon à lui faire utiliser énormément de mémoire, il est possible qu’elle puisse donc réduire son temps d’exécution. Cependant, cette configuration étant réalisée de façon statique à priori, il semble particulièrement difficile de réaliser une telle attaque. Si l’on suppose cependant que cette configuration puisse être modifiée, alors cela peut notamment être intéressant si on le combine à l’attaque présentée dans la section précédente. C’est ce que nous montrons dans la sous-section suivante. 813.6.3 Utilisation conjointe des deux attaques Dans ce dernier exemple (figure 3.19), nous avons cumulé les deux cas précédents. Nous considérons une partition malveillante P6 qui tente d’allonger son temps d’exécution pour voler du temps d’exécution de la partition P7, qui est non-malveillante. Par ailleurs, la partition P7 utilise énormément d’entrées dans la MMU et voit son temps de préparation déborder des 90ms. Dans ce cas très particulier, la partition P7 perd une partie conséquente de sa tranche de temps. P6 P7 T0 T1 T2 T3 90 1410 90 1410 Durée d'exécution Compteur (CCR) Fig. 3.19 – Dépassement de la phase de préparation et de la phase opérationnelle de P7. 3.7 Attaques ciblant les mécanismes de tolérance aux fautes Un composant typique de tolérance aux fautes est le gestionnaire d’erreurs du noyau, utilisé comme système de détection d’erreur et système de recouvrement. Ces mécanismes peuvent provoquer un redémarrage du module quand des erreurs sont considérées comme non-récupérables. Nous avons réalisé une expérience pour tester la robustesse de ce mécanisme de gestion des erreurs en utilisant un programme Crashme : la partition malicieuse génère une centaine d’instructions aléatoires puis les exécute. 3.7.1 Réalisation du programme Crashme Un programme Crashme consiste à générer des instructions aléatoires puis à les exécuter. Pour réaliser cela depuis une application, deux solutions sont possibles. Elles consistent à : • modifier le code source de l’application et utiliser une zone de mémoire avec les privilèges d’écriture et d’exécution : • modifier le fichier binaire de l’application pour exécuter les instructions aléatoires dans une zone de mémoire avec les privilèges d’exécution (donc comme n’importe quelle autre instruction de l’application). 82La première solution est plus simple à réaliser que la deuxième solution mais elle né- cessite des privilèges d’écriture et d’exécution sur une zone de la mémoire, ce qui qui ne devrait pas être possible justement pour éviter des exécutions de code arbitraire depuis une partition. Nous avons cependant décidé d’utiliser la première solution, puisqu’elle évite notamment de recharger l’application sur le P4080 à chaque test, même si nous considérons qu’un attaquant utiliserait plutôt la deuxième solution, qui évite de créer une zone de mémoire particulière avec des privilèges élevés (écriture et exécution). Pour notre preuve de concept, la première solution est suffisante. La création d’un générateur de nombres pseudo-aléatoires est complexe et difficile à prouver mais notre intérêt, ici, est de générer des instructions différentes à chaque exécution de notre partition et non de générer des nombres sans aucun biais. Nous avons utilisé une formule simple et rapide, le standard minimal de Park et Miller [PM88] : Xn+1 = (16807 ∗ Xn) mod (231 − 1) La première valeur X0 est initialisée à la valeur du registre TBL (Time Base Lower) qui est une mesure du temps de la plateforme variant très fortement car basé sur les nanosecondes. Cette formule permet donc de générer jusqu’à 2 147 483 647 (231 − 1) valeurs différentes, mais sur cet intervalle, nous utiliserons seulement 216 valeurs (2 octets) pour générer plus simplement les 4 octets (2 fois 2 octets) composant une instruction (4 octets). Une boucle dans notre programme nous permet de générer des centaines de valeurs de 2 octets et donc des centaines d’instructions. 3.7.2 Instrumentation du noyau Pour identifier et comparer les résultats, nous avons modifié légèrement le noyau et enregistré les erreurs générées. Nous avons également empêché le noyau de s’arrêter ou de redémarrer lorsque certaines erreurs étaient présentes. Le noyau gère 22 erreurs différentes, identifiées dans le P4080 comme des IVOR (Interrupt Vector Offset Register) : SRESET, Machine Check, DSI (Data Storage Interrupt), ISI (Instruction Storage Interrupt), ALG (Alignment), FPUNAV (Floating-Point Unavailable), DEC (Decrementor), PMC (Performance Monitor Controller), ITLB (Instruction TLB), DTLB (Data TLB), TIMER, Watchdog, Debug, Processor Doorbell, Processor doorbell critical, Guest Processor Doorbell, Guest Processor Doorbell Critical, Hypersyscall, Hypervisor Privilege, Program, trace et Non-Maskable Interrupt. A chacune de ces erreurs, nous avons ajouté quelques lignes de code pour incrémenter un compteur. Nous utilisons une zone de la mémoire accessible en lecture et écriture pour stocker ces valeurs de compteurs. Nous avons également ajouté un compteur pour compter le nombre de cycle (un cycle = 5ms) exécutés. De cette manière, nous avons exécuté plus d’un million de cycles (environ 1h30 d’exécution) puis nous avons comparé les résultats. 833.7.3 Résultats obtenus Ce programme Crashme a été exécuté pendant 1 043 806 cycles, ce qui nous permet de donner des statistiques fiables sur les comportements observés. Cette expérience nous a montré que parmi les 22 erreurs possibles, plus de 99,9% des erreurs sont des Program Exceptions. Le pourcentage restant est composé de 7 autres erreurs (Data TLB, Instruction TLB, DSI, ISI, Alignment, Hypervisor syscall et syscall) et il représente moins d’1% des erreurs. Les 14 autres erreurs ne sont jamais levées. Le tableau suivant indique comment le Health Monitor (HM) réagit lorsqu’une erreur apparaît et montre que beaucoup d’entre elles provoquent un redémarrage ou un arrêt du module. Même si le pourcentage d’apparition de ces erreurs est très faible comparé au pourcentage de l’erreur Program, qui elle provoque un simple redémarrage de la partition, leur nombre est elevé. Quasiment toutes les erreurs, autres que l’erreur Program provoquent un redémarrage ou un arrêt du module et donc un déni de service. Cette expérience est donc intéressante au sens où elle a montré que le mécanisme de traitement des erreurs devait clairement être amélioré de façon à mieux identifier la source de l’erreur et d’agir de façon adaptée. Ces problèmes ont ainsi été présentés à Airbus et ont été pris en compte de façon à corriger les mécanismes de traitement des erreurs. Type d’erreur % Red. partition Red. Mod. Arrêt module Program 99,92 v - - Data TLB 0,0475 v - - DSI 0,0252 - v v ITLB 0,0038 - v - ISI 0,00086 - - v Align 0,00134 - v - Hypervisor syscall 0,00067 - v - Syscall 0,00063 - - - Conclusion Nous avons vu dans ce chapitre de quoi était constitué la plate-forme d’expérimentation que nous avons utilisée. Nous avons également décrit plusieurs attaques réalisées sur ce système en utilisant différents canaux (gestion de la mémoire, communication, gestion du temps, mécanisme de tolérance aux fautes). Comme nous l’avons vu, plusieurs problèmes ont été identifiés, et ont été corrigés par Airbus après leurs découvertes. Ce cercle vertueux s’est ainsi montré très efficace pour améliorer la sécurité de ce noyau temps réel, d’autant plus que ces vulnérabilités, en général incluses dans du logiciel très bas niveau et liées à des mécanismes matériels propres de la plateforme, ne peuvent être détectées que grâce à ce type d’expérimentations et corrections. Dans le prochain chapitre, nous allons aborder les mécanismes de protection que l’on peut imaginer mettre en place pour faire face à ce genre d’attaques. Nous présenterons les contre-mesures spécifiques aux vulnérabilités que nous avons découvertes sur notre noyau particulier avec nos expérimentations adaptées à ce noyau. Elles seront présentées 84par type d’attaque. Ensuite, nous proposerons des contre-mesures les plus générique possibles, qui peuvent donc servir de recommandations de sécurité lors de l’implémentation d’un exécutif temps-réel désirant implémenter du partitionnement spatial et temporel. Enfin, nous présenterons une architecture sécurisée possible pour l’utilisation d’un périphérique réseau. 8586Chapitre 4 Protections des systèmes avioniques contre les malveillances Introduction Après avoir présenté dans les chapitres précédents, la classification des attaques possibles ciblant les couches basses logicielles des systèmes embarqués et après avoir mené des expérimentations mettant en œuvre de telles attaques, il est fondamental d’aborder pour terminer ce manuscrit, les mécanismes permettant de se protéger de ce type d’attaques. Nous allons donc détailler dans ce chapitre les différents mécanismes de protection que nous envisageons face à ces menaces. Nous commençons par proposer des contre-mesures spécifiques, qui permettent de nous protéger contre les attaques que nous avons mises en œuvre sur notre plateforme d’expérimentation. Ces contre-mesures spécifiques sont abordées dans la section 4.1 et elles sont présentées par type d’attaque (suivant notre classification des attaques du chapitre 2). Nous proposons ensuite, à partir de ces contre-mesures spécifiques, de dégager des grandes familles de mesures génériques, qui peuvent être appliquées de façon générale aux systèmes embarqués. Ces contre-mesures génériques sont abordées dans la section 4.2. Nous listons également des recommandations générales pour les développeurs de façon à éviter l’introduction de vulnérabilités lors de la phase de développement. Enfin, nous détaillons dans la section 4.3, une proposition d’architecture sécurisée pour une carte réseau AFDX afin de se protéger au mieux contre d’éventuelles attaques logicielles. Même si cette architecture est présentée à l’aide d’un exemple précis, elle a pour but de poser les bases d’une architecture générique sécurisée de pilote de périphé- rique pour systèmes embarqués. 874.1 Contre-mesures spécifiques à notre plateforme d’expé- rimentation Dans cette section, nous détaillons les contre-mesures adaptées à notre plateforme d’expérimentation P4080 qui permettent de se protéger contre les attaques suivantes : • les attaques ciblant la gestion de la mémoire ; • les attaques ciblant les communications ; • les attaques ciblant la gestion du temps ; • les attaques ciblant les mécanismes de tolérance aux fautes. 4.1.1 Attaques ciblant la gestion de la mémoire Dans la section 3.4, nous avons montré qu’un accès non limité au CCSR par les partitions peut avoir de graves conséquences sur le système. Rappelons que cette zone de 16Mo permet de configurer les composants du P4080. Elle contient entre autres la configuration de certains composants, comme le Security Engine ou encore le Run Control/Power Management. Ces composants peuvent redémarrer ou stopper le système si certaines valeurs dans les registres de cette zone sont positionnées. Ce choix d’implémentation concernant les droits d’accès au CCSR s’explique de la façon suivante. Dans l’implémentation actuelle du noyau, l’accès au CCSR est autorisé à toutes les partitions pour leur permettre d’envoyer/recevoir des messages via le réseau AFDX. Plus précisément, les communications AFDX sont effectuées via un transfert DMA initialisé en configurant certains registres du CCSR. Cette solution est en fait un moyen rapide pour fournir un accès AFDX aux partitions qui en ont besoin. La protection la plus évidente qu’il convient de préconiser consiste à apporter une modification sur les entrées de la MMU pour limiter les accès privilégiés de chaque partition au CCSR, mais cela empêche toute partition d’effectuer directement une communication AFDX. Cette solution doit donc s’accompagner de la création d’une partition dédiée aux communications AFDX. Cette partition est la seule partition (appelée “partition I/O”) permettant de communiquer directement sur le réseau AFDX. Les autres partitions né- cessitant des accès AFDX pourront alors avoir recours à cette partition en utilisant des mécanismes IPC (Inter Processus Communication). Ce choix d’architecture limite fortement les risques dûs aux malveillances concernant l’écriture dans la zone CCSR. La figure 4.1 illustre une telle implémentation. Sur ce schéma, les partitions P0 et P1 communiquent avec la partition I/O afin d’accéder à la carte AFDX. Le noyau gère toutes les autorisations. Il contrôle l’ensemble des données échangées et autorise ou non les partitions à établir des communications via l’AFDX. En revanche, la partition I/O doit être associée à un niveau de criticité élevé. De plus, cette partition est un passage obligé pour toute requête d’entrées/sorties sur le bus AFDX et cela a un impact en terme de performance temporelle. Nous ferons une autre proposition tout aussi sécurisée mais plus performante dans la section 4.3. Protéger efficacement la mémoire signifie aussi la protéger des accès DMA malveillants réalisés par les périphériques. Le P4080 dispose de plusieurs PAMUs (Platform 88Partitions Hyperviseur Matériel Carte réseau MMU - I/O MMU Partition I/O Partition 0 Partition 1 Partition 2 IPC DMA IPC Fig. 4.1 – Exemple d’accès entre 2 partitions et une partition I/O. Memory Management Units) qui sont identiques aux I/O MMUs (Input/Output Memory Management Units) présents sur les architectures Intel. Ces PAMUs permettent d’autoriser ou non les accès à la mémoire depuis les périphériques vers la mémoire mais aussi les accès de périphérique à périphérique. Cette protection se base sur l’affectation à chaque périphérique d’identifiants LIODN (Logical I/O Device Number) qui sont vérifiés par les PAMUs lors des accès à la mémoire. Chaque PAMU est configuré grâce à des tables, qui permettent de virtualiser la mémoire mais aussi d’attribuer des droits d’accès aux différentes zones de mémoire, de façon similaire aux tables de la MMU. 4.1.2 Attaques ciblant les communications Plusieurs attaques ciblant les communications sont détaillées dans la section 3.5. Les contre-mesures associées sont présentées en deux parties. La première partie est consacrée aux contre-mesures pour les attaques ciblant les communications AFDX et la deuxième partie est consacrée aux contre-mesures pour les attaques ciblant les IPC. 4.1.2.1 Communications AFDX Les communications AFDX permettent d’échanger des données entre modules via le réseau AFDX. Cependant, les mécanismes utilisés à l’heure actuelle possèdent un certain nombre de faiblesses et peuvent être corrompus (voir sous-section 3.5.1). Nous avons ainsi montré qu’il était possible depuis une partition qui utilise AFDX, de réaliser des accès DMA généralisés, de modifier des variables globales partagées entre partitions, ou encore de modifier le contenu des données de configuration qui sont envoyées au Flash Manager. La première contre-mesure que nous proposons, concernant les accès DMA, consiste à protéger l’accès au CCSR. Elle nécessite l’utilisation d’une partition I/O et elle a été explicitée dans la section précédente. La deuxième contre-mesure que nous proposons 89concerne l’accès à certaines variables globales depuis une partition qui utilise l’AFDX (partage qui est à l’origine d’une des attaques présentée dans le chapitre 3). Dans ce cas, nous préconisons de limiter l’accès de ces variables à la lecture uniquement. La modification de ces variables ne doit être effectuée que par le noyau, voire par la partition I/O. La troisième contre-mesure concerne la reprogrammation de la zone EEPROM par le Flash Manager. Il est nécessaire d’intégrer au Flash Manager un mécanisme de véri- fication d’intégrité des données utilisées pour la reprogramation. Cependant, l’absence de ce mécanisme aujourd’hui peut se justifier par la présence en amont de la vérification de ces données avant l’envoi au Data Loader. En effet, les données de reprogrammation sont particulièrement critiques puisqu’elle sont utilisées pour la reconfiguration complète du calculateur. Toutefois, ajouter un mécanisme supplémentaire de contrôle d’intégrité au moment de la reprogrammation nous semble pertinent, vu la criticité des données manipulées. 4.1.2.2 Communication IPC Nous avons également présenté des vulnérabilités dans l’implémentation des IPC, permettant à une partition d’invoquer des fonctions d’une autre partition. Il est possible de mettre en défaut ce mécanisme de différentes façons : (1) en invoquant l’appel-système de retour de la partition distante avant celui de la partition locale ; (2) en forçant le timer courant à s’arrêter pendant l’exécution de la fonction distante ; et (3) en modifiant le registre GPR 10 avant le premier appel-système. La première contre-mesure consiste à empêcher la partition distante d’invoquer l’appelsystème si l’appel-système de la partition locale n’a encore été invoqué. Pour cela, il est nécessaire de mémoriser et contrôler l’ordre des appel-système dans le noyau, en ajoutant des variables d’états contrôlées par le noyau. La figure 4.2 représente une implémentation possible des IPCs en utilisant un bit de vérification (noté b) et les mêmes appel-système que dans l’implémentation précédente (notés sc). Le noyau débute son initialisation en positionnant à 0 un bit par invocation possible entre une partition locale et une partition distante. Dans un comportement normal, l’appel-système de la partition locale est exécuté avant l’appel-système de la partition distante. Aussi, lors de l’appel-système, le noyau passe à 1 le bit correspondant. Lorsque l’appel-système de retour de la partition distante est exécuté, le noyau vérifie si le bit correspondant est à 1. Si tel est le cas, le retour dans la partition locale est autorisé. En revanche, dans le cas d’un comportement abusif, l’appel-système de retour de la partition distante est exécuté en premier. Au moment de la vérification par le noyau, le bit correspondant étant à 0, le retour dans la partition locale n’est pas autorisé. Ce mécanisme de vérification nécessite donc 1 bit par appel système entre chaque partition locale et chaque partition distante. L’occupation mémoire engendré est donc raisonnable et l’exécution des routines de vérification peut être réalisée en temps borné. Par conséquent, le coût de ce mécanisme de protection nous semble donc léger, bien adapté à un système temps réel et constitue donc une contre-mesure appropriée selon nous. En revanche, ce mécanisme ne prend pas en compte la possibilité d’avoir des 90Partition distante Partition locale Noyau Partition distante Partition locale Noyau Comportement normal : appel-système distant autorisé Comportement abusif : appel-système distant bloqué b = 0 b = 1 si b == 1 b = 0 si b == 1 sc sc sc Fig. 4.2 – Proposition de contre-mesure sur le mécanisme IPC. systèmes réentrants puisqu’un seul bit est considéré par appel-système. La deuxième contre-mesure que nous proposons vise à éviter un blocage dans le noyau lorsque le Global Timer expire pendant l’exécution de la fonction distante, qui a intentionnellement exécuté une boucle infinie. Cette contre-mesure consiste à améliorer la gestion des erreurs par le Health Monitor du noyau. Ce dernier peut par exemple détecter que dans le cas d’une IPC, l’instruction venant d’être exécutée provient de la partition distante (en fonction de l’adresse de cette instruction) et non de la partition locale. Il convient donc, soit de revenir dans la partition locale après l’appel à la fonction distante, avec un code d’erreur, soit d’arrêter la partition locale pour ne plus réaliser d’appel à la fonction. La troisième contre-mesure concerne le registre GPR10 qui est utilisé dans le code de la partition locale avant l’appel-système et qui est ensuite vérifié par le noyau. Ce registre étant un registre général sans privilège particulier, la partition peut modifier cette valeur. Ce registre devrait donc être un registre privilégié modifiable seulement par le noyau. 4.1.3 Attaques ciblant la gestion du temps Nous avons présenté dans la section 3.6 des attaques ciblant la gestion du temps. Celles-ci peuvent permettre à une partition malveillante d’allonger sa durée d’exécution, ce qui peut avoir pour conséquence de limiter la durée d’exécution de la partition suivante (en particulier lors de la phase de préparation de la partition suivante). Pour réaliser ce débordement, il suffit de provoquer une interruption à la fin de la tranche de temps de la partition malveillante. Cette interruption est traitée par le noyau, qui est non-interruptible. Par conséquent, l’ordonnancement des partitions est retardé. Il semble particulièrement difficile d’imaginer une contre-mesure technique à cette attaque. En revanche, on peut imaginer une contre-mesure concernant le calcul des WCET : il convient 91de prendre en compte la durée d’exécution de l’interruption la plus longue dans le calcul des différents WCET. Nous avons également montré qu’il est possible d’allonger la phase de préparation en utilisant un nombre très élevé d’entrées dans la MMU (pour utiliser un grand nombre de zones de mémoire différentes). La configuration de la MMU étant réalisée par le noyau, ce code est encore une fois non-interruptible, ce qui signifie qu’il est susceptible de poursuivre son exécution alors qu’un timer est en attente et que ce timer ne pourra déclencher une interruption que lorsque le processeur reprendra l’exécution de la boucle infinie en mode utilisateur. La contre-mesure que nous proposons ici est de limiter le nombre d’entrées dans la MMU directement par le générateur de code. Ceci empêche la création de trop nombreuses entrées sachant qu’il est très peu probable que toutes ces entrées soient réellement nécessaires. Il faut également que le temps de préparation de la partition prenne en compte le temps nécessaire à la configuration de toutes les entrées de la MMU. La figure 4.3 illustre les durées d’exécutions des partitions en prenant en compte les durées d’exécution des interruptions. 90 1410 1410 90 Durée d'exécution Compteur (CCR) Durée d'exécution réelle en comportement normal Durée d'exécution supplémentaire prévue en cas de comportement abusif Durée d'exécution de la plus longue interruption t (µs) Fig. 4.3 – Proposition de contre-mesure prenant en compte les durées d’exécution d’interruption. Sur la figure 4.3, nous présentons 2 partitions P6 et P7 avec leurs phases de pré- paration respectives W6 et W7. Les durées P6 et P7 sont constituées chacune de trois durées d’exécution : la durée d’exécution de la partition elle-même, la durée d’exécution de l’interruption la plus longue et enfin la marge de sûreté habituelle (de l’ordre de 20%). Pour les durées W6 et W7, il suffit de limiter le nombre d’entrées dans la MMU à une cinquantaine au maximum au lieu de 512 permises par défaut par la MMU. 4.1.4 Attaques ciblant les mécanismes de tolérance aux fautes Nous avons présenté dans la sous-section 3.7.1 la réalisation d’un programme Crashme qui nous a permis de détecter plusieurs dysfonctionnements dans le mécanisme de gestion des erreurs. Il est ainsi possible de redémarrer ou arrêter le module complet depuis une partition. Nous proposons de modifier le comportement du gestionnaire d’erreur pour 92ne pas autoriser de redémarrages intempestifs ou d’arrêt du module. Lorsqu’une erreur survient, le noyau doit sanctionner la partition à l’origine de l’erreur uniquement et non le module. Il doit donc établir un diagnostic de fautes très précis. La contre-mesure consiste à mieux identifier l’origine de l’erreur, ce qui est possible puisque le type de l’erreur est connu par le noyau ainsi que la partition concernée (le contexte d’exécution au moment du déclenchement de l’erreur). De cette façon, il a été possible de prendre des sanctions précises concernant uniquement l’origine de l’erreur et non plus des sanctions trop larges appliquées souvent à tout le module. Cette modification a été implémentée dans le noyau après nos expérimentations. Plus précisément, voici quelques éléments techniques qui ont été utilisés pour améliorer cette gestion des erreurs. Pour ce qui concerne l’origine de l’erreur, le cœur e500mc du P4080 comporte un mécanisme commun aux processeurs PowerPC : lorsqu’une interruption survient, le registre SRR0 contient la valeur de l’adresse qui a été interrompue41 et le registre SRR1 contient la valeur du registre MSR (Machine Status Register) qui contient le niveau de privilège actuel. Ces deux registres permettent notamment de se “repositionner” à l’instruction suivante avec les mêmes privilèges. Si une partition est la source de l’erreur, alors il est nécessaire d’arrêter le fonctionnement de cette partition. Si c’est le noyau qui en est la source, alors il est préférable de redémarrer ou d’arrêter le module complet car des défaillances à répétitions peuvent se produire. En ce qui concerne la nature de l’erreur, le registre ESR (Exception Syndrome Register) permet d’informer le noyau de la cause exacte de l’erreur (instruction illégale, instruction privilégiée, opération store, etc.). Le tableau 4.1 présente les résultats avec le nouveau gestionnaire d’erreurs. Type d’erreur % Redémarrage de Redémarrage Arrêt du la partition du module module Program 99,92 v - - Data TLB 0,0475 v - - Data Storage Int. 0,0252 v - - Instruction TLB 0,0038 v - - Instruction Storage Int. 0,00086 v - - Alignment 0,00134 v - - Hypervisor syscall 0,00067 - - - Syscall 0,00063 - - - Tab. 4.1 – Répartition des actions en fonction des types d’erreurs. Les taux d’erreurs sont identiques à l’ancienne version mais il n’est désormais plus possible de faire redémarrer ou arrêter le module depuis un code utilisateur d’une partition car la sanction se fait uniquement au niveau de la partition. En ce qui concerne 41Sauf en cas d’erreur imprécise. 93l’appel-système hyperviseur (hypervisor syscall), il ne fait pas redémarrer la partition, mais simplement passer à l’instruction suivante. Ce choix a été fait car cet appel système n’est pas une erreur en tant que tel, puisqu’il s’agit d’une instruction parfaitement légitime. Cependant, il est a priori improbable qu’elle soit invoquée dans notre système expérimental puisqu’aucun système d’exploitation invité n’y est présent. Dans cette section, nous nous sommes focalisés sur les contre-mesures spécifiques à notre plateforme d’expérimentation et aux attaques que nous avons pu mener. Il est possible de généraliser certaines de ces contre-mesures de façon à proposer des mécanismes de protection génériques, adaptés à différents types de systèmes embarqués. C’est l’objet de la section suivante. 4.2 Contre-mesures génériques Dans cette section, nous commençons par proposer des contre-mesures génériques adaptables à différents systèmes embarqués, face aux attaques suivantes : • les attaques ciblant le processeur ; • les attaques ciblant la gestion de la mémoire ; • les attaques ciblant les communications ; • les attaques ciblant la cryptographie ; • les attaques ciblant les fonctions ancillaires ; • les attaques ciblant les mécanismes de tolérance aux fautes. Ensuite, nous proposons de compléter ces contre-mesures par des recommandations aux développeurs (voir section 4.2.8). En particulier, nous présentons brièvement les techniques d’analyse statique (voir sous-section 4.2.9), qui permettent de vérifier le code source de l’applications et des techniques d’analyse dynamique (voir sous-section 4.2.10) qui permettent d’analyser l’exécution en temps-réel de l’application. 4.2.1 Attaques ciblant le processeur Le rôle central du processeur dans le système en fait un composant souvent ciblé par les attaques. Effectivement, la compromission du processeur permet soit d’exécuter un code malveillant, soit de porter atteinte à l’intégrité des périphériques. La plupart des contre-mesures présentées dans cette sous-section visent à consolider les configurations des différents éléments qui composent le processeur (cache, mécanisme de synchronisation, gestionnaire des interruptions, etc.). Les accès aux périphériques et à la mémoire centrale étant plus lents que la vitesse de fonctionnement du processeur, des mémoires caches avec des vitesses de fonctionnement intermédiaires sont utilisées comme espace de stockage temporaire. Ces espaces de stockage sont partagés entre les différents processus 42 qui s’exécutent sur le processeur. Il est important que, lors du changement de contexte, le contenu de ces caches soit complètement vidé. Cette contre-mesure assure qu’un processus malveillant ne puisse pas 42Le terme processus est utilisé au sens large et fait référence à une tâche, une partition, etc. 94stocker dans une des mémoires caches des instructions machines en espérant que le processeur les exécutera en pensant qu’elles correspondent aux instructions machines d’un autre processus. De plus, si la propriété de confidentialité est importante à assurer dans le système, le vidage du contenu des mémoires caches doit être réalisé indépendamment du contenu de ces mémoires. Les processeurs modernes sont également structurés en plusieurs cœurs pour l’exécution en parallèle des instructions. Sur la plupart des architectures, chaque cœur dispose de son propre gestionnaire d’interruptions (nommé Local APIC sur les architectures Intel). La synchronisation entre ces cœurs est également assurée via ces gestionnaires d’interruptions. La configuration de ces gestionnaires doit être réalisée lors de l’initialisation du noyau du système et elle doit être accessible uniquement par ce noyau. De la sorte, un processus ne peut pas envoyer des interruptions pour, par exemple, arrêter un des autres cœurs. Tous les cœurs du processeur doivent être initialisés. Cette initialisation peut être mise en place par une chaîne de confiance au démarrage. A titre d’exemple, pour la mise en place d’une chaîne de confiance, le processeur P4080 peut utiliser le composant Security Monitor et les processeurs Intel peuvent utiliser le composant TPM. Le processeur doit pouvoir exécuter des instructions machines privilégiées (telles que les instructions de manipulation des registres de configuration) uniquement si le niveau de privilège du processeur est lui-même élevé. Pour assurer ce contrôle, deux principaux mécanismes de protection doivent être configurés : les anneaux de protection (ring) avec la segmentation et les droits d’accès à la mémoire avec la pagination. L’anneau le plus privilégié doit correspondre aux instructions du noyau et toutes les instructions du noyau doivent être associées à cet anneau. Quant à la pagination, elle permet de protéger ces instructions de manière à empêcher un processus malveillant de les modifier dans le but de faire exécuter une séquence d’instructions malveillante au processeur. Les processeurs modernes disposent de plusieurs modes de fonctionnement (par exemple, pour la gestion des ressources, pour la virtualisation, etc.). Les processeurs du grand public intègrent également des modes historiques pour des raisons de rétrocompatibilités pour les logiciels. Il est important que le noyau configure tous ces modes. Les modes qui ne sont pas utilisés par le système doivent aussi être configurés et figés. Cette contre-mesure empêche des attaques de profiter des modes du processeur qui ont été ignorés par le noyau pour exécuter des actions en contournant les mécanismes de protection des modes effectivement configurés. Plus généralement, une contre-mesure importante est l’analyse du point de vue de la sécurité de la spécification du processeur, lorsque cette spécification est connue du développeur du système. Cette spécification peut correspondre au code VHDL utilisé pour la conception. Par exemple, le code VHDL du processeur Leon3 est disponible pour permettre aux développeurs d’y intégrer des modifications. Avoir à disposition la spécification d’un processeur permet d’identifier des vulnérabilités (généralement des instructions qui ne sont pas – ou mal – documentées). Par la suite, l’idéal est de modifier la spécification du processeur pour éliminer ces vulnérabilités. Si cette option n’est pas envisageable, ces vulnérabilités doivent alors être contenues par des mécanismes de pro- 95tection adaptés et intégrés dans le noyau du système. Lorsque cette spécification n’est pas connue du développeur du système, une analyse de vulnérabilités doit tout de même être réalisée en utilisant des outils de fuzzing. Le programme Crashme en est un bon exemple. Les vulnérabilités identifiées par ces outils doivent être également contenues par des contre-mesures à intégrer dans le noyau du système. 4.2.2 Attaques ciblant la mémoire La mémoire d’un système correspond à l’ensemble des mémoires accessibles depuis le processeur. Il s’agit de la mémoire centrale (habituellement nommée RAM) et de la mémoire des périphériques (par exemple, les registres des périphériques PCI-Express). Ces mémoires peuvent être directement manipulées par le processeur mais elles peuvent aussi être manipulées via des transferts DMA (Direct Memory Access). Par exemple, dans le cas d’un transfert DMA, un périphérique peut recopier le contenu d’un tableau en mémoire centrale sans passer par le processeur. Ces mémoires sont donc manipulées par différents processus et périphériques de différents niveaux de criticité. Dans la suite, le terme composant fait référence à un processus ou un périphérique. Une zone mémoire peut être attribuée de manière exclusive à un composant ou peut être partagée par plusieurs composants. Pour empêcher un composant d’interférer avec l’espace mémoire attribué et manipulé par un autre composant, il est nécessaire de mettre en place des contre-mesures. Le premier accès réalisé à une zone de la RAM attribuée de manière exclusive à un processus doit toujours être une écriture. Autrement dit, l’initialisation d’un processus doit toujours débuter par une écriture dans la zone mémoire pour placer l’environnement d’exécution du processus dans un état déterministe. De la même manière, dans le cas de l’allocation dynamique ou de l’attribution temporaire d’une zone mémoire par le noyau, le processus doit avant toute manipulation de ces nouvelles zones mémoires, placer leur contenu dans un état déterministe. Ces bonnes pratiques empêche un processus de copier un contenu dans une zone mémoire de manière à interférer avec un autre processus qui récupèrera un accès à cette zone mémoire. Les mécanismes de pagination et de segmentation de la MMU (Memory Management Unit) doivent être mis en place par le noyau pour assurer le partitionnement spatial de la mémoire des processus. Ces mécanismes permettent tout d’abord de virtualiser la mémoire et ensuite d’indiquer quels sont les droits d’accès à la mémoire (lecture, écriture ou exécution). La mise en place de la mémoire virtuelle consiste à construire une fonction de traduction entre une adresse virtuelle (manipulée par le processus) et une adresse physique. La granularité de cette fonction est la page mémoire (il s’agit d’une unité correspondant à 4ko). Il existe donc les pages mémoires virtuelles et les pages mé- moires physiques. Les droits d’accès aux pages mémoires sont indiqués directement dans la fonction de traduction. Il est important de noter qu’il est possible de construire des fonctions différentes pour les différents processus. Lors de la construction de chaque fonction, seules les pages mémoires physiques contenant des données d’un processus doivent avoir une page mémoire virtuelle comme image. Aussi, pour faciliter la mise en place de ces fonctions, le noyau doit charger les processus de manière à ne pas partager une page 96mémoire physique entre plusieurs processus. Dans le cas de la mémoire partagée, une page mémoire contenant uniquement les données partagées entre les processus doit être créée. Ce mécanisme de protection met en place le partitionnement spatial pour les accès mémoire depuis le processeur. Il doit s’accompagner d’un mécanisme complémentaire pour les accès réalisés avec les périphériques. De la même manière que précédemment, une fonction de traduction peut être mise en place pour les accès entre les périphériques et la mémoire centrale. Ces fonctions sont construites en configurant une MMU pour les entrées-sorties (I/O MMU sur les architectures Intel et PAMU sur le P4080). Si un périphérique est partagé entre plusieurs processus et que la virtualisation du matériel n’est pas disponible (cf. section 4.3), il est alors plus pertinent de construire un processus dédié aux communications avec le périphérique : un pilote de périphérique. Les autres processus peuvent alors invoquer les services de ce pilote de périphérique. Tout comme pour la configuration de la MMU précédente, les fonctions doivent uniquement permettre à un périphérique d’accéder aux pages de la mémoire physique qui le concerne. De la sorte, le système est prémuni des attaques via les transferts DMA. 4.2.3 Attaques ciblant les communications Les mécanismes de communications permettent à différents processus d’échanger de l’information. Ces échanges doivent être contrôlés de manière à s’assurer qu’un processus peut toujours envoyer ses données et qu’un processus peut recevoir des données. Autrement dit, il ne faut pas qu’un processus puisse empêcher un autre processus d’envoyer des données ou qu’un processus puisse recevoir les données destinées à un autre processus. Des mécanismes de protection doivent être mis en place pour garantir que ces propriétés sont bien assurées. Pour permettre aux mécanismes de protection de contrôler les messages échangés, il est nécessaire que les mécanismes de communication associent aux messages les identités de la source et de la destination. Ces informations ne doivent pas être fixées par la source elle-même. Elles doivent être fixées par un composant associé au plus haut niveau de confiance et incontournable pour l’échange de messages. Ce composant peut être le noyau qui peut être sollicité par des appels-système pour permettre les échanges. Le verdict associé à la tentative d’envoi d’un message doit se baser sur une liste de contrôle des accès, idéalement construite statiquement lors de la phase de conception et de compilation des différents composants du système. Quel que soit le type de communication mis en place entre les processus (communication asynchrone ou synchrone), un processus ne doit pas pouvoir submerger le récepteur au point de l’empêcher d’échanger à son tour des informations avec d’autres processus. Pour éviter cette situation, chaque processus doit disposer d’autant de boîtes aux lettres que de processus avec lesquels il peut communiquer. Le noyau peut alors poster le message dans la boîte aux lettres du destinataire correspondant au processus source. Ainsi, un débordement d’une boîte aux lettres issu d’une activité malveillante nuit uniquement au processus source. Le message échangé entre les processus doit pouvoir être analysé entièrement par le 97noyau. Le processus ne doit pas pouvoir utiliser un pointeur vers sa mémoire virtuelle pour indiquer au noyau le contenu du message. De plus, il est préférable que le message à échanger entre deux processus soit contenu dans une page mémoire dédiée. Ainsi, si le noyau associe cette page mémoire à la mémoire virtuelle du processus destinataire (à la manière des blackboards), ce dernier n’aura accès qu’au message. 4.2.4 Attaques ciblant la gestion du temps Les contre-mesures aux attaques ciblant la gestion du temps correspondent aux mé- canismes permettant de protéger la politique d’ordonnancement. Ces contre-mesures doivent donc être directement intégrées dans le noyau et elles entraînent nécessairement l’exécution de routines supplémentaires. La première contre-mesure correspond à la gestion de la sauvegarde du contexte d’un processus. L’espace mémoire associé doit être entièrement géré par le noyau et ne doit pas être accessible au processus. Par exemple sur les architectures Intel, en adoptant ce principe, un processus ne peut pas modifier le contenu du registre cr3 (il s’agit d’un registre permettant de contrôler la traduction entre une adresse virtuelle et une adresse physique). La seconde contre-mesure concerne le calcul du temps d’exécution d’un processus durant un cycle de l’ordonnanceur. Ce temps (le WCET) doit prendre en compte non seulement la durée d’exécution des instructions du processus mais également la durée d’exécution des routines permettant de configurer le matériel. Plus précisément, il est nécessaire de considérer la durée nécessaire pour re-configurer les composants matériels (MMU, périphériques, caches) et la durée d’exécution de l’interruption la plus longue. 4.2.5 Attaques ciblant la cryptographie Les attaques ciblant la cryptographie visent généralement à obtenir les clés privées incluses dans les fonctions cryptographiques voire à interférer avec les méthodes permettant de générer des nombres aléatoires. Pour empêcher un processus d’obtenir ces clés, il est nécessaire d’éviter les fuites d’information en vidant systématiquement les caches du processeur lors des changements de contexte. De cette manière, un processus malveillant ne peut pas se baser sur le contenu du cache pour déduire des informations sur les clés manipulées par le processeur. Un processus ne doit pas pouvoir deviner (totalement ou partiellement) la valeur d’un nombre aléatoire obtenu par un autre processus. Le service permettant de délivrer ces valeurs doit donc être implémenté dans un espace de confiance qui peut être un processus dédié ou le noyau. Ce service doit également, dans la mesure du possible, se baser sur un générateur aléatoire matériel pour empêcher les autres processus de surcharger le système dans le but de restreindre l’intervalle des valeurs que le service peut retourner. 4.2.6 Attaques ciblant les fonctions ancillaires Rappelons que les fonctions ancillaires correspondent à la gestion de l’alimentation, de l’over-clocking, du contrôle de température, etc. Sur les architectures x86, ces fonc- 98tions sont assurées dans un mode dédié du processeur : le mode SMM. Ce mode dispose d’un accès privilégié au système (dans la limite des quatre premiers giga-octets de mé- moire). Il a été la cible de plusieurs attaques. Pour éviter ces attaques, les fondeurs de processeurs x86 proposent un mécanisme permettant de verrouiller la mémoire contenant les instructions exécutées par ce mode. Il est important que ce mode soit configuré et verrouillé. 4.2.7 Attaques ciblant les mécanismes de tolérance aux fautes Comme nous l’avons montré dans la section 2.2, les attaques ciblant les mécanismes de tolérance aux fautes peuvent cibler le traitement d’erreur et le traitement des fautes. Nous allons proposer quelques contre-mesures génériques permettant de se défendre d’attaques ciblant ces mécanismes. Nous ne serons pas exhaustifs dans cette partie, puisque ce sont les attaques que nous avons pu le moins expérimenter, étant donné que le système expérimental dont nous disposions, contenait peu de mécanismes de tolérance aux fautes (il aurait fallu que nous disposions de plusieurs versions du calculateur pour utiliser la redondance par exemple, ce qui n’a pas été possible dans notre plateforme). 4.2.7.1 Traitement des fautes Concernant le traitement de fautes, on peut généraliser la contre-mesure mise en place dans le cas spécifique de notre expérimentation. Il est fondamental que le diagnostic de fautes soit le plus précis possible, de façon à identifier avec certitude l’origine des erreurs et donc le composant fautif. Cette contre-mesure, qui a été mis en place dans notre expérimentation et qui a permis d’améliorer la gestion des erreurs, a pour vocation d’empêcher une application malveillante de déclencher volontairement de multiples erreurs dans l’espoir de provoquer un redémarrage complet du système. La reconfiguration fait également partie du traitement de fautes. Cette reconfiguration intervient en général après identification et passivation d’un ou plusieurs composants fautifs et consiste à modifier la configuration du système pour qu’il puisse continuer à fonctionner (éventuellement en mode dégradé) sans faute. Elle est suivie d’une phase de réinitialisation dans laquelle la nouvelle configuration est enregistrée dans le système. Un attaquant ciblant la reconfiguration et réinitialisation peut tenter d’accéder à la zone mémoire où se situe cette configuration de façon à faire redémarrer le système dans une configuration incorrecte. Une contre-mesure face à ce type d’attaques est de choisir avec précaution la zone de mémoire dans le système où est stockée cette configuration. Cela fait intervenir une nouvelle fois la configuration précise de la MMU. 4.2.7.2 Traitement d’erreurs En ce qui concerne les différents mécanismes de traitement d’erreurs, on peut tout d’abord envisager des contre-mesures visant à se protéger d’attaques ciblant la détection d’erreurs. Par exemple, la duplication et la comparaison est un mécanisme efficace de tolérance aux fautes accidentelles mais il est relativement facile à contourner par une 99application malveillante. En revanche, la diversification fonctionnelle est un mécanisme efficace de détection d’erreur, même vis-à-vis des fautes intentionnelles. Il est donc à privilégier lorsque l’on s’intéresse aux malveillances. Il est en effet très difficile pour un attaquant, d’imaginer une attaque efficace qui puisse avoir les mêmes effets sur des matériels et logiciels diversifiés. Cette diversification a d’ailleurs déjà fait ses preuves vis-à-vis des malveillances dans d’autres contextes, comme dans le cadre d’opérations de maintenance des futurs architectures avions [Laa09], ou dans le cadre d’applications Web par exemple [Sai05]. En ce qui concerne les mécanismes de recouvrement d’erreurs et plus précisément la reprise, il nécessite, comme nous l’avons vu dans les précédents chapitres, l’existence de points de reprise (aussi appelés points de restauration). De façon à éviter qu’un attaquant puisse modifier ces points de reprise, une contre-mesure consiste à utiliser une zone de mémoire protégée pour stocker les points de reprise, de façon à que cette zone ne soit pas modifiable par les différentes partitions. Cela signifie qu’ils devront probablement être stockés dans l’espace du noyau. En ce qui concerne la corruption potentielle des mécanismes de poursuite, qui provoquerait volontairement le passage en mode dégradé du système, une contre-mesure possible consiste à disposer d’un mécanisme de diagnostic de fautes très précis. Si le diagnostic de fautes évalue avec certitude l’origine d’erreurs à répétition (provoquées dans le but de passer le système en mode dégradé), il peut alors sanctionner l’application (en l’occurrence malveillante) et non le système complet. 4.2.8 Recommandation aux développeurs Les contre-mesures proposées dans les sous-sections précédentes visent à intégrer des mécanismes de protection architecturaux. Il est bien sûr nécessaire de compléter ces mé- canismes par des bonnes pratiques de développement, permettant d’éviter l’introduction de vulnérabilités dans le logiciel ou de détecter leur présence. Ces bonnes pratiques sont déjà bien sûr préconisées pour détecter les fautes accidentelles (bugs) mais elles sont également fondamentales pour détecter les fautes intentionnelles. Notre objectif dans cette section est simplement de lister les bonnes pratiques de développement qui nous semblent les plus importantes vis-à-vis de l’identification de vulnérabilités. Deux d’entre elles sont notamment l’analyse statique et l’analyse dynamique de code. Elles sont l’objet de cette sous-section. Cette sous-section ne prétend pas faire une étude exhaustive de ces analyses (ce qui nécessiterait un chapitre complet) mais plutôt de souligner l’importance de leur utilisation lors du développement de systèmes embarqués. 4.2.9 Analyse statique L’analyse statique vise à détecter dans le code source du programme cible d’éventuelles fautes. L’identification de ces fautes est utile à la fois du point de vue de la tolérance aux fautes mais aussi du point de vue de la sécurité. En effet, leur identification durant la phase de développement permet de réduire de façon considérable les fautes 100de conception et ainsi de réduire les vulnérabilités exploitables dans le code source. Plusieurs classes de défaut sont identifiées par les outils d’analyse statiques [CE09]. Parmi celles-ci, nous pouvons citer les divisions par zéro, les fuites de mémoire, les déré- férencement de pointeur nul, les variables non-initialisées, les débordements de tampons, et les typages (cast) inappropriés. Elles correspondent aux fautes les plus couramment rencontrées dans les codes. Certains outils d’analyse statique de code sont capables de détecter la majorité de ces classes de défaut mais ils sont aussi capables de vérifier la conformité du code vis-à- vis de certains standards de développement. A titre d’exemple, Prevent43, Polyspace44 ou Astrée45, peuvent effectuer ces vérifications avec des langages comme C, C++, Java ou Ada. MALPAS Software Static Analysis Toolset46 effectue des vérifications similaires pour le code assembleur PowerPC. En particulier, pour notre étude, l’analyse statique peut être réalisée sur le code source du noyau ainsi que sur les codes source des partitions, qu’ils soient écrits en C ou en assembleur PowerPC. Nous pouvons également vérifier et analyser les fichiers de configuration utilisés pour paramétrer le noyau. En effet, ces fichiers de configuration contiennent des informations sur les zones de mémoires utilisées, les tranches de temps allouées aux partitions ou encore la gestion des erreurs (Health Monitor). Nous avons d’ailleurs régulièrement utilisé l’analyse statique de code dans le cadre de nos expérimentations sur la plateforme P4080 et le noyau expérimental d’Airbus dont le code source nous a été fourni (ce qui nous a donc permis de réaliser ce type d’analyse). Même si nous n’avons pas systématiquement utilisé d’outils automatiques, ce type d’analyse nous a permis d’identifier des vulnérabilités intéressantes, en ce qui concerne la gestion des IPC par exemple et s’est donc révélé particulièrement efficace. 4.2.10 Analyse dynamique L’analyse statique peut être complétée par l’analyse dynamique dont l’objectif est également l’identification de vulnérabilités mais en se basant sur l’observation du comportement du programme durant son exécution. Des outils comme Valgrind47 et mpatrol48 sont des exemples de logiciels permettant de détecter des fuites de mémoire en se basant par exemple sur l’observation des invocations à des bibliothèques standards telle que la libc. Une technique courante consiste à analyser le comportement d’un programme en l’exécutant en premier lieu dans un environnement restreint, dans lequel chaque accès à la mémoire et chaque entrée/sortie est contrôlé. Cet environnement peut prendre différentes formes, par exemple les sandbox Java ou les Jails des systèmes BSD. Cela peut aller jusqu’à l’utilisation des machines virtuelles complètes. Ceci est notamment couramment 43http://www.coverity.com 44http://www.mathworks.fr/products/polyspace/ 45http://astree.ens.fr 46http://www.malpas-global.com 47http://valgrind.org 48http://mpatrol.sourceforge.net/ 101utilisé par les éditeurs d’anti-virus, qui analysent en détail toute nouvelle génération de code malveillant (en particulier auto-reproducteurs) dans des machines virtuelles dédiées, de façon à confiner l’exécution de ce type de maliciels. Dans le cadre de nos expérimentations sur la plateforme P4080, nous avons réguliè- rement utilisé l’analyse dynamique, notamment pour vérifier s’il était possible de rompre l’isolation temporelle des partitions et pour analyser le comportement du noyau ou des différentes partitions critiques en présence d’une partition malveillante qui tente d’injecter des erreurs. L’analyse dynamique nous a permis d’identifier de nombreux problèmes de déni-de-service notamment. 4.3 Proposition d’une architecture sécurisée pour la gestion d’un périphérique partagé Comme nous l’avons vu dans cette thèse, plusieurs attaques sont liées à la volonté de partager un périphérique, en l’occurrence la carte AFDX dans notre plateforme d’expérimentations, entre partitions de différents niveaux de criticité. Ce partage est réalisé par deux mécanismes : échange d’informations avec le périphérique via des accès DMA et partage du pilote logiciel du périphérique entre les partitions. En particulier, dans la version préliminaire du noyau d’Airbus, le partage du pilote logiciel est réalisé via la création d’une mémoire partagée entre les différentes partitions et le pilote. Il s’agit d’une solution temporaire pour laquelle nous proposons une amélioration dans cette section. Cette solution permet d’implémenter des mécanismes de protection efficaces vis-à-vis des accès aux périphériques partagés entre partitions et est basée sur une architecture matérielle particulière. Cette proposition d’architecture n’a pas été expérimentée dans le cadre de cette thèse mais elle a toutefois été discutée en collaboration avec des ingénieurs d’Airbus. Nous présentons tout d’abord le principe général de cette solution, basée sur des technologies matérielles de virtualisation. Cette technologie est aujourd’hui implémentée dans un certain nombre de cartes réseaux (de type Ethernet) mais pas à notre connaissance pour des cartes AFDX. Nous présentons cette technologie, baptisée Single Root I/O (technologie qui n’a donc pas été spécifiquement développée pour des applications embarquées), dans la première partie de cette section. Nous présentons ensuite son utilisation dans un système avionique embarqué, utilisant le principe du partitionnement spatial et temporel. 4.3.1 Principe L’architecture sécurisée que nous proposons est basée sur des technologies maté- rielles d’assistance à la virtualisation. Ces technologies sont déjà relativement matures et utilisées sur les processeurs récents, et favorisent grandement le développement de gestionnaires de machines virtuelles (aussi appelés hyperviseurs). Elles portent respectivement le nom d’Intel-VTx ou AMD-V pour les processeurs des familles Intel et AMD. Elles sont par ailleurs déjà mises à profit dans plusieurs études au service de la sécurité 102des systèmes informatiques. Plusieurs hyperviseurs de sécurité ont ainsi été proposés dans différents travaux [M+10, LD11, S+09a] et ont souvent pour but d’assurer une protection efficace vis-à-vis de corruptions des couches basses du logiciel. Ainsi, souvent, les hyperviseurs de sécurité visent à protéger le noyau du système d’exploitation luimême, qui en principe, est le logiciel le plus privilégié, mais aussi le plus sensible d’un système informatique. L’idée principale derrière ces travaux réside dans le fait qu’il est très difficile de corrompre un hyperviseur utilisant des technologies d’assistance maté- rielle à la virtualisation puisque ces technologies sont considérées comme très difficiles à contourner, contrairement à des mécanismes de protection logiciels. L’architecture que nous proposons ici utilise également des techniques de virtualisation, mais au niveau des périphériques cette fois-ci. Ces mécanismes de virtualisation fonctionnent en coopération avec les mécanismes de virtualisation du processeur principal de la machine sur laquelle est connectée le périphérique. Ces mécanismes matériels incontournables et cette coopération sont selon nous une base solide pour assurer la sé- curité d’un périphérique. Elle est encore très peu déployée aujourd’hui et nous semble un atout important qu’il est utile de considérer dès aujourd’hui pour l’amélioration de la sécurisation des systèmes embarqués avioniques. 4.3.2 Virtualisation matérielle d’un périphérique : Single Root-I/O Virtualization Un certain nombre de périphériques réseau implémentent aujourd’hui une technologie de virtualisation matérielle baptisée Single Root-I/O Virtualization (SR-IOV). La carte Intel 82599EB 10Gb 49, qui peut être connectée sur un port PCIe, en est un exemple. La virtualisation SR-IOV permet, à partir d’une unique carte physique, d’exposer de multiple cartes virtuelles, pouvant être mises à disposition de différentes machines virtuelles. La virtualisation SR-IOV est plus précisément une extension de la spécification du protocole PCIe qui permet à différentes machines virtuelles de partager les mêmes ressources physiques PCIe. La figure 4.4 représente cette architecture. Les accès à ces ressources physiques sont donc virtualisés au travers de l’invocation de différentes fonctions PCIe : • Une fonction physique (PF) correspond à l’exposition sur le bus PCI-Express du périphérique réel ainsi que la totalité de ses ressources ; cette fonction est destinée à être accessible uniquement par du logiciel privilégié (typiquement l’hyperviseur s’exécutant sur le processeur principal ou à une machine virtuelle privilégiée de type Dom0 de Xen par exemple) mais non accessible aux machines virtuelles ; • Une ou plusieurs fonctions virtuelles (VF) exposent à une machine virtuelle une carte virtuelle qui correspond à un sous-ensemble de ressources de la carte physique. A chaque PF et VF, est associé un identifiant Express Request ID ou RID unique, 49http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ 82599-10-gbe-controller-datasheet.pdf 103Fig. 4.4 – Architecture de virtualisation Single Root I/O [sri]. qui permet à l’unité de traitement de entrées/sorties (comme l’I/O MMU sur Intel ou les PAMU sur le P4080) de distinguer les différents flux d’informations et d’appliquer des translations aux accès mémoires et aux interruptions concernant la PF et les VFs. L’intérêt de cette technologie est surtout un gain en performance. Effectivement, les requêtes PCIe sont directement acheminées entre les machines virtuelles et les VFs associées, par DMA, sans nécessiter une émulation logicielle par l’hyperviseur (cette émulation induit un surcoût en performance). Cela permet également de limiter la taille de l’hyperviseur ainsi que sa complexité. Pour pouvoir exploiter pleinement la technologie SR-IOV, il y a un certain nombres de contraintes que l’architecture matérielle, en particulier la MMU et l’I/O MMU, doivent respecter. Tout d’abord, il est nécessaire que l’I/O MMU soit capable de distinguer les opérations réalisées par les différentes cartes virtuelles (associées à des machines virtuelles différentes). Pour cela, il est nécessaire que l’I/O MMU implémente ses contrôles d’accès à la granularité de la fonction PCIe pour que les différentes machines virtuelles n’aient accès qu’à leur carte virtuelle dédiée (caractérisée par leur VF). Ceci permet d’autoriser très précisément les accès DMA notamment, en fonction de l’identifiant de VF inclus dans la requête PCIe. Il est également nécessaire que la gestion des interruptions par l’I/O MMU soit effectuée finement : elle doit être capable de distinguer les interruptions provenant des cartes virtuelles (c’est-à-dire des différentes VFs) de façon à les rediriger correctement vers la machine virtuelle associée (on parle d’IRQ remapping). Ensuite, 104l’utilisation correcte de SR-IOV impose aussi des contraintes sur la gestion des ressources au niveau de la MMU. En effet, la configuration des différentes VFs est projetée en mémoire en utilisant la technologie MMIO (Memory Mapped IO). Or, il est fondamental que chaque machine virtuelle puisse accéder à la configuration de sa VF mais surtout qu’elle ne puisse pas accéder à la configuration des VFs des autres machines virtuelles. Aussi, dans la mesure où la granularité des protections de la mémoire gérées par la MMU est la page (de taille 4ko), il est fondamental que les différentes VFs puissent être mappées sur des pages mémoires différentes de façon à bénéficier des protections dédiées par la MMU. Ces exigences, ainsi que quelques autres, que nous ne citons pas ici pour ne pas entrer dans trop de détails d’implémentations, sont bien détaillées dans un article de 2013 de Münch et al. ([MIM+13]). 4.3.3 Utilisation de SR-IOV dans un contexte avionique embarqué Dans un contexte avionique utilisant le partitionnement, l’adoption d’un périphérique de type SR-IOV doit s’adapter à l’architecture logicielle utilisée. Ainsi, dans ce contexte, chaque machine virtuelle correspond à une partition différente. Ces différentes partitions non privilégiées, appelées partitions “enfants”, ont accès chacune à une carte virtuelle différente représentée par sa VF. L’association de ces VFs aux partitions est réalisée par un logiciel privilégié, typiquement le noyau du système embarqué lui même, ou une partition de contrôle privilégiée, ainsi que le propose par exemple Münch et al. dans [MIM+13]. Cette partition de contrôle est associée à la fonction physique PF et peut ainsi avoir accès à l’ensemble des ressources de la carte ainsi qu’à sa configuration. Le partitionnement spatial est réalisé en utilisant la MMU et l’I/O MMU. Dans une architecture SR-IOV, nous avons listé ci-dessus un certain nombre de contraintes techniques qui doivent être respectés pour que leur utilisation soit efficace. Ces contraintes permettent en fait de séparer les contextes des partitions, car une partition ne doit pas être capable d’avoir accès au contexte (ensemble de registres) d’une autre partition. De son côté, l’hyperviseur ou la partition de contrôle doit gérer ses propres variables mais aussi des variables globales pour les autres partitions. Si les contraintes listées ci-dessus concernant la MMU et l’I/O MMU sont respectées, l’isolation spatiale est assurée efficacement entre partitions. Si l’on prend l’exemple de la plateforme d’expérimentation utilisée dans cette thèse, basée sur le P4080, ces contraintes ne sont pas respectées puisqu’elle inclut bien une MMU et un certain nombre de PAMUs mais ces PAMUs ne sont pas capables d’établir des contrôles d’accès basés sur des identifiants de fonctions PCIe. Les PAMUs sont capables de faire des vérifications uniquement en fonction de l’identité PCIe du périphérique lui-même. Ainsi, dans le cadre de l’utilisation du P4080, il est nécessaire d’enrichir le noyau du système embarqué de façon à pallier ce problème. De même, en ce qui concerne les interruptions, il est nécessaire, comme nous l’avons invoqué précédemment, que l’architectrure offre la possibilité de gérer l’IRQ Remapping de façon fine, basée sur l’identification de fonctions PCIe, ce qui encore une fois n’est pas le cas de la plateforme basé sur le P4080 utilisée dans cette thèse et qui implique 105donc une prise en charge supplémentaire du noyau de système embarqué. Enfin, le partitionnement temporel doit s’effectuer avec la prise en compte des durées d’exécution de la carte réseau elle-même pour traiter les paquets. Cette durée d’exécution doit avoir un impact minimal sur la durée d’exécution des partitions. En effet, en l’absence de périphérique SR-IOV, habituellement les entrées/sorties sont gérées par une partition I/O qui doit donc traiter les problèmes d’accès concurrents des différentes partitions au périphérique, et qui doit donc assurer l’isolation spatiale et temporelle. Dans le cas d’un périphérique SR-IOV, les différentes partitions accèdent directement à leur périphérique virtuel et c’est donc au périphérique de gérer l’isolation temporelle directement. Il est donc fondamental d’éviter qu’une partition ayant un accès légitime à sa carte virtuelle (via la VF associée) puisse empêcher une autre partition de pouvoir émettre ou recevoir dans son quantum de temps imparti, de façon à assurer le partitionnement temporel. Cela nécessite en particulier que le périphérique offre la possibilité au noyau du système embarqué (ou à la partition de contrôle en fonction du choix d’architecture effectué) d’annuler ou de suspendre une commande (opération d’envoi ou de réception demandée à la carte) mais aussi de gérer l’accès simultané de plusieurs partitions. En conclusion de cette section, on peut affirmer que si l’ensemble des contraintes relatives à la MMU et l’I/O MMU sont bien respectés sur la plateforme matérielle, l’utilisation d’un composant de type SR-IOV, en particulier pour les communications AFDX des systèmes embarqués avioniques, s’avère être une solution efficace (à la fois en termes de performance et en termes de complexité du logiciel privilégié) et sécurisée (car matériellement isolée en espace et en temps). Nous estimons donc que son utilisation dans les systèmes avioniques du futur est à considérer avec soin. Conclusion En conclusion, nous avons proposé dans ce chapitre différents moyens pour se protéger de tentatives de corruptions réalisées par une partition malveillante s’exécutant sur un calculateur avionique. Nous avons présenté des contre-mesures spécifiques pour les attaques expérimentées dans le chapitre 3. Nous avons ensuite proposé, pour certaines de ces attaques, des contre-mesures génériques applicables à différents types de systèmes embarqués. Nous avons également justifié l’intérêt de complémenter systématiquement ces contre-mesures par des techniques d’analyse statique de code et par des techniques d’analyse dynamique. Enfin, nous avons proposé une architecture sécurisée de péripérique partagé entre différentes partitions de criticités différentes. Cette architecture est basée sur les technologies matérielles de virtualisation Single Root-I/O. Nous avons présenté son utilisation dans un contexte avionique embarqué. L’ensemble de ces contre-mesures nous paraît être une bonne base pour améliorer la conception et le développement sécurisés de systèmes embarqués avioniques du futur. 106Conclusion générale La sécurité des systèmes informatiques est une préoccupation grandissante depuis déjà de nombreuses années. De nouveaux programmes malveillants sont sans cesse dé- couverts, ces programmes étant par ailleurs de plus en plus complexes et de plus en plus difficiles à éradiquer. En même temps, les systèmes informatiques sont de plus en plus connectés à de multiples réseaux, filaires ou non, qui constituent autant de “portes d’entrées” possibles pour les attaquants. Si la sécurité des systèmes informatiques “de bureau” fait l’objet de nombreux travaux depuis de nombreuses années, il n’en est pas de même pour les systèmes embarqués. Ces systèmes, embarqués dans tous nos appareils connectés à Internet à la maison par exemple, mais aussi embarqués dans les voitures, dans les avions, sont eux aussi et de plus en plus aujourd’hui, la cible potentielle d’attaques. Les travaux que nous avons menés dans le cadre de cette thèse visent à apporter une contribution à l’amélioration de la sécurité des systèmes embarqués, en particulier des systèmes avioniques. En effet, l’évolution récente de ces systèmes, notamment avec l’adoption par les avionieurs de l’architecture IMA Integrated Modular Avionics, vise à réduire les coûts de développement et de maintenance, mais elle accroît potentiellement la surface d’attaques possible. Les travaux présentés dans ce manuscrit ont donc eu pour but d’analyser et d’améliorer les mécanismes de sécurité existants sur des systèmes embarqués avioniques. Même si la sécurité de ces systèmes est déjà prise en compte par les avioneurs, les mécanismes de sécurité utilisés aujourd’hui sont davantage basés sur des méthodes d’analyse statique de code et sur l’utilisation de méthodes formelles pour la conception des applications avioniques. Ces méthodes sont évidemment essentielles et très pertinentes mais elles né- cessitent, selon nous, d’être complétées par des analyses de vulnérabilités, en particulier, visant les couches basses du logiciel. C’est dans cet objectif que se sont situés les travaux de cette thèse. Nous avons proposé dans le premier chapitre de ce manuscrit, après avoir justifié l’intérêt des nos travaux, une méthodologie pour mener à bien cette analyse de vulnérabilités. Elle a été réalisée en fonction d’une classification des attaques sur les systèmes embarqués, et c’est une première contribution de cette thèse. Cette classification, pré- sentée en détails dans le second chapitre, comprend deux catégories : les attaques ciblant les fonctionnalités de base et les attaques ciblant les mécanismes de tolérance aux fautes. Les attaques ciblant les fonctionnalités de base sont similaires aux attaques visant les systèmes informatiques grand public et concernent les attaques ciblant le processeur, la 107gestion de la mémoire, les communications, la gestion du temps, la gestion et l’ordonnancement des processus, les mécanismes cryptographiques et les fonctions ancillaires. Les attaques ciblant les mécanismes de tolérance aux fautes mettent l’accent sur des attaques qui visent à exploiter les mécanismes habituels de tolérance aux fautes présents dans la majorité des systèmes embarqués critiques et en particulier dans les systèmes avioniques. Ces attaques ciblent particulièrement les mécanismes que sont le traitement d’erreurs et le traitement de fautes. Dans le troisième chapitre, nous avons mené des expérimentations concernant un certain nombre des attaques identifiées dans la classification du second chapitre, sur un système embarqué expérimental développé par Airbus. Ce système nous a été fourni avec ses sources, ce qui nous a permis notamment de réaliser une analyse de code afin d’identifier d’eventuelles vulnérabilités. Nous avons considéré un système avionique composé de différentes partitions de criticités différentes et nous avons fait l’hypothèse qu’une partition non critique peut être malveillante et tenter de corrompre une partition critique s’exécutant sur le même calculateur (comme il est permis dans le contexte de l’architecture IMA). Ces attaques ont été réalisées sur une plateforme QorIQ P4080 de Freescale. Nous avons réalisé des attaques ciblant la gestion de la mémoire, la gestion du temps, les communications et les mécanismes de tolérance aux fautes. Ces attaques ont donné des résultats intéressants pour la plupart et ont permis de corriger certaines vulnérabilités présentes dans le système, ce qui a contribué à améliorer la sécurité du système. Ce cercle vertueux nous a paru fondamental car il a été réalisé durant la phase de développement. Il constitue pour nous la seconde contribution de cette thèse. Enfin, nous avons proposé, dans le quatrième chapitre de ce manuscrit, des contremesures spécifiques à nos attaques réalisées et des contre-mesures génériques adaptables à d’autres types de systèmes embarqués. Nous avons également donné des recommandations générales pour les développeurs d’applications embarquées et proposé une architecture sécurisée de périphérique partagé entre applications de différentes criticités. Bilan et perspectives Nous voudrions, avant d’aborder les perspectives, établir un petit retour d’expérience concernant les expérimentations et la collaboration avec Airbus dans le cadre de ces travaux. Nous avons eu la grande chance de disposer d’un exécutif temps-réel expérimental avec ses sources, développé par Airbus. Les échanges que nous avons effectués ont été très fructueux et ont permis d’introduire des modifications de cet exécutif pendant la phase de développement, en vue d’améliorer sa sécurité. De ce point de vue, nous estimons que cette étude a été particulièrement intéressante et fructueuse. En revanche, il nous a été assez difficile de nous procurer la plateforme d’expérimentation comprenant le P4080, les sondes JTAG et CodeWarrior, ce qui nous a un peu limité dans la quantité des expérimentations que nous avons pu réaliser ensuite. La découverte de vulnérabilités dans le noyau a été un exercice très intéressant, même si, le noyau étant particulièrement minimaliste et statique (Airbus le qualifie de “nano-noyau”), il était probable qu’il serait difficile de trouver des vulnérabilités très sérieuses. Il ne contient en effet que les fonctions 108vitales, pour ordonnancer les partitions et gérer les interruptions, et toute sa configuration est statique. La surface d’attaque était donc très limitée depuis une partition utilisateur. Cependant, il a été intéressant de comprendre comment le noyau temps-réel et les partitions ont été développés ainsi que le fonctionnement du P4080 de Freescale et ses nombreuses caractéristiques. Nous avons pu réaliser quelques expérimentations avec succès sur les communications, la gestion du temps et les mécanismes de tolérance aux fautes, et nous avons pu éliminer ces vulnérabilités avec la collaboration d’Airbus, ce qui était un des objectifs de cette thèse. L’important est que ces expérimentations et cette plateforme nous ont permis de valider, dans un contexte spécifique, notre méthodologie de recherche de vulnérabilités. En ce qui concerne les perspectives à ces travaux, on peut envisager des perspectives de deux ordres. Les premières perspectives, à court terme et sur un plan technique, concernent les expérimentations que nous avons menées. En effet, faute de temps et faute de matériel adéquat, nous n’avons pu toutes les réaliser. A titre d’exemple, d’autres attaques ciblant la gestion de la mémoire pourraient être mises en œuvre, notamment visant les caches du processeur. Ces attaques, que nous n’avons pu mener par faute de temps nous semblent particulièrement pertinentes dans un contexte avionique. D’autres attaques peuvent être envisagées si l’on dispose du matériel adéquat pour réellement mettre à l’épreuve certains mécanismes de tolérance aux fautes, en particulier basés sur la redondance. Nous ne disposions pas, pour cette étude, de multiples exemplaires du même calculateur et nous n’avions donc pas la possibilité de mettre en œuvre certaines techniques de tolérance aux fautes basées sur la redondance. A plus long terme et sur un plan méthodologique, nous pouvons envisager des perspectives concernant la méthodologie d’analyse de vulnérabilités pour des systèmes embarqués avioniques que nous avons présenté dans le chapitre 1.6. Il serait intéressant d’étudier l’adéquation de cette méthodologie à d’autres domaines d’applications. Le domaine automobile par exemple en est un bon exemple car de nombreux systèmes embarqués sont présents dans les voitures d’aujourd’hui. De même que pour les avions, la connectivité des véhicules automobiles devient de plus en plus étendue (connectivité Wifi, BlueTooth, GSM, etc.) et toutes ces sources de connectivité sont autant de sources d’attaques possibles. L’adoption de COTS dans ces véhicules peut également introduire les mêmes types de risques que leur adoption dans les systèmes avioniques. Il est donc pertinent de vouloir améliorer les mécanismes de sécurité existants sur les automobiles. Il est probable que la classification que nous avons proposée doive être adaptée aux mé- canismes de tolérance aux fautes des véhicules, qui sont différentes des mécanismes des systèmes avioniques. On peut bien sûr envisager ce même genre d’études sur d’autres systèmes embarqués très différentes, comme les systèmes embarqués qui envahissent notre quotidien professionnel et personnel aujourd’hui, car il est probable que beaucoup de ces équipements n’ont pas été développé avec un réel souci de sécurité. Enfin, une des perspectives de cette thèse concerne les contre-mesures. En particulier, nous avons proposé une première réflexion concernant une architecture sécurisée de périphérique partagé entre différentes partitions. Cette architecture, utilisant des mé- canismes matériels incontournables, est selon nous, une contribution intéressante à la 109conception d’architectures sécurisées de systèmes avioniques critiques. Cette réflexion demande à être poursuivie, en ayant toujours le souci d’envisager des mécanismes de sécurité à la fois logiciels et matériels pour pouvoir concevoir des mécanismes de défense efficaces contre des attaques visant les couches les plus basses du logiciel. 110Bibliographie [01N13] 01Net. Une attaque informatique bloque l’Internet chinois pendant des heures. http://www.01net.com/editorial/601826/ une-attaque-informatique-bloque-linternet-chinois-pendant-des-heures/, août 2013. [A+06] J. Akoka et al. Encyclopédie de l’informatique et des systèmes d’information. Vuibert, décembre 2006. [Aci06] Kaya Koç C. Aciiçmez, O. Trace-Driven Cache Attack on AES. In ICICS’06 Proceedings of the 8th international conference on Information and Communications Security, pages 112–121, 2006. [Aci07a] O. Aciiçmez. Yet Another MicroArchitectural Attack : Exploiting I-Cache. In Workshop on Computer Security Architecture (CSAW’07), pages 11–18, New-York City (NY, USA), 2007. ACM. [Aci07b] Schindler W. Kaya Koç C. Aciiçmez, O. Cache Based Remote Timing Attack on the AES. In CT-RSA 2007, The Cryptographers’ Track at the RSA Conference 2007, pages 271–286. Springer-Verlag, 2007. [Aed12] J. Aedla. Linux Kernel CVE-2012-0056 Local Privilege Escalation Vulnerability. Technical report, Janvier 2012. [ALRL04] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic Concepts and Taxonomy of Dependable and Secure Computing. Transactions On Dependable and Secure Computing, 1 :11–33, janvier/mars 2004. [ari05] ARINC 811 : Commercial Aircraft Information Security Concepts of Operation and Process Framework. Technical report, ARINC Corp., décembre 2005. [ARI08] ARINC 653 : Avionics Application Software Standard Interface Part 2 Extended Services. Technical report, ARINC Corp., décembre 2008. [ari09] ARINC 664 : Aircraft Data Network, Part 7, Avionics Full-Duplex Switched Ethernet Network. Technical report, ARINC Corp., septembre 2009. [arp10] ARP 4754A : Guidelines For Development Of Civil Aircraft and Systems. Technical report, SAE International, décembre 2010. [Art14] C. Arthur. Apple’s SSL iPhone vulnerability : how did it happen, and what next ? Technical report, Février 2014. 111[ASK07] O. Aciiçmez, J.-P. Seifert, and C. K. Koç. Predicting Secret Keys via Branch Prediction. In The 7th Cryptographers’ Track at the RSA Conference on Topics in Cryptlogy (CT-RSA’07), pages 225–242, San Francisco (CA, USA), 2007. Springer-Verlag. [Avi85] A. Avizienis. The N-Version Approach to Fault-Tolerant Software. Transactions On Software Engineering, 11 :1491–1501, décembre 1985. [B+02] P. Baudin et al. Caveat : a tool for software validation. In Dependable Systems and Networks (DSN), page 537, Juin 2002. [B+12a] P. Bieber et al. Security and Safety Assurance for Aerospace Embedded Systems. 2012. [B+12b] J.-P. Blanquart et al. Similarities and Dissimilarities between Safety Levels and Security Levels. 2012. [Ber05] D. J. Bernstein. Cache-timing attacks on AES. Technical report, 2005. [Boi06] A. Boileau. Hit by a Bus : Physical Access Attacks with FireWire. In RUXCON, Melbourne (Australia), septembre 2006. [Bon06] Mironov I. Bonneau, J. Cache-Collision Timing Attacks Against AES. In Cryptographic Hardware and Embedded Systems (CHES), pages 201–215, 2006. [Bro13] M. Brodbeck. Potential EMI from Portable Electronic Devices (PED) on aircraft. http://www.serec.ethz.ch/EVENTS%20WEF%202011/ AVIATION+SPACE_28JUN13/8_PED%20EMC%20in%20Aviation_V3_ BRODBECK.pdf, juin 2013. [C+07] P. Cousot et al. Varieties of Static Analyzers : A Comparison with ASTREE. In First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering(TASE’07), pages 3–20, Shangai, juin 2007. [Can12] Radio Canada. Fermeture de Megaupload : Anonymous riposte par une série d’attaques. http://www.radio-canada.ca/nouvelles/International/ 2012/01/19/013-anonymous-attaque-sites-megaupload.shtml, janvier 2012. [CC77] P. Cousot and R. Cousot. Abstract Interpretation : A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints. In 4th ACM Symposium Principles Of Programming Languages (POPL’77), pages 238–252, Los Angeles (California, Etats-Unis), 1977. [CC13] X. Chen and D. Caselden. MS Windows Local Privilege Escalation Zero-Day in The Wild. Technical report, Novembre 2013. [CE09] B. Chelf and C. Ebert. Ensuring the Integrity of Embedded Software with Static Code Analysis. volume 26, pages 96–99, mai/juin 2009. [Cou13] J. Couzins. Attacking the Hypervisor. Technical report, Novembre 2013. [DADN12] A. Dessiatnikoff, É. Alata, Y. Deswarte, and V. Nicomette. Potential Attacks on Onboard Aerospace Systems. In IEEE Security and Privacy vol. 10 N. 4, Juillet/Août 2012. 112[DADN13] A. Dessiatnikoff, É. Alata, Y. Deswarte, and V. Nicomette. Low-level Attacks on Avionics Embedded Systems. In The 32nd International Conference on Computer Safety, Reliability and Security (SAFECOMP), Toulouse, France, 24-27 septembre 2013. [DDAN13] A. Dessiatnikoff, Y. Deswarte, É. Alata, and V. Nicomette. Securing Integrated Modular Avionics Computers. In The 32nd Digital Avionics Systems Conference (DASC), Syracuse (NY, USA), 5-10 octobre 2013. [DKCG99] Y. Deswarte, M. Kaâniche, P. Corneillie, and J. Goodson. SQUALE Dependability Assessment Criteria. pages 27–38. Springer, 1999. [DLM09] L. Duflot, O. Levillain, and B. Morin. Getting into the SMRAM : SMM Reloaded. In CanSecWest 2009, Vancouver (BC, Canada), 2009. [DO11] J. D. O’Grady, ZDNet. FAA approves iPads in the cockpit ; American Airlines to start Friday. http://www.zdnet.com/blog/apple/ faa-approves-ipads-in-the-cockpit-american-airlines-to-start-friday/ 11865, décembre 2011. [do310] DO-326 Airworthiness Security Process Specification. Technical report, RTCA Inc., décembre 2010. [Dor04] M. Dornseif. 0wned by an iPod - hacking by Firewire. In PacSec/core04, Tokyo (Japan), novembre 2004. [Duf07] L. Duflot. Contribution à la sécurité des systèmes d’exploitation et des microprocesseurs. , Thèse de doctorat de l’université de Paris XI, octobre 2007. [ESZ08] S. Embleton, S. Sparks, and C. Zhou. SMM Rootkits : A New Breed of OS Independant Malware. In 4th International Conference on Security and Privacy in Communication Networks (SecureComm’08). ACM, 2008. [Fre11] Freescale. P4080 QorIQ Integrated Multicore Communication Processor Family Reference Manual. Technical report, avril 2011. [Gen13] S. Genevès. Améliorations de performances des systèmes multi-coeur : environnement d’exécution événementiel efficace et étude comparative de modèles de programmation. , Thèse de doctorat de l’université de Grenoble, avril 2013. [GST13] D. Genkin, A. Shamir, and E. Tromer. RSA Key Extraction via LowBandwidth Acoustic Cryptanalysis. Technical report, décembre 2013. [HS09] N. Henninger and H. Shacham. Reconstructing RSA Private Keys from Random Key Bits. In 29th Annual International Cryptology Conference (Crypto 2009, volume 5677, pages 1–17, Santa Barbara (CA, USA), 2009. Springer-Verlag. [IW08] V. Igure and R. Williams. Taxonomies of Attacks and vulnerabilities in Computer Systems. volume 10, pages 6–19, 1st quarter 2008. 113[JH08] E. Jaeger and T. Hardin. A few remarks about formal development of secure systems. In : HASE, IEEE Computer Society, pages 165–174, 2008. [KJJ99] P. Kocher, J. Jaffe, and B. Jun. Differential Power Analysis. volume 1666, pages 388–397. Springer, 1999. [Koc96] P. Kocher. Timing Attacks on Implementations of Diffe-Hellman, RSA, DSS,and Other Systems. Technical report, 1996. [KW07] R. Kaiser and S. Wagner. The PikeOS Concept - History and Design. , 2007. [L+96] J.-C. Laprie et al. Guide de la sûreté de fonctionnement, 2ème édition. Cépaduès-éditions, 1996. [LA95] S. Liu and R. Adams. Limitations of Formal Methods and An Approach to Improvement. In Software Engineering Conference, pages 498–507, Brisbane, Qld., Australie, décembre 1995. [Laa09] Y. Laarouchi. Sécurités (immunité et innocuité) des architectures ouvertes à niveaux de criticité multiples : application en avionique. , Thèse de doctorat de l’université de Toulouse, novembre 2009. [Lab12] Kaspersky Lab. Pourquoi la complexité est le pire ennemi de la sécurité informatique. Technical report, Kaspersky, 2012. [LABK90] J.-C. Laprie, J. Arlat, C. Béounes, and K. Kanoun. Definition and Analysis of Hardware-and-Software Fault-Tolerant Architectures. IEEE Computer, 23 :39–51, juillet 1990. [LAEJ11] M. Lee, M. Ahn, and K. Eun Jung. Fast Secure Communications in Shared Memory Multiprocessor Systems. volume 22, pages 1714–1721, juillet 2011. [LD11] Nicomette V. Lacombe, E. and Y. Deswarte. Enforcing kernel constraints by hardware-assisted virtualization. volume 7, pages 1–21, Février 2011. [lem13] AFP. Il sera bientôt possible de laisser son téléphone allumé dans l’avion. http://www.lemonde.fr/technologies/article/2013/12/09/ il-sera-bientot-possible-de-laisser-son-telephone-allume-dans-l-avion_ 3527966_651865.html, décembre 2013. [LSLND10] F. Lone-Sang, E. Lacombe, V. Nicomette, and Y. Deswarte. Exploiting an I/OMMU Vulnerability. In 5th International Conference on Malicious and Unwanted Software (MalWare 2010), pages 9–16, Nancy (France), 2010. [M+10] J. McCune et al. TrustVisor : Efficient TCB Reduction and Attestation. In Proceedings of the 2010 IEEE Symposium on Security and Privacy, pages 143–158, Washington, DC, USA, 2010. IEEE Computer Society. [May05] D. Maynor. 0wn3d by everything else - USB/PCMCIA Issues. In CanSecWest/core05, Vancouver (Canada), mai 2005. [MIM+13] D. Münch, O. Isfort, K. Muller, M. Paulitsch, and A. Herkersdorf. HardwareBased I/O Virtualization for Mixed Criticality Real-Time Systems Using PCIe SR-IOV. pages 706–713, Sydney (NSW), décembre 2013. 114[Mor91] M. J. Morgan. Integrated Modular Avionics for next generation commercial airplanes. volume 1, pages 43–49, mai 1991. [Mun11] C. Munoz. Computer Virus Infects Predator Ground Stations. http://breakingdefense.com/2011/10/ computer-virus-infects-predator-ground-stations/, octobre 2011. [NEV01] http://ec.europa.eu/research/growth/aeronautics-days/pdf/ posters/nevada.pdf, 2001. [OST06] D. A. Osvik, A. Shamir, and E. Tromer. Cache Attacks and Countermeasures : the Case of AES. In The 6th Cryptographers’ Track at the RSA Conference on Topics in Cryptlogy (CT-RSA’06), pages 1–20, San Jose (CA, USA), 2006. Springer-Verlag. [OWA13] OWASP. OWASP WebScarab Project. https://www.owasp.org/index. php/Category:OWASP_WebScarab_Project, 2013. [PAM01] http://www.airbus.com/innovation/eco-efficiency/ aircraft-end-of-life/pamela/, 2001. [Per05] C. Percival. Cache missing for fun and profit. In Proc. of BSDCan 2005, 2005. [pip09] PIPAME, La chaîne de valeur dans l’industrie aéronautique. Technical report, septembre 2009. [PM88] S. K. Park and K. W. Miller. Random number generators : good ones are hard to find. volume 31, pages 1192–1201. ACM, octobre 1988. [Pua11] I. Puaut. Worst-Case Execution Time (WCET) estimation : from monocore to multi-core architectures. http://www.ensta-paristech. fr/~chapoutot/seminaire/supports/isabelle_puaut_110517.pdf, mai 2011. [Ran75] B. Randell. System structure for software fault tolerance. IEEE Transactions on Software Engineering, SE-1 :220–232, juin 1975. [Rus99] J. Rushby. Partitioning in Avionics Architectures : Requirements, Mechanisms, and Assurance. , 1999. [RW09] J. Rutkowska and R. Wojtczuk. Attacking SMM Memory via IntelR CPU Cache Poisoning. Technical report, mars 2009. [S+09a] T. Shinagawa et al. BitVisor : A Thin Hypervisor for Enforcing I/O Device Security. In Proceedings of the 2009 ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments (VEE 2009), pages 121–130. ACM, 2009. [S+09b] J. Souyris et al. Formal Verification of Avionics Software Products. In A. Cavalcanti and D. Dams (Eds), editors, FM ’09 Proceedings of the 2nd World Congress on Formal Methods, pages 532–546, Eindhoven, Pays-Bas, novembre 2009. Springer-Verlag Berlin Heidelberg. 115[Sai05] A. Saidane. Conception et réalisation d’une architecture tolérant les intrusions pour les serveurs Internet. , Thèse de doctorat de l’université de Toulouse, janvier 2005. [SCA11] http://www.scarlettproject.eu/partnership/default.asp, 2011. [Ska13] P. Skaves. Information for Cyber Security Issues Related to Aircraft Systems rev-A. In 32nd Digital Avionics Systems Conference, octobre 2013. [SPHP02] B. Schätz, A. Pretschner, F. Huber, and J. Philipps. Model-Based Development of Embedded Systems. In In Advances in Object-Oriented Information Systems, Lecture, pages 298–312. Springer-Verlag, 2002. [SPL95] O. Sibert, P. A. Porras, and R. Lindell. The Intel 80x86 processor architecture : pitfalls for secure systems. In IEEE Symposium on Security and Privacy, pages 211–222, Oakland (CA, USA), 1995. [sri] SR-IOV Architecture. http://msdn.microsoft.com/en-us/library/ windows/hardware/hh440238%28v=vs.85%29.aspx. [Tes13] H. Teso. Aircraft Hacking : Practical Aero Series. In Hack In The Box, avril 2013. [usc12] Government Accountability Office. Cybersecurity : Threats Impacting the Nation. http://www.gao.gov/assets/600/590367.pdf, avril 2012. [VIC01] http://www1.fsr.tu-darmstadt.de/research/projects/en_victoria. html, 2001. [vir14] Multiples vulnérabilités dans Oracle VirtualBox et Apache Tomcat. Technical report, Février 2014. [vmw14] Multiples vulnérabilités dans les produits VMware. Technical report, janvier 2014. [WFLH04] X. Wang, D. Feng, X. Lai, and Yu H. Collisions for hash functions MD4, MD5, HAVAL-128 and RIPEMD. 2004. [xen14] Multiples vulnérabilités dans Xen. Technical report, Février 2014. [You] Y. Younan. 25 years of Vulnerabilities : 1988-2012. Technical report. [ZBR07] K. Zhou, B. Breinhauer, and T. Rausch. Violations of Real Time Communication Constraints caused by Memory Transfers exceeding CPU Cache Limits in RTAI and Rtnet. In 5th International Conference on Industrial Informatics, volume 1, pages 267–272, Vienne (Autriche), juin 2007. IEEE. [ZY09] W. Zhang and J. Yan. Accurately Estimating Worst-Case Execution Time for Multi-Core Processors with Shared Direct-Mapped Instruction Caches. In 15th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, pages 455–463, Beijing, Chine, août 2009. 116Résumé L’évolution actuelle des systèmes embarqués à bord des systèmes complexes (avions, satellites, navires, automobiles, etc.) les rend de plus en plus vulnérables à des attaques, en raison de : (1) la complexité croissante des applications; (2) l’ouverture des systèmes vers des réseaux et systèmes qui ne sont pas totalement contrôlés ; (3) l’utilisation de composants sur étagère qui ne sont pas développés selon les méthodes exigées pour les systèmes embarqués critiques ; (4) le partage de ressources informatiques entre applications, qui va de pair avec l’accroissement de puissance des processeurs. Pour faire face aux risques de malveillances ciblant les systèmes embarqués, il est nécessaire d’appliquer ou d’adapter les méthodes et techniques de sécurité qui ont fait leurs preuves dans d’autres contextes : Méthodes formelles de spécification, développement et vérification ; Mécanismes et outils de sécurité (pare-feux, VPNs, etc.) ; Analyse de vulnérabilités et contre-mesures. C’est sur ce dernier point que portent nos travaux de thèse. En effet, cet aspect de la sécurité a peu fait l’objet de recherche, contrairement aux méthodes formelles. Cependant, il n’existe pas actuellement de modèle formel capable de couvrir à la fois des niveaux d’abstraction suffisamment élevés pour permettre d’exprimer les propriétés de sécurité désirées, et les détails d’implémentation où se situent la plupart des vulnérabilités susceptibles d’être exploitées par des attaquants : fonctions des noyaux d’OS dédiées à la protection des espaces d’adressage, à la gestion des interruptions et au changement de contextes, etc. ; implémentation matérielle des mécanismes de protection et d’autres fonctions ancillaires. C’est sur ces vulnérabilités de bas niveau que se focalise notre étude. Nos contributions sont résumées par la suite. Nous avons proposé une classification des attaques possibles sur un système temps-réel. En nous basant sur cette classification, nous avons effectué une analyse de vulnérabilité sur un système réaliste : une plateforme avionique expérimentale fournie par Airbus. Il s’agit d’un noyau temps-réel critique ordonnancé avec plusieurs autres applications, le tout exécuté sur une plateforme Freescale QorIQ P4080. C’est à travers une application dite « malveillante », présente parmi l’ensemble des applications, que nous essayons de modifier le comportement des autres applications ou du système global pour détecter des vulnérabilités. Cette méthode d’analyse de vulnérabilités a permis de détecter plusieurs problèmes concernant les accès mémoire, la communication entre applications, la gestion du temps et la gestion des erreurs qui pouvaient conduire à la défaillance du système global. Enfin, nous avons proposé des contre-mesures spécifiques à certaines attaques et des contre-mesures génériques pour le noyau temps-réel qui permet d’empêcher une application d’obtenir des accès privilégiés ou encore de perturber le comportement du système. Mots-clés: systèmes embarqués, sécurité informatique, contre-mesure, système avionique, analyse de vulnérabilité. 117Abstract Security is becoming a major concern for embedded computing systems in various critical industrial sectors (aerospace, satellites, automotive, etc.). Indeed, recent trends in the development and operation of such systems, have made them more and more vulnerable to potential attacks, for the following reasons : 1) increasing complexity of the applications ; 2) openness to applications and networks that are note completely under control ; 3) Use Commercial-Off-The-Shelf (COTS) hardware and software components ; 4) Resource sharing among different applications, driven by the increase of processors capabilities. To improve the security of such systems, it is necessary to apply or adapt methods and techniques that have proven their efficiency in other contexts : Formal methods for specification, development and verification ; Security mechanisms and tools (firewalls, VPNs, etc.) ; Vulnerability assessment and countermeasure provision. The research carried out in this thesis adresses the latter technique. This aspect of security analysis cannot be easily covered by current formal methods, since no existing model is able to cover both high-level abstractions, where security properties can be defined, and low-level implementation details, where most vulnerabilities that could be exploited by attackers lie : OS kernel implementation of address space protection, interrupt management, context switching, etc. ; hardware implementation of protection mechanisms and other ancillary functions. Very few research projects are addressing this aspect of security, which is the main objective of this thesis. In particular, our research focuses on low-level vulnerabilities, but contrarily with common practice, we aim to discover and analyze them during the development process. Our contributions are summarized as follows. We elaborated a classification of lowlevel vulnerabilities for different implementations of real-time embedded systems. Based on this classification, we carried out a vulnerability analysis study on a realistic system : An experimental avionic platform provided by Airbus. It consists of a critical real-time kernel scheduling the execution of different applications on a freescale QorIQ P4080 platform. The identification and analysis of vulnerabilities is carried out based on a “malicious” application hosted on the platform that attempts to corrupt the behavior of the other applications or the global system considering different types of low level attacks. Such experiments allowed us to identify some problems related to the management of memory accesses, the communication between applications, time management and error handling that could lead to the global system failure.We have also proposed generic counter measures to protect the real-time kernel against specific attacks, and to prevent a given application from escalating its privileges or trying to compromise the system behavior. Keywords: embedded systems, computer security, countermeasure, avionic system, vulnerability assessment. 118 Localisation d’une flotte de v´ehicules communicants par approche de type SLAM visuel d´ecentralis´e Guillaume Bresson To cite this version: Guillaume Bresson. Localisation d’une flotte de v´ehicules communicants par approche de type SLAM visuel d´ecentralis´e. Automatic. Universit´e Blaise Pascal - Clermont-Ferrand II, 2014. French. . HAL Id: tel-00973894 https://tel.archives-ouvertes.fr/tel-00973894v2 Submitted on 7 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.N d’ordre : D.U 2439 EDSPIC : 645 Université Blaise Pascal - Clermont II École doctorale des Sciences Pour l’Ingénieur THÈSE en vue de l’obtention du grade de Docteur d’Université Spécialité : Vision pour la Robotique Présentée et soutenue par Guillaume Bresson Localisation d’une flotte de véhicules communicants par approche de type SLAM visuel décentralisé Thèse dirigée par Roland Chapuis préparée à l’Institut Pascal soutenue le 21 février 2014 Jury : Président : François Charpillet - Directeur de recherche INRIA Rapporteurs : Fawzi Nashashibi - Directeur de recherche INRIA Juan D. Tardós - Professeur Université de Saragosse Directeur : Roland Chapuis - Professeur Université B. Pascal Examinateurs : Javier Ibañez-Guzmán - Ingénieur de recherche Renault Romuald Aufrère - Maître de conférences Université B. PascalAbstract The localization of a vehicle with the use of SLAM techniques (Simultaneous Localization And Mapping) has been extensively studied during the last 20 years. However, only a few approaches have tried to extend these algorithms to a fleet of vehicles despite the many potential applications. It is the objective of this thesis. First of all, a monocular SLAM for a single vehicle has been developed. This one proposes to pair an Extended Kalman Filter with a Cartesian representation for landmarks so as to produce accurate low density maps. Indeed, the extension of SLAM to several vehicles requires permanent communications inside the fleet. With only a few landmarks mapped, our approach scales nicely with the number of vehicles. Cheap sensors have been favored (a single camera and an odometer) in order to spread more easily the use of multi-vehicle applications. Correctives have been proposed in order to avoid the divergence problems induced by such a scheme. The experiments showed that our SLAM is able to furnish good localization results while being light and fast. The drift affecting every SLAM algorithm has also been studied. Its integration inside the SLAM process, thanks to a dedicated architecture and a dynamic model, allows to ensure consistency even without an estimation of it. Loop closures or the integration of geo-referenced information becomes straightforward. They naturally correct all the past positions while still maintaining consistency. In a multi-vehicle scenario, it is a key aspect as each vehicle drifts differently from one another. It is consequently important to take it into account. Our SLAM algorithm has then been extended to several vehicles. A generic structure has been used so as to allow any SLAM algorithm to replace our monocular SLAM. The multi-vehicle architecture avoids data incest (double-counting information) and handles network failures, be they communication breakdowns or latencies when receiving data. The static part of the drift model allows to take into account the fact that the initial positions of the different vehicles composing the fleet might be unknown. Consistency is thus permanently preserved. Our approach has been successfully tested using simulations and real experiments with various settings (row or column convoy with 2 or 3 vehicles) in a fully decentralized way. Keywords : SLAM, decentralized, monocular, drift, EKF, multi-vehicle, localization, linearization, divergence.Résumé La localisation d’un véhicule via les techniques de SLAM (Simultaneous Localization And Mapping pour cartographie et localisation simultanées) a connu un essor important durant les 20 dernières années. Pourtant, peu d’approches ont tenté d’étendre ces algorithmes à une flotte de véhicules malgré les nombreuses applications potentielles. C’est ici l’objectif de cette thèse. Pour ce faire, une approche de SLAM monoculaire pour un seul véhicule a d’abord été développée. Celle-ci propose de coupler un filtre de Kalman étendu avec une représentation cartésienne des amers afin de produire des cartes de faible densité mais de qualité. En effet, l’extension à plusieurs véhicules nécessite des échanges permanents par l’intermédiaire de communications sans fil. Avec peu d’amers dans les cartes, notre approche s’accommode bien du nombre de véhicules de la flotte. Des capteurs peu onéreux ont aussi été privilégiés (une unique caméra et un odomètre) afin de réduire le coût d’une extension multivéhicule. Des correctifs ont été proposés afin d’éviter les problèmes de divergence induits par les choix précédents. Des expérimentations ont montré que la solution de SLAM produite était légère et rapide tout en fournissant une localisation de qualité. La dérive, inhérente à tout algorithme de SLAM, a également fait l’objet d’une analyse. Celle-ci a été intégrée au SLAM par l’intermédiaire d’une architecture dé- diée et d’un modèle dynamique. Le but est de pouvoir rendre consistante la localisation fournie par le SLAM, même en l’absence d’estimation de la dérive. Cela permet d’effectuer des fermetures de boucle ou encore d’intégrer des informations géo-référencées de manière naturelle tout en conservant l’intégrité de la solution. En multivéhicule, cet aspect est un point clef puisque chaque véhicule dérive différemment des autres. Il est donc important de le prendre en compte. Enfin, le SLAM a été étendu à plusieurs véhicules. Une structure générique a été prévue afin que notre approche monoculaire puisse être remplacée par n’importe quel algorithme de SLAM. Notre architecture décentralisée évite la consanguinité des données (le fait de compter deux fois une même information) et gère les défaillances réseau, que cela soit des ruptures de communication ou encore des latences dans la réception des données. La partie statique du modèle de dérive permet également de prendre en compte le fait que les positions initiales des véhicules d’une flotte puissent être inconnues. L’intégrité est ainsi maintenue en permanence. Enfin, notre approche étant entièrement décentralisée, elle a pu être testée et validée en simulation et avec des expérimentations réelles dans diverses configurations (convoi en colonne ou en ligne, avec 2 ou 3 véhicules). Mots clefs : SLAM, décentralisé, monoculaire, dérive, EKF, multivéhicule, localisation, linéarisation, divergence.Remerciements Avant de rentrer dans des considérations techniques, je souhaite remercier toutes les personnes qui m’ont accompagné durant ces 3 années de thèse. Tout d’abord, je remercie mes encadrants, Romulus Rémus Rémoulade Aufrère et Roland Chapuis, pour leurs conseils avisés et leur bonne humeur (presque) permanente. J’en pro- fite également pour remercier tous les gens de l’Institut Pascal ayant permis mon intégration dans leurs locaux. Je fais de même pour le personnel du département informatique de l’IUT de Clermont-Ferrand. Je tiens à remercier plus particulièrement Guénal, Sylvie et François pour m’avoir amené à cette thèse ainsi qu’à l’enseignement dans leurs locaux. Je félicite mes collègues de bureau, passés et présents, pour avoir contribué au succès de cette thèse. Un remerciement spécial va au Dr Thomas Féraud avec qui j’ai travaillé en (très) étroite collaboration durant presque 3 ans. Je remercie également Florent et Pierre pour le support technique du simulateur et les passages réguliers dans le bureau. D’un point de vue plus personnel, je fais des bisous à mes potos du midi qui m’ont permis de relâcher la pression. Je cite, par ordre de préférence (ça va faire des jaloux) : Clément, Nicolas, Nathalie, Pierre, Romain, Thomas (mais je l’avais déjà cité avant donc ça compte pas) et tous les autres. En vrac, j’en profite pour citer tous les gens qui m’ont aidé, directement ou indirectement, à mener à bien cette thèse : Damien, Clément, Maxime, Paul, Christophe, Thierry, Vanessa, Corinne, Françoise, Guddy, Nicolas, Beberth, Fanny, Fanny, Marine, Pierre, Antoine, Romain, François, Christine, Florian, Jean-Baptiste, Sébastien et tous les autres que j’oublie certainement. Évidemment, je termine par remercier ma famille pour l’accompagnement et le soutien psychologique. Merci à mes parents, beaux-parents, frères, belles-soeurs, beau-frère et tous les autres. Sur ces 3 années la personne la plus importante est sans l’ombre d’un doute Audrey à qui je dois d’en être arrivé là aujourd’hui. C’est grâce à son soutien et à ses encouragements que vous avez la chance ( !) de lire ce bel ouvrage, alors merci à elle ! Puisqu’il me reste un petit peu de place, je me remercie d’être aller au bout de la thèse aussi, parce que dans le fond il n’y a pas de raisons de ne pas le faire. Je remercie également les arbres de me fournir les jolies feuilles utilisées pour ce mémoire. J’aimerais terminer par une citation de Winston Churchill qui prend tout son sens dans le cadre d’une thèse : « Réussir, c’est aller d’échec en échec sans perdre l’enthousiasme. »Table des matières 1 Introduction et contexte 1 1.1 Robotique et mobilité .......................... 2 1.2 Perception pour la robotique mobile .................. 5 1.2.1 Place de la perception ...................... 5 1.2.2 Système de localisation ..................... 6 1.2.3 Extension au multivéhicule ................... 7 1.3 Organisation du mémoire ........................ 8 2 Localisation d’un véhicule 11 2.1 Analyse des capteurs pour la localisation . . . . . . . . . . . . . . . . 13 2.1.1 Capteurs proprioceptifs . . . . . . . . . . . . . . . . . . . . . 13 2.1.2 Capteurs extéroceptifs . . . . . . . . . . . . . . . . . . . . . . 14 2.1.3 Bilan des capteurs . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Méthodes de localisation pour le SLAM . . . . . . . . . . . . . . . . 20 2.2.1 Minimisation globale par ajustement de faisceaux . . . . . . . 21 2.2.2 Filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.3 Bilan des méthodes de localisation . . . . . . . . . . . . . . . 30 2.3 SLAM pour l’EKF dans un contexte de robotique mobile . . . . . . . 31 2.3.1 Prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.2 Mise à jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.3 Spécificité de la vision . . . . . . . . . . . . . . . . . . . . . . 40 3 Gestion de la non linéarité dans le SLAM monoculaire 43 3.1 Erreurs de linéarisation . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.1.1 Constatation du problème . . . . . . . . . . . . . . . . . . . . 44 3.1.2 Étude de la littérature . . . . . . . . . . . . . . . . . . . . . . 52 3.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.2.1 Suivi des amers . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2.2 Mise à jour via le filtre de Kalman . . . . . . . . . . . . . . . 65 3.3 Expérimentations réelles et simulées . . . . . . . . . . . . . . . . . . 70 3.3.1 Trajectoires à faible cadence caméra . . . . . . . . . . . . . . 70 3.3.2 Utilisation d’une carte préalablement construite . . . . . . . . 75 3.3.3 Comparaison avec une approche existante . . . . . . . . . . . 78 3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4 Dérive naturelle du SLAM et inconsistance 85 4.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.1.1 Constatation et origine . . . . . . . . . . . . . . . . . . . . . . 86 4.1.2 Solutions pour éviter l’inconsistance . . . . . . . . . . . . . . 88 4.2 Intégration de la dérive dans le SLAM . . . . . . . . . . . . . . . . . 90viii Table des matières 4.2.1 Modèle de dérive . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2.2 Architecture dédiée . . . . . . . . . . . . . . . . . . . . . . . . 106 4.2.3 Intégration de la dérive . . . . . . . . . . . . . . . . . . . . . 111 4.3 Validation expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.1 Fermeture de boucle . . . . . . . . . . . . . . . . . . . . . . . 115 4.3.2 Intégration d’amers géo-référencés . . . . . . . . . . . . . . . 118 4.4 Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5 Extension du SLAM à une flotte de véhicules 125 5.1 État de l’art du SLAM multivéhicule . . . . . . . . . . . . . . . . . . 127 5.1.1 Centralisé ou décentralisé . . . . . . . . . . . . . . . . . . . . 127 5.1.2 Consanguinité des données . . . . . . . . . . . . . . . . . . . 129 5.1.3 Problèmes de communication . . . . . . . . . . . . . . . . . . 133 5.1.4 Association de données . . . . . . . . . . . . . . . . . . . . . . 134 5.2 Conception d’un algorithme de SLAM décentralisé . . . . . . . . . . 136 5.2.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . 137 5.2.2 Positions initiales inconnues . . . . . . . . . . . . . . . . . . . 143 5.2.3 Résultats préliminaires . . . . . . . . . . . . . . . . . . . . . . 145 5.3 Association de données pour le multivéhicule . . . . . . . . . . . . . 150 5.3.1 Choix de la méthode . . . . . . . . . . . . . . . . . . . . . . . 150 5.3.2 Premiers résultats . . . . . . . . . . . . . . . . . . . . . . . . 153 6 Expérimentations et résultats pour le multivéhicule 157 6.1 Résultats avec simulateur . . . . . . . . . . . . . . . . . . . . . . . . 158 6.1.1 Convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . 159 6.1.2 Changement de l’ordre du convoi . . . . . . . . . . . . . . . . 165 6.2 Résultats avec données réelles . . . . . . . . . . . . . . . . . . . . . . 173 6.2.1 Convoi colonne à deux véhicules . . . . . . . . . . . . . . . . 173 6.2.2 Convoi ligne à deux véhicules . . . . . . . . . . . . . . . . . . 176 6.2.3 Convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . 182 6.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 7 Conclusion et perpespectives 193 7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Bibliographie 201Table des figures 1.1 Évolution des robots industriels en plus de 40 ans . .......... 2 1.2 Robotique domestique et médicale ................... 3 1.3 Des exemples de robots mobiles . . . .................. 4 1.4 Des robots terrestres avec des systèmes de mobilité différents .... 5 1.5 Schéma général d’un système robotique ................ 6 1.6 Coopération dans le cadre d’un système multivéhicule ........ 8 2.1 Fonctionnement d’un GPS RTK avec la correction par la station . . 15 2.2 Problèmes affectant les GPS . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Schématisation des effets de la distorsion . . . . . . . . . . . . . . . . 17 2.4 Schéma de fonctionnement simplifié d’un télémètre laser . . . . . . . 18 2.5 Laser 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6 Résultats de l’ajustement de faisceaux de [Royer et al. 2005] (approximativement 15 cm d’erreur) . . . . . . . . . . . . . . . . . . . . 22 2.7 Résultats de l’EKF de [Féraud 2011] (moins de 8 cm d’erreur) . . . . 27 2.8 Présentation d’un SLAM dans le contexte de l’EKF . . . . . . . . . . 32 2.9 Représentation des repères monde et véhicule et passage de l’un à l’autre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.10 Gestion des deux états en fonction des données fournies par les capteurs 36 2.11 Représentation des repères caméra et image et passage de l’un à l’autre 38 3.1 Initialisation de l’incertitude par une mise à jour de l’EKF . . . . . . 46 3.2 Initialisation de l’incertitude par les jacobiennes . . . . . . . . . . . . 48 3.3 Exemple de simulation d’une projection d’un ellipsoïde dans l’image 49 3.4 Zone de recherche et suivi par les jacobiennes . . . . . . . . . . . . . 50 3.5 Mise à jour avec erreur de linéarisation . . . . . . . . . . . . . . . . . 52 3.6 Paramétrisation inverse et représentation de [Montiel et al. 2006] . . 54 3.7 Exemple 2D pour le calcul de la fenêtre englobante . . . . . . . . . . 58 3.8 Exemples de plans intersectant l’image . . . . . . . . . . . . . . . . . 59 3.9 Zone de recherche et suivi par l’approche géométrique . . . . . . . . 63 3.10 Trajectoire utilisée pour la validation du suivi . . . . . . . . . . . . . 64 3.11 Mise à jour d’un amer suivant différentes observations . . . . . . . . 66 3.12 Les différentes possibilités de mise à jour . . . . . . . . . . . . . . . . 67 3.13 Mise à jour avec application du facteur correctif . . . . . . . . . . . . 68 3.14 Trajectoire suivie avec application ou non du correctif . . . . . . . . 69 3.15 Plate-forme expérimentale PAVIN . . . . . . . . . . . . . . . . . . . 71 3.16 Aperçu de quelques images de l’environnement PAVIN . . . . . . . . 72 3.17 Véhicule électrique VIPALab . . . . . . . . . . . . . . . . . . . . . . 72 3.18 Trajectoires accomplies avec une caméra à 3,75 Hz . . . . . . . . . . 73 3.19 Trajectoires accomplies avec une caméra à moins de 2 Hz . . . . . . 75x Table des figures 3.20 Environnement place de Jaude sous le simulateur . . . . . . . . . . . 76 3.21 Quelques exemples d’images issues de la caméra virtuelle . . . . . . . 77 3.22 Trajectoires suivies par les deux véhicules . . . . . . . . . . . . . . . 78 3.23 Erreur de localisation du second véhicule dans la carte du premier . 78 3.24 Robot utilisé dans cette expérimentation . . . . . . . . . . . . . . . . 79 3.25 Quelques images tirées du jeu de données de Milan . . . . . . . . . . 80 3.26 Odométrie et GPS de la trajectoire de Milan . . . . . . . . . . . . . 81 3.27 Résultats de localisation avec le SLAM monoculaire . . . . . . . . . . 81 3.28 Écart entre la position calculée et la vérité terrain . . . . . . . . . . . 82 3.29 Temps de calcul pris par image pour chaque algorithme . . . . . . . 82 4.1 Exemple de dérive en fonction de la distance parcourue . . . . . . . . 87 4.2 Exemple de différentes réalisations d’un biais unidimensionnel . . . . 96 4.3 Exemple de localisation 1D d’un véhicule avec intégration du biais . 97 4.4 Exemple d’évolution de l’incertitude d’un biais 1D . . . . . . . . . . 97 4.5 Exemple de localisation 1D d’un véhicule avec correction du biais . . 98 4.6 Exemple d’évolution et de correction de l’incertitude d’un biais 1D . 98 4.7 Trajectoire de simulation . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.8 Différentes réalisations de trajectoires . . . . . . . . . . . . . . . . . . 100 4.9 Trajectoire de simulation utilisée . . . . . . . . . . . . . . . . . . . . 101 4.10 Trajectoire calculée sans translation à l’origine . . . . . . . . . . . . 102 4.11 Trajectoire calculée avec translation à l’origine . . . . . . . . . . . . 103 4.12 Trajectoires sans associations de données . . . . . . . . . . . . . . . . 104 4.13 Trajectoires après la première boucle . . . . . . . . . . . . . . . . . . 104 4.14 Trajectoires complètes après la première boucle . . . . . . . . . . . . 105 4.15 Trajectoires estimées après les deux boucles . . . . . . . . . . . . . . 106 4.16 Organisation globale du système . . . . . . . . . . . . . . . . . . . . 107 4.17 Interactions entre les deux niveaux de l’architecture . . . . . . . . . . 108 4.18 État du système après une nouvelle convergence . . . . . . . . . . . . 109 4.19 Fonctionnement de l’algorithme haut niveau . . . . . . . . . . . . . . 110 4.20 Inconsistance et dérive du SLAM bas niveau . . . . . . . . . . . . . . 116 4.21 Prise en compte de la dérive sans fermeture de boucle . . . . . . . . 116 4.22 Prise en compte de la dérive avec fermeture de boucle . . . . . . . . 117 4.23 Écart de position entre le GPS RTK et le SLAM dans le cadre d’une fermeture de boucle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.24 Localisation obtenue sans intégrer les amers géo-référencés . . . . . . 120 4.25 Localisation obtenue avec intégration d’amers géo-référencés . . . . . 121 4.26 Écart de position entre le GPS RTK et le SLAM lors de l’intégration d’amers géo-référencés . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.1 Schéma simplifié d’un système centralisé . . . . . . . . . . . . . . . . 127 5.2 Schéma simplifié d’un système décentralisé . . . . . . . . . . . . . . . 128 5.3 Consanguinité dans le SLAM . . . . . . . . . . . . . . . . . . . . . . 131 5.4 Algorithme GCBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Table des figures xi 5.5 Séparation en sous-cartes afin d’éviter la consanguinité . . . . . . . . 139 5.6 Architecture de SLAM décentralisée pour un exemple à 2 véhicules . 140 5.7 Exemple d’inclusion d’un a priori dans le biais . . . . . . . . . . . . . 144 5.8 Initialisations possibles pour le biais . . . . . . . . . . . . . . . . . . 145 5.9 Trajectoire en convoi colonne . . . . . . . . . . . . . . . . . . . . . . 146 5.10 Temps de calcul requis par le processus décentralisé . . . . . . . . . . 147 5.11 Bande passante utilisée lors de la trajectoire . . . . . . . . . . . . . . 148 5.12 Trajectoire en convoi ligne . . . . . . . . . . . . . . . . . . . . . . . . 149 5.13 Exemple d’utilisation de l’algorithme GCBB . . . . . . . . . . . . . . 152 5.14 Associations trouvées entre deux passages . . . . . . . . . . . . . . . 154 6.1 Environnement PAVIN sous le simulateur . . . . . . . . . . . . . . . 159 6.2 Quelques exemples d’images issues de la caméra virtuelle sur PAVIN 159 6.3 Aperçu des trajectoires du scénario convoi colonne simulé . . . . . . 160 6.4 Trajectoires obtenues par le SLAM bas niveau pour le scénario convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 6.5 Intégration du biais pour le véhicule de tête dans le scénario convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.6 Intégration du biais pour le véhicule de queue dans le scénario convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 6.7 Localisation avec association de données pour le convoi colonne simulé163 6.8 Distance entre les véhicules en fonction du temps pour le convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.9 Quantité de données envoyées en fonction du temps pour le convoi colonne simulé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 6.10 Aperçu des trajectoires du scénario d’inversion de convoi . . . . . . . 166 6.11 Trajectoires obtenues par le SLAM bas niveau pour le scénario d’inversion de convoi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 6.12 Intégration du biais dans le scénario d’inversion de convoi (1/2) . . . 168 6.13 Intégration du biais dans le scénario d’inversion de convoi (2/2) . . . 168 6.14 Localisation avec association de données pour l’inversion de convoi . 170 6.15 Amers cartographiés pour le scénario d’inversion de convoi . . . . . . 171 6.16 Distance entre les véhicules en fonction du temps pour le scénario d’inversion de convoi . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 6.17 Quantité de données envoyées en fonction du temps pour l’inversion de convoi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 6.18 Aperçu des trajectoires du scénario convoi colonne . . . . . . . . . . 174 6.19 Trajectoires obtenues par le SLAM bas niveau pour le scénario convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 6.20 Intégration du biais pour le véhicule de tête dans le scénario convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 6.21 Intégration du biais pour le véhicule de queue dans le scénario convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 6.22 Localisation avec association de données pour le convoi colonne réel . 177xii Table des figures 6.23 Distance entre les véhicules en fonction du temps pour le convoi colonne178 6.24 Quantité de données envoyées en fonction du temps pour le convoi colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 6.25 Aperçu des trajectoires du scénario convoi ligne . . . . . . . . . . . . 179 6.26 Trajectoires obtenues par le bas niveau pour le scénario convoi ligne 179 6.27 Intégration du biais pour le véhicule de droite dans le convoi ligne . . 180 6.28 Intégration du biais pour le véhicule de gauche dans le convoi ligne . 180 6.29 Localisation avec association de données pour le convoi ligne . . . . . 181 6.30 Distance entre les véhicules en fonction du temps pour le convoi ligne 182 6.31 Quantité de données envoyées en fonction du temps pour le convoi ligne183 6.32 Aperçu des trajectoires du scénario à 3 véhicules . . . . . . . . . . . 183 6.33 Trajectoires obtenues par le bas niveau pour le convoi à trois véhicules184 6.34 Intégration du biais pour le véhicule de queue dans le scénario convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 6.35 Localisation avec associations pour le convoi à trois véhicules . . . . 186 6.36 Localisation avec association de données pour le véhicule de queue dans le convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . 187 6.37 Profil de distance en fonction du temps pour le convoi à trois véhicules189 6.38 Quantité de données envoyées au cours du temps pour le convoi à trois véhicules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Liste des tableaux 3.1 Comparatif des deux méthodes de suivi . . . . . . . . . . . . . . . . 64 3.2 Comparatif des deux méthodes pour les mises à jour . . . . . . . . . 70 3.3 Amers utilisés sur une trajectoire réelle avec une caméra à 3,75 Hz . 74 4.1 Estimation du biais au point de bouclage (sans translation à l’origine) 101 4.2 Estimation du biais au point de bouclage (avec translation à l’origine) 103 5.1 Erreur quadratique moyenne du biais pour le convoi colonne . . . . . 147 5.2 Erreur quadratique moyenne du biais pour le convoi ligne . . . . . . 149Chapitre 1 Introduction et contexte Sommaire 1.1 Robotique et mobilité ....................... 2 1.2 Perception pour la robotique mobile .............. 5 1.2.1 Place de la perception ...................... 5 1.2.2 Système de localisation ..................... 6 1.2.3 Extension au multivéhicule ................... 7 1.3 Organisation du mémoire ..................... 82 Chapitre 1. Introduction et contexte 1.1 Robotique et mobilité La robotique est un domaine dont le nombre d’applications est en augmentation constante depuis son invention. Cet essor découle essentiellement du besoin d’automatiser des tâches répétitives et difficiles. En plus d’épargner des travaux physiquement épuisants à l’Homme, la robotique permet également d’effectuer de substantielles économies dans un monde de plus en plus compétitif et ouvert. Au fur et à mesure que des progrès ont été faits, la diversité des situations où la robotique était applicable a créé de nouvelles branches plus spécialisées, chacune avec ses objectifs et contraintes bien particuliers. Le travail à la chaîne a, en grande partie, été supplanté par la robotique industrielle. Des bras manipulateurs sont maintenant utilisés afin de tordre, percer, peindre, assembler ou encore déplacer les matériaux nécessaires à l’élaboration d’un produit commercialisable (voir figure 1.1). La miniaturisation des composants ainsi que la croissante fiabilité des technologies employées ont largement contribué à la diffusion de ces robots, tout comme à leur acceptation auprès des professionnels puis du grand public. (a) Robot Unimate, commercialisé en 1961 (b) Robot Adapt Quattro, conçu en 2007 Figure 1.1 – Évolution des robots industriels en plus de 40 ans Des machines intelligentes ont peu à peu été intégrées un peu partout. Le pan de la robotique domestique en est un bon exemple avec l’arrivée et la diffusion récente d’aspirateurs capables de nettoyer plusieurs pièces quotidiennement sans aucune intervention humaine (figure 1.2). Il s’agit certainement du type de robot le plus populaire actuellement. Il est aussi l’un des rares robots ménagers à exister. En effet, la limite de ces machines est souvent liée à la notion d’autonomie : elles doivent être suffisamment intelligentes pour ne pas nécessiter de présence humaine pour fonctionner. Cela est souvent difficile à accomplir avec des machines de petite taille qui ont des ressources limitées. À l’inverse, les robots à visée médicale sont majoritairement conçus pour être1.1. Robotique et mobilité 3 utilisés par des médecins et non en complète autonomie. Le but est souvent de faciliter le travail du chirurgien en fournissant des nouveaux moyens d’interagir avec les patients (figure 1.2). (a) Roomba, vendu à plus de 5 millions d’exemplaires en 2009 (b) Da Vinci, 1750 exemplaires utilisés en 2011 Figure 1.2 – Robotique domestique et médicale Globalement, il est possible de construire deux grandes catégories pour regrouper les robots : ceux mobiles, dont fait partie le Roomba par exemple, et ceux fixes (bras manipulateurs, machines médicales...). La mobilité peut être gérée de deux manières différentes : soit en téléopérant le robot, soit en le dotant d’une autonomie suffisante de manière à ce qu’il puisse se déplacer seul dans un environnement donné. Ce dernier cas implique que la machine soit suffisamment “intelligente” pour comprendre l’environnement qui l’entoure. De manière réductrice, un aspirateur autonome doit être capable d’éviter tous les objets d’une pièce, qu’ils soient fixes ou mobiles, de parcourir l’intégralité de la surface à nettoyer et de revenir à sa station de recharge. Chacune de ces actions nécessite de prendre des décisions par rapport aux informations disponibles à un moment donné. Une grande variété est à noter dans la forme et la façon de se mouvoir de ces robots. Cela est fortement conditionné par l’environnement applicatif visé. De fait, la communauté scientifique sépare souvent les robots mobiles en trois grandes branches : les robots terrestres (d’intérieur ou d’extérieur), les robots aériens et enfin les robots sous-marins (voir figure 1.3). Cette catégorisation vient aussi du fait qu’il est extrêmement difficile de concevoir une intelligence qui puisse s’adapter à plusieurs milieux. Souvent, les équipes de recherche travaillant sur des environnements différents sont bien distinctes. La catégorie “terrestre”, dont ce manuscrit va traiter, se divise encore en fonction du moyen de déplacement du robot. Des chenilles, des pattes ou même des jambes peuvent être utilisées comme le montre la figure 1.4, même si le plus courant reste encore les roues. Le type de sol sur lequel le robot est amené à évoluer influe grande-4 Chapitre 1. Introduction et contexte (a) Cybercar de l’INRIA (b) Aeryon Scout de Aeryon Labs (c) SeaExplorer par ACSA Figure 1.3 – Des exemples de robots mobiles ment sur la motorisation de celui-ci. Par ailleurs, les besoins sont très différents dans un milieu urbain et dans un contexte désertique par exemple. Les environnements ruraux sont également différenciés des autres puisque le manque de structure du sol poussent généralement à développer des véhicules bien plus volumineux que dans les autres milieux. Les objectifs attribués à ces robots terrestres peuvent être variés. On peut noter le transport de marchandises, une visée éducative ou encore tout simplement le divertissement. Bien évidemment, ce sont loin d’être les seuls domaines où ils sont utilisés. Les systèmes de surveillance en font un usage croissant, tout comme le milieu agricole. De même, le transport de personnes (Intelligent Transportation Systems ou ITS en anglais) est souvent au coeur des problématiques associées à la robotique mobile. La mobilité est un aspect essentiel de cette thèse. En effet, le but est ici de faire collaborer des véhicules afin qu’ils soient à même de savoir où ils se situent les uns par rapport aux autres. Le cadre est bien ici les robots terrestres. De manière plus précise, ces derniers peuvent être assimilés à des véhicules puisque l’on s’oriente vers des robots capables de transporter des personnes ou des marchandises. Cela implique des robots faisant une certaine taille mais ne définit pas pour autant la vitesse de ceux-ci. Dans le cadre du transport de personnes par exemple, la vitesse d’un véhicule peut facilement varier de quelques kilomètres par heure pour une1.2. Perception pour la robotique mobile 5 (a) NAO, petit robot humanoïde (b) BigDog, robot quadrupède pour le transport de matériel (c) Morph, robot à chenilles de LEGO Mindstorms Figure 1.4 – Des robots terrestres avec des systèmes de mobilité différents voiturette de golf à plus de 130 km/h pour une voiture plus classique. Cet écart a une grande influence sur la façon dont le système est conçu, tout comme sur le design de l’algorithmie destinée à l’animer. Dans tous les cas, le système de perception du véhicule doit être capable de fournir des informations suffisamment détaillées pour permettre des actions complexes en toute sécurité. 1.2 Perception pour la robotique mobile 1.2.1 Place de la perception Tout système de robotique mobile, voire de robotique, s’inscrit dans une logique perception - contrôle - action. Le schéma de la figure 1.5 montre les interactions entre ces différents modules. Son fonctionnement est simple : l’analyse de l’environnement ainsi que du véhicule lui-même constitue la partie perception. Ces informations vont6 Chapitre 1. Introduction et contexte permettre au module de contrôle de décider de l’action à accomplir. Celle-ci sera, bien entendu, réalisée par la partie éponyme. Le retour de la dite action pourra ou non être communiqué à la perception afin d’orienter l’analyse. De manière similaire, le contrôle et la perception peuvent être amenés à échanger de l’information afin de valider ou de rejeter une première décision prise. L’ajout d’informations du côté de la perception peut en effet complètement changer le résultat de l’algorithme de contrôle. Figure 1.5 – Schéma général d’un système robotique Considérons une application dont l’objectif est de rejoindre un point précis, tout en évitant d’écraser des piétons (ce qui est tout à fait louable). Le module de perception aura, dans ce cas, pour but principal de détecter les piétons à l’aide de capteurs (une caméra par exemple) tout en se localisant dans l’environnement. La partie contrôle quant à elle, devra décider du chemin à emprunter afin d’éviter les passants dont la détection aura été fournie par la perception. Enfin, la trajectoire validée sera effectuée au sein de la brique action qui devra traduire en commandes pour le véhicule le parcours donné par le module de contrôle. Le déplacement réellement effectué pourra être transféré à la perception afin de calculer la position des piétons précédemment détectés et ainsi vérifier leur présence pour la nouvelle position du robot. Le schéma général itérera jusqu’au point d’arrivée. 1.2.2 Système de localisation Dans ce manuscrit, nous nous concentrerons majoritairement sur le module de perception. L’objectif étant de pouvoir localiser précisément les membres d’une flotte de véhicules, la fusion des données issues des capteurs est un point central. La partie guidage automatique ainsi que la prise de décision relative à des événements (évitement d’obstacles, détection de dangers...) sont des aspects qui ne seront pas abordés ici. Le système de perception qui sera présenté tout au long de ce mémoire peut1.2. Perception pour la robotique mobile 7 être assimilé à un système de localisation, l’objectif étant de savoir où se situe chacun des véhicules d’une flotte. Pour ce faire, il est nécessaire d’équiper ces robots avec des capteurs de manière à ce qu’ils se repèrent dans l’environnement. Il en existe différentes sortes, à des prix très variables, chacun ayant ses avantages et ses défauts. Deux catégories sont généralement utilisées pour les regrouper : les capteurs dits proprioceptifs et extéroceptifs. Les premiers donnent des informations sur l’état même du véhicule. On retrouve, entre autres, les odomètres qui renseignent sur le déplacement effectué entre deux moments successifs (mesure relative) et les centrales inertielles qui elles permettent d’obtenir les vitesses linéaires et angulaires d’un robot mobile. La seconde catégorie regroupe tous les capteurs permettant d’avoir des informations à l’aide de l’environnement. Les GPS en sont un bon exemple puisqu’ils utilisent des satellites afin d’obtenir une position absolue à un instant donné. Dans le cadre de la localisation d’un véhicule, les capteurs extéroceptifs (hormis les GPS) sont souvent utilisés pour reconnaître des portions de l’environnement déjà vues auparavant. La mesure du décalage d’une entité dans plusieurs données issues du capteur va permettre de déduire le déplacement du robot. Il est également possible d’identifier directement un véhicule distant et ainsi d’en inférer sa position relativement au capteur ayant servi à le détecter. Les plus communément employés sont les caméras, les télémètres et les radars. Les intérêts de chacun de ces capteurs seront développés ultérieurement dans ce manuscrit et ce relativement à l’algorithme de localisation que l’on cherche à construire. 1.2.3 Extension au multivéhicule Au cours des dernières décennies, la communauté autour de la robotique mobile s’est essentiellement concentrée sur la localisation d’un unique véhicule. L’extension de ces algorithmes vers des applications nécessitant plusieurs véhicules n’a été envisagée que très récemment. Pourtant, de nombreuses situations nécessitent, ou peuvent tirer avantage, d’un ensemble de robots fonctionnant de manière coopérative via des communications sans fil (voir figure 1.6). Parmi les applications citées précédemment, les ITS tirent naturellement parti d’une extension à plusieurs véhicules. Un système de localisation efficace pourrait à terme conduire à des voitures entièrement autonomes. Le milieu agricole est également concerné par l’utilisation d’une flotte de robots. En effet, plutôt que d’utiliser une seule grosse machine, il est envisageable de se tourner vers une multitude de plus petits robots, chacun s’occupant, par exemple, d’un unique sillon. L’intérêt ici serait surtout d’éviter la compaction des sols causée par les machines volumineuses. De nombreuses autres possibilités pourraient être citées puisque le fait d’avoir plusieurs véhicules permet à la fois d’être plus rapide pour couvrir une zone et d’être plus précis dès lors qu’au moins deux véhicules passent au même endroit. Néanmoins, le fait que l’émergence de ces systèmes soit très récente n’est pas anodin. D’importantes contraintes rendent la tâche beaucoup plus compliquée qu’avec8 Chapitre 1. Introduction et contexte Figure 1.6 – Coopération dans le cadre d’un système multivéhicule un seul véhicule. La présence d’une couche réseau est un premier point. Il faut concevoir l’application de telle sorte qu’elle soit capable de gérer les ruptures de communication qui peuvent intervenir. De même, les latences ainsi que les désynchronisations doivent être prises en compte. Il faut aussi décider de quelles informations envoyer et quand. En effet, la bande passante nécessaire à l’envoi et à la réception de données n’est pas infinie et dépend fortement du nombre de véhicules impliqués dans les échanges. La sélection des informations à envoyer joue également un rôle crucial dans la façon dont vont pouvoir être calculées les positions des robots. Sans a priori initial, un véhicule devra également être capable de situer chaque robot par rapport à lui-même, ce qui requiert des algorithmes robustes. De manière similaire à la bande passante, le coût calculatoire doit être au centre de la conception de l’application multivéhicule, la gestion des localisations des membres de la flotte induisant un surcoût non négligeable. Enfin, il faut aussi garder en tête le coût financier afin de rendre l’application commercialement viable. Chaque véhicule étant amené à embarquer des capteurs, il faudra être prudent lors du choix de ceux-ci car la solution globale verra son prix multiplié par le nombre de robots de la flotte. L’ensemble de ces points sera traité dans ce mémoire. 1.3 Organisation du mémoire Avant même de développer un système multivéhicule, il est nécessaire de construire un algorithme où chaque robot est capable d’estimer sa propre position. Cela sera l’objet du chapitre 2. Bien évidemment, le design d’un tel processus sera fait en fonction des contraintes fixées par l’application multivéhicule (coût fi- nancier, temps de calcul, quantité d’informations à traiter...). Pour ce faire, nous présenterons d’abord les capteurs utilisés puis l’algorithme de localisation employé. Les problématiques amenées par les choix faits seront étudiées lors du chapitre 3. Dans celui-ci, les améliorations apportées au système monovéhicule seront détaillées.1.3. Organisation du mémoire 9 L’algorithme construit sera ensuite testé dans des situations variées afin de valider les différentes innovations présentées au fur et à mesure du chapitre. Le chapitre suivant (chap. 4) se concentrera sur la dérive naturelle de ces algorithmes de localisation. Ce point est crucial car la divergence de ces systèmes se retrouve exacerbée lors de l’extension au multivéhicule. Un état de l’art sera dressé et une solution ainsi que son intégration seront proposées. L’extension au cas multivéhicule sera décrite durant le chapitre 5. Après une analyse de la littérature dans le domaine, une architecture résolvant les différentes problématiques citées précédemment sera présentée. L’estimation de la localisation des robots d’une même flotte sera également largement abordée. Bien que chaque contribution soit validée au fur et à mesure du mémoire (via simulation ou avec des expérimentations réelles) le chapitre 6 présentera les résultats globaux de l’algorithme multivéhicule développé. Divers exemples de trajectoires dans des situations variées seront exposés afin de démontrer l’efficacité de notre application. Enfin, le chapitre 7 proposera une synthèse des résultats obtenus ainsi que des limites de l’application conçue. Les perspectives d’évolution de l’algorithme seront également abordées.Chapitre 2 Localisation d’un véhicule Sommaire 2.1 Analyse des capteurs pour la localisation . . . . . . . . . . . 13 2.1.1 Capteurs proprioceptifs . . . . . . . . . . . . . . . . . . . . . 13 2.1.1.1 Capteurs inertiels . . . . . . . . . . . . . . . . . . . 13 2.1.1.2 Odomètre et angle volant . . . . . . . . . . . . . . . 13 2.1.2 Capteurs extéroceptifs . . . . . . . . . . . . . . . . . . . . . . 14 2.1.2.1 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.2.2 Caméra . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.2.3 Télémètre laser . . . . . . . . . . . . . . . . . . . . . 17 2.1.2.4 Radar . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.3 Bilan des capteurs . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Méthodes de localisation pour le SLAM . . . . . . . . . . . . 20 2.2.1 Minimisation globale par ajustement de faisceaux . . . . . . . 21 2.2.2 Filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2.1 Filtre de Kalman . . . . . . . . . . . . . . . . . . . . 23 2.2.2.2 Filtre de Kalman étendu . . . . . . . . . . . . . . . 25 2.2.2.3 Filtre de Kalman sans parfum . . . . . . . . . . . . 28 2.2.2.4 Filtre d’information . . . . . . . . . . . . . . . . . . 29 2.2.2.5 Filtre particulaire . . . . . . . . . . . . . . . . . . . 30 2.2.3 Bilan des méthodes de localisation . . . . . . . . . . . . . . . 30 2.3 SLAM pour l’EKF dans un contexte de robotique mobile . 31 2.3.1 Prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.2 Mise à jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.3 Spécificité de la vision . . . . . . . . . . . . . . . . . . . . . . 4012 Chapitre 2. Localisation d’un véhicule Construire un algorithme de localisation multirobot nécessite avant toute chose que chaque véhicule soit capable de se localiser. En effet, cette information de position sera partagée avec les autres membres de la flotte et devra être la plus juste possible. Au-delà même de ces considérations, façonner la partie monovéhicule pour qu’elle soit en adéquation avec son extension à plusieurs robots est essentiel. Chacun des choix concernant les aspects plus bas niveau va régir les performances globales de l’application multivéhicule. Afin de prendre une décision éclairée, il convient de définir le cadre applicatif de nos développements. En effet, celui-ci va permettre de fixer les contraintes gé- nérales de notre système multivéhicule et donc orienter le choix des capteurs et de la méthode de localisation monovéhicule. L’objectif est de construire un système de localisation suffisamment général pour qu’il puisse ensuite être adapté à des applications bien précises. Cela implique que le nombre de véhicules peut être élevé et qu’il est donc important de limiter la quantité de données à échanger. Dans un contexte agricole par exemple, plus d’une dizaine de robots pourraient être utilisés en parallèle. On peut aussi imaginer un système de transport de personnes, dédié à une zone géographique précis, qui nécessiterait un volume de véhicules similaire. Ces deux exemples sont intéressants puisqu’ils permettent aussi de constater que l’environnement peut être varié. Dans le contexte urbain, beaucoup d’informations peuvent être exploitées afin d’aider la localisation. Cela sera un peu moins le cas dans des environnements plus ouverts. Il faudra donc être vigilant à ce que la méthode et les capteurs choisis puissent opérer dans des contextes différents. Au niveau de la vitesse des véhicules, celle-ci sera peu élevée (autour de 2 mètres par seconde) afin de permettre une première validation dans des conditions maîtrisées. Enfin du point de vue de la justesse de localisation souhaitée, il est difficile de définir un ordre de grandeur car celui-ci dépend de la tâche visée. Néanmoins, il est essentiel que le système développé puisse être spécialisé pour atteindre des précisions autorisant la conduite automatique (autour de la vingtaine de centimètres) lorsque cela est possible car de nombreuses applications en découlent. Ce chapitre sera entièrement consacré à la conception de l’algorithme de localisation monovéhicule. Les différents choix technologiques seront toujours étudiés par rapport à la littérature ainsi qu’en relation avec l’impact qu’ils auront sur le multivéhicule. La section 2.1 présentera les différents capteurs disponibles pour la localisation. La section qui suit (section 2.2) se concentrera quant à elle sur les mé- thodes pour la localisation. La section 2.3 exposera ensuite le fonctionnement de la solution envisagée, tout d’abord de façon générale dans les sous-sections 2.3.1 et 2.3.2, puis par rapport aux capteurs sélectionnés (sous-section 2.3.3).2.1. Analyse des capteurs pour la localisation 13 2.1 Analyse des capteurs pour la localisation La localisation d’un unique véhicule est donc un domaine qui est aujourd’hui devenu un point central de la robotique mobile. De nombreux chercheurs travaillent sur cette thématique, que cela soit du côté de la conception des capteurs ou encore dans l’élaboration de méthodes pour la localisation. Afin de faciliter la compréhension, ces deux parties seront séparées mais traitées en relation l’une avec l’autre dans la suite de cette section. Comme énoncé précédemment, on distingue généralement les capteurs proprioceptifs, renseignant sur l’état même du robot, de ceux dits extéroceptifs qui donnent des informations sur l’environnement. Nous allons commencer par étudier la première catégorie. 2.1.1 Capteurs proprioceptifs 2.1.1.1 Capteurs inertiels Les capteurs inertiels exploitent des propriétés physiques pour extraire les accé- lérations (accéléromètres) ou les rotations (gyroscopes, gyromètres). Les centrales inertielles peuvent être considérées comme des capteurs, quand bien même il s’agit plus d’un regroupement de capteurs. En effet, celles-ci embarquent 3 gyromètres ainsi que 3 accéléromètres. Cela permet d’estimer les vitesses (linéaire et angulaire) ainsi que la pose complète d’un mobile, c’est-à-dire la position 3D et les 3 angles associés (roulis, tangage, lacet). L’intégration au cours du temps des mesures fournies par la centrale inertielle donne des résultats généralement satisfaisants. Bien évidemment, la qualité des capteurs qui la compose va fortement influencer la précision. Le prix est donc un aspect important lors du choix d’une centrale inertielle. Il est également possible d’utiliser uniquement des gyromètres sans centrale inertielle ce qui permet souvent d’avoir de meilleurs résultats avec un coût similaire. Hormis le prix, les capteurs inertiels sont affectés par des erreurs cumulatives. Ceux-ci ne fournissent pas de valeurs absolues mais quantifient des mouvements. Ainsi, si une erreur de mesure est faite à un instant donné, elle sera conservée dans toutes les estimations suivantes. Afin de compenser ce problème, les capteurs inertiels sont souvent couplés avec d’autres informations. 2.1.1.2 Odomètre et angle volant La mesure odométrique est à rapprocher des informations obtenues en sortie d’une centrale inertielle. Des capteurs, équipés sur les roues d’un véhicule, permettent de quantifier le déplacement accompli. Le principal avantage d’un odomètre est son coût ainsi que le fait qu’il est maintenant équipé en standard sur les véhicules. Il est généralement associé au capteur d’angle volant qui comme son nom l’indique renseigne sur l’angle de braquage des roues. Ces deux informations, couplées à un modèle d’évolution du robot, permettent d’obtenir des résultats de localisation convenable.14 Chapitre 2. Localisation d’un véhicule Néanmoins, tout comme les capteurs inertiels, les informations odométriques correspondent à des déplacements successifs rendant les erreurs cumulatives au fil du temps. Sur de longues distances, les écarts entre ce qui est estimé par odométrie et ce qui est réellement parcouru deviennent considérables. Les données odométriques (déplacement et angle de braquage) seront ainsi très souvent utilisées pour une première estimation qui sera ensuite affinée via un autre capteur. Contrairement à la centrale inertielle en revanche, uniquement le cap du robot (lacet) et la distance parcourue peuvent être estimés via l’odométrie. 2.1.2 Capteurs extéroceptifs Les différents capteurs présentés jusqu’ici sont ceux principalement utilisés pour renseigner l’état du véhicule. Les suivants rentrent, quant à eux, dans la catégorie des extéroceptifs. Les utiliser induit bien souvent de suivre des objets de l’environnement afin d’obtenir une information de déplacement. Généralement, ces données sont stockées dans ce qui est appelé une carte. Celle-ci peut être construite et utilisée en temps réel ou être fournie au véhicule et exploitée par l’algorithme de localisation. Parmi ceux présentés, le GPS fait figure d’exception puisqu’il fournit des informations absolues et non relatives. 2.1.2.1 GPS Le GPS (Global Positioning System) est très certainement le capteur de positionnement le plus populaire. Ce système de localisation par satellites permet d’obtenir une position absolue dont la précision varie en fonction du nombre de satellites disponibles. Le principe de fonctionnement est le suivant : des satellites parfaitement localisés transmettent en permanence leur position ainsi que la date associée à celleci. Un récepteur décode les signaux reçus et peut ainsi estimer, par triangulation, sa position sur la planète. Créé à des fins militaires, le système GPS s’est ensuite ouvert aux civils avec des précisions volontairement dégradées. En 2000, cette contrainte a été levée permettant ainsi d’atteindre une précision d’une dizaine de mètres. Cela s’avère généralement suffisant comme aide à la navigation, d’autant plus que la position est généralement corrigée par la mise en correspondance avec la route. La dénomination de GPS est quelque peu trompeuse puisque plusieurs systèmes du même acabit existent. On peut citer GLONASS, Beidou et Galileo (qui n’est pas encore opérationnel) qui sont les équivalents russe, chinois et européen du système GPS américain. Ceux-ci offrent une précision similaire au GPS, voire même légèrement meilleure sous certaines conditions dans le cas de Galileo. Quelque soit le système de positionnement utilisé, il est important de noter que la qualité de la localisation fournie dépend du nombre de satellites disponibles. Pour des applications visant à la conduite de manière autonome, cette précision est loin d’être suffisante. Des solutions, toujours basées sur les GPS, permettent d’améliorer ce point. Les GPS RTK (Real Time Kinematic) utilisent une station2.1. Analyse des capteurs pour la localisation 15 terrestre dont la position est parfaitement connue. Celle-ci envoie les correctifs à appliquer au récepteur GPS afin d’améliorer la précision (voir figure 2.1). Cela permet d’obtenir des positions justes au centimètre près. Néanmoins, ces systèmes sont extrêmement onéreux. Ces capteurs sont souvent utilisés comme vérité terrain afin de quantifier la justesse de résultats de localisation. Figure 2.1 – Fonctionnement d’un GPS RTK avec la correction par la station La localisation absolue fournie par des GPS bas coûts, bien qu’imprécise rend beaucoup plus facile le travail coopératif puisque toutes les positions sont données dans un même référentiel. Néanmoins, les GPS souffrent d’autres désavantages. Les deux principaux sont les multitrajets et les pertes du signal dans des environnements cloisonnés. Dans le premier cas, les signaux émis par les satellites sont réfléchis par des bâtiments au lieu d’être reçus directement par le GPS. Ainsi, le temps de vol est allongé et l’estimation de la position est biaisée. Ce phénomène est dangereux car le récepteur n’est pas conscient de cette erreur de positionnement : il y a perte de l’intégrité (la position réelle du véhicule n’est pas située dans l’incertitude de mesure). Des solutions palliatives existent néanmoins afin de contrer ce problème comme la technologie RAIM (Receiver Autonomous Integrity Monitoring) qui utilise la redondance d’information pour lever l’ambiguïté. Le deuxième cas est différent. Il correspond à la perte du signal GPS à cause d’un environnement qui masque les satellites. Cela apparaît souvent en milieu urbain à cause des bâtiments. On parle de canyon urbain. Une vue schématique de ces deux problèmes est donnée en figure 2.2.16 Chapitre 2. Localisation d’un véhicule (a) Erreur de positionnement à cause de multitrajets (ligne réfléchie en pointillés) (b) Perte du positionnement à cause d’un canyon urbain Figure 2.2 – Problèmes affectant les GPS 2.1.2.2 Caméra Les caméras commencent à occuper l’habitacle de nos voitures depuis quelques années maintenant. Elles ont un faible coût et fournissent beaucoup de données. L’information visuelle étant celle sur laquelle l’humain se base le plus, il est naturel de s’orienter vers ces capteurs pour des applications de localisation. Le principe est souvent le suivant : extraire des objets statiques dans l’image qui soient facilement reconnaissables et les suivre. En mesurant les écarts dans l’image entre les positions successives des objets, il est possible de déduire le déplacement du véhicule. L’intérêt majeur des caméras est de fournir beaucoup d’informations qui, regroupées en sousensembles de pixels, sont assez facilement différentiables. Parmi les contraintes de ces capteurs, il faut tout de même noter une phase d’étalonnage. Celle-ci permet de passer les informations de l’image, exprimées en pixels, dans un repère métrique plus classique. Cette étape est essentielle pour pouvoir mesurer les déplacements du véhicule. Les paramètres permettant d’inférer ce changement de repère sont appelés paramètres intrinsèques de la caméra. En plus de ceux-ci, on mesure généralement la position de la caméra par rapport au véhicule afin de pouvoir coupler les informations visuelles avec des données provenant d’un autre capteur. Ce nouveau changement de repère est régi par les paramètres extrinsèques de la caméra. Ceux-ci sont aussi estimés durant la phase d’étalonnage. Cette dernière sert aussi à estimer la distorsion qui affecte l’image (voir figure 2.3). Ce défaut optique, s’il n’est pas pris en compte, peut conduire à des problèmes de suivi. Les caméras sont grandement affectées par les conditions météorologiques. En effet, une forte pluie, un soleil éclatant ou encore des chutes de neige rendent le suivi d’objets plus difficile. Ce ne sont pas les seuls aspects ayant un impact sur la qualité2.1. Analyse des capteurs pour la localisation 17 (a) Distorsion de type barillet (b) Distorsion de type croissant Figure 2.3 – Schématisation des effets de la distorsion de l’image. On peut par exemple citer : le flou, la résolution du capteur, le temps de prise de vue et de saturation, etc. Les algorithmes construits doivent être robustes afin de résister à de telles conditions. L’utilisation d’une unique caméra pose le problème de l’estimation de la distance des objets. À partir d’une seule image, la profondeur ne peut être déterminée. C’est pourquoi une paire stéréoscopique (deux caméras) est souvent utilisée. Celle-ci permet de trianguler la position d’un objet dès lors qu’il apparaît dans le champ de vue des deux caméras. Un compromis doit être fait sur l’écart entre les caméras : plus elles sont éloignées, plus l’estimation sera précise (parallaxe suffisante) et à l’inverse plus elles sont proches et plus le champ recouvrant nécessaire à l’estimation de la profondeur sera important. L’étalonnage joue un rôle clef pour une paire stéréoscopique car il permet de synchroniser les deux caméras afin qu’elles délivrent des images sur la même base de temps. Grâce à ce procédé, les informations extraites dans chaque caméra peuvent être comparées. 2.1.2.3 Télémètre laser Les télémètres laser, souvent abrégés LRF pour Laser RangeFinders, sont une alternative intéressante aux caméras puisqu’ils fournissent directement la distance des objets par rapport au capteur. Le principe est simple : un faisceau laser est émis sur un miroir rotatif permettant ainsi de balayer l’environnement de 90 à 270˚en fonction du télémètre. Le faisceau laser est réfléchi dès lors qu’un obstacle est percuté. Au retour, le temps de vol est mesuré et ainsi, la distance de l’obstacle peut être connue. La figure 2.4 propose un schéma de fonctionnement simplifié d’un LRF. Le télémètre laser généralement employé dans la robotique mobile fournie une seule nappe et permet ainsi de n’avoir des informations que sur un seul plan. Ce capteur reste cependant assez cher même si la précision des données est très bonne. La résolution du télémètre laser peut également être problématique. Celle-ci est généralement de l’ordre de quelques points par degré. Reconnaître des objets préalablement18 Chapitre 2. Localisation d’un véhicule (a) (b) Figure 2.4 – Schéma de fonctionnement simplifié d’un télémètre laser détectés devient alors plus difficile puisqu’ils seront uniquement identifiables grâce à faible nombre de points. Des télémètres laser à plusieurs nappes existent, permettant ainsi d’avoir une information de hauteur, tout en augmenter la quantité de données. Plus récemment, de nouveaux LRF ont fait leur apparition. Leur intérêt réside dans la possibilité d’avoir des informations 3D sur 360˚. Toutefois, la quantité de données à traiter est telle qu’il est difficile d’utiliser ce capteur en temps réel. Son prix est aussi très élevé limitant de fait les applications dans lesquelles il est employé. Enfin, la construction d’une carte nécessite que l’on puisse reconnaître des endroits déjà cartographiés. Avec les données fournies par ces capteurs, des plans et des droites 3D sont généralement utilisées, ce qui rend la tâche compliquée. 2.1.2.4 Radar Le radar est très peu employé dans le domaine de la localisation. Pourtant, celuici n’est que très peu affecté par les conditions météorologiques ou les conditions de luminosité, ce qui est un avantage majeur par rapport à la caméra ou au télémètre laser.2.1. Analyse des capteurs pour la localisation 19 (a) Laser 3D Velodyne (b) Exemple d’image laser 3D Figure 2.5 – Laser 3D Comme le télémètre laser, il s’agit d’un capteur de distance. Son principe est simple : une onde de haute énergie est émise et est réfléchie par les surfaces percutées. Le retour de l’écho va permettre de mesurer la distance à la surface et ainsi de cartographier l’environnement. Dans certains cas, ce capteur peut offrir une vue à 360˚des alentours. En revanche, sa rotation est souvent lente, entraînant ainsi un important phénomène de distorsion dans les images radar [Vivet 2011]. Par ailleurs, le type de surface sur laquelle est réfléchie l’onde influe sur les résultats obtenus et peut ainsi créer des décalages importants avec la réalité. Il s’agit du speckle. Ce dernier peut générer des obstacles inexistants ou, au contraire, en faire disparaître. Ces capteurs demeurent assez coûteux, au même titre que les télémètres laser. Enfin, le même problème de reconnaissance dans la carte évoqué pour les capteurs télémétriques se pose ici aussi. En effet, le speckle et les effets de flou dans la réponse complexifient la tâche de mise en correspondance des informations. 2.1.3 Bilan des capteurs Les capteurs présentés dans cette section sont à mettre en relation avec les contraintes établies par rapport au contexte de l’application. Il faut donc une solution peu onéreuse et qui à la fois fournisse suffisamment d’informations pour que différents véhicules puissent reconnaître un même endroit. Pour ces raisons, nous n’avons pas souhaité nous orienter vers des capteurs de distance qui, bien que commodes, sont à la fois chers et complexes à mettre en oeuvre pour la construction de cartes amenées à être utilisées par plusieurs véhicules. Pour ces mêmes raisons de coût, nous avons décidé de privilégier le duo odomètre et angle volant plutôt qu’une centrale inertielle. L’avantage est que ces capteurs sont maintenant intégrés en standard sur la majorité des véhicules et offrent une première estimation satisfaisante même si elle est de moindre précision qu’avec une centrale inertielle plus coûteuse. Bien entendu, les informations odométriques seules ne sont pas suffisantes. Ainsi,20 Chapitre 2. Localisation d’un véhicule nous avons décidé d’adjoindre une caméra. Ce choix n’est pas anodin. La caméra est devenue un standard dans le milieu automobile grâce à son faible prix et la quantité d’informations fournie. De plus, ce capteur est souvent utilisé quand il s’agit de reconnaître des endroits déjà traversés, ce qui correspond tout à fait à une approche multivéhicule. L’avantage de l’associer à l’odomètre est de pouvoir contraindre le facteur d’échelle. En effet, lorsqu’une caméra est utilisée pour de la localisation, tout est mesuré à un facteur d’échelle près qui ne peut être quantifié que dans certaines conditions. Cela ne serait pas gênant si celui-ci ne dérivait pas au fil du temps [Strasdat et al. 2010b], rendant ainsi la localisation délicate. Les données odométriques vont pouvoir prévenir ce comportement en imposant la position du véhicule dans un repère métrique. L’ajout d’un GPS permettrait de lever bon nombre de contraintes pour l’extension à plusieurs véhicules. La localisation dans un repère absolu serait un avantage majeur puisque cela permettrait de connaître la position approximative de chaque membre de la flotte. Néanmoins, les problèmes de disponibilité évoqués ci-avant font qu’il est risqué de choisir un tel capteur pour résoudre le positionnement relatif des véhicules. Nous avons choisi de développer une solution basée sur le couple odomètre et caméra. Ainsi, nous avons décidé de ne pas intégrer de GPS. Cependant, son utilisation pourrait être bénéfique. Il faudra donc que l’algorithme de localisation permette d’ajouter ce capteur facilement si l’on souhaite étendre notre application. La solution de localisation de chaque véhicule sera donc locale, et non absolue, et basée sur l’utilisation conjointe d’une caméra avec des informations odométriques (déplacement et angle volant). Les différentes contraintes fixées en début de chapitre sont respectées par ce choix. Il faudra toutefois être vigilant aux faiblesses de ce duo. En effet, l’odométrie a tendance à accumuler les erreurs et une unique caméra ne permet pas une estimation immédiate de la distance. Ces points devront être pris en considération lors de la construction d’un algorithme de localisation. Ces inconvénients seront d’ailleurs largement évoqués dans le chapitre 3. 2.2 Méthodes de localisation pour le SLAM Le choix de la méthode de localisation est primordial. C’est d’ailleurs une dé- cision à prendre en adéquation avec les capteurs sélectionnés, à savoir dans notre cas une caméra, un odomètre et un capteur d’angle de braquage. Durant cette première partie du manuscrit, il a souvent été question de suivre des objets grâce aux capteurs afin de pouvoir estimer les déplacements d’un véhicule. Ces objets forment ce que l’on a défini comme étant une carte. Les applications visées par ces travaux de thèse ne prennent pas comme pré-requis l’existence d’une quelconque carte. Il est donc nécessaire que chaque véhicule construise la sienne au fur et à mesure, tout en se localisant dans celle-ci. Ce procédé est connu sous le nom de Simultaneous Localization And Mapping (SLAM), ou localisation et cartographie simultanées. Initié dès le début des années 90 [Smith et al. 1990][Leonard & Durrant-Whyte 1991],2.2. Méthodes de localisation pour le SLAM 21 voire même quelques années auparavant [Smith & Cheeseman 1986], le SLAM est un cadre regroupant toutes les méthodes de localisation basées sur des cartes construites de manière incrémentale. Les lecteurs intéressés pourront d’ailleurs se tourner vers [Durrant-Whyte & Bailey 2006] et [Bailey & Durrant-Whyte 2006] pour une introduction au domaine. Bien évidemment, toutes les approches de localisation ne se basent pas sur du SLAM. Néanmoins, ces méthodes reposent essentiellement sur des capteurs fournissant une localisation absolue (souvent des GPS RTK), ce qui n’est pas notre cas. Quelques approches de localisation par caméra arrivent à s’extraire du cadre du SLAM. On peut par exemple citer [Lovregrove et al. 2011] qui travaille à partir des gradients de l’image ou [Aires et al. 2008] qui présente une odométrie via flot optique basée sur les couleurs. Ces méthodes sont en nombre restreint et peu adaptées au contexte multivéhicule. En effet, des informations sur l’environnement doivent être transmises entre les robots afin que ceux-ci puissent savoir où ils se situent les uns par rapport aux autres. Ainsi, toutes les techniques de localisation présentées ci-après s’inscrivent dans la thématique du SLAM en environnement statique appliqué à la vision. Des techniques spécifiques (SLAMMOT) existent néanmoins pour les environnements dynamiques mais ne seront pas abordées ici. La littérature étant très vaste à ce sujet, cette section sera découpée en deux parties. Nous commencerons par une rapide analyse des méthodes de minimisation globale (sous-section 2.2.1) avant de détailler les différents filtres qui existent (sous-section 2.2.2). Ces deux courants s’opposent dans le principe : la minimisation globale est proche d’un estimateur de maximum de vraisemblance alors que les filtres s’orientent davantage vers la minimisation des erreurs quadratiques. Les techniques de localisation nécessitant la position exacte des amers observés pour fonctionner (triangulation, géométrie épipolaire) ne seront pas abordées ici puisque généralement difficiles à mettre en oeuvre sur des applications réelles. De plus, l’utilisation d’une unique caméra nécessite d’avoir une solution de localisation robuste aux approximations, éliminant de ce fait ces méthodes. 2.2.1 Minimisation globale par ajustement de faisceaux L’ajustement de faisceaux est une méthode très répandue dans la communauté SLAM. Elle permet d’estimer la pose d’un véhicule compte tenu d’observations faites par les capteurs. La majorité du temps, cette approche repose sur l’utilisation de caméras puisqu’il est nécessaire d’avoir une quantité importante de points à suivre afin d’assurer la bonne estimation de la pose du véhicule. L’idée est simple : des points caractéristiques sont extraits dans l’image et forment la carte. Ils sont ensuite re-projetés dans les images suivantes et des correspondances sont cherchées. Une fois les associations entre les points de la carte et l’image courante trouvées, le but est d’estimer le déplacement ayant affecté le véhicule entre ces images afin de pouvoir minimiser les erreurs de projection des amers (points de la carte) par rapport aux associations trouvées. Les lecteurs intéressés pourront se référer à [Triggs et al. 2000] pour une revue détaillée des méthodes basées sur l’ajustement de faisceaux.22 Chapitre 2. Localisation d’un véhicule L’étape de minimisation globale est effectuée via un algorithme robuste, souvent de type Levenberg-Marquardt [Press et al. 1992]. L’inconvénient majeur des techniques d’ajustement de faisceaux est la lourdeur de cette minimisation. Une organisation hiérarchique des traitements a été proposée par [Hartley & Zisserman 2000] et ensuite appliquée à de la navigation autonome par [Royer et al. 2005] avec d’excellents résultats de localisation (voir figure 2.6). (a) Reconstruction 3D (les points bleus sont ceux cartographiés par l’algorithme) (b) Résultats de localisation (le trait épais est la vérité terrain et le trait fin ce qui est estimé par l’algorithme) Figure 2.6 – Résultats de l’ajustement de faisceaux de [Royer et al. 2005] (approximativement 15 cm d’erreur)2.2. Méthodes de localisation pour le SLAM 23 Malheureusement, la construction de la carte et la localisation dans celle-ci doivent être séparées car trop coûteuses en temps. Nistér et al. [Nistér et al. 2006] se sont tournés vers une estimation de pose différente, faite sur des triplets d’images à chaque fois. L’algorithme repose sur la sélection de la meilleure solution de localisation via RANSAC [Fischler & Bolles 1981]. Néanmoins, bien que temps réel (autour de 13 Hz), l’approche fournie des résultats de localisation moins précis que [Royer et al. 2005], les erreurs s’accumulant au fil de la trajectoire. Enfin, Mouragon et al. ont proposé un algorithme d’ajustement de faisceaux local [Mouragnon et al. 2006] permettant une localisation temps réel autour de 7,5 Hz avec de très bons résultats. Ces méthodes de minimisation globale sont donc tout à fait adaptées à la localisation temps réel. Néanmoins, 8000 points 3D ainsi que 240 images clefs doivent être conservés pour l’étape de localisation et ce pour une trajectoire d’environ 200 mètres. Cela constitue une importante masse de données. De plus, au moins 400 points doivent être associés par image pour que l’étape de minimisation se déroule bien. Cela signifie que l’environnement doit être suffisamment texturé pour pouvoir extraire assez de points caractéristiques et les reconnaître. En- fin, les incertitudes associées aux amers ainsi qu’à la pose du véhicule ne sont pas directement disponibles et doivent être calculées. 2.2.2 Filtrage Les techniques de filtrage sont souvent opposées à celles d’ajustement de faisceaux. Les filtres ont longtemps été considérés comme meilleurs puisque plus facilement utilisables dans des applications temps réel. La sous-section précédente a montré que ce n’est maintenant plus vrai, des améliorations ayant permis d’accélérer les temps de calcul des approches par minimisation globale. Une grande partie de la communauté SLAM a d’ailleurs migré vers celles-ci. Néanmoins, les filtres sont toujours employés, certains cas étant encore propices à leur utilisation. La suite de cette sous-section va détailler les plus populaires dans le cadre du SLAM. 2.2.2.1 Filtre de Kalman Le filtre de Kalman est l’estimateur le plus populaire encore à ce jour [Kalman 1960]. Celui-ci permet, à partir de mesures bruitées, d’estimer l’état d’un système comme par exemple la pose d’un véhicule ou la position d’amers (points de la carte). Le filtre de Kalman fournit, conjointement à l’estimation de l’état, l’incertitude de celui-ci sous la forme d’une matrice de variance-covariance. Il s’agit d’un estimateur récursif markovien d’ordre 1. Ainsi, uniquement l’état précédent du filtre et les nouvelles mesures sont nécessaires pour produire une nouvelle estimation de celui-ci. Le filtre de Kalman suppose néanmoins que toutes les mesures soient décorrélées et suivent une distribution gaussienne ce qui n’est pas forcément toujours le cas. Sa notoriété est également liée au fait qu’il est optimal dans le cas de fonctions linéaires et qu’il est très peu coûteux. Son fonctionnement se découpe en 2 étapes : la prédiction et la mise à jour.24 Chapitre 2. Localisation d’un véhicule La phase de prédiction se charge de faire évoluer l’état depuis l’instant précédent jusqu’à l’instant courant. Les observations fournies par les capteurs viennent ensuite corriger l’état prédit : il s’agit de l’étape de mise à jour. À chaque fois, les incertitudes associées aux mesures, ainsi que celles affectant les différentes variables du vecteur d’état, sont prises en compte dans les calculs. Dans le cadre de la robotique mobile, la phase de prédiction consiste généralement à faire évoluer le véhicule suivant un modèle physique de celui-ci en fonction des données odométriques acquises. Pour l’étape de mise à jour, il s’agit d’observer les amers précédemment cartographiés. La différence entre ce qui est attendu et ce qui est observé va ainsi pouvoir corriger l’état prédit. Ces 2 étapes sont généralement formalisées comme suit. L’estimation de l’état du système représentée par 2 variables : xk|k qui est l’estimation de l’état à l’instant k considérant toutes les observations jusqu’à l’instant k, et Pk|k qui est la matrice de covariance (incertitude) associée à l’état xk|k . Soit Fk la forme matricielle du modèle linéaire d’évolution de l’état et uk les commandes effectuées par le robot entre k − 1 et k, l’étape de prédiction est alors : xk|k−1 = Fkxk−1|k−1 + Bkuk (2.1) où Bk est le modèle liant les commandes reçues à l’état (cela est surtout valable dans un contexte de robotique mobile). La prédiction de la matrice de covariance se fait comme suit : Pk|k−1 = FkPk−1|k−1F T k + Qk (2.2) où Qk est le bruit du processus d’évolution. Enfin, pour la mise à jour, soit zk la variable regroupant les observations faites à l’instant k et Hk la forme matricielle du modèle d’observation liant zk à l’état. On peut ainsi calculer l’innovation associée à la mise à jour de Kalman : Δk = zk − Hkxk|k−1 (2.3) Le gain de Kalman est ensuite donné par : Kk = Pk|k−1HT k (HkPk|k−1HT k + Rk) −1 (2.4) où Rk est l’incertitude associée aux observations zk. Une fois le gain de Kalman obtenu, la mise à jour peut être calculée et l’état (tout comme l’incertitude) corrigé : xk|k = xk|k−1 + KkΔk (2.5) Pk|k = Pk|k−1 − KkHkPk|k−1 (2.6) L’application du filtre de Kalman au SLAM propose d’excellentes propriétés en terme de convergence des données [Dissanayake et al. 2000][Dissanayake et al. 2001]. Malheureusement, sous cette2.2. Méthodes de localisation pour le SLAM 25 forme, ce filtre est rarement employé puisqu’il requiert des modèles linéaires ce qui est rarement le cas dans des applications de robotique mobile. Ainsi, une formulation adaptée aux systèmes non linéaires a été élaborée. 2.2.2.2 Filtre de Kalman étendu Présenté dans [Kalman & Bucy 1961], le filtre de Kalman étendu ou EKF (Extended Kalman Filter) a pour but d’estimer l’état de systèmes régis par des modèles non linéaires. Son fonctionnement est très similaire au filtre de Kalman classique si ce n’est qu’une étape de linéarisation est nécessaire. Celle-ci est faite autour du point de fonctionnement, à savoir l’estimée courante. Pour la prédiction, la linéarisation du modèle d’évolution sera faite autour de xk−1|k−1 . Pour l’étape de mise à jour, la linéarisation sera accomplie autour de xk|k−1 . Dans les 2 cas, ces phases de linéarisation correspondent au développement de Taylor d’ordre 1, à savoir le calcul des matrices jacobiennes (matrices aux dérivées partielles) associées aux modèles. Plus de détails concernant l’EKF dans le cadre du SLAM seront donnés en section 2.3. L’optimalité de l’EKF a été démontrée dès lors que la linéarisation se fait autour de la vraie valeur du vecteur d’état. Dans les faits, il s’agit de ce que l’on veut estimer et cette valeur n’est pas disponible. Plus l’estimée sera correcte, plus l’étape de linéarisation sera juste. En revanche, l’éloignement de la vraie valeur peut causer des problèmes d’inconsistance : la vérité ne serait alors plus comprise dans l’incertitude associée à l’estimation. Dans le cadre d’un SLAM, la divergence du vecteur d’état peut être conséquente [Julier & Uhlmann 2001b][Bar-Shalom et al. 2001]. Néanmoins, beaucoup d’approches se basent tout de même sur l’EKF. En effet, les estimées sont souvent suffisamment proches de la vérité pour éviter ces problèmes. On peut par exemple citer l’approche de Leonard et al. dans [Leonard & Feder 2000] qui utilise avec succès un EKF SLAM dans de grands environnements. L’utilisation d’un EKF pour le SLAM est souvent associée à l’emploi de capteurs de profondeur. Par exemple, dans [Guivant et al. 2000], un télémètre laser est utilisé. Cette approche a ensuite été étendue dans [Guivant & Nebot 2001] pour couvrir de grandes distances. Toujours avec des capteurs de distance, nous pouvons citer l’approche de [Newman & Leonard 2003] où un sonar permet une application sousmarine de l’EKF SLAM. Ces résultats suivent des travaux précédemment entrepris sur l’exploration, toujours par filtre de Kalman étendu [Newman et al. 2002]. Enfin, d’autres approches, couplant laser et vision avec un EKF, ont été expérimentées [Newman et al. 2006]. Bien que moins populaires, les processus utilisant une unique caméra pour l’EKF SLAM ont tout de même été largement étudiés [Davison 2003][Clemente et al. 2007]. Concernant les performances de l’EKF, celles-ci sont liées au nombre d’amers qui sont dans le vecteur d’état. Dans le cas de figure où la taille de la carte ne fait que croître (pas de suppression des anciens amers), cette charge ne fait qu’augmenter. En effet, la taille du vecteur d’état et de la matrice de covariance associée ont un gros impact sur le temps de calcul de la mise à jour. Il a été montré dans [Malartre 2011]26 Chapitre 2. Localisation d’un véhicule que traiter les observations une par une (c’est-à-dire que chaque observation entraîne une mise à jour) concède un gain de temps considérable. À l’inverse, prendre en compte toutes les observations d’un coup rend la mise à jour du filtre plus longue mais moins sensible aux fausses associations. Dans le premier cas (mise à jour itérative), si une observation est mauvaise, elle pourrait faire complètement diverger le filtre, empêchant ainsi le processus d’estimation de se dérouler correctement. Dans le second cas, celle-ci serait lissée et pondérée par le reste des observations qui tireront la mise à jour de l’état dans une autre direction. Ces quelques remarques sont valables pour l’ensemble des techniques de filtrage présenté ici. Afin de conserver une mise à jour à temps presque constant, il est toujours possible de supprimer des amers dès lors qu’ils ne sont plus visibles. Le SLAM s’apparente dès lors davantage à de l’odométrie visuelle. En fonction des applications (pas de boucle dans la trajectoire par exemple), cela peut s’avérer intéressant. De plus, il est toujours possible d’extraire les amers qui ne sont plus visibles pour les stocker en dehors du vecteur d’état et ainsi alléger la charge calculatoire. Dans tous les cas, il a été constaté que les filtres de Kalman ne requièrent que peu d’amers pour atteindre une bonne précision [Strasdat et al. 2010a]. Bien sûr, cela est à nuancer en fonction de la qualité des capteurs et donc des amers. À titre d’exemple, nous pouvons citer [Féraud 2011] qui présente des résultats de localisation par EKF en se basant sur une carte de référence préalablement construite. Il s’agit du même contexte que dans [Royer et al. 2005]. Les résultats sont exposés sur la figure 2.7. On peut constater que la précision atteinte est similaire à celle obtenue par Royer et al. dans [Royer et al. 2005]. Néanmoins, ici pour une trajectoire d’environ 170 mètres, uniquement 319 amers ont été cartographiés. Il est également possible de réduire le temps des mises à jour sans avoir à supprimer d’amers. Il faut pour cela utiliser les méthodes de sous-cartes (submapping). Le principe est assez simple : à chaque fois qu’une carte devient trop lourde à compléter (d’autres critères sont également possibles), celle-ci est fermée et une nouvelle entièrement vide est ouverte. Une carte de plus haut niveau garde les liens entre les sous-cartes afin de ne pas perdre d’information. En plus d’alléger les temps de traitement, cela permet aussi de diminuer les erreurs de linéarisation de l’EKF. En effet, dans une nouvelle sous-carte, toutes les informations précédentes sont oubliées ce qui permet d’avoir une incertitude nulle au départ de celle-ci. En revanche, les erreurs de linéarisation perdurent dans la carte haut niveau. Parmi les premières approches basées sous-cartes apparues, nous pouvons citer [Williams et al. 2002a] et le Constrained Relative Submap Filter où les sous-cartes sont décorrélées les unes des autres. Néanmoins, la structure de plus haut niveau en arbre rend l’intégration de fermetures de boucle (second passage à un endroit déjà exploré) difficile. Les approches de Leonard et al. dans [Leonard & Newman 2003] pour le SLAM à temps constant et de Bailey dans [Bailey 2002] avec les Network Coupled Features Maps sont assez similaires. Les amers communs entre les souscartes sont utilisés afin de garder les informations disponibles quand il y a une transition dans les sous-cartes. Malheureusement, ces approches ne prennent pas en compte le fait que les données soient corrélées créant ainsi des problèmes d’in-2.2. Méthodes de localisation pour le SLAM 27 (a) Reconstruction et trajectoire (les croix rouges sont les amers cartographiés par l’algorithme) (b) Résultats de localisation (le trait bleu est la vérité terrain et le trait rouge ce qui est estimé par l’algorithme) Figure 2.7 – Résultats de l’EKF de [Féraud 2011] (moins de 8 cm d’erreur) consistance. Dans l’approche Atlas décrite dans [Bosse et al. 2003], un graphe est utilisé comme carte de haut niveau. Les noeuds représentent la position globale des sous-cartes et les arêtes, les transformations de l’une vers l’autre. La cohérence de l’ensemble est malheureusement sacrifiée puisque les mises à jour globales ne sont faites qu’avec un processus hors-ligne. Estrada et al. proposent une approche similaire [Estrada et al. 2005] où deux cartes globales sont maintenues : une intégrant les informations corrigeant l’emplacement des sous-cartes et l’autre non. Les corrections ne sont néanmoins pas appliquées aux sous-cartes rendant ainsi impossible de28 Chapitre 2. Localisation d’un véhicule se servir de ces informations dans la navigation locale. La représentation est également sous-optimale puisqu’un même amer peut être dans plusieurs sous-cartes. Une utilisation de sous-cartes conditionnellement indépendantes est proposée dans [Piniés & Tardós 2008]. Celle-ci permet de conserver les informations d’une souscarte à l’autre et ainsi d’éviter de démarrer en perdant l’a priori disponible. Cela force cependant à faire attention aux données à marginaliser pour éviter de devenir inconsistant. L’approche décrite dans [Paz et al. 2008] propose de reconstituer la carte globale sans approximation. Pour ce faire, l’algorithme joint les sous-cartes deux à deux jusqu’à ce qu’il n’y ait plus qu’une carte globale. Le coût de la jointure est ainsi en partie lissé même si les dernières fusions restent coûteuses. Enfin, quelques séparations légèrement différentes ont été proposées. Dans [Blanco et al. 2009], les sous-cartes sont créées en fonction des amers qui sont observables simultanément. Le problème majeur est qu’uniquement les capteurs fournissant immédiatement la distance des amers sont utilisables. Enfin, un critère similaire pour trier les souscartes a été présenté dans [Chli & Davison 2009]. Celui-ci groupe ensemble les amers ayant de fortes corrélations. Cela n’empêche pas néanmoins les sous-cartes de ne pas intégrer toutes les corrections disponibles dans la carte haut niveau. L’utilisation des sous-cartes pose d’autres problèmes que ceux évoqués ci-dessus. En effet, chaque sous-carte est construite avec un facteur d’échelle différent puisque les informations menant d’une sous-carte à une autre ne sont pas utilisées lors de leur construction. Les traitements hors-ligne, souvent obligatoires pour obtenir une carte optimale, sont aussi un point qui nuit à l’emploi de ces méthodes. Cependant, cela reste un bon moyen pour qu’un EKF SLAM cartographie de très longues distances. Hormis le temps de calcul, il est toujours intéressant de regarder l’empreinte mémoire laissée par un algorithme. Dans le cas de l’EKF (et de ses dérivées), elle est faible car peu d’amers sont nécessaires pour couvrir de grandes distances. Néanmoins, pour atteindre une bonne précision de localisation, il faut veiller à avoir une bonne répartition des amers dans la carte (des points proches et éloignés) [Paz et al. 2008]. Dans les résultats présentés en figure 2.7, 319 points ont été utilisés pour une trajectoire de 170 mètres. Uniquement 20 points devaient être observables par image. Ces chiffres traduisent bien, dans ce cas précis, une faible occupation mémoire pour le filtre de Kalman étendu. 2.2.2.3 Filtre de Kalman sans parfum Le filtre de Kalman sans parfum, ou Unscented Kalman Filter (UKF), a été introduit dès 1997 [Julier & Uhlmann 1997]. Son objectif est de compenser les faibles performances de l’EKF dans le cadre de systèmes hautement non linéaires. L’idée principale est d’éviter le calcul des jacobiennes qui tend à rendre les estimées inconsistantes. Pour cela, une méthode d’échantillonnage est introduite. Celle-ci sélectionne un nombre minimum de particules (appelées points sigma) qui sont ensuite pondérées autour de l’espérance via une fonction de vraisemblance. Ces points sigma passent ensuite par les fonctions non linéaires. Il est alors possible de ré-estimer l’état du système ainsi que sa covariance. Les différentes particules sont ré-échantillonnées2.2. Méthodes de localisation pour le SLAM 29 au fur et à mesure afin d’affiner les résultats. Les UKF sont plus précis que les EKF puisque l’étape de linéarisation est évitée. Néanmoins, un important temps de calcul est requis par cette méthode, la rendant ainsi difficilement transposable à des applications réelles. L’UKF est donc logiquement très peu utilisé pour le SLAM. Les principaux travaux remontant au début des années 2000 [Wan & Merwe 2000][Julier & Uhlmann 2004]. Une application temps réel de l’UKF à un contexte monoculaire a tout de même été démontrée dans [Checklov et al. 2006]. 2.2.2.4 Filtre d’information Le filtre d’information [Maybeck 1982] est également souvent appelé la forme inverse du filtre de Kalman. En effet, sa particularité est de définir la matrice d’information comme étant l’inverse de la matrice de covariance : Yk|k = P −1 k|k (2.7) Cela se traduit comme suit pour la définition du vecteur d’information : yk|k = P −1 k|k xk|k (2.8) L’avantage de cette représentation est visible lors de l’étape de mise à jour. Cette dernière devient en effet additive et à l’intérêt de ne pas être dépendante de l’ordre dans lequel les observations sont intégrées [Liu & Thrun 2003]. Les mesures ainsi que les covariances associées sont exprimées sous forme linéaire de la façon suivante : ik = HT k R−1 k zk (2.9) Ik = HT k R−1 k Hk (2.10) La mise à jour s’écrit alors comme ceci : yk|k = yk|k−1 + ik (2.11) Yk|k = Yk|k−1 + Ik (2.12) Il est également possible de rendre la matrice d’information plus éparse en cassant les liens faibles entre les données [Thrun et al. 2004]. L’avantage majeur est que la mise à jour s’effectue alors quasiment en temps constant [Eustice et al. 2005]. Cependant, uniquement quelques approches utilisent ce filtre dans le cadre du SLAM monovéhicule [Mahon et al. 2008][Walter et al. 2007][Gutmann et al. 2010]. Cela est principalement dû au fait qu’il est nécessaire de convertir chaque mesure, tout comme l’état, sous cette forme inverse. Cette étape peut être coûteuse car elle fait intervenir une inversion de matrice de complexité cubique.30 Chapitre 2. Localisation d’un véhicule 2.2.2.5 Filtre particulaire Les filtres particulaires ou Particle Filters (PF) sont souvent utilisés quand l’état du système que l’on cherche à estimer ne suit pas une distribution gaussienne ou quand le caractère gaussien est cassé par la non linéarité des fonctions. Son principe est simple : l’état est échantillonné en un ensemble de particules suivant sa densité de probabilité. Ensuite, à l’instar du filtre de Kalman, une étape de prédiction est accomplie. Celle-ci applique à chaque particule le modèle d’évolution. De même, une phase de mise à jour suit. Dans celle-ci les particules sont pondérées suivant leur vraisemblance par rapport aux mesures. Les particules les plus probables sont conservées. Les autres sont éliminées et de nouvelles particules sont générées [Dellaert et al. 1999]. Cependant, l’application directe de cette méthode au SLAM est délicate. Cela nécessiterait d’avoir un ensemble de particules par amer de la carte, ce qui est, d’un point de vue calculatoire, extrêmement coûteux. Généralement, des hybrides EKF et PF sont utilisés pour le SLAM. L’algorithme le plus connu est le FastSLAM [Montemerlo et al. 2002] qui a lui-même été influencé par [Murphy 1999] et [Thrun et al. 2000]. Dans celui-ci, la carte est estimée via un EKF pendant que la localisation suit une approche particulaire. La qualité des résultats dépend fortement du nombre de particules utilisées. Ce choix est difficile à quantifier et une augmentation trop conséquente du nombre de particules pose le problème de la complexité calculatoire. Néanmoins, l’algorithme de FastSLAM a pu être appliqué en temps réel à un contexte monoculaire sur de petites distances (intérieur d’un bureau) dans [Eade & Drummond 2006]. Malgré le fait qu’il puisse représenter des distributions non gaussiennes, le FastSLAM souffre aussi d’inconsistance à long terme [Bailey et al. 2006b]. Pour éviter ce problème, cet algorithme a été combiné à un filtre d’information dans [Mohan & Madhava 2010]. Le problème majeur porte alors sur les complexités des deux méthodes qui se cumulent. 2.2.3 Bilan des méthodes de localisation L’aperçu donné sur les méthodes de localisation dans le cadre d’un SLAM local permet de dresser un bilan et de faire un choix en ayant connaissance des forces et faiblesses de chacune. Les plus intéressantes, du point de vue du temps de calcul, semblent être l’ajustement de faisceaux et le filtre de Kalman étendu. Cet aspect est très important puisqu’une utilisation multivéhicule va forcément entraîner un surcoût calculatoire. Un comparatif entre ces 2 approches a été dressé dans [Strasdat et al. 2010a] puis étendu dans [Strasdat et al. 2012] dans le cadre de l’utilisation de caméras. Il en ressort que les ajustements de faisceaux semblent plus précis que les EKF. Il est tout de même précisé qu’avec peu de ressources, il est plus intéressant de s’orienter vers un EKF puisqu’une minimisation globale est vite lourde. Un des problèmes de l’EKF reste l’augmentation constante du vecteur d’état mais des méthodes (citées2.3. SLAM pour l’EKF dans un contexte de robotique mobile 31 en 2.2.2.2) peuvent éviter cela. Un point important est le fait que l’EKF soit plus à même de traiter les données hautement incertaines ce qui est souvent le cas en utilisant une seule caméra (la profondeur des points étant plus qu’approximative lors des premières observations). La revue de l’état de l’art faite dans cette section semble confirmer la tendance évoquée dans ces articles. La quantité d’informations utilisée dans l’ajustement de faisceaux indique que ces approches sont difficiles à adapter à un contexte multivé- hicule. De son côté, l’EKF ne requiert que peu de points ce qui le désigne davantage pour des applications impliquant plusieurs véhicules. Pour privilégier l’économie des ressources (processeur et mémoire), nous nous sommes naturellement tournés vers l’utilisation d’un filtre de Kalman étendu. L’emploi de sa version itérative nous permet en plus d’accomplir les mises à jour plus rapidement même s’il faudra être prudent sur la phase d’association des données. Au delà du temps de calcul et de la consommation mémoire, l’EKF fournit un accès immédiat à la covariance, ce qui est justement important pour l’association de données. Enfin, il offre la possibilité de fusionner d’autres capteurs très facilement. Cela permet de garder notre solution évolutive si d’aventure il s’avérait que l’on souhaitait ajouter un GPS par exemple. La méthode de localisation ainsi que les capteurs étant décidés, la section suivante va maintenant présenter l’utilisation que nous allons faire de l’ensemble en décrivant les différents modèles utilisés. 2.3 SLAM pour l’EKF dans un contexte de robotique mobile Avant de débuter la description des modèles utilisés, nous allons en premier lieu présenter le SLAM dans le cadre de l’utilisation d’un EKF. Pour ce faire, nous allons nous appuyer sur l’exemple présenté en figure 2.8. Considérons l’initialisation d’un processus SLAM. Il convient tout d’abord de définir la position du véhicule en fonction d’un repère qui sera ensuite utilisé pour la navigation. Habituellement, et en l’absence d’informations absolues, le véhicule est très souvent initialisé à la position (0, 0) d’un repère situé sur le point de dé- part de la trajectoire (figure 2.8(a)). En suivant son modèle d’évolution, qui peut être basé ou non sur des informations odométriques, la position du véhicule après déplacement est estimée. Le modèle ainsi que les données issues des capteurs étant imprécises, une incertitude sera affectée à la position via sa matrice de covariance. C’est l’étape de prédiction. Lors de celle-ci, l’incertitude associée à la position du véhicule augmente obligatoirement. La matrice de covariance se traduit graphiquement par une ellipse (quadrique en 3D) dans laquelle la vraie position du véhicule est située (figure 2.8(b)). Puisque le véhicule vient seulement de commencer à bouger, il ne dispose pas encore d’une carte par rapport à laquelle il peut se localiser : il doit alors la construire. Pour cela, des points caractéristiques de l’environnement sont sélectionnés grâce à32 Chapitre 2. Localisation d’un véhicule (a) Initialisation du véhicule (en gris) (b) Déplacement du véhicule (incertitude en rouge) (c) Création d’un amer et de son incertitude (losange gris) (d) Nouveau déplacement du véhicule (e) Observation avec son incertitude (verte) du point de la carte (f) Mise à jour via l’observation et amélioration des positions et incertitudes (bleues) Figure 2.8 – Présentation d’un SLAM dans le contexte de l’EKF la caméra (ou tout autre capteur extéroceptif). Ils servent de base pour initialiser des amers complets qui seront ensuite intégrés dans la carte. Chaque amer construit prend en compte l’incertitude associée au véhicule au moment de l’initialisation ainsi que l’incertitude quant à la mesure faite par la caméra. Cela permet d’obtenir un point statique de l’environnement avec sa propre incertitude (figure 2.8(c)). Une2.3. SLAM pour l’EKF dans un contexte de robotique mobile 33 fois la cartographie faite, le véhicule continue de se déplacer. L’intégration de son déplacement fait gonfler son incertitude. En revanche, l’amer n’est pas affecté car il est statique et ne dépend donc pas de la position du véhicule (figure 2.8(d)). Maintenant qu’une carte est constituée (avec un seul amer), celle-ci va être utilisée afin d’améliorer la position du véhicule. Il y a deux façons de faire : la première consiste à utiliser le même détecteur de points caractéristiques que précédemment et d’essayer de trouver des correspondances avec la carte. Il est aussi possible de projeter les points de la carte dans l’espace capteur et de trouver une association à proximité. C’est généralement cette seconde méthode qui est employée. Ici, afin de faciliter la compréhension via les schémas, la première est illustrée. Un nouvel amer est construit avec sa propre incertitude (voir figure 2.8(e)). Grâce à un processus d’association de données, l’algorithme est capable de déterminer que ce nouvel amer correspond bien à celui déjà présent dans sa carte. Ce nouvel amer est alors considéré comme une observation de celui de la carte. Le modèle utilisé pour observer les points de la carte permet ensuite de calculer la mise à jour adéquate. L’utilisation du filtre de Kalman fait que non seulement l’amer sera précisé mais également la position du véhicule (figure 2.8(f)). Ce processus se répète ainsi jusqu’à la fin de la trajectoire. La suite de cette section va détailler chaque étape en donnant les équations des différents modèles. La première sous-section traitera de la prédiction. Puis, la sous-section 2.3.2 exposera l’étape de mise à jour ainsi que le modèle d’observation utilisé. Enfin, la sous-section 2.3.3 détaillera les différents points sur lesquels l’aspect monoculaire de l’algorithme a une forte influence. 2.3.1 Prédiction Soit vk la pose du véhicule à l’instant k. Le contexte de vision nous permet de la définir suivant 6 degrés de liberté, à savoir la position 3D et les 3 angles associés : vk = ⎛ ⎜⎜⎜⎜⎜⎜⎜⎝ xk yk zk Ψk Φk Θk ⎞ ⎟⎟⎟⎟⎟⎟⎟⎠ (2.13) où  xk yk zk est la position 3D du véhicule et  Ψk Φk Θk sont respectivement les angles de roulis, tangage et lacet. Ces paramètres nous permettent de passer du repère monde ℜm au repère vé- hicule ℜv et inversement. En l’absence de référence absolue, le (0, 0, 0) du repère monde sera fixé sur le début de la trajectoire. La figure 2.9 montre l’orientation de ces 2 repères. Dans cette figure, tvm est la translation, issue de la position du véhicule  xk yk zk , permettant de passer du repère monde au repère véhicule (ou inversement). De manière similaire, Rvm est la rotation, calculée à partir des34 Chapitre 2. Localisation d’un véhicule angles Ψk, Φk et Θk, qui complète le passage de ℜm à ℜv (ou encore une fois dans l’autre sens). Figure 2.9 – Représentation des repères monde et véhicule et passage de l’un à l’autre Dans le cadre du filtre de Kalman étendu, la prédiction de l’état du véhicule vk 1|k 1 de covariance Pvk 1|k 1 s’exprime comme suit : vk|k 1 = f(vk 1|k 1 , uk) (2.14) Pvk|k 1 = Fvk 1|k 1Pvk 1|k 1F T vk 1|k 1 + FukQkF T uk (2.15) où f est une fonction non linéaire, Fvk 1|k 1 est la jacobienne de f suivant vk 1|k 1 et Fuk la jacobienne de f suivant le vecteur de commande uk affecté du bruit Qk . Compte tenu du fait que le capteur odométrique nous fournit une distance de déplacement ds entre les instants k 1 et k et l’angle volant δ entre les mêmes instants, nous pouvons définir le vecteur de commande uk comme indiqué ci-après : uk = ds δ (2.16) La fonction non linéaire f se traduit par un modèle d’évolution prenant en compte l’état du véhicule vk 1|k 1 et les données odométriques uk.2.3. SLAM pour l’EKF dans un contexte de robotique mobile 35 Il s’agit d’un modèle bicyclette simplifié qui s’exprime de la manière suivante : ⎧ ⎪⎪⎪⎪⎪⎪⎪⎪⎨ ⎪⎪⎪⎪⎪⎪⎪⎪⎩ xk|k−1 = xk−1|k−1 + ds cos(Θk−1|k−1 + δ) yk|k−1 = yk−1|k−1 + ds sin(Θk−1|k−1 + δ) zk|k−1 = zk−1|k−1 + ds sin(Φk−1|k−1 ) Ψk|k−1 = Ψk−1|k−1 Φk|k−1 = Φk−1|k−1 Θk|k−1 = Θk−1|k−1 + ds sin(δ) L (2.17) où L est l’entre-axe du véhicule. La jacobienne Fvk−1|k−1 peut ensuite être calculée : Fvk−1|k−1 = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 1000 0 −ds sin(Θk−1|k−1 + δ) 0100 0 ds cos(Θk−1|k−1 + δ) 0010 ds cos(Φk−1|k−1 ) 0 0001 0 0 0000 1 0 0000 0 1 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ (2.18) Il en va de même pour Fuk : Fuk = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ cos(Θk−1|k−1 + δ) −ds sin(Θk−1|k−1 + δ) sin(Θk−1|k−1 + δ) ds cos(Θk−1|k−1 + δ) sin(Φk−1|k−1 ) 0 0 0 0 0 sin(δ) L ds cos(δ) L ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ (2.19) La matrice Qk est généralement définie expérimentalement en fonction de la qualité des données odométriques. Cette phase de prédiction n’est pas obligatoirement suivie par une étape de mise à jour. En effet, les capteurs fonctionnent à des fréquences différentes et il est courant que l’odomètre soit plus rapide que la caméra. Bien évidemment, rien n’empêche de faire plusieurs prédictions avant de faire une mise à jour. Seulement, il n’y a aucune garantie de l’ordre d’arrivée des mesures. Ainsi, dès qu’une image arrive, l’état du véhicule est extrapolé jusqu’à la date de l’image avec un modèle qui n’est pas basé sur l’odométrie (modèle à vitesse constante, etc.). Les états issus de l’odométrie et de la caméra sont ensuite fusionnés dès qu’une nouvelle donnée proprioceptive est disponible. Ce comportement est exposé dans la figure 2.10 au travers d’un exemple. Les lecteurs intéressés pourront se tourner vers [Tessier et al. 2006] pour plus de détails sur la gestion des données désynchronisées.36 Chapitre 2. Localisation d’un véhicule Figure 2.10 – Gestion des deux états en fonction des données fournies par les capteurs Sur la figure 2.10, on peut voir qu’une donnée odométrique est reçue à la date t1. Celle-ci permet, à l’aide du modèle du robot d’obtenir l’état t1. Une image arrive à une date t2 ultérieure à t1. Il est donc nécessaire d’extrapoler l’état t1 jusqu’à la date t2 afin de pouvoir prendre en compte cette information. Pour ce faire, un modèle à vitesse constante est utilisé, ce qui génère l’état t2. La réception d’une nouvelle donnée odométrique à t3 va créer l’état prédit t3 parallèlement à t2. Ceux-ci sont ensuite fusionnés pour obtenir l’état t3 qui intègre toutes les informations reçues jusqu’à la date t3. 2.3.2 Mise à jour La gestion des mises à jour est un peu plus compliquée puisqu’elle fait intervenir la carte. Les observations se faisant dans le repère image, il convient de bien définir les différents changements de repère qui peuvent intervenir. En plus des repères monde et véhicule préalablement définis, le repère caméra ℜc ainsi que le plan image ℜi doivent être pris en considération pour pouvoir passer d’amers 3D dans le monde à un point 2D dans le plan image. Le passage de ℜv à ℜc est similaire à celui défini pour aller de ℜm à ℜv. Une translation tcv ainsi qu’une rotation Rcv sont nécessaires à sa réalisation. Les 6 paramètres de ce changement de repère sont donnés par les paramètres extrinsèques de la caméra qui correspondent à la mesure de la position de la caméra par rapport au repère véhicule. Considérons un point 3D pm exprimé dans le repère monde. Son équivalent pc dans ℜc peut être calculé de la façon suivante : pc = RT cv(RT vm(pm tvm) tcv) (2.20) Rvm et tvm sont calculés à partir de l’état du véhicule vk comme suit : tvm = ⎡ ⎣ xk yk zk ⎤ ⎦ (2.21)2.3. SLAM pour l’EKF dans un contexte de robotique mobile 37 Rvm = Rz(Θk)Ry(Φk)Rx(Ψk) = ⎡ ⎣ cos(Θk) − sin(Θk) 0 sin(Θk) cos(Θk) 0 0 01 ⎤ ⎦ ⎡ ⎣ cos(Φk) 0 sin(Φk) 0 10 − sin(Φk 0 cos(Φk) ⎤ ⎦ ⎡ ⎣ 10 0 0 cos(Ψk) − sin(Ψk) 0 sin(Ψk) cos(Ψk) ⎤ ⎦ (2.22) Le calcul est similaire pour Rcv et tcv mais à partir des paramètres extrinsèques mesurés. Le passage de ℜc à ℜi est différent puisqu’il fait passer d’un point 3D à son équivalent 2D dans l’image. Pour effectuer cette opération, un modèle de la caméra est nécessaire. Le modèle sténopé est généralement utilisé de par sa simplicité. Celui-ci ne nécessite que quelques paramètres concernant la caméra qui peuvent être déterminés par un calibrage. Il s’agit des paramètres intrinsèques de la caméra. Ils peuvent être organisés sous forme matricielle afin de faciliter le changement de repère : F = ⎡ ⎣ cu fu 0 cv 0 fv 100 ⎤ ⎦ (2.23) où  cu cv est le point principal de l’image (projection du centre optique) et  fu fv correspond à la distance focale suivant les 2 axes. Le modèle sténopé nous donne ainsi la projection d’un point  xyz T dans l’image : ⎡ ⎣ su sv s ⎤ ⎦ = F ⎡ ⎣ x y z ⎤ ⎦ (2.24) Cela nous donne le point  u v T dans l’image : ⎧ ⎪⎪⎪⎨ ⎪⎪⎪⎩ u = cux + fuy x v = cvx + fvz x (2.25) Nous pouvons maintenant compléter la figure 2.9 avec les nouveaux repères. Le résultat est visible en figure 2.11. Les étapes présentées ici sont utilisées afin de projeter un point de la carte depuis le repère monde vers le repère image. Il s’agit de l’étape de prédiction des observations. Comme nous nous sommes placés dans le cadre d’un EKF itératif, nous définissions h comme la fonction non linéaire permettant de projeter un amer aik−1 depuis le repère monde dans le plan image. Il est ainsi possible de définir une observation zk comme étant le point de l’image correspondant à la prédiction de aik−1 dans ℜi . Ainsi, du point de vue de l’EKF, le calcul de l’innovation se traduit de la façon suivante : Δk = zk − h(vk|k−1 , aik−1 ) (2.26)38 Chapitre 2. Localisation d’un véhicule Figure 2.11 – Représentation des repères caméra et image et passage de l’un à l’autre La fonction h correspond en fait à l’enchaînement des équations (2.20) et (2.25) pour l’amer aik 1 défini dans le repère ℜm. Elle se traduit par le système suivant : ⎧ ⎪⎪⎪⎪⎪⎨ ⎪⎪⎪⎪⎪⎩ uik 1 = F1RT cv(RT vm(pm tvm) tcv) F3RT cv(RT vm(pm tvm) tcv) vik 1 = F2RT cv(RT vm(pm tvm) tcv) F3RT cv(RT vm(pm tvm) tcv) (2.27) où Fi représente la i ème ligne de la matrice de paramètres intrinsèques F. Nous pouvons maintenant calculer le gain de Kalman de manière similaire à l’équation (2.4). Ici, Rk caractérise le bruit dans l’image (matrice de taille 2 × 2) et Hk représente le calcul de la jacobienne de h suivant l’état xk|k 1 qui est ici limité à la pose du véhicule vk|k 1 et l’amer qui est couramment traité aik 1 . Cela signifie que le reste des amers de la carte n’intervient pas dans h et par conséquent : ∂h(vk|k 1 , aik 1 ) ∂aj=ik 1 = 0 (2.28) Ainsi, la jacobienne Hk sera nulle, hormis sur les lignes correspondant à la pose du véhicule et à l’amer observé. Pour une carte comportant n amers numérotés de 0 à n 1, Hk est de la forme suivante : Hk =  ∂h ∂vk|k 1 02×3i ∂h ∂aik 1 02×3n 3 3i  (2.29) Classification d’images et localisation d’objets par des m´ethodes de type noyau de Fisher Ramazan Gokberk Cinbis To cite this version: Ramazan Gokberk Cinbis. Classification d’images et localisation d’objets par des m´ethodes de type noyau de Fisher. Other. Universit´e de Grenoble, 2014. French. . HAL Id: tel-01071581 https://tel.archives-ouvertes.fr/tel-01071581 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.THÈSE Pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE Spécialité : Mathématiques, Sciences et Technologies de l’Information Arrêté ministériel : 7 août 2006 Présentée par Ramazan Gokberk Cinbis Thèse dirigée par Cordelia Schmid et codirigée par Jakob Verbeek préparée au sein Inria Grenoble et de l’école doctorale MSTII : Mathématiques, Sciences et Technologies de l’Information, Informatique Classification d’images et localisation d’objets par des méthodes de type noyau de Fisher Fisher kernel based models for image classification and object localization Thèse soutenue publiquement le 22 juillet 2014, devant le jury composé de : Dr. Florent Perronnin Xerox Research Centre Europe, Meylan, France, Président Pr. Martial Hebert Carnegie Mellon University, Pittsburgh, PA, USA, Rapporteur Pr. Andrew Zisserman University of Oxford, Oxford, UK, Rapporteur Pr. Deva Ramanan University of California at Irvine, Irvine, CA, USA, Examinateur Dr. Cordelia Schmid Inria Grenoble, Montbonnot, France, Directeur de thèse Dr. Jakob Verbeek Inria Grenoble, Montbonnot, France, Co-Directeur de thèseii The research that lead to this thesis was carried out at the LEAR team of INRIA Grenoble. This work was supported by the QUAERO project (funded by OSEO, French State agency for innovation), the European integrated project AXES and the ERC advanced grant ALLEGRO.Abstract In this dissertation, we propose models and methods targeting image understanding tasks. In particular, we focus on Fisher kernel based approaches for the image classification and object localization problems. We group our studies into the following three main chapters. First, we propose novel image descriptors based on non-i.i.d. image models. Our starting point is the observation that local image regions are implicitly assumed to be identically and independently distributed (i.i.d.) in the bag-of-words (BoW) model. We introduce non-i.i.d. models by treating the parameters of the BoW model as latent variables, which renders all local regions dependent. Using the Fisher kernel framework we encode an image by the gradient of the data loglikelihood with respect to model hyper-parameters. Our representation naturally involves discounting transformations, providing an explanation of why such transformations have proven successful. Using variational inference we extend the basic model to include Gaussian mixtures over local descriptors, and latent topic models to capture the co-occurrence structure of visual words. Second, we present an object detection system based on the high-dimensional Fisher vectors image representation. For computational and storage efficiency, we use a recent segmentation-based method to generate class-independent object detection hypotheses, in combination with data compression techniques. Our main contribution is a method to produce tentative object segmentation masks to suppress background clutter in the features. We show that re-weighting the local image features based on these masks improve object detection performance significantly. Third, we propose a weakly supervised object localization approach. Standard supervised training of object detectors requires bounding box annotations of object instances. This time-consuming annotation process is sidestepped in weakly supervised learning, which requires only binary class labels that indicate the absence/presence of object instances. We follow a multiple-instance learning approach that iteratively trains the detector and infers the object locations. Our main contribution is a multi-fold multiple instance learning procedure, which prevents training from prematurely locking onto erroneous object locations. We show that this procedure is particularly important when high-dimensional representations, such as the Fisher vectors, are used. Finally, in the appendix of the thesis, we present our work on person identification in uncontrolled TV videos. We show that cast-specific distance metrics can be learned without labeling any training examples by utilizing face pairs within tracks and across temporally-overlapping tracks. We show that the obtained metrics improve face-track identification, recognition and clustering performances. iiiiv Keywords Image classification, object detection, weakly supervised training, computer vision, machine learning.Résumé Dans cette thèse, nous proposons des modèles et des méthodes dédiés à des taches de compréhension de l’image. En particulier, nous nous penchons sur des approches de type noyau de Fisher pour la classification d’images et la localisation d’objets. Nos études se répartissent en trois chapitres. En premier lieu, nous proposons de nouveaux descripteurs d’images construits sur des modèles non-iid de l’image. Notre point de départ est l’observation que les régions locales d’une image sont souvent supposées indépendentes et identiquement distribuées (iid) dans les modèles de type sacs-de-mots (SdM). Nous introduisons des modèles non-iid en traitant les paramètres du SdM comme des variables latentes, ce qui rend interdépendantes toutes les régions locales. En utilisant le noyau de Fisher, nous encodons une image par le gradient de sa log-vraisemblance par rapport aux hyperparamètres du modèle. Notre représentation implique naturellement une invariance à certaines transformations, ce qui explique pourquoi de telles approches ont été courronnées de succès. En utilisant l’inférence variationnelle, nous étendons le modèle de base pour inclure un mélange de gaussiennes sur les descripteurs locaux, et un modèle latent de sujets pour capturer la structure co-occurente des mots visuels. Dans un second temps, nous présentons un système de détection d’objet reposant sur la représentation haute-dimension d’images par le vecteur de Fisher. Pour des raisons de complexité en temps et en espace, nous utilisons une méthode récente à base de segmentation pour engendrer des hypothèses de détection indépendantes des classes, ainsi que des techniques de compression. Notre principale contribution est une méthode pour produire des masques de segmentation potentiels, afin de supprimer le bruit du descripteur dû à l’arrière plan. Nous montrons que repondérer les descripteurs locaux de l’image en fonction de ces masques améliore significativement la performance en détection. Troisièmement, nous proposons une approche semi-supervisée pour la localisation d’objets. L’entrainement supervisé usuel de détecteurs d’objets nécessite l’annotation de boites englobantes des instances de ces objets. Ce processus coû- teux est évité en apprentissage semi-supervisé, lequel ne nécessite que des étiquettes binaires indiquant la présence ou l’absence des objets. Nous suivons une approche d’apprentissage à instance multiple en alterne itérativement entre entrainer un détecteur et inférer les positions des objets. Notre contribution principale est une procédure multi-état d’apprentissage à instance multiple, qui évite à l’apprentissage de se focaliser prématurément sur des positions d’objets erronnées. Nous montrons que cette procédure est particulièrement importante lorsque des représentations haute-dimensions comme le vecteur de Fisher sont utilisées. vvi Pour finir, nous présentons dans l’appendice de cette thèse notre travail sur l’identification de personnes dans des vidéos télévision non-contrôlées. Nous montrons qu’une distance adaptée au casting peut être apprise sans étiqueter d’exemple d’apprentissage, mais en utilisant des paires de visages au sein d’un même chemin et sur plusieurs chemins se chevauchant temporellement. Nous montrons que la métrique apprise améliore l’identification de chemins de visages, la reconnaissance et les performances en regroupement. Mots clés Classification d’image, détection d’objet, apprentissage faiblement supervisé, vision par ordinateur, apprentis-sage statistique.Acknowledgments I consider myself extremely lucky to have had the opportunity to work with my advisors Jakob Verbeek and Cordelia Schmid during my PhD. Their kind help and guidance in every bit of the PhD process, from choosing research directions to writing papers, have been invaluable. Jakob and Cordelia are my role models for being a scientist and an advisor. I would like to thank Andrew Zisserman, Martial Hebert, Deva Ramanan, and Florent Perronnin for kindly accepting to evaluate my work. I am grateful for having such an exceptional group of jury members. LEAR team has been a great working environment with its friendly culture. I would like to thank Zaid Harchaoui, Matthijs Douze, Karteek Alahari, and Julien Mairal for the informative and interesting discussions. I would like to also acknowledge the tremendous help by Matthijs while releasing the source code of our object detector. Special thanks to Dan Oneata for being a great roommate (and helping me in a lot of ways!), Adrien Gaidon for being a great officemate, Thomas Mensink for hosting me multiple times as a guest flatmate, and Mattis Paulin for kindly translating the thesis abstract. I would like to thank Albert Gordo, Alessandro Prest, Anoop Cherian, Arnau Ramisa, Danila Potapov, Federico Pierucci, Gaurav Sharma, Guillaume Fortier, Heng Wang, Jerome Revaud, Josip Krapac, Matthieu Guillaumin, Mohamed Ayari, Philippe Weinzaepfel, Piotr Koniusz, Shreyas Saxena, Yang Hua, Zeynep Akata, and many others for their friendship over the years. I would like to thank Nathalie Gillot for her help in administrative tasks and beyond. I am eternally grateful to my family, my parents, and my parents-in-law for their understanding and the sacrifices they have made on behalf of this thesis. This work would simply not have been possible without them. My wife Nazlı and my son Çınar Kagan, who experienced the most my frequent travels away from home ˘ and my constant busyness even when I am at home, have always been hugely supportive. This thesis is dedicated to my dear wife and my dear son. viiContents Abstract iii Résumé v Acknowledgments vii 1 Introduction 1 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Related Work 9 2.1 Image representations . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.1 Patch-based descriptors . . . . . . . . . . . . . . . . . . . 10 2.1.2 Incorporating spatial structure . . . . . . . . . . . . . . . 19 2.1.3 Other recent descriptors . . . . . . . . . . . . . . . . . . 21 2.2 Image classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.2 Support Vector Machines . . . . . . . . . . . . . . . . . . 26 2.2.3 Kernel functions and descriptor transformations . . . . . . 29 2.3 Object detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.1 Localization strategies . . . . . . . . . . . . . . . . . . . 32 2.3.2 Window descriptors and classifiers . . . . . . . . . . . . . 35 2.3.3 Contextual relationships . . . . . . . . . . . . . . . . . . 37 2.4 Weakly supervised object localization . . . . . . . . . . . . . . . 38 2.4.1 Initialization methods . . . . . . . . . . . . . . . . . . . 39 2.4.2 Iterative learning methods . . . . . . . . . . . . . . . . . 40 3 Image Categorization using Fisher Kernels of Non-iid Image Models 43 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2 Fisher vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3 Non-iid image representations . . . . . . . . . . . . . . . . . . . 49 3.3.1 Bag-of-words and the multivariate Pólya model . . . . . . 49 3.3.2 Modeling descriptors using latent MoG models . . . . . . 51 3.3.3 Capturing co-occurrence with topic models . . . . . . . . 56 3.4 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 57 3.4.1 Experimental setup . . . . . . . . . . . . . . . . . . . . . 58 3.4.2 Evaluating latent BoW and MoG models . . . . . . . . . 58 3.4.3 Evaluating topic model representations . . . . . . . . . . 60 ixx CONTENTS 3.4.4 Relationship between model likelihood and categorization performance . . . . . . . . . . . . . . . . . . . . . . . . 61 3.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4 Segmentation Driven Object Detection with Fisher Vectors 65 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.2 Segmentation driven object detection . . . . . . . . . . . . . . . . 68 4.2.1 Segmentation mask generation . . . . . . . . . . . . . . . 68 4.2.2 Feature extraction . . . . . . . . . . . . . . . . . . . . . . 69 4.2.3 Feature compression . . . . . . . . . . . . . . . . . . . . 71 4.2.4 Training the detector . . . . . . . . . . . . . . . . . . . . 72 4.2.5 Contextual rescoring . . . . . . . . . . . . . . . . . . . . 73 4.3 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 74 4.3.1 Parameter evaluation on the development set . . . . . . . 74 4.3.2 Evaluation on the full PASCAL VOC 2007 . . . . . . . . 76 4.3.3 Comparison to existing work . . . . . . . . . . . . . . . . 80 4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5 Multi-fold MIL Training for Weakly Supervised Object Localization 87 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2 Weakly supervised object localization . . . . . . . . . . . . . . . 90 5.2.1 Features and detection window representation . . . . . . . 90 5.2.2 Weakly supervised object detector training . . . . . . . . 91 5.3 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 94 5.3.1 Dataset and evaluation criteria . . . . . . . . . . . . . . . 94 5.3.2 Multi-fold MIL training and context features . . . . . . . 95 5.3.3 Comparison to state-of-the-art WSL detection . . . . . . . 99 5.3.4 Discussion and analysis . . . . . . . . . . . . . . . . . . 102 5.3.5 Training with mixed supervision . . . . . . . . . . . . . . 105 5.3.6 VOC 2010 evaluation . . . . . . . . . . . . . . . . . . . . 106 5.3.7 Application to image classification . . . . . . . . . . . . . 108 5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6 Conclusion 113 6.1 Summary of contributions . . . . . . . . . . . . . . . . . . . . . 113 6.2 Future research perspectives . . . . . . . . . . . . . . . . . . . . 115 A Unsupervised Metric Learning for Face Verification in TV Video 119 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 A.3 Unsupervised face metric learning . . . . . . . . . . . . . . . . . 123CONTENTS xi A.3.1 Face detection, tracking, and features . . . . . . . . . . . 123 A.3.2 Metric learning from face tracks . . . . . . . . . . . . . . 125 A.3.3 Metrics for verification and recognition . . . . . . . . . . 127 A.4 Experimental evaluation . . . . . . . . . . . . . . . . . . . . . . 128 A.4.1 Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 A.4.2 Experimental results . . . . . . . . . . . . . . . . . . . . 128 A.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Publications 137 Bibliography 139List of Figures 1.1 Example images from several datasets. . . . . . . . . . . . . . . . 3 1.2 Local image patches are not iid: the visible patches are informative on the masked-out ones; one has the impression to have seen the complete image by looking at half of the patches. . . . . . . . . . 5 1.3 Estimated foregroud masks for example images. The masks are used to suppress background clutter for object detection. . . . . . 6 1.4 Examples of the iterative re-localization process for the chair and bottle classes from initialization (left) to the final localization (right). Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. . . . . . . . . . . . . . 7 3.1 Local image patches are not iid: the visible patches are informative on the masked-out ones; one has the impression to have seen the complete image by looking at half of the patches. . . . . . . . . . 44 3.2 The score of a linear ‘cow’ classifier will increase similarly from images (a) through (d) due to the increasing number of cow patches. This is undesirable: the score should sharply increase from (a) to (b), and remain stable among (b), (c), and (d). . . . . 46 3.3 Comparison of (left to right) `2, Hellinger, and chi-square distances for x and y values ranging from 0 to 1. Both the Hellinger and chisquare distance discount the effect of small changes in large values unlike the `2 distance. . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4 Graphical representation of the models in Section 3.3.1: (a) multinomial BoW model, (b) Pólya model. The outer plate in (b) refer to images. The index i runs over the N patches in an image, and index k over visual words. Nodes of observed variables are shaded, and those of (hyper-)parameters are marked with a central dot in the node. 50 3.5 Digamma functions ψ(α +n) for various α, and √ n as a function of n; functions have been rescaled to the range [0,1]. . . . . . . . 51 3.6 Graphical representation of the models in Section 3.3.2: (a) MoG model, (b) latent MoG model. The outer plate in (b) refer to images. The index i runs over the N patches in an image, and index k over visual words. Nodes of observed variables are shaded, and those of (hyper-)parameters are marked with a central dot in the node. 52 3.7 Graphical representation of LDA. The outer plate refers to images. The index i runs over patches, and index t over topics. . . . . . . . 56 xiiixiv LIST OF FIGURES 3.8 Comparison of BoW representations: square-root BoW (green) and Pólya latent BoW model (blue), (a) without SPM and (b) with SPM. Relative mAP is defined as the difference between a given mAP score and the mAP score of the corresponding baseline plain BoW representation. . . . . . . . . . . . . . . . . . . . . . . . . 59 3.9 Comparison of MoG representations: square-root MoG (green) and latent MoG (blue), (a) without SPM and (b) with SPM. Relative mAP is defined as the difference between a given mAP score and the mAP score of the corresponding baseline plain MoG representation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.10 Topic models (T = 2, solid) compared with BoW models (dashed): BoW/PLSA (red), square-root BoW/PLSA (green), and Pólya/LDA (blue). SPM included in all experiments. . . . . . . . . . . . . . . 61 3.11 Performance when varying the number of topics: PLSA (red), square-root PLSA (green), and LDA (blue). BoW/Pólya model performance included as the left-most data point on each curve. All experiments use SPM, and K = 1024 visual words. . . . . . . 62 3.12 Evaluation of the model log-likelihood and the classification performance in terms of mAP scores as a function of the number of PCA dimensions (D) and the vocabulary size (K). The x-axis of each plot shows the number of PCA dimensions. Each curve represents a set of (D,K) values such that D×K stays constant. . . . 64 4.1 Illustration of the segmentation-driven process for estimating feature-weighting masks. For each candidate window, we estimate a foreground mask using multiple superpixel segmentations that are originally computed for generating the candidate windows of Uijlings et al. [2013] . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2 Segmentation masks for two correct (top) and two incorrect (bottom) candidate windows. The first four columns show the window, the merged segment that produced that window, our weighted mask, and the masked window. The eight images on the right show the binary masks of superpixels lying fully inside the window, for each of the eight segmentations. . . . . . . . . . . . . . . . . . . 69 4.3 Example images where the top scoring detection improves (top three rows) or degrades (bottom row) with inclusion of the masked window descriptors. Correct detections are shown in yellow, incorrect ones in magenta. See text for details. . . . . . . . . . . . . . 78LIST OF FIGURES xv 5.1 Distribution of the window scores in the positive training images following the fifth iteration of standard MIL training on VOC 2007. The right-most curve in terms of the mean scores correspond to the windows chosen in the latest re-localization step and utilized for training the detector. The curve in the middle correspond to the other windows that overlap more than 50% with the training windows. Similarly, the left-most curve correspond to the windows that overlap less than 50%. Each curve is obtained by averaging all per-class score distributions. Filled regions denote the standard deviation at each point. . . . . . . . . . . . . . . . . . . . . . . . 92 5.2 Distribution of inner products, scaled to the unit interval, of pairs of 50,000 windows sampled from 500 images using our highdimensional FV (top), and a low-dimensional FV (bottom). (a) uses all window pairs and (b) uses only within-image pairs, which are more likely to be similar. . . . . . . . . . . . . . . . . . . . . 93 5.3 Example failure cases on the bird, cat and dog images. Each row shows the re-localization process from initialization (left) to the fi- nal localization (right) and three intermediate iterations using standard MIL or multi-fold MIL. In these cases, whereas standard MIL finds full-object windows, multi-fold training localizes down to sub-regions of the objects. Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. . . 97 5.4 Correct localization (CorLoc) performance on training images averaged across classes over the MIL iterations starting from the first iteration after initialization. We show results for standard MIL training, and our multi-fold training algorithm. We also show results for both when using the 516 dimensional descriptors. CorLoc of the initial windows is 17.4%. . . . . . . . . . . . . . . . . . . 98 5.5 Correct localization (CorLoc) performance on training images averaged across classes over the MIL iterations starting from the first iteration after initialization. We compare results for standard MIL training using a number of different SVM cost parameters (C) vs. the multi-fold MIL training. We use C = 1000 for multi-fold MIL training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.6 Examples of the re-localization process using multi-fold training for images of nine classes from initialization (left) to the final localization (right) and three intermediate iterations. Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. . . . . . . . . . . . . . . . . . . . . . . . . 100 5.7 AP vs. CorLoc for multi-fold MIL (left), and ratio of WSL over supervised AP as a function of CorLoc (right). . . . . . . . . . . . 104xvi LIST OF FIGURES 5.8 Distribution of localization error types for each class, and averaged across all 20 VOC’07 classes using 10-fold MIL and standard MIL training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.9 Object detection results for training with mixed supervision. Each curve shows the detection AP as a function of the number of fullysupervised training images up to the point where all positive training images are fully-supervised. The first eight plots show per-class curves for the 20 classes and the last one shows the detection AP values averaged over all classes. The mixed supervision results are shown with solid lines and the fully-supervised baseline results are shown with dotted lines using the same color and edge markers as in the corresponding mixed supervised curves . . . . . . . . . . . 107 A.1 An overview of our processing pipeline. (a) A face detector is applied to each video frame. (b) Face tracks are created by associating face detections. (c) Facial points are localized. (d) Locally SIFT appearance descriptors are extracted on the facial features, and concatenated to form the final face descriptor. . . . . . . . . . 123 A.2 Example tracks. Each track is subsampled to 10 frames. . . . . . . 124 A.3 Equal error rate (EER) as a function of the number of training examples when using metrics learned from only supervised tracks (S, cyan) and using semi-supervised learning that also exploits unlabeled tracks to learn the metric (S+U, magenta). The performance of the L2 distance (green) and a metric learned on the LFW set (blue) are also shown for reference. . . . . . . . . . . . . . . . . . 129 A.4 2D projections of all face descriptors in the test set using LDML metrics trained on (a) all images in the LFW dataset, (b) the 227 supervised training tracks, and (c) using unsupervised training on the test tracks. The faces of the different people are color coded. . 130 A.5 Normalized histogram of distances of face pairs sampled from positive (left) and negative (right) track pairs. . . . . . . . . . . . . . 131 A.6 Nearest neighbor classification results. . . . . . . . . . . . . . . . 132 A.7 Multi-class logistic discriminant classification results. . . . . . . . 132 A.8 Evaluation of hierarchical clustering error based on different distance metrics, the true number of characters is eight. . . . . . . . . 134 A.9 Clustering results using an unsupervised metric (top), and a supervised metric (bottom). Each face image corresponds to unique track. The number of incorrect tracks shown (red) are proportional to the cluster purity. Figure is best viewed in color. . . . . . . . . 135List of Tables 3.1 Comparison of BoW representations: plain BoW, square-root BoW and Pólya. The data is the same as in Figure 3.8. . . . . . . . . . . 59 3.2 Comparison of MoG representations: plain MoG, square-root MoG and latent MoG. The data is the same as in Figure 3.9. . . . 60 4.1 The list of window descriptor components. The final descriptor is obtained by concatenating all components. . . . . . . . . . . . . . 71 4.2 Performance on the development set with different descriptors (S: SIFT, C: color), regions (W: window, G: generating segment, M: mask), and with / without SPM. . . . . . . . . . . . . . . . . . . 75 4.3 Performance on VOC’07 with different descriptors (S: SIFT, C: color), regions (W: window, M: mask, F: full image, X: contextual rescoring) using K = 64 Gaussians. . . . . . . . . . . . . . . . . 76 4.4 Performance on VOC’07 with varying number of Gaussians using SIFT local descriptors and window regions only. . . . . . . . . . . 77 4.5 Comparison of our detector using the candidate windows generated by Selective Search (SS) [Uijlings et al. 2013] vs. Randomized Prim (RP) [Manen et al. 2013a]. K = 64 Gaussians are used in the experiments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.6 The abbreviation list for Table 4.7 and Table 4.8. . . . . . . . . . 81 4.7 Comparison of our detector with and without context with the stateof-the-art object detectors on VOC 2007. Each method is shown with an abbreviation, see Table 4.6 for the corresponding citations. 81 4.8 Comparison of our detector with and without context with the stateof-the-art object detectors on VOC 2010. Each method is shown with an abbreviation, see Table 4.6 for the corresponding citations. 83 5.1 Evaluations on the PASCAL VOC 2007 dataset, in terms of correct localization (CorLoc) measure. . . . . . . . . . . . . . . . . . . . 95 5.2 Evaluations on the PASCAL VOC 2007 dataset, in terms of average precision (AP) measure. . . . . . . . . . . . . . . . . . . . . . . . 96 5.3 The abbreviation list for Table 5.4 and Table 5.5. . . . . . . . . . 99 xviixviii LIST OF TABLES 5.4 Comparison of our multi-fold MIL method based on foreground+contrastive descriptors against state-of-the-art weakly-supervised detectors on PASCAL VOC 2007 in terms of correct localization on positive training images (CorLoc). Each method is shown with an abbreviation, see Table 5.3 for the corresponding citations. The results for PL’11 were obtained through personal communication and those for ATH’02 and NTTR’09 are taken from Siva and Xiang [2011]. . 101 5.5 Comparison of weakly-supervised object detectors on PASCAL VOC 2007 in terms of test-set detection AP. Our detector is trained using the proposed multi-fold MIL over foreground+contrastive descriptors. Each method is shown with an abbreviation, see Table 5.3 for the corresponding citations. The results of Prest et al. [2012] are based on external video data for training. The results for PL’11 are taken from Prest et al. [2012]. . . . . . . . . . . . . . . 101 5.6 Performance on VOC 2007 with varying degrees of supervision. All results use window+contrastive descriptor. . . . . . . . . . . . 102 5.7 Comparison of standard MIL training vs our 10-fold MIL on VOC 2010 in terms of training set localization accuracy (CorLoc) using foreground+contrastive descriptors. . . . . . . . . . . . . . . . . 108 5.8 Comparison of standard MIL training vs our 10-fold MIL on VOC 2010 in terms of test set AP using foreground+contrastive descriptors.108 5.9 Image classification results on VOC 2007. RLYF’12 and SPC’12 are the abbreviations for Russakovsky et al. [2012] and Sánchez et al. [2012], respectively. “Cls-by-det” stands for classificationby-detection and “Det-driven” stands for detection-driven. See text for more details. . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.1 Comparison of supervised (S) and semi-supervised (S+U) training using average (avg) and min-min track distances. The EER is shown for several numbers of supervised training tracks. . . . . . 130 A.2 Comparison of labeling cost using different metrics for eight clusters (equals the number of characters). . . . . . . . . . . . . . . . 133CHAPTER 1 Introduction Contents 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 One of the main topics in computer vision research is image understanding, which refers to a set of inter-related tasks. These tasks include, but are not limited to detection of objects, recognition of scenes and inference of the relationships across objects in images. Image understanding tasks have received increasingly wider research interest due to their short-term and long-term importance. In the short-term, these tasks have numerous real-world applications without requiring a complete image understanding system. Some of the most popular applications include content-based querying of web-scale image databases (i.e. image retrieval), autonomous robot navigation in uncontrolled environments, video surveillance for security and safety purposes. In the long-term, these tasks are crucial for building up artificial systems that aim to match the human visual cognitive capabilities. In this dissertation, we focus on two main image understanding tasks. The first one is image categorization, where the problem is to classify images into predefined categories. The second one is object detection, where the the problem is to localize and recognize objects in images. 1.1 Context Modern research on image understanding is considered to have started in 1960s [Andreopoulos and Tsotsos 2013]. The focus of the first studies was mostly character recognition and simple template matching [Hu 1962, Mundy 2006, Roberts 1960]. The Builder project started at MIT in 1965 is probably the earliest project that is aiming to build a comprehensive image understanding system. The main goal of the project was to build a robot for manipulating wooden blocks, and therefore a program to recognize wooden blocks and their poses was necessary [Minsky 2007]. The difficulty of the object recognition problem was 12 CHAPTER 1. INTRODUCTION initially under-estimated and it was planned to complete the perception within a summer. Instead it took several years to implement a working system, and the final architecture ended up being much more complex than what was initially planned. Since 1960s, there has been significant progress in image understanding technology, despite the fact that it is still far from reaching human vision capabilities. Two external factors have been particularly important for the progress made in the past decade. The first important factor is the improvements in the computational resources. As summarized by the Moore’s law, number of transistors on processor chips has been doubling approximately every two years. As a result of this exponential growth, even an average contemporary desktop machine provides computational power that hardly any researcher could have accessed twenty years ago. The second factor is the dramatic increase in the availability of visual content. For example, each minute, tens of thousands of images are uploaded to Flickr and 100 hours of video are uploaded to YouTube according to the statistics released by these websites. Proliferation of the computational resources and the visual content have significantly impacted the computer vision research. In the following paragraphs, we list three outcomes that are of particular interest for this dissertation. The first outcome is the adoption of larger and more realistic datasets by the research community. The UIUC [Agarwal and Roth 2002] and Caltech 101 [FeiFei et al. 2004] datasets are among the first examples of the benchmark datasets developed for image categorization and object detection research. Although these datasets used to be popular testbeds, they are now considered outdated by the community due to the lack of real-world challenges in them [Ponce et al. 2006]. For example, UIUC contains side-view cars with few occlusions (See Figure 1.1a for example images) and Caltech101 contains little background clutter and little object scale variation (See Figure 1.1b). Newer benchmark datasets like PASCAL VOC [Everingham et al. 2010] and ImageNet [Deng et al. 2009] are improved in these respects and they provide a more realistic testbed (See Figure 1.1c and Figure 1.1d). In addition, newer datasets are typically much larger in terms of the dataset scale: While Caltech101 contains ∼5,000 images and one object instance per image, PASCAL VOC 2012 contains ∼20,000 images and 2.7 instances per image and ImageNet 2013 contains ∼500,000 images and 2.8 instances per image. Such large-scale benchmark dataset are now easier to collect thanks to the abundant amount of images and videos available online and now easier to process thanks to the advancements in computational resources. The transition to well-designed benchmark datasets not only allows a more objective comparison of approaches across publications, but also provides more training data for fitting models. This reduces overfitting issues, i.e. allows building models with likely higher performance in uncontrolled environments. However, even the largest benchmark datasets of today still contain dataset-specific biases [Torralba and Efros 2011]. Therefore,1.1. CONTEXT 3 (a) UIUC Car Dataset (b) Caltech101 Dataset (c) PASCAL VOC Dataset (d) ImageNet Dataset Figure 1.1 – Example images from several datasets.4 CHAPTER 1. INTRODUCTION strategies to enable exploitation of larger and more realistic training datasets is an important research direction towards building real-world image understanding systems. The second outcome is the rising importance given to rich object representations. A mainstream idea in early object detection research was to model objects using geometric primitives like generalized cylinders [Binford 1971, Brooks 1981], generalized cones called geons [Biederman 1987] or geometric invariants [Rothwell et al. 1993]. A major problem with these approaches is the fact that localization of geometric primitives has been very unreliable. Therefore, research interest progressively shifted to local and global appearance descriptor-based methods [Mundy 2006], a change pioneered by the works of Murase and Nayar [1993], Schmid and Mohr [1997], Schmid et al. [1996]. This shift is further accelerated as the importance of having rich descriptors is observed on the benchmark datasets and relatively costly feature extraction pipelines become feasible. Today, development of strong representations is continuing to be one of most important research directions. The third outcome is the development of the learning based recognition methods, rather than ad-hoc models that are hand-tuned. Aforementioned works based on geometric primitives mostly used manually tuned object models with few parameters. However, manual optimization is not feasible anymore for the contemporary object models. For example, bag-of-words [Csurka et al. 2004b] and Mixture of Gaussian Fisher vector [Sánchez et al. 2013] descriptors have dimensionalities varying from a few thousand to a few hundred thousand depending on the hyperparameters. Furthermore, recently emerging deep learning-based representations like Krizhevsky et al. [2012] are parameterized by millions of variables. As a result, usage and development of machine learning algorithms is now a central topic in the image understanding research. 1.2 Contributions Despite the significant progress made in the past decade, we are still far from solving the image understanding problems. The following paragraphs explain the problems that we focus on and our corresponding contributions. What are the limitations of the contemporary image representations and how can we improve them? We focus on the bag-of-words (BoW) and mixture of Gaussian Fisher vector representations, which rely on image models that treat an image as an unordered set of local regions. Implicitly, regions are assumed to be identically and independently distributed (iid). However, the iid assumption is a very poor one from a modeling perspective, which we illustrate in Figure 1.2. We1.2. CONTRIBUTIONS 5 Figure 1.2 – Local image patches are not iid: the visible patches are informative on the masked-out ones; one has the impression to have seen the complete image by looking at half of the patches. introduce a non-iid BoW model by treating the parameters of BoW model as latent variables which are integrated out, rendering all local regions dependent. Using variational inference we extend the basic model to include mixture of Gaussian (MoG) models over local descriptors, and latent topic models to capture the cooccurrence structure of visual words. Using the Fisher kernel we encode an image by the gradient of the data log-likelihood w.r.t. hyper-parameters that control priors on the model parameters. Our representations naturally involves discounting transformations similar to square-rooting and provides an explanation of why such transformations have proven successful for BoW and MoG Fisher vector representations. We obtain state-of-the-art categorization performance using linear classifiers; without using discounting transformations or using (approximate) explicit embeddings of non-linear kernels. This work is published in Cinbis et al. [2012] and presented in Chapter 3. Can we benefit from rich object representations and weak segmentation cues in object detection? State-of-the-art representations for image categorization are much higher dimensional and arguably much richer compared to typically used representations for object detection, like Histogram of Oriented Gradients [Dalal and Triggs 2005]. We present an object detection system based on the Fisher vector image representation computed over SIFT and color descriptors. For computational and storage efficiency, we use a recent selective search method [van de Sande et al. 2011] to generate class-independent object detection hypotheses, in combination with data compression techniques. Our main contribution is a method to produce tentative object segmentation masks to suppress background clutter in the features which are obtained using superpixel-based weak segmentation cues. We provide example segmentation masks in Figure 1.3. Re-weighting the local image features based on these masks is shown to improve object detection performance signif-6 CHAPTER 1. INTRODUCTION Figure 1.3 – Estimated foregroud masks for example images. The masks are used to suppress background clutter for object detection. icantly. We also exploit contextual features in the form of a full-image Fisher vector descriptor, and an inter-category rescoring mechanism. We obtain state-ofthe-art detection results on the PASCAL VOC 2007 and 2010 datasets. This work is published in Cinbis et al. [2013] and presented in Chapter 4. Can we train object detectors using weak supervision towards enabling the use of larger training datasets? Standard supervised training for object detection requires bounding box annotations of object instances. Whereas precise object locations simplify the training process, the time-consuming manual annotation process practically limits the size of the training datasets. Using weakly supervised learning, the necessary supervision for object detector training can be restricted to binary labels that indicate the absence/presence of object instances in the image, without their locations. We follow a multiple-instance learning approach that iteratively trains the detector and infers the object locations in the positive training images. Based on the results we obtain in Chapter 4, we represent detection windows using the powerful Fisher vector representation and restrict the search space using the selective search [van de Sande et al. 2011]. Our main contribution is a multi-fold multiple instance learning procedure, which prevents training from prematurely locking onto erroneous object locations. This procedure is particularly important when high-dimensional representations, such as Fisher vectors, are used. We present a detailed experimental evaluation using the PASCAL VOC 2007 dataset, for which we show example localizations in Figure 1.4. Compared to state-of-the-art weakly supervised detectors, our approach better localizes objects in the training images, which translates into improved detection performance. Finally, we also show that our weakly supervised localization can be used for extracting object-focused image representation, which provides significant gains in image categorization performance. This work is published in Cinbis et al. [2014] and presented in Chapter 5. Finally, we note that Appendix A contains our work on verification of face tracks that are automatically collected from uncontrolled TV video data. The goal of face verification is to decide whether two faces depict the same person or not.1.2. CONTRIBUTIONS 7 Figure 1.4 – Examples of the iterative re-localization process for the chair and bottle classes from initialization (left) to the final localization (right). Correct localizations are shown in yellow, incorrect ones in pink. This figure is best viewed in color. Face-track verification is an important component in systems that automatically label characters in TV series or movies based on subtitles and/or scripts: it enables effective transfer of the sparse text-based supervision to other faces. We show that, without manually labeling any examples, metric learning can be effectively used to address this problem. This is possible by using pairs of faces within a track as positive examples, while negative training examples can be generated from pairs of face tracks of different people that appear together in a video frame. In this manner we can learn a cast-specific metric, adapted to the people appearing in a particular video, without using any supervision. Verification performance can be further improved using semi-supervised learning where we also include labels for some of the face tracks. We show that our cast-specific metrics not only improve verification, but also recognition and clustering. This study was carried out as part of the thesis research and published in Cinbis et al. [2011]. Since this material is only loosely related to the other contributions, we include it as an appendix. The structure of the thesis is as follows: Before presenting our technical contributions in Chapters 3, 4 and 5, we give an overview of the related work in Chapter 2. We conclude the thesis with a summary and perspectives in Chapter 6.CHAPTER 2 Related Work Contents 2.1 Image representations . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.1 Patch-based descriptors . . . . . . . . . . . . . . . . . . . . 10 2.1.2 Incorporating spatial structure . . . . . . . . . . . . . . . . 19 2.1.3 Other recent descriptors . . . . . . . . . . . . . . . . . . . 21 2.2 Image classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.2 Support Vector Machines . . . . . . . . . . . . . . . . . . . 26 2.2.3 Kernel functions and descriptor transformations . . . . . . . 29 2.3 Object detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.1 Localization strategies . . . . . . . . . . . . . . . . . . . . 32 2.3.2 Window descriptors and classifiers . . . . . . . . . . . . . . 35 2.3.3 Contextual relationships . . . . . . . . . . . . . . . . . . . 37 2.4 Weakly supervised object localization . . . . . . . . . . . . . . . 38 2.4.1 Initialization methods . . . . . . . . . . . . . . . . . . . . 39 2.4.2 Iterative learning methods . . . . . . . . . . . . . . . . . . 40 In this chapter, we first provide a review of image representations in Section 2.1, which provides an overview of the methods for feature extraction over images and image regions. In Section 2.2, we overview the classification methods for image categorization tasks, where the purpose is to automatically assign a subset of the predefined labels to novel images. In Section 2.3, we overview the object detection approaches, where the task is to learn object localization models based on training images with bounding box annotations. Finally, in Section 2.4, we overview weakly supervised object localization methods, where the task is to learn object localization models using image-level binary object category labels only. In our overview, we focus only on the most relevant approaches for the thesis. A broader overview on image understanding can be found in the recent survey paper by Andreopoulos and Tsotsos [2013]. 910 CHAPTER 2. RELATED WORK 2.1 Image representations In this section, we overview image representation methods. We first overview patch-based descriptors, which are defined over the decomposition of images into a bag of image fragments. Then, we overview approaches for encoding the spatial structure across the image patches, which is typically ignored by the patch-based image descriptors. Finally, we shortly overview several other recent image representations. 2.1.1 Patch-based descriptors Patch-based image descriptors are built upon the notion of the extracting image descriptors by first decomposing an image into small patches. In this section, we first present the bag of words (BoW) descriptor as a concrete example to introduce the fundamentals of the patch-based descriptors. Then, we break down patch-based descriptors into four generic steps and overview the approaches proposed for each one of the four steps. Bag of words (also known as bag of visual words, bag of features or bag of keypoints) has been one of the most popular image representations of the past decade. BoW is originally developed as a text representation [Salton and McGill 1983] where a document is represented by a vector of word counts, i.e. a word histogram. In the works by Sivic and Zisserman [2003] and Csurka et al. [2004a], BoW is adapted to the image domain for image retrieval and image categorization tasks, respectively. The main idea is to obtain visual words by quantizing local descriptors of image patches (i.e. image regions) with respect to a visual vocabulary. In these works, the vocabulary is constructed by clustering a large set of local descriptors using the k-means algorithm [Duda et al. 2001]. Since the introduction of the BoW representation for images, there has been significant interest on improving particular steps of the BoW feature extraction pipeline. In addition, a number of other works proposed image representations – like mixture of Gaussian Fisher Vectors [Sánchez et al. 2013] – that diverge considerably from the original BoW approach, even though they use the local descriptors as the basis of the image descriptors. We can accommodate a great number of such approaches, as well as the BoW variants, within the following generalized feature extraction pipeline: 1. Sample image patches. 2. Extract local descriptors from the image patches. 3. Encode local descriptors. 4. Aggregate the encoded local descriptors to obtain the final image descriptor.2.1. IMAGE REPRESENTATIONS 11 We refer to the image descriptor extraction approaches that can naturally be decomposed into these four steps as the patch-based descriptors. Below we overview the alternatives proposed in the literature for each one of these four steps. Step I: Patch sampling For object recognition tasks, the main responsibility of a patch sampling method is to obtain a representative set of image patches covering the essential information in a given image. There are two mainstream approaches for this purpose. The first one is to use an interest point detector and the second one is the dense sampling of patches on a regular grid at multiple scales. Interest point detectors aim to find a (sparse) set of distinctive regions based on low-level image cues. These algorithms are typically designed in order to find a similar set of locations of a particular object (or scene) from different viewpoints and varying light sources. There are a number of algorithms that are proposed for this purpose, the most important of these include: • Harris-affine detector [Mikolajczyk and Schmid 2004], which adds affine invariance to the Harris corner detector [Harris and Stephens 1988]. • Lowe [2004] proposes to detect interest points by finding local extrema in a Difference of Gaussian pyramid and then suppressing the interest points that have low-contrast or that are on the edges. • Maximally stable extremal regions (MSER) detector [Matas et al. 2004], which finds affine invariant regions by selecting regions that are relatively uniform in illumination and have a distinct appearance from their surroundings. Although interest point algorithms are particularly effective in object instance recognition, where the task is to recognize a particular object instance across different images, dense sampling of the patches have been observed to perform better for object recognition purposes [Nowak et al. 2006]. One possible explanation for this phenomenon is that patches needed for the object recognition task may not be located at interest points. Dense sampling avoids missing important information by sampling uniformly over the whole image. Dense sampling also has disadvantages. One issue is that sampling frequency needs to be high in order to ensure obtaining similar patches across the images. In fact, the categorization accuracy typically increases as the sampling frequency increases [Chatfield et al. 2011, Nowak et al. 2006]. However, increasing the sampling frequency may significant increase the cost feature extraction pipeline. One potential remedy is to use the combination of interest points and densely sampled12 CHAPTER 2. RELATED WORK patches. Another alternative scheme proposed by Tuytelaars [2010] is to find interest points within a dense grid. Step II: Local descriptors In the second step of the feature extraction pipeline, feature vectors, which are called the local descriptors, are extracted at image patches that are sampled in the first step. Just like interest point detectors, most local descriptors are developed for object instance recognition or image matching (i.e. viewpoint invariant point matching) and then some of them are utilized for the image categorization task. SIFT [Lowe 2004] is probably the single most popular local descriptor. The main idea is to use gradient orientation histograms as the local descriptor. More precisely, a SIFT descriptor for a given patch is computed using the following algorithm: 1. Compute gradient orientations and magnitudes at each pixel. 2. Divide the patch into a spatial grid (4×4). 3. Within each spatial cell, compute a gradient orientation histogram, where each pixel is weighted by its gradient magnitude times the weight given by a 2D Gaussian aligned with the patch. 4. Concatenate the per-cell histograms and `2-normalize the descriptor. 5. Truncate values above a threshold (0.2) and `2-normalize again. Probably its most distinctive property is to rely on gradient orientation histograms. While using gradients capture local shape information, histogramming reduces the effect of small spatial shifts. The first `2 normalization step provides invariance to multiplicative and additive illumination changes. Descriptor truncation is designed in order to reduce the effect of non-linear illumination changes, which may undesirably boost the magnitudes of a certain subset of gradients. There are several other popular local descriptors. For example, SURF [Bay et al. 2008] descriptor consists of basic statistics of the vertical and horizontal gradient responses from different sub-regions of a given patch, which is computationally very efficient. DAISY [Winder et al. 2009] can be considered as a variant of the SIFT descriptor, where circular spatial cells are used instead of rectangular spatial cells as in SIFT. Local Self-Similarity (LSS) [Shechtman and Irani 2007] depicts self-similarities within image patches by measuring and storing similarities of the sub-region pairs inside the patches. Aforementioned local descriptors are originally defined over monochrome images. One possible way to include color information is to concatenate features2.1. IMAGE REPRESENTATIONS 13 computed over color channels. For example, OpponentSIFT [van de Sande et al. 2010], which has been shown to be one of the best color-extensions for the SIFT descriptor, is obtained by computing SIFT descriptors within channels of the opponent color space. There are also other approaches that aim primarily to encode color information. For example, the color statistics descriptor proposed by Clinchant et al. [2007] splits each image patch into a 4×4 grid and computes the mean and variance per color channel within each spatial cell. Applying an unsupervised dimension reduction technique on the local descriptors as a preprocessing step can be beneficial. For instance, Principle Component Analysis (PCA) is now widely used [e.g. Chatfield et al. 2011, Farquhar et al. 2005, Sánchez et al. 2013], since not only it speeds up the feature extraction pipeline but also it can improve the encoding quality by decorellating the local descriptor dimensions. PCA can also be interpreted as an efficient approximation to using Mahalanobis distance with a globally estimated covariance matrix over the local descriptors [e.g. Sivic and Zisserman 2009]. Other dimension reduction techniques, like Partial Least Squares [e.g. Farquhar et al. 2005], may also be beneficial. There are a few studies on optimizing local descriptors for a particular task. For example, Philbin et al. [2010] propose discriminative dimension reduction methods for enhancing local descriptors towards improving image retrieval accuracy and Brown et al. [2011] propose a method to automatically tune parameters of a DAISY-like descriptor. A limitation of these approaches is their susceptibility to getting stuck in local optima due to non-convex formulations. Simonyan et al. [2012] instead formulate the spatial pooling region tuning and discriminative dimension reduction as a convex optimization problem. Step III: Encoding Encoding transforms the local descriptors obtained in the second step into a form that is more suitable than the raw local descriptors for constructing an image descriptor. The majority of the encoding methods require a visual vocabulary (also known as dictionary or codebook), which typically provides a reference partitioning of the descriptor space. Previously, we have defined the standard BoW representation [Csurka et al. 2004a, Sivic and Zisserman 2003] as a histogram of visual words. Equivalently, BoW can be defined more formally in terms of an explicit encoding function as follows: Let vq(x) be the vector quantization (VQ, also known as hard assignment) function that maps a given local descriptor x to a unique id in 1,...,K by finding the closest vocabulary center. Then, the BoW encoding of a given x is a binary vector of length K such that its vq(x)-th dimension is 1 and the rest is 0: φ(x) = [1{vq(x)} (k)]k=1:K (2.1)14 CHAPTER 2. RELATED WORK where φ(x) is the encoding function and 1A is the indicator function for any given set A. Then, the summation ∑x φ(x) over all local descriptors is equivalent to the BoW histogram. Standard BoW encoding has certain shortcomings. First, the information loss due to vector quantization can significantly reduce the effectiveness of the image descriptors. Second, k-means clustering does not necessarily form the optimal partitioning for encoding purposes. In the past decade, numerous alternative encoding and vocabulary construction methods have been proposed towards overcoming these problems. In the following paragraphs, we overview some of these methods. Vector quantization can cause significant information loss [Boiman et al. 2008, Philbin et al. 2008]. van Gemert et al. [2010] study this problem in two parts. First, a local descriptor can be similar to multiple visual words in the descriptor space, a problem also known as visual word ambiguity. Second, a local descriptor may be dissimilar to any of the visual words in a vocabulary, a problem referred to as visual word plausibility. A way to deal with these problems is to use soft-assignment, where a patch is assigned to multiple visual words in a weighted manner according to its proximity to vocabulary centers in the local descriptor space, see e.g. Jiang et al. [2007], Philbin et al. [2008], van Gemert et al. [2010]. Different weighting schemes can be used to deal with the visual word ambiguity or the plausibility problems [van Gemert et al. 2010]. Farquhar et al. [2005] utilize mixture of Guassian (MoG) models [Bishop 2006] as a generalization of the k-means clustering for constructing a visual vocabulary. Since a MoG model can better model the manifold of the local descriptors compared to k-means, resulting vocabularies may provide a better-performing image descriptor. In addition, MoG models naturally lead to a principled soft-assignment scheme for BoW encoding: φ(x) = [p(k|x)]k=1:K (2.2) where p(k|x) is the posterior probability for the component k of a given local descriptor x and K is the number of components. Several other clustering approaches have also been proposed for constructing visual vocabularies. For example, Jurie and Triggs [2005] propose a clustering approach based on mean-shift algorithm [Comaniciu and Meer 2002], which is more likely to create infrequent but informative visual words compared to k-means. Nistér and Stewénius [2006] proposes a hierarchical k-means algorithm, which allows creating and utilizing large visual vocabularies efficiently. Leibe et al. [2008] proposes to use an efficient agglomerative clustering method, which can automatically determine number of visual words according to the desired compactness of the clusters. Sparse coding provides an alternative framework for encoding local descriptors. The essential idea in sparse coding [Olshausen and Field. 1997] is to reconstruct a2.1. IMAGE REPRESENTATIONS 15 signal using a sparse subset of basis vectors, which constitute the visual vocabulary. In the context of local descriptor encoding, the following encoding corresponds to the classical formulation [e.g. Raina et al. 2007, Yang et al. 2009]: φ(x) = argmin α kx−Dαk 2 2 +λkαk1 (2.3) where each column of the dictionary D is a basis vector and the resulting α ? = φ(x) is the vector of reconstruction coefficients. kαk1 provides `1 regularization, which is known to induce sparsity by approximating `0 regularization (i.e. the number of non-zero reconstruction coefficients). Regularization weight λ sets the trade-off between minimizing the reconstruction error and maintaining the sparsity of the solution. An advantage of sparse coding is that it can perform well even when raw image patches are used as the local descriptors. However, sparse coding can be costly since a convex but non-linear optimization problem needs to be solved using numeric methods for each local descriptor. Locality-constrained Linear Coding (LLC) [Wang et al. 2010] provides a fast alternative to sparse coding, where `1 sparsity regularization is replaced with an `2 locality constraint: φ(x) = argmin α kx−Dαk 2 2 +λks(x) Tαk 2 2 (2.4) where s(x)is a vector of similarities between the basis vectors and the local descriptor x. An advantage of LLC is that the encoding problem can be solved analytically. Further speed up can be obtained by approximating the solution via pre-selecting the nearest neighboring basis vectors. Compared to the classical sparse coding encoding, LLC is much faster while providing competitive image categorization performance. Class supervision can be incorporated for improving visual vocabularies. A simple approach is to construct a separate visual vocabulary for each class independently. For this purpose, local descriptor samples are collected from the examples of each category [Farquhar et al. 2005]. This approach allows constructing visual words that appear frequently (only) within a particular class in a generative manner. However, it can have a significant computational overhead particularly during training. One possible solution is to employ a fast clustering technique [e.g. Verbeek et al. 2006]. Alternatively, Perronnin et al. [2006] propose to adapt per-class vocabularies from a universal vocabulary. An advantage of this vocabulary adaptation approach is the ability to use a universal vocabulary as a prior, which can be valuable for classes with few training examples. However, although the visual words given by a class-specific vocabulary appear more frequently within the corresponding class compared to those in a universal vocabulary, class-specific visual words are not necessarily more discriminative. Class supervision can also be utilized in a more discriminative manner. Some example approaches are as follows: Tuytelaars and Schmid [2007] first quantize16 CHAPTER 2. RELATED WORK the local descriptor space into a regular lattice to create a large number of bins and then selects a subset of them based on class frequencies within each bin. Fulkerson et al. [2008] propose to merge clusters from an initial large vocabulary in order to obtain a small set of informative visual words. Moosmann et al. [2008] propose randomized clustering forests, where a set of tree-structured quantizers are independently built such that construction of each tree is guided by the class labels of the local descriptors. Resulting set of trees are used for assigning a local descriptor to multiple visual words. Lazebnik and Raginsky [2009] propose a supervised clustering approach where local descriptor class labels are utilized in an information loss minimization framework. Mairal et al. [2009] propose to learn a sparse coding dictionary and patch classifiers jointly. A common limitation of all these works is that they try to improve the patch classification performance, where patch class labels are typically inherited from the corresponding images, rather than directly optimizing the final image categorization performance. Discriminative vocabulary learning for directly optimizing image descriptors have also received interest in the recent years. For example, Winn et al. [2005] propose to start training with an initial large vocabulary and iteratively merge pairs of visual words according to a probabilistic image model, where BoW histograms are assumed to follow per-class Gaussian distributions. Similarly, Yang et al. [2007] propose a method for jointly training an image classifier and implicitly merging co-occurring visual words. Yang et al. [2008] introduce a boosting-based image classifier where one visual word is added at each boosting iteration. Zhang et al. [2009] proposes to use boosting to re-weight images for iteratively adding new vocabularies. Lian et al. [2010] propose to learn a vocabulary similar to mixture of Gaussian model and the corresponding BoW-based corresponding image classifier jointly. Boureau et al. [2010], Yang et al. [2010] propose methods to jointly train sparse coding dictionaries and image classifiers. Krapac et al. [2011a] propose a method for greedily constructing quantization trees, where each candidate split is evaluated by its effect on the final image categorization performance. Cinbis and Sclaroff [2012] propose a boosting-based set classifier where an image can be represented directly by a set of local descriptors. When decision trees are utilized as the weak classifiers, each learned tree is equivalent to a tree-structured quantizer. Although advanced vocabulary methods and soft-assignment can improve the representations based on bag-of-words and similar encodings, the resulting recognition accuracy may still be inherently limited. One possible solution is to avoid quantization altogether and classify solely using local descriptors [e.g. Boiman et al. 2008]. An alternative and usually better-performing solution is to use a richer encoding that directly incorporates the information loss due to quantization. Mixture of Gaussian Fisher Vector (FV) [Perronnin and Dance 2007, Sánchez et al. 2013], Vector of Locally Aggregated Descriptors (VLAD) [Jégou et al. 2010], Super Vector (SV) [Zhou et al. 2010] , Hamming Embedding (HE) [Jégou et al.2.1. IMAGE REPRESENTATIONS 17 2008] representations and the sparse coding based Fisher Kernel proposed by Raina et al. [2007] incorporate such statistics. Let’s first consider the following encoding, which is equivalent to the FV encoding up to a constant transformation: φ(x) =    qk qkdk qkd 2 k    k=1:K (2.5) where K is the vocabulary size and qk = p(k|x) is the posterior probability for the k-th Gaussian. dk = x− µk is the difference vector of size D×1 between the local descriptor x and the center of the k-th Gaussian µk , where D is the dimensionality of the local descriptor. In this encoding, the first term encodes the visual word counts, the second term encodes the first moments and the third term encodes the second moments. The first and the second moments provide statistics encoding the information loss due to quantization, which is absent from the BoW-based representations. VLAD can be considered as a subset of the FV representation based on hardassignment and first moments only [Jégou et al. 2012]. SV is also very similar to the FV representation, where the biggest difference is that the SV representation does not incorporate the second moments [Chatfield et al. 2011, Sánchez et al. 2013]. HE vector hard-assigns each local descriptor to a visual word and extracts an additional binary signature w.r.t. assigned visual word. The binary signature is obtained by subtracting the local descriptor from a pre-defined anchor point in the descriptor space and then thresholding the difference vector. Although HE does not convey statistics as rich as those in FV, the binary signatures extracted by HE has advantages for large scale image search efficiency. The sparse coding-based Fisher kernel proposed by Raina et al. [2007] includes reconstruction residual vector in addition to the sparse coding coefficients. More precisely, it corresponds to the following encoding: φ(x) = " α ? x−Dα ? # (2.6) where α ? is the reconstruction coefficients found as in Eq. (2.4). Reconstruction residuals encoded by the second term are much smaller compared to the first moments encoded by the mixture of Gaussian Fisher vectors (D compared to DK) , and, therefore they are likely to provide much weaker statistics. Step IV: Aggregation In the final step of the feature extraction pipeline, the image descriptor is obtained by aggregating the local descriptor encodings. For example, a very simple18 CHAPTER 2. RELATED WORK but commonly used aggregation method is average-pooling, which simply averages all local encodings: Φ(X) = 1 |X| ∑ x∈X φ(x) (2.7) where X is the set of all local descriptors and Φ(X) is the image descriptor. Another widely used aggregation method is max-pooling: Φ(X) = max x∈X φ(x) (2.8) where max is the element-wise maximum operator. Whereas quantization-based encoding methods are commonly used with average-pooling, sparse coding based encoding methods have been observed to work particularly well using max-pooling [e.g. Boureau et al. 2010, Raina et al. 2007, Wang et al. 2010, Yang et al. 2009]. Interestingly, Boureau et al. [2010] report that max-pooling works works better than average-pooling using a MoG-like vocabulary with soft-assignment encoding. This is likely because the authors have not used discounting transformations in their average pooling BoW histograms. We will come back to the image descriptor transformation techniques in Section 2.2. Carreira et al. [2012] propose aggregation methods for encoding second-order statistics. More precisely, they propose second-order average-pooling, which is defined as Φ(X) = 1 |X| ∑ x∈X φ(x)φ(x) T (2.9) and second-order max-pooling, which is defined as Φ(X) = max x∈X φ(x)φ(x) T . (2.10) We can equivalently define these two aggregation methods as plain average-pooling and max-pooling over outer products of local descriptor encodings. In some aggregation methods, the local descriptor encoding step can be bypassed. The simplest possible example for this type of aggregation methods is to represent each image with a set of local descriptors, which needs to be used in conjunction with a set classification method. Alternatively, the local descriptors in an image can be summarized using a parametric distribution. In this case, a probability density function kernel (PDF kernel) is typically utilized in order to measure image-to-image similarities. For example, Farquhar et al. [2005] propose to represent each image with a single Gaussian and compare images using KL Diverge kernel or Bhattacharyya kernel over the Gaussian distributions. However, a single Gaussian distribution may not be descriptive enough. Although using mixture of Gaussian models can instead provide much richer representations, fitting a MoG model per image is costly and most PDF kernels are intractable for MoG models in2.1. IMAGE REPRESENTATIONS 19 general [e.g. Goldberger et al. 2003, Vasconcelos 2004]. One promising approach in this area is to fit per-image MoG models by adapting from a prior MoG model, which allows fast and accurate approximations to PDF kernels [Liu and Perronnin 2008]. 2.1.2 Incorporating spatial structure So far, we have ignored the spatial coordinates and scales of the patches in our discussion of image descriptors. Without utilizing spatial information, we can capture the spatial structure only within the patches by means of local descriptors. However, spatial relationships across the patches can be a rich source of information. Now, we will overview the methods for incorporating spatial information into the patch-based representations. In an image category, certain global or local spatial structures may exist. Whereas global spatial structure refers to existence of certain visual elements in approximately fixed positions, local spatial structures refers to distinctive visual elements in arbitrary positions. For example, outdoor scene categories typically have a characteristic global spatial layout [Oliva and Torralba 2001] (e.g. a typical street scene is to have buildings at the left and right sides of the image with a road in the middle). Similarly, images that contain a particular object category may have a distinctive global spatial structure if the object is strongly correlated with a scene (e.g. cars are frequently pictures in street scenes). On the other hand, many indoor scene categories have only local spatial structures, e.g. even though the kitchen images may not have a distinctive global spatial structure, tables and appliances typically appear in kitchen scenes. Spatial Pyramid Matching (SPM) formulated by Lazebnik et al. [2006] is a very popular method for incorporating global spatial layout into the image representation. In the original formulation, SPM creates a pyramid of regular grids with increasingly finer cells. More precisely, i-th level is a 2i×2 i regular grid. The image descriptor is obtained by concatenating descriptors aggregated within each spatial cell. The popularity of SPM is partly due to the fact that it can easily be integrated into virtually any patch-based image descriptor. However, SPM does not necessarily provide the optimal spatial binning and it may make the final image descriptor more susceptible to overfitting due to increased dimensionality. A simple approach for improving SPM is to relax its definition and manually choose a custom set of spatial cells instead of the standard pyramid, e.g. Chatfield et al. [2011] employs 1×1 + 3×1 + 2×2 partitioning. A number of papers have also investigated methods for tuning SPM in a data-driven manner. For example, Bosch et al. [2007] propose to discriminatively learn perSPM level weights. Sharma and Jurie [2011] propose to build category-specific SPMs by successively adding spatial cells during training. Elfiky et al. [2012] pro-20 CHAPTER 2. RELATED WORK pose to find and merge clusters of (visual word, spatial cell) pairs using supervised vocabulary-reduction methods in order to lower the final image descriptor dimensionality. Two similar approaches for efficiently incorporating global spatial layout into Fisher vectors are proposed by Krapac et al. [2011b] and Sánchez et al. [2012]. Apart from small differences across the formulations of the two works, the essential idea in both cases is to extend the FV image descriptor with the spatial coordinate statistics. As a result, the full-image FV essentially encodes the first and the second moments of the patch x, y coordinates per vocabulary center. Compared to SPM, this typically gives a competitive image categorization performance using a much lower-dimensional image descriptor. Utilizing local spatial structures is typically more challenging than utilizing global spatial structures. This is mainly due to the fact that local structures typically need to be discovered automatically where local structures may vary significantly in terms of their locations in images and they may not necessarily appear in all images. In the following paragraphs, we overview a number of approaches aiming to localize and utilize distinctive local structures for improving image categorization performance. One of the approaches for utilizing locally interesting structures is to extract a saliency map, which essentially gives the locations that likely overlap with objects. The obtained saliency map is typically used for weighting the contribution of the image regions to the final image descriptor or the classification score. For example, Sánchez et al. [2012] estimates a class-independent saliency map using the objectness detector [Alexe et al. 2012a]. In constrast, Khan et al. [2009b] estimate a class-specific saliency map by estimating posterior distribution over the classes at each local color descriptor. Sharma et al. [2012] discriminatively estimate a class-specific saliency map per image by treating the saliency as a latent variable. Alternatively, local structures may implicitly be utilized by incorporating cooccurrence statistics of the visual words into the image descriptor. For example, Agarwal and Triggs [2006] propose the hierarchical image descriptor using hyperfeatures, which is obtained by recursively computing BoW histograms in local neighborhoods and treating local BoW vectors as new local descriptors. As a result, mid-level visual words created at the higher hierarchy levels implicitly encode co-occurrence statistics of visual words in increasingly larger regions. In contrast, Savarese et al. [2006] extract mid-level visual words directly based on cooccurrence statistics of visual word pairs at several predefined local neighborhoods. Perronnin [2008] proposes to generate a mid-level visual word from each visual word according to its local context, which is captured via a BoW histogram over the visual words in proximity. Similarly, Yao and Fei-Fei [2010] use local groups of visual words and Fernando et al. [2012] use local frequencies of visual words to2.1. IMAGE REPRESENTATIONS 21 extract mid-level visual words. Simonyan et al. [2013] propose a two-layer Fisher vector descriptor using an architecture that resembles hyperfeatures. More precisely, the first-layer FVs are aggregated in local regions and post-processed using a discriminative dimension reduction technique, which is then used as the mid-level local descriptors for the second-layer FVs. Although aforementioned mid-level visual words and local descriptors capture local co-occurrences of visual words, they may not correspond to semantically meaningful local structures. A recently emerging alternative is to first explicitly localize objects [Russakovsky et al. 2012] or object-like characteristic regions (also referred to as concepts) [Juneja et al. 2013, Pandey and Lazebnik 2011, Quattoni and Torralba 2009, Singh et al. 2012]. The localized regions can either be used as a spatial aggregation cell [e.g. Russakovsky et al. 2012] or they can be used as the mid-level features to construct higher-level representations [e.g. Singh et al. 2012]. Weakly supervised object localization methods, which we overview in Section 2.4, may be utilized in combination with these methods particularly when the image categories correspond to object classes. 2.1.3 Other recent descriptors So far, we have focused on the image descriptors that are based on local descriptors. In the following paragraphs, we overview examples of other recent popular descriptors. We first overview rigid descriptors, which are primarily developed for encoding global layout of the images and objects. Then, we give examples of the high-level image descriptors, which are typically learned using auxiliary training examples. Finally, we briefly overview deep learning architectures. Rigid Descriptors We will now overview examples for the rigid descriptors. As explained in our overview, global spatial layout of an image can optionally be incorporated into patch-based image descriptors using additional techniques such as SPM. In contrast, global spatial layout is an integral part of the rigid descriptors. The GIST descriptor is proposed by Oliva and Torralba [2001] for capturing spatial characteristics of the scene categories. The main idea is to split an image using a regular grid and compute average response magnitudes of a number Gabor filters in each spatial cell. Resulting descriptor encodes the existence of edge-like local structures at various orientations and scales. Haar-like features are developed by Viola and Jones [2004] for object detection tasks. A Haar-like feature is parameterized by a set of positive and negative rectangular regions and defined as the difference of average intensity of the positive regions from that of the negative regions. These features are particularly fast22 CHAPTER 2. RELATED WORK to compute since the average intensity of an arbitrary rectangular region can be computed in constant time using an integral image [Viola and Jones 2004]. In a similar spirit, Local Binary Pattern (LBP) descriptor [Ahonen et al. 2006, Ojala et al. 2002] encodes the relative grayscale values of the pixels. An LBP descriptor is obtained by first extracting a binary vector at each pixel with respect to its neighboring pixels, where each dimension depicts whether the pixel is darker or lighter than its corresponding neighbor. The binary vectors are then interpreted as integers and histogrammed, which gives the LBP vector. The Histogram of Oriented Gradients (HOG) descriptor is developed by Dalal and Triggs [2005] for pedestrian localization. It is composed by histogramming pixel-wise gradient orientations within a number of spatial cells. Local groups of per-cell gradient histograms, which are called HOG blocks, are concatenated and normalized to achieve robustness against illumination variations and local clutter. Each HOG block is akin to a SIFT descriptor. Therefore, a HOG descriptor can be interpreted as the concatenation of SIFT descriptors extracted on a regular and overlapping grid. HOG is now one of the most popular descriptors for object localization. Another noticeable rigid descriptor is global self-similarity (GSS) [Deselaers et al. 2010]. Similar to the LSS local descriptors [Shechtman and Irani 2007], GSS encodes self-similarities in an image. More precisely, patches at predefined locations are considered as the reference patches and a similarity map over the image with respect to each reference patch is computed. Concatenation of all similarity maps constitute the GSS descriptor. High-level Image Descriptors So far, we have focused on image representations that essentially encode lowlevel image cues. Now, we will overview high-level image descriptors that aim to capture more semantic structures in the images.1 An illustrative example for this group of approaches is the object-bank image representation [Li et al. 2010]. The descriptor is extracted by applying a large number of category-level object detectors and storing the maximum detection score of each object detector within predefined spatial cells. The main idea is to describe an image in terms of the spatial distribution of the object classes. An important disadvantage of this approach is that object detectors need to be trained on an auxiliary dataset of training examples with bounding box annotations. Classemes descriptor proposed by Torresani et al. [2010] also aims to extract a 1We call this group of descriptors high-level just to emphasize their purpose rather than their technical qualities. We acknowledge that whether to categorize a particular image descriptor as a low-level, mid-level or high-level representation is largely a subjective matter.2.1. IMAGE REPRESENTATIONS 23 high-level descriptor similar to the object-bank descriptor. The main difference is that classeme descriptor utilizes a set of image classifiers trained on weakly-labeled images retrieved from a web image search engine, rather than fully-supervised object detectors. Bergamo and Torresani [2012] proposes meta-class descriptor, which can be seen as a variant of the classeme features. The essential idea is to train classeme-like classifiers over groups of object classes rather than individual classes, in order to extract more generic high-level image features. Attributes, broadly speaking, refer to semantic features that aim to provide a rich characterization of the objects and scenes [see Farhadi et al. 2009, Ferrari and Zisserman 2007, Lampert et al. 2009b]. Attributes are typically generic in the sense that an attribute can be used in the expression of a large number of classes. For example, “man-made” attribute is related to a huge number of object categories including buildings, dining tables, sculptures, etc. One way to utilize attributes is to extract high-level features to improve image categorization. More noticeably, attributes can also be used for the recognition of unseen categories simply based on textual descriptions, which is also known as zero-shot learning. Deep Learning Deep Learning refers to hierarchical machine learning approaches that aim to automatically learn powerful image representations. Although deep learning typically refers to contemporary multi-layer neural network based approaches, some other hierarchical representations like hyperfeatures [Agarwal and Triggs 2006] and deep Fisher networks [Simonyan et al. 2013], can partially be considered as deep learning techniques. A prominent example is Convolutional Neural Networks (CNN). A CNN typically consists of a series of layers that convolve the input image with filters, apply non-linear transformations on filter responses and spatially pool the resulting values. Although it has been decades since the introduction of CNNs, see e.g. Fukushima [1980], LeCun et al. [1990, 1998], only very recently CNNs have re-emerged among the state-of-the-art image categorization approaches. The improvements in CNN training techniques, computational resources and image datasets have helped improving the performance of CNN based architectures. For instance, Krizhevsky et al. [2012] present one of the first studies to show that a CNN-based approach can perform very well in large-scale image categorization tasks. The proposed architecture contains 60 million model parameters, are automatically learned on a dataset of 1.2 million training images for 1000 image categories. One of the main advantages of such deep learning architectures is their ability to effectively share a large number of model parameters across image categories. Since a deep learning model implicitly learns an image representation, the24 CHAPTER 2. RELATED WORK upper-layers of a pre-trained model can be used to extract high-level image descriptors, as shown by Girshick et al. [2013]. 2.2 Image classifiers In image categorization, the task is to automatically annotate images with prede- fined categories, where the exact details of the categorization task can vary considerably across the applications. An important consideration is image composition. For example, whereas we can assume that each image consists of a single object in some cases, an image may correspond to full scenes with a large number of objects per image as well. Another important consideration is the definition of the image categories, where examples include high-level object classes (e.g. “bus”, “car”, etc.), fine-grained classes (e.g. bird species) and scene labels (e.g. “beach”, “kitchen”, etc.). Therefore, an image categorization architecture should be developed according to the specification of the task. In this regard, most image categorization approaches can be separated into two steps: (a) feature extraction, (b) image classification. The objective of the feature extraction step is to obtain a rich image descriptor, for which we have overviewed a number of approaches in the previous section. Once the image descriptors are extracted, image labels are predicted typically using a set of classifiers. In this section, we overview the popular classification methods for image categorization tasks. First, we will provide an overview of the machine learning problem for image categorization tasks. Then, we summarize linear and kernel Support Vector Machine (SVM) classifiers [Vapnik 1995]. Finally, we discuss examples of kernel functions and feature transformations. 2.2.1 Overview A variety of machine learning approaches for image categorization tasks have been proposed in the literature. A number of factors should be taken into consideration while choosing a classification method. Three particularly important factors are the type of the image descriptor being used, the training annotations being provided and the overall learning objectives. In the following paragraphs, we overview the learning problem from these three aspects. The type of the image descriptors being used is the first aspect in choosing a classification method. We have already overviewed a number of descriptor types, including matrices (e.g. raw image), vectors (e.g. BoW), sets of vectors (e.g. set of local descriptors), probability density functions (e.g. Gaussian PDF). In addition, some image descriptors have a characteristic data distribution (i.e. a manifold),2.2. IMAGE CLASSIFIERS 25 which may need to be handled properly by the learning method. Such properties of the image descriptors affect the spectrum of the learning methods that can be used. For example, a PDF based representation is likely to perform much better using a PDF kernel [e.g. Goldberger et al. 2003, Vasconcelos 2004] rather than a general-purpose kernel. The manual annotations being provided is the second aspect. In the case of supervised training for image categorization, typically a list of target class labels for each training image is provided. In contrast, semi-supervised training refers to classifier training based on weakly annotated training examples. For example, each training image may have a noisy list of keywords [e.g. Guillaumin et al. 2010a] or a candidate set of labels where exactly only one of them is correct [Cour et al. 2011]. Similarly, the training set may consist of a noisy set of training images where some of them are irrelevant [e.g. Ikizler-Cinbis et al. 2009, Schroff et al. 2007]. Another interesting paradigm is interactive labeling, which aims to efficiently obtain the most informative annotations without exhaustively labeling all the examples. Although interactive labeling is mainly utilized for training purposes (also known as active learning) [See Settles 2009], it can also be utilized for incorporating human assistance into image categorization [e.g. Branson et al. 2010, Mensink et al. 2012]. The third and the final aspect that we will overview is the overall learning objectives. Although it is not possible to list all the options in this aspect, some illustrative examples are as follows: • A classifier can be learned in a generative manner or in a discriminative manner or using a combination of these two approaches. Generative methods typically aim to model the image distribution via fitting class-conditional density functions. In contrast, discriminative methods aim to directly learn a classification function for discriminating classes, without explicitly modeling within-class data distributions. Although discriminative methods usually result in a higher classification accuracy, generative methods can be more flexible for certain purposes, such as handling non-vector data or introducing prior knowledge. In order to combine the strengths of these two frameworks, hybrid methods have been proposed, see e.g. Bouchard and Triggs [2004], Jaakkola and Haussler [1999]. • In certain cases, it may be desirable to incorporate confidence scores into the classifier training process such that the high-scoring misclassifications are considered more costly than the low-scoring ones, which lead to a better ranking using classification scores [e.g. Joachims 2002, Krapac et al. 2011a, Yue et al. 2007]. • The relationships across the classes, if it exists, can be incorporated into the26 CHAPTER 2. RELATED WORK classification method. For example, classes can be known to be mutually exclusive (e.g. each image contains a single object) or there can be contextual co-occurrence relationships across the classes (e.g. sea and beach) [e.g. Mensink et al. 2012]. As illustrated by these three aspects, the topic of classification for image categorization tasks is very broad on its own. Therefore, in the remainder of this section, we overview only the classification methods that are directly relevant for this thesis. In particular, we restrict our discussion to the image categorization setup where an independent classifier is to utilized per class in order to predict whether the correspond class label is relevant for a given image or not. Therefore, we discuss only binary (i.e. two-class) classifiers. In addition, we focus only to SVM classifiers, which have been one of the most popular classifiers in the past decade. 2.2.2 Support Vector Machines We will now overview the SVM classifiers. First we will summarize the Linear SVM and Kernel SVM classifiers. Then, we will briefly look at the optimization problem. Linear SVM Any binary classifier that corresponds to a linear function (plus a constant term) over the descriptor vectors is called a linear classifier. Equivalently, we can interpret a linear classifier as a hyperplane that divides the descriptor space into two. Formally, let w be the weight vector of a given binary linear classifier and b be the bias term. Then, an image descriptor x is assigned to the positive class if w Tx + b ≥ 0 and otherwise, it is assigned to the negative class. In the image categorization context, positive class typically corresponds to a particular class label for the image. There are numerous algorithms for training binary linear classifiers. Some wellknown examples are perceptron algorithm [Rosenblatt 1957], SVM [Vapnik 1995], logistic regression [Bishop 2006], SVM-rank [Joachims 2002] and SVM-map [Yue et al. 2007]. Although all these algorithms aim to learn linear classifiers, they differ in terms of their learning algorithms. SVM have been one of the most popular classification methods for image categorization tasks in the past decade. The distinctive property of the SVM is that it aims to find the hyperplane with the maximum margin, where margin is defined as the smallest distance from the hyperplane to any training point. More precisely, SVM can be formulated as follows: Let x1,..., xN be the training examples and y1,..., yN be the corresponding class labels, where each yi ∈ {−1,+1}. We note2.2. IMAGE CLASSIFIERS 27 that the distance from a given point x to the hyperplane (w,b) is given by w Tx+b where w is a unit vector. Then, assuming that training examples are linearly separable, unit-vector w leading to the maximum margin is given by maxw,b mini(w Txi +b)yi s.t. kwk = 1 (2.11) Although this is a difficult optimization problem, we can transform into the following convex, quadratic optimization problem [Bishop 2006]: minw,b w Tw s.t. (w Txi +b)yi ≥ 1 ∀i (2.12) Here, the points closest to the decision hyperplane are called the support vectors. The main limitation of this formulation is that there is no feasible solution if the training data is not linearly separable. To alleviate this problem, typically a set of slack variables ξ1,...,ξN is introduced, which relaxes the formulation such that some of the training examples can violate the margin: minw,b w Tw+C∑i ξi s.t. (w Txi +b)yi ≥ 1−ξi ∀i ξi ≥ 0 ∀i (2.13) where C is the cost parameter, which defines the trade-off between having a large margin and reducing the number of margin violating training examples. This problem can also be equivalently written as an unconstrained convex problem: min w,b w Tw+C∑ i L(w T xi +b, yi) (2.14) where L(s, y) = max(1−sy,0) is known as the hinge loss function. Kernel SVM So far we have looked at SVM only for training linear classifiers. Kernel SVM, on the other hand, allows learning much more complex decision functions via utilizing a user-defined kernel function, which should essentially measure the similarity of a given descriptor pair. In order to derive the Kernel SVM formulation, we can first write the Lagrangian dual [Bishop 2006] of Eq. (2.13), which is given by maxa1:N ∑i ai − 1 2 ∑i, j aiajyiy jk(xi ,xj) s.t. 0 ≤ ai ≤ C ∀i ∑i aiyi = 0 ∀i (2.15) Déconvolution adaptative pour le contrˆole non destructif par ultrasons Ewen Carcreff To cite this version: Ewen Carcreff. D´econvolution adaptative pour le contrˆole non destructif par ultrasons. Acoustics. Universit´e du Maine, 2014. French. HAL Id: tel-01098798 https://hal.archives-ouvertes.fr/tel-01098798 Submitted on 29 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 Ewen CARCREFF Mémoire présenté en vue de l’obtention du grade de Docteur de l’Université du Maine sous le label de l’Université de Nantes Angers Le Mans École doctorale : Sciences pour l’Ingénieur, Géosciences et Architecture Discipline : Acoustique, section CNU 60, 61 Unité de recherche : Institut de Recherche en Communications et Cybernétique de Nantes (IRCCyN) Laboratoire d’Acoustique de l’Université du Maine (LAUM) Soutenue le 28 novembre 2014 Déconvolution adaptative pour le contrôle non destructif par ultrasons JURY Président : M. Cédric RICHARD, Professeur des universités, Université de Nice Sophia Antipolis Rapporteurs : M. Laurent DAUDET, Professeur des universités, Université Paris Diderot M. Thomas RODET, Professeur des universités, École Normale Supérieure de Cachan Examinateur : M. Pierre CALMON, Directeur de recherche, CEA, Saclay Invité : M. Vincent BALTAZART, Chargé de recherche, IFSTTAR, Nantes Directeur de thèse : M. Laurent SIMON, Professeur des universités, Université du Maine Co-directeur de thèse : M. Jérôme IDIER, Directeur de recherche CNRS, IRCCyN Encadrant : M. Sébastien BOURGUIGNON, Maître de Conférences, École Centrale de NantesRemerciements En préambule, je remercie la région Pays de la Loire, et le pôle de compétence ECND-PdL, d’avoir financé cette thèse. Je tiens à remercier les membres du jury qui ont accepté de juger mon travail de thèse. Merci à Cédric Richard, professeur à l’Université de Nice Sophia Antipolis, d’avoir présidé ce jury. Merci à Pierre Calmon, directeur de recherche au CEA, et à Vincent Baltazart, chargé de recherche à l’IFSTTAR. Je remercie vivement Laurent Daudet, professeur à l’Université Paris Diderot, et Thomas Rodet, professeur à l’ENS Cachan, d’avoir accepté d’être les rapporteurs de mon manuscrit. Leurs remarques ont permis d’améliorer la qualité de celui-ci. Je veux exprimer ma reconnaissance à mes encadrants de thèse, Sébastien Bourguignon, Jérôme Idier et Laurent Simon. Ils ont su me guider en me laissant beaucoup d’autonomie, tout en me faisant toujours confiance. C’est un vrai luxe de travailler dans ces conditions. Je remercie Laurent pour son optimisme. Je remercie Jérôme pour sa hauteur de vue sur le sujet de thèse. Un immense merci à Sébastien pour sa disponibilité et son implication constante. Travailler à ses côtés a vraiment été très enrichissant, tant du point de vue professionnel que relationnel. Je tiens à souligner l’aide précieuse fournie par Aroune Duclos, maître de conférences à l’Université du Maine, pour réaliser les expérimentations au laboratoire d’acoustique de l’Université du Maine tout au long de la thèse. Mes remerciements vont également aux membres dynamiques de l’équipe Analyse et décision en traitement du signal et de l’image de l’IRCCyN, les permanents, Marie-Françoise Lucas, Saïd Moussaoui, Éric Le Carpentier et Mathieu Lagrange, ainsi que les doctorants (cités plus loin). Je remercie de surcroît les membres de l’IRCCyN que j’ai croisés pendant ces trois années. Je remercie particulièrement Emily Thureau pour son aide constante. Merci également au service administratif, Patricia Brière, Sylvie Julienne, Virginie Dupont, Michelle-Anne Audrain et Armelle Radigois. Je n’oublie pas le service informatique, Denis Creusot, Richard Randriatoamanana et Robert Legal. Je remercie enfin Michel Malabre, directeur de l’IRCCyN, de m’avoir accueilli dans le laboratoire où j’ai travaillé dans d’excellentes conditions. Je voudrais également remercier les membres du LAUM, qui m’ont toujours réservé le meilleur accueil lors de mes nombreuses visites. Notamment, je remercie Aroune Duclos, Catherine Potel, Claude Dépollier, Simon Félix, Pierrick Lotton, Jean-Hugh Thomas, Hervé Mézière. Je remercie également Joël Gilbert, directeur du LAUM, pour son soutien. Merci également à Anne-Marie Brulé pour son aide précieuse. Je remercie aussi Nacera Bedrici qui nous a accueillis à l’ESTACA. Je remercie Alain Le Duff et Guy Plantier, enseignant-chercheurs à l’ESEO pour leur bonne humeur et leur enthousiasme au sujet de ma thèse. Merci aussi à Roberto Longo pour 3son dynamisme. Avec Sébastien, nous avons accueilli Gwenola Rolland et Yan Li qui ont réalisé un stage au sein de l’équipe ADTSI. Je les remercie d’avoir travaillé sur ces projets en lieu avec ma thèse. J’ai passé deux jours au CEA pour réaliser des simulations avec le logiciel CIVA. Je veux remercier Raphaële Raillon et Pierre Calmon pour leur accueil. J’adresse mes vifs remerciements aux doctorants et post-doctorants qui m’ont accompagné pendant ces trois années : Maxime, Vincent, Corentin, Grégoire, Philip, Emmanuel, Julien, Joan, Ablamvi, Hendry, Robin, Maria, Oscar, Aleksandra, Jonathan, Inès, Denis, Xavier, Céline, ... Mes remerciements vont évidemment à mes amis qui me soutiennent depuis longtemps : Olivier, Gaëlle, Edwin, Quentin, Thomas, Hadrien, Guillaume, Nicolas, François, Charlotte, Jean-François, Aurélien, Enric, Mathieu, et bien d’autres. Enfin, je ne serai jamais assez reconnaissant envers ma famille qui est toujours là pour moi. Je remercie ma belle-famille pour leur bienveillance permanente. Je remercie Gwenal et Lena de m’avoir supporté toutes ces années. Merci à mes parents pour leur soutien inconditionnel. Je clos ces remerciements par le soutien qui me donne le plus de force, celui de ma femme Gaëlle et de mon fils Maden, qui est né pendant cette thèse. 4Table des matières Introduction générale 9 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1 Positionnement du problème 13 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1 Le contrôle non destructif industriel . . . . . . . . . . . . . . . . . . . . . 14 1.1.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.2 Le contrôle non destructif par ultrasons . . . . . . . . . . . . . . . 14 1.1.3 Transducteurs et mesures . . . . . . . . . . . . . . . . . . . . . . . 15 1.2 Détection des discontinuités et des défauts . . . . . . . . . . . . . . . . . . 17 1.2.1 Changements d’impédance acoustique . . . . . . . . . . . . . . . . 17 1.2.2 La séquence de réflectivité . . . . . . . . . . . . . . . . . . . . . . 19 1.3 Modèle direct et problème inverse . . . . . . . . . . . . . . . . . . . . . . 20 1.3.1 Modèle direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.2 Difficultés spécifiques liées au problème inverse . . . . . . . . . . 20 1.3.3 Caractère mal posé . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4 Revue bibliographique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.5 Axes de travail effectués pendant la thèse . . . . . . . . . . . . . . . . . . 24 2 Le modèle direct 25 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1 Modèle de signaux continus pour une cible ponctuelle . . . . . . . . . . . . 26 2.1.1 Modèle fréquentiel . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.2 Écriture en fonction de la distance de propagation . . . . . . . . . . 27 2.1.3 L’atténuation fréquentielle . . . . . . . . . . . . . . . . . . . . . . 28 2.1.4 La dispersion et les théories causales . . . . . . . . . . . . . . . . . 33 2.2 Modèle discret linéaire pour l’inversion . . . . . . . . . . . . . . . . . . . 38 2.2.1 Modèle de signaux à temps continu pour une distribution de cibles . 38 2.2.2 Modèle de signaux à temps discret . . . . . . . . . . . . . . . . . . 39 2.2.3 Différents cas pour le modèle linéaire discret . . . . . . . . . . . . 40 2.2.4 Calcul numérique des réponses impulsionnelles d’atténuation . . . 43 2.2.5 Modèle d’atténuation d’Olofsson . . . . . . . . . . . . . . . . . . 45 5TABLE DES MATIÈRES 2.3 Exploitation des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.3.1 Mesure en mode pulse-echo avec du polycarbonate . . . . . . . . . 48 2.3.2 Mesure en transmission dans l’huile de ricin . . . . . . . . . . . . . 53 2.3.3 Mesure aérienne en transmission dans un matériau poreux . . . . . 56 2.3.4 Exploitation du modèle pour l’Évaluation Non Destructive . . . . . 58 2.3.5 Problème de diffraction des cibles : application aux trous à fond plat 61 3 Le problème inverse 65 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.1 Approches paramétriques . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.1.1 Modèles de formes d’ondes . . . . . . . . . . . . . . . . . . . . . 66 3.1.2 Méthodes locales d’optimisation . . . . . . . . . . . . . . . . . . . 67 3.1.3 Quelques méthodes d’optimisation non-linéaire . . . . . . . . . . . 69 3.1.4 Méthodes de type Espérance-Maximisation . . . . . . . . . . . . . 71 3.2 Minimisation d’un critère pénalisé . . . . . . . . . . . . . . . . . . . . . . 73 3.2.1 Description du modèle direct . . . . . . . . . . . . . . . . . . . . . 73 3.2.2 Inverse généralisée . . . . . . . . . . . . . . . . . . . . . . . . . . 74 3.2.3 Régularisation par minimisation d’un critère pénalisé . . . . . . . . 74 3.2.4 Réglage du paramètre de régularisation . . . . . . . . . . . . . . . 79 3.3 Régularisation par la pseudo-norme `0 . . . . . . . . . . . . . . . . . . . . 80 3.3.1 Formulation du problème d’optimisation . . . . . . . . . . . . . . 80 3.3.2 Méthodes d’optimisation par une approche gloutonne . . . . . . . . 81 3.3.3 L’agorithme Single Best Replacement . . . . . . . . . . . . . . . . 84 3.3.4 Comparaison des algorithmes gloutons et SBR . . . . . . . . . . . 86 3.4 Des algorithmes plus efficaces d’optimisation `0 . . . . . . . . . . . . . . . 88 3.4.1 Mouvements plus complexes . . . . . . . . . . . . . . . . . . . . . 88 3.4.2 Sélection dans une fenêtre . . . . . . . . . . . . . . . . . . . . . . 89 3.4.3 Sélection basée sur un calcul d’auto-corrélation multidimensionnelle 92 4 Déconvolution parcimonieuse sur-échantillonnée 101 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.1 Modèle sur-échantillonné et MISO . . . . . . . . . . . . . . . . . . . . . . 102 4.1.1 Convolution discrète sur-échantillonnée . . . . . . . . . . . . . . . 102 4.1.2 Système MISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.2 Facteur de sur-échantillonnage . . . . . . . . . . . . . . . . . . . . . . . . 104 4.3 Algorithmes de déconvolution . . . . . . . . . . . . . . . . . . . . . . . . 105 4.3.1 Calcul rapide de la convolution discrète . . . . . . . . . . . . . . . 106 4.3.2 Détails de mise en œuvre des algorithmes . . . . . . . . . . . . . . 107 4.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.4.1 Outils de mesure de l’erreur d’estimation . . . . . . . . . . . . . . 108 4.4.2 Résultats issus de données simulées . . . . . . . . . . . . . . . . . 110 4.4.3 Simulations de Monte-Carlo . . . . . . . . . . . . . . . . . . . . . 112 4.4.4 Résultats expérimentaux . . . . . . . . . . . . . . . . . . . . . . . 113 6TABLE DES MATIÈRES 5 Application au CND 117 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.1 Estimation de la forme d’onde . . . . . . . . . . . . . . . . . . . . . . . . 118 5.1.1 Mesure d’un écho isolé . . . . . . . . . . . . . . . . . . . . . . . . 118 5.1.2 Estimation par connaissance de la séquence de réflectivité . . . . . 118 5.1.3 Moyennage dans le domaine homomorphique . . . . . . . . . . . . 119 5.1.4 Construction d’un dictionnaire ou apprentissage . . . . . . . . . . . 120 5.2 Plaque de matériau homogène . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2.2 Calcul d’incertitude . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.2.3 Estimation du temps de vol moyen par moindres carrés . . . . . . . 123 5.2.4 END d’une plaque épaisse . . . . . . . . . . . . . . . . . . . . . . 123 5.2.5 CND d’une plaque fine . . . . . . . . . . . . . . . . . . . . . . . . 126 5.3 Matériaux atténuants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.4 Plaques avec trous à fond plat . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.4.1 Cas d’un Ascan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.4.2 Cas d’un Bscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Conclusion et perspectives 133 Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 A Relations de causalité 139 A.1 Relations de causalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 A.2 Relations de causalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 A.2.1 Calcul de la phase dispersive pour une atténuation linéaire . . . . . 141 B Modèle de réponse impulsionnelle instrumentale 143 B.1 Modèle d’écho gaussien . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.2 Facteur de bande passante . . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 B.2.2 Application à la forme d’onde gaussienne . . . . . . . . . . . . . . 144 C Détails des calculs algorithmiques 147 C.1 Critère d’ajout pour OLS et SBR . . . . . . . . . . . . . . . . . . . . . . . 147 C.2 Critère de retrait pour SBR . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Bibliographie 150 7Introduction générale Contexte Ce travail de thèse est le fruit d’une collaboration entre les laboratoires IRCCyN (Institut de Recherche en Communications et Cybernétique de Nantes, UMR CNRS 6597) et LAUM (Laboratoire d’Acoustique de l’Université du Maine, UMR CNRS 6613). Il a été réalisé au sein de l’équipe ADTSI (Analyse et Décision en Traitement du Signal et de l’Image) de l’IRCCyN. Le financement a été assuré par la région Pays de la Loire par le biais du pôle de compétence ECND-PdL (Evaluation et Contrôle Non Destructifs en Pays de la Loire). Cette thèse traite de méthodes inverses dans un contexte de contrôle non destructif par ultrasons, où le but est la détection de discontinuités dans les objets inspectés. L’application directe de ces méthodes permet une meilleure interprétation des signaux et une aide au diagnostic. Problématique Le contrôle non destructif (CND) est une étape importante du processus industriel. Il permet de contrôler l’intégrité des composants sans les endommager, pendant ou à la fin de leur fabrication, et en situation d’utilisation. Différents phénomènes physiques permettent ces contrôles de par leur caractère pénétrant dans les objets (ondes électromagnétiques, ondes acoustiques, champ magnétique, etc.), menant à différents modes de contrôle1 . Nous nous intéressons dans ce travail au CND par ultrasons, modalité qui consiste à émettre des ondes acoustiques dans le matériau à inspecter [Krautkramer et Krautkramer 1990]. Les ondes se propageant dans le milieu, et récupérées par le capteur ultrasonore, permettent dans la mesure du possible de détecter et d’identifier les défauts contenus dans la pièce. Le même procédé peut être appliqué pour évaluer les matériaux, c’est-à-dire pour estimer des paramètres physiques propres, tels que la vitesse des ondes ou le coefficient d’atténuation. Le but de l’utilisateur est de visualiser les échos et d’en déduire une information spatiale sur l’objet inspecté. Nous nous intéressons ici aux discontinuités, qui présentent des transitions franches dans l’objet (surfaces, arêtes, défauts, etc.). L’analyse du signal peut cependant se révéler difficile à l’œil nu pour plusieurs raisons : bruit, atténuation, diffraction, superposition d’échos, etc. Des techniques de traitement du signal sont alors employées pour améliorer la résolution des signaux [Zhang et Harvey 2013]. Nous nous intéressons plus pré- cisément aux approches qui visent à résoudre le problème inverse d’estimation des distances de propagation correspondant à chaque écho. 1Voir le site de la COnfédération Française pour les Essais Non Destructifs (COFREND) : http://www.cofrend.com. 9INTRODUCTION GÉNÉRALE Nous nous plaçons dans le cadre des méthodes de déconvolution parcimonieuse qui ont montré de bons résultats dans un contexte de CND [Zala 1992]. Ces méthodes partent du principe que les échos sont des répliques d’un écho de référence. Le modèle sous-jacent est discret et linéaire, et donne de bons résultats lorsque la forme des échos varie très peu. Des algorithmes efficaces ont été mis en œuvre, notamment en utilisant une approche pénalisée pour traduire le caractère parcimonieux de l’inconnue. La pénalisation `1 a été beaucoup utilisée dans le domaine géophysique [Taylor et al. 1979], puis acoustique [O’Brien et al. 1994]. Elle trouve ses limites dans notre application car ce type de pénalisation fournit des solutions avec de nombreux pics de faibles amplitudes. La pénalisation `0 qui compte les composantes non-nulles semble plus adaptée à notre problème mais son caractère discret formule des problèmes d’optimisation plus complexes. Des travaux récents ont ainsi abordé le problème en pénalisation `0 sous la forme d’algorithmes itératifs sous optimaux (algorithme SBR [Soussen et al. 2011]). Nous nous plaçons dans la continuité de ces travaux. L’exploration combinatoire limitée peut se révéler insatisfaisante et requiert le développement de méthodes plus abouties et adaptées aux formes d’ondes ultrasonores. Dans de nombreux matériaux, la forme des échos reçus varie à cause de l’atténuation fré- quentielle, de la dispersion et des signatures des interfaces et des défauts. Certaines méthodes permettent de prendre en compte ces déformations, notamment les méthodes d’estimation de modèles paramétriques [Demirli et Saniie 2001a]. En revanche, de par son caractère invariant, le modèle de convolution n’est pas adapté à ces types de distorsion. Un modèle empirique de déformation des échos a été proposé dans [Olofsson et Stepinski 2001], mais ne prend pas en considération la réalité physique. Des modèles existent cependant dans la littérature pour traduire l’atténuation, notamment le modèle en loi de puissance fréquentielle [Ophir et Jaeger 1982]. La dispersion peut également être définie par certains modèles physiques [He 1999]. L’insertion de tels modèles physiques dans le modèle des données ultrasonores est une autre motivation de cette thèse. Contributions Les contributions de cette thèse portent sur deux aspects : la modélisation des signaux et la résolution du problème inverse. Les publications scientifiques issues de ces contributions sont indexées par des lettres majuscules et sont listées à la fin de ce chapitre. Nous développons tout d’abord un modèle de signaux ultrasonores qui prend en compte l’atténuation et la dispersion. La nouveauté de ce modèle est de produire un système linéaire non invariant pour les signaux discrets, tout en prenant en compte l’atténuation et la dispersion [A, E, F, H, I]. Ce modèle peut être vu comme une extension du modèle convolutif classique, mais où la réponse impulsionnelle varie en fonction de la distance de propagation. Nous montrons également qu’il est possible de discrétiser le modèle à une résolution plus élevée que les données, qui permet d’aboutir à un modèle sur-échantillonné (dit à superrésolution) [C, D, G]. Les contributions méthodologiques concernent la résolution du problème inverse par optimisation d’un critère des moindres carrés pénalisé par une norme `0. Nous proposons tout d’abord de revisiter des algorithmes de déconvolution parcimonieuse pour le modèle sur- échantillonné [C, D], qui est décrit comme un cas particulier de système à entrées multiples et sortie unique (MISO). Dans un second temps, nous développons un algorithme pour l’optimisation `0 grâce à une exploration combinatoire plus complexe adaptée aux formes d’ondes 10INTRODUCTION GÉNÉRALE oscillantes [B]. Cette thèse comporte également un volet expérimental qui a permis de valider les modèles et les méthodes développés sur des cas pratiques de contrôle non destructif par ultrasons. Les différentes données ont été acquises au Laboratoire d’Acoustique de l’Université du Maine. Le traitement de ces données expérimentales apparaît dans les publications [A, C, E, F, H, I]. Organisation du document Ce mémoire est composé de cinq chapitres dont nous précisons succinctement le contenu. • Le chapitre 1 a pour but de détailler la problématique et les objectifs de notre étude. Nous présentons ce qu’est le contrôle non destructif ultrasonore dans un contexte industriel. Nous abordons ensuite l’objectif de ce travail qui est la détection de discontinuités dans les matériaux. Dans cette optique, nous exposons les verrous du problème ainsi qu’une revue bibliographique des modèles et des méthodes utilisés. • Le chapitre 2 présente la construction du modèle direct de propagation ultrasonore développé. Nous proposons un modèle linéaire pour les signaux à temps discret qui prend en compte l’atténuation et la dispersion de l’onde propagée. Ce modèle est comparé à d’autres modèles de la littérature grâce à des signaux réels obtenus à partir de matériaux atténuants (polycarbonate, huile de ricin, mousse poreuse). • Le chapitre 3 est consacré au problème inverse et aux développements méthodologiques. Nous présentons tout d’abord les différentes approches pour résoudre le problème inverse et nous nous focalisons sur l’approche pénalisée par une pseudo-norme `0. Dans un premier temps, nous présentons une approche de mouvements multiples dans une fenêtre. Ensuite, nous proposons un algorithme inspiré de SBR pour l’optimisation avec une pénalisation `0 et présentant une exploration combinatoire plus complexe adaptée aux formes d’ondes oscillantes. Appliqué à des données ultrasonores, cet algorithme est plus performant pour un accroissement restreint du coût de calcul. • Le chapitre 4 présente la déconvolution parcimonieuse lorsque le modèle de convolution est sur-échantillonné, ce qui permet de reconstruire un train d’impulsions à une résolution temporelle plus fine que celle des données. Nous montrons que ce modèle a un cadre plus général de système à entrées multiples et sortie unique. Des algorithmes classiques de déconvolution parcimonieuse sont alors adaptés pour ce type de système. • Dans le chapitre 5, des exemples concrets d’application de la déconvolution parcimonieuse au contrôle non destructif sont présentés. Nous exposons en particulier des cas de calcul d’épaisseur de plaques fines et de détection de défauts dans l’aluminium, le plexiglas et le polycarbonate. 11INTRODUCTION GÉNÉRALE Publications • Article de revue internationale publié : [A] E. Carcreff, S. Bourguignon, J. Idier et L. Simon. A linear model approach for ultrasonic inverse problems with attenuation and dispersion. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, Vol. 61(7), Pages 1191-1203, Juillet 2014. • Article de revue internationale en cours de rédaction : [B] E. Carcreff, S. Bourguignon, J. Idier et L. Simon. Sparse deconvolution of signals containing oscillating waveforms. En cours de rédaction, 2014. • Articles de conférences avec actes et comité de lecture : [C] E. Carcreff, S. Bourguignon, J. Idier et L. Simon. Algorithmes de déconvolution impulsionnelle à résolution augmentée. Actes du 24ème colloque GRETSI, Brest, France, Septembre 2013. [D] E. Carcreff, S. Bourguignon, J. Idier et L. Simon. Resolution enhancement of ultrasonic signals by up-sampled sparse deconvolution, IEEE International Conference on Acoustics Speech and Signal Processing, pages 6511-6515, Vancouver, Canada, Mai 2013. • Articles de conférences avec actes : [E] E. Carcreff, S. Bourguignon, J. Idier et L. Simon. Contrôle non destructif des matériaux atténuants et dispersifs par déconvolution impulsionnelle. Actes du 12ème Congrès Français d’Acoustique, Poitiers, France, Avril 2014. [F] E. Carcreff, S. Bourguignon, J. Idier, L. Simon et Aroune Duclos. Including frequency-dependent attenuation for the deconvolution of ultrasonic signals, 19th International Congress on Acoustics, Montréal, Canada, Juin 2013. [G] E. Carcreff, S. Bourguignon, J. Idier et L. Simon. High-resolution deconvolution applied to non destructive testing, Acoustics 2012, Nantes, France, Avril 2012. • Articles de conférences sans actes : [H] E. Carcreff, A. Duclos, J.-P. Groby et S. Bourguignon. A dispersive attenuation model for ultrasonic wave propagation in porous materials. Symposium on the Acoustics of Poro-Elastic Materials, Stockholm, Suède, Décembre 2014. [I] E. Carcreff, S. Bourguignon, J. Idier et L. Simon. Déconvolution pour le contrôle par ultrasons des matériaux atténuants et dispersifs. Journées COFREND, Bordeaux, France, Mai 2014. 12Chapitre 1 Positionnement du problème : la détection de discontinuités en contrôle non destructif Sommaire Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1 Le contrôle non destructif industriel . . . . . . . . . . . . . . . . . . . 14 1.1.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.2 Le contrôle non destructif par ultrasons . . . . . . . . . . . . . . 14 1.1.3 Transducteurs et mesures . . . . . . . . . . . . . . . . . . . . . . 15 1.2 Détection des discontinuités et des défauts . . . . . . . . . . . . . . . . 17 1.2.1 Changements d’impédance acoustique . . . . . . . . . . . . . . . 17 1.2.2 La séquence de réflectivité . . . . . . . . . . . . . . . . . . . . . 19 1.3 Modèle direct et problème inverse . . . . . . . . . . . . . . . . . . . . 20 1.3.1 Modèle direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.2 Difficultés spécifiques liées au problème inverse . . . . . . . . . 20 1.3.3 Caractère mal posé . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.4 Revue bibliographique . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.5 Axes de travail effectués pendant la thèse . . . . . . . . . . . . . . . . 24 Introduction Le but de ce chapitre est de présenter les enjeux et objectifs de la thèse. La section 1.1 décrit tout d’abord les objectifs et les modalités du contrôle non destructif industriel. Il est question ici de présenter les généralités d’un contrôle par ultrasons : transducteurs, mesures, etc. Nous décrivons ensuite dans la section 1.2 l’objectif de notre travail, qui est la détection de discontinuités. Ce point est illustré par un exemple simple de contrôle de plaque homogène immergée. La formulation du problème inverse est ensuite décrite dans la section 1.3. Nous 13CHAPITRE 1 : Positionnement du problème détaillons notamment les difficultés de sa résolution. La section 1.4 établit une revue bibliographique des modèles et des méthodes inverses utilisés. Cela permet finalement de décrire les axes de travail abordés pendant la thèse dans la section 1.5. 1.1 Le contrôle non destructif industriel 1.1.1 Généralités Le Contrôle Non Destructif (CND) a pour objectif de détecter d’éventuels défauts à l’intérieur ou à la surface de pièces industrielles sans les endommager. La différence est faite avec l’Évaluation Non Destructive (END) où le but est de mesurer des grandeurs physiques propres aux matériaux (masse volumique, vitesse des ondes acoustiques, constante diélectrique, etc.). Différents phénomènes physiques permettent cette auscultation grâce à leurs propriétés pénétrantes dans le matériau1 : résurgence d’un liquide ou d’un gaz pénétrant (ressuage), ondes ultrasonores, courants de Foucault, ondes infrarouges (thermographie), ondes électromagnétiques X ou gamma (radiographie), champ magnétique (magnétoscopie), etc. La plupart de ces phénomènes sont employés dans le domaine de l’imagerie médicale (échographie, radiologie, imagerie par résonance magnétique, etc.), qui peut aussi être considérée comme un domaine d’application du CND pour les tissus mous et les os. Nous associons également au CND les techniques d’auscultation du sol et du génie civil qui utilisent les mêmes phénomènes, mais également les ondes sismiques (sismologie) et les micro-ondes [Jonscher 1983] (radar à pénétration de sol). Le CND dans le domaine industriel intervient pendant deux phases de la vie des composants. Premièrement, il sert à vérifier que les pièces produites ne contiennent pas d’anomalies ou de défauts avant leur utilisation. Il permet ainsi d’éviter un dysfonctionnement lié à la mauvaise fabrication d’une pièce. Ce contrôle peut être appliqué au contrôle de tubes, barres, plaques, etc. mais également de pièces manufacturées comme des assemblages avec soudures ou avec des matériaux composites. Un exemple de contrôle de tube de grosse dimension est présenté sur la figure 1.1. La deuxième phase d’utilisation du CND intervient pendant l’usage des pièces. Il sert alors à contrôler leur bon fonctionnement in situ, car celles-ci peuvent subir de fortes sollicitations mécaniques, chimiques, radioactives, menant à l’apparition de craquements, fissures, etc. Les domaines d’application sont variés : transports terrestres et aériens, centrales électriques, etc. 1.1.2 Le contrôle non destructif par ultrasons Le CND par ultrasons est effectué en émettant des ondes acoustiques à l’intérieur ou à la surface des pièces à inspecter. La réception de ces ondes après propagation dans le matériau permet d’obtenir des informations sur le milieu de propagation [Krautkramer et Krautkramer 1990]. Les ondes acoustiques créent des modifications locales de la pression et de la vitesse des particules. Par exemple, l’équation d’une onde plane se propageant dans la direction x s’écrit [Bruneau 1998] ❇ 2p♣x, tq ❇x 2 ✁ 1 c 2 ❇ 2p♣x, tq ❇t 2 ✏ 0, (1.1) 1Voir le site de la COnfédération Française pour les Essais Non Destructifs (COFREND) : http://www.cofrend.com. 141.1 Le contrôle non destructif industriel FIGURE 1.1 – Contrôle d’un tube de grand diamètre par ultrasons. La sonde ultrasonore est placée directement en contact avec la pièce par l’opérateur pour l’inspecter (source : IRC Advanced NDT Services, www.indiamart.com). où p♣x, tq est la pression en x à un instant t, et c est la vitesse des ondes. La solution de ce type d’équation est de ce fait une fonction de l’espace et du temps. Les ultrasons sont non invasifs, contrairement aux rayons X notamment. Cela présente un avantage évident dans le domaine médical, mais également dans le domaine industriel lorsque l’environnement est soumis à de fortes contraintes (radioactives par exemple). Un autre avantage du contrôle par ultrasons est leur facilité d’utilisation, qui permet par exemple de créer des systèmes de faible encombrement et portatifs que les opérateurs peuvent utiliser sur le terrain. Les systèmes utilisant des rayons X ou des champs magnétiques nécessitant une puissance électrique conséquente sont plus difficilement portables. Un dernier atout est le faible coût des systèmes et des sondes de mesure par ultrasons. D’un point de vue modé- lisation, l’hypothèse de linéarité [Bruneau 1998] de la propagation ultrasonore rend possible le développement de logiciels de simulation [Lingvall 2004a, Mahaut et al. 2009, McGough 2014]. Ce travail de thèse concerne le CND par ultrasons, même si les modèles et techniques d’inversion proposés pourraient être étendus à d’autres modalités de CND. 1.1.3 Transducteurs et mesures Les transducteurs utilisés en CND et END ultrasonores sont des convertisseurs électro-acoustiques : ils convertissent un signal électrique en mouvement de la membrane du transducteur (à la manière d’un haut-parleur). Le mouvement de cette membrane provoque la mise en mouvement des particules autour d’elle et crée ainsi une onde acoustique. Les transducteurs possèdent l’effet réciproque, c’est à dire qu’un mouvement de la membrane crée un signal électrique. Un transducteur peut donc être à la fois émetteur et récepteur. Typiquement, l’effet piézoélectrique permet de réaliser ces transducteurs [Krautkramer et Krautkramer 1990, chap. 7]. La piézoélectricité est la propriété que possèdent certains corps de se polariser électriquement sous l’action d’une contrainte mécanique, et réciproquement de se déformer lorsqu’on leur applique un champ électrique. Des transducteurs mono-élément sont représentés sur la figure 1.2a. Il existe également des capteurs multi-éléments (voir figure 1.2b). Ceux-ci permettent le contrôle spécifique de chaque élément et ainsi la génération de champs acoustiques complexes (focalisation, balayage, ondes planes, etc.). Une acquisition avec une sonde mono-élément permet d’obtenir un signal numérique unidimensionnel que l’on appelle Ascan. Un exemple de A-scan est présenté sur la figure 1.6. Il est également possible d’obtenir 15CHAPITRE 1 : Positionnement du problème (a) (b) FIGURE 1.2 – Types de sondes ultrasonores. (a) : sondes mono-palpeur, (b) : sonde multi- éléments (source : Olympus, www.olympus-ims.com). des images ou B-scans en déplaçant le transducteur mono-élément ou en utilisant un transducteur multi-éléments. Pour réaliser des contrôles par ultrasons, un émetteur et un récepteur ultrasonores sont né- cessaires. Deux cas de figure sont alors possibles. Le premier cas utilise un seul transducteur qui va servir d’émetteur et de récepteur. On parle alors de mesure en réflexion ou pulseecho en anglais. Ce type de mesure est utilisé pour sa simplicité, mais également lorsque la face arrière de la pièce n’est pas accessible [Krautkramer et Krautkramer 1990]. On peut par exemple citer le cas de contrôle de tube, à l’intérieur duquel on ne peut pas accéder. La deuxième possibilité consiste à utiliser un transducteur émetteur et un transducteur récepteur. On l’appelle alors mesure en transmission ou pitch-catch en anglais. Ce procédé est par exemple appliqué pour réaliser l’évaluation de matériaux avec un transducteur de part et d’autre de la pièce de test. Ces deux dispositifs expérimentaux sont représentés sur la figure 1.3. Emetteur R´ecepteur Pi`ece Emetteur R´ecepteur Pi`ece (a) (b) FIGURE 1.3 – Configurations de mesure par ultrasons. (a) : en réflexion, (b) : en transmission. Les mesures peuvent se faire directement en contact avec la pièce à inspecter (voir fi- gure 1.1). On utilise alors un couplant entre le(s) transducteur(s) et le matériau pour réaliser une adaptation d’impédance. L’eau est également un très bon adaptateur d’impédance si bien que la majorité des contrôles est réalisée en immersion dans une cuve (voir photo 1.4). 161.2 Détection des discontinuités et des défauts FIGURE 1.4 – Cuve de mesure par ultrasons au Laboratoire d’Acoustique de l’Université du Maine. Les transducteurs et les pièces à inspecter sont immergés le plus souvent dans l’eau. 1.2 Détection des discontinuités et des défauts 1.2.1 Changements d’impédance acoustique Les ondes acoustiques sont générées grâce à un transducteur électro-acoustique. L’onde se propage alors dans le milieu et crée une onde retour à chaque changement d’impédance rencontré [Saniie et Nagle 1989]. Ces discontinuités d’impédance acoustique peuvent provenir d’interfaces entre deux milieux ou alors de défauts qui créent des ruptures dans le matériau. À titre d’exemple, nous étudions le cas d’un matériau homogène d’impédance Z1 entouré par un milieu homogène d’impédance Z2 (cf. figure 1.5). C’est typiquement le cas d’une Z1 Z2 α12 β12 α21 β21 Z1 d transducteur FIGURE 1.5 – Coefficients de réflexion aux interfaces de deux matériaux. pièce immergée dans une cuve d’eau. L’impédance acoustique d’un matériau homogène est Zi ✏ ρici , où ρi est la masse volumique et ci est la vitesse des ondes [Krautkramer et Krautkramer 1990, chap. 2]. Le coefficient de réflexion αij , entre un milieu i et un milieu j, qui 17CHAPITRE 1 : Positionnement du problème indique le rapport entre la pression réfléchie et la pression incidente, se calcule par αij ✏ Zj ✁ Zi Zi Zj . (1.2) D’un manière similaire, le coefficient de transmission βij , d’un milieu i vers un milieu j, définit le rapport entre les pressions transmise et incidente, et s’écrit βij ✏ 1 αij ✏ 2Zj Zi Zj . (1.3) Pour une mesure en réflexion, nous pouvons alors calculer les coefficients de réflexion des deux premiers échos, l’écho de surface et l’écho du fond de la pièce (voir figure 1.5), qui ont pour amplitudes respectives α12 et β12α21β21. Les ondes réfléchies sont ensuite réceptionnées par un capteur acousto-électrique et forment les échos dans le signal électrique. Pour illustrer la problématique, nous avons choisi une pièce d’aluminium immergée dans l’eau avec les paramètres suivants : c1 ✏ 1500 m.s✁1 , ρ1 ✏ 1000 kg.m✁3 , c2 ✏ 6500 m.s✁1 , ρ2 ✏ 2660 kg.m✁3 . Le premier écho est l’écho de surface qui a une amplitude α12 ✏ 0.8403. Les échos suivants proviennent des allers-retours avec le fond de la pièce. Le deuxième écho a donc une amplitude β12α21β21 ✏ ✁0.2469, le troisième β12α 3 21β21 ✏ ✁0.1744 et ainsi de suite pour les échos suivants. Des exemples de signaux simulés pour des épaisseurs d ✏ 10 mm et d ✏ 1 mm sont représentés sur la fi- gure 1.6. Dans ces signaux, les amplitudes sont identiques, mais les temps entre les échos 0 5 10 15 20 25 −1 −0.5 0 0.5 1 (a) Donn´ees pour une ´epaisseur de 10 mm y(t) t [µs] 0 5 10 15 20 25 −1 −0.5 0 0.5 1 (b) Donn´ees pour une ´epaisseur de 1 mm y(t) t [µs] FIGURE 1.6 – Exemple de A-scan simulé correspondant à la figure 1.5 avec (a) d ✏ 10 mm et (b) d ✏ 1 mm. Le matériau 1 est l’eau (c1 ✏ 1500 m.s✁1 , ρ1 ✏ 1000 kg.m✁3 ) et le matériau 2 est l’aluminium (c2 ✏ 6500 m.s✁1 , ρ2 ✏ 2660 kg.m✁3 ). sont différents. En effet, le temps d’un aller-retour dans la pièce est 2d④c2 et vaut 3.08 µs pour d ✏ 10 mm et 0.31 µs pour d ✏ 1 mm. Le but de la déconvolution est de retrouver les positions et les amplitudes des discontinuités d’impédance à partir du signal électrique reçu par le capteur ultrasonore. Retrouver 181.2 Détection des discontinuités et des défauts ces grandeurs à partir de mesures échantillonnées, incomplètes et bruitées consiste en un problème inverse mal posé [Idier 2001]. Dans les exemples de la figure 1.6, on devine qu’il sera plus facile de résoudre le problème pour d ✏ 10 mm que pour d ✏ 1 mm. 1.2.2 La séquence de réflectivité A partir de la problématique évoquée dans la section précédente, nous pouvons formaliser l’inconnue à retrouver. Il s’agit d’une séquence de réflectivité qui contient les positions spatiales et les amplitudes des changements d’impédance. De façon analogue, la séquence de transmittivité est relative à une mesure en transmission. Deux configurations sont alors possibles suivant la nature de l’objet inspecté. La première considère une distribution dans toutes les directions à partir d’un point de référence à la surface du transducteur. L’illustration de la figure 1.7a montre par exemple trois réflecteurs ponctuels répartis dans un matériau homogène. La deuxième configuration considère une séquence de réflectivité dans une direction donnée. Ce principe est adapté pour analyser des matériaux multi-couches par exemple (fi- gure 1.7b). Les deux exemples que nous montrons aboutissent à la même séquence de réflec- 1 2 3 1 2 3 (a) (b) (c) 1 2 3 d1 d2 d3 z x(z) d1 d2 d3 d1 d2 d3 FIGURE 1.7 – Séquence de réflectivité. (a) : cas de trois réflecteurs considérés ponctuels, (b) : cas de trois couches de matériaux homogènes, (c) : séquence de réflectivité équivalente. tivité illustrée sur la figure 1.7c. Ces deux conventions permettent d’obtenir des séquences composées de pics, c’est-à-dire présentant des discontinuités franches. Nous pouvons alors modéliser la séquence x♣zq sous la forme x♣zq ✏ ➳ i aiδ♣z ✁ ziq, (1.4) où ai et zi sont respectivement les amplitudes et les positions des changements d’impédance. L’hypothèse que nous faisons ici est que x♣zq est parcimonieux : il ne contient qu’un faible nombre de valeurs non nulles. Ce point est important pour le développement des méthodes d’inversion. La figure 1.8 représente les séquences de réflectivité des exemples exposés sur la fi- gure 1.5 et correspondant aux données de la figure 1.6. Ce type d’information est à haute résolution car la forme temporellement étendue d’un écho devient un pic spatial. On peut 19CHAPITRE 1 : Positionnement du problème 0 50 100 150 −0.5 0 0.5 1 (a) S´equence de r´eflectivit´e pour une ´epaisseur de 10 mm x(z) z [mm] 0 50 100 150 −0.5 0 0.5 1 (b) S´equence de r´eflectivit´e pour une ´epaisseur de 1 mm x(z) z [mm] FIGURE 1.8 – Exemple de séquences de réflectivité correspondant aux signaux de la figure 1.6 pour (a) d ✏ 10 mm et (b) d ✏ 1 mm. par conséquent en déduire des dimensions spatiales, comme ici l’épaisseur d de la pièce : la distance entre chaque pic correspond à un aller-retour dans la plaque et donc à deux fois l’épaisseur. 1.3 Modèle direct et problème inverse 1.3.1 Modèle direct Le problème inverse consiste à estimer la grandeur x, inaccessible directement, à partir des données mesurées y. La première étape pour résoudre ce problème est d’établir un modèle direct qui relie x à y. Dans notre cas, ce lien doit respecter au mieux la physique des ondes ultrasonores. Nous développons ce point dans le chapitre 2. Un modèle parfait n’existant pas, il faut prendre en compte un terme d’erreur qui représente les erreurs de modélisation, les incertitudes de mesure et les erreurs de discrétisation. D’une façon générique, le modèle direct s’écrit y ✏ Φ x, bruit✟ , (1.5) où l’opérateur Φ établit le lien direct entre l’inconnue x, le bruit et les mesures y. 1.3.2 Difficultés spécifiques liées au problème inverse Le problème inverse introduit précédemment qui consiste à retrouver les positions des changements d’impédance et les coefficients d’amplitude associés présente des difficultés de ré- solution. 1. Premièrement, les transducteurs travaillant dans une bande de fréquences limitée, l’information reçue est également à bande limitée. Néanmoins, le signal à reconstruire est un train d’impulsions qui contient toutes les fréquences. 201.4 Revue bibliographique 2. Le deuxième problème provient de la manière dont sont acquis les signaux. En effet, nous disposons de signaux quantifiés, ce qui constitue une perte d’information par rapport au signal continu. De plus, ces données comprennent un bruit de mesure qui rajoute des imprécisions dans le signal à traiter. 3. Ensuite, la propagation des ondes acoustiques est soumise à l’atténuation fréquentielle et à la dispersion, phénomènes physiques qui modifient la forme des échos en fonction de la propagation. Cette modification, de caractère passe-bas, provoque une perte plus importante des hautes fréquences des échos lorsque la distance de propagation augmente. Des phénomènes de diffraction peuvent également être présents, qui modifient la forme des échos en fonction de la géométrie des obstacles rencontrés. 4. Enfin, le dernier problème est la superposition des échos qui intervient lorsque les discontinuités sont proches. C’est le cas par exemple pour des plaques minces, pour des défauts proches les uns des autres ou proches des interfaces. 1.3.3 Caractère mal posé Un problème mathématique est dit bien posé s’il vérifie les trois conditions d’existence de la solution, d’unicité de la solution et de continuité de la solution [Idier 2001]. Dans un cas linéaire de dimension finie, cas dans lequel nous nous ramènerons, la condition de continuité est toujours vérifiée. Les conditions d’existence et d’unicité dépendent alors des dimensions du problème. Pour un système carré, ces conditions sont vérifiées. Lorsque le système est sur-déterminé, il n’y a pas existence de solutions. Il est alors d’usage de choisir une solution au sens des moindres carrés : l’inverse généralisée. Quand le système est sous-déterminé, il y a une infinité de solutions et la condition d’unicité n’est pas vérifiée. On peut alors choisir la solution de plus petite norme. Ces propriétés occasionnent un caractère mal posé suivant la définition des dimensions du modèle direct. Dans notre application, le caractère mal posé vient avant tout du fait que le signal à reconstruire est à très large bande (train d’impulsions), alors que l’information reçue est à bande limitée. De ce fait, des informations sont absentes des données et ne peuvent être obtenues par une procédure classique d’inversion. Une opération d’inversion naïve aura pour seule conséquence d’amplifier le bruit de mesure et les erreurs de modèles à cause de son caractère filtre inverse, et donc amplificateur des fréquences hors du signal utile. Ceci est lié au mauvais conditionnement du système, qui est de surcroît aggravé en présence d’atténuation. Les effets propagatifs engendrent en effet une perte supplémentaire d’information à haute fréquence. Une solution efficace consiste à régulariser le problème, c’est-à-dire à introduire une certaine connaissance a priori de la solution recherchée. Dans le cas de la recherche de discontinuités franches, la solution sera considérée parcimonieuse. 1.4 Revue bibliographique Pour résoudre le problème d’estimation des discontinuités d’un objet inspecté par ultrasons, il existe dans la littérature plusieurs familles de méthodes [Zhang et Harvey 2013]. Une première approche consiste à utiliser un modèle d’écho en fonction d’un jeu de paramètres Θ : 21CHAPITRE 1 : Positionnement du problème y ✏ Φ ♣Θq bruit, l’inconnue x étant contenue dans certains paramètres de Θ. La relation entre les données et les paramètres est le plus souvent non-linéaire. L’avantage de ce modèle est sa flexibilité en termes de variation des paramètres, qui peut permettre de modéliser des changements de forme dus à l’atténuation, à la dispersion et à la diffraction. Un autre avantage est la définition des paramètres dans des espaces continus, qui ne sont donc pas limités par une discrétisation. Demirli et Saniie [2001a] ont proposé de modéliser les mesures comme une somme d’échos gaussiens modulés et de résoudre le problème par des algorithmes d’optimisation non linéaire locale (Gauss-Newton). Ils utilisent plus particulièrement l’algorithme SAGE (Space Alternating Generalized Expectation-Maximization) [Ziskind et Wax 1988, Fessler et Hero 1993], une extension de la méthode EM, qui donne de bons résultats dans un contexte de CND et d’END [Demirli et Saniie 2001b]. Ces méthodes sont très sensibles aux initialisations des paramètres et requièrent soit une certaine connaissance de la solution, soit des routines tendant vers une optimisation globale, mais augmentant considérablement le temps de calcul. Des travaux postérieurs utilisent des modèles d’échos plus complexes [Lu et al. 2006, Demirli et Saniie 2009], permettant une plus grande flexibilité mais compliquant l’optimisation. Ces travaux ne spécifient néanmoins aucun a priori physique sur la façon dont les paramètres peuvent varier. Afin d’éviter une optimisation des moindres carrés non-linéaires, qui présente une forte sensibilité aux initialisations et aux minima locaux, plusieurs auteurs ont proposé de discrétiser les paramètres du modèle pour obtenir un modèle linéaire [Hong et al. 2006, Lu et Michaels 2008, Zhang et al. 2008, Mor et al. 2010, Bossmann et al. 2012]. Ces approches utilisent un dictionnaire de grande taille qui liste les possibilités de modélisation des échos. De nombreux travaux effectuent également un apprentissage du dictionnaire [Lewicki et Sejnowski 2000, Kreutz-Delgado et al. 2003, Aharon et al. 2006, Zhang et al. 2008; 2012]. À cause de la grande dimension du problème, ils utilisent ensuite des méthodes rapides d’approximation parcimonieuse, de type Matching Pursuit (MP) [Mallat et Zhang 1993], qui sont peu performantes lorsque les échos se mélangent. Les méthodes décrites jusqu’ici sont considérées comme aveugles, car elles n’ont besoin d’aucun signal de référence. Une autre façon d’appréhender le problème inverse est d’utiliser un modèle discret linéaire. On se retrouve alors dans le cas où y ✏ Φx bruit, utilisé par exemple dans un contexte de CND dans [Zala 1992, Sin et Chen 1992]. Bien souvent, un opérateur de convolution est utilisé tel que y ✏ h ✝ x bruit, où h est la réponse impulsionnelle du système supposée connue (Φ est alors une matrice de convolution). Le modèle direct spécifie par conséquent que les données contiennent des répliques exactes de cette réponse et décalés dans le temps. Contrairement aux approches paramétriques, ce modèle direct est très contraint et permet d’utiliser des méthodes d’inversion robustes et efficaces. D’un autre côté, la résolution temporelle est limitée par la discrétisation, et le modèle s’applique à des problèmes où la forme des échos varie extrêmement peu. Les méthodes d’estimation les plus simples sont l’inversion généralisée [Sin et Chen 1992] et les méthodes basées sur l’intercorrélation [Quazi 1981, Nandi 1995]. Ces approches naïves sont malheureusement peu performantes en présence de bruit et/ou lorsque les échos se mélangent. Une solution adaptée consiste à régulariser le problème en injectant une connaissance a priori sur l’inconnue. L’objectif est dès lors de minimiser un critère d’attache aux données auquel on ajoute une fonction de pénalisation [Idier 2001, Zhang et al. 2008, Soussen et al. 2012]. Pour des aspects pratiques d’optimisation, des fonctions convexes et différentiables ont été utilisées, telles que la norme `2 [Idier 2001]. Le filtrage de Wiener est par exemple équi- 221.4 Revue bibliographique valent à une pénalisation `2 [Chen et al. 1988, Neal et al. 1993]. L’inconvénient de ce type de régularisation est que les solutions produites ne sont pas parcimonieuses. On préfère alors utiliser une norme `1 [Taylor et al. 1979, Chen et al. 1998] qui, de par sa non différentiabilité en zéro, produit des solutions parcimonieuses [Moulin et Liu 1999]. La convexité de la norme `1 permet l’utilisation d’algorithmes rapides qui aboutissent à un minimum unique (voir une revue dans [Tropp et Wright 2010]). O’Brien et al. [1990; 1994] utilisent notamment ce type de pénalisation dans un cadre de CND. Du fait de la pénalisation linéaire des amplitudes, cette régularisation produit néanmoins des solutions avec de nombreux pics de faibles amplitudes, qui sont faiblement pénalisés. Une autre solution repose sur la formulation du problème par une pénalisation `0 [Zala 1992, Rao et Kreutz-Delgado 1999, Soussen et al. 2011], qui compte le nombre de composantes non nulles dans l’estimé et donne donc un vrai critère de parcimonie pour la solution recherchée. Cette pénalisation est discrète, non convexe, et nécessite une exploration combinatoire des solutions. Une façon optimale de procéder est de tester toutes les combinaisons des composantes non nulles de x, ce qui est prohibitif en termes de temps de calcul (sauf pour des problèmes avec un très petit nombre de pics non nuls [He et al. 2011]). Il existe des méthodes sous-optimales inspirées des méthodes gloutonnes d’approximation parcimonieuse [Mallat et Zhang 1993, Pati et al. 1993, Chen et al. 1989]. Celles-ci partent d’une solution nulle et ajoutent un élément à chaque itération. L’algorithme Single Best Replacement (SBR) proposé par Soussen et al. [2011], et inspiré de l’algorithme SMLR utilisé pour la déconvolution sous un modèle Bernoulli-gaussien [Kormylo et Mendel 1982, Mendel 1983, Goussard et al. 1990, Champagnat et al. 1996], permet l’ajout ou le retrait d’un élément à chaque itération. Il a montré de bons résultats par rapport à des approches gloutonnes et aux approches par pénalisation `1 [Bourguignon et al. 2011, Selesnick et Bayram 2014], notamment dans un contexte de CND [Soussen et al. 2012]. Les mouvements d’un seul élément à chaque itération de l’algorithme SBR peuvent néanmoins être insuffisants lorsque les échos se mélangent. Dans une optique de mouvements plus complexes, Kaaresen [1997] a proposé les algorithmes Iterative Window Maximization (IWM) qui ont donné de bons résultats pour la déconvolution en CND [Kaaresen 1998]. On retrouve également ce type de mouvements dans [Zala 1992] dans un contexte de déconvolution pour le CND. L’atténuation et la dispersion provoquent une distorsion des échos, avec pertes des hautes fréquences, qui s’amplifie au fur et à mesure que la distance de propagation augmente [Wear 2000]. La prise en compte de ces phénomènes est un problème majeur dans les méthodes d’inversion [Zhang et Harvey 2013]. Ils sont indirectement pris en compte dans les méthodes aveugles citées plus haut, car celles-ci considèrent une variation de la forme d’onde au cours de son parcours [Demirli et Saniie 2001a]. Cette flexibilité permet, dans la limite du modèle considéré, de s’adapter aux variations dues à l’atténuation. D’autres approches aveugles permettent une faible variation des échos entre des intervalles temporels voisins [Kaaresen et Bolviken 1999]. D’un autre côté, les méthodes qui considèrent un modèle de convolution discrète ne prennent pas du tout en compte l’atténuation. Des travaux existent en géophysique et modélisent l’atténuation grâce un modèle en Q [Hale 1981, Wang 2009]. La propagation des ondes sismiques est en effet similaire à celle des ultrasons [Kjartansson 1979]. Dans le domaine ultrasonore, l’atténuation a été modélisée dans le domaine temporel de façon empirique par un filtre à réponse impulsionnelle finie [Rasmussen 1994, Olofsson et Stepinski 2001], dont la réponse impulsionnelle varie en fonction de la distance de propagation. Le modèle d’Olofsson et Stepinski a notamment donné de bons résultats pour le 23CHAPITRE 1 : Positionnement du problème contrôle de composites. Cependant, les modèles paramétriques et empiriques n’exploitent pas de connaissance physique sur la propagation. Les modèles en loi de puissance fréquentielle [Kak et Dines 1978, Ophir et Jaeger 1982, Narayana et Ophir 1983], qui ont montré de bons résultats avec de nombreux matériaux [Szabo 1995, He 1999], semblent de ce fait plus adaptés pour modéliser les signaux ultrasonores. La dispersion peut notamment être ré- glée en fonction de l’atténuation grâce à des théories de la causalité [Gurumurthy et Arthur 1982, Kuc 1984, Szabo 1995]. L’utilisation de ces modèles fréquentiels dans les problèmes inverses est plus compliquée du fait de leur non-linéarité et n’a à notre connaissance pas été envisagée avant ce travail. 1.5 Axes de travail effectués pendant la thèse Le premier axe de travail a consisté à établir un modèle direct qui prend en compte un pro- fil physique d’atténuation et de dispersion (chapitre 2). Nous avons développé un modèle linéaire pour les signaux discrets qui permet l’utilisation de méthodes d’inversion robustes et efficaces. Pour résoudre des problèmes dus à l’échantillonnage, nous montrons également comment développer un modèle sur-échantillonné par rapport aux données (chapitre 4). En ce qui concerne la partie méthodologique, nous dirigeons notre étude vers l’inversion par approche pénalisée avec une norme `0 (chapitre 3). Ce choix nous paraît le plus logique en termes de performances au vu des contributions récentes dans le domaine de la déconvolution parcimonieuse (algorithme SBR). Par différentes procédures, nous avons notamment montré l’efficacité de cette approche comparée aux approches naïves et aux méthodes d’estimation paramétrique. Nous avons développé plusieurs algorithmes inspirés de SBR, mais présentant une exploration combinatoire plus complexe et adaptée aux formes d’ondes oscillantes. La déconvolution pour un modèle sur-échantillonné a également été un axe de développement méthodologique important (chapitre 4). Nous avons adapté des algorithmes de déconvolution parcimonieuse pour obtenir une meilleure résolution de la solution et ainsi résoudre des problèmes de modes locaux. Tout au long de ce travail, nous avons illustré nos modèles et méthodes avec de nombreuses expérimentations réalisées au Laboratoire d’Acoustique de l’Université du Maine (LAUM). Le chapitre 5 est spécialement dédié à l’application concrète des méthodes de dé- convolution parcimonieuse pour le CND. Toutes les acquisitions ne figurent évidemment pas dans ce manuscrit, mais nous avons testé des matériaux homogènes comme l’aluminium, le polyméthacrylate de méthyle (PMMA2 ), le polycarbonate, le caoutchouc synthé- tique et l’huile de ricin, ainsi que des matériaux hétérogènes comme des composites carbone/époxyde et des matériaux poreux. 2Le PMMA est également connu sous le nom de la marque Plexiglas®. 24Chapitre 2 Le modèle direct des signaux ultrasonores Sommaire Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1 Modèle de signaux continus pour une cible ponctuelle . . . . . . . . . 26 2.1.1 Modèle fréquentiel . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.2 Écriture en fonction de la distance de propagation . . . . . . . . . 27 2.1.3 L’atténuation fréquentielle . . . . . . . . . . . . . . . . . . . . . 28 2.1.4 La dispersion et les théories causales . . . . . . . . . . . . . . . . 33 2.2 Modèle discret linéaire pour l’inversion . . . . . . . . . . . . . . . . . 38 2.2.1 Modèle de signaux à temps continu pour une distribution de cibles 38 2.2.2 Modèle de signaux à temps discret . . . . . . . . . . . . . . . . . 39 2.2.3 Différents cas pour le modèle linéaire discret . . . . . . . . . . . 40 2.2.4 Calcul numérique des réponses impulsionnelles d’atténuation . . 43 2.2.5 Modèle d’atténuation d’Olofsson . . . . . . . . . . . . . . . . . 45 2.3 Exploitation des modèles . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.3.1 Mesure en mode pulse-echo avec du polycarbonate . . . . . . . . 48 2.3.2 Mesure en transmission dans l’huile de ricin . . . . . . . . . . . . 53 2.3.3 Mesure aérienne en transmission dans un matériau poreux . . . . 56 2.3.4 Exploitation du modèle pour l’Évaluation Non Destructive . . . . 58 2.3.5 Problème de diffraction des cibles : application aux trous à fond plat 61 Introduction Ce chapitre présente le modèle direct que nous construisons pour résoudre le problème inverse. Dans la section 2.1, nous décrivons la formation du signal ultrasonore en présence 25CHAPITRE 2 : Le modèle direct d’une cible dans un milieu homogène. Ce modèle utilise la réponse instrumentale du système ainsi qu’un modèle de propagation spécifique, incluant l’atténuation. Nous détaillons plusieurs modèles d’atténuation, notamment celui qui décrit la dispersion à partir de l’atténuation grâce à des théories causales. Ensuite, dans la section 2.2, nous montrons qu’en présence de plusieurs cibles, le modèle discret échantillonné s’écrit comme un système linéaire. Nous validons dans la section 2.3 cette formulation avec des données expérimentales, tout d’abord pour comparer les modèles d’atténuation présentés. Puis le modèle est exploité pour réaliser l’évaluation non destructive d’un matériau. Enfin, nous utilisons des données acquises en présence d’un trou à fond plat et montrons les problèmes liés à la diffraction des cibles et donc les limites du modèle. Ce chapitre est en partie tiré des publications [Carcreff et al. 2013c], [Carcreff et al. 2014a] et [Carcreff et al. 2014b]. 2.1 Modèle de signaux continus pour une cible ponctuelle 2.1.1 Modèle fréquentiel Nous considérons un milieu de propagation homogène et isotrope dans lequel est placée une cible ponctuelle en rT (rT est composé des coordonnées spatiales de la cible par rapport au centre du transducteur émetteur). La cible est supposée avoir une impédance acoustique significativement différente de celle du milieu. La mesure ultrasonore peut être effectuée avec un seul transducteur en mode pulse-echo ou avec deux transducteurs utilisés en mode transmission sans que le modèle ne diffère. Les deux configurations sont illustrées sur la figure 2.1. Cibleb Emetteur R´ecepteur b Cible Emetteur R´ecepteur (a) (b) H r T (1) r H(2) r H(1) r H(2) r r T FIGURE 2.1 – Configurations possibles de mesure ultrasonore. (a) : Transmision, (b) : pulseecho. Le signal reçu par le transducteur est alors décrit dans le domaine fréquentiel par la cascade de plusieurs réponses fréquentielles [Fink et Cardoso 1984, Chen et al. 1988] : Y ♣f, rT q ✏ U♣fqHea♣fqHr♣f, rT qHae♣fq, (2.1) comme illustré sur la figure 2.2. Le signal U♣fq est l’excitation électrique fournie au transducteur électro-acoustique. Les fonctions Hea♣fq et Hae♣fq sont respectivement les réponses électro-acoustique et acousto-électrique du transducteur. La réponse instrumentale Hi♣fq ✏ U♣fqHea♣fqHae♣fq peut être définie en regroupant les fonctions qui ne dépendent pas de la propagation dans le matériau. L’équation (2.1) devient alors : Y ♣f, rT q ✏ Hi♣fqHr♣f, rT q. (2.2) 262.1 Modèle de signaux continus pour une cible ponctuelle b z Hea(f) Hae(f) U(f) Y (f, rT ) Hr Cible (f, rT ) transducteur S rT rb0 FIGURE 2.2 – Schéma de la mesure ultrasonore pour un cible ponctuelle. La fonction de transfert de propagation Hr♣f, rT q représente la fonction relative au parcours de l’onde dans le milieu de propagation [Stephanishen 1971, Fink et Cardoso 1984]. Elle prend en compte la diffraction de la source, la propagation vers la cible, la réflexion ou la transmission par la cible et la propagation vers la surface réceptrice, tout ceci incluant le cas échéant des effets visco-élastiques. Nous verrons par la suite que ces effets se traduisent sous forme d’atténuation et de dispersion. La fonction de transfert de propagation totale s’écrit alors Hr♣f, rT q ✏ H ♣1q r ♣f, rT qH ♣2q r ♣f, rT q. On peut calculer la fonction de transfert de propagation du transducteur vers la cible H ♣1q r ♣f, rT q grâce à l’intégrale de Rayleigh [Rayleigh 1945], qui est la somme de contributions ponctuelles intégrées sur la surface S [Stephanishen 1971, Harris 1981] H ♣1q r ♣f, rT q ✏ ➺ r0PS e✁jk♣fq⑤rT ✁ r0⑤ 2π⑤rT ✁ r0⑤ dS, (2.3) où k♣fq est le nombre d’onde1 (nous détaillerons ci-après sa formulation). Pour une mesure en pulse-echo, la fonction retour H ♣2q r ♣f, rT q se calcule en considérant la cible comme une nouvelle source excitée par le champ créé en son emplacement et en intégrant ensuite le champ sur la surface du transducteur récepteur [Lhemery 1991, Rhyne 1977]. Cette fonction n’est pas développée ici, mais a une forme similaire à l’équation (2.3) [Lhemery 1991]. En effet, la symétrie entre rT et r0 entraîne un principe de réciprocité entre l’émission et la ré- ception. Pour une mesure en pulse-echo, ce principe implique que H ♣1q r ♣f, rT q ✏ H ♣2q r ♣f, rT q à un facteur multiplicatif près [Lhemery 1991]. Le nombre d’onde k♣fq dépend de la fréquence et a une forme générale complexe k♣fq ✏ β♣fq ✁ jα♣fq. (2.4) Le terme β♣fq décrit le caractère propagatif de l’onde, tel que β♣fq ✏ 2πf④c♣fq, avec c♣fq la vitesse de phase des ondes acoustiques. Le terme α♣fq traduit le caractère dissipatif de l’onde et représente l’atténuation fréquentielle dans le matériau. 2.1.2 Écriture en fonction de la distance de propagation Nous considérons une distance de propagation moyenne z qui représente le trajet entre les centres des transducteurs émetteur et récepteur [Fink et Cardoso 1984] (voir les figures 2.1 et 2.2). Les effets de diffraction de la source et de la cible sont alors considérés comme 1Par convention, pour une fréquence f donnée, nous considérons e j♣2πf t✁k♣fqxq une onde plane se propageant dans le sens des x positifs. 27CHAPITRE 2 : Le modèle direct identiques en fonction de z. A partir des équations (2.3) et (2.4), ⑤rT ✁ r0⑤ ✔ z ne dépend plus de la position r0. La fonction de propagation H ♣1q r ♣f, zq peut donc s’écrire H ♣1q r ♣f, zq ✏ e✁jk♣fqz 2πz ➺ r0PS dS. (2.5) Par le principe de réciprocité évoqué plus haut, la fonction H ♣2q r ♣f, zq a une forme similaire à un facteur multiplicatif près. On peut considérer une amplitude b♣zq, indépendante de la fréquence, et qui dépend de plusieurs facteurs comme la surface ou les surfaces des transducteurs, la position de la cible et le changement d’impédance. On s’intéresse ici à la modélisation du problème pour une valeur fixée de z. Nous détaillons dans la partie 2.2.1 le modèle à plusieurs cibles. On peut donc écrire une forme générale de la fonction de propagation Hr♣f, zq ✏ b♣zqe ✁α♣fqz e ✁jβ♣fqz ✏ b♣zqe ✁α♣fqz e ✁j2πfz④c♣fq . (2.6) Elle est composée d’un facteur d’amplitude b♣zq, d’un terme de module e ✁α♣fqz qui défi- nit l’atténuation et d’un terme de phase e ✁j2πfz④c♣fq qui caractérise la vitesse de phase. Il faut noter que la fonction Hr♣f, zq est valable pour une fonction de diffraction donnée de la cible [Sin et Chen 1992], simplification nécessaire pour uniformiser l’effet de l’atténuation par rapport à z. Nous verrons dans la partie 2.3.5 l’influence de cette hypothèse. L’équation (2.2) devient donc Y ♣f, zq ✏ Hi♣fqHr♣f, zq. (2.7) Nous notons respectivement y♣t, zq, hi♣tq et hr♣t, zq les signaux temporels correspondant à Y ♣f, zq, Hi♣fq et Hr♣f, zq. Le signal temporel reçu par le capteur pour une cible est le produit de convolution à temps continu y♣t, zq ✏ hi♣tq ✝ hr♣t, zq ✏ ➺ ✽ ✁✽ hi♣τ qhr♣t ✁ τ, zqdτ. (2.8) 2.1.3 L’atténuation fréquentielle L’atténuation α♣fq de l’onde acoustique dans le milieu de propagation est due à plusieurs phénomènes [Krautkramer et Krautkramer 1990, chap. 6], [Sachse et Pao 1978]. Dans un matériau homogène, les deux principales causes d’atténuation sont la dissipation thermique et la diffusion. La dissipation thermique ou absorption traduit le fait que l’énergie de l’onde se transforme en chaleur à cause de la mise en mouvement des particules. La diffusion sousentend que le matériau n’est pas strictement homogène et que de petites discontinuités provoquent un éparpillement de l’onde dans toutes les directions. Ces deux phénomènes sont de ce fait dépendants de la longueur d’onde2 et donc de la fréquence de l’onde. En effet, les particules et discontinuités ne sont pas « vues » par une onde basse fréquence, lorsque la longueur d’onde est très supérieure à leur dimension. L’effet de l’atténuation augmente par conséquent avec la fréquence. 2La longueur d’onde λ est définie en fonction du nombre d’onde par λ♣fq ✏ 2π④k♣fq. Pour un matériau homogène non dissipatif, la longueur d’onde est seulement fonction de la fréquence de l’onde : λ♣fq ✏ c④f. 282.1 Modèle de signaux continus pour une cible ponctuelle Généralement, l’atténuation se modélise par une loi de puissance fréquentielle [Ophir et Jaeger 1982, Narayana et Ophir 1983] α♣fq ✏ α0⑤f⑤ γ , (2.9) où α0, le coefficient d’atténuation, et γ, le facteur de puissance, sont des paramètres réels positifs caractérisant un matériau homogène donné. Pour la majorité des milieux, le facteur γ (sans unité) vérifie γ P s0, 2s [Narayana et Ophir 1983, Szabo 1995]. Pour de nombreux matériaux, le choix d’un modèle linéaire (γ ✏ 1) s’est avéré une approximation satisfaisante [Serabian 1967, Kuc et al. 1976, Kak et Dines 1978, Kuc 1983; 1984]. On rencontre une atténuation non-linéaire pour des structures plus complexes de matériaux tels que le polyéthylène (γ ✓ 1.13), le caoutchouc synthétique (γ ✓ 1.38) ou l’huile de ricin (γ ✓ 1.67) [Harris et al. 1983, Szabo 1995, He 1999]. Pour les tissus mous, on peut considérer 1 ↕ γ ↕ 1.5 [Duck 1990]. Notons que les propagations sans atté- nuation (γ ✏ 0) et en régime visqueux (γ ✏ 2) présentent des équations d’onde analytiques exactes [Kelly et al. 2008]. Le coefficient d’atténuation α0 indique l’affaiblissement par unité de distance et de fré- quence et est donc exprimé en Np.MHz✁γ .m✁1 ou en dB.MHz✁γ .cm✁1 . Un coefficient α0 nul correspond à une propagation sans dissipation. Dans la réalité, α0 n’est jamais nul, même s’il peut être très faible, comme dans l’eau par exemple : α♣fq ✔ 0.025⑤f⑤ 2 Np.MHz✁2 .m✁1 [Pinkerton 1949]. De nombreuses méthodes permettent de mesurer α0 dans le cas de l’atténuation linéaire [Kuc et al. 1976, Kak et Dines 1978, Kuc 1983; 1984, Rokhlin et al. 1986] et de mesurer α0 et γ dans le cas non linéaire [Harris et al. 1983, Szabo 1995, He 1999]. Les paramètres α0 et γ peuvent également être tirés de catalogues [Selfridge 1985]. L’atténuation fréquentielle crée donc une fonction de transfert en module e ✁α0⑤f⑤ γz dans l’équation (2.6). Elle a un effet de filtrage passe-bas qui s’accentue au fur et à mesure de la propagation (quand z augmente), comme illustré sur la figure 2.3. Ceci a principalement deux effets dans une inspection par ultrasons. Premièrement, les ondes sont plus fortement 0 2 4 6 8 10 −20 −10 0 10 20 0 0.2 0.4 0.6 0.8 1 f (MHz) z (mm) |H r(f, z)| FIGURE 2.3 – Exemple de fonction d’atténuation ⑤Hr♣f, zq⑤ en fonction de la fréquence et de la distance de propagation. L’atténuation est linéaire, telle que ⑤Hr♣f, zq⑤ ✏ e ✁α0⑤f⑤z , avec α0 ✏ 50 Np.MHz✁1 .m✁1 . 29CHAPITRE 2 : Le modèle direct atténuées en amplitude lorsque z augmente, ce qui complique l’inspection pour de grandes distances de propagation. Deuxièmement, l’effet passe-bas provoque un étalement temporel des échos, ce qui diminue la résolution des mesures. Pour pallier le premier problème, il est d’usage d’utiliser des transducteurs plutôt basse fréquence pour inspecter des matériaux atténuants, au détriment de la résolution. Dans la suite de ce chapitre, en section 2.3, nous montrons comment mesurer les paramètres α0 et γ, à partir d’expériences réalisées avec des matériaux atténuants. Nous utilisons d’abord le polycarbonate qui est un polymère présentant une atténuation linéaire (partie 2.3.1). Ensuite, un cas d’atténuation non-linéaire est présenté avec l’huile de ricin (partie 2.3.2). Lien avec l’atténuation en géophysique En géophysique, les ondes sismiques ou radar sont utilisées pour inspecter le sol. Ce sont approximativement les mêmes modèles que ceux décrits précédemment [Wang 2009, chap. 2 et 3]. Les milieux sont caractérisés par un facteur de qualité Q qui correspond au rapport entre l’énergie maximale stockée et l’énergie perdue par cycle de déformation dans le milieu [Kjartansson 1979, Wang 2009]. Un facteur infini correspond donc à une propagation sans perte d’énergie et par conséquent à une atténuation nulle. Le coefficient d’atténuation est alors lié à Q par α♣fq ✏ πf Q♣fqc♣fq , (2.10) où c♣fq est la vitesse des ondes. Si Q♣fq et c♣fq sont constants en fonction de la fréquence, l’atténuation est linéaire, avec α0 ✏ π④Qc. Nous faisons ce lien car le domaine géophysique est actif en matière de développement de méthodes inverses. De nombreux travaux sont ainsi consacrés au filtre Q inverse [Hargreaves et Calvert 1991, Wang 2009]. Le but de ce procédé est d’annuler les effets de l’atténuation et de la dispersion tout en conservant la signature instrumentale. Cela permet de réduire la perte de résolution et d’amplitude des signaux. Exemple 1 : atténuation linéaire d’un écho gaussien Un modèle paramétrique couramment utilisé pour modéliser les échos ultrasonores est le modèle d’écho gaussien ou ondelette de Gabor [Kuc et al. 1976, Narayana et Ophir 1983, Wear 2000]. La réponse instrumentale s’écrit alors comme une gaussienne modulée par une sinusoïde hi♣tq ✏ Ae✁ ♣t✁t0q 2 2σ2 t cos♣2πf0♣t ✁ t0q φq, (2.11) avec A l’amplitude, t0 la position temporelle, σ 2 t la variance temporelle de la gaussienne, f0 la fréquence d’oscillation et φ le décalage de phase. On peut montrer que le module de la transformée de Fourier de hi♣tq est composé de deux gaussiennes, centrées en f0 et ✁f0 et de variance fréquentielle σ 2 f [Wear 2000]. En négligeant la contribution de la gaussienne en ✁f0, le module de la transformée de Fourier de cette forme d’onde pour les fréquences positives est ⑤Hi♣fq⑤ ✏ A ✶ e ✁ ♣f✁f0q 2 2σ2 f , (2.12) 302.1 Modèle de signaux continus pour une cible ponctuelle avec A✶ ✏ Aσt ❄ 2π et σf ✏ 1④♣2πσtq. Nous ne nous intéressons pas à la phase ici pour observer la perte d’amplitude et de résolution. Nous développerons l’étude de la phase dans la partie 2.1.4. D’après l’équation (2.7), le module de la transformée de Fourier de l’écho, après une propagation de distance z, est ⑤Y ♣f, zq⑤ ✏ ⑤Hi♣fq⑤e ✁α0⑤f⑤z et s’écrit, pour f ➙ 0, ⑤Y ♣f, zq⑤ ✏ A ✶ e ✁ ♣f✁f0q 2 2σ2 f e ✁α0fz ✏ A ✶ e ✁ f 2f 2 0 ✁2ff02α0fzσ2 f 2σ2 f ✏ A ✶ e ✁ f 2 0 f 2✁2f♣f0✁α0σ 2 f zq 2σ2 f . (2.13) En posant f1♣zq ✏ f0 ✁ α0σ 2 f z, (2.14) nous aboutissons à ⑤Y ♣f, zq⑤ ✏ A ✶ e ✁ f 2 0 f 2✁2ff1♣zqf1♣zq 2✁f1♣zq 2 2σ2 f ✏ A ✶ e f1♣zq 2✁f 2 0 2σ2 f e ✁ ♣f✁f1♣zqq2 2σ2 f . (2.15) Le spectre en module du signal transmis est donc une nouvelle gaussienne qui a la même variance σ 2 f mais une fréquence centrale f1♣zq plus petite que f0. L’atténuation crée donc un décalage linéaire de la fréquence centrale f1 en fonction de la distance de propagation z. On peut noter que f1♣zq s’annule pour une distance maximale : zmax ✏ f0 α0σ 2 f . (2.16) La fréquence f1♣zq étant inférieure à f0, le terme d’amplitude e f1♣zq 2✁f 2 0 ④2σ 2 f diminue lorsque z augmente. C’est ce terme qui crée la décroissance exponentielle en amplitude due à l’atté- nuation. Un exemple simulé est donné sur la figure 2.4. Nous traçons le module de Y ♣f, zq pour trois distances de propagation z sur la figure 2.4b. La fréquence centrale diminue quand la distance z augmente, tandis que la largeur de bande – liée à σf – reste constante. Les formes temporelles correspondantes sont également tracées sur la figure 2.4c, montrant l’étalement temporel quand z augmente. Dans la réalité, les échos sont retardés temporellement à cause des distances de propagation. Cet aspect n’est pas pris en compte ici pour bien montrer le comportement en amplitude. De plus, dans les domaines temporel et fréquentiel, les signaux sont normalisés pour plus de clarté. En réalité les signaux subissent une forte décroissance en amplitude à cause de l’atténuation. La figure 2.4d montre le décalage linéaire de la fréquence centrale en fonction de la distance de propagation, avec une pente de ✁α0σ 2 f ✏ ✁0.0465 MHz/mm. Exemple 2 : atténuation quadratique d’un écho gaussien Nous appliquons maintenant au même écho gaussien ⑤Hi♣fq⑤ une atténuation quadratique caractérisée par la fonction de transfert en module ⑤Hr♣f, zq⑤ ✏ e ✁α0⑤f⑤ 2z . En négligeant la 31CHAPITRE 2 : Le modèle direct 0 5 10 15 20 0 0.2 0.4 0.6 0.8 1 f [MHz] |Hr(f, z)| (a) Fonctions d’att´enuation z = 0mm z = 5mm z = 10mm z = 20mm 0 2 4 6 8 10 0 0.2 0.4 0.6 0.8 1 f [MHz] |Y (f, z)| (b) Spectres en module normalis´e des ´echos 1.5 2 2.5 3 −1 −0.5 0 0.5 1 t [µs] y(t,z) (c) Formes temporelles recal´ees et normalis´ees 0 5 10 15 20 3.5 4 4.5 5 5.5 z [mm] f1 [MHz] (d) Fr´equence centrale FIGURE 2.4 – Effets d’une atténuation linéaire avec α0 ✏ 50 Np.MHz✁1 .m✁1 pour plusieurs distances de propagation z ✏ 0, 5, 10, 20 mm. (a) : Modules des fonctions de transfert ⑤Hr♣f, zq⑤. (b) : modules ⑤Y ♣f, zq⑤. (c) : signaux temporels y♣t, zq, normalisés et de même retard de phase. (d) : fréquences centrales des échos en fonction de la distance de propagation. Les paramètres de l’écho gaussien hi♣tq sont A ✏ 1, f0 ✏ 5 MHz, σf ✏ 1, t0 ✏ 2.33 µs et φ ✏ 1.867 rad. contribution des fréquences négatives, nous avons donc pour les fréquences positives ⑤Y ♣f, zq⑤ ✏ ⑤Hi♣fq⑤e ✁α0f 2z ✏ A ✶ e ✁ ♣f✁f0q 2 2σ2 f e ✁α0f 2z ✏ A ✶ e ✁ f 2f 2 0 ✁2ff02α0f 2zσ2 f 2σ2 f ✏ A ✶ e ✁ f 2 0 f 2♣12α0σ 2 f zq✁2ff0 2σ2 f . (2.17) En posant f1♣zq ✏ f0 1 2α0σ 2 f z , (2.18) et σ ✶ f ♣zq ✏ σ 2 f 1 2α0σ 2 f z , (2.19) on aboutit à ⑤Y ♣f, zq⑤ ✏ A ✶ e ✁ f 2 0 ④♣12α0σ 2 f zqf 2✁2ff1♣zqf1♣zq 2✁f1♣zq 2 2σ✶ f ♣zq2 ✏ A ✶ e f1♣zq 2✁f 2 0 ④♣12α0σ 2 f zq 2σ✶ f ♣zq2 e ✁ ♣f✁f1♣zqq2 2σ✶ f ♣zq2 . (2.20) 322.1 Modèle de signaux continus pour une cible ponctuelle Pour une distance de propagation z, le module ⑤Y ♣f, zq⑤ est donc une gaussienne de fré- quence centrale f1♣zq et de variance σ ✶2 f ♣zq. Comme pour l’atténuation linéaire, la fréquence centrale de l’écho diminue lorsque la distance de propagation augmente, mais de façon plus significative. La largeur spectrale diminue également lorsque z augmente, effet qui n’apparaissait pas avec l’atténuation linéaire. Nous retrouvons ces effets sur la figure 2.5, qui reprend les mêmes simulations que dans la figure 2.4 dans le cas de l’atténuation quadratique. On remarque que ceux-ci sont plus accentués pour l’atténuation quadratique : baisse non-linéaire de la fréquence centrale et élargissement temporel dû à la baisse de la variance fréquentielle. 0 5 10 15 20 0 0.2 0.4 0.6 0.8 1 f [MHz] |Hr(f, z)| (a) Fonctions d’att´enuation z = 0mm z = 5mm z = 10mm z = 20mm 0 2 4 6 8 10 0 0.2 0.4 0.6 0.8 1 f [MHz] |Y (f, z)| (b) Spectres en module normalis´e des ´echos 1.5 2 2.5 3 −1 −0.5 0 0.5 1 t [µs] y(t,z) (c) Formes temporelles recal´ees et normalis´ees 0 5 10 15 20 1 2 3 4 5 6 z [mm] f1 [MHz] (d) Fr´equence centrale FIGURE 2.5 – Effets d’une atténuation quadratique avec α0 ✏ 50 Np.MHz✁2 .m✁1 pour plusieurs distances de propagation z ✏ 0, 5, 10, 20 mm. (a) : Module des fonctions de transfert ⑤Hr♣f, zq⑤. (b) : modules ⑤Y ♣f, zq⑤. (c) : signaux temporels y♣t, zq, normalisés et de même retard de phase. (d) : fréquences centrales des échos en fonction de la distance de propagation. Les paramètres de l’écho gaussien hi♣tq sont A ✏ 1, f0 ✏ 5 MHz, σf ✏ 1, t0 ✏ 2.33 µs et φ ✏ 1.867 rad. 2.1.4 La dispersion et les théories causales Le but est ici de décrire précisément Hr♣f, zq pour respecter la physique des ondes ultrasonores. En effet, l’atténuation et la dispersion jouent respectivement sur le module et la phase de Hr♣f, zq. La relation entre module et phase doit respecter le fait que la réponse impulsionnelle hr♣t, zq est réelle et causale. Tout d’abord, la réponse impulsionnelle correspondant à Hr♣f, zq doit être réelle, ce qui implique une symétrie hermitienne Hr♣✁f, zq ✝ ✏ Hr♣f, zq, où l’exposant ✝ indique le conjugué complexe. De ce fait, le nombre d’onde défini par l’équation (2.4) doit être à symétrie anti-hermitienne, signifiant que α♣fq est paire et β♣fq impaire. La dispersion est due au fait que la vitesse de propagation n’est pas constante en fonction de la fréquence de l’onde. Comme le montre l’équation (2.6), la dispersion provoque une 33CHAPITRE 2 : Le modèle direct distorsion de la phase en fonction de la distance et de la fréquence [Droin et al. 1998, Wear 2000, Haiat et al. 2006]. Dans les milieux homogènes, la seule cause de dispersion est l’atté- nuation décrite dans la partie précédente [Lee et al. 1990]. On parle dans ce cas d’atténuation dispersive. En effet, en présence d’atténuation (modification du module), la dispersion (modification de la phase) apparaît pour assurer la cohérence physique de la propagation. La dispersion joue donc un rôle équilibrant dans la fonction de transfert de propagation Hr♣f, zq. Plutôt que de mesurer la dispersion, il est d’usage de la déduire à partir de l’atténuation qui est décrite par un modèle fiable et relativement simple (équation (2.9)). Ce calcul met en jeu les théories causales des systèmes physiques développées pour les ondes électromagnétiques par Kramers et Kronig [Kronig 1926, Kramers 1927]. Nous allons maintenant étudier plusieurs modèles de phase de la fonction de transfert de propagation. Modèle à phase linéaire La première approche consiste à considérer une vitesse de phase constante c♣fq ✏ c0 [Carstensen et Schwan 1959]. Kak et Dines [1978] ont proposé un tel modèle pour une atténuation linéaire, aboutissant à une phase linéaire 2πfz④c0 dans la fonction de transfert. Cela correspond à un retard pur de t0 ✏ z④c0 pour chaque phase du signal. La vitesse c0 est également la vitesse de groupe. La fonction de transfert de propagation s’écrit alors Hr♣f, zq ✏ b♣zqe ✁α♣fqz e ✁j2πfz④c0 . (2.21) Dans le cas d’une atténuation linéaire α♣fq ✏ α0⑤f⑤, la réponse impulsionnelle correspondante pour b♣zq ✏ 1 est [Kak et Dines 1978] hr♣t, zq ✏ 1 π α0z④2π ♣α0z④2πq 2 ♣t ✁ z④c0q 2 . (2.22) Cette réponse est symétrique par rapport à t0 et est de ce fait non-causale (voir figure 2.7). La causalité Un système est causal si sa réponse impulsionnelle est strictement nulle pour les temps négatifs. Des conditions sont néanmoins nécessaires pour que Hr♣f, zq soit le spectre en module d’une fonction causale [Papoulis 1962], et que le calcul soit possible. Dans ce cas et pour notre problème, les parties réelles et imaginaires de Hr♣f, zq sont reliées par une paire de transformées de Hilbert pour que hr♣t, zq soit causale [Papoulis 1962] (voir le détail en annexe A.1). Premièrement, la fonction de transfert Hr♣f, zq doit être de carré intégrable [Papoulis 1962] ➺ ✽ ✁✽ ⑤Hr♣f, zq⑤2 df ➔ ✽. (2.23) Dans le cas d’une atténuation en loi de puissance ⑤Hr♣f, zq⑤ ✏ e ✁α0⑤f⑤ γz , ➺ ✽ ✁✽ ⑤Hr♣f, zq⑤2 df ✏ ➺ ✽ ✁✽ e ✁2α0⑤f⑤ γz df. (2.24) 342.1 Modèle de signaux continus pour une cible ponctuelle Cette intégrale est bien convergente pour γ → 0. Deuxièmement, Hr♣f, zq doit vérifier la relation de Paley-Wiener qui est une condition nécessaire et suffisante sur le module d’une fonction de transfert pour qu’il puisse définir une réponse impulsionnelle causale [Papoulis 1962] : ➺ ✽ ✁✽ ✞ ✞ ln ⑤Hr♣f, zq⑤ ✞ ✞ 1 f 2 df ➔ ✽. (2.25) Pour le modèle d’atténuation (2.9), nous avons ➺ ✽ ✁✽ ✞ ✞ ln ⑤Hr♣f, zq⑤ ✞ ✞ 1 f 2 df ✏ α0z ➺ ✽ ✁✽ ⑤f⑤ γ 1 f 2 df. (2.26) L’inégalité (2.25) est respectée seulement pour γ ➔ 1 [He 1999, Kelly et al. 2008, Szabo 1994], et donc hr♣t, zq n’est pas causale pour γ ➙ 1. En acoustique, plusieurs méthodes ont été développées pour calculer le terme de phase et se rapprocher d’une réponse impulsionnelle causale : le modèle nearly-local [O’Donnell et al. 1978], le modèle time-causal [Szabo 1994], le modèle à minimum de phase [Gurumurthy et Arthur 1982, Kuc 1983; 1984]. Ces modèles sont équivalents pour une atténuation linéaire [Gurumurthy et Arthur 1982, He 1999]. Nous avons choisi d’utiliser le modèle à minimum de phase car il a donné une bonne concordance avec des données expérimentales dans le cas d’une atténuation linéaire et non-linéaire [He 1999]. Il peut de surcroît être adapté à un modèle de signaux à temps discret [Kuc 1983; 1984, Oppenheim et Schafer 1989]. Définition d’un temps de vol minimal pour respecter la causalité En acoustique, la dispersion implique que la vitesse des ondes augmente avec la fréquence. Elle est appelée dispersion « anormale » (anomalous dispersion) en opposition à une dispersion « normale » (normal dispersion) pour laquelle la vitesse décroît avec la fréquence [Szabo 1995]. La dispersion « normale » est une convention établie pour les ondes électromagné- tiques. On peut donc considérer qu’il existe une vitesse c✽ obtenue lorsque fÑ ✽ [Kelly et al. 2008, Wang 2009]. Pour une distance de propagation z donnée, on a donc un temps de vol minimal t0 ✏ z④c✽. De ce fait, pour respecter la causalité, une onde émise à t ✏ 0 ne doit pas apparaître avant t0 pour une cible placée en z. On peut donc définir le nombre d’onde comme k♣fq ✏ 2πf c✽ ♣fq ✁ jα♣fq, (2.27) où ♣fq représente la partie dispersive de la propagation. La vitesse de phase s’écrit alors c♣fq ✏ ✂ 1 c✽ ♣fq 2πf ✡✁1 . (2.28) La fonction de transfert de propagation (2.6) peut de ce fait être exprimée suivant Hr♣f, zq ✏ b♣zqe ✁α♣fqz e ✁j2πfz④c✽e ✁j♣fqz . (2.29) Il est possible de regrouper les parties dépendant de l’atténuation et de la dispersion dans une même fonction de transfert : Ha♣f, zq ✏ e ✁α♣fqz e ✁j♣fqz , (2.30) 35CHAPITRE 2 : Le modèle direct le reste représentant le terme à phase linéaire b♣zqe ✁j2πfz④c✽, qui est la fonction de propagation sans atténuation, de fait causale. Ce découpage permet de séparer la partie propagation de la partie atténuation dispersive et sera utile pour construire le modèle numérique. Dans le domaine temporel, on a donc hr♣f, zq ✏ b♣zqδ♣t ✁ z④c✽q ✝ ha♣t, zq, (2.31) où ha♣t, zq est la réponse impulsionnelle correspondant à Ha♣f, zq. Modèle à phase dispersive pour les signaux à temps discret Dans le cas des signaux à temps continu, Gurumurthy et Arthur [1982] ont proposé, pour une atténuation linéaire, un modèle à minimum de phase [Papoulis 1962, Oppenheim et Schafer 1989] pour calculer la partie dispersive de Ha♣f, zq. Une fonction à minimum de phase indique que sa réponse impulsionnelle est causale et a un retard de phase minimal par rapport à l’origine [Oppenheim et Schafer 1989]. Pour respecter la condition de Paley-Wiener et calculer la phase, Gurumurthy et Arthur considèrent une fréquence au-delà de laquelle l’atténuation est sous-linéaire (γ ➔ 1). C’est un artifice de calcul permettant de satisfaire la condition aux limites (2.25). La partie dispersive ♣fq a alors une formulation analytique [Gurumurthy et Arthur 1982]. Ce modèle est équivalent à ceux établis par O’Donnell et al. [O’Donnell et al. 1978] et Szabo [Szabo 1994] dans le cas de l’atténuation linéaire [He 1999]. Le calcul de cette phase est également possible en considérant des signaux à temps discret pour une atténuation α♣fq quelconque [Oppenheim et Schafer 1989, Kuc 1984] : ♣fq ✏ ✁ 1 fS P ➺ fS 2 ✁ fS 2 α♣gq cot ✂ π fS ♣f ✁ gq ✡ dg, (2.32) où fS est la fréquence d’échantillonnage et P est la valeur principale de Cauchy de l’inté- grale3 . Le détail du calcul de l’équation (2.32) est donné en annexe A.2. Kuc a utilisé ce modèle pour calculer des réponses impulsionnelles de propagation pour une atténuation linéaire [Kuc 1983; 1984]. C’est ce modèle, parfaitement applicable à un modèle d’atténuation non-linéaire [He 1999], que nous utilisons dans notre modèle d’atténuation dispersive. Pour un modèle d’atténuation en loi de puissance (2.9), la phase s’écrit ♣fq ✏ ✁α0 fS P ➺ fS 2 ✁ fS 2 ⑤g⑤ γ cot ✂ π fS ♣f ✁ gq ✡ dg. (2.33) C’est la formulation courante de la littérature et qui est approchée par intégration numé- rique. Nous avons néanmoins montré que, pour γ ✏ 1, l’intégrale (2.33) a une expression analytique [Carcreff et al. 2014b], développée en annexe A.2.1 ♣fq ✏ ✁α0fS π 2 ✒ Cl2 ✂ 2πf fS π ✡ ✁ Cl2 ✂ 2πf fS ✡✚ , (2.34) 3La valeur principale de Cauchy de l’intégrale de f♣xq qui a une singularité en a est définie par P ➺ ✽ ✁✽ f♣xqdx ✏ limÑ0 ✂➺ a✁ ✁✽ f♣xqdx ➺ ✽ a f♣xqdx ✡ . 362.1 Modèle de signaux continus pour une cible ponctuelle où Cl2 est la fonction de Clausen à l’ordre 2 [Maximon 2003]. Nous montrons des exemples de calculs numériques dans la partie 2.2.4. Sur la figure 2.6a, un exemple de phase dispersive est donné, pour une atténuation linéaire (γ ✏ 1) et pour différentes valeurs de α0. L’équation (2.33) montre que la phase ♣fq est −500 0 500 0 0.2 0.4 0.6 0.8 1 f [MHz] |Ha(f)| (a) Module −500 0 500 −20 −15 −10 −5 0 5 10 15 20 f [MHz] ǫ(f) [rad] (b) Phase 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0.2 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 t [µs] ha(t) (c) R´eponse impulsionnelle α0 = 10 Np/m/MHz α0 = 50 Np/m/MHz α0 = 100 Np/m/MHz FIGURE 2.6 – Exemples de modèles à atténuation linéaire et phase dispersive pour plusieurs valeurs du coefficient d’atténuation α0 ✏ 10, 50, 100 Np.MHz✁1 .m✁1 et pour une distance de propagation z ✏ 1 mm. (a) : Modules ⑤Ha♣f, zq⑤ ✏ e ✁α0⑤f⑤z , (b) : phases ♣fq, (c) : réponses impulsionnelles ha♣t, zq obtenues par tranformée de Fourier inverse de Ha♣f, zq ✏ e ✁α0⑤f⑤z e ✁♣fqz . linéaire en fonction de α0, ce qui est vérifié dans la figure 2.6b. Les réponses impulsionnelles obtenues par transformées de Fourier inverse sont également tracées sur la figure 2.6c. On peut vérifier qu’elles sont causales. Il est également à noter que le retard de groupe augmente avec α0. Comparaison des réponses impulsionnelles Nous comparons ici les réponses impulsionnelles hr♣t, zq obtenues par trois modèles d’atté- nuation : 1. sans atténuation et phase linéaire : Hr♣f, zq ✏ b♣zqe ✁j2πfz④c0 2. avec atténuation linéaire et phase linéaire : Hr♣f, zq ✏ b♣zqe ✁α0⑤f⑤z e ✁j2πfz④c0 3. avec atténuation linéaire et phase dispersive : Hr♣f, zq ✏ b♣zqe ✁α0⑤f⑤z e ✁j2πfz④c✽e ✁j♣fqz 37CHAPITRE 2 : Le modèle direct Les modèles 1 et 2 ont des réponses impulsionnelles analytiques, respectivement b♣zqδ♣t ✁ z④c0q et la réponse de l’équation (2.22), tandis que celle du modèle 3 est calculée numériquement par transformée de Fourier inverse de Hr♣f, zq. Arbitrairement, la vitesse c✽ est réglée à la vitesse de groupe c0 ✏ 2000 m.s✁1 . Ce réglage nous permet de mieux observer la causalité. Dans la réalité, c0 → c✽, comme nous le verrons dans la section expérimentale 2.3 à la fin de ce chapitre. La cible est placée à une distance z ✏ 1 mm avec une amplitude b♣zq ✏ 1. Les trois réponses sont tracées sur la figure 2.7. La réponse sans atténuation est une impulsion 0.4 0.5 0.6 0.7 0 1 t [µs] hr(t, z) sans att´enuation phase lin´eaire phase dispersive FIGURE 2.7 – Réponses impulsionnelles simulées hr♣t, zq en utilisant trois modèles : sans atténuation, avec atténuation et phase linéaires, et avec atténuation linéaire et phase dispersive. Paramètres : c0 ✏ c✽ ✏ 2000 m.s✁1 , γ ✏ 1, α0 ✏ 50 Np.MHz✁1 .m✁1 , z ✏ 1 mm et b♣zq ✏ 1. Le temps de vol minimal est t0 ✏ z④c✽ ✏ 0.5 µs. placée en t0 ✏ z④c0 ✏ 0.5 µs. Nous observons que la réponse avec une phase linéaire a une forme symétrique, des deux côtés de t0, et est donc non-causale (cf. équation (2.22)). La ré- ponse avec dispersion apparaît causale, même si elle ne l’est pas au sens strict car elle viole la condition de Paley-Wiener (2.25). On observe cependant que le signal est nul numériquement avant t0. Nous étudierons le calcul numérique de cette réponse impulsionnelle dans la partie 2.2.4. 2.2 Modèle discret linéaire pour l’inversion 2.2.1 Modèle de signaux à temps continu pour une distribution de cibles Le milieu est maintenant considéré comme ayant une distribution quelconque continue b♣zq de cibles. À partir des équations (2.8) et (2.31), le signal temporel reçu est la somme des contributions de toutes les cibles y♣tq ✏ ➺ z hi♣tq ✝ hr♣t, zqdz ✏ ➺ z b♣zqhi♣tq ✝ ha♣t ✁ z④cref, zqdz ✏ ➺ z b♣zq ✂➺ τ hi♣t ✁ τ qha♣τ ✁ z④cref, zqdτ ✡ dz, (2.35) où z définit la distance de propagation et b♣zq le contenu en amplitude de la distribution. La vitesse de référence appelée cref permet de s’adapter à plusieurs modèles. Pour un modèle 382.2 Modèle discret linéaire pour l’inversion causal, il faut utiliser cref ✏ c✽, où c✽ est la vitesse de phase pour les fréquences tendant vers l’infini. Pour un modèle basé sur la vitesse de groupe, on emploie cref ✏ c0. Le but de l’inversion est d’estimer b♣zq à partir d’une version échantillonnée de y♣tq. La reconstruction est plus efficace si des connaissances sont disponibles a priori sur la distribution spatiale. Nous détaillons dans le chapitre suivant un modèle spécifique de distribution. 2.2.2 Modèle de signaux à temps discret Modèle générique Nous considérons un signal à temps discret yrns ✏ y♣nTSq, n ✏ 0, . . . , Ny ✁ 1 où TS ✏ 1④fS est la période d’échantillonnage. A partir de l’équation (2.35), ce signal s’écrit yrns ✏ y♣nTSq ✏ ➺ z b♣zq ➺ τ hi♣nTS ✁ τ qha♣τ ✁ z④cref, zqdτdz. (2.36) Pour généraliser l’écriture et ne pas être limité par la résolution de l’échantillonnage, nous discrétisons l’intégrale de la convolution temporelle (intégrale par rapport à τ ) par la méthode des rectangles avec un pas constant ∆t . Nous posons τ ✏ m∆t et aboutissons à : yrns ✔ ➺ z b♣zq∆t ➳ m hi♣nTS ✁ m∆tqha ✂ m∆t ✁ z cref , z✡ dz ✔ ∆t ➳ m hi♣nTS ✁ m∆tq ➺ z b♣zqha ✂ m∆t ✁ z cref , z✡ dz. (2.37) D’une façon similaire, l’intégrale spatiale est discrétisée en posant z ✏ p∆z : yrns ✔ ∆t∆z ➳ m hi♣nTS ✁ m∆tq ➳ p b♣p∆zqha ✂ m∆t ✁ p∆z cref , p∆z ✡ . (2.38) Modèle discret sur-échantillonné Nous définissons maintenant les pas ∆t et ∆z comme des multiples du pas de référence qui est la période d’échantillonnage. Le but de ce formalisme est de pouvoir régler la résolution de reconstruction d’une façon arbitraire, mais toujours pour des multiples de TS qui est fixé par les données. Il y a donc un facteur de sur-échantillonnage K à choisir et qui définit les résolutions du modèle ∆t ✏ TS K , (2.39) et ∆z ✏ crefTS K . (2.40) Nous aboutissons à yrns ✔ ∆t∆z ➳ m hi ♣nK ✁ m∆tq ➳ p b ♣p∆zq ha ♣♣m ✁ pq∆t , p∆zq. (2.41) 39CHAPITRE 2 : Le modèle direct Modèle compact Nous notons maintenant les signaux à temps discret ✩ ✫ ✪ hirms ✏ hi♣m∆tq har`, ps ✏ ha♣`∆t , p∆zq xrps ✏ ∆t∆zb♣p∆zq. (2.42) L’équation (2.41) devient alors yrns ✔ ➳ m hirnK ✁ ms ➳ p harm ✁ p, psxrps. (2.43) Nous considérons les vecteurs y ✏ ✑ yr0s ☎ ☎ ☎ yrNy ✁ 1s ✙T , (2.44) x ✏ ✑ xr0s ☎ ☎ ☎ xrNx ✁ 1s ✙T , (2.45) hi ✏ ✑ hir0s ☎ ☎ ☎ hirNh ✁ 1s ✙T , (2.46) et ha♣zpq ✏ ✑ har0, ps ☎ ☎ ☎ harNx ✁ 1, ps ✙T , (2.47) où T symbolise la transposition. Les tailles Nx et Ny ne sont pas nécessairement égales, Nx dépendant des hypothèses de bord de la convolution [Idier 2001]. Nous montrerons dans la partie 2.2.3 plusieurs conventions qui relient Nx à Ny et Nh. L’équation (2.43) peut alors se mettre sous la forme compacte : y ✏ HiHax ✏ Gx, (2.48) où Hi P R Ny✂Nx est la matrice de convolution correspondant à la réponse instrumentale hi . Pour K ✏ 1, cette matrice a une structure de Toeplitz [Gray 2006], c’est-à-dire que les diagonales sont composées de valeurs identiques. Pour K → 1, nous verrons qu’elle correspond, à un ordonnancement près des colonnes, à la concaténation de K matrices de Toeplitz. Ha P R Nx✂Nx est la matrice d’atténuation composée des réponses impulsionnelles ha♣zpq pour chaque colonne p ✏ 0, . . . , Nx ✁ 1. La matrice G P R Ny✂Nx combine à la fois les effets de l’instrument et de la propagation dans le milieu. Le modèle des données (2.48) est donc linéaire par rapport à x qui est l’inconnue du problème inverse. Nous détaillons ci-après plusieurs formalismes de modèle. 2.2.3 Différents cas pour le modèle linéaire discret Cas sans atténuation et sans sur-échantillonnage Dans le cas sans atténuation, la réponse impulsionnelle d’atténuation est une impulsion de Dirac : ha♣t ✁ z④cref, zq ✏ δ♣t ✁ z④crefq. Sans sur-échantillonnage (K ✏ 1), le pas de discré- tisation ∆t est réglé à la période d’échantillonnage : ∆t ✏ TS. L’équation discrète (2.43) devient de ce fait yrns ✔ ➳ m hirn ✁ ms ➳ p harm ✁ p, psxrps ✏ ➳ m hirn ✁ msxrms, (2.49) 402.2 Modèle discret linéaire pour l’inversion qui est équivalent à un produit de convolution discrète. A partir de l’équation (2.49), chaque élément yrns est donc le produit scalaire euclidien entre h T i retournée et x. Dans le modèle matriciel, chaque ligne contient donc une version retournée de hi . On obtient alors y ✏ Hix, (2.50) où la matrice Hi est de Toeplitz et peut être définie suivant des conditions de bords particulières en fonction des hypothèses sur le signal x. La matrice complète qui ne fait aucune hypothèse hors du support de x est donc Hi ✏ ✔ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✕ hirNh ✁ 1s ☎ ☎ ☎ ☎ ☎ ☎ hir0s hirNh ✁ 1s ☎ ☎ ☎ . . . . . . 0 . . . . . . ☎ ☎ ☎ hir0s hirNh ✁ 1s ☎ ☎ ☎ . . . . . . . . . . . . ☎ ☎ ☎ hir0s 0 hirNh ✁ 1s ☎ ☎ ☎ ☎ ☎ ☎ hir0s ✜ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✢ . (2.51) La taille de x est donc Nx ✏ Ny Nh ✁ 1. Dans le cadre d’un problème inverse où il faut retrouver x, le problème est sous-déterminé. On peut également utiliser une formulation qui considère x nul au-delà de ses bornes. La matrice devient alors Hi ✏ ✔ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✕ hir0s 0 . . . hir0s hirNh ✁ 1s . . . . . . hirNh ✁ 1s . . . hir0s 0 . . . . . . hirNh ✁ 1s ✜ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✢ , (2.52) définissant un problème sur-déterminé avec Nx ✏ Ny ✁ Nh 1. De plus, chaque colonne a la même norme, ce qui simplifie les calculs de certains algorithmes. Cette forme de matrice ainsi que le modèle (2.50) constituent la formulation classique des problèmes de déconvolution [O’Brien et al. 1994, Olofsson et Stepinski 2000, Idier 2001]. Les propositions de solutions – chaque colonne de Hi – sont donc des répliques de hi pour n’importe quelle distance de propagation. Cas sans atténuation et avec sur-échantillonnage Dans ce cas, le pas de discrétisation ∆t est réglé comme un multiple de la période d’échantillonnage tel que ∆t ✏ TS④K avec K → 1. L’équation discrète (2.43) devient yrns ✔ ➳ m hirnK ✁ ms ➳ p harm ✁ p, psxrps ✏ ➳ m hirnK ✁ msxrms, (2.53) qui n’est plus un produit de convolution discrète. Nous avons toujours le modèle (2.50) : y ✏ Hix, mais la matrice Hi n’est plus Toeplitz. Les lignes sont toujours des versions retournées de hi mais avec un décalage de K zéros entre chaque ligne. Par exemple, pour 41CHAPITRE 2 : Le modèle direct K ✏ 2, la matrice Hi similaire à celle de l’équation (2.51) (y est nul en dehors de ses bornes) est Hi ✏ ✔ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✕ hirNh ✁ 1s hirNh ✁ 2s hirNh ✁ 3s ☎ ☎ ☎ hir0s 0 0 ☎ ☎ ☎ 0 0 hirNh ✁ 1s ☎ ☎ ☎ hir2s hir1s hir0s 0 ☎ ☎ ☎ 0 0 0 ☎ ☎ ☎ hir4s hir3s hir2s hir1s ☎ ☎ ☎ ☎ ☎ ☎ hir6s hir5s hir4s hir3s ☎ ☎ ☎ . . . . . . . . . ☎ ☎ ☎ hir8s hir7s hir6s hir5s ☎ ☎ ☎ . . . . . . . . . . . . ☎ ☎ ☎ ✜ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✢ , (2.54) avec Nx ✏ K♣Ny ✁ 1q Nh. Dans le cas de l’équation (2.52), où x est nul en dehors de ses bornes, Hi s’écrit Hi ✏ ✔ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✕ hir0s 0 0 ☎ ☎ ☎ hir2s hir1s hir0s 0 ☎ ☎ ☎ hir4s hir3s hir2s hir1s hir0s 0 ☎ ☎ ☎ . . . . . . . . . . . . . . . . . . . . . . . . ☎ ☎ ☎ 0 hirNh ✁ 1s hirNh ✁ 2s hirNh ✁ 3s hirNh ✁ 4s hirNh ✁ 5s ☎ ☎ ☎ 0 hirNh ✁ 1s hirNh ✁ 2s hirNh ✁ 3s ☎ ☎ ☎ 0 hirNh ✁ 1s ✜ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✣ ✢ , (2.55) avec Nx ✏ K♣Ny ✁ Nh ✁ 1q 2. D’une manière générale, le vecteur x est donc environ K fois plus grand que le vecteur y. Un exemple de matrices Hi est représenté sur la figure 2.8, pour K ✏ 1 et K ✏ 4 (au format de la matrice 2.55). On remarque que le nombre de colonnes est environ K fois supérieur pour la matrice de droite. Hi (K ✏ 1) Hi (K ✏ 4) FIGURE 2.8 – Exemple de matrices Hi pour K ✏ 1 (gauche) et pour K ✏ 4 (droite). En observant les matrices (2.54) et (2.55), on remarque que toutes les K colonnes sont identiques à un décalage vertical près. On peut alors montrer que l’équation (2.53) est équivalente à K convolutions discrètes [Carcreff et al. 2012; 2013b;a] yrns ✔ ➳ K k✏1 ➳ m h k i rn ✁ msxrms, (2.56) où h k i est défini comme un sous-vecteur de hi . A partir de l’équation (2.42), on peut montrer que h k i r`s ✏ hirK` k ✁ 1s ✏ hi ♣`TS ♣k ✁ 1q∆tq. (2.57) 422.2 Modèle discret linéaire pour l’inversion Le vecteur h k i correspond donc à une résolution temporelle TS et est décalé d’un pas♣k ✁ 1q∆t . L’entrelacement des h k i forme de ce fait le vecteur hi . D’une façon analogue, la matrice Hi peut être décomposée en K sous-matrices de convolution Hk i pour k ✏ 1 . . . K, menant à y ✏ Hix ✏ ➳ K k✏1 Hk i x k , (2.58) où x k est le sous-vecteur de x, correspondant aux colonnes de Hk i par rapport à Hi . Les données y peuvent donc être modélisées par un système à plusieurs entrées et une sortie unique (Multiple Input Single Output : MISO). Le chapitre 4 est dédié au modèle et aux algorithmes adaptés à de tels systèmes MISO. Cas avec atténuation et sans sur-échantillonnage L’équation discrète (2.43) devient yrns ✔ ➳ m hirn ✁ ms ➳ p harm ✁ p, psxrps, (2.59) qui peut, comme nous l’avons montré, s’écrire y ✏ HiHax. Des formes similaires apparaissent également dans [Hale 1981, Olofsson et Stepinski 2001, Lingvall et al. 2003]. La matrice de convolution Hi peut prendre les mêmes formes que dans le cas sans atténuation. La « convolution » ➦ p harm ✁ p, psxrps est quant à elle non-stationnaire, car la réponse impulsionnelle ha a une forme différente pour chaque colonne p [Margrave 1998]. La matrice d’atténuation s’écrit alors : Ha ✏ ✔ ✖ ✖ ✖ ✖ ✖ ✕ har0, 0s har✁1, 1s har✁2, 2s ☎ ☎ ☎ har✁Nx 1, Nx ✁ 1s har1, 0s har0, 1s har✁1, 2s ☎ ☎ ☎ har✁2, Nx ✁ 1s har2, 0s har1, 1s har0, 2s ☎ ☎ ☎ har✁2, Nx ✁ 1s . . . . . . . . . . . . . . . harNx ✁ 1, 0s harNx ✁ 2, 1s harNx ✁ 3, 2s ☎ ☎ ☎ har0, Nx ✁ 1s ✜ ✣ ✣ ✣ ✣ ✣ ✢ . (2.60) Dans le cas où les réponses d’atténuation sont causales, la matrice Ha est triangulaire infé- rieure. Un exemple de matrices Hi et Ha est représenté sur la figure 2.9. La matrice instrumentale Hi est Toeplitz. La matrice Ha montre les réponses impulsionnelles d’atténuation générées avec une atténuation linéaire et une phase dispersive. 2.2.4 Calcul numérique des réponses impulsionnelles d’atténuation Si le modèle avec atténuation dispersive (2.30) est utilisé pour définir l’atténuation, la ré- ponse impulsionnelle ha♣zq est approchée par transformée de Fourier discrète inverse de Ha♣f, zq. La transformée de Fourier discrète est calculée pour f P r✁fD④2, fD④2s et est composée de Nf points. Elle est donc dépendante de deux paramètres qui sont fD et Nf . La fréquence de discrétisation fD est définie grâce à la résolution temporelle du modèle ∆t , telle que fD ✏ 1 ∆t ✏ KfS, (2.61) 43CHAPITRE 2 : Le modèle direct Hi Ha G ✏ HiHa FIGURE 2.9 – Exemple de matrices Hi , Ha et G, où chaque colonne a été normalisée. où fS est la fréquence d’échantillonnage définie par les données et K est le facteur de sur- échantillonnage du modèle. Le premier problème dans le calcul des réponses impulsionnelles concerne la résolution temporelle. Le deuxième problème vient du fait que la discrétisation de l’axe des fréquences entraîne une périodicité du signal temporel. Dans la mesure du possible, il faut disposer d’un nombre de points conséquent pour éviter le repliement temporel. Nous illustrons ces deux problèmes par des exemples simples dans la suite. Influence de la résolution temporelle Nous étudions l’influence de la résolution temporelle sur le calcul de ha♣zq, en utilisant un modèle d’atténuation linéaire avec α0 ✏ 50 Np.MHz✁1 .m✁1 et une distance z ✏ 10 mm. Le nombre de points de l’axe fréquentiel est fixé à Nf ✏ 256. En utilisant des résolutions temporelles ∆t ✏ 0.1 µs, 0.05 µs, 0.02 µs, les réponses impulsionnelles obtenues sont tracées sur la figure 2.10. Il est logique que la résolution temporelle soit plus fine lorsque ∆t diminue. On remarque aussi que la causalité est « plus » marquée quand ∆t diminue. Dans le modèle de signaux (2.48), il y a donc un intérêt certain à utiliser une discrétisation fine, par augmentation de la fréquence d’échantillonnage ou par sur-échantillonnage. Influence du nombre de points de la transformée de Fourier discrète Nous reprenons les mêmes simulations que précédemment mais avec ∆t ✏ 0.02 µs et en faisant varier la nombre de points fréquentiels Nf ✏ 64, 128, 256. Les réponses impulsionnelles correspondantes sont tracées sur la figure 2.11. Le repliement temporel crée une continuité entre les indices k ✏ 0 et k ✏ Nf ✁ 1. Pour Nf ✏ 64, la fonction ne descend pas suffisamment vers zéro et empêche donc la réponse d’être causale. Lorsque Nf augmente, les réponses tendent de plus en plus vers une fonction causale. Le nombre de points de calcul de la transformée Ha♣f, zq doit donc être le plus grand possible pour que la réponse ha♣zq tende vers une fonction causale. 442.2 Modèle discret linéaire pour l’inversion 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 ∆t = 0.1 µs ha[k, z] µs 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 ∆t = 0.05 µs ha[k, z] µs 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 ∆t = 0.02 µs ha[k, z] µs FIGURE 2.10 – Etude de l’influence de ∆t dans le calcul des réponses impulsionnelles ha♣zq obtenues par transformée de Fourier discrète inverse de Ha♣f, zq. Paramètres : γ ✏ 1, α0 ✏ 50 Np.MHz✁1 .m✁1 , z ✏ 20 mm, Nf ✏ 256, ∆t ✏ 0.1 µs, 0.05 µs, 0.02 µs. 2.2.5 Modèle d’atténuation d’Olofsson A partir de l’équation (2.6), la fonction de transfert de propagation pour zp ✏ p∆z peut s’écrire Hr♣f, zpq ✏ b♣zpqe ✁♣α♣fqjβ♣fqqp∆z ✏ b♣zpq ✏ e ✁♣α♣fqjβ♣fqq∆z ✘p ✏ b♣zpqP♣fq p . (2.62) Mise à part la constante b♣zpq, la fonction Hr♣f, zpq est donc équivalente à un noyau fréquentiel P♣fq à la puissance p. Si ρ est la réponse impulsionnelle à temps discret correspondant à P♣fq pour f P r✁fS④2, fS④2s, elle représente le changement entre deux couches élé- mentaires séparées par ∆z. La réponse impulsionnelle totale pour une distance zp ✏ p∆z correspond donc à p ✁ 1 auto-convolutions de ρ que nous notons hr♣t, zpq ✏ ρ ✝p ✏ ρ ❧♦♦♦♦♦♦♠♦♦♦♦♦♦♥ ✝ ρ ✝ . . . ✝ ρ p ✁ 1 auto-convolutions . (2.63) Olofsson et Stepinski ont proposé d’utiliser un noyau ρ très proche d’une impulsion de Dirac de façon à synthétiser une faible distorsion entre deux couches élémentaires [Olofsson et 45CHAPITRE 2 : Le modèle direct 32 64 Nf = 64 ha[k, z] k 32 64 96 128 Nf = 128 ha[k, z] k 32 64 96 128 160 192 224 256 Nf = 256 ha[k, z] k FIGURE 2.11 – Etude de l’influence de Nf dans le calcul des réponses impulsionnelles ha♣zq obtenues par transformée de Fourier discrète inverse de Ha♣f, zq. Paramètres : γ ✏ 1, α0 ✏ 50 Np.MHz✁1 .m✁1 , z ✏ 20 mm, fS ✏ 50 MHz, Nf ✏ 64, 128, 256. Stepinski 2001] ρ ✏ ✔ ✖ ✖ ✖ ✖ ✖ ✕ 0 1 ✁ a a 0 . . . ✜ ✣ ✣ ✣ ✣ ✣ ✢ , (2.64) avec a ✦ 1. On peut montrer que la transformée de Fourier de ρ est P♣fq ✏ 1 ✁ a ae✁j2π∆tf ✏ 1 ✁ a a♣cos 2π∆tf ✁ j sin 2π∆tfq. (2.65) On a alors le module au carré ⑤P♣fq⑤2 ✏ ♣1 ✁ a a cos 2π∆tfq 2 ♣a sin 2π∆tfq 2 ✏ 1 2a♣a ✁ 1q♣1 ✁ cos 2π∆tfq ✏ 1 ✁ 4a♣1 ✁ aqsin2 ♣π∆tfq. (2.66) Le module de la transformée de Fourier s’écrit alors ⑤P♣fq⑤ ✏ ❜ 1 ✁ 4a♣1 ✁ aqsin2 ♣π∆tfq, (2.67) 462.3 Exploitation des modèles qui, à partir de l’équation (2.62), correspond à une fonction d’atténuation de la forme α♣fq ✏ ✁ln ⑤P♣fq⑤ ∆z . (2.68) Enfin, la phase arg P♣fq ✏ β♣fq∆z permet de déduire la vitesse de phase c♣fq ✏ ✁ 2πf∆z arg P♣fq . (2.69) Sur la figure 2.12, nous comparons les noyaux P♣fq calculés avec l’atténuation linéaire ⑤P♣fq⑤ ✏ e ✁α0⑤f⑤∆z et par le modèle d’Olofsson (2.67). Les paramètres sont réglés de façon à donner des allures semblables aux fonctions P♣fq. Sur la figure 2.13, nous traçons un ensemble de fonctions de transfert de propagation avec le modèle d’Olofsson. En comparaison avec la figure 2.3 page 29, malgré un noyau semblable, nous observons des profils d’atténuation relativement différents. Le choix d’un tel modèle est plutôt empirique, car l’atténuation ne respecte pas un modèle physique de loi d’atténuation. L’avantage de ce modèle est qu’il −25 −20 −15 −10 −5 0 5 10 15 20 25 0.85 0.9 0.95 1 f (MHz) |P(f)| lin´eaire Olofsson FIGURE 2.12 – Comparaison des noyaux fréquentiels ⑤P♣fq⑤ pour l’atténuation linéaire (α0 ✏ 50 Np.MHz✁1 .m✁1 ) et pour le modèle d’Olofsson (a ✏ 0.06). ne dépend que d’un seul paramètre a. Il est défini dans le domaine temporel et est automatiquement causal grâce à la présence du premier zéro dans l’équation (2.64). Par conséquent, il n’y a pas de dispersion à régler, car elle est intégrée dans les réponses temporelles. La matrice Ha se construit donc simplement en plaçant la p ✁ 1 ème auto-convolution ρ ✝p à la colonne p Ha ✏ ✏ ρ ✝1 ρ ✝2 ρ ✝2 ☎ ☎ ☎ ✘ ✏ ✔ ✖ ✖ ✖ ✕ ρ ✝1 0 0 0 ☎ ☎ ☎ ρ ✝1 1 ρ ✝2 1 0 ☎ ☎ ☎ ρ ✝1 2 ρ ✝2 2 ρ ✝3 2 ☎ ☎ ☎ . . . . . . . . . . . . ✜ ✣ ✣ ✣ ✢ . (2.70) Par convention, la première colonne ρ ✝1 est une impulsion de Dirac discrète r1, 0, . . .s T . 2.3 Exploitation des modèles d’atténuation et de dispersion avec des données expérimentales Dans cette section, nous comparons les modèles décrits précédemment à l’aide de données expérimentales. Dans un premier temps, nous mesurons l’atténuation et la vitesse des ondes 47CHAPITRE 2 : Le modèle direct 0 2 4 6 8 10 −20 −10 0 10 20 0 0.2 0.4 0.6 0.8 1 f (MHz) z (mm) |H r(f, z)| FIGURE 2.13 – Exemple de fonction d’atténuation ⑤Hr♣f, zq⑤ en fonction de la fréquence et de la distance de propagation. Le noyau d’Olofsson (2.64) est défini avec a ✏ 0.06 pour générer le modèle d’atténuation (2.62). grâce à des échos atténués. Ces profils expérimentaux sont comparés à ceux produits par les modèles. Nous appliquons cette comparaison pour un matériau ayant une atténuation linéaire, le polycarbonate, et un matériau avec une atténuation non-linéaire, l’huile de ricin. Cette partie montre de ce fait comment mesurer les paramètres nécessaires pour régler les modèles. Nous montrons également la modélisation d’un signal transmis par un matériau hé- térogène, une mousse poreuse. Un deuxième exemple est l’évaluation non destructive d’un matériau. Nous montrons qu’il est possible de déduire le coefficient d’atténuation et la vitesse des ondes grâce aux modèles développés. Pour finir, nous exposons une des limites du modèle proposé dans le cas de la modélisation de l’écho provenant d’un trou à fond plat. 2.3.1 Mesure en mode pulse-echo avec du polycarbonate Pour vérifier expérimentalement la précision du modèle, nous réalisons une mesure en mode pulse-echo avec une plaque de polycarbonate d’épaisseur e ✏ 10.2 mm, comme illustré sur la Figure 2.14. Le polycarbonate présente une forte atténuation, et qui peut être considérée eau transducteur d pi`ece D FIGURE 2.14 – Schéma du dispositif expérimental d’une mesure en mode pulse-echo. linéaire en fréquence [Selfridge 1985]. Le transducteur utilisé a une surface plane circulaire de diamètre 12.7 mm et une fréquence centrale de 2.25 MHz. La plaque de polycarbonate 482.3 Exploitation des modèles est placée dans le champ lointain du transducteur en incidence normale. Les données sont échantillonnées à la fréquence fS ✏ 100 MHz et moyennées sur 100 réalisations pour réduire le niveau de bruit. Le signal reçu par le transducteur est représenté sur la figure 2.15a. Il contient un écho de surface et un écho de fond que nous notons respectivement yf et yb et que nous séparons manuellement. Ils sont respectivement représentés sur les figures 2.15b et 2.15c. Les transformées de Fourier normalisées de ces deux échos Yf ♣fq et Yb♣fq sont également représentées en module sur la figure 2.15d. On remarque le décalage quasiment uniforme vers les basses fréquences de la forme spectrale, qui sous-entend une atténuation linéaire. 0 1 2 3 4 5 6 7 8 9 10 11 −1 −0.5 0 0.5 1 t [µs] y (a) Donn´ees 0 1 2 3 −1 −0.5 0 0.5 1 t [µs] yf (b) Echo de surface ´ 8 9 10 11 −0.05 0 0.05 t [µs] yb (c) Echo de fond ´ 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 0 0.5 1 f [MHz] |Yf (f)|, |Yb(f)| (d) Spectres en module normalis´es ´echo de surface |Yf (f)| ´echo de fond |Yb(f)| FIGURE 2.15 – Signaux temporels et fréquentiels acquis à partir d’une plaque de polycarbonate de 10.2 mm d’épaisseur avec un transducteur à 2.25 MHz. (a) : Données, (b) : écho de surface, (c) : écho de fond, (d) : spectres en module. Le but est de vérifier la modélisation de l’écho de fond à partir de l’écho de surface et des modèles d’atténuation présentés dans ce chapitre. Pour cela, il faut dans un premier temps mesurer les paramètres des modèles : α0 et γ pour l’atténuation, c0 ou c✽ pour la vitesse de phase et le paramètre a pour le modèle d’Olofsson. A partir de l’équation (2.6), la transformée de Fourier de l’écho de surface yf s’écrit Yf ♣fq ✏ b♣2DqHi♣fqe ✁♣αw♣fqjβw♣fqq2D, (2.71) où ✁αw♣fq et βw♣fq sont respectivement les parties imaginaire et réelle du nombre d’onde dans l’eau. Pour simplifier, nous considérons b♣2Dq ✏ 1 comme l’amplitude de référence. D’une façon similaire, l’écho de fond yb est défini dans le domaine fréquentiel par Yb♣fq ✏ b♣2D 2dqHi♣fqe ✁♣αw♣fqjβw♣fqq2D✁♣α♣fqjβ♣fqq2d , (2.72) 49CHAPITRE 2 : Le modèle direct avec ✁α♣fq et β♣fq respectivement les parties imaginaire et réelle du nombre d’onde dans le polycarbonate. Le coefficient b♣2D 2dq est l’amplitude de l’écho de fond. Calcul de l’atténuation Le rapport des modules de Yb♣fq et Yf ♣fq caractérise la fonction de transfert pour une distance égale au double de l’épaisseur de la plaque, dans la bande passante du transducteur. Ce calcul permet de s’affranchir du terme Hi♣fq et de la propagation dans l’eau ⑤Yb♣fq⑤ ⑤Yf ♣fq⑤ ✏ b♣2D 2dqe ✁α♣fq2d . (2.73) En prenant le logarithme naturel de cette fonction, on aboutit à ln ✂ ⑤Yb♣fq⑤ ⑤Yf ♣fq⑤✡ ✏ ln ⑤b♣2D 2dq⑤ ✁ α♣fq2d. (2.74) Cette équation permet de déduire l’atténuation α♣fq à partir de la mesure des modules ✁ 1 2d ln ✂ ⑤Yb♣fq⑤ ⑤Yf ♣fq⑤✡ ✏ ✁ 1 2d ln ⑤b♣2D 2dq⑤ α♣fq. (2.75) Le tracé de ✁1④2d ln ♣⑤Yb♣fq⑤④⑤Yf ♣fq⑤q sur la figure 2.16 permet d’identifier α♣fq dans la bande de fréquences du transducteur. Cette fonction peut être considérée comme linéaire- 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3 3.2 3.4 20 40 60 80 100 120 140 160 180 200 f [MHz] [Np/m] (a) Att´enuation 53.50f − 1 2d ln|Yb(f)/Yf (f)|) r´egression mod`ele Olofsson 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 3 3.2 3.4 2255 2260 2265 2270 2275 2280 2285 (b) Vitesse de phase f [MHz] c(f) [m/s] cmes(f) mod`ele phase lin´eaire mod`ele phase dispersive mod`ele Olofsson FIGURE 2.16 – Atténuation fréquentielle et vitesse de phase, mesurées et modèles, pour du polycarbonate. (a) : Atténuation, (b) : vitesse de phase. 502.3 Exploitation des modèles ment dépendante de la fréquence. Une régression linéaire également représentée sur la fi- gure 2.16 permet d’estimer le terme d’ordonnée à l’origine ✁1④2d ln ⑤b♣2D 2dq⑤ et le terme qui dépend de la fréquence, α♣fq. On aboutit à un coefficient d’atténuation α♣0 ✏ 53.5 Np.MHz✁1 .m✁1 , conforme aux valeurs que l’on trouve dans la littérature [Selfridge 1985]. Pour le modèle d’Olofsson, le paramètre a est discrétisé sur une grille fine, de manière à générer les fonctions hr♣t, zq et à modéliser l’écho. Le paramètre qui minimise l’erreur entre les données et le modèle r ✏ ⑥yb ✁ y♣b ⑥ ⑥yb ⑥ , (2.76) est choisi. Le détail de cette procédure est présenté dans la partie 2.3.1 page 52. On obtient a ✏ 0.2098. A partir de l’équation (2.68), on peut calculer la fonction d’atténuation correspondant au modèle d’Olofsson. Elle est tracée sur la figure 2.16a et arbore une allure sensiblement équivalente au modèle d’atténuation linéaire. Calcul de la vitesse de phase A partir des équations (2.71) et (2.72), nous pouvons écrire la différence de phase entre les deux spectres arg Yf ♣fq ✁ arg Yb♣fq ✏ β♣fq2d ✏ 2πf c♣fq 2d, (2.77) ce qui permet d’écrire la vitesse de phase mesurée cmes♣fq cmes♣fq ✏ 2πf 2d arg Yf ♣fq ✁ arg Yb♣fq . (2.78) Dans le cas du modèle à phase linéaire, une estimation de la vitesse constante c♣fq ✏ c0 peut se calculer en effectuant la moyenne des cmes♣fq ♣c0 ✏ ❆ cmes♣fq ❊ . (2.79) Dans le cas du modèle dispersif, à partir de l’équation (2.28), la vitesse c✽ se calcule par 1 c✽ ✏ 1 c♣fq ✁ ♣fq 2πf , (2.80) où ♣fq est calculé à partir de α0 grâce à l’équation (2.33). On peut donc estimer ♣c✽ en calculant la moyenne 1 ♣c✽ ✏ ❈ 1 cmes♣fq ✁ ♣fq 2πf ● . (2.81) Les estimations de ♣c0 et ♣c✽ donnent respectivement ♣c0 ✏ 2273.2 m.s✁1 et ♣c✽ ✏ 2379.3 m.s✁1 . Ces valeurs permettent de calculer les vitesses de phase correspondantes, représentées sur la figure 2.16b. On observe que la vitesse de phase donnée par le modèle dispersif est assez fidèle à la vitesse mesurée. Le modèle à phase linéaire est forcément inexact en présence de dispersion et fournit une valeur moyenne de la vitesse. La vitesse de phase du modèle d’Olofsson donnée par l’équation (2.69) montre une vitesse quasiment constante dans la bande passante du transducteur, de valeur très proche de la vitesse de groupe calculée ♣c0 avec le modèle à phase linéaire. La vitesse c✽ pour le modèle d’Olofsson peut être trouvée en divisant 2e par le temps de vol (nous détaillons cela dans la partie 2.3.4), ce qui mène à ♣c✽ ✏ 2749.3 m.s✁1 . 51CHAPITRE 2 : Le modèle direct Estimation des signaux temporels par un processus de filtre adapté Nous comparons maintenant les échos de fond mesurés et modélisés grâce aux paramètres obtenus précédemment. Les valeurs des paramètres sont récapitulés dans le tableau 2.1. L’écho de surface yf est la transformée de Fourier inverse de Yf ♣fq ✏ Hi♣fqe ✁♣αw♣fqjβw♣fqq2D Atténuation Vitesse (m.s✁1 ) Modèle en loi de puissance α♣0 ✏ 53.5 Np.MHz✁1 .m✁1 ♣c0 ✏ 2273.2 ♣c✽ ✏ 2379.3 Olofsson ♣a ✏ 0.2098 ♣c✽ ✏ 2749.3 TABLE 2.1 – Tableau des estimations des coefficients d’atténuation et vitesses par division spectrale. Les mesures sont réalisées avec une plaque de polycarbonate de 10.2 mm d’épaisseur grâce à un transducteur centré à 2.25 MHz. (voir équation (2.71)). A partir de l’équation (2.72), l’écho de fond est défini par Yb♣fq ✏ Yf ♣fqb♣2D 2dqe ✁♣α♣fqjβ♣fqq2d . (2.82) Suivant les modèles retenus pour α♣fq et β♣fq, on peut donc modéliser l’écho de fond y♣b par une convolution entre l’écho de surface yf et une réponse impulsionnelle de propagation. Nous utilisons la formulation matricielle (2.48) : yb ✏ Gx. Quatre modèles sont comparés pour construire la matrice G : 1. le modèle sans atténuation 2. le modèle avec atténuation linéaire et phase linéaire 3. le modèle avec atténuation linéaire et phase dispersive 4. le modèle d’Olofsson. Pour modéliser un écho, le vecteur x est composé d’une seule valeur non nulle ♣a, qui correspond à l’amplitude b♣2D 2dq – pour rappel, nous avons considéré b♣2Dq ✏ 1 –, positionné à l’indice p♣ avec p♣ P r1 . . . Nxs. L’écho modélisé est donc une colonne gp♣ de G pondérée par un facteur d’amplitude tel que y♣b ✏ gp♣♣a. Nous considérons alors la minimisation d’un critère des moindres carrés entre les données et le modèle ♣p, ♣ ♣aq ✏ arg min p✏0...Nx✁1, aPR ✎ ✎yb ✁ gpa ✎ ✎ 2 . (2.83) Le modèle étant linéairement dépendant de l’amplitude, l’amplitude optimale peut être calculée pour chaque p en annulant la dérivée en fonction de a ❇ ✎ ✎yb ✁ gpa ✎ ✎ 2 ❇a ✏ ✁2g T p yb ✁ gpa ✟ ✏ 0 ÝÑ ♣a ✏ g T p yb ✎ ✎gp ✎ ✎ 2 . (2.84) 522.3 Exploitation des modèles En insérant l’équation (2.84) dans (2.83), on obtient ✎ ✎ ✎ ✎ ✎ yb ✁ gpg T p yb ✎ ✎gp ✎ ✎ 2 ✎ ✎ ✎ ✎ ✎ 2 ✏ ✄ yb ✁ gpg T p yb ✎ ✎gp ✎ ✎ 2 ☛T ✄ yb ✁ gpg T p yb ✎ ✎gp ✎ ✎ 2 ☛ ✏ ⑥yb ⑥ 2 ✁ 2 y T b gpg T p yb ✎ ✎gp ✎ ✎ 2 y T b gpg T p gpg T p yb ✎ ✎gp ✎ ✎ ✏ ⑥yb ⑥ 2 ✁ y T b gpg T p yb ✎ ✎gp ✎ ✎ 2 ✏ ⑥yb ⑥ 2 ✁ ✎ ✎g T p yb ✎ ✎ 2 ✎ ✎gp ✎ ✎ 2 . (2.85) Le terme ⑥yb ⑥ 2 étant constant et g T p yb étant scalaire, la minimisation de l’équation (2.85) revient à maximiser ⑤g T p yb ⑤④ ✎ ✎gp ✎ ✎. La position optimale p♣est donc déterminée par : p♣ ✏ arg max pPr1...Nxs ⑤g T p yb ⑤ ✎ ✎gp ✎ ✎ . (2.86) La localisation de l’écho revient donc à sélectionner la colonne gp♣ de G la plus corrélée aux données. Dans le cas spécifique où G est une matrice de convolution, ce calcul est équivalent à un filtre adapté [Van Trees 1968] ou au maximum d’intercorrélation. En pratique, les colonnes de la matrice G sont calculées pour des distances z autour de 2d ✏ 20.4 mm, avec un pas de discrétisation assez fin : ∆z ✏ 0.0001 mm. On obtient les résultats illustrés sur la figure 2.17. Nous affichons également l’erreur r entre les données et l’estimation, dé- finie selon l’équation (2.76). On peut observer que la meilleure estimation est réalisée par le modèle avec atténuation dispersive, qui fait baisser l’erreur d’un facteur cinq par rapport au modèle sans atténuation. Viennent ensuite les modèles avec phase linéaire et d’Olofsson. Nous remarquons que les formes estimées par ces deux modèles sont très proches, ce qui était attendu au vu des profils α♣fq et c♣fq de la figure 2.16. La plus mauvaise modélisation provient du modèle qui ne considère pas d’atténuation. 2.3.2 Mesure en transmission dans l’huile de ricin D’une manière similaire, nous présentons des résultats expérimentaux effectués avec de l’huile de ricin, matériau connu pour avoir une atténuation non-linéaire [He 1999, Szabo 1995]. Les mesures sont réalisées autour de 5 MHz par deux transducteurs, un émetteur et un récepteur, immergés face à face dans l’huile de ricin (voir figure 2.18). Comme illustré sur le schéma 2.19, la distance entre les transducteurs est fixée à 2 mm puis à 5 mm pour créer une épaisseur équivalente de matériau de 3 mm. Ces deux mesures correspondent respectivement aux signaux yf et yb . Les signaux temporels ainsi que leurs transformées de Fourier respectives Yf ♣fq et Yb♣fq sont représentés sur la figure 2.20. Nous observons un décalage du spectre vers les basses fréquences dû à l’atténuation. A partir de la division spectrale (2.75) et à l’aide d’une régression non-linéaire, nous identifions un facteur de puissance γ ✓ 1.70, valeur similaire à celles que l’on trouve dans la littérature [He 1999, Szabo 1995], et un coefficient d’atténuation α0 ✏ 10.93 Np.MHz✁1.70.m✁1 . Ces valeurs permettent de calculer 53CHAPITRE 2 : Le modèle direct 8 9 10 11 −0.05 0 0.05 t [µs] (a) Sans att´enuation r =0.46698 8 9 10 11 −0.05 0 0.05 t [µs] (b) Phase lin´eaire r =0.26442 8 9 10 11 −0.05 0 0.05 t [µs] (c) Phase dispersive r =0.08895 8 9 10 11 −0.05 0 0.05 t [µs] (d) Mod`ele d’Olofsson r =0.25699 FIGURE 2.17 – Estimation de l’écho de fond acquis avec une plaque de polycarbonate grâce à plusieurs modèles d’atténuation. (a) : Estimation sans atténuation, (b) : estimation avec atténuation linéaire et phase linéaire, (c) : estimation avec atténuation linéaire et phase dispersive, (d : estimation avec le modèle d’Olofsson. ’–’ : données, ’- -’ : estimation, r : erreur définie par l’équation (2.76). FIGURE 2.18 – Photos de l’expérimentation dans l’huile de ricin. Les transducteurs sont immergés dans l’huile et positionnés face à face pour réaliser une mesure en transmission. le profil de phase ♣fq grâce à l’équation (2.33). L’atténuation provenant du modèle d’Olofsson calculée avec l’équation (2.68) est également tracée sur la figure 2.21. On remarque une allure relativement proche de celle du modèle en loi de puissance. Les vitesses de phase mesurées et estimées sont représentées sur la figure 2.21. Le modèle à phase linéaire tend à estimer une vitesse moyenne ♣c0 ✏ 1522.5 m.s✁1 . Le modèle à phase dispersive permet d’obtenir, avec ♣c✽ ✏ 1592.4 m.s✁1 , une modélisation assez précise de la 542.3 Exploitation des modèles transducteur e transducteur FIGURE 2.19 – Schéma du dispositif expérimental pour la mesure dans l’huile de ricin. Le transducteur récepteur est déplacé d’une distance e pour créer un matériau de même épaisseur. 0 1 2 −1 −0.5 0 0.5 t [µs] yf (a) Echo 1 ´ 1 2 3 −0.5 0 0.5 t [µs] yb (b) Echo 2 ´ 0 1 2 3 4 5 6 7 8 9 0 0.5 1 f [MHz] |Yf (f)|, |Yb(f)| (c) Spectres en module normalis´es ´echo 1 |Yf (f)| ´echo 2 |Yb(f)| FIGURE 2.20 – Signaux temporels et fréquentiels acquis à partir d’une épaisseur d’huile de ricin de 3 mm avec un transducteur à 5 MHz. (a) : Écho 1 acquis avec la première position du transducteur, (b) : écho 2 acquis avec la deuxième position du transducteur, (c) : spectres en module des deux échos. vitesse de phase grâce à la prise de compte de la dispersion. Nous observons également que la vitesse calculée avec le modèle d’Olofsson (2.69) a une forme relativement proche de la réalité. La modélisation des signaux temporels est effectuée de la même façon que dans la partie précédente. Ces signaux sont représentés sur la figure 2.22. En termes d’adéquation entre les données et le modèle, nous obtenons le même classement que pour le polycarbonate. La moins bonne estimation est réalisée avec le modèle sans atténuation. Ensuite, les modèles à phase linéaire et d’Olofsson donnent des résultats équivalents. Les meilleurs résultats sont obtenus pour le modèle à phase dispersive qui fait baisser le résidu d’un facteur six par rapport à l’approche classique. 55CHAPITRE 2 : Le modèle direct 4 4.5 5 5.5 6 6.5 50 100 150 200 250 300 f [MHz] [Np/m] (a) Att´enuation -9.88 +10.93f 1.70 − 1 2d ln (Yb(f)/Yf (f)) r´egression mod`ele Olofsson 4 4.5 5 5.5 6 6.5 1520.5 1521 1521.5 1522 1522.5 1523 1523.5 1524 1524.5 (b) Vitesse de phase f [MHz] c(f) [m/s] cmes(f) mod`ele phase lin´eaire mod`ele phase dispersive mod`ele Olofsson FIGURE 2.21 – Atténuation fréquentielle et vitesse de phase dans l’huile de ricin, mesurées et modèles. (a) : Atténuation, (b) : vitesse de phase. 2.3.3 Mesure aérienne en transmission dans un matériau poreux Dans cette partie, nous nous intéressons aux matériaux poreux, qui sont des matériaux hé- térogènes, contrairement au polycarbonate et à l’huile de ricin. Un matériau poreux est un milieu biphasique, c’est-à-dire constitué d’une partie solide et d’une partie fluide (les pores). Lorsqu’il est immergé, il y a donc trois ondes qui se propagent : une onde longitudinale dans la partie fluide et deux ondes, longitudinale et transversale, dans la partie solide. Nous ne nous intéressons pas à un modèle précis de propagation dans les matériaux poreux, tel qu’il est présenté par Biot [1956a;b]. Nous voulons ici tester la capacité du modèle d’atténuation dispersive à s’adapter à des matériaux hétérogènes. La mesure que nous présentons est réalisée dans l’air, de manière à avoir uniquement l’onde dans le fluide. Tout d’abord, une mesure en transmission dans l’air entre deux transducteurs, de fré- quence centrale 100 kHz, espacés de 22.1 cm, nous permet d’obtenir le signal yf représenté sur la figure 2.23a. Cette mesure permet également d’obtenir la vitesse du son dans l’air : ca ✏ 343 m.s✁1 . Ensuite, une mousse poreuse d’épaisseur d ✏ 20 mm est placée entre les deux transducteurs. Le signal obtenu yb , après propagation dans la mousse, est tracé sur la figure 2.23b. Les spectres en module normalisés des deux signaux sont représentés sur la figure 2.23c. On peut remarquer une annulation vers 50 kHz, due aux caractéristiques des transducteurs. Les points autour de cette valeur n’ont pas servi aux calculs d’atténuation et de vélocité. D’une manière similaire à ce qui a été fait précédemment, les spectres permettent de mesurer l’atténuation (figure 2.23d) dans le matériau poreux. Celle-ci ayant un profil plutôt linéaire, on peut identifier α0 ✏ 513.8 Np.MHz✁1 .m✁1 par régression linéaire. Le coefficient α0 permet de calculer la partie dispersive de la phase ♣fq. La mesure de la vi- 562.3 Exploitation des modèles 2 2.5 3 −0.5 0 t [µs] (a) Sans att´enuation r =0.16601 2 2.5 3 −0.5 0 t [µs] (b) Phase lin´eaire r =0.04419 2 2.5 3 −0.5 0 t [µs] (c) Phase dispersive r =0.02671 2 2.5 3 −0.5 0 t [µs] (d) Mod`ele d’Olofsson r =0.04372 FIGURE 2.22 – Estimation du deuxième écho acquis dans l’huile de ricin grâce à plusieurs modèles d’atténuation. (a) : Estimation sans atténuation, (b) : estimation avec atténuation linéaire et phase linéaire, (c) : estimation avec atténuation linéaire et phase dispersive, (d) : estimation avec le modèle d’Olofsson. ’–’ : données, ’- -’ : estimation, r : erreur (2.76). tesse de phase, exposée en figure 2.23e, aboutit aux estimations des vitesses ♣c0 ✏ 301.3 m.s✁1 et ♣c✽ ✏ 325.8 m.s✁1 , grâce aux équations (2.79) et (2.81), respectivement. L’estimation de la vitesse de phase par le modèle dispersif est également représentée sur la figure 2.23e. L’adéquation n’est pas parfaite mais elle est plus proche que le modèle à vitesse de phase constante. Cette différence est due à la nature hétérogène de la mousse poreuse, qui a probablement un profil de vitesse de phase différent de notre modèle. Néanmoins, celui-ci permet une bonne approximation de la vitesse. Comme dans les parties précédentes, l’écho réceptionné après propagation dans la mousse peut être estimé grâce au modèle sans atténuation et au modèle avec atténuation linéaire et phase dispersive. Ces estimations sont respectivement représentées sur les figures 2.24a et 2.24b. Le modèle avec atténuation dispersive fournit un résultat avec une erreur environ deux fois inférieure au modèle sans atténuation. Cette expérience montre que, dans une moindre mesure que pour les matériaux homogènes, le modèle avec atténuation dispersive développé permet de modéliser des signaux provenant de matériaux hétérogènes, comme les mousses poreuses. Ce travail mériterait d’être poursuivi dans le cas de matériaux poreux saturés par de l’eau, dans lesquelles trois types d’ondes se propagent et se mélangent. 57CHAPITRE 2 : Le modèle direct 0.7 0.75 0.8 0.85 −2 −1 0 1 2 t [ms] yf (a) Signal de r´ef´erence 0.7 0.75 0.8 0.85 −0.2 −0.1 0 0.1 0.2 0.3 t [ms] yb (b) Signal transmis 0 50 100 150 0 0.2 0.4 0.6 0.8 1 f [kHz] (c) Spectres en module |Yf (f)| |Yb(f)| 20 40 60 80 100 120 140 60 80 100 120 140 160 f [kHz] [Np/m] (d) Att´enuation mesure mod`ele 20 40 60 80 100 120 140 285 290 295 300 305 f [kHz] c(f) [m/s] (e) Vitesse de phase mesure mod`ele lin´eaire mod`ele dispersif FIGURE 2.23 – Signaux temporels et fréquentiels acquis à partir d’une mousse poreuse de 20 mm d’épaisseur avec deux transducteurs à 100 kHz, et . (a) : Signal de référence, (b) : signal transmis, (c) : spectres en module, (d) : atténuation mesurée et régression linéaire, (e) : vitesse de phase mesurée et modèle. 0.74 0.76 0.78 0.8 0.82 0.84 0.86 −0.2 −0.1 0 0.1 0.2 0.3 t [ms] (a) Sans att´enuation donn´ees mod`ele, r = 0.0196 diff´erence 0.74 0.76 0.78 0.8 0.82 0.84 0.86 −0.2 −0.1 0 0.1 0.2 0.3 t [ms] (b) Avec att´enuation donn´ees mod`ele, r = 0.0099 diff´erence FIGURE 2.24 – Estimation de l’écho transmis par une mousse poreuse d’épaisseur 20 mm. (a) : Estimation sans atténuation, (b) : estimation avec atténuation linéaire et phase dispersive. ’–’ : données, ’- -’ : estimation, r : erreur (2.76). 2.3.4 Exploitation du modèle pour l’Évaluation Non Destructive Le modèle linéaire introduit dans la section 2.2 permet l’usage de méthodes d’estimation rapides comme le filtre adapté (équation (2.86)). Nous proposons d’utiliser cette procédure pour réaliser l’évaluation non-destructive d’un matériau, c’est-à-dire estimer certains de ses paramètres inhérents (masse volumique, vitesse des ondes, coefficient d’atténuation, etc.). Dans cette étude, les paramètres à retrouver sont le coefficient d’atténuation et la vitesse des ondes. Le principe est de tester plusieurs configurations de modèles avec des paramètres de différentes valeurs et de sélectionner les paramètres qui minimisent l’erreur entre les données et le modèle (équation (2.76)). Nous montrons qu’il est possible d’exprimer les modèles en fonction d’un seul paramètre (à facteur de loi de puissance constant). Dans cette partie, ce procédé d’évaluation est appliqué à l’estimation des paramètres du polycarbonate. Pour un facteur γ donné dans le modèle en loi de puissance α♣fq ✏ α0⑤f⑤ γ (équation (2.9)), 582.3 Exploitation des modèles on peut écrire la fonction de propagation (2.29) comme Hr♣f, p∆zq ✏ e ✁α♣fqp∆z✁j2πf p∆z④cref✁j♣fqp∆z . (2.87) La partie dispersive de la phase ♣fq ✏ ✁ 1 fS α0P ➺ fS 2 ✁ fS 2 ⑤g⑤ γ cot ✂ π fS ♣f ✁ gq ✡ dg ✏ α0 ✶ ♣f, γq, (2.88) est linéaire par rapport à α0. Si ∆z ✏ cref∆t , on peut donc écrire Hr♣f, zpq ✏ e ✁♣⑤f⑤ γj✶ ♣f,γqqα0crefp∆t e ✁j2πf p∆t . (2.89) Pour une valeur donnée de γ, la fonction de propagation est donc paramétrée par un unique coefficient sans unité χ ✏ α0cref. Pour chaque valeur de χ, la vitesse cref peut être déduite à partir de la dimension d de l’objet et de l’estimation de la position temporelle p♣ de l’écho suivant cref ✏ d p♣∆t . (2.90) où p♣est calculé selon l’équation (2.86). Le coefficient d’atténuation correspondant est alors α0 ✏ χ cref . (2.91) En pratique, nous discrétisons χ sur une grille fine de façon à couvrir des plages réalistes de paramètres pour α0 et cref. Pour chaque valeur de χ, une matrice G♣χq est construite avec un modèle d’atténuation donné. Nous utilisons ensuite le processus de filtrage adapté (voir partie 2.3.1) pour déterminer la position optimale p♣: ♣p♣♣χq, ♣a♣χqq ✏ arg min p✏0...Nx✁1, aPR ✎ ✎yb ✁ gp ♣χqa ✎ ✎ 2 . (2.92) L’estimation de l’écho est donc y♣b ♣χq ✏ gp♣♣χq♣a♣χq. (2.93) Une fois tous les p♣♣χq calculés, nous sélectionnons la solution χ♣ qui minimise l’erreur (2.76) χ♣ ✏ arg min χ ⑥yb ✁ y♣b ♣χq⑥ ⑥yb ⑥ . (2.94) Cette valeur permet d’estimer les paramètres α♣0 et ♣cref grâce aux équations (2.90) et (2.91). Dans cet exemple, nous avons utilisé les données acquises avec une plaque de polycarbonate de 10.2 mm d’épaisseur avec un transducteur à 2.25 MHz (mêmes données que dans la partie 2.3.1). Le paramètre χ est discrétisé entre 0 et 0.2350 avec un pas de 0.000175. Nous discrétisons également le paramètre a du modèle d’Olofsson entre 0 et 0.4 avec un pas de 0.0001. La résolution temporelle choisie est 0.0025 µs, ce qui correspond à un facteur de sur- échantillonnage K ✏ 4 (avec fS ✏ 100 MHz). Pour chaque valeur de χ ou a, une matrice G est générée et le calcul de l’équation (2.86) permet de retrouver la position temporelle optimale p♣. Nous représentons sur la figure 2.25, les coefficients d’atténuation et les vitesses associés à chaque valeur de χ ou de a. Les valeurs qui minimisent l’erreur (2.76) sont réca- 59CHAPITRE 2 : Le modèle direct 0 0.05 0.1 0.15 0.2 0 0.1 0.2 0.3 0.4 0.5 (a) mod`eles fr´equentiels χ R´esidu αb0 = 54.6 αb0 = 53.7 0 0.1 0.2 0.3 0.4 0 0.1 0.2 0.3 0.4 0.5 (b) Olofsson a R´esidu aˆ = 0.210 0 0.05 0.1 0.15 0.2 2250 2300 2350 2400 2450 2500 χ Vitesse [m/s] (c) mod`eles fr´equentiels bc0 = 2328.8 bc0 = 2273.0 bc∞ = 2379.7 sans att´enuation phase lin´eaire phase dispersive 0 0.1 0.2 0.3 0.4 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 a Vitesse [m/s] (b) Olofsson bc∞ = 2749.3 sans att´enuation Olofsson FIGURE 2.25 – Evaluation non destructive d’une plaque de polycarbonate. (a) : Résidu (2.76) en fonction de χ (modèles fréquentiels), (b) : résidu en fonction de a (modèle d’Olofsson), (c) : vitesse en fonction de χ, (d) : vitesse en fonction de a. Les valeurs minimales de résidu (✌) permettent l’estimation des coefficients d’atténuation (α♣0 ou ♣a) et des vitesses (♣c0 ou ♣c✽). Modèle χ♣ ou ♣a p♣∆t (µs) ♣cref (m.s✁1 ) α♣0 (Np.MHz✁1 .m✁1 ) 1 Sans atténuation 8.76 ♣c0 ✏ 2328.8 0 2 Phase linéaire χ♣ ✏ 0.1242 8.97 ♣c0 ✏ 2273.0 54.6 3 Phase dispersive χ♣ ✏ 0.1278 8.57 ♣c✽ ✏ 2379.7 53.7 4 Olofsson ♣a ✏ 0.210 7.42 ♣c✽ ✏ 2749.3 TABLE 2.2 – Tableau des estimations des χ♣, des temps de vol p♣∆t , des vitesses et des coef- ficients d’atténuation par évaluation non destructive. Mesures acquises avec une plaque de polycarbonate de 10.2 mm d’épaisseur grâce à un transducteur centré à 2.25 MHz. Pour les modèles 2 et 3, γ ✏ 1. pitulées dans le tableau 2.2. Ces valeurs sont à comparer avec celles obtenues par division spectrale dans la partie 2.3.1 (voir tableau 2.1 page 52). On remarque que ces valeurs sont très proches sauf pour le modèle sans atténuation. Le coefficient d’atténuation α♣0 et la vitesse ♣c0 ✏ 2273.0 m.s✁1 sont conformes aux valeurs que l’on trouve dans la littérature [Selfridge 1985]. Les signaux temporels estimés avec les paramètres optimaux sont représentés sur la figure 2.26. Notons que les résidus sont très proches de celles obtenues dans la partie 2.3.1. La différence pour le modèle sans atténuation vient du fait qu’une meilleure estimation est obtenue une demi-période plus tôt par rapport 602.3 Exploitation des modèles 8 9 10 11 −0.05 0 0.05 (a) Sans att´enuation t [µs] r = 0.45677 8 9 10 11 −0.05 0 0.05 (b) Phase lin´eare t [µs] r = 0.26478 8 9 10 11 −0.05 0 0.05 (c) Phase dispersive t [µs] r = 0.08894 8 9 10 11 −0.05 0 0.05 r = 0.25686 (d) Olofsson t [µs] FIGURE 2.26 – Signaux temporels correspondant aux paramètres obtenus par évaluation non destructive (voir tableau 2.2) d’une plaque de polycarbonate d’épaisseur 10.2 mm et un transducteur à 2.25 MHz. (a) : Estimation sans atténuation, (b) : estimation avec atténuation linéaire et phase linéaire, (c) : estimation avec atténuation linéaire et phase dispersive, (d) : estimation avec le modèle d’Olofsson. ’–’ : données, ’- -’ : estimation, r : erreur (2.76). à la figure 2.17. Cela influe donc directement sur l’estimation sur-évaluée de la vitesse qui devrait être proche de la vitesse de groupe : 2273 m.s✁1 . De même que dans les parties précédentes, c’est le modèle avec atténuation en loi de puissance et phase dispersive qui fournit l’erreur la plus faible et qui peut donc être considéré comme le plus fiable dans l’estimation des paramètres dans un contexte d’évaluation non destructive. 2.3.5 Problème de diffraction des cibles : application aux trous à fond plat Nous nous intéressons ici à la fiabilité du modèle dans le cas où les échos proviennent de profils géométriques différents. C’est typiquement le cas dans un cadre de contrôle non destructif où il faut détecter des défauts de formes variées. Nous choisissons d’étudier un cas simple : le trou à fond plat (Flat Bottom Hole, FBH). Celui-ci est percé par la face arrière d’une plaque d’aluminium de 40 mm d’épaisseur. L’aluminium est reconnu pour être homogène et avoir une atténuation quasiment nulle [Selfridge 1985]. De cette façon, nous nous focalisons sur la diffraction en négligeant l’atténuation. Nous considérons le schéma de mesure de la figure 2.27. Le transducteur centré sur 5 MHz utilisé en mode pulse-echo est placé du coté opposé au FBH. Ce dernier est de diamètre 5 mm et de profondeur d ✏ 20 mm. 61CHAPITRE 2 : Le modèle direct 2 3 1 3 transducteur Plaque FBH d FIGURE 2.27 – Schéma de la mesure ultrasonore avec une plaque percée d’un trou à fond plat (FBH) par le fond. Les échos reçus par le capteur sont respectivement 1) l’écho de surface, 2) l’écho du FBH et 3) l’écho du fond de la plaque. Nous utilisons le logiciel CIVA [Mahaut et al. 2009] 4 pour simuler le signal acquis pour une telle mesure. La méthode de calcul utilisée est l’approximation de Kirchhoff, qui est une extension du principe de Huygens5 . Les données acquises sont représentées sur la figure 2.28, respectivement composées de l’écho de surface yf , de l’écho du FBH yfbh et de l’écho du fond de la plaque yb . Nous tra- çons également les spectres en module ⑤Yf ♣fq⑤ et ⑤Yfbh♣fq⑤. On observe un décalage vers les hautes fréquences de la forme d’onde et donc un effet passe-haut du FBH. Cela se confirme si on trace le rapport des modules (2.75) : ✁1④2d ln ♣⑤Yfbh♣fq⑤④⑤Yf ♣fq⑤q. Cet effet passehaut se retrouve dans la littérature lorsqu’on aborde la modélisation du signal réfléchi par un disque [Rhyne 1977, Fink et Cardoso 1984, Cassereau et al. 1988]. Une approximation linéaire de la division spectrale permet d’obtenir un coefficient d’atténuation négatif α0 ✏ ✁10.23 Np.MHz✁1 .m✁1 sous le modèle de l’équation (2.9) α♣fq ✏ exp ♣✁α0⑤f⑤zq. Ce caractère passe-haut dû à la réflexion sur le trou a été observé avec des données réelles acquises dans l’aluminium, pour plusieurs diamètres et profondeurs de trou. Cet exemple permet de montrer que la géométrie des défauts joue un rôle important dans la signature spectrale. Dans un contexte d’inversion, pour retrouver les positions des défauts, l’hypothèse d’invariance de la fonction de diffraction que nous avions supposée est incorrecte. Le modèle que nous avons développé est de ce fait applicable à des problèmes où les formes géomé- triques sont équivalentes. C’est le cas par exemple pour les surfaces planes que nous avons utilisées dans les parties 2.3.1 et 2.3.4, ou des défauts de grandes tailles. Une des perspectives de ce travail sera d’adapter le modèle à plusieurs signatures de défauts dans le but de les détecter. 4Voir également le site du logiciel CIVA : http://www-civa.cea.fr. 5Le principe de Huygens postule que chaque point d’un front d’onde peut être considéré comme un point source émettant une onde sphérique, et que le champ total est ensuite construit par la superposition des champs créés par chacun des points sources. 622.3 Exploitation des modèles 0 1 2 3 4 5 6 7 8 9 10 11 12 13 −15 −10 −5 0 5 10 15 t [µs] y (a) Donn´ees 0 1 2 −15 −10 −5 0 5 10 15 t [µs] yf (b) Echo de surface ´ 6 7 8 −2 −1 0 1 2 t [µs] yfbh (c) Echo du FBH ´ 2 3 4 5 6 7 8 0 0.5 1 f [MHz] |Yf (f)|, |Yfbh(f)| (d) Spectres en module surface FBH 2 3 4 5 6 7 8 −40 −20 0 20 40 f [MHz] [Np/m] (e) Division spectrale -10.23f − 1 2d ln (Yfbh(f)/Yf (f)) r´egression FIGURE 2.28 – Signaux reçus à partir d’une plaque d’aluminium contenant un trou à fond plat (Simulations CIVA). (a) : Données, (b) : écho de surface, (c) : écho du FBH, (d) : spectres en modules des échos, (e) : division spectrale et regression linéaire. 63Chapitre 3 Le problème inverse : la déconvolution parcimonieuse Sommaire Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.1 Approches paramétriques . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.1.1 Modèles de formes d’ondes . . . . . . . . . . . . . . . . . . . . 66 3.1.2 Méthodes locales d’optimisation . . . . . . . . . . . . . . . . . . 67 3.1.3 Quelques méthodes d’optimisation non-linéaire . . . . . . . . . . 69 3.1.4 Méthodes de type Espérance-Maximisation . . . . . . . . . . . . 71 3.2 Minimisation d’un critère pénalisé . . . . . . . . . . . . . . . . . . . . 73 3.2.1 Description du modèle direct . . . . . . . . . . . . . . . . . . . . 73 3.2.2 Inverse généralisée . . . . . . . . . . . . . . . . . . . . . . . . . 74 3.2.3 Régularisation par minimisation d’un critère pénalisé . . . . . . . 74 3.2.4 Réglage du paramètre de régularisation . . . . . . . . . . . . . . 79 3.3 Régularisation par la pseudo-norme `0 . . . . . . . . . . . . . . . . . 80 3.3.1 Formulation du problème d’optimisation . . . . . . . . . . . . . 80 3.3.2 Méthodes d’optimisation par une approche gloutonne . . . . . . . 81 3.3.3 L’agorithme Single Best Replacement . . . . . . . . . . . . . . . 84 3.3.4 Comparaison des algorithmes gloutons et SBR . . . . . . . . . . 86 3.4 Des algorithmes plus efficaces d’optimisation `0 . . . . . . . . . . . . 88 3.4.1 Mouvements plus complexes . . . . . . . . . . . . . . . . . . . . 88 3.4.2 Sélection dans une fenêtre . . . . . . . . . . . . . . . . . . . . . 89 3.4.3 Sélection basée sur un calcul d’auto-corrélation multidimensionnelle 92 65CHAPITRE 3 : Le problème inverse Introduction Le problème inverse consiste à estimer les temps de vol et les amplitudes des échos contenus dans le signal reçu par le capteur ultrasonore. Nous détaillons dans ce chapitre plusieurs méthodes pour résoudre ce problème. La première approche consiste à formuler le modèle comme la somme d’échos paramétrés et à identifier les paramètres par des méthodes d’optimisation de type moindres carrés non linéaires. Dans la section 3.1, nous donnons un aperçu des modèles et des méthodes d’estimation des paramètres. Comme nous l’avons vu dans le chapitre 2, le modèle direct peut se mettre sous une forme linéaire en discrétisant les domaines spatial et temporel. Le but est alors d’estimer un vecteur parcimonieux, c’est-à-dire qui contient peu de valeurs non nulles, permettant de localiser les temps de vol. Dans la section 3.2, nous montrons qu’une inversion directe ne permet pas d’atteindre ce but et présente des problèmes d’instabilité. Une solution efficace est alors de régulariser le problème inverse grâce à la minimisation d’un critère pénalisé qui favorise la parcimonie. Nous nous intéressons particulièrement dans la section 3.3 à la régularisation par une pseudo-norme `0. Cette norme n’est pas convexe et nécessite des heuristiques performantes d’exploration des solutions. Plusieurs algorithmes d’optimisation sont proposés dans cette section et sont comparés grâce à des exemples simulés et à des simulations de Monte-Carlo. 3.1 Approches paramétriques La façon qui semble la plus naturelle pour résoudre le problème inverse est de considérer un modèle analytique des échos et d’estimer les paramètres de ce modèle à partir des données [Demirli et Saniie 2001a]. L’utilisation des méthodes paramétriques a fait l’objet d’un stage ingénieur au sein de l’équipe ADTSI de l’IRCCyN [Rolland 2014]. Il a été consacré aux méthodes d’optimisation locales dans un contexte de contrôle non destructif par ultrasons. Cette partie reprend quelques éléments et résultats obtenus lors du stage. 3.1.1 Modèles de formes d’ondes Nous avons vu au chapitre 2 que le signal peut être modélisé par la somme de K échos à laquelle on ajoute un bruit gaussien b♣tq. Chaque écho s♣t, θkq est défini par un jeu de paramètres θk. Le modèle du signal reçu par le capteur est alors y♣tq ✏ ➳ K k✏1 s♣t, θkq b♣tq. (3.1) On notera Θ, le vecteur colonne qui représente l’ensemble des paramètres θk, tel que Θ ✏ rθ T 1 , . . . , θ T Ks T . Ce vecteur est l’inconnue du problème. Le modèle le plus utilisé dans la littérature est l’écho gaussien1 ou ondelette de Gabor [Demirli et Saniie 2000; 2001a], qui est une gaussienne modulée par un signal sinusoï- 1Dans la suite, nous utilisons cette forme d’onde pour simuler des signaux ultrasonores. Par ailleurs, nous utilisons le paramètre de facteur de largeur de bande BWRp détaillé dans l’annexe B.2 pour régler la variance des gaussiennes. Pour une bande passante à p dB ce lien s’écrit σ 2 f ✏ ✁ ♣BWRpf0q 2 8 ln ♣10p④20q avec p ➔ 0. 663.1 Approches paramétriques dal : s♣t, θq ✏ Ae✁α♣t✁τq 2 cos♣2πf0♣t ✁ τ q φq, (3.2) où A est l’amplitude de l’écho, τ est le temps de vol, α est relié à la largeur de la gaussienne, f0 est la fréquence centrale et φ est le décalage de phase. Ces paramètres forment θ ✏ rα τ f0 φ As qui est le jeu de paramètres à estimer pour un écho. D’autres modèles plus complexes existent, comme par exemple, une sinusoïde avec une enveloppe composée de la somme de gaussiennes [Demirli et Saniie 2001b], un chirp avec une enveloppe gaussienne [Lu et al. 2006], un chirp avec une enveloppe composée de la somme de gaussiennes [Demirli et Saniie 2009], un chirp avec une enveloppe asymétrique [Demirli et Saniie 2010]. Ces modèles avec davantage de paramètres permettent une plus grande flexibilité mais peuvent rendre le problème d’optimisation plus difficile à résoudre. 3.1.2 Méthodes locales d’optimisation L’objectif est de minimiser l’erreur entre les données y♣tq et le modèle au sens des moindres carrés. Pour obtenir une estimation des paramètres Θ, il faut résoudre le problème d’optimisation Θ♣ ✏ arg min Θ ✎ ✎ ✎ ✎ ✎ y♣tq ✁ ➳ K k✏1 s♣t, θkq ✎ ✎ ✎ ✎ ✎ 2 ✏ arg min Θ f♣Θq. (3.3) Pour des données à temps discret, où tn ✏ nTS avec 0TS la période d’échantillonnage, la fonction à minimiser est donc f♣Θq ✏ ➳ Ny n✏1 ✄ y♣tnq ✁ ➳ K k✏1 s♣tn, θkq ☛2 ✏ ✎ ✎ ✎ ✎ ✎ y ✁ ➳ K k✏1 s♣θkq ✎ ✎ ✎ ✎ ✎ 2 ✏ ⑥r♣Θq⑥2 , (3.4) où y est le vecteur des données, s♣θkq est le modèle pour l’écho k et r♣Θq est le résidu d’estimation (ce sont des vecteurs colonnes). La fonction f étant non-linéaire en fonction de Θ, l’équation (3.3) formule un problème d’optimisation des moindres carrés non-linéaire. Il est possible d’utiliser une méthode d’optimisation itérative qui tend à converger vers une solution locale. Ces algorithmes partent d’une solution initiale Θ♣0q et s’arrêtent lorsque la norme entre deux itérés est inférieure à une tolérance . Il est possible d’utiliser d’autres conditions d’arrêt comme lorsque la fonction à minimiser ne décroît plus ou lorsque la norme de son gradient est inférieure à une certaine valeur. La structure générale d’un algorithme itératif est donnée ici : • Initialisations : i ✏ 1, cvge ✏ 0, Θ♣0q • Tant que cvge ✏ 0 faire Θ♣iq ✏ Θ♣i✁1q ∆Θ si ✎ ✎ ✎ Θ♣iq ✁ Θ♣i✁1q ✎ ✎ ✎ ➔  cvge ✏ 1 sinon i ✏ i 1 fin si Fin tant que 67CHAPITRE 3 : Le problème inverse La différence entre les méthodes réside dans la façon dont est calculé ∆Θ à chaque itération. Cette grandeur détermine la convergence et la vitesse de celle-ci. Nous détaillons quelques algorithmes dans la partie 3.1.3. Ces algorithmes sont des méthodes d’optimisation locales en opposition aux méthodes globales qui tentent de résoudre un problème contenant plusieurs minima locaux. Nous n’abordons pas ce type de méthodes qui sont très coûteuses en temps de calcul. Étude de f en fonction des paramètres Pour illustrer la difficulté de résolution du problème d’optimisation des moindres carrés non-linéaire, nous étudions qualitativement l’évolution de la fonction à minimiser de l’équation (3.4) en fonction de chaque paramètre pour un modèle à un écho gaussien. Les données sont générées sans bruit suivant le modèle de l’équation (3.2) avec les paramètres αq ✏ 25 µs ✁2 , τq ✏ 1 µs, fq0 ✏ 5 MHz, φq ✏ 0 rad, Aq ✏ 1 et sont représentées sur la figure 3.1a. Les variations de f en fonction de chaque paramètre, avec les autres paramètres fixés à leurs 0 0.5 1 1.5 2 −1 −0.5 0 0.5 1 t [µs] (a) donn´ees y(t) = s(t, θ) 0 20 40 60 80 100 0 10 20 30 40 50 α (b) f(α, τ, ˇ ˇf0,φ, ˇ Aˇ) 0 0.5 1 1.5 2 0 20 40 60 80 100 τ (c) f(ˇα, τ, ˇf0,φ, ˇ Aˇ) 0 5 10 15 20 0 20 40 60 80 f0 (d) f(ˇα, τ, f ˇ 0,φ, ˇ Aˇ) −3 −2 −1 0 1 2 3 0 50 100 150 φ (e) f(ˇα, τ, ˇ ˇf0, φ,Aˇ) −5 0 5 0 200 400 600 800 1000 A (f) f(ˇα, τ, ˇ ˇf0,φ, Aˇ ) FIGURE 3.1 – Étude de la fonction (3.4) à minimiser par rapport à chaque paramètre (les autres paramètres sont fixés à leur vraie valeur), pour un modèle d’écho gaussien. (a) : Données, (b) : f en fonction de α, (c) : f en fonction de τ , (d) : f en fonction de f0, (e) : f en fonction de φ, (f) : f en fonction de A. La valeur minimale de la fonction est nulle et les vraies valeurs des paramètres sont représentées par des cercles. vraies valeurs, sont présentées sur les figures 3.1b-c-d-e-f. Le paramètre d’amplitude A étant linéaire par rapport au modèle, on obtient une forme quadratique, donc convexe (figure 3.1f). Les paramètres α, f0 et φ ne montrent pas de difficulté particulière non plus, car les fonctions correspondantes ont un seul minimum local. Elles ne sont cependant pas convexes. Il 683.1 Approches paramétriques faut noter que la dépendance en φ est périodique. Le problème vient essentiellement de la dépendance de la fonction par rapport au temps de vol τ qui a de nombreux minima locaux. Ceci est dû au caractère oscillant du modèle de formes d’onde, qui crée une répétition des minima locaux espacés de 1④f0. Une bonne initialisation sur le temps de vol est donc primordiale pour que l’algorithme ne converge pas vers un mauvais minimum local. Le problème est plus difficile lorsque le nombre d’échos augmente, de surcroît lorsqu’ils se mélangent. 3.1.3 Quelques méthodes d’optimisation non-linéaire Nous présentons ici quelques méthodes d’optimisation locales [Bazaraa et al. 2013]. Méthode du gradient La méthode du gradient ou méthode de la plus forte pente consiste à sélectionner les ité- rés dans la direction opposée au gradient, de manière à faire décroître la fonction au point courant. Si f est différentiable, l’estimation des paramètres à l’itération i est donc Θ♣iq ✏ Θ♣i✁1q ✁ α∇f♣Θ♣i✁1q q, (3.5) où α → 0 est le pas de descente et ∇f♣Θ♣i✁1q q est le gradient de f au point Θ♣i✁1q . Le gradient étant défini par ∇f♣Θq ✏ 2J T r♣Θq, avec J la matrice jacobienne telle que Jn,m ✏ ❇rn ❇Θm ✏ ✁ ❇ ➦K k✏1 s♣tn, θkq ❇Θm , (3.6) (où rn est le n ème élément de r♣Θq), on peut écrire Θ♣iq ✏ Θ♣i✁1q ✁ 2αJ T r♣Θq. (3.7) Le pas de descente peut être constant. Dans ce cas, l’algorithme converge lentement si le pas est trop petit ou s’éloigne du minimum s’il est trop grand. Il est de ce fait préférable de définir le pas à chaque itération par recherche de ligne, de façon à assurer une décroissance suffisante du critère à chaque itération [Chouzenoux 2010]. Cet algorithme est efficace car il garantit une décroissance de la fonction à minimiser. Il est cependant connu pour être lent à converger. D’autres extensions, comme le gradient conjugué, effectuent une recherche de pas efficace combinée au calcul du gradient (nous avons fait le choix de ne pas poursuivre l’étude ce genre d’approches). Méthode de Newton Si f est deux fois dérivable, un extremum local vérifie la condition nécessaire ∇f♣Θq ✏ 0. La méthode de Newton va permettre de chercher des solutions de ∇f♣Θq ✏ 0, autrement dit les points stationnaires de f. La loi des itérés est Θ♣iq ✏ Θ♣i✁1q ✁ H♣Θ♣i✁1q q ✁1∇f♣Θ♣i✁1q q ✏ Θ♣i✁1q ✁ 2H♣Θ♣i✁1q q ✁1J T r♣Θ♣i✁1q q, (3.8) où H♣Θ♣i✁1q q est la matrice hessienne formée des dérivées partielles secondes de f au point Θ♣i✁1q : Hn,m ✏ ❇2 fn④❇Θm❇Θn. Cet algorithme est rapide à converger mais nécessite une inversion de système à chaque itération. Des problèmes se posent alors lorsque la matrice H♣Θ♣i✁1q q est mal conditionnée. De plus, il ne garantit pas une convergence au minimum local car il peut se diriger vers un maximum local ou un point selle. 69CHAPITRE 3 : Le problème inverse Méthode de Gauss-Newton La méthode de Gauss-Newton est spécifique à la résolution de problèmes de moindres carrés non linéaires, dont l’équation (3.3) fait partie. Si on considère la linéarisation de l’équation (3.4) telle que f♣Θ ∆Θq ✓ ⑥r♣Θq ✁ J∆Θ⑥ 2 (r♣Θq est le résidu d’estimation), l’annulation du gradient de f♣Θ ∆Θq par rapport à ∆Θ aboutit à ∆Θ ✏ J T J ✟ J T r♣Θq. Si on se dirige dans le sens opposé au gradient, on obtient alors la solution au point courant Θ♣iq ✏ Θ♣i✁1q ✁ J T J ✟✁1 J T r♣Θ♣i✁1q q. (3.9) Cette approche peut être vue comme une approximation de la méthode de Newton dans laquelle la matrice hessienne H♣Θq est approchée par 2J T J, évitant ainsi le calcul des dérivées secondes. Tout comme l’algorithme de Newton, l’algorithme peut ne pas converger si J T J est mal conditionnée. Méthode de Levenberg-Marquardt La méthode de Levenberg-Marquardt se situe entre les méthodes du gradient et de GaussNewton. Le principe est de régulariser l’équation (3.9) de façon à stabiliser l’inversion Θ♣iq ✏ Θ♣i✁1q ✁ J T J λI ✟✁1 J T r♣Θ♣i✁1q q, (3.10) où λ → 0 est un paramètre de régularisation et I est la matrice identité. Lorsque λ tend vers zéro, la méthode tend vers celle de Gauss-Newton alors que quand λ est très grand, elle tend vers la méthode du gradient avec un pas α ✏ 1④2λ. Une autre version de l’algorithme utilise la diagonale de J T J à la place de la matrice identité. Le paramètre λ est modifié en permanence pour obtenir la valeur qui fait le plus décroître f. Comparaison des algorithmes en fonction de l’initialisation Nous utilisons ici les données contenant un seul écho non bruité présentées dans la partie 3.1.2, où les vrais paramètres sont notés θq ✏ r25, 1, 5, 0, 1s. Les algorithmes de Newton, Gauss-Newton et Levenberg-Marquardt sont utilisés avec plusieurs initialisations. Nous écartons la méthode du gradient qui est lente à converger. Les résultats sont regroupés dans le tableau 3.1. Les valeurs très proches de zéro indiquent la convergence au minimum global Initialisation θ0 τ ♣0q Newton Gauss-Newton Levenberg-Marquardt θq 2% 1.02 2.29. 10✁15 5.60. 10✁27 5.11. 10✁20 θq 3% 1.03 25.07 1.47. 10✁27 2.30. 10✁23 θq 5% 1.05 26.63 24.99 25.07 θq 7% 1.07 73.67 26.97 1.07. 10✁13 TABLE 3.1 – Valeurs de la fonction des moindres carrés à minimiser pour plusieurs méthodes d’optimisation et différentes valeurs d’initialisation. tandis que les valeurs supérieures à la vingtaine correspondent à des minima locaux (voir la figure 3.1 pour les variations de la fonction par rapport à chaque paramètre). Pour une initialisation très proche de la vérité (2 %), les trois méthodes convergent vers l’optimum. 703.1 Approches paramétriques Pour des valeurs légèrement plus éloignées (3 %), la méthode de Newton converge vers un minimum local. Les méthodes aboutissent toutes à un minimum local pour une mauvaise initialisation de 5 %. La méthode de Levenberg-Marquardt permet néanmoins de converger vers le minimum global dans certains cas malgré de mauvaises initialisations (7 %). La ré- gularisation établit à l’équation 3.10 permet de stabiliser l’inversion et, dans certains cas, de ne pas rester bloqué dans un minimum local. D’après cet exemple simple, où un seul écho est considéré, nous montrons que les approches d’optimisation sont très sensibles aux valeurs initiales des paramètres. Dans un contexte où plusieurs échos se mélangent, ces approches ne semblent pas robustes. 3.1.4 Méthodes de type Espérance-Maximisation L’algorithme Espérance-Maximisation (EM) (ou Expectation-Maximization en anglais) est une méthode itérative qui permet l’estimation de paramètres, sous un modèle de signaux superposés [Feder et Weinstein 1988], i.e. en adéquation avec l’équation (3.1). Il travaille ainsi en séparant le problème en plusieurs modes correspondant aux différents échos. Les données sont alors représentées par y ✏ ➦K i✏k wk où wk est la k ème contribution. L’algorithme est composé de deux étapes, une étape d’espérance (E) qui construit les différentes estimations w♣ k, et une étape de maximisation (M) qui consiste à estimer les paramètres θ♣k pour chaque w♣ k. L’étape M est effectuée grâce un algorithme local des moindres carrés non-linéaires (voir partie 3.1.3). Cet algorithme est connu pour être relativement lent à converger. Il faut noter que si tous les jeux de paramètres sont initialisés aux mêmes valeurs, les w♣ k et les θ♣k resteront identiques. L’algorithme Space Alternating Generalized EM (SAGE) [Ziskind et Wax 1988, Fessler et Hero 1994] est une légère amélioration de l’algorithme EM qui met à jour tous les θk juste après une étape M. Chung et Böhme [2001] ont montré que cela permet à l’algorithme de converger plus rapidement. Le détail de l’algorithme est donné ici • Initialisations : i ✏ 1, cvge ✏ 0, Θ♣0q ✏ rθ ♣0qT 1 , . . . , θ ♣0qT K s T • Tant que cvge ✏ 0 faire Pour k ✏ 1 à K faire Étape E : w ♣i✁1q k ✏ s♣θ ♣i✁1q k q 1 K ✁ y ✁ ➦k `✏1 s♣θ ♣iq ` ✁ ➦K `✏k1 s♣θ ♣i✁1q ` q ✠ Étape M : θ ♣iq k ✏ arg min θk ✎ ✎ ✎ w ♣i✁1q k ✁ s♣θkq ✎ ✎ ✎ 2 avec init. θ ♣i✁1q k fin pour Θ♣iq ✏ rθ ♣iqT 1 , . . . , θ ♣iqT K s T si ✎ ✎ ✎ Θ♣iq ✁ Θ♣i✁1q ✎ ✎ ✎ ➔  cvge ✏ 1 sinon i ✏ i 1 fin si fin tant que 71CHAPITRE 3 : Le problème inverse Demirli et Saniie [2001a;b] ont appliqué l’algorithme SAGE avec un modèle d’écho gaussien pour le contrôle non destructif par ultrasons. Dans [Demirli et Saniie 2001a], l’optimisation est réalisée avec cinq paramètres pour chaque écho et des initialisations arbitraires plutôt favorables. Dans [Demirli et Saniie 2001b], seuls deux paramètres sont utilisés – l’amplitude et le temps de vol – de façon à disposer d’un modèle convolutif de la forme y♣tq ✏ ➦ k Akhi♣t ✁ τkq. Sur la figure 3.2, nous montrons un exemple de déconvolution par les méthodes de Levenberg-Marquardt et SAGE (avec étape M réalisée pas la méthode de Levenberg-Marquardt). Les données sont composées de cinq échos de fréquence centrale 0 0.5 1 1.5 2 2.5 3 3.5 −1 −0.5 0 0.5 1 (a) Donn´ees et v´erit´e 0 0.5 1 1.5 2 2.5 3 3.5 −1 −0.5 0 0.5 1 (b) Initialisation 0 0.5 1 1.5 2 2.5 3 3.5 −1 −0.5 0 0.5 1 (c) Levenberg-Marquardt 0 0.5 1 1.5 2 2.5 3 3.5 −1 −0.5 0 0.5 1 (d) Levenberg-Marquardt 0 0.5 1 1.5 2 2.5 3 3.5 −1 −0.5 0 0.5 1 (e) SAGE 0 0.5 1 1.5 2 2.5 3 3.5 −1 −0.5 0 0.5 1 (f) SAGE FIGURE 3.2 – Déconvolution par des méthodes paramétriques. (a) : Données (–) et vé- rité (+), (b) : vérité (+) et initialisation (✍), (c) : données (–) et approximation par la méthode de Levenberg-Marquardt (- -), (d) : vérité (+) et estimation par la méthode de LevenbergMarquardt (✆), (e) : données (–) et approximation par l’algorithme SAGE (- -), (f) : vérité (+) et estimation par l’algorithme SAGE (✆). fixe 5 MHz. Les paramètres α ✏ 16 et φ ✏ 0 sont également fixés. Pour davantage de simplicité, le nombre d’échos recherchés est fixé à la vraie valeur. Il serait possible d’augmenter le nombre d’échos itérativement et d’utiliser un critère d’arrêt sur la norme du résidu ou grâce à un critère de sélection d’ordre [Stoica et Selén 2004]. L’étape d’initialisation des temps de vol et des amplitudes est réalisée grâce à un calcul d’enveloppe par transformée de Hilbert, puis par une détection de maxima. Cette étape permet de détecter correctement les échos séparés, mais elle faillit à détecter les échos mélangés (entre 2 et 2.5 µs). Nous utilisons ensuite les méthodes de Levenberg-Marquardt et SAGE pour estimer les temps de vol et amplitudes des échos. Les deux méthodes parviennent à estimer correctement les échos bien localisés à l’initialisation (deux à gauche et un à droite). En revanche, la méthode de Levenberg-Marquardt n’estime pas correctement les échos dans [2 µs 2.5 µs]. La méthode 723.2 Minimisation d’un critère pénalisé SAGE parvient à détecter un des deux échos. Par cet exemple simple, on observe que les méthodes paramétriques sont très dépendantes de l’initialisation et servent en fait à raffiner localement le résultat issu de l’estimation initiale. Pour remédier à ce genre de problème, [Demirli et Saniie 2001b] établissent des règles d’initialisation à partir de connaissances a priori sur l’objet inspecté. Par exemple, dans le cas du traitement de signaux issus de plaques homogènes (où on recherche des temps de vol régulièrement espacés), chaque nouvel écho est initialisé avec un écart de temps de vol constant par rapport à l’écho précédent. De plus, plusieurs initialisations différentes sont réalisées à chaque étape M pour augmenter les chances de converger vers le minimum global. Ces règles semblent délicates à appliquer pour traiter de façon robuste et automatique les signaux ultrasonores, qui plus est dans un contexte d’échos mélangés provenant d’une pièce inconnue. 3.2 La déconvolution parcimonieuse par minimisation d’un critère pénalisé 3.2.1 Description du modèle direct Pour éviter l’optimisation des paramètres d’un modèle non-linéaire sensible aux mauvaises initialisations qui aboutissent à des minima locaux, nous proposons une formulation s’appuyant sur un modèle linéaire. Nous avons vu dans la section 2.2 du chapitre 2 qu’il est possible d’aboutir à un tel modèle en discrétisant les domaines spatial et temporel. A partir de l’équation (2.48), nous considérons un modèle discret linéaire auquel un terme de perturbation est rajouté y ✏ Gx b, y P R Ny , G P R Ny✂Nx , x P R Nx , b P R Ny , (3.11) où y est le signal mesuré et x est l’inconnue du problème. La construction de la matrice G dépend du modèle physique considéré (se reporter à la partie 2.2). Le terme de perturbation b représente les erreurs de modèle, le bruit de mesure et les erreurs de discrétisation. Nous considérons ce terme comme un ensemble de réalisations aléatoires indépendantes, centrées, de même loi gaussienne de variance σ 2 b . Le signal y peut être caractérisé par un rapport signal sur bruit RSB défini par RSB ✏ 10 log ✂ P♣Gxq P♣bq ✡ , (3.12) où P♣Gxq est la puissance du signal non bruité P♣Gxq ✏ 1 Ny ⑥Gx⑥ 2 ✏ 1 Ny ♣Gxq T Gx, (3.13) et P♣bq est la puissance du bruit P♣bq ✏ 1 Ny ➳ Ny n✏1 brns 2 ✏ 1 Ny ⑥b⑥ 2 ÝÑNyÑ✽ σ 2 b . (3.14) Dans la suite de ce chapitre, nous approximons le RSB par RSB ✔ 10 log ✂ P♣Gxq σ 2 b ✡ . (3.15) 73CHAPITRE 3 : Le problème inverse 3.2.2 Inverse généralisée Une approche simple pour estimer x dans l’équation (3.11) revient à minimiser un critère des moindres carrés entre les données et le modèle : J ♣xq ✏ ⑥y ✁ Gx⑥ 2 . (3.16) Puisque le critère est quadratique et donc convexe, le minimum global est défini par l’annulation du gradient qui s’écrit : ∇J ♣xq ✏ ✁2GT y 2GTGx ✏ 0. (3.17) Si GTG est inversible, la solution qui annule le gradient est x♣ ✏ GTG ✟✁1 GT y. (3.18) En considérant xq comme la solution du système, nous obtenons l’estimation x♣ ✏ xq GTG ✟✁1 GT b. (3.19) On observe que le terme d’erreur par rapport à la vraie solution est une fonction linéaire du terme du bruit. Si le bruit est nul, l’estimation est optimale. Dans le cas contraire, l’erreur due au bruit peut être importante suivant la nature de l’inverse de GTG. En effet, lorsque la matrice GTG est mal conditionnée, son inverse prend de grandes valeurs qui ont pour effet d’amplifier le bruit. Pour illustrer ce propos, nous générons des données d’après le modèle y ✏ Gxq b, où G est la matrice de convolution associée à une réponse instrumentale gaussienne (f0 ✏ 5 MHz, BWR✁3 ✏ 0.3, φ ✏ 0), de nature passe-bande autour de f0. Nous calculons x♣ pour plusieurs niveaux de bruit : sans bruit, RSB ✏ 80 dB et RSB ✏ 50 dB. Les données et résultats d’estimation sont représentés sur la figure 3.3. D’après ces résultats, la solution est exacte dans le cas sans bruit. En présence d’un très faible bruit (RSB de 80 et 50 dB), la solution est fortement perturbée. Pour RSB ✏ 50 dB, le terme d’erreur dû au bruit est si important qu’il ne permet pas de distinguer le signal piqué, alors que le bruit n’est pas discernable dans les données. On observe ici très nettement le caractère instable de l’inversion directe dû à l’amplification des fréquences, hors de la signature instrumentale, contenues dans le bruit. Cette approche se révèle par conséquent difficilement applicable à des situation réelles où le bruit instrumental et les erreurs de modèles sont présents, et viennent de fait perturber l’estimation. Pour pallier ce problème nous allons introduire un principe de régularisation qui consiste à renforcer certaines propriétés de la solution [Idier 2001]. 3.2.3 Régularisation par minimisation d’un critère pénalisé Pour remédier au problème d’instabilité de la solution due au bruit, le critère des moindres carrés (3.16) est remplacé par un critère composite J ♣x, µq ✏ ⑥y ✁ Gx⑥ 2 µR♣xq, (3.20) où R♣xq est une fonction de régularisation qui favorise un a priori sur la solution x. Le paramètre µ règle le compromis entre l’adéquation aux données et le respect de cet a priori. Lorsque µ est nul, on retrouve le critère des moindres carrés (3.16), tandis que lorsque µ tend vers l’infini, seul l’a priori est considéré, la solution ne dépendant alors pas des données. 743.2 Minimisation d’un critère pénalisé 0 50 100 150 200 250 −0.5 0 0.5 (a) Donn´ees non bruit´ees 0 50 100 150 200 250 −0.5 0 0.5 (c) Donn´ees RSB = 80 dB 0 50 100 150 200 250 −0.5 0 0.5 (e) Donn´ees RSB = 50 dB 0 20 40 60 80 100 120 140 160 180 200 −2 −1 0 1 2 (b) v´erit´e et estimation xˇ xˆ 0 20 40 60 80 100 120 140 160 180 200 −2 −1 0 1 2 (d) v´erit´e et estimation 0 20 40 60 80 100 120 140 160 180 200 −40 −20 0 20 40 (f) v´erit´e et estimation FIGURE 3.3 – Déconvolution par une approche d’inverse généralisée. (a) : Données non bruitées, (b) : vérité (+) et estimation (–), (c) : données avec RSB ✏ 80 dB, (d) : vérité (+) et estimation (–), (e) : données avec RSB ✏ 50 dB, (f) : vérité (+) et estimation (–). Notion de parcimonie Le vecteur x est supposé parcimonieux (sparse en anglais), c’est-à-dire qu’il contient un grand nombre de valeurs nulles [Elad 2010]. À temps continu, il peut être appelé train d’impulsions (spike train). Le format vectoriel est obtenu grâce à la discrétisation du modèle présenté dans la partie 2.2. Le nombre de composantes non-nulles dans x correspond de ce fait au nombre de cibles présentes. Le vecteur x a donc une interprétation spatiale puisqu’il indique les positions et les amplitudes des cibles (voir chapitre 2) [Olofsson et Stepinski 2000]. Régularisation quadratique Le choix le plus simple est de prendre une régularisation quadratique appelée également régularisation de Tikhonov R♣xq ✏ ⑥x⑥ 2 . (3.21) Cette fonction offre l’avantage d’être convexe, c’est-à-dire qu’elle est unimodale (un seul minimum) et qu’elle est différentiable en tout point. En annulant le gradient ∇J ♣x, µq ✏ ✁2GT y 2GTGx 2µx ✏ 0, (3.22) on aboutit à la solution unique x♣ ✏ GTG µI ✟✁1 GT y. (3.23) 75CHAPITRE 3 : Le problème inverse La présence de la matrice identité a pour effet de réduire le conditionnement et donc de stabiliser l’inversion. Pour un modèle de convolution, cette approche peut être implémentée par un filtre de Wiener ou de Kalman [Fatemi et Kak 1980, Demoment et al. 1984, Jensen 1992]. Cette forme de pénalisation est pratique mais n’aboutit pas à des solutions piquées, car elle pénalise trop les grandes amplitudes [Idier 2001]. Régularisation convexe non quadratique L’utilisation d’autres fonctions de régularisation qui pénalisent moins les grandes amplitudes est possible, comme par exemple la norme `p pour 1 ➔ p ➔ 2 R♣xq ✏ ⑥x⑥ p p ✏ ➳ Nx n✏1 ⑤xrns⑤p , 1 ➔ p ➔ 2. (3.24) C’est une fonction convexe, continûment différentiable qui introduit un critère (3.20) convexe et différentiable également, ayant un minimum unique. En terme de solution algorithmique, il est par exemple possible d’utiliser un algorithme itératif de descente (voir partie 3.1.2), ou l’algorithme IRLS (Iterative Reweighted Least-Squares) [Yarlagadda et al. 1985]. Régularisation de norme `1 Une fonction qui pénalise moins les grandes amplitudes est la norme `1 [Taylor et al. 1979, Chen et al. 1998, Elad 2010] R♣xq ✏ ⑥x⑥1 ✏ ➳ Nx n✏1 ⑤xrns⑤. (3.25) Cette fonction convexe permet d’obtenir un minimum unique dans le critère (3.20). Le problème algorithmique vient de sa non différentiabilité en zéro, mais qui crée des solutions piquées [Moulin et Liu 1999]. Différentes formulations provenant de plusieurs communautés permettent de résoudre ce problème [Tibshirani 1994, Efron et al. 2002, Davies et Daudet 2003, Malioutov et al. 2005, Maria et Fuchs 2006, Tropp et Wright 2010]. Ce type de pénalisation a été très utilisée depuis une vingtaine d’années, notamment en géophysique [Taylor et al. 1979] et en contrôle non destructif [O’Brien et al. 1994]. La pénalisation étant appliquée linéairement aux amplitudes, les solutions ont tendance à contenir des pics multiples de faibles amplitudes en lieu et place d’un seul vrai pic [Soussen et al. 2012]. Pour cette raison, il est possible d’effectuer un seuillage pour supprimer ces nombreuses fausses détections. Régularisation convexe qui favorise la parcimonie Des fonctions de régularisation strictement convexes et différentiables ont été proposées pour favoriser la parcimonie, comme par exemple la fonction hyperbolique R♣xq ✏ ➳ Nx n✏1 ❛ xrns 2 δ 2 , δ → 0. (3.26) Cette dernière a le comportement de la norme `1 pour les grandes amplitudes et celui de la norme `2 pour les petites amplitudes. Elle permet ainsi de favoriser les solutions piquées tout en offrant l’avantage de la différentiabilité pour la mise en œuvre algorithmique. Lorsque δ tend vers zéro, la fonction tend vers la norme `1. 763.2 Minimisation d’un critère pénalisé Régularisation non-convexe qui favorise la parcimonie D’autres fonctions permettent de favoriser la parcimonie mais ne sont pas convexes, comme par exemple la norme `p définie à l’équation 3.24 avec 0 ➔ p ➔ 1 [Rao et Kreutz-Delgado 1999]. Ce type de régularisation produit des solutions parcimonieuses du fait de la nondifférentiablité en zéro [Moulin et Liu 1999]. Lorsque p tend vers zéro, cette dernière tend vers la pseudo-norme `0 qui compte le nombre de composantes non-nulles dans x ⑥x⑥0 ✏ ➳ Nx n✏1 ⑤xrns⑤0 , (3.27) avec par définition ⑤x⑤ 0 ✏ ✧ 0 si x ✏ 0 1 sinon . (3.28) Ce n’est pas exactement une norme car elle ne vérifie pas la propriété d’homogénéité2 : ❅λ ✘ 0 et ⑤λ⑤ ✘ 1 on a ⑥λx⑥0 ✘ ⑤λ⑤ ⑥x⑥0 . Nous utilisons ce type de régularisation et les méthodes pour résoudre le problème d’optimisation associé dans la section 3.3. Comparaison de plusieurs types de régularisation Plusieurs exemples de fonctions de régularisation sont exposés sur la figure 3.4. Pour les x R(x) ℓ2 ℓ1.5 hyperbolique x R(x) ℓ1 ℓ0.5 ℓ0 FIGURE 3.4 – Exemples de fonctions de régularisation R♣xq. A gauche : `2, `1.5, hyperbolique (❄ x 2 δ 2 avec δ ✏ 0.1), à droite : `1, `0.5, `0. données de la figure 3.3 avec RSB ✏ 20 dB, les résultats de déconvolution correspondant à plusieurs fonctions de régularisation sont présentés sur la figure 3.5. Les paramètres de régularisation sont réglés empiriquement de façon à obtenir une solution la plus proche possible de la vérité. La solution de la régularisation `2 est donnée par la formulation explicite (3.23). L’optimisation pour la régularisation `1 est effectuée par un algorithme de type homotopie [Malioutov et al. 2005]. La minimisation pour la régularisation hyperbolique est réalisée par l’algorithme IRLS [Yarlagadda et al. 1985]. Pour la régularisation `0, nous utilisons l’algorithme d’optimisation locale SBR [Soussen et al. 2011], que nous détaillons dans la partie 3.3.3. Comme vu dans la partie 3.2.2, l’inversion généralisée ne fournit pas de solution acceptable car elle amplifie le bruit. La régularisation quadratique permet de stabiliser la solution 2La propriété d’homogénéité d’une norme N est vérifiée par la condition ❅♣λ, xq ✘ 0, N ♣λxq ✏ ⑤λ⑤N ♣xq. 77CHAPITRE 3 : Le problème inverse 0 50 100 150 200 250 −0.5 0 0.5 (a) Donn´ees RSB = 20 dB 0 20 40 60 80 100 120 140 160 180 200 −1000 −500 0 500 1000 (b) Inversion g´en´eralis´ee 0 20 40 60 80 100 120 140 160 180 200 −1.5 −1 −0.5 0 0.5 1 1.5 (c) R´egularisation ℓ2 xˇ xˆ 0 20 40 60 80 100 120 140 160 180 200 −1.5 −1 −0.5 0 0.5 1 1.5 (d) R´egularisation ℓ1 0 20 40 60 80 100 120 140 160 180 200 −1.5 −1 −0.5 0 0.5 1 1.5 (e) R´egularisation hyperbolique 0 20 40 60 80 100 120 140 160 180 200 −1.5 −1 −0.5 0 0.5 1 1.5 (f) R´egularisation ℓ0 FIGURE 3.5 – Déconvolution avec plusieurs fonctions de régularisation. (a) : Données avec RSB ✏ 50 dB, (b) : déconvolution par inverse généralisée, (c) déconvolution par régularisation quadratique, (d) : déconvolution par régularisation de norme `1, (e) : déconvolution par régularisation hyperbolique, (f) : déconvolution par régularisation de norme `0. mais ne produit pas de solution piquée. La régularisation de norme `1 crée bien une solution piquée assez proche de la vérité. On remarque néanmoins quelques petits pics de faibles amplitudes. La régularisation hyperbolique fournit une solution piquée proche de celle obtenue avec une régularisation `1 mais avec des amplitudes non nulles sur tout le support de la solution. La solution fournie par la régularisation `0 permet de localiser parfaitement les pics. Il n’y a pas de valeurs de faible amplitude comparée à la norme `1 ou la norme hyperbolique. Ceci est dû à à la pénalisation de la cardinalité et non de l’amplitude. Lien entre régularisation et loi a priori Nous l’avons vu, la fonction de pénalisation a une influence directe sur l’allure de la solution. Ce lien peut être expliqué dans un cadre probabiliste [Idier 2001]. En effet, suivant la règle de Bayes, la loi a posteriori de x s’écrit pX⑤Y ♣x ⑤ yq ✾ L♣y ⑤ xqpX ♣xq, (3.29) où L♣y ⑤ xq est la vraisemblance qui s’exprime à partir de la loi du bruit et pX ♣xq est la loi a priori de x (nous notons respectivement X et Y les variables aléatoires liées à x et y). En supposant le bruit gaussien centré de variance σ 2 b , on peut écrire pX⑤Y ♣x ⑤ yq ✾ 1 σb ❄ 2π ✟Ny exp ✂ ✁ 1 2σ 2 b ⑥y ✁ Gx⑥ 2 ✡ pX ♣xq. (3.30) 783.2 Minimisation d’un critère pénalisé La solution au sens du maximum a posteriori (MAP) consiste donc à prendre une solution qui maximise cette expression, pour une certaine loi a priori sur x. En prenant l’opposé du logarithme, on aboutit à une expression à minimiser ✁ ln pX⑤Y ♣x ⑤ yq ✏ 1 2σ 2 b ⑥y ✁ Gx⑥ 2 ✁ ln pX ♣xq constante, (3.31) qui peut directement s’interpréter par le critère pénalisé J ♣x, µq ✏ ⑥y ✁ Gx⑥ 2 µR♣xq. La fonction de régularisation respecte alors R♣xq ✾ ✁ ln pX ♣xq. (3.32) Dans le tableau 3.2, nous indiquons plusieurs exemples de fonctions de régularisation et de lois a priori associées. La régularisation quadratique induit donc une loi a priori gaussienne tandis que la norme `1 correspond à une loi de Laplace. Régularisation quadratique hyperbolique `p `1 R♣xq ✏ x 2 ❄ x 2 δ 2 ⑤x⑤ p ⑤x⑤ Loi a priori gaussienne « hyperbolique » gaussienne généralisée loi de Laplace pX ♣xq✾ e ✁x 2 ④T e ✁ ❄ x2δ 2④T e ✁⑤x⑤ p ④T e ✁⑤x⑤④T TABLE 3.2 – Exemples de lien entre fonction de régularisation R♣xq et loi a priori pX ♣xq de paramètre T. La régularisation de pseudo-norme `0 est un cas limite de la norme `p, plus délicate à formaliser en termes de loi a priori en raison de la nature discrète de la pseudo-norme `0. On peut cependant la mettre en relation avec une loi Bernoulli-gaussienne [Kormylo et Mendel 1982]. Celle-ci définit la présence ou l’absence d’un pic en tout point par un ensemble de variables binaires indépendantes suivant une loi de Bernoulli de paramètre λ, représentant la probabilité a priori de présence d’un pic en chaque point. Les amplitudes de ces pics sont représentées par des lois indépendantes gaussiennes, centrées, de variances σ 2 a . Soussen et al. [2011] montrent alors que la loi a priori correspondant à la régularisation de pseudo-norme `0 est un cas limite d’une loi Bernoulli-gaussienne où σ 2 a tend vers l’infini. Le paramètre de régularisation est alors lié au paramètre de la loi de Bernoulli par µ ✏ 2σ 2 b ln ♣1④λ ✁ 1q. 3.2.4 Réglage du paramètre de régularisation Le choix du paramètre de régularisation est primordial pour obtenir une solution satisfaisante [Fortier 1990]. En général, on calcule une collection de solutions correspondant à un ensemble de valeurs de µ. Le principe est ensuite de choisir une seule solution. Très souvent, on part d’un µ très grand qui minimise uniquement R♣xq, et on le fait décroître. Dans le cas de la pénalisation `1 par exemple, la continuation homotopique permet de trouver les valeurs de µ optimales pour avoir des solutions différentes pour chaque valeur de µ [Malioutov et al. 2005]. D’une façon générale, pour les régularisations favorisant la parcimonie, les solutions ont une cardinalité croissante lorsque µ diminue. Si la variance du bruit σ 2 b est connue, on peut alors sélectionner la solution dont le résidu respecte la loi du bruit [Fortier 1990]. On pourra de ce fait choisir la solution dont la norme du résidu ⑥y ✁ Gx♣⑥ 2 avoisine la norme du bruit ⑥b⑥ 2 ✔ Nyσ 2 b . Il est également possible de 79CHAPITRE 3 : Le problème inverse choisir la solution à partir d’un nombre de pics désiré. D’autres méthodes telles que la validation croisée [Wahba 1977, Hong et al. 2003] et la validation croisée généralisée [Golub et al. 1979] permettent de sélectionner une solution à partir de prédictions. Il existe également des critères informationnels qui permettent de choisir un compromis entre adéquation aux données et cardinalité [Akaike 1974, Rissanen 1983, Fitzgibbon et al. 2004, Stoica et Selén 2004, Selén et Larsson 2006]. Un exemple avec une application en déconvolution parcimonieuse pour le CND apparaît dans [Soussen et al. 2012]. Le réglage du paramètre ne fait pas l’objet d’une étude particulière dans cette thèse. Dans les exemples que nous montrons, il a été choisi par essai-erreur ou par adéquation au bruit contenu dans les données lorsque la variance de la loi du bruit est connue. 3.3 Régularisation par la pseudo-norme `0 3.3.1 Formulation du problème d’optimisation L’utilisation de la régularisation par cette norme dans les approches pénalisées apparaît peu souvent [Zala 1992, Rao et Kreutz-Delgado 1999, Soussen et al. 2011]. C’est pourtant cette norme qui fournit le vrai critère de parcimonie de la solution. Habituellement, le problème d’optimisation se formule de façon alternative par min ⑥x⑥0 sous contrainte ⑥y ✁ Gx⑥ 2 ➔ , (3.33) ou min ⑥y ✁ Gx⑥ 2 sous contrainte ⑥x⑥0 ➔ K. (3.34) Ces problèmes combinatoires sont connus pour être NP-difficiles [Natarajan 1995]. Sous certaines conditions strictes [Donoho et Elad 2003], ils peuvent être approximés par un problème d’optimisation relaxé convexe, utilisant par exemple une norme `1 [Chen et al. 1998]. Plus rigoureusement, ces problèmes sont analogues à la minimisation d’un critère composite pénalisé par la pseudo-norme `0 [Soussen et al. 2011] qui définit le problème d’optimisation ♣P0q : x♣ ✏ arg min x ⑥y ✁ Gx⑥ 2 µ ⑥x⑥0 . (3.35) Nous utilisons cette forme de problème d’optimisation dans la suite de ce manuscrit. La méthode optimale pour résoudre le problème P0 defini par l’équation (3.35) consiste à tester toutes les combinaisons du support de x, c’est-à-dire 2 Nx combinaisons [Miller 2002]. Cet examen est impossible à appliquer en un temps réaliste lorsque la taille du problème est importante ou quand le nombre de composantes dépasse quelques unités. Des méthodes sousoptimales existent et mettent en œuvre des heuristiques pour explorer un nombre limité de solutions. On peut tout d’abord citer quelques algorithmes gloutons (ou forward), matching pursuit (MP), orthogonal matching pursuit (OMP) et orthogonal least squares (OLS), qui partent d’une solution nulle et ajoute un seul élément à chaque itération [Mallat et Zhang 1993, Pati et al. 1993, Chen et al. 1989, Blumensath et Davies 2007]. La différence entre ces algorithmes réside en leur façon de réaliser la sélection. Un algorithme inspiré de OLS, single best replacement (SBR), a été proposé par Soussen et al. [2011] pour directement traiter le problème d’optimisation `0 (P0). Nous décrivons ces approches qui ont une complexité croissante ci-après. 803.3 Régularisation par la pseudo-norme `0 3.3.2 Méthodes d’optimisation par une approche gloutonne Notations Nous notons Qi le support actif de la solution à l’itération i, qui est une sélection du support complet t1, . . . , Nx✉. La solution correspondante est x♣i . Nous notons également Gi , la matrice composée des colonnes de G indexées par Qi . Pour plus de clarté, on définit la valeur du critère pour un µ donné par la notation JQi ✏ J ♣x♣i , µq ✏ ⑥y ✁ Gx♣i⑥ 2 µ ⑥x♣i⑥0 . (3.36) Nous verrons que cette notation n’est pas exacte pour l’algorithme matching pursuit. Pour les autres méthodes et celles que nous proposerons, elle est correcte car un support Qi donné entraîne une seule solution x♣i . Le résidu à l’itération i est noté ri et vérifie ri ✏ y ✁ Gx♣i . (3.37) A l’initialisation des algorithmes (i ✏ 0), la solution est nulle : x♣0 ✏ 0, le support actif est vide : Q0 ✏ ❍ et le critère est JQ0 ✏ ⑥y⑥ 2 . Le résidu est alors égal aux données : r0 ✏ y. Paramètre de régularisation maximal Il existe un paramètre de régularisation maximal µmax au delà duquel la solution respecte uniquement l’a priori et est donc nulle. Pour le déterminer, il faut calculer le critère à la première itération (le même pour tous les algorithmes ajoutant un élément) qui s’écrit JQ1 ✏ ⑥y ✁ gna⑥ 2 µ, (3.38) où gna est une colonne de G pondérée par une amplitude a. L’amplitude optimale étant ♣a ✏ g T n y④ ⑥gn ⑥ 2 , le critère peut s’écrire (se référer à l’équation (2.85) du chapitre 2) JQ1 ✏ ⑥y⑥ 2 ✁ ✎ ✎g T n y ✎ ✎ 2 ⑥gn ⑥ 2 µ. (3.39) Pour que JQ1 soit inférieur à JQ0 , il faut donc que µ ✁ ⑥g T n y⑥ 2 ⑥gn⑥ 2 soit inférieur à zéro. Le paramètre maximal µmax vérifie donc [Soussen et al. 2011] µmax ✏ max n ⑤g T n y⑤ 2 ⑥gn ⑥ 2 . (3.40) Matching Pursuit et Orthogonal Matching Pursuit Matching Pursuit (MP) [Mallat et Zhang 1993] et Orthogonal Matching Pursuit (OMP) [Pati et al. 1993] sont des algorithmes gloutons initialement conçus pour l’approximation parcimonieuse des signaux [Elad 2010]. Le but de cette technique est de modéliser le plus fi- dèlement un signal avec quelques éléments d’un dictionnaire, référencés dans le vecteur x. Dans ce cas, le dictionnaire n’est pas imposé par le problème inverse, mais est choisi pour représenter au mieux les données. Les algorithmes ne cherchent pas à minimiser le critère pénalisé et sont arrêtés par la cardinalité de la solution (voir équation (3.34)) ou par la norme 81CHAPITRE 3 : Le problème inverse du résidu (voir équation (3.33)). Ils peuvent néanmoins servir à explorer des solutions afin de minimiser le critère pénalisé J ♣x, µq (P0). Pour ces deux algorithmes, la sélection de l’élément à rajouter se fait grâce à un filtre adapté sur le résidu ri (voir les détails dans la partie 2.3.1 du chapitre 2). A l’itération i, la position et l’amplitude optimales sont celles qui minimisent l’erreur entre le résidu et une colonne de G ♣n, ♣ ♣aq ✏ arg min n,a ⑥ri✁1 ✁ agn ⑥ 2 . (3.41) Nous avons vu dans l’équation (2.86) du chapitre 2 que la position optimale est celle qui maximise le produit scalaire entre une colonne de G et le résidu n♣ ✏ arg max n❘Qi✁1 ⑤g T n ri✁1⑤ ⑥gn ⑥ 2 . (3.42) L’amplitude optimale est alors ♣a ✏ g T n♣ ri✁1④ ⑥gn♣ ⑥ 2 . La différence entre MP et OMP vient de la façon dont est mise à jour la solution, et donc le résidu. Pour MP, seul l’élément n♣ est modifié à chaque itération x♣irn♣s ✏ x♣i✁1rn♣s ♣a, (3.43) tandis que pour OMP, on calcule une solution x♣i dont l’approximation Gx♣i est orthogonale au résidu pour tout le support actif x♣i ✏ GT i Gi ✟✁1 GT i y. (3.44) Autrement dit, toutes les amplitudes du support actif sont remises à jour à chaque itération pour OMP. Par conséquent, MP met à jour le résidu par ri ✏ ri✁1 ✁ ♣agn♣ , (3.45) et OMP par ri ✏ y ✁ Gix♣i . (3.46) En pratique, l’algorithme OMP est plus efficace que MP car il remet en cause toutes les amplitudes de la solution courante. Il est récapitulé dans la table 3.3. Orthogonal Least Squares Le principe de l’algorithme Orthogonal Least Squares (OLS) [Chen et al. 1989] est de considérer a priori des solutions dont les approximations sont orthogonales au résidu. Dans OLS, l’idée est donc d’inclure l’estimation des amplitudes optimales dans la sélection du nouveau support. A l’inverse, OMP effectue l’orthogonalisation a posteriori, une fois la sélection effectuée. L’ajout d’une composante n ❘ Qi✁1 correspond à Gi ✏ rGi✁1, gn s. Pour l’ajout de la composante n, nous notons alors la différence du critère (3.36) : ∆J n Qi✁1 ✜ JQi✁1❨n ✁ JQi✁1 ✏ µ ✎ ✎ ✎y ✁ Gi GT i Gi ✟✁1 GT i y ✎ ✎ ✎ 2 ✁ ✎ ✎ ✎y ✁ Gi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1y ✎ ✎ ✎ 2 , (3.47) 823.3 Régularisation par la pseudo-norme `0 Initialisations : Q0 ✏ ∅, G0 ✏ ∅, JQ0 ✏ ⑥y⑥ 2 , r0 ✏ y, i ✏ 1 Algorithme : 1) n♣ ✏ arg max n❘Qi✁1 ⑤g T n ri✁1⑤④⑥gn ⑥ 2 2) Gi ✏ rGi✁1, gn♣ s 3) x♣i ✏ GT i Gi ✟✁1 GT i y 4) ri ✏ y ✁ Gix♣i 5) Calculer JQi (équation (3.36)) 6) si JQi ➔ JQi✁1 Qi ✏ Qi✁1 ❨ n♣ i ✏ i 1 aller à 1) sinon terminer fin si Sortie : x♣i✁1 TABLE 3.3 – Description de l’algorithme Orthogonal Matching Pursuit (OMP). celle-ci ne dépendant que de G, des données y, de l’indice n et de µ. La sélection de la composante optimale n♣ revient donc à minimiser le critère (3.47) telle que n♣ ✏ arg min n❘Qi✁1 ∆J n Qi✁1 . (3.48) Le calcul du critère (3.47) peut se faire efficacement de façon récursive en utilisant le lemme d’inversion de matrice partitionnée ou la factorisation de Cholesky [Soussen et al. 2011]. Cette dernière met en jeu des inversions de systèmes triangulaires qui sont rapides à calculer comparé aux inversions de systèmes complets. La factorisation de Cholesky permet d’écrire GT i Gi ✏ LiL T i où Li est une matrice triangulaire inférieure [Golub et al. 1979]. Il est possible d’identifier Li en posant GT i Gi ✏ ✒ GT i✁1Gi✁1 GT i✁1gn h T nGi✁1 ⑥gn ⑥ 2 ✚ ✏ LiL T i ✏ ✒ Li✁1 0 v T n an ✚ ✒L T i✁1 vn 0 an ✚ , (3.49) où vn ✏ L ✁1 i✁1GT i✁1gn et an ✏ ❜ ⑥gn ⑥ 2 ✁ ⑥vn⑥ 2 . (3.50) La matrice Li peut donc être construite récursivement à chaque itération. Après quelques manipulations détaillées en annexe C.1, le critère (3.47) s’écrit [Soussen et al. 2011] ∆J n Qi✁1 ✏ µ ✁ v T nL ✁1 i✁1GT i✁1y ✁ g T n y ✟2 ⑥gn ⑥ 2 ✁ ⑥vn⑥ 2 . (3.51) 83CHAPITRE 3 : Le problème inverse En posant ui✁1 ✏ L ✁1 i✁1GT i✁1y, (3.52) le critère (3.47) se calcule simplement par ∆J n Qi✁1 ✏ µ ✁ v T nui✁1 ✁ g T n y ✟2 ⑥gn ⑥ 2 ✁ ⑥vn⑥ 2 . (3.53) La solution x♣ peut être calculée par x♣i ✏ GT i Gi ✟✁1 GT i y ✏ L T i ✟✁1 L ✁1 i GT i y ✏ L T i ✟✁1 ui . (3.54) Étant donné qu’elle n’est pas nécessaire pour calculer le critère à chaque itération, elle est plutôt calculée à la fin de l’algorithme pour économiser du temps de calcul. L’algorithme OLS est récapitulé dans le tableau 3.4. Initialisations : Q0 ✏ ∅, L0 ✏ ∅, u0 ✏ ∅, i ✏ 1 Algorithme : 1) Calcul de vn, ❅n ❘ Qi✁1 (3.50) 2) n♣ ✏ arg min n❘Qi✁1 ∆J n Qi✁1 (3.53) 3) si ∆J n♣ Qi✁1 ➔ 0 Qi ✏ Qi✁1 ❨ n♣ Mise à jour de Li (3.49), ui (3.52) i ✏ i 1 aller à 1) sinon terminer fin si Sortie : x♣i✁1 ✏ ♣L T i✁1 q ✁1ui✁1 TABLE 3.4 – Description de l’algorithme Orthogonal Least Squares (OLS). En terme de nombre de combinaisons testées, pour un support final Q, les algorithmes gloutons explorent ➦card♣Qq i✏0 ♣Nx ✁ iq combinaisons (très loin des 2 Nx ). 3.3.3 L’agorithme Single Best Replacement L’algorithme Single Best Replacement (SBR) [Soussen et al. 2011] est dérivé de l’algorithme Single Most Likely Replacement (SMLR) [Kormylo et Mendel 1982, Mendel 1983, Goussard et al. 1990], qui a été développé pour la déconvolution parcimonieuse sous un modèle Bernoulli-gaussien. SBR est un algorithme dédié à la résolution du problème pénalisé P0 établi à l’équation (3.35). Il est basé sur l’algorithme glouton OLS : à chaque itération, il 843.3 Régularisation par la pseudo-norme `0 propose un ajout suivant la minimisation du critère (3.47), et pour i → 2, le retrait d’une composante. Le mouvement qui est sélectionné est celui qui fait le plus décroître le critère. SBR est un algorithme bi-directionnel (ou forward-backward) car il permet d’ajouter et de retirer des éléments du support. Par rapport aux algorithmes gloutons, la robustesse vient du fait qu’une fausse détection peut être annulée grâce à la possibilité de retrait. Le test pour le retrait d’un élément d’indice m P Qi✁1 est réalisé en calculant [Reeves 1999, Miller 2002] ∆J ✁m Qi✁1 ✏ ♣x♣i✁1rmsq2 γm ✁ µ, (3.55) où γm est le mème élément de la diagonale de GT i✁1Gi✁1 ✟✁1 et x♣i✁1rms est le mème élément de la solution à l’itération i ✁ 1. Le détail des calculs qui aboutissent à l’équation (3.55) est donné en annexe C.2. Le meilleur retrait est donc m♣ ✏ arg min mPQi✁1 ∆J ✁m Qi✁1 . (3.56) On retrouve cette procédure de retraits dans les algorithmes backward [Reeves 1999, Couvreur et Bresler 2000, Miller 2002], qui partent d’un support complet (correspondant à la solution de l’inverse généralisée) et enlèvent un élément à chaque itération. Cette approche est performante seulement lorsque le niveau de bruit est très faible. Pour résumer, à chaque itération, le mouvement qui aboutit à la plus faible valeur parmi ∆J n Qi✁1 pour n ❘ Qi✁1 et ∆J ✁m Qi✁1 pour m P Qi✁1 est sélectionné. Il faut noter que le minimum de ∆J ✁m Qi✁1 étant supérieur à ✁µ, si ∆J n Qi✁1 ➔ ✁µ, alors les retraits n’ont pas besoin d’être testés. Le détail de l’algorithme est donné dans le tableau 3.5. Pour une solution de support Q, on ne peut pas, contrairement aux algorithmes gloutons, prédire le nombre de combinaisons testées tant les mouvements d’ajout et de retrait peuvent mener à différents chemins possibles. Néanmoins, si tous les retraits sont testés pour i → 2 et qu’aucun retrait n’est effectué, les nombre de combinaisons testées est card ➳ ♣Qq i✏0 ♣Nx ✁ iq card ➳ ♣Qq i✏3 ♣i ✁ 1q. (3.57) Ce nombre est le minimum de combinaisons testées et reste très faible par rapport aux 2 Nx combinaisons possibles. L’algorithme SBR est à l’origine de nos travaux méthodologiques qui sont détaillés dans la section 3.4. Nous proposons d’une part, des mouvements multiples locaux (dans une fenêtre), et d’autre part, un algorithme qui utilise une information d’autocorrélation pour sélectionner les meilleures positions. 85CHAPITRE 3 : Le problème inverse Initialisations : Q0 ✏ ∅, L0 ✏ ∅, u0 ✏ ∅, i ✏ 1 Algorithme : 1) Calcul de vn, ❅n ❘ Qi✁1 (3.50) 2) n♣ ✏ arg min n❘Qi✁1 ∆J n Qi✁1 (3.53) 3) Pour i → 2 : m♣ ✏ arg min mPQi✁1 ∆J ✁m Qi✁1 (3.55) 4) si min ✁ ∆J n♣ Qi✁1 , ∆J ✁m♣ Qi✁1 ✠ ➔ 0 Qi ✏ Qi✁1 ❨ n♣ ou Qi ✏ Qi✁1③m♣ Mise à jour de Li (3.49), ui (3.52) i ✏ i 1 aller à 1) sinon terminer fin si Sortie : x♣i✁1 ✏ ♣L T i✁1 q ✁1ui✁1 TABLE 3.5 – Description de l’algorithme Single Best Replacement (SBR). 3.3.4 Comparaison des algorithmes gloutons et SBR Nous comparons ici les algorithmes gloutons (MP, OMP, OLS) et SBR pour résoudre le problème P0 à partir de données simulées. Le signal xq P R 200 à estimer est composé de 9 pics, de positions uniformément réparties dans r1, . . . , Nxs et d’amplitudes suivant une distribution gaussienne. Les données sont générées avec le modèle y ✏ Gxq b où G est une matrice de convolution associée à une forme d’onde gaussienne illustrée sur la figure 3.6a (Nh ✏ 51). Le bruit b respecte un rapport signal à bruit fixé à 25 dB (voir partie 3.2.1). Les données sont représentées sur la figure 3.6b. Le paramètre de régularisation est déterminé par une procédure d’adéquation aux données. Il est fixé à sa valeur maximale µmax établi à l’équation (3.40) et est géométriquement diminué. Lorsque le niveau du résidu ⑥y ✁ Gx♣i⑥ 2 , obtenu par SBR, est inférieur à la vraie norme du bruit ⑥b⑥ 2 ✏ ⑥y ✁ Gxq⑥ 2 , le paramètre courant est retenu. Même si cette méthode favorise SBR, elle offre l’avantage de comparer toutes les méthodes pour une même valeur de µ. Dans la partie 3.4.3, nous réaliserons des simulations en faisant varier la valeur de µ pour chaque algorithme. Les cardinalités de la solution et normes du résidu en fonction de µ pour l’exemple présenté sont tracées sur la figure 3.7. Comme attendu, la cardinalité augmente lorsque la norme du résidu diminue. Ces grandeurs évoluent par sauts à cause de la nature discrète de la pénalisation `0. En effet, pour un support donné, la solution est identique menant à une norme de résidu constante (d’une manière similaire aux algorithmes gloutons). Les résultats de déconvolution obtenus par MP, OMP, OLS et SBR sont respectivement présentés sur les figures 3.6c-d-e-f. La valeur du critère pour chaque algorithme est également affichée. Nous observons que cette valeur décroît quand la complexité des algorithmes 863.3 Régularisation par la pseudo-norme `0 10 20 30 40 50 −1 −0.5 0 0.5 1 (a) Forme d’onde 50 100 150 200 250 −2 −1 0 1 2 (b) Donn´ees et v´erit´e 50 100 150 200 −2 −1 0 1 2 (c) MP J (xb, µ) = 0.58946 50 100 150 200 −2 −1 0 1 2 (d) OMP J (xb, µ) = 0.44553 50 100 150 200 −2 −1 0 1 2 (e) OLS J (xb, µ) = 0.31884 50 100 150 200 −2 −1 0 1 2 (f) SBR J (xb, µ) = 0.28921 FIGURE 3.6 – Déconvolution par régularisation `0. (a) : Réponse impulsionnelle instrumentale avec f0 ✏ 5 MHz, BWR✁3 ✏ 0.3, φ ✏ ✁π④4, (b) : données avec RSB ✏ 25 dB (–) et vérité (+), (c) : vérité (+) et estimation par MP (✆), (d) vérité (+) et estimation par OMP (✆), (e) : vérité (+) et estimation par OLS (✆), (f) : vérité (+) et estimation par SBR (✆). augmente : MP, OMP, OLS puis SBR. Pour résumer, MP est plus sensible aux fausses dé- tections à cause de la non remise en cause des amplitudes de la solution. OMP donne à peu près le même résultat avec quelques fausses détections en moins. Les algorithmes OLS et SBR s’en sortent mieux grâce à une sélection plus raffinée. Il y a un avantage pour SBR qui parvient à supprimer quelques fausses détections grâce à sa possibilité de retraits. Pour tous les algorithmes, il est important de noter que la détection des deux pics centraux – autour de l’indice 100 – n’est pas réalisée. Ces échecs sont dûs au fait que la somme des deux échos crée une forme d’onde proche de l’ondelette de référence. Pour des algorithmes à détection simple, la position trouvée se situe donc au milieu des deux vrais pics. A partir de cet exemple, on peut conclure que les approches basées sur la sélection d’une seule composante par itération trouvent leur limite lorsque les échos sont fortement entremêlés. Il est par conséquent intéressant d’étudier des approches à détections multiples. Dans la suite de ce chapitre, nous considérons des algorithmes dérivant d’OLS dans lesquelles les amplitudes sont marginalisées. C’est-à-dire, pour un support Qi donné, la solution est de fait x♣i ✏ GT i Gi ✟✁1 GT i y. Le problème revient par conséquent à explorer des supports. 87CHAPITRE 3 : Le problème inverse 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 0 2 4 6 8 10 12 µ (a) Cardinalit´e (SBR) vraie valeur valeur SBR 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 0 0.5 1 1.5 2 2.5 3 3.5 4 µ (b) Norme du r´esidu (SBR) vraie valeur valeur SBR FIGURE 3.7 – Sélection du paramètre de régularisation par respect de la norme du bruit correspondant à l’exemple de la figure 3.6 pour l’algorithme SBR. Le paramètre qui donne la norme du résidu juste en dessous de la norme du bruit est sélectionné. (a) Cardinalité en fonction de µ, (b) norme du résidu en fonction de µ. 3.4 Des algorithmes plus efficaces d’optimisation `0 3.4.1 Mouvements plus complexes Sur un schéma similaire à l’algorithme SBR, il est possible de considérer des ajouts multiples, des retraits multiples et des remplacements multiples. Par exemple, pour l’ajout de deux composantes n1, n2 ❘ Qi✁1 la différence de critère s’écrit ∆J n1n2 Qi✁1 ✏ JQi✁1❨tn1,n2✉ ✁ JQi✁1 ✏ JQi✁1❨n1 ✁ JQi✁1 JQi✁1❨tn1,n2✉ ✁ JQi✁1❨n1 ✏ ∆J n1 Qi✁1 ∆J n2 Qi✁1❨n1 , (3.58) avec ∆J n2 Qi✁1❨n1 ✏ JQi✁1❨tn1,n2✉ ✁ JQi✁1❨n1 . Le calcul de la différence du critère pour deux ajouts est donc équivalent à la somme de deux mouvements simples. Ce principe s’étend de ce fait pour : • K insertions de n1, . . . , nK ❘ Qi✁1 : ∆J n1,...,nK Qi✁1 ✏ ∆J n1 Qi✁1 ∆J n2 Qi✁1❨n1 . . . ∆J nK Qi✁1❨tn1,...,nK✁1✉ . (3.59) 883.4 Des algorithmes plus efficaces d’optimisation `0 • L retraits de m1, . . . , mL P Qi✁1 ∆J ✁m1,...,✁mL Qi✁1 ✏ ∆J ✁m1 Qi✁1 ∆J ✁m2 Qi✁1③m1 . . . ∆J mL Qi✁1③tm1,...,mL✁1✉ . (3.60) • K insertions et L retraits de n1, . . . , nK ❘ Qi✁1, m1, . . . , mL P Qi✁1 ∆J n1,...,nK✁m1,...,✁mL Qi✁1 ✏ ∆J n1 Qi✁1 ∆J n2 Qi✁1❨n1 . . . ∆J nK Qi✁1❨tn1,...,nK✁1✉ ∆J ✁m1 Qi✁1❨tn1,...,nK✉ ∆J ✁m2 Qi✁1❨tn1,...,nK✉③m1 . . . ∆J ✁mL Qi✁1❨tn1,...,nK✉③tm1,...,mL✁1✉ . (3.61) Le coût de calcul augmente inévitablement si on augmente K et L. Par conséquent, nous allons plutôt orienter nos approches vers une exploration d’un nombre limité de combinaisons à tester. 3.4.2 Sélection dans une fenêtre La sélection dans une fenêtre a été proposée par Kaaresen dans les algorithmes Iterative Window Maximization (IWM) [Kaaresen 1997; 1998]. Le principe est de proposer des ajouts, retraits et remplacements multiples dans une fenêtre centrée autour d’un pic donné. Kaaresen [1997] se limite néanmoins à des mouvements doubles dans une fenêtre de quelques éléments. Nous proposons d’étendre ce principe à des mouvements plus généraux pour des fenêtres plus larges, jusqu’à par exemple deux fois la taille de la forme d’onde de référence. Nous notons Nw la taille de la fenêtre de calcul des mouvements multiples. Nous proposons un premier algorithme, basé sur SBR, mais avec des mouvements simples et doubles. Nous l’appelons Single or Double Best Replacement (SDBR). Il inclut à chaque itération le test 1. des ajouts simples : ∆J n Qi✁1 pour n ❘ Qi✁1, 2. des ajouts doubles : ∆J n1n2 Qi✁1 pour n1, n2 ❘ Qi✁1 et n1 ↕ n2 ↕ n1 Nw, 3. des remplacements : ∆J n✁m Qi✁1 pour n ❘ Qi✁1 et m P Qi✁1, 4. des retraits simples : ∆J ✁m Qi✁1 pour m P Qi✁1, 5. des retraits doubles : ∆J ✁m1✁m2 Qi✁1 pour m1 P Qi✁1 et m2 P Qi✁1③m1. Cet algorithme a un coût de calcul bien plus important que SBR car il teste tous les doubles ajouts dans une fenêtre de taille Nw, les remplacements et les doubles retraits. Kaaresen [1997] à proposé deux algorithmes : IWM1 et IWM2. IWM1 réalise les mouvements 1, 3 et 4 dans une fenêtre de cinq éléments, tandis que IWM2 effectue les mouvements 2, 3 et 5 dans une fenêtre de dix éléments. IWM2 permet également de séparer un pic en deux et de fusionner deux pics, qui sont en fait des mouvements d’ordre trois. Nous proposons ici un algorithme plus général avec des mouvements d’ordre deux. 89CHAPITRE 3 : Le problème inverse 10 20 30 40 50 −1 −0.5 0 0.5 1 (a) Forme d’onde 50 100 150 200 250 −2 −1 0 1 2 (b) Donn´ees et v´erit´e 50 100 150 200 −2 −1 0 1 2 (c) SBR J (xb, µ) = 0.28921 50 100 150 200 −2 −1 0 1 2 (d) SDBR (Nw = 5) J (xb, µ) = 0.27601 50 100 150 200 −2 −1 0 1 2 (e) SDBR (Nw = 25) J (xb, µ) = 0.26451 50 100 150 200 −2 −1 0 1 2 (f) SDBR (Nw = 50) J (xb, µ) = 0.26451 FIGURE 3.8 – Déconvolution par régularisation `0. (a) : Réponse impulsionnelle instrumentale avec f0 ✏ 5 MHz, BWR✁3 ✏ 0.3, φ ✏ ✁π④4, (b) : données avec RSB ✏ 25 dB (–) et vérité (+), (c) : vérité (+) et estimation par SBR (✆), (d) vérité (+) et estimation par SDBR (✆), (e) : vérité (+) et estimation par SDBR (✆), (f) : vérité (+) et estimation par SDBR (✆). Résultats à partir d’un exemple simulé Nous reprenons l’exemple de la figure 3.6 où la taille de la réponse impulsionnelle h est Nh ✏ 51. La valeur de µ est déterminée de la même façon que dans la partie 3.3.4, par respect de la norme du bruit avec SBR. Les algorithmes SBR et SDBR avec plusieurs tailles de fenêtre Nw ✏ 5, 25, 50 sont utilisés et les résultats sont présentés sur la figure 3.8. Les résultats numériques – pour les algorithmes gloutons, SBR et SDBR – sont récapitulés dans le tableau 3.6. Comme attendu, le critère et la norme du résidu baissent quand la complexité de JQ (0.276) ⑥y ✁ Gx♣⑥ 2 (0.196) card♣Qq (9) N. comb. temps (ms) MP 0.589 0.421 19 3810 4.5 OMP 0.446 0.295 17 3447 6.1 OLS 0.319 0.203 13 2709 7.7 SBR 0.289 0.183 12 3734 11.3 SDBR (Nw ✏ 5) 0.276 0.187 10 80217 496.5 SDBR (Nw ✏ 25) 0.265 0.185 9 65815 221.5 SDBR (Nw ✏ 50) 0.265 0.185 9 87202 188.2 TABLE 3.6 – Résultats issus des figures 3.6 et 3.8. JQ : valeur finale du critère, ⑥y ✁ Gx♣⑥ 2 : norme du résidu, card♣Qq : nombre de composantes non nulles de la solution estimée, N. comb. : nombre de combinaisons testées par l’algorithme, temps : temps de calcul. Les valeurs en la vérité xq, lorsqu’elles sont connues, sont affichées entre parenthèses. 903.4 Des algorithmes plus efficaces d’optimisation `0 l’algorithme augmente tandis que le nombre de combinaisons testées et le temps de calcul croissent. La cardinalité décroît quand la complexité augmente, signe de meilleures détections. Contrairement à SBR, SDBR parvient à détecter les deux pics autour de l’indice 100 et donc à faire baisser la valeur du critère. Pour Nw ✏ 5, les deux derniers pics sont mal dé- tectés. Sur cette portion de signal, ce résultat est moins bon que pour SBR car le chemin pris par l’algorithme a été légèrement modifié et mène à une moins bonne estimation des deux derniers pics. Pour Nw ✏ 25 et Nw ✏ 50, la solution a le bon support et est très proche de la séquence attendue. La norme du résidu est même inférieure à la norme du bruit ⑥y ✁ Gxq⑥ 2 . Cette différence s’explique par le fait que le résidu ⑥y ✁ Gx♣⑥ 2 est par définition, pour un même support, le résidu de norme minimale. La différence entre les deux approches SDBR (Nw ✏ 25 et Nw ✏ 50), qui renvoient la bonne solution, est le temps de calcul. Ces bonnes solutions sont obtenues grâce à un plus grand nombre de combinaisons testées, qui correspond forcément à un plus grand temps de calcul. Résultats issus de simulations de Monte-Carlo Nous réalisons ici 1000 simulations de Monte-Carlo avec une configuration voisine de la précédente : 8 pics uniformément positionnés dans r1, . . . , Nxs et d’amplitudes de distribution uniforme entre ✁1 et 1, Nx ✏ 200, RSB ✏ 20 dB. Nous testons cette fois trois tailles de fenêtres Nw ✏ 2, 11, 51. Les résultats numériques sont récapitulés dans le tableau 3.7. Comme observé dans l’exemple précédent, la valeur moyenne du critère, la norme du résidu JQ ⑥y ✁ Gx♣⑥ 2 card♣Qq N. comb. temps (ms) MP 0.656 0.130 15.9 3227 10.0 OMP 0.551 0.115 13.9 2863 9.9 OLS 0.464 0.098 13.6 2825 14.3 SBR 0.439 0.098 11.9 3399 17.2 SDBR (Nw ✏ 2) 0.429 0.099 11.0 33782 289.9 SDBR (Nw ✏ 11) 0.427 0.099 10.5 49991 279.1 SDBR (Nw ✏ 51) 0.411 0.098 9.5 90010 207.5 TABLE 3.7 – Résultats issus de 1000 simulations de Monte-Carlo pour des données aléatoires du type de celles illustrées sur la figure 3.6 (8 pics). JQ : valeur finale moyenne du critère, ⑥y ✁ Gx♣⑥ 2 : norme moyenne du résidu, card♣Qq : nombre de composantes non nulles de la solution estimée, N. comb. : nombre moyen de combinaisons testées par l’algorithme, temps : temps de calcul moyen. et la cardinalité baissent quand la complexité de l’algorithme augmente. Le nombre de combinaisons testées, et par conséquent le temps de calcul, ont tendance à augmenter avec la complexité. On remarque néanmoins que SDBR, avec Nw ✏ 2, a un temps de calcul moyen plus important, dû à un plus grand nombre d’itérations : une fenêtre trop petite a pour effet de favoriser les ajouts et retraits multiples successifs, ne permettant pas de détections doubles importantes. L’algorithme SDBR est plus efficace mais requiert un temps de calcul plus de dix fois supérieur à SBR. Plutôt que d’orienter nos développements vers des approches avec des mouvements plus complexes, qui accroissent les temps de calcul, nous choisissons de restreindre le nombre de possibilités de la sélection grâce à des calculs préalables. C’est ce que nous détaillons dans la prochaine partie. 91CHAPITRE 3 : Le problème inverse 3.4.3 Sélection basée sur un calcul d’auto-corrélation multidimensionnelle Définition d’une fonction d’auto-corrélation multidimensionnelle (FACM) Plutôt que de choisir uniformément dans une fenêtre les éléments à rajouter ou à enlever, nous proposons de calculer les éléments les plus corrélés à la forme d’onde de référence de façon à réaliser un nombre limité de tests. Cette approche est adaptée aux formes d’ondes oscillantes car les éléments les plus corrélées ne sont pas forcément situés sur un continuum, comme pour l’approche utilisant une fenêtre. Le principe est d’utiliser une information de type auto-corrélation pour proposer les positions à sélectionner. Nous considérons une colonne gn♣ de G. Le principe est de calculer les indices n1, . . . , nK tels que gn♣ peut être approximé par gn♣ ✔ ➳ K k✏1 akgn♣nk , (3.62) pour nk ✘ 0 et ❅k ✘ `, nk ✘ n` . Les ak sont des facteurs d’amplitude. Pour cela, nous cherchons à minimiser une erreur au sens des moindres carrés définie par ✎ ✎ ✎ ✎ ✎ ✎ ✎ gnˆ ✁ ✏ gnˆn1 . . . gnˆnK ✘ ✔ ✖ ✕ a1 . . . aK ✜ ✣ ✢ ✎ ✎ ✎ ✎ ✎ ✎ ✎ 2 2 . (3.63) Pour plus de simplicité et pour pouvoir faire les calculs au préalable, nous nous plaçons dans le cas d’un modèle de convolution où G ✏ H. H est alors une matrice de convolution où les colonnes sont des répliques décalées de h. Même si nous perdons la généralité de l’approche, cette approximation peut demeurer valide pour une atténuation raisonnable. Pour calculer l’expression (3.63), nous considérons une version de la réponse impulsionnelle avec insertion de zéros hr ✏ r0Nh , hr0s, . . . , hrNh ✁ 1s, 0Nh s T , où 0Nh est un vecteur ligne composé de Nh zéros. Les versions décalées d’une valeur m sont ensuite définies par hr ♣mq ✏ r0Nhm, hr0s, . . . , hrNh ✁ 1s, 0Nh✁ms T avec m ✏ ✁Nh, . . . , Nh. H étant une matrice de convolution, la fonction de l’équation (3.63) à minimiser n’est plus dépendante de n♣ et devient ✎ ✎ ✎ ✎ ✎ ✎ ✎ hr ✁ ✑ hr ♣n1q . . . hr ♣nKq ✙ ✔ ✖ ✕ a1 . . . aK ✜ ✣ ✢ ✎ ✎ ✎ ✎ ✎ ✎ ✎ 2 2 . (3.64) Nous définissons la matrice Hr ♣n1...nKq ✏ ✑ hr ♣n1q , . . . , hr ♣nKq ✙ . Les amplitudes optimales ♣a1 . . . ♣aK peuvent alors être calculées par ✔ ✖ ✕ ♣a1 . . . ♣aK ✜ ✣ ✢ ✏ ✁ Hr ♣n1...nKqTHr ♣n1...nKq ✠✁1 Hr ♣n1...nKqThr. (3.65) 923.4 Des algorithmes plus efficaces d’optimisation `0 A partir de cette expression, on peut calculer la fonction de l’équation (3.64) qui ne dépend plus des amplitudes ✎ ✎ ✎ ✎ ✎ ✎ ✎ hr ✁ ✑ hr ♣n1q . . . hr ♣nKq ✙ ✔ ✖ ✕ a1 . . . aK ✜ ✣ ✢ ✎ ✎ ✎ ✎ ✎ ✎ ✎ 2 2 ✏ ✎ ✎ ✎ ✎ hr ✁ Hr ♣n1...nKq ✁ Hr ♣n1...nKqTHr ♣n1...nKq ✠✁1 Hr ♣n1...nKqThr ✎ ✎ ✎ ✎ 2 2 ✏ ✎ ✎ ✎ hr ✎ ✎ ✎ 2 2 ✁ ✎ ✎ ✎ ✎ Hr ♣n1...nKq ✁ Hr ♣n1...nKqTHr ♣n1...nKq ✠✁1 Hr ♣n1...nKqThr ✎ ✎ ✎ ✎ 2 2 . (3.66) La minimisation de cette expression revient en fait à maximiser une fonction, que nous appelons fonction d’auto-corrélation multidimensionnelle (FACM) FK♣n1 . . . nKq ✏ ✎ ✎ ✎ ✎ Hr ♣n1...nK ✁ Hr ♣n1...nKqTHr ♣n1...nKq ✠✁1 Hr ♣n1...nKqThr ✎ ✎ ✎ ✎ 2 2 . (3.67) Les valeurs élevées de cette fonction indiquent que les indices correspondants produisent une combinaison linéaire de formes d’onde décalées (3.62) proche de la forme d’onde initiale. Par exemple, pour K ✏ 1, la FACM est F1♣n1q ✏ ✎ ✎ ✎ ✎ hr ♣n1q ✁ hr ♣n1qT hr ♣n1q ✠✁1 hr ♣n1qT hr ✎ ✎ ✎ ✎ 2 2 ✏ ✎ ✎ ✎ hr ♣n1qT hr ✎ ✎ ✎ 2 ✎ ✎ ✎ hr ♣n1q ✎ ✎ ✎ 2 . (3.68) Maximiser F1♣n1q revient donc à maximiser ⑤hr ♣n1qT hr⑤, qui est la valeur absolue de l’autocorrélation de hr en n1. Nous illustrons des exemples de telles fonctions pour K ✏ 1 et K ✏ 2 sur les figures 3.9 et 3.10. Seuillage de la FACM Dans le but de réduire le nombre de combinaisons à tester, nous introduisons un seuillage de la FACM tel que FK♣n1 . . . nKq ➙ , (3.69) où  est la valeur du seuil de la FACM. Pour limiter encore le nombre de combinaisons à tester, nous écartons les indices qui donnent une amplitude de la FACM trop faible : ⑤♣ak♣n1, . . . , nKq⑤ ➙ δ ❅k ✏ 1, . . . , K. (3.70) Cela revient à supprimer par exemple le cas où l’une des amplitudes est quasiment nulle, et toutes les autres ont des amplitudes significatives. Ce point sera mis en évidence dans un exemple ci-après. Un exemple de fonction F1♣n1q, pour la forme d’onde de la figure 3.6, est représenté sur la figure 3.9b. On ne garde alors que les indices qui ont une valeur de FACM supérieure au seuil . Les amplitudes optimales sont tracées sur la figure 3.9c et celles supérieures a δ sont retenues. Nous observons ici que le seuillage sur les amplitudes n’a pas d’impact sur la sélection. Les positions sélectionnées qui vérifient F1♣n1q ➙  et ⑤♣a♣n1q⑤ 93CHAPITRE 3 : Le problème inverse −50 −40 −30 −20 −10 0 10 20 30 40 50 −0.4 −0.2 0 0.2 0.4 (a) Forme d’onde eh −50 −40 −30 −20 −10 0 10 20 30 40 50 0 0.2 0.4 0.6 0.8 1 n1 F1(n1) (b) Fonction F1(n1) fonction s´election seuil ǫ −50 −40 −30 −20 −10 0 10 20 30 40 50 0 0.2 0.4 0.6 0.8 1 n1 |ba(n1)| (c) Amplitudes optimales amplitudes s´election seuil δ FIGURE 3.9 – Exemple de FACM pour K ✏ 1 avec  ✏ 0.4 and δ ✏ 0.2. (a) : Forme d’onde de référence h♣, (b) : fonction F1♣n1q (–), seuil  (- -) et sélection F1♣n1q ➙  (✆), (c) : amplitudes optimales aˆ♣n1q, seuil δ (- -) et sélection (✆). sont représentées par des ronds blancs. Sur la figure 3.10, nous présentons la FACM associée à la même forme d’onde pour K ✏ 2. La fonction F2♣n1, n2q est représentée sur la figure 3.10a et les deux matrices d’amplitudes, ⑤♣a1♣n1, n2q⑤ et ⑤♣a2♣n1, n2q⑤, sont affichées sur les figures 3.10b et 3.10c. La sélection, après seuillage sur la fonction seulement, est repré- sentée par des pixels blancs sur la figure 3.10d. On observe ici qu’il y a des positions sélectionnées alors qu’elles correspondent à de très faibles amplitudes ⑤♣a1♣n1, n2q⑤ ou ⑤♣a2♣n1, n2q⑤. Cela prouve l’intérêt d’utiliser un seuillage sur l’amplitude également. C’est ce qui est réalisé sur la figure 3.10e où les positions correspondant aux amplitudes inférieures à δ sont retirées. La figure 3.10f montre les positions sélectionnées suite au retrait des doublons dûs à la symétrie entre les indices. Sur la figure 3.11, nous montrons le nombre de combinaisons sélectionnées en fonction du seuil , le seuil δ étant fixé à zéro. Comme attendu, le nombre de combinaisons sélectionnées augmente avec K. Nous proposons de choisir un nombre constant de combinaisons à tester pour chaque valeur de K. On peut par exemple définir un degré de complexité supplé- mentaire par rapport à SBR. Nous notons Nc le nombre de combinaisons supplémentaires pour chaque valeur de K. L’algorithme MOBR Nous proposons un algorithme appelé Multiple Optimized Best Replacement (MOBR) qui est similaire à SBR, mais qui propose également à chaque itération un ensemble de mouve- 943.4 Des algorithmes plus efficaces d’optimisation `0 n1 n2 (a) Fonction F2(n1, n2) −50 0 50 −50 0 50 0 0.5 1 n1 n2 (b) |ba1(n1, n2)| −50 0 50 −50 0 50 0 0.5 1 n1 n2 (c) |ba2(n1, n2)| −50 0 50 −50 0 50 0 0.5 1 n1 n2 (d) S´election 1 −50 0 50 −50 0 50 0 0.5 1 n1 n2 (e) S´election 2 −50 0 50 −50 0 50 0 0.5 1 n1 n2 (f) S´election 3 −50 0 50 −50 0 50 0 0.5 1 FIGURE 3.10 – Exemple de FACM pour K ✏ 2 avec  ✏ 0.4 and δ ✏ 0.2. (a) : fonction F2♣n1, n2q, (b) : amplitudes optimales ⑤♣a1♣n1, n2q⑤, (c) : amplitudes optimales ⑤♣a2♣n1, n2q⑤, (d) : sélection sur la fonction F2♣n1, n2q ➙ , (e) : sélection sur la fonction F2♣n1, n2q ➙  et les amplitudes ⑤♣a1♣n1, n2q⑤ ➙ δ et ⑤♣a2♣n1, n2q⑤ ➙ δ, (f) : suppression des doublons à partir de (e). 95CHAPITRE 3 : Le problème inverse 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 20 40 60 80 100 ǫ (a) K = 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 1000 2000 3000 4000 5000 ǫ (b) K = 2 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 x 105 ǫ (c) K = 3 FIGURE 3.11 – Nombre de combinaisons retenues à partir de la FACM en fonction du seuil  pour (a) K ✏ 1, (b) K ✏ 2 et (c) K ✏ 3 (avec δ ✏ 0). ments à K composantes basé sur le calcul de la FACM (équation (3.67)). Les tests des ajouts et retraits simples sont identiques à SBR. Néanmoins, lorsqu’un indice n♣ est ajouté, nous proposons deux types de mouvements. Dans un premier temps, il est possible de rajouter K ✁ 1 composantes à n♣, ce qui se traduit en terme de support par Qi ✏ Qi✁1 ❨ tn, ♣ n♣ n1, . . . , n♣ nK✁1✉ . (3.71) La seconde possibilité est de remplacer n♣ par K contributions telles que Qi ✏ Qi✁1 ❨ tn♣ n1, . . . , n♣ nK✉ . (3.72) Pour une valeur de K, les indices correspondants sont calculés à partir de la FCAM FK♣n1 . . . nKq. Une description de l’algorithme est donnée dans le tableau 3.8. L’algorithme MOBR est plus complexe que SBR puisqu’il autorise des ajouts multiples après la phase d’un ajout unique. Résultats à partir d’un exemple simple Nous reprenons l’exemple de la figure 3.6 où le paramètre µ est réglé par SBR pour respecter la norme du bruit (voir partie 3.3.4). L’algorithme MOBR est utilisé avec K ✏ 1 et K ✏ 2, avec  ✏ 0.9, 0.7, 0.5 et δ ✏ 0.1. Les résultats de déconvolution sont affichés sur la fi- gure 3.12. On remarque que les valeurs du critère sont inférieures à celle de SBR et baissent quand  diminue. En termes de détection des pics, les algorithmes MOBR fournissent de meilleures solutions que SBR, MOBR pour  ✏ 0.5 fournissant une solution proche de la 963.4 Des algorithmes plus efficaces d’optimisation `0 Initialisations : Q0 ✏ ∅ pour K = 1 à Kmax faire ❅k P r1, . . . , Ks : n1 . . . nK P tFK♣n1 . . . nKq ➙  & ♣ak♣n1 . . . nKq ➙ δ✉ fin pour i ✏ 1 Algorithme : 1) calculer n♣ ✏ arg min n❘Qi✁1 ∆J n Qi✁1 pour K = 1 à Kmax faire 2) Proposer Qi ✏ Qi✁1 ❨ tn, ♣ n♣ n1, . . . , n♣ nK✁1✉ 3) Proposer Qi ✏ Qi✁1 ❨ tn♣ n1, . . . , n♣ nK✉ fin pour 4) Calculer m♣ ✏ arg min mPQi✁1 ∆J ✁m Qi✁1 choisir le mouvement qui minimise JQi parmi 1, 2, 3, 4 si JQi ➔ JQi✁1 mettre à jour Qi i ✏ i 1 aller à 1) sinon terminer fin si Sortie : x♣i TABLE 3.8 – Description de l’algorithme Multiple Optimized Best Replacement (MOBR). JQ (0.276) ⑥y ✁ Gx♣⑥ 2 (0.196) card♣Qq (9) N. comb. temps (ms) SBR 0.289 0.183 12 3734 11.3 SDBR (Nw ✏ 5) 0.276 0.187 10 80217 496.5 SDBR (Nw ✏ 25) 0.265 0.185 9 65815 221.5 SDBR (Nw ✏ 50) 0.265 0.185 9 87202 188.2 MOBR ( ✏ 0.90) 0.280 0.173 12 3667 49.4 MOBR ( ✏ 0.70) 0.278 0.180 11 5336 147.7 MOBR ( ✏ 0.50) 0.265 0.185 9 3840 156.1 TABLE 3.9 – Résultats issus des figures 3.6, 3.8 et 3.12. Les valeurs réélles, lorsqu’elles sont connues, sont affichées entre parenthèses. séquence attendue. Des résultats numériques associés sont récapitulés dans le tableau 3.9. Les algorithmes MOBR ont un niveau de performance équivalent aux algorithmes SDBR, pour beaucoup moins de combinaisons testées et des temps de calcul inférieurs. Le com- 97CHAPITRE 3 : Le problème inverse 10 20 30 40 50 −1 −0.5 0 0.5 1 (a) Forme d’onde 50 100 150 200 250 −2 −1 0 1 2 (b) Donn´ees et v´erit´e 50 100 150 200 −2 −1 0 1 2 (c) SBR J (xb, µ) = 0.28921 50 100 150 200 −2 −1 0 1 2 (d) MOBR (ǫ = 0.9) J (xb, µ) = 0.27955 50 100 150 200 −2 −1 0 1 2 (e) MOBR (ǫ = 0.7) J (xb, µ) = 0.27805 50 100 150 200 −2 −1 0 1 2 (f) MOBR (ǫ = 0.5) J (xb, µ) = 0.26451 FIGURE 3.12 – Déconvolution par régularisation `0. (a) : Réponse impulsionnelle instrumentale avec f0 ✏ 5 MHz, BWR✁3 ✏ 0.3, φ ✏ ✁π④4, (b) : données avec RSB ✏ 25 dB (–) et vérité (+), (c) : vérité (+) et estimation par SBR (✆), (d) vérité (+) et estimation par MOBR pour  ✏ 0.9 (✆), (e) : vérité (+) et estimation par MOBR pour  ✏ 0.7 (✆), (f) : vérité (+) et estimation par MOBR pour  ✏ 0.5 (✆). promis entre nombre de combinaisons testées et temps de calcul est néanmoins en défaveur de MOBR, ce que nous attribuons à l’implémentation Matlab. En effet, la mise en œuvre de MOBR, qui doit réaliser une recherche et faire des tests sur des segments de positions, est plus lente que SDBR. Nous reviendrons sur ce constat dans la prochaine partie où nous réalisons des simulations de Monte-Carlo. Résultats issus de simulations de Monte-Carlo Dans cette partie, nous réalisons 5000 simulations de Monte-Carlo. Nous choisissons une séquence xq P R 200 composée de 6 pics, de positions aléatoires uniformément réparties et d’amplitudes aléatoires uniformes entre ✁1 et 1. Nous utilisons les algorithmes gloutons (MP, OMP, OLS), SBR, SDBR avec Nw ✏ 25, 50 et MOBR avec un nombre de combinaisons supplémentaires Nc ✏ 20, 200, K ✏ 1 et K ✏ 2. Les données sont générées avec un bruit gaussien (RSB ✏ 25 dB). Les données sont divisées par ❄ µmax pour avoir une nouvelle valeur maximale µmax ✏ 1 au-delà de laquelle la solution est nulle (voir équation (3.40)). Afin de comparer équitablement les algorithmes, plusieurs valeurs de µ ↕ 1 sont utilisées. Nous traçons plusieurs résultats en fonction de µ sur la figure 3.13. La valeur finale du critère en fonction de µ est tracée sur la figure 3.13a pour tous les algorithmes. Les algorithmes ayant les plus faibles valeurs de critère sont SDBR et MOBR, suivis de SBR et OLS. A partir des valeurs du cri- 983.4 Des algorithmes plus efficaces d’optimisation `0 −5 −4 −3 −2 −1 0 −2.5 −2 −1.5 −1 −0.5 0 0.5 log (µ) log J (bx, µ) (a) Crit`ere −5 −4 −3 −2 −1 0 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 log (µ) kˇx − bxk / kˇxk (b) Erreur sur xb −5 −4 −3 −2 −1 0 1 2 3 4 5 6 7 8 log (µ) (c) Classement −5 −4 −3 −2 −1 0 0 5 10 15 20 25 30 log (µ) Card( bx) (d) Cardinalit´e MP OMP OLS SBR SDBR (Nw = 25) SDBR (Nw = 50) MOBR (Nc = 20) MOBR (Nc = 200) FIGURE 3.13 – Résultats issus de simulations de Monte-Carlo en fonction du paramètre de régularisation µ (en echelle logarithmique). (a) : Critère pénalisé final J ♣x♣, µq, (b) : erreur de x♣ par rapport à xq, (c) : classement des algorithmes en fonction du critère pénalisé, (d) : cardinalité des solutions x♣. tère pour chaque algorithme, un classement moyen est établi sur la figure 3.13c (le premier ayant la plus faible valeur de critère). Comme attendu avec les valeurs des critères, l’ordre du classement est le suivant : SDBR, MOBR, SBR, OLS, OMP, MP. Sur la figure 3.13b, nous traçons l’erreur de x♣ par rapport à xq en fonction de µ. Ces courbes respectent les ré- sultats établis précédemment. Pour les méthodes OLS, SBR, MOBR et SDBR, on remarque que les valeurs optimales de µ se situent à peu près au même endroit (✒ 10✁3.5 ). On peut distinguer quatre classes de méthodes : SDBR, MOBR, SBR/OLS et OMP/MP. Les cardinalités des solutions sont également tracées sur la figure 3.13d et baissent quand la complexité de l’algorithme augmente. Un algorithme peu performant a en effet tendance à favoriser de nombreuses fausses détections. Sur les figures 3.14a et 3.14b sont tracés le temps de calcul ainsi que le nombre de combinaisons testées en fonction de µ. On remarque que les deux algorithmes MOBR ont un temps de calcul intermédiaire entre SBR et SDBR. Le nombre de combinaisons testées est lui du même ordre de grandeur que SBR. Nous traçons également, sur les figures 3.14c et 3.14d, l’erreur sur x♣ en fonction du temps de calcul et du nombre de combinaisons testées. 99CHAPITRE 3 : Le problème inverse Pour Nc ✏ 20, on remarque que les performances de MOBR sont légèrement inférieures à −5 −4 −3 −2 −1 0 0 20 40 60 80 100 120 140 160 180 log (µ) t [ms] (a) Temps de calcul −5 −4 −3 −2 −1 0 2 2.5 3 3.5 4 4.5 5 5.5 log (µ) log(Nb. comb.) (b) Nombre de combinaisons test´ees −1 −0.5 0 0.5 1 1.5 2 2.5 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 (c) Erreur sur xb log(temps de calcul) kˇx − bxk / kˇxk MP OMP OLS SBR SDBR (Nw = 25) SDBR (Nw = 50) MOBR (Nc = 20) MOBR (Nc = 200) 2 2.5 3 3.5 4 4.5 5 5.5 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 (d) Erreur sur xb log(nombre de combinaisons) kˇx − bxk / kˇxk FIGURE 3.14 – Résultats des temps de calcul et du nombre de combinaisons testées issus de simulations de Monte-Carlo pour chaque algorithme. (a) : Temps de calcul est fonction de µ, (b) : nombre de combinaisons testées en fonction de µ, (c) : Erreur sur x♣ en fonction du temps de calcul, (d) : erreur sur x♣ en fonction du nombre de combinaisons testées. celles de SDBR, mais pour un temps de calcul inférieur et un nombre de combinaisons testées de l’ordre de SBR ou OLS. Pour Nc ✏ 200, le temps de calcul est légèrement inférieur à celui de SDBR, alors que le nombre de combinaisons testées est bien inférieur. Nous attribuons cette différence à l’implémentation sous Matlab. Comme évoqué plus haut, les recherches et indexations des différentes positions dans MOBR sont plus lentes que pour SDBR. Ce dernier teste en effet de façon brute des plages « continues » d’indices alors que MOBR exploite des listes d’indices. De plus, l’algorithme MOBR fonctionne pour n’importe quelle valeur de K alors que SDBR est adapté pour K ✏ 2. Nous sommes convaincus qu’une implémentation sous un autre langage serait bénéfique pour les approches de type MOBR. Nous avons donc montré qu’il est possible d’obtenir des performances plus élevées que SBR pour un nombre de combinaisons testées du même ordre de grandeur. L’approche MOBR explore en effet une quantité limitée de supports grâce à la proposition de mouvements adaptés basée sur la connaissance a priori de la fonction d’auto-corrélation multidimensionnelle, qui ne dépend que de la réponse impulsionnelle. 100Chapitre 4 Déconvolution parcimonieuse sur-échantillonnée Sommaire Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.1 Modèle sur-échantillonné et MISO . . . . . . . . . . . . . . . . . . . . 102 4.1.1 Convolution discrète sur-échantillonnée . . . . . . . . . . . . . . 102 4.1.2 Système MISO . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.2 Facteur de sur-échantillonnage . . . . . . . . . . . . . . . . . . . . . . 104 4.3 Algorithmes de déconvolution . . . . . . . . . . . . . . . . . . . . . . 105 4.3.1 Calcul rapide de la convolution discrète . . . . . . . . . . . . . . 106 4.3.2 Détails de mise en œuvre des algorithmes . . . . . . . . . . . . . 107 4.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.4.1 Outils de mesure de l’erreur d’estimation . . . . . . . . . . . . . 108 4.4.2 Résultats issus de données simulées . . . . . . . . . . . . . . . . 110 4.4.3 Simulations de Monte-Carlo . . . . . . . . . . . . . . . . . . . . 112 4.4.4 Résultats expérimentaux . . . . . . . . . . . . . . . . . . . . . . 113 Introduction Dans ce chapitre, nous nous plaçons dans le cas d’un modèle de convolution continue entre un train d’impulsions et la réponse instrumentale, le but étant d’identifier les temps d’arrivée et les amplitudes des échos. Le train d’impulsions contient donc des pics qui ont des positions temporelles continues. Grâce à un modèle de convolution discrète, l’approche classique permet de restituer un train d’impulsions à la résolution des données, i.e. la période d’échantillonnage. Nous proposons dans ce chapitre de discrétiser la convolution continue de façon plus précise grâce à un sur-échantillonnage du modèle. On peut alors estimer le train d’impulsions à une résolution plus fine que celle des données. Dans la section 4.1, le modèle sur-échantillonné est présenté. Nous montrons qu’il est équivalent à un système à entrées multiples et sortie unique (Multiple Input Single Output), 101CHAPITRE 4 : Déconvolution parcimonieuse sur-échantillonnée où chaque voie est un filtre numérique de réponse impulsionnelle finie. Dans la troisième section, nous donnons un éclairage sur le réglage du facteur de sur-échantillonnage. Nous proposons ensuite d’adapter quelques algorithmes de déconvolution parcimonieuse pour les systèmes MISO dans la section 4.3. Enfin, la section 4.4 présente des résultats de déconvolution parcimonieuse avec des données synthétiques et réelles. Ce chapitre est en partie tiré des publications [Carcreff et al. 2012], [Carcreff et al. 2013a] et [Carcreff et al. 2013b]. 4.1 Modèle sur-échantillonné et système MISO 4.1.1 Convolution discrète sur-échantillonnée Pour un modèle sans atténuation, nous avons montré dans la section 2.2 que les données pouvaient être modélisées par la convolution continue y♣tq ✏ ➺ τ h♣t ✁ τ qx♣τ qdτ, (4.1) où h♣tq est la réponse instrumentale1 et x♣tq est le train d’impulsions à estimer. Pour des données à temps discret yrns ✏ y♣nTSq avec TS la période d’échantillonnage, une discrétisation de l’intégrale par la méthode des rectangles avec un pas ∆t aboutit à yrns ✏ ∆t ➳ m h♣nTS ✁ m∆tqx♣m∆tq. (4.2) Dans le modèle classique de convolution discrète, ∆t est égal à la période d’échantillonnage. Le vecteur x a alors la même résolution que les données. Il est néanmoins possible de considérer un pas de discrétisation plus précis ∆t ✏ TS④K où K → 1 est un facteur de sur-échantillonnage. En incluant la constante ∆t dans x, on peut dans ce cas écrire le modèle des données à temps discret sous la forme yrns ✏ ➳ m hrnK ✁ msxrms. (4.3) Cette écriture a une forme compacte y ✏ Hx. (4.4) Pour K ✏ 1, la matrice H a une structure de Toeplitz2 [Gray 2006]. Pour K ✘ 1, elle est équivalente à la concaténation des K matrices de Toeplitz que nous notons ✍H k , pour k ✏ 1, . . . , K. Sur la figure 4.1, un exemple de matrices H pour K ✏ 1 et K ✏ 4 est montré. La matrice pour K ✏ 4 a K fois plus de colonnes que celle correspondant à K ✏ 1. Le modèle est par conséquent équivalent à y ✏ ✑ ✍H 1 . . . ✍H K ✙ ✔ ✖ ✕ x 1 . . . x K ✜ ✣ ✢ ✏ ➳ K k✏1 ✍H k x k , (4.5) 1Pour davantage de clarté dans ce chapitre, la réponse instrumentale hi♣tq sera notée h♣tq et la matrice Hi , H. 2Nous notons ✍H une matrice H de Toeplitz qui est donc une matrice de convolution. 1024.1 Modèle sur-échantillonné et MISO ✍H (K ✏ 1) H (K ✏ 4) FIGURE 4.1 – Exemple de matrices H pour K ✏ 1 et pour K ✏ 4. où chaque matrice ✍H k est de Toeplitz. Une matrice de convolution ✍H k est associée à un filtre de réponse impulsionnelle h k . Les vecteurs h k et x k sont donc à la résolution de y. Les données peuvent par conséquent être modélisées par K produits de convolution yrns ✏ ➳ K k✏1 h k ✝ x k ✏ ➳ K k✏1 ➳ m h k rn ✁ msx k rms, (4.6) où chaque vecteur h k est défini par h k r`s ✏ hrK` k ✁ 1s ✏ h ♣`TS ♣k ✁ 1q∆tq. (4.7) Sur la figure 4.2, un exemple de lien entre h et les h k est exposé pour K ✏ 3. h hk , k ✏ 1 . . . K FIGURE 4.2 – Exemple de désentrelacement de h pour obtenir les h k avec K ✏ 3. En pratique, les h k peuvent être obtenus par sur-échantillonnage de la réponse instrumentale mesurée, qui est échantillonnée à la fréquence FS. Le sur-échantillonnage peut-être effectué dans le domaine temporel en insérant K ✁ 1 zéros entre chaque échantillon, puis en appliquant un filtre passe-bas de fréquence de coupure F s④2. 4.1.2 Système MISO D’après la partie précédente, les données peuvent être définies par K produits de convolution discrète y ✏ ➳ K k✏1 h k ✝ x k . (4.8) 103CHAPITRE 4 : Déconvolution parcimonieuse sur-échantillonnée De façon générique, cette écriture se rapporte à un système à entrées multiples et sortie unique où chaque voie correspond à un filtre de réponse impulsionnelle finie h k . Le schéma d’un tel système est représenté sur la figure 4.3. Dans la suite de ce chapitre, le but est h 1 h 2 h 3 h K x 1 x 2 x 3 x K y b b b FIGURE 4.3 – Schéma d’un système Multiple Input Single Output (MISO). de retrouver les entrées x k du système MISO composé de K filtres h k (k ✏ 1, . . . , K). Même si notre application est la super-résolution de la déconvolution parcimonieuse, les algorithmes développés peuvent s’adapter à d’autres types de problèmes où les filtres n’ont pas de lien entre eux. 4.2 Facteur de sur-échantillonnage Nous nous intéressons au réglage du facteur de sur-échantillonnage K. En effet, le coût de calcul des algorithmes d’estimation va naturellement augmenter en fonction de K. Il faut donc trouver un compromis entre coût de calcul et résolution de reconstruction. De surcroît, la qualité de l’estimation des temps de retard est limitée par le contenu fréquentiel de l’écho recherché et par le niveau de bruit [Quazi 1981, Demirli et Saniie 2001a]. Par exemple, dans [Quazi 1981], la variance minimale sur l’estimation d’un temps de retard pour un signal à temps continu est σ 2 ✏ 3 8π 2T 1 RSB 1 f 3 2 ✁ f 3 1 , (4.9) où T est la durée d’observation, f1 et f2 sont les bornes de la bande passante du signal et RSB est le Rapport Signal à Bruit. Pour illustrer cette partie, nous nous plaçons dans le cas discret d’une seule forme d’onde gaussienne de fréquence centrale 5 MHz et de 40 % de facteur de bande passante (figure 4.4a). Les données sont composées de cette forme d’onde retardée d’un temps continu et d’un bruit additif gaussien de RSB ✏ 0 dB, échantillonnées à 50 MHz (figure 4.4b). Nous estimons alors de façon optimale la position de l’écho par un calcul d’intercorrélation entre la forme d’onde et les données, pour 100000 réalisations de bruit. Les histogrammes de l’estimation du temps de retard, pour respectivement K ✏ 1, 4, 10, 20, sont tracés respectivement sur les figures 4.4c, 4.4d, 4.4e et 4.4f. Pour chaque valeur de K, la grille de reconstruction est également représentée sur les figures. La dispersion intrinsèque à ce problème, donnée par l’équation (4.9) est de ✟σ ✏ ✟3.43 ns. Pour K ✏ 1, l’erreur est importante comparée à σ alors que pour les modèles sur-échantillonnés, l’estimation est davantage en accord avec σ. 1044.3 Algorithmes de déconvolution 0 0.2 0.4 0.6 −1 −0.5 0 0.5 1 temps [µs] (a) Forme de r´ef´erence 0 0.5 1 1.5 2 2.5 3 3.5 4 −1 −0.5 0 0.5 1 temps [µs] (b) Une r´ealisation des donn´ees et vraie position 1.995 2 2.005 2.01 2.015 2.02 2.025 0 20 40 60 80 % temps [µs] (c) Histogramme des temps de retard pour K = 1 1.995 2 2.005 2.01 2.015 2.02 2.025 0 10 20 30 40 50 60 70 % temps [µs] (d) Histogramme des temps de retard pour K = 4 1.995 2 2.005 2.01 2.015 2.02 2.025 0 10 20 30 40 % temps [µs] (e) Histogramme des temps de retard pour K = 10 1.995 2 2.005 2.01 2.015 2.02 2.025 0 5 10 15 20 % temps [µs] (f) Histogramme des temps de retard pour K = 20 FIGURE 4.4 – Estimation du temps de retard d’un écho (RSB ✏ 0 dB). (a) : Forme d’onde, (b) : vrai temps () et données (–). Distribution des temps de retard estimés par filtre adapté pour (c) K ✏ 1, (d) K ✏ 4, (e) K ✏ 10 et (f) K ✏ 20. Les traits rouges représentent le vrai temps de retard et les barres d’erreur ✟σ où l’écart est donné par l’équation (4.9). Pour cet exemple, il serait raisonnable de régler K ✏ 10, afin que la dispersion d’écart-type σ couvre quelques éléments de la grille sur-échantillonnée de résolution TS④K. 4.3 Algorithmes de déconvolution parcimonieuse pour les systèmes MISO Pour identifier les entrées du système MISO de l’équation (4.8), nous proposons d’utiliser des algorithmes reconnus d’approximation parcimonieuse des signaux, et qui ont montré de bons résultats dans le cas d’un problème de déconvolution classique (K ✏ 1) [Bourguignon et al. 2011, Selesnick et Bayram 2014]. Les algorithmes originaux (i.e. K ✏ 1) sont détaillés dans la partie 3.3.2. Ici, le but est d’approcher le signal y par K vecteurs parcimonieux x k , k ✏ 1 . . . K d’après la connaissance des K filtres à réponse impulsionnelle finie h k . La contribution de ce travail consiste à prendre en compte le caractère générique MISO dans les algorithmes de déconvolution parcimonieuse. Nous proposons ici de revisiter cinq algorithmes : • trois algorithmes gloutons : Matching Pursuit (MP), Orthogonal Matching Pursuit (OMP) et Orthogonal Least Squares (OLS) [Blumensath et Davies 2007], • l’algorithme Single Best Replacement (SBR) [Soussen et al. 2011], qui effectue la 105CHAPITRE 4 : Déconvolution parcimonieuse sur-échantillonnée minimisation locale du critère des moindres carrés pénalisé par une pseudo-norme `0 J♣x, µq ✏ ⑥y ✁ Hx⑥ 2 µ⑥x⑥0 , (4.10) où ⑥x⑥0 est le nombre d’éléments non nuls de x ; chaque itération calcule la valeur minimale du critère pour l’ajout ou la suppression d’une composante, le meilleur mouvement étant alors exécuté, • et un algorithme de déconvolution par pénalisation de norme `1 qui minimise J♣x, λq ✏ ⑥y ✁ Hx⑥ 2 λ⑥x⑥1 , (4.11) l’optimisation étant effectuée par méthode homotopique [Malioutov et al. 2005, Maria et Fuchs 2006], de complexité analogue à celle de OMP, `1-H faisant référence à cet algorithme. La mise en œuvre de chaque algorithme a été accélérée pour les systèmes MISO, notamment grâce aux calculs de convolution effectués par des algorithmes de transformée de Fourier rapides. 4.3.1 Calcul rapide de la convolution discrète L’intérêt du produit de convolution discrète est d’être implémentable de façon rapide dans le domaine de Fourier [Golub et Van Loan 1996, p. 193]. En effet, la convolution circulaire a une équivalence temporelle/fréquentielle y ✏ h ✝ x é y˜ ✏ h˜ ☎ x˜, (4.12) où le symbole˜désigne la transformée de Fourier discrète. Ce calcul peut être implémenté par y ✏ h ✝ x ✏ FFT✁1 ♣FFT♣hq ☎ FFT♣xqq, (4.13) où FFT est un algorithme rapide de transformée de Fourier discrète (Fast Fourier Transform) [Cooley et Tukey 1965]. Le calcul est réalisé sur Nf points fréquentiels et est historiquement adapté pour des puissances entières de deux. Le nombre de points doit respecter Nf → Nx Nh ✁ 1 pour éviter de tronquer h et x. La complexité de cet algorithme est en O♣Nf ln Nf q alors que la complexité du calcul de base de la transformée de Fourier discrète s’exprime en O♣N2 f q. Un calcul de convolution est par conséquent équivalent à trois algorithmes de type FFT. Nous définissons également le calcul d’inter-corrélation R♣x, yq, qui peut également être effectué par ce type de calcul, défini par R♣x, yq ✏ x ✝ y ✝ ✁, (4.14) où y ✝ ✁ est le conjugué retourné temporellement de y. 1064.3 Algorithmes de déconvolution 4.3.2 Détails de mise en œuvre des algorithmes Algorithmes MP et OMP A chaque itération, l’étape de sélection des algorithmes MP et OMP fait appel au produit HT r, où r est le résidu entre les données y et l’approximation Hx♣i [Blumensath et Davies 2007]. Pour un système MISO, ce calcul revient à effectuer K produits ♣ ✍H k q T r où les matrices ✍H k sont de Toeplitz. Chaque produit correspond à un calcul d’intercorrélation entre h k et r, équivalent à trois calculs de type FFT. En pratique, nous calculons les K FFT des h k à l’avance. Ensuite, à chaque itération, la FFT de r et les K IFFT de ♣ ✍H k q T r sont calculées pour l’étape de sélection. En termes de coût de calcul, l’accroissement est proportionnel à K. Pour MP, l’étape de mise à jour du résidu est identique à un algorithme standard (i.e. K ✏ 1). Pour OMP, le calcul de chaque solution est défini par x♣i ✏ ♣HT QHQq ✁1HT Qy, où HQ représente les colonnes de H sélectionnées à une itération donnée. Dans notre mise en œuvre, nous utilisons une factorisation de Cholesky de HT QHQ pour effectuer l’inversion à moindre coût [Golub et Van Loan 1996]. L’inversion du système revient ici à l’inversion de deux systèmes triangulaires de complexité O♣n 2 q, où n est le nombre d’indices actifs. Algorithmes OLS et SBR Pour sélectionner l’élément à rajouter, les algorithmes OLS et SBR utilisent de façon intensive les éléments de la matrice de Gram HTH (cf. partie 3.3.2). Ce sont en fait les éléments des matrices ♣ ✍H k q T ✍H ` qui peuvent être calculés préalablement à partir des séquences d’intercorrélation entre h k et h ` . Nous avons donc besoin des K♣K 1q④2 intercorrélations entre les K filtres h k et h ` , dans le domaine de Fourier. Pour OLS et SBR, le coût de calcul dans l’algorithme lui-même reste approximativement constant en fonction de K, l’accroissement du coût étant très majoritairement associé aux pré-calculs d’intercorrélation. Le test des retraits de SBR est effectué sur le support actif et n’est donc pas concerné par l’aspect multi-voies. Algorithme de déconvolution par pénalisation `1 L’algorithme `1-H minimise le critère (4.11) en faisant progressivement décroître les valeurs du paramètre λ [Malioutov et al. 2005]. La solution optimale est alors calculée pour chaque saut de λ, signifiant un changement de support de la solution d’un élément. On a donc un comportement similaire aux stratégies gloutonnes. A chaque itération, l’ajout d’un élément nécessite deux produits HT r, ce qui correspond à 2♣K 1q FFT. Le test des retraits requiert lui l’inversion de deux systèmes HT QHQ, effectuée également par une factorisation de Cholesky. En termes de complexité, `1-H est donc à peu près équivalent au double de l’algorithme OMP. Résumé de mise en œuvre des algorithmes Tous les algorithmes exigent les K pré-calculs des h˜ k . Pour résumer, les algorithmes MP, OMP et `1-H ont une complexité proportionnelle à K pour les pré-calculs et pour chaque itération de l’algorithme. D’un autre côté, OLS et SBR nécessitent seulement les pré-calculs 107CHAPITRE 4 : Déconvolution parcimonieuse sur-échantillonnée de FFT, et le cœur de l’algorithme reste à peu près le même quand K augmente. Le détail des coûts de calcul en termes de FFT est récapitulé dans le tableau 4.1. Algorithmes MP OMP `1-H OLS SBR Pré-calculs h˜ k h˜ k h˜ k h˜ k h˜ k y˜ y˜ y˜ ♣ ✍H k q T y ♣ ✍H k q T y ♣ ✍H k q T y ♣ ✍H k q T ✍H ` ♣ ✍H k q T ✍H ` Nb. total de FFT K K 12K 12K♣K2Kq④2 12K♣K2Kq④2 cœur r˜ r˜ 2 ✂ r˜ ♣ ✍H k q T r ♣ ✍H k q T r 2 ✂ ♣ ✍H k q T r ✒idem ✒idem Nb. total de FFT K1 K1 2♣K1q 0 0 TABLE 4.1 – Pré-calculs et calculs dans le cœur des algorithmes de déconvolution pour les systèmes MISO. 4.4 Résultats 4.4.1 Outils de mesure de l’erreur d’estimation Les trains d’impulsions ont dans la réalité des positions temporelles continues. En revanche, l’estimation place les pics sur une grille discrète. Si nous considérons respectivement xq♣tq et x♣♣tq comme la vérité et l’estimation, le calcul de l’erreur basé sur une différence entre ces deux signaux mène irrémédiablement à une mauvaise approche, xq♣tq et x♣♣tq ne coïncidant jamais. Il est de ce fait nécessaire d’utiliser des outils de mesure de la différence entre deux trains d’impulsions. Les références sont relativement nombreuses dans le domaine des neurosciences où l’on parle de distance entre des trains d’impulsions binaires. Dans ce domaine, les trains sont des stimuli électriques du système nerveux, dont les valeurs varient continûment. Victor et Purpura [1996; 1997] proposent des distances métriques au sens d’une approximation discrète par intervalle. Van Rossum [2001] utilise plutôt la distance euclidienne entre les deux trains convolués par une exponentielle décroissante causale. On a dans ce cas un paramètre de décroissance τ qui joue le rôle de tolérance temporelle pour la comparaison des trains. Il est également possible d’utiliser une gaussienne dans laquelle l’écart-type σ est équivalent à τ [Schreiber et al. 2003]. Dans [Paiva et al. 2010], les auteurs établissent une revue des distances fréquemment utilisées et proposent d’autres noyaux : triangle, rectangle et laplacien. Le noyau laplacien est une exponentielle décroissante symétrique. Nous trouvons ces mesures de distance intéressantes et adaptées à nos travaux. Afin de disposer de noyaux symétriques, nous choisissons l’utilisation des noyaux laplacien et gaussien. Nous les définissons respectivement par κ♣tq ✏ e ✁ ⑤t⑤ τ et κ♣tq ✏ e ✁ t 2 2σ2 (4.15) 1084.4 Résultats −1 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 1 0 0.2 0.4 0.6 0.8 1 Exemple de noyau pour le calcul de distance temps [µs] gaussien laplacien FIGURE 4.5 – Exemple de noyaux gaussien et laplacien pour le calcul de distance (τ ✏ σ ✏ 0.1 µs). Sur la figure 4.5, un exemple de ces deux noyaux est donné. Les paramètres τ et σ définissent la précision temporelle de comparaison et nous choisissons de les fixer à τ ✏ σ ✏ TS, de sorte que la précision de reconstruction soit de l’ordre de la période d’échantillonnage des données. Le signal filtré correspondant à un train d’impulsions x♣tq de N pics est calculé par f♣tq ✏ x♣tq ✝ κ♣tq ✏ ➳ N i✏1 aiκ♣t ✁ tiq, (4.16) où les ai et les ti sont respectivement les amplitudes et les temps d’arrivée des pics. La distance entre les trains x1♣tq et x2♣tq est ensuite définie par la distance euclidienne dx1,x2 ✏ ➺ ✽ 0 ♣f1♣tq ✁ f2♣tqq2 dt. (4.17) Cette distance peut se calculer analytiquement ou numériquement en discrétisant l’intégrale par la méthode des rectangles avec un pas très petit par rapport à TS. Dans la figure 4.6, nous montrons un exemple de calcul de distance pour deux trains d’impulsions x1♣tq et x2♣tq. Trois différences sont apparentes : une erreur d’amplitude pour le premier pic, une erreur de position pour le deuxième et une erreur d’amplitude et de position pour le troisième. Quatre paramétrages sont étudiés : 1. amplitudes inchangées et noyau laplacien, 2. amplitudes binarisées et noyau laplacien, 3. amplitudes inchangées et noyau gaussien, 4. amplitudes binarisées et noyau gaussien. Nous utilisons l’aspect binaire car c’est la formulation notamment utilisée en neurosciences. Comme attendu, on remarque que l’erreur d’amplitude sur le premier pic n’est pas prise en compte lorsqu’on binarise. Elle crée une seule forme à l’emplacement du pic. Les erreurs de position du deuxième pic crée deux formes symétriques et sont plus marquées avec le noyau gaussien car sa forme est moins resserrée que le noyau laplacien. Les erreurs d’amplitude et de position sur le troisième pic créent deux formes non symétriques. 109CHAPITRE 4 : Déconvolution parcimonieuse sur-échantillonnée 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (a1) x1(t) f1(t) 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (b1) x2(t) f2(t) 0 1 2 3 4 −0.5 0 0.5 1 1.5 2 2.5 (c1) d = 0.347 (f1(t) − f2(t))2 d= aire 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (a2) 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (b2) 0 1 2 3 4 −0.5 0 0.5 1 1.5 2 2.5 (c2) d = 0.214 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (a3) 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (b3) 0 1 2 3 4 −0.5 0 0.5 1 1.5 2 2.5 (c3) d = 0.652 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (a4) 0 1 2 3 4 −1.5 −1 −0.5 0 0.5 1 1.5 (b4) 0 1 2 3 4 −0.5 0 0.5 1 1.5 2 2.5 (c4) d = 0.394 FIGURE 4.6 – Exemple de calcul de distance entre trains d’impulsions. Les lettres indiquent (a) le train x1♣tq et la fonction f1♣tq associée, (b) le train x2♣tq et la fonction f2♣tq associée et (c) la distance euclidienne. Les indices correspondent à (1) amplitudes inchangées et noyau laplacien, (2) amplitudes binarisées et noyau laplacien, (3) amplitudes inchangées et noyau gaussien et (4) amplitudes binarisées et noyau gaussien. 4.4.2 Résultats issus de données simulées On considère les données présentées sur la figure 4.7c. Elles sont composées de six échos dont les temps d’arrivée sont choisis de façon continue sur toute la durée du signal : r0, 8s µs. On ne peut donc jamais retrouver les vraies positions, mais on peut s’en approcher du mieux possible. La forme d’onde de convolution est une gaussienne modulée par une sinusoïde de 5 MHz et de 40 % de facteur de bande passante (voir figure 4.7a). Les données sont échantillonnées à 25 MHz et le rapport signal à bruit est de 12 dB. Il y a dans ces données trois problèmes de superposition d’échos difficiles. La déconvolution est effectuée de façon classique (K ✏ 1) et avec sur-échantillonnage (K ✏ 6). Les algorithmes sont arrêtés lorsque la cardinalité est de l’ordre de celle de la vérité. Les résultats sont présentés respectivement sur les figures 4.7-d et 4.7-e. Nous voyons que, pour tous les algorithmes, le sur-échantillonnage permet de mieux résoudre un certain nombre de problèmes de pics proches par rapport à l’approche classique. OLS et SBR aboutissent à de bons résultats mais ne parviennent pas à détecter les deux pics centraux qui 1104.4 Résultats 0.25 0.5 0.75 1 1.25 1.5 −1 0 1 (a) Forme mesur´ee 0.25 0.5 0.75 1 1.25 1.5 −1 0 1 (b) Sur-´echantillonnage 0 2 4 6 8 −2 0 2 (c) Donn´ees et v´erit´e 0 2 4 6 8 −2 0 2 MP (d) 0 2 4 6 8 OMP 0 2 4 6 8 OLS 0 2 4 6 8 SBR 0 2 4 6 8 ℓ1 0 2 4 6 8 −2 0 2 temps [µs] (e) 0 2 4 6 8 temps [µs] 0 2 4 6 8 temps [µs] 0 2 4 6 8 temps [µs] 0 2 4 6 8 temps [µs] FIGURE 4.7 – Exemple de déconvolution de données synthétiques. (a) : Forme d’onde initiale, (b) : formes d’onde utilisées pour la déconvolution K ✏ 6, (c) : données (–) et vrais pics (✆), ligne (d) : résultats avec K ✏ 1, ligne (e) : résultats avec K ✏ 6. Vrais pics (✆) et pics estimés (). interfèrent de manière très critique. SBR réussit néanmoins à détecter un des deux pics. D’un autre côté, la déconvolution sur-échantillonnée par `1-H permet de retrouver ces deux pics, mais au prix de quelques fausses détections de faibles amplitudes, comportement typique de la pénalisation `1. Nous nous intéressons également aux calculs de distance développés dans la partie pré- cédente. Les résultats de ces calculs sont présentés dans les tableaux 4.2 et 4.3, pour respectivement K ✏ 1 et K ✏ 6. D’une manière générale, le fait de binariser est défavorable aux Algorithmes MP OMP OLS SBR `1-H d (laplacien) 0.9166 0.8889 0.8889 0.8889 0.7638 d (laplacien/bin) 0.3015 0.3015 0.3015 0.3015 0.4129 d (gaussien) 1.5799 1.5245 1.5245 1.5245 1.2723 d (gaussien/bin) 0.5144 0.5144 0.5144 0.5144 0.6776 TABLE 4.2 – Résultats des calculs de distance pour l’exemple de la figure 4.7 avec K ✏ 1. Algorithmes MP OMP OLS SBR `1-H d (laplacien) 0.7545 0.7117 0.4322 0.2665 0.3302 d (laplacien/bin) 0.2788 0.2788 0.1753 0.1005 0.1815 d (gaussien) 1.3226 1.2373 0.7703 0.4356 0.5498 d (gaussien/bin) 0.4793 0.4793 0.3065 0.1650 0.3140 TABLE 4.3 – Résultats des calculs de distance pour l’exemple de la figure 4.7 avec K ✏ 6. résultats issus de la pénalisation `1. En effet, cette pénalisation favorise les pics de faibles 111CHAPITRE 4 : Déconvolution parcimonieuse sur-échantillonnée amplitudes et crée donc des solutions avec une cardinalité plus élevée par rapport aux approches gloutonnes et à SBR. Pour K ✏ 1, dans le cas binaire, les distances les plus faibles correspondent de ce fait aux méthodes gloutonnes et à SBR. Dans le cas non binaire, c’est la pénalisation `1 qui donne les meilleurs résultats. Le sur-échantillonnage fait baisser les distances pour toutes les méthodes et pour toutes les métriques. Les diminutions sont plus significatives pour les méthodes OLS, SBR et `1-H, avec notamment une baisse d’un facteur deux pour OLS et `1-H, et d’un facteur trois pour SBR. La méthode SBR donne les distances les plus faibles en super-résolution. Cet exemple montre qu’un modèle plus précis ne permet pas seulement d’affiner la position des pics, mais permet également d’éviter des erreurs importantes. Les algorithmes l’utilisant aboutissent à des solutions plus précises en limitant les erreurs dues aux modes locaux. 4.4.3 Simulations de Monte-Carlo Nous présentons maintenant des simulations de Monte-Carlo. Les paramètres de l’exemple précédent sont repris : FS ✏ 25 MHz, f0 ✏ 5 MHz, BWR✁3 ✏ 0.3, RSB ✏ 12 dB, durée 8 µs, 6 pics aléatoirement placés et d’amplitudes uniformes. Nous appliquons les cinq algorithmes sur 1000 réalisations aléatoires en faisant varier K de 1 à 8 pour chaque réalisation. Les algorithmes sont arrêtés quand la norme du résidu ⑥y ✁ Hx♣⑥ 2 est au niveau de la norme du bruit ⑥b⑥ 2 ✓ Nyσ 2 b (cf. partie 3.2.4). Les calculs de distances sont présentés sur les figures 4.8a et 4.8b. Le noyau laplacien est utilisé avec et sans binarisation des pics. D’une manière générale, les distances baissent quand K augmente. La plus faible distance avec amplitudes inchangées est clairement celle calculée à partir de la pénalisation `1. Pour cette distance, les approches gloutonnes et SBR donnent à peu près les mêmes résultats, avec un léger avantage pour OLS et SBR. En ce qui concerne la distance calculée avec les amplitudes binaires, l’ordre de performance croissante des méthodes est nettement : MP, OMP, `1-H, OLS et SBR. Ces résultats confirment les conclusions partielles tirées de l’exemple de la partie 4.4.2. En ce qui concerne les temps de calcul exposés en figure 4.8c, ceux-ci augmentent avec K, mais de façon maîtrisée. Ces résultats sont à mettre en relation avec le nombre de pics estimés par chaque méthode (figure 4.8d). En effet, pour une méthode donnée, un plus grand nombre de pics estimés, faisant écho à un nombre d’itérations plus important, impose un temps de calcul plus élevé. Le nombre de pics obtenus baisse avec K, prouvant la meilleure performance du modèle quand K augmente. Les algorithmes les plus rapides sont MP et OMP malgré des solutions ayant une cardinalité élevée, mais avec un effet moins important pour OMP. Les méthodes ayant le plus grand temps de calcul sont SBR et `1-H. Ce dernier est censé être plus rapide que SBR, mais produit des solutions avec un plus grand nombre de pics. Les méthodes qui présentent les solutions ayant les plus faibles nombres de pics sont SBR et OLS, ce qui fait apparaître une meilleure représentation du signal avec moins de pics. La méthode OLS semble être un bon compromis entre temps de calcul et nombre de pics produits. Cette étude montre que la déconvolution sur-échantillonnée permet de réduire les distances entre la vraie séquence et la séquence estimée. Ceci est dû à un modèle plus précis grâce à une discrétisation plus fine. Cette approche provoque un surcoût de calcul limité par rapport à la déconvolution classique grâce à une implémentation efficace. 1124.4 Résultats 0 2 4 6 8 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 K (a) Distance (non binaris´e) MP OMP OLS SBR ℓ1-H 0 2 4 6 8 0.1 0.2 0.3 0.4 0.5 0.6 K (b) Distance (binaris´e) 0 2 4 6 8 2 4 6 8 10 12 14 K (c) Temps calcul (ms) 0 2 4 6 8 5 10 15 20 K (d) Cardinalit´e MP OMP OLS SBR ℓ1-H v´erit´e FIGURE 4.8 – Résultats de simulations de Monte-Carlo pour cinq méthodes de déconvolution en fonction du facteur de sur-échantillonnage K. (a) distance basée sur un noyau laplacien, (b) distance basée sur un noyau laplacien avec amplitudes binaires, (c) temps de calcul, (d) cardinalité. 4.4.4 Résultats expérimentaux Pour illustrer l’approche de déconvolution sur-échantillonnée, nous appliquons les algorithmes développés aux données acquises à partir de plaques d’aluminium. Le transducteur utilisé est à surface plane circulaire de diamètre 12.7 mm et de fréquence centrale 2.25 MHz. Les plaques sont insonifiées en incidence normale et dans le champ lointain du transducteur. Deux épaisseurs qui créent le chevauchement des échos sont utilisées : 4 et 2 mm. La section 5.2 explique plus en détail la procédure expérimentale utilisée pour acquérir ce type de données. Les données sont échantillonnées à 25 MHz, valeur qui est choisie volontairement faible pour montrer la capacité du modèle à résoudre des problèmes de chevauchement pour des fréquences d’échantillonnage basses. Dans la réalité, la fréquence d’échantillonnage pour cette fréquence de transducteur est plutôt de l’ordre de 50 ou 100 MHz. Nous choisissons un facteur de sur-échantillonnage K ✏ 4 de manière à reconstruire des signaux à 100 MHz. La réponse instrumentale est mesurée à partir d’une plaque épaisse (20 mm) dans les mêmes conditions (voir figure 4.9a). Les filtres de déconvolution, représentés sur la figure 4.9b, sont obtenus en sur-échantillonnant la réponse instrumentale par un facteur quatre. Les données et la séquence de réflectivité théorique pour la plaque de 4 mm sont représentées sur la figure 4.10a. Cette séquence est obtenue par le calcul des coefficients de réflexion et de transmission avec la connaissance de l’épaisseur, de la vitesse des ondes et de la masse 113CHAPITRE 4 : Déconvolution parcimonieuse sur-échantillonnée 0 0.5 1 1.5 −1 −0.5 0 0.5 1 (a) R´eponse instrumentale mesur´ee temps [µs] 0 0.5 1 1.5 −1 −0.5 0 0.5 1 (b) Filtres de d´econvolution temps [µs] h1 h2 h3 h4 FIGURE 4.9 – Réponse instrumentale mesurée et filtres de déconvolution obtenus par sur- échantillonnage. 0 1 2 3 4 5 6 7 8 9 10 −1 −0.5 0 0.5 1 (a) Donn´ees et vraie s´equence Donn´ees R´ef´erence 0 1 2 3 4 5 6 7 8 9 10 −0.5 0 0.5 1 (b) D´econvolution classique (K = 1) avec SBR v´erit´e d´econvolution 0 1 2 3 4 5 6 7 8 9 10 −0.5 0 0.5 1 temps [µs] (c) D´econvolution sur-´echantillonn´ee (K = 4) avec SBR v´erit´e d´econvolution FIGURE 4.10 – Déconvolution classique (K ✏ 1) et sur-échantillonnée (K ✏ 4) pour des données acquises à partir d’une plaque d’aluminium de 4 mm d’épaisseur. (a) données et vraie séquence, (b) vraie séquence et déconvolution classique, (c) vraie séquence et déconvolution sur-échantillonnée. volumique (pour plus de détails, se rapporter à la section 5.2). Le premier pic est négatif et correspond à la réflexion à la surface de la plaque. Les pics suivants correspondent aux allers-retours dans la plaque. Le but est donc d’obtenir un train d’impulsions le plus proche possible de cette séquence. Les résultats de déconvolution classique (K ✏ 1) et sur- échantillonnée (K ✏ 4), obtenus avec l’algorithme SBR, sont respectivement représentés sur les figures 4.10b et 4.10c. On remarque que la solution de la déconvolution classique aboutit 1144.4 Résultats à une solution proche de la vérité mais avec des pics doubles, dus à l’imprécision temporelle du modèle. Ces fausses détections produisent également des erreurs d’amplitude. D’un autre côté, la déconvolution sur-échantillonnée produit une solution sans pics doubles, avec des positions et des amplitudes proches de la séquence réelle. On peut expliquer ce résultat par une plus grande résolution temporelle du modèle. La sélection des formes d’onde est plus proche de la réalité grâce au choix plus large défini par les filtres du système MISO. Les données et les résultats pour la plaque de 2 mm d’épaisseur sont représentés sur la figure 4.11. Les conclusions sont à peu près les mêmes que précédemment. La différence 2 2.5 3 3.5 4 4.5 5 5.5 6 −1 −0.5 0 0.5 1 (a) Donn´ees et vraie s´equence Donn´ees R´ef´erence 2 2.5 3 3.5 4 4.5 5 5.5 6 −0.5 0 0.5 1 (b) D´econvolution classique (K = 1) avec SBR v´erit´e d´econvolution 2 2.5 3 3.5 4 4.5 5 5.5 6 −0.5 0 0.5 1 temps [µs] (c) D´econvolution sur-´echantillonn´ee (K = 4) avec SBR v´erit´e d´econvolution FIGURE 4.11 – Déconvolution classique (K ✏ 1) et sur-échantillonnée (K ✏ 4) pour des données acquises à partir d’une plaque d’aluminium de 2 mm d’épaisseur. (a) données et vraie séquence, (b) vraie séquence et déconvolution classique, (c) vraie séquence et déconvolution sur-échantillonnée. du positionnement temporel est encore plus flagrante dans ce cas. On voit que dans le cas classique, les erreurs de détection sont importantes, dès le troisième pic, et ne permettent pas de retrouver la séquence théorique. La déconvolution sur-échantillonnée parvient à détecter quatre pics en accord avec la vérité et ce aussi bien en amplitude que temporellement. Les résultats de déconvolution sur-échantillonnée nous montrent ainsi qu’il est possible de réaliser le contrôle non destructif de matériaux – en l’occurrence le calcul d’épaisseur de plaques – à partir de signaux échantillonnés à des fréquences plutôt basses. Cette modalité peut répondre à des problématiques de vitesse d’exécution, de codage et de stockage des données. 115Chapitre 5 Application au contrôle non destructif par ultrasons Sommaire Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.1 Estimation de la forme d’onde . . . . . . . . . . . . . . . . . . . . . . 118 5.1.1 Mesure d’un écho isolé . . . . . . . . . . . . . . . . . . . . . . . 118 5.1.2 Estimation par connaissance de la séquence de réflectivité . . . . 118 5.1.3 Moyennage dans le domaine homomorphique . . . . . . . . . . . 119 5.1.4 Construction d’un dictionnaire ou apprentissage . . . . . . . . . . 120 5.2 Plaque de matériau homogène . . . . . . . . . . . . . . . . . . . . . . 120 5.2.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2.2 Calcul d’incertitude . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.2.3 Estimation du temps de vol moyen par moindres carrés . . . . . . 123 5.2.4 END d’une plaque épaisse . . . . . . . . . . . . . . . . . . . . . 123 5.2.5 CND d’une plaque fine . . . . . . . . . . . . . . . . . . . . . . . 126 5.3 Matériaux atténuants . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.4 Plaques avec trous à fond plat . . . . . . . . . . . . . . . . . . . . . . 129 5.4.1 Cas d’un Ascan . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.4.2 Cas d’un Bscan . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Introduction Ce chapitre présente des résultats expérimentaux de déconvolution parcimonieuse. Les acquisitions ont été réalisées pour la majeure partie au Laboratoire d’Acoustique de l’Université du Maine. Nous abordons en préambule, dans la section 5.1, l’estimation de la forme d’onde de référence. Même si les techniques présentées ici n’ont pas toutes été utilisées en situation réelle, l’état de l’art sur celles-ci demeure intéressant pour l’utilisateur. Dans la section 5.2, nous traitons le cas de plaques homogènes. Une méthode de calcul de temps de vol 117CHAPITRE 5 : Application au CND pour les plaques par minimisation d’un critère des moindres carrés est proposée. Plusieurs méthodes de déconvolution sont comparées pour réaliser, dans un premier temps, le calcul de la vitesse des ondes, et dans un second temps, le calcul d’épaisseur de plaques fines. La déconvolution de matériaux atténuants est ensuite abordée dans la section 5.3. Le but ici est de détecter l’écho de fond d’un matériau très atténuant menant à un rapport signal à bruit très faible et à une distorsion importante liée à l’atténuation dispersive. Nous montrons dans cet exemple l’importance d’utiliser un modèle qui prend en compte l’atténuation dispersive. Pour finir, nous nous intéressons à la détection de trous à fond plat dans la section 5.4. La difficulté provient du mélange entre les échos du trou et du fond. Un cas de matériau atté- nuant contenant un trou est traité. Nous montrons également le résultat d’une image obtenue par déconvolutions successives des A-scans pour une plaque d’aluminium percée par quatre trous. Ce chapitre répond de façon pragmatique à des problèmes réels de contrôle non destructif. 5.1 Estimation de la forme d’onde de référence ou construction du dictionnaire 5.1.1 Mesure d’un écho isolé La méthode la plus simple pour obtenir la forme de référence est de réaliser une mesure en incidence normale avec une plaque de grande épaisseur placée en champ lointain [Krautkramer et Krautkramer 1990]. On obtient dans ce cas un écho de surface isolé. Lorsque le milieu de transmission entre le transducteur et la plaque est faiblement atténuant (de l’eau par exemple), on obtient la réponse instrumentale du système [Olofsson et Stepinski 2000]. Pour corriger les effets de diffraction, il est possible de modéliser la propagation entre le transducteur et la plaque grâce à une fonction de diffraction [Stephanishen 1971, Lingvall et al. 2003]. On peut ensuite retrouver la réponse instrumentale par déconvolution ou filtrage inverse [Cassereau et al. 1988]. En champ lointain, on peut montrer que la fonction de diffraction est proche d’une impulsion de Dirac. Par conséquent, l’écho de surface est équivalent à la réponse impulsionnelle instrumentale retardée du temps de propagation dans l’eau. Lorsque la mesure d’un écho isolé est impossible et qu’on dispose de signaux contenant des échos mélangés, il est nécessaire d’estimer la forme d’onde. Nous exposons quelques approches possibles comme l’estimation par connaissance de la séquence de réflectivité ou par moyennage dans le domaine homomorphique. Il est également possible de proposer un plus grand nombre de formes d’onde dans un dictionnaire. Dans ce cas, il est nécessaire de construire le dictionnaire suivant un modèle ou d’apprendre un jeu de représentations. 5.1.2 Estimation par connaissance de la séquence de réflectivité Sous un modèle de convolution, les données sont y♣tq ✏ hi♣tq ✝ x♣tq, où x♣tq représente la séquence de réflectivité ou de transmittivité. Dans le domaine fréquentiel, on a donc Y ♣fq ✏ Hi♣fqX♣fq. Si on suppose x♣tq connue, pour une pièce étalon par exemple, il est possible d’estimer la réponse instrumentale ♣hi♣tq par transformée de Fourier inverse de Y ♣fq④X♣fq. Cette inversion est bien conditionnée grâce au caractère très large bande de 1185.1 Estimation de la forme d’onde X♣fq, qui est la transformée de Fourier d’une somme d’impulsions de Dirac. Nous montrons sur la figure 5.1 un exemple simulé d’estimation de la réponse instrumentale pour trois RSB : 30 dB, 20,dB et 10 dB. Comme attendu, l’estimation de la réponse instrumentale est plutôt 0 50 100 150 200 250 −2 −1 0 1 2 (a) Donn´ees RSB = 30 dB y(t) x(t) 0 50 100 150 200 250 −2 −1 0 1 2 (c) Donn´ees RSB = 20 dB 0 50 100 150 200 250 −2 −1 0 1 2 (e) Donn´ees RSB = 10 dB 0 10 20 30 40 50 −1 0 1 (b) Estimation hi(t) hi(t) bhi (t) 0 10 20 30 40 50 −1 0 1 (d) Estimation hi(t) 0 10 20 30 40 50 −1 0 1 (f) Estimation hi(t) FIGURE 5.1 – Exemple d’estimation de la réponse instrumentale par connaissance de x♣tq pour trois niveaux de bruit. Colonne de gauche : Données y♣tq (–) et séquence x♣tq (+), colonne de droite : vérité hi♣tq et estimation ♣hi♣tq. Haut : RSB ✏ 30 dB, milieu : RSB ✏ 20 dB, bas : RSB ✏ 10 dB. bonne, même pour le cas le plus défavorable. Cette estimation peut être appliquée concrètement au cas des plaques par exemple. Nous verrons dans la section 5.2 que la séquence x♣tq a un modèle relativement simple et prédictif pour les plaques. 5.1.3 Moyennage dans le domaine homomorphique Le moyennage dans le domaine homomorphique est basé sur le cepstre d’un signal s♣tq qui correspond au logarithme naturel de sa transformée de Fourier [Oppenheim et al. 1968] ln S♣fq ✏ ln ⑤S♣fq⑤e jarg♣S♣fqq✟ ✏ ln ⑤S♣fq⑤ jarg♣S♣fqq. (5.1) Pour un modèle convolutif, les données sont modélisées par y♣tq ✏ hi♣tq ✝ x♣tq. En prenant le logarithme naturel dans le domaine fréquentiel, on obtient ln Y ♣fq ✏ ln Hi♣fq ln X♣fq. (5.2) Le principe consiste à utiliser une certaine quantité de signaux yn♣tq, n ✏ 1 . . . N pour lesquelles on considère hi♣tq invariant et x♣tq comme une réalisation aléatoire. C’est le cas 119CHAPITRE 5 : Application au CND lorsqu’on utilise un unique transducteur pour effectuer un grand nombre de mesures. La moyenne des cepstres réceptionnés est alors 1 N ➳ N n✏1 ln Yn♣fq ✏ ln Hi♣fq 1 N ➳ N n✏1 ln Xn♣fq. (5.3) Tria et al. [2007] suppose que, pour n ✏ 1 . . . N et pour chaque fréquence, ln ⑤Xn♣fq⑤ suit une même loi de probabilité de moyenne M et de variance σ, et que arg♣Xn♣fqq suit une loi uniforme sur r✁π, πs de moyenne nulle. La loi des grands nombres indique que, pour un grand nombre de réalisations, les paramètres moyennés tendent vers les paramètres de la loi de probabilité. On a par conséquent 1 N ➳ N n✏1 ln Xn♣fq ÝÑNÑ✽ ★ 1 N ➦N n✏1 ln ⑤Xn♣fq⑤ ÝÑNÑ✽ M 1 N ➦N n✏1 arg♣Xn♣fqq ÝÑNÑ✽ 0. (5.4) L’estimation de la réponse instrumentale est par conséquent ♣hi♣tq ✏ F ✁1 ★ exp ✄ 1 N ➳ N n✏1 ln Yn♣fq ☛✰ , (5.5) où F ✁1 est l’opérateur de transformée de Fourier inverse. Un exemple synthétique d’estimation est présenté sur la figure 5.2 pour plusieurs nombres de réalisations. Chaque séquence x♣tq est générée aléatoirement avec un nombre de pics allant de un à vingt, une loi uniforme pour les positions des pics et des amplitudes de loi gaussienne centrée. Le rapport signal à bruit de chaque jeu de données est fixé à 40 dB. Comme attendu, plus le nombre de réalisations augmente, plus l’estimation de la réponse instrumentale est bonne. 5.1.4 Construction d’un dictionnaire ou apprentissage L’approche par dictionnaire consiste à considérer le modèle linéaire y ✏ Dx où D P R Ny✂Nx est un dictionnaire avec beaucoup plus de colonnes que de lignes (Nx ✧ Ny). Il est possible d’utiliser un modèle d’écho particulier (voir partie 3.1.1 du chapitre 3) et de discrétiser les paramètres pour construire le dictionnaire [Lu et Michaels 2008]. Ce principe est inspiré de la construction des dictionnaires d’ondelettes utilisés en représentation parcimonieuse [Mallat et Zhang 1993, Mallat 1999]. Une autre technique pour construire le dictionnaire D et limiter sa taille consiste à réaliser un apprentissage à partir de plusieurs jeux de données [Lewicki et Sejnowski 2000, KreutzDelgado et al. 2003, Aharon et al. 2006, Zhang et al. 2008; 2012]. 5.2 Plaque de matériau homogène 5.2.1 Généralités Les matériaux considérés homogènes ne présentent ni atténuation ni dispersion. La vitesse des ondes est de ce fait indépendante de la fréquence et donc constante. Elle est notée c0. Nous considérons ici des mesures en pulse-echo en incidence normale par rapport à une 1205.2 Plaque de matériau homogène 0 20 40 60 80 100 −1 −0.5 0 0.5 1 (a) Estimation avec 10 r´ealisations hi(t) bhi (t) 0 20 40 60 80 100 −1 −0.5 0 0.5 1 (b) Estimation avec 100 r´ealisations 0 20 40 60 80 100 −1 −0.5 0 0.5 1 (c) Estimation avec 1000 r´ealisations FIGURE 5.2 – Exemple d’estimation de la réponse instrumentale par moyennage dans le domaine homomorphique. (a) : vérité hi♣tq et estimation ♣hi♣tq pour 10 réalisations, (b) : vérité hi♣tq et estimation ♣hi♣tq pour 100 réalisations, (c) : vérité hi♣tq et estimation ♣hi♣tq pour 1000 réalisations. (a) (b) d transducteur D 1 2 1 plaque FIGURE 5.3 – (a) Schéma et (b) photo d’une mesure en pulse-echo réalisée en incidence normale avec une plaque homogène immergée. plaque homogène, comme illustré sur la figure 5.3. La photo de la figure 5.3 montre une mesure effectuée avec une plaque d’aluminium. En incidence normale, seules les ondes longitudinales se propagent dans le matériau inspecté. A partir de ce type d’inspection, nous nous intéressons seulement à ce type d’ondes. Le temps de vol est équivalent à un aller- 121CHAPITRE 5 : Application au CND retour dans la plaque T ✏ 2d c0 . (5.6) Le modèle des données est alors défini par une répétition des réponses instrumentales tous les 2T [Saniie et Nagle 1989] y♣tq ✏ α12hi ✂ t ✁ 2D c0 ✡ β12β21 ➳✽ k✏1 ♣α21q 2k✁1 hi ✂ t ✁ 2D c0 ✁ kT✡ , (5.7) avec, respectivement, αij et βij les coefficients de réflexion et de transmission entre un milieu i et un milieu j (voir aussi la partie 1.2.1 du chapitre 1). Le coefficient de réflexion définit le rapport entre les pressions réfléchie et incidente, tandis que le coefficient de transmission traduit le rapport des pressions transmise et incidente [Krautkramer et Krautkramer 1990, chap. 2]. Ceux-ci sont définis par αij ✏ Zj ✁ Zi Zi Zj et βij ✏ 2Zj Zi Zj . (5.8) avec l’impédance acoustique Zi ✏ ρici . On a alors αij ✏ ✁αji et βij ✏ 1 αij [Zala 1992]. Par ailleurs, on trouve dans [Saniie et Nagle 1989] la convention Zi ✏ 1④ρici , qui n’est pas une impédance acoustique mais une admittance acoustique. Dans ce cas, Zi et Zj sont intervertis dans les expressions de αij et βij . Dans un cas de plaque immergée où Z1 ➔ Z2, les coefficients de réflexion respectent α12 → 0 et α21 ➔ 0. En se référant à l’équation (5.7), on remarque que le premier écho - l’écho provenant de la surface – a une amplitude positive α12 et que tous les autres échos, qui sont des allers-retours dans la plaque, ont des amplitudes négatives α 2k✁1 21 . Nous présentons deux exemples avec des plaques d’aluminium de même composition. Le premier est un problème d’évaluation non destructive (END), où il convient d’identifier la vitesse à partir de l’estimation de T et de la connaissance de l’épaisseur. Le deuxième exemple est le contrôle non destructif (CND) de la plaque où le but est d’identifier l’épaisseur de la plaque à partir de l’estimation de T et de la connaissance de la vitesse. Dans un contexte pratique d’inspection, l’étape d’END est généralement réalisée avant tout contrôle. 5.2.2 Calcul d’incertitude La méthode des dérivées partielles indique que l’incertitude absolue ∆f d’une fonction f♣x1, x2, . . .q est ∆f ✏ ✞ ✞ ✞ ✞ ❇f ❇x1 ✞ ✞ ✞ ✞ ∆x1 ✞ ✞ ✞ ✞ ❇f ❇x2 ✞ ✞ ✞ ✞ ∆x2 . . . , (5.9) où ∆x2, ∆x2, . . . sont les incertitudes absolues sur les variables de f. Calcul d’incertitude sur la vitesse Le calcul de la vitesse s’effectuant par c0 ✏ 2d④T, on peut écrire le logarithme ln c0 ✏ ln 2d ✁ ln T. (5.10) En prenant la dérivée de cette fonction, on obtient l’incertitude relative ∆c0 c0 ✏ ∆d d ∆T T . (5.11) 1225.2 Plaque de matériau homogène Calcul d’incertitude sur l’épaisseur D’une façon similaire, l’incertitude relative sur le calcul de l’épaisseur s’écrit ∆d d ✏ ∆c0 c0 ∆T T . (5.12) 5.2.3 Estimation du temps de vol moyen par moindres carrés Pour les matériaux homogènes, on peut considérer un modèle de convolution invariant (se reporter à la section 2.2 du chapitre 2). Le modèle de signal pour une plaque définie par l’équation (5.7) est une répétition de la réponse instrumentale tous les T [Saniie et Nagle 1989]. Pour K échos, on peut écrire un modèle équivalent y♣tq ✏ K ➳✁1 k✏0 akhi♣t ✁ kTq. (5.13) où les ak correspondent aux amplitudes de chaque écho, définies dans la partie 5.2.1. Pour les signaux discrets, il est alors possible d’écrire le modèle y ✏ HTx, (5.14) où la matrice HT est composée des K réponses hi retardées de kT et x est constitué des ak. L’estimation du temps de vol T♣ est réalisée par minimisation des moindres carrés T♣ ✏ arg min T ⑥y ✁ HTx⑥ 2 . (5.15) La solution optimale x♣ est obtenue par inverse généralisée (voir partie 3.2.2 du chapitre 3) et s’écrit x♣ ✏ HT THT ✟✁1 HT T y. (5.16) La résolution de l’équation (5.15) revient donc à T♣ ✏ arg max T y THT HT THT ✟✁1 HT T y. (5.17) Cette optimisation scalaire peut être effectuée en discrétisant T sur une grille. Cette méthode est dédiée au calcul d’un temps de vol moyen pour les plaques. Nous l’utilisons dans la suite pour réaliser l’évaluation et le contrôle d’épaisseur de plaques d’aluminium. A la différence des méthodes de déconvolution classique, elle ne peut être utilisée pour détecter des défauts. 5.2.4 END d’une plaque épaisse Les mesures sont réalisées en incidence normale avec un transducteur plan circulaire de diamètre 12.7 mm et de fréquence centrale 2.25 MHz. Les données reçues sont échantillonnées à 100 MHz. Nous étudions plusieurs plaques d’aluminium de même composition mais d’épaisseurs différentes. Le principe est de calculer la vitesse des ondes c0 à partir de la connaissance de l’épaisseur d c0 ✏ 2d T . (5.18) 123CHAPITRE 5 : Application au CND Habituellement, T est déterminé par seuillage, passage par zéro ou détection de maximum [Krautkramer et Krautkramer 1990, chap. 11]. Ces méthodes se révèlent peu précises et diffi- cilement applicables lorsque les échos se mélangent, même partiellement. La déconvolution peut être une méthode efficace et précise pour estimer T. Nous utilisons pour cela les mé- thodes • par pénalisation `1 : méthode homotopique [Malioutov et al. 2005], • par pénalisation `0 : algorithme bi-directionnel SBR [Soussen et al. 2011], • par minimisation des moindres carrés par rapport au temps de vol. Nous montrons tout d’abord les résultats obtenus à partir de données acquises avec une plaque de 20.5 mm d’épaisseur sur la figure 5.4. La réponse instrumentale est obtenue à 0 0.5 1 1.5 2 −1 −0.5 0 0.5 1 (a) R´eponse instrumentale hi(t) 0 10 20 30 −1 −0.5 0 0.5 1 (b) Donn´ees y(t) 0 10 20 30 −0.5 0 0.5 1 1.5 (c) D´econvolution ℓ1 xb(t) 0 10 20 30 −0.5 0 0.5 1 1.5 (e) D´econvolution SBR 0 10 20 30 −0.5 0 0.5 1 1.5 t [µs] (g) Optimisation T 0 10 20 30 −1 −0.5 0 0.5 1 (d) Mod´elisation r = 0.02880 0 10 20 30 −1 −0.5 0 0.5 1 (f) Mod´elisation r = 0.03768 0 10 20 30 −1 −0.5 0 0.5 1 t [µs] (h) Mod´elisation r = 0.03768 FIGURE 5.4 – Déconvolution pour l’END d’une plaque d’aluminium de 20.5 mm d’épaisseur. (a) réponse instrumentale, (b) données, (c) déconvolution par pénalisation `1 et (d) adéquation aux données, (e) déconvolution par SBR et (f) adéquation aux données, (g) optimisation T et (h) adéquation aux données. partir de l’écho de surface et est tracée sur la figure 5.4a. Sur la figure 5.4b, les échos contenus dans les données sont bien séparés et correspondent aux allers-retours des ultrasons dans la plaque. Les résultats de déconvolution sont représentés sur les figures 5.4c-e-f. Les paramètres de régularisation sont réglés de façon à obtenir un maximum de bonnes détections. La déconvolution par pénalisation `1 parvient à détecter tous les échos mais au prix de pics doubles. La déconvolution par SBR et par optimisation sur le temps de vol aboutissent aux mêmes résultats, sans pics doubles, en accord avec la séquence attendue. Nous traçons également les données modélisées y♣ ✏ Hx♣ par chaque méthode et affichons la norme du 1245.2 Plaque de matériau homogène résidu r ✏ ⑥y ✁ Hx♣⑥ 2 . La pénalisation `1 parvient à une meilleure adéquation aux données grâce à sa cardinalité plus élevée. Dans un contexte d’END, où il s’agit de retrouver des temps de vol, la déconvolution par pénalisation `1 n’est cependant pas adaptée car elle est sujette à produire des doublons ou des pics de faibles amplitudes. Ceci est dû à la pénalisation des amplitudes et non de la cardinalité. Les résultats de l’estimation de la vitesse pour quatre plaques sont affichés dans le tableau 5.1. La méthode utilisée pour la déconvolution est l’optimisation sur le temps de vol. épaisseur d (mm) temps de vol moyen T (µs) vitesse c0 (m.s✁1 ) 60.4 ✟ 0.2 18.98 ✟ 0.04 6370 ✟ 35 39.1 ✟ 0.2 12.20 ✟ 0.04 6410 ✟ 54 20.5 ✟ 0.1 6.43 ✟ 0.04 6380 ✟ 71 4.0 ✟ 0.05 1.24 ✟ 0.04 6370 ✟ 285 moyenne 6383 TABLE 5.1 – Estimation des vitesses des ondes longitudinales dans l’aluminium et calcul d’incertitude pour plusieurs épaisseurs de plaques d’aluminium. Les valeurs obtenues sont du même ordre de grandeur. Nous affichons également l’incertitude due aux imprécisions de la mesure d’épaisseur et au calcul des temps de vol (voir partie 5.2.2). Les incertitudes absolues sur l’épaisseur ont été obtenues en mesurant l’épaisseur au pied à coulisse à plusieurs endroits des plaques. Celle sur le temps de vol moyen a été arbitrairement fixée à 4TS ✏ 0.04 µs. Les valeurs des vitesses et des incertitudes sont en adéquation avec la littérature [Selfridge 1985] car, suivant la composition de l’aluminium, la vitesse des ondes longitudinales peut varier entre 6200 et 6500 m.s✁1 . Même pour une épaisseur de 4 mm, pour laquelle les échos se mélangent partiellement, on parvient à détecter les temps de vol et à en déduire correctement une vitesse. La valeur moyenne est celle que nous utiliserons pour le contrôle non destructif de ce matériau. Le problème de l’estimation de l’impédance et de la masse volumique Les amplitudes des pics permettent de calculer l’impédance acoustique, dont on déduit la masse volumique. Concrètement, à partir de l’équation (5.7), on calcule α21 pour chaque pic détecté. Ensuite, à partir de l’impédance de l’eau Z1, l’impédance de l’aluminium est donnée par Z2 ✏ Z1 ✂ 1 ✁ α21 1 α21✡ . (5.19) Une fois les valeurs moyennées, on peut estimer l’impédance acoustique et la masse volumique, dont les valeurs sont récapitulées dans le tableau 5.2 pour plusieurs épaisseurs de plaques (pour la méthode d’optimisation sur le temps de vol). D’après les données fournies par le constructeur, l’impédance théorique1 de cet aluminium se situe plutôt autour de 16.9 MPa.s.m✁1 et la masse volumique vers 2660 kg.m✁3 . Cette différence provient de l’atténuation qui, même si elle est très faible, crée un affaiblissement de l’amplitude de la 1L’impédance théorique Z ✏ ρc est calculée à partir de la vitesse des ondes longitudinales c ✏ ❜ E♣1✁νq ρ♣1νq♣1✁2νq , où E est le module d’Young et ν est le coefficient de Poisson du matériau. 125CHAPITRE 5 : Application au CND épaisseur d (mm) impédance Z2 (MPa.s.m✁1 ) ρ2 (kg.m✁3 ) 60.4 9.3 1462 39.1 10.7 1671 20.5 12.1 1891 4.0 13.7 2154 TABLE 5.2 – Estimation de l’impédance et de la masse volumique pour plusieurs épaisseurs de plaques d’aluminium, avec les vitesses du tableau 5.1. forme a♣zq ✏ a0 exp ♣✁αzq, où z est la distance de propagation dans le matériau (voir la partie 2.1.3 page 30 pour l’analogie fréquentielle). En accord avec ce modèle, on remarque que les estimations de Z2 et de ρ2 se rapprochent des valeurs théoriques lorsque l’épaisseur diminue. Ce comportement est logique car l’atténuation est plus faible quand la distance de propagation diminue. Cette décroissance due à l’atténuation n’étant pas facile à quantifier, l’estimation de l’impédance, et donc de la masse volumique, est difficile à réaliser. Malgré tout, Zala [1992] utilise cette formulation pour retrouver les impédances lors de l’inversion, en réglant empiriquement les valeurs de a0 et α. 5.2.5 CND d’une plaque fine Nous nous intéressons au contrôle d’une plaque fine d’aluminium où le but est d’estimer l’épaisseur d à partir de la connaissance de la vitesse c0 d ✏ c0T 2 . (5.20) La vitesse c0 est obtenue grâce à l’évaluation non destructive réalisée précédemment. Nous utilisons une plaque fine d’épaisseur 2 mm inspectée par le même transducteur que dans la partie 5.2.4. Les données sont représentées sur la figure 5.5b. Dans ce cas de figure, les échos sont fortement mélangés et il est nécessaire d’utiliser une méthode de séparation d’échos. Les résultats par déconvolution avec les trois approches présentées dans la partie précédente sont affichés sur les figures 5.5c-e-g. La modélisation des signaux ainsi que les résidus d’estimation sont représentés sur les figures 5.5d-f-h. Comme dans l’exemple précédent, la déconvolution par pénalisation `1 ne fournit pas de solution acceptable car elle produit de nombreuses fausses détections. Ce surplus de pics aboutit par conséquent à une meilleure adéquation aux données et à un plus faible résidu d’estimation. La solution de SBR est acceptable et permet d’identifier quatre pics en conformité avec la vérité [Saniie et Nagle 1989]. Cette solution est néanmoins moins bonne que celle fournie par l’optimisation en fonction du temps de vol. L’a priori de pics régulièrement espacés fonctionne bien ici et aboutit à une plus grande capacité de bonnes détections (huit pics). Les résultats du calcul d’épaisseur avec SBR et l’optimisation en T sont représentés dans le tableau 5.3. A partir de la partie 5.2.2, les incertitudes de mesure sont également calculées. La déconvolution par pénalisation `1 ne permet pas d’estimer une épaisseur à cause des mauvaises détections. Une telle estimation nécessiterait un post-traitement des résultats de déconvolution afin de sélectionner, par exemple, les pics régulièrement espacés. L’optimisation en fonction du temps de vol donne l’épaisseur la plus proche de la vraie valeur. 1265.3 Matériaux atténuants 0 0.5 1 1.5 2 −1 −0.5 0 0.5 1 (a) R´eponse instrumentale hi(t) 6 8 10 12 14 −1 −0.5 0 0.5 1 (b) Donn´ees y(t) 6 8 10 12 14 −0.5 0 0.5 1 (c) D´econvolution ℓ1 xb(t) 6 8 10 12 14 −0.5 0 0.5 1 1.5 2 (e) D´econvolution SBR xb(t) 6 8 10 12 14 −0.5 0 0.5 1 1.5 2 t [µs] (g) Optimisation T xb(t) 6 8 10 12 14 −1 −0.5 0 0.5 1 (d) Mod´elisation r = 0.31770 y(t) yb(t) 6 8 10 12 14 −1 −0.5 0 0.5 1 (f) Mod´elisation r = 0.75401 y(t) yb(t) 6 8 10 12 14 −1 −0.5 0 0.5 1 t [µs] (h) Mod´elisation r = 0.51781 y(t) yb(t) FIGURE 5.5 – Déconvolution pour le CND d’une plaque d’aluminium de 2 mm d’épaisseur. (a) réponse instrumentale, (b) données, (c) déconvolution par pénalisation `1 et (d) adéquation aux données, (e) déconvolution par SBR et (f) adéquation aux données, (g) optimisation T et (h) adéquation aux données. méthode temps de vol moyen (µs) épaisseur (mm) SBR 0.612 ✟ 0.1 1.952 ✟ 0.34 optimisation T 0.620 ✟ 0.1 1.979 ✟ 0.34 TABLE 5.3 – Mesure d’épaisseur dans l’aluminium par déconvolution avec c0 ✏ 6383 ✟ 50 m.s✁1 . 5.3 Matériaux atténuants Nous utilisons ici des données acquises à partir d’une plaque de polycarbonate immergée dans l’eau. Le système instrumental emploie un transducteur non focalisé de 12.7 mm de diamètre et centré à 5 MHz. Les données sont représentées sur la figure 5.6a, les deux cadres correspondant à des dynamiques différentes pour mieux visualiser l’écho de fond. Elles sont constituées d’un écho de surface et d’un écho de fond très fortement atténué. La déconvolution est utile dans ce cas de figure pour deux raisons. Premièrement, l’écho de fond est très atténué et presque noyé dans le bruit, ce qui peut rendre sa détection visuelle difficile par un opérateur. Deuxièmement, la distorsion de la phase due à la dispersion rend compliqué le positionnement précis du temps de vol de l’écho. Pour pallier ces deux problèmes, la déconvolution prenant en compte le modèle de propagation développé au chapitre 2 permet dans cet exemple la prédiction et la détection de l’écho. Nous utilisons ici l’algorithme OLS. Le 127CHAPITRE 5 : Application au CND 0 2 −1 −0.5 0 0.5 1 (a) 2 4 6 8 10 −6 −4 −2 0 2 4 6 x 10 −3 (a) Donn´ees 0 2 −1 −0.5 0 0.5 1 (b) 2 4 6 8 10 −6 −4 −2 0 2 4 6 x 10 −3 (b) D´econvolution sans att. 0 1 2 3 4 5 6 7 8 9 10 −0.01 −0.005 0 0.005 0.01 (c) R´esidu sans att. r = 1.009 10−2 0 2 −1 −0.5 0 0.5 1 t [µs] (d) 2 4 6 8 10 −6 −4 −2 0 2 4 6 x 10 −3 t [µs] (d) D´econvolution avec att. 0 1 2 3 4 5 6 7 8 9 10 −0.01 −0.005 0 0.005 0.01 t [µs] (e) R´esidu avec att. r = 1.057 10−2 FIGURE 5.6 – Déconvolution pour le CND d’une plaque de polycarbonate de 10.2 mm d’épaisseur. (a) : données, (b) : données (–), déconvolution sans atténuation (✍) et modélisation (- -), (c) : résidu, (d) : données (–), déconvolution avec atténuation (✍) et modélisation (- -), (e) : résidu. paramètre de régularisation est réglé de façon à détecter un pic dans la région de l’écho de fond. Nous nous attendons à trouver un pic positif pour la surface et un pic négatif pour le fond (voir partie 5.2.1). Pour construire les matrices G, nous utilisons deux modèles : un modèle sans atténuation où la matrice G est construite à partir de la réponse instrumentale seule et un modèle avec atténuation linéaire et phase dispersive (se rapporter à la section 2.2 du chapitre 2 pour plus d’explications). Nous utilisons les paramètres obtenus dans la partie 2.3.4 du chapitre 2 : c0 ✏ 2273 m.s✁1 , c✽ ✏ 2280 m.s✁1 et α0 ✏ 53.5 Np.MHz✁1 .m✁1 . Les résultats de déconvolution sans et avec atténuation sont respectivement représentés sur les figures 5.6b et 5.6d. Nous traçons également les résidus d’estimation y ✁ Gxˆ sur les figures 5.6c et 5.6e. Les résultats numériques sont récapitulés dans le tableau 5.4. La Vérité Sans atténuation Avec atténuation 0 0 0 1.08 ✁ 1.40 ✁ 10.2 ✁ 10.02 10.23 ✁ TABLE 5.4 – Positions spatiales en mm et signes des pics obtenus pour la déconvolution des données de la plaque de polycarbonate de 10.2 mm d’épaisseur. 1285.4 Plaques avec trous à fond plat solution sans atténuation contient quatre pics dont un dans la zone de l’écho de fond. Il est positionné à 9.12 µs et est de signe positif, ce qui est contraire à la vérité. La position du fond correspondante est 10.02 mm. Il y a également deux fausses détections entre 1 µs et 2 µs. Ces erreurs sont dues à l’imprécision du modèle sans atténuation. Le résultat de déconvolution avec atténuation dispersive présente seulement deux pics, pour la surface et pour le fond, et de signes conformes à la réalité. L’estimation de l’épaisseur est dans ce cas plus juste : 10.23 mm. Il est à noter que l’erreur quadratique est légèrement plus faible pour le modèle sans atténuation. Ceci est dû au fait que les deux fausses détections se situent dans une zone où le bruit a une énergie importante. L’erreur résiduelle est en revanche plus faible dans la zone de l’écho de fond pour le modèle avec atténuation. 5.4 Plaques avec trous à fond plat 5.4.1 Cas d’un Ascan Dans cet exemple, le signal est acquis avec un transducteur plan circulaire de diamètre 12.7 mm et de fréquence centrale 2.25 MHz. La pièce de test est une plaque de polyméthacrylate de méthyle (PMMA2 ) d’épaisseur 23.9 mm qui contient un trou à fond plat (Flat Bottom Hole, FBH) de diamètre 10 mm et de longueur percée 0.5 mm. Ce matériau possède des propriétés d’atténuation linéaire [Selfridge 1985]. Le transducteur est placé en incidence normale par rapport à la plaque, du coté non débouchant du FBH. La proximité du FBH et du fond crée le mélange des deux échos autour de 18 µs (cf. Figure 5.7a). Le but est alors de détecter les positions du trou et du fond de la plaque. Dans ce cas de figure, la déconvolution peut permettre de retrouver les positions précises des échos mélangés. Le signal x♣ est supposé avoir un pic positif pour la surface et deux pics négatifs pour le FBH et le fond. Comme précédemment, un modèle invariant (sans atténuation) est utilisé ainsi qu’un modèle avec atténuation linéaire et phase dispersive. Les paramètres des modèles sont c0 ✏ 2771 m.s✁1 , c✽ ✏ 2805 m.s✁1 et α0 ✏ 12.3 Np.MHz✁1 .m✁1 [Carcreff et al. 2014b]. Pour cet exemple, nous utilisons un algorithme issu de SBR avec détection simultanée de deux pics à chaque itération (voir algorithme SDBR section 3.4). Cette démarche est particulièrement adaptée ici afin d’obtenir la meilleure sélection de deux pics lorsque les échos sont fortement recouvrants, alors que OLS et SBR localisent plus souvent un minimum local. Les résultats sont représentés dans les figures 5.7b et 5.7d. Les résidus sont tracés sur les figures 5.7c et 5.7e, et les résultats numériques sont reportés dans le tableau 5.5. Nous Vérité Sans atténuation Avec atténuation 0 0 0 23.4 ✁ 23.26 22.99 ✁ 23.9 ✁ 23.51 23.77 ✁ TABLE 5.5 – Positions spatiales en mm et signes des pics obtenus pour les deux exemples de déconvolution des données de la plaque de PMMA contenant un trou à fond plat. observons que les deux méthodes détectent deux pics dans la zone de mélange [17 µs, 19 µs]. Le premier pic correspond à l’écho du FBH alors que le deuxième correspond au fond de 2Le PMMA est également connu sous le nom de la marque Plexiglas®. 129CHAPITRE 5 : Application au CND 0 2 4 −1 −0.5 0 0.5 1 (a) 4 6 8 10 12 14 16 18 20 −0.1 −0.05 0 0.05 0.1 (a) Donn´ees 0 2 4 −1 −0.5 0 0.5 1 (b) 4 6 8 10 12 14 16 18 20 −0.2 −0.1 0 0.1 0.2 0.3 (b) D´econvolution sans att. 0 2 4 6 8 10 12 14 16 18 20 −0.04 −0.02 0 0.02 0.04 (c) R´esidu sans att. r = 3.704 10−2 0 2 4 −1 −0.5 0 0.5 1 t [µs] (d) 4 6 8 10 12 14 16 18 20 −0.1 −0.05 0 0.05 0.1 t [µs] (d) D´econvolution avec att. 0 2 4 6 8 10 12 14 16 18 20 −0.04 −0.02 0 0.02 0.04 t [µs] (e) R´esidu avec att. r = 2.141 10−2 FIGURE 5.7 – Déconvolution pour le CND d’une plaque de PMMA contenant un FBH. (a) : données, (b) : données (–), déconvolution sans atténuation (✍) et modélisation (- -), (c) : résidu, (d) : données (–), déconvolution avec atténuation (✍) et modélisation (- -), (e) : résidu. la plaque. Le résidu plus élevé et les pics positifs obtenus par déconvolution sans atténuation montrent bien que l’approche avec le modèle d’atténuation est plus adaptée. En effet, les deux pics détectés sont négatifs et permettent une meilleure adéquation aux données. En termes de modélisation, on remarque que la différence majeure provient de l’écho provenant du trou, l’écho de fond étant relativement bien modélisé. Comme cela a été mis en évidence dans la partie 2.3.5 du chapitre2, la signature de diffraction n’est pas prise en compte dans le modèle, et mène inévitablement à une mauvaise modélisation. La prise en compte de l’atténuation dans le modèle permet néanmoins d’assurer une bonne adéquation et de détecter correctement la position du trou. Cet exemple montre qu’il est nécessaire, dans certains cas, d’allier un modèle précis avec un algorithme plus évolué. Des améliorations pourraient cependant être réalisées en intégrant des profils de diffraction des trous à fond plat. 5.4.2 Cas d’un Bscan Nous utilisons maintenant une plaque d’aluminium de 40 mm d’épaisseur percée par quatre trous à fond plat de profondeurs 10, 4, 2 et 1 mm comme illustré sur la figure 5.8. Un transducteur diamètre 12.7 mm et de fréquence centrale 5 MHz est placé en incidence normale du côté non débouchant des trous. Plusieurs A-scans sont acquis en suivant un balayage horizontal du bras mécanique portant le transducteur pour former un B-scan. Il est représenté sur la figure 5.9a. Sur chaque ligne verticale, on peut identifier les échos provenant respectivement de la surface, du FBH le cas échéant et du fond de la plaque. Pour la déconvolution, la réponse est identifiée avec l’écho de surface de façon à former un modèle invariant. Un 1305.4 Plaques avec trous à fond plat FIGURE 5.8 – Photo des quatre trous à fond plat de diamètre 10 mm percés dans la plaque d’aluminium d’épaisseur 40 mm. Les profondeurs des trous sont respectivement 10, 4, 2 et 1 mm. x [mm] z [mm] (a) Bscan brut 50 100 150 200 250 0 10 20 30 40 50 −1 −0.5 0 0.5 1 x [mm] z [mm] (b) Bscan deconvolu´e 50 100 150 200 250 0 10 20 30 40 50 0 0.2 0.4 0.6 0.8 1 FIGURE 5.9 – Déconvolution d’un B-scan issu d’une plaque d’aluminium contenant quatre trous à fond plat. (a) B-scan brut, (b) B-scan déconvolué en valeur absolue. algorithme de type OMP est ensuite utilisé sur chaque A-scan. Grâce à la vitesse des ondes mesurée dans cet aluminium dans la partie 5.2.4 – c0 ✏ 6383 m.s✁1 – il est possible de créer une image spatiale à partir des résultats de déconvolution (voir figure 5.9a). Cette image à haute résolution permet d’identifier la géométrie de la pièce et de localiser précisément chaque trou. 131Conclusion et perspectives Conclusion générale Dans ce travail de thèse, nous nous sommes intéressés à la détection de discontinuités en contrôle non destructif ultrasonore. Dans le chapitre 1, nous avons montré que cette dé- marche pouvait se formuler comme un problème inverse où il s’agit d’identifier les temps de vol et les amplitudes d’échos reçus par le capteur. Plusieurs problèmes rendent difficile cette inversion, auxquels nous avons tenté d’apporter des solutions. Tout d’abord, le modèle direct est souvent formulé par un modèle linéaire invariant : le produit de convolution entre une réponse instrumentale et un train d’impulsions. Ce dernier est composé de pics placés aux positions des discontinuités et avec des amplitudes traduisant les changements d’impédance acoustique. Ce modèle est invariant en fonction de la distance de propagation et n’est pas adapté en présence d’atténuation. En effet, ce phénomène provoque la perte des hautes fréquences au fur et à mesure que la distance de propagation augmente. Dans le chapitre 2, nous avons par conséquent développé un modèle qui prend en compte une atténuation en loi de puissance dans le domaine fréquentiel. C’est un modèle physique à deux paramètres, qui a démontré sa capacité à modéliser correctement plusieurs types de matériaux. Dans ce modèle, la dispersion est calculée à partir des paramètres de l’atténuation de façon à respecter la causalité des signaux. Dans ce cas, nous avons en particulier proposé un calcul analytique de la dispersion lorsque la loi d’atténuation est linéaire. Le modèle reste linéaire, mais ne s’écrit plus comme un produit de convolution. Dans ce modèle, la forme des signaux change en fonction de la distance de propagation et permet de prédire la forme d’un écho pour une distance donnée. À partir de données expérimentales acquises avec des matériaux atténuants (polycarbonate, huile de ricin, mousse poreuse), nous avons montré que le modèle développé est plus performant qu’un modèle ne prenant pas en compte l’atténuation. Il est également comparé au modèle empirique d’atténuation d’Olofsson et Stepinski [2001], et fournit de meilleurs résultats. Ce modèle a été exploité pour réaliser l’évaluation non destructive de matériaux. Par une procédure de type filtre adapté, nous obtenons des estimations relativement précises du coefficient d’atténuation et de la célérité des ondes longitudinales. À la fin du chapitre 2, par l’intermédiaire de mesures réalisées sur une plaque comportant un trou à fond plat, une des limites du modèle est abordée. En effet, la diffraction due à la réflexion sur le trou a une signature particulière non prise en compte par le modèle. Le chapitre 3 se consacre aux méthodes d’estimation des temps de vol et des amplitudes des échos. Le problème inverse peut être abordé par une approche de minimisation des moindres carrés non linéaires. Il s’agit alors d’estimer un jeu de paramètres pour chaque écho défini par un modèle spécifique. Dans le chapitre 3, avec des signaux synthétiques suivant un modèle d’écho gaussien, nous mettons en évidence les difficultés des approches 133Conclusion et perspectives d’optimisation non-linéaire (Gauss-Newton, Levenberg-Marquardt, SAGE), pourtant couramment utilisées en contrôle non destructif. Celles-ci sont très sensibles aux initialisations des paramètres, et mènent souvent à une convergence vers des minima locaux. Ces mé- thodes ne semblent de ce fait pas adaptées à l’identification de plusieurs échos, de surcroît s’ils sont mélangés. D’autres méthodes utilisent un modèle linéaire, comme celui que nous avons développé. Nous montrons que le caractère mal posé du problème inverse associé ne permet pas d’utiliser une inversion directe. En effet, celle-ci a pour effet d’amplifier les hautes fréquences dues au bruit contenu dans les données. Il est donc nécessaire d’introduire une régularisation qui stabilise l’inversion et favorise une connaissance a priori de la solution. Dans notre étude, les trains d’impulsions recherchés sont des solutions piquées ou parcimonieuses, c’est-à-dire contenant un grand nombre de valeurs nulles. Nous détaillons quelques fonctions de régularisation dans le chapitre 3, notamment la norme `1 qui est très utilisée en déconvolution parcimonieuse. Cette approche est efficace et a souvent été utilisée en contrôle non destructif, mais produit des solutions avec des pics dédoublés et des pics de faibles amplitudes, à cause de la pénalisation linéaire des amplitudes. Pour cette raison, nous préférons nous intéresser à la régularisation par la pseudo-norme `0, qui pénalise la cardinalité des solutions. Cette pénalisation n’offre pas de solution algorithmique rapide et optimale, et requiert des heuristiques d’exploration des solutions. Nous détaillons quelques méthodes comme les algorithmes gloutons et l’algorithme Single Best Replacement (SBR), qui surpasse les méthodes gloutonnes. Nous avons mis en évidence les performances limitées de ces méthodes à détection simple lorsque les échos interfèrent. Nous avons proposé alors plusieurs algorithmes issus de SBR qui réalisent une exploration plus complexe. Dans un premier temps, nous présentons un algorithme réalisant des mouvements multiples dans une fenêtre. La taille de la fenêtre influe directement sur les performances, mais également sur le temps de calcul. Avec des exemples simulés, nous montrons qu’il est plus efficace que SBR, mais nécessite un temps de calcul important. Nous proposons alors de restreindre le nombre de combinaisons à tester grâce à un calcul d’auto-corrélation multidimensionnelle. Ce calcul permet de proposer les positions qui produisent les estimations les plus corrélées à l’écho de référence, cherchant ainsi à éviter les minima locaux. L’algorithme associé que nous proposons permet d’obtenir des performances nettement supérieures à SBR, pour une augmentation limitée du coût de calcul et un nombre de combinaisons testées équivalent. La discrétisation à la période d’échantillonnage du modèle de convolution continue défi- nissant notre problème, peut mener à des approximations du modèle discret. En effet, le train d’impulsions réel à retrouver est à temps continu. Dans le chapitre 4, nous avons pour cela proposé de discrétiser plus finement le produit de convolution continu. Nous avons utilisé un facteur de sur-échantillonnage qui permet d’avoir une résolution temporelle multiple de la période d’échantillonnage. Dans un cadre sans atténuation, le modèle obtenu n’est plus un produit de convolution, mais équivalent à une somme de convolutions discrètes. Nous avons montré que ce modèle a une forme générique de système à entrées multiples et sortie unique (MISO). Dans ce chapitre, nous avons mis en œuvre plusieurs algorithmes d’approximation parcimonieuse adaptés pour les systèmes MISO. Ceux-ci sont accélérés par des calculs efficaces dans le domaine de Fourier. Pour comparer les solutions obtenues avec la véritable séquence continue, nous avons utilisé un calcul de distance inspiré du domaine des neurosciences. Un exemple simple et des simulations de Monte-Carlo ont mis en évidence l’augmentation de la qualité des solutions quand le facteur de sur-échantillonnage augmente, avec un accroissement maîtrisé du coût de calcul. Nous avons enfin appliqué ces méthodes au 134Conclusion et perspectives calcul d’épaisseur de plaques minces d’aluminium, où les échos se mélangent. On parvient à une meilleure estimation de l’épaisseur grâce aux méthodes de déconvolution utilisant un modèle sur-échantillonné. Le chapitre 5 est dédié au traitement de données réelles avec des applications concrètes de contrôle non destructif. Une partie de ce chapitre est consacrée à l’estimation de la réponse instrumentale. Celle-ci peut être obtenue par mesure directe ou par des méthodes indirectes comme le moyennage dans le domaine homomorphique. Le premier cas réel abordé ensuite est le traitement des plaques homogènes dans un but d’évaluation ou de contrôle. Nous proposons pour cela une approche par moindres carrés à une inconnue, pour estimer un temps de vol moyen. Elle peut être vue comme une approche avec la contrainte d’un espacement régulier des pics. Cette méthode, spécialement adaptée aux plaques, permet d’obtenir de meilleurs résultats que la déconvolution par pénalisation `1 ou SBR. Dans un premier temps, nous appliquons les algorithmes par pénalisation `1, SBR et par minimisation par rapport au temps de vol à l’évaluation de plaques d’aluminium, où il s’agit d’estimer la vitesse des ondes longitudinales. Ensuite, le but est d’estimer l’épaisseur de plaques d’aluminium de faibles épaisseurs. Dans ce cas, les échos se superposent et les méthodes de déconvolution apportent des solutions efficaces pour identifier l’épaisseur. Le deuxième cas auquel nous nous sommes intéressés est le contrôle de matériaux atténuants. Suite à la partie expérimentale développée au chapitre 2, nous montrons ici l’intérêt du modèle avec atténuation dispersive pour la dé- tection d’échos atténués dans le polycarbonate. Ce modèle a, de par son caractère prédictif, une capacité plus importante de détection dans des environnements atténuants. La dernière partie s’intéresse à la détection de trous à fond plat dans des plaques d’aluminium et de plexiglas. Pour le plexiglas, nous avons montré ici l’intérêt d’allier un modèle adapté (notre modèle avec atténuation dispersive) à un algorithme performant à détections multiples. Dans le cas contraire, on aboutit à une mauvaise localisation du trou. Pour finir, nous formons une image B-scan à partir de plusieurs A-scan déconvolués. Ce type d’image parcimonieuse ou à haute résolution permet une meilleure interprétation, et une meilleure distinction des échos originellement mélangés. Perspectives Ce travail de recherche ouvre la voie à d’autres travaux sur les modèles ultrasonores, les méthodes d’inversion et les applications en contrôle non destructif. En ce qui concerne le modèle direct, la prise en compte des effets de diffraction est un verrou important des approches de déconvolution. Pour illustrer ce point, nous avons vu, à la fin du chapitre 2, que la réflexion sur un trou à fond plat a un effet passe-haut sur l’écho reçu. Or, ce phénomène n’est pas considéré dans le modèle développé, car nous prenons en compte l’atténuation qui a une nature passe-bas. Il sera donc intéressant de prendre en compte des signatures expérimentales dans le modèle linéaire. La difficulté de ce problème reste la multitude de signatures possibles dans un contexte de détection de défauts inconnus. Une solution consistera à proposer un certain nombre de signatures, cumulées à l’atténuation dispersive, dans un dictionnaire (à la manière des travaux de Lu et Michaels [2008]). Cette approche peut également être utilisée pour s’adapter aux réflexions multiples dans un matériau multi-couches. Une telle démarche offre l’avantage de la linéarité. Néanmoins, de par la taille importante du dictionnaire, il se pourrait que l’utilisation des algorithmes d’optimisation performants, comme OLS, SBR ou les extensions que nous avons développées, ne 135Conclusion et perspectives soient pas envisageables. L’emploi de méthodes peu coûteuses comme MP ou OMP serait sans doute incontournable. Le développement de méthodes performantes et rapides pour la détection de défauts est également un enjeu important concernant ce premier point. Pour revenir aux matériaux multi-couches, il est possible d’étendre le modèle linéaire avec atténuation pour prendre en compte plusieurs milieux successifs d’atténuations différentes. Dans un contexte d’évaluation, ceci pourrait être appliqué pour identifier les paramètres d’atténuation des différents milieux, à condition que les épaisseurs des couches soient connues et que les échos soient séparés. A la suite de cette procédure, on peut envisager de construire le modèle de propagation pour réaliser le contrôle du matériau multi-couches. Les modèles et méthodes testés dans ce travail concernent les ondes longitudinales, car nous avons réalisé nos mesures en incidence normale. Il sera donc intéressant de les tester avec des ondes transversales, qui apparaissent dans les milieux solides lorsque l’incidence est oblique. Le modèle pourrait être celui de deux systèmes concaténés, car il y aura deux types de réponses instrumentales. Cette approche pourra être appliquée dans un cadre de contrôle non destructif avec des tirs d’angle, où les deux types d’ondes se propagent, voire se mélangent. Cette perspective trouve écho pour le traitement des matériaux poreux, abordé au chapitre 2. Il sera intéressant d’étudier les modèles applicables, en termes d’atténuation et de dispersion, aux matériaux biphasiques (matériaux poreux par exemple). Ensuite, les méthodes d’inversion pourront être appliquées lorsque plusieurs types d’ondes se mélangent. Au chapitre 3, nous avons montré que les méthodes des moindres carrés non-linéaires sont intéressantes pour leur flexibilité. Par conséquent, elles permettent de s’adapter à des phénomènes difficiles à prendre en compte dans un modèle linéaire (atténuation, dispersion, diffraction). Malheureusement, elles sont sensibles aux initialisations et sont difficiles à appliquer en situation réelle. Des approches d’optimisation globale pourront pas conséquent être envisagées. Celles-ci pourraient également être couplées à des méthodes d’optimisation linéaire comme OLS ou SBR, pour raffiner l’estimation. L’étude des algorithmes de minimisation du critère des moindres carrés pénalisé par une pseudo-norme `0 effectuée au chapitre 3 mérite d’être poursuivie. Elle a en effet montré son efficacité pour des problèmes simulés (chapitre 3) et des problèmes réels de CND (chapitre 5). Les progrès récents en programmation en nombres entiers pour réaliser l’optimisation globale pourront également fournir des outils efficaces de comparaison des méthodes dé- veloppées. Par ailleurs, nous avons vu qu’il est possible de restreindre le nombre de candidats par une procédure d’auto-corrélation temporelle. Cette approche mène malheureusement à une implémentation logicielle non optimale avec Matlab, à cause des recherches d’indices et d’indexations qui sont lentes à effectuer. Il sera avantageux de comparer les algorithmes avec une implémentation faite sous un autre langage. D’un point de vue applicatif, les sondes multi-éléments sont très utilisées actuellement. L’approche de déconvolution parcimonieuse pourra par conséquent être adaptée à ce type de transducteurs. Cela nécessitera par exemple d’utiliser une réponse instrumentale par élément ou des réponses inter-éléments [Kerbrat et al. 2002]. Des extensions pourront être nécessaires à l’adaptation des méthodes inverses aux spécificités des multi-éléments, comme la focalisation, le tir avec angle, etc. De nos jours, les méthodes d’imagerie Synthetic Aperture Focusing Technique (SAFT) [Karaman et al. 1995, Lingvall et al. 2003] ou Focalisation en Tout Point (FTP) [Holmes et al. 2005] sont très utilisées et demandées par les industriels. Ces méthodes d’imagerie, couplées aux approches de déconvolution parcimonieuse, pourront fournir des performances supérieures en termes de reconstruction. Elles seront notamment intéressantes 136Conclusion et perspectives pour réduire le bruit de structure grâce à la capacité de débruitage de la déconvolution. L’application des modèles et méthodes est également possible pour d’autres techniques d’imagerie, notamment dans le domaine biomédical, comme la tomographie ultrasonore [Glover et Sharp 1977, Greenleaf et Bahn 1981] ou la restauration d’images biomédicales [Fatemi et Kak 1980, Jensen 1991]. 137Annexe A Relations de causalité A.1 Relation entre la partie réelle et imaginaire d’une fonction continue causale Tout signal h♣tq réel1 peut être considéré comme la somme d’un signal pair he♣tq et d’un signal impair ho♣tq [Papoulis 1962, Oppenheim et Schafer 1989] h♣tq ✏ he♣tq ho♣tq, (A.1) avec he♣tq ✏ h♣tq h♣✁tq 2 , (A.2) et ho♣tq ✏ h♣tq ✁ h♣✁tq 2 . (A.3) Si la transformée de Fourier de h♣tq est H♣fq ✏ R♣fq jX♣fq alors ✧ he♣tq ðñ R♣fq, ho♣tq ðñ X♣fq. (A.4) Si h♣tq est causale alors h♣tq ✏ 0 pour t ➔ 0 et réciproquement h♣✁tq ✏ 0 pour t → 0. h♣tq et h♣✁tq ne se superposant pas, excepté pour t ✏ 0, on peut écrire h♣tq ✏ 2he♣tqγ♣tq ✁ he♣0qδ♣tq, (A.5) où γ♣tq est la fonction échelon telle que γ♣tq ✏ ✧ 0 ❅t ➔ 0 1 ❅t ➙ 0. (A.6) La transformée de Fourier de γ♣tq est Γ♣fq ✏ 1 2 δ♣fq 1 j2πf . D’après l’équation (A.5), on peut écrire l’expression de la transformée de Fourier de h♣tq H♣fq ✏ 2R♣fq ✝ Γ♣fq ✁ he♣0q ✏ 2R♣fq ✝ ✂ 1 2 δ♣fq 1 j2πf ✡ ✁ he♣0q ✏ R♣fq jR♣fq ✝ ✁ 1 πf ✁ he♣0q. (A.7) 1 Il est possible de généraliser pour des signaux complexes (voir [Oppenheim et Schafer 1989]). 139CHAPITRE A : Relations de causalité La partie imaginaire de H♣fq s’écrit donc X♣fq ✏ R♣fq ✝ ✁ 1 πf ✏ ✁ 1 π ➺ ✽ ✁✽ R♣fq f ✁ s ds. (A.8) Cette dernière expression qui permet de déduire la partie imaginaire d’une fonction analytique à partir de sa partie réelle n’est autre que la transformée de Hilbert de R♣fq [Papoulis 1962, Oppenheim et Schafer 1989]. Notons également que h♣0q ✏ he♣0q ✏ ➺ ✽ ✁✽ R♣fqdf. (A.9) A.2 Relation entre le module et la phase d’une fonction discrète causale Pour plus de clarté nous posons ω ✏ 2πf, où ω est la pulsation en rad/s. Oppenheim et Schafer étendent le calcul précédent à des signaux à temps discret [Oppenheim et Schafer 1989]. Nous définissons le signal échelon à temps discret γrns ✏ γ♣nTSq, où TS est la période d’échantillonnage. La transformée de Fourier de γrns est Γ♣ωq ✏ ✽ ➳ k✏✁✽ πδ♣ω 2kπq 1 1 ✁ e ✁jω . (A.10) Le terme 1 1✁e✁jω peut être réécrit 1 1 ✁ e ✁jω ✏ 1 1 ✁ cos ω j sin ω ✏ 1 2 1 ✁ cos ω ✁ j sin ω 1 ✁ cos ω ✏ 1 2 ✁ 1 ✁ j cot ω 2 ✠ . (A.11) D’après l’équation (A.5), la transformée de Fourier de h♣tq s’écrit H♣ωq ✏ 2R♣ωq ✝ Γ♣ωq ✁ hr0s ✏ 1 2π ➺ π ✁π 2R♣θqΓ♣ω ✁ θqdθ ✁ hr0s ✏ 1 π ➺ π ✁π R♣ωq ✝ ✓ ✽ ➳ k✏✁✽ πδ♣θ 2kπq 1 2 ✂ 1 ✁ j cot ω ✁ θ 2 ✡✛ dθ ✁ hr0s ✏ R♣ωq 1 2π ➺ π ✁π R♣θqdθ ✁ j 1 2π ➺ π ✁π R♣θq cot ω ✁ θ 2 dθ ✁ hr0s ✏ R♣ωq ✁ j 1 2π ➺ π ✁π R♣θq cot ω ✁ θ 2 dθ. (A.12) La partie imaginaire de H♣ωq pour des signaux à temps discret s’écrit alors X♣ωq ✏ ✁ 1 2π P ➺ π ✁π R♣θq cot ✂ θ ✁ ω 2 ✡ dθ, (A.13) où P est la valeur principale de Cauchy. Pour une singularité en a, cette dernière est définie par P ➺ ✽ ✁✽ f♣xqdx ✏ limÑ0 ✂➺ a✁ ✁✽ f♣xqdx ➺ ✽ a f♣xqdx ✡ . (A.14) 140A.2 Relations de causalité Dans l’équation A.13, la singularité est en θ ✏ ω. Si une réponse a pour transformée de Fourier H♣ωq ✏ A♣ωqe jφ♣ωq , alors ln H♣ωq ✏ ln ⑤A♣ωq⑤ jφ♣ωq. Si on considère que ln H♣ωq est le spectre d’une fonction causale, l’équation (A.13) devient φ♣ωq ✏ ✁ 1 2π P ➺ π ✁π ln ⑤A♣ωq⑤ cot ✂ θ ✁ ω 2 ✡ dθ. (A.15) Dans le cas d’un module fonction de la fréquence, de la forme A♣fq ✏ e ✁α♣fq , on aboutit à φ♣fq ✏ 1 fS P ➺ fS 2 ✁ fS 2 α♣gq cot ✂ π fS ♣f ✁ gq ✡ dg, (A.16) où fS est la fréquence d’échantillonnage. A.2.1 Calcul de la phase dispersive pour une atténuation linéaire Avec une atténuation linéaire α♣fq ✏ α0⑤f⑤, le terme de phase (2.33) est ♣fq ✏ ✁α0fS 4π 2 J ✂ 2πf fS ✡ , avec J ♣ωq ✏ P ➺ π ✁π ⑤v⑤ cot ✁ω ✁ v 2 ✠ dv, ω P r✁π, πs. (A.17) La fonction J ♣ωq est impaire avec J ♣πq ✏ 0. Nous considérons ω Ps0, πr. En posant u ✏ ω ✁ v, nous obtenons J ♣ωq ✏ P ➺ ω ω✁π ♣ω ✁ uq cot u 2 du ✁ ➺ ωπ ω ♣ω ✁ uq cot u 2 du, (A.18) où la valeur principale de Cauchy de la première intégrale exclut 0 du domaine. Soit Fω♣uq la primitive de ♣ω ✁ uq cot u 2 . La primitive de cot u 2 est 2 ln ✞ ✞sin u 2 ✞ ✞ . De ce fait, une intégration par parties aboutit pour u Ps ✁ 2π, 2πr, u ✘ 0 à Fω♣uq ✏ 2♣ω ✁ uqln ✞ ✞ ✞ sin u 2 ✞ ✞ ✞ 2 ➺ u 0 ln ✞ ✞ ✞ sin ϕ 2 ✞ ✞ ✞ dϕ. (A.19) La dernière intégrale respecte alors ➺ u 0 ln ✞ ✞ ✞ sin ϕ 2 ✞ ✞ ✞ dϕ ✏ ✁Cl2♣uq ✁ u ln♣2q, (A.20) où Cl2♣uq ✏ ✁ ➩u 0 ln ✞ ✞2 sin ϕ 2 ✞ ✞ dϕ est la fonction de Clausen à l’ordre 2, i.e., la partie imaginaire du dilogarithme de e ju [Maximon 2003]. A partir de (A.18)-(A.20), on peut montrer que J ♣ωq ✏ 2Cl2♣ω πq 2Cl2♣ω ✁ πq ✁ 4Cl2♣ωq ✏ 4 ♣Cl2♣ω πq ✁ Cl2♣ωqq. (A.21) Finalement, on peut montrer que (A.21) est également valide pour w P r✁π, 0s. 141Annexe B Modèle de réponse impulsionnelle instrumentale B.1 Modèle d’écho gaussien Nous avons vu que la réponse impulsionnelle instrumentale peut être modélisée par un écho gaussien hi♣t, θq ✏ Ae✁ ♣t✁τq 2 2σ2 t cos♣2πf0♣t ✁ τ q φq, (B.1) où A est l’amplitude de l’écho, τ est le temps de vol, σ 2 t est la variance de l’enveloppe gaussienne, f0 est la fréquence centrale et φ est le décalage de phase. On définit alors le vecteur de paramètres θ ✏ rσt τ f0 φ As. B.2 Facteur de bande passante B.2.1 Définition Il est d’usage de définir un transducteur par son facteur de bande passante (bandwidth ratio, BWR) : BWRp ✏ ∆f ♣pq f0 , (B.2) où ∆f ♣pq est la largeur de bande fréquentielle pour une perte de p dB. Un facteur proche de zéro indique un signal à bande étroite tandis qu’un facteur supérieur à un correspond à un signal large bande. La perte p est définie comme le rapport des puissances en décibels p ✏ 10 log πp ✏ 20 log πa, (B.3) où πp désigne le rapport en puissance et πa le rapport en amplitude. Quelques correspondances sont récapitulées dans le tableau B.1. La convention la plus adoptée est de prendre la bande passante à mi-puissance maximale (half power bandwidth, HPBW) [Lingvall 2004b], c’est-à-dire p ✏ ✁3 dB. 143ANNEXE B : Modèle de réponse impulsionnelle instrumentale πp πa p (dB) ❄ 2 2 ✓ 0.707 ❜❄ 2 2 ✓ 0.84 -1.5 1 2 ✏ 0.5 ❄ 2 2 ✓ 0.707 -3 1 4 ✏ 0.25 1 2 ✏ 0.5 -6 1 16 ✏ 0.0625 1 4 ✏ 0.25 -12 TABLE B.1 – Exemples de correspondance entre le rapport de puissance πp, le rapport d’amplitude πa et la perte en décibels p. B.2.2 Application à la forme d’onde gaussienne Le module de la transformée de Fourier de la forme temporelle (B.1) est la somme de deux gaussiennes centrées en ✁f0 et f0. En considérant f0 ✧ 0, on peut négliger la contribution de la gaussienne en ✁f0 sur la gaussienne en f0. Cette dernière s’écrit ⑤Hi♣fq⑤ ✏ A ✶ e ♣f✁f0q 2 2σ2 f (B.4) avec A✶ ✏ Aσt ❄ 2π et σf ✏ 1④♣2πσtq. Nous cherchons ensuite la largeur de bande qui correspond à e ♣f✁f0q 2 2σ2 f ✏ πa. Après quelques manipulations, il vient ∆f ♣pq ✏ 2 ❜ 2σ 2 f ln ♣1④πaq. (B.5) Le facteur de bande passante est donc BWRp ✏ ∆f ♣pq f0 ✏ 2 ❛ 2 ln ♣1④πaq σf f0 , (B.6) et permet d’obtenir la variance fréquentielle σ 2 f ✏ ♣BWRpf0q 2 8 ln ♣1④πaq ✏ ✁ ♣BWRpf0q 2 8 ln ♣10p④20q . (B.7) Ce calcul permet donc de générer des échos gaussiens grâce à un paramètre physique de largeur de bande . Dans la réalité, les transducteurs ultrasonores ont des facteurs BWR✁3 compris entre 0.1 et 0.9. Plusieurs exemples de signaux avec des facteurs BWR✁3 différents sont représentés sur la figure B.1. 144B.2 Facteur de bande passante −2 −1 0 1 2 −1 −0.5 0 0.5 1 (a) : BWR−3 = 0.1 −2 −1 0 1 2 −1 −0.5 0 0.5 1 (b) : BWR−3 = 0.3 −2 −1 0 1 2 −0.5 0 0.5 1 t [µs] (c) : BWR−3 = 0.1 0 5 10 15 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 f [MHz] (d) : Transform´ees de Fourier BWR−3 = 0.1 BWR−3 = 0.3 BWR−3 = 0.9 FIGURE B.1 – Exemples de formes d’onde gaussiennes pour trois valeurs de BWRp (a-bc) avec p ✏ ✁3 et transformées de Fourier normalisées correspondantes (d). Paramètres : A ✏ 1, t0 ✏ 0 µs, f0 ✏ 5 MHz, φ ✏ 0. 145Annexe C Détails des calculs algorithmiques C.1 Critère d’ajout pour OLS et SBR Il s’agit d’ajouter d’une composante n ❘ Qi✁1 à l’itération courante i telle que Gi ✏ rGi✁1, gn s où gn est une colonne de G. On calcule alors la différence de critère ∆J n Qi✁1 ✏ µ ✎ ✎ ✎y ✁ Gi GT i Gi ✟✁1 GT i y ✎ ✎ ✎ 2 ✁ ✎ ✎ ✎y ✁ Gi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1y ✎ ✎ ✎ 2 . (C.1) Notons que ✎ ✎ ✎y ✁ G GTG ✟✁1 GT y ✎ ✎ ✎ 2 2 ✏ ✁ y T ✁ y TG GTG ✟✁1 GT ✠ ✁y ✁ G GTG ✟✁1 GT y ✠ ✏ ⑥y⑥ 2 ✁ 2y TG GTG ✟✁1 GT y y TG GTG ✟✁1 GTG GTG ✟✁1 GT y ✏ ⑥y⑥ 2 ✁ y TG GTG ✟✁1 GT y. (C.2) La différence de critère est alors ∆J n Qi✁1 ✏ µ ⑥y⑥ 2 ✁ y TGi GT i Gi ✟✁1 GT i y ✁ ⑥y⑥ 2 y TGi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1y ✏ µ y T ✁ Gi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1 ✁ Gi GT i Gi ✟✁1 GT i ✠ y. (C.3) Nous utilisons ensuite la décomposition Cholesky qui permet de poser GT i Gi ✏ LiL T i avec Li ✏ ✒ Li✁1 0 v T n an ✚ , (C.4) où vn ✏ L ✁1 i✁1GT i✁1gn et an ✏ ❜ ⑥gn ⑥ 2 ✁ ⑥vn⑥ 2 . LiL T i devient alors LiL T i ✏ ✒ Li✁1L T i✁1 Li✁1vn v T nL T i✁1 ⑥gn ⑥ 2 ✚ . (C.5) En utilisant le lemme d’inversion d’une matrice partitionnée, son inverse s’écrit LiL T i ✟✁1 ✏ ✔ ✕ Li✁1L T i✁1 ✟✁1 ♣LT i✁1 q ✁1vnv T n L ✁1 i✁1 ⑥gn⑥ 2✁⑥vn⑥ 2 ✁ ♣LT i✁1 q ✁1vn ⑥gn⑥ 2✁⑥vn⑥ 2 ✁ vnL ✁1 i✁1 ⑥gn⑥ 2✁⑥vn⑥ 2 1 ⑥gn⑥ 2✁⑥vn⑥ 2 ✜ ✢ . (C.6) 147ANNEXE C : Détails des calculs algorithmiques En insérant cette expression dans l’équation (C.3), on obtient ∆J n Qi✁1 ✏ µ y T ✁ Gi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1 ✁ Gi GT i Gi ✟✁1 GT i ✠ y ✏ µ y T ✁ Gi✁1 Li✁1L T i✁1 ✟✁1 GT i✁1 ✁ rGi✁1, gn s LiL T i ✟✁1 rGi✁1, gn s T ✠ y ✏ 1 ⑥gn⑥ 2✁⑥vn⑥ 2 y TGi✁1♣L T i✁1 q ✁1vnv T nL ✁1 i✁1GT i✁1y ✁ y T gnv T nL ✁1 i✁1GT i✁1y ✁y TGi✁1♣L T i✁1 q ✁1vng T n y y T gng T n y ✟ ✏ v T nL ✁1 i✁1GT i✁1y ✁ g T n y ✟2 ⑥gn ⑥ 2 ✁ ⑥vn⑥ 2 . (C.7) En posant ui✁1 ✏ L ✁1 i✁1GT i✁1y, la différence de critère est [Chen et al. 1989, Soussen et al. 2011] : ∆J n Qi✁1 ✏ µ ✁ v T nui✁1 ✁ g T n y ✟2 ⑥gn ⑥ 2 ✁ ⑥vn⑥ 2 . (C.8) C.2 Critère de retrait pour SBR Ici, on retire une colonne gm de Gi✁1 avec m P Qi✁1 : Gi✁1 ✏ rGi , gms. Le critère à calculer est toujours ∆J ✁m Qi✁1 ✏ ✁µ y T ✁ Gi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1 ✁ Gi GT i Gi ✟✁1 GT i ✠ y. (C.9) On a alors GT i✁1Gi✁1 ✏ ✒ GT i Gi GT i gm g T mGi ⑥gm⑥ 2 ✚ , (C.10) qui, grâce au lemme d’inversion de matrice partitionnée, a pour inverse GT i✁1Gi✁1 ✟✁1 ✏ ✒Wm wm wT m γm ✚ , (C.11) avec Wm ✏ GT i Gi ✟✁1 GT i Gi ✟✁1 GT i gmγmg T mGi GT i Gi ✟✁1 , (C.12) wm ✏ ✁ GT i Gi ✟✁1 GT i gmγm, (C.13) et γm ✏ ✁ ⑥gm⑥ 2 ✁ g T mGi GT i Gi ✟✁1 GT i gm ✠✁1 . (C.14) Par identification, on obtient Wm ✏ GT i Gi ✟✁1 wmγ ✁1 m wT m. (C.15) On peut alors écrire GT i✁1Gi✁1 ✟✁1 Gi✁1 ✏ ✒Wm wm wT m γm ✚ ✒GT i g T m ✚ ✏ ✒WmGT i wmg T m wT mGT i γmg T m ✚ , (C.16) 148C.2 Critère de retrait pour SBR et ensuite, grâce à l’expression de Wm dans l’équation (C.15) Gi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1 ✏ GiWmGT i Giwmg T m gmwT mGT i gmγmg T m ✏ Gi GT i Gi ✟✁1 GT i Giwmγ ✁1 m wT mGT i Giwmg T m gmwT mGT i gmγmg T m. (C.17) Le critère s’écrit alors ∆J ✁m Qi✁1 ✏ ✁µ y T ✁ Gi✁1 GT i✁1Gi✁1 ✟✁1 GT i✁1 ✁ Gi GT i Gi ✟✁1 GT i ✠ y ✏ ✁µ γ ✁1 m y TGiwmwT mGT i y y TGiwmγmg T my y T gmγmwT mGT i y y T gmγ 2 mg T my ✟ ✏ ✁µ γ ✁1 m wT mGT i y γmg T my ✟T wT mGT i y γmg T my ✟ ✏ ✁µ γ ✁1 m wT mGT i y γmg T my ✟2 . (C.18) A partir de l’équation (C.16), le m-ème terme de la solution x♣i✁1 ✏ GT i✁1Gi✁1 ✟✁1 GT i✁1y apparaît. Le critère pour le retrait d’un élément s’écrit alors [Reeves 1999, Miller 2002, Soussen et al. 2011] ∆J ✁m Qi✁1 ✏ x♣ 2 i✁1 rms γm ✁ µ. (C.19) 149Bibliographie AHARON, M., ELAD, M. et BRUCKSTEIN, A. (2006). K-SVD : An Algorithm for Designing Overcomplete Dictionaries for Sparse Representation. IEEE Transactions on Signal Processing, 54(11):4311–4322. 22, 120 AKAIKE, H. (1974). A new look at the statistical model identification. IEEE Transactions of automatic control, 19:716–723. 80 BAZARAA, M. S., SHERALI, H. D. et SHETTY, C. M. (2013). Nonlinear programming : theory and algorithms. John Wiley & Sons. 69 BIOT, M. A. (1956a). Theory of propagation of elastic waves in a fluid-saturated porous solid. I. Low-frequency range. The Journal of the Acoustical Society of America, 28(2): 168–178. 56 BIOT, M. A. (1956b). Theory of propagation of elastic waves in a fluid-saturated porous solid. II. Higher frequency range. The Journal of the Acoustical Society of America, 28(2): 179–191. 56 BLUMENSATH, T. et DAVIES, M. E. (2007). On the difference between Orthogonal Matching Pursuit and Orthogonal Least Squares. Rapport technique, University of Edinburgh. 80, 105, 107 BOSSMANN, F., PLONKA, G., PETER, T., NEMITZ, O. et SCHMITTE, T. (2012). Sparse Deconvolution Methods for Ultrasonic NDT. Journal of Nondestructive Evaluation, 31(3):225–244. 22 BOURGUIGNON, S., SOUSSEN, C., CARFANTAN, H. et IDIER, J. (2011). Sparse deconvolution : Comparison of statistical and deterministic approaches. In IEEE Statistical Signal Processing Workshop, pages 317–320. 23, 105 BRUNEAU, M. (1998). Manuel d’acoustique fondamentale. Hermes, Paris. 14, 15 CARCREFF, E., BOURGUIGNON, S., IDIER, J. et SIMON, L. (2012). High-resolution deconvolution applied to non destructive testing. In Acoustics 2012, Nantes, France. 42, 102 CARCREFF, E., BOURGUIGNON, S., IDIER, J. et SIMON, L. (2013a). Algorithmes de déconvolution impulsionnelle à résolution augmentée. In Actes du 24e colloque GRETSI, Brest, France. 42, 102 151BIBLIOGRAPHIE CARCREFF, E., BOURGUIGNON, S., IDIER, J. et SIMON, L. (2013b). Resolution enhancement of ultrasonic signals by up-sampled sparse deconvolution. In Proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing, pages 6511– 6515, Vancouver, Canada. 42, 102 CARCREFF, E., BOURGUIGNON, S., IDIER, J. et SIMON, L. (2014a). Contrôle non destructif des matériaux attnuants et dispersifs par d ´ convolution impulsionnelle. ´ In Actes du 12e Congrès Français d’Acoustique, Poitiers, France. 26 CARCREFF, E., BOURGUIGNON, S., IDIER, J. et SIMON, L. (2014b). A linear model approach for ultrasonic inverse problems with attenuation and dispersion. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 61(7):1191–1203. 26, 36, 129 CARCREFF, E., BOURGUIGNON, S., IDIER, J., SIMON, L. et DUCLOS, A. (2013c). Including frequency-dependent attenuation for the deconvolution of ultrasonic signals. In 19th International Congress on Acoustics, Montréal, Québec, Canada. 26 CARSTENSEN, E. L. et SCHWAN, H. P. (1959). Acoustic properties of hemoglobin solutions. The Journal of the Acoustical Society of America, 31(3):305–311. 34 CASSEREAU, D., GUYOMAR, D. et FINK, M. (1988). Time deconvolution of diffraction effects - application to calibration and prediction of tranducer waveforms. The Journal of Acoustical Society of America, 84(3):1073–1085. 62, 118 CHAMPAGNAT, F., GOUSSARD, Y. et IDIER, J. (1996). Unsupervised deconvolution of sparse spike trains using stochastic approximation. IEEE Transactions on Signal Processing, 44(12):2988–2998. 23 CHEN, C.-H., HSU, W.-L. et SIN, S.-K. (1988). A comparison of wavelet deconvolution techniques for ultrasonic NDT. In IEEE International Conference on Acoustics, Speech, and Signal Processing, volume 2, pages 867–870, New-York, USA. 23, 26 CHEN, S., BILLINGS, S. et LUO, W. (1989). Orthogonal least squares methods and their application to non-linear system identification. International Journal of Control, 50(5): 1873–1896. 23, 80, 82, 148 CHEN, S. S., DONOHO, D. L. et SAUNDERS, M. A. (1998). Atomic decomposition by basis pursuit. SIAM J. Sci. Comput., 20(1):33–61. 23, 76, 80 CHOUZENOUX, E. (2010). Recherche de pas par Majoration-Minoration. Application à la résolution de problèmes inverses. Thèse de doctorat, École Centrale de Nantes. 69 CHUNG, P. J. et BÖHME, J. F. (2001). Comparative convergence analysis of EM and SAGE algorithms in DOA estimation. IEEE Transactions on Signal Processing, 49(12):2940– 2949. 71 COOLEY, J. W. et TUKEY, J. W. (1965). An algorithm for the machine calculation of complex Fourier series. Mathematics of computation, 19(90):297–301. 106 152BIBLIOGRAPHIE COUVREUR, C. et BRESLER, Y. (2000). On the optimality of the backward greedy algorithm for the subset selection problem. The SIAM Journal on Matrix Analysis and Applications, 21(3):797–808. 85 DAVIES, M. et DAUDET, L. (2003). Sparsifying subband decompositions. In IEEE Workshop on Applications of Signal Processing to Audio and Acoustics, pages 107–110. 76 DEMIRLI, R. et SANIIE, J. (2000). Model based time-frequency estimation of ultrasonic echoes for NDE applications. In IEEE International Ultrasonics Symposium, volume 1, pages 785–788. 66 DEMIRLI, R. et SANIIE, J. (2001a). Model-based estimation of ultrasonic echoes. Part I : Analysis and algorithms. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 48(3):787–802. 10, 22, 23, 66, 71, 72, 104 DEMIRLI, R. et SANIIE, J. (2001b). Model-based estimation of ultrasonic echoes. Part II : Nondestructive evaluation applications. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 48(3):803–811. 22, 67, 72, 73 DEMIRLI, R. et SANIIE, J. (2009). A generic parametric model for ultrasonic signal analysis. In IEEE International Ultrasonics Symposium, pages 1522–1525. 22, 67 DEMIRLI, R. et SANIIE, J. (2010). Asymmetric gaussian chirplet model for ultrasonic echo analysis. In IEEE International Ultrasonics Symposium, pages 124–128. 67 DEMOMENT, G., REYNAUD, R. et HERMENT, A. (1984). Range resolution improvement by a fast deconvolution method. Ultrasonic Imaging, 6(4):435–451. 76 DONOHO, D. L. et ELAD, M. (2003). Optimally sparse representation in general (nonorthogonal) dictionaries via `1 minimization. In Proc. Natl Acad. Sci., volume 100, pages 2197–2202, USA. 80 DROIN, P., BERGER, G. et LAUGIER, P. (1998). Velocity dispersion of acoustic waves in cancellous bone. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 45(3):581–592. 34 DUCK, F. A. (1990). Physical properties of tissue. Academic Press, London. 29 EFRON, B. T., HASTIE, T., JOHNSTONE, L. et TIBSHIRANI, R. (2002). Least angle regression. Annals of Statistics, 32:407–499. 76 ELAD, M. (2010). Sparse and Redundant Representations : From Theory to Applications in Signal and Image Processing. Springer. 75, 76, 81 FATEMI, M. et KAK, A. C. (1980). Ultrasonic B-scan imaging : Theory of image formation and a technique for restoration. Ultrasonic Imaging, 2(1):1–47. 76, 137 FEDER, M. et WEINSTEIN, E. (1988). Parameter estimation of superimposed signals using the EM algorithm. IEEE Transactions on Acoustics, Speech and Signal Processing, 36(4): 477–489. 71 153BIBLIOGRAPHIE FESSLER, J. et HERO, A. (1993). Complete-data spaces and generalized EM algorithms. In IEEE International Conference on Acoustics, Speech, and Signal Processing, volume 4, pages 1–4, Minneapolis, USA. 22 FESSLER, J. A. et HERO, A. O. (1994). Space-alternating generalized expectationmaximization algorithm. IEEE Transactions on Signal Processing, 42(10):2664–2677. 71 FINK, M. et CARDOSO, J.-F. (1984). Diffraction effects in pulse-echo measurement. IEEE Transactions on Sonics and Ultrasonics, 31(4):313–329. 26, 27, 62 FITZGIBBON, L. J., DOWE, D. L. et VAHID, F. (2004). Minimum message length autoregressive model order selection. In International Conference on Intelligent Sensing and Information Processing, pages 439–444. 80 FORTIER, N. (1990). Détermination des hyperparamètres dans les méthodes linéaires de restauration d’image. Thèse de doctorat, Université de Paris Sud, Centre d’Orsay. 79 GLOVER, G. H. et SHARP, J. C. (1977). Reconstruction of ultrasound propagation speed distributions in soft tissue : Time-Of-Flight tomography. IEEE Transactions on Sonics and Ultrasonics, 24(4):229–234. 137 GOLUB, G. H., HEATH, M. et WAHBA, G. (1979). Generalized cross-validation as a method for choosing a good ridge parameter. Technometrics, 21:215–223. 80, 83 GOLUB, G. H. et VAN LOAN, C. F. (1996). Matrix Computations, volume 3. The Johns Hopkins University Press, Baltimore and London. 106, 107 GOUSSARD, Y., DEMOMENT, G. et IDIER, J. (1990). A new algorithm for iterative deconvolution of sparse spike trains. In IEEE International Conference on Acoustic, Speech and Signal Processing, pages 1547–1550, Albuquerque, NM, USA. 23, 84 GRAY, R. M. (2006). Toeplitz and circulant matrices : A review. now publishers inc. 40, 102 GREENLEAF, J. F. et BAHN, R. C. (1981). Clinical imaging with transmissive ultrasonic computerized tomography. IEEE Transactions on Biomedical Engineering, 28(2):177– 185. 137 GURUMURTHY, K. V. et ARTHUR, R. M. (1982). A dispersive model for the propagation of ultrasound in soft tissue. Ultrasonic Imaging, 4(4):355–377. 24, 35, 36 HAIAT, G., PADILLA, F., CLEVELAND, R. et LAUGIER, P. (2006). Effects of frequencydependent attenuation and velocity dispersion on in vitro ultrasound velocity measurements in intact human femur specimens. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 53(1):39–51. 34 HALE, D. (1981). An inverse Q-filter. Stanford Exploration Project, 26:231–244. 23, 43 HARGREAVES, N. et CALVERT, A. (1991). Inverse Q-filtering by Fourier transform. Geophysics, 56:519–527. 30 154BIBLIOGRAPHIE HARRIS, G. R. (1981). Review of transient field theory for a baffled planar piston. The Journal of the Acoustical Society of America, 70(1):10–20. 27 HARRIS, G. R., HERMAN, B. A., SMITH, S. W. et BODINE, W. J. (1983). Through transmission technique for ultrasonic attenuation measurement using broadband, plane wave pulses. In Ultrasonics Symposium, pages 778–781. 29 HE, H., IDIER, J., BALTAZART, V. et WANG, Y. (2011). Déconvolution impulsionnelle par optimisation combinatoire exacte et application au CND radar. In Actes du 23e colloque GRETSI, Bordeaux. 23 HE, P. (1999). Experimental verification of models for determining dispersion from attenuation. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 46(3):706–714. 10, 24, 29, 35, 36, 53 HOLMES, C., DRINKWATER, B. W. et WILCOX, P. (2005). Post-processing of the full matrix of ultrasonic transmit-receive array data for non-destructive evaluation. NDT&E International, 38(8):701–711. 136 HONG, J.-C., SUN, K. H. et KIM, Y. Y. (2006). Waveguide damage detection by the matching pursuit approach employing the dispersion-based chirp functions. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 53(3):592–605. 22 HONG, X., SHARKEY, P. et WARWICK, K. (2003). Automatic nonlinear predictive modelconstruction algorithm using forward regression and the PRESS statistic. IEE Proceedings - Control Theory and Applications, 150:245–254. 80 IDIER, J. (2001). Approche bayésienne pour les problèmes inverses. Traité IC2, Série traitement du signal et de l’image, Hermès, Paris. 19, 21, 22, 40, 41, 74, 76, 78 JENSEN, J. A. (1991). Estimation of pulses in ultrasound B-scan images. IEEE Transactions on Medical Imaging, 10(2):164–172. 137 JENSEN, J. A. (1992). Deconvolution of ultrasound images. Ultrasonic Imaging, 14(1):1–15. 76 JONSCHER, A. K. (1983). Dielectric relaxation in solids. Chelsea Dielectrics Press, London. 14 KAARESEN, K. F. (1997). Deconvolution of sparse spike trains by iterated window maximization. IEEE Transactions on Signal Processing, 45(5):1173–1183. 23, 89 KAARESEN, K. F. (1998). Evaluation and applications of the iterated window maximization method for sparse deconvolution. IEEE Transactions on Signal Processing, 46(3):609– 624. 23, 89 KAARESEN, K. F. et BOLVIKEN, E. (1999). Blind deconvolution of ultrasonic traces accounting for pulse variance. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 46(3):564–573. 23 155BIBLIOGRAPHIE KAK, A. C. et DINES, K. A. (1978). Signal processing of broadband pulsed ultrasound : Measurement of attenuation of soft biological tissues. IEEE Transactions on Biomedical Engineering, 25(4):321–344. 24, 29, 34 KARAMAN, M., LI, P.-C. et O’DONNELL, M. (1995). Synthetic aperture imaging for small scale systems. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 42(3):429–442. 136 KELLY, J. F., MCGOUGH, R. J. et MEERSCHAERT, M. M. (2008). Analytical time-domain Green’s functions for power-law media. The Journal of the Acoustical Society of America, 124(5):2861–2872. 29, 35 KERBRAT, E., PRADA, C., CASSEREAU, D. et FINK, M. (2002). Ultrasonic nondestructive testing of scattering media using the decomposition of the time-reversal operator. IEEE Transactions on Ultrasonics, Ferroelectrics, and Frequency Control, 49(8):1103–1113. 136 KJARTANSSON, E. (1979). Constant Q-Wave Propagation and Attenuation. Journal of Geophysical Research, 84(B9):4737–4748. 23, 30 KORMYLO, J. J. et MENDEL, J. M. (1982). Maximum likelihood detection and estimation of Bernoulli - Gaussian processes. IEEE Transactions on Information Theory, 28(3):482– 488. 23, 79, 84 KRAMERS, H. A. (1927). La diffusion de la lumière par les atomes. In Atti del Congresso Internatzionale dei Fisici, volume 2, pages 545–557, Como-Pavia-Roma, Italy. Zanichelli. 34 KRAUTKRAMER, J. et KRAUTKRAMER, H. (1990). Ultrasonic Testing of materials. Springer-Verlag, Berlin. 9, 14, 15, 16, 17, 28, 118, 122, 124 KREUTZ-DELGADO, K., MURRAY, J. F., RAO, B. D., ENGAN, K., LEE, T. W. et SEJNOWSKI, T. J. (2003). Dictionary learning algorithms for sparse representations. Neural Computation, 15:592–396. 22, 120 KRONIG, R. d. L. (1926). On the theory of dispersion of x-rays. Journal of the Optical Society of America, 12(6):547–556. 34 KUC, R. (1983). Generating a minimum-phase digital filter model for the acoustic attenuation of soft tissue. In Ultrasonics Symposium, pages 794–796. 29, 35, 36 KUC, R. (1984). Modeling acoustic attenuation of soft tissue with a minimum-phase filter. Ultrasonic Imaging, 6(1):24–36. 24, 29, 35, 36 KUC, R., SCHWARTZ, M. et MICSKY, L. V. (1976). Parametric estimation of the acoustic attenuation coefficient slope for soft tissue. In Ultrasonics Symposium, pages 44–47. 29, 30 LEE, C., LAHHAM, M. et MARTIN, B. (1990). Experimental verification of the KramersKronig relationship for acoustic waves. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 37(4):286–294. 34 156BIBLIOGRAPHIE LEWICKI, M. S. et SEJNOWSKI, T. J. (2000). Learning overcomplete representations. Neural Computation, 12:337–365. 22, 120 LHEMERY, A. (1991). Impulse-response method to predict echo-responses from targets of complex geometry. Part I : Theory. The Journal of the Acoustical Society of America, 90(5):2799–2807. 27 LINGVALL, F. (2004a). The DREAM toolbox. http ://www.signal.uu.se/Toolbox/dream. 15 LINGVALL, F. (2004b). Time-domain Reconstruction methods for ultrasonic array imaging. Thèse de doctorat, Signals and systems, Uppsala University, Sweden. 143 LINGVALL, F., OLOFSSON, T. et STEPINSKI, T. (2003). Synthetic aperture imaging using sources with finite aperture : Deconvolution of the spatial impulse response. The Journal of the Acoustical Society of America, 114(1):225–234. 43, 118, 136 LU, Y., DEMIRLI, R., CARDOSO, G. et SANIIE, J. (2006). A successive parameter estimation algorithm for chirplet signal decomposition. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 53(11):2121–2131. 22, 67 LU, Y. et MICHAELS, J. (2008). Numerical implementation of matching pursuit for the analysis of complex ultrasonic signals. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 55(1):173–182. 22, 120, 135 MAHAUT, S., DARMON, M., CHATILLON, S., JENSON, F. et CALMON, P. (2009). Recent advances and current trends of ultrasonic modelling in CIVA. Insight : Non-Destructive Testing & Condition Monitoring, 51(2):78. 15, 62 MALIOUTOV, D. M., CETIN, M. et WILLSKY, A. S. (2005). Homotopy continuation for sparse signal representation. In IEEE International Conference on Acoustics, Speech, and Signal Processing, volume 5, pages 733–736, Philadelphia, USA. 76, 77, 79, 106, 107, 124 MALLAT, S. (1999). A wavelet tour of signal processing. Academic press. 120 MALLAT, S. et ZHANG, Z. (1993). Matching pursuits with time-frequency dictionaries. IEEE Transactions on Signal Processing, 41(12):3397–3415. 22, 23, 80, 81, 120 MARGRAVE, F. (1998). The theory of non-stationary linear filtering in the Fourier domain with application to time-variant filtering. Geophysics, 63(1):244–259. 43 MARIA, S. et FUCHS, J.-J. (2006). Application of the global matched filter to stap data : an efficient algorithmic approach. In IEEE International Conference on Acoustics, Speech, and Signal Processing, volume 4, Toulouse, France. 76, 106 MAXIMON, L. C. (2003). The dilogarithm function for complex argument. Proceedings of the Royal Society of London. Series A : Mathematical, Physical and Engineering Sciences, 459(2039):2807–2819. 37, 141 MCGOUGH, R. J. (2014). Fast Object-oriented C++ Ultrasound Simulator (FOCUS). http ://www.egr.msu.edu/ fultras-web. 15 157BIBLIOGRAPHIE MENDEL, J. M. (1983). Optimal Seismic Deconvolution : an Estimation Based Approach. Academic Press, New York. 23, 84 MILLER, A. J. (2002). Subset Selection in Regression, volume 2nd ed. Chapman & Hall, London, U.K. 80, 85, 149 MOR, E., AZOULAY, A. et ALADJEM, M. (2010). A matching pursuit method for approximating overlapping ultrasonic echoes. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 57(9):1996–2004. 22 MOULIN, P. et LIU, J. (1999). Analysis of multiresolution image denoising schemes using generalized gaussian and complexity priors. IEEE Transactions on Information Theory, 45(3):909–919. 23, 76, 77 NANDI, A. K. (1995). On the subsample time delay estimation of narrowband ultrasonic echoes. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 42(6): 993–1001. 22 NARAYANA, P. A. et OPHIR, J. (1983). A closed form method for the measurement of attenuation in nonlinearly dispersive media. Ultrasonic Imaging, 5:117–21. 24, 29, 30 NATARAJAN, B. (1995). Sparse approximate solutions to linear systems. SIAM Journal on Computing, 24(2):227–234. 80 NEAL, S. P., SPECKMAN, P. L. et ENRIGHT, M. A. (1993). Flaw signature estimation in ultrasonic nondestructive evaluation using the wiener filter with limited prior information. IEEE transactions on ultrasonics, ferroelectrics, and frequency control, 40(4):347–353. 23 O’BRIEN, M. S., SINCLAIR, A. N. et KRAMER, S. M. (1990). High resolution deconvolution using least-absolute-values minimization. In Ultrasonics Symposium, volume 2, pages 1151–1156. 23 O’BRIEN, M. S., SINCLAIR, A. N. et KRAMER, S. M. (1994). Recovery of a sparse spike time series by `1 norm deconvolution. IEEE Transactions on Signal Processing, 42(12): 3353–3365. 10, 23, 41, 76 O’DONNELL, M., JAYNES, E. T. et MILLER, J. G. (1978). General relationships between ultrasonic attenuation and dispersion. The Journal of the Acoustical Society of America, 63(6):1935–1937. 35, 36 OLOFSSON, T. et STEPINSKI, T. (2000). Maximum a posteriori deconvolution of ultrasonic signals using multiple transducers. The Journal of the Acoustical Society of America, 107(6):3276–3288. 41, 75, 118 OLOFSSON, T. et STEPINSKI, T. (2001). Minimum entropy deconvolution of pulse-echo signals acquired from attenuative layered media. The Journal of the Acoustical Society of America, 109(6):2831–2839. 10, 23, 43, 45, 133 OPHIR, J. et JAEGER, P. (1982). Spectral shifts of ultrasonic propagation through media with nonlinear dispersive attenuation. Ultrasonic Imaging, 4:282–289. 10, 24, 29 158BIBLIOGRAPHIE OPPENHEIM, A. et SCHAFER, R. (1989). Discrete-time signal processing. Prentice-Hall signal processing series. Prentice Hall. 35, 36, 139, 140 OPPENHEIM, A. V., SCHAFER, R. W. et STOCKHAM, T. G. (1968). Nonlinear filtering of multiplied and convolved signals. Proceedings of the IEEE, 56(8):1264–1291. 119 PAIVA, A. R. C., PARK, I. et PRÍNCIPE, J. C. (2010). A comparison of binless spike train measures. Neural Computing and Applications, 19(3):405–419. 108 PAPOULIS, A. (1962). The Fourier integral and its applications. McGraw-Hill electronic sciences series. McGraw-Hill. 34, 35, 36, 139, 140 PATI, Y., REZAIIFAR, R. et KRISHNAPRASAD, P. (1993). Orthogonal matching pursuit : recursive function approximation with applications to wavelet decomposition. In Conference Record of The Twenty-Seventh Asilomar Conference on Signals, Systems and Computers, volume 1, pages 40–44. 23, 80, 81 PINKERTON, J. M. M. (1949). The absorption of ultrasonic waves in liquids and its relation to molecular constitution. Proceedings of the Physical Society. Section B, 62(2):129. 29 QUAZI, A. (1981). An overview on the time delay estimate in active and passive systems for target localization. IEEE Transactions on Acoustics, Speech and Signal Processing, 29(3):527–533. 22, 104 RAO, B. D. et KREUTZ-DELGADO, K. (1999). An affine scaling methodology for best basis selection. IEEE Transactions on Signal Processing, 47(1):187–200. 23, 77, 80 RASMUSSEN, K. (1994). Maximum likelihood estimation of the attenuated ultrasound pulse. IEEE Transactions on Signal Processing, 42(1):220–222. 23 RAYLEIGH, J. W. S. (1945). Theory of sound, volume 2. Dover, New-York. 27 REEVES, S. J. (1999). An efficient implementation of the backward greedy algorithm for sparse signal reconstruction. IEEE Signal Processing Letters, 6(10):266–268. 85, 149 RHYNE, T. L. (1977). Radiation coupling of a disk to a plane and back or disk to a disk : an exact solution. The Journal of Acoustical Society of America, 61(2):318–324. 27, 62 RISSANEN, J. (1983). A universal prior for integers and estimation by minimum description length. The Annals of statistics, pages 416–431. 80 ROKHLIN, S. I., LEWIS, D. K., GRAFF, K. F. et ADLER, L. (1986). Real-time study of frequency dependence of attenuation and velocity of ultrasonic waves during the curing reaction of epoxy resin. The Journal of the Acoustical Society of America, 79(6):1786– 1793. 29 ROLLAND, G. (2014). Algorithmes d’optimisation pour l’estimation des paramètres d’ondes ultrasonores en contrôle non destructif. Rapport de stage de 2ème année d’école d’ingénieur ESEO. 66 SACHSE, W. et PAO, Y.-H. (1978). On the determination of phase and group velocities of dispersive waves in solids. Journal of Applied Physics, 49(8):4320–4327. 28 159BIBLIOGRAPHIE SANIIE, J. et NAGLE, D. (1989). Pattern recognition in the ultrasonic imaging of reverberant multilayered structures. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 36(1):80–92. 17, 122, 123, 126 SCHREIBER, S., FELLOUS, J. M., WHITMER, D., TIESINGA, P. et SEJNOWSKI, T. J. (2003). A new correlation-based measure of spike timing reliability. Neurocomputing, 52-54:925– 931. 108 SELÉN, Y. et LARSSON, E. G. (2006). Parameter estimation and order selection for linear regression problems. In IEEE European Signal Processing Conference, Florence, Italy. 80 SELESNICK, I. et BAYRAM, I. (2014). Sparse signal estimation by maximally sparse convex optimization. IEEE Transactions on Signal Processing, 62(5):1078–1092. 23, 105 SELFRIDGE, A. R. (1985). Approximate material properties in isotropic materials. IEEE Transactions on Sonics and Ultrasonics, 32(3):381–394. 29, 48, 51, 60, 61, 125, 129 SERABIAN, S. (1967). Influence of attenuation upon the frequency content of a stress wave packet in graphite. The Journal of the Acoustical Society of America, 42(5):1052–1059. 29 SIN, S.-K. et CHEN, C.-H. (1992). A comparison of deconvolution techniques for the ultrasonic nondestructive evaluation of materials. IEEE Transactions on Image Processing, 1(1):3–10. 22, 28 SOUSSEN, C., IDIER, J., BRIE, D. et DUAN, J. (2011). From Bernoulli Gaussian Deconvolution to Sparse Signal Restoration. IEEE Transactions on Signal Processing, 59(10):4572– 4584. 10, 23, 77, 79, 80, 81, 83, 84, 105, 124, 148, 149 SOUSSEN, C., IDIER, J., CARCREFF, E., SIMON, L. et POTEL, C. (2012). Ultrasonic non destructive testing based on sparse deconvolution. Journal of Physics : Conference Series, 353:012018 (10 pages). 22, 23, 76, 80 STEPHANISHEN, P. R. (1971). Transient radiation from pistons in an infinite baffle. The Journal of American Society of America, 49(5):1629–1638. 27, 118 STOICA, P. et SELÉN, Y. (2004). Model-order selection : a review of information criterion rules. IEEE Signal Processing Magazine, 21(4):36–47. 72, 80 SZABO, T. (1994). Time domain wave equations for lossy media obeying a frequency power law. The Journal of the Acoustical Society of America, 96:491–500. 35, 36 SZABO, T. L. (1995). Causal theories and data for acoustic attenuation obeying a frequency power law. The Journal of the Acoustical Society of America, 97:14–24. 24, 29, 35, 53 TAYLOR, H. L., BANKS, S. C. et MCCOY, J. F. (1979). Deconvolution with the `1 norm. Geophysics, 44(1):39–52. 10, 23, 76 TIBSHIRANI, R. (1994). Regression shrinkage and selection via the lasso. Journal of the Royal Statistical Society, Series B, 58:267–288. 76 160BIBLIOGRAPHIE TRIA, M., Van der BAAN, M., LARUE, A., et J., M. (2007). Wavelet estimation in homomorphic domain by spectral averaging for deconvolution of seismic data. In 5th international conference in Physics in signal and image processing, Mulhouse, France. 120 TROPP, J. et WRIGHT, S. (2010). Computational methods for sparse solution of linear inverse problems. Proceedings of the IEEE, 98(6):948–958. 23, 76 VAN ROSSUM, M. C. W. (2001). A novel spike distance. Neural Computation, 13(4):751– 763. 108 VAN TREES, H. L. (1968). Detection, estimation and modulation, part I. Wiley, New-York. 53 VICTOR, J. D. et PURPURA, K. P. (1996). Nature and precision of temporal coding in visual cortex : a metric-space analysis. Journal of neurophysiology, 76(2):1310–1326. 108 VICTOR, J. D. et PURPURA, K. P. (1997). Metric-space analysis of spike trains : theory, algorithms and application. Network : computation in neural systems, 8(2):127–164. 108 WAHBA, G. (1977). Practical approximate solutions to linear operator equations when the data are noisy. SIAM Journal on Numerical Analysis, 14(4):651–667. 80 WANG, Y. (2009). Seismic Inverse Q-filtering. ISTE Ltd and John Wiley & Sons Inc, London, U.K. 23, 30, 35 WEAR, K. (2000). The effects of frequency-dependent attenuation and dispersion on sound speed measurements : applications in human trabecular bone. IEEE Transactions on Ultrasonics, Ferroelectrics and Frequency Control, 47(1):265–273. 23, 30, 34 YARLAGADDA, R., BEDNAR, J. et WATT, T. (1985). Fast algorithms for `p deconvolution. IEEE Transactions on Acoustics, Speech and Signal Processing, 33(1):174–182. 76, 77 ZALA, C. (1992). High-resolution inversion of ultrasonic traces. IEEE Transactions on Ultrasonics, Ferroelectrics, and Frequency Control, 39(4):458–463. 10, 22, 23, 80, 122, 126 ZHANG, G.-M. et HARVEY, D. M. (2013). Contemporary ultrasonic signal processing approaches for nondestructive evaluation of multilayered structures. Nondestructive testing and evaluation, 27(1):1–27. 9, 21, 23 ZHANG, G.-M., HARVEY, D. M. et BRADEN, D. R. (2008). Signal denoising and ultrasonic flaw detection via overcomplete and sparse representations. The Journal of the Acoustical Society of America, 124(5):2963–2972. 22, 120 ZHANG, G.-M., ZHANG, C.-Z. et HARVEY, D. M. (2012). Sparse signal representation and its applications in ultrasonic NDE. Ultrasonics, 52(3):351–363. 22, 120 ZISKIND, I. et WAX, M. (1988). Maximum likelihood localization of multiple sources by alternating projection. IEEE Transactions on Acoustics, Speech and Signal Processing, 36(10):1553–1560. 22, 71 161Thèse de Doctorat Ewen CARCREFF Déconvolution adaptative pour le contrôle non destructif par ultrasons Adaptative deconvolution for ultrasonic non destructive testing Résumé Nous nous intéressons au contrôle non destructif par ultrasons des matériaux industriels. En pratique, les signaux réceptionnés par le transducteur ultrasonore sont analysés pour détecter les discontinuités de la pièce inspectée. L’analyse est néanmoins rendue difficile par l’acquisition numérique, les effets de la propagation ultrasonore et la superposition des échos lorsque les discontinuités sont proches. La déconvolution parcimonieuse est une méthode inverse qui permet d’aborder ce problème afin de localiser précisément les discontinuités. Ce procédé favorise les signaux parcimonieux, c’est à dire ne contenant qu’un faible nombre de discontinuités. Dans la littérature, la déconvolution est généralement abordée sous l’hypothèse d’un modèle invariant en fonction de la distance de propagation, modalité qui n’est pas appropriée ici car l’onde se déforme au cours de son parcours et en fonction des discontinuités rencontrées. Cette thèse développe un modèle et des méthodes associées qui visent à annuler les dégradations dues à l’instrumentation et à la propagation ultrasonore, tout en résolvant des problèmes de superposition d’échos. Le premier axe consiste à modéliser la formation du signal ultrasonore en y intégrant les phénomènes propres aux ultrasons. Cette partie permet de construire un modèle linéaire mais non invariant, prenant en compte l’atténuation et la dispersion. L’étape de modélisation est validée par des acquisitions avec des matériaux atténuants. La deuxième partie de cette thèse concerne le développement de méthodes de déconvolution efficaces pour ce problème, reposant sur la minimisation d’un critère des moindres carrés pénalisé par la pseudo-norme L0. Nous avons développé des algorithmes d’optimisation spécifiques, prenant en compte, d’une part, un modèle de trains d’impulsions sur-échantillonné par rapport aux données, et d’autre part le caractère oscillant des formes d’onde ultrasonores. En utilisant des données synthétiques et expérimentales, ces algorithmes associés à un modèle direct adapté aboutissent à de meilleurs résultats comparés aux approches classiques pour un coût de calcul maîtrisé. Ces algorithmes sont finalement appliqués à des cas concrets de contrôle non destructif où ils démontrent leur efficacité. Abstract This thesis deals with the ultrasonic non destructive testing of industrial parts. During real experiments, the signals received by the acoustic transducer are analyzed to detect the discontinuities of the part under test. This analysis can be a difficult task due to digital acquisition, propagation effects and echo overlapping if discontinuities are close. Sparse deconvolution is an inverse method that aims to estimate the precise positions of the discontinuities. The underlying hypothesis of this method is a sparse distribution of the solution, which means there are a few number of discontinuities. In the literature, deconvolution is addressed by a linear time-invariant model as a function of propagation distance, which in reality does not hold. The purpose of this thesis is therefore to develop a model and associated methods in order to cancel the effects of acquisition, propagation and echo overlapping. The first part is focused on the direct model development. In particular, we build a linear time-variant model that takes into account dispersive attenuation. This model is validated with experimental data acquired from attenuative materials. The second part of this work concerns the development of efficient sparse deconvolution algorithms, addressing the minimization of a least squares criterion penalized by a L0 pseudo-norm. Specific algorithms are developed for up-sampled deconvolution, and more robust exploration strategies are built for data containing oscillating waveforms. By using synthetic and experimental data, we show that the developed methods lead to better results compared to standard approaches for a competitive computation time. The proposed methods are then applied to real non destructive testing problems where they confirm their efficiency. Mots clés Contrôle non destructif, ultrasons, modélisation acoustique, atténuation dispersive, problème inverse, déconvolution, parcimonie. Key Words Non destructive testing, ultrasound, acoustic modeling, dispersive attenuation, inverse problem, deconvolution, sparsity. L’UNIVERSITÉ NANTES ANGERS LE MANS Adaptation des services sensibles au contexte selon une approche intentionnelle Najar Salma To cite this version: Najar Salma. Adaptation des services sensibles au contexte selon une approche intentionnelle. Ubiquitous Computing. Universit´e Panth´eon-Sorbonne - Paris I, 2014. French. HAL Id: tel-00989775 https://tel.archives-ouvertes.fr/tel-00989775 Submitted on 12 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.THESE DE DOCTORAT DE L’UNIVERSITE DE PARIS I – PANTHEON-SORBONNE Spécialité : Informatique Salma Najar Pour l’obtention du titre de : DOCTEUR DE L’UNIVERSITE PARIS I – PANTHEON-SORBONNE Adaptation des services sensibles au contexte selon une approche intentionnelle Soutenu le 11 Avril 2014 devant le jury composé de : Mme Carine SOUVEYET Directeur de Thèse Mme Manuele KIRSCH-PINHEIRO Co-Directeur de Thèse Mme Isabelle MIRBEL Rapporteur Mr Jérôme GENSEL Rapporteur Mme Corine CAUVET Membre de Jury Mme Bénédicte LE-GRAND Membre de Jury« Chercher n'est pas une chose et trouver une autre, mais le gain de la recherche, c'est la recherche même. » de Saint Grégoire de Nysse A mes parents, mon amour sans faille, A Sana et Omar, ma sœur et mon frère adorés, A Aymen, mon amour et ma source d’inspiration v Remerciements La thèse est une aventure extraordinaire qui nous pousse au bout de nous-mêmes et qui nous construit... C’est une belle expérience, difficile par moment et agréable par d’autres… Je me suis sentie complètement transformée et grandie par cette expérience… J’ai vécu mon doctorat comme une véritable aventure, un enrichissement personnel et professionnel considérable…C’est l’aboutissement d’une étape importante dans ma vie et le commencement d’une autre que j’espère aussi attractive… Un énorme Merci à toutes les personnes qui ont contribué pour que cette expérience soit si exceptionnelle. Je tiens à remercier en premier lieu, Carine Souveyet, Professeur à l’Université Paris 1 Panthéon - Sorbonne pour m’avoir accordée sa confiance en acceptant de diriger mes recherches. Je la remercie infiniment de m’avoir fait bénéficier tout au long de ce travail de sa grande compétence, de sa rigueur intellectuelle et de ses précieux conseils. Sa revendication constante du travail sérieux m’a aidée à progresser. Que le fruit de ces longues années de travail soit à la hauteur de ce qu’elle a semé en moi. J’exprime également toute ma gratitude à Manuele Kirsch-Pinheiro, Maître de Conférence à l’Université de Paris 1 Panthéon - Sorbonne qui m’a épaulée tout au long de la réalisation de ce travail de recherche et prodiguée de précieux conseils qui m’ont permis d’aller constamment de l’avant. Elle m’a encouragée par ses orientations sans cesser d’être une grande source de motivation et de persévérance. Son exigence m’a permise de progresser dans l’élaboration de ma recherche. Qu’elle trouve dans ce travail l’expression de ma profonde et sincère reconnaissance. Je souhaiterais adresser mes remerciements les plus sincères à Isabelle Mirbel, Maître de Conférence Habilitée à Diriger des Recherches à l’Université de Nice Sophia Antipolis, et Jérôme Gensel, Professeur à l’Université de Pierre Mendès France - Grenoble 2, pour m’avoir fait l’honneur d’être les rapporteurs de ce travail. Je les remercie pour leur application et leurs précieux commentaires et recommandations. Je voulais également remercier les examinateurs de ce travail, Madame Corine Cauvet, Professeur à l’Université d’Aix-Marseille et Madame Bénédicte Le Grand, Professeur à l’Université de Paris 1 Panthéon – Sorbonne pour avoir accepté de faire partie de mon jury de thèse et d’évaluer mon travail. Je remercie profondément Bénédicte qui a eu la gentillesse de me consacrer du temps pour échanger avec moi autour de mon sujet de thèse. Ses remarques et ses conseils m’ont été d’une aide précieuse. J’ai pu travailler dans un cadre particulièrement agréable, grâce à l’ensemble des membres de l’équipe du Centre de Recherche en informatique (CRI). J’exprime toute ma gratitude envers tous ceux qui m’ont aidée et encouragée tout au long de mon séjour au sein de l’équipe et surtout l’ensemble des thésards pour leur enthousiasme et leur soutien vi quotidien. Merci à tous pour votre bonne humeur, pour toutes ces séances de rires et de sourires, et pour toutes ces discussions autour d’un café. Cet aboutissement n’aurait jamais pu se faire sans l’encouragement, le soutien et l’amour de tous les membres de ma famille et de mes amis. A mes chers parents, à ma sœur Sana et à mon frère Omar : Merci d’avoir cru en moi… Merci pour votre patience et pour l’affection que vous m’avez manifestée durant ces années… A ma belle famille : Merci du fond du cœur pour votre soutien et pour vos précieux conseils… A mes amis : Merci d’être là et de m’avoir toujours soutenue et m’avoir changée les idées quand j’en avais besoin … Une dédicace toute particulière à Sonda et Fatma, deux amies très spéciales qui m’ont soutenue dès le début et m’ont aidée dans les périodes de doute. Je garde pour la fin un remerciement particulier pour mon mari, Aymen. Je te remercie infiniment de m’avoir aidée, soutenue, encouragée et surtout aimée... Ces dernières années n’ont pas été si simples, tu m’as supportée dans les périodes les plus difficiles… Tu m’as aidée à garder le moral haut et surtout à surmonter les difficultés. Merci d’avoir été toujours là… 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. vii Résumé L’émergence des nouvelles technologies a fait évoluer l’usage de ces technologies dans la perspective d’accéder aux différents systèmes qui prennent place dans notre vie quotidienne à n'importe quel endroit et à tout moment. En effet, la démocratisation des dispositifs et l’évolution des technologies mobiles ont bouleversé la manière dont on utilise ces systèmes dans un environnement pervasif. Dans le cadre de l’entreprise, ces nouvelles technologies ont élargi les frontières des Systèmes d'Information (SI) bien au-delà des frontières physiques de l’organisation. Les directeurs des Systèmes d’Information (DSI) sont ainsi confrontés à de nouveaux modes d’interaction entre le SI et son environnement. Les Systèmes d’Information sont ainsi confrontés à un environnement pour lequel ils n’ont pas été particulièrement conçus. Ces systèmes doivent maintenant faire face à un environnement pervasif, et à l'avenir, intégrer des éléments physiques ainsi que logiques et organisationnels. Nous assistons donc aujourd’hui à l’émergence d’une nouvelle génération de Systèmes d’Information : les « Systèmes d’Information Pervasifs » (SIP). Les Systèmes d’Information Pervasifs se veulent alors une réponse à cette importante évolution des SI. Par contre, ils se doivent de gérer l’hétérogénéité et le dynamisme de l’environnement de manière transparente afin de satisfaire au mieux les besoins des utilisateurs. Nous ainsi sommes face à un problème de conception et de réalisation d’un SIP répondant à tous les besoins de transparence, d’adaptation à l’environnement et d’adaptation à l’utilisateur d’un SIP. Or les SIP constituent aujourd’hui une nouvelle génération des SI qui est difficile à conceptualiser, avec peu de méthodes et de modèles disponibles. Ainsi, il devient essentiel de mettre en place un cadre plus formel permettant d’aider les concepteurs à mieux comprendre les SIP et surtout à mieux les maîtriser, tout en assurant la transparence nécessaire à ces systèmes. Dans ce travail de thèse, nous proposons une nouvelle vision intentionnelle et contextuelle des SIP. Cette nouvelle vision représente une vision centrée utilisateur d’un SIP transparent, non intrusif et compréhensible à l’utilisateur. Elle se base sur l’orientation service, la sensibilité au contexte et sur une approche intentionnelle afin de résoudre les problèmes de transparence, d’adaptation à l’environnement et d’adaptation aux utilisateurs. Par la suite, nous proposons une solution plus globale pour concrétiser cette vision intentionnelle et contextuelle des SIP. Nous proposons un cadre conceptuel des SIP décrivant et formalisant l’ensemble de ses éléments afin d’aider la DSI dans sa conception du système. Nous proposons ensuite des mécanismes de découverte et de prédiction de services qui sont intégrés dans une architecture de gestionnaire de SIP qui est conforme à ce cadre conceptuel. Finalement, nous proposons une démarche méthodologique de conception et de réalisation d’un SIP qui supporte le passage entre le cadre conceptuel et l’implémentation de l’architecture proposée. viii Abstract The emergence of new technologies has changed the use of these technologies in order to access to the various systems that take place in our daily life anywhere and anytime. Indeed, the democratization of devices and the evolution of mobile technologies have changed the way these systems are used in a pervasive environment. As part of the company, these new technologies have expanded the boundaries of Information Systems (IS) beyond the physical boundaries of the organization. Chiefs Information Officers (CIOs) are confronted with new modes of interaction with their SI. Information Systems are thus faced with an environment for which they were not specifically designed. These systems must now face a pervasive environment, and in the future, integrate physical as well as logical and organizational elements. We are now witnessing the emergence of a new generation of Information Systems: « Pervasive Information Systems« (PIS). The Pervasive Information Systems want an answer to this important evolution of SI. Against, they must manage the heterogeneity and dynamism of the environment in a transparent manner to best meet the users needs. Thus, currently we are facing a problem of design and implementation of PIS that meets all the needs of transparency, adaptation to the environment and adaptation to the user. Although, PIS represent today a new generation of SI that is difficult to conceptualize, with few methods and models available. Thus, it becomes essential to establish a more formal framework to help designers better understand PIS and especially to the better control of it, while ensuring the necessary transparency to these systems. In this thesis, we propose a new intentional and contextual vision of PIS. This new vision represents a user centric vision of PIS, which is transparent, non-intrusive and understandable to the user. It is based on service orientation, context-awareness and intentional approach to solve the problems of transparency, adaptation to the environment and adaptation to users. Subsequently, we propose a more comprehensive solution to achieve this intentional and contextual vision of PIS. We propose a conceptual framework for describing and formalizing PIS and all its elements to help CIOs in their system design. We then propose mechanisms for services discovery and prediction that are integrated in the architecture of PIS manager. Finally, we propose a methodological approach for the design and the implementation of PIS that supports the transition between the conceptual framework to its implementation with the proposed architecture. ix Table des matières Remerciements..............................................................................................................!v Résumé.........................................................................................................................vii Abstract.......................................................................................................................viii Table1des1matières........................................................................................................ ix Chapitre!1. Introduction!Générale ..............................................................................!1 1.1. Contexte!de!Recherche :!La!vision!d’un!Système!d’Information!Pervasif................................!1 1.1.1. Informatique-Pervasive..............................................................................................................................-1 1.1.2. Impact-de-l’Informatique-Pervasive-sur-les-Systèmes-d’Information-(SI)............................-2 1.1.3. Les-Systèmes-d’Information-Pervasifs-(SIP)......................................................................................-3 1.2. Problématique ...................................................................................................................................................!4 1.3. Hypothèses ..........................................................................................................................................................!8 1.4. Aperçu!de!la!proposition............................................................................................................................10 1.5. Organisation!de!la!thèse .............................................................................................................................11 Chapitre!2. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte ..................... 13 2.1. Introduction.....................................................................................................................................................13 2.2. L’Informatique!Pervasive et!les!Systèmes!Sensibles!au!Contexte............................................13 2.2.1. Définition-et-historique-du-domaine-de-l’Informatique-Pervasive ........................................14 2.2.2. Systèmes-Sensibles-au-Contexte............................................................................................................15 2.3. Le!contexte .......................................................................................................................................................17 2.3.1. La-notion-de-contexte :-définitions,-caractéristiques-et-dimensions.....................................17 2.3.2. Modélisation-de-contexte ........................................................................................................................23 2.3.3. Gestion-de-contexte....................................................................................................................................32 2.3.4. Cadre-d’analyse-et-de-comparaison-des-modèles-existants......................................................35 2.4. Les!Systèmes!d’Information!Pervasifs!et!caractéristiques ..........................................................41 2.5. Conclusion ........................................................................................................................................................44 Chapitre!3. Systèmes d’Information!Pervasifs!et!l’orientation!service ....................... 46 3.1. Introduction.....................................................................................................................................................46 3.2. La!notion!de!service......................................................................................................................................47 3.3. L’architecture!Orientée!Services :!SOA.................................................................................................!48 3.4. L’orientation!service!sous!ses!différentes!formes...........................................................................50 3.4.1. Services-Web :-vers-une-vision-technologique ................................................................................51 3.4.2. Services-Sémantiques :-vers-une-vision-sémantique ....................................................................53 3.4.3. Services-Intentionnels :-vers-une-vision-intentionnelle...............................................................58 3.5. Les!challenges!pour!les!systèmes!d’Information!Pervasifs!Orientés!Services....................64 3.5.1. Les-challenges..............................................................................................................................................64 3.5.2. La-découverte-de-services .......................................................................................................................65 3.5.3. La-prédiction-de-services.........................................................................................................................81 3.6. Conclusion!et!considérations!finales.....................................................................................................87 Chapitre!4. Vision intentionnelle!et!contextuelle!des!systèmes!d’information!pervasifs 90 4.1. Introduction.....................................................................................................................................................90 4.2. Rappel!du!contexte!de!recherche!et!de!la!problématique ...........................................................90 4.2.1. Contexte-de-recherche ..............................................................................................................................90 4.2.2. Problématique .............................................................................................................................................91x 4.3. Aperçu!de!la!solution ...................................................................................................................................92 4.3.1. Notre-vision-intentionnelle-et-contextuelle-des-SIP :-couplage-entre-services,-contexteet intention...........................................................................................................................................................................93 4.3.2. Solution-globale :-de-la-conception-à-la-mise-en-œuvre-d’un-SIP-transparent-et-centré- utilisateurV-............................................................................................................................................................................94 4.3.3. Contributions-attendues..........................................................................................................................99 4.4. Conclusion ..................................................................................................................................................... 100 Chapitre!5. Cadre!conceptuel!d’un!SIP :!Espace!de!Services..................................... 101 5.1. Introduction.................................................................................................................................................. 101 5.2. Formalisation!de!la!notion!de!service!dans!un!SIP ...................................................................... 103 5.2.1. Les-fonctionnalités-du-service ............................................................................................................104 5.2.2. Les-intentions-du-service ......................................................................................................................105 5.2.3. Le-contexte-du-service............................................................................................................................107 5.3. Formalisation!de!la!notion!de!contexte............................................................................................. 110 5.3.1. Modélisation-de-contexte .....................................................................................................................111 5.3.2. Formalisation-de-la-notion-d’observation-et-de-capteur ........................................................116 5.4. Formalisation!de!l’espace!de!services ............................................................................................... 118 5.4.1. Entités-actives-...........................................................................................................................................120 5.4.2. Entités-passives.........................................................................................................................................120 5.4.3. Etat-de-l’espace-de-services-et-son-évolution ...............................................................................121 5.5. Conclusion ..................................................................................................................................................... 123 Chapitre!6. Description!intentionnelle!et!contextuelle!des!services......................... 124 6.1. Introduction.................................................................................................................................................. 124 6.2. Vers!un!descripteur!intentionnel!et!contextuel :!OWLTSIC ...................................................... 125 6.3. La!dimension!intentionnelle!d’un!service........................................................................................ 127 6.3.1. Le-service-et-son-intention-principale.............................................................................................128 6.3.2. La-composition-intentionnelle ...........................................................................................................134 6.4. La!dimension!Contextuelle!d’un!service!........................................................................................... 139 6.4.1. Le-modèle-de-contexte ...........................................................................................................................141 6.4.2. Le-contexte-d’exécution-d’un-service-(Cx)-.....................................................................................145 6.4.3. Le-contexte-requis-par-un-service-(CxR)-.........................................................................................146 6.5. Conclusion ..................................................................................................................................................... 147 Chapitre!7. Découverte!de!services!guidée!par!l’intention!et!le!contexte ................ 148 7.1. Introduction.................................................................................................................................................. 148 7.2. Processus!de!découverte!de!services!guidé!par!l’intention!et!le!contexte......................... 149 7.2.1. Principe........................................................................................................................................................149 7.2.2. Algorithme-de-découverte-de-services-guidée-par-le-contexte-et-l’intention .................150 7.3. Implémentation!et!évaluation............................................................................................................... 170 7.3.1. Les-Technologies-utilisées....................................................................................................................170 7.3.2. Implémentation-du-processus-de-découverte-de-services ......................................................171 7.3.3. Evaluation-du-processus-de-découverte-de-services.................................................................-174 7.3.4. Le-passage-à-l’échelle-(Performance-sur-plusieurs-configurations)..................................177 7.4. Conclusion ..................................................................................................................................................... 184 Chapitre!8. Prédiction!de!services!guidée!par!l’intention et!le!contexte .................. 185 8.1. Introduction.................................................................................................................................................. 185 8.2. Processus!de!prédiction!de!services!guidée!par!le!contexte!et!l’intention........................ 186xi 8.2.1. La#gestion#des#traces#(historiques)..................................................................................................188 8.2.2. Le#processus#d’apprentissage.............................................................................................................190 8.2.3. Le#processus#de#prédiction...................................................................................................................201 8.3. Implémentation!et!Evaluation .............................................................................................................. 206 8.3.1. Implémentation........................................................................................................................................206 8.3.2. Evaluation ..................................................................................................................................................212 8.4. Conclusion ..................................................................................................................................................... 220 Chapitre)9. Architecture)de)gestionnaire)de)SIP)...................................................... 221 9.1. Introduction.................................................................................................................................................. 221 9.2. Les!prérequis!de!l’architecture!de!gestionnaire!de!SIP.............................................................. 221 9.3. L’architecture!de!gestionnaire!de!SIP................................................................................................ 222 9.3.1. Module#de#gestion#de#requête#(1).....................................................................................................224 9.3.2. Module#de#gestion#de#contexte#(2)...................................................................................................225 9.3.3. Répertoire#de#services#sémantiques................................................................................................227 9.3.4. Module#de#découverte#de#services....................................................................................................229 9.3.5. Module#d’apprentissage........................................................................................................................231 9.3.6. Module#de#prédiction#de#services......................................................................................................232 9.4. Conclusion ..................................................................................................................................................... 234 Chapitre)10. Démarche)methodologique)de)conception)d’un)SIP ............................ 235 10.1. Introduction ............................................................................................................................................... 235 10.2. Présentation!de!la!démarche!méthodologique ........................................................................... 235 10.3. Les!étapes!du!processus!de!conception!D’un!SIP....................................................................... 239 10.3.1. Etape#1 :#Spécification#des#espaces#de#services........................................................................239 10.3.2. Etape#2 :#Identification#des#fonctionnalités#pertinentes......................................................239 10.3.3. Etape#3 :#Identification#du#couple#intention#et#contexte......................................................241 10.3.4. Etape#4 :#Description Sémantique#des#Services#selon#le#contexte#et#l’intention ........245 10.4. Cas!d’étude!sécurité!et!accès!au!SI!pour!des!employés!mobiles.......................................... 248 10.4.1. Introduction#du#cas#d’étude..............................................................................................................248 10.4.2. Conception#de#l’espace#de#services................................................................................................249 10.4.3. Description#du#cas#d’étude................................................................................................................258 10.5. Conclusion................................................................................................................................................... 262 Chapitre)11. Conclusions)et)Perspectives................................................................ 263 11.1. Conclusions................................................................................................................................................. 263 11.1.1. Rappel#de#la#problématique .............................................................................................................263 11.1.2. Bilan#du#travail#réalisé .......................................................................................................................265 11.2. Perspectives ............................................................................................................................................... 267 Bibliographie ............................................................................................................. 270 Annexes).................................................................................................................... 288Introduction)Générale 1 Chapitre 1. INTRODUCTION GENERALE Le travail réalisé dans le cadre de cette thèse se situe dans le domaine de l’Ingénierie des Services, de l’Informatique Ubiquitaire (ou Pervasive) et de l’ingénierie des Systèmes d’Information. Il présente une approche centrée utilisateur permettant de concevoir et de construire la nouvelle génération des Systèmes d’Information, qu’on appelle Systèmes d’Information Pervasifs. 1.1. CONTEXTE DE RECHERCHE : LA VISION D’UN SYSTEME D’INFORMATION PERVASIF 1.1.1. Informatique Pervasive Depuis plusieurs années, nous assistons à l’émergence des nouvelles technologies. Nous sommes témoins de l’évolution de l’usage de ces technologies afin d’accéder aux différents systèmes qui prennent place dans notre quotidien. En effet, la démocratisation des dispositifs utilisés dans notre vie quotidienne (Smartphones, tablettes, etc.), ainsi que l’évolution des technologies mobiles (3G, géolocalisation, Bluetooth, etc.) et des autres technologies ont bouleversé la manière dont on utilise ces systèmes. Selon Musolesi (Musolesi, 2011), les Smartphones, par exemple, sont considérés comme la plateforme informatique de l'avenir, où l’informatique peut être fortement décentralisée et répartie sur les différents terminaux utilisés par les utilisateurs pour fournir des solutions hautement évolutives. Ces avancées technologiques, qui nous donnent le pouvoir d'interagir avec le monde d’une manière naturelle, ont contribué à l'amélioration de nos capacités quotidiennes, fournissant, ainsi, des avantages à long-terme pour la société dans son ensemble (Cheng, 2010). Grâce à ces avancées, l’informatique s’est intégrée à l’environnement d’une façon invisible. Schmidt (Schmidt, 2010) illustre ceci par l’usage du GPS dans différentes situations et d’une manière presque inconsciente. Plus précisément, il utilise trois récepteurs GPS différents : le premier dans son téléphone, fournissant aux réseaux sociaux sa localisation, le second intégré dans le système de navigation de la voiture et le dernier dans l’appareil photo, afin de géo-localiser les photos prises. Cet auteur démontre à travers son exemple, que cette technologie est devenue invisible, comme d’autres technologies intégrées à notre environnement. Cette réalité a été soutenue depuis plusieurs années par l’Informatique Ubiquitaire (ou Pervasive) (Weiser, 1991). Weiser (Weiser, 1991) soutient que « les technologies les plus profondément enracinées sont les technologies invisibles. Elles s’intègrent dans la trame de la vie quotidienne jusqu’à ne plus pouvoir en être distinguées ».Introduction!Générale 2 A l’instar de Bell et Dourish (Bell et Dourish, 2007), nous pensons que l’Informatique Ubiquitaire est déjà une réalité et non pas un avenir proche. Elle fait partie intégrante de notre quotidien, notamment à travers les nouvelles technologies. Celles-ci sont devenues presque invisibles à nos yeux, à tel point qu’il nous est désormais impossible d’imaginer notre vie personnelle et professionnelle sans elles. Selon ces auteurs, l'Informatique Ubiquitaire a pris une forme différente de celle attendue par Weiser, dans laquelle les dispositifs mobiles représentent l'élément central de notre vie quotidienne. Ces auteurs soutiennent que nous sommes continuellement en train d’utiliser des ressources informatiques dans notre vie courante sans forcément les percevoir en tant qu’ordinateurs. L’informatique Ubiquitaire est ainsi une réalité sous la forme d’un environnement densément peuplé de ressources informatiques et de communication. 1.1.2. Impact de l’Informatique Pervasive sur les Systèmes d’Information (SI) La dernière décennie a été remarquablement marquée par le changement dans la manière dont nous travaillons et dans la manière dont nous nous appuyons sur les technologies. Nous passons d’un modèle statique, dans lequel les travailleurs n’interagissent avec un processus métier que durant leur « temps de travail » et dans des circonstances bien définies (e.g. assignés à leur ordinateur de bureau), à un modèle dynamique, dans lequel ils se caractérisent par leur mobilité, permise par l’évolution des réseaux sans fil et des dispositifs mobiles. Ainsi, les SI sont confrontés à un environnement pour lequel ils n’ont pas été prévus. En effet, l’arrivée de l’Informatique Ubiquitaire, au sein des organisations, a directement impacté les Systèmes d’Information (SI). La mobilité qu’apportent ces nouvelles technologies a étendu les SI bien au-delà des frontières physiques de l’organisation. Ceci revient à dire que l’évolution de ces technologies mobiles et pervasives a ouvert de nouvelles perspectives et a changé le mode d’accès à ces systèmes. Nous assistons au passage graduel d’un paradigme entièrement fondé sur les desktops à un paradigme mixte, intégrant des dispositifs multiples et très hétérogènes : desktops, dispositifs mobiles et ressources intégrées à l’environnement physique (Kourouthanassis et Giaglis, 2006). Depuis leur apparition, les Systèmes d’Information n’ont cessé d’évoluer et de progresser dans la perspective d’améliorer la productivité et l’efficacité au sein de l’organisation, comme l’illustre la Figure 1. Au début, un Système d’Information (SI) a été conçu comme une combinaison de pratiques de travail, d’information, d’individus, et de technologies de l’information en vue d’atteindre certains objectifs (Alter, 1992). Par la suite, un SI a été défini comme un ensemble organisé de ressources (individus, matériel, logiciel, progiciel, bases de données, procédures) qui permettent d’acquérir, de traiter, de stocker, et de communiquer l’information sous différentes formes au sein d’une organisation (Reix, 2004). Récemment, Nurcan (Nurcan, 2012) a synthétisé toutes ces définitions en présentant les Systèmes d’Information comme étant le cœur stratégique de l’entreprise, rassemblant un ensemble organisé de ressources technologiques et humaines visant à (i) aider la réalisation des Introduction!Générale 3 activités de l'organisation, et (ii) faciliter/servir l’accomplissement des objectifs métier fixés pour et par cette organisation. Figure 1. L'émergence des Systèmes d'Information Pervasifs Les Systèmes d’Information sont devenus un élément clé des organisations. Selon Henderson et Venkatrama (Henderson et Venkatraman, 1993), « posséder un système d'information efficace et efficient supportant les stratégies métiers et les processus qui y sont rattachés est rapidement devenu un facteur clé de succès ». Ainsi, le rôle des SI est devenu plus stratégique au sein des organisations : ils contribuent à la mise en place des différents processus métiers propres à ces organisations, dont le succès ou l’échec peut avoir d’importantes conséquences pour leur survie. Avec le développement des nouvelles technologies, les directeurs des Systèmes d’Information (DSI) sont confrontés à de nouveaux modes d’interaction avec leur SI. L’évolution des SI devient ainsi inévitable. Ces systèmes doivent s’adapter aux nouvelles technologies et aux nouveaux modes d’accès mis à disposition de leurs utilisateurs. Or, cette évolution ne doit pas être subie, mais choisie. Nous assistons donc aujourd’hui à l’émergence d’une nouvelle génération de Systèmes d’Information : les « Systèmes d’Information Pervasifs » (SIP). Nous assistons aujourd’hui au passage progressif des technologies de l’information (IT) à l’arrière-plan. En d’autres termes, les Systèmes d’Information sont là aujourd’hui pour surveiller les activités des utilisateurs, pour assembler et traiter les informations et pour intervenir lorsque cela est nécessaire (au lieu d’être uniquement déclenchés et manipulés directement par l’utilisateur) (Kourouthanassis et Giaglis, 2006) . 1.1.3.Les Systèmes d’Information Pervasifs (SIP) La notion de Système d’Information Pervasif est au cœur de l’évolution mentionnée cidessus. Cette nouvelle classe de SI représente l’avenir de ces systèmes. Elle apporte de Introduction!Générale 4 nouvelles opportunités, notamment par la prise en compte de l’environnement et la possibilité d’offrir des services innovants. A l’inverse des SI traditionnels, les Systèmes d’Information Pervasifs s’intègrent progressivement à l’environnement physique (Kourouthanassis et Giaglis, 2006). Cette nouvelle classe de SI se distingue des SI traditionnels par l’environnement pervasif dans lequel ils émergent. Contrairement aux SI traditionnels, intégrés notamment à un environnement desktop classique qui limite le mode d’interaction de l’utilisateur (modes d’accès stationnaires), les SIP s’ouvrent à d’autres dispositifs plus évolués, offrant à l’utilisateur des espaces plus étendus d’interaction avec le SI : des dispositifs mobiles transportables par l’utilisateur, dispositifs directement intégrés à l’environnement autour. Ainsi, comme le mentionnent Kourouthanassis et al. (Kourouthanassis et al., 2007), en dehors des interactions physiques uniquement avec le système, un SIP peut également intégrer des éléments d'interactions mobiles avec des dispositifs ou des objets de l'environnement physique d'une manière naturelle et discrète. Par conséquent, à l’opposé des SI traditionnels, complétement maîtrisés et bornés, les futurs SIP visent à s’intégrer à un environnement dynamique et hétérogène. D’une part, selon (Kourouthanassis et Giaglis, 2006), ces SIP s’inscrivent dans un environnement particulièrement dynamique, composé d’une multitude d’artefacts capables de percevoir le contexte de l’utilisateur et de gérer sa mobilité. D’autre part, ces SIP offre, par cette intégration à un environnement hétérogène, une interaction continue avec le SI là où on est et quand on le souhaite. Toujours selon (Kourouthanassis et Giaglis, 2006), contrairement aux SI traditionnels, dont l’intelligence réside dans l’ordinateur desktop, les SIP doivent faire résider cette intelligence au-delà de l’ordinateur en l’intégrant dans le monde physique. De plus, les SIP doivent être proactifs, réagissant aux stimuli de l’environnement, à l’encontre des SI traditionnels, dans lesquels une réponse du système est forcément précédée d’une action de l’utilisateur. Cette nouvelle génération des SI, avec les nouvelles opportunités qu’elle apporte, représente l’avenir de ces systèmes. Mais il est à noter que cette nouvelle génération apporte également son lot de défis : hétérogénéité, dynamisme, accès ubiquitaire aux SI, etc. À ce jour, les DSI sont livrés à eux-mêmes. Ils ne disposent d’aucun moyen leur permettant de concevoir, de construire et de mieux comprendre cette nouvelle classe de SI. 1.2. PROBLEMATIQUE A travers ces nouvelles technologies, de nouvelles opportunités de services peuvent s’offrir aux utilisateurs. Selon (Kourouthanassis et Giaglis, 2006), les SIP se caractériseraient non seulement par l’hétérogénéité des dispositifs impliqués, mais également par l’interaction continue rendue possible par ces dispositifs, mobiles ou intégrés à l’environnement physique, ce qui ouvre la possibilité d’offrir aux utilisateurs de nouveaux services innovants. Introduction!Générale 5 Toutefois, afin de concevoir de tels SI évoluant dans un environnement pervasif, il est nécessaire de bien comprendre les caractéristiques et les exigences auxquelles ces nouveaux systèmes seraient soumis. Bien évidemment, les caractéristiques principales des SIP sont l’hétérogénéité des ressources, des infrastructures, des terminaux. Cette hétérogénéité vient justement de l’environnement pervasif dans lequel ces systèmes sont intégrés. Cette hétérogénéité se retrouve également au niveau des services offerts par le SI, avec de multiples technologies possibles (services Web traditionnels, composants OSGI, pour ne citer qu’eux). Les utilisateurs s’orientent ainsi vers un monde de plus en plus hétérogène avec des données et des services répartis à différents niveaux. Il est illusoire d’imaginer que cette hétérogénéité disparaîtra avec le temps. Ces environnements resteront toujours complexes et extrêmement denses d’un point de vue technologique. Les SIP doivent gérer cette hétérogénéité et veiller à la bonne interaction entre l'utilisateur et l'environnement physique (Kourouthanassis et Giaglis, 2006). Se pose alors la question : comment l’utilisateur peut-il faire face à cette hétérogénéité et se concentrer sur son propre objectif et non sur la technologie elle-même ? Effectivement, il faut masquer cette hétérogénéité et cacher la complexité de l’environnement. L’élément clé devient ainsi la gestion de la transparence. Or il nous paraît impossible d’homogénéiser toutes les technologies existantes, même dans un cadre plus contrôlé comme celui des SI. Par ailleurs, les offres de services risquent d’augmenter significativement. Selon Savidis (Savidis, 2010), dans un environnement pervasif, nous sommes confrontés à une évolution rapide du spectre et du nombre de services disponibles pour tout type d’utilisateur, à n'importe quel endroit et à tout moment. Dans la vie quotidienne, le temps moyen passé dans l’utilisation de ces services varie d’une dizaine de secondes à quelques minutes, alors qu'ils sont impliqués dans un nombre croissant d’activités quotidiennes, hebdomadaires ou mensuelles (Savidis, 2010). En effet, il y a une claire tendance à développer et à offrir de plus en plus de services et notamment de services personnalisés, comme le mentionne Wolisz (Wolisz, 2010). Les Systèmes d’Information sont ainsi confrontés à un environnement pour lequel ils n’ont pas été particulièrement conçus (hétérogénéité, offre de services grandissante, etc.). Les Systèmes d’Information Pervasifs se veulent alors une réponse à cette importante évolution des SI. Par contre, ils se doivent de gérer l’hétérogénéité de l’environnement et l’offre de services de manière transparente afin de rassurer les utilisateurs. Or les concepteurs des SIP se trouvent, aujourd’hui, démunis face à une notion relativement nouvelle. Effectivement, les SIP constituent une nouvelle génération des SI qui est difficile à conceptualiser, avec peu de formalismes disponibles. Autant dire qu’ils n’ont rien à leur disposition pour les aider à concevoir de tels systèmes. Partant de ce fait, il est nécessaire de mettre en place un cadre plus formel permettant d’aider les concepteurs à mieux comprendre les SIP et surtout à mieux les maîtriser, tout en assurant la transparence nécessaire à ces systèmes. Par ailleurs, force est de constater que l’environnement pervasif est un environnement hautement dynamique qui varie en fonction de l’utilisateur (ses actions, sa mobilités, etc.) et Introduction!Générale 6 de ses éléments. Ceci ajoute aux SIP une autre caractéristique, au-delà de l’hétérogénéité : le dynamisme. Selon (Hagras, 2011), la nature dynamique des environnements pervasifs impose une capacité d’adaptation à des conditions d’opération changeantes et à des utilisateurs dont les préférences et le comportement sont également variables. Un système pervasif doit être capable d’accomplir les fonctionnalités sollicitées, malgré les changements dans les conditions environnantes ou dans l’état du système (Römer et Friedemann, 2010). En d’autres termes, les SIP doivent s’adapter aux changements de l’environnement afin de gérer son dynamisme. Ainsi, afin d’assurer la transparence nécessaire, les SIP doivent être sensibles au contexte, permettant la prise en compte de l’environnement pervasif. Selon Baldauf et al. (Baldauf et al., 2007), les systèmes sensibles au contexte se caractérisent par leur capacité à adapter leur fonctionnement, par la prise en compte du contexte environnant, afin d’augmenter leur utilisabilité et leur efficacité. Dans ce cadre, la notion de contexte représente « l’ensemble des caractéristiques de l'environnement physique ou virtuel qui affecte le comportement d'une application et dont la représentation et l’acquisition sont essentielles à l’adaptation des informations et des services » (Gensel et al., 2008). Pour (Kourouthanassis et al., 2008), la sensibilité au contexte représente la capacité d’un système à percevoir les informations contextuelles relatives à l’utilisateur, au système lui-même et à l’environnement afin de pouvoir adapter ses fonctionnalités de manière dynamique et proactive, réagissant aux stimuli de l’environnement. Cependant, cette sensibilité au contexte ne doit pas se faire au dépend de la transparence. Selon Dey (Dey, 2011), lorsque les utilisateurs ont des difficultés à former un modèle mental de l’application, ils ont moins envie de l’adopter et de l’utiliser. En plus de leurs capacités d’adaptation au contexte et d’un comportement proactif, les SIP doivent rester compréhensibles à leurs utilisateurs, d’autant plus qu’il s’agit, avant tout, de Systèmes d’Information. Les SI sont là pour répondre aux besoins des utilisateurs. Il est primordial de rassurer les utilisateurs afin qu’ils gardent leur confiance sur ces systèmes. De ce fait, il faut avoir une vision globale du fonctionnement des SI afin d’assurer un tel niveau de compréhension. Ainsi, il est nécessaire de représenter ce fonctionnement global du système à travers une modélisation de haut niveau. Selon (Hagras, 2011), ces modèles doivent être euxmêmes transparents et d’interprétation facile aux utilisateurs afin que ceux-ci puissent mieux analyser le système et ses performances. Partant de ces faits, les SIP se doivent d’être sensibles au contexte et compréhensibles à leurs utilisateurs afin d’assurer la transparence nécessaire et de gérer l’hétérogénéité, sans pour autant perdre complétement le caractère maîtrisé et prédictible propre aux SI. En tant que Systèmes d’Information, les SIP doivent être conçus afin de mieux satisfaire les besoins de leurs utilisateurs en prenant en considération leur environnement pervasif. De plus, au contraire des SI traditionnels, les SIP doivent désormais s’adapter à l’environnement et au contexte de l’utilisateur afin de lui offrir le service le plus approprié. Cependant, cette adaptation doit respecter certains critères et ne doit pas se faire n’importe comment et à n’importe quel prix. Effectivement, le comportement d’un SIP, même s’il doit tirer profit de l’environnement dynamique et des opportunités qu’un tel environnement peut lui offrir, se Introduction!Générale 7 doit de rester prédictible, afin d’assurer la gouvernance de ces systèmes et la confiance des utilisateurs en eux. Le développement d’un SIP répondant à ces besoins est aujourd’hui un problème encore non résolu. Il n’existe pas à l’heure actuelle de modèle ou de méthode permettant aux concepteurs et aux développeurs de prendre en compte ces besoins lors de la conception d’un SIP. D’une part, les recherches au niveau des systèmes pervasifs se sont essentiellement concentrées sur le niveau technique. Des efforts importants ont été consacrés sur l’adaptation au contexte (Baldauf et al., 2007) (Chaari et al., 2008b) (Preuveneers et al., 2009), surtout à la localisation (Coronato et al., 2009) (Varshavsky et Patel, 2009) et aux terminaux (Lemlouma, 2004) (Yang et Shao, 2007). Nous constatons aujourd'hui les limitations de ces approches qui ne tiennent pas compte des exigences derrière l’expérience de l’utilisateur. Plusieurs possibilités peuvent être offertes à l’utilisateur, qui n’est toujours pas capable de comprendre ce qui lui a été proposé, ce qui nuit à la transparence d'utilisation de ces systèmes. Pour nous, la clé du succès serait donc d’assurer un certain niveau de compréhension à ces systèmes pervasifs sensibles au contexte. D’autre part, les recherches autour de la conception des SI ont été nombreuses, et nombreux sont les chercheurs à souligner l’importance de la notion d’intention (Santos et al., 2009)(Rolland et al., 2010)(Deneckere et Kornyshova, 2010). Une intention représente ce qu’attend l’utilisateur de l’exécution du service. Elle représente donc la vision de l’utilisateur sur les fonctionnalités qu’il désire dans un service (Fensel et al., 2011). Cette vision intentionnelle place la notion de service à un niveau d’abstraction plus élevé : le service est là afin de conduire son utilisateur à la satisfaction d’une intention. Il s’agit, selon (Rolland et al., 2010), de combler le fossé qui sépare une vision purement technique d’une vision purement métier des services, centrée sur l’utilisateur et ses besoins. La notion d’intention place donc le service à un niveau plus proche de celui de l’utilisateur final : quelle que soit la technologie utilisée, le service est défini pour satisfaire un besoin, un but exprimé par l’utilisateur. La notion d’intention a été souvent reliée à la notion de service. Plusieurs travaux ont, en effet, considéré la notion de service sous un angle intentionnel (Rolland et al., 2010) (Mirbel et Crescenzo, 2010a) (Santos et al., 2009) (Fensel et al., 2011). Ces approches considèrent qu’un utilisateur cherche, avant tout, à satisfaire une intention, et que les services constituent seulement un moyen de l’atteindre. Mais on constate que cette notion n’a été confrontée à la notion de contexte que rarement (Mirbel et Crescenzo, 2010a) (Santos et al., 2009) (Deneckere et Kornyshova, 2010). En effet, même si la notion d’intention permet au système de mieux comprendre les besoins réels des utilisateurs, l’influence d’un environnement pervasif dans l’émergence et la satisfaction des intentions reste encore peu explorée. Ainsi, nous pouvons résumer notre problématique à un problème de conception et de réalisation d’un SIP qui répond à tous les besoins de transparence, d’adaptation à l’environnement et d’adaptation à l’utilisateur d’un SIP. En effet, avec le manque de modèle et de méthode permettant de prendre en compte tous ces besoins, la DSI (concepteur du SIP) se trouve face à de grandes difficultés rendant difficiles la conception et la réalisation d’un Introduction!Générale 8 SIP transparent et centré utilisateur. Elle se trouve démunie face à une nouvelle génération de SI qui jusqu’à présent n’a pas été véritablement mise en place avec des formalismes appropriés dans l’objectif d’aider et d’orienter les concepteurs de ce système. En somme, nous pensons que la conception et la réalisation d’un SIP doit impérativement répondre aux problèmes suivants : • Transparence : contrairement aux SI traditionnels, les SIP doivent gérer l’hétérogénéité des environnements et des services, et ils doivent le faire de manière transparente à l’utilisateur. Or, à ce jour, peu d’outils, de formalismes et de méthodes destinés aux SIP sont à dispositions de leurs concepteurs. • Adaptation à l’environnement : contrairement aux SI traditionnels, les SIP doivent être conçus pour opérer dans un environnement pervasif. Ils doivent s’adapter au caractère dynamique de ces environnements, sans pour autant perdre la maitrise propre aux SI. L’équation est délicate et, à nouveau, peu d’outils ou de formalismes s’offrent aux concepteurs de ces systèmes. • Adaptation aux utilisateurs : les SIP doivent être conçus de manière à s’adapter non seulement à leur environnement, mais également à leurs utilisateurs. Ceux-ci ont des besoins auxquels les SIP doivent répondre de la manière la plus adaptée possible, tout en gardant la transparence nécessaire pour que le système disparaisse derrière la satisfaction des besoins. 1.3. HYPOTHESES Afin de traiter les problèmes soulevés dans la section précédente, nous considérons les hypothèses de travail suivantes : • Hypothèse principale : Une approche centrée utilisateur permettrait de garantir un environnement pervasif transparent au sein des SIP. Le développement d’une couche de haut niveau centrée utilisateur permettrait aux SIP de cacher la complexité de l’environnement pervasif qui se caractérise par son hétérogénéité et son dynamisme. Ceci permettrait alors de garantir la transparence de cet environnement pour l’utilisateur final. Nous croyons qu’une telle approche doit se concentrer à la fois sur l’adaptation (la prise en compte de l’environnement afin que celui-ci puisse devenir plus transparent à l’utilisateur) et sur les besoins de l’utilisateur (considérer aussi bien la raison pour laquelle il sollicite une action que la manière dont elle est réalisée). Les hypothèses ci-dessous détaillent cette vision. • Hypothèse 1 : La prise en compte de l’intention permettrait de mieux répondre aux besoins de l’utilisateur dans un Système d’Information Pervasif Introduction!Générale 9 Dans un Système d’Information, le but principal est de répondre aux besoins de l’utilisateur. L’expression de ces besoins sous la forme d’intention permettrait aux SIP de comprendre le ‘pourquoi’ d’une action, de mieux assimiler ce que l’utilisateur cherche réellement, et de répondre au mieux à ces besoins en proposant le service le plus approprié. • Hypothèse 2 : La sensibilité au contexte permettrait de mieux gérer le dynamisme de l’environnement pervasif dans les SIP Dans un environnement pervasif, la sensibilité au contexte joue un rôle central. Dans le cadre d’un SIP, elle permettrait de mieux gérer le dynamisme de l’environnement en percevant les informations contextuelles relatives à l’utilisateur et à l’environnement afin de pouvoir mieux adapter ses fonctionnalités de manière dynamique et proactive. • Hypothèse 3 : L’intention de l’utilisateur émerge dans un contexte donné L’intention n’est pas le fruit du hasard. Elle représente le besoin d’un utilisateur. Or ce besoin émerge dans un contexte donné. En d’autres termes, la notion d’intention est directement liée à la notion de contexte. Nous pensons qu’une intention n’a de sens que lorsqu’on la considère dans un contexte donné. • Hypothèse 4 : La réalisation de l’intention est valide dans un contexte, le contexte influence le choix de la réalisation Le contexte dans lequel émerge une intention peut influencer considérablement la manière dont cette intention peut être satisfaite, et donc influencer sa réalisation. • Hypothèse 5 : La prise en compte de l’intention et du contexte permettrait d’assurer un Système d’Information Pervasif transparent et compréhensible à l’utilisateur Un Système d’Information Pervasif doit être considéré comme étant un SI qui évolue dans un environnement pervasif. La prise en compte de leurs besoins respectifs en termes d’intentionnalité et de sensibilité au contexte permettrait de répondre au mieux aux besoins de l’utilisateur en assurant la transparence nécessaire pour un SIP. • Hypothèse 6 : Un mécanisme de prédiction de services, capable d'anticiper les besoins de l'utilisateur, pourra améliorer la transparence générale du système Le développement d’un mécanisme de prédiction de services qui permet d’anticiper les besoins des utilisateurs et de répondre à leurs intentions futures dans un contexte donné, permettrait aux SIP de cacher la complexité de l’environnement pervasif et d’améliorer la transparence de cet environnement pour l’utilisateur final. Introduction!Générale 10 Toutes ces hypothèses représentent le fondement de notre vision intentionnelle et contextuelle des Système d’Information Pervasif. Cette vision est présentée dans la section suivante et sera mise en place en présentant un cadre conceptuel des SIP, une démarche de conception d’un SIP et une architecture de gestionnaire de SIP conforme au cadre conceptuel. 1.4. APERÇU DE LA PROPOSITION Afin de répondre à notre problématique, nous proposons notre vision des SIP. Cette vision se base sur l’orientation service, la sensibilité au contexte et sur une approche intentionnelle afin de résoudre les problèmes de transparence, d’adaptation à l’environnement et d’adaptation aux utilisateurs que nous avons soulevés ci-dessus. Notre vision vise à concevoir un SIP transparent qui (i) gère l’hétérogénéité et la dynamique de l’environnement pervasif ; (ii) assure un certain niveau de contrôle et de maitrise nécessaire dans le cadre d’un SI ; et (iii) comprend les exigences et les besoins réels des utilisateurs derrière leur demande d’un service donné. Les hypothèses énumérées ci-dessus représentent le fondement de cette vision des SIP basée sur les notions d’intention, de contexte et de services. Ceci représente une vision centrée utilisateur des SIP, permettant de gérer l’hétérogénéité et le dynamisme de l’environnement à travers une approche intentionnelle et contextuelle. En effet, dans la perspective d’assurer la transparence et la compréhension nécessaire pour la conception d’un SIP, nous considérons les SIP et leurs éléments à la fois sous l’angle des SI et celui des environnements pervasifs, en observant leurs besoins respectifs de contrôle, d’intentionnalité et de sensibilité au contexte. Cette vision est orientée services, car elle permet de répondre au besoin de gestion de l’hétérogénéité technique de l’environnement dans lequel évoluent les SIP et des actions que le système propose afin de satisfaire les besoins des utilisateurs. Ce choix repose sur la caractéristique principale des services, à savoir leur indépendance par rapport aux aspects technologiques et à leur implémentation, ce qui nous permet ainsi de masquer l’hétérogénéité technologique des environnements pervasifs. De plus, notre vision est orientée contexte, car elle permet d’adapter les SIP au contexte de l’utilisateur et à l’environnement. Elle permet également de mieux gérer l’hétérogénéité et le dynamisme de l’environnement pervasif. Enfin, notre vision est orientée intention, permettant de répondre d’une façon personnalisée aux besoins de l’utilisateur. Cette notion d’intention formalise les besoins de l’utilisateur. Nous pensons que, dans le cadre des SIP, cette notion est nécessaire pour que ces systèmes comprennent mieux l’utilisateur et répondent à son besoin de la manière la plus appropriée. Par ailleurs, nous mettons l’accent, dans le cadre de notre vision centrée utilisateur des SIP, sur l’étroite relation entre les notions d’intention, de contexte et de service. Comme l’illustre Introduction!Générale 11 nos hypothèses, l’intention de l’utilisateur émerge dans un contexte donné. De plus, les réalisations de ses intentions ne sont valides que dans un contexte d’utilisation bien défini. Dans ce cadre, la notion de contexte représente un élément important dans le processus d'adaptation d’un système à l'utilisateur, auquel nous souhaitons ajouter la notion d’intention. En se basant sur ces notions d’intention, de contexte et de service et en exploitant la relation qui les lie, nous proposons une nouvelle vision centrée utilisateur d’un SIP transparent, non intrusif et compréhensible à l’utilisateur. Par la suite, nous proposons une solution plus globale pour concrétiser notre vision intentionnelle et contextuelle des SIP orientés services. Nous proposons une solution pour aider la DSI à concevoir un SIP en présentant un cadre conceptuel des SIP (cf. Chapitre 5) décrivant et formalisant l’ensemble de ses éléments. Nous proposons ensuite des mécanismes de découverte (cf. Chapitre 7) et de prédiction (cf. Chapitre 8) de services qui sont intégrés dans une architecture de gestionnaire de SIP (cf. Chapitre 9) qui est conforme à ce cadre conceptuel. Finalement, nous proposons une démarche méthodologique (cf. Chapitre 10) de conception et de réalisation d’un SIP qui supporte le passage entre le cadre conceptuel et l’implémentation de l’architecture proposée. Notre vision centrée utilisateur est déclinée sur quatre dimensions : • Dimension conceptuelle, à travers un cadre conceptuel dans la perspective d’aider la Direction des Systèmes d’Information (DSI) à mieux conceptualiser de tels systèmes et ses éléments (i.e. le service qu’ils offrent et les éléments de contexte observés) ; • Dimension fonctionnelle, grâce aux mécanismes de découverte de services et de prédiction de services en utilisant l’approche intentionnelle et sensible au contexte des SIP proposée ; • Dimension système, par l’architecture de gestionnaire de SIP en mettant en œuvre la vision intentionnelle et contextuelle conforme au cadre conceptuel. Elle intègre également des mécanismes de découverte et de prédiction de services ; • Dimension support, avec la démarche méthodologique de conception guidant le design des SIP du cadre conceptuel jusqu’à la description des services au dessus de l’architecture du système. Notre vision centrée utilisateurs des SIP, ainsi que sa concrétisation selon les quatre dimensions citées ci-dessus, seront présentées plus en détails dans le Chapitre 4. 1.5. ORGANISATION DE LA THESE Ce travail est organisé comme suit : • Le deuxième chapitre, représente un état de l’art sur les Systèmes d’Information Pervasifs et sur la notion de contexte. Nous évoquons, dans ce chapitre, les principaux Introduction!Générale 12 thèmes liés à notre travail, à savoir la sensibilité au contexte et les Systèmes d’Information Pervasifs ; • Le troisième chapitre, représente un état de l’art sur l’orientation service. Dans ce chapitre, nous évoquons les principaux thèmes liés à notre travail, à savoir les systèmes orientés services et les différentes tendances existantes, les systèmes intentionnels, etc. Par la suite, nous présentons les challenges pour les Systèmes d’Information Pervasifs orientés services, plus spécifiquement la découverte et la prédiction dynamique de services ; • Le quatrième chapitre, résume notre problématique et présente plus en détail notre proposition et la solution globale ; • Le cinquième chapitre, présente le cadre conceptuel des SIP, qu’on a appelé « espace de services ». Dans ce chapitre, nous présentons une conceptualisation des différents éléments constituant l’espace de services, à savoir les services et les capteurs ; • Le sixième chapitre, détaille la description sémantique des services. Ce chapitre explique notre extension de OWL-S pour inclure les informations intentionnelles et contextuelles des services en conformité avec l’espace de services ; • Le septième chapitre, présente le mécanisme de découverte de services guidé par le contexte et l’intention. Dans ce chapitre nous présentons notre algorithme de découverte dynamique des services intentionnels et contextuels, ainsi que notre implémentation et évaluation de cet algorithme ; • Le huitième chapitre, illustre le mécanisme de prédiction de services basé sur l’intention et le contexte. Dans ce chapitre nous présentons notre processus d’apprentissage et de prédiction dynamique des services intentionnels et contextuels, ainsi que notre implémentation et évaluation de ce processus ; • Le neuvième chapitre, illustre notre architecture de gestionnaire de SIP et présente ses différents composants et les interactions entre eux, afin de mettre en œuvre les différents concepts de l’espace de services ; • Le dixième chapitre, expose notre démarche méthodologique supportant le passage du cadre conceptuel des SIP vers l’architecture de gestionnaires des SIP. Nous illustrons, par la suite, cette méthodologie à travers un cas d’étude ; • Finalement, nous finalisons ce manuscrit par le onzième chapitre qui conclut ce travail de recherche et ouvre de nouvelles perspectives. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 13 Chapitre 2. SYSTEMES D’INFORMATION PERVASIFS ET LA NOTION DE CONTEXTE 2.1. INTRODUCTION L’émergence des nouvelles technologies et la démocratisation des terminaux mobiles ont impacté remarquablement notre quotidien et notre façon d’utiliser les systèmes et les services disponibles. Ceci représente l’apparition de l’Informatique Pervasive, laquelle vise à intégrer les technologies d’une façon invisible dans notre vie, rendant les services offerts par les systèmes disponibles n’importe où et n’importe quand. Cette arrivée de l’Informatique Pervasive impacte sérieusement les Systèmes d’Information (SI) au sein des organisations. Au cœur de l’Informatique Pervasive se trouve la notion de sensibilité au contexte. La notion de contexte a été largement étudiée et discutée dans ce domaine. Elle représente un concept très vague qui fait apparaître diverses définitions selon différents points de vue allant des plus généraux, applicables à tous les domaines, au plus spécifiques s’appliquant à un type d’application ou domaines précis. Cette variété de définition a fait émerger de multiples modèles dans la perspective de représenter et de limiter la notion de contexte. Ces modèles de contexte ont fait l’objet de plusieurs années de recherche qui ont conduit à une modélisation sémantique plus compréhensible et plus significative, faisant appel aux ontologies et à de techniques de raisonnement plus puissantes. Ces modèles de contexte sont utilisés dans les processus d’adaptation et de personnalisation au sein des Systèmes Sensibles au Contexte afin d’offrir les services les plus appropriés et les mieux adaptés à l’utilisateur. Ce chapitre présente un état de l’art sur la notion de contexte et sur les Systèmes d’Information Pervasifs (SIP). Nous commençons par illustrer l’émergence et l’historique du domaine de l’Informatique Pervasive et des Systèmes Sensibles au Contexte. Nous présentons, par la suite, la notion de contexte, nécessaire à ces systèmes, exposée sous différentes définitions, caractéristiques et dimensions. Dans cette partie, nous attribuons une attention particulière aux différentes modélisations de contexte illustrées à la littérature et au processus de gestion de contexte qui représentent le fondement des Systèmes Sensibles au Contexte. De plus, face à la multitude de modèles de contexte, nous proposons, à la fin de cette partie, un cadre d’analyse et de comparaison des modèles existants. Finalement, nous présentons l’impact de l’émergence de l’Informatique Pervasive sur les SI faisant apparaître une nouvelle classe de SI appelée les Systèmes d’Information Pervasifs (SIP). 2.2. L’INFORMATIQUE PERVASIVE ET LES SYSTEMES SENSIBLES AU CONTEXTE Dans cette section, nous présentons l’historique de l’apparition du domaine de l’Informatique Pervasive et des Systèmes d’Information Pervasifs. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 14 2.2.1. Définition et historique du domaine de l’Informatique Pervasive Depuis plusieurs années, nous sommes témoins d’une importante évolution des nouvelles technologies (Smartphones, tablettes, 3G, etc.) et de la façon dont nous les utilisons pour accéder aux différents systèmes et services qui prennent place dans notre quotidien. Ceci représente l’ère de l’Informatique Pervasive, dorénavant invisible à nos yeux, faisant partie intégrante de notre quotidien, à tel point qu’il nous est désormais impossible d’imaginer notre vie personnelle et professionnelle sans elle. Cette nouvelle ère vise à intégrer discrètement les ordinateurs dans la vie de tous les jours des utilisateurs à la maison et au travail (Che et al. 2007). L’objectif est de rendre plus confortable la vie au quotidien des utilisateurs. Elle a tendance vers la miniaturisation des dispositifs électroniques et leur intégration à n'importe quel objet du quotidien, favorisant ainsi l'accès aux informations dont nous avons besoin partout et à tout moment. Ainsi, l'Informatique Pervasive émerge comme un nouveau paradigme fournissant des services informatiques à tout moment et n'importe où. Cette vision d’une Informatique invisible et intégrée à l’environnement a été soutenue depuis plusieurs années par l’Informatique Pervasive (ou Ubiquitaire) (Weiser 1991). Selon plusieurs observations, Weiser a constaté que le ratio d’ordinateur par personne n’a cessé d’augmenter considérablement. Dans son article (Weiser 1991), il soutient que « Les technologies les plus profondément enracinées sont les technologies invisibles. Elles s’intègrent dans la trame de la vie quotidienne jusqu’à en devenir indiscernables ». Cette vision des technologies présentes mais non intrusives, qui accompagnent les usages du quotidien et les déplacements des utilisateurs, a guidé vingt années de recherche en Informatique Pervasive (Bell et Dourish, 2007). L’Informatique Pervasive a été envisagée par Weiser (Weiser, 1991) comme la troisième ère de l’informatique moderne, dans laquelle l’utilisateur est confronté à une multitude d’ordinateurs sans fil communiquant entre eux discrètement. En effet, un changement radical dans l’informatique a été souligné par Weiser (Weiser, 1991) : partant de l’époque ou plusieurs utilisateurs partagent le même ordinateur (ère de l’ordinateur central « mainframe »), vers l’époque de la relation personnelle avec l’ordinateur (ère de l’ordinateur personnel), en arrivant à l’émergence d’un monde où l’utilisateur interagit en toute transparence avec une multitude d’ordinateurs. L’ère de l’Informatique Pervasive représente l'époque actuelle qui est caractérisée par l’évolution des technologies mobiles et par la démocratisation des dispositifs et des réseaux mobiles. Ceci a entraîné progressivement la croissance remarquable des ordinateurs intégrés dans la vie quotidienne. Selon Satyanarayana (Satyanarayana 2001), l’Informatique Pervasive englobe l’informatique mobile, mais elle va beaucoup plus loin. L'informatique mobile s'appuie sur les fondations de systèmes distribués, des réseaux mobiles et des systèmes sensibles à l'énergie. Elle englobe tout ceci en y intégrant quatre axes de recherche complémentaires : les espaces intelligents, l’invisibilité, le passage à l’échelle localisée et le conditionnement inégal (Satyanarayana 2001). Le premier axe, les espaces intelligents, est l’utilisation efficace des Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 15 espaces intelligents qui embarquent le monde physique dans le monde conceptuel. Le deuxième axe, l’invisibilité, renvoie à ce que Weiser décrit comme une intégration transparente de l'informatique dans le tissu de notre vie quotidienne. Ceci signifie, comme l’a mentionné Weiser (Weiser 1991), la disparition de la technologie dans la conscience de l’utilisateur. Le troisième axe, le passage à l’échelle localisée, comprend l’emploi de méthodes qui réduisent l’intensité des interactions de l'utilisateur avec les services offerts par le système (basées sur la distance entre eux). Finalement, le quatrième axe, le conditionnement inégal, fait référence aux techniques permettant de masquer le conditionnement intégral de l’environnement. Ceci nécessite un espace de transition, où les applications informatiques traditionnelles et les infrastructures sont peu à peu remplacées par d'autres, présentant les caractéristiques de l'Informatique Pervasive. Toutefois, une certaine confusion persiste quant à savoir si cette vision est une réalité ou un avenir proche. Bell et Dourish (Bell et Dourish, 2007) avancent l’idée selon laquelle l’Informatique Pervasive est déjà une réalité. Pour ces auteurs, elle fait partie intégrante de notre quotidien, notamment à travers les nouvelles technologies. Celles-ci sont effectivement devenues presque invisibles à nos yeux, à tel point qu’il nous est désormais impossible d’imaginer notre vie personnelle et professionnelle sans ces technologies. Selon Bell et Dourish (Bell et Dourish, 2007), l'Informatique Pervasive a pris une forme différente de celle attendue par Weiser, à travers les dispositifs mobiles centraux à notre vie quotidienne. Ces auteurs soutiennent que nous sommes continuellement en train d’utiliser des ressources informatiques dans notre vie courante sans forcément les percevoir en tant qu’ordinateurs. L’Informatique Pervasive est ainsi une réalité sous la forme d’un environnement densément peuplé de ressources informatiques et de communication (Bell et Dourish, 2007). Ce point de vue est partagé par Greenfield (Greenfield, 2006) selon qui l’Informatique Pervasive représente une informatique sans ordinateur, dans laquelle le traitement de l'information est omniprésent dans la vie quotidienne. De part l’intégration des différents dispositifs à l’environnement et à notre vie quotidienne, on peut caractériser l’Informatique Pervasive par son hétérogénéité, hétérogénéité des ressources et de l’infrastructure. Il est illusoire d’imaginer que cette hétérogénéité disparaîtra avec le temps. Ces environnements resteront toujours complexes et extrêmement denses d’un point de vue technologique. Au-delà de cette hétérogénéité, les environnements pervasifs se caractérisent également par leur dynamique. Selon (Hagras, 2011), la nature dynamique de ces environnements leur impose une capacité d’adaptation à des conditions d’opération changeantes et à des utilisateurs dont les préférences et le comportement sont également variables. L’informatique Pervasive implique donc la sensibilité au contexte. 2.2.2.Systèmes Sensibles au Contexte Les années quatre-vingt-dix ont été caractérisées par l’émergence des Systèmes Sensible au Contexte. Cette nouvelle notion est apparue à travers notamment les travaux de Schilit et Theimer (Schilit et Theimer, 1994), Schilit et al. (Schilit et al., 1994), Hull (Hull et al., 1997) et Dey (Dey, 2000). Schilit et Theimer (Schilit et Theimer, 1994) définissent la sensibilité au Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 16 contexte comme la capacité d'une application à découvrir et à réagir aux modifications dans l'environnement où se trouve l'utilisateur. Selon Schilit et al. (Schilit et al., 1994), les Systèmes Sensibles au Contexte sont définis comme des systèmes qui s'adaptent à la localisation de l'utilisateur et à l'ensemble des personnes, des machines et des dispositifs proches ou accessibles, ainsi qu'aux changements dans le temps de ces éléments. Quelques années plus tard, d’autres définitions de la sensibilité au contexte sont apparues avec les travaux de (Hull et al., 1997) et (Dey, 2000), pour ne citer qu’eux. Hull et al. (Hull et al., 1997) définissent la sensibilité au contexte comme la capacité des dispositifs informatiques à détecter, capturer, interpréter et répondre aux aspects de l’environnement de l’utilisateur et aux dispositifs informatiques. Dey (Dey, 2000), quant à lui, présente une définition plus générale. Il considère qu'un système est sensible au contexte s'il utilise le contexte pour fournir à l'utilisateur des informations ou des services pertinents, où la pertinence dépend de la tâche exécutée par l'utilisateur (Dey, 2000). Ainsi, l'une des prémisses essentielles des systèmes sensibles au contexte est d’être conscient des circonstances dans lesquelles se trouve l'utilisateur, d'être capable d'interpréter et de réagir à toute interaction conformément à ces circonstances (O’Hare et O’Grady, 2002). Dans ce cadre, le contexte est un élément clé, car il est au centre des mécanismes d’adaptation prônés par ces systèmes dits sensibles au contexte. Ces systèmes se caractérisent, en effet, par leur capacité à adapter leur fonctionnement afin d’augmenter leur utilisabilité et leur efficacité, par la prise en compte du contexte environnant (Baldauf et al., 2007). En d’autres termes, un Système Sensible au Contexte est un système qui supporte une certaine variabilité, le choix de la variante dépendant du contexte qui entoure l’exécution du système et son interaction avec les utilisateurs. Le contexte agit ainsi comme un élément extérieur au système qui influence sa variabilité intérieure, une sorte de contrainte qui guiderait le choix de la variante la plus appropriée et le processus d’adaptation la concernant (Najar et al., 2009). La sensibilité au contexte est une des propriétés les plus importantes d’un système pervasif caractérisant la capacité d’un système à prendre en compte l’environnement, à acquérir des informations sur ce dernier, puis à réagir en conséquence. Il s’agit d’un des piliers pour construire des systèmes mobiles et pervasifs modernes (Schilit et al., 1994) (Dey et Abowd, 2000) (Jones et Grandhi, 2005) (Bolchini et al., 2009). La mobilité de l'utilisateur apportée par l'évolution des nouvelles technologies représente un aspect important conduisant à l’apparition de ces Systèmes Sensibles au Contexte. Selon Dourish (Dourish, 2004), lorsque l'informatique est sortie de l'environnement du bureau (fixe) traditionnel, il est devenu important de suivre à la trace la situation dans laquelle la technologie est utilisée. Par exemple, les utilisateurs mobiles ont besoin d'un contenu informatif qui convient à leur utilisation sous des conditions changeantes (temporelles, spatiales, matérielles, physiques et environnementales) (Carrillo-Ramos et al., 2009). Ces besoins d'adaptation ont guidé la proposition des Systèmes Sensibles au Contexte. Dans ces systèmes, le contexte guide les mécanismes d'adaptation utilisés pour personnaliser le contenu et les services en conséquence. Même si des solutions sensibles au contexte sont apparues dans différents domaines de recherche, la sensibilité au contexte atteint son utilité maximale lorsqu'elle est appliquée à des Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 17 systèmes pervasifs mobiles. La sensibilité au contexte permet également aux services de s'adapter dynamiquement et efficacement à la fois : (i) à la situation actuelle, tels que le lieu physique actuel et/ou l'activité sociale ; et (ii) aux conditions complexes et variables de déploiement typiques des environnements mobiles (rareté des ressources, la connectivité, etc.). Cette capacité à rassembler et à livrer à un service toutes les informations pertinentes pouvant caractériser son environnement d’exécution (les ressources/capacités informatiques, l'emplacement du dispositif physique, les préférences des utilisateurs, etc.) est ainsi devenue une fonction fondamentale pour le développement de systèmes mobiles modernes. Finalement, il est important de souligner que la notion de contexte est considérée comme l’élément clé des Systèmes Sensibles au Contexte et, ainsi des Systèmes d’Information Pervasifs. En effet, le contexte est au centre des mécanismes d’adaptation de ces systèmes. Nous discutons, dans la section suivante, les différentes facettes de la notion de contexte. 2.3. LE CONTEXTE Dans cette section, nous allons procéder à l’étude de la notion de contexte. Nous commençons par présenter, dans la section 2.3.1, les différentes définitions, caractéristiques et dimensions, et nous détaillons, par la suite, les différentes modélisations dans la section 2.3.2. La section 2.3.3 englobe une présentation de la gestion de contexte nécessaire aux processus d’adaptation des Systèmes Sensibles au Contexte. Nous conclurons cette section par une analyse comparative des différents modèles de contexte existants. 2.3.1.La notion de contexte : définitions, caractéristiques et dimensions La notion de « contexte » est un concept très large, exploré depuis plusieurs années dans plusieurs domaines de recherche tel que l’Intelligence Artificielle et l’Informatique Pervasive (Kirsch-Pinheiro, 2006). Cette notion permet, entre autres, de mieux comprendre les interactions des utilisateurs mobiles avec le système et leurs attentes vis-à-vis du même système. La notion de contexte est ainsi utilisée par certains systèmes dans leur processus d’adaptation. Ce processus d’adaptation permet de fournir une réponse plus appropriée à l’utilisateur, potentiellement répondant au mieux à ses besoins dans un contexte donné. Dans cette perspective, la notion de contexte apparaît comme un élément central dans une démarche d'adaptation dans un tel système (Najar et al., 2009). Au regard de la littérature, nous pouvons constater qu’elle fait par ailleurs l'objet de nombreuses définitions et interprétations. Plusieurs travaux de recherche (Schilit et Theimer, 1994) (Brown et al., 1997) (Dey, 2001) (Strang et Linnhoff-Popien, 2004) se sont focalisés sur la définition et l’utilisation de contexte. Cette section aborde les différents travaux et les définitions portés sur la notion de contexte, ainsi que ses différentes caractéristiques et dimensions proposées dans la littérature. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 18 2.3.1.1. Définitions Afin d’utiliser efficacement la notion de contexte, il faut commencer par comprendre la signification de contexte et comment il peut être utilisé (Dey, 2001). La définition précise de contexte et de ses caractéristiques s’est avérée une question assez délicate. En effet, la notion de contexte est utilisée et interprétée différemment selon le domaine de recherche dans lequel elle est employée et selon les perspectives offertes. Les premiers travaux dans les Systèmes Sensibles au Contexte ont proposé une vision et une utilisation particulièrement limitée du contexte. Initialement, de nombreux chercheurs, tels que (Schilit et Theimer, 1994) (Brown et al., 1997) (Ryan et al., 1997), représentent la définition de contexte comme une énumération des différents types d’informations portées sur l’utilisateur ou l’environnement dans lequel s’intègre l’application et qui sont jugés pertinents. Schilit et Theimer (Schilit et Theimer, 1994) présentent l’une des premières tentatives de formulation de la notion de contexte. Ces auteurs limitent la définition de contexte à l’observation de la localisation de l’utilisateur, de l’ensemble des utilisateurs présents, des objets à proximités, et des changements apportées à ces éléments (Schilit et Theimer, 1994). Schilit et al. (Schilit et al., 1994) ne cherchent pas à comprendre la nature du contexte. Ils affirment tout simplement que les aspects les plus importants de la notion de contexte peuvent être déterminés en répondant aux questions « où se trouve l’utilisateur ? », « avec qui se trouve-t-il ? » et « quelles sont les ressources à proximité ? ». Une autre définition est ensuite proposée par Brown et al. (Brown et al., 1997). Ces derniers considèrent que le contexte regroupe la localisation de l’utilisateur, les identités des personnes qui l’accompagnent, le temps représentant un moment de la journée, la saison, la température, etc. (Brown et al., 1997). Pour Ryan et al. (Ryan et al., 1997), qui appliquent la sensibilité au contexte dans le cas d'un logiciel de prise de note pour l'archéologie, le contexte se définit de façon plus générale comme la localisation, l'environnement, l'identité et le temps relatifs à l'utilisateur. Toujours dans le même principe de définir la notion de contexte en énumérant ses différents types d’information, Dey (Dey et al., 1998) apportent une autre définition qui présente le contexte comme étant l’état émotionnel de l’utilisateur, le focus de l’attention, la localisation et l’orientation, la date et le temps, les objets et les personnes dans l’environnement de l’utilisateur comme les éléments constituant la définition de contexte. Enfin, Chen et Kotz (Chen et Kotz, 2000) définit le contexte comme l’ensemble des états et des paramètres environnementaux qui soit déterminent le comportement d'une application soit dans lesquels un événement d'application se produit et est intéressant pour l’utilisateur. Nous observons que ces premiers travaux de recherche se sont focalisés plus précisément sur l’identification des éléments décrivant le contexte d’usage d'un système, plutôt que de comprendre sa réelle signification. Ils demeurent assez vagues sur la nature de la notion de contexte elle même. Toutefois, suite à ces premiers travaux, une plus grande attention a été accordée à la notion de contexte. Pascoe 1998 (Pascoe, 1998) et Dey (Dey, 2001), par exemple, ont proposé des définitions de contexte plus générales et largement acceptées. Ces définitions donnent un sens plus opérationnel à la notion de contexte, employée pour leSystèmes!d’Information!Pervasifs!et!la!notion!de!contexte 19 développement d'applications pervasives (ubiquitaires) et mobiles. Leur objectif est d’abstraire les précédents travaux sur le contexte de leurs liens aux expérimentations et aux scénarii bien spécifiques. Ainsi, Pascoe 1998 (Pascoe, 1998) voit le contexte comme le sousensemble mesurable d'un environnement porté à l'intérêt des utilisateurs. Cette définition ne se limite pas à un domaine en particulier et a comme objectif de pouvoir être dérivée et applicable à différents types d’application et de scénarii. Par contre, de part sa généricité, cette définition est parfois difficilement applicable à un cas concret. Quelques années plus tard, apparaît la définition la plus connue proposée Dey (Dey, 2000) qui décrit le contexte comme étant « toute information qui peut être utilisée pour caractériser la situation d'une entité. Une entité est une personne, un endroit ou un objet considérés comme pertinents pour l'interaction entre un utilisateur et une application, y compris l'utilisateur et les applications elles-mêmes ». Cette définition a été illustrée et utilisée par la suite comme une référence dans plusieurs travaux de recherche. La pertinence de cette définition émerge de sa capacité à être dérivée selon différents degrés de granularité, en plus d’être utilisée dans n'importe quel scénario. Elle concerne plus particulièrement la conception des Systèmes Sensibles au Contexte, puisqu’elle prend en compte la pertinence des éléments pour les interactions entre l’utilisateur et le système. Cet auteur (Dey, 2001) estime d’ailleurs que les précédentes définitions étaient trop précises, car il est impossible d'énumérer les aspects qui sont importants pour toutes les situations, ceux-ci pouvant changer d'une situation à une autre. La notion de contexte s’est étendue avec (Mostefaoui et al., 2004) (Brézillon, 2005) (Kirsch-Pinheiro, 2006). Désormais, elle ne se limite plus à l’utilisateur qui a effectué une action ou à sa localisation, mais elle s’étend aux informations physiques (localisation, temps, etc.), aux informations sociales et même organisationnelles (rôle de l’utilisateur, etc.). D’une manière plus générale, Mostefaoui et al. (Mostefaoui et al., 2004) définissent le contexte comme ce qui entoure le centre d'intérêt de l'individu et qui apporte des informations additionnelles capables d'aider à la compréhension de ce centre d'intérêt. Dans ce même cadre, Brézillon (Brézillon, 2005) précise que le contexte dépend également de l’activité courante de l’utilisateur. L’activité est considérée, par ces auteurs, comme un élément clé de contexte : elle détermine les informations, les connaissances, les objets de l’environnement, etc. qui représentent les éléments les plus pertinents autour d’elle et qui sont nécessaires à son accomplissement. Selon cet auteur, le contexte entoure un focus (par exemple, la tâche à accomplir ou l'interaction) et donne un sens aux éléments liés à ce focus sans intervenir explicitement dans celui-ci. La notion de contexte est ainsi employée afin d’orienter le focus d'attention, à savoir les sous-ensembles d'un terrain d'entente jugé pertinent pour l’activité en cours (Brézillon, 2005). Sous cette optique, nous pouvons voir le contexte comme étant l’ensemble des caractéristiques de l'environnement dans lequel se déroule l'activité, mais qui sont séparés de l'activité elle-même. Toutefois, malgré le fait que la définition proposée par Dey (Dey, 2000) soit une référence dans le domaine de l’informatique sensible au contexte, elle demeure débattue (Tamminen et al., 2004). Certains auteurs, comme (Greenberg, 2001), la trouvent trop générale et révèlent un problème important d’adaptation au processus de conception. D’autres auteurs, dont Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 20 (Chaari et al., 2005), trouvent que le problème essentiel dans cette définition est l'identification des éléments composant la notion de contexte. De plus, selon ces auteurs, la définition proposée par Dey ne distingue pas les données contextuelles des données de l'application. Ces auteurs considèrent que cette séparation est très importante pour la modélisation de contexte. Selon Chaari et al. (Chaari et al., 2004), la notion de contexte correspond à un ensemble de paramètres qui sont externes à l'application et qui influencent le comportement de celle-ci en définissant de nouvelles vues sur ses données et ses services. Dans la même ligne, Gensel et al. (Gensel et al., 2008) définissent la notion de contexte comme étant l’ensemble des caractéristiques de l'environnement physique ou virtuel qui affecte le comportement d'une application et dont la représentation et l’acquisition sont essentielles à l’adaptation des informations et des services. Elle devient un élément clé de l’Informatique Pervasive, car elle est au centre des mécanismes d’adaptation prônés par les Systèmes Sensibles au Contexte. Selon cet aperçu de la littérature, nous pouvons observer que le contexte a été défini de multiples façons, selon des points de vue différents. Ceci a engendré les multiples définitions de contexte présentées ci-dessus. Toutefois, la définition proposée par (Dey, 2000) demeure la référence dans le domaine de l’informatique sensible au contexte. 2.3.1.2. Caractéristiques La notion de contexte expose un certain nombre de caractéristiques dans l’Informatique Pervasive. A partir des travaux de (Henricksen et al., 2002) (Gu et al., 2004) (Baldauf et al., 2007), nous soulignons ici celles qui nous semblent les plus pertinentes : • Hétérogénéité : Les informations de contexte peuvent provenir de diverses sources (Gu et al., 2004). Elles peuvent être capturées (à travers des capteurs physiques, logiques ou virtuels), dérivées (en se basant sur des mécanismes de raisonnement ou de transformation), statiques (qui ne varient pas avec le temps), ou fournies par l’utilisateur (décrivant son profil). De plus, le contexte se définit par toute sorte d’information capable de décrire les objets physiques, les applications et les utilisateurs dans différents domaines. Ceci conduit à une hétérogénéité remarquable des informations contextuelles ; • Statique vs dynamique : Les informations de contexte peuvent être définies en tant qu’informations statiques ou dynamiques de contexte. Cette caractéristique dépend du niveau de variabilité des valeurs de cette information contextuelle. D’une part, les informations dites statiques sont celles qui décrivent les aspects ne variant pas avec le temps, tel que la date de naissance de l’utilisateur. D’autre part, les informations dites dynamiques sont celles qui varient avec le temps selon les changements capturés, tel que la localisation d’un utilisateur. En effet, les Systèmes Sensibles au Contexte se caractérisent par leurs changements fréquents, ce qui implique que la majorité des informations contextuelles est dynamique. Brézillon (Brézillon, 2002), Rey et Courtaz (Rey et Coutaz, 2004) ont souligné ce caractère dynamique, dit aussi évolutif, de la notion de contexte. Selon Brézillon et al. (Brézillon, 2002), le contexte doit être Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 21 considéré comme étant un espace qui dépend fortement de la situation et qui est en continuelle évolution. Pour Chaari et al. (Chaari et al., 2004), les paramètres qui composent le contexte évoluent durant l'exécution du système ; • Interdépendance : Les informations de contexte peuvent être dépendantes entre elles (Henricksen et al., 2002)(Gu et al., 2004). Certaines informations peuvent être interdépendantes par raisonnement et par dérivation de règles par exemple. En effet, par raisonnement sur le contexte, une information peut être inférée à partir d’une ou de plusieurs autres informations capturées, définies ou agrégées. Cette dérivation démontre certaines dépendances internes entre les éléments de contexte. Par exemple, dans certains cas, l’activité de l’utilisateur ne peut être dérivée que de sa localisation et de son planning numérique ; • Imperfection : L’acquisition des informations contextuelles se fait à travers divers capteurs qui peuvent fournir des informations défectueuses ou être même la déconnection ou l’échec de communication entre le fournisseur et le consommateur de contexte, peuvent conduire à l’imperfection des éléments de contexte (Henricksen et al., 2002). En effet, certaines informations contextuelles peuvent être incorrectes si elles ne reflètent pas la situation réelle de ce qu’elles modélisent. De plus, elles peuvent être incomplètes dans le cas où certains éléments de contexte demeurent inconnus. Ceci est dû, par exemple, à l’arrêt d’un capteur ou à un échec de communication entre le fournisseur et le consommateur de contexte. En outre, certaines informations de contexte peuvent être inconsistantes si elles contiennent des informations contradictoires par exemple. La prise en compte de la notion de contexte pour gérer la caractéristique dynamique d’un Système Sensible au Contexte dépend de la nature de chaque type d’éléments de contexte, de sa pertinence et de son utilisation dans le système. Ainsi, étant donnée la diversité des informations de contexte, il est utile de bien les classifier par dimension afin de faciliter leur utilisation et compréhension. C’est pour cette raison que nous présentons dans la section suivante les dimensions potentielles de contexte. 2.3.1.3. Dimensions Les difficultés rencontrées à définir d’une manière unique et non ambiguë la notion de contexte ont encouragé différentes interprétations des dimensions. Ces dimensions regroupent les informations contextuelles qui appartiennent à une même catégorie. En d’autres termes, ils représentent la classification des éléments de contexte afin de faciliter leur interprétation, leur compréhension ainsi que leur utilisation. Il est possible de classifier les éléments de contexte de différentes manières. Henricksen et al. (Henricksen et al., 2002) notent que la catégorisation des éléments de contexte en un ensemble de dimensions est utile pour gérer la qualité de contexte. En outre, cette classification est également utile pour la modélisation (Soylu et al., 2009), que nous discuterons dans la section 2.3.2. La description de ces dimensions a fait l’objet de plusieurs propositions résumées dans multiples travaux (Baldauf et al., 2007) (Banâtre et al., 2007) (Han et al., 2008) (Soylu et al., Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 22 2009). Ces travaux proposent des dimensions de contexte représentées à un niveau élevé de granularité. Cette classification des éléments de contexte, selon Soylu et al. (Soylu et al., 2009), permet une stratification claire pour le développement des Systèmes Sensibles au Contexte. Elle peut servir comme un premier pas vers une conceptualisation générique des éléments de contexte. Nous présentons certaines de ces dimensions : • Dimension temporelle caractérise, selon (Soylu et al., 2009), des éléments de contexte dont l’existence ou l’importance dans la perception du contexte est liée à un moment donné. Cette dimension peut être utilisée pour décrire le temps associé aux différents types d’information de contexte, par exemple : le fuseau horaire, l’heure actuelle de l’utilisateur, le début et la fin d’une situation, la durée d’un évènement, d’une activité, ainsi que d’un planning de travail, ou d’utilisation d’une ressource ... Par ailleurs, le temps est un élément très important pour établir et gérer l’historique des contextes ou des situations passées permettant d’enrichir le contexte ; • Dimension spatiale définit, selon (Soylu et al., 2009), la localisation. Cette localisation peut déterminer un espace précis dans lequel s’organise certains dispositifs ou objets de l’environnement, comme elle peut décrire l’emplacement des utilisateurs qui se déplacent d’un endroit à un autre. Cette dimension regroupe la localisation physique, tels que la position absolue (adresse géographiques), le lieu (à la maison, chez le client, etc.), coordonnées GPS, ainsi que la localisation virtuelle, tel que l’adresse IP considérée comme une localisation dans un réseau ; • Dimension relative aux dispositifs permet de mesurer les caractéristiques de la plateforme cliente (Van Welie et De Ridder, 2001) (Groot et Welie, 2002). Cette dimension est appropriée dans le cas où le système doit s’adapter aux capacités et aux conceptions très hétérogènes de ces dispositifs. Cette dimension caractérise les dispositifs mobiles (i.e. smartphone, ordinateur portable, tablette, etc.), les dispositifs fixes (i.e. écrans LCD, des capteurs fixes, des hauts parleurs, etc.), ainsi que d’autres ressources informatiques. Les caractéristiques de ces dispositifs (taille, résolution, puissance de calcul, etc.) peuvent varier beaucoup, ainsi que leur disponibilité. Par conséquent, le système doit adapter son contenu en fonction des caractéristiques de ces dispositifs. Les dispositifs fixes peuvent communiquer et échanger des données avec d’autres types de dispositifs. Pour les ressources informatiques, certains systèmes prennent en compte la charge et la puissance du processeur de l’ordinateur, des périphériques, la charge du réseau en fonction de sa bande passante, etc. ; • Dimension relative à l’utilisateur représente les informations de contexte relatives à un représentant du public cible du système, décrit par ses capacités physiques et cognitives (i.e. profil de l’utilisateur, les personnes à proximité, la situation sociale actuelle, etc.) (Schilit et al., 1994) (Chen et Kotz, 2000) ; • Dimension relative à l’environnement regroupe les informations contextuelles portant sur les informations périphériques à la tâche de l’utilisateur, mais susceptibles de l’influencer (Calvary et al., 2002). Pour certains systèmes, il est intéressant voire nécessaire de mesurer les caractéristiques de l’environnement autour de l’utilisateur afin de s’adapter et de réagir en conséquence. Par exemple, en mesurant le niveau de bruit, nous pouvons ajuster le niveau sonore du haut parleur d’un dispositif mobile ; Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 23 • Dimension relative à l’infrastructure caractérise les impacts de la communication entre les composants distribués sur l’activité fonctionnelle du système et sur l’interaction avec le ou les utilisateur(s) (Rodden et al., 1998). Selon Rodden et al. (Rodden et al., 1998), dans les systèmes mobiles la nature de l’infrastructure est susceptible de changer pendant son usage. Cette variabilité dans l'infrastructure peut avoir un impact sur l’interaction. Il est essentiel que les styles et les interfaces des interactions soient compatibles avec l'état de l'infrastructure. Les propriétés particulières de l’infrastructure, comme la topologie du système, doivent ainsi être intégrées lors de la conception d’un système mobile ; • Dimension relative au système évalue l'utilisation des ressources, par exemple la mémoire, le processeur et le réseau, des composants du système et des capacités du dispositif mobile de l'utilisateur. Malgré ces différentes définitions et visions de la notion de contexte, l’informatique sensible au contexte a su adopter des démarches pragmatiques pour proposer différentes modélisations de contexte. En effet, la gestion de contexte et de ses différentes caractéristiques nécessite de représenter le contexte explicitement dans le système. Nous décrivons dans la section suivante la modélisation de cette notion de contexte. 2.3.2.Modélisation de contexte Dans les Systèmes Sensibles au Contexte, la notion de contexte joue un rôle central qui guide le mécanisme d'adaptation utilisé pour personnaliser le contenu et les services en conséquence. La façon dont les informations de contexte sont utilisées dans ces systèmes dépend de : (i) quelle information est observée ; et (ii) comment elle est représentée. Pour (Brézillon, 2002), une représentation efficace du contexte en machine, tant en termes de modélisation de connaissances que de raisonnement à partir de celles-ci, est un problème à résoudre, et ce, aussi bien du point de vue de la programmation que de son utilisation. Un modèle de contexte est une représentation explicite de l’information de contexte dans le système afin qu’il puisse stocker, interpréter, gérer et raisonner sur ces informations contextuelles pour un objectif précis. Dans un environnement pervasif, la modélisation de ces informations contextuelles dans un système est nécessaire car elle permet de gérer la sensibilité au contexte et l’adaptation. En d'autres termes, les capacités d'adaptation d'un Système Sensible au Contexte dépendent du modèle de contexte utilisé (Najar et al., 2009). Ainsi, un modèle de contexte bien conçu est le fondement d'un Système Sensible au Contexte (Strang et Linnhoff-Popien, 2004). De toute évidence, le formalisme choisi pour représenter ce modèle est important, car il détermine les méthodes de raisonnement que le système peut utiliser pour effectuer certaines adaptations. Grâce à la littérature, nous pouvons observer que de nombreux modèles de contexte ont été proposés par la communauté de recherche (Strang et Linnhoff-Popien, 2004) (Najar et al., 2009) (Bettini et al., 2010). Chaque modèle présente différents points de vue de la notion de contexte qui ont été étudiés dans différents domaines d'application (e.g. intelligence ambiante, systèmes mobiles de tourisme). Un modèle de contexte assure la définition de processus d'adaptation indépendant et isole ce processus des Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 24 techniques d'acquisition de contexte, représentant ainsi la première exigence pour la maintenance et l'évolution des Systèmes Sensibles au Contexte (Najar et al., 2009). L'évolution des Systèmes Sensibles au Contexte de la dernière décennie a été suivie par une importante évolution des modèles de contexte, allant des simples structures clé-valeur aux modèles basés sur des ontologies. Les approches existantes de modélisation de contexte diffèrent ainsi par la puissance d’expression des modèles de contexte, par le support qu'ils peuvent fournir pour raisonner sur des informations de contexte, et par la performance de calcul de ce raisonnement. Strang et Linnhoff-Popien (Strang et Linnhoff-Popien, 2004) et Bettoni et al. (Bettini et al., 2010) ont souligné les approches les plus pertinentes. Ces auteurs classifient les modèles de contexte en fonction de leurs structures de données utilisées pour maintenir et échanger les informations contextuelles dans un système donné. Dans les prochaines sections, nous présentons les structures de données les plus couramment utilisées. 2.3.2.1. Modélisation de contexte basée sur les paires clé-valeur La modélisation de contexte constituée de paires « clé-valeur » correspond au formalisme le plus simple pour représenter le contexte. Il s'agit de représenter le contexte d'utilisation comme un ensemble de paires contenant chacune une clé et la valeur qui lui correspond. Dans cette approche, un élément observé de l’environnement est considéré comme une clé, et la valeur de cet élément représente les données de l’information contextuelle. Schilit et Theimer (Schilit et Theimer, 1994) se basent sur ce formalisme pour modéliser des informations de contexte tel que la localisation. Cette représentation est également adoptée par le Context Toolkit (Salber et al., 1999) (Dey, 2000). Les approches de modélisation constituée des paires clé-valeur se caractérisent par leur simple représentation, leur gestion facile des paires (dans le cas d’un nombre raisonnable de paire) et leur facilité de stockage. La simplicité des pairs clé-valeur peut être un avantage d’un point de vue gestion, mais ils représentent un inconvénient majeur lors de l’interprétation sémantique et si le critère d’ambiguïté est à considérer. La modélisation par les paires clé- valeur ne permet de représenter que la valeur capturée pour un élément observé de l’environnement. Avec cette simple modélisation, la qualité des informations contextuelles n’est pas prise en compte. Ce type de modélisation ne permet pas de déterminer si les informations contextuelles capturées sont incomplètes, ambiguës ou même incertains. De ce fait, l’ambiguïté des informations contextuelles ne peut pas être prise en compte par ce modèle. De plus, cette modélisation manque de capacités pour des structurations assez sophistiquées. En effet, plus le nombre de paires possibles évolue, plus difficile sera la gestion de ces paires et des aspects sémantiques liés à ces paires. Cette augmentation entraine avec elle un risque d'avoir des doublons, entrainant ainsi une incohérence entre les paires contenant des informations sur un même élément de contexte. Cette modélisation est également confrontée à un autre problème, à savoir la difficulté de sa réutilisation dans d'autres systèmes que celui d'origine, car l'interprétation des paires clé-valeur dépend de l'application. Ceci entraine un problème d’interopérabilité si les clés et les valeurs ne sont pas standardisées. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 25 2.3.2.2. Modélisation de contexte basée sur les schémas de balisage Une seconde approche soulignée dans la littérature est l'approche utilisant les modèles de schéma de balisage. Ces modèles formalisent les informations de contexte selon une structure de données fixe et hiérarchique (un arbre syntaxique). Cette structure est constituée de balises avec des attributs et de contenu permettant d'exprimer des relations plus complexes tels que les associations. Cette approche de modélisation de contexte est sérialisée dans des documents XML ou RDF (Lassila et Swick, 1999) afin d’améliorer l'interopérabilité. Ces modèles de contexte sont souvent utilisés pour représenter des informations statiques portant sur des « profils » d'entités. Ils peuvent formaliser par exemple des profils de l’utilisateur, tel que l’approche Friend-Of-A-Friend (FOAF) (Brickley et Miller, 2005), et des profils des dispositif, tels que les approche Composite Capabilities/Preferences Profile (CC/PP) (Klyne et al., 2004) (Lemlouma, 2004) (Kiss, 2010), User Agent Profile (UAProf) (WAP FORUM, 2006) et Comprehensive Structured Context Profile (CSCP) (Buchholz et al., 2004), qui ont pu atteindre un certain niveau d’expressivité par la sérialisation XML et RDF. Par exemple, le standard CC/PP (Klyne et al., 2004) est une recommandation W3C permettant de créer des « profils » décrivant non seulement les caractéristiques logicielles et matérielles d'un dispositif, mais également les préférences de l'utilisateur. Un profil CC/PP est utilisé pour personnaliser le contenu et adapter la présentation sur la base des capacités des dispositifs et des préférences des utilisateurs. Chaque profil est constitué d’un ensemble d’attributs et de valeurs associées. Le standard CC/PP est lui-même basé sur un autre standard, RDF (Manola et al., 2004). Le point important que relève l'utilisation de RDF, par rapport à l'utilisation d'un ensemble de paires clé/valeur, est la possibilité de décrire des métadonnées sur ces paires et de définir un vocabulaire commun réunissant les propriétés susceptibles d'être décrites. Plus spécifiquement, Lemlouma (Lemlouma, 2004) propose un modèle de contexte se basant sur CC/PP pour représenter le contexte d'utilisation. Ce modèle est utilisé par son architecture NAC (Negociation Adaptation Core) qui assure, dans un environnement hétérogène, la transmission au client d’un contenu dont la présentation est adaptée aux contraintes des dispositifs mobiles. Cet auteur utilise le modèle CC/PP pour décrire les capacités physiques (capacité mémoire, taille écran, etc.) et logicielles (systèmes d’exploitation, navigateur, etc.) d’un terminal. La Figure 2 illustre un exemple de modélisation de profil CC/PP, présenté par Lemlouma et al. (Lemlouma, 2004). Cet exemple décrit les capacités d'affichage d'un terminal en particulier, à travers les valeurs de l'élément HardwarePlatform (largeur 320 et hauteur 200), ainsi que la description du système d'exploitation et du navigateur Web installé dans le dispositif (élément SoftwarePlatform). Dans ce travail, Lemlouma et al. 2004 (Lemlouma, 2004) propose deux mécanismes de capture (extraction de contexte) à savoir l’extraction statique qui fait appel à une interrogation paramétrée d’une base des profils ou l’extraction dynamique qui calcule la valeur de certaines caractéristiques de l’environnement. Cet auteur propose dans ce cadre un mode d’interaction optimisé avec un répertoire de profil permettant de maintenir une base des profils CC/PP. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 26 Figure 2. Exemple de profil CC/PP (d’après (Lemlouma, 2004)) Après l’apparition de CC/PP, plusieurs autres extensions de ce standard ont été proposées. Le forum WAP, par exemple, (WAP FORUM, 2006) a proposé UAProfile come une autre approche de modélisation qui adopte la spécification de CC/PP. A l’instar de CC/PP, un profil UAProf présente une hiérarchie à deux niveaux composée d'éléments et de leurs propriétés. En revanche, contrairement à CC/PP, la spécification UAProf propose également un vocabulaire concret, représenté par un ensemble spécifique d'éléments et d'attributs, pour décrire la prochaine génération de téléphones WAP. Une autre extension de ce langage CC/PP a été proposée par Held et al. (Held et al., 2002). Cette extension nommée CSCP (Comprehensive Structured Context Profiles) ne définit aucune hiérarchie fixe, au contraire de la modélisation de CC/PP. Le CSCP s’appuie sur la flexibilité de RDF/S pour exprimer la structure naturelle des informations d’un profil requises pour l’information contextuelle. Cette modélisation de contexte est un métalangage basé aussi sur RDF et hérite de ce dernier, l’interopérabilité, la décomposition et l’extensibilité. Il est plus flexible que CC/PP concernant la structuration des documents et étend le mécanisme pour exprimer les préférences de l’utilisateur. Par rapport aux modèles de paires clé-valeur, les modèles de schéma de balisage fournissent un langage plus expressif pour structurer l'information de contexte qui peut, dans certain cas, être adapté à un domaine d'application plus spécifique. 2.3.2.3. Modélisation de contexte graphique et orientée objet L'évolution de la modélisation de contexte se poursuit avec l'émergence de modèles graphiques (ORM, CML, UML, etc.) et des modèles orientés objets, dont la force est leur structure. Une des propositions les plus pertinentes dans cette approche est le langage de modélisation de contexte (CML) (Context Modelling Language), décrit au départ par Henricksen et al. (Henricksen et al., 2002) et affiné dans des travaux ultérieurs (Henricksen et Indulska, 2004)(Henricksen et Indulska, 2006). CML est une approche de modélisation Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 27 graphique de contexte destinée à la modélisation des bases de données. CML représente une extension de la modélisation ORM (Object-Role Modeling) (Halpin, 2001) qui est une approche basée sur les « faits ». Cette approche (ORM), qui a été conçue pour la modélisation conceptuelle des bases de données, modélise les faits représentant les informations vraies ou correctes dans une application, et les types des faits définissant les types de l’information. CML fournit une notation graphique (visible sur la Figure 3) conçue pour soutenir le concepteur dans l'analyse et la spécification formelle des exigences d'une application sensible au contexte. Ce langage propose des constructions de modélisation pour : la capture des différentes classes et sources de faits, la capture des informations imparfaites en utilisant des métadonnées de qualité, la capture des dépendances entre les types des faits, la capture des historiques de certains types de faits et des contraintes sur ces historiques (Bettini et al., 2010). Les concepts modélisés fournissent une base formelle pour la représentation et le raisonnement sur certaines propriétés de l’information contextuelle (persistance, qualité, interdépendances, etc.). Chaque entité modélisée décrit un objet physique ou conceptuel, comme une personne, un dispositif ou un moyen de communication. Les attributs représentent les propriétés des entités auxquelles ils sont attachés par le biais des associations. Les associations connectent également les entités entre elles. Figure 3. Exemple de modélisation CML (d’après (Henricksen et al., 2002)) La Figure 3 illustre un exemple d’une modélisation de contexte selon le modèle CML (Henricksen et Indulska, 2006). Le modèle représente les utilisateurs (Person), leurs activités (Activity), les terminaux utilisés (Device), la localisation des utilisateurs et des terminaux (Location), les canaux de communication (Communication Channel) et les modes de communication (Communication Mode). Chaque ellipse de la Figure 3 représente un type d'objet avec la valeur entre parenthèses décrivant le schéma de représentation utilisé pour le type d'objet, tandis que chaque case représente un rôle joué par un type d'objet dans un type de fait. Ainsi les activités sont associées à un fait temporel. La localisation d'un utilisateur ou d’un dispositif est une information capturée et a une valeur de certitude associée correspondant à un indice de confiance en fonction de l’endroit de capture. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 28 La modélisation CML permet d’interroger des informations incertaines (ambiguës) en utilisant une logique à trois valeurs, en plus des assertions et des conditions complexes exprimées en utilisant une forme de logique de prédicat (Henricksen et Indulska, 2006). Le point faible de cette approche est sa modélisation des informations jugées « plates » par Bettini et al. (Bettini et al., 2010). De plus, même si CML peut être utilisé pour le développement d’une application en particulier, il ne fournit pas de support pour l’interopérabilité entre applications. Par ailleurs, nous observons dans la littérature l’émergence des modélisations de contexte basées sur les modèles orientés objets. Ces modèles peuvent être visualisés en utilisant UML. Ces diagrammes reposent sur une méthode de notation standard et générique. Grâce à sa structure générique, UML est approprié pour modéliser le contexte selon un ensemble de classes, d’objets et d’associations. Ceci est illustré, par exemple, dans Bauer (Bauer, 2003), dans lequel les aspects contextuels pertinents à la gestion du trafic aérien sont modélisés comme des extensions UML. Les approches de modélisation de contexte orientée objets tirent profit de l’encapsulation et de la réutilisation propre l’approche objets afin de couvrir une partie des problèmes liés à la dynamique de la gestion de contexte dans les environnements pervasifs. Les détails concernant le traitement des éléments de contexte sont encapsulés au niveau de l’objet, et ainsi ils sont masqués aux autres composants. Selon (Bouzy et Cazenave, 1997), la modélisation objets permet de définir le plus petit nombre de propriétés, fonctions et règles [...] afin de simplifier la représentation des connaissances dans des domaines et de systèmes très complexes. Par exemple, Kirsch-Pinheiro et al. (Kirsch-Pinheiro et al., 2004) (KirschPinheiro, 2006) proposent une approche orientée objets pour la structuration des éléments de contexte et de leurs relations. Un tel modèle est utilisé pour personnaliser le contenu fourni par des systèmes collaboratifs basés sur le Web : le contenu fourni est sélectionné selon le contexte et les préférences de l'utilisateur. L'originalité de ce modèle est la proposition d’éléments de contexte qui sont liés aux aspects collaboratifs (rôle de l'utilisateur, activités, etc.) en plus des aspects physiques (la localisation de l'utilisateur, le dispositif, etc.). Néanmoins, la capture et la maintenance de ces éléments de contexte sont en dehors du modèle. Les auteurs (Kirsch-Pinheiro et al., 2004) supposent l'existence de composants externes qui observent les éléments de contexte correspondants et alimentent ainsi le modèle. Toutefois, les modèles de contexte orientées objets demeurent peu adaptées au partage des connaissances dans un environnement ouvert et dynamique. Elles nécessitent certains accords d’exécution de bas niveau entre les applications pour assurer l’interopérabilité. 2.3.2.4. Modélisation de contexte basée sur les ontologies Dans le cadre de la modélisation de contexte, nous observons l’émergence de nouvelles approches impliquant la modélisation sémantique, en fournissant une description plus structurée et plus riche de contexte basée sur les ontologies. Les ontologies, selon Grubber (Gruber, 1993) et Uschold (Uschold et al., 1996), se basent sur l’idée de spécifier un Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 29 vocabulaire décrivant un ensemble de concepts et les relations pertinentes entre eux. L’ontologie représente ainsi une spécification explicite d’une conceptualisation. Plus spécifiquement, dans la modélisation de contexte, les ontologies fournissent une description formelle et sémantique des informations de contexte en termes d'objets, concepts, propriétés et relations. Elles sont largement acceptées pour la modélisation des informations de contexte dans le domaine de l'Informatique Pervasive. La principale raison de leur acceptation est la popularité et la maturité des langages venus du Web sémantique. Dans le Web sémantique, plusieurs langages de spécification et de description des ontologies existent, tels que RDFS/OWL (Beckett, 2004) et OWL (Horrocks et al., 2003). Le standard OWL définit une ontologie comme une collection d’informations, notamment des informations sur des classes et des propriétés (Smith et al., 2004). La modélisation à base d’ontologies exploite la puissance de la représentation et du raisonnement des logiques de description pour de multiples raisons énumérées par Bettini et al. (Bettini et al., 2010) : (i) l’expressivité du langage est utilisée pour décrire des données de contexte plus complexes qui ne peuvent pas être représentées en CC/PP ; (ii) en fournissant une sémantique formelle aux données de contexte, il devient ainsi possible de partager et/ou intégrer le contexte de différentes sources ; et (iii) les moteurs de raisonnement disponibles peuvent être utilisés afin de vérifier, d’une part, la consistance de l’ensemble des relations entre les éléments de contexte et de dériver des informations de contexte de plus haut niveau. Ainsi, à part la richesse et, d’autre part, l’expressivité des représentations sémantiques apportées par les ontologies, ces dernières se caractérisent également par leur capacité de partage de connaissance et de réutilisation. Ceci est particulièrement important dans un environnement pervasif caractérisé par son hétérogénéité et son dynamisme. De ce fait, et dans la perspective d’une modélisation de contexte plus riche et avec un fort contenu sémantique, plusieurs travaux ont choisi l'utilisation d'ontologies (Strang et LinnhoffPopien, 2004) (Chen et al., 2003) (Gu et al., 2004). Nous détaillons certains de ces travaux dans les sections qui suivent. 2.3.2.4.1. L’ontologie CONON L’ontologie de contexte CONON (CONtext ONtology) est une proposition de Wang et al. (Wang et al., 2004) laquelle repose sur les capacités de partage des connaissances et de réutilisation des ontologies afin de définir ses éléments de contexte. Wang et al. (Wang et al., 2004) se sont concentrés sur la classification et la représentation des éléments de contexte et sur le raisonnement sur ses éléments. Ils ont représenté l’ontologie CONON en OWL-DL sous une forme hiérarchique à deux niveaux. Le plus haut niveau (upper onotology) décrit l’ensemble de concepts les plus généraux et qui sont communs à tous les domaines, tels que la localisation, l’activité la personne, etc. Chacune de ces classes est associée à des propriétés afin d’exprimer ses relations avec les autres classes. Le bas niveau (domain-specific ontologies) représente une collection d’ontologies, qui définit les détails des concepts généraux et leurs propriétés dans chaque sous-domaine. Ces ontologies représentent des concepts de contexte plus spécifiques qui sont dépendants du domaine. Ce niveau étend les classes abstraites en classes plus spécifiques, permettant ainsi une certaine flexibilité par Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 30 l’extension de l’ontologie de haut niveau aux différents domaines. Figure 4. L’ontologie de contexte CONON (d’après (Wang et al., 2004)) Comme l’illustre la Figure 4, Wang et al. (Wang et al., 2004) définissent 4 concepts de base : Personne, Localisation, Activité et Entité de calcul (service, application, réseau, dispositif, etc.). Ainsi, à partir de cette ontologie de haut niveau, il est possible de développer un ensemble d’ontologies qui sont spécifiques à un domaine précis. Pour ce faire, les ontologies dépendantes du domaine peuvent étendre les classes abstraites, définies dans l’ontologie de haut niveau, avec le constructeur subClassOf du langage OWL-DL qui va permettre de définir une certaine hiérarchie des classes. Dans le cadre de ce travail, ces auteurs (Wang et al., 2004) se basent sur un ensemble de règles afin d’exprimer des situations qui sont implémentées avec des prédicats en logique de premier ordre. Ainsi, à travers la création de règles de raisonnement, des connaissances de contexte peuvent être inférées à partir des informations contextuelles de bas niveau. Concrètement, les travaux de Wang et al. (Wang et al., 2004) reposent sur Jena 2 pour le raisonnement sur les ontologies. Alors que les performances d’exécution des méthodes de raisonnement sur le contexte dépendent de la taille de l’ontologie et de la complexité des règles de raisonnement, Wang et al. (Wang et al., 2004) concluent qu’un raisonnement puissant basé sur la logique demeure un calcul assez intensif. 2.3.2.4.2. L’ontologie CoDaMoS L’approche de modélisation de contexte CoDaMoS (Context-Driven Adaptation of Mobile Services) (Preuveneers et al., 2004) a été proposée afin de représenter les informations contextuelles utilisées dans un processus d’adaptation et de personnalisation de services selon les capacités des dispositifs et les préférences de l’utilisateur. CoDaMoS représente une ontologie de contexte adaptable et extensible pour la création des infrastructures sensibles au contexte. Comme l’illustre la Figure 5, cette ontologie de contexte est conçue autour de quatre Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 31 principaux concepts : utilisateur, service, plateforme et environnement qui représentent, selon Preuveneers (Preuveneers, 2009), les aspects les plus importants des informations de contexte. A part ces concepts de base, CoDaMos inclut également des propriétés telles que la localisation courante, les préférences de l’utilisateur, les dispositifs disponibles, etc. Figure 5. L’ontologie de contexte CoDaMoS (d’après (Preuveneers et al., 2004)) Ces auteurs (Preuveneers et al., 2004) proposent des méthodes de transformation et de raisonnement afin de déduire des informations de contexte de plus haut niveau. La technique utilisée dérive de nouvelles informations contextuelles à partir des règles de dérivation et des faits existants. Ils utilisent Jena 2 pour la description des ontologies et le raisonnement. 2.3.2.4.3. L’ontologie MUSIC Reichle et al. (Reichle et al., 2008) et Paspallis (Paspallis, 2009) proposent une ontologie de contexte extensible, bien structurée et facile à comprendre. Celle-ci, à l’instar de SOUPA (Chen et al., 2004a) et CONON (Wang et al., 2004), est composée de deux niveaux hiérarchiques. D’une part, le haut niveau définit les éléments de contexte communs à tous les domaines. D’autre part, le bas niveau décrit les éléments de contexte spécifiques à un domaine en particulier. La Figure 6 illustre la modélisation des éléments de contexte proposée par Reichle et al. (Reichle et al., 2008). L’originalité de cette modélisation repose sur trois concepts de base : (1) l’entité à laquelle l’information de contexte se réfère ; (2) le scope représentant le périmètre sémantique de l’entité sous forme d’un attribut ; et (3) la représentation utilisée en tant que structure interne de l’information de contexte. Ces concepts sont par la suite décrits lors de la modélisation de l’ontologie dans différents domaines d’application. Cette ontologie de contexte entre dans le cadre du projet IST-MUSIC (IST-MUSIC, 2010), englobant une architecture extensible qui permet de collecter, de stocker, d’organiser et d’accéder aux informations de contexte. Cette architecture repose sur des plug-ins agissant comme des fournisseurs de contexte. Chaque plug-in se charge de la capture dynamique d’une catégorie d’information contextuelle correspondant au triplet ou de l’interprétation de ces informations (Paspallis, 2009). Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 32 Figure 6. La structure principale de l'ontologie de contexte MUSIC (d’après (Reichle et al., 2008) (Paspallis, 2009)) Finalement, comme nous l’avons mentionné au début de cette section, la prise en compte du contexte dans un Système Sensible au Contexte nécessite l’utilisation d’un modèle de contexte afin de formaliser et de limiter la notion de contexte. La dépendance entre les informations de contexte observées et le comportement d'un Système Sensible au Contexte peut expliquer la grande variété des modèles de contexte (Najar et al., 2009). Par ailleurs, afin de recueillir des informations de contexte, les Systèmes Sensibles au Contexte utilisent généralement des capteurs physiques et/ou logiques. Ces informations sont ensuite interprétées, traitées et mémorisées pour pouvoir réagir à l’environnement en utilisant le modèle de contexte. Ceci représente le processus de gestion de contexte qui sera détaillé dans la section suivante. 2.3.3. Gestion de contexte Le processus de gestion de contexte est le cœur des Systèmes Sensibles au Contexte. Il est constitué d’un processus itératif qui capture et diffuse les informations contextuelles ainsi que ses changements, les traite et les mémorise. De plus, il permet de prendre des décisions concernant le déclenchement ou non de certaines actions en fonction du contexte observé. Les interactions de l’utilisateur avec le système et avec l’environnement peuvent déclencher des changements du contexte. Il est donc nécessaire que ce processus de gestion de contexte prenne en compte ces changements afin que les processus d’adaptation puissent prendre ces changements en considération. Selon (Preuveneers, 2009), il y a une nécessité croissante d'applications et de services qui sont plus sensibles aux besoins des utilisateurs, mais moins dépendants de l'attention que cet utilisateur leur porte. La prise en compte d’une large gamme de dispositifs, tels que les téléphones mobiles et les tablettes, représente un facteur essentiel de réussite d'une architecture sensible au contexte. De ce fait, le système de gestion de contexte doit gérer, d’une part, l’hétérogénéité de l’environnement d’exécution, et assurer, d’autre part, l’acceptation de cette adaptation par les utilisateurs. Plusieurs architectures ont été proposées Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 33 dans la littérature : Context Toolkit (Salber et al., 1999), GAIA (Ranganathan et Campbell, 2003), Contexteur (Rey et Coutaz, 2004), COSMOS (Conan et al., 2007) (Rouvoy et al., 2008), pluggable middleware architecture (Paspallis, 2009). Plusieurs Systèmes Sensibles au Contexte se basent sur ces architectures complexes, lesquelles intègrent des sous composants responsables de la représentation, de la gestion, du raisonnement et de l’analyse des informations contextuelles. Même si ces architectures différent entre elles, nous constatons que la plupart d’entre elles se composent de trois étapes essentielles : (i) l’acquisition ; (ii) la modélisation ; et (iii) la manipulation des informations contextuelles. La première étape représente la phase d’acquisition de contexte. En se basant sur des capteurs physiques et logiques, le système est capable de capturer des informations contextuelles de nature hétérogène. Après la collecte des informations contextuelles, le système se charge de modéliser ces informations, de les traiter et éventuellement de les stocker. Cette deuxième étape représente la modélisation des informations contextuelles, dans laquelle le bon choix d’un modèle de contexte est un élément clé. Finalement, le système contrôle le niveau d’abstraction des données de contexte en interprétant les données de contexte brutes et en les transformant en information contextuelle de plus haut niveau d’abstraction. Ceci illustre la troisième étape du processus de gestion de contexte, laquelle représente la manipulation des informations de contexte en se basant sur des mécanismes de transformation et de raisonnement sur les données collectées. 2.3.3.1. Acquisition des informations contextuelles L’acquisition des informations contextuelles repose sur la capacité d’un système à capturer des informations de l’environnement et à détecter les changements effectués. En d’autres termes, elle consiste à acquérir de l’environnement les informations jugées pertinentes en fonction des besoins du système. Ceci se base sur un module d’acquisition de contexte qui (i) capture directement les informations de l’environnement intégrant l’utilisateur et le système au travers de différentes sources hétérogènes, et (ii) les envoie à la couche supérieure pour différents usages. Les sources de contexte représentent les différents capteurs utilisés. Un capteur est une source matérielle ou logicielle qui peut générer un certain type d’information contextuelle. On distingue trois types de capteurs : les capteurs physiques directement installés dans l’environnement, les capteurs virtuels qui fournissent des informations contextuelles à partir d'applications ou de services logiciels, et les capteurs logiques qui utilisent plusieurs sources d'information contextuelles pour définir une autre information (Indulska et Sutton, 2003). Plus en détails, ces capteurs sont définis comme suit : • Le capteur physique représente un dispositif matériel capable de fournir des données contextuelles de l’environnement autour de l’utilisateur et du système lui-même. Ceci peut se faire par le biais de différentes technologies. Par exemple, un capteur photodiode permet de capturer l’information sur la lumière. La localisation d’un utilisateur peut être capturée par la technologie GPS (Global Positionning System), laquelle permet de le localiser en utilisant un récepteur approprié ; Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 34 • Le capteur virtuel correspond à une application et à un service logiciel capable de fournir des informations sur le contexte. Par exemple, il est possible de capturer la tâche actuelle d’un employé en consultant son planning numérique. Ces capteurs, qui sont basés sur des composants logiciels, sont généralement moins coûteux que les capteurs physiques ; • Le capteur logique repose sur plusieurs types d’information pour proposer une information dérivée de haut niveau. Selon Chaari (Chaari, 2007), ce type de capteur peut réutiliser des capteurs physiques et virtuels pour fournir un contexte de plus haut niveau, tel que les caractéristiques sociales, économiques, les compétences, etc. Cette information, dans certains travaux, peut être acquise à travers des méthodes de raisonnement. Par exemple, le système peut analyser l’historique d’un utilisateur afin de mettre à jour ses préférences. Après avoir collecté les données contextuelles, ces informations doivent être représentées selon une structure bien déterminée, que nous présentons dans la section suivante. 2.3.3.2. Modélisation des informations contextuelles L’étape de modélisation des informations contextuelles organise et modélise les informations de contexte capturées selon le modèle de contexte choisi et peut, par la suite, les stocker dans un répertoire. Un tel répertoire de contexte permet d’assurer la persistance des informations de contexte. Pour pouvoir stocker et transmettre au reste du système les informations contextuelles, il est impératif de définir un modèle de contexte pour les décrire. Ainsi, un modèle de contexte est requis pour pouvoir l'utiliser dans le système. En d’autres termes, le choix du modèle de contexte est l’élément clé de cette étape qui peut jouer un rôle central dans le traitement et l’interprétation de ces informations. La modélisation des informations contextuelles est présentée plus en détails dans la section 2.3.2. 2.3.3.3. Manipulation des informations contextuelles Les données de contexte capturées lors de la première étape sont souvent des données brutes. Les capteurs interrogés remontent le plus souvent des données techniques qui ne sont pas appropriées à être utilisées par le concepteur du système (Baldauf et al., 2007). L’étape de manipulation consiste à traiter ces données afin de déduire et d’inférer des données de plus haut niveau. Les capteurs collectent les données de contexte de l’utilisateur et du système lui même. Ces données représentent des informations contextuelles qui sont directes, explicites et de bas niveau (e.g. la localisation de l’utilisateur est exprimée sous forme de longitude et latitude). Le manipulateur de contexte (ou interpréteur de contexte) est responsable du raisonnement et de l’interprétation de ces données et d’en déduire/inférer des informations contextuelles qui sont implicites, indirectes et de plus haut niveau. Ces informations contextuelles de haut niveau rajoutent de la connaissance sur le contexte acquis. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 35 L’interprétation des données de contexte de bas niveau peut être faite par plusieurs opérations comme : opérations de calcul et de transformation, opérations de raisonnement, etc. Nous pouvons séparer ces opérations en deux catégories distinctes : • La transformation de contexte : ce type d’opération permet de modifier la représentation de certaines informations de contexte en se basant sur des méthodes de classification, des calculs mathématiques, etc. Par exemple, la représentation d’une localisation exprimée sous forme de longitude et latitude peut être transformée en représentation sous forme d’adresse postale, plus significative, en utilisant des méthodes de transformation (Preuveneers, 2009). D’autres méthodes de transformation peuvent se baser sur des méthodes de calcul mathématique, telle que la transformation d’une représentation de la température exprimée en degré Celsius C° en une représentation exprimée en Fahrenheit F°. • Le raisonnement sur le contexte : cette opération permet de dériver de nouvelles connaissances sur le contexte en se basant sur des faits existants et sur des règles de dérivations (Preuveneers, 2009). Le raisonnement sur le contexte peut combiner plusieurs règles de dérivation permettant de raisonner sur plusieurs informations contextuelles afin d’en déduire d’autres plus expressives ou plus précises par rapport au système. Dans ce sens, il est possible, par exemple, de déterminer l’activité courante de l’utilisateur en combinant plusieurs informations contextuelles, telle que le planning numérique de l’utilisateur, sa localisation, etc. Finalement, face à la grande variété des modèles de contexte que nous avons détaillés dans la section 2.3.2 et aux différents moyens de capture et de gestion de contexte, nous proposons dans la section suivante, un cadre permettant d’analyser ces différents modèles de contexte. 2.3.4. Cadre d’analyse et de comparaison des modèles existants Selon Mostéfaoui et al. (Mostefaoui et al., 2004), la pertinence des informations contextuelles diffère d’un domaine à un autre selon leur utilisation. Cette affirmation peut être observée dans les différents travaux de modélisation de contexte qui ont été présentés dans la section 2.3.2, dans lesquels divers éléments de contexte (profil de l’utilisateur, préférences de l’utilisateur, localisation, dispositif, etc.) sont observés pour différentes raisons (découverte et configuration de services, personnalisation et adaptation du contenu, etc.). L’immense diversité présente par les modèles de contexte, autant en termes d’éléments de contexte observés, que de formalismes utilisés, rend souvent difficile leur évaluation. Nous proposons ainsi, dans le cadre de cette thèse, un cadre qui analyse et compare les différents modèles de contexte. Ce cadre a comme objectif d'aider à la compréhension et à l’analyse de ces modèles. Il permet d'étudier et de classifier les modèles de contexte, selon différents critères, dans la perspective d’aider le concepteur à choisir le modèle qui lui convient ou de le guider à en déduire un nouveau modèle à partir de l’existant. Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 36 2.3.4.1. Les critères d’analyse des modèles de contexte Les différents critères d’évaluation que nous proposons sont utilisés pour l’analyse des modèles de contexte. Ces critères sont choisis afin de mettre en avant les caractéristiques de chaque modélisation, aidant ainsi l’utilisateur à faire son choix. Ces critères sont : • Information : Quelles sont les informations de contexte qui doivent être observées ? Ce critère permet d’identifier les informations les plus pertinentes qui vont être observées et ensuite utilisées par une application particulière. Ces informations forment le contexte qui doit être modélisé ; • Action : Quelles sont les actions prises par le système sur la base des informations contenues dans un modèle de contexte ? Ce critère représente l’ensemble d'actions qui peuvent être entreprises par le système s’appuyant sur le modèle de contexte. Il montre comment le modèle de contexte est utilisé ; • Structure (Str) : Comment cette information est-elle représentée ? Ce critère représente la structuration interne de l'information contextuelle. Il permet de mesurer le degré de formalisation des informations contextuelles ; • Capture (Capt) : Quelle est la méthode utilisée pour capturer l’information contextuelle ? Pour chaque application, afin d'obtenir des informations sur le contexte d'utilisation, il faut avoir une stratégie de capture qui détecte les informations contextuelles et notifie le reste du système lorsqu’il y a un changement ; • Maintenance (Maint) : Comment pouvons-nous mettre à jour cette information et garder sa pertinence ? L'objectif de ce critère est de préciser les techniques utilisées pour la mise à jour de l'information contextuelle et de définir les stratégies utilisées pour cela ; • Raisonnement (Rais) : Est-ce qu’il existe un moteur de raisonnement capable d'interpréter les informations de contexte ? Ce critère permet de vérifier si des techniques sont mises en place afin de dériver de la connaissance contextuelle de haut niveau à partir des données de contexte de bas niveau ; • Expressivité (Exp) : Est-ce que le modèle peut représenter des informations complexes ? Ce critère mesure la capacité de représenter des entités et des relations complexes. Ceci va permettre d’améliorer l’interopérabilité qui demande une compréhension commune de l’information obtenue. Ce critère est généralement en conflit mutuel avec l'efficacité du raisonnement ; • Efficacité (Eff) : Est-ce qu’il y a un équilibre entre l’expressivité du modèle de contexte et la complexité du traitement mis en place ? Ce critère permet de mesurer la performance d'un type de modèle de contexte en termes de quantité d'informations qui doit être traitée et de complexité du modèle de contexte lui-même ; • Ambiguïté et Incomplétude (Ambig) : Est-ce que les informations de contexte capturées sont de bonne qualité ? Ce critère permet de déterminer si les informations contextuelles capturées sont incomplètes, ambiguës ou incertaines. Il permet de mesurer la qualité et la pertinence des informations de contexte ; Systèmes!d’Information!Pervasifs!et!la!notion!de!contexte 37 • Effort de Programmation (Prog) : Est-ce que les développeurs ont fourni un effort remarquable pour la définition et l’utilisation d’un modèle de contexte particulier au sein de l'application ? Ce critère reflète l’effort dépensé par les développeurs afin de mettre en place leur modèle de contexte. 2.3.4.2. Analyse comparative des modèles de contexte Les modèles de contexte que nous avons étudiés dans la section 2.3.2 ont d'abord été classifiés selon leur approche de modélisation, avant d’être analysés selon les critères précédemment énoncés. Un aperçu de cette analyse comparative est illustré au Tableau 1. Pour les deux critères information et action, nous avons décrit textuellement les informations contextuelles utilisées et les actions entreprises faisant appel au modèle de contexte pour chaque approche. Les autres critères sont évalués par un indicateur d’évaluation qualitatif : (++) score élevé ; (+) score acceptable ; (-) score médiocre. Par exemple, le critère de structure indique le degré de formalisation du modèle de contexte. Ainsi, nous indiquons (++) si l'information est très structurée, comme dans les modèles basés sur les ontologies ; (+) si elle est semi-structurée, généralement XML ou autres modèles orientés objets ; ou (-) si elle n'est pas structurée, comme dans les modèles clé-valeur. Le critère de capture se réfère au degré d'automatisation du processus d'acquisition de contexte. Nous indiquons (++) si l'information est capturée périodiquement ; (+) si elle répond aux changements de contexte suite à une approche basée sur les événements ; ou (-) si elle est acquise manuellement. Le critère de maintenance évalue la stratégie utilisée pour mettre à jour les informations de contexte. Nous indiquons (++) si l'information est maintenue automatiquement ; (+) si elle est semi-automatique (sur demande) ; ou (-) si elle est maintenue manuellement. Le critère de raisonnement montre une évaluation des techniques de raisonnement. Nous désignons par (++) le fait qu’elle dispose d'un moteur de raisonnement ; (+) qu’elle ait un mécanisme de raisonnement ad-hoc lequel est codé en dur ; ou (-) qu’elle dispose d'un mécanisme de raisonnement assez faible. De même, les critères d’expressivité, d’efficacité, d’ambiguïté et d’effort de programmation sont évalués de la même façon. Ils sont évalués (++) pour les modèles qui sont les plus expressifs et assurant un niveau élevé d’interopérabilité, qui sont les plus efficaces, qui offrent le moyen de détecter et de gérer l’ambiguïté et l’incomplétude des informations contextuelles, et qui ne demandent pas beaucoup d’effort de programmation pour les réutiliser. Ils sont ainsi évalués (-) pour les modèles les moins expressifs, les moins efficaces, qui ne gèrent pas la qualité des données de contexte et qui demandent un effort remarquable de programmation. Systèmes(d’Information(Pervasifs(et(la(notion(de(contexte 38 Tableau 1. Cadre d'analyse et de comparaison des modèles de contexte (Najar et al., 2009) Approche de modélisation de Contexte Information Action Str Capt Maint Rais Exp Eff Ambig Prog Approche Schilit (Schilit et al., 1994) - Localisation - Identité des personnes et objets à proximité - Sélection approximative - Reconfiguration automatique de contexte - ++ ? - - ++ - ++ Approche CC/PP (Lemlouma, 2004) - Utilisateur - Terminal - Adaptation de la présentation du contenu pour les dispositifs mobiles + - - - + + - + Approche Kirsch-Pinheiro (Kirsch-Pinheiro, 2006) - Info physique de l’utilisateur -Info collaborative de l’utilisateur - Adaptation du contenu d’un utilisateur mobile dans un groupe + - - + + + + ++ Approche CML (Henricksen et al., 2002) (Henricksen et Indulska, 2006) - Préférence utilisateur - Situation utilisateur - Prise de décision dépendante du contexte et des préférences - Invocation automatique des actions selon changement de contexte + + - - ++ - + + Approche MUSIC (Reichle et al., 2008) - Utilisateur - Dispositif - Environnement - Entité de calcul - Découverte de services - Composition de services ++ ++ ++ + ++ - ++ + Systèmes(d’Information(Pervasifs(et(la(notion(de(contexte 39 Le modèle de contexte proposé par Schilit et al. (Schilit et al., 1994), par exemple, est structuré selon un formalisme clé-valeur, présentant une structuration assez simple, laquelle ne permet pas des structures complexes (-). Les informations de contexte incluent la localisation et l’identité des personnes et des objets à proximité. Le système déploie différentes technologies pour capturer périodiquement la localisation des objets mobiles, le plus souvent la localisation des personnes au voisinage (++). Ce modèle de contexte ne se base que sur des mises en correspondance (matching ) exactes entre les valeurs capturées, représentant ainsi un modèle de contexte avec un niveau de raisonnement très faible (-), mais qui gagne en terme d’efficacité (++). De plus, l'interprétation dans les modèles de contexte utilisant une structure simple de clé-valeur dépend de l'application, ce qui signifie que l’interopérabilité devient un problème si les clés et les valeurs ne sont pas standardisées, affectant ainsi l’expressivité de ce modèle (-). En outre, la simplicité des paires clé-valeur ne permet pas de gérer l’ambiguïté des informations contextuelles (-), mais présente une certaine facilité en terme d’effort de programmation (++). Nous analysons de même les travaux de Lemlouma (Lemlouma, 2004) qui propose un modèle de contexte se basant sur la structure CC/PP (+) pour décrire sous forme de profil les préférences de l’utilisateurs et les capacités physiques et logicielles d’un terminal. Cet auteur utilise le modèle CC/PP basé sur RDF permettant ainsi d’améliorer le niveau d’expressivité de ce modèle (+) et d’améliorer l’interopérabilité entre les différents terminaux et ressources. De plus, le modèle proposé repose sur un mécanisme manuel de capture (-) dans lequel le dispositif client donne, au départ, une description de ses caractéristiques qui peut être, par la suite complétée, par le système. Néanmoins, les informations contextuelles ou ses changements ne sont pas capturées automatiquement. Les profils contenant les informations de contexte sont mis à jour régulièrement, mais manuellement, afin d’intégrer de nouveaux terminaux et logiciels ou pour changer les préférences des utilisateurs (-). En outre, dans ses travaux, Lemlouma (Lemlouma, 2004) ne supporte pas de mécanismes de raisonnement et d’interprétation (-). De plus, cet auteur traite l’ambiguïté et l’incomplétude des informations contextuelles exclusivement au niveau de l’application (+). L’approche proposée par Kirsch-Pinheiro et al. (Kirsch-Pinheiro et al., 2004), quant à elle, repose sur une structure de modélisation orientée objets (+) pour la description des éléments de contexte, telle que les informations physiques (la localisation de l'utilisateur, le dispositif, etc.) et collaboratives (rôle de l'utilisateur, activités, etc.), dans le but de personnaliser le contenu fourni par des systèmes collaboratifs basés sur le Web. Néanmoins, la capture et la maintenance de ces éléments de contexte sont considérées comme extérieures au modèle et ne sont pas prises en compte (-). Par ailleurs, ces auteurs proposent également une méthode de raisonnement ad-hoc (+), à travers un ensemble de mesures de similarité permettant de comparer les éléments de contexte et leurs relations. Comparée à d’autres modèles, cette approche gagne en expressivité (+), avec cette nouvelle modélisation orientée objets, mais demeure peu adaptée au partage des connaissances dans un environnement ouvert et dynamique. De plus, elle nécessite certaines normes d’exécution de bas niveau entre les applications pour assurer l’interopérabilité. Enfin, ce modèle de contexte offre la possibilité de représenter une information contextuelle incomplète ou même ambiguë (+). Systèmes(d’Information(Pervasifs(et(la(notion(de(contexte 40 Nous continuons cette étude comparative par l’analyse du modèle de contexte CML, proposé par (Henricksen et al., 2002), lequel profite de la structuration de la modélisation graphique (+). Henricksen et al. (Henricksen et al., 2002) gèrent la capture de contexte de diverses sources en mettant en place un composant de contexte qui collecte les informations dès qu’il y a un changement (+). De plus cette modélisation permet l’interprétation des informations contextuelles, à travers de conditions simples, notamment l’évaluation des assertions ainsi que des requêtes SQL. Pour traiter des conditions plus complexes, Henricksen et al. (Henricksen et al., 2002) définit une grammaire pour la formulation des situations qui sont exprimées en utilisant la logique des prédicats (+). Par ailleurs, l’implémentation de ce modèle conduit à un code plus propre qu'un modèle non structuré (+), mais à des applications plus difficiles à maintenir (-). En outre, CML fournit également un soutien plus complet à la saisie et à l'évaluation de l'information imparfaite et ambiguë que d’autres approches de modélisation de contexte (+). Reichle et al. (Reichle et al., 2008) ont contribué avec la proposition du modèle de contexte utilisé dans le projet IST-MUSIC (IST-MUSIC, 2010). Cette ontologie pour assurer l’adaptation de systèmes à base de composants OSGI, en prenant en considération les éléments de contexte énumérés. Le modèle, basé sur une ontologie, est extensible, bien structuré et facile à comprendre (++), composé de deux niveaux hiérarchiques, afin de faciliter sa réutilisation dans divers domaines. L’acquisition de contexte sur la plateforme MUSIC repose sur des plug-ins de contexte (Paspallis, 2009) agissant comme des fournisseurs de contexte qui capturent dynamiquement des informations contextuelles (++) et les modélisent sémantiquement. Ces plug-ins de contexte assurent aussi l’interprétation et le raisonnement sur les informations contextuelles, afin de dériver de la connaissance de plus haut niveau, en se basant sur d’autres plug-ins (+). De plus cette ontologie se caractérise principalement par son expressivité et son interopérabilité facilitant ainsi son usage et ses modifications (++) mais impactant ainsi son efficacité en terme de complexité de traitement et de quantité d’informations à traiter (-). A la fin de cette analyse comparative des différents modèles de contexte, nous concluons que, même si d'autres modèles pourraient aussi être adaptés à certaines applications, les approches basées sur l'ontologie semblent en général être les plus prometteuses en termes de raisonnement et d’expressivité, mais l'impact sur l’efficacité et la complexité de programmation sont les deux principaux obstacles à franchir. Dans un environnement pervasif, la notion de contexte, que nous avons explorée dans les sections précédentes, représente les informations capables d’être observées dans cet environnement. Ainsi, les Systèmes d’Information intégrés dans un tel environnement pervasif se doivent de prendre en considération cette notion de contexte (cf. section 2.3.1) afin de s’adapter à la dynamique de l’environnement. En d’autres termes, ils se doivent d’être sensibles au contexte (cf. section 2.2.2). Cette nouvelle classe de SI, qui s’intègre dans cet environnement pervasif, est fondée sur cette notion de contexte et de sensibilité au contexte afin d’assurer, d’une part, la gestion de l’hétérogénéité et de la dynamique de l’environnement, et d’autre part, la transparence de ce système. De plus, afin de représenter Systèmes(d’Information(Pervasifs(et(la(notion(de(contexte 41 les informations contextuelles capturées et de s’adapter en conséquence, ces systèmes doivent définir au préalable un modèle de contexte, comme nous l’avons discuté dans la section 2.3.2. Dans la section suivante, nous présentons cette nouvelle vision des SI, présentée sous le nom de Systèmes d’Information Pervasifs (SIP). 2.4. LES SYSTEMES D’INFORMATION PERVASIFS ET CARACTERISTIQUES Au sein des organisations, les Systèmes d’Information (SI) sont directement impactés par l’arrivée de l’Informatique Pervasive. La mobilité qu’apportent ces nouvelles technologies a étendu les SI bien au-delà des frontières physiques de l’organisation. De ce fait, émerge une nouvelle classe de Systèmes d’Information, les Systèmes d’Information Pervasifs (SIP) (Birnbaum, 1997). Cette nouvelle génération de SI est le fruit d’un important changement dans la manière dont nous travaillons et dont les technologies nous supportent dans notre quotidien. Nous passons d’un modèle statique, dans lequel les travailleurs n’interagissent avec un processus métier que durant leur « temps de travail » et dans des circonstances bien définies (e.g. assignés à leurs ordinateurs de bureau), à un modèle dynamique, assuré par l’évolution des réseaux sans fil et des dispositifs mobiles, dans lequel les travailleurs se caractérisent par leur mobilité. Les Systèmes d’Information Pervasifs (SIP) représentent une classe émergente de SI dans laquelle les technologies de l’information (IT) sont graduellement intégrées à l’environnement physique (Kourouthanassis et Giaglis, 2006). A l’inverse des SI traditionnels, les Systèmes d’Information Pervasifs s’intègrent progressivement à l’environnement physique, passent à l’arrière-plan, gardent une trace des activités des utilisateurs, analysent les informations et interviennent lorsque cela est nécessaire, afin de mieux répondre aux besoins de ces utilisateurs (Kourouthanassis et Giaglis, 2006). Il s’agit d’intégrer l’informatique dans l’environnement physique de manière invisible, telle que soutenue depuis plusieurs années par l’Informatique Pervasive (Weiser, 1991). Les Systèmes d’Information Pervasifs se veulent alors une réponse à cette importante évolution des SI. Selon (Kourouthanassis et Giaglis, 2006), les SIP revisitent la manière dont nous interagissons avec les SI : le paradigme d’interaction passe du simple bureau classique et complétement maîtrisé à un ensemble de dispositifs multiples, très hétérogènes et intégrés dans un environnement hautement dynamique. Toujours selon ces auteurs, les SIP se caractérisent par l’hétérogénéité des terminaux qui permettent d’accéder à leurs services. Ces terminaux peuvent être eux-mêmes mobiles ou intégrés directement à l’environnement. A l’opposé des SI traditionnels, dans lesquels les dispositifs d'accès sont stationnaires, les SIP supportent des dispositifs mobiles qui peuvent être transportés partout par les utilisateurs. Néanmoins, les SIP doivent ainsi gérer cette hétérogénéité et veiller à la bonne interaction entre l'utilisateur et l'environnement physique (Kourouthanassis et Giaglis, 2006). En d’autres termes, les SIP revoient la façon dont nous interagissons avec les ordinateurs par l'introduction de nouvelles modalités d’accès à ces systèmes. Selon (Kitsios et al., 2010), les Systèmes(d’Information(Pervasifs(et(la(notion(de(contexte 42 SIP ont pris du recul par rapport aux interactions originales d’un utilisateur avec son SI et ils considèrent les dispositifs comme entièrement intégrés, d’une manière transparente, à l’environnement physique. Avec cette évolution, le SI traditionnel de bureau (DSI - Desktop Information System) est considéré alors comme un des dispositifs d’accès mis à disposition de leurs utilisateurs. Par conséquent, des interactions continues sont rendues possibles par ces dispositifs, qu’ils soient mobiles ou intégrés dans l’environnement physique (Kourouthanassis et Giaglis, 2006). En découle ainsi la possibilité d’offrir aux utilisateurs des nouveaux services innovants, mais également un système qui serait capable de percevoir son contexte d’utilisation, de gérer la mobilité des utilisateurs et des services, afin de mieux s’accommoder aux besoins et aux désirs de ces utilisateurs. Les SIP s’opposent aux SI traditionnels en s’intégrant de plus en plus dans le monde physique. Les SI traditionnels intègrent l’intelligence uniquement à l’intérieur du système. Dans le cas des SIP, l'intelligence du système ne réside plus uniquement dans l'ordinateur, mais elle est aussi intégrée dans le monde physique (Kourouthanassis et al., 2008). Au-delà de l’hétérogénéité, l’environnement dans le quel s’intègre les SIP se caractérise également par sa dynamique. Selon (Kourouthanassis et Giaglis, 2006), les SIP s’inscrivent dans un environnement particulièrement dynamique, composé d’une multitude d’artefacts capables de percevoir le contexte de l’utilisateur et de gérer sa mobilité. Il s’agit, par opposition aux environnements de bureau qui caractérisent traditionnellement les SI, d’un environnement hautement dynamique, dont l’état varie en fonction non seulement des actions et de la mobilité de leurs utilisateurs, mais également de l’état de ses éléments, eux-mêmes très variables. Selon (Hagras, 2011), la nature dynamique des environnements pervasifs leur impose une capacité d’adaptation à des conditions d’opération changeantes et à des utilisateurs dont les préférences et le comportement sont également variables. Quelques soient les variations auxquelles il est exposé, un système opérant sur un tel environnement se doit d’être adaptable. En d’autres termes, un système dit pervasif doit être capable d’accomplir les fonctionnalités sollicitées, malgré les changements dans les conditions environnantes ou dans l’état du système (Römer et Friedemann, 2010). Ainsi, la dynamique des environnements pervasifs apporte aux SIP une autre caractéristique importante : la sensibilité au contexte (cf. section 2.2.2). Plusieurs auteurs (Vanrompay et al., 2011) (Baldauf et al., 2007) soulignent le rôle central de la sensibilité au contexte dans les systèmes pervasifs. Pour (Kourouthanassis et al., 2008), contrairement aux SI traditionnels, dans lesquels une réponse du système est précédée d’une action de l’utilisateur, les SIP doivent être proactifs, réagissant aux stimuli de l’environnement. Ils doivent s’adapter aux préférences de l’utilisateur et au contexte d’utilisation. A l’opposé, ces nouveaux Systèmes d’Information Pervasifs se distinguent également des applications et des plateformes sensibles au contexte, traditionnellement proposées dans le domaine de l’Informatique Pervasive (Baldauf et al., 2007) (Preuveneers et al., 2009) (Geihs et al., 2009). Nous discuterons ces applications dans le prochain chapitre (cf. chapitre 3) qui s’intéresse aux systèmes orientés services sensibles au contexte. Contrairement à ces derniers, Systèmes(d’Information(Pervasifs(et(la(notion(de(contexte 43 dans lesquels le caractère dynamique et l’autogestion sont des caractéristiques essentielles, les SIP se doivent de rester maîtrisables et maîtrisés. En réalité, cette sensibilité au contexte ne doit pas se faire au dépend de la transparence. Selon (Dey, 2011), lorsque les utilisateurs ont des difficultés à former un modèle mental de l’application, ils ont moins envie de l’adopter et de l’utiliser. Malgré les capacités d’adaptation au contexte et un comportement proactif, les SIP doivent rester compréhensibles à leurs utilisateurs, d’autant plus qu’il s’agit, avant tout, des Systèmes d’Information. Les utilisateurs doivent garder leur confiance en ces systèmes qui sont là pour répondre à leurs besoins. Les SIP doivent ainsi faire coexister deux mondes aux antipodes. Ils se doivent d’être sensibles au contexte, de prendre en compte le caractère dynamique des environnements pervasifs, sans pour autant perdre complétement le caractère maîtrisé et prédictible propre aux SI. En tant que Systèmes d’Information, les SIP doivent être conçus afin de mieux satisfaire les besoins de leurs utilisateurs. Leur objectif est de rendre ces utilisateurs plus performants par une meilleure prise en compte de l’environnement pervasif dans lequel ils se trouvent. Il s’agit de répondre aux besoins des utilisateurs de manière adaptée, quelques soient les conditions d’usage. La satisfaction de l’utilisateur est une priorité pour les SIP. Contrairement aux SI traditionnels, dans lesquels c’était à l’utilisateur de s’adapter au système, les SIP doivent désormais prendre en compte l’environnement et le contexte d’utilisation afin de mieux s’adapter et de fournir aux utilisateurs le service qui correspond au mieux à ses besoins et à son contexte. Cependant, cette adaptation ne doit pas se faire à n’importe quel prix. Même s’il doit tirer profit de l’environnement dynamique et des opportunités qu’un tel environnement peut lui offrir, le comportement d’un SIP, avec les services et les fonctionnalités qu’il offre à ses utilisateurs, doit rester prédictible, afin d’assurer la gouvernance de ces systèmes et la confiance des utilisateurs en eux. De plus, certains auteurs, tels que Kourouthanassis et al. (Kourouthanassis et al., 2008), considèrent ainsi le degré d’omniprésence (pervasiveness) d’un SIP donné. Ces auteurs définissent l’omniprésence comme la mesure dans laquelle un Système d’Information est constitué d'artefacts technologiques interconnectées, diffusés dans l’environnement qui les entoure, qui travaillent ensemble pour soutenir de façon ubiquitaire les tâches et les objectifs de l'utilisateur à un niveau, organisationnel, de groupe, ou individuel d'une manière sensible au contexte. En se basant sur cette définition, les SIP s’organisent selon trois dimensions principales : (i) la sensibilité au contexte représente la capacité à percevoir l'information contextuelle en observant l'utilisateur, le système et l'environnement dans le but d'adapter ses fonctionnalités d'une façon dynamique et proactive ; (ii) l’ubiquité représente la capacité à fournir aux utilisateurs un accès continu aux ressources d'information indépendamment de leur localisation à l'intérieur des limites du système ; et (iii) la diffusion représente la capacité d’un système à intégrer des éléments invisibles à l'utilisation dans l'environnement physique, et dont l'interaction se fait par le biais d'interfaces physiques. Afin d’assurer ces trois dimensions, les Systèmes d’Information Pervasifs (SIP) doivent faire face à un ensemble de challenges, dont : Systèmes(d’Information(Pervasifs(et(la(notion(de(contexte 44 • l’adaptabilité : les SIP doivent s’adapter aux changements de l’environnement afin de gérer sa dynamique. S’ils souhaitent augmenter leur utilisabilité et leur efficacité, ces systèmes sont amenés à adapter leur fonctionnement par la prise en compte du contexte environnant. Comme l'environnement d'exécution change en raison de la mobilité de l'utilisateur et du dynamisme de l’environnement, le système doit changer son comportement pour prendre en considération cette mobilité et ce dynamisme. Ainsi, les SIP doivent désormais s’adapter à l’environnement et au contexte de l’utilisateur en toute transparence afin de lui offrir les services les plus appropriés ; • l’interopérabilité : un environnement pervasif intègre divers types de dispositifs informatiques, de réseaux et d’entités logicielles et matérielles. Tous ces éléments se caractérisent par leur hétérogénéité. Ainsi, en raison du grand nombre de services hétérogènes offerts par l’environnement pervasif, l'interopérabilité est devenue une nécessité à tous les niveaux pour les SIP. Par exemple, la découverte et la composition de services au sein de ces systèmes doivent pouvoir tirer profit des fonctionnalités et des services de différentes natures, et pour cela ils doivent être interopérables ; • la sécurité : dans le cadre d’un SI, les mécanismes de sécurité représentent un défi important. Un SIP demeure un système fermé, qui nécessite un certain niveau de maîtrise et de contrôle. Toutefois, l’immersion des fonctionnalités d’un SI dans l’environnement pervasif expose celui-ci à un risque de perdre le contrôle et la maitrise du SI dans un tel environnement hétérogène et hautement dynamique. En effet, un comportement totalement dynamique, avec une prise en compte opportuniste des ressources et des services disponibles dans l’environnement et l’autogestion des services offerts, peut être vu comme une menace pour le SI. Le défi ici est de fournir les mécanismes de sécurité adéquats pour contrôler intelligemment l'accès aux ressources informatiques et aux services offerts par le SIP, sans pour autant perdre la confiance des utilisateurs. Toutefois, nous observons à travers la littérature, que cette nouvelle notion de SIP demeure une vision conceptuellement étudiée mais qui n’est pas mise en place par de vrais formalismes de conception, ni d’architecture pour les réaliser. Ceci ouvre de nouvelles opportunités pour traiter les SIP et les mettre en place dans un environnement pervasif et de les concevoir de telle sorte qu’ils soient acceptés par les DSI. 2.5. CONCLUSION Dans le cadre de ce premier chapitre de l’état de l’art, nous avons introduit l’émergence de l’Informatique Pervasive. Celle-ci a pour but de rendre accessible toutes sortes de services, n'importe où et à tout moment. Cette volonté d'affranchir l'utilisateur des contraintes actuelles d'utilisation d'un ordinateur lui rend sa liberté d'actions, notamment sa liberté de mobilité. Au cœur de l’Informatique Pervasive se trouve la notion de sensibilité au contexte. Cette notion représente la prise en compte du contexte d’utilisation lors du développementSystèmes(d’Information(Pervasifs(et(la(notion(de(contexte 45 d’applications qui fournissent, en conséquence, des solutions mieux adaptées à leur usage. Nous avons signalé, que dans ce cadre, le contexte représente un élément clé dans les mécanismes d’adaptation prônés par ces systèmes dits sensibles au contexte. A travers les différentes définitions discutées dans ce chapitre, nous avons souligné que la notion de contexte est une notion très large et vague, qui peut varier selon le domaine, par exemple. Ainsi, face à ces différentes définitions de contexte, se pose la question de la modélisation de contexte afin de pouvoir le représenter et le limiter. Différents modèles de contexte ont été présentés allant des plus simples modèles à paires clés-valeurs, aux plus expressifs modèles basés sur les ontologies. Nous avons ainsi constaté que les ontologies sont de plus en plus utilisées. Ceci est principalement dû aux propriétés formelles et à l’expressivité des ontologies, ainsi qu’aux moteurs d’inférence associés. Les ontologies permettent également d’assurer l’interopérabilité souhaitée au niveau sémantique, et donc la réutilisation de ces modèles avec une certaine cohérence sémantique. Ceci facilite donc la gestion de contexte. Ensuite, nous observons que cette Informatique Pervasive a impacté l’usage des Systèmes d’Information (SI) existants et a fait apparaître une nouvelle génération de SI, nommé les Systèmes d’Information Pervasifs. En effet, la dernière décennie a été remarquablement marquée par le changement dans la manière dont nous travaillons. Les différents travaux de recherches menés dans cette thématique ont montré que la mobilité qu’apportent les nouvelles technologies a étendu les SI bien au-delà des frontières physiques de l’organisation. Par la prise en compte de la notion de contexte et de sensibilité au contexte, les SIP répondent à la problématique d’adaptation à l’environnement physique dans lequel ils s’intègrent et qui se caractérise par sa haute dynamique et son changement fréquent. Toutefois, ces SIP doivent faire face à d’autres problématiques à savoir la gestion de l’hétérogénéité et la compréhension des besoins des utilisateurs afin d’assurer une certaine transparence nécessaire dans le cadre des SIP. Nous abordons ces sujets dans le chapitre suivant de l’état de l’art. Systèmes(d’Information(Pervasifs(et(l’orientation(service 46 Chapitre 3. SYSTEMES D’INFORMATION PERVASIFS ET L’ORIENTATION SERVICE 3.1. INTRODUCTION Depuis des années, la notion de service a été largement étudiée dans la littérature. Cette notion peut être vue, d’une manière générale, comme étant des composants logiciels qui sont désignés de telle sorte qu’ils supportent des demandes métiers évolutives. Cette notion de service n’a cessé d’évoluer avec l’apparition des services Web et du Web sémantique permettant de garantir un meilleur niveau d’interopérabilité, d’intégration, de compréhension et d’automatisation. Cette évolution a encouragé d’autres chercheurs à étudier la notion de services sous un angle plus proche de l’utilisateur. Ceci a fait apparaître les services sensibles au contexte, qui doivent s’adapter aux changements de l’environnement, et les services intentionnels, qui décrivent les intentions qu’ils peuvent satisfaire. Dans le cadre des Systèmes d’Information Pervasifs (SIP), l’orientation service permet de répondre au besoin de gestion de l’hétérogénéité technique de l’environnement dans lequel évoluent ces systèmes et des actions que ces systèmes proposent afin de satisfaire les besoins des utilisateurs. En effet, l’indépendance des services par rapport aux aspects technologiques et à leurs implémentations est un des moyens permettant de masquer l’hétérogénéité technologique des environnements pervasifs. Avec l’évolution des SI vers les SIP, de nouveaux challenges sont apparus ou ont pris une forme différente. En effet, afin de construire un SIP qui prend en considération à la fois le caractère dynamique des environnements pervasifs et le caractère contrôlé et maîtrisé des SI, il est important de répondre à certains défis, tels que l’adaptabilité, la découverte, la composition et la prédiction dynamique des services. Dans le cadre de cette thèse, nous soulevons la problématique de la découverte et de la prédiction de service dans le cadre d’un SIP transparent, proactif et centré utilisateur. Ce chapitre présente un état de l’art sur l’orientation service. Nous commençons par présenter la notion de services et l’émergence des visions techniques, sémantiques et intentionnelles de cette notion. L’orientation service, selon nous, est un concept clé dans la conception des SIP qui doivent faire face à un ensemble de défis. Nous présentons, par la suite, les différents défis auxquels un SIP orienté service doit répondre. Nous nous focalisons sur deux d’entre eux : la découverte de services et la prédiction de services. Nous attribuons une attention particulière aux différentes approches de découverte de services apparues dans la littérature. Nous commençons par analyser quatre types d’approches, à savoir : (i) la découverte de services sémantiques ; (ii) la découverte de services sensibles au contexte ; (iii) la découverte de services intentionnels ; et (iv) la découverte de services sensibles au contexte et intentionnels. Par la suite, nous nous concentrons sur deux approches de prédiction de Systèmes(d’Information(Pervasifs(et(l’orientation(service 47 services, à savoir : (i) la prédiction de contexte ; et (ii) la recommandation de services selon le contexte. Finalement, nous présentons un récapitulatif suite à cette analyse des approches de découverte et de prédiction de services. 3.2. LA NOTION DE SERVICE A travers la littérature, la notion de services correspond à un concept largement répandu. Originairement, la notion de service est apparue avec l’émergence de l’informatique orientée services (SOC) (Service Oriented Computing) afin de gérer le problème d’interopérabilité entre des applications et des architectures hétérogènes (Papazoglou et Georgakopoulos, 2003) (Papazoglou, 2003). Le paradigme SOC utilise les services comme étant les éléments fondamentaux afin de supporter un développement rapide, fiable et à moindre coût d’applications logicielles distribuées dans des environnements hétérogènes avec une facilité de composition (Papazoglou et al., 2008). La notion de service est employée afin de fournir des abstractions de haut niveau pour l’organisation d’applications à grande échelle sur des environnements ouverts. L’usage des services contribue à implémenter et à configurer des applications logicielles d’une manière qui améliore leur productivité et leur qualité (Huhns et Singh, 2005). Plus spécifiquement, ces services diffèrent des artefacts traditionnels par leur nature autonome, auto-descriptive, réutilisable et portable. Ils sont conçus comme un ensemble de modules logiciels autonomes qui peuvent être exposés, publiés, découverts, composés et négociés à la demande d’un client et invoqués par d’autres applications (Papazoglou et al., 2008). Dans le paradigme SOC, la notion de service est matérialisée par un composant logiciel souvent associé à un ensemble de fonctionnalités particulières dont l’interface est clairement définie, voir standard, et dont le fonctionnement interne est inconnu des clients (Papazoglou et al., 2008). En d’autres termes, toujours selon ces auteurs, les services exécutent des fonctions qui peuvent être aussi bien de simples requêtes dans un formulaire, que des processus métiers complexes. En effet, les processus métiers sont supportés par des fonctionnalités qui sont implémentées comme des services. Ces services représentent des composants logiciels qui sont désignés de telle sorte qu’ils supportent les demandes métiers qui sont évolutives. Dans la même lignée, Alonso et al. (Alonso et al., 2004) définissent les services comme des éléments logiciels auto-décrits, indépendants de la plateforme et accessibles par une interface standard. Une définition plus générale est donnée par Issarny et al. (Issarny et al., 2007), qui considèrent un service comme une entité indépendante, dotée d’interfaces bien définies et pouvant être invoquée de manière standard, sans requérir de son client une quelconque connaissance sur la manière dont le service réalise réellement ses tâches. Quelle que soit la définition utilisée, il est important de souligner que les fonctionnalités (ou tâches) attachées aux services peuvent se trouver à des niveaux de granularité très différents. Même si, bien souvent, la notion de service fait référence aux Services Web, celle-Systèmes(d’Information(Pervasifs(et(l’orientation(service 48 ci est, en réalité, bien plus large, allant d’une vision orientée technologie à une vision orientée « business » (les services offerts par une organisation, par un SI). Même dans une optique purement technologique, cette notion dépasse le cadre des Services Web et peut correspondre à des technologies variées telles que les ESB (Roshen, 2009) ou les composants OSGi (souvent vus comme de « micro-services ») (Hall et al., 2011). Un autre aspect clé se dégage de ces multiples définitions : le faible couplage entre le client et le fournisseur de service. En effet, l’absence de dépendance entre les fournisseurs de services et leurs consommateurs permet d’ordonner les services dans de nombreux flux réalisant différents processus métiers (Fremantle et al., 2002) (Papazoglou et al., 2008). Le client n’a pas besoin de connaître la manière dont le service fonctionne ou est implémenté pour faire appel à ses fonctionnalités. C’est ce faible couplage qui rend la notion de service particulièrement attractive pour les environnements pervasifs, puisque ces environnements se caractérisent par la volatilité de leurs éléments (Vanrompay et al., 2011). La notion de service se comporte ainsi comme une « boîte noire » : rien de son contenu interne n’est visible aux clients, seule son interface l’est. La notion de service joue un rôle clé dans l’architecture SOA, introduite dans la section 3.3, et devient l’unité informatique de base pour supporter le développement et la composition de services de plus en plus complexes, qui à leur tour peuvent être utilisés pour créer des applications flexibles et dynamiques. 3.3. L’ARCHITECTURE ORIENTEE SERVICES : SOA Pour soutenir l’intégration des applications basées sur différents processus métiers, la modélisation de services est supportée par l’architecture orientée service (SOA – Service Oriented Architecture) (Papazoglou et al., 2008). L'orientation service s’est introduite à différents niveaux organisationnels au sein des entreprises. Elle s'appuie sur la technologie pour faire face à la demande croissante d’une plus grande intégration, flexibilité et agilité au sein de l'entreprise. Depuis la fin des années 1990, de nombreuses définitions de l’architecture SOA ont été publiées (Allen et Frost, 1998) (Alonso et al., 2004). Keith et al. (Keith et al., 2006) considèrent SOA comme un concept de modélisation métier et une architecture technique présentée sous la forme d’une infrastructure standardisée basée sur XML et sur des Services Web utilisés pour supporter des processus métiers. Ces auteurs proposent une définition très technique de SOA, laquelle est particulièrement attachée à une seule technologie. Cependant, pour apporter plus de clarté, le modèle de référence d’OASIS (Organization for the Advancement of Structured Information Standards) définit l’architecture SOA comme un paradigme pour l'organisation et l'utilisation de capacités de diffusion qui peuvent être sous le contrôle de différents auteurs. Il fournit un moyen uniforme pour offrir, découvrir, interagir avec et utiliser les capacités afin de produire les effets désirés en conformité avec les prés conditions et les attentes mesurables (MacKenzie et al., 2006). Selon ce modèle, illustré par la Figure 7, un fournisseur de services peut publier une interface bien définie sur un répertoire Systèmes(d’Information(Pervasifs(et(l’orientation(service 49 qui permet à d'autres parties prenantes de le récupérer et de coupler faiblement ce service offert à leurs propres services. Selon cette définition, les caractéristiques principales d’une architecture SOA sont le faible couplage, l’indépendance par rapport aux aspects technologiques et l’extensibilité. Le faible couplage permet de garantir la réutilisation et l’interopérabilité des services. L’indépendance aux technologiques est garantie grâce aux contrats d’utilisation qui sont indépendants de la plateforme technique utilisée par les fournisseurs de services. Enfin, l’extensibilité est rendue possible par le fait que de nouveaux services peuvent être découverts et invoqués à l’exécution. Figure 7. L’Architecture Orientée Service (SOA) et les technologies des Services Web (d’après (O’Sullivan et al., 2002)) L’architecture orientée services se base sur une collection de politiques, principes, interfaces et patrons de conception qui permettent l’intégration des différentes fonctionnalités exposées comme des services (Papazoglou et Heuvel, 2007) (Van Der Aalst et al., 2007). Selon (Papazoglou et Heuvel, 2007), l’architecture SOA fournit la capacité d’adresser les exigences de l’informatique distribuée, à savoir : indépendance des protocoles, faible couplage, réutilisation et standardisation. L’architecture SOA est ainsi mise en place afin de garantir, d’une part, la flexibilité dans la maintenance et l’évolution des systèmes, et d’assurer, d’autre part, un niveau élevé d’interopérabilité entres des systèmes hétérogènes et d’adaptation aux changements (Papazoglou et al., 2008). Cette évolution a encouragé beaucoup d’entreprises à adopter l’architecture SOA afin de permettre une réponse rapide aux changements et une réduction sur le coût de remplacement des systèmes hérités qu’ils avaient, ainsi que l’intégration de nouveaux systèmes basés sur cette architecture permettant à toutes les informations d’être accessibles et partagées par tous les systèmes (Keen et al., 2004) (Minoli, 2008). L’architecture SOA, comme elle a été définit par (MacKenzie et al., 2006), est utilisée afin de permettre d’une part l’identification et la publication de services pour les rendre réutilisables par les autres systèmes et d’autre part la découverte et la localisation de services déjà existants. La Figure 7 illustre ainsi les trois principaux acteurs qui interviennent dans cette architecture : le fournisseur, le consommateur (client) et le répertoire de services. Le Consommateur de services Fournisseur de services Répertoire de services Découvrir et localiser UDDI WSDL Publier Invoquer et Intéragir SOAPSystèmes(d’Information(Pervasifs(et(l’orientation(service 50 fournisseur de services se charge de décrire les fonctionnalités offertes par un service ainsi que les informations nécessaires pour permettre à un client de l’utiliser. Ceci représente la description de services qui sera par la suite publiée par le fournisseur dans un répertoire de services (ou annuaire de services). Ce dernier joue le rôle d’intermédiaire entre le fournisseur et le consommateur de services. Ce consommateur peut interagir avec le répertoire de services afin de retrouver le service qui répond à ses besoins. Cette étape correspond à la phase de découverte de services, laquelle se base sur les descriptions publiées afin de ne sélectionner que celles qui pouvant satisfaire le client (consommateur de service). Si le client trouve le service désiré, alors il peut mettre en place un contrat avec le fournisseur de services, afin de consommer le service. Le principe de conception derrière l’architecture SOA est qu'un service est une unité faiblement couplée composée d'une interface et d’une implémentation. L’architecture SOA se caractérise ainsi par la séparation entre la description de service (interface) et sa mise en œuvre (implémentation). L’interface définit l'identité d'un service, ses moyens d’invocation et ses capacités fonctionnelles, tandis que l’implémentation représente la mise en œuvre des opérations internes que le service doit exécuter. Cette séparation a permis aux fournisseurs et aux consommateurs de services d’être faiblement couplés. En outre, les services peuvent être facilement réutilisés. Parce que les interfaces de services sont indépendantes de la plateforme et que la mise en œuvre est transparente pour les consommateurs de services, un client devrait être capable d'utiliser le service à partir de n'importe quel terminal de communication en utilisant n'importe quelle plateforme informatique, système d'exploitation et n'importe quel langage de programmation. Ainsi, l’architecture SOA introduit essentiellement une nouvelle philosophie pour le développement d’applications distribuées, où les services peuvent être découverts, composés, publié, réutilisés, et invoqués au niveau de l'interface, indépendamment de la technologie spécifique utilisée en interne pour implémenter chaque service (Granell et al., 2010). Depuis son apparition, l’orientation service n’a cessé de progresser dans la perspective de satisfaire au mieux les besoins des utilisateurs. Cette évolution peut être analysée selon différentes visions, à savoir la vision technologique, la vision sémantique et la vision intentionnelle. Nous les détaillons dans la section suivante. 3.4. L’ORIENTATION SERVICE SOUS SES DIFFERENTES FORMES L’orientation service, telle que présentée dans les sections précédentes, n’a cessé d’évoluer. Cette notion a été impactée par une vision purement technologique, faisant apparaître les services Web afin de garantir l’interopérabilité et l’intégration des fonctionnalités métiers dans le Web. Cette vision a été étendue, par la suite, avec l’appariation du Web Sémantique. Nous avons assisté à l’émergence des services sémantiques qui se basent sur une description sémantique, plus expressive et plus compréhensible. Cette vision vient répondre aux lacunes en termes de recherche d’information et d’extraction de l’information pertinente des pages Web, par exemple. Nous avons vu apparaître également une vision intentionnelle qui place la notion de service à un niveau d’abstraction plus élevé, dans lequel Systèmes(d’Information(Pervasifs(et(l’orientation(service 51 le service est conçu afin de satisfaire une ou des intention(s) (but) précis de l’utilisateur. Cette vision soulève l’importance d’exploiter la notion d’intention dans la description des services, représentant l’émergence des services dits intentionnels. Ces services sont décris selon l’intention qu’ils arrivent à satisfaire, laquelle représente ce qu’attend l’utilisateur de l’exécution du service. Dans la suite de cette section, nous discuterons ces visions technologiques, sémantiques et intentionnelles de la notion de service. 3.4.1.Services Web : vers une vision technologique Depuis son apparition, la notion de services Web a été présentée comme la technologie la plus prometteuse qui va permettre d’assurer l’interopérabilité et l’intégration des fonctionnalités métiers dans le Web. Les services Web représentent une suite logique des intergiciels, comme DCE (Distributed Computing Environment) (Harold et Lochart, 1994), CORBA (Common Object Request Broker Architecture) (Pope, 1998) et DCOM (Distributed Component Object Model) (Redmond, 1997), vers plus d’interopérabilité (chose que ces intergiciels n’ont pas réussis à garantir). Cette interopérabilité peut être assurée grâce à la plateforme Web et aux différents standards utilisés. Dans la littérature et à travers le consortium W3C, nous observons qu’il existe diverses définitions de la notion de services Web allant des plus génériques, qui présentent un service Web comme une application modulaire accessible à d’autres applications sur le Web (Almeida et Menasce, 2002) (Curbera et al., 2001), au plus spécifiques, qui mettent en évidence les technologies et leurs rôles pour mettre en œuvre un service Web (Booth et al., 2004). Par exemple, le consortium OASIS considère un service Web comme une application métier modulaire, formant un tout qui a des interfaces basées sur des standards, orientées Internet et ouvertes (OASIS, 2001). Cette définition présente les services Web en mettant l’accent sur les standards utilisés sur le Web et sur les interfaces qui permettent d’invoquer les services ouvertement. Par la suite, le consortium W3C (Austin et al., 2002) a proposé une définition plus précise des services Web. Pour la W3C, un service Web représente une application logicielle identifiée par une URI (Uniform Resource Identification), dont les interfaces et les liaisons sont définies, décrites et découvertes comme des objets XML. Un Service Web supporte les interactions directes avec d’autres agents logiciels en utilisant le passage de messages basé sur XML via les protocoles de l’Internet. Austin et al. (Austin et al., 2002) mettent ainsi l’accent sur la façon dont les services Web doivent fonctionner. Dans cette définition, un service Web est définit en fonction de son moyen d’identification (URI), de son interopérabilité à travers les interfaces et les liaisons en XML et des interactions possibles (au travers de protocoles basés sur XML). Nous pouvons observer à ce niveau l’importance du standard XML dans cette dernière définition. Toutefois, ceci peut apporter une certaine confusion dans la mesure où n’importe quelle application sur le Web qui soit fondée sur des technologies basées sur XML peut être considérée comme un Service Web. Systèmes(d’Information(Pervasifs(et(l’orientation(service 52 Une nouvelle définition a ainsi été proposée par le consortium W3C (Booth et al., 2004) mettant plus l’accent sur l’ensemble des technologies utilisées. Ces auteurs définissent un Service Web comme un système logiciel conçu pour supporter l’interaction interopérable de machine à machine sur un réseau. Il possède une interface décrite dans un format exploitable par la machine, i.e. décrite en WSDL (Web Services Description Language). D’autres systèmes interagissent avec le Service Web d’une façon prescrite par sa description en utilisant des messages SOAP (Simple Object Access Protocol), typiquement en utilisant HTTP (HyperText Transfer Protocol) avec une sérialisation XML en même temps que d’autres normes du Web (Booth et al., 2004). Cette définition apporte un niveau plus élevé de granularité en précisant les technologies et leurs rôles pour mettre en œuvre un service Web. Elle spécifie WSDL (Christensen et al., 2001) comme la technologie utilisée pour la description des Services Web et SOAP (Mitra et Lafon, 2007) comme la technologie de communication et de messagerie assurant l’interaction avec le Service Web en question. Toutefois, nous remarquons que cette définition ne précise pas, dans le même contexte, la technologie utilisée pour permettre à un consommateur de services de rechercher un service, et au fournisseur de services de publier son service dans le répertoire de services. Une réponse à cela est déjà présentée par (OASIS, 2001) à travers la technologie UDDI comme une API et un modèle de données standard permettant l’enregistrement des informations sur les entreprises et fournisseurs de services. Nous pouvons dégager ici, une vision des services totalement concentrée sur les technologies utilisées, à savoir : (i) WSDL pour la description des services ; (ii) UDDI pour la publication des services dans un répertoire de services et pour la localisation des services recherchés ; et (iii) SOAP pour communiquer et transporter les données. Nous résumons ces technologies dans les prochaines sections. La Figure 7 illustre l’usage de ces technologies de services Web par les différents acteurs de l’architecture SOA : • Le fournisseur de services décrit les services en WSDL. Par la suite, il enregistre et publie ces services à l’aide d’un répertoire UDDI en fournissant certains détails sur le service, tels que les informations de contact sur le fournisseur, le pointeur vers le service et sa description WSDL ; • Une fois le répertoire est rempli d’informations sur les services, le consommateur de services (client) peut accéder au répertoire ; • Les requêtes UDDI sont envoyées par le consommateur de services. Si un service pertinent est trouvé, alors le répertoire fournit au consommateur les informations nécessaires pour accéder au service ; • Le consommateur, à ce stade, a encore besoin de comprendre comment accéder et invoquer réellement le service. Ces informations sont généralement disponibles dans la description WSDL du service. Il peut alors négocier avec le fournisseur le contrat d’accès au service. Ces interactions sont assurées à travers le protocole SOAP. Systèmes(d’Information(Pervasifs(et(l’orientation(service 53 Le langage WSDL (version 1.0 (Christensen et al., 2001) et version 2.0 (Chinnici et al., 2007)) permet ainsi de décrire les interfaces des services Web, en représentant de manière abstraite les opérations que les services peuvent réaliser, et cela indépendamment de l’implémentation qui en a été faite. L’Universal Description, Discovery and Integration (UDDI) (Bellwood, 2002) représente une plateforme destinée à stocker les descriptions des services Web disponibles. Il fournit, d’une part, au fournisseur de services des mécanismes pour enregistrer leurs services Web, et d’autre part, au consommateur de services les mécanismes pour les retrouver. Le mécanisme de recherche se base sur les mots-clés fournis par les fournisseurs proposant les services. La plateforme UDDI permet d’héberger un ensemble de descriptions de services Web sur un seul serveur. Toutefois, cette plateforme ne permet pas une recherche efficace de service. Ceci est dû à la simplicité de cette architecture où la sémantique des données est inexistante et où la description des services se limite à de simples mots-clés sur lesquels aucun traitement plus approfondi tel que l’approximation n’est possible. Le Simple Object Access Protocol (SOAP) (Mitra et Lafon, 2007) est un format de message basé sur XML pour l’échange d’informations dans un environnement distribué et décentralisé (Newcomer, 2002). SOAP est désigné pour gérer le problème de transport et de messagerie dans de larges environnements distribués. Il définit comment organiser les informations en utilisant XML, de sorte qu'il peut être échangé entre les machines. Cette vision purement technologique ne propose qu’une conception limitée des services et ne permette pas un réel partage des informations et du savoir. Ces technologies permettent de présenter les informations et la connaissance, mais en aucun cas de les rendre facilement utilisables et exploitables. Ainsi émerge un réel besoin d’automatisation de certaines fonctionnalités nécessaires aux Services Web, dont la découverte, la composition l’invocation et la surveillance de l’exécution des services. Ces lacunes ont conduits à la naissance des services Web sémantiques. Cette nouvelle vision apporte avec elle de nouvelles technologies et outils qui peuvent certainement compléter les technologies des services Web. L’objectif ici est, entre autres, de rendre les informations et les services plus compréhensibles afin de faciliter leur réutilisation et exploitation et de répondre au problème de l'automatisation. Nous présentons les services Web sémantique dans la section suivante. 3.4.2.Services Sémantiques : vers une vision sémantique Dès son appariation, le Web n’a cessé de croître remarquablement. Dans la perspective d’extraire du Web les informations les plus pertinentes et de les réutiliser, il a été proposé le Web sémantique (Berners-Lee et al., 2001). Celui-ci se base sur une description formelle de la sémantique des informations et des services. Grâce à cette nouvelle vision du Web, les machines arrivaient à comprendre et potentiellement à satisfaire la demande de l’utilisateur en Systèmes(d’Information(Pervasifs(et(l’orientation(service 54 se basant sur la sémantique. De manière générale, la notion de services sémantiques vise à créer un Web sémantique qui intègre des services décrit de manière non ambiguë et exploitable par des machines. Selon le consortium W3C (W3C, 2001), le Web sémantique se rapporte à deux choses différentes. D'abord, il s'agit de formats communs pour l'intégration des données provenant de sources hétérogènes, alors que le Web initial s'était focalisé principalement sur l'échange de documents. Ensuite, il s'agit d’un ensemble de langages pour enregistrer comment les données se rapportent à des objets du monde réel. Selon McIlraith et al. (McIlraith et al., 2001), l’association d’une information de nature sémantique au descripteur d’un Service Web a pour objectif la localisation, la composition et l’utilisation automatique des services distribués. La description sémantique fait référence à l’usage des ontologies qui représente une arborescence de concepts liés entre eux avec des relations bien spécifiques. Ainsi, les recherches dans le domaine du Web Sémantique se sont plus accentuées sur la définition de langages et d’outils pour la représentation des informations et des services de telle sorte qu’il soient facilement partagés, réutilisés, combinés et traités sur le Web. Ces recherches ont conduit à de multiples standards tels que RDF(S) (Brickley et Guha, 2004) et OWL (Patel-Schneider et al., 2004), ainsi qu’à des outils d’édition comme Protégé (Noy et al., 2001) et des raisonneurs comme Racer (Haarslev et Möller, 2003) et Jena (Carroll et al., 2004). De plus, plusieurs initiatives sont apparues dans l’objectif d’annoter et de décrire sémantiquement des services Web. Ces initiatives ont conduit à de multiples approches facilitant les tâches d'automatisation, dont les principales ont été standardisées par le W3C, telles que OWL-S (Martin et al., 2004), WSMO (Lausen et al., 2005) ou encore WSDL-S (Akkiraju et al., 2005) et SAWSDL. (Farrell et Lausen, 2007). Dans cette section, nous nous concentrons sur les deux standards OWL-S et SAWSDL, utilisés pour enrichir sémantiquement la description des services. Le standard WSMO sera introduit dans la section suivante (cf. section 3.4.2.1). 3.4.2.1. OWL-S (OWL-based Web service ontology) Le langage OWL-S (Semantic Markup for Web Services) (Martin et al., 2007), initialement connu sous le nom de DAML-S, permet de spécifier et décrire les services Web de façon compréhensible, non ambiguë et facilement interprétable. Ce langage, basé sur le langage d’ontologie OWL (Smith et al., 2004), est représenté aussi comme une ontologie basée sur OWL, définie afin de décrire les services Web sémantiques. Son objectif est de permettre aux utilisateurs et aux agents logiciels de découvrir, d’invoquer, de composer et de contrôler automatiquement les ressources Web offrant des services (Martin et al., 2004). OWL-S définit les capacités des services Web en trois parties, comme l’illustre la Figure 8. Ces trois parties représentant trois ontologies interdépendantes nommées « Service Profile », « Process Model » et « Service Grounding » (Martin et al., 2007). Chacune décrit un aspect important d’un service Web sémantique. Systèmes(d’Information(Pervasifs(et(l’orientation(service 55 Figure 8. La structure du haut niveau de l'ontologie OWL-S (d’après (Martin et al., 2004)) Le « service profile » exprime ce que le service réalise (Martin et al., 2004). Il donne une description de haut niveau d'un service, comme l’illustre la Figure 9, à des fins de description, de publication et de découverte de services. Le « service profile » est utilisé à la fois par les fournisseurs de services pour publier leurs services et par les consommateurs pour spécifier leurs besoins afin de découvrir le service le plus pertinent. Figure 9. Classe et propriétés de l'ontologie du profil de service de OWL-S (d’après (Martin et al., 2004)) Le « process model » répond à la question : comment est-il utilisé ? (Martin et al., 2004). Il définit les comportements d’un service en tant que processus défini par les entrées/sorties et décrit comment cela fonctionne. Le « process model » est utilisé, entre autres, à des fins de composition de services. En OWL-S, il existe trois types de processus illustrés à la Figure 10 : les processus atomiques (AtomicProcess), les processus simples (SimpleProcess) et les processus composites (CompositeProcess). Un processus atomique représente le niveau le plus fin pour un processus et correspond à l’action qu'un service peut effectuer en une seule interaction. C’est un processus qui peut être directement invocable sans sous-processus. Les processus composites représentent des processus qui sont décomposables en d’autres Systèmes(d’Information(Pervasifs(et(l’orientation(service 56 processus, qui peuvent être eux mêmes des composites. Un processus composite se base sur un ensemble de structures de contrôles telles que : « sequence », « split », « choice », afin de spécifier sa décomposition. Figure 10. La structure de l'ontologie de haut niveau du modèle de processus de OWL-S (d’après (Martin et al., 2004)) Enfin, le « service grounding » expose comment on peut accéder au service (Martin et al., 2004). Il indique comment accéder concrètement au service et fournit les détails concernant les formats de messages, les protocoles, entre autres. Cette information est particulièrement utile pour l’invocation automatique de services et elle est souvent exprimée en WSDL. La description proposée par OWL-S permet une découverte basée sur la sémantique, grâce à des outils et des algorithmes de mise en correspondance, tels que OWLS-Matcher (Jaege, 2001). De plus, OWL-S offre une grande expressivité ainsi que la possibilité d’inférer de nouvelles connaissances grâce notamment aux nombreux moteurs de raisonnements proposés pour OWL, tels que Jena (Carroll et al., 2004b), Pellet (Parsia et Sirin, 2004) et Racer (Haarslev et Möller, 2003). Enfin, même si OWL-S est conçue pour les services Web, elle est riche et suffisamment générale pour décrire tout type de services (Suraci et al., 2007). 3.4.2.2. SAWSDL (Semantic Annotations for WSDL) L’annotation sémantique de WSDL, nommé SAWSDL (Semantic Annotations for WSDL) (Farrell et Lausen, 2007) est une recommandation W3C qui a fait suite à l’approche WSDL-S Systèmes(d’Information(Pervasifs(et(l’orientation(service 57 (Akkiraju et al., 2005). SAWSDL est une approche utilisant les ontologies pour enrichir la description standard d’un service en se basant sur des mécanismes d'annotation sémantique. Figure 11. Présentation de SAWSDL avec ces deux formes d’annotations (d’après (Farrell et Lausen, 2007)) A l’encontre de OWL-S, SAWSDL ne définit pas de nouveaux langages pour modéliser sémantiquement les services, mais il fournit un mécanisme de référencement vers des modèles sémantiques souvent externes comme des ontologies. L’extension SAWSDL, comme l’illustre la Figure 11, se présente sous deux formes d’annotation. La première est le modèle de référence. Celui-ci est utilisé pour associer aux interfaces/ports, opérations, entrées, sorties, des concepts sémantiques d'une ou plusieurs ontologies. Il peut être appliqué à n’importe quel élément de WSDL, dans le but d’y associer un ou plusieurs concepts sémantiques. La valeur est un ensemble d’URI (Uniform Resource Identifier), identifiant chacun un fragment de cette description sémantique. En tant que tel, le modèle de référence sert comme un crochet où la sémantique peut être fixée (Fensel et al., 2011). Ainsi, il peut être utilisé pour décrire la sémantique des données ou afin de spécifier celle d’une opération d’un service Web. La deuxième forme d’annotation est le mappage de schémas lequel spécifie les transformations de données entre les structures de données XML des messages et le modèle sémantique associé. Cette transformation d’une représentation de données à une autre permet d’assurer l'interopérabilité nécessaire entre formats de données hétérogènes lors de l'invocation (e.g. contenu d'un message SOAP). L’inconvénient de l’approche SAWSDL est qu’elle se base sur la simple annotation qui mélange la description technique avec une description de plus haut niveau. Ainsi, plus la taille des informations à annoter devient importante, plus il devient difficile de les analyser. Systèmes(d’Information(Pervasifs(et(l’orientation(service 58 3.4.3.Services Intentionnels : vers une vision intentionnelle Les services Web, ainsi que les services Web sémantiques, sont là pour répondre aux requêtes et aux besoins de l’utilisateur. Différentes approches (Lausen et al., 2005) (Kaabi, 2007) ont soulevé ainsi l’importance de l’exploitation de la notion d’intention dans la description des services. Une intention représente ce qu’attend l’utilisateur lors de l’exécution d’un service, représentant la vision de l’utilisateur sur les fonctionnalités qu’il désire dans un service (Fensel et al., 2011). Ceci représente une nouvelle vision des services : la vision intentionnelle. Cette vision place la notion de service à un niveau d’abstraction plus élevé où le service est conçu afin de conduire à la satisfaction d’une intention de l’utilisateur. Selon (Rolland et al., 2010), cette vision permet de combler le fossé séparant une vision purement technique d’une vision purement métier des services, centrée sur l’utilisateur et ses besoins. Nous présentons, dans la suite de cette section, la définition de la notion d’intention, ainsi que deux approches orientées intentions, à savoir WSMO et l’architecture iSOA (Intentional Service Oriented Architecture). 3.4.3.1. La notion d’intention Les approches intentionnelles ont été proposées dans le domaine de l’ingénierie des exigences dans la perspective de capturer l’intentionnalité derrière les exigences logicielles (Yu et Mylopoulos, 1998). Dans ce cadre, les intentions représentent une abstraction utile pour décrire les besoins et les attentes des parties prenantes d’un système et elles offrent une façon très intuitive pour obtenir et analyser ces besoins. D’une manière générale, une intention exprime un but, un objectif que l’on souhaite atteindre et que le système doit réaliser. Plihon et al. (Plihon et al., 1998) définit une intention comme quelque chose que certains intervenants espèrent réaliser à l'avenir. Selon Antón et al. (Antón et al., 1994), une intention se réfère aux objectifs de haut niveau du métier, de l’organisation ou du système. Dans le même contexte, Van Lamsweerde (van Lamsweerde, 2000) rajoute que l’intention se présente comme un objectif que le système doit atteindre à travers une coopération d’agents dans le futur logiciel et dans l’environnement. Cet auteur souligne une distinction entre la notion d’intention et celle d’exigence. Il affirme qu’une intention est une assertion prescriptive que doit satisfaire le système considéré, alors que l’exigence est une assertion prescriptive que doit satisfaire la partie logicielle du système uniquement (van Lamsweerde, 2001). Le terme intention a plusieurs significations différentes. Selon (Jackson, 1995), l'intention est une déclaration « optative », exprimant un état qui devrait être atteint ou maintenu. En d’autres termes, l'intention représente l'objectif ou le but que nous voulons atteindre sans dire comment l'exécuter (Jackson, 1995). Cette intention peut être traduite comme le but qu’un utilisateur souhaite atteindre sans avoir à spécifier comment y parvenir ou encore comme le but à atteindre pour mener à bien un processus, celui-ci étant composé d'une séquence de sous-intentions et de stratégies pour l’atteindre (Kaabi et Souveyet, 2007). Santos et al. Systèmes(d’Information(Pervasifs(et(l’orientation(service 59 (Santos et al., 2009) définissent une intention comme un objectif à atteindre par l'exécution d'un processus présenté comme une séquence d'intentions et des stratégies à l'intention cible. Même si elles diffèrent, toutes ces définitions nous permettent de considérer l'intention comme une exigence de l'utilisateur représentant l'intention qu’il souhaite être satisfaite par un service sans dire comment l'exécuter (Najar et al., 2009). Cette intention représente donc la demande de l'utilisateur quand il est à la recherche d'un service répondant à ses besoins. Figure 12. Modèle d'intention (d’après (Prat, 1997)) Avec l’émergence de cette notion d’intention dans le domaine de l’ingénierie des exigences, Prat (Prat, 1997) a proposé une modélisation de cette notion. Ce modèle d’intention est dérivé de l'approche linguistique, laquelle est inspirée par la grammaire des cas de Fillmore (Fillmore, 1968) et des extensions de Dik (Dik, 1989). Selon ce modèle, illustré par la Figure 12, une intention est décrite sous la forme d’un verbe associé à une cible et complété par un ensemble de paramètres optionnels. Une déclaration d'intention est alors représentée par un verbe, cibles et les différents paramètres qui jouent des rôles spécifiques par rapport au verbe. Dans cette modélisation, le verbe expose l'action permettant la réalisation de l'intention, tandis que la cible représente soit l'objet existant avant la réalisation de l'intention, soit le résultat découlant de la satisfaction de l'intention. Les paramètres (façon, direction, quantité, qualité et bénéficiaire) sont utiles pour clarifier l'intention et pour exprimer les informations supplémentaires. Le paramètre direction, par exemple, caractérise la source et la destination des entités. La destination identifie l'emplacement des entités produites par la satisfaction de l'intention, alors que la source identifie l'emplacement initial des entités. Le paramètre façon, quant à lui, fait référence à l'instrument de la satisfaction de l'intention. Il représente le moyen et la manière. Le moyen indique l'entité qui sert d'instrument pour atteindre l'intention, tandis que la manière identifie une approche dans laquelle l'intention peut être satisfaite. Enfin, le paramètre de qualité définit une propriété qui doit être atteinte ou maintenue. Par exemple l’intention, I1 = {#préparer, #proposition, ∅} est composée du verbe « préparer » et de la cible « proposition » qui représente le résultat découlant de la satisfaction de l’intention. Systèmes(d’Information(Pervasifs(et(l’orientation(service 60 La notion d’intention a été utilisée dans différents modèles intentionnels, tels que KAOS (Dardenne et al., 1993), i* (Yu, 1996), Map (Rolland et al., 1998) et Tropos (Bresciani et al., 2004). Ces modèles offrent une représentation intentionnelle utilisée au début de la phase d'analyse des exigences dans le but d'expliquer le pourquoi d'un système logiciel. Elles fournissent des constructions utiles pour analyser les objectifs et les moyens de les satisfaire. Par exemple, le framework i* (Yu, 1996) propose une approche orientée agent de l'ingénierie des exigences qui est centrée sur les caractéristiques intentionnelles des agents. Dans ce framework, les agents s’attribuent les propriétés intentionnelles et raisonnent sur les relations stratégiques qui les lient. La modélisation orientée intention i* est ainsi utilisée afin de comprendre le domaine du problème. Tropos (Bresciani et al., 2004), quant à lui, est destiné à soutenir les activités d'analyse et de conception dans le processus de développement logiciel, de l'analyse du domaine d'application jusqu'à la mise en œuvre du système. Dans une perspective intentionnelle, Penserini et al. (Penserini et al., 2007) propose une approche de développement se basant sur la méthodologie de développement Tropos (Bresciani et al., 2004). Cette approche cherche à analyser les utilisateurs et à identifier leurs intentions dans la perspective de guider la conception du futur système. Cette conception est composée d’agents logiciels qui ont leurs propres capacités et qui sont destinés à supporter la réalisation des intentions du client. Le formalisme de la Carte (Map) (Rolland et al., 1998) décrit le niveau métier selon une perspective intentionnelle en fournissant les directives nécessaires pour la représentation d’un processus métier. Plus spécifiquement, la carte représente un graphe orienté et étiqueté, dont les nœuds représentent les intentions et les liens entre les nœuds forment les stratégies. Une stratégie représente une manière de réaliser une intention. Dans ce cadre, l'intention est définie comme une condition qui peut être atteinte selon différentes stratégies. Selon (Rolland et al., 2010), la Carte permet de capturer la variabilité en mettant l'accent sur la stratégie visant à atteindre une intention et les alternatives possibles pour accomplir la même intention. Cette représentation explicite de la variabilité offerte par les cartes est absente dans d'autres formalismes d'ingénierie des exigences tel que Tropos. La notion d’intention a été appliquée, sur différents travaux, à l’orientation de service. Dans la suite de cette section, nous mettons l’accent sur deux intéressantes approches WSMO et ISOA qui reposent sur la notion d’intention qu’un service est capable de satisfaire. 3.4.3.2. WSMO (Web Service Modeling Ontology) L’ontologie WSMO (Web Service Modeling Ontology) (Lausen et al., 2005) est utilisée afin de migrer la gestion des processus métier (BPM) du niveau IT (technique) au niveau utilisateur (Business) (Super Project, 2006). La notion d’intention est utilisée ici afin de préciser les processus et les tâches pour lesquels les services Web les plus appropriés puissent être découverts dynamiquement. Systèmes(d’Information(Pervasifs(et(l’orientation(service 61 L’ontologie WSMO se base sur le framework WSMF (Web Service Modeling Framework) (Fensel et al., 2002), lequel est présenté comme un cadre conceptuel à part entière pour décrire les différents aspects liés aux Services Web. Ce framework spécifie les principaux éléments pour décrire les services Web sémantiques. De tels éléments incluent : • Les ontologies qui définissent la terminologie, utilisée lors de la description, en termes de concepts, relations, fonctions, instances et axiomes ; • La description d’un service Web qui décrit formellement les fonctionnalités offertes par le service, en termes de capacité et de méthode d’interaction et en termes d’interface ; • Les intentions qui spécifient ce que l’utilisateur attend du service ; • Les médiateurs qui décrivent les différents éléments permettant de résoudre le problème d’interopérabilité entre les différents composants hétérogènes. WSMO (Web Service Modeling Ontology) (Lausen et al., 2005) représente ainsi une ontologie de modélisation des services Web sémantiques proposant un modèle conceptuel pour ces services. Les concepts de cette ontologie sont décrit formellement par le langage WSML (Web Service Modeling Langage) (de Bruijn et al., 2006). Les descriptions WSMO, formalisées en WSML, sont exécutées par l’environnement d’exécution WSMX (Web Service Modeling eXecution environement) (Bussler et al., 2005), lequel permet également la découverte, la médiation, l’invocation et l’interopérabilité des services sémantiques. WSMO est bien connu par son approche basée sur les intentions. Cette approche suppose qu’un utilisateur est à la recherche d'un service afin de satisfaire une intention spécifique. Selon Roman et al. (Roman et al., 2005), une intention décrit les aspects liés aux désirs de l'utilisateur par rapport à la fonctionnalité demandée. Ensuite, Keller et al. (Keller et al., 2004) présentent un mécanisme de découverte de services WSMO reposant sur un processus de mise en correspondance entre l’intention de l'utilisateur et les capacités de ces services. Dans WSMO, l’intention de l'utilisateur et les capacités de services ne sont pas formulées selon un modèle spécifique. Cette information est représentée uniquement comme un ensemble d'objets. Par conséquent, WSMO ne permet pas d'identifier le rôle réel que joue chaque objet dans la spécification de l'intention. En effet, les intentions dans WSMO n’ont pas une structure bien définie, tel que le modèle de Prat (Prat, 1997) présenté précédemment. Ceci empêche l’exploration de la sémantique propre à chaque objet formant l’intention. Enfin, comparé à OWL-S, WSMO ne dispose que de quelques outils d’édition, tel que WSML Editor (Kerrigan, 2005) et pas d’autant de moteurs de raisonnement puissants. Ainsi, le développement d’outils pour WSMO s’avèrent une tâche plus difficile à développer que OWL-S, puisque OWL-S s’appuient sur le langage RDF et OWL qui sont plus utilisés que WSML (M’bareck et Tata, 2008). Systèmes(d’Information(Pervasifs(et(l’orientation(service 62 3.4.3.3. L’architecture iSOA Rolland et al. (Rolland et al., 2008) soulèvent le problème de la correspondance entre les besoins exprimés par les utilisateurs, à un niveau élevé, et les services logiciels, exprimés à un bas niveau. Selon ces auteurs, afin d’atteindre le vrai potentiel de SOA au niveau de l'entreprise, il est nécessaire de combler le fossé entre les services métiers de haut niveau, compréhensibles par les acteurs métiers, et les services logiciels de bas niveau, compréhensible par le personnel technique. Ces services métiers doivent être exprimés d'une manière intentionnelle, en termes d'objectifs et de stratégies pour pouvoir les atteindre. Ceci représente une approche intentionnelle de description de services proposée par (Kaabi, 2007) (Rolland et al., 2010), appelée l’architecture orientée service intentionnel (iSOA - intentionnal Service Oriented Architecture). Figure 13. Le service intentionnel : la correspondance entre l'agent métier et le service logiciel (d’après (Kaabi et Souveyet, 2007)) L’architecture iSOA introduit la migration de l’architecture SOA centrée sur les fonctionnalités vers une architecture équivalente centrée sur les intentions. En réalité, iSOA représente une surcouche intentionnelle de l’architecture SOA, laquelle représente une approche « top-down ». Cette approche se base sur deux niveaux d’abstraction, à savoir le niveau opérationnel, décrivant les services logiciels, et le niveau intentionnel, décrivant les services intentionnels. La Figure 13 illustre cette correspondance entre l’agent métier (le haut niveau) et le service logiciel (le bas niveau). En effet, l’architecture iSOA permet d’abstraire les détails du service technique et de ses fonctionnalités, grâce au concept de service intentionnel. Ce service intentionnel correspond aux exigences fonctionnelles des agents métiers : il se concentre sur l’essence du service, à savoir l’intention qu’il permet d’atteindre. Ce service intentionnel exprimé à un haut niveau d'abstraction, se réfère à l'intention qu'il permet de satisfaire plutôt qu’aux fonctionnalités qu'il offre. Ces services, appelés services intentionnels, sont exprimés en termes d'intentions et de stratégies pour les atteindre. De plus, iSOA supporte l’opérationnalisation du service intentionnel vers les services logiciels. Agents Métiers Objectifs et intentions Service Intentionnel Description intentionnelle Service technique Description Fonctionnelle Abstraction Mise en Correspondance Niveau Intentionnel Niveau OpérationnelSystèmes(d’Information(Pervasifs(et(l’orientation(service 63 Selon Kaabi et Souveyet (Kaabi et Souveyet, 2007), l’architecture iSOA permet une prise en compte directe des objectifs métiers de l’utilisateur. En faisant la distinction avec SOA, dans iSOA les agents métiers viennent remplacer les agents logiciels au niveau des interactions, et la description intentionnelle des services vient remplacer la description technique. L’agent métier qui cherche un ou plusieurs services coïncidant avec ses besoins effectue ainsi une recherche basée sur les intentions métier. En iSOA, le fournisseur métier décrit le service de manière intentionnelle et le publie dans un répertoire de services intentionnels. La découverte de service est alors guidée par l'intention, en faisant correspondre l'intention de l'utilisateur avec les intentions que les services disponibles peuvent satisfaire. Afin d'assurer la puissante mise en correspondance de l'intention, celle-ci est formulée selon le modèle de Prat (Prat, 1997) présente dans la section 3.4.3.1. Dans le cadre de l’architecture iSOA, Kaabi et Souveyet (Kaabi et Souveyet, 2007) et Rolland et al. (Rolland et al., 2010) ont proposé un modèle de service intentionnel (ISM – Intentional Service Model) qui permet de décrire un service intentionnel selon trois différents aspects : l’interface, le comportement et la composition. L’interface expose les principales caractéristiques du service intentionnel aux clients potentiels, permettant sa réutilisation dans un processus de composition de services. Le comportement correspond aux pré/postconditions, alors que la composition permet de distinguer les services selon leur granularité (agrégat ou atomique). Selon Rolland et al. (Rolland et al., 2010), le service atomique est celui qui ne peut être composé d’autres services intentionnels. Il est lié aux intentions opérationnelles qui peuvent être satisfaites par les services fonctionnels de l’architecture SOA. Ainsi, l’opérationnalisation de service intentionnel atomique peut être assurée par l’exécution d’un service logiciel ou d’une composition de services logiciels. En revanche, les services agrégats ont des intentions de haut niveau qui doivent être décomposées jusqu'à ce que des services intentionnels atomiques se trouvent. Cette agrégation est déterminée à partir des liens d’affinement et/ou de l’intention du service. La composition intentionnelle admet deux types de services agrégats : un service composite et un service variable. D’un côté, le service composite reflète la relation de précédence ou de succession entre les intentions qu’il satisfait (reliées par un lien Et). Dans ses travaux, Kaabi (Kaabi, 2007) propose trois types de services composites. Le premier représente le service séquentiel, défini lorsqu’un ordre dans l’appel des services composants est nécessaire. Le deuxième illustre le service parallèle qui peut être réalisé selon n’importe quel ordre. Le troisième représente le service itératif défini lorsqu’un service intentionnel peut être exécuté récursivement. De l’autre côté, le service à variation correspond à différentes manières de réaliser une intention (reliées par un lien OU). Kaabi (Kaabi, 2007) propose trois types de services à variation. Le premier représente le service à choix alternatif qui exprime un choix parmi plusieurs services composants, lesquels sont mutuellement exclusifs. Le deuxième porte sur le service à choix multiple qui exprime un choix non-exclusif entre les services composants. Le dernier illustre le service multi-chemin qui introduit une variation portant sur des enchaînements alternatifs d’intentions. Systèmes(d’Information(Pervasifs(et(l’orientation(service 64 Néanmoins, nous plaidons que cette vision ne tient pas compte de l'évolution de la technologie des services, qui peut se tenir maintenant aux petits logiciels encapsulant des fonctionnalités réutilisables, ainsi que pour de grands systèmes hérités (Legacy System), dont le processus complexe est caché par des technologies telles que les services Web ou ESB (Roshen, 2009). En considérant que seuls les services atomiques peuvent être opérationnalisés à travers le service logiciel, l'architecture iSOA limite la réutilisation de ces systèmes hérités dans une approche intentionnelle. En fait, les systèmes hérités englobent souvent des processus complexes, qui subsument les satisfactions de multiples intentions ou une variabilité intensive sur leur satisfaction. Ces systèmes peuvent être comparés aux intentions agrégats, mais ils ne peuvent pas être assimilées à des intentions atomiques simples. Les trois visions que nous venons de discuter (technique, sémantique et intentionnelle) représentent le fondement de divers travaux portés sur les systèmes orientés services. Les nouveaux Systèmes d’Information Pervasifs peuvent ainsi s’inspirer de ces trois visions pour adopter une orientation service. Cependant, ceux-ci seront confrontés à différents challenges, que nous discuterons dans les sections suivantes. Nous nous focalisons ensuite sur certaines approches de découverte et de prédiction de services dans les différentes visions. 3.5. LES CHALLENGES POUR LES SYSTEMES D’INFORMATION PERVASIFS ORIENTES SERVICES Les Systèmes d’Information Pervasifs (cf. section 2.4) se présentent comme une nouvelle génération des SI dans un environnement pervasif hautement dynamique et hétérogène, dans laquelle l'interopérabilité est devenue une nécessité à tous les niveaux. Ainsi, la vision technologique de l’orientation service (cf. section 3.4.1) permettra de répondre à cette problématique d’interopérabilité. Ces SIP se doivent, de plus, d’être capable d’intégrer, de réutiliser et d’exploiter facilement et d’une manière compréhensible l’ensemble des services qui sont disponibles. Ils doivent fournir des mécanismes de découverte et de composition de services ne nécessitant pas forcément l’intervention d’un utilisateur. Dans ce cadre, la vision sémantique (cf. section 3.4.2) pourrait être vue comme une solution pour aider les SIP à répondre à ce besoin. Finalement, les SIP doivent être conçus dans la seule perspective de répondre aux besoins des utilisateurs de la manière la plus appropriée. Ainsi, une prise en compte des besoins des utilisateurs s’avère un principe fondamental de cette nouvelle génération de SI. La vision intentionnelle (cf. section 3.4.3) peut contribuer dans ce cadre en mettant en avant les besoins des utilisateurs qui sont formulés sous forme d’intention. Dans la suite de cette section, nous présentons un ensemble de challenges auxquels les SIP doivent répondre. Nous nous focalisons sur les approches de découverte et de prédiction de services que nous estimons primordiales pour un SIP transparent et proactif. 3.5.1.Les challenges L'Informatique Pervasive a apporté aux SI de nouveaux défis liés au dynamisme, à l’hétérogénéité et à l’accès ubiquitaire à l’environnement (cf. section 2.2.1). Elle a apporté Systèmes(d’Information(Pervasifs(et(l’orientation(service 65 également de nouveaux challenges dans l’usage des services au sein des SIP. Ces challenges concernent les aspects suivants : • La découverte dynamique des services : les SIP doivent satisfaire au mieux les besoins des utilisateurs mobiles. Ceci nécessite la prise en compte de l’utilisateur et de ses besoins ainsi que de son contexte courant, afin de lui proposer le service le plus approprié en toute transparence. La découverte de services est ainsi un des défis majeurs des SIP. Ce mécanisme doit assurer un certain niveau de transparence et d’efficacité tout en s’adaptant au contexte (gestion de l’hétérogénéité et du dynamisme) et en prenant en considération les besoins de l’utilisateur (afin de garantir une meilleure compréhension de l'utilisation réelle des services). Le challenge ici est de retrouver le mécanisme le plus adéquat pour répondre à tous ces besoins ; • La composition dynamique des services : face à l'hétérogénéité des services, les SIP se retrouvent devant le challenge de développer des modèles, des techniques et des algorithmes afin de composer dynamiquement les services hétérogènes et de les exécuter d’une manière transparente tout en prenant en considération l’adaptation aux changements fréquent de l’environnement ; • La prédiction (recommandation) dynamique des services : un des challenges des SIP est d’introduire des techniques de recommandation dans la perspective d’augmenter le caractère dynamique et proactif du système en proposant à l’utilisateur le service le plus approprié qui pourra l’intéresser. Un utilisateur, même dans le cadre d’un SIP, peut suivre un modèle de comportement qui évoluent avec le temps. Ces schémas de comportement représentent certaines habitudes de l’utilisateur lorsqu’il interagit avec son système. La prise en compte de ces habitudes nous permet d’anticiper ses besoins, et ainsi rendre les SIP plus proactifs. Le défi est de faire ceci de la manière la plus transparente possible. Il faut donc retrouver les moyens pour mieux comprendre les besoins des utilisateurs et observer le contexte dans lequel ils évoluent et sollicitent certains services. L’objectif ici est de trouver le mécanisme qui va permettre d’offrir une meilleure pro-activité au système, notamment par la compréhension de la relation entre la notion de contexte et des besoins des utilisateurs. Les Systèmes d’Information Pervasifs doivent faire face à l’ensemble des challenges que nous avons évoqués dans cette section. Dans la suite de ce chapitre et dans le cadre de cette thèse, nous allons nous concentrer essentiellement sur les deux challenges : la découverte et la prédiction de services. Nous nous intéressons ainsi aux différentes approches mises en place par les systèmes orientés services soient-elles techniques, sémantiques ou intentionnelles. 3.5.2.La découverte de services Durant les dernières années, de grands efforts de recherche ont été menés sur le sujet de la découverte des services. Effectivement, la pertinence d’un mécanisme de découverte de Systèmes(d’Information(Pervasifs(et(l’orientation(service 66 services dépend de comment son algorithme de mise en correspondance (matching) permet d’aller au-delà de ce que fournissent déjà les mécanismes standards comme UPnP, Jini, etc. Ce sujet a ainsi été largement traité selon une vision sémantique. Différents travaux, tels que (Paolucci et al., 2002) (Klusch et al., 2006) (Martin et al., 2007), ont concentré leurs efforts sur la mise en correspondance sémantique entre les capacités d’un service et la requête d’un utilisateur. Ces travaux ont servi de base pour d’autres travaux, tels que les travaux dans le domaine de la découverte de services sensibles au contexte (Suraci et al., 2007) (Ben Mokhtar et al., 2008) (Toninelli et al., 2008). Ceux-ci prennent en considération le contexte d’un service et le contexte courant de l’utilisateur lors de la découverte du service le plus approprié. De plus, d’autres travaux suivant une approche intentionnelle ont proposé des mécanismes de découverte de services selon l’intention (Mirbel et Crescenzo, 2010a) (Aljoumaa, 2011) (Olsson et al., 2011). Ceux-ci prennent en considération l’intention qu’un service est capable de satisfaire lors du processus de découverte. 3.5.2.1. La découverte de services sémantiques Les premiers travaux de découverte de services sémantiques, tels que (Klusch et al., 2006) et (Martin et al., 2007), se sont focalisés sur la mise en correspondance entre les entrées et les sorties pour la découverte du service le plus pertinent face à une requête donnée. Ces auteurs proposent des mécanismes de mise en correspondance sémantique (Paolucci et al., 2002) (Martin et al., 2007) et hybride (Klusch et al., 2009) en se basant sur les signatures des capacités fournies par les services. Ces mécanismes comprennent notamment l’identification des relations de subsomption entre les concepts décrivant les entrées et les sorties d’un service (Zaremski et Wing, 1995). Ces relations, semblables aux relations d’héritages, permettent de relier des concepts plus spécifiques à des concepts plus généraux explorant ainsi les hiérarchies entre les concepts dans une ontologie. 3.5.2.1.1. L’approche proposée par Paolucci et al. Une des approches les plus connues de découverte de services sémantiques a été proposée par Paolucci et al.(Paolucci et al., 2002) et Sycara et al. (Sycara et al., 2003). Ces auteurs se basent sur une description de services en DAML-S (OWL-S), dans laquelle un profil de service est décrit afin de refléter les fonctionnalités qu’il souhaite fournir à la communauté. Ils proposent, ensuite, un mécanisme de découverte de services se basant sur un algorithme de mise en correspondance sémantique entre une capacité demandée, décrite sous la forme d’un ensemble d’entrées fournies et de sorties requises, avec un ensemble de capacités fournies, décrites elles aussi sous la forme d’un ensemble d’entrées et de sorties. Cet algorithme se base sur une ontologie DAML (OWL), dans laquelle les entrées et les sorties d’un service sont sémantiquement décrites comme des concepts dans cette ontologie. En se basant sur cette ontologie, le processus de mise en correspondance peut faire des inférences sur les relations hiérarchiques de subsomption, conduisant ainsi à une mise en correspondance sémantique malgré les différences syntaxiques. Dans cet algorithme, Paolucci et al. (Paolucci et al., 2002)Systèmes(d’Information(Pervasifs(et(l’orientation(service 67 analyse les correspondances entre les capacités des services, fournies et demandées, selon quatre niveaux distincts : • Exact : si le concept demandé correspond exactement au concept proposé ou s’il représente une sous classe directe du concept proposé ; • Plug-In : si le concept proposé subsume celui qui est requis et celui-ci n'est pas une sous-classe directe du premier ; • Subsume : si le concept demandé subsume le concept proposé et celui-ci n'est pas une sous-classe directe du premier ; • Fail : s’il n’y a aucune relation entre les deux concepts. Dans cet algorithme, Paolucci et al. (Paolucci et al., 2002) reposent sur une première étape de mise en correspondance entre les sorties. Cette étape retourne, pour chaque sortie évaluée, un score représentant le degré de mise en correspondance obtenu. Ainsi, le service ayant le score le plus élevé sera sélectionné à la fin de cette étape. Toutefois, selon cet algorithme, la mise en correspondance entre les entrées n’est effectuée qu’en deuxième étape et sous condition que le résultat de la première étape retourne une égalité. Cette approche a été la base de différentes approches de découverte de services, telles que OWLS-MX (Klusch et al., 2006) que nous présentons dans la section suivante. 3.5.2.1.2. Les approches OWLS-MX, WSMO-MX et SAWSDL-MX Klusch et al. (Klusch et al., 2006) (Klusch et Kaufer, 2008) (Klusch et al., 2009) proposent différentes approches de découverte de services utilisant différents langages de description de services (OWL-S, WSMO et SAWSDL). Ces approches retournent le service le plus pertinent qui répond au mieux à la requête de l’utilisateur. Elles sont dites hybrides car elles se basent sur une combinaison de mécanismes de mise en correspondance syntaxique et sémantique. Chacune de ces approches a abouti à la proposition d’un outil de Matchmaker : OWLS-MX (Klusch et al., 2006), WSMO-MX (Klusch et Kaufer, 2008) et SAWSDL-MX (Klusch et al., 2009). Dans les trois approches, l’algorithme de mise en correspondance reçoit comme requête une description du service voulu en OWL-S, en WSMO ou en SAWSDL et retourne en conséquence les services les plus pertinents, qui se rapprochent au mieux de cette description. A chaque service est associé le degré de mise en correspondance et une valeur de similarité syntaxique par rapport à la requête. L’utilisateur peut spécifier le degré de mise en correspondance souhaité, ainsi qu’un seuil pour la valeur de similarité syntaxique. La différence entre les approches réside dans les formats de services utilisés et dans les degrés de mise en correspondance appliqués. L’approche OWLS-MX (Klusch et al., 2006) propose cinq degrés de mise en correspondance en plus des degrés Exact et Fail, dont trois basés uniquement sur la logique (Plug-In, Subsumes et Subsumed-By) et deux de type hybrides (Logic-based Fail et Nearest-Systèmes(d’Information(Pervasifs(et(l’orientation(service 68 neighbor). Le degré Logic-based Fail est utilisé lorsque le service ne parvient pas à répondre à la demande en fonction des critères de filtrage basés sur la logique, tandis que le degré Nearest-neighbor indique une certaine similarité entre un service S et une requête R définie comme :∀ INS ∃ INR : INs ≥ INR ET ∀ OUTR ∃ OUTs : OUTR ≥ OUTS V SIMIR (SnR) ≥α. Contrairement au précédent, le Matchmaker WSMO-MX (Klusch et Kaufer, 2008) utilise WSML à la place de OWL-S. La spécificité de ce Matchmaker réside dans l’usage de la notion d’intention (goal) dans la mise en correspondance, par l’application récursive de différents filtres sur les pré-conditions et les post-conditions associées à un service. Ces filtres représentent les mises en correspondance intentionnelles et syntaxiques, ainsi que ceux sur les relations, sur les contraintes et sur les paramètres. Le résultat est une mise en correspondance de l’intention selon sept degrés : equivalence, plug-in, inverse plug-in, intersection, disjonction, similarité floue (mise en correspondance basée sur la non logique), et neutre (lorsqu’aucune correspondance n’est déterminée ou lors d’un échec, le seuil de tolérance d’un échec de mise en correspondance est déclaré). L’approche SAWSDL-MX (Klusch et al., 2009) accepte, quant à elle, des services spécifiés en SAWSDL. Le processus de mise en correspondance se situe au niveau de l’interface de service en évaluant toutes les combinaisons des opérations d’un service offert et du service demandé. Cette évaluation repose sur le raisonnement par subsomption (exact, subsumes et subsumedBy) mais également sur une mise en correspondance syntaxique similaire à OWLSMX. Celle-ci compare la moyenne de similitude entre les vecteurs d'entrées et les vecteurs de sorties pour chaque opération offerte et requise à l’aide des mesures de similarité de texte (Loss-of-Information, Extended Jaccard, cosinus ou Jensen-Shannon) (Klusch et al., 2009). Ces approches précédemment citées (Paolucci et al., 2002) (Klusch et al., 2006) (Klusch et Kaufer, 2008) (Klusch et al., 2009) se caractérisent par une mise en correspondance sémantique entre les services disponibles et la requête de l’utilisateur. Dans la section suivante, nous présentons les approches de découverte de services qui, en plus de leur caractère sémantique, prennent en considération aussi le contexte d’utilisation. 3.5.2.2. La découverte de services sémantiques sensibles au contexte La sensibilité au contexte est la base pour différentes approches de découverte de services, à l’instar de (Suraci et al., 2007) (Ben Mokhtar et al., 2008) et (Vanrompay et al., 2011). Ces approches se basent, dans leur majorité, sur des descriptions sémantiques des services. La sensibilité au contexte étant une des caractéristiques de SIP (cf. section 2.4), ces approches sont ainsi particulièrement pertinentes pour les SIP, puisque ceux-ci doivent adapter leurs offres de services à l’environnement et au contexte d’utilisation. 3.5.2.2.1. L’approche DAIDALOS Suraci et al. (Suraci et al., 2007) proposent une approche orientée contexte pour la découverte de services Web. Celle-ci s’inscrit dans le cadre du projet européen DAIDALOS Systèmes(d’Information(Pervasifs(et(l’orientation(service 69 II1 . Suraci et al. (Suraci et al., 2007) considèrent la découverte de services sensibles au contexte comme la capacité d’utiliser l’information contextuelle pour découvrir et sélectionner les services les plus pertinents pour l’utilisateur. Ils considèrent que l’utilisateur et le service ont des exigences sur les informations de contexte dont ils ont besoin pour fonctionner correctement. Un utilisateur peut avoir des exigences sur le contexte d’un service qu'il recherche (disponibilité, localisation, etc.), ainsi que sur le contexte fourni par l'environnement (connexion sans fil, etc.). Un service peut demander à son tour des informations contextuelles sur l'utilisateur (lieu, les capacités du terminal, etc.) et de l'environnement (réseau, etc.). Figure 14. Les trois phases du mécanismes de filtrage lors du processus de découverte de service (d’après (Suraci et al., 2007)) Dans le cadre de cette approche, illustrée par la Figure 14, l’utilisateur débute le processus de découverte de services en fournissant au serveur de découverte de services (SDS – Service Discovery Server) sa requête et le pointeur vers sa description de contexte. Cette requête est composée de deux parties : (i) la requête basique (Basic Query) exprimée dans un des langages de découverte de services de bas niveau, tels que SLP, UPnP, UDDI, etc. ; (ii) la requête sémantique (Semantic Query) exprimée en utilisant un langage de requête sémantique de haut niveau. Du côté fournisseur, le service est décrit selon le contexte auquel il doit répondre. Celui-ci est décrit et publié par le fournisseur de service dans le gestionnaire de contexte. Ce contexte 1 Designing'Advanced'network'Interfaces'for'the'Delivery'and'Administration'of'Location' independent,'Optimised'personal'Services : http://www.ist-daidalos.org/ UTILISATEUR SDS SP GESTIONNAIRE DE CONTEXT CONTEXTE DE SERVICE CONTEXTE DE L'UTILISATUER CONTEXTE DE L'ENVIRONNEMENT Requête Basique Filtre Basique Description de Service Basique Requête Sémantique Filtre Sémantique Description de Service Sémantique Exigences de l'utilisateur sur le contexte du service Exigences de l'utilisateur sur le contexte de l'Env Filtre du Contexte Etape 1 Filtre du Contexte Etape 2 Filtre du Contexte Etape 3 Exigences du service sur le contexte de l'utilisateur Exigences du service sur le contexte de l'Env BASIC SEMANTIC CONTEXTESystèmes(d’Information(Pervasifs(et(l’orientation(service 70 inclut les conditions d’utilisation du service en fonction de la description de l’utilisateur (localisation, dispositif, mémoire disponible, taille de l’écran, etc.) et de son environnement (la température, le taux de pollution, etc.). Il agit donc comme une contrainte pour l’usage de chaque service. La description d’un service est elle aussi organisée en description basique, exprimée en XML ou WSDL, et en description sémantique, exprimée en OWL-S. Après la réception de la requête utilisateur, le SDS invoque le moteur de filtrage de services qui effectue la recherche de services en plusieurs phases, comme l’illustre la Figure 14 : • Le filtre de base compare la requête basique de l’utilisateur aux descriptions basiques des services stockés dans un répertoire de services ; • Le filtre sémantique compare la requête sémantique de l’utilisateur et les descriptions sémantiques des services qui n’ont pas été filtrées lors de la première étape. Le résultat de ce filtre est une liste de services qui répondent aux besoins de l’utilisateur mais sans aucune restriction sur les informations contextuelles ; • Le filtre de contexte compare le contexte associé au service aux attentes de l’utilisateur en termes de contexte de service. Il compare également le contexte de l’utilisateur avec les conditions d’utilisation de chaque service analysé et le contexte de l’environnement avec les exigences de l'utilisateur et du service en termes de contexte de l'environnement. L’originalité de ce travail réside dans la représentation de contexte associé à un service grâce à l’extension de OWL-S. Plus spécifiquement, le profil du service a été étendu par un attribut contexte qui représente une URL pointant vers le contexte réel du service décrit en OWL. Cette séparation entre les deux descriptions facilite la mise à jour des informations contextuelles caractérisées par leur nature dynamique. 3.5.2.2.2. L’approche AIDAS Toninelli et al. (Toninelli et al., 2008) considèrent que, dans les environnements pervasifs, les utilisateurs ont besoin de services sensibles au contexte adaptés à des paramètres tels que la localisation, l'environnement d'exécution, etc. Ces auteurs proposent alors un mécanisme de découverte de services personnalisé intégrant une représentation sémantique des données de contexte ainsi qu’une mise en correspondances de ces données. Ce mécanisme de découverte de services a été développé dans le cadre du middleware AIDAS (Adaptable Intelligent Discovery of Context-Aware Services). Celui-ci propose un mécanisme de découverte de services destiné aux utilisateurs mobiles. Le middleware AIDAS exploite la sensibilité au contexte sous forme de métadonnées, contenant les informations contextuelles. Ce modèle de métadonnées est composé des métadonnées de services, de l'utilisateur et de son dispositif. Chacun de ces composants est décrit par un profil statique qui contient les informations d'identification, ainsi que les capacités, les exigences et les interfaces des services, et un profil dynamique qui décrit les propriétés des services qui Systèmes(d’Information(Pervasifs(et(l’orientation(service 71 peuvent varier dans le temps. Ce profil dynamique comprend essentiellement des informations sur les conditions d'exploitation du service (état du service). Dans cette approche, le mécanisme de découverte de services considère en entrée les capacités offertes par les services et celles requises par l’utilisateur et offre en sortie le degré de la similarité sémantique entre eux. Pour chaque capacité requise, l’algorithme est capable de reconnaître les relations de subsomption possibles avec la capacité offerte, à l’instar de Paolucci et al. (Paolucci et al., 2002), à savoir la capacité offerte peut être une instance de la classe de la capacité requise (exact), ou une instance d'une classe qui subsume celle-ci (subsume) ou une instance d'une classe qui est subsumé par celui-ci (plug-in). Ces relations sémantiques sont déterminées en considérant les valeurs de propriétés et les classes des capacités offertes et requises. En cas de correspondance exacte pour toutes les capacités du service, alors le service offert est compatible avec la demande de l'utilisateur. Dans le cas où la correspondance n'est pas exacte, la compatibilité est évaluée en fonction des préférences de l’utilisateur. S'il existe une préférence indiquant que la contrainte sur cette propriété peut être assouplie, un plug-in ou un subsume peut être considéré comme compatible 3.5.2.2.3. L’approche EASY Similairement aux approches précédentes, Ben Mokhtar et al. (Ben Mokhtar et al., 2008) proposent un middleware sémantique et orienté services, nommé EASY, illustré à la Figure 15, pour la découverte et la composition de services dans un environnement pervasif. Figure 15. Aperçu de l'architecture du middleware EASY (d’après (Ben Mokhtar et al., 2008)) Cette proposition inclut le langage EASY-L basé sur OWL, pour la spécification sémantique, non ambiguë, de propriétés fonctionnelles et non-fonctionnelles des services. De plus, elle présente EASY-M (EASY-Matching) qui représente un ensemble de relations de conformité pour la mise en correspondance entre les services en termes de leurs propriétés EASY-enhanced SDP EASY Descriptions de EASY-L SDP-L Reg/adv EASY-L + SDP-L Reg/adv E A S Y - M Indexer ontology au group Indexer EASY-L à SDP-L Legacy SDP S Descriptions de SPD-L D P - MSystèmes(d’Information(Pervasifs(et(l’orientation(service 72 fonctionnelles et non fonctionnelles. EASY-M fournit les moyens pour découvrir le service qui correspond au mieux aux exigences non-fonctionnelles des utilisateurs en prenant en considération leurs préférences. Ben Mokhtar et al. (Ben Mokhtar et al., 2008) adoptent des niveaux de mise correspondance similaires à ceux proposés par Paolucci et al. (Paolucci et al., 2002) (cf. section 3.5.2.1.1). Ils présentent ainsi leurs trois relations pour la mise en correspondance des propriétés fonctionnelles des capacités requises et des capacités offertes : ExactCapabilityMatch, InclusiveCapabilityMatch et WeakCapabilityMach. La relation ExactCapabilityMatch permet de trouver les capacités offertes qui correspondent exactement à une capacité requise. La relation InclusiveCapabilityMatch permet de trouver des capacités qui peuvent être plus génériques que la capacité requise, tandis que la relation WeakCapabilityMach représente la relation la moins restrictive, où les concepts des capacités requises soit subsument, soit sont subsumés par les concepts offerts. Ceci permet de découvrir des services fournissant des sorties plus spécifiques que celle requises. En se basant sur EASY-L et EASY-M, le middleware EASY utilise un algorithme d’encodage hors ligne lequel réalise un encodage des concepts des ontologies utilisés et permet ainsi de réduire le coût du raisonnement sémantique sur les ontologies à une comparaison numérique de codes. Selon Ben Mokhtar et al. (Ben Mokhtar et al., 2008), cet algorithme s'appuie sur les nombres premiers et prend en charge un encodage progressif et sans conflit, permettant ainsi de faciliter la réutilisation et l’extension des ontologies existantes. Le middleware EASY se base sur cette technique d’encodage pour d’organiser efficacement les spécifications des services sémantiques dans les répertoires de services. Cette organisation permet de réduire considérablement le nombre de mises en correspondance sémantiques effectuées lors de la découverte de services. 3.5.2.2.4. L’approche proposée par Vanrompay et al. Vanrompay et al. (Vanrompay et al., 2011) proposent un mécanisme de découverte de services basé sur une mise en correspondance contextuelle, lequel prend en compte l'incertitude des informations de contexte lors du classement des variantes de services. Ce mécanisme se base sur des descriptions de services en OWL-S enrichies avec des propriétés contextuelles. Ces propriétés représentent le contexte requis du service, lesquelles sont non fonctionnelles et liées à l'environnement d'exécution le plus adapté pour le service. A l’instar de Suraci et al. (Suraci et al., 2007), la description de contexte requis est incluse dans un fichier XML extérieur référencé à l’intérieur du profil de service OWL-S. L’originalité de cette approche réside dans l’analyse de cette description contextuelle sous forme de graphe. Dans ce graphe, les objets représentent les concepts et les propriétés, alors que les arêtes représentent les relations reliant ces concepts. Cette approche par graphe permet de comparer les informations contextuelles en se basant sur des mesures de similarité. Le mécanisme de découverte de services utilise des mesures de similarité locale combinées à des mesures de similarités globales dans le but de comparer les exigences liées au contexte de chaque variante de service avec les valeurs du contexte courant d’exécution. Les mesures locales comparent deux nœuds individuellement, en considérant Systèmes(d’Information(Pervasifs(et(l’orientation(service 73 seulement le concept qu'il représente et ses propriétés. Les mesures globales prennent en compte le graphe dans son ensemble, évaluant, par exemple, la proportion des éléments similaires dans les deux graphes. Ces mesures sont basées sur l'analyse des valeurs moyennes et des degrés d'incertitude. Le degré d’incertitude est représenté comme une métadonnée associée au contexte observé. Plus le degré d’incertitude est faible, plus l’information contextuelle est fiable. Les résultats de ces mesures globales sont utilisés pour classer les services selon leur pertinence dans le contexte courant. 3.5.2.2.5. L’approche proposée par Petit Petit (Petit, 2010) propose une approche spatiale pour la modélisation et la conception d’un Système d'Information mobile et distribué par l’analyse du contexte. Cet auteur propose un modèle décrivant l'espace géographique d’un système utilisé pour différencier un ensemble de contextes d'exécution. Son but principal est d’aider et de guider les concepteurs à caractériser les évolutions possibles de la mobilité du systèmes lors de sa future exécution. La description de contexte permet de mettre en correspondance les attentes des utilisateurs avec les capacités techniques de la plateforme afin de leur offrir les fonctionnalités les plus adéquates. Dans ce modèle, les composants de la plateforme génèrent une seule région d'exécution définie selon une certaine couverture spatiale. Cette région d’exécution présente l'espace dans lequel ce composant agit au sein du système. Ce modèle définit également des régions d'intérêt qui sont définies par rapport à des informations relatives à des lieux ou des évènements de l'environnement du système. Dans ces travaux, Petit (Petit, 2010) propose un cadre de conception unifié permettant d’identifier et de prendre en compte les besoins des utilisateurs et leurs attentes futures. Ce cadre se définit selon les deux étapes suivantes : (1) définition des objectifs des utilisateurs ; et (2) identification des étapes nécessaires à l’accomplissement de ces objectifs (tâches). Ce cadre de conception est utilisé comme support pour l’intégration des contextes d’exécution décrits par l’étude géographique de l’environnement et des relations entre régions. Le cadre de conception résultant est dit cadre de conception étendu. Il considère les variations du contexte d’exécution au niveau de chaque composant. Il ajoute ainsi une description géographique de l’environnement comme entrée du processus de modélisation. La modélisation des contextes d’exécution est fournie en entrée d’un processus de conception étendu, centré sur l’analyse des tâches des utilisateurs pour l’écriture de scénario. 3.5.2.3. La découverte de services sémantiques intentionnels En plus des approches sémantiques et sensibles au contexte citées précédemment, une autre vision est proposée par des travaux tels que (Rolland et al., 2010) (Aljoumaa et al., 2011) (Olsson et al., 2011). Ces approches, dites guidées par l'intention, prônent l'importance des besoins de l'utilisateur lors du choix des services. Systèmes(d’Information(Pervasifs(et(l’orientation(service 74 3.5.2.3.1. L’approche SATIS L’approche SATIS (Semantically AnnotaTed Intentions for Services) (Mirbel et Crescenzo, 2010b) a été proposée dans la perspective d’offrir à des utilisateurs finaux le moyen de représenter leurs démarches de recherche de Services Web pour opérationnaliser des parties d’un processus métier. Cette approche permet, d’une part, aux utilisateurs finaux d’exprimer leurs besoins selon une perspective intentionnelle, et d’autre part, de les aider à rechercher les Services Web disponibles qui correspondent à leurs besoins. Cette approche est dépendante d’un domaine particulier pour lequel des connaissances du domaine et des descriptions de services Web sont disponibles. L’approche SATIS (Mirbel et Crescenzo, 2010b) repose sur les technologies du Web sémantique pour représenter : (i) les besoins intentionnels de haut niveau des utilisateurs ; (ii) les patrons de spécifications de services Web ; ainsi que (iii) les spécifications des services Web. Dans leur approche, ces auteurs adoptent le modèle de la Carte (Rolland, 2007) pour la description des besoins intentionnels des utilisateurs finaux. Le modèle de carte met en avant les intentions et les stratégies possibles pour atteindre celles-ci. Celles-ci sont rassemblées dans une ontologie spécifiée en RDFS (Brickley et Guha, 2004), dédiée à la représentation des processus intentionnels et à l’annotation du processus de recherche (Corby et al., 2009). En plus de cette ontologie, l’approche SATIS repose sur deux autres ontologies, une ontologie OWL-S utilisée pour la description de Services Web, et une ontologie de domaine, notamment une ontologie décrivant les images médicales et les traitements d’image associés (Mirbel et Crescenzo, 2010b). Finalement, les patrons de spécifications de service Web sont définis à l’aide du langage de requête SPARQL. Ces patrons de spécifications des services Web sont ainsi modélisés comme des patrons de graphes qui sont projetés sur les graphes des annotations de Services Web (Mirbel et Crescenzo, 2010a). L’approche SATIS propose ainsi un modèle de réutilisation et de partage de requêtes dans une communauté permettant de construire les démarches d’une façon dynamique. Ces requêtes sont organisées sous la forme d’un ensemble de fragments de démarche de recherche. Un fragment de démarche représente un morceau autonome et cohérent du processus de recherche de Services Web (Mirbel et Crescenzo, 2010a), modélisé sous forme de requêtes SPARQL. Chaque fragment permet de supporter l’opérationnalisation d’une partie du processus métier (e.g. une chaîne de traitement d’images) à l’aide de Services Web (Mirbel et Crescenzo, 2010b). Ces fragments seront par la suite réutilisés et partagés à l’intérieur d’une communauté d’utilisateurs partageant les mêmes centres d’intérêts dans un domaine. L’approche SATIS (Mirbel et Crescenzo, 2009) passe par quatre phases, comme l’illustre la Figure 16. La première phase est la phase d’élicitation dans laquelle les utilisateurs finaux définissent leurs fragments de démarches selon le modèle de la Carte (Rolland, 2007). La deuxième phase représente la phase de formalisation comportant deux activités. Tout d’abord, elle se charge de raffiner certaines sections (composées d’une intention source, d’une intention cible et d’une stratégie) de la Carte décrite lors de la phase d’élicitation. Ce raffinement permet de détailler la manière d’atteindre une intention cible. Ensuite, elle se Systèmes(d’Information(Pervasifs(et(l’orientation(service 75 charge de générer les requêtes SPARQL afin de concrétiser chaque section par un service Web approprié ou par un ensemble de spécification de services Web. La troisième phase est la phase de fragmentation, laquelle transforme toutes les spécifications capturées pendant la phase de formalisation en un ensemble de règles (Corby et al., 2009). Finalement, la quatrième phase est la phase de population. Cette phase consiste à dériver les spécifications sémantiques des services Web pour opérationnaliser l’ensemble des intentions et des stratégies associées à la requête en cours de réalisation. Figure 16. L’approche SATIS (d’après (Mirbel et Crescenzo, 2009)) Dans approche (Mirbel et Crescenzo, 2010b), la phase de recherche comporte deux alternatives : (i) rechercher parmi les besoins intentionnels décrits explicitement dans la mémoire sémantique de la communauté ; ou (ii) créer lui-même une nouvelle spécification de besoin. La création d’une nouvelle spécification consiste à spécifier des besoins intentionnels selon le modèle de la Carte (Rolland, 2007), sous forme d’intentions et de stratégies pour les atteindre. Cette modélisation permet de spécifier des intentions suffisamment précises pour qu’elles soient associées à des patrons de spécifications de Services Web. Par la suite, l’étape de mise en œuvre de la démarche de découverte de Services Web va permettre l’opérationnalisation du processus métier. Quant au mécanisme de recherche de services, il s’appuie sur un moteur de chaînage arrière qui exploite les règles SPARQL implémentant les fragments de démarches. Plus spécifiquement, l’approche SATIS s’appuie sur le moteur sémantique CORESE (Corby et al., 2009), lequel représente un moteur de recherche sémantique basé sur le modèle des graphes conceptuels. CORESE intègre un moteur de chaînage arrière exploitant des règles implémentées par des requêtes SPARQL représentant les fragments de la forme construct-where. Selon cette formalisation, la clause construct est un patron de graphe permettant de construire la représentation RDF de la section de la carte et la clause where est un patron de graphe qui représente soit une carte (règle abstraite) soit un critère de recherche de ressources pertinentes (règle concrète). Elicitation Formalisation Fragmentation Population Requêtes SPARQL Règles CORESE RDF Annotation RDF Approche intentionnelle Ontologies Domaine métier Modèle de Carte pour les services Services WebSystèmes(d’Information(Pervasifs(et(l’orientation(service 76 Le point fort de SATIS est qu’elle s’appuie sur les modèles et langages du Web sémantique pour enrichir la description des besoins des utilisateurs et ainsi proposer des moyens de raisonnement et d’explications des Services Web trouvés pour implémenter un besoin métier. 3.5.2.3.2. L’approche PASiS Aljoumaa et al. (Aljoumaa et al., 2011) proposent une approche sémantique orientée services basée sur l’architecture iSOA (Kaabi et Souveyet, 2007) (Rolland et al., 2010) (cf. section 3.4.3.3). A partir du modèle de services intentionnels (ISM - Intentional Services Model), Aljoumaa et al. (Aljoumaa et al., 2011) proposent l’approche PASiS (Publishing And Searching intentional Services) dont l’objectif est de permettre aux utilisateurs finaux d’exprimer leurs besoins sous forme de requêtes basées sur le modèle d’intention de Prat (Prat, 1997) (cf. section 3.4.3.1). A l’aide d’un processus de reformulation, l’approche PASiS vise à assister les utilisateurs lors de la formulation de leur requête. Ces auteurs se basent essentiellement sur le principe de guidage méthodologique pour formuler les besoins des utilisateurs sous forme d’intention et découvrir et sélectionner les services intentionnels les plus proches des besoins de l’utilisateur. Cette approche vise ainsi à rendre opérationnels les travaux de (Kaabi et Souveyet, 2007) (Rolland et al., 2010) en implémentant, entre autres, le mécanisme de découverte de services intentionnels de l’architecture iSOA. Ce mécanisme repose sur une description des services en SAWSDL étendue afin de prendre en considération l’aspect intentionnel (Aljoumaa et al., 2011). Le mécanisme de découverte de services guidé par l’intention, se base sur un ensemble d’ontologies : (i) iOnto décrivant les services intentionnels ; (ii) vOnto représentant les verbes du domaines ; et (iii) pOnto représentant l’ontologie de domaine. Ce mécanisme de découverte applique un algorithme de mise en correspondance sémantique entre une requête formulée sous forme d’intention et les intentions des services disponibles dans le répertoire étendu de services. Cette mise en correspondance s’inspire particulièrement de Paolucci et al. (Paolucci et al., 2002). Elle détermine un possible lien d’héritage entre deux concepts dans l’ontologie et ensuite, en fonction du nombre de niveaux hiérarchiques qui les séparent, elle détermine si les deux intentions correspondent. L’architecture iSOA (cf. section 3.4.3.3), comme pour PASiS (Aljoumaa, 2011), considère qu’un service intentionnel est attaché directement à un service technique (une relation 1 à 1). Ces auteurs ne prennent pas en charge non plus la dynamique de l’environnement technique par rapport à la réalisation de l’intention, ni le fait que dans des contextes différents, une intention peut être réalisée par différents services techniques. 3.5.2.3.3. L’approche proposée par Olsson et al. Olsson et al. (Olsson et al., 2011) défendent également l'utilisation de l'intention pour décrire les services selon un nombre arbitraire de niveaux d'abstraction. Ces auteurs proposent une approche de découverte de services orientée intention. Dans cette approche, un utilisateur Systèmes(d’Information(Pervasifs(et(l’orientation(service 77 doit être capable de spécifier une intention de haut niveau, exprimée en WSML, en termes de QoS, d’indicateurs clés de performance et, bien sûr, de fonctionnalités spécifiques. Cette intention décrit un état souhaité du système, ce qui va permettre au mécanisme de découverte de découvrir les services les plus pertinents qui peuvent satisfaire l’intention de l’utilisateur. Cette approche se base sur une méthodologie ascendante (bottom-up) pour la modélisation sémantique des services Web, en se basant sur l’annotation des fichiers WSDL avec des informations sémantiques pour chaque opération. Ainsi, ces auteurs représentent un service Web comme un ensemble d’opérations annotées sémantiquement. Chaque opération est modélisée comme un ensemble de variables d’entrée et de sortie, et d’états de transition constitués d’une assomption (assumption) et d’un effet. Dans le mécanisme de découverte de services, une intention est mise en correspondance avec les effets des opérations, et les assomptions peuvent alors, à leur tour, être considérées comme des intentions supplémentaires qui infèrent des dépendances entre les opérations. Ce mécanisme se base sur un algorithme de mise en correspondance, également inspiré des travaux de Paolucci et al. (Paolucci et al., 2002). Cette mise en correspondance entre une intention et l’effet d’une opération est déterminée ainsi selon les mêmes niveaux que Paolucci et al. (Paolucci et al., 2002) (exact, plug-in, subsume et fail), alors que la mise en correspondance des opérations s’effectue par une vérification de la requête dans le framework WSML2Reasoner (Grimm et al., 2007). De plus, cette approche de découverte de services intègre un algorithme de raffinement d’intention. Cet algorithme décompose une intention en sous intentions plus spécifiques avec lesquelles on peut avoir un résultat de mise en correspondance plus précis. Cet algorithme de raffinement d’intentions permet de déterminer également l’ensemble d’opérations qui sont nécessaires pour l’accomplissement d’une intention. Selon ces auteurs (Olsson et al., 2011), cet algorithme de raffinement permet non seulement la description des services, mais aussi l'amélioration de la performance de la découverte de ces services. Cette approche se concentre uniquement sur les aspects fonctionnels, permettant de découvrir avec les opérations des services qui devraient être utilisées lors d’une composition. 3.5.2.4. La découverte de services sémantiques sensibles au contexte et intentionnels Aucun de travaux précédemment cités (Mirbel et Crescenzo, 2010b) (Aljoumaa et al., 2011) (Olsson et al., 2011) ne combine la notion de contexte à celle d’intention, contrairement à Santos et al. (Santos et al., 2009), Ramadour et Fakhri (Ramadour et Fakhri, 2011) et Ma et al. (Ma et al., 2011) qui ont relevé l’importance d’exploiter l’étroite relation entre ces deux notions dans les processus de découverte de services. Systèmes(d’Information(Pervasifs(et(l’orientation(service 78 3.5.2.4.1. L’approche proposée par Santos et al. Santos et al. (Santos et al., 2009) proposent le framework GSF (Goal-Based Service Framework), qui permet une découverte et une composition dynamique de services guidée par l'intention et le contexte. Cette approche se base sur la notion d’intention afin d’analyser les besoins exprimés par les utilisateurs. Pour cela, ces auteurs identifient à priori un ensemble d'intentions spécifiques à un domaine et les différentes tâches qui permettent leur accomplissement. Les services sont aussi associés à ces tâches, permettant une découverte guidée par l'intention. Le concept d’intention est utilisé afin d’exprimer l’objectif de l’utilisateur vis à vis du service. Le framework GSF illustré à la Figure 17 propose ainsi une ontologie des services basée sur les intentions (GSO) (Goal Service Based-Ontology) décrivant les concepts indépendants du domaine tels que le service, le client, le fournisseur, l’intention, la tâche et leurs relations. Ces concepts sont par la suite utilisés et spécialisés dans les ontologies de tâche et de domaine. L’ontologie de domaine inclut les concepts spécifiques à un domaine, les relations entre ces concepts et les intentions valides que les utilisateurs de ce domaine peuvent avoir, tandis que l’ontologie de tâche utilise les concepts définis dans l’ontologie de domaine et fournit les définitions spécifiques à ce domaine des tâches et comment elles peuvent être liées à l'accomplissement des intentions de l'utilisateur. Le framework GSF fournit également une plateforme des services sensibles au contexte supportant l'interaction entre les fournisseurs et les clients de services. Du point de vue fournisseur, la plateforme prend en charge la publication des descriptions de services. Du point de vue client, celle-ci fournit des mécanismes de découverte, de composition et d’invocation de services. Cette plateforme comprend des composants de gestion de contexte qui se chargent de fournir des informations contextuelles de l'utilisateur. Ces informations représentent des données d'entrée pour les services découverts, et sont utilisées autant pour la sélection de la tâche qui répond à une intention donnée, que pour réduire l'interaction de l'utilisateur avec la plateforme soutenant ainsi un comportement plus autonome. Figure 17. Les principaux composants de GSF (d’après(Santos et al., 2009)) A travers cette plateforme (Santos et al., 2008) (Santos et al., 2009), un client peut soumettre soit une intention, en demandant à la plateforme de lui retourner le service qui satisfait celle-ci, soit directement une tâche. Si l’utilisateur décrit sa demande sous forme Spécification de Domaine "Utilisé par" Ontologie de Domaine Ontologie de tache Ontologie de services basée les intentions Méta-model de services basée les intentions Plateforme Services sensibles au contexte Service "Représenté par" "Instance" "Annoter" "Interagir avec" "Utilisé par"Systèmes(d’Information(Pervasifs(et(l’orientation(service 79 d’intention, alors un processus de découverte de services en deux phases démarre. La première phase effectue une mise en correspondance entre l’intention de l'utilisateur et les intentions définies dans l'ontologie de domaine. Si une intention est trouvée, le processus déclenche la deuxième phase qui va chercher les tâches définies dans l'ontologie de tâche pouvant répondre à cette intention. Ce processus identifie alors les services qui implémentent la tâche satisfaisant l’intention demandée, grâce à une correspondance entre les services et les tâches fixées à l'étape précédente. Par contre, si l’utilisateur choisit de soumettre une tâche, alors la plateforme tente de trouver la mise en correspondance entre la tâche demandée et celles dans l'ontologie de tâches, puis les services qui implémentent les tâches choisies. Cette approche semble particulièrement restrictive car elle demande l’association au préalable des intentions aux tâches dans l’ontologie de tâches. Par ailleurs, la notion de contexte n’est utilisée que comme un paramètre d'entrée pour les services recherchés, sans avoir une réelle relation avec l'intention. Ces auteurs ne considèrent le contexte que comme un filtre pour la découverte de services, le contexte étant décrit comme une partie des entrées nécessaires aux services, et les intentions comme de simples étiquettes permettant de relier les demandes des utilisateurs aux services. 3.5.2.4.2. L’approche proposée par Ramadour et Fakhri Ramadour et Fakhri (Ramadour et Fakhri, 2011) proposent une méthode de découverte et de composition de services nommée PAX (Pattern-Based Approach for Composition of Services). Cette approche se base sur la notion d’intention et de contexte afin de formaliser les besoins des utilisateurs et de représenter les aspects environnementaux (culturel, organisationnel, spatial, temporel) et non fonctionnels (qualitatif, sécuritaire) liés aux utilisateurs (rôle, compétence). Dans leur travaux, ces auteurs proposent l’utilisation des patrons de compositions afin d’assurer l’accessibilité, la réutilisation et l’adaptabilité des compositions. Ces patrons réalisent une certaine intention dans un contexte donné. D’un côté, l’intention est structurée selon le modèle de Prat (Prat, 1997). De l’autre côté, le contexte est exprimé sous la forme d’assertions contextuelles exprimées sous forme de type (temporelle, financière, rôle, compétence, etc.) et de sa formulation. Ces deux notions sont basées sur les concepts de l’ontologie contextuelle proposée par (Ramadour et Fakhri, 2011). Les assertions contextuelles sont combinées à travers les connecteurs logiques AND et NOT. Pour découvrir les compositions de services nécessaires pour répondre aux besoins des utilisateurs, Ramadour et Fakhri (Ramadour et Fakhri, 2011) se basent sur la notion de rapprochement entre l’intention et le contexte de l’utilisateur avec ceux des patrons disponibles. Ce rapprochement comporte essentiellement deux types de traitements : (i) la similarité des intentions ; et (ii) la compatibilité de contexte. Ces deux traitements se basent sur une ontologie linguistique. D’une part, la similarité des intentions repose sur la similarité sémantique entre les actions et les objets. Ainsi, deux intentions sont similaires si leurs actions (verbes) et leurs objets sont sémantiquement équivalents selon l’ontologie Systèmes(d’Information(Pervasifs(et(l’orientation(service 80 linguistique. Cette équivalence comporte les liens d’hyponymie et de synonymie, et est évaluée soit à une mesure exacte, soit à un poids entre [0..1] reflétant l’équivalence sémantique. D’autre part, la compatibilité de contexte se base sur des assertions contextuelles. Les assertions contextuelles sont séparées en deux groupes. Le premier groupe comporte les assertions positives, celles qui sont combinées par l’opérateur AND. Le deuxième groupe comporte les assertions négatives, celles qui sont combinées par l’opérateur NOT. Ainsi, la compatibilité de deux contextes commence par comparer séparément les assertions positives et négatives. Cette comparaison se base sur l’équivalence sémantique, selon l’ontologie linguistique, entre le type et la formulation de deux assertions contextuelles. La découverte des services composites représente un des trois opérateurs de l’approche proposée par Ramadour et Fakhri (Ramadour et Fakhri, 2011), en plus de l’opérateur de spécialisation qui permet de descendre dans le niveau d’abstraction et d’opérationnalisation qui permet d’assembler les compositions fournies par les patrons d’une manière abstraite. Ces opérateurs représentent le processus de manipulation des compositions de services, lequel prend comme entrée le besoin à satisfaire et comme sortie la composition de services retrouvée à l’aide du processus de découverte décrit ci-dessus. 3.5.2.4.3. Extension de WSMO pour la sensibilité au contexte Afin de suivre l’évolution des applications mobiles, l’approche WSMO a été étendue afin de prendre en considération divers éléments non fonctionnels, tels que la notion de contexte (Grenon, 2009). L’incorporation des informations contextuelles dans WSMO a été traitée dans le cadre du projet européen SOA4ALL2 . L'objectif principal de ce projet est de fournir un cadre global qui intègre les avancées technologiques (i.e. SOA, gestion de contexte, Web 2.0 et Web sémantique) dans une plateforme de prestation de services cohérente et indépendante du domaine. Dans ce cadre, Grenon (Grenon, 2009) propose des mécanismes et des directives pour spécifier des dimensions structurant et uniformisant les informations contextuelles. Ces dimensions fournissent un ensemble d’informations contextuelles pertinentes dont certaines on été introduites dans une extension minimale de WSMO. Cette extension repose d’abord sur la relation entre l’intention et ces dimensions, considérées comme aspects non fonctionnels de l’intention. Pour cela, une nouvelle classe d’éléments a été ajoutée à WSMO et spécialisée dans les relations ci-dessus. Enfin, une notion d’agent pour la collecte de l’information contextuelle a aussi été ajoutée. Outre l’approche de Grenon (Grenon, 2009), Saadon et Mohamad (Saadon et Mohamad, 2011) propose également une extension de WSMO, appelée WSMO-M, destinée à l’Informatique Mobile. Celle-ci considère le contexte en tant que propriété non fonctionnelle. Ces auteurs considèrent que l’ensemble des propriétés non fonctionnelles (NFP – NonFunctional Properties) proposé par WSMO, tel que description, relation, sécurité, exactitude, couverture, version, passage à l’échelle, etc., ne sont pas suffisamment expressives et 2 http://www.soa4all.eu/Systèmes(d’Information(Pervasifs(et(l’orientation(service 81 flexibles pour prendre en considération l’attribut contexte. Par conséquence, et comme l’illustre la Figure 18, ils proposent une nouvelle catégorie de la classe NFP appelée contexte. Celle-ci contient toutes les informations contextuelles qui peuvent être associées à la classe service Web, telles que ressource, moyen de paiement, localisation et temps, ainsi qu’à la classe intention, telles que le profil de l’utilisateur et du dispositif, la localisation et le temps. Figure 18. Extension des propriétés non fonctionnelles du modèle conceptuel de WSMO (d’après (Saadon et Mohamad, 2011)) De plus, ces auteurs proposent un mécanisme de découverte de services qui repose sur une mise en correspondance des propriétés fonctionnelles (pré-conditions et post-conditions), mais également des éléments de contexte liés au service et à l’utilisateur et une mise en correspondance sémantique entre l’intention qu’un service permet de satisfaire et la requête de l’utilisateur exprimée sous la forme d’intention. Celle-ci repose sur les mêmes degrés de mise en correspondance proposés par (Paolucci et al., 2002) : exact, plug-in, subsume et fail. Les approches précédemment citées visent la satisfaction immédiate d’une requête directe de l’utilisateur. Il s’agit d’un comportement réactif et non proactif. Dans la section suivante, nous présentons ces approches proactives, de la prédiction de services, lesquelles représentent le deuxième challenge de SIP auquel nous nous intéressons. 3.5.3.La prédiction de services A ce jour, une majorité de systèmes sensibles au contexte sont simplement réactifs, prenant les décisions en se basant seulement sur le contexte courant. Les recherches dans les systèmes anticipatoires et proactifs, notamment par la prédiction de la situation future de l’utilisateur, sont encore à leurs débuts. Dans de tels systèmes, un utilisateur peut avoir un ensemble d’habitudes. En exploitant celui-ci, nous pouvons améliorer la transparence des systèmes en réduisant l'effort de compréhension de l'utilisateur par l’anticipation de ces besoins. Plusieurs approches ont été proposées afin d’atteindre ce caractère anticipatoire soit des services, par la recommandation (Abbar et al., 2009) (Xiao et al., 2010)(Yu et al., 2012), soit du contexte Service Web * Intention Capacité Interface Axiome Orchestration Chorégraphie Prop. non Fonctionnelle Contexte QoWS Variable Partagée * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "hasAssumption" "hasPrecondition" "hasPostcondition" "hasEffect"Systèmes(d’Information(Pervasifs(et(l’orientation(service 82 d’utilisation, par la prédiction (Meiners et al., 2010)(Boytsov et Zaslavsky, 2011). Les prochaines sections introduisent certaines de ces approches. 3.5.3.1. Prédiction de contexte Dans l’Informatique Pervasive, plusieurs recherches ont été menées dans le cadre de la prédiction de contexte d’utilisation. Ces contributions visent à introduire de nouvelles techniques de prédiction afin d’augmenter le caractère dynamique des systèmes pervasifs. 3.5.3.1.1. L’approche proposée par Mayrhofer et al. Une des premières contributions dans la prédiction de contexte a été proposée par Mayrhofer (Mayrhofer, 2004). Cet auteur propose une architecture et un cadre pour la prédiction de contexte. Il est basé sur une classification non supervisée, qui tente de trouver des clusters de contexte, jusque-là inconnues à partir des données d'entrée, représentant des patrons récurrents. Cette approche interprète le contexte comme des états, dans lesquels un utilisateur ou un dispositif avance d’un état à un autre. Ainsi, l’interprétation d’un changement de contexte, comme une trajectoire d’état, permet de prévoir le développement futur de la trajectoire, et par conséquent prédire le contexte attendu. Figure 19. Architecture de prédiction de contexte ( d’après (Mayrhofer, 2004)) Mayrhofer (Mayrhofer, 2004) propose un processus en cinq étapes illustré à la Figure 19, qui prend en entrée des séries temporelles (ensembles d’observations, chacune enregistrée à un temps précis) et qui offre en sortie le contexte courant de l’utilisateur (ou d’un dispositif) ainsi que son contexte futur prédis. L’étape d’acquisition de contexte se charge de collecter les informations contextuelles à partir d’un ensemble de capteurs physiques ou logiques. Les données ainsi capturées sont transformées en des caractéristiques (features) plus significatives lors de l’étape d’extraction des caractéristiques afin de mieux les interpréter. Ensuite l’étape de classification se charge de reconnaître les patrons récurrents, appelés clusters, dans l'espace des caractéristiques définies lors de l’étape précédente. Cette approche de classification utilise un vecteur de caractéristiques lequel peut éventuellement être affecté à plusieurs clusters avec certains Extraction Caractéristiques Classification Etiquetage Capteurs PredictionSystèmes(d’Information(Pervasifs(et(l’orientation(service 83 degrés d'appartenance. Ce degré représente la probabilité que le vecteur de caractéristiques appartienne à un cluster. Cette étape repose sur une extension de l’algorithme de classification LLGNG (Lifelong Growing Neural Gas) (Hamker, 2001). Enfin, l’étiquetage affecte des noms descriptifs aux clusters individuels ou aux combinaisons de clusters. Une fois les clusters identifiés, l’étape de prédiction va essayer de prédire le cluster de contexte futur sur la base de l'historique observé. Cette étape s'appuie sur le vecteur de clusters généré par l'étape de classification. Cela permet de prévoir plus qu'une future meilleure correspondance de contexte en exploitant les degrés appartenance aux clusters. L'objectif est de générer des vecteurs de cluster pour des points dans le futur, qui correspondent au vecteur de cluster courant fourni par l'étape de classification. Cela permet d’alimenter les vecteurs de clusters prévus (prédis) dans l'étape d'étiquetage pour fournir des étiquettes de contextes prévus pour une utilisation dans des applications dynamiques. 3.5.3.1.2. L’approche proposée par Sigg et al. Semblable à Mayrhofer (Mayrhofer, 2004), Sigg et al. (Sigg, 2008) (Sigg et al., 2010) proposent une définition formelle de la tâche de prédiction de contexte répondant à la problématique posée sur la qualité de contexte et sur la prise en compte de l’ambiguïté de cette information qui peut être incomplète (cf. section 2.3.4.1). Ils proposent une architecture de prédiction de contexte basée sur une méthode d'alignement, à partir de laquelle les informations de contexte manquantes sont déduites. L’architecture proposée par Sigg et al. (Sigg et al., 2010), à l’instar de Mayrhofer (Mayrhofer, 2004), est aussi basée sur des patrons de contexte type que l’algorithme d’apprentissage construit pour guider le module de prédiction. Ceux-ci sont composés de séries temporelles auxquelles on attribue des poids décrivant l’importance attachée à chacune. Ainsi, si la série temporelle observée est identique ou similaire à un patron de contexte, alors le poids attaché à l’alignement dans la base est renforcé. Dans le cas contraire, un nouvel alignement est rajouté à la base et les poids des autres patrons de contexte qui sont différents du nouveau patron de contexte observé sont réduits. Ces séries temporelles représentent l'historique de contexte. Elles sont alimentées par toutes les sources de contexte disponibles dans la couche d'acquisition de contexte de l’architecture. Le module de prédiction de contexte se base sur une méthode d’alignement, permettant de prédire la continuation la plus probable d’une série temporelle à partir du suffixe de la séquence observée. Cette approche de prédiction par alignement cherche à aligner deux chaînes à l'aide de leurs écarts de sorte que le nombre de positions correspondant aux deux chaînes soit maximisé. Enfin Sigg et al. (Sigg et al., 2010) proposent également un module d’apprentissage continu dans le but de s’adapter à l'évolution des environnements ou des habitudes des utilisateurs. Il surveille en permanence les séries temporelles enregistrées dans l'historique de contexte et met à jour les patrons enregistrés. Cependant, dans le cadre de ces travaux, ces auteurs ne proposent aucune implémentation spécifique pour ce module d’apprentissage. Seules les conditions requises pour celui-ci sont indiquées, notamment Systèmes(d’Information(Pervasifs(et(l’orientation(service 84 l'interface spécifiée par l'historique de contexte et le langage de description des règles, représentant les patrons. 3.5.3.1.3. L’approche SCP Meiners et al. (Meiners et al., 2010) proposent une approche de prédiction de contexte nommée SCP (Structured Context Prediction). Celle-ci est basée sur deux principes clés. Le premier repose sur l’utilisation des connaissances du domaine d'application que les développeurs peuvent intégrer au moment du design. Ces connaissances sont décrites selon un modèle de prédiction qui spécifie la manière dont les prédictions doivent être exécutées et qui configure le système de prédiction. Le deuxième principe expose l’application de plusieurs méthodes de prédiction, qui sont échangeables. Ces méthodes sont proposées afin d’assurer l'exactitude et l'efficacité des prédictions spécifiques à un domaine. Elles peuvent être choisies et combinées par les développeurs d'applications. D’après (Meiners et al., 2010), le modèle de prédiction attribue une méthode pour chaque variable afin de prédire sa valeur. La méthode utilise comme entrée les valeurs d'autres variables qui sont soit prédites par leurs propres méthodes, soit connues (mesurables par des capteurs). Figure 20. Architecture du système de prédiction selon l'approche SCP (d’après (Meiners et al., 2010)) De plus, ces auteurs proposent une architecture pour un système de prédiction qui peut être utilisé comme un composant réutilisable par des applications sensibles au contexte. Cette architecture, comme l’illustre la Figure 20, se base sur quatre éléments principaux. Le premier représente le composant de connaissances, lequel contient les connaissances sur les relations, les caractéristiques et les régularités qui déterminent le contexte. Ce composant est constitué d’un modèle de prédiction et des instances de données. Ensuite, cette architecture comporte le composant d'acquisition de données qui se charge d'acquérir des données de contexte. Un troisième composant, celui de l'apprentissage, obtient régulièrement des données de contexte du composant d'acquisition et les affecte aux méthodes de prédictions comme des données d'apprentissage. Ensuite, ce composant crée et met à jour les connaissances en utilisant les Application Apprentissage Prediction Connaissance Acquisition de données Instance de données Modèle de prediction methode methode methode Modèle de prédiction ... Développeurs d'application données de contexte relation d'utilisation lire / stocker / transmettre flux de données de contexte Systeme de prédictionSystèmes(d’Information(Pervasifs(et(l’orientation(service 85 résultats de l’exécution de ces méthodes. Le dernier composant représente celui de la prédiction. Il utilise les connaissances acquises pour la prédiction effectuée sur demande. Ce composant repose sur un algorithme proposé par (Meiners et al., 2010) qui se charge de coordonner l’ensemble de méthodes. Cet algorithme est inspiré de l’algorithme « Stochastic Simulation » (Jensen, 2001) initialement développé pour les réseaux bayésiens. 3.5.3.2. Systèmes de recommandation centrés sur le contexte Dans le cadre de la prédiction de services, nous avons souligné, à travers la littérature, des contributions dans le domaine de la recommandation de services. Ces contributions sont similaires aux approches de prédiction puisqu’elles cherchent à proposer les prochains services qui peuvent intéresser l’utilisateur et répondre à son besoin futur. 3.5.3.2.1. L’approche proposée par Abbar et al. Abbar et al. (Abbar et al., 2009) fournissent une approche, dans laquelle les services sont recommandés sur la base des fichiers log de l'utilisateur et de son contexte courant. Ces auteurs proposent un système de recommandation sensible au contexte nommé CARS – (Context-Aware Recommender System), qui se base sur le profil de l’utilisateur et sur son contexte. Cette approche utilise une architecture, sur laquelle un ensemble de concepts génériques (profil de l’utilisateur, utilisateur actif, contexte, contexte actif, profil contextualisé et profil opérationnel) et de services de personnalisation (découverte de services, contextualisation des services, service de liaison, service de mise en correspondance) sont déployés afin de rendre une application sensible au contexte. Figure 21. Architecture du système de recommandation sensible au contexte (d’après (Abbar et al., 2009)) Cette architecture, comme l’illustre la Figure 21, se répartie en deux processus. Le premier est le processus d’acquisition de la connaissance qui se charge d’acquérir et de gérer les connaissances (profil de l’utilisateur, description du contenu et du contexte) dont CARS a Profils Profils Contextualisés Contenu Liste Recommandations Logs/ Feedbacks Acquis. Profil Contextualisation Acquis. Contexte Acquis. Contenu Moteur de Recommandation Processus de Recommandation Personnalisée Processus d'Acquisition de Connaissances ContexteSystèmes(d’Information(Pervasifs(et(l’orientation(service 86 besoin pour la recommandation des services. Dans ce processus, l’acquisition de contexte se base sur les logs contenant un ensemble d’enregistrements lesquels contiennent à leur tour les informations contextuelles (date, temps, dispositif, etc.). Ces enregistrements sont regroupés en un ensemble de clusters qui représentent le contexte régulier. Ce processus utilise d’abord l’algorithme « Agglomerative Hierarchical Clustering » (AHC) pour estimer le nombre de clusters. Le nombre de clusters retrouvés ainsi que les enregistrements représentent, par la suite, l’entrée de l’algorithme « K-means » utilisée pour déterminer les clusters. De plus, ce processus inclut une étape de contextualisation du profil de l’utilisateur laquelle se charge de découvrir les relations entre les éléments de contexte et les profils de l’utilisateur. Le deuxième processus représente le processus de recommandation personnalisée proprement parlé. Le moteur de recommandation accepte comme entrée le profil contextualisé de l’utilisateur ainsi que son contexte courant. Au cours de ce processus, un algorithme appelé « Top Contextual K Neighbors » est appliqué afin de déterminer un nombre « K » d’utilisateurs qui sont les plus similaires à l’utilisateur actif par rapport à son profil. Ensuite, dès que les K plus proches des voisins sont déterminés, les classements attribués aux éléments à recommander sont agrégés. Le résultat d’agrégation permet de décider s’il est pertinent ou pas de recommander un certain item représentant le service à recommander à l’utilisateur. Comme pour les autres approches de prédiction de contexte, cette approche nécessite, afin de sélectionner et de recommander des services, des données historiques (log), qui ne sont pas toujours disponibles. En effet, elle a besoin d’une première phase de collecte afin d’obtenir suffisamment de données qui vont être traitées par la suite. De ce fait, les premières recommandations de services peuvent être biaisées et surtout peuvent ne pas intéresser l’utilisateur puisqu’elles ne sont pas déduites à partir de ses habitudes. 3.5.3.2.2. Approche proposée par Xiao et al. A l’encontre de l’approche précédente, l’approche proposée par (Xiao et al., 2010) propose une procédure de recommandation de services sans compter sur des fichiers logs. Ces auteurs (Xiao et al., 2010) proposent une approche qui détermine dynamiquement un modèle de contexte. Ce modèle gère divers types et valeurs contextuels, et recommande ensuite des services en utilisant ces informations. Cette approche utilise les ontologies pour améliorer la sémantique des valeurs de contexte associées à un utilisateur et identifie automatiquement les relations entre ces différentes valeurs. Ces auteurs se basent sur les relations entre les valeurs de contexte afin de trouver les services potentiels dont l'utilisateur pourrait avoir besoin. Une relation définit la façon dont les classes ou les individus peuvent être associés entre eux dans une ontologie. Elle peut être soit une relation prédéfinie par l’ontologie (subclass, partOf, complement ou equivalence), soit une relation spécifique représentée par les propriétés de l’ontologie. Au lieu de définir manuellement les règles de type si-alors en utilisant des types de contexte spécifiques ou des valeurs prédéfinies, cette approche utilise les relations entre les valeurs de contexte afin de déduire le contexte dans lequel émerge les besoins des utilisateurs. Systèmes(d’Information(Pervasifs(et(l’orientation(service 87 La Figure 22 présente un aperçu de cette approche. Pour identifier les relations, une recherche des ontologies disponibles pour étendre la sémantique des valeurs de contexte est effectuée. Les relations identifiées sont utilisées afin de découvrir le contexte dans lequel les besoins des utilisateurs sont exprimés. Ceci conduit à la génération des critères de recherche des services correspondants. Ces critères sont utilisés à leur tour pour la recherche de nouveaux services, permettant au système de recommander ces services aux utilisateurs. Figure 22. Les étapes de l'approche de recommandation de services sensibles au contexte (Xiao et al., 2010) Les relations de contexte sont de deux types, les relations entre deux valeurs de contexte et les relations entre multiples valeurs. Les relations entre deux valeurs de contexte identifient deux entités appartenant à des ontologies différentes, en se basant sur la similarité entre elles. Cette similarité peut être entre deux propriétés atomiques (si elles ont le même nom et la même valeur de propriété), ou entre deux classes ou deux propriétés non atomiques (si elles ont le même nom ou n’importe quelle propriété définie dans l’une est similaire à une propriété dans l’autre). En se basant sur cette similarité, quatre relations peuvent être identifiées entre deux valeurs de contexte, à savoir : intersection, complémentaire, équivalence et indépendance. Les relations entre multiples valeurs de contexte sont décrites à l’aide du modèle E-R (Entity Relationship). Pour chaque relation entre deux valeurs, les valeurs sont converties en entités du modèle et les types de relations en nœuds de relation dans le modèle. Concernant la génération des critères de recherche, cette approche définie des règles génériques pour inférer les besoins des utilisateurs à partir du modèle E-R. Ensuite, elle extrait les critères de recherche (mots clés) de la description des besoins des utilisateurs pour rechercher les services à recommander. 3.6. CONCLUSION ET CONSIDERATIONS FINALES Dans ce deuxième chapitre de l’état de l’art, nous avons introduit la notion de service. Ces services se caractérisent essentiellement par leur indépendance par rapport aux aspects technologiques et à leur implémentation et ont été conçue principalement pour répondre à des besoins de réutilisation et d’interopérabilité (Papazoglou et Georgakopoulos, 2003). Dans le cadre des systèmes sensibles au contexte, multiples travaux (Maamar et al., 2006) (Baldauf et al., 2007) (Toninelli et al., 2008) (Preuveneers et al., 2009) démontrent l’intérêt de la notion de service pour l’adaptabilité d’un système. La notion de service permet ici de masquer l’hétérogénéité technologique des environnements pervasifs. Ainsi, l’orientation service permet ainsi de répondre au besoin de gestion de l’hétérogénéité des SIP et notamment des actions que ces systèmes pourront proposer pour satisfaire les besoins des utilisateurs. Types & Valeurs de contexte Services Ontologies Services Détecter contexte Recherche ontologies Identifier relations contexte Recherche services Calculer critères de recherche de servicesSystèmes(d’Information(Pervasifs(et(l’orientation(service 88 Nous avons également souligné un ensemble de challenges auxquels les SIP orientés services doivent faire face. Ces challenges représentent les éléments clés pour la construction d’un SIP proactifs et réactifs aux changements de l’environnement et aux besoins des utilisateurs. Nous nous sommes ainsi focalisés sur d’eux d’entre eux, à savoir la découverte et la prédiction de services. Nous avons ainsi exposé une multitude d’approches de découverte et de prédiction de services. Avec l’apparition du Web sémantique, différentes approches de découverte de services sémantiques, telles que (Paolucci et al., 2002) (Sycara et al., 2003) (Klusch et al., 2009), ont été proposées. Celles-ci, même si elles sont prometteuses, demeurent assez limitées quant à son emploi dans le cadre d’un environnement pervasif et donc dans les SIP. En effet, ces approches se limitent aux capacités des services en termes d’entrée et de sortie et ne prennent pas en considération le caractère dynamique de l’environnement par la prise en compte de l’information contextuelle. De plus, elles ne tiennent pas compte du besoin réel de l’utilisateur derrière sa demande d’un service. Les approches suivantes même si elles sont différentes, représentent une évolution des SI vers des SI centrés utilisateur, soit par une approche intentionnelle (Mirbel et Crescenzo, 2010b) (Aljoumaa et al., 2011) (Olsson et al., 2011), soit par une approche contextuelle (Suraci et al., 2007) (Toninelli et al., 2008) (Vanrompay et al., 2011). Cependant, les approches sensibles au contexte requièrent des connaissances techniques complexes de l’utilisateur s’il veut comprendre le choix suggéré, alors que normalement ces utilisateurs demandent simplement un service qui répond à leurs besoins. Cette problématique, est évoquée par les approches intentionnelles. Celles-ci focalisent sur les besoins des utilisateurs décrits sous forme d’intention. Toutefois, la satisfaction de ces intentions par les services peut varier selon le contexte dans lequel se situe l’utilisateur. Ces approches ne prennent pas en considération cet aspect, ce qui peut nuire au résultat proposé à l’utilisateur en lui offrant un service mal adapté à son contexte d’usage. Nous pensons que ces approches sont en réalité complémentaires, et qu’une telle évolution ne peut être atteinte véritablement que par la combinaison de ces deux approches. À notre avis, seulement un mécanisme de découverte de services basé à la fois sur le contexte et sur l'intention de l'utilisateur est en mesure de répondre à des questions telles que « pourquoi un service est utile dans un contexte donné ? » ou « dans quelles circonstances émerge le besoin d'un service ? ». Cette vision a commencé à se développer dans la littérature. Quelques auteurs, dont (Santos et al., 2009) (Ramadour et Fakhri, 2011) (Ma et al., 2011), proposent déjà d’associer ces deux notions lors de la découverte et de la composition de services. Cependant, pour beaucoup d’entre eux, cette association reste assez floue. Le contexte reste souvent confiné à un rôle de filtre pour la découverte de services, étant présenté comme une partie des entrées nécessaires aux services, alors que les intentions sont vues comme de simples étiquettes permettant de relier les demandes des utilisateurs aux services. Nous croyons, au contraire, que le contexte ne peut être réduit à de simples paramètres d’entrées ou de sorties. Non seulement il influence l’exécution du service, mais il caractérise le service luimême et les intentions affichées par le service. Systèmes(d’Information(Pervasifs(et(l’orientation(service 89 Selon notre analyse, aucun des travaux cités ne propose un mécanisme de découverte de services qui combine et exploite réellement le contexte et l'intention. Un tel mécanisme de découverte de services est essentiel dans le cadre d’un SIP transparent et centrée utilisateur, lequel doit se caractériser par son adaptabilité au contexte et sa compréhension de l’utilisateur et de ses besoins. Le même constat peut être fait pour les mécanismes de prédiction de services. Nous avons souligné deux familles d’approches intéressantes, à savoir les approches de prédiction de contexte et les approches de recommandation de services. Les approches de prédiction de contexte dans les environnements pervasifs, tels que (Mayrhofer, 2004) (Sigg, 2008) (Meiners et al., 2010), tentent de prédire le prochain contexte de l'utilisateur en fonction de son contexte courant et de son historique. Tous ces auteurs proposent des architectures et des méthodes intéressantes qui assurent la prédiction de contexte de haut et de bas niveau. Cependant, aucun de ces travaux n’associent à ce contexte les services ou les activités qu'un utilisateur invoque. Ils se focalisent uniquement sur la prédiction de contexte suivant ou la prédiction de la continuité de celui-ci, sans pour autant souligner comment ce contexte prédit est utilisé pour découvrir ou prédire le service. A l’opposé les approches de recommandation de services selon le contexte, tels que (Abbar et al., 2009) et (Xiao et al., 2010), proposent des mécanismes pour recommander le service suivant selon le contexte de l’utilisateur. La plupart de ces approches tiennent compte uniquement des informations contextuelles, sans prendre en considération les besoins réels de l'utilisateur derrière un service, c'est-à-dire, de ses objectifs. Ils proposent une mise en œuvre à l'utilisateur, en ignorant pourquoi celle-ci est nécessaire. Aujourd'hui, un enjeu important dans le domaine des SIP est de se positionner au niveau de l'utilisateur et de prendre en considération sa mobilité et la dynamique de l’environnement qui l’entoure. Les approches que nous avons présentées, que ce soit la découverte ou la prédiction de services, n’exploitent pas vraiment l’étroite relation entre la notion d’intention, qui représente le besoin de l’utilisateur, et la notion de contexte. En conséquence, plusieurs possibilités sont offertes à l'utilisateur, qui n’est pas toujours en mesure de les utiliser proprement, ni de comprendre ce qui lui est proposé. Afin de répondre aux exigences des SIP, il nous semble nécessaire de concevoir et de développer des mécanismes de découverte et de prédiction de services qui doivent être guidés à la fois par le contexte et par l’intention. Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 90 Chapitre 4. VISION INTENTIONNELLE ET CONTEXTUELLE DES SYSTEMES D’ INFORMATION PERVASIFS 4.1. INTRODUCTION Après une analyse de la littérature (cf. Chapitre 2 et Chapitre 3), nous pouvons constater que les SI traditionnels ne sont plus adaptés à l’environnement pervasif dans lequel évolue l’utilisateur actuellement. Aucun des éléments caractérisant un environnement pervasif (hétérogénéité, dynamisme, etc.) n’est particulièrement pris en compte dans ces systèmes, conçus pour les environnements de bureau stables et contrôlés. Ceci à fait apparaître une nouvelle génération des SI, les Systèmes d’Information Pervasifs. Nous proposons dans cette thèse une nouvelle vision intentionnelle et contextuelle pour la gestion de ces nouveaux Systèmes d'Information Pervasifs orientés services. Cette vision répond aux problématiques de transparence, d’adaptation à l’environnement et d’adaptation aux utilisateurs relevés dans le premier chapitre (cf. section 1.2). Notre vision est centrée utilisateur, qui devient le centre des nouveaux Systèmes d'Information Pervasifs. Ce chapitre rappelle notre contexte de recherche, à savoir les SIP, et notre problématique de départ, laquelle a conduit à notre proposition d’une vision intentionnelle et contextuelle des SIP. Nous présentons ensuite un aperçu détaillé de la solution répondant à la problématique et la mise en place des hypothèses en pratique. 4.2. RAPPEL DU CONTEXTE DE RECHERCHE ET DE LA PROBLEMATIQUE Dans cette section, nous rappelons notre contexte de recherche et la problématique qui a conduit à notre proposition (cf. Chapitre 1). 4.2.1. Contexte de recherche Comme nous l’avons présenté dans le Chapitre 2, l’Informatique Pervasive est devenue une réalité grâce à l'intégration transparente de plusieurs périphériques dans notre vie quotidienne. Les nouvelles technologies ont élargi les frontières des Systèmes d'Information (SI) en dehors de l'environnement des entreprises. Le BYOD (Bring Your Own Device) illustre assez bien cette tendance : les employés apportent leurs propres dispositifs au bureau et continuent à les utiliser pour accéder au SI, même quand ils sont en déplacement. La conséquence de cette évolution technologique est que les SI doivent maintenant faire face à un environnement pervasif, et à l'avenir, intégrer des éléments physiques ainsi que logiques et Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 91 organisationnels. Par ailleurs, dans les dernières années, les SI ont massivement adoptés une approche basée sur les services, devenant ainsi des systèmes orientés services exposant ses fonctionnalités en tant que services. Ainsi, émerge une nouvelle génération de Systèmes d'Information, appelée les Systèmes d'Information Pervasifs (SIP). Les SIP ont l'intention d’améliorer la productivité de l'utilisateur en permettant aux services d’un SI d’être disponibles à tout moment et à n’importe quel endroit. Ces systèmes déplacent le paradigme d'interaction de l'informatique de bureau aux nouvelles technologies, passant d'un environnement entièrement contrôlé (le bureau) vers un environnement pervasif hautement dynamique. 4.2.2.Problématique Les Systèmes d'Information Pervasifs doivent faire face à des environnements pervasifs, sans laisser derrière le fait qu'ils demeurent des Systèmes d'Information. Les SIP doivent faire face à l'hétérogénéité qui caractérise les environnements pervasifs. La transparence est donc nécessaire afin de cacher aux utilisateurs cette hétérogénéité des dispositifs, des infrastructures et des services. Cette transparence est d'autant plus nécessaire en raison du rôle central que jouent les SI dans les entreprises. Ces systèmes sont conçus pour aider les utilisateurs à atteindre des objectifs métiers bien précis. Par conséquent, lors de l’utilisation de tels systèmes, les utilisateurs doivent se concentrer sur leurs propres tâches/activités et non sur la technologie elle-même. Sans transparence, tout Système d'Information Pervasif ne sera pas en mesure de remplir avec succès son rôle de SI. Au cours de la dernière décennie, beaucoup de recherches ont été effectuées sur les systèmes et principalement sur les services sensibles au contexte (Maamar et al., 2006) (Toninelli et al., 2008) (Vanrompay et al., 2011) (Bronsted et al., 2010) (Truong et Dustdar, 2009). Ces travaux de recherche proposent un comportement sensible au contexte pour la découverte et la composition de services. La sensibilité au contexte devient un élément clé pour soutenir de tels environnements pervasifs. Ainsi, les Systèmes d'Information Pervasifs devraient fournir des capacités de sensibilité au contexte afin de faire face aux changements dynamiques de l'environnement et d’améliorer l'efficacité de l'utilisateur. Néanmoins, les SIP, contrairement aux systèmes pervasifs, doivent aussi se comporter comme des Systèmes d'Information traditionnels, gérant les services en fonction de l'utilisateur et des objectifs métiers. Les SIP représentent la prochaine génération des SI et ils doivent aussi faire face à ce rôle de SI. En raison de leur rôle stratégique, les SIP ne peuvent pas être conçus comme des systèmes pervasifs « normaux ». Les SIP doivent être « contrôlables » et « maîtrisables ». En d'autres termes, ils doivent être gérés et contrôlés par la Direction des Systèmes d’Information (DSI), puisqu’une exposition inappropriée d'un service interne peut avoir des conséquences importantes pour l'activité de l'entreprise. Ainsi, les comportements exploratoires et opportunistes, tels que ceux proposés par (Preuveneers et Berbers, 2010) et (Khan, 2010) ne peuvent pas être pleinement acceptés par la DSI. Ils représentent un risque pour le SI vu le rôle qu’il joue dans l’entreprise. Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 92 La conception des Systèmes d'Information Pervasifs qui réponde aux exigences des SI et des systèmes pervasifs est un défi. Les SIP sont censés être conçus pour améliorer l'efficacité de l'utilisateur en tenant compte de l’environnement pervasif dans lequel l'utilisateur émerge. Pour réussir, les SIP doivent tirer profit des opportunités offertes par les environnements pervasifs, et notamment la mobilité de l'utilisateur, tout en offrant aux utilisateurs des services du Système d'Information de manière transparente. Les SIP doivent être conçus afin de fournir les services les plus appropriés que les utilisateurs ont besoin pour satisfaire leurs objectifs dans leur situation courante. Pour récapituler, nous résumons notre problématique à un problème de conception et de réalisation d’un SIP transparent, s’adaptant à l’environnement (sensibilité au contexte) et à l’utilisateur (prise en compte des intentions et de la mobilité de l’utilisateur). A l’heure actuelle, il existe peu de modèles ou de méthodes permettant aux concepteurs et aux développeurs de prendre en compte ces besoins lors de la conception d’un SIP. Ainsi, nous avons privilégié l’axe conceptualisation du système à développer pour élaborer notre solution, à l’instar de Mathieu Petit (Petit, 2010), qui propose un cadre conceptuel pour les Systèmes d’Information mobiles et distribués (cf. section 3.5.2.2.5) exploitant des modèles géographiques. La cible du système à développer, dans notre cas, ne prend pas en considération uniquement l’aspect géographique mais s’étend plus généralement à l’adaptation à l’environnement et à l’utilisateur. 4.3. APERÇU DE LA SOLUTION La conception de Systèmes d'Information Pervasifs est un défi pour lequel la DSI n’a aucune aide. Nous soutenons que l'utilisateur doit être au centre de cette nouvelle génération de Systèmes d'Information, étant donné que ces systèmes doivent être conçus pour aider l’utilisateur à mieux satisfaire ses objectifs en fonction de l'environnement dans lequel il se trouve. En outre, cette vision devrait examiner tous les aspects des nouveaux SIP : leur besoin de transparence, l'hétérogénéité et la dynamique des environnements pervasifs, ainsi que les intentions qu'ils doivent satisfaire à partir du point de vue SI. Ainsi, nous proposons notre vision des Systèmes d’Information Pervasifs. Après notre analyse de la littérature dans le Chapitre 2 et Chapitre 3, nous avons constaté que l’orientation service, la sensibilité au contexte, ainsi que l’approche intentionnelle représentent des approches très prometteuses à prendre en considération afin de concevoir un SIP transparent, non intrusif et compréhensible à l’utilisateur. Ces approches représentent des solutions pour résoudre les problèmes que nous avons soulevés ci-dessus. Les prochaines sections résument notre vision intentionnelle et contextuelle des SIP et les différents éléments composant notre solution. Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 93 4.3.1. Notre vision intentionnelle et contextuelle des SIP : couplage entre services, contexte et intention Notre vision des Système d’Information Pervasif est basée sur les notions d’intention, de contexte et de services. Elle représente notre solution pour répondre à la problématique de recherche soulevée et pour mettre en place les hypothèses, énumérées dans la section 1.3, en pratique. Cette solution représente une vision centrée sur l’utilisateur des SIP. Elle permet, d’une part, de se focaliser plus sur les besoins réels des utilisateurs à travers une approche intentionnelle, assurant ainsi une meilleure compréhension du système des objectifs de l’utilisateur derrière sa demande de services. Elle permet, d’autre part, de gérer l’hétérogénéité et la dynamique de l’environnement pervasif à travers une approche contextuelle. En effet, nous considérons les SIP et leurs éléments à la fois sous l’angle des SI et celui des environnements pervasifs, en observant leurs besoins respectifs de contrôle, d’intentionnalité et de sensibilité au contexte. Ceci est dans la perspective d’assurer la transparence nécessaire pour la conception d’un SIP. Notre vision se caractérise par son orientation service. Selon notre analyse de l’état de l’art (cf. section Chapitre 3), nous avons soulevé la caractéristique principale de la notion de service, à savoir son indépendance par rapport aux aspects technologiques et à leur implémentation. Ainsi, une orientation service va permettre de répondre au besoin de gestion de l’hétérogénéité technique de l’environnement dans lequel évoluent les SIP et des actions que le système propose afin de satisfaire les besoins des utilisateurs. Dans notre vision, la notion de service permet de masquer l’hétérogénéité technologique des environnements pervasifs. Le concept « service » a été conçu pour répondre à des besoins de réutilisation et d’interopérabilité (Papazoglou et Georgakopoulos, 2003). Ses multiples usages dans les systèmes sensibles au contexte (cf. section Chapitre 3) démontrent également l’intérêt de la notion de service pour l’adaptabilité d’un système. De plus, afin de mieux gérer l’hétérogénéité et la dynamique qui caractérisent l’environnement pervasif, notre vision se base sur une orientation contexte. Ceci va permettre d’adapter les SIP au contexte de l’utilisateur et à l’environnement. A partir de notre analyse de la littérature, nous avons soulevé le rôle central que joue cette notion de contexte dans les systèmes sensibles au contexte (cf. Chapitre 2). Notre approche présente les SIP comme des systèmes sensibles au contexte, qui s’adaptent aux changements sans pour autant demander à l’utilisateur de s’adapter lui-même à l’environnement. Enfin, et dans la perspective de répondre au mieux aux exigences des utilisateurs et de se situer à leur niveau, notre vision des SIP est orientée intention. Ainsi, les SIP peuvent, d’une part, mieux comprendre les besoins des utilisateurs, et d’autre part, répondre d’une façon plus appropriée à ces besoins. Comme nous l’avons présentée dans la littérature (cf. section 3.4.3.1), la notion d’intention formalise, en général, les besoins de l’utilisateur. Une intention peut être considérée comme le but que nous voulons atteindre sans dire comment l'exécuter (Kaabi et Souveyet, 2007). Dans le cadre de notre vision, la notion d’intention est nécessaire afin que le système puisse mieux comprendre les besoins des utilisateurs et donc de répondre Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 94 à ses besoins de la manière la plus appropriée. En effet, l'approche intentionnelle nous permet de considérer le service du point de vue des exigences de l'utilisateur, en se concentrant sur pourquoi un service est nécessaire, et pas seulement sur comment il est exécuté. En fait, nous considérons que l'utilisateur ne nécessite pas un service uniquement parce qu'il est dans un contexte donné. Il requiert un service parce qu'il a une intention qu'un service peut satisfaire dans ce contexte d’usage (Najar et al., 2012a). Figure 23. Contexte et intention dans l'orientation service Par ailleurs, nous considérons que l’intention de l’utilisateur émerge dans un contexte donné et que ses réalisations ne sont valides que dans un contexte d’utilisation bien défini. Dans ce cadre, la notion de contexte représente un élément important dans le processus d'adaptation d’un système à l'utilisateur et à l’environnement, auquel nous souhaitons ajouter la notion d’intention. Ainsi, nous exploitons, dans notre vision des SIP, l’étroite relation entre les notions d’intention, de contexte et de service, illustrée à la Figure 23. Nous considérons que la satisfaction des intentions de l'utilisateur dans un SIP dépend du contexte dans lequel se trouve cet utilisateur. Pour nous, le contexte impacte directement la manière de satisfaire les intentions, et ainsi le choix des services qui seront exécutés. Ainsi, en combinant les approches intentionnelles et contextuelles dans une orientation service et en exploitant la relation qui les lie, nous proposons une nouvelle vision centrée utilisateur d’un SIP transparent, non intrusif et compréhensible à l’utilisateur. Nous proposons, par la suite, des solutions pour mettre en œuvre cette vision intentionnelle et contextuelle des SIP centrés utilisateur. 4.3.2.Solution globale : de la conception à la mise en œuvre d’un SIP transparent et centré utilisateurNous proposons, dans le cadre de cette thèse, une solution globale pour mettre en place notre vision intentionnelle et contextuelle des SIP orientés services. Nous proposons celle-ci dans la perspective d’aider la DSI à concevoir un SIP transparent et centrée utilisateur. Nous commençons par introduire un cadre conceptuel des SIP appelé « espace de services » (cf. Chapitre 5) afin de conceptualiser le SIP et ses différents éléments. Nous proposons ensuite une architecture de gestionnaire de SIP (cf. Chapitre 9) qui interagit avec l’espace de services afin d’assurer les fonctionnalités de découverte (cf. Chapitre 7) et de prédiction (cf. Chapitre 8) des services pour l’utilisateur. Finalement, nous proposons une démarche méthodologique Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 95 de conception et de réalisation d’un SIP qui supporte le passage du cadre conceptuel vers les descriptions de services à l’intérieur du système. Figure 24. Vision intentionnelle et contextuelle des Systèmes d'Information Pervasifs Nous proposons ainsi de présenter, comme l’illustre la Figure 24, notre solution globale selon quatre dimensions différentes : conceptuelle, fonctionnelle, système et support. Nous détaillons, dans les sections suivantes, chacune de ses dimensions. 4.3.2.1. Dimension conceptuelle : cadre conceptuel des SIP nommé « Espace de services » Dans cette thèse, nous soutenons que la conception d’un SIP est devenue un problème difficile à gérer, en raison notamment de l’immersion des fonctionnalités d’un SIP dans un environnement pervasif. Il nous faut donc un cadre conceptuel permettant de masquer l’hétérogénéité de cet environnement et de spécifier les fonctionnalités qui seront proposées par le SIP et sous quelles conditions, et ceci de manière indépendante des technologies. La notion d’espace de services que nous proposons (cf. Chapitre 5) s’attaque à cette question. Dans un espace de services s’intègrent, de manière transparente, l’ensemble des services offerts par le SI traditionnel (services logiques) et ceux offerts par l’environnement physique, grâce à l’intégration de différentes technologies dans cet environnement (services physiques), ainsi qu’un ensemble de capteurs qui renseignent l’utilisateur et le système sur cet environnement. La notion d’espace de services est un outil conceptuel permettant de gérer l’hétérogénéité des environnements pervasifs et des SIP déployés sur ces environnements, ce qui offre aux concepteurs des SIP les moyens d’analyser de manière abstraite l’interaction entre un utilisateur et le système. Ce cadre conceptuel vise à aider le concepteur à identifier les descriptions des services que l’utilisateur a besoin dans son SIP. Cet espace de services représente la partie générique de cette dimension conceptuelle puisqu’il représente un cadre conceptuel indépendant de la mise en œuvre des SIP et donc des modèles de contexte et des approches de services choisis pour son implémentation. Toutefois, Vision intentionnelle et contextuelle des SIP Dimension Fonctionnelle (2) Découverte de services & Prédiction de services Dimension Support (4) Dimension Conceptuelle (1) Espace de Services Dimension Système (3) Architecture de gestionnaire des SIP Démarche Méthodologique de conception d'un SIP - Ontologie multi-niveaux de contexte - OWL-SICVision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 96 cette dimension conceptuelle intègre une partie spécifique nécessaire pour mettre en place notre vision intentionnelle et contextuelle des SIP. Nous proposons ainsi de décrire sémantiquement, selon cet espace de services, les services en incluant ces informations intentionnelles et contextuelles. L’objectif ici est de proposer des services de haut niveau, permettant de cacher la complexité technique de l’environnement due, entre autres, aux différentes technologies et services proposés. Ces services sont décrits selon le contexte dans lequel ils s’adaptent au mieux et les intentions qu’ils peuvent satisfaire. Ceci est basé sur une extension de OWL-S nommée OWL-SIC (OWL-S Intentional & Contextual) (cf. Chapitre 6). De plus, nous proposons dans ce cadre conceptuel de modéliser sémantiquement les informations contextuelles relatives aux éléments de l’espace de services et à l’utilisateur. Nous proposons une ontologie multi-niveaux de contexte (cf. section 6.4.1). L’espace de services est présenté plus en détails, dans le cadre du Chapitre 5 qui illustre une conceptualisation de cet espace à travers la formalisation de ses différents éléments, services et capteurs de contexte, et la présentation de ses différentes caractéristiques, dynamisme et perméabilité. 4.3.2.2. Dimension fonctionnelle : Découverte et prédiction de services selon l’intention et le contexte Un utilisateur interagit avec son SIP à travers l’espace de services. Il souhaite, dans le cadre d’un SIP, avoir des services qui répondent à ses besoins dans un contexte donné et en toute transparence. Ainsi, l’utilisateur expose son besoin au système, qui se charge de lui proposer des services en réponse à ce besoin et éventuellement à des besoins futurs (subséquents au besoin présent). Les services proposés sont sélectionnés comme étant ceux qui répondent au mieux à ses intentions dans son contexte courant et ceux considérés comme les plus appropriés en fonction de l’usage de l’utilisateur. L’intention de l’utilisateur est valable dans un contexte donné tout comme le contexte influence la satisfaction de cette intention. Nous pensons, ainsi, que les deux approches, sensibles au contexte et intentionnelles, sont complémentaires et ne doivent pas être isolées les unes des autres. Nous pensons que, en tenant compte de ces deux aspects dans le cadre d’un SIP orienté services, il est possible de proposer à l’utilisateur des services qui peuvent mieux satisfaire ses intentions dans son contexte courant, renforçant ainsi la transparence du SIP. Cela peut être fait par la proposition de nouveaux mécanismes de découverte de services qui adoptent cette approche duale (intentionnelle et sensible au contexte), mais aussi par la proposition de nouveaux mécanismes de prédiction qui ont l'intention d'anticiper les besoins de l'utilisateur en fonction de ses intentions antérieures sur des contextes similaires. Aujourd'hui, un enjeu important dans le domaine des SIP est de se positionner au niveau de l'utilisateur et de prendre en considération sa mobilité et le dynamisme de l’environnement qui l’entoure, sans pour autant perdre les moyens en termes de maîtrise et de contrôle. Ainsi, après une analyse de la littérature, nous avons constaté également que parmi les importants challenges des SIP, la découverte et la prédiction dynamique des services représentent deux Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 97 mécanismes permettant de satisfaire les besoins de l’utilisateur en lui offrant le service le plus approprié assurant ainsi la dynamique et la pro-activité des SIP. Toutefois, aucune des approches étudiées, par exemple (Toninelli et al., 2008)(Vanrompay et al., 2011)(Mirbel et Crescenzo, 2010a)(Olsson et al., 2011)(Santos et al., 2009)(Ramadour et Fakhri, 2011), n’exploite réellement l’étroite relation entre les approches intentionnelles et contextuelles. En conséquence, plusieurs possibilités sont offertes à l'utilisateur, qui n’est pas toujours en mesure de comprendre ce qui lui est proposé. Selon notre étude de l’état de l’art, aucun des travaux analysés dans la section 3.5.2 ne propose un mécanisme de découverte de services qui combine et exploite réellement le contexte et l'intention. Un tel mécanisme de découverte de service guidé par le contexte et l’intention est nécessaire dans le cadre d’un SIP transparent et centrée utilisateur, et qui se caractérise par son adaptabilité au contexte et sa compréhension des besoins réels de l’utilisateur et de ses besoins. À notre avis, seulement un mécanisme de découverte de services basé à la fois sur le contexte et sur l'intention de l'utilisateur est en mesure de répondre à des questions telles que « pourquoi un service est utile dans un contexte donné ? » ou « dans quelles circonstances émerge le besoin d'un service ? ». Une découverte dynamique des services est un mécanisme essentiel pour les SIP parce qu’il permet de répondre au mieux aux besoins de l’utilisateur. La prise en compte de la notion d’intention dans ce mécanisme permet de bien comprendre le réel besoin derrière la demande de l’utilisateur, appuyant ainsi le caractère centré utilisateur des SIP. De plus, la prise en compte de la notion de contexte, permet à ce mécanisme de découvrir le service qui pourra être réellement exécuté, lors de l’invocation du service, en se basant sur le contexte de l’utilisateur et sur le contexte dans lequel ce service est exécutable, assurant ainsi une meilleure adaptation à l’environnement. Ainsi la découverte de service joue un rôle important dans l’amélioration de la transparence des SIP, en proposant à l’utilisateur le service le plus approprié selon son intention et son contexte courant. Toujours d'après notre analyse de la littérature (cf. section 3.5.3) les approches de prédiction se concentrent plus sur les mécanismes de prédiction de contexte suivant ou de prédiction de la continuité de contexte, sans pour autant souligner comment ce contexte prédit est utilisé pour découvrir et prédire le service suivant, par exemple. De plus, la plupart des systèmes de recommandation qui ont été étudiés se basent uniquement sur les informations contextuelles afin de proposer le service suivant aux utilisateurs, sans pour autant tenir compte des besoins réels de l'utilisateur derrière sa demande du service, c'est-à-dire, de ses objectifs. Ils proposent une certaine réalisation du service à l'utilisateur, tout en ignorant pourquoi ce service est nécessaire. Nous soulevons ainsi le besoin de concevoir de nouveaux mécanismes de prédiction pour les SIP afin d'anticiper les besoins futurs de l'utilisateur en fonction de ses intentions antérieures sur des contextes similaires. Ce mécanisme introduit des techniques de recommandation afin d’augmenter le caractère dynamique et proactif des SIP en suggérant à l’utilisateur, d’une manière transparente, le service le plus approprié qui pourra, par la suite, Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 98 l’intéresser. L’objectif est de mieux comprendre les besoins de l’utilisateur afin de l’aider à y répondre d’une manière non intrusive. Ceci nous permettra d’offrir une meilleure pro-activité du système par la prise en compte de la relation entre la notion de contexte et les intentions, permettant ainsi de contribuer à l’amélioration de la transparence nécessaire des SIP. Ainsi, afin de construire un SIP transparent, centré utilisateur et proactif, il est essentielle de se positionner au niveau de l’utilisateur afin de lui proposer les services les mieux adaptés à son contexte et qui répondent au mieux à ses besoins, ceci en se basant sur des mécanismes de découverte et de prédiction de services guidées par le contexte et l’intention. 4.3.2.3. Dimension système : Architecture de gestionnaire de SIP Pour mettre en place notre vision intentionnelle et contextuelle des SIP conformément à l’espace de services, nous proposons une architecture de gestionnaire de SIP (cf. Chapitre 9) offrant essentiellement des modules de gestion de contexte, de découverte de services et de prédiction de services nécessaires pour l’utilisateur. Cette architecture intègre nos différentes propositions pour la construction d’un SIP transparent et centré utilisateur : • Un gestionnaire de contexte conforme à l’espace de services qui se chargera de l’acquisition des données contextuelles, à travers un ensemble de capteurs, et de la dérivation et de la modélisation de toutes les informations contextuelles des différents éléments de l’espace de services (services et capteurs) et celui de l’utilisateur (cf. section 9.3.2) ; • La mise en œuvre du processus de découverte de services (cf. section 9.3.4), dont l’objectif est de satisfaire au mieux les besoins de l’utilisateur (formulés en termes d’intentions) dans son contexte courant, en lui proposant le service le plus approprié en toute transparence. Cette mise en œuvre se base sur l’implémentation d’un algorithme de mise en correspondance (matching) qui calcul le degré de mise en correspondance entre l’intention et le contexte courant de l’utilisateur et l’ensemble des services sémantiques décrit selon OWL-SIC (cf. Chapitre 6) et disponible dans le répertoire de services sémantique (cf. section 9.3.3) ; • La mise en œuvre du processus de prédiction de services (cf. section 9.3.6), dont l’objectif est d’introduire des techniques de recommandation afin d’augmenter le caractère dynamique de l’architecture en suggérant à l’utilisateur, d’une manière transparente, le service le plus approprié qui pourra, par la suite, l’intéresser. 4.3.2.4. Dimension support : démarche méthodologique de conception des SIP Pour la mise en œuvre et la réalisation de notre vision des SIP et afin de faciliter et d’organiser la conception de l’espace de services, nous proposons une démarche méthodologique de conception à destination des concepteurs des SIP. Cette démarcheVision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 99 supporte le passage du cadre conceptuel vers la description des services proposés au sein de l'architecture de gestionnaire de SIP. Notre objectif est d’aider la DSI à spécifier les fonctionnalités attendues de leur système, ainsi que les informations contextuelles qui seront capturées par celui-ci pour une meilleure adaptation. Il s’agit d’un processus de conception d’un espace de services et de ses différents éléments dans la perspective de garder le contrôle sur la définition du système et de ses services, tout en permettant la prise en compte d’un environnement hautement dynamique. 4.3.3. Contributions attendues A travers ces différentes propositions, cette thèse vise à contribuer au domaine des SIP à différents niveaux : • Au niveau conceptuel de notre vision d’un SIP : o D’abord par la notion d’espace de services qui constitue un cadre conceptuel indépendant d’une approche spécifique de modélisation de contexte et de services, permettant la spécification des fonctionnalités proposées par un SIP à ses utilisateurs ; o La proposition d’un cadre d’analyse et de comparaison des modèles de contexte. L’objectif est d’aider à la compréhension et à l’analyse de la notion de contexte afin de mieux la représenter et la prendre en charge ; o L’extension de la description sémantique des services OWL-SIC, permettant la prise en considération de l’intention que le service permet d’atteindre et du contexte dans lequel ce service est valide et exécutable, ainsi que ces conditions contextuelles, dans les descriptions des services. • Au niveau de l’implémentation de notre vision d’un SIP : o La définition d’une architecture de gestionnaire de SIP orientée services, intention et contexte. Cette architecture intègre des modules de gestion de contexte, de découverte et de prédiction de services. Ces services, plus précisément leurs descriptions, sont enregistrés dans un répertoire sémantique de services, alors que les traces de leur usage sont enregistrées dans un répertoire de traces ; ! La proposition et le développement d’un processus de découverte de services. Ce processus permet de découvrir et de sélectionner le service le mieux adapté afin de satisfaire le besoin de l’utilisateur dans un contexte donné, tout en masquant la complexité de l’environnement et en assurant une meilleure compréhension de l’utilisateur ; ! La proposition et le développement d’un processus de prédiction de services, permettant de prédire, à partir de l’historique de l’utilisateur et Vision(intentionnelle(et(contextuelle(des(Systèmes(d’Information(Pervasifs 100 à partir de son intention et de son contexte courant, les services répondant à son intention future, avant même de le demander. • Au niveau de la mise en œuvre de notre vision d’un SIP : o La définition d’une démarche méthodologique permettant d’aider les concepteurs à définir leurs espaces de services, le modèle de contexte nécessaire, ainsi que la description sémantique de ces services ; o La proposition d’un cas d’étude permettant d’illustrer le déroulement des différentes étapes de ce travail de thèse et d’évaluer notre proposition. 4.4. CONCLUSION Dans ce chapitre nous avons présenté un aperçu de la solution proposée dans cette thèse. L'objectif auquel doit répondre celle-ci est de concevoir et mettre en place un SIP transparent et centré utilisateur, permettant ainsi à un SI maitrisable d’évoluer dans le cadre d’un environnement pervasif. Pour ce faire, nous avons d'abord introduit une nouvelle vision intentionnelle et contextuelle des SIP. Cette vision présente les SIP orientés services qui exploitent l’étroite relation entre l’intention et le contexte. Cette vision a été concrétisée, par la suite, selon quatre dimensions. La première dimension expose l’aspect conceptuel de notre solution. Nous proposons, dans cette partie, un cadre conceptuel permettant de guider la conception des SIP et de ses différents éléments. La deuxième dimension présente l’aspect fonctionnel de notre vision. Nous proposons dans ce cadre de nouveaux mécanismes de découverte et de prédiction de services répondants mieux aux attentes des utilisateurs selon leurs intentions et contexte. La troisième dimension expose l’aspect architectural de notre solution par la présentation d’une architecture de gestionnaires des SIP. Finalement, la quatrième dimension supporte le passage du cadre conceptuel à la mise en place de cette vision intentionnelle et contextuelle des services, par la proposition d’une démarche méthodologique. Les chapitres suivants de cette thèse détaillent le contenu de cette solution et sont organisés de la façon suivante : • Le Chapitre 5 présente le cadre conceptuel à travers notre notion d’espace de services ; • Le Chapitre 6 explique notre description des services intentionnels et contextuels qui composent notre espace de services, en présentant notre extension de OWL-S ; • Le Chapitre 7 et Chapitre 8 discutent et évaluent nos mécanismes de découverte et de prédiction de services selon l’intention et le contexte ; • Le Chapitre 9 décrit l'architecture de gestionnaire de SIP en présentant les composants essentiels qui la constituent et les interactions possibles entre ses composants ; • Le Chapitre 10 illustre notre démarche méthodologique de conception des SIP et présente un cas pratique d'application de notre approche. Cadre(conceptuel(d’un(SIP :(Espace(de(services 101 Chapitre 5. CADRE CONCEPTUEL D’UN SIP : ESPACE DE SERVICES 5.1. INTRODUCTION Le but d’un Système d’Information Pervasif (SIP) est de rendre accessibles les fonctionnalités offertes par le SI à travers un environnement pervasif. Pour ce faire, les SIP doivent faire face à un certain nombre de problèmes, qu’on a cités dans le Chapitre 4, à savoir le problème de transparence lors de la gestion de l’hétérogénéité des environnements et des services, le problème d’adaptation à l’environnement dynamique tout en gardant la maitrise du SIP et le problème d’adaptation à l’utilisateur afin de répondre à ses besoins de la manière la plus appropriée et de manière complètement transparente pour l’utilisateur. Face à ces problèmes, la spécification d’un tel SIP devient ainsi un problème complexe à gérer. C’est d’autant plus vrai que l’immersion des fonctionnalités du SI dans un environnement pervasif expose celui-ci aux risques de perte de contrôle et de maitrise du SI dans un environnement pervasif fortement hétérogène et hautement dynamique. Appliquer un comportement totalement dynamique, avec (i) une prise en compte opportuniste des ressources disponibles dans l’environnement et (ii) l’autogestion des services offerts, peut constituer une menace pour le SI (par exemple, l’utilisation d’un composant non-certifié ou tout simplement, nonaligné aux stratégies de l’entreprise). Avec le manque de modèle et de formalisme permettant de prendre en compte tous ces besoins de transparence, d’adaptation à l’environnement et d’adaptation à l’utilisateur d’un SIP, la DSI se trouve face à de grandes difficultés qui rendent difficile la conception et la réalisation d’un SIP transparent et centré utilisateur. Nous proposons pour lever ces difficultés un cadre conceptuel, que nous appelons « espace de services », facilitant le passage d’un SI existant vers un SIP. Nous partons du principe qu’un SI traditionnel est déjà mis en place et que le futur SIP ne sera pas construit à partir de rien. Il s’agit surtout d’une évolution d’un SI vers un SIP en se basant sur un espace de services. Celui-ci permet, d’une part, de masquer l’hétérogénéité caractérisant l’environnement pervasif et, d’autre part, de comprendre et de décrire les fonctionnalités proposées et leurs conditions d’usage indépendamment des technologies utilisées. Ce cadre conceptuel, appelé espace de services, est construit selon le point de vue du SI en mettant en avant les composants majeurs de celui-ci qui sont (1) les services offerts à l’utilisateur et (2) les capteurs qui renseignent sur le contexte de l’utilisateur. Il est à noter que ces deux types de composants sont décrits d’une manière conceptuelle et indépendamment des aspects implémentations. De plus, ce cadre préconise aux fournisseurs de décrire les services qu’ils proposent en fonction des objectifs qu’ils permettent de satisfaire indépendamment de la manière dont ils sont réalisés. Cadre(conceptuel(d’un(SIP :(Espace(de(services 102 Ce cadre conceptuel, appelé espace de services, représente un outil guidant la conception d’un SIP et l’identification des différents éléments qui le constituent, indépendamment de l’implémentation. Cette notion d’espace de services est définie dans l’optique de présenter un cadre conceptuel indépendant de la mise en œuvre des SIP et donc des modèles de contexte et des approches de services choisis pour son implémentation. Ce cadre conceptuel peut fonctionner sur n’importe quelle réalisation de SIP puisqu’il est générique et indépendant de la couche technique. Selon notre analyse de la littérature (cf. section 2.3.2), nous avons souligné quatre approches de modélisation de contexte, à savoir la modélisation basée sur les clés-valeurs (cf. section 2.3.2.1), la modélisation basée sur le balisage (cf. section 2.3.2.2), la modélisation orientée objet (cf. section 2.3.2.3) et la modélisation basée sur les ontologies (cf. section 2.3.2.4). De plus, nous avons détectés différentes approches de services, à savoir les approches des services Web (cf. section 3.4.1), des services sémantiques (cf. section 3.4.2) et des services intentionnels (cf. section 3.4.3). Ainsi, nous proposons un cadre conceptuel qui décrit d’une manière générique la notion de contexte et de service afin de fonctionner sur l’ensemble des modélisations de contexte et des approches de services citées ci-dessus. Cet espace de services représente une vision conceptuelle de la dynamique et de l’évolution d’un SIP. Selon notre analyse de la littérature (cf. section 2.4), nous avons constaté que les SIP demeurent une nouvelle génération de SI sans un usage concret dans le milieu professionnel et qui jusqu’à présent n’ont pas été véritablement mis en place avec des formalismes appropriés. Ainsi, l’espace de services va permettre, d’une manière conceptuelle, de rendre explicite la dynamique de SIP, en représentant les différents éléments qui le composent à différents niveaux d’abstraction. Ceci va permettre d’avoir une idée sur le SIP à mettre en place ainsi que ses différents éléments, indépendamment de l’implémentation. Dans le cadre de cette thèse, l’espace de services est un cadre conceptuel offrant un guide de conception pour identifier, décrire et valider les différents composants constituant l’espace de services en fonction des souhaits de l’entreprise et des utilisateurs ciblés par le SIP. Il représente un outil conceptuel pour aider le concepteur des SIP (la DSI), dont le but est d’assurer le maintien et le contrôle du Système d’Information même dans un environnement pervasif dynamique. Ce cadre de base est ensuite utilisé pour définir l’architecture de gestionnaire de services (cf. Chapitre 9) qui intègrera les mécanismes de découverte et de prédiction de services. Cette notion d’espace de services nous permet d’analyser de manière abstraite l’interaction d’un utilisateur avec un SIP, comme l’illustre la Figure 25. L’utilisateur interagit avec le SI à travers l’espace de services dans lequel s’intègrent, de manière transparente, l’ensemble des services offerts par le SI et l’ensemble de capteurs qui renseignent l’utilisateur et le système sur le contexte. Cadre(conceptuel(d’un(SIP :(Espace(de(services 103 Figure 25. Dans un SIP, l'utilisateur interagit avec le système à travers un espace de services pervasif Dans le cadre de ce chapitre, nous définissons la notion d’espace de services ainsi que les différents éléments qui le composent. L’ordre de présentation des éléments suit le point de vue du concepteur du SIP. Nous commençons par les fonctionnalités du système, qui seront représentées par le terme de services. L’environnement dans lequel évoluent ces services étant primordial dans un système pervasif, nous décrivons ensuite la manière dont nous modélisons cet environnement, sous le terme de contexte. Un service est choisi par rapport à son contexte et au contexte de l’utilisateur. Nous commençons par observer le contexte courant de l’utilisateur. Ce contexte correspond à l’observation d’un ensemble d’éléments qui entoure l’utilisateur à un instant t. Grâce à cette observation, nous sélectionnons par la suite le service qui répond au mieux à ce contexte de l’utilisateur. Le contexte courant de l’utilisateur est ainsi comparé aux conditions contextuelles associées aux services afin de sélectionner ceux qui peuvent opérer dans l’environnement courant de l’utilisateur. Ces informations relatives au contexte sont obtenues grâce à des capteurs sensibles à l’environnement. Ces capteurs font, selon nous, partie intégrante de l’espace de services et nous proposons une manière de les inclure dans cet espace au même titre que les services. L’espace de services formalise le support contextuel que le SIP fournit à l’utilisateur. Ce support se concrétise à travers un ensemble de services offerts et un ensemble de capteurs permettant l’observation de contexte. Il est à noter que la formalisation de l’espace de services se focalise sur ces entités fournies par le SIP et l’utilisateur n’en est que le bénéficiaire. 5.2. FORMALISATION DE LA NOTION DE SERVICE DANS UN SIP La notion de service correspond à un concept largement répandu dans la littérature, défini de multiples façons. Parmi les nombreuses définitions existantes, et que nous avons présentées dans la section 3.2, nous citons, par exemple, la définition proposée par (Papazoglou et Georgakopoulos, 2003) (Papazoglou et al., 2008) qui considèrent le service comme un ensemble de modules logiciels autonomes apparu avec l’émergence du paradigme SOC comme une réponse au problème d’interopérabilité entre des applications et des Cadre(conceptuel(d’un(SIP :(Espace(de(services 104 architectures hétérogènes. Une définition plus générale est donnée par (Issarny et al., 2007), qui considèrent un service comme une entité indépendante, dotée d’interfaces bien définies et pouvant être invoquée de manière standard, sans requérir de son client une quelconque connaissance sur la manière dont le service réalise réellement ses tâches. Quelle que soit la définition utilisée, les aspects clés qui se dégagent des multiples définitions présentées dans la section 3.2 sont : le faible couplage entre le client et le fournisseur de service, l’interopérabilité et la réutilisation. En effet, ce faible couplage rend la notion de service particulièrement attractive pour les environnements pervasifs qui se caractérisent par la volatilité de leurs éléments (Vanrompay et al., 2011). De plus, la" caractéristique principale des services est leur indépendance par rapport aux aspects technologiques, ce qui nous permet ainsi de masquer l’hétérogénéité technologique des environnements pervasifs. En effet, la notion de service a été conçue pour répondre à des besoins de réutilisation et d’interopérabilité (Papazoglou et Georgakopoulos, 2003). Ses récents usages dans les systèmes sensibles au contexte (Maamar et al., 2006)(Baldauf et al., 2007)(Toninelli et al., 2008) démontrent aussi l’intérêt de la notion de service pour l’adaptabilité dans les SIP. Dans le cadre de notre espace de services, la notion de service représente une entité très importante. La notion de service est définie, d’une manière générale et dans toutes les approches orientées services, sous forme d’un ensemble de fonctionnalités F. Comme nous l’avons montré dans le Chapitre 4, l’orientation intentionnelle et contextuelle permet de répondre aux problèmes de transparence, d’adaptation à l’environnement et d’adaptation à l’utilisateur auxquels les SIP sont confrontés. Ainsi, nous proposons dans ce cadre conceptuel des SIP de définir les notions d’intention et de contexte pour enrichir le concept de service. 5.2.1.Les fonctionnalités du service Malgré les multiples définitions de la notion de service (cf. section 3.2) et les différentes approches de services proposées (cf. section 3.4), nous pouvons décrire, d’une manière générique, un service comme un ensemble de fonctionnalités F dont l’interface est clairement définie, voire standard, et dont le fonctionnement interne est inconnu des clients. La Définition 1 résume cette vision fonctionnelle d’un service. Définition 1 : Chaque fonctionnalité fj ∈ F se définit en fonction des entrées inj et des sorties outj attendues par les clients du service. F = { fj ( inj , outj ) } Définition 1. La notion de fonctionnalité relative à un serviceCadre(conceptuel(d’un(SIP :(Espace(de(services 105 D’un point de vue fonctionnel, chaque fonctionnalité fj est définie en fonction de l’ensemble d’entrées in et de l’ensemble de sorties out attendues. La Définition 1 résume cet aspect de la notion de service. On remarquera qu’à aucun moment la nature exacte du service n’est révélée au client qui cherche et invoque un service svi. Seule l’interface fonctionnelle du service, représentée par l’ensemble de fonctionnalités fj avec leurs données entrantes (in) et sortantes (out), est indiquée. Ce point est très important car il nous permet de gérer l’hétérogénéité de l’environnement, en gardant une certaine transparence dans la définition des services qui y sont offerts. Une découverte de services par les aspects fonctionnels est donc possible sans que le client ait besoin de connaître les technologies impliquées pour les réaliser. Par ailleurs, la nature atomique ou composite du service devient également transparente pour le client. En effet, les fonctionnalités exposées correspondent à celles offertes par le service. Un client peut alors les invoquer indistinctement, quelque soit leur origine, qu’elles viennent d’un service atomique ou d’une composition de services complexe. Toutefois, afin d’améliorer la découverte de services et de proposer à l’utilisateur le service qui le satisfait au mieux, il est important de prendre en compte d’autres aspects, tels que les intentions que le service permet de satisfaire et le contexte dans lequel le service est valide et exécutable. Ces aspects jouent un rôle essentiel dans la découverte du service le plus approprié aux besoins de l’utilisateur. L’aspect intentionnel qui peut être associé à un service sv i est introduit dans la section 5.2.2. Par contre, les aspects non-fonctionnels du service sv i sont considérés sous l’angle contextuel, ci-dessous dans la section 5.2.3. 5.2.2.Les intentions du service Les fonctionnalités proposées par un service permettent aux utilisateurs de répondre à un besoin précis. A partir de notre analyse de la littérature (cf. section 3.4.3.1), on peut associer ce besoin à l’expression d’une intention par les utilisateurs. Un service est ainsi proposé afin de satisfaire une (ou plusieurs) intention(s) de ces utilisateurs. La notion d’intention, présentée dans la section 3.4.3.1, formalise, en général, les besoins de l’utilisateur. Elle a été définie par Jackson (Jackson, 1995) comme étant une déclaration ‘optative’ qui exprime ce que l’on veut, un état ou un résultat que l’on cherche à atteindre. Ensuite, Kaabi et al. (Kaabi et Souveyet, 2007) présente l’intention comme un but qu’on veut atteindre sans indiquer comment le faire. Enfin, Bonino et al (Santos et al., 2009) l’a défini comme étant un but à atteindre en effectuant un processus présenté comme une séquence de sous-buts et de stratégies vers le but cible. En d’autres termes, une intention représente un besoin que l’utilisateur souhaite satisfaire, sans se soucier vraiment de quelle implémentation permet de le satisfaire ou de la façon de l’exécuter. La notion d’intention a souvent été associée, par le passé, à la notion de service. Plusieurs travaux ont, en effet, considéré la notion de service sous un angle intentionnel (Santos et al., 2009) (Rolland et al., 2010) (Mirbel et Crescenzo, 2010a) et (Fensel et al., 2011), comme nous l’avons mentionné dans la section 3.4.3.1. Cette notion d’intention place donc le service à un niveau plus proche de l’utilisateur final : quelle que soit la technologie utilisée, le service est défini pour satisfaire un besoin exprimé par l’utilisateur sous forme d’intention, telle que Cadre(conceptuel(d’un(SIP :(Espace(de(services 106 le présente la Définition 2. En tant que SI, les SIP doivent être conçus afin de mieux satisfaire les besoins des utilisateurs. Ainsi, les fonctionnalités d’un service doivent être soigneusement choisies afin de répondre aux besoins métiers exprimés sous forme d’intention. Une intention peut être représentée selon une structure basée sur les travaux de (Prat, 1997), composée d’un verbe, une cible et un ensemble de paramètres relatifs au verbe (Rolland et al., 2010). Le verbe v caractérise l’action décrivant l’intention. Cette action agit sur une cible tg, pouvant être aussi bien l’objet affecté par l’action que le résultat obtenu par cette action. L’ensemble des paramètres par spécifient d’autres aspects de l’action tels que le bénéficiaire, la direction, la quantité, pour ne citer qu’eux. Ces paramètres sont, bien entendu, optionnels et dépendent directement du verbe utilisé. Par exemple, un service offrant à un agent commercial la possibilité de consulter une fiche client peut être associé à l’intention I1 = {#consulter, #fiche_client, ∅}. Ici, le verbe « consulter » est utilisé en compagnie de la cible « fiche client » sans qu’un paramètre soit indiqué. La formalisation de l’intention qu’un service permet de satisfaire est introduite dans la Définition 2. Par exemple le service « AccèsFicheClientServiceVPN » est un service qui répond à l’intention principale I1 = {#consulter, #fiche_client, ∅}. Cette intention nécessite la réalisation d’autres intentions : I1.1 = {#connecter, #VPN, ∅}, I1.2 = {#afficher, #liste_client, ∅} et I1.3 = {#sélectionner, #client, ∅}. Ces intentions représentent les intentions qui vont être satisfaites par la mise en œuvre du service. Chaque élément de cette définition doit être lui-même sémantiquement défini au préalable. En d’autres termes, nous supposons l’existence d’une ontologie d’intentions, qui décrit sémantiquement ces éléments. Cette ontologie, qui représente une ontologie du domaine, se compose, en réalité, de multiples ontologies, chacune décrivant un élément : une ontologie de verbes, une ontologie de cibles rendues accessibles par le SIP, ainsi qu’un ensemble d’ontologies spécifiant chacun des paramètres acceptés par le SIP. Ces ontologies établissent de manière non-ambiguë la sémantique des actions acceptées par le SIP dans l’espace de services et l’ensemble des cibles atteignables par le biais de cet espace. Définition 2 : Chaque intention I est définie par un verbe v, qui caractérise son action, une cible tg, sur laquelle l’action agit, et un ensemble optionnel de paramètres par. I = { < v , tg , par > } Définition 2. Formalisation d'une intention qu'un service permet de satisfaire Une telle définition, basée sur une ontologie préétablie, n’est envisageable que dans le cadre fermé d’un Système d’Information. En effet, ces systèmes n’autorisent pas un comportement ouvert sur des intentions et des cibles non-autorisées ou inconnues. D’autre Cadre(conceptuel(d’un(SIP :(Espace(de(services 107 part, dans un environnement pervasif ouvert, l’expression de l’intention à l’aide d’un ensemble prédéfini de termes est difficilement imaginable, laissant une part trop importante à l’ambigüité. Cette ambigüité vient, en réalité, des utilisateurs : dans un environnement pervasif ouvert, le profil des utilisateurs n’est pas forcément connu à l’avance et le mode d’expression de ces utilisateurs peut être très différent. 5.2.3.Le contexte du service Une intention n’est pas le fruit du hasard. Elle représente le besoin d’un utilisateur. Or ce besoin émerge dans un contexte donné. En d’autres termes, la notion d’intention est directement liée à la notion de contexte. Nous pensons qu’une intention n’a de sens que lorsqu’on la considère dans un contexte donné. Selon nous, et comme l’illustre la partie A de la Figure 26, un utilisateur invoque un service parce que celui-ci lui permettra de satisfaire une intention. Cependant, le contexte dans lequel émerge cette intention est lui-aussi significatif. Il peut influencer considérablement la manière dont cette intention peut être satisfaite, et donc influencer l’exécution même du service (par exemple, par le choix d’une implémentation qui s’adapte au contexte courant de l’utilisateur). Inversement, un utilisateur n’invoque pas un service uniquement parce qu’il est dans un contexte donné. Il le fait parce que ce service lui permettra d’atteindre ses objectifs dans ce contexte précis. La partie A Figure 26 schématise cette vision, selon laquelle un service est proposé afin de satisfaire une intention de l’utilisateur émergeant dans un contexte précis. Cette vision commence à se développer dans la littérature, comme nous l’avons discuté dans la section 3.5.2.4. Quelques auteurs, dont Santos et al. (Santos et al., 2009), proposent déjà d’associer ces deux notions. Cependant, pour beaucoup d’entre eux, cette association reste assez floue. Par exemple, Santos et al. (Santos et al., 2009) ne considèrent le contexte que comme un filtre pour la découverte de services, le contexte étant vu comme une partie des entrées nécessaires aux services, et les intentions comme de simples étiquettes permettant de relier les demandes des utilisateurs aux services. Nous croyons, au contraire, que ces deux notions sont complémentaires et indissociables. Le contexte ne peut être réduit à de simples paramètres d’entrées ou de sorties. Non seulement il influence l’exécution du service, mais il caractérise aussi le service lui-même et les intentions ciblées par le service. Figure 26. Relation entre l'intention, le contexte et les services.Cadre(conceptuel(d’un(SIP :(Espace(de(services 108 A partir de la partie B de la Figure 26, on observe que l’impact de la notion de contexte sur le service est double : il influence son exécution et caractérise le service. Nous considérons qu’un service svi se trouve lui aussi immergé dans l’espace de services. Par conséquent, il se place lui-même dans un contexte Cxsvi donné. Ainsi, à l’instar de (Vanrompay et al., 2011), nous considérons qu’un service peut être associé à deux contextes complémentaires. Tout d’abord, un service s’exécute lui-même dans un contexte Cxsvi donné. Celui-ci représente un ensemble non vide d’observations contextuelles qui sert non seulement à indiquer les observations de contexte dans lesquelles le service est exécuté par son fournisseur, mais également à caractériser le positionnement de ce service dans l’espace de services. Le service est un objet dynamique qui bouge dans le temps et qui doit être observé. Ensuite, nous considérons également qu’un service sv i peut avoir un contexte requis CxRsvi représentant un ensemble non vide de conditions contextuelles dans lesquelles le service est le plus apte à atteindre ses objectifs, i.e. les conditions de contexte auxquelles il peut s’adapter. En d’autres termes, le contexte requis CxRsvi représente un ensemble de conditions de contexte permettant au service une meilleure possibilité de satisfaction des intentions qui lui sont associées. Il s’agit d’un filtre défini sur les observations de contexte de l’utilisateur : plus le contexte courant observé pour l’utilisateur correspond au contexte requis, plus le service aura de chance de s’adapter à cette situation et de satisfaire au mieux l’utilisateur. Ainsi, dans le cadre des mécanismes de découverte (cf. Chapitre 7) et de prédiction (cf. Chapitre 8) de services, le contexte requis est exploité dans le cadre de la sélection des services les plus appropriés au contexte courant de l’utilisateur (cf. section 7.2.2.4). Il faut mettre en correspondance le contexte requis du service (CxRsvi) avec le contexte courant l’utilisateur (CxU), afin de sélectionner les services qui peuvent s’adapter au mieux à la situation courante de l’utilisateur. Dans le cadre de notre espace de services, la notion de contexte doit être modélisée d’une manière générique afin de permettre à n’importe quel modèle de contexte (cf. section 2.3.2) de fonctionner avec notre cadre conceptuel des SIP. Pour ce faire, nous avons besoin d’une modélisation de contexte de plus haut niveau qui peut être instanciée par n’importe quelle approche de contexte. Ainsi, afin de formaliser la notion de contexte nous proposons de définir avant un méta-modèle de contexte qui va être utilisé dans notre cadre conceptuel des SIP. Ce méta-modèle de contexte représente une modélisation générique de contexte Cx. Il permet à toute approche orientée contexte d’utiliser notre méta-modèle pour représenter ses informations contextuelles, quelque soit le modèle de contexte qu’elle va utiliser au niveau implémentation. Quant au contexte requis CxRsvi, il aura une structure similaire à Cxsvi, mais il doit exprimer des conditions contextuelles, lesquelles nécessitent un langage sémantique pour pouvoir les représenter sous la forme la plus adéquate. Ce langage sémantique va essentiellement dépendre du modèle de contexte choisi et mis en place au niveau implémentation. Ainsi, il est plus approprié de garder le choix de la modélisation de contexte CxRsvi au niveau implémentation et de spécifier ses conditions contextuelles en langage naturel au niveau conceptuel. En conséquence, au niveau conceptuel, il faut spécifier en langage naturel les conditions contextuelles qui vont être attachées à chaque service. Par la suite, en Cadre(conceptuel(d’un(SIP :(Espace(de(services 109 choisissant le langage adéquat au niveau implémentation qui correspond au modèle de contexte choisi, il faudra traduire ces conditions pour pouvoir les traiter. Nous présenterons le méta-modèle de contexte dans la section 5.3.1. Nous formalisons, dans la section 5.3.2, la notion de contexte à travers la notion d’observation et de capteur. Ainsi, à partir de ce qu’on vient de présenter, il nous paraît évident qu’un service ne peut être défini sans tenir compte de ces éléments qui lui permettent de mieux se situer dans son environnement et de réagir à celui-ci. A ces éléments, on ajoute les notions préalablement mises en évidence : les intentions (Définition 2) et les fonctionnalités (Définition 1) offertes par le service. Nous formalisons ainsi la notion de service comme l’illustre la Définition 3 Définition 3 : Un service sv i correspond à un ensemble de fonctionnalités F fournies par cette entité sv i dans un contexte Cx afin de satisfaire un ensemble d’intentions I. La satisfaction de ces intentions dépend également d’un contexte favorable, décrit comme un contexte requis CxR pour le bon déroulement du service. sv i = Définition 3. Formalisation de la notion de service de l’espace de services Derrière la notion de contexte, il existe une autre notion importante pour l’univers des services : les aspects non-fonctionnels qui caractérisent ces services. Beaucoup de recherches ont été menées autour de ces aspects (Liu et Issarny, 2004) (Chaari et al., 2008a) (Vanrompay, 2011)(Xin et Hao, 2012) (Ait Ali Slimane, 2012), pour ne citer qu’eux. Par exemple la notion de qualité présente l’un des aspects non-fonctionnels des services. Nous soulignons deux importantes tendances de travaux dans cette thématique, à savoir : la qualité des service (QoS – Quality of Service) et la qualité de contexte (QoC - Quality of Context). D’un côté, Vanrompay (Vanrompay, 2011), dans ces travaux de recherche, a souligné l’importance de la qualité de contexte (QoC) pour les applications, qui permet une utilisation efficace des informations contextuelles fournies. Cet auteur propose un ensemble de mesures de qualité des informations de contexte, telles que la probabilité d’exactitude, certitude, taux d’erreur standard, granularité, temps de réponse, etc. Plus spécifiquement, ces mesures représentent la qualité du futur contexte qui a été prédit (QoFC – Quality of Future Context) et elles sont classifiées en trois catégories de qualité de prédiction de contexte : mesure individuelle, mesure globale et mesure dépendante des entrées. De l’autre côté, Ait Ali Slimane (Ait Ali Slimane, 2012) a proposé une autre dimension qualitative des services sous un angle intentionnel, la qualité des services intentionnels (QoiS – Quality of intentional Service). L’objectif principal derrière l’introduction de la QoiS est de résoudre les problèmes de discordance conceptuelle entre les exigences non-fonctionnelles des utilisateurs finaux et la qualité des services logiciels, celui des dépendances fonctionnelles entre les services. Dans Cadre(conceptuel(d’un(SIP :(Espace(de(services 110 ces travaux, Ait Ali Slimane (Ait Ali Slimane, 2012) propose un méta-modèle de la qualité, et un référentiel qualité. Cependant, il faut noter que le contexte est lui-même un de ces aspects. Le contexte peut être considéré comme un élément extérieur au service, capable de l’influencer. En tant que tel, il peut être considéré comme un ensemble d’aspects non-fonctionnels caractérisant le service. Inversement, beaucoup d’éléments traditionnellement pris en compte sous un angle d’analyse non-fonctionnelle peuvent également être vus comme des conditions contextuelles à l’exécution du service. A travers la spécification explicite du contexte offert Cxsvi et requis CxRsvi par un service, nous espérons également offrir une possibilité de représentation des aspects non-fonctionnels dans le cadre de l’espace de services. 5.3. FORMALISATION DE LA NOTION DE CONTEXTE La notion de contexte, qu’on a discuté dans la section 2.3.1, est un concept très large, exploré depuis plusieurs années dans l’Informatique Pervasive (Masmoudi et Conan, 2013) (Najar et al., 2009) (Villalonga et al., 2010). Selon (Gensel et al., 2008), le contexte est « l’ensemble des caractéristiques de l'environnement physique ou virtuel qui affecte le comportement d'une application et dont la représentation et l’acquisition sont essentielles à l’adaptation des informations et des services ». Le contexte est un élément clé de l’Informatique Pervasive, car il est au centre des mécanismes d’adaptation prônés par les systèmes dits sensibles au contexte. Ces systèmes se caractérisent, en effet, par leur capacité à adapter leur fonctionnement afin d’augmenter leur utilisabilité et leur efficacité, par la prise en compte du contexte environnant (Baldauf et al., 2007). Figure 27. Vue schématique d'un système sensible au contexte (d’après (Najar et al., 2009)) De manière schématique, et comme l’illustre la Figure 27, un système sensible au contexte est un système qui supporte une certaine variabilité, le choix de la variante dépendant du contexte qui entoure l’exécution du système et son interaction avec les utilisateurs. Le contexte agit ainsi comme un élément extérieur au système qui influence sa variabilité intérieure, une sorte de paramètre qui guiderait le choix de la variante la plus appropriée et le processus d’adaptation la concernant (Najar et al., 2009). Cadre(conceptuel(d’un(SIP :(Espace(de(services 111 Dans la section suivante, nous présentons une modélisation de contexte qui nous semble la plus générale permettant ainsi son exploitation et son extension dans différents domaines. Cette modélisation est le fruit de l’analyse des différentes approches de modélisation de contexte existantes, mentionnées à la section 2.3.2, et qui sont utilisées pour l’abstraction et l’encodage des informations de contexte dans une forme non ambiguë. 5.3.1.Modélisation de contexte La notion de contexte (cf. section 2.3.1) est un élément essentiel pour la réalisation de systèmes sensibles au contexte. Or, tout Système d’Information Pervasif (SIP) doit également être sensible au contexte pour pouvoir s’adapter à l’environnement pervasif dans lequel évoluent ses utilisateurs. La maîtrise des SIP passe donc par la maîtrise de la notion de contexte. Celle-ci étant particulièrement extensible, une représentation formelle est nécessaire afin d’en définir les contours et d’identifier les informations pertinentes, qui influenceront effectivement le comportement du système (Gensel et al., 2008). Ce constat, effectué par différents auteurs (Gensel et al., 2008) (Masmoudi et Conan, 2013) (Chaari et al., 2007) (Brézillon et Brézillon, 2007) a conduit à la proposition de multiples modèles de contexte (Najar et al., 2009) (Bettini et al., 2010). Même si ceux-ci varient par leur forme et leur formalisme, nous pouvons dégager certains éléments clés, qui caractérisent l’immense majorité de ces modèles. D’après l’analyse des différentes définitions et approches de modélisation de contexte, que nous avons exposées dans la section 2.3.2, nous remarquons certains éléments communs. En se basant sur la définition référence de Dey, « toute information qui peut être utilisée pour caractériser la situation d’une entité » (Dey, 2000), deux concepts clés peuvent être dégagés : (i) « entité » qui fait référence à quelque chose observable dans l’environnement et (ii) « toute information » qui est présentée comme tout attribut observé de cette entité. Ces concepts ont été soulignés dans la plupart des approches de modélisation de contexte, telles que (Lemlouma, 2004) (Kirsch-Pinheiro, 2006) (Paspallis, 2009) (Masmoudi et Conan, 2013). En effet, dans la plupart des définitions de contexte, on parle de l’observation de quelque chose afin de déterminer les informations de contexte. Nous introduisons ainsi le concept « sujet observé » dans notre méta-modèle de contexte. Ce concept représente ce qu’on observe concrètement dans l’environnement afin de collecter un certain nombre d’informations contextuelles. C’est un élément important puisqu’il permet de déterminer à qui ou à quoi s’attache les informations de contexte que nous allons détecter. Lemlouma (Lemlouma, 2004), par exemple, dans sa modélisation de contexte se base sur l’observation de l’utilisateur et du dispositif afin de déterminer des informations sur leurs profils. L’utilisateur et le dispositif sont considérés comme des « sujets observés » dans sa modélisation de contexte CC/PP. Masmoudi et Conan (Masmoudi et Conan, 2013), ont souligné aussi l’importance de ce concept en introduisant dans leur méta-modèle la notion d’entité observable qui décrit une entité physique ou logique qui peut être observée. Cadre(conceptuel(d’un(SIP :(Espace(de(services 112 De plus, la majorité des approches de modélisation de contexte expose et énumère dans leur modèle les éléments de contexte qu’ils souhaitent observer et acquérir pour pouvoir adapter leur système. Nous introduisons la notion « élément de contexte » qui représente l’attribut observé permettant de caractériser la situation du « sujet observé » en question. Kirsch-Pinheiro (Kirsch-Pinheiro, 2006), par exemple, propose une approche orientée objet pour la structuration des éléments de contexte et de leurs relations. Ce modèle propose une classe élément de contexte qui est spécialisée avec l’énumération des différents éléments de contexte qui sont liés aux aspects collaboratifs (rôle de l'utilisateur, activités, etc.) en plus des aspects physiques (la localisation de l'utilisateur, le dispositif, etc.). Dans cette modélisation l’élément de contexte est le concept central qui tourne autour des éléments qui semblent indispensables à l’auteur (Kirsch-Pinheiro, 2006), soit de par leur importance à l'utilisateur, soit de par leur pouvoir de caractériser une situation. De même, Reichle et al. (Reichle et al., 2008) soulignent aussi l’importance de ce concept « élément de contexte » dans la modélisation de contexte. Ils le présentent dans leurs travaux comme étant un « scope » identifiant l'attribut exact de l'entité sélectionnée qui le caractérise. Selon ce modèle de contexte, Reichle et al. (Reichle et al., 2008) associent directement leur notion du scope observé avec l'entité à laquelle il se réfère. Dans un système sensible au contexte, l’observation d’un élément de contexte pour un sujet observé donné, permet de lui déterminer une valeur. Cette valeur est soit acquise dynamiquement à travers des capteurs, soit définie statiquement au départ ou dérivée ensuite à travers un processus d’interprétation. Compte tenu de l’importance de cette valeur dans le processus d’adaptation des systèmes sensibles au contexte, nous introduisons la notion de « valeur observée » dans notre méta-modèle qui est associée à un « élément de contexte ». Dans la littérature, par exemple, la modélisation de contexte constituée de paires « clé- valeur », qu’on a présentée à la section 2.3.2.1, permet de représenter le contexte d'utilisation comme un ensemble de paires contenant chacune une clé et la valeur qui lui correspond. Dans cette approche, un élément de contexte est considéré comme clé, et la valeur associée à cet élément représente la valeur observée. Finalement, nous avons constaté à travers la littérature que certaines informations supplémentaires sont associées aux informations de contexte modélisées pour les décrire. Paspallis (Paspallis, 2009), par exemple, souligne l’importance de la représentation des éléments de contexte lors de la modélisation. La représentation est utilisée pour préciser la structure interne utilisée pour encoder les informations de contexte dans des structures de données. Cet auteur propose ainsi de rajouter la représentation comme un concept clé de sa modélisation de contexte. De plus, Vanrompay (Vanrompay, 2011), souligne dans ces travaux l’importance de la prise en compte de la qualité de l’information de contexte utilisée. Cette qualité de contexte permet de déterminer la pertinence de l’information qui peut jouer sur le processus d’adaptation dans les systèmes sensibles au contexte. Dans cette optique, Pierrick et al. (Pierrick et al., 2013), ont proposé dans leurs travaux un méta-modèle de contexte qui souligne l’importance de la qualité de contexte lors de sa modélisation. Ils proposent le métamodèle QoCIM qui offre un support de modélisation générique de critères de la qualité de contexte (QoC) en introduisant le concept QoCIndicator. Ainsi, une information de contexte Cadre(conceptuel(d’un(SIP :(Espace(de(services 113 (ContextData) est qualifiée par des indicateurs de qualité (QoCIndicator). Suite à ces propositions, nous soulignons de même l’importance de ces concepts, entre autres. Nous introduisons, en conséquence, le concept « métadonnée » comme étant les informations pertinentes qui peuvent être associées à la valeur observée d’un élément de contexte. Nous présentons ainsi un méta-modèle flexible, illustré à la Figure 28. Ce méta-modèle permet de décrire comment les informations de contexte générales peuvent être modélisées. Il fournit une vue des structures de base qui peuvent être utilisées lors de la définition d’un modèle de contexte spécifique à un domaine donné. Il nous permet de « réduire » un modèle de contexte à l’observation d’un ou plusieurs sujets observés (un utilisateur, un dispositif, etc.) pour lequel (lesquels) on observe un ensemble d’éléments de contexte (localisation, activité, mémoire disponible, etc.), obtenant ainsi, pour chacun de ces concepts, des valeurs observées qualifiées par leur métadonnée (représentation, indicateurs de qualité, etc.). Figure 28. Méta-modèle de contexte. Ce méta-modèle est fondé sur le principe de la séparation claire entre le sujet observé et l’élément de contexte. Le sujet observé représente le sujet de contexte auquel l’élément de contexte se réfère. L’élément de contexte fait référence à l’attribut ou à la propriété de contexte qu’on souhaite observer pour un sujet donné. Par exemple, on pourrait observer l’élément de contexte « mémoire » du sujet observé « dispositif ». Pour chaque sujet observé, on peut observer de zéro à plusieurs éléments de contexte. Un élément de contexte peut être associé à zéro ou plusieurs autres éléments de contexte. La représentation de cette association entre éléments de contexte, dans notre méta-modèle, permet d’exprimer les relations sémantiques qui peuvent exister entre ces éléments dans les approches orientées objets, par balisage ou sous forme d’ontologie. Cette relation entre éléments de contexte peut être une composition, une spécialisation, une simple association, etc. Ainsi, lors de l’instanciation de notre méta-modèle, il faut capturer la sémantique de ce lien qui peut exister entre les éléments de contexte dans le modèle de contexte au moment de son implémentation. Par exemple, dans une modélisation de contexte sous forme d’ontologie, on souhaite observer l’élément de contexte « profil » du sujet observé « utilisateur ». Cet élément de contexte se caractérise par d’autres éléments comme « âge », « expérience », etc. De ce fait, notre méta-modèle de contexte répond aux faiblesses des autres modèles de contexte à gérer l’aspect hiérarchique entre les éléments de contexte. Par exemple, (Kirsch-Pinheiro, 2006) propose un modèle de contexte très détaillé, où tous les éléments de contexte sont exposés directement dans le modèle. Ce modèle gère difficilement la hiérarchie entre les éléments de contexte. En métadonnée << Classifier >> Element de Contexte << Classifier >> * 1 caractérise Valeur Observée << Classifier >> Observation Sujet Observé << Classifier >> * 0..1 * * * 1Cadre(conceptuel(d’un(SIP :(Espace(de(services 114 conséquence, des éléments de contexte comme « LocalisationParGPS » et « LocalisationParAdresse », par exemple, sont représentés comme deux éléments de contexte totalement distincts, alors qu’en réalité ils ne sont que des éléments composant de l’élément de contexte « localisation ». Ceci peut entrainer certaine confusion lors du traitement du modèle de contexte. Chaque élément de contexte est composé de plusieurs valeurs observées. Chaque valeur observée représente une donnée de contexte capturée à un instant donné. Par exemple, pour le sujet observée « dispositif » et l’élément de contexte « mémoire », on pourrait avoir une valeur observée égale à « 1024 Mo ». Chaque valeur peut avoir des représentations différentes, des indicateurs de qualité, de confiance, etc. Ces derniers indiquent les aspects extra-fonctionnels des informations contextuelles représentées, dans le méta-modèle (Figure 28) comme des métadonnées. Ainsi une valeur observée peut avoir plusieurs métadonnées. Par exemple, on peut associer à une valeur donnée de la localisationGPS (élément de contexte) d’un utilisateur (sujet observé) la représentation ReprésentationLocalisationGPS et comme indicateur de qualité, la confiance à 80%. Le méta-modèle que nous proposons dans le cadre de ce chapitre, peut s’appliquer aux quatre approches de modélisation de contexte citées dans la section 2.3.2. Par exemple, la modélisation de contexte basée sur les paires clé-valeur peut être instanciée par notre métamodèle de contexte, où la clé est représentée par l’élément de contexte et la valeur est définie par la valeur observée. Si on prend, par exemple, la modélisation de contexte suivante : ‘température’ = ‘25’. Dans ce cas, la clé « température » représente l’élément de contexte auquel on associe une valeur égale à 25 qui peut être la valeur observée pour l’élément de contexte défini. Dans la modélisation clé-valeur, on n’a pas de relation entre éléments de contexte. De plus, les valeurs observées ne sont pas associées à des métadonnées. La cardinalité [0..n] entre éléments de contexte et entre une valeur observée et les métadonnées permet à notre méta-modèle de contexte d’être instancié par le modèle de contexte clé-valeur même s’il ne permet pas d’exprimer de relation sémantique entre les éléments de contexte et de lien entre les valeurs observées et les métadonnées. Dans le cadre de la modélisation de contexte basée sur le balisage, nous prenons l’exemple de profil CC/PP présenté par Lemlouma (Lemlouma, 2004), et qui illustré à la Figure 29. Ce modèle de contexte représente une description des capacités physiques et logicielles d’un type de terminal donné. Ainsi, le type du terminal représente le sujet observé dans notre métamodèle de contexte. Ensuite, pour chaque type de terminal une description de ces capacités lui est attribuée. Cette description porte sur un ensemble de composants (e.g terminalHardware, hardwarePlatform, terminalSoftware, terminalBrowser, etc.) auxquels est associé un ensemble de valeurs. Par exemple, pour le composant hardwarePlatform on lui associe comme nom EPOC et comme version 2.0. A partir de cet exemple, nous pouvons affirmer que les composants représentés dans le modèle de contexte CC/PP représente les éléments de contexte de notre méta-modèle auxquels on va associer un ensemble de valeurs observées. De plus le lien hiérarchique entre éléments de contexte peut être représenté par le lien de composition entre composant dans le fichier CC/PP. Par exemple, le composant terminalHardware est composé du composant hardwarePlatform. Cadre(conceptuel(d’un(SIP :(Espace(de(services 115 Figure 29. Extrait de profil CC/PP (Lemlouma, 2004) Dans le cadre de la modélisation de contexte orientée objet, nous prenons l’exemple proposé par kirsch-Pinheiro (Kirsch-Pinheiro, 2006). Dans sa modélisation de contexte, cet auteur représente une classe description de contexte à laquelle on associe un ensemble de valeurs des éléments de contexte observés. Comme l’illustre la Figure 30, cette description de contexte décrit le contexte d’un élément de contexte donné (par exemple, le membre Alain). Ainsi, cette description de contexte peut être vue comme une réunion d’un ensemble d’observation d’éléments de contexte (e.g. session, rôle, application, etc.) autour d’un sujet donné. En conséquence, le lien entre un sujet observé et un ensemble d’éléments de contexte dans notre méta-modèle peut représenter cette description de contexte. Figure 30. Extrait du modèle de contexte orienté objet de (Kirsch-Pinheiro, 2006) : lien entre sujet observé et élément de contexte De plus, dans le modèle de contexte orienté objet de kirsch-Pinheiro (Kirsch-Pinheiro, 2006), et comme l’illustre la Figure 31, un élément de contexte peut avoir un lien avec un autre élément de contexte. Ce lien peut être un « is-A » ou une simple association entre deux éléments de contexte, par exemple l’élément de contexte « session » (ayant comme valeur session Alain) a un lien « espace_d’éxécution » avec l’élément de contexte « disposition » (ayant comme valeur treo650). Ceci représente le lien hiérarchique entre les éléments de contexte de notre méta-modèle de contexte. Dans cette modélisation de contexte, aucune métadonnée n’est prise en compte. Contexte Alain : Description de contexte Alain : Membre Alain : Membre Session Alain : Session Comité : Groupe Président : Rôle treo650 : Dispositif +Description +Cible décrit_contexte_de élémentCadre(conceptuel(d’un(SIP :(Espace(de(services 116 Figure 31. Extrait du modèle de contexte orienté objet de (Kirsch-Pinheiro, 2006) : lien entre éléments de contexte Finalement, Reichle et al. (Reichle et al. 2008), par exemple, proposent une modélisation de contexte sous forme d’ontologie décrivant les informations contextuelles en se basant sur trois concepts principaux : 1) l'entité se référant à l'élément sur lequel l'information de contexte se rapporte ; 2) le scope identifiant l'attribut exact de l'entité sélectionnée qui le caractérise ; et 3) la représentation utilisée pour préciser la représentation interne utilisée pour encoder les informations de contexte dans des structures de données. En faisant le lien avec notre méta-modèle de contexte, l’entité peut représenter le sujet observé, le scope peut définir l’élément de contexte, la valeur associée au scope peut faire référence à la valeur associée à l’élément de contexte, et la représentation peut être une instance des métadonnées. De plus, la représentation du modèle de contexte sous forme d’ontologie permet de lier deux éléments de contexte ensemble. Ce lien peut être de type « is-A », « Part-Of » ou une relation de type « property » entre deux éléments de contexte. Ce lien représente une instance du lien hiérarchique entre éléments de contexte représenté dans notre méta-modèle de contexte Dans la section, nous proposons une instanciation de notre méta-modèle de contexte en présentant notre modèle de contexte basé sur les ontologies. 5.3.2.Formalisation de la notion d’observation et de capteur 5.3.2.1. Formalisation de la notion d’observation Selon notre analyse de la littérature (cf. section 2.3.2.4), nous avons conclu que les approches basées sur l'ontologie semblent être les plus prometteuses en termes de raisonnement et d’expressivité. Ainsi, le rattachement de notre méta-modèle de contexte à une description sémantique peut s’appliquer aussi bien aux éléments de contexte qu’aux sujets observés : avant toute observation d’un sujet ou d’un élément de contexte, la nature de celuici doit d’abord être clairement identifiée dans une ontologie de domaine propre au SI en question (cf. section 6.4.1). En d’autres termes, un SIP n’est pas sensé observer n’importe quel sujet, sans rapport avec son activité, de la même façon qu’il ne doit pas observer un élément de contexte inconnu, qu’il ne saura pas interpréter. Le fait de considérer uniquement des éléments spécifiés dans une ontologie présuppose que des éléments de contexte inconnus Alain : Membre répertoire partagé : Application +espace +participant est_localisé_dans Session Alain : Session treo650 : Dispositif +espace +outil espace_applicatif +outil conçu_pour +dispositif +dispositif +espace espace_d'exécutionCadre(conceptuel(d’un(SIP :(Espace(de(services 117 jusqu’à alors ne seront pas pris en compte par le SIP, car ils risquent de ne pas être correctement interprétés par ce dernier. Ce n’est qu’après avoir été reconnu dans l’ontologie, et donc reconnu par le système lui-même, qu’un élément de contexte pourra être pris en compte. En effet, l’ontologie de contexte établit de manière non-ambiguë la sémantique des sujets et des éléments de contexte observables et acceptées par le SIP. Les SIP se situent avant tout dans le cadre fermé des Systèmes d’Information qui doivent rester maitrisés et contrôlés par la DSI. Par conséquence, ils n’autorisent pas un comportement ouvert sur des sujets et des éléments de contexte non-autorisés ou inconnus. Une fois cette description sémantique rendue possible par le modèle de contexte, nous pouvons nous concentrer sur l’observation de contexte par un capteur donné. La notion d’observation est nécessaire parce qu’elle permet d’instancier notre métamodèle de contexte au niveau instance avec des valeurs capturées à travers les capteurs et remontées ensuite au système. Nous pouvons ainsi dégager la Définition 4, qui établit la notion d’observation réalisée par un capteur. Pour un sujet donné sj, on peut observer un ensemble d’élément de contexte Eso. Une observation donnée s’attache à un seul élément de contexte eo observé pour le sujet sj. Ainsi, pour déterminer l’ensemble des éléments de contexte que nous pouvons observer pour un sujet sj, nous définissons la fonction suivante : ElementsContexte (sj) = Eso. La fonction ElementsContexte retourne pour un sujet donné sj l’ensemble de ces éléments de contexte observables. Au cœur de cette fonction, le type so du sujet observé sj est déterminé. De ce fait, l’association entre les éléments de contexte d‘un sujet donné peut être formalisée selon cette fonction, mais sera différente selon les approches de contexte utilisées. Ainsi, cette relation entre les éléments de contexte sera plutôt exploitée au moment de la gestion de contexte. Définition 4 : Une observation Ocpi se réfère au capteur cpi pour lequel on a observé, pour le sujet sj, un élément de contexte eo à un instant tj. Ainsi, chaque observation est un n-uplet composé du sujet sj, de l’élément de contexte eo, ainsi que de la valeur v observée à un moment tj et décrite par l’ensemble de métadonnées M. Ocpi = { < obj , tj > }, obj = < sj , eo , v , M >, où - sj correspond au sujet observé ∈ so ; - eo correspond à un élément de contexte ∈ Eso ; - v correspond à une valeur observée pour ce concept ; - t représente l’instant (timestamp) auquel cette observation a été réalisée ; et - M correspond à l’ensemble des métadonnées m et de leur valeur d décrivant cette observation : M = {m = d}. Définition 4. Formalisation de la notion d'observationCadre(conceptuel(d’un(SIP :(Espace(de(services 118 5.3.2.2. Formalisation de la notion de capteur Un capteur offre au SI et aux utilisateurs un ensemble d’informations contextuelles correspondant à des valeurs observées dans l’environnement. Les capteurs, de différentes natures, permettent l’observation d’éléments caractérisant aussi bien l’environnement physique (GPS, température, etc.), que logique (mémoire disponible sur le terminal, préférences de l’utilisateur, etc.) et organisationnel (rôle de l’utilisateur, état d’exécution d’un processus, etc.). Ces capteurs sont importants puisqu’ils sont responsables de la capture des informations contextuelles dont le système aura besoin pour l’adaptation. Les valeurs observées correspondent à l’observation d’éléments de contexte clairement identifiés sur une ontologie de domaine (cf. section 6.4.1). Ces capteurs alimentent ainsi le SIP en informations contextuelles qu’il utilisera afin d’adapter son offre de services aux utilisateurs et à leurs besoins dans le contexte observé. Un capteur cpi est défini par l’ensemble d’observations Ocpi qu’il réalise, ainsi que par le contexte Cxcpi dans lequel il se trouve. Ce contexte est lui aussi décrit par un ensemble d’observations d’éléments de contexte relatifs à un sujet donné, qui est, dans ce cas précis, le capteur lui-même. Le contexte de capteur Cxcpi est un aspect important à prendre en considération car il permet de déterminer le positionnement du capteur dans l’espace de service. En effet, ce contexte Cxcpi permet de déterminer à quel espace de services ces capteurs peuvent être attachés. La Définition 5 ci-dessous synthétise cette position. Définition 5 : Un capteur cpi se définit en fonction d’un ensemble d’observations Ocpi qu’il réalise et d’un contexte Cx, également décrit par un ensemble d’observations. cpi = { Ocpi , Cxcpi } Définition 5. Formalisation de la notion de capteur 5.4. FORMALISATION DE L’ESPACE DE SERVICES Grâce à tous les éléments identifiés précédemment, nous proposons enfin de conceptualiser un espace de services, en définissant de manière générale chacun de ses éléments. L’espace de services est un cadre conceptuel qui permet de définir et de spécifier tous ce qui est jugé important et pertinent d’un point de vue utilisateur. Nous introduisons ainsi la notion d’entité comme une généralisation des différents éléments de l’espace : services (cf. section 5.2) et capteurs (cf. section 5.3). De plus, notre espace de services peut être étendu ou utilisé dans différents contextes. Cette généralisation va permettre ainsi de ne pas limiter cet espace aux notions de services et de capteurs mais de laisser la possibilité de prendre en compte d’autres éléments jugés pertinents dans d’autres usages. Cadre(conceptuel(d’un(SIP :(Espace(de(services 119 Il est à noter que l’espace de services n’inclut pas l’utilisateur dans sa formalisation comme une entité mais les services et les capteurs de SIP doivent être définis pour supporter les intentions de l’utilisateur et capturer son contexte. Plus spécifiquement, un espace de services ξ est un ensemble d’éléments, nommées entités (ei.), qui entourent l’utilisateur dans son environnement. Celui-ci est à la fois physique (localisation de l’utilisateur, dispositifs qui l’entourent, etc.), logique (ensemble des outils et des applications qui composent habituellement un SI) et organisationnel (organisation dans laquelle s’intègre le SIP). Dans cet environnement, nous pouvons considérer deux types d’entités distinctes : les entités actives, capables d’offrir aux utilisateurs un (ou plusieurs) service(s), et les entités passives, capables de renseigner les utilisateurs (et le système luimême) sur cet environnement. En d’autres termes, nous proposons de généraliser la notion de service en la présentant comme une entité active dans un espace qui est capable d’agir sur l’environnement et la notion de capteur comme une entité passive permettant l’observation de cet environnement. A partir de cette considération, nous dégageons la Définition 6 suivante : Définition 6 : Un Espace de Services ξ est un environnement pervasif composé d’un ensemble d’entités ei ξ = {ei | ei ∈ A ∨ ei ∈ P}, où - A correspond à l’ensemble des entités actives, et - P correspond à l’ensemble des entités passives disponibles sur l’espace . Définition 6. Formalisation de l'espace de service Présentes dans l’espace de services, ces entités passives et actives se situent elles-mêmes dans un contexte donné, qui caractérise leur positionnement (au sens large du terme) dans l’espace de services ξ. Ainsi, et comme le synthétise la Définition 7, chaque entité possède un contexte Cx dans lequel on l’observe et qui lui est associé. Définition 7 : Toute entité ei, qu’elle soit active ou passive, est associée à un contexte Cx qui la caractérise dans l’espace de services ξ. Définition 7. la notion d'entité dans l'espace de services De plus, grâce à la notion de contexte discutée précédemment et à la Définition 4, nous pouvons désormais définir le contexte Cx qui caractérise une entité (passive ou active) dans l’espace de services ξ. Nous considérons, dans la Définition 8, que les entités qui composent Cadre(conceptuel(d’un(SIP :(Espace(de(services 120 l’espace de services ξ se trouvent elles-mêmes dans cet espace et peuvent donc être caractérisées par les informations contextuelles que l’on peut y capter à leur sujet. Définition 8 : Une entité ei (ei ∈ A ou ei ∈ P) est caractérisée, dans l’espace de services ξ, par un contexte Cx. Celui-ci est constitué d’un ensemble d’observations. Chaque observation se réfère à l’entité ei observée et contient une valeur v pour un élément de contexte eo observé à un instant t, ainsi que l’ensemble de métadonnées M caractérisant cette observation. Cx = { < obj , tj > }, obj = < ei , eo , v , M > Définition 8. Le contexte qui caractérise une entité dans l'espace de services 5.4.1. Entités actives Le concept de service permet d’évoquer le caractère actif des entités capables d’offrir à l’utilisateur et aux autres entités placées dans l’espace de services un ensemble de fonctionnalités agissant sur l’environnement qui les entoure. Ainsi, nous pouvons généraliser la notion de service en une entité active. A travers la notion de service, la nature réelle des entités actives demeure cachée derrière une interface bien définie, représentant les fonctionnalités pouvant être rendues par ces entités, sans spécifier comment elles le sont. En définissant les entités actives en tant que services, nous pouvons gérer l’hétérogénéité qui les caractérise dans l’espace de services. L’ensemble des entités actives ei ∈ A correspond à l’ensemble des services offerts aux utilisateurs par le SI dans un environnement pervasif. Une entité active est une entité capable de réaliser une action (atomique ou composée de plusieurs actions) pour un client quelconque à travers une interface clairement définie. Le client n’a pas besoin de connaître les détails de l’implémentation du service, mais uniquement son interface. Les entités actives sont en mesure d’agir sur l’environnement, qu’il soit physique (gestion de la température d’un dépôt de stockage, par exemple), logique (invocation d’un service Web ou d’une fonctionnalité d’un ERP) ou organisationnel (e.g. intervention sur un processus métier). La nature exacte de l’entité active est ainsi transparente : qu’il s’agisse d’un service Web, une imprimante ou un fax, l’entité sera toujours vue à travers les services qu’elle offre à ces clients. 5.4.2. Entités passives Le concept de capteur permet d’évoquer le caractère passif des entités capables d’observer l’environnement et de renseigner l’utilisateur et le SI sur les informations contextuelles observées de cet environnement. Ainsi, nous pouvons généraliser la notion de capteur en une Cadre(conceptuel(d’un(SIP :(Espace(de(services 121 entité passive. Ces entités passives sont importantes puisqu’elles sont responsables de la détection des informations contextuelles dont le système aura besoin pour l’adaptation. Leur définition délimite la notion de contexte, spécifiant les informations considérées comme pertinentes. L’objectif est de permettre la prise en compte de ce contexte afin de proposer aux utilisateurs les services qui leur correspondent le mieux. L’ensemble des entités passives ei ∈ P correspond à un ensemble de capteurs capables d’observer l’environnement de l’utilisateur et son interaction avec le SIP. En d’autres termes, une entité passive est une entité capable d’offrir au SI et aux utilisateurs un ensemble d’informations contextuelles correspondant à des valeurs observées dans l’environnement, qu’il soit physique, logique ou organisationnel. Il s’agit d’une source d’information qui alimente les autres éléments de l’espace de services en informations contextuelles. Ces informations peuvent, par la suite, être utilisées pour l’adaptation des services offerts à l’utilisateur, voire l’adaptation de l’espace de services lui-même. En d’autres termes, ces entités passives alimentent le SIP en informations contextuelles qu’il utilisera afin de mieux adapter son offre de services aux utilisateurs et à leurs besoins dans le contexte observé. 5.4.3. Etat de l’espace de services et son évolution L’espace de services représente un espace conceptuel et non technique constitué d’un ensemble d’entités (services et capteurs) à un instant t. En réalité, cet espace de services ne forme pas un espace discret et fermé. Bien au contraire, nous proposons un espace de services dynamique qui n’est pas formalisé ou défini par une description propre à lui mais par la description des différentes entités qui le constituent à un instant donné. En conséquence, un espace de services peut évoluer dans le temps, avec de nouvelles entités qui s’ajoutent aux entités déjà présentes et d’autres entités qui disparaissent ou deviennent simplement indisponibles. On peut ainsi distinguer deux visions à partir de cette définition. D’abord, une vision statique qui conceptualise l’espace de services par la définition des entités dont l’intégration à l’espace est prévue, voire souhaitée par l’entreprise. Or, la nature fortement dynamique des environnements pervasifs oblige cette conceptualisation à évoluer avec cet environnement. Une vision dynamique est donc nécessaire. Celle-ci doit tenir compte des entités effectivement disponibles dans l’espace de services à un instant t. Cette distinction est nécessaire afin de mieux capturer la dynamique propre à cet espace. La notion d’espace de services se présente ainsi comme un conteneur conceptuel permettant aux concepteurs de SIP de mieux décrire ces systèmes. Dans les faits, les SIP sont confrontés à la dynamique propre aux environnements pervasifs, caractérisée par la volatilité des ressources qui s’y trouvent. Cependant, contrairement aux environnements purement pervasifs, pour lesquels la découverte et la prise en compte opportuniste des entités est recherchée, les SIP requièrent le maintien d’un certain contrôle et maîtrise. Il s’agit, avant tout, d’un système d’information, et la prise en compte de nouvelles entités sans une validation ou un accord au préalable de la part de l’entreprise (typiquement, de sa DSI), n’est pas toujours possible, voire n’est pas souhaitable. La notion d’espace de services permet aux concepteurs de mieux imaginer les environnements optimaux, maîtrisés et pourtant dynamiques. Les concepteurs peuvent ainsi décrire leur SIP sous la forme de multiples espaces de services perméables, comme l’illustre Cadre(conceptuel(d’un(SIP :(Espace(de(services 122 la Figure 32. En d’autres termes, un espace de services n’est pas un espace fermé totalement déconnecté des autres espaces. Bien au contraire, c’est un espace qui n’a pas de frontières claires qui l’empêchent de communiquer avec les autres espaces et qui demeure accessible. Ainsi, ces espaces de services peuvent se partager des entités (actives ou passives) communes (voir Figure 32). Les entités actives ou passives d’un espace peuvent ainsi exister sur d’autres espaces. De plus, l’utilisateur évolue entre ces multiples espaces qui se superposent et évoluent dans le temps. Figure 32. Multiples espaces de services perméables Afin de permettre aux visions statiques et dynamiques de coexister de manière harmonieuse, nous considérons l’état d’un espace de services en plus de sa définition statique, selon la Définition 9. L’état d’un espace de services  à un instant t, notét , correspond aux entités, passives ou actives, effectivement disponibles sur l’espaceà cet instant. Ceci équivaut à dire qu’une entité ei possède elle aussi un état à un instant t. Cet état de l’entité, noté ei t , indique la disponibilité de celle-ci dans l’espace  à l’instant t. Définition 9 : L’état d’un espace de services  à un instant t, noté t , se définit comme l’ensemble des états des entités ei présentes à cet espace : ! ! ⊆ !, ! ! = !! !! ∈ ! ∧ !! !! , où ei ξt indique l’état de l’entité ei à l’instant t (disponible ou indisponible). Définition 9. Etat d'un espace de services Service Préférences Rôle Service Service Service Service Service mémoire réseaux GPS humidité Service Service Service TempératureCadre(conceptuel(d’un(SIP :(Espace(de(services 123 5.5. CONCLUSION Dans ce cinquième chapitre, nous avons proposé la notion d’espace de services, cadre conceptuel pour la conception d’un SIP. Celui-ci permet la définition d’un SIP par la spécification d’un ensemble d’espaces, dans lesquels cohabitent les services offerts par le système aux utilisateurs et les capteurs qui l’alimentent avec des informations récoltées à partir de l’environnement (physique, logique ou organisationnel). Ces éléments sont définis par rapport à un contexte dans lequel ils se situent, permettant ainsi une meilleure prise en compte de l’environnement dans lequel évolue l’utilisateur. Cette notion, représentant notre vision des SIP, permet aux DSI de spécifier les fonctionnalités attendues de leur système, ainsi que les informations qui seront capturées par celui-ci pour une meilleure adaptation. Il s’agit de garder le contrôle sur la définition du système et de ses services, tout en permettant la prise en compte d’un environnement hautement dynamique. Ce compromis entre dynamisme et spécification au préalable est une nécessité pour les SIP, car, même s’ils veulent tirer profit d’un environnement pervasif, ils restent néanmoins des SI. Cette possibilité de spécifier le système tout en permettant l’expression de sa dynamique constitue une des forces de cette proposition. L’espace de services est défini comme un cadre conceptuel, lequel formalise d’une manière générique la notion de contexte et de service. Ce cadre est conçu indépendamment de la couche technique, ainsi que des approches de modélisation de contexte et des approches de services choisies pour son implémentation. En réalité, l’objectif principal de cet espace de services est de représenter une vision conceptuelle de la dynamique d’un SIP, offrant ainsi un guide de conception pour identifier, décrire et valider les différents composants constituant cet espace en fonction des souhaits de l’entreprise et des utilisateurs ciblés par le SIP. Nous avons formalisé cette notion d’espace de services et présenté ses composants dans l’ordre qui nous semble le plus pertinent du point de vue d’un DSI. Le cadre conceptuel proposé dans ce chapitre s’inscrit dans une approche de recherche plus large. D’une part, cette approche inclut la mise en œuvre de cette vision des SIP à travers la description sémantique des services, intégrant les notions d’intention et de contexte (cf. Chapitre 6), la découverte (cf. Chapitre 7) et la prédiction de services (cf. Chapitre 8) basées sur les notions de l’espace de services. Cette mise en œuvre a été mise en place par la réalisation d’une architecture que nous avons développée dans le cadre de cette thèse pour définir les différents espaces de services et leurs entités, et que nous avons nommée architecture de gestionnaire d’un SIP (cf. Chapitre 9). D’autre part, cette approche inclut une démarche de mise en œuvre et de réalisation de cet espace à l’intention des concepteurs de SIP (cf. Chapitre 8). Cette démarche supporte le passage du cadre conceptuel « espace de services » vers l’implémentation de l’architecture de gestionnaire de SIP contenant les modules de description, découverte et prédiction de services, que nous proposons dans la suite de cette thèse. Descripteur(intentionnel(et(contextuel :(OWLASIC 124 Chapitre 6. DESCRIPTION INTENTIONNELLE ET CONTEXTUELLE DES SERVICES 6.1. INTRODUCTION La vision intentionnelle et contextuelle des SIP que nous proposons dans le cadre de ce travail de thèse (cf. section 4.3.1) met l’accent sur l’étroite relation entre l’intention, le contexte et le service. Nous considérons qu’un service est là pour répondre à une intention particulière dans un contexte donné. Ce contexte peut influencer la satisfaction de cette intention. Cette vision a été mise en place conceptuellement par la notion d’espace de services, que nous avons présentée dans le chapitre précédent (cf. Chapitre 5). L’espace de services présente un cadre conceptuel qui intègre les différents services et capteurs qui entourent l’utilisateur dans son environnement. Nous décrivons cet espace par une description formelle qui lui est propre laquelle considère l’ensemble de services potentiellement disponibles à un instant donné. Ceci est dans le but de gérer l’aspect dynamique et perméable de cet espace. Une description de services selon une vision intentionnelle et contextuelle est un élément clé pour la réalisation de cette vision. Un service doit être décrit selon l’intention qu’il est capable de satisfaire. Il doit être décrit également par le contexte dans lequel il est valide et exécutable. Une telle description reflète l’étroite relation entre la notion d’intention, celle de contexte et le service. Son rôle est d’apporter plus de signification au service (intention) et de prendre en considération son adaptation à l’environnement (contexte). Ce descripteur de services représente une extension de OWL-S, que nous avons appelé OWL-SIC (OWL-S Intentional & Contextual), laquelle considère le service comme une entité unique avec de multiples dimensions : dimensions intentionnelles, techniques et contextuelles. Le descripteur intentionnel et contextuel que nous allons décrire dans ce sixième chapitre permet la description de l’espace de services à travers la description de l’ensemble des services qu’il intègre. De plus, ce descripteur représente le point d’entrée pour le mécanisme de découverte (cf. Chapitre 7) et celui de prédiction (cf. Chapitre 8) de services. Ces mécanismes interagissent avec un répertoire de services contenant ces descripteurs pour satisfaire les besoins des utilisateurs. Dans le cadre de ce chapitre, nous argumentons notre choix d’étendre le langage OWL-S pour prendre en considération les notions de contexte et d’intention. Par la suite, nous détaillons notre descripteur de services et nos extensions de OWL-S.Descripteur(intentionnel(et(contextuel :(OWLASIC 125 6.2. VERS UN DESCRIPTEUR INTENTIONNEL ET CONTEXTUEL : OWLSIC Selon notre vision intentionnelle et contextuelle des Systèmes d’Information Pervasifs (cf. section 4.3.1), les services sont sélectionnés et exécutés dans un contexte donné et sont censés satisfaire certaines intentions particulières. Ces services forment les entités actives de notre espace de services (cf. section 5.4.1). Cet espace de services représente un cadre conceptuel, non technique, qui se définit, entre autres, à travers les différents services qu’il englobe. Ainsi, il est important de présenter une description des services selon cette perspective intentionnelle et contextuelle. Les descriptions de services actuelles ne décrivent pas nécessairement les deux aspects. Pour beaucoup de travaux, cette association reste floue et pas assez exploitée. Ce constat se base sur l’analyse des approches de découvertes de services détaillée dans la section 3.5.2. Ainsi, nous proposons un descripteur intentionnel et contextuel de services qui supporte notre notion d’espace de services. Ce descripteur correspond à la définition et à la description des différentes entités actives (services) qui cohabitent dans un ou plusieurs espaces de services. Pour cela, nous proposons de relever les services à un niveau plus élevé en proposant une description sémantique qui inclut la description intentionnelle et contextuelle des services. Un utilisateur n'a pas besoin d'un service parce qu'il est situé dans un endroit donné ou dans un contexte donné. Il nécessite un service parce qu'il a une intention particulière qu'un service peut satisfaire dans ce contexte. Cette description sémantique étendue des services, permet de gérer l’hétérogénéité de l’environnement. L’objectif ici est de proposer des services de haut niveau, permettant de cacher la complexité technique de l’environnement dû, entre autres, aux différentes technologies et services proposés. Afin de proposer une telle description sémantique, nous avons besoin d’un langage assez riche et suffisamment extensible pour prendre en considération les aspects intentionnels et contextuels dans la description d’un service. Dans le Chapitre 3, nous avons évoqué deux langages de description de services correspondants à ces critères. Le premier est le langage WSMO (cf. section 3.4.3.2) qui représente une ontologie décrivant sémantiquement les différents aspects relatifs à un service Web. WSMO (Keller et al., 2004) se caractérise essentiellement par son approche basée sur les intentions. Celle-ci prend en considération les intentions spécifiques derrière une recherche de services de l’utilisateur. Le deuxième langage est le langage OWL-S (Martin et al., 2007). Celui-ci (cf. section 3.4.2.1) définit les capacités des services Web en trois parties représentées par des ontologies interdépendantes : le profil de services, le modèle de processus et le grounding. Face à ces deux propositions, nous avons considéré la question suivante : quel langage parmi les deux cités ci-dessus (OWL-S et WSMO) permettrait de décrire, d’une façon claire, expressive et sans perte d’informations, l’intention que le service est capable de satisfaire et le contexte de validité et d’exécution de ce service, et qui permet également de raisonner dessus. Selon Roman et al. (Roman et al., 2005), dans WSMO, une intention décrit les aspects Descripteur(intentionnel(et(contextuel :(OWLASIC 126 liés aux désirs de l'utilisateur par rapport à la fonctionnalité demandée. Toutefois, cette intention n’est pas formulée selon un modèle bien spécifique. Comme nous l'avons mentionné dans la section 3.4.3.2, cette information est représentée uniquement comme un ensemble d'objets. Par conséquent, WSMO ne permet pas d'identifier le rôle réel que joue chaque objet dans la spécification de l'intention. En d’autres termes, ce langage n'exploite pas la sémantique des verbes, des cibles et des paramètres qui peuvent représenter une intention, comme présenté dans les travaux de (Kaabi et Souveyet, 2007) et (Rolland et al., 2010). Nous concluons ainsi, que cette représentation d’intention perd une partie de son expressivité avec une telle modélisation. Dans notre vision, l’intention représente un élément clé très riche et qui apporte une réelle compréhension au service associé. Il est important de décrire la sémantique de tous éléments composant cette intention pour tout éventuel usage, tel que la découverte et la prédiction de service. De plus, une des reproches de WSMO est qu’il ne s’appuie pas sur des moteurs de raisonnement qui soient assez performants et puissants pour raisonner sur l’intention et le contexte. Cette phase de raisonnement est très importante dans nos mécanismes de découvertes (cf. Chapitre 7) et de prédictions de services (cf. Chapitre 8), étant donné que nous raisonnons sur les ontologies et sur les descriptions de services. Concernant le langage OWL-S (cf. section 3.4.2.1), les dernières recherches dans l’Informatique orientée services recommandent l'utilisation de ce langage pour décrire sémantiquement les services. Selon (Suraci et al., 2007), même si OWL-S est conçu pour les services Web, il est riche et suffisamment général pour décrire tout type de services. Le langage OWL-S représente un langage souple et facilement extensible, tel que démontré par les travaux de Suraci et al. (Suraci et al., 2007) et Vanrompay et al. (Vanrompay et al., 2011). De plus, OWL-S offrent un très grand pouvoir d’expressivité ainsi que la possibilité d’inférer de nouvelles connaissances grâce au nombre de constructeurs de ce langage ainsi qu’au nombre de raisonneurs proposés, tels que Jena (Carroll et al., 2004), Pellet (Parsia et Sirin, 2004) et Racer (Haarslev et Möller, 2003). Ainsi, nous avons choisi de nous baser sur OWL-S puisque, d’une part, il est assez souple et extensible pour inclure d’autres types d’informations dans la description de services, et d’autre part, parce qu’il offre des moteurs de raisonnement assez puissants nécessaires pour la découverte et la prédiction de ces services. Nous proposons ainsi d'étendre OWL-S afin d’inclure les informations concernant à la fois le contexte et l'intention qui caractérisent un service. Cette extension est présentée sous le nom de OWL-SIC (Intentional & Context aware Services Web Ontology Language). Elle a fait l’objet de plusieurs publications (Najar et al., 2011a) (Najar et al., 2011b) (Najar et al., 2012c) et sera utilisée, dans la suite de cette thèse, pour la découverte (cf. Chapitre 7) et prédiction de services (cf. Chapitre 8). Pour inclure l’aspect intentionnel à la description de services, nous avons différentes manières de faire et différentes extensions possibles. La première extension, et la plus simple, consiste à étendre la description du profil de services. La problématique ici est que cette description intentionnelle peut rapidement devenir complexe si on prend en considération la description de la variabilité dans l’expression de l’intention (cf. section 6.3). Ainsi, par soucis d’interopérabilité, nous avons choisi d’apporter des modifications minimes à la partie du Descripteur(intentionnel(et(contextuel :(OWLASIC 127 profil de service, laquelle est utilisée par les mécanismes de découverte traditionnels, afin de garder son caractère souple et flexible. Nous rajoutons ainsi un nouveau bloc « Intention service » dans la description de services, lequel se concentre uniquement sur la description intentionnelle des services. Par ailleurs, et à l’instar de Kirsch-Pinheiro et al. (Kirsch-Pinheiro et al., 2008), nous avons choisi de décrire les informations relatives au contexte par une URL qui fait référence à une ressource externe, permettant ainsi une mise à jour facile des informations de contexte liées à la description du service (cf. section 6.4). Avec notre extension OWL-SIC, nous pouvons décrire l'intention qu'un service est capable de satisfaire et les conditions de contexte dans lesquelles ce service est valable et peut être exécuté. Par ailleurs, contrairement à Rolland et al. (Rolland et al., 2010), nous ne considérons pas que le service intentionnel doive être observé comme une entité distincte du service technique. Cette séparation conduit à des descriptions techniques pauvres qui sont sémantiquement incomplètes, car ils ne comprennent pas de description intentionnelle. Nous proposons, dans cette section, un descripteur sémantique complet, qui considère le service comme une entité unique aux multiples dimensions (dimension intentionnelle, technique et contextuelle), qui s’intègrent dans une description sémantique unique. Chacune de ces dimensions est décrite plus en détails dans les sections suivantes. 6.3. LA DIMENSION INTENTIONNELLE D’UN SERVICE Un service est décrit avec une intention principale qu’il est capable de satisfaire. Celle-ci représente l’intention décrite par la communauté dans un domaine précis et qui va être analysée lors du processus de découverte de services (cf. Chapitre 7). D’un domaine à un autre, une même intention peut être exprimée de différentes manières. Cette variabilité d’expression de l’intention dépend de la communauté d'expert qui a établi l’ontologie d’intention et qui partage une vision commune de leur domaine, comme les ontologies soutenues par la communauté proposés par Mirbel et Crescenzo (Mirbel et Crescenzo, 2010). Ainsi, nous avons trouvé intéressant de prendre en considération cette variabilité dans notre descripteur de services. De plus, comme nous l’avons souligné dans la section 3.4.3.3, une intention peut être atomique ou agrégat. Une intention atomique représente une intention qui ne se décompose pas en d’autres sous-intentions, tandis qu’une intention agrégat représente une intention qui se compose d’un ensemble de sous-intentions, qui à leur tour peuvent être décomposables. Nous introduisons, dans la section 6.3.1, notre extension de OWL-S pour inclure les informations sur l’intention principale du service et sa variabilité d’expression. Ensuite, nous détaillons dans la section 6.3.2, notre prise en compte de la composition intentionnelle dans notre descripteur de services. Descripteur(intentionnel(et(contextuel :(OWLASIC 128 6.3.1.Le service et son intention principale L'information relative à l'intention est décrite, comme l’illustre la Figure 33, dans une ontologie « Intention Service ». Cette ontologie représente une description de l'intention principale que le service est censé satisfaire. Elle se base sur une ontologie de domaine qui est établie par une communauté d'expert partageant un même domaine. Cette vision s'intègre parfaitement avec les SIP, puisque les services offerts par ces systèmes doivent s’adapter à une communauté d'utilisateurs spécifique. Figure 33. Extension de OWL-S pour représenter l'intention du service Notre extension intentionnelle rajoute à OWL-S une nouvelle propriété au service, nommée « satisfait » et sa classe respective « IntentionService » (cf. Figure 33). Chaque instance de « service » permet ainsi de satisfaire une description intentionnelle de celui-ci. L’ontologie « Intention Service » fournit les informations nécessaires pour découvrir le service approprié qui satisfait au mieux une ou plusieurs intention(s) particulière(s). L’objectif ici est de mentionner l’intention qu’un service permet de satisfaire de manière à ce que ce service puisse être retrouvé à partir de l’intention de l’utilisateur. La prise en compte de cet aspect intentionnel dans la description de services conduit à des modifications dans l’ontologie de services, pour faire référence à l’ontologie d’intention de services, et dans l’ontologie de profil, pour faire appel à l’ontologie d’intention lors du mécanisme de découverte de services par exemple. Nous introduisons dans les sections suivantes ces modifications ainsi que la nouvelle ontologie d’intention. Service Profil Service Modèle Service Grounding Service Intention Service "Supporte" (Comment y accéder?) "Présente" (Qu'est ce qu'il fait?) "Satisfait" (Qu'est ce qu'il satisfait?) "DécritPar" (Comment il fonctionne?)Descripteur(intentionnel(et(contextuel :(OWLASIC 129 6.3.1.1. Extension de l’ontologie de service Les parties constituant la description d’un service en OWL-S (cf. Figure 33) sont organisés dans une ontologie. Cette ontologie représente la structure de cette description exposant ces trois parties de base, à savoir le profil, le modèle et le grounding du service. Nous y rajoutons une quatrième partie, représentant la dimension intentionnelle d’un service. Nous étendons ainsi cette ontologie de services, comme l’illustre la Figure 34, afin de mettre en avant le lien entre un service et une intention. Cette extension a été établie par l’ajout d’une classe « Service Intention » qui fournit une superclasse à la description intentionnelle du service (ligne 7-10 de la Figure 34). Figure 34. Extension de l'ontologie de services La classe « Service Intention » ne mentionne aucune représentation des services, mais elle impose les informations de base permettant de lier une intention avec une instance de service. Il existe une relation réciproque entre un service et une intention de service, de sorte qu'un service peut être lié à une intention et une intention à un service. Ces relations sont exprimées par les propriétés « satisfait » (satisfies) et « satisfaitPar » (satisfiedBy). D’une part, la propriété « satisfait » décrit une relation entre une instance de service et une instance d'intention (ligne 14-18 de la Figure 34), indiquant ainsi que le service est capable de satisfaire cette intention. D’autre part, la propriété « satisfaitPar » représente l'inverse de « satisfait » (ligne 20-28 de la Figure 34). Elle spécifie qu'une intention donnée peut être satisfaite par un service. 6.3.1.2. Extension de l’ontologie de profil L’ontologie de profile, comme nous l’avons mentionné dans la section 3.4.2.1, exprime ce que le service réalise. Cette ontologie donne une description de haut niveau d'un service, à Descripteur(intentionnel(et(contextuel :(OWLASIC 130 des fins de description, de publication et de découverte des services. Ainsi, afin d’inclure l’aspect intentionnel de notre descripteur de services, nous avons dû étendre l’ontologie du profil de services, comme l’illustre la Figure 35. Dans la description du « Profil Service », nous avons introduit un pointeur vers la sousontologie qui présente la description intentionnelle de service (ligne 44-47 de la Figure 35). Pour cela, nous proposons la propriété « has_intention ». Celle-ci a comme domaine la classe profil (Profile) et comme classe respective (range) la classe « intention ». Figure 35. Extension de l’ontologie de description de profil de service La classe intention représente une spécialisation de la classe de profil de service (Service Profile). Cette nouvelle classe utilise le caractère flexible et extensible de OWL-S. En effet, nous y ajoutons une nouvelle classe tout en gardant en perspective la possibilité de représenter l’ontologie d’intention de différentes manières. Figure 36. Description du service « Edition_Proposal_Service » en OWL-SICDescripteur(intentionnel(et(contextuel :(OWLASIC 131 Pour mieux comprendre cette description intentionnelle de services proposée à travers OWL-SIC, nous présentons, dans la Figure 36, un exemple de description de service. Dans cet exemple, nous présentons la description d’un service d’édition de proposition nommé « Edition_Proposal_Service » (ligne 5). Dans cette description, le service satisfait l’intention « prepare proposition » (ligne 9). Cette ligne représente l’identifiant de la description intentionnelle du service qui est détaillée dans le bloc de description des intentions (ligne 27- 29). De plus, dans la partie de description de profile du service, nous rajoutons un pointeur vers la description de cette intention (ligne 21), afin de l’explorer dans un processus de découverte de services. On observe que le changement que nous avons apporté au profil de service est minimal, puisque l’intention n’y est pas détaillée, étant décrite par l’ontologie d’intention. Ceci est particulièrement important pour maintenir une certaine compatibilité entre cette nouvelle description de services et les mécanismes de découverte. 6.3.1.3. Ajout d’une ontologie d’intention Nous proposons, dans le cadre de cette extension, une ontologie d’intentions, laquelle propose une description des intentions qu’un service est capable de satisfaire. Nous considérons qu’un service satisfait une intention principale, qu’elle soit atomique ou composite. Cette intention est formulée selon le modèle de Prat (Prat, 1997) (cf. section 3.4.3.1). Ce modèle présente l’intention sous forme de verbe, de cible qui peut être un objet ou un résultat et un ensemble de paramètres qui sont optionnels. Les paramètres représentent la façon, la quantité, la qualité, la direction, la qualité et le bénéficiaire. La Figure 37 illustre les classes et les propriétés qui composent cette description intentionnelle d’un service. Figure 37. Les classes et les propriétés de l'ontologie d’intention Selon Prat (Prat, 1997), le verbe expose l'action permettant la réalisation de l'intention. La cible représente soit l'objet existant avant la réalisation de l'intention ou le résultat découlant Moyen Manière Source Destination Objet Résultat Façon Quantité Direction Qualité Bénéficiaire Verbe Cible Paramètre Intention Intention Service Légende owl : Class rdfs : subClassOf owl : Property "aParamètre" "aCible" "aVerbe" "aSens" Sens "aSynonym"Descripteur(intentionnel(et(contextuel :(OWLASIC 132 de la satisfaction de l'intention. Les paramètres sont utiles pour clarifier l'intention et pour exprimer les informations supplémentaires. Le paramètre direction caractérise la source ou la destination des entités. D’un côté, la destination identifie l'emplacement des entités produites par la satisfaction de l'intention. De l'autre côté, la source identifie l'emplacement initial des entités. En outre, ce modèle d'intention représente le paramètre façon, faisant référence à l'instrument de la satisfaction de l'intention. Il représente le moyen ou la manière de satisfaire l’intention. Le moyen indique l'entité qui sert d'instrument pour atteindre l'intention, tandis que la manière identifie une approche dans laquelle l'intention peut être satisfaite. Enfin, le paramètre de qualité définit une propriété qui doit être atteinte ou maintenue. Dans leurs travaux, Corby et al. (Corby et al., 2009) proposent une ontologie d’intention qui organise l’intention par section, selon le modèle de la carte (Rolland et al., 1998). Dans nos travaux, nous nous concentrons sur la description de l’intention elle-même. Toutefois, nous pouvons dégager certains points communs entre les deux ontologies, que nous avons entouré dans notre ontologie d’intention à la Figure 38. Par exemple, dans les deux ontologies nous suivons la même description des paramètres qui sont la façon, la quantité, la qualité, la direction, la qualité, etc. Ainsi, nous attachons dans ces deux travaux une cible à l’intention, appelée objet dans l’ontologie proposée par Corby et al. (Corby et al., 2009). Par contre, la description des verbes dans notre ontologie d’intention est plus riche. En effet, nous exploitons plus d’éléments autour du verbe, tels que le synonyme et le sens, que dans l’ontologie de Corby et al. (Corby et al., 2009). Notre ontologie d’intention représente une description sémantique du modèle d’intention de Prat (Prat, 1997), alors que l’ontologie de Corby et al. représente une description sémantique du modèle de la carte. Figure 38. Comparaison avec l'ontologie d'intention de Corby et al. (Corby et al., 2009) Chaque élément de cette description intentionnelle doit être lui-même sémantiquement défini au préalable dans des ontologies d’intentions qui sont dépendantes du domaine. En réalité, ces ontologies intentionnelles décrivent chacune un élément de l’intention : une ontologie de verbes, une ontologie de cibles rendues accessibles par le SIP et des ontologies de paramètres. Les ontologies de verbes et de cibles établissent de manière non-ambiguë la Moyen Manière Source Destination Quantité Façon Qualité Direction Bénéficiaire Requête Générique Carte Directive Réalisation Intention Paramètre Section "aStratégie" "OpérationnaliséPar" "ComposéDe" "aRessource" Ressource "aVerbe" Localisation Temps Référence Intention Verbe "aSource" "aCible" Start Stop Objet "aObjet" Moyen Manière Source Destination Objet Résultat Façon Quantité Direction Qualité Bénéficiaire Verbe Cible Paramètre Intention Intention Service "aParamètre" "aCible" "aVerbe" "aSens" Sens "aSynonym" Ontologie d'intention Ontologie pour les démarches de recherche d'information (Corby et al., 2009) "isA" "isA" "isA"Descripteur(intentionnel(et(contextuel :(OWLASIC 133 sémantique des actions acceptées par le SIP dans l’espace de services, représentant le verbe de l’intention, et l’ensemble des cibles atteignables par le biais de cet espace. Une telle définition, basée sur une ontologie prédéfinie, n’est envisageable que dans le cadre fermé d’un Système d’Information. En effet, ces systèmes n’autorisent pas un comportement ouvert sur des intentions et des cibles non-autorisées ou inconnues auparavant, de par leur importance stratégique dans les entreprises. L’ontologie de verbe (OntoV) contient un ensemble de verbes liés à un domaine précis, celui du SIP, leurs significations et les relations entre ces verbes. OntoV établit une description sémantique des actions acceptées par les SIP. Elles présentent des liens d’héritage entre les verbes reflétant des relations de hyponymie (plus spécifique) et d’hyperonymie (plus général). A part ces deux liens, cette ontologie de verbes décrit la relation de synonyme entre deux verbes. Deux verbes synonymes représentent deux verbes identiques ou très voisins (ayant le même sens ou deux sens très proches). De plus, un verbe peut avoir un sens bien défini. En conséquence, nous décrivons le verbe, dans l’ontologie (OntoV), avec son sens. Le sens du verbe est introduit par le fournisseur de ce service afin de rajouter plus d’expressivité au verbe. En d’autres termes, il n’est là que pour aider l’utilisateur à mieux comprendre la signification des verbes qui existent dans l’ontologie des verbes (OntoV). Par exemple, le verbe « consulter » peut être décrit par plusieurs sens, à savoir « examiner quelque chose » ou « interroger quelque chose ». L’ontologie des cibles (OntoT) représente des concepts sémantiques relatifs aux cibles pouvant être utilisées avec une intention. Cette ontologie établit de manière non-ambiguë la sémantique de l’ensemble des cibles atteignables par le biais de l’espace de services. Elle présente une vue hiérarchique de plusieurs types de cibles du domaine en question, en présentant les liens de spécialisations et de généralisation entre elles. Figure 39. Exemple de description intentionnelle d'un service d'édition de propositionDescripteur(intentionnel(et(contextuel :(OWLASIC 134 La Figure 39 illustre un exemple de description intentionnelle du service d’édition de proposition. Ce service satisfait l’intention principale « prepare proposition » (ligne 5). Cette intention se compose du verbe « prepare » (ligne 6-9). La cible de l’intention représente le résultat obtenu par la satisfaction de cette intention, à savoir « proposal » (ligne 11-18). Comme nous l’avons souligné précédemment, une même intention peut être exprimée de différentes manières selon la communauté. Ceci exprime la variabilité dans l’expression de l’intention que nous introduisons dans notre description intentionnelle des services. Pour un même service, nous pouvons associer différentes intentions, dont une est représentée comme principale et les autres comme ses alternatives dans des domaines différents. Par exemple, le service d’édition de proposition a comme intention principale « prepare proposition ». Cette intention est décrite dans le cadre d’une entreprise qui peut configurer ses propositions (e.g. logiciels) selon les appels d’offre. Cette même intention peut être exprimée différemment dans le cadre d’une autre entreprise qui propose ses produits sans configuration à ses clients. Dans ce cas, l’intention qui sera associée à ce service sera plutôt « propose product ». Ces multiples variations d’intention sont décrites dans le bloc de la description intentionnelle de la même manière que l’intention principale est décrite dans la Figure 39. En plus de cette variabilité dans l’expression, une intention associée à un service peut être soit une intention simple, appelée intention atomique, soit une intention décomposable en plusieurs sous intentions, appelée intention agrégat (cf. section 3.4.3.3). Nous estimons qu’il est important de prendre en compte cette composition intentionnelle qui peut être exploitée dans d’éventuel mécanisme de composition de services. Nous discutons cette composition intentionnelle dans la section suivante. 6.3.2.La composition intentionnelle Un service satisfait une intention particulière. Cette intention, et comme nous l’avons introduit précédemment, peut être atomique ou agrégat. Une intention atomique représente une intention simple et non décomposable, tandis que l’intention agrégat représente une intention qui est composée d’autres intentions. La satisfaction d’une intention agrégat nécessite la satisfaction de toutes ses sous intentions. Cet aspect intentionnel reflète la composition des intentions introduites dans les travaux de Kaabi et Souveyet (Kaabi et Souveyet, 2007) et Rolland et al. (Rolland et al., 2010). Néanmoins, et comme nous l’avons souligné dans la section 3.4.3.3, la vision de ces auteurs ne prend pas en considération l'évolution de la technologie de services qui peut supporter des logiciels avec des fonctionnalités réutilisables, ainsi que des systèmes hérités (legacy system) avec des processus complexes cachés par des technologies. Dans leurs travaux, Kaabi et Souveyet (Kaabi et Souveyet, 2007) et Rolland et al. (Rolland et al., 2010) considèrent que seuls les services intentionnels atomiques peuvent être opérationnalisés à travers le service logiciel. Ceci limite la réutilisation des systèmes hérités, puisque ces systèmes peuvent être associés à des intentions agrégats, mais ils ne peuvent pas être assimilés à des intentions atomiques simples. Descripteur(intentionnel(et(contextuel :(OWLASIC 135 Dans notre descripteur, nous nous sommes inspirés de ces travaux (Kaabi, 2007) (Rolland et al., 2010) et nous admettons ainsi l’importance de la composition intentionnelle dans la description d’un service. Par contre, et dans la perspective de suivre cette évolution technologique et de prendre en considération des systèmes complexes tels que les systèmes hérités, nous estimons qu’un service atomique peut satisfaire des intentions complexes qui peuvent être agrégats. Ainsi, puisqu’un service peut être assez complexe en soi, d’un point de vue intentionnel, nous avons décidé d’inclure la composition intentionnelle dans la description de services. Ceci nous distingue également de WSMO qui ne gère pas cet aspect. En effet, un service englobe un certain processus intentionnel lequel peut être aussi simple que la satisfaction d’une seule intention atomique, mais qui peut être également assez complexe encapsulant une véritable composition intentionnelle. Que le service soit simple ou composite, l’intention qu’il satisfait peut être également atomique ou agrégat. Nous avons donc deux compositions orthogonales, représentées sur deux dimensions séparées : une technique et l’autre intentionnelle. Dans le cas d’une composition traditionnelle, l’agrégation technique fournit des éléments techniques nécessaires à l'exécution du service. Par contre, l’agrégation intentionnelle permet de mieux comprendre, du point de vue utilisateur final, le service et les différentes façons de satisfaire son intention principale. Ainsi, nous proposons d'étendre le modèle de processus de OWL-S en incluant la spécification d'un processus intentionnel. Cette nouvelle spécification est décrite indépendamment de l’agrégation traditionnelle, étant donné que cette dernière dépasse le cadre de cette thèse. Notre extension est inspirée de la spécification technique des processus de services décrits en OWL-S et de la composition de services intentionnels proposée par (Kaabi et Souveyet, 2007) et (Rolland et al., 2010). La Figure 40 présente notre extension de OWL-S pour inclure l’aspect de composition intentionnelle. Cette extension considère deux types de processus : le processus intentionnel atomique et le processus intentionnel agrégat. Le processus intentionnel atomique représente la spécification d’une intention qui est indécomposable. Ce processus intentionnel atomique est ainsi décrit uniquement par son intention principale qui n’est pas décomposable. Par exemple, le service « LaunchConnexionVPN_service » est un service qui permet de répondre à l’intention principale de lancement de connexion I5 = {#connecter, #VPN, ∅}. Cette intention peut être satisfaite directement et n’a pas besoin d’être décomposée en sousintentions pour être satisfaite. A l’opposé, le processus intentionnel agrégat est un processus dont l’intention principale peut être décomposée en des intentions plus fines qui contribuent à sa satisfaction. Par exemple, le service « AccessClientView_Service » est un service qui répond à l’intention principale I6 = {#consulter, #fiche_client, ∅}. Cette intention se compose d’autres intentions : I6.1 = {#connecter, #VPN, ∅}, I6.2 = {#afficher, #liste_client, ∅} et I6.3 = {#sélectionner, #client, ∅}. Ces intentions représentent les intentions qui devront être satisfaites pour que l’intention principale le soit. Descripteur(intentionnel(et(contextuel :(OWLASIC 136 Figure 40. Extension de OWL-S pour prendre en considération la composition intentionnelle des services Par ailleurs, notre extension du modèle de processus considère un processus intentionnel simple, lequel fournit une vue abstraite d’un processus intentionnel pouvant être atomique ou agrégat. Comme l’illustre la Figure 40, un processus intentionnel simple est réalisé par un processus intentionnel atomique et s’étend en un processus intentionnel agrégat. Un processus intentionnel agrégat peut être soit un processus intentionnel composite (qui établit des liens ET entre les intentions et affine l’intention principale en sous intentions qui lui sont associées), soit un processus intentionnel à variante (lequel établit des liens OU entre les intentions et offre le choix dans la satisfaction de l’intention principale) (cf. section 3.4.3.3). Ces processus, comme l’illustre la Figure 40, relient les intentions entre elles par des constructeurs bien spécifiques. Ces constructeurs, appelé constructeur de composition intentionnelle et constructeur de variation intentionnelle, sont inspirés des liens de choix et de composition proposés par Kaabi (Kaabi, 2007). Ces liens répondent parfaitement aux liens de composition et de variation qui peuvent exister entre les intentions. Dans la cadre du processus intentionnel composite, le lien séquentiel a été choisi parce qu’il représente, dans le cadre de notre processus intentionnel composite, le cas le plus typique dans lequel il y a un ordre séquentiel entre les intentions qui contribuent à la satisfaction de l’intention principale. Nous avons choisi de représenter le lien parallèle parce qu’il reflète le cas dans lequel la satisfaction de l’intention principale nécessite la réalisation de certaines intentions en parallèle. Finalement, le lien itératif a été choisis parce qu’il existe des cas où l’intention principale ne peut être satisfaite que par l’itération de certaines de ces intentions composites. Dans la cadre du processus intentionnel à variation, nous avons choisi de représenter le lien multiple parce qu’il reflète un choix non exclusif dans la manière de satisfaire l'intention principale par les intentions composites. Parmi ces intentions composites, au moins une sera choisie. De plus, nous avons décidé de garder le lien alternatif parce qu’il présente le cas exigeant un choix exclusif dans la manière de satisfaire l'intention principale Descripteur(intentionnel(et(contextuel :(OWLASIC 137 par les intentions composites. Parmi ces intentions composites, uniquement une sera choisie. Nous gardons également le lien chemin parce qu’il offre un choix dans la façon d'atteindre l’intention principal. Dans ce cas, la variation intentionnelle porte sur un chemin d’intentions qui représente un ensemble d’alternatifs entre elles. Figure 41. Exemple d’un processus intentionnel composite Afin d’illustrer la composition intentionnelle dans la description de services, nous considérons le service « Edition_ Proposal_Service » qui permet de décrire une proposition commerciale et de l'envoyer au client. La Figure 41 décrit le processus intentionnel associé à ce service. Il représente un séquencement entre quatre processus intentionnels (ligne 5-16) dont l’ordre de composition doit être pris en compte lors de la satisfaction de l’intention principale. Plus précisément, d’un point de vue intentionnel, cette intention principale se compose de trois processus intentionnels atomiques, à savoir les intentions atomiques « Launch Connection » (ligne 8), « Encrypt Data » (ligne 10) et « Edit Proposal » (ligne 12). Celles-ci contribuent à la satisfaction directe de l’intention principale associée au service « Edition_ Proposal_Service ». De plus, celui-ci, et toujours d’un point de vue intentionnel, comporte une variante représentée par le processus intentionnel à variation décrit par l’intention « Send Proposal » (ligne 14). Figure 42. Exemple de processus intentionnel à variationDescripteur(intentionnel(et(contextuel :(OWLASIC 138 Cette intention « Send Proposal », comme l’illustre la Figure 42, représente un processus intentionnel présentant un choix non exclusif dans la manière de satisfaire cette intention par les deux intentions « Send Mail » (ligne 30) et « Send Fax » (ligne 32). Parmi ces deux intentions composites, au moins une devra être satisfaite. Ces deux dernières représentent deux processus intentionnels simples. Cet exemple (Figure 42) montre que pour satisfaire l’intention principale d’envoi de proposition, nous avons deux choix, soit l’envoi de la proposition par Mail et/ou l’envoi de la proposition par Fax. Dans le cadre du processus intentionnel à variation, nous croyons que la variabilité sur la réalisation de l'intention peut dépendre de certains facteurs externes. Ces facteurs concernent des informations contextuelles. Tel un service, chaque variante peut avoir des conditions contextuelles dans lesquelles elle est la plus appropriée à être satisfaite. Ainsi, nous attribuons, pour chaque variante à l’intérieur d’un processus intentionnel, une description des conditions contextuelles (cf. section 6.4). Cette description de contexte représente les circonstances dans lesquelles il est le plus approprié de satisfaire une intention à variation plutôt qu’une autre. Figure 43. Extension de OWL-S pour décrire les ressources d'un service intentionnel et les conditions contextuelles Afin de considérer l'influence du contexte sur les variantes intentionnelles, nous étendons le processus de services de OWL-S pour inclure les informations contextuelles dans la description de la variabilité du processus intentionnel mis en place par le service, comme l’illustre la Figure 43. Nous associons ainsi les conditions contextuelles pour chaque variante de ce processus. Cette description contextuelle permettra de rendre le plus explicite possible le processus intentionnel mis en place par le service. Il s’agit d’une démarche descriptive ouvrant de nouvelles possibilités à des mécanismes de découverte et de composition de services. Ainsi, une telle extension pourrait aider à choisir la variante en fonction des conditions de contexte. Nous étendons le modèle de processus OWL-S en intégrant les conditions contextuelles, comme nous allons le décrire dans la section 6.4. Grâce à notre extension OWL-SIC, nous permettons une description de la composition intentionnelle, du point de vue utilisateur final. Cette extension expose la variabilité représentant les différentes manières de satisfaire les intentions de l'utilisateur. Cette description de la composition intentionnelle ouvre la porte pour des processus de composition Processus Paramètre Entrée Sortie Condition Contextuelle aEntrée aParamètre aSortie aContext Légende owl : Class rdfs : subClassOf owl : PropertyDescripteur(intentionnel(et(contextuel :(OWLASIC 139 de services guidée par l’intention et le contexte, présenté à un haut niveau d’abstraction. Même si un tel processus dépasse le cadre de cette thèse, nous jugeons important que le descripteur OWL-SIC puisse permettre ces évolutions. Après avoir introduit notre extension de OWL-S pour inclure l’aspect intentionnel des services, nous détaillons dans la section suivante le deuxième volet de cette extension laquelle inclut l’aspect contextuel. 6.4. LA DIMENSION CONTEXTUELLE D’UN SERVICE Une intention que l'utilisateur souhaite satisfaire émerge dans un contexte donné. Cette constatation soulève l’étroite relation entre la notion de contexte et celle d'intention. Cette relation représente notre troisième hypothèse décrite dans le Chapitre 1 et doit ainsi s’exprimer dans la description de services afin de mieux satisfaire les utilisateurs en leur proposant des services qui s’adaptent à leur contexte. Nous croyons que l’intention de l'utilisateur devient moins significative si nous ne la prenons pas avec son contexte d'usage. Ceci est dû à l’influence que peut avoir le contexte sur la satisfaction de l’intention. En effet, nous croyons que le contexte joue un rôle important dans le choix de la meilleure réalisation pour satisfaire l’intention de l’utilisateur (cf. hypothèse 4 dans la section 1.3). Dans notre formalisation de l’espace de services, nous avons définit deux types de contexte auxquels un service est associé (cf. section 5.3.2.1) : le contexte dans lequel se place et s’exécute un service (Cx) et le contexte requis représentant les conditions contextuelles dans lesquelles le service est le plus apte à atteindre ses objectifs (CxR). Le contexte Cx sert non seulement à indiquer les conditions dans lesquelles le service est exécuté par son fournisseur, mais également à caractériser le positionnement de ce service dans l’espace de services. Tandis que, le contexte requis CxR représente les conditions de contexte permettant au service une meilleure possibilité de satisfaction des intentions qui lui sont associées. Nous proposons ainsi d’étendre le langage de description de services OWL-S, en incluant, d’une part, la description des conditions contextuelles dans lesquelles un service est valide et exécutable (CxR), et d’autre part, le contexte dans lequel le service se place et s’exécute (Cx). Cette extension est introduite dans la description du profil de service « Service Profile ». Ceci est parce que le profil de services représente la partie de la description qui décrit ce que fait le service et comprend également une description des exigences que le demandeur de service doit satisfaire pour utiliser le service avec succès. Ainsi, étant donné que les conditions contextuelles d’un service (CxR) doivent correspondre au contexte de l’utilisateur afin de sélectionner ce service dans le processus de découverte de services (cf. Chapitre 7), nous concluons que ces conditions contextuelles doivent faire partie de ces exigences à l’intérieur du profil de services. De plus, puisqu’un service est décrit par un contexte (Cx) qui reflète les conditions dans lesquelles il s’exécute, nous concluons que ce contexte peut être décrit également dans cette partie afin de refléter non seulement ce que fait le service mais également dans quelles conditions il l’a fait. Descripteur(intentionnel(et(contextuel :(OWLASIC 140 Selon Najar et al. (Najar et al., 2011c), une condition contextuelle (CxR) peut être considérée comme faisant partie de la description du service, car elle indique des situations auxquelles le service est mieux adapté. Toutefois, selon Kirsch-Pinheiro et al. (KirschPinheiro et al., 2008), les informations de contexte (Cx) ne peuvent pas être statiquement enregistrées dans le profil de service puisque certaines de ces informations sont capturées dynamiquement. En effet, les propriétés de contexte liées à l'exécution du service peuvent évoluer dans le temps, alors que le profil de service est censé être une description statique plutôt stable d’un service. Figure 44. Inclusion de la description contextuelle dans la description du profil de services en OWL-S Dans l’objectif d’inclure les informations de contexte, qui sont dynamiques, dans la description d’un service, nous adoptons l'approche proposée par Kirsch-Pinheiro et al. (Kirsch-Pinheiro et al., 2008). Ceci consiste à enrichir le profil de service de OWL-S par un attribut de contexte. Cet attribut introduit dans la description une URL qui fait référence à une ressource externe, laquelle contient la description de contexte. Prenons, par exemple, la description de contexte d’un service qui est contenue dans un fichier externe se trouvant à l’URI suivante : http://www.crinfo.univ-paris1.fr/ExtensionOWL-S/ContextDescription.xml. Notre extension de OWL-S revient à inclure, comme l’illustre la Figure 44, cette URI dans la description du profil à travers la balise . Cette alternative permet aux fournisseurs de services de mettre à jour plus facilement, voir d’une manière automatique, les informations de contexte sans pour autant modifier la description de service elle-même. Afin d’arriver à cette description de contexte, il nous faut donc un modèle de contexte à suivre permettant de décrire comment ces informations de contexte peuvent être représentées. Dans le cadre de notre espace de services, nous avons présenté un méta-modèle de contexte (cf. section 5.3.1) représentant une modélisation générique de contexte Cx et qui peut être instancié par les différentes approches de modélisation de contexte analysées dans la section 2.3.2. Ainsi, afin de représenter notre description de contexte, nous instancions ce métamodèle de contexte. Dans les sections suivantes, nous présentons une instanciation de notre méta-modèle de contexte qui va être utilisée, par la suite, pour représenter le contexte Cx. En se basant sur cette modélisation, nous introduisons notre description des conditions contextuelles de CxR.Descripteur(intentionnel(et(contextuel :(OWLASIC 141 6.4.1.Le modèle de contexte L’ensemble des sujets et des éléments de contexte observés dans un espace de services varient, bien évidemment, en fonction du système et du modèle de contexte mis en place. Depuis quelques années, une tendance se dégage sur les modèles de contexte les plus récents : la description sémantique de ces éléments (Najar et al., 2009). Comme nous l’avons conclu dans la section 2.3.2, de plus en plus de modèles utilisent les ontologies pour décrire ces éléments. Ces ontologies fournissent un vocabulaire représentant de la connaissance sur les informations de contexte selon le domaine (Wang et al., 2004) (Preuveneers et al., 2004) (Reichle et al., 2008). La structuration des informations contextuelles dans des ontologies a de multiples avantages. Ceci permet de partager une compréhension commune de la structure de l’information de contexte (Gu et al., 2004). De plus, la définition d’une ontologie assez riche, permet la réutilisation des connaissances représentées du domaine. Les ontologies ont également comme avantage aussi d’être extensible, permettant ainsi la réutilisation de concepts de base d’une ontologie et de l’étendre selon le domaine auquel elle s’applique. Finalement, la représentation explicite des concepts de contexte dans des ontologies permet également de raisonner sur l’ensemble de concepts. C’est pour toutes ces raisons que de plus en plus de modèles de contexte se basent sur les ontologies pour définir ces éléments. Figure 45. Concept de base de notre Modèle de contexte soutenu par une ontologie Nous proposons, dans cette section, un modèle de contexte soutenu par une ontologie. Malgré, la multitude de modélisation de contexte sous forme d’ontologie, telle que SOUPA (Chen et al., 2004), COBrA (Chen et al., 2003), CoDaMos (Preuveneers et al., 2004), entre autres, nous proposons une autre modélisation de contexte qui prend en considération tous les éléments qu’on a mis en avant lors de notre méta-modélisation de contexte. Les concepts de base de notre ontologie de contexte sont illustrés à la Figure 45. Ce modèle de contexte représente une instanciation de notre méta-modèle de contexte, présentée dans la section 5.3.1, où les concepts du modèle de contexte sont dérivés et compatibles avec les éléments clés de notre méta-modèle. Plus concrètement, nous introduisons le concept « entité de contexte » comme une instanciation du concept « sujet observé », nous gardons la même dénomination pour l’« élément de contexte » et finalement nous dérivons le concept « représentation » du concept « métadonnée ». L’ontologie de contexte que nous proposons se base sur le langage d’ontologie Web OWL (OWL - Web Ontologie Langage), ainsi tous ses concepts héritent des propriétés du concept « owl : Thing » qui représente la racine de la description OWL. Au cœur de cette ontologie, se trouve l’entité de contexte qui représente à qui/quoi l’information de contexte fait référence : utilisateur, dispositif, etc. De plus, cette Descripteur(intentionnel(et(contextuel :(OWLASIC 142 ontologie tourne autour des éléments de contexte, qui correspondent à tout élément détectable et calculable statiquement ou dynamiquement, tels que température, localisation, etc. De plus, afin de fournir une ontologie extensible qui est bien structurée et facile à comprendre, intégrer et étendre, nous utilisons une ontologie multi-niveaux. Cette ontologie, basée sur l’ontologie de contexte MUSIC (Paspallis, 2009), est conçue pour être facilement extensible par des sous-ontologies, dépendantes du domaine, en fonction du système dans lequel le modèle s’applique. Ces ontologies sont construites par niveaux que nous pouvons étendre facilement. L’utilisation d’ontologies offre une description sémantique particulièrement riche et fournit de nouvelles perspectives pour les mécanismes d’adaptation grâce aux différentes possibilités de raisonnement. Ainsi, les concepts de base de notre métamodèle sont décrits sémantiquement dans une ontologie multi-niveaux, qui étend les concepts de base de notre ontologie de contexte aux éléments les plus communs et les plus utilisés. A la Figure 46, nous représentons, à ce niveau, l’ensemble des concepts que nous avons identifiés comme couramment utilisés dans la littérature. Par exemple, « GPS » représente un héritage du concept « localisation » qui représente lui même une spécification du concept « environnement ». Cette ontologie multi-niveaux est structurée comme suit : • Ontologie générique (Niveau supérieur) décrit les informations de base de contexte dans un environnement pervasif. Ces informations sont assez génériques et communes à plusieurs domaines. A ce niveau, les concepts de base sont définis. Trois concepts de niveau supérieur sont ainsi définis (voir Figure 46) : l’utilisateur, l’environnement et l’entité informatique. Ces concepts sont organisés autour du concept « Element de Contexte » qui représente le point d’entrée pour déclarer l’ontologie de haut-niveau. L’Element de Contexte est spécialisé par la suite afin d’y représenter les concepts les plus spécifiques relatifs aux notions de l’utilisateur, l’environnement et l’entité informatique. Cette ontologie de haut-niveau est en suite spécialisée à un niveau inférieur. En effet, dans la conception de cette ontologie, le niveau supérieur de l’ontologie générique peut par la suite être étendu selon le domaine en un ensemble d’ontologies de niveau inférieur ; • Ontologie spécifique du domaine (Niveau inférieur) comporte des informations de contexte spécifiques à un domaine d’application. Le détail des informations de base de contexte, représentées dans le niveau supérieur de cette ontologie, est défini dans ce niveau inférieur qui est spécifique à un domaine donné et qui varie d’un domaine à un autre. En d’autres termes, les informations du concept représenté dans ce niveau de l’ontologie sont divisées en plusieurs sous-domaines, à l’instar du modèle de contexte proposé par Wang et al. (Wang et al., 2004). Chacun définit les détails et les propriétés spécifiques pour un domaine d'application donné. Par exemple, le concept « localisation » de l’ontologie de haut niveau peut être spécifié en « localisation Architecturale » qui est de même spécifiée en « bâtiment », « chambre » et « passage », entres autres. Dans un autre domaine, ce concept « localisation » peut être spécifié en « localisation GPS » qui a comme propriétés : « longitude », « latitude » et « altitude ».Descripteur*intentionnel*et*contextuel :*OWL3SIC 143 Figure 46. Ontologie multi-niveaux de contexte Element de Contexte Utilisateur Environnement Entité de Calcul Profile Activité Rôle ... Temps Condition physique Localisation ... Ressource Dispositif Réseau Application ... Ontologie générique : Ontologie de haut niveau Ontologie-spécifique du domaine : Ontologie de bas niveau Rôle Condition physique Profile name age expertise Activité Déplacement Réunion Conférence Commercial Directeur Technicien température humidité bruit Localisation Architecturale Batiment Chambre Passage Localisation GPS longitude lattitude altitude << Espace de service au travail >> << Espace de service à la maison >> owl : Thing Entité de Contexte Représentation Représentation par Défaut Utilisateur Dispositif Homme Femme Représentation Localisation Représentation Localisation GPS Représentation Architecturale ... ... Dispositif de communication Ordinateur ... ... ... Légende owl : Class (haut niveau) owl : Class (bas niveau) rdfs : subClassOf owl : PropertyDescripteur!intentionnel!et!contextuel :!OWL3SIC 144 A partir des éléments définis sur l’ontologie de haut niveau, nous pouvons distinguer trois catégories pour les éléments de contexte qui y sont représentés : • L’utilisateur joue un rôle central au sein de l’environnement pervasif, puisque bien souvent les systèmes pervasifs cherchent à s’adapter à l’utilisateur. Cette adaptation à l’utilisateur représente d’ailleurs un des principes fondateurs de l’Informatique Pervasive, laquelle soutient que l’informatique doit s’adapter à l’utilisateur et non l’inverse. Les concepts de cette catégorie décrivent ainsi l’utilisateur et tout ce qui lui est rattaché. Ces éléments de contexte sont ainsi observés à partir d’un sujet représentant l’utilisateur. Parmi les concepts plus importants de cette catégorie, on peut citer : profil, rôle, activité, etc. ; • L’environnement représente un élément clé dans la spécification de contexte puisque l’utilisateur est représenté dans un environnement avec lequel il interagit. L’environnement peut être de différentes natures : physique (GPS, température, localisation, etc.), logique (mémoire disponible sur le terminal, préférences de l’utilisateur, etc.) et organisationnel (rôle de l’utilisateur, état d’exécution d’un processus, etc.). Cette catégorie comporte des informations sur la localisation, le temps, et de manière plus générale, le contexte physique représentant les conditions environnementales. De manière générale, ces éléments de contexte correspondent à l’observation d’un environnement physique autour d’un sujet donné, le plus souvent l’utilisateur, même si d’autres entités seraient également possibles (la localisation d’un terminal ou d’un capteur, par exemple). ; • L’entité de calcul représente la description du matériel et du logiciel dans l’environnement observé bien souvent, spécifique à un dispositif (sujet). Cela comprend la spécification du type du réseau, de la bande passante disponible, de la taille de la mémoire d’un dispositif, etc. Cette modélisation va nous permettre de décrire le contexte dans lequel s’exécute le service (Cx) (cf. section 6.4.2). Quant au contexte requis (CxR) (cf. section 6.4.3), il va être structuré de la même manière que Cx. Par contre, puisqu’il représente des conditions contextuelles, ceci nécessite un langage sémantique adéquat pour pouvoir représenter ces conditions. Ainsi, nous répartissons la description globale de contexte du service, qui est enregistrée dans le fichier externe, en deux parties. D'un côté, nous décrivons les informations de contexte qui se réfèrent aux conditions contextuelles (CxR) dans lesquelles il est plus utile de sélectionner et appeler ce service. Cette partie sera décrite dans un bloc intitulé « condition ». De l'autre côté, nous décrivons le contexte dans lequel un service s’exécute (Cx). Cette partie sera décrite dans un bloc intitulé « state » et fera référence aux conditions de contexte dans lesquelles un service est exécuté par le fournisseur de services (l'état dans lequel le service est exécuté). Nous détaillons la description de contexte d’exécution Cx ainsi que le contexte requis CxR d’un service dans les sections suivantes. Descripteur!intentionnel!et!contextuel :!OWL3SIC 145 6.4.2.Le contexte d’exécution d’un service (Cx) Selon cette modélisation de contexte, présentée dans la section précédente, nous représentons le contexte d’exécution d’un service Cx dans une partie nommée « state » du fichier de description contextuelle. Ce contexte Cx est décrit comme un ensemble d’observations acquises par des capteurs (cf. section 5.3.2.1). Chaque observation est décrite par l’entité que nous avons observée, l’élément de contexte attribué à cette entité, ainsi que la valeur associée à cet élément et sa représentation. Pour illustrer cette description de contexte Cx, nous penons l’exemple de l’intention « prepare proposal » satisfaite par le service « edition proposal service ». Ce service a été exécuté dans un contexte décrivant, entre autre, l’observation de la taille de l’écran de son dispositif qui était égale à 10 pouces et l’observation de sa localisation qui était en France. Nous représentons, dans la Figure 47, l’observation de la localisation de l’utilisateur. Figure 47. Exemple d'une observation de contexte du service Cx Cette observation est décrite dans la partie « context state » (ligne 3-25 de la Figure 47). Elle décrit l’élément de contexte localisation (ligne 6-7) de l’entité observé utilisateur (ligne 4-5). Plus spécifiquement, cette observation capture la ville dans laquelle se trouve l’utilisateur (ligne 10-12). L’élément de contexte ville représente une spécification de l’élément de contexte localisation dans l’ontologie multi-niveaux de contexte (cf. section 6.4.1). Ceci représente l’association qui peut exister entre les éléments de contexte représentée dans notre méta-modèle de contexte (cf. section 5.3.1). Dans cette observation, la valeur associée à la localisation de l’utilisateur est France (ligne 20). Cette valeur est représentée sous la forme d’une localisation par ville (ligne 13-15). Inspiré de cette modélisation et description contextuelle de Cx, nous décrivons dans la section suivante le contexte requis d’un service (CxR). Descripteur!intentionnel!et!contextuel :!OWL3SIC 146 6.4.3.Le contexte requis par un service (CxR) En se basant sur la modélisation de contexte Cx, nous représentons le contexte requis d’un service CxR dans une partie nommée « condition » du fichier de description contextuelle. Ce contexte CxR est décrit comme un ensemble de conditions contextuelles (cf. section 5.3.2). Chaque condition contextuelle est décrite par l’entité sur laquelle porte la condition, l’élément de contexte attribué à cette entité, ainsi que la condition. Cette condition est exprimée par un ensemble d’opérateurs. D’une part, ces opérateurs peuvent être des opérateurs simple, tels que l’égalité, la différence, l’intervalle, la supériorité et l’infériorité. D’autre part, ces opérateurs peuvent être plus complexes, par exemple un opérateur permettant de déterminer si la localisation de l’utilisateur se trouve dans une zone particulière. Il est à noter que certains de ces opérateurs nécessitent des opérations de transformation d’une représentation à une autre pour pouvoir évaluer la satisfaction de la condition. Figure 48. Exemple d'une condition de contexte CxR Pour illustrer cette description de contexte CxR, nous penons le même exemple utilisé dans la section précédente. Notre objectif est de porter une condition qui permet d’évaluer la satisfaction de l’observation décrite dans la Figure 47. D’une manière générale, cette condition permet d’évaluer si la localisation de l’utilisateur (France) satisfait la condition qui indique que ce service exige que la localisation soit en Europe. Cette condition contextuelle est décrite dans la partie « context condition » (ligne 3-26 de la Figure 48). Elle porte sur l’élément de contexte localisation (ligne 6-7) de l’entité utilisateur (ligne 4-5). Plus spécifiquement, cette condition emploie un opérateur « Location-In » (ligne 20) sur une valeur de localisation qui est l’Europe (ligne 21). Ceci veut dire que la condition portée sur la Descripteur!intentionnel!et!contextuel :!OWL3SIC 147 localisation observée par Cx doit être en Europe. Si cette localisation observée se trouve en Asie par exemple, alors cette condition du service ne sera pas satisfaite. Dans ce cadre, nous rappelons que les conditions contextuelles d’une intention à variation, décrite dans la section 6.3.2, sont décrites de la même manière que le contexte CxR du service. D’une manière conceptuelle, un contexte requis CxR peut être attribué soit à un service soit à une intention à variation. 6.5. CONCLUSION Nous avons proposé, dans le cadre de ce chapitre, un descripteur sémantique des services intentionnels et sensibles au contexte. Ce descripteur, à l’encontre des différentes approches présentées dans le Chapitre 3, propose une extension de OWL-S qui combine et exploite la relation entre le contexte et l'intention dans la description du service. Une telle description guidée par le contexte et l’intention est essentielle dans le cadre d’un SIP transparent et centré utilisateur, celui-ci doit se caractériser par son adaptabilité au contexte et sa compréhension de l’utilisateur et de ses besoins. Cette description complète notre proposition de l’espace de services, puisqu’elle permet de décrire l’ensemble de services qu’il englobe. Ainsi, avec la description de l’ensemble des services disponibles dans cet espace, nous pouvons avoir une réelle visibilité et une description de celui-ci. De plus, ce descripteur intentionnel et contextuel sera exploité par les mécanismes de découverte (cf. Chapitre 7) et de prédiction (cf. Chapitre 8) de services puisqu’ils interagissent avec un répertoire de services décrit selon ce descripteur. Cependant, il convient de souligner que les mécanismes de découverte et de prédiction, que nous allons présenter dans le Chapitre 7 et le Chapitre 8 n’exploitent pas, pour autant, toute la description intentionnelle et contextuelle que nous avons présentée dans ce chapitre. Ces deux mécanismes vont interagir notamment avec le profil de service de OWL-SIC, la partie de la description de services qui indique ce que fait le service. Cette partie comprend une description de contexte et des intentions possibles de ce service. C’est elle qui va être traitée dans le processus de découverte et de prédiction de services. Ceci n’empêche pas que l’extension décrivant le processus intentionnel peut être exploitée par un mécanisme de composition de services lequel pourrait gérer la variabilité et la composition dans la satisfaction de l’intention de l’utilisateur, selon des contraintes contextuelles spécifiques. Cette partie est en dehors de la portée de notre travail de thèse et reste ici en tant que travaux futurs. Découverte!de!services!guidée!par!l’intention!et!le!contexte 148 Chapitre 7. DECOUVERTE DE SERVICES GUIDEE PAR L’ INTENTION ET LE CONTEXTE 7.1. INTRODUCTION Aujourd’hui, nous constatons que l’utilisateur interagit avec une panoplie de dispositifs et de services offerts par l’ensemble des SI qui nous entourent. Alors que de grands efforts ont été concentrés sur la recherche sémantique et sur l'adaptation au contexte, surtout à la localisation et aux dispositifs utilisés, nous constatons aujourd'hui les limitations de ces approches, notamment une certaine surcharge de l’utilisateur dû aux « faux-positifs ». Les utilisateurs se voient proposer plusieurs implémentations pour un même service, sans avoir pour autant le bagage nécessaire pour comprendre ces implémentations, ce qui nuit à la transparence d'utilisation de ces systèmes. La clé du succès serait donc d'offrir à l'utilisateur le service qui satisfait ses besoins, sans qu'il soit forcé de comprendre des détails sur l'implémentation ou sur les contraintes des dispositifs utilisés. Nous pensons que seulement une approche centrée sur l'utilisateur sera capable d'apporter des services adaptés au contexte d'utilisation tout en gardant un niveau de transparence convenable. C'est dans ce souci que nous proposons, dans le cadre de ce chapitre, un processus de découverte de services guidé non seulement par le contexte de l’utilisateur, mais également par son intention. Ce processus s’encadre donc dans une vision plus globale, celle avancée par la notion d’espace de services (cf. Chapitre 5), laquelle soutient une vision centrée utilisateur pour les SIP. Tel que nous l’avons défini à travers la notion d’espace de services, une intention représente les exigences formulées par l'utilisateur, qui sait ce qu'il attend d'un service mais qui ne sait pas indiquer comment y parvenir. Ces intentions émergent dans un contexte d’utilisation précis. Il s'agit d'un élément important dans le processus d'adaptation d’un système, processus que nous souhaitons enrichir par la notion d’intention. Nous pensons non seulement que la satisfaction des intentions de l'utilisateur dans un SIP dépend du contexte dans lequel se trouve cet utilisateur, mais aussi que le contexte impacte la manière dont les intentions sont satisfaites, tout comme le contexte impacte le choix des services qui seront exécutés. Cette relation peut être exploitée dans la découverte de services : grâce à l'observation de l'intention et du contexte d’utilisation, un processus de découverte plus précis peut être mis au point, offrant aux utilisateurs les services les plus adaptés à leurs besoins. Dans ce chapitre, nous présentons un processus de découverte de services à la fois contextuel et intentionnel. Ce processus se base sur un principe de mise en correspondance entre l’intention de l’utilisateur, formulée dans sa requête, et les intentions des services, d’une part, et entre le contexte courant de l’utilisateur et les conditions contextuelles associées aux services, d’autre part. Nous présentons, par la suite, une implémentation de ce mécanisme et Découverte!de!services!guidée!par!l’intention!et!le!contexte 149 analysons les résultats des expérimentations menées notamment par rapport au passage à l’échelle, à la précision et au rappel. Ces trois critères nous semblent particulièrement importants, puisqu'ils démontrent non seulement la faisabilité de l'approche, mais également son intérêt pour une découverte plus appropriée aux utilisateurs. 7.2. PROCESSUS DE DECOUVERTE DE SERVICES GUIDE PAR L’ INTENTION ET LE CONTEXTE 7.2.1.Principe Un utilisateur interagit avec un SIP à travers l’espace de services. Cette interaction reflète le désir de l’utilisateur d’avoir un SIP qui soit capable de satisfaire ses besoins (formulés en termes d’intentions) selon son contexte d’usage. Ceci consiste à lui offrir, en toute transparence, le service le plus adapté à son contexte courant et le plus approprié à ses intentions. Ainsi, découle le besoin de présenter un nouveau processus de découverte de services qui prend en considération le contexte et l’intention de l’utilisateur lors de cette phase de découverte du service le plus approprié. Par conséquence, nous proposons un processus de découverte de services guidée par l'intention et le contexte. Ce processus se base sur un algorithme de mise en correspondance (matching) des services. Cet algorithme va permettre de comparer sémantiquement, et en se basant sur un ensembles de mesures de similarité, l’intention et le contexte de l’utilisateur avec chaque service disponible dans le répertoire de services (cf. Chapitre 9). Dans ce cadre, le concept d'intention est utilisé pour exposer les services et mettre en œuvre une vision centrée utilisateur des SIP dans un contexte donné. Nous soutenons qu’une meilleure prise en compte de l'intention de l'utilisateur peut conduire à une meilleure compréhension de l'utilisation réelle des services, ce qui par conséquent peut améliorer la précision et le rappel des services choisis pour satisfaire les besoins des utilisateurs. Par ailleurs, les informations contextuelles jouent un rôle central dans ce processus de découverte de services car elles influencent le choix des meilleures stratégies de satisfaction de l'intention. Ce processus de découverte est proposé afin de masquer la complexité de la mise en œuvre des services dans un environnement hétérogène et dynamique, et par conséquent d'atteindre la transparence promise et l'efficacité souhaitée des Systèmes d'Information Pervasifs (Najar et al., 2012a) (Najar et al., 2012b). En d’autres termes, ce processus est proposé afin d’assurer un certain niveau de transparence et d’efficacité des systèmes, en s’adaptant au contexte (permettant ainsi une meilleure gestion de l’hétérogénéité) et en prenant en considération l’intention (permettant ainsi une meilleure compréhension de l’utilisateur et de l'utilisation réelle des services). Ceci permet, par conséquent, d’améliorer la sélection des services en réduisant les services « faux-positifs » offerts à l’utilisateur. Découverte!de!services!guidée!par!l’intention!et!le!contexte 150 Figure 49. Interaction avec le module de découverte de services dans le cadre de l’architecture de gestionnaire de SIP Dans l’architecture proposée dans le Chapitre 9, le processus de découverte de services, comme l’illustre la Figure 49, se déclenche lorsqu’il reçoit une demande de la part du module de gestion de requête. Plus précisément, lorsqu’un utilisateur envoie sa requête sous forme d’intention, cette requête est prise en compte par le module de gestion de requête. Ce dernier communique, ensuite, avec le module de gestion de contexte afin d’enrichir l’intention de l’utilisateur avec son contexte courant. Par la suite, il envoie cette requête enrichie au module de découverte de services. Dès lors, le module de découverte de services interagit avec le répertoire de services intentionnels et contextuels pour charger les services disponibles. Par la suite, il lance son mécanisme de découverte pour trouver le service qui répond au mieux à l’intention et au contexte de l’utilisateur. Le processus de découverte de services, en fonction de ces deux concepts de contexte et d’intention, aidera les utilisateurs à découvrir le service le plus approprié pour eux. Ce processus représente celui qui répond aux besoins immédiats de l'utilisateur dans un contexte donné. Il utilise la description de services sémantiques, que nous avons présentée dans le Chapitre 6, dans un algorithme de découverte de services guidé par l’intention et le contexte, qui sera présenté dans la suite de ce chapitre. Cet algorithme effectue une mise en correspondance sémantique afin de sélectionner le service le plus approprié à l'utilisateur. Le but de cet algorithme est de classer les services disponibles en fonction de leurs informations contextuelles et intentionnelles. Il sélectionne, ensuite, celui qui répond au mieux à l’intention immédiate de l’utilisateur dans son contexte courant. 7.2.2. Algorithme de découverte de services guidée par le contexte et l’intention Dans cette section, nous présentons l’algorithme de découverte de services selon une vision intentionnelle et contextuelle, comme l’illustre la Figure 50. Cet algorithme se compose d’une première phase de mise en correspondance intentionnelle (cf. section 7.2.2.3), qui permet de déterminer si l’intention du service correspond sémantiquement à l’intention de l’utilisateur, et d’une deuxième phase de mise en correspondance contextuelle (cf. section Découverte!de!services!guidée!par!l’intention!et!le!contexte 151 7.2.2.4), qui permet de déterminer si la description de contexte associée à un service correspond à la description de contexte courant de l’utilisateur. Le résultat final représente le service qui répond au mieux à l’intention et au contexte de l’utilisateur. Figure 50. Principe de la découverte de services selon une vision intentionnelle et contextuelle 7.2.2.1. Concepts préliminaires : les mesures de similarités et la mise en correspondance sémantique Une mesure de similarité représente une métrique qui calcule une distance entre deux éléments en se basant sur des fonctions plus ou moins adaptées au type des éléments utilisés. Parmi ces mesures de similarités, nous pouvons citer, par exemple : • La mesure de similarité euclidienne (d) représente une mesure qui calcule la distance entre deux vecteurs x et y de dimension n, comme l’illustre la Formule 1. ! (!, !) = !! − !! ! ! !!! Formule 1. Mesure de similarité euclidienne • La mesure de similarité cosinus (θ) représente une mesure qui permet de calculer, comme l’illustre la Formule 2, la similarité entre deux vecteurs A et B à n dimension en déterminant un angle θ entre eux. Cet angle s'obtient par le produit scalaire et la norme des vecteurs. ! (!, !) = !"##$% ! . ! ||!||. ||!|| Formule 2. Mesure de similarité cosinus • La mesure de similarité sémantique (ds) représente une mesure qui calcule la distance sémantique (normalisée) entre deux concepts en se basant sur leur lien sémantique dans une ontologie. Ce lien représente les relations de généralisation et de spécialisation entre les concepts. Cette distance est calculée selon la Formule 3, où l représente le nombre de liens qui séparent un concept a d’un concept b. Découverte!de!services!guidée!par!l’intention!et!le!contexte 152 !" (!, !) = 1 (! + 1) Formule 3. Mesure de similarité sémantique Un certain nombre de travaux de recherche utilisant ces mesures ont été menés dans la découverte des services sémantiques, tel que nous l'avons détaillé dans la section 3.5.2. La plupart de ces travaux, tels que (Paolucci et al., 2002) et (Klusch et al., 2009), se basent sur le principe de la mise en correspondance sémantique entre deux concepts. Ceci correspond à une comparaison entre deux concepts en se basant sur leur niveau hiérarchique dans une ontologie. Plus précisément, la mise en correspondance sémantique se base sur la mesure de la similarité sémantique afin de calculer la distance sémantique qui sépare ces deux concepts. Cette mise en correspondance permet ainsi de déterminer la relation de subsomption entre deux concepts dans une ontologie. Cette relation de subsomption permet de lier des concepts spécifiques à des concepts plus génériques dans une ontologie. Dans l’algorithme de mise en correspondance de services, que nous proposons dans la section suivante, nous appliquons différents types de mesures de similarité : (i) des mesures de similarité sémantique entre les intentions (entre les cibles décrites dans l’ontologie des cibles (cf. section 7.2.2.3.1) et entre les verbes dans l’ontologie des verbes (cf. section 7.2.2.3.2)) ; (ii) des mesures de similarité sémantique entre les contextes (entre les entités, les éléments et les représentation de contexte dans l’ontologie multi-niveaux de contexte (cf. section 7.2.2.4.1)) ; et (iii) d’autres types de mesures de similarité appliqués essentiellement sur les valeurs des éléments de contexte observés (cf. section 7.2.2.4.1). 7.2.2.2. L’algorithme de mise en correspondance de services guidée par le contexte et l’intention D’une manière générale, l’algorithme de mise en correspondance que nous proposons se décompose en quatre étapes, comme indiqué schématiquement dans la Figure 51. Pour chaque service disponible, l'intention de l'utilisateur est d’abord comparée à l'intention principale associée à ce service (étape 1.1). Ensuite, le contexte courant de l’utilisateur est comparé, sémantiquement et en se basant sur des mesures de similarités, aux conditions de contexte associées au service (CxR) (étape 1.2). Finalement, le score du degré de mise en correspondance final entre la requête de l'utilisateur (représentant son intention enrichie par son contexte courant) et chacun des services disponibles dans le répertoire de services est calculé (étape 1.3). Ce score va définir le classement de chaque service répondant à l’intention et au contexte de l’utilisateur. À partir de ce classement, le service qui obtient le score le plus élevé est proposé à l'utilisateur. Découverte!de!services!guidée!par!l’intention!et!le!contexte 153 Figure 51. Aperçu du processus de découverte de service guidée par le contexte et l'intention Plus en détails, nous présentons, dans la Figure 52, notre algorithme de mise en correspondance de services. Cet algorithme prend en entrée une intention présentant le besoin de l’utilisateur (Iu), une description du contexte courant de l’utilisateur (Cxu) et un ensemble de services disponibles (Sv) dans le répertoire de services intentionnels et contextuels, décrit en OWL-SIC (cf. Chapitre 6). De plus, il prend en entrée un ensemble d’ontologies, à savoir une ontologie de cibles (OntoT), une ontologie de verbes (OntoV) (cf. section 6.3.1.3) et une ontologie multi-niveaux de contexte (OntoCX) (cf. section 6.4.1). L’algorithme de mise en correspondance produit à la sortie, une liste qui contient les couples . Le service svi représente le service candidat qui peut répondre à l’intention de l’utilisateur dans son contexte. Le degré de similarité Sscore représente le degré de similarité entre l’intention et le contexte du service svi et de l’utilisateur U. Procedure Service Discovery (Cx u, I u, Sv, OntoT, OntoV, OntoCX ) (1) Sranked = Ø /* Liste des services classés avec leur score de mise en correspondance */ (2) Iscore = 0 /* Degré de similarité entre Iu et l’intention du service (Isvi) */ (3) Cscore = 0 /* Degré de similarité entre Cxu et le contexte du service (Cxsvi) */ (4) Sscore = 0 /* Score final de la mise en correspondance entre (Iu, Cxu) et (Isvi, Cxsvi) */ (5) For each svi ∈ Sv Do (6) Cxsvi = GetContext (svi) (7) Isvi = GetIntention (svi) (8) Iscore = IntentionMatching (Iu, Isvi, OntoT, OntoV) /* Mise en correspondance intentionnelle */ (9) If Iscore > α Then (10) Cscore = ContextMatching (Cxu, Cxsvi, OntoCX) /* Mise en correspondance contextuelle */Découverte!de!services!guidée!par!l’intention!et!le!contexte 154 (11) If Cscore > β Then (12) Sscore = (Iscore + Cscore)/2 (13) Sranked = Sranked ∪ {} (14) End If (15) End If (16) End For (17) svselected = GetBestService (Sranked) /* Retourne le service ayant le score le plus élevé */ (18) Return svselected (19) End Procedure Figure 52. Algorithme de découverte de services basée sur l’intention et le contexte Dans cet algorithme, nous précisons deux paramètres α et β qui prennent leurs valeurs dans l’intervalle [0,1]. Le paramètre α représente le seuil au-delà duquel l’algorithme procède à la mise en correspondance contextuelle. Si le degré de similarité des intentions est supérieur ou égal au seuil α, alors l’algorithme lance la mise en correspondance entre les contextes. Le paramètre β représente le seuil au-delà duquel l’algorithme procède au calcul du score global de la mise en correspondance et de l’ajout du service parmi la liste des services candidats. Si le degré de similarité des descriptions de contexte est supérieur ou égal au seuil β, alors l’algorithme considère ce service comme service candidat potentiel répondant au contexte de l’utilisateur. Le paramètre α permet de configurer de manière indirecte la distance d’expression de l’intention de l’utilisateur avec celle associée à un service. Le seuil β, quant à lui, permet de paramétrer la distance d’expression du contexte de l’utilisateur avec le contexte requis du service. La configuration d’un seuil α très élevé, proche de un, implique inévitablement que l’utilisateur connaît exactement la formulation des intentions associées aux services et l’utilisateur ne peut pas être dans un mode exploratoire ou dynamique. Par contre, la configuration d’un seuil α très bas, permet un meilleur mode exploratoire mais peut conduire à la sélection de services qui n’intéressent pas l’utilisateur. Ainsi, il est important de bien définir le seuil de paramétrage α en fonction de l’usage qu’on souhaite faire du système. Un seuil β très élevé correspond à un couplage fort entre la description contextuelle des services et celle du contexte courant de l’utilisateur. Ce couplage fort entraîne un coût de maintenance élevé lorsque le modèle de contexte évolue ou freine la réutilisation potentielle des services en fonction d’un contexte. Par contre, un seuil β très bas peut engendrer la sélection d’un service inapproprié au contexte. C’est pour cette raison qu’il faut bien spécifier le seuil de paramétrage β en fonction de la complexité de la description du modèle de contexte et de son niveau de généralisation/spécialisation. Ces deux paramètres α et β sont définis au préalable par le concepteur du système de manière empirique en fonction des scénarios. Ainsi, le concepteur est amené à tester l’algorithme avec son propre jeux de tests en utilisant son répertoire de services et ses ontologies. A chaque fois, il doit modifier les seuils et évaluer les résultats obtenus. Ceci va Découverte!de!services!guidée!par!l’intention!et!le!contexte 155 lui permettre de trouver le seuil le plus approprié sélectionnant les résultats les plus pertinents. Ainsi, l’avantage d’un tel seuil de paramétrage est son adaptation au cas par cas. Toutefois, cette évaluation empirique demande un effort supplémentaire du concepteur. L’algorithme de mise en correspondance, comme l’illustre la Figure 52, commence par sélectionner un service (svi) parmi les services disponibles dans le répertoire (ligne 5). Ensuite, le contexte (Cxsvi) et l’intention (Isvi) du service (svi) sont récupérés (ligne 6-7). Après avoir récupéré toutes ces informations, l’intention (Isvi) est mise en correspondance sémantiquement avec l’intention de l’utilisateur (Iu). Le degré de similarité résultant est par la suite stocké dans la variable Iscore (ligne 8). Le score Iscore est par la suite comparé au seuil  (ligne 9). Si le score est inférieur au seuil alors l’algorithme ne traite pas la mise en correspondance contextuelle et passe directement au service suivant. Ceci est parce que le service en cours de traitement n’est pas capable de satisfaire l’intention de l’utilisateur. Ainsi, même si ce service peut correspondre au contexte courant de l’utilisateur, il ne sera pas sélectionné puisqu’il ne répond pas au besoin de l’utilisateur. Ce choix va nous permettre de gagner en performance en évitant un traitement (mise en correspondance contextuelle) inutile. Par contre, si le degré de similarité Iscore est supérieur ou égal au seuil  alors le contexte de l’utilisateur (Cxu) est évalué par rapport au contexte requis du service (CxRsvi). Le degré de similarité résultant est par la suite stocké dans la variable Cscore (ligne 10). Le score Cscore est ensuite comparé au seuil (ligne 11). Si le score est inférieur au seuil alors l’algorithme ne sélectionne pas le service comme service candidat et passe directement au service suivant. Dans le cas contraire, le degré de similarité final (Sscore) est, par la suite calculé selon la formule suivante Sscore = (Iscore + Cscore) / 2 (ligne 12). Par la suite, le service et son degré de similarité sont enregistrés dans la liste des services candidats (Sranked) (ligne 13). Finalement, si un autre service est toujours disponible, alors l’algorithme relance la même démarche décrite ci-dessus. Sinon, l’algorithme sélectionne le service (svselected) ayant le score le plus élevé (ligne 17) et le retourne comme résultat final (ligne 18). Les sections suivantes détaillent chacune des étapes de l’algorithme de mise en correspondance de services guidé par l’intention et le contexte. 7.2.2.3. La mise en correspondance intentionnelle des services La correspondance intentionnelle (Intention Matching) représente la première étape de l’algorithme de mise en correspondance guidée par l’intention et le contexte. Celle-ci consiste à comparer sémantiquement l’intention de l’utilisateur (IU), qui représente son besoin lors de sa demande d’un service, et l’intention principale (Isvi) qu’un service peut satisfaire. Dans le cadre de ce processus de découverte de services, nous formulons l’intention selon le modèle de Prat (Prat, 1997). Nous avons choisi de représenter l’intention sous forme de verbe et de cible puisqu’ils représentent les éléments de base d’une intention et qui sont obligatoires lors de sa représentation. Nous estimons que la prise en compte des paramètres dans cette étape peut nuire à la qualité des résultats obtenus. Par exemple, Frioui (Frioui, https://hal.archives-ouvertes.fr/tel-00989775/document Analyse de d´ependances ML pour les ´evaluateurs de logiciels critiques. Vincent Benayoun To cite this version: Vincent Benayoun. Analyse de d´ependances ML pour les ´evaluateurs de logiciels critiques.. Software Engineering. Conservatoire national des arts et metiers - CNAM, 2014. French. . HAL Id: tel-01062785 https://tel.archives-ouvertes.fr/tel-01062785 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écommunication et Électronique CEDRIC - Centre d’Étude et De Recherche en Informatique et Communications THÈSE DE DOCTORAT présentée par : Vincent BENAYOUN soutenue le : 16 MAI 2014 pour obtenir le grade de : Docteur du Conservatoire National des Arts et Métiers Discipline / Spécialité : Informatique / Preuve formelle Analyse de dépendances ML pour les évaluateurs de logiciels critiques THÈSE dirigée par Mme. DUBOIS Catherine Professeur, ENSIIE - CEDRIC M. PESSAUX François Maître de conférences, ENSTA ParisTech RAPPORTEURS M. DI COSMO Roberto Professeur, Université Paris Diderot Mme. BLAZY Sandrine Professeur, Université de Rennes 1 EXAMINATEURS M. RAJCHENBACH-TELLER David Ingénieur R&D, Mozilla M. POTET Marie-Laure (Présidente) Professeur, Ensimag - VERIMAG2Remerciements Je tiens tout d’abord à remercier vivement Catherine Dubois, qui m’a guidé tout au long de mon parcours depuis mon passage à l’école d’ingénieur jusqu’à aujourd’hui. Elle m’a fait découvrir OCaml sous un nouveau jour et m’a ainsi permis d’apprécier à leur juste valeur les bienfaits du typage fort. Elle m’a ensuite donné le goût des méthodes formelles et m’a introduit dans l’équipe CPR du CNAM où j’ai découvert le monde de la recherche en réalisant ma première véritable modélisation formelle sous la direction de Maria-Virginia Aponte et de Marianne Simonot, que je remercie également pour cette expérience très inté- ressante. Catherine a ensuite pris la direction de ma thèse lors mon entrée à MLstate jusqu’à la rédaction de ce manuscrit. Elle a su gérer les nombreuses péripéties de mon parcours de thèse et m’accompagner jusqu’au bout en me prodiguant de nombreux conseils précieux. Je remercie Roberto Di Cosmo et Sandrine Blazy d’avoir accepté le rôle de rapporteurs de cette thèse et d’avoir fourni les efforts nécessaires à compréhension fine de mon travail. Merci pour leurs remarques judicieuses et leurs questions pertinentes. Je remercie également Marie-Laure Potet pour son implication dans mon jury de thèse en tant que présidente. Mon parcours de thèse à commencé à MLstate. Je remercie donc Henri Binsztok de m’avoir proposé de rejoindre MLstate en thèse CIFRE. J’ai eu l’occasion d’y travailler avec une équipe géniale. Je souhaite tout particulièrement remercier mes encadrants Catherine, David Teller, Pierre Courtieu et Adam Koprowski qui m’ont beaucoup apporté. David m’a guidé au quotidien dans toutes mes activités à MLstate, il s’est battu sans cesse pour la réussite de ma thèse, comme il l’a fait pour tout le projet OPA en géné- ral. C’est un homme qui a les épaules pour être partout à la fois et s’occuper de chaque chose avec intelligence et efficacité. Pierre et Adam m’ont appris à maîtriser Coq, ce qui m’a beaucoup aidé pour réaliser les preuves que je présente dans ce manuscrit. Je remercie également tous les membres de l’équipe avec qui j’ai travaillé à MLstate, en particulier Mikołaj Konarski avec qui j’ai eu grand plaisir à travailler et pour qui j’ai un grand respect. Catherine m’a donné toute sa confiance et ses encouragements en me permettant de continuer mon parcours de thèse après mon départ de MLstate. Elle m’a proposé avec le concours de Thérèse Hardin un nouveau sujet de thèse que je présente aujourd’hui dans ce manuscrit. Je tiens à remercier sincèrement Thérèse qui a suivi mon parcours d’un œil bienveillant et m’a donné des conseils judicieux aux moments opportuns. Sur son conseil, je me suis dirigé vers MLstate et sur son conseil, j’ai pris la suite de la thèse de Philippe Ayrault. Je remercie d’ailleurs Philippe pour le temps qu’il m’a consacré afin de m’expliquer les dé- tails de son analyse de dépendances ainsi que les besoins spécifiques, en tant qu’évaluateur de logiciels critiques, qui l’ont amené à faire certains choix. Je remercie François Pessaux d’avoir assuré l’encadrement de ma thèse aux côtés de Catherine. Il a su me transmettre son expérience et sa rigueur intellectuelle. En particulier il m’a permis de mieux comprendre les besoins des évaluateurs de logiciels critiques en partageant son expérience dans le domaine. Ces remerciements ne pourraient être complets sans remercier mes parents et mon frère qui m’ont toujours apporté leur soutien et leurs encouragements ainsi que ma chère femme qui me soutient par son amour et ses délicates attentions et nos deux petites princesses, qui par leurs jolies voix m’ont aidé à ne pas somnoler devant l’ordinateur pendant les nombreuses nuits passées en compagnie de Coq et de Latex.REMERCIEMENTS 4Résumé Les logiciels critiques nécessitent l’obtention d’une évaluation de conformité aux normes en vigueur avant leur mise en service. Cette évaluation est obtenue après un long travail d’analyse effectué par les évaluateurs de logiciels critiques. Ces derniers peuvent être aidés par des outils utilisés de manière interactive pour construire des modèles, en faisant appel à des analyses de flots d’information. Des outils comme SPARK-Ada existent pour des sousensembles du langage Ada utilisés pour le développement de logiciels critiques. Cependant, des langages émergents comme ceux de la famille ML ne disposent pas de tels outils adaptés. La construction d’outils similaires pour les langages ML demande une attention particulière sur certaines spécificités comme les fonctions d’ordre supérieur ou le filtrage par motifs. Ce travail présente une analyse de flot d’information pour de tels langages, spécialement conçue pour répondre aux besoins des évaluateurs. Cette analyse statique prend la forme d’une interprétation abstraite de la sémantique opérationnelle préalablement enrichie par des informations de dépendances. Elle est prouvée correcte vis-à-vis d’une définition formelle de la notion de dépendance, à l’aide de l’assistant à la preuve Coq. Ce travail constitue une base théorique solide utilisable pour construire un outil efficace pour l’analyse de tolérance aux pannes. Mots clés : analyse de dépendances, logiciels critiques, langages fonctionnels, Coq, preuve de correction, analyse statique, interprétation abstraite 5Abstract Critical software needs to obtain an assessment before commissioning in order to ensure compliance with standards. This assessment is given after a long task of software analysis performed by assessors. They may be helped by tools, used interactively, to build models using information-flow analyses. Tools like SPARK-Ada exist for Ada subsets used for critical software. But some emergent languages such as those of the ML family lack such adapted tools. Providing similar tools for ML languages requires special attention on specific features such as higher-order functions and pattern-matching. This work presents an information-flow analysis for such a language specifically designed according to the needs of assessors. This analysis is built as an abstract interpretation of the operational semantics enriched with dependency information. It is proved correct according to a formal definition of the notion of dependency using the Coq proof assistant. This work gives a strong theoretical basis for building an efficient tool for fault tolerance analysis. Keywords : dependency analysis, critical software, functional languages, Coq, proof of correctness, static analysis, abstract interpretation 7Table des matières Introduction 19 Évaluation des logiciels critiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Outils automatiques, interactifs et corrects . . . . . . . . . . . . . . . . . . . . . . 20 Pourquoi une analyse de dépendances pour ML ? . . . . . . . . . . . . . . . . . . 21 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1 État de l’art 27 1.1 Analyse de dépendances pour les logiciels critiques . . . . . . . . . . . . . . 27 1.1.1 Les langages ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.1.2 SPARK/Ada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1.2 Analyse de flot pour les langages fonctionnels . . . . . . . . . . . . . . . . . 32 1.3 Analyse de teintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1.4 Interprétation abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2 Notion de dépendance 41 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.2 Le langage : algèbre des expressions . . . . . . . . . . . . . . . . . . . . . . . 43 2.3 Sémantique opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3.1 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9TABLE DES MATIÈRES 2.3.2 Environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.3.3 Règles d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.3.4 Sémantique des programmes mal typés et filtrage par motif . . . . . 45 2.4 Points d’injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.4.1 Dans le programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.4.2 Dans l’environnement . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.5 Sémantique opérationnelle avec injection . . . . . . . . . . . . . . . . . . . . 49 2.5.1 Règles d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.5.2 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.5.2.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . 51 2.5.2.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . 51 2.5.2.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . 54 2.5.2.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . 54 2.6 Impact d’une injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.6.1 Impact sur la terminaison . . . . . . . . . . . . . . . . . . . . . . . . 57 2.6.2 Impact sur la valeur . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.7 Dépendances d’une expression . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.7.1 Dépendances de terminaison . . . . . . . . . . . . . . . . . . . . . . . 58 2.7.2 Dépendances de valeur . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.7.3 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . . . . . . 58 3 Analyse dynamique 61 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.2 Sur-instrumentation des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.2.1 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.2.2 Ensembles de dépendances . . . . . . . . . . . . . . . . . . . . . . . . 65 10TABLE DES MATIÈRES 3.2.3 Environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.2.4 Valeur de référence d’une valeur sur-instrumentée . . . . . . . . . . . 66 3.2.5 Instanciation d’une valeur sur-instrumentée . . . . . . . . . . . . . . 67 3.2.6 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.3 Sémantique avec injection dans un t-environnement sur-instrumenté . . . . . 70 3.3.1 Règles d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 3.3.2 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.3.2.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . 72 3.3.2.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . 74 3.3.2.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . 76 3.3.2.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . 76 3.4 Sémantique sur-instrumentée . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.4.1 Règles d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.4.1.1 Explication des règles avec dépendances indirectes . . . . . 85 3.4.1.2 Spécification des dépendances indirectes . . . . . . . . . . . 93 3.4.2 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.4.2.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . 102 3.4.2.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . 103 3.4.2.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . 113 3.4.2.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . 113 3.5 Sémantique instrumentée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 3.5.1 Algèbre des valeurs instrumentées . . . . . . . . . . . . . . . . . . . . 121 3.5.1.1 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 3.5.1.2 Ensembles de dépendances . . . . . . . . . . . . . . . . . . 121 3.5.1.3 Environnements . . . . . . . . . . . . . . . . . . . . . . . . 122 11TABLE DES MATIÈRES 3.5.2 Règles d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 3.5.3 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 3.5.3.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . 127 3.5.3.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . 127 3.5.3.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . 131 3.5.3.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . 134 3.6 Correction de l’analyse dynamique . . . . . . . . . . . . . . . . . . . . . . . 138 3.6.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . . . . . . 138 3.6.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . . . . . . 138 3.6.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . . . . . . 140 3.6.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 4 Analyse statique 145 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 4.2 Sémantique instrumentée multiple . . . . . . . . . . . . . . . . . . . . . . . 147 4.2.1 Présentation informelle . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.2.2 Définition formelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.3 Sémantique collectrice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 4.3.1 Algèbre des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 4.3.1.1 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 4.3.1.2 Ensembles de dépendances . . . . . . . . . . . . . . . . . . 150 4.3.1.3 Environnements . . . . . . . . . . . . . . . . . . . . . . . . 150 4.3.2 Règles d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 4.3.3 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 4.3.3.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . 157 4.3.3.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . 158 12TABLE DES MATIÈRES 4.3.3.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . 159 4.3.3.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . 162 4.4 Sémantique abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 4.4.1 Algèbre des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 4.4.1.1 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 4.4.1.2 Ensembles de dépendances . . . . . . . . . . . . . . . . . . 173 4.4.1.3 Environnements . . . . . . . . . . . . . . . . . . . . . . . . 176 4.4.2 Règles d’inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 4.4.3 Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 4.4.3.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . 182 4.4.3.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . 182 4.4.3.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . 183 4.4.3.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . 184 4.5 Correction de l’analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . 192 4.5.1 Énoncé informel du théorème . . . . . . . . . . . . . . . . . . . . . . 192 4.5.2 Illustration par l’exemple . . . . . . . . . . . . . . . . . . . . . . . . 193 4.5.3 Énoncé formel du théorème . . . . . . . . . . . . . . . . . . . . . . . 194 4.5.4 Preuve de correction . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 5 Implémentation et preuve 197 5.1 Prototypes implémentés en OCaml . . . . . . . . . . . . . . . . . . . . . . . 197 5.2 Développement Coq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.2.1 Contenu du développement . . . . . . . . . . . . . . . . . . . . . . . 198 5.2.2 Intérêt du choix de Coq . . . . . . . . . . . . . . . . . . . . . . . . . 199 5.3 Extraction de Coq vers OCaml . . . . . . . . . . . . . . . . . . . . . . . . . 200 13TABLE DES MATIÈRES Conclusion 203 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Bibliographie 205 Annexes 213 A Définitions des sémantiques en Coq 213 A.1 Sémantique opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 A.2 Sémantique avec injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 A.3 Sémantique sur-instrumentée . . . . . . . . . . . . . . . . . . . . . . . . . . 217 A.4 Sémantique instrumentée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 A.5 Sémantique instrumentée multiple . . . . . . . . . . . . . . . . . . . . . . . 221 A.6 Sémantique collectrice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 A.7 Sémantique abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 B Énoncés des théorèmes en Coq 229 B.1 Correction de la sémantique avec injection . . . . . . . . . . . . . . . . . . . 229 B.2 Correction de la sémantique sur-instrumentée . . . . . . . . . . . . . . . . . 230 B.3 Correction de la sémantique instrumentée . . . . . . . . . . . . . . . . . . . 230 B.4 Correction de la sémantique collectrice . . . . . . . . . . . . . . . . . . . . . 231 B.5 Correction de la sémantique abstraite . . . . . . . . . . . . . . . . . . . . . . 231 Index 233 14Table des figures 2.1 Algèbre des expressions du langage . . . . . . . . . . . . . . . . . . . . . . . 43 2.2 Règles d’inférence de la sémantique opérationnelle . . . . . . . . . . . . . . 46 2.3 Règles d’inférence du filtrage de la sémantique opérationnelle . . . . . . . . 46 2.4 Sémantique opérationnelle avec injection : règles d’inférence identiques à la sémantique usuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.5 Sémantique opérationnelle avec injection : règles d’inférence spécifiques . . . 50 2.6 Prédicat de non-apparition d’un label lors d’une évaluation . . . . . . . . . 55 2.7 Prédicat de non-apparition d’un label dans une valeur . . . . . . . . . . . . 55 3.1 Sémantiques intermédiaires pour l’analyse dynamique . . . . . . . . . . . . . 62 3.2 Enchaînement des preuves des sémantiques intermédiaires pour l’analyse dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.3 Sémantique avec injection dans un t-environnement sur-instrumenté : règles d’inférence identiques à la sémantique usuelle . . . . . . . . . . . . . . . . . 73 3.4 Sémantique avec injection dans un t-environnement sur-instrumenté : règles d’inférence spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.5 Sémantique sur-instrumentée . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.6 Sémantique sur-instrumentée : règles de filtrage . . . . . . . . . . . . . . . . 81 3.7 Valeurs sur-instrumentées : suppression des t-dépendances . . . . . . . . . . 81 3.8 Valeurs sur-instrumentées : ajout de t-dépendances . . . . . . . . . . . . . . 82 15TABLE DES FIGURES 3.9 Exemple 1 : arbre de dérivation du jugement d’évaluation sur-instrumentée 105 3.10 Exemple 1 : arbre de dérivation du jugement d’évaluation avec injection si l = l ′ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.11 Exemple 1 : arbre de dérivation du jugement d’évaluation avec injection si l ̸= l ′ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.12 Exemple 2 : arbre de dérivation du jugement d’évaluation sur-instrumentée 109 3.13 Exemple 2 : sous-arbre de dérivation sur-instrumentée du filtrage . . . . . . 109 3.14 Exemple 2 : arbre de dérivation du jugement d’évaluation avec injection sur l1110 3.15 Exemple 2 : sous-arbre de dérivation du filtrage avec injection sur l1 . . . . 110 3.16 Exemple 2 : arbre de dérivation du jugement d’évaluation avec injection sur l2111 3.17 Exemple 2 : sous-arbre de dérivation du filtrage avec injection sur l2 . . . . 111 3.18 Exemple 2 : arbre de dérivation du jugement d’évaluation avec injection sur l ̸∈ {l1, l2} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.19 Exemple 2 : sous-arbre de dérivation du filtrage avec injection sur l ̸∈ {l1, l2} 112 3.20 Sémantique instrumentée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 3.21 Sémantique instrumentée : règles de filtrage . . . . . . . . . . . . . . . . . . 123 3.22 Valeurs instrumentées : suppression des t-dépendances . . . . . . . . . . . . 124 3.23 Valeurs instrumentées : ajout de t-dépendances . . . . . . . . . . . . . . . . 125 3.24 Exemple 1 : arbre de dérivation du jugement d’évaluation instrumentée . . . 128 3.25 Exemple 2 : arbre de dérivation du jugement d’évaluation instrumentée . . . 130 3.26 Exemple 2 : sous-arbre de dérivation instrumentée du filtrage . . . . . . . . 130 3.27 Prédicat de non-apparition d’un label lors d’une évaluation instrumentée . . 140 3.28 Prédicat de non-apparition d’un label dans une valeur instrumentée . . . . . 141 3.29 Prédicat de non-apparition d’un label dans un environnement instrumenté . 141 4.1 Sémantiques intermédiaires pour l’analyse statique . . . . . . . . . . . . . . 146 16TABLE DES FIGURES 4.2 Enchaînement des preuves des sémantiques intermédiaires pour l’analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.3 Sémantique collectrice : première partie . . . . . . . . . . . . . . . . . . . . 151 4.4 Sémantique collectrice : seconde partie . . . . . . . . . . . . . . . . . . . . . 152 4.5 Sémantique collectrice : règles de filtrage . . . . . . . . . . . . . . . . . . . . 152 4.6 Sémantique collectrice : prédicat d’application instrumentée multiple . . . . 154 4.7 Sémantique collectrice : Définition de la fonction d’abstraction . . . . . . . . 160 4.8 Sémantique collectrice : Définition de la fonction de concrétisation . . . . . 161 4.9 Relation d’ordre sur les valeurs et environnements instrumentés . . . . . . . 161 4.10 Relation d’ordre sur les valeurs et environnements instrumentés multiples . 161 4.11 Sémantique abstraite : Définition de la fonction d’abstraction (partie 1/2) . 174 4.12 Sémantique abstraite : Définition de la fonction d’abstraction (partie 2/2) . 175 4.13 Sémantique abstraite : Définition de la fonction de concrétisation . . . . . . 175 4.14 Sémantique abstraite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 4.15 Sémantique abstraite : v-dépendances des identificateurs libres d’une expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 4.16 Sémantique abstraite : règles de filtrage . . . . . . . . . . . . . . . . . . . . 178 4.17 Valeurs abstraites : suppression des t-dépendances . . . . . . . . . . . . . . 179 4.18 Valeurs abstraites : ajout de t-dépendances . . . . . . . . . . . . . . . . . . 180 4.19 Relation d’ordre sur les valeurs collectrices . . . . . . . . . . . . . . . . . . . 184 4.20 Prédicat de non-apparition d’un label lors d’une évaluation abstraite . . . . 195 4.21 Prédicat de non-apparition d’un label dans une valeur abstraite . . . . . . . 195 4.22 Prédicat de non-apparition d’un label dans un environnement abstrait . . . 195 17TABLE DES FIGURES 18Introduction Depuis son apparition jusqu’à aujourd’hui, l’informatique s’est développée à une vitesse phénoménale. Les systèmes informatiques sont devenus de plus en plus complexes et « l’intelligence » de ces systèmes a progressivement migré du matériel vers le logiciel. Les logiciels sont maintenant présents partout et s’occupent de tâches de plus en plus importantes et complexes. On les retrouve aussi bien dans nos téléphones portables que dans nos voitures. Ils nous permettent de nous divertir, de communiquer mais aussi de piloter des avions ou de gérer des systèmes bancaires. Compte tenu des conséquences dramatiques que peut engendrer une défaillance dans certains logiciels, une rigueur particulière doit être exigée pour la conception et le développement de ces logiciels dits « critiques ». Les logiciels critiques sont présents dans divers domaines dont le nucléaire, le transport (aéronautique, ferroviaire et automobile), le médical, le bancaire et l’armement. Certains dysfonctionnements peuvent causer des pertes financières de l’ordre de plusieurs centaines de millions d’euros, comme le montrent les exemples récents de dysfonctionnements [Kni12] dans des logiciels automatiques de spéculation boursière. D’autres peuvent mettre en jeu des vies humaines, comme on a pu en être témoin lors des accidents de voiture provoqués par des dysfonctionnements du régulateur de vitesse du véhicule. Les conséquences d’un dysfonctionnement dans le logiciel de pilotage d’un train, d’un avion ou d’une fusée peuvent se révéler dramatiques. La destruction de la fusée Arianne V lors de son vol inaugural en 1996 est un exemple bien connu de catastrophe provoquée par un dysfonctionnement logiciel. Le domaine médical n’est pas non plus épargné. La machine de radiothérapie Therac-25 a provoqué le décès de plusieurs patients à cause d’un dysfonctionnement logiciel passé inaperçu pendant plusieurs années. 19INTRODUCTION Évaluation des logiciels critiques La prise de conscience de l’importance d’un haut niveau de sûreté de fonctionnement des logiciels critiques a conduit les autorités à établir différentes normes selon les différents domaines d’application (EN-50128 [Sta99] pour le ferroviaire, DO-178B/C [RTC92] pour l’avionique, . . . ). Ces normes spécifient les exigences que doivent respecter les logiciels critiques de la conception à la mise en fonctionnement voire au démantèlement, en fonction de leur niveau de criticité. La vérification de la conformité d’un logiciel aux normes en vigueur nécessite de faire appel à un évaluateur indépendant engageant personnellement sa responsabilité pénale. Celui-ci va alors produire une démonstration du respect des normes par le système critique évalué. Cette démonstration est constituée d’un ensemble de documents ayant pour but de justifier un certain niveau de confiance. La justification est basée sur l’utilisation de méthodes de développement rigoureuses, de tests unitaires et d’intégration (avec un taux de couverture raisonnable) voire de preuves mathématiques dans les cas les plus critiques. La démonstration produite sera alors soumise à l’approbation d’une autorité de tutelle qui délivre alors l’autorisation de mise en exploitation. Outils automatiques, interactifs et corrects La tâche d’évaluation d’un logiciel critique est particulièrement coûteuse en temps et en main d’œuvre. On estime [Ayr11] le coût du développement d’un logiciel critique entre 6 et 10 hommes-années pour mille lignes de code dont environ 60% sont attribuables aux phases de vérification, validation et évaluation. Des outils automatiques permettant de simplifier une partie de ce travail de vérification peuvent donc être fortement appréciés, moyennant le respect de certaines contraintes dues à leur utilisation. Ces outils automatiques doivent être utilisés uniquement comme une aide pour l’évaluateur. L’interactivité est primordiale dans ce type d’outil pour que l’évaluateur puisse utiliser son expertise pour guider l’outil et obtenir ainsi les résultats dont il a besoin. La question de la correction des outils utilisés par l’évaluateur de logiciels critiques est une question essentielle. Pour que l’évaluateur puisse faire confiance à l’outil et utiliser les résultats fournis par celui-ci pour prendre des décisions, il faut que cet outil bénéficie d’un 20INTRODUCTION haut niveau de fiabilité. Par exemple une preuve formelle de la correction de l’outil peut être un gage de fiabilité acceptable par l’évaluateur. Pourquoi une analyse de dépendances pour ML ? Divers outils peuvent permettre d’alléger le travail d’évaluation d’un logiciel critique. Parmi ces outils, l’analyse des dépendances dans le code source du logiciel a une importance particulière. En effet, ce type d’analyse peut permettre à l’évaluateur d’identifier les parties du programme qui n’ont aucune influence sur la partie critique du système évalué. L’évaluateur peut alors se reposer sur la fiabilité de l’outil d’analyse pour s’épargner un long travail de vérification sur les parties du programme pour lesquelles il a une garantie qu’elles ne peuvent en aucune manière influencer les fonctionnalités critiques du système : elles ne font alors pas partie de la « cible d’analyse » (Target of Analysis). D’autre part, l’analyse des dépendances du code source peut permettre à l’évaluateur de visualiser les interactions entre les différentes parties du logiciel. Il acquiert ainsi une meilleure compréhension du logiciel et de sa structure. En particulier, ces informations se révèlent être précieuses pour construire la « modélisation fonctionnelle du système » qui constitue une des étapes de l’AMDEC [X6086, MSA80], méthode d’analyse utilisée fréquemment par les évaluateurs de systèmes critiques. Les analyses de dépendances, comme les analyses de flots d’information, les analyses de non-interférence, ou encore les analyses d’impact, sont des analyses opérant sur le code source des logiciels. Elles sont dépendantes du langage de programmation utilisé pour dé- velopper le logiciel à évaluer. Certains langages de programmation sont mieux outillés que d’autres. Des outils d’analyse de dépendances existent pour le langage C, particulièrement répandu. On peut citer par exemple le plug-in d’analyse d’impact de l’environnement d’analyse de code source Frama-C [CKK+12]. Même si cet outil n’est pas conçu spécifiquement pour répondre aux besoins des évaluateurs de logiciels critiques, il peut être utilisé dans une certaine mesure pour aider à la construction d’une modélisation fonctionnelle. Le langage SPARK [Bar03], sous-ensemble du langage ADA, est lui aussi équipé d’un outil permettant de spécifier les dépendances d’un programme et de les vérifier. 21INTRODUCTION D’autres langages, quant à eux, ne bénéficient pas d’un tel outillage. C’est le cas notamment des langages fonctionnels de la famille ML qui voient leur utilisation commencer à se répandre dans le cadre du développement de logiciels critiques. Certains développements industriels utilisent d’ores et déjà des langages de la famille ML. La société Jane Street Capital développe des logiciels critiques d’investissements financiers en OCaml ([MW08]) manipulant des centaines de millions de dollars chaque jour. Le générateur de code embarqué certifié SCADE [PAC+08] est lui aussi écrit en OCaml. De nombreux autres logiciels critiques sont développés en utilisant les langages de la famille ML comme l’analyse statique Goanna [FHJ+06] permettant de rechercher des erreurs dans du code source critique écrit en C/C++, ou encore la plate-forme logicielle Apropos [JES00] développée par LexiFi pour la tarification et la gestion de produits financiers. Contribution Dans cette thèse, nous nous intéressons à l’analyse des dépendances d’un logiciel. Le langage sur lequel opère notre analyse est un langage comprenant les principales fonctionnalités présentes dans les langages de la famille ML, c’est-à-dire des fonctions d’ordre supérieur, des constructeurs de données algébriques et du filtrage par motif. Nous participons ainsi à combler le manque d’outils associés aux langages de la famille ML. L’analyse que nous présentons a été spécifiquement conçue dans le but de répondre aux besoins particuliers des évaluateurs de logiciels critiques. Ces besoins, présentés ci-dessous, ont été identifiés suite au retour d’expérience de Philippe Ayrault, lui-même évaluateur de logiciels critiques dans le domaine ferroviaire [ABDP12, Ayr11]. Interactivité et souplesse Notre analyse permet à l’évaluateur d’analyser n’importe quelle partie du code source du logiciel critique à évaluer, en fournissant un environnement d’analyse qui est une spécification plus ou moins précise de l’environnement d’évaluation. Cet environnement d’analyse offre à l’évaluateur la possibilité de paramétrer l’analyse en donnant pour chaque identificateur présent dans l’environnement une valeur plus ou moins abstraite. Il est ainsi possible pour l’évaluateur d’analyser les programmes à différents niveaux d’abstraction, de manière à avoir tantôt une vision globale des différents composants 22INTRODUCTION du système, tantôt une vision plus fine d’un composant en particulier. C’est l’expertise de l’évaluateur qui donne la ligne directrice du processus de vérification en utilisant l’analyse à différentes étapes du processus, à chaque fois en utilisant le niveau d’abstraction qui convient. Haut niveau de confiance Pour garantir la fiabilité de notre analyse, nous sommes remontés jusqu’aux fondements de la notion de dépendance. Nous donnons une définition formelle de la notion de dépendance en nous appuyant directement sur la sémantique opé- rationnelle du langage. Nous avons ensuite construit, étape par étape, une preuve formelle permettant de fournir à l’évaluateur une garantie de la propriété de correction dont il a besoin en établissant formellement le lien entre notre analyse et la notion de dépendance. Une grande partie de la preuve a été réalisée et vérifiée à l’aide de l’assistant à la preuve COQ. Nous fournissons dans le présent manuscrit une preuve papier de la partie restantes. L’intégralité du développement Coq réalisé est disponible librement à l’adresse suivante : https://github.com/vincent-benayoun/PhD-thesis. Notre analyse possède une spécificité supplémentaire : la prise en compte de l’impact d’un dysfonctionnement sur la terminaison du programme. En consultant le résultat de l’analyse d’un programme, on peut savoir non seulement quelles sont les parties du programme ayant une influence sur les valeurs calculées mais également celles ayant une in- fluence sur la terminaison. Cette dernière information est intéressante pour l’évaluateur de logiciels critiques dans la mesure où la non-terminaison d’un programme peut constituer un réel risque de dysfonctionnement. Plan de la thèse La structure du manuscrit est la suivante : Chapitre 1 : État de l’art Nous présentons le contexte scientifique de cette thèse en mettant en relation notre analyse de dépendances avec d’autres travaux. En premier lieu, nous expliquons en quoi notre travail s’inscrit dans la continuité de travaux existants dans le domaine. Puis nous explicitons les liens entre notre analyse de dépendances et 23INTRODUCTION quelques travaux similaires portant sur la non-interférence et l’analyse de teintes. Enfin montrons en quoi notre analyse s’inscrit dans le cadre général de l’interprétation abstraite de programmes. Chapitre 2 : Notion de dépendance Après avoir présenté le langage sur lequel opère notre analyse ainsi que sa sémantique opérationnelle, nous présentons une définition formelle des notions de base utilisée pour exprimer ce que nous appelons dépendances d’un programme. Nous commençons par présenter l’injection de valeur qui nous permet de représenter formellement les points de programme dont on veut connaître l’impact. Nous définissons alors formellement la notion d’impact en elle-même, qui est double : l’impact sur la terminaison et l’impact sur la valeur du programme. Nous pouvons ensuite introduire la notion de dépendance qui se divise également en deux : les dépendances de terminaison et les dépendances de valeur. Chapitre 3 : Analyse dynamique Une fois la notion de dépendance formalisée, nous définissons une analyse dynamique permettant de calculer les dépendances d’un programme. Ces dépendances seront fournies par l’analyse dynamique sous forme d’annotations sur chacun des sous-termes de la valeur du programme. Nous appelons cette analyse dynamique sémantique instrumentée et nous l’introduisons à l’aide de deux sémantiques intermé- diaires qui nous permettent d’établir la correction de cette sémantique instrumentée. Chapitre 4 : Analyse statique Ce chapitre touche enfin au but de cette thèse : présenter notre analyse statique des dépendances d’un programme. Afin d’atteindre ce résultat, nous partons de l’analyse dynamique présentée au chapitre précédent. Nous introduisons alors, à l’aide de deux nouvelles sémantiques intermédiaires, une interprétation abstraite de l’analyse dynamique que nous appelons sémantique abstraite. C’est cette dernière sémantique qui constitue notre analyse statique de dépendances. Chapitre 5 : Implémentation et preuve Nous présentons dans ce dernier chapitre les développements effectués autour de l’analyse de dépendances. D’une part, nous exposerons le développement au sein de l’atelier de preuve Coq, qui a permis de formaliser les différentes 24INTRODUCTION sémantiques présentées dans cette thèse ainsi que de construire et vérifier leurs preuves de correction. D’autre part, nous discuterons des différents prototypes réalisés. Conclusion et perspectives Enfin, nous présentons un bilan du travail réalisé en ouvrant la voie vers de possibles développements futurs. En particulier, nous parlerons des possibilités d’extension du langage analysé et des pistes d’optimisation de l’analyse (performance et précision). 25INTRODUCTION 26Chapitre 1 État de l’art 1.1 Analyse de dépendances pour les logiciels critiques 1.1.1 Les langages ML Cette thèse s’inscrit dans la suite de la thèse de P. Ayrault [Ayr11, ABDP12] soutenue en 2011. Elle reprend l’analyse statique de dépendances qui y était présentée, la rend plus générale en y apportant un certain nombre de modifications et en propose une preuve formelle vérifiée mécaniquement à l’aide de l’assistant à la preuve Coq. La première modification réside en la manière d’annoter les programmes pour permettre à l’évaluateur de logiciel critique de désigner les points de programme dont il souhaite connaître l’impact. Dans l’analyse de P. Ayrault, on ne pouvait annoter que les sous-expressions du programme explicitement nommées par une instruction de liaison (let x = e). Dans l’analyse que nous présentons, toute sous-expression du programme peut être marquée pour analyser son impact sur l’évaluation du programme. La notion de marquage concret/abstrait présentée par P. Ayrault effectuait simultanément deux opérations distinctes. Premièrement, elle permettait de désigner une sousexpression pour connaître son impact. Deuxièmement, elle cachait la valeur de la sousexpression désignée pour la considérer comme une boîte noire. Autrement dit, elle lui appliquait une sorte d’abstraction. Notre approche est plus générale et permet une souplesse accrue quant à l’utilisation de ces deux opérations. Il est maintenant possible de réaliser ces deux opérations séparément. Plus précisément, il est toujours possible de consi- 271.1. ANALYSE DE DÉPENDANCES POUR LES LOGICIELS CRITIQUES dérer comme une boîte noire toute sous-expression marquée pour l’analyse d’impact, mais il est également possible de suivre l’impact d’une sous-expression tout en utilisant sa valeur pour affiner l’analyse d’impact. Il est aussi possible de considérer une partie du programme comme une boîte noire en cachant sa valeur sans pour autant nous intéresser à son impact. Cette amélioration apporte une solution au problème de perte de la structure des valeurs. Ce problème avait été soulevé dans [ABDP12] au sujet de l’analyse de dépendances qui y était présentée. La seconde modification est la distinction entre deux types de dépendance correspondant aux deux types d’impact que peut avoir la valeur d’une sous-expression sur l’évaluation du programme : impact sur la valeur du programme ou impact sur la terminaison de son évaluation. L’analyse présentée par P. Ayrault n’effectuait pas de distinction entre ces deux notions d’impact. Ainsi, si un identificateur se trouvait uniquement dans un certain sous-terme du résultat de l’analyse, on ne savait pas si cet identificateur avait uniquement un impact sur la valeur de ce sous-terme ou bien si celui-ci avait un impact global sur la terminaison de l’évaluation du programme. L’analyse statique que nous présentons dans cette thèse apporte une réponse plus précise quant au type d’impact. Si un identificateur se trouve uniquement dans un certain sous-terme du résultat de l’analyse et qu’il n’apparaît pas dans les dépendances de terminaison du programme, alors on peut être sûr qu’il n’a d’impact que sur la valeur de ce sous-terme précis et qu’il ne peut aucunement affecter les autres sous-termes de la valeur, ni la terminaison du calcul. Considérons un exemple simple pour illustrer les différences entre les deux approches : l e t a = 3 2 ; ; l e t b = 1 8 ; ; l e t c = b + 8 ; ; l e t f x = ( a + 1 , x ) ; ; l e t d = f c ; ; Supposons que nous souhaitons analyser l’impact de a, de b et de c. Dans l’analyse de P. Ayrault, nous marquons les trois premières définitions top-level à l’aide d’un tag « abstrait ». Dans notre analyse, nous annotons les trois définitions correspondantes à 281.1. ANALYSE DE DÉPENDANCES POUR LES LOGICIELS CRITIQUES l’aide de trois labels la, lb et lc. On obtient alors les résultats suivants : Analyse de P. Ayrault Notre analyse statique a : a a : [ ∅ | [ la | ⊤ ] ] b : b b : [ ∅ | [ lb | ⊤ ] ] c : c c : [ ∅ | [ lb, lc | ⊤ ] ] f : < λx.(a + 1, x),(a, a); . . . > f : [ ∅ | [ ∅ | < λx.(a + 1, x),(a, . . .); . . . > ] ] d : (a, c) d : [ ∅ | [ ∅ | ( [ la | ⊤ ], [ lb, lc | ⊤ ]) ] ] L’analyse de P. Ayrault nous apprend que l’identificateur a ne dépend que de lui-même. Elle nous apprend la même chose pour l’identificateur b et pour c. On remarque que l’identificateur b n’apparaît pas dans le résultat de c. Ceci est dû à la notion de marquage « abstrait » qui coupe en quelque sorte les dépendances d’un identificateur marqué. C’est pour cette raison que le théorème exprimé dans la thèse de P. Ayrault n’est en général pas valable s’il y a plus d’un identificateur marqué. Le résultat obtenu pour f est simplement une fermeture. Enfin, le résultat pour d nous apprend qu’il s’agit d’un couple dont la première composante dépend de a et la seconde composante dépend de c. Notre analyse fournit des résultats un peu différents. Pour a (resp. b), on apprend qu’aucune injection ne peut empêcher l’évaluation de cette partie de programme de terminer. Par contre, une injection sur a (resp. b) peut provoquer une modification du résultat de cette évaluation. Le symbole ⊤ indique que la valeur a été abstraite. Pour l’identificateur c, l’analyse fournit à la fois la dépendance lb (car la valeur de c dépend de celle de b) et la dépendance lc (car on a annoté la définition de c avec ce label). Le résultat pour f est une fermeture. Celui pour d nous indique qu’aucune injection ne peut empêcher la terminaison du programme et que la valeur de d est un couple dont la première composante dépend de la et la seconde dépend de lb et lc. Un autre apport important par rapport à la thèse de P. Ayrault concerne la preuve de correction de l’analyse. Dans le chapitre 3 de sa thèse, P. Ayrault présente une preuve formelle de son analyse de dépendances. Cette preuve, complexe à vérifier, a été réalisée sur papier, bien que l’assistant à la preuve Coq ait été utilisé pour vérifier formellement certaines propriétés (formalisation du langage et de l’analyse, preuve du déterminisme de l’analyse). De plus, la preuve de correction proposée n’est valable que dans le cas particulier où le programme analysé n’est marqué qu’en un unique point. Il n’est donc pas possible de 291.1. ANALYSE DE DÉPENDANCES POUR LES LOGICIELS CRITIQUES se reposer sur ce théorème lors de l’analyse d’un programme marqué en plusieurs points (il est facile de trouver des contre-exemples). Nous apportons dans cette thèse une preuve formelle réalisée en Coq. Cette preuve a été réalisée par étapes successives en « instrumentant » (c’est-à-dire en enrichissant) la sémantique opérationnelle du langage pour qu’elle transporte toutes les informations nécessaires au calcul des dépendances, puis en prouvant formellement des abstractions successives de cette sémantique jusqu’à obtenir l’analyse statique désirée. Nous obtenons ainsi une plus grande clarté en mettant en exergue des résultats intermédiaires importants et compréhensibles permettant de composer la preuve finale de façon modulaire. Un avantage certain de cette approche est de pouvoir prouver une version modifiée de l’analyse statique en réutilisant une grande partie des preuves déjà effectuées. On pourra ainsi proposer par la suite de modifier l’analyse statique pour obtenir des résultats plus précis (à l’aide d’une représentation plus fine pour les types sommes, les entiers ou encore les fonctions) ou pour améliorer les performances de calcul (en ajoutant des approximations). La preuve de correction d’une telle analyse sera alors obtenue à moindre frais puisqu’il faudra uniquement prouver la toute dernière abstraction, toutes les autres preuves étant réutilisables telles quelles. 1.1.2 SPARK/Ada Des analyses statiques de dépendances adaptées aux évaluateurs de logiciels critiques existent déjà. C’est notamment le cas pour SPARK [Bar03], un sous-ensemble du langage Ada, spécialement conçu pour le développement de logiciels critiques. Il embarque toute une série d’analyses statiques prenant en compte les annotations de l’utilisateur afin de garantir que le programme fonctionne conformément à ses spécifications. En particulier, SPARK est doté d’un langage d’annotations [CH04] permettant à l’utilisateur de spécifier diverses contraintes sur les flots d’information et de contrôle de son programme. Il est tout d’abord possible de préciser pour chaque paramètre d’une fonction s’il s’agit d’une entrée, d’une sortie ou d’une entrée/sortie, ce qui permet de donner une direction aux flots d’information possibles et de vérifier certaines erreurs statiquement. C’est également une information précieuse pour l’évaluateur de logiciels critiques pour lui permettre de comprendre de façon simple et sûre le comportement du programme. Nous ne nous sommes 301.1. ANALYSE DE DÉPENDANCES POUR LES LOGICIELS CRITIQUES pas intéressés à ce type d’annotation puisque la distinction entre les entrées et les sorties ainsi que la nécessité d’initialiser une variable avant son utilisation découle naturellement des propriétés intrinsèques des langages purement fonctionnels. Une autre fonctionnalité importante concernant la spécification du flot d’information est la possibilité de spécifier pour chaque sortie, quelles sont les entrées utilisées pour le calcul de sa valeur. Voici un exemple de code annoté en SPARK spécifiant que la seule variable globale utilisée est Count et qu’après l’appel de la fonction, la nouvelle valeur de Count dépend de son ancienne valeur et de celle de X et la nouvelle valeur de X dépend uniquement de sa valeur précédente. p ro c e d u r e Inc remen t (X : i n out Counter_Type ) ; −−# g l o b a l Count ; −−# d e r i v e s −−# Count from Count , X & −−# X from X; Le développeur peut ainsi spécifier avec précision le flot d’information pour détecter d’éventuelles erreurs au plus tôt dans le cycle de développement. Cette spécification est alors vérifiée statiquement par une analyse du code source. Ce type d’annotation est un élément important dans la phase de vérification d’un logiciel critique. L’évaluateur peut alors se reposer sur les annotations du développeur puisqu’il sait qu’une analyse du code source a été faite par un outil logiciel fiable afin d’assurer la correction de ces annotations. Cette garantie de fiabilité des annotations permet à l’évaluateur de logiciels critiques de s’épargner une vérification manuelle fastidieuse et coûteuse. Cet outil de spécification et de vérification de propriétés sur le flot d’information du programme disponible pour SPARK (SPARK Examiner) est un outil puissant et fiable que l’évaluateur de logiciels critiques voudrait retrouver pour d’autres langages de programmation. Notre travail s’inscrit dans la satisfaction de ce besoin concernant les langages de la famille ML qui commencent à être utilisés pour des développements critiques, soit pour la construction de logiciels nécessitant un haut niveau de fiabilité [MW08], soit pour la construction d’outils logiciels nécessitant d’être qualifiés pour leur utilisation dans le développement de logiciels critiques régis par des normes (EN-50128, DO-178B/C, . . . ) [PAC+08, FHJ+06, JES00]. 311.2. ANALYSE DE FLOT POUR LES LANGAGES FONCTIONNELS Nous présentons dans cette thèse une analyse statique des dépendances d’un programme ML qui pourra être utilisée comme une base théorique solide afin de développer un outil de spécification et de vérification de propriétés sur le flot d’information adapté aux spécificités des langages ML, en s’inspirant de l’outil analogue disponible pour SPARK. 1.2 Analyse de flot pour les langages fonctionnels L’analyse de flot pour les langages fonctionnels d’ordre supérieur est un sujet qui a fait l’objet de nombreux travaux dont nous mentionnons les principaux dans la suite. En 1996, M. Abadi, B.W. Lampson et J.J. Lévy [ALL96] proposent une analyse de flot d’information pour un lambda calcul. Le but de leur analyse est alors l’optimisation du temps d’exécution en stockant des valeurs déjà calculées. Lors de l’évaluation d’une expression, si celle-ci a déjà été évalué et que depuis cette première évaluation les seules valeurs mofidiées depuis sont indépendantes, alors on utilise la valeur déjà calculée au lieu de ré- évaluer l’expression. Dans le langage qu’ils considèrent, n’importe quelle sous-expression du programme analysé peut être annotée avec un label. Leur analyse est construite comme une extension de la sémantique opérationnelle usuelle du lambda calcul en ajoutant une règle manipulant les labels. Ainsi, il s’agit d’une analyse dynamique qui évalue le programme pour obtenir une valeur contenant certains des labels présents en tant qu’annotation dans le programme. Si un label n’est pas présent dans la valeur, cela signifie que la sous-expression correspondante n’a pas d’influence sur le calcul de la valeur du programme. Pour illustrer le fonctionnement de cette analyse, reprenons l’exemple suivant que nous avons déjà présenté plus haut : l e t a = 3 2 ; ; l e t b = 1 8 ; ; l e t c = b + 8 ; ; l e t f x = ( a + 1 , x ) ; ; l e t d = f c ; ; l e t d1 = f s t d ; ; l e t d2 = snd d ; ; 321.2. ANALYSE DE FLOT POUR LES LANGAGES FONCTIONNELS Analyse dynamique de M. Abadi et al. Notre analyse statique a : la : 32 a : [ ∅ | [ la | ⊤ ] ] b : lb : 18 b : [ ∅ | [ lb | ⊤ ] ] c : lb, lc : 26 c : [ ∅ | [ lb, lc | ⊤ ] ] f : λx.(32 + 1, x) f : [ ∅ | [ ∅ | < λx.(a + 1, x),(a, . . .); . . . > ] ] d : (la : 32 + 1, lb, lc : 26) d : [ ∅ | [ ∅ | ( [ la | ⊤ ], [ lb, lc | ⊤ ]) ] ] d1 : la : 33 d1 : [ ∅ | [ la | ⊤ ] ] d2 : lb, lc : 26 d2 : [ ∅ | [ lb, lc | ⊤ ] ] L’analyse dynamique de M. Abadi et al. est définie par une sémantique small-step et les couples sont encodés sous forme de fonctions, ce qui explique pourquoi la valeur de d n’est pas complètement réduite. Outre les dépendances de terminaison qui ne sont pas présentes dans l’analyse de M. Abadi et al. et les valeurs numériques qui sont abstraites dans notre analyse, les dépendances calculées sont identiques dans cet exemple. M. Abadi et al. [ABHR99] montrent ensuite que plusieurs formes d’analyses de flot d’information peuvent être construites en utilisant le même calcul de dépendances. Ils proposent alors un cadre générique pour ces diverses formes d’analyses. F. Pottier et S. Conchon [PC00] ont alors transformé l’analyse dynamique de [ALL96] en une analyse statique en utilisant une « simple » traduction et un système de types standard. Ils affirment qu’en combinant leur travail avec celui de [ABHR99], leur analyse statique peut aussi être utilisée pour toutes les formes d’analyse de dépendances présentées dans [ABHR99]. Plus tard, François Pottier et Vincent Simonet [PS02] ont proposé une technique pour l’analyse de flot sur un lambda calcul étendu par la gestion des références et des exceptions. C’est une nouvelle approche, basée sur un système de types spécifique, qui a été proposée pour combler les manques de l’approche précédente [PC00]. Cette dernière approche, utilisée comme base pour la construction de l’outil FlowCaml [SR03, Flo03], utilise un treillis représentant des niveaux de sécurité dans le but d’assurer des propriétés de non-interférence. Comme il a été montré précédemment dans [ABHR99], ce type d’analyse à base de treillis peut être utilisé pour effectuer diverses analyses de dépendances en utilisant un treillis adapté. La notion de non-interférence a été introduite en 1982 par J.A. Goguen et J. Meseguer [GM82]. Il s’agit d’une propriété sur un programme manipulant des données et ayant des 331.2. ANALYSE DE FLOT POUR LES LANGAGES FONCTIONNELS interaction avec son environnement. En langage simple, cette propriété s’exprime de la manière suivante : « Un comportement du programme ayant un niveau de sécurité faible n’est pas affecté par une donnée ayant un niveau de sécurité élevé ». Cette propriété permet en particulier de ne pas révéler d’information confidentielle à des personnes non-autorisées. On retrouve par exemple cette notion sous la forme de propriétés d’isolation sur les programmes embarqués dans les cartes à puce [ACL03]. L’analyse de non-interférence de FlowCaml est une analyse de flot d’information pré- sentant des similarités avec notre analyse de dépendances. On peut attribuer à certaines valeurs du programme des niveaux de sécurité et définir un treillis spécifiant une relation d’ordre entre les différents niveaux de sécurité. Un système de types permet alors d’inférer les niveaux de sécurité des valeurs calculées par le programme et de vérifier la cohérence avec les annotations de l’utilisateur. On peut ainsi vérifier qu’aucune valeur confidentielle n’a d’influence sur une valeur moins confidentielle. Dans l’analyse de dépendances dont nous avons besoin, la préoccupation sous-jacente est de savoir si une défaillance quelconque à un point donné du programme peut ou non avoir des répercussions sur une valeur considérée comme critique. Cette analyse est particulièrement utile pour garantir qu’un point de programme (une sous-expression donnée) n’a aucune influence sur une certaine valeur critique. On peut alors certifier que cette valeur restera valide en cas de défaillance au point de programme. On constate que, bien que le vocabulaire soit différent, notre besoin est assez proche de ce que propose l’analyse de non-interférence de FlowCaml. D’après nos expérimentations, il est possible d’utiliser FlowCaml pour calculer les dé- pendances dont nous avons besoin (du point de vue de l’évaluateur de logiciels critiques) en obtenant des résultats plutôt bons, jusqu’à un certain point. Pour cela, on utilise un treillis plat (relation d’ordre vide) dont les éléments sont des identifiants désignant les points de programmes dont nous souhaitons connaître l’impact. L’inférence de type fournit alors l’analyse de dépendances désirée. Cependant, certains aspects de l’analyse ne sont pas adaptés. Premièrement, le système d’annotation manque de souplesse. Par exemple, on ne peut annoter que des valeurs mutuellement indépendantes, sans quoi il serait nécessaire d’expliciter dans le treillis les relations entre les valeurs annotées, ce qui nous ferait 341.2. ANALYSE DE FLOT POUR LES LANGAGES FONCTIONNELS perdre la traçabilité des différentes dépendances. Il n’est pas non plus possible d’annoter une valeur structurée (par exemple un couple) par un label unique. On notera également qu’il n’est pas possible d’annoter un point de programme quelconque, mais uniquement les valeurs nommées. Deuxièmement, l’analyse de FlowCaml ne permet pas d’abstraire un morceau de programme en le considérant comme une boîte noire. C’est un besoin important pour l’évaluateur de logiciels critiques pour lui permettre de se concentrer sur l’analyse d’un composant particulier du programme, en considérant les autres composants comme opaques. Cette fonctionnalité peut aussi lui permettre d’analyser facilement un composant isolé du programme sans connaître l’implémentation des autres composants utilisés. Par exemple, un évaluateur peut vouloir effectuer l’évaluation d’un programme faisant appel à des librairies dont il n’a pas accès au code source. De plus, l’analyse de dépendances que nous présentons permet à la fois l’analyse d’impact sur la terminaison du programme et l’analyse d’impact sur les valeurs calculées lors de l’évaluation du programme. Cette distinction entre dépendances de terminaison et dé- pendances de valeurs n’est pas présente dans FlowCaml. Toujours sur le même exemple, voici une comparaison entre l’analyse de FlowCaml et notre analyse statique : flow ! b < ! c ; ; l e t a : ! a i n t = 3 2 ; ; l e t b : ! b i n t = 1 8 ; ; l e t c : ! c i n t = b + 8 ; ; l e t f x = ( a + 1 , x ) ; ; l e t d = f c ; ; Analyse statique FlowCaml Notre analyse statique a : !a int a : [ ∅ | [ la | ⊤ ] ] b : !b int b : [ ∅ | [ lb | ⊤ ] ] c : [> !b, !c] int c : [ ∅ | [ lb, lc | ⊤ ] ] f : ’a -> !a int * ’a f : [ ∅ | [ ∅ | < λx.(a + 1, x),(a, . . .); . . . > ] ] d : !a int * [> !b, !c] int d : [ ∅ | [ ∅ | ( [ la | ⊤ ], [ lb, lc | ⊤ ]) ] ] FlowCaml calcule les dépendances pendant le typage et fournit les résultats de types annotés par des informations de dépendances. Les résultats nous indiquent que la valeur de 351.2. ANALYSE DE FLOT POUR LES LANGAGES FONCTIONNELS l’identificateur a (resp. b) est un entier qui ne dépend que de lui-même. Pour la définition de c, FlowCaml rejette cette définition si nous n’indiquons pas explicitement la relation entre b et c à l’aide de la directive flow !b < !c ;; qui signifie que l’on autorise un flot d’information allant d’une valeur de niveau !b vers une valeur de niveau !c. Le résultat de c correspond au type d’une fonction prenant un paramètre et retournant un couple dont la première composante est un entier dépendant de a et dont la seconde composante a le même type et les mêmes dépendances que l’argument. C’est un résultat bien plus concis et explicite que le résultat de notre analyse qui embarque le corps de la fonction ainsi que son environnement. Le résultat de d nous fournit les mêmes informations de dépendances que notre analyse. Dans notre analyse, nous représentons tous les nombres entiers par la valeur ⊤ qui représente n’importe quelle valeur. Nous pourrions ajouter à notre algèbre de valeurs abstraites une valeur permettant de représenter uniquement les nombres entiers, mais il n’est pas évident que ceci ait un réel intérêt. Par contre, au sujet de la représentation des fonctions au sein de notre algèbre de valeurs abstraites, il serait sans doute intéressant de trouver une représentation plus compacte, à l’image du type retourné par FlowCaml. Nous nous sommes inspirés de la méthode utilisée par M. Abadi et al. [ALL96] pour annoter à l’aide de labels les sous-expressions du programme dont nous souhaitons suivre l’impact. Notre analyse dynamique suit le même principe que leur analyse en calculant la valeur du programme tout en y accumulant les labels utilisés pour son élaboration. Il faut cependant remarquer deux différences fondamentales. Premièrement, nous utilisons une sé- mantique big-step contrairement à M. Abadi et al. qui utilisent une sémantique small-step. L’avantage d’une sémantique big-step est de pouvoir lier directement une expression avec le résultat de son évaluation, ce qui nous est d’une grande aide lorsque l’on veut parler de plusieurs évaluations simultanées d’une même expression. Le choix de la sémantique bigstep nous a permis d’exprimer les définitions de nos sémantiques de façon plus naturelle, en particulier pour la sémantique collectrice. Ce choix nous a également permis d’obtenir des preuves plus simples, en particulier pour les sémantiques collectrice et abstraite. Deuxiè- mement, nous produisons des valeurs structurées dont chaque sous-terme est annoté par ses propres dépendances, contrairement à leur analyse qui regroupe en tête de la valeur 361.3. ANALYSE DE TEINTES produite une liste globale de tous les labels utilisés pour produire la valeur. Notre analyse permet ainsi d’obtenir un résultat plus précis. Nous avons ensuite transformé notre analyse dynamique en une analyse statique. Nous avons alors marqué une rupture avec les autres travaux présentés dans cette section, puisque contrairement à F. Pottier et S. Conchon, nous n’avons pas formalisé notre analyse statique sous forme d’un système de types. Nous avons fait le choix d’utiliser le formalisme de l’interprétation abstraite qui nous a permis plus de souplesse dans la définition d’une analyse adaptée à nos besoins. En particulier, ce cadre nous a permis de définir avec aisance l’abstraction d’une partie de programme sous forme de boîte noire. 1.3 Analyse de teintes L’analyse de teintes telle que présentée dans [XBS06] est un cas particulier d’analyse de flot d’information [Kri07]. Ce type d’analyse permet d’identifier les entrées (contrôlables par l’utilisateur) ayant un impact sur certaines opérations dites « critiques » ou « dangereuses » du point de vue de la sécurité. Par exemple, si une valeur contrôlable par l’utilisateur est utilisée sans précaution particulière en tant qu’indice lors de la modification d’une case de tableau, il peut y avoir une vulnérabilité de type buffer overflow. Dans ce cas, l’utilisateur peut modifier des valeurs en mémoire auxquelles il ne devrait pas avoir accès. Pour détecter ce type de vulnérabilité, l’analyse de teinte permet d’identifier tout au long du programme les valeurs dites teintées (ie. contrôlables par l’utilisateur) afin de donner une alerte si une telle valeur est utilisée pour effectuer une opération dangereuse (accès à un tableau, instruction jump, requête SQL, . . . ). Notre analyse a pour but, quant à elle, d’identifier tout au long du programme les valeurs possiblement impactées par certains points de programmes (parties non vérifiées d’un programme ou bien valeurs possiblement issues d’un dysfonctionnement). Cette information peut alors nous permettre d’alerter l’utilisateur si une valeur critique du programme peut être impactée par un dysfonctionnement éventuel. On peut ainsi apercevoir la similarité entre les deux approches en considérant un point de programme annoté pour notre analyse comme une valeur teintée. L’analyse de teinte 371.4. INTERPRÉTATION ABSTRAITE permettrait alors de faire la distinction entre les valeurs impactées par ce point de programme et celles qui ne le sont pas. Cependant, elles diffèrent par plusieurs aspects. Dans l’analyse de teintes, une valeur est soit « teintée » soit « non teintée ». Il n’y a aucune distinction entre les différents points d’entrée de l’utilisateur, Bien qu’il soit possible de relier une valeur teintée à un point d’entrée précis en utilisant des informations supplémentaires au sujet des chemins d’exécution, l’analyse de teintes en elle-même ne le permet pas. Notre analyse permet d’indiquer pour chaque valeur quels sont les points d’entrée dont elle dépend. C’est une information importante pour aider l’évaluateur à comprendre la structure du programme et les dépendances entres ses différentes parties. De plus, comme nous l’avons montré plus haut dans la comparaison avec les analyses de flot d’information, nous avons besoin de pouvoir considérer certaines parties du programme comme opaques, ce qui n’est pas le cas des analyses de teintes en général. Enfin, notre analyse s’effectue sur un langage fonctionnel dans lequel les préoccupations de sécurité sont différentes de celles de la plupart des analyses de teintes effectuées sur des langages impératifs. En effet, les accès à des tableaux ou les instructions jump ne sont pas courants dans les langages fonctionnels purs. Une piste intéressante détaillée dans [CMP10] pour une analyse de teintes est la possibilité de garder trace des chemins d’exécution permettant de relier un point d’entrée à l’instruction impactée. Ce type d’information pourrait être particulièrement utile pour notre analyse de dépendances. Ce sujet a d’ailleurs été abordé dans la thèse de P. Ayraut [Ayr11] (Partie III, chapitre 4). 1.4 Interprétation abstraite L’interprétation abstraite est un cadre mathématique permettant de formaliser des analyses de programmes et de prouver leur correction. L’idée principale est d’exécuter des programmes sur un domaine abstrait dont les éléments représentent des propriétés sur le domaine d’évaluation standard. Pour cela, on définit explicitement des fonctions d’abstraction et de concrétisation pour établir le lien entre le domaine d’évaluation standard et le domaine abstrait. Une méthode générique permet alors de prouver la correction de ce 381.4. INTERPRÉTATION ABSTRAITE genre d’analyses de programmes en prouvant certaines propriétés sur la composition des fonctions d’abstraction, de concrétisation et d’évaluation abstraite. À l’origine, la théorie de l’interprétation abstraite a été conçue par P. et R. Cousot [CC77, CC79] pour des langages impératifs. Les analyses de programmes décrites par cette méthode sont exprimées sous forme d’une sémantique opérationnelle. Par la suite, le cadre de l’interprétation abstraite a été adapté aux langages fonctionnels du premier ordre par A. Mycroft [Myc81]. La théorie sous-jacente est alors différente. Contrairement au travail de P. et R. Cousot basé sur une description sous forme de sé- mantique opérationnelle, A. Mycroft fait le choix d’utiliser une sémantique dénotationnelle pour décrire les analyses de programmes. G. Burn, C. Hankin et S. Abramsky [BHA86] ont alors étendu l’analyse de programmes de A. Mycroft en l’adaptant aux langages fonctionnels d’ordre supérieur. En plus d’étendre cette analyse qui est un cas particulier d’interprétation abstraite, ils ont également étendu le cadre général de l’interprétation abstraite aux langages fonctionnels d’ordre supérieur. Dans la lignée de A. Mycroft, leur travail fait usage d’une sémantique dénotationnelle pour définir leur analyse. D’autres travaux, comme ceux de S. Hunt [Hun91] ont appliqué l’interprétation abstraite à des langages de programmation fonctionnels en utilisant des sémantiques dénotationnelles. D’autres approches sont présentées par N.D. Jones et F. Nielson dans [Jon94]. Nous présentons ici une approche originale de l’interprétation abstraite pour un langage fonctionnel d’ordre supérieur. Notre analyse de programme est exprimée sous forme d’une sémantique opérationnelle, comme pour les langages impératifs. De plus, notre analyse opère sur un langage de programmation comprenant des constructeurs de données récursives ainsi que du filtrage par motifs. Pour ce qui est des fonctions récursives, nous nous affranchissons du problème de la terminaison et de la recherche d’un point fixe à l’aide d’une approximation permettant de casser la récursion. Cependant, le problème pourrait resurgir en recherchant une meilleure représentation des fonctions récursives dans l’algèbre des valeurs abstraites. En effet, il serait souhaitable d’améliorer notre analyse en trouvant une meilleure représentation des fonctions, ce qui pourrait apporter de nombreux avantages 391.4. INTERPRÉTATION ABSTRAITE autant du point de vue de la précision de l’analyse que du point de vue de la performance. 40Chapitre 2 Notion de dépendance 2.1 Introduction La notion de dépendance est souvent utilisée de manière intuitive. De nombreuses analyses de dépendances se contentent d’une définition informelle. Et quand une définition formelle est donnée, elle est parfois incomplète et ne reflète que partiellement la notion utilisée dans l’analyse correspondante. Nous nous appliquons dans ce chapitre à donner une définition formelle à cette notion de dépendance. Une particularité de la notion de dépendance que nous proposons est la distinction entre 2 types de dépendances : – les dépendances concernant la valeur d’une expression, – les dépendances concernant la terminaison d’une évaluation. Les dépendances de terminaison sont rarement prises en compte dans les analyses de dépendances. Pourtant, la modification d’une partie d’un programme peut provoquer une boucle infinie ou une erreur lors de son évaluation. Dès lors, la connaissance des dépendances de terminaison constitue une information importante, en particulier pour les évaluateurs de logiciels critiques. Après avoir présenté la sémantique opérationnelle de notre langage (qui est la sémantique usuelle d’un programme ML purement fonctionnel), nous expliquerons comment annoter un programme dont on veut connaître les dépendances. Nous verrons ensuite comment annoter les valeurs du langage avec des informations de dépendance. Nous pourrons alors définir la sémantique opérationnelle avec injection qui nous permettra d’introduire 412.1. INTRODUCTION les notions d’injection de valeur et d’impact d’une injection. Nous aurons alors à notre disposition toutes les notions sous-jacentes nécessaires à la définition formelle de la notion de dépendance. Nous présenterons alors la définition de la notion de dépendance que nous proposons. 422.2. LE LANGAGE : ALGÈBRE DES EXPRESSIONS 2.2 Le langage : algèbre des expressions Le langage sur lequel nous définissons notre analyse est un noyau purement fonctionnel de la famille ML. Il contient les principales caractéristiques des langages purement fonctionnels : les fonctions d’ordre supérieur, les constructeurs de données (types algébriques), le filtrage par motif (pattern-matching), la liaison (let-binding). En plus des constructions habituelles, on ajoute la possibilité d’annoter une sousexpression à l’aide d’un label. Cette annotation permet de définir un point d’injection (cf. section 2.4). e := n | C | D(e) | (e1, e2) Constructeurs de données x Identificateur λx.e | recf.x.e Fonctions (récursive ou non) e1 e2 Application let x = e1 in e2 Liaison if e then e1 else e2 Expression conditionnelle match e with p → e1 | x → e2 Filtrage par motif l : e Annotation d’un point d’injection p := C | D(x) | (x1, x2) Filtres des données structurées Figure 2.1 – Algèbre des expressions du langage Etant donné un ensemble de constantes numériques noté Z, un ensemble de constructeurs de donnée sans paramètre est noté Constr0 un ensemble de constructeurs de données avec paramètre est noté Constr1 . 2.3 Sémantique opérationnelle Il s’agit de la sémantique opérationnelle usuelle. Nous ajoutons une seule règle supplé- mentaire permettant d’ignorer les annotations dans les programmes. 2.3.1 Valeurs L’algèbre des valeurs comprend les valeurs constantes (entières et booléennes), des constructeurs de données structurées (paramétrés ou non), un constructeur de couple et des fermetures (récursives ou non). 432.3. SÉMANTIQUE OPÉRATIONNELLE v := n | b | C | D(v) | (v1, v2) Constructeurs de données < λx.e, Γ > Fermeture < recf.x.e, Γ > Fermeture récursive 2.3.2 Environnements Un environnement d’évaluation est une liste associative identificateurs → valeur. Γ := (x1, v1) ⊕ . . . ⊕ (xn, vn) Environnement 2.3.3 Règles d’inférence Le jugement d’évaluation de la sémantique opérationnelle prend la forme suivante : Γ ⊢ e →→ v Hormis la règle de l’évaluation d’une expression annotée par un label que nous avons ajoutée, les règles d’inférence définissant la sémantique opérationnelle de notre langage sont usuelles. Ces règles sont récapitulées dans les figures 2.2 et 2.3. Nous donnons ci-dessous quelques explications concernant l’évaluation des fonctions et de leur application, du filtrage par motif et des expressions annotées. Évaluation et application des fonctions Une fonction non-récursive est évaluée en une fermeture. Celle-ci contient la définition de la fonction ainsi que l’environnement dans lequel elle a été définie (ce qui permet de retrouver la valeur de chaque identificateur libre de la définition de la fonction). Une fonction récursive est évaluée en une fermeture récursive, similaire à une fermeture non-récursive. Les deux types de fermeture permettent de déterminer quelle règle d’inférence appliquer lors de l’application d’une fonction. Dans notre sémantique, l’application d’une fonction (récursive ou non) se fait en appel par valeur. C’est-à-dire que la valeur de l’argument est calculée systématiquement avant l’évaluation du corps de la fonction (même si l’argument n’est pas utilisé dans le corps de la fonction). 442.3. SÉMANTIQUE OPÉRATIONNELLE Filtrage à motif unique Une particularité du filtrage par motif dans notre langage est qu’il ne filtre que sur un seul motif. Si la valeur filtrée correspond au motif, alors l’évaluation passe par la première branche, sinon, l’évaluation passe par la seconde branche. Bien que cette restriction contraigne la forme des programmes, elle n’affecte en rien l’expressivité du langage. En effet, il est toujours possible d’écrire des filtrages imbriqués, ce qui donne la possibilité de réécrire tout programme contenant des filtrages à plusieurs motifs en un programme équivalent contenant uniquement des filtrages à motif unique en cascade. Notre langage peut donc être vu comme un langage noyau n’étant pas directement manipulé par l’utilisateur. Une phase de réécriture simple sera nécessaire entre le langage utilisé en pratique par l’utilisateur et le langage sur lequel l’analyse sera effectuée. Expressions annotées Les annotations sont utilisées pour définir des points d’injection (cf. section 2.4). Ces points d’injection serviront à calculer les dépendances du programme. En ce qui concerne la sémantique opérationnelle, ils n’ont aucune signification et sont donc ignorés. Techniquement, évaluer une expression annotée revient à évaluer sa sous-expression sans tenir compte de l’annotation. 2.3.4 Sémantique des programmes mal typés et filtrage par motif Le filtrage par motif que nous présentons est défini par les règles op-match et opmatch-var ainsi que par le jugement v, p ⊢p •. On considère que le typage garantit que toute valeur filtrée est soit un constructeur de donnée, soit un couple. Dans ces cas-là, les règles d’inférence définissent la sémantique du filtrage. Par contre, nous ne donnons pas de sémantique à l’évaluation des programmes mal typés pour lesquels l’expression filtrée ne s’évalue pas en une valeur filtrable (constructeur de donnée ou couple). Par exemple, si l’expression filtrée s’évalue en une fermeture, le filtrage n’a pas de sens et l’expression n’a donc pas de sémantique d’évaluation. Ce choix est cohérent avec la sémantique d’une expression conditionnelle. En effet, nous n’explicitons pas la sémantique d’une expression conditionnelle dans le cas où la condition s’évalue en autre chose qu’un booléen. Dans un compilateur réel, la sémantique des programmes mal typés peut dépendre du 452.3. SÉMANTIQUE OPÉRATIONNELLE op-num Γ ⊢ n →→ n op-ident v = Γ[x] Γ ⊢ x →→ v op-abstr Γ ⊢ λx.e →→< λx.e, Γ > op-abstr-rec Γ ⊢ recf.x.e →→< recf.x.e, Γ > op-apply Γ ⊢ e1 →→< λx.e, Γ1 > Γ ⊢ e2 →→ v2 (x, v2) ⊕ Γ1 ⊢ e →→ v Γ ⊢ e1 e2 →→ v op-apply-rec Γ ⊢ e1 →→ v1 v1 =< recf.x.e, Γ1 > Γ ⊢ e2 →→ v2 (f, v1) ⊕ (x, v2) ⊕ Γ1 ⊢ e →→ v Γ ⊢ e1 e2 →→ v op-if-true Γ ⊢ e →→ true Γ ⊢ e1 →→ v1 Γ ⊢ if e then e1 else e2 →→ v1 op-if-false Γ ⊢ e →→ f alse Γ ⊢ e2 →→ v2 Γ ⊢ if e then e1 else e2 →→ v2 op-constr-0 Γ ⊢ C →→ C op-constr-1 Γ ⊢ e →→ v Γ ⊢ D(e) →→ D(v) op-couple Γ ⊢ e1 →→ v1 Γ ⊢ e2 →→ v2 Γ ⊢ (e1, e2) →→ (v1, v2) op-match Γ ⊢ e →→ v v, p ⊢p Γp Γp ⊕ Γ ⊢ e1 →→ v1 Γ ⊢ match e with p → e1 | x → e2 →→ v1 op-match-var Γ ⊢ e →→ v v, p ⊢p ⊥ (x, v) ⊕ Γ ⊢ e2 →→ v2 Γ ⊢ match e with p → e1 | x → e2 →→ v2 op-letin Γ ⊢ e1 →→ v1 (x, v1) ⊕ Γ ⊢ e2 →→ v2 Γ ⊢ let x = e1 in e2 →→ v2 op-annot Γ ⊢ e →→ v Γ ⊢ l : e →→ v Figure 2.2 – Règles d’inférence de la sémantique opérationnelle opm-constr-0 C, C ⊢p {} opm-constr-1 D(v), D(x) ⊢p {(x, v)} opm-couple (v1, v2),(x1, x2) ⊢p {(x1, v1); (x2, v2)} opm-constr-0-not p ̸= C C, p ⊢p ⊥ opm-constr-1-not p ̸= D′ (_) D(v), p ⊢p ⊥ opm-couple-not p ̸= (_, _) (v1, v2), p ⊢p ⊥ Figure 2.3 – Règles d’inférence du filtrage de la sémantique opérationnelle 462.3. SÉMANTIQUE OPÉRATIONNELLE choix de l’implémentation du compilateur. Il est en effet possible que pour des raisons de performance, le compilateur se repose sur le typage pour limiter le nombre d’opérations effectuées. Dans le cas de l’évaluation d’une expression conditionnelle par exemple, on pourrait ne tester que l’égalité entre la valeur de la condition est la valeur true pour passer dans la première branche et que dans tous les autres cas, on passe dans la seconde branche, même si la valeur de la condition n’est pas f alse mais un couple, une fermeture ou toute autre valeur. De même, dans le cas de l’évaluation d’une expression de filtrage, on pourrait se reposer sur le typage pour passer dans la seconde branche dans tous les cas où la valeur filtrée ne correspond pas au motif, même dans les cas mal typés où la valeur de l’expression filtrée n’est ni un constructeur de donnée, ni un couple. Ces choix d’optimisation du compilateur se reposant sur le typage n’ont évidemment pas d’influence sur le résultat de l’évaluation des programmes bien typés. Cependant, notre approche de l’analyse de dépendances considère à la fois l’impact des injections bien typées et l’impact des injections mal typées. Une injection mal typée peut survenir à diverses occasions, par exemple lors du dysfonctionnement d’un capteur ou bien lors d’une perturbation électromagnétique qui modifierait la mémoire de façon imprévisible. 472.4. POINTS D’INJECTION 2.4 Points d’injection 2.4.1 Dans le programme On souhaite analyser un programme pour calculer ses dépendances vis-à-vis de certains points du programme. Ces points de programmes sont appelés « points d’injection » et sont représentés formellement par des annotations sur les sous-expressions du programme. Par exemple, si l’utilisateur veut analyser l’impact d’une sous-expression sur l’évaluation complète d’un programme, il suffira alors d’annoter cette sous-expression à l’aide d’un label unique et de lancer l’analyse. L’utilisateur de l’analyse (évaluateur de logiciels critiques) choisira d’après son expertise quels sont les points de programmes qu’il souhaite annoter. Ces points d’injection peuvent en particulier correspondre à des parties du programmes non-critiques dans le but de s’assurer qu’un dysfonctionnement dans une partie non-critique du programme ne peut pas se propager à une partie critique de celui-ci. 2.4.2 Dans l’environnement La valeur d’une fonction est représentée par une fermeture contenant le corps de la fonction. Celui-ci est une expression contenant possiblement des points d’injection. Au cours de l’évaluation d’un programme, les points d’injection vont donc naturellement se retrouver dans l’environnement d’évaluation. 482.5. SÉMANTIQUE OPÉRATIONNELLE AVEC INJECTION 2.5 Sémantique opérationnelle avec injection La sémantique opérationnelle avec injection est une extension de la sémantique opérationnelle usuelle. Son but est de donner une valeur à un programme dans un environnement donné et ceci pour n’importe quelle injection (à un point du programme ou bien dans son environnement d’évaluation). Cette sémantique donne toujours le même résultat que la sémantique opérationnelle sur les programmes ne comportant pas de point d’injection (programmes non-annotés). La seule différence entre la sémantique opérationnelle usuelle et celle avec injection se trouve lors de l’évaluation d’une sous-expression annotée par un label. Là où la sémantique opérationnelle ignore tout simplement l’annotation, la sémantique opérationnelle avec injection va effectuer ce que l’on appelle l’injection. C’est le comportement de la sémantique opérationnelle avec injection sur les sous-expressions annotées qui constitue précisément notre définition de la notion d’injection. La notion d’injection définie ici est à la base de notre notion de dépendance. 2.5.1 Règles d’inférence Formellement, la sémantique opérationnelle avec injection prend la forme d’un jugement d’évaluation défini par des règles d’inférence. Ce jugement d’évaluation se note de la manière suivante : Γ ⊢l:vl e →→ v , où e est l’expression évaluée, Γ l’environnement d’évaluation et v la valeur résultat. Ce jugement d’évaluation est paramétré par une injection notée en indice (⊢l:vl ), où l représente le point du programme sur lequel on fait l’injection et vl la valeur injectée. On dit que v est la valeur de l’expression e dans l’environnement Γ après injection de la valeur vl au point de programme l. Les règles d’inférence sont toutes identiques aux règles de la sémantique opérationnelle hormis la règle d’évaluation d’une sous-expression annotée. Cette dernière règle est divisée en 2 cas distincts : si l’expression est annotée par le label sur lequel on fait l’injection, alors sa valeur réelle est ignorée et remplacée par la valeur injectée vl , sinon, l’annotation est 492.5. SÉMANTIQUE OPÉRATIONNELLE AVEC INJECTION opinj-num Γ ⊢l:vl n →→ n opinj-ident v = Γ[x] Γ ⊢l:vl x →→ v opinj-abstr Γ ⊢l:vl λx.e →→< λx.e, Γ > opinj-abstr-rec Γ ⊢l:vl recf.x.e →→< recf.x.e, Γ > opinj-apply Γ ⊢l:vl e1 →→< λx.e, Γ1 > Γ ⊢l:vl e2 →→ v2 (x, v2) ⊕ Γ1 ⊢l:vl e →→ v Γ ⊢l:vl e1 e2 →→ v opinj-apply-rec Γ ⊢l:vl e1 →→ v1 v1 =< recf.x.e, Γ1 > Γ ⊢l:vl e2 →→ v2 (f, v1) ⊕ (x, v2) ⊕ Γ1 ⊢l:vl e →→ v Γ ⊢l:vl e1 e2 →→ v opinj-if-true Γ ⊢l:vl e →→ true Γ ⊢l:vl e1 →→ v1 Γ ⊢l:vl if e then e1 else e2 →→ v1 opinj-if-false Γ ⊢l:vl e →→ f alse Γ ⊢l:vl e2 →→ v2 Γ ⊢l:vl if e then e1 else e2 →→ v2 opinj-match Γ ⊢l:vl e →→ v v, p ⊢p Γp Γp ⊕ Γ ⊢l:vl e1 →→ v1 Γ ⊢l:vl match e with p → e1 | x → e2 →→ v1 opinj-match-var Γ ⊢l:vl e →→ v v, p ⊢p ⊥ (x, v) ⊕ Γ ⊢l:vl e2 →→ v2 Γ ⊢l:vl match e with p → e1 | x → e2 →→ v2 opinj-constr-0 Γ ⊢l:vl C →→ C opinj-constr-1 Γ ⊢l:vl e →→ v Γ ⊢l:vl D(e) →→ D(v) opinj-couple Γ ⊢l:vl e1 →→ v1 Γ ⊢l:vl e2 →→ v2 Γ ⊢l:vl (e1, e2) →→ (v1, v2) opinj-letin Γ ⊢l:vl e1 →→ v1 (x, v1) ⊕ Γ ⊢l:vl e2 →→ v2 Γ ⊢l:vl let x = e1 in e2 →→ v2 Figure 2.4 – Sémantique opérationnelle avec injection : règles d’inférence identiques à la sémantique usuelle opinj-annot-same Γ ⊢l:vl l : e →→ vl opinj-annot-other Γ ⊢l:vl e →→ v l ̸= l ′ Γ ⊢l:vl l ′ : e →→ v Figure 2.5 – Sémantique opérationnelle avec injection : règles d’inférence spécifiques ignorée. On notera qu’une injection (évaluation d’une sous-expression annotée par le label sur lequel on fait l’injection) termine toujours. En effet, la sous-expression n’est pas évaluée et sa valeur (qu’elle existe ou non) est remplacée par la valeur injectée. Les règles identiques à la sémantique opérationnelle usuelle sont réunies sur la figure 2.4. Les deux règles spécifiques à la sémantique opérationnelle avec injection se trouvent sur la figure 2.5. 502.5. SÉMANTIQUE OPÉRATIONNELLE AVEC INJECTION 2.5.2 Correction 2.5.2.1 Énoncé informel du théorème Comme nous l’avons dit plus haut, la sémantique opérationnelle avec injection vient introduire la notion d’injection en remplaçant une règle de la sémantique opérationnelle usuelle par deux nouvelles règles d’inférence. Il convient de vérifier qu’en ce qui concerne les programmes non-annotés, la sémantique opérationnelle avec injection fournit exactement les mêmes résultats que la sémantique opérationnelle. En ce qui concerne la sémantique de la notion d’injection (les deux nouvelles règles d’inférence), il n’y a pas de propriété de correction à vérifier puisque ces deux règles d’inférences constituent notre définition de la notion d’injection. Cependant, il y a une propriété intéressante concernant la notion d’injection : si un label n’apparaît pas dans le programme évalué, alors aucune injection sur ce label ne peut modifier la valeur du programme. Cette propriété engloble la propriété d’extension énoncée ci-dessus. En effet, l’évaluation avec injection d’un programme non-annoté est un cas particulier d’évaluation avec injection sur un label n’apparaissant pas dans le programme. Notre théorème de correction exprimera donc la propriété la plus forte. 2.5.2.2 Illustration par l’exemple Afin d’illustrer la notion d’injection et le fonctionnement de la sémantique opérationnelle avec injection, voici quelques exemples d’évaluation de programmes. Exemple 1 : programme non-annoté Sur les programmes non-annotés les résultats de la sémantique opérationnelle avec injection et de la sémantique opérationnelle sont les mêmes. Notons e le programme suivant : l e t t = 18 i n l e t f x = ( x−t , x+t ) i n 512.5. SÉMANTIQUE OPÉRATIONNELLE AVEC INJECTION f 32 Nous avons les deux jugements suivants : ⊢ e →→ (14, 50) ⊢l:vl e →→ (14, 50) (pour toute injection (l, vl)) Exemple 2 : programme annoté Maintenant voyons le cas du même programme en lui ajoutant une annotation (label l) sur une de ses sous-expressions. Notons e ′ le programme suivant : l e t t = 18 i n l e t f x = ( l : x−t , x+t ) i n f 32 Nous avons les deux jugements suivants : ⊢ e ′ →→ (14, 50) ⊢l:vl e ′ →→ (vl , 50) (pour toute valeur injectée vl) ⊢l:3 e ′ →→ (3, 50) (exemple en injectant la valeur 3) Lorsque la sous-expression f 32 est évaluée, le corps de la fonction est déplié. On évalue alors l’expression (l :x−t, x+t) dans l’environnement {(x, 32); (t, 18)}. La valeur vl est alors injectée lors de l’évaluation de la première composante du couple puisque celle-ci est annotée par le label l. La seconde composante du couple est évaluée de manière usuelle. Exemple 3 : programme annoté en plusieurs points Modifions de nouveau notre exemple pour annoter une seconde sous-expression. Notons e ′′ le programme suivant : l e t t = l ’ : 1 8 i n l e t f x = ( l : x−t , x+t ) i n 522.5. SÉMANTIQUE OPÉRATIONNELLE AVEC INJECTION f 32 Voyons le résultat pour une injection sur l, celui pour une injection sur l ′ : celui pour une injection sur un l ′′ n’apparaissant pas dans le programme : ⊢ e ′′ →→ (14, 50) ⊢l:vl e ′′ →→ (vl , 50) (pour toute valeur injectée vl) ⊢l ′ :vl ′ e ′′ →→ (14, 32 + vl ′) (pour toute valeur injectée vl ′) ⊢l ′ :5 e ′′ →→ (14, 37) (exemple en injectant la valeur 5) ⊢ l ′′ →→ vl ′′e ′′(14, 50) Exemple 4 : programme annoté dans l’environnement Un environnement d’évaluation peut contenir des points d’injection. En effet, un identificateur peut être lié à une fermeture (récursive ou non) dont le corps de la fonction contient des points d’injection. Prenons, dans l’exemple ci-dessus, l’évaluation de la sous-expression f 32. Cette évaluation se fait dans un environnement contenant une valeur pour t et une pour f. Ces valeurs dépendent de l’injection considérée. Dans le cas des fermetures, l’injection est retardée pour avoir lieu lors de l’application de la fonction. Par exemple, pour l’injection (l ′ , 7), l’environnement d’évaluation de l’expression f 32 est le suivant : Γ := (f, < λx.(l : x − t, x + t), {(t, 7)} >); (t, 7) On a donc le jugement d’évaluation suivant : ⊢l ′ :7 f 32 →→ (25, 39) Dans le cas de l’injection (l, 3), l’environnement d’évaluation de l’expression f 32 est le suivant : Γ := (f, < λx.(l : x − t, x + t), {(t, 18)} >); (t, 18) On évalue alors l’expression (l : x − t, x + t) dans l’environnement {(t, 18)} pour obtenir la valeur (3, 50). On a donc le jugement d’évaluation suivant : 532.5. SÉMANTIQUE OPÉRATIONNELLE AVEC INJECTION ⊢l:3 f 32 →→ (3, 50) 2.5.2.3 Énoncé formel du théorème Théorème 2.5.1. ∀(Γ, e, v), Γ ⊢ e →→ v ⇒ ∀l, ldna_in_eval(l, Γ, e) ⇒ ∀vl . Γ ⊢l:vl e →→ v Le prédicat ldna_in_eval(l, Γ, e) signifie que le label l n’apparaît pas lors de l’évaluation de e dans Γ. C’est à dire qu’il n’apparaît ni dans l’expression e, ni dans les valeurs dans Γ des identificateurs apparaissant dans e. Le prédicat ldna_in_val(l, v) signifie que le label l n’apparaît pas dans la valeur v. Les figures 2.6 et 2.7 fournissent la définition formelle de ces prédicats sous forme de règles d’inférence mutuellement récursives : 2.5.2.4 Preuve de correction La preuve de correction se fait par induction sur le jugement d’évaluation de la sémantique opérationnelle. Pour effectuer la preuve par induction, nous avons besoin de prouver une propriété un peu plus forte que celle énoncée ci-dessus. Nous modifions donc l’énoncé de la propriété à prouver, notre théorème de correction en sera une conséquence triviale. La propriété à prouver se formule alors : ∀(Γ, e, v), Γ ⊢ e →→ v ⇒ ∀l, ldna_in_eval(l, Γ, e) ⇒ ∀vl . Γ ⊢l:vl e →→ v ∧ ldna_in_val(l, v) Dans la majorité des cas, la preuve est triviale. Les cas intéressants sont : – le cas Annot 542.5. SÉMANTIQUE OPÉRATIONNELLE AVEC INJECTION ldna-e-num ldna_in_eval(l, Γ, n) ldna-e-constr-0 ldna_in_eval(l, Γ, C) ldna-e-constr-1 ldna_in_eval(l, Γ, e) ldna_in_eval(l, Γ, D(e)) ldna-e-ident ldna_in_val(l, Γ[x]) ldna_in_eval(l, Γ, x) ldna-e-ident-unbound ̸ ∃v, Γ[x] = v ldna_in_eval(l, Γ, x) ldna-e-abstr ldna_in_eval(l, Γ, e) ldna_in_eval(l, Γ, λx.e) ldna-e-abstr-rec ldna_in_eval(l, Γ, e) ldna_in_eval(l, Γ, recf.x.e) ldna-e-apply ldna_in_eval(l, Γ, e1) ldna_in_eval(l, Γ, e2) ldna_in_eval(l, Γ, e1 e2) ldna-e-if ldna_in_eval(l, Γ, e) ldna_in_eval(l, Γ, e1) ldna_in_eval(l, Γ, e2) ldna_in_eval(l, Γ, if e then e1 else e2) ldna-e-match ldna_in_eval(l, Γ, e) ldna_in_eval(l, Γ, e1) ldna_in_eval(l, Γ, e2) ldna_in_eval(l, Γ, match e with p → e1 | x → e2) ldna-e-annot l ̸= l ′ ldna_in_eval(l, Γ, e) ldna_in_eval(l, Γ, l : e) ldna-e-couple ldna_in_eval(l, Γ, e1) ldna_in_eval(l, Γ, e2) ldna_in_eval(l, Γ,(e1, e2)) ldna-e-letin ldna_in_eval(l, Γ, e1) ldna_in_eval(l, Γ, e2) ldna_in_eval(l, Γ, let x = e1 in e2) Figure 2.6 – Prédicat de non-apparition d’un label lors d’une évaluation ldna-v-num ldna_in_val(l, n) ldna-v-bool ldna_in_val(l, b) ldna-v-constr-0 ldna_in_val(l, C) ldna-v-constr-1 ldna_in_val(l, v) ldna_in_val(l, D(v)) ldna-v-couple ldna_in_val(l, v1) ldna_in_val(l, v2) ldna_in_val(l,(v1, v2)) ldna-v-closure ldna_in_eval(l, Γ, e) ldna_in_val(l, < λx.e, Γ >) ldna-v-closure-rec ldna_in_eval(l, Γ, e) ldna_in_val(l, < recf.x.e, Γ >) Figure 2.7 – Prédicat de non-apparition d’un label dans une valeur 552.6. IMPACT D’UNE INJECTION – les cas effectuant une liaison dans l’environnement (Letin, Match et Apply) – le cas Ident cas annot Pour le cas Annot, nous utilisons l’hypothèse que le label l n’apparaît pas dans l’expression évaluée. Dans ce cas, la règle de la sémantique opérationnelle avec injection est la même que celle de la sémantique opérationnelle (elle ignore l’annotation). cas des liaison Pour les cas effectuant une liaison dans l’environnement, nous avons besoin de savoir que le label n’apparaît pas dans la valeur liée pour appliquer notre hypothèse d’induction. Nous avons cette information grâce au renforcement de l’énoncé de notre théorème car toute valeur liée est issue d’une évaluation, donc puisque le label n’apparaît pas dans l’expression évaluée alors il n’apparaît pas dans la valeur résultat. Pour illustrer nos propos, prenons le cas du let-binding. Nous avons évalué la sous-expression liée e1 dans le même environnement que l’expression globale, donc nous savons par hypothèse d’induction que le label n’apparaît pas dans sa valeur. Cette information nous permet de prouver que le label n’apparaît pas dans l’environnement d’évaluation de la sous-expression e2, puisque la valeur ajoutée à l’environnement est précisément le résultat de l’évaluation de e1. Nous pouvons donc appliquer également l’hypothèse d’induction sur la seconde prémisse de la règle du let-binding et conclure. cas ident La règle Ident de la sémantique opérationnelle avec injection s’applique de façon identique à celle de la sémantique opérationnelle. Le jugement de la sémantique opérationnelle avec injection est donc immédiat à trouver. On déduit que le label n’apparaît pas dans la valeur trouvée dans l’environnement à partir de l’hypothèse que le label n’apparaît pas lors de l’évaluation. 2.6 Impact d’une injection Maintenant que la notion d’injection a été clairement définie, nous pouvons aborder la notion d’impact. Cette dernière nous sera utile pour définir formellement la notion de dépendance. 562.7. DÉPENDANCES D’UNE EXPRESSION Une fois un programme annoté par des points d’injection, on se demande si ces points d’injection ont un « impact » sur l’évaluation du programme. Autrement dit, on souhaite déterminer si l’injection d’une valeur à un certain point d’injection va modifier le comportement du programme. Puisque nous nous limitons à l’analyse de programmes qui terminent, un changement de comportement peut prendre deux formes possibles. Suite à l’injection, l’évaluation peut terminer sur une valeur différente ou bien ne pas terminer. 2.6.1 Impact sur la terminaison Si le programme considéré a une valeur par la sémantique opérationnelle mais qu’il n’a pas de valeur par la sémantique avec injection pour une injection particulière (l, vl), alors on dit que cette injection a un impact sur la terminaison de l’évaluation du programme. On dira également que ce point d’injection (représenté par le label l) a un impact sur la terminaison du programme puisqu’il existe une injection sur ce label ayant un impact sur la terminaison du programme. 2.6.2 Impact sur la valeur Si le programme considéré a une valeur par la sémantique opérationnelle et qu’il a une valeur différente par la sémantique avec injection pour une injection particulière (l, vl), alors on dit que cette injection a un impact sur la valeur du programme. On dira également que ce point d’injection (représenté par le label l) a un impact sur la valeur du programme puisqu’il existe une injection sur ce label ayant un impact sur la valeur du programme. 2.7 Dépendances d’une expression On distingue deux types de dépendances distincts, issus des deux types d’impact pré- sentés plus haut : les dépendances de terminaison et les dépendances de valeur. 572.7. DÉPENDANCES D’UNE EXPRESSION 2.7.1 Dépendances de terminaison La terminaison de l’évaluation d’un programme dépend d’un point d’injection (repré- senté par un label) s’il existe une injection sur ce label ayant un impact sur la terminaison de l’évaluation. On dit alors que ce label fait partie des t-dépendances de ce programme (dans un environnement donné). Lors de l’analyse d’un programme, le résultat de l’analyse contiendra un ensemble de labels représentant l’ensemble des t-dépendances du programme. 2.7.2 Dépendances de valeur La valeur résultant de l’évaluation d’un programme dépend d’un point d’injection (représenté par un label) si il existe une injection sur ce label ayant un impact sur la valeur de l’évaluation. On dit alors que ce label fait partie des v-dépendances de ce programme (dans un environnement donné). Certains labels peuvent avoir un impact uniquement sur une partie de la valeur. Dans ce cas, on voudrait savoir le plus précisément possible quelle partie de la valeur dépend de quel label. Lors de l’analyse d’un programme, le résultat de l’analyse devra contenir une valeur structurée dont chaque sous-terme peut être annoté par l’ensemble de ses v-dépendances. 2.7.3 Illustration par l’exemple Considérons le programme suivant (noté e) : l e t c = l : t r u e i n l e t r e c f x = match x with | ( a , b ) −> i f a then b e l s e f x i n f ( c , l ’ : 17 ) Ce programme termine lors de son évaluation par la sémantique opérationnelle sur la valeur 17. On a le jugement suivant : ⊢ e →→ 17 582.7. DÉPENDANCES D’UNE EXPRESSION Un label n’apparaissant pas dans le programme Un label l ′′ n’apparaissant pas dans le programme e ne peut pas faire partie de ses dépendances (que ce soit ses t-dépendances ou ses v-dépendances) puisqu’aucune injection sur l ′′ n’affecte le comportement du programme. On a le jugement suivant : ⊢l ′′:vl ′′ e →→ 17 (pour toute valeur injectée vl ′′) Le label l Le point d’injection représenté par le label l fait partie des t-dépendances du programme. En effet, il existe une injection (l, f alse) ayant un impact sur la terminaison du programme. La sémantique avec injection ne fournit aucune valeur pour l’évaluation de e avec l’injection (l, f alse). ̸ ∃v. ⊢l:false e →→ v Le label l ′ Le point d’injection représenté par le label l ′ fait partie des v-dépendances du programme. En effet, il existe une injection (l ′ , 18) ayant un impact sur la valeur du programme. La sémantique avec injection fournit une valeur (i.e. 18) pour l’évaluation de e avec l’injection (l ′ , 18) et cette valeur est différente de la valeur opérationnelle du programme (i.e. 17). ⊢l ′ :18 e →→ 18 Par contre, le label l ′ ne fait pas partie des t-dépendances du programme puisque pour toute injection sur l ′ , le programme termine : ⊢l ′ :vl ′ e →→ vl ′ (pour toute valeur injectée vl ′). 592.7. DÉPENDANCES D’UNE EXPRESSION 60Chapitre 3 Analyse dynamique 3.1 Introduction Ce chapitre a pour but de présenter une analyse dynamique des dépendances d’un programme et sa preuve de correction, étape préliminaire à la définition et à la preuve d’une analyse statique présentée dans le chapitre suivant. Notre analyse dynamique est appelée sémantique instrumentée et se trouve présentée à la fin de ce chapitre (cf. section 3.5). Pour présenter cette analyse et en prouver sa correction, nous devons tout d’abord introduire deux sémantiques intermédiaires : la sémantique avec injection dans un t-environnement sur-instrumenté (cf. section 3.3) et la sémantique sur-instrumentée (cf. section 3.4). Ces deux sémantiques intermédiaires permettent de faire le lien entre la notion de dépendance et la sémantique dynamique étape par étape. Chaque étape a son importance dans la simplification de la preuve de correction. La figure 3.1 présente une vue globale des différentes sémantiques intermédaires entre la sémantique opérationnelle avec injection et la sémantique instrumentée. L’analyse dynamique (sémantique instrumentée) a pour but d’analyser le programme au cours de son évaluation. Le résultat fourni est la valeur du programme (au sens de la sémantique opérationnelle) sur laquelle on ajoute des annotations de dépendance. Chaque sous-terme de la valeur contient ses propres annotations pour savoir avec précision quelles parties de la valeur dépendent de tel label et quelles parties n’en dépendent pas. Si on 613.1. INTRODUCTION Sémantique opérationnelle avec injection : Sémantique opérationnelle avec injection dans t-environnement sur-instrumenté : Sémantique sur-instrumentée : Sémantique instrumentée : Les flèches correspondent à des fonctions injectives entre les ensembles de valeurs ou entre les ensembles d'environnements pour visualiser les pertes de précision et pertes de généralité. Figure 3.1 – Sémantiques intermédiaires pour l’analyse dynamique La sémantique avec injection donne la même valeur si on instancie l'environnement avant l'évaluation. En instanciant la valeur sur-instrumentée, on peut obtenir la valeur (ou l'absence de valeur) du programme pour n'importe quelle injection. Il existe une valeur sur-instrumentée pour le programme telle que sa valeur instrumentée est obtenue en supprimant les fonctions d'impact dans la valeur sur-instrumentée. Ce diagramme montre le lien entre l'analyse dynamique d'un programme (sémantique instrumentée) et la notion d'injection (sémantique opérationnelle avec injection). On peut ainsi visualiser l’enchaînement des preuves de correction des 3 sémantiques présentées dans ce chapitre. Figure 3.2 – Enchaînement des preuves des sémantiques intermédiaires pour l’analyse dynamique 623.2. SUR-INSTRUMENTATION DES VALEURS supprime toutes les annotations de dépendance, on obtient exactement la même valeur qu’après l’évaluation du programme par la sémantique opérationnelle. Les annotations ajoutées par l’analyse dynamique correspondent aux dépendances du programme (c’est-à-dire l’ensemble des labels ayant un impact sur l’évaluation de ce programme, comme défini plus haut (cf. section 2.7)). Nous prouvons formellement cette af- firmation par le théorème de correction de l’analyse dynamique (cf. section 3.6.4). Pour arriver à cette preuve, nous prouvons successivement la correction de la sémantique avec injection dans un t-environnement sur-instrumenté (cf. section 3.3.2), puis la correction de la sémantique sur-instrumentée (cf. section 3.4.2) et enfin la correction de la sémantique instrumentée (cf. section 3.5.3). Les propriétés de correction de ces trois sémantiques s’enchaînent pour obtenir le théorème de correction de l’analyse dynamique. La figure 3.2 illustre l’enchaînement de ces propriétés de correction. Dans ce chapitre, nous présenterons tout d’abord la sur-instrumentation des valeurs (cf. section 3.2) qui nous permettra d’introduire la première sémantique intermédiaire pour l’analyse dynamique : la sémantique opérationnelle avec injection dans un t-environnement sur-instrumenté (cf. section 3.3). Nous présenterons ensuite la seconde sémantique intermédiaire : la sémantique sur-instrumentée (cf. section 3.4). Enfin nous pourrons présenter l’analyse dynamique elle-même : la sémantique instrumentée (cf. section 3.5). La présentation de chaque sémantique sera accompagnée de l’énoncé de son théorème de correction par rapport à la sémantique précédente ainsi que d’une explication sur sa preuve. Nous terminerons ce chapitre avec l’énoncé du théorème global de correction de l’analyse dynamique et une explication sur sa preuve utilisant la propriété de correction de chaque sémantique par rapport à la sémantique précédente. 3.2 Sur-instrumentation des valeurs Jusqu’à maintenant, nous avons vu comment évaluer un programme à l’aide de la sémantique opérationnelle (cf. section 2.3) pour obtenir sa valeur opérationnelle (également appelée valeur de référence du programme). Nous avons également vu comment évaluer un programme à l’aide de la sémantique avec injection (cf. section 2.5) pour obtenir sa valeur 633.2. SUR-INSTRUMENTATION DES VALEURS après injection, pour n’importe quelle injection possible. Un même programme possède donc plusieurs valeurs : sa valeur de référence (obtenue par la sémantique opérationnelle) et une valeur après injection (ou une absence de valeur après injection) pour chaque injection possible. Nous souhaitons maintenant intégrer toutes ces informations sur un programme en un seul et unique terme appelé « valeur sur-instrumentée ». La valeur sur-instrumentée d’un programme permettra alors de retrouver, à l’aide d’un mécanisme d’instanciation, la valeur de référence de ce programme ainsi que la valeur (ou l’absence de valeur) de ce programme après n’importe quelle injection. Pour cela, nous allons annoter la valeur de référence du programme avec des informations de dépendance sur chaque sous-terme de celle-ci. 3.2.1 Valeurs Comme nous l’avons vu plus haut (cf. section 2.7), un programme possède des tdépendances (dépendances de terminaison) ainsi que des v-dépendances (dépendances de valeur). Lors de la sur-instrumentation des valeurs, nous associons à toute valeur (résultat de l’évaluation d’un programme) l’ensemble des t-dépendances du programme évalué. Ensuite, nous associons à chaque sous-terme de la valeur un ensemble de v-dépendances correspondant aux points d’injection ayant un impact sur ce sous-terme. Une t-valeur sur-instrumentée (notée tuoi) est composée d’un ensemble de t-dépendances tdoi et d’une v-valeur sur-instrumentée u oi . tuoi := [ tdoi | u oi ] Valeur avec annotation de t-dépendances Une v-valeur sur-instrumentée (notée u oi) est composée d’un v-ensemble de dépendances d oi et d’une valeur simple sur-instrumentée v oi . u oi := [ d oi | v oi ] Valeur avec annotation de v-dépendances Enfin, une valeur simple sur-instrumentée (notée v oi) est une valeur simple dont les 643.2. SUR-INSTRUMENTATION DES VALEURS sous-termes sont des v-valeurs sur-instrumentées u oi . v oi := n | b | C | D(u oi) | (u oi 1 , uoi 2 ) Constructeurs de données < λx.e, Γ oi > Fermeture < recf.x.e, Γ oi > Fermeture récursive 3.2.2 Ensembles de dépendances On distingue 2 types de dépendances : – les t-dépendances, concernant la terminaison de l’évaluation – les v-dépendances, concernant le résultat de l’évaluation Un ensemble de t-dépendances tdoi est un ensemble de labels dans lequel on associe à chaque label une t-fonction d’impact. Cette t-fonction d’impact est une fonction booléenne sur les valeurs nous indiquant pour chaque injection possible, si l’évaluation terminerait ou non (ce qui permet de modéliser un impact aboutissant soit à une boucle infinie, soit à une erreur d’exécution). Si une t-fonction d’impact retourne true, cela signifie qu’il y a non-terminaison, sinon, cela signifie que l’évaluation correspondante termine. tdoi := (l1, tf1); . . .(ln, tfn) t-dépendances tf : v → bool t-fonction d’impact Un ensemble de v-dépendances d oi est un ensemble de labels dans lequel on associe à chaque label une v-fonction d’impact. Cette v-fonction d’impact est une fonction des valeurs vers les valeurs nous indiquant pour chaque injection possible, quelle serait la valeur de l’évaluation avec injection. d oi := (l1, f1); . . .(ln, fn) v-dépendances f : v → v v-fonction d’impact 3.2.3 Environnements On distingue 2 types d’environnements sur-instrumentés : – les environnements dans lesquels on évalue les expressions – les environnements qui se trouvent encapsulés dans les valeurs (fermetures et les fermetures récursives). 653.2. SUR-INSTRUMENTATION DES VALEURS Dans le cas de l’évaluation d’une expression, on a besoin de connaître les t-dépendances de chaque identificateur. On utilisera donc la notion de t-environnement sur-instrumenté. En revanche, pour les environnements encapsulés dans une valeur (via une fermeture), il suffit de connaître les t-dépendances globales de cette valeur et il n’est pas nécessaire d’avoir les t-dépendances de chaque identificateur lié. Dans ce cas, on utilisera un v-environnement sur-instrumenté sans t-dépendances. En effet, pour qu’un tel environnement ait pu être créé et emprisonné dans une fermeture, il faut nécessairement que tout ce qui a précédé la création de cette fermeture ait terminé. Les valeurs présentes dans l’environnement proviennent de l’évaluation d’une expression de liaison (liaison let in, filtrage par motif ou application de fonction). Dans tous les cas possibles, lorsqu’on effectue la liaison d’une valeur dans l’environnement, les t-dépendances de cette valeur sont toujours ajoutés à la valeur de l’expression évaluée (cf. figure 3.5, règles oi-letin, oi-match, oi-match-var, oi-apply et oi-rec-apply). Un t-environnement sur-instrumenté permet de lier chaque identificateur à une t-valeur sur-instrumentée. tΓ oi := (x1, tuoi 1 ); . . . ; (xn, tuoi n ) t-environnement sur-instrumenté Un v-environnement sur-instrumenté permet de lier chaque identificateur à une v-valeur sur-instrumentée. Γ oi := (x1, uoi 1 ); . . . ; (xn, uoi n ) v-environnement sur-instrumenté 3.2.4 Valeur de référence d’une valeur sur-instrumentée Pour obtenir la valeur de référence d’une valeur sur-instrumentée, il suffit de retirer toutes les annotations de dépendance. La valeur de référence d’une valeur sur-instrumentée est notée ↑toi(tuoi). Formellement, l’extraction de la valeur de référence d’une t-valeur sur-instrumentée se définit comme suit : 663.2. SUR-INSTRUMENTATION DES VALEURS Valeur de référence d’une t-valeur sur-instrumentée : ↑toi( [ tdoi | u oi ]) := ↑oi(u oi) Valeur de référence d’une v-valeur sur-instrumentée : ↑oi( [ d oi | v oi ]) := ↑oi(v oi) Valeur de référence d’une valeur simple sur-instrumentée : ↑oi(n) := n ↑oi(b) := b ↑oi(C) := C ↑oi(D(u oi)) := D(↑oi(u oi)) ↑oi((u oi 1 , uoi 2 )) := (↑oi(u oi 1 ), ↑oi(u oi 2 )) ↑oi(< λx.e, Γ oi >) := < λx.e, ↑oi(Γoi) > ↑oi(< recf.x.e, Γ oi >) := < recf.x.e, ↑oi(Γoi) > Environnement de référence d’un t-environnement sur-instrumenté : ↑toi(∅) := ∅ ↑toi((x, tuoi) ⊕ tΓ oi) := (x, ↑toi(tuoi))⊕ ↑toi(tΓ oi) Environnement de référence d’un v-environnement sur-instrumenté : ↑oi(∅) := ∅ ↑oi((x, uoi) ⊕ Γ oi) := (x, ↑oi(u oi))⊕ ↑oi(Γoi) 3.2.5 Instanciation d’une valeur sur-instrumentée La valeur sur-instrumentée d’un programme contient toute l’information nécessaire pour savoir quelle serait le comportement du programme lors de son évaluation par la sémantique avec injection et ce pour n’importe quelle injection. Pour extraire la valeur après une injection (l, vl) depuis une valeur sur-instrumentée tuoi, on utilise une fonction d’instanciation notée ↓ l:vl(tuoi). Tout d’abord, il faut regarder si le label l appartient à l’ensemble des t-dépendances. Si c’est le cas, la t-fonction d’impact associée au label nous indique si le programme aurait ou non terminé sur une valeur lors de son évaluation par la sémantique avec injection. Si le label l n’appartient pas aux t-dépendances, alors le programme a forcément une valeur si on l’évalue à l’aide de la sémantique avec injection. 673.2. SUR-INSTRUMENTATION DES VALEURS Ensuite, pour chaque sous-terme de la valeur, on regarde si le label l appartient aux v-dépendances correspondant au sous-terme considéré. Si c’est le cas, alors la v-fonction d’impact nous indique la valeur du sous-terme pour l’injection considérée. Si le label l n’appartient pas aux v-dépendances du sous-terme, alors la valeur du sous-terme après injection correspond à sa valeur de référence dans laquelle on a instancié chaque sousterme. On remarquera que puisque les valeurs simples sur-instrumentées (v oi) ne contiennent que des valeurs sur-instrumentées (u oi), il n’est pas question de terminaison lors du parcours de ces sous-termes. Ceci est parfaitement justifié puisque la terminaison est une propriété globale pour une t-valeur sur-instrumentée. La fonction d’instanciation d’une t-valeur sur-instrumentée se définit formellement comme suit : Instanciation des t-valeurs sur-instrumentées : ↓ l:vl( [ tdoi | u oi ]) := ↓ l:vl(u oi) si atifl:vl (tdoi) = f alse La fonction d’instanciation des t-valeurs sur-instrumentées est une fonction partielle. Elle n’est définie que lorsque atifl:vl (tdoi) = f alse. Dans le cas où atifl:vl (tdoi) = true, on dit que la t-valeur sur-instrumentée n’est pas instanciable et on écrit ̸ ∃v. ↓ l:vl( [ tdoi | u oi ]) = v. Instanciation des valeurs sur-instrumentées : ↓ l:vl( [ d oi | v oi ]) := aifl:vl (d oi) si l ∈ d oi ↓ l:vl( [ d oi | v oi ]) := ↓ l:vl(v oi) si l ̸∈ d oi Instanciation des valeurs simples sur-instrumentées : ↓ l:vl(n) := n ↓ l:vl(b) := b ↓ l:vl(C) := C ↓ l:vl(D(u oi)) := D(↓ l:vl(u oi)) ↓ l:vl((u oi 1 , uoi 2 )) := (↓ l:vl(u oi 1 ), ↓ l:vl(u oi 2 )) ↓ l:vl(< λx.e, Γ oi >) := < λx.e, ↓ l:vl(Γoi) > ↓ l:vl(< recf.x.e, Γ oi >) := < recf.x.e, ↓ l:vl(Γoi) > 683.2. SUR-INSTRUMENTATION DES VALEURS Instanciation des environnements sur-instrumentés : ↓ l:vl({}) := {} ↓ l:vl((x, uoi) ⊕ Γ oi) := (x, ↓ l:vl(u oi))⊕ ↓l:vl(Γoi) Application des t-fonctions d’impact : atifl:vl ((l, tf oi);tdoi) := tf oi(vl) ∨ atifl:vl (tdoi) atifl:vl ((l ′ , tf oi);tdoi) := atifl:vl (tdoi) si l ′ ̸= l atifl:vl (∅) := f alse Application des fonctions d’impact : aifl:vl ((l, f oi); d oi) := f oi(vl) aifl:vl ((l ′ , f oi); d oi) := aifl:vl (d oi) si l ′ ̸= l 3.2.6 Conversion Compte tenu du nombre de notions similaires à propos des environnements et des valeurs, et pour éviter toute confusion, les conversions seront toujours explicites. Par exemple, la notation Γ oi désigne un environnement sur-instrumenté qui n’est pas forcément en relation avec le t-environnement sur-instrumenté tΓ oi. Lorsqu’il y a une relation entre deux environnements, celle-ci est exprimée explicitement à l’aide d’une fonction de conversion. Par exemple Γ oi =↑ oi toi(tΓ oi) exprime que l’environnement Γ oi est le résultat de l’application de la fonction de conversion ↑ oi toi(•) à l’environnement tΓ oi. Cette fonction convertit un t-environnement sur-instrumenté (resp. une t-valeur sur-instrumentée) en un v-environnement sur-instrumenté (resp. une v-valeur sur-instrumentée). 693.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ 3.3 Sémantique avec injection dans un t-environnement surinstrumenté La sémantique avec injection que nous avons présentée plus haut (cf. section 2.5) nous a permis de définir formellement la notion de dépendance vis-à-vis de laquelle nous pourrons prouver la correction de notre analyse. Nous avons également défini (cf. section 3.2) une manière d’annoter la valeur d’un programme avec des informations de dépendance de façon à intégrer en un seul et même terme le comportement du programme pour toute injection. Plus loin, nous définirons (cf. section 3.4) une sémantique permettant d’inférer une valeur sur-instrumentée pour tout programme dont l’évaluation de référence termine. Cette sémantique sur-instrumentée devra manipuler au sein de l’environnement d’évaluation des valeurs elles-mêmes sur-instrumentées (obtenues par l’évaluation d’un programme précédent ou spécifiées par l’utilisateur) et non des valeurs simples comme dans la sémantique opérationnelle. Afin de faciliter la preuve de correction de la sémantique sur-instrumentée, nous introduisons maintenant une extension de la sémantique avec injection. Cette extension donnera un sens à l’évaluation avec injection d’un programme dans un environnement sur-instrumenté. L’expression est évaluée dans un t-environnement sur-instrumenté, ce qui permet de spécifier pour chaque identificateur présent dans l’environnement, quelle aurait été sa valeur si on l’avait obtenue après telle ou telle injection. Le résultat de l’évaluation d’une expression par la sémantique avec injection dans un t-environnement sur-instrumenté est une valeur sans annotation, tout comme pour la sémantique opérationnelle avec injection ou pour la sémantique opérationnelle usuelle. Lorsque les annotations du t-environnement sur-instrumenté sont vides, alors la sémantique avec injection dans le t-environnement sur-instrumenté coïncide avec la sémantique avec injection dans son environnement de référence. 703.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ 3.3.1 Règles d’inférence Formellement, la sémantique avec injection dans un t-environnement sur-instrumenté prend la forme d’un jugement d’évaluation similaire à celui de la sémantique opérationnelle avec injection. On note le jugement d’évaluation de la manière suivante : tΓ oi ⊢l:vl e →→ v La seule différence par rapport à la sémantique opérationnelle avec injection est l’environnement d’évaluation. Dans la sémantique que nous définissons ici, l’environnement d’évaluation est un t-environnement sur-instrumenté. Il contient plus d’information que l’environnement d’évaluation de la sémantique opérationnelle avec injection. En effet dans l’environnement opérationnel, chaque identificateur est lié à une unique valeur. Celle-ci représente la valeur de l’identificateur quelque soit l’injection considérée. Par contre, dans un t-environnement sur-instrumenté, la valeur d’un identificateur dans l’environnement peut changer en fonction de l’injection considérée. Cette nouvelle sémantique est plus générale que la sémantique opérationnelle avec injection que nous avions définie pour introduire notre notion de dépendance. En utilisant la fonction injective ↑ toi(•) qui décore tout environnement opérationnel avec des annotations de dépendance vides, on obtient un plongement de l’ensemble des jugements de la sémantique opérationnelle avec injection vers l’ensemble des jugements de la sémantique avec injection dans un t-environnement sur-instrumenté. Ainsi lorsque nous prouverons la correction de la sémantique avec injection dans un tenvironnement sur-instrumenté, nous en déduirons trivialement la correction de la sémantique opérationnelle avec injection par une simple spécialisation du théorème de correction. De même lorsque nous prouverons la correction de la sémantique sur-instrumentée par rapport à la sémantique avec injection dans un t-environnement sur-instrumenté, nous en déduirons trivialement la correction de la sémantique sur-instrumentée par rapport à la sémantique opérationnelle avec injection. Remarque : de la même manière que la sémantique opérationnelle avec injection, la sémantique avec injection dans un t-environnement sur-instrumenté est paramétrée par le 713.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ label l sur lequel on effectue l’injection et par la valeur injectée vl . Ces paramètres sont notés en indice du jugement d’évaluation (⊢l:vl ). Bien que l’environnement d’évaluation contienne des annotations de dépendance, la sémantique avec injection ne fait qu’utiliser ces annotations. Cette sémantique n’a pas pour but de calculer des dépendances. Lors de l’évaluation d’un programme, elle ne produit aucune annotation. En particulier, lorsqu’une valeur est ajoutée à l’environnement, elle contient toujours des annotations vides, la valeur ajoutée n’étant utilisée que pour une injection particulière : l’injection se trouvant en paramètre du jugement d’évaluation. Les règles identiques à la sémantique opérationnelle usuelle sont réunies sur la figure 3.3. Les deux règles spécifiques à la sémantique opérationnelle avec injection se trouvent sur la figure 3.4. La majorité des règles sont identiques à la sémantique opérationnelle (modulo l’ajout d’annotations vides via la fonction ↑ toi(•) lors de la construction d’un environnement). En plus des deux règles d’évaluation d’une expression annotée, trois autres règles sont spéci- fiques à la sémantique avec injection dans un t-environnement sur-instrumenté. Lorsqu’on va chercher la valeur d’un identificateur dans l’environnement, on instancie la t-valeur surinstrumentée trouvée pour l’injection considérée. Lorsqu’on construit une fermeture (ou une fermeture récursive), on instancie le t-environnement sur-instrumenté pour l’injection considérée avant de l’encapsuler dans la fermeture. 3.3.2 Correction 3.3.2.1 Énoncé informel du théorème La sémantique avec injection dans un t-environnement sur-instrumenté permet de calculer la valeur d’un programme dans un t-environnement sur-instrumenté. Pour chaque identificateur, cet environnement contient une t-valeur sur-instrumentée. Cette valeur nous permet de connaître la valeur opérationnelle de l’identificateur pour n’importe quelle injection. En particulier, lorsque l’on évalue un programme pour une injection particulière (l, vl), sa valeur opérationnelle est l’instanciation de sa t-valeur sur-instrumentée pour l’in- 723.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ inj-num tΓ oi ⊢l:vl n →→ n inj-letin tΓ oi ⊢l:vl e1 →→ v1 (x, ↑ toi(v1)) ⊕ tΓ oi ⊢l:vl e2 →→ v2 tΓ oi ⊢l:vl let x = e1 in e2 →→ v2 inj-apply tΓ oi ⊢l:vl e1 →→< λx.e, Γ1 > tΓ oi ⊢l:vl e2 →→ v2 (x, ↑ toi(v2))⊕ ↑toi(Γ1) ⊢l:vl e →→ v tΓ oi ⊢l:vl e1 e2 →→ v inj-apply-rec tΓ oi ⊢l:vl e1 →→ v1 v1 =< recf.x.e, Γ1 > tΓ oi ⊢l:vl e2 →→ v2 (f, ↑ toi(v1)) ⊕ (x, ↑ toi(v2))⊕ ↑toi(Γ1) ⊢l:vl e →→ v tΓ oi ⊢l:vl e1 e2 →→ v inj-if-true tΓ oi ⊢l:vl e →→ true tΓ oi ⊢l:vl e1 →→ v1 tΓ oi ⊢l:vl if e then e1 else e2 →→ v1 inj-if-false tΓ oi ⊢l:vl e →→ f alse tΓ oi ⊢l:vl e2 →→ v2 tΓ oi ⊢l:vl if e then e1 else e2 →→ v2 inj-match tΓ oi ⊢l:vl e →→ v v, p ⊢p Γp ↑ toi(Γp) ⊕ tΓ oi ⊢l:vl e1 →→ v1 tΓ oi ⊢l:vl match e with p → e1 | x → e2 →→ v1 inj-match-var tΓ oi ⊢l:vl e →→ v v, p ⊢p ⊥ (x, ↑ toi(v)) ⊕ tΓ oi ⊢l:vl e2 →→ v2 tΓ oi ⊢l:vl match e with p → e1 | x → e2 →→ v2 inj-constr-0 tΓ oi ⊢l:vl C →→ C inj-constr-1 tΓ oi ⊢l:vl e →→ v tΓ oi ⊢l:vl D(e) →→ D(v) inj-couple tΓ oi ⊢l:vl e1 →→ v1 tΓ oi ⊢l:vl e2 →→ v2 tΓ oi ⊢l:vl (e1, e2) →→ (v1, v2) Figure 3.3 – Sémantique avec injection dans un t-environnement sur-instrumenté : règles d’inférence identiques à la sémantique usuelle inj-ident v =↓ l:vl (tΓ oi[x]) tΓ oi ⊢l:vl x →→ v inj-annot-same tΓ oi ⊢l:vl l : e →→ vl inj-annot-other tΓ oi ⊢l:vl e →→ v l ̸= l ′ tΓ oi ⊢l:vl l ′ : e →→ v inj-abstr tΓ oi ⊢l:vl λx.e →→< λx.e, ↓ l:vl (tΓ oi) > inj-abstr-rec tΓ oi ⊢l:vl recf.x.e →→< recf.x.e, ↓ l:vl (tΓ oi) > Figure 3.4 – Sémantique avec injection dans un t-environnement sur-instrumenté : règles d’inférence spécifiques 733.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ jection (l, vl). L’évaluation d’un programme dans un t-environnement sur-instrumenté pour une injection (l, vl) doit donc retourner la même valeur que son évaluation opérationnelle pour l’injection (l, vl) dans l’environnement opérationnel obtenu par instanciation du tenvironnement sur-instrumenté pour l’injection (l, vl). Dit d’une manière plus concise, on peut exprimer informellement le théorème de correction de notre sémantique avec injection dans un t-environnement sur-instrumenté ainsi : la sémantique avec injection doit être la même si on instancie ou non l’environnement avant l’évaluation. 3.3.2.2 Illustration par l’exemple Pour mieux appréhender la signification de ce théorème de correction, voici un exemple très simple d’évaluation de programme par la sémantique avec injection dans un t-environnement sur-instrumenté et dans son instanciation. Notons tΓ oi l’environnement suivant : tΓ oi ≡ (y, [ tdoi y | [ d oi y | 7 ] ]) ⊕ (z, [ tdoi z | [ d oi z | 4 ] ]) avec : tdoi y ≡ (l, tfl y ) où tfl y (v) vaut f alse si v est un entier positif, true sinon d oi y ≡ (l, fl y ) où f l y (v) vaut le double de v si v est un entier positif, 0 sinon tdoi z ≡ ∅ d oi z ≡ (l ′ , fl ′ z ) où f l ′ z (v) vaut 3 si v est le constructeur de donnée C, 5 sinon l ̸= l ′ Notons e le programme suivant : l e t f x = ( x , x+z ) i n f ( y + l ’ ’ : 2 ) avec l ̸= l ′′ et l ′ ̸= l ′′ Exemple 1 : impact sur la valeur d’un identificateur Considérons l’injection de la valeur 8 sur le label l. La sémantique avec injection dans le t-environnement sur-instrumenté nous donne le jugement suivant : 743.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ tΓ oi ⊢l:8 e →→ (18, 22) En instanciant le t-environnement sur-instrumenté, nous obtenons : ↓ l:8(tΓ oi) = (y, 16) ⊕ (z, 4) La sémantique opérationnelle avec injection dans cet environnement nous donne alors le même résultat que la sémantique avec injection dans le t-environnement sur-instrumenté : (y, 16) ⊕ (z, 4) ⊢l:8 e →→ (18, 22) Exemple 2 : impact sur la valeur d’un identificateur Considérons l’injection de la valeur C sur le label l ′ . La sémantique avec injection dans le t-environnement sur-instrumenté nous donne le jugement suivant : tΓ oi ⊢l ′ :C e →→ (9, 12) En instanciant le t-environnement sur-instrumenté, nous obtenons : ↓ l ′ :C(tΓ oi) = (y, 7) ⊕ (z, 3) La sémantique opérationnelle avec injection dans cet environnement nous donne alors le même résultat que la sémantique avec injection dans le t-environnement sur-instrumenté : (y, 7) ⊕ (z, 3) ⊢l ′ :C e →→ (9, 12) Exemple 3 : impact sur la terminaison d’un identificateur Considérons l’injection de la valeur −4 sur le label l. La t-valeur sur-instrumentée de l’identificateur y n’est pas instanciable. La sémantique avec injection dans le t-environnement sur-instrumenté ne fournit donc aucun jugement, puisque la sous-expression y ne trouve aucune règle d’inférence permettant de déduire un jugement d’évaluation. Le t-environnement sur-instrumenté n’est donc pas instanciable lui non plus. Nous sommes dans une situation où l’évaluation de la partie précédente du programme (celle qui a permi de construire l’environnement) ne termine pas pour l’injection considérée (l, −4). Il n’est alors pas possible de donner une valeur au programme par la sémantique opérationnelle avec l’injection (l, −4) puisque l’environnement d’évaluation correspondant 753.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ n’existe pas. Exemple 4 : impact sur un point d’injection sur programme Considérons l’injection de la valeur 17 sur le label l ′′. La sémantique avec injection dans le t-environnement sur-instrumenté nous donne le jugement suivant : tΓ oi ⊢l ′′:17 e →→ (24, 28) En instanciant le t-environnement sur-instrumenté, nous obtenons : ↓ l ′′:17(tΓ oi) = (y, 7) ⊕ (z, 4) La sémantique opérationnelle avec injection dans cet environnement nous donne alors le même résultat que la sémantique avec injection dans le t-environnement sur-instrumenté : (y, 7) ⊕ (z, 4) ⊢l ′′:17 e →→ (24, 28) 3.3.2.3 Énoncé formel du théorème Théorème 3.3.1 (Correction de la sémantique avec injection dans un t-environnement sur-instrumenté). ∀(tΓ oi , Γ, e, v, l, vl), tΓ oi ⊢l:vl e →→ v ⇒ Γ = ↓ l:vl(tΓ oi) ⇒ Γ ⊢l:vl e →→ v 3.3.2.4 Preuve de correction La preuve se fait trivialement par induction sur le jugement de la sémantique avec injection dans le t-environnement sur-instrumenté. Voici quelques explications sommaires sur quelques cas de la preuve : inj-abstr Dans le cas de l’évaluation d’une abstraction (récursive ou non), l’environnement encapsulé dans la fermeture est l’instanciation du t-environnement sur-instrumenté. La sémantique opérationnelle avec injection coïncide donc avec notre nouvelle sémantique. inj-ident Dans le cas de l’évaluation d’un identificateur, il suffit de remarquer que l’instanciation de la t-valeur sur-instrumentée d’un identificateur est la même que la valeur opé- rationnelle de cet identificateur dans l’instanciation du t-environnement sur-instrumenté. 763.3. SÉMANTIQUE AVEC INJECTION DANS UN T-ENVIRONNEMENT SUR-INSTRUMENTÉ inj-match Le cas du filtrage par motif est lui-aussi très simple. Supposons que nous avons un jugement de la forme suivante : inj-match tΓ oi ⊢l:vl e →→ v v, p ⊢p Γp ↑ toi(Γp) ⊕ tΓ oi ⊢l:vl e1 →→ v1 tΓ oi ⊢l:vl match e with p → e1 | x → e2 →→ v1 Les hypothèses d’induction nous permettent de déduire ces jugements : ↓ l:vl(tΓ oi) ⊢l:vl e →→ v et ↓ l:vl(↑ toi(Γp) ⊕ tΓ oi) ⊢l:vl e1 →→ v1 Enfin, puisque ↑ toi(•) n’ajoute que des dépendances vides, nous avons : ↓ l:vl(↑ toi(Γp) ⊕ tΓ oi) = Γp⊕ ↓l:vl(tΓ oi) Nous pouvons alors appliquer la règle de la sémantique opérationnelle avec injection permettant de conclure : opinj-match ↓ l:vl(tΓ oi) ⊢l:vl e →→ v v, p ⊢p Γp Γp⊕ ↓l:vl(tΓ oi) ⊢l:vl e1 →→ v1 ↓ l:vl(tΓ oi) ⊢l:vl match e with p → e1 | x → e2 →→ v1 773.4. SÉMANTIQUE SUR-INSTRUMENTÉE 3.4 Sémantique sur-instrumentée Ce chapitre a pour but de présenter une seconde sémantique intermédiaire utilisée pour la preuve de notre analyse dynamique : la sémantique sur-instrumentée. Cette sémantique n’est pas nécessaire pour définir l’analyse dynamique mais a pour but de simplifier et de faciliter la preuve de correction de cette dernière. Nous avons commencé par définir la sémantique opérationnelle avec injection qui donne un sens à la notion d’injection lors de l’évaluation d’un programme. Cette sémantique évalue un programme dans un environnement opérationnel pour une injection donnée. L’environnement d’évaluation doit alors contenir la valeur opérationnelle de chaque identificateur pour l’injection considérée. Si nous souhaitons considérer plusieurs injections, il nous faut évaluer le programme dans autant d’environnements, puisqu’à chaque injection correspond un certain environnement. Nous avons ensuite présenté la définition de la sémantique avec injection dans un tenvironnement sur-instrumenté. Cette sémantique évalue un programme dans un t-environnement sur-instrumenté pour une injection donnée. Ce t-environnement sur-instrumenté regroupe tous les environnements correspondant aux différentes injections. Si on souhaite considérer plusieurs injections, il faut toujours effectuer plusieurs évaluations du programme, mais toutes ces évaluations se font alors dans le même environnement. En effet, cette sémantique, bien qu’elle manipule des t-valeurs sur-instrumentées dans l’environnement d’évaluation, produit uniquement des valeurs simples au sens de la sémantique opérationnelle, tout comme la sémantique opérationnelle avec injection. La définition de cette sémantique est un premier pas permettant de faire le lien entre la notion d’injection et l’analyse dynamique. Dans cette section, nous allons définir la sémantique sur-instrumentée qui constitue un pas supplémentaire entre la notion d’injection et l’analyse dynamique. La sémantique surinstrumentée évalue un programme dans un t-environnement sur-instrumenté pour fournir une t-valeur sur-instrumentée. Cette fois-ci, nous avons la possibilité d’analyser un programme pour toutes les injections simultanément. En une seule évaluation, nous obtenons une t-valeur sur-instrumentée contenant toutes les informations nécessaires pour déduire 783.4. SÉMANTIQUE SUR-INSTRUMENTÉE le comportement du programme pour toute injection. On se rapproche ainsi de notre analyse dynamique. Cependant, la sémantique sur-instrumentée n’est pas calculable. C’est la contrepartie nécessaire pour avoir une sémantique donnant le comportement exact du programme pour toute injection. Lorsque nous définirons l’analyse dynamique, nous obtiendrons une sémantique calculable fournissant une approximation du comportement du programme pour toute injection. 3.4.1 Règles d’inférence La sémantique sur-instrumentée est représentée formellement par un jugement d’évaluation de la forme suivante : tΓ oi ⊢ oi e →→ tuoi où e est l’expression évaluée, tΓ oi le t-environnement sur-instrumenté dans lequel on effectue l’évaluation et tuoi la t-valeur sur-instrumentée résultat de l’évaluation. Les règles d’inférence (figure 3.5) sont en grande partie similaires aux règles habituelles de la sémantique opérationnelle. Cependant, trois d’entre elles sont notablement différentes : l’application de fonction (récursive ou non), la structure conditionnelle et le filtrage par motif. Nous allons détailler ci-dessous chacune des règles pour en donner les explications indispensables à leur compréhension. oi-num Le résultat de l’évaluation d’une constante entière est une t-valeur sur-instrumentée comprenant un ensemble de t-dépendances vide, un ensemble de v-dépendances vide et une valeur simple sur-instrumentée étant la constante elle-même. L’ensemble des t-dépendances est vide car aucune injection ne peut avoir d’impact sur la terminaison de l’évaluation de cette expression. L’ensemble des v-dépendances est vide car aucune injection ne peut avoir d’impact sur la valeur de cette expression. oi-ident L’évaluation d’un identificateur se fait de manière habituelle, en allant chercher la valeur correspondante dans l’environnement. Les dépendances de la t-valeur surinstrumentée retournée sont celles qui ont été enregistrées dans l’environnement pour cet 793.4. SÉMANTIQUE SUR-INSTRUMENTÉE oi-num tΓ oi ⊢ oi n →→ [ ∅ | [ ∅ | n ] ] oi-abstr tΓ oi ⊢ oi λx.e →→ [ ∅ | [ ∅ | < λx.e, ↑ oi toi(tΓ oi) > ] ] oi-ident tuoi = tΓ oi[x] tΓ oi ⊢ oi x →→ tuoi oi-abstr-rec tΓ oi ⊢ oi recf.x.e →→ [ ∅ | [ ∅ | < recf.x.e, ↑ oi toi(tΓ oi) > ] ] oi-apply tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ] tΓ oi ⊢ oi e2 →→ tuoi 2 tuoi 2 = [ tdoi 2 | u oi 2 ] (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) tΓ oi ⊢ oi e1 e2 →→ [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ] oi-rec-apply tΓ oi ⊢ oi e1 →→ tuoi 1 tuoi 1 = [ tdoi 1 | [ d oi 1 | < recf.x.e, Γ oi 1 > ] ] tΓ oi ⊢ oi e2 →→ tuoi 2 tuoi 2 = [ tdoi 2 | u oi 2 ] (f, tuoi 1 ) ⊕ (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) tΓ oi ⊢ oi e1 e2 →→ [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ] oi-letin tΓ oi ⊢ oi e1 →→ tuoi 1 tuoi 1 = [ tdoi 1 | u oi 1 ] (x, tuoi 1 ) ⊕ tΓ oi ⊢ oi e2 →→ [ tdoi 2 | u oi 2 ] tΓ oi ⊢ oi let x = e1 in e2 →→ [ tdoi 1 ∪ tdoi 2 | u oi 2 ] oi-if-true tΓ oi ⊢ oi e →→ [ tdoi | [ d oi | true ] ] tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | v oi 1 ] ] deps_spec_if(tΓ oi, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi if e then e1 else e2 →→ [ td′oi ∪ tdoi ∪ tdoi 1 | [ d ′oi ∪ d oi 1 | v oi 1 ] ] oi-if-false tΓ oi ⊢ oi e →→ [ tdoi | [ d oi | false ] ] tΓ oi ⊢ oi e2 →→ [ tdoi 2 | [ d oi 2 | v oi 2 ] ] deps_spec_if(tΓ oi, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi if e then e1 else e2 →→ [ td′oi ∪ tdoi ∪ tdoi 2 | [ d ′oi ∪ d oi 2 | v oi 2 ] ] oi-match tΓ oi ⊢ oi e →→ tuoi tuoi = [ tdoi | [ d oi | v oi ] ] tuoi, p ⊢ oi p tΓ oi p tΓ oi p ⊕ tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | v oi 1 ] ] deps_spec_match(tΓ oi, p, x, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi match e with p → e1 | x → e2 →→ [ td′oi ∪ tdoi ∪ tdoi 1 | [ d ′oi ∪ d oi 1 | v oi 1 ] ] oi-match-var tΓ oi ⊢ oi e →→ tuoi tuoi = [ tdoi | [ d oi | v oi ] ] tuoi, p ⊢ oi p ⊥ (x, tuoi) ⊕ tΓ oi ⊢ oi e2 →→ [ tdoi 2 | [ d oi 2 | v oi 2 ] ] deps_spec_match(tΓ oi, p, x, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi match e with p → e1 | x → e2 →→ [ td′oi ∪ tdoi ∪ tdoi 2 | [ d ′oi ∪ d oi 2 | v oi 2 ] ] oi-constr-0 tΓ oi ⊢ oi C →→ [ ∅ | [ ∅ | C ] ] oi-constr-1 tΓ oi ⊢ oi e →→ [ tdoi | u oi ] tΓ oi ⊢ oi D(e) →→ [ tdoi | [ ∅ | D(u oi) ] ] oi-couple tΓ oi ⊢ oi e1 →→ [ tdoi 1 | u oi 1 ] tΓ oi ⊢ oi e2 →→ [ tdoi 2 | u oi 2 ] tΓ oi ⊢ oi (e1, e2) →→ [ tdoi 1 ∪ tdoi 2 | [ ∅ | (u oi 1 , uoi 2 ) ] ] oi-annot tΓ oi ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] tΓ oi ⊢ oi l : e →→ [ tdoi | [ (l, fun x ⇒ x); d oi | v oi ] ] Figure 3.5 – Sémantique sur-instrumentée 803.4. SÉMANTIQUE SUR-INSTRUMENTÉE oim-constr-0 [ tdoi | [ d oi | C ] ], C ⊢ oi p {} oim-constr-1 [ tdoi | [ d oi | D(u oi) ] ], D(x) ⊢ oi p {(x, [ ∅ | u oi ])} oim-couple ( [ tdoi 1 | [ d oi 1 | u oi 1 ] ], [ tdoi 2 | [ d oi 2 | u oi 2 ] ]),(x1, x2) ⊢ oi p {(x1, [ ∅ | u oi 1 ]); (x2, [ ∅ | u oi 2 ])} oim-constr-0-not p ̸= C [ tdoi | [ d oi | C ] ], p ⊢ oi p ⊥ oim-constr-1-not p ̸= D′ (_) [ tdoi | [ d oi | D(u oi) ] ], p ⊢ oi p ⊥ oim-couple-not p ̸= (_, _) ( [ tdoi 1 | [ d oi 1 | u oi 1 ] ], [ tdoi 2 | [ d oi 2 | u oi 2 ] ]), p ⊢ oi p ⊥ Figure 3.6 – Sémantique sur-instrumentée : règles de filtrage ↑ oi toi( [ tdoi | u oi ]) = u oi ↑ oi toi({}) = {} ↑oi toi((x, tuoi) ⊕ tΓ oi) = (x, ↑ oi toi(tuoi)) ⊕ ↑oi toi(tΓ oi) Figure 3.7 – Valeurs sur-instrumentées : suppression des t-dépendances identificateur. oi-abstr Dans la t-valeur sur-instrumentée d’une abstraction, l’ensemble des t-dépendances est vide puisque l’évaluation d’une abstraction termine toujours (on ne considère que des injections pour lesquelles l’environnement est instanciable). Pour la même raison, les ensembles de t-dépendances présentes dans l’environnement sont ignorées. On les supprime à l’aide de la fonction ↑ oi toi(•) définie en figure 3.7. L’ensemble des v-dépendances est vide lui-aussi car l’évaluation d’une abstraction retourne toujours une fermeture contenant le même corps de fonction, seul l’environnement encapsulé peut différer d’une injection à l’autre. L’impact d’une injection sur l’environnement encapsulé dans la fermeture est déjà encodé à l’aide des v-dépendances des v-valeurs sur-instrumentées de l’environnement. Attention, le fait qu’aucune dépendance n’est introduite par la règle d’évaluation de l’abstraction ne signifie pas qu’une fermeture ne contient jamais de dépendances. D’une part, des dépendances peuvent être ajoutées à la fermeture lorsqu’elle est le résultat de l’évaluation d’une expression conditionnelle par exemple (cf. règle oi-if-true). D’autre 813.4. SÉMANTIQUE SUR-INSTRUMENTÉE ↑ toi oi (u oi) = [ ∅ | u oi ] ↑ toi oi ({}) = {} ↑toi oi ((x, uoi) ⊕ Γ oi) = (x, ↑ toi oi (u oi)) ⊕ ↑toi oi (Γoi) Figure 3.8 – Valeurs sur-instrumentées : ajout de t-dépendances part, il y a des v-dépendances présentes dans l’environnement encapsulé dans la fermeture. Celles-ci seront prises en compte lors de l’application de la fonction. Il est également intéressant de noter que le corps de la fonction peut contenir des points d’injection qui généreront probablement des dépendances lors de l’application de la fonction. oi-abstr-rec L’évaluation d’une abstraction récursive suit exactement le même modèle que l’évaluation d’une abstraction non-récursive. oi-apply La règle de l’application suit le schéma habituel de l’évaluation d’une application dans la sémantique opérationnelle. Elle évalue e1 et impose que sa valeur soit une fermeture, puis elle évalue e2 avant d’évaluer le corps de la fermeture dans son environnement en ajoutant à l’environnement une liaison pour la valeur de l’argument. Pour évaluer le corps de la fermeture, on doit transformer le v-environnement encapsulé en un t-environnement. On utilise alors la fonction ↑ toi oi (•) (définie en figure 3.8) qui ajoute des tdépendances vides. Cette approche est valide puisque les t-dépendances des identificateurs utilisés ont déjà été pris en compte. A ce schéma habituel vient s’ajouter le calcul des dépendances qui nécessite une spé- cification complexe. Compte tenu de la complexité de cette spécification, des explications détaillées sont données dans la section 3.4.1.1. oi-rec-apply La règle de l’application d’une fonction récursive est similaire à la règle de l’application d’une fonction non-récursive. Elle suit le schéma d’évaluation habituel en y greffant une spécification complexe des dépendances. Une explication détaillée de cette règle d’inférence est donnée en section 3.4.1.1. 823.4. SÉMANTIQUE SUR-INSTRUMENTÉE oi-letin L’évaluation d’une liaison (let in) se fait de la même manière que pour la sémantique opérationnelle. On commence par évaluer la sous-expression e1 pour obtenir sa valeur, puis on évalue la sous-expression e2 en ajoutant à l’environnement une liaison pour la valeur de e1. La t-valeur sur-instrumentée de l’expression évaluée est alors constituée d’un ensemble de t-dépendances et de la v-valeur sur-instrumentée de e2. L’ensemble des t-dépendances est la concaténation des t-dépendances des deux sous-expressions car si une des deux n’a pas de valeur, alors l’expression globale n’a pas de valeur non plus. oi-if-true et oi-if-false Pour l’évaluation d’une expression conditionnelle, on évalue tout d’abord la condition puis l’une des deux branches en fonction de la valeur (de référence) de la condition. On retrouve alors dans le résultat les t-dépendances de chacune des deux sous-expressions évaluées. On ajoute au résultat un ensemble de t-dépendance td′oi et un ensemble de v-dépendance d ′oi qui permettent de spécifier le comportement du programme pour les injections ayant un t-impact ou un v-impact sur l’évaluation de la condition. En effet, si un label a un impact sur l’évaluation de la condition, alors l’évaluation de l’expression conditionnelle ne passe pas forcément par la même branche. Pour de plus amples détails sur cette règle d’inférence, se référer à la section 3.4.1.1. oi-match et oi-match-var Dans la règle d’évaluation d’un filtrage par motif, on retrouve le même principe que dans la règle d’évaluation d’une expression conditionnelle. Une prémisse supplémentaire permet de déterminer la branche évaluée à l’aide d’un pré- dicat de filtrage prenant en paramètre la valeur (de référence) de l’expression filtrée et le motif de filtrage. On retrouve également les ensembles de dépendance td′oi et d ′oi permettant de spécifier le comportement du programme pour les injections ayant un impact sur l’évaluation de l’expression filtrée. De plus amples explications sur cette règle d’inférence sont données dans la section 3.4.1.1. oi-constr-0 L’évaluation d’un constructeur sans paramètre suit la même logique que l’évalution d’une constante numérique. Aucune t-dépendance, ni aucune v-dépendance n’est introduite. 833.4. SÉMANTIQUE SUR-INSTRUMENTÉE oi-constr-1 Pour l’évaluation d’un constructeur paramétré, on évalue la sous-expression en paramètre puis on applique le constructeur de donnée à sa v-valeur sur-instrumentée. L’ensemble des t-dépendances est exactement le même que pour la sous-expression, puisque l’évaluation d’une telle expression termine sur une valeur si et seulement si l’évaluation de la sous-expression termine sur une valeur. En ce qui concerne l’ensemble des v-dépendances, il est vide puisqu’aucune injection ne peut modifier le constructeur de tête de la valeur de l’expression. L’impact des injections sur les sous-termes de la valeur est déjà encodé dans la v-valeur sur-instrumentée de la sous-expression. oi-couple Pour l’évaluation d’un couple, on évalue les sous-expressions pour obtenir les deux sous-termes de la valeur sur-instrumentée finale que l’on réunit à l’aide du constructeur de couple. On concatène les t-dépendances des deux sous-expressions pour obtenir les t-dépendances de la t-valeur sur-instrumentée finale, puisque l’évaluation du couple termine sur une valeur si et seulement si l’évaluation des deux sous-expressions termine. L’ensemble des v-dépendances est vide pour la même raison que pour l’évaluation d’un constructeur paramétré : les v-dépendances correspondant à un impact sur un sous-terme de la valeur sont déjà présents dans les sous-termes de la valeur simple sur-instrumentée. oi-annot Une expression annotée a les mêmes dépendances que sa sous-expression auxquelles on ajoute le label de l’annotation que l’on associe à la fonction identité. Cette fonction indique que si on injecte une valeur sur un label lors de l’évaluation d’une expression annotée par ce même label, alors la valeur de l’expression annotée est directement la valeur injectée. C’est la seule règle qui permet d’introduire de nouvelles dépendances. Au moment de son introduction, une dépendance est toujours associée à la fonction identité. On peut remarquer également que l’on introduit uniquement des v-dépendances et qu’aucune règle ne permet d’introduire des t-dépendances sans que celles-ci ne soient déjà présentes dans les t-dépendances ou dans les v-dépendances d’une des prémisses. Ce sont les règles manipulant des dépendances indirectes (cf. section 3.4.1.1) qui permettent d’associer aux labels des fonctions autres que l’identité et ce sont elles également qui introduisent des t-dépendances 843.4. SÉMANTIQUE SUR-INSTRUMENTÉE à partir de v-dépendances des prémisses. Règles de filtrage Les règles de filtrage sont divisées en deux groupes de trois règles. Le premier regroupe les règles positives (une règle pour chaque forme de motif). Elles définissent un jugement de la forme tuoi, p ⊢ oi p Γ oi. Ce jugement indique que la t-valeur surinstrumentée tuoi correspond bien au motif de filtrage p et retourne un v-environnement sur-instrumentée Γ oi contenant les liaisons des identificateurs du motif avec les sous-termes de tuoi correspondants. Le second groupe réunit les règles négatives (une règle pour chaque forme de motif). Ces règles définissent un jugement de la forme tuoi, p ⊢ oi p ⊥. Ce jugement signifie que la t-valeur sur-instrumentée tuoi ne correspond pas au motif de filtrage p. 3.4.1.1 Explication des règles avec dépendances indirectes Dans la majorité des règles d’inférence, le calcul des t-dépendances (resp. des v-dépendances) se fait par simple concaténation des t-dépendances (resp. des v-dépendances) pré- sentes dans les prémisses. Les règles de l’évaluation de l’application, de l’expression conditionnelle et du filtrage par motif nécessitent, quant à elles, une spécification plus complexe des dépendances. Il n’est pas possible dans ces cas-là d’obtenir les dépendances du résultat par simple concaténation des dépendances des prémisses, ni par aucun autre procédé calculatoire. On utilise dans alors des fonctions de spécification des dépendances indirectes. Nous allons tout d’abord présenter en détail les règles d’inférence concernées, en expliquant de quelle manière les fonctions de spécification des dépendances indirectes sont utilisées. Ensuite nous reviendrons sur ces fonctions de spécification (cf. section 3.4.1.2) en leur donnant une définition formelle. oi-apply Rappellons tout d’abord la règle d’inférence que nous allons expliquer : 853.4. SÉMANTIQUE SUR-INSTRUMENTÉE oi-apply tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ] tΓ oi ⊢ oi e2 →→ tuoi 2 tuoi 2 = [ tdoi 2 | u oi 2 ] (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) tΓ oi ⊢ oi e1 e2 →→ [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ] La première prémisse correspond à l’évaluation de la sous-expression e1. Celle-ci doit obligatoirement avoir pour résultat une fermeture (notée < λx.e, Γ oi 1 >) pour que la règle de l’application non récursive s’applique. À cette fermeture sont associés un ensemble de t-dépendances (noté tdoi 1 ) et un ensemble de v-dépendances (noté d oi 1 ). La deuxième prémisse est l’évaluation de la sous-expression e2 qui retourne une t-valeur sur-instrumentée (notée tuoi 2 ) composée d’un ensemble de t-dépendances tdoi 2 et d’une vvaleur sur-instrumentée u oi 2 . La troisième prémisse évalue le corps de la fermeture dans l’environnement de la fermeture, en y ajoutant la liaison de la valeur du paramètre. Les composantes de la t-valeur sur-instrumentée résultant de cette évaluation sont notées tdoi , d oi et v oi. On notera que pour évaluer le corps de la fermeture, on ajoute des t-dépendances vides à l’environnement (fonction ↑ toi oi ()). Cette pratique est justifiée par le fait que les t-dépendances sont toujours regroupées en tête de la t-valeur sur-instrumentée. Les t-dépendances de l’évaluation de e1 sont donc toutes présentes dans l’ensemble tdoi 1 qui fait partie des t-dépendances du résultat final. Jusque là, nous avons suivi la manière habituelle d’évaluer une application de fonction dans un langage fonctionnel. En ce qui concerne la dernière prémisse, elle est propre à la sémantique sur-instrumentée car elle ne participe pas à l’élaboration de la valeur simple sur-instrumentée du résultat mais uniquement à ses dépendances. Plus précisément, elle spécifie les dépendances indirectes td′oi et d ′oi qui vont apparaître dans les dépendances du résultat final. Pour plus de détails concernant la spécification des dépendances indirectes, se reporter à la section 3.4.1.2. Intéressons-nous maintenant au résultat final : la t-valeur sur-instrumentée de l’appli- 863.4. SÉMANTIQUE SUR-INSTRUMENTÉE cation de e1 à e2. Celle-ci est composée d’un ensemble de t-dépendances, d’un ensemble de v-dépendances et d’une valeur simple sur-instrumentée. L’ensemble de ses t-dépendances est la concaténation des quatres ensembles de tdépendances suivants, obtenus dans les prémisses : – tdoi 1 et tdoi 2 car si l’évaluation de e1 ou celle de e2 ne termine pas, alors l’évaluation de l’application ne termine pas non plus, – tdoi car si l’évaluation du corps de la fonction ne termine pas, alors l’évaluation de l’application ne termine pas non plus, – et td′oi qui spécifie les cas de non-terminaison de l’application pour les labels dont dépend la valeur de l’expression e1. Notons que le fait d’ajouter l’ensemble tdoi en entier constitue une sur-approximation car il est inutile de considérer la non-terminaison de l’évaluation du corps de la fermeture de la valeur de référence de e1 lorsque le label de l’injection considérée a un impact sur la valeur de e1. En effet, dans un tel cas, la fonction appliquée n’est pas celle de la valeur de ré- férence mais celle spécifiée par d oi 1 . Il est donc possible que la sémantique sur-instrumentée indique qu’une certaine injection provoque une non-terminaison de l’évaluation de l’application en ce basant sur le fait que cette injection provoque une non-terminaison de l’évaluation du corps de la fonction de référence alors que le label en question apparaît dans d oi 1 et que l’évaluation de la fonction correspondante termine. Pour que la sémantique sur-instrumentée soit exacte, il ne faudrait ajouter que les labels de tdoi n’apparaissant pas dans d oi 1 . C’est une amélioration qu’il serait souhaitable d’envisager puisque la sémantique sur-instrumentée a pour objectif de spécifier de façon exacte le comportement du programme pour toute injection sans faire d’approximation. La même remarque pourrait être faite concernant les v-dépendances. On pourrait n’ajouter que les labels de d oi n’apparaissant pas dans d oi 1 . Cependant, la sémantique sur-instrumentée ne serait en rien affectée puisque dans les v-dépendances sur-instrumentées, seule la première occurence d’un label est prise en compte (cf. définition de la fonction d’instanciation aifl:vl (•)). Ces améliorations n’auraient cependant aucune influence concernant la précision de l’analyse dynamique ou de l’analyse statique car les ensembles de labels resteraient identiques. 873.4. SÉMANTIQUE SUR-INSTRUMENTÉE En ce qui concerne l’ensemble des v-dépendances du résultat final, il est constitué de la concaténation des deux ensembles de v-dépendances suivants : – d ′oi qui spécifie la valeur de l’application pour une injection sur un label dont dépend la valeur de l’expression e1, – et d oi car si un label n’est pas dans d ′oi (i.e. n’est pas dans d oi 1 ) alors la valeur de l’application pour une injection sur ce label est celle de l’évaluation du corps de la fermeture < λx.e, Γ oi 1 >. La valeur simple sur-instrumentée du résultat final est la valeur simple sur-instrumentée v oi issue de l’évaluation du corps de la fermeture. En effet, c’est elle qui détermine la valeur de l’application dans le cas d’une injection sur un label n’ayant pas d’impact sur la valeur de e1 et n’apparaissant pas dans d oi . oi-rec-apply oi-rec-apply tΓ oi ⊢ oi e1 →→ tuoi 1 tuoi 1 = [ tdoi 1 | [ d oi 1 | < recf.x.e, Γ oi 1 > ] ] tΓ oi ⊢ oi e2 →→ tuoi 2 tuoi 2 = [ tdoi 2 | u oi 2 ] (f, tuoi 1 ) ⊕ (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) tΓ oi ⊢ oi e1 e2 →→ [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ] La règle de l’application récursive suit le même schéma que la règle de l’application. Les deux premières prémisses correspondent à l’évaluation de e1. Elles donnent des noms aux différentes composantes de sa t-valeur sur-instrumentée et imposent que sa valeur de référence soit une fermeture récursive. Les deux prémisses suivantes décrivent l’évaluation de e2 et donnent des noms aux différentes composantes de sa t-valeur sur-instrumentée. La prémisse suivante est un jugement d’évaluation pour le corps de la fermeture de référence. Lors de cette évaluation, on ajoute dans l’environnement une liaison pour la fonction récursive et une seconde liaison pour l’argument de la fonction. On retrouve dans la dernière prémisse la fonction de spécification des dépendances indirectes deps_spec_apply utilisée de la même manière que dans la règle de l’application. Elle permet de spécifier les t-dépendances ainsi que les v-dépendances de l’application dans 883.4. SÉMANTIQUE SUR-INSTRUMENTÉE le cas où la fonction appliquée n’est pas la valeur de référence de e1, c’est-à-dire dans le cas où le label concerné a un impact sur la valeur de e1. On peut remarquer que le c’est la même fonction de spécification qui est utilisée dans la règle de l’application et dans celle de l’application récursive. Ceci s’explique par le fait que la valeur de l’application dans le cas d’une injection sur un label ayant un impact sur la valeur de e1 ne dépend pas de la valeur de référence de e1. De plus, une injection peut conduire à une fermeture récursive pour e1 alors que sa valeur de référence était une fermeture non-récursive ou inversement. Enfin, la t-valeur sur-instrumentée de l’application de e1 à e2 se construit de la même manière que dans le cas de l’application non-récursive. Les t-dépendances sont la concaté- nation des t-dépendances de e1, des t-dépendances de e2, de celles de l’évaluation du corps de la fermeture de référence et des t-dépendances indirectes. De même pour la v-valeur sur-instrumentée, il s’agit de la v-valeur sur-instrumentée issue de l’évaluation du corps de la fermeture de référence à laquelle on a ajouté les v-dépendances indirectes spécifiées par la dernière prémisse. oi-if-true oi-if-true tΓ oi ⊢ oi e →→ [ tdoi | [ d oi | true ] ] tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | v oi 1 ] ] deps_spec_if(tΓ oi, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi if e then e1 else e2 →→ [ td′oi ∪ tdoi ∪ tdoi 1 | [ d ′oi ∪ d oi 1 | v oi 1 ] ] Expliquons maintenant la règle d’inférence de l’évaluation sur-instrumentée d’une expression conditionnelle. Nous expliquons tout d’abord la règle oi-if-true qui correspond au cas où la valeur de référence de la condition est true. Nous verrons ensuite la règle oi-if-false qui donne la t-valeur sur-instrumentée de l’expression conditionnelle dans le cas où la valeur de référence est f alse. On peut remarquer qu’on ne donne pas de t-valeur sur-instrumentée aux expresssions conditionnelles dont la valeur de référence de la condition n’est ni true ni f alse. En effet, notre analyse dynamique ne permet d’analyser que des programmes qui terminent sur une valeur lorsqu’on les évalue sans injection. La première prémisse est un jugement d’évaluation pour la condition e. Elle impose que sa valeur de référence soit true pour que cette règle puisse s’appliquer. Les t-dépendances de la condition sont notées tdoi et ses v-dépendances sont notées d oi 893.4. SÉMANTIQUE SUR-INSTRUMENTÉE Puisque la valeur de référence de la condition est true, on doit évaluer la première branche e1 par la sémantique sur-instrumentée pour obtenir sa valeur de référence et ses dépendances. En effet, la valeur de référence de e1 est également la valeur de référence du résultat. Les v-dépendances de e1 permettent de spécifier la valeur de l’expression conditionnelle pour toute injection sur un label qui n’a pas d’impact sur la valeur de la condition, puisque dans tous ces cas, on passe dans la première branche. Dans le cas d’une injection sur un label ayant un impact sur la valeur de la condition (ie. un label présent dans d oi), c’est la dernière prémisse qui fournit les dépendances correspondantes à l’aide de la fonction de spécification des dépendances indirectes deps_spec_if. L’idée est que l’injection a pu modifier la valeur de la condition et donc qu’on ne passe plus forcément par la première branche. Le résultat de l’évaluation de l’expression conditionnelle est une t-valeur sur-instrumentée. Celle-ci est constituée de t-dépendances obtenues par l’union des t-dépendances indirectes et des t-dépendances directes (les t-dépendances des deux sous-expressions évaluées e et e1 et d’une v-valeur sur-instrumentée construite en ajoutant les v-dépendances indirectes à la v-valeur sur-instrumentée de e1. L’ordre des t-dépendances n’a pas d’importance puisque si l’une des sous-expressions évaluées n’a pas de valeur, alors l’expression complète n’a pas non plus de valeur. Par exemple, un label peut apparaître à la fois dans tdoi et dans tdoi 1 , associé respectivement à des t-fonctions d’impact tf oi et tf oi 1 . Pour une certaine injection vl , on peut avoir tf oi(vl) = true et tf oi 1 (vl) = f alse et pour une autre injection v ′ l , on peut avoir tf oi(vl) = f alse et tf oi 1 (vl) = true. Dans les deux cas, atifl:vl (tdoi∪tdoi 1 ) = true. Par contre, l’ordre des v-dépendances est important car la fonction aifl:vl (•) ne prend en compte que la première occurence du label. Ainsi, dans notre cas, les v-dépendances indirectes d ′oi sont placées avant les v-dépendances directes d oi 1 puisque ces dernières n’ont de signification que lorsqu’on est sûr que l’on passe par la première branche, c’est-à-dire dans le cas d’une injection sur un label n’apparaîssant pas dans d oi (donc dans d ′oi). 903.4. SÉMANTIQUE SUR-INSTRUMENTÉE oi-if-false oi-if-false tΓ oi ⊢ oi e →→ [ tdoi | [ d oi | f alse ] ] tΓ oi ⊢ oi e2 →→ [ tdoi 2 | [ d oi 2 | v oi 2 ] ] deps_spec_if(tΓ oi, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi if e then e1 else e2 →→ [ td′oi ∪ tdoi ∪ tdoi 2 | [ d ′oi ∪ d oi 2 | v oi 2 ] ] Cette règle est pratiquement identique à la précédente. La seule différence est que la valeur de référence de la condition e est f alse. C’est donc la sous-expression correspondant à la seconde branche qui est évaluée pour obtenir la valeur de référence de l’expression conditionnelle ainsi que les dépendances directes. Les dépendances indirectes sont quant à elles obtenues de la même manière que dans la règle précédente. On utilise pour cela la fonction de spécification deps_spec_if qui est appelée avec les mêmes arguments puisque les dépendances indirectes ne dépendent pas de la valeur de référence. oi-match oi-match tΓ oi ⊢ oi e →→ tuoi tuoi = [ tdoi | [ d oi | v oi ] ] tuoi, p ⊢ oi p tΓ oi p tΓ oi p ⊕ tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | v oi 1 ] ] deps_spec_match(tΓ oi, p, x, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi match e with p → e1 | x → e2 →→ [ td′oi ∪ tdoi ∪ tdoi 1 | [ d ′oi ∪ d oi 1 | v oi 1 ] ] L’évaluation des expressions de filtrage se définit également à l’aide de deux règles d’inférence. Nous allons expliquer la règle correspondant à une évaluation de référence passant dans la première branche. Nous verrons ensuite la règle correspondant à une évaluation de référence passant dans la seconde branche. La première prémisse est un jugement d’évaluation sur-instrumentée pour la sousexpression filtrée e. La t-valeur sur-instrumentée de la sous-expression e est notée tuoi . La deuxième prémisse permet de nommer les différentes composantes de tuoi. Les tdépendances sont notées tdoi, les v-dépendances d oi et la valeur simple sur-instrumentée est notée v oi . La troisième prémisse indique que la t-valeur sur-instrumentée de la sous-expression filtrée correspond au motif de filtrage p (cf. figure 3.6). Cette correspondance produit un environnement de liaison tΓ oi p qui associe à chaque identificateur présent dans le motif p 913.4. SÉMANTIQUE SUR-INSTRUMENTÉE une t-valeur sur-instrumentée issue du sous-terme correspondant dans tuoi. Ce jugement garantit que la valeur de référence extraite de tuoi correspond elle aussi au motif de filtrage p. La quatrième prémisse correspond à l’évaluation sur-instrumentée de la première branche du filtrage. On évalue cette branche-ci puisque l’évaluation de référence passe dans cette branche. Les composantes de la t-valeur sur-instrumentée de e1 sont notées tdoi 1 , d oi 1 et v oi 1 . La dernière prémisse est la spécification des dépendances indirectes du filtrage. Elle utilise la fonction de spécification deps_spec_match pour spécifier les t-dépendances indirectes td′oi et les v-dépendances indirectes d ′oi. Ces dépendances indirectes décrivent le comportement de l’évaluation de l’expression lorsque l’injection considérée est faite sur un label ayant un impact sur la valeur de la sous-expression filtrée. En effet, une modification de la valeur de la sous-expression filtrée provoquée par une injection peut entraîner un changement de branche. Enfin, le résultat de l’évaluation sur-instrumentée de l’expression de filtrage est la tvaleur sur-instrumentée correspondant à l’évaluation de la branche de référence à laquelle on a ajouté des dépendances. Les t-dépendances ajoutées sont les t-dépendances indirectes et les t-dépendances de la sous-expression filtrée. Les v-dépendances ajoutées sont uniquement les v-dépendances indirectes. oi-match-var oi-match-var tΓ oi ⊢ oi e →→ tuoi tuoi = [ tdoi | [ d oi | v oi ] ] tuoi, p ⊢ oi p ⊥ (x, tuoi) ⊕ tΓ oi ⊢ oi e2 →→ [ tdoi 2 | [ d oi 2 | v oi 2 ] ] deps_spec_match(tΓ oi, p, x, e1, e2, doi) = (td′oi, d′oi) tΓ oi ⊢ oi match e with p → e1 | x → e2 →→ [ td′oi ∪ tdoi ∪ tdoi 2 | [ d ′oi ∪ d oi 2 | v oi 2 ] ] Cette règle ressemble fortement à la règle correspondant à un passage dans la première branche pour l’évaluation de référence. Nous allons souligner uniquement les différences entre ces deux règles d’inférence. La troisième prémisse nous indique que cette règle n’est appliquée que lorsque la tvaleur sur-instrumentée de la sous-expression filtrée ne correspond pas au motif de filtrage. 923.4. SÉMANTIQUE SUR-INSTRUMENTÉE La correspondance (ou non-correspondance) d’une t-valeur sur-instrumentée à un motif est équivalente à la correspondance (resp. non-correspondance) de la valeur de référence à ce motif. C’est pourquoi cette règle correspond à l’évaluation sur-instrumentée d’un programme dont l’évaluation de référence passe par la seconde branche. La quatrième prémisse évalue la seconde branche au lieu de la première puisque c’est la seconde branche qui est évaluée lors de l’évaluation de référence. La spécification des dépendances indirectes est identique à la règle précédente. Enfin, le résultat est construit de la même manière, en ajoutant les t-dépendances indirectes, les t-dépendances de la sous-expression filtrée et les v-dépendances indirectes à la t-valeur sur-instrumentée résultat de l’évaluation de la branche empruntée par l’évaluation de référence. 3.4.1.2 Spécification des dépendances indirectes Dans les règles d’inférence les plus simples, les t-dépendances (resp. les v-dépendances) du résultat sont des dépendances directes, c’est-à-dire qu’elles sont la concaténation des t-dépendances (des v-dépendances) apparaissant dans les prémisses. C’est le cas des règles suivantes : oi-num, oi-ident, oi-abstr, oi-abstr-rec, oi-letin, oi-constr-0, oiconstr-1, et oi-couple. La règle oi-annot, quant à elle, introduit une v-dépendance supplémentaire. La vfonction d’impact associée à cette dépendance est toujours l’identité. C’est cette introduction de dépendance qui correspond à la sémantique de l’injection, telle que définie dans la sémantique opérationnelle avec injection et dans la sémantique avec injection dans un t-environnement sur-instrumenté. Le théorème de correction de la sémantique sur-instrumentée nous fournira une justification formelle de cette correspondance. En ce qui concerne les autres règles (oi-apply, oi-rec-apply, oi-if-true, oi-iffalse, oi-match, oi-match-var), on introduit une fonction de spécification des dépendances indirectes. Ces fonctions permettent de spécifier une partie des dépendances du résultat en fonction des dépendances des prémisses. 933.4. SÉMANTIQUE SUR-INSTRUMENTÉE Dépendances indirectes dans les règles de l’application deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) La fonction deps_spec_apply est utilisée dans les règles de l’application et de l’application récursive. Lorsqu’un label apparaît dans les v-dépendances de e1, toute injection sur ce label est susceptible de modifier la valeur de la fonction appliquée. La valeur de retour de l’application est donc également susceptible d’être modifiée, c’est pourquoi le label en question doit apparaître dans les v-dépendances du résultat. En ce qui concerne la v-fonction d’impact associée à un tel label, elle va dépendre de la fonction effectivement appliquée (valeur de e1 pour cette injection) ainsi que du paramètre effectivement passé à la fonction (valeur de e2 pour cette injection). Il se peut également que la fonction effectivement appliquée ne termine pas, le label en question doit donc apparaître dans les t-dépendances du résultat et la t-fonction d’impact associée doit permettre de déterminer pour chaque injection sur ce label si l’application de la fonction va effectivement terminer ou non. C’est le rôle de la fonction deps_spec_apply de spécifier ces dépendances indirectes. Elle prend en argument la t-valeur sur-instrumentée de e2 (notée tuoi 2 ) ainsi que l’ensemble des v-dépendances de e1 (noté d oi 1 ). Elle retourne les t-dépendances ainsi que les v-dépendances qu’il faut ajouter au résultat pour prendre en compte ces dépendances indirectes. Il est nécessaire de préciser que cette fonction n’est pas calculable, ce qui rend la sémantique sur-instrumentée elle-même non-calculable. Pour spécifier td′oi et d ′oi, on commence par définir leur liste de labels comme étant exactement la même que celle de d oi 1 (les v-dépendances de e1). Ensuite, il faut associer à chaque label de cette liste une t-fonction d’impact ou une v-fonction d’impact. La t-fonction d’impact (notée tf′ ) dans td′oi et la v-fonction d’impact (notée f ′ ) dans d ′oi associées à un certain label sont spécifiées à l’aide de la fonction deps_spec_apply_fun en fonction de la v-fonction d’impact correspondante dans d oi 1 et d’autres paramètres explicités ci-dessous. deps_spec_apply_fun(tuoi 2 , l, f1) = (tf′ , f′ ) On donne en paramètre de cette fonction la t-valeur sur-instrumentée de e2 (notée 943.4. SÉMANTIQUE SUR-INSTRUMENTÉE tuoi 2 ), un label présent dans d oi 1 (noté l) et la v-fonction d’impact associée à ce label dans d oi 1 (notée f1). Pour toute valeur vl , on va spécifier les valeurs de retour de tf′ et de f ′ en fonction de tuoi 2 (la t-valeur sur-instrumentée de e2) et de la valeur f1(vl). On distingue trois cas possibles : • f1(vl) est une fermeture < λx.e, Γ > Dans ce cas, les valeurs de retour de la t-fonction d’impact tf′ et de la v-fonction d’impact f ′ sont spécifiées par la formule suivante :  ∀(v2, v′ ). ↓ l:vl(tuoi 2 ) = v2 ∧ (x, ↑ toi(v2))⊕ ↑toi(Γ) ⊢l:vl e →→ v ′ ⇒ tf′ (vl) = f alse ∧ f ′ (vl) = v ′  ∧  ̸ ∃(v2, v′ ). ↓ l:vl(tuoi 2 ) = v2 ∧ (x, ↑ toi(v2))⊕ ↑toi(Γ) ⊢l:vl e →→ v ′  ⇒ tf′ (vl) = true ∧ f ′ (vl) = vdummy Cette formule signifie que si e2 a une valeur v2 pour cette injection (l’instanciation de tuoi 2 pour l’injection considérée retourne une valeur v2) et que l’application de la fermeture à cet argument termine sur une valeur v ′ , alors l’évaluation de l’application de e1 à e2 termine (tf′ (vl) = f alse) sur la valeur v ′ (f ′ (vl) = v ′ ). Dans le cas contraire (si tuoi 2 n’est pas instanciable ou si l’application de la fermeture ne termine pas) alors tf′ (vl) = true, ce qui signifie que l’évaluation de l’expression e1 e2 ne termine pas pour l’injection (l, vl), et f ′ (vl) = vdummy, ce qui signifie que la valeur de f ′ (vl) n’a aucune importance puisque tf′ (vl) = true. Remarque : une autre solution serait de définir les v-fonctions d’impact comme des fonctions partielles et de spécifier ici que f ′ n’a pas de valeur pour l’argument vl , cependant il n’est pas évident que cette solution soit préférable. C’est une piste qui reste à explorer. • f1(vl) est une fermeture récursive < recf.x.e, Γ > 953.4. SÉMANTIQUE SUR-INSTRUMENTÉE Dans ce cas, les valeurs de retour de la t-fonction d’impact tf′ et de la v-fonction d’impact f ′ sont spécifiées par la formule suivante :  ∀(v2, v′ ). ↓ l:vl(tuoi 2 ) = v2 ∧ (f, ↑ toi(< recf.x.e, Γ >)) ⊕ (x, ↑ toi(v2))⊕ ↑toi(Γ) ⊢l:vl e →→ v ′ ⇒ tf′ (vl) = f alse ∧ f ′ (vl) = v ′  ∧  ̸ ∃(v2, v′ ). ↓ l:vl(tuoi 2 ) = v2 ∧ (f, ↑ toi(< recf.x.e, Γ >)) ⊕ (x, ↑ toi(v2))⊕ ↑toi(Γ) ⊢l:vl e →→ v ′  ⇒ tf′ (vl) = true ∧ f ′ (vl) = vdummy Le principe est le même que dans le cas précédent sauf qu’on applique une fermeture récursive dans le cas présent. On peut remarquer que, comme d’habitude, dans le jugement d’application de la fermeture, on ajoute deux liaisons à l’environnement : une pour la fonction récursive et une pour l’argument. • f1(vl) est autre chose On a affaire à une erreur de type donc dans ce cas, la spécification est la suivante : tf′ (vl) = true ∧ f ′ (vl) = vdummy. Dépendances indirectes dans les règles de l’expression conditionnelle deps_spec_if(tΓ oi, e1, e2, doi) = (td′oi, d′oi) La fonction deps_spec_if est utilisée dans les deux règles d’évaluation de l’expression conditionnelle. Lorsqu’un label apparaît dans les v-dépendances de la condition e, toute injection sur ce label est susceptible de modifier la valeur de la condition et donc la valeur du résultat de l’évaluation de l’expression conditionnelle. Le label en question doit donc apparaître dans les v-dépendances du résultat. La v-fonction d’impact associée à ce label est alors spécifiée par deps_spec_if. Une injection sur un tel label peut également provoquer 963.4. SÉMANTIQUE SUR-INSTRUMENTÉE la non-terminaison de l’évaluation de la condition e ou bien la terminaison sur une valeur provoquant une erreur de type. C’est pourquoi le label doit également apparaître dans les t-dépendances de la t-valeur sur-instrumentée de l’expression conditionnelle. Ces dépendances indirectes (un impact sur l’évaluation de la condition e qui provoque soit un impact sur la valeur de l’expression conditionnelle soit un impact sur la terminaison de l’évaluation de l’expression conditionnelle) sont spécifiées à l’aide de la fonction deps_spec_if. Cette fonction de spécification prend quatre arguments : le t-environnement sur-instrumenté tΓ oi dans lequel on évalue l’expression conditionnelle, la sous-expression e1 de la première branche, à évaluer dans le cas où la condition est vraie, la sous-expression e2 de la seconde branche, à évaluer dans le cas où la condition est fausse et l’ensemble de v-dépendances d oi de l’expression testée. Le résultat de cette fonction est une spécification caractérisant de façon unique les t-dépendances ainsi que les v-dépendances qu’il est nécessaire d’ajouter à la t-valeur sur-instrumentée de l’expression conditionnelle pour prendre en compte les dépendances indirectes. La fonction de spécification deps_spec_if ainsi que ses deux homologues deps_spec_apply et deps_spec_match donnent uniquement une caractérisation des ensembles de dépendance td′oi et d ′oi sous forme de formule logique mais ne fournissent pas un procédé calculatoire permettant de construire les fonctions d’impact inclues dans td′oi et d ′oi . Pour spécifier td′oi et d ′oi, on commence par définir leur liste de labels comme étant exactement la même que celle de d oi (les v-dépendances de l’expression testée). Ensuite, il faut associer à chaque label de cette liste une t-fonction d’impact dans td′oi et une vfonction d’impact dans d ′oi. La t-fonction d’impact (notée tf′ ) et la v-fonction d’impact (notée f ′ ) associées à un certain label sont spécifiées en fonction de la v-fonction d’impact (notée f) correspondant à ce label dans d oi et d’autres paramètres explicités ci-dessous. Nous notons alors deps_spec_if_fun la fonction qui permet de spécifier les t-fonctions d’impact de td′oi et les v-fonctions d’impact de d ′oi . deps_spec_if_fun(tΓ oi, e1, e2, l, f) = (tf′ , f′ ) On donne en paramètre de cette fonction le t-environnement sur-instrumenté (noté 973.4. SÉMANTIQUE SUR-INSTRUMENTÉE tΓ oi) dans lequel on évalue l’expression, les deux sous-expressions e1 et e2 correspondant aux deux branches de l’expression conditionnelle, un label présent dans d oi (noté l) et la v-fonction d’impact associée à ce label dans d oi (notée f). Pour toute valeur vl , on va spécifier les valeurs de retour de tf′ et de f ′ . On distingue trois cas possibles : • f(vl) vaut true Dans ce cas, les valeurs de retour de la t-fonction d’impact tf′ et de la v-fonction d’impact f ′ sont spécifiées par la formule suivante :  ∀v1.tΓ oi ⊢l:vl e1 →→ v1 ⇒ tf′ (vl) = f alse ∧ f ′ (vl) = v1  ∧  ̸ ∃v1.tΓ oi ⊢l:vl e1 →→ v1  ⇒ tf′ (vl) = true ∧ f ′ (vl) = vdummy Cette spécification fait la distinction entre deux cas : soit il existe une valeur v1 telle que l’évaluation de e1 pour l’injection considérée termine sur v1, et dans ce cas l’évaluation de l’expression conditionnelle termine également pour cette même injection (tf′ (vl) = f alse) et sa valeur est v1 (f ′ (vl) = v1), soit il n’existe pas de jugement d’évaluation de e1 pour l’injection considérée, et dans ce cas l’évaluation de l’expression conditionnelle ne termine pas non plus sur une valeur (tf′ (vl) = true et f ′ (vl) = vdummy). • f(vl) vaut f alse Dans ce cas, les valeurs de retour de la t-fonction d’impact tf′ et de la v-fonction d’impact f ′ sont spécifiées par la formule suivante : 983.4. SÉMANTIQUE SUR-INSTRUMENTÉE  ∀v2.tΓ oi ⊢l:vl e2 →→ v2 ⇒ tf′ (vl) = f alse ∧ f ′ (vl) = v2  ∧  ̸ ∃v2.tΓ oi ⊢l:vl e2 →→ v2  ⇒ tf′ (vl) = true ∧ f ′ (vl) = vdummy L’injection considérée entraîne le passage dans la seconde branche de l’expression conditionnelle en donnant f alse pour valeur à la condition e. La spécification est donc la même que la précédente, sauf que l’on évalue e2 au lieu de e1. • f(vl) ne vaut ni true nif alse On a affaire à une erreur de type donc dans ce cas, la spécification est la suivante : tf′ (vl) = true ∧ f ′ (vl) = vdummy. Dépendances indirectes dans les règles du filtrage par motif deps_spec_match(tΓ oi, p, x, e1, e2, doi) = (td′oi, d′oi) La fonction deps_spec_match est utilisée dans les deux règles d’évaluation du filtrage par motif. Lorsqu’un label apparaît dans les v-dépendances de l’expression filtrée e, toute injection sur ce label est susceptible de modifier la branche choisie lors du filtrage et donc la valeur du résultat. Ce label doit donc apparaître dans les v-dépendances de la t-valeur sur-instrumentée résultant de l’évaluation du filtrage. Il doit également apparaître dans ses t-dépendances puisqu’une injection sur ce label peut entraîner la non-terminaison de l’évaluation de l’expression filtrée e ou bien provoquer une erreur de type. La fonction deps_spec_match donne une spécification permettant de caractériser de façon unique ces dépendances indirectes à ajouter aux t-dépendances et aux v-dépendances de la t-valeur sur-instrumentée du filtrage. Il est intéressant de remarquer que si l’injection considérée n’a d’impact que sur un sous-terme de la valeur de l’expression filtrée, alors ces dépendances ne sont pas des dé- pendances indirectes. Ces dépendances sont prises en compte dans le calcul de la t-valeur 993.4. SÉMANTIQUE SUR-INSTRUMENTÉE sur-instrumentée de la branche de référence. En effet, une injection sur un tel label ne peut pas avoir d’influence sur le choix de la branche et on évaluera donc la branche de référence. Ceci est dû à notre sémantique du filtrage qui ne discrimine que sur le constructeur de tête de la valeur filtrée. C’est une manière courante de définir le filtrage puisque tout filtrage à une profondeur arbitraire peut être réécrit en une imbrication de filtrages successifs. La fonction de spécification deps_spec_match prend quatre arguments : le t-environnement sur-instrumenté tΓ oi dans lequel on évalue l’expression de filtrage, le motif de filtrage de la première branche ainsi que l’identificateur de liaison de la seconde branche, la sous-expression e1 de la première branche, la sous-expression e2 de la seconde branche et l’ensemble de v-dépendances d oi de l’expression filtrée. Le résultat de cette fonction est une spécification permettant de caractériser sans ambiguïté les t-dépendances ainsi que les v-dépendances correspondant aux dépendances indirectes de l’expression de filtrage. Formellement, on ne peut pas exprimer la fonction deps_spec_match (ni ses homologues deps_spec_apply et deps_spec_if) sous forme d’une fonction calculable. On définit cependant le graphe correspondant à cette fonction à l’aide d’un prédicat. Comme pour les deux autres fonctions de spécification, on définit les listes de labels de td′oi et d ′oi comme étant exactement les mêmes que celle de d oi. Pour spécifier la tfonction d’impact (notée tf′ ) dans td′oi correspondant à un de ces labels, ou la v-fonction d’impact (notée f ′ ) dans d ′oi, on définit la fonction deps_spec_match_fun qui en donne une spécification dépendant entre autre de la v-fonction d’impact (notée f) correspondant à ce label dans d oi . deps_spec_match_fun(tΓ oi, p, x, e1, e2, l, f) = (tf′ , f′ ) Les paramètres de cette fonction sont : le t-environnement sur-instrumenté tΓ oi dans lequel on évalue l’expression, le motif p correspondant à la première branche, l’identificateur x permettant de lier la valeur filtrée dans la seconde branche, des deux sous-expressions e1 et e2 correspondant aux corps des branches, d’un label l présent dans d oi et de la v-fonction d’impact f correspondant à ce label dans d oi. Pour toute valeur vl , on va alors spécifier les valeurs de retour de tf′ et de f ′ . 1003.4. SÉMANTIQUE SUR-INSTRUMENTÉE On distingue trois cas possibles : • f(vl) correspond au motif de filtrage p (on a f(vl), p ⊢p Γp) Dans ce cas, les valeurs de retour de la t-fonction d’impact tf′ et de la v-fonction d’impact f ′ sont spécifiées par la formule suivante :  ∀v1. ↑ toi(Γp) ⊕ tΓ oi ⊢l:vl e1 →→ v1 ⇒ tf′ (vl) = f alse ∧ f ′ (vl) = v1  ∧  ̸ ∃v1. ↑ toi(Γp) ⊕ tΓ oi ⊢l:vl e1 →→ v1  ⇒ tf′ (vl) = true ∧ f ′ (vl) = vdummy On tente ici d’évaluer e1 dans l’environnement tΓ oi augmenté de l’environnement de liaison issu du filtrage Γp. On distingue alors deux cas : soit l’évaluation retourne une valeur, soit elle n’en retourne pas. Dans le premier cas, l’évaluation du filtrage termine sur une valeur, ce qui est traduit par la formule tf′ (vl) = f alse et sa valeur est v1, ce qui est traduit par la formule f ′ (vl) = v1. On constate ici qu’il est impossible de définir la fonction de spécification sous forme de fonction calculable car elle nécessiterait une fonction calculable permettant de déterminer si l’évaluation de e1 termine ou non. Cette remarque est valable pour les trois fonctions de spécification. • f(vl) ne correspond pas au motif de filtrage p (on a f(vl), p ⊢p ⊥) Dans ce cas, les valeurs de retour de la t-fonction d’impact tf′ et de la v-fonction d’impact f ′ sont spécifiées par la formule suivante :  ∀v2.(x, ↑ toi(f(vl))) ⊕ tΓ oi ⊢l:vl e2 →→ v2 ⇒ tf′ (vl) = f alse ∧ f ′ (vl) = v2  ∧ 1013.4. SÉMANTIQUE SUR-INSTRUMENTÉE  ̸ ∃v2.(x, ↑ toi(f(vl))) ⊕ tΓ oi ⊢l:vl e2 →→ v2  ⇒ tf′ (vl) = true ∧ f ′ (vl) = vdummy Si la valeur de l’expression filtrée ne correspond pas au motif, on évalue alors la seconde branche du filtrage. Si l’évaluation de cette seconde branche termine sur une valeur v2, alors on a la spécification suivante : tf′ (vl) = f alse ∧ f ′ (vl) = v2. Si l’évaluation de e2 ne termine pas sur une valeur, alors la spécification qui s’applique est : tf′ (vl) = true ∧ f ′ (vl) = vdummy. • f(vl) n’est pas une valeur filtrable Ce cas correspond à une erreur de type. La spécification est donc la suivante : tf′ (vl) = true ∧ f ′ (vl) = vdummy. 3.4.2 Correction 3.4.2.1 Énoncé informel du théorème La sémantique sur-instrumentée permet de simuler en une seule évaluation toutes les évaluations avec injection possibles. En effet, le résultat de l’évaluation d’un programme par cette sémantique est une t-valeur sur-instrumentée contenant la valeur de référence du programme ainsi que, en puissance, la valeur du programme pour toute évaluation avec injection. Pour extraire la valeur du programme pour une injection donnée, il suffit d’instancier la t-valeur sur-instrumentée. Si l’instanciation retourne une valeur, alors nous pouvons être sûrs que l’évaluation de ce programme par la sémantique avec injection termine pour l’injection considérée et que la valeur retournée est la même que l’instanciation de la t-valeur sur-instrumentée. Le théorème auquel nous nous intéressons exprime le lien qu’il doit y avoir entre la sémantique sur-instrumentée et la sémantique avec injection dans un t-environnement surinstrumenté. En combinant ce résultat avec le théorème de correction de la sémantique avec injection dans un t-environnement sur-instrumenté et le théorème de correction de 1023.4. SÉMANTIQUE SUR-INSTRUMENTÉE la sémantique opérationnelle avec injection, il sera possible de déduire que si un label n’apparaît pas dans la t-valeur sur-instrumentée d’un programme alors ce label n’a pas d’impact sur l’évaluation du programme. Cependant, cette propriété ne nous intéresse pas en elle-même car il n’est pas possible en pratique d’analyser un programme avec la sémantique sur-instrumentée. On prouvera cette propriété sur la sémantique instrumentée qui constitue notre analyse dynamique. 3.4.2.2 Illustration par l’exemple Pour se rendre compte concrètement de la signification du théorème de correction de la sémantique sur-instrumentée, nous illustrons ici par quelques exemples le lien entre la sémantique sur-instrumentée et la sémantique avec injection dans un t-environnement surinstrumenté. Exemple 1 : évaluation d’un couple Notons e1 le programme suivant : (3, l :7) Considérons maintenant le jugement d’évaluation de ce programme par la sémantique sur-instrumentée dans le t-environnement sur-instrumenté vide (son arbre de dérivation est donné en figure 3.9) : ∅ ⊢oi e1 →→ tuoi avec tuoi = [ ∅ | [ ∅ | ( [ ∅ | 3 ], [ (l, id) | 7 ]) ] ] où id représente la fonction identité. Donnons des noms aux différentes composantes de tuoi : tuoi = [ tdoi | [ d oi | ( [ d oi 1 | 3 ], [ (l, f2) | 7 ]) ] ] L’instanciation de tuoi retourne toujours une valeur puisque son ensemble de t-dépendances tdoi est vide. L’ensemble de v-dépendances d oi est vide lui aussi, ce qui indique que pour toute injection, l’instanciation de tuoi aura toujours une structure de couple. L’ensemble des v-dépendances de la première composante du couple d oi 1 est également vide, donc pour toute injection, la première composante du couple est la valeur 3. En ce 1033.4. SÉMANTIQUE SUR-INSTRUMENTÉE qui concerne l’ensemble des v-dépendances de la seconde composante du couple, il contient un unique label l et sa v-fonction d’impact associée f2. Si on instancie tuoi pour une injection sur un label autre que l, on obtiendra un couple dont la seconde composante est spécifiée par f2. Si on instancie tuoi pour une injection sur le label l, alors le couple résultat aura pour seconde composante la valeur 7 qui est la valeur de référence de ce sous-terme. La fonction f2 est l’identité donc on a : ∀vl . ↓ l:vl(tuoi) = (3, vl) et ∀vl . ↓ l ′ :vl ′ (tuoi) = (3, 7) si l ̸= l ′ Maintenant, intéressons nous à l’évaluation de e1 par la sémantique avec injection dans le même t-environnement sur-instrumenté (l’environnement vide). La sémantique avec injection évalue le programme pour une injection donnée. Considérons une injection que nous noterons (l ′ , vl ′). La figure 3.10 présente l’arbre de dérivation du jugement d’évaluation de e1 par la sémantique avec injection dans le cas où l = l ′ . En réalité, il existe un tel arbre de dérivation pour chaque valeur de vl ′, cependant tous ces arbres de dérivation ont la même structure. Nous présentons donc un arbre d’évaluation paramétré par la valeur vl ′. Dans le cas ou l ̸= l ′ , tous les arbres d’évaluation ont eux aussi la même structure. La figure 3.11 présente donc un arbre d’évaluation paramétré par l’injection (l ′ , vl ′) dans le cas ou l ̸= l ′ . Nous obtenons les deux jugements paramétrés suivants, correspondant aux deux situations possibles : ∀vl ′.tΓ oi ⊢l:vl ′ (3, l : 7) →→ (3, vl ′) et ∀(l ′ , vl ′).tΓ oi ⊢l ′ :vl ′ (3, l : 7) →→ (3, 7) si l ̸= l ′ Nous pouvons alors constater que pour toute injection possible, l’instanciation de la t-valeur sur-instrumentée de e1 retourne bien la valeur retournée par l’évaluation de e1 via la sémantique avec injection. En outre, la sémantique avec injection termine toujours sur une valeur (car la t-valeur sur-instrumentée de e1 est instanciable pour toute injection). 1043.4. SÉMANTIQUE SUR-INSTRUMENTÉE oi-couple oi-num tΓ oi ⊢ oi 3 →→ [ ∅ | [ ∅ | 3 ] ] oi-annot oi-num tΓ oi ⊢ oi 7 →→ [ ∅ | [ ∅ | 7 ] ] tΓ oi ⊢ oi l : 7 →→ [ ∅ | [ (l, fun x ⇒ x) | 7 ] ] tΓ oi ⊢ oi (3, l : 7) →→ [ tdoi 1 ∪ tdoi 2 | [ ∅ | ( [ ∅ | 3 ], [ (l, fun x ⇒ x) | 7 ]) ] ] Figure 3.9 – Exemple 1 : arbre de dérivation du jugement d’évaluation sur-instrumentée inj-couple inj-num tΓ oi ⊢l:vl ′ 3 →→ 3 inj-annot-same tΓ oi ⊢l:vl ′ l : 7 →→ vl ′ tΓ oi ⊢l:vl ′ (3, l : 7) →→ (3, vl ′) Figure 3.10 – Exemple 1 : arbre de dérivation du jugement d’évaluation avec injection si l = l ′ inj-couple inj-num tΓ oi ⊢l ′ :vl ′ 3 →→ 3 inj-annot-other inj-num tΓ oi ⊢l ′ :vl ′ 7 →→ 7 l ′ ̸= l tΓ oi ⊢l ′ :vl ′ l : 7 →→ 7 tΓ oi ⊢l ′ :vl ′ (3, l : 7) →→ (3, 7) Figure 3.11 – Exemple 1 : arbre de dérivation du jugement d’évaluation avec injection si l ̸= l ′ 1053.4. SÉMANTIQUE SUR-INSTRUMENTÉE Exemple 2 : liaison d’une fonction Notons e2 le programme suivant : l e t f o = match o with | Some ( x ) → x + l1 : 8 | none → d i n ( f ( Some 18 ) , l2 : 17 ) Remarque : Some est écrit avec une majuscule puisqu’il s’agit d’une constructeur de donnée alors que none est écrit sans majuscule puisqu’il s’agit d’une variable (cf. algèbre des valeurs sur-instrumentées). Nous souhaitons évaluer ce programme dans l’environnement suivant : tΓ oi 2 = (d, [ tdoi d | [ d oi d | 26 ] ]) avec tdoi d = (l3, tfd) et tdoi d = (l4, fd) Le jugement d’évaluation de e2 par la sémantique sur-instrumentée est : tΓ oi 2 ⊢ oi e2 →→ [ ∅ | [ ∅ | ( [ (l1, f1) | 26 ], [ (l2, id) | 17 ]) ] ] avec f1 = fun x ⇒ 18 + x Pour s’en convaincre, l’arbre d’évaluation de ce programme par la sémantique surinstrumentée est présenté dans les figures 3.12 et 3.13. Pour faciliter la lecture de l’arbre d’évaluation, on écrit à gauche de chaque règle le nom de la règle d’inférence appliquée et à droite le niveau de profondeur de la règle au sein de l’arbre d’évaluation du programme complet e2. Le niveau 0 correspond à la racine de l’arbre, le niveau 1 correspond à ses prémisses et ainsi de suite. Le sous-arbre d’évaluation du filtrage par motif est présenté dans une figure séparée pour plus de lisibilité. Notre exemple contient le symbole d’addition. Pour donner une sémantique à ce symbole, il serait nécessaire d’ajouter une règle d’inférence. Nous ne détaillons pas l’ajout de cette règle ici et cachons le sous-arbre d’évaluation correspondant. Il est possible de manipuler les nombres entiers dans notre langage sans avoir recours à l’ajout de règle supplémentaire. Pour cela, il suffit d’encoder les entiers à l’aide des constructeurs de données 1063.4. SÉMANTIQUE SUR-INSTRUMENTÉE et de définir les fonctions usuelles (addition, soustraction, division, multiplication, . . . ) directemement dans le langage. Cependant, nous avons choisi de ne pas utiliser cet encodage dans l’exemple afin de simplifier la présentation. Nous pouvons constater que les labels l3 et l4 n’apparaissent pas dans la t-valeur surinstrumentée de e2. En effet, puisque l’évaluation du filtrage passe toujours par la première branche la valeur de l’identificateur d dans l’environnement n’a pas d’importance. L’analyse donne une t-valeur sur-instrumentée à la sous-expression filtrée. L’ensemble des v-dépendances de cette t-valeur sur-instrumentée est vide donc il n’y a aucune dépendance indirecte lors de l’évaluation du filtrage (aucune injection susceptible de modifier le choix de la branche lors de l’évaluation). L’analyse « déduit » donc de cette manière que l’évaluation du filtrage passe toujours pas la première branche. Notons tuoi 2 la t-valeur sur-instrumentée de e2 dans tΓ oi 2 . L’instanciation de tuoi 2 ne dépend que des labels l1 et l2. Si on instancie pour une injection sur l1, seule la première composante du couple est modifiée. Si on instancie pour une injection sur l2, seule la seconde composante du couple est modifiée. Si on instancie pour une injection sur un autre label, on obtient la valeur de référence. Ces trois cas sont récapitulés ci-dessous : ↓ l1:vl1(tuoi 2 ) = (18 + vl1 , 17) ↓ l2:vl2(tuoi 2 ) = (26, vl2 ) ↓ l:vl(tuoi 2 ) = (26, 17) si l ̸= l1 et l ̸= l2 Intéressons-nous maintenant à l’évaluation de l’expression e2 à l’aide de la sémantique avec injection. En fonction du label sur lequel on effectue l’injection, l’arbre de dérivation du jugement de la sémantique avec injection change de forme. On distingue 3 cas, suivant qu’il s’agisse d’une injection sur le label l1, sur le label l2 ou sur un autre label. Pour une injection sur le label l1, l’arbre de dérivation est donné en deux parties, dans les figures 3.14 et 3.15. Pour une injection sur le label l2, l’arbre de dérivation est donné dans les figures 3.16 et 3.17. Pour une injection sur un label autre que l1 et l2, l’arbre de dérivation est donné en deux parties, dans les figures 3.18 et 3.19. On obtient les trois jugements suivants qui correspondent aux troix cas de l’instancia- 1073.4. SÉMANTIQUE SUR-INSTRUMENTÉE tion de la t-valeur sur-instrumentée du programme : tΓ oi 2 ⊢l1:vl1 e2 →→ (18 + vl1 , 17) tΓ oi 2 ⊢l2:vl2 e2 →→ (26, vl2 ) tΓ oi 2 ⊢l :vl e2 →→ (26, 17) si l ̸= l1 et l ̸= l2 On constate ainsi que pour tout injection, la sémantique avec injection termine sur une valeur qui est la même que l’instanciation de la t-valeur sur-instrumentée. Pour chaque arbre de dérivation, le niveau 0 correspond à l’évaluation de l’expression de liaison. On a ensuite deux sous-arbres au niveau 1 : un pour l’évaluation de la sousexpression liée et un autre pour l’évaluation du couple. La forme du premier sous-arbre est commune à tous les cas (l1, l2 ou autre). Par contre, la forme du second sous-arbre dépend du label sur lequel on effectue l’injection. Il s’agit de l’évaluation de la sous-expression couple. Cette évaluation comprend elle-même deux sous-arbres (de niveau 2), un pour chaque composante du couple. On peut constater que le sous-arbre de niveau 2 correspondant à l’évaluation de la première composante du couple est le même pour toute injection sur un label différent de l1 (c’est-à-dire pour tout label n’apparaissant pas dans l’ensemble des v-dépendances surinstrumentées de la première composante du couple). De même, le sous-arbre correspondant à la seconde composante du couple est le même pour toute injection sur un label différent de l2 (c’est-à-dire pour tout label n’apparaissant pas dans l’ensemble des v-dépendances sur-instrumentées de la seconde composante du couple). 1083.4. SÉMANTIQUE SUR-INSTRUMENTÉE oi-letin oi-abstr tΓ oi 2 ⊢ oi λo.match o with... →→ [ ∅ | [ ∅ | < λo.match o with..., ↑ oi toi(tΓ oi 2 ) > ] ] 1 oi-couple oi-apply oi-ident [ ∅ | [ ∅ | < λo.match o with..., ↑ oi toi(tΓ oi 2 ) > ] ] = ((f, ...) ⊕ tΓ oi 2 )[f] (f, ...) ⊕ tΓ oi 2 ⊢ oi f →→ [ ∅ | [ ∅ | < λo.match o with..., ↑ oi toi(tΓ oi 2 ) > ] ] 3 oi-constr-1 oi-num (f, ...) ⊕ tΓ oi 2 ⊢ oi 18 →→ [ ∅ | [ ∅ | 18 ] ] 4 (f, ...) ⊕ tΓ oi 2 ⊢ oi Some 18 →→ [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ] 3 oi-match . . . (figure 3.13) . . . (o, ...)⊕ ↑toi oi (↑ oi toi(tΓ oi 2 )) ⊢ oi match o with Some x → x + l1 : 8 | none → d →→ [ ∅ | [ (l1, fun x ⇒ 18 + x) | 26 ] ] 3 deps_spec_apply( [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ], ∅) = (∅, ∅) (f, ...) ⊕ tΓ oi 2 ⊢ oi f(Some 18) →→ [ ∅ | [ (l1, fun x ⇒ 18 + x) | 26 ] ] 2 oi-annot oi-num (f, ...) ⊕ tΓ oi 2 ⊢ oi 17 →→ [ ∅ | [ ∅ | 17 ] ] 3 (f, ...) ⊕ tΓ oi 2 ⊢ oi l2 : 17 →→ [ ∅ | [ (l2, fun x ⇒ x) | 17 ] ] 2 (f, ...) ⊕ tΓ oi 2 ⊢ oi (f(Some 18), l2 : 17) →→ [ ∅ | [ ∅ | ( [ (l1, fun x ⇒ 18 + x) | 26 ], [ (l2, fun x ⇒ x) | 17 ]) ] ] 1 tΓ oi 2 ⊢ oi e2 →→ [ ∅ | [ ∅ | ( [ (l1, fun x ⇒ 18 + x) | 26 ], [ (l2, fun x ⇒ x) | 17 ]) ] ] 0 Figure 3.12 – Exemple 2 : arbre de dérivation du jugement d’évaluation sur-instrumentée oi-match oi-ident [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ] = ((o, ...)⊕ ↑toi oi (↑ oi toi(tΓ oi 2 )))[o] (o, ...)⊕ ↑toi oi (↑ oi toi(tΓ oi 2 )) ⊢ oi o →→ [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ] 4 oim-constr-1 [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ], Some x ⊢ oi p (x, [ ∅ | 18 ]) 4 oi-plus . . . (x, [ ∅ | 18 ]) ⊕ (o, ...)⊕ ↑toi oi (↑ oi toi(tΓ oi 2 )) ⊢ oi x + l1 : 8 →→ [ ∅ | [ (l1, fun x ⇒ 18 + x) | 26 ] ] 4 deps_spec_match((o, ...)⊕ ↑toi oi (↑ oi toi(tΓ oi 2 )), Some x, none, x + l1 : 8, d, ∅) = (∅, ∅) (o, ...)⊕ ↑toi oi (↑ oi toi(tΓ oi 2 )) ⊢ oi match o with Some x → x + l1 : 8 | none → d →→ [ ∅ | [ (l1, fun x ⇒ 18 + x) | 26 ] ] 3 Figure 3.13 – Exemple 2 : sous-arbre de dérivation sur-instrumentée du filtrage 1093.4. SÉMANTIQUE SUR-INSTRUMENTÉE inj-letin inj-abstr tΓ oi 2 ⊢l1:vl1 λo.match o with... →→< λo.match o with..., (d, 26) > 1 inj-couple inj-apply inj-ident < λo.match o with..., (d, 26) >=↓ l1:vl1(((f, ...) ⊕ tΓ oi 2 )[f]) (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 f →→< λo.match o with..., (d, 26) > 3 inj-constr-1 inj-num (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 18 →→ 18 4 (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 Some 18 →→ Some 18 3 inj-match . . . (figure 3.15) . . . (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l1:vl1 match o with... →→ 18 + vl1 3 (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 f(Some 18) →→ 18 + vl1 2 inj-annot-other inj-num (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 17 →→ 17 3 l1 ̸= l2 (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 l2 : 17 →→ 17 2 (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 (f(Some 18), l2 : 17) →→ (18 + vl1 , 17) 1 tΓ oi 2 ⊢l1:vl1 e2 →→ (18 + vl1 , 17) 0 Figure 3.14 – Exemple 2 : arbre de dérivation du jugement d’évaluation avec injection sur l1 inj-match inj-ident Some 18 =↓ l1:vl1(↑ toi(Some 18)) (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l1:vl1 o →→ Some 18 4 opm-constr-1 Some 18, Some x ⊢p (x, 18) 4 inj-plus . . . (x, ↑ toi(18)) ⊕ (o, ↑ toi(v2)) ⊕ (d, 26) ⊢l1:vl1 x + l1 : 8 →→ 18 + vl1 4 (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l1:vl1 match o with Some x → x + l1 : 8 | none → d →→ 18 + vl1 3 Figure 3.15 – Exemple 2 : sous-arbre de dérivation du filtrage avec injection sur l1 1103.4. SÉMANTIQUE SUR-INSTRUMENTÉE inj-letin inj-abstr tΓ oi 2 ⊢l2:vl2 λo.match o with... →→< λo.match o with..., (d, 26) > 1 inj-couple inj-apply inj-ident < λo.match o with..., (d, 26) >=↓ l2:vl2(((f, ...) ⊕ tΓ oi 2 )[f]) (f, ...) ⊕ tΓ oi 2 ⊢l2:vl2 f →→< λo.match o with..., (d, 26) > 3 inj-constr-1 inj-num (f, ...) ⊕ tΓ oi 2 ⊢l2:vl2 18 →→ 18 4 (f, ...) ⊕ tΓ oi 2 ⊢l2:vl2 Some 18 →→ Some 18 3 inj-match . . . (figure 3.17) . . . (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l2:vl2 match o with... →→ 26 3 (f, ...) ⊕ tΓ oi 2 ⊢l2:vl2 f(Some 18) →→ 26 2 inj-annot-same (f, ...) ⊕ tΓ oi 2 ⊢l2:vl2 l2 : 17 →→ vl2 2 (f, ...) ⊕ tΓ oi 2 ⊢l2:vl2 (f(Some 18), l2 : 17) →→ (26, vl2 ) 1 tΓ oi 2 ⊢l2:vl2 e2 →→ (26, vl2 ) 0 Figure 3.16 – Exemple 2 : arbre de dérivation du jugement d’évaluation avec injection sur l2 inj-match inj-ident Some 18 =↓ l2:vl2(↑ toi(Some 18)) (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l2:vl2 o →→ Some 18 4 opm-constr-1 Some 18, Some x ⊢p (x, 18) 4 inj-plus . . . (x, ↑ toi(18)) ⊕ (o, ↑ toi(v2)) ⊕ (d, 26) ⊢l2:vl2 x + l2 : 8 →→ 26 4 (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l2:vl2 match o with Some x → x + l2 : 8 | none → d →→ 26 3 Figure 3.17 – Exemple 2 : sous-arbre de dérivation du filtrage avec injection sur l2 1113.4. SÉMANTIQUE SUR-INSTRUMENTÉE inj-letin inj-abstr tΓ oi 2 ⊢l:vl λo.match o with... →→< λo.match o with..., (d, 26) > 1 inj-couple inj-apply inj-ident < λo.match o with..., (d, 26) >=↓ l:vl(((f, ...) ⊕ tΓ oi 2 )[f]) (f, ...) ⊕ tΓ oi 2 ⊢l:vl f →→< λo.match o with..., (d, 26) > 3 inj-constr-1 inj-num (f, ...) ⊕ tΓ oi 2 ⊢l:vl 18 →→ 18 4 (f, ...) ⊕ tΓ oi 2 ⊢l:vl Some 18 →→ Some 18 3 inj-match . . . (figure 3.19) . . . (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l:vl match o with... →→ 26 3 (f, ...) ⊕ tΓ oi 2 ⊢l:vl f(Some 18) →→ 26 2 inj-annot-other inj-num (f, ...) ⊕ tΓ oi 2 ⊢l1:vl1 17 →→ 17 3 l1 ̸= l2 (f, ...) ⊕ tΓ oi 2 ⊢l:vl l : 17 →→ 17 2 (f, ...) ⊕ tΓ oi 2 ⊢l:vl (f(Some 18), l : 17) →→ (26, 17) 1 tΓ oi 2 ⊢l:vl e2 →→ (26, 17) 0 Figure 3.18 – Exemple 2 : arbre de dérivation du jugement d’évaluation avec injection sur l ̸∈ {l1, l2} inj-match inj-ident Some 18 =↓ l:vl(↑ toi(Some 18)) (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l:vl o →→ Some 18 4 opm-constr-1 Some 18, Some x ⊢p (x, 18) 4 inj-plus . . . (x, ↑ toi(18)) ⊕ (o, ↑ toi(v2)) ⊕ (d, 26) ⊢l:vl x + l : 8 →→ 26 4 (o, ↑ toi(Some 18)) ⊕ (d, 26) ⊢l:vl match o with Some x → x + l : 8 | none → d →→ 26 3 Figure 3.19 – Exemple 2 : sous-arbre de dérivation du filtrage avec injection sur l ̸∈ {l1, l2} 1123.4. SÉMANTIQUE SUR-INSTRUMENTÉE 3.4.2.3 Énoncé formel du théorème Théorème 3.4.1 (Correction de la sémantique sur-instrumentée). ∀(tΓ oi, e, tuoi).tΓ oi ⊢ oi e →→ tuoi ⇒ ∀(l, vl).∃Γ.Γ =↓ l:vl(tΓ oi) ⇒ ∀v.v =↓ l:vl(tuoi) ⇒ tΓ oi ⊢l:vl e →→ v Ce théorème énonce la correction de la sémantique sur-instrumentée. Si l’évaluation sur-instrumentée d’un programme e dans un environnement tΓ oi termine sur une valeur sur-instrumentée tuoi, alors cette valeur doit être correcte. Pour toute injection, si le tenvironnement sur-instrumenté tΓ oi et la t-valeur sur-instrumentée tuoi sont instanciables alors la sémantique avec injection termine sur une valeur et cette valeur est précisément l’instanciation de la t-valeur sur-instrumentée tuoi . L’hypothèse d’instanciabilité du t-environnement sur-instrumenté assure que l’injection considérée peut conduire à l’évaluation de l’expression e. Autrement dit, si le tenvironnement sur-instrumenté n’est pas instanciable, cela signifie que l’injection considérée provoquera une erreur avant même l’évaluation de l’expression e, par exemple lors de l’évaluation d’une autre partie du programme précédant celle de e. 3.4.2.4 Preuve de correction La preuve de correction se fait par induction sur le jugement d’évaluation de la sémantique sur-instrumentée. Cette induction implique la preuve de quinze cas : un pour chaque règle d’inférence. Nous allons présenter ici les grandes lignes de la preuve en détaillant quelques uns de ces cas. La preuve complète est disponible sous forme de code Coq. cas oi-num Ce cas est trivial. Dans ce cas, l’expression e n’est autre qu’une constante numérique n, la t-valeur sur-instrumentée tuoi ne contient que des dépendances vides et la valeur simple sur-instrumentée n. L’instanciation de tuoi est donc la valeur n et il suffit d’appliquer la règle d’inférence inj-num de la sémantique avec injection pour conclure. 1133.4. SÉMANTIQUE SUR-INSTRUMENTÉE cas oi-abstr À partir d’un jugement de la sémantique sur-instrumentée obtenu par la règle oi-abstr, d’une injection (l, vl) donnée, et de la valeur v obtenue par instanciation de la valeur sur-instrumentée pour l’injection (l, vl), on veut déduire le jugement correspondant pour la sémantique avec injection. Voici les trois hypothèses à notre disposition : oi-abstr tΓ oi ⊢ oi λx.e →→ [ ∅ | [ ∅ | < λx.e, ↑ oi toi(tΓ oi) > ] ] ∃Γ.Γ =↓ l:vl(tΓ oi) v =↓ l:vl( [ ∅ | [ ∅ | < λx.e, ↑ oi toi(tΓ oi) > ] ]) Puisque tΓ oi est instanciable pour l’injection (l, vl), alors on a : ↓ l:vl(↑ oi toi(tΓ oi)) =↓ l:vl(tΓ oi) En simplifiant la dernière hypothèse, on obtient : v =< λx.e, ↓ l:vl(↑ oi toi(tΓ oi)) >=< λx.e, ↓ l:vl(tΓ oi) > On peut alors conclure en appliquant la règle d’inférence suivante : inj-abstr tΓ oi ⊢l:vl λx.e →→< λx.e, ↓ l:vl(tΓ oi) > cas oi-apply À partir d’un jugement de la sémantique sur-instrumentée obtenu par la règle oi-apply, d’une injection (l, vl) donnée, de la valeur v obtenue par instanciation de la valeur sur-instrumentée pour l’injection (l, vl) et de trois hypothèses d’induction correspondant aux trois jugements de la sémantique sur-instrumentée présents dans les prémisses de la règle oi-apply, on veut déduire le jugement correspondant pour la sémantique avec injection. Voici les six hypothèses à notre disposition : oi-apply tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ] tΓ oi ⊢ oi e2 →→ tuoi 2 tuoi 2 = [ tdoi 2 | u oi 2 ] (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) tΓ oi ⊢ oi e1 e2 →→ [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ] 1143.4. SÉMANTIQUE SUR-INSTRUMENTÉE ∃Γ.Γ =↓ l:vl(tΓ oi) (HtΓ oi inst) v =↓ l:vl( [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ]) (Htuoi inst) ∃Γ.Γ =↓ l:vl(tΓ oi) ⇒ ∀v.v =↓ l:vl( [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ]) ⇒ tΓ oi ⊢l:vl e1 →→ v (IH1) ∃Γ.Γ =↓ l:vl(tΓ oi) ⇒ ∀v.v =↓ l:vl(tuoi 2 ) ⇒ tΓ oi ⊢l:vl e2 →→ v (IH2) ∃Γ.Γ =↓ l:vl((x, tuoi 2 )⊕ ↑toi oi (Γoi 1 )) ⇒ ∀v.v =↓ l:vl( [ tdoi | [ d oi | v oi ] ]) ⇒ (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢l:vl e →→ v (IH) Nous commençons par utiliser les hypothèses d’induction pour obtenir des jugements d’évaluation avec injection pour e1, pour e2 et pour le corps de la fonction appliquée. Nous pourrons ensuite appliquer la règle inj-apply pour conclure. Le corps de la fonction appliquée n’est pas le même selon que le label l sur lequel on fait l’injection appartient à d oi 1 ou non. En effet, si l ̸∈ d oi 1 alors la valeur de e1 est bien une fermeture dont le corps est l’expression e. Dans le cas contraire, si l ∈ d oi 1 alors la valeur de e1 est spécifiée par la v-fonction d’impact associée à l dans d oi 1 . Nous allons donc séparer la preuve en deux parties pour prouver ces deux cas séparément. Traitons tout d’abord le cas où l ̸∈ d oi 1 . Nous savons d’une part que l’environnement tΓ oi est instanciable, c’est exactement l’hypothèse HtΓ oi inst . D’autre part, l’hypothèse Htuoi inst nous apprend que la t-valeur sur-instrumentée ( [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ]) est instanciable. En effet, Htuoi inst implique atifl:vl (tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi) = f alse ce qui implique atifl:vl (tdoi 1 ) = f alse. Nous pouvons donc appliquer l’hypothèse d’induction IH1 : ↓ l:vl( [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ]) =< λx.e, ↓ l:vl(Γoi 1 ) > 1153.4. SÉMANTIQUE SUR-INSTRUMENTÉE tΓ oi ⊢l:vl e1 →→< λx.e, ↓ l:vl(Γoi 1 ) > Pour obtenir un jugement d’évaluation avec injection pour e2, nous procédons de la même manière que pour e1. L’instanciabilité de tΓ oi est fournie par HtΓ oi inst . En ce qui concerne l’instanciation de tuoi 2 , on déduit atifl:vl (tdoi 2 ) = f alse à partir de la propriété atifl:vl (tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi) = f alse qui a déjà été montrée. Puisque l’instanciabilité d’une t-valeur sur-instrumentée dépend uniquement de ses t-dépendances sur-instrumentées et de l’injection considérée (une v-valeur sur-instrumentée est toujours instanciable), tuoi 2 est instanciable en une certaine valeur v2. ↓ l:vl( [ tdoi 2 | u oi 2 ]) =↓ l:vl(u oi 2 ) = v2 tΓ oi ⊢l:vl e2 →→ v2 Pour obtenir un jugement d’évaluation avec injection pour e, nous procédons une troisième fois de la même manière. Il faut prouver l’instanciabilité de (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ). La t-valeur sur-instrumentée tuoi 2 est instanciable, comme on l’a vu plus haut. L’environnement ↑ toi oi (Γoi 1 ) est instanciable car Γ oi 1 est instanciable et la fonction ↑ toi oi (•) n’ajoute que des annotations vides. On a donc : ↓ l:vl((x, tuoi 2 )⊕ ↑toi oi (Γoi 1 )) = (x, v2)⊕ ↓l:vl(Γoi 1 ) Nous prouvons que [ tdoi | [ d oi | v oi ] ] s’instancie en v, en réduisant l’hypothèse Htuoi inst à l’aide du fait que atifl:vl (tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi) = f alse et de l’hypothèse l ̸∈ d oi 1 : v =↓ l:vl( [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ]) =↓ l:vl( [ d ′oi ∪ d oi | v oi ]) =↓ l:vl( [ d oi | v oi ]) =↓ l:vl( [ tdoi | [ d oi | v oi ] ]) Cette dernière égalité étant justifiée car nous déduisons atifl:vl (tdoi) = f alse de la propriété prouvée précédemment atifl:vl (tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi) = f alse. On obtient ainsi le jugement de la sémantique avec injection en appliquant l’hypothèse d’induction IH : (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢l:vl e →→ v 1163.4. SÉMANTIQUE SUR-INSTRUMENTÉE Avant de pouvoir appliquer la règle d’inférence de l’application, il nous faut appliquer la propriété suivante notée P inj inst (dont la preuve est fournie en Coq). Cette propriété énonce que si, pour un programme e, la sémantique avec injection dans un t-environnement surinstrumenté tΓ oi termine sur une valeur v alors elle termine sur la même valeur v dans l’environnement ↑ toi(↓ l:vl(Γoi)). Cette propriété est très proche du théorème de correction de la sémantique avec injection dans un t-environnement sur-instrumenté. ∀(tΓ oi, l, vl , e, v, Γ), tΓ oi ⊢l:vl e →→ v ⇒ Γ =↓ l:vl(tΓ oi) ⇒↑toi(Γ) ⊢l:vl e →→ v (P inj inst) On obtient alors : ↑ toi(↓ l:vl((x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ))) ⊢l:vl e →→ v (x, ↑ toi(↓ l:vl(tuoi 2 )))⊕ ↑toi(↓ l:vl(↑ toi oi (Γoi 1 ))) ⊢l:vl e →→ v (x, ↑ toi(v2))⊕ ↑toi(↓ l:vl(Γoi 1 )) ⊢l:vl e →→ v Les trois jugements d’évaluation avec injection ainsi obtenus pour e1, e2 et e nous servent alors de prémisses pour appliquer la règle de la sémantique avec injection injapply qui nous permet de conclure : inj-apply tΓ oi ⊢l:vl e1 →→< λx.e, ↓ l:vl(Γoi 1 ) > tΓ oi ⊢l:vl e2 →→ v2 (x, ↑ toi(v2))⊕ ↑toi(↓ l:vl(Γoi 1 )) ⊢l:vl e →→ v tΓ oi ⊢l:vl e1 e2 →→ v Supposons maintenant que l ∈ d oi 1 . On prouve ce cas-là par induction sur la structure de la liste d oi 1 . On élimine le premier cas, où d oi 1 est vide, puisque d oi 1 doit contenir au moins l. On suppose donc que d oi 1 est de la forme (l ′ , f1); d oi 1,tl pour une certaine v-fonction d’impact f1 et un certain v-ensemble de dépendances d oi 1,tl. Par la définition de deps_spec_apply, on déduit qu’il existe une tfonction d’impact tf′ et un t-ensemble de dépendances td′oi tl tels que td′oi = (l ′ , tf′ );td′oi tl 1173.4. SÉMANTIQUE SUR-INSTRUMENTÉE et qu’il existe une v-fonction d’impact f ′ et un v-ensemble de dépendances d ′oi tl tels que d ′oi = (l ′ , f′ ); d ′oi tl . On a alors les propriétés suivantes ainsi que l’hypothèse d’induction IHd1 : deps_spec_apply(tuoi 2 , doi 1,tl) = (td′oi tl , d′oi tl ) deps_spec_apply_fun(tuoi 2 , l′ , f1) = (tf′ , f′ ) ∀v.v =↓ l:vl( [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi tl | [ d ′oi tl ∪ d oi | v oi ] ]) ⇒ tΓ oi ⊢l:vl e1 e2 →→ v (IHd1 ) On distingue alors deux cas, l = l ′ ou l ̸= l ′ . Commençons par supposer l = l ′ . On a forcément la propriété tf′ (vl) = f alse. Si ce n’était pas le cas, la t-valeur surinstrumentée [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ] ne serait pas instanciable, ce qui contredirait l’hypothèse Htuoi inst. Puisque tf′ (vl) = f alse, il y a uniquement deux cas possibles pour la valeur de f1(vl) (cf. définition de deps_spec_apply_fun, section 3.4.1.2). • f1(vl) est une fermeture < λx′ .e′ , Γ1 > Dans ce cas, il existe deux valeurs v2 et v ′ avec les propriétés suivantes : ↓ l:vl(tuoi 2 ) = v2 (x ′ , ↑ toi(v2))⊕ ↑toi(Γ1) ⊢l:vl e ′ →→ v ′ f ′ (vl) = v ′ De plus, on prouve que v ′ = v en réduisant l’égalité de l’hypothèse Htuoi inst. En utilisant les hypothèses d’induction IH1 et IH2, on obtient les jugements d’évaluation avec injection suivants pour e1 et e2 : tΓ oi ⊢l:vl e1 →→< λx′ .e′ , Γ1 > tΓ oi ⊢l:vl e2 →→ v2 Il suffit donc d’appliquer la règle d’inférence inj-apply pour conclure : inj-apply tΓ oi ⊢l:vl e1 →→< λx′ .e′ , Γ1 > tΓ oi ⊢l:vl e2 →→ v2 (x ′ , ↑ toi(v2))⊕ ↑toi(Γ1) ⊢l:vl e ′ →→ v tΓ oi ⊢l:vl e1 e2 →→ v 1183.4. SÉMANTIQUE SUR-INSTRUMENTÉE • f1(vl) est une fermeture récursive < recf ′ .x′ .e′ , Γ1 > Dans ce cas, il existe deux valeurs v2 et v ′ avec les propriétés suivantes : ↓ l:vl(tuoi 2 ) = v2 (f ′ , ↑ toi(< recf ′ .x′ .e′ , Γ1 >)) ⊕ (x, ↑ toi(v2))⊕ ↑toi(Γ1) ⊢l:vl e ′ →→ v ′ f ′ (vl) = v ′ Comme ci-dessus, on utilise l’hypothèse Htuoi inst pour prouver que v ′ = v et on déduit les jugements d’évaluation avec injection pour e1 et e2 à l’aide des hypothèses d’induction IH1 et IH2. On applique ensuite la règle inj-apply-rec pour conclure : inj-apply-rec tΓ oi ⊢l:vl e1 →→ v1 v1 =< recf ′ .x′ .e′ , Γ1 > tΓ oi ⊢l:vl e2 →→ v2 (f, ↑ toi(v1)) ⊕ (x, ↑ toi(v2))⊕ ↑toi(Γ1) ⊢l:vl e ′ →→ v tΓ oi ⊢l:vl e1 e2 →→ v Maintenant supposons l ̸= l ′ . Puisque l ̸= l ′ , on a l’égalité suivante : v = ↓ l:vl( [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi | [ d ′oi ∪ d oi | v oi ] ]) = ↓ l:vl( [ tdoi 1 ∪ tdoi 2 ∪ tdoi ∪ td′oi tl | [ d ′oi tl ∪ d oi | v oi ] ]) (Htuoi inst) On peut alors appliquer l’hypothèse d’induction IHd1 qui nous permet de conclure ce dernier cas : tΓ oi ⊢l:vl e1 e2 →→ v 1193.5. SÉMANTIQUE INSTRUMENTÉE 3.5 Sémantique instrumentée Nous arrivons maintenant à la présentation de la sémantique instrumentée, qui constitue ce que nous appelons notre analyse dynamique. Le but de cette analyse est de pouvoir évaluer un programme de la même manière qu’avec la sémantique opérationnelle usuelle mais en gardant trace pour chaque sous-terme de la valeur produite des dépendances de ce sous-terme. On veut alors pouvoir garantir que si un label n’apparaît pas parmi les dépendances d’un programme, alors ce label n’a pas d’impact sur l’évaluation de ce programme. Pour prouver la correction de l’analyse dynamique par rapport à la notion d’impact présentée en section 2.6, nous prouverons tout d’abord une propriété de correction de la sémantique instrumentée vis-à-vis de la sémantique sur-instrumentée puis nous nous reposerons sur la correction des deux sémantiques intermédiaires présentées plus haut : la sémantique avec injection dans un t-environnement sur-instrumenté (cf. section 3.3) et la sémantique sur-instrumentée (cf. section 3.4). La sémantique instrumentée évalue une expression dans un t-environnement instrumenté pour retourner une t-valeur instrumentée. C’est une simplification de la sémantique sur-instrumentée. En effet, on peut remarquer dans la sémantique sur-instrumentée que le calcul de la présence d’un label dans un ensemble de v-dépendances (resp. de tdépendances) ne dépend pas des v-fonctions d’impact (resp. des t-fonctions d’impact) qui sont associées. On peut donc calculer les ensembles de labels sans leur associer de fonction d’impact. C’est justement ce que fait la sémantique instrumentée. On obtient ainsi une sémantique décidable sur les programmes qui terminent puisque le caractère indécidable de la sémantique sur-instrumentée venait de la spécification des fonctions d’impact. La sémantique instrumentée constitue en elle-même l’analyse dynamique de dépendances que nous souhaitions définir, puisque l’analyse qui nous intéresse est justement le calcul des ensembles de labels. Sa définition ne nécessite aucunement une définition préalable de la sémantique sur-instrumentée ou bien de la sémantique avec injection. L’intérêt d’avoir défini la sémantique sur-instrumentée est uniquement de simplifier et de clarifier la preuve de correction de la sémantique instrumentée. 1203.5. SÉMANTIQUE INSTRUMENTÉE 3.5.1 Algèbre des valeurs instrumentées La sémantique instrumentée manipule des valeurs instrumentées. Ces valeurs peuvent être vues comme des valeurs abstraites par rapport aux valeurs sur-instrumentées. La fonction d’abstraction est tout simplement la fonction qui supprime toutes les fonctions d’impact. Ainsi, chaque valeur sur-instrumentée correspond à une valeur instrumentée unique et plusieurs valeurs sur-instrumentées peuvent correspondre à la même valeur instrumentée. Cette section présente la composition des valeurs instrumentées. 3.5.1.1 Valeurs Une t-valeur instrumentée (notée tui ) est composée d’un ensemble de t-dépendances tdi et d’une v-valeur instrumentée u i . tui := [ tdi | u i ] Valeur avec annotation de t-dépendance Une v-valeur instrumentée (notée u i ) est composée d’un ensemble de v-dépendances d i et d’une valeur simple instrumentée v i . u i := [ d i | v i ] Valeur avec annotation de v-dépendance Enfin, une valeur simple instrumentée (notée v i ) est une valeur simple dont les soustermes sont des v-valeurs instrumentées u i . On note V i l’ensemble des valeurs simples instrumentées. v i := n | b | C | D(u i ) | (u i 1 , ui 2 ) Constructeurs de données < λx.e, Γ i > Fermeture < recf.x.e, Γ i > Fermeture récursive 3.5.1.2 Ensembles de dépendances Dans les t-valeurs instrumentées (resp. les v-valeurs instrumentées), les ensembles de t-dépendances (resp. de v-dépendances) sont simplement des ensembles de labels. tdi := {l1; . . . ; ln} t-dépendances d i := {l1; . . . ; lm} v-dépendances 1213.5. SÉMANTIQUE INSTRUMENTÉE 3.5.1.3 Environnements De même que pour la sémantique sur-instrumentée, on distingue 2 types d’environnements. Un t-environnement instrumenté permet de lier chaque identificateur à une t-valeur instrumentée. tΓ i := (x1, tui 1 ); . . . ; (xn, tui n ) t-environnement instrumenté Un v-environnement instrumenté permet de lier chaque identificateur à une v-valeur instrumentée. Γ i := (x1, ui 1 ); . . . ; (xn, ui n ) v-environnement instrumenté 3.5.2 Règles d’inférence Le jugement d’évaluation de la sémantique instrumentée prend la forme suivante : tΓ i ⊢ i e →→ tui où e est l’expression évaluée, tΓ i le t-environnement instrumenté dans lequel on effectue l’évaluation et tui la t-valeur instrumentée résultat de l’évaluation. Ce jugement est défini par les règles d’inférence présentée en figure 3.20. Les règles simples de la sémantique sur-instrumentée restent les mêmes dans la sémantique instrumentée, seule la signification de la concaténation de dépendances est différente puisqu’on concatène des listes de labels au lieu de concaténer des listes d’associations. En ce qui concerne les règles contenant des dépendances indirectes, la sémantique instrumentée n’effectue plus le calcul des fonctions d’impact mais se concente de calculer les ensembles de labels. Des explications détaillées de ces règles sont données ci-dessous. i-num La règle d’évaluation d’une constante entière est identique à celle de la sémantique sur-instrumentée. L’ensemble des t-dépendances instrumentées est vide, de même que l’ensemble des v-dépendances instrumentées et la valeur simple instrumentée est la constante entière. 1223.5. SÉMANTIQUE INSTRUMENTÉE i-num tΓ i ⊢ i n →→ [ ∅ | [ ∅ | n ] ] i-ident tui = tΓ i [x] tΓ i ⊢ i x →→ tui i-letin tΓ i ⊢ i e1 →→ tui 1 tui 1 = [ tdi 1 | u i 1 ] (x, tui 1 ) ⊕ tΓ i ⊢ i e2 →→ [ tdi 2 | u i 2 ] tΓ i ⊢ i let x = e1 in e2 →→ [ tdi 1 ∪ tdi 2 | u i 2 ] i-abstr tΓ i ⊢ i λx.e →→ [ ∅ | [ ∅ | < λx.e, ↑ i ti(tΓ i ) > ] ] i-abstr-rec tΓ i ⊢ i recf.x.e →→ [ ∅ | [ ∅ | < recf.x.e, ↑ i ti(tΓ i ) > ] ] i-apply tΓ i ⊢ i e1 →→ [ tdi 1 | [ d i 1 | < λx.e, Γ i 1 > ] ] tΓ i ⊢ i e2 →→ tui 2 tui 2 = [ tdi 2 | u i 2 ] (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] tΓ i ⊢ i e1 e2 →→ [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] i-apply-rec tΓ i ⊢ i e1 →→ tui 1 tui 1 = [ tdi 1 | [ d i 1 | < recf.x.e, Γ i 1 > ] ] tΓ i ⊢ i e2 →→ tui 2 tui 2 = [ tdi 2 | u i 2 ] (f, tui 1 ) ⊕ (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] tΓ i ⊢ i e1 e2 →→ [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] i-if-true tΓ i ⊢ i e →→ [ tdi | [ d i | true ] ] tΓ i ⊢ i e1 →→ [ tdi 1 | [ d i 1 | v i 1 ] ] tΓ i ⊢ i if e then e1 else e2 →→ [ d i ∪ tdi ∪ tdi 1 | [ d i ∪ d i 1 | v i 1 ] ] i-if-false tΓ i ⊢ i e →→ [ tdi | [ d i | false ] ] tΓ i ⊢ i e2 →→ [ tdi 2 | [ d i 2 | v i 2 ] ] tΓ i ⊢ i if e then e1 else e2 →→ [ d i ∪ tdi ∪ tdi 2 | [ d i ∪ d i 2 | v i 2 ] ] i-match tΓ i ⊢ i e →→ tui tui = [ tdi | [ d i | v i ] ] tui , p ⊢ i p tΓ i p tΓ i p ⊕ tΓ i ⊢ i e1 →→ [ tdi 1 | [ d i 1 | v i 1 ] ] tΓ i ⊢ i match e with p → e1 | x → e2 →→ [ d i ∪ tdi ∪ tdi 1 | [ d i ∪ d i 1 | v i 1 ] ] i-match-var tΓ i ⊢ i e →→ tui tui = [ tdi | [ d i | v i ] ] tui , p ⊢ i p ⊥ (x, tui ) ⊕ tΓ i ⊢ i e2 →→ [ tdi 2 | [ d i 2 | v i 2 ] ] tΓ i ⊢ i match e with p → e1 | x → e2 →→ [ d i ∪ tdi ∪ tdi 2 | [ d i ∪ d i 2 | v i 2 ] ] i-constr-0 tΓ i ⊢ i C →→ [ ∅ | [ ∅ | C ] ] i-constr-1 tΓ i ⊢ i e →→ [ tdi | u i ] tΓ i ⊢ i D(e) →→ [ tdi | [ ∅ | D(u i ) ] ] i-couple tΓ i ⊢ i e1 →→ [ tdi 1 | u i 1 ] tΓ i ⊢ i e2 →→ [ tdi 2 | u i 2 ] tΓ i ⊢ i (e1, e2) →→ [ tdi 1 ∪ tdi 2 | [ ∅ | (u i 1 , ui 2 ) ] ] i-annot tΓ i ⊢ i e →→ [ tdi | [ d i | v i ] ] tΓ i ⊢ i l : e →→ [ tdi | [ l; d i | v i ] ] Figure 3.20 – Sémantique instrumentée im-constr-0 [ tdi | [ d i | C ] ], C ⊢ i p {} im-constr-1 [ tdi | [ d i | D(u i ) ] ], D(x) ⊢ i p {(x, [ ∅ | u i ])} im-couple [ tdi | [ d i | (u i 1 , ui 2 ) ] ], (x1, x2) ⊢ i p {(x1, [ ∅ | u i 1 ]); (x2, [ ∅ | u i 2 ])} im-constr-0-not p ̸= C [ tdi | [ d i | C ] ], p ⊢ i p ⊥ im-constr-1-not p ̸= D(_) [ tdi | [ d i | D(u i ) ] ], p ⊢ i p ⊥ im-couple-not p ̸= (_, _) [ tdi | [ d i | (u i 1 , ui 2 ) ] ], p ⊢ i p ⊥ Figure 3.21 – Sémantique instrumentée : règles de filtrage 1233.5. SÉMANTIQUE INSTRUMENTÉE ↑ i ti( [ tdi | u i ]) = u i ↑ i ti({}) = {} ↑i ti((x, tui ) ⊕ tΓ i ) = (x, ↑ i ti(tui )) ⊕ ↑i ti(tΓ i ) Figure 3.22 – Valeurs instrumentées : suppression des t-dépendances i-ident Cette règle est identique à celle de la sémantique sur-instrumentée. L’évaluation d’un identificateur se fait de manière habituelle, en allant chercher la valeur correspondante dans l’environnement. Les dépendances de la t-valeur instrumentée retournée sont celles qui ont été enregistrées dans l’environnement pour cet identificateur. i-abstr De même que pour la sémantique sur-instrumentée, les t-dépendances et les v-dépendances sont vides. La valeur simple instrumentée est une fermeture contenant l’environnement d’évaluation préalablement nettoyé de ses t-dépendances à l’aide de la fonction ↑ i ti(•) définie en figure 3.22. i-abstr-rec L’évaluation d’une abstraction récursive suit exactemement le même modèle que l’évaluation d’une abstraction non-récursive. i-apply La règle de l’application de la sémantique sur-instrumentée fait partie des règles avec dépendances indirectes. La règle correspondante de la sémantique instrumentée pré- sentée ici lui ressemble à une différence près : les dépendances indirectes ne nécessitent pas de spécification complexe. En effet, dans la sémantique sur-instrumentée, la fonction de spécification des dépendances indirectes deps_spec_apply permettait de spécifier les t-dépendances indirectes td′oi ainsi que les v-dépendances indirectes d ′oi. Cette spécification précisait que la liste des labels présents dans td′oi (de même pour d ′oi) était la même que la liste des labels présents dans d oi 1 (l’ensemble v-dépendances sur-instrumentée de e1) et donnait une spécification pour chaque fonction d’impact associée à une dépendance indirecte. Dans la sémantique instrumentée, nous ne considérons plus que les listes de labels et ignorons les fonctions d’impact. Ainsi, nous pouvons remplacer td′oi et d ′oi par la liste de labels d i 1 . Le caractère 1243.5. SÉMANTIQUE INSTRUMENTÉE ↑ ti i (u i ) = [ ∅ | u i ] ↑ ti i ({}) = {} ↑ti i ((x, ui ) ⊕ Γ i ) = (x, ↑ ti i (u i )) ⊕ ↑ti i (Γi ) Figure 3.23 – Valeurs instrumentées : ajout de t-dépendances indécidable de cette règle disparaît ainsi, avec la disparition de la fonction de spécification des dépendances indirectes. Comme dans la sémantique sur-instrumentée, nous utilisons une fonction ajoutant des t-dépendances vides à l’environnement encapsulé pour évaluer le corps de la fermeture. Cette fonction, notée ↑ ti i (•) est définie en figure 3.23. i-rec-apply De la même manière que pour la règle de l’application d’une fonction non récursive, cette règle reprend la règle de la sémantique sur-instrumentée en remplaçant les dépendances indirectes par la liste des v-dépendances de la sous-expression e1. i-letin La règle d’évaluation d’une liaison est identique à la règle correspondante dans la sémantique sur-instrumentée. Elle évalue e1 puis ajoute une liaison à l’environnement pour évaluer e2. Le résultat est une t-valeur instrumentée constituée de la concaténation des t-dépendances des sous-expressions évaluées et de la v-valeur instrumentée de e2. i-if-true et i-if-false La règle d’évaluation d’une expression conditionnelle contient des dépendances indirectes. Dans la sémantique sur-instrumentée, cette règle faisait appel à la fonction de spécification des dépendances indirectes deps_spec_if pour spécifier la liste des labels des dépendances indirectes ainsi que leurs fonctions d’impact. Cette fonction n’est plus nécessaire ici puisque la sémantique instrumentée ignore les fonctions d’impact. Nous reprennons donc la règle de la sémantique sur-instrumentée en remplaçant les tdépendances indirectes et les v-dépendances indirectes par d i , la liste des v-dépendances de la sous-expression testée. 1253.5. SÉMANTIQUE INSTRUMENTÉE i-match et i-match-var Comme pour les règles d’évaluation de l’application et de l’expression conditionnelle, la fonction de spécification des dépendances indirectes n’est plus nécessaire. Les dépendances indirectes, qui ne sont plus que des listes de labels, sont données immédiatement par la liste des v-dépendances de la sous-expression filtrée. i-constr-0, i-constr-1 et i-couple Ces trois règles reprennent à l’identique les règles de la sémantique sur-instrumentée. Le fait que les dépendances ne contiennent plus de fonction d’impact n’a aucune influence sur la logique de ces règles. Ceci est dû au fait qu’aucune dépendance n’est introduite, on ne fait que regrouper les t-dépendances des éventuelles sous-expressions en les concaténant et on construit la v-valeur instrumentée à l’aide des v-valeurs instrumentées des sous-expressions. La concaténation des dépendances a une signification légèrement différente puisqu’elle concatène des listes de labels au lieu de concaténer des listes associatives. i-annot La règle concernant une expression annotée est elle aussi similaire à son homologue dans la sémantique sur-instrumentée. Elle ajoute simplement le label l aux dé- pendances de la valeur de la sous-expression. La seule différence avec la sémantique surinstrumentée est qu’elle n’ajoute pas de fonction d’impact. Règles de filtrage De même que pour la sémantique sur-instrumentée, les règles de filtrage de la sémantique instrumentée se divisent en deux groupes de trois règles. Le premier groupe définit un jugement de la forme tui , p ⊢ i p Γ i qui indique qu’une valeur instrumentée tui correspond au motif p et retourne le v-environnement instrumenté Γ i . Le second groupe de règles définit un second jugement qui prend la forme suivante : tui , p ⊢ i p ⊥. Ce jugement signifie que la t-valeur instrumentée tui ne correspond pas au motif de filtrage p. Toutes ces règles d’inférence sont identiques à celle de la sémantique sur-instrumentée, ce qui se comprend aisément puisque la filtrage ne dépend pas des fonctions d’impact. 1263.5. SÉMANTIQUE INSTRUMENTÉE 3.5.3 Correction 3.5.3.1 Énoncé informel du théorème La sémantique instrumentée est une simplification de la sémantique sur-instrumentée. Elle permet de définir une analyse dynamique calculable pour tout programme dont l’évaluation de référence termine. Pour obtenir une sémantique calculable, nous avons retiré les fonctions d’impact de toutes les valeurs. En effet, dans les règles d’inférence avec dépendances indirectes, les fonctions d’impact contenues dans les dépendances indirectes sont spécifiées par rapport aux fonctions d’impact des prémisses. Ces spécifications ne permettent pas de construire les fonctions d’impact des dépendances indirectes et il n’est pas possible de définir un procédé calculatoire permettant de les construire puisque le problème de l’arrêt est indécidable (cf. section 3.4.1.2). On remarque qu’il est possible de supprimer les fonctions d’impact de toutes les valeurs car dans les règles d’inférence de la sémantique sur-instrumentée, les fonctions d’impact des prémisses ne servent qu’à définir d’autres fonctions d’impact et ne sont pas du tout utilisées pour le calcul des autres parties de la valeur (la valeur de référence et les listes de labels). Pour assurer la correction de la sémantique instrumentée il nous faut donc montrer que la seule différence entre la valeur d’un programme par la sémantique sur-instrumentée et sa valeur par la sémantique instrumentée est l’absence de fonction d’impact dans cette dernière. 3.5.3.2 Illustration par l’exemple Pour illustrer le fonctionnement de la sémantique instrumentée ainsi que la nécessité du théorème de correction que nous venons d’énoncer informellement, reprenons les deux exemples présentés précédemment. Exemple 1 : évaluation d’un couple Notons e1 le programme suivant : (3, l :7) 1273.5. SÉMANTIQUE INSTRUMENTÉE i-couple i-num tΓ i ⊢ i 3 →→ [ ∅ | [ ∅ | 3 ] ] i-annot i-num tΓ i ⊢ oi 7 →→ [ ∅ | [ ∅ | 7 ] ] tΓ i ⊢ i l : 7 →→ [ ∅ | [ l | 7 ] ] tΓ i ⊢ i (3, l : 7) →→ [ tdi 1 ∪ tdi 2 | [ ∅ | ( [ ∅ | 3 ], [ l | 7 ]) ] ] Figure 3.24 – Exemple 1 : arbre de dérivation du jugement d’évaluation instrumentée Nous avions présenté son jugement d’évaluation sur-instrumentée dans le t-environnement sur-instrumenté vide : ∅ ⊢oi e1 →→ tuoi avec tuoi = [ ∅ | [ ∅ | ( [ ∅ | 3 ], [ (l, id) | 7 ]) ] ] Intéressons-nous maintenant au jugement d’évaluation instrumenté dans le t-environnent instrumenté vide. L’arbre d’évaluation correspondant est donné en figure 3.24 et voici le jugement obtenu : ∅ ⊢i e1 →→ tui avec tui = [ ∅ | [ ∅ | ( [ ∅ | 3 ], [ l | 7 ]) ] ] On remarque la disparition de la fonction d’impact associée au label l dans l’ensemble des v-dépendances de la seconde composante du couple. Outre ce changement, toutes les autres parties de la valeur instrumentée sont identiques à celles de la valeur sur-instrumentée car les autres ensembles de dépendances sont vides. Pour l’évaluation de e1, on obtient donc la même t-valeur instrumentée, que l’on évalue le programme directement par la sémantique instrumentée ou bien en évaluant le programme par la sémantique sur-instrumentée puis en retirant toutes les fonctions d’impact. Exemple 2 : liaison d’une fonction Notons e2 le programme suivant : l e t f o = match o with | Some ( x ) → x + l1 : 8 | none → d i n 1283.5. SÉMANTIQUE INSTRUMENTÉE ( f ( Some 18 ) , l2 : 17 ) Nous allons évaluer ce programme par la sémantique sur-instrumentée dans l’environnement tΓ oi 2 et par la sémantique instrumentée dans l’environnement tΓ i 2 =↑ ti toi(tΓ oi 2 ). On pose : tΓ oi 2 = (d, [ tdoi d | [ d oi d | 26 ] ]) avec tdoi d = (l3, tfd) et d oi d = (l4, fd) L’arbre de dérivation du jugement d’évaluation sur-instrumentée de e2 a été donné dans les figures 3.12 et 3.13. On rappelle ici le jugement obtenu : tΓ oi 2 ⊢ oi e2 →→ [ ∅ | [ ∅ | ( [ (l1, f1) | 26 ], [ (l2, id) | 17 ]) ] ] avec f1 = fun x ⇒ 18 + x En ce qui concerne l’évaluation de e2 par la sémantique instrumentée, nous donnons l’arbre de dérivation dans les figures 3.25 et 3.26. Voici le jugement d’évaluation de e2 par la sémantique instrumentée : ↑ ti toi(tΓ oi 2 ) ⊢ i e2 →→ [ ∅ | [ ∅ | ( [ l1 | 26 ], [ l2 | 17 ]) ] ] Comme dans l’exemple précédent, on constate que la propriété de correction de la sémantique instrumentée est également vraie pour l’évaluation de e2. En effet, on obtient exactement la même valeur en utilisant la sémantique instrumentée ou la sémantique surinstrumentée. En évaluant e2 par la sémantique sur-instrumentée puis en supprimant toutes les fonctions d’impact dans la t-valeur sur-instrumentée, on obtient la t-valeur instrumentée [ ∅ | [ ∅ | ( [ l1 | 26 ], [ l2 | 17 ]) ] ]. Aussi, en supprimant dans un premier temps toutes les fonctions d’impact dans l’environnement d’évaluation tΓ oi 2 puis en utilisant la sémantique instrumentée pour évaluer e2 on obtient la même t-valeur instrumentée [ ∅ | [ ∅ | ( [ l1 | 26 ], [ l2 | 17 ]) ] ]. 1293.5. SÉMANTIQUE INSTRUMENTÉE i-letin i-abstr tΓ i 2 ⊢ i λo.match o with... →→ [ ∅ | [ ∅ | < λo.match o with..., ↑ i ti(tΓ i 2 ) > ] ] 1 i-couple i-apply i-ident [ ∅ | [ ∅ | < λo.match o with..., ↑ i ti(tΓ i 2 ) > ] ] = ((f, ...) ⊕ tΓ i 2 )[f] (f, ...) ⊕ tΓ i 2 ⊢ i f →→ [ ∅ | [ ∅ | < λo.match o with..., ↑ i ti(tΓ i 2 ) > ] ] 3 i-constr-1 i-num (f, ...) ⊕ tΓ i 2 ⊢ i 18 →→ [ ∅ | [ ∅ | 18 ] ] 4 (f, ...) ⊕ tΓ i 2 ⊢ i Some 18 →→ [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ] 3 i-match . . . (figure 3.26) . . . (o, ...)⊕ ↑ti i (↑ i ti(tΓ i 2 )) ⊢ i match o with Some x → x + l1 : 8 | none → d →→ [ ∅ | [ l1 | 26 ] ] 3 (f, ...) ⊕ tΓ i 2 ⊢ i f(Some 18) →→ [ ∅ | [ l1 | 26 ] ] 2 i-annot i-num (f, ...) ⊕ tΓ i 2 ⊢ i 17 →→ [ ∅ | [ ∅ | 17 ] ] 3 (f, ...) ⊕ tΓ i 2 ⊢ i l2 : 17 →→ [ ∅ | [ l2 | 17 ] ] 2 (f, ...) ⊕ tΓ i 2 ⊢ i (f(Some 18), l2 : 17) →→ [ ∅ | [ ∅ | ( [ l1 | 26 ], [ l2 | 17 ]) ] ] 1 tΓ i 2 ⊢ i e2 →→ [ ∅ | [ ∅ | ( [ l1 | 26 ], [ l2 | 17 ]) ] ] 0 Figure 3.25 – Exemple 2 : arbre de dérivation du jugement d’évaluation instrumentée i-match i-ident [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ] = ((o, ...)⊕ ↑ti i (↑ i ti(tΓ i 2 )))[o] (o, ...)⊕ ↑ti i (↑ i ti(tΓ i 2 )) ⊢ i o →→ [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ] 4 im-constr-1 [ ∅ | [ ∅ | Some( [ ∅ | 18 ]) ] ], Some x ⊢ i p (x, [ ∅ | 18 ]) 4 i-plus . . . (x, [ ∅ | 18 ]) ⊕ (o, ...)⊕ ↑ti i (↑ i ti(tΓ i 2 )) ⊢ i x + l1 : 8 →→ [ ∅ | [ l1 | 26 ] ] 4 (o, ...)⊕ ↑ti i (↑ i ti(tΓ i 2 )) ⊢ i match o with Some x → x + l1 : 8 | none → d →→ [ ∅ | [ l1 | 26 ] ] 3 Figure 3.26 – Exemple 2 : sous-arbre de dérivation instrumentée du filtrage 1303.5. SÉMANTIQUE INSTRUMENTÉE 3.5.3.3 Énoncé formel du théorème On veut prouver que la sémantique instrumentée donne les mêmes résultats que la sé- mantique sur-instrumentée hormis les fonctions d’impact. Si un programme a une valeur instrumentée, alors on peut être sûr qu’il a aussi une valeur sur-instrumentée et qu’en supprimant les fonctions d’impact de cette dernière, on obtient la même valeur instrumentée. On commence par définir formellement la fonction qui supprime toutes les fonctions d’impact d’une valeur sur-instrumentée pour obtenir la valeur instrumentée correspondante. Cette fonction est notée ↑ ti toi(•). On dit que c’est une abstraction des valeurs surinstrumentées en valeurs instrumentées. Abstraction d’une t-valeur sur-instrumentée : ↑ ti toi( [ tdoi | u oi ]) := [ ↑ ti toi(tdoi) | ↑i oi(u oi) ] Abstraction d’une v-valeur sur-instrumentée : ↑ i oi( [ d oi | v oi ]) := [ ↑ i oi(d oi) | ↑i oi(v oi) ] Abstraction d’un ensemble de t-dépendances sur-instrumenté : ↑ ti toi(∅) := ∅ ↑ ti toi((l, tf oi);tdoi) := l; ↑ ti toi(tdoi) Abstraction d’un ensemble de v-dépendances sur-instrumenté : ↑ i oi(∅) := ∅ ↑ i oi((l, f oi); d oi) := l; ↑ i oi(d oi) Abstraction d’une valeur simple sur-instrumentée : ↑ i oi(n) := n ↑ i oi(b) := b ↑ i oi(C) := C ↑ i oi(D(u oi)) := D(↑ i oi(u oi)) ↑ i oi((u oi 1 , uoi 2 )) := (↑ i oi(u oi 1 ), ↑ i oi(u oi 2 )) ↑ i oi(< λx.e, Γ oi >) := < λx.e, ↑ i oi(Γoi) > ↑ i oi(< recf.x.e, Γ oi >) := < recf.x.e, ↑ i oi(Γoi) > Abstraction d’un t-environnement sur-instrumenté : ↑ ti toi(∅) := ∅ ↑ ti toi((x, tuoi) ⊕ tΓ oi) := (x, ↑ ti toi(tuoi))⊕ ↑ti toi(tΓ oi) 1313.5. SÉMANTIQUE INSTRUMENTÉE Abstraction d’un v-environnement sur-instrumenté : ↑ i oi(∅) := ∅ ↑ i oi((x, uoi) ⊕ Γ oi) := (x, ↑ i oi(u oi))⊕ ↑i oi(Γoi) Il nous faut également définir formellement la fonction de concrétisation. Cette fonction transforme toute valeur instrumentée en une valeur sur-instrumentée dont elle est l’image par la fonction d’abstraction. Pour cela, la fonction de concrétisation doit associer une fonction d’impact à tout label présent dans un ensemble de dépendances de la valeur instrumentée. Le choix de ces fonctions d’impact est complètement arbitraire. Cette fonction de concrétisation est notée ↑ toi ti (•). Notons tf oi dummy et f oi dummy une t-fonction d’impact et une v-fonction d’impact quelconques qui seront introduites lors de la concrétisation des ensembles de dépendances instrumentés. Concrétisation d’une t-valeur instrumentée : ↑ toi ti ( [ tdi | u i ]) := [ ↑ toi ti (tdi ) | ↑oi i (u i ) ] Concrétisation d’une v-valeur instrumentée : ↑ oi i ( [ d i | v i ]) := [ ↑ oi i (d i ) | ↑oi i (v i ) ] Concrétisation d’un ensemble de t-dépendances instrumenté : ↑ toi ti (∅) := ∅ ↑ toi ti (l;tdi ) := (l, tf oi dummy); ↑ toi ti (tdi ) Concrétisation d’un ensemble de v-dépendances instrumenté : ↑ oi i (∅) := ∅ ↑ oi i (l; d i ) := (l, f oi dummy); ↑ oi i (d i ) Concrétisation d’une valeur simple instrumentée : ↑ oi i (n) := n ↑ oi i (b) := b ↑ oi i (C) := C ↑ oi i (D(u i )) := D(↑ oi i (u i )) ↑ oi i ((u i 1 , ui 2 )) := (↑ oi i (u i 1 ), ↑ oi i (u i 2 )) ↑ oi i (< λx.e, Γ i >) := < λx.e, ↑ oi i (Γi ) > ↑ oi i (< recf.x.e, Γ i >) := < recf.x.e, ↑ oi i (Γi ) > 1323.5. SÉMANTIQUE INSTRUMENTÉE Concrétisation d’un t-environnement instrumenté : ↑ toi ti (∅) := ∅ ↑ toi ti ((x, tui ) ⊕ tΓ i ) := (x, ↑ toi ti (tui ))⊕ ↑toi ti (tΓ i ) Concrétisation d’un v-environnement instrumenté : ↑ oi i (∅) := ∅ ↑ oi i ((x, ui ) ⊕ Γ i ) := (x, ↑ oi i (u i ))⊕ ↑oi i (Γi ) Nous pouvons alors énoncer le thèorème de correction : Théorème 3.5.1 (Correction de la sémantique instrumentée). ∀(tΓ i , e, tui ).tΓ i ⊢ i e →→ tui ⇒ ∃(tuoi). ↑ toi ti (tΓ i ) ⊢ oi e →→ tuoi ∧ tui =↑ ti toi(tuoi) Le théorème de correction énonce que s’il existe un jugement pour la sémantique instrumentée évaluant un programme e dans un t-environnement instrumenté tΓ i et retournant une t-valeur instrumentée tui , alors il existe un jugement évaluant e dans le t-environnement sur-instrumenté obtenu en ajoutant des fonctions d’impact quelconques dans tΓ i et en supprimant les fonctions d’impact dans la t-valeur sur-instrumentée obtenue, on retrouve la t-valeur instrumentée tui . La propriété suivante est plus forte que le théorème de correction. Elle permet de s’affranchir de la fonction de concrétisation qui n’a que peu de signification puisqu’elle ne fait qu’introduire des fonctions d’impact quelconques dans les ensembles de dépendances. Il aurait été sans doute plus judicieux de prouver cette propriété à la place du théorème de correction exprimé ci-dessus. Elle exprime que pour tout t-environnement sur-instrumenté tΓ oi, s’il existe un jugement instrumenté pour e dans l’environnement obtenu en supprimant toutes les fonctions d’impact de tΓ oi et que ce jugement retourne une t-valeur instrumentée tui , alors il existe un jugement sur-instrumenté dans tΓ oi et en supprimant les fonctions d’impact dans la t-valeur sur-instrumentée obtenue, on retrouve la t-valeur instrumentée tui . Si on spécialise cette propriété en prenant tΓ oi =↑ toi ti (tΓ i ), on retrouve le théorème de correction exprimé ci-dessus qui est donc un cas particulier. La preuve de cette propriété pourra faire l’objet d’un travail futur. ∀(tΓ oi, e, tui ). ↑ ti toi(tΓ oi) ⊢ i e →→ tui ⇒ ∃(tuoi).tΓ oi ⊢ oi e →→ tuoi ∧ tui =↑ ti toi(tuoi) 1333.5. SÉMANTIQUE INSTRUMENTÉE 3.5.3.4 Preuve de correction La preuve est faite par induction sur le jugement de la sémantique instrumentée. Nous expliquons ici quelques cas pour permettre au lecteur de comprendre facilement la manière dont la preuve a été faite. La preuve complète est disponible sous forme de code source Coq. cas i-num Ce cas est trivial. Dans ce cas, l’expression e n’est autre qu’une constante numérique n, la t-valeur instrumentée tui ne contient que des dépendances vides et la valeur simple sur-instrumentée n. Il suffit d’appliquer la règle d’inférence oi-num de la sémantique sur-instrumentée pour conclure. cas i-ident Dans ce cas, l’expression e est un identificateur que nous noterons x. Cet identificateur est présent dans l’environnement tΓ i associé à la valeur tui . L’identificateur x est donc également présent dans l’environnement ↑ toi ti (tΓ i ) associé à la valeur ↑ toi ti (tui ). Il suffit donc d’appliquer la règle d’inférence oi-ident de la sémantique sur-instrumentée pour conclure : ↑ toi ti (tΓ i ) ⊢ oi x →→↑toi ti (tui ) ∧ tui =↑ ti toi(↑ toi ti (tui )) cas i-abstr Nous avons le jugement de la sémantique instrumentée suivant : tΓ i ⊢ i λx.e →→ [ ∅ | [ ∅ | < λx.e, ↑ i ti(tΓ i ) > ] ] Nous allons montrer que la t-valeur sur-instrumentée suivante convient : ↑ toi ti ( [ ∅ | [ ∅ | < λx.e, ↑ i ti(tΓ i ) > ] ]) qui est égale à [ ∅ | [ ∅ | < λx.e, ↑ oi i (↑ i ti(tΓ i )) > ] ] Il nous faut alors montrer la propriété suivante : ↑ toi ti (tΓ i ) ⊢ oi e →→ [ ∅ | [ ∅ | < λx.e, ↑ oi i (↑ i ti(tΓ i )) > ] ] ∧ [ ∅ | [ ∅ | < λx.e, ↑ i ti(tΓ i ) > ] ] =↑ ti toi( [ ∅ | [ ∅ | < λx.e, ↑ oi i (↑ i ti(tΓ i )) > ] ]) 1343.5. SÉMANTIQUE INSTRUMENTÉE La première partie de la propriété se montre en appliquant la règle d’inférence oi-abstr et en remarquant que : ↑ oi i (↑ i ti(tΓ i )) =↑ oi toi(↑ toi ti (tΓ i )) La seconde partie de la propriété se montre en remarquant que : ↑ ti toi( [ ∅ | [ ∅ | < λx.e, ↑ oi i (↑ i ti(tΓ i )) > ] ]) = [ ∅ | [ ∅ | < λx.e, ↑ i oi(↑ oi i (↑ i ti(tΓ i ))) > ] ] et ↑ i ti(tΓ i ) =↑ i oi(↑ oi i (↑ i ti(tΓ i ))) cas i-apply Nous avons les jugements de la sémantique instrumentée issus de la règle d’inférence i-apply ainsi que les trois hypothèses d’induction suivantes : tΓ i ⊢ i e1 →→ [ tdi 1 | [ d i 1 | < λx.e, Γ i 1 > ] ] tΓ i ⊢ i e2 →→ tui 2 tui 2 = [ tdi 2 | u i 2 ] (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] tΓ i ⊢ i e1 e2 →→ [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] ↑ toi ti (tΓ i ) ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ] ∧ [ tdi 1 | [ d i 1 | < λx.e, Γ i 1 > ] ] =↑ ti toi( [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ]) ↑ toi ti (tΓ i ) ⊢ oi e2 →→ [ tdoi 2 | u oi 2 ] ∧ [ tdi 2 | u i 2 ] =↑ ti toi( [ tdoi 2 | u oi 2 ]) ↑ toi ti ((x, tui 2 )⊕ ↑ti i (Γi 1 )) ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] ∧ [ tdi | [ d i | v i ] ] =↑ ti toi( [ tdoi | [ d oi | v oi ] ]) Nous souhaitons dériver un jugement d’évaluation sur-instrumentée pour l’expression e1 e2 en utilisant la règle d’inférence oi-apply ainsi que les jugements d’évaluation de e1 et de e2 issus des hypothèses d’induction ci-dessus. Il nous manque un jugement d’évaluation adéquat pour e et une hypothèse concernant la spécification des dépendances indirectes. Tout d’abord, nous remarquons que la fonction de spécification des dépendances indirectes deps_spec_apply est une fonction totale (la preuve de cette propriété est assez 1353.5. SÉMANTIQUE INSTRUMENTÉE simple mais nécessite cependant de faire appel à l’axiome du choix ainsi qu’à l’axiome du tiers exclu). Il existe donc des ensembles de dépendances td′oi et d ′oi tels que : deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) En ce qui concerne le jugement d’évaluation sur-instrumentée de e, on reprend celui qui provient des hypothèses d’induction en l’adaptant. Remarquons tout d’abord qu’il est possible de réécrire l’environnement d’évaluation ainsi : ↑ toi ti ((x, tui 2 )⊕ ↑ti i (Γi 1 )) = ↑ toi ti ((x, ↑ ti toi( [ tdoi 2 | u oi 2 ]))⊕ ↑ti i (↑ i oi(Γoi 1 ))) = (x, ↑ toi ti (↑ ti toi( [ tdoi 2 | u oi 2 ])))⊕ ↑toi ti (↑ ti i (↑ i oi(Γoi 1 ))) = (x, ↑ toi ti (↑ ti toi( [ tdoi 2 | u oi 2 ])))⊕ ↑toi ti (↑ ti toi(↑ toi oi (Γoi 1 ))) = ↑ toi ti (↑ ti toi((x, [ tdoi 2 | u oi 2 ])⊕ ↑toi oi (Γoi 1 ))) On a donc le jugement suivant : ↑ toi ti (↑ ti toi((x, [ tdoi 2 | u oi 2 ])⊕ ↑toi oi (Γoi 1 ))) ⊢ oi e →→ [ tdoi | [ d oi | v oi ] ] On en déduit qu’il existe un jugement d’évaluation dans le t-environnement sur-instrumenté (x, [ tdoi 2 | u oi 2 ])⊕ ↑toi oi (Γoi 1 ) qui évalue e en une certaine t-valeur sur-instrumentée [ td′′oi | [ d ′′oi | v ′′oi ] ] qui vérifie les propriétés suivantes : (x, [ tdoi 2 | u oi 2 ])⊕ ↑toi oi (Γoi 1 ) ⊢ oi e →→ [ td′′oi | [ d ′′oi | v ′′oi ] ] ↑ ti toi( [ td′′oi | [ d ′′oi | v ′′oi ] ]) =↑ ti toi( [ tdoi | [ d oi | v oi ] ]) On peut alors appliquer la règle d’inférence oi-apply pour déduire un jugement d’évaluation sur-instrumentée pour l’expression e1 e2 : oi-apply tΓ oi ⊢ oi e1 →→ [ tdoi 1 | [ d oi 1 | < λx.e, Γ oi 1 > ] ] tΓ oi ⊢ oi e2 →→ tuoi 2 tuoi 2 = [ tdoi 2 | u oi 2 ] (x, tuoi 2 )⊕ ↑toi oi (Γoi 1 ) ⊢ oi e →→ [ td′′oi | [ d ′′oi | v ′′oi ] ] deps_spec_apply(tuoi 2 , doi 1 ) = (td′oi, d′oi) tΓ oi ⊢ oi e1 e2 →→ [ tdoi 1 ∪ tdoi 2 ∪ td′′oi ∪ td′oi | [ d ′oi ∪ d ′′oi | v ′′oi ] ] Pour conclure, il ne nous reste plus qu’à prouver qu’en supprimant les fonctions d’impact de la t-valeur sur-instrumentée de e1 e2, on retrouve sa t-valeur instrumentée : 1363.5. SÉMANTIQUE INSTRUMENTÉE ↑ ti toi( [ tdoi 1 ∪ tdoi 2 ∪ td′′oi ∪ td′oi | [ d ′oi ∪ d ′′oi | v ′′oi ] ]) = [ ↑ ti toi(tdoi 1 )∪ ↑ti toi(tdoi 2 )∪ ↑ti toi(td′′oi)∪ ↑ti toi(td′oi) | [ ↑ i oi(d ′oi)∪ ↑i oi(d ′′oi) | ↑i oi(v ′′oi) ] ] = [ ↑ ti toi(tdoi 1 )∪ ↑ti toi(tdoi 2 )∪ ↑ti toi(tdoi)∪ ↑ti toi(td′oi) | [ ↑ i oi(d ′oi)∪ ↑i oi(d oi) | ↑i oi(v oi) ] ] = [ tdi 1 ∪ tdi 2 ∪ tdi∪ ↑ti toi(td′oi) | [ ↑ i oi(d ′oi) ∪ d i | v i ] ] = [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] 1373.6. CORRECTION DE L’ANALYSE DYNAMIQUE 3.6 Correction de l’analyse dynamique Nous souhaitons, dans cette section, établir une preuve de correction de notre analyse dynamique vis-à-vis de la notion de dépendance établie formellement en section 2.7. Pour cela, nous avons présenté plus haut plusieurs sémantiques intermédiaires en établissant à chaque étape la correction de la sémantique présentée par rapport à la précédente. Nous allons maintenant pouvoir enchaîner les preuves intermédiaires pour établir un théorème de correction de l’analyse dynamique (la sémantique instrumentée) par rapport à la notion de dépendances introduite formellement à l’aide de la sémantique avec injection (cf. section 3.3). 3.6.1 Énoncé informel du théorème Le but de notre analyse est de pouvoir affirmer que si un label n’apparaît pas dans le résultat de l’analyse d’un programme alors ce label n’a pas d’impact sur l’évaluation de ce programme. Autrement dit, après avoir obtenu un jugement d’évaluation instrumentée du programme à analyser et après avoir vérifié que le label en question n’apparaît pas dans les dépendances calculées alors on peut affirmer que peu importe l’injection considérée sur ce label, l’évaluation avec injection de ce programme retournera toujours la valeur de référence du programme (la valeur du programme lors d’une évaluation sans injection). 3.6.2 Illustration par l’exemple Exemple 1 : évaluation d’un couple Notons e1 le programme suivant : (3, l :7) Son jugement d’évaluation instrumenté dans le t-environnent instrumenté vide est : ∅ ⊢i e1 →→ [ ∅ | [ ∅ | ( [ ∅ | 3 ], [ l | 7 ]) ] ] Seul le label l apparaît dans la t-valeur instrumentée de e1. On peut donc affirmer que 1383.6. CORRECTION DE L’ANALYSE DYNAMIQUE tout autre label n’a pas d’impact sur l’évaluation de e1. On a en effet pour toute injection (l ′ , vl ′) sur un label l ′ différent de l : ∅ ⊢l ′ :vl ′ e1 →→ (3, 7) Exemple 2 : liaison d’une fonction Notons e2 le programme suivant : l e t f o = match o with | Some ( x ) → x + l1 : 8 | none → d + l2 : 8 i n ( f ( Some 18 ) , l3 : 17 ) Voici le jugement d’évaluation instrumentée de e2 dans un t-environnement instrumenté tΓ i 2 = (d, [ tdi d | [ d i d | 26 ] ]) où d est un identificateur, tdi d un ensemble de t-dépendances et d i d un ensemble de v-dépendances : tΓ i 2 ⊢ i e2 →→ [ ∅ | [ ∅ | ( [ l1 | 26 ], [ l3 | 17 ]) ] ] Le label l2 n’étant pas présent dans la t-valeur instrumentée du programme e2, nous pouvons en conclure qu’aucune injection sur l2 n’a d’impact sur l’évaluation de e2 : ∀vl2 .(d, 26) ⊢l2:vl2 e2 →→ (26, 17) Par contre, les labels l1 et l3 apparaissent dans la t-valeur instrumentée du programme e2. Il n’est donc pas impossible qu’une injection sur un de ces labels puisse modifier le comportement du programme, comme le montrent les exemples ci-dessous : (d, 26) ⊢l1:24 e2 →→ (32, 17) (d, 26) ⊢l3:613 e2 →→ (26, 613) 1393.6. CORRECTION DE L’ANALYSE DYNAMIQUE ldna-e-i-num ldna_in_evali (l, tΓ i , n) ldna-e-i-constr-0 ldna_in_evali (l, tΓ i , C) ldna-e-i-constr-1 ldna_in_evali (l, tΓ i , e) ldna_in_evali (l, tΓ i , D(e)) ldna-e-i-ident ldna_in_vali (l, tΓ i [x]) ldna_in_evali (l, tΓ i , x) ldna-e-i-ident-unbound x ̸∈ support(tΓ i ) ldna_in_evali (l, tΓ i , x) ldna-e-i-abstr ldna_in_evali (l, tΓ i , e) ldna_in_evali (l, tΓ i , λx.e) ldna-e-i-abstr-rec ldna_in_evali (l, tΓ i , e) ldna_in_evali (l, tΓ i , recf.x.e) ldna-e-i-apply ldna_in_evali (l, tΓ i , e1) ldna_in_evali (l, tΓ i , e2) ldna_in_evali (l, tΓ i , e1 e2) ldna-e-i-if ldna_in_evali (l, tΓ i , e) ldna_in_evali (l, tΓ i , e1) ldna_in_evali (l, tΓ i , e2) ldna_in_evali (l, tΓ i , if e then e1 else e2) ldna-e-i-match ldna_in_evali (l, tΓ i , e) ldna_in_evali (l, tΓ i , e1) ldna_in_evali (l, tΓ i , e2) ldna_in_evali (l, tΓ i , match e with p → e1 | x → e2) ldna-e-i-annot l ̸= l ′ ldna_in_evali (l, tΓ i , e) ldna_in_evali (l, tΓ i , l : e) ldna-e-i-couple ldna_in_evali (l, tΓ i , e1) ldna_in_evali (l, tΓ i , e2) ldna_in_evali (l, tΓ i ,(e1, e2)) ldna-e-i-letin ldna_in_evali (l, tΓ i , e1) ldna_in_evali (l, tΓ i , e2) ldna_in_evali (l, tΓ i , let x = e1 in e2) Figure 3.27 – Prédicat de non-apparition d’un label lors d’une évaluation instrumentée 3.6.3 Énoncé formel du théorème Pour énoncer formellement le théorème de correction, il nous faut tout d’abord définir formellement les notions de non-apparition d’un label dans une valeur instrumentée et dans un t-environnement instrumenté. On définit pour cela les prédicats ldna_in_evali , ldna_in_vali et ldna_in_envi . Leur définition est donnée respectivement en figure 3.27, en figure 3.28 et en figure 3.29. Théorème 3.6.1 (Correction de l’analyse dynamique). ∀(tΓ i , e, tui , l). tΓ i ⊢ i e →→ tui ⇒ ldna_in_envti(l, tΓ i ) ⇒ ldna_in_valti(l, tui ) ⇒ ∀vl . ↑ti(tΓ i ) ⊢l:vl e →→↑ti(tui ) 1403.6. CORRECTION DE L’ANALYSE DYNAMIQUE ldna-v-i-num ldna_in_vali (l, n) ldna-v-i-bool ldna_in_vali (l, b) ldna-v-i-constr-0 ldna_in_vali (l, C) ldna-v-i-constr-1 ldna_in_vali (l, u) ldna_in_vali (l, D(u)) ldna-v-i-couple ldna_in_vali (l, u1) ldna_in_vali (l, u2) ldna_in_vali (l,(u1, u2)) ldna-v-i-closure ldna_in_evali (l, ↑ ti i (Γi ), e) ldna_in_vali (l, < λx.e, Γ i >) ldna-v-i-closure-rec ldna_in_evali (l, ↑ ti i (Γi ), e) ldna_in_vali (l, < recf.x.e, Γ i >) ldna-v-i-v-val l ̸∈ d i ldna_in_vali (l, vi ) ldna_in_vali (l, [ d i | v i ]) ldna-v-i-t-val l ̸∈ tdi ldna_in_vali (l, ui ) ldna_in_vali (l, [ tdi | u i ]) Figure 3.28 – Prédicat de non-apparition d’un label dans une valeur instrumentée ldna-env-i-empty ldna_in_envi (l, ∅) ldna-env-i-cons ldna_in_envi (l, tui ) ldna_in_envi (l, tΓ i ) ldna_in_envi (l,(tui ) ⊕ tΓ i ) Figure 3.29 – Prédicat de non-apparition d’un label dans un environnement instrumenté 3.6.4 Preuve de correction La preuve de ce théorème repose sur les théorèmes déjà prouvés précédemment concernant la correction de la sémantique instrumentée vis-à-vis de la sémantique sur-instrumentée, la correction de la sémantique sur-instrumentée vis-à-vis de la sémantique avec injection et la correction de la sémantique avec injection vis-à-vis de la sémantique opérationnelle avec injection. L’enchaînement de ces théorèmes permet ainsi d’établir le lien entre la sémantique instrumentée et la sémantique opérationnelle avec injection. On part des hypothèses suivantes : tΓ i ⊢ i e →→ tui ldna_in_envti(l, tΓ i ) ldna_in_valti(l, tui ) 1413.6. CORRECTION DE L’ANALYSE DYNAMIQUE Rappel du théorème de correction de la sémantique instrumentée : ∀(tΓ i , e, tui ).tΓ i ⊢ i e →→ tui ⇒ ∃(tuoi). ↑ toi ti (tΓ i ) ⊢ oi e →→ tuoi ∧ tui =↑ ti toi(tuoi) En utilisant le jugement d’évaluation instrumenté et le théorème de correction de la sémantique instrumentée vis-à-vis de la sémantique sur-instrumentée, on déduit qu’il existe une t-valeur sur-instrumentée tuoi vérifiant les deux propriétés suivantes : ↑ toi ti (tΓ i ) ⊢ oi e →→ tuoi tui =↑ ti toi(tuoi) D’autre part, puisque le label l n’apparaît pas dans le t-environnement instrumenté tΓ i , on en déduit que ce dernier est instanciable et l’environnement instancié est son environnement de référence. C’est-à-dire qu’il existe un environnement Γ tel que : Γ =↓ l:vl(tΓ oi) =↑toi(tΓ oi) =↑ti(tΓ i ) Puisque le label l n’apparaît pas non plus dans la t-valeur instrumentée tui , cette dernière est instanciable et la valeur de l’instanciation est sa valeur de référence. Il existe donc une valeur v telle que : v =↓ l:vl(tuoi) =↑toi(tuoi) =↑ti(tui ) Rappel du théorème de correction de la sémantique sur-instrumentée vis-à-vis de la sémantique avec injection dans un t-environnement sur-instrumenté : tΓ oi ⊢ oi e →→ tuoi ⇒ ∀(l, vl).∃Γ.Γ =↓ l:vl(tΓ oi) ⇒ ∀v.v =↓ l:vl(tuoi) ⇒ tΓ oi ⊢l:vl e →→ v On utilise alors ce théorème pour obtenir : tΓ oi ⊢l:vl e →→ v Rappel du théorème de correction de la sémantique avec injection dans un t-environnement sur-instrumenté vis-à-vis de la sémantique opérationnelle avec injection : ∀(tΓ oi , Γ, e, v, l, vl), tΓ oi ⊢l:vl e →→ v ⇒ Γ = ↓ l:vl(tΓ oi) ⇒ Γ ⊢l:vl e →→ v 1423.6. CORRECTION DE L’ANALYSE DYNAMIQUE On utilise enfin ce théorème pour déduire : Γ ⊢l:vl e →→ v On peut alors conclure en utilisant les égalités ci-dessus concernant Γ et v : ↑ti(tΓ i ) ⊢l:vl e →→↑ti(tui ) 1433.6. CORRECTION DE L’ANALYSE DYNAMIQUE 144Chapitre 4 Analyse statique 4.1 Introduction Ce chapitre a pour but de présenter une analyse statique des dépendances d’un programme et sa preuve de correction. Cette analyse permettra d’analyser tout programme écrit dans notre langage et de fournir une approximation raisonnable de ses dépendances. Elle permettra également d’analyser un programme sans en connaître précisément l’environnement d’évaluation. Il suffira de spécifier un environnement d’évaluation abstrait correspondant à un ensemble d’environnements d’évaluation possibles. La présentation de cette analyse statique fait suite à la présentation dans le chapitre précédent d’une analyse dynamique. Là où l’analyse dynamique permettait d’analyser un programme uniquement dans un environnement d’évaluation de référence connu, l’analyse statique permet de spécifier de façon souple l’environnement d’évaluation. Bien que la définition de l’analyse statique, que nous appelons sémantique abstraite, soit indépendante de celle de la sémantique instrumentée ainsi que des autres sémantiques présentées, sa présentation fait suite à la présentation dans le chapitre précédent de l’analyse dynamique (sémantique instrumentée). En effet, dans le but de faciliter la preuve de correction de l’analyse statique, nous définissons la sémantique abstraite comme une interprétation abstraite de la sémantique instrumentée. De la même manière que dans le chapitre précédent, nous serons amené à introduire des sémantiques intermédiaires permettant une preuve par étapes, plus simple qu’une approche directe. 1454.1. INTRODUCTION Sémantique instrumentée : Sémantique instrumentée multiple : Sémantique collectrice : Sémantique abstraite : Les flèches correspondent à des fonctions injectives entre les ensembles de valeurs ou entre les ensembles d'environnements pour visualiser les pertes de précision et pertes de généralité. Figure 4.1 – Sémantiques intermédiaires pour l’analyse statique La figure 4.1 présente une vue globale des différentes sémantiques intermédaires entre la sémantique instrumentée et la sémantique abstraite. Ainsi, dans ce chapitre, nous utilisons la sémantique instrumentée comme une sémantique de base dont nous allons proposer une interprétation abstraite en plusieurs étapes. La preuve de correction de l’analyse statique sera alors constituée de l’enchaînement des preuves de correction des différentes sémantiques intermédiaires. La figure 4.2 propose une représentation graphique de l’enchaînement des différentes preuves de correction. Tout d’abord, nous présenterons la sémantique instrumentée multiple qui permet d’analyser un programme simultanément pour un ensemble de t-environnements instrumentés possibles (cf. section 4.2). Ensuite, nous aborderons la présentation de la sémantique collectrice (cf. section 4.3), qui permet d’analyser un programme dans un environnement collecteur dans lequel chaque identificateur est lié à un ensemble de valeurs possibles. En- fin nous présenterons la définition et la preuve de correction de la sémantique abstraite (cf. section 4.4), dans laquelle les ensembles de valeurs présents dans la sémantique collectrice sont remplacés par des valeurs abstraites représentant certains ensembles de valeurs particuliers. 1464.2. SÉMANTIQUE INSTRUMENTÉE MULTIPLE La sémantique instrumentée multiple effectue plusieurs évaluations instrumentées à la fois. Si un t-environnement instrumenté appartient à l'ensemble des environnements, alors la t-valeur instrumentée appartient au résultat. La sémantique collectrice est une interprétation abstraite de la sémantique instrumentée multiple. La sémantique abstraite est une interprétation abstraite de la sémantique collectrice. Ce diagramme montre le lien entre l'analyse statique d'un programme (sémantique abstraite) et l'analyse dynamique (sémantique instrumentée). On peut ainsi visualiser l’enchaînement des preuves de correction des 3 sémantiques présentées dans ce chapitre. Figure 4.2 – Enchaînement des preuves des sémantiques intermédiaires pour l’analyse statique 4.2 Sémantique instrumentée multiple La sémantique instrumentée multiple est la première sémantique intermédiaire permettant de faire le lien entre la sémantique instrumentée et la sémantique abstraite. Il s’agit d’un outil technique permettant de faciliter la preuve de correction de la sémantique collectrice qui sera présentée dans la section suivante. 4.2.1 Présentation informelle Un des buts de notre analyse statique est de pouvoir obtenir en une unique analyse un résultat contenant une approximation des dépendances d’un programme pour un ensemble d’évaluations possibles. La sémantique instrumentée multiple franchit ce premier pas en regroupant dans un jugement d’évaluation unique un ensemble d’évaluations instrumentées possibles. 4.2.2 Définition formelle La définition formelle de la sémantique instrumentée multiple ne comprend qu’une seule règle d’inférence. Celle-ci se base sur la sémantique instrumentée précédemment définie. 1474.2. SÉMANTIQUE INSTRUMENTÉE MULTIPLE Le point de départ est un ensemble tΓ im d’environnements d’évaluations instrumentés possibles. Chacun de ces environnements instrumentés fournit ou non un jugement d’évaluation instrumenté pour le programme e aboutissant sur une certaine t-valeur instrumentée. Toutes les t-valeurs instrumentées tui pour lesquelles il existe un jugement d’évaluation instrumentée du programme e dans un t-environnement instrumenté présent dans tΓ im sont regroupées dans un ensemble de t-valeurs instrumentées v im qui est le résultat du jugement d’évaluation instrumentée multiple. Il est utile de remarquer que pour tout ensemble de t-environnements instrumentés et tout programme e, il existe un jugement d’évaluation instrumentée multiple de ce programme en un certain ensemble de t-valeurs instrumentées (éventuellement vide). i-multiple v im = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i e →→ tui } tΓ im ⊢ im e →→ v im 1484.3. SÉMANTIQUE COLLECTRICE 4.3 Sémantique collectrice La sémantique collectrice a pour but de faire apparaître le calcul des dépendances lors de l’analyse simultanée d’un ensemble d’évaluations possibles d’un programme. La sémantique instrumentée multiple permettait d’analyser simultanément un ensemble d’évaluations possibles d’un programme mais le calcul des dépendances se faisait séparément pour chacune des évaluations possibles. La sémantique collectrice évalue un programme dans un environnement collecteur et fournit comme résultat une valeur collectrice. Cette valeur collectrice comprend des t-dépendances ainsi que des v-dépendances globales (partagées par toutes les valeurs possibles) ainsi qu’un ensemble de valeurs possibles. L’intérêt d’une telle sémantique est de séparer le calcul des dépendances du calcul des valeurs dans chaque environnement possible. Cette étape permettra par la suite de définir une abstraction du calcul des valeurs en gardant le calcul des dépendances défini ici. 4.3.1 Algèbre des valeurs 4.3.1.1 Valeurs Une t-valeur collectrice (ou simplement « valeur collectrice » puisqu’ici il n’y a pas d’ambiguïté, notée tuc ) est composée d’un ensemble de t-dépendances tdc , d’un ensemble de v-dépendances d c ainsi que d’un ensemble de valeurs simples instrumentées vsi . tuc := [ tdc | d c | vsi ] Valeur collectrice Les annotations de dépendance tdc et d c sont globales et chaque valeur simple instrumentée présente dans vsi contient des annotations de dépendance concernant ses propres soustermes. Comme dans toutes les autres sémantiques présentées, les ensembles de t-dépendances ainsi que les ensembles de v-dépendances sont des ensembles nécessairement finis. Par contre, l’ensemble des valeurs simples instrumentées contenu dans une valeur collectrice est un ensemble potentiellement infini. 1494.3. SÉMANTIQUE COLLECTRICE 4.3.1.2 Ensembles de dépendances Dans les valeurs collectrices, les ensembles de t-dépendances (resp. de v-dépendances) sont simplement des ensembles de labels, comme dans la sémantique instrumentée. tdc := {l1; . . . ; ln} t-dépendances d c := {l1; . . . ; lm} v-dépendances 4.3.1.3 Environnements Contrairement à la sémantique instrumentée, il n’y a qu’un seul type d’environnement. La représentation des fonctions sous forme de valeur collectrice est constituée d’un ensemble de fermetures instrumentées, contenant chacune un v-environnement instrumenté. Il n’y a donc pas besoin d’un type d’environnement collecteur spécial pour la représentation des fonctions. Un t-environnement collecteur (ou simplement « environnement collecteur » puisqu’ici il n’y a pas d’ambiguïté) permet de lier chaque identificateur à une t-valeur collectrice. tΓ c := (x1, tuc 1 ); . . . ; (xn, tuc n ) t-environnement collecteur 4.3.2 Règles d’inférence La sémantique collectrice évalue une expression dans un environnement collecteur et fournit une valeur collectrice. Tout comme la sémantique instrumentée multiple, elle fournit toujours un résultat (pour toute expression et tout environnement collecteur, il existe une valeur collectrice). La valeur collectrice peut éventuellement contenir un ensemble vide de valeurs simples, ce qui correspond à une erreur d’évaluation. Le jugement d’évaluation prend la forme suivante : tΓ c ⊢ c e →→ tuc c-num La règle d’évaluation d’une constante numérique n’introduit aucune dépendance. Les t-dépendances ainsi que les v-dépendances sont donc vides. L’ensemble des valeurs simples instrumentées est réduit à un singleton contenant uniquement la constante numé- rique correspondant à l’expression. 1504.3. SÉMANTIQUE COLLECTRICE c-num tΓ c ⊢ c n →→ [ ∅ | ∅ | {n} ] c-ident tuc = tΓ c [x] tΓ c ⊢ c x →→ tuc c-ident-empty x ̸∈ support(tΓ c ) tΓ c ⊢ c x →→ [ ∅ | ∅ | ∅ ] c-abstr vsi = {< λx.e, Γ i > | Γ i ∈↑im c (tΓ c )} tΓ c ⊢ c λx.e →→ [ ∅ | ∅ | vsi ] c-abstr-rec vsi = {< recf.x.e, Γ i > | Γ i ∈↑im c (tΓ c )} tΓ c ⊢ c recf.x.e →→ [ ∅ | ∅ | vsi ] c-apply tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] v im = multiple_instrumented_application(tdc 1 , dc 1 , vsi 1 , tdc 2 , dc 2 , vsi 2 ) (∀l. l ∈ tdc ⇔ (∃(tdi , di , vi ). l ∈ tdi ∧ [ tdi | [ d i | v i ] ] ∈ v im)) (∀l. l ∈ d c ⇔ (∃(tdi , di , vi ). l ∈ d i ∧ [ tdi | [ d i | v i ] ] ∈ v im)) vsi = {v i | ∃(tdi , di ). [ tdi | [ d i | v i ] ] ∈ v im} tΓ c ⊢ c e1 e2 →→ [ tdc | d c | vsi ] c-if-true tΓ c ⊢ c e →→ [ tdc | d c | vsi ] true ∈ vsi false ̸∈ vsi tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] tu′c = [ d c ∪ tdc ∪ tdc 1 | d c ∪ d c 1 | vsi 1 ] tΓ c ⊢ c if e then e1 else e2 →→ tu′c c-if-false tΓ c ⊢ c e →→ [ tdc | d c | vsi ] false ∈ vsi true ̸∈ vsi tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] tu′c = [ d c ∪ tdc ∪ tdc 2 | d c ∪ d c 2 | vsi 2 ] tΓ c ⊢ c if e then e1 else e2 →→ tu′c c-if-unknown tΓ c ⊢ c e →→ [ tdc | d c | vsi ] true ∈ vsi false ∈ vsi tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] tu′c = [ d c ∪ tdc ∪ tdc 1 ∪ tdc 2 | d c ∪ d c 1 ∪ d c 2 | vsi 1 ∪ vsi 2 ] tΓ c ⊢ c if e then e1 else e2 →→ tu′c c-if-empty tΓ c ⊢ c e →→ [ tdc | d c | vsi ] true ̸∈ vsi false ̸∈ vsi tΓ c ⊢ c if e then e1 else e2 →→ [ ∅ | ∅ | ∅ ] c-match tΓ c ⊢ c e →→ tuc tuc = [ tdc | d c | vsi ] vsi ∩ vsi matchable ̸= ∅ tuc , p ⊢ c p tΓ c p tΓ c p ⊕ tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] tΓ c ⊢ c match e with p → e1 | x → e2 →→ [ d c ∪ tdc ∪ tdc 1 | d c ∪ d c 1 | vsi 1 ] c-match-var tΓ c ⊢ c e →→ tuc tuc = [ tdc | d c | vsi ] vsi ∩ vsi matchable ̸= ∅ tuc , p ⊢ c p ⊥ (x, tuc ) ⊕ tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] tΓ c ⊢ c match e with p → e1 | x → e2 →→ [ d c ∪ tdc ∪ tdc 2 | d c ∪ d c 2 | vsi 2 ] c-match-unknown tΓ c ⊢ c e →→ tuc tuc = [ tdc | d c | vsi ] vsi ∩ vsi matchable ̸= ∅ tuc , p ⊢ c p? tΓ c p tΓ c p ⊕ tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] (x, tuc ) ⊕ tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] tΓ c ⊢ c match e with p → e1 | x → e2 →→ [ d c ∪ tdc ∪ tdc 1 ∪ tdc 2 | d c ∪ d c 1 ∪ d c 2 | vsi 1 ∪ vsi 2 ] c-match-empty tΓ c ⊢ c e →→ tuc tuc = [ tdc | d c | vsi ] vsi ∩ vsi matchable = ∅ tΓ c ⊢ c match e with p → e1 | x → e2 →→ [ ∅ | ∅ | ∅ ] Figure 4.3 – Sémantique collectrice : première partie 1514.3. SÉMANTIQUE COLLECTRICE c-constr-0 tΓ c ⊢ c C →→ [ ∅ | ∅ | {C} ] c-constr-1 tΓ c ⊢ c e →→ [ tdc | d c | vsi ] tΓ c ⊢ c D(e) →→ [ tdc | ∅ | {D( [ d c | v i ]) | v i ∈ vsi } ] c-couple tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] tΓ c ⊢ c (e1, e2) →→ [ tdc 1 ∪ tdc 2 | ∅ | {( [ d c 1 | v i 1 ], [ d c 2 | v i 2 ]) | v i 1 ∈ vsi 1 ∧ v i 2 ∈ vsi 2} ] c-letin tΓ c ⊢ c e1 →→ tuc 1 tuc 1 = [ tdc 1 | d c 1 | vsi 1 ] vsi 1 ̸= ∅ (x, tuc 1 ) ⊕ tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] tΓ c ⊢ c let x = e1 in e2 →→ [ tdc 1 ∪ tdc 2 | d c 2 | vsi 2 ] c-letin-empty tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | ∅ ] tΓ c ⊢ c let x = e1 in e2 →→ [ ∅ | ∅ | ∅ ] c-annot tΓ c ⊢ c e →→ [ tdc | d c | vsi ] tΓ c ⊢ c l : e →→ [ tdc | {l} ∪ d c | vsi ] Figure 4.4 – Sémantique collectrice : seconde partie vsi matchable = {C|∀C ∈ Constr0 } ∪ {D(u i )|∀D ∈ Constr1 , ∀u i } ∪ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2} cm-constr-0 vsi ∩ vsi matchable ⊆ {C|∀C ∈ Constr0 } [ tdc | d c | vsi ], C ⊢ c p {} cm-constr-1 vsi ∩ vsi matchable ⊆ {D(u i )|∀D ∈ Constr1 , ∀u i } vs′i = {v i |∃d i .D( [ d i | v i ]) ∈ vsi } ∀l.l ∈ d ′c ⇔ ∃d i .l ∈ d i ∧ ∃v i .D( [ d i | v i ]) ∈ vsi [ tdc | d c | vsi ], D(x) ⊢ c p {(x, [ ∅ | d ′c | vs′i ])} cm-couple vsi ∩ vsi matchable ⊆ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2} vsi 1 = {v i 1 |∃(d i 1 , di 2 , vi 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi } ∀l.l ∈ d c 1 ⇔ ∃d i 1 .l ∈ d i 1 ∧ ∃(v i 1 , di 2 , vi 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi vsi 2 = {v i 2 |∃(d i 1 , vi 1 , di 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi } ∀l.l ∈ d c 2 ⇔ ∃d i 2 .l ∈ d i 2 ∧ ∃(d i 1 , vi 1 , vi 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi [ tdc | d c | vsi ], (x1, x2) ⊢ c p {(x1, [ ∅ | d c 1 | vsi 1 ]); (x2, [ ∅ | d c 2 | vsi 2 ])} cm-constr-0-not vsi ∩ {C|∀C ∈ Constr0 } = ∅ [ tdc | d c | vsi ], C ⊢ c p ⊥ cm-constr-1-not vsi ∩ {D(u i )|∀D ∈ Constr1 , ∀u i } = ∅ [ tdc | d c | vsi ], D(x) ⊢ c p ⊥ cm-couple-not vsi ∩ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2} = ∅ [ tdc | d c | vsi ], (x1, x2) ⊢ c p ⊥ cm-constr-0-unknown vsi ∩ vsi matchable ̸⊆ {C|∀C ∈ Constr0 } vsi ∩ {C|∀C ∈ Constr0 } ̸= ∅ [ tdc | d c | vsi ], C ⊢ c p? {} cm-constr-1-unknown vsi ∩ vsi matchable ̸⊆ {D(u i )|∀D ∈ Constr1 , ∀u i } vsi ∩ {D(u i )|∀D ∈ Constr1 , ∀u i } ̸= ∅ vs′i = {v i |∃d i .D( [ d i | v i ]) ∈ vsi ∩ {D(u i )|∀D ∈ Constr1 , ∀u i }} ∀l.l ∈ d ′c ⇔ ∃d i .l ∈ d i ∧ ∃v i .D( [ d i | v i ]) ∈ vsi ∩ {D(u i )|∀D ∈ Constr1 , ∀u i } [ tdc | d c | vsi ], D(x) ⊢ c p? {(x, [ ∅ | d ′c | vs′i ])} cm-couple-unknown vsi ∩ vsi matchable ̸⊆ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2} vsi ∩ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2} ̸= ∅ vsi 1 = {v i 1 |∃(d i 1 , di 2 , vi 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi ∩ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2}} ∀l.l ∈ d c 1 ⇔ ∃d i 1 .l ∈ d i 1 ∧ ∃(v i 1 , di 2 , vi 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi ∩ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2} vsi 2 = {v i 2 |∃(d i 1 , vi 1 , di 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi ∩ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2}} ∀l.l ∈ d c 2 ⇔ ∃d i 2 .l ∈ d i 2 ∧ ∃(d i 1 , vi 1 , vi 2 ).( [ d i 1 | v i 1 ], [ d i 2 | v i 2 ]) ∈ vsi ∩ {(u i 1 , ui 2 )|∀u i 1 , ∀u i 2} [ tdc | d c | vsi ], (x1, x2) ⊢ c p? {(x1, [ ∅ | d c 1 | vsi 1 ]); (x2, [ ∅ | d c 2 | vsi 2 ])} Figure 4.5 – Sémantique collectrice : règles de filtrage 1524.3. SÉMANTIQUE COLLECTRICE c-ident La règle d’évaluation d’un identificateur est semblable à celle des autres sémantiques. Elle retourne la valeur associée à cet identificateur dans l’environnement. c-ident-empty Une nouvelle règle est introduite pour donner une valeur à un identificateur dans le cas où il n’apparaît pas dans l’environnement. Dans ce cas, l’ensemble des valeurs simples est vide pour signifier qu’il n’existe aucune évaluation instrumentée correspondante. Cette règle est nécessaire pour que la sémantique collectrice soit totale, c’est-à-dire qu’elle fournisse une valeur pour n’importe quelle expression dans n’importe quel environnement. c-abstr L’évaluation d’une fonction ne produit aucune dépendance, comme dans les sémantiques précédentes. En ce qui concerne l’ensemble des valeurs simples instrumentées, on remarquera qu’il contient un ensemble de fermetures. Puisque l’environnement collecteur correspond à un ensemble d’environnements instrumentés, on construit une fermeture pour chaque environnement instrumenté possible. Pour cela, on utilise la fonction ↑ im c (•) qui transforme un t-environnement collecteur en l’ensemble des environnements instrumentés lui correspondant. Cette fonction est définie en figure 4.8. c-abstr-rec Selon le même principe que pour la règle c-abstr, on construit une fermeture récursive pour chaque environnement instrumenté possible. c-apply La règle de l’application, est plus complexe car il faut construire l’ensemble des valeurs possibles pour l’application à partir de l’ensemble des valeurs possibles pour e1 et e2. Tout d’abord, on évalue e1 et e2 dans l’environnement collecteur pour obtenir leur valeur collectrice. On construit ensuite l’ensemble des t-valeurs instrumentées de l’application en utilisant la fonction multiple_instrumented_application avec les valeurs collectrices de e1 et e2. À partir du résultat de cette fonction, on extrait alors les t-dépendances, les v-dépendances ainsi que l’ensemble des valeurs simples instrumentées de l’application. La fonction multiple_instrumented_application a pour but de définir l’ensemble des 1534.3. SÉMANTIQUE COLLECTRICE multiple_instrumented_application(tdc 1 , dc 1 , vsi 1 , tdc 2 , dc 2 , vsi 2 ) = { tui | ( ∃ < λx.e, Γ i 1 >∈ vsi 1 . ∃v i 2 ∈ vsi 2 . ∃(tdi , ti , vi ). ∃tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ]. (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] ∧ tui = [ tdc 1 ∪ tdc 2 ∪ tdi ∪ d c 1 | [ d c 1 ∪ d i | v i ] ] ) ∨ ( ∃ < recf.x.e, Γ i 1 >∈ vsi 1 . ∃v i 2 ∈ vsi 2 . ∃(tdi , ti , vi ). ∃tui f = [ tdc 1 | [ d c 1 | < recf.x.e, Γ i 1 > ] ]. ∃tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ]. (f, tui f ) ⊕ (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] ∧ tui = [ tdc 1 ∪ tdc 2 ∪ tdi ∪ d c 1 | [ d c 1 ∪ d i | v i ] ] ) } Figure 4.6 – Sémantique collectrice : prédicat d’application instrumentée multiple t-valeurs instrumentées d’une application de fonction à partir de la valeur collectrice de la fonction et de la valeur collectrice de l’argument. Cet ensemble est défini par un prédicat d’appartenance. Une t-valeur instrumentée appartient à cet ensemble si il existe une fermeture (récursive ou non) et une valeur argument telles que l’application de cette fermeture à cette valeur par la sémantique instrumentée fournit la t-valeur considérée. La définition formelle de cette fonction est donnée en figure 4.6. Expressions conditionnelles Pour l’évaluation collectrice d’une expresssion conditionnelle, on distingue 4 cas : – pour tout environnement possible, seule la première branche est évaluée – pour tout environnement possible, seule la seconde branche est évaluée – selon l’environnement possible, l’une ou l’autre des branches est évaluée – il n’y a aucune évaluation possible c-if-true Le premier cas est caractérisé par l’appartenance de la valeur true à l’ensemble des valeurs possible de la condition (ce qui indique qu’il existe une évaluation possible passant par la première branche) et la non-appartenance de la valeur f alse (ce qui indique qu’aucune évaluation possible ne passe par la seconde branche). Dans ce cas, le calcul des dépendances s’effectue de manière similaire à la sémantique instrumentée. 1544.3. SÉMANTIQUE COLLECTRICE c-if-false Le second cas est caractérisé de la même manière, par l’appartenance de la valeur f alse et la non-appartenance de la valeur true à l’ensemble des valeurs possibles de la condition. Dans ce cas également, le calcul des dépendances s’effectue de manière similaire à la sémantique instrumentée. c-if-unknown Le cas incertain, où l’on peut passer parfois par la première branche et parfois par la seconde branche est caractérisé par l’appartenance des deux valeurs true et f alse à l’ensemble des valeurs possibles de la condition. Dans ce cas, les dépendances de la première branche ainsi que celles de la seconde branche se retrouvent toutes les deux dans les dépendances du résultat. C’est une des sources d’approximation dues à l’incertitude sur les valeurs de l’environnement. c-if-empty Le dernier cas de l’évaluation d’une expression conditionnelle correspond au cas d’erreur. Le programme analysé est incorrect et son analyse par notre calcul de dépendances n’a pas d’intérêt. Pattern-matching Pour l’évaluation collectrice d’un pattern-matching, on distingue 4 cas, homologues aux 4 cas concernant une expression conditionnelle : – pour tout environnement possible, seule la première branche est évaluée – pour tout environnement possible, seule la seconde branche est évaluée – selon l’environnement possible, l’une ou l’autre des branches est évaluée – il n’y a aucune évaluation possible Cette distinction en 4 cas suit les sémantiques opérationnelles et instrumentées présentées plus haut dans lesquelles seules les valeurs « filtrables » aboutissent à une évaluation. Par exemple, si l’expression filtrée s’évalue en une fermeture ou un nombre, alors aucune des deux branches du filtrage n’est évaluée, le résultat est donc une erreur lors de l’évaluation. Il se peut que cette sémantique « théorique » ne corresponde pas à l’implémentation d’un compilateur en pratique. Ce point est discuté plus en détail en section 2.3.4. 1554.3. SÉMANTIQUE COLLECTRICE La discrimination entre les 4 cas se fait tout d’abord en vérifiant si la valeur collectrice contient au moins une valeur filtrable (cf. définition de vsi matchable en figure 4.5). Si c’est le cas, on distingue alors trois possibilités à l’aide d’un prédicat de filtrage défini en figure 4.5. Ce prédicat est noté tuc , p ⊢ c p result où tuc est la valeur collectrice filtrée, p est le filtre et result peut prendre trois formes différentes. Il s’agit soit d’un environnement collecteur (si la valeur est toujours filtrée), soit du symbole ⊥ (si la valeur n’est jamais filtrée), soit du symbole ? accompagné d’un environnement collecteur (si la valeur collectrice contient à la fois des valeurs filtrées et des valeurs non filtrées). c-match Le cas où seule la première branche peut être évaluée est caractérisé par deux conditions. Premièrement, il doit exister des valeurs « filtrables » dans l’ensemble des valeurs possibles de l’expression filtrée (sinon, aucune branche n’est jamais évaluée). Deuxiè- mement, la valeur collectrice de l’expression filtrée est filtrée par le motif (ce qui signifie que toutes les valeurs instrumentées « filtrables » correspondantes sont filtrées par ce motif). L’environnement collecteur obtenu par le filtrage contient les liaisons des éventuels identificateurs contenus dans le motif. Chaque identificateur est lié à l’ensemble des valeurs filtrées par le motif. c-match-var Le cas où seule la seconde branche peut être évaluée est aussi caractérisé par la non-vacuité de l’ensemble des valeurs « filtrables » de l’expression filtrée ainsi que par une seconde condition. La seconde condition impose qu’aucune valeur « filtrable » de l’expression filtrée ne correspond au motif. c-match-unknown Comme pour l’évaluation d’une expression conditionnelle, il existe un cas incertain où on ne peut pas garantir que l’évaluation passera toujours pas la même branche. On caractérise ce cas par la condition de non-vacuité de l’ensemble des valeurs « filtrables » de l’expression filtrée et une seconde condition qui impose qu’il existe parmi les valeurs « filtrables » de l’expression filtrée certaines qui correspondent au motif et d’autres qui n’y correspondent pas. Dans ce cas, les dépendances des deux branches se retrouvent dans les dépendances du résultat. 1564.3. SÉMANTIQUE COLLECTRICE c-match-empty S’il n’existe aucune valeur « filtrable » pour l’expression filtrée alors on est en présence d’un programme erroné. c-constr-0 L’évaluation collectrice d’un constructeur constant est similaire à l’évaluation d’une constante numérique. Les t-dépendances ainsi que les v-dépendances sont donc vides et l’ensemble des valeurs simples instrumentées est réduit à un singleton contenant uniquement le constructeur. c-constr-1 L’évaluation d’un constructeur paramétré n’ajoute pas de dépendances. Les t-dépendances sont exactement les t-dépendances de la sous-expression et l’ensemble des v-dépendances est vide. Pour obtenir l’ensembles des valeurs simples instrumentées, on enrobe avec le constructeur chacune des valeurs simples instrumentées de la sous-expression. c-couple L’évaluation d’un couple suit le même principe que celle d’un constructeur paramétré sauf qu’il y a deux sous-expressions. c-letin La règle d’évaluation d’une liaison est habituelle. On ajoute simplement comme condition qu’il existe au moins une valeur possible pour e1. Cette condition n’est pas absolument nécessaire mais permet à l’analyse de fournir un résultat plus précis. c-letin-empty Dans le cas où il n’existe aucune valeur pour e1, il n’existe pas non plus de valeur pour l’expression globale. c-annot La règle d’évaluation d’une expression annotée est la même que dans la sé- mantique instrumentée. On ajoute simplement le label à l’ensemble des v-dépendances de l’expression. 4.3.3 Correction 4.3.3.1 Énoncé informel du théorème On veut montrer que la sémantique collectrice est une interprétation abstraite de la sémantique instrumentée multiple. C’est-à-dire qu’une évaluation par la sémantique 1574.3. SÉMANTIQUE COLLECTRICE instrumentée multiple peut être simulée par une évaluation collectrice et que la valeur ainsi obtenue sera moins précise que celle obtenue par une évaluation directe. Cette simulation nécessite une conversion de l’environnement et de la valeur retournée définies formellement à l’aide d’une fonction d’abstraction notée ↑ c im (•) (cf. figure 4.7) et d’une fonction de concrétisation notée ↑ im c (•) (cf. figure 4.8). Le lien entre l’évaluation directe par la sémantique instrumentée multiple et l’évaluation passant par la sémantique collectrice et les fonctions de conversion, est illustré en figure 4.2. 4.3.3.2 Illustration par l’exemple Pour illustrer le fonctionnement de la sémantique collectrice ainsi que la signification du théorème de correction que nous venons d’énoncer informellement, examinons un exemple simple. Nous nous limitons à un exemple très simple car les jugements d’évaluation deviennent vite volumineux. Rappelons que la sémantique instrumentée multiple ainsi que la sémantique collectrice n’ont pas pour but d’être utilisées en pratique. Leur rôle est de simplifier et de rendre modulaire la preuve de correction de l’analyse statique qui, elle, est utilisable en pratique. Exemple 1 : évaluation d’un couple Notons e1 le programme suivant : (x, l1:7) Nous nous intéressons à l’évaluation instrumentée multiple de ce programme dans un environnement instrumenté multiple tΓ im 1 contenant deux t-environnements instrumentés. tΓ im 1 = {(x, [ ∅ | [ {l2} | C1 ] ]); (x, [ ∅ | [ {l3} | C2 ] ])} En évaluant le programme e1 par la sémantique instrumentée multiple, dans l’environnement instrumenté multiple tΓ im 1 , on obtient le jugement suivant : tΓ im 1 ⊢ im e1 →→ { [ ∅ | [ ∅ | ( [ {l2} | C1 ], [ {l1} | 7 ]) ] ]; [ ∅ | [ ∅ | ( [ {l3} | C2 ], [ {l1} | 7 ]) ] ] } 1584.3. SÉMANTIQUE COLLECTRICE Nous allons maintenant nous intéresser à l’évaluation du même programme, dans le même environnement, mais en utilisant l’interprétation abstraite fournie par la sémantique collectrice. Commençons par abstraire l’environnement instrumenté multiple tΓ im 1 en un environnement collecteur que nous noterons tΓ c 1 : ↑ c im(tΓ im 1 ) = (x, [ ∅ | {l2; l3} | {C1; C2} ]) = tΓ c 1 Nous procédons alors à l’évaluation de e1 dans l’environnement collecteur obtenu après abstraction : tΓ c 1 ⊢ c e1 →→ [ ∅ | ∅ | { ( [ {l2; l3} | C1 ], [ {l1} | 7 ]); ( [ {l2; l3} | C2 ], [ {l1} | 7 ]) } ] Nous obtenons enfin la valeur instrumentée multiple correspondante en utilisant la fonction de concrétisation : ↑ im c ( [ ∅ | ∅ | { ( [ {l2; l3} | C1 ], [ {l1} | 7 ]); ( [ {l2; l3} | C2 ], [ {l1} | 7 ]) } ]) = { [ ∅ | [ ∅ | ( [ {l2; l3} | C1 ], [ {l1} | 7 ]) ] ]; [ ∅ | [ ∅ | ( [ {l2; l3} | C2 ], [ {l1} | 7 ]) ] ] } Nous constatons alors que la valeur instrumentée multiple obtenue directement est plus précise que celle obtenue par l’interprétation abstraite. En effet, cette dernière contient des dépendances supplémentaires. Formellement, nous avons la relation suivante : { [ ∅ | [ ∅ | ( [ {l2} | C1 ], [ {l1} | 7 ]) ] ]; [ ∅ | [ ∅ | ( [ {l3} | C2 ], [ {l1} | 7 ]) ] ] } ⊆im { [ ∅ | [ ∅ | ( [ {l2; l3} | C1 ], [ {l1} | 7 ]) ] ]; [ ∅ | [ ∅ | ( [ {l2; l3} | C2 ], [ {l1} | 7 ]) ] ] } 4.3.3.3 Énoncé formel du théorème Avant d’énoncer formellement le théorème de correction de la sémantique collectrice, il nous faut définir formellement quelques notions qui serviront à exprimer le théorème. Tout d’abord, nous définissons une fonction d’abstraction (cf. figure 4.7) ainsi qu’une fonction de concrétisation (cf. figure 4.8). La fonction d’abstraction (notée ↑ c im (•)) permet de transformer un ensemble de t-environnements instrumentés en un environnement 1594.3. SÉMANTIQUE COLLECTRICE abstr-im-env-empty tΓ im = {{}} ↑ c im(tΓ im) = {} abstr-im-env-cons tΓ im = {(x, tui ) ⊕ tΓ i | ∀tui ∈ v im.∀tΓ i ∈ tΓ c } ↑c im(v im) = tuc ↑ c im(tΓ im) = (x, tuc )⊕ ↑c im(tΓ c ) abstr-im-val ∀l.l ∈ tdc ⇔ ∃tdi .l ∈ tdi ∧ ∃u i . [ tdi | u i ] ∈ v im ∀l.l ∈ d c ⇔ ∃d i .l ∈ d i ∧ ∃(tdi , vi ). [ tdi | [ d i | v i ] ] ∈ v im vsi = {v i | ∃(tdi , di ). [ tdi | [ d i | v i ] ] ∈ v im} ↑ c im(v im) = [ tdc | d c | vsi ] Figure 4.7 – Sémantique collectrice : Définition de la fonction d’abstraction collecteur. La règle d’inférence abstr-im-env-cons se lit ainsi : pour abstraire un environnement tΓ im qui est de la forme {(x, tui ) ⊕ tΓ i | ∀tui ∈ v im.∀tΓ i ∈ tΓ c} pour une certaine valeur instrumentée multiple v im et un certain environnement collecteur tΓ c , on construit une valeur collectrice tuc pour x à partir de v im et on ajoute cette liaison à l’abstraction de tΓ c . La fonction de concrétisation (notée ↑ im c (•)) permet quant à elle de transformer une valeur collectrice en un ensemble de t-valeurs instrumentées. Nous pouvons alors composer ces fonctions avec la sémantique collectrice pour établir une simulation de la sémantique instrumentée multiple. Pour cela, nous commençons par abstraire l’environnement d’évaluation, puis nous évaluons le programme considéré à l’aide de la sémantique collectrice et enfin nous concrétisons la valeur collectrice. Il nous faut ensuite pouvoir comparer la valeur instrumentée multiple obtenue directement à l’aide de la sémantique instrumentée multiple et celle obtenue en passant par la sémantique collectrice. Pour cela, nous définissons une relation d’ordre (cf. figure 4.9 et 4.10) sur les valeurs instrumentées multiples. Nous exprimerons alors dans le théorème de correction que la valeur instrumentée multiple obtenue directement à l’aide de la sémantique instrumentée multiple est plus petite (ie. plus précise) que celle obtenue en passant par la sémantique collectrice. Le théorème de correction de la sémantique collectrice s’exprime alors ainsi : Théorème 4.3.1 (Correction de la sémantique collectrice). ∀(tΓ im, e, vim, tuc , tΓ c ). 1604.3. SÉMANTIQUE COLLECTRICE ↑ im c ( [ tdc | d c | vsi ]) := { [ tdc | [ d c | v i ] ] | v i ∈ vsi} ↑ im c (tΓ c ) := appendim c (tΓ c , {}) append-c-im-empty tΓ c = {} appendim c (tΓ c , tΓ im) = tΓ im append-c-im-cons tΓ c = (x, [ tdc | d c | vsi ]) ⊕ tΓ ′c tΓ ′im = appendim c (tΓ ′c , tΓ im) appendim c (tΓ c , tΓ im) = {(x, [ tdc | [ d c | v i ] ]) ⊕ tΓ i | v i ∈ vsi , tΓ i ∈ tΓ ′im} Figure 4.8 – Sémantique collectrice : Définition de la fonction de concrétisation le-td ∀l ∈ tdi 1 . l ∈ tdi 2 tdi 1 ⊆ tdi 2 le-d ∀l ∈ d i 1 . l ∈ d i 2 d i 1 ⊆ d i 2 le-ti-val tdi 1 ⊆ tdi 2 u i 1 ⊆ i u i 2 [ tdi 1 | u i 1 ] ⊆ i [ tdi 2 | u i 2 ] le-i-val d i 1 ⊆ d i 2 v i 1 ⊆ i v i 2 [ d i 1 | v i 1 ] ⊆ i [ d i 2 | v i 2 ] le-i-val-num n ⊆ i n le-i-val-bool b ⊆ i b le-i-val-constr0 C ⊆ i C le-i-val-constr1 u i 1 ⊆ i u i 2 D(u i 1 ) ⊆ i D(u i 2 ) le-i-val-couple u i 1 ⊆ i u i 2 u ′i 1 ⊆ i u ′i 2 (u i 1 , u′i 1 ) ⊆ i (u i 2 , u′i 2 ) le-i-val-closure Γ i 1 ⊆ i Γ i 2 < λx.e, Γ i 1 >⊆ i< λx.e, Γ i 2 >) le-i-val-rec-closure Γ i 1 ⊆ i Γ i 2 < recf.x.e, Γ i 1 >⊆ i< recf.x.e, Γ i 2 >) le-i-env-empty {} ⊆i {} le-i-env-cons u i 1 ⊆ i u i 2 Γ i 1 ⊆ i Γ i 2 (x, ui 1 ) ⊕ Γ i 1 ⊆ i (x, ui 2 ) ⊕ Γ i 2 le-ti-env-empty {} ⊆i {} le-ti-env-cons tui 1 ⊆ i u i 2 tΓ i 1 ⊆ i tΓ i 2 (x, tui 1 ) ⊕ tΓ i 1 ⊆ i (x, tui 2 ) ⊕ tΓ i 2 Figure 4.9 – Relation d’ordre sur les valeurs et environnements instrumentés le-im-val ∀tui 1 ∈ v im 1 . ∃tui 2 ∈ v im 2 . tui 1 ⊆ i tui 2 v im 1 ⊆ im v im 2 le-im-env ∀tΓ i 1 ∈ tΓ im 1 . ∃tΓ i 2 ∈ tΓ im 2 . tΓ i 1 ⊆ i tΓ i 2 tΓ im 1 ⊆ im tΓ im 2 Figure 4.10 – Relation d’ordre sur les valeurs et environnements instrumentés multiples 1614.3. SÉMANTIQUE COLLECTRICE tΓ im ⊢ im e →→ v im ⇒ tΓ c =↑ c im(tΓ im) ⇒ tΓ c ⊢ c e →→ tuc ⇒ v im ⊆im ↑ im c (tuc ) 4.3.3.4 Preuve de correction La preuve est faite par induction sur le jugement de la sémantique collectrice. On obtient alors 20 cas à prouver, suivant les 20 règles d’inférences de la sémantique collectrice. Nous expliquons ici quelques cas pour permettre au lecteur de comprendre plus facilement la manière dont la preuve a été faite. La preuve complète est disponible sous forme de code source Coq. cas c-num Ce cas est trivial, tout comme le cas c-constr-0. Nous allons tout de même l’expliquer rapidement pour illustrer le principe de la preuve qui est également utilisé dans les autres cas. Nous avons les hypothèses suivantes : tΓ im ⊢ im n →→ v im tΓ c =↑ c im(tΓ im) tΓ c ⊢ c n →→ [ ∅ | ∅ | {n} ] On veut alors prouver la propriété ci-dessous : v im ⊆ im↑ im c ( [ ∅ | ∅ | {n} ]) La règle de la sémantique instrumentée multiple i-multiple nous fait appliquer la règle i-num de la sémantique instrumentée. Pour tout environnement tΓ i ∈ tΓ im, cette dernière nous donne la valeur [ ∅ | [ ∅ | n ] ]. On en déduit que v im est le singleton { [ ∅ | [ ∅ | n ] ]}. D’autre part, la concrétisation de la valeur collectrice vaut : ↑ im c ( [ ∅ | ∅ | {n} ]) = { [ ∅ | [ ∅ | n ] ]}. Pour conclure, il nous suffit donc de prouver la propriété ci-dessous qui est évidente puisque la relation d’ordre sur les valeurs instrumentées multiples est réflexive. { [ ∅ | [ ∅ | n ] ]} ⊆im { [ ∅ | [ ∅ | n ] ]} 1624.3. SÉMANTIQUE COLLECTRICE cas c-constr-1 Ce cas est légèrement plus complexe que le précédent du fait que l’expression évaluée possède une sous-expression. Nous avons les hypothèses suivantes dont une hypothèse d’induction : i-multiple v im = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i D(e) →→ tui } tΓ im ⊢ im D(e) →→ v im tΓ c =↑ c im(tΓ im) c-constr-1 tΓ c ⊢ c e →→ [ tdc | d c | vsi ] tΓ c ⊢ c D(e) →→ [ tdc | ∅ | {D( [ d c | v i ]) | v i ∈ vsi } ] i-multiple v ′im = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i e →→ tui } tΓ im ⊢ im e →→ v ′im v ′im ⊆ im↑ im c ( [ tdc | d c | vsi ]) Nous devons alors montrer cette propriété : v im ⊆ im↑ im c ( [ tdc | ∅ | {D( [ d c | v i ]) | v i ∈ vsi } ]) Pour cela, nous montrons que pour un élément quelconque de tui ∈ v im, il existe un élément plus grand dans ↑ im c ( [ tdc | ∅ | {D( [ d c | v i ]) | v i ∈ vsi} ]). Puisque tui appartient à v im, il est issu d’un jugement d’évaluation instrumentée déduit de la règle d’inférence ci-dessous (en notant tui = [ tdi | [ ∅ | D(u i ) ] ]) : i-constr-1 tΓ i ⊢ i e →→ [ tdi | u i ] tΓ i ⊢ i D(e) →→ [ tdi | [ ∅ | D(u i ) ] ] Nous avons alors [ tdi | u i ] ∈ v ′im et nous pouvons donc appliquer notre hypothèse d’induction pour en déduire qu’il existe une valeur [ tdi 2 | [ d i 2 | v i 2 ] ] telle que : [ tdi 2 | [ d i 2 | v i 2 ] ] ∈↑im c ( [ tdc | d c | vsi ]) [ tdi | u i ] ⊆ i [ tdi 2 | [ d i 2 | v i 2 ] ] De la première de ces deux propriétés, nous déduisons que tdi 2 = tdc , d i 2 = d c et v i 2 ∈ vsi . Nous pouvons alors construire la valeur [ tdc | [ ∅ | D( [ d c | v i 2 ]) ] ] et montrer qu’elle 1634.3. SÉMANTIQUE COLLECTRICE respecte les conditions nous permettant de conclure : [ tdc | [ ∅ | D( [ d c | v i 2 ]) ] ] ∈↑im c ( [ tdc | ∅ | {D( [ d c | v i ]) | v i ∈ vsi } ]) [ tdi | [ ∅ | D(u i ) ] ] ⊆ i [ tdc | [ ∅ | D( [ d c | v i 2 ]) ] ] cas c-ident Une des particularités de la sémantique collectrice est d’avoir des règles d’inférence donnant une sémantique à un programme erroné, par exemple un programme évalué dans un environnement où certains identificateurs libres ne sont pas définis. Nous présentons donc la preuve des cas c-ident et c-ident-empty pour se rendre compte de la manière dont sont traités les cas d’erreur. Commençons par le cas c-ident. Nous avons les hypothèses suivantes : i-multiple v im = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i x →→ tui } tΓ im ⊢ im x →→ v im tΓ c =↑ c im(tΓ im) c-ident tuc = tΓ c [x] tΓ c ⊢ c x →→ tuc Nous devons alors montrer cette proriété : v im ⊆ im ↑ im c (tuc ) Pour cela, supposons que nous avons une t-valeur instrumentée tui ∈ v im et montrons qu’il existe une t-valeur instrumentée tui 2 ∈ ↑im c (tuc ) telle que tui ⊆i tui 2 . Puisque tui ∈ v im, il existe un t-environnement instrumenté tΓ i ∈ tΓ im tel que : i-ident tui = tΓ i [x] tΓ i ⊢ i x →→ tui D’après la définition des fonctions d’abstraction et de concrétisation, nous pouvons déduire qu’il existe une valeur tui 2 ∈↑im c (tΓ c [x]) telle que tui ⊆i tui 2 , ce qui nous permet de conclure. cas c-ident-empty Dans ce cas, nous avons les hypothèses suivantes : i-multiple v im = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i x →→ tui } tΓ im ⊢ im x →→ v im tΓ c =↑ c im(tΓ im) c-ident-empty x ̸∈ support(tΓ c ) tΓ c ⊢ c x →→ [ ∅ | ∅ | ∅ ] 1644.3. SÉMANTIQUE COLLECTRICE Et nous devons montrer : v im ⊆ im ↑ im c ( [ ∅ | ∅ | ∅ ]) Puisque ↑ im c ( [ ∅ | ∅ | ∅ ]) = ∅, il nous faut montrer que v im = ∅. D’après la définition de la fonction d’abstraction, les identificateurs présents dans n’importe quel élément de tΓ im sont les mêmes que ceux présents dans tΓ c . Ainsi, puisque l’identificateur x n’est pas présent dans l’environnement tΓ c , alors il n’est présent dans aucun t-environnement instrumenté appartenant à tΓ im. Il n’existe alors aucune règle d’inférence permettant d’évaluer l’expression x dans un t-environnement instrumenté appartenant à tΓ im. On peut donc conclure puisque v im = ∅. cas c-apply Le cas de l’application est un des cas les plus complexes en raison de la complexité des règles d’inférence correspondantes dans la sémantique collectrice et dans la sémantique instrumentée. Nous avons à notre disposition les hypothèses de l’énoncé du thèorème ainsi que deux hypothèses d’induction, correspondant aux deux sous-termes de l’expression : i-multiple v im = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i e1 e2 →→ tui } tΓ im ⊢ im e1 e2 →→ v im tΓ c =↑ c im(tΓ im) c-apply tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] v ′im = multiple_instrumented_application(tdc 1 , dc 1 , vsi 1 , tdc 2 , dc 2 , vsi 2 ) (∀l. l ∈ tdc ⇔ (∃(tdi , di , vi ). l ∈ tdi ∧ [ tdi | [ d i | v i ] ] ∈ v ′im)) (∀l. l ∈ d c ⇔ (∃(tdi , di , vi ). l ∈ d i ∧ [ tdi | [ d i | v i ] ] ∈ v ′im)) vsi = {v i | ∃(tdi , di ). [ tdi | [ d i | v i ] ] ∈ v ′im} tΓ c ⊢ c e1 e2 →→ [ tdc | d c | vsi ] i-multiple v im 1 = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i e1 →→ tui } tΓ im ⊢ im e1 →→ v im 1 i-multiple v im 2 = {tui | ∃tΓ i ∈ tΓ im. tΓ i ⊢ i e2 →→ tui } tΓ im ⊢ im e1 →→ v im 2 v im 1 ⊆ im ↑ im c ( [ tdc 1 | d c 1 | vsi 1 ]) v im 2 ⊆ im ↑ im c ( [ tdc 2 | d c 2 | vsi 2 ]) 1654.3. SÉMANTIQUE COLLECTRICE Et nous devons montrer : v im ⊆ im ↑ im c ( [ tdc | d c | vsi ]) Pour cela, supposons que nous avons une t-valeur instrumentée tui ∈ v im et montrons qu’il existe une t-valeur instrumentée tu′i ∈ ↑im c ( [ tdc | d c | vsi ]) telle que tui ⊆i tu′i . Puisque tui ∈ v im, il existe une évaluation instrumentée de l’expression e1 e2 en la t-valeur instrumentée tui dans un certain t-environnement instrumenté tΓ i ∈ tΓ im. Il y a alors deux cas possibles selon que la règle d’inférence de cette évaluation est i-apply ou i-apply-rec. – cas i-apply i-apply tΓ i ⊢ i e1 →→ [ tdi 1 | [ d i 1 | < λx.e, Γ i 1 > ] ] tΓ i ⊢ i e2 →→ tui 2 tui 2 = [ tdi 2 | u i 2 ] (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] tΓ i ⊢ i e1 e2 →→ [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] tui = [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] D’après nos hypothèses d’induction, nous savons qu’il existe des t-valeurs instrumentées tu′i 1 ∈ ↑im c ( [ tdc 1 | d c 1 | vsi 1 ]) et tu′i 2 ∈ ↑im c ( [ tdc 2 | d c 2 | vsi 2 ]) vérifiant les propriétés suivantes : [ tdi 1 | [ d i 1 | < λx.e, Γ i 1 > ] ] ⊆i tu′i 1 tui 2 ⊆i tu′i 2 Puisque tu′i 1 ∈ ↑im c ( [ tdc 1 | d c 1 | vsi 1 ]), nous savons qu’il existe une valeur simple instrumentée v ′i 1 telle que tu′i 1 = [ tdc 1 | [ d c 1 | v ′i 1 ] ] et v ′i 1 ∈ vsi 1 . De même, il existe une valeur simple instrumentée v ′i 2 telle que tu′i 2 = [ tdc 2 | [ d c 2 | v ′i 2 ] ] et v ′i 2 ∈ vsi 2 . Nous déplions alors la définition de la relation d’ordre pour obtenir les relations suivantes (en notant tui 2 = [ tdi 2 | [ d i 2 | v i 2 ] ]) : tdi 1 ⊆i tdc 1 d i 1 ⊆i d c 1 < λx.e, Γ i 1 >⊆i v ′i 1 v ′i 1 =< λx.e, Γ ′i 1 > Γ i 1 ⊆i Γ ′i 1 tdi 2 ⊆i tdc 2 d i 2 ⊆i d c 2 v i 2 ⊆i v ′i 2 1664.3. SÉMANTIQUE COLLECTRICE Nous utilisons le lemme intermédiaire suivant pour déduire un jugement d’évaluation instrumentée de l’expression e dans l’environnement (x, tu′i 2 )⊕ ↑ti i (Γ′i 1 ). La preuve de ce lemme a été réalisée en Coq (Lemma ival_of_in_le_itenv). Voici son énoncé : ∀(Γi , Γ ′i , e, tui ).(Γi 1 ⊆ i Γ ′i 1 ) ⇒ (tΓ i ⊢ i e →→ tui ) ⇒ ∃tu′i .(tΓ ′i ⊢ i e →→ tu′i )∧(tui ⊆ i tu′i ) Nous obtenons alors une t-valeur instrumentée [ td′i | [ d ′i | v ′i ] ] vérifiant le jugement d’évaluation instrumentée suivant et la relation d’ordre suivante : (x, tu′i 2 )⊕ ↑ti i (Γ′i 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] [ tdi | [ d i | v i ] ] ⊆ i [ td′i | [ d ′i | v ′i ] ] Pour conclure le cas i-apply, il nous faut maintenant montrer que la t-valeur instrumentée [ tdc | [ d c | v ′i ] ] convient. C’est à dire qu’elle vérifie les deux propriétés suivantes : [ tdc | [ d c | v ′i ] ] ∈ ↑im c ( [ tdc | d c | vsi ]) et tui ⊆i [ tdc | [ d c | v ′i ] ]. Commençons par la première des deux propriétés à prouver. En dépliant la définition de la fonction de concrétisation, la propriété à prouver se réduit à v ′i ∈ vsi . Pour cela, il nous faut montrer ∃(tdi , di ). [ tdi | [ d i | v ′i ] ] ∈ v ′im. Nous allons donc montrer que [ tdc 1∪tdc 2∪td′i∪d c 1 | [ d c 1∪d ′i | v ′i ] ] ∈ v ′im. Nous déplions ensuite la valeur de v ′im ainsi que celle de multiple_instrumented_application(tdc 1 , dc 1 , vsi 1 , tdc 2 , dc 2 , vsi 2 ). Ainsi, la propriété à montrer devient : [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] ∈ { tui | ( ∃ < λx.e, Γ i 1 >∈ vsi 1 . ∃v i 2 ∈ vsi 2 . ∃(tdi , ti , vi ). ∃tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ]. (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] ∧ tui = [ tdc 1 ∪ tdc 2 ∪ tdi ∪ d c 1 | [ d c 1 ∪ d i | v i ] ] ) ∨ ( ∃ < recf.x.e, Γ i 1 >∈ vsi 1 . ∃v i 2 ∈ vsi 2 . ∃(tdi , ti , vi ). ∃tui f = [ tdc 1 | [ d c 1 | < recf.x.e, Γ i 1 > ] ]. ∃tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ]. (f, tui f ) ⊕ (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] ∧ tui = [ tdc 1 ∪ tdc 2 ∪ tdi ∪ d c 1 | [ d c 1 ∪ d i | v i ] ] ) } 1674.3. SÉMANTIQUE COLLECTRICE Puisque nous sommes dans le cas de l’application d’une fonction non récursive, c’est la première partie de la disjonction que nous allons prouver. Nous prouvons cette propriété à l’aide des propriétés suivantes déjà prouvées plus haut : < λx.e, Γ ′i 1 >∈ vsi 1 v ′i 2 ∈ vsi 2 (x, tu′i 2 )⊕ ↑ti i (Γ′i 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] Montrons maintenant la seconde propriété qui nous permettra de conclure. Après avoir déplié la valeur de tui elle exprime ainsi : [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] ⊆ i [ tdc | [ d c | v ′i ] ] En dépliant la définition de la relation d’ordre, nous obtenons les trois propriétés suivantes à prouver : ∀l ∈ (tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 ).l ∈ tdc ∀l ∈ (d i 1 ∪ d i ).l ∈ d c v i ⊆i v ′i Prouvons la propriété concernant les t-dépendances. Soit l ∈ (tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 ). D’après la définition de tdc , il nous faut montrer que ∃(tdi , di , vi ). l ∈ tdi ∧ [ tdi | [ d i | v i ] ] ∈ v ′im. Nous savons déjà que [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] ∈ v ′im Montrons donc que l ∈ (tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 ). Cette propriété est issue des relations d’ordre déjà montrées et de la compatibilité de la relation d’ordre avec la concaténation 1 . Les relations concernées sont : tdi 1 ⊆i tdc 1 , tdi 2 ⊆i tdc 2 , [ tdi | [ d i | v i ] ] ⊆i [ td′i | [ d ′i | v ′i ] ] et d i 1 ⊆i d c 1 . Prouvons la propriété concernant les v-dépendances. Soit l ∈ (d i 1∪d i ). D’après la définition de d c , il nous faut montrer que ∃(tdi , di , vi ). l ∈ d i ∧ [ tdi | [ d i | v i ] ] ∈ v ′im. Nous savons déjà que [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] ∈ v ′im Montrons donc que l ∈ (d c 1 ∪ d ′i ). Cette propriété est issue des relations d’ordre déjà montrées et de la compatibilité de la relation d’ordre avec la concaténation 2 . Les relations concernées sont : d i 1 ⊆i d c 1 et [ tdi | [ d i | v i ] ] ⊆i [ td′i | [ d ′i | v ′i ] ]. 1. ∀(td1, td2, td′ 1, td′ 2). (td1 ⊆ td′ 1) ∧ (td2 ⊆ td′ 2) ⇒ td1 ∪ td2 ⊆ td′ 1 ∪ td′ 2 2. ∀(d1, d2, d′ 1, d′ 2). (d1 ⊆ d ′ 1) ∧ (d2 ⊆ d ′ 2) ⇒ d1 ∪ d2 ⊆ d ′ 1 ∪ d ′ 2 1684.3. SÉMANTIQUE COLLECTRICE La propriété concernant les valeurs simples instrumentées vient directement de la relation [ tdi | [ d i | v i ] ] ⊆i [ td′i | [ d ′i | v ′i ] ] prouvée précédemment. Le cas i-apply est donc complètement prouvé. – cas i-apply-rec i-apply-rec tΓ i ⊢ i e1 →→ tui 1 tui 1 = [ tdi 1 | [ d i 1 | < recf.x.e, Γ i 1 > ] ] tΓ i ⊢ i e2 →→ tui 2 tui 2 = [ tdi 2 | u i 2 ] (f, tui 1 ) ⊕ (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] tΓ i ⊢ i e1 e2 →→ [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] tui = [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] D’après nos hypothèses d’induction, nous savons qu’il existe des t-valeurs instrumentées tu′i 1 ∈ ↑im c ( [ tdc 1 | d c 1 | vsi 1 ]) et tu′i 2 ∈ ↑im c ( [ tdc 2 | d c 2 | vsi 2 ]) vérifiant les propriétés suivantes : [ tdi 1 | [ d i 1 | < recf.x.e, Γ i 1 > ] ] ⊆i tu′i 1 tui 2 ⊆i tu′i 2 Puisque tu′i 1 ∈ ↑im c ( [ tdc 1 | d c 1 | vsi 1 ]), nous savons qu’il existe une valeur simple instrumentée v ′i 1 telle que tu′i 1 = [ tdc 1 | [ d c 1 | v ′i 1 ] ] et v ′i 1 ∈ vsi 1 . De même, il existe une valeur simple instrumentée v ′i 2 telle que tu′i 2 = [ tdc 2 | [ d c 2 | v ′i 2 ] ] et v ′i 2 ∈ vsi 2 . Nous déplions alors la définition de la relation d’ordre pour obtenir les relations suivantes (en notant tui 2 = [ tdi 2 | [ d i 2 | v i 2 ] ]) : tdi 1 ⊆i tdc 1 d i 1 ⊆i d c 1 < recf.x.e, Γ i 1 >⊆i v ′i 1 v ′i 1 =< recf.x.e, Γ ′i 1 > Γ i 1 ⊆i Γ ′i 1 tdi 2 ⊆i tdc 2 d i 2 ⊆i d c 2 v i 2 ⊆i v ′i 2 Comme dans le cas précédent, nous utilisons le lemme intermédiaire suivant pour déduire un jugement d’évaluation instrumentée de l’expression e dans l’environnement (f, tu′i 1 ) ⊕ (x, tu′i 2 )⊕ ↑ti i (Γ′i 1 ). La preuve de ce lemme a été réalisée en Coq (Lemma ival_of_in_le_itenv). Voici son énoncé : ∀(Γi , Γ ′i , e, tui ).(Γi 1 ⊆ i Γ ′i 1 ) ⇒ (tΓ i ⊢ i e →→ tui ) ⇒ ∃tu′i .(tΓ ′i ⊢ i e →→ tu′i )∧(tui ⊆ i tu′i ) 1694.3. SÉMANTIQUE COLLECTRICE Nous obtenons alors une t-valeur instrumentée [ td′i | [ d ′i | v ′i ] ] vérifiant le jugement d’évaluation instrumentée suivant et la relation d’ordre suivante : (f, tu′i 1 ) ⊕ (x, tu′i 2 )⊕ ↑ti i (Γ′i 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] [ tdi | [ d i | v i ] ] ⊆ i [ td′i | [ d ′i | v ′i ] ] Pour conclure le cas i-apply-rec, il nous faut maintenant montrer que la t-valeur instrumentée [ tdc | [ d c | v ′i ] ] convient. C’est à dire qu’elle vérifie les deux propriétés suivantes : [ tdc | [ d c | v ′i ] ] ∈ ↑im c ( [ tdc | d c | vsi ]) et tui ⊆i [ tdc | [ d c | v ′i ] ]. Commençons par la première des deux propriétés à prouver. En dépliant la définition de la fonction de concrétisation, la propriété à prouver se réduit à v ′i ∈ vsi . Pour cela, il nous faut montrer ∃(tdi , di ). [ tdi | [ d i | v ′i ] ] ∈ v ′im. Nous allons donc montrer que [ tdc 1∪tdc 2∪td′i∪d c 1 | [ d c 1∪d ′i | v ′i ] ] ∈ v ′im. Nous déplions ensuite la valeur de v ′im ainsi que celle de multiple_instrumented_application(tdc 1 , dc 1 , vsi 1 , tdc 2 , dc 2 , vsi 2 ). Ainsi, la propriété à montrer devient : [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] ∈ { tui | ( ∃ < λx.e, Γ i 1 >∈ vsi 1 . ∃v i 2 ∈ vsi 2 . ∃(tdi , ti , vi ). ∃tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ]. (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] ∧ tui = [ tdc 1 ∪ tdc 2 ∪ tdi ∪ d c 1 | [ d c 1 ∪ d i | v i ] ] ) ∨ ( ∃ < recf.x.e, Γ i 1 >∈ vsi 1 . ∃v i 2 ∈ vsi 2 . ∃(tdi , ti , vi ). ∃tui f = [ tdc 1 | [ d c 1 | < recf.x.e, Γ i 1 > ] ]. ∃tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ]. (f, tui f ) ⊕ (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ tdi | [ d i | v i ] ] ∧ tui = [ tdc 1 ∪ tdc 2 ∪ tdi ∪ d c 1 | [ d c 1 ∪ d i | v i ] ] ) } Puisque nous sommes dans le cas de l’application d’une fonction récursive, c’est la seconde partie de la disjonction que nous allons prouver. Nous prouvons cette propriété à l’aide des propriétés suivantes déjà prouvées plus haut : < recf.x.e, Γ ′i 1 >∈ vsi 1 1704.3. SÉMANTIQUE COLLECTRICE v ′i 2 ∈ vsi 2 (f, tu′i 1 ) ⊕ (x, tu′i 2 )⊕ ↑ti i (Γ′i 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] Montrons maintenant la seconde propriété qui nous permettra de conclure. Après avoir déplié la valeur de tui elle exprime ainsi : [ tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 | [ d i 1 ∪ d i | v i ] ] ⊆ i [ tdc | [ d c | v ′i ] ] En dépliant la définition de la relation d’ordre, nous obtenons les trois propriétés suivantes à prouver : ∀l ∈ (tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 ).l ∈ tdc ∀l ∈ (d i 1 ∪ d i ).l ∈ d c v i ⊆i v ′i Nous procédons de la même manière que dans le cas i-apply. Prouvons la propriété concernant les t-dépendances. Soit l ∈ (tdi 1 ∪ tdi 2 ∪ tdi ∪ d i 1 ). D’après la définition de tdc , il nous faut montrer que ∃(tdi , di , vi ). l ∈ tdi ∧ [ tdi | [ d i | v i ] ] ∈ v ′im. Nous savons déjà que [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] ∈ v ′im Montrons donc que l ∈ (tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 ). Cette propriété est issue des relations d’ordre déjà montrées et de la compatibilité de la relation d’ordre avec la concaténation. Les relations concernées sont : tdi 1 ⊆i tdc 1 , tdi 2 ⊆i tdc 2 , [ tdi | [ d i | v i ] ] ⊆i [ td′i | [ d ′i | v ′i ] ] et d i 1 ⊆i d c 1 . Prouvons la propriété concernant les v-dépendances. Soit l ∈ (d i 1∪d i ). D’après la définition de d c , il nous faut montrer que ∃(tdi , di , vi ). l ∈ d i ∧ [ tdi | [ d i | v i ] ] ∈ v ′im. Nous savons déjà que [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] ∈ v ′im. Montrons donc que l ∈ (d c 1 ∪ d ′i ). Cette propriété est issue des relations d’ordre déjà montrées et de la compatibilité de la relation d’ordre avec la concaténation. Les relations concernées sont : d i 1 ⊆i d c 1 et [ tdi | [ d i | v i ] ] ⊆i [ td′i | [ d ′i | v ′i ] ]. La propriété concernant les valeurs simples instrumentées vient directement de la relation [ tdi | [ d i | v i ] ] ⊆i [ td′i | [ d ′i | v ′i ] ] prouvée précédemment. Le cas i-apply-rec est donc complètement prouvé. Ce qui conclut le cas c-apply. 1714.4. SÉMANTIQUE ABSTRAITE 4.4 Sémantique abstraite Ce chapitre présente enfin la sémantique abstraite, qui constitue ce que nous appelons notre analyse statique. Le but de cette analyse est de calculer les dépendances de n’importe quel programme écrit dans notre langage et de permettre à l’utilisateur de spécifier les environnements d’évaluation possibles avec souplesse. La sémantique abstraite est une interprétation abstraite de la sémantique collectrice présentée dans le chapitre précédent. La sémantique collectrice avait permis de faire ressortir le calcul des dépendances lors d’un ensemble d’évaluations instrumentées simultanées. Cependant, cette sémantique n’était pas calculable compte tenu des ensembles de valeurs simples instrumentées éventuellement infinis présents dans les valeurs collectrices. La sémantique abstraite vient résoudre ce problème de non-calculabilité en remplaçant ces ensembles de valeurs simples par un nombre fini de valeurs simples abstraites. Elle présente deux intérets par rapport à la sémantique instrumentée. D’une part, elle permet d’analyser un programme sans avoir besoin de connaître avec précision son environnement d’évaluation. En effet, un environnement abstrait permet de représenter un ensemble d’environnements instrumentés. Et une seule évaluation abstraite permet de simuler un ensemble d’évaluations instrumentées possibles. D’autre part, cette sémantique termine pour n’importe quel programme à évaluer et n’importe quel environnement d’évaluation. On est donc certain d’obtenir un résultat en un temps fini. En effet, dans la sémantique instrumentée, deux cas pouvaient provoquer la non-terminaison de l’évaluation d’un programme : une erreur de type ou une boucle infinie. La sémantique abstraite permet de résoudre ces deux cas. Le cas d’une erreur de type résulte en une valeur spéciale qui indique qu’il n’existe aucune évaluation instrumentée correspondante. Le cas de la boucle infinie est résolu à l’aide d’une sur-approximation des dépendances et de la valeur de retour qui permet de stopper les appels récursifs infinis. 4.4.1 Algèbre des valeurs La sémantique abstraite manipule des valeurs abstraites. Ces valeurs constituent une abstraction des valeurs collectrices. Les fonctions d’abstraction et de concrétisation sont 1724.4. SÉMANTIQUE ABSTRAITE définies formellement en figures 4.11, 4.12 et 4.13. 4.4.1.1 Valeurs Une t-valeur abstraite (notée tua ) est composée d’un ensemble de t-dépendances tda et d’une v-valeur abstraite u a . tua := [ tda | u a ] Valeur avec annotation de t-dépendance Une v-valeur abstraite (notée u a ) est composée d’un ensemble de v-dépendances d a et d’une valeur simple abstraite v a . u a := [ d a | v a ] Valeur avec annotation de v-dépendance Enfin, une valeur simple abstraite (notée v a ) est une valeur simple dont les sous-termes sont des v-valeurs abstraites u a . v a := C | D(u a ) | (u a 1 , ua 2 ) Constructeurs de données < λx.e, Γ a > Fermeture < recf.x.e, Γ a > Fermeture récursive ⊥ Aucune valeur ⊤ Valeur quelconque On peut remarquer qu’il n’existe pas de valeur abstraite permettant de représenter une constante numérique ou bien un booléen. En effet, toute valeur numérique ou booléenne est abstraite en la valeur ⊤, comme on peut le constater dans la définition formelle de la fonction d’abstraction (cf. figures 4.11 et 4.12). En pratique, cette approximation permet à l’analyse de gagner en rapidité sans trop perdre en précision. En effet, les valeurs numériques et booléennes sont rarement connues statiquement, lors de l’analyse d’un programme. Il aurait été possible d’abstraire ces valeurs de façon moins brutale (par exemple à l’aide de listes d’intervalles représentant les valeurs possibles), cependant, ce n’est pas l’objet de notre analyse et il sera tout à fait possible de proposer par la suite une interprétation abstraite plus fine de la sémantique collectrice. 4.4.1.2 Ensembles de dépendances Dans les valeurs abstraites, les ensembles de t-dépendances (resp. de v-dépendances) sont des ensembles de labels, comme dans les sémantiques instrumentée et collectrice. 1734.4. SÉMANTIQUE ABSTRAITE Abstraction d’une t-valeur collectrice : abstr-c-val ↑ a im({ [ d c | v i ] | v i ∈ vsi }) = u a ↑ a c ( [ tdc | d c | vsi ]) = [ tda | u a ] Abstraction d’un ensemble de v-valeurs instrumentées : abstr-im-a-val-empty ↑ a im(∅) = [ ∅ | ⊥ ] abstr-im-a-val-contr-0 usi ⊂ { [ d i | C ] | ∀d i } usi ̸= ∅ d_of_usi (usi ) = d a ↑ a im(usi ) = [ d a | C ] abstr-im-a-val-contr-1 usi ⊂ { [ d i | D(u i ) ] | ∀(d i , ui )} usi ̸= ∅ d_of_usi (usi ) = d a ↑ a im({u i | ∃d i . [ d i | D(u i ) ] ∈ usi }) = u a ↑ a im(usi ) = [ d a | D(u a ) ] abstr-im-a-val-couple usi ⊂ { [ d i | (u i 1 , ui 2 ) ] | ∀(d i , ui 1 , ui 2 )} usi ̸= ∅ d_of_usi (usi ) = d a ↑ a im({u i 1 | ∃(d i , ui 2 ). [ d i | (u i 1 , ui 2 ) ] ∈ usi }) = u a 1 ↑ a im({u i 2 | ∃(d i , ui 1 ). [ d i | (u i 1 , ui 2 ) ] ∈ usi }) = u a 2 ↑ a im(usi ) = [ d a | (u a 1 , ua 2 ) ] abstr-im-a-val-closure usi ⊂ { [ d i | < λx.e, Γ i > ] | ∀(d i , Γ i )} usi ̸= ∅ d_of_usi (usi ) = d a ↑ a im({Γ i | ∃d i . [ d i | < λx.e, Γ i > ] ∈ usi }) = Γa ↑ a im(usi ) = [ d a | < λx.e, Γ a > ] abstr-im-a-val-closure-rec usi ⊂ { [ d i | < recf.x.e, Γ i > ] | ∀(d i , Γ i )} usi ̸= ∅ d_of_usi (usi ) = d a ↑ a im({Γ i | ∃d i . [ d i | < recf.x.e, Γ i > ] ∈ usi }) = Γa ↑ a im(usi ) = [ d a | < recf.x.e, Γ a > ] abstr-im-a-val-unknown usi ̸= ∅ usi ̸⊂ { [ d i | C ] | ∀d i } usi ̸⊂ { [ d i | D(u i ) ] | ∀(d i , ui )} usi ̸⊂ { [ d i | (u i 1 , ui 2 ) ] | ∀(d i , ui 1 , ui 2 )} usi ̸⊂ { [ d i | < λx.e, Γ i > ] | ∀(d i , Γ i )} usi ̸⊂ { [ d i | < recf.x.e, Γ i > ] | ∀(d i , Γ i )} ↑ a im(usi ) = [ ∅ | ⊤ ] Figure 4.11 – Sémantique abstraite : Définition de la fonction d’abstraction (partie 1/2) 1744.4. SÉMANTIQUE ABSTRAITE Récolte des v-dépendances d’un ensemble de v-valeurs instrumentées : abstr-im-da ∀l.l ∈ d a ⇔ ∃(d i , vi ).l ∈ d i ∧ [ d i | v i ] ∈ usi d_of_usi (usi ) = d a Abstraction d’un ensemble de v-environnements instrumentés : abstr-im-a-env-empty ↑ a im({}) = {} abstr-im-a-env-cons Γ im = {(x, ui ) ⊕ Γ i | ∀u i ∈ usi .Γ i ∈ Γ ′im} ↑ a im(usi ) = u a ↑ a im(Γ′im) = Γa ↑ a im(Γim) = (x, ua ) ⊕ Γ a Abstraction d’un t-environnement collecteur : abstr-c-a-env-empty ↑ a c ({}) = {} abstr-c-a-env-cons ↑ a c (tuc ) = tua ↑ a c (tΓ c ) = tΓ a ↑ a c ((x, tuc ) ⊕ tΓ c ) = (x, tua ) ⊕ tΓ a Figure 4.12 – Sémantique abstraite : Définition de la fonction d’abstraction (partie 2/2) Concrétisation d’une t-valeur abstraite : ↑ c a ( [ tda | [ d a | v a ] ]) := [ tda | d a | ↑c a (v a ) ] Concrétisation d’une valeur simple abstraite : ↑ c a (C) := {C} ↑ c a (D( [ d a | v a ])) := {D( [ d a | v i ]) | ∀v i ∈↑c a (v a )} ↑ c a (( [ d a 1 | v a 1 ], [ d a 2 | v a 2 ])) := {( [ d a 1 | v i 1 ], [ d a 2 | v i 2 ]) | ∀v i 1 ∈ ↑c a (v a 1 ).∀v i 2 ∈ ↑c a (v a 2 )} ↑ c a (< λx.e, Γ a >) := {< λx.e, Γ i > | ∀Γ i ∈↑c a (Γa )} ↑ c a (< recf.x.e, Γ a >) := {< recf.x.e, Γ i > | ∀Γ i ∈↑c a (Γa )} ↑ c a (⊥) := ∅ ↑ c a (⊤) := {v i | ∀v i ∈ Vi} Concrétisation d’un v-environnement abstrait : ↑ c a ({}) := {{}} ↑ c a ((x, [ d a | v a ]) ⊕ Γ a ) := {(x, [ d a | v i ]) ⊕ Γ i | ∀v i ∈↑c a (v a ).∀Γ i ∈↑c a (Γa )} Concrétisation d’un t-environnement abstrait : ↑ c a ({}) := {{}} ↑ c a ((x, tua ) ⊕ tΓ a ) := (x, ↑ c a (tua ))⊕ ↑c a (tΓ a ) Figure 4.13 – Sémantique abstraite : Définition de la fonction de concrétisation 1754.4. SÉMANTIQUE ABSTRAITE tda := {l1; . . . ; ln} t-dépendances d a := {l1; . . . ; lm} v-dépendances 4.4.1.3 Environnements De même que pour la sémantique sur-instrumentée et la sémantique instrumentée, on distingue 2 types d’environnements. Un t-environnement abstrait permet de lier chaque identificateur à une t-valeur abstraite. Ce sont les environnements abstraits dans lesquels sont évalués les programmes. tΓ a := (x1, tua 1 ); . . . ; (xn, tua n ) t-environnement abstrait Un v-environnement abstrait permet de lier chaque identificateur à une v-valeur abstraite. Ce sont les environnements abstraite encapsulés dans les fermetures (récursives ou non). Γ a := (x1, ua 1 ); . . . ; (xn, ua n ) v-environnement abstraite 4.4.2 Règles d’inférence Le jugement d’évaluation de la sémantique abstraite prend la forme suivante : tΓ a ⊢ a e →→ tua où e est l’expression évaluée, tΓ a le t-environnement abstrait dans lequel on effectue l’évaluation et tua la t-valeur abstraite résultat de l’évaluation. Ce jugement est défini par les règles d’inférence présentées en figure 4.14. Des explications détaillées de ces règles sont données ci-dessous. a-num La règle d’évaluation d’une constante entière est semblable à celle de la sémantique instrumentée. L’ensemble des t-dépendances instrumentées est vide, de même que l’ensemble des v-dépendances instrumentées. Par contre, en ce qui concerne la valeur simple abstraite, elle vaut ⊤ qui est une abstraction de la constante entière. 1764.4. SÉMANTIQUE ABSTRAITE a-num tΓ a ⊢ a n →→ [ ∅ | [ ∅ | ⊤ ] ] a-ident tua = tΓ a [x] tΓ a ⊢ a x →→ tua a-ident-empty x ̸∈ support(tΓ a ) tΓ a ⊢ a x →→ [ ∅ | [ ∅ | ⊥ ] ] a-abstr tΓ a ⊢ a λx.e →→ [ ∅ | [ ∅ | < λx.e, ↑ a ta(tΓ a ) > ] ] a-abstr-rec tΓ a ⊢ a recf.x.e →→ [ ∅ | [ ∅ | < recf.x.e, ↑ a ta(tΓ a ) > ] ] a-letin tΓ a ⊢ a e1 →→ tua 1 tua 1 = [ tda 1 | u a 1 ] (x, tua 1 ) ⊕ tΓ a ⊢ a e2 →→ [ tda 2 | u a 2 ] tΓ a ⊢ a let x = e1 in e2 →→ [ tda 1 ∪ tda 2 | u a 2 ] a-apply tΓ a ⊢ a e1 →→ [ tda 1 | [ d a 1 | < λx.e, Γ a 1 > ] ] tΓ a ⊢ a e2 →→ tua 2 tua 2 = [ tda 2 | u a 2 ] (x, tua 2 )⊕ ↑ta a (Γa 1 ) ⊢ a e →→ [ tda | [ d a | v a ] ] tΓ a ⊢ a e1 e2 →→ [ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 | [ d a 1 ∪ d a | v a ] ] a-apply-rec tΓ a ⊢ a e1 →→ [ tda 1 | [ d a 1 | < recf.x.e, Γ a 1 > ] ] tua 1 = [ tda 1 | [ d_of_freevars(recf.x.e, tΓ a ) | ⊤ ] ] tΓ a ⊢ a e2 →→ tua 2 tua 2 = [ tda 2 | u a 2 ] (f, tua 1 ) ⊕ (x, tua 2 )⊕ ↑ta a (Γa 1 ) ⊢ a e →→ [ tda | [ d a | v a ] ] tΓ a ⊢ a e1 e2 →→ [ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 | [ d a 1 ∪ d a | v a ] ] a-apply-unknown tΓ a ⊢ a e1 →→ [ tda 1 | [ d a 1 | v a 1 ] ] tΓ a ⊢ a e2 →→ [ tda 2 | [ d a 2 | v a 2 ] ] ∀(f, x, e, Γ a 1 ).va 1 ̸=< λx.e, Γ a 1 > ∧v a 1 ̸=< recf.x.e, Γ a 1 > tΓ a ⊢ a e1 e2 →→ [ tda 1 ∪ tda 2 ∪ d a 1 ∪ d a 2 | [ d a 1 ∪ d a 2 | ⊤ ] ] a-if tΓ a ⊢ a e →→ [ tda | [ d a | v a ] ] tΓ a ⊢ a e1 →→ [ tda 1 | [ d a 1 | v a 1 ] ] tΓ a ⊢ a e2 →→ [ tda 2 | [ d a 2 | v a 2 ] ] tΓ a ⊢ a if e then e1 else e2 →→ [ d a ∪ tda ∪ tda 1 ∪ tda 2 | [ d a ∪ d a 1 ∪ d a 2 | ⊤ ] ] a-match tΓ a ⊢ a e →→ tua tua = [ tda | [ d a | v a ] ] tua , p ⊢ a p tΓ a p tΓ a p ⊕ tΓ a ⊢ a e1 →→ [ tda 1 | [ d a 1 | v a 1 ] ] tΓ a ⊢ a match e with p → e1 | x → e2 →→ [ d a ∪ tda ∪ tda 1 | [ d a ∪ d a 1 | v a 1 ] ] a-match-var tΓ a ⊢ a e →→ tua tua = [ tda | [ d a | v a ] ] tua , p ⊢ a p ⊥ (x, tua ) ⊕ tΓ a ⊢ a e2 →→ [ tda 2 | [ d a 2 | v a 2 ] ] tΓ a ⊢ a match e with p → e1 | x → e2 →→ [ d a ∪ tda ∪ tda 2 | [ d a ∪ d a 2 | v a 2 ] ] a-match-unknown tΓ a ⊢ a e →→ tua tua = [ tda | [ d a | v a ] ] tua , p ⊢ a p? tΓ a p tΓ a p ⊕ tΓ a ⊢ a e1 →→ [ tda 1 | [ d a 1 | v a 1 ] ] (x, tua ) ⊕ tΓ a ⊢ a e2 →→ [ tda 2 | [ d a 2 | v a 2 ] ] tΓ a ⊢ a match e with p → e1 | x → e2 →→ [ d a ∪ tda ∪ tda 1 ∪ tda 2 | [ d a ∪ d a 1 ∪ d a 2 | ⊤ ] ] a-match-error tΓ a ⊢ a e →→ [ tda | [ d a | v a ] ] tua , p ⊢ a p × tΓ a ⊢ a match e with p → e1 | x → e2 →→ [ ∅ | [ ∅ | ⊥ ] ] a-constr-0 tΓ a ⊢ a C →→ [ ∅ | [ ∅ | C ] ] a-constr-1 tΓ a ⊢ a e →→ [ tda | u a ] tΓ a ⊢ a D(e) →→ [ tda | [ ∅ | D(u a ) ] ] a-couple tΓ a ⊢ a e1 →→ [ tda 1 | u a 1 ] tΓ a ⊢ a e2 →→ [ tda 2 | u a 2 ] tΓ a ⊢ a (e1, e2) →→ [ tda 1 ∪ tda 2 | [ ∅ | (u a 1 , ua 2 ) ] ] a-annot tΓ a ⊢ a e →→ [ tda | [ d a | v a ] ] tΓ a ⊢ a l : e →→ [ tda | [ l; d a | v a ] ] Figure 4.14 – Sémantique abstraite 1774.4. SÉMANTIQUE ABSTRAITE d_of_freevars(e, tΓ a) := dof_aux(e, tΓ a, ∅, ∅) dof_aux(n, tΓ a, bvars, acc) := acc dof_aux(C, tΓ a, bvars, acc) := acc dof_aux(D(e), tΓ a, bvars, acc) := dof_aux(e, tΓ a, bvars, acc) dof_aux(x, tΓ a, bvars, acc) := acc si x ∈ bvars dof_aux(x, tΓ a, bvars, acc) := d a ∪ acc si x ̸∈ bvars ∧ tΓ a[x] = [ tda | [ d a | v a ] ] dof_aux(λx.e, tΓ a, bvars, acc) := dof_aux(e, tΓ a, x; bvars, acc) dof_aux(recf.x.e, tΓ a, bvars, acc) := dof_aux(e, tΓ a, f; x; bvars, acc) dof_aux(e1 e2, tΓ a, bvars, acc) := dof_aux(e2, tΓ a, bvars, acc1) pour acc1 = dof_aux(e1, tΓ a, bvars, acc) dof_aux(if e then e1 else e2, tΓ a, bvars, acc) := dof_aux(e2, tΓ a, bvars, acc1) pour acc1 = dof_aux(e1, tΓ a, bvars, acc0) et acc0 = dof_aux(e, tΓ a, bvars, acc) dof_aux(match e with p → e1 | x → e2, tΓ a, bvars, acc) := dof_aux(e2, tΓ a, x; bvars, acc1) pour acc1 = dof_aux(e1, tΓ a, binders_of(p); bvars, acc0) et acc0 = dof_aux(e, tΓ a, bvars, acc) dof_aux((e1, e2), tΓ a, bvars, acc) := dof_aux(e2, tΓ a, bvars, acc1) pour acc1 = dof_aux(e1, tΓ a, bvars, acc) dof_aux(l : e, tΓ a, bvars, acc) := dof_aux(e, tΓ a, bvars, acc) dof_aux(let x = e1 in e2, tΓ a, bvars, acc) := dof_aux(e2, tΓ a, x; bvars, acc1) pour acc1 = dof_aux(e1, tΓ a, bvars, acc) binders_of(C) := {} binders_of(D(x)) := {x} binders_of((x, y)) := {x; y} Figure 4.15 – Sémantique abstraite : v-dépendances des identificateurs libres d’une expression am-constr-0 [ tda | [ d a | C ] ], C ⊢ a p {} am-constr-1 [ tda | [ d a | D(u a ) ] ], D(x) ⊢ a p {(x, [ ∅ | u a ])} am-couple [ tda | [ d a | (u a 1 , ua 2 ) ] ], (x1, x2) ⊢ a p {(x1, [ ∅ | u a 1 ]); (x2, [ ∅ | u a 2 ])} am-constr-0-not p ̸= C [ tda | [ d a | C ] ], p ⊢ a p ⊥ am-constr-1-not p ̸= D(_) [ tda | [ d a | D(u a ) ] ], p ⊢ a p ⊥ am-couple-not p ̸= (_, _) [ tda | [ d a | (u a 1 , ua 2 ) ] ], p ⊢ a p ⊥ am-constr-0-unknown [ tda | [ d a | ⊤ ] ], C ⊢ a p? {} am-constr-1-unknown [ tda | [ d a | ⊤ ] ], D(x) ⊢ a p? {(x, [ ∅ | [ ∅ | ⊤ ] ])} am-couple-unknown [ tda | [ d a | ⊤ ] ], (x1, x2) ⊢ a p? {(x1, [ ∅ | [ ∅ | ⊤ ] ]); (x2, [ ∅ | [ ∅ | ⊤ ] ])} am-error ∀C.va ̸= C ∀D.va ̸= D(_) v a ̸= (_, _) v a ̸= ⊤ [ tda | [ d a | v a ] ], p ⊢ a p × Figure 4.16 – Sémantique abstraite : règles de filtrage 1784.4. SÉMANTIQUE ABSTRAITE ↑ a ta( [ tda | u a ]) = u a ↑ a ta({}) = {} ↑a ta((x, tua ) ⊕ tΓ a ) = (x, ↑ a ta(tua )) ⊕ ↑a ta(tΓ a ) Figure 4.17 – Valeurs abstraites : suppression des t-dépendances a-ident Cette règle est identique à celle de la sémantique instrumentée. L’évaluation d’un identificateur se fait de manière habituelle, en allant chercher la valeur correspondante dans l’environnement. Les dépendances de la t-valeur abstraite retournée sont celles qui ont été enregistrées dans l’environnement pour cet identificateur. a-ident-empty Comme dans la sémantique collectrice, une règle a été ajoutée pour permettre l’analyse d’un programme dont certains identificateurs ne sont pas liés dans l’environnement. La valeur simple abstraite retournée est la valeur ⊥, ce qui correspond à une erreur (l’évaluation d’un tel programme par la sémantique opérationnelle ne retourne aucune valeur). a-abstr L’évaluation abstraite d’une fonction n’a rien de surprenant. Comme dans la sémantique instrumentée, les dépendances sont vides. La valeur simple abstraite est une fermeture encapsulant l’environnement abstrait d’évaluation préalablement nettoyé de ses t-dépendances à l’aide de la fonction ↑ a ta(•) définie en figure 4.17. a-abstr-rec Selon le même principe que pour la règle a-abstr, on construit une fermeture récursive encapsulant l’environnement abstrait d’évaluation. a-letin La règle d’évaluation d’une liaison est identique à la règle correspondante dans la sémantique instrumentée. Elle évalue e1 puis ajoute une liaison à l’environnement pour évaluer e2. Le résultat est une t-valeur abstraite constituée de la concaténation des tdépendances des sous-expressions évaluées et de la v-valeur abstraite de e2. a-apply La règle de l’application d’une fonction non-récursive est identique à son homologue de la sémantique instrumentée. 1794.4. SÉMANTIQUE ABSTRAITE ↑ ta a (u a ) = [ ∅ | u a ] ↑ ta a ({}) = {} ↑ta a ((x, ua ) ⊕ Γ a ) = (x, ↑ ta a (u a )) ⊕ ↑ta a (Γa ) Figure 4.18 – Valeurs abstraites : ajout de t-dépendances Comme dans la sémantique instrumentée, nous utilisons une fonction ajoutant des tdépendances vides à l’environnement encapsulé pour évaluer le corps de la fermeture. Cette fonction, notée ↑ ta a (•) est définie en figure 4.18. a-apply-rec La règle d’évaluation abstraite d’une application de fonction récursive ressemble à celle de la sémantique instrumentée. Il y a cependant une différence importante. Lorsque le corps de la fonction récursive est évalué, l’identificateur représentant la fonction récursive est lié à la valeur ⊤. Cette abstraction permet d’empêcher les appels récursifs lors de l’analyse d’un programme. À chaque appel récursif, au lieu de déplier le corps de la fonction une nouvelle fois, on renvoie la valeur ⊤ accompagnée de toutes les dépendances de tous les identificateurs libres présents dans le corps de la fonction. a-apply-unknown La sémantique abstraite possède une règle d’évaluation d’une application dans le cas où on ne connaît pas le corps de la fonction à appliquer. On caractérise ce cas en spécifiant que la valeur abstraite de e1 n’est pas une fermeture. Si le programme est bien typé, alors la valeur abstraite de e1 est forcément ⊤. Cependant, il serait possible de rendre la sémantique abstraite plus précise en utilisant une réprésentation des fonctions ayant un niveau de précision intermédiaire entre la fermeture, contenant le corps de la fonction, et la valeur ⊤ ne fournissant aucune information. Lorsque l’on ne connaît pas le corps de la fonction à appliquer, on effectue l’approximation suivante : tout label présent dans les v-dépendances de l’argument fait partie à la fois des t-dépendances et des v-dépendances du résultat. Il fait partie des t-dépendances du résultat car une modification de la valeur de l’argument peut provoquer la non-terminaison du corps de la fonction (qui est inconnu). Il fait également partie des v-dépendances du résultat la valeur de l’argument peut être utilisée pour élaborer la valeur de retour de la 1804.4. SÉMANTIQUE ABSTRAITE fonction. a-if Contrairement aux autres sémantiques, la sémantique abstraite ne contient qu’une seule règle d’inférence pour décrire l’évaluation d’une expression conditionnelle. En effet, l’algèbre des valeurs abstraites ne permet pas de réprésenter les valeurs booléennes. Il est donc impossible de déterminer laquelle des deux branches sera évaluée à partir de la valeur abstraite de la condition. Nous évaluons donc les deux branches de l’expression pour recueillir les dépendances du résultat. L’ensemble des t-dépendances du résultat contient les t-dépendances des trois sous-expressions ainsi que les v-dépendances de la condition (car une modification de la valeur de la condition entraîne nécessairement un changement de branche, ce qui peut provoquer la non-terminaison de l’évaluation). L’ensemble des v-dépendances du résultat contient les v-dépendances des trois sous-expressions. a-match Cette règle décrit l’évaluation abstraite d’un filtrage lorsqu’on sait statiquement que l’évaluation passe toujours par la première branche. Elle ne présente pas de particularité par rapport à la sémantique instrumentée. a-match-var Cette règle décrit l’évaluation abstraite d’un filtrage lorsqu’on sait statiquement que l’évaluation passe toujours par la seconde branche. Elle ne présente pas de particularité par rapport à la sémantique instrumentée. a-match-unknown Cette règle décrit l’évaluation abstraite d’un filtrage lorsqu’on ne sait statiquement par quelle branche l’évaluation va passer. Elle correspond à la règle c-match-unknown de la sémantique collectrice. On évalue alors les deux branches pour récolter les dépendances du filtrage. a-match-error Cette règle décrit l’évaluation abstraite d’un filtrage dans le cas où la valeur abstraite de l’expression filtrée ne correspond pas à une valeur filtrable. Il s’agit d’une erreur de type. La valeur simple abstraite est donc ⊥, ce qui indique qu’il n’existe aucune évaluation opérationnelle correspondante. 1814.4. SÉMANTIQUE ABSTRAITE a-constr-0 a-constr-1 a-couple a-annot Ces quatres règles sont identiques à leurs homologues de la sémantique instrumentée. 4.4.3 Correction 4.4.3.1 Énoncé informel du théorème La sémantique abstraite est une interprétation abstraite de la sémantique collectrice. C’est-à-dire qu’une évaluation par la sémantique collectrice peut être simulée par une évaluation abstraite (avec l’aide de fonctions d’abstraction et de concrétisation) et que la valeur ainsi obtenue sera moins précise que celle obtenue par une évaluation directe. Les fonctions d’abstraction et de concrétisation sont définies formellement en figures 4.11, 4.12 et 4.13. Le lien entre l’évaluation directe par la sémantique collectrice et l’évaluation passant par la sémantique abstraite et les fonctions de conversion, est illustré en figure 4.2. 4.4.3.2 Illustration par l’exemple Exemple 1 : évaluation d’un couple Notons e1 le programme suivant : (x, l1:7) Nous nous intéressons ici à l’évaluation de ce programme par la sémantique collectrice dans l’environnement collecteur tΓ c 1 : tΓ c 1 = (x, [ ∅ | {l2; l3} | {C1; C2} ]) Voici le jugement d’évaluation : tΓ c 1 ⊢ c e1 →→ [ ∅ | ∅ | { ( [ {l2; l3} | C1 ], [ {l1} | 7 ]); ( [ {l2; l3} | C2 ], [ {l1} | 7 ]) } ] La sémantique abstraite étant une interprétation abstraite de la sémantique collectrice, on peut simuler toute évaluation collectrice par une évaluation abstraite. Pour cela, on commence par abstraire l’environnement d’évaluation : ↑ a c (tΓ c 1 ) = (x, [ ∅ | [ {l2; l3} | ⊤ ] ]) = tΓ a 1 On peut ensuite évaluer e1 dans l’environnement abstrait à l’aide de la sémantique abstraite. On obtient le jugement suivant : tΓ a 1 ⊢ a e1 →→ [ ∅ | [ ∅ | ( [ {l2; l3} | ⊤ ], [ {l1} | ⊤ ]) ] ] 1824.4. SÉMANTIQUE ABSTRAITE Il ne reste plus qu’à concrétiser la t-valeur abstraite obtenue pour produire une valeur collectrice qui se trouvera être moins précise que celle obtenue directement par la sémantique collectrice. ↑ c a ( [ ∅ | [ ∅ | ( [ {l2; l3} | ⊤ ], [ {l1} | ⊤ ]) ] ]) = [ ∅ | ∅ | {( [ {l2; l3} | v i 1 ], [ {l1} | v i 2 ]) | ∀v i 1 ∈ Vi , ∀v i 2 ∈ Vi} ] Les ensembles de dépendances sont vides et l’ensemble des valeurs simples obtenu directement est inclus dans l’ensemble des valeurs simples obtenu après abstraction : {( [ {l2; l3} | C1 ], [ {l1} | 7 ]); ⊆im {( [ {l2; l3} | v i 1 ], [ {l1} | v i 2 ]) | ∀v i 1 ∈ Vi , ∀v i 2 ∈ Vi} ( [ {l2; l3} | C2 ], [ {l1} | 7 ])} Voici quelques exemples d’évaluations instrumentées correspondant à l’évaluation collectrice présentée ici : (x, [ ∅ | {l2} | C1 ]) ⊢ i e1 →→ [ ∅ | [ ∅ | ( [ {l2} | C1 ], [ {l1} | 7 ]) ] ] (x, [ ∅ | {l3} | C2 ]) ⊢ i e1 →→ [ ∅ | [ ∅ | ( [ {l3} | C2 ], [ {l1} | 7 ]) ] ] 4.4.3.3 Énoncé formel du théorème Ce théorème de correction exprime le fait que la sémantique abstraite est une interprétation abstraite de la sémantique collectrice. Autrement dit, pour tout jugement d’évaluation collectrice, il est possible de simuler cette évaluation en commençant par abstraire l’environnement d’évaluation, puis en évaluant l’expression par la sémantique abstraite pour enfin concrétiser la valeur abstraite. La valeur collectrice ainsi obtenue est alors moins précise que celle obtenue directement par la sémantique collectrice. Pour exprimer formellement ce théorème, il nous faut d’abord définir formellement la relation d’ordre sur les valeurs collectrices qui exprime le fait qu’une valeur collectrice est plus précise qu’une autre. Cette définition est donnée en figure 4.19. Théorème 4.4.1 (Correction de la sémantique abstraite). ∀(tΓ c , e, tuc , tΓ a , tua ). tΓ c ⊢ c e →→ tuc ⇒ tΓ a =↑ a c (tΓ c ) ⇒ tΓ a ⊢ a e →→ tua ⇒ tuc ⊆c ↑ c a (tua ) 1834.4. SÉMANTIQUE ABSTRAITE le-c-val tdc 1 ⊆ tdc 2 d c 1 ⊆ d c 2 vsi 1 ⊆ si vsi 2 [ tdc 1 | d c 1 | vsi 1 ] ⊆ c [ tdc 2 | d c 2 | vsi 2 ] le-si-val ∀v i 1 ∈ vsi 1 . ∃v i 2 ∈ vsi 2 . vi 1 ⊆ i v i 2 vsi 1 ⊆ si vsi 2 Figure 4.19 – Relation d’ordre sur les valeurs collectrices 4.4.3.4 Preuve de correction La preuve de correction de ce théorème est similaire à la preuve de correction de la sé- mantique collectrice. Il s’agit de prouver qu’une sémantique est une interprétation abstraite d’une autre, étant données une fonction d’abstraction et une fonction de concrétisation. On procède par induction sur le jugement d’évaluation de la sémantique abstraite. Il y a 18 cas à prouver, correspondant aux 18 règles d’inférences de la sémantique abstraite. Nous présentons ici la preuve de quelques uns de ces cas. cas a-num Ce cas est trivial, tout comme le cas a-constr-0. Nous allons tout de même l’expliquer rapidement pour illustrer le principe de la preuve qui est également utilisé dans les autres cas. Nous avons les hypothèses suivantes : tΓ c ⊢ c n →→ [ ∅ | ∅ | {n} ] tΓ a = ↑ a c (tΓ c ) tΓ a ⊢ a n →→ [ ∅ | [ ∅ | ⊤ ] ] Il reste uniquement à prouver la propriété ci-dessous qui est une conséquence directe de la définition de la relation d’ordre ⊆c donnée en figure 4.19 : [ ∅ | ∅ | {n} ] ⊆ c ↑ c a ( [ ∅ | [ ∅ | ⊤ ] ]) cas a-constr-1 Ce cas est légèrement plus complexe que le précédent du fait que l’expression évaluée possède une sous-expression. Nous avons les hypothèses suivantes dont une hypothèse d’induction : c-constr-1 tΓ c ⊢ c e →→ [ tdc | d c | vsi ] tΓ c ⊢ c D(e) →→ [ tdc | ∅ | {D( [ d c | v i ]) | v i ∈ vsi } ] 1844.4. SÉMANTIQUE ABSTRAITE tΓ a = ↑ a c (tΓ c ) a-constr-1 tΓ a ⊢ a e →→ [ tda | [ d a | v a ] ] tΓ a ⊢ a D(e) →→ [ tda | [ ∅ | D( [ d a | v a ]) ] ] [ tdc | d c | vsi ] ⊆ c ↑ c a ( [ tda | [ d a | v a ] ]) Nous devons alors montrer cette propriété : [ tdc | ∅ | {D( [ d c | v i ]) | v i ∈ vsi } ] ⊆ c ↑ c a ( [ tda | [ ∅ | D( [ d a | v a ]) ] ]) Une fois simplifiée à l’aide des définitions de la relation d’ordre et de la fonction de concrétisation, il nous reste à prouver les propriétés suivantes : tdc ⊆ tda {D( [ d c | v i ]) | v i ∈ vsi} ⊆c↑ c a (D( [ d a | v a ])) Nous simplifions alors la seconde propriété en plusieurs étapes : ∀v i 1 ∈ {D( [ d c | v i ]) | v i ∈ vsi}. ∃v i 2 ∈↑c a (D( [ d a | v a ])). vi 1 ⊆i v i 2 ∀v i 1 ∈ vsi . ∃v i 2 ∈↑c a (D( [ d a | v a ])). D( [ d c | v i 1 ]) ⊆i v i 2 ∀v i 1 ∈ vsi . ∃v i 2 ∈ {D( [ d a | v i ]) | ∀v i ∈↑c a (v a )}. D( [ d c | v i 1 ]) ⊆i v i 2 ∀v i 1 ∈ vsi . ∃v i 2 ∈↑c a (v a ). D( [ d c | v i 1 ]) ⊆i D( [ d a | v i 2 ]) ∀v i 1 ∈ vsi . ∃v i 2 ∈↑c a (v a ). dc ⊆ d a ∧ v i 1 ⊆i v i 2 d c ⊆ d a ∀v i 1 ∈ vsi . ∃v i 2 ∈↑c a (v a ). vi 1 ⊆i v i 2 De notre hypothèse d’induction, nous déduisons les propriétés suivantes, en utilisant simplement les définitions de la relation d’ordre et de la fonction de concrétisation : tdc ⊆ tda d c ⊆ d a vsi ⊆c ↑ c a (v a ) ∀v i 1 ∈ vsi . ∃v i 2 ∈↑c a (v a ). vi 1 ⊆i v i 2 Ce qui nous permet de conclure immédiatement. cas a-apply Comme d’habitude, le cas de l’application fait partie des cas les plus complexes à prouver. 1854.4. SÉMANTIQUE ABSTRAITE Nous avons les hypothèses suivantes dont trois hypothèses d’induction : c-apply tΓ c ⊢ c e1 →→ [ tdc 1 | d c 1 | vsi 1 ] tΓ c ⊢ c e2 →→ [ tdc 2 | d c 2 | vsi 2 ] v im = multiple_instrumented_application(tdc 1 , dc 1 , vsi 1 , tdc 2 , dc 2 , vsi 2 ) (∀l. l ∈ tdc ⇔ (∃(tdi , di , vi ). l ∈ tdi ∧ [ tdi | [ d i | v i ] ] ∈ v im)) (∀l. l ∈ d c ⇔ (∃(tdi , di , vi ). l ∈ d i ∧ [ tdi | [ d i | v i ] ] ∈ v im)) vsi = {v i | ∃(tdi , di ). [ tdi | [ d i | v i ] ] ∈ v im} tΓ c ⊢ c e1 e2 →→ [ tdc | d c | vsi ] tΓ a = ↑ a c (tΓ c ) a-apply tΓ a ⊢ a e1 →→ [ tda 1 | [ d a 1 | < λx.e, Γ a 1 > ] ] tΓ a ⊢ a e2 →→ tua 2 tua 2 = [ tda 2 | [ d a 2 | v a 2 ] ] (x, tua 2 )⊕ ↑ta a (Γa 1 ) ⊢ a e →→ [ tda | [ d a | v a ] ] tΓ a ⊢ a e1 e2 →→ [ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 | [ d a 1 ∪ d a | v a ] ] [ tdc 1 | d c 1 | vsi 1 ] ⊆ c ↑ c a ( [ tda 1 | [ d a 1 | < λx.e, Γ a 1 > ] ]) [ tdc 2 | d c 2 | vsi 2 ] ⊆ c ↑ c a ( [ tda 2 | [ d a 2 | v a 2 ] ]) ∀(tΓ c , tuc ). tΓ c ⊢ c e →→ tuc ⇒ (x, tua 2 )⊕ ↑ta a (Γa 1 ) =↑ a c (tΓ c ) ⇒ tuc ⊆ c ↑ c a ( [ tda | [ d a | v a ] ]) Nous devons alors montrer cette propriété : [ tdc | d c | vsi ] ⊆ c ↑ c a ( [ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 | [ d a 1 ∪ d a | v a ] ]) Après simplification, nous devons donc montrer les trois propriétés suivantes : tdc ⊆ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 d c ⊆ d a 1 ∪ d a ∀v i 1 ∈ vsi . ∃v i 2 ∈↑c a (v a ). vi 1 ⊆i v i 2 Prouvons tout d’abord quelques propriétés préliminaires concernant l’évaluation collectrice de e ainsi que son évaluation instrumentée multiple. Puisque la sémantique collectrice est totale, nous savons qu’il existe un jugement d’évaluation collectrice pour e dans l’environnement ↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 )). Il existe donc une valeur collectrice [ td′c | d ′c | vs′i ] telle que : ↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 )) ⊢ c e →→ [ td′c | d ′c | vs′i ] La composition de la fonction de concrétisation et de la fonction d’abstraction est l’identité. Nous en déduisons donc la propriété suivante : ↑ a c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))) = (x, tua 2 )⊕ ↑ta a (Γa 1 ) 1864.4. SÉMANTIQUE ABSTRAITE On utilise alors la troisième hypothèse d’induction pour établir la relation d’ordre entre les valeurs collectrice et abstraite de e. Nous obtenons : [ td′c | d ′c | vs′i ] ⊆ c ↑ c a ( [ tda | [ d a | v a ] ]) La sémantique instrumentée multiple est elle aussi totale. Il existe donc un jugement de la sémantique instrumentée multiple pour l’évaluation de e dans l’ensemble d’environnements instrumentés suivant : ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))). Voici le jugement : i-multiple v im = {tui | ∃tΓ i ∈ ↑im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))). tΓ i ⊢ i e →→ tui } ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))) ⊢ im e →→ v im Commençons maintenant par prouver la première des trois propriétés : tdc ⊆ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 Soit l ∈ tdc on veut alors montrer que l ∈ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 D’après la définition de tdc , on a (tdi , di , vi ) tels que : l ∈ tdi∧ [ tdi | [ d i | v i ] ] ∈ v im Il y a alors 2 cas possibles d’après la définition de multiple_instrumented_application. Il s’agit soit de l’application d’une fonction non-récursive, soit de l’application d’une fonction récursive. Nous prouvons plus loin que le second cas est impossible. Commençons par nous placer dans le premier cas, on a alors : < λx.e, Γ i 1 > ∈ vsi 1 v i 2 ∈ vsi 2 tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ] (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] [ tdi | [ d i | v i ] ] = [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] On remarque que {(x, tui 2 )⊕ ↑ti i (Γi 1 )} ⊆im ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))) Puisque la sémantique instrumentée multiple est croissante, la valeur de e dans l’environnement {(x, tui 2 )⊕ ↑ti i (Γi 1 )} est plus précise que la valeur de e dans l’environnement ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))). Ce qui nous donne : { [ td′i | [ d ′i | v ′i ] ]} ⊆im v im D’après le théorème de correction de la sémantique collectrice, on a : v im ⊆ im ↑ im c ( [ td′c | d ′c | vs′i ]) 1874.4. SÉMANTIQUE ABSTRAITE On utilise alors la transitivité de la relation d’ordre sur les valeurs instrumentées multiples pour déduire : { [ td′i | [ d ′i | v ′i ] ]} ⊆im ↑ im c ( [ td′c | d ′c | vs′i ]) En composant cette relation ainsi que la relation d’ordre entre la valeur collectrice de e et sa valeur abstraite ( [ td′c | d ′c | vs′i ] ⊆c ↑ c a ( [ tda | [ d a | v a ] ])), on obtient : td′i ⊆ td′c ⊆ tda D’autre part, nos hypothèses d’induction nous disent que : tdc 1 ⊆ tda 1 tdc 2 ⊆ tda 2 d c 1 ⊆ d a 1 Puisque l ∈ tdc 1 ∪tdc 2 ∪td′i ∪d c 1 , on déduit donc la propriété voulue pour conclure le cas de l’application d’un fonction non-récursive : l ∈ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 Montrons maintenant que le cas de l’application d’une fonction récursive est absurde. Dans ce cas, on a les propriétés suivantes : < recf.x.e, Γ i 1 > ∈ vsi 1 v i 2 ∈ vsi 2 tui f = [ tdc 1 | [ d c 1 | < recf.x.e, Γ i 1 > ] ] tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ] (f, tui f ) ⊕ (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] [ tdi | [ d i | v i ] ] = [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] Or la première propriété < recf.x.e, Γ i 1 > ∈ vsi 1 contredit notre première hypothèse d’induction qui implique que vsi 1 ⊆im ↑ c a (< λx.e, Γ a 1 >) Ceci nous permet de conclure la preuve de tdc ⊆ tda 1 ∪ tda 2 ∪ tda ∪ d a 1 On procède de même pour montrer que d c ⊆ d a 1 ∪ d a Soit l ∈ d c on veut alors montrer que l ∈ d a 1 ∪ d a D’après la définition de d c , on a (tdi , di , vi ) tels que : l ∈ d i ∧ [ tdi | [ d i | v i ] ] ∈ v im Il y a alors 2 cas possibles d’après la définition de multiple_instrumented_application. Il s’agit soit de l’application d’une fonction non-récursive, soit de l’application d’une fonction récursive. Pour la même raison que dans le cas précédent, le cas de l’application d’une fonction récursive est absurde. Plaçons nous donc dans le premier cas, on a alors : 1884.4. SÉMANTIQUE ABSTRAITE < λx.e, Γ i 1 > ∈ vsi 1 v i 2 ∈ vsi 2 tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ] (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] [ tdi | [ d i | v i ] ] = [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] On remarque que {(x, tui 2 )⊕ ↑ti i (Γi 1 )} ⊆im ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))) Puisque la sémantique instrumentée multiple est croissante, la valeur de e dans l’environnement {(x, tui 2 )⊕ ↑ti i (Γi 1 )} est plus précise que la valeur de e dans l’environnement ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))). Ce qui nous donne : { [ td′i | [ d ′i | v ′i ] ]} ⊆im v im D’après le théorème de correction de la sémantique collectrice, on a : v im ⊆ im ↑ im c ( [ td′c | d ′c | vs′i ]) On utilise alors la transitivité de la relation d’ordre sur les valeurs instrumentées multiples pour déduire : { [ td′i | [ d ′i | v ′i ] ]} ⊆im ↑ im c ( [ td′c | d ′c | vs′i ]) En composant cette relation ainsi que la relation d’ordre entre la valeur collectrice de e et sa valeur abstraite, on obtient d ′i ⊆ d ′c ⊆ d a D’autre part, nos hypothèses d’induction nous disent que : d c 1 ⊆ d a 1 Puisque l ∈ d c 1 ∪ d ′i , on déduit donc la propriété voulue pour conclure : l ∈ d a 1 ∪ d a Ceci nous permet de conclure la preuve de d c ⊆ d a 1 ∪ d a Il nous reste alors à montrer cette troisième et dernière propriété : ∀v i 1 ∈ vsi . ∃v i 2 ∈ ↑c a (v a ). vi 1 ⊆ i v i 2 Pour cela, on prend v i 1 ∈ vsi et on procède une troisième fois de la même manière, en faisant le lien entre l’évaluation instrumentée correspondant à v i 1 et l’évaluation abstraite de e. 1894.4. SÉMANTIQUE ABSTRAITE D’après la définition de vsi , on a (tdi , di ) tels que : [ tdi | [ d i | v i 1 ] ] ∈ v im Il y a là aussi 2 cas possibles d’après la définition de multiple_instrumented_application. Il s’agit soit de l’application d’une fonction non-récursive, soit de l’application d’une fonction récursive. Pour la même raison que précédemment, le cas de l’application d’une fonction récursive est absurde. Plaçons nous donc dans le premier cas, on a alors : < λx.e, Γ i 1 > ∈ vsi 1 v i 2 ∈ vsi 2 tui 2 = [ tdc 2 | [ d c 2 | v i 2 ] ] (x, tui 2 )⊕ ↑ti i (Γi 1 ) ⊢ i e →→ [ td′i | [ d ′i | v ′i ] ] [ tdi | [ d i | v i 1 ] ] = [ tdc 1 ∪ tdc 2 ∪ td′i ∪ d c 1 | [ d c 1 ∪ d ′i | v ′i ] ] On remarque que {(x, tui 2 )⊕ ↑ti i (Γi 1 )} ⊆im ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))) Puisque la sémantique instrumentée multiple est croissante, la valeur de e dans l’environnement {(x, tui 2 )⊕ ↑ti i (Γi 1 )} est plus précise que la valeur de e dans l’environnement ↑ im c (↑ c a ((x, tua 2 )⊕ ↑ta a (Γa 1 ))). Ce qui nous donne : { [ td′i | [ d ′i | v i 1 ] ]} ⊆im v im D’après le théorème de correction de la sémantique collectrice, on a : v im ⊆ im ↑ im c ( [ td′c | d ′c | vs′i ]) On utilise alors la transitivité de la relation d’ordre sur les valeurs instrumentées multiples pour déduire : { [ td′i | [ d ′i | v i 1 ] ]} ⊆im ↑ im c ( [ td′c | d ′c | vs′i ]) De cette dernière relation, nous déduisons qu’il existe une valeur v ′i 2 ∈ vs′i telle que : v i 1 ⊆ i v ′i 2 Nous utilisons alors la relation d’ordre entre la valeur collectrice de e et sa valeur abstraite pour déduire qu’il existe une valeur v i 2 ∈ ↑c a (v a ) telle que : v ′i 2 ⊆ i v i 2 1904.4. SÉMANTIQUE ABSTRAITE La transitivité de la relation d’ordre nous permet alors de conclure : v i 1 ⊆ i v i 2 La preuve du cas a-apply de notre induction est alors terminée. 1914.5. CORRECTION DE L’ANALYSE STATIQUE 4.5 Correction de l’analyse statique Nous établissons enfin la correction de notre analyse statique. L’analyse statique ainsi que l’ensemble des sémantiques intermédiaires ont été introduites dans le but de simplifier la preuve du théorème présenté ici et de la rendre modulaire. Cette modularité permettra de réutiliser une grande partie des preuves présentées ici lors d’une modification de l’analyse statique. Par exemple, si on modifie l’algèbre des valeurs abstraites afin de proposer une représentation différente des fonctions ou bien si on modifie les règles d’inférence pour améliorer la précision ou l’efficacité de l’analyse, il suffira de reprendre la preuve de la sémantique abstraite par rapport à la sémantique collectrice sans avoir à refaire les preuves des sémantiques précédentes. 4.5.1 Énoncé informel du théorème De même que pour la correction de l’analyse dynamique, notre but est de pouvoir affirmer que si un label n’apparaît pas dans le résultat de l’analyse d’un programme alors ce label n’a pas d’impact sur l’évaluation de ce programme. La différence essentielle entre l’analyse dynamique et l’analyse statique est que cette dernière considère de façon simultanée un ensemble éventuellement infini d’évaluations possibles. En effet, l’environnement abstrait utilisé lors de l’analyse statique correspond à un ensemble éventuellement infini d’environnements possibles alors que l’environnement instrumenté utilisé lors de l’analyse dynamique correspond à un environnement de référence unique. Plus précisément, après avoir obtenu un jugement d’évaluation abstraite du programme à analyser et après avoir vérifié que le label en question n’apparaît pas dans les dépendances calculées alors on peut affirmer que peu importe l’injection considérée sur ce label, l’évaluation avec injection de ce programme dans n’importe quel environnement possible retournera toujours la valeur de référence du programme (la valeur du programme lors d’une évaluation sans injection). 1924.5. CORRECTION DE L’ANALYSE STATIQUE 4.5.2 Illustration par l’exemple Exemple 1 : évaluation d’un couple Notons e1 le programme suivant : (3, l :7) Son jugement d’évaluation abstraite dans le t-environnent abstrait vide est : ∅ ⊢a e1 →→ [ ∅ | [ ∅ | ( [ ∅ | ⊤ ], [ l | ⊤ ]) ] ] Seul le label l apparaît dans la t-valeur abstraite de e1. On peut donc affirmer que tout autre label n’a pas d’impact sur l’évaluation de e1. On a en effet pour toute injection (l ′ , vl ′) sur un label l ′ différent de l : ∅ ⊢l ′ :vl ′ e1 →→ (3, 7) Exemple 2 : liaison d’une fonction Notons e2 le programme suivant : l e t f o = match o with | Some ( x ) → x + l1 : 8 | none → d + l2 : 8 i n ( f ( Some 18 ) , l3 : 17 ) Définissons le t-environnement abstrait dans lequel nous souhaitons effectuer l’analyse statique du programme e2 : tΓ a 2 = (d, [ tda d | [ d a d | ⊤ ] ]) Le jugement d’évaluation abstraite de e2 dans cet environnement est : tΓ a 2 ⊢ a e2 →→ [ ∅ | [ ∅ | ( [ l1 | ⊤ ], [ l3 | ⊤ ]) ] ] Le label l2 n’étant pas présent dans la t-valeur abstraite du programme e2, nous pouvons en conclure qu’aucune injection sur l2 n’a d’impact sur l’évaluation de e2 et ceci, quelque 1934.5. CORRECTION DE L’ANALYSE STATIQUE soit la valeur de d dans l’environnement : ∀(vl2 , vd).(d, vd) ⊢l2:vl2 e2 →→ (26, 17) Les dépendances de l’identificateur d présent dans l’environnement ne sont pas présentes non plus, ce qui indique que la valeur de cette identificateur n’a aucune influence sur le résultat du programme. Par contre, les labels l1 et l3 apparaissent dans la t-valeur instrumentée du programme e2. Il n’est donc pas impossible qu’une injection sur un de ces labels puisse modifier le comportement du programme, comme le montrent les exemples ci-dessous : (d, 26) ⊢l1:24 e2 →→ (42, 17) (d, 32) ⊢l3:613 e2 →→ (26, 613) 4.5.3 Énoncé formel du théorème Pour énoncer formellement le théorème de correction, il nous faut tout d’abord définir formellement les notions de non-apparition d’un label dans une valeur abstraite et dans un t-environnement abstrait. On définit pour cela les prédicats ldna_in_evala , ldna_in_vala et ldna_in_enva . Leur définition est donnée respectivement en figure 4.20, en figure 4.21 et en figure 4.22. Théorème 4.5.1 (Correction de l’analyse statique). ∀(tΓ a , e, tua , l). tΓ a ⊢ a e →→ tua ⇒ ldna_in_enva (l, tΓ a ) ⇒ ldna_in_vala (l, tua ) ⇒ ∀tΓ i ∈ ↑im c (↑ c a (tΓ a )).∀vl .tΓ i ⊢ i e →→ tui ⇒↑ti(tΓ i ) ⊢l:vl e →→↑ti(tui ) 4.5.4 Preuve de correction Nous avons les hypothèses suivantes : tΓ a ⊢ a e →→ tua ldna_in_enva (l, tΓ a ) ldna_in_vala (l, tua ) tΓ i ∈ ↑im c (↑ c a (tΓ a )) tΓ i ⊢ i e →→ tui 1944.5. CORRECTION DE L’ANALYSE STATIQUE ldna-e-a-num ldna_in_evala (l, tΓ a , n) ldna-e-a-constr-0 ldna_in_evala (l, tΓ a , C) ldna-e-a-constr-1 ldna_in_evala (l, tΓ a , e) ldna_in_evala (l, tΓ a , D(e)) ldna-e-a-ident ldna_in_vala (l, tΓ a [x]) ldna_in_evala (l, tΓ a , x) ldna-e-a-ident-unbound x ̸∈ support(tΓ a ) ldna_in_evala (l, tΓ a , x) ldna-e-a-abstr ldna_in_evala (l, tΓ a , e) ldna_in_evala (l, tΓ a , λx.e) ldna-e-a-abstr-rec ldna_in_evala (l, tΓ a , e) ldna_in_evala (l, tΓ a , recf.x.e) ldna-e-a-apply ldna_in_evala (l, tΓ a , e1) ldna_in_evala (l, tΓ a , e2) ldna_in_evala (l, tΓ a , e1 e2) ldna-e-a-if ldna_in_evala (l, tΓ a , e) ldna_in_evala (l, tΓ a , e1) ldna_in_evala (l, tΓ a , e2) ldna_in_evala (l, tΓ a , if e then e1 else e2) ldna-e-a-match ldna_in_evala (l, tΓ a , e) ldna_in_evala (l, tΓ a , e1) ldna_in_evala (l, tΓ a , e2) ldna_in_evala (l, tΓ a , match e with p → e1 | x → e2) ldna-e-a-annot l ̸= l ′ ldna_in_evala (l, tΓ a , e) ldna_in_evala (l, tΓ a , l : e) ldna-e-a-couple ldna_in_evala (l, tΓ a , e1) ldna_in_evala (l, tΓ a , e2) ldna_in_evala (l, tΓ a ,(e1, e2)) ldna-e-a-letin ldna_in_evala (l, tΓ a , e1) ldna_in_evala (l, tΓ a , e2) ldna_in_evala (l, tΓ a , let x = e1 in e2) Figure 4.20 – Prédicat de non-apparition d’un label lors d’une évaluation abstraite ldna-v-a-top ldna_in_vala (l, ⊤) ldna-v-a-bottom ldna_in_vala (l, ⊥) ldna-v-a-constr-0 ldna_in_vala (l, C) ldna-v-a-constr-1 ldna_in_vala (l, u) ldna_in_vala (l, D(u)) ldna-v-a-couple ldna_in_vala (l, u1) ldna_in_vala (l, u2) ldna_in_vala (l,(u1, u2)) ldna-v-a-closure ldna_in_evala (l, ↑ ta a (Γa ), e) ldna_in_vala (l, < λx.e, Γ a >) ldna-v-a-closure-rec ldna_in_evala (l, ↑ ta a (Γa ), e) ldna_in_vala (l, < recf.x.e, Γ a >) ldna-v-a-v-val l ̸∈ d a ldna_in_vala (l, va ) ldna_in_vala (l, [ d a | v a ]) ldna-v-a-t-val l ̸∈ tda ldna_in_vala (l, ua ) ldna_in_vala (l, [ tda | u a ]) Figure 4.21 – Prédicat de non-apparition d’un label dans une valeur abstraite ldna-env-a-empty ldna_in_enva (l, ∅) ldna-env-a-cons ldna_in_vala (l, tua ) ldna_in_vala (l, tΓ a ) ldna_in_vala (l,(tua ) ⊕ tΓ a ) Figure 4.22 – Prédicat de non-apparition d’un label dans un environnement abstrait 1954.5. CORRECTION DE L’ANALYSE STATIQUE Nous voulons montrer : ↑ti(tΓ i ) ⊢l:vl e →→↑ti(tui ) Tout d’abord, nous utilisons le fait que les sémantiques collectrice et instrumentée multiple sont totales pour déduire les jugements d’évaluation suivants : ↑ c a (tΓ a ) ⊢ c e →→ tuc i-multiple v im = {tui | ∃tΓ i ∈↑im c (↑ c a (tΓ a )). tΓ i ⊢ i e →→ tui } ↑ im c (↑ c a (tΓ a )) ⊢ im e →→ v im Nous appliquons alors le théorème de correction de la sémantique abstraite (cf. section 4.4.3.3) en utilisant le fait que ↑ a c (↑ c a (tΓ a )) = tΓ a , ce qui nous donne : tuc ⊆ c ↑ c a (tua ) Nous pouvons alors appliquer le théorème de correction de la sémantique collectrice (cf. section 4.3.3.3) en utilisant le fait que ↑ c im(↑ im c (↑ c a (tΓ a ))) =↑ c a (tΓ a ), ce qui nous donne : v im ⊆ im ↑ im c (tuc ) On remarque que puisque ldna_in_enva (l, tΓ a ) et tΓ i ∈ ↑im c (↑ c a (tΓ a )) alors on a ldna_in_envti(l, tΓ i ) D’autre part, on remarque que tui ∈ v im. En utilisant la relation d’ordre issue de la correction de la sémantique collectrice on déduit qu’il existe un tui 2 ∈↑im c (tuc ) tel que tui ⊆i tui 2 . Puis en utilisant la relation d’ordre issue de la correction de la sémantique abstraite on déduit qu’il existe un tui 3 ∈↑im c (↑ c a (tua )) tel que tui 2 ⊆i tui 3 . Enfin, puisque ldna_in_vala (l, tua ) alors ldna_in_valti(l, tui 3 ) et ldna_in_valti(l, tui ). Nous appliquons enfin le théorème de correction de l’analyse dynamique pour conclure : ↑ti(tΓ i ) ⊢l:vl e →→↑ti(tui ) 196Chapitre 5 Implémentation et preuve Nous présentons dans ce dernier chapitre les développements effectués autour de l’analyse de dépendances. D’une part, nous discutons des différents prototypes réalisés. D’autre part, nous exposons le développement au sein de l’assistant à la preuve Coq, qui a permis de formaliser les différentes sémantiques présentées dans cette thèse ainsi que de construire et vérifier leur preuve de correction. 5.1 Prototypes implémentés en OCaml Trois prototypes ont été développés sous la forme d’une implémantation directe en OCaml. Le premier prototype correspond à l’analyse présentée dans [ABDP12]. Il a permis de cerner les besoins de l’analyse et les améliorations possibles. Un exemple de programme sur lequel nous avons testé ce premier prototype est disponible dans [ABDP12]. Les deux autres prototypes correspondent respectivement à notre analyse dynamique et à notre analyse statique. Cependant, ces derniers ont été développés dans une phase préliminaire, avant de réaliser le développement Coq. Il en résulte qu’ils ne sont pas à jour par rapport aux analyses présentées dans la thèse. En effet, le travail de preuve réalisé en Coq a permis d’identifier différents problèmes qui nous ont conduit à modifier la définition de nos analyses. En particulier, c’est lors de la preuve Coq de la sémantique instrumentée que nous avons identifié la nécessité de faire la distinction entre les t-dépendances et les v-dépendances. Afin d’obtenir une implémentation à jour par rapport au développement Coq, nous 1975.2. DÉVELOPPEMENT COQ envisageons une extraction vers OCaml des définitions inductives des sémantiques correspondantes (cf. 5.3). Il convient de noter que les triplets ont été encodés sous forme de couples imbriqués et le filtrage sur les triplets à été traduit en une imbrication de filtrages de tête à deux branches et d’expressions conditionnelles. Afin de tester des exemples plus complexes, il serait bon d’ajouter aux prototypes un préprocesseur permettant de traduire automatiquement un langage de programmation réaliste vers notre langage noyau. On aurait besoin en particulier d’une traduction d’un filtrage par motifs quelconque vers notre filtrage de tête à deux branches. Ce type de traduction est bien connu, il suffirait de l’intégrer à notre prototype afin de pouvoir accepter des programmes écrits de façon plus naturelle. 5.2 Développement Coq 5.2.1 Contenu du développement Les sémantiques présentées dans cette thèse permettant de définir et de prouver la correction de nos analyses dynamique et statique ont été formalisées en Coq. Cette formalisation prend la forme d’un ensemble de définitions inductives pour la sémantique opé- rationnelle, la sémantique avec injection, la sémantique sur-instrumentée, la sémantique instrumentée, la sémantique instrumentée multiple, la sémantique collectrice ainsi que la sémantique abstraite. Le développement Coq est constitué de la définition de ces 7 sémantiques ainsi que des algèbres de valeurs correspondantes, de 6 théorèmes concernant la correction des sémantiques et 233 lemmes intermédiaires utilisés pour la preuve des théorèmes. Le code Coq donnant la définition des sémantiques est donné en annexe A. Le code Coq des énoncés des différents théorèmes de correction des sémantiques est donné en annexe B. Le code Coq complet, disponible en ligne [BVi14] contient 16 621 lignes de code réparties de la manière suivante : 1985.2. DÉVELOPPEMENT COQ Définition des algèbres de valeurs : 3% Définition des sémantiques : 7% Conversions entres les algèbres de valeurs : 3% Corps des preuves : 30% Lemmes intermédiaires : 57% La preuve de correction de la sémantique abstraite par rapport à la sémantique collectrice n’a pas été terminée par manque de temps. Cependant, la preuve a été suffisamment avancée sur papier pour garantir un certain niveau de confiance. Pour compléter le travail de preuve formelle présenté ici, il faudra envisager de terminer cette dernière étape de la preuve. 5.2.2 Intérêt du choix de Coq Le fait d’avoir choisi Coq pour formaliser et prouver nos différentes sémantiques plutôt que d’opter pour une version papier uniquement offre bien entendu une confiance accrue en la correction de notre analyse. Cependant, ce n’est pas le seul bénéfice. En effet, en tant qu’assistant à la preuve, Coq nous a imposé une certaine rigueur qui nous a permis d’identifier des problèmes dans la définition des sémantiques ainsi que dans l’approche de la preuve. En particulier, la distinction entre les t-dépendances et les v-dépendances s’est imposée au cours de la preuve Coq de la sémantique instrumentée. Lorsque nous avons entamé cette preuve, il n’y avait qu’une seule notion de dépendance et la sémantique avec injection n’était définie que dans un environnement opérationnel. Nous avons essayé de prouver la propriété suivante : « si un label n’apparaît pas dans la valeur instrumentée d’une expresssion alors deux évaluations quelconques avec injetions sur ce label fournissent forcément la même valeur ». Une preuve par induction a été entamée et lorsque nous sommes arrivés au cas de l’évaluation d’une expression de liaison, il n’a pas été possible d’en faire la preuve. Nous avons rapidement compris la nécessité de définir une algèbre de valeurs contenant l’information nécessaire pour connaître la valeur de l’expression considérée pour toute injection possible. C’est ainsi que l’algèbre des valeurs sur-instrumentées est née, dans le but de définir la sémantique avec injection dans des environnements sur-instrumentés. Il nous a ensuite fallu faire le lien entre cette nouvelle sémantique avec injection et la sémantique 1995.3. EXTRACTION DE COQ VERS OCAML instrumentée, ce qui a donné naissance à la sémantique sur-instrumentée. Et c’est enfin lors de la définition formelle en Coq de la sémantique sur-instrumentée que nous avons identifié la nécessité de séparer les t-dépendances des v-dépendances. Coq nous a ainsi permis d’identifier rapidement un trou dans notre définition formelle de la notion d’injection, ce qui nous a entraîné dans un processus qui aurait été probablement beaucoup plus long sans l’aide de l’assistant à la preuve formelle. 5.3 Extraction de Coq vers OCaml Une piste intéressante pour l’implémentation de notre analyse de dépendances est l’extraction à partir de Coq vers OCaml. Les différentes sémantiques que nous avons présentées ont toutes été formalisées en Coq. Leurs jugements d’évaluation sont représentés sous forme de prédicats définis inductivement. Ce style de définition ne fournit pas de fonction d’évaluation. Cependant, les travaux de P.N. Tollitte et al. [TDD12] ont rendu possible l’extraction de code à partir de prédicats définis inductivement. Leur outil [CRE13] permettrait ainsi d’extraire vers OCaml, à partir de nos définitions Coq, une implémentation de nos analyses dynamique et statique. Ces implémentations auraient l’avantage de correspondre parfaitement à leurs définitions formelle et de pouvoir être mis à jour facilement en cas de nouvelle version de l’analyse. Il serait éventuellement possible d’obtenir une garantie formelle de la correction de l’implémentation en utilisant leur outil [CRE13] d’extraction d’une relation inductive Coq vers une fonction Coq, puis en utilisant l’extraction [CEC] des fonctions Coq vers OCaml. Outre les différentes sémantiques intermédiaires non-calculables que nous avons définies pour les besoins de la preuve et qu’il n’est pas question d’implémenter, nous pouvons nous intéresser à l’extraction de la sémantique instrumentée et de la sémantique abstraite. Ces deux sémantiques calculables constituent respectivement la définition de notre analyse dynamique et de notre analyse statique. 200Conclusion 201CONCLUSION Bilan Nous avons présenté dans cette thèse une analyse statique de programmes ML permettant de cerner l’impact d’une injection (dysfonctionnement ou modification de code) sur le comportement d’un programme et sur sa valeur. Cette analyse de dépendances a été spécialement étudiée pour répondre aux besoins exprimés par des évaluateurs de logiciels critiques. De plus, afin d’offrir un niveau de confiance élevé, nous avons effectué une preuve de correction de notre analyse à l’aide de l’assistant à la preuve Coq. Afin de parvenir à ce résultat, nous avons commencé par fournir une définition formelle de la notion d’impact. Cette définition, basée directement sur la sémantique opérationnelle du langage, nous a permis de donner un sens précis à la notion de dépendance. Nous nous sommes alors appliqués à prouver la correction de notre analyse vis-à-vis de cette définition formelle. La preuve formelle s’est déroulée en deux temps. Il a tout d’abord fallu enrichir la sémantique opérationnelle pour qu’elle puisse transporter les informations de dépendance nécessaires à l’analyse, ce qui a donné lieu à la notion de sémantique sur-instrumentée. Ensuite, nous avons procédé par abstractions successives, jusqu’à obtenir une analyse statique permettant d’analyser des programmes dans un environnement partiellement inconnu. La première de ces abstractions a abouti à la définition de la sémantique instrumentée qui constitue une analyse dynamique calculable des dépendances d’un programme. Nous avons ensuite étendu la sémantique instrumentée afin de pouvoir effectuer un ensemble d’évaluations simultanément, étant donné un ensemble d’environnements d’évaluation. C’est ce que nous avons appelé la sémantique instrumentée multiple. À partir de cette dernière, nous avons encore effectué deux abstractions successives afin d’obtenir la sémantique collectrice puis enfin la sémantique abstraite. C’est cette dernière qui constitue l’analyse statique désirée. Toutes ces sémantiques ont été formalisées en Coq. Le code source, contenant également les preuves de correction, est disponible à l’adresse suivante : https://github.com/vincent-benayoun/PhD-thesis. 203CONCLUSION Perspectives Vers un outil utilisable dans l’industrie Ce travail constitue un premier pas vers un outil utilisable en pratique. Il donne une base théorique solide à l’analyse d’impact en définissant formellement la notion d’impact et en proposant une manière efficace de cerner l’impact d’un éventuel dysfonctionnement par l’analyse directe du code source du programme. Il reste encore plusieurs étapes à franchir avant de pouvoir utiliser cette analyse en pratique. Tout d’abord, il faudra terminer la preuve Coq du théorème de correction de la sé- mantique abstraite vis-à-vis de la sémantique collectrice. Celle-ci n’a pas été terminée par manque de temps. Cependant, nous avons entamé de façon significative la preuve sur papier 4.4.3.4 en procédant par induction sur le jugement d’évaluation de la sémantique abstraite. Parmi les dix-huit cas de l’induction, nous en avons traité quatre, dont le cas de l’application qui est vraisemblablement un des cas les plus complexes à prouver. Cette preuve permettra de clôturer la preuve complète de l’analyse statique. Ensuite, il faudra envisager d’étendre le langage sur lequel s’effectue l’analyse pour prendre en compte les fonctionnalités présentes dans les langages ML utilisés dans l’industrie. En particulier il sera nécessaire de gérer les variables mutables et éventuellement les tableaux de valeurs mutables. Cette extension nécessitera probablement une modification de toutes les sémantiques, ce qui aura sans doute un impact conséquent sur les preuves des théorèmes de correction. Une piste intéressante pour éviter la modification de toutes les sémantiques serait d’utiliser une traduction pour transformer tout programme en un programme équivalent ne contenant pas de mutables. Ce type de traduction peut être réalisé de façon naïve en encodant l’environnement des mutables dans le langage et en l’ajoutant en argument et en valeur de retour de toutes les fonctions. On peut aussi utiliser une analyse d’effets pour n’ajouter en argument que les valeurs nécessaires. Le but de l’analyse est de fournir au développeur ainsi qu’à l’évaluateur de logiciels critiques un outil de spécification et de vérification du flot d’information, à l’image de celui présent dans SPARK. Il faudra donc définir un langage d’annotation permettant de spécifier les relations entre les entrées et les sorties d’un sous-programme. On pourra 204CONCLUSION ensuite utiliser notre analyse pour inférer les dépendances du sous-programme et vérifier l’adéquation entre les dépendances inférées et la spécification donnée par l’utilisateur. Optimisation de l’analyse Outre le travail consistant à compléter l’analyse pour en faire un outil utilisable en pratique, différentes pistes d’optimisation de l’analyse sont envisageables. Certaines permettront d’améliorer les performances de l’analyse afin de faciliter le passage à l’échelle pour analyser des programmes de taille importante. D’autres permettront de raffiner l’analyse pour obtenir des résultats plus précis. En particulier, deux pistes nous semblent prometteuses : l’amélioration de la repré- sentation abstraite des fonctions dans l’algèbre des valeurs et l’ajout d’une représentation abstraite pour les types sommes. La représentation actuelle des fonctions dans l’algèbre des valeurs abstraites se présente sous forme d’une fermeture. Celle-ci contient le corps de la fonction qui est analysé à chaque endroit du programme où la fonction est appliquée à un argument. L’idée d’amélioration est de trouver une représentation compacte des fonctions ne contenant pas leur corps mais uniquement une information synthétique concernant le lien entre la valeur de retour de la fonction et son paramètre. Une telle représentation ressemblerait probablement aux types des fonctions dans FlowCaml. L’avantage serait double. D’une part le temps d’exécution de l’analyse pourrait être considérablement réduit en analysant le corps de chaque fonction une fois pour toute (probablement à l’aide d’une exécution symbolique) et non à chaque site d’appel de la fonction. D’autre part, l’analyse pourrait gagner en précision puisque l’union de deux fonctions abstraites ne serait plus nécessairement la valeur abstraite ⊤ mais pourrait être une approximation moins brutale dans le treillis des valeurs abstraites. En ce qui concerne les types sommes, le but serait d’améliorer la précision de l’analyse. Le fait de pouvoir représenter les types sommes dans l’algèbre des valeurs abstraites nous permettrait de rendre plus riche le treillis des valeurs abstraites. On pourrait ainsi profiter de connaissances plus fines sur les valeurs possibles d’une expression filtrée afin d’éliminer certains cas du filtrage. 205CONCLUSION 206Bibliographie [ABDP12] P. Ayrault, V. Benayoun, C. Dubois, and F. Pessaux. ML Dependency Analysis for Assessors. In International Conference on Software Engineering and Formal Methods (SEFM’12), volume 7504 of LNCS, pages 278–292, Thessaloniki, Greece, October 2012. [ABHR99] Martín Abadi, Anindya Banerjee, Nevin Heintze, and Jon G. Riecke. A core calculus of dependency. In Andrew W. Appel and Alex Aiken, editors, POPL, pages 147–160. ACM, 1999. [ACL03] June Andronick, Boutheina Chetali, and Olivier Ly. Using coq to verify java card tm applet isolation properties. In David Basin and Burkhart Wolff, editors, Theorem Proving in Higher Order Logics, volume 2758 of Lecture Notes in Computer Science, pages 335–351. Springer Berlin Heidelberg, 2003. [ALL96] Martín Abadi, Butler W. Lampson, and Jean-Jacques Lévy. Analysis and caching of dependencies. In Robert Harper and Richard L. Wexelblat, editors, ICFP, pages 83–91. ACM, 1996. [Ayr11] Philippe Ayrault. Développement de logiciel critique en Focalize. Méthodologie et outils pour l’évaluation de conformité. PhD thesis, Université Pierre et Marie Curie - LIP6, 2011. [Bar03] John Barnes. High Integrity Software : The SPARK Approach to Safety and Security. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. [BHA86] Geoffrey L Burn, Chris Hankin, and Samson Abramsky. Strictness analysis for higher-order functions. Science of Computer Programming, 7 :249–278, 1986. 207BIBLIOGRAPHIE [BVi14] Preuve de correction de l’analyse de dépendance en Coq. https://github. com/vincent-benayoun/PhD-thesis, 2014. [CC77] Patrick Cousot and Radhia Cousot. Abstract interpretation : A unified lattice model for static analysis of programs by construction or approximation of fixpoints. In Proceedings of the 4th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, POPL ’77, pages 238–252, New York, NY, USA, 1977. ACM. [CC79] Patrick Cousot and Radhia Cousot. Systematic design of program analysis frameworks. In Proceedings of the 6th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, POPL ’79, pages 269–282, New York, NY, USA, 1979. ACM. [CEC] Extraction Coq vers du code fonctionnel. http://coq.inria.fr/refman/ Reference-Manual025.html. [CH04] Roderick Chapman and Adrian Hilton. Enforcing security and safety models with an information flow analysis tool. Ada Lett., XXIV(4) :39–46, November 2004. [CKK+12] Pascal Cuoq, Florent Kirchner, Nikolai Kosmatov, Virgile Prevosto, Julien Signoles, and Boris Yakobowski. Frama-c - a software analysis perspective. In George Eleftherakis, Mike Hinchey, and Mike Holcombe, editors, SEFM, volume 7504 of Lecture Notes in Computer Science, pages 233–247. Springer, 2012. [CMP10] Dumitru Ceara, Laurent Mounier, and Marie-Laure Potet. Taint dependency sequences : A characterization of insecure execution paths based on inputsensitive cause sequences. In Proceedings of the 2010 Third International Conference on Software Testing, Verification, and Validation Workshops, ICSTW ’10, pages 371–380, Washington, DC, USA, 2010. IEEE Computer Society. [CRE13] Contribution Coq : RelationExtraction. http://coq.inria.fr/pylons/ contribs/view/RelationExtraction/v8.4, 2013. [FHJ+06] Ansgar Fehnker, Ralf Huuck, Patrick Jayet, Michel Lussenburg, and Felix Rauch. Goanna - a static model checker. In Lubos Brim, Boudewijn R. Ha- 208BIBLIOGRAPHIE verkort, Martin Leucker, and Jaco van de Pol, editors, FMICS/PDMC, volume 4346 of Lecture Notes in Computer Science, pages 297–300. Springer, 2006. [Flo03] The Flow Caml System - Documentation and user’s manual. http://www. normalesup.org/~simonet/soft/flowcaml/flowcaml-manual.pdf, 2003. [GM82] Joseph A. Goguen and José Meseguer. Security policies and security models. In IEEE Symposium on Security and Privacy, pages 11–20, 1982. [Hun91] Sebastian Hunt. Abstract Interpretation of Functional Languages : From Theory to Practice. PhD thesis, Department of Computing, Imperial College of Science Technology and Medicine, 1991. [JES00] Simon L. Peyton Jones, Jean-Marc Eber, and Julian Seward. Composing contracts : an adventure in financial engineering, functional pearl. In Odersky and Wadler [OW00], pages 280–292. [Jon94] Neil D. Jones. Abstract interpretation : a semantics-based tool for program analysis, 1994. [Kni12] Is Knight’s 440 million glitch the costliest computer bug ever ? http://money. cnn.com/2012/08/09/technology/knight-expensive-computer-bug, 2012. [Kri07] Jens Krinke. Information flow control and taint analysis with dependence graphs, 2007. [MSA80] MIL-STD-1629A. Procedure for performing a Failure Mode, Effets and Criticality Analysis. Department of Defense, November 1980. [MW08] Yaron Minsky and Stephen Weeks. Caml trading - experiences with functional programming on wall street. J. Funct. Program., 18(4) :553–564, 2008. [Myc81] Alan Mycroft. Abstract interpretation and optimising transformations for applicative programs. PhD thesis, University of Edinburgh, 1981. [OW00] Martin Odersky and Philip Wadler, editors. Proceedings of the Fifth ACM SIGPLAN International Conference on Functional Programming (ICFP ’00), Montreal, Canada, September 18-21, 2000. ACM, 2000. [PAC+08] Bruno Pagano, Olivier Andrieu, Benjamin Canou, Emmanuel Chailloux, JeanLouis Colaço, Thomas Moniot, and Philippe Wang. Certified development tools 209implementation in objective caml. In Paul Hudak and David Scott Warren, editors, PADL, volume 4902 of Lecture Notes in Computer Science, pages 2–17. Springer, 2008. [PC00] François Pottier and Sylvain Conchon. Information flow inference for free. In Odersky and Wadler [OW00], pages 46–57. [PS02] François Pottier and Vincent Simonet. Information flow inference for ml. In John Launchbury and John C. Mitchell, editors, POPL, pages 319–330. ACM, 2002. [RTC92] RTCA, Incorporated. Software Considerations in Airborne Systems and Equipment Certification, 1992. [SR03] Vincent Simonet and Inria Rocquencourt. Flow caml in a nutshell. In Proceedings of the first APPSEM-II workshop, pages 152–165, 2003. [Sta99] Standard Cenelec EN 50128. Railway Applications - Communications, Signaling and Processing Systems - Software for Railway Control and Protection Systems, 1999. [TDD12] Pierre-Nicolas Tollitte, David Delahaye, and Catherine Dubois. Producing certified functional code from inductive specifications. In Chris Hawblitzel and Dale Miller, editors, CPP, volume 7679 of Lecture Notes in Computer Science, pages 76–91. Springer, 2012. [X6086] X60510. Procédures d’analyse des modes de défaillance et de leurs effets (AMDE). AFNOR, Décembre 1986. [XBS06] Wei Xu, Sandeep Bhatkar, and R. Sekar. Taint-enhanced policy enforcement : A practical approach to defeat a wide range of attacks. In In the Proc. of the 15th USENIX Security Symp, 2006.Annexes 211Annexe A Définitions des sémantiques en Coq 213A.1. SÉMANTIQUE OPÉRATIONNELLE A.1 Sémantique opérationnelle Inductive val_of : env → expr → val → Prop := | Val_of_num : forall (v : Z) (c : env), val_of c (Num v) (V_Num v) | Val_of_ident : forall (c : env) (i : identifier) (v : val), assoc_ident_in_env i c = Ident_in_env v → val_of c (Var i) v | Val_of_lambda : forall (c:env) (x:identifier) (e:expr), val_of c (Lambda x e) (V_Closure x e c) | Val_of_rec : forall (c:env) (f x:identifier) (e:expr), val_of c (Rec f x e) (V_Rec_Closure f x e c) | Val_of_apply : forall (c c1 : env) (e1 e2 e : expr) (x: identifier) (v2 v: val), val_of c e1 (V_Closure x e c1) → val_of c e2 v2 → val_of (add_env x v2 c1) e v → val_of c (Apply e1 e2) v | Val_of_apply_rec : forall (c c1 : env) (e1 e2 e : expr) (f x: identifier) (v2 v: val), val_of c e1 (V_Rec_Closure f x e c1) → val_of c e2 v2 → val_of (add_env f (V_Rec_Closure f x e c1) (add_env x v2 c1)) e v → val_of c (Apply e1 e2) v | Val_of_let : forall (c : env) (x : identifier) (e1 e2 : expr) (v1 v : val), val_of c e1 v1 → val_of (add_env x v1 c) e2 v → val_of c (Let_in x e1 e2) v | Val_of_If_true : forall (c : env) (e e1 e2 : expr) (v : val), val_of c e (V_Bool true) → val_of c e1 v → val_of c (If e e1 e2) v | Val_of_If_false : forall (c : env) (e e1 e2 : expr) (v : val), val_of c e (V_Bool false) → val_of c e2 v → val_of c (If e e1 e2) v | Val_of_Match : forall (c c_p : env) (e e1 : expr) (p : pattern) (v v_e : val) (br2 : option (identifier∗expr)), val_of c e v_e → is_filtered v_e p = Filtered_result_Match c_p → val_of (conc_env c_p c) e1 v → val_of c (Expr_match e (p,e1) br2) v | Val_of_Match_var : forall (c : env) (e e1 e2 : expr) (p : pattern) (v v_e : val) (x : identifier), val_of c e v_e → is_filtered v_e p = Filtered_result_Match_var → val_of (add_env x v_e c) e2 v → val_of c (Expr_match e (p,e1) (Some (x,e2))) v | Val_of_Constr0 : forall c n, val_of c (Constr0 n) (V_Constr0 n) | Val_of_Constr1 : forall c n e v, val_of c e v → val_of c (Constr1 n e) (V_Constr1 n v) | Val_of_Couple : forall c (e1 e2 : expr) (v1 v2 : val), val_of c e1 v1 → val_of c e2 v2 → val_of c (Couple e1 e2) (V_Couple v1 v2) | Val_of_Annot : forall c (l : label) (e : expr) v, val_of c e v → val_of c (Annot l e) v. 214A.2. SÉMANTIQUE AVEC INJECTION A.2 Sémantique avec injection Inductive val_of_with_injection : label → val → oitenv → expr → val → Prop := | Val_of_with_injection_Num : forall (l:label) (vl:val) (v:Z) (c:oitenv), val_of_with_injection l vl c (Num v) (V_Num v) | Val_of_with_injection_Ident : forall (l:label) (vl v:val) (c:oitenv) (i:identifier) (uu:oitval), assoc_ident_in_oitenv i c = Ident_in_oitenv uu → Some v = instantiate_oitval l vl uu → val_of_with_injection l vl c (Var i) v | Val_of_with_injection_Lambda : forall (l:label) (vl v:val) (c:oitenv) (c’:env) (x:identifier) (e:expr), Some c’ = instantiate_oitenv l vl c → v = V_Closure x e c’ → val_of_with_injection l vl c (Lambda x e) v | Val_of_with_injection_Rec : forall (l:label) (vl v:val) (c:oitenv) (c’:env) (f x:identifier) (e:expr), Some c’ = instantiate_oitenv l vl c → v = V_Rec_Closure f x e c’ → val_of_with_injection l vl c (Rec f x e) v | Val_of_with_injection_Apply : forall (l:label) (vl:val) (c:oitenv) (c1:env) (e1 e2 e:expr) (x:identifier) (v2 v:val), val_of_with_injection l vl c e1 (V_Closure x e c1) → val_of_with_injection l vl c e2 v2 → val_of_with_injection l vl (OITEnv_cons x (val_to_oitval v2) (env_to_oitenv c1)) e v → val_of_with_injection l vl c (Apply e1 e2) v | Val_of_with_injection_Apply_rec : forall (l:label) (vl:val) (c : oitenv) (c1 : env) (e1 e2 e : expr) (f x : identifier) (v2 v : val), val_of_with_injection l vl c e1 (V_Rec_Closure f x e c1) → val_of_with_injection l vl c e2 v2 → val_of_with_injection l vl (env_to_oitenv (add_env f (V_Rec_Closure f x e c1) (add_env x v2 c1))) e v → val_of_with_injection l vl c (Apply e1 e2) v | Val_of_with_injection_Let_in : forall (l:label) (vl:val) (c : oitenv) (i : identifier) (e1 e2 : expr) (v1 v2 : val), val_of_with_injection l vl c e1 v1 → val_of_with_injection l vl (OITEnv_cons i (val_to_oitval v1) c) e2 v2 → val_of_with_injection l vl c (Let_in i e1 e2) v2 | Val_of_with_injection_If_true : forall (l:label) (vl:val) (c : oitenv) (e e1 e2 : expr) (v : val), val_of_with_injection l vl c e (V_Bool true) → val_of_with_injection l vl c e1 v → val_of_with_injection l vl c (If e e1 e2) v 215A.2. SÉMANTIQUE AVEC INJECTION | Val_of_with_injection_If_false : forall (l:label) (vl:val) (c : oitenv) (e e1 e2 : expr) (v : val), val_of_with_injection l vl c e (V_Bool false) → val_of_with_injection l vl c e2 v → val_of_with_injection l vl c (If e e1 e2) v | Val_of_with_injection_Match : forall (l:label) (vl:val) (c:oitenv) (c_p:env) (e e1 : expr) (p : pattern) (v v_e : val) (br2 : option (identifier∗expr)), val_of_with_injection l vl c e v_e → is_filtered v_e p = Filtered_result_Match c_p → val_of_with_injection l vl (conc_oitenv (env_to_oitenv c_p) c) e1 v → val_of_with_injection l vl c (Expr_match e (p,e1) br2) v | Val_of_with_injection_Match_var : forall (l:label) (vl:val) (c : oitenv) (e e1 e2 : expr) (p : pattern) (v v_e : val) (x : identifier), val_of_with_injection l vl c e v_e → is_filtered v_e p = Filtered_result_Match_var → val_of_with_injection l vl (OITEnv_cons x (val_to_oitval v_e) c) e2 v → val_of_with_injection l vl c (Expr_match e (p,e1) (Some (x,e2))) v | Val_of_with_injection_Constr0 : forall (l:label) (vl:val) c n, val_of_with_injection l vl c (Constr0 n) (V_Constr0 n) | Val_of_with_injection_Constr1 : forall (l:label) (vl:val) c n e v, val_of_with_injection l vl c e v → val_of_with_injection l vl c (Constr1 n e) (V_Constr1 n v) | Val_of_with_injection_Couple : forall (l:label) (vl:val) c (e1 e2 : expr) (v1 v2 : val), val_of_with_injection l vl c e1 v1 → val_of_with_injection l vl c e2 v2 → val_of_with_injection l vl c (Couple e1 e2) (V_Couple v1 v2) | Val_of_with_injection_Annot_eq : forall (l:label) (vl:val) c (e : expr), val_of_with_injection l vl c (Annot l e) vl | Val_of_with_injection_Annot_neq : forall (l:label) (vl:val) c (l’ : label) (e : expr) v, val_of_with_injection l vl c e v → neq_label l l’ → val_of_with_injection l vl c (Annot l’ e) v. 216A.3. SÉMANTIQUE SUR-INSTRUMENTÉE A.3 Sémantique sur-instrumentée Inductive oival_of : oitenv → expr → oitval → Prop := | OIVal_of_Num : forall (v:Z) (c:oitenv), oival_of c (Num v) (OIV nil (OIV_ nil (OIV_Num v))) | OIVal_of_Ident : forall (c:oitenv) (x:identifier) (uu:oitval), assoc_ident_in_oitenv x c = Ident_in_oitenv uu → oival_of c (Var x) uu | OIVal_of_Lambda : forall (c:oitenv) (x:identifier) (e:expr) (uu:oitval), uu = OIV nil (OIV_ nil (OIV_Closure x e (oitenv_to_oienv c))) → oival_of c (Lambda x e) uu | OIVal_of_Rec : forall (c:oitenv) (f x:identifier) (e:expr) (uu:oitval), uu = OIV nil (OIV_ nil (OIV_Rec_Closure f x e (oitenv_to_oienv c))) → oival_of c (Rec f x e) uu | OIVal_of_Apply : forall (c:oitenv) (c1:oienv) (e1 e2 e : expr) (x : identifier) (uu2 uu:oitval) (u2:oival) (d d’ d1:oideps) (td1 td2 td td’:oitdeps) (v:oival0), oival_of c e1 (OIV td1 (OIV_ d1 (OIV_Closure x e c1))) → oival_of c e2 uu2 → uu2 = OIV td2 u2 → oival_of (OITEnv_cons x uu2 (oienv_to_oitenv c1)) e (OIV td (OIV_ d v)) → deps_spec_Apply uu2 d1 td’ d’ (* specification des dependances td’ et d’ *) → uu = OIV (conc_oitdeps td1 (conc_oitdeps td2 (conc_oitdeps td td’))) (OIV_ (conc_oideps d’ d) v) (* resultat de l’application *) → oival_of c (Apply e1 e2) uu | OIVal_of_Apply_Rec : forall (c:oitenv) (c1:oienv) (e1 e2 e : expr) (f x:identifier) (uu1 uu2 uu:oitval) (u2:oival) (d d’ d1:oideps) (td1 td2 td td’:oitdeps) (v:oival0), oival_of c e1 uu1 → uu1 = (OIV td1 (OIV_ d1 (OIV_Rec_Closure f x e c1))) → oival_of c e2 uu2 → uu2 = OIV td2 u2 → oival_of (OITEnv_cons f uu1 (OITEnv_cons x uu2 (oienv_to_oitenv c1))) e (OIV td (OIV_ d v)) → deps_spec_Apply uu2 d1 td’ d’ (* specification des dependances td’ et d’ *) → uu = OIV (conc_oitdeps td1 (conc_oitdeps td2 (conc_oitdeps td td’))) (OIV_ (conc_oideps d’ d) v) (* resultat de l’application *) → oival_of c (Apply e1 e2) uu | OIVal_of_Let_in : forall (c:oitenv) (x:identifier) (e1 e2:expr) (uu1 uu2:oitval) (td1 td2:oitdeps) (u1 u2:oival), oival_of c e1 uu1 → uu1 = (OIV td1 u1) → oival_of (OITEnv_cons x uu1 c) e2 uu2 → uu2 = (OIV td2 u2) → oival_of c (Let_in x e1 e2) (OIV (conc_oitdeps td1 td2) u2) | OIVal_of_If_true : forall (c:oitenv) (e e1 e2:expr) (td td1 td’:oitdeps) (d d1 d’:oideps) (uu1:oitval) (v1:oival0), oival_of c e (OIV td (OIV_ d (OIV_Bool true))) → oival_of c e1 uu1 → uu1 = (OIV td1 (OIV_ d1 v1)) → deps_spec_If c e1 e2 d td’ d’ (* specification des dependances td’ et d’ *) → oival_of c (If e e1 e2) (OIV (conc_oitdeps td’ (conc_oitdeps td td1)) (OIV_ (conc_oideps d’ d1) v1)) 217A.3. SÉMANTIQUE SUR-INSTRUMENTÉE | OIVal_of_If_false : forall (c:oitenv) (e e1 e2:expr) (td td2 td’:oitdeps) (d d2 d’:oideps) (uu2:oitval) (v2:oival0), oival_of c e (OIV td (OIV_ d (OIV_Bool false))) → oival_of c e2 uu2 → uu2 = (OIV td2 (OIV_ d2 v2)) → deps_spec_If c e1 e2 d td’ d’ (* specification des dependances td’ et d’ *) → oival_of c (If e e1 e2) (OIV (conc_oitdeps td’ (conc_oitdeps td td2)) (OIV_ (conc_oideps d’ d2) v2)) | OIVal_of_Match : forall (c c_p:oitenv) (e e1 e2: expr) (p:pattern) (x:identifier) (uu uu1:oitval) (td td1 td’:oitdeps) (d d1 d’:oideps) (v v1:oival0), oival_of c e uu → uu = (OIV td (OIV_ d v)) → is_filtered_oitval uu p = Filtered_oitval_result_Match c_p → oival_of (conc_oitenv c_p c) e1 uu1 → uu1 = (OIV td1 (OIV_ d1 v1)) → deps_spec_Match c p x e1 e2 d td’ d’ (* specification des dependances td’ et d’ *) → oival_of c (Expr_match e (p,e1) (Some (x,e2))) (OIV (conc_oitdeps td’ (conc_oitdeps td td1)) (OIV_ (conc_oideps d’ d1) v1)) | OIVal_of_Match_var : forall (c:oitenv) (e e1 e2: expr) (p:pattern) (x:identifier) (uu uu2:oitval) (td td2 td’:oitdeps) (d d2 d’:oideps) (v v2:oival0), oival_of c e uu → uu = (OIV td (OIV_ d v)) → is_filtered_oitval uu p = Filtered_oitval_result_Match_var → oival_of (OITEnv_cons x uu c) e2 uu2 → uu2 = (OIV td2 (OIV_ d2 v2)) → deps_spec_Match c p x e1 e2 d td’ d’ (* specification des dependances td’ et d’ *) → oival_of c (Expr_match e (p,e1) (Some (x,e2))) (OIV (conc_oitdeps td’ (conc_oitdeps td td2)) (OIV_ (conc_oideps d’ d2) v2)) | OIVal_of_Constr0 : forall (c:oitenv) (n:constr), oival_of c (Constr0 n) (OIV nil (OIV_ nil (OIV_Constr0 n))) | OIVal_of_Constr1 : forall (c:oitenv) (n:constr) (e:expr) (td:oitdeps) (u:oival), oival_of c e (OIV td u) → oival_of c (Constr1 n e) (OIV td (OIV_ nil (OIV_Constr1 n u))) | OIVal_of_Couple : forall (c:oitenv) (e1 e2:expr) (td1 td2:oitdeps) (u1 u2:oival), oival_of c e1 (OIV td1 u1) → oival_of c e2 (OIV td2 u2) → oival_of c (Couple e1 e2) (OIV (conc_oitdeps td1 td2) (OIV_ nil (OIV_Couple u1 u2))) | OIVal_of_Annot : forall (c:oitenv) (l:label) (e:expr) (td:oitdeps) (d:oideps) (v:oival0), oival_of c e (OIV td (OIV_ d v)) → oival_of c (Annot l e) (OIV td (OIV_ (cons (l, fun x⇒ x) d) v)). 218A.4. SÉMANTIQUE INSTRUMENTÉE A.4 Sémantique instrumentée Inductive ival_of : itenv → expr → itval → Prop := | IVal_of_Num : forall (v:Z) (c:itenv), ival_of c (Num v) (IV nil (IV_ nil (IV_Num v))) | IVal_of_Ident : forall (c:itenv) (x:identifier) (uu:itval), assoc_ident_in_itenv x c = Ident_in_itenv uu → ival_of c (Var x) uu | IVal_of_Lambda : forall (c:itenv) (x:identifier) (e:expr) (uu:itval), uu = IV nil (IV_ nil (IV_Closure x e (itenv_to_ienv c))) → ival_of c (Lambda x e) uu | IVal_of_Rec : forall (c:itenv) (f x:identifier) (e:expr) (uu:itval), uu = IV nil (IV_ nil (IV_Rec_Closure f x e (itenv_to_ienv c))) → ival_of c (Rec f x e) uu | IVal_of_Apply : forall (c:itenv) (c1:ienv) (e1 e2 e : expr) (x : identifier) (uu2 uu:itval) (u2:ival) (d d1:ideps) (td1 td2 td:itdeps) (v:ival0), (* construction de la valeur *) ival_of c e1 (IV td1 (IV_ d1 (IV_Closure x e c1))) → ival_of c e2 uu2 → uu2 = IV td2 u2 → ival_of (ITEnv_cons x uu2 (ienv_to_itenv c1)) e (IV td (IV_ d v)) (* resultat de l’application *) → uu = IV (conc_itdeps td1 (conc_itdeps td2 (conc_itdeps td d1))) (IV_ (conc_ideps d1 d) v) → ival_of c (Apply e1 e2) uu | IVal_of_Apply_Rec : forall (c:itenv) (c1:ienv) (e1 e2 e : expr) (f x:identifier) (uu1 uu2 uu:itval) (u2:ival) (d d1:ideps) (td1 td2 td:itdeps) (v:ival0), (* construction de la valeur *) ival_of c e1 uu1 → uu1 = (IV td1 (IV_ d1 (IV_Rec_Closure f x e c1))) → ival_of c e2 uu2 → ival_of (ITEnv_cons f uu1 (ITEnv_cons x uu2 (ienv_to_itenv c1))) e (IV td (IV_ d v)) → uu2 = IV td2 u2 (* resultat de l’application *) → uu = IV (conc_itdeps td1 (conc_itdeps td2 (conc_itdeps td d1))) (IV_ (conc_ideps d1 d) v) → ival_of c (Apply e1 e2) uu | IVal_of_Let_in : forall (c:itenv) (x:identifier) (e1 e2:expr) (uu1 uu2:itval) (td1 td2:itdeps) (u1 u2:ival), ival_of c e1 uu1 → uu1 = (IV td1 u1) → ival_of (ITEnv_cons x uu1 c) e2 uu2 → uu2 = (IV td2 u2) → ival_of c (Let_in x e1 e2) (IV (conc_itdeps td1 td2) u2) 219A.4. SÉMANTIQUE INSTRUMENTÉE | IVal_of_If_true : forall (c:itenv) (e e1 e2:expr) (td td1:itdeps) (d d1:ideps) (uu1:itval) (v1:ival0), ival_of c e (IV td (IV_ d (IV_Bool true))) → ival_of c e1 uu1 → uu1 = (IV td1 (IV_ d1 v1)) → ival_of c (If e e1 e2) (IV (conc_itdeps d (conc_itdeps td td1)) (IV_ (conc_ideps d d1) v1)) | IVal_of_If_false : forall (c:itenv) (e e1 e2:expr) (td td2:itdeps) (d d2:ideps) (uu2:itval) (v2:ival0), ival_of c e (IV td (IV_ d (IV_Bool false))) → ival_of c e2 uu2 → uu2 = (IV td2 (IV_ d2 v2)) → ival_of c (If e e1 e2) (IV (conc_itdeps d (conc_itdeps td td2)) (IV_ (conc_ideps d d2) v2)) | IVal_of_Match : forall (c c_p:itenv) (e e1 e2: expr) (p:pattern) (x:identifier) (uu uu1:itval) (td td1:itdeps) (d d1:ideps) (v v1:ival0), ival_of c e uu → uu = (IV td (IV_ d v)) → is_filtered_itval uu p = Filtered_itval_result_Match c_p → ival_of (conc_itenv c_p c) e1 uu1 → uu1 = (IV td1 (IV_ d1 v1)) → ival_of c (Expr_match e (p,e1) (Some (x,e2))) (IV (conc_itdeps d (conc_itdeps td td1)) (IV_ (conc_ideps d d1) v1)) | IVal_of_Match_var : forall (c:itenv) (e e1 e2: expr) (p:pattern) (x:identifier) (uu uu2:itval) (td td2:itdeps) (d d2:ideps) (v v2:ival0), ival_of c e uu → uu = (IV td (IV_ d v)) → is_filtered_itval uu p = Filtered_itval_result_Match_var → ival_of (ITEnv_cons x uu c) e2 uu2 → uu2 = (IV td2 (IV_ d2 v2)) → ival_of c (Expr_match e (p,e1) (Some (x,e2))) (IV (conc_itdeps d (conc_itdeps td td2)) (IV_ (conc_ideps d d2) v2)) | IVal_of_Constr0 : forall (c:itenv) (n:constr), ival_of c (Constr0 n) (IV nil (IV_ nil (IV_Constr0 n))) | IVal_of_Constr1 : forall (c:itenv) (n:constr) (e:expr) (td:itdeps) (u:ival), ival_of c e (IV td u) → ival_of c (Constr1 n e) (IV td (IV_ nil (IV_Constr1 n u))) | IVal_of_Couple : forall (c:itenv) (e1 e2:expr) (td1 td2:itdeps) (u1 u2:ival), ival_of c e1 (IV td1 u1) → ival_of c e2 (IV td2 u2) → ival_of c (Couple e1 e2) (IV (conc_itdeps td1 td2) (IV_ nil (IV_Couple u1 u2))) | IVal_of_Annot : forall (c:itenv) (l:label) (e:expr) (td:itdeps) (d:ideps) (v:ival0), ival_of c e (IV td (IV_ d v)) → ival_of c (Annot l e) (IV td (IV_ (cons l d) v)). 220A.5. SÉMANTIQUE INSTRUMENTÉE MULTIPLE A.5 Sémantique instrumentée multiple Inductive imval_of : imenv → expr → imval → Prop := | IMVal_of : forall (imc:imenv) (e:expr) (imv:imval), imv = (fun itu ⇒ exists (itc:itenv), In _ imc itc ∧ ival_of itc e itu) → imval_of imc e imv. 221A.6. SÉMANTIQUE COLLECTRICE A.6 Sémantique collectrice Inductive ctval_of : ctenv → expr → ctval → Prop := | CTVal_of_Num : forall (ctc:ctenv) (v:Z), ctval_of ctc (Num v) (CTVal nil nil (Singleton _ (IV_Num v))) | CTVal_of_Constr0 : forall (ctc:ctenv) (n:constr), ctval_of ctc (Constr0 n) (CTVal nil nil (Singleton _ (IV_Constr0 n))) | CTVal_of_Constr1 : forall (ctc:ctenv) (n:constr) (e:expr) (td:itdeps) (d:ideps) (ivs ivs’:Ensemble ival0), ctval_of ctc e (CTVal td d ivs) → ivs’ = SetMap (fun iv ⇒ IV_Constr1 n (IV_ d iv)) ivs → ctval_of ctc (Constr1 n e) (CTVal td nil ivs’) | CTVal_of_Apply : forall (ctc:ctenv) (e1 e2:expr) (td1 td2 td:itdeps) (d1 d2 d:ideps) (ivs1 ivs2:Ensemble ival0) (ctv:ctval) (imv:Ensemble itval), ctval_of ctc e1 (CTVal td1 d1 ivs1) → ctval_of ctc e2 (CTVal td2 d2 ivs2) → imv = (fun itu ⇒ (exists x e ic1 iv2 itd id iv, In _ ivs1 (IV_Closure x e ic1) ∧ In _ ivs2 iv2 ∧ ival_of (ITEnv_cons x (IV td2 (IV_ d2 iv2)) (ienv_to_itenv ic1)) e (IV itd (IV_ id iv)) ∧ itu = IV (conc_itdeps td1 (conc_itdeps td2 (conc_itdeps itd d1))) (IV_ (conc_ideps d1 id) iv)) ∨ (exists f x e ic iv2 itd id iv, In _ ivs1 (IV_Rec_Closure f x e ic) ∧ In _ ivs2 iv2 ∧ ival_of (ITEnv_cons f (IV td1 (IV_ d1 (IV_Rec_Closure f x e ic))) (ITEnv_cons x (IV td2 (IV_ d2 iv2)) (ienv_to_itenv ic))) e (IV itd (IV_ id iv)) ∧ itu = IV (conc_itdeps td1 (conc_itdeps td2 (conc_itdeps itd d1))) (IV_ (conc_ideps d1 id) iv))) → (forall l:label, List.In l td ↔ (exists td’, List.In l td’ ∧ In _ (SetMap (fun itu ⇒ match itu with | IV td (IV_ d iv) ⇒ td end) imv) td’)) → (forall l:label, List.In l d ↔ (exists d’, List.In l d’ ∧ In _ (SetMap (fun itu ⇒ match itu with | IV td (IV_ d iv) ⇒ d end) imv) d’)) → ctv = CTVal td d (SetMap (fun itu ⇒ match itu with | IV td (IV_ d iv) ⇒ iv end) imv) → ctval_of ctc (Apply e1 e2) ctv | CTVal_of_Ident : forall (ctc:ctenv) (x:identifier) (ctv:ctval), assoc_ident_in_ctenv x ctc = Ident_in_ctenv ctv → ctval_of ctc (Var x) ctv 222A.6. SÉMANTIQUE COLLECTRICE | CTVal_of_Ident_empty :forall (ctc:ctenv) (x:identifier), assoc_ident_in_ctenv x ctc = Ident_not_in_ctenv → ctval_of ctc (Var x) (CTVal nil nil (Empty_set _)) | CTVal_of_Lambda : forall (ctc:ctenv) (x:identifier) (e:expr) (ctv:ctval) (ivs:Ensemble ival0), ivs = SetMap (fun itc ⇒ IV_Closure x e (itenv_to_ienv itc)) (ctenv_to_imenv ctc) → ctval_of ctc (Lambda x e) (CTVal nil nil ivs) | CTVal_of_Rec : forall (ctc:ctenv) (f x:identifier) (e:expr) (ctv:ctval) (ivs:Ensemble ival0), ivs = SetMap (fun itc ⇒ IV_Rec_Closure f x e (itenv_to_ienv itc)) (ctenv_to_imenv ctc) → ctval_of ctc (Rec f x e) (CTVal nil nil ivs) | CTVal_of_If_true : forall (ctc:ctenv) (e e1 e2:expr) (td td1:itdeps) (d d1:ideps) (ivs ivs1:Ensemble ival0), ctval_of ctc e (CTVal td d ivs) → In _ ivs (IV_Bool true) → (not (In _ ivs (IV_Bool false))) → ctval_of ctc e1 (CTVal td1 d1 ivs1) → ctval_of ctc (If e e1 e2) (CTVal (conc_itdeps d (conc_itdeps td td1)) (conc_ideps d d1) ivs1) | CTVal_of_If_false : forall (ctc:ctenv) (e e1 e2:expr) (td td2:itdeps) (d d2:ideps) (ivs ivs2:Ensemble ival0), ctval_of ctc e (CTVal td d ivs) → Same_set _ ivs (Singleton _ (IV_Bool false)) → In _ ivs (IV_Bool false) → (not (In _ ivs (IV_Bool true))) → ctval_of ctc e2 (CTVal td2 d2 ivs2) → ctval_of ctc (If e e1 e2) (CTVal (conc_itdeps d (conc_itdeps td td2)) (conc_ideps d d2) ivs2) | CTVal_of_If_unknown : forall (ctc:ctenv) (e e1 e2:expr) (td td1 td2:itdeps) (d d1 d2:ideps) (ivs ivs1 ivs2:Ensemble ival0), ctval_of ctc e (CTVal td d ivs) → Included _ (Couple _ (IV_Bool true) (IV_Bool false)) ivs → ctval_of ctc e1 (CTVal td1 d1 ivs1) → ctval_of ctc e2 (CTVal td2 d2 ivs2) → ctval_of ctc (If e e1 e2) (CTVal (conc_itdeps d (conc_itdeps td (conc_itdeps td1 td2))) (conc_ideps d (conc_ideps d1 d2)) (Union _ ivs1 ivs2)) | CTVal_of_If_empty : forall (ctc:ctenv) (e e1 e2:expr) (td td1:itdeps) (d d1:ideps) (ivs ivs1:Ensemble ival0), ctval_of ctc e (CTVal td d ivs) → (not (In _ ivs (IV_Bool true))) → (not (In _ ivs (IV_Bool false))) → ctval_of ctc (If e e1 e2) (CTVal nil nil (Empty_set _)) 223A.6. SÉMANTIQUE COLLECTRICE | CTVal_of_Match : forall (ctv:ctval) (ctc ctc_p:ctenv) (e e1:expr) (br2:option (identifier∗expr)) (p:pattern) (td td1:itdeps) (d d1:ideps) (ivs ivs1:Ensemble ival0), ctval_of ctc e ctv → ctv = (CTVal td d ivs) → Inhabited _ (Intersection _ ivs ivs_of_matchable) → is_filtered_ctval ctv p (Filtered_ctval_result_Match ctc_p) → ctval_of (conc_ctenv ctc_p ctc) e1 (CTVal td1 d1 ivs1) → ctval_of ctc (Expr_match e (p,e1) br2) (CTVal (conc_itdeps d (conc_itdeps td td1)) (conc_ideps d d1) ivs1) | CTVal_of_Match_var : forall (ctv:ctval) (ctc:ctenv) (e e1 e2:expr) (p:pattern) (x:identifier) (td td2:itdeps) (d d2:ideps) (ivs ivs2:Ensemble ival0), ctval_of ctc e ctv → ctv = (CTVal td d ivs) → Inhabited _ (Intersection _ ivs ivs_of_matchable) → is_filtered_ctval ctv p Filtered_ctval_result_Match_var → ctval_of (CTEnv_cons x ctv ctc) e2 (CTVal td2 d2 ivs2) → ctval_of ctc (Expr_match e (p,e1) (Some (x,e2))) (CTVal (conc_itdeps d (conc_itdeps td td2)) (conc_ideps d d2) ivs2) | CTVal_of_Match_unknown : forall (ctv:ctval) (ctc ctc_p:ctenv) (e e1 e2:expr) (p:pattern) (x:identifier) (td td1 td2:itdeps) (d d1 d2:ideps) (ivs ivs1 ivs2:Ensemble ival0), ctval_of ctc e ctv → ctv = (CTVal td d ivs) → Inhabited _ (Intersection _ ivs ivs_of_matchable) → is_filtered_ctval ctv p (Filtered_ctval_result_Match_unknown ctc_p) → ctval_of (conc_ctenv ctc_p ctc) e1 (CTVal td1 d1 ivs1) → ctval_of (CTEnv_cons x ctv ctc) e2 (CTVal td2 d2 ivs2) → ctval_of ctc (Expr_match e (p,e1) (Some (x,e2))) (CTVal (conc_itdeps d (conc_itdeps td (conc_itdeps td1 td2))) (conc_ideps d (conc_ideps d1 d2)) (Union _ ivs1 ivs2)) | CTVal_of_Match_empty : forall (ctv:ctval) (ctc ctc_p:ctenv) (e e1:expr) (br2:option (identifier∗expr)) (p:pattern) (td td1:itdeps) (d d1:ideps) (ivs ivs1:Ensemble ival0), ctval_of ctc e ctv → ctv = (CTVal td d ivs) → not (Inhabited _ (Intersection _ ivs ivs_of_matchable)) → ctval_of ctc (Expr_match e (p,e1) br2) (CTVal nil nil (Empty_set _)) 224A.6. SÉMANTIQUE COLLECTRICE | CTVal_of_Couple : forall (ctc:ctenv) (e1 e2:expr) (td1 td2:itdeps) (d1 d2:ideps) (ivs1 ivs2 ivs’:Ensemble ival0), ctval_of ctc e1 (CTVal td1 d1 ivs1) → ctval_of ctc e2 (CTVal td2 d2 ivs2) → ivs’ = SetMap2 (fun iv1 iv2 ⇒ IV_Couple (IV_ d1 iv1) (IV_ d2 iv2)) ivs1 ivs2 → ctval_of ctc (language.Couple e1 e2) (CTVal (conc_itdeps td1 td2) nil ivs’) | CTVal_of_Annot : forall (ctc:ctenv) (l:label) (e:expr) (td:itdeps) (d:ideps) (ivs:Ensemble ival0), ctval_of ctc e (CTVal td d ivs) → ctval_of ctc (Annot l e) (CTVal td (cons l d) ivs) | CTVal_of_Let_in : forall (ctc:ctenv) (x:identifier) (e1 e2:expr) (ctv1 ctv2:ctval) (td1 td2:itdeps) (d1 d2:ideps) (ivs1 ivs2:Ensemble ival0), ctval_of ctc e1 ctv1 → ctv1 = (CTVal td1 d1 ivs1) → (exists (iv1:ival0), In _ ivs1 iv1) → ctval_of (CTEnv_cons x ctv1 ctc) e2 ctv2 → ctv2 = (CTVal td2 d2 ivs2) → ctval_of ctc (Let_in x e1 e2) (CTVal (conc_itdeps td1 td2) d2 ivs2) | CTVal_of_Let_in_empty : forall (ctc:ctenv) (x:identifier) (e1 e2:expr) (ctv1:ctval) (td1:itdeps) (d1:ideps) (ivs1:Ensemble ival0), ctval_of ctc e1 ctv1 → ctv1 = (CTVal td1 d1 ivs1) → not (Inhabited _ ivs1) → ctval_of ctc (Let_in x e1 e2) (CTVal nil nil (Empty_set _)). 225A.7. SÉMANTIQUE ABSTRAITE A.7 Sémantique abstraite Inductive atval_of : atenv → expr → atval → Prop := | ATVal_of_Num : forall (v:Z) (atc:atenv), atval_of atc (Num v) (ATV nil (AV nil (AV_Top))) | ATVal_of_Ident : forall (atc:atenv) (x:identifier) (atu:atval), assoc_ident_in_atenv x atc = Ident_in_atenv atu → atval_of atc (Var x) atu | ATVal_of_Ident_empty : forall (atc:atenv) (x:identifier) (atu:atval), assoc_ident_in_atenv x atc = Ident_not_in_atenv → atval_of atc (Var x) (ATV nil (AV nil (AV_Bottom))) | ATVal_of_Lambda : forall (atc:atenv) (x:identifier) (e:expr) (atu:atval), atu = ATV nil (AV nil (AV_Closure x e (atenv_to_aenv atc))) → atval_of atc (Lambda x e) atu | ATVal_of_Rec : forall (atc:atenv) (f x:identifier) (e:expr) (atu:atval), atu = ATV nil (AV nil (AV_Rec_Closure f x e (atenv_to_aenv atc))) → atval_of atc (Rec f x e) atu | ATVal_of_Apply : forall (atc:atenv) (ac1:aenv) (e1 e2 e : expr) (x : identifier) (atu2 atu:atval) (au2:aval) (ad ad1:adeps) (atd1 atd2 atd:atdeps) (av:aval0), (* construction de la valeur *) atval_of atc e1 (ATV atd1 (AV ad1 (AV_Closure x e ac1))) → atval_of atc e2 atu2 → atu2 = ATV atd2 au2 → atval_of (ATEnv_cons x atu2 (aenv_to_atenv ac1)) e (ATV atd (AV ad av)) (* resultat de l’application *) → atu = ATV (conc_atdeps atd1 (conc_atdeps atd2 (conc_atdeps atd ad1))) (AV (conc_adeps ad1 ad) av) → atval_of atc (Apply e1 e2) atu | ATVal_of_Apply_rec : forall (atc:atenv) (ac1:aenv) (e1 e2 e:expr) (f x:identifier) (atu2 atu atu_f:atval) (au2:aval) (ad ad1:adeps) (atd1 atd2 atd:atdeps) (av:aval0), (* construction de la valeur *) atval_of atc e1 (ATV atd1 (AV ad1 (AV_Rec_Closure f x e ac1))) → atu_f = ATV atd1 (AV (deps_of_freevars (Rec f x e) (atenv_to_aenv atc)) AV_Top) → atval_of atc e2 atu2 → atu2 = ATV atd2 au2 → atval_of (ATEnv_cons f atu_f (ATEnv_cons x atu2 (aenv_to_atenv ac1))) e (ATV atd (AV ad av)) (* resultat de l’application *) → atu = ATV (conc_atdeps atd1 (conc_atdeps atd2 (conc_atdeps atd ad1))) (AV (conc_adeps ad1 ad) av) → atval_of atc (Apply e1 e2) atu 226A.7. SÉMANTIQUE ABSTRAITE | ATVal_of_Apply_unknown : forall (atc:atenv) (e1 e2: expr) (atu:atval) (atd1 atd2:atdeps) (ad1 ad2:adeps) (av1 av2:aval0), (* construction de la valeur *) atval_of atc e1 (ATV atd1 (AV ad1 av1)) → (match av1 with | AV_Closure _ _ _ ⇒ False | AV_Rec_Closure _ _ _ _ ⇒ False | _ ⇒ True end) → atval_of atc e2 (ATV atd2 (AV ad2 av2)) (* resultat de l’application *) → atu = ATV (conc_atdeps atd1 (conc_atdeps atd2 (conc_atdeps ad1 ad2))) (AV (conc_adeps ad1 ad2) AV_Top) → atval_of atc (Apply e1 e2) atu (* amelioration possible : pour une analyse plus precise, si la valeur de e1 ou e2 est Bottom, retourner Bottom *) | ATVal_of_Let_in : forall (atc:atenv) (x:identifier) (e1 e2:expr) (atu1 atu2:atval) (atd1 atd2:atdeps) (au1 au2:aval), atval_of atc e1 atu1 → atu1 = (ATV atd1 au1) → atval_of (ATEnv_cons x atu1 atc) e2 atu2 → atu2 = (ATV atd2 au2) → atval_of atc (Let_in x e1 e2) (ATV (conc_atdeps atd1 atd2) au2) | ATVal_of_If : forall (atc:atenv) (e e1 e2:expr) (atd atd1 atd2:atdeps) (ad ad1 ad2:adeps) (atu1 atu2:atval) (av av1 av2:aval0), atval_of atc e (ATV atd (AV ad av)) → atval_of atc e1 atu1 → atu1 = (ATV atd1 (AV ad1 av1)) → atval_of atc e2 atu2 → atu2 = (ATV atd2 (AV ad2 av2)) → atval_of atc (If e e1 e2) (ATV (conc_atdeps ad (conc_atdeps atd (conc_atdeps atd1 atd2))) (AV (conc_adeps ad (conc_adeps ad1 ad2)) AV_Top)) | ATVal_of_Match : forall (atc atc_p:atenv) (e e1 e2: expr) (p:pattern) (x:identifier) (atu atu1:atval) (atd atd1:atdeps) (ad ad1:adeps) (av av1:aval0), atval_of atc e atu → atu = (ATV atd (AV ad av)) → is_filtered_atval atu p = Filtered_atval_result_Match atc_p → atval_of (conc_atenv atc_p atc) e1 atu1 → atu1 = (ATV atd1 (AV ad1 av1)) → atval_of atc (Expr_match e (p,e1) (Some (x,e2))) (ATV (conc_atdeps ad (conc_atdeps atd atd1)) (AV (conc_adeps ad ad1) av1)) 227A.7. SÉMANTIQUE ABSTRAITE | ATVal_of_Match_var : forall (atc atc_p:atenv) (e e1 e2: expr) (p:pattern) (x:identifier) (atu atu2:atval) (atd atd2:atdeps) (ad ad2:adeps) (av av2:aval0), atval_of atc e atu → atu = (ATV atd (AV ad av)) → is_filtered_atval atu p = Filtered_atval_result_Match_var → atval_of (ATEnv_cons x atu atc) e2 atu2 → atu2 = (ATV atd2 (AV ad2 av2)) → atval_of atc (Expr_match e (p,e1) (Some (x,e2))) (ATV (conc_atdeps ad (conc_atdeps atd atd2)) (AV (conc_adeps ad ad2) av2)) | ATVal_of_Match_unknown : forall (atc atc_p:atenv) (e e1 e2: expr) (p:pattern) (x:identifier) (atu atu1 atu2:atval) (atd atd1 atd2:atdeps) (ad ad1 ad2:adeps) (av av1 av2:aval0), atval_of atc e atu → atu = (ATV atd (AV ad av)) → is_filtered_atval atu p = Filtered_atval_result_Match_unknown atc_p → atval_of (conc_atenv atc_p atc) e1 atu1 → atu1 = (ATV atd1 (AV ad1 av1)) → atval_of (ATEnv_cons x atu atc) e2 atu2 → atu2 = (ATV atd2 (AV ad2 av2)) → atval_of atc (Expr_match e (p,e1) (Some (x,e2))) (ATV (conc_atdeps ad (conc_atdeps atd (conc_atdeps atd1 atd2))) (AV (conc_adeps ad (conc_adeps ad1 ad2)) AV_Top)) | ATVal_of_Match_bottom : forall (atc atc_p:atenv) (e e1 e2: expr) (p:pattern) (x:identifier) (atu:atval) (atd:atdeps) (ad:adeps) (av:aval0), atval_of atc e atu → atu = (ATV atd (AV ad av)) → is_filtered_atval atu p = Filtered_atval_result_Error → atval_of atc (Expr_match e (p,e1) (Some (x,e2))) (ATV nil (AV nil AV_Bottom)) | ATVal_of_Constr0 : forall (atc:atenv) (n:constr), atval_of atc (Constr0 n) (ATV nil (AV nil (AV_Constr0 n))) | ATVal_of_Constr1 : forall (atc:atenv) (n:constr) (e:expr) (atd:atdeps) (au:aval), atval_of atc e (ATV atd au) → atval_of atc (Constr1 n e) (ATV atd (AV nil (AV_Constr1 n au))) | ATVal_of_Couple : forall (atc:atenv) (e1 e2:expr) (atd1 atd2:atdeps) (au1 au2:aval), atval_of atc e1 (ATV atd1 au1) → atval_of atc e2 (ATV atd2 au2) → atval_of atc (Couple e1 e2) (ATV (conc_atdeps atd1 atd2) (AV nil (AV_Couple au1 au2))) | ATVal_of_Annot : forall (atc:atenv) (l:label) (e:expr) (atd:atdeps) (ad:adeps) (av:aval0), atval_of atc e (ATV atd (AV ad av)) → atval_of atc (Annot l e) (ATV atd (AV (cons l ad) av)). 228Annexe B Énoncés des théorèmes en Coq B.1 Correction de la sémantique avec injection Dans la version Coq de notre travail, nous avons défini la notion d’injection en formalisant directement la sémantique avec injection dans un t-environnement sur-instrumenté. Cependant, dans le manuscrit de thèse, nous avons choisi de présenter la sémantique avec injection en deux étapes pour des raisons de clarté dans la présentation. En effet, nous souhaitions commencer par introduire la notion d’injection telle que nous pouvons la concevoir de façon intuitive avant d’entrer dans les détails de la sur-instrumentation des valeurs et des environnements. Il convient de remarquer ici que la preuve de correction de nos analyses dynamique et statique ne dépend d’aucune manière de la preuve de correction de la sémantique avec injection. En effet, c’est la sémantique avec injection qui pose la définition de la notion d’injection, qui est le fondement de la notion de dépendance. Le théorème de correction que nous apportons n’est donc pas nécessaire à la preuve de nos analyses par rapport à la notion d’injection. Cependant, il constitue une justification de la définition formelle de l’injection par rapport à la notion intuitive que nous en avons. Voici le théorème de correction de la sémantique avec injection qui a été prouvé en Coq. Theorem injection_correctness : forall (l:label) (vl:val) (c:env) (c’:oitenv) (e:expr) (v:val), label_does_not_appear_in_expr l c’ e → c = oitenv_to_env c’ → val_of c e v → val_of_with_injection l vl c’ e v. 229B.2. CORRECTION DE LA SÉMANTIQUE SUR-INSTRUMENTÉE B.2 Correction de la sémantique sur-instrumentée Le théorème présenté dans le manuscrit pour la correction de la sémantique surinstrumentée (cf. section 3.4.2.3) est identique à celui prouvé en Coq. Nous avons simplement déplié la définition du prédicat is_instantiable_oitenv. Theorem oival_of_correctness : forall (c:oitenv) (e:expr) (uu:oitval), oival_of c e uu → forall (l:label) (vl:val), is_instantiable_oitenv l vl c → forall (v:val), Some v = instantiate_oitval l vl uu → val_of_with_injection l vl c e v. B.3 Correction de la sémantique instrumentée Le théorème présenté dans le manuscrit pour la correction de la sémantique instrumentée (cf. section 3.5.3.3) est identique à celui prouvé en Coq. Theorem ival_of_correctness : forall (itc:itenv) (e:expr) (itu:itval), ival_of itc e itu → exists (oitu:oitval), (oival_of (itenv_to_oitenv itc) e oitu ∧ oitval_to_itval oitu = itu). 230B.4. CORRECTION DE LA SÉMANTIQUE COLLECTRICE B.4 Correction de la sémantique collectrice Le théorème présenté dans le manuscrit pour la correction de la sémantique collectrice (cf. section 4.3.3.3) est identique à celui prouvé en Coq. On peut peut remarquer une petite différence de notation concernant la fonction de conversion d’un environnement instrumenté multiple en un environnement collecteur. En Coq, cette conversion est définie sous la forme d’un prédicat inductif alors que dans le manuscrit de thèse, nous utilisons une notation fonctionnelle. Il s’agit uniquement d’une différence de notation. La définition donnée dans le manuscrit (cf. figure 4.7) est la même que sa version Coq. Theorem ctval_of_correctness : forall (imc:imenv) (e:expr) (imv:imval) (ctv:ctval) (ctc:ctenv), imval_of imc e imv → imenv_to_ctenv imc ctc → ctval_of ctc e ctv → le_imval imv (ctval_to_imval ctv). B.5 Correction de la sémantique abstraite Le théorème présenté dans le manuscrit pour la correction de la sémantique abstraite (cf. section 4.4.3.3) est identique à celui prouvé en Coq. La preuve de ce théorème en Coq n’a pas été terminée par manque de temps. La version de la preuve présente dans le manuscrit (cf. section 4.4.3.4) est un peu plus complète puisque le cas de l’application, qui est un des cas les plus complexes, a été prouvé. Theorem atval_of_correctness : forall (e:expr) (ctc:ctenv) (ctv:ctval) (atc:atenv) (atu:atval), ctenv_to_atenv ctc atc → ctval_of ctc e ctv → atval_of atc e atu → le_ctval ctv (atval_to_ctval atu). 231B.5. CORRECTION DE LA SÉMANTIQUE ABSTRAITE 232Index Abstraction ↑ a • (•) ↑ a c (tΓ c ), 175 ↑ a im(Γim), 175 ↑ a c (tuc ), 174 ↑ a im(usi ), 174 d_of_usi (usi ), 175 Abstraction ↑ c • (•) ↑ c im(tΓ im), 160 ↑ c im(v im), 160 Abstraction ↑ i • (•) ↑ ti toi(tΓ oi), 131 ↑ i oi(Γoi), 132 ↑ ti toi(tuoi), 131 ↑ i oi(u oi), 131 ↑ i oi(v oi), 131 ↑ ti toi(tdoi), 131 ↑ i oi(d oi), 131 Ajout de t-dépendances ↑ toi oi (Γoi), 82 ↑ toi oi (u oi), 82 ↑ ti i (Γi ), 125 ↑ ti i (u i ), 125 ↑ ta a (Γa ), 180 ↑ ta a (u a ), 180 Concrétisation ↑ • a (•) ↑ c a (tΓ a ), 175 ↑ c a (Γa ), 175 ↑ c a (tua ), 175 ↑ c a (v a ), 175 Concrétisation ↑ • c (•) ↑ im c (tΓ c ), 161 appendim c (tΓ c , tΓ im), 161 ↑ im c (tuc ), 161 Concrétisation ↑ • i (•) ↑ toi ti (tΓ i ), 133 ↑ oi i (Γi ), 133 ↑ toi ti (tui ), 132 ↑ oi i (u i ), 132 ↑ oi i (v i ), 132 ↑ toi ti (tdi ), 132 ↑ oi i (d i ), 132 Ensemble des valeurs simples instrumentées V i , 121 Fonctions auxiliaires d_of_freevars(•), 178 Instanciation ↓ l:vl(tΓ oi), 67 ↓ l:vl(tuoi), 67 atifl:vl (tdoi), 69 233INDEX aifl:vl (d oi), 69 Jugement d’évaluation Γ ⊢ e →→ v, 44 Γ ⊢l:vl e →→ v, 49 tΓ oi ⊢l:vl e →→ v, 71 tΓ oi ⊢ oi e →→ tuoi, 79 tΓ i ⊢ i e →→ tui , 122 tΓ im ⊢ im e →→ v im, 148 tΓ c ⊢ c e →→ tuc , 150 tΓ a ⊢ a e →→ tua , 177 Relation d’ordre ⊆c , 184 ⊆i , 161 ⊆im, 161 Suppression des t-dépendances ↑ oi toi(tΓ oi), 81 ↑ oi toi(tuoi), 81 ↑ i ti(tΓ i ), 124 ↑ i ti(tui ), 124 ↑ a ta(tΓ a ), 179 ↑ a ta(tua ), 179 Valeur de référence ↑toi(tΓ oi), 67 ↑oi(Γoi), 67 ↑toi(tuoi), 66 ↑oi(u oi), 67 ↑oi(v oi), 67 234Vincent BENAYOUN Analyse de dépendances ML pour les évaluateurs de logiciels critiques Résumé : Les logiciels critiques nécessitent l’obtention d’une évaluation de conformité aux normes en vigueur avant leur mise en service. Cette évaluation est obtenue après un long travail d’analyse effectué par les évaluateurs de logiciels critiques. Ces derniers peuvent être aidés par des outils utilisés de manière interactive pour construire des modèles, en faisant appel à des analyses de flots d’information. Des outils comme SPARKAda existent pour des sous-ensembles du langage Ada utilisés pour le développement de logiciels critiques. Cependant, des langages émergents comme ceux de la famille ML ne disposent pas de tels outils adaptés. La construction d’outils similaires pour les langages ML demande une attention particulière sur certaines spécificités comme les fonctions d’ordre supérieur ou le filtrage par motifs. Ce travail présente une analyse de flot d’information pour de tels langages, spécialement conçue pour répondre aux besoins des évaluateurs. Cette analyse statique prend la forme d’une interprétation abstraite de la sémantique opérationnelle préalablement enrichie par des informations de dépendances. Elle est prouvée correcte vis-à-vis d’une définition formelle de la notion de dépendance, à l’aide de l’assistant à la preuve Coq. Ce travail constitue une base théorique solide utilisable pour construire un outil efficace pour l’analyse de tolérance aux pannes. Mots clés : analyse de dépendances, logiciels critiques, langages fonctionnels, Coq, preuve de correction, analyse statique, interprétation abstraite Abstract : Critical software needs to obtain an assessment before commissioning in order to ensure compliance to standards. This assessment is given after a long task of software analysis performed by assessors. They may be helped by tools, used interactively, to build models using information-flow analysis. Tools like SPARK-Ada exist for Ada subsets used for critical software. But some emergent languages such as those of the ML family lack such adapted tools. Providing similar tools for ML languages requires special attention on specific features such as higher-order functions and pattern-matching. This work presents an information-flow analysis for such a language specifically designed according to the needs of assessors. This analysis is built as an abstract interpretation of the operational semantics enriched with dependency information. It is proved correct according to a formal definition of the notion of dependency using the Coq proof assistant. This work gives a strong theoretical basis for building an efficient tool for fault tolerance analysis. Keywords : dependency analysis, critical software, functional languages, Coq, proof of correctness, static analysis, abstract interpretation Scénarisation d’environnements virtuels. Vers un ´equilibre entre contrˆole, coh´erence et adaptabilit´e. Camille Barot To cite this version: Camille Barot. Sc´enarisation d’environnements virtuels. Vers un ´equilibre entre contrˆole, coh´erence et adaptabilit´e.. Artificial Intelligence. Universit´e de Technologie de Compi`egne, 2014. French. HAL Id: tel-00980537 https://tel.archives-ouvertes.fr/tel-00980537v2 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.Thèse pour l’obtention du grade de Docteur de l’Université de Technologie de Compiègne Spécialité : Technologies de l’Information et des Systèmes Scénarisation d’environnements virtuels. Vers un équilibre entre contrôle, cohérence et adaptabilité. par Camille Barot Soutenue le 24 février 2014 devant un jury composé de : M. Ronan CHAMPAGNAT Maître de Conférences (HDR) Université de la Rochelle Rapporteur M. Stéphane DONIKIAN Directeur de Recherche (HDR) INRIA Rennes-Bretagne Rapporteur M. Stacy MARSELLA Professor Northeastern University Examinateur Mme Indira MOUTTAPA-THOUVENIN Enseignant-Chercheur (HDR) Université de Technologie de Compiègne Examinatrice M. Nicolas SZILAS Maître d’Enseignement et de Recherche Université de Genève Examinateur M. Dominique LENNE Professeur Université de Technologie de Compiègne Directeur Mme Domitile LOURDEAUX Maître de Conférences (HDR) Université de Technologie de Compiègne Directrice2Résumé Ces travaux traitent de la scénarisation d’environnements virtuels, définie comme la spécification des déroulements possibles ou souhaitables d’une simulation, et la mise en place de mécanismes permettant de contrôler son déroulement effectif de manière dynamique. Nous visons pour cette scénarisation un ensemble d’objectifs, souvent considérés comme contradictoires : la liberté et la capacité d’action de l’utilisateur, l’ampleur, le caractère dynamique et l’efficacité du contrôle exercé sur le scénario, la cohérence des comportements présentés et l’adaptabilité du système, nécessaire pour la variabilité des scénarios. Nous proposons SELDON, un modèle basé sur le contrôle centralisé et indirect d’une simulation émergente à partir de modèles du contenu scénaristique. L’environnement est peuplé de personnages virtuels autonomes et l’utilisateur y est libre de ses actions. La scénarisation est réalisée en deux étapes : des objectifs dynamiques sont déterminés à partir de l’activité de l’utilisateur, puis un scénario est généré en fonction de ces objectifs et exécuté au travers d’ajustements sur la simulation. Le moteur DIRECTOR permet de générer et de réaliser ce scénario. DIRECTOR utilise les modèles qui sous-tendent la simulation pour prédire son évolution, et guide cette évolution au travers d’un ensemble d’ajustements indirects, qui influencent les réactions des systèmes techniques et les prises de décision des personnages. Il utilise un moteur de planification pour générer des scénarios composés d’étapes de prédiction, dont il suit la réalisation dans la simulation, et d’ajustements, qu’il dé- clenche. Les objectifs scénaristiques pris en compte sont à la fois dynamiques, au travers de situations prescrites et proscrites et de contraintes sur les propriétés globales du scénario, et statiques, sous la forme d’espaces de scénario. Le contenu scénaristique et les objectifs scénaristiques statiques sont représentés à l’aide de l’ensemble de langages que nous avons proposé : DOMAIN-DL, ACTIVITY-DL et CAUSALITY-DL. Ces contributions permettent d’allier la réactivité et la variabilité permises par des simulations émergentes et la pertinence des scénarios offerte par les systèmes basés sur de la planification. 34Abstract Orchestration of virtual environments: Balancing control, coherence and adaptability. This work addresses the orchestration of virtual environments, defined as the specification of possible or wanted unfoldings of events in a simulation and the implementation of control mechanisms over the actual unfolding. We aim at a set of objectives often considered contradictory: userfreedom/agency, range, dynamicity and efficiency of control over the scenario, behavioural coherence, and system adaptability, which is essential for scenario variability. We propose SELDON, a model based on centralised and indirect control of an emergent simulation. Scenario content is represented by domain and activity models in the DOMAIN-DL and ACTIVITY-DL languages. The virtual environement is populated by autonomous characters, and the user’s choices of actions are unconstrained. Orchestration is carried out in two steps: first, a set of dynamic objectives is determined from the user’s profile and activity, then a scenario is generated from these objectives and executed through adjustements on the simulation. The DIRECTOR engine performs scenario generation and execution. DIRECTOR uses the simulation’s models to predict its evolution and guide it through a set of indirect adjustements that influence technical systems’ reactions and characters’ decisions. It uses planning to generate scenarios made up of prediction steps that DIRECTOR monitors in the simulation and adjustements that it triggers in the virtual environment. Scenario objectives can be defined dynamically through prescribed/proscribed situations and constraints on global scenario properties or statically as a space of scenarios of interest represented in the CAUSALITY-DL language. 56Remerciements Je tiens avant tout à exprimer ma profonde gratitude à Domitile Lourdeaux, qui m’a encadrée, conseillée et soutenue tout au long de ce doctorat. Merci, Domitile, d’avoir toujours cru en moi et de m’avoir encouragée à viser plus haut. Merci aussi de m’avoir permis de trouver mes marques et de m’intégrer dans une approche existante sans jamais m’imposer un point de vue, de m’avoir laissé poursuivre mes idées même quand tu n’y croyais pas au départ. Merci enfin de m’avoir montré que l’on pouvait vraiment s’éclater en faisant de la recherche. Tu as fait de ton équipe une vraie famille, avec son arbre généalogique accroché au mur de ton bureau, et je suis heureuse d’en faire partie. Je suis fière du travail accompli à tes côtés. Je remercie également Dominique Lenne d’avoir co-encadré cette thèse. Merci de m’avoir fait confiance, et de m’avoir poussée aussi, durant la thèse certes mais également bien avant puisque c’est toi qui, dès IA01, m’a incitée à envisager la voie de la recherche. Je souhaite remercier Ronan Champagnat et Stéphane Donikian d’avoir accepté de rapporter ma thèse, et je remercie Nicolas Szilas d’avoir accepté d’en être examinateur. I thank (in English!) Stacy Marsella, for not only accepting to suffer the slings and arrows of visioconference to attend my defense, but also for the faith he put in me during our short time working together. Je remercie de tout cœur Indira Mouttapa Thouvenin, qui a accepté de présider mon jury de thèse, mais m’a surtout soutenue et encouragée depuis plusieurs années. Merci à tous pour vos critiques, vos remarques et vos questions qui ont fait de ma soutenance un moment d’échanges passionnants. Cette thèse n’aurait pas pu voir le jour sans le soutien de la région Picardie et du FEDER au projet ARAKIS, et je les en remercie. De même, je remercie toutes les personnes impliquées dans ce projet, mais aussi dans les projets V3S et NIKITA auxquels j’ai pu participer, en particulier les groupes du CEA, du LATI et d’Emissive. Merci donc à Emmanuel Guerriero, Fabien Barati et Antoine Ferrieux avec qui j’ai été ravie de travailler avant comme pendant la thèse. Un grand merci également à Jean-Marie Burkhardt, avec qui les échanges ont été particulièrement enrichissants. Enfin, je suis très reconnaissante à Fabrice Camus d’être venu avec moi affronter les dangers des dépôts pétroliers pour réaliser les analyses terrain, et de m’avoir encouragée sans relâche pendant toute la durée de cette thèse. Mes pensées vont à l’équipe HUMANS, et à tous ceux qui ont pu graviter autour de celle-ci à un moment où à un autre : Margot Lhommet, Pierre-Yves Gicquel, Vincent Lanquepin, Kahina Amokrane, Antoine Vincent, Dorine Dufour, Hazaël Jones, Jocelyn Thiery, Lydie Edward, Lucile Callebert, Juliette Lemaitre, Loïc Fricoteaux, Jérôme Olive, Alistair Jones, Kevin Wagrez, Thibaut Arribe... mais aussi la bande de Reviatech — Romain Lelong, Mehdi Sbaouni et Morgan Fraslin — et celle des déjeuners à l’IMI — Benjamin Diemert et Thomas Bottini. On a vécu de grands moments, et vous avez été bien plus que des collègues à mes yeux. J’espère que les traditions des journées à thèmes du mardi et des bières au Shamrock qui font rater le train perdureront, et que de nouvelles viendront s’y ajouter. Kevin Carpentier, mon acolyte de toujours, mérite son paragraphe rien qu’à lui : tu as été un binôme fantastique durant toutes ces années, et ça va beaucoup me manquer de travailler avec toi. J’espère qu’on y remédiera très vite et qu’on finira par ouvrir ensemble un grand parc d’attractions autour du storytelling, de la génération procédurale et de la synesthésie. Je remercie également le laboratoire Heudiasyc et l’équipe ICI pour leur accueil, ainsi que les étudiants de l’UTC que j’ai pu encadrer autour de différents projets pour l’équipe HUMANS et qui ont été d’une aide précieuse : Barthélémy Arribe, Yacine Badiss, Clément Boissière, Marion Cayla, Jonathan Denonain, Pierre-Henri Fricot, Thibaud Huet, Ronan Kervella, Pierre-Alexandre Kofron, 7Julien Mazars, Aloïs Nolin, Vincent Palancher, Thierry Tang... sans oublier Diane Wakim bien sûr ! Je voudrais aussi saluer le travail du personnel de l’UTC, en particulier Nathalie Alexandre et Marion Kaczkowski qui m’ont sauvé la mise plus d’une fois. Merci à mes amis, la MDB et tous les autres, d’avoir toujours su me changer les idées et me faire relativiser. Merci en particulier à Elise, qui est mon rayon de soleil, et qui maintenant va se sentir obligée de lire cette thèse en entier. Enfin, merci à mes parents, mon frère, ma sœur, ainsi qu’à toute ma famille, de m’avoir supportée (dans les deux sens du terme !) dans des moments qui ont été très difficiles pour moi comme pour eux. C’est grâce à leur soutien inconditionnel que je peux présenter aujourd’hui ce travail. 8Table des matières 1 Introduction 15 1.1 Scénarisation et environnements virtuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.1 Déroulement des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.2 Contenu des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.3.3 Conception des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.3.4 Bilan sur les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.6 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.6.1 Modèle pour la scénarisation d’environnements virtuels – SELDON . . . . . . . . 26 1.6.2 Moteur de planification et réalisation de scénarios prédictifs – DIRECTOR . . . . 27 1.6.3 Méta-modèle de la causalité – CAUSALITY-DL . . . . . . . . . . . . . . . . . . . . . 29 1.6.4 Autres contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.7 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.7.1 Plateforme HUMANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.7.2 Cas d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1.8 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 I Etat de l’art 37 2 Scénarisation dans les environnements virtuels 39 2.1 Classifications des approches pour la scénarisation . . . . . . . . . . . . . . . . . . . . . . 40 2.1.1 Approches centrées sur le scénario ou sur les personnages . . . . . . . . . . . . . 40 2.1.2 Scénarisation intrinsèque ou extrinsèque . . . . . . . . . . . . . . . . . . . . . . . . 41 2.1.3 Scénario prédéfini ou généré dynamiquement . . . . . . . . . . . . . . . . . . . . 41 2.2 Simulations pures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.2.1 CS WAVE et VTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.2.2 VRaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.2.3 I-Storytelling et EmoEmma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.2.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3 Scénarios prédéfinis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.1 EMSAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.2 Generic Virtual Trainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.4 Graphes multilinéaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.4.1 PAPOUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.4.2 ICT Leaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.4.3 Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.4.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 9TABLE DES MATIÈRES TABLE DES MATIÈRES 2.5 Scénarios dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.5.1 IDTension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.5.2 Mimesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.5.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.6 Personnages partiellement autonomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.6.1 MRE et FearNot ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.6.2 ISAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.6.3 IN-TALE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.6.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.7 Contrôle de personnages autonomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.7.1 Initial State Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.7.2 Virtual Storyteller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.7.3 Thespian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.7.4 Planification sociale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.7.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.8 Bilan global et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3 Représentation des connaissances pour la scénarisation 63 3.1 Représentation de contenu scénaristique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.1.1 Représentation du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.1.2 Représentation de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.1.3 Représentation des événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.1.4 Bilan et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.2 Représentation d’objectifs scénaristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.1 Objectifs scénaristiques de bas niveau . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.2 Objectifs scénaristiques de haut niveau . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.2.3 Bilan et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.3 Représentation des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.3.1 Modèles de compréhension d’histoires . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.3.2 Modèles de scénarios pédagogiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 3.3.3 Modèles d’analyses de risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.3.4 Automates finis et graphes orientés acycliques . . . . . . . . . . . . . . . . . . . . 95 3.3.5 Plans et points clés partiellement ordonnés . . . . . . . . . . . . . . . . . . . . . . 97 3.3.6 Bilan et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 II Contributions 103 4 SELDON – Modèle pour la scénarisation d’environnements virtuels 105 4.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.2 Vers quoi scénariser – le moteur TAILOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.3 Comment scénariser – le moteur DIRECTOR . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.4 A partir de quoi scénariser – les langages HUMANS-DL . . . . . . . . . . . . . . . . . . . 109 5 Représentation du contenu scénaristique 111 5.1 DOMAIN-DL – Représentation du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.1.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.1.2 Description du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.1.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.2 ACTIVITY-DL – Représentation de l’activité . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.2.2 Description du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.2.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 10TABLE DES MATIÈRES TABLE DES MATIÈRES 6 DIRECTOR – Moteur de planification et réalisation de scénarios prédictifs 133 6.1 Ajustements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 6.1.1 Happenings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 6.1.2 Late commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.1.3 Contraintes d’occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6.2 Représentation des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.2.1 Plan partiellement ordonné . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.2.2 Opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.3 Particularité de la génération de plans prédictifs . . . . . . . . . . . . . . . . . . . . . . . . 142 6.4 Génération d’opérateurs de prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 6.4.1 Génération des opérateurs d’action . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 6.4.2 Génération des opérateurs de comportement . . . . . . . . . . . . . . . . . . . . . 151 6.5 Processus de génération, suivi et exécution du scénario . . . . . . . . . . . . . . . . . . . 155 6.5.1 Génération du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.5.2 Suivi et exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.5.3 Replanification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 7 Représentation et prise en compte des objectifs scénaristiques 163 7.1 CAUSALITY-DL – Représentation d’espaces de scénarios d’intérêt . . . . . . . . . . . . . 164 7.1.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 7.1.2 Description du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 7.1.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 7.2 Trames scénaristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 7.3 Situations prescrites et proscrites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 7.4 Propriétés des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 7.4.1 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 7.4.2 Gravité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 7.4.3 Crédibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 7.5 Prise en compte des objectifs scénaristiques par DIRECTOR . . . . . . . . . . . . . . . . 177 7.5.1 Sélection de la trame scénaristique . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 7.5.2 Instanciation de la trame scénaristique . . . . . . . . . . . . . . . . . . . . . . . . . 178 7.5.3 Complétion du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 7.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 III Implémentation et résultats 183 8 Implémentation 185 8.1 Choix liés à la planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 8.1.1 Représentation en PDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 8.1.2 Choix du moteur de planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 8.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 8.2.1 Génération du domaine PDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 8.2.2 Génération du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 8.2.3 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 8.2.4 Plateforme HUMANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 9 Validation 193 9.1 Evaluation informatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 9.1.1 Eléments comparés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 9.1.2 Influence du moteur sur les plans générés . . . . . . . . . . . . . . . . . . . . . . . 196 9.1.3 Validité des plans générés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 11TABLE DES MATIÈRES TABLE DES MATIÈRES 9.1.4 Temps de génération des plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 9.1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 9.2 Retours d’usage sur la conception des modèles . . . . . . . . . . . . . . . . . . . . . . . . 201 9.2.1 DOMAIN-DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 9.2.2 ACTIVITY-DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 9.3 Pistes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.3.1 Efficacité de la prédiction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.3.2 Efficacité du contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.3.3 Résilience du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.3.4 Variabilité des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.3.5 Cohérence des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 IV Discussion et conclusion 205 10 Discussion 207 10.1 Points forts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 10.1.1 Cohérence des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 10.1.2 Liberté et capacité d’action de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . 208 10.1.3 Degrés de contrôle des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 10.1.4 Variabilité et pertinence des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . 209 10.1.5 Adaptabilité du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 10.2 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 10.2.1 Temps de planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 10.2.2 Replanification et instanciation des trames scénaristiques . . . . . . . . . . . . . 211 10.2.3 Prise en compte des objectifs lors de la planification . . . . . . . . . . . . . . . . . 211 10.2.4 Génération des opérateurs de prédiction . . . . . . . . . . . . . . . . . . . . . . . . 212 10.2.5 Dépendance des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 10.2.6 Cas où la planification est impossible . . . . . . . . . . . . . . . . . . . . . . . . . . 213 10.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 10.3.1 Représentation des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 10.3.2 Modèle de la cognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 10.3.3 Modélisation de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 10.3.4 Discours et récit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 10.3.5 Calcul de l’intérêt narratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 11 Conclusion 219 V Annexes 221 A Glossaire 223 B Description des modules de la plateforme HUMANS 225 B.1 HUMANS-DL - Représentation des connaissances . . . . . . . . . . . . . . . . . . . . . . 226 B.2 WORLD MANAGER - Gestion de l’état du monde . . . . . . . . . . . . . . . . . . . . . . . 227 B.3 REPLICANTS - Personnages virtuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 B.4 MONITOR - Suivi de l’apprenant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 B.5 TAILOR - Génération de situations d’apprentissage . . . . . . . . . . . . . . . . . . . . . . 229 C Diagrammes UML 231 D Algorithmes 233 12TABLE DES MATIÈRES TABLE DES MATIÈRES E Exemple “Gas Station” 235 E.1 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 E.2 Scénarios générés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Table des figures 251 Liste des tableaux 255 Publications 257 Bibliographie 259 13TABLE DES MATIÈRES TABLE DES MATIÈRES 14Chapitre 1 Introduction Sommaire 1.1 Scénarisation et environnements virtuels . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.1 Déroulement des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Liberté d’action de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Possibilités de contrôle du scénario . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Caractère dynamique du contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Résilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.3.2 Contenu des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Validité écologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Explicabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Variabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.3.3 Conception des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Passage à l’échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Maintenabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Réutilisabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.4 Bilan sur les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.6 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1.6.1 Modèle pour la scénarisation d’environnements virtuels – SELDON . . . . . . . 26 1.6.2 Moteur de planification et réalisation de scénarios prédictifs – DIRECTOR . . . 27 1.6.3 Méta-modèle de la causalité – CAUSALITY-DL . . . . . . . . . . . . . . . . . . . . 29 1.6.4 Autres contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Méta-modèle de l’activité – ACTIVITY-DL . . . . . . . . . . . . . . . . . . . . . . 29 Méta-modèle du domaine – DOMAIN-DL . . . . . . . . . . . . . . . . . . . . . . 30 1.7 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.7.1 Plateforme HUMANS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 1.7.2 Cas d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 ARAKIS – Formation des opérateurs de dépôts pétroliers . . . . . . . . . . . . . 32 SimADVF – Formation des assistantes de vie de famille . . . . . . . . . . . . . . 33 NIKITA – Formation des assembleurs-monteurs en aéronautique . . . . . . . . 34 1.8 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 151.1. SCÉNARISATION ET ENVIRONNEMENTS VIRTUELS CHAPITRE 1. INTRODUCTION Les travaux présentés dans cette thèse traitent de la scénarisation d’environnements virtuels. Leur objectif est de fournir un modèle pour la scénarisation dynamique de ces environnements, qui permette de générer et de mettre en place des scénarios pertinents, en particulier dans le cas de simulations complexes, le tout en conservant la cohérence des comportements présentés. 1.1 Scénarisation et environnements virtuels Ces travaux s’inscrivent dans le contexte des environnements virtuels : des systèmes interactifs permettant à un ou plusieurs utilisateurs d’interagir avec un monde artificiel, généralement en trois dimensions, par le biais d’un ensemble de techniques informatiques couvrant une ou plusieurs modalités sensorielles [Burkhardt et al., 2003]. Plutôt que de considérer ces environnements sous l’angle des périphériques utilisés et des différents degrés d’interaction et d’immersion induits sur le plan sensori-moteur, nous nous intéresserons aux événements ayant lieu dans le monde artificiel et à l’activité de l’utilisateur en termes cognitifs, en suivant la définition de la réalité virtuelle donnée par [Fuchs et al., 2006] : “ La finalité de la réalité virtuelle est de permettre à une personne (ou à plusieurs) une activité sensori-motrice et cognitive dans un monde artificiel, créé numériquement, qui peut être imaginaire, symbolique ou une simulation de certains aspects du monde réel. La scénarisation est un processus qui vise à spécifier les événements devant se produire dans un ” cadre donné, qui peut être celui d’un film, d’un jeu vidéo, d’une session d’apprentissage, etc. Or, selon le cadre considéré, le terme de scénarisation, ainsi que la notion de scénario lui-même, ne revêtent pas le même sens. Dans le domaine cinématographique, un scénario est un document écrit décrivant les différentes scènes d’un film. On distingue deux types de scénarios : le script, ou screenplay, décrit l’enchainement des événements (actions, dialogues...) — “what to shoot", tandis que le découpage technique, ou shooting script, inclut également des indications sur la manière de mettre en scène et de porter ces événements à l’écran (découpage en séquences et plans, points de vue...) — “how to shoot it" [Van Rijsselbergen et al., 2009]. La scénarisation désigne alors le processus d’écriture de ce scénario. De même, dans le domaine de l’apprentissage, la scénarisation est souvent considérée comme une activité de modélisation (voir par exemple [Ouraiba, 2012]). Elle consiste alors en la spécification, de manière prescriptive, du déroulement futur d’une activité pédagogique, en décrivant à la fois les intentions des enseignants et les situations d’apprentissage prévues pour leurs enseignements à l’aide d’un langage de scénarisation pédagogique [Abedmouleh, 2012]. Pour Pernin et Lejeune [Pernin and Lejeune, 2004], la spécification du scénario n’est au contraire que la première étape de la scénarisation. Ils distinguent ainsi quatre phases dans le cycle de vie d’un scénario d’apprentissage : – la conception, qui consiste à spécifier l’activité prescrite dans le langage de scénarisation ; – l’opérationnalisation, durant laquelle ces spécifications sont transformées en composants exé- cutables sur des plateformes informatiques ; – l’exploitation, qui consiste à “jouer" le scénario, et durant laquelle les acteurs (apprenants et tuteurs) doivent pouvoir observer et ajuster les situations mises en place. – le retour d’usage, où les résultats obtenus lors de la phase d’exploitation sont évalués Si de nombreux travaux sur les Environnements Informatiques pour l’Apprentissage Humain (EIAH) et Environnements Virtuels pour l’Apprentissage Humain (EVAH) se concentrent sur la phase de conception des scénarios et sur les langages de scénarisation [Martel et al., 2007] [Laforcade et al., 2007], la phase d’exploitation revêt une importance capitale : à partir du moment où on utilise l’outil 16CHAPITRE 1. INTRODUCTION 1.1. SCÉNARISATION ET ENVIRONNEMENTS VIRTUELS informatique, l’exécution, la supervision et la régulation du scénario ne sont plus intégralement le fait du formateur humain, mais relèvent en partie de l’outil lui-même 1 . Ainsi, dès lors que l’on se place dans un contexte interactif, la scénarisation ne consiste plus uniquement en la modélisation d’un scénario, mais également en la mise en place des mécanismes nécessaires à la réalisation de ce scénario. Selon les travaux, cette partie dynamique du processus de scé- narisation sera désignée par les termes de pilotage [Delmas, 2009], drama management [Mateas and Stern, 2005], directorial control [Si et al., 2009], ou encore story mediation [Magerko, 2007]. C’est autour de cette problématique que se place le domaine de la narration interactive (interactive storytelling). La narration interactive permet aux utilisateurs de participer activement à une histoire, soit de manière intradiégétique, en incarnant l’un des personnages, soit de manière extradiégétique, en exerçant un contrôle sur le déroulement des événements [Si, 2010]. Les travaux effectués dans le domaine de la narration interactive visent à trouver un équilibre entre l’intérêt narratif et le respect des intentions de l’auteur d’un côté, et la liberté d’action du ou des utilisateurs de l’autre [Magerko, 2005]. Lorsqu’il s’agit de concevoir un environnement virtuel ou un système de narration interactive, il existe deux approches : la scénarisation peut être considérée comme partie intégrante du processus de conception, ou bien elle peut être vue comme une étape supplémentaire de cadrage d’un environnement existant. Dans le premier cas, la scénarisation va consister à définir l’ensemble des objets de l’environnement virtuel, leurs règles de fonctionnement, les actions possibles de la part de l’utilisateur et des personnages virtuels, le comportement de ces derniers, etc. Les scénarios peuvent être définis de manière plus ou moins explicite, allant du script exhaustif à la modélisation des comportements individuels, les scénarios effectifs émergeant alors des interactions entre le ou les utilisateurs et le monde virtuel. L’environnement virtuel scénarisé est ici vu comme un tout. C’est le cas par exemple dans [Mateas and Stern, 2005] ou [Cavazza et al., 2002]. Dans le deuxième cas, la scénarisation va consister à réduire l’espace des scénarios possibles, en sélectionnant, ordonnant ou priorisant des sous-ensembles d’événements en vue d’une utilisation particulière de l’environnement virtuel. Ainsi, pour N. Mollet, “la scénarisation consiste à utiliser l’environnement et agencer les interactions afin de réaliser une tâche particulière" [Mollet, 2005]. La modélisation du scénario est alors séparée en deux parties : la spécification du contenu scénaristique d’un côté, et celle des objectifs scénaristiques de l’autre. Si l’on reprend la métaphore du jeu de rôle (non numérique), souvent utilisée en narration interactive (voir par exemple [Aylett et al., 2011], [Delmas, 2009]), on peut identifier trois composantes principales au sein du jeu avec lequel les joueurs interagissent : – le corpus de règles qui décrit l’univers et les mécanismes du jeu, – la trame préparée en amont par le meneur de jeu (game master), qui peut être plus ou moins détaillée et plus ou moins dirigiste, – les interventions du meneur de jeu, qui décrit la situation initiale, interprète et applique les règles du jeu, fait intervenir des personnages non-joueurs, déclenche des événements et met en scène le tout. L’activité du meneur de jeu est assimilable au processus de pilotage de l’environnement virtuel, tandis que le corpus de règles correspond au contenu scénaristique et la trame aux objectifs scénaristiques. On constate ainsi que, pour un même contenu, de nombreux scénarios différents pourront être créés en fonction des objectifs définis, et que la spécification du contenu et celle des objectifs scénaristiques ne sont pas forcément réalisées par les mêmes personnes (ainsi le créateur du jeu de 1. Il est nécessaire de distinguer ici la scénarisation des activités pédagogiques et celle des situations d’apprentissage (parfois appelée orchestration [Luengo, 2009]). La première va situer l’utilisation de l’environnement virtuel comme outil de formation dans le cadre plus large d’un scénario pédagogique, au même titre que d’autres activités pédagogiques comme des cours magistraux. Le passage d’une activité à une autre peut alors relever de la responsabilité du formateur, ou être déclenché automatiquement par un système informatique. La seconde va poser des contraintes sur le déroulement de l’activité même de l’utilisation de l’environnement virtuel, contraintes qui devront être appliquées sur la simulation par un système de scénarisation, afin que le scénario se déroule quelles que soient les actions de l’apprenant. 171.2. MOTIVATIONS CHAPITRE 1. INTRODUCTION rôle définit le système de règles, et peut également fournir des trames pré-écrites, mais le meneur de jeu peut choisir d’utiliser une trame de sa propre invention). On retrouve cette même approche dans de nombreux environnements virtuels de type simulateurs, utilisés pour la formation : ces environnements sont construits autour d’un noyau générique, qui contient les règles de fonctionnement de la simulation (ex : le fonctionnement d’une automobile, le code de la route, etc.) auquel vient s’ajouter une couche d’instanciation pour un objectif pédagogique donné (ex : “conduite sur autoroute avec un trafic dense”). Les objectifs scénaristiques peuvent ainsi être spécifiés de manière très large en donnant simplement les conditions initiales d’une simulation. Le terme de “scénario" est alors utilisé pour désigner ces conditions initiales, par exemple la disposition de l’environnement virtuel (settings) dans [Hullett and Mateas, 2009]. Le “scénario" en tant qu’objectif scénaristique peut, selon les travaux, être modélisé à différents niveaux de granularité, et de manière plus ou moins explicite : contraintes sur les conditions initiales [Hullett and Mateas, 2009], ensemble de séquences d’événements exemplaires [Si, 2010], contraintes d’ordonnancement sur des événements clés [Porteous and Cavazza, 2009], contraintes de haut niveau sur des fonctions d’évaluation du scénario [Weyhrauch, 1997], etc. Certains parlent au contraire du “scénario” d’un environnement virtuel pour désigner le domaine d’application [Szilas, 2007]. D’autres utilisent ce même terme pour parler d’une séquence d’événements particulière, instanciée lors d’une session d’interaction [Champagnat et al., 2005] — il peut alors s’agir d’une séquence prescrite ou effective. C’est cette acception que nous utiliserons dans le reste de ce mémoire, et nous parlerons alors d’“espace de scénarios" lorsqu’il s’agira de se référer à un ensemble de possibles. Nous adopterons ainsi dans cette thèse les définitions suivantes : Scénarisation La scénarisation est un processus comprenant à la fois la spécification du ou des déroulements possibles ou souhaitables de la simulation, et le contrôle (exécution et/ou suivi et correction) du déroulement des événements en temps-réel. Système de scénarisation Un système de scénarisation est composé d’un ou plusieurs langages de scénarisation, permettant de modéliser le contenu scénaristique et/ou les objectifs scénaristiques, et d’un moteur de scénarisation permettant de gérer de manière dynamique la réalisation du scénario. 1.2 Motivations La scénarisation d’environnements virtuels a des applications dans de nombreux domaines, parmi lesquels on peut citer la formation [Burkhardt et al., 2006], l’aide à la décision [Bourdot et al., 2006], la thérapie [Klinger et al., 2006] et le divertissement, notamment via le domaine de la narration interactive [Bates, 1992]. Dans le cadre de ce mémoire, nous nous intéresserons surtout aux deux premiers. Les Environnements Virtuels pour l’Apprentissage Humain (EVAH) constituent en effet une des applications majeures de la réalité virtuelle, se démocratisant de plus en plus depuis les premiers développements remontant aux années 90. Les avantages de la réalité virtuelle pour la formation sont nombreux [Lourdeaux, 2001] : non seulement l’utilisation d’un environnement virtuel permet de se dé- tacher des contraintes pouvant exister dans les formations en conditions réelles (dangerosité, contraintes d’accessibilité au site ou au matériel, coût, etc.), mais elle permet également d’enrichir ces situations à des fins pédagogiques, via par exemple des fonctions de rejeu ou de segmentation de l’apprentissage. Ces environnements concernent à présent de nombreux domaines d’application, que ce soit au niveau 18CHAPITRE 1. INTRODUCTION 1.2. MOTIVATIONS de la formation professionnelle — formation au geste technique [Da Dalto, 2004], aux procédures de maintenance [Gerbaud, 2008] ou de conduite de machineries [Crison et al., 2005] [Rickel and Johnson, 1998], formation à la maîtrise des risques [Fabre et al., 2006] [Barot et al., 2013] [Querrec and Chevaillier, 2001], etc. — ou bien de l’éducation [Mikropoulos and Natsis, 2011] — compréhension de concepts scientifiques [Dede et al., 1996] [Windschitl and Winn, 2000], travaux pratiques virtuels [Baudouin, 2007], apprentissage des langues [Schlemminger, 2013], etc. Ils peuvent être utilisés dans différentes configurations techniques et avec différentes stratégies pédagogiques : présence ou non d’un formateur, environnement mono ou multi-apprenant, apprenant spectateur ou acteur de l’interaction avec l’environnement virtuel, etc. [Burkhardt et al., 2005]. Les environnements virtuels sont également utilisés pour des applications d’aide à la décision, que ce soit dans l’industrie [Bourdot et al., 2006] ou dans le domaine médical [Rizzo et al., 2012], mais aussi pour des applications de planification urbaine [Roupé, 2013], de gestion des flux d’immigration [Hedge, 2011], etc. La simulation informatique d’un système socio-technique peut en effet permettre au décideur d’appréhender rapidement les conséquences induites par ses choix, lui donnant une meilleure visibilité, en particulier lorsque les décisions doivent être prises dans l’urgence et dans un contexte flou [Castagna et al., 2001]. De tels simulateurs sont aussi utilisés en amont comme outils d’aide à la décision pour la conception de systèmes [Robotham and Shao, 2012], ou encore pour la maîtrise des risques, afin de permettre de détecter les facteurs d’accidents possibles [Gounelle et al., 2007]. Pour de nombreux environnements, dont la visée est de simuler un système technique dans une situation précise et cadrée, un faible niveau de scénarisation est suffisant. Les concepteurs définissent dans ce cas les règles d’évolution des systèmes simulés, sans chercher à exercer de contrôle supplémentaire sur le déroulement des événements. Ces environnements peuvent servir de support d’apprentissage — l’apprenant expérimentant avec la simulation à la manière d’un chercheur scientifique [De Vries and Baille, 2006] — ou d’entrainement, comme c’est le cas pour de nombreux simulateurs de conduite dits “pleine échelle” [Joab et al., 2006]. D’autre part, certains environnements font l’objet d’une scénarisation pédagogique réalisée au travers de rétroactions extradiégétiques, c’est à dire qui ne correspondent pas à des événements du domaine simulé (elles se situent ainsi en dehors de la diégèse). Ces rétroactions peuvent apporter des modifi- cations à l’environnement virtuel au sein d’une même situation d’apprentissage, sous la forme d’assistances [Lourdeaux, 2001] : enrichissement de l’environnement via l’ajout de symboles visuels ou sonores, restriction des déplacements ou manipulations de l’utilisateur, etc. Elles peuvent également permettre de naviguer dans le scénario pédagogique en passant d’une situation d’apprentissage à une autre [Luengo, 2009] ; la simulation est alors arrêtée et relancée à partir d’une situation différente. Cependant, dans le domaine de la formation et de l’aide à la décision, peu de travaux s’intéressent à la scénarisation des environnements virtuels sur le plan intradiégétique. Ce type de scénarisation consiste à contrôler le déroulement des événements au sein même de la simulation, sans couper l’immersion de l’utilisateur dans l’environnement virtuel. La visée ici n’est pas de remplacer les systèmes de scénarisation pédagogique qui ont fait leurs preuves pour la formation initiale et l’entrainement d’apprenants, mais de se positionner de manière complémentaire, en adressant d’autres besoins et d’autres types de formation. Ainsi, dans le cadre de la formation continue d’apprenants experts, ces derniers doivent être confrontés à des scénarios particuliers, plus rares, mettant en jeu des situations de travail dégradées. La scénarisation peut alors permettre d’amener à la réalisation d’un événement précis, comme le dé- clenchement d’un accident donné pour une formation à la maîtrise des risques. Pour des applications d’analyse de risque, cela permettrait ainsi de rejouer des scénarios accidentels, ou de déterminer les facteurs de risque d’un accident donné sans avoir besoin de procéder à des ajustements progressifs des conditions initiales de la simulation (voir par exemple [Bosse and Mogles, 2013]). De même, alors que les situations de travail se complexifient, il devient nécessaire de former non seulement aux compétences techniques, mais également aux compétences non-techniques, comme le travail en groupe ou la gestion du stress. Les environnements virtuels seront alors peuplés de per- 191.3. OBJECTIFS CHAPITRE 1. INTRODUCTION sonnages virtuels, dont le comportement devra lui-aussi être pris en compte par le système de scé- narisation : les personnages pourraient ainsi tenter de minimiser ou de maximiser les risques liés à une procédure collaborative, aider l’apprenant quand il est en difficulté en lui donnant des conseils ou en réalisant des actions à sa place, ou au contraire le mettre en situation de stress. Cette scénarisation adaptative permettrait ainsi de contrôler le niveau de tension et de difficulté de manière à ce qu’ils restent adaptés au profil et à l’activité de l’apprenant. Elle permettrait également de motiver ce dernier par le biais d’une mise en scène, en favorisant son implication émotionnelle dans une histoire, à la manière de la narration interactive. Il serait alors possible de transposer les jeux de rôles réalisés dans le cadre des formations sur des personnages de l’environnement virtuel, évitant ainsi de devoir faire intervenir plusieurs formateurs. 1.3 Objectifs De nos motivations concernant la scénarisation d’environnements virtuels destinés à la formation ou à l’aide à la décision découlent un certain nombre d’objectifs pour notre système de scénarisation. Ces objectifs touchent à la fois aux différents degrés de liberté pour l’utilisation et le pilotage de l’environnement virtuel, au contenu et à la qualité des scénarios produits, et aux possibilités offertes pour la phase de conception de ces environnements virtuels scénarisés. 1.3.1 Déroulement des scénarios Le premier groupe d’objectifs concerne les propriétés dynamiques de notre système de scénarisation, c’est à dire à la fois l’utilisation qui sera faite par l’apprenant de l’environnement virtuel en temps-réel, et la manière dont le système de scénarisation va pouvoir diriger le scénario de l’environnement virtuel (quoi, quand et comment). Nous déterminons ainsi quatre objectifs : – liberté d’action de l’utilisateur, – degrés de contrôle du scénario, – caractère dynamique du contrôle, – résilience. Liberté d’action de l’utilisateur Pour promouvoir un apprentissage par essai-erreur, ou pour permettre de tester différents cas dans un cadre d’aide à la décision, il est nécessaire de laisser à l’utilisateur une certaine liberté d’action. Par utilisateur, nous désignons ici la personne qui est immergée dans l’environnement virtuel et joue le rôle de l’un des personnages de l’environnement — dans le cas d’un environnement virtuel pour la formation, nous considèrerons qu’il s’agit de l’apprenant — et non les hypothétiques personnes qui pourraient exercer un contrôle extérieur sur l’environnement en temps réel — par exemple, un formateur. Ainsi, laisser à l’utilisateur une certaine latitude dans le choix de ses actions peut lui permettre d’expérimenter et de comparer les conséquences des différents choix qui s’offrent à lui. Il faut cependant distinguer le sentiment de liberté d’action que peut avoir l’utilisateur et sa capacité d’action réelle, c’est à dire l’impact réel de ses décisions sur le déroulement des événements (user agency) [Thue et al., 2010]. Si la liberté d’action perçue permet d’intéresser l’utilisateur en répondant à ses désirs en termes d’interaction [Wardrip-Fruin et al., 2009], seule une réelle capacité d’action peut lui permettre d’adopter une posture expérimentale vis à vis de l’environnement virtuel. De plus, la capacité d’action affecte également l’implication de l’utilisateur dans l’environnement virtuel [Si, 2010]. 20CHAPITRE 1. INTRODUCTION 1.3. OBJECTIFS Possibilités de contrôle du scénario En plus de la capacité d’action de l’utilisateur sur le scénario (user agency), il est nécessaire de considérer également la capacité d’action du système de scénarisation lui-même (global agency). Ainsi, parmi les objectifs scénaristiques qui vont pouvoir être pris en compte par le système, il faut tout d’abord permettre de spécifier des situations à atteindre. Par situation, nous entendons ici une combinaison particulière d’états de l’environnement virtuel, pouvant être décrite à plus ou moins haut niveau, par exemple “Il y a une fuite au niveau de la vanne n°32” ou “Il y a une anomalie au niveau d’une vanne”. Pour les environnements virtuels pour l’apprentissage se situant dans un cadre d’apprentissage situé, il est considéré que la situation dans laquelle se développent les apprentissages est primordiale et que les apprentissages doivent être contextualisés. La situation est une composante intégrale de la connaissance qui se développe [Rogalski, 2004]. On va donc chercher à placer l’apprenant dans une situation d’apprentissage donnée, afin de mettre en jeu des connaissances et des compétences, et de générer ces apprentissages. A l’inverse, les situations à ne pas atteindre doivent également pouvoir être spécifiées. Cela est notamment utile dans le cas où un apprenant ne possède pas encore les ressources nécessaires pour gérer une situation, ou au contraire s’il a déjà rencontré cette situation par le passé. Enfin, il s’agit de ne pas seulement s’intéresser aux situations ponctuelles mais aussi aux propriétés plus globales du scénario. En effet, une situation d’apprentissage peut être plus large qu’une situation ponctuelle dans l’environnement virtuel et inclure une dimension temporelle : augmentation du rythme de travail ou présence d’un collaborateur récalcitrant, par exemple. Contrôler l’agencement des situations, le rythme ou encore la complexité globale du scénario permettrait ainsi de pouvoir gérer une augmentation de la difficulté et de faire disparaître progressivement les assistances offertes par l’environnement virtuel [Burkhardt, 2010]. Caractère dynamique du contrôle En parallèle du quoi contrôler, il faut aussi s’intéresser au quand, car si la définition des objectifs scénaristiques en amont permet déjà de spécifier un scénario, il peut être utile dans de nombreux cas de re-définir ces objectifs de manière dynamique, afin d’offrir un scénario qui soit pertinent par rapport au profil et à l’activité de l’utilisateur de l’environnement virtuel. On veut ainsi pouvoir adapter les objectifs scénaristiques d’une session d’utilisation à l’autre afin de prendre en compte ce qui a été réalisé précédemment par l’utilisateur : introduire de nouvelles situations, augmenter la difficulté, éviter de rejouer des scénarios déjà vus, etc. De plus, il peut s’avérer intéressant dans certain cas d’aller plus loin, en proposant une adaptation dynamique du scénario au cours d’une même session d’utilisation de l’environnement virtuel. En effet, de même que l’environnement est modifié du fait des actions de l’apprenant, ce dernier évolue lui aussi au fur et à mesure de ses interactions avec la simulation. L’analyse de son activité en temps-réel permettant d’inférer sur ses connaissances et compétences, ces informations peuvent être utilisées pour déterminer les nouvelles situations auxquelles il doit être confronté. Le système de scénarisation doit ainsi être capable de prendre en compte de nouveaux objectifs scénaristiques de manière dynamique. Résilience Par résilience, nous désignons la capacité du système de scénarisation à réaliser un scénario possédant les propriétés souhaitées en dépit des perturbations extérieures. En effet, l’utilisateur étant libre d’agir dans l’environnement virtuel, ses actions peuvent aller à l’encontre du scénario prévu : distraction des personnages virtuels, modification des états des objets, etc. Le système de scénarisation doit être capable de gérer ces déviations, soit en limitant les conséquences de l’action de l’utilisateur sur le scénario (intervention), soit en modifiant le scénario afin de les prendre en compte 211.3. OBJECTIFS CHAPITRE 1. INTRODUCTION (accommodation) [Riedl et al., 2003]. Cette propriété est particulièrement importante dans le cas où les objectifs du système de scénarisation et ceux de l’utilisateur sont opposés. Dans les environnements virtuels pour la formation à la maîtrise des risques, par exemple, le système de scénarisation va chercher à confronter l’apprenant à une situation accidentelle, tandis que ce dernier cherchera à l’éviter. 1.3.2 Contenu des scénarios Le second groupe d’objectifs a trait aux propriétés des scénarios générés via l’interaction de l’utilisateur et du système de scénarisation lors de sessions d’utilisation de l’environnement virtuel. Nous déterminons ainsi trois objectifs pour ces scénarios : – validité écologique, – explicabilité, – variabilité. Validité écologique Pour qu’il puisse y avoir un transfert d’apprentissage entre l’environnement virtuel et la situation de travail réelle, ou que les conclusions tirées de la simulation pour l’aide à la décision soient transposables, il faut que la situation simulée corresponde par certains aspects à la situation réelle. La reproduction parfaitement fidèle de la réalité n’est pas nécessairement un objectif en soi : dans certains cas, la situation d’apprentissage autorise une déformation ou une exagération de la réalité pour faire mieux comprendre la complexité de la situation [Lourdeaux, 2001]. Au contraire, selon la visée de la formation ou le type de système simulé, les environnements virtuels auront différents besoins en termes de réalisme. Pour des environnements virtuels destinés à la formation au geste technique, par exemple, il sera nécessaire de veiller à la fidélité perceptive de la simulation, c’est à dire à la création d’une expérience perceptive qui serait crédible si elle était vécue dans le monde réel [Burkhardt et al., 2003]. A l’inverse, lorsqu’il s’agit de former à des compétences de plus haut niveau (apprentissage de procédure, formation à la réaction dans des situations d’urgence, etc.), on va privilégier au réalisme visuel la fidélité psychologique de la simulation, c’est à dire la proportion dans laquelle la tâche simulée engendre une activité et des processus psychologiques identiques à ceux de la tâche réelle [Burkhardt et al., 2003]. Plutôt que de réalisme, on va préférer parler de validité écologique des situations. La notion de validité écologique est issue du domaine de la psychologie de la perception, et désigne la proximité entre une situation expérimentale et la situation réelle à laquelle elle fait référence. Les situations écologiquement valides sont traditionnellement mises en opposition avec les situations artificielles très contrôlées et contraintes désignées comme “laboratoires” [Loomis et al., 1999]. Puisque nous nous intéressons à des formations à des compétences de haut niveau, incluant des aspects facteurs humain, nous viserons donc la génération de scénarios rendant compte de la complexité des comportements humains dans les situations de terrain, et induisant de la part des utilisateurs des comportements équivalents à ceux rencontrés en situation réelle. Explicabilité En plus de correspondre par certains aspects à la situation réelle, ces scénarios doivent également être explicables. Il s’agit ici de pouvoir expliquer non seulement les chaînes de causalité (conséquences des actions, chaînes accidentelles, etc.), mais aussi les comportements individuels des personnages. Sans aller toutefois jusqu’à rechercher la modélisation des processus décisionnels humains à la manière cognitiviste, nous visons à intégrer des aspects facteurs humains dans la modélisation comportementale des personnages virtuels, et à assurer la cohérence de leurs comportements par rapport 22CHAPITRE 1. INTRODUCTION 1.3. OBJECTIFS à ce modèle. Il a en effet été montré dans [Si et al., 2010] que les contradictions dans les motivations des personnages virtuels ont un impact négatif sur la compréhension qu’a l’utilisateur de ce qui se passe dans l’environnement virtuel. Cette explicabilité est donc nécessaire pour que l’utilisateur puisse comprendre le déroulement des événements, ainsi que pour produire des traces et tirer des conclusions dans le cas de systèmes d’aide à la décision. De même, pour que l’utilisateur ressente un sentiment de présence dans l’environnement virtuel, il doit pouvoir se former un modèle mental du monde, et pouvoir anticiper les résultats de ses actions ainsi que de celles des personnages virtuels : l’environnement doit alors réagir de manière constante et prévisible [Slater and Usoh, 1993] La notion d’explicabilité est très liée à celle de cohérence, dans le sens de la cohérence perçue par un utilisateur. [Riedl et al., 2003] définit la cohérence d’un scénario comme la capacité par un utilisateur de comprendre les relations entre les événements du scénario, à la fois au niveau des événements du monde de la simulation, et au niveau des événements qui lui sont directement présentés. Variabilité Notre objectif est de cibler de la formation à des situations de travail complexes ou de la formation continue, plutôt que de l’entraînement à un geste technique ou à une procédure limitée. Dans cette optique, il faut que le système de scénarisation puisse générer un panel varié de scénarios, allant des scénarios les plus courants où le système fonctionne en mode nominal et les personnages virtuels réalisent la procédure prescrite, aux scénarios les plus dégradés et les plus rares. Cette variabilité peut découler d’un système permettant l’émergence de scénarios inédits, ce qui est particulièrement intéressant pour des systèmes d’aide à la décision en maîtrise des risques, où l’on va utiliser la simulation pour juger si des situations accidentelles peuvent émerger des règles de fonctionnement du système technique et des procédures associées. 1.3.3 Conception des scénarios Enfin, le troisième groupe d’objectifs concerne le processus de conception des scénarios, c’est à dire la modélisation du contenu scénaristique faite en amont par des auteurs humains. On va chercher ici à limiter l’effort nécessaire à la conception (authoring) de ces environnements. Nous déterminons ici trois objectifs principaux : – passage à l’échelle, – maintenabilité, – réutilisabilité. Passage à l’échelle La création du contenu scénaristique est aujourd’hui l’un des principaux verrous identifiés dans le domaine de la narration interactive [Spierling and Szilas, 2009]. La création du système le plus connu à l’heure actuelle, Façade, a par exemple nécessité le travail à plein temps de deux ingénieurs pendant 5 ans, dont 3 ont été passés uniquement sur la création du contenu scénaristique, et ce pour une expérience interactive de 20 minutes environ à chaque session [Mateas and Stern, 2005]. Ce problème se fait d’autant plus ressentir lorsqu’il s’agit d’opérer un passage à l’échelle, c’est à dire d’augmenter fortement la taille, la complexité et la variabilité des scénarios couverts par l’environnement virtuel. Si l’on souhaite que le système de scénarisation puisse offrir une grande variabilité en termes de scénarios générés, il faut qu’il soit conçu de manière à pouvoir augmenter le nombre de scénarios possibles sans pour autant augmenter exponentiellement la taille du contenu scénaristique nécessaire à la génération de ces scénarios. 231.4. PROBLÉMATIQUE CHAPITRE 1. INTRODUCTION Maintenabilité Dans les systèmes de narration interactive, la personne qui crée le contenu scénaristique et celle qui crée le moteur de scénarisation sont souvent en réalité la même personne [Spierling and Szilas, 2009]. Dans le cas des environnements virtuels pour la formation ou l’aide à la décision, ce constat pose problème, notamment pour ce qui est de la maintenabilité de l’environnement. En effet, si le système technique change, ou si les procédures sont mises à jour, les formateurs ou les décideurs doivent être capables d’adapter l’environnement virtuel, sinon ce dernier devient obsolète. Il faut donc, d’une part, que les connaissances soient représentées de manière explicite et séparées de l’implémentation du moteur, et d’autre part qu’elles soient représentées dans un formalisme qui soit relativement accessible à des non-informaticiens. Réutilisabilité La séparation du moteur de scénarisation et des connaissances utilisées par ce moteur est également nécessaire pour la réutilisabilité de ces connaissances. Un même environnement virtuel pourrait ainsi être utilisé pour la formation de novices, pour la formation d’experts et pour de l’aide à la décision, en modifiant les objectifs scénaristiques ou en n’utilisant qu’une partie du contenu scénaristique. De même, il serait possible de réutiliser une partie d’un environnement virtuel pour une formation à une procédure similaire sur un autre site ou sur une machinerie différente. 1.3.4 Bilan sur les objectifs Ces dix objectifs peuvent être regroupés autour de quatre axes : – la liberté d’action de l’utilisateur, – le contrôle dynamique du scénario, qui regroupe les objectifs de possibilités de contrôle, de caractère dynamique du contrôle, et de résilience du système de scénarisation, – la cohérence du scénario global et des comportements individuels, qui regroupe les objectifs de validité écologique et d’explicabilité des scénarios, – l’adaptabilité de l’environnement virtuel, qui regroupe les objectifs de variabilité, de passage à l’échelle, de maintenabilité et de réutilisabilité des scénarios. L’objectif de cette thèse est donc de proposer un système de scénarisation d’environnements virtuels — un moteur de scénarisation et un ensemble de formalismes pour la modélisation du contenu et des objectifs scénaristiques — qui concilie ces quatres axes, en permettant d’assurer à la fois la liberté d’action de l’apprenant, le contrôle dynamique de la simulation, la cohérence des comportements présentés et l’adaptabilité de l’environnement virtuel. Si ces objectifs découlent de nos motivations concernant les applications particulières que sont les environnements virtuels pour l’apprentissage ou pour l’aide à la décision, nous estimons cependant qu’ils sont suffisament larges pour qu’un système de scénarisation ainsi conçu puisse être utilisé dans d’autres contextes. 1.4 Problématique L’objectif de cette thèse est de proposer un système de scénarisation d’environnements virtuels qui permette d’assurer à la fois la liberté d’action de l’apprenant, le contrôle dynamique de la simulation, la cohérence des comportements présentés et l’adaptabilité de l’environnement virtuel. Le verrou lié à ces travaux naît de l’incompatibilité entre ces différents objectifs : le contrôle s’oppose 24CHAPITRE 1. INTRODUCTION 1.5. APPROCHE à l’adaptabilité, la liberté d’action va à l’encontre du contrôle, l’alliance du contrôle et de l’adaptabilité met en péril la cohérence, et ainsi de suite. Le domaine de la narration interactive oppose ainsi traditionnellement le contrôle et l’adaptabilité des environnements virtuels, en classifiant les approches orientées scénario, qui pilotent l’environnement virtuel au niveau global, d’un côté, et orientées émergence, qui font émerger les scénarios à partir de comportements individuels, de l’autre. Dans le domaine du jeu vidéo, on parle du paradoxe narratif pour désigner l’opposition fondamentale entre l’interactivité et la narration [Juul, 1998], c’est à dire que le fait de donner davantage de capacité d’action au joueur va venir entraver le récit prévu par l’auteur [Aylett, 1999]. De plus, ces jeux sont rarement adaptables, et la variabilité des scénarios n’est atteinte qu’au prix d’un gros travail de conception, puisque la plupart utilisent un modèle de narration arborescente, où tous les déroulements possibles doivent être décrits explicitement [Genvo, 2002]. Cet effort nécessaire pour le passage à l’échelle de scénarios cohérents et précisément contrôlés constitue ce qu’on appelle l’authoring bottleneck [Spierling and Szilas, 2009], et montre la nécessité de mettre en place des systèmes de scénarisation permettant de créer des environnements adaptables, sans avoir à définir explicitement l’intégralité des scénarios possibles. Cependant, il est fréquent que les systèmes qui proposent de concilier contrôle et adaptabilité se bornent à apposer une surcouche de contrôle sur une simulation composée d’entités autonomes, et que les interventions de ces systèmes perturbent la cohérence de l’environnement en modifiant à la volée des états de la simulation. 1.5 Approche Pour conserver la liberté d’action de l’utilisateur et assurer l’adaptabilité des scénarios, nous avons choisi d’opter pour une approche émergente et modulaire. Le contenu scénaristique est repré- senté au travers d’un ensemble de modèles — le modèle du domaine qui décrit les objets, les actions possibles et le fonctionnement des systèmes, et le modèle de l’activité qui décrit les comportements humains dans la situation considérée. L’utilisateur est libre d’effectuer n’importe quelle action permise par le modèle du domaine, et l’environnement est peuplé de personnages virtuels autonomes, capables de s’adapter aux changements dans l’environnement, dont le comportement est généré à partir du modèle de l’activité. Ces modèles, ainsi que les moteurs qui vont permettre de faire évoluer l’état du monde et de générer les comportements des personnages virtuels, vont constituer le noyau de nos environnements virtuels. A ce niveau, les scénarios émergent des interactions libres de l’utilisateur, des personnages virtuels autonomes, et des systèmes simulés. Les scénarios ainsi créés sont explicables, puisqu’ils se conforment aux modèles, et valides écologiquement, les-dits modèles étant créés par des experts à partir d’analyses terrain. Afin de pouvoir exercer un contrôle supplémentaire sur le déroulement des événements, on ajoute à ce noyau une sur-couche de scénarisation, à travers un module en charge de la gestion des objectifs scénaristiques. Ce module va, en premier lieu, utiliser les traces d’activité et le profil de l’apprenant pour déterminer de manière dynamique, à partir d’un ensemble de règles pédagogiques et scénaristiques, les objectifs scénaristiques à atteindre dans l’environnement virtuel. Dans un deuxième temps, il va chercher à générer et à réaliser un scénario qui respecte ces objectifs scénaristiques. Afin de maintenir la cohérence de la simulation, le module de scénarisation va utiliser les modèles qui la sous-tendent afin de prédire son évolution, et va chercher à guider cette évolution au travers d’un ensemble d’ajustements possibles, qui vont influencer les réactions des systèmes techniques et les prises de décision des personnages virtuels de manière indirecte, sans nuire à leur explicabilité. 251.6. CONTRIBUTIONS CHAPITRE 1. INTRODUCTION 1.6 Contributions J’ai proposé dans le cadre de cette thèse un ensemble de contributions, qui sont résumées dans cette partie, avant d’être présentées en détail dans le reste du mémoire. Mes contributions majeures sont : – SELDON, un modèle pour la scénarisation d’environnements virtuels, – DIRECTOR, un moteur de planification et réalisation de scénarios prédictifs, – CAUSALITY-DL, un langage permettant de représenter des modèles de la causalité. J’ai également participé à la proposition de deux méta-modèles, dans le cadre d’un travail commun avec mon équipe de recherche : – ACTIVITY-DL, un langage permettant de représenter des modèles de l’activité, – DOMAIN-DL, un langage permettant de représenter des modèles du domaine. 1.6.1 Modèle pour la scénarisation d’environnements virtuels – SELDON J’ai proposé le modèle SELDON, pour ScEnario and Learning situations adaptation through Dynamic OrchestratioN, qui permet d’adapter le scénario d’un environnement virtuel en fonction de l’activité de l’utilisateur en conciliant les problématiques de contrôle, de cohérence et d’adaptabilité. FIGURE 1.1 – Modèle SELDON (voir légende figure 1.2) Le modèle SELDON tient son nom du personnage d’Hari Seldon, héros de la série de romans Fondation écrite par Isaac Asimov. Seldon est le fondateur de la psychohistoire, une science visant à prédire l’histoire à partir de connaissances sur la psychologie humaine. Pour mener l’humanité vers un meilleur futur, Hari Seldon utilise ses prédictions pour élaborer le Plan Seldon, qui décrit l’évolution souhaitée de la civilisation. Afin de s’assurer de la réalisation de ce plan, il met également en place des Fondations, organisations chargées d’agir localement pour guider l’évolution de l’humanité au moment des Crises Seldon, points clés du Plan Seldon. 26CHAPITRE 1. INTRODUCTION 1.6. CONTRIBUTIONS FIGURE 1.2 – Légende des schémas Le principe derrière le modèle SELDON est similaire : à partir d’une simulation interactive peuplée d’entités autonomes, un module de scénarisation permet d’orienter indirectement le déroulement des événements en réalisant des ajustements ponctuels sur l’état du monde ou sur les personnages virtuels. Dans un premier temps, ce module utilise la trace d’activité de l’utilisateur pour générer un ensemble d’objectifs scénaristiques (désirabilité de situations particulières ou contraintes globales sur les propriétés du scénario). Puis il utilise les modèles qui sous-tendent la simulation pour prédire son évolution, et calculer un scénario répondant à ces objectifs à partir de ces prédictions et d’un ensemble d’ajustements possibles. Ces ajustements sont transmis aux moteurs de simulation du monde et de génération des comportements des personnages virtuels afin d’influencer leur évolution, de sorte à ce que le scénario prédit par le module de scénarisation se réalise effectivement dans l’environnement virtuel. 1.6.2 Moteur de planification et réalisation de scénarios prédictifs – DIRECTOR Mes travaux de thèse se sont focalisés sur la génération et la réalisation du scénario dans l’environnement virtuel, ce qui correspond à la seconde phase de la scénarisation dans le modèle SELDON. Pour cela, j’ai proposé DIRECTOR, un moteur pour l’adaptation dynamique du scénario d’un environnement virtuel, utilisant de la planification pour prédire l’évolution de la simulation, et des ajustements sur l’état du monde pour guider cette évolution vers le scénario désiré. FIGURE 1.3 – Moteur DIRECTOR 271.6. CONTRIBUTIONS CHAPITRE 1. INTRODUCTION En amont du lancement de l’environnement virtuel, DIRECTOR utilise les modèles du domaine et de l’activité pour générer un ensemble d’opérateurs de prédiction : des opérateurs de planification qui sont cadrés par des préconditions, de manière à permettre de prédire l’évolution de la simulation. Lorsque DIRECTOR, durant l’exécution de la simulation, reçoit un ensemble d’objectifs scénaristiques à atteindre, il utilise un planificateur, prenant en entrée à la fois les objectifs scénaristiques, les opérateurs de prédiction, et les opérateurs d’ajustements qui décrivent les interventions possibles sur l’environnement virtuel, pour planifier un scénario répondant aux objectifs. Le scénario planifié correspond au scénario souhaité dans la simulation, et contient à la fois des opérateurs de prédiction — qui décrivent les actions attendues de la part des personnages virtuels et de l’utilisateur, et les comportements attendus de la part des systèmes techniques — et des opérateurs d’ajustement — qui décrivent les ajustements nécessaires à la réalisation de ce scénario. Puis, à la réception des messages indiquant les changements d’état dans l’environnement virtuel, DIRECTOR va comparer l’évolution de l’état du monde avec le scénario planifié, et déclencher au besoin les ajustements. Dans le cas où le scénario effectif dévie du scénario planifié, alors DIRECTOR planifiera un nouveau scénario tenant compte des changements dans l’environnement virtuel. Goal : (fire) commitment: agent-novice marcel action: ignore-turn-off-phone marcel phone1 tank1 car1 commitment: joint-used joint1 behaviour: leak tank1 joint1 commitment: tank-empty tank1 behaviour: ignore-leak tank1 joint1 action: open-tank marcel tank1 car1 behaviour: open tank1 action: pump-gas marcel tank1 car1 behaviour: pump-gas tank1 empty behaviour: fire happening: phonecall phone1 behaviour: spark phone1 occurrence: spark-true