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.
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’e ort 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 o ert 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 in uence 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 Ra nement lié à l’induction . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3 Ra nement lié aux coupures entrelacées . . . . . . . . . . . . . . . . . . . . 81
6.4 Ra nement 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’e cacité . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 e ectivement toujours « la même
chose » ?
Nos cousins shadocks a rment 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 e et 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 e cace 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 e ectivement 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] o rent 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 o rent à 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 con uante : 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’e et 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
con uence). 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
con uence 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 su sante 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 con uence 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 e ectivement 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 ra ner 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 e et 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 e et, 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 e acé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 o re à 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 e ectué 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 e ectué 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 e acé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 e et, 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’o rir à 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 sou rent 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 su t 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 e et, E a le type even 2 alors que H a le type even m. L’hypothèse
2 = m ne su t 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 o re 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 e et, si m est e ectivement 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 su sants 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 su t 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’e cacité 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 e et, 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 e et, 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)) e cacement, 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 ra né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 ra née dans les branches mais son type n’est pas modié. Le
typage de la clause de retour ne pose pas de di culté.
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 e et 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 Squele e 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 ra nement 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 e et ê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 ra ner
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 ra nement 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 ra ner au fur et à mesure que les index du terme ltré
sont ra nés.
An d’illustrer cette a rmation, 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 su santes ? La di culté 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
di culté.
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 e et
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 di culté.
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 a aire à 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
e ectivement 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’e acer 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 di culté 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 e et 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 o re à 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 e et 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 ra ner 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’a che 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 e et, 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 ine cace 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 e acement 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 | e acement(sk)i ↓CBN hv’ | s’i alors
∆ ⊢ v 7→βδ v’ et les termes apparaissant dans l’e acement 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 ine cace. Elle est calculatoirement
ine cace 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 e et ê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 e ectivement
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 su sant 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 o rir à 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 e ectivement
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 su t pas à o rir 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 o re 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 e ective permet ce comportement en
ra nant 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
ra nements 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’e cacité.
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 e ectivement 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 e et, 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 in uencé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 e et 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 Ra nement 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 Ra nement 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 ra nements 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 Ra nement 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
insu sant à 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 su sant. 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
}
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
![[TXT]](http://www.audentia-gestion.fr/icons/text.gif){kind=icon}
